МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РФ
А. К. Бойцов, С. С. Колмогорова
ПРАКТИЧЕСКОЕ МОДЕЛИРОВАНИЕ
НА UML
Монография
Санкт-Петербург
2023
УДК 004.434:004.94
ББК 32.973.26+32.973.42
Б77
Рецензенты:
С. П. Присяжнюк, профессор, д-р техн. наук,
заслуженный деятель науки РФ,
действенный член АИН им. А.М. Прохорова,
генеральный директор Санкт-Петербургской научной организации «Институт
телекоммуникаций»,
А. В. Никонов, профессор, д-р техн. наук,
профессор кафедры автоматизированные системы
обработки информации и управления
Омского государственного технического университета
Б77
Бойцов А. К., Колмогорова С. С.
Практическое моделирование на UML : монография / А. К. Бойцов,
С. С. Колмогорова ; Минобрнауки России, [ФГБОУ ВО СПбГЛТУ,
ФГБОУ ВО СПбГЭТУ «ЛЭТИ»]. — Санкт-Петербург : Реноме,
2023. — 684 с.
ISBN 978-5-00125-880-3
UML является важным инструментом разработки программного обес­
печения, который можно использовать для моделирования структуры
приложения, поведения и бизнес-процессов. Это помогает пользовате­
лям понять процесс проектирования и разработки. Он также состоит из
нескольких интересных позиций, таких как разработка процедур оформ­
ления заказа в электронной коммерции, разработка эффективной базы
данных для взаимосвязанных таблиц, решение общих проблем проекти­
рования, диаграммы пользовательских случаев, а также диаграммы эле­
ментов и действий. Тем не менее, этот элемент разработки программного
обеспечения может быть довольно проблематичным для большинства
пользователей, поскольку он состоит из таких тем, как моделирование баз
данных, моделирование процессов и разработка алгоритмов. Диаграммы
UML не слишком просты, нужно много работать над заданиями на
основе диаграмм UML. Таким образом, нужна профессиональная помощь
по назначению диаграмм UML. Авторами предлагается монография
по назначению диаграмм UML, которое и помогает добиться наилучших
результатов в данной области моделирования.
Табл. 12, ил. 664, библиограф.: 38 назв.
ISBN 978-5-00125-880-3
© А. К. Бойцов, С. С. Колмогорова, 2023
© Санкт-Петербургский государственный
лесотехнический университет имени
С. М. Кирова, 2023
© Санкт-Петербургский государственный
электротехнический университет «ЛЭТИ»
имени В.И. Ленина, 2023
https://t.me/it_boooks/2
Оглавление
ВВЕДЕНИЕ .....................................................................................................................................................................11
КАК РАБОТАТЬ С КНИГОЙ .................................................................................................................................... 12
РАЗДЕЛ I ВВЕДЕНИЕ В UML................................................................................................................................... 13
1. ОСНОВНЫЕ ОБЛАСТИ ИСПОЛЬЗОВАНИЯ И ПОНЯТИЯ UML ДИАГРАММ................................................................................ 14
1.1. Понятие UML Диаграмм ................................................................................................................................ 14
1.2. Программные инструменты UML .............................................................................................................. 15
1.3. Различные типы UML Диаграмм ................................................................................................................. 21
1.4. Применение UML Диаграмм .......................................................................................................................... 24
1.5. Версии UML Диаграмм .................................................................................................................................... 25
2. КЛАССИФИКАЦИЯ UML ДИАГРАММ ..................................................................................................................................................................... 30
2.1. Таксономия UML Диаграмм ........................................................................................................................... 30
2.2. Структурные UML Диаграммы ....................................................................................................................33
2.2. UML Диаграммы повеДения ........................................................................................................................... 37
3. ОСНОВНЫЕ ЭЛЕМЕНТЫ UML ......................................................................................................................42
3.1. Пакет яДра ....................................................................................................................................................... 42
3.2. Элемент ........................................................................................................................................................... 42
3.3. ВлаДение ........................................................................................................................................................... 43
3.4. Именованный элемент .................................................................................................................................. 44
3.5. ПереопреДеляемый элемент ........................................................................................................................ 44
3.6. Тип ......................................................................................................................................................................45
3.7. Функция ............................................................................................................................................................. 46
3.7.1. Понятие функции ....................................................................................................................................................... 46
3.7.2. Нестатическая функция .............................................................................................................................................47
3.7.3. Статическая функция .................................................................................................................................................47
3.7.4. Структурная особенность ......................................................................................................................................... 48
3.7.5. Поведенческая особенность .................................................................................................................................... 48
3.8. Экземпляр и спецификация экземпляра ...................................................................................................... 49
3.9. Отношение ...................................................................................................................................................... 52
3.10. Направленные отношения .......................................................................................................................... 54
3.11. Комментарий ................................................................................................................................................ 54
РАЗДЕЛ II СТРУКТУРНЫЕ UML ДИАГРАММЫ .............................................................................................56
4. UML ДИАГРАММА КЛАССОВ ........................................................................................................................ 57
4.1. Понятие и типы UML Диаграммы классов................................................................................................. 57
4.2. Класс.................................................................................................................................................................. 59
4.3. Абстрактный класс ........................................................................................................................................ 63
4.4. Стереотипы класса ........................................................................................................................................ 64
4.5. Шаблон класса ................................................................................................................................................. 68
4.6. Интерфейс ....................................................................................................................................................... 69
4.7. Функция ............................................................................................................................................................. 72
4.8. UML-ограничение.............................................................................................................................................81
4.9. Отношения ...................................................................................................................................................... 83
4.9.1. UML-ассоциация........................................................................................................................................................84
4.9.2. Обобщение в UML..................................................................................................................................................... 93
4.9.3. Зависимость в UML ................................................................................................................................................... 99
5. UML ДИАГРАММА ОБЪЕКТОВ ...................................................................................................................107
5.1. Понятие UML Диаграммы объектов ........................................................................................................ 107
5.2. UML-объект................................................................................................................................................... 108
5.3. Слот ................................................................................................................................................................ 110
5.4. Ссылка ............................................................................................................................................................. 111
6. UML ДИАГРАММА ПАКЕТОВ ......................................................................................................................112
6.1. Понятие UML Диаграммы пакетов .......................................................................................................... 112
3
6.2. Схема UML диаграммы пакетов................................................................................................................. 112
6.3. Пакеты ............................................................................................................................................................113
6.3.1. Понятие пакета......................................................................................................................................................... 113
6.3.2. Атрибут URI пакета ...................................................................................................................................................116
6.3.3. Шаблон пакета ......................................................................................................................................................... 117
6.3.4. Упаковываемый элемент ....................................................................................................................................... 118
6.4. Объединение пакетов UML ......................................................................................................................... 119
6.5. Импорт пакета UML ....................................................................................................................................120
6.6. Зависимость в UML ....................................................................................................................................... 122
7. UML ДИАГРАММА МОДЕЛИ........................................................................................................................ 130
7.1. Понятие UML диаграммы модели.............................................................................................................. 130
7.2. Схема UML диаграммы модели................................................................................................................... 130
7.3. UML- модель ................................................................................................................................................... 131
7.4. UML профиль.................................................................................................................................................. 134
7.5. UML-стереотип............................................................................................................................................137
7.5.1. Понятие UML-стереотипа....................................................................................................................................... 137
7.5.2. Применение стереотипов ...................................................................................................................................... 139
7.5.2. Стереотипные отношения ...................................................................................................................................... 141
7.5.2. Определение тега ....................................................................................................................................................142
7.6. Метакласс UML профиля ............................................................................................................................ 145
7.7. UML - актер .................................................................................................................................................... 145
7.7.1. Понятие UML - актера............................................................................................................................................ 145
7.7.2. Бизнес-актер ............................................................................................................................................................. 148
7.7.3. Отношения между актерами .................................................................................................................................. 149
8. СОСТАВНЫЕ СТРУКТУРНЫЕ UML ДИАГРАММЫ ........................................................................... 150
8.1. Понятие и типы составных структурных UML диаграмм ................................................................ 150
8.2. UML диаграмма внутренней структуры................................................................................................. 150
8.2.1 Понятие и схема UML диаграммы внутренней структуры ................................................................................ 150
8.2.3 Класс .......................................................................................................................................................................... 151
8.2.3 UML-часть................................................................................................................................................................. 155
8.2.4 UML-порт.................................................................................................................................................................. 157
8.2.5 UML-соединитель.....................................................................................................................................................163
8.2.6 UML-использование................................................................................................................................................ 168
8.3. UML диаграмма кооперации ....................................................................................................................... 171
8.3.1 Понятие и схема UML диаграммы кооперации ................................................................................................... 171
8.3.2 UML-сотрудничество.............................................................................................................................................. 175
8.3.3 UML-соединитель.....................................................................................................................................................178
8.3.4 UML-часть................................................................................................................................................................. 183
8.3.5. Зависимость в UML ................................................................................................................................................ 185
9. UML ДИАГРАММА КОМПОНЕНТОВ ....................................................................................................... 192
9.1. Понятие и схема UML диаграммы компонентов ................................................................................... 192
9.2. Компонент .................................................................................................................................................... 193
9.2.1 Понятие компонента ................................................................................................................................................ 193
9.2.2 Обозначение .............................................................................................................................................................. 194
9.2.3 Стереотипы стандартных компонентов ................................................................................................................ 197
9.2.4 История ...................................................................................................................................................................... 199
9.3. Интерфейс ..................................................................................................................................................... 200
9.4. Класс................................................................................................................................................................ 203
9.5. Порт ............................................................................................................................................................... 206
9.6. UML-соединитель......................................................................................................................................... 213
9.7. Артефакт ...................................................................................................................................................... 218
9.8. Реализация компонента ............................................................................................................................. 222
9.9. Зависимость .................................................................................................................................................. 224
9.10. Использование ............................................................................................................................................ 225
10. UML ДИАГРАММЫ РАЗВЁРТЫВАНИЯ.................................................................................................. 228
10.1. Определение и типы UML диаграмм развертывания ......................................................................... 228
10.2. Понятия UML диаграмм развертывания ...............................................................................................229
10.2.1 Проявление .............................................................................................................................................................. 229
4
10.2.2 Цель развертывания................................................................................................................................................230
10.2.3 Узел.......................................................................................................................................................................... 231
10.2.4 Устройство .............................................................................................................................................................. 234
10.2.5 Среда выполнения ................................................................................................................................................. 236
10.2.6 Путь связи ............................................................................................................................................................... 237
10.2.7 Развертывание ......................................................................................................................................................... 238
10.2.8 Спецификация развертывания .............................................................................................................................. 241
10.2.9 Зависимость спецификации развертывания ....................................................................................................... 242
10.2.10 Ассоциация спецификаций развёртывания ...................................................................................................... 243
10.2.11 UML-стереотип......................................................................................................................................................243
10.2.11.1 Понятие UML-стереотипа............................................................................................................................ 243
10.2.11.2 Применение стереотипов............................................................................................................................ 245
10.2.11.3 Стереотипные отношения ........................................................................................................................... 248
10.2.11.4 Определение тега ........................................................................................................................................ 248
10.3. UML диаграмма проявления компонентов артефактами ............................................................... 251
10.4. UML диаграмма развертывания уровня спецификации ......................................................................252
10.5. UML диаграмма развертывания на уровне экземпляра ......................................................................253
10.6. Сетевая архитектура уровня спецификации ...................................................................................... 254
10.6.1. Понятие и схема сетевой архитектуры .............................................................................................................. 254
10.6.2. Сетевые устройства .............................................................................................................................................. 255
10.6.3. Сегменты сети ........................................................................................................................................................ 258
10.7. Диаграмма артефактов ........................................................................................................................... 261
10.7.1. Понятие и схема диаграммы артефактов .......................................................................................................... 261
10.7.2. Применение диаграммы артефактов ...................................................................................................................262
10.7.3. Основные элементы диаграммы артефактов ..................................................................................................... 263
10.7.4. Советы и рекомендации по диаграмме артефактов ..........................................................................................269
11. UML ДИАГРАММА ПРОФИЛЯ ................................................................................................................... 271
11.1. Понятие и схема UML диаграммы профиля .......................................................................................... 271
11.2. Профиль ........................................................................................................................................................ 273
11.3. Метакласс ................................................................................................................................................... 275
11.4. Стереотип ................................................................................................................................................... 276
11.4.1 Понятие UML-стереотипа................................................................................................................................. 276
11.4.2 Применение стереотипов................................................................................................................................. 278
11.4.3 Стереотипные отношения ................................................................................................................................ 280
11.4.4 Определение тега ............................................................................................................................................. 281
11.5. Расширение профиля UML ......................................................................................................................... 284
11.6. Ссылка ........................................................................................................................................................... 286
11.7. Приложение профиля UML ........................................................................................................................287
РАЗДЕЛ III UML ДИАГРАММЫ ПОВЕДЕНИЯ ............................................................................................... 289
1. UML ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ...................................................................... 290
1.1. Понятие UML диаграммы вариантов использования ........................................................................... 290
1.2. Схема бизнес-прецедентов ........................................................................................................................ 290
1.2.1. Понятие и схема бизнес-прецедентов ...................................................................................................................290
1.2.2. Бизнес-прецедент .....................................................................................................................................................292
1.2.3. Бизнес-актер ............................................................................................................................................................. 294
1.2.4. Обобщение в UML ...................................................................................................................................................295
1.2.5. Тема UML варианта использования ......................................................................................................................296
1.2.6. Предмет бизнес-модели ......................................................................................................................................... 298
1.2.7. Отношения включения варианта использования ................................................................................................ 300
1.2.7.1 Понятие отношения включения варианта использования ......................................................................... 300
1.2.7.2 Сравнение взаимосвязей вариантов использования.................................................................................. 304
1.2.7.3 Отсутствие связи варианта использования ................................................................................................... 305
1.2.8. Расширение варианта использования UML......................................................................................................... 307
1.2.8.1 Понятие расширения варианта использования UML .................................................................................. 307
1.2.8.2 Точка расширения............................................................................................................................................ 308
1.3. Схема вариантов использования системы ..............................................................................................309
1.3.1. Использование и элементы схемы вариантов использования системы ...........................................................309
1.3.2. UML - актер............................................................................................................................................................. 310
5
1.3.2.1 Понятие UML - актера ...................................................................................................................................... 310
1.3.2.2 Бизнес-актер ..................................................................................................................................................... 312
1.3.2.2 Отношения между актерами........................................................................................................................... 313
1.4.Вариант использования UML ....................................................................................................................... 314
1.4.1. Понятие варианта использования UML ............................................................................................................... 314
1.4.2. Абстрактный вариант использования ..................................................................................................................318
1.4.3. Пример использования в бизнесе ..........................................................................................................................321
1.4.4. Описание вариантов использования ................................................................................................................... 322
1.4.5. Отношения между вариантами использования ................................................................................................... 325
1.4.6. Тема UML варианта использования ......................................................................................................................326
1.4.7. Предмет бизнес-модели ........................................................................................................................................ 327
1.4.8. Отношения включения варианта использования ................................................................................................ 329
1.4.8.1 Понятие отношения включения варианта использования ......................................................................... 329
1.4.8.2 Сравнение взаимосвязей вариантов использования.................................................................................. 333
1.4.8.3 Отсутствие связи варианта использования ................................................................................................... 334
1.4.9. Расширение варианта использования UML......................................................................................................... 335
1.4.9.1 Понятие расширения варианта использования UML .................................................................................. 335
1.4.9.2 Точка расширения............................................................................................................................................ 337
2. UML ДИАГРАММЫ ИНФОРМАЦИОННЫХ ПОТОКОВ ......................................................................339
2.1. Понятие и схема UML Диаграммы информационных потоков ........................................................... 339
2.2. Элементы информационного потока ...................................................................................................... 340
2.2.1. Понятие информационного потока .......................................................................................................................340
2.2.2. Информационный элемент .................................................................................................................................... 341
2.3. UML-классификатор.................................................................................................................................... 342
2.3.1. Понятие UML-классификатора.............................................................................................................................342
2.3.2. Абстрактный классификатор ................................................................................................................................. 345
2.3.3. Окончательный классификатор ............................................................................................................................. 346
2.3.4. Тип .............................................................................................................................................................................346
2.3.5. Шаблонный элемент............................................................................................................................................... 347
2.3.5.1 Понятие шаблонный элемент ......................................................................................................................... 347
2.3.5.2 Подпись шаблона..............................................................................................................................................349
2.3.5.3 Параметр шаблона........................................................................................................................................... 349
2.3.5.4 Привязка шаблона ........................................................................................................................................... 350
2.3.6. Переопределяемый элемент................................................................................................................................... 351
2.3.7. Пространство имен ..................................................................................................................................................352
3. UML ДИАГРАММА ДЕЯТЕЛЬНОСТИ ....................................................................................................... 356
3.1. Понятие и схема UML Диаграммы Деятельности ................................................................................. 356
3.2. Активность ................................................................................................................................................... 357
3.2.1. Понятие активности ................................................................................................................................................357
3.2.2. Раздел активности .................................................................................................................................................... 359
3.2.3. Край активности ...................................................................................................................................................... 363
3.2.4. Край потока объекта............................................................................................................................................... 365
3.2.5. Прерывание края...................................................................................................................................................... 366
3.3. Действия ........................................................................................................................................................ 366
3.3.1. Понятие действия .................................................................................................................................................... 366
3.3.2. Действие объекта..................................................................................................................................................... 369
3.3.3. Переменное действие ..............................................................................................................................................370
3.3.4. Действие вызова ...................................................................................................................................................... 370
3.3.5. Действия при вызове ...............................................................................................................................................371
3.3.6. Действие «Отправить сигнал» ...............................................................................................................................373
3.3.7. Структурное действие .............................................................................................................................................374
3.3.8. Действие ссылки ...................................................................................................................................................... 375
3.3.9. Действие события .................................................................................................................................................... 376
3.3.10. Принять действие события .................................................................................................................................. 377
3.3.11. Принять действие сигнала ................................................................................................................................... 379
3.3.12. Действие времени ожидания .............................................................................................................................. 379
3.4. Узлы объектов ............................................................................................................................................... 380
3.4.1. Понятие узла объекта ..............................................................................................................................................380
3.4.2. Узел объекта, как абстрактный узел действия .................................................................................................... 380
3.4.3. Пины ......................................................................................................................................................................... 381
6
3.4.4. Центральный буфер ................................................................................................................................................ 382
3.4.5. Хранилище данных................................................................................................................................................. 382
3.5. Элементы управления диаграммой активности UML ......................................................................... 383
3.5.1. Понятие узла управления ....................................................................................................................................... 383
3.5.2. Начальный узел........................................................................................................................................................ 384
3.5.3. Конечный узел потока ............................................................................................................................................ 384
3.5.4. Конечный узел действия ........................................................................................................................................ 385
3.5.5. Узел решения ........................................................................................................................................................... 385
3.5.6. Узел слияния ............................................................................................................................................................ 388
3.5.7. Узел разветвления....................................................................................................................................................389
3.5.8. Узел соединения ...................................................................................................................................................... 391
3.6. Ребро действия ............................................................................................................................................. 392
3.6.1. Понятие ребра действия ......................................................................................................................................... 392
3.6.2. Край потока объекта ................................................................................................................................................394
3.6.3. Прерывание ребра................................................................................................................................................... 395
4. UML ДИАГРАММА СОСТОЯНИЙ .............................................................................................................. 396
4.1. Понятие и схема UML диаграммы состояний ......................................................................................... 396
4.2. Начальное состояние (Start state) .............................................................................................................. 397
4.3. Конечное состояние (Final state)................................................................................................................. 397
4.4. Состояние (State)........................................................................................................................................... 398
4.5. Составное состояние (Composite state).................................................................................................... 399
4.6. Защитное условие (Guard Condition) ..........................................................................................................400
4.7. Разделитель (Concurrent state) ................................................................................................................... 400
4.8. Историческое состояние (Historical State) ............................................................................................... 401
4.9. Глубокое историческое состояние (Deep Historical State) ..................................................................... 402
4.10. Переход (Transition)...................................................................................................................................... 402
5. UML ДИАГРАММЫ КОНЕЧНОГО АВТОМАТА .................................................................................... 404
5.1. Понятие и схема UML диаграммы конечного автомата ..................................................................... 404
5.2. Поведенческий конечный автомат ...........................................................................................................404
5.2.1. Понятие поведенческого конечного автомата..................................................................................................... 404
5.2.2. Вершина ................................................................................................................................................................... 406
5.2.3. Поведенческое состояние ...................................................................................................................................... 406
5.2.4. Область ..................................................................................................................................................................... 412
5.2.5. Псевдосостояние..................................................................................................................................................... 413
5.2.6. Конечное состояние................................................................................................................................................ 420
4.2.7. Поведенческий переход ......................................................................................................................................... 421
5.3. UML диаграмма конечного автомата протокола ................................................................................ 423
5.4. Машина состояния протокола .................................................................................................................. 424
5.5. Состояние протокола ..................................................................................................................................425
5.6. Переход протокола ....................................................................................................................................... 426
5.7. Триггер .............................................................................................................................................................428
6. UML ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ................................................................................................ 429
6.1. UML диаграмма последовательности..................................................................................................... 429
6.1.1. Понятие UML диаграммы последовательности .................................................................................................. 429
5.1.2. Линия жизни ............................................................................................................................................................ 430
5.1.3. Шлюз ........................................................................................................................................................................ 432
5.1.4. Фрагмент взаимодействия ..................................................................................................................................... 433
5.1.5. Возникновение ......................................................................................................................................................... 433
5.1.6. Исполнение .............................................................................................................................................................. 436
5.1.7. Инвариант состояния.............................................................................................................................................. 439
5.1.8. Использование взаимодействия ............................................................................................................................ 440
5.1.9. UML-сообщение......................................................................................................................................................442
5.1.9.1 Понятие UML-сообщения................................................................................................................................ 442
5.1.9.2 Сообщения по типу действия ..........................................................................................................................443
5.1.9.3 Сообщения о наличии событий ..................................................................................................................... 446
5.1.10. Комбинированный фрагмент .............................................................................................................................. 448
5.1.10.1 Понятие комбинированного фрагмента ..................................................................................................... 448
5.1.10.2 Ограничение взаимодействия ..................................................................................................................... 449
7
5.1.10.3 Альтернативы ................................................................................................................................................. 449
5.1.10.4 Вариант ............................................................................................................................................................450
5.1.10.5 Цикл.................................................................................................................................................................. 450
5.1.10.6 Перерыв .......................................................................................................................................................... 453
5.1.10.7 Параллельно....................................................................................................................................................454
5.1.10.8 Строгая последовательность.........................................................................................................................455
5.1.10.9 Слабое секвенирование ................................................................................................................................456
5.1.10.10 Критическая область.................................................................................................................................... 457
5.1.10.11 Игнорировать ............................................................................................................................................... 458
5.1.10.12 Учитывать.......................................................................................................................................................458
5.1.10.13 Утверждение ................................................................................................................................................ 459
5.1.10.14 Отрицательный ............................................................................................................................................ 459
6.2.
UML диаграмма связи ............................................................................................................................. 460
6.2.1. Понятие и схема UML диаграммы связи ............................................................................................................. 460
6.2.2. Рамка......................................................................................................................................................................... 461
6.2.3. Линия жизни ............................................................................................................................................................ 462
6.2.4. Сообщение................................................................................................................................................................ 464
6.3.
Временная UML диаграмма................................................................................................................... 467
6.3.1. Понятие и схема временной UML диаграммы .................................................................................................... 467
6.3.2. Линия жизни ............................................................................................................................................................ 468
6.3.3. Хронология состояния ........................................................................................................................................... 469
6.3.4. Ограничение продолжительности .........................................................................................................................470
6.3.5. Ограничение времени............................................................................................................................................. 470
6.3.6. Разрушение...............................................................................................................................................................471
6.4.
UML диаграмма обзора взаимодействия............................................................................................ 472
6.4.1. Понятие и схема UML диаграммы обзора взаимодействия .............................................................................. 472
6.4.2. Рамка......................................................................................................................................................................... 473
6.4.3. Элементы диаграммы обзора взаимодействия .................................................................................................... 474
6.4.4. Элементы диаграммы обзора взаимодействия .................................................................................................... 475
РАЗДЕЛ IV ПРИМЕРЫ UML ДИАГРАММ ....................................................................................................... 477
1. ПРИМЕРЫ UML ДИАГРАММЫ КЛАССОВ.............................................................................................. 478
1.1. Полис медицинского страхования ............................................................................................................ 478
1.2. Абстрактная фабричная конструкция.................................................................................................... 481
1.3. Модель предметной области библиотеки ............................................................................................ 482
1.4. Модель домена онлайн-покупок ................................................................................................................ 484
1.5. Банковский счет ............................................................................................................................................486
1.6. Модель домена для больницы ....................................................................................................................488
1.7. Цифровая визуализация в медицине — DICOM-модель реального мира........................................... 492
1.8. API хостинга приложений DICOM .............................................................................................................. 495
1.9. Домен лицензирования программного обеспечения Sentinel HASP ...................................................... 498
1.10. Java.util.concurrent ......................................................................................................................................501
1.11. Классы реализации камеры Android ........................................................................................................ 504
1.12. Лицензирование Sentinel HASP пакета Aladdin ..................................................................................... 506
2. ПРИМЕРЫ UML ДИАГРАММЫ ОБЪЕКТОВ............................................................................................509
2.1. Схема объекта контроллера входа в веб-приложение ........................................................................ 509
3. ПРИМЕРЫ UML ДИАГРАММЫ ИНФОРМАЦИОННЫХ ПОТОКОВ............................................... 511
3.1. Поток информации о запланированном рабочем процессе для Технической основы радиологии
IHE ............................................................................................................................................................................ 511
4. ПРИМЕРЫ UML ДИАГРАММЫ МОДЕЛИ................................................................................................ 514
4.1. Многоуровневое приложение на основе Руководства по архитектуре приложений Microsoft, 2-е
изд........................................................................................................................................................................... 514
5. ПРИМЕРЫ UML ДИАГРАММЫ РАЗВЕРТЫВАНИЯ............................................................................. 517
5.1. UML диаграмма проявления компонентов артефактами для веб-приложения ............................ 517
5.2. Пример схемы развертывания UML для веб-приложения .................................................................... 518
5.3. Сбалансированное по нагрузке и кластерное развертывание веб-приложения J2EE ................... 519
5.4. Балансировка нагрузки веб-серверов J2EE ................................................................................................520
5.5. Схема развертывания Apple iTunes UML ................................................................................................. 522
8
5.6. Развертывание Android-приложения....................................................................................................... 523
5.7. Пример сетевой Диаграммы Домашней сети....................................................................................... 525
5.8. Пример сетевой диаграммы веб-приложения ....................................................................................... 527
6. ПРИМЕРЫ UML ДИАГРАММЫ ПРОФИЛЯ............................................................................................ 530
6.1. Примеры схем профиля UML на языке моДелирования сервис-ориентированной архитектуры
(SoaML)....................................................................................................................................................................530
6.2. Корпоративный JavaBeans™ EJB 3.0 .......................................................................................................... 533
6.3. Цифровая визуализация и коммуникации в меДицине (DICOM) ........................................................... 535
7. ПРИМЕРЫ UML ДИАГРАММЫ СВЯЗИ.....................................................................................................539
7.1. Диаграмма коммуникации книжного интернет-магазина ................................................................. 539
8. ПРИМЕРЫ UML ДИАГРАММ ПАКЕТОВ.................................................................................................. 541
8.1. Многоуровневая веб-архитектура ........................................................................................................... 541
8.2. API Java™ Servlet 2.5 ...................................................................................................................................... 542
8.3. API-интерфейс Java™ Servlet 3.0................................................................................................................ 544
8.4. Классы Spring и Hibernate ............................................................................................................................. 546
8.5. Многоуровневое приложение .................................................................................................................... 547
8.6. Платформа Java™ Standard Edition 7 API .................................................................................................. 549
8.7. Объект переДачи Данных ............................................................................................................................ 551
9. UML ДИАГРАММЫ КОМПОНЕНТОВ....................................................................................................... 554
9.1. Пример UML Диаграммы компонентов. Покупки в интернет-магазине .......................................... 554
9.2. Пример UML Диаграммы компонентов. Компоненты лицензирования Sentinel HASP .................. 555
9.3. Шаблон проектирования Observer как пример использования совместной работы UML ............ 558
10. СОСТАВНЫЕ СТРУКТУРНЫЕ UML ДИАГРАММЫ .........................................................................561
10.1. Пример Диаграммы составной структуры UML банкомата в банке ..............................................561
10.2. Пример Диаграммы составной структуры UML. Сервер Apache Tomcat 7..................................... 563
10.3. Пример UML Диаграммы совместного использования. Шаблон проектирования наблюДателя
566
11. UML ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ................................................................... 568
11.1. UML Диаграммы обзора взаимоДействия ............................................................................................. 568
11.1.1. Бизнесс модель ресторна...................................................................................................................................... 568
11.1.2. Регистрация в аэропорту и проверка безопасности ..........................................................................................570
11.2. UML Диаграммы вариантов использования системы .........................................................................571
11.2.1. Автомат по продаже билетов .............................................................................................................................. 571
11.2.2. Диаграмма вариантов использования UML банкомата ...................................................................................573
11.2.3. Каталог общедоступной онлайн-библиотеки ................................................................................................... 576
11.2.4. Диаграммы вариантов использования онлайн-покупок ..................................................................................577
11.2.5. Система обработки кредитных карт................................................................................................................... 580
11.2.6. Администрирование сайта .................................................................................................................................. 583
11.2.7. Пример диаграммы вариантов использования UML для отчетов о рентгенологической диагностике .... 588
11.2.8. Управление больницей ......................................................................................................................................... 592
11.2.9. Защита программного обеспечения и лицензирование ...................................................................................593
12. UML ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ .................................................................................................... 596
12.1. Покупки в интернет-магазине ................................................................................................................ 596
12.2. Обработка заказа на покупку.................................................................................................................. 596
12.3. Процесс управления Документами ......................................................................................................... 597
12.4. Решение проблемы с программным обеспечением .............................................................................. 598
12.5. Sentinel HASP SL — Активация пробного проДукта .............................................................................. 599
12.6. ЕДиный вхоД Для Google Apps................................................................................................................... 602
12.7. Электронный рецептурный сервис ........................................................................................................ 604
12.8. Автомат по проДаже билетов ................................................................................................................608
13. UML ДИАГРАММЫ КОНЕЧНОГО АВТОМАТА ................................................................................. 611
13.1. ВоДные фазы ................................................................................................................................................ 611
13.2. Банкомат ..................................................................................................................................................... 611
13.3. Состояния потоков Java и жизненный цикл ..........................................................................................613
13.4. Java EJB — жизненный цикл объекта сеанса .........................................................................................616
13.5. Интернет-магазин - учетная запись пользователя.......................................................................... 617
9
13.6. Жизненный цикл размещенного приложения DICOM Application Hosting API .................................. 619
14. UML ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ .................................................................................. 623
14.1. Книжный интернет-магазин .................................................................................................................. 623
14.2. Отправление комментариев в Pluck ...................................................................................................... 624
14.3. Веб-аутентификация пользователей Facebook .................................................................................. 625
14.4. Управление транзакциями Spring и Hibernate....................................................................................... 627
15. ВРЕМЕННАЯ UML ДИАГРАММА............................................................................................................. 630
15.1. Временная шкала стадий болезни Альцгеймера ................................................................................. 630
15.2. Задержка веб-сайта .................................................................................................................................. 632
15.3. Система доступа банковского терминала .......................................................................................... 634
16. UML ДИАГРАММА ОБЗОРА ВЗАИМОДЕЙСТВИЯ ............................................................................. 637
16.1. Пример диаграммы обзора взаимодействия онлайн-покупок .......................................................... 637
16.2. Отправление комментариев в Pluck, используя DWR, AJAX, JSON .................................................... 638
17. UML ДИАГРАММА СОСТОЯНИЙ ............................................................................................................ 640
17.1. Учебный курс ................................................................................................................................................ 640
17.2. Счет системы банковского автомата.................................................................................................. 640
17.3. Телефон ........................................................................................................................................................ 641
17.4. Заказ.............................................................................................................................................................. 642
18. UML ДИАГРАММА АРТЕФАКТОВ ........................................................................................................... 643
18.1. Физическая база данных ............................................................................................................................ 643
18.2. Адаптируемая система ............................................................................................................................ 645
18.3. Прямое и обратное проектирование ..................................................................................................... 647
РАЗДЕЛ V КРАТКИЙ СПРАВОЧНИК UML ...................................................................................................... 651
Что такое UML-диаграмма?....................................................................................................................................................................................652
ЧТО ПОДРАЗУМЕВАЕТСЯ ПОД UML? ......................................................................................................................... 652
ТИПЫ ДИАГРАмм UML .............................................................................................................................................. 653
СИмВОЛЫ ДИАГРАммЫ UML ................................................................................................................................... 654
UML ДИАГРАммА КЛАССОВ .......................................................................................................................................................................................................................................... 656
UML ДИАГРАммА ПАКЕТОВ .......................................................................................................................................................................................................................................... 657
UML ДИАГРАммА ОБЪЕКТОВ........................................................................................................................................................................................................................................ 659
UML ДИАГРАммА мОДЕЛИ............................................................................................................................................................................................................................................. 659
ДИАГРАммА КОмПОЗИТНОЙ СОСТАВНОЙ СТРУКТУРЫ ................................................................................................................................................................. 660
ДИАГРАммА ВНУТРЕННЕЙ СТРУКТУРЫ............................................................................................................................................................................................................ 661
ДИАГРАммА КООПЕРАЦИИ................................................................................................................................................................................................................................................662
ДИАГРАммА КОмПОНЕНТОВ .......................................................................................................................................................................................................................................... 663
ДИАГРАммА ПРОЯВЛЕНИЯ ............................................................................................................................................................................................................................................... 664
ДИАГРАммА РАЗВЕРТЫВАНИЯ .....................................................................................................................................................................................................................................665
ДИАГРАммА СЕТЕВОЙ АРХИТЕКТУРЫ................................................................................................................................................................................................................ 666
ДИАГРАммА АРТЕФАКТОВ ................................................................................................................................................................................................................................................666
ДИАГРАммА ПРОФИЛЕЙ ....................................................................................................................................................................................................................................................... 667
UML ДИАГРАммА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ..............................................................................................................................................................................668
UML ДИАГРАммА ПОТОКА ИНФОРмАЦИИ .................................................................................................................................................................................................. 669
UML ДИАГРАммА ДЕЙСТВИЙ ...................................................................................................................................................................................................................................... 670
ДИАГРАммА СОСТОЯНИЙ...................................................................................................................................................................................................................................................671
ДИАГРАммА ПОВЕДЕНИЯ КОНЕЧНОГО АВТОмАТА ............................................................................................................................................................................ 671
ДИАГРАммА КОНЕЧНОГО АВТОмАТА ПРОТОКОЛА ............................................................................................................................................................................ 672
ОБЗОРНАЯ ДИАГРАммА ВЗАИмОДЕЙСТВИЯ................................................................................................................................................................................................673
UML ДИАГРАммА ПОСЛЕДОВАТЕЛЬНОСТИ ................................................................................................................................................................................................ 674
ДИАГРАммА СВЯЗИ ....................................................................................................................................................................................................................................................................675
ВРЕмЕННАЯ ДИАГРАммА ................................................................................................................................................................................................................................................... 676
ДИАГРАммА ОБЗОРА ВЗАИмОДЕЙСТВИЙ ....................................................................................................................................................................................................... 677
БИБЛИОГРАФИЧЕСКИЙ СПИСОК .................................................................................................................. 679
10
ВВЕДЕНИЕ
UML расшифровывается как Unified Modified Language — это язык
моделирования общего назначения, который используется в области
разработки программного обеспечения. Он имеет целый ряд методов
графической записи, которые используются для создания визуальных
моделей объектно-ориентированных программных систем. UML будет
использовать
методы,
включающие
моделирование
данных,
бизнес-
моделирование, компонентное моделирование и объектное моделирование.
Этот процесс можно использовать на протяжении всего жизненного цикла
разработки программного обеспечения и для реализации различных
технологий.
В UML можно проектировать десять различных типов диаграмм. К ним
относятся
варианты
использования,
последовательность,
активность,
развертывание, совместная работа, диаграмма отношений сущностей и связь.
Каждая диаграмма служит определенной цели и позволяет бизнесаналитикам разрабатывать различные и более совершенные программные
решения.
Сегодня,
это
стало
ключевым
предметом
в
разработке
программного обеспечения для моделирования структур, связанных с
приложением, бизнес-процессами и поведением. Это помогает пользователю
легко узнать о процессе разработки и проектирования, затрагивая много
важных областей, таких как проектирование процесса оформления заказа на
сайте электронной коммерции, проектирование базы данных, подключенной
к
различным
таблицам,
проблем,
решение
связанных
с
дизайном,
использование диаграмм случаев, моделирование процессов и разработка
алгоритмов.
Данное учебное пособие предлагает наилучшую помощь, в которой
нуждается каждый пользователь и поможет вам получить хорошие знания
концепций UML.
11
КАК РАБОТАТЬ С КНИГОЙ
Тем, кто только начинает осваивать UML, лучше изучать страницы
книги последовательно. Особое внимание стоит уделять каждой главе, в
которой подробно излагается концептуальная модель языка и каждой UML
диаграммы.
Каждую главу книги авторы постарались сделать последовательной, но
в тоже время отдельной, чтобы в случае необходимости, опытный
разработчик,
желающий
найти
решение
конкретных
проблем
при
моделировании, мог изучить данное руководство, не прибегая к прочтению
всей книги целиком.
Советуем обратить внимание на основные элементы UML в каждой
главе.
12
РАЗДЕЛ I
ВВЕДЕНИЕ В UML
13
1. ОСНОВНЫЕ ОБЛАСТИ ИСПОЛЬЗОВАНИЯ
И ПОНЯТИЯ UML ДИАГРАММ
https://t.me/it_boooks/2
1.1. Понятие UML диаграмм
Unified Modeling Language (UML) — это семейство графических
нотаций или по-другому стандартный язык визуального моделирования,
предназначенный для:
•
моделирования бизнес и подобных процессов,
•
анализа, проектирования и внедрения программных систем
UML — это общий язык для бизнес-аналитиков, архитекторов
программного обеспечения и разработчиков, используемый для описания,
спецификаций, проектирования и документирования существующих или
новых бизнес-процессов, структуры и поведения артефактов программных
систем.
UML можно применять в различных областях приложений (например,
в
банковском деле,
финансах,
Интернете,
аэрокосмической отрасли,
здравоохранении и т.д.). Его можно использовать со всеми основными
методами разработки объектного
и компонентного программного
обеспечения и для различных платформ реализации (например, J2EE,
.NET).
UML — это стандартный язык моделирования, а не процесс
разработки программного обеспечения. Спецификация UML объяснила
этот процесс:
•
обеспечивает руководство относительно порядка действий команды;
•
указывает, какие артефакты должны быть разработаны;
•
направляет задачи отдельных разработчиков и команды в целом;
•
предлагает критерии для мониторинга и измерения продуктов и
деятельности проекта.
UML намеренно независим от процессов и может применяться в
контексте различных процессов. Тем не менее, он больше всего подходит для
итеративных и инкрементных процессов разработки,
14
основанных на
прецедентах. Примером такого процесса является Rational Unified Process
(RUP).
Язык UML в своем нынешнем состоянии определяет нотацию и
метамодель. Нотация
представляет собой совокупность графических
элементов, которые применяются в моделях; она и есть синтаксис данного
языка моделирования. Например, нотация диаграммы классов определяет
способ представления таких элементов и понятий, как класс, ассоциация и
кратность.
UML не является полным и полностью визуальным. Учитывая
некоторые диаграммы UML, мы не можем быть уверены, что поймем
изображенную часть или поведение системы только по диаграмме.
Некоторая информация может быть намеренно опущена на диаграмме,
некоторая информация,
представленная
на диаграмме,
может иметь
различную интерпретацию, а некоторые понятия UML вообще не имеют
графической записи, поэтому их невозможно отобразить на диаграммах.
Например,
множества
семантика
вариантов
множественности
использования
на
действующих
диаграммах
лиц
и
вариантов
использования не определена точно в спецификации UML и может означать
одновременное
или
последовательное
использование
вариантов
использования.
1.2. Программные инструменты UML
UML диаграммы очень важны в области разработки программного
обеспечения. Это позволяет визуализировать и анализировать системы.
Клиентам легче объяснить, используя UML диаграммы. В программной
инженерии диаграммы UML используются для визуализации проекта до его
завершения и для документирования проекта после его завершения. Важно
понимать и знать, что с помощью этих диаграмм часто экономится много
времени.
15
Моделирование на UML происходит при помощи программного
обеспечения. Сегодня доступно множество инструментов для разработки
UML-диаграмм, где выбор инструмента моделирования очень важен. Ниже
приводится список отобранных инструментов UML с
популярными
функциями.
Draw.io: бесплатное кроссплатформенное программное обеспечение
для построения графиков с открытым исходным кодом, разработанное на
HTML5
и JavaScript. Он содержит предопределенные шаблоны для
построения любых диаграмм UML, создания каркасов, бизнес-диаграмм и
т.д. Он доступен как в виде программного обеспечения, так и в виде онлайнинструмента и связан с Google Диском, поэтому автоматически сохраняет
вашу работу. Поддерживает формат файлов PNG, JPEG, SVG, PDF и т.д.
Используется
многими
предприятиями,
поддерживает
корпоративные
браузеры. Имеет удобный интерфейс для начинающих и, несмотря на это, он
в основном используется для профессиональных диаграмм. Не содержит
никаких платных сервисов. Поддерживается в таких браузерах, как Chrome,
Microsoft Edge и Mozilla Firefox. ОС, поддерживаемые этим инструментом -
Windows, Linux и macOS.
На рисунке 1 продемонстрированы графический пользовательский
интерфейс программы Draw.io. На данный момент это один из самых
известных сервисов для создания UML-диаграмм.
Его популярность
обусловлена двумя основными фактерами: простота использования и
обширный функционал.
16
Рисунок 1 - Графический пользовательский интерфейс сервиса Draw.io
Помимо широкого функционала программы для построения диаграмм,
так же имеется большое количество шаблонов, значительно упрощающих
работы с UML.
Особенности данного программного обеспечения:
• есть как платная, так и бесплатная версия
• наличие собственных видеоуроков и руководств, с возможностью
индивидуальных сессий
• интуитивно понятное построение диаграмм
• возможность создания как блок-схем, диаграмм UML, так и
Canban досок
• кроссплатформенность
• все необходимые функции доступны в бесплатной версии
Dia Diagram: это программное обеспечение для построения диаграмм с
открытым исходным кодом, которое упрощает работу с различными типами
диаграмм, такими как сетевые диаграммы, блок-схемы и модели баз данных.
17
Он используется несколькими разработчиками программного обеспечения и
специалистами по базам данных, которые помогают создавать код из
профессиональных диаграмм.
MagicDraw:
это
программное
обеспечение
для
визуального
моделирования UML, которое помогает анализировать и проектировать базу
данных и является объектно-ориентированным. Это позволяет пользователям
легко развертывать жизненный цикл разработки программного обеспечения,
который лучше всего подходит для их бизнеса.
AgroUML: это программный инструмент с открытым исходным кодом,
который поддерживает все типы диаграмм UML. Он в основном работает на
платформе Java и доступен на десяти языках.
UMLet: этот бесплатный инструмент UMLet с открытыми ресурсами
помогает пользователю создавать диаграммы UML с пользовательским
интерфейсом без всплывающих окон. Это также помогает экспортировать
диаграммы в такие форматы, как pdf, eps, GIF, BMP, SVG, JPEG и т.д.
Umbrella UML Modeler: этот программный инструмент поддерживает
всю процедуру разработки программного обеспечения, особенно анализ и
проектирование программного обеспечения. Таким образом,
моделирования
UML
Umbrella
позволяет
пользователю
средство
создавать
высококачественный продукт.
Star UML: это программный инструмент с открытым исходным кодом,
обладающий множеством эффективных функций, который позволяет вам
рисовать различные типы диаграмм UML и позволяет пользователям
создавать коды на разных языках (рис. 2).
18
Рисунок 2 - Графический пользовательский интерфейс сервиса StarUML
Одним из основных преимуществ StarUML является его богатый
инструментарий для моделирования (большой и доступный набор шаблонов
UML-диаграмм и возможность создания собственных шаблонов). Кроме
того,
StarUML
поддержку
обеспечивает
различных
языков
программирования, включая C++, Java, PHP, Ruby, JavaScript и Python.
Однако, стоимость StarUML является одним из главных его недостатков. Тем
не менее, StarUML один из наиболее популярных инструментов для создания
UML-диаграмм
и
визуального
проектирования
программных систем.
Стоимость лицензии на момент написания книги варьируется от 99 до 125
долларов.
Lucidchart: это инструмент, с помощью которого пользователи
создают диаграммы (рис. 3). Визуально очень схож с draw.io. Предоставляет
платформу для совместной работы для проектирования диаграмм. Это
онлайн-инструмент и платный сервис. Его можно использовать с помощью
единой регистрации. Он удобен для пользователя. Содержит все формы для
моделирования любых диаграмм UML. Также предоставляет базовые
шаблоны для всех диаграмм. Очень полезен для визуализации данных.
Имеется бесплатная пробная версия, но доступно всего несколько фреймов и
19
фигур, а также в бесплатной версии программы доступны работы только с 3
документами. Не поддерживает корпоративные версии браузера.
Blank diagram ЙО» Draft ▼
О File
Ъ
ф
Edit
Select
View
Insert
Arrange
Hr1 I’ Body________ Liberation Sans
Try paid features with a free trial!
Share
О Saved
Help •
▼][-|lOpt|+] В
I
У
А=Т’{+}^^®Й X СЕ—Tl
1 Рх » l -Г
Containers
▼ Flowchart
В ■=□<>□
оо| к jzz
о□
’ UML State/Activity
□ □ 0 ffl Е
В
Smart Containers
CD CD CD
CD CD
CD
"3 Import Data
Рисунок 3 - Графический пользовательский интерфейс сервиса
Lucidchart
Особенности данного программного обеспечения:
• имеет удобный для пользователя интерфейс;
• имеет материалы для обучения;
• бесплатная версия имеет огромное количество ограничений, как с
количеством редактируемых файлов, так и с импортом и
экспортом
В инструменте Lucidchart доступны следующие варианты подписок (со
временем данные о стоимости могли измениться):
1. Бесплатный: для редактирования доступны только три документа,
максимум 60 фигур на один документ, 100 шаблонов.
2. Индивидуальный: 8$, документы без ограничений, количество
объектов не ограничено, импорт и экспорт из Microsoft Visio,
премиум библиотеки фигур.
20
3. Команда: 9$ за пользователя, возможность комментирования,
публикация защищена паролем, контроль версий, интеграция с
Confluence, Jira, Microsoft 365.
Рекомендация по использованию программ от авторов книги:
Какой инструмент использовать - вы выбираете сами, но авторы
рекомендуют бесплатное ПО - draw.io, которое и было использовано при
создании UML диаграмм в данной книге.
1.3. Различные типы UML диаграмм
Диаграмма UML является наиболее важным аспектом разработки
программного обеспечения, который требует специальной помощи. Задания
и проекты на диаграмме UML носят сугубо технический характер. Эти
задания требуют большой исследовательской работы и глубоких знаний
различных принципов диаграмм UML.
Диаграммы UML делятся на две разные группы: структурные
диаграммы UML и поведенческие диаграммы UML.
Виды структурных диаграмм UML:
• Диаграмма классов
• Диаграмма пакетов
• Диаграмма объектов
• Диаграмма компонентов
• Диаграмма развертывания
• Диаграмма композитной составной структуры
• Диаграмма профилей
Диаграмма классов: это статическая диаграмма, которая определяет
поведение класса, а также ограничения, применяемые в системе. Это не
только помогает объяснить элемент системы, но также помогает в создании
исполняемого кода программного приложения.
Диаграмма пакетов: это популярная диаграмма UML, которая
демонстрирует структуру разработанной системы на различных уровнях
21
пакетов. Он также состоит из нескольких важных элементов, таких как
элементы пакета, импорт элемента, импорт пакета, пакет, слияние пакетов и
т.д.
Диаграмма объектов: диаграмма объектов обычно получается из
диаграммы
классов,
которая
помогает
представить
статическое
представление системы. Основная цель диаграммы объектов - понять
поведение объектов и их взаимосвязь друг с другом.
Диаграмма компонентов: эта диаграмма сильно отличается от других
структурных диаграмм с точки зрения характера и функций. Он используется
для отображения физического аспекта системы и включает в себя такие
элементы, как файлы, документы, библиотеки, исполняемые файлы и т. д.
Диаграмма развертывания: Диаграмма развертывания используется
для представления и описания физических элементов системы. Для
получения дополнительной информации о типах структурных диаграмм
UML обратитесь к нашим специалистам по назначению диаграмм UML.
Диаграмма
композитной
составной
структуры:
статическая
структурная диаграмма, демонстрирует внутреннюю структуру классов и, по
возможности, взаимодействие элементов (частей) внутренней структуры
класса. Подвидом диаграмм композитной структуры является диаграмма
кооперации (Collaboration Use Diagram, введена в UML 2.0), которая
показывает
роли
и
взаимодействие
классов
в
рамках
кооперации.
Кооперации удобны при моделировании шаблонов проектирования. Ещё
одним подвидом диаграмм композитной структуры является диаграмма
внутренней структуры (Internal Structure Diagram), которая используется
для более подробного представления структурных классификаторов, прежде
всего классов и компонентов.
Диаграмма профилей: это структурная диаграмма, которая описывает
упрощенный
механизм
расширения
UML
путем
определения
пользовательских стереотипов, значений тегов и ограничений. Профили
22
позволяют адаптировать метамодель UML для различных платформ и
доменов.
Виды поведенческих диаграмм UML:
• Диаграмма варианта использования/прецедентов
• Диаграмма деятельности
• Диаграмма состояний
• Диаграмма последовательности
• Диаграмма коммуникации
• Временная диаграмма
• Диаграмма обзора взаимодействий
Диаграмма варианта использования/прецедентов: используется для
сбора требований, в основном потребностей проектирования системы,
включая внутренние и внешние воздействия. Когда система собирает свои
функциональные возможности, подготавливается вариант использования.
Диаграмма деятельности: это самая важная поведенческая диаграмма
UML, которая используется для определения динамического элемента
системы. Это операция системы, означающая переход от одной деятельности
к другой.
Диаграмма состояний: это одна из поведенческих диаграмм UML,
которая символизирует поток управления из одного состояния в другое.
Кроме того, она используется для прямого и обратного проектирования
системы.
Диаграмма последовательности:
относится
к
типу
диаграмм
это
поведенческая диаграмма,
взаимодействия,
в
которых
подробно
описывается, как выполняются операции. Они фиксируют взаимодействие
между
объектами
в
контексте
сотрудничества.
Диаграммы
последовательности ориентированы на время и визуально показывают
порядок взаимодействия, используя вертикальную ось диаграммы для
представления времени, когда и какие сообщения отправляются. Т.е.
23
диаграмма последовательности показывает различные части работы системы
в “последовательности”, чтобы что-то сделать.
Диаграмма коммуникации/связи:
это поведенческая диаграмма
UML, которая объясняет взаимодействие между объектами.
Диаграмма
коммуникации — это расширение диаграммы объектов, которое показывает
объекты вместе с сообщениями, которые передаются от одного объекта к
другому. В дополнение к ассоциациям между объектами диаграмма
коммуникации показывает сообщения, которые объекты посылают друг
другу.
Временная диаграмма: это ещё одна поведенческая диаграмма UML,
относящаяся
к
типу
диаграмм
взаимодействия,
используется
для
отображения взаимодействий, когда основная цель — рассуждать о времени.
Временные
диаграммы
описывают
поведение
как
отдельных
классификаторов, так и взаимодействия классификаторов, акцентируя
внимание на времени возникновения событий, вызывающих изменения в
смоделированных условиях.
Диаграмма обзора взаимодействий: это комбинация диаграмм
деятельности и диаграмм последовательности. Можно считать диаграммы
обзора взаимодействия диаграммами деятельности, в которых деятельности
заменены небольшими диаграммами последовательности, или диаграммами
последовательности, разбитыми с помощью нотации диаграмм деятельности
для отображения потока управления.
1.4. Применение UML диаграмм
UML намеренно независим от процессов и может применяться в
контексте различных процессов. Тем не менее, он больше всего подходит для
итеративных и инкрементных процессов разработки,
основанных на
прецедентах. Примером такого процесса является Rational Unified Process
(RUP).
24
UML диаграммы применяется и могут использоваться в различных типах
технических областей:
• Розничные магазины, оборона, телекоммуникации активно используют
UML диаграммы.
• Финансовые услуги и банковский сектор используют UML диаграммы
для разработки своих услуг и процедур. Это увеличило спрос и
потребность в UML диаграммах на рынке.
• Для различных платформ реализации (например, J2EE, .NET).
1.5. Версии UML диаграмм
Текущая версия UML 2.5, выпущенная в июне 2015 г. Спецификация
UML (стандартная) обновляется и управляется Группой управления
объектами (OMG, Object Management Group). Первые версии UML были
созданы — Грэди Бучем (создателем метода Буча), Иваром Якобсоном
(объектно-ориентированная разработка программного обеспечения, OOSE) и
Джимом Рамбо (техника объектного моделирования). В таблице 1
представлены все версии UML диаграмм.
Таблица 1
Версии UML диаграмм
Версия
Дата выпуска
1.1
11-1997
Предложение UML 1.1 принято OMG.
1,3
03-2000
Содержит ряд изменений в метамодели UML, семантике и
Описание
нотации, но их следует рассматривать как незначительное
обновление исходного предложения.
1,4
09-2001
В основном «настраиваемый» выпуск, но не полностью
совместимый с UML 1.3. Добавление профилей в виде
расширений UML, сгруппированных вместе. Обновлена
видимость функций. Стрелка в виде палочки на диаграммах
взаимодействия теперь обозначает асинхронный вызов.
Элемент модели теперь может иметь несколько стереотипов.
Уточненные
коллаборации.
25
Уточненные
определения
компонентов и связанных с ними понятий. Артефакт был
добавлен
представления
для
представлений
физических
компонентов.
1,5
03-2003
Добавлены действия — исполняемые действия и процедуры,
включая их семантику во время выполнения, определено
понятие
потока
для
данных
переноса
данных
между
действиями и т. д.
1.4.2
01-2005
Эта версия была принята в качестве спецификации ISO
(стандарта) ISO/IEC 19501. UML 1.5 был выпущен двумя
годами ранее.
2.0
08-2005
Новые диаграммы: диаграммы объектов, диаграммы пакетов,
диаграммы
составной
взаимодействия,
структуры,
диаграммы
диаграммы,
временные
обзора
диаграммы
профилей. Диаграммы сотрудничества были переименованы
в диаграммы коммуникаций.
деятельности
Диаграммы
диаграммы
и
усовершенствованы.
последовательности были
Действия
были переработаны для использования семантики, подобной
Петри. Ребра теперь могут содержаться в разделах. Разделы
могут
быть
иерархическими
и
многомерными.
Явно
моделируемые потоки объектов являются новыми.
Классы были расширены за счет внутренних структур и
портов (составных структур). Добавлены информационные
потоки.
Сотрудничество
теперь
является
рода
своего
классификатором и может иметь любые связанные описания
поведения.
Взаимодействия
содержатся
теперь
в
классификаторах, а не только в сотрудничестве. Теперь
варианты
использования
принадлежать
могут
классификаторам в целом, а не только пакетам.
Новая
нотация
для
параллелизма
и
ветвления
с
использованием комбинированных фрагментов. Нотация и/или
семантика были обновлены для компонентов, реализации,
развертывания
артефактов.
26
Компоненты
больше
нельзя
развертывать непосредственно на узлах. Реализация была
заменена
«манифест».
на
Артефакты
теперь
могут
манифестировать любой пакетируемый элемент (а не только
компоненты, как раньше). Теперь возможно развертывание на
узлах с внутренней структурой.
Добавлены новые метаклассы: коннектор, использование
работы,
совместной
коннектора,
конец
устройство,
спецификация развертывания, среда выполнения, действие
принятия события, действие отправки объекта, действие
структурной функции, булавка значения, конечная активность,
центральный буферный узел, хранилища данных, конечный
поток, прерываемый регионы, узлы цикла, параметр, порт,
поведение, поведенческий классификатор, продолжительность,
интервал,
ограничение
по
времени,
комбинированный
фрагмент, событие создания, событие уничтожения, событие
выполнения,
фрагмент
взаимодействия,
взаимодействия,
событие
получения
использование
сигнала,
событие
отправки сигнала, расширение и т. д. .
Из стандартного профиля UML были исключены многие
стереотипы,
например,
«уничтожить»,
«фасад»,
«друг»,
«профиль», «требование», «таблица», «поток».
Улучшена интеграция между структурными и поведенческими
моделями благодаря лучшей поддержке исполняемых моделей.
2.1
04-2006
Незначительная редакция UML 2.0
—
исправления
и
незначительных
проблем
с
улучшения согласованности.
2.1.1
02-2007
Незначительная редакция UML 2.1.
2.1.2
11-2007
Незначительная редакция UML 2.1.1.
2.2
02-2009
Исправлено
множество
согласованностью и добавлены пояснения к UML 2.1.2.
27
2.3
05-2010
Незначительная доработка UML 2.2, уточнены ассоциации и
классы
ассоциаций,
добавлен
обновлены
классификатор,
окончательный
диаграммы
компонентов,
составные структуры, действия и т. д.
2.4.1
08-2011
Версия UML с несколькими исправлениями и обновлениями
для классов, пакетов — добавлен атрибут пакета URI;
обновленные действия; удалено событие создания, событие
события
выполнения,
события
отправки
уничтожения
и
получения
операций,
получения
сигналов,
событие
отправки
и
переименовано
спецификацию
в
возникновения разрушения; профили- изменены стереотипы
и применены стереотипы, чтобы первая буква была заглавной «Метакласс» и применение стереотипов.
2,5
06-2015
UML 2.5 называют «незначительной версией» UML 2.4.1, хотя
они потратили много усилий на упрощение и реорганизацию
документа спецификации UML. Спецификация UML была
переписана
«для
чтения».
облегчения
Например,
они
попытались «максимально сократить прямые ссылки».
Больше нет двух отдельных документов по инфраструктуре и
надстройке, спецификация UML 2.5 представляет собой
единый документ. Слияние пакетов больше не используется в
спецификации.
Четыре уровня соответствия UML (L0, L1, L2 и L3)
исключены, так как на практике они были бесполезны.
Инструменты UML 2.5 должны будут поддерживать полную
спецификацию UML. Информационные потоки, модели и
шаблоны
не
больше
UML.
конструкциями
являются
В
то
же
вспомогательными
время
варианты
использования, развертывания и информационные потоки
стали «дополнительными понятиями» в UML 2.5.
В UML 2.5 добавлен ряд исправлений, уточнений и пояснений.
Они обновили описание для множественности и элемента
множественности,
28
уточнили
определения
агрегации
и
композиции и, наконец исправили неправильный пример
«инстанцируемой» зависимости для автомобильного завода.
Была введена новая запись для унаследованных членов с
символом вставки «Л». В UML 2.5 уточнено переопределение
и
перегрузка
функций.
Они
также
переместили
и
перефразировали определения квалификаторов.
Значение по умолчанию для наборов обобщения было
изменено с {неполный, непересекающийся} на {неполный,
перекрывающийся}.
Есть несколько уточнений и исправлений для стереотипов,
конечных
автоматов
и
действий.
Конечные
автоматы
протокола теперь обозначаются с использованием «протокол»
вместо {протокол}. Прецеденты больше не требуются для
выражения некоторых потребностей актеров и инициирования
актером.
29
2. КЛАССИФИКАЦИЯ UML ДИАГРАММ
2.1. Таксономия UML диаграмм
UML диаграмма — это частичное графическое представление модели
системы,
в
стадии
разработки,
реализации
Диаграмма
UML
содержит
графические
находящейся
существующей.
или
уже
элементы
(символы) — узлы UML, соединенные ребрами (также известные как пути
или
—
потоки),
которые
представляют
элементы
модели
UML
проектируемой системы. UML-модель системы может также содержать
другую документацию, например, варианты использования, написанные в
виде шаблонных текстов.
Вид диаграммы определяется первичными графическими символами,
изображенными на диаграмме. Например, диаграмма, где основными
символами
диаграммой
области
содержимого
классов.
Диаграмма,
в
являются
которая
классы,
называется
показывает
варианты
использования и действующих лиц, называется диаграммой вариантов
использования.
Диаграмма
последовательности
показывает
последовательность обмена сообщениями между линиями жизни.
Спецификация UML не исключает смешивания различных видов
диаграмм, например, для объединения структурных и поведенческих
элементов для отображения конечного автомата, вложенного в прецедент.
Следовательно, границы между различными видами диаграмм строго не
соблюдаются. В то же время некоторые инструменты UML ограничивают
набор доступных графических элементов, которые можно использовать при
работе с диаграммами определенного типа.
Спецификация UML определяет два основных типа диаграмм UML:
диаграммы структуры и диаграммы поведения.
Структурные диаграммы
показывают
статическую структуру
системы и ее частей на разных уровнях абстракции и реализации и то, как
они связаны друг с другом. Элементы на структурной диаграмме
30
представляют значимые концепции системы и могут включать абстрактные
концепции, концепции реального мира и реализации.
Диаграммы
поведения
показывают
динамическое
поведение
объектов в системе, которое можно описать как серию изменений в системе с
течением времени.
UML диаграммы можно разделить на иерархические категории, как
показано ниже (рис. 2.1). Обратите внимание, элементы, показанные синим
цветом, не являются частью официальной таксономии диаграмм UML 2.5.
31
Рис. 2.1 Иерархические категории диаграмм UML 2.5.
32
2.2. Структурные UML диаграммы
Структурные диаграммы показывают статическую структуру
системы и ее частей на разных уровнях абстракции и реализации, а также то,
как эти части связаны друг с другом. Элементы на структурной диаграмме
представляют значимые концепции системы и могут включать абстрактные
концепции, концепции реального мира и реализации.
Структурные диаграммы не используют понятия, связанные со
временем, не показывают детали динамического поведения. Однако они
могут
демонстрировать
взаимосвязь
поведением классификаторов,
с
представленных на структурных диаграммах (табл. 2).
Таблица 2
Структурные UML диаграммы
Диаграмма
Цель
Диаграмма
Показывает структуру проектируемой системы, класс,
классов
подсистемы или компонента в виде связанных функция,
классов
Элементы
и
интерфейсов
с
интерфейс,
функциями, ограничение,
их
ограничениями и отношениями — ассоциациями, ассоциация,
обобщениями, зависимостями и т. д.
обобщение,
зависимость.
Диаграмма
Диаграмма класса уровня экземпляра, на которой спецификация
объектов
показаны экземплярные спецификации классов и экземпляра, объект,
интерфейсов
слоты
(объектов),
со слот, ссылка.
спецификациями значений и ссылки (экземпляры
ассоциации).
Диаграмма
объектов
была
определена
в
устаревшей спецификации UML 1.4.2 как «граф
экземпляров,
данных.
включая
Диаграмма
объекты
и
значения
статических
объектов
является экземпляром диаграммы классов; она
показывает моментальный снимок подробного
состояния системы в момент времени». В нем
также говорилось, что диаграмма объектов —
33
это «диаграмма классов с объектами и без
классов».
Спецификация
UML
просто не дает
2.5
определения диаграммы объектов.
Диаграмма
пакетов
Показывает
пакеты
и
отношения
между пакет,
(по пакетами.
пакетируемый
другому иногда
элемент,
«Схема
зависимость, импорт
упаковки»)
элемента,
импорт
пакета,
слияние
пакетов.
Схема модели
Диаграмма вспомогательной структуры UML, модель,
пакет,
которая показывает некоторую абстракцию или пакетируемый
конкретное представление системы для описания элемент,
архитектурных, логических или поведенческих зависимость.
аспектов системы. Это могло бы показать,
например, архитектуру многоуровневого (он же
multi-tiered)
приложения
см.
—
модель
многоуровневого приложения.
Схема
составной
На диаграмме можно показать:
•
структуры
Внутреннюю структуру
классификатора
•
Поведение сотрудничества\диаграмма
кооперации
внутреннюю
структуру структурированный
Схема
Показывает
внутренней
классификатора - разложение классификатора на класс, часть, порт,
структуры
его свойства, части и отношения.
разъем,
использование.
Диаграмма
кооперации
(иногда
Показывает
объекты
в
системе, сотрудничество,
взаимодействующие друг с другом для создания разъем,
по некоторого поведения системы.
другому
называют
34
зависимость.
часть,
«использования
совместной
работы»)
Диаграмма
Показывает компоненты и зависимости между компонент,
компонентов
ними. Этот тип диаграмм используется для интерфейс,
разработки на основе компонентов (CBD) для предоставляемый
описания систем с сервис-ориентированной интерфейс,
архитектурой (SOA).
требуемый
интерфейс,
порт,
класс,
коннектор,
артефакт,
реализация
компонента,
использование.
Диаграмма
В то время как диаграммы компонентов проявление,
проявления
показывают компоненты и отношения между компонент,
компонентами
классификаторами,
и
а артефакт.
диаграммы развертывания — развертывание
артефактов в целях развертывания, некоторая
отсутствующая промежуточная диаграмма — это
диаграмма проявления, которая используется
(реализации)
для демонстрации проявления
компонентов
артефактами
внутренней
и
структурой артефактов.
Поскольку
определены
диаграммы
проявления
спецификацией
UML
не
2.5,
проявление компонентов в виде артефактов
можно
показать
с
помощью
диаграмм
компонентов или диаграмм развертывания.
35
Диаграмма
Показывает
системы
архитектуру
как развертывание,
развертывания развертывание (распределение) программных артефакт,
артефактов
по
цель
объектам развертывания, узел,
целевым
развертывания.
устройство,
среда
Обратите внимание, что компоненты были выполнения,
путь
непосредственно
развернуты
узлах
на
на связи, спецификация
диаграммах развертывания UML 1.x. В UML 2.x развертывания.
артефакты
на
развертываются
могут
артефакты
узлах,
и
манифестировать
(реализовывать)
компоненты.
развертываются
на
узлах
Компоненты
косвенно
через
артефакты.
Диаграмма
развертывания
(также
спецификации
типа)
показывает
развертывания
на
уровне
называемая
уровнем
некоторый
обзор
в
целях
артефактов
развертывания без ссылки на конкретные
экземпляры артефактов или узлов.
Диаграмма
развертывания
экземпляра
показывает
развертывание
экземпляров
артефактов
в
на
уровне
конкретных
экземплярах целей развертывания. Его можно
например,
использовать,
для
отображения
различий в развертывании в среде разработки,
промежуточной или производственной среде с
именами/идентификаторами
серверов
или
устройств
конкретных
сборки
или
развертывания.
Диаграмма
Диаграммы развертывания можно использовать узел,
сетевой
для демонстрации логической или физической маршрутизатор,
архитектуры
сетевой архитектуры системы. Такого рода балансировщик
диаграммы
развертывания,
формально
определенные в UML 2.5, можно
диаграммами сетевой архитектуры.
36
коммутатор,
не нагрузки,
назвать брандмауэр,
путь
связи, сегмент сети,
магистраль.
Диаграмма
Вспомогательная
профиля
позволяет
диаграмма
определять
которая профиль, метакласс,
UML,
пользовательские стереотип,
стереотипы, помеченные значения и ограничения расширение, ссылка,
в
упрощенного
качестве
расширения
стандарта
UML.
механизма профильное
Профили приложение.
позволяют адаптировать метамодель UML для
различных
•
Платформы (например, J2EE или .NET)
•
Области (например, моделирование в
или
реальном времени или бизнес-процессов).
Профильные
диаграммы
были
впервые
представлены в UML 2.0.
2.2. UML диаграммы поведения
Диаграммы
поведения
показывают
динамическое
поведение
объектов в системе, которое можно описать как серию изменений в системе с
течением времени (табл. 3).
Таблица 3
UML диаграммы поведения
Диаграмма
Цель
Элементы
Диаграмма
Описывает набор действий (вариантов прецедент,
вариантов
использования),
использования
система или системы (субъект) должны предмет,
которые
некоторая действующее лицо,
или могут выполнять в сотрудничестве с расширение,
одним
или
несколькими
внешними включение,
пользователями системы (субъектами) для ассоциация.
37
предоставления некоторых наблюдаемых и
ценных результатов субъектам или другим
заинтересованным сторонам система(ы).
Обратите внимание, что в спецификации
UML
указано,
что
диаграммы
использования
являются
2.4.1
вариантов
специализацией диаграмм классов, так что
показанные классификаторы ограничены
либо
вариантами
либо
субъектами,
Диаграммы
использования.
классов
являются структурными диаграммами.
Диаграмма
Показывает обмен информацией между информационный
информационных
сущностями
системы
потоков
высоких
уровнях
Информационные
полезны
через
некоторых поток,
абстракции. информационная
потоки
описания
для
информации
на
могут
быть единица,
актер,
циркуляции класс
систему
путем
представления аспектов моделей, еще не
полностью определенных или с меньшим
количеством деталей.
Диаграмма
Показывает последовательность и условия активность, раздел,
деятельности (иногда для координации поведения более низкого действие,
называют
уровня, а не то, какие классификаторы управление,
«активности»)
владеют этим поведением. Их обычно активности.
называют моделями потока управления и
потока объектов.
Диаграмма
Используется в разработке программного
состояний
обеспечения,
чтобы
моделировать
поведение
визуализировать
объекта
и
или
системы в различных состояниях. Она
позволяет
описать
все
возможные
состояния объекта, а также переходы
между ними в ответ на определенные
38
объект,
край
события. Диаграмма показывает автомат
(state
machine),
состояния,
включающий
в
себя
события
переходы,
и
деятельности. Описывает динамическое
представление объекта. Они особенно
важны
моделирования
для
поведения
интерфейсов, классов или коопераций и
событийно-зависимое
подчеркивает
поведение объекта, что особенно удобно
для моделирования реактивных систем.
Диаграмма
Используется
для
моделирования
конечного автомата дискретного поведения через конечные
переходы состояний. В дополнение
к
выражению
поведения
части
системы
конечные
автоматы
также
могут
использоваться для выражения протокола
использования части системы. Эти два
типа
называются
автоматов
конечных
поведенческими конечными автоматами
и
конечными
протокольными
автоматами.
Диаграмма
Демонстрирует
поведенческого
части
поведение поведенческое
дискретное
проектируемой
системы
через состояние,
поведенческий
конечного автомата конечные переходы состояний.
переход,
псевдосостояние.
Схема
конечного Показывает протокол использования или состояние
цикл
автомата протокола жизненный
классификатора,
операции
вызваны
классификатора
в
некоторого протокола, переход
например,
каждом
какие протокола,
могут
быть псевдосостояние.
состоянии
классификатора, при каких конкретных
условиях
и
выполнении
39
некоторых
необязательных
перехода
постусловий
после
в
целевое
классификатора
состояние.
Диаграмма
Диаграммы взаимодействия включают
взаимодействия
несколько различных типов диаграмм:
•
диаграммы последовательности,
•
диаграммы связи (известные как
диаграммы сотрудничества в UML
1.x),
Диаграмма
•
временные диаграммы,
•
схемы взаимодействия.
Наиболее распространенный вид диаграмм линия
жизни,
последовательности взаимодействия, который фокусируется на спецификация
обмене
сообщениями
между
линиями выполнения,
жизни (объектами).
сообщение,
комбинированный
фрагмент,
использование
взаимодействия,
инвариант
состояния,
возникновение
разрушения.
Диаграмма
уделяется спасательный
внимание
связи Основное
(она же диаграмма взаимодействию между линиями жизни, сообщение.
сотрудничества
UML 1.x)
в где архитектура внутренней структуры и
то,
как
она
сообщений,
соответствует
являются
передаче
центральными.
Последовательность сообщений задается с
40
круг,
помощью схемы порядковой нумерации.
Временная
Показывает
диаграмма
основная цель диаграммы — рассуждать о временная
взаимодействия,
времени.
Временные
фокусируются
на
когда линия
жизни,
шкала
диаграммы состояния
или
условий состояния, событие
изменении
внутри и между линиями жизни вдоль разрушения,
линейной оси времени.
ограничение
продолжительности,
ограничение
времени
Обзорная диаграмма Определяет взаимодействия с помощью начальный
узел,
таким конечный
узел
взаимодействия
действий
диаграмм
варианта
образом,
чтобы
потока
управления.
способствовать
Диаграммы
обзору потока,
конечный
обзора узел действия, узел
взаимодействия фокусируются на обзоре решения,
узел
потока управления, где узлами являются слияния,
узел
использования разветвления,
взаимодействия
или
взаимодействия.
Линии
жизни
и соединения,
отображаются
на
этом взаимодействие,
сообщения
не
обзорном уровне.
узел
использование
взаимодействия,
ограничение
продолжительности,
ограничение
времени.
41
3. ОСНОВНЫЕ ЭЛЕМЕНТЫ UML
3.1. Пакет ядра
Спецификация UML имеет пакет ядра, который предоставляет
основные концепции моделирования UML, включая элемент, именованный
элемент, пространство имен, отношение, направленное отношение,
классификатор, комментарий и т. д.
Большинство
этих
понятий
абстрактны,
не
имеют
графического
представления и поэтому не используются непосредственно на диаграммах
UML, но они важны для понимания того, как организован UML.
3.2. Элемент
Элемент — это абстрактный корневой метакласс UML, у него нет
суперкласса в иерархии элементов UML. Это суперкласс для всех
метаклассов в инфраструктурной библиотеке UML (рис. 3.1.).
Рис. 3.1. Некоторые подклассы элемента UML.
Общего обозначения элемента нет. Конкретные подклассы элемента
определяют свои собственные обозначения.
42
3.3. Владение
Спецификации
«собственность»,
UML
2.x
«содержит»,
используют
«контейнер»
по
слова
«владеет»,
всему
тексту
без
надлежащего объяснения значения этих терминов. Вот мое предположение о
таинственных отношениях собственности.
Каждый элемент UML имеет отношение композиции к самому себе,
чтобы поддерживать способность элементов владеть другими элементами
(рис. 3.2.).
+ownedElement
*
*►
+owner
< >
0„l
0„l
+owningElement
{subsets owner}
*
+ownedComment
Comment
{subsets ownedElement}
Рис. 3.2. Каждый элемент UML имеет собственную композицию
— он может владеть другими элементами.
Таким образом, каждый элемент UML может быть владельцем других
элементов,
как
определено
отношением
композиции
— бинарным
отношением целое/часть, которое требует, чтобы каждая часть была
включена не более чем в один составной (целое) за раз, и, если составное
(целое) удаляется, все его составные части также удаляются. (UML также
позволяет в некоторых случаях удалять часть из композиции до того, как она
будет удалена, и, таким образом, не удалять ее как часть композиции.)
Обратите внимание, что любой элемент UML не может прямо или косвенно
владеть собой.
Когда спецификация UML определяет пространство имен, в одном
месте говорится, что пространство имен «содержит набор именованных
элементов», а в другом — что оно «может владеть другими именованными
элементами». Из этого мы можем сделать вывод, что, по крайней мере, для
43
пространств имен, владение и включение близки к синонимам (но, скорее
всего, содержащийся элемент не обязательно принадлежит).
3.4. Именованный элемент
Именованный элемент — это абстрактный элемент, который может
иметь имя. Имя используется для идентификации именованного элемента в
пространствах имен, в которых он определен или доступен.
Спецификация
UML
именованному
позволяет
элементу
быть
анонимным, т.е. не иметь имени. Также считается, что отсутствие имени
отличается от элемента с пустым именем.
Именованный
элемент
также
иметь
может
уточненное
имя,
позволяющее однозначно идентифицировать его в иерархии вложенных
пространств
имен.
Полное
имя
строится
из
имен
содержащихся
пространств имен, начиная с корня иерархии и заканчивая именем самого
именованного элемента и разделяя их «::». Если у элемента нет имени или
одно из содержащихся пространств имен не имеет имени, то у элемента нет
полного имени.
Именованный элемент может иметь видимость. Видимость определяет
пространства имен, в которых именованный элемент виден или доступен.
Если именованный элемент не принадлежит ни одному пространству имен,
то он не имеет видимости.
Некоторые подклассы именованного элемента:
•
пространство имен
•
переопределяемый элемент
•
пакетируемый элемент
•
действие
3.5. Переопределяемый элемент
Переопределяемый элемент
— это
абстрактный
именованный
элемент, который при определении в контексте обобщения классификатора
может быть переопределен более конкретно или иначе в контексте
44
другого классификатора, специализирующегося (прямо или косвенно)
классификатора контекста.
Переопределяющий элемент должен быть непротиворечивым или
совместимым с переопределяемым им элементом. Переопределяемый
элемент может быть переопределен несколько раз. Кроме того, один
переопределяющий
элемент
может
переопределять
несколько
унаследованных переопределяемых элементов.
UML не предоставляет нотации для переопределяемого элемента.
Конкретные подклассы переопределяемого элемента определяют свои
собственные обозначения.
Переопределяемый элемент имеет логический атрибут isLeaf, который
указывает, возможно ли переопределить элемент в подклассах. Если
значение равно true, дальнейшее переопределение элемента невозможно. В
языке Java он соответствует конечному классу, в C# — закрытому классу.
В предыдущих версиях UML конечный класс отображался со
свойством "{leaf}" под именем класса. (Наличие ключевого слова для
логического типа без значения подразумевает значение true.)
В UML 2.3 метаатрибут isLeaf был заменен свойством isLeaf
переопределяемого
элемента,
спецификация
но
не
предоставляет
обозначения для элементов, имеющих это свойство как истинное.
Некоторые подклассы переопределяемого элемента:
•
классификатор
•
особенность
•
точка расширения
3.6. Тип
Тип — это абстрактный метакласс UML, который представляет набор
значений и используется в качестве ограничения диапазона значений,
представляемых связанным типизированным
элементом (рис. 3.3.).
Типизированный элемент, имеющий этот тип, ограничен представлением
45
значений в наборе значений. Типизированный элемент без связанного типа
может представлять значения любого типа.
Рис. 3.3. Тип — это метакласс UML, используемый в качестве
ограничения диапазона значений, представленных связанным
типизированным элементом.
И
тип,
и
типизированный
элемент
являются
абстрактными
метаклассами UML и не имеют нотации.
3.7. Функция
3.7.1. Понятие функции
Функция представляет собой структурную или поведенческую
характеристику классификатора или экземпляров классификаторов (рис.
3.4.).
46
Рис. 3.4. Обзорная диаграмма функций
Функция может быть, как нестатической, так и статической. Один и
тот же признак не может быть статичным в одном контексте и нестатичным в
другом.
Признаками класса являются атрибуты (структурные признаки) и
операции (поведенческие признаки).
Характеристики не имеют общих обозначений. Подклассы определяют
свою конкретную нотацию.
Многоточие (...) в конце списка функций указывает на то, что
дополнительные функции существуют, но не отображаются в этом списке.
3.7.2. Нестатическая функция
Нестатический
признак
характеризует
отдельные
экземпляры
классификатора.
3.7.3. Статическая функция
Статическая функция представляет собой некоторую характеристику
самого классификатора.
Статическая функция может иметь одну из двух альтернативных
семантик:
•
разные значения для разных классификаторов характеристик или
47
•
одинаковое значение для всех классификаторов признаков.
По этой причине наследование значений статических функций
разрешено, но не требуется в UML 2.
Имена статических объектов подчеркнуты.
3.7.4. Структурная особенность
Структурная
функция
—
типизированная
это
функция
классификатора, которая определяет структуру экземпляров классификатора,
она указывает, что экземпляры характерного классификатора имеют слот,
значение или значения которого имеют указанный тип.
Свойство является примером структурной особенности.
Структурный элемент поддерживает множественность, указывающую
допустимые количества элементов для набора значений, связанных с
созданием экземпляра структурного элемента.
Структурная функция может быть обозначена как функция только
для чтения.
Структурная
функция только для чтения показана с
использованием {readOnly} как части обозначения функции.
Структурные элементы по умолчанию доступны не только для чтения,
но в то же время спецификация UML позволяет подавить аннотацию
{readOnly} на диаграммах UML. Если {readOnly} был подавлен, невозможно
определить, доступна ли статическая функция только для чтения или нет по
диаграмме.
3.7.5. Поведенческая особенность
Поведенческий
признак
—
это
признак
классификатора,
определяющий аспект поведения его экземпляров. Поведенческая функция
указывает, что экземпляр классификатора будет отвечать на определенные
запросы, вызывая поведение.
Операция является примером поведенческой особенности.
Список
собственных
параметров
описывает
порядок,
тип
и
направление аргументов, которые могут быть переданы при вызове
48
поведенческой функции или которые возвращаются при завершении работы
поведенческой функции. Поведенческая функция может вызвать исключение
во время ее вызова.
3.8. Экземпляр и спецификация экземпляра
Экземпляр — некоторая системная сущность, конкретное проявление
(реализация) абстракции. Абстракция может быть представлена одним или
несколькими классификаторами, или вообще без классификаторов. Обычно
мы используем/имеем экземпляры:
•
класс -> объекты
•
ассоциация -> ссылки
•
составная часть
•
артефакт
•
узел
•
актер
•
вариант использования
Когда экземпляр проявляет какой-либо классификатор, он называется
экземпляром этого классификатора, например, экземпляром класса Customer,
экземпляром узла Server, экземпляром варианта использования Buy Ticket. В
некоторых случаях экземпляры классификаторов имеют определенные
имена. Например, объект — это экземпляр класса, а ссылка — экземпляр
ассоциации.
Экземпляр обычно занимает некоторое пространство или слоты
памяти в реальном или программном мире, и он может находиться в
некотором состоянии в результате примененных операций.
Спецификация
экземпляра
—
это
пакетный
элемент
UML,
представляющий некоторый экземпляр в смоделированной системе.
Спецификация экземпляра обычно отображается на диаграммах
уровня экземпляра— диаграммах
структуры,
диаграммах
объектов,
развертывания
49
на
диаграммах составной
уровне
экземпляров,
диаграммах
поведения
—
диаграммах
вариантов
использования,
диаграммах взаимодействия и диаграммах действий.
Спецификация экземпляра описывает экземпляр с соответствующей
степенью детализации, частично или полностью. Описание может
включать:
•
Тип объекта, не заданный ни одним, одним или несколькими
классификаторами, экземпляром которого является объект.
•
Определение значений структурных признаков объекта.
•
Спецификация того, как создать, получить или вычислить экземпляр.
Не все структурные особенности всех классификаторов спецификации
экземпляра должны быть представлены слотами,
и в этом случае
спецификация экземпляра является частичным описанием.
Экземпляр может иметь имя или быть анонимным, если имя не важно.
Имя экземпляра позволяет отличить экземпляр от других экземпляров в том
же контексте именования (области действия).
UML 2.4 не предоставляет ни синтаксических правил BNF, ни даже
вербальных правил для имен экземпляров. Есть также только несколько
примеров. Обычно имя представляет собой короткое существительное или
именное словосочетание, последовательность букв, цифр и некоторых знаков
препинания (например, обычно исключается двоеточие). Ниже я составил
несколько BNF, потому что есть еще кое-что, о чем следует помнить.
instance-specification-name ::= [labels][instance-name]
[composite-type-names]
labels ::= '«' label[ ',' label]* '»'
label ::= keyword | stereotype
instance-name ::= identifier
composite-type-names ::= composite-type-name [ ',' composite-type-name ]*
composite-type-name ::= namespace [
namespace]*
namespace ::= identifier
Спецификация
экземпляра
использует ту же
нотацию,
что
и
классификатор. Имя отображается в виде подчеркнутой конкатенации имени
50
экземпляра (если есть), двоеточия (':') и имени (имен) классификатора.
Обратите внимание, что приведенный выше BNF делает ':' в имени
спецификации экземпляра обязательным, что не обязательно верно. В
некоторых случаях, когда очевидно, что на диаграмме показан экземпляр,
допускается не использовать подчеркивание.
Имена необязательны как для спецификаций экземпляров, так и для
классификаторов UML (рис. 3.5.).
:Customer
Рис. 3.5. Анонимный экземпляр класса Customer.
В некоторых случаях классификатор экземпляра неизвестен или не
указан. Когда имя экземпляра также не указано, нотация для такого
анонимного экземпляра безымянного классификатора представляет собой
просто подчеркнутое двоеточие - :_(рис. 3.6. и рис. 3.7.).
newPatient:
Рис. 3.6. Экземпляр newPatient безымянного или неизвестного класса.
Рис. 3.7. Экземпляр app-srv-37 сервера Sun Fire X4150, представленный
как устройство.
Экземпляр может иметь указанное имя экземпляра (рис. 3.8.),
классификатор и пространство имен (пакет), все это необязательно. При
отображении нескольких классификаторов принято разделять их имена
запятыми.
51
front-facm о-cam:
android.hardware­
camera
Рис. 3.8. Экземпляр фронтальной камеры класса Camera из пакета
android.hardware.
Если экземпляр имеет некоторое значение, спецификация значения
отображается либо после знака равенства ('=') после имени экземпляра, либо
без знака равенства под именем (рис. 3.9.).
Рис. 3.9. Экземпляр orderPaid класса Date имеет значение 31 июля 2011
г., 15:00.
Слоты показаны как структурные элементы с именем элемента, за
которым следует знак равенства ('=') и спецификация значения (рис. 3.10.).
Также может быть показан тип (классификатор) признака.
newPatient: Patient
id: String = “38-545-137"
name = John Doe
gender Gender = male
Рис. 3.10. Экземпляр newPatient класса Patient имеет слоты с
указанными значениями.
3.9. Отношение
Отношения — это абстрактный элемент, который представляет собой
концепцию некоторого отношения между элементами UML.
Связь ссылается на один или несколько связанных элементов.
52
Общего обозначения
отношения
нет. В большинстве
случаев
обозначение представляет собой некую линию, соединяющую связанные
элементы. Конкретные подклассы отношения определяют свои собственные
обозначения.
Подклассы отношений:
•
ассоциация,
•
направленная связь.
Семантическая связь.
Хотя спецификации UML (от UML 1.3 до UML 2.4) используют
семантические отношения терминов в нескольких местах, они не дают ни
определения, ни объяснения термина. В спецификациях UML нет глоссария,
начиная с UML 2.0, поэтому мы можем только догадываться о значении
многих причудливых терминов, используемых в спецификациях UML.
В
UML
1.x
классифицируются
ассоциации,
как
и
зависимости
отношения.
Руководство
ограничения
семантические
пользователя UML примерно в то же время определило ассоциацию как
структурную связь.
Начиная
с
UML
2.0,
только
ассоциация
по-прежнему
классифицируется как семантическая связь по спецификации UML, в то
время как ограничение стало упаковываемым элементом, а зависимость
теперь является отношением поставщик/клиент. Веб-сайт IBM / Rational
определяет ассоциацию как структурную, так и семантическую связь, где
«семантическая» означает, что могут быть «связи между ... экземплярами», а
«структурная», что «объекты одной вещи связаны с объектами другой вещи».
Попробуйте найти разницу, предполагая, что объекты и экземпляры
являются синонимами!
Моя интуиция подсказывает мне, что структурные отношения — это
отношения между целым и частью или, возможно, между частями одного и
того же целого, как, например, двигатель структурно связан с автомобилем.
Я не думаю, что связанные экземпляры обязательно структурно связаны. Моя
53
беспроводная мышь имеет связь с моим компьютером, но не является
структурной частью этого компьютера. С другой стороны, структурная
взаимосвязь может означать просто взаимосвязь, используемую на
структурной диаграмме.
Я мог бы предположить, что семантическая связь — это связь, в
которой существует какая-то нематериальная ассоциация или связь (в
здравом смысле) между объектами, не имеющая никаких физических связей
— как автомобиль может быть семантически связан с автомобильной
компанией, производящей его, или игрок с командой, в которой он работает.
играет за - но нам нужно подождать, пока авторы UML перестанут
безответственно использовать декоративные слова или должным образом
объясняться.
3.10. Направленные отношения
Направленная связь — это абстрактная связь между набором
исходных элементов и набором целевых элементов.
Общего обозначения направленной связи не существует. В большинстве
случаев обозначение представляет собой своего рода линию, проведенную от
источника(-ов)
к
цели(-ям).
Конкретные
подклассы
направленного
отношения определяют свои собственные обозначения.
Подклассы направленного отношения:
•
обобщение,
•
зависимость,
•
включить (из вариантов использования),
•
расширить (из вариантов использования),
•
привязка шаблона.
3.11. Комментарий
Комментарий (он же примечание) — это элемент, представляющий
собой текстовую аннотацию (примечание, комментарий), которую можно
прикрепить к другому элементу или набору элементов. Комментарий не
54
добавляет семантики к элементам, но может содержать некоторую
информацию, полезную для разработчика моделей или читателя диаграммы
UML, которую обычно нельзя выразить с помощью других элементов UML.
Комментарий может принадлежать любому элементу.
Комментарий отображается в виде прямоугольника с загнутым правым
верхним углом - "символ примечания" (рис. 3.11.). Прямоугольник содержит
тело комментария. Комментарий соединяется с каждым аннотируемым
элементом пунктирной линией.
Рис. 3.11. Комментарий, поясняющий клинический документ и его
отношение к пациенту.
Пунктирная линия, соединяющая комментарий с аннотируемым
элементом (элементами), может быть опущена, если это понятно из
контекста или не имеет значения на диаграмме.
55
РАЗДЕЛ II
СТРУКТУРНЫЕ
UML ДИАГРАММЫ
56
4. UML ДИАГРАММА КЛАССОВ
4.1. Понятие и типы UML диаграммы классов
Диаграмма классов — это структурная диаграмма UML, которая
показывает структуру проектируемой системы на уровне классов и
интерфейсов, показывает их особенности, ограничения и отношения —
ассоциации,
обобщения,
зависимости
и
т.д.
Диаграммы
предназначены для статического представления системы.
Некоторые распространенные типы диаграмм классов:
•
диаграмма модели предметной области (рис. 4.1.),
•
схема классов реализации (рис. 4.2.).
57
классов
порядок чтения
атрибуты
Book
Перечислимый
тип данных
абстрактный класс
ISBN: String[O..1] {id}
title: String
4
summary
\
Author
name:String
biography: String
publisher
\
publication date \
number of pages \
«enumeration»
language
«use»
кратность
обобщение
AccointState
Active
Frozen
Closed
«enity» Account
«enity» Book Item
barcode: String (0..1) {id) 0..12
tag: RFID <0..1){id}
◄ borrowed
стереотипный
класс
isReferenceOniy
0..3
◄ reserved
number {id}
history: History[0..*J
opened: Date
stale: Accountstate
accounts
accounts *
агрегация
ассоциация
Library
Parton
О
records
композиция
name
adress
name
address
«interface»
Search
Librarian
Catalog
«interface»
Manage
<---
■'
use
реализация
зависимость
Рис. 4.1 Диаграмма модели предметной области
58
name
address
position
android,app::Activity
# onCreate(state: Bundle)
SonStartf)
# onStop()
setType(type: Integer)
# onDestroyO
setFormatfformat: Integer)
onCreateOptionsMenu(menu: Menu): Boolean
getSurface(): Surface
onOptionsltemSelected(item: Menuitem): Boolean
sunacecnangedfholder SurfaceHolder,
irmat: Integer, width: Integer, height: Intec
' shutterCallback: ShutterCallback
surfaceCreatedfholder SurfaceHolder)
' rawCallback: Picturecallback
' jpegCallback: Picturecallback
surfaceDestroyed(holder: SurfaceHolder)
tr /onCreate(savedlnstanceState: Bundle)
#/onStart()
android.view:: SurfaceView
S/onStopO
/drawfcanvas: Canvas)
# /onDestroyO
getHolderf): SurfaceHolder
- mHolder SurfaceHolder
"create" Previewfcontext: Context)
open(camerald: integer): camera
/surfaceChangedfholder: SurfaceHolder, format Integer,
idth: Integer, height: Integer)
Ь
/surfaceCreatedfholder: SurfaceHolder)
setParametersfparams: Parameters)
/surfaceDestroyedfholder: SurfaceHolder)
setPreviewDisplayfholder: SurfaceHolder) {final}
/getHolderf): SurfaceHolder
startPreviewf) {final}
/drawfcanvas: Canvas)
stopPreviewO {final}
takePicturefshutter: ShutterCallback, raw: Picturecallback,
postview: Picturecallback, jpeg: Picturecallback) {final}
Рис. 4.2. Диаграмма классов реализации
4.2. Класс
Класс — это классификатор, описывающий набор объектов,
имеющих одинаковые:
•
особенности,
•
ограничения,
•
семантику (значение).
Класс отображается в виде прямоугольника со сплошным контуром,
содержащего
имя класса, и, возможно, с
59
отсеками,
разделенными
горизонтальными линиями, содержащими функции или другие элементы
классификатора.
Поскольку
класс
является
наиболее
широко
используемым
классификатором, нет необходимости добавлять ключевое слово «класс» в
кавычках над именем класса. Имя класса должно располагаться по центру и
выделено жирным шрифтом (рис. 4.3.), причем первая буква имени класса
должна быть заглавной (если набор символов поддерживает верхний
регистр).
Customer
Рис. 4.3. Класс Customer - подробности скрыты
Признаками класса являются атрибуты и операции (рис. 4.4).
SearchService
engine: SearchEngine
query: SearchRequest
search))
Рис. 4.4. Класс SearchService — детали уровня анализа
Когда класс показан с тремя отсеками, средний отсек содержит список
атрибутов, а нижний отсек содержит список операций. Атрибуты и
операции должны быть выровнены по ширине, а первая буква имени
должна быть в нижнем регистре.
Характеристики, представленные функцией, могут относиться к
экземплярам
классификатора,
рассматриваемым
индивидуально
(не
статические), или к самому классификатору (статические). Один и тот же
60
признак не может быть статичным в одном контексте и нестатичным в
другом.
Что касается статических признаков, признаются две альтернативные
семантики. Статическая функция может иметь:
•
разные значения для разных классификаторов характеристик или
•
одинаковое значение для всех классификаторов признаков.
В соответствии с этой семантикой наследование значений статических
функций разрешено, но не требуется в UML 2.
Статические признаки подчеркнуты, но только имена. Многоточие (...)
в конце списка функций указывает на то, что дополнительные функции
существуют, но не отображаются в этом списке.
Атрибуты
класса
представлены
экземплярами
свойств,
принадлежащих классу. Некоторые из этих атрибутов могут представлять
навигационные концы бинарных ассоциаций.
Объекты класса должны содержать значения для каждого атрибута,
который является членом этого класса, в соответствии с характеристиками
атрибута, например, его типом и множественностью (рис. 4.5.).
SearchService
- config: Configuration
- engine: SearchEngine
+ search( query: SearchRequest): SearchResult
- createEnqinef): SearchEngine
Рис. 4.5. Класс SearchService — детали уровня реализации, где
createEngine является статической операцией
Атрибуты или операции могут быть сгруппированы по видимости.
Ключевое слово или символ видимости в этом случае можно указать один
раз для нескольких объектов с одинаковой видимостью (рис. 4.6.).
61
SearchService
private:
config: Configuration
engine: SearchEngine
private:
createEngineQ: SearchEngine
public:
search( query: SearchRequest): SearchResult
Рис. 4.6. Класс SearchService — атрибуты и операции, сгруппированные
по видимости
Дополнительные отсеки могут быть предоставлены для отображения
других деталей, таких как ограничения, или просто для разделения
функций.
Класс в UML можно использовать в качестве пространства имен для других
классификаторов, включая классы, интерфейсы, варианты использования и
т.д. Вложенные классификаторы видны только в пространстве имен
содержащего класса.
В UML 2.5 класс стал структурированным, инкапсулированным и
управляемым за счет расширения инкапсулированного классификатора и
поведенческого классификатора. Из-за этого любой класс может иметь
некоторую внутреннюю структуру и порты (рис. 4.7.).
Library
Services
Search Books
Searchvideo
O-
searchPort
Inventory
Рис. 4.7. Library Services — это структурированный класс,
инкапсулированный через порт searchPort.
Вложенность
классификаторов,
структурированного класса, ограничивает
62
определенных
видимость
в
рамках
классификаторов
областью пространства имен содержащего их структурированного класса и,
таким образом, поддерживает инкапсуляцию (сокрытие информации) через
порты (рис. 4.8.).
Рис. 4.8. Структурированный класс Online Shopping с торговым портом
и внутренней структурой.
4.3. Абстрактный класс
В UML 2.4 упоминается абстрактный класс, но не дается определения.
Вероятно, мы можем связать определение абстрактного классификатора с
абстрактным классом.
Мы можем предположить, что в UML 2.x
абстрактный класс не имеет полного объявления и «обычно» не может быть
создан. Абстрактный класс предназначен для использования другими
классификаторами (например, в качестве цели отношений обобщения-
обобщения).
UML 2.4 не дает объяснения «неполного объявления класса» и того,
связано ли оно с концепцией абстрактной операции, которая также
присутствовала в UML 1.4.2 и отсутствует в UML 2.x.
Попытка создать экземпляр абстрактного класса не определена —
некоторые языки могут сделать это действие незаконным, другие могут
создать частичный экземпляр для целей тестирования.
Имя абстрактного класса показано курсивом (рис. 4.9.).
SearchRequest
Рис. 4.9. Класс SearchRequest является абстрактным классом
63
Абстрактный классификатор также можно отобразить с помощью
ключевого слова {abstract} после или под именем.
Абстрактный класс был определен в UML 1.4.2 как класс, экземпляр
которого нельзя создать напрямую. Абстрактный класс существует только
для того, чтобы другие классы наследовали и поддерживали повторное
использование функций, объявленных им. Никакой объект не может быть
прямым экземпляром абстрактного класса, хотя объект может быть
косвенным экземпляром одного через подкласс, который не является
абстрактным.
4.4. Стереотипы класса
На диаграммах классов в качестве сущностей применяются, прежде
всего, классы, как в своей наиболее общей форме, так и в форме
многочисленных стереотипов и частных случаев: интерфейсы, типы
данных, активные классы и др.
Стереотипы
являются
одним
из
трех
типов
механизмов
расширяемости в UML. Они позволяют проектировщикам расширять словарь
UML для создания новых элементов моделирования, получаемых из
существующих, но имеющих определенные свойства, которые подходят для
конкретной
проблемы
предметной
области
или
для
другого
специализированного использования.
Термин происходит от первоначального значения слова «стереотип»,
который используется в книгопечатании. Например, при моделировании сети
вам могут понадобиться символы для представления маршрутизаторов и
концентраторов. С помощью стереотипных узлов вы можете представлять их
в виде примитивных строительных блоков.
Существует несколько стандартных стереотипов UML, применимых к
классам (табл. 4).
Таблица 4
Стандартные стереотипы классов UML
64
Описание
Имя
"Вспомогательный"
Вспомогательный класс — это класс, который поддерживает
другой, более центральный или фундаментальный класс,
обычно путем реализации вторичной логики или потока
управления.
Класс,
поддерживаемый
вспомогательным
модулем, может быть определен либо явно с помощью класса
фокуса, либо неявно с помощью отношения зависимости.
Вспомогательные
классы
используются
обычно
для
определения вторичной бизнес-логики или потока управления
компонентами на этапе проектирования.
«Фокус»
Фокус — это класс, который определяет основную логику или
поток
управления
для
одного
или
нескольких
вспомогательных классов. Поддерживающие классы могут
быть определены либо явно с помощью вспомогательных
классов, либо неявно с помощью отношений зависимости.
Фокус-классы
основной
обычно
для
определения
потока
управления
используются
бизнес-логики
или
компонентами на этапе проектирования.
«Класс реализации»
Реализация класса на каком-либо языке программирования
(например, C++, Smalltalk, Java), в котором экземпляр не
может иметь более одного класса.
Это отличается от класса UML, для которого экземпляр может
иметь несколько классов одновременно и может приобретать
или терять классы с течением времени, а объект может
динамически иметь несколько классов.
Класс реализации может реализовать ряд различных типов.
Физические атрибуты и ассоциации класса реализации не
обязательно
должны быть такими
же,
как
у
любого
классификатора, который он реализует, и класс реализации
может предоставлять методы для своих операций с точки
зрения своих физических атрибутов и ассоциаций.
«Метакласс»
Класс, экземпляры которого также являются классами.
"Тип"
Тип — это класс, который определяет домен объектов вместе с
65
Описание
Имя
операциями, применимыми к объектам, без определения
физической реализации этих объектов.
Тип может иметь атрибуты и ассоциации. Поведенческие
спецификации для типовых операций могут быть выражены с
использованием, например, диаграмм деятельности. Объект
может иметь не более одного класса реализации, однако он
может соответствовать нескольким различным типам.
"Утилита"
Утилита — это класс, который имеет только статические
атрибуты и операции, относящиеся к классу. Таким образом,
служебный класс обычно не имеет экземпляров.
«utility»
Math
{leaf}
+ E: double = 2.7182818 (readOnlvl
+ PI: double = 3.1415926 treadOnlv)
- random NumberGenerator: Random
- Math()
* maxtint, int): int
* maxtlona. Iona): Iona
* sin(double): double
+ cos(double): double
* loq(double): double
Math — это служебный класс, имеющий статические
атрибуты и операции (подчеркнуто)
Обратите внимание, что соглашение об именах для стереотипов и
применяемых стереотипов было изменено в UML 2.4.1, чтобы первая буква
была в верхнем регистре. Вы по-прежнему везде будете встречать
стереотипы в нижнем регистре, например, «фокус», «тип», так как
потребуется некоторое время, чтобы переключиться на новое обозначение.
В некоторых инструментах UML, включая IBM Rational Software
Architect (RSA) и Sparx Enterprise Architect, есть несколько нестандартных, но
обычно используемых стереотипов классов: «Граница», «Контроль»,
«Сущность».
66
Эти стереотипы классов являются частью профиля анализа в RSA,
который по умолчанию
применяется с шаблоном модели анализа.
Стереотипы примерно соответствуют частям шаблона проектирования
Model-View-Controller (MVC), где Boundary представляет View, Control —
Controller, а Entity — Model (табл. 5).
Таблица 5
Нестандартные стереотипы классов UML
Описание
Имя
«Граница»
Граница
—
это
стереотипный
или
класс
объект,
представляющий некоторую границу системы, например экран
пользовательского интерфейса, системный интерфейс или
объект интерфейса устройства. Его можно использовать на
этапе анализа или концептуальной разработки для регистрации
пользователей или внешних систем, взаимодействующих с
разрабатываемой
диаграммах
системой.
Он
последовательности,
часто
используется
которые
демонстрируют
в
взаимодействие пользователя с системой.
Граница изображается в виде окружности, соединенной
короткой линией с вертикальной линией слева. Также может
быть представлена как класс со стереотипом «Граница».
"Контроль/Управление" Управление — это стереотипный класс или объект, который
используется для моделирования потока управления или
некоторой координации поведения. Один или несколько
классов управления могут описывать реализацию варианта
использования.
Системные
элементы
управления
представляют динамику спроектированной системы и обычно
описывают некоторую «бизнес-логику».
Элемент управления нарисован в виде круга со встроенной
стрелкой сверху. Его также можно представить как класс со
стереотипом «Контроль».
Обратите внимание, что UML имеет стандартный стереотип
«Фокус»,
применимый
к
классам,
которые
можно
использовать для указания основной бизнес-логики или
67
Описание
Имя
управления потоком компонентов во время проектирования.
"Сущность"
Сущность — это стереотипный класс или объект, который
представляет некоторую информацию или данные, обычно, но
не обязательно, постоянные.
Сущность изображается в виде круга с линией, прикрепленной
к нижней части круга. Его также можно представить как класс
со стереотипом «Сущность».
Бизнес - сущности представляют собой некоторые «вещи»,
предметы,
документы
или
используются
обрабатываются,
информацию,
или
которые
обрабатываются
работниками бизнеса во время ведения бизнеса. Примерами
бизнес - сущностей являются Рецепт в кабинете врача, Меню в
ресторане, Билет в аэропорту.
Системные объекты представляют некоторую информацию
или данные, обычно, но не обязательно постоянные, которые
обрабатываются системой.
Обратите внимание, что в UML 1.4.2 стереотип «сущность»
представлял собой пассивный класс, т.е. класс, объекты
которого сами по себе не инициируют взаимодействия. UML
2.0 обновил стандартный стереотип «Сущность», чтобы он
был
применим
к
компонентам
и представлял
бизнес-
концепцию постоянной информации.
4.5. Шаблон класса
Классы UML могут быть шаблонными или связанными.
В приведенном ниже примере на рисунке 4.10 показан класс шаблона
Array с двумя формальными параметрами шаблона. Первый параметр
шаблона T является неограниченным параметром шаблона класса. Второй
параметр шаблона n является параметром шаблона целочисленного
выражения.
68
Рис. 4.10. Класс шаблона Array и связанный класс Customers.
Привязка шаблона для связанного класса Customers заменяет
неограниченный класс T классом Customer и границей n с целочисленным
значением 24. Таким образом, связанный класс Customers представляет собой
Array (массив) из 24 объектов класса Customer.
4.6. Интерфейс
—
Интерфейс
согласованных
это
который
классификатор,
общедоступных
функций
и
объявляет
обязательств.
набор
Интерфейс
определяет контракт. Любой экземпляр классификатора, который реализует
(реализует) интерфейс, должен выполнять этот контракт и, таким образом,
предоставлять услуги, описанные в контракте.
Поскольку интерфейсы являются объявлениями, они не могут быть
созданы. Вместо этого спецификация интерфейса реализуется экземпляром
инстанцируемого классификатора,
классификатор
представляет
что означает,
общедоступный
что инстанцируемый
фасад,
соответствующий
спецификации интерфейса.
Любой данный классификатор может реализовывать более одного
интерфейса.
Интерфейс
может
быть
реализован
рядом
различных
классификаторов.
Связь
между интерфейсом и любым другим классификатором
подразумевает, что соответствующая ассоциация должна существовать
69
между
любой
реализацией
классификатором.
В
интерфейса
этого
ассоциация
частности,
и
этим
другим
интерфейсами
между
подразумевает, что между реализациями интерфейсов должна существовать
соответствующая ассоциация.
Обозначение. Интерфейс может быть показан с помощью символа
прямоугольника с ключевым словом «интерфейс» перед именем (рис. 4.11).
«interface»
SiteSearch
Рис. 4.11. Интерфейс SiteSearch
Обязательства,
представлены
в
которые
виде
могут
быть
связаны
различных
видов
ограничений
с
интерфейсом,
(таких
как
предварительные и постусловия) или спецификаций протокола, которые
могут налагать ограничения на упорядочение взаимодействий через
интерфейс (рис. 4.12).
«interface»
Pageable
+ UNKNOWN_N_OF_PAGES: int = -1
+ getNumberOfPages(): int
+ getPageFormat(int): PageFormat
+ getPrintable(int): Printable
Рис. 4.12. Интерфейс Pageable
Интерфейсы,
классификатором,
реализованные
являются
его
предоставляемыми интерфейсами и представляют обязательства, которые
экземпляры этого классификатора имеют перед своими клиентами. Они
описывают услуги, которые экземпляры этого классификатора предлагают
своим клиентам.
Интерфейс, участвующий в зависимости реализации интерфейса,
показан в виде кружка или шара, помечен названием интерфейса и
70
прикреплен сплошной линией к классификатору, реализующему этот
интерфейс (рис. 4.13.).
Рис. 4.13. Интерфейс SiteSearch, участвующий в реализации
SearchService
Требуемый интерфейс определяет сервисы, которые необходимы
классификатору для выполнения своих функций и выполнения собственных
обязательств перед своими клиентами. Он определяется зависимостью
использования между классификатором и соответствующим интерфейсом.
Зависимость использования от классификатора к интерфейсу показана
путем представления интерфейса полукругом или сокетом, помеченным
именем интерфейса, прикрепленным сплошной линией к классификатору,
которому требуется этот интерфейс (рис. 4.14.).
SiteSearch
—c
Search
Controller
Рис. 4.14. Интерфейс SiteSearch используется SearchController
На практике часто бывает так, что два или более интерфейсов взаимно
связаны зависимостями, зависящими от приложения. В таких ситуациях
каждый интерфейс представляет определенную роль в многостороннем
«протоколе». Эти типы связей ролей протоколов могут быть зафиксированы
ассоциациями между интерфейсами.
Интерфейс в UML можно использовать в качестве пространства имен
для других классификаторов, включая классы, интерфейсы, варианты
использования и т.д. Вложенные классификаторы видны только в
пространстве имен содержащего интерфейса.
Редакции.
71
В UML 1.4 интерфейс был формально эквивалентен абстрактному
классу без атрибутов и методов, а только с абстрактными операциями.
4.7. Функция
Функция представляет собой структурную или поведенческую
характеристику классификатора или экземпляров классификаторов (рис.
4.15.).
Рис. 4.15. Обзорная диаграмма функций
Функция может быть, как нестатической, так и статической. Один и
тот же признак не может быть статичным в одном контексте и нестатичным в
другом.
Признаками класса являются атрибуты (структурные признаки) и
операции (поведенческие признаки).
Характеристики не имеют общих обозначений. Подклассы определяют
свою конкретную нотацию.
Многоточие (...) в конце списка функций указывает на то, что
дополнительные функции существуют, но не отображаются в этом списке.
Нестатическая функция.
72
признак
Нестатический
характеризует
отдельные
экземпляры
классификатора.
Статическая функция.
Статическая функция представляет собой некоторую характеристику
самого классификатора.
Статическая функция может иметь одну из двух альтернативных
семантик:
•
разные значения для разных классификаторов характеристик или
•
одинаковое значение для всех классификаторов признаков.
По этой причине наследование значений статических функций
разрешено, но не требуется в UML 2. Имена статических объектов
подчеркнуты.
Структурная особенность.
Структурная
функция
—
это
типизированная
функция
классификатора, которая определяет структуру экземпляров классификатора,
она указывает, что экземпляры характерного классификатора имеют слот,
значение или значения которого имеют указанный тип.
Свойство является примером структурной особенности. Структурный
элемент
поддерживает
множественность,
указывающую
допустимые
количества элементов для набора значений, связанных с созданием
экземпляра структурного элемента.
Структурная функция может быть обозначена как функция только
для чтения.
Структурная
функция только для чтения показана с
использованием {readOnly} как части обозначения функции.
Структурные элементы по умолчанию доступны не только для чтения,
но в то же время спецификация UML позволяет подавить аннотацию
{readOnly} на диаграммах UML. Если {readOnly} был подавлен, невозможно
определить, доступна ли статическая функция только для чтения или нет по
диаграмме.
Поведенческая особенность.
73
Поведенческий
признак
—
это
признак
классификатора,
определяющий аспект поведения его экземпляров. Поведенческая функция
указывает, что экземпляр классификатора будет отвечать на определенные
запросы, вызывая поведение.
Операция является примером поведенческой особенности. Список
собственных параметров описывает порядок, тип и направление аргументов,
которые могут быть переданы при вызове поведенческой функции или
которые возвращаются при завершении работы поведенческой функции.
Поведенческая функция может вызвать исключение во время ее вызова.
Экземпляр и спецификация экземпляра.
Экземпляр — некоторая системная сущность, конкретное проявление
(реализация) абстракции. Абстракция может быть представлена одним или
несколькими классификаторами, или вообще без классификаторов. Обычно
мы используем/имеем экземпляры:
•
класс -> объекты
•
ассоциация -> ссылки
•
составная часть
•
артефакт
•
узел
•
актер
•
вариант использования
Когда экземпляр проявляет какой-либо классификатор, он называется
экземпляром этого классификатора, например, экземпляром класса Customer,
экземпляром узла Server, экземпляром варианта использования Buy Ticket. В
некоторых случаях экземпляры классификаторов имеют определенные
имена. Например, объект — это экземпляр класса, а ссылка — экземпляр
ассоциации.
Экземпляр обычно занимает некоторое пространство или слоты
памяти в реальном или программном мире, и он может находиться в
некотором состоянии в результате примененных операций.
74
Спецификация
экземпляра
—
это
пакетный элемент
UML,
представляющий некоторый экземпляр в смоделированной системе.
Спецификация экземпляра обычно отображается на диаграммах
уровня экземпляра — диаграммах объектов, диаграммах составной
структуры,
диаграммах
диаграммах
поведения
развертывания
—
диаграммах
на
уровне
вариантов
экземпляров,
использования,
диаграммах взаимодействия и диаграммах действий.
Спецификация экземпляра описывает экземпляр с соответствующей
степенью детализации, частично или полностью. Описание может включать:
•
Тип объекта, не заданный ни одним, одним или несколькими
классификаторами, экземпляром которого является объект.
•
Определение значений структурных признаков объекта.
•
Спецификация того, как создать, получить или вычислить экземпляр.
Не все структурные особенности всех классификаторов спецификации
экземпляра должны быть представлены слотами,
и в этом случае
спецификация экземпляра является частичным описанием.
Экземпляр может иметь имя или быть анонимным, если имя не важно.
Имя экземпляра позволяет отличить экземпляр от других экземпляров в том
же контексте именования (области действия).
UML 2.4 не предоставляет ни синтаксических правил BNF, ни даже
вербальных правил для имен экземпляров. Есть также только несколько
примеров. Обычно имя представляет собой короткое существительное или
именное словосочетание, последовательность букв, цифр и некоторых знаков
препинания (например, обычно исключается двоеточие). Ниже я составил
несколько BNF, потому что есть еще кое-что, о чем следует помнить.
instance-specification-name::= [labels'] [instance-name]':'[composite-type-names]
labels ::= '«' label [',' label ]*'»'
label::= keyword | stereotype
instance-name::= identifier
composite-type-names ::= composite-type-name [ ',' composite-type-name ]*
75
composite-type-name ::= namespace [ '::' namespace ]*
namespace ::= identifier
Спецификация
экземпляра использует ту же
нотацию,
что
и
классификатор. Имя отображается в виде подчеркнутой конкатенации имени
экземпляра (если есть), двоеточия (':') и имени (имен) классификатора.
Обратите внимание, что приведенный выше BNF делает ':' в имени
спецификации экземпляра обязательным, что не обязательно верно. В
некоторых случаях, когда очевидно, что на диаграмме показан экземпляр,
допускается не использовать подчеркивание.
Как уже говорилось в прошлой главе, имена необязательны как для
спецификаций экземпляров, так и для классификаторов UML (рис. 4.16.).
:Customer
Рис. 4.16. Анонимный экземпляр класса Customer.
В некоторых случаях классификатор экземпляра неизвестен или не
указан. Когда имя экземпляра также не указано, нотация для такого
анонимного экземпляра безымянного классификатора представляет собой
просто подчеркнутое двоеточие -_:_(рис. 4.17. и 4.18.).
newPatient:
Рис. 4.17. Экземпляр newPatient безымянного или неизвестного класса.
76
Рис. 4.18. Экземпляр app-srv-37 сервера Sun Fire X4150, представленный
как устройство.
Экземпляр может иметь указанное имя экземпляра (рис. 4.19.),
классификатор и пространство имен (пакет), все это необязательно. При
отображении нескольких классификаторов принято разделять их имена
запятыми.
front-facing-cam:
android.hard ware::
Camera
Рис. 4.19. Экземпляр фронтальной камеры класса Camera
из пакета android.hardware.
Если экземпляр имеет некоторое значение (рис. 4.20.), спецификация
значения отображается либо после знака равенства ('=') после имени
экземпляра, либо без знака равенства под именем.
Рис. 4.20. Экземпляр orderPaid класса Date
имеет значение 31 июля 2011 г., 15:00.
Слоты показаны как структурные элементы с именем элемента, за
которым следует знак равенства ('=') и спецификация значения (рис. 4.21.).
Также может быть показан тип (классификатор) признака.
77
newPatient: Patient
id: String = "36-545-137"
name = John Doe
gender: Gender = male
Рис. 4.21. Экземпляр newPatient класса Patient
имеет слоты с указанными значениями.
Отношение.
Отношения — это абстрактный элемент, который представляет собой
концепцию некоторого отношения между элементами UML.
Связь ссылается на один или несколько связанных элементов.
Общего обозначения
отношения
нет. В большинстве
случаев
обозначение представляет собой некую линию, соединяющую связанные
элементы. Конкретные подклассы отношения определяют свои собственные
обозначения.
Подклассы отношений:
•
Ассоциация
•
Направленная связь
Семантическая связь.
Хотя спецификации UML (от UML 1.3 до UML 2.4) используют
семантические отношения терминов в нескольких местах, они не дают ни
определения, ни объяснения термина. В спецификациях UML нет глоссария,
начиная с UML 2.0, поэтому мы можем только догадываться о значении
многих причудливых терминов, используемых в спецификациях UML.
В
UML
1.x
классифицируются
как
ассоциации,
и
зависимости
отношения.
Руководство
ограничения
семантические
пользователя UML примерно в то же время определило ассоциацию как
структурную связь.
78
Начиная
с
UML
2.0,
только
ассоциация
по-прежнему
классифицируется как семантическая связь по спецификации UML, в то
время как ограничение стало упаковываемым элементом, а зависимость
теперь является отношением поставщик/клиент. Веб-сайт IBM / Rational
определяет ассоциацию как структурную, так и семантическую связь, где
«семантическая» означает, что могут быть «связи между ... экземплярами», а
«структурная» - что «объекты одной вещи связаны с объектами другой
вещи». Попробуйте найти разницу, предполагая, что объекты и экземпляры
являются синонимами!
Моя интуиция подсказывает мне, что структурные отношения — это
отношения между целым и частью или, возможно, между частями одного и
того же целого, как, например, двигатель структурно связан с автомобилем.
Я не думаю, что связанные экземпляры обязательно структурно связаны. Моя
беспроводная мышь имеет связь с моим компьютером, но не является
структурной частью этого компьютера. С другой стороны, структурная
взаимосвязь может означать просто взаимосвязь, используемую на
структурной диаграмме.
Я мог бы предположить, что семантическая связь — это связь, в
которой существует какая-то нематериальная ассоциация или связь (в
здравом смысле) между объектами, не имеющая никаких физических связей
— как автомобиль может быть семантически связан с автомобильной
компанией, производящей его, или игрок с командой, в которой он работает.
играет за - но нам нужно подождать, пока авторы UML перестанут
безответственно использовать декоративные слова или должным образом
объясняться.
Направленные отношения.
Направленная связь — это абстрактная связь между набором
исходных элементов и набором целевых элементов.
Общего
обозначения
направленной
связи
не
существует.
В
большинстве случаев обозначение представляет собой своего рода линию,
79
проведенную
от
источника(ов)
к
цели(ям).
Конкретные
подклассы
направленного отношения определяют свои собственные обозначения.
Подклассы направленного отношения:
•
обобщение,
•
зависимость,
•
включить (из вариантов использования),
•
расширить (из вариантов использования),
•
привязка шаблона.
Комментарий.
Комментарий (он же примечание) — это элемент, представляющий
собой текстовую аннотацию (примечание, комментарий), которую можно
прикрепить к другому элементу или набору элементов. Комментарий не
добавляет семантики к элементам, но может содержать некоторую
информацию, полезную для разработчика моделей или читателя диаграммы
UML, которую обычно нельзя выразить с помощью других элементов UML.
Комментарий может принадлежать любому элементу.
Комментарий отображается в виде прямоугольника с загнутым правым
верхним углом - "символ примечания" (рис. 4.22.). Прямоугольник содержит
тело комментария. Комментарий соединяется с каждым аннотируемым
элементом пунктирной линией.
Рис. 4.22. Комментарий, поясняющий клинический документ и его
отношение к пациенту.
80
соединяющая комментарий с аннотируемым
Пунктирная линия,
элементом (элементами), может быть опущена, если это понятно из
контекста или не имеет значения на диаграмме.
4.8. UML-ограничение
Ограничение — это пакетируемый элемент, который представляет
некоторое условие, ограничение или утверждение, связанное с некоторым
элементом (владеющим ограничением) или несколькими элементами.
Ограничение обычно задается логическим выражением, которое должно
быть истинным или ложным. Ограничение должно быть удовлетворено (т. е.
оценено
как
истинное)
при
правильном
проектировании
системы.
Ограничения обычно используются для различных элементов на диаграммах
классов.
Вообще есть много возможных типов владельцев для ограничения.
Элемент-владелец должен иметь доступ к ограниченным элементам для
проверки
ограничения.
ограничение
будет
ограничения
Владелец
оцениваться.
Например,
определяет,
операция
может
когда
иметь
ограничения предусловия и/или постусловия.
Ограничение может иметь произвольное имя, хотя обычно оно
анонимно. Ограничение отображается в виде текстовой строки в фигурных
скобках в соответствии со следующим синтаксисом:
constraint ::= '{' [ name ':' ] boolean-expression '}'
Спецификация
UML
не
ограничивает
языки,
которые
можно
использовать для выражения ограничения. Некоторые примеры языков
ограничений:
•
ОКЛ
•
Ява
•
какой-то машиночитаемый язык
•
естественный язык
81
OCL — это язык ограничений, предопределенный в UML, но, если
какой-либо инструмент UML используется для рисования диаграмм, можно
применить любой язык ограничений, поддерживаемый этим инструментом.
Для элемента, обозначением которого является текстовая строка
(например, атрибут класса), строка ограничения может следовать за
текстовой строкой элемента в фигурных скобках (рис. 4.23.).
Bank Account
♦owner: String {owner->notEmpty()}
♦balance: Number (balance >= 0}
Рис. 4.23. Ограничения атрибутов банковского счета
- не пустой владелец и положительный баланс.
Для ограничения, которое применяется к одному элементу (например,
классу или пути ассоциации), строка ограничения может быть помещена
рядом с символом элемента, предпочтительно рядом с именем, если таковое
имеется. Инструмент UML должен позволять определять ограниченный
элемент.
Для ограничения, которое применяется к двум элементам (например,
двум классам или двум ассоциациям), ограничение может быть показано в
виде пунктирной линии между элементами, помеченными строкой
ограничения в фигурных скобках (рис. 4.24.).
Рис. 4.24. Владелец учетной записи — это лицо или корпорация,
{xor} — это предопределенное ограничение UML.
82
Если ограничение показано в виде пунктирной линии между двумя
элементами, то на одном конце может быть указана стрелка. Направление
стрелки является релевантной информацией в рамках ограничения. Элемент
в конце стрелки сопоставляется с первой позицией, а элемент в начале
стрелки сопоставляется со второй позицией в коллекции constrainedElements.
Для трех или более путей одного типа (таких как пути обобщения или
пути ассоциации) ограничение может быть прикреплено к пунктирной
линии, пересекающей все пути.
Строка ограничения может быть помещена в символ примечания
(такой же, как используется для комментариев) и присоединена к
каждому из символов для элементов ограничений пунктирной линией (рис.
4.25.).
Bank Account
♦owner: String
♦balance: Number
-------------- a------------
(owner->notEmpty()
and balance >= 0}
4
Рис. 4.25. Ограничения банковского счета - не пустой владелец и
положительный баланс.
4.9. Отношения
В UML способы соединения сущностей друг с другом, логические либо
физические,
моделируются
связями.
В
объектно-ориентированном
моделировании существует три типа наиболее важных связей: зависимости,
обобщения и ассоциации.
1. Зависимость представляет собой связь использования. Например,
трубы зависят от водонагревателя для подогрева воды, которая по ним
передается.
83
2. Ассоциация - это структурная связь между экземплярами. Например,
комнаты состоят из стен и других объектов; в стены вмонтированы двери и,
возможно, окна; через стены могут тянуться трубы.
3.
Обобщение
обобщенные
связывает
классы
с
более
специализированными и потому известны как связи наследования («классподкласс», или «родитель-потомок»). Например, витраж - это окно с очень
большими, жестко фиксированными панелями; патио - разновидность окна,
открывающегося вбок.
Эти три вида связей описывают большинство основных способов
взаимодействия сущностей. Неудивительно, что они хорошо проецируются и
на
те
способы,
которые
предусмотрены
большинством
объектно­
ориентированных языков для соединения объектов.
UML предлагает особое графическое представление для каждого вида
связи. Эта нотация позволяет визуализировать связи независимо от
конкретного языка программирования, причем способом, описывающим
наиболее важные параметры связей: имя, соединяемые сущности и свойства.
4.9.1. UML-ассоциация
Ассоциация — это отношение между классификаторами, которое
используется для демонстрации того, что экземпляры классификаторов могут
быть либо связаны друг с другом, либо логически или физически
объединены в некоторую совокупность.
Спецификация UML классифицирует ассоциацию как семантическое
отношение.
Некоторые
другие
источники
UML
также
определяют
ассоциацию как структурную связь. Википедия утверждает, что ассоциация
— это отношение уровня экземпляра, и что ассоциации могут быть
показаны только на диаграммах классов. Не уверен, откуда они взяли эту
информацию, но она не основана на спецификации UML. Ассоциация может
использоваться на различных типах структурных диаграмм UML:
•
ассоциации диаграммы классов,
•
ассоциации диаграмм вариантов использования,
84
•
ассоциации артефактов диаграммы развертывания,
•
схема развертывания коммуникационный путь.
Существует несколько понятий, связанных с ассоциацией:
•
ассоциация окончание владения,
•
мореходность,
•
ассоциация арность,
•
тип агрегации.
Простая ассоциация между двумя классами представляет структурную
связь
между равноправными элементами: оба класса концептуально
находятся на одном уровне - ни один из них не может считаться важнее
другого. Рано или поздно вам понадобится смоделировать связь «целоечасть», в которой один класс представляет крупную сущность (целое),
содержащую в себе более мелкие (части). Этот тип связей, основанных на
отношениях обладания, называется агрегацией и подразумевает, что объект-
целое обладает объектами-частями. По сути, агрегация - это особый вид
ассоциации, поэтому изображается она линией простой ассоциации, к
которой добавлен пустой ромбик со стороны объекта-целого.
Спецификация UML 2.4 утверждает, что для ассоциации: «Тип
агрегации,
возможность
навигации
и
конечное
владение
являются
ортогональными понятиями, ...», что явно является преувеличением.
Ортогональный обычно означает полностью независимый. Хотя обозначение
типа агрегации, навигации и владения концом ассоциации можно
применять
независимо друг от
друга,
сами понятия не являются
ортогональными. Например, в UML 2.4 конечное свойство ассоциации,
принадлежащее конечному классу, является доступным для навигации, что
явно делает навигацию зависимой от владельца (рис. 4.26.).
85
Рис. 4.26. Обзорная диаграмма взаимосвязей ассоциации.
Ассоциация обычно рисуется сплошной линией, соединяющей два
классификатора или один классификатор сам с собой. (рис. 4.27.) Название
ассоциации может быть показано где-то рядом с серединой линии
ассоциации, но не слишком близко к любому из концов линии. Каждый
конец линии может быть украшен именем конца ассоциации.
Рис. 4.27. Связь Ассоциация. Название «Wrote» написано между
Профессором и Книгой.
Конец ассоциации.
Конец ассоциации — это соединение между строкой, изображающей
ассоциацию, и значком, изображающим подключенный классификатор
(рис. 4.28.). Имя конца ассоциации может располагаться в конце строки.
Конечное имя ассоциации обычно называют именем роли (но оно не
определено как таковое в стандарте UML 2.4). Имя роли является
необязательным и подавляемым.
86
Рис. 4.28. Профессор, «исполняющий роль» автора, ассоциируется
с окончанием учебника, типизированным как Книга.
Идея роли заключается в том, что один и тот же классификатор может
играть те же или разные роли в других ассоциациях. Например, Профессор
может быть автором некоторых Книг или редактером.
Конец ассоциации может принадлежать либо:
•
конечному классификатору, либо
•
самой ассоциации
Концы
с
ассоциации
более
чем
двумя
концами
должны
принадлежать ассоциации.
Принадлежность
классификатору
может
ассоциации
концов
быть
обозначена
ассоциированному
графически
маленьким
закрашенным кружком (также известным как точка) (рис. 4.29.). Точка
рисуется в точке, где линия встречается с классификатором. Это можно
интерпретировать как демонстрацию того, что модель включает в себя
свойство типа, представленного классификатором, на котором стоит точка.
Это свойство принадлежит классификатору на другом конце.
Рис. 4.29. Запрос конца ассоциации принадлежит классификатору
QueryBuilder, а qbuilder конца ассоциации принадлежит самой
ассоциации Builds.
Точка «собственности» может использоваться в сочетании с другими
графическими обозначениями пути линии для свойств ассоциаций и концов
ассоциаций. К ним относятся тип агрегации и навигация.
87
Стандарт UML не предписывает использование явной нотации
конечного владельца, но определяет нотацию, которая должна применяться в
моделях, где такое использование выбрано. Точечная нотация должна
применяться на уровне полных ассоциаций или выше, так что отсутствие
точки означает принадлежность ассоциации. Другими словами, в
бинарных ассоциациях точка будет опущена только для тех концов, которые
не принадлежат классификатору.
Нотация атрибута может использоваться для конца ассоциации,
принадлежащего классу, потому что конец ассоциации, принадлежащий
классу, также является атрибутом (рис. 4.30.). Эту нотацию можно
использовать в сочетании с нотацией со стрелкой, чтобы было совершенно
ясно, что атрибут также является концом ассоциации.
Рис. 4.30. Конец ассоциации qb является атрибутом класса SearchService
и принадлежит этому классу.
Навигация. Свойство End ассоциации является доступным для
навигации с противоположного конца (концов) ассоциации, если к
экземплярам классификатора на этом конце ссылки можно эффективно
получить доступ во время выполнения из экземпляров на других концах
ссылки.
Спецификация UML не определяет, насколько эффективным должен
быть этот доступ, или какой-либо конкретный механизм для достижения
эффективности. Это зависит от реализации.
Когда конечное свойство ассоциации помечено как недоступное для
навигации, в [UML 2.4] это означает, что «доступ с других концов может
быть или не быть возможным, а если да, то он может быть
неэффективным».
UML 2.4 также предоставляет другое определение навигации:
88
«Свойство конца ассоциации, которым владеет конечный класс или
который является управляемым концом ассоциации, указывает, что
ассоциация доступна для навигации с противоположных концов; в
противном случае ассоциация будет без навигации с противоположных
концов».
Это
определение является
странным, потому что
оно
делает
навигацию сильно зависимой от права собственности, в то время, как они
предполагаются
ортогональными
понятиями;
некоторые примеры
в
спецификациях UML 2.4 показывают конечные свойства, принадлежащие
классу, как недоступные для навигации, что противоречит приведенному
выше определению; а возможность навигации определяется с помощью
«навигационного конца ассоциации».
Обозначение:
•
навигационный конец обозначен незаштрихованной стрелкой в
конце ассоциации
•
ненавигационный конец обозначается маленьким крестиком в
конце ассоциации
•
отсутствие украшения в конце ассоциации означает неуказанную
навигацию
На рисунках 4.31. - 4.36. представлены примеры обозначения.
Рис. 4.31. Оба конца ассоциации имеют неопределенную навигацию.
Рис. 4.32. A2 имеет неуказанную навигацию, а B2 - навигацию из A2.
89
Рис. 4.33. Навигация по A3 невозможна из B3, а навигация по B3 не
определена.
Рис. 4.34. Навигация по A4 невозможно из B4, а по B4 — из A4.
Рис. 4.35. По A5 можно пройти от B5, а по B5 можно пройти от A5.
Рис. 4.36. Навигация по A6 невозможно из B6, а по B6 нельзя пройти из
A6.
Символ видимости может быть добавлен в качестве украшения на
навигационный конец, чтобы показать видимость конца как атрибут
классификатора признаков.
Специфика.
Каждая ассоциация имеет свою специфику, так как может связывать
два или более предметов.
Бинарная ассоциация.
Двоичная ассоциация связывает два типизированных экземпляра.
Обычно
он
отображается
как
сплошная
линия,
соединяющая
два
классификатора, или сплошная линия, соединяющая один классификатор с
90
самим собой (два конца различны) (рис. 4.37.). Линия может состоять из
одного или нескольких соединенных сегментов.
Рис. 4.37. Классификаторы работы и года связаны.
Небольшой сплошной треугольник можно поместить
рядом с
названием бинарной ассоциации или вместо него (нарисованным сплошной
линией), чтобы показать порядок концов ассоциации. Стрелка указывает
вдоль линии в направлении последнего конца в порядке окончания
ассоциации. Это обозначение также указывает, что ассоциация должна быть
прочитана от первого конца до последнего конца (рис. 4.38.).
Рис. 4.38. Порядок концов и прочтения: Автомобиль - разработан в -
Год.
Спецификация UML 2.4 утверждает, что эта стрелка используется
только для целей документации и не имеет общей семантической
интерпретации. Это странное уточнение, поскольку диаграммы UML на
самом деле используются в основном для целей документации, но, что еще
более важно, эта стрелка в соответствии со спецификацией UML определяет
порядок концов ассоциации, который действительно относится к семантике.
N-арная ассоциация.
Любая ассоциация может быть изображена в виде ромба со сплошной
линией
для
каждого
конца
ассоциации,
соединяющей
ромб
с
классификатором, который является типом конца. Только таким образом
можно нарисовать N-арную ассоциацию с более чем двумя концами (рис.
4.39.).
91
Рис. 4.39. Трёхнарная ассоциация Design связывает три классификатора.
Общая и составная агрегация.
Агрегация — это бинарная ассоциация, представляющая некоторые
отношения «целое/часть». Тип агрегации может быть:
•
разделяемая агрегация (она же агрегация) или
•
составная агрегация (также известная как композиция).
Класс ассоциации.
Ассоциация может быть уточнена, чтобы иметь свой собственный
набор признаков; то есть функции, которые не принадлежат ни одному из
связанных классификаторов, а принадлежат самой ассоциации. Такая
ассоциация
называется
классом
ассоциации.
Это
одновременно
и
ассоциация, соединяющая набор классификаторов и класс, и поэтому она
может иметь особенности и может быть включена в другие ассоциации.
Класс ассоциации можно рассматривать как ассоциацию, которая
также имеет свойства класса, или как класс, который также имеет свойства
ассоциации.
Класс ассоциации показан как символ класса, присоединенный к пути
ассоциации пунктирной линией. Путь ассоциации и символ класса
ассоциации представляют один и тот же базовый элемент модели, который
имеет одно имя. Имя ассоциации может быть помещено в путь, в символ
класса или в оба, но они должны быть одним и тем же именем.
Ссылка.
Ссылка является экземпляром ассоциации. Это кортеж с одним
значением для каждого конца ассоциации, где каждое значение является
92
экземпляром типа конца. Ассоциация имеет как минимум два конца,
представленных свойствами (end properties).
Ссылка отображается с использованием тех же обозначений, что и для
ассоциации (рис. 4.40.). Сплошная линия соединяет экземпляры, а не
классификаторы. Название ссылки может быть показано подчеркнутым, хотя
это не обязательно. Могут отображаться конечные имена (роли) и стрелки
навигации.
Рис. 4.40. Ссылка, написанная между экземпляром р:Профессора,
играющего роль автора и экземпляром Ь:Книги, играющей роль
учебника.
4.9.2. Обобщение в UML
Обобщение представляет собой бинарную таксономическую (т.е.
связанную с классификацией) направленную связь между более общим
классификатором (надклассом) и более конкретным классификатором
(подклассом).
Каждый экземпляр конкретного классификатора также является
косвенным экземпляром общего классификатора, поэтому мы можем сказать:
«Пациент — это человек», «Сберегательный счет — это счет» и т. д. Из-за
этого отношение обобщения также неофициально называется «является
Отношения».
Обобщение принадлежит конкретному классификатору.
Обобщение показано в виде линии с полым треугольником в виде
стрелки
между
символами,
представляющими
задействованные
классификаторы (рис. 4.41.). Стрелка указывает на символ, представляющий
общий классификатор. Эта нотация называется «отдельным целевым
стилем».
93
Рис. 4.41. Текущие, сберегательные и кредитные счета обобщаются по
счету.
Отношения обобщения, которые ссылаются на один и тот же общий
классификатор, также могут быть связаны друг с другом в «общем целевом
стиле» (рис. 4.42.).
Рис. 4.42. Текущие, сберегательные и кредитные счета обобщаются по
счету.
Наследование.
В OOAD наследование обычно определяется как механизм, с
помощью которого более конкретные классы (называемые подклассами или
производными классами) включают структуру и поведение более общих
классов (называемых суперклассами или базовыми классами).
Наследование объяснялось в UML 1.4.2 с использованием концепций
полного дескриптора и дескриптора сегмента. Полный дескриптор
содержит описание всех атрибутов, ассоциаций, операций и ограничений,
содержащихся в объекте, и обычно является неявным, поскольку строится из
добавочных
сегментов,
объединенных
наследования.
94
вместе
с
использованием
В объектно-ориентированном языке описание объекта строится из
добавочных
сегментов,
объединяются
которые
использованием
с
наследования для создания полного дескриптора объекта. Сегменты — это
элементы моделирования, которые фактически объявлены в модели. Они
включают такие элементы, как класс и другие обобщаемые элементы.
Каждый обобщаемый элемент содержит список функций и других
отношений, которые он добавляет к тому, что он наследует от своих предков.
Каждый вид обобщаемого элемента имеет набор наследуемых
признаков. Для любого элемента модели они включают ограничения. Для
классификаторов к ним относятся признаки (атрибуты, операции, приемы
сигналов и методы) и участие в ассоциациях.
Если
элемент
обобщаемый
имеет
более
одного
родителя
(множественное наследование), то его полный дескриптор содержит
объединение признаков из его собственного дескриптора сегмента и
дескрипторов сегментов всех его предков.
Атрибуты в UML 1.4 нельзя было переопределить, но метод можно
было объявить более чем в одном подклассе. Метод, объявленный в любом
сегменте, заменяет метод с той же сигнатурой, объявленный в любом предке.
UML 2.4 и новейшие спецификации UML 2.5 не содержат определения
наследования. Спецификации UML 2.x говорят, что при обобщении
специализированный классификатор наследует
классификатора.
Кроме
того,
любое
черты
ограничение,
более
общего
применяемое
к
экземплярам общего классификатора, также применяется к экземплярам
конкретного классификатора.
UML 2.5 дает расплывчатое и неполное объяснение того, как работает
наследование в UML:
Когда классификатор обобщается, некоторые члены его обобщений
наследуются, то есть они ведут себя так, как если бы они были определены в
самом наследующем классификаторе. Например, унаследованный член,
который является атрибутом, имеет значение или набор значений в любом
95
экземпляре наследующего классификатора, а унаследованный член, который
является операцией, может быть вызван в экземпляре наследующего
классификатора.
Множественное наследование.
Множественное наследование неявно разрешено стандартом UML,
хотя стандарт не дает определения, что это такое.
Классификатор в UML может иметь ноль, одно или несколько
отношений обобщения к более общим классификаторам (рис. 4.43.). В OOAD
множественное наследование относится к способности класса наследовать
поведение и функции от более чем одного суперкласса.
Рис. 4.43. Множественное наследование для менеджера-консультанта и
постоянного менеджера — оба наследуют от двух классов
Происхождение множественного наследования может быть связано с
объединением ортогональных таксономий. Например, на приведенной выше
диаграмме объединены две разные классификации сотрудников: одна
основана на том, является ли сотрудник постоянным или временным, а
другая основана на занимаемой должности.
96
Хотя стандарт UML неявно разрешает множественное наследование,
он не предоставляет явных решений или рекомендаций для хорошо
известных проблем и неясностей, таких как проблема «алмаза» (рис. 4.44.).
Рис. 4.44. Пример проблемы с ромбом - кнопка наследует 2 реализации
equals()
В приведенном выше примере задачи множественного наследования
класс Button наследует две разные реализации equals(), хотя у него нет
собственной реализации операции. При вызове button.equals() неизвестно,
какая реализация — из Rectangle или из Clickable — будет использоваться.
Профили UML позволяют специализировать семантику обобщения.
Например, в профиле языка Java обобщение классов должно быть
ограничено одиночным наследованием.
Набор обобщений.
Набор обобщений — это пакетный элемент, который позволяет нам
определять
иерархии
классификации
путем
объединения
некоторых
обобщений конкретного общего классификатора в (под) множества. Каждый
набор
обобщения
также
может
быть связан с
называемым его типом мощности.
97
классификатором,
Каждый набор обобщения имеет два свойства — isCovering (полное
или
неполное
ограничение)
и
isDisjoint
(непересекающееся
или
перекрывающееся ограничение), чтобы уточнить, что это за набор.
Свойство isCovering набора обобщения указывает, является ли набор
конкретных классификаторов в этом наборе обобщения полным. Для
покрывающего ({complete}) набора обобщений каждый экземпляр общего
классификатора также является экземпляром (по крайней мере) одного из
конкретных классификаторов. Если набор не является покрывающим
({incomplete}), могут быть некоторые экземпляры общего классификатора,
нельзя
которые
классифицировать
какие-либо
как
конкретные
классификаторы из набора обобщения.
Свойство isDisjoint указывает, могут ли конкретные классификаторы
набора обобщения перекрываться. Набор обобщений, ограниченный как
{непересекающийся}, не имеет экземпляра какого-либо конкретного
классификатора, а также может быть экземпляром другого конкретного
классификатора (т. е. классификаторы не перекрываются). Если набор
обобщения
{overlapping},
некоторые
или
все
его
конкретные
классификаторы могут иметь общие экземпляры.
По умолчанию в UML 2.0 и UML 2.4.1 набор обобщений равен
{incomplete, disjoint}, тогда как в UML 2.5 значение по умолчанию было
изменено на {incomplete, перекрывающиеся}.
Набор
обобщения
может
быть
дополнительно
связан
с
классификатором, называемым его типом мощности. Экземпляры мощного
типа в этом случае могут рассматриваться как семантически эквивалентные
каждому из соответствующих специализированных классификаторов в
каждом
обобщения
в
наборе
обобщений.
Спецификация
UML
не
предписывает, как эта семантическая эквивалентность реализуется и как
поддерживается ее целостность.
98
На диаграмме ограничения набора обобщения размещены рядом с
наборами, рядом с общей стрелкой набора обобщения или рядом с
пунктирной линией для набора обобщения.
Спецификация типа мощности отображается в виде двоеточия, за
которым
следует
классификатора
имя
типа
мощности
рядом
с
соответствующим набором обобщений (рис. 4.45.).
Coverage
Type
coverage
policy
*
1
Health Insurance
Policy
л
д
(complete, overlapping}
:CoverageType
policy
plan
Insurance
1
Plan
*
(incomplete, disjoint)
JnsurancePlan
Job Based
Insurance
HMO Insurance
POS Insurance
Self Insurance
PPO Insurance
Benefits
Insurance
FFS Insurance
Рис. 4.45. Наборы обобщений полиса медицинского страхования — тип
покрытия является полным и перекрывающимся, в то время как план
страхования является неполным и непересекающимся.
Полный пример обобщения полиса медицинского страхования и
типов мощности можно найти в разделе 4 данной книги.
4.9.3. Зависимость в UML
Зависимость — это направленная связь, которая используется для
демонстрации того, что какой-либо элемент или набор элементов UML
требует, нуждается или зависит от других элементов модели для
спецификации или реализации. Из-за этого зависимость называется
99
отношениями поставщик - клиент, когда поставщик что-то предоставляет
клиенту, и, таким образом, клиент является в некотором смысле неполным,
хотя семантически или структурно зависит от элемента (элементов)
поставщика. Изменение поставщика может повлиять на элементы клиента.
Зависимость — это связь между именованными элементами, которая
в UML включает множество различных элементов, например, классы,
интерфейсы, компоненты, артефакты, пакеты и т.д. Существует
несколько видов зависимостей, показанных на диаграмме ниже (рис. 4.46.).
Рис. 4.46. Обзорная диаграмма отношения зависимости —
использование, абстракция, развертывание.
Использование — это зависимость, при которой один именованный
элемент (клиент) требует другого именованного элемента (поставщика) для
своего полного определения или реализации.
100
Абстракция связывает два элемента, представляющих одно и то же
понятие, но на разных уровнях абстракции.
Развертывание — это зависимость, которая показывает распределение
(развертывание) артефакта в цель развертывания. (Не очень понятно,
почему UML 2.4.1 определяет развертывание как зависимость, а не как
ассоциацию или просто направленную связь.)
Обратите внимание, что спецификация UML 2.4.1 содержит некоторое
сбивающее с толку разъяснение о том, что «наличие отношений зависимости
в модели не имеет никаких последствий семантики времени выполнения, все
это дается в терминах элементов модели, которые участвуют в
отношениях, а не в терминах. их экземпляров».
Это
уточнение
противоречит
определению
зависимости
от
использования, которая является зависимостью от реализации. Опытный
разработчик программного обеспечения знает, что происходит во время
выполнения, когда какая-то зависимость отсутствует, а приложение
уничтожается LinkageError или ClassNotFoundException из загрузчика
классов. Таким образом, зависимость может иметь серьезные последствия
семантики времени выполнения.
Зависимость обычно изображается пунктирной стрелкой, указывающей
от клиента (зависимого) в конце к поставщику (поставщику) в конце
стрелки. Стрелка может быть помечена необязательным стереотипом и
необязательным именем. Поскольку направление стрелки противоположно
тому, что мы обычно ожидаем, проще воспринимать это как стереотип, что
клиент «зависит от» поставщика (рис. 4.47.).
Рис. 4.47. Класс SearchController зависит от интерфейса SiteSearch
(данному классу требуется данный интерфейс).
101
В
течение
многих
лет
спецификации
UML
предоставляют
противоречивый пример зависимости, показанной ниже. Объяснение рисунка
7.38 спецификации UML 2.4.1 гласит: «В приведенном ниже примере класс
Car имеет зависимость от класса CarFactory. В этом случае зависимость
представляет собой экземпляр зависимости, где класс Car является
экземпляром класс CarFactory» (рис. 4.48.).
Рис. 4.48. Неправильно: класс Car зависит от класса CarFactory.
Справа: класс CarFactory зависит от класса Car.
Этот пример на самом деле показывает обратное тому, что утверждает
спецификация UML. CarFactory зависит от класса Car. Класс Car может быть
определен без знания класса CarFactory, но CarFactory требует Car для своего
определения, потому что он производит Cars. Также неправильно говорить,
что «... класс Car является экземпляром класса CarFactory». Класс Car
создается классом CarFactory.
Возможен набор элементов для клиента или поставщика. В этом случае
одна или несколько стрелок с концами на клиентах соединяются с концами
одной или нескольких стрелок с концами на поставщиках. При желании на
стыке можно поставить маленькую точку. В месте соединения следует
прикрепить примечание о зависимости.
Зависимость может использоваться на нескольких типах диаграмм UML:
•
диаграмма классов
•
схема составной структуры
•
схема пакета
•
диаграмма компонентов
•
схема развертывания
Вот несколько примеров зависимостей на рисунках 4.49. и 4.50.:
102
Рис. 4.49. Пакет Web Shopping использует (зависит от) пакет Payment.
Рис. 4.50. Интерфейс SiteSearch реализован (реализован) SearchService.
Обратите внимание, что зависимость от абстракции имеет соглашение
о более абстрактном элементе в качестве поставщика и более конкретном
элементе или элементе реализации в качестве клиента, но спецификация
UML также позволяет рисовать его противоположным образом (рис. 4.51.).
Рис. 4.51. Компонент UserService, реализованный UserServlet и UserDAO.
Применение.
Использование — это отношения зависимости, в которых один
элемент (клиент) требует другого элемента (или набора элементов)
(поставщика) для его полной реализации или работы.
Зависимость использования не указывает, как клиент использует
поставщика, кроме того факта, что поставщик используется определением
или реализацией клиента. Например, это может означать, что некоторые
методы в классе (клиент) используют объекты (например, параметры)
другого класса (поставщика).
103
Зависимость
использования
отображается
как
зависимость
с
прикрепленным к ней ключевым словом «использовать» (рис. 4.52.).
Рис. 4.52. Класс SearchController использует класс SearchEngine.
Создание.
Создание — это зависимость использования, означающая, что
классификатор клиента создает экземпляры классификатора поставщика.
Обозначается стандартным стереотипом «творить» (рис. 4.53.).
Рис. 4.53. Класс DataSource создает Connection.
Создать также может указать, что назначенный признак создает
экземпляр
классификатора,
к
которому
присоединен
признак.
Эта
зависимость может быть повышена до классификатора, содержащего
функцию.
Create может связать значение экземпляра с конструктором для класса,
описывая единственное значение, возвращаемое операцией конструктора.
Операция — это клиент, созданный экземпляр — поставщик. Значение
экземпляра может ссылаться на параметры, объявленные операцией (рис.
4.54.).
Рис. 4.54. Конструктор учетной записи создает новые экземпляры
учетной записи
Instantiate — это еще одна зависимость использования среди
классификаторов,
указывающая,
что
104
операции
на
клиенте
создают
экземпляры поставщика. Обозначается стандартным стереотипом «создавать
экземпляры».
Не очень понятно, почему в стандарте UML 2.4 есть и «создать», и
«создать экземпляр».
Вызов.
Call — это зависимость использования, которая указывает, что
исходная операция вызывает целевую операцию. Эта зависимость может
связывать исходную операцию с любой целевой операцией, находящейся в
области действия, включая, помимо прочего, операции включающего
классификатора и операции других видимых классификаторов.
Вызов обозначается стандартным стереотипом «вызов», источником и
целью которого является операция.
Это отношение также может быть применено к классу, содержащему
операцию, в том смысле, что в классе существует операция, к которой
применяется зависимость.
Send — это зависимость использования, источником которой
является операция, а целью — сигнал, указывающий, что источник
отправляет целевой сигнал.
Отправка обозначается стандартным стереотипом «отправить».
Требуемый интерфейс.
Требуемый интерфейс определяет сервисы, которые необходимы
классификатору для выполнения своих функций и выполнения собственных
обязательств перед своими клиентами. Он определяется зависимостью
использования
между
классификатором
и
соответствующим
интерфейсом.
Зависимость использования от классификатора к интерфейсу показана
путем представления интерфейса полукругом или сокетом, помеченным
именем интерфейса, прикрепленным сплошной линией к классификатору,
которому требуется этот интерфейс (рис. 4.55.).
105
SiteSearch
Search
Controller
—C
Рис. 4.55. Интерфейс SiteSearch используется (обязательно)
SearchController.
Если интерфейс представлен в виде прямоугольника, зависимость
использования
интерфейса
обозначается
стрелкой
зависимости.
Классификатор в конце стрелки использует (требует) интерфейс в начале
стрелки (рис. 4.56.).
Рис. 4.56. Интерфейс SiteSearch используется (обязательно)
SearchController.
106
5. UML ДИАГРАММА ОБЪЕКТОВ
5.1. Понятие UML диаграммы объектов
Диаграмму объектов можно рассматривать как диаграмму классов
уровня экземпляра, которая показывает экземплярные спецификации
классов и интерфейсов (объекты), слоты со спецификациями значений и
ссылки (экземпляры ассоциации).
Диаграмма объектов была определена в устаревшей спецификации
UML 1.4.2 как «граф экземпляров, включая объекты и значения данных.
Диаграмма статических объектов является экземпляром диаграммы
классов; она показывает моментальный снимок подробного состояния
системы в момент времени». В нем также говорилось, что диаграмма
объектов — это «диаграмма классов с объектами и без классов».
Спецификация UML 2.5 просто не дает определения диаграммы
объектов, за исключением того, что «следующие узлы и ребра обычно
рисуются в диаграмме объектов: спецификация экземпляра и ссылка (т. е.
ассоциация)».
Обратите внимание, что стандартная иерархия диаграмм UML 2.5 (см.
глава 2. классификация UML диаграмм) показывает диаграммы классов и
диаграммы объектов как совершенно не связанные между собой. Некоторые
другие
авторитетные
компонентов
и
источники
диаграммы
UML
заявляют,
развертывания,
что
диаграммы
содержащие
только
спецификации экземпляров, также являются особыми видами диаграмм
объектов.
В приведенном ниже обзоре диаграммы объектов на рисунке 5.1.
показаны
некоторые
основные
элементы
диаграммы
объектов
—
спецификации именованных и анонимных экземпляров для объектов,
слоты со спецификациями значений и ссылки (экземпляры ассоциации).
107
Рис. 5.1. Обзор диаграммы объектов — спецификации экземпляров,
спецификации значений, слоты и ссылки.
5.2. UML-объект
Во всех версиях UML от UML 1.x до UML 2.5 суть объекта одна и та
же:
Объект является экземпляром класса.
Глоссарий устаревшей спецификации UML 1.4.2 определил объект как
Сущность с четко определенными границами и идентичностью,
которая инкапсулирует состояние и поведение. Состояние представлено
атрибутами и отношениями, поведение представлено операциями, методами
и конечными автоматами. Объект является экземпляром класса.
Объект — это отдельная «вещь» с состоянием и отношениями с
другими объектами. Состояние объекта идентифицирует значения для этого
объекта свойств классификатора объекта.
108
Класс можно смоделировать как активный, что означает, что
экземпляр класса имеет некоторое автономное поведение.
Хотя объект является базовой концепцией UML, для него не
существует соответствующего элемента UML. Объекты визуализируются как
спецификации экземпляров, обычно на диаграммах объектов. Итак, когда
мы видим экземпляр класса, мы можем назвать его объектом (рис. 5.2.).
:Customer
Рис. 5.2. Экземпляр класса Customer без имени, анонимный объект.
В некоторых случаях класс экземпляра либо неизвестен, либо не указан
(рис. 5.3.).
newPatient:
Рис. 5.3. Экземпляр с именем newPatient некоторого безымянного или
неизвестного класса
Если имя экземпляра также не указано, нотация для такого анонимного
экземпляра
безымянного
классификатора
представляет собой
просто
подчеркнутое двоеточие - :_.
Объект может иметь всё: имя экземпляра, класс и пространство имен
(пакет) (рис. 5.4.).
front-facing-cam:
android.hardware­
camera
Рис. 5.4. Объект front-facing-cam класса Camera из пакета
android.hardware.
109
Если экземпляр имеет некоторое значение, спецификация значения
может быть показана либо после знака равенства ('=') после имени
экземпляра, либо под именем без знака равенства (рис. 5.5.).
Рис. 5.5. Экземпляр orderPaid класса Date имеет значение 31 июля 2011
г., 15:00.
Слоты объекта показаны как структурные элементы с именем
элемента, за которым следует знак равенства ('=') и спецификация значения
(рис. 5.6.). Также может быть показан тип (классификатор) признака.
Рис. 5.6. Экземпляр newPatient класса Patient имеет слоты с указанными
значениями.
5.3. Слот
Слот — это элемент UML, указывающий, что экземпляр имеет
значение
или
значения
для
определенного
структурного
элемента.
Спецификация UML также говорит, что слот дает значение или значения
структурной особенности экземпляра. Экземпляр может иметь один слот для
каждого
структурного
признака
своих
классификаторов,
включая
унаследованные признаки.
В программировании мы бы назвали этот вид отображения слотами
памяти или хранилищем. Говоря простым языком, атрибуты классификатора
хранятся в слотах классификатора.
110
Когда создается экземпляр классификатора, каждое нестатическое
свойство становится частью состояния этого экземпляра и реализуется путем
некоторого сопоставления имени свойства с определенным значением или
значениями, из которых состоит состояние экземпляра. Значения каждого
свойства имеют определенный тип и размещаются в слотах экземпляра или
связаны с этим экземпляром (рис. 5.7.).
Рис. 5.7. Экземпляр newPatient класса Patient имеет слоты с указанными
значениями.
5.4. Ссылка
Ссылка является экземпляром ассоциации. Это кортеж с одним
значением для каждого конца ассоциации, где каждое значение является
экземпляром типа конца. Ассоциация имеет как минимум два конца,
представленных свойствами (end properties).
Ссылка отображается с использованием тех же обозначений, что и для
ассоциации. Сплошная линия соединяет экземпляры, а не классификаторы.
Название ссылки может быть показано подчеркнутым, хотя это не
обязательно. Могут отображаться конечные имена (роли) и стрелки
навигации (рис. 5.8.).
Рис. 5.8. Ссылка, написанная между экземпляром р:Профессора,
играющего роль автора и экземпляром Ь:Книги, играющей роль
учебника.
111
6. UML ДИАГРАММА ПАКЕТОВ
6.1. Понятие UML диаграммы пакетов
Диаграмма пакетов — это структурная диаграмма UML, которая
показывает пакеты и зависимости между пакетами.
Диаграммы моделей позволяют показать различные виды системы,
например, как многоуровневое (иначе многоуровневое) приложение —
модель многоуровневого приложения.
На диаграмме пакетов обычно рисуются следующие узлы и ребра:
пакет, пакетируемый элемент, зависимость, импорт элемента, импорт
пакета, объединение пакетов.
6.2. Схема UML диаграммы пакетов
Некоторые основные элементы диаграммы упаковки показаны на
рисунке ниже (рис. 6.1.). Пакеты «Покупки через Интернет», «Покупки с
мобильных устройств», «Покупки по телефону» и «Покупки по почте»
объединяют пакет «Корзина покупок». Те же 4 пакета используют
Платежный пакет. Пакеты «Оплата» и «Корзина» импортируют другие
пакеты.
112
Рис. 6.1. Элементы UML диаграммы пакетов — пакет, импорт, доступ,
использование, слияние.
6.3. Пакеты
6.3.1. Понятие пакета
Пакет — это пространство имен, используемое для группировки
элементов, которые семантически связаны и могут меняться вместе. Это
механизм общего назначения для организации элементов в группы для
обеспечения лучшей структуры модели системы.
Все члены пакета, принадлежащие ему, должны быть пакетируемыми
элементами. Если пакет удаляется из модели, то удаляются и все элементы,
принадлежащие пакету. Пакет сам по себе является упаковываемым
элементом, поэтому любой пакет может быть также членом других пакетов.
Поскольку пакет является пространством имен, элементы родственного
или одного типа должны иметь уникальные имена внутри окружающего
пакета. Разные типы элементов могут иметь одно и то же имя.
113
В качестве пространства имен пакет может импортировать либо
отдельных членов других пакетов, либо всех членов других пакетов. Пакет
также может быть объединен с другими пакетами.
Пакет отображается как папка с вкладками — прямоугольник с
небольшой вкладкой, прикрепленной к левой стороне верхней части
прямоугольника. Если члены пакета не показаны внутри прямоугольника
пакета, то имя пакета должно быть помещено внутри (рис. 6.2.).
org.hibernate
Рис. 6.2. Пакет org.hibernate.
Члены пакета могут быть показаны в границах пакета. В этом случае
название пакета должно быть размещено на вкладке (рис. 6.3.).
Рис. 6.3. Пакет org.hibernate содержит SessionFactory и Session.
Диаграмма, показывающая пакет с содержимым, может отображать
только подмножество содержащихся элементов в соответствии с некоторым
критерием.
Члены пакета могут быть показаны вне пакета с помощью ответвлений
от пакета к членам. Знак плюс (+) внутри круга рисуется в конце,
прикрепленном к пространству имен (пакету). Это обозначение для пакетов
семантически эквивалентно композиции (которая показана сплошным
ромбом) (рис. 6.4.).
114
Рис. 6.4. Пакет org.hibernate содержит интерфейсы SessionFactory и
Session.
Элементы, на которые можно ссылаться внутри пакета, используя
неполные имена:
•
принадлежащие элементы,
•
импортные элементы и
•
элементы во вложенных (внешних) пространствах имен.
Собственные и импортированные элементы могут иметь видимость,
которая определяет, доступны ли они вне пакета.
Если элемент, принадлежащий пакету, имеет видимость, это может
быть только общедоступная или частная видимость. Защищенная или
пакетная видимость не допускается. Доступность элемента пакета может
быть обозначена символом видимости перед именем элемента ("+" для
общедоступного и "-" для частного) (рис. 6.5.).
Library Domain
+ Catalog
+ Patron
+ Librarian
- Account
Рис. 6.5. Все элементы пакета Library Domain являются
общедоступными, кроме учетной записи.
Общедоступные элементы пакета всегда доступны за пределами пакета
благодаря использованию полных имен.
115
6.3.2. Атрибут URI пакета
Пакет
имеет
атрибут
необязательный
URI,
который
служит
уникальным идентификатором пакета. Этот атрибут был введен в UML 2.4
в основном для поддержки обмена профилями с использованием XMI.
Обратите внимание, что спецификация UML 2.4 требует, чтобы этот
атрибут URI соответствовал правилам и синтаксису спецификации IETF URI
RFC 2396 в то время как более поздняя версия синтаксиса URI RFC 3986
(выпущенная в 2005 г.) сделала RFC 2396 устаревшим.
Оба RFC позволяют URI быть унифицированными указателями
ресурсов (URL), унифицированными именами ресурсов (URN) или и тем, и
другим. Хотя URN фактически определяет идентификатор элемента
(уникальный идентификатор), а URL-адрес предоставляет метод для его
поиска, очень часто и иногда сбивает с толку то, что URL-адреса служат в
качестве URN.
Вот несколько примеров атрибута URI пакета в виде URL. Обратите
внимание, что использование схемы «http://» часто не связано с протоколом
HTTP, и фактический ресурс не находится в этом месте. URL просто
используется как замена уникального идентификатора:
•
http://www. ietf.org/rfc/rfc2396.txt
•
http://www.omg.org/spec/UML/20100901/PrimitiveTypes.xmi
•
http://www.uml-diagrams.org/profiles/20110410/EJB-30.xmi
Но
поскольку
некоторые предпочитают
URN
идентификатора
был
вместо этого использовать URN,
разработан
(уникального
специально
идентификатора)
и
для
определения
не
подразумевает
доступность идентифицированного ресурса (например, для устаревших
ресурсов):
•
urn: ietf: rfc: 3986
•
urn: oasis: names: спецификация :docbook: dtd:xml:4.1.2
•
urn: схемы-Microsoft-com: XML-данные
•
urn:uml-diagrams-org:profiles:20110410:EJB-3 0
116
Атрибут URI пакета может отображаться в форме {uri=<uri>} после
имени пакета (рис. 6.6.).
Рис. 6.6. Профиль EJB показан как пакет с атрибутом URI.
6.3.3. Шаблон пакета
Пакет можно использовать как шаблон для других пакетов. Обратите
внимание, что [Спецификация UML 2.4.1] непоследовательно называет его и
шаблоном пакета, и шаблоном пакета.
Упаковываемый элемент можно использовать в качестве параметра
шаблона. Параметр шаблона пакета может ссылаться на любой элемент,
принадлежащий шаблону пакета или используемый им, или шаблоны,
вложенные в него.
Пакет может быть привязан к одному или нескольким пакетам
шаблонов. Когда применяется несколько привязок, результат привязок
создается путем взятия промежуточных результатов и их объединения в
комбинированный результат с использованием слияния пакетов (рис. 6.7.).
117
Рис. 6.7. Шаблон пакета Service Provider и связанный пакет Scheduler
Service.
6.3.4. Упаковываемый элемент
Упаковываемый элемент — это именованный элемент, которым
может непосредственно владеть пакет.
Некоторые примеры пакетируемых элементов:
•
Тип
•
Классификатор (--> Тип)
•
Класс (--> Классификатор)
•
Вариант использования (--> Классификатор)
•
Компонент (--> Классификатор)
•
Упаковка
•
Ограничение
•
Зависимость
•
Событие
118
Упаковываемый элемент сам по себе не имеет обозначений.
6.4. Объединение пакетов UML
Слияние пакетов — это направленная связь между двумя пакетами,
указывающая, что содержимое одного пакета расширяется за счет
содержимого другого пакета.
Слияние пакетов похоже на обобщение в том смысле, что исходный
элемент концептуально добавляет характеристики целевого элемента к своим
собственным характеристикам, в результате чего получается элемент,
сочетающий характеристики обоих.
Слияние пакетов можно рассматривать как операцию, которая берет
содержимое двух пакетов и создает новый пакет, объединяющий содержимое
пакетов, участвующих в слиянии.
Этот механизм следует использовать, когда элементы, определенные в
разных
пакетах,
имеют одинаковые
имена
и
предназначены
для
представления одной и той же концепции. Чаще всего его используют для
предоставления разных определений данного понятия для разных целей,
исходя из общего базового определения.
Данная базовая концепция расширяется поэтапно, причем каждое
приращение определяется в отдельном объединенном пакете. Выбирая, какие
приращения объединять, можно получить пользовательское определение
концепции для конкретной цели.
Слияние пакетов особенно полезно при метамоделировании и широко
используется при определении метамодели UML.
Объединение пакетов показано с помощью пунктирной линии с
открытой стрелкой, указывающей от принимающего пакета к объединенному
пакету (рис. 6.8.). Ключевое слово «слияние» показано рядом со штриховой
линией.
119
Рис. 6.8. Пакеты ядра и профиля объединяют пакет Constructs, который
импортирует примитивные типы.
6.5. Импорт пакета UML
Импорт пакета — это направленная связь между импортируемым
пространством имени, импортируемым пакетом,
которая позволяет
использовать неполные имена для ссылки на членов пакета из другого
пространства имен.
При импорте пространства имен имена членов импортируемого пакета
добавляются в собственное пространство имен. Концептуально импорт
пакета эквивалентен импорту элемента для каждого отдельного члена
импортированного пространства имен, если только не существует отдельно
определенного импорта элемента.
Импорт пакета показан пунктирной стрелкой с открытой стрелкой от
пространства имен импорта к импортируемому пакету (рис. 6.9.).
Рис. 6.9. WebApplication импортирует пакет Presentation.
120
Обратите внимание, что, хотя это выглядит точно так же, как
отношения зависимости и использования, это совершенно отдельные
направленные отношения.
Видимость импорта пакета может быть общедоступной или частной.
Если импорт пакета является общедоступным, импортированные элементы
будут добавлены в пространство имен и станут видимыми за пределами
пространства имен, в то время как, если он является частным, они все равно
будут добавлены в пространство имен, но не будут видны снаружи.
Рядом с пунктирной стрелкой показано ключевое слово, указывающее,
какой тип импорта пакета предполагается (рис. 6.10.). Предопределенные
ключевые слова: «импорт» для импорта общедоступных пакетов и «доступ»
для импорта частных пакетов. По умолчанию значение видимости является
общедоступным.
Рис. 6.10. Частный импорт пакета презентации и публичный импорт
пакета домена
В качестве альтернативы пунктирной стрелке можно показать импорт
пакета
с
помощью
текста,
который
однозначно
идентифицирует
импортированный пакет в фигурных скобках либо под, либо после имени
пространства имен. Синтаксис в этом случае можно описать так (обратите
внимание, это моя модифицированная версия синтаксиса):
package-import ::= '{' ( 'import' | 'access' ) qualified-name '}'
121
Элементы, которые становятся доступными для использования в
импортирующем пакете посредством импорта пакета, могут иметь особый
цвет или быть затемнены, чтобы указать, что их нельзя изменить.
6.6. Зависимость в UML
Зависимость — это направленная связь, которая используется для
демонстрации того, что какой-либо элемент или набор элементов UML
требует, нуждается или зависит от других элементов модели для
спецификации или реализации. Из-за этого зависимость называется
отношениями поставщик - клиент, когда поставщик что-то предоставляет
клиенту, и, таким образом, клиент является в некотором смысле неполным,
хотя семантически или структурно зависит от элемента (элементов)
поставщика. Изменение поставщика может повлиять на элементы клиента.
Зависимость — это связь между именованными элементами, которая
в UML включает множество различных элементов, например, классы,
интерфейсы, компоненты, артефакты, пакеты и т. д. Существует
несколько видов зависимостей, показанных на диаграмме ниже (рис. 6.11.).
122
Рис. 6.11. Обзорная диаграмма отношения зависимости —
использование, абстракция, развертывание.
Использование — это зависимость, при которой один именованный
элемент (клиент) требует другого именованного элемента (поставщика) для
своего полного определения или реализации.
Абстракция связывает два элемента, представляющих одно и то же
понятие, но на разных уровнях абстракции.
Развертывание — это зависимость, которая показывает распределение
(развертывание) артефакта в цель развертывания. (Не очень понятно,
почему UML 2.4.1 определяет развертывание как зависимость, а не как
ассоциацию или просто направленную связь)
Обратите внимание, что спецификация UML 2.4.1 содержит некоторое
сбивающее с толку разъяснение о том, что «наличие отношений зависимости
в модели не имеет никаких последствий семантики времени выполнения, все
123
это дается в терминах элементов модели, которые участвуют в
отношениях, а не в терминах их экземпляров».
Это
уточнение
противоречит
определению
зависимости
от
использования, которая является зависимостью от реализации. Опытный
разработчик программного обеспечения знает, что происходит во время
выполнения, когда какая-то зависимость отсутствует, а приложение
уничтожается LinkageError или ClassNotFoundException из загрузчика
классов. Таким образом, зависимость может иметь серьезные последствия
семантики времени выполнения.
Зависимость обычно изображается пунктирной стрелкой, указывающей
от клиента (зависимого) в конце к поставщику (поставщику) в конце
стрелки. Стрелка может быть помечена необязательным стереотипом и
необязательным именем. Поскольку направление стрелки противоположно
тому, что мы обычно ожидаем, стоит воспринимать это как стереотип, что
клиент «зависит от» поставщика (рис. 6.12.).
Рис. 6.12. Класс SearchController зависит (требуется) от интерфейса
SiteSearch.
В
течение
многих
лет
спецификации
UML
предоставляют
противоречивый пример зависимости, показанной ниже. Объяснение рисунка
7.38 спецификации UML 2.4.1 гласит: «В приведенном ниже примере класс
Car имеет зависимость от класса CarFactory (рис. 6.13.). В этом случае
зависимость представляет собой экземпляр зависимости, где класс Car
является экземпляром класс CarFactory».
Рис. 6.13. Неправильно: класс Car зависит от класса CarFactory.
Справа: класс CarFactory зависит от класса Car.
124
Этот пример на самом деле показывает обратное тому, что утверждает
спецификация UML. CarFactory зависит от класса Car. Класс Car может быть
определен без знания класса CarFactory, но CarFactory требует Car для своего
определения, потому что он производит Cars. Также неправильно говорить,
что «... класс Car является экземпляром класса CarFactory». Класс Car
создается классом CarFactory .
Возможен набор элементов для клиента или поставщика. В этом случае
одна или несколько стрелок с концами на клиентах соединяются с концами
одной или нескольких стрелок с концами на поставщиках. При желании на
стыке можно поставить маленькую точку. В месте соединения следует
прикрепить примечание о зависимости.
Зависимость может использоваться на нескольких типах диаграмм
UML:
•
диаграмма классов
•
схема составной структуры
•
схема пакета
•
диаграмма компонентов
•
схема развертывания
Вот несколько примеров зависимостей на рисунках 6.14. и 6.15.:
Web
Shopping
«use»
----------------- >
Payment
Рис. 6.14. Пакет Web Shopping использует (зависит от) пакет Payment.
Рис. 6.15. Интерфейс SiteSearch реализован (реализован) SearchService.
125
Обратите внимание, что зависимость от абстракции имеет соглашение
о более абстрактном элементе в качестве поставщика и более конкретном
элементе или элементе реализации в качестве клиента, но спецификация
UML также позволяет рисовать его противоположным образом (рис. 6.16.).
Рис. 6.16. Компонент UserService, реализованный UserServlet и UserDAO.
Применение.
Использование — это отношения зависимости, в которых один
элемент (клиент) требует другого элемента (или набора элементов)
(поставщика) для его полной реализации или работы.
Зависимость использования не указывает, как клиент использует
поставщика, кроме того факта, что поставщик используется определением
или реализацией клиента. Например, это может означать, что некоторые
методы в классе (клиент) используют объекты (например, параметры)
другого класса (поставщика).
Зависимость
использования
отображается
как
зависимость
прикрепленным к ней ключевым словом «использовать» (рис. 6.17.).
Рис. 6.17. Класс SearchController использует класс SearchEngine.
Создание.
126
с
Создание — это зависимость использования, означающая, что
классификатор клиента создает экземпляры классификатора поставщика.
Обозначается стандартным стереотипом «create» (рис. 6.18.).
Рис. 6.18. Класс DataSource создает Connection.
Создать также может указать, что назначенный признак создает
экземпляр
классификатора,
к
которому
присоединен
признак.
Эта
зависимость может быть повышена до классификатора, содержащего
функцию.
Create может связать значение экземпляра с конструктором для класса,
описывая единственное значение, возвращаемое операцией конструктора.
Операция — это клиент, созданный экземпляр — поставщик. Значение
экземпляра может ссылаться на параметры, объявленные операцией (рис.
6.19.).
Рис. 6.19. Конструктор учетной записи создает новые экземпляры
учетной записи
Instantiate — это еще одна зависимость использования среди
классификаторов,
указывающая,
что
операции
на
клиенте
создают
экземпляры поставщика. Обозначается стандартным стереотипом «создавать
экземпляры».
Не очень понятно, почему в стандарте UML 2.4 есть и «создать», и
«создать экземпляр».
Вызов.
Call — это зависимость использования, которая указывает, что
исходная операция вызывает целевую операцию. Эта зависимость может
127
связывать исходную операцию с любой целевой операцией, находящейся в
области действия, включая, помимо прочего, операции включающего
классификатора и операции других видимых классификаторов.
Вызов обозначается стандартным стереотипом «вызов», источником и
целью которого является операция.
Это отношение также может быть применено к классу, содержащему
операцию, в том смысле, что в классе существует операция, к которой
применяется зависимость.
Send — это зависимость использования, источником которой
является операция, а целью — сигнал, указывающий, что источник
отправляет целевой сигнал.
Отправка обозначается стандартным стереотипом «отправить».
Требуемый интерфейс.
Требуемый интерфейс определяет сервисы, которые необходимы
классификатору для выполнения своих функций и выполнения собственных
обязательств перед своими клиентами. Он определяется зависимостью
использования
между
классификатором
и
соответствующим
интерфейсом.
Зависимость использования от классификатора к интерфейсу показана
путем представления интерфейса полукругом или сокетом, помеченным
именем интерфейса, прикрепленным сплошной линией к классификатору,
которому требуется этот интерфейс (рис. 6.20).
SlteSearch
—c
Search
Controller
Рис. 6.20. Интерфейс SiteSearch используется (обязательно)
SearchController.
Если интерфейс представлен в виде прямоугольника, зависимость
использования
интерфейса
обозначается
128
стрелкой
зависимости.
Классификатор в конце стрелки использует (требует) интерфейс в начале
стрелки (рис. 6.21.).
Рис. 6.21. Интерфейс SiteSearch используется (обязательно)
SearchController.
129
7. UML ДИАГРАММА МОДЕЛИ
7.1. Понятие UML диаграммы модели
Диаграмма модели — это вспомогательная структурная диаграмма
UML,
которая
показывает
некоторую
абстракцию
или
конкретное
представление системы для описания архитектурных, логических или
поведенческих аспектов системы. Это могло бы показать, например,
архитектуру многоуровневого (он же multi-tiered) приложения — модель
многоуровневого приложения.
7.2. Схема UML диаграммы модели
Диаграмма модели — это вспомогательная структурная диаграмма
UML,
которая
показывает
некоторую
абстракцию
или
конкретное
представление системы для описания некоторых архитектурных, логических
или поведенческих аспектов системы.
На приведенном ниже рисунке 7.1. показаны некоторые основные
элементы
схемы
модели.
приложение
Многоуровневое
—
это
«контейнерная» модель, которая содержит три другие модели — уровень
представления,
бизнес-уровень
и
уровень
данных.
содержащимися моделями определены зависимости.
130
Между
этими
Рис. 7.1. Элементы UML диаграммы модели - модель, пакет,
зависимость.
Модели обычно содержат пакеты. Пакеты могут иметь зависимости
или другие отношения, например, import, определенные между ними.
7.3. UML- модель
Модель — это специализированный пакет UML, описывающий
систему с определенной точки зрения, точки зрения. Точка обзора может
также относиться к определению профиля. Модели используются для
построения диаграмм моделей.
UML 2.5 не очень последовательно определяет объем модели,
системы. В одном месте говорится, что модель фиксирует представление о
131
физической системе, а в другом - эта система понимается в самом широком
смысле и может включать не только программное и аппаратное
обеспечение, но и организации и процессы.
Представление определяется как некоторая абстракция системы,
включающая только те аспекты системы, которые имеют отношение к цели
модели,
описывающие
сторон
заинтересованных
заинтересованных
эти
сторон
аспекты
для
или
определенной
и
в
с
определенной
соответствующих
категории
точки
зрения
случаях.
уровень
детализации.
Это означает, что для одной и той же системы могут быть
предоставлены разные модели, причем каждая модель представляет систему
с разных точек зрения или на другом уровне абстракции.
UML 2.5 нечетко определяет заинтересованные стороны «на
примере»,
например,
проектировщиков,
пользователей или клиентов
системы.
Заинтересованная сторона (в контексте программных проектов или
систем) может быть определена как лицо, группа или организация внутри,
или вне проекта или системы, спонсирующая или проявляющая интерес к
проекту или оказывающая положительное, или отрицательное влияние на
проект.
Примеры заинтересованных сторон включают клиентов, группы
пользователей, высшее руководство, владельцев продуктов, руководителей
проектов, команды разработчиков, инженеров по качеству программного
обеспечения и т. д.
Спецификация
UML
2.5
также
несовместима
между
своими
намерениями и примерами, объясняющими модели. Хотя в нем говорится,
что модель является полной в том смысле, что она охватывает всю
132
систему, приведенный пример показывает модели, представляющие части
(уровни) системы.
Модель содержит иерархический набор элементов, которые вместе
описывают систему.
может содержать
Он также
набор
элементов,
представляющих среду системы, обычно действующих лиц, вместе с их
отношениями. Поскольку они являются внешними по отношению к системе,
они могут быть собраны вне иерархии в отдельные пакеты. Эти внешние
элементы и элементы, представляющие систему, могут быть связаны друг с
другом.
Модель обозначена обычным символом пакета (иконка папки) с
маленьким треугольником в правом верхнем углу большого прямоугольника
(рис. 7.2.).
I
Business A
Layer
Рис. 7.2. Модель бизнес-уровня
Если
содержимое
отображается
модели
внутри
большого
прямоугольника, справа от названия модели на вкладке может быть
нарисован треугольник (рис. 7.3.).
Services Layer Д
Message
Types
Service
Interfaces
Рис. 7.3. Модель сервисного уровня содержит сервисные интерфейсы и
типы сообщений.
133
Модель может быть обозначена как пакет с ключевым словом
«модель», расположенным над названием модели (рис. 7.4.).
Рис. 7.4. Стереотипная модель Layered Service.
Вы
можете
увидеть
пример
схемы
модели
многоуровневого
приложения на основе Руководства по архитектуре приложений Microsoft, 2­
е изд. В разделе 4 данной книги.
7.4. UML профиль
Профиль — это пакет профилей, который расширяет эталонную
метамодель (например, UML), позволяя адаптировать или настраивать
метамодель с помощью конструкций, специфичных для конкретной области,
платформы или метода разработки программного обеспечения. Другими
словами, профиль — это облегченный механизм расширения стандарта UML.
Профиль
вводит
несколько
ограничений
на
обычное
метамоделирование посредством использования метаклассов, определенных
в этом пакете. Основной конструкцией расширения является стереотип,
который определяется как часть профиля и расширяет некоторый метакласс.
Профиль — это ограниченная форма эталонной метамодели, которая
всегда должна быть связана с некоторой эталонной метамоделью, созданной
из, например, MOF, UML или CWM. Невозможно определить автономный
профиль без его эталонной метамодели.
134
Профиль использует ту же нотацию, что и пакет, с добавлением того,
что ключевое слово «профиль» отображается перед или над именем пакетма
(рис. 7.5.).
«profile»
EJB
Рис. 7.5. Профиль EJB
Профиль может определять классы, стереотипы, типы данных,
примитивные типы, перечисления (рис. 7.6.).
Рис. 7.6. Серверы профилей
Один профиль может повторно использовать некоторые или все части
другого профиля для расширения уже существующих профилей. К одной и
той же модели можно применить несколько профилей.
Ограничения, являющиеся частью профиля, оцениваются,
когда
профиль применяется к пакету. Эти ограничения должны быть соблюдены,
чтобы модель была корректной.
Пакет, начиная с UML 2.4, имеет необязательный атрибут URI,
который служит уникальным идентификатором пакета. Профиль — это
135
пакет, а атрибут URI был введен в основном для поддержки обмена
профилями с использованием XMI.
Атрибут URI профиля может отображаться в форме {uri= uri} после
имени профиля. Нормативные профили OMG следуют нормативной схеме
именования OMG для URI. Для нестандартных пользовательских профилей
соглашение, рекомендованное OMG, выглядит так:
uri::=
Ьмр://к11ал.ш1)11Ц11рова1111ый-род11телъ-проф11лъ
/версия-профил.я
/имя-
профиля..хпи
•
квалифицированный-профиль-родитель — это полное имя пакета,
содержащего профиль (если есть), с заменой «::» на «/» (прямая косая
черта) и удалением всех других недопустимых символов XML QName.
Например:www. uml-диаграммы. орг/ профили.
•
profile-version — это идентификатор версии профиля. Нормативные
профили OMG используют для этого дату в формате ГГГГММДД,
например:20110331.
•
имя-профиля — это имя профиля, которое должно содержать только
допустимые символы XML QName. Например: ejb-30.
Обратите внимание, что спецификация UML здесь смешала две разные
спецификации. Все значение URI должно соответствовать устаревшей
спецификации URI RFC 2396 (см. Атрибут пакета URI), в то время как
часть Qualified-profile-parent также должна быть (или будет сделана)
допустимым
XML
QName.
XML
QName
обычно
имеет
префикс
пространства имен, за которым следует ':', например, 'taxes:dependent', что
противоречит требованию URI (рис. 7.7.).
136
Рис. 7.7. Профиль EJB показан как пакет с атрибутом URI.
7.5. UML-стереотип
7.5.1. Понятие UML-стереотипа
Стереотип—
это
класс
профиля,
который
определяет,
как
существующий метакласс может быть расширен как часть профиля. Он
позволяет использовать специфичную для платформы или предметной
области терминологию или обозначения вместо или в дополнение к тем,
которые используются для расширенного метакласса.
Стереотип не может использоваться сам по себе, но всегда должен
использоваться с одним из метаклассов, которые он расширяет. Стереотип
не может быть расширен другим стереотипом.
Стереотип использует ту же нотацию, что и класс, с ключевым словом
«стереотип», показанным до или над названием стереотипа. Имена
стереотипов не должны конфликтовать с именами ключевых слов для
элемента расширенной модели (рис. 7.8.).
Рис. 7.8. Стереотип Servletа расширяет компонент.
137
Стереотип может изменить графический вид элемента расширенной
модели с помощью прикрепленных значков, представленных классом
профиля изображения (рис. 7.9. и 7.10).
Рис. 7.9. Стереотипный Servlet с прикрепленным пользовательским
значком.
Рис. 7.10. Актер расширен стереотипным веб-клиентом с
прикрепленным пользовательским значком.
Поскольку стереотип — это класс, он может иметь свойства. Свойства
стереотипа называются определениями тегов. Когда стереотип применяется
к
элементу
модели,
значения
свойств
значениями (рис. 7.11.).
138
называются
помеченными
Рис. 7.11. Устройство расширено стереотипом сервера с определениями
тегов и пользовательским значком.
7.5.2. Применение стереотипов
Диаграмма профиля используется для демонстрации определения
стереотипа. Стереотип применяется, когда он используется на диаграммах
вариантов использования, диаграммах классов, диаграммах развертывания и
т. д.
Когда стереотип
применяется
к
элементу
модели,
экземпляр
стереотипа связывается с экземпляром метакласса. Название применяемого
стереотипа отображается в паре кайр выше или перед названием элемента
модели.
Версии UML до
2.4
требовали,
чтобы
первая
буква
имени
применяемого стереотипа была в нижнем регистре (например, «Servlet»).
Начиная с UML 2.4, первая буква обычно должна быть в верхнем регистре
(рис. 7.12.). Именование приложений-стереотипов строчными буквами, где
сами стереотипы определяются с использованием прописной первой буквы,
все еще допустимо, но считается устаревшим.
«Servlet»
SearchServlet
Рис. 7.12. Стереотип «Servlet» применительно к элементу модели
SearchServlet
139
Если к одному и тому же элементу применяется несколько
стереотипов, имена примененных стереотипов отображаются в виде списка,
разделенного запятыми, внутри пары кайр.
Когда в расширенном элементе модели есть ключевое слово, то имя
стереотипа может отображаться рядом с ключевым словом, внутри
отдельных кайм (пример: «устройство» «сервер»).
Когда стереотип включает в себя определение значка, этот значок
может быть графически прикреплен к элементам модели, расширяемым
стереотипом.
Каждый
модели,
элемент
имеющий
графическое
представление, может иметь прикрепленную иконку. Когда элемент модели
расширен одним единственным стереотипом, значок может быть представлен
в уменьшенной форме внутри и сверху поля, представляющего элемент
модели (рис. 7.13.).
ю
SearchServlet
Рис. 7.13. Стереотип Servlet применен к классу SearchServlet.
При применении стереотипа весь блок классификатора может быть
заменен увеличенной иконкой стереотипа (рис. 7.14.).
SearchServlet
Рис. 7.14. Стереотип Servlet применен к классу SearchServlet.
Некоторые
элементы
модели
уже
используют
значок
для
представления по умолчанию. Типичным примером этого является элемент
модели актера, в котором используется значок «человечек». В этом случае,
когда элемент модели расширяется стереотипом со значком, значок
стереотипа заменяет значок представления по умолчанию на диаграммах
(рис. 7.15 и 7.16.).
140
«Web Client»
Geek
Рис. 7.15. Стереотип «веб-клиент» применительно к актеру-гику.
•—
«Computer»
Vendor = "Acer"
CPU = "AMD Phenom X4"
Memory = “4 GB DDR2"
У
Рис. 7.16. Стереотип компьютера с тегами, примененными к классу
устройств.
7.5.2. Стереотипные отношения
Стереотип всегда должен использоваться в сочетании с одним из
метаклассов, которые он расширяет. Метакласс может быть расширен
одним или несколькими стереотипами. Каждый стереотип может расширять
один или несколько метаклассов.
Стереотипы
могут
участвовать
в
бинарных
ассоциациях.
Противоположный класс может быть другим стереотипом, нестереотипным
классом, принадлежащим профилю или метаклассу. Стереотип должен
иметь свойство в конце ассоциации, чтобы иметь возможность перейти к
противоположному классу. Если противоположный конец не является
стереотипом, противоположное свойство должно принадлежать самой
ассоциации.
Стереотип может обобщать или специализировать только другой
стереотип (рис. 7.17.).
141
Рис. 7.17. Объект Session EJB с абстрактным стереотипом
специализируется на стереотипах Stateless EJB и Stateful EJB.
7.5.2. Определение тега
Свойства
стереотипа
называются
определениями
тегов
(или
метасвойствами) (рис. 7.18.).
Рис. 7.18. Стереотип Компьютер с определениями тегов для
производителя, ЦП и памяти
Помеченное значение. Стереотип применяется, когда он используется на
диаграммах вариантов использования, диаграммах классов, диаграммах
развертывания и т. д.
Когда стереотип применяется к элементу модели, значения его свойств
могут называться тегированными значениями.
В UML 1.x теговое значение определяется как один из механизмов
расширения UML, позволяющий прикреплять к моделям произвольную
информацию (которая не может быть выражена с помощью UML). Теговое
142
значение — это пара ключевое слово-значение, которую можно прикрепить к
любому элементу модели.
Ключевое
слово
называется
тегом.
Каждый
тег
представляет
определенный тип свойства, применимый к одному или нескольким типам
элементов модели. И тег, и значение обычно кодируются как строки, хотя
инструмент UML позволяет использовать другие типы данных для значений.
Спецификация
тегового
значения
в
UML
1.x
имеет
вид
имя = значение, где имя — это имя тега или атрибута метамодели, а
значение — произвольная строка, обозначающая его значение. Например:
■1аШког="Дмсо Смит", крайний срок=31 марта 1997г., статус=анализ}
Логические теги часто имеют форму isQuality, где качество — это
некоторое условие, которое может быть истинным или ложным. В этих
случаях форма «качество» обычно может появляться сама по себе, без
значения
и
по
умолчанию
имеет
значение
true.
Например,
{abstract}совnадает с {isAbstract=true}. Чтобы указать значение false,
полностью опустите имя. Теги других типов требуют явных значений.
Теговое значение (а также атрибут метамодели) отображается в виде
последовательности свойств, разделенных запятыми, внутри пары фигурных
скобок "{" и "}" (рис. 7.19.).
«Computer»
(Vendor = “Acer",
CPU = “AMD Phenom X4",
Memory = “4 GB DDR2’}
Aspire X1300
Рис. 7.19. Стереотипный компьютер, примененный с использованием
«традиционных» обозначений значений тегов.
В UML 1.3 помеченные значения могли расширять элемент модели, не
требуя наличия стереотипа. В UML 1.4 эта возможность, хотя и по-прежнему
143
поддерживается,
объявлена
устаревшей
и
используется только
по
соображениям обратной совместимости.
Начиная с UML 2.0, помеченное значение может быть представлено
только как атрибут, определенный в стереотипе. Поэтому элемент модели
должен быть расширен стереотипом, чтобы его можно было расширить
помеченными значениями. Для обеспечения совместимости с UML 1.3
некоторые инструменты UML могут автоматически определять стереотип, к
которому будут присоединены «несвязанные» атрибуты (помеченные
значения).
Значения тегов могут отображаться в разделе класса под именем
стереотипа. Для каждого применяемого стереотипа, значения которого
необходимо отобразить, требуется дополнительное отделение. Каждое такое
отделение озаглавлено названием применяемого стереотипа (рис. 7.20.).
«Computer»
Aspire Х1300
«Computer»
Vendor = “Acer"
CPU = “AMD Phenom X4"
Memory = “4 GB DDR2"
Рис. 7.20. Стереотипный компьютер со значениями тегов в отсеке
Значения тегов могут отображаться в прикрепленном комментарии
под названием стереотипа (рис. 7.21.).
Рис. 7.21. Стереотипный компьютер, примененный со значениями тега в
примечании к комментарию
144
При отображении в ячейках или в символе комментария каждая пара
"имя-значение" должна отображаться на отдельной строке.
7.6. Метакласс UML профиля
Метакласс— это класс профиля и пакетный элемент, который
может быть расширен за счет одного или нескольких стереотипов.
Метакласс может быть показан с необязательным стереотипом
«Метакласс», показанным выше или перед его именем (все «метаклассы» в
нижнем регистре использовались в версиях UML до 2.4) (рис. 7.22.).
«Metaclass»
Component
Рис. 7.22. Компонент метакласса
Метакласс
стереотипами
с
может
быть
использованием
расширен
одним
специального
или
вида
несколькими
ассоциации
-
расширения (рис. 7.23.).
Рис. 7.23. Стереотипный компьютер расширяет метакласс устройства
7.7. UML - актер
7.7.1. Понятие UML - актера
Актер — это поведенческий классификатор, который определяет
роль, которую играет внешний объект, взаимодействующий с субъектом
(например, путем обмена сигналами и данными), человек-пользователь
145
проектируемой системы, какая-либо другая система или оборудование,
использующие услуги субъекта.
Термин
«роль»
используется
неофициально
для
обозначения
некоторого типа, группы или определенного аспекта пользователей, которым
требуются
определенные
услуги
от
субъекта,
смоделированные
с
соответствующими вариантами использования. Когда внешний субъект
взаимодействует с субъектом, он играет роль определенного актера. Этот
единственный физический объект может играть несколько разных ролей, а
конкретную роль могут играть один или несколько разных экземпляров.
Поскольку субъект является внешним по отношению к субъекту, он
обычно определяется в том же классификаторе или пакете, который
включает субъект.
Все актеры должны иметь имена в соответствии с предполагаемой
ролью. Примеры имен актеров (ролей пользователей):
•
Покупатель
•
Веб-клиент
•
Ученик
•
Пассажир
•
Система оплаты
Стандартная нотация UML для актера — это значок «человек-палка» с
именем актера над или под значком (рис. 7.24.). Имена актеров должны
соответствовать рекомендациям по использованию заглавных букв и
пунктуации для классов. Имена абстрактных актеров должны быть
выделены курсивом.
146
Student
Рис. 7.24. Студенческий актер
Пользовательские значки, обозначающие тип актера, также могут
использоваться для обозначения актера, например, использование отдельных
значков для актеров, не являющихся людьми (рис. 7.25. и 7.26.).
Web Client
Рис. 7.25. Пользовательский значок для актера веб-клиента
Рис. 7.26. Пользовательская иконка для актера банка
Актер также может быть показан в виде прямоугольника класса со
стандартным ключевым словом «актер», при необходимости с обычным
обозначением для сегментов класса (рис. 7.27.).
«actor»
Customer
+ name: Name
+ address: Address
Рис. 7.27. Актер клиента как класс
147
Актер может иметь только бинарные ассоциации с вариантами
использования, компонентами и классами.
7.7.2. Бизнес-актер
Бизнес - актер (представленный в Rational Unified Process (RUP) для
поддержки бизнес-моделирования) представляет собой роль, которую играет
какое-то лицо или система, внешние по отношению к моделируемому
бизнесу и взаимодействующие с бизнесом. Обратите внимание, что бизнес-
актер не определен в стандарте UML.
Некоторые типичные примеры бизнес-актеров:
•
Покупатель
•
Поставщик
•
Покровитель
•
Пассажир
•
Власть
•
Банк
Каждый бизнес-субъект представляет собой что-то, выходящее за
рамки моделируемого бизнеса, и должен участвовать по крайней мере в
одном бизнес-варианте использования.
Бизнес-актер представлен в RUP значком в виде человечка-палки с
линией, пересекающей его голову (рис. 7.28.).
Passenger
Рис. 7.28. Бизнес-актер Пассажир
148
7.7.3. Отношения между актерами
Мы можем определить абстрактных или конкретных актеров и
специализировать их, используя отношение обобщения.
Обобщение
между
актерами
отображается
в
виде
сплошной
направленной линии с большой стрелкой (так же, как и для обобщения
между классами) (рис. 7.29.).
Web Client
Administrator
Customer
Editor
Рис. 7.29. Актер веб-клиента — это абстрактный суперкласс для
администратора, редактора и клиента.
149
8. СОСТАВНЫЕ СТРУКТУРНЫЕ UML ДИАГРАММЫ
8.1. Понятие и типы составных структурных UML диаграмм
Составная структурная диаграмма может быть использована для
отображения:
•
внутренней структуры классификатора - схемы внутренней
структуры;
•
взаимодействие классификатора с окружающей средой через порты;
•
поведение диаграммы кооперации.
Термин «структура» для этого типа диаграмм определяется в UML как
композиция взаимосвязанных элементов, представляющих экземпляры
времени выполнения, взаимодействующие по каналам связи для достижения
некоторых общих целей.
8.2. UML диаграмма внутренней структуры
8.2.1 Понятие и схема UML диаграммы внутренней структуры
Подвидом диаграммы композитной структуры является диаграмма
внутренней структуры (Internal Structure Diagram), которая используется
для более подробного представления структурных классификаторов, прежде
всего классов и компонентов.
Диаграмма
внутренней
структуры
показывает
внутреннюю
структуру классификатора - разложение этого классификатора на его
свойства, части и отношения (рис. 8.1.).
150
Рис. 8.1. Обзор составной структурной UML диаграммы, которая
показывает элементы внутренней структуры структурированного
классификатора - роли, части, соединители.
Следующие графические элементы обычно рисуются на составной
структурной диаграмме, которая показывает внутреннюю структуру
классификатора: класс, часть, порт, соединитель, использование.
8.2.3 Класс
Класс — это классификатор, описывающий набор объектов,
имеющих одинаковые:
•
особенности,
•
ограничения,
•
семантику (значение).
151
Класс отображается в виде прямоугольника со сплошным контуром,
содержащего
имя класса, и, возможно, с
отсеками,
разделенными
горизонтальными линиями, содержащими функции или другие элементы
классификатора.
Поскольку
класс
является
наиболее
широко
используемым
классификатором, нет необходимости добавлять ключевое слово «класс» в
кавычках над именем класса. Имя класса должно располагаться по центру и
выделено жирным шрифтом (рис. 8.2.), причем первая буква имени класса
должна быть заглавной (если набор символов поддерживает верхний
регистр).
Customer
Рис. 8.2. Класс Customer - подробности скрыты
Признаками класса являются атрибуты и операции (рис. 8.3).
Рис. 8.3. Класс SearchService — детали уровня анализа
Когда класс показан с тремя отсеками, средний отсек содержит список
атрибутов, а нижний отсек содержит список операций. Атрибуты и
операции должны быть выровнены по ширине, а первая буква имени
должна быть в нижнем регистре.
Характеристики, представленные функцией, могут относиться к
экземплярам
классификатора,
рассматриваемым
индивидуально
(не
статические), или к самому классификатору (статические). Один и тот же
152
признак не может быть статичным в одном контексте и нестатичным в
другом.
Что касается статических признаков, признаются две альтернативные
семантики. Статическая функция может иметь:
•
разные значения для разных классификаторов характеристик или
•
одинаковое значение для всех классификаторов признаков.
В соответствии с этой семантикой наследование значений статических
функций разрешено, но не требуется в UML 2.
Статические признаки подчеркнуты, но только имена. Многоточие (...)
в конце списка функций указывает на то, что дополнительные функции
существуют, но не отображаются в этом списке.
Атрибуты
класса
представлены
экземплярами
свойств,
принадлежащих классу. Некоторые из этих атрибутов могут представлять
навигационные концы бинарных ассоциаций.
Объекты класса должны содержать значения для каждого атрибута,
который является членом этого класса, в соответствии с характеристиками
атрибута, например, его типом и множественностью (рис. 8.4.).
SearchService
- config: Configuration
- engine: SearchEnglne
+ search( query: SearchRequest): SearchResult
- createEnginef): SearchEngine
Рис. 8.4. Класс SearchService — детали уровня реализации, где
createEngine является статической операцией
Атрибуты или операции могут быть сгруппированы по видимости.
Ключевое слово или символ видимости в этом случае можно указать один
раз для нескольких объектов с одинаковой видимостью (рис. 8.5.).
153
SearchService
private:
config: Configuration
engine: SearchEngine
private:
createEngineQ: SearchEngine
public:
search( query: SearchRequest): SearchResult
Рис. 8.5. Класс SearchService — атрибуты и операции, сгруппированные
по видимости
Дополнительные отсеки могут быть предоставлены для отображения
других деталей, таких как ограничения, или просто для разделения
функций.
Класс в UML можно использовать в качестве пространства имен для других
классификаторов, включая классы, интерфейсы, варианты использования и
т.д. Вложенные классификаторы видны только в пространстве имен
содержащего класса.
В UML 2.5 класс стал структурированным, инкапсулированным и
управляемым за счет расширения инкапсулированного классификатора и
поведенческого классификатора. Из-за этого любой класс может иметь
некоторую внутреннюю структуру и порты (рис. 8.6.).
Library
Services
SearchBooks
Searchvideo
o-
searchPort
Inventory
Рис. 8.6. Library Services — это структурированный класс,
инкапсулированный через порт searchPort.
Вложенность
классификаторов,
структурированного класса, ограничивает
определенных
видимость
в
рамках
классификаторов
областью пространства имен содержащего их структурированного класса и,
154
таким образом, поддерживает инкапсуляцию (сокрытие информации) через
порты (рис. 8.7.).
Рис. 8.7. Структурированный класс Online Shopping с торговым портом
и внутренней структурой.
8.2.3 UML-часть
Свойство (внутренних структур) является подклассом свойства ядра и
представляет набор экземпляров, принадлежащих содержащему экземпляру
классификатора. Это также соединительный элемент (из внутренних
конструкций).
Часть — это свойство, которое содержится в классификаторе с
использованием композиции. Это означает, что все части уничтожаются при
уничтожении содержащего экземпляра классификатора.
Часть показана графическим вложением символа коробки со сплошным
контуром, представляющим часть в отдельном отсеке внутри символа,
представляющего содержащий классификатор (рис. 8.8.).
Рис. 8.8. Контроллер поиска имеет от 1 до 3 систем — часть поисковой
системы
155
Поле части или свойства имеет только область имени, содержащую
строку в соответствии с синтаксисом, определенным для свойства из ядра.
Подробности могут быть показаны в поле, указывающем конкретные
значения свойств.
Множественность свойства или части может отображаться в виде
метки кратности в правом верхнем углу окна свойства (рис. 8.9.).
Рис. 8.9. Контроллер поиска имеет от 1 до 3 систем — часть поисковой
системы
Может отображаться символ свойства, содержащий только одно имя
(без двоеточия) в строке имени. Это подразумевает определение класса с
анонимным именем, вложенного в пространство имен содержащего его
класса.
Свойство, указывающее экземпляр, который не принадлежит с
использованием композиции экземпляру содержащего его классификатора,
показано графическим вложением символа прямоугольника с пунктирным
контуром (рис. 8.10.).
156
Рис. 8.10. Два источника данных являются свойством источников, но не
частью контроллера поиска.
8.2.4 UML-порт
Порт определяет точку взаимодействия, через которую классификатор
может
со
своим
окружением,
со
своими
внутренними
взаимодействовать
или
классификаторами
Инкапсулированный
классификатор
определен
с
в
другими
частями.
UML
как
структурированный классификатор с возможностью владения портами, и,
таким
образом,
порт
является
свойством
инкапсулированного
классификатора. Порт по умолчанию общедоступен.
Порт показан в виде маленького квадрата, который либо перекрывает
границу
прямоугольника,
классификатор,
либо
может
обозначающего
быть
показан
инкапсулированный
внутри
этого
символа
прямоугольника (рис. 8.11.). Название порта размещено рядом с небольшой
площадью.
Рис. 8.11. Класс библиотечных служб имеет порт searchPort.
Хотя UML не диктует правила именования портов, здравый смысл
состоит в том, чтобы начинать имена портов с нижнего регистра, например, "
p ", " port12 ", " searchPort ". Неясно, должен ли каждый порт иметь имя.
157
Если у порта есть имя, оно может быть скрыто на диаграмме. Спецификация
UML 2.5 дает странное пояснение, что «каждое изображение безымянного
порта обозначает порт, отличный от любого другого порта». Если имя
порта было просто подавлено, каждое изображение этого порта должно быть
одним и тем же портом.
Тип порта может быть указан после имени порта, разделенного
двоеточием ":" (рис. 8.12.).
search Port:
SearchBooks
Library
Services
г
Рис. 8.12. Класс Library Services имеет порт searchPort с типом
SearchBooks.
Кратность порта (если есть) указывается после имени порта в
квадратных скобках (рис. 8.13.). И имя, и кратность порта являются
необязательными.
Рис. 8.13. Класс Library Services имеет от 1 до 6 портов searchPort.
Предоставленный интерфейс может быть показан с использованием
нотации «леденец на палочке», прикрепленной к порту. Требуемый
интерфейс может быть показан с помощью нотации «сокет», прикрепленной
к порту (рис. 8.14.).
158
Library
Services
Search Books
SearchVideo
o—
search Port
Inventory
Рис. 8.14. Порт searchPort предоставляет интерфейсы SearchBooks и
SearchVideo и требует наличия интерфейса Inventory.
В
порту
поиска
класс
библиотечных
служб
полностью
инкапсулирован — его можно реализовать без каких-либо знаний о среде, в
которую будет встроен класс.
Если с портом связано несколько интерфейсов, эти интерфейсы могут
быть перечислены через запятую "," рядом со значком одного интерфейса
(рис. 8.15.).
Рис. 8.15. Несколько портов searchPort предоставляют интерфейсы
SearchBooks и SearchVideo и требуют наличия интерфейса Inventory.
Порт также может быть показан в виде маленького квадратного
символа, перекрывающего границу прямоугольного символа, обозначающего
часть, типизированную этим классификатором.
Простой порт.
Простой порт — это порт с одним требуемым или предоставляемым
интерфейсом (рис. 8.16.). Сложный порт имеет несколько предоставляемых
и/или обязательных интерфейсов.
159
Рис. 8.16. Компонент SearchEngine имеет простой порт searchPort
с единым интерфейсом ProductSearch.
В структурированном классификаторе UML допускает несколько
альтернативных обозначений для подключения простых портов к частям и
ролям.
Единственным обязательным обозначением соединения портов во
внутренней конструкции является соединение разъема непосредственно с
портами (рис. 8.17.). Дополнительные леденцы и сокеты могут отображать
предоставленные и требуемые интерфейсы подключенных портов.
«subsystem» Accountir g
Я
internal structure
Account
N
Customers
: Orders
Рис. 8.17. Простые порты, соединенные напрямую соединителем,
обязательная нотация UML. Компонент «Клиенты» обеспечивает
интерфейс «Учетная запись» для части «Заказы».
Как вариант, UML позволяет присоединять соединительную линию к
шару и гнезду вместо портов, как показано ниже (рис. 8.18.).
160
g~|
«subsystem» Accounting
internal structure
Account
4:
:Orders
R n
Customers
Рис. 8.18. Шар и гнездо соединены соединителем, необязательная
нотация UML. Компонент «Клиенты» обеспечивает интерфейс «Учетная
запись» для части «Заказы».
Соединитель сборки не отображается в другом необязательном
обозначении «шарик и гнездо» для простых портов. Это обозначение не
следует использовать для соединения сложных портов или частей без портов
(рис. 8.19.).
«subsystem» Accounting
internal structure
4
:Orders
Account
"I________ ________ г
г
Customers
Рис. 8.19. Сборочное соединение типа «шар-и-гнездо» для простых
портов, необязательная нотация UML. Компонент «Клиенты»
обеспечивает интерфейс «Учетная запись» для части «Заказы».
Сервисный порт.
Порт
может
указывать
услуги,
которые
инкапсулированный
классификатор предоставляет своей среде, а также услуги, которые
инкапсулированный классификатор требует от своей среды. Любой порт по
умолчанию является служебным портом, который определяется по
умолчанию истинным значением атрибута isService порта.
Предоставляемые
интерфейсы
порта
описывают
запросы
к
классификатору, которые другие классификаторы могут делать через этот
161
порт. Необходимые интерфейсы порта описывают запросы, которые могут
быть сделаны от классификатора к его среде через порт.
Когда для атрибута isService порта задано значение false, это означает,
что этот порт принадлежит реализации инкапсулированного классификатора
и не является частью контракта службы или важной видимой извне
функциональности. Такой неслужебный порт может быть изменен или
удален без каких-либо последствий для контракта на обслуживание.
Спецификация UML не дает объяснения, зачем нужен этот атрибут, если мы
можем просто изменить общедоступную видимость порта по умолчанию,
например, на частную видимость. Частные свойства не являются частью
каких-либо видимых извне функций.
UML не предоставляет специальных обозначений для визуального
отличия служебных портов от неслужебных портов, но имеет некоторые
соглашения
для
отображения
логических
атрибутов
в
качестве
модификаторов свойств (рис. 8.20.). Например, {ordered} означает, что
атрибут isOrdered имеет значение true, а {unordered} означает, что
соответствующее
свойство
не
упорядочено.
Вероятно,
мы
можем
использовать то же соглашение для атрибута isService порта, отображая его
либо как {service}, либо как {nonservice}.
Рис. 8.20. Порт actPort по умолчанию является служебным портом,
предоставляющим интерфейсы Orders и Customers и требующим
интерфейса Inventory.
Порт поведения.
162
Порт поведения — это такой порт, что запросы, поступающие на этот
порт, отправляются классификатору поведения, владеющему портом, а не
пересылаются некоторым содержащимся экземплярам. Если для этого
классификатора не определено поведение, любая связь, поступающая на порт
поведения, теряется. По умолчанию порты не являются портами поведения.
Порт поведения отображается как порт, соединенный сплошной
линией
с
небольшим
символом
состояния,
нарисованным
внутри
классификатора, содержащего порт (рис. 8.21.). Небольшой символ
состояния обозначает поведение содержащего классификатора.
Library
Services
SearchBooks
search Port
Рис. 8.21. Порт searchPort — это порт поведения с предоставленным
интерфейсом SearchBooks.
8.2.5 UML-соединитель
Соединитель — это функция, которая указывает ссылку, которая
обеспечивает связь между двумя или более экземплярами, играющими
определенные роли в структурированном классификаторе. Эта ссылка
может быть экземпляром ассоциации, или она может представлять
возможность того, что экземпляры могут взаимодействовать, потому что их
личности известны благодаря тому, что они передаются в качестве
параметров,
хранятся
в переменных или слотах, или потому что
взаимодействующие экземпляры являются тот же экземпляр.
Ссылка может быть реализована чем-то простым, например указателем,
или чем-то более сложным, например, сетевым соединением. В отличие от
ассоциаций, которые задают связи между любыми экземплярами связанных
163
классификаторов,
соединители
задают
связи
между
экземплярами,
воспроизводящими только связанные части.
Соединитель визуализируется с использованием нотации, похожей на
ассоциацию.
Необязательная
метка
соединителя
имеет
следующий
синтаксис:
connector-label::= [ connector-name ] [( association-name | association-class-name ) ]
где имя-соединителя — это имя соединителя, имя-ассоциации — имя
ассоциации, а имя-класса-ассоциации — имя класса ассоциации. Ключевое
слово или стереотип внутри кайр может быть помещен над или перед именем
соединителя на диаграмме. Строка свойства может быть размещена после
имени соединителя или под ним.
Компоненты соединения коннектора могут быть следующими:
•
разъем делегирования или
•
монтажный соединитель.
Тип атрибута соединителя является производным: соединитель с одним
или несколькими концами, подключенными к порту, который не находится в
части и не является портом поведения, является делегированием; иначе это
сборка.
Контракт коннектора — это набор поведений, которые определяют
допустимые шаблоны взаимодействия через коннектор.
Соединитель сборки. Соединитель сборки — это соединитель между
двумя или более деталями, или портами на деталях, который определяет, что
одна или несколько деталей предоставляют услуги, которые используют
другие детали.
Семантика времени выполнения для соединителя сборки заключается в
том, что сигналы проходят вдоль экземпляра соединителя. Несколько
коннекторов, направленных к разным частям и из них, или n-арные
164
коннекторы, где n > 2, указывают, что экземпляр, который будет создавать
или обрабатывать сигнал, будет определен во время выполнения.
Совместимость
интерфейсов
между
подключенными
портами
позволяет заменить существующий компонент в системе таким, который
(минимально) предлагает тот же набор услуг. Кроме того, в контекстах, где
компоненты
используются
для
расширения
системы,
предлагая
существующие службы, а также добавляя новые функции, соединители
можно использовать для связи в определении нового компонента.
Соединитель сборки обозначается как соединитель между двумя или
более деталями, или портами на деталях (рис. 8.22.).
«component»
Web Store
c
Рис. 8.22. Коннектор сборки между портами компонентов Authentication
и Customers
Когда соединитель сборки соединяет простые порты (порты, которые
обеспечивают или требуют один интерфейс), это может быть обозначено
соединением «шар-и-гнездо» между предоставленным интерфейсом и
требуемым интерфейсом (рис. 8.23.).
Рис. 8.23. Соединитель сборки между простыми портами компонентов
Authentication и Customers
165
Обозначение «шар-и-гнездо» нельзя использовать для соединения
«сложных» портов или частей без портов.
Если
несколько
компонентов имеют
простые порты,
которые
предоставляют или требуют один и тот же интерфейс, может быть показан
один символ, представляющий интерфейс, и линии от компонентов могут
быть проведены к этому символу (рис. 8.24.). Этот вариант представления
применим независимо от того, показан ли интерфейс с использованием
нотации «шар-и-гнездо» или просто с использованием требуемого или
предоставленного символа интерфейса.
Рис. 8.24. Сборочный соединитель, который собирает три детали
Соединитель делегирования. Соединитель делегирования — это
соединитель, который связывает внешний контракт компонента (как указано
его портами) с реализацией этого поведения. Он представляет собой
пересылку событий (запросов операций и событий): сигнал, поступающий на
порт, который имеет соединитель делегирования для одной или нескольких
частей или портов на частях, будет передан этим целям для обработки.
Соединитель делегирования — это декларация того, что поведение,
доступное для экземпляра компонента, на самом деле реализуется не самим
этим компонентом, а одним или несколькими экземплярами, имеющими
«совместимые» возможности. Эти ситуации моделируются с помощью
соединителя делегирования от порта к совместимым портам или частям.
Коннекторы делегирования можно использовать для моделирования
иерархической декомпозиции поведения, когда услуги, предоставляемые
166
компонентом, в конечном итоге могут быть реализованы компонентом,
вложенным
в
него
на
нескольких
уровнях.
Слово
делегирование
предполагает, что между подключенными портами будет происходить
конкретный поток сообщений и сигналов, возможно, на нескольких уровнях.
Следует отметить, что такой поток сигналов не всегда реализуется во всех
системных средах или реализациях (т. е. это может быть только время
разработки).
Порт может делегировать набор портов на подчиненных компонентах.
В этом случае эти подчиненные порты должны вместе предлагать
делегированные функции делегирующего порта. Во время выполнения
сигналы будут доставлены на соответствующий порт. В случаях, когда
несколько целевых портов поддерживают обработку одного и того же
сигнала, сигнал будет доставлен на все эти подчиненные порты.
Соединитель делегирования обозначается как соединитель от порта
делегирования к порту обработки или его части (рис. 8.25.).
Рис. 8.25. Соединитель делегирования от порта делегирования к части
UserServlet
Если делегирование обрабатывается простым портом, коннектор может
быть дополнительно показан подключенным к одному сокету (рис. 8.26. и
8.27.).
167
Рис. 8.26. Соединитель делегирования от делегирующего порта к
простому порту SearchEngine
Рис. 8.27. Соединитель делегирования от простого порта компонента
аутентификации к порту делегирования
8.2.6 UML-использование
Использование — это отношения зависимости, в которых один
элемент (клиент) требует другого элемента (или набора элементов)
(поставщика) для его полной реализации или работы.
Зависимость использования не указывает, как клиент использует
поставщика, кроме того факта, что поставщик используется определением
или реализацией клиента. Например, это может означать, что некоторые
методы в классе (клиент) используют объекты (например, параметры)
другого класса (поставщика).
Зависимость
использования
отображается
как
зависимость
прикрепленным к ней ключевым словом «использовать» (рис. 8.28.).
168
с
Рис. 8.28. Класс SearchController использует класс SearchEngine.
Создавать.
Создание
—
это
использования,
зависимость
означающая, что классификатор клиента создает экземпляры классификатора
поставщика. Обозначается стандартным стереотипом «create» (рис. 8.29.).
Рис. 8.29. Класс DataSource создает Connection.
Создать также может указать, что назначенный признак создает
экземпляр
классификатора,
к
которому
присоединен
признак.
Эта
зависимость может быть повышена до классификатора, содержащего
функцию.
Create может связать значение экземпляра с конструктором для класса,
описывая единственное значение, возвращаемое операцией конструктора.
Операция — это клиент, созданный экземпляр — поставщик. Значение
экземпляра может ссылаться на параметры, объявленные операцией (рис.
8.30.).
Рис. 8.30. Конструктор учетной записи создает новые экземпляры
учетной записи
Instantiate — это еще одна зависимость использования среди
классификаторов,
указывающая,
что
операции
на
клиенте
создают
экземпляры поставщика. Обозначается стандартным стереотипом «создавать
экземпляры».
169
Не очень понятно, почему в стандарте UML 2.4 есть и «создать», и
«создать экземпляр».
Вызов.
Call — это зависимость использования, которая указывает, что
исходная операция вызывает целевую операцию. Эта зависимость может
связывать исходную операцию с любой целевой операцией, находящейся в
области действия, включая, помимо прочего, операции включающего
классификатора и операции других видимых классификаторов.
Вызов обозначается стандартным стереотипом «вызов», источником
которого является операция и целью которого также является операция.
Это отношение также может быть применено к классу, содержащему
операцию, в том смысле, что в классе существует операция, к которой
применяется зависимость.
Send — это зависимость использования, источником которой
является операция, а целью — сигнал, указывающий, что источник
отправляет целевой сигнал.
Отправка обозначается стандартным стереотипом «отправить».
Требуемый интерфейс.
Требуемый интерфейс определяет сервисы, которые необходимы
классификатору для выполнения своих функций и выполнения собственных
обязательств перед своими клиентами. Он определяется зависимостью
использования
между
классификатором
и
соответствующим
интерфейсом.
Зависимость использования от классификатора к интерфейсу показана
путем представления интерфейса полукругом или сокетом, помеченным
именем интерфейса, прикрепленным сплошной линией к классификатору,
которому требуется этот интерфейс (рис. 8.31.).
170
SiteSearch
—c
Search
Controller
Рис. 8.31. Интерфейс SiteSearch используется (обязательно)
SearchController.
Если интерфейс представлен в виде прямоугольника, зависимость
использования интерфейса обозначается стрелкой зависимости (рис. 8.32.).
Классификатор в конце стрелки использует (требует) интерфейс в начале
стрелки.
Рис. 8.32. Интерфейс SiteSearch используется (обязательно)
SearchController.
8.3. UML диаграмма кооперации
8.3.1 Понятие и схема UML диаграммы кооперации
Подвидом диаграмм композитной структуры является диаграмма
кооперации (Collaboration Use Diagram, введены в UML 2.0), которая
показывает
роли
и
взаимодействие
классов
в рамках
кооперации.
Кооперации удобны при моделировании шаблонов проектирования. UML
диаграмма
кооперации по
другому иногда называется
диаграммой
совместного использования.
Поведение системы — это функциональность, которую будет
реализовывать проектируемая система или которая уже реализована какой-
либо существующей системой. Объекты в системе обычно взаимодействуют
друг с другом для создания поведения системы.
Поведение сотрудничества в конечном итоге будет демонстрироваться
набором взаимодействующих экземпляров (указанных классификаторами),
которые взаимодействуют друг с другом, отправляя сигналы или вызывая
171
операции. Однако для понимания механизмов, используемых в дизайне,
может быть важно описать только те аспекты этих классификаторов и их
взаимодействия,
которые
задействованы
в
выполнении
задачи
или
связанного набора задач, проецируемых этими классификаторами.
Сотрудничество позволяет нам описать только важные аспекты
взаимодействия набора экземпляров, определяя конкретные роли, которые
будут играть экземпляры.
Интерфейсы позволяют указывать внешне наблюдаемые свойства
экземпляра без определения классификатора, который в конечном итоге
будет использоваться для определения этого экземпляра. Следовательно,
роли в кооперации часто будут типизированы интерфейсами, а затем будут
предписывать свойства, которые должны демонстрировать участвующие
экземпляры, но не будут определять, какой класс будет определять
участвующие экземпляры.
Следующие узлы и ребра обычно рисуются на составной структурной
диаграмме
(рис.
сотрудничество,
8.33.),
поведение
кооперации:
специализация
кооперации,
показывающей
соединитель,
часть,
зависимость.
172
Рис. 8.33. Элементы сотрудничества - роли, части, соединители.
Collaboration Visit показывает взаимодействие ролей врача и пациента.
Использование сотрудничества представляет собой одно конкретное
использование
(событие)
или
применение
шаблона,
описываемого
сотрудничеством, к конкретной ситуации, включающей определенные
классы или экземпляры, играющие роли сотрудничества. Использование
сотрудничества показывает, как шаблон, описываемый сотрудничеством,
применяется в заданном контексте путем привязки определенных объектов
из этого контекста к ролям сотрудничества (рис. 8.34.).
173
Рис. 8.34. Элементы использования совместной работы - роли, части,
связывание ролей. Использование совместной работы childVisit
представляет собой одно конкретное использование совместной работы
Visit.
Классификатор
(во
внутренних
структурах
и
коллаборациях)
расширен возможностью использовать собственные коллаборации. Это
сотрудничество использует связь сотрудничества с классификатором,
чтобы дать описание поведения классификатора.
Одно из совместных применений, принадлежащее классификатору,
может быть выбрано как представляющее поведение классификатора в
целом. Кооперация, связанная с классификатором посредством такого
использования кооперации, показывает, как экземпляры, соответствующие
структурным
характеристикам
этого
174
классификатора
(например,
его
атрибутам и частям), взаимодействуют для создания общего поведения
классификатора.
кооперация
Представляющая
использоваться
может
для
предоставления описания поведения классификатора на другом уровне
абстракции, чем предлагается внутренней структурой классификатора.
Свойства классификатора сопоставляются с ролями в кооперации с
помощью привязок ролей кооперации use.
В разделе четыре вы можете увидеть примеры диаграммы
сотрудничества.
8.3.2 UML-сотрудничество
Сотрудничество расширяет как поведенческий классификатор, так и
структурированный
классификатор,
чтобы
объяснить,
как
набор
взаимодействующих экземпляров выполняет совместную задачу или набор
задач. Его основная цель — объяснить, как работает система, и поэтому
обычно он включает только те аспекты реальности, которые считаются
важными для объяснения.
Сотрудничество описывает структуру взаимодействующих элементов
(ролей), каждый из которых выполняет специализированную функцию,
которые
вместе
выполняют некоторую
желаемую
функциональность
(задачу) (рис. 8.35.). Детали, такие как идентификатор или точный класс
фактических участвующих экземпляров, скрыты.
175
Рис. 8.35. Элементы сотрудничества - роли, части, соединители.
Collaboration Visit показывает взаимодействие ролей врача и пациента.
Сотрудничество представляется в виде своего рода классификатора и
определяет набор взаимодействующих сущностей, которые должны играть
экземпляры (его роли), а также набор коннекторов, определяющих пути
связи между участвующими экземплярами. Сотрудничающие объекты
являются свойствами сотрудничества.
Сотрудничество определяет представление (или проекцию) набора
взаимодействующих классификаторов. В нем описываются необходимые
связи между экземплярами, играющими роли кооперации, а также функции,
требуемые от классификаторов, определяющих участвующие экземпляры.
Несколько коллабораций могут описывать разные проекции одного и
того же набора классификаторов.
Роли
коопераций
определяют
использование
экземпляров,
а
классификаторы, типизирующие эти роли, указывают все необходимые
свойства этих экземпляров. Таким образом, кооперация определяет, какими
свойствами должны обладать экземпляры, чтобы иметь возможность
176
участвовать в кооперации. Роль определяет (посредством своего типа)
требуемый
функций,
набор
который
должен
иметь
участвующий
экземпляр. Соединители между ролями определяют, какие пути связи
должны существовать между участвующими экземплярами.
Сотрудничество
часто
определяется
с
точки
зрения
ролей,
типизированных интерфейсами . Интерфейс — это описание набора свойств
(внешних
наблюдаемых
функций),
требуемых
или
предоставляемых
экземпляром. Интерфейс можно рассматривать как проекцию внешне
наблюдаемых признаков классификатора, реализующего интерфейс.
Экземпляры
различных
классификаторов
могут
играть
роль,
определяемую данным интерфейсом, если эти классификаторы реализуют
интерфейс. Несколько интерфейсов могут быть реализованы одним и тем же
классификатором даже в одном контексте, но их функции могут быть
разными подмножествами функций реализующего классификатора.
Сотрудничество не может быть создано напрямую. Вместо этого
кооперация,
определяемая
кооперацией,
возникает
как
следствие
фактического кооперации между экземплярами, которые играют роли,
определенные в кооперации (сотрудничество — это выборочный взгляд на
эту ситуацию).
Кооперация
может
быть
присоединена
к
операции
или
классификатору посредством использования кооперации. Сотрудничество,
используемое таким образом, описывает, как эта операция или этот
классификатор реализуются набором взаимодействующих экземпляров.
Соединители, определенные в сотрудничестве, определяют связи между
экземплярами, когда они выполняют поведение, указанное в классификаторе.
Сотрудничество определяет контекст, в котором выполняется поведение.
Такое
сотрудничество
взаимодействий,
которые
может
ограничивать
набор
допустимых
могут
происходить
между
экземплярами,
соединенными ссылкой.
177
Сотрудничество отображается в виде значка пунктирного эллипса,
содержащего имя сотрудничества. Внутренняя структура сотрудничества,
состоящая из ролей и соединителей, может быть показана в отсеке внутри
значка пунктирного эллипса.
8.3.3 UML-соединитель
Соединитель — это функция, которая указывает ссылку, которая
обеспечивает связь между двумя или более экземплярами, играющими
определенные роли в структурированном классификаторе. Эта ссылка
может быть экземпляром ассоциации, или она может представлять
возможность того, что экземпляры могут взаимодействовать, потому что их
личности известны благодаря тому, что они передаются в качестве
параметров,
хранятся
в переменных или слотах, или потому что
взаимодействующие экземпляры являются тот же экземпляр.
Ссылка может быть реализована чем-то простым, например указателем,
или чем-то более сложным, например, сетевым соединением. В отличие от
ассоциаций, которые задают связи между любыми экземплярами связанных
классификаторов,
соединители
задают
связи
между
экземплярами,
воспроизводящими только связанные части.
Соединитель визуализируется с использованием нотации, похожей на
ассоциацию.
Необязательная
метка
соединителя
имеет
следующий
синтаксис:
connector-label ::= [ connector-name ] [
( association-name | association-class-name ) ]
где имя-соединителя — это имя соединителя, имя-ассоциации — имя
ассоциации, а имя-класса-ассоциации — имя класса ассоциации. Ключевое
слово или стереотип внутри кайр может быть помещен над или перед именем
соединителя на диаграмме. Строка свойства может быть размещена после
имени соединителя или под ним.
Компоненты соединения коннектора могут быть следующими:
178
разъем делегирования или
•
монтажный соединитель.
Тип атрибута соединителя является производным: соединитель с одним
или несколькими концами, подключенными к порту, который не находится в
части и не является портом поведения, является делегированием; иначе это
сборка.
Контракт коннектора — это набор поведений, которые определяют
допустимые шаблоны взаимодействия через коннектор.
Соединитель сборки.
Соединитель сборки — это соединитель между двумя или более
деталями, или портами на деталях, который определяет, что одна или
несколько деталей предоставляют услуги, которые используют другие
детали.
Семантика времени выполнения для соединителя сборки заключается в
том, что сигналы проходят вдоль экземпляра соединителя. Несколько
коннекторов, направленных к разным частям и из них, или n-арные
коннекторы, где n > 2, указывают, что экземпляр, который будет создавать
или обрабатывать сигнал, будет определен во время выполнения.
Совместимость
интерфейсов
между
подключенными
портами
позволяет заменить существующий компонент в системе таким, который
(минимально) предлагает тот же набор услуг. Кроме того, в контекстах, где
компоненты
используются
для
расширения
системы,
предлагая
существующие службы, а также добавляя новые функции, соединители
можно использовать для связи в определении нового компонента.
Соединитель сборки обозначается как соединитель между двумя или
более деталями, или портами на деталях (рис. 8.36.).
179
c
«component»
Web Store
Рис. 8.36. Коннектор сборки между портами компонентов Authentication
и Customers
Когда соединитель сборки соединяет простые порты (порты, которые
обеспечивают или требуют один интерфейс), это может быть обозначено
соединением «шар-и-гнездо» между предоставленным интерфейсом и
требуемым интерфейсом (рис. 8.37.).
Рис. 8.37. Соединитель сборки между простыми портами компонентов
Authentication и Customers
Обозначение «шар-и-гнездо» нельзя использовать для соединения
«сложных» портов или частей без портов.
Если
несколько
компонентов
имеют
простые
порты,
которые
предоставляют или требуют один и тот же интерфейс, может быть показан
один символ, представляющий интерфейс, и линии от компонентов могут
быть проведены к этому символу (рис. 8.38.). Этот вариант представления
применим независимо от того, показан ли интерфейс с использованием
нотации «шар-и-гнездо» или просто с использованием требуемого или
предоставленного символа интерфейса.
180
Рис. 8.38. Сборочный соединитель, который собирает три детали
Соединитель делегирования.
Соединитель делегирования — это соединитель, который связывает
внешний контракт компонента (как указано его портами) с реализацией этого
поведения. Он представляет собой пересылку событий (запросов операций и
событий): сигнал, поступающий на порт, который имеет соединитель
делегирования для одной или нескольких частей, или портов на частях, будет
передан этим целям для обработки.
Соединитель делегирования — это декларация того, что поведение,
доступное для экземпляра компонента, на самом деле реализуется не самим
этим компонентом, а одним или несколькими экземплярами, имеющими
«совместимые» возможности. Эти ситуации моделируются с помощью
соединителя делегирования от порта к совместимым портам или частям.
Коннекторы делегирования можно использовать для моделирования
иерархической декомпозиции поведения, когда услуги, предоставляемые
компонентом, в конечном итоге могут быть реализованы компонентом,
вложенным
в
него
на
нескольких
уровнях.
Слово
делегирование
предполагает, что между подключенными портами будет происходить
конкретный поток сообщений и сигналов, возможно, на нескольких уровнях.
Следует отметить, что такой поток сигналов не всегда реализуется во всех
системных средах или реализациях (т. е. это может быть только время
разработки).
181
Порт может делегировать набор портов на подчиненных компонентах.
В этом случае эти подчиненные порты должны вместе предлагать
делегированные функции делегирующего порта. Во время выполнения
сигналы будут доставлены на соответствующий порт. В случаях, когда
несколько целевых портов поддерживают обработку одного и того же
сигнала, сигнал будет доставлен на все эти подчиненные порты.
Соединитель делегирования обозначается как соединитель от порта
делегирования к порту обработки или его части (рис. 8.39.).
Рис. 8.39. Соединитель делегирования от порта делегирования к части
UserServlet
Если делегирование обрабатывается простым портом, коннектор может
быть дополнительно показан подключенным к одному сокету (рис. 8.40. и
8.41.).
Рис. 8.40. Соединитель делегирования от делегирующего порта к
простому порту SearchEngine
182
Рис. 8.41. Соединитель делегирования от простого порта компонента
аутентификации к порту делегирования
8.3.4 UML-часть
Свойство (внутренних структур) является подклассом свойства ядра и
представляет набор экземпляров, принадлежащих содержащему экземпляру
классификатора. Это также соединительный элемент (из внутренних
конструкций).
Часть — это свойство, которое содержится в классификаторе с
использованием композиции. Это означает, что все части уничтожаются при
уничтожении содержащего экземпляра классификатора.
Часть показана графическим вложением символа коробки со сплошным
контуром, представляющим часть в отдельном отсеке внутри символа,
представляющего содержащий классификатор (рис. 8.42.).
Рис. 8.42. Контроллер поиска имеет от 1 до 3 систем — часть поисковой
системы
Поле части или свойства имеет только область имени, содержащую
строку в соответствии с синтаксисом, определенным для свойства из ядра.
183
Подробности могут быть показаны в поле, указывающем конкретные
значения свойств.
Множественность свойства или части может отображаться в виде
метки кратности в правом верхнем углу окна свойства (рис. 8.43.).
Рис. 8.43. Контроллер поиска имеет от 1 до 3 систем — часть поисковой
системы
Может отображаться символ свойства, содержащий только одно имя
(без двоеточия) в строке имени. Это подразумевает определение класса с
анонимным именем, вложенного в пространство имен содержащего его
класса.
Свойство, указывающее экземпляр, который не принадлежит с
использованием композиции экземпляру содержащего его классификатора,
показано графическим вложением символа прямоугольника с пунктирным
контуром (рис. 8.44.).
Рис. 8.44. Два источника данных являются свойством источников, но не
частью контроллера поиска.
184
8.3.5. Зависимость в UML
Зависимость — это направленная связь, которая используется для
демонстрации того, что какой-либо элемент или набор элементов UML
требует, нуждается или зависит от других элементов модели для
спецификации или реализации. Из-за этого зависимость называется
отношениями поставщик - клиент, когда поставщик что-то предоставляет
клиенту, и, таким образом, клиент является в некотором смысле неполным,
хотя семантически или структурно зависит от элемента (элементов)
поставщика. Изменение поставщика может повлиять на элементы клиента.
Зависимость — это связь между именованными элементами, которая
в UML включает множество различных элементов, например, классы,
интерфейсы, компоненты, артефакты, пакеты и т. д. Существует
несколько видов зависимостей, показанных на диаграмме ниже (рис. 8.45.).
Рис. 8.45. Обзорная диаграмма отношения зависимости —
использование, абстракция, развертывание.
185
Использование — это зависимость, при которой один именованный
элемент (клиент) требует другого именованного элемента (поставщика) для
своего полного определения или реализации.
Абстракция связывает два элемента, представляющих одно и то же
понятие, но на разных уровнях абстракции.
Развертывание — это зависимость, которая показывает распределение
(развертывание) артефакта в цель развертывания. (Не очень понятно,
почему UML 2.4.1 определяет развертывание как зависимость, а не как
ассоциацию или просто направленную связь.)
Обратите внимание, что спецификация UML 2.4.1 содержит некоторое
сбивающее с толку разъяснение о том, что «наличие отношений зависимости
в модели не имеет никаких последствий семантики времени выполнения, все
это дается в терминах элементов модели, которые участвуют в
отношениях, а не в терминах. их экземпляров».
Это
уточнение
противоречит
определению
зависимости
от
использования, которая является зависимостью от реализации. Опытный
разработчик программного обеспечения знает, что происходит во время
выполнения,
когда какая-то зависимость отсутствует,
а приложение
уничтожается LinkageError или ClassNotFoundException из
загрузчика
классов. Таким образом, зависимость может иметь серьезные последствия
семантики времени выполнения.
Зависимость обычно изображается пунктирной стрелкой, указывающей
от клиента (зависимого) в конце к поставщику (поставщику) в конце
стрелки (рис. 8.46.). Стрелка может быть помечена необязательным
стереотипом и необязательным именем. Поскольку направление стрелки
противоположно тому, что мы обычно ожидаем, я обычно воспринимаю это
как стереотип, что клиент «зависит от» поставщика.
186
Рис. 8.46. Класс SearchController зависит (требуется) от интерфейса
SiteSearch.
В
течение
многих
лет
спецификации
противоречивый пример зависимости,
UML
предоставляют
показанной ниже (рис. 8.47.).
Объяснение рисунка 7.38 спецификации UML 2.4.1 гласит: «В приведенном
ниже примере класс Car имеет зависимость от класса CarFactory. В этом
случае зависимость представляет собой экземпляр зависимости, где класс
Car является экземпляром класс CarFactory».
Рис. 8.47. Неправильно: класс Car зависит от класса CarFactory.
Справа: класс CarFactory зависит от класса Car.
Этот пример на самом деле показывает обратное тому, что утверждает
спецификация UML. CarFactory зависит от класса Car. Класс Car может быть
определен без знания класса CarFactory, но CarFactory требует Car для своего
определения, потому что он производит Cars. Также неправильно говорить,
что «... класс Car является экземпляром класса CarFactory». Класс Car
создается классом CarFactory.
Возможен набор элементов для клиента или поставщика. В этом случае
одна или несколько стрелок с концами на клиентах соединяются с концами
одной или нескольких стрелок с концами на поставщиках. При желании на
стыке можно поставить маленькую точку. В месте соединения следует
прикрепить примечание о зависимости.
Зависимость может использоваться на нескольких типах диаграмм
UML:
•
диаграмма классов
187
схема составной структуры
•
схема пакета
•
диаграмма компонентов
•
схема развертывания
Вот несколько примеров зависимостей на рисунках 8.48. и 8.49.:
Web
Shopping
«use» >
-----------
Payment
Рис. 8.48. Пакет Web Shopping использует (зависит от) пакет Payment.
Рис. 8.49. Интерфейс SiteSearch реализован (реализован) SearchService.
Обратите внимание, что зависимость от абстракции имеет соглашение
о более абстрактном элементе в качестве поставщика и более конкретном
элементе или элементе реализации в качестве клиента, но спецификация
UML также позволяет рисовать его противоположным образом (рис. 8.50.).
Рис. 8.50. Компонент UserService, реализованный UserServlet и UserDAO.
Применение.
Использование — это отношения зависимости, в которых один
элемент (клиент) требует другого элемента (или набора элементов)
(поставщика) для его полной реализации или работы.
188
Зависимость использования не указывает, как клиент использует
поставщика, кроме того факта, что поставщик используется определением
или реализацией клиента. Например, это может означать, что некоторые
методы в классе (клиент) используют объекты (например, параметры)
другого класса (поставщика).
Зависимость
использования
отображается
как
зависимость
с
прикрепленным к ней ключевым словом «использовать» (рис. 8.51.).
Рис. 8.51. Класс SearchController использует класс SearchEngine.
Создание.
Создание — это зависимость использования, означающая, что
классификатор клиента создает экземпляры классификатора поставщика.
Обозначается стандартным стереотипом «create» (рис. 8.52.).
Рис. 8.52. Класс DataSource создает Connection.
Создать также может указать, что назначенный признак создает
экземпляр
классификатора,
к
которому
присоединен
признак.
Эта
зависимость может быть повышена до классификатора, содержащего
функцию.
Create может связать значение экземпляра с конструктором для класса,
описывая единственное значение, возвращаемое операцией конструктора.
Операция — это клиент, созданный экземпляр — поставщик (рис. 8.53.).
Значение
экземпляра
может
ссылаться
операцией.
189
на
параметры,
объявленные
Рис. 8.53. Конструктор учетной записи создает новые экземпляры
учетной записи
Instantiate — это еще одна зависимость использования среди
классификаторов,
указывающая,
что
операции
на
клиенте
создают
экземпляры поставщика. Обозначается стандартным стереотипом «создавать
экземпляры».
Не очень понятно, почему в стандарте UML 2.4 есть и «создать», и
«создать экземпляр».
Вызов.
Call — это зависимость использования, которая указывает, что
исходная операция вызывает целевую операцию. Эта зависимость может
связывать исходную операцию с любой целевой операцией, находящейся в
области действия, включая, помимо прочего, операции включающего
классификатора и операции других видимых классификаторов.
Вызов обозначается стандартным стереотипом «вызов», источником и
целью которого также является операция.
Это отношение также может быть применено к классу, содержащему
операцию, в том смысле, что в классе существует операция, к которой
применяется зависимость.
Send — это зависимость использования, источником которой
является операция, а целью — сигнал, указывающий, что источник
отправляет целевой сигнал.
Отправка обозначается стандартным стереотипом «отправить».
Требуемый интерфейс.
Требуемый интерфейс определяет сервисы, которые необходимы
классификатору для выполнения своих функций и выполнения собственных
190
обязательств перед своими клиентами. Он определяется зависимостью
использования
между
классификатором
и
соответствующим
интерфейсом.
Зависимость использования от классификатора к интерфейсу показана
путем представления интерфейса полукругом или сокетом, помеченным
именем интерфейса, прикрепленным сплошной линией к классификатору,
которому требуется этот интерфейс (рис. 8.54.).
SiteSearch
—c
Search
Controller
Рис. 8.54. Интерфейс SiteSearch используется (обязательно)
SearchController.
Если интерфейс представлен в виде прямоугольника, зависимость
использования интерфейса обозначается стрелкой зависимости (рис. 8.55.).
Классификатор в конце стрелки использует (требует) интерфейс в начале
стрелки.
Рис. 8.55. Интерфейс SiteSearch используется (обязательно)
SearchController.
191
9. UML ДИАГРАММА КОМПОНЕНТОВ
9.1. Понятие и схема UML диаграммы компонентов
Диаграмма компонентов показывает компоненты, предоставляемые и
требуемые интерфейсы, порты и отношения между ними. Этот тип диаграмм
используется в компонентно-ориентированной разработке (CBD) для
описания
систем
с
сервис-ориентированной
архитектурой
(SOA).
Диаграмма компонентов - это разновидность диаграмм классов; она
демонстрирует инкапсулированные классы и их интерфейсы, порты и
внутренние
структуры,
из
состоящие
вложенных
компонентов
и
коннекторов.
Разработка на основе компонентов основана на предположениях, что
ранее созданные компоненты могут быть повторно использованы и что
компоненты могут быть заменены некоторыми другими «эквивалентными»
или «совместимыми» компонентами, если это необходимо.
Артефакты, реализующие компонент, предназначены для независимого
развертывания и повторного развертывания, например, для обновления
существующей системы.
Компоненты в UML могут представлять
•
логические компоненты (например, бизнес-компоненты, компоненты
процесса) и
•
физические
компоненты
(например,
компоненты
CORBA,
компоненты EJB, компоненты COM+ и .NET, компоненты WSDL и т.
д.),
Вместе с артефактами, которые их реализуют, и узлами, на которых
они развертываются и выполняются. Ожидается, что профили, основанные
на компонентах,
будут разработаны для конкретных компонентных
технологий и соответствующих аппаратных и программных сред.
192
На диаграмме компонентов обычно рисуются следующие узлы и
ребра: компонент, интерфейс, предоставленный интерфейс, требуемый
интерфейс, класс, порт, коннектор, артефакт, реализация компонента,
зависимость, использование. Эти основные элементы показаны на рисунке
ниже (рис. 9.1.).
Рис. 9.1. Основные элементы UML диаграммы компонентов компонент, предоставляемый интерфейс, требуемый интерфейс, порт,
коннекторы.
9.2. Компонент
9.2.1 Понятие компонента
Компонент — это класс, представляющий модульную часть системы с
инкапсулированным содержимым, воплощение которого можно заменить в
его среде.
Поведение компонента определяется с точки зрения предоставляемых
интерфейсов и требуемых интерфейсов (потенциально предоставляемых
через порты).
193
Компонент служит типом, соответствие которого определяется этими
предоставленными и требуемыми интерфейсами (включая их статическую и
динамическую семантику). Таким образом, один компонент может быть
заменен другим только в том случае, если они соответствуют типу.
Более крупные части функциональности системы могут быть собраны
путем повторного использования компонентов в качестве частей в
охватывающем компоненте или сборке компонентов и соединения их
требуемых и предоставляемых интерфейсов.
Компонент моделируется на протяжении всего жизненного цикла
разработки и последовательно уточняется для развертывания и выполнения.
Компонент может проявляться одним или несколькими артефактами.
Косвенно созданный компонент определяется во время разработки, но
не существует как адресуемый объект во время выполнения. Поведение
компонента и его портов во время выполнения определяется поведением
реализующих его классификаторов или частей. Этот атрибут предполагают
несколько стандартных стереотипов, например, «Спецификация», «Фокус»,
«Подсистема».
Внутренности компонента скрыты и недоступны, кроме как в его
интерфейсах. Хотя он может зависеть от других элементов с точки зрения
требуемых интерфейсов, компонент инкапсулирован, а его зависимости
спроектированы таким образом, чтобы с ним можно было обращаться как
можно более независимо.
9.2.2 Обозначение
Компонент отображается в виде прямоугольника классификатора с
ключевым словом «component» (рис. 9.2.).
194
«component»
WeatherServices
Рис. 9.2. Компонент WeatherServices
Дополнительно значок компонента, аналогичный значку UML 1.4,
может отображаться в правом верхнем углу прямоугольника компонента
(рис. 9.3.). Если отображается символ пиктограммы, ключевое слово
«компонент» может быть опущено.
c
UserServices
Рис.9.3. Компонент UserServices
Компонент
может
быть
представлен
одним
или
несколькими
артефактами, и, в свою очередь, этот артефакт может быть развернут в
своей среде выполнения. Спецификация развертывания может определять
значения, которые параметризуют выполнение компонента.
Предоставляемый интерфейс.
Предоставленный интерфейс — это тот, который либо
•
реализуется непосредственно самим компонентом, или
•
реализуется одним из реализующих компонент классификаторов, или
•
предоставляется общедоступным портом компонента (рис. 9.4.).
Weather
d
Forecast
WeatherServices
Рис. 9.4. Компонент Weather Services предоставляет (реализует)
интерфейс прогноза погоды
195
Требуемый интерфейс.
Необходимый интерфейс либо:
•
обозначенный зависимостью использования от самого компонента, или
•
обозначенный зависимостью использования от одного из реализующих
компонент классификаторов, или
•
требуется общедоступным портом компонента (рис. 9.5.).
lOrder
С
Services
UserServices
С
Рис. 9.5. Для компонента User Services требуется интерфейс
IOrderServices
Внешний вид компонента.
Компонент имеет внешний вид или вид «черного ящика» с помощью
символов интерфейса, торчащих из поля компонента, раскрывающих его
общедоступные свойства и операции.
При необходимости к интерфейсу, порту и самому компоненту можно
прикрепить такое поведение, как конечный автомат протокола, для более
точного определения внешнего представления путем явного определения
динамических ограничений в последовательности вызовов операций. Другие
варианты поведения также могут быть связаны с интерфейсами или
соединителями
для
определения
«контракта»
между
участниками
сотрудничества (например, с точки зрения вариантов использования,
действий или спецификаций взаимодействия).
В качестве альтернативы интерфейсы и/или отдельные операции и
атрибуты могут быть перечислены в ячейках окна компонента (для
масштабируемости инструменты могут предлагать способ перечисления и
сокращения свойств и поведения компонентов) (рис. 9.6.).
196
«component» f~~|
UserServices
«provided interfaces»
lUserServices
«required interfaces»
lOrderServices
Рис. 9.6. Внешний вид компонента пользовательских служб — он
предоставляет интерфейс IUserServices и требует интерфейса
IOrderServices.
Для
отображения
полной
сигнатуры
интерфейса
компонента
интерфейсы также могут отображаться в виде типичных прямоугольников
классификатора, которые можно развернуть для отображения сведений об
операциях и событиях.
9.2.3 Стереотипы стандартных компонентов
Существует несколько стандартных стереотипов UML, применимых к
компонентам:
Таблица 6
Стереотипы стандартных компонентов UML
Имя
Описание
«BuildComponent»
Набор элементов, определенных для целей разработки на
системном уровне, таких как компиляция и управление
версиями.
"Сущность"
Постоянный информационный компонент, представляющий
бизнес-концепцию.
«Entity»
Customer
Компонент сущности Клиент
197
Стереотипы стандартных компонентов UML
Имя
Описание
"Воплощать в жизнь"
Реализация — это определение компонента, которое не
предназначено для самой спецификации. Скорее, это
реализация для отдельной «Спецификации», от которой она
зависит.
"Процесс"
Процесс — это компонент, основанный на транзакциях.
«Реализация»
Реализация — это классификатор, который определяет
домен объектов, а также определяет физическую реализацию
этих объектов.
Например,
компонент,
стереотипизированный
«Реализацией»,
будет
только
иметь
реализующие
классификаторы, которые реализуют поведение, заданное
отдельным компонентом «Спецификация». Это отличается
от «ImplementationClass», потому что класс реализации —
это реализация класса, которая может иметь такие функции,
как атрибуты и методы, полезные для разработчиков систем.
"Услуга"
Служба — это функциональный компонент без сохранения
состояния.
«Service»
WeatherServices
Сервисный компонент WeatherServices
"Спецификация"
Спецификация — это классификатор, который определяет
домен объектов, не определяя физическую реализацию этих
объектов.
Например, компонент со стереотипом «Спецификация»
будет
иметь
только
предоставленные
и
требуемые
интерфейсы и не предназначен для каких-либо реализующих
классификаторов как часть его определения. Это отличается
198
Стереотипы стандартных компонентов UML
Имя
Описание
от «типа», потому что «тип» может иметь такие функции,
как
и
атрибуты
методы,
для
полезные
аналитиков,
моделирующих системы.
«Спецификация»
и
«Реализация»
используются
для
моделирования компонентов с различными определениями
спецификации и реализации, где одна спецификация может
иметь несколько реализаций.
«Подсистема»
Подсистема — это компонент, представляющий единицу
иерархической декомпозиции для
используемый
для
моделирования
больших
систем и
крупномасштабных
компонентов. Определения подсистем могут различаться в
разных предметных областях и программных методах.
Ожидается,
что
профили
домена
и
метода
будут
специализировать этот элемент.
Подсистема обычно создается косвенно. Подсистема может
иметь элементы спецификации и реализации.
9.2.4 История
Обозначение компонента в виде прямоугольника классификатора с
ключевым словом «component» было введено в UML 2.0.
В предыдущих версиях UML 1.x компонент представлял собой
прямоугольник с двумя маленькими прямоугольниками, выступающими из
его сторон. Из соображений обратной совместимости эта нотация все еще
может использоваться в UML 2.5 (рис. 9.7.).
199
Рис. 9.7. Компонент CustomerEJB в нотации UML 1.x.
В UML 1.4.2 стереотип «сущность» представлял собой пассивный
класс, т.е. класс, объекты которого не инициируют взаимодействия сами по
себе. «Сущность» стала постоянным информационным компонентом в UML
2.0.
Стереотип
задавал
«процесс»
классификатор,
представляющий
тяжеловесный поток управления в UML 1.4.2. «Процесс» стал компонентом,
основанным на транзакциях, в UML 2.0.
В UML 1.4.2 «подсистема» — это особый вид пакета, используемый
для
представления
единицы
поведения
в
физической
системе
и,
следовательно, в модели, а также в качестве единицы спецификации для
поведения содержащихся в ней элементов модели. «Подсистема» стала
стереотипом компонента
для представления единицы иерархической
декомпозиции для больших систем в UML 2.0.
UML 2.0 также представил стандартные стереотипы компонентов
«BuildComponent», «Implement» и «Service».
9.3. Интерфейс
Интерфейс
согласованных
—
это
классификатор,
общедоступных
функций
который
и
объявляет
обязательств.
набор
Интерфейс
определяет контракт. Любой экземпляр классификатора, который реализует
интерфейс, должен выполнять этот контракт и, таким образом, предоставлять
услуги, описанные в контракте.
Поскольку интерфейсы являются объявлениями, они не могут быть
созданы. Вместо этого спецификация интерфейса реализуется экземпляром
инстанцируемого классификатора, что означает, что инстанцируемый
200
классификатор
представляет
соответствующий
фасад,
общедоступный
спецификации интерфейса.
Любой данный классификатор может реализовывать более одного
интерфейса.
Интерфейс
быть
может
реализован
рядом
различных
классификаторов.
Связь между интерфейсом и любым другим классификатором
подразумевает, что соответствующая ассоциация должна существовать
между
любой
реализацией
классификатором.
этого
частности,
В
интерфейса
ассоциация
и
этим
между
другим
интерфейсами
подразумевает, что между реализациями интерфейсов должна существовать
соответствующая ассоциация.
Обозначение. Интерфейс может быть показан с помощью символа
прямоугольника с ключевым словом «интерфейс» перед именем (рис. 9.8).
«interface»
SiteSearch
Рис. 9.8. Интерфейс SiteSearch
Обязательства,
представлены
в
могут
быть
связаны
различных
видов
ограничений
которые
виде
с
интерфейсом,
(таких
как
предварительные и постусловия) или спецификаций протокола, которые
могут налагать ограничения на упорядочение взаимодействий через
интерфейс (рис. 9.9.).
«interface»
Pageable
+ UNKNOWN_N_OF_PAGES: int = -1
+ getNumberOfPagesO: int
+ getPageFormat(int): PageFormat
+ getPrintable(int): Printable
Рис. 9.9. Интерфейс Pageable
201
Интерфейсы,
классификатором,
реализованные
являются
его
предоставляемыми интерфейсами и представляют обязательства, которые
экземпляры этого классификатора имеют перед своими клиентами. Они
описывают услуги, которые экземпляры этого классификатора предлагают
своим клиентам.
Интерфейс, участвующий в зависимости реализации интерфейса,
показан в виде кружка или шара, помечен названием интерфейса и
прикреплен сплошной линией к классификатору, реализующему этот
интерфейс (рис. 9.10.).
Рис. 9.10. Интерфейс SiteSearch, участвующий в реализации
SearchService
Требуемый интерфейс определяет сервисы, которые необходимы
классификатору для выполнения своих функций и выполнения собственных
обязательств перед своими клиентами. Он определяется зависимостью
использования между классификатором и соответствующим интерфейсом.
Зависимость использования от классификатора к интерфейсу показана
путем представления интерфейса полукругом или сокетом, помеченным
именем интерфейса, прикрепленным сплошной линией к классификатору,
которому требуется этот интерфейс (рис. 9.11).
SiteSearch
—c
Search
Controller
Рис. 9.11. Интерфейс SiteSearch используется SearchController
На практике часто бывает так, что два или более интерфейсов взаимно
связаны зависимостями, зависящими от приложения. В таких ситуациях
каждый интерфейс представляет определенную роль в многостороннем
202
«протоколе». Эти типы связей ролей протоколов могут быть зафиксированы
ассоциациями между интерфейсами.
Интерфейс в UML можно использовать в качестве пространства имен
для других классификаторов, включая классы, интерфейсы, варианты
использования и т.д. Вложенные классификаторы видны только в
пространстве имен содержащего интерфейса.
Редакции.
В UML 1.4 интерфейс был формально эквивалентен абстрактному
классу без атрибутов и методов, а только с абстрактными операциями.
9.4. Класс
Класс — это классификатор, описывающий набор объектов,
имеющих одинаковые:
•
особенности,
•
ограничения,
•
семантику (значение).
Класс отображается в виде прямоугольника со сплошным контуром,
содержащего
имя класса,
и,
возможно,
с отсеками,
разделенными
горизонтальными линиями, содержащими функции или другие элементы
классификатора.
Поскольку
класс
является
наиболее
широко
используемым
классификатором, нет необходимости добавлять ключевое слово «класс» в
кавычках над именем класса. Имя класса должно располагаться по центру и
выделено жирным шрифтом (рис. 9.12.), причем первая буква имени
класса должна быть заглавной (если набор символов поддерживает верхний
регистр).
Customer
Рис. 9.12. Класс Customer - подробности скрыты
203
Признаками класса являются атрибуты и операции (рис. 9.13).
Рис. 9.13. Класс SearchService — детали уровня анализа
Когда класс показан с тремя отсеками, средний отсек содержит список
атрибутов, а нижний отсек содержит список операций. Атрибуты и
операции должны быть выровнены по ширине, а первая буква имени
должна быть в нижнем регистре.
Характеристики, представленные функцией, могут относиться к
экземплярам
классификатора,
рассматриваемым
индивидуально
(не
статические), или к самому классификатору (статические). Один и тот же
признак не может быть статичным в одном контексте и нестатичным в
другом.
Что касается статических признаков, признаются две альтернативные
семантики. Статическая функция может иметь:
•
разные значения для разных классификаторов характеристик или
•
одинаковое значение для всех классификаторов признаков.
В соответствии с этой семантикой наследование значений статических
функций разрешено, но не требуется в UML 2.
Статические признаки подчеркнуты, но только имена. Многоточие (...)
в конце списка функций указывает на то, что дополнительные функции
существуют, но не отображаются в этом списке.
Атрибуты
класса
представлены
экземплярами
свойств,
принадлежащих классу. Некоторые из этих атрибутов могут представлять
навигационные концы бинарных ассоциаций.
204
Объекты класса должны содержать значения для каждого атрибута,
который является членом этого класса, в соответствии с характеристиками
атрибута, например, его типом и множественностью (рис. 9.14.).
SearchService
- config: Configuration
- engine: SearchEnglne
+ search( query: SearchRequest): SearchResult
- createEnqineO: SearchEngine
Рис. 9.14. Класс SearchService — детали уровня реализации, где
createEngine является статической операцией.
Атрибуты или операции могут быть сгруппированы по видимости.
Ключевое слово или символ видимости в этом случае можно указать один
раз для нескольких объектов с одинаковой видимостью (рис. 9.15.).
SearchService
private:
config: Configuration
engine: SearchEngine
private:
createEnqineO: SearchEngine
public:
search( query: SearchRequest): SearchResult
Рис. 9.15. Класс SearchService — атрибуты и операции, сгруппированные
по видимости
Дополнительные отсеки могут быть предоставлены для отображения
других деталей, таких как ограничения, или просто для разделения
функций.
Класс в UML можно использовать в качестве пространства имен для других
классификаторов, включая классы, интерфейсы, варианты использования и
т.д. Вложенные классификаторы видны только в пространстве имен
содержащего класса.
205
В UML 2.5 класс стал структурированным, инкапсулированным и
управляемым за счет расширения инкапсулированного классификатора и
поведенческого классификатора. Из-за этого любой класс может иметь
некоторую внутреннюю структуру и порты (рис. 9.16.).
Library
Services
Search Books
SearchVideo
o—
searchPort
Inventory
Рис. 9.16. Library Services — это структурированный класс,
инкапсулированный через порт searchPort.
Вложенность
классификаторов,
структурированного класса, ограничивает
в
определенных
видимость
рамках
классификаторов
областью пространства имен содержащего их структурированного класса и,
таким образом, поддерживает инкапсуляцию (сокрытие информации) через
порты (рис. 9.17.).
Рис. 9.17. Структурированный класс Online Shopping с торговым портом
и внутренней структурой.
9.5. Порт
Порт определяет точку взаимодействия, через которую классификатор
может
взаимодействовать
классификаторами
Инкапсулированный
или
со
своим
окружением,
со
своими
внутренними
классификатор
определен
в
с
другими
частями.
UML
как
структурированный классификатор с возможностью владения портами, и,
206
таким
образом,
порт
является
свойством
инкапсулированного
классификатора. Порт по умолчанию общедоступен.
Порт показан в виде маленького квадрата, который либо перекрывает
границу
прямоугольника,
классификатор,
либо
может
обозначающего
быть
показан
инкапсулированный
внутри
этого
символа
прямоугольника. Название порта размещено рядом с небольшой площадью
(рис. 9.18.).
Library
Services
search Port
Рис. 9.18. Класс библиотечных служб имеет порт searchPort.
Хотя UML не диктует правила именования портов, здравый смысл
состоит в том, чтобы начинать имена портов с нижнего регистра, например, "
p ", " port12 ", " searchPort ". Неясно, должен ли каждый порт иметь имя.
Если у порта есть имя, оно может быть скрыто на диаграмме. Спецификация
UML 2.5 дает странное пояснение, что «каждое изображение безымянного
порта обозначает порт, отличный от любого другого порта». Если имя
порта было просто подавлено, каждое изображение этого порта должно быть
одним и тем же портом.
Тип порта может быть указан после имени порта, разделенного
двоеточием ":" (рис. 9.19.).
Library
Services
search Port:
SearchBooks
Рис. 9.19. Класс Library Services имеет порт searchPort с типом
SearchBooks.
207
Кратность порта (если есть) указывается после имени порта в
квадратных скобках (рис. 9.20). И имя, и кратность порта являются
необязательными.
Library
Services
searchPort[1..6)
Рис. 9.20. Класс Library Services имеет от 1 до 6 портов searchPort.
Предоставленный интерфейс может быть показан с использованием
нотации «дерева», прикрепленного к порту. Требуемый интерфейс может
быть показан с помощью нотации «сокет», прикрепленной к порту (рис.
9.21.).
Library
Services
SearchBooks
SearchVideo
o—
search Port
Inventory
Рис. 9.21. Порт searchPort предоставляет интерфейсы SearchBooks и
SearchVideo и требует наличия интерфейса Inventory.
В
порту
поиска
класс
библиотечных
служб
полностью
инкапсулирован — его можно реализовать без каких-либо знаний о среде, в
которую будет встроен класс.
Если с портом связано несколько интерфейсов, эти интерфейсы могут
быть перечислены через запятую "," рядом со значком одного интерфейса
(рис. 9.23.).
208
Рис. 9.23. Несколько портов searchPort предоставляют интерфейсы
SearchBooks и SearchVideo и требуют наличия интерфейса Inventory.
Порт также может быть показан в виде маленького квадратного
символа, перекрывающего границу прямоугольного символа, обозначающего
часть, типизированную этим классификатором.
Простой порт.
Простой порт — это порт с одним требуемым или предоставляемым
интерфейсом (рис. 9.24.). Сложный порт имеет несколько предоставляемых
и/или обязательных интерфейсов.
Рис. 9.24. Компонент SearchEngine имеет простой порт searchPort
с единым интерфейсом ProductSearch.
В структурированном классификаторе UML допускает несколько
альтернативных обозначений для подключения простых портов к частям и
ролям.
Единственным обязательным обозначением соединения портов во
внутренней конструкции является соединение разъема непосредственно с
портами (рис. 9.25.). Дополнительные леденцы и сокеты могут отображать
предоставленные и требуемые интерфейсы подключенных портов.
209
Я
«subsystem» Accounting
internal structure
Account
c
: Orders
:Customers
Рис. 9.25. Простые порты, соединенные напрямую соединителем,
обязательная нотация UML. Компонент «Клиенты» обеспечивает
интерфейс «Учетная запись» для части «Заказы».
Как вариант, UML позволяет присоединять соединительную линию к
шару и гнезду вместо портов, как показано ниже (рис. 9.26.).
«subsystem» Accounting
g~~|
internal structure
о
1p Account
Customers
Рис. 9.26. Шар и гнездо соединены соединителем, необязательная
нотация UML. Компонент «Клиенты» обеспечивает интерфейс «Учетная
запись» для части «Заказы».
Соединитель сборки не отображается в другом необязательном
обозначении «шарик и гнездо» для простых портов (рис. 9.27.). Это
обозначение не следует использовать для соединения сложных портов или
частей без портов.
210
Рис. 9.27. Сборочное соединение типа «шар-и-гнездо» для простых
портов, необязательная нотация UML. Компонент «Клиенты»
обеспечивает интерфейс «Учетная запись» для части «Заказы».
Сервисный порт.
Порт
может
указывать
услуги,
которые
инкапсулированный
классификатор предоставляет своей среде, а также услуги, которые
инкапсулированный классификатор требует от своей среды. Любой порт по
умолчанию является служебным портом,
который определяется по
умолчанию истинным значением атрибута isService порта.
Предоставляемые
интерфейсы
порта
описывают
запросы
к
классификатору, которые другие классификаторы могут делать через этот
порт. Необходимые интерфейсы порта описывают запросы, которые могут
быть сделаны от классификатора к его среде через порт.
Когда для атрибута isService порта задано значение false, это означает,
что этот порт принадлежит реализации инкапсулированного классификатора
и не является частью контракта службы или важной видимой извне
функциональности. Такой неслужебный порт может быть изменен или
удален без каких-либо последствий для контракта на обслуживание.
Спецификация UML не дает объяснения, зачем нужен этот атрибут, если мы
можем просто изменить общедоступную видимость порта по умолчанию,
например, на частную видимость. Частные свойства не являются частью
каких-либо видимых извне функций.
211
UML не предоставляет специальных обозначений для визуального
отличия служебных портов от неслужебных портов, но имеет некоторые
соглашения
для
отображения
атрибутов
логических
в
качестве
модификаторов свойств (рис. 9.28.). Например, {ordered} означает, что
атрибут isOrdered имеет значение true, а {unordered} означает, что
соответствующее
свойство
не
упорядочено.
Вероятно,
мы
можем
использовать то же соглашение для атрибута isService порта, отображая его
либо как {service}, либо как {nonservice}.
Рис. 9.28. Порт actPort по умолчанию является служебным портом,
предоставляющим интерфейсы Orders и Customers и требующим
интерфейса Inventory.
Порт поведения. Порт поведения — это такой порт, что запросы,
поступающие на этот порт, отправляются классификатору поведения,
владеющему
портом, а
не
пересылаются
некоторым
содержащимся
экземплярам. Если для этого классификатора не определено поведение,
любая связь, поступающая на порт поведения, теряется. По умолчанию
порты не являются портами поведения.
Порт поведения отображается как порт, соединенный сплошной
линией
с
небольшим
символом
классификатора, содержащего
состояния,
нарисованным
внутри
порт (рис. 9.29.). Небольшой символ
состояния обозначает поведение содержащего классификатора.
212
Library
Services
search Port
Рис. 9.29. Порт searchPort — это порт поведения с предоставленным
интерфейсом SearchBooks.
9.6. UML-соединитель
Соединитель — это функция, которая указывает ссылку, которая
обеспечивает связь между двумя или более экземплярами, играющими
определенные роли в структурированном классификаторе. Эта ссылка
может быть экземпляром ассоциации, или она может представлять
возможность того, что экземпляры могут взаимодействовать, потому что их
личности известны благодаря тому, что они передаются в качестве
параметров,
хранятся
в
потому что
переменных или слотах, или
взаимодействующие экземпляры являются тот же экземпляр.
Ссылка может быть реализована чем-то простым, например указателем,
или чем-то более сложным, например, сетевым соединением. В отличие от
ассоциаций, которые задают связи между любыми экземплярами связанных
классификаторов,
соединители
задают
связи
между
экземплярами,
воспроизводящими только связанные части.
Соединитель визуализируется с использованием нотации, похожей на
ассоциацию.
Необязательная
метка
соединителя
имеет
следующий
синтаксис:
connector-label::= [connector-name] [':'(association-namelassociation-class-name)]
где имя-соединителя — это имя соединителя, имя-ассоциации — имя
ассоциации, а имя-класса-ассоциации — имя класса ассоциации. Ключевое
слово или стереотип внутри кайр может быть помещен над или перед именем
213
соединителя на диаграмме. Строка свойства может быть размещена после
имени соединителя или под ним.
Компоненты соединения коннектора могут быть следующими:
•
разъем делегирования или
•
монтажный соединитель.
Тип атрибута соединителя является производным: соединитель с одним
или несколькими концами, подключенными к порту, который не находится в
части и не является портом поведения, является делегированием; иначе это
сборка.
Контракт коннектора — это набор поведений, которые определяют
допустимые шаблоны взаимодействия через коннектор.
Соединитель сборки. Соединитель сборки — это соединитель между
двумя или более деталями, или портами на деталях, который определяет, что
одна или несколько деталей предоставляют услуги, которые используют
другие детали.
Семантика времени выполнения для соединителя сборки заключается в
том, что сигналы проходят вдоль экземпляра соединителя. Несколько
коннекторов, направленных к разным частям и из них, или n-арные
коннекторы, где n > 2, указывают, что экземпляр, который будет создавать
или обрабатывать сигнал, будет определен во время выполнения.
Совместимость
интерфейсов
между
подключенными
портами
позволяет заменить существующий компонент в системе таким, который
(минимально) предлагает тот же набор услуг. Кроме того, в контекстах, где
компоненты
используются
для
расширения
системы,
предлагая
существующие службы, а также добавляя новые функции, соединители
можно использовать для связи в определении нового компонента.
214
Соединитель сборки обозначается как соединитель между двумя или
более деталями, или портами на деталях (рис. 9.30.).
«component»
Web Store
Рис. 9.30. Коннектор сборки между портами компонентов Authentication
и Customers
Когда соединитель сборки соединяет простые порты (порты, которые
обеспечивают или требуют один интерфейс), это может быть обозначено
соединением «шар-и-гнездо» между предоставленным интерфейсом и
требуемым интерфейсом (рис. 9.31.).
Рис. 9.31. Соединитель сборки между простыми портами компонентов
Authentication и Customers
Обозначение «шар-и-гнездо» нельзя использовать для соединения
«сложных» портов или частей без портов.
Если
несколько
компонентов
имеют
простые
порты,
которые
предоставляют или требуют один и тот же интерфейс, может быть показан
один символ, представляющий интерфейс, и линии от компонентов могут
быть проведены к этому символу. Этот вариант представления применим
независимо от того, показан ли интерфейс с использованием нотации «шари-гнездо» или просто с использованием требуемого или предоставленного
символа интерфейса (рис. 9.32.).
215
Рис. 9.32. Сборочный соединитель, который собирает три детали
Соединитель делегирования. Соединитель делегирования — это
соединитель, который связывает внешний контракт компонента (как указано
его портами) с реализацией этого поведения. Он представляет собой
пересылку событий (запросов операций и событий): сигнал, поступающий на
порт, который имеет соединитель делегирования для одной или нескольких
частей, или портов на частях, будет передан этим целям для обработки.
Соединитель делегирования — это декларация того, что поведение,
доступное для экземпляра компонента, на самом деле реализуется не самим
этим компонентом, а одним или несколькими экземплярами, имеющими
«совместимые» возможности. Эти ситуации моделируются с помощью
соединителя делегирования от порта к совместимым портам или частям.
Коннекторы делегирования можно использовать для моделирования
иерархической декомпозиции поведения, когда услуги, предоставляемые
компонентом, в конечном итоге могут быть реализованы компонентом,
вложенным
в
него
на
нескольких
уровнях.
Слово
делегирование
предполагает, что между подключенными портами будет происходить
конкретный поток сообщений и сигналов, возможно, на нескольких уровнях.
Следует отметить, что такой поток сигналов не всегда реализуется во всех
системных средах или реализациях (т. е. это может быть только время
разработки).
Порт может делегировать набор портов на подчиненных компонентах.
В этом случае эти подчиненные порты должны вместе предлагать
216
делегированные функции делегирующего порта. Во время выполнения
сигналы будут доставлены на соответствующий порт. В случаях, когда
несколько целевых портов поддерживают обработку одного и того же
сигнала, сигнал будет доставлен на все эти подчиненные порты.
Соединитель делегирования обозначается как соединитель от порта
делегирования к порту обработки или его части (рис. 9.33.).
Рис. 9.33. Соединитель делегирования от порта делегирования к части
UserServlet
Если делегирование обрабатывается простым портом, коннектор может
быть дополнительно показан подключенным к сокету (рис. 9.34. и 9.35.).
Рис. 9.34. Соединитель делегирования от делегирующего порта к
простому порту SearchEngine
Рис. 9.35. Соединитель делегирования от простого порта компонента
аутентификации к порту делегирования
217
9.7. Артефакт
Артефакт — это классификатор, представляющий некоторый
физический объект, часть информации, которая используется или создается
в процессе разработки программного обеспечения или при развертывании и
эксплуатации системы. Артефакт — это источник развертывания на узле.
Конкретный экземпляр (или «копия») артефакта развертывается в экземпляре
узла.
Некоторые примеры артефактов UML:
•
Текстовый документ
•
исходный файл
•
сценарий
•
бинарный исполняемый файл
•
архивный файл
•
таблица базы данных
Стандартный профиль UML определяет несколько стандартных
стереотипов, применимых к артефактам:
"файл"
Физический файл в контексте разработанной системы.
Стандартные стереотипы — подклассы «файла»:
"документ"
Общий файл, который не является «исходным» файлом
или «исполняемым файлом».
"источник"
Исходный файл, который можно скомпилировать в
исполняемый файл.
218
"библиотека"
Файл статической или динамической библиотеки.
«исполняемый» Файл программы, который может выполняться в
компьютерной системе.
«сценарий»
Файл сценария, который может быть интерпретирован
компьютерной системой.
Стандартный стереотип UML 1.x, который сейчас устарел:
"стол"
Таблица в базе данных.
Стандартные стереотипы могут быть дополнительно адаптированы к
реализации и специфичным для платформы стереотипам в профилях.
Например, профиль Java может определять «jar» как подкласс
«executable» для исполняемых архивов Java. Ожидается, что определенные
профили обеспечат некоторый стереотип для артефактов, представляющих
наборы файлов.
Спецификации UML определяют артефакт как подкласс абстрактного
развернутого артефакта (рис. 9.36.). Развернутый артефакт описывается как
артефакт или экземпляр артефакта, развернутый в целевом объекте
развертывания. Здравый смысл говорит, что отношения должны быть
обратными - развернутый артефакт должен быть подклассом артефакта, в то
время как должно быть разрешено, чтобы некоторые артефакты вообще не
развертывались.
219
Рис. 9.36. Абстрактный синтаксис UML Artifact.
Артефакты могут иметь свойства, представляющие особенности
артефакта, и операции, которые можно выполнять над его экземплярами.
Артефакты
имеют
атрибут
fileName
—
конкретное
имя,
которое
используется для ссылки на артефакт в физическом контексте — например,
имя файла или URI. Артефакт мог иметь вложенные артефакты.
Артефакты развертываются в целевом объекте развертывания .
Спецификация экземпляра была расширена в UML, чтобы разрешить
развертывание
экземпляров
артефактов
артефактов
в
отношении
развертывания .
Артефакт представляется с помощью обычного прямоугольника класса
с ключевым словом «артефакт». Примеры в спецификации UML также
отображают значок документа в правом верхнем углу (рис. 9.37. - 9.39.).
220
«artifact» D
web-app.war
Рис. 9.37. Артефакт web-app.war
«source»
D
UserServices.es
Рис.9.38. Артефакт исходного файла C# UserServices.cs
«library» D
commons.dll
Рис.9.39. Библиотека commons.dll
В качестве альтернативы артефакт может быть изображен значком
(рис. 9.40.).
web-tools-lib.jar
Рис.9.40. Артефакт web-tools-lib.jar
При необходимости подчеркивание имени экземпляра артефакта может
быть
опущено,
поскольку
предполагается,
что
контекст
известен
пользователям.
Ассоциации между артефактами. Артефакты могут быть вовлечены в
ассоциации с другими артефактами, например, ассоциации композиции.
Например, артефакт дескриптора развертывания для компонента может
содержаться в артефакте, манифестирующем этот компонент (рис. 9.41.).
221
Таким образом, компонент и его дескриптор развертываются в экземпляре
узла как один экземпляр артефакта.
Рис. 9.41. Артефакт book-club.ear приложения содержит артефакт userservice.jar EJB и дескриптор развертывания.
Зависимость между артефактами. Артефакты могут быть вовлечены
в отношения зависимости с другими артефактами.
Зависимость между артефактами обозначается так же, как и общая
зависимость, т.е. общей пунктирной линией с открытой стрелкой,
направленной от артефакта клиента к артефакту поставщика (рис. 9.42.).
Рис. 9.42. Артефакт book-club.war зависит от артефакта web-tools-lib.jar.
9.8. Реализация компонента
Реализация компонента — это специализированная зависимость
реализации,
используемая
классификаторов,
которые
для
(необязательного)
определения
контракт,
предлагаемый
реализуют
компонентом, с точки зрения предоставляемых им интерфейсов и
требуемых интерфейсов.
Поведение
компонента
обычно
может
быть реализовано
(или
реализовано) несколькими классификаторами. По сути, он формирует
222
абстракцию для набора элементов модели. В этом случае компонент владеет
набором зависимостей реализации компонента от этих классификаторов.
Реализация компонента обозначается так же, как и зависимость
реализации,
т.
е.
общей
пунктирной
линией
от
реализующих
классификаторов к реализованному компоненту с полым треугольником в
качестве стрелки (Рис. 9.43.).
Рис. 9.43. Компонент UserService, реализованный UserServlet и UserDAO.
Для приложений, которым требуется несколько различных наборов
реализаций для спецификации одного компонента, набор стандартных
стереотипов определен в стандартном профиле UML. В частности, для этого
там определены «Спецификация» и «Реализация».
Компонент может быть показан с использованием внутреннего
представления или представления «белого ящика», раскрывающего его
частные свойства и реализующего классификаторы (рис. 9.44.). Этот вид
показывает, как внешнее поведение реализуется внутри. Реализующие
классификаторы могут быть перечислены в дополнительном отсеке
«реализации». Отсеки также можно использовать для отображения списка
любых частей и соединителей или любых артефактов реализации.
223
«component»
UserServices
«provided interfaces»
I UserServices
«required interfaces»
lOrderServices
«realizations»
UserServlet
UserDAO
«artifact»
UserService.jar
Рис. 9.44. Представление компонента User Services в виде белого ящика реализовано UserServlet и UserDAO и проявляется в артефакте
UserService.jar.
В качестве альтернативы
внутренние классификаторы, которые
реализуют поведение компонента, могут отображаться вложенными в форму
компонента (рис. 9.45.).
Рис. 9.45 Представление компонента User Services в виде белого ящика -
реализуется UserServlet и UserDAO.
9.9. Зависимость
Зависимость в UML была рассмотрена в данной книге в разделе 2
пункте 6.6 на примере зависимости в диаграмме пакетов. Для диаграммы
компонентов описанная выше теория остается актуальной.
224
9.10. Использование
Использование — это отношения зависимости, в которых один
элемент (клиент) требует другого элемента (или набора элементов)
(поставщика) для его полной реализации или работы.
Зависимость использования не указывает, как клиент использует
поставщика, кроме того факта, что поставщик используется определением
или реализацией клиента. Например, это может означать, что некоторые
методы в классе (клиент) используют объекты (например, параметры)
другого класса (поставщика).
Зависимость
использования
отображается
как
зависимость
с
прикрепленным к ней ключевым словом «использовать» (рис. 9.46.).
Рис. 9.46. Класс SearchController использует класс SearchEngine.
Создавать.
Создание
—
это
зависимость
использования,
означающая, что классификатор клиента создает экземпляры классификатора
поставщика. Обозначается стандартным стереотипом «create» (рис. 9.47.).
Рис. 9.47. Класс DataSource создает Connection.
Создать также может указать, что назначенный признак создает
экземпляр
классификатора,
к
которому
присоединен
признак.
Эта
зависимость может быть повышена до классификатора, содержащего
функцию.
Create может связать значение экземпляра с конструктором для класса,
описывая единственное значение, возвращаемое операцией конструктора
(рис. 9.48.). Операция — это клиент, созданный экземпляр — поставщик.
225
Значение
экземпляра
может
ссылаться
на
параметры,
объявленные
операцией.
Рис. 9.48. Конструктор учетной записи создает новые экземпляры
учетной записи
Instantiate — это еще одна зависимость использования среди
классификаторов,
указывающая,
что
операции
на
клиенте
создают
экземпляры поставщика. Обозначается стандартным стереотипом «создавать
экземпляры».
Не очень понятно, почему в стандарте UML 2.4 есть и «создать», и
«создать экземпляр».
Вызов
Call — это зависимость использования, которая указывает, что
исходная операция вызывает целевую операцию. Эта зависимость может
связывать исходную операцию с любой целевой операцией, находящейся в
области действия, включая, помимо прочего, операции включающего
классификатора и операции других видимых классификаторов.
Вызов обозначается стандартным стереотипом «вызов», источником и
целью которого является операция.
Это отношение также может быть применено к классу, содержащему
операцию, в том смысле, что в классе существует операция, к которой
применяется зависимость.
Послать
226
Send — это зависимость использования, источником которой
является операция, а целью — сигнал, указывающий, что источник
отправляет целевой сигнал.
Отправка обозначается стандартным стереотипом «отправить».
Требуемый интерфейс
Требуемый интерфейс определяет сервисы, которые необходимы
классификатору для выполнения своих функций и выполнения собственных
обязательств перед своими клиентами. Он определяется зависимостью
использования
между
классификатором
и
соответствующим
интерфейсом.
Зависимость использования от классификатора к интерфейсу показана
путем представления интерфейса полукругом или сокетом, помеченным
именем интерфейса, прикрепленным сплошной линией к классификатору,
которому требуется этот интерфейс (рис. 9.49.).
SiteSearch
—c
Search
Controller
Рис. 9.49. Интерфейс SiteSearch используется (обязательно)
SearchController.
Если интерфейс представлен в виде прямоугольника, зависимость
использования интерфейса обозначается стрелкой зависимости (рис. 9.50.).
Классификатор в конце стрелки использует (требует) интерфейс в начале
стрелки.
Рис. 9.50. Интерфейс SiteSearch используется (обязательно)
SearchController.
227
10. UML ДИАГРАММЫ РАЗВЁРТЫВАНИЯ
10.1. Определение и типы UML диаграмм развертывания
Диаграмма развертывания — это структурная диаграмма, которая
показывает
архитектуру
системы как развертывание (распределение)
программных артефактов по целям развертывания. По-другому диаграмму
развертывания называют диаграммой размещения.
Артефакты представляют собой конкретные элементы физического
мира, являющиеся результатом процесса разработки. Примерами артефактов
являются исполняемые файлы, библиотеки, архивы, схемы баз данных,
файлы конфигурации и т. д.
Цель развертывания обычно представлена узлом, который является
либо аппаратным устройством, либо некоторой программной средой
выполнения. Узлы могут быть соединены коммуникационными путями
для создания сетевых систем произвольной сложности.
Обратите
внимание,
что
компоненты
были
непосредственно
развернуты на узлах на диаграммах развертывания UML 1.x. В UML 2.x
артефакты развертываются на узлах, и артефакты могут манифестировать
(реализовывать)
компоненты.
Компоненты
развертываются
узлах
на
косвенно через артефакты.
Диаграммы развертывания могут описывать архитектуру на уровне
спецификации (также называемом
уровнем
типа) или
на
уровне
экземпляра (аналогично диаграммам классов и диаграммам объектов).
Диаграмма развертывания на уровне спецификации показывает
некоторый обзор развертывания артефактов в целях развертывания без
ссылок на конкретные экземпляры артефактов или узлов.
Диаграмма развертывания на уровне экземпляра показывает
развертывание экземпляров артефактов в конкретных экземплярах целей
развертывания. Его можно использовать, например, для отображения
различий в развертывании в среде разработки, промежуточной или
228
производственной среде с именами/идентификаторами конкретных серверов
или устройств сборки, или развертывания.
Распространенные типы диаграмм развертывания:
•
Реализация (проявление) компонентов артефактами;
•
Диаграмма развертывания уровня спецификации;
•
Диаграмма развертывания на уровне экземпляра;
•
Сетевая архитектура системы.
10.2. Понятия UML диаграмм развертывания
10.2.1 Проявление
Проявление — это отношение абстракции, которое представляет
конкретную физическую визуализацию (реализация) одного или нескольких
элементов модели с помощью артефакта или использование элементов
модели при построении или генерации артефакта. Артефакт представляет
один или несколько элементов модели.
Обратите внимание, что поскольку артефакты UML 2.0 могут
манифестировать
любые
упаковываемые
элементы,
а
не
только
компоненты, как это было в предыдущих версиях UML.
Артефакт владеет воплощениями, каждое из которых представляет
использование упаковываемого элемента.
Ожидается, что определенные профили стереотипизируют отношения
проявления, чтобы указать на определенные формы проявления. Например,
«сгенерированный инструмент» и «пользовательский код» могут быть
двумя проявлениями разных классов, воплощенных в артефакте.
Проявление обозначается так же, как и абстракция, т. е. пунктирной
линией
с
открытой
стрелкой,
направленной
от
артефакта
к
упаковываемому элементу (например, к компоненту или пакету) и
помечается ключевым словом «манифест» (рис. 10.1.).
229
Рис. 10.1 EJB-компонент UserService и скелет веб-сервисов
манифестируются (реализуются) EJB-модулем user-service.jar
артефактом
В UML 1.x концепция проявления называлась реализацией и
аннотировалась как «реализовать». Поскольку это было одним из многих
случаев использования слова «реализация», в UML 2.x оно было заменено на
«манифест».
10.2.2 Цель развертывания
Артефакты
развертываются
в
целях
развертывания.
развертывания — это место для развернутого артефакта (рис. 10.2.).
230
Цель
Рис. 10.2. UML 2.4 определение цели развертывания
Спецификация экземпляра была расширена в UML 2.0, чтобы
позволить экземпляру узла быть целью развертывания в отношениях
развертывания.
Свойство также было расширено в UML 2.0 за счет возможности быть
целью развертывания
в
отношениях
развертывания.
Это
позволяет
моделировать развертывание на иерархических узлах, свойства которых
функционируют как внутренние части.
Целевой
объект
развертывания
владеет
набором
целевых
развертываний.
Цель развертывания сама по себе не имеет конкретных обозначений,
см. обозначения для подклассов.
10.2.3 Узел
Узел — это цель развертывания, которая представляет собой
вычислительный ресурс, на котором артефакты могут быть развернуты для
выполнения.
231
Узел показан в виде трехмерного куба в перспективе (рис. 10.3).
Рис. 10.3. Узел сервера приложений
Узел
связан
упаковываемыми
с
развертыванием
элементами,
которые
артефактов
и
косвенно
участвуют
в
проявлениях
с
артефакта, развернутого на узле.
Узлы могут быть связаны между собой коммуникационными
путями. Пути связи могут быть определены между узлами, такими как
сервер приложений и сервер базы данных, чтобы определить возможные
пути связи между узлами. Конкретные сетевые топологии затем могут быть
определены через ссылки между экземплярами узлов.
Узел специализируется на:
•
устройство
•
среда выполнения
Иерархический узел. Иерархические узлы можно моделировать,
используя композицию или определяя внутреннюю структуру. Внутренняя
структура узла определяется с точки зрения частей и соединителей. Части
узла могут быть только узлами (рис. 10.4.).
232
Рис. 10.4. Блок сервера приложений запускает несколько веб-серверов и
серверов J2EE.
Среда выполнения обычно является частью общего узла или
«устройства», которое представляет собой физическую аппаратную среду, в
которой находится эта среда выполнения. Среды выполнения могут быть
вложенными (например, среда выполнения базы данных может быть
вложена в среду выполнения операционной системы) (рис. 10.5).
Рис. 10.5. Несколько сред выполнения, вложенных в серверное
устройство
Экземпляры среды выполнения назначаются экземплярам узла с
помощью составных ассоциаций между узлами и средами выполнения, где
среда выполнения играет роль части.
233
10.2.4 Устройство
Устройство
—
это
узел,
представляющий
физический
вычислительный ресурс с возможностью обработки, на котором артефакты
могут быть развернуты для выполнения.
Устройство визуализируется как узел (перспектива, трехмерный вид
куба), аннотированный ключевым словом «устройство» (рис. 10.6.).
71
«device»
Application
Server
Рис. 10.6. Устройство сервера приложений
UML не предоставляет стандартных стереотипов для устройств.
Примеры ненормативных стереотипов для устройств:
•
«сервер приложений»
•
«клиентская рабочая станция»
•
«мобильное устройство»
•
«встроенное устройство»
Устройство может отображаться с помощью пользовательского значка
(рис. 10.7. - 10.10.). Профили, стереотипы и значения тегов можно
использовать для предоставления пользовательских значков и свойств для
устройств.
«application server»
IBM System x37S5 М3
Рис. 10.7. Устройство сервера приложений, отображаемое с помощью
пользовательского значка
234
L
«Computer»
Vendor = “Acer"
CPU = “AMD Phenom X4"
Memory = “4 GB DDR2"
T
Рис. 10.8 Стереотип компьютера с тегами, примененными к классу
устройств.
4
«database server»
Sun SPARC Server
Рис. 10.9. Устройство сервера базы данных, отображаемое с помощью
пользовательского значка
«mobile device»
smartphone
Рис. 10.10. Мобильный смартфон с пользовательским значком
Устройства могут быть сложными (т.е. они могут состоять из других
устройств), когда физическая машина разбивается на ее элементы, либо через
235
владение пространством имен, либо через атрибуты, типизированные
устройствами.
10.2.5 Среда выполнения
Среда выполнения — это (программный) узел, который предлагает
среду выполнения для определенных типов компонентов, развернутых на
нем в виде исполняемых артефактов. Компоненты соответствующего типа
развертываются в определенных средах выполнения.
Среда выполнения реализует стандартный набор сервисов, которые
требуются компонентам во время выполнения (на уровне моделирования эти
сервисы обычно неявны). Для каждого развертывания компонента аспекты
этих услуг могут определяться свойствами в спецификации развертывания
для конкретного типа среды выполнения.
Среда выполнения обозначается так же, как узел (перспектива,
трехмерное представление куба), аннотируется стандартным стереотипом
UML «executionEnvironment» (рис. 10.11.).
/
S
«executionEnvironment»
J2EE Container
Рис. 10.11. Среда выполнения — контейнер J2EE
Этот «executionEnvironment» надоедлив в использовании. UML не
предоставляет никаких других стандартных стереотипов для сред
выполнения. Примеры разумных ненормативных стереотипов:
•
«Операционные системы» (рис. 10.12.)
•
«Двигатель рабочего процесса»
•
«Система баз данных» (рис. 10.13.)
•
«J2EE-контейнер»
236
«Веб сервер»
•
«Веб-браузер"
Рис. 10.12. Среда выполнения операционной системы Linux
«database system»
Oracle 10g
Рис. 10.13. Среда выполнения СУБД Oracle 10g
Среда выполнения может дополнительно иметь явный интерфейс
служб системного уровня, которые могут использоваться развернутыми
элементами, в тех случаях, когда разработчик модели хочет сделать явными
службы среды выполнения программного обеспечения среды выполнения.
10.2.6 Путь связи
Путь связи — это ассоциация между двумя целями развертывания,
посредством которой они могут обмениваться сигналами и сообщениями.
Коммуникационный путь обозначается как ассоциация и не имеет
дополнительных обозначений по сравнению с ассоциацией (рис. 10.14.).
Рис. 10.14. Путь связи между несколькими серверами приложений и
серверами баз данных.
237
Обратите внимание, что, когда целями развертывания являются
некоторые физические устройства, путь связи обычно представляет собой
физическое соединение между узлами (рис. 10.15.).
Рис. 10.15. Gigabit Ethernet как канал связи между серверами
приложений и баз данных.
Когда целями развертывания являются среды выполнения, путь связи
обычно представляет собой некоторый протокол (рис. 10.16.).
Рис. 10.16. Протокол TCP/IP как путь связи между сервером J2EE и
системой базы данных.
10.2.7 Развертывание
Развертывание — это отношение зависимости, описывающее
выделение
(развертывание)
артефакта
в
цель
развертывания.
Развертывание также может быть определено на уровне экземпляра — как
выделение определенного экземпляра артефакта конкретному экземпляру
цели развертывания.
Развертывание компонентов — это развертывание одного или
нескольких
артефактов,
или
экземпляров
артефактов,
параметризованных спецификацией развертывания.
238
опционально
Не очень понятно, почему UML определяет развертывание как
зависимость, а не как ассоциацию или просто направленную связь.
Основное противоречие заключается в том, что зависимость в UML не имеет
никаких последствий во время выполнения и определяется в терминах
элементов модели, а не в терминах их экземпляров. В то же время UML 2.4
позволяет и показывает примеры экземпляров артефактов, развернутых на
экземплярах узлов.
Развертывание может быть показано как зависимость от артефакта
(поставщика) до цели развертывания (клиента) и помечена словом «deploy»
(рис. 10.17.). Обратите внимание, что зависимость обычно указывает от
клиента к поставщику, то есть в направлении, противоположном тому, что
рекомендуется для развертывания в UML 2.4.
С другой стороны,
спецификация UML позволяет изменять направление зависимости в
зависимости от условий пользователя.
Рис. 10.17. Архив веб-приложений J2EE, port.war,
развернутый на сервере Apache Tomcat JSP.
На
«уровне
экземпляра»
экземпляры
артефактов
могут
быть
развернуты в определенных экземплярах цели развертывания (рис. 10.18.).
Подчеркивание имени экземпляра артефакта может быть опущено.
239
Рис. 10.18. Архив веб-приложений J2EE Portal.war, развернутый
на двух экземплярах JSP-сервера Apache Tomcat — psrv_023 и psrv_037.
Для
моделирования
сложных
целевых
моделей
развертывания,
состоящих из узлов с составной структурой, определяемой посредством
«частей», свойство (которое функционирует как часть) также может быть
целью развертывания.
Развертывание может быть показано с развернутыми артефактами,
содержащимися в цели развертывания (рис. 10.19.).
Рис. 10.19. Артефакт porto.ear, развернутый на сервере приложений.
Развертывание можно показать с помощью
текстового списка
развернутых артефактов в целевом объекте развертывания (рис. 10.20.).
Рис. 10.20. Артефакты Portugal.ear, Stocks.ear, Weather.ear развернуты в
контейнере J2EE 1.4.
240
Развертывание
может отображаться в
прямоугольной рамке с
названием развертывания в ячейке в левом верхнем углу (рис. 10.21.).
Полное название заголовка диаграммы — deployment, а сокращенное — dep.
dep User Services
2________________ /
«deploy»
«ejb-jar»
-----------_>
user-service.jar
«J2ee server»
WebSphere
6.1
Рис. 10.21. Развертывание пользовательских служб показано на
диаграмме.
10.2.8 Спецификация развертывания
Спецификация развертывания — это артефакт, определяющий набор
свойств
развертывания,
определяют
которые
параметры
выполнения
артефакта компонента, развернутого на узле. Спецификация развертывания
может быть нацелена на конкретный тип контейнера для компонентов.
Спецификация
параметризации
развертывания
отношения
—
это
механизм
для
распространенный
в
общий
развертывания,
различных аппаратных и программных технологиях. Ожидается, что элемент
спецификации развертывания будет расширен в профилях конкретных
компонентов.
Ненормативными
примерами
стандартных
стереотипов,
которые профиль может добавить в спецификацию развертывания, являются,
например, «concurrencyMode» с помеченными значениями {thread, process,
none}
или
«transactionMode»
с
помеченными
значениями
{transaction,nestedTransaction, none}.
Спецификация
развертывания
на
уровне
спецификации
отображается в виде прямоугольника классификатора с дополнительными
свойствами развертывания в ячейке (рис. 10.22.).
241
«deployment spec»
ejb-jar.xml
ejb-name: String
session-type: String
transaction-type: String
Рис. 10.22. Спецификация развертывания ejb-jar.xml
Артефакт,
спецификации
который
конкретизирует
развертывания
на
уровне
или
реализует
экземпляра,
свойства
называется
дескриптором развертывания (рис. 10.23.). Дескриптор развертывания
отображается в виде прямоугольника классификатора с подчеркнутым
именем и свойствами развертывания, имеющими определенные значения в
ячейке.
«deployment spec»
eib-iar.xml
ejb-name: UserService
session-type: Stateful
transaction-type: Bean
Рис. 10.23. Дескриптор развертывания ejb-jar.xml
Экземпляр спецификации развертывания с конкретными значениями
свойств развертывания может содержаться в сложном артефакте.
10.2.9 Зависимость спецификации развертывания
Спецификацию
развертывания
можно
отобразить
в
виде
прямоугольника классификатора, прикрепленного к артефакту компонента,
с помощью обычной стрелки зависимости, указывающей на развернутый
артефакт (рис. 10.24.).
242
Рис. 10.24. Спецификация развертывания ejb-jar.xml для артефакта user-
service.ejb.
10.2.10 Ассоциация спецификаций развёртывания
Спецификация
развертыванием
развертывания
может
компонента
артефакта
на
быть
узле.
В
с
связана
этом
случае
спецификация развертывания может быть показана в виде прямоугольника
классификатора, прикрепленного к развертыванию.
Обратите внимание, что в спецификации UML 2.4 эта ассоциация
показана пунктирной линией (в то время как связь обычно отображается
сплошной линией) (рис. 10.25.).
Рис. 10.25. Спецификация развертывания ejb-jar.xml, прикрепленная к
развертыванию.
10.2.11 UML-стереотип
10.2.11.1 Понятие UML-стереотипа
Стереотип—
это
класс
профиля,
который
определяет,
как
существующий метакласс может быть расширен как часть профиля. Он
позволяет использовать специфичную для платформы или предметной
243
области терминологию или обозначения вместо или в дополнение к тем,
которые используются для расширенного метакласса.
Стереотип не может использоваться сам по себе, но всегда должен
использоваться с одним из метаклассов, которые он расширяет. Стереотип
не может быть расширен другим стереотипом.
Стереотип использует ту же нотацию, что и класс, с ключевым словом
«стереотип», показанным до или над названием стереотипа (рис. 10.26.).
Имена стереотипов не должны конфликтовать с именами ключевых слов для
элемента расширенной модели.
Рис. 10.26. Стереотип Servletа расширяет компонент.
Стереотип может изменить графический вид элемента расширенной
модели с помощью прикрепленных значков, представленных классом
профиля изображения (рис. 10.27. и 10.28.).
Рис. 10.27. Стереотипный Servlet с прикрепленным пользовательским
значком.
244
Рис. 10.28. Актер расширен стереотипным веб-клиентом с
прикрепленным пользовательским значком.
Поскольку стереотип — это класс, он может иметь свойства (рис.
10.29.). Свойства стереотипа называются определениями тегов. Когда
стереотип применяется к элементу модели, значения свойств называются
помеченными значениями.
Рис. 10.29. Устройство расширено стереотипом сервера с определениями
тегов и пользовательским значком.
10.2.11.2 Применение стереотипов
Диаграмма профиля используется для демонстрации определения
стереотипа. Стереотип применяется, когда он используется на диаграммах
вариантов использования, диаграммах классов, диаграммах развертывания и
т. д.
Когда стереотип
применяется
к
элементу
модели,
экземпляр
стереотипа связывается с экземпляром метакласса. Название применяемого
245
стереотипа отображается в паре кайр выше или перед названием элемента
модели.
Версии UML
до
2.4
требовали,
чтобы
первая
буква имени
применяемого стереотипа была в нижнем регистре (например, «Servlet»)
(рис. 10.30.). Начиная с UML 2.4, первая буква обычно должна быть в
верхнем
регистре.
Именование
приложений-стереотипов
строчными
буквами, где сами стереотипы определяются с использованием прописной
первой буквы, все еще допустимо, но считается устаревшим.
«Servlet»
SearchServlet
Рис. 10.30. Стереотип «Servlet» применительно к элементу модели
SearchServlet
Если к одному и тому же элементу применяется несколько
стереотипов, имена примененных стереотипов отображаются в виде списка,
разделенного запятыми, внутри пары кайр.
Когда в расширенном элементе модели есть ключевое слово, то имя
стереотипа может отображаться рядом с ключевым словом, внутри
отдельных кайм (пример: «устройство» «сервер»).
Когда стереотип включает в себя определение значка, этот значок
может быть графически прикреплен к элементам модели, расширяемым
стереотипом.
Каждый
элемент
модели,
имеющий
графическое
представление, может иметь прикрепленную иконку. Когда элемент модели
расширен одним единственным стереотипом, значок может быть представлен
в уменьшенной форме внутри и сверху поля, представляющего элемент
модели (рис. 10.31.).
io"
SearchServlet
Рис. 10.31. Стереотип Servletа применен к классу SearchServlet.
246
При применении стереотипа весь блок классификатора может быть
заменен увеличенной иконкой стереотипа (рис. 10.32.).
ю
SearchServlet
Рис. 10.32. Стереотип Servletа применен к классу SearchServlet.
Некоторые
элементы
модели
уже
используют
значок
для
представления по умолчанию. Типичным примером этого является элемент
модели актера, в котором используется значок «человечек». В этом случае,
когда элемент модели расширяется стереотипом со значком, значок
стереотипа заменяет значок представления по умолчанию на диаграммах
(рис. 10.33. и 10.34.).
«Web Client»
Geek
Рис. 10.33. Стереотип «веб-клиент» применительно к актеру-гику .
«Computer»
Vendor = "Acer"
CPU = “AMD Phenom X4”
Memory = “4 GB DDR2"
У
0
Рис. 10.34. Стереотип компьютера с тегами, примененными к классу
устройств.
247
10.2.11.3 Стереотипные отношения
Стереотип всегда должен использоваться в сочетании с одним из
метаклассов, которые он расширяет. Метакласс может быть расширен
одним или несколькими стереотипами. Каждый стереотип может расширять
один или несколько метаклассов.
Стереотипы
могут
участвовать
в
бинарных
ассоциациях.
Противоположный класс может быть другим стереотипом, нестереотипным
классом, принадлежащим профилю или метаклассу. Стереотип должен
иметь свойство в конце ассоциации, чтобы иметь возможность перейти к
противоположному классу. Если противоположный конец не является
стереотипом, противоположное свойство должно принадлежать самой
ассоциации.
Стереотип может обобщать или специализировать только другой
стереотип (рис. 10.35.).
«stereotype»
Session EJB
«stereotype»
Stateless EJB
«stereotype»
Stateful EJB
Рис. 10.35. Объект Session EJB с абстрактным стереотипом
специализируется на стереотипах Stateless EJB и Stateful EJB.
10.2.11.4 Определение тега
Свойства
стереотипа
называются
метасвойствами) (рис. 10.36.).
248
определениями
тегов
(или
Рис. 10.36. Стереотип Компьютер с определениями тегов для
производителя, ЦП и памяти
Помеченное
значение.
Стереотип
применяется,
когда
он
используется на диаграммах вариантов использования, диаграммах классов,
диаграммах развертывания и т. д.
Когда стереотип применяется к элементу модели, значения его свойств
могут называться тегированными значениями.
В UML 1.x теговое значение определяется как один из механизмов
расширения UML, позволяющий прикреплять к моделям произвольную
информацию (которая не может быть выражена с помощью UML). Теговое
значение — это пара ключевое слово-значение, которую можно прикрепить к
любому элементу модели.
Ключевое слово
называется
тегом.
Каждый тег
представляет
определенный тип свойства, применимый к одному или нескольким типам
элементов модели. И тег, и значение обычно кодируются как строки, хотя
инструмент UML позволяет использовать другие типы данных для значений.
Спецификация
тегового
значения
в
UML
1.x
имеет
вид
«имя» = «значение», где имя — это имя тега или атрибута метамодели, а
значение — произвольная строка, обозначающая его значение. Например,
{аиЛог="Джо Смит", крайний срок=31 марта 1997 г., статус=анализ}
Логические теги часто имеют форму isQuality, где качество — это
некоторое условие, которое может быть истинным или ложным. В этих
случаях форма «качество» обычно может появляться сама по себе, без
значения
и
по
умолчанию
имеет
249
значение
true.
Например,
{abstract}совnаgает с {isAbstract=true}. Чтобы указать значение false,
полностью опустите имя. Теги других типов требуют явных значений.
Теговое значение (а также атрибут метамодели) отображается в виде
последовательности свойств, разделенных запятыми, внутри пары фигурных
скобок "{" и "}" (рис. 10.37.).
«Computer»
{Vendor = “Acer",
CPU = “AMD Phenom X4",
Memory = "4 GB DDR2”}
Aspire X1300
Рис. 10.37. Стереотипный компьютер, примененный с использованием
«традиционных» обозначений значений тегов.
В UML 1.3 помеченные значения могли расширять элемент модели, не
требуя наличия стереотипа. В UML 1.4 эта возможность, хотя и по-прежнему
поддерживается,
объявлена
устаревшей
и
используется только
по
соображениям обратной совместимости.
Начиная с UML 2.0, помеченное значение может быть представлено
только как атрибут, определенный в стереотипе. Поэтому элемент модели
должен быть расширен стереотипом, чтобы его можно было расширить
помеченными значениями. Для обеспечения совместимости с UML 1.3
некоторые инструменты UML могут автоматически определять стереотип, к
которому будут присоединены «несвязанные» атрибуты (помеченные
значения).
Значения тегов могут отображаться в разделе класса под именем
стереотипа (рис. 10.38.). Для каждого применяемого стереотипа, значения
которого необходимо отобразить, требуется дополнительное отделение.
Каждое такое отделение озаглавлено названием применяемого стереотипа.
250
«Computer»
Aspire X1300
«Computer»
Vendor = “Acer"
CPU = “AMD Phenom X4’
Memory = “4 GB DDR2"
Рис. 10.38. Стереотипный компьютер со значениями тегов в
отсеке/отделении
Значения тегов могут отображаться в прикрепленном комментарии
под названием стереотипа (рис. 10.39.).
Рис. 10.39. Стереотипный компьютер, примененный со значениями тега
в примечании к комментарию
При отображении в ячейках или в символе комментария каждая пара
"имя-значение" должна отображаться на отдельной строке.
10.3. UML диаграмма проявления компонентов артефактами
В то время как диаграммы компонентов показывают компоненты и
отношения между компонентами и классификаторами, а диаграммы
развертывания — развертывание артефактов в целях развертывания,
некоторая отсутствующая промежуточная диаграмма — это диаграмма
проявления,
которая
(реализации)
компонентов
используется
для
артефактами
демонстрации
проявления
и
структурой
внутренней
артефактов.
Поскольку диаграммы проявления не определены спецификацией
UML 2.4, проявление компонентов в виде артефактов можно показать с
помощью диаграмм компонентов или диаграмм развертывания (рис. 10.40.).
251
Рис. 10.40. UML диаграмма проявления компонентов артефактами.
10.4. UML диаграмма развертывания уровня спецификации
Диаграмма развертывания уровня спецификации (также называемого
уровнем типа) показывает некоторый обзор развертывания артефактов в
целях развертывания без ссылки на конкретные экземпляры артефактов или
узлов (рис. 10.41.).
252
Рис. 10.41. UML диаграмма развертывания на уровне спецификации —
веб-приложение развернуто на сервере Tomcat JSP, а схемы базы данных
в системе баз данных.
10.5. UML диаграмма развертывания на уровне экземпляра
Диаграмма
развертывания
на
уровне
экземпляра
показывает
развертывание экземпляров артефактов в конкретных экземплярах целей
развертывания. Его можно использовать, например, для отображения
различий в развертывании в среде разработки, промежуточной или
производственной среде с именами/идентификаторами конкретных серверов
развертывания или устройств.
В приведенном ниже примере веб-приложение развернуто на сервере
приложений wsrv-01, а несколько схем баз данных — на сервере баз данных
dbsrv-14 (рис. 10.42.).
253
Рис. 10.42. UML диаграмма развертывания на уровне экземпляра —
веб-приложение развернуто на сервере Tomcat JSP, а схемы базы данных
— в системе баз данных.
10.6. Сетевая архитектура уровня спецификации
10.6.1. Понятие и схема сетевой архитектуры
Стандарт UML не имеет отдельного вида диаграмм для описания
сетевой архитектуры и не содержит конкретных элементов, связанных с
сетью. Диаграммы развертывания могут использоваться для этой цели, как
правило,
с
некоторыми
дополнительными
сетевыми
стереотипами.
Диаграмма сетевой архитектуры обычно показывает сетевые узлы и пути
связи между ними.
Пример сетевой диаграммы ниже показывает сетевую архитектуру с
конфигурацией,
называемой
«демилитаризованная
зона
с
двумя
брандмауэрами» (рис. 10.43.). Демилитаризованная зона (DMZ) — это узел
или сегмент сети, расположенный в «нейтральной зоне» между Интернетом и
внутренней сетью организации (частной сетью).
254
Это
предотвращает
получение внешними пользователями прямого доступа к внутренней сети
организации, в то же время не открывая доступ к веб-серверу, электронной
почте или DNS-серверу напрямую из Интернета.
устройство
Коммуникационный
«Firewall»
Cisco ASA 5585-X
«Firewall»
Cisco ASA 5585-X
«Router»
Cisco 7613
«Switch»
Linksys SR2016
«Switch»
Linksys SR2O16
устройство
S10
«Web servep>
«DNS server»
>
<Application serve p
Рис. 10.43. Обзор схемы сетевой архитектуры — сетевые устройства и
связь.
Обратите внимание, что на этой диаграмме используются сетевые
значки, которые не являются частью стандарта UML. Стандарт UML для узла
или устройства — трехмерное представление куба.
10.6.2. Сетевые устройства
Эталонная архитектура системы Windows Server (WSSRA) (см. Схема
сетевой архитектуры Microsoft [MSNAB 05]) использует следующие
сетевые устройства для демонстрации общей сетевой архитектуры:
•
Переключение устройств
•
Маршрутизаторы
•
Устройства балансировки нагрузки
•
Устройства брандмауэра
255
•
Устройства виртуальной частной сети (VPN)
Ни одно из этих устройств не определено в стандарте UML, поэтому в
большинстве приведенных ниже описаний и примеров используются сетевые
значки и описания, предоставленные Microsoft как часть чертежей.
Центр. Концентратор — это сетевое устройство, которое связывает
сетевые компоненты, такие как рабочие станции и серверы, на уровне 1 OSI
(L1). Концентратор содержит порт для каждого сетевого устройства и
копирует данные, полученные на один порт, на каждый другой порт,
независимо от того, требуется это или нет. Из-за этого очень вероятны
коллизии при передаче данных.
Если два устройства, подключенные к хабу, начинают передачу
одновременно, возникает коллизия. В результате фреймы ошибок будут
скопированы на все устройства, подключенные к хабу. По мере увеличения
сетевой активности коллизии становятся более частыми.
Концентраторы больше не считаются сетевыми компонентами в
Microsoft WSSRA (см. Microsoft Network Devices Blueprint [MSNAB 05]),
поскольку они в значительной степени были заменены коммутаторами.
Концентраторы все еще могут использоваться в некоторых случаях,
таких как сетевое взаимодействие между членами кластеров серверов,
поддерживающее механизм сердцебиения узлов кластера.
Выключатель. Коммутатор — это сетевое устройство, которое
перемещает сетевые пакеты с одного устройства на другое на уровне 2 OSI.
Коммутирующие устройства могут определять MAC-адреса устройств
назначения пакетов путем мониторинга сетевого трафика. Как только адреса
назначения определены, коммутаторы могут отправлять определенные
пакеты на порт, который подключается к сетевому адаптеру с определенным
MAC-адресом. (Концентраторы отправляют каждый пакет на все порты.)
256
Коммутаторы
уровня
предприятия
могут
иметь
возможность
маршрутизировать пакеты на уровне 3 OSI между сегментами сети и, таким
образом, могут использоваться в качестве маршрутизаторов (рис. 10.44.).
«Switch»
Linksys SR2016
Рис. 10.44. Сетевой коммутатор.
Маршрутизатор. Маршрутизатор — это сетевое устройство, которое
перемещает пакеты данных из одного сегмента сети в другой на основе
адресов уровня 3 OSI (рис. 10.45.). Устройства маршрутизации способны
обмениваться информацией с другими маршрутизаторами в сети, чтобы
определить наиболее эффективный путь от одного устройства к другому.
«Router»
Cisco 7613
Рис.10.45. Сетевой маршрутизатор.
Балансировщик нагрузки. Балансировщик нагрузки — это сетевое
устройство, облегчающее горизонтальную кластеризацию, когда несколько
серверов настроены для выполнения одной и той же функции в сети (рис.
10.46.). Функциональность балансировки нагрузки может быть обеспечена
программным обеспечением или аппаратным устройством одним из двух
способов:
•
Распределенный — каждый узел в кластере получает каждый пакет,
предназначенный для кластера.
257
•
Routed — балансировщик нагрузки получает каждый входящий пакет,
предназначенный для кластера, и определяет, на какой хост в кластере
отправить пакет.
«Load balancer»
А10АХ 1030 ADC
Рис. 10.46. Балансировщик сетевой нагрузки.
Межсетевой экран. Брандмауэр — это сетевое устройство, которое
управляет потоком трафика между сегментами сети, используя адреса
уровня 3 OSI, чтобы соответствовать требованиям безопасности (рис. 10.47.).
Службы брандмауэра могут быть реализованы с помощью специального
аппаратного устройства (в частности, для защиты границы между внутренней
сетью и Интернетом) или с помощью сетевого узла, на котором работает
программный брандмауэр.
«Firewall» Cisco
ASA 5585-X
Рис. 10.47. Сетевой брандмауэр.
Брандмауэр
имеет
набор
правил,
позволяющих
устройству,
выполняющему роль службы брандмауэра, определять, какой трафик
разрешен для прохождения или, наоборот, какой трафик запрещен. В
большинстве брандмауэров есть правило «неявного отказа», поэтому, если
правило, разрешающее запрос, не существует, запрос отклоняется.
10.6.3. Сегменты сети
Сегмент сети определяется как два или более устройств, которые
взаимодействуют друг с другом на уровне 2 OSI (L2) с использованием
258
устройств подключения к локальной сети уровня 2 без маршрутизации на
уровне 3 между ними.
сети
Сегменты
(виртуальными).
могут
быть
физическими
сегменты
Логические
или
называются
логическими
виртуальными
локальными сетями (VLAN).
Устройства подключения L2 LAN перемещают пакеты данных на
уровне 2 OSI между хостами или устройствами в одном сегменте сети. Эта
функциональность обычно обеспечивается коммутатором.
Устройства подключения L3 LAN перемещают пакеты данных на
уровне 3 OSI между несколькими сегментами сети. Эта функциональность
обычно предоставляется маршрутизаторами или балансировщиками
нагрузки.
Локальные сети (LAN) создаются путем соединения либо нескольких
сетевых узлов через устройство подключения к локальной сети уровня 2,
либо нескольких сегментов сети с помощью устройства подключения к
локальной сети уровня 3. Провода устройств подключения L2 и L3 LAN
обычно принадлежат организации. Скорость подключения между хостами и
устройствами в сегментах сети или между сегментами сети в локальной сети
обычно составляет 10 мегабит в секунду (Мбит/с), 100 Мбит/с или 1 Гбит/с.
Глобальные сети формируются путем объединения одной или
нескольких локальных сетей с помощью устройств и технологий глобальной
сети. Устройства подключения конечных точек к глобальной сети обычно
принадлежат
организации,
а
промежуточные
устройства
обычно
принадлежат операторам телефонной связи.
Магистраль. Магистраль — это канал, который соединяет несколько
коммутаторов вместе (рис. 10.48.).
259
«Database server»
«Database server»
«Web server»
Рис. 10.48. Пример сетевой магистрали.
Магистраль обычно масштабируется, чтобы обеспечить возможность
одновременного обмена несколькими сетевыми компьютерами и серверами в
соответствии со скоростью и количеством устройств на ней. Например,
магистраль может быть рассчитана на 1 гигабит в секунду (Гбит/с), чтобы
обеспечить несколько обменов данными на скорости 100 Мбит/с по
магистрали между клиентскими компьютерами и серверами, подключенными
к коммутаторам на скорости 100 Мбит/с.
Мультидоминг.
Множественная
адресация
серверов
—
это
использование нескольких сетевых адаптеров на одном сервере или
использование нескольких IP-адресов на одном сервере (что может
использоваться
с
одним
или
несколькими
сетевыми
адаптерами).
Использование нескольких сетевых адаптеров подразумевает использование
нескольких IP-адресов.
Несколько
сетевых адаптеров на одном устройстве позволяют
разделить трафик для повышения производительности и/или повышения
безопасности.
Примерами
множественной
260
адресации
являются
общедоступный брандмауэр с отдельными сетевыми интерфейсами для
применения правил безопасности и маршрутизации, а также веб-сервер
периметра с несколькими сетевыми интерфейсами для разделения периметра
и внутреннего трафика, а также для обеспечения переднего интерфейса для
балансировки нагрузки.
10.7. Диаграмма артефактов
10.7.1. Понятие и схема диаграммы артефактов
Диаграмма артефактов (artifact diagram) - это один из двух видов
диаграмм, предназначенных для моделирования физических аспектов
объектно-ориентированных систем.
Диаграмма
артефактов
показывает
организацию и зависимости между наборами артефактов. Стоит отметить,
что данную диаграмму иногда рассматривают как отдельную, но мы будем её
трактовать, как один из видов диаграмм развёртывания.
Такие диаграммы используются для моделирования статического
представления реализации системы, включая моделирование физических
сущностей, размещаемых на узлах (например, исполнимых программ,
библиотек,
таблиц,
файлов,
документов
разного
рода).
Диаграммы
артефактов - это, по своему существу, диаграммы классов, которые
сосредоточены на артефактах системы.
Диаграммы
артефактов
важны
не
только
для
визуализации,
специфицирования и документирования систем, основанных на артефактах,
но также для конструирования исполняемых систем посредством прямого и
обратного проектирования.
Диаграммы артефактов показывают физический состав компьютерной
системы (рис. 10.49.). Артефакты представляют собой файлы, базы данных и
подобные им физические наборы битов. Диаграммы данного типа часто
применяются в сочетании с диаграммами размещения. Также показывают
классы и компоненты, реализованные ими. UML трактует диаграммы
261
артефактов как разновидность диаграмм размещения, но мы рассматриваем
их отдельно.
Рис. 10.49. Схема диаграммы артефактов
10.7.2. Применение диаграммы артефактов
Диаграммы артефактов применяются для моделирования статического
представления реализации системы. Это представление в первую очередь
поддерживает управление конфигурацией частей системы, состоящих из
артефактов, которые могут быть собраны разными способами для построения
работающей системы.
Когда моделируется статическое представление реализации системы,
то диаграммы артефактов обычно используются одним из следующих
четырех способов:
1. Для моделирования исходного кода. В большинстве современных
объектно-ориентированных языков программирования код пишется в
интегрированных средах разработки, сохраняющих исходные тексты в
файлах. Диаграммы артефактов можно применять для моделирования
конфигурации этих файлов, которые представляют собой рабочие продукты,
и установки вашей системы управления конфигурацией.
262
2. Для моделирования исполняемых версий. Версия (release) - это
относительно полный и согласованный набор артефактов, поставляемый
внутреннему или внешнему пользователю. Версия в данном понимании
сосредоточена на тех частях, которые необходимы для поставки работающей
системы. При моделировании версий с помощью диаграмм артефактов
происходят визуализация, специфицирование и документирование решений,
принятых относительно физических составляющих системы, то есть
артефактов размещения.
3. Для моделирования физических баз данных. Представьте себе
физическую базу данных как конкретную реализацию схемы, существующую
в мире битов. Схемы, по сути, описывают API для доступа к хранимой
информации; модель же физической базы представляет способы хранения
информации в таблицах реляционной базы или на страницах объектно­
ориентированной базы данных. Для представления этих и иных физических
баз данных можно использовать диаграммы артефактов.
4. Для моделирования адаптируемых систем. Некоторые системы
достаточно статичны: их компоненты появляются на сцене, принимают
участие в исполнении, а затем покидают ее. Другие системы более
динамичны: они включают в себя мобильных агентов, или артефакты,
мигрирующие с целью балансирования нагрузки и восстановления после
сбоев. Поведение таких систем моделируется диаграммами артефактов
совместно с некоторыми другими диаграммами UML.
10.7.3. Основные элементы диаграммы артефактов
Для того чтобы рассуждать о поведении информационной или иной
системы,
создаются
диаграммы
вариантов
использования.
Словарь
предметной области описывается диаграммами классов. Чтобы внести
ясность, как сущности из этого словаря совместно работают для обеспечения
нужного
поведения,
применяются
диаграммы
последовательности,
коммуникации, состояний и деятельности. В конечном счете логические
263
чертежи превращаются в реалии из мира битов - исполняемые программы,
библиотеки,
таблицы,
файлы
и
различные
документы.
При
этом
обнаруживается, что некоторые из этих артефактов приходится создавать "с
нуля". Поэтому диаграмма артефактов показывает набор артефактов и связей
между ними. Изображается в виде графа с вершинами и дугами (ребрами).
Артефакты представляют собой конкретные элементы физического
мира, являющиеся результатом процесса разработки. Примерами артефактов
являются исполняемые файлы, библиотеки, архивы, схемы баз данных,
файлы конфигурации и т. д.
У диаграммы артефактов, как и у всех диаграмм, есть имя и
графическое наполнение. От остальных типов диаграмм она отличается
своим содержимым.
Диаграммы артефактов обычно содержат артефакты, а также связи
зависимости, обобщения, ассоциации и реализации (рис. 10.50.). Подобно
другим диаграммам, могут содержать примечания и ограничения.
Рис. 10.50. Диаграмма артефактов
264
Логический класс HelloWorld показан в верхнем прямоугольнике (рис.
10.51.). Все другие пиктограммы на рисунке символизируют артефакты UML
в представлении реализации системы. Артефакт - это физическая сущность,
такая как файл. Артефакт по имени hello.java представляет исходный код
логического класса HelloWorld; этим файлом могут манипулировать среда
разработки и инструменты управления конфигурацией. Исходный код может
быть
трансформирован
в
бинарный
апплет
hello.class
с
помощью
компилятора Java, что делает его пригодным для запуска в среде виртуальной
машины Java. Как исходный текст, так и бинарный апплет физически
реализуют логический класс. Это показано пунктирными стрелками,
помеченными ключевым словом «manifest».
Рис. 10.51. Артефакты HelloWorld
Спецификации UML определяют артефакт как подкласс абстрактного
развернутого артефакта. Развернутый артефакт описывается как артефакт
или экземпляр артефакта, развернутый в целевом объекте развертывания
(рис. 10.52.). Здравый смысл говорит, что отношения должны быть
обратными - развернутый артефакт должен быть подклассом артефакта, в то
265
время как должно быть разрешено, чтобы некоторые артефакты вообще не
развертывались.
Рис. 10.52. Абстрактный синтаксис UML Artifact
Артефакты могут иметь свойства, представляющие особенности
артефакта, и операции, которые можно выполнять над его экземплярами.
Артефакты
имеют
атрибут
fileName
—
конкретное
имя,
которое
используется для ссылки на артефакт в физическом контексте — например,
имя файла или URI. Артефакт мог иметь вложенные артефакты.
Артефакты развертываются в целевом объекте развертывания.
Спецификация экземпляра была расширена в UML, чтобы разрешить
развертывание
экземпляров
артефактов
артефактов
в
отношении
развертывания.
Артефакт представляется с помощью обычного прямоугольника класса
с ключевым словом «артефакт» (рис. 10.53. - 10.55.). Примеры в
266
спецификации UML также отображают значок документа в правом верхнем
углу.
Рис. 10.53. Артефакт web-app.war
«source»
D
UserServices.es
Рис. 10.54. Артефакт исходного файла C# UserServices.cs
«library»
D
commons.dll
Рис. 10.55. Библиотека commons.dll
В качестве альтернативы артефакт может быть изображен значком
(рис. 10.56.).
web-tools-lib.jar
Рис. 10.56. Артефакт web-tools-lib.jar
При необходимости подчеркивание имени экземпляра артефакта может
быть
опущено,
поскольку
предполагается,
пользователям.
267
что
контекст
известен
Ассоциации между артефактами. Артефакты могут быть вовлечены в
ассоциации с другими артефактами, например, ассоциации композиции.
Например, артефакт дескриптора развертывания для компонента может
содержаться в артефакте, манифестирующем этот компонент (рис. 10.57.).
Таким образом, компонент и его дескриптор развертываются в экземпляре
узла как один экземпляр артефакта.
Рис. 10.57. Артефакт book-club.ear приложения содержит артефакт user-
service.jar EJB и дескриптор развертывания.
Зависимость между артефактами. Артефакты могут быть вовлечены
в отношения зависимости с другими артефактами.
Зависимость между артефактами обозначается так же, как и общая
зависимость, т.е.
общей пунктирной линией с открытой стрелкой,
направленной от артефакта клиента к артефакту поставщика (рис. 10.58.).
Рис. 10.58. Артефакт book-club.war зависит от артефакта web-tools-lib.jar
Диаграммы артефактов применяются для моделирования статического
представления реализации системы. Это представление в первую очередь
поддерживает управление конфигурацией частей системы, состоящих из
268
артефактов, которые могут быть собраны разными способами для построения
работающей системы. го использования старых артефактов.
В UML диаграммы артефактов используются в целях визуализации
статического аспекта физических артефактов и их связей, а кроме того,
описания их деталей для конструирования.
10.7.4. Советы и рекомендации по диаграмме артефактов
При создании диаграмм артефактов следует помнить, что каждая такая
диаграмма - это графическое представление реализации системы, это
означает, что каждая диаграмма артефактов не должна отражать всё, что
известно о реализации системы, потому как все диаграммы артефактов в
совокупности будут представлять систему с точки зрения реализации, но
каждая диаграмма в отдельности описывает лишь один аспект.
Хорошо структурированная диаграмма артефактов:
• сосредоточена на выражении какого-то одного аспекта статического
представления реализации системы;
• содержит только те элементы, которые существенны для понимания
реализации системы;
• представляет уровень детализации,
соответствующий ее уровню
абстракции, включая лишь те дополнения, которые важны для
понимания на данном уровне.
При создании диаграммы артефактов необходимо:
• присваивать диаграмме имя, описывающее ее назначение;
• располагать
элементы
так,
чтобы
минимизировать
количество
пересекающихся линий;
• пространственно организовывать элементы так, чтобы семантически
близкие сущности оказывались рядом;
269
• использовать примечания и цветовые выделения для привлечения
внимания к важным моментам диаграммы;
• осторожно применять элементы со стереотипами. Выделять небольшой
набор
общих
для
проекта
(или
использовать их согласованно.
270
организации)
пиктограмм
и
11. UML ДИАГРАММА ПРОФИЛЯ
11.1. Понятие и схема UML диаграммы профиля
Диаграмма профиля — это структурная диаграмма, которая
описывает упрощенный механизм расширения UML путем определения
пользовательских стереотипов, значений тегов и ограничений. Профили
позволяют адаптировать метамодель UML для различных:
•
платформ, таких как Java Platform, Enterprise Edition (Java EE) или
Microsoft .NET Framework, или
•
Доменов,
таких
как
моделирование
бизнес-процессов,
сервис-
ориентированная архитектура, медицинские приложения и т.д.
Например, семантика стандартных элементов метамодели UML может
быть специализирована в профиле. В модели с профилем «модель Java»
обобщение классов должно иметь возможность ограничиваться одиночным
наследованием без необходимости явно назначать стереотип «класс Java»
каждому экземпляру класса.
Механизм
профилей
не
является
первоклассным
механизмом
расширения. Он не позволяет изменять существующие метамодели или
создавать новые метамодели, как это делает MOF. Профиль позволяет
адаптировать или настраивать
существующую метамодель только
с
конструкциями, специфичными для конкретной области, платформы или
метода.
Невозможно убрать какие-либо ограничения, применимые к
метамодели, но можно добавить новые ограничения, относящиеся к
профилю.
Настройки метамодели определяются в профиле, который затем
применяется к пакету. Стереотипы — это определенные метаклассы,
теговые значения — это стандартные метаатрибуты, а профили — это
определенные виды пакетов.
271
Профили можно динамически применять к модели или удалять из нее.
Их также можно динамически комбинировать, чтобы несколько профилей
применялись одновременно к одной и той же модели.
Графические узлы и ребра, используемые на диаграммах профилей:
профиль, метакласс, стереотип, расширение, ссылка, приложение
профиля (рис. 11.1.).
Рис. 11.1. Основные элементы UML диаграммы профиля — профиль,
стереотип, метакласс, расширение, профиль приложения.
Редакции. Профили присутствовали в UML 1.x. Диаграммы профилей
были введены в UML 2.0, но впервые появились в «официальной»
таксономии диаграмм UML в UML 2.2.
272
11.2. Профиль
Профиль — это пакет профилей, который расширяет эталонную
метамодель (например, UML), позволяя адаптировать или настраивать
метамодель с помощью конструкций, специфичных для конкретной области,
платформы или метода разработки программного обеспечения. Другими
словами, профиль — это облегченный механизм расширения стандарта UML.
Профиль
вводит
несколько
ограничений
на
обычное
метамоделирование посредством использования метаклассов, определенных
в этом пакете. Основной конструкцией расширения является стереотип,
который определяется как часть профиля и расширяет некоторый метакласс.
Профиль — это ограниченная форма эталонной метамодели, которая
всегда должна быть связана с некоторой эталонной метамоделью, созданной
из MOF, например, UML или CWM. Невозможно определить автономный
профиль без его эталонной метамодели.
Профиль использует ту же нотацию, что и пакет, с добавлением того,
что ключевое слово «профиль» отображается перед или над именем пакета
(рис. 11.2.).
«profile»
EJB
Рис. 11.2. Профиль EJB
Профиль может определять классы, стереотипы, типы данных,
примитивные типы, перечисления (рис. 11.3.).
273
Рис. 11.3. Серверы профилей
Один профиль может повторно использовать некоторые или все части
другого профиля для расширения уже существующих профилей. К одной и
той же модели можно применить несколько профилей.
Ограничения, являющиеся частью профиля, оцениваются,
когда
профиль применяется к пакету. Эти ограничения должны быть соблюдены,
чтобы модель была корректной.
Пакет, начиная с UML 2.4, имеет необязательный атрибут URI,
который служит уникальным идентификатором пакета. Профиль — это
пакет, а атрибут URI был введен в основном для поддержки обмена
профилями с использованием XMI.
Атрибут URI профиля может отображаться в форме {uri= uri} после
имени профиля. Нормативные профили OMG следуют нормативной схеме
именования OMG для URI. Для нестандартных пользовательских профилей
соглашение, рекомендованное OMG, выглядит так:
uri::= Ы1р://квалифицированный-родитель-профи:ль /версия-профиля /имя-профиля.х1ш
•
квалифицированный-профиль-родитель — это полное имя пакета,
содержащего профиль (если есть), с заменой «::» на «/» (прямая косая
274
черта) и удалением всех других недопустимых символов XML QName.
Например: www. uml-диаграммы. орг/ профили.
•
profile-version — это идентификатор версии профиля. Нормативные
профили OMG используют для этого дату в формате ГГГГММДД,
например: 20110331.
•
имя-профиля— это имя профиля, которое должно содержать только
допустимые символы XML QName. Например: ejb-30.
Обратите внимание, что спецификация UML здесь смешала две разные
спецификации. Все значение URI должно соответствовать устаревшей
спецификации URI RFC 2396 (см. Атрибут пакета URI), в то время как
часть Qualified-profile-parent также должна быть (или будет сделана)
допустимым XML QName (рис. 11.4.). XML QName обычно имеет префикс
пространства имен, за которым следует ':', например, 'taxes:dependent', что
противоречит требованию URI.
Рис. 11.4. Профиль EJB показан как пакет с атрибутом URI.
11.3. Метакласс
Метакласс — это класс профиля и пакетный элемент, который
может быть расширен за счет одного или нескольких стереотипов.
Метакласс может быть показан с необязательным стереотипом
«Метакласс», показанным выше или перед его именем (все «метаклассы» в
нижнем регистре использовались в версиях UML до 2.4) (рис. 11.5.).
275
«Metaclass»
Component
Рис. 11.5. Компонент метакласса
Метакласс
стереотипами с
может
быть
расширен
одним
или
использованием специального вида
несколькими
ассоциации
—
расширения (рис. 11.6.).
Рис. 11.6. Стереотипный компьютер расширяет метакласс устройства
11.4. Стереотип
11.4.1 Понятие UML-стереотипа
Стереотип
—
это
класс профиля, который определяет,
как
существующий метакласс может быть расширен как часть профиля. Он
позволяет использовать специфичную для платформы или предметной
области терминологию или обозначения вместо, или в дополнение к тем,
которые используются для расширенного метакласса.
Стереотип не может использоваться сам по себе, но всегда должен
использоваться с одним из метаклассов, который он расширяет. Стереотип
не может быть расширен другим стереотипом.
Стереотип использует ту же нотацию, что и класс, с ключевым словом
«стереотип», показанным до или над названием стереотипа (рис. 11.7.).
Имена стереотипов не должны конфликтовать с именами ключевых слов для
элемента расширенной модели.
276
Рис. 11.7. Стереотип Servletа расширяет компонент.
Стереотип может изменить графический вид элемента расширенной
модели с помощью прикрепленных значков, представленных классом
профиля изображения (рис. 11.8. и 11.9.).
Рис. 11.8. Стереотипный Servlet с прикрепленным пользовательским
значком.
Рис. 11.9. Актер расширен стереотипным веб-клиентом с
прикрепленным пользовательским значком.
Поскольку стереотип — это класс, он может иметь свойства. Свойства
стереотипа называются определениями тегов (рис. 11.10.). Когда стереотип
применяется
к
элементу
модели,
помеченными значениями.
277
значения
свойств
называются
Рис. 11.10. Устройство расширено стереотипом сервера с определениями
тегов и пользовательским значком.
11.4.2 Применение стереотипов
Диаграмма профиля используется для демонстрации определения
стереотипа. Стереотип применяется, когда он используется на диаграммах
вариантов использования, диаграммах классов, диаграммах развертывания и
т. д.
Когда стереотип
применяется
к
элементу
модели,
экземпляр
стереотипа связывается с экземпляром метакласса. Название применяемого
стереотипа отображается в паре кайр выше или перед названием элемента
модели.
Версии UML
до
2.4
требовали,
чтобы
первая
буква имени
применяемого стереотипа была в нижнем регистре (например, «servlet»).
Начиная с UML 2.4, первая буква обычно должна быть в верхнем регистре
(рис. 11.11.). Именование приложений-стереотипов строчными буквами, где
сами стереотипы определяются с использованием прописной первой буквы,
все еще допустимо, но считается устаревшим.
«Servlet»
SearchServlet
Рис. 11.11. Стереотип «Servlet» применительно к элементу модели
SearchServlet
278
Если к одному и тому же элементу применяется несколько
стереотипов, имена примененных стереотипов отображаются в виде списка,
разделенного запятыми, внутри пары кайр.
Когда в расширенном элементе модели есть ключевое слово, то имя
стереотипа может отображаться рядом с ключевым словом, внутри
отдельных кайм (пример: «устройство» «сервер»).
Когда стереотип включает в себя определение значка, этот значок
может быть графически прикреплен к элементам модели, расширяемым
стереотипом.
Каждый
элемент
модели,
имеющий
графическое
представление, может иметь прикрепленную иконку (рис. 11.12.). Когда
элемент модели расширен одним единственным стереотипом, значок может
быть
представлен
в
уменьшенной
форме
внутри
и
сверху
поля,
представляющего элемент модели.
ю
SearchServlet
Рис. 11.12. Стереотип Servletа применен к классу SearchServlet.
При применении стереотипа весь блок классификатора может быть
заменен увеличенной иконкой стереотипа (рис. 11.13.).
SearchServlet
Рис. 11.13. Стереотип Servletа применен к классу SearchServlet.
Некоторые
элементы
модели
уже
используют
значок
для
представления по умолчанию. Типичным примером этого является элемент
модели актера, в котором используется значок «человечек» (рис. 11.14.). В
этом случае, когда элемент модели расширяется стереотипом со значком,
значок стереотипа заменяет значок представления по умолчанию на
диаграммах (рис. 11.15.).
279
«Web Client»
Geek
Рис. 11.14. Стереотип «веб-клиент» применительно к актеру-Geek.
N
«Computer»
Vendor = "Acer"
CPU = “AMD Phenom X4"
Memory = “4 GB DDR2"
Рис. 11.15. Стереотип компьютера с тегами, примененными к классу
устройств.
11.4.3 Стереотипные отношения
Стереотип всегда должен использоваться в сочетании с одним из
метаклассов, которые он расширяет. Метакласс может быть расширен
одним или несколькими стереотипами. Каждый стереотип может расширять
один или несколько метаклассов.
Стереотипы
могут
участвовать
в
бинарных
ассоциациях.
Противоположный класс может быть другим стереотипом, нестереотипным
классом, принадлежащим профилю или метаклассу. Стереотип должен
иметь свойство в конце ассоциации, чтобы иметь возможность перейти к
противоположному классу. Если противоположный конец не является
стереотипом, противоположное свойство должно принадлежать самой
ассоциации.
Стереотип может обобщать или специализировать только другой
стереотип (рис. 11.16.).
280
Рис. 11.16. Объект Session EJB с абстрактным стереотипом
специализируется на стереотипах Stateless EJB и Stateful EJB.
11.4.4 Определение тега
Свойства
стереотипа
называются
определениями
тегов
(или
метасвойствами) (рис. 11.17.).
Рис. 11.17. Стереотип Компьютер с определениями тегов для
производителя, ЦП и памяти
Помеченное
значение.
Стереотип
применяется,
когда
он
используется на диаграммах вариантов использования, диаграммах классов,
диаграммах развертывания и т. д.
Когда стереотип применяется к элементу модели, значения его свойств
могут называться тегированными значениями.
В UML 1.x теговое значение определяется как один из механизмов
расширения UML, позволяющий прикреплять к моделям произвольную
информацию (которая не может быть выражена с помощью UML). Теговое
значение — это пара ключевое слово-значение, которую можно прикрепить к
любому элементу модели.
281
Ключевое
слово
называется
тегом.
Каждый
тег
представляет
определенный тип свойства, применимый к одному или нескольким типам
элементов модели. И тег, и значение обычно кодируются как строки, хотя
инструмент UML позволяет использовать другие типы данных для значений.
Спецификация
тегового
в
значения
UML
1.x
имеет
вид
«имя = значение», где имя — это имя тега или атрибута метамодели, а
значение — произвольная строка, обозначающая его значение. Например,
{аиЛог="Джо Смит", крайний срок=31 марта 1997 г., статус=анализ}
Логические теги часто имеют форму isQuality, где качество — это
некоторое условие, которое может быть истинным или ложным. В этих
случаях форма «качество» обычно может появляться сама по себе, без
значения
и
по
умолчанию
имеет
значение
true.
Например,
{abstract}совnаgает с {isAbstract=true}. Чтобы указать значение false,
полностью опустите имя. Теги других типов требуют явных значений.
Теговое значение (а также атрибут метамодели) отображается в виде
последовательности свойств, разделенных запятыми, внутри пары фигурных
скобок "{" и "}" (рис. 11.18.).
«Computer»
(Vendor = “Acer",
CPU = "AMD Phenom X4",
Memory = “4 GB DDR2”}
Aspire X1300
Рис. 11.18. Стереотипный компьютер, примененный с использованием
«традиционных» обозначений значений тегов.
В UML 1.3 помеченные значения могли расширять элемент модели, не
требуя наличия стереотипа. В UML 1.4 эта возможность, хотя и по-прежнему
поддерживается,
объявлена
устаревшей
соображениям обратной совместимости.
282
и
используется только
по
Начиная с UML 2.0, помеченное значение может быть представлено
только как атрибут, определенный в стереотипе. Поэтому элемент модели
должен быть расширен стереотипом, чтобы его можно было расширить
помеченными значениями. Для обеспечения совместимости с UML 1.3
некоторые инструменты UML могут автоматически определять стереотип, к
которому будут присоединены «несвязанные» атрибуты (помеченные
значения).
Значения тегов могут отображаться в разделе класса под именем
стереотипа (рис. 11.19.). Для каждого применяемого стереотипа, значения
которого необходимо отобразить, требуется дополнительное отделение.
Каждое такое отделение озаглавлено названием применяемого стереотипа в
кайрах.
«Computer»
Aspire Х1300
«Computer»
Vendor = “Acer"
CPU = "AMD Phenom X4
Memory = “4 GB DDR2"
Рис. 11.19. Стереотипный компьютер со значениями тегов в отсеке
Значения тегов могут отображаться в прикрепленном комментарии
под названием стереотипа (рис. 11.20.).
Рис. 11.20. Стереотипный компьютер, примененный со значениями тега
в примечании к комментарию
При отображении в ячейках или в символе комментария каждая пара
"имя-значение" должна отображаться на отдельной строке.
283
11.5. Расширение профиля UML
Расширение — это ассоциативное отношение, используемое для
указания того, что свойства метакласса расширяются через стереотип, и
дает возможность гибко добавлять стереотипы к классам и удалять их позже,
если это необходимо.
Один конец ассоциации расширения является обычным свойством, а
другой
конец
является
концом
расширения.
Свойство
связывает
расширение с метаклассом, в то время как конец расширения связывает
расширение со стереотипом, расширяющим метакласс.
Конец расширения является навигационным концом, принадлежащим
расширению. Это позволяет прикрепить экземпляр стереотипа к экземпляру
расширенного классификатора без добавления свойства к классификатору.
Обратите внимание, что до конца расширения UML 2.3" никогда не было
навигации".
Обозначение расширения представляет собой стрелку с закрашенным
треугольником, указывающую от стереотипа к расширенному метаклассу
(рис. 11.21.).
Рис. 11.21. Класс метакласса расширен стереотипом Клиент.
Поскольку расширение является подклассом ассоциации, оно может
иметь обычные украшения ассоциации, но стрелки навигации не должны
отображаться. Украшения расширения обычно подавляются.
Необязательное расширение означает, что экземпляр стереотипа
может быть связан с экземпляром расширенного метакласса по желанию, а
также впоследствии удален по желанию. Однако не требуется, чтобы каждый
экземпляр метакласса был расширен. Экземпляр стереотипа удаляется либо
284
при удалении экземпляра, расширенного метакласса, либо при удалении
профиля, определяющего стереотип, из применяемых профилей пакета.
По умолчанию расширение не требуется. Когда расширение не имеет
дополнений, это может означать либо значение по умолчанию, либо то, что
дополнение {required} было подавлено. Множественность 0...1 на конце
расширения может использоваться как альтернатива необязательным
расширениям.
Обязательное расширение означает, что экземпляр стереотипа всегда
должен быть связан с экземпляром расширенного метакласса. Экземпляр
стереотипа
обычно
удаляется
только
при
удалении
экземпляра,
расширенного метакласса или при удалении профиля, определяющего
стереотип, из применяемых профилей пакета.
Необходимое
расширение
отображается
с
помощью
свойства
{required} рядом с концом расширения (рис. 11.22.).
Рис. 11.22. Необходимое расширение компонента метакласса
стереотипом WebService.
Также разрешено использовать кратность 1 на конце расширения в
качестве альтернативы {обязательному}.
Метакласс
может
быть
расширен
одним
или
несколькими
стереотипами. Это очевидно и ожидаемо.
Каждый стереотип может расширять один или несколько метаклассов.
Это может вызвать некоторую путаницу. Например, спецификация UML 2.3
объясняет свой рисунок 18.16 так: «один и тот же стереотип Clock может
расширять либо компонент метакласса, либо класс метакласса». Либо
285
сбивает с толку, поскольку предполагает, что расширение является своего
рода или отношением, но не так, как мы предполагаем.
Тот же подход "либо" применяется в SoaML 1.0 Beta 2 — поставщик
стереотипов расширяет метаклассы интерфейса или класса (рис. 11.23.).
SoaML поясняет, что Interface используется в случае не составного контракта
на обслуживание, а Class — в случае составного контракта на обслуживание.
Рис. 11.23. Поставщик стереотипов расширяет метаклассы интерфейса
или класса.
11.6. Ссылка
Ссылка — это отношение импорта, представленное импортом
элемента «metaclassReference» и импортом пакета «metamodelReference».
Импорт
элементов
«metaclassReference»
и
импорт
пакетов
«metamodelReference» служат двум целям: (1) они определяют ссылочные
элементы метамодели, которые импортируются профилем, и (2) они
определяют правила фильтрации профиля.
Правила фильтрации определяют, какие элементы метамодели видны
при применении профиля, а какие скрыты.
Обратите внимание, что применение профиля никоим образом не
меняет базовую модель; он просто определяет представление базовой модели
(рис. 11.24.). Как правило, при применении профиля будут видны только
элементы модели, являющиеся экземплярами импортированных ссылочных
286
метаклассов. Все остальные метаклассы будут скрыты. По умолчанию видны
элементы модели, чьи метаклассы являются общедоступными и принадлежат
эталонной метамодели.
Рис. 11.24. На компонент метакласса ссылаются (импортируют)
профильные Servlet
11.7. Приложение профиля UML
Приложение профиля — это направленная связь, используемая для
отображения того, какие профили были применены к пакету.
Один или несколько профилей могут быть применены к пакету,
созданному на основе той же метамодели, расширенной профилем.
Применение профиля означает, что разрешено, но не обязательно требуется
применять стереотипы, определенные как часть профиля.
К пакету можно применить несколько профилей, если они не имеют
конфликтующих ограничений. Если применяемый профиль зависит от
других профилей, то эти профили должны быть применены в первую
очередь.
При
применении
профиля
быть
должны
созданы
экземпляры
соответствующих стереотипов для тех элементов, которые являются
экземплярами
метаклассов
с
требуемыми
расширениями.
Без
этих
экземпляров модель плохо сформирована.
После того, как профиль был применен к пакету, его можно удалить по
желанию. Удаление профиля подразумевает удаление всех элементов,
являющихся
экземплярами
элементов,
287
определенных
в
профиле.
Примененный профиль не может быть удален, пока другие прикладные
профили, зависящие от него, не будут предварительно удалены.
Нанесенный профиль показан пунктирной стрелкой с открытой
стрелкой от упаковки к наносимому профилю (рис. 11.25.). Рядом со
стрелкой указано ключевое слово «применить».
Рис. 11.25. Профили Java и Servlet применяются к пакету
WebApplication.
Если
несколько
прикладных
профилей
имеют
стереотипы
с
одинаковыми именами, может потребоваться уточнение имени стереотипа
именем профиля.
288
РАЗДЕЛ III
UML ДИАГРАММЫ
ПОВЕДЕНИЯ
289
1. UML ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
1.1. Понятие UML диаграммы вариантов использования
Диаграммы
вариантов
использования
обычно
называют
диаграммами поведения или диаграммами прецедентов, используемыми
для описания набора действий (вариантов использования), которые
некоторая система или системы (субъект) должны или могут выполнять в
сотрудничестве с одним или несколькими внешними пользователями
системы (актерами). Каждый вариант использования должен обеспечивать
некоторый наблюдаемый и ценный результат для участников или других
заинтересованных сторон системы.
Обратите внимание, что в спецификациях UML 2.0-2.4 диаграмма
вариантов
использования
также
описывается
как
специализация
диаграммы классов, а диаграмма классов — это структурная диаграмма.
Диаграммы вариантов использования на самом деле двояки: обе они
являются диаграммами поведения, потому что описывают поведение
системы, и они также являются структурными диаграммами — как особый
случай диаграмм классов, где классификаторы ограничены тем, что могут
быть либо действующими лицами, либо вариантами использования,
связанными с каждым из них. прочее с ассоциациями.
В UML 2.5 варианты использования перемещены из моделирования
поведения в дополнительные концепции UML.
1.2. Схема бизнес-прецедентов
1.2.1. Понятие и схема бизнес-прецедентов
Хотя поддержка бизнес-моделирования была заявлена как одна из
целей UML, спецификация UML не содержит нотаций, специфичных для
нужд бизнеса.
290
Бизнес-прецеденты были введены в Rational Unified Process (RUP)
для представления бизнес-функций, процессов или действий, выполняемых в
моделируемом бизнесе. Бизнес - актер представляет собой роль, которую
играет какое-то лицо или система, внешняя по отношению к моделируемому
бизнесу и взаимодействующая с бизнесом. Бизнес-вариант использования
должен давать результат, имеющий наблюдаемую ценность для бизнес-
актера.
Основные элементы схемы бизнес-прецедентов показаны на рисунке
ниже (рис. 12.1.). Еще раз обратите внимание, что как вариант использования
в бизнесе, так и бизнес-субъект не определены в стандарте UML, поэтому
вам нужно будет либо использовать какой-либо инструмент UML,
поддерживающий их, либо создать свои собственные стереотипы бизнесмоделирования.
291
субъект, Гранина система:
вариант использования
в бизнесе
«Business»
Airport
бизнес-актор
Group
Check-In
Tour Suide
«include»
обобщение между
действующими
липами \
расширяющее
отношение
extend:
Baggage
Check-In
Passenger
Security
Screeninc
вариант использованза
в бизнесе
Рис. 12.1. Основные элементы схемы бизнес-прецедентов — бизнессубъект, бизнес-прецедент, границы бизнеса, отношения включения и
расширения.
1.2.2. Бизнес-прецедент
Бизнес-прецеденты были введены в Rational Unified Process (RUP)
для поддержки бизнес-моделирования для представления бизнес-функций,
процессов или действий, выполняемых в моделируемом бизнесе. Бизнесвариант использования должен давать результат, имеющий наблюдаемую
ценность для бизнес-актера.
Бизнес - вариант использования определяет, что происходит в
бизнесе, когда бизнес-субъект запрашивает вариант использования, он
описывает полный рабочий процесс или бизнес-процесс, который дает
результаты, требуемые или в которых нуждается бизнес-субъект.
292
Бизнес-вариант использования представлен в RUP овалом варианта
использования и линией, пересекающей его, как показано ниже (рис. 12.2.).
Рис. 12.2. Бизнес-вариант индивидуальной регистрации
Существует два альтернативных подхода к именованию вариантов
использования в бизнесе. Вариант использования может быть назван с точки
зрения бизнес-субъекта, выражая цель или потребность субъекта, или с
точки зрения самого бизнеса, давая имена бизнес-процессам или услугам,
предоставляемым бизнес-субъектам (рис. 12.3.).
Candidate
Рис. 12.3. Вариант использования в бизнесе - Кандидат подает заявку на
работу
Бизнес-прецедент «Подать заявку на работу» выражает цель бизнес-
актера «Кандидат». Альтернативное название с точки зрения бизнеса —
Hire Staff.
В
этом
случае
вариант
бизнес-использования
называется
в
соответствии с бизнес-процессом или услугой — Business Serves Meal to
Customer. Альтернативное название с точки зрения актера — Have Meal
(рис. 12.4.).
Customer
Рис. 12.4. Бизнес-вариант использования — Бизнес подает еду клиенту
293
Вы можете увидеть другие различия между этими двумя подходами,
сравнив примеры диаграмм бизнес-прецедентов для ресторана.
1.2.3. Бизнес-актер
Бизнес - актер (представленный в Rational Unified Process (RUP) для
поддержки бизнес-моделирования) представляет собой роль, которую играет
какое-то лицо или система, внешняя по отношению к моделируемому
бизнесу и взаимодействующая с бизнесом. Обратите внимание, что бизнес-
актер не определен в стандарте UML.
Некоторые типичные примеры бизнес-актеров:
•
Покупатель
•
Поставщик
•
Покровитель
•
Пассажир
•
Власть
•
Банк
Каждый бизнес-субъект представляет собой что-то, выходящее за
рамки моделируемого бизнеса, и должен участвовать по крайней мере в
одном бизнес-варианте использования.
Бизнес-актер представлен в RUP значком в виде человечка-палки с
линией, пересекающей его голову. (рис. 12.5.)
Passenger
Рис. 12.5. Бизнес-актер Пассажир
294
Отношения между актерами
Мы можем определить абстрактных или конкретных актеров и
специализировать их, используя отношения обобщения.
Обобщение
между
актерами
отображается
в
виде
сплошной
направленной линии с большой стрелкой (так же, как и для обобщения
между классами) (рис. 12.6.).
Рис. 12.6. Актер веб-клиента — это абстрактный суперкласс для
администратора, редактера и клиента.
1.2.4. Обобщение в UML
Обобщение представляет собой бинарную таксономическую (т.е.
связанную с классификацией) направленную связь между более общим
классификатором (надклассом) и более конкретным классификатором
(подклассом).
Каждый экземпляр конкретного классификатора также является
косвенным экземпляром общего классификатора, поэтому мы можем сказать:
«Пациент — это человек», «Сберегательный счет — это счет» и т. д. Из-за
этого отношение обобщения также неофициально называется «является
Отношения.
Обобщение принадлежит конкретному классификатору.
295
Обобщение показано в виде линии с полым треугольником в виде
стрелки
между
символами,
представляющими
задействованные
классификаторы (рис. 12.7.). Стрелка указывает на символ, представляющий
общий классификатор. Эта нотация называется «отдельным целевым
стилем».
Рис. 12.7. Текущие, сберегательные и кредитные счета обобщаются по
счету.
Отношения обобщения, которые ссылаются на один и тот же общий
классификатор, также могут быть связаны друг с другом в «общем целевом
стиле» (рис. 12.8.).
Рис. 12.8. Текущие, сберегательные и кредитные счета обобщаются по
счету.
1.2.5. Тема UML варианта использования
Предмет варианта использования определяет и представляет границы
бизнеса, программной системы, физической системы или устройства,
подсистемы, компонента или даже отдельного класса в отношении сбора и
анализа требований.
296
В терминах UML, тема — это классификатор, играющий роль
«субъекта». Они не создавали отдельный специальный класс для субъекта,
как это было сделано для актера и варианта использования. UML 2.5
утверждает, что субъектом варианта использования может быть система
или любой другой элемент, который может иметь поведение, например
компонент или класс. ". Классификатор, который может иметь собственное
поведение, называется поведенческим классификатором. Тем не менее,
абстрактный синтаксис UML 2.5 показывает предмет как простой ванильный
классификатор.
Субъект— это классификатор (включая подсистему, компонент или
даже класс), представляющий бизнес, программную систему, физическую
систему
или
анализируемое,
проектируемое
или
рассматриваемое
устройство, имеющее некоторое поведение и к которому применяется набор
вариантов использования.
связан
Субъект
с
применимыми
вариантами
использования
и
отличается от вариантов использования, владеющих классификатором. В
UML
2.x
до
2.5
использования
вариантов
классификатор
был
классификатором, расширенным с возможностью собственных вариантов
использования. В UML 2.5 любой классификатор может владеть вариантами
использования.
Обозначение.
Тема
(иногда
границей
называемая
системы)
представлена
прямоугольником с названием темы, соответствующими ключевыми словами
и
стереотипами
использования,
в
верхнем
применимые
левом
к
углу
субъекту,
(рис.
12.9.).
расположены
прямоугольника, а актеры — за пределами системной границы.
297
Варианты
внутри
Рис. 12.9. Электронные книги (тема) с применимыми вариантами
использования и субъектом веб-клиента.
Редакции.
Требование, чтобы имя субъекта находилось в верхнем левом углу
границы системы, было добавлено только в UML 2.5. Предыдущие версии
UML позволяли использовать и имели примеры с именем в одном из верхних
углов. Лично я считаю слишком ограничивающим использование только
верхнего левого угла. Когда большинство действующих лиц находится слева,
имя субъекта лучше смотрится справа. В некоторых случаях я бы не
возражал против того, чтобы имя субъекта было даже вверху посередине.
1.2.6. Предмет бизнес-модели
Сценарии использования можно использовать для моделирования
некоторых бизнес -процессов для анализа бизнес-процессов, выявления
возникающих
проблем
и
определения
возможностей
для
лучшего
обслуживания клиентов.
Субъектом вариантов использования в данном случае является бизнес,
предприятие, компания или ее подразделение, отдел, коллектив.
Примеры бизнес-тем:
•
Универмаг
•
аэропорт
•
Ресторан
298
UML не предоставляет стандартных стереотипов для моделирования
бизнес-процессов, но мы можем использовать собственные стереотипы,
такие как «Бизнес» или «Отдел», если это необходимо для ясности.
В приведенном ниже примере показан ресторан «Бизнес» с бизнес-
актерами «Клиент», «Рекламодатель» и «Поставщик» и соответствующие
варианты использования в бизнесе (рис. 12.10.).
Рис. 12.10. Тема ресторанного бизнеса с субъектами бизнеса и
применимыми вариантами использования
Распространенные ошибки.
Пример ниже показывает типичное заблуждение для ресторана
«Бизнес», в котором бизнес-субъекты ошибочно включают официанта и
кассира. Они оба работают на ресторан и являются частью бизнеса. Их не
следует показывать, как актеров, потому что актеры являются внешними
пользователями (заказчиками) бизнеса (системы) (рис. 12.11.).
299
«Business»
Restaurant
Order Meal,
Waiter
Customer
Cashier
Рис. 12.11. Ошибка: в ресторанном бизнесе не должно быть официанта и
кассира.
1.2.7. Отношения включения варианта использования
1.2.7.1 Понятие отношения включения варианта использования
Включение варианта использования — это направленная связь
между двумя вариантами использования, которая используется для
демонстрации того, что поведение включенного варианта использования
(дополнение) вставлено в поведение включающего (базового) варианта
использования.
Можно использовать отношение включения:
•
упростить большой вариант использования, разбив его на несколько
вариантов использования,
•
для извлечения общих частей поведения двух или более вариантов
использования.
Большой вариант использования может иметь некоторые варианты
поведения, которые могут быть отделены от отдельных более мелких
300
вариантов
использования
и включены обратно
в базовый вариант
использования с использованием отношения включения UML. Целью этого
действия
является
модульность
поведения,
что
делает
его
более
управляемым (рис. 12.12. и 12.13.).
Рис. 12.12. Вариант использования B извлекается из более крупного
варианта использования A в отдельный вариант использования.
Рис. 12.13. Варианты использования B и C извлекаются из более
крупного варианта использования A в отдельные варианты
использования.
Когда два или более вариантов использования имеют некоторое общее
поведение, эта общая часть может быть выделена в отдельный вариант
использования, который будет включен обратно в варианты использования с
отношением включения UML (рис. 12.14.).
301
Рис. 12.14. Вариант использования C извлекается из вариантов
использования A и B для повторного использования обоими вариантами
использования с использованием отношения включения UML.
Выполнение включенного варианта использования аналогично вызову
подпрограммы или макрокоманды в программировании. Все поведение
включенного
варианта
использования
выполняется
в
одном
месте
включающего варианта использования до возобновления выполнения
включающего варианта использования.
Обратите внимание, что, хотя UML 2.x определяет точки расширения
для отношения расширения, не существует «точек включения», чтобы
указать местоположение или условие включения для включения.
Включение
варианта
использования
зависит
от
добавления
включенного варианта использования, которое является обязательным, а не
необязательным. Это означает, что включение варианта использования само
по себе не является полным, и поэтому имеет смысл называть включение
вариантов использования абстрактными вариантами использования. Ни в
одной из спецификаций UML 2.x вплоть до UML 2.5 даже не упоминаются
абстрактные варианты использования. В ряде других источников UML
абстрактный вариант использования определяется как включающий вариант
использования, хотя на самом деле должно быть наоборот: включение
302
варианта использования является абстрактным вариантом использования.
См. обсуждение определения абстрактных вариантов использования.
Включающая взаимосвязь между вариантами использования показана
пунктирной стрелкой с открытой стрелкой от включающего (базового)
варианта
использования
к
включенному
(общая
часть)
варианту
использования (рис. 12.15.). Стрелка помечена ключевым словом «include».
Рис. 12.15. Вариант использования Checkout включает несколько
вариантов использования — Scan Item, Calculation Total and Tax и
Payment.
Большой и сложный вариант использования Checkout содержит
несколько извлеченных вариантов использования, каждый меньший вариант
использования описывает некоторую логическую единицу поведения (рис.
12.16.). Обратите внимание, что включение вариантов использования
Checkout становится неполным само по себе и требует завершения
включенных вариантов использования.
303
Рис. 12.16. Варианты использования «Ввод средств» и «Снятие
наличных» включают вариант использования «Аутентификация
клиента».
1.2.7.2 Сравнение взаимосвязей вариантов использования
Довольно распространённым вопросом является: какие отношения
вариантов использования следует использовать и в какой ситуации. Авторы
объединили несколько ключевых моментов из спецификации UML 2.4 в
приведенную ниже таблицу (табл. 7 - 9.).
Таблица 7
Взаимосвязь Обобщение
Обобщение
Базовый вариант использования может быть абстрактным
(неполным) или конкретным (полным).
Специализированный вариант использования обязателен, а не
необязателен, если базовый вариант использования является
абстрактным.
Нет явного местоположения для использования специализации.
Нет явного условия для использования специализации.
304
Таблица 8
Взаимосвязь Расширение
Расширение
Базовый вариант использования является завершенным
(конкретным) сам по себе, определяемым независимо.
Расширение варианта использования является необязательным,
дополнительным.
Имеет хотя бы одно явное расположение расширения.
Может иметь необязательное условие расширения.
Таблица 9
Взаимосвязь Обобщение
Обобщение
Базовый вариант использования неполный (абстрактный вариант
использования).
Включенный вариант использования обязателен, а не необязателен.
Нет явного места включения, но оно включено в каком-то месте.
Нет явного условия включения.
1.2.7.3 Отсутствие связи варианта использования
305
Одним,
казалось
бы,
простым,
но
неразрешимым
примером
использованием UML 2.4 является указание взаимосвязей между Payment,
Payment by Credit, Payment by Cash и т. д., в случае использования, когда
мы хотим разрешить клиентам платить частично наличными, частично в
кредит и т. д. Это довольно распространенная ситуация для Кассового
терминала в супермаркетах. (Еще один похожий пример: «Планирование
поездки и поиск рейса», «Найти отель», «Найти машину» и т. д., где
пользователь может захотеть
искать
не
одну,
а
несколько
вещей
одновременно.)
Хотя обобщение варианта использования кажется естественным для
платежа, платежа в кредит, платежа чеком и т. Д., мы не можем его
использовать, потому что он предполагает использование только одной
конкретной формы платежа за раз.
Расширение кажется подходящим, потому что оно имеет точки
расширения с условиями расширения, но мы не можем его использовать,
потому что базовый вариант использования Оплата должна быть завершена
сама по себе, что, очевидно, не так, как у нас.
Включение кажется подходящим, потому что базовый вариант
использования «Платеж» не завершен сам по себе, и все различные виды
платежей дополняют его, но мы не можем его использовать, потому что для
отношения включения включенный случай не является необязательным, а
обязательным (и нет условия включения), это означает, что клиенту
придется платить,
используя все способы оплаты,
что
совершенно
неправильно.
Авторы надеются, что разработчики UML обновят отношения включения,
чтобы разрешить условия и местоположения включения, как это было
сделано для extend, или, по крайней мере, предоставят больше примеров
диаграмм вариантов использования в будущих версиях спецификации UML.
306
1.2.8. Расширение варианта использования UML
1.2.8.1 Понятие расширения варианта использования UML
Расширение — это направленная связь, которая указывает, как и
когда поведение, определенное в обычно дополнительном (необязательном)
расширяющем
прецеденте,
может
быть
вставлено
в
поведение,
определенное в расширенном прецеденте.
Расширенный вариант использования имеет смысл сам по себе, он не
зависит от расширенного варианта использования. Расширение варианта
использования обычно определяет необязательное поведение, которое само
по себе не обязательно имеет смысл. Отношение расширения принадлежит
варианту использования расширения. Один и тот же расширяющий
прецедент может расширять более одного прецедента, а сам расширяющий
прецедент может быть расширен.
Расширение происходит в одной или нескольких точках расширения,
определенных в расширенном варианте использования.
Связь расширения показана в виде пунктирной линии с открытой
стрелкой, направленной от расширяющего варианта использования к
расширенному (базовому) варианту использования. Стрелка помечена
ключевым словом «extend» (рис. 12.17.).
Рис. 12.17. Вариант использования регистрации является полным и
содержательным сам по себе. Его можно расширить с помощью
дополнительного варианта использования Get Help On Registration.
307
Состояние отношения расширения, а также ссылки на точки
расширения дополнительно отображаются в примечании к комментарию,
прикрепленном к соответствующему отношению расширения (рис. 12.18.).
Рис. 12.18. Вариант использования «Регистрация» условно расширяется
вариантом использования «Получить справку по регистрации» в
справке по регистрации точки расширения.
1.2.8.2 Точка расширения
Точка расширения - это характеристика варианта использования,
которая идентифицирует (ссылается) на точку в поведении варианта
использования, где это поведение может быть расширено каким-либо другим
(расширяющим) вариантом использования, как указано в отношении
расширения.
Точки расширения могут быть показаны в ячейке овального символа
варианта использования под заголовком Точки расширения. Каждая точка
расширения
должна
иметь
имя,
уникальное
в
рамках
варианта
использования. Точки расширения отображаются в виде текстовой строки в
соответствии со следующим синтаксисом:
точка расширения ::= имя [: объяснение ]
Необязательное объяснение — это некоторое описание, которое
обычно дается в виде неофициального текста. Это могут быть и другие
формы, такие как имя состояния в конечном автомате, действие на
диаграмме действий, некоторое предусловие или постусловие (рис. 12.19.).
308
Рис. 12.19. Пример использования регистрации с точками расширения
Справка по регистрации и Пользовательское соглашение
Точки расширения могут быть показаны в ячейке прямоугольника
варианта использования со значком эллипса под заголовком точки
расширения (рис. 12.20.).
Registration О
-userProfile
extension points
Registration Help
User Agreement
Рис. 12.20. Точки расширения варианта использования «Регистрация» ,
показанные в виде прямоугольника
1.3. Схема вариантов использования системы
1.3.1. Использование и элементы схемы вариантов использования
системы
Диаграммы вариантов использования используются для указания:
•
(внешние) требования, требуемые способы использования
разрабатываемой или анализируемой системы (предмет) — чтобы
зафиксировать, что система должна делать;
•
предлагаемый субъектом функционал — что может система;
•
требования, которые указанный субъект предъявляет к своей среде,
определяя, как среда должна взаимодействовать с субъектом, чтобы он
мог выполнять свои услуги.
309
Основные элементы схемы вариантов использования UML показаны на
Рис. 12.21. Основные элементы диаграммы вариантов использования
UML — действующее лицо, вариант использования, субъект, отношения
включения и расширения.
1.3.2. UML - актер
1.3.2.1 Понятие UML - актера
Актер — это поведенческий классификатор, который определяет
роль, которую играет внешний объект, взаимодействующий с субъектом
(например, путем обмена сигналами и данными), человек-пользователь
проектируемой системы, какая-либо другая система или оборудование,
использующие услуги субъекта.
Термин
«роль»
используется
неофициально
для
обозначения
некоторого типа, группы или определенного аспекта пользователей, которым
310
требуются
определенные
услуги
от
субъекта,
смоделированные
с
соответствующими вариантами использования. Когда внешний субъект
взаимодействует с субъектом, он играет роль определенного актера. Этот
единственный физический объект может играть несколько разных ролей, а
конкретную роль могут играть один или несколько разных экземпляров.
Поскольку субъект является внешним по отношению к субъекту, он
обычно определяется в том же классификаторе или пакете, который
включает субъект.
Все актеры должны иметь имена в соответствии с предполагаемой
ролью. Примеры имен актеров (ролей пользователей):
•
Покупатель
•
Веб-клиент
•
Ученик
•
Пассажир
•
Система оплаты
Стандартная нотация UML для актера — это значок «человек-палка»
с именем актера над или под значком (рис. 12.22.). Имена актеров должны
соответствовать рекомендациям по использованию заглавных букв и
пунктуации для классов. Имена абстрактных актеров должны быть
выделены курсивом.
Student
Рис. 12.22. Студенческий актер
Пользовательские значки, обозначающие тип актера, также могут
использоваться для обозначения актера, например, использование отдельных
значков для актеров, не являющихся людьми (рис. 12.23. и рис. 12.24.).
311
Web Client
Рис. 12.23. Пользовательский значок для актера веб-клиента
Bank
Рис. 12.24. Пользовательская иконка для актера банка
Актер также может быть показан в виде прямоугольника класса со
стандартным ключевым словом «актер», при необходимости с обычным
обозначением для сегментов класса (рис. 12.25.).
«actor»
Customer
+ name: Name
+ address: Address
Рис. 12.25. Актер клиента как класс
Актер может иметь только бинарные ассоциации с вариантами
использования, компонентами и классами.
1.3.2.2 Бизнес-актер
Бизнес - актер (представленный в Rational Unified Process (RUP) для
поддержки бизнес-моделирования) представляет собой роль, которую играет
какое-то лицо или система, внешняя по отношению к моделируемому
бизнесу и взаимодействующая с бизнесом. Обратите внимание, что бизнес-
актер не определен в стандарте UML.
Некоторые типичные примеры бизнес-актеров:
312
•
Покупатель
•
Поставщик
•
Покровитель
•
Пассажир
•
Власть
•
Банк
Каждый бизнес-субъект представляет собой что-то, выходящее за
рамки моделируемого бизнеса, и должен участвовать по крайней мере в
одном бизнес-варианте использования.
Бизнес-актер представлен в RUP значком в виде человечка-палки с
линией, пересекающей его голову (рис. 12.26.).
Passenger
Рис. 12.26. Бизнес-актер Пассажир
1.3.2.2 Отношения между актерами
Мы можем определить абстрактных или конкретных актеров и
специализировать их, используя отношение обобщения.
Обобщение
между
актерами
отображается
в
виде
сплошной
направленной линии с большой стрелкой (так же, как и для обобщения
между классами) (рис. 12.27.).
313
Рис. 12.27. Актер веб-клиента — это абстрактный суперкласс для
администратора, редактера и клиента.
1.4. Вариант использования UML
1.4.1. Понятие варианта использования UML
Сценарии
использования
позволяют
фиксировать
требования
разрабатываемых или рассматриваемых систем, описывать функциональные
возможности, предоставляемые этими системами, и определять требования,
которые системы предъявляют к своей среде.
Спецификации UML, например, UML 2.5, предоставляют несколько
отличающихся друг от друга определений варианта использования. Я
составил определение ниже из этих частей.
Вариант
классификатор,
использования
который
—
это
определяет
своего
[полную]
рода
поведенческий
единицу
[полезной]
функциональности, выполняемую [одним или несколькими] субъектами, к
которым применяется вариант использования в сотрудничестве с одним
или несколькими действующими лицами, и который [для полных вариантов
использования] дает наблюдаемый результат, который имеет некоторую
ценность для тех участников [или других заинтересованных сторон] каждого
субъекта.
Спецификации UML требуют, чтобы «эта функциональность всегда
должна быть завершена для завершения UseCase. Она считается
314
завершенной, если после ее выполнения субъект будет находиться в
состоянии, в котором не ожидаются дальнейшие входные данные или
действия, и UseCase может быть инициирован снова или в состоянии
ошибки».
Проблема с этим требованием заключается в том, что оно не
рассматривает расширенные варианты использования и включенные
варианты использования. Расширение варианта использования может не
обязательно
быть
значимым
само
по
себе.
Включенный
вариант
использования — это некоторая общая часть, выделенная в отдельный
вариант использования. Также кажется неприменимым требовать получения
наблюдаемого результата.
Также сомнительно, что функциональность варианта использования
всегда полезна: «Каждый вариант использования определяет единицу
полезной функциональности, которую субъект предоставляет своим
пользователям».
«Вариант использования может применяться к любому количеству
субъектов». Разумно ожидать, что для каждого варианта использования
будет по крайней мере один предмет, иначе определение варианта
использования не будет иметь смысла. В то же время описание класса
UseCase в спецификации UML позволяет варианту использования не иметь
связанных субъектов.
В то время как «ключевыми понятиями, указанными в этом пункте,
являются действующие лица, варианты использования и субъекты», в одном
из
определений
варианта
использования
каким-то
образом
также
упоминаются «другие заинтересованные стороны предмета» в противном
случае они должны быть включены в спецификацию UML как отдельная
концепция.
Спецификации
UML
до
версии
UML
2.5
требовали,
чтобы
функциональность варианта использования инициировалась действующим
лицом. В UML 2.5 это было удалено, а это означает, что могут быть
315
некоторые ситуации, когда системная функциональность запускается самой
системой, но при этом предоставляет полезный результат действующему
лицу. Например, система может уведомить клиента об отправке заказа,
запланировать очистку и архивирование информации о пользователе,
запросить некоторую информацию из другой системы и т. д.
Кроме того, во всех спецификациях UML 2.x до UML 2.5 указывалось,
что
варианты
использования
«определяются
в
соответствии
с
потребностями субъектов». Это предложение было удалено из UML 2.5,
поскольку некоторые субъекты могут сами по себе не иметь ни
потребностей, ни требований.
Именование вариантов использования
Спецификация UML не содержит указаний по именам вариантов
использования. Единственное требование состоит в том, что каждый вариант
использования
должен
иметь
имя.
Мы
должны
просто
следовать
определению варианта использования, чтобы дать какое-то имя той единице
функциональности, выполняемой системой, которая обеспечивает некоторый
наблюдаемый и полезный результат для актера. Примеры имен прецедентов:
•
Сделать покупку
•
Разместить заказ
•
Обновить подписку
•
Перевод средств
•
Нанять сотрудника
•
Управлять счетом
Обозначение
Вариант
использования
обычно
отображается в
виде эллипса,
содержащего имя варианта использования (рис. 12.28.).
Рис. 12.28. Пример использования регистрации пользователя
316
Название варианта использования также может быть помещено под
многоточием (рис. 12.29.).
Transfer Funds
Рис. 12.29. Вариант использования «Перевод средств»
Если отображается субъект (или граница системы), эллипс варианта
использования визуально располагается внутри прямоугольника границы
системы. Обратите внимание, что это не обязательно означает, что
предметный
классификатор
владеет
содержащимися
вариантами
использования, а просто означает, что вариант использования применяется к
этому классификатору.
Варианты использования не имеют стандартных ключевых слов или
стереотипов.
Вариант
использования
может
быть
показан
с
пользовательским стереотипом над именем. Как классификатор, вариант
использования имеет свойства. Список свойств вариантов использования —
операций и атрибутов — может быть показан в ячейке внутри овала
варианта использования под именем варианта использования (рис. 12.30.).
Рис. 12.30. Вариант использования Вход пользователя в систему,
стереотипный как «аутентификация»
317
Вариант использования с точками расширения может быть указан в
разделе варианта использования с заголовком точки расширения (рис.
12.31.).
Рис. 12.31. Вариант использования регистрации с точками расширения
Справка по регистрации и Пользовательское соглашение
Вариант использования также может быть показан с использованием
стандартной нотации прямоугольника для классификаторов со значком
эллипса в верхнем правом углу прямоугольника и с необязательными
отдельными отсеками списка для его функций (рис. 12.32.).
Registration CD
-userProfile
extension points
Registration Help
User Agreement
Рис. 12.32. Вариант использования регистрации, показанный с
использованием стандартной нотации прямоугольника для
классификаторов
1.4.2. Абстрактный вариант использования
Все спецификации UML 2.x, включая UML 2.5, не упоминают, не
определяют и не объясняют абстрактные варианты использования. В
спецификации UML 1.x упоминалось, что «название абстрактного варианта
использования может быть выделено курсивом», но начиная с UML 2.0 это
предложение было удалено из спецификаций UML без каких-либо
объяснений.
318
Одной из причин, по которой это предложение было удалено, может
быть то, что, поскольку вариант использования является классификатором,
а любой классификатор может быть абстрактным (с именем, выделенным
курсивом), очевидно, что он должен быть применим и к вариантам
использования.
С другой стороны, поскольку предложение было удалено, а UML 2.5
вообще не упоминает абстрактные варианты использования и не
предоставляет ни одного примера абстрактных вариантов использования, это
может означать, что они ожидают, что все варианты использования будут
конкретными, а не абстрактными. В этом случае было бы разумно явно
объяснить эту ситуацию в спецификации UML.
Предполагая, что вариант использования может быть абстрактным и
применить
соответствующее
определение
для
классификатора,
абстрактный вариант использования - это вариант использования, который
не имеет полного объявления (неполный) и ("обычно", как говорится в
спецификации UML) не может быть создан. Абстрактный вариант
использования
предназначен для использования другими вариантами
использования, например, в качестве цели отношения обобщения. Я
надеюсь, что «название абстрактного варианта использования может быть
выделено курсивом» по-прежнему применимо в UML 2.5, как это было
указано в UML 1.x (рис. 12.33.).
Рис. 12.33. Вариант использования веб-аутентификации пользователя —
это абстрактный вариант использования, специализирующийся на
вариантах использования «Вход», «Запомнить меня» и «Единый вход».
319
Когда
спецификация
UML
2.4
описывает
взаимосвязь
между
вариантами использования, они объясняют, что «то, что остается в базовом
варианте использования, обычно не является полным», но по какой-то
причине избегают называть это абстрактным вариантом использования
(рис. 12.34.). Как правило, это должно означать, что включение варианта
использования всегда абстрактно.
Рис. 12.34. Вариант использования «Транзакция банковского
банкомата» становится абстрактным вариантом использования в
результате включения варианта использования «Аутентификация
клиента».
Хотя спецификация UML избегает этого, довольно часто можно найти
источники, которые определяют включение вариантов использования как
абстрактные
варианты
использования
или
основные
варианты
использования. Хотя мы можем предположить, что включение вариантов
использования всегда абстрактно, включенный вариант использования,
вероятно, может быть либо абстрактным, либо конкретным. Удивительно, но
есть некоторые источники, с которыми я не могу согласиться, дающие прямо
противоположное объяснение того, что включение (базовых) вариантов
использования «обычно конкретно», а включение («дополнение») вариантов
использования «обычно абстрактно».
Чтобы
абстрактные
еще
больше
варианты
запутать,
использования
другие
как
источники
варианты
определяют
использования,
описанные на абстрактном уровне (бизнес-варианты использования, иногда
называемые основными вариантами использования), в отличие от системных
вариантов использования.
320
1.4.3. Пример использования в бизнесе
Хотя поддержка бизнес-моделирования заявлена как цель UML,
спецификация UML не дает представления о вариантах использования в
бизнесе.
Бизнес-прецеденты были введены в Rational Unified Process (RUP)
для поддержки бизнес-моделирования для представления бизнес-функций,
процессов или действий, выполняемых в моделируемом бизнесе. Бизнесвариант использования должен давать результат, имеющий наблюдаемую
ценность для бизнес-актера.
Бизнес - вариант использования определяет, что происходит в
бизнесе, когда бизнес-субъект запрашивает вариант использования, он
описывает полный рабочий процесс или бизнес-процесс, который дает
результаты, требуемые или в которых нуждается бизнес-субъект.
Бизнес-вариант использования представлен в RUP овалом варианта
использования и линией, пересекающей его, как показано ниже (рис. 12.35.).
Рис. 12.35. Бизнес-вариант индивидуальной регистрации
Существует два альтернативных подхода к именованию вариантов
использования в бизнесе. Вариант использования может быть назван с точки
зрения бизнес-субъекта, выражая цель или потребность субъекта, или с
точки зрения самого бизнеса, давая имена бизнес-процессам или услугам,
предоставляемым бизнес-субъектам (рис. 12.36.).
Candidate
Рис. 12.36. Вариант использования в бизнесе - Кандидат подает заявку
на работу
321
Бизнес-прецедент «Подать заявку на работу» выражает цель бизнесактера «Кандидат» (рис. 12.37.). Альтернативное название с точки зрения
бизнеса — Hire Staff.
Customer
Рис. 12.37. Бизнес-вариант использования — Бизнес подает еду клиенту
В
этом
случае
вариант
бизнес-использования
называется
в
соответствии с бизнес-процессом или услугой — Business Serves Meal to
Customer. Альтернативное название с точки зрения актера — Have Meal.
1.4.4. Описание вариантов использования
Поведение варианта использования может быть описано текстом на
естественном языке (непрозрачное поведение), что является обычной
практикой в настоящее время, или с помощью диаграмм поведения UML
для конкретных поведений, таких как
•
деятельность,
•
государственная машина,
•
взаимодействие.
Поведение варианта использования также может быть описано
косвенно через сотрудничество, которое использует вариант использования
и его участников в качестве классификаторов, типизирующих его части.
Какой из этих методов использовать, зависит от характера поведения
прецедента, а также от предполагаемого читателя. Эти описания можно
комбинировать.
Инструменты
UML должны
позволять
связывать
описанным вариантом использования. Вариант
322
поведение
с
использования может
отображаться во фрейме, помеченном как вариант использования или uc
(сокращенно) (рис. 12.38.). Область содержимого фрейма может быть
представлена различными видами диаграмм UML, описывающих поведение
варианта использования.
Рис. 12.38. Вариант использования. Элементы поиска отображаются в
виде фрейма с соответствующей диаграммой действий элементов поиска
Другой пример такой привязки варианта использования к поведению,
представленному активностью, показан ниже с использованием нотации
UML 2.5 (рис. 12.39.).
Purchase Ticket C2?
owned behaviors
«activity»
Purchase Ticket
Рис. 12.39. Вариант использования «Покупка билета» определяет
поведение, представленное действием «Покупка билета».
Пример диаграммы действия «Покупка билета» ниже описывает
поведение варианта использования «Покупка билета» (рис. 12.40.).
323
Bank
Ticket vending machine
Commuter
JL
'j
Start Session к
_
**
С Z
A
Request
Trip Info
<
J
z------ ■—ч
Provide
Trip Info
'
z
<
Z
V
Provide
Payment Info
X
x
Process
Trip Info
У
Request
Г
Payment
J
Process
Payment
V._______ __ _________ У
[pay with
cash)
s--------X
X
Authorize
Card Payment
J
( Dispense Ticket 'II
hU
Ticket
Ticket
[paid with cash
& with change)
z.
V
X
Dispense
Change
ч____ '
__ /
Change
<
X
Gel
Change
7
z
Show
Thank You
\
к___ _ ___ 7
Рис. 12.40. Пример поведения варианта использования «Покупка
билета», описанного с помощью диаграммы действий.
324
Исполнение варианта использования — это появление эмерджентного
поведения. Каждый экземпляр классификатора, реализующий прецедент,
должен вести себя так, как это описано в прецеденте.
1.4.5. Отношения между вариантами использования
Варианты использования могут быть организованы с использованием
следующих отношений:
•
обобщение
•
ассоциация
•
продлевать
•
включать
Обобщение вариантов использования
Обобщение между вариантами использования похоже на обобщение
между классами — дочерний вариант использования наследует свойства и
поведение родительского варианта использования и может переопределить
поведение родителя.
Обобщение показано в виде сплошной направленной линии с большой
полой
треугольной
классификаторами,
стрелкой,
как
и
направленной
от
более
для
обобщения
конкретного
между
варианта
использования к общему варианту использования (рис. 12.41.).
Рис. 12.41. Вариант использования веб-аутентификации пользователя —
это абстрактный вариант использования, специализирующийся на
вариантах использования «Вход», «Запомнить меня» и «Единый вход».
325
Связь между вариантами использования
Варианты
использования
быть
могут
задействованы
только
в
бинарных ассоциациях.
Два варианта использования, определяющие один и тот же предмет, не
могут быть связаны, поскольку каждый из них по отдельности описывает
полное использование системы.
1.4.6. Тема UML варианта использования
Предмет варианта использования определяет и представляет границы
бизнеса, программной системы, физической системы или устройства,
подсистемы, компонента или даже отдельного класса в отношении сбора и
анализа требований.
В терминах UML, тема — это классификатор, играющий роль
«субъекта». Они не создавали отдельный специальный класс для субъекта,
как это было сделано для актера и варианта использования. UML 2.5
утверждает, что субъектом варианта использования может быть система
или любой другой элемент, который может иметь поведение, например
компонент или класс.". Классификатор, который может иметь собственное
поведение, называется поведенческим классификатором. Тем не менее,
абстрактный синтаксис UML 2.5 показывает предмет как простой ванильный
классификатор.
Субъект — это классификатор (включая подсистему, компонент или
даже класс), представляющий бизнес, программную систему, физическую
систему
или
анализируемое,
проектируемое
или
рассматриваемое
устройство, имеющее некоторое поведение и к которому применяется набор
вариантов использования.
Субъект
связан
с
применимыми
вариантами
использования
и
отличается от вариантов использования, владеющих классификатором. В
UML
2.x
до
2.5
классификатор
вариантов
использования
был
классификатором, расширенным с возможностью собственных вариантов
326
использования. В UML 2.5 любой классификатор может владеть вариантами
использования.
Обозначение.
Тема
(иногда
называемая
границей
системы)
представлена прямоугольником с названием темы, соответствующими
ключевыми словами и стереотипами в верхнем левом углу (рис. 12.42.).
Варианты использования, применимые к субъекту, расположены внутри
прямоугольника, а актеры — за пределами системной границы.
Рис. 12.42. Электронные книги (тема) с применимыми вариантами
использования и субъектом веб-клиента.
Редакции.
Требование, чтобы имя субъекта находилось в верхнем левом углу
границы системы, было добавлено только в UML 2.5. Предыдущие версии
UML позволяли использовать и имели примеры с именем в одном из верхних
углов. Лично я считаю слишком ограничивающим использование только
верхнего левого угла. Когда большинство действующих лиц находится слева,
имя субъекта лучше смотрится справа. В некоторых случаях я бы не
возражал против того, чтобы имя субъекта было даже вверху посередине.
1.4.7. Предмет бизнес-модели
Сценарии использования можно использовать для моделирования
некоторых бизнес -процессов для анализа бизнес-процессов, выявления
возникающих
проблем
и
определения
возможностей
для
лучшего
обслуживания клиентов.
Субъектом вариантов использования в данном случае является бизнес,
предприятие, компания или ее подразделение, отдел, коллектив.
327
Примеры бизнес-тем:
•
Универмаг
•
аэропорт
•
Ресторан
UML не предоставляет стандартных стереотипов для моделирования
бизнес-процессов, но мы можем использовать собственные стереотипы,
такие как «Бизнес» или «Отдел», если это необходимо для ясности.
В приведенном ниже примере показан ресторан «Бизнес» с бизнес-
актерами «Клиент», «Рекламодатель» и «Поставщик» и соответствующие
варианты использования в бизнесе (рис. 12.43.).
Рис. 12.43. Тема ресторанного бизнеса с субъектами бизнеса и
применимыми вариантами использования.
Распространенные ошибки.
Пример ниже показывает типичное заблуждение для ресторана
«Бизнес», в котором бизнес-субъекты ошибочно включают официанта и
кассира (рис. 12.44.). Они оба работают на ресторан и являются частью
бизнеса. Их не следует показывать, как актеров, потому что актеры являются
внешними пользователями (заказчиками) бизнеса (системы).
328
«Business»
Restaurant
Order Meal,
Waiter
Customer
Cashier
Рис. 12.44. Ошибка: в ресторанном бизнесе не должно быть официанта и
кассира.
1.4.8. Отношения включения варианта использования
1.4.8.1 Понятие отношения включения варианта использования
Включение варианта использования — это направленная связь
между двумя вариантами использования, которая используется для
демонстрации того, что поведение включенного варианта использования
(дополнение) вставлено в поведение включающего (базового) варианта
использования.
Можно использовать отношение включения:
•
упростить большой вариант использования, разбив его на несколько
вариантов использования,
•
для извлечения общих частей поведения двух или более вариантов
использования.
Большой вариант использования может иметь некоторые варианты
поведения, которые могут быть отделены от отдельных более мелких
вариантов
использования
и
включены
329
обратно
в
базовый
вариант
использования с использованием отношения включения UML. Целью этого
действия
является
модульность
поведения,
что
делает
его
более
управляемым (рис. 12.45. и 12.46.).
Рис. 12.45. Вариант использования B извлекается из более крупного
варианта использования A в отдельный вариант использования.
Рис. 12.46. Варианты использования B и C извлекаются из более
крупного варианта использования A в отдельные варианты
использования.
Когда два или более вариантов использования имеют некоторое общее
поведение, эта общая часть может быть выделена в отдельный вариант
использования, который будет включен обратно в варианты использования с
отношением включения UML (рис. 12.47.).
330
Рис. 12.47. Вариант использования C извлекается из вариантов
использования A и B для повторного использования обоими вариантами
использования с использованием отношения включения UML.
Выполнение включенного варианта использования аналогично вызову
подпрограммы или макрокоманды в программировании. Все поведение
включенного
варианта
использования
выполняется
в
одном
месте
включающего варианта использования до возобновления выполнения
включающего варианта использования.
Обратите внимание, что, хотя UML 2.x определяет точки расширения
для отношения расширения, не существует «точек включения», чтобы
указать местоположение или условие включения для включения.
Включение
варианта
использования
зависит
от
добавления
включенного варианта использования, которое является обязательным, а не
необязательным. Это означает, что включение варианта использования само
по себе не является полным, и поэтому имеет смысл называть включение
вариантов использования абстрактными вариантами использования. Ни в
одной из спецификаций UML 2.x вплоть до UML 2.5 даже не упоминаются
абстрактные варианты использования. В ряде других источников UML
абстрактный вариант использования определяется как включающий вариант
использования, хотя на самом деле должно быть наоборот: включение
331
варианта использования является абстрактным вариантом использования.
См. обсуждение определения абстрактных вариантов использования.
Включающая взаимосвязь между вариантами использования показана
пунктирной стрелкой с открытой стрелкой от включающего (базового)
варианта
использования
к
включенному
(общая
часть)
варианту
использования. Стрелка помечена ключевым словом «include» (рис. 12.48.).
Рис. 12.48. Вариант использования Checkout включает несколько
вариантов использования — Scan Item, Calculation Total and Tax и
Payment.
Большой и сложный вариант использования Checkout содержит
несколько извлеченных вариантов использования, каждый меньший вариант
использования описывает некоторую логическую единицу поведения (рис.
12.49.). Обратите внимание, что включение вариантов использования
Checkout становится неполным само по себе и требует завершения
включенных вариантов использования.
Рис. 12.49. Варианты использования «Ввод средств» и «Снятие
наличных» включают вариант использования «Аутентификация
клиента».
332
1.4.8.2 Сравнение взаимосвязей вариантов использования
Довольно
распространённым
вопросом
является:
какие
отношения
вариантов использования следует использовать и в какой ситуации. Авторы
объединили несколько ключевых моментов из спецификации UML 2.4 в
приведенную ниже таблицу.
Таблица 10
Взаимосвязь Обобщение
Обобщение
Базовый вариант использования может быть абстрактным
(неполным) или конкретным (полным).
Специализированный вариант использования обязателен, а не
необязателен, если базовый вариант использования является
абстрактным.
Нет явного местоположения для использования специализации.
Нет явного условия для использования специализации.
Таблица 11
Взаимосвязь Расширение
333
(конкретным) сам по себе, определяемым независимо.
Расширение варианта использования является необязательным,
дополнительным.
Имеет хотя бы одно явное расположение расширения.
Может иметь необязательное условие расширения.
Таблица 12
Взаимосвязь Включение
Включение
Базовый вариант использования неполный (абстрактный
вариант использования).
Включенный вариант использования обязателен, а не
необязателен.
Нет явного места включения, но оно включено в каком-то месте.
Нет явного условия включения.
1.4.8.3 Отсутствие связи варианта использования
Одним,
казалось
бы,
простым,
но
неразрешимым
примером
использованием UML 2.4 является указание взаимосвязей между Payment,
Payment by Credit, Payment by Cash и т. д., в случае использования, когда
мы хотим разрешить клиентам платить частично наличными, частично в
кредит и т. д. Это довольно распространенная ситуация для Кассового
терминала в супермаркетах. (Еще один похожий пример: «Планирование
334
поездки и поиск рейса», «Найти отель», «Найти машину» и т. д., где
пользователь может захотеть искать не одну, а несколько
вещей
одновременно.)
Хотя обобщение варианта использования кажется естественным для
платежа, платежа в кредит, платежа чеком и т. д., мы не можем его
использовать, потому что он предполагает использование только одной
конкретной формы платежа за раз.
Расширение кажется подходящим, потому что оно имеет точки
расширения с условиями расширения, но мы не можем его использовать,
потому что базовый вариант использования Оплата должна быть завершена
сама по себе, что, очевидно, не так, как у нас.
Включение кажется подходящим, потому что базовый вариант
использования «Платеж» не завершен сам по себе, и все различные виды
платежей дополняют его, но мы не можем его использовать, потому что для
отношения включения включенный случай не является необязательным, а
обязательным (и нет условия включения), это означает, что клиенту
придется платить, используя все способы оплаты, что совершенно
неправильно.
Авторы надеются, что разработчики UML обновят отношения
включения, чтобы разрешить условия и местоположения включения, как это
было сделано для extend, или, по крайней мере, предоставят больше
примеров
диаграмм
вариантов
использования
в
будущих
версиях
спецификации UML.
1.4.9. Расширение варианта использования UML
1.4.9.1 Понятие расширения варианта использования UML
Расширение — это направленная связь, которая указывает, как и
когда поведение, определенное в обычно дополнительном (необязательном)
335
расширяющем
прецеденте,
может
быть
вставлено
в
поведение,
определенное в расширенном прецеденте.
Расширенный вариант использования имеет смысл сам по себе, он не
зависит от расширенного варианта использования. Расширение варианта
использования обычно определяет необязательное поведение, которое само
по себе не обязательно имеет смысл. Отношение расширения принадлежит
варианту использования расширения. Один и тот же расширяющий
прецедент может расширять более одного прецедента, а сам расширяющий
прецедент может быть расширен.
Расширение происходит в одной или нескольких точках расширения,
определенных в расширенном варианте использования.
Связь расширения показана в виде пунктирной линии с открытой
стрелкой, направленной от расширяющего варианта использования к
расширенному (базовому) варианту использования. Стрелка помечена
ключевым словом «extend» (рис. 12.50.).
Рис. 12.50. Вариант использования регистраци является полным и
содержательным сам по себе. Его можно расширить с помощью
дополнительного варианта использования Get Help On Registration.
Состояние отношения расширения, а также ссылки на точки
расширения дополнительно отображаются в примечании к комментарию,
прикрепленном к соответствующему отношению расширения (рис. 12.51.).
336
Рис. 12.51. Вариант использования «Регистрация» условно расширяется
вариантом использования «Получить справку по регистрации» в
справке по регистрации точки расширения.
1.4.9.2 Точка расширения
Точка расширения — это характеристика варианта использования,
которая идентифицирует (ссылается) на точку в поведении варианта
использования, где это поведение может быть расширено каким-либо другим
(расширяющим) вариантом использования, как указано в отношении
расширения.
Точки расширения могут быть показаны в ячейке овального символа
варианта использования под заголовком Точки расширения. Каждая точка
расширения
должна
иметь
имя,
уникальное
в
рамках
варианта
использования. Точки расширения отображаются в виде текстовой строки в
соответствии со следующим синтаксисом:
точка расширения::=имя[: объяснение ]
Необязательное объяснение — это некоторое описание, которое
обычно дается в виде неофициального текста. Это могут быть и другие
формы, такие как имя состояния в конечном автомате, действие на
диаграмме действий, некоторое предусловие или постусловие (рис. 12.52.).
337
Рис. 12.52. Пример использования регистрации с точками расширения
Справка по регистрации и Пользовательское соглашение
Точки расширения могут быть показаны в ячейке прямоугольника
варианта использования со значком эллипса под заголовком точки
расширения (рис. 12.53.).
Registration О
-userProfile
extension points
Registration Help
User Agreement
Рис. 12.53. Точки расширения варианта использования «Регистрация» ,
показанные в виде прямоугольника
338
2. UML ДИАГРАММЫ ИНФОРМАЦИОННЫХ ПОТОКОВ
2.1. Понятие и схема UML диаграммы информационных потоков
Диаграмма информационных потоков — это диаграмма поведения
UML, которая показывает обмен информацией между сущностями системы
на некоторых высоких уровнях абстракции. Информационные потоки могут
быть полезны для описания циркуляции информации через систему путем
представления аспектов моделей, еще не полностью определенных или с
меньшим количеством деталей.
Информационные потоки не определяют характер информации,
механизмы ее передачи, последовательность обмена или какие-либо условия
управления.
Информационные элементы могут использоваться для
представления информации, проходящей через систему по информационным
потокам до того, как будут разработаны детали их реализации (рис. 13.1.).
Рис. 13.1. Элементы UML схемы информационного потока -
информационный поток, информационный элемент.
Ограничения диаграмм информационных потоков.
Диаграммы информационных потоков в UML предоставляют довольно
скудные выразительные возможности.
339
Информационные элементы не содержат сведений об информации,
которую они передают. У них нет черт, обобщений, ассоциаций.
2.2. Элементы информационного потока
2.2.1. Понятие информационного потока
Информационный поток — это направленная связь, которая
используется как спецификация некоего «информационного канала» для
однонаправленной передачи информации от источников к целям.
Информация, перемещающаяся по информационному каналу, может
быть
представлена
абстрактными
элементами
информации
и/или
конкретными классификаторами.
Источники и цели информационного потока должны быть одного из
следующих типов: актер, вариант использования, узел, артефакт, класс,
компонент, порт, свойство, интерфейс, пакет, узел действия, раздел
действия и спецификация экземпляра.
Информационный поток представлен в виде пунктирной линии с
открытой стрелкой, указывающей от источника(-ов) потока к цели(-ям). Хотя
это обозначение выглядит именно как зависимость, это независимость.
Чтобы его отличить, информационный поток должен иметь ключевое слово
«поток» над или под пунктирной линией.
При «прикреплении» информационного объекта к пунктирной линии
информационного потока имя информационного объекта отображается
рядом с соответствующей линией «потока» (рис. 13.2.). По необъяснимым
причинам или по ошибке в спецификациях UML 2.x имя информационного
элемента отображается строчными буквами.
Рис. 13.2. Информационный поток элемента информации о заказе
от клиента в отдел выставления счетов.
340
2.2.2. Информационный элемент
Информационная единица представляет собой классификатор,
который представляет некоторую информацию, передаваемую внутри
системы от источника(-ов) к цели(-ям) информационного потока.
Информационные элементы не содержат подробностей о передаваемой
ими информации, поскольку они не имеют функций.
Информационные элементы являются абстрактными и не могут быть
конкретизированы.
При «прикреплении» информационного объекта к пунктирной линии
информационного потока название информационного объекта отображается
рядом с линией «потока» (рис. 13.3.). По необъяснимым причинам или по
ошибке в спецификациях UML 2.x имя информационного элемента
отображается строчными буквами.
order
Billing
Department
Customer
Рис. 13.3. Информационный поток элемента информации
о заказе от клиента в отдел выставления счетов.
Информационный элемент может быть представлением некоторых
классификаторов. Представленные классификаторы могли бы уточнить
структуру
или
семантику
информации,
передаваемой
элементом
информации. Классификатором, реализующим информационный элемент,
может быть только другой информационный элемент, класс, интерфейс,
сигнал, компонент.
Информационные единицы не могут участвовать в обобщениях и
ассоциациях.
341
2.3. UML-классификатор
2.3.1. Понятие UML-классификатора
Классификатор — это абстрактный метакласс, который описывает
(классифицирует) набор экземпляров, имеющих общие признаки. Функция
объявляет структурную или поведенческую характеристику экземпляров
классификаторов (рис. 13.4.).
Более формально классификатор (расширяет):
•
тип,
•
шаблонный элемент,
•
переопределяемый элемент,
•
пространство имен.
Рис. 13.4. Классификатор UML — это тип, шаблонный элемент,
переопределяемый элемент и пространство имен.
342
Пространство имен — это именованный элемент, который может
владеть (содержать) другими именованными элементами. Как пространство
имен, классификатор может иметь функции.
Тип представляет набор значений. Типизированный элемент, имеющий
этот тип, ограничен представлением значений в этом наборе. Как тип,
классификатор может владеть обобщениями, что позволяет определять
отношения обобщения к другим классификаторам.
Переопределяемый
элемент
—
это
элемент,
который
при
определении в контексте классификатора может быть переопределен более
конкретно или иначе в контексте другого классификатора, который
специализируется (прямо или косвенно) на классификаторе контекста. Как
переопределяемый
элемент,
классификатор
может
переопределять
вложенные классификаторы.
Хотя классификатор является абстрактным элементом модели и
поэтому не нуждается в графической нотации, UML предоставляет нотацию,
которая используется в качестве нотации по умолчанию для любого
подкласса
конкретного
классификатора.
Некоторые
специализации
классификатора имеют свои обозначения.
Обозначение по умолчанию для классификатора представляет собой
прямоугольник со сплошным контуром, содержащий имя классификатора, и,
возможно,
с
отсеками,
разделенными
горизонтальными
линиями,
содержащими функции или другие элементы классификатора. Конкретный
тип классификатора может быть показан в каймах над названием.
Назовите имя классификатора заглавными буквами (т. е. начните с
прописной буквы), используйте полужирный шрифт и отцентрируйте имя.
Центральное ключевое слово (включая имена стереотипов) в обычном виде
внутри кайм над именем классификатора.
Любой отсек может быть подавлен. Линия-разделитель для закрытого
отсека не рисуется. Если компартмент подавлен, нельзя сделать никаких
343
выводов о наличии или отсутствии в нем элементов. Имена отсеков можно
использовать для устранения двусмысленности, если это необходимо.
Начинайте имена атрибутов и операций со строчной буквы. Имена из
нескольких слов часто образуются путем объединения слов и использования
нижнего регистра для всех букв, за исключением первой буквы каждого
слова, кроме первой. Выравнивание по левому краю атрибутов и операций на
простом лице.
Тип, видимость, значение по умолчанию, множественность, строка
свойства могут быть скрыты от отображения, даже если в модели есть
значения. Отдельные свойства атрибута могут отображаться в столбцах, а не
в виде непрерывной строки.
Некоторые
ассоциация,
тип
примеры
классификаторов:
данных,
актер
класс,
(подкласс
интерфейс,
поведенческого
классификатора), вариант использования (подкласс поведенческого
классификатора),
компонент
(подкласс
артефакт, узел, сигнал (рис. 13.5.).
344
класса),
сотрудничество,
Templateable
Element
Type
Namespace
Redefinable
Element
Classifier
Structured
Classifier
Behaviored
Classifier
лллл
Encapsulated
Classifier
Interface
DataType
\.r
Class
Г Collaboration ;
UseCase
ч
I
Actor
Primitive
Typo
sn
Component4^
Enumeration
Рис. 13.5. Наиболее важные классификаторы UML 2.5 —класс,
интерфейс, тип данных, компонент, совместная работа, вариант
использования и т. д.
2.3.2. Абстрактный классификатор
Абстрактный классификатор не дает полного описания признаков и
обычно не может быть реализован. Он предназначен для специализации
(подкласса) другими классификаторами. Классификаторы по умолчанию
являются конкретными (не абстрактными).
Название
абстрактного
классификатора
выделено
курсивом.
2Абстрактный классификатор также может быть показан с помощью
ключевого слова {abstract} после или под именем классификатора.
345
2.3.3. Окончательный классификатор
В
UML
2.4
классификатор
имеет
логический
атрибут
isFinalSpecialization. Если это правда, классификатор не может быть
специализирован
путем
обобщения
и
называется
окончательным
классификатором.
Итоговый классификатор не может быть специализированным
(подклассифицированным) с
обобщением другими классификаторами.
Классификаторы по умолчанию не являются окончательными. Родители
классификатора не должны быть окончательными.
UML не предоставляет визуальных обозначений для окончательных
классификаторов. Что еще больше сбивает с толку, так это то, что
классификатор является переопределяемым элементом и, как таковой,
наследует логический атрибут isLeaf, который указывает, возможно ли
переопределить элемент в подклассах или нет. Необходимость иметь как
isFinalSpecialization, так и isLeaf — загадка.
2.3.4. Тип
Тип — это абстрактный метакласс UML, который представляет набор
значений и используется в качестве ограничения диапазона значений,
представляемых связанным типизированным элементом (рис. 13.6.).
Типизированный элемент, имеющий этот тип, ограничен представлением
значений в наборе значений. Типизированный элемент без связанного типа
может представлять значения любого типа.
346
Рис. 13.6. Тип — это метакласс UML, используемый в качестве
ограничения диапазона значений, представленных связанным
типизированным элементом.
И
тип,
и
типизированный
элемент
являются
абстрактными
метаклассами UML и не имеют нотации.
2.3.5. Шаблонный элемент
2.3.5.1 Понятие шаблонный элемент
Шаблонный элемент — это элемент, который можно дополнительно
определить, как шаблон или связать с другими шаблонами (рис. 13.7.).
347
Рис. 13.7. Класс шаблона Массив и связанный класс Customers.
Шаблон
Шаблон — это шаблонный элемент, содержащий подпись шаблона
(рис. 13.8.).
шаблон
совместной работы
параметр
шаблона класса
параметр
шаблона класса
Рис. 13.8. Шаблон совместной работы
Связанный элемент
Связанный элемент — это шаблонный элемент, который содержит
привязки к шаблонам, которые описывают, как конструируется шаблонный
элемент путем замены формальных параметров шаблона фактическими
параметрами (рис. 13.9.).
348
Рис. 13.9. Шаблон пакета Service Provider и связанный пакет Scheduler
Service.
2.3.5.2 Подпись шаблона
Сигнатура шаблона — это элемент, определяющий упорядоченный
набор формальных параметров шаблона для шаблона.
Формальные
параметры
шаблона
показаны
в
пунктирном
прямоугольнике, наложенном на символ шаблона, обычно в правом верхнем
углу. Список формальных параметров шаблона не должен быть пустым,
иметь хотя бы один формальный параметр.
Список параметров формального шаблона может отображаться в виде
списка, разделенного запятыми, или это может быть один параметр
формального шаблона на строку.
Обратите внимание, что спецификация UML позволяет скрыть подпись
шаблона на диаграмме.
2.3.5.3 Параметр шаблона
349
Параметр шаблона — это элемент (абстрактный корневой метакласс
UML), который предоставляет параметрический элемент как формальный
параметр шаблона. Он принадлежит подписи шаблона.
Формальный параметр шаблона ограничивает элементы, которые могут
быть заменены
фактическими параметрами в привязке шаблона.
Формальный параметр шаблона может использоваться только в рамках
шаблона и его специализаций,
если таковые имеются.
Его нельзя
использовать в других частях модели.
Формальный параметр шаблона отображается в списке параметров
шаблона с использованием следующего синтаксиса:
параметр-шаблона::= имя-шаблона-параметра [ ':' тип-параметра ] [ '=' по умолчанию ]
2.3.5.4 Привязка шаблона
Связывание шаблона — это направленная связь между связанным
элементом и сигнатурой целевого шаблона.
Привязка шаблона задает и владеет набором замен фактических
параметров шаблона формальными параметрами шаблона и владеет ими.
Привязка
шаблона показана пунктирной
стрелкой,
украшенной
ключевым словом «bind» и информацией о привязке, с полым треугольным
наконечником и направленной от привязанного элемента в конце к шаблону
(рис. 13.10.).
Рис. 13.10 Связывание заменяет класс T классом Customer
и границей n с целочисленным значением 24.
350
Информация о привязке обычно отображается в виде списка
разделенных запятыми шаблонов-параметров-подстановок, заключенных в
угловые скобки '<' и '>':
замена-шаблона-параметра ::= имя -шаблона-параметра '->' фактический-параметр-шаблона
Синтаксис
имени
-параметра-шаблона
определяется
типом
параметризованного элемента для этой подстановки параметров шаблона,
тогда как фактический-параметр-шаблона зависит от типа элемента.
2.3.6. Переопределяемый элемент
Переопределяемый элемент — это
абстрактный
именованный
элемент, который при определении в контексте обобщения классификатора
может быть переопределен более конкретно или иначе в контексте
другого классификатора, специализирующегося (прямо или косвенно)
классификатора контекста.
Переопределяющий элемент должен быть непротиворечивым или
совместимым с переопределяемым им элементом.
Переопределяемый
элемент может быть переопределен несколько раз. Кроме того, один
переопределяющий
элемент
может
переопределять
несколько
унаследованных переопределяемых элементов.
UML не предоставляет нотации для переопределяемого элемента.
Конкретные подклассы переопределяемого элемента определяют свои
собственные обозначения.
Переопределяемый элемент имеет логический атрибут isLeaf, который
указывает, возможно ли переопределить элемент в подклассах. Если
значение равно true, дальнейшее переопределение элемента невозможно. В
языке Java он соответствует конечному классу, в C# — закрытому классу.
В предыдущих версиях UML конечный класс отображался со
свойством "{leaf}" под именем класса. (Наличие ключевого слова для
логического типа без значения подразумевает значение true.)
351
В UML 2.3 метаатрибут isLeaf был заменен свойством isLeaf
элемента,
переопределяемого
но
спецификация
не
предоставляет
обозначения для элементов, имеющих это свойство как истинное.
Некоторые подклассы переопределяемого элемента:
•
классификатор
•
характерная черта
•
точка расширения
2.3.7. Пространство имен
Пространство имен — это абстрактный именованный элемент,
который содержит (или владеет) набором именованных элементов,
которые
можно
идентифицировать
по
имени.
Другими
словами,
пространство имен — это контейнер для именованных элементов (рис.
13.11.).
Некоторые примеры (подклассы) пространства имен:
•
упаковка
•
классификатор
•
поведенческая особенность
•
государство
•
область, край
352
Рис. 13.11. Пространство имен — это абстрактный именованный элемент
и контейнер для именованных элементов.
Членами
пространства
имен
являются
либо
элементы,
непосредственно принадлежащие пространству имен, либо элементы,
введенные в пространство имен путем наследования или импорта. Таким
образом, член пространства имен может быть одним из следующих:
•
принадлежащий член,
353
•
унаследованный член,
•
импортированный член.
Именованный элемент может принадлежать не более чем одному
пространству имен.
В UML 2.x не совсем понятно, что такое унаследованные члены
пространства имен. Хотя унаследованные члены упоминаются в контексте
пространства имен, унаследованные члены фактически определяются на
уровне классификатора, который является подклассом пространства имен.
Элементы могут быть импортированы в пространство имен как по
отдельности, так и все сразу. Член может иметь несколько имен в
пространстве имен, если он импортирован более одного раза с разными
псевдонимами.
Пространство имен обеспечивает способ идентификации именованных
элементов по-простому или полному имени. На импортированные элементы
можно ссылаться в импортирующем пространстве имен без уточнения. В
случае конфликтов имен следует использовать полные имена или
псевдонимы, чтобы различать элементы, на которые делается ссылка.
Члены
пространства имен (собственные,
импортированные или
унаследованные именованные элементы) могут упоминаться составным
именем в форме:
имя-пространства-имен:: имя-элемента.
Одно пространство имен может быть заключено в другое пространство
имен. Имена, на которые можно ссылаться без уточнения внутри замкнутого
пространства имен, включают в себя члены пространства имен и все не
скрытые члены включающих пространств имен.
Правило по умолчанию для различения одного именованного элемента
от другого состоит в том, что два элемента различимы, если
•
у них есть несвязанные типы, или
•
родственные типы, но разные имена.
354
Это правило может быть переопределено для особых случаев,
например, операции класса различаются по их сигнатуре.
Обозначение
Пространство имен не имеет самостоятельной нотации. Некоторые
подклассы определяют свои собственные специальные обозначения.
355
3. UML ДИАГРАММА ДЕЯТЕЛЬНОСТИ
3.1. Понятие и схема UML диаграммы деятельности
Диаграмма деятельности — это диаграмма поведения UML, которая
показывает поток управления или поток объектов с акцентом на
последовательность и условия потока. Действия, координируемые моделями
действий, могут быть инициированы, когда заканчиваются другие действия,
становятся доступными объекты и данные или происходят какие-то внешние
по отношению к потоку события.
Наглядный пример с разъяснением ниже на рисунке 14.1, где
запрошенный заказ является входным параметром действия. После того, как
заказ принят, и вся необходимая информация заполнена, оплата принимается
Рис. 14.1. Схема UML диаграммы деятельности на примере описания
действий бизнес-потока обработки заказа
На диаграммах действий UML обычно рисуются следующие узлы и
ребра: действие, раздел, действие, узлы объекта, элемент управления,
ребро действия.
В разделе четыре данной книги вы можете найти несколько примеров
диаграмм деятельности:
356
•
Покупки в интернет-магазине
•
Бизнес-поток — технологический заказ
•
Бизнес-поток — процесс управления документами
•
Дизайн программного обеспечения — решение проблемы
•
Sentinel HASP SL — ручная активация пробного продукта
•
Единый вход для Google Apps
3.2. Активность
3.2.1. Понятие активности
Активность — это параметризованное поведение, представленное в
виде согласованного потока действий.
Поток выполнения моделируется как узлы действий, соединенные
ребрами действий. Узел может быть выполнением подчиненного поведения,
такого
как
арифметическое
вычисление,
вызов
операции
или
манипулирование содержимым объекта. Узлы действий также включают
конструкции управления потоком, такие как синхронизация, принятие
решений и управление параллелизмом. Действия могут формировать
иерархию вызовов, вызывая другие действия, в конечном счете приводя к
отдельным действиям. В объектно-ориентированной модели действия
обычно вызываются косвенно как методы, связанные с операциями, которые
вызываются напрямую.
Activity содержит узлы активности, которые могут быть:
•
действие
•
объект
•
контроль
Активности могут содержать действия различных видов:
•
Вхождения
примитивных
функций,
таких
как
арифметические
функции.
•
Призывы к поведению, например, к действиям.
•
Коммуникационные действия, такие как отправка сигналов.
357
•
Манипуляции с объектами, такие как чтение или запись атрибутов, или
ассоциаций.
Существуют действия, которые вызывают действия — либо напрямую,
используя действие поведения вызова, либо косвенно, используя действие
операции вызова.
Активность может быть представлена в виде прямоугольника со
скругленными углами с именем активности в верхнем левом углу и узлами и
ребрами активности внутри границы (рис. 14.2.). В примерах спецификации
UML 2.4 имя действия выделено жирным шрифтом.
Рис. 14.2. Интернет-магазины.
Параметры действия отображаются на границе и перечислены под
именем действия в виде (рис. 14.3.):
имя-параметра: тип-параметра.,
Рис. 14.3. Аутентифицируйте действия пользователя с двумя
параметрами — идентификатором входа и паролем.
358
Поскольку поведенческая активность может иметь ограничения до и
после условия. Если они присутствуют, они отображаются с ключевыми
словами «предусловие» и «постусловие» соответственно.
Ключевое слово «singleExecution» используется для действий, которые
выполняются как одно совместное выполнение (singleton), в противном
случае каждый вызов выполняется в своем собственном пространстве.
Граница деятельности с закругленными углами может быть заменена
обозначением рамки для диаграмм. Вид фрейма в данном случае деятельность или действие в краткой форме. Параметры активности, если
таковые имеются, отображаются на рамке (рис. 14.4.).
Рис. 14.4. Аутентифицируйте кадр активности пользователя с двумя
параметрами — идентификатором входа и паролем.
Обозначение классов с ключевым словом «деятельность» может
использоваться для того, чтобы показать особенности рефлексивной
деятельности, указать, что это класс деятельности. При необходимости также
можно использовать нотацию ассоциации и конечного автомата.
UML позволяет поведениям создавать токены, которые являются
действиями и которые, в свою очередь, могут выполняться во время
выполнения.
3.2.2. Раздел активности
Раздел активности — это группа действий для действий, которые
имеют некоторые общие характеристики.
359
Разделы часто соответствуют организационным единицам или
субъектам бизнеса в бизнес-модели.
Разделы
обеспечивают
ограниченное
представление
о
поведении,
вызываемом в действиях. Ограничения могут быть выбраны в соответствии с
типом элемента, который представляет раздел. Следующие ограничения
являются нормативными (стандартными) в UML 2.4:
•
классификатор
•
экземпляр
•
часть
•
атрибут и значение
Например,
разделы
могут
представлять
определенные
классификаторы. В этом случае действия в каждом разделе должны быть
операциями
или сигналами,
нацеленными
на объекты, являющиеся
экземплярами соответствующего классификатора.
Раздел может представлять некоторый атрибут, а его подразделы —
конкретные значения этого атрибута. Например, раздел может представлять
местоположение, в котором выполняется поведение, а подразделы могут
представлять определенные значения для этого атрибута, например, Нью-
Йорк.
Раздел активности может быть показан с использованием обозначения
дорожки — с двумя, обычно параллельными линиями, горизонтальными или
вертикальными, и именем, обозначающим раздел в рамке на одном конце
(рис. 14.5. и 14.6.). Любые узлы активности, например, действия и ребра,
расположенные между этими линиями, считаются содержащимися в разделе.
360
Рис. 14.5. Деятельность разделяет
Рис. 14.6. Деятельность разделяет
клиентов и отдел заказов как
клиентов и отдел заказов как
горизонтальные плавательные
вертикальные плавательные
дорожки.
дорожки.
Иерархическое разбиение представлено с помощью дорожек для
подразделов, как показано ниже (рис. 14.7.).
«attribute»
«external» Department
Customer
Order Dept
4
Рис. 14.7. Иерархическое разделение с подразделами
Раздел может быть помечен как измерение для его подразделов, чтобы
содержать (группировать) эти подразделы по измерению. Например,
действие может иметь одно измерение разделов для местоположения, в
котором выполняются содержащиеся в нем действия, а другое — для
стоимости их выполнения. Разделы измерений не могут содержаться ни в
одном другом разделе.
Диаграммы также могут быть разделены многомерно, где каждая
плавательная ячейка представляет собой пересечение нескольких разделов.
Разделы в каждом измерении могут быть сгруппированы в объемлющий
361
раздел действий с isDimension=true, имя которого является именем
измерения. Однако вместо того, чтобы отображаться как сам раздел,
измерение указывается путем размещения его имени рядом с набором
разделов в измерении.
Раздел может представлять внешний объект, к которому структура
разделения не применяется. Внешние разделы являются преднамеренными
исключениями из правил структуры разделов. Например, в измерении могут
быть разделы, показывающие части структурированного классификатора.
Он может иметь внешний раздел, представляющий собой не одну из частей,
а совершенно отдельный классификатор. В бизнес-моделировании внешние
разделы могут использоваться для моделирования объектов вне бизнеса.
Когда считается, что действия происходят за пределами домена
конкретной модели, раздел может быть помечен ключевым словом
«внешний». Всякий раз, когда действие в дорожке помечается как
«внешнее», это переопределяет обозначение дорожки и измерения (рис.
14.8.).
«external»
Customer
Рис. 14.8. Действие покупки происходит во внешнем разделе Customer
В тех случаях, когда дорожки не
могут использоваться для
отображения разделов, вместо этого можно использовать альтернативную
текстовую нотацию с уточненным именем действия. В этом случае имя
раздела помещается в круглых скобках над названием действия. Список
имен разделов, разделенных запятыми, означает, что узел содержится более
чем в одном разделе. Двойное двоеточие в имени раздела указывает на то,
362
что раздел является вложенным, причем более крупные разделы идут в
начале имени (рис. 14.9.).
r
I
«external»
(Customer)
Buy
Рис. 14.9. Действие покупки происходит во внешнем разделе Customer
3.2.3. Край активности
Activity Edge — это абстрактный класс для направленных соединений,
по которым токены или объекты данных перетекают между узлами
активности. Он включает в себя ребра управления и ребра потока
объектов. Источник и цель ребра должны находиться в той же активности,
что и ребро.
Край активности обозначается незамкнутой линией стрелки,
соединяющей два узла активности (рис. 14.10.).
Рис. 14.10. Край действия соединяет порядок заполнения и порядок
просмотра.
Ребрам можно присваивать имена, однако ребрам не обязательно иметь
уникальные имена в рамках действия. Если ребро имеет имя, оно указывается
рядом со стрелкой (рис. 14.11.).
Рис. 14.11. Ребро активности «обновлено» соединяет два узла.
Край активности может иметь защиту — спецификацию, оцениваемую
во время выполнения, чтобы определить, можно ли пройти через край.
363
Охранник должен оцениваться как истина для каждого маркера, который
предлагается пройти по краю.
Защита края активности показана в квадратных скобках, которые
содержат защиту (рис. 14.12.).
Рис. 14.12. Заполнить заказ, когда приоритет равен 1
Край активности можно обозначить с помощью коннектора, который
представляет собой небольшой кружок с
именем внутри. Хотя в
спецификации UML 2.4 это называется name of the edge, приведенная
нотация соединителя и примеры предполагают, что у соединителя есть
собственное имя (также называемое label).
Соединители обычно используются, чтобы
избежать рисования
длинного края (рис. 14.13.). Это чисто обозначение. Это не влияет на
базовую модель. Используемые круги и линии сопоставляются с одним
ребром активности в модели. Каждый коннектор с заданной меткой должен
быть связан ровно с одним другим соединителем с такой же меткой на одной
и той же диаграмме действий. У одного коннектора должно быть ровно одно
входящее ребро, а у другого ровно одно исходящее ребро, каждый с одним и
тем же типом потока, объекта или элемента управления.
Рис. 14.13. Соединитель A соединяет два ребра между Fill Order и Review
Order.
364
3.2.4. Край потока объекта
Ребра потока объектов — это ребра активности, используемые для
отображения потока данных объекта и токенов данных между узлами
действия.
Поток объекта обозначается линией со стрелкой (рис. 14.14.).
Рис. 14.14. Поток объектов ордеров между действиями «Заполнить
ордер» и «Просмотреть ордер»
По ребру может проходить любое количество жетонов, группами
одновременно или по отдельности в разное время. Атрибут веса определяет
минимальное количество токенов, которые должны пересечь ребро
одновременно. Когда предлагается минимальное количество токенов, все
токены в источнике одновременно предлагаются цели.
Вес ребра может быть показан в фигурных скобках, содержащих вес
(рис. 14.15.). Вес - это спецификация значения, которая может быть
константой, которая оценивается как ненулевое неограниченное натуральное
значение. Неограниченный вес обозначается знаком «*».
Рис. 14.15. Отправить уведомление, когда количество предупреждений
достигает 6.
365
3.2.5. Прерывание края
Прерывающий
край
это
край
активности,
выражающий
прерывание для областей, в которых есть прерывания (рис. 14.16.). Он
представлен в виде молнии.
-ч
\
Cancel
/
Request
1
1 /
Рис. 14.16. Сигнал Cancel Request вызывает прерывание, приводящее к
Cancel Order.
Вариант
обозначения
прерывающегося края
-
зигзагообразный
орнамент на прямой линии (рис. 14.17.).
'Ч
V
\ Cancel
/ Request
<
s.
-
/ -------------- 1
:
I Order
i
Process
Order
J
Cancel
/
Рис. 14.17. Сигнал Cancel Request вызывает прерывание, приводящее к
Cancel Order.
3.3. Действия
3.3.1. Понятие действия
Действие — это именованный элемент, представляющий один
атомарный шаг внутри действия, т. е. не подвергающийся дальнейшей
декомпозиции
в
рамках действия.
Активность
представляет
собой
поведение, состоящее из отдельных элементов, являющихся действиями.
Обратите внимание, что действие поведения при вызове может
ссылаться на действие (вызов). Это действие просто для деятельности,
366
содержащей его, но может быть сложным по своему эффекту. Активность
определяет поведение, которое можно повторно использовать во многих
местах.
Явно смоделированные действия как часть действий появились в UML
2.0 и заменяют состояние действия, состояние вызова и состояние
поддействия в UML 1.5.
Действия обозначены прямоугольниками со скругленными углами
(рис. 14.18.). Название или описание действия размещается внутри
прямоугольника.
Process
Order
Рис. 14.18. Действие «Обработка заказа».
Название действия обычно представляет собой глагол действия или
существительное для действия с некоторым объяснением. Не используйте
имена состояний в качестве имен действий. Некоторые примеры названий
действий:
•
Заполнить заказ
•
Обзорный документ
•
Записаться на курс
•
Проверить
•
Показать страницу ошибки
Действие также может быть выражено на каком-либо языке действий,
зависящем от приложения (рис. 14.19.).
for (Account a: accounts)
a.verifyBalance();
Рис. 14.19. Пример действия, выраженного с помощью языка действий,
зависящего от инструмента.
367
Действие может иметь наборы входящих и исходящих ребер
активности, которые определяют поток управления и поток данных от и к
другим узлам.
Действие не начнет выполнение, пока не будут выполнены все его
входные условия. Завершение выполнения действия может разрешить
выполнение набора последующих узлов и действий, которые получают свои
входные данные от выходных данных действия.
Если
во
время
действия
выполнения
возникает
исключение,
выполнение действия прекращается, и это действие не генерирует обычный
вывод. Если у действия есть обработчик исключений, оно получает объект
исключения в качестве токена. Если у действия нет обработчика исключений,
исключение распространяется на охватывающий узел и так далее, пока оно
не будет перехвачено одним из них. Если исключение распространяется за
пределы вложенного узла (действия, узла структурированного действия или
действия),
все
маркеры
во
вложенном узле завершаются.
Данные,
описывающие исключение, представляются как объект любого класса.
Локальные
предусловия
и
локальные
постусловия
—
это
ограничения, которые должны соблюдаться, когда выполнение начинается и
завершается соответственно. Они действуют только в той точке потока, в
которой они указаны, а не глобально для других вызовов поведения в других
местах потока или на других диаграммах.
То, как применяются локальные пред- и постусловия, определяется
реализацией. Например, нарушения могут быть обнаружены во время
компиляции или во время выполнения. Эффектом может быть ошибка,
которая останавливает выполнение, или просто предупреждение и так далее.
Локальные предусловия и локальные постусловия отображаются в
виде примечаний, прикрепленных к вызову с ключевыми словами
«localPrecondition» и «localPostcondition» соответственно (рис. 14.20.).
368
Рис. 14.20. Локальные предварительные и последующие условия
показаны в виде примечаний, прикрепленных к действию «Обработка
заказа».
Подклассы действий перечислены ниже. Обратите внимание, что я добавил
действия объекта и действия события, которые не определены явно в
спецификации UML 2.4.
•
действие объекта (неявное в стандарте UML)
•
переменное действие
•
действие вызова
•
вызвать действие исключения
•
действие структурной особенности
•
действие ссылки
•
действие события (неявное в стандарте UML)
•
непрозрачное действие
3.3.2. Действие объекта
Действия с объектами включают в себя различные действия над
объектами,
например,
создание
и
уничтожение
объекта,
проверка
идентичности объекта, указание значения и т. д. Действие объекта не
определяется явно стандартом UML. В стандарте UML все действия с
объектами являются прямыми подклассами действий.
Действия с объектом:
•
создать действие объекта
369
действие уничтожения объекта
действие проверки личности
•
читать само действие
•
действие спецификации значения
•
запустить действие поведения классификатора
•
чтение классифицировано действие объекта
•
переклассифицировать объектное действие
•
действие расширения чтения
3.3.3. Переменное действие
Действия с переменными включают в себя чтение, запись, добавление,
удаление и очистку переменных (рис. 14.21.).
Рис. 14.21. Обзорная диаграмма действий с переменными
3.3.4. Действие вызова
Действия вызова включают в себя несколько действий вызова,
действия отправки и широковещания сигнала и действия отправки объекта
(рис. 14.22.).
370
—\
Z-----
Action
V__
f----- ------InvocationAction
JAO
z
Call
Action
—\
_J
CallBehavior
Action
StartObject
BehaviorAction
\__ ______
SendSignal
Action
-------------------X
Broadcastsignal
Action
SendObject
Action
\______ _ _______ 7
CallOperation
Action
\_ ______7
Рис. 14.22. Обзорная диаграмма действий вызова
3.3.5. Действия при вызове
Действие вызова поведения — это действие вызова, которое
вызывает поведение напрямую, а не вызывает операцию, которая вызывает
поведение.
Параметры могут быть переданы действием вызываемому поведению.
Количество выводов аргумента и количество параметров поведения типа in и
in-out должны быть равны. Также равными должны быть количество выводов
результата и количество параметров поведения типа return, out и in-out.
Для синхронных вызовов выполнение действия поведения вызова
откладывается
до
завершения
выполнения
вызванного
поведения.
Выполнение вызывающего действия блокируется до получения ответа. Ответ
включает значения для любых параметров return, out или inout. Значения
результата помещаются на выводы результата действия поведения вызова,
после чего выполнение действия завершается. Если выполнение вызванного
371
поведения вызывает исключение, исключение передается обратно в действие
поведения вызова, чтобы начать поиск некоторого обработчика исключений.
Если вызов асинхронный, действие вызова завершается сразу после
запуска поведения. Любые возвращаемые или исходящие значения из
вызванного поведения не передаются обратно.
Действие поведения вызова отображается как действие с именем
поведения, которое выполняется действием, или описанием поведения,
помещенным внутри прямоугольника действия со скругленными углами
(рис. 14.23.). Если имя узла отличается от имени поведения, оно вместо этого
отображается в символе.
Рис. 14.23. Действие поведения вызова для поведения Checkout
Обратите внимание, что, поскольку оно выглядит точно так же, как
обычное действие, невозможно просто посмотреть на диаграмму, чтобы
сказать, является ли имя именем общего действия, именем действия
поведения вызова или каким-либо именем поведения.
Как
известно,
некоторые
подклассы
поведения
—
это
взаимодействие, конечный автомат, активность.
Действие вызова обозначается размещением символа в стиле граблей
внутри символа действия (рис. 14.24.). Грабли напоминают миниатюрную
иерархию, указывая на то, что этот вызов запускает другое действие.
Обратите внимание, что, хотя UML предоставляет эту нотацию, в
спецификации UML нет официального действия по вызову.
372
User rh]
I Authentication I
Рис. 14.24. Действие действия вызова для действия проверки
подлинности пользователя
Альтернативное обозначение для вызванной активности состоит в том,
чтобы показать содержимое вызванной активности внутри большого
прямоугольника с закругленными углами. Ребра, входящие в вызов,
соединяются с узлами объекта параметра в вызываемом действии. Узлы
объекта параметров отображаются на границе вызванного действия.
Пред- и постусловия поведения можно показать с помощью ключевых
слов «предусловие» и «постусловие».
3.3.6. Действие «Отправить сигнал»
Действие отправки сигнала — это действие вызова, которое создает
сигнал из своих входов и передает его указанному целевому объекту, где
это может вызвать срабатывание перехода конечного автомата или
выполнение действия.
Когда
все
предпосылки
выполнения
действия выполнены,
из
аргументов формируется сигнал, который передается идентифицированному
целевому объекту. Целевой объект может быть локальным или удаленным.
Если ввод действия уже является сигналом, вместо этого следует
использовать действие отправки объекта.
Отправитель
сигнала
(он
же
«запрашивающий»)
немедленно
продолжает выполнение, не дожидаясь ответа. Действие «Отправить сигнал»
не получает ответа от вызванного поведения. Любая попытка ответить
просто игнорируется, и передача обратно отправителю не выполняется.
Способ передачи сигнала, количество времени, необходимое для его
передачи, порядок, в котором передачи достигают различных целей, и путь
373
достижения целей не определены в. Экземпляр сигнала может быть
скопирован во время передачи, поэтому идентичность может не сохраниться.
Когда передача достигает целевого объекта, она может вызывать
поведение целевого объекта. Эффект от получения объекта сигнала указан в
Common Behaviors. К таким эффектам относятся выполнение действий и
срабатывание переходов конечного автомата.
Действие
сигнала
отправки
выпуклым
обозначается
пятиугольником (рис. 14.25.). Обратите внимание, что имя действия
соответствует имени класса сигнала, который оно отправляет (рис. 14.26.).
Целевой объект не указан с этой нотацией.
Ship
Order
J
Notify
Customer
>
Рис. 14.25. Действие отправки
Рис. 14.26. После отправки заказа
сигнала «Уведомить клиента»
действие отправки сигнала
создает и отправляет сигнал
«Уведомить клиента» создает и
«Уведомить клиента».
отправляет сигнал «Уведомить
клиента ».
3.3.7. Структурное действие
Действия со структурными элементами включают в себя несколько
действий,
работающих
с
составными
структурами:
добавление, удаление, очистка и уменьшение (рис. 14.27.).
374
чтение,
запись,
Рис. 14.27. Обзорная диаграмма действий структурных элементов
Обратите внимание, что в спецификации UML 2.4
действие
сокращения является прямым подклассом действия.
3.3.8. Действие ссылки
Действия со ссылками включают в себя несколько действий,
работающих со ссылками: чтение, запись, создание, уничтожение и удаление
ассоциаций (рис. 14.28.).
375
Рис. 14.28. Обзорная диаграмма действий по ссылке
Обратите внимание, что в спецификации UML 2.4 действие чтения
объекта ссылки, действие квалификатора конца объекта ссылки, действие
очистки ассоциации являются прямыми подклассами действия.
3.3.9. Действие события
Действия по событию включают в себя действие «принять событие»,
«принять вызов», «принять событие времени», «ответить» и «отменить
сортировку» (рис. 14.29.). Обратите внимание, что действие события не
является явной частью спецификации UML. В UML 2.4 все действия события
являются прямыми подклассами действия. Авторы добавили сюда действие
события для ясности.
376
Рис. 14.29. Обзорная диаграмма действий по событию
3.3.10. Принять действие события
Действие «Принять событие» — это действие, которое ожидает
наступления
определенного
события.
Это
действие
обрабатывает
асинхронные сообщения, включая асинхронные вызовы. Его нельзя
использовать с синхронными вызовами (кроме действия accept call).
Действие принятия события было введено в UML 2.0.
Действие «Принять событие» обрабатывает события, обнаруженные
объектом,
которому
принадлежит
исполняемое
поведение.
События
сохраняются объектом в некоторой очереди. Порядок обнаруженных
событий не определяется спецификацией UML, но может быть указан в
расширениях или профилях.
Если действие принятия события выполнено и объект обнаружил
событие, соответствующее одному из триггеров действия, то действие
принятия события выводит значение, описывающее событие. Если событие
не соответствует ожидаемому событию, действие ожидает следующего
события.
377
В системе с параллелизмом несколько действий или других вариантов
поведения могут конкурировать за доступное событие. Только одно действие
принимает событие, если иное не указано в расширении или профиле, даже
если событие удовлетворяет нескольким одновременно выполняемым
действиям.
Действие
события
принятия
обозначается
вогнутым
пятиугольником (рис. 14.30.). По умолчанию имя действия события
принятия соответствует имени события, которое принимает это действие,
так что, например, действие принятия события принятия заказа ожидает
события принятия заказа.
\
)
Accept
Order
Process
Order
Рис. 14.30. Принятие события «Принять заказ» действием «Принять
заказ» вызывает вызов действия «Обработка заказа». Действие
принятия события включается при входе в действие, содержащее его
Если действие принятия события не имеет входящих ребер, то
действие начинается, когда это происходит у содержащего действия или
структурированного узла, в зависимости от того, что непосредственно
содержит действие. Кроме того, действие принятия события без входящих
ребер остается активным после принятия события. Он не завершается после
принятия события и вывода значения, а продолжает ожидать других
событий. Эта семантика является исключением из обычных правил
выполнения действий. Действие события принятия без входящих ребер,
содержащееся в структурированном узле, завершается, когда закрывается его
контейнер.
378
3.3.11. Принять действие сигнала
Действие «принять сигнал» — это неофициальное название действия
«принять событие», триггером которого является сигнальное событие. Это
соответствует действию отправки сигнала.
Действие по приему сигнала обозначается так же, как действие по
событию — в виде вогнутого пятиугольника (рис. 14.31.). По умолчанию
имя действия приема сигнала соответствует имени сигнала, которое
принимает это действие.
Payment
Requested
Рис. 14.31. Отправляется сигнал «Запрос платежа». Затем действие
ожидает получения сигнала подтверждения платежа. Прием сигнала
Payment Confirmed включается только после отправки запроса на
оплату.
3.3.12. Действие времени ожидания
Если событие является событием времени, результирующее значение
содержит
время,
когда
это
событие
произошло.
Такое
действие
неофициально называется действием времени ожидания.
Действие «Принять событие времени» (также известное как
неофициальное: действие «Время ожидания») отмечено песочными часами
(рис. 14.32.).
Every
hour
Рис. 14.32. Действие «Принять событие времени».
Действие события «Каждый час принять время» генерирует выходные
данные каждый час. Для этого действия события времени нет входящих
ребер, поэтому оно включено до тех пор, пока включено содержащее его
действие или структурированный узел.
379
3.4. Узлы объектов
3.4.1. Понятие узла объекта
Узел объекта — это абстрактный узел действия, который используется
для определения потоков объектов в действии. Узлы объекта включают
вывод, центральный буфер, параметры, узлы расширения (рис. 14.33.).
Рис. 14.33. Узлы объекта активности включают в себя параметры,
вывод, центральный буфер, узлы расширения.
Немного странно, что, хотя объектный узел является абстрактным
узлом активности, он напрямую используется в потоках объектов, используя
собственную нотацию (см. ниже). Было бы разумно иметь какой-то
отдельный конкретный метакласс UML для узлов данных.
3.4.2. Узел объекта, как абстрактный узел действия
Узел объекта — это абстрактный узел действия, который используется
для определения потока объектов в действии. Он указывает, что экземпляр
определенного классификатора, возможно, в определенном состоянии,
380
может быть доступен в определенный момент действия. Узлы объектов
можно использовать по-разному, в зависимости от того, откуда и куда
перетекают объекты.
Узлы объекта обозначены как прямоугольники. Имя, обозначающее
узел, помещается внутри символа, где имя указывает тип узла объекта или
имя и тип узла в формате «имя:тип» (рис. 14.34.).
Рис. 14.34. Поток объектов ордеров между действиями «Заполнить
ордер» и «Просмотреть ордер»
Имя также может быть уточнено состоянием или состояниями, которые
должны быть записаны в скобках под именем типа. Верхние границы,
порядок и тип управления, отличные от значений по умолчанию, указаны в
фигурных скобках под узлом объекта.
3.4.3. Пины
Пин — это объектный узел для входов и выходов действий.
Пин обычно изображается в виде маленького прямоугольника,
прикрепленного к прямоугольнику действия (рис. 14.35. и 14.36.). Имя
вывода может отображаться рядом с булавкой.
'
Create
Wee
Invoice
Рис. 14.35. Товар является
Рис. 14.36. Счет — это выходной
входным контактом для действия
пин из действия «Создать счет».
«Добавить в корзину».
381
3.4.4. Центральный буфер
Центральный буферный узел — это объектный узел для управления
потоками из нескольких источников и пунктов назначения. Центральный
буферный узел принимает токены от нескольких объектов в потоках,
буферизует их и передает в исходящие потоки. Центральные буферы не
подключаются напрямую к действиям.
Обратите внимание, что все узлы объектов имеют встроенную
возможность буферизации данных. Пины могли буферизовать данные для
действий, а параметры активности — для активности. Центральный буфер
отличается тем, что он не привязан ни к действию, ни к активности. Он
обеспечивает дополнительную поддержку очередей и конкуренции между
потоками объектов.
Центральный буфер обозначается как узел объекта с необязательным
ключевым словом «centralBuffer», которое позволяет отличить его от
автономного вывода.
3.4.5. Хранилище данных
Хранилище данных — это центральный буферный узел для
постоянной информации.
Все входящие токены сохраняются в хранилище данных. Специальное
правило заключается в том, что если входящий токен содержит какой-то
конкретный объект, который уже хранится в хранилище данных, то новый
токен заменит любые токены в узле объекта, содержащем этот объект.
Токены, которые были выбраны для выхода («перемещения вниз»)
хранилища данных, фактически копируются, в то время как исходный токен
сохраняется и не удаляется из хранилища данных.
Хранилище данных обозначается как узел объекта с ключевым словом
«хранилище данных» (рис. 14.37.).
382
Рис. 14.37. Входящий токен пациента хранится в хранилище данных
пациентов.
3.5. Элементы управления диаграммой активности UML
3.5.1. Понятие узла управления
Узел
управления
—
это
узел
действия,
используемый
для
координации потоков между другими узлами (рис. 14.38.). Это включает в
себя:
начальный узел
конечный узел потока
конечный узел действия
узел решения
узел слияния
узел вилки (разветвления)
Узел соединения
Рис. 14.38. Обзор узлов управления активностью.
Узлы управления действиями можно использовать как в диаграммах
действий, так и в диаграммах обзора взаимодействия.
383
3.5.2. Начальный узел
Начальный узел — это управляющий узел, с которого начинается
поток при вызове действия.
Маркер управления помещается в начальный узел при запуске
действия, но не в начальные узлы в структурированных узлах, содержащихся
в действии. Токены в начальном узле предлагаются всем исходящим ребрам.
Для удобства начальные узлы являются исключением из правила, согласно
которому управляющие узлы не могут удерживать токены, если их движение
вниз по течению заблокировано, например, охраной.
Действия могут иметь более одного начального узла. В этом случае
вызов действия запускает несколько потоков, по одному на каждом
начальном узле.
Обратите внимание, что потоки также могут запускаться на других
узлах, поэтому начальные узлы не требуются для начала выполнения
действия.
Начальные узлы показаны как маленький сплошной кружок (рис.
14.39.).
Рис. 14.39. Начальный узел активности.
3.5.3. Конечный узел потока
Конечный
узел
потока
—
это
конечный
узел
управления,
завершающий поток. Он уничтожает все поступающие к нему токены, но не
влияет на другие потоки активности. Окончательный поток был представлен
в UML 2.0.
Обозначение конечного узла потока представляет собой маленький
кружок с X внутри (рис. 14.40.).
384
Рис. 14.40. Конечный узел потока.
3.5.4. Конечный узел действия
Конечный узел действия — это управляющий конечный узел,
который останавливает все потоки в действии. Финал активности был
представлен в UML 2.0.
Действие может иметь более одного конечного узла действия. Первый
достигнутый останавливает все потоки в действии. Токен, достигший
конечного узла действия, завершает действие. В частности, он останавливает
все выполняемые действия в действии и уничтожает все токены в узлах
объекта,
за
исключением
выходных
узлов
параметров
действия.
Прекращение выполнения синхронных действий вызова также прекращает
любое поведение, от которого они ожидают возврата. Любое поведение,
вызываемое действием асинхронно, не затрагивается. Если нежелательно
прерывать все потоки в действии, используйте вместо этого поток final.
Конечные узлы активности показаны сплошным кругом с полым
кругом внутри (рис. 14.41.). Это можно рассматривать как цель,
обозначенную как «яблочко» или цель.
Рис. 14.41. Конечный узел действия.
3.5.5. Узел решения
Узел принятия решения — это управляющий узел, который
принимает маркеры на одном или двух входящих ребрах и выбирает одно
исходящее ребро из одного или нескольких исходящих потоков. Узлы
принятия решений были введены в UML для поддержки условий в
действиях.
385
Ребра, входящие и исходящие из узла принятия решений, кроме потока
ввода решения (если он есть), должны быть либо всеми потоками
объектов, либо всеми потоками управления.
Каждый токен, прибывающий в узел принятия решения, может пройти
только одно исходящее ребро. Токены не дублируются. Каждый токен,
предлагаемый входящим краем, предлагается исходящим ребрам.
Какое из ребер фактически пройдено, зависит от оценки охранников
на исходящих ребрах. Порядок, в котором оцениваются охранники, не
определен, т. е. мы не должны полагаться на какой-либо порядок
визуального или текстового описания.
Обозначение узла решения представляет собой символ в форме ромба
(рис. 14.42.).
Рис. 14.42. Узел решения с двумя исходящими ребрами с ограждениями.
Разработчик модели должен сделать так, чтобы каждая лексема
выбиралась только для прохождения одного исходящего ребра. Для точек
принятия решения предопределенная защита «иначе» может быть
определена не более чем для одного исходящего ребра (рис. 14.43.).
[priority—1]
[priori ty=2]
------------ >
[else]
------------
Рис. 14.43. Узел решения с тремя исходящими ребрами и защитой [else].
386
Для решения может быть указано поведение ввода решения.
Поведение ввода решений было введено в UML, чтобы избежать избыточных
пересчетов в охранниках.
В этом случае каждый токен данных передается поведению до того,
как будут оценены охранники на исходящих ребрах. Поведение вызывается
без ввода управляющих токенов. Результат поведения доступен каждому
охраннику. Поскольку это поведение используется в процессе предложения
токенов исходящим ребрам, оно может выполняться много раз на одном и
том же токене, прежде чем маркер будет принят этими ребрами. Это
означает, что поведение не может иметь побочных эффектов.
ввода
Поведение
«decisionInput»
и
решения
некоторым
определяется
поведением
ключевым
словом
или
условием,
решения
помещенным в символ примечания и прикрепленным к соответствующему
узлу решения (рис. 14.44.).
«decisioninput»
inventory < min
Рис. 14.44. Узел решения с поведением ввода решения.
Решение может также иметь входной поток решения. В этом случае
маркеры, предлагаемые во входном потоке решения, которые становятся
доступными для защиты на каждом исходящем ребре, определяют,
передается ли предложение на обычном входящем ребре вдоль этого
исходящего ребра.
Поток
ввода
решения
определяется
ключевым
«decisionInputFlow», аннотирующим этот поток (рис. 14.45.).
387
словом
Рис. 14.45. Узел решения с входным потоком решения.
Если есть как входное поведение решения, так и поток ввода
решения, токен, предлагаемый в потоке ввода решения, передается
поведению (в качестве единственного аргумента, если обычное входящее
ребро является потоком управления, в качестве второго аргумента, если это
поток ввода). поток объектов). Узлы принятия решений с дополнительным
потоком ввода решений предлагают токены исходящим ребрам только тогда,
когда один токен предлагается на каждом входящем крае.
3.5.6. Узел слияния
Узел слияния — это узел управления, который объединяет несколько
входящих альтернативных потоков для приема одного исходящего потока.
Объединения
токенов
нет.
Слияние
не
следует
использовать
для
синхронизации параллельных потоков.
Например, если решение используется после разветвления, два потока,
исходящих из решения, должны быть объединены в один перед переходом к
объединению; в противном случае соединение будет ожидать обоих потоков,
из которых прибудет только один.
Все ребра, входящие и исходящие из узла слияния, должны быть либо
потоками объектов, либо потоками управления.
Обозначение узла слияния представляет собой ромбовидный символ с
двумя или более ребрами, входящими в него, и одним выходным ребром
активности (рис. 14.46.).
388
Рис. 14.46. Узел слияния с тремя входящими ребрами и одним
исходящим ребром
Функциональность узла слияния и узла принятия решения можно
комбинировать, используя один и тот же символ узла, как показано ниже
(рис. 14.47.). Этот случай отображает модель, содержащую узел слияния со
всеми входящими ребрами, показанными на диаграмме, и одно исходящее
ребро с узлом принятия решения, у которого все исходящие ребра показаны
на диаграмме.
Рис. 14.47. Узел слияния и узел решения объединены с использованием
одного и того же символа
3.5.7. Узел разветвления
Узел разветвления — это управляющий узел, который имеет одно
входящее ребро и несколько исходящих ребер и используется для разделения
входящего потока на несколько параллельных потоков. Узлы ветвления
введены для поддержки параллелизма в действиях. По сравнению с UML
1.5
ветвления
активности
UML
2.0
моделируют
неограниченный
параллелизм.
Токены, поступающие на разветвление, дублируются на исходящих
ребрах. Если хотя бы одно исходящее ребро принимает маркер, создаются
дубликаты маркера, и одна копия проходит через каждое ребро, которое
принимает маркер. Исходящие ребра, которые не приняли токен из-за того,
389
что их цели не приняли его, хранят свою копию в неявной очереди FIFO до
тех пор, пока она не будет принята целью. Остальные исходящие ребра
маркер не получают.
Обозначение для узла разветвления представляет собой отрезок линии
с одним входным ребром активности и двумя или более выходящими
ребрами (рис. 14.48.).
Рис. 14.48. Узел разветвления с одним входным ребром активности и
тремя исходящими ребрами.
Функциональность узла соединения и узла разветвления можно
комбинировать, используя один и тот же символ узла (рис. 14.49.). Этот
случай отображает модель, содержащую узел соединения со всеми
входящими ребрами, показанными на диаграмме, и одним исходящим
ребром с узлом разветвления, у которого все исходящие ребра показаны на
диаграмме.
------ --------- >
------ >------ >
—ЦI—>
Рис. 14.49. Комбинированный узел соединения и узел разветвления.
Если на ребрах, исходящих из ответвлений, используются охранники,
разработчики моделей должны гарантировать, что ни одно нисходящее
соединение
не
зависит
от
прибытия
маркеров,
проходящих
через
защищенное ребро. Если этого нельзя избежать, то следует ввести узел
принятия решений, чтобы иметь защиту и шунтировать токен к
нисходящему соединению, если защита не работает.
390
3.5.8. Узел соединения
Узел соединения — это управляющий узел, который имеет несколько
входящих ребер и одно исходящее ребро и используется для синхронизации
входящих параллельных потоков. Узлы соединения введены для поддержки
параллелизма в действиях.
Обозначение для узла соединения представляет собой отрезок линии с
несколькими ребрами активности, входящими в него, и только одним
ребром, выходящим из него (рис. 14.50.).
Рис. 14.50. Соедините узел с тремя ребрами активности, входящими в
него, и одним ребро, выходящим из него.
Функциональность узла соединения и узла разветвления можно
комбинировать, используя один и тот же символ узла (рис. 14.51.). Этот
случай отображает модель, содержащую узел соединения со всеми
входящими ребрами, показанными на диаграмме, и одним исходящим
ребром с узлом разветвления, у которого все исходящие ребра показаны на
диаграмме.
------ --------- >
------ >----- >
------ ц----- s>
Рис. 14.51. Комбинированный узел соединения и узел разветвления.
Узлы
соединения
имеют
спецификацию
соединения,
которая
представляет собой спецификацию логического значения, использующую
имена входящих ребер для указания условий, при которых соединение
будет выдавать токен.
Спецификация соединения оценивается всякий раз, когда на любом
входящем ребре предлагается новый маркер. Оценка не прерывается
391
никакими
новыми
токенами,
предлагаемыми
во
время
оценки,
и
параллельные оценки не начинаются, когда во время оценки предлагаются
новые токены.
Спецификация соединения по умолчанию — это зарезервированная
строка " и ". Это эквивалентно спецификации, которая требует, чтобы на
каждом входящем ребре предлагался хотя бы один токен.
Спецификации соединения показаны в фигурных скобках рядом с
узлом соединения как joinSpec=... (рис. 14.52.).
Рис. 14.52. Узел соединения со спецификацией соединения, показанной в
фигурных скобках.
3.6. Ребро действия
3.6.1. Понятие ребра действия
Ребро действия — это абстрактный класс для направленных
соединений, по которым токены или объекты данных перетекают между
узлами активности. Он включает в себя ребра управления и ребра потока
объектов. Источник и цель ребра должны находиться в той же активности,
что и ребро.
Край
активности
обозначается
незамкнутой
линией
стрелки,
соединяющей два узла активности (рис. 14.53.).
Рис. 14.53. Ребро действия соединяет порядок заполнения и порядок
просмотра.
392
Ребрам можно присваивать имена, однако ребрам не обязательно иметь
уникальные имена в рамках действия. Если ребро имеет имя, оно указывается
рядом со стрелкой.
Рис. 14.54. Ребро действия «обновлено» соединяет два узла.
Край активности может иметь защиту — спецификацию, оцениваемую
во время выполнения, чтобы определить, можно ли пройти через край.
Охранник должен оцениваться как истина для каждого маркера, который
предлагается пройти по краю.
Защита края активности показана в квадратных скобках, которые
содержат защиту (рис. 14.55.).
Рис. 14.55. Заполнить заказ, когда приоритет равен 1
Край активности можно обозначить с помощью коннектора, который
представляет собой небольшой кружок с именем внутри. Хотя в
спецификации UML 2.4 это называется name of the edge, приведенная
нотация соединителя и примеры предполагают, что у соединителя есть
собственное имя (также называемое label ).
Соединители обычно используются, чтобы избежать рисования
длинного края (рис. 14.56.). Это чисто обозначение. Это не влияет на
базовую модель. Используемые круги и линии сопоставляются с одним
ребром активности в модели. Каждый коннектор с заданной меткой должен
быть связан ровно с одним другим соединителем с такой же меткой на одной
и той же диаграмме действий. У одного коннектора должно быть ровно одно
входящее ребро, а у другого ровно одно исходящее ребро, каждый с одним и
тем же типом потока, объекта или элемента управления.
393
Рис. 14.56. Соединитель A соединяет два ребра
между Fill Order и Review Order.
3.6.2. Край потока объекта
Ребра потока объектов — это ребра активности, используемые для
отображения потока данных объекта и токенов данных между узлами
действия.
Поток объекта обозначается линией со стрелкой (рис. 14.57.).
Рис. 14.57. Поток объектов ордеров между действиями «Заполнить
ордер» и «Просмотреть ордер»
По ребру может проходить любое количество жетонов, группами
одновременно или по отдельности в разное время. Атрибут веса определяет
минимальное количество токенов, которые должны пересечь ребро
одновременно. Когда предлагается минимальное количество токенов, все
токены в источнике одновременно предлагаются цели.
Вес ребра может быть показан в фигурных скобках, содержащих вес
(рис. 14.58.). Вес - это спецификация значения, которая может быть
константой, которая оценивается как ненулевое неограниченное натуральное
значение. Неограниченный вес обозначается знаком «*».
394
Рис. 14.58. Отправить уведомление, когда количество предупреждений
достигает 6.
3.6.3. Прерывание ребра
Прерывание ребра — это ребро действия, выражающее прерывание
для областей, в которых есть прерывания. Он представлен в виде молнии
(рис. 14.59.).
Рис. 14.59. Сигнал Cancel Request вызывает прерывание, приводящее к
Cancel Order.
Вариант
обозначения
прерывающегося
края
зигзагообразный
орнамент на прямой линии (рис. 14.60.).
\
Cancel
/ Request
Рис. 14.60. Сигнал Cancel Request вызывает прерывание, приводящее к
Cancel Order.
395
4. UML ДИАГРАММА СОСТОЯНИЙ
4.1. Понятие и схема UML диаграммы состояний
Диаграмма состояний (State diagram) — это один из видов диаграмм
UML, используемых в разработке программного обеспечения, чтобы
визуализировать и моделировать поведение объекта или системы в
различных состояниях. Она позволяет описать все возможные состояния
объекта, а также переходы между ними в ответ на определенные события.
Диаграмма
состояний
показывает
автомат
(state
machine),
включающий в себя состояния, переходы, события и деятельности (рис.
15.1.). Диаграммы состояний описывают динамическое представление
объекта. Они особенно важны для моделирования поведения интерфейсов,
классов или коопераций и подчеркивают событийно-зависимое поведение
объекта, что особенно удобно для моделирования реактивных систем.
Рис. 15.1. Схема диаграммы состояний
396
4.2. Начальное состояние (Start state)
Начальное состояние — это состояние, с которого начинается
выполнение процесса. Оно обозначается с помощью символа заполненного
кружка, откуда исходят стрелки, представляющие переходы в другие
состояния.
Начальное состояние указывает на точку входа в модель поведения и
определяет, с какого состояния объект или система начинает свое
выполнение или реагирует на события (рис. 15.2.). Когда диаграмма
состояний запускается, она сразу переходит из начального состояния в
другое состояние в ответ на определенное событие или действие.
Рис. 15.2. Пример отображения начального состояния на state
diagram
4.3. Конечное состояние (Final state)
Конечное состояние — это состояние, в котором процесс завершает
свое выполнение. Оно обозначается обычно с помощью символа закрытого
кружка.
Конечное состояние указывает на завершение объекта или системы и
обозначает, что дальнейшее выполнение или процесс достиг своего
завершения. При достижении конечного состояния объект или система
останавливается,
и
дальнейшие
переходы
или
события
становятся
недопустимыми.
Конечное состояние может быть одним или множественным на
диаграмме состояний (рис. 15.3.). Если на диаграмме присутствует только
одно конечное состояние, то оно указывает на окончательное завершение
объекта или системы. Если же присутствуют несколько конечных состояний,
397
это может означать возможность завершения в различных конечных
состояниях, которые могут быть достигнуты в зависимости от определенных
условий или событий.
Рис. 15.3. Обозначение конечного состояния на state diagram
4.4. Состояние (State)
Состояние в диаграмме состояний UML представляет определенное
состояние объекта или системы, которое может изменяться в ответ на
определенные события, условия или действия. Оно определяет его поведение
и свойства в определенный момент времени.
В диаграмме состояний UML состояние обычно представляется
прямоугольником с названием состояния (рис. 15.4.). Состояния могут быть
обозначены
текстовыми
функциональность.
метками,
Например,
описывающими
состояние
их
«ожидание»,
смысл
или
«активный»,
«заблокирован» и т.д.
z
>
Состояние
ч_____________ >
Рис. 15.4. Обозначение состояния на state diagram
Состояние объекта может быть долговременным или мгновенным.
Долговременное состояние означает, что объект остается в этом состоянии на
протяжении некоторого времени, пока не произойдет событие или условие,
вызывающее переход в другое состояние. Мгновенное состояние, с другой
стороны, представляет собой непродолжительный момент времени, когда
объект находится в определенном состоянии перед выполнением перехода.
398
4.5. Составное состояние (Composite state)
Составное состояние в диаграмме состояний UML представляет собой
состояние, которое содержит внутренние состояния и переходы между ними.
Оно позволяет структурировать более сложные состояния и их поведение
внутри объекта или системы.
Составное состояние обычно представляется в виде прямоугольника,
внутри которого содержатся другие состояния и переходы. Внутренние
состояния и переходы могут быть представлены как отдельные элементы
внутри составного состояния или в виде вложенных диаграмм состояний.
В составном состоянии можно определить иерархию вложенных
состояний, которая отображает различные уровни детализации поведения
объекта или системы (рис. 15.5.). Когда объект находится в составном
состоянии, его поведение может зависеть от текущего внутреннего состояния
и переходить между ними в ответ на определенные события или условия.
Рис. 15.5. Обозначение составного состояния на диаграмме
состояний
Составные состояния обычно используются для моделирования
сложных сценариев или поведения системы, где объект может находиться в
различных подсостояниях и переходить между ними в соответствии с
определенными
правилами
или
условиями.
Они
позволяют
более
структурировано и понятно представить сложные потоки выполнения и
взаимодействия объектов в системе.
399
4.6. Защитное условие (Guard Condition)
Защитное условие представляет собой логическое выражение, которое
определяет условия, при которых может произойти переход из одного
состояния в другое. Оно является частью перехода и помогает управлять
потоком выполнения между состояниями.
Защитное условие указывает на необходимость удовлетворения
определенного условия для совершения перехода. Если условие истинно
(выполняется), переход может произойти. Если условие ложно, переход
будет заблокирован, и объект или система останется в текущем состоянии.
Защитные условия могут быть выражены с помощью логических
операторов и сравнений для проверки значений переменных, флагов или
других условий, которые влияют на переходы между состояниями.
Защитные
условия
позволяют
управлять
переходами
между
состояниями на основе определенных условий, что делает модель более
гибкой и реалистичной. Они позволяют объекту принимать решения о
переходах, основываясь на текущих условиях и переменных окружения.
4.7. Разделитель (Concurrent state)
Разделитель, также известный как параллельное состояние или
состояние с одновременным выполнением, представляет состояние, в
котором объект или система может находиться одновременно в нескольких
взаимодействующих состояниях. Это позволяет моделировать параллельное
выполнение или конкурентные аспекты поведения объекта или системы.
Разделитель представляется горизонтальной линией, пересекающей
состояния и переходы. Он указывает, что объект может находиться в
различных
состояниях
одновременно
и
выполнять
соответствующие
действия параллельно.
Состояния, расположенные выше и ниже разделителя, являются
параллельными и могут выполняться независимо друг от друга. Переходы,
400
связанные с
каждым параллельным
состоянием,
могут
срабатывать
независимо в зависимости от условий или событий.
Разделитель часто используется для моделирования параллельных
процессов или параллельных потоков выполнения в системе. Он позволяет
представить ситуации, когда объект выполняет несколько действий
одновременно или, когда в системе происходит взаимодействие между
различными компонентами, выполняющими разные задачи одновременно.
4.8. Историческое состояние (Historical State)
Историческое состояние представляет специальное состояние, которое
сохраняет информацию о предыдущем состоянии объекта или системы. Оно
используется для моделирования возврата к предыдущему состоянию или
сохранения контекста состояния.
В диаграмме состояний историческое состояние обычно обозначается
символом «H» внутри состояния. История может иметь входящие и
исходящие переходы, позволяющие объекту или системе восстановить
предыдущее состояние или перейти к новому состоянию в зависимости от
контекста.
Историческое состояние сохраняет только само состояние, без
сохранения информации о подсостояниях (рис. 15.6.). При переходе через
такое состояние объект возвращается к предыдущему состоянию без
восстановления его внутренних состояний.
Рис. 15.6. Обозначение исторического состояния на диаграмме
состояний
Использование истории состояний позволяет объекту возвращаться к
предыдущему состоянию и продолжать выполнение соответствующего
401
поведения. Это полезно в ситуациях, когда после выполнения определенного
действия или события объект должен вернуться к состоянию, которое он
находил ранее и продолжая выполнение с того места, где был оставлен.
4.9. Глубокое историческое состояние (Deep Historical State)
Глубокое историческое состояние является особой формой истории
состояний, которая сохраняет информацию о предыдущем состоянии объекта
и всех его внутренних состояниях (рис. 15.7.). Оно обозначается символом
«H*» внутри состояния. Оно имеет входящие и исходящие переходы,
позволяющие объекту восстановить предыдущее состояние со всеми
вложенными состояниями.
Рис. 15.7. Обозначение глубокого исторического состояния на
диаграмме состояний
Использование глубокой историй полезно в ситуациях, когда объект
имеет сложную структуру состояний с вложенными подсостояниями. При
переходе через глубокую историю объект возвращается в предыдущее
состояние вместе с его подсостояниями.
4.10. Переход (Transition)
Переход — это элемент диаграммы состояний, который представляет
собой переход объекта из одного состояния в другое. Он определяет событие
или условие, которое вызывает изменение состояния, и указывает, какой
переход должен быть выполнен при наступлении этого события или условия.
Переходы обычно представляются стрелками, которые соединяют
состояния в диаграмме состояний. Они могут иметь метку, которая указывает
событие или условие, при котором переход может быть выполнен.
402
Переходы могут быть направленными или ненаправленными (рис.
15.8.).
Направленный
переход
указывает
однонаправленный
поток
выполнения от одного состояния к другому. Ненаправленный переход
представляет переход, который может быть выполнен в обоих направлениях
между состояниями.
--------------------------------------- >
Рис. 15.8. Обозначение перехода на диаграмме состояний
При наступлении события или удовлетворении условия, связанного с
переходом, объект или система переходит из текущего состояния в целевое
состояние, которое указано на конце перехода. В результате выполнения
перехода могут быть выполнены действия или изменения внутреннего
состояния объекта.
Переходы позволяют моделировать потоки выполнения и изменения
состояний объекта, отражая его поведение и реакцию на события или
условия. Они помогают создать более детализированную и понятную модель
объекта или системы в рамках диаграммы состояний.
403
5. UML ДИАГРАММЫ КОНЕЧНОГО АВТОМАТА
5.1. Понятие и схема UML диаграммы конечного автомата
Диаграмма конечного автомата — это диаграмма поведения,
которая показывает дискретное поведение части проектируемой системы
через конечные переходы состояний. Диаграммы конечного автомата также
могут использоваться для выражения протокола использования части
системы. В UML 2.4 определены два вида конечных автоматов:
•
поведенческий конечный автомат и
•
автомат состояния протокола.
На диаграмме конечного автомата обычно рисуются следующие
узлы и ребра: поведенческое состояние, поведенческий переход, состояние
протокола, переход протокола, различные псевдосостояния.
В разделе четыре данной монографии вы сможете найти некоторые
примеры диаграмм конечного автомата.
5.2. Поведенческий конечный автомат
5.2.1. Понятие поведенческого конечного автомата
Поведенческий
конечный
автомат
является
специализацией
поведения и используется для указания дискретного поведения части
проектируемой системы посредством конечных переходов состояний.
Используемый в данном случае формализм конечного автомата представляет
собой объектно-ориентированный вариант диаграмм состояний Харела.
Поведение моделируется как обход графа узлов состояний, связанных
с переходами. Переходы запускаются при отправке серии событий. Во время
обхода конечный автомат также может выполнять некоторые действия.
Поведенческий
конечный
автомат
может
принадлежать
поведенческому классификатору, который называется его контекстом.
Контекст определяет, какие триггеры сигналов и вызовов определены для
404
этого конечного автомата и какие атрибуты, и операции доступны в
действиях конечного автомата. Триггеры сигналов и триггеры вызовов для
конечного автомата определяются в соответствии с приемами и операциями
этого классификатора.
Конечный автомат может иметь ассоциированный поведенческий
признак (спецификацию) и быть методом этого поведенческого признака. В
этом случае конечный автомат определяет поведение этой поведенческой
функции. Параметры конечного автомата соответствуют параметрам
поведенческого признака и предоставляют средства для доступа к
параметрам поведенческого признака в конечном автомате.
Пул событий для конечного автомата — это пул событий экземпляра в
соответствии
с
классификатором
поведенческого
контекста
или
классификатором, владеющим поведенческой функцией, для которой
конечный автомат является методом.
Классификатор контекста конечного автомата метода поведенческой
функции
должен
быть
классификатором,
которому
принадлежит
поведенческая функция. Конечный автомат без классификатора контекста
может использовать триггеры, которые не зависят от приемов или операций
классификатора, т. е. либо просто триггеры сигналов, либо триггеры вызова
на основе параметров шаблона операции (параметризованного) конечного
автомата.
Связь между конечным автоматом и его классификатором контекста
или поведенческой характеристикой не имеет специального обозначения.
Конечный автомат может быть представлен в кадре, обозначенном как
конечный автомат или сокращенно stm (рис. 16.1.). (Обратите внимание,
что по какой-то причине во всех примерах фреймов конечного автомата в
спецификации UML 2.4 этот тип фрейма не указан.) Область содержимого
405
фрейма обычно является самим конечным автоматом, но в целом она может
содержать другие виды UML диаграмм.
Рис. 16.1. Поведенческий конечный автомат высокого уровня для
банковского банкомата.
Поведенческий
автомат
конечный
является
подклассом
протокольного конечного автомата.
5.2.2. Вершина
Вершина — это именованный элемент, который является абстракцией
узла в графе конечного автомата. В общем, это может быть источник или
пункт назначения любого количества переходов.
Подклассы вершины:
•
состояние
•
псевдосостояние
Состояние — это вершина, моделирующая ситуацию, в которой
выполняется некоторое (обычно неявное) инвариантное условие.
5.2.3. Поведенческое состояние
Состояние в поведенческих автоматах моделирует ситуацию, во
время которой выполняется некоторое (обычно неявное) инвариантное
условие. Инвариант может представлять статическую ситуацию, такую как
406
объект, ожидающий возникновения некоторого внешнего события. Однако
он также может моделировать динамические условия, такие как процесс
выполнения некоторого поведения (т. е. рассматриваемый элемент модели
входит в состояние, когда поведение начинается, и выходит из него, как
только поведение завершается).
Унаследованные состояния изображаются пунктирными линиями или
линиями, окрашенными в серый цвет.
UML определяет следующие виды состояний:
•
простое состояние,
•
сложное состояние,
•
субмашинное состояние.
Простое состояние.
Простое состояние — это состояние, не имеющее подсостояний — у
него нет регионов и нет субмашинных состояний.
Простое
состояние
отображается
в
виде
прямоугольника
со
скругленными углами и именем состояния внутри прямоугольника (рис.
16.2.).
7
\
Waiting for
User Input
к_______
/
Рис. 16.2. Простое состояние Ожидание ввода от клиента.
При желании состояние может иметь имя штата, помещенное на
вкладку прикрепленного
прямоугольник,
обычно
имени. Вкладка имени представляет собой
расположенный
состояния.
407
снаружи
верхней
стороны
Простое состояние может иметь отсеки. Отсеками государства
являются:
•
именной отсек
•
отделение внутренней деятельности
•
отсек внутренних переходов
Отсек имени содержит (необязательное) имя состояния в виде строки.
Состояния без имен называются анонимными состояниями, и все они
считаются отдельными (разными) состояниями. Разделы имени не следует
использовать,
если
используется
вкладка
имени,
и
наоборот.
Не
рекомендуется использовать состояние с одним и тем же именем несколько
раз на одной и той же диаграмме.
Раздел
«Внутренние
действия»
содержит
список
внутренних
действий или действий состояния (выполнения), которые выполняются, пока
элемент находится в состоянии. Метка действия определяет обстоятельства,
при которых будет вызываться поведение, заданное выражением действия.
Выражение поведения может использовать любые атрибуты и концы
ассоциаций, которые находятся в области действия объекта-владельца. Для
элементов
списка, где
выражение пусто, разделитель
косой черты
необязателен.
Некоторые метки зарезервированы для специальных целей и не могут
использоваться в качестве имен событий. Ниже на рисунке 16.3. приведены
зарезервированные метки действий:
•
вход (поведение, выполняемое при входе в состояние)
•
do (постоянное поведение, выполняемое до тех пор, пока элемент
находится в состоянии)
•
выход (поведение, выполняемое при выходе из состояния)
408
f
Waiting for 'X
User Input
entry/ welcome
^exit/ thanks_____
Рис. 16.3. Простое состояние «Ожидание ввода данных от клиента» с
разделами «Имя» и «Внутренние действия».
Отделение внутренних переходов содержит список внутренних
переходов, где каждый элемент имеет форму, аналогичную описанной для
триггера. Каждое имя события может появляться более одного раза для
каждого состояния, если условия защиты различны. Параметры события и
условия защиты являются необязательными. Если у события есть параметры,
их можно использовать в выражении через текущую переменную события.
Составное состояние
Как правило, составное состояние определяется как состояние,
имеющее подсостояния (вложенные состояния). Подсостояния могут быть
последовательными
(непересекающимися)
или
параллельными
(ортогональными). UML 2.4 определяет составное состояние как состояние,
содержащее одну или несколько областей. (Обратите внимание, что этот
регион определяется как ортогональная часть либо составного состояния,
либо конечного автомата.) Состояние не может иметь одновременно регионы
и субмашину.
Простое составное состояние содержит только одну область (рис.
16.4.).
409
Рис. 16.4. Простое составное состояние Serving Customer имеет два
подсостояния.
Ортогональное составное состояние имеет более одной области.
Каждая область имеет набор взаимоисключающих непересекающихся
подвершин и набор переходов. Данное состояние может быть разложено
только одним из этих двух способов.
Любое состояние, заключенное в область составного состояния,
называется подсостоянием этого составного состояния. Оно называется
прямым подсостоянием, если оно не содержится ни в каком другом
состоянии; в противном случае оно называется косвенным подсостоянием.
Каждая область составного состояния может иметь начальное
псевдосостояние и конечное состояние. Переход в объемлющее состояние
представляет собой переход в начальное псевдосостояние в каждой области.
Вновь созданный объект использует самые верхние переходы по умолчанию,
происходящие из самых верхних начальных псевдосостояний каждой
области.
Составное состояние может иметь имя состояния, помещенное внутри
прикрепленной
вкладки
имени.
прямоугольник,
обычно
расположенный
Вкладка имени представляет
снаружи
верхней
собой
стороны
состояния.
Составное состояние может иметь отсеки. Отсеками государства
являются:
•
именной отсек
410
отделение внутренней деятельности
•
отсек внутренних переходов
•
отсек разложения
Первые три отсека такие же, как и для простого состояния.
Раздел
декомпозиции
показывает
композиционную
структуру
состояния в виде вложенной диаграммы с областями, состояниями и
переходами. Для удобства и внешнего вида текстовые ячейки могут быть
сжаты по горизонтали в пределах графической области.
В некоторых случаях удобно скрыть разложение составного состояния.
Например, внутри составного состояния может быть вложено большое
количество состояний, и они могут просто не уместиться в графическом
пространстве, доступном для диаграммы. В этом случае составное состояние
может быть представлено простым графическим изображением состояния со
специальным «составным» значком, обычно в правом нижнем углу (рис.
16.5.). Этот значок, состоящий из двух горизонтально расположенных и
соединенных состояний, является необязательным визуальным признаком
того, что состояние имеет декомпозицию, не показанную на этой конкретной
диаграмме. Вместо этого содержимое составного состояния показано на
отдельной диаграмме. «Скрытие» является вопросом графического удобства
и не имеет семантического значения с точки зрения ограничений доступа.
Serving
Customer
Рис. 16.5. Составное состояние Serving Customer со скрытой
декомпозицией.
411
Составное государство может иметь одну или несколько точек входа и
выхода на своей внешней границе или в непосредственной близости от этой
границы (внутри или снаружи).
Состояние субмашины
Состояние субмашины определяет вставку спецификации конечной
машины субмашины. Конечный автомат, который содержит состояние
подмашины, называется содержащим конечным автоматом. Один и тот же
конечный автомат может быть подмашиной более одного раза в контексте
одного содержащего его конечного автомата.
Субмашинное состояние семантически эквивалентно
составному
состоянию. Области конечного автомата-субмашины — это области
составного состояния. Действия входа, выхода и поведения, а также
внутренние переходы определяются как часть состояния. Состояние
субмашины — это механизм декомпозиции, который позволяет учитывать
общие поведения и их повторное использование.
Отсек имени содержит (необязательное) имя состояния в виде строки.
Имя конечного автомата, на который ссылаются, отображается в виде строки,
следующей за ':' после имени состояния.
5.2.4. Область
Область определяется в UML 2.4 как ортогональная часть либо
составного
состояния,
либо
конечного
автомата. Регион содержит
состояния и переходы.
Составное состояние или конечный автомат с областями показан путем
мозаичного покрытия области графа конечного автомата пунктирными
линиями, чтобы разделить его на области. Каждая область может иметь
произвольное имя и содержать вложенные непересекающиеся состояния и
переходы между ними. Текстовые части всего состояния отделены от
ортогональных областей сплошной линией.
412
Составной конечный автомат или конечный автомат только с одной
областью показан путем отображения вложенной диаграммы состояний в
области графа.
Чтобы указать, что унаследованный регион является расширенным,
ключевое слово «расширенный» связано с названием региона.
5.2.5. Псевдосостояние
Псевдосостояние — это абстрактная вершина, которая охватывает
различные типы переходных вершин в графе конечного автомата.
Псевдосостояния обычно используются для соединения нескольких
переходов в более сложные пути переходов состояний. Например,
комбинируя переход, входящий в псевдосостояние вилки, с набором
переходов, выходящих из псевдосостояния вилки, мы получаем составной
переход, который приводит к набору ортогональных целевых состояний.
Псевдостаты включают:
•
начальное псевдосостояние
•
завершать псевдосостояние
•
входная точка
•
точка выхода
•
выбор
•
присоединиться
•
вилка
•
перекресток
•
поверхностное псевдосостояние истории
•
псевдогосударство глубокой истории
Исходное псевдосостояние
413
Начальное псевдосостояние представляет вершину по умолчанию ,
которая является источником для одиночного перехода к состоянию по
умолчанию составного состояния. В области может быть не более одной
начальной вершины. Исходящий переход из начальной вершины может
иметь поведение, но не триггер или защиту.
Исходное псевдосостояние показано в виде маленького сплошного
закрашенного кружка (рис. 16.6.).
Waiting for
User Input
Рис. 16.6. Начальное псевдосостояние переходит в состояние ожидания
ввода пользователем
В области конечного автомата поведения классификатора переход из
начального псевдосостояния может быть помечен триггерным событием,
которое создает объект; в противном случае он не должен быть помечен.
Если он не помечен, он представляет собой любой переход из объемлющего
состояния.
Завершить псевдосостояние
Псевдосостояние завершения подразумевает, что выполнение этого
конечного автомата посредством его объекта контекста прекращено.
Конечный автомат не выходит из каких-либо состояний и не выполняет
никаких действий выхода, кроме тех, которые связаны с переходом, ведущим
к псевдосостоянию завершения. Вход в псевдосостояние завершения
эквивалентен вызову действия DestroyObjectAction.
Псевдосостояние завершения показано крестиком (рис. 16.7.).
Рис. 16.7. Переход к завершению псевдосостояния
414
Входная точка
Псевдосостояние точки входа — это точка входа конечного автомата
или составного состояния. В каждой области конечного автомата или
составного состояния он имеет не более одного перехода к вершине в той же
области.
Точка входа показана в виде маленького кружка на границе диаграммы
конечного автомата или составного состояния со связанным с ней именем
(рис. 16.8.).
Рис. 16.8. Точка входа пользователя
Опционально он может быть размещен как внутри диаграммы
конечного автомата, так и за границей диаграммы конечного автомата или
составного состояния.
Точка выхода
Псевдосостояние точки выхода — это точка выхода конечного
автомата или составного состояния. Вход в точку выхода в любой области
составного состояния или конечного автомата, на который ссылается
состояние подмашины, подразумевает выход из этого составного состояния
или состояния подмашины и инициирование перехода, который имеет эту
точку выхода в качестве источника в конечном автомате, охватывающем
подмашину или составное состояние.
415
Точка выхода показана в виде маленького кружка с крестом на границе
диаграммы конечного автомата или составного состояния с именем,
связанным с ним (рис. 16.9.).
Рис. 16.9. Точка выхода пользователя
Опционально он может быть размещен как внутри диаграммы
конечного автомата или составного состояния, так и за границей диаграммы
конечного автомата или составного состояния.
В
качестве
альтернативы,
нотация
«скобка»
также
может
использоваться для нотации, ориентированной на переход.
Выбор
Псевдосостояние выбора реализует динамическую условную ветвь.
Он оценивает защиту триггеров своих исходящих переходов, чтобы выбрать
только один исходящий переход. Решение о том, какой путь выбрать, может
зависеть от результатов предыдущих действий, выполненных на одном и том
же этапе выполнения до завершения. Динамический выбор следует отличать
от статических узловых точек ветвления.
Псевдосостояние выбора показано ромбовидным символом (рис.
16.10.).
416
Рис. 16.10. Выберите исходящий переход в зависимости от условия.
Если более чем один из охранников оценивается как true, выбирается
произвольный. Если ни один из охранников не оценивается как истинный, то
модель считается неправильно сформированной. Чтобы избежать этого,
определите один исходящий переход с предопределенной защитой «else»,
когда это необходимо.
Если все средства защиты, связанные с триггерами переходов,
выходящих из псевдосостояния выбора, представляют собой двоичные
выражения с общим левым операндом, можно использовать упрощенную
запись. Левый операнд помещается внутри ромбовидного символа, а
остальные защитные выражения размещаются на исходящих переходах (рис.
16.11.).
Рис. 16.11. Выбор основан на защите, применяемой к значению
внутри ромба.
Вилка
Вершины псевдосостояния разветвления служат для разделения
входящего перехода на два или более переходов, заканчивающихся на
ортогональных целевых вершинах (т. е. вершинах в разных областях
417
составного состояния). Отрезки, выходящие из вершины разветвления, не
должны иметь ограждений и триггеров.
Обозначение вилки - короткая тяжелая полоса (рис. 16.12.). Панель
может иметь одну или несколько стрелок от панели к состояниям. Рядом с
полосой может отображаться строка перехода.
Рис. 16.12. Вилка разделяет переход на два перехода
Присоединиться
Псевдосостояние
соединения
объединяет
несколько
переходов,
происходящих из исходных вершин в разных ортогональных областях.
Переходы, входящие в вершину соединения, не могут иметь защиты или
триггеры.
Обозначение соединения — короткая жирная черта. (рис. 16.13.)
Панель может иметь одну или несколько стрелок от исходных состояний к
панели. Рядом с полосой может отображаться строка перехода.
Рис. 16.13. Соединение объединяет переходы в один переход
Соединение
Вершины псевдосостояния соединения — это вершины, которые
используются для объединения нескольких переходов в цепочку. Они
используются для построения составных путей перехода между состояниями.
Например, соединение можно использовать для объединения нескольких
418
входящих переходов в один исходящий переход, представляющий общий
путь перехода (это называется слиянием).
И наоборот, их можно использовать для разделения входящего
перехода на несколько исходящих сегментов перехода с разными условиями
защиты. Это реализует статическую условную ветвь. (В последнем случае
исходящие переходы, чьи защитные условия оцениваются как ложные,
отключаются).
Предопределенная защита, обозначенная "else", может быть определена
не более чем для одного исходящего перехода. (Этот переход разрешен, если
все охранники, помечающие другие переходы, ложны.) Статические
условные переходы отличаются от динамических условных переходов,
реализуемых вершинами выбора.
Соединение представлено маленьким черным кружком.
Множественные переходы без триггеров и эффектов, возникающие в
наборе состояний и нацеленные на вершину соединения с одним исходящим
переходом, могут быть представлены в виде символа состояния со списком
имен состояний и символом исходящего перехода, соответствующим
исходящему переходу из перекрестка.
Частный случай перехода от перекрестка, имеющего историю в
качестве
цели,
может
быть
дополнительно
представлен
как
цель,
представляющая собой символ состояния в списке состояний.
Неглубокая история псевдосостояния
Псевдосостояние мелкой истории представляет самое последнее
активное подсостояние содержащего его состояния (но не подсостояния
этого подсостояния). Составное состояние может иметь не более одной
неглубокой вершины истории. Переход в неглубокую вершину истории
эквивалентен переходу в самое последнее активное подсостояние состояния.
Максимум один переход может происходить из соединителя истории в
419
состояние неглубокой истории по умолчанию. Этот переход осуществляется
в том случае, если составное состояние никогда ранее не было активным.
Выполняется
входное
действие
состояния,
представленного
мелкой
историей.
Неглубокая история обозначается маленьким кружком с буквой «H».
Это относится к государственному региону, который непосредственно его
окружает.
Псевдосостояние глубокой истории
Псевдосостояние глубокой истории представляет собой самую
последнюю
активную
конфигурацию
составного
состояния,
которая
непосредственно содержит это псевдосостояние (например, конфигурация
состояния, которая была активной при последнем выходе из составного
состояния). Составное состояние может иметь не более одной вершины
глубокой истории. Максимум один переход может происходить из
соединителя истории в состояние глубокой истории по умолчанию. Этот
переход осуществляется в том случае, если составное состояние никогда
ранее не было активным. Выполняются входные действия состояний,
введенных на неявном прямом пути от глубокой истории к самому
внутреннему состоянию (состояниям), представленному глубокой историей.
Действие входа выполняется только один раз для каждого состояния в
восстанавливаемой конфигурации активного состояния.
Глубокая история обозначена маленьким кружком с буквой «H*». Это
относится к государственному региону, который непосредственно его
окружает.
5.2.6. Конечное состояние
Конечное состояние — это особый вид состояния, означающий, что
окружающая область завершена. Если объемлющая область непосредственно
содержится в конечном автомате, а все остальные регионы в конечном
420
автомате также завершены, то это означает, что весь конечный автомат
завершен. Обратите внимание, что по какой-то причине UML 2.4 определяет
конечное состояние как подкласс состояния, а не как псевдосостояние
(Исходное состояние является псевдосостоянием).
Конечное состояние показано в виде круга, окружающего небольшой
закрашенный кружок (рис. 16.14.).
Рис. 16.14. Переход в конечное состояние.
4.2.7. Поведенческий переход
Переход — это направленная связь между исходной вершиной и
целевой вершиной. Это может быть частью составного перехода, который
переводит конечный автомат из одной конфигурации состояния в другую,
представляя полный ответ конечного автомата на возникновение события
определенного типа.
Нотация по умолчанию для поведенческого перехода описывается
следующей BNF (слегка измененная и исправленная версия BNF из
спецификаций UML 2.4):
transition ::= [ triggers ] [ guard ] [ '/' behavior-expression ]
triggers ::= trigger [ ',' trigger ]*
guard ::= '[' constraint ']'
Необязательный список триггеров определяет события, которые
могут вызвать переход состояния. Событие удовлетворяет триггеру, если
оно соответствует событию, связанному с триггером. Поскольку одно и то же
событие может активировать более одного перехода, это необходимое, но
недостаточное условие для срабатывания перехода.
Guard -constraint — это логическое выражение, записанное в терминах
параметров инициирующего события и атрибутов и ссылок объекта
421
контекста. Защитное ограничение может также включать проверки
ортогональных
состояний
текущего
конечного
автомата
или
явно
обозначенных состояний некоторого достижимого объекта (например, «в
активном состоянии»).
В простом переходе с защитой защита оценивается до запуска
перехода. В составных переходах, включающих несколько охранников, все
охранники оцениваются до запуска перехода, если только на одном или
нескольких путях нет точек выбора. Порядок, в котором оцениваются
охранники, не определен. Охранники не должны включать выражения,
вызывающие побочные эффекты.
Выражение поведения выполняется, если и когда срабатывает переход.
Он может быть записан в терминах операций, атрибутов и ссылок объекта
контекста и параметров инициирующего события или любых других
функций, видимых в его области. Выражением поведения может быть
последовательность действий.
Пример перехода с защитным ограничением и строкой перехода:
левая-мышь-вниз(координаты)
[координаты
в
активном_окне]
/
ссылка:=выбрать-ссылка(координатъ1);1тк.1'о11о\уО
Когда происходит событие нажатия левой кнопки мыши ( триггер ) и
координаты клика находятся в активном_окне ( guard ), ссылка будет
выбрана и перейдена ( поведенческое-выражение ), а переход сработает.
Триггеры и последующий эффект перехода могут быть обозначены
либо текстом в соответствии с приведенным выше синтаксисом, либо с
использованием графических символов перехода.
Переходы, возникающие
переходами высокого уровня
из составных состояний,
или
называются
групповыми переходами.
При
срабатывании они приводят к выходу из всех подсостояний составного
422
состояния, выполняя свои действия по выходу, начиная с самых внутренних
состояний в конфигурации активного состояния.
Составной переход представляет собой «семантически завершенный»
путь, состоящий из одного или нескольких переходов, исходящий из набора
состояний (в отличие от псевдосостояния) и нацеленный на набор состояний.
Внутренний переход выполняется без выхода или повторного входа в
состояние, в котором он определен. Это верно, даже если конечный автомат
находится во вложенном состоянии внутри этого состояния.
Переход завершения — это переход, происходящий из состояния или
точки выхода, но не имеющий явного триггера, хотя для него может быть
определена защита. Переход завершения неявно инициируется событием
завершения.
5.3. UML диаграмма конечного автомата протокола
Диаграммы конечного автомата протокола UML используются для
выражения протокола использования или жизненного цикла некоторого
классификатора. Он показывает, какие операции классификатора могут
быть вызваны в каждом состоянии классификатора, при каких конкретных
условиях и выполнении некоторых необязательных постусловий после
перехода классификатора в целевое состояние.
Поскольку эти диаграммы показывают жизненный цикл, они полезны
для отображения различных стабильных состояний класса объектов, которые
могут существовать в течение некоторого времени, и для объяснения того,
как объекты могут изменять свое состояние с течением времени. Например,
мы можем показать, как можно создать, активировать, приостановить и
отменить учетную запись пользователя.
Основными элементами диаграммы конечного автомата протокола
являются
состояние
протокола,
переход
протокола
и
различные
псевдосостояния, как показано на обзорной диаграмме ниже (рис. 16.15.).
423
Рис. 16.15. Обзор схемы UML диаграммы конечного автомата протокола
5.4. Машина состояния протокола
Конечный
автомат
протокола
является
специализацией
поведенческого конечного автомата и используется для выражения
протокола использования или жизненного цикла классификатора. Он
указывает, какие операции классификатора можно вызывать в каком
состоянии и при каких условиях, таким образом, определяя разрешенные
последовательности вызовов операций классификатора. Конечные автоматы
протокола выражают допустимые переходы, которые может вызвать
классификатор.
424
Конечный автомат протокола всегда определяется в контексте
классификатора. Классификатор может иметь несколько конечных автоматов
протокола.
Все переходы конечного автомата протокола должны быть переходами
протокола.
Обозначение конечного автомата протокола похоже на обозначение
поведенческого
конечного
автомата
(рис.
16.16.).
Ключевое
слово
{протокол} помещено рядом с именем конечного автомата, чтобы различать
диаграммы конечного автомата протокола.
Рис. 16.16. Конечный автомат протокола для класса URLConnection
5.5. Состояние протокола
Состояния конечного автомата протокола (состояния протокола)
представляют внешнее представление класса, которое доступно его
клиентам. В зависимости от контекста состояния протокола могут
соответствовать
внутренним
состояниям
экземпляров,
выраженным
поведенческими конечными автоматами, или они могут быть разными.
Состояния конечных автоматов протоколов доступны пользователям
их классификаторов контекста. Состояние протокола представляет открытую
стабильную ситуацию его классификатора контекста: когда экземпляр
425
классификатора не обрабатывает какую-либо операцию, пользователи этого
экземпляра всегда могут знать конфигурацию его состояния (рис. 16.17.).
f Running
: 'I
Рис. 16.17. Состояние простого протокола Running.
Состояния конечного автомата протокола не могут иметь действия
входа, выхода или действия. Машины состояний протокола также не могут
иметь псевдосостояния глубокой или поверхностной истории.
Конечные автоматы протокола могут иметь состояния подмашины,
составные состояния и параллельные области (рис. 16.18.).
Рис. 16.18. Состояние простого составного протокола Runnable.
Например, параллельные регионы позволяют выразить протокол, в
котором
экземпляр
может
иметь
несколько
активных
состояний
одновременно. Машины подсостояний и составные переходы используются,
как и в поведенческих машинах состояний, для фактеризации сложных
машин состояний протокола.
5.6. Переход протокола
Переход протокола — это специализация (поведенческого) перехода,
используемая для конечных автоматов протокола, которая указывает
426
допустимый переход для операции. Переход протокола имеет следующие
особенности: предусловие (охрана), триггер и постусловие.
Переход
протокола
обычно
связан
с
некоторой
операцией,
принадлежащей классификатору контекста конечного автомата протокола.
Переход протокола указывает, что связанная (упомянутая) операция может
быть вызвана для экземпляра в исходном состоянии в соответствии с
начальным условием (защита), и что в конце перехода состояние назначения
будет достигнуто с выполнением постусловия.
Составные переходы также могут использоваться для конечных
автоматов протокола.
Переход протокола отображается в виде стрелки перехода от исходной
вершины к целевой вершине с необязательным текстом, описывающим
переход (рис. 16.19.).
Рис. 16.19. Переход протокола из состояния New в состояние Active
с предусловием (защитой), триггером и постусловием.
Текстовая нотация для перехода протокола описывается следующими
правилами синтаксиса (обратите внимание, что в спецификации UML 2.5 нет
правил синтаксиса для перехода протокола, поэтому я их придумал):
protocol-transition ::= [ pre-condition ] trigger '/' [ post-condition ]
pre-condition ::= '[' constraint ']'
post-condition ::= '[' constraint ']'
Обратите внимание, что, хотя спецификация UML 2.5 говорит, что
«применяется обычная нотация StateMachine» , это довольно шутливое
427
заявление, поскольку синтаксис перехода протокола (показан выше) сильно
отличается от синтаксиса поведенческого перехода.
Защита
поведенческих
переходов
для
переходов
протокола
называется предварительным условием и помещается перед триггером.
Постусловие было добавлено к переходам протокола и появляется после
триггера. Переходы протокола не имеют выражения поведения. Неясно,
является ли триггер необязательным для переходов протокола, как и для
поведенческих переходов. И синтаксис перехода протокола, и примеры
показывают «/» после триггера, что отличается от поведенческих переходов,
где «/» — это токен, помещенный перед выражением поведения. Все
остальное - "обычная нотация StateMachine".
5.7. Триггер
Триггер — это именованный элемент, который используется для
связи определенного события с поведением , которое может повлиять на
экземпляр классификатора .
События могут вызвать выполнение поведения (например, выполнение
действия эффекта перехода в конечном автомате). Триггер определяет
событие, которое может инициировать выполнение поведения. Каждый
триггер связан ровно с одним событием.
Триггер обозначается как безымянное событие, с которым он связан.
Детали синтаксиса для события определяются различными подклассами
события:
trigger ::= call-event | signal-event | any-receive-event | time-event | change-event
428
6. UML ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ
Диаграммы взаимодействия включают несколько различных типов
диаграмм:
•
диаграммы последовательности,
•
диаграммы связи (известные как диаграммы сотрудничества в UML
1.x),
•
временные диаграммы,
•
схемы взаимодействия.
6.1. UML диаграмма последовательности
6.1.1. Понятие UML диаграммы последовательности
Диаграмма последовательности является наиболее распространенным
типом диаграммы взаимодействия, которая фокусируется на обмене
сообщениями между несколькими линиями жизни.
Диаграмма
последовательности
описывает
взаимодействие,
фокусируясь на последовательности сообщений, которыми обмениваются, а
также на соответствующих спецификациях их появления на линиях жизни.
На диаграмме последовательности UML обычно рисуются следующие
узлы и ребра: линия жизни, спецификация выполнения, сообщение,
комбинированный фрагмент, использование взаимодействия, инвариант
состояния, продолжение, возникновение разрушения.
Основные элементы диаграммы последовательности показаны ниже на
рисунке 5.1.
429
Рис. 17.1. Основные элементы UML диаграммы последовательности.
Вы
можете
найти
несколько
примеров
диаграмм
последовательности здесь:
•
Книжный интернет-магазин
•
Отправляйте комментарии к Pluck, используя DWR, AJAX, JSON
•
Аутентификация пользователя Facebook в веб-приложении
•
Управление транзакциями Spring и Hibernate
5.1.2. Линия жизни
Линия жизни — это именованный элемент, представляющий
отдельного участника взаимодействия. В то время как кратность частей и
структурных элементов может быть больше 1, линии жизни представляют
собой только один взаимодействующий объект.
430
Если указанный соединяемый элемент является многозначным (т. е.
имеет кратность > 1), то линия жизни может иметь выражение ( селектор ),
указывающее, какая конкретная часть представлена этой линией жизни. Если
селектор опущен, это означает, что выбран произвольный представитель
многозначного соединительного элемента.
Линия
жизни
показана
образующего
прямоугольника,
помощью
с
его
символа,
«голову»,
за
состоящего
которым
из
следует
вертикальная линия (которая может быть пунктирной), обозначающая
продолжительность жизни участника.
Информация, идентифицирующая линию жизни, отображается внутри
прямоугольника в следующем формате (немного измененном по сравнению
со стандартом UML 2.4):
lifeline-ident ::= [ connectable-element-name [ '[' selector ']' ]] [ ':' class-name ] [
decomposition ] | 'self'
selector ::= expression
decomposition ::= 'ref' interaction-ident [ 'strict' ]
где class-name — это тип, на который ссылается представленный
соединяемый элемент. Обратите внимание, что, хотя синтаксис позволяет это
сделать, lifeline-ident не может быть пустым.
Головка линии жизни имеет форму, основанную на классификаторе
той части, которую представляет эта линия жизни (рис. 17.2. - 17.4.). Обычно
голова представляет собой белый прямоугольник, содержащий имя класса.
data:Stock
I
Рис. 17.2. Lifeline «данные» класса
Рис. 17.3. Анонимный
Stock
спасательный круг класса User
431
х[к]:Х
I
Рис. 17.4. Линия жизни "x" класса X выбирается
с помощью селектора [k]
Если имя представляет собой ключевое слово self, то линия жизни
представляет
объект
классификатора,
который
заключает
в
себе
взаимодействие, которому принадлежит линия жизни. Порты корпуса
могут быть показаны отдельно, даже если включен сам.
5.1.3. Шлюз
Шлюз — это конец сообщения, точка соединения для связи
сообщения
вне
фрагмента взаимодействия
с
сообщением внутри
фрагмента взаимодействия.
Целью шлюзов и сообщений между шлюзами является указание конкретного
отправителя и получателя для каждого сообщения. Ворота играют разные
роли:
•
формальные ворота - на взаимодействиях
•
фактические ворота - при использовании взаимодействия
•
ворота экспрессии - на комбинированном фрагменте
Ворота названы неявно или явно. Неявное имя шлюза строится путем
объединения направления сообщения ("вход" или "выход") и имени
сообщения, например, in_search, out_read.
432
Шлюзы обозначаются так же, как точки соединения сообщений на
фрейме.
5.1.4. Фрагмент взаимодействия
представляющий
—
взаимодействия
Фрагмент
наиболее
общую
именованный
элемент,
единицу взаимодействия.
Каждый
это
фрагмент взаимодействия концептуально подобен взаимодействию сам по
себе.
Общего обозначения фрагмента взаимодействия не существует. Его
подклассы определяют свои собственные обозначения.
Примеры фрагментов взаимодействия:
•
вхождение
•
исполнение
•
инвариант состояния
•
комбинированный фрагмент
•
использование взаимодействия
5.1.5. Возникновение
Возникновение (полное UML-имя — спецификация возникновения,
т.
е.
«описание
события»)
—
это
фрагмент
взаимодействия,
представляющий момент времени (событие) в начале или конце сообщения,
или в начале или конце выполнения.
Спецификация вхождения является одной из основных семантических
единиц
взаимодействия.
Значения
взаимодействий
определяются
последовательностями вхождений, описанными спецификациями вхождений.
433
Каждая спецификация вхождения появляется ровно на одной линии
жизни. Спецификации появления линии жизни упорядочены вдоль линии
жизни.
Спецификация вхождения не имеет обозначения и представляет собой
просто точку в начале или конце сообщения, или в начале или конце
спецификации выполнения.
Примеры возникновения:
•
появление сообщения
•
возникновение выполнения
Возникновение сообщения
Возникновение сообщения (полное имя UML — спецификация
возникновения сообщения) — это возникновение, которое представляет
такие события, как отправка и получение сигналов или вызов, или получение
вызовов операций.
Разрушение
Возникновение разрушения — это появление сообщения, которое
представляет собой уничтожение экземпляра, описанного линией жизни. Это
может
привести
к
последующему
уничтожению
других
объектов,
принадлежащих этому объекту по составу. Никакое другое событие не
может появляться ниже события разрушения на данной линии жизни.
Полное
UML-имя
вхождения
—
спецификация
вхождения
уничтожения. До UML 2.4 это называлось событием уничтожения, а
раньше — остановкой.
Уничтожение экземпляра изображается крестиком в виде буквы Х
внизу спасательного круга (рис. 17.5.).
434
Рис. 17.5. Линия жизни аккаунта прекращена
Выполнение
Выполнение (полное имя UML — спецификация выполнения) —
это событие, представляющее моменты времени, в которые начинаются или
заканчиваются действия, или поведение.
Экземпляр выполнения ссылается ровно на одну спецификацию
выполнения, которая описывает выполнение, которое начинается или
завершается в этом экземпляре выполнения (рис. 17.6.).
435
Рис. 17.6. Продолжительность выполнения представлена
двумя событиями выполнения — началом и окончанием.
5.1.6. Исполнение
Исполнение (полное название — спецификация исполнения,
неофициально называемая активацией) — фрагмент взаимодействия,
который представляет собой период в жизни участника, когда он
•
выполнение единицы поведения или действия в пределах линии
жизни,
•
отправка сигнала другому участнику,
•
ожидание ответного сообщения от другого участника.
Обратите внимание,
что спецификация выполнения включает
случаи, когда поведение не активно, а просто ожидает ответа. Длительность
436
выполнения
представлена
двумя
экземплярами
выполнения
—
начальным и конечным.
Исполнение изображается тонким серым или белым прямоугольником
Рис. 17.7. Спецификация выполнения показана серым прямоугольником
на линии жизни службы.
Спецификацию выполнения можно представить в виде более
широкого прямоугольника с меткой, где метка обычно идентифицирует
действие, которое было выполнено (рис. 17.8.).
437
Рис. 17.8. Спецификация выполнения представлена в виде более
широкого прямоугольника, помеченного как действие.
Для спецификаций выполнения, которые относятся к атомарным
действиям,
таким
как
чтение
атрибутов
сигнала
(передаваемого
сообщением), символ действия может быть связан со спецификацией
события приема линией, чтобы подчеркнуть, что все действие связано только
с одним событием. спецификации (и ассоциации начала и окончания
относятся к одной и той же спецификации вхождения).
Перекрывающиеся спецификации выполнения на одной жизненной
линии представлены перекрывающимися прямоугольниками (рис. 17.9. и
17.10).
Рис. 17.9. Перекрывающиеся
Рис. 17.10. Перекрывающиеся
спецификации выполнения на
спецификации выполнения на
одной жизненной линии -
одной жизненной линии -
сообщение самому себе.
сообщение обратного вызова.
438
5.1.7. Инвариант состояния
Инвариант состояния — это фрагмент взаимодействия, который
представляет
ограничение
времени
выполнения
для
участников
взаимодействия. Его можно использовать для указания различных видов
ограничений, таких как значения атрибутов или переменных, внутренние или
внешние состояния и т. д.
Ограничение
оценивается
непосредственно
перед
выполнением
следующей спецификации вхождения, так что все действия, которые не
моделируются явно, были выполнены. Если ограничение истинно, трасса
является допустимой трассой, в противном случае трасса является
недопустимой.
Инвариант состояния обычно отображается как ограничение в
фигурных скобках на линии жизни (рис. 17.11.).
:Task
{t==complete}
V
Рис. 17.11. Атрибут t Задачи должен быть равен завершенному.
Это
также
может
быть
показано
как
символ
состояния,
представляющий эквивалент ограничения, которое проверяет состояние
объекта, представленного линией жизни. Это может быть либо внутреннее
состояние поведения классификатора соответствующего классификатора,
либо некоторое внешнее состояние, основанное на представлении «черного
ящика» линии жизни.
439
Рис. 17.12. Задача должна находиться в состоянии «Завершено».
Инвариант состояния может дополнительно отображаться в виде
примечания, связанного со спецификацией вхождения.
5.1.8. Использование взаимодействия
Использование взаимодействия — это фрагмент взаимодействия,
который позволяет использовать (или вызывать) другое взаимодействие.
Большие и сложные диаграммы последовательности могут быть упрощены с
использованием
взаимодействия.
Также
распространено
повторное
использование некоторого взаимодействия между несколькими другими
взаимодействиями.
Упомянутое взаимодействие имеет формальные ворота. Использование
взаимодействия предоставляет набор фактических ворот, которые должны
соответствовать формальным вратам взаимодействия.
Использование взаимодействия работает как:
•
скопировать содержимое упомянутого взаимодействия туда, где это
взаимодействие необходимо использовать,
•
замените формальные параметры аргументами,
•
соедините формальные ворота с фактическими.
Использование взаимодействия показано как совмещенный фрагмент с
оператором ref (рис. 17.13.).
440
Рис. 17.13. Веб-клиент и книжный магазин используют (справочное)
взаимодействие Checkout.
Синтаксис взаимодействия с использованием оператора ref:
interaction-use ::= [ attribute-name '=' ] [ collaboration-use '.' ] interaction-name [
io-arguments ] [ ':' return-value ]
io-arguments ::= '(' io-argument [ ',' io-argument ]* ')'
io-argument ::= in-argument | 'out' out-argument
Имя атрибута относится к атрибуту одной из линий жизни во
взаимодействии, которая получит результат взаимодействия. Обратите
внимание, что это ограничивает назначение результатов взаимодействий
только атрибутам. В реальной жизни результаты вызова метода могут быть
присвоены переменной из вызывающего метода.
Использование
совместной
работы
—
это
идентификация
использования совместной работы, которая связывает жизненные линии
сотрудничества (рис. 17.14.). В этом случае имя взаимодействия находится в
рамках этого сотрудничества.
io -arguments — это список входных и/или исходящих аргументов
взаимодействия.
441
Рис. 17.14. Используйте взаимодействие входа для аутентификации
пользователя и присвоения результата обратно атрибуту пользователя
контроллера сайта.
Одно ограничение, налагаемое спецификацией UML, которому иногда
трудно следовать, заключается в том, что использование взаимодействия
должно охватывать все задействованные линии жизни, представленные во
включающем взаимодействии. Это означает, что все эти линии жизни
должны быть каким-то образом расположены рядом друг с другом. Если у
нас есть другое использование взаимодействия на той же диаграмме, может
быть очень сложно переставить все задействованные линии жизни, как того
требует UML.
5.1.9. UML-сообщение
5.1.9.1 Понятие UML-сообщения
Сообщение — это именованный элемент,
определяющий один конкретный вид связи между жизненными линиями
взаимодействия. В сообщении указывается не только вид связи, но также
отправитель и получатель. Отправитель и получатель обычно представляют
собой две спецификации вхождения (точки на концах сообщений).
Синтаксис сообщения:
message ::= [ attribute '=' ] signal-or-operation-name [ arguments ] [ ':' return-value ]
| '*'
arguments ::= '(' [argument [ ',' argument]* ')'
442
argument ::= [ parameter-name '='] argument-value | attribute '=' out-parameter-name
[ ':' argument-value ] | ' -'
Аргументы сообщения могут быть только:
•
атрибуты отправляющей линии жизни,
•
константы,
•
символические
значения
(которые
представляют
собой
подстановочные знаки, представляющие любое допустимое значение),
•
явные параметры объемлющего взаимодействия,
•
атрибуты класса, владеющего взаимодействием.
Сообщение отображается как линия от конца сообщения отправителя
до конца сообщения получателя. Строка должна быть такой, чтобы каждый
фрагмент строки был либо горизонтален, либо направлен вниз при переходе
от события отправки к событию получения. События отправки и получения
могут находиться на одной и той же линии жизни. Форма линии или стрелки
отражает свойства сообщения.
5.1.9.2 Сообщения по типу действия
Сообщение отражает либо вызов операции и начало ее выполнения,
либо отправку и прием сигнала.
Когда сообщение представляет собой вызов операции, аргументы
сообщения являются аргументами операции. Когда сообщение представляет
сигнал, аргументы сообщения являются атрибутами сигнала.
В зависимости от типа действия, которое использовалось для создания
сообщения, сообщение может быть одним из:
•
синхронный вызов
•
асинхронный вызов
•
асинхронный сигнал
443
•
сообщение о создании
•
удалённое сообщение
•
ответное сообщение
Синхронный вызов
Синхронный вызов обычно представляет собой вызов операции —
отправить сообщение и приостановить выполнение в ожидании ответа.
Сообщения о синхронных вызовах отображаются с закрашенной стрелкой
(рис. 17.15.).
Рис. 17.15. Веб-клиент выполняет поиск в Интернет-книжном магазине и
ожидает результатов.
Асинхронный вызов
Асинхронный вызов - отправьте сообщение и продолжите работу
немедленно,
не
дожидаясь
возвращаемого
значения
(рис.
17.16.).
Асинхронные сообщения имеют открытую стрелку.
Рис. 17.16. Служба запускает Task и продолжает работу параллельно без
ожидания.
444
Асинхронный сигнал
Асинхронное сигнальное сообщение соответствует асинхронному
действию отправки сигнала.
Сообщение о создании
Сообщение о создании отправляется на линию жизни, чтобы создать
себя. Оно отображается в виде пунктирной линии с открытой стрелкой
(выглядит так же, как ответное сообщение), указывающей на начало
созданной линии жизни (рис. 17.17.).
Рис. 17.17. Книжный-интернет магазин создает учетную запись.
Обратите внимание, что это странное соглашение об отправке
сообщения
несуществующему
объекту
для
создания
самого
себя
используется как в UML 1.x, так и в 2.x. В практике OOAD сообщение create,
вероятно, должно быть отправлено классу, см. Сообщение в обсуждении
OOAD для получения фоновой информации. В Smalltalk-80 новые объекты
создаются путем отправки сообщений классам, при этом экземпляр класса
создается и возвращается обратно. Таким образом, один из способов
интерпретировать нотацию создания сообщений UML, вероятно, состоит в
том, чтобы использовать ярлык для этих действий.
Удаленное сообщение
Сообщение об удалении (называемое остановкой в предыдущих
версиях UML) отправляется для завершения другой линии жизни. Линия
жизни обычно заканчивается крестом в виде Х внизу, обозначающим
возникновение разрушения.
445
Спецификация UML 2.4 не предоставляет ни специальных обозначений
для сообщения об удалении, ни стереотипа. Пока они не предоставят какую-
нотацию,
то
мы
можем
использовать
пользовательский
стереотип
«уничтожить» (рис. 17.18.).
Рис. 17.18. Книжный-интернет магазин прекращает действие Учетной
записи.
Ответное сообщение
Ответное сообщение на вызов операции отображается в виде
пунктирной линии с открытой стрелкой (похоже на сообщение о создании)
(рис. 17.19.).
Рис. 17.19. Веб-клиент выполняет поиск в Интернет-книжном магазине и
ожидает результатов.
5.1.9.3 Сообщения о наличии событий
В зависимости от того, присутствуют ли события отправки и получения
сообщения, сообщение может быть одним из:
•
полное сообщение
446
потерянное сообщение
•
найденное сообщение
•
неизвестное сообщение (по умолчанию)
Семантика
полного
сообщения
—
это
трассировка
<sendEvent,
ReceiveEvent>. Присутствуют как sendEvent, так и ReceiveEvent.
Неизвестное сообщение - оба sendEvent и ReceiveEvent отсутствуют
(не должны появляться).
Потерянное сообщение
Потерянное сообщение — это сообщение, в котором известно событие
отправки, но нет события получения (рис. 17.20.). Это интерпретируется так,
как будто сообщение, так и не достигло адресата. Семантика - трассировка
<sendEvent>, receiveEvent отсутствует. Потерянные сообщения обозначаются
маленьким черным кружком в конце сообщения со стрелкой.
search
X
Рис. 17.20. Веб-клиент отправил поисковое сообщение,
которое было потеряно.
Найденное сообщение
Найденное сообщение — это сообщение, в котором известно событие
получения, но нет (известного) события отправки. Это интерпретируется так,
как будто источник сообщения выходит за рамки описания. Это может быть,
например, шум или другая активность, которую мы не хотим подробно
описывать. Семантика — это просто трассировка: <receiveEvent>, а событие
отправки отсутствует.
447
Найденные сообщения обозначаются маленьким черным кружком в
начале сообщения (рис. 17.21.).
search
>
Рис. 17.21. Книжный-интернет магазин получает поисковое сообщение
неизвестного происхождения.
5.1.10. Комбинированный фрагмент
5.1.10.1 Понятие комбинированного фрагмента
Комбинированный
фрагмент
-
определяющий комбинацию (выражение)
фрагмент
взаимодействия,
фрагментов взаимодействия.
Комбинированный фрагмент определяется оператором взаимодействия и
соответствующими операндами взаимодействия. Благодаря использованию
комбинированных фрагментов пользователь сможет компактно и лаконично
описать ряд трасс.
Комбинированный
фрагмент
может
иметь
взаимодействия, также называемые защитой в UML 2.4.
Оператор взаимодействия может быть одним из:
•
alt - alternatives (альтернативы)
•
opt - option (вариант)
•
loop - iteration (итерация)
•
break - break (перерыв)
•
par - parallel (параллельно)
•
strict - strict sequencing (строгая последовательность)
448
ограничения
•
seq - weak sequencing (слабое секвенирование)
•
critical - critical region (критическая область)
•
ignore - ignore (игнорировать)
•
consider - consider (рассматривать)
•
assert - assertion (утверждение)
•
neg - negative (отрицательный)
5.1.10.2 Ограничение взаимодействия
Ограничение взаимодействия — это ограничение, используемое во
взаимодействиях, — логическое выражение, которое защищает операнд в
комбинированном фрагменте.
Ограничение
взаимодействия
показано
в
квадратных
скобках,
закрывающих линию жизни, где произойдет первое событие, расположенное
над
этим
событием
в
содержащем
взаимодействии
или
операнде
взаимодействия.
В UML 2.4 ограничение взаимодействия часто называется защитой.
5.1.10.3 Альтернативы
Оператор взаимодействия alt означает, что объединенный фрагмент
представляет собой выбор или альтернативы поведения. Будет выбран не
более одного из операндов. Выбранный операнд должен иметь явное или
неявное защитное выражение, которое на данном этапе взаимодействия
оценивается как истинное.
Неявная истинная защита подразумевается, если операнд не имеет
защиты.
Операнд, защищенный else, означает защиту, которая является
отрицанием дизъюнкции всех других защиты. Если ни один из операндов не
449
имеет защиты, которая оценивается как истина, ни один из операндов не
выполняется, и выполняется оставшаяся часть окружающего фрагмента
взаимодействия (рис. 17.22.).
J [balance>0] 1
alt
accept()
—
[else]
reject ()
,
*LI
ш
Рис. 17.22. Вызовите accept(), если баланс > 0, в противном случае
вызовите reject().
5.1.10.4 Вариант
Оператор
взаимодействия
opt
означает,
что
комбинированный
фрагмент представляет собой выбор поведения, при котором происходит
либо (единственный) операнд, либо ничего не происходит (рис. 17.23.).
Параметр семантически эквивалентен альтернативному комбинированному
фрагменту, в котором есть один операнд с непустым содержимым, а второй
операнд пуст.
opt J [no errors]
I
post_comments()
ru
т
Рис. 17.23. Оставляйте комментарии, если не было ошибок.
5.1.10.5 Цикл
Цикл оператора взаимодействия означает, что объединенный фрагмент
представляет собой цикл. Операнд цикла будет повторяться несколько раз.
Конструкция цикла представляет собой рекурсивное применение оператора
450
seq, в котором операнд цикла упорядочивается после результата предыдущих
итераций.
Спецификация UML 2.4 предоставляет странное описание оператора
цикла со странными примерами. Я постараюсь извлечь из этого хоть какойто смысл.
Цикл может контролироваться одной или обеими границами итерации
и защитой.
Операнд цикла может иметь границы итераций, которые могут
включать нижнее и верхнее число итераций цикла. Текстовый синтаксис
цикла:
loop-operand ::= loop [ '(' min-int [ ',' max-int ] ')' ]
min-int ::= non-negative-integer
max-int ::= positive-integer | '*'
Если в цикле не указаны границы, это означает потенциально
бесконечный цикл с нулем в качестве нижней границы и бесконечной
верхней границей (рис. 17.24.).
Рис. 17.24. Потенциально бесконечный цикл.
Если указано только min-int, это означает, что верхняя граница равна
нижней, и цикл будет выполняться ровно указанное количество раз (рис.
17.25.).
451
Рис. 17.25. Цикл для выполнения ровно 10 раз.
Если указано max-int, оно должно быть больше или равно min-int.
Цикл будет повторяться минимальное количество раз min-int и максимальное
количество раз max-int.
Помимо
границ
итерации,
цикл
может
иметь
ограничение
взаимодействия — логическое выражение в квадратных скобках. Чтобы
добавить к другим путаницам, UML 2.4 также называет их обоих guards.
UML пытается перетасовать простейшую форму цикла for и цикла
while, что вызывает странную семантику цикла UML 2.3 [UML 2.3 -
Надстройка]: «после выполнения минимального количества итераций и
логического выражения ложно цикл завершится " (рис. 17.26.). Это
поясняется, хотя и с противоположным значением, на следующей странице:
«Цикл будет продолжаться только в том случае, если эта спецификация
оценивается как истина во время выполнения, независимо от минимального
количества итераций, указанного в цикле».
Рис. 17.26. Мы можем предположить, что в соответствии с UML 2.3
ожидается, что цикл будет выполнен минимум 5 раз и не более 10 раз.
452
Если защитное условие [size<0] становится ложным, цикл завершается
независимо от указанного минимального количества итераций.
5.1.10.6 Перерыв
Оператор взаимодействия break представляет прерывающий или
исключительный
сценарий,
который
выполняется
вместо
остатка
окружающего фрагмента взаимодействия.
Оператор break с защитой выбирается, когда защита истинна. В этом
случае
остальная
часть
непосредственно
окружающего
фрагмента
взаимодействия игнорируется (рис. 17.27.). Когда защита операнда разрыва
ложна, операнд разрыва игнорируется, и продолжается остальная часть
окружающего фрагмента взаимодействия.
Рис. 17.27. Разорвите замыкающий цикл, если y>0.
Комбинированный фрагмент с оператором break должен охватывать
все линии жизни окружающего фрагмента взаимодействия.
Обратите внимание, что UML позволяет отказаться только от одного
уровня, непосредственно включающего фрагмент взаимодействия. Это
может стать очень раздражающим, если двойной цикл или цикл с другими
комбинированными фрагментами должны быть нарушены.
453
UML 2.3 утверждает, что, когда операнд разрыва не имеет защиты,
выбор между операндом разрыва и остальной частью окружающего
фрагмента взаимодействия выполняется «недетерминированно», что, скорее
всего, означает «непредсказуемый». Не используйте break без защиты.
5.1.10.7 Параллельно
Оператор взаимодействия par определяет потенциально параллельное
выполнение поведения операндов объединенного фрагмента. Различные
операнды могут чередоваться любым способом, пока сохраняется порядок,
налагаемый каждым операндом.
Набор следов параллельного оператора описывает все возможные
способы или комбинации, которыми спецификации вхождения операндов
могут чередоваться без изменения порядка внутри каждого операнда (рис.
17.28.).
Рис. 17.28. Поиск в Google, Bing и Ask в любом порядке, возможно,
параллельно.
Параллельно объединенный фрагмент имеет условное обозначение для
типичных ситуаций, когда порядок событий на одной линии жизни не имеет
значения. В области коррегиона («Coregion») линии жизни, ограниченной
горизонтальными
квадратными
скобками,
454
все
непосредственно
содержащиеся
фрагменты
рассматриваются
как
отдельные
операнды
параллельного объединенного фрагмента (рис. 17.29.).
i
■
1
searchjgoogteQ
|
isearch_bing()
-------- ——--- ►search_ask()
L
i
J——*0I
Рис. 17.29. Coregion — поиск в Google, Bing и Ask в любом порядке,
возможно, параллельно.
5.1.10.8 Строгая последовательность
Оператор взаимодействия strict требует строгой последовательности
(порядка) операндов на первом уровне внутри объединенного фрагмента
(рис. 17.30.).
search_google()
search_yahoo()
----------- H
Рис. 17.30. Поиск в Google, Bing и Yahoo строго в последовательном
порядке.
Операнды более низких уровней в содержащемся комбинированном
фрагменте не будут напрямую сравниваться с другими спецификациями
вхождения включающего комбинированного фрагмента. Нотативно это
означает, что вертикальная координата содержащихся фрагментов значима
455
во всем объеме объединенного фрагмента, а не только на одной линии
жизни.
5.1.10.9 Слабое секвенирование
Оператор взаимодействия seq означает, что объединенный фрагмент
представляет собой слабую последовательность поведения операндов.
Слабое секвенирование определяется набором трасс со следующими
свойствами:
•
Порядок следования спецификаций внутри каждого из операндов
сохраняется.
•
Спецификации появления на разных линиях жизни из разных
операндов могут идти в любом порядке.
•
Спецификации появления на одной и той же жизненной линии из
разных операндов упорядочены таким образом, что спецификация
появления первого операнда предшествует спецификации второго
операнда.
Слабое последовательность сводится к параллельному слиянию,
когда
операнды
принадлежат
разным
наборам
участников.
Слабая
последовательность сводится к строгой последовательности, когда операнды
работают с одним и тем же участником (рис. 17.31.).
456
search_google()
Рис. 17.31. Ищите в Google, возможно, параллельно с Bing и Yahoo, но
ищите в Bing до Yahoo.
5.1.10.10 Критическая область
Оператор взаимодействия Critical определяет, что объединенный
фрагмент
представляет
собой
критическую
область
(рис.
17.32.).
Критическая область — это область с трассами, которые не могут
чередоваться с другими спецификациями возникновения (на линиях жизни,
покрываемых областью). Это означает, что область обрабатывается
атомарно окружающим фрагментом и не может чередоваться, например, с
помощью параллельного оператора.
Рис. 17.32. Add() или remove() можно вызывать параллельно,
но каждый из них должен выполняться как критическая область.
457
5.1.10.11 Игнорировать
Семантика и цель игнорирования оператора взаимодействия неясны.
UML 2.3 определяет его значение как «существуют некоторые типы
сообщений, которые не отображаются в этом комбинированном фрагменте.
Эти
типы
сообщений
можно
считать
незначительными
и
неявно
игнорировать, если они появляются в соответствующем выполнении. В
качестве альтернативы можно понимать игнорирование как означающее, что
типы сообщений, которые игнорируются, могут появляться в любом месте
трассировки».
С другой стороны, пояснения к рисунку 14.25 на с. 530 [UML 2.3 —
Надстройка] заключаются в том, что этот вид взаимодействия можно
использовать для определения теста существующей системы. Во время
выполнения сообщения, проигнорированные в тестах, «конечно, будут
каким-то образом обрабатываться работающей системой».
Список игнорируемых сообщений следует за операндом, заключенным
в пару фигурных скобок "{" и "}" (рис. 17.33.). Операция игнорирования
обычно сочетается с другими операциями, такими как «утверждение
игнорирования {m, s}».
ignore{get,set}J
add()
remove!)
“
Рис. 17.33. Игнорировать сообщения get() и set(), если таковые имеются.
5.1.10.12 Учитывать
Оператор взаимодействия, рассматривающий, определяет, какие
сообщения следует рассматривать в этом комбинированном фрагменте, что
означает, что любое другое сообщение будет проигнорировано.
458
Список
рассматриваемых
сообщений
следует
за
операндом,
заключенным в пару фигурных скобок "{" и "}". Операция рассмотрения
обычно сочетается с другими операциями, такими как «утверждение
рассмотрения {m, s} (рис. 17.34.)».
considerfadd, removekJ
add()
r 1
remove()
M
Рис. 17.34. Учитывайте только сообщения add() или remove(),
игнорируйте любые другие.
5.1.10.13 Утверждение
Оператор взаимодействия assert означает, что комбинированный
фрагмент представляет собой утверждение, что последовательности операнда
assert являются единственными действительными продолжениями (должны
удовлетворяться при правильном проектировании системы) (рис. 17.35.). Все
остальные продолжения приводят к недопустимой трассировке.
assert J
commitO
T
{t==coiriplete}
1
Рис. 17.35. В этот момент должно появиться сообщение Commit(),
сопровождаемое оценкой инварианта состояния.
5.1.10.14 Отрицательный
Оператор взаимодействия neg описывает объединенный фрагмент
трасс, которые
определены
как
отрицательные
459
(недействительные).
Отрицательные трассировки — это трассировки, возникающие при сбое
системы. Все фрагменты взаимодействия, отличные от отрицательного,
считаются положительными, что означает, что они описывают следы,
которые являются действительными и должны быть возможными (рис.
17.36.).
«remote» login()
1
■
neg )
timeout
<--------------------
Рис. 17.36. Если мы получим сообщение об истечении тайм-аута,
это означает, что система вышла из строя.
6.2. UML диаграмма связи
6.2.1. Понятие и схема UML диаграммы связи
Диаграмма связи (называемая диаграммой сотрудничества в UML
1.x) — это своего рода диаграмма взаимодействия UML, которая
показывает
взаимодействие
между
объектами
и/или
частями
(представленными в виде линий жизни) с использованием упорядоченных
сообщений в произвольной форме.
Коммуникационная диаграмма соответствует (т.е. может быть
преобразована в/из или заменена) простой диаграмме последовательности
без структурирующих механизмов, таких как использование взаимодействия
и комбинированные фрагменты. Также предполагается, что перехват
сообщений (т. е. порядок приема отличается от порядка отправки данного
набора сообщений) не будет иметь места или не имеет значения.
На диаграммах связи UML рисуются следующие узлы и ребра: фрейм,
линия жизни, сообщение. Эти основные элементы коммуникационной
диаграммы показаны на рисунке ниже (рис. 17.37.).
460
Рис. 17.37. Основные элементы UML диаграммы связи.
6.2.2. Рамка
Схемы связи могли отображаться в прямоугольной рамке с названием
в ячейке в верхнем левом углу.
Для типов заголовков коммуникационных диаграмм не существует
специального
полного
имени.
Можно
использовать
длинное
имя
взаимодействия (обычно используемое для диаграмм взаимодействия)
(рис. 17.38.).
Рис. 17.38. Рамка взаимодействия для коммуникационной диаграммы
BuyItem
461
Для
коммуникационных
диаграмм
также
не
существует
специального краткого названия. Можно использовать короткое имя sd
(которое обычно используется для диаграмм взаимодействия) (рис. 17.39.).
Эта sd немного сбивает с толку, так как выглядит как аббревиатура
диаграммы последовательности.
Рис. 17.39. Рамка Sd для диаграммы связи BuyItem
6.2.3. Линия жизни
Линия жизни — это специализация именованного элемента, который
представляет отдельного участника взаимодействия. В то время как
кратность частей и структурных элементов может быть больше 1, линии
жизни представляют собой только один взаимодействующий объект.
Если указанный соединяемый элемент является многозначным (т. е.
имеет кратность > 1), то линия жизни может иметь выражение ( селектор ),
указывающее, какая конкретная часть представлена этой линией жизни. Если
селектор опущен, это означает, что выбран произвольный представитель
многозначного соединительного элемента.
Линия жизни показана в виде прямоугольника (соответствует «голове»
на
диаграммах
последовательности).
Линия
жизни
на
диаграммах
последовательности имеет «хвост», представляющий линию жизни, тогда
как «линия жизни» на диаграмме связи не имеет линии, а только «голову».
Информация, идентифицирующая линию жизни, отображается внутри
прямоугольника в следующем формате:
462
lifeline-ident ::= ([ connectable-element-name [ '[' selector ']' ] ] [: class-name ]
[decomposition] ) | 'self'
selector ::= expression
decomposition ::= ‘ref' interaction-ident [ 'strict' ]]
где class-name — это тип, на который ссылается представленный
подключаемый элемент. Обратите внимание, что, хотя синтаксис позволяет
это, lifeline-ident не может быть пустым.
Головка линии жизни имеет форму, основанную на классификаторе
той части, которую представляет эта линия жизни. Обычно заголовок
представляет собой белый прямоугольник, содержащий имя класса после
двоеточия (рис. 17.40. - 17.42.).
Рис. 17.40. Анонимный
Рис. 17.41. Lifeline «данные»
спасательный круг класса User.
класса Stock
Рис. 17.42. Линия жизни "x" класса X выбирается с помощью селектора
[k].
Если имя представляет собой ключевое слово self, то линия жизни
представляет
объект
классификатора,
который
заключает
в
себе
взаимодействие, которому принадлежит линия жизни. Порты корпуса
могут быть показаны отдельно, даже если включен сам.
463
6.2.4. Сообщение
Сообщение на диаграмме связи отображается в виде линии с
выражением последовательности и стрелкой над линией. Стрелка
указывает направление связи (рис. 17.43.).
Рис. 17.43. Экземпляр класса A отправляет сообщение remove()
экземпляру B, если s1 равно s2
Выражение последовательности
Выражение последовательности представляет собой список членов
последовательности, разделенных точками, за которыми следует двоеточие
(":") и имя сообщения после него:
sequence-expression ::= sequence-term '.' . . . ':' message-name
Например, 3b.2.2:m5 содержит выражение последовательности 3b.2.2 и
имя сообщения m5.
Каждый член последовательности представляет собой уровень
процедурной вложенности в рамках общего взаимодействия. Каждый
термин последовательности имеет следующий синтаксис:
sequence-term ::= [ integer [ name ] ] [ recurrence ]
Целое число представляет собой порядковый номер сообщения на
следующем более высоком уровне процедурного вызова (активации).
Сообщения, отличающиеся одним целочисленным термином, являются
последовательными на этом уровне вложенности.
Например,
464
сообщение с последовательностью 2 следует за сообщением с
последовательностью 1 (рис. 17.44.),
•
2.1 следует за 2
•
5.3 следует за 5.2 в рамках активации 5
•
1.2.4 следует за сообщением 1.2.3 при активации 1.2.
Рис. 17.44. Экземпляр A отправляет сообщение draw() экземпляру B, а
после этого B отправляет paint() экземпляру C
Имя представляет параллельный поток управления. Сообщения,
отличающиеся конечным именем, являются одновременными на этом уровне
вложенности.
Например,
•
сообщения 2.3a и 2.3b одновременны в активации 2.3 (рис. 17.45.),
•
1.1 следует за 1а и 1б,
•
3a.2.1 и 3b.2.1 следуют за 3.2.
Рис. 17.45. Экземпляр A отправляет сообщения draw() одновременно
экземпляру B и экземпляру C
465
Повторение определяет условное или итеративное выполнение нуля
или более сообщений, которые выполняются в зависимости от указанного
условия.
recurrence ::= branch | loop
branch ::= '[' guard ']'
loop ::= '*' [ '||' ] [ '['iteration-clause ']' ]
Guard задает условие, при котором сообщение должно быть отправлено
(выполнено) на заданной глубине вложенности. UML не определяет
синтаксис защиты, поэтому он может быть выражен в псевдокоде, на каком-
либо языке программирования или в чем-то еще.
Например,
•
2.3b [x>y]: draw() — сообщение draw() будет выполнено, если x
больше y (рис. 17.46.),
•
1.1.1 [s1.equals(s2)]: removeO — сообщение remove() будет выполнено,
если s1 равно s2.
Рис. 17.46. Экземпляр класса A отправит сообщение
draw() экземпляру C, если x > y
Итерация задает последовательность сообщений с заданной глубиной
вложенности. UML не определяет синтаксис предложения итерации,
поэтому
его
можно
выразить
в
псевдокоде,
каком-либо
языке
программирования или чем-то еще. Предложение итерации может быть
опущено, и в этом случае условия итерации не указаны.
Нотация итерации * указывает, что сообщения в итерации будут
выполняться последовательно. * || (звездочка, за которой следует двойная
466
вертикальная черта) итерация определяет одновременное (параллельное)
выполнение сообщений.
Например,
•
4.2c *[i=1..12]: search(t[i]) - search() будет выполняться 12 раз, один за
другим (рис. 17.47.),
•
4.2c *||[i=1..12]: search(t[i]) — одновременно будет отправлено 12
сообщений search() (рис. 17.48.),
•
2.2 *: notifyO - сообщение notify() будет повторяться неопределенное
количество раз.
Рис. 17.47. Экземпляр класса A
Рис. 17.48. Экземпляр класса A
будет отправлять сообщение
отправит n одновременных
search() экземпляру B n раз, один
сообщений search() экземпляру B.
за другим
Повторение не повторяется на внутренних уровнях вложенной
управляющей структуры. Каждый уровень структуры определяет свою
собственную итерацию в окружающем контексте.
6.3. Временная UML диаграмма
6.3.1. Понятие и схема временной UML диаграммы
Временные диаграммы — это диаграммы взаимодействия UML,
которые используются для демонстрации взаимодействий, когда основная
цель диаграммы — рассуждать о времени. Временные диаграммы
фокусируются на изменении условий внутри и между линиями жизни вдоль
467
линейной оси времени. Временные диаграммы описывают поведение как
отдельных классификаторов, так и взаимодействие классификаторов,
акцентируя внимание на времени событий, вызывающих изменения в
моделируемых состояниях линий жизни (рис. 17.49.).
Рис. 17.49. Основные элементы временной UML диаграммы— линия
жизни, временная шкала, состояние или условие, сообщение,
ограничение длительности, линейка времени.\
Вы сможете найти несколько примеров временных диаграмм в
разделе 4 данной монографии.
6.3.2. Линия жизни
Линия жизни — это именованный элемент, представляющий
отдельного участника взаимодействия. В то время как кратность частей и
структурных элементов может быть больше 1, линии жизни представляют
468
собой только один взаимодействующий объект. Подробности см. в
жизненном цикле на диаграммах последовательности в 5.1.2.
Линия жизни на временных диаграммах представлена именем
классификатора или экземпляром, который он представляет. Его можно
разместить внутри рамки диаграммы или «дорожки для плавания» (рис.
17.50.).
Рис. 17.50. Линии жизни, представляющие экземпляры
системы и вируса
6.3.3. Хронология состояния
Временная диаграмма может отображать состояния участвующего
классификатора или атрибута, или некоторые проверяемые условия, такие
как дискретное или перечисляемое значение атрибута (рис. 17.51.).
Execution
“
Triggering
>
Propagation
Dormant
Рис. 17.51. Временная шкала показывает, как вирус меняет свое
состояние между состоянием бездействия, распространения, запуска и
выполнения.
UML также допускает непрерывность измерения состояния/условия.
Его можно использовать в сценариях, в которых объекты постоянно меняют
свое состояние, например, температуру или плотность.
469
6.3.4. Ограничение продолжительности
Ограничение продолжительности — это ограничение интервала,
которое относится к интервалу длительности. Интервал длительности —
это длительность, используемая для определения того, удовлетворяется ли
ограничение.
Семантика ограничения длительности наследуется от ограничений.
Если ограничения нарушаются, трассы становятся отрицательными, что
означает, что система считается неисправной.
Ограничение длительности отображается как некоторая графическая
связь между интервалом длительности и конструкциями, которые он
ограничивает (рис. 17.52.).
~
Melting
----------
Water
-----
Рис. 17.52. Лед должен растаять в воде за 1-6 минут.
6.3.5. Ограничение времени
Ограничение по времени — это ограничение интервала, которое
относится к интервалу времени. Интервал времени — это выражение
времени,
используемое
для
определения
того,
удовлетворяется
ли
ограничение.
Семантика временного ограничения наследуется от ограничений. Все
трассы, где ограничения нарушаются, являются отрицательными трассами,
т.е. если они встречаются, система считается отказавшей.
Ограничение по времени отображается как графическая связь между
временным интервалом и конструкцией, которую он ограничивает (рис.
470
17.53.). Обычно эта графическая ассоциация представляет собой небольшую
линию, например, между спецификацией события и временным интервалом.
с
о
2
«>
о.
Рис. 17.53. Человек должен проснуться между 5:40 и 6:00
6.3.6. Разрушение
Возникновение разрушения — это появление сообщения, которое
представляет собой уничтожение экземпляра, описанного линией жизни. Это
может
привести
к
последующему
уничтожению
других
объектов,
принадлежащих этому объекту по составу. Никакое другое событие не
может появиться после события разрушения на данной линии жизни.
Обозначение
Событие уничтожения изображается крестом в форме X в конце
временной шкалы (рис. 17.54.).
Execution
“
Triggering
>
Propagation
Dormant
Рис. 17.54. Линия жизни вируса прекращена
История
Полное
UML-имя
вхождения
—
спецификация
вхождения
уничтожения. До UML 2.4 это называлось событием уничтожения, а
раньше — остановкой.
471
6.4. UML диаграмма обзора взаимодействия
6.4.1. Понятие и схема UML диаграммы обзора взаимодействия
Диаграммы
управления,
обзора взаимодействия
где
узлами
потока
обеспечивают
являются
обзор потока
взаимодействия
или
использование взаимодействия. Спецификация UML 2.4.1 в некоторых
местах относит эти диаграммы к диаграммам взаимодействия, в то время
как в других местах диаграммы обзора взаимодействия называются
диаграммами специализации действий.
Диаграммы обзора взаимодействий действительно выглядят как
диаграммы
действий,
которые
могут
иметь
только
встроенные
взаимодействия или использования взаимодействий вместо действий
вызова. Встроенные взаимодействия и использование взаимодействий
считаются особыми формами действия поведения при вызове. (Похоже, что
спецификация UML 2.4 ошибочно называет их либо объектными узлами,
либо ActivityInvocations, которые просто отсутствуют в UML 2.4.)
UML 2.4 требует, чтобы ветвление и соединение ветвей в диаграммах
обзора взаимодействия были правильно вложены друг в друга. Это более
ограничительно, чем в диаграммах деятельности, и его может быть довольно
трудно соблюдать.
Обзорная диаграмма взаимодействия UML объединяет элементы
диаграмм действий и диаграмм взаимодействия, как показано на рисунке
ниже.
На диаграммах обзора взаимодействия можно использовать следующие
элементы диаграмм действий: начальный узел, конечный узел потока,
конечный узел действия, узел принятия решения, узел слияния, узел
разветвления, узел соединения.
На
обзорных
следующие
диаграммах
элементы
диаграмм
взаимодействия
можно
взаимодействия:
472
использовать
взаимодействие,
использование
взаимодействия,
ограничение
продолжительности,
ограничение времени (рис. 17.55.).
рамка диаграммы взаимодейс
, участвующие i
•адействии
interaction Submit Comments lifelines Window, zComments, zProxy, zDWRServlet, zPluckRequestBatcti, zPluckSeivice
(вид деятельности)
начальный узел
sd Post Comments
Validate and Approve
Comment
«javascript»
zComments
zWindow
«service»
zPluckSeivice
«javascript»
zComments
ночение
(вид деятельности)
(вцд деятельности) ветвление
(вид деятельности)
слияние
Request all comments
включение
(вид деятельности) слияние
Request all comments
(взаимодействие) временное ограничение
Рис. 17.55. Обзорная UML диаграмма взаимодействия, объединяет
элементы диаграмм действий и диаграмм взаимодействия.
Вы
можете
найти
несколько
примеров
диаграмм
обзора
взаимодействия в разделе 4 данной монографии.
6.4.2. Рамка
Диаграммы обзора взаимодействия обрамляются рамкой того же типа,
что и другие формы диаграмм взаимодействия — прямоугольной рамкой
вокруг диаграммы с названием в ячейке в левом верхнем углу (рис. 17.56.).
Вид взаимодействия — взаимодействие или сд (сокращенно). Обратите
внимание, что UML не имеет аббревиатуры io или iod, как можно было бы
ожидать.
473
Рис. 17.56. Диаграмма обзора взаимодействия Интернет-магазина
Текст заголовка может также включать список содержащихся в нем
линий жизни (которые не отображаются графически).
6.4.3. Элементы диаграммы обзора взаимодействия
Диаграммы обзора взаимодействия определяются как специализация
диаграмм деятельности, и поэтому они наследуют ряд графических
элементов.
Диаграммы обзора взаимодействий могут иметь только встроенные
взаимодействия или использования взаимодействий вместо действий, а
действия диаграммы действий нельзя использовать.
Следующие элементы диаграмм деятельности могут использоваться на
диаграммах обзора взаимодействия:
•
начальный узел
•
конечный узел потока
•
конечный узел активности
•
узел решения
•
узел слияния
474
узел вилки
•
присоединиться к узлу
6.4.4. Элементы диаграммы обзора взаимодействия
На
обзорных
диаграммах
взаимодействия
можно
использовать
следующие элементы диаграмм взаимодействия:
•
взаимодействие
•
использование взаимодействия
•
ограничение продолжительности
•
ограничение времени
Взаимодействие
Диаграмма взаимодействия любого типа может отображаться как
встроенное действие вызова. Встроенные диаграммы взаимодействия могут
быть анонимными или именованными (рис. 17.57.).
Рис. 17.57. Взаимодействие «Добавить товар в корзину» может
отображаться на некоторых схемах обзора взаимодействия.
Использование взаимодействия
Использование взаимодействия может выглядеть как действие
вызова (рис. 17.58.).
475
ref J Add Item to
—' Shopping Cart
Рис. 17.58. Использование взаимодействия «Добавить товар в корзину»
может отображаться на некоторой обзорной диаграмме взаимодействия.
Некоторые инструменты UML могут «развернуть» использование
взаимодействия во встроенное взаимодействие с именем взаимодействия, на
которое ссылается использование. Встроенное взаимодействие будет иметь
аргументы (если есть) ссылки, замененные параметрами.
476
РАЗДЕЛ IV
ПРИМЕРЫ UML
ДИАГРАММ
477
1. ПРИМЕРЫ UML ДИАГРАММЫ КЛАССОВ.
1.1. Полис медицинского страхования
Назначение: Модель предметной области, описывающая различные
типы полисов медицинского страхования.
Резюме: В этом примере показано несколько подтипов полиса
медицинского страхования с использованием наборов обобщения UML.
Один набор обобщений — это тип покрытия — покрытие на основе работы,
самопокрытие и покрытие льгот, а другой набор основан на плане
страхования — HMO, POS, PPO, FFS.
Различные варианты медицинского страхования и варианты для
работы,
государственного
медицинского
страхования
и частного страхования, а также планы
описаны
на
веб-сайте
Министерства
здравоохранения и социальных служб США HealthCare.gov.
Несколько обобщений Полиса медицинского страхования можно
сгруппировать в набор обобщений - Тип покрытия. Этот набор включает
политики, сгруппированные по типу покрытия — покрытие на основе
работы, самопокрытие и покрытие льгот.
Люди, у которых есть работа, могут иметь право на медицинское
страхование через работу — либо на свою работу, либо на работу своего
супруга или родителя. Если человек не может получить страховку через
работодателя, у него или у нее есть ряд других вариантов либо путем
самостоятельного покрытия, либо с использованием некоторых страховых
пособий.
Если человек не может получить медицинскую страховку по работе, он
или она может приобрести полис медицинского страхования для себя или
своей семьи (индивидуальные или семейные страховые полисы).
Люди, имеющие частную медицинскую страховку, также могут иметь
право на участие в программе Medicaid. Это одна из причин, по которой
набор обобщений CoverageType имеет ограничение {перекрытия}.
478
В каждом штате США действует программа Medicaid, которая
обеспечивает медицинское страхование людей с низким доходом, семей и
детей, пожилых людей и людей с ограниченными возможностями. Все штаты
предоставляют страховое покрытие для детей, имеющих право на участие,
через Medicaid и Программу медицинского страхования детей (CHIP). Люди
с ранее существовавшим заболеванием, которые не были застрахованы в
течение последних шести месяцев, могут иметь право на участие в Плане
страхования от ранее существовавших заболеваний (PCIP), созданном в
соответствии с Законом о доступном медицинском обслуживании.
Пример полиса медицинского страхования в виде Диаграммы классов с
наборами обобщений и типами мощности представлен на риссинку 18.1.
479
Рис. 18.1. Пример полиса медицинского страхования Диаграмма классов
UML с наборами обобщений и типами мощности
Другой набор обобщений для полиса медицинского страхования
может
быть
сгруппирован
по
плану
страхования.
Некоторыми
распространенными типами планов медицинского страхования являются
организация медицинского обслуживания (HMO), пункт обслуживания
(POS), вариант участвующего поставщика (PPO) и плата за обслуживание
(FFS). Поскольку этот список неполный, так как существуют другие
480
страховые планы, набор обобщений страховых планов имеет ограничение
{incomplete}. Обычно в страховых планах нет пересечения, что является
причиной еще одного {непересекающегося} ограничения.
HMO является одним из самых доступных и распространенных
вариантов семейного медицинского страхования. Обычно это ограничивает
пациентов в получении медицинской помощи от определенных «входящих в
сеть» врачей и больниц (поставщиков медицинских услуг). PPO — еще один
популярный и гибкий вариант для семей, поскольку он обеспечивает как
покрытие от предпочитаемых сетевых поставщиков, так и возможность
получить помощь от поставщиков медицинских услуг, не входящих в сеть.
План POS представляет собой комбинацию HMO и PPO. План FFS обычно
обеспечивает одинаковое покрытие от всех доступных поставщиков
медицинских услуг, но не работает ни с одной сетью поставщиков
медицинских услуг. Большинство услуг покрываются, потому что это самый
дорогой план медицинского страхования.
1.2. Абстрактная фабричная конструкция
Назначение: проиллюстрировать шаблон проектирования абстрактной
фабрики.
Резюме: Абстрактная фабрика — это творческий шаблон
проектирования программного обеспечения. Этот шаблон предоставляет
интерфейсы для создания семейств связанных или зависимых объектов без
указания их конкретных классов (рис. 18.2.).
481
Рис. 18.2. Пример диаграммы классов UML для шаблона
проектирования абстрактной фабрики.
Клиентское программное обеспечение создает конкретную реализацию
абстрактной фабрики, а затем использует общие интерфейсы для создания
конкретных объектов, которые являются частью семейства объектов. Клиент
не знает и не заботится о том, какие конкретные объекты он получает от
каждой из этих конкретных фабрик, поскольку он использует только общие
интерфейсы их продуктов.
Использование этого шаблона позволяет обмениваться семействами
конкретных классов без изменения кода, который их использует. Он отделяет
детали реализации набора объектов от их использования.
1.3. Модель предметной области библиотеки
Назначение: Описать предметную область для интегрированной
библиотечной системы (ILS), также известной как система управления
библиотекой (LMS) — библиотека, каталог, книга, покровитель, учетная
запись.
Резюме: модель предметной области библиотеки описывает основные
классы и взаимосвязи, которые можно использовать на этапе анализа, чтобы
лучше понять предметную область для ILS или LMS.
Модель предметной области библиотеки (по другому- домен
библиотеки или доменная модель библиотеки) описывает основные классы
и отношения, которые можно использовать на этапе анализа, чтобы лучше
понять область предметной области для интегрированной библиотечной
системы (ILS), также известной как система управления библиотекой
(LMS).
482
Каждый элемент физической библиотеки - книга, магнитофонная
кассета, компакт-диск, DVD и т. д. может иметь собственный номер
элемента. Чтобы поддержать это, предметы могут быть штрих-кодированы.
Целью штрих-кодирования является предоставление уникального и
сканируемого идентификатора, который связывает физический предмет со
штрих-кодом с электронной записью в каталоге. Штрих-код должен быть
физически прикреплен к товару, а номер штрих-кода вводится в
соответствующее поле в электронной записи товара.
Штрих-коды на элементах библиотеки могут быть заменены метками
RFID (рис. 18.3.). Метка RFID может содержать идентификатор предмета,
название, тип материала и т. д. Она считывается считывателем RFID без
необходимости открывать обложку книги или футляр для CD/DVD для
сканирования с помощью считывателя штрих-кода.
Рис. 18.3. Пример диаграммы классов UML модели предметной области
библиотек
Атрибуты библиотечной книги ISBN и тема наследуются от книги и
отображаются с добавленным символом вставки 'Л'.
483
Атрибут «title» явно переопределяет «name». Хотя тип атрибутов тот
же, имя другое. Атрибут «lang» явно переопределен с другим типом.
Первоначальный тип был произвольным текстом String, тогда как
переопределенный атрибут является более конкретным (например,
перечисляемым) классом языка. В этом случае мы использовали явное
переопределение, потому что типы атрибутов «String» и «Language» не
связаны. Язык является типом перечисления.
В библиотеке есть некоторые правила относительно того, что можно
брать напрокат, а что предназначено только для справки. Также определены
правила относительно того, сколько книг может быть одолжено
посетителями и сколько может быть зарезервировано.
Производными являются атрибуты библиотечной книги «loanPeriod»,
«dueDate» и «isOverdue». Продолжительность времени, в течение которого
библиотечная книга может быть взята напрокат (период аренды), зависит от
политики библиотеки и зависит от типа книги и от того, кто ее берет.
Например, в университетской библиотеке студенты могут брать книги на 30
дней, аспиранты — на четверть, а преподаватели — на год. В публичной
библиотеке нормальный срок выдачи книги может составлять 3 недели, а для
новых книг он может быть снижен до 2 недель. Срок возврата книги будет
рассчитываться на основе даты кредита и периода кредита. Если срок
выполнения превышает текущую дату, логический флаг isOverdue, который
по умолчанию является ложным, будет установлен в значение true.
Библиотечный каталог обеспечивает доступ посетителей и
сотрудников библиотеки ко всем источникам информации о библиотечных
объектах, позволяет осуществлять поиск по определенному автору, по
определенной теме или в определенном формате, которые есть в библиотеке.
Он сообщает пользователю, где можно найти материалы, отвечающие его
конкретным потребностям.
1.4. Модель домена онлайн-покупок
Назначение: показать некоторую модель предметной области для
онлайн-покупок — клиент, учетная запись, корзина, продукт, заказ, оплата.
Резюме: Пример диаграммы классов UML, представляющей домен
онлайн-покупок. У каждого клиента может быть некоторая идентификация
веб-пользователя. Веб-пользователь может находиться в одном из
нескольких состояний и может быть связан с корзиной покупок.
Здесь мы приводим пример диаграммы классов UML, которая
показывает модель предметной области для онлайн-покупок (по другомудоменная модель онлайн-покупок). Цель диаграммы - представить
484
некоторые общие термины, «словарь» для онлайн-покупок - Клиент, Веб­
пользователь, Учетная запись, Корзина, Продукт, Заказ, Оплата и т. Д. И
отношения между ними. Его можно использовать как точку соприкосновения
между бизнес-аналитиками и разработчиками программного обеспечения.
Каждый клиент имеет уникальный идентификатор и привязан только к
одной учетной записи (рис. 18.4.). Аккаунт владеет корзиной и заказами.
Клиент может зарегистрироваться в качестве веб-пользователя, чтобы иметь
возможность покупать товары в Интернете. Покупателю не обязательно быть
веб-пользователем, поскольку покупки также можно совершать по телефону
или делать заказы по каталогам. Веб-пользователь имеет имя для входа,
которое также служит уникальным идентификатором. Веб-пользователь
может находиться в нескольких состояниях — новый, активный, временно
заблокированный или заблокированный, а также быть привязанным к
корзине покупок. Корзина принадлежит аккаунту.
Рис. 18.4. Пример диаграммы классов UML домена онлайн-покупок.
485
Аккаунт владеет заказами клиентов. У клиента может не быть заказов.
Заказы клиентов отсортированы и уникальны. Каждый заказ может
относиться к нескольким платежам, возможно, ни к одному. Каждый платеж
имеет уникальный идентификатор и относится только к одной учетной
записи.
Каждый заказ имеет текущий статус заказа. И в заказе, и в корзине есть
позиции, связанные с конкретным продуктом. Каждая позиция связана
только с одним продуктом. Продукт может быть связан со многими
позициями или вообще не связан с позициями.
1.5. Банковский счет
Назначение:
Модель
предметной
распространенные типы банковских счетов.
области,
описывающая
Резюме: В этом примере показано несколько подтипов банковского
счета с использованием наборов обобщения UML. Банковские счета могут
быть сгруппированы в наборы обобщения UML на основе различных
критериев. Примерная диаграмма показывает топологию банковских счетов с
двумя ортогональными измерениями и соответствующими типами
мощностей: Типом ответственности и Типом счета.
Это пример описания некоторых типов банковских счетов с
использованием наборов обобщения UML.
Банковские счета могут быть сгруппированы в наборы обобщения
UML на основе различных критериев. Примерная диаграмма ниже
показывает банковские счета, разделенные по типу пассива и типу счета. Эти
два ортогональных измерения также имеют соответствующие типы
мощности — LiabilityType и AccountType.
Банковский счет может быть использован как для личных, так и для
деловых целей. Чтобы показать, что он предполагает полное покрытие и нет
перекрытия, у нас есть ограничения типа ответственности, показанные как
{complete, disjoint}.
Обратите внимание, что владельцы бизнеса по-прежнему могут
использовать личный банковский счет для своих деловых целей, но это не
рекомендуется в первую очередь потому, что это может повлиять на
юридическую ответственность владельца бизнеса. С точки зрения банка,
например, при открытии счета, это два разных вида счетов.
Другая классификация банковских счетов основана на связанных
параметрах и функциях и показана ниже как набор обобщений типов счетов.
Чтобы показать, что этот набор неполный, но все же нет перекрытия, у нас
есть ограничения типа учетной записи, показанные как {incomplete, disjoint}.
486
Обратите внимание, что можно иметь банковские счета с различными
комбинациями обязательств по счету и типа счета, например, личный
сберегательный счет или счет делового денежного рынка (рис. 18.5.).
Рис. 18.5. Пример диаграммы классов UML таксономии банковских
счетов с наборами обобщения и типами мощности.
Цель сберегательного счета состоит в том, чтобы позволить нам
экономить деньги. Владелец счета может делать ограниченное количество
депозитов и снятия средств в месяц, при этом учетная запись не
предоставляет чеки. Банк обычно выплачивает процентную ставку, которая
выше, чем у расчетного счета, но ниже, чем у счета денежного рынка или
компакт-дисков.
Текущий счет — это банковский счет, который использует чеки как
способ снятия или перевода денег со счета — оплаты счетов, покупки
товаров, перевода или займа денег. Обычно банки позволяют владельцам
счетов снимать деньги и вносить депозиты через банкоматы. Базовые
расчетные счета, иногда называемые счетами без излишеств, предлагают
ограниченный набор услуг. Обычно они не выплачивают проценты, имеют
более низкий минимальный баланс, могут ограничивать выписку и/или
депонирование более определенного количества чеков в месяц. Проверка
счетов с процентами имеют более высокий требуемый минимальный
баланс, но платят проценты (на основе среднего поддерживаемого остатка) и
487
обычно предлагают более качественные услуги, например, позволяют
выписывать неограниченное количество чеков. Эти счета иногда называют
счетами оборотного порядка снятия (NOW).
Счет денежного рынка или депозитный счет денежного рынка
(MMDA) выплачивает проценты по более высокой ставке, чем ставка,
выплачиваемая
по
сберегательным
или
текущим
счетам
с
процентами. Рыночные счета обычно требуют более высокого минимального
баланса, чтобы счет начал приносить проценты, по сравнению с текущим или
сберегательным счетом. Снятие средств, разрешенное в месяц, очень
ограничено.
Депозитные сертификаты (CD), также известные как срочные
депозиты, представляют собой банковские счета, которые требуют, чтобы
владелец счета внес относительно крупный депозит и оставил средства на
счете на определенный согласованный период времени, обычно несколько
месяцев или лет. За досрочный вывод средств предусмотрен штраф. Из-за
этих ограничений проценты, выплачиваемые по CD, обычно выше, чем
проценты, выплачиваемые по другим типам банковских счетов.
На этой диаграмме UML показаны два особых случая: Детский
сберегательный счет и Медицинский сберегательный счет (HSA). Эти два
счета являются как личными счетами, так и сберегательными счетами.
Это проявляется как множественное наследование.
Детский сберегательный счет — это личный сберегательный счет,
который позволяет детям узнавать о денежных сбережениях, процентных
ставках и видеть, что это означает по отношению к их сбережениям.
Некоторые банки требуют ежемесячной платы или минимального остатка и
могут взимать комиссию, если счет неактивен или слишком много мелких
депозитов.
Медицинский сберегательный счет (HSA) — это личный
сберегательный счет, который позволяет лицам, охваченным планами
медицинского страхования с высокой степенью вычета, получать льготное
налогообложение денег, сэкономленных на будущие медицинские расходы.
1.6. Модель домена для больницы
Назначение: Модель домена для больницы, чтобы показать и
объяснить структуру больницы, персонал, отношения с пациентами и
терминологию лечения пациентов.
Резюме: модель предметной области для системы управления
больницей представлена несколькими диаграммами классов.
488
Доменная модель - это модель предметной области. В данном случае
предметной области - больницы, где в такой модели встречаются объекты,
например - палаты.
Палата — это отделение больницы или набор комнат, в которых живут
пациенты, нуждающиеся в аналогичном уходе. В больнице есть несколько
палат, каждая из которых может быть пустой или содержать одного, или
нескольких пациентов. Каждая палата имеет уникальное имя.
Врачи в больнице организованы в команды (также называемые
бригадами). Каждая команда имеет уникальное название или код (например,
ортопедия или педиатрия) и возглавляется врачом-консультантом или
лечащим врачом.
Это пример диаграммы модели предметной области больницы. Модель
предметной области для системы управления больницей представлена
несколькими диаграммами классов. Цель диаграммы — показать и
объяснить структуру больницы, персонал, отношения с пациентами и
терминологию лечения пациентов.
На диаграмме ниже человек может быть связан с разными больницами,
а больница может нанимать или обслуживать несколько человек. Класс
«Person» имеет производные атрибуты «name» и «homeAddress». Имя
представляет собой полное имя и может быть составлено из титула, имени
(или имени), отчества и фамилии (или фамилии). Класс пациента имеет
производный атрибут возраста, который можно рассчитать на основе даты
его или ее рождения и текущей даты или даты госпитализации.
Класс «Patient» наследует атрибуты класса «Person». Несколько
унаследованных атрибутов «name», «пол» и «BirthdayDate» показаны с
добавленным символом вставки ,Л' (новое обозначение, введенное в UML
2.5) (рис. 18.6.).
489
class Organization^
Person
title:
givenName;
middleName:
familyName:
/name:
birth Date:
gender:
/homeAddress:
phone:
Hospital
String
String
String
String
FullName
Date
Gender
Address
Phone
name: String {id}
/address: Address
phone: Phone
Department
Patient
id:
Strinq {id}
лпате:
FullName
flgender:
Gender
AbirthDate:
Date
/age:
Integer
accepted:
Date
sickness:
History
prescriptions: String)*]
allergies:
String)*]
speeialReqs: SringH
Staff
joined:
education:
certification:
languages:
Administrative
Staff
Operations
Staff
Doctor
Front Desk
Staff
Nurse
specialty: String!*]
locations: String)*]
Surgeon
Date
String [*1
String [•]
String!*]
Receptionist
Technical
Staff
Technician
Technologist
Surgical
Technologist
Рис. 18.6. Модель предметной области организации больницы - Пациент,
Больница, Персонал - Операционный, Административный,
Технический.
Палата — это отделение больницы или набор комнат, в которых живут
пациенты, нуждающиеся в аналогичном уходе. В больнице есть несколько
палат, каждая из которых может быть пустой или содержать одного, или
нескольких пациентов. Каждая палата имеет уникальное имя. На диаграмме
ниже это показано с использованием модификатора {id} для имени
подопечного.
Палаты различаются по полу пациентов, т.е. мужские и женские
палаты. В отделение могут поступать только пациенты того пола. Пол
показан перечислением. У подопечного и пациента есть ограничения по
полу.
Каждая палата имеет фиксированную вместимость, которая
представляет собой максимальное количество пациентов, которые могут
находиться в ней одновременно (т. е. вместимость — это количество коек в
палате). Разные палаты могут иметь разную вместимость.
490
Врачи в больнице организованы в команды (также называемые
фирмами) (рис. 18.7.). Каждая группа имеет уникальное название или код
(например, ортопедия или педиатрия) и возглавляется врачом консультантом (в Великобритании, Ирландии и некоторых странах
Содружества) или лечащим врачом (также известным как штатный врач) (в
Соединенных Штатах). Состояния). Врач-консультант или лечащий врач это старший врач, прошедший всю свою специальную подготовку,
ординатуру и практикующий врач в клинике или больнице по специальности,
полученной во время ординатуры. Она или он может контролировать
стипендиатов, резидентов и студентов-медиков. Вся остальная команда —
младшие врачи. Каждый врач мог быть членом не более чем одной бригады.
Рис. 18.7. Больничные палаты, бригады врачей и пациентов.
Каждый пациент находится в отдельной палате и находится под
наблюдением одной бригады врачей (рис. 18.8.). Пациента может лечить
любое количество врачей, но все они должны быть в команде, которая
заботится о пациенте. Врач может лечить любое количество пациентов.
Руководитель бригады берет на себя окончательную ответственность, как
юридическую, так и иную, за лечение всех направленных к нему пациентов,
даже если многие ежеминутные решения принимаются подчиненными.
491
Рис. 18.8. Модель предметной области - пациент, врачи и лечение.
1.7. Цифровая визуализация в медицине — DICOM-модель реального
мира
Назначение: представить модель предметной области («модель
реального мира») для цифровых изображений и коммуникаций в медицине
(DICOM) — пациент, визит, учреждение, запрос на визуализацию, этап
запланированной процедуры, этап выполненной процедуры модальности.
Резюме: Пример диаграммы UML представляет расширенный домен
DICOM, абстрактное описание объектов реального мира, используемых в
интерфейсе Modality-IS. Модальность — это часть оборудования для
медицинской визуализации, например, компьютерная томография (КТ) или
ультразвуковое исследование (УЗИ).
492
Пример диаграммы классов, представляющей модель предметной
области («модель реального мира») для цифровых изображений и
коммуникаций в медицине (DICOM). Эта диаграмма основана на модели ER
Рис. 7-3 стандарта DICOM Часть 3 - PS 3.3-2009.
Диаграмма представляет расширенный домен DICOM, абстрактное
описание объектов реального мира, используемых в интерфейсе Modality-IS.
Модальность — это часть оборудования для визуализации, например,
компьютерная томография (КТ) или УЗИ (УЗИ).
Пациент — это человек или животное, получающее или
зарегистрированное для получения медицинских услуг, или являющееся
объектом научных исследований. Клинический документ является частью
истории болезни пациента. Это документация клинических наблюдений и
услуг, оказанных пациенту.
Эпизод обслуживания — это набор событий, контекст, в котором
происходит лечение или ведение произвольного подмножества заболеваний
пациента. Служебный эпизод совершенно произволен; оно может включать
однократное амбулаторное посещение или госпитализацию, либо длиться в
течение значительного периода времени, например, во время беременности
или в режиме лечения онкологических заболеваний. Эпизод обслуживания
может включать одну или несколько организаций здравоохранения
(административные
органы,
которые
разрешают
поставщикам
медицинских услуг предоставлять услуги в рамках их административно­
правовой сферы, например, больницы, частные врачебные кабинеты,
многопрофильные клиники, дома престарелых) (рис. 18.9.).
493
Рис. 18.9. Модель домена DICOM для примера диаграммы классов UML
интерфейса Modality-IS.
Визит - это часть служебного эпизода, совокупность событий,
находящихся в ведении конкретной организации здравоохранения в одном
учреждении. Посещение может быть связано с одним или несколькими
физическими местами (например, разными комнатами, отделами или
зданиями) в одном и том же учреждении.
Запрос службы визуализации представляет собой набор из одной или
нескольких запрашиваемых процедур, выбранных из списка типов
процедур. Запрос службы обработки изображений подается одним
авторизованным заказчиком услуги обработки изображений одному
авторизованному поставщику услуг обработки изображений в контексте
одного эпизода обслуживания. Запрос на визуализацию может быть связан с
одним или несколькими посещениями, происходящими в рамках одного и
того же эпизода обслуживания.
494
Шаг запланированной процедуры модальности — это произвольно
определенная запланированная единица обслуживания, указанная в Плане
процедуры для запрашиваемой процедуры. Он предписывает протокол,
который может быть идентифицирован одним или несколькими кодами
протокола. Этап запланированной процедуры модальности включает в себя
оборудование (например, оборудование для визуализации, хирургическое
оборудование и т. д.), человеческие ресурсы, расходные материалы, место и
время.
Шаг выполненной процедуры по модальности — это произвольно
определенная единица услуги, которая фактически была выполнена (а не
только запланирована). Он содержит ссылки на ноль или более серий
изображений.
1.8. API хостинга приложений DICOM
Назначение: пример диаграммы классов UML, представляющей API
хостинга приложений DICOM, определенный в части 19 стандарта DICOM
(PS 3.19-2011). Application Hosting API описывает интерфейсы между двумя
программными приложениями — Hosting System и Hosted Application,
которые обмениваются медицинскими данными, находясь в одной системе.
Резюме: API хостинга приложений DICOM определяет три
интерфейса: интерфейс Application, Host и DataExchange. Хостинг-система
предоставляет различные услуги, такие как извлечение и хранение объектов
DICOM для размещенного приложения. Последние процессы предоставляли
медицинские данные, потенциально возвращая некоторые вновь
сгенерированные наборы данных.
Пример диаграммы классов, представляющей DICOM Application
Hosting API. API хостинга приложений DICOM был опубликован в
Стандарте цифровых изображений и коммуникаций в медицине (DICOM),
часть 19 Хостинг приложений (PS 3.19-2011). Пример, показанный ниже,
является нашей собственной интерпретацией API. Официальное описание и
схемы см. в стандарте DICOM.
Часть 19 стандарта DICOM определяет интерфейс прикладного
программирования (API) между двумя программными приложениями —
Hosting System и Hosted Application, причем оба приложения обмениваются
медицинскими данными, находясь в одной системе.
Хостинг -система (хост) (также известная как хост-приложение) — это
приложение, используемое для запуска и управления размещенными
приложениями. Хостинг-система предоставляет множество услуг, таких как
поиск и хранение объектов DICOM для размещенного приложения. Хостинг495
система предоставляет инфраструктуру, в которой размещенное приложение
работает и взаимодействует с внешней средой. Это включает доступ к сети,
базу данных и безопасность. Хост-приложение предоставляет размещенному
приложению данные, такие как набор медицинских изображений и
соответствующие метаданные.
Размещенное приложение (Application) — это приложение,
запускаемое и управляемое системой хостинга, которое также может
использовать некоторые услуги, предлагаемые системой хостинга. Процессы
размещенных
приложений
предоставляли
медицинские
данные,
потенциально возвращая некоторые вновь сгенерированные данные,
например, в виде другого набора изображений и/или структурированных
отчетов, в приложение размещения.
Хост-система имеет механизм для запуска или подключения к одному
или нескольким размещенным приложениям, проверки того, что
размещенное приложение успешно запущено, а затем передачи исходных
объектов данных. Все взаимодействия начинаются в системе хостинга (рис.
18.10.).
496
Рис.18.10. Пример диаграммы классов UML DICOM Application Hosting
API.
API хостинга приложений DICOM определяет три интерфейса.
Интерфейс приложения («interface» Application) инкапсулирует
размещенное приложение и вызывается хост-системой для управления
размещенным приложением. Метод getState() позволяет запрашивать
размещенное приложение о его текущем состоянии. Хостинг-система может
запросить размещенное приложение для переключения в новое состояние с
помощью метода setState(). Вызывая метод BringToFront(), хост-система
может попросить размещенное приложение сделать его графический
интерфейс видимым в качестве самого верхнего окна и получить фокус.
Хост - интерфейс («interface» Host) представляет собой хост-систему и
используется размещенным приложением для запроса услуг и уведомления
хост-системы о событиях во время выполнения размещенного приложения.
497
Например, хост-система может создать новый UID DICOM для
использования размещенным приложением. Размещенное приложение может
информировать систему размещения о заметных событиях, происходящих во
время выполнения, путем вызова метода notifyStatus().
Интерфейс DataExchange («interface» DataExchange) — это
интерфейс, который используется как хост-системой, так и хостприложением для прямого или косвенного обмена медицинскими данными,
поэтому он должен быть реализован ими обоими. Данные, которыми
обмениваются хост-система и размещенное приложение, могут быть
переданы в виде файлов или описаны в моделях, которые могут быть
запрошены получателем. Методы на основе моделей могут работать с
различными моделями, которые могут быть либо некоторой абстракцией
данных, либо могут быть моделью некоторого собственного формата,
включая модели, определенные стандартом DICOM. Конкретные модели
идентифицируются по UID и описываются как XML Infosets, даже если
исходные данные могут никогда не быть фактически представлены в форме
XML.
API размещения приложений DICOM использует класс-оболочку
ArrayOf [Type] для представления массива определенного типа «для
обеспечения межплатформенной совместимости». В приведенном здесь
примере диаграммы UML вместо этого используется стандартная
множественность UML.
1.9. Домен лицензирования программного обеспечения Sentinel HASP
Назначение: Диаграмма предметной области предназначена для
демонстрации основных «элементов», используемых в процессе
лицензирования и защиты программного обеспечения с использованием
Sentinel HASP, а также взаимосвязей между этими элементами.
Резюме: Когда поставщик программного обеспечения приобретает
Sentinel HASP LDK, ему предоставляется уникальный пакетный код и
соответствующий ключ поставщика. Каждый защищенный программный
продукт имеет некоторые особенности и связан с пакетным кодом. Право
может содержать один или несколько продуктов и связано с клиентом,
разместившим заказ. Заказчиком может быть, как индивидуальный клиент,
так и компания.
Пример диаграммы классов UML, которая обеспечивает упрощенное
представление домена лицензирования программного обеспечения для
SafeNet Sentinel HASP Software Licensing Security Solution.
498
Цель диаграммы предметной области — показать основные «вещи»,
используемые во время лицензирования и защиты программного
обеспечения с помощью Sentinel HASP, и отношения между этими вещами.
Когда поставщик программного обеспечения приобретает пакет
разработки лицензий Sentinel HASP (LDK), ему также предоставляется
уникальный пакетный код и соответствующий ключ поставщика, который
содержит уникальный код поставщика, специфичный для компании. Этот
код используется Sentinel LDK для связи с ключами защиты и для того,
чтобы отличать ключи поставщика от ключей других поставщиков
программного обеспечения.
Пакетный код состоит из пяти символов, представляющих уникальный
код поставщика компании. Когда ключи защиты Sentinel заказываются в
SafeNet, пакетный код записывается в ключи перед отправкой поставщику.
Батч-код также написан на внешней стороне каждого ключа.
Функция — это некоторая идентифицируемая функциональность
программного приложения.
Функции могут использоваться для
идентификации целых исполняемых файлов, программных модулей, методов
.NET или Java или определенных функций, таких как печать или сохранение.
Каждой функции присваивается уникальный идентификатор и связывается с
определенным батч-кодом. Идентификатор функции, и имя функции должны
быть уникальными в соответствующем пакете. Максимальная длина имени
функции составляет 50 символов.
Каждый защищенный программный продукт имеет некоторые
особенности и связан с пакетным кодом. Имя продукта, которое
идентифицирует продукт, является уникальным в выбранной партии.
Максимальная длина имени продукта — 50 символов. Продукт имеет
определенный тип блокировки (тип типа защиты), который должен быть
применен к продукту.
Основной единицей, на которой создаются все продукты, является
базовый продукт. Базовый продукт может содержать все атрибуты
продукта, такие как функции, лицензионные данные и память, и может
использоваться как продукт, предлагаемый для продажи. Предварительные
продукты также могут распространяться как пробные версии. Свойства
временных продуктов не полностью идентичны свойствам базового
продукта. После определения продукта его можно включить в права (заказы)
(рис. 18.11.).
499
Рис. 18.11. Пример диаграммы домена (класса) UML для Sentinel HASP
Software Licensing Security Solution.
Право — это заказ на поставку продуктов с одним или несколькими
ключами защиты Sentinel. Заказы или отдел продаж получает и выполняет
права. Персонал по обработке заказов обрабатывает данные о правах с
помощью Sentinel EMS. Право может содержать один или несколько
продуктов. Когда право определяется в Sentinel EMS, они могут указать
клиента,
разместившего
заказ.
Заказчиком
может
быть,
как
индивидуальный клиент, так и компания.
Тип блокировки, назначенный продукту, может определять тип
разрешения, которое может быть создано. Они не могут добавить продукт,
определенный только с типом блокировки HL, и другой продукт,
определенный только с типом блокировки SL (будь то AdminMode или
UserMode) в одно и то же право:
•
Продукты, определенные только с типом блокировки HL, могут быть
включены в права на ключи HASP HL, ключи продуктов или
обновления ключей защиты.
•
Продукты, определенные только с типом блокировки SL AdminMode
или SL UserMode, могут быть включены только в права на ключи
продуктов или обновления ключей защиты.
500
•
Продукты, определенные с типом блокировки HL или SL AdminMode,
или HL, или SL AdminMode, или SL User-Mode, могут быть включены
в права на ключи HASP HL, ключи продуктов или обновления ключей
защиты.
1.10. Java.util.concurrent
Назначение: Примеры диаграмм классов UML, представляющих
наиболее важные интерфейсы и классы Java™ util.concurrent API. Несколько
пакетов java.util.concurrent.* поддерживают высокоуровневые функции
параллелизма в Java с новыми параллельными структурами данных в среде
коллекций Java.
Резюме: Исполнители определяют высокоуровневый API для запуска и
управления потоками для поддержки крупномасштабных приложений, в
основном путем добавления возможностей управления пулом потоков.
Параллельные коллекции уменьшают потребность в синхронизации и
предназначены для поддержки одновременного доступа и модификации
больших коллекций данных. Интерфейс Future<V> представляет результат
асинхронного вычисления.
Здесь приведено несколько диаграмм классов UML для пакета
Java™ 7 java.util.concurrent. Несколько пакетов java.util.concurrent,
представленных в версии 5.0 платформы Java, добавили высокоуровневые
функции параллелизма в Java и новые параллельные структуры данных в
Java Collections Framework (рис. 18.12.).
501
Рис. 18.12. Диаграмма классов UML для исполнителей Java™ 7 и
менеджеров пулов потоков из пакета java.util.concurrent
Исполнители определяют высокоуровневый API для запуска и
управления потоками для поддержки крупномасштабных приложений, в
основном за счет добавления возможностей управления пулом потоков
(рис. 18.13.). Пакет java.util.concurrent включает несколько классов
реализации управления пулом потоков.
502
Рис. 18.13. Диаграмма классов UML для параллельных коллекций из
пакета Java 7 java.util.concurrent
Параллельные коллекции также являются частью пакета
java.util.concurrent (рис. 18.14.). Эти коллекции уменьшают потребность в
синхронизации и предназначены для поддержки одновременного доступа и
модификации больших коллекций данных.
503
java.util.concurrent
________ ! ~ I
«interfaces—i—'
Comparable
«interface»
Delayed
-—I v
«interface»—r —1
Future
«interface»
Runnable
\z\
«interface» T ~'
ScheduledFuturo
1 „ 1
1
|
«interface» T—
RunnableFuture
«Interfaces!—r —1
Callable
z
—------------ 1 v
«interface» —r —1
RunnableScheduled
Future
—
/
/
—
1 v 1
1
Futu reTask I
Рис. 18.14. UML диаграмма классов для асинхронных результатов
(фьючерсов) из пакета Java 7 java.util.concurrent.
Интерфейс Future <V> представляет результат асинхронного
вычисления, где тип V — это тип результата, возвращаемый методом get
Future. Методы этого интерфейса позволяют дождаться завершения
вычислений, отменить выполнение задачи, проверить завершено ли
вычисление или оно было отменено, а также получить результат вычисления.
Интерфейс Delayed позволяет отмечать объекты, над которыми следует
действовать после заданной задержки. Интерфейс ScheduledFuture<V>
расширяет возможности Future<V> и Delayed и обычно является результатом
планирования задачи с помощью ScheduledExecutorService.
Класс FutureTask — это реализация Future, реализующая java.lang.
Выполняется в соответствии с требованиями интерфейса RunnableFeature и,
таким образом, может выполняться исполнителем.
1.11. Классы реализации камеры Android
Назначение: пример диаграммы классов UML уровня реализации для
иллюстрации использования Android Camera API (платформа Android 3.1,
уровень API 12).
Резюме: Класс CameraDemo расширяет класс Activity Android. Activity
— это отдельная целенаправленная вещь, которую пользователь может
делать с Android. Activity обычно взаимодействует с пользователем, и класс
Activity заботится о создании окна, в котором мы можем разместить наш
пользовательский интерфейс. Действие CameraDemo создаст объект Preview
и будет содержать ссылку на него. Предварительный просмотр удерживает
504
ссылку на действие как на его контекст. Объект Preview создаст объект
Camera и вернет его активности CameraDemo.
Этот пример представляет собой диаграмму классов уровня
реализации, на которой показаны некоторые классы, использующие Android
Camera API (платформа Android 3.1, уровень API 12). Подробную
информацию об API можно найти в классе аппаратной камеры Android.
Пример реализации, которому мы следуем, описан в разделе Использование
Android Camera API.
CameraDemo расширяет активность Android. Действие — это
отдельная целенаправленная вещь, которую пользователь может делать с
Android. Activity обычно взаимодействует с пользователем, и класс Activity
заботится о создании окна, в котором мы можем разместить наш
пользовательский интерфейс. Действие CameraDemo создаст объект Preview
и будет содержать ссылку на него. Предварительный просмотр удерживает
ссылку на действие как на его контекст. Объект Preview создаст объект
Camera и вернет его активности CameraDemo.
Класс Camera — это аппаратный класс Android, используемый для
получения/создания объектов класса Camera, настройки параметров захвата
изображения, запуска или остановки предварительного просмотра, съемки
изображений и т. Д (рис. 18.15.). Класс Camera не является
потокобезопасным и должен использоваться из одного потока событий. Этот
класс является клиентом для службы камеры, которая управляет
фактическим оборудованием камеры.
505
Рис. 18.15. Пример диаграммы классов UML для демонстрационной
реализации камеры Android
Нам потребуется зарегистрировать некоторые методы обратного
вызова, которые будут вызываться камерой асинхронно после вызова метода
takePicture и открытия затвора, съемки изображения и готовности данных
изображения.
SurfaceHolder — это интерфейс, реализуемый объектами,
удерживающими поверхность дисплея. Это позволяет нам управлять
размером и форматом поверхности, редактировать пиксели на поверхности,
отслеживать изменения поверхности, получать прямой доступ к объекту
поверхности и т. д. Интерфейс SurfaceHolder.Callback позволяет получать
информацию об изменениях поверхности.
1.12. Лицензирование Sentinel HASP пакета Aladdin
Назначение: показать детали реализации нескольких классов HASP,
реализующих компонент HASP Java Native Interface Proxy.
Резюме: в пакет HASP Aladdin входят 4 класса. Эти классы являются
реализацией компонента HASP Java Native Interface Proxy, который вы
можете найти на диаграмме компонентов лицензирования Sentinel HASP.
506
Это пример диаграммы классов уровня реализации UML, на
которой показаны классы HASP, включенные в пакет Aladdin. Эти
классы представляют собой реализацию компонента HASP Java Native
Interface Proxy, который вы можете увидеть на диаграмме компонентов
лицензирования Sentinel HASP.
API лицензирования SafeNet Sentinel LDK 6.1 (реализованный на
нескольких языках) включает:
•
структурные объявления и информация об отдельных функциях
Sentinel Licensing API,
•
описание тегов XML, которые можно использовать для определения
области действия и формата вывода различных функций API,
•
описание всех кодов возврата API.
Пакет Aladdin предоставляет интерфейс Java для собственной
библиотеки, реализующей Sentinel LDK 6.1 Licensing API (рис. 18.16.).
Рис. 18.16. Диаграмма классов для пакета Aladdin, реализующего
Sentinel LDK 6.1 Licensing API на Java.
507
HASP Java API включает в себя 4 класса Java: Hasp, HaspApiVersion,
HaspTime и HaspStatus, которые являются частью пакета Aladdin. Эти классы
объединены в артефакт HASPJava.jar. Классы HASP Java API загружают и
связывают нативные методы из нативной библиотеки для конкретной
платформы.
Основной класс HASP Java API — Hasp. Этот класс позволяет войти
или выйти из ключа защиты программного обеспечения для конкретного
ключа или области действия поставщика (см. пример 1.9. домен Sentinel
HASP), зашифровать или расшифровать некоторые байты данных лицензии,
получить информацию о ключе защиты, часах реального времени и т. д. Этот
класс использует HaspApiVersion, HaspTime и классы HaspStatus.
508
2. ПРИМЕРЫ UML ДИАГРАММЫ ОБЪЕКТОВ.
2.1. Схема объекта контроллера входа в веб-приложение
Назначение: пример диаграммы объектов UML, на которой показаны
некоторые объекты среды выполнения, участвующие в процессе входа в
систему для веб-пользователя.
Резюме: экземпляр класса контроллера входа связан с экземплярами
диспетчера пользователей, диспетчера файлов cookie и регистратора.
Контроллер входа в систему, диспетчер пользователей и DAO пользователя
Hibernate (объект доступа к данным) совместно используют один экземпляр
Logger.
Это пример диаграммы объектов, на которой показаны некоторые
объекты среды выполнения, связанные с процессом входа в систему веб­
пользователя. Экземпляр класса loginCtrl контроллера входа имеет
несколько слотов со структурными особенностями типов Integer и String и
соответствующими спецификациями значений.
Экземпляр LoginController также связан с экземплярами UserManager,
CookieManager и Logger. LoginController, UserManager и HibernateUserDAO
(объект доступа к данным) совместно используют один экземпляр Logger
(рис. 19.1.).
509
Рис. 19.1. Пример диаграммы объекта UML контроллера входа
пользователя
UserManager имеет закрытый атрибут defaultURI, который
представляет собой упорядоченную коллекцию (массив) из 5 уникальных
строк. Экземпляр CookieManager имеет две общедоступные структурные
функции с указанными значениями. По большинству ссылок нельзя
перемещаться в обратном направлении.
510
3. ПРИМЕРЫ UML ДИАГРАММЫ ИНФОРМАЦИОННЫХ
ПОТОКОВ.
3.1. Поток информации о запланированном рабочем процессе для
Технической основы радиологии IHE
Назначение: Показать информационный поток, связанный с
радиологическими исследованиями, включая регистрацию пациентов, заказ
рентгенологических исследований, планирование исследований, получение
изображений, хранение изображений и действия по просмотру.
Резюме: В приведенном ниже примере схемы потока информации
UML показан упрощенный поток информации на основе профиля
интеграции запланированного рабочего процесса из Технической основы
радиологии IHE.
Диаграммы информационных потоков являются вспомогательными
диаграммами UML версии 2.x, которые можно использовать для описания
циркуляции информации в системе в общем виде.
Запланированный рабочий процесс (SWF) объединяет действия по
заказу, планированию, получению изображений, хранению и просмотру,
связанные с рентгенологическими исследованиями (рис. 20.1.).
Системы, задействованные в этом профиле:
(ADT)/регистрации
•
Система
госпитализации-выписки-перевода
пациентов
•
Больничная информационная система (HIS)
•
Информационная система радиологии (RIS)
•
Система архивирования и передачи изображений (PACS)
•
Способ получения изображения
511
Рис. 20.1. Пример схемы потока информации для запланированного
рабочего процесса в радиологии.
Прием-Выписка-Перевод (ADT) /Регистрация пациентов — это
общекорпоративная
информационная
система,
которая
управляет
регистрацией пациентов и заказами услуг, отвечает за добавление и/или
обновление демографических данных пациентов и сведений о встречах. В
частности, он регистрирует нового пациента в системе размещения заказов и
отделений.
Метод сбора данных — это система, которая получает и создает
медицинские изображения в присутствии пациента, например, с помощью
компьютерного томографа (КТ), камеры УЗИ или ядерной медицины
(ЯМ). Модальность может также создавать другие объекты свидетельств,
такие как состояния представления мягкой копии в оттенках серого (GSPS)
для последовательного просмотра изображений или документов
свидетельств, содержащих измерения.
Направляющий врач - это врач, который направляет пациента в
рентгенологическое отделение или клинику для обследования.
512
Рентгенолог — это врач, прошедший специальную подготовку по
получению и интерпретации медицинских изображений с помощью методов
получения изображений. Рентгенолог сопоставляет результаты медицинских
снимков с другими обследованиями и тестами, рекомендует дальнейшие
обследования
или
лечение
и
консультируется
с
лечащим
врачом. (Рентгенологи также лечат болезни с помощью излучения, но это не
является частью описанного рабочего процесса.)
513
4. ПРИМЕРЫ UML ДИАГРАММЫ МОДЕЛИ.
4.1. Многоуровневое приложение на основе Руководства по архитектуре
приложений Microsoft, 2-е изд.
Пример
схемы
модели
UML,
представляющей
модель
многоуровневого приложения на основе Руководства по архитектуре
приложений Microsoft, 2-е изд.
Согласно Руководству, уровни связаны с логическим разделением
компонентов и функций и не учитывают физическое расположение
компонентов, тогда как уровни описывают физическое распределение
функций и компонентов на отдельных серверах, компьютерах, в сетях или на
удаленных серверах. места. Слои могут располагаться на разных уровнях или
на одном уровне.
Модель приложения показывает несколько уровней — уровень
представления, уровень услуг, бизнес-уровень, уровень данных и сквозные
уровни. Все слои представлены в виде UML- моделей (рис. 21.1.).
514
Рис. 21.1. Пример схемы модели многоуровневого приложения UML.
Пользователи и внешние системы также представлены в виде моделей
и взаимодействуют с уровнями представления и служб соответственно. На
диаграмме также показаны источники данных, такие как реляционные базы
данных и агенты веб-служб, которые обеспечивают доступ к данным, а также
внешние или удаленные службы, используемые приложением.
Сквозной уровень содержит общие функции, охватывающие уровни и
уровни. Эта функциональность обычно поддерживает аутентификацию,
авторизацию, кэширование, обмен данными, управление исключениями,
515
ведение журнала и
инструментирование,
а
также проверку.
функциональность обычно описывается как сквозная.
516
Такая
5. ПРИМЕРЫ UML ДИАГРАММЫ РАЗВЕРТЫВАНИЯ.
5.1. UML диаграмма проявления компонентов артефактами для веб­
приложения
Назначение: Пример диаграммы проявления для веб-приложения.
Резюме: Артефакт архива веб-приложения book_club_app.war содержит
несколько файлов, папок и подпапок. На диаграмме показаны несколько
компонентов, представленных (реализованных) архивными файлами jar.
Это пример диаграммы развертывания UML, которая показывает
проявление компонентов артефактами и внутреннюю структуру артефактов
(рис. 22.1.). Но авторы назвали бы такого рода диаграммы развертывания диаграммами проявления или диаграммами реализации, поскольку на
самом деле они не показывают никакого развертывания.
«folder» META-1 NF
«file»
manifestmf
«library»
shp-cartjar
«library»
customers.jar
-------- i--------
I
1
I
I
+
I
IShoppingCart
О---- □ «component»
Shopping Cart
I
:
----- 1-----i
c
«component»
Customers
Рис. 22.1. Пример диаграммы проявления для веб-приложения
Артефакт
архива
веб-приложения
book_club_app.war
содержит
несколько файлов, папок и подпапок. Стереотипы «файл» и «библиотека»
являются стандартными стереотипами UML, применимыми к артефактам. На
517
этой диаграмме также показана нестандартная стереотипная «папка», которая
визуализируется как пакет.
На диаграмме показаны несколько компонентов, представленных
(реализованных) архивными файлами jar.
5.2. Пример схемы развертывания UML для веб-приложения
Цель: Пример схемы развертывания UML для веб-приложения.
Резюме: Артефакт веб-приложения книжного клуба book_club_app.war
развернут в контейнере Catalina Servlet 2.4 / JSP 2.0, который является частью
веб-сервера Apache Tomcat 5.5. Пример UML- схемы развертывания веб­
приложения. Артефакт веб-приложения книжного клуба book_club_app.war
развернут в контейнере Catalina Servlet 2.4/JSP 2.0, который является частью
веб-сервера Apache Tomcat 5.5.
Артефакт book_club_app.war манифестирует (воплощает) компонент
OnlineOrders. Артефакт содержит три других артефакта, один из которых
представляет компонент UserServices.
«Устройство»
Сервера
приложений
(компьютерный
сервер
-
Application Server «device») имеет канал связи с «устройством» Сервера баз
данных (другой сервер - Database Server «device») (рис. 22.2.).
518
Рис. 22.2. Пример схемы развертывания веб-приложения J2EE.
5.3. Сбалансированное по нагрузке и кластерное развертывание
веб-приложения J2EE
Назначение: пример диаграммы развертывания веб-приложения J2EE
с балансировкой
нагрузки и кластеризацией, на которой показаны
задействованные экземпляры конкретных серверов.
Резюме:
Входящие HTTP-запросы сначала обрабатываются веб­
сервером Apache. Статическое содержимое, такое как HTML-страницы,
изображения, CSS и JavaScript, обслуживается веб-сервером. Запросы к JSP-
страницам распределяются по нагрузке и перенаправляются на два сервера
Apache Tomcat с использованием как вертикальной, так и горизонтальной
кластеризации.
Пример
балансировкой
диаграммы
нагрузки
развертывания
и
веб-приложения
кластеризацией,
на
которой
J2EE
с
показаны
задействованные экземпляры конкретных серверов.
Входящие HTTP-запросы сначала обрабатываются веб-сервером
Apache. Статическое содержимое, такое как HTML-страницы, изображения,
CSS и JavaScript, обслуживается веб-сервером. Запросы к JSP-страницам
519
распределяются по нагрузке и перенаправляются на два сервера Apache
Tomcat с использованием как вертикальной,
так и горизонтальной
кластеризации.
Все 4 экземпляра серверов Apache Tomcat сохраняют/получают данные
в/из одного экземпляра СУБД Oracle 11g, что может стать узким местом в
производительности, если веб-приложение интенсивно использует данные
(рис. 22.3.).
Рис. 22.3. Сбалансированное по нагрузке и кластерное развертывание
веб-приложения J2EE.
5.4. Балансировка нагрузки веб-серверов J2EE
Назначение: Пример схемы развертывания UML с аппаратной и
программной балансировкой нагрузки и кластерами.
520
Резюме: В примере показаны 2 активных аппаратных балансировщика
нагрузки, подключенных к 2-4 серверам Sun Fire. На каждом сервере
установлено 3 экземпляра серверов приложений IBM WebSphere 7 J2EE.
Пример
схемы развертывания
с
аппаратной
и
программной
балансировкой нагрузки и кластерами.
Балансировщик сетевой нагрузки — это устройство,
которое
используется для распределения сетевой нагрузки между несколькими
серверами (рис. 22.4.). В примере показан аппаратный балансировщик
нагрузки jetNEXUS ALB-X. Оно сочетает в себе функции балансировки
нагрузки уровня 7 OSI (прикладного уровня), сжатия HTTP, разгрузки SSL и
кэширования контента в одном решении.
Рис. 22.4. Пример схемы развертывания UML с аппаратной
балансировкой нагрузки серверов J2EE.
Показанная
конфигурация
включает
2
активных
аппаратных
балансировщика нагрузки, подключенных к 2-4 серверам Sun Fire. На
каждом сервере установлено по 3 экземпляра серверов приложений IBM
WebSphere 7 J2EE,
поэтому у нас
есть как вертикальная,
так и
базой
данных,
горизонтальная кластеризация.
Когда
приложение
запрашивает
соединение
с
балансировка нагрузки соединения Oracle во время выполнения выбирает
521
соединение, которое принадлежит лучшему экземпляру, из кэша соединений,
предоставляемого базой данных Oracle RAC (Real Application Clusters).
5.5. Схема развертывания Apple iTunes UML
Назначение: Пример схемы развертывания приложения Apple iTunes.
Резюме: Приложение Apple iTunes взаимодействует с Apple iTunes
Store. Клиент может покупать и скачивать музыку, видео, сериалы,
аудиокниги и т. д. и хранить их в медиатеке. Мобильные устройства, такие
как Apple iPod Touch и Apple iPhone, обновляют медиатеки с домашнего
компьютера с помощью iTunes через USB или могут загружать медиафайлы
непосредственно из Apple iTunes Store, используя какой-либо беспроводной
протокол.
Ниже представлен пример схемы развертывания приложения Apple
iTunes (рис. 22.5.).
«device»
Apple Web Server
«device»
Home Computer
«website»
ITunes
v
\
Media
Library
-■
\
«protocol»
HTTP
«web browser»
«deploy»'^
\
USB
Media libraries are
synchronized
between devices by
iTunes
i
«application»^)
iTunes
«protocol»
iTunes Store protocol
«website»
iTunes Store
«mobile
device»
«wireless protocol»
iTunes Store protocol
Media
Library
«application» ^)
iTunesSetup.exe
Media
Library
«OS»
iPhone OS
Рис. 22.5. Пример схемы развертывания UML для Apple iTunes.
Приложение для установки iTunes можно загрузить с веб-сайта iTunes
и установить на домашний компьютер. После установки и регистрации
522
приложение iTunes могло обмениваться данными с Apple iTunes Store.
Клиент может покупать и загружать музыку, видео, телешоу, аудиокниги и т.
д. и хранить их в медиатеке.
Мобильные устройства, такие как Apple iPod Touch и Apple iPhone,
могут обновлять собственные медиатеки с домашнего компьютера с
помощью
iTunes
через
USB
или
могут
загружать
медиафайлы
непосредственно из Apple iTunes Store, используя какой-либо беспроводной
протокол, такой как Wi-Fi, 3G или EDGE.
5.6. Развертывание Android-приложения
Назначение: Пример диаграммы развертывания для развертывания
приложения Android.
Резюме: инструменты Android SDK компилируют и упаковывают код
вместе со всеми необходимыми файлами данных и ресурсов в архивный
файл
приложения
Android.
Файл
архива
представляет
собой
одно
приложение Android, которое будет развернуто на мобильных устройствах с
поддержкой Android.
Это пример схемы развертывания UML, на которой показано
развертывание приложения на Android.
Android — это программный стек для мобильных устройств,
включающий операционную систему, промежуточное ПО и ключевые
приложения. Android использует ОС Linux для основных системных служб,
таких как безопасность, управление памятью, управление процессами,
сетевой стек и модель драйвера. Ядро Linux также действует как уровень
абстракции между аппаратным обеспечением и остальным программным
стеком.
Приложения для Android пишутся на Java. Инструменты Android
SDK компилируют и упаковывают код вместе со всеми необходимыми
файлами данных и ресурсов в архивный файл приложения Android с
523
суффиксом .apk. Файл .apk представляет собой одно приложение Android,
которое необходимо развернуть на мобильных устройствах с поддержкой
Android (рис. 22.6.).
Рис. 22.6. Пример развертывания приложения на Android.
Приложения Android состоят из одного или нескольких компонентов
приложения (действий, служб, поставщиков контента и приемников
вещания). Каждый компонент выполняет свою роль в общем поведении
приложения, и каждый из них может быть активирован индивидуально (даже
другими приложениями).
Файл манифеста (спецификации развертывания) AndroidManifest.xml
описывает требования к приложению, такие как минимальная требуемая
версия Android и любые поддерживаемые конфигурации оборудования, а
также объявляет все компоненты в приложении.
С Android API уровня 8 или выше приложение можно установить на
внешнее хранилище (например, на SD-карту). Это необязательная функция,
524
которую можно запросить для конкретного приложения с помощью атрибута
манифеста. По умолчанию приложение устанавливается во внутреннюю
память мобильного устройства и не может быть перемещено во внешнее
хранилище.
5.7. Пример сетевой диаграммы домашней сети
Назначение: UML не предоставляет специального вида диаграмм для
описания логической или физической сетевой архитектуры проектируемой
или существующей системы. Для этой цели можно использовать диаграммы
развертывания с элементами, ограниченными в основном устройствами, на
которых не показаны ни артефакты, ни фактическое развертывание.
Резюме: В этом примере схемы сети показана сетевая архитектура с
конфигурацией, обычно называемой «демилитаризованной зоной с двумя
брандмауэрами (DMZ)». DMZ — это узел или сегмент сети, расположенный
в «нейтральной зоне» между Интернетом и внутренней сетью организации
(частной сетью). Это предотвращает получение внешними пользователями
прямого доступа к внутренней сети организации, в то же время не открывая
доступ к веб-серверу, электронной почте или DNS-серверу напрямую из
Интернета.
Современные дома обычно имеют сеть взаимосвязанных устройств
разного типа и с различными типами соединений и протоколами связи (рис.
22.7.). Пример схемы домашней сети ниже показывает одну общую
конфигурацию с кабельным модемом, беспроводным маршрутизатором в
сочетании с коммутатором, телевизором, телефоном с передачей голоса по IP
(VoIP), различными компьютерами и устройствами.
525
Home Office
«Web Server»
«Cable Modem»
Touchstone TM822
«Wireless Router»
Belkin N+
----------------------...........
-----------------------
Coaxial cable
Cat5e Gigabit Ethernet TP cable
Phone cable
Wireless connection
Wii Component Video Cable
USE 2,0 cable
Рис. 22.7. Пример схемы домашней сети - кабельный модем,
беспроводной маршрутизатор, различные компьютеры и устройства.
UML
не
предоставляет
специальных
диаграмм
для
описания
логической или физической сетевой архитектуры проектируемой или
существующей системы. Для этой цели можно использовать диаграммы
развертывания с элементами, ограниченными в основном устройствами,
на которых не показаны ни артефакты, ни фактическое развертывание.
Входящий коаксиальный кабель разделяется на два кабеля - один идет
непосредственно в телевизор, а другой в кабельный модем Touchstone
TM822. Модем совместим со стандартами DOCSIS® 3.0 (спецификация
интерфейса передачи данных по кабелю) и PacketCable® 2.0 и обеспечивает
передачу как данных, так и голосового трафика. DOCSIS — это
международный
телекоммуникационный
стандарт,
описывающий
высокоскоростную передачу данных по существующей системе кабельного
телевидения (CATV). Модем поддерживает две независимые телефонные
линии VoIP и имеет телефон, подключенный стандартным телефонным
526
кабелем. Он также имеет беспроводной маршрутизатор Belkin N+,
подключенный к модему с помощью кабеля Cat5e Gigabit Ethernet.
Беспроводной маршрутизатор Belkin N+ поддерживает стандарты
беспроводной связи IEEE 802.11b/g/n и использует преобразование сетевых
адресов
(NAT)
для
совместного
использования
одного
IP-адреса,
назначенного вашим интернет-провайдером (ISP). Маршрутизатор имеет
встроенный
четырехпортовый
коммутатор
сетевой
Gigabit
Ethernet,
позволяющий использовать до 4 проводных соединений. Маршрутизатор N+
также включает USB-порт для одного устройства хранения (флэш-
накопитель или внешний жесткий диск).
N+ оснащен брандмауэром, который защищает сеть от широкого
спектра распространенных хакерских атак, включая спуфинг IP, наземную
атаку, Ping of Death (PoD), отказ в обслуживании (DoS), IP с нулевой длиной,
SYN-флуд, дефект ICMP, переполнение фрагментами и т. д. Для защиты
беспроводной сети Belkin N+ поддерживает как WEP (64-битное и 128­
битное
шифрование),
так
и
WPA/WPA2-Personal
(PSK). Он
также
поддерживает фильтрацию MAC-адресов.
Несколько
устройств
имеют
беспроводное
подключение
к
маршрутизатору — игровая консоль Wii, некоторые смартфоны, ноутбуки,
компьютеры Mac и домашние офисные компьютеры. На ноутбуках и
настольных
компьютерах
установлено
дополнительное
программное
обеспечение брандмауэра. На рабочем столе домашнего офиса есть
несколько устройств, подключенных с помощью USB 2.0. Существует также
веб-сервер, подключенный к маршрутизатору с помощью кабеля Gigabit
Ethernet для более быстрого и надежного подключения к Интернету.
5.8. Пример сетевой диаграммы веб-приложения
Назначение: Пример схемы сетевой архитектуры для домашней сети.
527
Резюме: Современные дома обычно имеют сеть взаимосвязанных
устройств разного типа и с различными типами соединений и протоколами
связи.
UML
не
предоставляет
специальных
диаграмм
для
описания
логической или физической сетевой архитектуры проектируемой или
существующей системы. Для этой цели можно использовать диаграммы
развертывания с элементами, ограниченными в основном устройствами,
на которых не показаны ни артефакты, ни фактическое развертывание.
Пример сетевой диаграммы ниже показывает сетевую архитектуру с
конфигурацией, обычно называемой «демилитаризованной зоной с двумя
брандмауэрами» (рис. 22.8.). Демилитаризованная зона (DMZ) — это узел
или сегмент сети, расположенный в «нейтральной зоне» между Интернетом и
внутренней сетью организации (частной сетью). Это предотвращает
получение внешними пользователями прямого доступа к внутренней сети
организации, в то же время не открывая доступ к веб-серверу, электронной
почте или DNS-серверу напрямую из Интернета.
«Firewall» Cisco
Catalyst 6500 FWSM
«Firewall» Cisco
Catalyst 6500 FWSM
«Web farm»
Рис. 22.8. Пример сетевой схемы для веб-приложения с двумя
конфигурациями DMZ брандмауэра.
Конфигурация DMZ с двумя брандмауэрами со сложными правилами
безопасности обеспечивает лучшую защиту по сравнению с конфигурацией
DMZ брандмауэра маршрутизатора и часто
528
способна анализировать
входящий и исходящий HTTP-трафик и защищать от атак прикладного
уровня, направленных на веб-серверы.
Веб-серверы
с
балансировкой
нагрузки,
показанные
в
демилитаризованной зоне, взаимодействуют с серверами приложений и баз
данных, расположенными в частной сети (интранет).
529
6. ПРИМЕРЫ UML ДИАГРАММЫ ПРОФИЛЯ.
6.1. Примеры схем профиля UML на языке моделирования сервис-
ориентированной архитектуры (SoaML)
Профиль UML для сервис-ориентированной архитектуры описан в
спецификации
языка
архитектуры
(SoaML).
сервис-ориентированной
моделирования
«Цели SoaML
заключаются
в
том, чтобы
поддерживать действия по моделированию и проектированию сервисов, а
также вписываться в общий подход к разработке на основе моделей» (SoaML
1.0 Beta 2). Спецификация SoaML содержит как метамодель SoaML, так и
профиль SoaML UML.
Профиль
SoaML
UML
поддерживает
моделирование
сервис-
ориентированных архитектур, включая спецификацию систем сервисов,
спецификацию
интерфейсов
отдельных
сервисов
и
спецификацию
реализаций сервисов.
Услуга определяется там как ценность, доставляемая другому через
четко определенный интерфейс и доступная сообществу (которым может
быть широкая общественность). Результатом услуги является работа,
предоставляемая друг другу (рис. 23.1.).
Рис. 23.1. UML-профиль SoaML — контракты.
530
Сотрудничество, сервисный контракт или сервисная архитектура
представляют собой шаблон взаимодействия между ролями. В SoaML это
взаимодействие может быть неформальным и неопределенным, как в
наброске требований. Он также может представлять собой формальные
соглашения или требования, которые должны быть точно выполнены.
Описание услуги указывает, как участники взаимодействуют для
предоставления или использования услуги. В SoaML существует три способа
указать взаимодействие службы: интерфейс UML, интерфейс службы и
контракт службы.
Потребитель моделирует интерфейс, предоставляемый потребителем
услуги. Потребитель услуги получает результаты взаимодействия услуги.
Обычно взаимодействие с сервисом инициирует потребитель.
Выглядит странно, что Consumer и Provider расширяют метаклассы
Interface и Class. SoaML поясняет, что Interface используется в случае не
составного контракта на обслуживание, а Class — в случае составного
контракта на обслуживание (рис. 23.2.).
Рис. 23.2. UML-профиль SoaML — службы
Участники — это либо определенные объекты, либо виды объектов,
которые
предоставляют
представлять
людей,
или
используют
организации
услуги.
или компоненты
Участники
могут
информационной
системы. Участники могут предоставлять любое количество услуг и могут
531
потреблять
любое
количество
услуг. Участники
предоставляют
или
потребляют услуги через порты.
Агент — это автономная сущность, которая может адаптироваться к
окружающей среде и взаимодействовать с ней. Агент может быть
программным
агентом,
аппаратным
агентом,
агентом
встроенного
программного обеспечения, роботизированным агентом, агентом-человеком
и т. д.
Порт — это часть или функция участника, которая является точкой
взаимодействия для услуги, где она предоставляется или потребляется. Порт,
где предлагается услуга, может быть обозначен как порт «Сервис», а порт,
где потребляется услуга, может быть обозначен как порт «Запрос».
Запрос расширяет порт, чтобы указать функцию участника, которая
представляет услугу, которая нужна участнику и которую он получает от
других участников. Запрос определяется сервисным интерфейсом. Порт
запроса является «сопряженным» портом — предоставленный и требуемый
интерфейсы типа порта инвертируются, создавая порт, который использует
тип порта, а не реализует тип порта.
Услуга представляет собой функцию Участника, которая представляет
собой предложение услуги одним Участником другим с использованием
четко определенных условий и интерфейсов (рис. 23.3.). Служба обозначает
Порт,
определяющий точку подключения,
через
которую
предлагает свои возможности и предоставляет услугу клиентам.
532
Участник
Рис. 23.3. UML-профиль SoaML — сервисные данные.
Тип сообщения определяет информацию, которой обмениваются
потребители и поставщики услуг. Тип сообщения, как правило, следует
применять только к типу данных, поскольку предполагается, что он не имеет
идентификатора. Однако SoaML признает, что многие существующие модели
не различают четко идентичность, либо смешивая класс и тип данных, либо
используя только класс. Из-за этого еще одна странность заключается в том,
что SoaML позволяет типу сообщения расширять класс, а также тип данных.
Вложение — это часть сообщения, которая прикреплена к сообщению,
а не содержится в нем.
6.2. Корпоративный JavaBeans™ EJB 3.0
Здесь мы приводим пример упрощенного и неофициального профиля
UML для Enterprise JavaBeans™ (EJB) 3.0 с поддержкой сеансов, объектов
и управляемых сообщениями Enterprise JavaBeans.
Официальная метамодель и профиль UML для спецификации Java
и EJB, версия 1.0 от OMG и JCP предназначена для Java 1.3, EJB 1.1 и,
скорее всего, UML 1.4, поэтому она может представлять некоторый интерес
только для книжных червей.
Спецификация
UML
2.4
предоставляет
пример
профиля
для
неопределенной версии J2EE/Enterprise Java Beans (EJB) в Приложении D.1.
533
Этот образец профиля UML не является ни нормативным (официальным), ни
полным и предоставляется только в качестве иллюстрации.
Спецификация EJB 3.0 определяет сеансовые компоненты как с
сохранением состояния, так и без него. Существуют различия в API между
сеансовыми компонентами с отслеживанием состояния и сеансовыми
компонентами без сохранения состояния. Клиент сеансового компонента
может быть локальным клиентом, удаленным клиентом или клиентом веб­
службы, в зависимости от интерфейса, предоставляемого компонентом и
используемого клиентом (рис. 23.4.).
Рис. 23.4. Упрощенный пример неофициального профиля Java EJB 3.0.
Сессионный компонент с отслеживанием состояния представляет
диалоговый
сеанс с
конкретным
клиентом.
Такие объекты
сеанса
автоматически поддерживают свое диалоговое состояние в нескольких
вызываемых клиентом методах.
534
Сущностный объект представляет собой детальный постоянный
объект. Клиентом объектного компонента может быть локальный клиент или
клиент может быть удаленным клиентом.
Класс компонента, управляемого сообщениями, должен реализовать
соответствующий интерфейс прослушивателя сообщений для типа обмена
сообщениями, поддерживаемого компонентом, управляемым сообщениями,
или указать интерфейс прослушивателя сообщений, используя аннотацию
метаданных MessageDriven или элемент дескриптора развертывания типа
обмена сообщениями.
Файл ejb-jar должен содержать дескриптор развертывания в формате,
определенном в спецификации EJB. Дескриптор развертывания должен
храниться с именем META-INF/ejb-jar.xml.
6.3. Цифровая визуализация и коммуникации в медицине (DICOM)
Здесь мы показываем упрощенный пример диаграммы профиля UML
для версии стандарта цифровых изображений и коммуникаций в
медицине (DICOM)
2011 года.
Стандарт
DICOM,
опубликованный
Национальной ассоциацией производителей электрооборудования (NEMA),
облегчает взаимодействие медицинского оборудования для визуализации,
способствует обмену информацией о цифровом изображении независимо от
производителя устройства, упрощает разработку и расширение систем
архивирования и передачи изображений (PACS), которые также могут
взаимодействовать друг с другом. с другими системами больничной
информации,
позволяет
создавать
базы
данных
диагностической
информации, которые могут запрашиваться с помощью самых разных
устройств, распределенных географически.
Стандарт DICOM основан на нескольких концепциях, разработанных в
других стандартах. Например, Application Entity (AE) определяется в
семиуровневой модели взаимодействия открытых систем (OSI) (ISO/IEC
535
7498-1) как «активный элемент, воплощающий набор возможностей,
относящихся к OSI и определенный для Прикладного уровня» (уровень 7).
Уровень приложений — это уровень OSI, с которым приложения
взаимодействуют с использованием протоколов уровня приложений для
отправки или получения данных по сети.
Спецификация класса обслуживания определяет группу из одного или
нескольких классов SOP, связанных с определенной функцией, которая
должна выполняться путем обмена данными с прикладными объектами.
Спецификация класса обслуживания также определяет правила, которые
позволяют реализациям устанавливать некоторый заранее определенный
уровень соответствия одному или нескольким классам SOP. Приложения
могут соответствовать классам SOP либо как пользователь класса
обслуживания (SCU), либо как поставщик класса обслуживания (SCP).
Пользователь класса обслуживания — это роль, которую играет
объект приложения DICOM (DIMSE-Service-User), который вызывает
операции и выполняет уведомления для конкретной ассоциации (рис. 23.5.).
Поставщик класса обслуживания — это роль, которую играет объект
приложения DICOM (DIMSE-Service-User), который выполняет операции и
вызывает уведомления для конкретной ассоциации.
536
Рис. 23.5. Пример диаграммы профиля UML для стандарта DICOM 2011.
Элемент службы сообщений DICOM (DIMSE) определяет элемент
службы
приложений (как службу,
так и протокол), используемый
одноранговыми объектами приложений DICOM для обмена медицинскими
изображениями и соответствующей информацией. DIMSE предоставляет
свои услуги, полагаясь на протокол DIMSE. Протокол DIMSE определяет
правила кодирования, необходимые для построения сообщений. Сообщение
состоит из набора команд, за которым следует условный набор данных.
Класс пары сервис-объект (SOP) представляет собой объединение
сервисной
группы
DIMSE
и
одного
связанного
определения
информационного объекта (IOD), которое полностью определяет точный
контекст для передачи операций над таким объектом или уведомлений о его
состоянии. Определение класса SOP содержит правила и семантику, которые
537
могут ограничивать использование услуг в группе услуг DIMSE или
атрибутов IOD.
Сервисная
группа
DIMSE
определяет
одну
или
несколько
операций/уведомлений, применимых к IOD.
Определение информационного объекта — это абстракция реального
информационного объекта (например, КТ-изображение, структурированный
отчет и т. д.), на который воздействует одна или несколько команд DICOM.
IOD представляет не конкретный экземпляр объекта реального мира, а скорее
класс объектов реального мира, которые имеют одни и те же свойства.
Нормализованный IOD — это определение информационного объекта,
которое обычно представляет собой единый объект в модели DICOM
реального мира.
Составной IOD — это определение информационного объекта, которое
представляет части нескольких объектов в модели DICOM реального мира.
Такой IOD включает в себя атрибуты, которые не присущи объекту
реального мира, который представляет собой IOD, а присущи родственным
объектам реального мира.
Атрибуты IOD описывают свойства экземпляра объекта реального
мира. Связанные атрибуты сгруппированы в модули, которые представляют
более высокий уровень семантики, задокументированный в спецификациях
модулей.
538
7. ПРИМЕРЫ UML ДИАГРАММЫ СВЯЗИ.
7.1. Диаграмма коммуникации книжного интернет-магазина
Пример коммуникационной схемы для интернет-магазина. Веб­
клиент (изображенный как актер) может искать, просматривать и покупать
книги (рис. 24.1.).
interaction Online Bookshop
inventory
r 2.3 [order complete]:
update_inventory()
1.1: search() л
1.2 [interested]:
view_book()
1 *: find_books()
:Book
:Online
Bookshop
''v
2: checkout()
2.2 [not empty(cart)]:
make_order()
1.3 [decided to buy]:
add_to_cart()
2.1: get_books()
Chopping
Cart
: Order
Рис. 24.1. Пример схемы связи UML для онлайн-книжного магазина.
Коммуникация начинается с 1 *: find_books()- итеративное сообщение,
которое может повторяться неопределенное количество раз. Клиент
просматривает инвентарь книг, и если он/она интересуется какой-либо
книгой, он/она может просмотреть описание книги (1.2
[interested]:
view_book()). Если клиент решил купить, он может добавить книгу в корзину
- 1.3 [decided to buy]: add_to_cart().
Оформление заказа включает в себя получение списка книг из корзины,
создание заказа и обновление инвентаря, если заказ был выполнен.
539
На рисунке ниже названы некоторые элементы коммуникационной
диаграммы (рис. 24.2.).
Рис. 24.2. Основные элементы UML диаграммы связи.
540
8. ПРИМЕРЫ UML ДИАГРАММ ПАКЕТОВ.
8.1. Многоуровневая веб-архитектура
Ниже представлен пример диаграммы пакета UML, представляющей
некоторую многоуровневую веб-архитектуру.
Зависимости между пакетами создаются таким образом, чтобы
избежать циклических зависимостей между пакетами.
Пакеты более высокого уровня зависят от пакетов более низкого
уровня. Пакеты, принадлежащие одному уровню, могут зависеть друг от
друга. Объекты передачи данных и общие исключения используются
пакетами более высокого уровня (рис. 25.1.).
—1
—1
exceptions
orders
г----_____ L i
1
l
l
1
1
l
l
l
l
|
L_
------------ 1_ —
1—i
—
—1 v
---- 1 V 'I'
dto
exceptions
——
____
types
values
Рис. 25.1. Пример диаграммы пакета UML для многоуровневой вебархитектуры.
541
8.2. API Java™ Servlet 2.5
Пример диаграммы пакетов UML 2.5, представляющей наиболее
важные интерфейсы и классы Java™ Servlet 2.5 API . Этот API описан в
Спецификации Servletов Java версии 2.5 и является обязательным (частью)
API платформы Java, Enterprise Edition ("Java EE"), версия 5.
Интерфейс прикладного программирования (API) — это общий термин
программирования, который обычно определяется как набор интерфейсов,
классов и некоторых правил, определяющих, как некоторый клиент API
может (повторно) использовать службы и/или ресурсы, предоставляемые
программным компонентом, реализующим этот API.
Обратите внимание, что UML 2.5 не предоставляет нотацию или
стереотип для поддержки моделирования API. На приведенной ниже
диаграмме Servlet API обозначен как пакет со стереотипом«API», что не
является стандартным стереотипом UML.
Servlet — это класс Java, прямо или косвенно реализующий интерфейс
Servletа API Java Servlet. В документации по Java EE Servletbi обычно
упоминаются как веб- компоненты. Жизненный цикл Servletов управляется
веб-контейнером. Веб-контейнер предоставляется как часть веб-сервера или
сервера приложений Java EE.
Java Servlet 2.5 API состоит из двух пакетов: javax.servlet и
javax.servlet.http. Пакет javax.servlet содержит ряд интерфейсов и классов
(как абстрактных, так и конкретных), которые описывают и определяют
контракты между классом Servletа и средой выполнения, предоставляемой
экземпляру такого класса соответствующим контейнером Servleta.
javax.servlet.http — это пакет, содержащий API-интерфейсы и классы,
специализированные для Servletов, поддерживающих протокол HTTP и
соответствующую среду выполнения (рис. 25.2.).
542
Рис. 25.2. Схема пакета UML, представляющая основные интерфейсы и
классы Java™ Servlet 2.5 API.
Два абстрактных класса в Java Servlet API, которые реализуют
интерфейс Servleta, — это GenericServlet и HttpServlet. HttpServlet обычно
расширяется разработчиками для реализации Servletов для конкретных
приложений, поддерживающих протокол HTTP.
543
8.3. API-интерфейс Java™ Servlet 3.0
Ниже
рассмотрим
пример
диаграммы
пакетов
UML
2.5,
представляющей наиболее важные интерфейсы и классы API Java™ Servlet
3.0. Этот API описан в Спецификации Servletов Java версии 3.0 и является
обязательным (частью) API платформы Java, Enterprise Edition ("Java
EE"), версия 6.
Интерфейс прикладного программирования (API) — это общий термин
программирования, который обычно определяется как набор интерфейсов,
классов и некоторых правил, определяющих, как некоторый клиент API
может (повторно) использовать службы и/или ресурсы, предоставляемые
программным компонентом, реализующим этот API.
Обратите внимание, что UML 2.5 не предоставляет нотацию или
стереотип для поддержки моделирования API. На приведенной ниже
диаграмме Servlet API обозначен как пакет со стереотипом «API», что не
является стандартным стереотипом UML.
Servlet — это класс Java, прямо или косвенно реализующий интерфейс
Servletа API Java Servlet. В документации по Java EE Servletbi обычно
упоминаются как веб- компоненты. Жизненный цикл Servletов управляется
веб-контейнером. Веб-контейнер предоставляется как часть веб-сервера или
сервера приложений Java EE.
Java Servlet 3.0 API состоит из четырех пакетов:
•
javax.Servlet,
•
javax.servlet.http,
•
javax.servlet.annotation и
•
j■avax.servlet.gескриптор.
Пакет javax.servlet содержит ряд интерфейсов и классов (как
абстрактных, так и конкретных),
которые описывают и определяют
контракты между классом Servletа и средой выполнения, предоставляемой
экземпляру такого класса соответствующим контейнером Servleta.
544
javax.servlet.http — это пакет, содержащий API-интерфейсы и классы,
специализированные для Servletов, поддерживающих протокол HTTP и
соответствующую среду выполнения (рис. 25.3.).
Рис. 25.3. Схема пакета UML, представляющая основные интерфейсы и
классы Java™ Servlet 3.0 API.
545
Пакет javax.servlet.annotation содержит ряд аннотаций, которые
позволяют объявлять Servletbi, фильтры, прослушиватели и указывать
метаданные для объявленного компонента с помощью этих аннотаций.
(Аннотации в Java — это особый вид интерфейса.)
Пакет
javax.servlet.descriptor
интерфейсы,
предоставляет
обеспечивающие программный доступ к информации о конфигурации веб­
приложения из дескрипторов web.xml и web-fragment.xml.
Два абстрактных класса в Java Servlet API, которые реализуют
интерфейс Servletа, — это Generic Servlet и HttpServlet. HttpServlet обычно
расширяется разработчиками для реализации Servletов для конкретных
приложений, поддерживающих протокол HTTP.
8.4. Классы Spring и Hibernate
Ниже рассмотрен пример диаграммы пакета UML, представляющей
некоторые классы доступа к данным Spring и Hibernate.
Spring
Framework
обеспечивает
интеграцию
с
несколькими
технологиями доступа к данным Object Relational Mapping (ORM), включая
Hibernate, JDO, Oracle TopLink, iBATIS SQL Maps и JPA.
Пакеты поддержки для объектно-реляционных карт соответствуют
общей иерархии транзакций и исключений DAO Spring (рис. 25.4.). Пакеты
Spring framework hibernate3 используют несколько пакетов Hibernate.
546
Рис. 25.4. Пример диаграммы пакета UML для классов доступа к
данным Spring и Hibernate.
8.5. Многоуровневое приложение
Пример
схемы
модели
UML
,
представляющей
многоуровневого приложения на основе Руководства
модель
по архитектуре
приложений Microsoft, 2-е изд.
Согласно руководству, уровни связаны с логическим разделением
компонентов и функций и не учитывают физическое расположение
компонентов, тогда как уровни описывают физическое распределение
функций и компонентов на отдельных серверах, компьютерах, в сетях или на
удаленных серверах. места. Слои могут располагаться на разных уровнях или
на одном уровне.
547
Модель приложения показывает несколько уровней — уровень
представления, уровень услуг, бизнес-уровень, уровень данных и сквозные
уровни. Все слои представлены в виде UML- моделей (рис. 25.5.).
Users
Presentation Layer
User
Interface
д
External
Systems
V
Service
Interfaces
Presentation
Logic
Business
Workflow
4:'
z
----- 1 V
Message
Types
X
4
Business
Components
Business
Entities
ДД1
Data Access
Service Agents
Рис. 25.5. Пример схемы модели многоуровневого приложения UML.
Пользователи и внешние системы также представлены в виде моделей
и взаимодействуют с уровнями представления и служб соответственно. На
диаграмме также показаны источники данных, такие как реляционные базы
данных и агенты веб-служб, которые обеспечивают доступ к данным, а также
внешние или удаленные службы, используемые приложением.
Сквозной уровень содержит общие функции, охватывающие уровни и
уровни. Эта функциональность обычно поддерживает аутентификацию,
548
авторизацию, кэширование, обмен данными, управление исключениями,
ведение
журнала и инструментирование,
а также
проверку.
Такая
функциональность обычно описывается как сквозная.
8.6. Платформа Java™ Standard Edition 7 API
Это пример диаграммы пакетов UML, представляющей Java™
Platform Standard Edition (SE) 7 API. Официальное описание API является
частью документации Oracle Java Platform Standard Edition 7.
Интерфейс прикладного программирования (API) — это общий термин
программирования, который обычно определяется как набор интерфейсов,
классов и некоторых правил, определяющих, как некоторый клиент API
может (повторно) использовать службы и/или ресурсы, предоставляемые
программным компонентом, реализующим этот API.
Обратите внимание, что UML 2.5 не предоставляет нотацию или
стереотип для поддержки моделирования API. На приведенной ниже
диаграмме API обозначен как стереотипный пакет с двойным значком
интерфейса, что не является стандартным стереотипом UML.
API Java SE 7 состоит из нескольких модулей: API пользовательского
интерфейса и набора инструментов, API интеграционных библиотек, API
других базовых библиотек, API базовых библиотек lang и util, API
виртуальной машины Java (JVM) (рис. 25.6.). Java SE 7 API реализуется
двумя продуктами Oracle — Java SE Development Kit (JDK) 7 и Java SE
Runtime Environment (JRE) 7.
549
1
1
'Й
Accessibility
IDL
04
%=l
JDBC
4.1
JNDI
1.2
RMI
Internation '"Ch
alfcation
■/0
JMX %=!
1.4
'й
---- 1
Drag and Drop
Input
RMI-IEOP
Scripting
1.0
JN1
____
Endorsed '~t>?
Override
.
a Й
Security
Object
Serialization
r oncurrency
C
Regular
Expressions
—1
JftR
Zip
—,
,
□ t
Preferences
Versioning
Рис. 25.6. Диаграмма пакетов UML для Java™
Platform Standard Edition 7 API.
Пользовательский
интерфейс
Java
и
API-интерфейсы
Toolkit включают Swing, Java 2D™ Graphics and Imaging API, Abstract
Windowing Toolkit (AWT), Accessibility API, перетаскивание данных,
550
инфраструктуру методов ввода, Image I/O API, Java™ Print Service API,
Звуковой API.
API-интерфейсы интеграции Java содержат Java IDL (CORBA), Java
Connectivity Database Connectivity (JDBC) 4.1 API, Java Naming and Directory
Interface™ (JNDI) 1.2 API, Remote Method Invocation (RMI), RMI-IIOP,
Scripting 1.0 для платформы Java.
Другие (расширенные) базовые API состоят из API JavaBeans™
Component 1.01, интернационализации, API расширений управления Java
(JMX) 1.4, собственного интерфейса Java (JNI), сети, безопасности,
сериализации объектов, API Java для обработки XML (JAXP) 1.4,
архитектура Java для привязки XML (JAXB) 2.2, API Java для веб-служб
XML (JAX-WS) 2.2, API SOAP с вложениями для Java (SAAJ) 1.3 и т. д.
Модуль Java Base APIs
состоит из Java lang и util API, Collections
Framework, Concurrency API, Reflection, Reference Objects, Logging, Java
Archive (JAR) API, Monitoring and Management, Package Version Identification,
Preferences API и т. д.
8.7. Объект передачи данных
Пример шаблона пакета UML для шаблона проектирования,
известного как «Передача объекта в базовых шаблонах J2EE» или
«Объект передачи данных» (DTO) в Руководстве по архитектуре
приложений Microsoft .Net. Он также был известен как Value Object (VO) в
более старых версиях шаблонов проектирования J2EE.
В мире .Net объекты-значения — это неизменяемые объекты домена, не
имеющие уникального идентификатора. Примером объекта значения может
быть сумма транзакции или адрес клиента (рис. 25.7.). Раньше это
называлось структурой в старых языках программирования. Transfer Object
— это некоторая «крупнозернистая» структура данных, предназначенная для
перемещения через разные пограничные слои или транспортировки по сети,
551
обычно сериализуемая, чтобы можно было использовать один вызов метода
для получения или отправки всего Transfer Object, чтобы сократить
количество удаленных вызовов. Примерами DTO являются клиент, заказ на
покупку, учетная запись и т.д.
Рис. 25.7. Пример шаблона пакета UML для шаблона проектирования
объекта передачи данных.
Шаблон имеет неограниченный идентификатор параметра класса и два
параметра
строкового
выражения.
Привязка
заменяет
формальный
параметр идентификатора класса классом Integer, в то время как параметры
строкового выражения используются для построения имен фактических
интерфейсов и классов. Доступ к данным клиента связан с пакетом.
Результат привязки показан ниже (рис. 25.8.). Пакет Customer Data
Access содержит классы Customer DAO (Data Access Object) и Customer TO
(Transfer Object), реализующие соответствующие интерфейсы.
552
Рис. 25.8. Доступ к данным клиента — это пакет, привязанный к
шаблону.
553
9. UML ДИАГРАММЫ КОМПОНЕНТОВ
9.1. Пример UML диаграммы компонентов. Покупки в интернет-
магазине
Пример диаграммы компонентов UML 2.5 для онлайн-покупок. На
диаграмме показан вид «белого ящика» внутренней структуры трех
взаимосвязанных подсистем — Интернет-магазина, Складов и Бухгалтерии.
В UML «подсистема» является стандартным стереотипом для более крупных
компонентов, обычно содержащих несколько более мелких компонентов
(рис. 26.1.).
«subsystem» WebStore
«subsystem» Warehouses
internal structure
§~]
internal structure
Search
Inventory
Productsearch
inventory
:SearchEngine Lr
Manage
Inventory
E
L
«subsystem» Accounting
internal structure
Manage
Orders
OnlineShopping
: Orders
tShopplng Cart
I
I
Manage I
Inventory I
__ I
—X
Manage О
Customers T
Manage
Customers
UserSession
: Authentication
: Customers
5
Manage ,
Accounts
:Accounts
Рис. 26.1. Пример диаграммы компонентов UML для онлайн-покупок с
тремя связанными подсистемами: онлайн-магазином, складами и
бухгалтерией.
Подсистема WebStore содержит три компонента, связанных с онлайнпокупками: поисковая система, корзина и аутентификация. Компонент
«Поисковая система» позволяет искать или просматривать элементы,
554
открывая предоставленный интерфейс «Поиск продукта» и используя
необходимый
интерфейс
в
«Поиск
инвентаре»,
предоставляемый
компонентом «Инвентарь». Компонент «Корзина» использует интерфейс
управления заказами, предоставляемый компонентом «Заказы» во время
оформления заказа. Аутентификация Компонент позволяет клиентам
создавать учетную запись, входить в систему или выходить из нее и
привязывать клиента к какой-либо учетной записи.
Подсистема бухгалтерского учета предоставляет два интерфейса —
«Управление заказами» и «Управление клиентами». Соединители
делегирования
эти
связывают
внешние
контракты
подсистемы
с
реализацией контрактов компонентами «Заказы» и «Клиенты».
Подсистема складов предоставляет два интерфейса Search Inventory
и Manage Inventory, которые используются другими подсистемами и
связаны между собой зависимостями.
9.2. Пример UML диаграммы компонентов. Компоненты
лицензирования Sentinel HASP
Пример диаграммы компонентов UML с некоторым упрощенным
предоставленных
представлением
и
реализованных
компонентов
с
использованием SafeNet Sentinel HASP Software Licensing Security Solution и
Licensing API.
В верхней части диаграммы показано программное обеспечение,
реализованное с использованием приложения Sentinel HASP - License
Status.Net и Java - компонента License Services. Приложение License Status
предназначено
для
отображения
статуса
лицензии
и
проявляется
(реализуется) артефактом license_status.exe. Java-компонент License Services
реализует интерфейс License Service и может использоваться другими Java-
приложениями или службами.
Приложение License Status использует компонент License Services Net
через
интерфейс
License
Service, реализованный этим компонентом.
Компонент License Services Net использует HASP .Net API, предоставляемый
555
компонентом HASP .Net Runtime, который является частью продукта
Sentinel HASP.
Компонент License Services Java использует прокси-сервер HASP Java
Native Interface Proxy для связи с компонентом HASP Java Native Interface,
оба компонента предоставляются Sentinel. Когда продукт используется в
Microsoft Windows, собственный интерфейс HASP Java может быть
представлен либо HASPJava.dll (32-разрядная ОС), либо HASPJava_x64.dll,
либо HASPJava_ia64.dll (64-разрядная ОС).
API лицензирования SafeNet Sentinel LDK 6.1 включает:
•
структурные объявления и информация об отдельных функциях
Sentinel Licensing API,
•
описание тегов XML, которые можно использовать для определения
области действия и формата вывода различных функций API,
•
описание всех кодов возврата API.
Установка Sentinel LDK включает образцы API для различных языков
программирования, включая C, C#, Java. Например, HASP Java API
включает в себя 4 класса Java: Hasp, HaspApiVersion, HaspTime и HaspStatus в
пакете Aladdin. Эти классы объединены в артефакт HASPJava.jar. Классы
HASP Java API загружают и связывают нативные методы из нативной
библиотеки
для
конкретной
платформы
System.loadLibrary(). Как мы уже говорили,
загруженной
библиотекой
DLL
является
HASPJava_x64.dll или HASPJava_ia64.dll.
556
с
помощью
метода
для Microsoft Windows
одна
из
HASPJava.dll,
Рис. 26.2. Пример диаграммы компонентов для продукта,
использующего Sentinel HASP Software Licensing Security Solution.
557
Каждому поставщику программного обеспечения, использующему
Sentinel
уникальный
присваивается
HASP,
соответствующий ключ поставщика. Вендор
пакетный
создает
и
код
и
использует
собственные динамические библиотеки, реализующие HASP Vendor API
(Sentinel Licensing API). Эти динамические библиотеки именуются ключом
поставщика как частью имени файла. Формат имен библиотек API для
выглядит
Windows
так:
hasp_wmdows_[язык/биты]_[код производителя] .[расширение библиотеки]
Например,
hasp_windows_x64_99999.dll
— это 64-разрядная библиотека API DLL, связанная с ключом
поставщика программного обеспечения 99999.
Когда Sentinel HASP Runtime устанавливается в Microsoft Windows, он
также устанавливает Sentinel HASP Local License Manager, представленный
как hasplms.exe и работающий как локальная служба. Эта служба зависит от
системного компонента драйвера протокола TCP/IP.
9.3. Шаблон проектирования Observer как пример использования
совместной работы UML
Шаблон наблюдателя (Observer) — это поведенческий шаблон
проектирования программного обеспечения, в котором субъект ведет
список подписчиков, называемых наблюдателями, и уведомляет их о любых
изменениях состояния, обычно вызывая один из их методов. После
получения уведомления об изменении состояния наблюдатель может
запросить текущее состояние субъекта.
Пример совместной работы для шаблона проектирования Observer
показан ниже (рис. 26.3.). Две роли коллаборации — субъекта и
наблюдателя
—
будут
играть
558
экземпляры
классификаторов,
типизированные интерфейсами Subject и Observer. Эти интерфейсы можно
рассматривать
как
проекцию
внешне
наблюдаемых
особенностей
классификаторов, играющих роли.
Рис. 26.3. Пример совместной работы — шаблон проектирования
Observer.
Тоже самое сотрудничество может быть показано с использованием
альтернативной записи для свойств (рис. 26.4.). Значок совместной работы
подключен к каждому из прямоугольников, обозначающих интерфейсы,
которые являются типами свойств совместной работы. Каждая строка
помечена названием свойства (роли).
559
Рис. 26.4. Пример составной структуры — шаблон проектирования
Observer.
560
10. СОСТАВНЫЕ СТРУКТУРНЫЕ UML ДИАГРАММЫ
10.1. Пример диаграммы составной структуры UML банкомата в банке
Назначение: Цель этой диаграммы — показать внутреннюю структуру
банкомата банка и взаимосвязь между различными частями банкомата.
Резюме: банкомат банка обычно состоит из нескольких устройств,
таких как центральный процессор (ЦП), криптопроцессор, память, дисплей
клиента, кнопки функциональных клавиш (обычно расположенные рядом с
дисплеем), считыватель магнитных карт и/или смарт-карт, шифрующая
ПИН-пад, принтер чеков, хранилище, модем.
Это пример схемы внутренней структуры UML, которая показывает
составную структуру банкомата (банкомата). Цель этой диаграммы —
показать внутреннюю структуру банкомата банка и связи между различными
частями банкомата.
Банкомат обычно состоит из нескольких устройств, таких как
центральный процессор (ЦП), криптопроцессор, память, дисплей клиента,
кнопки функциональных клавиш (обычно расположенные рядом с дисплеем),
устройство чтения магнитных карт и/или смарт-карт, шифрующая ПИН-пад,
кассовый чек, принтер, хранилище, модем (рис. 27.1.).
561
Рис. 27.1. Пример схемы UML внутренней структуры банкомата банка
В хранилище хранятся устройства и детали, доступ к которым
ограничен, в том числе механизм выдачи наличных, депозитный механизм,
несколько
датчиков
безопасности
(например,
магнитных,
тепловых,
сейсмических, газовых), система электронного журнала для ведения
системного журнала и т. д. Банкомат включает в себя несколько съемных
картриджей для наличных и депозитный механизм - съемные депозитные
кассеты.
Банкомат обычно подключается к банковской или межбанковской сети
через какой-либо модем (например, коммутируемый или ADSL) через
коммутируемую телефонную линию общего пользования или выделенную
линию. Сетевая интерфейсная карта (NIC) может использоваться в качестве
высокоскоростной альтернативы в VPN-подключениях.
562
На приведенной ниже обзорной диаграмме поясняется составная
структурная
диаграмма
с
элементами
внутренней
структуры
структурированного классификатора — ролями, частями, соединителями
Рис. 27.2. Обзор составной структурной диаграммы показывает
элементы внутренней структуры структурированного классификатора -
роли, части, соединители.
10.2. Пример диаграммы составной структуры UML. Сервер Apache
Tomcat 7
Назначение:
показать
упрощенную
составную
структуру
некластеризованного веб-сервера Apache Tomcat 7.
Резюме: элемент Server представляет контейнер сервлетов Catalina веб­
сервера Apache Tomcat 7. Это единственный внешний элемент в файле
конфигурации
conf/server.xml.
Элемент
563
сервера
может
содержать
необязательный компонент глобальных ресурсов именования и одну или
несколько служб. Каждый элемент службы представляет собой композицию
исполнителей и соединителей, которые совместно используют один
компонент Engine.
Это пример схемы внутренней структуры UML, которая показывает
упрощенную составную структуру некластеризованного сервера Apache
Tomcat 7.
Элемент Server представляет контейнер Servletoe Catalina веб-сервера
Apache Tomcat 7. Это единственный внешний элемент в файле конфигурации
conf/server.xml. Элемент Server может содержать необязательный компонент
Global Naming Resources и один или несколько Services.
Каждый
элемент
службы
представляет
собой
композицию
исполнителей и соединителей, которые совместно используют один
компонент Engine (рис. 27.3.). Механизм получает и обрабатывает все
запросы от одного или нескольких соединителей и возвращает готовый ответ
соединителю для его передачи обратно веб-клиенту. Один или несколько
элементов Host вложены внутрь Engine.
564
Рис. 27.3. Пример внутренней структуры — сервер Apache Tomcat 7.
Элемент Host представляет виртуальный хост, который является
ассоциацией сетевого имени сервера (например, "www.mycompany.com") с
конкретным сервером, на котором работает Tomcat. С одним и тем же
виртуальным хостом может быть связано более одного сетевого имени.
Элемент Context представляет собой веб-приложение, которое
работает на определенном виртуальном хосте. Каждое веб-приложение
основано на файле архива веб-приложений (WAR) или каталоге, содержащем
соответствующее распакованное содержимое, как описано в спецификации
Servleta. Каждый контекст должен иметь уникальное имя контекста.
565
10.3. Пример UML диаграммы совместного использования. Шаблон
проектирования наблюдателя
Назначение: пример совместной работы UML, представляющий
шаблон проектирования Observer.
Резюме:
шаблон
проектирования
поддерживает
наблюдателя
программного
список
—
это
обеспечения,
подписчиков,
поведенческий
шаблон
в
субъект
называемых
котором
наблюдателями,
и
уведомляет их о любых изменениях состояния, обычно вызывая один из их
методов.
После
получения
уведомления
об
изменении
состояния
наблюдатель может запросить текущее состояние субъекта.
Шаблон
—
наблюдателя
это
поведенческий
шаблон
проектирования программного обеспечения, в котором субъект ведет
список подписчиков, называемых наблюдателями, и уведомляет их о любых
изменениях состояния, обычно вызывая один из их методов. После
получения уведомления об изменении состояния наблюдатель может
запросить текущее состояние субъекта.
Пример совместной работы для шаблона проектирования Observer
показан ниже (рис. 27.4.). Две роли коллаборации — субъекта и
наблюдателя
—
будут
играть
экземпляры
классификаторов,
типизированные интерфейсами Subject и Observer. Эти интерфейсы можно
рассматривать
как
проекцию
внешне
классификаторов, играющих роли.
566
наблюдаемых
особенностей
Рис. 27.4. Пример совместной работы — шаблон проектирования
Observer
То же самое сотрудничество можно было бы показать, используя
альтернативное обозначение свойств (рис. 27.5.). Значок совместной работы
подключен к каждому из прямоугольников, обозначающих интерфейсы,
которые являются типами свойств совместной работы. Каждая строка
помечена названием свойства (роли).
Рис. 27.5. Пример составной структуры — шаблон проектирования
Observer
567
11. UML ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
11.1. UML диаграммы обзора взаимодействия
11.1.1. Бизнесс модель ресторна
Здесь мы приводим два альтернативных примера диаграммы бизнеспрецедентов для ресторана, представленных в нотации, используемой
Rational Unified Process (RUP).
В первом примере показан внешний вид ресторана (рис. 28.1.). Мы
можем видеть, что у нескольких участников бизнеса есть определенные
потребности и цели, связанные с вариантами использования ресторана и
бизнеса, выражающие ожидания участников от бизнеса.
Рис. 28.1. Диаграмма бизнес-прецедентов для ресторана — внешний вид.
568
Например, Заказчик хочет Поесть, Кандидат — Устроиться на
работу, а Подрядчик — починить какую-то технику. Обратите внимание,
что у нас нет таких актеров, как Шеф или Официант. Это не внешние роли,
а часть моделируемого нами бизнеса - ресторана, поэтому они не актеры. С
точки зрения RUP повар и официант являются деловыми работниками.
Второй
пример
показывает внутреннюю бизнес -презентацию
ресторана. В этом случае мы видим, что у ресторана есть несколько бизнес-
процессов, представленных бизнес-вариантами, которые предоставляют
некоторые услуги внешним бизнес-актерам. Как и в предыдущем примере, у
актеров есть определенные потребности и цели, связанные с рестораном.
Этот подход может быть более полезен для моделирования услуг,
которые бизнес предоставляет различным типам клиентов, но чтение такого
рода диаграмм бизнес-прецедентов может привести к путанице.
Например, Customer теперь подключен к варианту использования
Serve Meal, Поставщик — к Purchase Supplies (рис. 28.2.). Теперь у нас
есть новый действующий потенциальный клиент, который участвует в
сценарии использования «Реклама», читая рекламу и получая некоторую
информацию о ресторане. В то же время актер «Подрядчик» ушел, потому
что ремонт бытовой техники не является услугой, обычно предоставляемой
ресторанами.
569
«Business»
Restaurant
Serve Luncl
Serve Dinnei
Customer
Advertiser
Advertise
Potential
Customer
Purchase
Supplies/
Supplier
Candidate
Рис. 28.2. Диаграмма бизнес-прецедентов для ресторана — вид изнутри.
Тем не менее, в этом примере у нас нет актеров в качестве шеф- повара
или официанта по тем же причинам, что и раньше — они оба не внешние
роли, а часть бизнеса, который мы моделируем.
11.1.2. Регистрация в аэропорту и проверка безопасности
Это пример диаграммы бизнес-прецедентов, которая обычно создается
во время бизнес-моделирования и представлена здесь в нотации Rational
Unified Process (RUP).
Субъектами бизнеса являются пассажир, гид, несовершеннолетний
(ребенок), пассажир с особыми потребностями (например, с ограниченными
570
возможностями), все они играют внешние роли по отношению к
деятельности аэропорта.
Варианты
использования
в бизнесе —
это индивидуальная
регистрация, групповая регистрация (для групп туристов), проверка
безопасности и т. д. — представляющие бизнес-функции или процессы,
происходящие в аэропорту и обслуживающие потребности пассажиров.
Варианты использования в бизнесе Регистрация багажа и обработка
багажа расширяют варианты использования регистрации, поскольку у
пассажира может не быть багажа, поэтому регистрация и обработка багажа
не являются обязательными (рис. 28.3.).
Рис. 28.3. Пример диаграммы вариантов использования для
регистрации в аэропорту и проверки безопасности.
11.2. UML диаграммы вариантов использования системы
11.2.1. Автомат по продаже билетов
Автомат по продаже билетов, т. е. торговый автомат, который продает
и производит билеты для пассажиров, является предметом диаграммы
примера использования. Этот тип машины представляет собой комбинацию
571
аппаратного и программного обеспечения, и это только часть всей системы
продажи
билетов
клиентам.
Поэтому
воспользуемся
стереотипом
«Подсистема».
Автомат по продаже билетов позволяет пассажирам покупать билеты.
Таким образом, Commuter является нашим основным действующим лицом
(рис. 28.4.).
Рис. 28.4. Автомат по продаже билетов предоставляет вариант
использования «Покупка билета» для участников
пригородных поездов и банка.
Конечной целью пассажиров пригородных поездов в отношении
нашего автомата по продаже билетов является покупка билета. Итак, у нас
есть вариант использования «Покупка билета». При покупке билета
может участвовать банк, если оплата производится с помощью дебетовой или
кредитной карты. Поэтому мы также добавляем еще одного актера — Банк.
Оба актора, участвующие в варианте использования, связаны с вариантом
использования ассоциацией.
Поведение вариантов использования может быть описано текстом на
естественном языке (непрозрачное поведение), что является общепринятой
практикой, или с помощью диаграмм поведения UML. Инструменты UML
должны
позволять
привязывать
поведение
к
описанным
вариантам
использования. Пример такой привязки варианта использования «Купить
билет» к поведению, представленному активностью, показан ниже с
использованием нотации UML 2.5 (рис. 28.5.).
572
Purchase Ticket G2>
owned behaviors
«activity»
Purchase Ticket
Рис. 28.5. Вариант использования «Покупка билета» определяет
поведение, представленное действием «Покупка билета»
11.2.2. Диаграмма вариантов использования UML банкомата
Банкомат (ATM) или банкомат (ABM) — это банковская подсистема
(субъект), которая предоставляет клиентам банка доступ к финансовым
транзакциям в общественном месте без необходимости присутствия кассира,
проверки баланса своих банковских счетов, внесения средств, снятия
наличных и/или перевода средств (варианты использования) (рис. 28.6.).
Специалист по банкоматам осуществляет техническое обслуживание и
ремонт. Все эти варианты использования также связаны с банковским
субъектом, независимо от того, связаны ли они с транзакциями клиентов или
с обслуживанием банкоматов.
573
«subsystem»
Bank ATM
Рис. 28.6. Пример диаграммы прецедентов для подсистемы банкоматов
банка - прецеденты верхнего уровня.
В большинстве банковских банкоматов аутентификация клиента
осуществляется путем вставки пластиковой карты банкомата и ввода личного
идентификационного
номера
(ПИН-кода).
Вариант
использования
«Аутентификация клиента» требуется для каждой транзакции банкомата,
поэтому мы показываем его как включающее отношение. Включение этого
варианта использования, а также обобщения транзакций делает транзакцию
банкомата абстрактным вариантом использования (рис. 28.7.).
574
Рис. 28.7. Пример использования банковских банкоматов и
аутентификации клиентов.
Клиенту
использования
может
понадобиться
«Транзакция
помощь
банкомата»
банкомата.
расширяется
через
Вариант
точку
расширения, называемую меню, вариантом использования «Справка
банкомата» всякий раз, когда «Транзакция банкомата» находится в месте,
указанном в меню, и клиент банка запрашивает помощь, например, выбирая
пункт меню «Справка» (рис. 28.8.).
Рис. 28.8. Пример техническое обслуживание, ремонт, диагностика
банковских банкоматов.
575
Техник банкомата обслуживает или ремонтирует банкомат банка.
Сценарий
технического обслуживания включает в себя пополнение
банкомата наличными, чернилами или бумагой для принтера, обновление
аппаратного обеспечения, микропрограммы или программного обеспечения,
а также удаленную диагностику или диагностику на месте. Диагностика
также включена в вариант использования Repair (совместно с ним).
11.2.3. Каталог общедоступной онлайн-библиотеки
Каталог общедоступного онлайн-доступа (Online Public Access
Catalog - OPAC) — это веб-сайт электронной библиотеки, который является
частью интегрированной библиотечной системы (ILS), также известной
как система управления библиотекой (LMS), и управляется библиотекой
или группой библиотек.
Постоянные посетители библиотеки могут искать в онлайн-каталоге
библиотеки различные ресурсы — книги, периодические издания, аудио- и
видеоматериалы
или
другие
предметы,
находящиеся
в
ведении
библиотеки. Покровители могут резервировать или продлевать товар,
оставлять отзывы и управлять своей учетной записью (рис. 28.9.).
576
«module»
Online Public Access Catalog
Рис. 28.9. Пример диаграммы вариантов использования UML для
каталога общедоступного онлайн-доступа электронной библиотеки.
11.2.4. Диаграммы вариантов использования онлайн-покупок
Актер веб-клиента использует некоторый веб-сайт для совершения
покупок в Интернете. Варианты использования верхнего уровня —
«Просмотр товаров», «Совершение покупки» и «Регистрация клиента».
Вариант использования View Items может использоваться клиентом как
вариант использования верхнего уровня, если клиент хочет найти и
просмотреть только некоторые продукты. Этот вариант использования также
можно использовать как часть варианта использования «Совершить
покупку». Вариант использования «Регистрация клиента» позволяет клиенту
зарегистрироваться на веб-сайте, например, чтобы получить купоны или
быть приглашенным на частные продажи. Обратите внимание, что вариант
использования «Оформить заказ» включен в вариант использования,
недоступный сам по себе — оформление заказа является частью совершения
покупки.
577
Кроме актора Web Customer, есть несколько других акторов, которые
будут описаны ниже с подробными вариантами использования (рис. 28.10.).
«Subsystem»
Online Shopping
A
/ «Service»
Authentication
I
I «include»
Registered
Customer
Identity
Provider
I «include»
L
Web
Customer
Checkout
Credit
Payment
Service
New
Customer
Client
Register
PayPal
Рис. 28.10. Пример диаграммы вариантов использования UML для
онлайн-покупок — варианты использования верхнего уровня.
Вариант
использования
View
Items
расширен
несколькими
дополнительными вариантами использования - клиент может искать товары,
просматривать каталог, просматривать товары, рекомендованные для него /
нее, добавлять товары в корзину или список пожеланий. Все эти варианты
использования расширяют варианты использования, потому что они
предоставляют
некоторые
дополнительные
функции,
позволяющие
покупателю найти товар.
Вариант использования «Аутентификация клиента» включен в
«Просмотр рекомендуемых элементов» и «Добавить в список желаний»,
поскольку оба требуют аутентификации клиента (рис. 28.11.). При этом
товар можно было добавить в корзину без авторизации пользователя.
578
Рис. 28.11. Пример диаграммы вариантов использования UML для
онлайн-покупок — вариант использования просмотра элементов.
Вариант использования Checkout включает несколько обязательных
вариантов использования. Веб-клиент должен быть аутентифицирован. Это
можно сделать через страницу входа пользователя, файл cookie для
аутентификации пользователя («Запомнить меня») или систему единого
входа (SSO). Служба проверки подлинности веб-сайта используется во всех
этих случаях использования, в то время как SSO также требует участия
внешнего поставщика удостоверений.
Вариант
использования
Checkout
также
включает
вариант
использования Payment, который может быть выполнен либо с помощью
кредитной карты и внешней службы кредитных платежей, либо с помощью
PayPal (рис. 28.12.).
579
Рис. 28.12. Пример диаграммы вариантов использования UML для
онлайн-покупок — варианты использования для оформления заказа,
аутентификации и оплаты.
11.2.5. Система обработки кредитных карт
В этом примере схемы вариантов использования UML показаны
некоторые
варианты
использования
системы,
которая
обрабатывает
кредитные карты.
Система обработки кредитных карт (известная также как Платежный
шлюз по кредитным картам) находится в стадии разработки или
рассмотрения. Основным действующим лицом системы является система
обработки кредитных карт продавца. Продавец от имени клиента
отправляет некоторый запрос на транзакцию по кредитной карте в
580
платежный шлюз по кредитной карте. Банк, выпустивший кредитную карту
клиента, является субъектом, который может одобрить или отклонить
транзакцию. Если транзакция будет одобрена, средства будут переведены на
банковский счет продавца.
Вариант использования «Авторизация и захват» — наиболее
распространенный тип транзакции по кредитной карте. Запрошенная сумма
денег должна быть сначала авторизована банком кредитных карт Клиента,
и, если она одобрена, она затем передается для расчета. Во время расчетов
средства, утвержденные для транзакции по кредитной карте, зачисляются на
банковский счет Торговца.
В некоторых случаях запрашивается только авторизация, и транзакция
не отправляется на расчет. В этом случае, как правило, если в течение
некоторого количества дней не предпринимаются дальнейшие действия, срок
действия авторизации истекает. Продавцы могут отправить этот запрос, если
они хотят проверить наличие средств на кредитной карте клиента, если товар
в настоящее время отсутствует на складе или если продавец хочет проверить
заказы перед отправкой.
Вариант использования «Захват» (запрос средств, которые ранее
были авторизованы) описывает несколько сценариев, когда продавцу
необходимо выполнить какую-либо ранее авторизованную транзакцию —
либо представленную через платежный шлюз, либо запрошенную без
использования системы, например, с помощью голосовой авторизации (рис.
28.13.).
581
«Subsystem»
Credit Card Payment Gateway
Рис. 28.13. Пример диаграммы вариантов использования UML для
системы обработки кредитных карт.
Вариант использования кредита описывает ситуации, когда клиент
должен получить возмещение за транзакцию, которая была успешно
обработана и рассчитана через систему, или за какую-то транзакцию, которая
изначально не была отправлена через платежный шлюз.
Случай использования Void описывает случаи, когда необходимо
отменить одну или несколько связанных транзакций, которые еще не были
рассчитаны. Если возможно, транзакции не будут отправлены на расчет.
Если транзакция Void завершается неудачей, исходная транзакция, скорее
всего, уже урегулирована.
Вариант использования Verify описывает транзакции проверки с
нулевой или небольшой суммой, которые также могут включать проверку
некоторых данных клиента, таких как адрес.
Вы
можете
найти отличные ресурсы,
документацию,
официальные
документы, руководства и т. д., связанные с обработкой кредитных карт, на
Authorize.Net — Платежный шлюз для приема онлайн-платежей.
582
11.2.6. Администрирование сайта
Требования
безопасности
веб-сайта
требуют
отделения
административных интерфейсов от общих функций, предоставляемых
пользователям. Такое разделение, например, требуется компанией Sarbanes
Oxley (SOX) в США и настоятельно рекомендуется стандартом ISO 17799.
В системе должны быть отдельные приложения для администраторов и
для обычных пользователей. В OWASP Guide 2.0 рекомендуется, чтобы
приложения для администрирования веб-сайтов не были доступны из
Интернета без прохождения через некоторые сети управления, например,
через VPN со строгой аутентификацией или из доверенного сетевого
операционного центра.
За исключением администраторов, некоторая часть административных
интерфейсов также должна быть доступна сотрудникам службы поддержки,
поскольку они должны иметь возможность помогать клиентам, у которых
возникают проблемы при использовании клиентоориентированного веб­
сайта.
На приведенной ниже диаграмме вариантов использования верхнего
уровня показаны некоторые административные функции, которые может
предоставить административный веб-сайт.
Двумя действующими лицами, использующими административные
интерфейсы, являются администратор веб-сайта и служба поддержки (рис.
28.14.). Служба поддержки использует подмножество функций, доступных
администратору веб-сайта. Все показанные варианты использования
верхнего уровня являются абстрактными, поскольку каждый представляет
некоторую группу или «пакет» административной функциональности.
583
«Web Application»
Admin Website
Рис. 28.14. Диаграмма вариантов использования верхнего уровня для
веб-сайта администрирования.
Абстрактный вариант использования «Управление группами
пользователей» специализируется на вариантах использования «Создать
группу», «Обновить группу» и «Удалить группу» (рис. 28.15.). Идея
заключается в том, что администратор веб-сайта может создавать разные
группы пользователей, например, с разными привилегиями или опциями, а
впоследствии некоторые группы пользователей могут быть изменены или
даже удалены.
584
Рис. 28.15. Диаграмма вариантов использования управления группами
пользователей для веб-сайта администрирования.
Примеры использования управления пользователями доступны как для
администратора веб-сайта, так и для службы поддержки. Имеется
стандартный
пользовательский
набор
функций
CRUD
(создание,
извлечение/найти, обновление, удаление).
Два других варианта использования, «Заблокировать пользователя»
и «Разблокировать пользователя», относятся к безопасности веб-сайта
(рис. 28.16.). Например, если в течение некоторого предопределенного
периода времени было несколько неудачных попыток входа в систему с
использованием
неправильного
пароля
пользователя,
учетная запись
пользователя должна быть заблокирована на некоторое заранее определенное
время, чтобы предотвратить возможную атаку подбора пароля методом
грубой силы. Эта блокировка и разблокировка обычно выполняется
автоматически подсистемой обнаружения вторжений или аутентификации
веб-сайта, но на всякий случай эта функция должна быть доступна и в
ручном режиме. Например, какой-то пользователь может позвонить и
попросить заблокировать его или ее учетную запись.
585
«Web Application»
Рис. 28.16. Диаграмма вариантов использования управления
пользователями для веб-сайта администрирования.
Сеанс пользователя создается либо для каждого нового входящего
запроса,
который
еще
не
является
частью
сеанса,
либо/и
после
аутентификации пользователя (рис. 28.17.). Администратор веб-сайта должен
иметь возможность видеть, сколько сеансов было создано, включая
некоторую статистику по сеансам, находить конкретный сеанс и видеть его
статус, а также при необходимости отменять (удалять) какой-либо сеанс.
586
Рис. 28.17. Диаграмма вариантов использования управления сеансами
пользователей для веб-сайта администрирования.
Список административных функций, включенных в управление
журналом, зависит от требований безопасности, поддерживаемых и
реализуемых веб-сайтом.
Стандартным требованием безопасности (например, см. OWASP Guide
2.0) для журналов является то, что новые записи могут только добавляться, в
то время как старые записи журнала не должны перезаписываться или
удаляться. Это может быть реализовано, например, путем записи журналов
на устройство с однократной/многократной записью (WORM), такое как CDR.
Администратор веб-сайта должен иметь возможность видеть состояние
журналов. Статус может включать в себя проверку того, что ведение журнала
все еще работает (на диске достаточно места и/или подключение к базе
данных не устарело), и что старые файлы журнала по расписанию
перемещаются в постоянное хранилище для архивирования (рис. 28.18.).
587
Рис. 28.18. Диаграмма вариантов использования управления журналами
для веб-сайта администрирования.
Также распространено требование разрешить администратору веб­
сайта находить и просматривать некоторые записи журнала, относящиеся к
конкретному пользователю или исключительной ситуации.
11.2.7. Пример диаграммы вариантов использования UML для отчетов о
рентгенологической диагностике
Integrating the Healthcare Enterprise (IHE) — это инициатива,
продвигающая использование стандартов для достижения функциональной
совместимости систем медицинских информационных технологий (HIT) и
эффективного использования электронных медицинских карт (EHR).
IHE публикует руководства по внедрению под названием «Профили
IHE», включенные в соответствующую техническую структуру IHE после
успешного
тестирования
и
развертывания
в
реальных
условиях
здравоохранения.
Простой отчет по изображениям и числам (SINR) способствует
растущему использованию цифровой диктовки, распознавания голоса и
специализированных
пакетов
отчетов
588
за
счет
разделения
функций
диагностических отчетов на отдельных участников для создания, управления,
хранения и просмотра отчетов. Разделение этих функций при определении
транзакций для обмена отчетами между ними позволяет поставщику
включить одну или несколько из этих функций в реальную систему.
Техническая структура IHE (TF) идентифицирует участников IHE -
функциональные компоненты предприятия здравоохранения с точки зрения
их взаимодействия в распределенной среде здравоохранения. На диаграмме
ниже мы показываем акторы IHE как акторы UML, обозначенные как
классификаторы, отмеченные значком радиологии.
IHE TF также определяет набор скоординированных, основанных на
стандартах
между
взаимодействий
субъектами
IHE,
называемых
транзакциями IHE. Транзакции передают необходимую информацию с
помощью
стандартных
сообщений.
На
диаграмме
ниже
показаны
транзакции IHE как варианты использования UML.
Блок-схема диагностического отчета IHE описывает типичную
последовательность операций, связанных с диагностической отчетностью.
Транзакции IHE этого потока — от RAD-24 до RAD-27.
На начальном этапе
диагностического
отчета
лечащий
врач
записывает диагноз, создавая черновой объект структурированного отчета
(SR) DICOM. В транзакции отправки отчета субъект Report Creator
передает этот объект DICOM SR в исходном черновом или окончательном
состоянии диспетчеру отчетов. Объект структурированного отчета требуется
как минимум для соответствия шаблону TID 2000. Структурированные
отчеты
DICOM
предлагают
возможность
кодировать
произвольно
структурированные данные диагностического отчета.
Простой отчет с изображениями позволяет создавать документы с
несколькими разделами (с заголовками), содержащими текст отчета и ссылки
на соответствующие изображения. Некоторые текстовые элементы этих
документов также могут быть связаны с определенными изображениями. Это
позволяет читающему врачу идентифицировать одно или несколько
589
изображений, на основании которых были сделаны выводы. В отчетах такого
типа (иначе «шаблон контента») следует использовать
определение
информационного объекта SR основного текста DICOM (IOD) и шаблон
отчета о диагностике основного изображения (TID 2000 в DICOM 2011
PS3.16).
Простой отчет по изображениям и числам аналогичен простому
отчету по изображениям, но позволяет добавлять числовые значения (рис.
28.19.). Это позволяет включать в диагностику измерения и другие числовые
значения. В отчетах такого типа следует использовать шаблон отчета DICOM
Enhanced SR IOD и Basic Image Diagnostic Report (TID 2000 в DICOM 2011
PS3.16).
Рис. 28.19. Пример диаграммы вариантов использования UML для
отчетов о рентгенологической диагностике для простого изображения и
числового отчета (SINR) IHE Radiology Integration Profile.
590
Отчеты обрабатываются и модифицируются актером Report Manager
IHE. Это включает в себя добавление и изменение данных отчета, а также
проверку
черновиков
отчетов. Во
всех
случаях
любое
изменение
содержимого отчета диспетчером отчетов приводит к созданию нового
объекта DICOM SR. В любое время диспетчер отчетов может передавать
отчеты в репозиторий отчетов для внешнего доступа, но как минимум
окончательный отчет должен быть отправлен в репозиторий отчетов.
В транзакции «Выдача отчета» диспетчер отчетов передает либо
неизмененный черновик DICOM SR, либо новый модифицированный
DICOM SR в репозиторий отчетов. Диспетчер отчетов обрабатывает все
изменения состояния и содержимого структурированных отчетов DICOM, и
при каждом изменении создаются новые объекты структурированного отчета
DICOM, которые могут храниться в репозитории отчетов.
Репозиторий
отчетов
обеспечивает
постоянное
хранение
структурированных отчетов DICOM. Это также позволяет программам
чтения отчетов запрашивать и извлекать отчеты по всему предприятию.
Средство чтения отчетов предоставляет пользовательский интерфейс
для
просмотра
структурированных
отчетов
DICOM.
DICOM
SR
запрашиваются и извлекаются средством чтения отчетов из репозитория
отчетов или доступа к внешнему репозиторию отчетов.
Актер доступа к внешнему репозиторию отчетов является шлюзом
для получения отчетов других отделов предприятия, таких как лаборатория и
патология, из отдела визуализации.
В
транзакции
экспорта
структурированных
отчетов
[RAD-28]
диспетчер отчетов передает проверенные структурированные отчеты как
незапрошенные наблюдения HL7 в репозиторий корпоративных отчетов.
Репозиторий корпоративных отчетов получает диагностические отчеты в
формате HL7. Менеджер отчетов отвечает за сопоставление DICOM SR с
HL7.
591
11.2.8. Управление больницей
Цель: Описать основные услуги (функциональные возможности),
предоставляемые приемным отделением больницы.
Система
управления
больницей
—
это
большая
система,
включающая в себя несколько подсистем или модулей, обеспечивающих
различные функции. В приведенном ниже примере на диаграмме вариантов
использования UML показаны действующие лица и варианты использования
для приема в больнице.
Подсистема или модуль приема в больнице поддерживает некоторые
из многих рабочих обязанностей регистратора больницы (рис. 28.20.).
Регистратор записывает пациентов на прием и поступление в больницу,
собирает информацию от пациента по прибытии пациента и/или по телефону.
Для пациента, который будет находиться в больнице («стационар»), ему или
ей должна быть выделена койка в палате. Регистраторы также могут
получать платежи пациентов, записывать их в базу данных и предоставлять
квитанции, подавать страховые претензии и медицинские заключения.
«module»
Hospital Reception
Schedule Patient
Appointment
Schedule Patient
Hospital Admissicn
x
\
«extend» I
I
/
«extend» //
Patient Registration
Receptionist
«include»
Outpatient Hospital
Admission
Patient Hospital
Admission
Inpatient Hospital
Admission
«include»
Bed Allotment
File Insurance
Forms / Claims
File Medical Reports
Рис. 28.20. Пример диаграммы прецедентов для приемной больницы.
592
11.2.9. Защита программного обеспечения и лицензирование
Sentinel License Development Kit (Sentinel LDK) — это решение для
управления цифровыми правами на программное обеспечение (DRM) от
SafeNet Inc., которое обеспечивает надежную защиту от копирования, защиту
интеллектуальной собственности (IP),
а также безопасное и гибкое
лицензирование. Sentinel LDK отделяет процессы лицензирования и
производства (реализуемые с помощью Sentinel EMS) от процесса защиты
программного обеспечения (реализуемого с помощью Sentinel Licensing API
или Sentinel LDK Envelope).
Sentinel EMS — это графическое веб-приложение, предоставляемое как
часть Sentinel LDK, которое используется для выполнения ряда функций,
необходимых
для
управления
лицензированием,
производством,
распространением, поддержкой клиентов и обслуживанием защищенных
приложений. Это
управления
приложение
бизнес-операциями,
на основе ролей предназначено для
необходимыми
для
внедрения
и
обслуживания Sentinel LDK в организации, которой необходимо защитить
свое программное обеспечение. Sentinel EMS Server поддерживает базу
данных, содержащую широкий спектр информации, включая данные,
относящиеся к функциям продукта, лицензиям, продажам, заказам и
клиентам.
На приведенной ниже диаграмме вариантов использования (рис. 28.21.)
показано
упрощенное
представление
вариантов
использования
лицензирования программного обеспечения, поддерживаемых приложением
Sentinel EMS (обозначается как стереотипная тема «Приложение»). Sentinel
EMS обрабатывает три основных рабочих процесса:
•
лицензионное планирование,
•
обработка заказов и производство, а также
•
активация пробного ПО.
593
Рис. 28.21. Пример схемы использования UML для лицензирования
программного обеспечения с приложением Sentinel EMS.
Менеджер продукта определяет функции и продукты. Каждый продукт
имеет одну или несколько функций. После определения функций и
продуктов в Sentinel EMS права могут быть обработаны и созданы с
помощью группы функций «Производство».
Пользователи, которым назначена роль «Разработка», могут выполнять
одно из следующих действий, связанных с разработкой:
•
Создание пакетов предварительных (пробных) продуктов
594
•
Создание настроенного установочного файла Sentinel LDK Run-time
Environment (RTE)
•
Настройка утилиты Sentinel Remote Update System (утилита RUS)
Диспетчер прав определяет и управляет клиентами, а также вводит
права и управляет ими. Право — это выполнение заказа клиента на элементы
Sentinel LDK, и это может быть либо заказ на поставку Продуктов с одним
или несколькими ключами защиты Sentinel, либо Обновление ключа защиты,
в котором указываются изменения, которые необходимо внести в условия
лицензии и/или или данные, хранящиеся в ключах защиты Sentinel, которые
уже развернуты.
Роль обслуживания клиентов может управлять клиентами так же, как
это делает Entitlement Manager, а также может управлять активацией
продукта.
Для разрешений, которые генерируют ключи продукта, клиент
получает электронное письмо от Sentinel EMS, содержащее ключи. Клиент
может войти на Портал клиентов EMS, используя Ключ продукта, чтобы
активировать Продукт.
595
12. UML ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ
12.1. Покупки в интернет-магазине
Пример диаграммы деятельности для интернет-магазинов. Онлайн-
клиент может просматривать или искать товары, просматривать конкретный
товар, добавлять его в корзину, просматривать и обновлять корзину покупок,
оформлять заказ. Пользователь может просмотреть корзину в любое время.
Предполагается, что проверка включает регистрацию пользователя и вход в
систему.
В этом примере не используются разделы, предполагается, что
большинство действий выполняет онлайн-клиент (рис. 29.1.).
/ Online Shopping
[found]
Search
Items
[search]
[not found] I
View
Item
[made decision]
[browse]
Browse
Items
I
I
[proceed]
Shopping cart can be^
checked at any time
[view carl]
f Update
I Shopping Cart
V
Check
/ Shopping Cart
Proceed io
Checkout
—
[update
needed]
Checkout
View
Shopping Cart
[done with
shopping]
[more
shopping]
Рис. 29.1. Пример диаграммы деятельности UML для онлайн-покупок.
12.2. Обработка заказа на покупку
Пример действия бизнес-потока обработки заказа (рис. 29.2.).
Запрашиваемый заказ является входным параметром активности. После того,
как заказ принят и вся необходимая информация заполнена, оплата
принимается и заказ отправляется. Обратите внимание, что этот бизнес596
процесс позволяет отгрузить заказ до отправки счета или подтверждения
оплаты.
Рис. 29.2. Пример действия бизнес-потока для обработки заказа на
покупку.
В этом примере не используются разделы, поэтому неясно, кто
отвечает за выполнение каждого конкретного действия.
12.3. Процесс управления документами
Пример
диаграммы
действий
UML,
описывающий
процесс
управления документами. В любой крупной корпорации обычно требуется
какой-то формальный и должным образом сообщенный процесс управления
документами, особенно в соответствии с нормативными требованиями.
Документ проходит через разные состояния или этапы — он создается,
проверяется, обновляется, утверждается и в какой-то момент архивируется. В
этом процессе участвуют разные роли: Автор, Рецензент, Утверждающий и
Владелец (рис. 29.3.). Эти роли представлены на диаграмме разделами,
представленными в виде горизонтальных «плавающих дорожек».
597
Рис. 29.3. Пример деятельности процесса управления документами.
На этой диаграмме действий показаны обязанности различных ролей и
поток или последовательность изменений документа. Альтернативный тип
диаграммы — диаграмма конечного автомата — также может быть
использован в этом случае, чтобы показать, как документ изменяет свое
состояние с течением времени.
Обратите внимание, что объект «Документ» — не единственный узел
объекта, показанный на этой диаграмме действий. Существует также еще
один объект — Запрос на изменение, объект, который используется для
передачи изменений в документ, запрошенный Reviewer. Диаграмма
состояний для документа будет отображать только состояния и переходы
документа, поэтому диаграмма действий полезна, когда задействованы
разные роли и несколько узлов объектов.
12.4. Решение проблемы с программным обеспечением
Пример диаграммы действий UML, которая показывает, как решить
проблему в разработке программного обеспечения. После создания тикета
каким-либо
органом
и
воспроизведения
598
проблемы,
проблема
идентифицируется,
определяется
решение,
проблема
устраняется
и
проверяется, а тикет закрывается, если проблема была решена.
В этом примере не используются разделы, поэтому не очень понятно,
кто отвечает за выполнение каждого конкретного действия (рис. 29.4.).
Рис. 29.4. Пример диаграммы действий UML для решения проблемы в
разработке программного обеспечения.
12.5. Sentinel HASP SL — Активация пробного продукта
Пример диаграммы деятельности, описывающей ручную активацию
пробного (предварительного) продукта, защищенного программным ключом
Sentinel HASP SL решения Sentinel HASP - защиты программного
обеспечения и безопасности лицензирования.
599
Sentinel HASP защищает от убытков от компьютерного пиратства и
кражи интеллектуальной собственности. Например, он предлагает лучшую в
отрасли поддержку лицензирования в виртуальных средах и является первым
на рынке инструментальным решением для лицензирования программного
обеспечения и защиты от обратного проектирования, которое поддерживает
приложения J2EE.
Программное обеспечение Sentinel HASP включает в себя Business
Studio — мощный инструмент лицензирования и управления программным
обеспечением на основе ролей. Business Studio используется специалистами
по продукту, маркетингу и разработке для подготовки программного
продукта к выходу на рынок и включает в себя все инструменты,
необходимые для лицензирования и привязки приложения к аппаратному
ключу продукта Sentinel HASP HL или программному продукту HASP SL,
для управления и отслеживания лицензий, создавать ключи продукта,
которые впоследствии используются для процесса активации продукта и т. д.
Три
раздела
вертикальных
деятельности
дорожек
и
показаны
представляют
на
диаграмме
актеров,
в
виде
участвующих
в
деятельности — управление заказами, обслуживание клиентов и клиент.
У клиента установлен пробный продукт,
например,
игра или
инструмент, который имеет определенный пробный период и может иметь
некоторые ограниченные функции или опции. После использования продукта
в течение некоторого времени клиент решает активировать продукт,
запросив постоянную полную лицензию на продукт (рис. 29.5.).
600
Customer
Request
Activation
Generate
Business Studio
-> Manage Orders
Product Key
Activate
Product
Business Studio
-> Manage Activation
HASP SRM-> Ц
V
Admin Center
z
z
Рис. 29.5. Пример диаграммы деятельности по ручной активации
пробного продукта, защищенного HASP SL.
601
Менеджер по заказам должен будет создать новый ключ активации для
продукта, в то время как клиент может создать и отправить файл C2V
(«компьютерный отпечаток пальца»). Как только новый ключ продукта и
файл C2V станут доступными для службы поддержки клиентов, она сможет
активировать продукт, сгенерировать файл V2C и вернуть его клиенту.
Клиент применяет полученную лицензию и таким образом активирует
установленный пробный продукт, чтобы он стал полноценным продуктом.
Продукт может быть защищен от копирования на другие компьютеры или
виртуальные машины с помощью лицензии HASP SL и ключа защиты.
12.6. Единый вход для Google Apps
Пример UML диаграммы деятельности, описывающей единый вход
(SSO) в Google Apps.
Для взаимодействия с компаниями-партнерами Google использует
систему единого входа на основе протокола OASIS SAML 2.0. Google
выступает в качестве поставщика услуг с такими службами, как Gmail или
стартовые страницы (рис. 29.6.). Компании-партнеры выступают в качестве
поставщиков удостоверений и контролируют имена пользователей, пароли и
другую информацию, используемую для идентификации, аутентификации и
авторизации пользователей для веб-приложений, которые размещает Google.
Каждый партнер предоставляет Google URL-адрес своей службы SSO, а
также открытый ключ, который Google будет использовать для проверки
ответов SAML.
602
Рис. 29.6. Пример UML диаграммы деятельности для единого входа в
Google Apps.
603
Когда пользователь пытается использовать какое-либо размещенное
приложение
Google,
например,
Gmail,
Google
генерирует
запрос
аутентификации SAML и отправляет запрос перенаправления обратно в
браузер
пользователя.
Перенаправление
указывает
на
конкретного
поставщика удостоверений. Запрос аутентификации SAML содержит
закодированный URL-адрес приложения Google, к которому пытается
обратиться пользователь.
Поставщик удостоверений партнера аутентифицирует пользователя,
либо запрашивая действительные учетные данные для входа, либо проверяя
свои собственные действительные файлы cookie для аутентификации.
Партнер создает ответ SAML и подписывает его цифровой подписью. Ответ
направляется в службу поддержки утверждений Google (ACS).
ACS Google проверяет ответ SAML, используя открытый ключ
партнера. Если ответ действителен и личность пользователя подтверждена
поставщиком удостоверений, ACS перенаправляет пользователя на целевой
URL-адрес. В противном случае пользователь увидит сообщение об ошибке.
12.7. Электронный рецептурный сервис
Это пример диаграммы активности для электронных рецептов. Этот
пример основан на документации для впечатляющей версии 2 службы
электронных рецептов (EPS), разработанной NHS Connecting for Health (NHS
CFH) в рамках Национальной программы по ИТ в Национальной службе
здравоохранения (NHS) в Англии. Обратите внимание, что эта страница
представляет собой неформальный пример диаграммы UML. Пожалуйста,
обратитесь к NHS CFH, чтобы получить ряд официальных сообщений и
руководств.
Служба электронных рецептов позволяет лицам, выписывающим
рецепты, таким как врачи общей практики (GP) и практикующие медсестры,
отправлять рецепты в электронном виде в пункт выдачи (например, в
аптеку) по выбору пациента.
604
Как и во всех службах NHS Connecting for Health, доступ к EPS
контролируется с помощью смарт-карты NHS, на которой напечатано имя
пользователя, фотография и уникальный идентификационный номер, а также
со
встроенным
смарт-чипом.
Смарт-карта
предоставляет
отдельным
пользователям различные уровни доступа в зависимости от их роли.
Врач, выписывающий рецепт, входит в клиническую систему,
используя свою смарт-карту и код доступа, выбирает лекарство или
медицинский прибор для пациента, добавляет подтверждение назначения,
где это необходимо, и применяет электронную подпись для авторизации
электронного рецепта. Электронный рецепт передается в ЭПС. Жетон
рецепта печатается там, где это необходимо. Уполномоченное лицо вручает
рецептурный жетон пациенту при необходимости.
Бумажные копии электронных рецептов называются жетонами (рис.
29.7.). Они действуют как печатная копия сведений, содержащихся в
электронном рецепте. Существует два типа жетонов — «жетоны рецепта» и
«жетоны выдачи». Когда EPS будет полностью внедрена, бумажные копии
электронных рецептов больше не понадобятся, но они по-прежнему должны
быть доступны по запросу, когда это необходимо.
605
Patent
Prescriber
Create
electronic
Reimbursement
Agency
Dispenser
Electronic
prescription
]^
r
h-
Electronic
MionZ
prescription
Store
electronic
Д prescription J
^prescri ption
---------------------- . Prescription
f Request
Provide with 'itoken
prescription 3
prescription
token
у
Items
Prescription T
token X-
f
Retrieve
АН—1
electronic
J-
-E>£
prescription J
Provide
electronic
prescription
T
Prescription
Dispense
prescription
Prescription
Get
[items
prescription 3^--------------
Items
RecordI
prescription
status
X__ ZL
__ /
U Prescription
[complete]
у
I
Dispense
\
A
notification
/
"у notification
Get
schedule
Д
J
Dispense
X
Schedule
endorsement
ч____ _ _______ 7
Z
j—
On schedule
Reimbursement
\
A Reimbursement
endorsement
/~
■y
endorsement
Рис. 29.7. Пример диаграммы активности UML для электронных
рецептов.
Диспансер (или подрядчик по выдаче) — это любая организация,
которая выдает рецепты первичной медико-санитарной помощи NHS
пациентам, например, общественная аптека, подрядчик по выдаче устройств
606
или врач общей практики, выдающий лекарства. С EPS только рецепты,
отправленные
пациентом
назначенному
дистрибьютору,
могут
быть
подписаны и отправлены в электронном виде.
Диспенсер извлекает электронные рецепты из EPS. Это можно сделать
тремя способами: либо путем автоматической загрузки (например, в
либо
одночасье),
путем
ввода
ручного
рецепта,
идентификатора
напечатанного на жетоне, либо путем сканирования штрих-кода на жетоне
рецепта. При необходимости распечатывается жетон выдачи. Рецептурные
препараты выдаются пациенту или представителю пациента.
Диспетчер должен зафиксировать статус каждого рецептурного
наименования
как
один
«причитается»
или
«частично».
из
следующих:
Чтобы
«не
выдано»,
процесс
выдачи,
«выдано»,
завершить
необходимо заполнить весь рецепт, а это означает, что все прописанные
предметы должны быть помечены как «выданные» или «не выданные».
Некоторые
клинические
системы
автоматически
записывают
статус
выданных предметов.
Если
процесс
выдачи
завершен,
диспансер должен отправить
уведомление о выдаче в службу электронных рецептов. Сообщение
информирует EPS о том, какое лекарство было/не было доставлено пациенту.
Для фармацевтов будет выпущен график, по которому следует подавать
электронное сообщение об одобрении возмещения. Электронное сообщение
с подтверждением возмещения может быть отправлено только после того,
как для электронного рецепта отправлено сообщение с уведомлением о
выдаче.
Для поддержки процесса подачи заявки на возмещение, EPS позволит
фармацевтам отправлять в электронном виде сообщения об одобрении
возмещения в агентство по возмещению выданных электронных рецептов,
чтобы агентство по возмещению могло произвести платеж. Сообщения
отправляются в соответствии с расписанием рамбурсного агентства.
607
12.8. Автомат по продаже билетов
Это
пример
диаграммы
активности
UML,
описывающей
поведение варианта использования «Покупка билета».
Активность начинает пригородный актер, которому нужно купить
билет. Автомат по продаже билетов запросит информацию о поездке у
Commuter. Эта информация будет включать количество и тип билетов,
например, месячный проездной билет, билет в один конец или туда и
обратно, номер маршрута, номер пункта назначения или зоны и т. д.
На основании предоставленной информации о поездке автомат по
продаже билетов рассчитает платеж и запросит варианты оплаты (рис. 29.8.).
Эти варианты включают оплату наличными, кредитной или дебетовой
картой. Если оплата картой была выбрана Commuter, другой участник, банк,
будет участвовать в операции, авторизуя платеж.
608
Ticket vending machine
Commuter
/
Request
Trip Info
Start Session
4________ ?
Provide
Trip Info
Provide
Payment Info
\
____ ______ У
J
Z----------------------л
-
Bank
Process
Trip Info
f
Request
Payment
ч___ ___ _____у
------------------------- \
Process
Payment
[pay with card]
[pay with
cash]
------------ ------------
Authorize
Card Payment
4_____ _ _______ у
( Dispense Ticket 'l
Ticket dr­
Get
Ticket
'X
<___ __ /
[paid with cash
& with change]
Dispense
Change
k__________ У
change dGet
Change J
z------- -------- X
Show
Thank You
4________________ У
Рис. 29.8. Пример поведения варианта использования «Покупка билета»,
описанного с помощью диаграммы действий UML.
609
После оплаты билет выдается пассажиру. При оплате наличными
может потребоваться сдача, поэтому в этом случае сдача выдается
пассажиру. Автомат по продаже билетов покажет экран «Спасибо» в конце
мероприятия.
610
13. UML ДИАГРАММЫ КОНЕЧНОГО АВТОМАТА
13.1. Водные фазы
Это пример диаграммы состояния воды, представленной в виде
диаграммы конечного автомата UML.
Вода
может
находиться
в
нескольких
состояниях - жидком,
парообразном, твердом и плазменном (рис. 30.1.). Возможны несколько
переходов из одного состояния в другое. Например, замерзание — это
фазовый переход от жидкого состояния к льду. Конденсация - это фазовый
переход из парообразного состояния в жидкое. Водяной пар может
превратиться непосредственно в иней в результате осаждения.
Рис. 30.1. Пример конечного автомата UML — диаграмма водной фазы.
13.2. Банкомат
Это пример схемы поведенческого конечного автомата UML,
показывающий конечный автомат верхнего уровня банкомата (ATM).
611
Банкомат изначально выключен. После включения питания банкомат
выполняет действие запуска и переходит в состояние самотестирования .
Если тест не пройден, банкомат переходит в состояние Out of Service , в
противном случае происходит бестриггерный переход в состояние Idle . В
этом состоянии банкомат ожидает взаимодействия с клиентом.
Состояние банкомата изменяется с «Неактивный» на «Обслуживает
клиента», когда клиент вставляет банковскую или кредитную карту в
устройство чтения карт банкомата (рис. 30.2.). При входе в состояние
«Обслуживающий
клиент»
выполняется
действие входа
readCard.
Обратите внимание, что переход из состояния «Обслуживание клиента»
обратно в состояние «Бездействие» может быть вызван событием отмены,
поскольку клиент может отменить транзакцию в любое время.
Рис. 30.2. Пример UML-диаграммы поведенческого конечного автомата
— банковский банкомат.
612
Состояние обслуживания клиента — это составное состояние с
последовательными подсостояниями «Аутентификация клиента», «Выбор
транзакции» и «Транзакция» . Аутентификация клиента и транзакция
сами по себе являются составными состояниями, которые отображаются
скрытым значком индикатора декомпозиции. Состояние «Обслуживающий
клиент» имеет неактивный переход обратно в состояние «Простой» после
завершения транзакции. У состояния также есть действие выхода ejectCard,
которое высвобождает карту клиента при выходе из состояния, независимо
от того, что вызвало переход из состояния.
13.3. Состояния потоков Java и жизненный цикл
Это
пример
схемы
конечного
автомата
протокола
UML,
показывающий состояния потока и жизненный цикл потока для класса
Thread в Java™. Поток — это легковесный процесс, наименьшая единица
запланированного
выполнения.
Состояние
потока —
это
состояние
виртуальной машины Java (JVM), сообщаемое JVM программе Java, оно не
отражает состояние потока операционной системы (ОС). В любой момент
времени экземпляр класса Thread в Java 5 — Java 9 может находиться в
одном из следующих состояний Thread:
•
New (новый),
•
Runnable (Запускаемый),
•
Timed waiting (Время ожидания),
•
Waiting (Ожидание),
•
Blocked (Заблокирован),
•
Terminated (Прекращено).
Теперь устаревшая Java 2 имела другой набор состояний: Ready,
Running , Suspended , Sleeping , Blocked , Monitor. На приведенной ниже
613
диаграмме UML показаны два из этих устаревших состояний — Ready и
Running — как часть состояния Runnable (рис. 30.3.).
Рис. 30.3. Пример конечного автомата протокола — состояния потока и
жизненный цикл в Java.
New — это состояние потока для потока, который был создан, но еще
не запущен.
Поток в состоянии Runnable выполняется с точки зрения JVM, но на
самом деле он может ожидать от ОС некоторых ресурсов, таких как
процессор. Это состояние можно рассматривать как составное состояние с
двумя подсостояниями. Когда поток переходит в состояние Runnable, поток
сначала переходит в подсостояние Ready. Планирование потока решает,
когда поток может фактически запуститься. Thread.yield() является явной
рекомендацией планировщику потоков приостановить выполнение текущего
614
потока, чтобы разрешить выполнение другого потока. Нить жива, если она
была запущена и еще не умерла.
Timed waiting (Временное ожидание) — это состояние потока для
потока, ожидающего заданное время ожидания. Поток переходит в состояние
ожидания по времени из-за вызова одного из следующих методов с заданным
(положительным) временем ожидания:
•
Thread.sleep(время сна)
•
ОЬ|ей^аЬ(время ожидания)
•
Thread.join(время ожидания)
•
LockSupport.parkNanos(время ожидания)
•
LockSupport.parkUntil(время ожидания)
Поток переходит в состояние Waiting (ожидания) после вызова одного
из следующих методов без тайм-аута:
•
Object.wait()
•
Thread.join()
•
LockSupport.park()
Обратите внимание, что поток в состоянии ожидания бесконечно
ожидает,
пока
другой
поток
предоставит
что-то,
что
необходимо
ожидающему потоку. Как только это будет сделано, этот другой поток может
вызвать Object.notify() или Object.notifyAll() для
используемого
потоками.
Поток,
вызвавший
объекта, совместно
Thread.join(),
ожидает
завершения указанного потока. Это означает, что состояние ожидания можно
сделать составным состоянием с состояниями, соответствующими этим
конкретным условиям.
615
Поток находится в состоянии Blocked, ожидая, пока блокировка
монитора войдет в синхронизированный блок или метод, или повторно
войдет в синхронизированный блок или метод после вызова Object.wait().
Синхронизированный оператор или метод получает блокировку
взаимного исключения от имени выполняющегося потока, выполняет блок
или метод, а затем снимает блокировку. Пока выполняющийся поток владеет
блокировкой, никакой другой поток не может получить блокировку и
блокируется в ожидании блокировки.
После того, как поток завершил выполнение метода run(), он переходит
в состояние Terminated .
13.4. Java EJB — жизненный цикл объекта сеанса
Это пример схемы конечного автомата протокола UML, на которой
показан жизненный цикл объекта сеанса Java™ EJB с точки зрения
локального или удаленного клиента, использующего Java EJB 2.1 и более
ранние версии API клиентского представления (рис. 30.4.).
Рис. 30.4. Жизненный цикл Java EJB объекта сеанса — пример схемы
конечного автомата протокола UML.
С точки зрения локального или удаленного клиента, использующего
EJB 2.1 и более ранние версии API клиентского представления, жизненный
616
цикл объекта сеанса показан ниже. Объект сеанса не существует, пока он не
создан. Когда клиент создает объект сеанса, у клиента есть ссылка на
интерфейс компонента вновь созданного объекта сеанса.
13.5. Интернет-магазин - учетная запись пользователя
Каждая компания, имеющая клиентов, ведет учетные записи клиентов
и поддерживает полный жизненный цикл учетной записи от ее создания до ее
закрытия. Существуют различия в том, каковы этапы (состояния) жизненного
цикла учетной записи и какие условия или события вызывают изменение
состояния учетной записи.
Здесь мы приводим пример жизненного цикла учетной записи
пользователя в контексте онлайн-покупок, показанный в виде диаграммы
конечного автомата протокола UML.
Чтобы учетная запись пользователя была создана, она должна
соответствовать
некоторым
первоначальным
требованиям.
Например,
идентификатор пользователя (используемый в качестве имени для входа)
должен быть уникальным, по крайней мере, для существующих учетных
записей (рис. 30.5.). После создания учетной записи может потребоваться ее
проверка. Проверка зависит от компании и может включать проверку
электронной почты, телефона и/или адреса. Если учетная запись не была
проверена в течение определенного заранее определенного периода времени,
эта учетная запись может быть перемещена в приостановленные учетные
записи.
617
Рис. 30.5. Диаграмма состояния протокола учетной записи пользователя
в интернет-магазине.
Новые, активные или приостановленные учетные записи могут быть
аннулированы в любое время по запросу клиента. Обратите внимание, что
предварительное условие для этого обычно включает в себя оплату любых
непогашенных остатков и может потребовать отдельного состояния счета
или подсостояния для обработки этого случая.
Учетная
запись
пользователя
может
быть
заблокирована
по
соображениям безопасности вручную или автоматически. Например, система
обнаружения вторжений на веб-сайт блокирует учетную запись пользователя
618
на заданный период времени, если было несколько неудачных попыток входа
с использованием неверного пароля учетной записи. По истечении времени
блокировки
учетной
записи
учетная
запись
снова
активируется
автоматически.
Некоторые учетные записи пользователей могут быть неактивны в
течение длительного периода времени. Политика компании или бизнесправила могут потребовать перевода таких неактивных учетных записей на
год или два в приостановленное состояние.
После того, как мы перечислили состояния учетных записей пользователей и
указали все возможные переходы из одного состояния в другое, мы можем
просмотреть диаграмму с другими экспертами в предметной области, чтобы
увидеть, не упущено ли что-то или требуются дополнительные разъяснения.
13.6. Жизненный цикл размещенного приложения DICOM Application
Hosting API
Пример диаграммы конечного автомата протокола UML для
DICOM Application Hosting API. API хостинга приложений DICOM был
опубликован в Стандарте цифровых изображений и коммуникаций в
медицине (DICOM), часть 19 Хостинг приложений (PS 3.19-2011). Пример,
показанный ниже, является нашей собственной интерпретацией API.
Официальное описание и схемы см. в стандарте DICOM.
Часть 19 стандарта DICOM определяет интерфейс прикладного
программирования (API) между двумя программными приложениями —
Hosting System и Hosted Application, причем оба приложения обмениваются
медицинскими данными, находясь в одной системе.
Хостинг -система (хост) (также известная как хост-приложение) — это
приложение, используемое для запуска и управления размещенными
приложениями. Хостинг-система предоставляет множество услуг, таких как
поиск и хранение объектов DICOM для размещенного приложения. Хост619
приложение предоставляет размещенному приложению данные, такие как
набор медицинских изображений и соответствующие метаданные.
Размещенное приложение
(Приложение)
—
это
приложение,
запускаемое и управляемое системой хостинга, которое также может
использовать некоторые услуги, предлагаемые системой хостинга. Процессы
размещенных
приложений
потенциально
возвращая
медицинские
предоставляли
некоторые
вновь
данные,
сгенерированные данные,
например, в виде другого набора изображений и/или структурированных
отчетов, в приложение размещения.
Хост-система имеет механизм для запуска или подключения к одному
или
нескольким
размещенным
приложениям,
проверки
того,
что
размещенное приложение успешно запущено, а затем передачи исходных
объектов данных (рис. 30.6.). Конечный пользователь запускает систему
хостинга, и все последующие взаимодействия начинаются в системе
хостинга.
Рис. 30.6. Пример схемы конечного автомата протокола UML,
жизненный цикл размещенного приложения DICOM.
620
Хост-система инициализирует размещенное приложение, выполнив
команду run или exec или ее эквивалент. После инициализации размещенного
приложения его состояние становится состоянием бездействия (Idle).
Приложение должно уведомлять хост о любых изменениях состояния,
вызывая метод notifyStateChanged(), но сам этот метод не является частью
какого-либо перехода состояния.
Находясь в состоянии IDLE, размещенное приложение ожидает нового
назначения задачи от хост-системы.
Как только размещенное приложение начинает выполнять какую-либо
назначенную задачу, оно меняет свое состояние на InProgress.
После завершения обработки приложение переходит в состояние
«Выполнено» (Suspended). В этом состоянии он ожидает, пока хост получит
доступ ко всем выходным данным из размещенного приложения, и после
этого освобождает все ресурсы.
Приложение также может быть приостановлено. В этом состоянии
обработка текущей задачи останавливается и высвобождается максимально
возможное количество ресурсов. Тем не менее, размещенное приложение
должно
хранить
столько
информации,
сколько
необходимо
для
возобновления обработки.
Приложение могло перейти в состояние «отменено» (Canceled) либо
по входящему запросу на отмену задачи, либо в случае, когда приложение
сталкивается
с
нефатальной
ошибкой,
препятствующей
дальнейшей
обработке текущей задачи, но сохраняющей возможность обработки другой
задачи.
В состоянии «отменено» (Canceled) приложение останавливает всю
обработку и должно освободить все ресурсы. Нет возможности возобновить
обработку отмененной задачи из этого состояния.
621
Состояние выхода (Exit) — это конечное состояние размещенного
приложения.
622
14. UML ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ
14.1. Книжный интернет-магазин
Пример диаграммы последовательности высокого уровня для
книжного интернет-магазина (рис. 31.1.). Онлайн-клиент может искать в
каталоге книг, просматривать описание выбранной книги, добавлять книгу в
корзину, оформлять заказ.
Рис. 31.1. Пример диаграммы последовательности UML для онлайнкнижного магазина.
623
14.2. Отправление комментариев в Pluck
Пример диаграммы последовательности, которая показывает, как
пользовательские комментарии к некоторой статье отправляются в Pluck с
использованием различных технологий AJAX.
Комментарии, представленные пользователем, сначала проверяются
веб-сайтом, на котором размещаются статьи. Технология DWR (AJAX для
Java) используется для преобразования пользовательских комментариев
данных формы HTML в объект Java и возможных ошибок проверки —
обратно в обратные вызовы JavaScript для ошибок.
Комментарии, которые выглядят нормально, отправляются на сервер
Pluck, на котором размещены все комментарии ко всем статьям (рис. 31.2.). В
этом случае также используется технология AJAX как для отправки
нового комментария, так и для возврата списка всех последних комментариев
(включая новый). JSON используется для получения комментариев.
Рис. 31.2. Отправление комментариев в Pluck, используя DWR, AJAX,
JSON — пример диаграммы последовательности UML.
624
На этой диаграмме также показаны некоторые ограничения по
продолжительности. Стоит отметить, что указанные ограничения являются
фиктивными и не описывают никакого реального общения. Например,
согласно диаграмме, время ожидания обратного вызова для опубликованного
комментария варьируется от 1 до 4 секунд. В то же время запрос всех
опубликованных комментариев занимает всего до 100 мс.
14.3. Веб-аутентификация пользователей Facebook
Пример диаграммы последовательности UML, которая показывает,
как пользователь Facebook (FB) может быть аутентифицирован в веб­
приложении, чтобы разрешить доступ к его/ее ресурсам FB. Facebook
использует структуру протокола OAuth 2.0,
которая позволяет веб­
приложению (так называемому «клиенту»), которое обычно не является
владельцем ресурса FB, но действует от имени пользователя FB, запрашивать
доступ к ресурсам, контролируемым пользователем FB и размещенным на
сервере FB. Вместо использования учетных данных пользователя FB для
доступа к защищенным ресурсам веб-приложение получает токен доступа.
Веб-приложение должно быть зарегистрировано Facebook, чтобы иметь
идентификатор приложения (client_id) и секрет (client_secret). При получении
запроса
к
некоторым
(«пользовательский
защищенным
агент»)
ресурсам
перенаправляется
на
Facebook
веб-браузер
сервер
авторизации
Facebook с идентификатором приложения и URL-адресом, на который
пользователь
должен
быть
перенаправлен
обратно
после
процесса
авторизации.
Пользователь получает форму Запроса на разрешение (рис. 31.3.). Если
пользователь разрешает приложению
получить свои данные,
сервер
авторизации Facebook перенаправляет обратно на указанный ранее URI
вместе с кодом авторизации («строка подтверждения»). Веб-приложение
может обменять код авторизации на токен доступа OAuth.
625
Рис. 31.3. Пример диаграммы последовательности UML для
аутентификации пользователя Facebook.
Если веб-приложение получает токен доступа для пользователя FB, оно
может выполнять авторизованные запросы от имени этого пользователя FB,
включая токен доступа в запросы API Facebook Graph. Если пользователь не
626
авторизовал
веб-приложение,
отправляет
Facebook
запрос
на
перенаправление на указанный ранее URI и добавляет параметр error_reason,
чтобы уведомить веб-приложение об отклонении запроса на авторизацию.
14.4. Управление транзакциями Spring и Hibernate
Среда разработки приложений Spring для предприятия Java™
интегрирует управление транзакциями Hibernate. Здесь мы приводим
пример диаграммы последовательности UML, которая иллюстрирует
управление транзакциями по отношению к обработке исключений.
Когда вызывается какой-либо бизнес-метод, он может быть перехвачен
Spring Transaction Interceptor. Этот перехватчик за кулисами создает сеанс
Hibernate и запускает Hibernate JDBC-транзакцию, поэтому бизнес-метод
будет выполняться в контексте новой транзакции.
Выполнение бизнес-метода может завершиться (успешно или нет) без
создания
каких-либо
исключений
или
путем
создания
некоторого
(непроверенного) исключения среды выполнения Java или некоторого
бизнес-исключения (проверенного) (рис. 31.4.).
627
Рис. 31.4. Транзакции Spring и Hibernate с обработкой исключений,
показанной в виде диаграммы последовательности UML.
Если бизнес-метод не выдал никакого исключения или выдал какое-то
бизнес-исключение
(проверено),
перехватчик
транзакции
попытается
зафиксировать транзакцию. Когда транзакция Hibernate JDBC сбрасывается
(для постоянного хранения данных), эта операция может завершиться
неудачно, например, из-за нарушения какого-либо ограничения базы данных.
В этом случае транзакция будет отменена (даже если выполнение бизнес-
метода прошло успешно).
628
Если бизнес-метод выдал какое-то исключение времени выполнения
Java (непроверенное), это указывает на сбой бизнес-метода, и перехватчик
транзакции откатит транзакцию.
В конце сеанс Hibernate будет закрыт Spring Transaction Interceptor.
629
15. ВРЕМЕННАЯ UML ДИАГРАММА
15.1. Временная шкала стадий болезни Альцгеймера
Назначение: показать временную шкалу/стадии болезни Альцгеймера
в виде временной диаграммы UML.
Резюме:
Для
болезни
Альцгеймера
врач
может
использовать
диагностическую схему с тремя-семью уровнями (стадиями). Прохождение
этих стадий может длиться от 8 до 10 лет, а в некоторых случаях и до 20 лет с
момента начала изменения нейронов. Пример временной диаграммы UML
показывает синхронизацию для семиэтапной структуры.
Пример временной диаграммы медицинской области, показывающей
стадии
болезни Альцгеймера.
Болезнь
Альцгеймера
(БА) —
это
прогрессирующее, в конечном итоге смертельное заболевание головного
мозга, вызывающее потерю памяти и интеллектуальных способностей.
Причина заболевания неизвестна. AD не лечится и является одной из
основных причин смерти в Соединенных Штатах.
Для болезни Альцгеймера врач может использовать диагностическую
схему с тремя-семью уровнями (стадиями). Прохождение этих стадий может
длиться от 8 до 10 лет, а в некоторых случаях и до 20 лет с момента начала
изменения нейронов.
Пример временной диаграммы ниже показывает временные рамки для
семиэтапной схемы (рис. 32.1.). Обратите внимание, что это пример
диаграммы UML, и его не следует рассматривать в качестве медицинского
справочника по заболеванию. Медицинские подробности приведены здесь
только для того, чтобы помочь лучше понять схему.
630
Рис. 32.1. Пример временной диаграммы — стадии болезни
Альцгеймера.
Структура семи стадий болезни Альцгеймера включает следующие
стадии:
•
Без нарушений, нормальное состояние.
Память и когнитивные способности кажутся нормальными.
•
Нормальная возрастная забывчивость.
Половина или более лиц старше 65 лет испытывают субъективные
жалобы на когнитивные и/или функциональные трудности, например, они
больше не могут вспомнить имена так же хорошо, как 5 или 10 лет назад.
•
Ранняя спутанность сознания, легкие когнитивные нарушения.
Проблемы с поиском слов, планированием, организацией, потерей
предметов и забыванием недавних знаний влияют на домашнюю и рабочую
среду. Продолжительность 2-7 лет.
•
Поздняя
спутанность
сознания,
легкая
форма
болезни
Альцгеймера.
Недавние события и разговоры все чаще забываются. Все еще знает
себя и семью, но имеет проблемы с выполнением последовательных задач,
631
включая приготовление пищи, вождение автомобиля и управление домом.
Продолжительность около 2 лет.
•
Ранняя деменция, умеренная болезнь Альцгеймера.
Больше не может самостоятельно управлять в сообществе. Невозможно
вспомнить детали личной истории и контактную информацию. Часто
дезориентированы в пространстве и/или во времени. Продолжительность
около 1,5 лет.
•
Средняя
деменция,
умеренно
тяжелая
форма
болезни
Альцгеймера.
Полное
нынешних событиях
отсутствие осведомленности о
неспособность
точно
вспомнить
Потерял
прошлое.
и
способность
самостоятельно одеваться и мыться. Длится примерно 2,5 года.
•
Поздняя или тяжелая деменция, задержка развития.
Сильно ограниченные интеллектуальные способности. Общайтесь с
помощью коротких слов или криков. Здоровье значительно ухудшается,
поскольку системы организма начинают отключаться. Продолжительность от
1 до 2,5 лет.
15.2. Задержка веб-сайта
Назначение: пример временной диаграммы UML, которая показывает
некоторые ограничения продолжительности для веб-сайта, чтобы оценить,
как
долго
веб-пользователь
может
ждать,
чтобы
увидеть
что-то,
отображаемое на его / ее дисплее.
Резюме: после того, как веб-пользователь вводит URL-адрес какойлибо веб-страницы, этот URL-адрес преобразуется в IP-адрес. Servlet Java
получает управление и запрашивает некоторые данные из «модели». Веб­
браузеру требуется некоторое время для обработки ответа HTTP и HTML-
страницы, чтобы начать отображение страницы.
632
Пример временной диаграммы, которая показывает некоторые
ограничения продолжительности для сфабрикованного веб-сайта, чтобы
оценить, как долго веб-пользователь должен ждать, чтобы увидеть что-то,
отображаемое на его / ее дисплее.
После того, как веб-пользователь вводит URL-адрес веб-страницы,
URL-адрес должен быть преобразован в какой-либо IP-адрес. Разрешение
DNS может добавить некоторое ощутимое время ожидания к задержке
ответа, воспринимаемой пользователем. Задержки задержки, связанные с
разрешением DNS, могут варьироваться от 1 мс (локальный кеш DNS) до
нескольких секунд.
С помощью простой реализации Model-View-Control (MVC) Servlet
Java получает управление и запрашивает некоторые данные из «модели».
Связь с источниками данных обычно занимает определенное время. После
того, как данные получены и обработаны, Servlet перенаправляет обработку
запроса в JSP («представление»). Буферизованный ответ HTTP отправляется
обратно в браузер.
Веб-браузеру требуется некоторое время для обработки HTTP-ответа и
HTML-страницы, чтобы начать отображение страницы в веб-клиенте (рис.
32.2.).
(Обратите
внимание,
что
после
этого
веб-браузеру
может
потребоваться еще больше времени для запроса других ресурсов, таких как
CSS, JavaScript, изображения, что не показано на диаграмме.)
633
Рис. 32.2. Пример временной диаграммы — задержка веб-сайта для
пользователей.
15.3. Система доступа банковского терминала
На рисунке ниже представлена временная диаграмма работы системы
доступа банковского терминала (рис. 32.3.).
634
Рис. 32.3. Пример временной диаграммы UML с работой системы
доступа банковского терминала.
В верхнем левом углу обычно подписывают название, в данном случае
это просто «td Timing diagram».
Нижняя горизонтальная линия, размеченная на отрезки цифрами, временная шкала. «Time(ms)» - указывает на то, что отрезки времени указаны
в данной диаграмме в миллисекундах.
Пространство между названием и временной шкалой разделено на 3
блока: «User», «ACSystem», «UserAccepted» - это 3 компонента системы
выбранного нами процесса.
Рассмотрим составные части диаграммы на примере компонента
«User»:
Линия с подъёмами и спусками - это линия жизни. Линия жизни обозначает переход из одного состояния в другое. Это достигается путём
изменения уровня, показанного на линии жизни.
«WaitAccess», «WaitCard», «Idle» - это состояния: «Ожидание доступа»,
«Ожидание карты», «Бездействие». в течение периода времени, когда объект
635
находится в данном состоянии, временная шкала проходит параллельно
этому состоянию.
Подпись «Code» - стимул. При его появлении происходит событие,
вызывающее изменение состояния.
«d...d*3» - ограничение продолжительности. Используется, когда мы
не можем точно определить временные рамки того или иного состояния.
Прочитаем данную диаграмму:
Диаграмма
бездействия
начинается с
пользователя. Этому же
состоянию соответствует бездействие блока «Доступ пользователя» и «нет
карты» в системе доступа. Состояние «бездействие» длится 35 секунд. Мы
можем оценить это по временной шкале в нижнем блоке. Далее состояние
меняется на «Ожидание карты» (подъём ступенькой выше в блоке
«Пользователь»). После ввода пароля система доступа определяет, что карта
внутри банкомата. Проходит неопределённое количество времени и банкомат
начинает обрабатывать пароль и состояние меняется на «Ожидание доступа».
Далее
происходят
действия
пользователя,
неотражённые
на
нашей
диаграмме, так как они не связаны с системой доступа. После того, как
пользователь вынимает карту, доступ прекращается и системы снова
переходит в состояние бездействия.
636
16. UML ДИАГРАММА ОБЗОРА ВЗАИМОДЕЙСТВИЯ
16.1. Пример диаграммы обзора взаимодействия онлайн-покупок
Назначение: Пример обзорной диаграммы взаимодействия UML для
онлайн-покупок.
Резюме: Клиент может искать или просматривать товары, добавлять
или удалять товары из корзины, оформлять заказ.
Пример диаграммы обзора взаимодействия для онлайн-покупок.
Клиент может искать или просматривать товары, добавлять или удалять
товары из корзины, оформлять заказ (рис. 33.1.).
Рис. 33.1. Пример обзорной диаграммы взаимодействия UML для
онлайн-покупок.
Эта диаграмма обзора взаимодействия заключена в рамку sd
(сокращенная форма для всех видов диаграмм взаимодействия). Все
неуправляющие узлы диаграммы являются ссылками на взаимодействия —
взаимодействие использует.
637
16.2. Отправление комментариев в Pluck, используя DWR, AJAX, JSON
Назначение: пример диаграммы обзора взаимодействия, которая
показывает,
как
пользовательские
комментарии
к
некоторой
статье
отправляются в Pluck с использованием различных технологий AJAX.
Резюме: комментарии,
отправленные веб-пользователем,
сначала
проверяются веб-сайтом, на котором размещена комментируемая статья.
Технология DWR (AJAX для Java) используется для преобразования
пользовательских комментариев данных формы HTML в объект Java и
возможных ошибок проверки — обратно в обратные вызовы JavaScript для
ошибок. Комментарии, которые выглядят нормально, отправляются на
сервер Pluck, на котором размещены все комментарии ко всем статьям.
Пример диаграммы обзора взаимодействия, которая показывает, как
пользовательские комментарии к некоторой статье отправляются в Pluck с
использованием различных технологий AJAX. (См. пример диаграммы
последовательности с аналогичной семантикой в разделе «Отправить
комментарии в Pluck с использованием DWR, AJAX, JSON».)
Pluck - это небольшая и простая система управления контентом на php,
при
помощи
которой
можно
управлять
сайтом
без
знания
языка
программированияю
Комментарии, отправленные веб-пользователем, сначала проверяются
веб-сайтом, на котором размещена комментируемая статья. Технология
DWR (AJAX для Java) используется для преобразования пользовательских
комментариев данных формы HTML в объект Java и возможных ошибок
проверки — обратно в обратные вызовы JavaScript для ошибок.
Комментарии, которые выглядят нормально, отправляются на сервер
Pluck, на котором размещены все комментарии ко всем статьям. В этом
случае также используется технология AJAX как для отправки нового
638
комментария, так и для возврата списка всех последних комментариев
(включая новый). JSON используется для получения комментариев.
На
этой
диаграмме
также
показаны
некоторые
ограничения
продолжительности (рис. 33.2.). (Отказ от ответственности: показанные
ограничения являются фиктивными и не описывают никакого реального
общения.) Например, согласно диаграмме время ожидания обратного вызова
для опубликованного комментария варьируется от 1 до 4 секунд. При этом
запрос всех размещенных комментариев занимает всего до 100 мс.
Рис. 33.2. Пример диаграммы обзора взаимодействия — отправка
комментариев в Pluck с использованием DWR, AJAX, JSON.
639
17. UML ДИАГРАММА СОСТОЯНИЙ
17.1. Учебный курс
Ниже приведен пример диаграммы состояний (простая форма) для
класса Course (Учебный курс). Курс может быть открыт, закрыт, отменен или
завершен (рис. 34.1.).
Рис. 34.1. Пример диаграммы состояний.
Из этой диаграммы состояний видно, что состояния Открыт и Закрыт
можно поместить в одно суперсостояние (например, Активный курс). Станет
проще и понятнее, да и переходов будет меньше.
17.2. Счет системы банковского автомата
Показать диаграмму состояний для объектов класса Account (Счет)
системы банковского автомата (АТМ) (рис. 34.2.). Счет может находиться в
разных состояниях (открыт, закрыт, превышен), и в каждом из них ведет себя
по-разному.
640
Рис. 34.2. Диаграмма состояний для объектов банковского автомата.
17.3. Телефон
Изображение диаграммы состояний для телефона (рис. 34.3.).
Рис. 34.3. Диаграмма состояний для телефона.
Только что включенный в сеть телефон находится в начальном
состоянии, то есть его предыдущее поведение несущественно. В начальном
641
состоянии телефон готов к тому, чтобы можно было позвонить или принять
звонок. Если поднять трубку, то телефон перейдет в новое состояние:
готовности к набору номера. И в этом состоянии мы не ожидаем, что телефон
зазвонит. Если кто-то наберет ваш номер, и телефон находится в начальном
состоянии, то при поднятии трубки телефон перейдет в новое состояние:
состояние с установленным соединением.
17.4. Заказ
Создать диаграмму состояний для класса Заказ (рис. 34.4.). Заказ может
быть выполнен, отменен, выполнение заказа приостановлено (остаются не
заказанные позиции в заказе) и при инициализации объекта “Заказ”
сохранить дату заказа (входное действие), добавить к заказу новые позиции
(деятельность) и т.д.
Рис. 34.4. Диаграмма состояний для класса Заказ.
642
18. UML ДИАГРАММА АРТЕФАКТОВ
18.1. Физическая база данных
Логическая схема базы данных охватывает словарь хранимых данных
системы вместе с семантикой их связей. Физически все эти сущности
сохраняются в базе данных - либо в реляционной, либо в объектно­
ориентированной,
последующего
либо
в
извлечения.
гибридной
(объектно-реляционной)
UML
же
так
хорошо
-
приспособлен
для
к
моделированию физических баз данных, как и к моделированию их
логических схем.
Отображение
логической
схемы
базы
данных
на
объектно­
ориентированную базу достаточно прямолинейно, поскольку даже сложные
цепочки
наследования
могут
быть
сохранены
без
какого-либо
преобразования. Однако отобразить логическую схему на реляционную базу
не так просто. Если имеет место наследование, приходится принимать
решения относительно того, как отображать классы на таблицы. Обычно
применяется либо одна из трех ниженазванных стратегий, либо их
комбинация:
1. Спуск (push down) - определяется отдельная таблица для каждого
класса. Это простой, но примитивный подход, поскольку он вызывает
проблемы сопровождения при добавлении новых дочерних классов или
модификации существующих родительских;
2. Подъем (pull up) - все цепочки наследования свертываются так, что
реализации любого класса в иерархии имеют одинаковое состояние.
Недостаток в том, что во многих экземплярах приходится хранить
избыточную информацию;
3. Расщепление таблиц (split tables) - данные родительского и
дочернего класса разносятся по разным таблицам. Такой подход лучше
отображает структуру наследования, но его недостаток состоит в том, что для
643
доступа к данным приходится соединять многие таблицы. Проектируя
физическую базу данных, необходимо также решить, как следует отображать
операции, определенные в логической схеме. Объектно-ориентированные
базы данных обеспечивают достаточно прозрачное отображение, но что
касается реляционных, здесь приходится решать, как реализовать эти
логические операции. Опять же, существует несколько вариантов:
1. Простые операции создания, выборки, обновления и удаления
реализуются стандартными вызовами SQL или ODBC;
2. Более сложное поведение (такое как бизнес-правила) отображается
на триггеры и хранимые процедуры. С учетом приведенных соображений для
моделирования физической базы данных необходимо (рис. 35.1.):
• Идентифицировать присутствующие в модели классы, которые
представляют логическую схему базы данных.
• Выбрать стратегию отображения этих классов на таблицы. Следует
рассмотреть и физическое распределение баз данных. Необходимо
проанализировать физическое размещение данных в системе - от
этого тоже зависит выбор стратегии.
• Создать
артефактов
диаграмму
специфицирования,
конструирования
визуализации,
для
и
документирования
отображения, в которой артефакты имеют стереотип таблицы.
• По возможности использовать инструментальные средства для
преобразования логической схемы в физическую. На рис. показан
набор таблиц базы данных, взятых из информационной системы
учебного
заведения.
Вы
видите
одну
базу
-
изображенную в виде артефакта со стереотипом database.
644
school.db,
Рис. 35.1. Моделирование физической базы данных.
Она состоит из пяти таблиц: student (студент), class (класс), instructor
(инструктор), department (отдел) и course (курс). В соответствующей
логической схеме базы данных нет наследования, поэтому отобразить ее на
физическую несложно. Хотя в данном примере это не показано, вы можете
специфицировать содержимое каждой таблицы. Артефакты могут иметь
атрибуты, поэтому общая идиома при моделировании физической базы
данных заключается в использовании атрибутов для специфицирования
столбцов каждой таблицы. Аналогичным образом артефакты могут иметь
операции, которые позволяют отображать хранимые процедуры.
18.2. Адаптируемая система
Все диаграммы артефактов, показанные до сих пор, использовались для
моделирования статических представлений. Их артефакты проводили всю
свою жизнь на одном узле. Хотя эта ситуация встречается чаще всего,
иногда, особенно при работе со сложными распределенными системами, все
же приходится моделировать и динамические представления. Например,
можно представить систему, которая реплицирует свои базы данных на
несколько узлов, переключаясь на резервный сервер в случае отказа
главного. Аналогично при моделировании глобальной распределенной
системы, работающей в режиме 24х7 (то есть 7 дней в неделю, 24 часа в
сутки), вы, скорее всего, столкнетесь с мобильными агентами - артефактами,
645
которые мигрируют с одного узла на другой для обслуживания некоторой
транзакции. Чтобы смоделировать такие динамические представления, вам
понадобится использовать комбинацию диаграмм артефактов, объектов и
взаимодействия.
Для моделирования адаптируемой системы необходимо:
• Рассмотреть физическое распределение артефактов, которые могут
мигрировать с одного узла на другой. Вы можете специфицировать
местоположение экземпляра артефакта, пометив его атрибутом
location, который можно отобразить на диаграмме артефактов.
• Если нужно смоделировать действия, вызывающие миграцию
артефакта, создать с этой целью соответствующую диаграмму
взаимодействия, которая будет содержать экземпляры артефактов.
Изменение местоположения артефакта можно проиллюстрировать,
нарисовав один экземпляр несколько раз, но с разными значениями
состояния, включая его местоположение.
На рисунке 35.2.
представлено моделирование репликации базы
данных, уже рассматривавшейся выше. Здесь мы видим два экземпляра
артефакта school.db. Оба анонимны и имеют разные помеченные значения
местоположения (location). Также присутствует примечание, которое явно
указывает, какой экземпляр куда реплицируется.
Рис. 35.2. Моделирование адаптируемых систем
646
Если необходимо показать подробности каждой базы данных, их можно
изобразить в канонической форме - в виде артефакта со стереотипом
database. Хотя на этом рисунке это не показано, можно использовать и
диаграмму взаимодействия для моделирования динамики переключения с
главной базы данных на резервную.
18.3. Прямое и обратное проектирование
Прямое и обратное проектирование артефактов довольно просто, потому
что артефакты сами по себе - физические сущности (исполняемые
программы, библиотеки, таблицы, файлы и разнообразные документы), а
потому близки к работающей системе. При прямом проектировании класса
или кооперации вы на самом деле проектируете артефакт, который
представляет исходный код, двоичную библиотеку или исполняемую
программу для этого класса или кооперации. Точно так же при обратном
проектировании исходного кода, двоичной библиотеки или исполняемой
программы вы на самом деле выполняете обратное проектирование
артефакта или набора артефактов, которые, в свою очередь, отображаются на
классы или кооперации.
Приступая к прямому проектированию (созданию кода из модели)
класса
или
кооперации,
вы
должны
решить,
во
что
нужно
их
преобразовывать: в исходный код, двоичную библиотеку или исполняемую
программу. Логическую модель имеет смысл превратить в исходный код,
если вас интересует управление конфигурацией файлов, которые затем будут
переданы среде разработки. Если же вас интересует управление артефактами,
которые фактически будут развернуты в составе работающей системы, то
логические модели следует непосредственно преобразовать в двоичные
библиотеки или исполняемые программы. Иногда нужно и то, и другое.
Классу или кооперации можно поставить в соответствие как исходный код,
так и двоичную библиотеку или исполняемую программу.
647
Чтобы выполнить прямое проектирование диаграммы артефактов,
необходимо:
• Идентифицировать классы и кооперации, которые реализует
каждый артефакт. Выразить эту реализацию при помощи связи
материализации.
• Выбрать форму представления каждого артефакта. Это может
быть либо исходный код (форма, поддающаяся управлению
средствами
разработки),
либо
двоичная
библиотека
или
исполняемая программа (форма, которая может быть включена в
работающую систему).
• Использовать
инструментальные
средства
для
прямого
проектирования модели.
Обратное проектирование диаграммы артефактов (создание модели из
кода) - не идеальный процесс, поскольку при этом всегда происходит потеря
информации. По исходному коду можно обратно спроектировать классы -
это в общем-то тривиальная задача. Обратное проектирование артефактов из
исходного кода выявляет существующие между файлами зависимости
компиляции. Если же говорить о двоичных библиотеках, то самое большее,
на что можно рассчитывать, - обозначить библиотеку как артефакт, а затем,
используя обратное проектирование, раскрыть его интерфейсы. Это второе
по распространенности действие, которое выполняется над диаграммами
артефактов. Такой подход может быть полезен при ознакомлении с новыми
плохо документированными библиотеками. Максимум, что можно сделать в
отношении исполняемой программы, - обозначить ее как артефакт, а затем
дизассемблировать ее код, но вряд ли стоит этим заниматься, если только вы
не пишете на языке ассемблера.
Чтобы выполнить обратное проектирование диаграммы артефактов,
необходимо:
648
• Выбрать
представление.
целевое
Исходный
код
можно
реконструировать в артефакты, а затем в классы. Двоичные
библиотеки можно подвергнуть обратному проектированию,
чтобы
раскрыть
их
интерфейсы.
Исполняемые
программы
поддаются обратному проектированию в наименьшей степени.
• Используя инструментальные средства, указать код, который
следует подвергнуть обратному проектированию. Использовать
инструменты для генерации новой модели или модификации
существующей, для которой ранее было выполнено прямое
проектирование.
• Опрашивая модель и используя инструментальное средство,
создать диаграмму артефактов - например, начать с одного или
нескольких артефактов, а затем расширить диаграмму, следуя по
связям или переходя к соседним артефактам. Отображать или
скрывать детали этой диаграммы артефактов в соответствии с
вашими установками.
В качестве примера на рисунке 35.3. показана диаграмма артефактов,
которая
представляет результат обратного проектирования артефакта
ActiveX vbrun.dll. Видно, что он реализует 11 интерфейсов.
649
Рис. 35.3. Обратное проектирование диаграммы артефактов.
Имея перед глазами такую диаграмму, можно понять семантику
артефакта, перейдя к раскрытию его интерфейсных классов. Чаще всего при
обратном проектировании исходного кода, а иногда и двоичных библиотек, и
исполняемых
программ,
прибегают
к помощи
системы
управления
конфигурацией. Это означает, что вы будете работать с конкретными
версиями файлов и библиотек, совместимых друг с другом. В таких случаях
полезно включать помеченное значение, указывающее версию артефакта, -
ее может предоставить система управления конфигурацией. Таким образом,
можно использовать UML для визуализации истории артефакта при смене
версий системы.
650
РАЗДЕЛ V
КРАТКИЙ
СПРАВОЧНИК
UML
651
Что такое UML-диаграмма?
UML — это способ визуализации программы с помощью набора
диаграмм. Нотация развилась из работ Грэди Буча, Джеймса Рамбо, Ивара
Джейкобсона и Rational Software Corporation для использования в объектно­
ориентированном проектировании, но с тех пор она была расширена для
охвата
широкого
более
круга
проектов
разработки
программного
обеспечения. Сегодня UML принят Object Management Group (OMG) в
качестве
стандарта
для
моделирования
разработки
программного
обеспечения.
Что подразумевается под UML?
UML означает унифицированный язык моделирования. UML 2.0 помог
расширить исходную спецификацию UML, чтобы охватить более широкую
часть усилий по разработке программного обеспечения, включая методы
гибкой разработки.
•
Улучшенная интеграция между структурными моделями, такими как
диаграммы классов, и моделями поведения, такими как диаграммы
действий.
•
Добавлена
возможность
определять
иерархию
и
разбивать
программную систему на компоненты и подкомпоненты.
•
Исходный UML определял девять диаграмм; В UML 2.x это число
увеличено до 13. Четыре новые диаграммы называются: диаграмма
связи,
диаграмма
составной
структуры,
диаграмма
обзора
взаимодействия и временная диаграмма. Он также переименовал
диаграммы состояний в диаграммы состояний, также известные как
диаграммы состояний.
652
Типы диаграмм UML
Текущие стандарты UML требуют 13 различных типов диаграмм:
класс, действие, объект, вариант использования, последовательность, пакет,
состояние, компонент, связь, составная структура, обзор взаимодействия,
время и развертывание.
Эти диаграммы организованы в две отдельные группы: структурные
диаграммы и диаграммы поведения или взаимодействия.
Структурные диаграммы UML
•
Диаграмма классов
•
Диаграмма пакетов
•
Диаграмма объектов
•
Диаграмма модели
•
Диаграмма композитной составной структуры
•
Диаграмма внутренней структуры
•
Диаграмма кооперации
•
Диаграмма компонентов
•
Диаграмма проявления
•
Диаграмма развертывания
•
Диаграмма сетевой архитектуры
•
Диаграмма артефактов
•
Диаграмма профилей
Поведенческие диаграммы UML
•
Диаграмма вариантов использования
•
Диаграмма потока информации
653
•
Диаграмма деятельности
•
Диаграмма состояний
•
Диаграмма поведения конечного автоматаэ
•
Диаграмма конечного атвомата протокола
•
Диаграмма взаимодействия
•
Диаграмма последовательности
•
Диаграмма коммуникации
•
Временная диаграмма
•
Диаграмма обзора взаимодействий
Символы диаграммы UML
Существует множество различных типов диаграмм UML, и каждый из
них имеет немного отличающийся набор символов.
Диаграммы
классов,
возможно,
являются
одними из
наиболее
распространенных используемых диаграмм UML, а символы диаграмм
классов сосредоточены вокруг определения атрибутов класса. Например,
есть символы для активных классов и интерфейсов. Символ класса также
можно разделить, чтобы показать операции, атрибуты и обязанности класса.
Видимость любых членов класса отмечена нотациями (рис. 36.1.):
654
+
For Public
For Private
#
For Protected
I
For Derived
For Package
Рис. 36.1. Символы видимости членов класса.
Линии также являются
важными символами
для обозначения
отношений между компонентами (рис. 36.2.). Обобщение и наследование
обозначены
пустыми стрелками. Композиция показана
закрашенным
ромбом. Агрегация показана пустым ромбом. Зависимости отмечены
пунктирной линией со стрелкой. Использование << >> позволяет указать
свойства этой зависимости. Множественность обычно указывается числом на
одном конце стрелки и * на другом.
<H
Generalization
4>
Inheritance
♦
Composition
-o
... ->
«»
*
1
—>
Aggregation
Dependencies
Properties
Multiplicity
Рис. 36.2. обозначения отношений между компонентами.
655
На диаграммах пакетов есть символы, определяющие пакет, которые
выглядят как папка (рис. 36.3.).
Рис. 36.3. Обозначение пакета
Диаграммы действий имеют символы для действий, состояний,
включая отдельные символы для начального состояния и конечного
состояния (рис. 36.4.). Поток управления обычно показан стрелкой, а поток
объекта показан пунктирной стрелкой.
Рис. 36.4. Символы начального и конечного состояния.
На
диаграммах
вариантов
использования
есть
символы
для
действующих лиц и вариантов использования.
UML диаграмма классов
Диаграммы
классов являются основой почти всех объектно­
ориентированных методов, включая UML (рис. 36.4.). Они описывают
статическую структуру системы. Данная диаграмма показывает структуру
проектируемой системы на уровне классов и интерфейсов, показывает их
особенности, ограничения и отношения — ассоциации, обобщения,
зависимости и т.д.
656
порядок чтения
атрибуты
Book
Перечислимый
тип данных
абстрактный класс
ISBN: String[O..1] {id}
title: String
4
summary
\
Author
name:String
biography: String
publisher
\
publication date \
number of pages \
«enumeration»
language
«use»
AccointState
кратность
обобщение
Active
Frozen
Closed
«enity» Account
«enity» Book Item
стереотипный
класс
barcode: String (0..1) {id) 0..12
tag: RFID <0..1){id}
0..3
isReferenceOniy
number {id}
history: History[0..*J
opened: Date
stale: Accountstate
◄ borrowed
◄ reserved
accounts
accounts *
агрегация
ассоциация
Library
Parton
О
records
композиция
name
adress
name
address
«interface»
Search
Librarian
Catalog
«interface»
Manage
<---
■'
use
name
address
position
реализация
зависимость
Рис. 36.4. Диаграмма классов
UML диаграмма пакетов
Диаграммы пакетов представляют собой подмножество диаграмм
классов, но разработчики иногда рассматривают их как отдельный метод
(рис. 36.5. и 36.6.). Диаграммы пакетов организуют элементы системы в
связанные группы, чтобы свести к минимуму зависимости между пакетами.
657
Рис. 36.5. Вариация диаграммы пакетов.
Рис. 36.6. Вариация диаграммы пакетов.
658
UML диаграмма объектов
Диаграммы объектов описывают статическую структуру системы в
определенный момент времени (рис. 36.7.). Их можно использовать для
проверки диаграмм классов на точность.
Рис. 36.7. Диаграмма объектов
UML диаграмма модели
Диаграмма модели — это вспомогательная структурная диаграмма
UML,
которая
показывает
некоторую
абстракцию
или
конкретное
представление системы для описания некоторых архитектурных, логических
или поведенческих аспектов системы (рис. 36.8.).
659
Рис. 36.8. Элементы UML диаграммы модели - модель, пакет,
зависимость.
Диаграмма композитной составной структуры
Составные структурные диаграммы показывают внутреннюю часть
класса, взаимодействие классификатора с окружающей средой через порты и
поведение диаграммы кооперации (рис. 36.9.).
660
Рис. 36.9. Диаграмма композитной составной структуры
Диаграмма внутренней структуры
Диаграмма внутренней структуры - подвид диаграммы композитной
структуры. Используется для более подробного представления структурных
классификаторов, прежде всего классов и компонентов.
Диаграмма
внутренней
структуры
показывает
внутреннюю
структуру классификатора - разложение этого классификатора на его
свойства, части и отношения (рис. 36.10.).
661
Рис. 36.10. Обзор составной структурной UML диаграммы, которая
показывает элементы внутренней структуры структурированного
классификатора - роли, части, соединители.
Диаграмма кооперации
Подвидом диаграмм композитной структуры является диаграмма
кооперации, которая показывает роли и взаимодействие классов в рамках
кооперации (рис. 36.11.). Кооперации удобны при моделировании шаблонов
проектирования.
662
Рис. 36.11. Элементы сотрудничества - роли, части, соединители.
Collaboration Visit показывает взаимодействие ролей врача и пациента.
Диаграмма компонентов
Диаграммы
компонентов
компонентов
программного
описывают
обеспечения,
организацию физических
включая
исходный
исполняемый (двоичный) код и исполняемые файлы (рис. 36.12.).
663
код,
Рис. 36.12. Диаграмма компонентов.
Диаграмма проявления
В то время как диаграммы компонентов показывают компоненты и
отношения между компонентами и классификаторами, а диаграммы
развертывания — развертывание артефактов в целях развертывания,
некоторая отсутствующая промежуточная диаграмма — это диаграмма
проявления,
которая
(реализации)
компонентов
используется
для
артефактами
артефактов (рис. 36.13.).
664
демонстрации
проявления
и
структурой
внутренней
Рис. 36.13. UML диаграмма проявления компонентов артефактами.
Диаграмма развертывания
Диаграммы развертывания изображают физические ресурсы в
системе, включая узлы, компоненты и соединения.
Диаграмма развертывания — это структурная диаграмма, которая
показывает
архитектуру
системы как развертывание (распределение)
программных артефактов по целям развертывания (рис. 36.14.). По-другому
диаграмму развертывания называют диаграммой размещения.
Рис. 36.14. Диаграмма развёртывания
665
Диаграмма сетевой архитектуры
Стандарт UML не имеет отдельного вида диаграмм для описания
сетевой архитектуры и не содержит конкретных элементов, связанных с
сетью. Диаграммы развертывания могут использоваться для этой цели, как
правило, с некоторыми дополнительными сетевыми стереотипами (рис.
36.15.). Диаграмма сетевой архитектуры обычно показывает сетевые узлы и
пути связи между ними.
Рис. 36.15. Обзор схемы сетевой архитектуры — сетевые устройства и
связь.
Диаграмма артефактов
Диаграмма артефактов (artifact diagram) - это один из двух видов
диаграмм, предназначенных для моделирования физических аспектов
объектно-ориентированных систем (рис. 36.16.). Диаграмма артефактов
показывает организацию и зависимости между наборами артефактов.
666
Диаграмма профилей
Диаграмма профиля
это структурная диаграмма, которая
описывает упрощенный механизм расширения UML путем определения
пользовательских стереотипов, значений тегов и ограничений (рис. 36.17.).
667
Рис. 36.17. Основные элементы UML диаграммы профиля — профиль,
стереотип, метакласс, расширение, профиль приложения.
UML диаграмма вариантов использования
Диаграммы
использования
вариантов
моделируют
функциональность системы с использованием действующих лиц и вариантов
использования (рис. 36.18.).
668
субъект. граница системы
ассоциация
«Business»
Airport
бизнес-актор
Group
Check-In
включаюше?
отношение
Tour Suide
«include» \
обобщение между
действующими
лицами к
Individual
Check-In,
расширяющее
отношение
[extend;
бизнес-актор
Baggage
Passenger
Check-In.
Security
Screeninc
вариант использования
в бизнесе
Рис. 36.18. Диаграмма вариантов использования
UML диаграмма потока информации
Диаграмма информационных потоков — это диаграмма поведения
UML, которая показывает обмен информацией между сущностями системы
на некоторых высоких уровнях абстракции.
Информационные потоки не определяют характер информации,
механизмы ее передачи, последовательность обмена или какие-либо условия
управления (рис. 36.19.).
669
Рис. 36.19. Элементы UML схемы информационного потока -
информационный поток, информационный элемент.
UML диаграмма действий
Диаграммы
действий
иллюстрируют
динамическую
природу
системы, моделируя поток управления от действия к действию (рис. 36.20.).
Действие представляет собой операцию над некоторым классом в системе,
которая приводит к изменению состояния системы. Как правило, диаграммы
деятельности используются для моделирования рабочего процесса или
бизнес-процессов и внутренних операций.
Рис. 36.20. Диаграмма действий
670
Диаграмма состояний
Диаграммы состояний, теперь известные как диаграммы состояний и
диаграммы состояний, описывают динамическое поведение системы в ответ
на внешние воздействия (рис. 36.21.). Диаграммы состояний особенно
полезны при моделировании реактивных объектов, состояния которых
запускаются определенными событиями.
Рис. 36.21. Диаграмма состояний
Диаграмма поведения конечного автомата
Диаграмма конечного автомата — это диаграмма поведения,
которая показывает дискретное поведение части проектируемой системы
через конечные переходы состояний.
Диаграммы конечного автомата также могут использоваться для
выражения протокола использования части системы (рис. 36.22.).
671
Рис. 36.22. Поведенческий конечный автомат высокого уровня для
банковского банкомата.
Диаграмма конечного автомата протокола
Диаграммы конечного автомата протокола UML используются для
выражения протокола использования или жизненного цикла некоторого
классификатора.
Он показывает, какие операции классификатора могут быть вызваны в
каждом состоянии классификатора, при каких конкретных условиях и
выполнении
некоторых необязательных
постусловий после перехода
классификатора в целевое состояние (рис. 36.23.).
672
Обзорная диаграмма взаимодействия
Обзорные
диаграммы
взаимодействия
представляют
собой
комбинацию диаграмм действий и диаграмм последовательности (рис.
36.24.). Они моделируют последовательность действий и позволяют
разложить более сложные взаимодействия на управляемые события. Вы
должны
использовать
те
же
обозначения
взаимодействия, что и на диаграмме действий.
673
на
диаграммах
обзора
рамка диаграммы взаимодействия
тинии жизни, участвующие во взаимодействии
Рис. 36.24. Диаграмма обзора взаимодействия.
UML диаграмма последовательности
Диаграммы последовательности описывают взаимодействие между
классами с точки зрения обмена сообщениями во времени (рис. 36.25.).
674
Рис. 36.25. Диаграмма последовательности.
Диаграмма связи
Диаграммы связи моделируют последовательное взаимодействие
между объектами (рис. 36.26.). Они описывают как статическую структуру,
так
и
динамическое
поведение
системы.
Во
многих
отношениях
коммуникационная диаграмма представляет собой упрощенную версию
диаграммы сотрудничества, представленной в UML 2.0.
675
Рис. 36.26. Диаграмма связи.
Временная диаграмма
Временная диаграмма — это тип UML-диаграммы поведения или
взаимодействия, который фокусируется на процессах, происходящих в
течение определенного периода времени (рис. 36.27.). Это особый пример
диаграммы
последовательности,
за
исключением
увеличивается слева направо, а не сверху вниз.
676
того,
что
время
Lh
Рис. 36.27. Временная диаграмма
Диаграмма обзора взаимодействий
Диаграммы обзора взаимодействия обеспечивают обзор потока
управления,
где
узлами
потока
являются
взаимодействия
или
использование взаимодействия.
На диаграммах обзора взаимодействия можно использовать следующие
элементы диаграмм действий: начальный узел, конечный узел потока,
конечный узел действия, узел принятия решения, узел слияния, узел
разветвления, узел соединения (рис. 36.28.).
677
рамка диаграммы взаимодействия
\
линии жизн и, участвующие во взаимодействии
'х
Рис. 36.28. Обзорная UML диаграмма взаимодействия,
объединяет элементы диаграмм действий
и диаграмм взаимодействия.
678
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Adele Goldberg, David Robson. Smalltalk-80: The Language and its
Implementation. Xerox Palo Alto Research Center, ISBN 0-201-11371-6.
344 pp. 1983.
2. Arifin M. N., Siahaan D. Structural and Semantic Similarity
Measurement of UML Use Case Diagram //Lontar Komputer: Jurnal
Ilmiah Teknologi Informasi. - 2020. - Т. 11. - №. 2. - С. 88.
3. Arlow J., Neustadt I. UML 2 and the unified process: practical objectoriented analysis and design. - Pearson Education, 2005.
4. C. Strachey, Fundamental concepts in programming languages. Notes for the
International Summer School in Computer Programming, Copenhagen,
1967.
5. Cavique L. et al. Improving information system design: Using UML
and axiomatic design //Computers in Industry. - 2022. - Т. 135. - С.
103569.
6. Ciccozzi F., Malavolta I., Selic B. Execution of UML models: a
systematic review of research and practice //Software & Systems
Modeling. - 2019. - Т. 18. - С. 2313-2360.
7. Eriksson H., Penker M. Business Modeling with UML: Business
Patterns at Work. - John Wiley & Sons, 2000. - 459 p.
8. Febriani R., Romdoni M. Y., Nugraha M. D. RANCANG BANGUN
APLIKASI POINT OF SALE TANAMAN HIAS BERBASIS WEB DI
ANUGRAH HIJAU FLORIST & NURSERY //Journal of Innovation
And Future Technology (IFTECH). - 2023. - Т. 5. - №. 2. - С. 102­
111.
9. Fuady T. et al. PERANCANGAN SISTEM INFORMASI CATATAN
DAN PENGAWASAN HEWAN TERNAK MENGGUNAKAN QR
CODE BERBASIS WEB DENGAN METODE AGILE //Jurnal Ilmiah
Sains dan Teknologi. - 2023. - Т. 7. - №. 1. - С. 33-42.
679
10.
Gajski D. D. et al. Embedded system design: modeling,
synthesis and verification. - Springer Science & Business Media,
2009.
11. Ganyun A. H., Kristina K., Ndaumanu R. I. APLIKASI SMART
LIBRARY BERBASIS ANDROID //MASITIKA. - 2023. - Т. 8.
12. Gibran P. F., Sharyanto S., Sudarsono B. G. DESIGN AND
CREATION
A
OF
INFORMATION
WEB-BASED
GOODS
DISTRIBUTION
PT.
LAUTAN
MAS
SYSTEM AT
MAKMUR
//Journal of Engineering, Technology and Computing (JETCom). 2023. - Т. 2. - №. 3. - С. 210-218.
13. Gorski T. UML Profile for Messaging Patterns in Service-Oriented
Architecture, Microservices, and Internet of Things //Applied
Sciences. - 2022. - Т. 12. - №. 24. - С. 12790.
14. Hidayanti N. et al. RANCANG BANGUN SISTEM INFORMASI
MANAJEMEN
PERPUSTAKAAN MENGGUNAKAN
QR
CODE
BERBASIS WEBSITE //Jurnal Sistem Informasi dan Informatika
(Simika). - 2023. - Т. 6. - №. 1. - С. 35-47.
15. Hoendarto G., Yulius A., Candra H. PENERAPAN INFORMASI
PENJADWALAN MATA PELAJARAN PADA PERSEKOLAHAN SMA
SANTO FRANSISKUS ASISI PONTIANAK //INTEKSIS. - 2023. - Т.
10. - №. 2. - С. 1-11.
16.Ismail A. Digitalization of Management Information Systems at
Intuition Bookstore Makassar City //Asian Journal of Applied
Business and Management. - 2023. - Т. 2. - №. 3. - С. 439-448.
17. Julianto V. J. et al. Rancang Bangun Sistem Informasi Audit Mutu
Internal //Journal of Applied Computer Science and Technology. 2023. - Т. 4. - №. 2. - С. 108-117.
18.
Jurgelaitis M. et al. Solidity code generation from UML state
machines in model-driven smart contract development //IEEE
Access. - 2022. - Т. 10. - С. 33465-33481.
680
19. K0C H. et al. UML diagrams in software engineering research: a
systematic literature review //Proceedings. - MDPI, 2021. - Т. 74. №. 1. - С. 13.
20.
Lukmana H. H., Alhusaini M., Purwayoga V. PERANCANGAN
SISTEM
INFORMASI
PERPUSTAKAAN
DIGITAL
BERBASIS
WEBSITE MENGGUNAKAN METODE WATERFALL DI JURUSAN
INFORMATIKA
UNIVERSITAS
SILIWANGI
//METHOMIKA:
Jurnal Manajemen Informatika & Komputerisasi Akuntansi. - 2023.
- Т. 7. - №. 2. - С. 340-346.
21. Norrahman M. I. APLIKASI ARSIP BERITA DAN DOKUMENTASI
KEGIATAN PADA BIDANG INFORMASI DAN KOMUNIKASI
PUBLIK
DINAS
DI
KOMUNIKASI
DAN
INFORMATIKA
KABUPATEN KAPUAS BERBASIS WEB : дис. - Universitas Islam
Kalimantan MAB, 2023.
22.OMG Unified Modeling Language™. Version 2.5. Object Management
Group, Inc., formal/2015-03-01 March 2015.
23.
Ozkaya M., Erata F. A survey on the practical use of UML for
different
software
architecture
viewpoints
//Information
and
Software Technology. - 2020. - Т. 121. - С. 106275.
24.
Rukmana A. Y. et al. PENGANTAR SISTEM INFORMASI:
Panduan Praktis Pengenalan Sistem Informasi & Penerapannya. -
PT. Sonpedia Publishing Indonesia, 2023.
25.
Saputra D., Sharyanto S., Sudarsono B. G. DESIGN AND
CREATION
OF
A
WEB-BASED
CONSTRUCTION
PROJECT
MONITORING INFORMATION SYSTEM AT PT. TRI SAYAKA
SELARAS //Journal of Engineering, Technology and Computing
(JETCom). - 2023. - Т. 2. - №. 3. - С. 198-209.
26.
Selic B., Gerard S. Modeling and analysis of real-time and
embedded systems with UML and MARTE: Developing cyber­
physical systems. - Elsevier, 2013.
681
Wazlawick R. S. Object-oriented analysis and design for
27.
information systems: modeling with UML, OCL, and IFML. Elsevier, 2014.
28.
Yigitbas E. et al. Design and evaluation of a collaborative uml
modeling environment in virtual reality //Software and Systems
Modeling. - 2023. - Т. 22. - №. 5. - С. 1397-1425.
29.
Yulianto M. A. et al. Rancang Bangun Sistem Informasi
Penjualan Pada CV Citra Timbangan Berbasis Web Menggunakan
Model Waterfall //BINER: Jurnal Ilmu Komputer, Teknik dan
Multimedia. - 2023. - Т. 1. - №. 3. - С. 828-837.
30.
Богуславский А.А.
и др.
Модели и
алгоритмы
для
интеллектуальных систем управления //М.: ИПМ им. МВ
Келдыша. - 2019.
31. Буч Г., Якобсон И., Рамбо Д. Введение в UML от создателей
языка. - Litres, 2022.
32.
Гамма
Э.
объектно-ориентированного
Приемы
проектирования. Паттерны проектирования. / Э. Гамма [и д.р.]
СПб.: Питер, 2015. - 368 с.
33.
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы
проектирования.
объектноориентированного
Паттерны
проектирования. - СПб.: Питер, 2016. - 366 с.
34.
Гома Х. UML. Проектирование систем реального времени,
распределенных и параллельных приложений. - Litres, 2022.
Гурьянов В. И. Имитационное моделирование на UML SP. -
35.
2014.
36.
Кватрани Т. Rational Rose 2000 и UML. Визуальное
моделирование. - Litres, 2022.
37.
Ларман
К.
Применение
UML
2.0
и
шаблонов
проектирования. 3 изд. Пер. с англ. - М.: Вильямс, 2013. - 736 с.
682
38.
Леоненков, А. В. Объектно-ориентированный анализ и
проектирование с использованием UML и IBM Rational Rose :
учебное пособие / А. В. Леоненков. — 3-е изд. — Москва :
Информационных
Интернет-Университет
Технологий
(ИНТУИТ), Ай Пи Ар Медиа, 2020. — 317 c. — ISBN 978-5-4497­
0667-6. — Текст : электронный // Цифровой образовательный
ресурс
IPR
SMART
:
https://www.iprbookshop.ru/97554.html
[сайт].
(дата
—
URL:
обращения:
13.11.2023). — Режим доступа: для авторизир. пользователей.
683
Научное издание
Александр Константинович Бойцов,
Светлана Сергеевна Колмгорова
ПРАКТИЧЕСКОЕ МОДЕЛИРОВАНИЕ НА UML
Монография
Подписано в печать 28.12.2023. Формат 60 х 90 1/16.
Усл. печ. л. 42,8. Тираж 300 экз. Печать цифровая.
Заказ № 296С.
Отпечатано в соответствии с предоставленным оригинал-макетом
в типографии издательско-полиграфической фирмы «Реноме»,
192007, Санкт-Петербург, наб. Обводного канала, 40.
Тел. (812) 766-05-66.
