 |
Создание отношений между классами
|
|
|
|
Добавим отношения между классами (рис. 2.10):
· класс Client и Order - отношение ассоциации, поскольку данные два класса просто связаны друг с другом и никакие другие типы связей здесь применить нельзя. Один клиент может сделать несколько заказов, каждый заказ поступает только от одного клиента, поэтому кратность связи со стороны класса Client - 1, со стороны Order - 1..n;
· класс Order и OrderItem - отношение композиции, поскольку строка заказа является частью заказа, и без него существовать не может. В один заказ может входить несколько строк заказа, строка заказа относится только к одному заказу, поэтому кратность связи со стороны Order - 1, со стороны OrderItem - 1..n;
· класс OrderItem и ComponentPart - отношение агрегации, поскольку комплектующие изделия являются частями строки заказа, но и те, и другие, явлюятся самостоятельными классами. Одно комплектующее изделие может входить во много строк заказа, в одну строку заказа входит только одно комплектующее изделие, поэтому кратность связи со стороны ComponentPart - 1, со стороны OrderItem - 1..n.
Рис. 2.10 Классы-сущности и отношения между ними
Создание пакетов
Пакеты предназначены для группировки элементов в группы по определенным критериям. В простейшем случае классы можно группировать по их стереотипам. Создадим пакет Entities (классы-сущности):
Рис. 2.11 Пакет Entities
Группировка классов в пакеты
Группировка классов в пакеты осуществляется путем перетаскивания в Логическом представлении браузера соответствующего класса в соответствующий пакет:
Рис. 2.13 Классы и пакеты для сценария "Добавление нового заказа"
Задание для самостоятельного выполнения работы
· создать диаграмму классов для одного из сценариев диаграммы прецедентов, созданной в предыдущей лабораторной работе. Для каждого класса необходимо задать атрибуты и операции. Каждый класс должен быть подробно задокументирован - необходимо задать текстовое описание самого класса, описания его атрибутов и операций;
|
|
|
· создать пакеты для группировки классов, созданных в пункте 1;
· сгруппировать классы из пункта 1 в пакеты;
Содержание отчета
· созданные диаграммы классов (для диаграммы классов из пункта 2 задания должен быть указан сценарий, для которого данная диаграмма построена);
· краткое описание каждого созданного класса и отношений между классами.
Лабораторная работа № 3
Создание диаграмм деятельности
3.1 Цель работы: получить навыки построения диаграмм деятельности.
Теоретическое введение
Важнейшим понятием, применяемым при описании поведения, является деятельность.
Деятельность (activity) в UML — это описание поведения в форме графа деятельности.
Деятельность в UML моделирует то же, что и действие, т. е. какую-то содержательную активность во время работы системы; в этом смысле деятельность подобна действию, но деятельность противопоставляется действию по всем характеристическим признакам. В таблице 3.1 проведено сопоставление понятий "действие" и "деятельность" в UML.
Таблица 3.1 Сопоставление действия и деятельности
| Характеристика | Действие | Деятельность |
| Внешнее событие | Не прерывает выполнения | Может прерваться и завершить выполнение |
| Завершаемость | Всегда завершается самостоятельно | Может продолжаться неограниченно долго |
| Внутренняя структура | Не моделируется | Может быть раскрыта на отдельной диаграмме |
| Время выполнения | Пренебрежимо мало | Продолжительное |
Если нам не важно различие между действием и деятельностью и нужно употребить более общее понятие, то применяется термин активность.
|
|
|
Граф деятельности
Семантически граф деятельности (activity graph) — это множество сущностей, которыми являются действия или деятельности, и отношения между этими сущностями, которые задают порядок их выполнения.
Синтаксически граф деятельности — это нагруженный ориентированный (псевдо) гиперграф, в котором используются узлы четырех типов: узлы действий, узлы деятельности, узлы управления и узлы объектов, а дуги являются потоками управления или потоками данных.
На диаграмме деятельности применяется ряд значков, которые на самом деле не являются сущностями, хотя и являются узлами графа деятельности. Это так называемые узлы управления. Для VS 2010 узлы управления перечислены в Таблице 3.2.
Таблица 3.2. Узлы управления
| Название | Изображение | Что обозначает | ||
| Начальный узел (initial node) | 
| Начало деятельности | ||
| Конечный узел (final node) | 
| Завершение деятельности | ||
| Узел решения (decision node) | 
| Начало альтернативных ветвей деятельности | ||
| Узел слияния (merge node) | 
| Конец альтернативных ветвей деятельности | ||
| Узел ветвления (fork node) | 
| Начало параллельных ветвей деятельности | ||
| Соединительный узел (join node) | 
| Конец параллельных ветвей деятельности | ||
| Посылка сигнала (send) | 
| Действие посылки сигнала | ||
| Прием сигнала (accept) | 
| Ожидание события прихода сигнала | ||
Приведем пример диаграммы деятельности. Для этого рассмотрим увольнение сотрудника как бизнес-процесс, реализующий соответствующий вариант использования. Приведенная на рис. 3.0 блок схема буквально воспроизводит текстовое описание сценария. Никаких пояснений, как именно выполняется, например, деятельность Написать заявление здесь нет, но бизнес-процесс описан совершенно ясно.
Рис. 3.0 Диаграмма деятельности
|
|
|
