Файл: Применение объектно-ориентированного подхода при проектировании информационной системы.pdf

Напри­мер, у любой стены есть высота, ширина и толщина; при моделировании клиентов можно задавать фамилию, адрес, номер телефона и дату рождения. Таким образом, атрибут является абстракци­ей данных объекта или его состояния. В каждый момент времени любой атрибут объекта, принадлежащего дан­ному классу, обладает вполне определенным значением.

Операцией называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на поведение. Иными словами, операция - это аб­стракция того, что позволено делать с объектом. У всех объектов класса имеется общий набор операций. Класс может содержать любое число операций или не со­держать их вовсе. Например, для всех объектов класса 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) или действующим лицом называется любая сущность, взаимодействующая с системой извне.