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

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

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

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

Рис. 1. Виды деятельности для прецедента Order Configured Computer (Internet-магазин)

Чтобы изобразить диаграмму, виды деятельности, обозначенные операции, следует соединить линиями перехода, как показано на рис. 2.

Рис. 2. Диаграмма видов деятельности для прецедента Order Configured Computer (Интернет магазин)

Начальное состояние деятельности — Display Current Configuration, покупателю отображаются допустимые конфигурации продаваемых компьютеров. Рекурсивный переход на этом состоянии служит признанием того факта, что отображение непрерывно обновляется до тех пор, пока покупатель не выберет требуемую ему конфигурацию компьютера, т.е. сформирует событие (выбор сделан), будет совершён следующий переход (переход в состояние Get Order Request) – получение запроса на заказ. Этот факт может интерпретироваться как осознание того, что это состояние является деятельностью, а не действием.

Если при нахождении модели в состоянии Display Purchase Form (Отображение закупочной формы) сработает условие timeout (истечение времени ожидания), то выполнение модели видов деятельности завершится. Иначе, активизируется состояние Get Purchase Details (Детализировать информацию о покупке). Если детальные данные относительно покупки неполны, система вновь переходит в состояние Display Purchase Form. В противном случае система переходит в состояние Store Order - запомнить заказ, а затем — в состояние Email Order Details - отправить детальную ин формацию по заказу (конечное состояние).

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

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

Систему образует системное состояние. Состояние является функцией содержимого системной информации в заданный момент времени — это функция системного текущего набора объектов-экземпляров.

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

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

2.1. Классы

До сих пор мы использовали классы для определения бизнес-объектов. Все классы относились к долгоживущим (постоянным или перманентным) сущностям бизнес-процессов, таким как Order (Заказ), Shipment (Доставка), Customer (Клиент), Student (Студент) и т.д. Это классы, которые определяют модель базы данных для прикладной области. По этой причине подобные классы часто называют классами-сущностями (entity class) или модельными классами. Они представляют постоянно хранимые объекты базы данных.

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

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

Следуя подходу, принятому при установлении субъектов и прецедентов, можно построить таблицу, которая поможет выявить классы в результате анализа функциональных требований (табл. 2).

Таблица 2. Соответствие функциональных требований и классов-сущностей (Internet-магазин)

№ п/п	Требование	Класс-сущность
	Для знакомства со стандартной конфигурацией выбираемого сервера, настольного или портативного компьютера клиент использует Web-страницу; Internet-магазина. При этом также приводится цена конфигурации	Customer (Клиент) Computer (Компьютер) StandardConfiguration (Стандартная конфигурация) Product (Товар)
	Клиент выбирает детали конфигурации,с которыми хочет познакомиться, возможно, с намерением купить готовую или составить более подходящую конфигурацию. Цена для каждой конфигурации может быть подсчитана по требованию пользователя	Customer, ConfiguredComputer (Сконфигурированный компьютер) ConfiguredProduct (Укомплектованный товар) Configurationltem (Элемент конфигурации)
	Клиент может выбрать вариант заказа компьютера по 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. Входит ли оно в границы прикладной области?

Перечень классов, приведенный в табл. 2, кроме того, вызывает много вопросов. К примеру, следует задаться такими вопросами.

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

2. Совпадает ли смысл понятия Shipment, приведенный в требованиях №4 и №7? Скорее всего, нет. Необходим ли нам класс Shipment, если нам известно, что поставка является обязанностью склада и, таким образом, выходит за рамки приложения?.

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

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

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

Дать ответы на эти и аналогичные вопросы не легко, для этого требуется глубокое знание требований прикладной области. В целях дальнейшей работы с данным наставлением мы выбрали классы, перечень которых приведен на рис. 2.27. Обратите \ внимание, что класс Customer (Клиент) уже появился в качестве субъекта на диаграмме прецедента — отсюда примечание "с точки зрения прецедента".

Рис.3. Классы (Интернет магазин)

Дата добавления: 2017-01-14