Файл: Применение объектно-ориентированного подхода при проектировании информационной системы.pdf
Добавлен: 25.06.2023
Просмотров: 87
Скачиваний: 3
Например, у любой стены есть высота, ширина и толщина; при моделировании клиентов можно задавать фамилию, адрес, номер телефона и дату рождения. Таким образом, атрибут является абстракцией данных объекта или его состояния. В каждый момент времени любой атрибут объекта, принадлежащего данному классу, обладает вполне определенным значением.
Операцией называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на поведение. Иными словами, операция - это абстракция того, что позволено делать с объектом. У всех объектов класса имеется общий набор операций. Класс может содержать любое число операций или не содержать их вовсе. Например, для всех объектов класса Rectangle (Прямоугольник) из библиотеки для работы с окнами, содержащейся в пакете awt языка Java,определены операции перемещения, изменения размера и опроса значений свойств. Часто (хотя не всегда) обращение к операции объекта изменяет его состояние или его данные. Операции класса изображаются в разделе, расположенном ниже раздела с атрибутами.
Имя операции, как и имя класса, может быть произвольной текстовой строкой. На практике для именования операций используют короткий глагол или глагольный оборот, соответствующий определенному поведению объемлющего класса. Каждое слово в имени операции, кроме самого первого, обычно пишут с заглавной буквы, например move или isEmpty.
2.2. Типичные приемы моделирования. Словарь системы
С помощью классов обычно моделируют абстракции, извлеченные из решаемой задачи или технологии, применяемой для ее решения. Такие абстракции являются составной частью словаря вашей системы, то есть представляют сущности, важные для пользователей и разработчиков.
Для пользователей не составляет труда идентифицировать большую часть абстракций, поскольку они созданы на основе тех сущностей, которые уже использовались для описания системы. Чтобы помочь пользователям выявить эти абстракции, лучше всего прибегнуть к таким методам, как использование CRC-карточек и анализ прецедентов. Для разработчиков же абстракции являются обычно просто элементами технологии, которая была задействована при решении задачи.
Моделирование словаря системы включает в себя следующие этапы:
1.Определите, какие элементы пользователи и разработчики применяют для описания задачи или ее решения. Для отыскания правильных абстракций используйте CRC-карточки и анализ прецедентов.
2.Выявите для каждой абстракции соответствующее ей множество обязанностей. Проследите, чтобы каждый класс был четко определен, а распределение обязанностей между ними хорошо сбалансировано.
3. Разработайте атрибуты и операции, необходимые для выполнения классами своих обязанностей.
Shipment
Обязанности
– сохранять информацию
о товарах, поставленных по закзам
– отслеживать состояние и местонахождение товаров
Рисунок 1. Моделирование словаря системы
На рис. 1 показан набор классов для системы розничной торговли: Customer (Клиент), Order (Заказ) и Product (Товар). Представлено несколько соотнесенных с ними абстракций, взятых из словаря проблемной области: Shipment (Отгрузка), Invoice (Накладная) и Warehouse (Склад). Одна абстракция, а именно Transaction (Транзакция), применяемая к заказам и отгрузкам, связана с технологией решения задачи.
По мере того как вы будете строить все более сложные модели, обнаружится, что многие классы естественным образом объединяются в концептуально и семантически родственные группы. В языке UML для моделирования таких групп классов используются пакеты.
Как правило, модели не бывают статичными. Напротив, большинство абстракций из словаря системы динамически взаимодействует друг с другом. В UML существует несколько способов моделирования такого динамического поведения.
Если в ваш проект входит нечто большее, нежели пара несложных классов, предстоит позаботиться о сбалансированном распределении обязанностей. Это значит, что надо избегать слишком больших или, наоборот, чересчур маленьких классов. Каждый класс должен хорошо делать что-то одно. Если ваши абстрактные классы слишком велики, то модель будет трудно модифицировать и повторно использовать. Если же они слишком малы, то придется иметь дело с таким большим количеством абстракций, что ни понять, ни управлять ими будет невозможно. Язык UML способен помочь в визуализации и специфицировании баланса обязанностей.
Моделирование распределения обязанностей в системе включает в себя следующие этапы:
1. Идентифицируйте совокупность классов, совместно отвечающих за некоторое поведение.
2. Определите обязанности каждого класса.
3. Взгляните на полученные классы как на единое целое и разбейте те из них, у которых слишком много обязанностей, на меньшие - и наоборот, крошечные классы с элементарными обязанностями объедините в более крупные.
4. Перераспределите обязанности так, чтобы каждая абстракция стала в разумной степени автономной.
5. Рассмотрите, как классы кооперируются друг с другом, и перераспределите обязанности с таким расчетом, чтобы ни один класс в рамках кооперации не делал слишком много или слишком мало.
2.3. Внепрограммные сущности
Моделируемые вами сущности могут не иметь аналогов в программном обеспечении. Например, частью рабочего процесса в модели предприятия розничной торговли могут быть люди, отправляющие накладные, и роботы, которые автоматически упаковывают заказанные товары для доставки со склада по месту назначения. В вашем приложении совсем не обязательно окажутся компоненты для представления этих сущностей (в отличие от сущности «клиент», для хранения информации о которой, собственно, и создается система).
View
Обязанности
– изображать модель на экране
– управлять перемещением и изменением размера поля зрения
– перехватывать события пользователя
Controller
Обязанности
– синхронизировать изменение модели и ее видов
Model
Обязанности
– управлять состоянием
модели
Рисунок 2. Моделирование распределения обязанностей в системе
Моделирование внепрограммных сущностей производится следующим образом:
1. Смоделируйте сущности, абстрагируемые в виде классов.
2. Если вы хотите отличить эти сущности от предопределенных строительных блоков UML, создайте с помощью стереотипов новый строительный блок, опишите его семантику и сопоставьте с ним ясный визуальный образ.
3.Если моделируемый элемент является аппаратным средством с собственным программным обеспечением, рассмотрите возможность смоделировать его в виде узла, которая позволила бы в дальнейшем расширить его структуру.
Примечание UML предназначен в первую очередь для моделирования программных систем, однако в сочетании с текстовым языком моделирования аппаратных средств, таким как VHDL, его вполне допустимо использовать и для моделирования аппаратных систем.
2.4. Примитивные типы
Другой крайностью являются сущности, взятые непосредственно из языка программирования, используемого при решении задачи. Обычно к таким абстракциям относят примитивные типы, например целые, символы, строки и даже перечислимые типы, которые вы создаете сами.
Моделирование примитивных типов производится следующим образом:
1. Смоделируйте сущность, абстрагируемую вами в виде типа или перечисления. Она изображается с помощью нотации класса с подходящим стереотипом.
2.Если требуется задать связанный с типом диапазон значений, воспользуйтесь ограничениями.
Рис. 3 показывает, что такие сущности можно моделировать в UML как типы или перечисления, которые изображаются точно так же, как классы, но с явно указанным стереотипом. Сущности, подобные целым числам (представленные классом Int), моделируются как типы, а с помощью ограничений вы можете явно указать диапазон принимаемых значений. Перечислимые типы (скажем, Boolean и Status) допустимо моделировать как перечисления, причем их конкретные значения становятся атрибутами.
Такие языки, как Си C++, позволяют определить эквивалентные целые значения для перечислений. Подобное моделирование возможно и в UML, если указать для атрибута, обозначающего перечисление, константное начальное значение по умолчанию.
Рисунок 3. Моделирование примитивных типов
2.5. Рекомендации к моделированию классов
При моделировании классов в UML всегда помните, что каждому классу должна соответствовать некоторая реальная сущность или концептуальная абстракция из области, с которой имеет дело пользователь или разработчик. Хорошо структурированный класс обладает следующими свойствами:
- является четко очерченной абстракцией некоторого понятия из словаря проблемной области или области решения;
- содержит небольшой, точно определенный набор обязанностей и выполняет каждую из них;
- поддерживает четкое разделение спецификаций абстракции и ее реализации;
- понятен и прост, но в то же время допускает расширение и адаптацию к новым задачам.
Изображая класс в UML, придерживайтесь следующих правил:
- показывайте только те его свойства, которые важны для понимания абстракции в данном контексте;
- разделяйте длинные списки атрибутов и операций на группы в соответствии с их категориями;
- показывайте взаимосвязанные классы на одной и той же диаграмме.
Выводы
Базовым понятием объектно-ориентированного программирования является класс. Классом называется описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. UML имеет развитые средства позволяющие отобразить структуру классов и связи между ними, соответствующие статическому виду системы с точки зрения проектирования. Имеющиеся в арсенале UML диаграммы классов и объектов при моделировании объектно-ориентированных систем используются чаще всего (особенно диаграммы классов).
Графически класс изображается в виде прямоугольника. Прямоугольник разделяется на три раздела: первый содержит имя, второй атрибуты (свойства), третий операции, кроме того, могут использоваться дополнительные разделы, содержащие обязанности класса, список принимаемых сигналов и т.п. Имеются развитые средства описания свойств атрибутов и свойств и структуры операций (область видимости, область действия, типы атрибутов, атрибуты операций и их свойства и т.д.).
На начальном этапе проектирования важно распределить обязанности в системе между классами. На этом этапе рекомендуется использовать упрощенную спецификацию классов, содержащую только имя класса и его обязанности.
При моделировании систем, особенно интерактивных, возникает необходимость работать с объектами принципиально различного типа. Язык UML имеет возможности моделирования классов (и соответственно объектов) в широком диапазоне от внепрограммных сущностей до примитивных типов данных.
3. Примеры моделирования
Рассмотрим задачу разработки модели справочно-информационной системы музыки на CD. Данная система должна предоставлять пользователю средства электронной картотеки, включать в себя такие возможности как: добавление, удаление и редактирование данных об исполнителях, альбомах; обеспечивать поиск записи по названию альбома, по стилю; поиск исполнителя; просмотр обложки альбома и фотографии исполнителя.
Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме диаграммы прецедентов (вариантов использования), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования.
В качестве среды моделирования будем использовать систему Rational Rose [3] фирмы Rational Software, являющейся признанным лидером в разработке систем моделирования программного обепспечения.
3.1. Диаграмма прецедентов
Диаграмма прецедентов является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне.