Моделирование взаимодействий

Моделирование классов

Диаграмма видов деятельности

Диаграмма видов деятельности (activity diagram) показывает переходы между видами деятельности. Если вид деятельности не представляет собой замкнутого цикла, то диаграмма содержит начальное состояние вида деятельности и одно или более конечных состояний вида деятельности.

Переходы могут разветвляться по условию и объединяться. В результате возникают альтернативные (alternative) вычислительные потоки (thread). Условие ветвления обозначается ромбом. Переходы могут также разделяться и сливаться. В результате возникают параллельные (одновременно выполняемые) (concurrent) потоки. Распараллеливание и воссоединение переходов представляется в виде жирной линии или полосы. Заметим, что диаграмма вида деятельности, в которой отсутствуют параллельные процессы, похожа на обычную блок_схему.

Начальное состояние деятельности — Отображение текущей конфигурации. Рекурсивный переход на этом состоянии служит признанием того факта, что отображение непрерывно обновляется до тех пор, пока не сработает следующий переход (переход в состояние Получение запроса на заказ). Этот факт может интерпретироваться как осознание того, что это состояние является деятельностью, а не действием.

Если при нахождении модели в состоянии Получение закупочной формы сработает условие [время вышло], то выполнение модели видов деятельности завершится. Иначе, активизируется состояние Детализировать информацию о покупке. Если детальные данные относительно покупки неполны, система вновь переходит в состояние Отображение закупочной формы. В противном случае система переходит в состояние Запомнить заказ, а затем — в состояние Отправить детальную информацию по заказу (конечное состояние).

Обратите внимание, что на диаграмме показаны только те условные переходы, которые появляются на выходах из состояния вида деятельности. Условные переходы, которые являются внутренними для состояния вида деятельности, не показаны явно на диаграмме. Об их существовании можно догадаться по наличию нескольких исходящих переходов, которые, возможно, сопровождаются именем условия в квадратных скобках (например, таким как [время вышло] на выходе из состояния Отображение закупочной формы).

Рисунок 4.2. Диаграмма видов деятельности для прецедента Заказ сконфигурированного компьютера

Классы-сущности определяют существо любой информационной системы. Анализ требований направлен преимущественно на выявление классов-сущностей. Однако, для функционирования системы требуются также классы другого типа. Пользователям системы необходимы классы, которые определяют объекты графического интерфеса (например, такие как экранные формы), называемые пограничными классами (boundary classes) Чтобы функционировать надлежащим образом, системе также необходимы классы, которые управляют программной логикой — управляющие классы (control classes)

В зависимости от конкретного подхода к моделированию пограничные и управляющие классы могут рассматриваться или не рассматриваться на некотором уровне представления в ходе анализа требований. Моделирование классов этого типа может быть отложено до этапа проектирования системы.

Можно построить таблицу, которая поможет выявить классы в результате анализа функциональных требований.

Таблица 4.4. Соответствие функциональных требований и классов-сущностей

№	Требование	Класс-сущность
	Для знакомства со стандартной конфигурацией выбираемого сервера, настольного или портативного компьютера клиент использует Web-страницу Internet-магазина. При этом также приводится цена конфигурации	● Customer (Клиент); ● Computer (Компьютер); ● StandardConfiguration (Стандартная конфигурация); ● Product (Товар)
	Клиент выбирает детали конфигурации, с которыми хочет познакомиться, возможно, с намерением купить готовую или составить более подходящую конфигурацию. Цена для каждой конфигурации может быть подсчитана по требованию пользователя	● Customer, ● ConfiguredComputer (Сконфигурированный компьютер); ● ConfiguredProduct (Укомплектованный товар); ● ConfigurationItem (Элемент конфигурации)
	Клиент может выбрать вариант заказа компьютера по Internet либо попросить, чтобы продавец связался с ним для объяснения деталей заказа, договорился о цене и т.п. прежде, чем заказ будет фактически размещен	● Customer, ConfiguredComputer, ● Order (Заказ), ● Salesperson (Продавец)
	Для размещения заказа клиент должен заполнить электронную форму с адресами для доставки товара и отправки счета-фактуры, а также деталями, касающимися оплаты (кредитная карточка или чек)	● Customer; ● Order; ● Shipment(Поставка); ● Invoice (Счет_фактура); ● Payment (Платеж)
	После ввода заказа клиента в систему продавец отправляет на склад электронное требование, содержащее детали, касающиеся заказанной конфигурации	● Customer; ● Order; ● Salesperson; ● ConfiguredComputer; ● ConfigurationItem
	Детали сделки, включая номер заказа, номер счета клиента, отправляются по электронной почте клиенту, так что заказчик может проверить состояние заказа через Internet	● Order; ● Customer; ● OrderStatus ● (Состояние заказа)
	Склад получает счет-фактуру от продавца и отправляет компьютер клиенту	● Invoice; ● Shipment

Выделение классов представляет собой итеративную задачу, и первоначальный перечень предполагаемых классов, как правило, претерпевает изменения. При определении того, являются ли понятия, присутствующие в требованиях, искомыми классами, могут помочь ответы на некоторые вопросы. Вот эти вопросы.

1 Является ли понятие “вместилищем” данных?

2 Обладает ли оно отдельными атрибутами, способными принимать разные значения?

3 Можно ли создать для него множество объектов-экземпляров?

4 Входит ли оно в границы прикладной области?

При анализе таблицы возникают следующие вопросы:

1 В чем различие между классами ConfiguredComputer (Сконфигурированный компьютер) и Order (ЗаказБудем ли мы хранить информацию о сконфигурированном компьютере (ConfiguredComputer), до того как заказ (объект Order) размещен или нет?

2 Совпадает ли смысл понятия Shipment (Поставка), приведенный в требованиях №4 и №7?

3 Если нет, тонужен ли нам класс Shipment, если нам известно, что поставка является обязанностью склада и, таким образом, выходит за рамки приложения?

4 Не является ли понятие элемента конфигурации (ConfigurationItem) просто атрибутом понятия сконфигурированного компьютера (ConfiguredComputer)?

5 Является понятие состояние заказа (OrderStatus) самостоятельным классом или это атрибут понятия заказа (Order)?

6 Является ли понятие продавца (Salesperson) самостоятельным классом или это атрибут понятий Order и Invoice?

Ответив на эти вопросы (дать ответы на эти и аналогичные вопросы не легко, для этого требуется глубокое знание требований прикладной области), можно получить следующие классы:

● Customer (Клиент) – с точки зрения прецедента (Клиент появился в качестве субъекта на диаграмме прецедента).

● Computer (Компьютер).

● ConfiguredComputer (Сконфигурированный компьютер);

● ConfigurationItem (Элемент конфигурации).

● Order (Заказ).

● Payment (Платеж).

● Invoice (Счет_фактура).

При дальнейшем анализе предметной области определяем атрибуты классов.

Рисунок 4.3. Классы и элементарные атрибуты (Интернет-магазин)

Рассмотрим связи, которые можно установить между классами.

Ассоциации, связывающие классы, устанавливают пути, облегчающие взаимодействие объектов. В модели анализа ассоциации представлены соединительными линиями. На рис. 4.4. показаны наиболее очевидные ассоциации между классами. При определении кратности ассоциаций был сделан ряд предположений. Заказ (Order) поступает от одного клиента (Customer), однако клиент может разместить несколько заказов. Заказ не принимается до тех пор, пока не определены реквизиты платежа (Payment) (отсюда, ассоциация типа “один к одному”). Заказ не должен обладать связанной с ним счетом-фактурой (Invoice), однако счет-фактура всегда связана с единственным заказом. Заказ делается на один или несколько сконфигурированных компьютеров (ConfiguredComputer). А компьютер с данной конфигурацией может заказываться многократно или не заказываться вовсе.

Рисунок 4.4. Ассоциации (Интернет-магазин)

Агрегация и композиция являются более сильной формой ассоциативной связи, которой присуща семантика принадлежности. На рис. 4.5. к модели добавлены отношения агрегации. Компьютер (Computer) обладает одним или более элементами конфигурации (ConfigurationItems). Подобно этому, сконфигурированный компьютер (ConfiguredComputer) состоит из одного или нескольких элементов (ConfigurationItems).

Обобщение представляет собой средство повторного использования ПО, кроме того, оно также способно в значительной мере упростить и прояснить модель. Обобщение обычно используют как метод создания дополнительных базовых классов (как правило, абстрактных). Упрощение достигается за счет увеличения точности, с которой существующий класс может быть ассоциирован с наиболее подходящими (т.е. на наиболее удобном уровне абстракции) классами в иерархии обобщения.

На рис. 4.6. показана модифицированная модель, в которой класс изменен на абстрактный класс Computer, являющийся базовым для двух производных классов - StandardComputer и ConfiguredComputer. Теперь классы Order и ConfigurationItem связаны с классом Computer, который может быть либо классом StandardComputer, либо классом ConfiguredComputer.

В результате мы получили диаграмму классов, которая составляет основу объектно-ориентированной системы. В классах пока не определены операции. Операции принадлежат больше к сфере проектирования, а не анализа. После того, как операции в конечном итоге вводятся в классы, модель классов в явном виде определяет поведение системы.

Рисунок 4.5. Агрегации (Интернет-магазин)

Рисунок 4.6. Диаграмма классов (Интернет-магазин)

Моделирование взаимодействий рассматривает вопросы взаимодействия между объектами, необходимыми для выполнения прецедента. Модели взаимодействия используются на более развитых стадиях анализа требований, когда становится известной модель классов, так что ссылки на объекты опираются на модель классов.

Диаграммы взаимодействий разделяются на два вида - диаграммы последовательностей и диаграммы кооперации. Они могут использоваться как взаимозаменяемые, и многие CASE-средства поддерживают автоматическое преобразование одной модели в другую. Разница между моделями заключается в акцентах. Модели последовательностей концентрируются на временных последовательностях событий, а в моделях кооперации основное внимание уделяется отношениям между объектами.

Диаграммы последовательностей, как правило, используются на этапе анализа требований, а диаграммы кооперации — системного проектирования. Этот выбор соответствует общепринятой практике разработки ИС.

Взаимодействие представляет собой набор сообщений, свойственных поведению некоторой системы, которыми обмениваются объекты в соответствии с установленными между ними связями. Диаграмма последовательностей представляется двумерным графом. Объекты располагаются по горизонтали. Последовательности сообщений располагаются сверху вниз по вертикали. Каждая вертикальная линия называется линией жизни (lifeline) объекта.

Стрелки представляют каждое сообщение, направляемое от вызывающего объекта (отправителя) к операции (методу) вызываемого объекта (получателя). Для каждого сообщения, как минимум, указывается его имя. Кроме того, для сообщения могут быть указаны фактические аргументы сообщения и другая управляющая информация. Фактические аргументы соответствуют формальным аргументам метода объекта получателя.

Фактические аргументы могут быть входными аргументами (передаются от отправителя к получателю) или выходными аргументами (передаются от получателя назад к отправителю). Входные аргументы могут быть обозначены ключевым словом in (если ключевое слово отсутствует, то предполагается, что аргумент — входной). Выходные аргументы обозначаются ключевым словом out. Допускаются также аргументы типа inout (“входные/выходные”), однако, для объектно-ориентированного подхода они не характерны.

Показывать на диаграмме возврат управления от объекта-получателя объекту-отправителю не обязательно. Стрелка, указывающая на объект-получатель, предполагает автоматический возврат управления отправителю. Получатель знает уникальный идентификатор объекта (Object Identifier, OID) отправителя. Сообщение может быть отправлено коллекции объектов (коллекция может быть набором, списком, массивом объектов и т.д.). Довольно частой является ситуация, когда вызывающий объект связан с несколькими объектами-получателями (поскольку кратность ассоциации указана как “один ко многим” или “многие ко многим”). Итеративный маркер - звездочка перед обозначением сообщения - указывает на процесс итерации сообщения по всей коллекции.

Диаграмма последовательностей для “отображения текущей конфигурации” показана на рис. 4.7. Внешний субъект - клиент (Customer) принимает решение об отображении конфигурации компьютера. Сообщение openNew (открыть новое [окно]) отправляется объекту confWin класса ConfWin ([диалоговое] окно конфигурации). В результате создается новый объект confWin. Класс ConfigurationWindow - пограничный класс.

Объекту ConfWin необходимо “отобразить себя” вместе с данными, относящимися к конфигурации. С этой целью он отправляет сообщение объекту aComp:Computer. В действительности, aComp — это объект класса StandardComputer или ConfiguredComputer. Класс Computer — абстрактный класс. Объект aComp использует выходной аргумент для того, чтобы “собрать себя” из элементов конфигурации — объектов ConfigurationItem. Затем он “оптом” отсылает элементы конфигурации объекту aConfWin в качестве аргумента i_recset сообщения displayComputer. Теперь объект aConfWin может отобразить себя на экране.

Рисунок 4.7. Диаграмма последовательностей для вида деятельности Отображение текущей конфигурации.

Хотя введение операций в классы часто откладывается до этапа проектирования, исследование взаимодействий между классами может привести к выявлению операций. Между взаимодействиями и операциями существует прямая зависимость. Каждое сообщение обращается к операции в вызываемом объекте. Имена операции и сообщения совпадают. Для каждого сообщения на диаграмме последовательностей нужно ввести операцию на диаграмме классов.

Изменениям вносятся в три класса. Класс ConfigurationWindow — это пограничный класс. Два других класса — это классы-сущности, представляющие постоянные объекты базы данных. Операция openNew выбрана в качестве шаблона операции конструктора. Это означает, что операция openNew будет реализована в качестве метода конструктора, который порождает новые объекты класса. (В RSA – операции добавляются в классы автоматически).

Для каждого прецедента, как правило, строится отдельная диаграмма последовательностей. Т.к. каждый прецедент должен быть выражен через диаграмму видов деятельности, диаграмма последовательностей строится для каждой диаграммы видов деятельности. Использование нескольких взаимоувязанных точек зрения на одну и ту же систему является краеугольным камнем моделирования.

Диаграмма последовательностей во многом является самоочевидной. Сообщение acceptConf вызывает отправку сообщения prepareForOrder объекту:Order. Это приводит к созданию временного объекта:Order, отображаемого в “объекте-окне”:OrderWindow.

В ответ на принятие клиентом детализированных условий заказа (submitOrder) объект:OrderWindow инициирует (storeOrder) создание постоянного объекта:Order. После этого объект-заказ:Order устанавливает связь с заказанным компьютером (:Computer), а также соответствующими клиентом (:Customer) и платежом:Payment. После того, как эти объекты постоянно связаны в базе данных, объект:Order отправляет электронное сообщение emailOrder клиенту (Customer).

Обратите внимание на двойное использование сущности:Customer - в качестве внешнего субъекта, представленного объектом, и внутреннего объекта-класса. Подобная двойственность довольно часто встречается в моделировании. Клиент (Customer) является по отношению к системе одновременно и внешней, и внутренней сущностью. Он представляет собой внешнюю сущность, поскольку взаимодействует с системой извне. Однако информация о клиенте должна храниться в системе, чтобы иметь возможность установить идентичность внешнего клиента и внутренней сущности, о которой знает система.

Рисунок 4.8. Диаграмма последовательности для прецедента Заказ выбранной конфигурации (Интернет-магазин)

Дата добавления: 2014-01-05