Автор: Шмуллер Дж.
Теги: компьютерные технологии языки программирования
ISBN: 5-8459-0855-8
Год: 2005
Текст
SAMS________________
Освой самостоятельно
Джозеф Шмуллер
часа
ВИЛЬЯМС
Издательский дом “Вильямс"
Москва ♦ Санкт-Петербург ♦ Киев
2005
ББК 32.973.26-018.2.75
Ш75
УДК 681.3.07
Издательский дом “Вильямс”
Зав. редакцией С.Н. Тригуб
Перевод с английского и редакция канд. техн. наукЛ./О. Шелестова
По общим вопросам обращайтесь в Издательский дом “Вильямс”
по адресу: info@winiamspublishing.com, http://www.williamspublishing.com
115419, Москва, а/я 783; 03150, Киев, а/я 152
Шмуллер, Джозеф.
Ш75 Освой самостоятельно UML за 24 часа, 3-е издание. : Пер. с англ. — М. : Изда-
тельский дом “Вильямс”, 2005. — 416 с.: ил. — Парал. тит. англ.
ISBN 5-8459-0855-8 (рус.)
В книге рассматриваются вопросы использования унифицированного языка моделирова-
ния UML 2.0. При этом основное внимание уделяется реализации объектно-ориентированной
методологии, а не построению отдельных диаграмм. Кроме рассмотрения конкретных
диаграмм приводятся также и сведения об их совместном использовании, а также реальные
примеры, которые позволяют освоить язык UML еще лучше.
Книга будет полезна для специалистов по логистике, для разработчиков программного
обеспечения, а также для всех тех, кто интересуется вопросами объектного моделирования.
В третье издание вошло много нового материала о самой структуре языка UML и о меха-
низмах его расширения, так что она будет интересной и тем читателям, кто знаком с преды-
дущими двумя изданиями.
ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками соответст-
вующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было
форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирова-
ние и запись на магнитный носитель, если на это нет письменного разрешения издательства Sams Publishing.
Authorized translation from the English language edition published by Sams Publishing Copyright © 2004
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic
or mechanical, including photocopying, recording or by any information storage retrieval system, without permission
from the Publisher.
Russian language edition is published by Williams Publishing House according to the Agreement with R&I
Enterprises International, Copyright © 2005
ISBN 5-8459-0855-8 (рус.) © Издательский дом “Вильямс”, 2005
ISBN 0-672-32640-Х (англ.) © Sams Publishing, 2004
Оглавление
Введение 20
Часть I. Начало 23
1-й час. Введение в UML 24
2-й час. Знакомство с объектно-ориентированным подходом 43
3-й час. Использование концепций объектно-ориентированного
проектирования 56
4-й час. Работа со связями 66
5-й час. Агрегация, композитные объекты, интерфейсы и реализации 79
6-й час. Знакомство с прецедентами 89
7-й час. Использование диаграмм прецедентов 97
8-й час. Диаграммы состояний 112
9-й час. Диаграммы последовательностей 123
10-й час. Диаграммы коммуникации 142
11-й час. Диаграммы видов деятельности 155
12-й час. Диаграммы компонентов 176
13-й час. Работа с диаграммами развертывания 189
14-й час. Пакеты и принципы построения UML 200
15-й час. Место UML в процессе разработки 221
Часть II. Конкретный пример 233
16-й час. Знакомство с конкретным примером 234
17-й час. Анализ предметной области 249
18-й час. Формирование системных требований 267
19-й час. Разработка прецедентов 282
20-й час. Взаимодействие элементов системы и изменение их состояния 293
21-й час. Проектирование интерфейса пользователя и развертывание системы 302
22-й час. Знакомство с шаблонами проектирования 315
Часть III. Взгляд в будущее 327
23-й час. Моделирование встроенных систем 328
24-й час. Картина будущего UML 344
Часть IV. Приложения 357
Приложение А. Ответы 358
Приложение Б. Использование средств моделирования, поддерживающих
язык UML 369
Приложение В. Резюме в картинках 391
Предметный указатель 402
Содержание
Введение 20
Часть I. Начало 23
1-й час. Введение в UML 24
Упорядочение 25
История создания языка UML 26
Компоненты UML 26
Диаграмма классов 27
Диаграмма объектов 28
Диаграмма прецедентов 28
Диаграмма состояний 29
Диаграмма последовательностей 30
Диаграмма видов деятельности 32
Диаграмма коммуникации 32
Диаграмма компонентов 33
Диаграмма развертывания 34
Некоторые дополнения 34
Примечания 34
Ключевые слова и стереотипы 35
Новые диаграммы в UML 2.0 36
Композитная структурная диаграмма 36
Обзорная диаграмма взаимодействия 37
Временная диаграмма 38
И старое, и новое — диаграмма пакетов 39
Зачем так много различных диаграмм? 39
Может, это просто картинки? 40
Резюме 40
Вопросы и ответы 40
Практические занятия 41
Тесты 41
Упражнения 41
2-й час. Знакомство с объектно-ориентированным подходом 43
Вездесущие объекты 44
Общие понятия 46
Абстракция 46
Наследование 46
Полиморфизм 47
Инкапсуляция 48
Передача сообщений 49
Ассоциации 50
Агрегация 52
Обратная связь 53
Резюме 54
Вопросы и ответы 54
Практические занятия 54
Тесты 55
3-й час. Использование концепций объектно-ориентированного
проектирования 56
Визуализация класса 56
Атрибуты 57
Операции 58
Визуализация атрибутов и операций 59
Обязанности и ограничения 60
Комментарии 61
Для чего предназначены классы и как их выявлять 62
Резюме 64
Вопросы и ответы 64
Практические занятия 64
Тесты 64
Упражнения 65
4-й час. Работа со связями 66
Ассоциации 66
Ограничения ассоциаций 67
Классы ассоциаций 68
Связи 68
Кратность 69
Квалификатор ассоциации 70
Рефлексивные ассоциации 71
Наследование и обобщение 71
Изучение наследования 73
Абстрактные классы 73
Зависимости 74
Диаграммы классов и диаграммы объектов 75
Резюме 76
Вопросы и ответы 77
Практические занятия 77
Тесты 77
Упражнения 78
5-й час. Агрегация, композитные объекты, интерфейсы и реализации 79
Объекты-агрегаты 79
Ограничения агрегации 80
Композитные объекты 81
Структурные диаграммы композитов 81
Интерфейсы и реализации 81
Интерфейсы и порты 85
Области видимости 85
Статические и динамические классы 86
Резюме 86
Вопросы и ответы 87
Практические занятия 87
Тесты 87
Упражнения 88
6-й час. Знакомство с прецедентами 89
Что такое прецеденты 89
Зачем нужны прецеденты 90
Пример: автомат для продажи лимонада 90
Прецедент Покупка лимонада 90
Содержание 7
Дополнительные прецеденты 92
Включение прецедента 93
Расширение прецедента 94
Анализ прецедента 94
Резюме 95
Вопросы и ответы 95
Практические занятия 96
Тесты 96
Упражнения 96
7-й час. Использование диаграмм прецедентов 97
Представление модели прецедентов 97
Модель автомата по продаже лимонада 98
Отслеживание действий в сценариях 99
Визуализация взаимосвязей прецедентов 99
Включение 99
Расширение 100
Обобщение 102
Группирование 103
Роль диаграмм прецедентов в процессе анализа 103
Пример использования модели прецедентов 103
Изучение предметной области 104
Работа с пользователями 104
Описание прецедентов 104
Уточнение деталей 105
Подведение итогов 107
Структурные элементы 108
Взаимосвязи 108
Группирование 108
Аннотация 108
Расширение 108
...И еще 109
Общая картина 109
Резюме 109
Вопросы и ответы 110
Практические занятия ПО
Тесты 111
Упражнения 111
8-й час. Диаграллмы состояний 112
Что такое диаграмма состояний 112
Основные обозначения 113
Дополнительные элементы в изображении состояния 114
Дополнительные обозначения для переходов: события и действия 115
Дополнительные обозначения для переходов: условия переходов 115
Подчиненные состояния 116
Последовательные подчиненные состояния 116
Параллельные подчиненные состояния 117
История состояний 118
Новое в UML 2.0 119
Зачем нужны диаграммы состояний 119
Дополнение к общей картине 120
Резюме 120
Вопросы и ответы 121
8
Содержание
Практические занятия 121
Тесты 121
Упражнения 122
9-й час. Диаграммы последовательностей 123
Что такое диаграмма последовательностей 123
Объекты 124
Сообщения 124
Время 125
Автомобили и ключи 126
Диаграмма классов 126
Диаграмма последовательностей 127
Автомат по продаже лимонада 128
Общая диаграмма последовательности 131
Отображение создания объекта на диаграмме последовательностей 132
Кадрирование последовательности в UML 2.0 135
Включения 135
Комбинирование фрагментов взаимодействия 137
Построение общей картины 138
Резюме 139
Вопросы и ответы 140
Практические занятия 140
Тесты 140
Упражнения 140
10-й час. Диаграллмы коммуникации 142
Что представляет собой диаграмма коммуникации 143
Автомобили и ключи 144
Изменение состояния и вложенные сообщения 145
Автомат для продажи лимонада 147
Создание объекта 148
Еще о нумерации 148
Еще несколько понятий 149
Множество объектов-получателей одного класса 149
Представление возвращаемых результатов 150
Активные объекты 151
Синхронизация 151
Построение общей картины 152
Резюме 153
Вопросы и ответы 153
Практические занятия 154
Тесты 154
Упражнения 154
11-й час. Диаграммы видов деятельности 155
Что такое диаграмма видов деятельности 156
Решения, решения, решения... 156
Параллельные пути 157
Сигналы 158
Применение диаграмм видов деятельности 158
Процесс “Создание документа” 158
Роли на диаграмме видов деятельности 159
Смешанные диаграммы 160
Новые понятия в UML 2.0 164
Объекты вида деятельности 164
Содержание
9
Исключения 165
Декомпозиция видов деятельности 166
Изображение длительности и момента завершения вида деятельности 167
Специальные эффекты 168
Обзорная диаграмма взаимодействия 169
Построение общей картины 172
Резюме 173
Вопросы и ответы 173
Практические занятия 174
Тесты 174
Упражнения 174
12-й час. Диаграммы компонентов 176
Что такое компонент 176
Компоненты и интерфейсы 177
Несколько слов об интерфейсах 177
Замещение и повторное использование 178
Что такое диаграмма компонентов 178
Представление компонента в UML 1.x и UML 2.0 178
Представление интерфейсов 179
Модели черного и белого ящика 181
Применение диаграмм компонентов 182
Диаграмма компонентов в общей картине UML 186
Резюме 187
Вопросы и ответы 188
Практические занятия 188
Тесты 188
Упражнения 188
13-й час. Работа с диаграммами развертывания 189
Что такое диаграмма развертывания 189
Применение диаграмм развертывания 192
Домашняя система 192
Кольцевая сеть с маркерным доступом 193
Сеть ARC 194
Сеть Ethernet 194
Беспроводная сеть Ricochet 195
Место диаграмм развертывания в общей картине UML 196
Резюме 198
Вопросы и ответы 198
Практические занятия 199
Тесты 199
Упражнения 199
14-й час. Пакеты и принципы построения UML 200
Диаграммы пакетов 201
Для чего нужны пакеты 201
Отношения между пакетами 201
Объединение пакетов 203
Иерархия 204
Аналогия 205
Двигаемся дальше 207
Только вперед... 207
Пакеты инфраструктуры UML 208
Пакет Основа 209
10
Содержание
Пакет Простые типы 209
Пакет Абстракции 210
Пакет Основные элементы 210
Пакет Структурные элементы 210
Пакет Профили 211
И снова... UML! 213
Еще раз о четырех уровнях 213
Пакеты суперструктуры UML 214
Пакет Классы 215
Пакет Общие элементы поведения 215
Пакет Прецеденты 215
Пакет Композитные структуры 216
Пакет Вспомогательные элементы 216
Расширение UML 216
Стереотипы 216
Зависимость 217
Класс 217
Пакет 217
Графические стереотипы 217
Ограничения 218
Тегированные значения 218
Резюме 219
Вопросы и ответы 219
Практические занятия 220
Тесты 220
Упражнения 220
15-й час. Место UML в процессе разработки 221
Методики: старая и новая 222
Старый способ 222
Новый способ 223
Что должно происходить в ходе процесса разработки 223
Процесс GRAPPLE 224
RAD3: Структура GRAPPLE 225
Формулирование требований 226
Изучение бизнес-процессов 226
Анализ предметной области 226
Определение взаимосвязанных систем 226
Выяснение системных требований 227
Представление результатов клиенту 227
Анализ 228
Определение прецедентов системы 228
Конкретизация прецедентов 228
Внесение уточнений в диаграммы классов 228
Анализ изменений состояния объектов 228
Определение взаимодействий между объектами 228
Анализ уровня интеграции с другими системами 229
Проектирование 229
Построение и уточнение диаграмм объектов 229
Построение диаграмм компонентов 229
План развертывания 229
Проектирование и создание прототипа пользовательского интерфейса 229
Проектирование тестов 230
Содержание
11
Техническая документация 230
Разработка 230
Конструирование кода 230
Тестирование кода 230
Конструирование пользовательского интерфейса, подключение к коду
и тестирование 230
Завершение комплекта документации 230
Развертывание 230
Планирование средств резервирования и восстановления 231
Установка готовой системы на соответствующих аппаратных средствах 231
Тестирование установленной системы 231
Празднование 231
Итоговые замечания о процессе GRAPPLE 231
Резюме 232
Вопросы и ответы 232
Практические занятия 232
Тесты 232
Часть II. Конкретный пример 233
16-й час. Знакомство с конкретным примером 234
Перейдем к делу 234
Применение процесса GRAPPLE для решения проблемы 235
Исследование бизнес-процессов 235
Обслуживание клиента 236
Приготовление блюда 240
Уборка стола 245
Полученные уроки 246
Резюме 247
Вопросы и ответы 247
Практические занятия 248
Тесты 248
Упражнения 248
17-й час. Анализ предметной области 249
Анализ интервью 250
Разработка исходной диаграммы классов 250
Группирование классов 251
Формирование ассоциаций 253
Ассоциации класса Клиент 254
Ассоциации класса ОбслуживающийПерсонал 257
Ассоциации класса ШефПовар 258
Ассоциации класса Уборщик 259
Ассоциации класса Управляющий 259
Отступление 259
Формирование агрегатов и композитов 260
Конкретизация классов 261
Клиент 262
Служащий 262
Счет 264
Общие вопросы 264
Словарь модели 264
Организация диаграмм 264
Полученные уроки 265
12
Содержание
Резюме 265
Вопросы и ответы 265
Практические занятия 266
Тесты 266
Упражнения 266
18-й час. Формирование системных требований 267
Разработка видения системы 269
Формулирование системных требований 275
Семинар по формулированию требований 275
Итог 278
Что дальше 280
Резюме 280
Вопросы и ответы 280
Практические занятия 281
Тесты 281
Упражнение 281
19-й час. Разработка прецедентов 282
Изучение прецедентов 282
Анализ прецедентов 283
Пакет Официант 284
Прецедент Прием заказа 284
Прецедент Передача заказа на кухню 285
Прецедент Изменение заказа 285
Прецедент Контроль состояния заказа 286
Прецедент Уведомление шеф-повара о состоянии компании 286
Описание 287
Предположения 287
Предусловия 287
Постусловия 287
Основные действия 287
Лицо, для которого выполняются действия 288
Прецедент Подготовка счета 288
Описание 288
Предположения 288
Предусловия 288
Постусловия 288
Основные действия 288
Лицо, для которого выполняются действия 288
Прецедент Распечатка счета 288
Описание 288
Предположения 288
Предусловия 288
Постусловия 289
Основные действия 289
Лицо, для которого выполняются действия 289
Прецедент Вызов уборщика 289
Описание 289
Предположения 289
Предусловия 289
Постусловия 289
Основные действия 289
Лицо, для которого выполняются действия 289
Содержание 13
Остальные прецеденты 290
Компоненты системы 290
Резюме 291
Вопросы и ответы 292
Практические занятия 292
Тесты 292
Упражнения 292
20-й час. Взаимодействие элементов системы и изменение их состояния 293
Элементы системы 293
Пакет Официант 294
Пакет Шеф-повар 294
Пакет Уборщик 294
Пакет ПомощникОфицианта 295
Пакет ПомощникШефПовара 295
Пакет Бармен 295
Пакет Гардеробщик 295
Взаимодействия в системе 296
Прием заказа 296
Изменение заказа 297
Контроль состояния заказа 298
Итоги 299
Резюме 300
Вопросы и ответы 300
Практические занятия 301
Тесты 301
Упражнения 301
21-й час. Проектирование интерфейса пользователя и развертывание
системы 302
Некоторые принципы проектирования GUI 302
Сеанс JAD, посвященный GUI 304
От прецедентов к пользовательским интерфейсам 305
Диаграммы UML для проектирования GUI 307
Планирование развертывания системы 308
Сеть 309
Диаграмма развертывания 309
Следующие шаги 309
...А сейчас, несколько слов от спонсора 310
Обеспечение возможностей продавцов 311
Развитие ресторанного бизнеса 311
Резюме 312
Вопросы и ответы 313
Практические занятия 313
Тесты 314
Упражнения 314
22-й час. Знакомство с шаблонами проектирования 315
Параметризация 315
Шаблоны проектирования 317
Шаблон Цепочка обязанностей 318
Шаблон Цепочка обязанностей в предметной области ресторана 319
Применение шаблона Цепочка обязанностей для моделирования
событий в Web-браузере 320
14
Содержание
Разработка собственного шаблона проектирования 322
Преимущества шаблонов проектирования 324
Резюме 324
Вопросы и ответы 325
Практические занятия 325
Тесты 325
Упражнения 325
Часть III. Взгляд в будущее 327
23-й час. Моделирование встроенных систем 328
Назад к ресторану 328
Голь на выдумки хитра 329
Детализация проекта ВозьмиИСожми 329
Что представляет собой встроенная система 331
Принципы организации встроенных систем 332
Время 332
Процессы 332
Прерывания 333
Операционная система 334
Моделирование устройства ВозьмиИСожми 336
Классы 336
Прецеденты 338
Взаимодействия 338
Общие изменения состояния 341
Развертывание 341
Напряжение мышц 342
Резюме 342
Вопросы и ответы 343
Практические занятия 343
Тесты 343
Упражнения 343
24-й час. Картина будущего UML 344
Расширения в области бизнеса 344
Выводы из расширений для бизнеса 346
Графический пользовательский интерфейс 346
Подключение прецедентов 346
Моделирование пользовательского интерфейса 346
Экспертные системы 347
Компоненты экспертной системы 348
Пример 350
Моделирование базы знаний 351
Web-приложения 353
Вот и все, друзья 355
Резюме 355
Вопросы и ответы 356
Практические занятия 356
Тесты 356
Упражнения 356
Часть IV. Приложения 357
Приложение А. Ответы 358
1-й час 358
Содержание 15
2-й час 358
3-й час 359
4-й час 359
5-й час 360
6-й час 360
7-й час 360
8-й час 361
9-й час 361
10-й час 362
11-й час 362
12-й час 363
13-й час 363
14-й час 364
15-й час 364
16-й час 364
17-й час 365
18-й час 365
19-й час 365
20-й час 366
21-й час 366
22-й час 367
23-й час 367
24-й час 367
Приложение Б. Использование средств моделирования, поддерживающих
язык UML 369
Какие возможности предоставляют средства моделирования 369
Использование UML в Visio Professional Edition 370
Итак, начнем 372
Диаграмма классов 372
Диаграмма объектов 381
Диаграмма последовательности 384
Другие средства моделирования 389
Rational Rose 389
Select Component Architect 389
Visual UML 390
Приложение В. Резюме в картинках 391
Диаграмма видов деятельности 392
Диаграмма классов 394
Диаграмма коммуникации 395
Диаграмма компонентов 396
Структурная композитная диаграмма 396
Диаграмма развертывания 397
Диаграмма объектов 397
Диаграмма пакетов 398
Параметризованная диаграмма взаимодействия 398
Диаграмма последовательности 399
Диаграмма состояний 400
Временная диаграмма 400
Диаграмма прецедентов 401
Предметный указатель 402
16
Содержание
Благодарности
Написание книги — очень сложный процесс, и подготовка нового издания — не
исключение. К счастью, группа профессионалов мирового класса из издательства
Sams Publishing смогла его значительно облегчить. С удовольствием еще раз высказы-
ваю благодарность всему коллективу за вклад в создание книги.
За работу над первым изданием хочется поблагодарить редакторов Криса Веба
(Chris Webb) и Мэта Парсела (Matt Purcell), которые помогли облечь мои мысли в ли-
тературную форму. Выражаю им признательность за профессиональное мастерство, а
также за терпение и поддержку. Технические редакторы Билл Ров (Bill Rowe) и Майкл
Тоблер (Michael Tobler) обеспечили техническое оформление книги, за что я им бла-
годарен. Старший редактор издательства Сюзан Мур (Susan Moore) и многие другие
сотрудники превратили рукопись в книгу, которую вы держите в руках.
В работе над вторым изданием большую помощь оказали редакторы Майкл Сте-
фенс (Michael Stephens), Кристи Франклин (Christy Franklin), Мэт Виналда (Matt
Wynalda) и технический редактор Поль Густавсон (Paul Gustavson). Их терпение, муд-
рость и профессионализм способствовали усовершенствованию материалов, вошед-
ших в книгу.
Процесс работы над третьим изданием существенно ускорил редактор Тодд Грин
(Todd Green). Благодаря его стараниям, а также усилиям Сонглина Квиу (Songlin Qiu)
работа над этим изданием прошла достаточно гладко. Спасибо им за терпение. Редак-
тор проекта Мэт Парсел (Matt Purcell) (он снова работал над книгой, но уже в новой
роли) внес неоценимый вклад в формирование материала, а менеджер проекта Ян
Фишер (Ian Fisher) обеспечил соблюдение сроков при работе над проектом. Опыт и
знания технического редактора Джеффри Пайора (JeDffiey Payor) помогли существенно
уточнить содержание книги.
Выражаю благодарность своему агенту Девиду Фагейту (David Fugate) из издатель-
ства Waterside Production.
В процессе работы над всеми изданиями книги мои коллеги проявили чувство со-
лидарности и стремление к сотрудничеству. В частности, дискуссии с Кейтом Барре-
том (Keith Barret) и Робом Уорнером (Rob Warner) помогли мне в решении многих
вопросов. К сожалению, работа над первым изданием была омрачена безвременной
кончиной руководителя нашего отдела Тома Вильямсона (Tom Williamson). Том был
душой отдела, советчиком, руководителем, коллегой и другом.
Я благодарен своим друзьям за постоянную поддержку и участие. Спасибо моей
маме и брату Дэвиду (David) за их любовь и внимание, а также Кэтрин (Kathrin) за
все, что она сделала для меня.
Введение
Для системы самое главное — видение. Сложная система рождается на свет, когда
ее автор понимает, как технология может улучшить жизнь. Разработчики должны об-
рести это видение и держать его в уме в процессе реализации и создания системы.
Успешные проекты разработки позволяют сократить разрыв (построить мост) меж-
ду видением системы и ее воплощением. Унифицированный язык моделирования
UML (Unified Modeling Language) — средство построения этого моста. Он помогает
отобразить видение системы и дает возможность обсуждать его со всеми заинтересо-
ванными лицами. Это делается с помощью набора обозначений и диаграмм. Каждая
диаграмма играет свою роль в процессе разработки.
Основная цель этой книги — дать полное представление о UML за 24 часа изуче-
ния. В каждой главе приводятся примеры, облегчающие понимание материала, а так-
же упражнения, позволяющие закрепить полученные знания.
Что нового в этом издании
При подготовке этого издания автор внимательно проанализировал и переработал
два предыдущих, добавил и уточнил необходимый материал. Некоторые добавления
обусловлены появлением новой версии языка моделирования — UML 2.0. Другие мо-
дификации связаны с изменением и обновлением технологии за время, прошедшее с
момента выхода в свет предыдущего издания.
Как и в двух предыдущих изданиях, первая часть книги посвящена теоретическим
основам языка UML. В этом издании автор постарался изложить новые понятия вер-
сии UML 2.0.
Модифицированы некоторые модели и диаграммы, а также добавлены тесты и уп-
ражнения. В этом издании каждая диаграмма взаимодействия сопровождается диа-
граммой классов, позволяющей лучше понять взаимосвязи между классами. Благодаря
такой модификации диаграммы взаимодействия стали более понятными. Если вы уже
немного знакомы с языком UML, то понимаете, что автор имеет в виду. Если — нет,
поймете после прочтения книги.
Для кого предназначена эта книга
Эта книга рассчитана на системных аналитиков, менеджеров, разработчиков и ди-
зайнеров, которые хотят быстро освоить язык UML. Если вы хотите начать работу
с UML немедленно или планируете быстро понять основные принципы этого язы-
ка, — эта книга для вас.
Структура книги
Книга разделена на три части. В первой дается общее представление об UML
и рассмотрены базовые понятия объектно-ориентированного подхода, положенного
в основу построения диаграмм классов и объектов. Рассмотрены прецеденты, позво-
ляющие изобразить систему с точки зрения пользователя, рассказано, как строить
диаграммы прецедентов. Много внимания уделено и другим вопросам. В остальных
главах части I рассматриваются другие типы диаграмм UML.
В части II представлена упрощенная методика разработки на примере условной
системы, показано, как UML используется в контексте выполнения проекта, а также
каким образом элементы UML объединяются в общей модели системы.
В части III показано применение языка UML для разработки шаблонов, встроен-
ных систем и т.д.
Некоторые производители предлагают пакеты, позволяющие строить диаграммы
UML и интегрировать их в рамках модели. В приложении Б рассказывается о созда-
нии трех типов диаграмм UML с помощью высокоуровневого средства построения
диаграмм Microsoft Visio ProCBssional Edition, а также кратко описываются три других
средства моделирования.
Для построения диаграмм и выполнения упражнений из этой книги вам понадо-
бится только карандаш и бумага, а также знание принципов построения программных
систем.
Принятые в книге обозначения
В начале каждой главы приводится список рассматриваемых в ней вопросов.
Новые термины выделены курсивом.
Эта пиктограмма сопровождает интересные фрагменты информации, напрямую не связан-
ные с рассматриваемым вопросом.
Итак, приступим!
Введение
21
Ждем ваших отзывов!
Вы, читатель этой книги, и есть главный ее критик и комментатор. Мы ценим ва-
ше мнение и хотим знать, что было сделано нами правильно, что можно было сделать
лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно услышать и
любые другие замечания, которые вам хотелось бы высказать в наш адрес.
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам бу-
мажное или электронное письмо либо просто посетить наш Web-сервер и оставить
свои замечания там. Одним словом, любым удобным для вас способом дайте нам
знать, нравится вам эта книга или нет, а также выскажите свое мнение о том, как
сделать наши книги более интересными для вас.
Посылая письмо или сообщение, не забудьте указать название книги и ее авторов,
а также ваш обратный адрес. Мы внимательно ознакомимся с вашим мнением и обя-
зательно учтем его при отборе и подготовке к изданию последующих книг. Наши ко-
ординаты:
E-mail: info@williamspublishing.com
WWW: http: //www.williamspublishing.com
Адреса для писем из:
России: 115419, Москва, а/я 783
Украины: 03150, Киев, а/я 152
22
Введение
Часть I
Начало
Темы занятий
1. Введение в UML
2. Знакомство с объектно-ориентированным подходом
3. Использование концепций объектно-ориентированного проектирования
4. Работа со связями
5. Агрегация, композитные объекты, интерфейсы и реализации
6. Знакомство с прецедентами
7. Использование диаграмм прецедентов
8. Диаграммы состояний
9. Диаграммы последовательностей
10. Диаграммы коммуникации
11. Диаграммы видов деятельности
12. Диаграммы компонентов
13. Работа с диаграммами развертывания
14. Пакеты и принципы построения UML
15. Место UML в процессе разработки
1-й час
Введение в UML
Из этого часа вы узнаете
> Назначение языка UML
> Как создавался UML
> Как представляются компоненты на диаграммах UML
> Зачем нужно такое количество различных типов диаграмм
В настоящее время унифицированный язык моделирования (UML — Unified
Modeling Language) является одним из наиболее популярных инструментов в сфере
разработки объектно-ориентированных систем. Почему именно он? UML является
визуальным языком моделирования, который позволяет системным архитекторам
представлять свое видение системы в стандартной и легкой для понимания форме.
Кроме того, UML предоставляет эффективный механизм совместного использования
проектных решений и взаимодействия разработчиков друг с другом.
Сформировать видение системы — чрезвычайно важный момент. До появления
языка UML процесс разработки зачастую основывался на сделанных наугад предпо-
ложениях. Системный аналитик должен был оценить потребности клиентов, сформу-
лировать задачу в понятной для специалиста форме (не всегда для клиента), передать
результаты своего анализа программисту или группе программистов и надеяться, что
конечный программный продукт будет представлять собой именно ту систему, кото-
рая нужна клиенту.
Поскольку процесс разработки системы во многом зависит от человеческой дея-
тельности, то на любой стадии могут возникать ошибки. Аналитик может неправиль-
но понять клиента и создать непонятный для него документ. Результаты работы ана-
литика могут оказаться неочевидными для программистов, которые создадут сложную
в использовании программу, не позволяющую клиенту решить исходную задачу.
Некоторые термины
В этой книге предполагается, что система - это комбинация программных и аппаратных
средств, которые обеспечивают выполнение поставленной задачи. Разработка системы
представляет собой процесс ее создания для клиента, т.е. человека, которому необходимо
решить какую-либо проблему. Аналитик разрабатывает документы с описанием этой про-
блемы и передает их разработчикам— программистам, которые создают программное
обеспечение для решения требуемой задачи и гарантируют его развертывание на аппарат-
ных средствах.
Не удивительно, что многие из долго используемых систем громоздки и трудны в
использовании.
Упорядочение
На ранних этапах развития вычислительной техники программисты анализировали
проблему “на пальцах”. Если какой-нибудь анализ вообще выполнялся, то для этого
использовалась “обратная сторона салфетки”. Зачастую программы разрабатывались
“с нуля”, а код создавался по мере решения задачи. Хотя такой подход и придавал
этому процессу черты романтизма и отчаянной смелости, практика показала его не-
эффективность.
В настоящее время ключевым моментом процесса разработки является хорошо
продуманный план. Клиент должен разобраться в том, что собирается делать группа
разработчиков, и должен иметь возможность внести поправки, если его задачи реша-
ются не в полном объеме (или если изменится его представление о создаваемой сис-
теме). С другой стороны, в процессе разработки обычно задействованы усилия целой
группы специалистов. При этом каждый разработчик должен представлять решаемую
задачу в целом и осознавать свою собственную роль в ее решении.
Окружающий мир становится все более сложным. Поэтому отражающие его ком-
пьютерные системы также усложняются. Зачастую они состоят из большого числа
программных и аппаратных компонентов, взаимодействующих друг с другом на
больших расстояниях и связанных с базами данных, в которых содержится огромное
количество информации. Как же научиться преодолевать сложности и создавать хо-
рошие системы?
Ключевым аспектом процесса проектирования является его правильная организа-
ция, когда аналитики, клиенты, программисты и другие специалисты, участвующие в
разработке системы, способны понять друг друга и придти к общему мнению. Язык
UML и обеспечивает такую возможность.
Ни одно сложное сооружение, например офисное здание, не строится без разра-
ботки подробной документации. Продумывание любой сложной системы должно на-
чинаться с создания подробного плана. Его необходимо составить так, чтобы можно
было предоставить клиенту. Именно таким образом поступает архитектор, когда гото-
вит чертежи и документацию для заказчика, оплачивающего строительство. План раз-
работки должен создаваться лишь после тщательного анализа требований клиента.
Еще одной отличительной чертой процесса разработки современных систем явля-
ется дефицит времени для выполнения работ. Если предельные сроки сдачи подсис-
тем нагромождаются друг на друга, то обеспечение непрерывности процесса разработ-
ки становится жизненно важной необходимостью.
Другой аспект современной жизни — слияние корпораций — также предъявляет
жесткие требования к процессу проектирования. Когда одна компания приобретает
другую, новая организация должна внести изменения в процесс разработки (средства
реализации, язык программирования и т.д.). Четко обусловленный план позволит
1-й час. Введение в UML
25
снизить издержки. При тщательном планировании изменения в реализации будут
происходить более незаметно.
Потребность в качестве процесса разработки обуславливает необходимость созда-
ния стандартных условных обозначений, которые используются аналитиками, разра-
ботчиками и клиентами. Точно такие же стандартные обозначения применяются в
схемах инженерами-электронщиками, а обозначения диаграмм Фейнмана являются
стандартом де-факто для физиков. Язык UML представляет собой именно такую сис-
тему обозначений.
История создания языка UML
Авторами UML являются Гради Буч (Grady Booch), Джеймс Румбах (James
Rumbaugh) и Айвар Якобсон (Ivar Jacobson). Известные как “три товарища”, в 1980-х —
начале 1990-х годов они работали в разных организациях и независимо друг от друга
продумывали методы объектно-ориентированного анализа и проектирования, которые
имели явные преимущества перед всеми известными методами. В середине 1990-х годов
они стали заимствовать идеи друг друга и поэтому решили объединить свои усилия.
Объектно-ориентированный подход
Концепции объектно-ориентированного проектирования более подробно рассматриваются в
главе 2, “Знакомство с объектно-ориентированным подходом”, главе 3, “Использование
концепций объектно-ориентированного проектирования”, а также в главе 4, “Работа со свя-
зями”. Эти концепции играют ключевую роль в данной книге.
В 1994 году Румбаха пригласили в компанию Rational Software Corporation, где уже
работал Буч. Через год к ним присоединился Якобсон.
Остальное, как говорят, — история. Предварительные версии UML начали исполь-
зоваться в области создания программного обеспечения, а на основании отзывов по-
требителей производились существенные доработки. Многие корпорации ощутили,
что язык UML может быть им полезен для достижения стратегических целей. Это
привело к возникновению консорциума UML, в который вошли такие компании, как
DEC, Hewlett-Packard, Intellicorp, MicrosoCt, Oracle, Texas Instruments, Rational и дру-
гие. В 1997 году консорциум выработал первую версию UML и представил ее на рас-
смотрение группе OMG (Object Management Group), откликнувшись на призыв пода-
вать предложения по стандартному языку моделирования.
После расширения консорциума вышла версия 1.1 языка UML, которую группа
OMG приняла в конце 1997 года. После этого OMG приступила к сопровождению
UML и выпустила в 1998 году две его новые версии. Язык UML стал стандартом де-
факто в области разработки программного обеспечения. В настоящее время этот язык
продолжает активно развиваться. За последние годы увидели свет версии 1.3, 1.4. 1.5,
а недавно группа OMG одобрила версию 2.0. В основу большинства моделей совре-
менных систем и многих книг по моделированию положены обозначения более ран-
них версий (так называемых версий 1.x). Поэтому в книге будут отслеживаться разли-
чия в обозначениях между новой и предыдущими версиями языка.
Компоненты UML
Язык UML включает набор графических элементов, используемых на диаграммах.
Будучи языком, UML содержит правила для объединения этих элементов. Перед тем
как изучать эти элементы и правила, рассмотрим диаграммы, используемые при ана-
лизе системы.
26
Часть I. Начало
С места в карьер
Этот подход аналогичен применяемому при изучении иностранного языка, когда сразу начи-
нают использовать этот язык, а не изучают грамматику и спряжения глаголов. Потратив не-
много времени и пытаясь говорить на этом языке, вы скорее поймете грамматические пра-
вила.
Диаграммы используются для отображения различных представлений системы.
Этот набор различных представлений называется моделью. Модель UML системы
можно сравнить с художественно оформленной моделью здания. Важно отметить, что
модель UML описывает, что должна делать система. В то же время, ничего не сооб-
щается о том, как она будет реализована.
В последующих разделах кратко описаны наиболее общие диаграммы UML и кон-
цепции, которые они представляют, а также исследована каждая из них более под-
робно. Имейте в виду, что можно использовать гибридные диаграммы и что UML
обеспечивает возможности для организации и развития таких диаграмм.
Модели
Концепция модели полезна в научной и инженерной сферах. При создании модели исполь-
зуется что-то очень хорошо известное, для того чтобы понять нечто менее известное. В не-
которых областях деятельности модель представляет собой набор уравнений. В других —
это компьютерное моделирование. Возможно существование различных типов моделей.
В нашем случае модель является набором диаграмм UML, которые можно исследовать, оце-
нивать и изменять, чтобы понять и спроектировать систему.
Диаграмма классов
Подумайте о вещах в окружающем мире. (Довольно неопределенное требование, но
все равно попробуйте!) Вероятно, большинство из них имеют атрибуты (свойства) и
действуют определенным образом. Мы будем считать эти действия набором операций.
Также можно увидеть, что все понятия естественным образом разделяются по ка-
тегориям (автомобили, мебель, стиральные машины и т.д.). Мы обращаемся к этим
категориям как к классам. Класс — это категория или группа вещей, которая имеет
сходные атрибуты и общие свойства. Например, любой объект в классе стиральных
машин имеет такие атрибуты, как производитель, номер изделия и емкость. Свойства
объектов этого класса включают операции “загрузить белье”, “засыпать стиральный
порошок”, “включить” и “выключить”.
На рис. 1.1 представлен пример обозначения UML, где показаны атрибуты и свой-
ства стиральной машины. Класс представляется прямоугольником, разделенным на
три области. Самая верхняя область содержит имя, в средней располагаются атрибуты,
а в самой нижней — операции.
Обратите внимание на специфику обозначений классов, атрибутов и операций.
В UML имена классов зачастую включают несколько слов. При этом каждое слово в
имени класса начинается с прописной буквы, а пробелы между словами отсутствуют
(например, СтиральнаяМашина). Имена атрибутов и операций строятся по тем же
правилам, но первая буква в имени этих элементов обычно является строчной
(например, загрузитьБелье). После имени операции следуют круглые скобки.
(Почему это так, вы поймете, прочитав главу 3.)
Как вы узнаете из главы 4, диаграмма классов состоит из определенного количест-
ва прямоугольников, соединенных линиями, которые показывают, как классы связа-
ны между собой.
1-й час. Введение в UML
27
СтиральнаяМашина
производитель
модель
серийныйНомер
емкость
загрузитьБелье()
загрузитьСтиральныйПорошок()
включить()
выключить()
Рис. 1.1. Изображение класса в UML
Зачем размышлять о классах вещей, их атрибутах и операциях? Для взаимодейст-
вия с нашим сложным миром наиболее современное программное обеспечение моде-
лирует некоторые его аспекты. Десятилетний опыт подсказывает, что проще разраба-
тывать программное обеспечение, которое работает таким образом и представляет
классы реально существующих вещей. Диаграммы классов представляют собой отпра-
вную точку процесса разработки.
Диаграммы классов помогают также при анализе. Они позволяют аналитику об-
щаться с клиентом в привычных ему терминах и стимулируют процесс выявления
важных деталей в проблеме, которую требуется решить.
Диаграмма объектов
Объект представляет собой экземпляр класса — особую сущность, которая имеет
заданные значения атрибутов и операций. Ваша стиральная машина, например, может
иметь следующие атрибуты: компания-производитель — Laundatorium, наименование
модели — Washmeister, серийный номер изделия — GL57774 и емкость — 16 фунтов.
На рис. 1.2 показано, как объект представляется в обозначениях UML. Отметим,
что объект изображается прямоугольником, как в случае представления класса, но его
имя подчеркнуто. Наименование экземпляра размещено слева от двоеточия, а наиме-
нование класса — с правой стороны. Имя объекта начинается со строчной буквы.
Существуют также анонимные объекты. Обозначение такого объекта показано на
рис. 1.2 справа. Оно свидетельствует о том, что объект принадлежит некоторому клас-
су, но не имеет имени.
мояМашина:СтиральнаяМашина
:СтиральнаяМашина
Рис. 1.2. Два обозначения объектов в UML. Сле-
ва представлен именованный объект, а спра-
ва — анонимный
Диаграмма прецедентов
Прецедент — это описание поведения системы с точки зрения пользователя. Для
разработчиков системы это полезный инструмент, предоставляющий надежную мето-
дику формирования требований к системе с точки зрения пользователя. Это важно,
если целью работы является создание системы, которую смогут использовать обычные
люди, а не только компьютерные фанаты.
28
Часть I. Начало
Прецеденты будут подробнее описаны в главах 6, “Знакомство с прецедентами”, 7,
“Использование диаграмм прецедентов”, 18, “Формирование системных требований”
и 19, “Разработка прецедентов”. А сейчас рассмотрим простой пример. Вы используе-
те стиральную машину, вероятно, чтобы стирать белье. На рис. 1.3 показано, как
можно это отразить на диаграмме прецедентов UML.
Рис. 1.3. Диаграмма прецедентов UML
Небольшая простая фигурка, соответствующая пользователю стиральной машины,
называется исполнителем (actor). Эллипс представляет прецедент. Отметим, что испол-
нитель, инициирующий прецедент, может быть как человеком, так и другой системой.
Диаграмма состояний
В каждый момент времени объект находится в определенном состоянии: человек
может быть новорожденным, младенцем, ребенком, юношей, подростком или взрос-
лым. Лифт может двигаться вверх, находиться в неподвижном состоянии или двигать-
ся вниз. Стиральная машина может находиться в состоянии замачивания белья, стир-
ки, полоскания, отжима или быть выключенной.
Диаграмма состояний UML, представленная на рис. 1.4, отображает эту сторону
реальности. Диаграмма показывает, как стиральная машина переходит из одного со-
стояния в другое.
Символ вверху диаграммы представляет начальное состояние, а символ внизу со-
ответствует конечному.
Замачивание
Полоскание
Отжим
Рис. 1.4. Диаграмма со-
стояний UML
1-й час. Введение в UML
29
Переходы
Переходы между состояниями не всегда линейны. Иногда переход диктуется некоторым ус-
ловием. Об этом вы узнаете из главы 8, “Диаграммы состояний”.
Диаграмма последовательностей
Диаграммы классов и диаграммы объектов дают статическую информацию. Однако
во время работы системы объекты взаимодействуют друг с другом, и это взаимодейст-
вие происходит во времени. Диаграмма последовательностей UML показывает вре-
менную динамику взаимодействия.
Возвращаясь к примеру со стиральной машиной, отметим, что машина включает
трубу для подачи (чистой) воды, барабан (часть, в которой находится белье) и сливную
трубу. Это тоже объекты. (Вы увидите, что один объект может состоять из других.)
Что происходит при выполнении прецедента “стирка белья”? Предположим, что
операции “загрузка белья”, “загрузка порошка” и “включение” уже выполнены. Тогда
последовательность действий может состоять из следующих шагов.
1. В начале режима замачивания вода поступает в барабан через подводящую трубу.
2. Барабан остается неподвижным в течение пяти минут.
3. По окончании режима замачивания прекращается подача воды.
4. После начала режима стирки барабан вращается вперед и назад пятнадцать минут.
5. По завершении режима стирки мыльная вода выливается через сливную трубу.
6. Барабан перестает вращаться.
7. С началом режима полоскания возобновляется подача воды.
8. Барабан продолжает вращаться вперед и назад.
9. Через 15 минут прекращается подача воды.
10. По завершении режима полоскания отжатая вода выливается через сливную трубу.
11. Барабан прекращает вращаться.
12. С началом режима отжима барабан начинает вращаться с более высокой ско-
ростью. Вращение происходит в течение пяти минут.
13. По завершении режима отжима вращение барабана прекращается.
14. Стирка окончена.
Представьте себе следующие объекты: таймер, насос и барабан. С каждым из этих
объектов связано несколько операций. Эти объекты совместно работают, передавая
друг другу сообщения. Каждое сообщение — это запрос объекта-отправителя к объек-
ту-получателю. Запрос требует выполнения одной из операций получателя.
Давайте конкретизируем операции, связанные с перечисленными выше объектами.
Таймер может выполнять следующие операции.
Засечь время замачивания.
Засечь время стирки.
Засечь время полоскания.
Засечь время отжима.
Насос может выполнять следующие действия.
Подавать воду.
Прекратить подачу воды.
30
Часть I. Начало
Барабан может выполнять следующие операции.
Закрыть клапан слива воды.
Вращаться вперед и назад.
Быстро вращаться.
Прекратить вращение.
Открыть клапан слива воды.
Рис. 1.5. Диаграмма последовательностей UML
На рис. 1.5 показана диаграмма последовательностей, иллюстрирующая выполне-
ние этих операций в процессе передачи сообщений между таймером, насосом и бара-
баном. Эти сущности показаны в верхней части диаграммы в виде анонимных объек-
тов. Стрелки на диаграмме означают передачу сообщений между объектами. На этой
1-й час. Введение в UML
31
диаграмме время изменяется сверху вниз. Первое сообщение засечьВремяЗамачива-
ния () таймер отправляет сам себе. Следующее сообщение податьВоду О он передает
насосу. И, наконец, последнее сообщение на диаграмме остановитьВращениеО по-
ступает от таймера барабану.
Заметим, что объект (в данном случае таймер) может отправлять сообщения сам
себе. Обратите также внимание на разную форму стрелок на диаграмме. Об этом бо-
лее подробно будет рассказано в главе 9, “Диаграммы последовательностей”.
Если вы забыли, что такое анонимный объект, обратитесь к рис. 1.2.
Диаграмма видов деятельности
Действия, которые совершаются при выполнении прецедента или во время функ-
ционирования объекта, обычно происходят последовательно, как описанные выше
шаги работы стиральной машины. На рис. 1.6 показано, как на диаграмме видов дея-
тельности UML представлены шаги 4-6 этой цепочки.
Еще раз о переходах
Выше уже упоминалось о том, что переходы между состояниями не всегда бывают линей-
ными. Это отражается и на диаграммах видов деятельности. Об этом речь пойдет в гла-
ве 11, “Диаграммы видов деятельности”.
^Вращение барабана вперед и назад (15 минут)^
V_____________.
Слив мыльной воды из барабана
Останов вращения
Рис, 1.6. Диаграмма видов деятельности UML
Диаграмма коммуникации
Элементы системы совместно работают для достижения общих целей системы, и
язык моделирования должен иметь возможность показать это. Диаграмма коммуника-
ции UML, как и диаграмма последовательностей, тоже позволяет отразить взаимодей-
ствие объектов, но в несколько ином виде. На рис. 1.7 показана диаграмма коммуни-
кации, которая отражает передачу первых трех сообщений между таймером, насосом и
барабаном, показанных на рис. 1.5. На этой диаграмме время не изменяется сверху
вниз. Очередность событий на диаграмме показана с помощью числовой метки на со-
общении.
Как диаграммы последовательностей, так и диаграммы коммуникации отражают
взаимодействие объектов. По этой причине эти два вида диаграмм в UML называют
диаграммами взаимодействия (interaction diagram).
32
Часть I. Начало
Рис. 1.7. Диаграмма коммуникации UML
Изменение названия
Термин диаграмма коммуникации появился в версии UML 2.0. В версиях 1.x такие диаграм-
мы назывались диаграммами кооперации. Не удивляйтесь, если эти два термина будут ис-
пользоваться в качестве синонимов.
Диаграмма компонентов
Эта и следующая за ней диаграммы не имеют отношения к миру стиральных ма-
шин, потому что они предназначены только для компьютерных систем.
Проектирование современного программного обеспечения происходит путем раз-
работки компонентов, что очень важно при организации совместных работ коллекти-
ва программистов. На рис. 1.8 показано изображение компонента программного обес-
печения, принятое в версиях UML 1.x.
В UML 2.0 с учетом пожеланий многих пользователей появилось новое обозначе-
ние программного компонента. Оно показано на рис. 1.9.
Рис. 1.8. Программный
компонент в обозначе-
ниях UML 1.x
Рис. 1.9. Обозначение
программного компо-
нента в UML 2.0
Что за скобки?
Что это за угловые скобки (« »), окружающие слово "компонент” на рис. 1.9? Это специ-
альное обозначение UML, о котором вы прочтете ниже в этой главе.
1-й час. Введение в UML
33
Диаграмма развертывания
Диаграмма развертывания UML показывает физическую архитектуру компьютер-
ной системы. Она представляет компьютеры и устройства, их соединение между со-
бой, а также программное обеспечение, размещенное на каждой машине. Компьюте-
ры изображаются в виде куба, а соединения между ними — в виде линий. Пример
диаграммы развертывания показан на рис. 1.10.
Рис. 1.10. Диаграмма развертывания UML
Некоторые дополнения
Ранее упоминались возможности UML, позволяющие организовать и расширить
диаграммы. В этом разделе речь пойдет о некоторых из них.
Примечания
Часто случается, что часть диаграммы недостаточно понятна. Неясно, почему она
расположена именно там, или как с ней работать. В этом случае полезно использовать
примечания (note) UML. Они представляют собой графические эквиваленты желтой
наклейки и изображаются в виде прямоугольника с загнутым уголком. Внутри прямо-
угольника размещается пояснительный текст. На рис. 1.11 представлен пример при-
соединения такого комментария к элементу диаграммы.
Некоторый пояснительный
текст для Класса 1
Класс 1
Рис. 1.11. В любую диаграмму можно вве-
сти пояснительный комментарий
34
Часть I. Начало
Ключевые слова и стереотипы
UML обеспечивает определенное количество необходимых понятий, но, к сожале-
нию, не исчерпывающий набор. При разработке системы обычно необходимы инди-
видуальные настройки UML. Стереотипы (stereotype) позволяют создавать новые эле-
менты UML на базе существующих. Это напоминает покупку деталей для изготовле-
ния полки, которую нужно приспособить к размерам помещения. Идея стереотипа
как раз соответствует такого рода изменениям. Его имя представляется в двух парах
угловых скобок. Само имя стереотипа называют ключевым словом (keyword).
В UML иногда происходит следующее. Вместо создания абсолютно нового симво-
ла, обозначающего некоторое понятие, к существующему элементу добавляется новое
ключевое слово. Это ключевое слово означает, что в данном случае привычный эле-
мент используется в несколько необычном смысле. Хорошим примером может послу-
жить концепция интерфейса, о которой речь пойдет в главе 5, “Агрегация, композит-
ные объекты, интерфейсы и реализации”. Интерфейс представляет собой класс, кото-
рый обладает только операциями, но не имеет атрибутов. Допустим, существует набор
операций, который можно повторно использовать в модели. Вместо включения но-
вого элемента для представления интерфейса, можно использовать изображение клас-
са с ключевым словом <<интерфейс», размещенным прямо над именем класса. На
рис. 1.12 показано, как это сделать.
<<интерфейс»
ИмяИнтерфейса
Рис. 1.12. Стереотип позволяет
создавать новые элементы на
основе существующих за счет
добавления ключевого слова, за-
ключенного в две пары угловых
скобок. Ключевое слово означа-
ет, что данный элемент ис-
пользуется в несколько необыч-
ном смысле
Концепция стереотипа особенно полезна при использовании автоматизированных
средств моделирования. Такие средства обычно позволяют создать “словарь” элемен-
тов, используемых в модели, — классов, прецедентов, компонентов и т.д. (Термин
“словарь” введен автором этой книги. В разных системах моделирования для обозна-
чения этого понятия применяются различные названия.) Словарь позволяет работать
только с существующими элементами UML, а также со стереотипами, созданными на
базе этих элементов. Так, стереотипы позволяют создавать новые типы элементов и
сохранять их в словаре. Это очень важно, поскольку словарь помогает управлять мо-
делью и обеспечивает повторное использование ее элементов.
1-й час. Введение в UML
35
В главе 14, “Пакеты и принципы построения UML” понятие стереотипа рассмат-
ривается более подробно. А пока вам достаточно познакомиться с его обозначением и
понять смысл ключевых слов. Имейте в виду, что автоматизированные системы моде-
лирования на UML обычно содержат некоторый встроенный набор стереотипов и
ключевых слов (таких как <<компонент>> и <<интерфейс>>).
Регресс?
Обозначение стереотипа впервые встретилось в этой книге при описании диаграммы компо-
нентов. Там речь шла о том, что существующий в UML 1.x символ компонента в новой вер-
сии UML2.0 заменен обозначением, показанным на рис. 1.9. Однако при описании стерео-
типа говорилось, что этот элемент используется для создания новых элементов (для кото-
рых в UML не предусмотрено стандартных обозначений) на базе существующих. В случае с
символом компонента все произошло наоборот: обозначение класса с ключевым словом в
новой версии было введено взамен существующего в прежних версиях стандартного обо-
значения компонента.
Новые диаграммы в UML 2.0
Помимо новых принципов обозначений (например, способа изображения про-
граммного компонента) в UML 2.0 появились новые виды диаграмм.
Композитная структурная диаграмма
При моделировании класса иногда полезно отобразить его внутреннюю структуру.
Это особенно важно для классов-агрегатов.
Например, человек имеет тело и интеллект. В главе 5 будет рассказано о том, как
правильно моделировать подобные утверждения. Это делается с помощью специаль-
ных обозначений и линий, связывающих классы Человек, Тело и Интеллект.
В UML 2.0 появился новый вид диаграмм — композитная структурная диаграмма
(composite structure diagram). На такой диаграмме каждый класс-компонент помещает-
ся внутрь композитного класса или класса-агрегата. Создается впечатление, что чита-
тель заглядывает внутрь класса и видит его структуру (рис. 1.13).
В версиях UML 1.x такие связи изображались на диаграммах классов, а в версии
2.0 для них появился новый вид диаграмм.
Человек
Интеллект------------- Тело
Рис. 1.13. Композитная структурная
диаграмма позволяет моделировать внут-
реннюю структуру класса
36
Часть I. Начало
Философия линий
Как станет ясно при изучении объектно-ориентированного подхода, линия, соединяющая два
класса, обычно имеет название. Как пометить линию, соединяющую на рис. 1.13 тело и
Интеллект? Философы думают над этим вопросом уже много веков. Они дискутируют не
только о названии этой ассоциации, но и о самом ее существовании, а также о существова-
нии самого интеллекта и т.д.
Обзорная диаграмма взаимодействия
Вернемся к диаграмме видов деятельности (см. рис. 1.6). На ней показана после-
довательность шагов или видов деятельности. Допустим, каждому виду деятельности
соответствует последовательность сообщений, передаваемых между объектами. Если
некоторые виды деятельности заменить диаграммами последовательностей или ком-
муникации (или комбинацией этих двух видов диаграмм), получим введенную в
UML 2.0 новую обзорную диаграмму взаимодействия.
Приведем пример. Представьте себе библиотеку.
1. Вы находите книгу в базе данных библиотеки.
2. Приносите информацию о книге в регистратуру и заказываете книгу.
3. Охранник на выходе проверяет, оформили ли вы заказ книги, которую соби-
раетесь вынести.
На рис. 1.14 показана простая диаграмма взаимодействия, отражающая описанные
три шага.
Поиск книги
Получение книги
Выход из библиотеки
Рис. 1.14. Три вида деятель-
ности, выполняемые при по-
сещении библиотеки
Теперь давайте проанализируем каждый из видов деятельности. На первом этапе
вы обращаетесь в базу данных библиотеки и запрашиваете местонахождение нужной
книги. База данных сообщает нужное местоположение. На втором шаге вы просите
библиотекаря выдать вам книгу, и он ее выдает. На третьем этапе вы покидаете биб-
лиотеку (но только после того, как охранник удостоверится, что вы нужным образом
оформили книгу).
На рис. 1.15 показано, как организована эта последовательность действий.
1-й час. Введение в UML
37
оформитьВыдачуКниги()
получитьКнигу()
:Клиент
:Охранник
।
проверитьОформлениеЗаказа()
покинутьБиблиотеку()
Рис. 1.15. Обзорная диаграмма взаимодействия, расши-
ряющая диаграмму видов деятельности, показанную на
рис. 1.14
Временная диаграмма
Вернемся к примеру со стиральной машиной. Мы будем его использовать при об-
суждении диаграмм классов, состояний, последовательностей и коммуникаций.
Когда речь шла о диаграммах последовательностей, упоминалось время пребыва-
ния объекта в каждом из состояний (замачивание — 5 минут, стирка — 15 минут, по-
лоскание — 15 минут и отжим — 5 минут).
Если внимательно посмотреть на диаграмму, показанную на рис. 1.5, то можно за-
метить, что длительность пребывания в каждом из состояний нигде явно не указана.
Эту проблему позволяет решить временная диаграмма (timing diagram), которая появи-
лась в стандарте UML 2.0. Пример такой диаграммы показан на рис. 1.16.
38
Часть I. Начало
:СтиральнаяМашина
Отжим
Полоскание
Стирка
Замачивание
О 5 10 15 20 25 30 35 40
Рис. 1.16. Временная диаграмма UML
1/1 старое, и новое — диаграмма пакетов
В версиях 1.x существует возможность организовать элементы диаграмм в группы.
Это можно сделать с помощью пакета, который представляется папкой с заклад-
кой, как на рис. 1.17. Основная идея пакета — объединить элементы в рамках общей
сущности, представляемой в виде папки с закладкой. Например, если некоторые
классы или компоненты являются частью отдельной подсистемы, их можно объеди-
нить в пакет.
Рис. 1.17. Обозначение пакета
UML
В версии 2.0 появился отдельный вид диаграмм — диаграмма пакетов. Теперь па-
кет не просто позволяет объединять элементы. Они приобрел статус диаграммы.
Зачем так много различных диаграмм?
Несложно заметить, что диаграммы UML позволяют описать систему с разных то-
чек зрения. Необязательно использовать все диаграммы в каждой модели UML.
Большинство моделей содержит набор приведенных выше диаграмм.
Зачем нужны различные представления системы? Обычно системой занимается
несколько специалистов, которых интересуют различные ее аспекты. Давайте вернем-
ся к примеру со стиральной машиной. Если вы разрабатываете двигатель стиральной
машины, у вас одно представление о системе. А если пишете инструкцию по эксплуа-
тации, то, соответственно, другое. Если вы проектируете общий вид машины, ваше
представление о системе будет кардинально отличаться от того, которое вы бы имели,
желая просто постирать белье.
Точное проектирование системы требует наличия всех возможных представлений,
а диаграммы UML позволяют объединить отдельные представления. Основная цель
состоит в удовлетворении требований каждого заинтересованного лица.
1-й час. Введение в UML
39
Может, это просто картинки?
Некоторые читатели могут не осознавать важность языка UML. В конце концов,
разве не программирование является основным этапом работы над проектом? Зачас-
тую бытует мнение, что именно разработчики выполняют “реальную” работу, а спе-
циалисты по моделированию просто рисуют картинки.
Чтобы понять важность точного визуального моделирования, рассмотрим следую-
щий пример. Предположим, требуется построить сложную развязку в большом городе,
включающую сеть мостов и подземных туннелей.
При небрежном моделировании чертежи могут содержать неточную информацию.
Допустим, на одном чертеже автор не учел строение, расположенное на месте предпо-
лагаемой развязки. На другом чертеже создатели на несколько метров ошиблись при
отображении плана подземных туннелей. Такая ошибка может выявиться только в
процессе строительства, когда рабочие не смогут правильно соединить два туннеля.
Устранение подобных “оплошностей” может обойтись в очень крупную сумму и при-
вести к срыву сроков выполнения проекта.
Звучит убедительно?
Моделирование, изучение и знание
По мнению автора, процесс обучения имеет три стадии.
1. Вам не известно, чего вы не знаете. Это означает, что вы еще не знакомы с пред-
метной областью.
2. Вам известно, чего вы не знаете. Другими словами, вы начинаете понимать взаимо-
связи в предметной области и осознаете пробелы в своих знаниях.
3. Вы устраняете эти пробелы.
Язык UML (и моделирование в целом) позволяет быстро перейти ко второй стадии — понять,
чего вы не знаете и приступить к поиску необходимой информации.
Резюме
Системы разрабатываются людьми. Поэтому использование простой системы обо-
значений в процессе разработки поможет избежать многих ошибок.
Система обозначений UML стала стандартом в области разработки систем. Это ре-
зультат работы Гради Буча (Grady Booch), Джеймса Румбаха (James Rumbaugh) и
Айвара Якобсона (Ivar Jacobson). UML содержит набор разных диаграмм и поэтому
поддерживает стандарт, позволяющий системному аналитику строить комплексный
пакет документации, которым могут пользоваться клиенты, программисты и другие
специалисты, участвующие в разработке. Все эти диаграммы нужны, так как каждая
из них адресована отдельному заинтересованному лицу системы.
Модель UML описывает, что предположительно будет делать система. Но ничего
не говорится о том, как система будет это делать.
Вопросы и ответы
Унифицированный язык моделирования называют и UML, и The UML. Как правильно?
Основатели языка предпочитают название The UML.
40
Часть I. Начало
В этой главе говорилось о том, что принципы объектно Сориентированного проектироП
вания играют важную роль для понимания данной книги. Значит ли это, что для полного
усвоения материала читатель должен владеть языком программирования Java или C++?
Нет. Объектно-ориентированный подход относится не только к программирова-
нию. Он очень полезен и для системного аналитика, который хочет понять и промо-
делировать некоторую предметную область.
Я пришел к выводу, что UML — превосходный инструмент для анализа. В то же вре
мя диаграмма развертывания кажется лишней на стадии анализа разработки системы.
Может быть, ее лучше использовать на более поздних этапах?
На самом деле никогда не рано думать о развертывании (или о других вопросах,
решение которых традиционно оставляют “на потом”). Действительно, аналитик об-
щается с клиентами и пользователями. Именно в процессе анализа он должен думать
о компьютерах и других компонентах, составляющих аппаратное обеспечение систе-
мы. Иногда это определяется клиентом. В других случаях он ожидает рекомендаций
разработчиков. Поэтому архитектору системы диаграмма развертывания будет полезна.
Вы упоминали, что возможны гибридные диаграммы. Налагает ли UML, извините,
The UML, ограничения на комбинирование элементов на диаграмме?
Нет. UML не налагает никаких ограничений. Однако, обычно диаграмма состоит
из элементов одного вида. Вы можете разместить изображение класса на диаграмме
развертывания, но вряд ли это будет полезно.
На рис. 1.3 показана диаграмма прецедентов, из которой следует лишь то, что пользой
ватель стиральной машины хочет постирать одежду. Нужно ли для этого использовать
специальные обозначения? не проще ли выразить эту мысль в обычном предложении?
Если ваша мысль заключается только в этом, конечно вы правы. Это можно ска-
зать одним предложением. Однако в типичных проектах диаграммы прецедентов
имеют гораздо более сложный вид, причем обычно они усложняются по мере выпол-
нения проекта.
Практические занятия
Вы погрузились в UML. Теперь нужно ответить на несколько вопросов и проде-
лать упражнения для проверки знаний. Ответы содержатся в приложении А.
Тесты
1. Зачем строить различные диаграммы в модели системы?
2. Какие диаграммы соответствуют статическому представлению системы?
3. Какие диаграммы обеспечивают динамическое представление системы (т.е. по-
казывают изменения во времени)?
4. Какие типы объектов показаны на рис. 1.5?
Упражнения
1. Предположим, вы создаете компьютерную систему для игры с пользователем в
шахматы. Какая диаграмма UML была бы полезна при разработке системы?
Почему?
2. Составьте список вопросов потенциальному пользователю упомянутой шах-
матной системы и объясните, почему вы хотели бы задать именно их?
1-й час. Введение в UML
41
3. Обратимся к рис. 1.7. Дополните его таким образом, чтобы он стал эквивален-
тен диаграмме последовательностей, показанной на рис. 1.5. С какими про-
блемами вы при этом столкнулись?
4. Вернемся к спискам операций для объектов, показанных на рис. 1.5. Будем
считать, что каждый объект является экземпляром некоторого класса. По-
стройте диаграмму классов, отражающую указанные классы и операции. По-
старайтесь придумать новые операции для данных классов.
5. Сделаем шаг вперед. Постарайтесь представить классы из упражнения 4 в виде
композитной структурной диаграммы стиральной машины. Можно ли доба-
вить к этой диаграмме дополнительные компоненты?
6. В разделе, посвященном диаграммам состояний, речь шла о том, что лифт
может либо двигаться, либо стоять. Постарайтесь изобразить эти состояния
лифта. Какую информацию, кроме названий состояний, должна содержать
подобная диаграмма? (Подсказка: вспомните о дверях лифта. Когда они от-
крыты, а когда закрыты?)
7. Вернемся к рис. 1.5 и 1.15, иллюстрирующим диаграмму последовательностей
и обзорную диаграмму взаимодействия, соответственно. Обратите внимание
на сообщения, передаваемые объектами друг другу. Подумайте, какая инфор-
мация может содержаться в круглых скобках, расположенных рядом с именем
каждого сообщения?
42
Часть I. Начало
2-й час
Знакомство с объектно-
ориентированным подходом
Из этого часа вы узнаете
> В чем состоят основные принципы объектно-ориентированного подхода
> Как объекты взаимодействуют друг с другом
> Как связывать объекты между собой
> Как комбинировать объекты
Объектно-ориентированный подход был воспринят разработчиками программного
обеспечения очень быстро, что вполне понятно. Как одна из технологий разработки
программ, он имеет много преимуществ. В настоящее время развивается компонент-
ный подход к разработке программного обеспечения, при котором создание любой
системы начинается с создания набора классов. Затем можно расширить эту систему
путем добавления новых свойств к уже созданным компонентам либо путем создания
новых компонентов. При таком подходе классы, созданные во время проектирования
системы, можно использовать повторно, что существенно снизит время разработки.
UML позволяет построить легкие в использовании и понимании модели объектов,
благодаря чему упрощается их программная реализация.
Объектно-ориентированный подход определяется несколькими фундаментальными
принципами, которые и будут изучены в этой главе. В следующей же части будет рас-
сказано, как для реализации этих принципов применяется язык UML.
Вездесущие объекты
Все, что окружает нас, относится к объектам. Они составляют наш мир. Как было
отмечено в предыдущей главе, современное программное обеспечение обычно моде-
лирует окружающий мир или небольшую его часть. Другими словами, программы
строятся на основе объектов. Если вы понимаете основные свойства объектов, то мо-
жете создать представляющее их программное обеспечение.
Прежде всего, объект является экземпляром класса (типа). Вы и я, например,
представляем собой экземпляры класса Человек. Объект имеет структуру, т.е. обла-
дает атрибутами (свойствами) и поведением. Поведение объекта определяется опера-
циями, которые этот объект выполняет. Атрибуты и операции вместе называются свой-
ствами.
Соглашения об именовании
Напомним некоторые соглашения, принятые разработчиками объектно-ориентированных
систем и описанные в главе 1, "Введение в UML".
• Имя класса начинается с заглавной буквы.
• Если имя класса состоит из нескольких слов, эти слова пишутся без пробелов и каждое
из них начинается с прописной буквы.
• Имя свойства (атрибута или операции) начинается со строчной буквы.
• Если имя свойства состоит из нескольких слов, эти слова пишутся без пробелов и каж-
дое из них начинается с прописной буквы, за исключением первого.
• За именем операции следует пара круглых скобок.
Как объекты класса Человек вы и я имеем такие атрибуты: рост, вес и возраст.
(Можно придумать еще какие-нибудь.) Мы также выполняем операции: едим, спим,
читаем, пишем, говорим, ходим на работу и т.д. (На языке объектного подхода, мы
выполняем операции есть (), спать (), читать (), писать (), говорить () и идтиНа-
РаботуО) Если бы требовалось создать систему, связанную с информацией о людях,
например систему начисления зарплаты или систему для отдела социального обеспе-
чения, пришлось бы отразить некоторые из этих атрибутов и операций в программ-
ном обеспечении.
В области объектно-ориентированных систем, помимо категоризации, классы
обеспечивают выполнение других задач. Класс представляет собой шаблон для созда-
ния объектов. Его можно представить как формочку, предназначенную для “штам-
повки” новых объектов. (Кто-то может возразить, что это та же категоризация, но,
думается, не стоит вступать в дискуссию по этому поводу.)
Вернемся к примеру со стиральной машиной. Если класс стиральных машин имеет
атрибуты: компанияПроизводитель, названиеМодели, серийныйНомер и емкость, а
также выполняет операции загрузитьБелье(), загрузитьСтиральныйПорошок(),
включить () и выключить () — налицо механизм для создания новых экземпляров
класса СтиральнаяМашина. Другими словами, на базе этого класса можно создавать
новые объекты (рис. 2.1).
Это очень важно для создания объектно-ориентированного программного обеспе-
чения. Хотя в этой книге вопросы программирования не рассматриваются, знание
того, что программные классы могут использоваться для создания новых экземпляров,
очень важно для понимания концепции объектно-ориентированного подхода.
44
Часть I. Начало
загрузитьБелье()
загрузитьСтиральныйПорошок()
включить()
выключить
Рис. 2.1. Класс стиральной машины — исходная модель стиральной маши-
ны, которая служит шаблоном для создания новых экземпляров стираль-
ных машин
Отметим еще один момент. Запомните, что цель объектно-ориентированного под-
хода состоит в создании программного обеспечения, которое отражает (т.е.
“моделирует”) отдельную часть окружающего нас мира. Чем больше атрибутов и опе-
раций принимается во внимание, тем ближе полученная модель к реальности. В при-
мере со стиральной машиной для получения более точной модели можно использо-
вать дополнительные атрибуты, такие как объемБарабана, типФильтра, типДвигателя,
скоростьДвигателя. Можно еще повысить точность модели, добавив операции до-
бавитьОтбеливатель () и установитьУровеньВоды() (рис. 2.2).
компанияПроизводитель
названиеМодели
с ерийныйН омер
емкость
объемБарабана
типФильтра
типДвигателя
скоростьДвигателя
Операции
загрузитьБелье()
загрузитьСтиральныйПорошок()
включить()
выключить()
добавитьОтбеливатель()
установитьУровеньВоды()
Рис. 2.2. Увеличение числа атрибутов и операций в модели позволяет точнее
отражать окружающий мир
2-й час. Знакомство с объектно-ориентированным подходом
45
Общие понятия
Объектно-ориентированный подход не сводится только к моделированию атрибу-
тов и поведения. Он предполагает также наличие других свойств объектов. Эти свой-
ства носят название абстракция, наследование, полиморфизм и инкапсуляция. Еще три
составляющие объектно-ориентированного подхода называются передача сообщений,
ассоциации и агрегация. Рассмотрим каждое из этих понятий.
Абстракция
Абстракция означает выделение важных и нужных свойств и операций объекта.
Что же значит выражение “важных и нужных”?
Каждая из решаемых проблем требует определенного количества информации.
При второй попытке построения класса стиральной машины было задействовано
больше атрибутов и операций, чем в первой. Нужно ли это?
Если группа разработчиков должна создать программу, точно моделирующую по-
ведение стиральной машины, то такое количество атрибутов и операций необходимо.
Подобная программа может быть полезна для проектировщиков стиральных машин и
позволит им прогнозировать поведение готового изделия во время стирки. Для такой
программы можно отбросить только атрибут номера изделия, потому что он вряд ли
будет востребован при работе.
С другой стороны, если вы собираетесь создать программу для мониторинга за-
грузки прачечной, оснащенной несколькими стиральными машинами, то использова-
ние большого количества атрибутов и операций неоправданно. В то же время вам по-
надобится такой атрибут, как номер изделия для каждого экземпляра стиральной ма-
шины.
В любом случае, после принятия решения о включении или исключении парамет-
ров объекта, вы все равно будете использовать абстракцию стиральной машины.
Важнейший навык
Некоторые авторитетные специалисты в области объектно-ориентированного подхода ут-
верждают, что умение правильно определить уровень абстракции (выделить существенные
признаки и отбросить несущественные) — важнейший навык специалиста по моделированию.
Наследование
Стиральные машины, холодильники, микроволновые печи, тостеры, посудомоеч-
ные машины, радиоприемники, вафельницы, миксеры относятся к классу бытовой
техники, т.е. являются его подклассами. Другими словами, класс БытоваяТехника яв-
ляется суперклассом для перечисленных выше классов.
Бытовая техника имеет атрибуты: выключатель, электропровод и операции
включить (), выключить (). Каждый класс бытовой техники содержит эти свойства.
Поэтому, если некий объект относится к одному из типов бытовой техники, то он
имеет общие для бытовой техники свойства и операции.
На языке объектно-ориентированного подхода такая взаимосвязь между классами
называется наследованием (inheritance). Каждый подкласс класса БытоваяТехника
(а именно, классы СтиральнаяМашина, Холодильник, Миксер) наследует его свойства.
Важно понимать, что в каждом подклассе добавляются новые атрибуты и операции.
Взаимосвязь суперкласса с подклассами иллюстрирует рис. 2.3.
46
Часть I. Начало
БытовыеУстройства
Рис. 2.3. Бытовые приборы наследуют атрибуты и опера-
ции класса бытовой техники. Каждый бытовой прибор яв-
ляется подклассом класса бытовой техники. Класс быто-
вой техники является суперклассом каждого подкласса
Наследование не ограничивается приведенным примером. Бытовая техника, на-
пример, является подклассом класса домашнего оборудования. Мебель — это другой
подкласс указанного класса (рис. 2.4). Мебель, естественно, имеет собственные под-
классы.
Рис. 2.4. Суперклассы, в свою очередь, могут быть
подклассами и наследовать свойства других су-
перклассов
Полиморфизм
Иногда операция имеет одно и то же название в разных классах. Например, можно
открыть дверь, окно, газету, подарок, банковский счет, переговоры. В каждом случае
выполняется новая операция, но каждый класс “знает”, как выполняется операция
“открыть”. Это и есть полиморфизм (рис. 2.5).
2-й час. Знакомство с объектно-ориентированным подходом
47
Рис, 2.5. Полиморфизм означает применение в не-
скольких классах операций с одинаковым названием,
но различным содержанием
На первый взгляд кажется, что эта концепция более важна для разработчиков
программного обеспечения, чем для моделирования системы. Действительно, про-
граммисты должны создать программу, которая реализует модели, поэтому необходи-
мо учитывать важные отличия между разными одноименными операциями. Для этого
нужно разработать классы, которые “знают”, как выполнять операции в каждом случае.
Нужно сказать, что полиморфизм важен и при моделировании. Он позволяет раз-
работчику общаться с клиентом, хорошо знающим моделируемую часть окружающего
мира, на его языке. Иногда терминология предметной области естественным образом
приводит к появлению одноименных операций (например, “открыть”), имеющих не-
сколько значений. Полиморфизм позволяет поддерживать такую терминологию, из-
бегая искусственных слов для разделения терминов по смыслу.
Инкапсуляция
Несколько лет назад в программе коммерческого телевидения обсуждался вопрос
экономии денег при использовании семизначного префикса перед набором номера
при междугородных звонках.
Один из участников передачи спросил: “За счет чего это происходит?”.
Другой ответил: “А за счет чего лопается поп-корн? Кто знает?”.
В этом сущность инкапсуляции', при выполнении операций объектом сами эти опе-
рации скрыты (рис. 2.6). Когда люди смотрят телевизор, большинство из них не име-
ют никакого представления о сложной электронной начинке, размещенной за экра-
ном, и о многих операциях, происходящих при выводе телевизионного изображения.
Телевизор просто работает, а процессы внутри него скрыты от нас. Почти вся бытовая
техника работает подобным образом. (Большое спасибо!)
Почему это важно? Инкапсуляция помогает снизить потенциал воздействия нега-
тивных событий. В системе, состоящей из объектов, все они связаны друг с другом
различным образом. Если один из них начинает работать неправильно и программи-
стам приходится изменять его, скрытость операций от других объектов позволяет не
затрагивать связанные с ним объекты.
Возвращаясь в реальный мир, можно оценить важность инкапсуляции в окружаю-
щих объектах. Монитор скрывает свои операции от процессора системного блока. Ес-
ли монитор поломается, его можно либо починить, либо заменить. При этом не нуж-
но заменять или чинить процессор.
Пока мы не перешли к следующему вопросу, рассмотрим еще одно понятие. По-
ведение объекта скрыто от других объектов и от окружающего мира. (С этой точки
зрения инкапсуляцию называют сокрытием информации.) Но объект должен предста-
вить системе свое “лицо”, чтобы можно было инициировать его операции. У телеви-
зора, например, имеется набор кнопок, размещенных либо на самом аппарате, либо
48
Часть I. Начало
на пульте. Стиральная машина оснащена набором регуляторов для установки темпе-
ратуры и уровня воды. Телевизионные кнопки и регуляторы стиральной машины
имеют общее название интерфейс.
Операции
телевизора
скрыты
от зрителя
Рис. 2.6. Объекты инкапсулируют выполняемые
ими операции, т.е. они скрывают выполнение
внутренних операций от внешнего мира и от
других объектов
Передача сообщений
Считается, что объекты в системе работают совместно и при этом обмениваются
сообщениями. Один объект посылает сообщение о необходимости выполнить какую-
либо операцию другому, а принявший это сообщение объект выполняет нужную опе-
рацию.
Телевизор и пульт дистанционного управления представляют собой прекрасный
интуитивный пример из окружающего мира. Если человек хочет посмотреть телеви-
зор, ему необходимо вначале отыскать пульт, расположиться в любимом кресле и на-
жать кнопку включения. Что при этом происходит? Объект пульта дистанционного
управления отправляет сообщение о включении (буквально!) объекту телевизора. Объ-
ект телевизора принимает это сообщение и, “зная”, как выполнить операцию вклю-
чения, включается. Чтобы посмотреть другой канал, нужно нажать соответствующую
кнопку на пульте. При этом объект пульта дистанционного управления передает дру-
гое сообщение — сменить канал — объекту телевизора. Пульт дистанционного управ-
ления может также обмениваться с телевизором другими сообщениями, предназна-
ченными для изменения громкости, отключения звука или настройки изображения.
Давайте ненадолго вернемся к интерфейсам. Большинство действий, выполняемых
с помощью пульта дистанционного управления, можно также осуществить по-
другому: покинуть кресло, подойти к телевизору и понажимать кнопки на самом ап-
парате. (Иногда это необходимо проделывать!) Интерфейс телевизора (набор кнопок),
очевидно, не такой же, как у пульта (инфракрасный приемник). На рис. 2.7 показаны
указанные отличия.
2-й час. Знакомство с объектно-ориентированным подходом
49
Снова к первому уроку...
На самом деле мы уже знакомы с процессом передачи сообщений. На диаграмме последо-
вательностей из главы 1 (см. рис. 1.5) стрелки представляют собой сообщения, передавае-
мые от одного объекта к другому.
Рис, 2.7. Пример передачи сообщения от одного объекта дру-
гому. Объект пульта дистанционного управления передает
сообщение о включении объекту телевизора. Объект телеви-
зора принимает сообщение через свой интерфейс — инфра-
красный приемник
Ассоциации
В дополнение к сказанному можно отметить, что объекты обычно связаны между
собой некоторым образом. Например, согласно терминологии объектно-ориентиро-
ванного подхода, при включении телевизора человек находится в отношении ассоциа-
ции со своим телевизором.
Ассоциация “включить” однонаправленная, как показано на рис. 2.8. Человек
включает телевизор. Конечно, можно смотреть несколько телевизоров одновременно,
но это уже нетипичный пример. Существуют двунаправленные ассоциации, например
“быть женатым/замужем”.
Иногда объект должен ассоциироваться с другими объектами несколькими спосо-
бами. Например, вы и ваш сменщик — друзья. При этом вы находитесь в ассоциаци-
ях “быть другом” и “быть напарником”, как показано на рис. 2.9.
Класс может быть ассоциирован с несколькими другими классами. Человек может
ехать в легковой машине или в автобусе (рис. 2.10).
Важным аспектом ассоциаций применительно к объектам является кратность.
Она означает количество объектов одного класса, связанных с объектом ассоцииро-
ванного класса. Например, обычно каждый курс колледжа имеет своего куратора.
Курс и куратор находятся в ассоциации “один к одному”. Однако после начала спе-
циализации в течение семестра курс ведут несколько инструкторов. Этот случай ассо-
циации курс—инструктор трактуется как “один ко многим”.
50
Часть I. Начало
Рис. 2.8. Объекты часто ассоциированы друг
с другом некоторым образом. При включении
телевизора человек вступает с ним в одно-
направленную ассоциацию
Рис. 2.9. Объекты часто ассоциированы
друг с другом несколькими способами
Рис. 2.10. Класс может ассоциироваться с несколькими други-
ми классами
В жизни встречаются разные типы кратности. Велосипед ездит на двух колесах
(кратность “один к двум”), трехколесный велосипед ездит на трех колесах, а восемна-
дцатиколесная машина — на восемнадцати.
2-й час. Знакомство с объектно-ориентированным подходом
51
Агрегация
Вернемся к компьютерной системе. Она состоит из системного блока, клавиатуры,
мыши, монитора, устройства проигрывания компакт-дисков, одного или более жест-
ких дисков, модема, дисковода для гибких дисков размером 3,5 дюйма, принтера и,
возможно, колонок. Внутри системного блока наряду с перечисленными выше уст-
ройствами есть процессор, графическая карта, звуковая карта и другие элементы, ко-
торые можно обнаружить при более тщательном осмотре.
Компьютер представляет собой агрегат, получаемый при другом типе ассоциации
между объектами. Подобно другим объектам, компьютер состоит из различных ком-
понентов (рис. 2.11). В жизни существует много примеров агрегации.
Рис. 2.11. Пример агрегации: типичная компьютерная сис-
тема, созданная из комбинации нескольких объектов разных
типов
Один из типов агрегации предполагает тесную связь между объектом-агрегатом и
составляющими его компонентами. Это называется композицией. Главной особенно-
стью композиции является то, что компонент существует в виде такового только в
рамках композитного объекта. Например, рубашка — это композиция основной час-
ти, воротника, рукавов, пуговиц, петель и манжет. Порвите рубашку, и рукава станут
бесполезными.
Иногда компоненты существуют не так долго, как содержащий их композитный
объект. Листья на дереве погибают раньше всего дерева. Если сломать дерево, погиб-
нут и листья (рис. 2.12).
Агрегация и композиция очень важны, потому что отражают наиболее общие от-
ношения и помогают создавать модели, точно воспроизводящие реальность.
52
Часть I. Начало
Рис. 2.12. Компонент иногда погиба-
ет раньше содержащей его компози-
ции. Но если разрушить компози-
цию, то разрушается и компонент
Обратная связь
Объекты и их ассоциации составляют основу функционирования систем. Для мо-
делирования этих систем нужно понимать, что собой представляют ассоциации. Имея
представление о возможных типах ассоциаций, разработчик будет хорошо подготовлен
к разговору с клиентами об их нуждах, формулированию требований и созданию мо-
делей систем, которые смогут решить существующие проблемы.
Понятие объектно-ориентированного подхода помогает освоить предметную об-
ласть клиента (его домен) и ознакомиться с проблемами клиента на понятном ему
языке.
Вот тут-то и выходит на сцену UML. В следующих трех главах вы узнаете, как
применить UML для визуализации понятий, изученных в этой главе.
Это интересно
Объектно-ориентированный подход точно соответствует человеческой природе. Мы стара-
емся классифицировать окружающие нас объекты, поскольку легче работать с несколькими
категориями, чем с со множеством отдельных экземпляров.
Объектная категоризация применяется в современных исследованиях мозга. Психологи
Изабель Готье (Isabel Gauthier) и Мишель Тарр (Michael Tarr) специально разработали набор
объектов для исследования процессов, происходящих в мозге человека. Они обнаружили,
что в процессе категоризации объектов особенно активной является специальная область
церебральной коры.
2-й час. Знакомство с объектно-ориентированным подходом
53
Резюме
Объектно-ориентированный подход определяется несколькими фундаментальными
принципами. Объект представляет собой экземпляр класса. Класс — это общая кате-
гория объектов, которая обладает атрибутами и операциями. При создании объекта
количество принимаемых во внимание атрибутов и операций определяется предмет-
ной областью задачи.
Наследование — важный аспект объектно-ориентированного подхода. Объект на-
следует атрибуты и операции своего класса. Класс может также наследовать атрибуты
и операции другого класса.
Другой важный аспект — полиморфизм. Он означает наличие операций, имеющих
одинаковое имя в различных классах, но выполняемых в каждом классе по-своему.
Объект скрывает выполнение своих операций от других объектов и от окружаю-
щего мира. Каждый объект предоставляет интерфейс, так что другие объекты (и люди)
могут воспринимать его и выполнять его операции.
Объекты функционируют совместно путем передачи сообщений друг другу. Сооб-
щения — это требования на выполнение операций.
Обычно объекты связаны друг с другом. Ассоциация может иметь различные фор-
мы. Объект в одном классе может ассоциироваться с любым количеством объектов
другого класса.
Агрегация — тип ассоциации. Агрегатный объект состоит из набора компонентов.
Композиция является особым видом агрегации. В композитном объекте компоненты
существуют только как часть композиции.
Вопросы и ответы
Вы говорили, что объектно Сориентированный подход быстро распространился в обл ас □
ти программного обеспечения. Существуют ли важные приложения, не относящиеся к
объектное]ориентированному подходу?
Да. Это созданные ранее системы. Объектно-ориентированный подход дает мно-
жество преимуществ, таких как повторное использование и быстрота разработки. По-
этому новые приложения (и обновленные версии многих существующих систем), раз-
рабатываются с использованием объектно-ориентированного подхода.
Когда начал развиваться объектно Сориентированный подход?
Принципы объектно-ориентированного программирования появились в середине
60-х годов прошлого столетия в Норвегии, когда Оле-Джон Дал (Ole-Johan Dahl) и
Кристен Нигард (Kristen Nygaard) разработали язык программирования SIMULA 1 для
моделирования сложных систем. Хотя этот язык никогда широко не использовался, в
нем впервые появились классы, объекты, наследование и другие важные понятия объ-
ектно-ориентированного подхода.
Практические занятия
Чтобы проверить, как вы усвоили основные понятия объектно-ориентированного
подхода, попробуйте ответить на предлагаемые вопросы. Ответы содержатся в прило-
жении А. Эта глава была посвящена теоретическим вопросам, поэтому в ней не пред-
лагаются практические упражнения. Но они появятся в следующих главах!
54
Часть I. Начало
Тесты
1. Что такое объект?
2. Как объекты взаимодействуют друг с другом?
3. На что указывает кратность?
4. Могут ли два объекта быть связаны друг с другом несколькими способами?
5. Что такое наследование?
6. Что такое инкапсуляция?
2-й час. Знакомство с объектно-ориентированным подходом
55
3-й час
Использование концепций объектно-
ориентированного проектирования
Из этого часа вы узнаете
> Как выглядит модель класса
> Как изобразить свойства, обязанности и ограничения классов
> Как выявить классы
Пришло время объединить рассмотренные в предыдущих главах вопросы и UML
для реализации объектно-ориентированного подхода. В этой главе вы расширите свои
знания в области объектно-ориентированного подхода и узнаете еще больше о UML.
Визуализация класса
Как упоминалось в главе 1, прямоугольник — это условное обозначение класса в
UML. Из предыдущих глав вам уже известно, что именем класса обычно является
слово, начинающееся с прописной буквы. Оно располагается в верхней части прямо-
угольника. Если имя класса состоит из двух слов, объедините их, и второе слово тоже
напишите с прописной буквы (например, СтиральнаяМашина на рис. 3.1).
Роль имени класса может играть другая конструкция UML — пакет. В главе 1,
“Введение в UML”, мы выяснили, что пакет — это принятый в UML способ органи-
зации элементов диаграммы. Как вы помните, пакет представляется в UML в виде
папки с корешком, на которой указано имя пакета в виде строки текста (рис. 3.2).
Если класс СтиральнаяМашина является частью пакета Бытовая техника, то это-
му объекту МОЖНО дать ИМЯ Бытовая техника: : СтиральнаяМашина. Двойное двоето-
чие отделяет имя пакета слева от имени класса справа. Такой вид имени класса назы-
вается полным именем (рис. 3.3).
СтиральнаяМашина
Бытовая техника
Рис. 3.1. Обозначение Рис. 3.2. Пакет UML
класса в UML
Бытовая техника::СтиральнаяМашина
Рис. 3.3. Класс с полным именем
Атрибуты
Атрибут — это свойство класса. Атрибуты описывают перечень значений, в рамках
которых указываются свойства объектов (т.е. экземпляров) этого класса. Класс может
не иметь атрибутов или содержать любое их количество. Имена атрибутов, состоящие
из одного слова, принято обозначать строчными буквами. Если имя состоит из не-
скольких слов, то они объединяются, и каждое слово, за исключением первого, начи-
нается с прописной буквы. Список имен атрибутов начинается ниже линии, отде-
ляющей их от имени класса (рис. 3.4).
Атрибуты каждого объекта класса принимают конкретные значения. На рис. 3.5
показан соответствующий пример. Обратите внимание, что имя объекта начинается
со строчной буквы. После имени объекта следует точка с запятой, а за ней — имя
класса. При этом имя объекта и класса подчеркнуты.
WashingMachine
brandName
modelName
serialNumber
capacity
Рис. 3.4. Класс и его
атрибуты
3-й час. Использование концепций объектно-ориентированного проектирования
57
Именованные и безымянные объекты
Имя myWasher:WashingMashine является именованным экземпляром. Возможно су-
ществование И анонимного экземпляра, например : WashingMashine.1
UML позволяет отображать дополнительную информацию об атрибутах. В изобра-
жении класса можно указать тип для каждого значения атрибута. Перечень возмож-
ных типов включает строку, число с плавающей точкой, целое число, логическое зна-
чение и другие перечислимые типы. Для отображения типа используется двоеточие,
которое отделяет имя атрибута от его типа. Здесь же можно указать значение атрибута
по умолчанию. На рис. 3.6 показан этот способ задания атрибутов.
myWasher: WashingMachine
brandName = "Laundatorium"
modelName = "Washmeister"
serialNumber = "GL57774"
capacity = 16
Puc. 3.5. Объект имеет задан-
ное значение для каждого из
атрибутов класса
WashingMachine
brandName: String = "Laundatorium”
modelName: String
serialNumber: String
capacity: Integer
Рис. 3.6. Наряду с именем атрибута
можно указывать его тип и значение
по умолчанию
Именованные значения
Перечислимый тип представляет собой информацию, заданную списком именованных зна-
чений. Логический тип также является перечислимым, потому что он состоит из значений
“истина” и “ложь”. Можно определить собственные перечислимые типы (например, Со-
стояние, образованный из значений “твердое”, “жидкое” и “газообразное").
Операции
Операция — это то, что может выполнять класс, либо то, что вы (или другой класс)
можете выполнять над данным классом. Подобно имени атрибута, имя операции за-
писывается строчными буквами, если это одно слово. Если имя состоит из нескольких
слов, они соединяются, и все слова, кроме первого, пишутся с прописной буквы.
Список операций начинается ниже линии, отделяющей операции от атрибутов
(рис. 3.7).
Помимо дополнительной информации об атрибутах, можно отобразить дополни-
тельную информацию об операциях. В скобках, следующих за именем операции,
можно указать параметр операции и его тип. Один из типов операций, функция, по
окончании работы возвращает значение. В этом случае можно указать возвращаемое
значение и его тип.
1 При построении диаграмм UML имена объектов и других элементов можно указывать как
на русском, так и на английском языке. В этой книге для ясности объекты именуются по-
русски. Однако если на диаграмме отображаются программные классы, то их принято имено-
вать по-английски, в соответствии с требованиями языков программирования. — Прим. ред.
58
Часть I. Начало
Перечисленные фрагменты информации об операции носят название сигнатуры
операции. На рис. 3.8 представлена операция и ее сигнатура. Для первых двух опера-
ций указан тип параметра, а для двух последующих — тип возвращаемого значения.
WashingMachine
brandName
modelName
serialNumber
capacity
acceptClothes()
acceptDetergent()
turnOn()
turnOff()
WashingMachine
brandName
modelName
serialNumber
capacity
acceptClothes(c:String)
acceptDetergent(d:Integer)
turnOn():Boolean
turnOff():Boolean
Рис. 3.7. Список опе-
раций класса распо-
лагается ниже линии,
отделяющей его от
списка атрибутов
Рис. 3.8. Сигнатура операции
Визуализация атрибутов и операций
До сих пор мы имели дело с отдельно взятым классом и показывали все его атри-
буты и операции. На практике приходится работать с несколькими классами одно-
временно. В этом случае бесполезно отображать все атрибуты и операции, поскольку
это усложняет восприятие диаграммы. Можно просто указать имя класса и оставить
поле операций или атрибутов пустым (или оба поля — рис. 3.9).
Иногда перечисляют лишь некоторые атрибуты или операции. Чтобы указать на
частичное отображение, список сопровождается многоточием (...) (рис. 3.10).
классов не всегда указы-
вают все атрибуты и
операции
WashingMachine
brandName
acceptClothes()
Рис. 3.10. Непол-
ный набор атри-
бутов и операций
класса
Если имеющийся список атрибутов и операций слишком велик, можно уточнить
информацию с помощью ключевого слова. Как упоминалось в главе 1, ключевое сло-
во, заключенное в две пары угловых скобок, называется стереотипом. Стереотип —
это механизм расширения UML, позволяющий создавать новые элементы с учетом
особенностей решаемой задачи. В списке атрибутов ключевое слово можно использо-
вать в качестве заголовка определенного подмножества атрибутов (рис. 3.11).
3-й час. Использование концепций объектно-ориентированного проектирования
59
WashingMachine
«идентификационные данные>>
brandName
modelName
serialNumber
«данные о машине>>
capacity
«для белья»
acceptClothes()
acceptDetergent()
«для машины»
turnOn()
turnOff()
Рис, 3.11. Стереотип можно
использовать для организации
списка атрибутов или операций
Обязанности и ограничения
На изображении класса можно указать и другую информацию о нем. В области,
расположенной ниже списка операций, можно привести обязанности класса. Обязан-
ность — это описание выполняемой классом функции, для которой и предназначены
его атрибуты и операции. Стиральная машина должна принять на входе грязное белье
и выдать чистое на выходе.
На изображении класса его обязанности перечисляются ниже области операций
(рис. 3.12).
WashingMachine
brandName
modelName
serialNumber
capacity
acceptClothes()
acceptDetergent()
turnOn()
turnOff()
Взять грязное белье
на входе и выдать
чистое белье на
выходе
Рис. 3.12. На изображении класса
его обязанности размещаются
ниже списка операций
Главное — как можно более точно описать класс, поэтому включение обязанно-
стей является неформальным способом исключить двусмысленность описания.
Более формальным путем решения задачи является добавление ограничений в виде
произвольного текста, заключенного в фигурные скобки. Этот текст задает одно или
60
Часть I. Начало
несколько правил класса, к которому он относится. Предположим, для класса
WashingMachine нужно указать, что емкость барабана может составлять только 16, 18
или 20 фунтов (и таким образом “ограничить” атрибут емкости). Тогда рядом с изо-
бражением класса нужно написать {capacity = 16 или 18 или 20 фунтов}. На
рис. 3.13 показано, как это сделать.
WashingMachine
brandName
modelName
serialNumber
capacity
acceptClothes()
acceptDetergent()
turnOn()
turnOff()
{capacity = 16 или 18, или 20 фунтов}
Рис. 3.13. Правило в фигурных скобках ограничивает ат-
рибут емкости тремя допустимыми значениями
Еще об ограничениях
В UML также используется более формальный способ добавления ограничений, позволяю-
щий уточнить определения, — специальный язык OCL (Object Constraint Language). Это
сложный, но полезный инструмент, имеющий собственный набор правил, терминов и опера-
ций. Документацию по языку OCL можно найти на Web-узле группы Object Management
Group ПО адресу www. omg. org.
Комментарии
Помимо атрибутов, операций, обязанностей и ограничений, дополнительную ин-
формацию о классе можно представить в виде комментариев, присоединенных к
классу.
Комментарии обычно связаны с атрибутами и операциями. На рис. 3.14 приведен
комментарий, ссылающийся на правительственный стандарт по формированию номе-
ров изделий для объектов класса WashingMachine.
Комментарий наряду с текстом может содержать также и графические объекты.
WashingMachine
brandName
modelName
serialNumber
capacity
acceptClothes()
acceptDetergent()
turnOn()
turnOff()
В соответствии
с правительственным
• Стандартом EV-2241
о присвоении серийных
номеров
Рис. 3.14. Комментарии служат для предоставления
дополнительной информации о классе
3-м час. Использование концепций объектно-ориентированного проектирования
61
Для чего предназначены классы
и как их выявлять
Классы — это слова и термины из предметной области задачи. При общении с
клиентом разработчик, анализируя предметную область заказчика, строит компьютер-
ные системы для решения задач в этой области. При этом программист изучает тер-
минологию и формирует классы UML.
Во время переговоров с клиентом старайтесь запомнить существительные, кото-
рыми он описывает свою деятельность, — они могут стать именами классов в вашей
модели. Обратите внимание также на глаголы, употребляемые клиентом для описания
действий, потому что они должны использоваться для обозначения операций классов.
Характеристики объектов предметной области представляют собой не что иное, как
атрибуты классов. После составления основного списка классов, выясните у клиента
роль каждого из них в его деятельности. Полученные ответы укажут на обязанности
классов модели.
Предположим, аналитику требуется построить модель игры в баскетбол. Он берет
интервью у тренера, чтобы понять, как происходит игра. Беседа может происходить
следующим образом.
Аналитик: “Тренер, что такое баскетбол?”.
Тренер: “Цель игры — забросить мяч в корзину и получить больше очков, чем про-
тивник. Каждая команда состоит из пяти игроков: двух защитников, двух нападающих
и центрового. В процессе игры баскетболист стремится перенести мяч в зону сопер-
ника и забросить его в корзину”.
Аналитик: “Как передается мяч?”.
Тренер: “Его ведет и передает игрок. Команда должна забросить мяч до истечения
времени атаки команды”.
Аналитик: “Времени атаки команды?”.
Тренер: “Да. Это — 24 секунды в профессиональных играх, 30 секунд — в между-
народных и 35 секунд — в любительских. После получения мяча в течение этого вре-
мени нужно сделать бросок”.
Аналитик: “Как ведется счет?”.
Тренер: “За каждое попадание в корзину команда получает два очка, если только
бросок не происходил из-за пределов трехочковой линии. В последнем случае добав-
ляется три очка. Свободный бросок оценивается в одно очко. Свободный бросок,
кстати, является наказанием для команды, нарушившей правила. Если игрок непра-
вильно сыграл против соперника, игра останавливается, и противник получает право
на бросок с линии свободного броска”.
Аналитик: “Расскажите еще о роли каждого игрока”.
Тренер: “Защитник преимущественно ведет мяч и передает его. Такие игроки часто
меньше ростом, чем нападающие, которые, в свою очередь, ниже центрового. Пред-
полагается, что все игроки в состоянии вести мяч, передавать его, выполнять броски
и отбор мяча. Нападающие, в основном, выполняют отбор и промежуточную передачу
мяча, в то время как центральный игрок располагается возле корзины и делает броски
с небольшого расстояния”.
Аналитик: “Каковы размеры площадки и сколько продолжается игра?”.
Тренер: Для международных игр длина площадки составляет 28 метров, а шири-
на — 15. Корзина располагается в десяти футах от земли. В профессиональном бас-
кетболе игра проходит в течение сорока восьми минут, разделенных на четыре двена-
дцатиминутных тайма. В любительских и международных играх матч длится 40 минут,
разделенных на два тайма по 20 минут. Часы показывают оставшееся время”.
62
Часть I. Начало
Этот разговор может продолжаться бесконечно, но давайте остановимся и разбе-
ремся, что нового можно из него узнать. Вот существительные, которых мы раньше
не знали: мяч, корзина, команда, игроки, защитники, нападающие, центровой, бро-
сок, время атаки команды, трехочковая линия, свободный бросок, линия свободного
броска, площадка, время игры.
А вот глаголы: бросать, вести мяч, нарушать правила, передавать и отбирать мяч.
Имеется также дополнительная информация о росте игроков, выполняющих на поле
разные задачи, размере площадки, времени, отведенном для броска в корзину, и об-
щем времени игры.
Наконец, при описании игры можно отразить собственные знания и рассуждения,
пользуясь имеющимися знаниями и здравым смыслом. Например, если вы знаете, что
мяч имеет такие атрибуты, как масса и диаметр, то можете добавить их самостоятельно.
Используя собранную информацию, можно построить диаграмму, показанную на
рис. 3.15, где отображены классы, некоторые атрибуты, операции и ограничения. На
диаграмме также указаны обязанности. Эту диаграмму можно использовать в качестве
основы для последующих переговоров с тренером и получения недостающей инфор-
мации.
Мяч Игрок
диаметр масса имя рост вес
вестиМяч() передаватьМяч() бросатьМяч() отбиратьМяч() обыгратьПротивника()
Нападающий Центровой
выполняет промежуточные броски и отбор мяча находится возле корзины, бросает с близкого расстояния
ВремяАтаки {проф=24 сек любит=30 сек междунар=35 сек}
{проф=4 12-минутных тайма любит и междунар=2 20-минутных тайма)
ВремяИгры
ВремяМатча {проф=48 минут любит и междунар=40 минут}
ЛинияСвободногоБроска
Защитник Команда
ведет мяч и делает передачи Корзина
Бросок НарушениеПравил
ТрехОчковаяЛиния
СвободныйБросок
Площадка
Рис. 3.15. Исходная диаграмма классов для моделирования игры в баскетбол
3-й час. Использование концепций объектно-ориентированного проектирования
63
Резюме
Для представления класса в UML используется прямоугольник. Имя, атрибуты,
операции и обязанности класса помещаются в разных частях прямоугольника. Для
организации списка атрибутов и операций используют стереотип. Можно отображать
только часть набора атрибутов и операций класса. Это позволяет разгрузить диаграм-
му и сделать ее более удобной для восприятия.
Можно указать тип атрибута и его начальное значение, выполняемые операции и
их тип. Такая дополнительная информация для операций называется сигнатурой.
Для уменьшения неоднозначности описания класса можно использовать ограни-
чения. UML также допускает размещение дополнительной информации о классе в
связанных с прямоугольником комментариях.
Классы представляют собой термины из предметной области. Общение с клиентом
или экспертом в данной области позволяет выявить существительные, которые объе-
диняют имена классов в модели, и глаголы, которые будут обозначать операции.
Диаграмму классов можно использовать для получения от клиента дополнительной
информации о его предметной области.
Вопросы и ответы
При построении диаграммы классов для игры в баскетбол вы порекомендовали рассуП
ждать, опираясь на здравый смысл. Это очень хорошо, но что делать, если нужно анализиС
ровать совершенно незнакомую область, когда нельзя воспользоваться здравым смыслом?
Обычно аналитик имеет дело с новой для себя областью. Перед встречей с клиен-
том или экспертом попытайтесь стать “субэкспертом”. Подготовьтесь к встрече, по
возможности ознакомьтесь с документацией. Узнайте у своего интервьюируемого о
существующей литературе или руководствах. Прочитав эту литературу, вы получите
начальные знания и сможете задавать вопросы для получения информации.
Когда возникает потребность в сигнатуре?
Обычно это происходит после окончания фазы анализа в начале этапа проектиро-
вания. Сигнатура — это полезная для программиста часть информации.
В течение длительного времени я работаю в одной и той же компании и хорошо знаю
все бизнес [ процессы. Стоит ли мне создать модель классов для предметной области, соП
ответствующей сфере работы моей компании?
Это хорошая идея. При построении модели вы увидите, чего на самом деле не
знаете.
Практические занятия
Чтобы проверить полученные знания, попытайтесь ответить на следующие вопро-
сы. Ответы приведены в приложении А.
Тесты
1. Как изображается класс в UML?
2. Какую информацию можно разместить на изображении класса?
3. Что такое ограничение?
4. Зачем для класса используется комментарий?
64
Часть I. Начало
Упражнения
1. Вот короткое (и неполное) описание игры в хоккей.
Хоккейная команда состоит из центрового, вратаря, двух крайних нападающих
и двух защитников. Каждый игрок имеет клюшку, которую он использует для
ведения шайбы по льду. С помощью клюшки нужно забросить шайбу в воро-
та. В хоккей играют на катке с максимальными размерами 100 футов в шири-
ну и 200 футов в длину. Задачей центрального игрока является передача шай-
бы крайним нападающим, которые обычно лучше всех выполняют броски.
Защитник старается остановить игроков противника и не дать им занять по-
зицию для броска. Вратарь — это последняя линия защиты; он задерживает
шайбу после бросков противника. Каждый раз, когда он останавливает шайбу
и не дает ей попасть в ворота, ему засчитывается один балл. Каждый гол при-
носит команде одно очко. Игра длится 60 минут, разделенных на три периода
по 20 минут каждый.
Используйте эту информацию для построения диаграммы, аналогичной при-
веденной на рис. 3.15. Если вы знаете о хоккее больше, чем заложено в этом
описании, отобразите эту информацию на диаграмме.
2. Если вам известно о баскетболе больше, чем представлено на рис. 3.15, до-
бавьте эту информацию в диаграмму.
3. Вернитесь к разговору аналитика с баскетбольным тренером. Просмотрите от-
веты тренера и найдите хотя бы три фразы, побуждающие к дополнительным
вопросам. Например, в одной реплике тренер упоминает “трехочковую ли-
нию”. Дальнейшие расспросы должны прояснить особенности этого термина.
4. Забегая вперед, постарайтесь изобразить взаимосвязи между классами, пред-
ставленными на рис. 3.15.
3-й час. Использование концепций объектно-ориентированного проектирования
65
4-й час
Работа со связями
Из этого часа вы узнаете
> Как моделировать связи между классами
> Как визуализировать отношения класса с его подклассами
> Как отразить зависимости между классами
В модели, описанной в предыдущей главе, был указан набор классов, представ-
ляющих словарь предметной области игры в баскетбол. Такая модель обеспечивает
основу для дальнейшего исследования принципов игры. Очевидно, что она является
неполной.
Недостающая информация — это взаимодействие классов между собой. Взглянув
на модель (см. рис. 3.15), можно заметить отсутствие связи игрока с мячом. Из самой
модели не понятно, как игроки образуют команду или как происходит игра. Сконст-
руирован лишь список терминов, но не “снимок” предметной области.
В этой главе будут изучены связи между классами, позволяющие дополнить карти-
ну предметной области.
Ассоциации
Если классы концептуально взаимодействуют друг с другом, то такое взаимодейст-
вие называется ассоциацией. Исходная модель игры в баскетбол содержит несколько
подобных примеров. Рассмотрим одну ассоциацию — между игроком и командой. Ее
можно охарактеризовать фразой “игрок играет в команде” и отобразить в виде соеди-
няющей два класса линии, указав имя ассоциации (играет в) прямо над этой лини-
ей. Для наглядности с помощью закрашенного треугольника указывается направление
взаимосвязи. На рис. 4.1 показано, как изобразить ассоциацию Играет в между иг-
роком и командой.
Когда один класс ассоциируется с другим, каждый из них играет свою роль в этой
ассоциации. Такие роли можно показать на диаграмме под линией ассоциации возле
обозначения класса, выполняющего соответствующую роль. В ассоциации между
профессиональным игроком и командой эти роли носят название наемный работник
и наниматель. На рис. 4.2 показано, как изображать эти роли.
Рис. 4.1. Ассоциация между игроком
и командой
Рис. 4.2. В ассоциации каждый класс обычно
играет определенную роль, которую можно
представить на диаграмме
Ассоциация может работать в другом направлении: команда нанимает игроков.
Обе ассоциации можно показать на одной диаграмме, сопровождая их закрашенным
треугольником соответствующей ориентации (рис. 4.3).
Ассоциации могут быть более сложными, чем просто связь одного класса с другим.
Если рассмотреть таких игроков команды, как защитники, нападающие и центровые,
то при построении их ассоциаций с классом Команда получим диаграмму, изобра-
женную на рис. 4.4.
Рис. 4.4. С одним классом могут ассоции-
роваться несколько других
Рис. 4.3. На одной диаграмме можно
показать две ассоциации между
классами
Ограничения ассоциаций
Иногда ассоциация между двумя классами должна удовлетворять некоторому пра-
вилу. Это правило заключается в размещении ограничения возле линии ассоциации.
Например, БанковскийСлужащий обслуживает клиентов по очереди. Этот факт отра-
жается в модели с помощью фразы по очереди в фигурных скобках возле класса
Клиент (для отражения ограничения) (рис. 4.5).
Другой тип ограничения представляется отношением или, которое обозначается с
помощью пунктирной линии, соединяющей две линии ассоциаций, с надписью
{или}. Модель на рис. 4.6 показывает студента, выбирающего бюджетную или ком-
мерческую форму обучения.
4-й час. Работа со связями
67
Рис. 4.5. На ассоциацию можно наложить
ограничение. В этом примере ограничение ас-
социации Обслуживает указывает на то,
что БанковскийСлужащий обслуживает
клиентов в порядке очереди
Рис. 4.6. Отношение ИЛИ между двумя ассоциациями
Классы ассоциаций
Подобно классам, ассоциация может иметь атрибуты и операции. В этом случае
можно говорить о классе ассоциации. Для отображения класса ассоциации использу-
ются обозначения обычного класса с добавлением пунктирной линии, соединяющей
его с линией ассоциации. Класс ассоциации может быть связан с другими классами.
На рис. 4.7 показан класс ассоциации Играет в между игроком и командой. Класс
ассоциации Контракт связан с классом ГлавныйМенеджер.
Рис. 4.7. Класс ассоциации имеет атрибуты и операции. Он
связан с соответствующей ассоциацией с помощью пунктир-
ной линии и может также быть связан с другими классами
Связи
Ассоциация (как и класс) характеризуется наличием экземпляров. Если предста-
вить себе игрока, играющего в конкретной команде, отношение Играет в называется
связью, которую изображают в виде линии, соединяющей два объекта. Имя этой свя-
зи, как и имя объекта, подчеркивается (рис. 4.8).
68
Часть I. Начало
Рис. 4.8. Связь является экземпляром ассоциации. Она со-
единяет объекты. При изображении связи ее имя подчерки-
вается, как и имена объектов
Кратность
Ассоциация между объектами Игрок и Команда предполагает, что два класса нахо-
дятся в отношении “один к одному”. Здравый смысл подсказывает, что это не един-
ственный вариант взаимосвязи. В баскетбольной команде — пять человек, не считая
запасных игроков. Ассоциация Включает должна учитывать этот факт. С другой сто-
роны, игрок может играть только в одной команде, что должно учитываться в ассо-
циации Играет в.
Приведенные отношения являются примерами разной кратности, которая означа-
ет количество объектов одного класса, связанных с одним объектом другого. Чтобы
представить это количество на диаграмме, определенное число можно поместить над
линией ассоциации возле соответствующего класса, как это сделано на рис. 4.9.
Игрок
Команда
5 1
Рис. 4.9. Кратность означает количество
объектов одного класса, которые могут
быть связаны с одним объектом другого
класса
В этом примере приведен только один из вариантов кратности. Возможны также и
другие значения кратности. Один класс может быть связан с другим различными спо-
собами: “один к одному”, “один ко многим”, “один к нескольким”, “один к ограни-
ченному интервалу” (например, “один к 5.. 10”), “один к заданному количеству п” (как в
рассматриваемом примере) или “один к набору” (например, “один к 9 или 10”).
Для представления понятия “много” в UML используется символ звездочки (*).
Логическое ИЛИ передается двумя обозначениями: с помощью двух точек (1.. *), что
означает “один или более”, или запятой (5,10), что означает “5 или 10”. На рис. 4.10
показаны изображения возможных значений кратности.
Один к 0 или 1
Если класс а находится в отношении “один к 0 или Г’ с классом б, то последний называется
необязательным для класса а.
4-й час. Работа со связями
69
Рис. 4.10. Возможные значения кратности и их представление в UML
Квалификатор ассоциации
Если кратность ассоциации описывается отношением “один ко многим”, возника-
ет проблема поиска. Если объект одного класса для выполнения отведенной ему роли
в ассоциации должен выбрать конкретный объект другого класса, то он может сделать
это на основе некоторого заданного атрибута. Этот атрибут обычно представляет со-
бой идентификатор, например числовой. В частности, в списке зарезервированных
номеров отеля содержится много заказов (рис. 4.11).
Рис. 4.11. Список зарезервированных номе-
ров отеля и содержащиеся в нем заказы на-
ходятся в отношении “один ко многим ”
Когда вы резервируете место в гостинице, вашему заказу присваивается номер. Ес-
ли нужно узнать о наличии зарезервированного места, необходимо сообщить номер
заказа.
В UML идентифицирующая информация называется квалификатором. Он обозна-
чается небольшим прямоугольником, который прилегает к обозначению одиночного
70
Часть I. Начало
класса в отношении “один ко многим” (рис. 4.12). Хотя кратность ассоциации между
классами СписокЗаказов и Заказ составляет “один ко многим”, кратность ассоциации
между квалификатором номерПодтверждения и классом Заказ — “один к одному”.
Рис. 4.12. Обозначение квалификатора в UML. Оно
представляется прямоугольником, квалифицирующим
ассоциацию
Рефлексивные ассоциации
Иногда класс ассоциирован с самим собой. Этот вариант отношения, названный
рефлексивной ассоциацией, может возникнуть, когда объекты класса выполняют не-
сколько ролей. Человек в машине может быть пассажиром или водителем. В роли во-
дителя он везет одного или нескольких пассажиров (или не везет никого). На диа-
грамме этот случай отображается с помощью линии ассоциации, ведущей от прямо-
угольника класса к этому же прямоугольнику. На линии ассоциации, как и ранее,
обозначаются роли, имя ассоциации, ее направление и кратность. Пример такой ас-
социации представлен на рис. 4.13.
Везет
Рис. 4.13. Для случая рефлексив-
ной ассоциации линия проводится
от класса к этому же классу.
Здесь же можно указать выпол-
няемые роли, имя ассоциации, ее
направление и кратность
Наследование и обобщение
Одним из признаков объектно-ориентированного подхода является выполнение
одного из общеизвестных аспектов повседневной жизни: если вы знаете что-либо о
некоторой категории, то автоматически можете перенести эти знания на другие кате-
гории. Если известно, что объект относится к бытовой технике, то уже известно, что
он имеет выключатель, имя производителя и номер изделия. Если известно, что объ-
ект — это животное, то заранее ясно, что оно ест, спит, размножается, перемещается
в пространстве. При более детальном анализе можно составить список других атрибу-
тов и операций.
В рамках объектно-ориентированного подхода такое положение вещей называется
наследованием. В UML для наследования используется термин обобщение. Один класс
(дочерний, или подкласс) может наследовать атрибуты и операции другого (родитель-
4-й час. Работа со связями
71
ского класса, или суперкласса). Родительский класс является более общим по отно-
шению к дочернему.
Иерархия наследования не ограничивается двумя уровнями: дочерний класс может
выступать в роли родительского класса для другого дочернего класса. Класс Млекопи-
тающее является дочерним классом для класса Животное и родительским для класса
Лошадь.
В UML наследование отображается с помощью линии, которая соединяет роди-
тельский класс с дочерним. Конец линии, связанный с родительским классом, поме-
чается незакрашенным треугольником, указывающим на родительский класс. Такая
связь соответствует отношению является видом. Млекопитающее является видом жи-
вотного, лошадь является видом млекопитающего. На рис. 4.14 представлена описан-
ная иерархия наследования и дополнительные классы.
Обратите внимание на графическое представление ситуации, когда родительский
класс имеет несколько дочерних. Такая конструкция позволяет разгрузить диаграмму.
Нужно отметить, что UML не запрещает изображать все без исключения линии и тре-
угольники и не требует указывать наследуемые атрибуты и операции в прямоугольни-
ках подклассов, т.к. они уже представлены в обозначении суперкласса.
Рис. 4.14. Иерархия наследования в жи-
вотном мире
Наследование и отношение “является видом”
При моделировании наследования нужно убедиться, что дочерний класс удовлетворяет тре-
бованию “является видом” по отношению к родительскому классу. Если связь классов опи-
сывается по-другому, нужно использовать другую ассоциацию.
Дочерний класс часто отличается наличием дополнительных атрибутов и опера-
ций. Например, млекопитающее имеет шерсть и дает молоко, а такого атрибута и
операции нет в классе Животное.
Класс может не иметь родителя. В этом случае он называется базовым или корне-
вым классом. Класс также может не иметь дочернего класса, и тогда он называется
листовым классом. Если класс имеет только одного родителя, то говорят об одиночном
наследовании, а если несколько, — о множественном.
72
Часть I. Начало
Имя класса - существительное в единственном числе
Обратите внимание, что имена классов всегда представляют собой существительные в
единственном числе (например, класс животное, а не животные). Это согласуется с
отношением “является видом”. Обычно мы говорим “Лошадь — это вид животного”, а не
“Лошадь — это вид животных".
Изучение наследования
Во время бесед с клиентом аналитик выявляет отношение наследования несколь-
кими способами. В процессе переговоров могут быть выявлены как родительские так
и дочерние классы. Аналитик должен определить, являются ли атрибуты и операции
одного класса общими для нескольких классов, которые могут иметь собственные ат-
рибуты и операции.
В модели игры в баскетбол (см. главу 3, “Использование концепций объектно-
ориентированного проектирования”) содержатся классы Игрок, Защитник, Нападаю-
щий и Центровой. Атрибутами класса Игрок являются имя, рост, вес, стартовая-
Скорость и высотаВертикальногоПрыжка. Этот класс имеет операции вестиМячО,
передаватьМяч (), отбиратьМяч (), бросатьМяч (). Классы Защитник, Нападающий И
Центровой наследуют эти атрибуты и операции. Кроме того, у них имеются и собст-
венные. Класс Защитник должен включать операции начинатьАтаку (), перехваты-
ватьВерхниеМячи (). Класс Центровой должен содержать операцию забиватьМяч-
вкорзину (). Основываясь на информации тренера об относительном росте, аналитик
может наложить ограничение на рост человека, выполняющего определенную роль в
команде.
Аналитик может также заметить, что несколько классов имеют некоторое количе-
ство общих атрибутов и операций. В модели баскетбола используется класс ВремяИг-
ры, показывающий, сколько времени осталось до конца периода, и класс ВремяАтаки,
отвечающий за определение времени с момента овладения команды мячом. Учитывая
показания обоих временных счетчиков, аналитик может определить класс Время с
операцией отслеживатьВремя (), а классы ВремяИгры и ВремяАтаки будут наследо-
ваться от него.
Пример полиморфизма
Поскольку класс ВремяАтаки отслеживает 24 секунды (в профессиональном баскетболе)
или 35 секунд (в любительском), а ВремяИгры отслеживает 12 минут и 20 минут, соответ-
ственно, ТО операция отслеживатьВремя () обладает СВОЙСТВОМ полиморфизма.
Абстрактные классы
В модели баскетбола два класса — Игрок и Время — очень полезны, поскольку
служат в качестве родительских для важных дочерних классов. Важность дочерних
классов состоит в том, что в системе непременно появятся их экземпляры: при реали-
зации модели понадобятся экземпляры классов Защитник, Нападающий, Центровой,
ВремяИгры, ВремяАтаки.
Классы Игрок и Время не предоставляют никаких экземпляров в модели. Объекты
класса Игрок не служат какой-либо цели, так же, как и объекты класса Часы.
Классы, подобные классам Игрок и Время, называются абстрактными. Их имена
выделяются курсивом. На рис. 4.15 изображены два абстрактных класса и их дочерние
классы.
4-й час. Работа со связями
73
Рис, 4,15, Две иерархии наследования с абстрактными классами в модели баскетбола
Зависимости
Другой тип взаимосвязи характеризуется тем, что один класс использует другой.
Это называется зависимостью. Наиболее общим случаем зависимости является ис-
пользование одного класса в сигнатуре операции другого класса.
Предположим, нужно спроектировать систему, отображающую на экране монитора
формы, заполняемые служащими. Для выбора заполняемой формы используется ме-
ню. В системе будет два класса: Система и Форма. В числе операций класса Система
имеется операция отобразитьФорму (f:Форма). Отображаемая системой форма зави-
сит от того, какой экземпляр класса Форма выбрал пользователь. В UML это отноше-
ние изображается пунктирной линией, направленной от зависимого класса (рис. 4.16).
Рис. 4.16. Зависимость изображается пунктирной
линией со стрелкой
74
Часть I. Начало
Диаграммы классов и диаграммы
объектов
До сих пор речь шла о диаграммах классов, но ничего не говорилось о диаграммах
объектов. В завершение главы о связях самое время поговорить о способах визуализа-
ции объектов.
Диаграмма классов содержит общую декларативную информацию о свойствах клас-
са и его атрибутах, а также о связи данного класса с другими. Диаграмма объектов со-
держит более конкретную информацию об экземплярах класса и их связях с другими
экземплярами во времени.
Приведем пример. Допустим, вы наблюдаете за игрой в шахматы. Фрагмент шах-
матной партии показан на рис. 4.17.
Рис. 4.17. Фрагмент шахматной партии
Если вы не знаете правил игры в шахматы, то не сможете понять сложившуюся
ситуацию. Если же у вас есть диаграмма классов для игры в шахматы (рис. 4.18), то
она поможет понять общие правила игры. Атрибут верхняяЧастьФигуры просто опи-
сывает внешний вид шахматной фигуры.
Несмотря на то что диаграмма классов помогает понять общие правила игры в
шахматы (в частности, если в ней описываются операции ходКонемО, ходФерземО
и ходПешкой ()), она не проясняет конкретную позицию, показанную на рис. 4.17.
В этом поможет диаграмма объектов. На рис. 4.19 показана модель позиции, изобра-
женной на рис. 4.17, в которой все связи между объектами имеют имена.
4-й час. Работа со связями
75
Рис. 4.18. Диаграмма классов для фрагмента игры в шахматы
Рис. 4.19. Диаграмма объектов, отражающая фрагмент шах-
матной партии, показанной на рис. 4.17
Резюме
Если без отражения взаимосвязей модель классов является набором прямоуголь-
ников, составляющих словарь предметной области, то при их наличии проявляется
взаимосвязь терминов, что позволяет получить частичный снимок моделируемого ми-
ра. Ассоциации представляют собой общую концептуальную связь между классами.
Каждый класс в ассоциации играет определенную роль, а кратность показывает,
сколько объектов одного класса связано с одним объектом другого класса. Возможны
разные типы кратности. Графическим эквивалентом ассоциации является линия меж-
ду прямоугольными изображениями классов с указанием ролей и кратностей на ее
концах. Как и класс, ассоциация может иметь атрибуты и операции.
Класс может наследовать атрибуты и операции другого класса. Наследующий класс
является дочерним по отношению к родительскому, от которого он наследуется. При
изучении наследования в исходной модели были обнаружены классы, имеющие об-
щие атрибуты и операции. Абстрактные классы предназначены только для использо-
вания в качестве базовых для наследования и не порождают своих объектов. Наследо-
76
Часть I. Начало
вание изображается направленной к родительскому классу линией между родитель-
ским и дочерним классами.
Взаимосвязь при использовании одного класса другим называется зависимостью.
Наиболее общий случай зависимости состоит в использовании в сигнатуре операции
одного класса другим классом. Зависимость изображается пунктирной линией со
стрелкой, соединяющей связанные классы и исходящей из зависимого класса.
Диаграмма классов содержит общую информацию о классах. Для изображения кон-
кретных экземпляров классов и их взаимосвязей используются диаграммы объектов.
Вопросы и ответы
Используются ли имена в отношениях наследования, как это делается для ассоциации?
В UML не запрещается именовать отношения наследования, но обычно это из-
лишне.
Можно ли отражать другие типы отношений на диаграммах наследования?
Конечно. Модель может отражать любые виды отношений.
На рис. 4.18 класс ШахматнаяФигура содержит атрибуты цвет, начальнаяПозиция
и текущаяПозиция, которые не показаны в подклассах Конь, Ферзь и Пешка. Однако
эти классы тоже обладают указанными свойствами. Почему же эти свойства не показаны
на диаграмме?
Символ наследования — незаштрихованый треугольник — означает, что подклассы
содержат эти же атрибуты. В этом и состоит смысл наследования. Дочерний класс
включает все атрибуты и операции родительского класса.
На рис. 4.18 два атрибута подклассов имеют определенные значения. Как они отоО
бражаются на диаграмме объектов?
Конечно, значения атрибутов отражаются на диаграмме объектов. В главе 3 речь шла
о том, как изображаются значения атрибутов класса, принимаемые по умолчанию.
Практические занятия
Предлагаемые вопросы и упражнения разработаны для упорядочения полученных
знаний в области взаимосвязей классов в UML. Каждый вопрос и упражнение требу-
ют размышления о только что изученных обозначениях и их применении в соответст-
вии с конкретной ситуацией. Ответы можно найти в приложении А.
Игра в карты
При выполнении упражнений, связанных с классами, можно воспользоваться карточками.
Напишите в верхней части каждой карточки имя класса, а ниже линии — имена атрибутов и
операций. Набор таких карточек — прекрасное средство моделирования.
Тесты
1. Что такое кратность?
2. Как бы вы описали наследование?
3. Что такое абстрактные классы?
4. Каково назначение квалификатора?
4-й час. Работа со связями
77
Упражнения
1. В исходную модель баскетбола (глава 3) добавьте взаимосвязи, изученные в
этой главе. Если вы знакомы с баскетболом, добавьте связи, соответствующие
тому, что вы знаете об этой игре.
2. Существует афоризм: “Юрист, защищающий себя, в глазах клиента выглядит
дураком”. Создайте модель, которая отражала бы эту житейскую мудрость.
3. Изобразите иерархию наследования в вашем офисе. Обязательно включите в
нее абстрактные классы, а также все экземпляры.
4. Вспомните предметы, которые вы изучали в школе. Смоделируйте их набор
как иерархию наследования и не забудьте об абстрактных классах и экземпля-
рах. Включите в эту модель зависимости. (Являются ли какие-нибудь предме-
ты предпосылкой для изучения других?)
5. Представьте себе ассоциацию между классами Собака и Человек. Ее можно
назвать быть питомцем. После этого подумайте о такой же ассоциации между
классами Кошка и Человек. Теперь изобразите каждую из них и соедините
взаимосвязанные классы. Используйте понятие класса ассоциации, чтобы по-
казать, чем эти одинаково обозначенные ассоциации отличаются друг от друга.
6. Дополните обозначение класса ШахматнаяФигура на рис. 4.18, отобразив ог-
раничения атрибутов цвет, высота и верхняяЧастьФигуры. Придумайте на-
звания, определяющие форму различных фигур.
7. Если вы умеете играть в шахматы, дополните модель, показанную на рис. 4.18,
изобразив на ней остальные шахматные фигуры. Затем создайте диаграмму
объектов и начните игру. Добавьте на диаграмму значения всех атрибутов.
78
Часть I. Начало
5-й час
Агрегация, композитные объекты,
интерфейсы и реализации
Из этого часа вы узнаете
> Как построить модель класса, включающего другие классы
> Как моделировать интерфейсы и их связь с классами
> Что такое область видимости
Вы уже изучили ассоциации, познакомились с понятием кратности и наследова-
ния. Теперь вы практически готовы к созданию полноценных диаграмм классов.
В этой главе будет рассмотрен последний фрагмент головоломки, касающийся допол-
нительных типов взаимосвязей и других проблем, связанных с классами. Основная
цель — приобрести навыки создания статического представления системы с отраже-
нием всех взаимосвязей между ее классами.
Объекты-агрегаты
Иногда класс состоит из некоторого количества классов-компонентов. Это особый
тип взаимосвязи, называемый агрегацией. Компоненты и класс, который они состав-
ляют, находятся в ассоциации часть-целое (part-whole). В главе 2, “Знакомство с объ-
ектно-ориентированным подходом”, говорилось о том, что домашний компьютер
представляет собой агрегат, состоящий из системного блока, клавиатуры, манипуля-
тора “мышь”, монитора, устройства считывания компакт-дисков, одного или не-
скольких жестких дисков, модема, устройства чтения гибких дисков, принтера и, воз-
можно, колонок. В свою очередь, системный блок, наряду с дисковыми накопителя-
ми, содержит оперативную память, графическую карту и звуковую карту (и, возмож-
но, какие-либо другие устройства).
Агрегацию можно представить в виде дерева, корнем которого является “целое”
(например, компьютерная система), листьями — его компоненты. Целое с его компо-
нентом соединяет линия с незакрашенным ромбом, расположенным вблизи целого.
На рис. 5.1 показана компьютерная система в виде агрегата.
Рис. 5.1. Ассоциация агрегации (часть-целое) представляется линией, соединяю-
щей компонент и целое, с незакрашенным ромбом рядом с объектом-агрегатом
Хотя в этом примере каждый компонент принадлежит одному целому, для отно-
шения агрегации это необязательно. Среди домашней техники пульт дистанционного
управления может быть компонентом телевизора и видеомагнитофона одновременно.
Ограничения агрегации
Иногда набор возможных компонентов агрегата описывается с помощью взаимо-
связи ИЛИ. В некоторых ресторанах обед состоит из супа или салата, главного блюда
и десерта. Для моделирования такого меню вам потребуется использовать ограниче-
ние — слово или в фигурных скобках на пунктирной линии, соединяющей две линии
взаимосвязи “часть-целое” (рис. 5.2).
Рис. 5.2. На агрегацию можно наложить ограничение
и показать, что частью целого является один из двух
компонентов
80
Часть I. Начало
Соответствие ограничений
Обратите внимание на сходство в использовании надписи {или} на рис. 5.2 (задает огра-
ничение для агрегации) и на рис. 4.6 (задает ограничение для ассоциации).
Композитные объекты
Композит — это строгий тип агрегации, характеризующийся тем, что каждый эле-
мент может принадлежать только одному целому. Компоненты кофейного столика —
столешница и ножки — составляют композит. Символ композита совпадает с симво-
лом агрегации, за исключением того, что в этом случае используется закрашенный
ромб (рис. 5.3).
Рис. 5.3. В композите каждый ком-
понент принадлежит только одному
целому. Эта взаимосвязь обознача-
ется закрашенным ромбом
Структурные диаграммы композитов
Композит — это способ представления компонентов класса. Если вы хотите пред-
ставить внутреннюю структуру класса на языке UML 2.0, то это можно сделать при
помощи структурной диаграммы композита или композитной структурной диаграммы.
Рассмотрим пример. Предположим, вы создаете модель рубашки и хотите пока-
зать, как она вписывается в гардероб. Один тип контекстной диаграммы (рис. 5.4)
отображает рубашку как большой прямоугольник класса с размещенной внутри него
диаграммой. Эта диаграмма показывает связи компонентов друг с другом и является
композитной структурной диаграммой.
Структурная диаграмма композита концентрирует внимание на рубашке и состав-
ляющих ее компонентах.
Этот тип диаграмм является не совсем новым в UML 2.0. В версиях 1.x аналогом
такой диаграммы служила структурная контекстная диаграмма.
Интерфейсы и реализации
В главе 2 упоминалась инкапсуляция. Это свойство объекта скрывать свои операции
от других объектов. Например, закрывая автомобиль, человек не видит, какие опера-
ции при этом выполняются. При переключении канала телевизора зритель тоже не
знает, как с технической точки зрения выполняется эта операция. Но если эти опера-
ции скрыты, как соответствующие устройства знают, что им нужно делать?
54 час. Агрегация, композитные объекты, интерфейсы и реализации
81
Рис. 5.4. Структурная композитная диаграмма показывает компо-
ненты класса, размещенные внутри прямоугольника, соответст-
вующего этому классу
Автомобиль и телевизор получают сообщение (запрос на выполнение операции) че-
рез интерфейс. Интерфейс — это набор операций, которые задают некоторые аспекты
поведения класса и представляют его для других классов.
Рассмотрим пример, проясняющий концепцию интерфейса. Включая стиральную
машину, мы не задаем временнь/е параметры и не управляем напрямую вращением
барабана. Не требуется также вручную включать насос и прекращать подачу воды. Все
эти операции выполняет сама стиральная машина, для которой мы задаем режим
стирки с помощью панели управления (рис. 5.5).
Панель управления — это интерфейс стиральной машины. Какие операции вы-
полняет эта панель? Она позволяет нажать или отпустить кнопки, а также повернуть
ручку управления по часовой стрелке или против.
Эти операции являются в определенном смысле абстрактными. Они не имеют фи-
зического смысла, если панель управления не подключена к самой стиральной маши-
не. Таким образом, стиральная машина “реализует” эти операции, выполняя их при
стирке: включение и выключение стиральной машины, определение параметров ре-
жима стирки (температуры, числа оборотов при отжиме и т.п.).
На языке UML стиральная машина частично “реализует” поведение панели управ-
ления. По этой причине взаимосвязь между классом и его интерфейсом называется
отношением реализации.
Почему мы говорим о частичной реализации поведения? Дело в том, что не все
операции стиральной машины связаны с параметрами панели управления. Некоторые
операции, например загрузитьБелье() выполняются без использования элементов
управления.
До сих пор много говорилось об операциях интерфейса, но ничего не говорилось о
его атрибутах. Дело в том, что интерфейс не имеет атрибутов. Да, панель управления
имеет кнопки и диски определенного размера. Но на работе стиральной машины эти
значения никак не отражаются. Когда речь идет об интерфейсе, важную роль играют
только операции.
Изображение интерфейса аналогично изображению класса — он тоже представля-
ется прямоугольником. Отличие состоит в том, что интерфейс как набор операций не
имеет атрибутов. Однако из изображения класса можно исключать атрибуты. Как же
82
Часть I. Начало
безошибочно отличить интерфейс от класса, у которого просто не показаны атрибу-
ты? Во-первых, можно использовать конструкцию стереотипа и поместить надпись
«интерфейс» над именем интерфейса. Во-вторых, имя любого интерфейса может
начинаться с буквы “I”.
Рис. 5.5. Панель управления —
это интерфейс стиральной
машины, позволяющий зада-
вать параметры выполняемых
ею операций
Отношение реализации между классом и интерфейсом изображается пунктирной
линией с полым треугольником, примыкающим к интерфейсу и указывающим на
него. На рис. 5.6 показано отношение реализации между классом СтиральнаяМашина
и интерфейсом ПанельУправления.
ПанельУправления
Рис. 5.6. Интерфейс — это набор операций,
реализуемых классом. Класс связан с ин-
терфейсом отношением реализации, кото-
рое обозначается пунктирной линией с не-
закрашенным треугольником, примыкающим
к интерфейсу и указывающим на него
5-й час. Агрегация, композитные объекты, интерфейсы и реализации
83
Существует еще один способ представления класса и интерфейса — с помощью
небольшого кружочка, соединенного линией с классом, как показано на рис. 5.7.
СтиральнаяМашина
ПанельУправления
О
Рис. 5.7. Редко используемый спо-
соб изображения класса, реализую-
щего интерфейс
Наследование и реализация
Отметим сходство символов реализации и наследования. Наследование можно рассматри-
вать как взаимосвязь между родителем и ребенком. Родитель передает физические атрибу-
ты (цвет глаз, цвет волос и т.д.) ребенку, поведение которого тоже совпадает с родитель-
ским. Реализация напоминает взаимосвязь учителя и ученика: учитель не передает физиче-
ские атрибуты ученику, но ученик перенимает поведение и образ действий от учителя и
использует их для достижения своих целей.
Класс может реализовывать несколько интерфейсов, а интерфейс, в свою очередь,
может быть реализован несколькими классами.
Вездесущие интерфейсы
Интерфейсы окружают нас повсюду. Зачастую мы рассматриваем их как неотъемлемую
часть соответствующих классов.
В частности, панель управления — обязательная составляющая любого бытового устройства.
Она позволяет управлять не только стиральной машиной, но и включать радио и настраивать
его на нужную волну. Сложно перечислить все устройства, для ввода информации в которые
используются панели управления.
Одна компания выпустила панель управления, которая подключается в качестве устройства
ввода к персональному компьютеру через USB-порт. Ее можно запрограммировать таким
образом, чтобы она выполняла любую функцию, которую можно реализовать с помощью
клавиатуры. Гордые обладатели такой панели управления обычно говорят: "Она абсолютно
бесполезна, но я пользуюсь ею каждый день!”
Поскольку при пользовании стиральной машиной мы вынуждены общаться с ней
через интерфейс, то взаимодействие человека с интерфейсом часто моделируется как
зависимость. В главе 4 указывалось, что отношение зависимости на диаграммах UML
изображается пунктирной линией со стрелкой на конце (рис. 5.8).
<<интерфейс>>
СтиральнаяМашина
ПанельУправления
Человек
Рис. 5.8. Для моделирования взаимодействия класса с интерфейсом
используется символ зависимости
84
Часть I. Начало
В UML 1.x отношение зависимости отображалось на полной и усеченной диа-
граммах. В UML 2.0 для обозначения усеченной версии взаимодействия объектов че-
рез интерфейс используется специальное обозначение, показанное на рис. 5.9.
Рис. 5.9. В UML 2.0 для моделирования взаимодейст-
вия классов через интерфейс без изображения самого
символа интерфейса используется символ кружочка,
помещенного в гнездо
Интерфейсы и порты
В UML 2.0 концепция интерфейса проработана несколько глубже, чем в предыду-
щих версиях. Теперь можно моделировать взаимосвязь между интерфейсом и классом.
Мышь можно рассматривать как интерфейс к компьютеру. С ее помощью можно
выполнять несколько операций — указывать на нужный объект на экране и щелкать
на кнопке (иногда навигацию можно осуществлять с помощью колесика, располо-
женного между кнопками мыши). Сами по себе эти операции достаточно бесполезны.
Они приобретают смысл только в том случае, когда “реализуются” компьютером.
Только в этом случае можно выделять объекты на экране и выполнять над ними оп-
ределенные действия.
Как мышь подключается к компьютеру? Кабель мыши подключается к компьюте-
ру через порт — точку подключения периферийного устройства к компьютеру. Каж-
дый компьютер имеет параллельный, последовательный порт, а также один или не-
сколько USB-портов. Порты — это точки, через которые компьютер взаимодействует
с окружающей средой.
В UML 2.0 существует специальное обозначение для моделирования этих точек
взаимодействия. Как видно из рис. 5.10, символ порта — это небольшой прямоуголь-
ник, расположенный на границе обозначения класса, который соединен линией с
кружочком, связанным с интерфейсом.
Компьютер
Мышь
Рис. 5.10. Символ порта в UML 2.0,
представляющего собой точку взаи-
модействия класса со средой
Области видимости
Понятие области видимости тесно связано с интерфейсом и реализацией. Термин
видимость применяется по отношению к атрибутам и операциям и задает типы других
классов, которые могут использовать заданные атрибуты или операции класса (или
5-й час. Агрегация, композитные объекты, интерфейсы и реализации
85
операции интерфейса). Выделяют три области видимости. Элементы открытой облас-
ти (public) могут использовать другие классы. Атрибуты и операции защищенной об-
ласти (protected) могут использовать только наследники этого класса. Атрибуты и опе-
рации закрытой (private) области используются только самими классами. Для телеви-
зионной аппаратуры операции изменитьГромкость () и изменитьКанал ()
общедоступны, а операция отобразитьКартинкуНаЭкране() — закрыта. Для автомо-
биля операции увеличитьСкорость () и тормозить () — открыты, а операция обно-
витьКилометраж() относится к защищенной области.
Несложно догадаться, что реализация предполагает открытость всех операций ин-
терфейса. Ограничивать доступ к операциям не имеет смысла, потому что они приме-
няются для реализации множества классов.
Для обозначения открытой области видимости перед обозначением атрибута или
операции ставится символ “+”, элементы защищенной области помечаются символом
а члены закрытой области — символом Примеры вышеупомянутых обозна-
чений открытых, защищенных и закрытых операций для телевизора и автомобиля
приведены на рис. 5.11.
Телевизор
+ производитель
+ модель
+ изменитьГромкость()
+ изменитьКанал()
- отобразитьКартинкуНаЭкране()
Автомобиль
+ производитель
+ модель
+ увеличитьСкорость()
+ тормозить()
# обновитьКилометраж()
Рис. 5.11. Общедоступные и закрытые операции для теле-
визора; общедоступные и защищенные операции для авто-
мобиля
Статические и динамические классы
С атрибутами и операциями связано понятие статических и динамических классов.
Для динамического класса (instance scope) каждый экземпляр имеет собственное значе-
ние атрибутов и операций. Все экземпляры статического класса (classifier scope) име-
ют общее значение для каждого атрибута или операции. В последнем случае имена
атрибутов и операций подчеркиваются. Статический класс используется в том случае,
когда заданная группа экземпляров должна совместно использовать значения закры-
того атрибута. Динамические классы встречаются гораздо чаще.
Резюме
Завершая изучение классов и взаимосвязей между ними, необходимо остановиться
на некоторых дополнительных типах взаимоотношений. Агрегация задает ассоциацию
“часть-целое”. “Целый” класс состоит из классов-компонентов. Компонент может
быть частью нескольких агрегатов. Композит представляет собой строгую форму аг-
регации, в которой компонент может быть частью только одного целого. Обозначения
UML для агрегации и композиции очень схожи. На линии связи части и целого со
стороны агрегата добавляется ромб. При обычной агрегации используется полый
ромб, а при композиции — закрашенный.
86
Часть I. Начало
Композитная структурная диаграмма визуализирует внутреннюю структуру класса
(отображает вложенные классы).
Реализация — это ассоциация между классом и интерфейсом, представляющая на-
бор операций, используемых другими классами. Графически интерфейс представляет-
ся как класс без атрибутов. Чтобы отличить его от класса, чьи атрибуты просто не по-
казаны на диаграмме, над именем интерфейса размещают стереотип <<интерфейс>>
ли (второй вариант) имена интерфейсов начинают с прописной буквы “I”. Реализа-
ция представляется в UML в виде пунктирной линии, соединяющей класс и интерфейс.
На этой линии со стороны интерфейса размещают закрашенный треугольник, указы-
вающий на интерфейс. Другим способом представления реализации является соедине-
ние класса сплошной линией с небольшим кружком, изображающим интерфейс.
В UML 2.0 появился символ порта — точки, через которую класс взаимодействует
со своей средой. Этот символ представляет собой маленький прямоугольник на гра-
нице обозначения класса. Кружочек обозначает соединение с интерфейсом.
В терминах областей видимости все операции интерфейсов общедоступны или от-
крыты (public), так что любой класс может их использовать. Существует еще две об-
ласти видимости: защищенная (protected) (атрибуты и операции из этой области могут
использоваться дочерними классами) и закрытая (private) (атрибуты и операции ис-
пользуются только самим классом). Символ “+” означает общедоступную область ви-
димости, “#” соответствует защищенной, а — закрытой.
С атрибутами и операциями связано понятие статических и динамических классов.
Каждый объект динамического класса имеет собственное значение атрибутов и опе-
раций. Для статического класса каждый атрибут или операция имеют только одно
значение.
Вопросы и ответы
Обладает ли отношение агрегации свойством транзитивности? Другими словами, если
класс 3 является компонентом класса 2, а класс 2 — компонент класса 1, то будет ли
класс 3 компонентом класса 1?
Да, агрегация транзитивна. В нашем примере кнопки манипулятора “мышь” и его
шарик являются частями, и в то же время они являются частями компьютерной сис-
темы.
Можно ли считать, что термин “интерфейс” соответствует термину “пользовательский
интерфейс” или “графический пользовательский интерфейс”?
Нет, это более общее понятие. Интерфейс — это набор операций, которые один
класс предоставляет другим классам, один из которых может быть пользователем (но
это не обязательно).
Практические занятия
Вопросы и упражнения предназначены для проверки и закрепления знаний об аг-
регации, композитных объектах, контекстах и интерфейсах. Ответы содержатся в при-
ложении А.
Тесты
1. В чем состоит различие между агрегатным и композитным объектом?
2. Что такое реализация? В чем сходство реализации с наследованием? В чем от-
личие реализации от наследования?
5-й час. Агрегация, композитные объекты, интерфейсы и реализации
87
3. Как промоделировать взаимодействие классов через интерфейс?
4. Перечислите три области видимости и опишите их свойства.
Упражнения
1. Создайте композитную структурную диаграмму периодического журнала. Ис-
пользуйте классы Оглавление, ОтРедактора, Статья, Рубрика.
2. Наиболее популярным типом графического интерфейса пользователя является
оконный интерфейс. Используя полученные о UML знания, изобразите диа-
грамму классов интерфейса с использованием классов Окно, Пиктограмма,
Меню, УказательМыши. Дополнительно к перечисленным классам добавьте
связанные с ними термины, такие как ПолосаПрокрутки, Курсор и другие
необходимые классы.
3. Сконструируйте модель электрической точилки для карандашей с использова-
нием всех существенно важных атрибутов и операций. Каков ее интерфейс?
4. Промоделируйте взаимодействие класса Компьютер с интерфейсом Сенсор-
наяПанель. Укажите, какие компьютерные операции можно выполнять через
сенсорную панель. Включите в модель класс Пользователь. Используйте при
этом полное и усеченное обозначения, применяемые в UML 2.0.
88
Часть I. Начало
6-й час
Знакомство с прецедентами
Из этого часа вы узнаете
> Что такое прецеденты
> Как создавать, включать и расширять прецеденты
> Как выполнить анализ прецедента
В трех предыдущих главах мы познакомились с диаграммами, обеспечивающими
статическое представление классов в системе. Теперь перейдем к динамическому
представлению и покажем, как система и ее классы изменяются во времени. Статиче-
ское представление позволяет проанализировать структурные аспекты будущей систе-
мы. Динамическое представление, как мы убедимся далее, помогает анализировать
взаимодействие внутри системы, а также способствует созданию программ.
Заказчик и команда разработчиков составляют группу заинтересованных лиц для
данной системы. Но мы не учли еще одну важную составляющую общей картины —
пользователя. Ни статическое, ни динамическое представление не отображают пове-
дения системы с точки зрения пользователя. Понимание его точки зрения — это ключ
к построению системы. Система должна удовлетворять требованиям пользователя.
Моделирование системы с точки зрения пользователя — это задача прецедентов.
В этой главе будут рассмотрены прецеденты и их функции. В следующей главе вы уз-
наете, как визуализировать прецеденты с помощью диаграмм.
Что такое прецеденты
Недавно я купил цифровую фотокамеру. При ее покупке в магазине мне предло-
жили множество модификаций. Как выбрать нужную модель? Я спросил себя, что со-
бираюсь делать с фотокамерой. Какие возможности мне требуются? Нужна ли мне
совместимость с другими устройствами? Играют ли роль возможности объектива? Бу-
ду ли я снимать объекты в движении? Нужно ли мне будет отправлять снимки через
Internet? Буду ли я печатать снимки? Если да, то какого размера? Нужны ли мне воз-
можности видеосъемки? А звуковое сопровождение?
Делая осознанную покупку, мы все оказываемся в подобном положении. Наши
действия называются анализом прецедентов (use case analysis). Мы спрашиваем себя,
как будем использовать тот или иной продукт или систему, в которую собираемся
вложить деньги, и пытаемся найти то, что удовлетворяет нашим требованиям. Поэто-
му очень важно знать эти требования.
Такой процесс играет особенно важную роль на этапе анализа системных требова-
ний. Способ использования системы пользователями определяет проектное решение,
которое будет положено в ее основу.
Прецедент — это конструкция, помогающая аналитику определить способ исполь-
зования системы. Набор прецедентов описывает систему в терминах действий, вы-
полняемых пользователем.
Рассматривайте прецедент как набор сценариев использования системы. Каждый
сценарий описывает последовательность действий. Каждая последовательность дейст-
вий инициируется пользователем, другой системой, аппаратным средством или в ка-
кой-либо момент времени. Сущности, инициирующие сценарии, называются испол-
нителями (actor). Результат этих действий должен быть полезен исполнителю.
Зачем нужны прецеденты
Прецедент заставляет потенциальных пользователей думать о системе со своих по-
зиций. Пользователям не всегда легко выразить свои требования к системе. Посколь-
ку обычно процесс разработки системы представлял собой бессистемную процедуру с
кратким анализом, то пользователей несколько удивлял интерес к их мнению.
Основная идея заключается в том, чтобы привлечь пользователей к разработке
системы на ранних стадиях анализа и проектирования. Это повышает вероятность
создания полезной системы, позволяет сконцентрироваться на мнении людей, а не на
компьютерных понятиях, с которыми не могут работать реальные пользователи.
Пример: автомат для продажи лимонада
Допустим, требуется разработать автомат для продажи лимонада. Чтобы узнать
мнение пользователей, нужно опросить большое количество людей и узнать, как они
будут использовать эту машину.
Поскольку основная функция автомата — продавать лимонад, то пользователи бы-
стро расскажут вам о главном прецеденте Покупка лимонада. В обычной системе эти
сценарии описываются в терминах взаимодействия с пользователями (рис. 6.1).
Прецедент Покупка лимонада
Исполнителем в данном прецеденте является покупатель, желающий приобрести
стакан лимонада. Он инициирует сценарий, опуская монету в автомат. Затем он вы-
бирает сорт лимонада. Если все идет нормально, автомат выдает ему стакан с выбран-
ным напитком.
Помимо последовательности выполняемых действий заслуживают внимания также
и другие факторы. Какие предусловия необходимы для реализации сценария Покупка
лимонада? Наиболее очевидным является ощущение жажды. Какие постусловия реа-
90
Часть I. Начало
лизуются после выполнения сценария? Самым очевидным является наличие лимонада
у покупателя.
Является ли описанный сценарий единственным для прецедента Покупка лимо-
нада? Мне приходят в голову и другие сценарии. Возможно, выбранный покупателем
сорт лимонада отсутствует или у покупателя нет точной суммы, соответствующей
стоимости напитка. Как автомат должен обрабатывать эти сценарии?
Рис. 6.1. Прецедент определяет набор
сценариев для достижения цели, по-
лезной исполнителю. В рассматри-
ваемом примере одним из прецедентов
является Покупка лимонада
SODR
о О О О О О О
ГГ1 I I I I 1П1
Давайте вернемся к сценарию, когда требуемый сорт лимонада отсутствует. Он яв-
ляется альтернативным при реализации этого прецедента. Пользователь инициирует
прецедент, опуская монету в автомат. Затем он выбирает сорт лимонада. Поскольку
выбранный сорт отсутствует, покупателю выдается соответствующее сообщение. В
идеале пользователю нужно предложить выбрать другой сорт лимонада или вернуть
деньги. Пользователь выберет другой сорт лимонада или потребует вернуть деньги.
Постусловием этого сценария является полученный стакан лимонада или возвращен-
ные деньги.
Еще один сценарий
Возможен, конечно, и еще один ход событий. При отсутствии определенного сорта лимона-
да сообщение об этом отображается непрерывно до новой заправки автомата. В этом слу-
чае пользователю даже не придется опускать монету. Клиенту, для которого разрабатывает-
ся автомат, больше должен понравиться первый сценарий. Если покупатель уже опустил мо-
нету, то он скорее всего закажет другой сорт лимонада, а не потребует вернуть деньги.
Теперь рассмотрим сценарий отсутствия нужной суммы. Пользователь инициирует
прецедент и выбирает сорт лимонада. Допустим, требуемый сорт лимонада имеется.
Тогда автомат должен выдать стакан лимонада и сдачу. Если сдача отсутствует, авто-
мат должен вернуть деньги с предложением опустить точную сумму. Предусловие для
этого сценария совпадает с предыдущим. Постусловием является стакан лимонада со
сдачей либо возвращенная сумма денег.
Еще одной возможностью при отсутствии сдачи является постоянное отображение
сообщения с просьбой опускать точную стоимость покупки. Это сообщение должно
оставаться до тех пор, пока в автомат не добавят мелочи для выдачи сдачи.
6-й час. Знакомство с прецедентами
91
Дополнительные прецеденты
Мы рассмотрели пример с автоматом по продаже лимонада с точки зрения потреби-
теля — покупателя. Другие пользователи дополняют картину эксплуатации автомата.
Этот автомат обслуживает специалист, пополняющий запасы лимонада (рис. 6.2), и ин-
кассатор (рис. 6.3). Зачастую такие функции выполняет один и тот же человек. Назван-
ные специалисты реализуют еще два прецедента: Заправка автомата и Сбор денег.
Рис. 6.2. Важный прецедент Заправка лимонада
Рис. 6.3. Еще один важный прецедент —
Сбор денег
92
Часть I. Начало
Рассмотрим прецедент Заправка автомата. Специалист инициирует этот преце-
дент через заданные интервалы времени (скажем, раз в две недели). Он разблокирует
систему защиты автомата (возможно, специальным ключом), открывает автомат и за-
полняет емкости для сиропа. Затем пополняет запас мелочи для сдачи. После этого он
закрывает автомат и включает систему защиты. Предусловием этого прецедента явля-
ется истечение заданного интервала времени, а постусловием — новый запас продукта
для продажи.
Прецедент Сбор денег инициируется также по истечении заданного интервала
времени. Он включает ту же последовательность действий, что и Заправка автомата.
Специалист разблокирует автомат, открывает его, забирает деньги, закрывает и бло-
кирует автомат. Предусловием является истечение интервала времени, а постуслови-
ем — деньги в руках инкассатора.
Заметим, что при описании прецедента нас не интересует способ его реализации.
В рассматриваемом примере мы не касаемся внутреннего устройства автомата. Не
важно также, как работает механизм дозировки или происходит оплата. Мы описыва-
ем, как автомат выглядит с точки зрения пользователя.
Основной задачей этого этапа является описание набора прецедентов для разра-
ботчиков автомата по продаже лимонада. Если разработчики знают, чего ожидают от
автомата покупатели, специалисты по заправке и инкассаторы, то разработают авто-
мат, удовлетворяющий требованиям всех этих групп пользователей.
Включение прецедента
Прецеденты Заправка автомата и Сбор денег включают некоторые общие шаги.
Оба прецедента начинаются с разблокирования и открытия автомата, а завершаются
его закрытием и блокировкой. Можно ли избежать дублирования этих шагов в раз-
личных прецедентах?
Можно. Это делается с помощью выделения стандартных последовательностей
действий и оформления их в виде дополнительного прецедента. Шаги “разблокирова-
ние” и “открытие” можно объединить в рамках прецедента Проникновение внутрь,
а “закрытие” и “блокировку” — в рамках прецедента Выход наружу. Подобная по-
следовательность шагов показана на рис. 6.4.
Введя эти прецеденты, можно переформулировать описанные выше прецеденты.
Так, сценарий Заправка автомата начинается со сценария Проникновение внутрь.
Затем специалист по заправке выполняет свои функции, после чего прецедент завер-
шается выполнением сценария Выход наружу. Аналогично: прецедент Сбор денег
начинается со сценария Проникновение внутрь, затем выполняются основные дей-
ствия, и, наконец, —- сценарий Выход наружу.
Таким образом, прецеденты Заправка автомата и Сбор денег включают новые
прецеденты. Такой пример повторного использования прецедента называется включе-
нием прецедента.
Несколько слов о включении
В ранних версиях UML включение прецедента называлось использованием прецедента. Этот
термин встречается до сих пор. Однако понятие “включение” обладает двумя преимущест-
вами. Во-первых, оно яснее. Действия одного прецедента включают действия другого. Во-
вторых, этот термин позволяет избежать повторного употребления слов с общим корнем.
Нам не придется говорить “повторное использование за счет использования прецедента”.
6-й час. Знакомство с прецедентами
93
Рис. 6.4. Некоторые действия в рамках прецедента мож-
но объединять. Комбинация действий составляет допол-
нительный прецедент
Расширение прецедента
Повторное использование прецедентов обеспечивается не только за счет включе-
ния. Иногда новый прецедент создается путем добавления нескольких шагов к суще-
ствующему.
Вернемся к прецеденту Заправка автомата. Перед заправкой емкостей специали-
сту можно сообщить, какие сорта лимонада продаются хорошо, а какие — не очень.
Тогда вместо равномерной заправки всех сортов сиропа этот специалист мог бы уве-
личить количество сиропа популярных сортов.
Добавив эти действия к прецеденту Заправка автомата, получим новый преце-
дент, который можно назвать Заправка с учетом спроса. Этот прецедент является
расширением исходного прецедента.
Анализ прецедента
В нашем примере мы сразу перешли к рассмотрению конкретных прецедентов.
В реальной жизни обычно сначала выполняется анализ прецедентов.
На основе опроса клиента (и консультаций с экспертами) составляются исходные
диаграммы классов, описанные в главе 3. Это позволяет познакомиться с предметной
областью и используемыми терминами. Теперь у разработчиков есть основа для об-
щения с пользователями.
Программисты опрашивают пользователей (желательно большую группу) с прось-
бой рассказать о способах использования разрабатываемой системы. На основе отве-
тов создается набор прецедентов. Затем нужно кратко описать каждый прецедент.
94
Часть I. Начало
Желательно также сформировать список всех исполнителей, которые инициируют
прецеденты и получают выгоду от их реализации. После этого разработчики могут
общаться с пользователями на их языке.
Описание прецедентов приносит плоды на нескольких стадиях процесса разработ-
ки: оказывает помощь в разработке интерфейса пользователя, в принятии программ-
ных решений и обеспечении основы для тестирования системы.
Для дальнейшего анализа прецедентов нужно ознакомиться с системой обозначе-
ний UML, что и предлагается в следующей главе.
Резюме
Прецедент — это конструкция, позволяющая описать систему с точки зрения по-
тенциальных пользователей. Прецедент представляет собой набор сценариев, ини-
циируемых исполнителями (людьми, аппаратными средствами, другими системами
или интервалами времени). Результат прецедента должен быть полезен исполнителю,
инициировавшему этот прецедент, либо какому-то другому исполнителю.
Прецеденты можно использовать повторно. Один из способов предполагает вклю-
чение шагов одного прецедента в последовательность действий другого. Другой путь
сводится к созданию нового прецедента путем добавления нескольких шагов к суще-
ствующему — расширению прецедента.
Опрос пользователей — лучший способ определения прецедентов. При этом важно
выявить предусловия для инициализации прецедента и постусловия, реализуемые в
результате выполнения прецедента.
Опрос пользователей осуществляется после составления перечня классов-
кандидатов. Это обеспечивает базовую терминологию для общения с пользователями.
Желательно опрашивать группы пользователей. Задачей этого этапа является форми-
рование списка возможных прецедентов и всех возможных исполнителей.
Вопросы и ответы
Для чего введено понятие прецедента? Нельзя ли ограничиться опросом пользователей?
Нет, нельзя. Ответы пользователей нужно структурировать. А это делается с помо-
щью прецедентов. Такая структура оказывается очень полезной для последующих об-
суждений результатов опроса пользователей с участием заказчика и разработчиками.
Нужно ли ограничивать список прецедентов только теми сценариями, которые виде Г
ляют пользователи в процессе интервьюирования?
Конечно, нет. Очень важно проанализировать ответы пользователей и постараться
выделить прецеденты, о которых они даже не подумали.
Насколько сложно выделить прецеденты?
Я убедился на своем опыте, что сформулировать прецеденты (даже высокого уров-
ня) совсем несложно. Трудности возникают при детальном составлении каждого сце-
нария. При построении системы пользователям очень сложно сформулировать после-
довательность действий, поскольку эти действия им слишком хорошо знакомы. По-
этому работа в группах обычно позволяет лучше сформулировать мысли, которые
трудно выразить отдельному пользователю.
6-й час. Знакомство с прецедентами
95
Практические занятия
В этой главе не рассматривался язык UML. Поэтому задачей этого занятия являет-
ся освоение теоретических понятий и применение их в различных ситуациях. Прак-
тическая часть позволяет подготовиться к следующему занятию, предполагающему
визуализацию рассмотренных здесь теоретических вопросов средствами UML. Ответы
можно найти в приложении А.
Тесты
1. Как называется сущность, инициирующая прецедент?
2. Что означает термин “включение прецедента”?
3. Что означает термин “расширение прецедента”?
4. Можно ли сказать, что прецедент — это сценарий?
Упражнения
1. Допустим, вы выбираете некоторый товар в магазине. Какие прецеденты нуж-
но рассмотреть, чтобы принять решение о покупке?
2. Составьте список прецедентов, связанных с домашним кинотеатром.
3. Для рассмотренного примера с автоматом по продаже лимонада создайте пре-
цедент, включающий прецеденты Проникновение внутрь И Выход наружу.
4. Прецеденты позволяют проанализировать и экономический процесс, и саму
систему. Возьмем для примера супермаркет по продаже компьютерной техни-
ки, где представлены аппаратные средства, периферия и программные продук-
ты. Кто в этой системе исполнители? Выделите основные прецеденты для
этой системы. Какие сценарии существуют в рамках каждого прецедента?
96
Часть I. Начало
7-й час
Использование диаграмм прецедентов
Из этого часа вы узнаете
> Как представить модель прецедентов
> Как визуализировать отношения между прецедентами
> Как создавать и применять модели прецедентов
Описание прецедентов — это мощный инструмент, позволяющий аналитику понять
принципы работы системы и сформулировать требования к системе с точки зрения ее бу-
дущих пользователей. В этой главе будут рассмотрены вопросы визуализации прецедентов.
Роль прецедентов в разработке системы возрастает с использованием UML для их
визуализации. В этом случае появляется возможность получения дополнительной ин-
формации от пользователей, которые, как правило, не могут четко изложить все свои
знания о предметной области. Кроме того, визуальное представление позволяет ком-
бинировать диаграммы прецедентов с другими типами диаграмм, создаваемыми при
разработке системы.
Одна из главных целей системного анализа — определение набора прецедентов.
Такой набор является пользовательским представлением системы. Его необходимо
упорядочить и привести к удобному для использования виду. При модификации сис-
темы каталог прецедентов служит основой дня формирования требований к новой
версии системы.
Представление модели прецедентов
Один исполнитель инициирует прецедент, а другой (возможно, инициатор, но не-
обязательно) — получает новое качество от его реализации. Графически это представ-
ляется просто. Эллипс соответствует прецеденту, упрощенная фигурка представляет
исполнителя. Инициирующий исполнитель находится слева от прецедента, прини-
мающий исполнитель — справа. Имя исполнителя размещается прямо под его графи-
ческим изображением. Имя прецедента располагается либо внутри эллипса, либо
прямо под ним. Обозначения исполнителя и прецедента соединяются сплошной лини-
ей, представляющей их взаимодействие подобно отображению взаимосвязи классов.
При выполнении анализа прецедентов определяются границы системы и ее связь с ок-
ружающим миром. Исполнители обычно находятся вне системы, в то время как прецеден-
ты — внутри. Для обозначения границ системы используется прямоугольник (внутри ко-
торого указывается имя системы). Внутри прямоугольника располагаются прецеденты.
Исполнители, прецеденты и соединительные линии образуют модель прецедентов.
На рис. 7.1 показаны используемые графические обозначения.
Исполнитель
Исполнитель
Рис. 7.1. В модели прецедентов упро-
щенная фигура соответствует испол-
нителю, эллипс — прецеденту, линия
связи представляет взаимодействие
исполнителя и прецедента
Модель автомата по продаже лимонада
Воспользуемся этими обозначениями при создании модели прецедентов для сис-
темы, рассмотренной в предыдущей главе, в которой говорилось о прецедентах для
автомата по продаже газированной воды. Прецедент Покупка лимонада располагает-
ся внутри системы вместе с прецедентами Заправка автомата и Сбор денег. Ис-
полнителями являются Покупатель, Специалист по заправке и Инкассатор. На
рис. 7.2 показана модель прецедентов UML для автомата по продаже лимонада.
Рис. 7.2. Модель прецедентов для автомата по прода-
же лимонада (см. предыдущую главу)
98
Часть I. Начало
Отслеживание действий в сценариях
Каждый прецедент представляет собой набор сценариев, а каждый сценарий явля-
ется последовательностью шагов. Нужно отметить, что эти шаги не отражаются на
диаграмме. Нет их и в комментариях, связанных с прецедентами. Хотя в UML не за-
прещается отображать дополнительную информацию, при создании диаграммы нужно
добиваться доступности и ясности, а комментарии иногда только мешают. Как же от-
следить шаги выполнения сценария и где разместить пояснения по этому поводу?
Диаграмма прецедентов обычно представляет собой лишь часть документации, к
которой обращаются заказчик и разработчики системы. Каждая диаграмма должна
размещаться на отдельной странице. Сценарий прецедента тоже должен располагаться
на отдельной странице и содержать следующую информацию.
Исполнитель-инициатор прецедента.
Предположения для прецедента.
Предусловия для прецедента.
Последовательность шагов в сценарии.
Постусловия сценария.
Исполнитель, получающий пользу от прецедента.
Можно также привести перечень используемых предположений (например, авто-
матом по продаже лимонада покупатели пользуются по очереди) и краткое, размером
в одно предложение, его описание.
В главе 6, “Знакомство с прецедентами”, описаны альтернативные сценарии для
прецедента Покупка лимонада. В соответствии с этим описанием, альтернативные
сценарии можно рассматривать отдельно или в качестве исключений для первого сце-
нария прецедента. Все определяется удобством представления сценария для разработ-
чика, заказчика и пользователей.
Еще одна возможность
Для отображения шагов выполнения сценария в UML существует и другая возможность —
применение диаграммы видов деятельности UML Этот вопрос рассматривается в главе 11.
Визуализация взаимосвязей прецедентов
В главе 6 рассмотрены два типа взаимоотношений между прецедентами. Первый,
включение, позволяет повторно использовать шаги одного прецедента в другом. Вто-
рой, расширение, позволяет создавать новый прецедент путем добавления некоторых
шагов в существующий прецедент.
Существуют еще два способа взаимосвязи — обобщение (generalization) и группиро-
вание (grouping). Как и в случае классов, обобщение означает наследование одного
прецедента другим. Группирование — простой способ создания набора прецедентов.
Включение
Рассмотрим прецеденты Заправка автомата и Сбор денег. Они оба начинаются
с разблокирования и открытия автомата и заканчиваются закрытием и блокировкой.
Прецедент Проникновение внутрь включает первые два шага, а Выход наружу —
два остальных. Прецеденты Заправка автомата и Сбор денег включают в себя пре-
цеденты Проникновение внутрь И Выход наружу.
7-й час. Использование диаграмм прецедентов
99
Чтобы графически отобразить взаимосвязь включения, зависимость между класса-
ми обозначается в виде соединительной пунктирной линии со стрелкой, указывающей
на тот класс, от которого зависит другой. Прямо над линией вписывается стереотип —
слово <<включает>> в двойных прямых кавычках. На рис. 7.3 показано отношение
включения в модели прецедентов для автомата по продаже лимонада.
В текстовом описании указывается последовательность шагов и отмечаются вклю-
ченные прецеденты. Первый шаг прецедента Заправка автомата — это реализация
включенного прецедента (Проникновение внутрь).
Рис. 7.3. Модель прецедентов для автомата по продаже
лимонада с включением
Расширение
Прецедент Заправка автомата из рассмотренного в главе 6 примера может стать
основой для другого прецедента — Заправка с учетом спроса. В отличие от равно-
мерного пополнения запасов всех сортов сиропа, этот прецедент позволяет пополнять
автомат с учетом спроса. Новый прецедент будет расширять исходный, называемый
также базовым, за счет добавления новых шагов.
Расширение может происходить только в заданных точках последовательности
шагов базового прецедента. Такие места называются точками расширения. В прецеден-
те Заправка автомата новые шаги (поставки соответственно спросу) могут добав-
ляться, когда специалист по заправке открыл автомат и приступает к наполнению от-
секов для разных марок лимонада. Для этого примера точка расширения будет
“наполнять отсеки”.
Подобно включению, расширение отображается линией зависимости (пунктир со
стрелкой) со стереотипом <<расширяет>>. Внутри базового прецедента под его име-
100
Часть I. Начало
нем располагается точка расширения. На рис. 7.4 показан пример расширения для
прецедентов Заправка автомата и Заправка с учетом спроса, а также пример
включения для прецедентов Заправка автомата и Выход наружу
Рис. 7.4. Диаграмма прецедентов с отношениями включения
и расширения
Проникновение внутрь
Выход наружу
Важно понимать, что расположение прецедентов на диаграмме не играет роли.
Например, на рис. 7.4 прецедент Проникновение внутрь располагается выше, чем
прецедент Выход наружу. Но такое расположение никак не связано с порядком вы-
полнения прецедентов. Из общих соображений понятно, что сначала автомат откры-
вают, а затем закрывают, но в диаграмме прецедентов это никак не учитывается.
Иногда прецеденты на диаграмме нумеруют, чтобы определить порядок их следо-
вания. Но это очень хлопотно и малоэффективно.
Диаграмма прецедентов отображает только перечень возможных сценариев, но не
учитывает порядок их выполнения.
Расширение, включение и заблуждение
Из собственного опыта автор знает, что специалисты по моделированию процессов
(работающие со времен, когда UML не было и в помине) зачастую путаются в направлениях
стрелок, определяющих отношение зависимости. Непонимание возрастает, когда приходит-
ся моделировать расширение и включение прецедентов. Это заблуждение связано с тем,
что ветераны моделирования привыкли при помощи стрелок отражать последовательность
операций или видов деятельности. Две следующие друг за другом операции соединялись
линией со стрелкой, направленной от первой операции ко второй.
Поэтому, анализируя диаграммы прецедентов, на которых прецедент А включает преце-
дент Б, эти специалисты считают, что прецедент А происходит первым, а за ним следует
прецедент Б. Но во многих случаях, определяемых самой природой включения, все происхо-
дит в обратном порядке.
Важно понимать, что стрелки в отношениях зависимости определяют не направление про-
цесса, а направление взаимосвязи. Стрелка, ведущая от прецедента А к прецеденту Б озна-
чает, что А зависит от Б, а не А предшествует Б.
7-й час. Использование диаграмм прецедентов
101
Обобщение
Прецеденты, подобно классам, могут наследовать друг друга. При наследовании
дочерний прецедент наследует последовательность действий (behavior) от базового и
добавляет собственную очередность шагов. Дочерний прецедент можно применить
там, где применяется родительский.
Возвращаясь к примеру автомата по продаже лимонада, можно описать прецедент
Покупка стакана лимонада, который наследует свойства прецедента Покупка ли-
монада. Обобщение прецедентов, подобно обобщению классов, отображается на
диаграмме сплошной линией с незакрашенным треугольником, указывающим на ро-
дителя (рис. 7.5).
Покупка лимонада
д
Покупка бутылки лимонада
Покупка стакана лимонада
Рис. 7.5. Отношение обобщения существует не только
для классов, но и для прецедентов
Отношение обобщения может существовать также и между исполнителями. Спе-
циалиста по заправке автомата и инкассатора можно считать представителями по-
ставщика. В терминах модели Специалист по заправке и Инкассатор являются до-
черними объектами по отношению к объекту Представитель поставщика, что ото-
бражено на рис. 7.6.
Представитель
поставщика
о
О
Специалист Инкассатор
по заправке
Рис. 7.6. Подобно классам
и прецедентам исполните-
ли могут находиться во
взаимоотношениях обоб-
щения
102
Часть I. Начало
Группирование
Иногда диаграммы прецедентов получаются очень сложными, и возникает необхо-
димость сгруппировать изображенные на них прецеденты. Это может потребоваться,
если система состоит из множества подсистем или при интервьюировании пользова-
телей для формулирования требований к системе возникает потребность систематизи-
ровать те из них, которые определяются прецедентами.
Наиболее подходящим способом организации в этих случаях является группирова-
ние связанных прецедентов в пакеты. Вспомним, что пакет изображается в виде пап-
ки с закладкой. Сгруппированные прецеденты размещаются внутри этой папки.
Роль диаграмм прецедентов в процессе
анализа
В рассматриваемом примере обозначения прецедентов сразу применялись для по-
строения диаграмм. Давайте вернемся на шаг назад и рассмотрим использование пре-
цедентов в контексте анализа.
Процесс должен начинаться с интервьюирования. После обработки этих интервью
нужно построить диаграмму классов, которая станет основой базы сведений разработ-
чиков о предметной области разрабатываемой системы. Освоив общую терминологию
предметной области, разработчики будут готовы беседовать с пользователями.
Общение с пользователями начинается в терминологии предметной области сис-
темы, но затем следует перейти к терминологии пользователей. Результатом интервью
должно стать выявление исполнителей и высокоуровневых прецедентов, описываю-
щих функциональные требования в общих терминах. На основе этой информации
можно оценить рамки и масштаб системы.
В процессе дальнейшего общения с пользователями необходимо уточнить выяв-
ленные требования к системе и сформулировать прецеденты, подробно описав сцена-
рии и последовательность действий. На их основе можно модифицировать модель
прецедентов, выделяя отношения включения и расширения. На этом этапе очень
важно глубоко понимать предметную область (с помощью диаграмм классов, постро-
енных в процессе общения с заказчиком). Недостаточное знание предметной области
приведет к созданию избыточного количества прецедентов и отдельных деталей, а это
усложнит проектное решение и разработку системы.
Пример использования модели
прецедентов
Для того чтобы вы глубже поняли модели прецедентов и их применение, рассмот-
рим более сложный пример. Предположим, необходимо спроектировать локальную
вычислительную сеть (LAN) для консалтинговой фирмы и определить функциональ-
ность этой сети. С чего начать?
Так что же такое локальная сеть?
Локальной называется сеть, используемая на небольших расстояниях, например в пределах ор-
ганизации. Она позволяет пользователям совместно обращаться к ресурсам и информации.
7-й час. Использование диаграмм прецедентов
103
Изучение предметной области
Работа над системой начинается с общения с заказчиком и создания диаграммы
классов, отражающей предметную область консалтинга. Диаграмма классов может
включать следующие: Консультант, Клиент, Проект, Предложение, Данные И Отчет.
На рис. 7.7 представлен общий вид диаграммы.
Рис. 7.7. Диаграмма классов для предметной об-
ласти консалтинга
Работа с пользователями
Изучив предметную область, нужно переходить к работе с пользователями, потому
что в разрабатываемой системе должны поддерживаться выполняемые ими функции.
На практике для этого нужно интервьюировать пользователей. В рассматриваемом
примере будем опираться на общие знания о локальных сетях и предметной области
задачи. Однако при этом следует помнить, что в процессе системного анализа обще-
ние с реальными людьми ничем заменить нельзя.
Одна группа пользователей будет консультантами, в другую можно включить об-
служивающий персонал. Кроме того, потенциальными пользователями системы будут
руководители корпорации, маркетологи, сетевые администраторы, офисные менедже-
ры и менеджеры проектов. (Можете придумать других?)
На этом этапе полезно изобразить пользователей в иерархии обобщения, как это
сделано на рис. 7.8.
Описание прецедентов
А как же прецеденты? В процессе общения с пользователями системы можно вы-
явить следующие: Обеспечение безопасности, Создание предложения, Сохране-
ние предложения, Использование электронной почты, Совместное использова-
ние базы данных, Выполнение расчетов, Подключение к сети, Соединение с
Internet, Организация каталога предложений, Использование существующих
предложений, Совместное использование принтеров. На рис. 7.9 изображена
диаграмма высокоуровневых прецедентов, построенная на основании полученной ин-
формации.
Приведенный набор прецедентов определяет функциональные требования к ло-
кальной сети.
104
Часть I. Начало
о
Сотрудник
Консультант
Клерк
Руководитель Менеджер
корпорации
Офис-
менеджер
Менеджер
проекта
Администратор
сети
Рис. 7.8. Иерархия пользователей, кото-
рые будут взаимодействовать с локаль-
ной сетью
Уточнение деталей
Выберем один из высокоуровневых прецедентов и построим для него модель.
В консалтинговой фирме важнейшим видом деятельности является написание пред-
ложений, поэтому исследуем прецедент Создание предложения.
Интервью с консультантами позволит определить, что этот прецедент состоит из
некоторого количества шагов. Во-первых, инициирующим исполнителем является
консультант. Он должен зарегистрироваться в сети и пройти аутентификацию. Затем с
помощью офисных программ (текстового редактора, электронных таблиц и графиче-
ских приложений) консультант готовит предложения. Во время работы он может ис-
пользовать фрагменты созданных ранее предложений. Допустим, на фирме существу-
ет порядок, согласно которому один из ее руководителей и два других консультанта
должны просмотреть предложение перед отправкой клиенту. Чтобы выполнить это
требование, консультант загружает свое предложение в общее хранилище, доступное
через локальную сеть, и с помощью электронной почты сообщает трем сотрудникам о
готовности предложения и его местонахождении. Получив ответ и внеся необходимые
изменения (с помощью того же набора офисного программного обеспечения), кон-
сультант распечатывает предложение и отправляет его по почте клиенту. По оконча-
нии работы консультант отключается от сети. Теперь он закончил подготовку предло-
жения и является исполнителем, получающим выходную информацию прецедента.
7-й час. Использование диаграмм прецедентов
105
Рис. 7.9. Высокоуровневая диаграмма прецеден-
тов модели локальной сети для консалтинговой
фирмы
Бизнес-логика
Когда во время интервью обсуждается упомянутая выше политика “трех рецензий”, нужно
тщательно протоколировать такие подробности. Речь идет о бизнес-логике — наборе пра-
вил, определяющих организацию работы. Чем больше бизнес-правил вы сможете выявить,
тем более профессиональным аналитиком станете. Это позволит глубже понять принципы
работы и потребности организации-клиента.
106
Часть I. Начало
Из приведенного описания ясно, что некоторые шаги одного прецедента повторя-
ются в другом. Это наводит на мысль об использовании других (возможно, включен-
ных) прецедентов, о которых нельзя было догадаться раньше. Регистрация в сети и
проверка учетной записи — два шага, которые можно включить в другие прецеденты.
С этой точки зрения следует создать прецедент Регистрация пользователя, кото-
рый будет включен в прецедент Создание предложения. Два других включаемых
прецедента — Использование офисного программного обеспечения и Отключе-
ние от сети.
Предложение, написанное для нового клиента, естественно, отличается от тех, ко-
торые составлялись для постоянных клиентов. В самом деле, предложение для нового
клиента должно включать характеристику фирмы. Постоянным клиентам такого рода
информацию отправлять не нужно. Таким образом, новый прецедент Создание
предложения для нового клиента расширяет прецедент Создание предложения.
На рис. 7.10 представлена диаграмма, полученная по результатам анализа преце-
дента Создание предложения.
Создание предложения
для нового клиента
Рис. 7.10. Прецедент Создание предложения в системе локаль-
ной сети консалтинговой фирмы
Этот пример подтверждает достаточно важный момент, уже упомянутый ранее:
анализ прецедентов позволяет описать поведение системы. Он никоим образом не ка-
сается реализации. Это особенно важно подчеркнуть на данном этапе, потому что во-
просы разработки локальной сети выходят за рамки этой книги!
Подведение итогов
Настал момент рассмотреть общую структуру UML, потому что мы уже изучили
два его главных аспекта — объектно-ориентированный подход и анализ прецедентов.
Были рассмотрены основные принципы и обозначения, а также некоторые приложения.
В главах 2—7 введены следующие понятия:
класс;
объект;
интерфейс;
прецедент;
7-й час. Использование диаграмм прецедентов
107
исполнитель;
ассоциация;
обобщение;
зависимость;
реализация;
агрегация;
композит;
стереотип;
ограничение;
комментарий;
пакет;
расширение;
включение.
Попытаемся разделить этот набор на категории.
Структурные элементы
Классы, объекты, исполнители, интерфейсы и прецеденты — пять структурных
элементов UML. Хотя у них имеются отличия (которые в качестве упражнения следо-
вало бы перечислить), они подобны в том, что представляют физические либо концеп-
туальные части модели. Далее речь пойдет о дополнительных структурных элементах.
Взаимосвязи
Ассоциации, обобщения, зависимости, агрегации, композиты и реализации пред-
ставляют собой типы взаимосвязей в UML. (Включение и расширение представляют
собой два типа зависимости.) Без взаимосвязей модели UML были бы просто списком
структурных элементов. Взаимосвязи позволяют соединить эти элементы и, следова-
тельно, устанавливают связь модели с реальностью.
Группирование
Пакет — единственный элемент UML, предназначенный для группирования. Он
позволяет систематизировать структурные компоненты модели. Пакет может содер-
жать любые типы структурных элементов, в том числе различные типы элементов од-
новременно.
Аннотация
Комментарий — это элемент аннотации UML. Комментарии позволяют добавить к
моделям ограничения, заметки, требования и поясняющие рисунки.
Расширение
Стереотипы и ограничения — две конструкции UML, служащие для расширения
языка. Они позволяют создавать новые, не совпадающие с существующими, элемен-
ты. Благодаря этому модель более точно отражает реальность, в которой будет исполь-
зоваться разрабатываемая система.
108
Часть I. Начало
...И еще
Кроме структурных элементов, взаимосвязей, группирования, аннотирования и
расширения, в UML имеется еще одна категория — поведенческие элементы. Они
показывают изменение частей модели (таких, как объекты) во времени. Один из таких
элементов будет рассмотрен в следующей главе.
Общая картина
Теперь вы представляете себе, как организован UML. На рис. 7.11 эта организация
отображена в графическом виде. Ее следует постоянно помнить. По мере дальнейшего
изучения к уже указанной общей картине будут добавляться новые детали.
Структурные Элементы
Исполнитель
Взаимосвязи
Ассоциация
Обобщение
Зависимость
Реализация
Рис. 7.11. Организация
UML в терминах рассмот-
ренных элементов
Резюме
Прецедент — мощное средство для формирования функциональных требований к
системе. Диаграммы прецедентов — еще более мощный инструмент: они визуализи-
руют прецеденты, служат основой для взаимодействия между аналитиками и пользо-
вателями, а также между аналитиками и клиентами. На диаграмме прецедент обозна-
7-й час. Использование диаграмм прецедентов
109
чается эллипсом. Исполнители обозначаются упрощенной фигуркой. Линия ассоциа-
ции соединяет исполнителя с прецедентом. Обычно прецеденты располагаются внут-
ри прямоугольника, отображающего границы системы.
Включение представляется линией зависимости со стереотипом <<включает>>.
Два других типа взаимосвязи прецедентов — это обобщение, при котором один пре-
цедент наследует значение и поведение другого, и группирование, позволяющее сис-
тематизировать набор прецедентов. Обозначение обобщения на диаграмме совпадает с
обозначением наследования для классов. Группирование изображают с помощью па-
кетов.
Диаграммы прецедентов активно используются в процессе анализа. Сначала на ос-
нове общения с заказчиком строятся диаграммы классов, обеспечивающие основу для
интервьюирования пользователей. В результате предлагается высокоуровневая диа-
грамма прецедентов, которая отражает функциональные требования к системе. Для
создания моделей прецедентов нужно детально изучить каждый высокоуровневый
прецедент. На основе полученных моделей прецедентов выполняется проектирование
и разработка системы.
Объектно-ориентированный подход и прецеденты — два краеугольных камня
UML. Ознакомившись с ними, нетрудно сформировать общую структуру UML. Эле-
менты, изученные в главах 2—7, можно разделить на следующие категории: структур-
ные элементы, взаимосвязи, средства группирования, аннотации и расширение. В
следующей главе будет рассмотрен элемент одной из поведенческих категорий. Общая
структурная схема UML поможет в дальнейшем изучении этого языка.
Вопросы и ответы
Я заметил, что на высокоуровневых диаграммах прецедентов не показаны ассоциации
между исполнителями и прецедентами. Почему?
Высокоуровневая диаграмма прецедентов строится на ранней стадии общения с
пользователями. Это некое умственное упражнение, его цель — выявление общих
требований и границ, в которых будет действовать система. Ассоциации приобретают
смысл, когда разработчик глубоко разобрался в каждом требовании. Тогда модели
прецедентов приобретают законченный вид.
В контексте анализа прецедентов вы упоминали бизнес Г логику. Только ли здесь она
используется?
Не только. Информация о бизнес-логике может понадобиться на всех стадиях
процесса разработки.
Почему важно понимать общую картину UML? Нельзя ли просто выучить, когда исС
пользовать каждый тип диаграммы?
Поняв организацию UML, вы сможете разобраться в новых задачах и распознать
ситуацию, когда существующий элемент UML не выполняет требуемую функцию. В
этом случае нужно сконструировать новый элемент. Вы также сможете создать сме-
шанную диаграмму (которая содержит набор разнотипных элементов UML), если это
единственный способ представить модель в понятной форме.
Практические занятия
Активизируем знания, полученные в главах 6 и 7. Ответьте на несколько вопросов
и выполните упражнения, чтобы закрепить знания о диаграммах прецедентов. Ответы
содержатся в приложении А.
110
Часть I. Начало
Тесты
1. Назовите два преимущества визуализации прецедентов.
2. Опишите обобщение и группирование — взаимосвязи прецедентов, изученные
в этой главе. Назовите две ситуации, требующие группирования прецедентов.
3. В чем сходство классов и прецедентов? В чем их отличия?
4. Как промоделировать включение и расширение?
Упражнения
1. Набросайте эскиз диаграммы прецедентов пульта дистанционного управления
телевизора. Не забудьте в качестве прецедентов включить все функции пульта.
2. Во втором упражнении предыдущей главы были перечислены исполнители и
прецеденты компьютерного супермаркета. Постройте высокоуровневую диа-
грамму прецедентов, основанную на полученных тогда результатах. Затем соз-
дайте модель хотя бы для одного высокоуровневого прецедента. Постарайтесь
использовать взаимосвязи <<включает>> и <<расширяет>>.
3. Вспомните, как происходит покупка товаров в супермаркете. Разработайте мо-
дель устройства, устраняющего некоторые неудобства, связанные с этим ме-
роприятием, и модель прецедентов для этого устройства. В наборе прецеден-
тов при необходимости используйте отношения включения, расширения и
обобщения.
7-й час. Использование диаграмм прецедентов
111
8-й час
Диаграммы состояний
1/1з этого часа вы узнаете
> Что такое диаграмма состояний и как с ней работать
> Что такое события, действия и условия перехода
> Как моделировать подчиненные состояния, историю состояний и точки соединения
Эта глава будет посвящена новой категории элементов, которая позволяет описать
поведение системы и показать, как части модели UML изменяются во времени. К од-
ной из таких категорий относятся элементы диаграммы состояний.
Появляются новые стили одежды и новые модели автомобилей, в течение года из-
меняется цвет листьев на деревьях, подрастают дети. Попросту говоря, с течением
времени происходят события и изменяются объекты вокруг нас.
То же самое можно сказать и о любой системе. Когда она взаимодействует с поль-
зователями и (возможно) с другими системами, составляющие ее объекты претерпе-
вают определенные изменения, чтобы система могла выполнять свои функции. По-
этому, построив модель системы, необходимо определить механизм изменения этой
модели.
Что такое диаграмма состояний
Изменения в системе можно охарактеризовать так: объекты изменяют свое состоя-
ние в ответ на происходящие события и с течением времени. Вот несколько простых
примеров.
При щелчке на выключателе освещение меняет свое состояние с “Выклю-
чено” на “Включено”.
При щелчке на кнопке пульта дистанционного управления телевизор изме-
няет свое состояние и показывает передачи другого канала.
По истечении заданного времени стиральная машина изменяет свое состоя-
ние со “Стирка” на “Полоскание”.
Диаграмма состояний UML охватывает приведенные выше типы изменений. Она
представляет состояния объекта и переходы между ними, а также показывает началь-
ное и конечное состояние объекта.
Диаграммы состояний и чертежи
В контексте диаграммы состояний аналогия между моделями UML и чертежами нарушается.
Чертеж показывает, как будет выглядеть дом по завершении строительства. Однако из него
не видно, в каком месте прохудится крыша, где возникнет трещина в стене и как начнут
ржаветь металлические части дома. Диаграмму состояний иногда называют автоматом со-
стояний, поскольку она отражает все эти изменения.
Запомните, что диаграмма состояний по своей сути значительно отличается от
диаграммы классов, диаграммы объектов или диаграммы прецедентов, и это отличие
очень важно. Изученные ранее диаграммы моделируют поведение всей системы или
группы классов, объектов или прецедентов. Диаграмма состояний показывает состоя-
ния одного объекта.
Некоторые соглашения
Имя состояния всегда начинается с прописной буквы. Состояниям желательно присваивать
имена, указывающие на действие (а для английских имен выбирать существительные с
Окончанием “ing”), например Набор номера (Dialing), Отправка факса
(Faxing). Иногда это невозможно (состояние ожидания по-английски idle).
Основные обозначения
На рис. 8.1 состояние показано в виде прямоугольника со скругленными углами, а
переход между состояниями — сплошной линией со стрелкой. Она указывает на со-
стояние, в направлении которого происходит переход. Закрашенный круг символизи-
рует начальную точку, а “глазок” — конечную.
Рис. 8.1. Основные обозначения UML для
диаграммы состояний. Состояние изо-
бражается прямоугольником со скруг-
ленными углами, переход — сплошной ли-
нией со стрелкой. Закрашенный круг со-
ответствует начальной точке последо-
вательности состояний, а обведенный
круг (“глазок”) представляет конечную
точку
8-й час. Диаграммы состояний
113
Дополнительные элементы в изображении
состояния
UML дает возможность добавлять необходимые детали к изображению состояния.
Подобно выделению трех областей в обозначении класса (для имени, атрибутов и
операций), изображение состояния тоже можно разделить на две области. Верхняя со-
держит имя состояния (которое нужно присвоить независимо от того, будут ли при-
сутствовать другие элементы обозначения), а нижняя предназначена для размещения
видов деятельности. Эти области показаны на рис. 8.2.
К стандартным видам деятельности относятся вход (что происходит, когда система
входит в рассматриваемое состояние), выход (система выходит из рассматриваемого
состояния) и выполнение (система находится в рассматриваемом состоянии). По мере
необходимости можно добавлять и другие виды деятельности.
Факс является примером объекта, состояние которого характеризуется определен-
ными видами деятельности. При отправке факса (состояние Отправка факса) указы-
вается дата, время отправки, телефонный номер и имя отправителя. Другими видами
деятельности в этом состоянии являются протяжка бумаги, разделение факса на стра-
ницы и завершение передачи.
Находясь в состоянии ожидания, факс-машина отображает на дисплее текущую
дату и время. Диаграмма состояний этого объекта приведена на рис. 8.3.
Рис. 8.2. Графическое изобра- Рис. 8.3. Факс — объект, состояние которого ха-
жение состояния можно раз- рактеризуется видами деятельности
делить на области, содержа-
щие имя состояния и виды
деятельности
114
Часть I. Начало
Дополнительные обозначения для переходов:
события и действия
К линиям перехода можно добавить дополнительные детали. Например, можно
указать событие, которое привело к переходу {переключающее событие), и выполняе-
мые вычисления {действия), которые приводят к изменению состояния. Чтобы доба-
вить события и действия, нужно записать их возле линии перехода, отделяя друг от
друга косой чертой. Иногда событие вызывает переход без всякого действия, иногда
же переход происходит из-за того, что в текущем состоянии выполнены все действия
(не из-за события). Такой тип перехода называется безусловным переходом.
Переходы между состояниями можно рассмотреть на примере графического поль-
зовательского интерфейса (GUI) компьютера. Предположим, интерфейс может нахо-
диться в одном из трех состояний.
Инициализация.
Работа.
Завершение работы.
При включении компьютера происходит загрузка. Поэтому включение компьютера
является переключающим событием, которое приводит к переходу интерфейса в со-
стояние Инициализация, а загрузка — действие, происходящее во время перехода.
Результатом выполнения действий в состоянии инициализации является выработ-
ка переключающего события, которое вызывает переход в состояние Работа. При
щелчке на кнопке завершения работы осуществляется переход в состояние Заверше-
ние работы, и в конечном итоге компьютер выключается. На рис. 8.4 показана диа-
грамма, представляющая состояния и переходы для пользовательского интерфейса.
Рис. 8.4. Состояния и переходы графического пользовательского интер-
фейса с указанием переключающих событий, действия и безусловных пе-
реходов
Дополнительные обозначения для переходов:
условия переходов
Предыдущий пример с графическим пользовательским интерфейсом значительно
упрощен. Во-первых, если на компьютере не выполняются никакие действия, активи-
зируется экранная заставка. В терминах изменения состояний эту ситуацию можно
охарактеризовать так. Если по истечении заданного интервала времени не наблюдает-
ся активности пользователя, пользовательский интерфейс переходит из состояния Ра-
бота в состояние Отображение заставки, не показанное на рис. 8.4.
Временной интервал, по истечении которого происходит включение заставки, за-
дается с помощью панели управления Windows. Обычно он составляет 15 минут. Лю-
бое нажатие клавиши или перемещение указателя мыши переключает монитор из со-
стояния Отображение заставки в состояние Работа.
8-й час. Диаграммы состояний
115
Этот пятнадцатиминутный интервал времени и является условием перехода — когда
это время истекает, осуществляется переход. На рис. 8.5 представлена более полная
диаграмма состояний GUI с состоянием Отображение заставки и условием перехода.
Рис. 8.5. Диаграмма состояний графического пользовательского интер-
фейса с состоянием Отображение заставки и условием перехода
Подчиненные состояния
В приведенной модели GUI чего-то не хватает. Состояние Работа, в частности,
является более сложным по сравнению с изображенным на рис. 8.4 и 8.5.
Когда GUI находится в состоянии Работа, выполняется много действий, но не все
они отражаются на экране. Интерфейс GUI постоянно ожидает действий пользовате-
ля — нажатия клавиш, перемещения указателя мыши или щелчка на кнопке. При вы-
полнении таких действий интерфейс должен зарегистрировать событие и изменить
содержимое экрана, чтобы отобразить действия пользователя, например переместить
указатель при движении мыши или вывести символ “а” при нажатии клавиши <а>.
Находясь в состоянии Работа, GUI-интерфейс претерпевает внутренние измене-
ния состояния. Поскольку такие состояния относятся к одному более общему состоя-
нию, они называются подчиненными. Существует два типа подчиненных состояний:
последовательные и параллельные.
Последовательные подчиненные состояния
Как следует из названия, такие состояния наступают одно за другим. Переходы
подчиненных состояний GUI в рамках состояния Работа могут выполняться в сле-
дующей последовательности.
Ожидание ввода пользователя.
Регистрация ввода пользователя.
Визуализация ввода пользователя.
Ввод информации пользователем обеспечивает переход из состояния Ожидание
ввода пользователя к состоянию Регистрация ввода пользователя. Выполнение
действий в состоянии Регистрация ввода пользователя переводит пользователь-
ский интерфейс в состояние Визуализация ввода пользователя. После выполне-
ния всех действий в третьем состоянии GUI-интерфейс возвращается в состояние
Ожидание ввода пользователя. На рис. 8.6 показано, как представить последова-
тельные подчиненные состояния в состоянии Работа.
116
Часть I. Начало
Рис. 8.6. Последовательные подчиненные состояния GUI-интерфейса для состояния Ра-
бота
Параллельные подчиненные состояния
Находясь в состоянии Работа, GUI-интерфейс не просто ожидает действий поль-
зователя. Он также отслеживает системное время и, возможно, обновляет экран по
истечении заданного интервала времени. Например, на экране могут отображаться ча-
сы, изображение которых должно регулярно обновляться.
Эти действия происходят одновременно с последовательностями, о которых шла
речь в предыдущем разделе. Хотя каждая последовательность является набором после-
довательных подчиненных состояний, две последовательности переходов происходят
параллельно. Параллельные последовательности переходов изображаются пунктирной
линией, как показано на рис. 8.7.
Рис. 8.7. Параллельные подчиненные состояния наступают од-
новременно. Графически они разделяются пунктирной линией
8-й час. Диаграммы состояний
117
Выделение в состоянии Работа двух компонентов напоминает об изученных ранее
отношениях агрегации и композитных объектах. Если каждый компонент является
частью только одного “целого”, речь идет о композитном объекте. Параллельные час-
ти состояния Работа связаны с этим состоянием таким же отношением. С этой точки
зрения состояние Работа является композитным. Состояние, включающее только по-
следовательные подчиненные состояния, также называется композитным.
История состояний
Что происходит, если при отображении заставки пользователь нажимает клавишу
или перемещает указатель мыши, чтобы вернуть экран в состояние Работа? Возвра-
щается ли экран к исходному состоянию, наступающему сразу же после инициализа-
ции GUI-интерфейса? Или же на экране отражается последнее состояние, предшест-
вующее моменту включения заставки?
Очевидно, что в первом случае пользователь потеряет время и выполненную рабо-
ту и вынужден будет повторить ее.
Диаграмма состояний позволяет учесть такую особенность. В UML применяется
специальное обозначение, указывающее на то, что в композитном состоянии запоми-
нается активное промежуточное состояние во время выхода объекта из композитного
состояния. Это символ н, заключенный в небольшой круг и соединенный сплошной
линией со стрелкой с запоминаемым подчиненным состоянием. На рис. 8.8 это обо-
значение введено для отображения состояния Работа.
[время истекло]
Рис. 8.8. История состояний, обозначенная символом н в небольшом круге, показывает,
что композитное состояние запоминает свое активное промежуточное состояние при
выходе объекта из этого композитного состояния
На рассматриваемой диаграмме не принимались во внимание окна, которые от-
крываются в других, — вложение состояний в иные подчиненные состояния. Если за-
поминаются подчиненные состояния всех уровней вложенности (как для подчинен-
118
Часть I. Начало
ных состояний Работа окон состояния Работа), то история состояний называется
глубокой. Если запоминается только самое верхнее подчиненное состояние, история
считается мелкой. Для глубокой истории в кружочке отображается надпись н*.
Новое в UML 2.0
В UML 2.0 появились новые обозначения, связанные с состояниями. Это точки
соединения. Они представляют точки входа в состояние и выхода из него.
Приведем пример. Представим себе два состояния книги в библиотеке. В одном из
них книга стоит на полке. Если читатель закажет книгу, библиотекарь принесет ее в
читальный зал, и книга перейдет в состояние Заказ. Если читатель придет в библио-
теку, найдет книгу на полке и запишет ее в свой формуляр, она тоже перейдет в со-
стояние Заказ, но несколько иным способом. Считается, что в этих двух ситуациях
книга переходит в состояние Заказ через разные точки входа.
Если читатель превысил лимит заказанных книг или просто решил вернуть книгу в
библиотеку, то книга выйдет из состояния Заказ через точку выхода.
На рис. 8.9 показана модель этой ситуации на языке UML. Каждая точка входа на
диаграмме обозначена незакрашенным кружочком. Точка выхода показана кружочком
с крестиком внутри. В обоих случаях кружочки размещаются на границе обозначения
состояния.
Хранение
на полке
[заказана]
завершение
у' использования
Рис. 8.9. Точки входа и выхода на диаграмме состояний
UML
Зачем нужны диаграммы состояний
На диаграмме состояний отображаются все переходы между состояниями одного
объекта системы. Если информация слишком детализирована, то диаграмма вскоре
слишком усложнится. Нужно ли это?
Оказывается, нужно. Диаграммы состояния используются аналитиками, проекти-
ровщиками и разработчиками для исследования поведения объектов в системе. Диа-
грамма классов и соответствующая диаграмма объектов отображают только статиче-
ское состояние системы. На них представлены иерархии и ассоциации, и из них
можно узнать о возможном перечне действий системы, но ничего нельзя узнать о де-
талях динамического поведения.
Однако разработчики должны понимать поведение объектов, поскольку их задачей
является реализация этого поведения в программном обеспечении. Просто разрабо-
тать объект недостаточно: специалисты должны добиваться того, чтобы объект выпол-
нял свои функции. Диаграммы состояний дают полную информацию о желаемом по-
ведении. Ясное представление о поведении объекта повышает вероятность того, что
группа разработчиков создаст систему, удовлетворяющую выдвинутым требованиям.
8-й час. Диаграммы состояний
119
Дополнение к общей картине
Теперь в общую картину UML можно добавить “поведенческие элементы”. На
рис. 8.10 представлена общая картина UML с добавленными к ней элементами диа-
граммы состояний.
Структурные элементы
Поведенческие элементы
Класс
Состояние
о
Интерфейс
Исполнитель
Взаимосвязи
Группировка
Пакет
Ассоциация
Обобщение
Зависимость
Реализация
Расширение
<<стереотип>>
{ограничение}
Аннотация
Примечание
Рис. 8.10. Общая картина UML теперь включает поведенче-
ский элемент — диаграмму состояний
Резюме
С течением времени и в ответ на события состояние объектов в системе изменяет-
ся. Эти изменения отражает диаграмма состояний UML. На ней изображаются пере-
ходы между состояниями одного объекта. Состояние графически представляется пря-
моугольником со скругленными углами, а переход из одного состояния в другое изо-
бражается линией со стрелкой.
Обозначение состояния содержит его имя и может включать набор действий, вы-
полняемых в контексте этого состояния. Переход зачастую происходит в ответ на пе-
реключающее событие и может вызывать выполнение некоторых действий. Переход
также может происходить вследствие выполнения необходимых действий в предыду-
щем состоянии: он называется безусловным. Наконец, переход может происходить в
случае выполнения специальных условий — так называемых условий перехода.
Иногда состояние складывается из подчиненных состояний, которые могут быть
последовательными (т.е. происходят друг за другом) или параллельными (происходят
120
Часть I. Начало
одновременно). Состояние, включающее подчиненные состояния, называется компо-
зитным. История состояния показывает, что композитное состояние запоминает свое
промежуточное состояние, когда объект из него выходит. Мелкая история подразуме-
вает запоминание только одного подчиненного состояния. Глубокая история включает
все уровни вложенности состояний.
В UML 2.0 появились символы, обозначающие точки соединения — точки входа в
состояние и выхода из него.
Диаграммы состояний важны для аналитиков, проектировщиков и разработчиков,
поскольку они позволяют понять поведение объектов системы. Разработчики, в част-
ности, должны знать о предполагаемом поведении объектов в системе, чтобы про-
граммно реализовать это поведение. Не достаточно реализовать сам объект — нужно
добиться, чтобы объект выполнял свои функции.
Вопросы и ответы
С чего начинать построение диаграмм состояний?
Процесс создания диаграмм состояний напоминает создание диаграммы классов
или прецедентов. В диаграмме классов сначала перечисляются все классы, а затем оп-
ределяются ассоциации. В диаграмме состояний сначала отображаются все состояния
объекта, а затем строятся переходы. Анализируя переходы, можно добавить в диа-
грамму переключающие события и происходящие действия.
Нужно ли каждую диаграмму состояний завершать конечным состоянием (“глазком”)?
Нет. Объект, который никогда “не выключается”, не имеет такого состояния.
Существуют ли какие Снибудь рекомендации по построению диаграммы состояний?
Старайтесь располагать состояния и переходы таким образом, чтобы минимизиро-
вать пересечение линий. Одной из задач такой диаграммы (и любой другой) является
прояснение и структурирование известной информации. Если разработчики не в со-
стоянии понять построенную модель, они не будут ее использовать, и все усилия
окажутся напрасными.
Практические занятия
Ответив на вопросы и выполнив упражнения, вы перейдете в состояние Диаграм-
мы состояний изучены. Как всегда, ответы можно найти в приложении А.
Тесты
1. Какое важное отличие существует между диаграммами состояний и диаграм-
мами классов, объектов или прецедентов?
2. Дайте определение терминов переход, событие и действие.
3. Что такое безусловный переход!
4, Чем отличаются последовательные и параллельные подчиненные состояния?
8-й час. Диаграммы состояний
121
Упражнения
1. Предположим, вы проектируете тостер. Создайте диаграмму состояний, кото-
рая отслеживает состояния хлеба в тостере. Используйте необходимые пере-
ключающие события, действия и условия переходов.
2. На рис. 8.7 показаны параллельные подчиненные состояния для состояния
GUI-интерфейса Работа. Постройте диаграмму состояния Отображение за-
ставки, которая включала бы параллельные подчиненные состояния.
3. На рис. 8.9 показаны два состояния, в которых может пребывать библиотечная
книга. Используя свой опыт посещения библиотеки, дополните эту диаграм-
му, включив в нее остальные возможные состояния. Не забудьте о подчинен-
ных состояниях и условиях перехода.
122
Часть I. Начало
9-й час
Диаграммы последовательностей
Из этого часа вы узнаете
> Что такое диаграмма последовательностей
> Как применять диаграммы последовательностей
> Как моделировать создание объекта
> Как использовать новые элементы диаграммы последовательностей в UML 2.0
> Как диаграммы последовательностей вписываются в общую картину UML
Диаграммы состояний, изученные в предыдущей главе, отражают изменение со-
стояний одного объекта.
Однако UML позволяет расширить поле обозрения и показать взаимодействие
объектов друг с другом. В это расширенное поле включается важное измерение: вре-
мя. Основная идея сводится к тому, что взаимодействие объектов происходит в задан-
ной последовательности, и для выполнения этой последовательности от начала до
гонца требуется время. Такая последовательность задается в процессе разработки сис-
темы, и для ее отображения используется диаграмма последовательностей UML.
Что такое диаграмма
последователь н осте й
Диаграмма последовательностей состоит из обычных объектов, представленных в
аде прямоугольников (с подчеркнутыми именами), сообщений, изображенных
сплошными линиями со стрелками, а также вертикальной оси времени, определяю-
щей последовательность событий.
Объекты
Объекты располагаются в верхней части диаграммы слева направо. Порядок распо-
ложения может быть произвольным; он определяется лишь одним требованием: диа-
грамма должна быть простой.
Пунктирная вертикальная линия, расположенная под каждым объектом, называется
линией жизни (li'eline) этого объекта. Вдоль линии жизни располагаются узкие прямо-
угольники, называемые точками активации. Точка активации представляет выполнение
объектом некоторой операции. Длина этого прямоугольника соответствует длительности
процесса активации. На рис. 9.1 показаны объект, линия жизни и точка активации.
: Имя
I
в
I
Рис. 9.1. Представление объекта на
диаграмме последовательностей
Сообщения
Сообщения, передаваемые от одного объекта другому, на диаграмме изображаются
в виде линий, соединяющих линии жизни этих объектов. Объект может передать со-
общение самому себе, т.е. между своими же линиями жизни.
В UML сообщение представляется в виде линии со стрелкой, которая начинается
от линии жизни одного объекта и заканчивается на линии жизни другого. Форма
стрелки определяет тип сообщения. В UML 1.x существовали три вида стрелок.
В UML 2.0 один из видов стрелок не используется, что, по мнению автора, приводит
к путанице. Сначала мы поговорим о сообщениях, а потом рассмотрим, как их пред-
ставление изменилось в UML 2.0.
Первый тип сообщений называется вызовом. Это запрос объекта-отправителя к объек-
ту-получателю на выполнение одной из его операций. Обычно отправитель ожидает за-
вершения выполнения операции. Поскольку в этом случае отравитель “синхронизирует”
свои действия с получателем, такой тип сообщения называется синхронным.
Рис. 9.2. Обозначения
для вызова и ответа
UML
Неоднозначный ответ
Несколько слов об обозначении ответного сообщения. Во-первых, оно может ввести в за-
блуждение, поскольку очень напоминает обозначение отношения зависимости. Во-вторых,
глубже ознакомившись с UML, можно обнаружить несколько видов обозначений для этого
типа сообщения. В документации по UML 1.x это сообщение иногда изображают линией с
обычной стрелкой на конце, а иногда — линией с треугольным наконечником, как в сообще-
нии вызова. В UML 2.0 используется обозначение, показанное на рис. 9.2. Его мы и будем
придерживаться в этой книге.
124
Часть I. Начало
Еще один вид сообщения — асинхронное. В этом случае отправитель передает
управление получателю и не ожидает ответа для продолжения выполнения своих дей-
ствий. На диаграмме последовательностей линия асинхронного сообщения дополня-
ется обычной стрелкой, как показано на рис. 9.3.
Рис. 9.3. Символ асинхронного
сообщения в UML
Отсутствующая стрелка
В UML 1.x существовало еще одно обозначение сообщения — линия с половинной стрелкой
(представьте себе обозначение, показанное на рис. 9.3, у которого отсутствует одна поло-
винка стрелки. В UML 1.x оно использовалось для отображения асинхронного сообщения).
В предыдущих версиях асинхронное сообщение и сообщение о передаче управления разде-
лялись, но на самом деле граница между ними весьма размыта. Поэтому мы будем исполь-
зовать обозначения UML 2.0, показанные на рис. 9.2 и 9.3.
Время
Время на диаграмме изменяется вдоль вертикального направления. Начало отсчета
находится вверху, а увеличение происходит сверху вниз. Сообщения, находящиеся
ближе к верхней части, передаются раньше по времени, чем сообщения в нижней
части диаграммы.
Таким образом, диаграмма последовательности имеет два измерения. Слева напра-
во размещаются объекты, а сверху вниз отображается время.
На рис. 9.4 показан основной набор обозначений диаграммы последовательности.
Объекты располагаются в верхней части. Каждая линия жизни объекта изображается
пунктирной линией, проходящей от объекта вниз. Сплошная линия со стрелкой, со-
единяющая одну линию жизни с другой, соответствует передаче сообщения от одного
объекта к другому.
: Имя1
:Имя2
Рис. 9.4. Обозначения
диаграммы последователь-
ности
Давайте попытаемся практически использовать это важное средство UML в при-
ложениях. При этом нам придется поработать с некоторыми концепциями объектно-
ориентированного подхода, которые составляют основу диаграмм последовательно-
стей, а именно — с классами.
9-й час. Диаграммы последовательностей
125
Автомобили и ключи
Думаю вы знакомы со специальным видом ключей для автомобиля, которые по-
зволяют закрывать его на расстоянии. С помощью такого ключа можно также откры-
вать багажник машины. Если у вас есть такой ключ, то вам не нужно объяснять, что
происходит, когда вы нажимаете кнопку Lock (закрыть). Машина закрывается, мигает
фарами и подает звуковой сигнал, свидетельствующий о том, что все двери закрыты.
Диаграмма классов
Давайте изобразим эту ситуацию на диаграмме классов. На рис. 9.5 показаны
взаимосвязи между классами ВладелецАвтомобиля, Автомобиль, Ключ.
Класс Автомобиль соответствующим образом обрабатывает сообщение, отправ-
ляемое классом Ключ.
ВладелецАвтомобиля
имя
датаРождения
адрес
номерЛицензии
ехать()
припарковаться()
<<сигнал>> МигнутьФарами
«сигнал>> ЗвуковойСигнал
Ключ
идентификатор
нажатьКнопку(к:ИмяКнопки)
Кнопочная Беспроводное
Панель Соединение
Рис. 9.5. Взаимосвязи между классами ВладелецАвтомобиля, Автомобиль и Ключ
Остановимся на этой диаграмме. В обозначении класса Ключ показана сигнатура
операции нажатьКнопку (). Параметром этой операции является имя кнопки: за-
крыть, открыть или открытьБагажник. Класс Автомобиль получает сообщение от
класса Ключ, обрабатывает его и выполняет операцию, соответствующую имени нажа-
той кнопки.
На диаграмме также показаны два сигнала: МигнутьФарами и ЗвуковойСигнал.
Сигнал изображается как класс с ключевым словом <<сигнал>>. Линии зависимости,
связывающие класс Автомобиль с каждым из сигналов, свидетельствуют о том, что
автомобиль передает эти сигналы. Однако в UML нет обозначения для отношения
передачи, поэтому здесь используется символ отношения зависимости с ключевым
словом <<передает>>.
Заметим, что в обозначении класса ВладелецАвтомобиля использованы два новых
элемента с ключевым словом <<сигнал>>. Они означают, что владелец автомобиля
может получать эти сигналы. Получение сигналов не требует выполнения каких-либо
действий. Поскольку класс-отправитель Автомобиль при передаче сигналов не пере-
дает никакого запроса, то он и не требует действий от класса ВладелецАвтомобиля.
Следовательно, на диаграмме последовательностей сигналы будут моделироваться
асинхронными сообщениями.
126
Часть I. Начало
Диаграмма последовательностей
Показанная на рис. 9.5 диаграмма классов — это статическое представление из
мира автомобилей. Диаграмма последовательностей обеспечивает его динамическое
представление, отображая передачу сообщений между соответствующими классами.
Сначала изобразим три объекта: экземпляр класса ВладелецАвтомобиля, предста-
витель класса Ключ и объект класса Автомобиль. Расположим их в верхней части
диаграммы и проведем от каждого из них линию жизни (рис. 9.6).
Рис. 9.6. Начало диаграммы последовательностей
Анонимные объекты
Несложно заметить, что объекты на диаграмме последовательностей (рис. 9.6) не имеют
конкретных имен (например, мойАвтомобиль: Автомобиль). Как вы помните из гла-
вы 3, “Использование концепций объектно-ориентированного проектирования”, такие объек-
ты называются анонимными.
Затем добавим сообщения, соединяющие линии жизни объектов (рис. 9.7). Первое
сообщение (самое верхнее) — это запрос объекта класса ВладелецАвтомобиля к объ-
екту класса Ключ на выполнение операции нажать Кнопку () для соответствующей
кнопки к. Форма стрелки свидетельствует о том, что объект класса ВладелецАвтомо-
биля передает управление объекту класса Ключ.
М час. Диаграммы последовательностей
127
Затем объект класса Ключ передает сообщение объекту класса Автомобиль на вы-
полнение операции обработатьСообщение () для соответствующей кнопки. После
обработки этого сообщения объект класса Автомобиль передает себе сообщение на
выполнение операции, соответствующей нажатой кнопке. Обратите внимание на вы-
ражение в квадратных скобках. Это условие перехода, о котором речь шла в главе 8,
“Диаграммы состояний”. Таким образом, в случае нажатия кнопки “Закрыть” авто-
мобиль передает самому себе запрос на выполнение операции закрыть (). Затем ав-
томобиль передает два сигнала владельцу. Первое сообщение и сигналы — примеры
использования обычной стрелки.
Из этого примера видно назначение диаграммы последовательностей — моделиро-
вание взаимодействия между объектами предметной области, определяемыми диа-
граммой классов. В следующем примере показан еще один контекст применения
диаграммы последовательностей.
Автомат по продаже лимонада
Рассмотрим более сложный пример. В главах 6 и 7 описаны прецеденты для моде-
ли автомата по продаже лимонада. Напомним, что прецедент — это набор сценариев.
Диаграмма последовательностей позволяет моделировать сценарии прецедента.
Построим модель сценариев прецедента Покупка лимонада.
Как и в предыдущем примере, начнем с построения диаграммы классов, модели-
рующей элементы автомата для продажи лимонада. Для упрощения задачи предполо-
жим, что в реализации этого сценария участвуют три объекта: лицевая панель, реестр
для сбора монет, а также отсек для хранения лимонада и его передачи на лицевую па-
нель. Разработчики автомата, конечно, скажут, что такое представление слишком уп-
рощено, но для нашего примера этого достаточно.
В модели автомата лицевая панель выполняет следующие функции:
принимает монеты и заказ;
отображает приглашения;
получает сдачу от реестра и возвращает ее покупателю;
возвращает монеты;
получает лимонад из отсека, где он хранится, и передает его покупателю.
Реестр выполняет следующие действия:
получает заказ покупателя (деньги и сорт лимонада) от лицевой панели;
считает деньги;
находит сдачу.
Отсек для хранения лимонада выполняет операции:
проверяет наличие выбранного сорта лимонада;
выдает стакан напитка.
Рассмотрим автомат для продажи лимонада как агрегат, содержащий эти три ком-
понента. На рис. 9.8 показана соответствующая диаграмма классов.
Промоделируем основной успешный сценарий прецедента Покупка лимонада:
покупатель бросает в автомат нужную сумму и выбирает марку лимонада. Поскольку
речь идет об основном успешном сценарии, в автомате имеется по крайней мере один
стакан лимонада нужного сорта, который и предлагается покупателю. Последователь-
ность действий по реализации сценария будет следующей.
1. Покупатель помещает монету в щель на лицевой панели автомата и выбирает
сорт лимонада.
128
Часть I. Начало
2. Монета попадает в реестр, который ее обрабатывает.
3. Для рассматриваемого основного сценария считаем, что нужный сорт лимона-
да имеется и реестр дает команду отсеку доставить лимонад к лицевой панели
автомата.
Рис. 9.8. Модель автомата по продаже лимонада
На рис. 9.9 показана диаграмма последовательностей, моделирующая эти действия.
Рис. 9.9. Диаграмма последовательности, моделирующая основной успешный сценарий
прецедента Покупка лимонада
Это лишь один из сценариев прецедента. В другом сценарии выбранного сорта
лимонада может и не оказаться. На рис. 9.10 показана диаграмма последовательности
для сценария, если нужная марка лимонада отсутствует.
9-й час. Диаграммы последовательностей
129
Рис. 9.10. Диаграмма последовательности, моделирующая сценарий отсутствия нужной
марки лимонада для прецедента Покупка лимонада
Рассмотрим еще один сценарий. Допустим, покупатель бросает в автомат неточ-
ную сумму денег. Диаграмма последовательностей для этого сценария показана на
рис. 9.11.
И, наконец, предположим, покупатель вводит неточную сумму, а в автомате отсут-
ствует сдача. Соответствующая диаграмма последовательности показана на рис. 9.12.
Рис. 9.11. Диаграмма последовательности для сценария, когда вводится неточная стои-
мость товара
130
Часть I. Начало
Рис. 9.12. Диаграмма последовательности для сценария, когда вводится неточная сумма
и отсутствует сдача
Общая диаграмма последовательности
Поскольку каждая из представленных выше диаграмм описывает только один сце-
нарий прецедента Покупка лимонада, она называется частной диаграммой последова-
тельности (instance sequence diagram).
Если диаграмма последовательности включает все сценарии прецедента, она назы-
вается общей диаграммой последовательностей. Построим общую диаграмму последова-
тельностей. Для этого нужно учесть условия выполнения различных сценариев. На-
помним, что в примере с автомобилем уже упоминались условия переходов, указы-
ваемые в квадратных скобках. Например, для того чтобы указать, что данное
сообщение передается только в случае отсутствия нужного сорта лимонада, перед со-
общением добавляют условие перехода [нет выбора].
Условия перехода обеспечивают ту же информацию, что и ответные сообщения.
Например, условие перехода [нет выбора] свидетельствует о том, что выбранный
сорт лимонада отсутствует. Эти же сведения можно передать с помощью ответного
сообщения нетВыбора (). Поэтому ответные сообщения на диаграмме можно не ука-
зывать. Они бы только загромождали диаграмму.
И еще одно замечание относительно общей диаграммы последовательности. Необ-
ходимо показать, что последовательность действий одного из сценариев полностью
завершена, а остальные сообщения относятся к другим сценариям. Для этого послед-
нее сообщение каждого сценария сопровождают стереотипом <<транзакция завер-
шена».
Эти идеи отражены на рис. 9.13.
Рассмотрим диаграмму сверху вниз. Она начинается с запроса покупателя к лице-
вой панели. Покупатель задает сорт лимонада и бросает монеты в автомат. Затем объ-
ект :ЛицеваяПанель передает объекту :Реестр введенные покупателем данные. Если
сумма денег превышает цену, объект : Реестр вычисляет причитающуюся сдачу и
проверяет резерв наличности. Если нет сдачи, реестр возвращает объекту
: ЛицеваяПанель введенную сумму, а лицевая панель выводит сообщение о необхо-
димости внести точную сумму. Транзакция завершена.
9-й час. Диаграммы последовательностей
131
:Клиент
: ЛицеваяПанель
:Реестр
:Отсек
принять(сумха, выбор)
I
t
I
I
лолучитьЗаказКлиента(сумма, выбор)
[нет сдачиj зернутьДеньги(сумма)
[сумма>цена]
проверитьСдачу(сумма, цена)
<<транзакция завершена>>вызести
Сообшение('Используйте другую сумму')
>:ет выбора]
вывестиСообшение('Нет выбора')
«транзакция завершена»
[нет выбора j вернутьДеньги(сумма)
[сумма>цена]
проверитьНаличие(выбор)
| обновить(сумма
, цена)
।
।
получитьСдачу(сдача)
«транзакция завершена» ।
• [есть выборjполучитьЛимонад(выбор) •
I •
выдатьЛимонад(выбор)
।
।
Рис. 9.13. Общая диаграмма последовательностей для автомата по продаже лимонада
На линии жизни объекта : Реестр начинается другой сценарий. Реестр обращается
к объекту : Отсек с запросом о наличии нужного сорта лимонада.
Если выбранная марка товара отсутствует, отсек обращается к объекту
: ЛицеваяПанель с запросом на вывод сообщения об отсутствии нужного сорта лимо-
нада. Затем объект : ЛицеваяПанель возвращает деньги покупателю. Транзакция за-
вершена.
Двигаясь далее по линии жизни объекта : Реестр, видим, что в случае продолже-
ния транзакции реестр обрабатывает информацию о введенной сумме и цене товара.
Если уплаченная сумма больше цены, реестр возвращает сдачу объекту
:ЛицеваяПанель. Затем реестр обращается к отсеку с запросом на лимонад нужного
сорта, объект :Отсек передает лимонад объекту : ЛицеваяПанель, и транзакция снова
завершается.
Если читателю ясно, что за каждым прецедентом стоит одна или несколько диа-
грамм последовательностей, он правильно понял основную идею.
Отображение создания объекта на
диаграмме последовательностей
Несколько лет назад компания-гигант в области телекоммуникации, Ericsson, про-
демонстрировала технологию, позволяющую покупать лимонад в автомате с помощью
мобильного телефона. Как отразить соответствующие взаимодействия на диаграмме
последовательностей? Что нужно добавить на эту диаграмму?
Давайте снова начнем с диаграммы классов. Рис. 9.14 является расширением
рис. 9.8. С помощью беспроводного соединения класс МобильныйТелефон связывает-
ся с интерфейсом ЛицеваяПанель. Лицевая панель теперь является более интеллекту-
альной и умеет обрабатывать информацию от покупателя. Она обладает дополнитель-
ной способностью (это очень важно) — создает запись о транзакции между покупате-
лем и автоматом. Автомат использует эту запись для расчета с покупателем по его
кредитной карточке. На диаграмме последовательностей необходимо визуализировать
создание записи о транзакции.
132
Часть I. Начало
АвтоматПоПродажеЛимонада
Рис. 9.14. Расширение диаграммы классов из рис. 9.8 для отображения взаимодейст-
вия автомата с мобильным телефоном
Построим диаграмму последовательностей. Начнем с основного сценария: покупа-
тель вводит информацию о своей кредитной карточке в мобильный телефон и переда-
ет ее объекту :Лицевая панель. Лицевая панель обрабатывает поступившую инфор-
мацию и выводит приглашение покупателю. Покупатель вводит сведения о выбран-
ном напитке в мобильный телефон, который, в свою очередь, передает их объекту
:Лицевая панель. В этой модели автомата для продажи лимонада объект :Лицевая
панель обрабатывает данные покупателя и напрямую взаимодействует с объектом
: Отсек. В остальном сценарий в точности соответствует приведенному выше основ-
ному сценарию для автомата прошлого столетия, за исключением создания объекта
:ЗаписьТранзакции.
Диаграмма последовательностей для описанного сценария показана на рис. 9.15.
Все объекты, за исключением объекта : ЗаписьТранзакции, располагаются вдоль
верхнего края диаграммы. Почему так? Дело в том, что объект : ЗаписьТранзакции
не существует в начале сценария. Его создание иллюстрируется расположением в
нижней части диаграммы (в соответствии со временем создания). При этом сообще-
ние, отправляемое объектом-отправителем создаваемому объекту, сопровождается сте-
реотипом с ключевым словом <<создает>>. (Поскольку объект : Реестр не участвует
в реализации данного сценария, он не отображен на диаграмме.)
Если речь идет о создании объектов, то нельзя не вспомнить об их уничтожении.
Чтобы отразить на диаграмме момент разрушения объекта, в нижней части его линии
жизни изображают большой жирный символ X (рис. 9.16). В левой части диаграммы
показан момент саморазрушения объекта. В правой части диаграммы один объект от-
правляет другому инструкцию о разрушении с помощью сообщения с ключевым сло-
вом <<разрушает>>.
9-й час. Диаграммы последовательностей
133
Рис. 9.15. Диаграмма последовательности, моделирующая основной сценарий использова-
ния мобильного телефона в качестве интерфейса к автомату для продажи лимонада
Рис. 9.16. Объект может разрушаться сам по себе (слева) или
получать инструкцию на уничтожение от другого объекта
(справа)
134
Часть I. Начало
Кадрирование последовательности
в UML 2.0
В UML 2.0 появилось полезное новшество, связанное с диаграммами последова-
тельности. Теперь из такой диаграммы можно выделить кадр, заключить его в рамку и
указать в левом верхнем углу информацию о диаграмме.
Одним из фрагментов этой информации является оператор, описывающий тип
диаграммы в кадре. Для диаграммы последовательности используется оператор sd. На
рис. 9.17 показана общая диаграмма последовательности, помещенная в кадр в стиле
UML 2.0. Рядом с оператором указывается имя прецедента (Покупка лимонада),
описываемого диаграммой.
Включения
Кадрирование можно применять различными способами. Приведем пример.
При создании частных диаграмм последовательностей для различных сценариев
одного прецедента приходится многократно дублировать общие фрагменты различных
диаграмм. Кадры обеспечивают быстрый и удобный способ повторного использова-
ния фрагментов диаграмм последовательностей. Нужно просто заключить в кадр часть
диаграммы, добавить метку кадра и вставить этот кадр с меткой (без сообщений и ли-
ний жизни) в новую диаграмму. Эта добавленная часть называется включением. Ей со-
ответствует оператор ref.
На рис. 9.18 показан кадр, включающий часть основного сценария и представ-
ляющий собой включение, описывающее процесс доставки лимонада. На рис. 9.19
показано, как можно повторно использовать это включение на диаграмме сценария с
неточной суммой оплаты.
sd Покупка лимонада
:Клиент
:ЛицеваяПанель
принять(сумма, выбор)
:Отсек
:Реестр
।
I 1 1 « получитьЗаказКлиента(сумма, выбор) I
[нет сдачи]вернутьДеньги(сумма) | [сумма>цена] 1 проверитьСдачу(сумма, цена) । I । I
«транзакция завершена»вывести I I
Сообщение("Используйте другую сумму") проверитьНаличие(выбор) 1 (
^[нет выбора]
вывестиСообщение("Нет выбора") и
«транзакция завершена» 1 <
[нет выбора]вернутьДеньги(сумма) [сумма>цена] | обновить(сумма, цена) 1 1 1 1 <
получитьСдачу(сдача) выдатьЛимонад(выбор) 1 1
«транзакция завершена» 1 । 1
[есть выбор]получитьЛимонад(выбор) t 1 t
т
i
।
Рис. 9.17. Кадрирование диаграммы последовательности в UML 2.0
9-й час. Диаграммы последовательностей
135
sd Покупка лимонада
^ис. 9.18. Кадр включения в диаграмме последовательности
sd Покупка лимонада
?ис. 9.19. Повторное использование включения
136
Часть I. Начало
Комбинирование фрагментов взаимодействия
Включение — это частный случай фрагмента взаимодействия (interaction fragment),
под которым в UML 2.0 понимают общую часть диаграммы последовательности.
Фрагменты взаимодействия можно комбинировать различными способами. Тип ком-
бинации определяется именем оператора. Чтобы показать комбинацию, нужно помес-
тить в кадр весь набор фрагментов, а для разделения фрагментов взаимодействия ис-
пользовать пунктирную линию.
По мнению автора, чаще всего используются два типа комбинаций, определяемые
операторами alt и par.
В комбинации alt каждый фрагмент представляет собой альтернативу и выполня-
ется только при определенных условиях перехода. Этот тип комбинации на общей
диаграмме последовательности показан на рис. 9.20.
В отличие от оператора ref, комбинация alt применяется в основном для ясно-
сти, а не для повторного использования. Сравнив рис. 9.20 и 9.17, можно заметить,
что условия переходов между фрагментами устраняют необходимость задания некото-
рых условий перехода для сообщений. По мнению автора, это упрощает понимание
общей диаграммы.
В комбинации par фрагменты взаимодействия выполняются параллельно, не пе-
рекрываясь друг с другом. Например, предположим автомат по продаже лимонада ра-
ботает очень эффективно, параллельно выдавая и напиток и сдачу. При этом не-
сколько событий происходит одновременно. Эта ситуация показана на рис. 9.21.
Рис. 9.20. В комбинации alt каждый фрагмент взаимодействия представляет собой одну
из альтернатив и выполняется только при определенных условиях
9-й час. Диаграммы последовательностей
137
sd Покупка лимонада
Рис. 9.21. В комбинации par фрагменты выполняются параллельно, не перекрываясь друг
с другом
Пока в UML 2.0 не появился оператор par, на диаграмме последовательности бы-
ло сложно отобразить параллельные события.
Построение общей картины
Теперь к общей картине UML можно добавить еще одну диаграмму. Поскольку
диаграмма последовательностей связана с поведением объектов, она располагается в
категории “Поведенческие элементы”. На рис. 9.22 изображена обновленная общая
картина UML.
138
Часть I. Начало
Поведенческие элементы
Структурные элементы
Исполнитель
Взаимосвязи
Состояние
S_________>
------------- Ассоциация
{> Обобщение
Зависимость
Реализация
Последовательность событий
Группировка
Пакет
Расширение
<<стереотип>>
{ограничение}
: Имя 2
Аннотация
--------L.
Примечание
Рис. 9.22. Общая картина
последовательности
Резюме
Диаграмма последовательностей UML добавляет измерение времени ко взаимо-
действию объектов. Объекты располагаются в верхней части диаграммы, а время из-
меняется сверху вниз. От каждого отображенного на диаграмме объекта опускается
линия его жизни.
Передаваемые объектами сообщения изображаются в виде линий, соединяющих
одну линию жизни с другой, со стрелками на конце. Расположение сообщений вдоль
вертикального направления соответствует времени их передачи. Переданные ранее
сообщения находятся ближе к верхней части диаграммы Чем позже передается сооб-
щение, тем ближе к нижней части диаграммы последовательностей оно располагается.
Узкий прямоугольник на линии жизни объекта представляет точку активации — вы-
полнение одной из операций объекта. На диаграмме последовательностей можно ука-
зать состояния объекта, разместив их вдоль линии жизни.
Диаграмма прецедентов представляет либо один сценарий прецедента, либо объе-
диняет все сценарии. Каждому прецеденту соответствует диаграмма последовательно-
стей. Один сценарий отображается на частной диаграмме, а несколько сценариев —
на общей. На общей диаграмме последовательностей нередко отображают оператор
“если”. Условия для операторов “если” заключаются в квадратные скобки.
Если последовательность операций включает создание объекта, он представляется
обычным образом. Его позиция вдоль вертикального направления должна соответст-
вовать времени его создания.
9-й час. Диаграммы последовательностей 139
В UML 2.0 диаграммы последовательностей можно дополнять новыми элемента-
ми — кадрами, представляющими фрагменты диаграммы. Кадры обеспечивают воз-
можность повторного использования и позволяют прояснить некоторые аспекты
диаграммы.
Вопросы и ответы
Похоже, диаграмма последовательности полезна не только для системного анализа.
Можно ли ее использовать для отображения взаимодействия в организации?
В качестве объектов могут выступать сотрудники организации, а сообщения могут
иллюстрировать передачу управления.
Иногда последовательность действий предполагает рекурсию. Как отразить рекурсию
на диаграмме последовательностей?
Для этого нужно показать, что объект передает сообщение сам себе. При его акти-
визации будет выполняться дальнейшая активизация. Этот процесс изображается с
помощью стрелки.
Вы упоминали, что условие перехода в квадратных скобках в UML соответствует опеГ
ратору if. Можно ли подобным образом изобразить цикл while?
Можно. Цикл while можно рассматривать как многократное повторение операто-
ра if. Из главы 4 известно, что для представления множества в UML используется
звездочка (*). Поэтому в UML цикл while представляется обозначением * [ ].
Перед диаграммой последовательности вы изображали диаграмму классов. Всегда ли
это нужно делать?
Это хорошая идея. Если сначала построить диаграмму классов, то проще понять,
какие сообщения класс может передавать объектам других классов.
Практические занятия
Теперь, после того как мы рассмотрели взаимодействие объектов, ответьте на не-
сколько вопросов и выполните упражнения, чтобы закрепить знания о диаграммах
последовательностей. Ответы на вопросы вы найдете в приложении А.
Тесты
1. Дайте определение синхронным и асинхронным сообщениям.
2. Что такое фрагмент взаимодействия в UML 2.0?
3. Что означает в UML 2.0 оператор par?
4. Как на диаграмме последовательности отображается вновь созданный объект?
Упражнения
1. Создайте частную диаграмму последовательностей, соответствующую успеш-
ной отправке факса. Это значит, что в модели должно быть представлено
взаимодействие объектов при выполнении основного успешного сценария
прецедента Отправка факса для факс-машины. Включите в диаграмму объек-
ты, соответствующие отправляющей и принимающей машинам, передаваемо-
му сообщению и центральному узлу обмена сообщениями, который маршру-
тизирует факсы и телефонные вызовы.
140
Часть I. Начало
2. Создайте общую диаграмму последовательностей, включающую дополнитель-
ные сценарии (линия занята, ошибка в отправляющей факс-машине), а также
основной успешный сценарий из упражнения 1. Используйте максимальное
количество обозначений из UML 2.0.
3. Создайте диаграмму последовательностей для электрической точилки каран-
дашей. Используйте объекты: исполнитель, карандаш, точка вставки (гнездо
для вставки затачиваемого карандаша в точилку), двигатель и затачивающий
элемент. Какие сообщения следует использовать? Что собой представляют
точки активации? Должна ли эта диаграмма включать рекурсию?
9-й час. Диаграммы последовательностей
141
10-й час
Диаграммы коммуникации
Из этого часа вы узнаете
> Что представляет собой диаграмма коммуникации
> Как применять диаграммы коммуникации
> Как моделировать активные объекты, параллелизм и синхронизацию
> Какое место занимают диаграммы коммуникации в UML
В этой главе будут рассмотрены диаграммы, аналогичные изученным в предыду-
щей главе. На них тоже отражается взаимодействие между объектами, но несколько
иначе, чем на диаграммах последовательностей.
Подобно диаграммам последовательностей, диаграммы коммуникации отражают
взаимодействие объектов. На них изображаются объекты вместе с сообщениями, ко-
торыми они обмениваются. Возникает вопрос: если все можно делать с помощью
диаграмм последовательностей, то зачем в UML нужны другие диаграммы? Разве в
них не описывается одно и то же? Зачем же использовать оба типа диаграмм?
Эти два типа диаграмм действительно похожи. По сути, они семантически эквива-
лентны. Иными словами, в них представлена одна и та же информация. Диаграмму
последовательностей можно преобразовать в диаграмму коммуникации, и наоборот.
На самом деле весьма полезно работать с обоими видами диаграмм. Диаграмма
последовательностей акцентирует внимание на временном упорядочении взаимодей-
ствий. Диаграмма коммуникации ориентирована на состояние и общую организацию
взаимодействующих объектов. Существует еще один способ понять различие между
ними: диаграмма последовательностей упорядочена в соответствии со временем, диа-
грамма коммуникации — в соответствии с пространственным расположением объек-
тов. Оба вида диаграмм отражают взаимодействие объектов, поэтому их относят к
диаграммам взаимодействия.
Что представляет собой диаграмма
коммуникации
В объектной диаграмме описываются объекты и их взаимосвязь друг с другом.
Диаграмма коммуникации является расширением понятия объектной диаграммы.
В дополнение к связям между объектами в диаграмму коммуникации включают со-
общения, которые объекты передают друг другу. До сих пор этот момент не учитывал-
ся, чтобы не создавать неразберихи.
Чтобы понять взаимосвязь диаграмм коммуникации с объектными диаграммами,
можно воспользоваться следующей аналогией. Представьте себе отличие моменталь-
ного снимка от фрагмента видеосъемки. Объектная диаграмма — это моментальный
снимок. На нем показаны экземпляры класса и их взаимосвязь в конкретный момент
времени. Диаграмма коммуникации — это видеофильм. Она отражает взаимодействие
объектов во времени.
Чтобы изобразить обращение к объекту, параллельно линии, которая соединяет
объекты, рисуют стрелку. Направление стрелки указывает на объект, к которому об-
ращаются. Метка возле стрелки служит для описания этого сообщения. В сообщении,
как правило, дается команда объекту-получателю выполнить одну из операций. Стрелки
при этом выполняют ту же функцию, что и на диаграммах последовательностей.
Как уже упоминалось, любую диаграмму последовательностей можно преобразо-
вать в диаграмму коммуникации, и наоборот. Следовательно, последовательную ин-
формацию можно описать и в диаграмме коммуникации. Для этого к метке сообще-
ния нужно добавить номер, соответствующий номеру этого сообщения в последова-
тельности сообщений. Номер от самого сообщения отделяется двоеточием.
На рис. 10.1 продемонстрирован набор обозначений для диаграммы коммуникации.
Рис. 10.1. Набор обозначений для диаграммы
коммуникации
Отличия UML 1.x от UML 2.0
Если вы имели дело с более ранними версиями UML или знакомы с предыдущими издания-
ми этой книги, то вам встречался термин диаграмма кооперации. В UML 2.0 вместо него
появился новый термин — диаграммы коммуникации. Далее в книге автор будет придержи-
ваться новой терминологии. Если вы пользуетесь документацией или средствами моделиро-
вания, основанными на UML 1.x, то вам придется работать с устаревшими понятиями.
Воспользуемся преимуществом эквивалентности двух типов диаграмм и рассмот-
рим примеры, приведенные в предыдущей главе. Это позволит развить концепцию
диаграмм коммуникации и ввести новые понятия.
10-й час. Диаграммы коммуникации
143
Автомобили и ключи
Вернемся к предметной области автомобилей и ключей. Показанная на рис. 10.2
диаграмма классов является повторением диаграммы, представленной на рис. 9.5 в
предыдущей главе.
ВладелецАвтомобиля
имя
датаРождения
адрес
номерЛицензии
ехать()
припарковаться()
<<сигнал>> МигнутьФарами
<<сигнал>> ЗвуковойСигнал
Ключ
идентификатор
нажатьКнопку(к:ИмяКнопки)
—J 6—
Кнопочная Беспроводное
Панель Соединение
Рис. 10.2. Диаграмма классов для предметной области автомобилей и ключей
Теперь построим диаграмму объектов, моделирующую экземпляры классов, пока-
занных на рис. 10.2. Эта диаграмма показана на рис. 10.3. Она составляет основу
диаграммы коммуникации.
Рис. 10.3. Диаграмма объектов, моделирующая экземп-
ляры классов из рис. 10.2
Добавим к этой диаграмме сообщения, показанные ранее на рис. 9.7. Получим
диаграмму, изображенную на рис. 10.4. Эта диаграмма представляет один из способов
отображения множества сообщений, передаваемых между двумя объектами. Сообще-
ния 4 и 5 являются сигналами, передаваемыми объектом :Автомобиль объекту
: ВладелецАвтомобиля. Им соответствуют разные метки, но не разные линии со
стрелками. Это позволяет не перегружать диаграмму лишней информацией. Однако в
некоторых средствах моделирования каждому сообщению соответствует отдельная
стрелка. Помните, если между двумя объектами передаются сообщения различных
типов, каждый тип сообщений нужно изображать отдельной линией.
144
Часть I. Начало
Рис. 10.4. Диаграмма коммуникации, моделирующая передачу сообщений
между объектами из рис. 10.3
Чтобы показать эквивалентность диаграмм коммуникации и последовательности,
на рис. 10.5 автор одновременно изобразил эти два вида диаграмм (представленные на
рис. 10.4 и 9.7, соответственно).
Рис. 10.5. Диаграмма коммуникации и эквивалентная ей диаграмма последовательности
для примера с автомобилем и ключами
Изменение состояния и вложенные
сообщения
Допустим, класс Автомобиль содержит атрибут закрыт, имеющий значение Исти-
на или Ложь. Возвращаясь к главе 8, “Диаграммы состояний”, представьте себе два
состояния объекта : Автомобиль — Закрыт и Открыт, — показанные на рис. 10.6.
Изменение состояния можно представить на диаграмме коммуникации. Для этого
в данном примере для объекта : Автомобиль нужно указать значение атрибута за-
крыт. Затем нужно добавить еще одно изображение объекта с новым значением атри-
бута закрыт. Соединим эти два прямоугольника и покажем сообщение, передаваемое
первым объектом второму. Пометим сообщение стереотипом с ключевым словом
«становится».
Этот пример позволяет познакомиться с новым понятием, связанным с диаграм-
мой коммуникации. На этих диаграммах для отображения взаимосвязи между сооб-
щениями используется нумерация. С ее помощью можно проследить последователь-
ность передачи сообщений. Можно также изображать вложенные сообщения. Номер
вложенного сообщения начинается с номера родительского сообщения, за которым
следует собственно номер вложенного сообщения. Изменение состояний и вложен-
ные сообщения показаны на рис. 10.7.
10-й час. Диаграммы коммуникации
145
Открыт
Открыть
Закрыть
Рис 10.6. Состояния Закрыт и
Открыт объекта -.Автомобиль
Рис 10.7. Моделирование изменения состояний на диаграмме коммуникации.
Обратите внимание на вложенное сообщение (3.1: <<становится>>)
На рис. 10.8 показан еще один способ моделирования изменения состояний. Автор
предпочитает первый вариант, поскольку пунктирная линия во втором способе напо-
минает отношение зависимости. Новичкам в области UML обычно сложно понять
отношение зависимости.
Этот пример может привести читателя к ошибочному заключению, что вложенное
сообщение связано с изменением состояния. Из следующего раздела станет ясно, что
это не всегда так.
146
Часть I. Начало
Рис 10.8. Еще один способ моделирования изменения состояний на диа-
грамме коммуникации
Автомат для продажи лимонада
Вернемся к примеру автомата для продажи лимонада и рассмотрим диаграмму
коммуникации, соответствующую диаграмме последовательности из главы 9.
Начнем с основного успешного сценария прецедента Покупка лимонада. Диа-
грамма коммуникации для этого сценария показана на рис. 10.9.
Здесь приводится еще один пример вложенного сообщения. Ответное сообщение
ЕстьВыбор является вложенным для операции проверить (Выбор). Его номер 3.1.
4:обновитьДенежныйБаланс
(сумма, цена)
Рис 10.9. Диаграмма коммуникации для основного успешного сцена-
рия прецедента Покупка лимонада
10-й час. Диаграммы коммуникации
147
В качестве упражнения постройте диаграммы коммуникации для остальных част-
ных диаграмм последовательностей, показанных на рис. 9.10, 9.11 и 9.12. А сейчас об-
ратимся к общей диаграмме последовательности (см. рис. 9.13) и создадим соответст-
вующую диаграмму коммуникации (рис. 10.10).
:Клиент
1:принять(сумха, выбор)
।сумма>цена]
6:получитьСдачу(сдача)
•нет сдачи] 3.1:вернутьДеньги(сумма)
«транзакция завершена»
3.2:вывестиСообщение('Используйте другую сумму*)
[нет выбора] 4.1:вывестиСообщение(*Нет выбора*)
«транзакция завершена»
4.2:[нет выбора] зернутьДеньги(сумма)
«транзакция завершена»
[есть выбор] 8:получитьЛихонад(зыбор)
:ЛицеваяПанель
:Отсек
4:проверитьЕаличие(выбор)
7:выдатьЛимонап(выбор)
2:получитьЗаказКлиента(сумма, выбор)
[сумма>цена] 3:проверитьСдачу(сумма, цена)
5:обновить(сумма, цена)
Рис 10.10. Диаграмма коммуникации для общей диаграммы последовательности автомата
для продажи лимонада
Несложно убедиться, что эта диаграмма слишком загромождена, особенно в той
части, где отображаются сообщения между объектами :Лицевая панель и : Реестр.
Метки сообщений расположены близко друг к другу, несколько видов сообщений
сливаются, и для ясности используются условия перехода и стереотипы.
Создание объекта
Чтобы понять процедуру создания объекта, вернемся к примеру управления авто-
матом для продажи лимонада с помощью мобильного телефона. Создаваемый объ-
ект — это запись транзакции, позволяющая автомату работать со счетом покупателя.
Для моделирования создания объекта к метке сообщения добавляется стереотип
«создать». Соответствующая диаграмма коммуникации показана на рис. 9.11.
Еще о нумерации
Иногда два сообщения участвуют в процессе принятия решений и их условия пе-
рехода являются взаимоисключающими. Как их нумеровать? Вернемся к примеру
управления автоматом для продажи лимонада с помощью мобильного телефона. На
рис. 10.11 показан только основной успешный сценарий. Допустим, идентификация
пользователя может завершиться неудачно. В этом случае к сообщению 2.1 на
рис. 10.11 нужно добавить условие перехода [принят] и ввести дополнительное со-
общение с условием перехода [не принят]. В последнем случае транзакция заверша-
ется, а объект :Лицевая панель выводит соответствующую информацию.
Как нумеровать дополнительное сообщение? Поскольку условия перехода являют-
ся взаимоисключающими, возможен только один вариант. На рис. 10.12 показана со-
ответствующая часть рис. 10.11 с этими двумя сообщениями.
148
Часть I. Начало
1:нажатьКнопку(номерКредитнойКарточки)
Рис 10.11. Моделирование создания объекта в основном сценарии взаимодействия авто-
мата для продажи лимонада с мобильным телефоном
[принята] 2.1:вывестиСообщение("Принята")
:ЛицеваяПанель
-- <<транзакция завершена>> [не принята]
▼ 2.1:вывестиСообщение("Не принята")
Рис 10.12. Нумерация сообщений со взаимоисключающими усло-
виями перехода
Еще несколько понятий
Хотя уже рассмотрено множество вопросов, мы коснулись далеко не всех понятий,
связанных с диаграммами коммуникации. Понятия, представленные в настоящем раз-
деле, являются в некотором роде “эзотерическими”, но они могут оказаться весьма
полезными в процессе моделирования.
Множество объектов-получателей одного
класса
Иногда объект передает сообщение множеству объектов одного класса. Например,
профессор потребовал от студентов сдать задание. На диаграмме коммуникации мно-
жество объектов представляется в виде набора прямоугольников, расположенных друг
за другом. При этом в скобках добавляется условие с указанием того, что сообщение
адресуется всем объектам. Перед скобками ставится символ * (рис. 10.13).
В некоторых случаях весьма важна очередность отправки сообщений. Банковский
работник обслуживает клиентов согласно очереди. Это можно представить в виде
цикла, в условие которого включен номер клиента в очереди (например, номер в
очереди=1...п). Кроме того, в цикл включается само сообщение и набор прямо-
угольников (рис. 10.14).
10-й час. Диаграммы коммуникации
149
Рис. 10.13. Объект передает сообщение
множеству объектов одного класса
Рис. 10.14. Объект отправляет сообщение множеству объек-
тов одного класса в заданном порядке
Представление возвращаемых результатов
Сообщение может приводить к выполнению некоторых действий и возврату ре-
зультата. Покупатель может вычислить на калькуляторе общую стоимость на основе
стоимости товаров и налога на продажу.
В UML существует обозначение для возвращаемых значений. Для этого нужно на-
писать выражение, в левой части которого находится возвращаемая переменная, за
которой после знака := следует имя операции и ее параметры. В данном примере вы-
ражение будет иметь вид: общаяСтоимость:= вычислить(ценаТовара, налог). На
рис. 10.15 отображен этот пример диаграммы коммуникации.
Рис. 10.15. Диаграмма коммуникации, в которую включено
обозначение возвращаемого значения
Правая часть этого выражения называется сигнатурой сообщения.
150
Часть I. Начало
Активные объекты
Иногда на ход событий может влиять определенный объект. Этот активный объект
может отправлять сообщения пассивным объектам и взаимодействовать с другими ак-
тивными объектами. Библиотекарь получает задание от клиента, ищет требуемую ин-
формацию в базе данных, дает ответ на запрос, поручает сотрудникам пополнить за-
пас книг и т.п. Библиотекарь также общается со своими сотрудниками, выполняю-
щими те же функции. Процессы, в которых несколько активных объектов работает
одновременно, называются параллельными.
На диаграмме коммуникации активные объекты изображаются так же, как осталь-
ные объекты, только рамка прямоугольника более жирная (рис. 10.16).
I:Библиотекарь |
:Сотрудник
4: выдать(название)
сформироватьЗапрос(название
;Сотрудник
2: найти(название)
:Клиент
Рис. 10.16. Активный объект влияет на ход событий в последовательно-
сти. Его изображают в виде прямоугольника с жирной рамкой
3: вернутьИнформацию(название)
Синхронизация
В некоторых случаях пользователь может столкнуться с тем, что объект передает
сообщение только после отправки нескольких других (возможно, непоследовательных)
сообщений. Иными словами, объект должен “синхронизировать” это сообщение с на-
бором других сообщений.
Следующий пример внесет ясность в этот вопрос. Предположим, объекты — это
сотрудники некой корпорации, участвующие в “раскрутке” нового продукта. После-
довательность их взаимодействий следующая.
1. Вице-президент по маркетингу дает задание вице-президенту по продажам
разработать рекламную кампанию для определенного вида продукции.
2. Вице-президент по продажам разрабатывает политику и поручает ее проведе-
ние менеджеру по продаже.
3. Менеджер по продаже направляет торгового агента вести торговлю продукци-
ей согласно разработанной программе.
4. Агент устраивает распродажу в кругу потенциальных потребителей.
5. После того как вице-президент по продажам дает задание, а менеджер по про-
дажам выпускает директиву (т.е. шаги 2 и 3 пройдены), специалист корпора-
ции по рекламе, согласно разработанной политике, размещает рекламные
объявления в местной газете.
Как отразить п. 5 данной последовательности на диаграмме? Опять же, для такого
случая в UML предусмотрено обозначение. Вместо порядкового номера перед сооб-
щением указывают номера сообщений, которые необходимо передать для выполнения
п. 5. Номера сообщений в списке отделяются друг от друга запятой. Весь список за-
канчивается косой чертой. На рис. 10.17 изображена диаграмма коммуникации для
этого примера.
10-й час. Диаграммы коммуникации
151
Рис. 10.17. Синхронизация сообщений на диаграмме коммуникации
Построение общей картины
Теперь диаграмму коммуникации можно добавить в общую картину UML. Она яв-
ляется еще одним поведенческим элементом, как изображено на рис. 10.18.
Поведенческие элементы
Структурные элементы
Исполнитель
Взаимосвязи
Ассоциация
Обобщение
Зависимость
£> Реализация
Группировка
Пакет
Расширение
«стереотип»
{ограничение}
Состояние
Последовательность событий
Коммуникация
Аннотация
-------к
Примечание
Рис. 10.18. Добавление диаграммы коммуникации в общую
картину UML
152
Часть I. Начало
Резюме
Диаграмма коммуникации — еще один способ представить информацию, которая
ранее была отображена на диаграмме последовательности. Эти два типа диаграмм се-
мантически эквивалентны, но при этом при разработке модели системы желательно
использовать обе диаграммы. Диаграмма последовательностей упорядочена в соответ-
ствии со временем, диаграмма коммуникации — в соответствии со взаимосвязью объ-
ектов.
На диаграмме коммуникации ассоциации между объектами изображаются в виде
сообщений, передаваемых объектами друг другу. Сообщение представляют в виде
стрелки возле соединительной линии, а имя сообщения указывается рядом со стрел-
кой. Порядковый номер указывает место данного сообщения в общей последователь-
ности.
Условия отображают в квадратных скобках. Чтобы описать цикл, надо поместить
перед левой скобкой маленькою звездочку.
Некоторые сообщения являются дочерними по отношению к другим. В системе
нумерации сообщений они описываются точно так же, как заголовки и подзаголовки
в технических руководствах — с использованием десятичной точки для обозначения
уровня вложенности.
Диаграмма коммуникации позволяет моделировать множество объектов-
получателей одного класса независимо от того, получают они сообщения по очереди
или одновременно. Можно также изображать активные объекты, управляющие пото-
ком сообщений, а также синхронизированные сообщения.
Вопросы и ответы
Так ли необходимо включать и диаграмму коммуникации, и диаграмму последователь□
ностей в модель системы на языке UML?
Очень удобно включать обе диаграммы. Эти типы диаграмм стимулируют различ-
ные мыслительные процессы на этапе анализа системы. В диаграмме коммуникации
проясняются взаимодействия между объектами, поскольку она содержит связи между
объектами. Диаграмма последовательностей фокусирует внимание на последователь-
ности событий. В организации могут работать люди с различным типом мышления,
поэтому при изучении модели сотрудникам могут понравиться разные диаграммы.
В главе 9 говорилось о кадрах, в которые можно помещать части диаграммы последов
вательностей в UML 2.0. Существует ли в UML 2.0 подобная возможность для диаграмм
коммуникации?
В UML 2.0 в кадр можно заключить и часть диаграммы коммуникации, хотя, соглас-
но спецификации UML 2.0, кадры не являются частью диаграммы коммуникации.
Из этой главы вы узнали, как моделировать изменение состояния объекта. Можно ли
отобразить этот процесс на диаграмме последовательности?
Можно. Состояние указывается с помощью соответствующего обозначения на ли-
нии жизни объекта. Местоположение состояния на линии жизни определяет период
пребывания объекта в этом состоянии. Чтобы отразить изменение состояния, добавь-
те новое обозначение состояния ниже на линии жизни. Язык UML допускает исполь-
зование обозначений, относящихся к одним диаграммам, на других видах диаграмм.
Однако некоторые средства моделирования не позволяют этого делать.
10-й час. Диаграммы коммуникации
153
Практические занятия
В этом разделе даны различные тесты и упражнения для закрепления знаний о
диаграммах последовательностей и их “сестрах” — диаграммах коммуникации. Отве-
ты, как всегда, размещены в приложении А.
Тесты
1. Как представить сообщение на диаграмме коммуникации?
2. Как на диаграмме коммуникации отобразить последовательную информацию?
3. Как представить изменения состояния?
4. Что подразумевается под “семантической эквивалентностью двух типов диа-
грамм”?
Упражнения
1. В сценарии с вводом некорректной суммы денег прецедента Покупка лимо-
нада была показана эквивалентность диаграммы коммуникации и диаграммы
последовательностей. Постройте полную диаграмму коммуникации, которая
будет соответствовать диаграмме последовательности, представленной в гла-
ве 9. При этом на диаграмму коммуникации, изображенную на рис. 10.5, до-
бавьте сценарий с отсутствием нужного сорта лимонада.
2. Вернемся к рис. 4.17—4.19 из главы 4, “Работа со связями”. Постройте диа-
грамму коммуникации, отражающую соответствующие ходы. Каждый ход рас-
сматривайте как сообщение, передаваемое от одной шахматной фигуры другой.
3. Для модели электрической точилки карандашей (см. главу 9) необходимо по-
строить диаграмму коммуникации, эквивалентную ранее созданной диаграмме
последовательностей.
154
Часть I. Начало
11-й час
Диаграммы видов деятельности
Из этого часа вы узнаете
> Что такое диаграмма видов деятельности
> Как применять диаграммы видов деятельности
> Как отобразить роли участников
> Какие важные понятия появились в UML 2.0
> Какое место занимают диаграммы видов деятельности в общей картине UML
В этой главе будет рассматриваться тип диаграмм, который может показаться чита-
телю знакомым. Эти диаграммы описывают стадии какой-либо операции или процесса.
Тем, кто посещал вводные курсы по программированию, наверняка встречалось
такое понятие, как блок-схема. Блок-схема — это одна из первых визуальных моде-
лей, демонстрирующих процесс вычислений. С помощью блок-схемы изображается
последовательность шагов, процессов, точек принятия решений и ветвления. Начи-
нающие программисты предпочитают использовать для осмысления задач и поиска
решений именно блок-схемы. Блок-схема является основой будущей программы. Раз-
нообразные типы диаграмм UML тоже, в некотором смысле, являются очень
“развитыми” блок-схемами.
Диаграмма видов деятельности UML очень похожа на старые блок-схемы. В ней
точками принятия решений и переходов описывается последовательность шагов
(названных с достаточной точностью видами деятельности). Такая схема достаточно
удобна для отображения бизнес-процессов или операций. Поэтому диаграммы видов
деятельности являются неотъемлемой частью системного анализа.
В первой части этой главы мы рассмотрим основные понятия, которые использо-
вались и в прежних версиях UML 1.x, а во второй — опишем новые идеи UML 2.0,
расширяющие возможности моделирования видов деятельности.
Что такое диаграмма видов деятельности
Первое и самое главное заключается в том, что с помощью диаграммы видов дея-
тельности реально описывается все, что происходит во время какой-либо операции
или процесса.
Каждый вид деятельности изображается прямоугольником со скругленными угла-
ми — более узким и овальным, чем символ состояния из главы 8, “Диаграммы со-
стояний”. После завершения одного вида деятельности переход к следующему проис-
ходит автоматически. Переход от одного вида деятельности к другому изображается
стрелкой. Как и на диаграмме состояний, на диаграмме видов деятельности имеется
начальная точка, изображенная в виде закрашенного кружка, и конечная точка в виде
“глазка“.
Начальная и конечная точка, два вида деятельности и переход между ними изо-
бражены на рис. 11.1.
Рис. 11.1. Переходы от од-
ного вида деятельности к
другому
Решения, решения, решения...
В последовательности видов деятельности практически всегда наступает этап при-
нятия решения. Один набор условий выводит на один путь, следующий — на другой
путь, причем эти пути исключают друг друга.
Точку принятия решений можно изобразить двумя способами. (Вот так штука! Уже
для выбора способа представления точки принятия решения нам приходится прини-
мать решение.) Первый способ — просто показать возможные пути развития событий
после завершения этого вида деятельности. Во втором случае изображают переход к
маленькому ромбику, который внешне похож на символ проверки (условия) в блок-
схеме. Затем все возможные пути выходят из этого ромбика. (Автор предпочитает вто-
рой, более консервативный способ.) В любом случае около пути указывается соответ-
ствующее условие в квадратных скобках, как изображено на рис. 11.2.
156
Часть I. Начало
Рис. 11.2. Два способа изображения точки принятия решения
Параллельные пути
При моделировании видов деятельности иногда очень важно показать два отдель-
ных пути развития событий, которые идут параллельно друг другу, а затем сходятся.
Для описания этого разбиения используется непрерывная жирная линия, перпенди-
кулярная переходам, а пути изображаются выходящими из этой линии. Слияние пу-
тей представляется другой непрерывной жирной линией (рис. 11.3).
Рис. 11.3. Параллельные пу-
ти развития событий
11-й час. Диаграммы видов деятельности
157
Сигналы
На каком-то этапе последовательности видов деятельности можно передать сигнал,
при получении которого активизируется другой вид деятельности. Отправляемый сиг-
нал изображают в виде выпуклого пятиугольника, а получаемый сигнал — в виде во-
гнутого пятиугольника (рис. 11.4).
Выбор номера канала
ДУ.выбрать(канал)
переключить(канал)
Рис. 11.4. Отправка и получение сигналов
Применение диаграмм видов
деятельности
Рассмотрим пример использования диаграммы видов деятельности для моделиро-
вания процесса.
Процесс “Создание документа"
Рассмотрим виды деятельности, которые будут выполняться при использовании
офисного программного обеспечения для создания документа. Ниже представлена од-
на из возможных последовательностей этого процесса.
1. Открывается текстовый процессор.
2. Создается файл.
3. Файл сохраняется под уникальным именем в отдельном каталоге.
4. Вводится текст.
5. Если необходима графика, открывается графический пакет, создается графи-
ческое изображение и добавляется в документ.
6. Если нужна таблица, открывается пакет обработки электронных таблиц, соз-
дается таблица и добавляется в документ.
158
Часть I. Начало
7. Файл сохраняется.
8. Печатается копия документа.
9. Пакет офисного обеспечения закрывается.
На рис. 11.5 изображена диаграмма видов деятельности для данной последователь-
ности.
т
^Открытие текстового процессора
1 'Л
(Создание файла 1
( Сохранение файла 1
( Ввод документа 1
[графика нужна]
[графика не нужна]
и использование графического пакета
[таблицы нужны] (
>1 Открытие и использование электронной таблицы
[таблицы не нужны]
Печать документа
Выход из офисного пакета
Рис. 11.5. Диаграмма видов деятельности для процесса создания документа
Роли на диаграмме видов деятельности
Одним из важнейших аспектов диаграммы видов деятельности является возмож-
ность добавлять расширения, в которых указываются ответственные за выполнение
каждого вида деятельности в процессе.
11-й час. Диаграммы видов деятельности
159
Рассмотрим консалтинговую фирму и бизнес-процесс организации встречи с но-
вым клиентом. Последовательность видов деятельности будет следующей.
1. Агент договаривается с клиентом о встрече.
2. Если встреча планируется “на своем поле” (в офисе консалтинговой фирмы),
то специалист по техническому обеспечению готовит конференц-зал для пе-
реговоров.
3. Если встреча состоится “на чужом поле” (в офисе клиента), консультант гото-
вит всю необходимую документацию на переносном компьютере.
4. Консультант и агент встречаются с клиентом в назначенном месте и в огово-
ренное время.
5. Агент готовит документы о результатах встречи.
6. Если результат встречи положителен и задача сформулирована, консультант
оформляет предложение и отправляет его клиенту.
Стандартная диаграмма видов деятельности изображена на рис. 11.6.
На диаграмме видов деятельности можно отразить роли участников процесса. Для
этого диаграмму разбивают вертикальными пунктирными линиями на сегменты, на-
поминающие плавательные дорожки. В верхней части каждой дорожки указывается
название роли. На дорожке отображаются виды деятельности для каждой роли. Между
дорожками могут быть переходы. На рис. 11.7 изображена версия диаграммы видов
деятельности из рис. 11.6 с “плавательными дорожками” для процесса подготовки
встречи с новым клиентом.
Использование примечания
На обеих диаграммах для процесса подготовки встречи с новым клиентом создание пред-
ложения описывается как вид деятельности. В каждом случае для этого вида деятельности
можно добавить примечание со ссылкой на диаграмму видов деятельности по созданию до-
кумента.
Смешанные диаграммы
Вернемся к диаграмме видов деятельности по созданию документа. Виды деятель-
ности по распечатке копии документа можно уточнить. Добавим некоторые детали к
виду деятельности “Печать документа”. Процесс печати начинается после того, как
сигнал с указанием имени файла документа передается из текстового процессора на
принтер, на котором и распечатывается документ.
На рис. 11.8 этот процесс изображен с использованием символов передачи и полу-
чения сигнала. Сигнал передается в направлении объекта печатающего устройства,
который получает сигнал и выполняет распечатку. Такая диаграмма называется сме-
шанной, поскольку в ней используются символы, относящиеся к разным типам диа-
грамм.
160
Часть I. Начало
Договор о встрече
[нет постановки задачи]
Рис. 11.6. Диаграмма видов деятельности для бизнес-процесса встречи с новым
клиентом
11-й час. Диаграммы видов деятельности
161
Рис. 11.7. Указание ролей на диаграмме видов деятельности
См. диаграмму
видов
деятельности
по созданию
документа
162
Часть I. Начало
Открытие текстового процессора
Создание
Сохранение
Ввод документа
[графика нужна]
Открытие и использование графического пакета
[графика не нужна]
[таблицы нужны]
Открытие и использование электронной таблицы
[таблицы не нужны]
Рис. 11.8. Уточнение вида деятельности “Печать документа” приводит к созданию сме-
шанной диаграммы
11-й час. Диаграммы видов деятельности
163
Новые понятия в UML 2.0
Объекты вида деятельности
В новой версии UML появилась возможность задавать входную и выходную ин-
формацию для вида деятельности с помощью узлов объектов. Для иллюстрации этого
понятия рассмотрим математический пример, позволяющий разобраться с новыми
понятиями в UML.
Ряд чисел 1, 1, 2, 3, 4, 8, 13, ... называется числами Фибоначчи, по имени средне-
векового математика, жившего около 800 лет назад. Каждое число называется
“фибом”. Таким образом, первый “фиб”, или “фиб(1)”, — это 1, “фиб(2)” — 1,
“фиб(З)” — 2 и т.д. Ряд строится на основе того, что каждый последующий “фиб” (за
исключением двух первых) является суммой двух предыдущих, т.е. “фиб”(8)=21.
Вычисление чисел Фибоначчи представим в виде вида деятельности. Для этого
внутри обозначения вида деятельности запишем вычислитьФиб (п). Это обозначение
можно соединить с другим видом деятельности, представляющим вывод полученного
значения на печать. На рис. 11.9 показана диаграмма с примечанием, описывающим
формат вывода информации.
Для реализации первого вида деятельности необходимо ввести значение п. В ре-
зультате вычисления n-ого “фиба” нужно вывести ответ и передать его в качестве
входной информации следующему виду деятельности. Заодно нужно передать и зна-
чение п, чтобы оно тоже выводилось при печати.
Для отображения входной информации к левой границе первого вида деятельности
добавляется маленький прямоугольник, метка которого определяет входное значение.
Для отображения выходной информации аналогичный прямоугольник добавляется к
правой границе вида деятельности. Эти прямоугольники называются узлами объекта.
Аналогичный узел объекта определяет входные данные для второго вида деятельности.
На рис. 11.10 показана диаграмма видов деятельности, представленная на рис. 11.9, с
добавленными к ней узлами объекта.
Формат.
"п-ый фиб:" Ответ
Рис. 11.9. Диаграмма видов деятельности, моделирующая вы-
числение и печать числа Фибоначчи
Формат.
"п-ый фиб:" Ответ
п вычислитьФиб(п)
вывестиФиб(п)
Рис. 11.10. Добавление узлов объекта позволяет задавать входные и вы-
ходные данные вида деятельности
164
Часть I. Начало
Если узлы объекта слишком загромождают диаграмму, можно использовать сокра-
щенную форму обозначений, представленную на рис. 11.11.
п, Ответ
вычислитьФиб(п)
вычислитьФиб(п)
п, Ответ
Рис. 11.11. Сокращенные обозначения, эквивалентные
представленным на рис. 11.10
Исключения
Иногда реализация вида деятельности генерирует исключение — неординарное об-
стоятельство, выходящее за рамки возможностей объекта. Например, калькулятор не
может вычислить числа Фибоначчи, индекс которых превышает 1 миллион. Если п
принимает значение больше миллиона, нужно вывести значение п и сообщение
"Превышен предел п".
Чтобы представить эту ситуацию на диаграмме видов деятельности используют ли-
нию со стрелкой в форме молнии. Она начинается с вида деятельности, генерирую-
щего исключение, и заканчивается у вида деятельности, описывающего перечень дей-
ствий, выполняемых в исключительной ситуации. Этот вид деятельности называется
обработчиком исключения (рис. 11.12).
Формат.
"п-ый фиб:" Ответ
Рис. 11.12. Моделирование исключения и его обработчика
11-й час. Диаграммы видов деятельности
165
Декомпозиция видов деятельности
В UML 2.0 большое значение уделяется декомпозиции видов деятельности. Каж-
дый вид деятельности может состоять из множества действий, обозначаемых так же,
как и виды деятельности. Вернемся к задаче вычисления чисел Фибоначчи и выделим
действия, составляющие вид деятельности вычислитьФиб (п).
Для того чтобы промоделировать процесс вычисления “фиба”, понадобится не-
сколько переменных и счетчик, показывающий, дошел ли процесс вычислений до п-
ого “фиба”. Необходима также переменная для хранения текущего результата вычис-
лений (назовем ее Ответ) и еще две переменные для хранения двух “фибов”, которые
будут суммироваться (назовем их Ответ1 и Ответ2). На рис. 11.13 изображена после-
довательность действий и принятия соответствующих решений. Согласно принятым в
UML 2.0 соглашениям, последовательность действий заключена в кадр, расположен-
ный внутри обозначения более крупного вида деятельности вычислитьФиб(п).
К действиям тоже можно добавлять узлы объектов, которые в данном случае назы-
ваются выводами. На рис. 11.14 показано несколько действий вида деятельности вы-
числитьФиб (п) с соответствующими входными и выходными выводами. Несложно
заметить, что символ вывода меньше символа узла объекта для вида деятельности, а
его название пишется снаружи обозначения вывода. В качестве упражнения дополни-
те выводами остальные действия вида деятельности вычислитьФиб (п).
Рис. 11.13. Моделирование действий, составляющих вид деятельно-
сти вычислитьФиб(п)
166
Часть I. Начало
Рис. 11.14. Часть рис. 11.13
с добавленными выводами
Изображение длительности и момента
завершения вида деятельности
На рис. 11.15 показаны новые символы UML, предназначенные для уточнения диа-
грамм видов деятельности. Символ слева, напоминающий песочные часы, обозначает
период времени. Справа изображен завершающий узел, символизирующий окончание
последовательности видов деятельности без завершения остальных видов деятельности.
Он аналогичен обозначению конечной точки на диаграмме состояний из главы 8.
Хорошим примером, иллюстрирующим применение этих обозначений на диа-
грамме видов деятельности, является моделирование любимых автором цифровых на-
ручных часов, которые автоматически переустанавливаются каждое утро. В обычном
режиме информация на циферблате часов обновляется каждую секунду.
С 2 до 5 часов утра часы работают в другом режиме. Каждый час (в 2 часа ночи,
3 часа, 4 часа и 5 часов) эти часы переходят из режима отображения времени в режим
отображения калибровочного сигнала от атомных часов, расположенных в штате Ко-
лорадо. По завершении сеанса приема информации, который длится от 3 до 6 минут,
часы отображают откалиброванное время и переходят в нормальный режим работы.
Если сигнал прерывается, например в связи с неблагоприятными погодными усло-
виями, сеанс приема прерывается, и часы снова переходят в режим отображения вре-
мени. Этот процесс показан на рис. 11.16.
Во избежание перегрузки диаграммы при изображении времени в виде узла объек-
та используется сокращенная форма обозначений. В этом формате видно, что выход-
ная информация одного вида деятельности является входной для другого. Время
приема сигнала промоделировано как исключение. Это разумно, если учесть, что часы
в обычном режиме должны отображать время с точностью до секунды. Исключением
также является прерывание сигнала, при котором завершается сеанс приема
(калибровки), что не влияет на остальные действия часов.
Рис. 11.15. Обозначения UML 2.0
для диаграммы видов деятельности.
Слева показан символ, обозначаю-
щий период времени, а справа —
символ момента завершения после-
довательности видов деятельности
11-й час. Диаграммы видов деятельности
167
Рис. 11.16. Модель часов, которые каждое утро автоматически переуста-
навливают точное время на основе сигнала атомных часов в штате Колора-
до. Если калибровочный сигнал прерывается, часы возвращаются в режим
отображения времени
Специальные эффекты
Использование объектов на диаграмме видов деятельности открывает новые воз-
можности моделирования. Можно ввести обозначения для отображения влияния вида
деятельности (или отдельного действия) на объект.
Приведем лишь один из примеров такого влияния (хотя их может быть множест-
во). Автор очень любит смотреть видеофильмы через Internet. (Он — фанат бейсбола,
а у читателей могут быть другие предпочтения.) Построим модель передачи и приема
этого типа видеоинформации.
На рис. 11.17 показана модель с “плавательными дорожками”. Одна дорожка пред-
ставляет сервер, другая — клиента. Сервер передает клиенту видеосигнал, изображен-
ный в виде выходного объекта. Для клиента этот видеосигнал является входным объ-
ектом. Каждое вхождение слова {поток} в фигурных скобках означает, что данный
вид деятельности является непрерывной операцией: вид деятельности “Отображение
видео” не ожидает завершения действия “Отправка видео”. Благодаря такой органи-
зации процесса не приходится часами ожидать, пока полностью загрузится огромный
файл мультимедиа.
168
Часть I. Начало
Рис. 11.17. Моделирование влияния вида деятельности на объект.
В данном случае символ {поток} обозначает непрерывную операцию:
для реализации вида деятельности “Отображение видео ” не нужно
ждать завершения действия “Отправка видео ”
Обзорная диаграмма взаимодействия
В главе 9, “Диаграммы последовательностей”, речь шла о комбинировании диа-
грамм последовательности. При этом было сказано, что в главе 11 будет показан еще
один способ комбинирования. Самое время поговорить об этом.
В UML 2.0 появился новый вид модели — обзорная диаграмма взаимодействия, ко-
торая представляет собой комбинацию диаграммы видов деятельности и диаграммы
взаимодействия. Обзорная диаграмма взаимодействия — это диаграмма видов дея-
тельности, на которой каждый вид деятельности представлен отдельной диаграммой
взаимодействия.
Чтобы проиллюстрировать сказанное, вернемся к модели автомата для продажи
лимонада. Для удобства еще раз приведем рис. 9.13 под номером 11.18. Это общая
диаграмма последовательности для прецедента Покупка лимонада.
Как представить эту последовательность взаимодействия объектов в ракурсе диа-
граммы видов деятельности? Условия переходов для сообщений нужно поместить на
линиях, соединяющих диаграммы последовательностей. Придется также удалить сте-
реотип <<транзакция завершена>>, поскольку он больше не нужен. На этой диа-
грамме завершение транзакции моделируется обычным для диаграмм видов деятель-
ности способом — стрелка направлена на точку завершения.
При создании этой диаграммы основное время придется уделить построению от-
дельных диаграмм последовательности, которые затем будут связаны друг с другом.
Воспользуемся рис. 11.18. Результат показан на рис. 11.19. Автор упростил ситуацию,
установив стоимость покупки $0,00.
11-й час. Диаграммы видов деятельности
169
:Клиент
:ЛицеваяПанель
;Реестр
:Отсек
принять(сумма, выбор)
i
I
I
I
получитьЗаказКлиента(сумма, выбор)
[нет сдачи]вернутьДеньги(сумма)
[сумма>цена]
проверитьСдачу(сумма, цена)
«транзакция завершена»вывести
Сообщение(‘Используйте другую сумму")
^[нет выбора]
вывестиСообщение(‘Нет выбора*)
«транзакция завершена»
[нет выбора]вернутьДеньги(сумма)
[сумма>цена]
получитьСдачу(сдача)
«транзакция завершена» »
I [есть выбор]получитьЛимонад(выбор)
I *
проверитьНаличие(выбор)
| обновить(сумма, цена)
выдатьЛимонад(выбор)
I
I
I
।
Рис. 11.18. Общая диаграмма последовательностей для прецедента Покупка лимонада
Обратите внимание на кадр общей диаграммы и кадры отдельных диаграмм после-
довательности. Согласно принятым в UML 2.0 обозначениям, в левом верхнем углу
каждого кадра содержится ячейка с идентификационной информацией. Оператор sd
означает диаграмму последовательности (от английского sequence diagram). Метка
большого кадра содержит имя прецедента и имена взаимодействующих объектов.
(В UML 2.0 принято указывать имена объектов, используемые в диаграмме последо-
вательности. Поэтому мы тоже будем придерживаться этого.)
Кадры на диаграмме напоминают описанные в главе 9 включения — фрагменты
диаграммы последовательности, которым можно присвоить имя, а затем многократно
использовать. Эти включения можно многократно использовать и на обзорной диа-
грамме взаимодействия.
Вернемся к рис. 9.18. В основном успешном сценарии прецедента Покупка лимо-
нада сообщения доставить (Выбор) и получить (Выбор) выделены в отдельное
включение под названием доставить (Выбор), которое повторно используется на
рис. 9.19.
На обзорной диаграмме включение доставить (Выбор) соответствует нижней
диаграмме последовательности. На рис. 11.20 этот фрагмент диаграммы показан более
подробно. Из этого рисунка видно, как повторно использовать включение доста-
вить (Выбор).
170
Часть I. Начало
sd Покупка лимонада линии жизни :Покупатель, :ЛицеваяПанель,:Реестр, :Отсек
Рис. 11.19. Обзорная диаграмма взаимодействий для прецедента Покупка лимонада
11-й час. Диаграммы видов деятельности
171
Рис, 11.20. Повторное использование включения для одной из диаграмм после-
довательности на рис. 11.19
Построение общей картины
На рис. 11.21 к общей картине UML добавлена диаграмма видов деятельности. Эта
диаграмма является поведенческим элементом.
Структурные элементы
Поведенческие элементы
О
Интерфейс
Состояние
Класс
Исполнитель
Взаимосвязи
Группировка
Ассоциация
Обобщение
Зависимость
Реализация
Последовательность событий
Пакет
Расширение
<<стереотип>>
{ограничение}
Коммуникация
Аннотация
Вид деятельности
Рис. 11.21. В общую картину UML теперь включе-
на диаграмма видов деятельности
172
Часть I. Начало
Резюме
Диаграмма видов деятельности UML очень похожа на блок-схему. С ее помощью
описывают виды деятельности, точки принятия решений и ветвления.
Каждый вид деятельности изображается в виде прямоугольника со скругленными
углами, более вытянутого и овального, чем обозначение состояния. Для обозначения
начальной и конечной точки в диаграмме видов деятельности используются такие же
символы, как и в диаграмме состояний.
Разветвление одного пути на два или более изображается в виде непрерывной
жирной линии, перпендикулярной им. Соединение путей представляют в виде такой
же линии. На определенном этапе последовательности видов деятельности можно пе-
редать сигнал. Отправка и получение сигнала изображается в виде выпуклого и вогну-
того пятиугольника, соответственно.
С помощью диаграммы видов деятельности можно описывать виды деятельности
для каждой роли. Для этого диаграмма разбивается на “плавательные дорожки” — па-
раллельные сегменты, соответствующие ролям.
В диаграмму видов деятельности можно добавлять символы из других диаграмм,
т.е. строить смешанную диаграмму.
В UML 2.0 появились многочисленные новые обозначения для диаграмм видов
деятельности. В новой версии UML основное внимание уделяется элементам дейст-
вий и объектам, связанным с видами деятельности и передаваемым от одного вида
деятельности другому.
Обзорная диаграмма взаимодействия обеспечивает общий каркас диаграммы видов
деятельности, элементами которой являются диаграммы взаимодействия.
Вопросы и ответы
Зачем нужны диаграммы видов деятельности, если можно обойтись диаграммами со-
стояний?
Рекомендуется включать в анализ и такие диаграммы. С их применением многие
аспекты процессов и операций станут более ясными для вас и ваших клиентов. Эти
диаграммы очень полезны и для разработчиков. Однако диаграммам видов деятельно-
сти нужно еще пройти долгий путь, прежде чем они смогут оказывать существенную
помощь при написании программного кода.
Существуют ли в UML ограничения при создании различных смешанных диаграмм?
В UML не существует ограничений. Несмотря на наличие синтаксических правил,
задача аналитиков состоит не в том, чтобы слепо подчиняться правилам, а в том, что-
бы построить модель, которая смогла бы дать четкую картину заказчику, проектиров-
щикам и разработчикам. Если вы способны построить смешанную диаграмму, которая
поможет всем заинтересованным лицам организовать свое дело, то, как говорится,
флаг вам в руки. Однако помните, что не все средства моделирования обеспечивают
достаточную гибкость при создании смешанных диаграмм.
При внимательном изучении рис. 11.12 создается впечатление, что узлы объектов
предназначены для передачи значений от одного вида деятельности другому. Верно ли,
что эти диаграммы предназначены для отображения передачи информации?
Абсолютно верно. Основная задача диаграммы видов деятельности, особенно в
UML 2.0, — отобразить в последовательности видов деятельности передачу маркера —
фрагмента информации или фокуса управления. Эта идея пришла из метода модели-
рования, возникшего в 1960-е годы и получившего название сетей Петри. Добавление
узлов объектов и выходов в UML 2.0 позволяет сделать диаграммы видов деятельно-
сти более объектно-ориентированными.
11-й час. Диаграммы видов деятельности
173
Изучение обзорной диаграммы взаимодействия натолкнуло меня на мысль, что диа-
грамму видов деятельности можно считать промежуточным шагом на пусти к созданию
общей диаграммы последовательности. Можно начать с изображения видов деятельности,
а затем вместо каждого из них подставить диаграмму взаимодействия. Такая комбинация
приводит к общей диаграмме последовательности. Верно ли это?
Это хорошая идея. Такой процесс является обратным к процессу построения диа-
граммы, показанной на рис. 11.19. Однако можно двигаться и в этом направлении.
Многие специалисты предпочитают сначала строить диаграммы видов деятельности.
Я заметил, что вы используете диаграммы последовательностей как части обзорной
диаграммы взаимодействия. Можно ли вместо них использовать диаграммы кооперации,
простите, коммуникации?
Да, можно. В обзорную диаграмму взаимодействия можно включать любой вид
диаграммы взаимодействия. Можно использовать одновременно оба вида диаграмм,
но это может сбить с толку ваших клиентов.
“Плавательные дорожки” обычно отображают в виде вертикально ориентированных
компонентов. Можно ли расположить их горизонтально?
Да, их можно представить в любом виде. Автор предпочитает вертикальную ориен-
тацию, но вы можете положиться на свой вкус.
Практические занятия
Тесты и упражнения помогут закрепить понятия о диаграммах видов деятельности
и их применении. Ответы находятся в приложении А.
Тесты
1. Назовите два способа описания точки принятия решений.
2. Что такое “плавательная дорожка”?
3. Как описать передачу и получение сигнала?
4. Что такое действие?
5. Что такое узел объекта?
6. Что такое выход?
Упражнения
1. Постройте диаграмму видов деятельности, которая описывает, как заводится
автомобиль. Начните со вставки ключа в зажигание и закончите запуском
двигателя. При этом необходимо учесть вид деятельности, который активизи-
руется, если двигатель не заработает сразу.
2. Что можно добавить в диаграмму видов деятельности для процесса подготовки
встречи с новым клиентом?
3. Если выложить три камня таким образом, чтобы они не лежали на одной ли-
нии, то получится треугольник. Если выложить шесть камней так, чтобы один
был на одной линии, два — на другой, а три — на третьей, то получится тоже
треугольник. По этой причине, числа 3 и 6 называются “треугольными” числа-
ми. Следующее такое число — 10, затем идет 15, и т.д. Первое “треугольное”
число — 1. Постройте две различные диаграммы видов деятельности для про-
цесса подсчета n-ого “треугольного” числа. Например, начните спи двигай-
тесь в обратном направлении. Или начните с 1 и двигайтесь вперед. (Легко
174
Часть I. Начало
подметить, что n-ое число равно [(п)(п+1)]/2. Но чтобы получить максималь-
ную пользу от этого упражнения, лучше не использовать данную формулу.)
4. Следующее задание для людей, разбирающихся в математике. Если упражне-
ние 3 решалась легко, то и с этим можно справиться. Если же нет, то перехо-
дите к следующей главе. (Читатель мог бы уже построить диаграмму на основе
двух предыдущих предложений!) В геометрии точка в пространстве задается
координатами х и у. Таким образом, можно сказать, что положение точки 1 —
это [Х1,У1]. Положение точки 2 — [X2,Y2]. Чтобы найти расстояние между
ними, нужно возвести в квадрат выражения [Х2-Х1] и [Y2-Y1]. Затем сложить
возведенные в квадрат выражения и извлечь квадратный корень из суммы.
Постройте диаграмму видов деятельности для операции вычислитьРасстоя-
ние (Xi, Y1,X2, Y2), с помощью которой определяется расстояние между дву-
мя точками.
11-й час. Диаграммы видов деятельности
175
12-й час
Диаграммы компонентов
Из этого часа вы узнаете
> Что такое компонент
> Как моделировать компоненты и интерфейсы
> Что такое диаграмма компонентов
> Как применять диаграммы компонентов
> Какое место занимают диаграммы компонентов в общей картине UML
В предыдущих главах рассматривались диаграммы, относящиеся к абстрактным
логическим объектам. С помощью диаграммы классов описывают понятие — некую
абстракцию или категорию. С помощью диаграммы состояний описывают другое по-
нятие — изменение состояния объекта.
В этой главе будут изучены диаграммы UML, с помощью которых описываются
другие сущности — компоненты программного обеспечения или программные компоненты.
Что такое компонент
Программный компонент является модулем или частью системы. Поскольку он содер-
жит реализацию одного или нескольких классов, то находится в компьютере, а не в вооб-
ражении аналитиков. Компонент обеспечивает интерфейс с другими компонентами.
В UML 1.x компонентами считались таблицы, файлы данных, исполняемые фай-
лы, документы и динамически подключаемые библиотеки. На самом деле для уточне-
ния этих понятий при моделировании эти типы элементов назывались компонентами
развертывания, рабочими и исполняемыми компонентами. В UML 2.0 все эти понятия
называют общим именем — артефакт, под которым подразумевают фрагмент ин-
формации, используемый или генерируемый системой.
В отличие от артефакта, компонент определяет функциональность системы. Он
представляет собой программную реализацию одного или нескольких классов. Следо-
вательно, артефакт (исполняемый) — это реализация компонента.
Модели компонентов и их взаимосвязей строят в следующих целях.
1. Клиенты смогут увидеть структуру законченной системы.
2. Разработчики смогут представить себе структуру будущей работы.
3. Редакторы, ответственные за предоставление документации и файлов справки,
смогут лучше понять суть разработки.
4. Компоненты можно будет использовать многократно.
Давайте проанализируем последнее утверждение. Одним из важнейших аспектов
компонентов является потенциальная возможность их многократного использования.
В современном стремительно развивающемся мире бизнеса быстрая разработка дает
преимущества перед конкурентами. В более выгодном положении оказывается тот, кто
может построить компонент для одной системы и многократно использовать его для
других. Повторное использование компонентов сэкономит много времени и усилий.
Вопрос о многократном использовании компонентов будет более подробно рас-
смотрен в конце следующего раздела.
Компоненты и интерфейсы
Работая с компонентами, приходится иметь дело с их интерфейсами. Интерфейсы
уже рассматривались при изучении классов и объектов. Как вы помните из главы 2,
“Знакомство с объектно-ориентированным подходом44, внутренние операции объекта
скрыты от других объектов и окружающей среды. (Это называется инкапсуляцией или
сокрытием информации.) Объект должен “показать лицо” окружению, чтобы другие
объекты (в том числе и люди), могли давать объекту указания о выполнении опера-
ций. Этим “лицом” и является объектный интерфейс.
Несколько слов об интерфейсах
Эта идея детально рассматривалась в главе 5, “Агрегация, композитные объекты,
интерфейсы и реализации”. Как было упомянуто, интерфейс — это набор операций,
который определяет поведение класса (подобно управляющей панели стиральной ма-
шины, с помощью которой можно обеспечить выполнение операций, связанных со
стиркой белья). Интерфейс можно представить как класс с одними операциями, без
атрибутов. Таким образом, интерфейс — это набор операций, которые класс предос-
тавляет другим классам.
При обсуждении интерфейсов в главе 5 было сказано, что связь между классом и
его интерфейсом называется реализацией.
Таким образом, получается, что моделирование интерфейса — это упражнение по
моделированию понятия. В начале этой главы было сказано, что при моделировании
компонента отражается не абстрактная, а конкретная, связанная с компьютером ин-
формация. Так где же связь?
На самом деле интерфейс может быть и абстрактным, и физическим. Интерфейс,
используемый классом, такой же, как и интерфейс его программной реализации
(компонента). Для разработчика моделей это означает, что способы описания интер-
фейсов класса и компонента одинаковы. Несмотря на то что символика UML для
класса отличается от символики для компонента, разница между абстрактным и фи-
зическим интерфейсом отсутствует.
12-й час. Диаграммы компонентов
177
Очень важно помнить, что операции компонента выполняются только через ин-
терфейс. Как и в случае класса, связь между компонентом и его интерфейсом называ-
ется реализацией.
Еще один важный момент. Интерфейс компонента может быть открытым, и опе-
рации этого интерфейса могут использоваться другими компонентами. Другими сло-
вами, компонент может получать доступ к услугам другого компонента. Говорят, что
компонент, обеспечивающий доступ, предоставляет экспортируемый интерфейс. Для
компонента, который пользуется таким доступом, этот интерфейс называется импор-
тируемым.
Замещение и повторное использование
Важные понятия замещения и повторного использования компонентов довольно
легко распространить и на интерфейсы. Один компонент можно заменить другим, ес-
ли новый компонент имеет такой же интерфейс.
Чтобы проиллюстрировать идею замены компонентов с общим интерфейсом, при-
ведем пример из мира автомобилей. Несколько лет назад мой друг приобрел класси-
ческий спортивный автомобиль, выпущенный в конце 60-х годов прошлого века. (Не
станем здесь называть производителя.) Счастливый обладатель покупки довольно бы-
стро убедился, что для полного счастья ему не хватает одной важной детали — еще
одного автомобиля, позволяющего доставить покупку в место постоянной дислока-
ции. Дело в том, что двигатель вновь купленной машины находился в абсолютно не-
пригодном состоянии и требовал капитального ремонта. К счастью, друг смог заме-
нить его на менее мощный, но более надежный стандартный двигатель от другого ав-
томобиля. Это стало возможным благодаря тому, что новый двигатель, разработанный
для совсем другой модели машины, обеспечивал нужный интерфейс с остальными
компонентами спортивного автомобиля.
Это хорошая иллюстрация использования интерфейсов. Компонент можно по-
вторно использовать в другой системе, если она имеет доступ к этому компоненту че-
рез его интерфейсы. Можно создать компонент, который в ходе разработки проектов
подошел бы всему предприятию, а не только одному из отделов. Для этого интерфейс
компонента нужно устроить таким образом, чтобы к нему мог иметь доступ широкий
класс других компонентов.
Вот тут-то и приходит на помощь моделирование интерфейсов. Разработчику, ко-
торый пытается заменить или повторно использовать компонент, будет гораздо удоб-
нее, если информация компонентного интерфейса легко доступна в форме модели.
Если же — нет, разработчик вынужден идти более длинным путем обратного проек-
тирования (реинжиниринга) на основе кода.
Что такое диаграмма компонентов
Диаграмма компонентов содержит компоненты, интерфейсы и их взаимосвязи.
В ней также могут участвовать и другие типы обозначений, которые уже были изучены.
Представление компонента в UML 1.x
и UML 2.0
В UML 1.x главное обозначение диаграммы компонентов имеет вид прямоуголь-
ника, на левую сторону которого наложены еще два прямоугольника. Многие специа-
листы по моделированию считают это обозначение из UML 1.x несколько громозд-
178
Часть I. Начало
ким. Оно является особенно неудобным, если слева от изображения компонента нуж-
но показать его связи. Поэтому в UML 2.0 появилось новое обозначение компонента.
Теперь он изображается в виде прямоугольника с ключевым словом <<компонент>> в
его верхней части. При этом для преемственности обозначений внутри нового симво-
ла из UML 2.0 можно размещать обозначение компонента из UML 1.x. Все эти обо-
значения показаны на рис. 12.1. Внутрь пиктограммы помещается имя компонента в
виде строки.
Рис. 12.1. Обозначение компонента в UML 1.x и две версии
пиктограммы компонента в UML 2.0
Из рис. 12.2 видно, что, если компонент является элементом пакета, имя пакета
можно указать перед именем компонента. Можно также добавить информацию об
операциях компонента.
<<компонент>>
tools: Calculator
add ()
substract()
multiply()
divide()
Рис. 12.2. Добавление
информации к обозна-
чению компонента
На рис. 12.3 показаны два обозначения артефакта, а также способ моделирования
взаимосвязи между конкретным видом артефакта (исполняемым кодом) и реализую-
щим его компонентом. К обозначению артефакта можно добавить его пиктограмму
(аналогично добавлению пиктограммы компонента из UML 1.x к новому обозначе-
нию компонента).
Представление интерфейсов
Компонент и реализуемые им интерфейсы можно представить двумя способами.
Первый предполагает изображение интерфейса в виде прямоугольника, который со-
держит всю необходимую информацию. Он соединяется с компонентом пунктирной
линией со стрелкой в виде треугольника, обозначающей реализацию (рис. 12.4).
12-й час. Диаграммы компонентов
179
Рис. 12.3. Моделирование взаимосвязи между артефак-
том и компонентом
<<компонент>>
Calculator
Рис. 12.4. Интерфейс можно представить в
виде прямоугольника, содержащего необходи-
мую информацию и связанного с компонентом
На рис. 12.5 показан другой способ описания. Интерфейс изображается в виде ма-
ленького кружка, соединенного с компонентом сплошной линией. (Сравните
рис. 12.4 и 12.5 с рис. 5.6 и 5.7.)
Рис. 12.5. Интерфейс можно предста-
вить в виде маленького кружка, соеди-
ненного с компонентом сплошной линией
180
Часть I. Начало
В дополнение к реализации можно изобразить зависимость — связь между компо-
нентом и интерфейсом, с помощью которого осуществляется доступ к другому ком-
поненту. Напомним, что зависимость обозначается пунктирной линией со стрелкой.
Реализацию и зависимость можно изобразить на одной диаграмме, как это сделано на
рис. 12.6. Нижняя диаграмма на рис. 12.6 соответствует сокращенным обозначениям,
описанным в главе 5. В использованной ранее терминологии кружок обозначает экс-
портируемый интерфейс, а гнездо — импортируемый.
Рис. 12.6. Два способа изображения реализации и зависимости на
одной диаграмме
Модели черного и белого ящика
При изображении интерфейсов компонента (см. рис. 12.6) используется так назы-
ваемое внешнее представление UML (модель “черного ящика”). Можно изобразить и
внутреннее представление (модель “белого ящика”). При этом интерфейсы помеща-
ются внутрь изображения компонента и помечаются ключевыми словами. На
рис. 12.7 показана модель “белого ящика” для компонентов, представленных на
рис. 12.6.
<<компонент>>
Calculator
сспредоставляемый интерфейс»
Key
Рис. 12.7. Представление компонентов, изображенных на
рис. 12.6, в виде модели “белого ящика”
12-й час. Диаграммы компонентов
181
Применение диаграмм компонентов
Несколько примеров помогут детально разобраться с диаграммами компонентов. В
данном примере промоделируем программу, описанную в книге Роджерса Каденхеда
(Rogers Cadenhead) Teach Yourself Java 2 in 24 Hours, Third Edition (Sams Publishing). Эта
книга написана очень хорошим языком. Автор настоятельно рекомендует прочитать
ее всем, кто желает быстро изучить язык Java.
Данный пример описан в главе 16 упомянутой выше книги. На языке Java создает-
ся приложение Color Slide. В диалоговом окне программы находятся три бегунка,
позволяющие смешивать красный, зеленый и синий цвета для создания новых цветов.
Положение каждого бегунка определяет количество данного цвета в формируемом но-
вом цвете. При этом созданный цвет отображается на панели, расположенной под
бегунками.
На рис. 12.8 показано окно этой программы. Поскольку этот рисунок содержит
лишь оттенки серого цвета, вы не сможете увидеть созданный цвет. На самом деле та-
кое положение бегунков определяет зеленый цвет, который является символом уни-
верситета штата Техас.
Рис. 12.8. Приложение Color-
Slide Роджерса Каденхеда из
книги Teach YourseluJava 2
in 24 Hours, Third Edition
Чтобы лучше понять принцип действия программы, рассмотрим несколько диа-
грамм компонентов. При этом можно не только разобраться со структурой програм-
мы, но и освоить некоторые приемы моделирования.
На рис. 12.9 показаны пакеты, содержащие используемые в программе элементы
Java. Аббревиатура awt расшифровывается как Abstract Windowing Toolkit — абстракт-
ный набор компонентов для работы с окнами графического интерфейса пользователя
(GUI). В данной программе используются компоненты Color (для отображения цве-
та), GridLayout и FlowLayout (для упорядочения элементов GUI), а также Graphics
и Graphics2D (для отображения элементов GUI, т.е. перерисовки экрана).
Другой пакет называется swing. Он содержит набор компонентов, которые можно
добавлять к графическому интерфейсу пользователя. Имена компонентов пакета, по-
казанных на этом рисунке, говорят сами за себя: JSlider — бегунок, JFrame —
фрейм, JPanel — панель (область внутри фрейма) и JLabel — метка.
Пакет swing.event содержит интерфейс ChangeListener, который ожидает из-
менения состояния интерфейса пользователя.
182
Часть I. Начало
awt
swing
«компонент»
Color
«компонент»
Graphics
«компонент»
JFrame
«компонент»
JSlider
«компонент»
JPanel
«компонент»
GridLayout
«компонент»
FlowLayout
«компонент»
Graphics2D
«компонент»
JLabel
Рис. 12.9. Пакеты, содержащие элементы Java для приложения ColorSlide
На рис. 12.10 показаны результаты анализа компонентов на самом высоком уров-
не. Из этого рисунка видно, что приложение ColorSlide наследует свойства компонен-
та JFrame и реализует интерфейс ChangeListener. Взаимодействие между
ChangeListener и ColorSlide осуществляется через порт. Результат этого взаимо-
действия передается компоненту Color, что отображается линией связи между этими
компонентами со стрелкой на конце. В UML 2.0 обозначение в виде кружочка с гнез-
дом используется для ансамблевого коннектора, а стрелка означает коннектор делегиро-
вания. (Понятие коннектора появилось только в UML 2.0.)
Рис. 12.10. Исходная диаграмма компонентов для
приложения ColorSlide
Заметим, что имена пакетов указываются в качестве префиксов имен компонентов.
(Строго говоря, пакет awt на самом деле называется java.awt, a swing.event —
javax. swing.event, но в книге для простоты используются сокращенные обозначе-
12-й час. Диаграммы компонентов
183
ния.) В начале кода Java-программы обычно используется оператор импортирования
пакетов, поэтому в самой программе разработчику не нужно каждый раз указывать
имя пакета. Следующие рисунки отражают импортирование пакетов, поэтому на них
имена пакетов не указываются.
Рис. 12.11 соответствует следующему уровню анализа. На нем показано, что
Colorslide является агрегатом, содержащим компоненты JSlider, JPanel и
Jlabel. При этом указана кратность ассоциации. Поскольку в программе использу-
ются три основных цвета (красный, зеленый и синий), диалоговое окно содержит три
бегунка и три метки. При этом в окне имеется четыре панели: по одной для каждого
бегунка и одна для отображения полученного цвета.
Рис. 12.11. Агрегация компонентов в приложении Color Slide
Рис. 12.12 отражает взаимное расположение компонентов и перерисовку экрана.
Ключевое слово <<упорядочивает>> указывает на то, что компоненты GridLayout и
FlowLayout упорядочивают панели, бегунки и метки (не будем вдаваться в детали и
описывать, как это делается). Ключевое слово <<рисует>> означает, что компоненты
Graphics и Graphics 2D перерисовывают содержимое экрана (снова опускаем дета-
ли). Эти ключевые слова не входят в состав UML. Они добавлены для ясности.
184
Часть I. Начало
Рис. 12.12. Добавление компонентов Java, отвечающих за упорядочение элементов
GUI и перерисовку экрана
Читатель внимательно следивший за изложением, заметит некоторое несоответст-
вие. На рис. 12.11 и 12.12 JSlider изображен как компонент, a ChangeListener —
как интерфейс. Пользователь может создать цвет только с помощью бегунков. Каждое
перемещение бегунка приводит к изменению цвета на панели. Как же отразить взаи-
мосвязь между бегунками и интерфейсом?
Ответ на этот вопрос можно получить на следующем уровне анализа. При этом бу-
дет видно, что программа создает экземпляры компонентов GUI. Для изображения
экземпляров можно использовать обозначения объектов, изученные в главе 3. В Java
при создании объекта (например, экземпляра бегунка) его можно зарегистрировать в
списке прослушивания на предмет изменений. В этом случае перемещение бегунка
будет приводить к изменению результирующего цвета.
На рис. 12.13 показан результат такого детального анализа. Здесь показаны объек-
ты, входящие в состав ColorSlide. Теперь ChangeListener — импортируемый ин-
терфейс для трех экземпляров JSlider. Коннектор делегирования связывает порт с
объектом current — экземпляром класса Color. Объект canvas — это экземпляр
класса ColorPanel, который является дочерним для jpanel. Для полноты описания
отметим, что на рис. 12.13 показано отношение наследования между классами
ColorPanel И JPanel.
12-й час. Диаграммы компонентов
185
Рис. 12.13. Моделирование объектов для компонентов приложения ColorSlide
Зачем понадобилось создавать класс ColorPanel? Как зарегистрировать объект
как интерфейс? Как работают компоненты awt? Для этого нужно прочесть упомяну-
тую выше книгу по Java.
Диаграмма компонентов в общей
картине UML
Общая картина UML уже практически готова. На рис. 12.14 в нее включена диа-
грамма компонентов, с помощью которой описывается архитектура программного
обеспечения. В следующей главе будет рассмотрено моделирование архитектуры ап-
паратных средств.
186
Часть I. Начало
Структурные элементы
Поведенческие элементы
Класс
Имя компонента
(1.x)
Состояние
Исполнитель
Взаимосвязи
Интерфейс
«компонент»
Имя конпонента (2.0)
Ассоциация
Обобщение
Зависимость
Реализация
Последовательность событий
Группировка
Пакет
Расширение
«стереотип»
{ограничение}
Коммуникация
ср
а
Вид деятельности
Аннотация
--------ь.
Примечание
Рис. 12.14. В общую картину UML теперь включена диаграмма компонентов
Резюме
Диаграмма компонентов — это модульное представление компьютерной системы.
Артефакт — это фрагмент информации, который используется или создается в про-
граммной системе. Компоненты определяют функциональность программной системы.
Компонент обеспечивает интерфейсы доступа к нему для других программных
компонентов. Для компонента, использующего доступ к интерфейсу другого компо-
нента, этот интерфейс называется импортируемым.
В UML 1.x изображением компонента служил прямоугольник с двумя маленькими
прямоугольниками на его левой стороне. В UML 2.0 компонент обозначается прямо-
угольником с ключевым словом <<компонент>>. Для соблюдения преемственности
обозначений в UML 2.0 рекомендуется в верхнем правом углу нового обозначения
добавлять пиктограмму компонента из UML 1.x. Обозначение артефакта — это пря-
моугольник с ключевым словом <<артефакт>>. В верхнем правом углу можно ис-
пользовать символ комментария.
Интерфейс можно представить двумя способами. В одном случае — это прямо-
угольник, содержащий информацию об интерфейсе. Он соединяется с компонентом
пунктирной линией со стрелкой в виде полого треугольника. В другом случае — это
маленький кружок, соединенный с компонентом сплошной линией. В UML 2.0 для
12-й час. Диаграммы компонентов
187
изображения интерфейса, экспортируемого одним компонентом и импортируемого
другим, применяется кружочек с гнездом. При этом кружочек обозначает экспорти-
руемый интерфейс, а гнездо — импортируемый.
Вопросы и ответы
В рассмотренном выше примере речь шла о том, что один компонент предоставляет
экспортируемый интерфейс, а другой использует импортируемый. Может ли один компоС
нент иметь несколько интерфейсов?
Да, компонент может иметь несколько интерфейсов.
Практические занятия
Эти практические задания помогут закрепить знания о компонентах и их модели-
ровании. Ответы можно найти в приложении А.
Тесты
1. В чем разница между компонентом и артефактом?
2. Назовите два способа представления связи между компонентом и его интер-
фейсом.
3. Что такое экспортируемый интерфейс? Что такое импортируемый интерфейс?
Упражнения
1. Хотя UML 2.0 существенно отличается от UML 1.x, многие средства модели-
рования до сих пор поддерживают более ранние версии этого языка. Чтобы
попрактиковаться в использовании прежних стандартов, преобразуйте диа-
граммы, показанные на рис. 12.8—12.13, к обозначениям UML 1.x. При этом
вам придется не просто поменять обозначения. Напомним, что в UML 1.x не
существовало обозначений для портов и коннекторов.
2. Создайте представление “черного ящика” для компонента Colorsize.
188
Часть I. Начало
13-й час
Работа с диаграммами развертывания
Из этого часа вы узнаете
> Что такое диаграмма развертывания
> Применение диаграмм развертывания
> Место диаграмм развертывания в общей картине UML
До сих пор рассматривались абстрактные вопросы, и лишь в предыдущей главе
были затронуты модели программных компонентов. Сейчас самое время поговорить
об аппаратных средствах. В процессе изучения материала центр внимания постепенно
смещался от элементов (таких, как классы), используемых в процессе анализа, к
программным компонентам, а теперь и аппаратным средствам, т.е. реальному обору-
дованию.
Аппаратные средства очень важны в многокомпонентных системах. В современном
компьютерном мире такие системы являются распределенными, предоставляют боль-
шие возможности и могут использоваться на множестве различных платформ. Вопро-
сы развертывания аппаратных средств должны быть хорошо проработаны еще в про-
цессе проектирования. Язык UML предоставляет систему обозначений для создания
проекта развертывания аппаратных средств.
Что такое диаграмма развертывания
Диаграммы развертывания отражают способ воплощения артефактов (о которых
речь шла в главе 12, “Диаграммы компонентов”) в физической системе и способ со-
единения аппаратных средств между собой. Главным аппаратным элементом является
узел — общее название для любого вычислительного ресурса.
В UML 1.x зачастую выделяли два типа узлов: процессоры (узлы, выполняющие ко-
манды компонента) и устройства (периферийные аппаратные средства, которые не
выполняют команды компонентов, а осуществляют интерфейс с внешним миром).
Хотя такая классификация в UML 1.x не была формализована, она широко использо-
валась.
В UML 2.0 устройство формально определяется как узел, выполняющий артефак-
ты. (Напомним, что исполняемый код теперь называется артефактом.)
В UML 2.0 узел изображается в виде куба (как и в UML 1.x), с которым связано
определенное имя и необязательное ключевое слово <<устройство>>. По мнению ав-
тора, однако, желательно различать устройства и периферийные устройства. На
рис. 13.1 приведен пример графического изображения узла.
<<устроиство>>
Сервер базы данных
Рис. 13.1. Представление уз-
ла в UML
На рис. 13.2 показаны три способа моделирования артефактов, развернутых в рам-
ках узла.
Линия, соединяющая два куба, представляет соединение двух узлов. Примите во
внимание, что соединение — это не обязательно кусок провода или кабель. Сущест-
вуют также и беспроводные соединения, например, на основе инфракрасного излуче-
ния и спутниковой связи. На рис. 13.3 показан пример такого соединения.
Со смещением акцентов в сторону артефактов в UML 2.0 появилось множество
связанных с ними понятий. Одно из них — спецификация развертывания — артефакт,
обеспечивающий параметры для другого артефакта. Хорошим примером является ко-
манда инициализации, используемая для модемных соединений. Это строка симво-
лов, в которой задаются значения характеристик модема. На рис. 13.4 показана мо-
дель спецификации развертывания.
Для ясности к соединительной линии можно добавить ключевое слово
<<параметризует>>, хотя это ключевое слово не является частью спецификации
UML 2.0.
190
Часть I. Начало
Рис. 13.2. Три способа моделирования развертывания артефактов на узле
Рис. 13.3. Представление соединений между узлами
13-й час. Работа с диаграммами развертывания
191
<<спецификация развертывания>>
Команда инициализации
<<артефакт>>
Модемное соединение
Рис. 13.4. Представление спецификации развертывания и ее взаимосвязи с
параметризуемыми артефактами
Применение диаграмм развертывания
Поскольку лучше всего начать с домашней компьютерной системы, в качестве
первого примера рассмотрим диаграмму развертывания для системы, которая исполь-
зовалась при написании этой книги.
Как уже упоминалось, в современных многопроцессорных системах могут содер-
жаться узлы, расположенные далеко друг от друга. Для более полного представления
этой картины стоит также рассмотреть примеры диаграмм развертывания для сетей.
Приведенные диаграммы достаточно полезны и пригодны для использования в про-
фессиональной деятельности. В каждый пример включены ограничения, отражающие
правила построения сетей различных типов.
Домашняя система
В модель домашней системы автор включил необходимые устройства. Символом
узла обозначены дополнительные периферийные элементы. Как упоминалось выше,
иногда полезно разделять устройства и периферию, и данный пример еще раз под-
тверждает это.
Способ использования узла в данном контексте в UML 2.0 называется ненорма-
тивным. Строго говоря, в UML 2.0 узел представляет собой элемент аппаратных
средств, который может выполнять вычисления. Поскольку система содержит пери-
ферийные устройства, их логично включить в модель. Чтобы отличить периферийные
устройства от основных, соответствующие ненормативные узлы можно пометить клю-
чевым словом <<периферия>>. Однако это ключевое слово не входит в специфика-
цию UML. Имя такого ненормативного узла является достаточно информативным, и
применение дополнительных ключевых слов становится ненужным.
Диаграмма развертывания изображена на рис. 13.5. На ней показано широкопо-
лосное соединение с провайдером Internet и подключение к Internet самого провайде-
ра. Облако, представляющее Internet, и “молния”, символизирующая беспроводное
соединение, не являются стандартными обозначениями UML, но их использование
на диаграмме весьма полезно для повышения ясности модели. (О применении подоб-
ных символов речь пойдет в главе 14, “Пакеты и принципы построения UML”.)
192
Часть I. Начало
Internet
| Кабельное соединение
IE 6.0
Compaq Presario 1510
Переносной компьютер
Netgear MR814
Беспроводный
маршрутизатор
Беспроводное
соединение
802.11b
Сервер
провайдера
услуг Internet
camcast.net
RCADCM315R
Кабельный
модем
<<артефакт»
MS Word
Персональный компьютер
Характеристики:
Athlon 1600ХР
Рис. 13.5. Диаграмма развертывания для домашней системы
Netgear МА401
Беспроводный
адаптер
Кольцевая сеть с маркерным доступом
В кольцевой сети с маркерным доступом компьютеры, оснащенные сетевыми
адаптерами (NIC — Network Interlace Card), подсоединены к центральному устройст-
ву множественного доступа MSAU (Multistation Access Unit). Многочисленные устрой-
ства MSAU соединены в кольцо (отсюда и появилось слово “кольцо” в названии).
Кольцо объединенных MSAU-устройств действует подобно регулировщику, исполь-
зующему сигнал, называемый маркером, чтобы дать каждому компьютеру знак, когда
он может передавать информацию (отсюда слово “маркерное” в названии).
Когда компьютер получает маркер, только его информация может направляться в
сеть. После отправки информация передается по назначению. Когда она достигает
пункта назначения, компьютеру, с которого ее отправили, передается уведомление о
получении информации.
В примере, изображенном на рис. 13.6, смоделирована сеть, состоящая из трех
MSAU и связанных с ними персональных компьютеров (ПК).
13-й час. Работа с диаграммами развертывания
193
Рис. 13.6. Диаграмма развертывания для сети кольцевой архитектуры,
состоящей из трех устройств MSA U
Сеть ARC
Подобно маркерному кольцу компьютерная сеть с подключаемыми ресурсами
(ARC — Attached Resources Computing) тоже осуществляет передачу маркера от ком-
пьютера к компьютеру. Разница заключается в том, что в сети ARC каждый компью-
тер имеет собственный номер, с помощью которого определяется, какой из компью-
теров получает маркер. Каждый компьютер соединен с концентратором, который мо-
жет быть активным (восстанавливает и ретранслирует сигнал) и пассивным (просто
выполняет коммутацию).
В отличие от устройств MSAU в маркерном кольце, концентраторы сети ARC не
перемещают маркер по кольцу. Компьютеры пересылают маркер друг другу.
На рис. 13.7 изображена модель сети ARC с пассивным концентратором, активным
концентратором и несколькими компьютерами.
Сеть Ethernet
Одним из наиболее популярных типов сетей является Ethernet. Компьютеры со-
единяются с сетью посредством кабельных соединительных устройств, называемых Т-
образными разъемами. Одна часть внутренней локальной сети может быть соединена
с другой посредством повторителя — устройства, которое усиливает сигнал перед его
отправлением.
194
Часть I. Начало
Рис. 13.7. Диаграмма развертывания для сети ARC
На рис. 13.8 изображена модель сети Ethernet.
Беспроводная сеть Ricochet
Компания Ricochet Networks, Inc. обеспечивает беспроводное модемное решение
для мобильного доступа к Internet. Беспроводный модем подключается к последова-
тельному порту компьютера и соединяется в широковещательном режиме с соответст-
вующей сетью Ricochet.
Сеть Ricochet состоит из радиоприемопередатчиков, размером с коробку для обуви.
Эти радиоустройства установлены на уличных фонарях, расположенных в шахматном
порядке и отстоящих друг от друга на расстоянии от четырехсот до восьмисот метров.
Каждое радиоустройство оснащается специальным адаптером и получает небольшое
количество энергии от уличных фонарей.
Радиоустройства передают сигналы в пункты доступа к проводной сети, с которых
информация поступает на сетевой соединительный узел NIF (Network Interconnection
Facility). Узел NIF состоит из сервера имен (базы данных, которая подтверждает пра-
вильность соединения), маршрутизатора (устройства для соединения сетей) и шлюза
(устройства для соединения разнотипных сетей, работающих по разным протоколам
связи, в целях обеспечения передачи информации из одной сети в другую). Затем ин-
формация передается от узла NIF в Internet.
К моменту написания этой книги такая сетевая топология еще не получила широ-
кого распространения, однако она является хорошим примером для моделирования.
На рис. 13.9 изображена диаграмма развертывания для такой сети.
13-й час. Работа с диаграммами развертывания
195
Рис. 13.8. Диаграмма развертывания для сети Ethernet
Место диаграмм развертывания в общей
картине UML
Итак, к настоящему моменту рассмотрен весь набор диаграмм UML. Теперь общая
картина UML (рис. 13.10), включающая узлы и артефакты, завершена.
196
Часть I. Начало
Рис. 13.9. Беспроводная сеть Ricochet
13-й час. Работа с диаграммами развертывания
197
Структурные элементы
Поведенческие элементы
Класс
Узел
Состояние
Исполнитель
Имя компонента
<<компонент»
Имя компонента (2.0)
<<артефакт>>
Взаимосвязи
Группировка
Ассоциация
Обобщение
Зависимость
Реализация
Пакет
Расширение
<<стереотип>>
{ограничение}
Последовательность событий
Коммуникация
: Имя 2
Аннотация
--------L.
Примечание
Вид деятельности
Рис. 13.10. Общая картина UML, включающая диаграмму развертывания
Резюме
Диаграмма развертывания UML описывает физическую систему в готовом виде.
Система состоит из узлов, каждый из которых изображается в виде куба. Линия между
двумя кубами символизирует соединение двух узлов. На каждом из узлов можно ото-
бразить соответствующие артефакты.
Из этой главы читатель узнал, что диаграммы развертывания очень удобны для
моделирования сетей. Здесь были описаны такие модели, как кольцо с маркерным
доступом, сеть ARC, сеть Ethernet и беспроводная сеть Ricochet.
Вопросы и ответы
Для изображения сети Internet используется символ “облачка”, хотя он не является
символом UML. Можно ли при моделировании использовать другие символы, не входя □
щие в стандартный набор UML?
Да, можно. Вряд ли кто-то будет предъявлять претензии по этому поводу. Глав-
ное — сделать более ясной общую картину. Наиболее удобно использовать эти симво-
лы на диаграммах развертывания. Если у вас есть графические изображения рабочего
198
Часть I. Начало
стола, переносного компьютера, сервера и других процессоров (и устройств), можете
использовать их в диаграммах. В сущности, так создаются графические стереотипы. В
следующей главе будут приведены некоторые примеры. (Кстати, по поводу символа
“облачка” можно сделать интересное примечание. Один из создателей UML, Гради
Буч, использовал такие символы в качестве обозначений для описания объектов еще
до начала работы над созданием UML.)
Допустим, у нас есть графические изображения, но не для всех объектов. Можно ли
сочетать их с обычными символами UML?
Да, можно. Целью является построение диаграмм, которые проясняют картину, а
не (просим прощения за каламбур) покрывают ее облаками.
Практические занятия
Сейчас, после изучения набора диаграмм UML, закрепим знания о способах опи-
сания аппаратных средств. Ответы приведены в приложении А.
Тесты
1. Как изображается узел на диаграмме развертывания?
2. Информацию какого характера можно добавлять в изображение узла?
3. Как работает сеть с кольцевой архитектурой?
Упражнения
1. Опишите домашнюю компьютерную систему как набор узлов. Постройте
диаграмму развертывания, включите в нее центральный процессор и перифе-
рийные устройства. Добавьте соответствующие артефакты.
2. Сети можно соединять друг с другом, подключив каждую сеть к маршрутиза-
тору, а маршрутизатор — к другим локальным сетям. Постройте диаграмму
развертывания, отражающую соединение сети кольцевой архитектуры с сетью
Ethernet.
13-й час. Работа с диаграммами развертывания
199
14-й час
Пакеты и принципы построения UML
Из этого часа вы узнаете
> Что такое диаграмма пакетов
> Какова структура UML
> Как расширить UML
Если бы настоящая книга была составлена в соответствии с академическими пра-
вилами, а не в виде самоучителя, то эту главу следовало бы поместить вначале первой
части, а не в ее конце. Выбранная структура книги дает читателю шанс глубже осоз-
нать, что собой представляет язык UML и что можно делать с его помощью. Таким
образом, читатель уже должен быть готов к восприятию основ UML и к работе с ними.
Предлагаемый в книге подход похож на метод изучения иностранных языков.
Наилучший способ — это погрузиться в изучение предмета с головой, как это было
сделано в главах 1—13 (и будет продолжаться в части II, “Конкретный пример”). По-
сле этого можно почувствовать правила грамматики и синтаксиса, поскольку для
этого имеются все необходимые предпосылки. (К сожалению, многие общепринятые
академические курсы иностранных языков построены совершенно иначе!)
Зачем вообще нужна эта глава, если читатель уже знаком с диаграммами UML и
знает, как их использовать? Так вот, поняв, на чем базируется UML, можно расши-
рять его и приспосабливать для использования в реальных ситуациях. Как сказал бы
системный аналитик, у каждого проекта есть свои особенности. Никакие книги, по-
собия или руководства не смогут подготовить читателя ко всем ситуациям, с которы-
ми он может столкнуться. Глубокое понимание основных принципов поможет подго-
товиться к моделированию большинства систем.
Диаграммы пакетов
Перед погружением в основы языка UML, стоит познакомиться с еще одним ти-
пом диаграмм — диаграммами пакетов. Эти диаграммы способствуют более глубокому
пониманию других диаграмм. Хотя понятие пакета использовалось в каждой версии
языка UML, диаграммы пакетов получили настоящий статус лишь в UML 2.0.
Для чего нужны пакеты
Как следует из названия, пакет предназначен для группирования элементов диа-
грамм (например, классов или прецедентов). Для помещения элементов в пакет их
нужно разместить внутри изображения в виде папки. Если пакету присвоено имя,
значит, это же имя связано и с группой элементов. В терминах языка UML пакет
предоставляет для содержащихся в нем элементов пространство имен.
Для представления содержимого пакета можно воспользоваться одним из следую-
щих способов (рис. 14.1).
Рис. 14.1. Два способа представления содержимого пакета
Для ссылки на элемент пакета используется следующая форма записи: ИмяПаке-
та: :ЭлементПакета (например, Инструмент: :Молоток). Такая система именования
определяет полностью определенные имена элементов.
Отношения между пакетами
Пакеты могут связываться друг с другом одним из трех следующих способов. Один
пакет может обобщать другой пакет; может зависеть от другого пакета или уточнять его.
На рис. 14.2 показаны примеры отношений обобщения и зависимости между пакетами.
Обобщение и зависимость в контексте других элементов UML уже рассматрива-
лись выше. Уточнение имеет отношение к уровню детализации. Один пакет уточняет
другой, если в нем содержатся те же самые элементы, но в более подробном пред-
ставлении. Например, при написании книги вы наверняка начнете с формулировки
предложения, в котором кратко будет представлено содержание каждой главы. Пред-
14-й час. Пакеты и принципы построения UML
201
положим, что резюме к каждой главе в качестве отдельного элемента входит в пакет
Предложение. Допустим также, что Завершенная книга — это пакет, элементами ко-
торого являются законченные главы. В этом контексте пакет Завершенная книга яв-
ляется уточнением пакета Предложение. На рис. 14.3 показано два способа визуали-
зации этого отношения.
Электроэнергия
Рис. 14.2. Отношения обобщения и зависимости между па-
кетами
Рис. 14.3. Два способа визуализации отношения
уточнения
На диаграмме слева (см. рис. 14.3) отношение уточнения представлено как разно-
видность зависимости (штриховая линия со стереотипом <<уточняет>>).
На диаграмме справа (см. рис. 14.3) отношение уточнения показано в виде реали-
зации. Эта связь обычно соединяет класс и интерфейс. Означает ли это, что класс
“уточняет” свой интерфейс? В некотором смысле, да. Операции интерфейса
(подобные вращению ручки управления) уточняются в более детализированных опе-
рациях (как настройка радиостанции) при его соединении с классом (в данном случае
радио). Взаимосвязь реализации и уточнения рассматривается также в главе 22,
“Знакомство с шаблонами проектирования”.
202
Часть I. Начало
Объединение пакетов
Пакет может объединяться с другим пакетом. Отношение объединения является
разновидностью отношения зависимости между пакетом, который объединяет
(источник), и пакетом, который объединяется (целевой). Результатом объединения яв-
ляется преобразование пакета-источника.
Рассмотрим пример. Предположим, имеются пакеты Компьютеры и Телефоны, в
которых содержатся какие-то классы. Третий пакет Компьютерная телефония объе-
диняется с каждым из двух первых пакетов. Эти пакеты с их содержимым показаны
на рис. 14.4. Обратите внимание на то, что пакет Компьютерная телефония пуст.
Рис. 14.4. Моделирование объединения пакета с двумя другими пакетами
Объединение приводит к трансформации пакета Компьютерная телефония, как
показано на рис. 14.5. Импортируются все классы из двух пакетов-источников. В со-
ответствии с системой именования отношения наследования для классов Переносной
компьютер и Наземная линия связи показаны вместе с именами исходных целевых
пакетов.
Отношение наследования для класса Мобильное устройство иллюстрирует важ-
ный момент объединения. Если выполняется объединение пакетов и в результирую-
щем пакете содержатся классы с теми же именами, то класс из целевого пакета будет
содержать атрибуты и операции всех одноименных классов из пакетов-источников.
В рассматриваемом примере класс Мобильное устройство из пакета Компьютерная
телефония унаследует соответствующие члены от классов каждого пакета-источника.
Фактически класс Компьютерная телефония:: Мобильное устройство будет Пред-
14-й час. Пакеты и принципы построения UML
203
ставлять собой некий “интеллектуальный” мобильный телефон с компьютерными
возможностями. В свою очередь, существование классов-наследников PocketPC и
PalmOS говорит о том, что “интеллектуальный” телефон может работать под управле-
ния разных операционных систем (в нашем примере —- двух).
Компьютерная телефония
Рис. 14.5. Трансформация целевого пакета после объединения пакетов,
представленного на рис. 14.4
Знакомство с пакетами является прекрасным введением к рассмотрению основ по-
строения языка UML, поскольку этот язык определен в терминах пакетов понятий.
Сейчас основное внимание будет уделено именно понятиям, а соответствующие паке-
ты будут рассмотрены чуть ниже.
Иерархия
В общей картине UML изображены типы диаграмм и диаграммы в каждой катего-
рии. Как уже упоминалось в главе 1, “Введение в UML”, эти диаграммы необходимы
для построения всеобъемлющей модели системы. Поскольку к системе могут предъ-
являться различные требования, необходимо уметь рассматривать ее с разных точек
зрения.
Несмотря на то что общая картина весьма полезна для мысленного представления
и запоминания элементов UML, она вовсе не является исчерпывающим описанием
UML. “Три товарища” создавали UML как универсальную структуру, с помощью
элементов которой можно ясно представить любую систему и способы ее разработки.
Именно на этом основывается язык UML версии 2.0.
Итак, приступим к знакомству с архитектурой языка UML. Архитектуру следует
рассматривать как набор решений, определяющих построение системы. Эти решения
204
Часть I. Начало
строго ориентированы на свойства системных элементов — что они собой представ-
ляют, какова их роль, как они себя ведут, какой у них интерфейс и как их комбини-
ровать.
В архитектуре UML имеется четыре уровня, которые определяются степенью
обобщенности элементов, входящих в их состав. На рис. 14.6 представлены все четыре
уровня. Для краткости каждый уровень помечен собственной меткой МО—М3.
М3
М2
М1
МО
Рис. 14.6. Четыре уровня UML
Наиболее частный уровень, МО, называется уровнем пользовательских объектов.
Сущности именно этого уровня создаются при написании программного кода на ос-
нове построенной модели.
Следующий уровень, Ml, называется уровнем модели. К этому уровню относятся
модели, создаваемые на языке UML.
В начале каждой главы при знакомстве с новым понятием, таким как класс или
узел, мы поднимались до уровня М2 — третьего уровня из четырех. На этом уровне
определяется язык, используемый для описания модели. После небольшой практики
и более тесного знакомства с UML третий уровень станет близок и понятен читателю.
Этот уровень называется уровнем метамодели, потому что на нем определяется содер-
жимое модели, т.е. вводятся обозначения для классов, узлов, компонентов, прецеден-
тов и т.п.
И, наконец, четвертый уровень, М3. Четвертый уровень можно представить себе
как способ определения языка, с помощью которого описываются классы, прецеден-
ты, компоненты и все остальные элементы UML. Поскольку на таком уровне опреде-
ляется состав метамодели, он называется уровнем моделирования метамодели.
Аналогия
Для того чтобы лучше разобраться в уровнях UML, рассмотрим небольшой при-
мер. Оставим в стороне область моделирования систем и займемся более прозаичны-
ми вещами.
14-й час. Пакеты и принципы построения UML
205
Как правило, написание делового письма начинается с имени и адреса отправите-
ля. После этого добавляется дата, адрес получателя, приветствие, основной текст
письма, завершающая фраза (например, “с искренним уважением”), подпись и ваше
имя. Но так пишутся деловые письма. При написании письма другу обычно руково-
дствуются другими принципами.
Возвращаясь к четырем уровням на рис. 14.6, создаваемое письмо (например, в
текстовом редакторе) можно рассматривать как модель. Набор рекомендаций по на-
писанию делового письма по существу является метамоделью. При печатании и от-
правке письма вы имеете дело с уровнем пользовательских объектов.
Поднимемся на один уровень вверх. Рекомендации по написанию деловых писем
во многом определяются общими рекомендациями по составлению корреспонденции.
То же самое касается и рекомендаций по написанию дружеских писем и служебных
записок. Все это обусловлено тем, что общие рекомендации по составлению коррес-
понденции (“начните с приветствия”, “сформулируйте свою идею”) составляют осно-
ву всех метамоделей нижнего уровня. Таким образом, рекомендации по составлению
писем следует отнести к уровню моделирования метамодели.
Если приведенные выше рекомендации рассматривать как пакеты определенных
концепций и понятий, то их можно представить, как показано на рис. 14.7.
Рис. 14.7. Уровень моделирования метамодели, метамодель и модель написания
писем
206
Часть I. Начало
Двигаемся дальше
В предыдущих изданиях этой книги уровень моделирования метамодели, М3, рас-
сматривался очень кратко. Однако, после изменений, появившихся в версии 2.0 языка
UML, и широкого распространения мощных средств моделирования с этим уровнем
стоит познакомиться более подробно. Хотя с уровнем М3 вы вряд ли будете работать
при выполнении обычного моделирования, даже беглое знакомство с его фундамен-
тальными понятиями позволит лучше “почувствовать” язык UML. Знание этих кон-
цепций существенно облегчит и использование современных программных средств
моделирования.
Так что наберитесь терпения, мы приступаем к изучению уровня моделирования
метамодели, М3.
Только вперед...
Относите ли вы себя к любителям научных абстракций? Или к поклонникам
звездных путешествий? Удивляют ли вас экзотичность форм жизни на далеких плане-
тах и необычность их обитателей, которые могут говорить на прекрасном английском
языке с членами экипажа звездного корабля (и почему-то между собой)?
Зачастую научные фантасты просто игнорируют проблему языка. Их герои говорят
на английском независимо от места их обитания. Однако создатели Звездных путеше-
ствий не забыли об этой проблеме и придумали универсальный транслятор — устрой-
ство, которое каким-то образом “умеет” сопоставлять мысли, возникающие у говоря-
щего, с мыслями у его слушателя и строить информационную матрицу. После этого
слова, фразы и идиомы одного языка универсальный транслятор с помощью этой
матрицы может быстро переводить в слова, фразы и идиомы другого языка. Таким
образом два обитателя галактики могут общаться друг с другом.
Возможно, у вас возник вопрос: зачем нужен этот короткий экскурс в область
лингвистики. Если фразу “необычные обитатели далеких планет” заменить на
“системы обработки различной информации в самых различных областях”, а фразу
“на прекрасном английском языке” — на “неограниченное взаимодействие”, то вы
поймете, какую проблему в свое время попыталась решить группа OMG (команда
звездолета). В начале 1990-х годов специалисты группы OMG (Object Management
Group) приступили к созданию чего-то наподобие универсального транслятора. Ос-
новная цель заключалась в том, чтобы объекты различных программных систем
(которые, как правило, создавались разными разработчиками) могли легко и естест-
венно взаимодействовать друг с другом.
И снова вернемся к звездным путешествиям. Если вы можете представить универ-
сальный транслятор в качестве реального физического устройства, то вполне очевид-
но, что его архитектура и инфраструктура должна напоминать CORBA — платформу
группы OMG, которая позволяет приложениям осуществлять друг с другом сетевое
взаимодействие. В свою очередь информационную матрицу можно рассматривать как
аналог другого архитектурного решения группы OMG — модели MOF (Meta-Object
Facility). Эта модель обеспечивает описание и управление информацией в рамках ин-
фраструктуры CORBA.
Итак, от звездных путешествий мы плавно перешли к спецификации CORBA и
модели MOF. Так какое же отношение все вышесказанное имеет к языку UML? Все
очень просто: модель MOF является основой внутренней структуры UML 2.0.
Что же все это означает?
Группа OMG использует модель MOF не только для описания природы данных в
рамках инфраструктуры CORBA. Эта модель применятся также в качестве шаблона
для разработки языков моделирования, подобных UML.
14-й час. Пакеты и принципы построения UML
207
Языки моделирования, подобные UML? Именно так, UML является далеко не един-
ственным языком для разработки моделей. По существу, он стал стандартом, однако
вполне допустимо и существование других языков. Можно изучить модель MOF и ее
основные концепции, а затем использовать ее в качестве основы для создания другого
языка моделирования.
Такой подход напоминает использование информационной матрицы универсаль-
ного транслятора в качестве основы для создания новых языков общения между пред-
ставителями различных форм жизни.
Пакеты инфраструктуры UML
Рассмотрим уровень М3 с более формальной точки зрения. На рис. 14.7 для пред-
ставления различных уровней в модели написания писем использовались пакеты.
Этот же подход мы будем применять и при обсуждении основ языка UML, т.е. разбе-
ремся, что же группа OMG понимает под инфраструктурой UML.
В пакетах инфраструктуры UML содержатся диаграммы в терминах MOF. Эти
диаграммы составляют основу спецификаций. (Именно поэтому модель MOF являет-
ся основой языка UML.) Возможно, упоминание о модели MOF может вызвать удив-
ление. Однако не торопитесь, скоро вы узнаете, что к чему.
На уровне М3 основным элементом является пакет Библиотека инфраструктуры
(Infrastructure Library). Как видно из рис. 14.8, в этом пакете содержится два других
пакета, Основа (Core) и Профили (Profiles). Пакет Основа следует рассматривать как
хранилище понятий, которые используются для создания метамоделей, подобных
языку UML. В пакете Профили содержатся понятия, позволяющие выполнять допол-
нительную “настройку” метамоделей и создавать вариации UML (и других метамоде-
лей) для определенных предметных областей.
Рис. 14.8. В пакете Библиотека инфраструктуры содер-
жится два других пакета — Основа и Профили
Рассмотрим еще одну аналогию. Предположим, что пакет Библиотека инфра-
структуры на самом деле является библиотекой, в которой хранятся такие “понятия”,
как книги. В разделе “Основа” этой библиотеки можно найти книги примерно с та-
кими названиями: “Как использовать масляные краски и холст”. Книгу можно про-
читать, создать собственный стиль рисования, а затем описать эту технологию рисо-
вания в этом стиле. После этого другие люди смогут применить описанные приемы
для создания картин в определенном стиле.
208
Часть I. Начало
В разделе “Профили” библиотеки могут содержаться “понятия”, например, со сле-
дующими названиями: “Анатомия человека для художников”. После чтения этой
книги к определенному стилю рисования можно добавить специальные приемы,
предназначенные для создания портретов людей.
Пакет Основа
В пакете Основа содержится четыре пакета: Простые типы (Primitive Types), Абст-
ракции (Abstractions), Основные элементы (Basic) и Структурные элементы
(Constructs) (рис. 14.9). Ниже каждый из этих пакетов будет рассмотрен подробно.
Пакет Простые типы
В этом пакете содержатся типы данных, которые можно использовать при созда-
нии языка моделирования. К этим типам относятся Integer, Boolean, String и
UnlimitedNatural. К последнему типу относится любое число из бесконечного
множества натуральных чисел. Обычно бесконечность задается с помощью символа *.
На диаграммах UML эти числа позволяют использовать кратность связи на концах
ассоциаций между классами (а звездочка (*) обозначает много). Простые типы данных
представлены на рис. 14.10.
Фундаментальный вопрос
При анализе рис. 14.10 может снова возникнуть вопрос о модели MOF. Если диаграммы па-
кета Библиотека инфраструктуры (в которых определяются базовые понятия) ос-
нованы на модели MOF, то где же описание самой модели MOF? И где тогда найти описание
этого описания... и т.д.
Одним словом, где-то подобная цепочка должна закончиться, и именно модель MOF являет-
ся этим звеном. Модель MOF является рефлективной. Другими словами, модель MOF оп-
ределена сама в себе.
14-й час. Пакеты и принципы построения UML
209
Простые типы
«примитив>>
Integer
<<примитив>>
Boolean
<<примитив>>
String
<<примитив>>
UnlimitedNatural
Рис. 14.10. Пакет Простые типы из пакета Основные элементы,
который входит в состав пакета Библиотека инфраструктуры
Возвращаясь к аналогии с масляными красками, можно сказать, что простые типы
соответствуют свойствам этих красок. Эти свойства и должны учитываться во всех
правилах, которые определяют стиль рисования.
Пакет Абстракции
В этом пакете содержится 20 других пакетов. В каждом из них определены пред-
ставления понятий, которые рассматривались в главах 1—13. Основным пакетом явля-
ется Элемент (Element), в котором содержится один абстрактный класс, который, как
нетрудно догадаться, называется Элемент. Не забывайте о том, что в данный момент
рассматривается уровень М3, так что на класс Элемент наиболее естественно ссылать-
ся как на абстрактный метаметакласс.
Поскольку эта абстракция в обобщенном виде представляет любой элемент моде-
ли, то класс Элемент является суперклассом для всех других классов, точнее, метаме-
таклассов из пакета Библиотека инфраструктуры.
К другим пакетам относятся Зависимости (Relationships), Комментарии (Com-
ments), Кратности (Multiplicities) и Классификаторы (Classifiers). (Классификатором
является любой элемент, который описывает структуру и поведение. В языке U Ml-
все классы, прецеденты, узлы и исполнители — это примеры классификаторов.)
Пакет Основные элементы
Этот пакет можно рассматривать как средство описания процесса моделирования.
В его состав входят классы, которые используются для разработки сложных языков
моделирования. Если язык UML представить состоящим просто из классов (с атрибу-
тами и возможностью их наследования от других классов), параметров (для операций
классов), пакетов и типов данных, то именно это и является основной идеей, зало-
женной в пакет Основные элементы.
Пакет Структурные элементы
Пакет Структурные элементы зависит от пакетов, содержащихся в пакетах Абст-
ракции и Основные элементы. В нем комбинируются различные элементы из этих
пакетов и, таким образом, добавляются новые свойства к классам, отношениям и ти-
пам данных. Например, этот пакет расширяет, т.е. конкретизирует, способ визуализа-
ции атрибутов и операций класса. В пакете Структурные элементы определена также
информация, которую можно добавлять к ассоциациям между классами (в том числе
имена ролей и значения кратности).
210
Часть I. Начало
Пакет Профили
Теперь познакомимся с пакетом Профили. Именно он предоставляет механизм
адаптации метамодели к специальной области знаний. По существу, каждая такая
адаптация является отдельным профилем.
Определяется ли в новом профиле новая метамодель? Нет. При создании новой
метамодели, по существу, создается новый язык моделирования. В этом случае от-
правной точкой является пакет Основа.
Профиль следует рассматривать как некий вариант уже существующей метамодели,
который, например, был получен при адаптации языка UML к моделированию облас-
ти права или обучения. Для создания нового профиля к UML добавляются дополни-
тельные свойства. Что и как можно добавить, определяется в пакете Профили.
Так что же можно добавить? Выше уже упоминались стереотипы, которые можно
применять для расширения языка UML. В пакете Профили определен формальный
механизм создания стереотипов. Другими словами, в нем содержатся метаметаклассы
(т.е. классы уровня М3) Расширение (Extension) и Стереотип (Stereotype).
Для того чтобы лучше разобраться в основных принципах использования этих
классов, можно создать профиль UML для моделирования электрических схем. При
этом нужно позаботиться о способе моделирования конденсаторов, транзисторов, ис-
точников питания и других важных электрических компонентов. Поскольку эти эле-
менты относятся к аппаратным средствам, то для их представления можно воспользо-
ваться стереотипами узла — обозначения UML, используемого для визуализации эле-
ментов аппаратных средств.
Однако на рассматриваемом уровне инфраструктуры UML (М3) в нашем распоря-
жении нет пиктограммы куба, существует лишь метаметакласс Узел (Node). Поэтому
для того чтобы зафиксировать факт создания стереотипа Конденсатор (Capacitor) (т.е.
элемент с таким стереотипом может хранить электрический заряд), нужно воспользо-
ваться диаграммой, как показано на рис. 14.11.
Рис. 14.11. Создание стереотипа Кон-
денсатор
На этом рисунке закрашенная стрелка используется для представления отношения
“расширения”, т.е. ассоциации между метаклассом и стереотипом.
Конденсаторы (и другие электрические компоненты) зачастую предоставляют воз-
можность (интерфейс) управлять их свойствами. В частности, для управления конден-
сатором используется ручка управления, позволяющая изменять емкость хранящегося
в нем электрического заряда. В следующий раз при включении радиоприемника вы
уже будете помнить о том, что ручка управления на самом деле является интерфейсом
управления конденсатором. Таким образом, можно создать также стереотип Ручка-
Управления (ControlKnob).
Созданные стереотипы следует разместить внутри пиктограммы пакета, который
представляет новый профиль Электричество (Electricity). Этот пакет представлен на
рис. 14.12.
14-й час. Пакеты и принципы построения UML
211
Рис. 14.12. Новый профиль, в котором язык UML адаптирован
для моделирования электрических схем
С практической точки зрения можно считать, что после создания требуемых сте-
реотипов в распоряжении специалиста по моделированию имеются условные обозна-
чения из профиля UML Электричество (т.е. из расширенной метамодели), которые
представлены на рис. 14.13. (В языке UML узел изображается в виде куба.)
Рис. 14.13. Условные обозначения UML, которые можно исполь-
зовать, создав профиль Электричество
Новые обозначения можно использовать при моделировании, как показано на
рис. 14.14.
212
Часть I. Начало
Рис. 14.14. Использование условных обозначения из профи-
ля Электричество
1/1 снова... UML!
Теперь подробнее познакомимся с уровнем М2. На рис. 14.15 язык UML изобра-
жен в контексте идей, упоминавшихся в предыдущем разделе, — пакет Библиотека
инфраструктуры является его основой.
Библиотека
инфраструктуры
UML
Рис. 14.15. Язык UML основан на пакете
Библиотека инфраструктуры
Еще раз о четырех уровнях
Вне всякого сомнения, язык UML является основой для всех создаваемых моде-
лей. В терминах классов, метаклассов и метаметаклассов эту мысль можно выразить и
несколько по-другому. При создании класса в какой-либо модели создается экземп-
ляр класса UML. В свою очередь, класс UML является экземпляром метаметакласса
уровня М3. Двигаясь в другом направлении, можно сказать, что экземпляр класса
(объект) времени выполнения создается на основе программного кода, который был
написан на основе построенной модели. На рис. 14.16 все вышесказанное представле-
но в терминах четырех уровней архитектуры UML.
14-й час. Пакеты и принципы построения UML
213
Рис. 14.16. Экземпляры в рамках четырех уровней моделирования
Пакеты суперструктуры UML
Наряду с использованием диаграмм пакетов для моделирования основы языка
UML их можно применять и для моделирования элементов внутри самого UML. Ре-
зультаты такого моделирования специалисты группы OMG называют суперструктурой
UML.
На рис. 14.17 в увеличенном виде изображен пакет имь из рис. 14.15. В этом паке-
те определена суперструктура UML, состоящая из двенадцати пакетов.
Как видно из названий пакетов, в суперструктуре содержатся формальные специ-
фикации всех элементов, которые рассматривались в главах 1—13. На рис. 14.17 мож-
но увидеть двунаправленную (линия с двумя стрелками) и несколько циклических от-
ношений зависимости (пакет Общие элементы поведения (CommonBehaviors) зави-
сит от пакета Операции (Actions), пакет Операции зависит от пакета Виды
деятельности (Activities), а пакет Виды деятельности зависит от пакета Общие эле-
менты поведения). На приведенной диаграмме отношение зависимости между двумя
пакетами означает, что как минимум один элемент пакета зависит от как минимум
одного элемента другого пакета.
Поскольку имена пакетов практически однозначно характеризуют их назначение,
ниже просто описаны наиболее важные из них. (Пакет Профили содержится в пакете
Библиотека инфраструктуры и в данном случае лишь повторно используется.)
214
Часть I. Начало
<<метамодель» UML
Рис. 14.17. Суперструктура UML
Пакет Классы
Как легко предположить, в пакете Классы содержится описание классов и взаимо-
связей между ними. Эти вопросы уже упоминались при рассмотрении пакетов Абст-
ракции и Структурные элементы пакета Библиотека инфраструктуры::Основа.
Спецификации из этих двух пакетов повторно используются в пакете Классы.
Пакет Общие элементы поведения
В этом пакете содержится описание поведения объектов, их взаимодействия и мо-
делирования во времени.
Пакет Прецеденты
В этом пакете используется информация из пакета Общие элементы поведения и
некоторых других пакетов. В нем определены диаграммы, используемые для представ-
ления системных функциональных требований. Именно здесь вы можете найти фор-
мальное описание исполнителей, прецедентов, отношений включения и расширения.
14-й час. Пакеты и принципы построения UML
215
Пакет Композитные структуры
Кроме описания композитных структурных диаграмм (упоминавшихся в главе 1), в
этом пакете определены порты и интерфейсы. Кроме того, в нем также показано, как
классы могут “сотрудничать” друг с другом. Более подробно этот вопрос рассматрива-
ется в главе 22.
Пакет Вспомогательные элементы
Этот пакет рассматривается в данном разделе, поскольку его название не столь
очевидно. Пакет Вспомогательные элементы по существу является хранилищем раз-
нородных элементов. Он имеет отношение к шаблонам (еще одна тема, которая обсу-
ждается в главе 22), визуализации информационных потоков в системе и содержит
условные обозначения для представления моделей. На рис. 14.18 показана пикто-
грамма модели: условное обозначение пакета с небольшим треугольником. В пакете
Вспомогательные элементы повторно используются простые типы, которые опреде-
лены в пакете Библиотека инфраструктуры.
Модель проектирования
Рис. 14.18. Пиктограмма па-
кета для представления модели
Расширение UML
Как вы узнали из предыдущих разделов, язык UML имеет достаточно разветвлен-
ную структуру, которая является основой для самых разнообразных приемов модели-
рования, рассмотренных в главах 1-13.
Кроме этих приемов моделирования существует еще три механизма, с помощью
которых язык UML можно расширить, — стереотипы, ограничения и тегированные
значения.
Стереотипы
Стереотипы предназначены для расширения элементов UML и создания на их ос-
нове новых элементов. Выше в разделе, посвященном пакету Профили, было показа-
но, как стереотипы можно применять при работе с инфраструктурой UML. Не забы-
вайте о том, что при использовании стереотипов в создании нового профиля нет не-
обходимости.
Стереотипы обеспечивают достаточную гибкость в работе. Это означает, что в ка-
честве основы для создаваемого элемента можно использовать уже существующий
элемент UML. Причем этот новый элемент фиксирует некоторые аспекты системы
или рассматриваемой предметной области таким способом, каким стандартные эле-
менты UML этого сделать не могут.
В UML предусмотрен расширенный набор готовых стереотипов. Некоторые из них
будут рассмотрены ниже.
216
Часть I. Начало
Зависимость
Стереотипы позволяют расширить отношение зависимости между клиен-
том/источником (элементом, из которого выходит пунктирная линия со стрелкой) и
сервером/целью (элементом, к которому ведет линия). Ниже кратко описано несколько
стереотипных зависимостей.
Зависимость «импортирует» возможна между двумя пакетами. Этот стереотип
добавляет содержимое цели в пространство имен источника (пространство имен явля-
ется аспектом пакета, в котором определены имена его компонентов). В начале этой
главы упоминалась также другая стереотипная зависимость между пакетами,
<<уточняет>>.
При использовании стереотипа «передает» клиент передает сигнал серверу.
Зависимость со стереотипом «инстанцирует>> может использоваться между кли-
ентом и сервером, которые оба являются классами. Такая зависимость свидетельствует
о том, что клиентом создаются экземпляры сервера.
Класс
Стереотип <<метакласс>> показывает, что классификатор с этим стереотипом яв-
ляется метаклассом другого класса. Это означает, что моделирование выполняется на
уровне метамодели. Экземпляры метакласса также являются классами (а не объекта-
ми). Не забывайте о том, что класс, входящий в состав модели UML, представляет со-
бой экземпляр метакласса — класса в контексте языка UML.
Класс со стереотипом «тип» определяет набор объектов вместе с их атрибутами,
операциями и ассоциациями. В него не включены методы (исполняемые алгоритмы
для его операций). Объект может относиться к нескольким типам.
Стереотип <<Класс реализации>> противоположен классу «тип». Он описыва-
ет реализацию класса на языке программирования. Объект не может относиться более
чем к одному классу реализации.
Класс со стереотипом <<утилита>> определяет именованный набор атрибутов и
операций, которые не являются членами этого класса. Такой класс не может иметь
экземпляров.
В классе могут быть определены методы или операции, предназначенные для соз-
дания или уничтожения его экземпляров. (В языке программирования C++ такие ме-
тоды называются конструктором и деструктором, соответственно.) Тогда эти методы
можно пометить стереотипами <<создает>> или <<уничтожает>>.
Пакет
В языке UML имеется также несколько стереотипов, которые можно использовать
вместе с пакетами. Один из них, «Библиотека модели>>, определяет, что в пакете
содержатся элементы модели, которые можно повторно использовать в других паке-
тах.
«Контур>> — это стереотипированный пакет, в котором содержатся шаблоны —
элементы UML, специально предназначенные для повторного использования. Более
подробно шаблоны рассматриваются в главе 22.
Графические стереотипы
В некоторых случаях необходимо ввести в предметную область один или несколько
новых символов, чтобы объяснить смысл клиенту. Если значение нового символа по-
нятно практически каждому человеку, то его вполне можно использовать в модели.
Диаграмма развертывания предоставляет для этого большие возможности. Обычно
в распоряжении разработчика имеются графические изображения элементов аппарат-
14-й час. Пакеты и принципы построения UML
217
ного обеспечения, которыми можно заменять откровенно банальные кубы, исполь-
зуемые в главе 13, “Работа с диаграммами развертывания”. Если в качестве пикто-
граммы UML используется графическое изображение, то тем самым создается графи-
ческий стереотип.
На рис. 14.19 показан пример такой замены. Он представляет собой художествен-
ную версию модели сети ARC из рис. 13.7.
ПК#4 ПК#5
{Максимальное расстояние=30м}
Активный концентратор
Рис. 14.5. Художественная версия модели сети ARC
Ограничения
С помощью ограничений для элементов модели UML можно задавать условия и
ограничения. Ограничение может иметь произвольный формат. Главное — разместить
его в фигурных скобках. Если, например, один из атрибутов класса предназначен для
хранения значения скорости, то для него можно задать ограничение {скорость не
может превышать скорость света}.
Тегированные значения
Тегированные значения предназначены для явного определения какого-либо свой-
ства. Они также помещаются в фигурные скобки. Тегированные значения имеют сле-
дующую структуру. Сначала ставится дескриптор (тег), который задает определяемое
свойство, а затем — знак равенства (=) и само значение. Например, к компоненту
можно присоединить тегированное значение {местоположение = имяУзла}, где имя-
Узла задает узел, на котором расположен данный компонент.
218
Часть I. Начало
Резюме
В этой главе рассматривались пакеты и понятия, лежащие в основе UML. Задачей
данной главы являлось углубление понимания, позволяющее применять UML в ре-
альных жизненных ситуациях, которые зачастую существенно отличаются от упраж-
нений из учебника. Основные понятия были рассмотрены после знакомства со всеми
типами диаграмм. Поэтому анализ основ языка UML именно в этой главе должен
обеспечить гораздо лучшее понимание его основных элементов.
Один из подходов к пониманию языка UML заключается в его анализе в терминах
четырех уровней: уровня пользовательских объектов, моделей, метамоделей и моделей
метамоделей (которые обозначаются как МО, Ml, М2 и М3). В процессе анализа и
построения моделей UML разработчик работает на втором уровне. Программный код,
написанный на основе построенных моделей, относится к первому уровню. Изучение
понятий UML выполняется на третьем уровне. Четвертый уровень предназначен ско-
рее для разработчиков языка и теоретиков, чем для пользователей языка и системных
аналитиков. С этим уровнем вы вряд ли столкнетесь при выполнении непосредствен-
ных служебных обязанностей. Однако даже поверхностное знакомство с понятиями,
относящимися к четвертому уровню, сможет существенно облегчить понимание ос-
новных принципов построения языка UML и позволит воспользоваться всеми пре-
имуществами современных средств моделирования. Разработчики CASE-средств опе-
рируют именно этим уровнем.
В языке UML определено три механизма его расширения: стереотипы, ограниче-
ния и тегированные значения. Стереотипы позволяют создавать новые элементы пу-
тем расширения уже существующих. Некоторые стереотипы предопределены в самом
UML. При необходимости можно создать и собственные стереотипы. Графические
стереотипы представляют собой графические изображения, которые можно применять
в качестве пиктограмм UML. При необходимости на элементы модели можно нало-
жить требуемые ограничения. Тегированные значения предназначены для явного за-
дания значений свойств.
А теперь скажите: что бы вы уяснили, если бы эти все базовые понятия были из-
ложены в главе 1?
Вопросы и ответы
Я заметил, что имя пакета иногда размещается во вкладке условного обозначения па-
кета, а в других случаях — в его теле. Можно ли сформулировать основное правило?
Если в пакете показаны его элементы, то имя пакета лучше всего разместить во
вкладке. Во всех остальных случаях имя можно размещать в теле пакета.
Насчет объектов уровня пользовательских объектов возник следующий вопрос. Это те
же самые объекты, что и в модели UML?
Нет, это не так. Объект в модели отличается от пользовательского объекта. Объект
модели относится к уровню Ml, а пользовательский объект — к уровню МО.
Вы несколько раз упоминали о четырех уровнях. Является ли это определенным огра-
ничением? Может ли многоуровневое представление метамодели содержать больше четы-
рех уровней?
Да. Теоретически на количество возможных уровней не налагается никаких огра-
ничений. Например, возвращаясь к аналогии с письмами, можно сказать, что нашей
моделью метамодели была “корреспонденция”. В качестве более высокого уровня
можно было бы использовать что-то вроде “письменного общения”. Тогда в модели
метамодели кроме “корреспонденции” присутствовали бы, например, “художествен-
ные произведения” и “нехудожественные произведения”. Однако с практической точ-
14-й час. Пакеты и принципы построения UML
219
ки зрения в реальном мире можно найти много областей, где наиболее естественным
является использование четырехуровневого представления.
Выше несколько раз упоминались “другие метамодели”. Используется ли пакет Биб-
лиотека инфраструктуры в качестве основы других метамоделей, отличных от метамо-
дели UML?
Да. Пакет Библиотека инфраструктуры является также основой CWM — языка
моделирования складских хранилищ товаров.
Тогда возникает еще один вопрос. Когда создавать профиль, а когда — новую метамо-
дель?
Хороший вопрос. К сожалению, на этот счет не существует определенных правил.
Из приведенного материала я понял, что модель MOF представляет собой основу
UML 2.0. Использовалась ли эта модель в качестве базовой для всех других версий язы-
ка UML?
Нет, не использовалась. UML 1.x был определен в терминах самого UML.
Чем же вызваны подобные изменения?
Группа OMG решила привести язык UML в соответствие с другими своими разра-
ботками, в том числе и будущими. Использование общей основы —наилучший способ
решения этой задачи.
Известно, что существуют правила UML. Кто следит за этими правилами?
Как уже было сказано, не существует полиции UML, которая бы проверяла кор-
ректность модели. Но при этом средства моделирования ненавязчиво вынуждают со-
блюдать эти правила.
Практические занятия
Предлагаемые задания закрепят знания об основах UML. Обдумайте вопросы теста
и найдите ответы в приложении А.
Тесты
1. Что такое метамодель?
2. Что такое классификатор?
3. Почему так важно иметь возможность расширять UML?
4. Что собой представляют механизмы расширения UML?
Упражнения
1. Поищите в Internet графические изображения компонентов и устройств и ис-
пользуйте их для улучшения диаграмм развертывания из главы 13.
220
Часть I. Начало
15-й час
Место UML в процессе разработки
Из этого часа вы узнаете
> В чем состоит важность процесса разработки
> Почему старые методики разработок не подходят для современных систем
> Процесс разработки GRAPPLE
> Как использовать UML в процессе разработки
Теперь, после изучения диаграмм и структуры UML, пришло время отшлифовать
методики. UML является великолепным инструментальным средством, но не стоит
использовать его отдельно от других средств. Он предназначен для того, чтобы
“обеспечивать топливом” разработку программного продукта. С этой главы начинает-
ся изучение процессов и методик разработки, чтобы в их контексте лучше понять, как
использовать UML.
Допустим, определенной организации нужна новая компьютерная система. Совре-
менные аппаратные средства и программное обеспечение предоставят бесспорное
преимущество, которое так необходимо этой организации. Требуется разработка, при-
чем срочная.
Итак, решено создать новую систему. Для этого набирается коллектив разработчиков, в
который входят: руководитель проекта, разработчики модели, аналитики, программисты и
системные инженеры. Итак, они собрались и горят желанием начать работу.
Представим себя на месте клиента. Каких результатов следует ожидать от коллек-
тива? Каких отчетов нужно требовать от руководителя проекта? В конце концов, но-
вая система должна заработать. Но сначала необходимо удостовериться, что коллектив
понимает проблему и пути ее решения. Заказчику нужно видеть систему в развитии,
то есть иметь представление о том, что делает команда на каждом этапе.
Эти вопросы обычно интересуют каждого отдельного клиента и касаются любого
проекта разработки системы, для которого требуется время, деньги и энергия, затра-
чиваемая членами команды.
Методики: старая и новая
Вряд ли нужно, чтобы команда разработчиков тут же бросилась писать программы.
Что, собственно, они будут программировать? Разработка должна выполняться струк-
турировано и методично. Принцип и характер разработки определяются методикой.
Перед началом написания программ разработчики должны полностью уяснить се-
бе суть проблемы. Для этого необходимо проанализировать потребности заказчика.
Можно ли начинать программирование по окончании этого анализа? Нет. Кто-то
должен внести результаты анализа в проект. Тогда программисты будут писать про-
грамму, руководствуясь проектом, который после тестирования и развертывания ста-
нет системой.
Старый способ
Упрощенный взгляд на последовательность этапов работ может навести на мысль,
что эти этапы должны следовать друг за другом в определенные промежутки времени.
Действительно, раньше методики разработок создавались таким способом. На
рис. 15.1 изображен один из процессов разработки, который был весьма распростра-
нен на протяжении долгих лет. Это так называемый “каскадный” метод, который за-
ключается в том, что анализ, проектирование, программирование и развертывание
следуют друг за другом как виды деятельности. В диаграмме видов деятельности толь-
ко после выполнения одного из них начинается выполнение другого.
Такой метод работы имеет несколько недостатков. При его использовании объем
работ приходится дробить на отдельные участки. Если аналитик будет просто переда-
вать результаты своей деятельности проектировщику, а тот, в свою очередь, передаст
проект разработчику, то вероятность успешной работы этих трех участников команды
существенно снизится.
Развертывание
Рис. 15.1. Каскадный метод разработки про-
граммного обеспечения
Другая проблема, связанная с этим методом, заключается в том, что существенно
снижается влияние отдельных участников на общий курс разработки проекта.
(Скорее, это даже заблуждение. Ведь понимание углубляется по мере развития проек-
222
Часть I. Начало
та, и даже после того как результаты анализа переданы на следующий этап проекти-
рования.) Если процесс нельзя развернуть в обратном направлении для пересмотра
предыдущих стадий, то новые идеи, появляющиеся в ходе развития, не будут приме-
нены. Попытаться протолкнуть эти идеи в проект во время разработки, в лучшем слу-
чае, весьма проблематично. Пересмотр этапов анализа и проектирования и обеспечение,
таким образом, более глубокого понимания, существенно повысит шансы на успех.
Новый способ
В противовес “каскадному” методу, в современном проектировании программного
обеспечения делается упор на взаимодействие между стадиями разработки. Например,
аналитики и проектировщики переходят от одной стадии к другой и возвращаются
обратно, чтобы развить прочный фундамент для программистов. Программисты, в
свою очередь, взаимодействуют с аналитиками и проектировщиками, чтобы поделить-
ся с ними своим пониманием задачи, модифицировать проекты и улучшить качество
своих программ.
Преимущество заключается в углублении понимания. Команда внедряет новые
идеи и строит более мощную систему. Обратная сторона (если она есть) в том, что
некоторые предпочитают замкнутость и хотят, чтобы каждая стадия выполнялась от-
дельно. Иногда руководители проекта желают прибегнуть к чему-нибудь наподобие:
“Анализ уже закончен, и мы приступаем к проектированию. На это нам потребуется
два или три дня, а затем мы начнем программирование”.
Такая точка зрения довольно опасна. Установка искусственных барьеров между
стадиями в конечном счете приведет к тому, что система будет совсем не такой, как
требуется клиенту.
Старый способ таит в себе и другую проблему: сторонники “каскадного” метода
львиную долю времени, выделенного на проект, тратят на программирование. Это
происходит, естественно, за счет уменьшения времени на анализ и проектирование.
Что должно происходить в ходе процесса
разработки
В первые годы программирования на компьютерах анализировать проблему, при-
нимать решения и писать программу мог один человек. Точно так же в первые годы
строительства домов (когда мир был проще) один человек мог построить вполне
прочный и симпатичный дом.
Сегодня все по-другому. Для разработки комплексных систем, необходимых со-
временному деловому миру, требуется коллективный подход. Почему? Познания ста-
новятся настолько специализированными, что один человек просто физически не мо-
жет охватить все грани бизнес-процесса, понять суть проблемы, разработать проект
решения, представить это решение в виде программы, развернуть ее на аппаратных
средствах и гарантировать корректную совместную работу всех компонентов аппарат-
ных средств.
Команда должна состоять из аналитиков, которые обеспечат контакт с клиентом
для понимания его проблемы; проектировщиков, которые разработают решение;
программистов, которые преобразуют эти решения в программы; и системных инже-
неров, которые развернут окончательный проект. В процессе разработки выполнение
всех этих видов должно проходить в совокупности при правильном распределении
времени между этапами работ. Проект должен развиваться, причем все члены коман-
ды несут известную долю ответственности за выполнение вверенных им этапов работ.
15-й час. Место UML в процессе разработки
223
И, наконец, необходимы гарантии того, что каждый последующий шаг работы не
будет изолирован от предыдущего. Для стимулирования творческого поиска и упро-
щения процесса внедрения новых идей нужно обеспечить обратную связь между эта-
пами работ. Ведь гораздо легче вносить изменения в процессе проектирования, чем
переделывать здание после окончания строительства.
В ходе процесса появляется соблазн выработать полный комплект стадий проекта,
что обычно выливается в море бумажной работы. Довольно часто именно так и по-
ступают, вынуждая руководителя проекта заполнять бесконечные формы. В результате
этой бумажной работой все и заканчивается.
Причиной этого является неверное предположение о существовании универсаль-
ной методики. Каждая организация по-своему уникальна. В организации имеются
собственная культура, нормы, история и, естественно, люди. Методика разработки,
которая верна для многонационального конгломерата, может оказаться непригодной в
сфере малого бизнеса, и наоборот. В попытках подогнать методику под организацию
заложено ошибочное мнение о том, что количество документации сможет как-то по-
мочь в этом деле.
Это непростая задача. В процессе разработки необходимо:
гарантировать, что у коллектива разработчиков имеется ясное понимание
проблемы, которую они пытаются разрешить;
укомплектовать группу разработчиков всеми необходимыми специалистами
(людьми);
стимулировать контакты между членами коллектива;
обеспечить обратную связь в ходе прохождения стадий разработки;
спланировать разработку таким образом, чтобы на каждом этапе получать
ощутимые результаты, оформление которых не требует лишней бумажной
работы.
Кроме того, желательно представить законченный проект в максимально сжатые
сроки.
Процесс и методика
Слова “процесс” и “методика” здесь используются как синонимы. Однако смысл их несколь-
ко различен. Предпочтительнее было бы не разделять эти понятия. Дело в том, что слово
“методика” имеет в последнее время плохую репутацию. Объединение этого слова со сло-
вом “процесс” в ходе обсуждения несколько смягчает его отрицательное восприятие.
Процесс GRAPPLE
Для решения сложной и многогранной задачи структурирования процесса разра-
ботки можно предложить принципы быстрого проектирования приложений —
GRAPPLE (Guidelines for Rapid APPLication Engineering). Идеи GRAPPLE не ориги-
нальны. Они представляют собой обработку идей множества других подходов. “Три
товарища” создали унифицированный процесс RUP (Rational Unified Process), поло-
жив в его основу наработки каждого из авторов. Принципы этих процессов сходны с
принципами GRAPPLE.
Первое слово в аббревиатуре GRAPPLE — “Guidelines” (Принципы), имеет важный
смысл: это не методика, вписанная в скрижали. Напротив, это набор легко приспо-
сабливаемых гибких идей. Можно сказать, что они представляют собой упрощенный
костяк процесса разработки. Это средство, в контексте которого можно наблюдать
UML в действии. С учетом небольших вариаций (настроек), принципы GRAPPLE
224
Часть I. Начало
можно применять для довольно большого количества различных организаций (правда,
не для всех). Руководитель проекта вправе добавить туда собственные идеи касательно
работы в конкретной организации и пропустить шаги, которые в данном случае не
нужны.
UML в конкретном контексте
Перед обсуждением процесса GRAPPLE можно задать себе вопрос: Зачем это рассматрива-
ется в книге по UML?
Ответ следующий. Если не обсудить процесс разработки и не обеспечить контекст для ис-
пользования UML, то все обучение закончится описанием диаграмм. Очень важно знать, ко-
гда и зачем использовать каждую из них.
В части II будет рассмотрен конкретный пример разработки системы с применением
GRAPPLE и UML.
RAD3: Структура GRAPPLE
GRAPPLE состоит из пяти сегментов, или этапов. Автор предпочитает использо-
вать термин “сегмент” вместо “этап”, чтобы у читателя не закралось ощущение того,
что один “этап” должен быть завершен до начала другого. Каждый сегмент, в свою
очередь, состоит из нескольких операций. Выполнение каждой операции завершается
результатом (продуктом), и за каждую операцию отвечает конкретный исполнитель.
В большинстве случаев руководитель проекта может объединять результаты дея-
тельности в отчете, который он представляет клиенту. В сущности, результаты служат
для той же цели, что и бумажные отчеты, только без “затопления” проекта бумажной
рутиной.
Для настройки (подгонки) процесса GRAPPLE руководитель проекта может добав-
лять операции к каждому этапу. Допустимо также опуститься на уровень ниже и раз-
делить каждую операцию на подоперации. Есть еще одна возможность: реорганизо-
вать операции каждого сегмента. Естественно, при этом нужно руководствоваться по-
требностями организации.
GRAPPLE предназначен для объектно-ориентированных систем. Поэтому опера-
ции каждого сегмента связаны с получаемыми результатами деятельности в рамках
объектно-ориентированного подхода.
Процесс GRAPPLE включает несколько сегментов.
1. Выяснение набора требований.
2. Анализ.
3. Проектирование.
4. Разработка.
5. Развертывание.
Эту совокупность сегментов обозначают по начальным буквам английского назва-
ния каждого сегмента — Requirements, Analysis, Design, Development и Deployment —
RADDD, или RAD3. По завершении третьего сегмента руководитель проекта объеди-
няет результаты в проектную документацию для клиента и разработчиков. Когда сег-
менты RAD3 завершены, все результаты объединяют в документ, в котором описыва-
ется система.
Перед началом выполнения всех этих этапов нужно изучить бизнес-процессы, ко-
торые будут реализованы в новой системе. Нужно также набрать членов коллектива, в
частности аналитиков, чтобы изучить всю необходимую документацию.
Рассмотрим все сегменты более тщательно с учетом тех элементов UML, которые
будут использоваться в каждом из них.
15-й час. Место UML в процессе разработки
225
Формулирование требований
Если попытаться определить относительную важность каждого сегмента, то этот
этап займет первое место. Ведь если не ясно, что именно необходимо клиенту, соот-
ветствующая система никогда не будет построена. Никакой мировой опыт анализа не
поможет, если разработчики не знакомы с предметной областью клиента и его про-
блемами.
Изучение бизнес-процессов
Разработку следует начать с изучения сути бизнес-процессов, особенно той их час-
ти, которую требуется улучшить с помощью предлагаемой системы. Чтобы выработать
понимание, аналитик беседует с клиентом или с назначенным им компетентным ли-
цом и шаг за шагом выясняет все существенные детали.
Важным итогом этого общения является изучение аналитиком рабочей термино-
логии клиента (или необходимой ее части). Во время следующей итерации аналитик
использует терминологию, приобретенную при общении с клиентом.
Результатом этой работы будет диаграмма видов деятельности или набор диаграмм
видов деятельности, которые охватят основные шаги и точки принятия решений биз-
нес-процесса (или процессов).
Анализ предметной области
Примером этой операции служит беседа с баскетбольным тренером. Она выполня-
ется во время того же совещания, в рамках которого осуществляется изучение бизнес-
процессов. Ее целью является получение наиболее точного понимания предметной
области клиента. Заметим, что эта и предыдущая операции касаются понятий, а не
создаваемой системы. Аналитик должен почувствовать себя свободно в мире клиента,
поскольку он будет его эмиссаром в коллективе разработчиков.
Задача общения аналитика с клиентом — понять основную суть предметной облас-
ти. В течение беседы аналитика с клиентом другой член коллектива разработчиков де-
лает заметки (лучше всего при помощи переносного компьютера с текстовым редак-
тором), а разработчик модели строит диаграмму классов высокого уровня. Еще лучше,
если в команде есть несколько человек, которые записывают содержание беседы.
Разработчик модели отмечает существительные и начинает с представления каж-
дого существительного в виде класса. В конечном счете, некоторые существительные
становятся атрибутами. Разработчик модели также отмечает и глаголы, которые станут
операциями классов. На этом этапе очень большое значение приобретают компью-
терные средства моделирования.
Записывать или не записывать?
Необходимо ли записывать на диктофон эти беседы или достаточно ограничиться заметка-
ми? Этот вопрос возникает довольно часто. Когда записывается разговор, возникает со-
блазн не вслушиваться в него и не стенографировать. (Ведь позже всегда можно прослу-
шать запись.) И все же автор советует забыть о диктофоне и делать заметки, как будто дик-
тофона нет.
Диктофон полезно использовать для обучения нового разработчика модели. Разработчик со
стажем может сравнить диаграммы нового разработчика с записью обсуждения и, таким об-
разом, проверить его компетентность.
Определение взаимосвязанных систем
Поэт XVII века Джон Донн (John Donne) писал: “Человек — не остров, живущий
сам по себе”. Если бы Джон Донн жил сейчас, то он бы написал приблизительно так:
226
Часть I. Начало
“Человек — не самодостаточный участок земли, окруженный водой”. Он мог бы на-
писать и так: “Система — не остров...” и т.д.
И был бы прав по всем пунктам. Современные бизнес-системы, как правило, не
подвешены в вакууме. Они должны взаимодействовать с другими системами. В начале
процесса разработки команда выясняет, от каких систем будет зависеть новая система
и какие системы будут зависеть от нее. Системный инженер строит диаграмму развер-
тывания с учетом результатов этих исследований. На диаграмме система изображена в
виде узлов, с линиями коммуникаций между ними, компонентов-резидентов и зави-
симостей между компонентами.
Выяснение системных требований
Данная операция чрезвычайно важна. Об этом можно догадаться, исходя из слова
“требования” в названии. Выполнение этой операции начинается в рамках сеанса или
семинара по совместной разработке приложения JAD (Joint Application Development) и
продолжается на других этапах процесса GRAPPLE.
В семинаре участвуют представители организации клиента, принимающие реше-
ния, потенциальные пользователи и члены коллектива разработчиков. Заинтересован-
ные лица назначают руководителя семинара. Его работа заключается в том, чтобы вы-
яснить требования к системе со стороны организации клиента и потенциальных поль-
зователей. По крайней мере два члена группы разработчиков должны делать заметки,
а разработчик модели, как правило, вносит уточнения в диаграмму классов, построен-
ную ранее.
Результаты деятельности выводятся в виде диаграммы пакетов. Каждый пакет опи-
сывает высокоуровневую область выполняемых функций системы (например,
“содействие в обслуживании потребителя”). В каждом пакете сгруппирован набор
прецедентов (например, Воссоздание истории потребителя и Контакты между
потребителями).
Длительность семинара определяется сложностью системы. Он занимает, как ми-
нимум, половину рабочего дня и может затянуться на полную рабочую неделю. Орга-
низация клиента должна выделить необходимое для этого время.
Почему для разработки системных требований так необходим этот семинар? Не
поговорить ли с каждым индивидуально? Как говорилось ранее, процесс разработки
лучше завершить в максимально короткие сроки. Беседы с каждым займут неделю и
даже больше, если графики работы этих людей будут перекрываться. Ожидание ре-
зультатов индивидуальных бесед отнимет много времени и, соответственно, лишит
разработчиков возможности завершить проект в установленные сроки. В индивиду-
альных беседах люди могут выражать противоположные точки зрения, и коллектив
потеряет много времени на поиск компромиссов. Групповая работа обеспечивает це-
лостность, которая значит гораздо больше суммы отдельных частей. Взаимодействие
между участниками семинара создаст симбиоз, выгодный каждому отдельному участ-
нику.
Представление результатов клиенту
По завершении этапа формулировки требований руководитель проекта представля-
ет результаты клиенту. В некоторых организациях на этом этапе требуется одобрение
клиента для продолжения разработки. В других — могут потребовать смету расходов.
Поэтому результаты этого этапа варьируются в соответствии с требованиями органи-
зации.
15-й час. Место UML в процессе разработки
227
Анализ
На этом этапе коллектив углубляется в анализ результатов стадии формулировки
требований и, таким образом, расширяет свое понимание проблемы. В сущности, от-
дельные операции этого этапа начинают выполняться уже в процессе формулирова-
ния требований, и разработчик модели начинает вносить уточнения в диаграмму
классов во время семинара по определению требований.
Определение прецедентов системы
Эта операция представляет собой анализ прецедентов высокого уровня. В рамках
семинара коллектив разработчиков общается с пользователями для выявления испол-
нителей, инициирующих прецеденты и пользующихся результатами этих прецедентов.
(Исполнителем может быть как система, так и конкретный человек.) Снова назнача-
ется руководитель семинара и два члена команды, протоколирующих это заседание.
После нескольких таких семинаров руководитель может с легкостью переквалифици-
роваться в аналитика прецедентов.
Группа разработчиков пытается также выявить новые прецеденты. Результаты вы-
полнения операции представляются в виде набора диаграмм прецедентов, на которых
изображаются исполнители и всевозможные зависимости между прецедентами со сте-
реотипами (<<расширяет>> и <<включает>>).
Конкретизация прецедентов
Во время этой операции коллектив разработчиков продолжает работать с пользова-
телями. Целью операции является анализ последовательности действий при реализа-
ции каждого прецедента. Такой семинар может быть продолжением предыдущего. За-
метим, что это самый сложный семинар для пользователей. Возможно, они не при-
выкли разбивать операции на составляющие действия и точно перечислять их.
Результаты выполнения операции будут представлены в виде текстового описания
шагов каждого прецедента.
Внесение уточнений в диаграммы классов
Во время семинара разработчик модели выслушивает все дискуссии и продолжает
вносить уточнения в диаграмму классов. На этом этапе разработчик модели должен
определить имена ассоциаций, абстрактных классов, значения кратности, выявить от-
ношения обобщения и агрегации. Результатом выполнения этой операции будет
уточнение диаграммы классов.
Анализ изменений состояния объектов
Разработчик модели продолжает уточнять ее, описывая изменения состояний там, где
это необходимо. Результатом выполнения этой операции будет диаграмма состояний.
Определение взаимодействий между объектами
Теперь, имея набор диаграмм прецедентов и уточненную диаграмму классов, самое
время определить, как взаимодействуют объекты. Разработчик модели строит набор
диаграмм последовательностей и коопераций для описания взаимодействия. Сюда
также необходимо включить диаграммы изменения состояния. Результатом выполне-
ния этой операции является перечень соответствующих диаграмм.
228
Часть I. Начало
Анализ уровня интеграции с другими системами
Параллельно со всеми предыдущими видами деятельности системный инженер
определяет характерные детали интегрирования разрабатываемой системы с другими
системами. Какой тип взаимодействия здесь присутствует? Какова архитектура сети?
Если система должна иметь доступ к базам данных, то аналитик баз данных определяет
их архитектуру (физическую или логическую). Результатом выполнения этой операции
будут подробные диаграммы развертывания и (если необходимо) модели данных.
Проектирование
На этом этапе команда работает над результатами анализа и принимает проектные
решения. От этапа проектирования необходимо постоянно возвращаться к сегменту
анализа, вплоть до завершения работ по проектированию. В некоторых методиках
этапы анализа и проектирования даже объединяют в одну стадию.
Построение и уточнение диаграмм объектов
На основе диаграмм классов программисты генерируют все необходимые диаграм-
мы объектов. Они конкретизируют диаграммы объектов путем исследования каждой
операции и построения соответствующих диаграмм видов деятельности. Диаграммы
видов деятельности служат основой для большинства программ на этапе разработки.
Результатом выполнения этой операции будут диаграммы объектов и диаграммы ви-
дов деятельности.
Построение диаграмм компонентов
Во время этой операции основную функцию выполняют программисты. Целью
операции является визуальное представление компонентов, а также описание зависи-
мостей между ними. Результатом выполнения этой операции будут диаграммы ком-
понентов.
План развертывания
После завершения работы над диаграммами компонентов системный инженер на-
чинает планирование развертывания и интеграции системы. Он создает диаграмму, на
которой показана схема развертывания компонентов. Результат выполнения опера-
ции — диаграмма, которая является частью диаграммы развертывания, построенной
ранее.
Проектирование и создание прототипа пользовательского
интерфейса
Во время выполнения этой операции должен состояться еще один семинар с уча-
стием пользователей. Несмотря на то что данная операция относится к сегменту про-
ектирования, дополнительный семинар может быть продолжением предыдущих — как
свидетельство взаимодействия между сегментами анализа и проектирования.
В пользовательском интерфейсе должны быть учтены все прецеденты. Для того
чтобы выполнить эту операцию, аналитик графического интерфейса пользователя
(Graphical User Interface) работает с клиентами для создания на бумаге прототипа эк-
ранов, соответствующих группам прецедентов. Пользователи высказывают свои поже-
лания по поводу управляющих элементов (кнопок, флажков, раскрывающихся спи-
сков, меню и т.д.). Когда они одобрят расположение компонентов, разработчики нач-
нут создание прототипа интерфейса. Результатом выполнения операции будут копии
экрана из этого прототипа.
15-й час. Место UML в процессе разработки
229
Проектирование тестов
Знание прецедентов позволяет спроектировать процедуры тестирования программ-
ного обеспечения. Их целью является определение соответствия разработанного про-
граммного обеспечения запланированным результатам — это делается при помощи
прецедентов. Желательно, чтобы разработчик или специалист по тестированию неза-
висимо от коллектива разработчиков на основе диаграммы прецедентов написал тес-
товые программы для автоматизированных средств тестирования. Тестовые програм-
мы и являются результатом выполнения этой операции.
Техническая документация
Никогда не рано начинать создание документации системы для конечных пользова-
телей и системных администраторов. Специалист по документации параллельно с про-
ектировщиками работает над документами и созданием для каждого документа структу-
ры высокого уровня. Результатом выполнения операции будет структура документа.
Разработка
Это уже сфера деятельности программистов. С учетом всестороннего анализа и
проектирования работа на данном этапе пройдет быстро и гладко.
Конструирование кода
Имея в своем распоряжении диаграммы классов, диаграммы объектов, диаграммы
видов деятельности и диаграммы компонентов, программисты реализуют систему в
программном коде. Этот код и будет результатом выполнения данной операции.
Тестирование кода
Специалисты по тестированию (не разработчики) запускают тестовые программы
для проверки корректности работы кода. Результатом выполнения этой операции бу-
дут данные теста. Эта операция возвращает разработчиков к предыдущей операции до
тех пор, пока код не пройдет все уровни тестирования.
Конструирование пользовательского интерфейса,
подключение к коду и тестирование
В этой операции используется утвержденный заинтересованными лицами прото-
тип пользовательского интерфейса. Специалист по GUI конструирует этот интерфейс
и подключает его к программному коду. С помощью тестирования проверяется функ-
циональность интерфейса. Результатом выполнения операции будет работающая сис-
тема, оснащенная пользовательским интерфейсом.
Завершение комплекта документации
На этапе разработки специалист по написанию документации параллельно обща-
ется с программистами и занимается доработкой документации, которая и является
результатом выполнения этой операции.
Развертывание
По завершении процесса разработки систему устанавливают на соответствующих
аппаратных средствах и интегрируют с другими системами. Однако первая операция
на этом участке работ может выполняться задолго до начала этапа разработки.
230
Часть I. Начало
Планирование средств резервирования и восстановления
Системный инженер создает пошаговый план на случай полного отказа системы.
В этом плане, который и является результатом выполнения данной операции, описыва-
ется, как создать резервную копию и восстановить систему в случае ее полного отказа.
Установка готовой системы на соответствующих
аппаратных средствах
Системный администратор при помощи программистов (в случае необходимости)
устанавливает готовую систему на соответствующем компьютере (или компьютерах).
Результатом выполнения этой операции будет полностью развернутая система.
Тестирование установленной системы
В заключение коллектив разработчиков тестирует установленную систему. Функ-
ционирует ли она так, как было запланировано? Работают ли средства резервирования
и восстановления информации? Результаты тестов определяют необходимость даль-
нейшего усовершенствования и являются итогом выполнения данной операции.
Празднование
Тут все понятно. Коллектив сам решает, каким результатом должно завершиться
выполнение этой, возможно, наиболее опасной для здоровья операции.
Итоговые замечания о процессе GRAPPLE
Проследив этапы и операции процесса GRAPPLE, можно заметить движение от
общего к частному — от неизвестного к известному. Сначала достигается концепту-
альное понимание предметной области, затем определяются выполняемые функции
высокого уровня, далее — прецеденты, потом происходит уточнение модели, проекти-
рование, разработка, и развертывание системы.
Можно также подметить, что этапы анализа и проектирования включают большее
количество операций, чем этап разработки. Так и должно быть. Суть в том, чтобы по-
тратить как можно больше времени на предварительный анализ и проектирование. То-
гда сам процесс программирования пройдет гладко. Это может показаться странным, но
в идеальном случае программирование является всего лишь малой частью процесса раз-
работки системы. Чем тщательнее проведен анализ, тем ближе к идеалу система.
Как было сказано, GRAPPLE — это упрощенный костяк процесса разработки. Он
не затрагивает таких важных деталей, как уровни тестирования, и не касается сле-
дующих вопросов: каким образом команда убеждается в развитии проекта? Как ко-
манда справляется со всеми важными деталями организационной деятельности?
Эти темы не были затронуты, поскольку они не имеют прямого отношения к об-
суждению UML. Для того чтобы получить ответы на эти вопросы, нужно испытать
описанную методику на практике. Результаты деятельности (законченные или проме-
жуточные) можно поместить в общем хранилище данных организации. Можно также
создать иерархию каталогов, доступных для всех членов команды. Но наиболее безо-
пасный способ — установить средство контроля версий, которым регистрируются ре-
зультаты деятельности участников проекта. Отлаживать и копировать эти документы в
каждый момент времени может только один человек. Это является основой решения
организационных вопросов. Средства контроля версий неуклонно развиваются и об-
новляются.
В следующей главе начнется рассмотрение конкретного примера разработки сис-
темы с применением UML и процесса GRAPPLE.
15-й час. Место UML в процессе разработки
231
Резюме
Методика разработки позволяет структурировать этапы и виды деятельности в
процессе разработки системы. При отсутствии методики разработчики не смогли бы
понять суть проблемы, которую они пытаются разрешить, и системы не соответство-
вали бы требованиям своих пользователей. В ранних методиках пропагандировалась
“каскадная” последовательность этапов анализа, проектирования, программирования
и развертывания.
Этот тип методики приводит к изоляции этапов разработки, когда команда разра-
ботчиков не в состоянии углублять свое понимание во время разработки проекта. При
этом, как правило, основное внимание уделяется написанию программ, и не остается
времени на анализ и проектирование.
В этой главе представлены принципы быстрого проектирования приложений
GRAPPLE (Guidelines for Rapid APPLication Engineering), составляющие костяк про-
цесса разработки. Процесс GRAPPLE складывается из пяти этапов или сегментов:
формулирование требований, анализ, проектирование, разработка и развертывание.
Каждый сегмент состоит из нескольких операций. Результатом выполнения большин-
ства этих операций являются диаграммы UML.
В части II рассматривается конкретный пример применения процесса GRAPPLE и
языка иМЕдля разработки системы.
Вопросы и ответы
Применяется ли где-либо “каскадный” метод разработки?
Если масштабы разрабатываемой системы невелики, то можно применить после-
довательную методику разработки. Однако для современных объектно-
ориентированных систем гораздо лучшие результаты может дать использование других
подходов.
В предыдущем ответе была упомянута разработка объектно-ориентированных систем.
А если предлагаемая система не является объектно-ориентированной?
Идеи, рассмотренные в этой главе, вполне пригодны для систем, выходящих за
рамки объектно-ориентированного подхода. Семинары, предварительный анализ и
проектирование, взаимосвязь этапов разработки прекрасно подходят и для такого слу-
чая. Тогда придется несколько адаптировать процесс GRAPPLE (например, путем ис-
ключения моделирования классов и самих классов). Но гибкие принципы разработки
гораздо лучше, чем жестко заданная методика.
Практические занятия
Теперь проверьте полученные знания о методиках с помощью тестов. Ответы на
вопросы находятся в приложении А.
Тесты
1. Что обычно интересует клиента?
2. Что подразумевается под методикой разработки?
3. Что собой представляет “каскадный” метод разработки? В чем его недостатки?
4. Что такое сегменты GRAPPLE?
5. Что такое сеанс JAD?
232
Часть 1. Начало
Часть II
Конкретный пример
Темы занятий
16. Знакомство с конкретным примером
17. Анализ предметной области
18. Формирование системных требований
19. Разработка прецедентов
20. Взаимодействие элементов системы и изменение их состояния
21. Проектирование интерфейса пользователя и развертывание системы
22. Знакомство с шаблонами проектирования
16-й час
Знакомство с конкретным примером
Из этого часа вы узнаете
> Как построить сценарий для конкретного примера
> Что такое изучение и моделирование бизнес-процессов
> Получите полезные советы по интервьюированию
Теперь, после закрепления практического опыта работы с UML и рассмотрения
основ методологии разработки программных систем, приступим к применению UML
в процессе разработки. Эта глава посвящена конкретному примеру, в котором UML
применяется в контексте процесса GRAPPLE, (Guidelines for Rapid APPLication Engi-
neering)
Перейдем к делу
Крупнейшие многонациональные (вымышленные) конгломераты LaHudra, Nar и
Goniff, Inc. провели исследования на базе широкой сети ресторанов и пришли к за-
ключению: люди предпочитают питаться вне дома, но им не нравится обслуживание.
“А знаете, — сказал представитель LaHudra, — я мог бы заранее предсказать ре-
зультаты исследований. Заходя перекусить, я терпеть не могу, когда официант берет
мой заказ и исчезает на час. Лучше я пойду в хорошее место, где смогу рассчитывать
на более качественное обслуживание.”
“Ваша правда, — вторил ему представитель Nar, — иногда я хочу изменить уже
сделанный заказ, и мне приходится долго ждать официанта. Или же хочу о чем-то
спросить и не могу найти этого парня”.
Представитель Goniff поддерживает беседу: “Согласен. Ведь сходить пообедать —
это не шутки. Мне нравится, когда кто-нибудь меня обслуживает. Мне нравится, ко-
гда персонал кухни готовит для меня пищу. Результаты наших исследований показы-
вают, что большинство людей думают точно так же”.
“Существует ли способ повысить уровень обслуживания на основе такого практи-
ческого опыта?”
“Какой же?” — спрашивает представитель Nar.
“Я знаю, какой! — говорит представитель LaHudra. — С помощью компьютерной
технологии”.
После такого обсуждения они решили поручить группе разработчиков программ-
ных систем создать ресторан будущего.
Применение процесса GRAPPLE для
решения проблемы
Все члены группы разработчиков оказались убежденными сторонниками процесса
GRAPPLE. Они понимают, что основное время, выделенное на проект, следует по-
святить анализу и проектированию. Тогда программирование пройдет быстро и глад-
ко, а вероятность того, что при установке и развертывании не будет никаких проблем,
существенно повысится.
Начинать нужно с выяснения системных требований и понимания предметной об-
ласти ресторанов. Как было описано в предыдущей главе, этап формулирования тре-
бований состоит из следующих операций.
Исследование бизнес-процессов.
Анализ предметной области.
Определение взаимодействующих систем.
Изучение системных требований.
Представление результатов клиенту.
В этой главе будет рассмотрена первая из этих операций.
Исследование бизнес-процессов
Компании LaHudra, Nar и Goniff ко всему подходят масштабно. Они готовы объе-
динить свои усилия и создать новую всемирную сеть ресторанов LNG (по первым бу-
квам названий конгломератов). Для этого они набирают опытных администраторов,
официантов, шеф-поваров и обслуживающий персонал.
Однако сначала необходимо создать технологическую основу для будущего ресто-
рана. Тогда с ее помощью можно обучить первых администраторов качественному об-
служиванию.
За дело берется замечательная команда разработчиков. Они начинают, как гово-
рится, с чистого листа. Всем необходимо понять суть бизнес-процессов и предметной
области.
Анализ бизнес-процесса начинается с интервью с администратором ресторана. Во
время беседы стенографист делает заметки, обычно с помощью переносного компью-
тера. В то же время разработчик модели на доске изображает и модифицирует диа-
граммы видов деятельности, иллюстрирующих беседу аналитика, стенографиста и ад-
министратора ресторана.
В следующих разделах мы остановимся на беседах по поводу каждого бизнес-
процесса ресторана. Целью бесед является построение диаграмм видов деятельности
для моделирования процесса.
16-й час. Знакомство с конкретным примером
235
Обслуживание клиента
“Спасибо за предоставленное время”, — говорит аналитик.
“Очень приятно, — отвечает администратор. — Что конкретно вас интересует?”
“Давайте начнем с главного. Что происходит, когда клиент приходит в ресторан?”
“Происходит следующее. Если клиент в верхней одежде, мы помогаем ему раз-
деться, относим одежду в гардероб и даем номерок. То же самое относится к головно-
му убору. Затем мы ...”.
“Одну секунду. Давайте вернемся назад. Предположим, стоит очередь. Встанут ли
клиенты в очередь или запишутся в список ожидающих?”
“Нет. Мы пытаемся сразу же предоставить им максимум удобств. Также приносим
извинения за очередь, если она есть. Если ресторан действительно переполнен, мы
спрашиваем клиента, хочет ли он зарезервировать столик. Мы всегда стараемся сразу
отдать дань уважения и разместить людей из списка как можно быстрее. Если же мес-
та не зарезервированы, клиенты всегда могут записаться, а тем временем пойти в наш
коктейль-бар и выпить перед обедом. Естественно, они не обязаны это делать. Но все
же смогут подождать своей очереди в уютном месте”.
“Интересно. Они, еще не заказывали блюда, а уже имеют несколько точек приня-
тия решений!”
Давайте прервемся и оценим такой момент. Диаграмма видов деятельности для
этого бизнес-процесса выглядит примерно так, как изображено на рис. 16.1.
Рис. 16.1. Начальная часть диаграммы видов деятельности для бизнес-процесса
“Обслуживание клиента ” в ресторане
Вернемся к беседе.
Работа аналитика заключается в том, чтобы изучить бизнес-процесс.
— Отлично. Когда подходит очередь клиента из списка ожидающих, или когда
прибывает клиент, забронировавший столик, нужно разместить этого клиента, пра-
вильно?
— Точно. Правда, теперь я сам вижу, что не все так просто. Столик нужно подго-
товить. Естественно, он должен быть чистым, поэтому уборщица меняет скатерть по-
сле предыдущего клиента и сервирует столик. Затем метрдотель проводит клиента к
столику и зовет официанта.
— Зовет?
236
Часть II. Конкретный пример
Совет 1: добивайтесь определений
К чему клонит аналитик? Администратор использовал новый термин (новый в ходе беседы),
и аналитику требуются разъяснения.
Необходимо научиться применять такие приемы в процессе интервью с клиентом. Лучшим
учителем в этом будет практический опыт.
— Да. Дело в том, что за официантами закреплены определенные столики и они
обычно знают, когда место для посетителя уже подготовлено. Наблюдая за своими
столиками, они видят все жесты метрдотеля.
— Что происходит потом?
Официант начинает обслуживание. Он рассказывает о каждом блюде из меню и
интересуется, не желает ли клиент чего-нибудь выпить, пока блюда будут готовиться.
Затем вызывает помощника, который приносит поднос с хлебом и маслом, наливает в
стаканы воду для каждого члена компании. Если кто-нибудь заказывает выпивку, то
официант приносит ее клиенту.
— Одну секунду. Вы сказали “он”. Человек, который обслуживает столик, всегда
мужчина?
— Нет. Я сказал по привычке. Прошу прощения.
— Хорошо. Как насчет использования нейтрального слова “обслуживающий пер-
сонал”? Замечу также, что клиент может заказывать выпивку дважды.
— Это так. Если клиент ожидает столика в баре с выпивкой, то он может забрать с
собой недопитый бокал. В то же время мы можем отказать в обслуживании тому, кто
уже чересчур “набрался”.
Совет 2: определяйте бизнес-логику
Интервьюер не всегда пассивно выслушивает ответы на вопросы. В данном случае аналитик
должен объединить ответы на вопросы, заданные ранее, и задавать новые вопросы, чтобы вы-
делить определенные моменты (возможность заказа выпивки). Ответы описывают логику биз-
нес-процесса или бизнес-правила, которые выполняются в отдельных ситуациях. Здесь причи-
на отказа опьяневшему клиенту в дальнейшем обслуживании объясняется бизнес-логикой.
— Вернемся к выбору блюд из меню.
— Да. У нас всегда имеются постоянные блюда, которых нет в меню, и офици-
ант.., вернее, обслуживающий персонал перечисляет их клиенту.
— Знаете, как я себе это представляю? Люди спрашивают, что им порекомендуют
выбрать, а официанты абсолютно честно рассказывают, чем же одно блюдо лучше
другого. Вы поощряете это?
— Не совсем. Обслуживающий персонал питается в нашем ресторане и имеет свои
пристрастия. И если официантам действительно не нравится какое-то блюдо, они
должны сказать об этом шеф-повару до того, как говорить о нем клиенту. Они не
могут рассказывать клиентам о своих предпочтениях. Мы ведь не хотим, чтобы наш
обслуживающий персонал своими “рекомендациями” вызывал у клиента отвращение
к пище, лучше объяснить причины предпочтения одного блюда другому.
— Понятно. Хорошо, давайте подведем итог. Клиент.., хотя обычно это компания,
не так ли? Компания сдает свою верхнюю одежду, присаживается в баре, ожидает
свободного столика, садится за него, возможно, заказывает выпивку, получает хлеб и
воду и изучает меню.
Совет 3: периодически подводите итоги
Это хорошая идея — время от времени останавливаться и подводить итог. Это позволяет
проверить свое понимание с использованием терминологии предметной области, а также
вести беседу на хорошем уровне и внимательно выслушивать участников опроса.
16-й час. Знакомство с конкретным примером
237
— Правильно. Обслуживающий персонал приносит заказанное, и клиенты пьют,
изучая меню. Официант предоставляет им пять-десять минут для выбора блюд и воз-
вращается за заказом. Естественно, если клиенты сделали выбор раньше, то обслужи-
вающий персонал тоже возвращается раньше.
— А как он узнает, что надо вернуться раньше?
— Ну, клиенты должны привлечь его внимание. Обычно он находится недалеко от
столика, если ему не нужно сходить на кухню передать заказ или же о чем-то погово-
рить с шеф-поваром.
— Недалеко?
— Да. Каждый официант обслуживает определенное количество столиков (часть
зала). Часть зала предназначена для курящих, остальные — для некурящих.
— Как вы определяете, кто обслуживает ту или иную часть зала?
— Мы чередуем обслуживающий персонал по всем частям зала.
— Давайте вернемся к процессу обслуживания. Клиенты выбирают блюда, персо-
нал записывает их выбор, а затем...
— А затем информирует шеф-повара. Обслуживающий персонал записывает заказ
на бланке, который отдает шеф-повару.
— Как оформляется бланк заказа?
— Номер столика, выбранные блюда и, что очень важно, время приготовления.
— Почему это так важно?
— Потому, что кухня обычно (так мы рассчитываем) очень загружена и шеф-повар
часто сам определяет сроки и время приготовления заказанных блюд.
— Могут ли здесь быть какие-либо трудности?
— Некоторые осложнения возникают с очередностью обслуживания.
— Как так?
— Большинство клиентов перед основным блюдом заказывают закуски для повы-
шения аппетита. Обычно люди предпочитают получить основное блюдо горячим. Та-
ким образом, шеф-повар готовит закуски, — а многие из них уже готовы (например,
салаты), — и обслуживающий персонал выносит эти закуски к столику. Сложность
заключается в том, чтобы принести основные блюда для всех членов компании в одно
и то же время и в горячем виде. Дело в том, что люди за столиком обычно съедают
свои закуски за разное время. Все это необходимо координировать.
— М-да... это выглядит как отдельный процесс. Давайте и обсудим его отдельно —
с учетом мнения шеф-повара.
— Нет проблем. Идея, неплохая.
— Итак, мы остановились на том, что шеф-повар готовит основное блюдо. Кстати,
как вам нравится наша диаграмма (рис. 16.2)?
— Думаю, вы все правильно поняли. Как бы то ни было, шеф-повар готовит ос-
новное блюдо, а обслуживающий персонал забирает его, когда участники компании
доели свои закуски. Официант приносит блюдо к столику. Люди едят свои кушанья, а
официант по крайней мере еще раз подходит к столику для дальнейшего обслуживания.
Совет 4: сложные процессы обсуждайте отдельно
Аналитик принял важное решение— отложил обсуждение последовательности, которая,
возможно, представляет собой отдельный процесс. Чтобы почувствовать, когда это необхо-
димо сделать, нужен опыт.
Небольшой совет. Если опрашиваемый будет использовать в общении такие слова, как
“комплексный” и “составной”, или ответы “да” на вопросы о необходимости разбиения
сложных моментов на набор шагов для моделирования, нужно подумать о новом процессе.
— Предположим, клиент недоволен пищей.
— Тогда мы готовим то, что ему точно понравится, даже если это нам обойдется
дороже. Лучше потерять немного денег, чем потерять клиента.
238
Часть II. Конкретный пример
Рис. 16.2. Средняя часть диаграммы видов деятельности для бизнес-процесса
“Обслуживание клиента ” в ресторане
— Хороший подход.
— Спасибо. Когда клиенты пообедают, обслуживающий персонал спрашивает, не
желают ли они десерт. Если ответ положителен, официант приносит меню десертов и
принимает заказ. Если же клиенты отказываются от десерта, то он предлагает кофе. В
случае согласия он приносит чашки и наливает кофе. Если клиенты больше ничего не
желают, то обслуживающий персонал приносит счет. Через несколько минут он полу-
чает оплату по счету в виде наличных денег или кредитных карточек. Он возвращает
сдачу и/или квитанции об оплате с кредитных карточек, клиенты оставляют чаевые,
надевают верхнюю одежду и уходят.
— Именно так?
— В основном. Официант вызывает уборщика, чтобы тот очистил столик, и ожи-
дает следующую компанию клиентов.
— Мне хотелось бы обсудить еще некоторые моменты — хотя бы кратко, посколь-
ку у меня возникло несколько вопросов. Первый: как обслуживающий персонал узна-
ет, что люди уже закончили обедать?
16-й час. Знакомство с конкретным примером
239
— Официант стоит и наблюдает за своими столиками. Опытный официант знает,
сколько времени потребуется посетителю, чтобы съесть блюдо, т.е. может предвидеть,
когда ему необходимо появиться возле столика. Вы хотели еще о чем-то спросить?
— Да. Ранее вы сказали, что официант может находиться на кухне, чтобы перего-
ворить с шеф-поваром. Почему так происходит?
— Иногда клиент хочет знать, как долго ему ждать блюда. В таких случаях клиент
зовет официанта, который идет на кухню и спрашивает об этом шеф-повара. Выяснив
все, он возвращается и сообщает клиенту полученную информацию.
— Вы знаете, я раньше никогда не представлял себе комплексно процесс обслужи-
вания клиента в ресторане.
— Признаться, я и сам до тех пор, пока мы с вами не разобрали по косточкам все
эти шаги, никогда не обдумывал их так детально. Надеюсь на вашей диаграмме изо-
бражено все, о чем я говорил, и она удачно проиллюстрирует мои размышления на
эту тему (рис. 16.3).
Как было сказано в главе 11, “Диаграммы видов деятельности”, диаграмму видов
деятельности можно преобразовать в диаграмму с “плавательными дорожками”. Это
очень полезно делать при моделировании бизнес-процесса, поскольку на диаграмме с
“плавательными дорожками” видна роль каждого действующего лица процесса. На
рис. 16.4 изображена диаграмма с “плавательными дорожками” для бизнес-процесса
“Обслуживание клиента”.
Приготовление блюда
Вспомним первый отдельный процесс, выявленный во время беседы. Давайте
вновь присоединимся к аналитику и администратору ресторана и исследуем процесс
“Приготовление блюда”.
— Вы упомянули о том, — сказал аналитик, — что большинство клиентов заказы-
вают закуски для повышения аппетита и хотят, чтобы основное блюдо приносили го-
рячим. Вы говорили о проблемах, связанных с тем, чтобы принести основное блюдо для
каждого члена компании в одно и то же время и в горячем виде. Также вы останавлива-
лись на проблеме важности координации. Не могли бы вы уточнить сказанное?
— Конечно, — отвечает администратор. — Члены компании практически всегда
съедают закуску, салат или суп в разное время. Мы же должны скоординировать вы-
нос основных горячих блюд для каждого. Координация проводится официантом и
шеф-поваром. Шеф-повар принимает заказ у официанта, начинает готовить закуски и
основное блюдо. Когда закуски готовы, официант возвращается на кухню, берет их и
выносит к столику.
— И официант знает о том, что закуски готовы, поскольку?..
— Поскольку он время от времени проверяет работу на кухне. Теперь начинается
процесс координации: шеф-повар после передачи закусок официанту ждет от офици-
анта информации о том, когда каждый член компании почти доел свою закуску, что-
бы закончить приготовление основного блюда. Официант (или официантка) стоит и
наблюдает за столиком. В соответствующий момент официант возвращается на кух-
ню, сообщает шеф-повару о готовности клиентов к приему основного блюда, и шеф-
повар заканчивает его приготовление. Опытный шеф-повар, работая с группой по-
мощников, координирует приготовление блюд одновременно для нескольких компа-
ний клиентов. Цель заключается в том, чтобы основное блюдо было готово, как толь-
ко клиент захочет приступить к нему.
— Всегда ли это происходит вовремя?
— Нет, не всегда. Но, при наличии небольшого опыта и здравого смысла, это бу-
дет получаться чаще. Иногда один медлительный едок в компании не совсем готов,
когда мы выносим основное блюдо, поэтому возникают незначительные затруднения.
— Ясно. Что вы думаете о нашей диаграмме для этого процесса (рис. 16.5)?
240
Часть II. Конкретный пример
[одет в верхнюю одежду и/
или головной убор] .
Помогает снять верхнюю одежду
Сдает одежду и/или головной
[список ожидающих]
Усаживает клиента
[не зарезервирован]
[предпочитает бар]
Ожидает в баре
холл]
Вызывает официанта
[предпочитает
Ожидает в холле
Столик подготовлен
Описывает меню
^Приносит хлеб' и воду
Изучает меню^
Описывает постоянные блюда
Принимает заказ на выпивку
[желает выпить] 1 ' |
Получает выпивку^
Вызывает помощника
Приносит выпивку
Информирует шеф-повара
Ест закуски
Приносит основное блюдо
[желает десерт]
Приносит закуски
Готовит основное
Показано на
отдельной диаграмме
(рис. 16.5)
Ест основное блюдо
Оплачивает счет
Оставляет чаевые
[желает кофе]
Приносит меню десертов
Выбирает десерт
[желает кофе]
Наливает кофе
Наливает кофе
Приносит десерт
Приносит счет
Пьет кофе
Ест десерт
V
V
[одежда и/или головной
убор сданы] <аб1ГОает
одежду и/
или головной убор
Рис. 16.3. Полная диаграмма видов деятельности для бизнес-процесса “Обслуживание
клиента ” в ресторане
16-й час. Знакомство с конкретным примером
241
(Продолжение)
Рис. 16.4, а. Диаграмма с “плавательными дорожками” для бизнес-процесса “Обслужива-
ние клиента” (первая часть)
242
Часть II. Конкретный пример
Рис. 16.4, б. Диаграмма с “плавательными дорожками”для бизнес-процесса “Обслужива-
ние клиента ” (вторая часть)
16-й час. Знакомство с конкретным примером
243
основное
Рис. 16.5. Диаграмма видов деятельности для
процесса “Приготовление блюда ”
Как и в случае предыдущего бизнес-процеса, на рис. 16.6 изображена диаграмма с
“плавательными дорожками”.
244
Часть II. Конкретный пример
Рис. 16.6. Диаграмма с “плавательными дорожками” для процесса
“Приготовление блюда ”
Уборка стола
— Давайте обратимся к процессу уборки стола, — предлагает аналитик.
— Здесь также необходима небольшая координация. Удостоверившись, что клиен-
ты ушли, официант вызывает уборщика, чтобы тот позаботился о столике. Если зал
переполнен, это нужно сделать быстро. Уборщиков у нас гораздо меньше, чем офици-
антов, поэтому иногда это происходит бессистемно. Уборщик не всегда оказывается
рядом, поэтому официант должен буквально охотиться за ним.
— Думаю, я понял, что вы имеете в виду под выражением “позаботиться о столи-
ке”, но нельзя ли об этом рассказать поподробнее?
— Конечно. В ресторане, которым я управляю, имеются чистые скатерти для каж-
дого приема. Таким образом, уборщик должен свернуть использованную скатерть,
принести чистые тарелки, столовые приборы и салфетки и сервировать ими стол.
Свернутую скатерть он относит в служебное помещение. Мы пакуем их и на следую-
щий день отправляем в прачечную.
На рис. 16.7 изображена диаграмма видов деятельности для этого бизнес-процесса.
16-й час. Знакомство с конкретным примером
245
Упаковка старой скатерти для прачечной
Рис. 16.7. Диаграмма видов деятельности
для бизнес-процесса “Сервировка стола ”
Полученные уроки
Тому, кто хочет стать аналитиком, необходимо вынести следующие уроки из этого
интервью.
Время от времени останавливайтесь и подводите итог, чтобы проверить свое
понимание и знания терминологии; это поможет провести беседу на хоро-
шем уровне.
Стремитесь получать разъяснения всех незнакомых терминов. Не стоит бо-
яться, если чего-то не знаете. Только так можно по-настоящему ознако-
миться с процессом и изучить терминологию. Новый словарный запас по-
может потом углубиться в анализ предметной области.
Задавайте как можно больше вопросов. Необходимо постоянно отслеживать
содержание беседы и задавать новые вопросы. Логика бизнес-процессов час-
то всплывает именно в ответах на вопросы.
Когда заходит речь о бизнес-логике, делайте пометки. Сохраняйте записи
этих правил. Они могут пригодиться позже. (Кто знает, может быть, однаж-
ды вы захотите создать автоматизированный набор инструментальных
средств на основе этих правил.) Естественно, записи нужно вести во время
встреч.
Если вы считаете часть процесса замкнутым циклом, выделите ее в виде от-
дельного, независимого бизнес-процесса. Это облегчит моделирование. Если
не пытаться представлять все части процесса как единое целое, конечная
модель будет иметь более отчетливый вид.
246
Часть II. Конкретный пример
Возвращайте опрашиваемого к диаграммам видов деятельности. Вносите все
модификации, которые он посоветует сделать.
В этой главе рассмотрены многие вопросы и полезные технические приемы. Со
временем их можно развить.
В следующей главе приступим к анализу предметной области.
Резюме
В этой главе рассмотрен сценарий конкретного примера, где для процесса разра-
ботки был применен UML. В этом сценарии вымышленные конгломераты LaHudra,
Nar и Goniff решили внедрить компьютерные технологии в работу ресторана будуще-
го. Работа аналитиков заключается в том, чтобы понять бизнес-процессы, предметную
область и сформулировать требования, — т.е. выполнить операции первого этапа про-
цесса GRAPPLE.
Создаваемая сеть ресторанов LNG предоставляет экспертов в предметной области,
которые хорошо знакомы с бизнес-процессом.
Содержимое этой главы в основном было посвящено интервью с экспертами. В
примечаниях даются советы о том, как вести разговор. Цель заключалась в том, чтобы
объяснить приемы отображения результатов интервью в модели UML.
В следующей главе приступим к анализу предметной области.
Вопросы и ответы
Всегда ли операции выполняются в том порядке, в каком они перечислены в этой
книге?
Нет. Иногда есть смысл избрать иной порядок. Например, можно исследовать сис-
темные требования, прежде чем определить взаимодействующие системы. Для неко-
торых проектов часть этих операций может оказаться необязательной. Некоторые
операции выполняются параллельно с другими.
Всегда ли опросы проводятся только одним человеком? Разве два не лучше, чем один?
Обычно, лучше всего выяснять бизнес-логику в процессе беседы аналитика, с экс-
пертом один на один. Тогда эксперт не будет себя чувствовать жертвой перекрестного
допроса. Можно обдумать возможность замены интервьюеров в процессе опроса. Вто-
рой опрашивающий может внести новую струю в проведение интервью.
Существуют ли какие-то особые соображения по поводу ведения записей?
Удостоверьтесь в том, что в начале записей аккуратно отмечена дата, время, место
и имена участников сеанса. Никто не знает, когда может понадобиться эта информа-
ция, поэтому не стоит полагаться на свою память. Естественно, записывать нужно
столько, сколько возможно. Для этого можно даже пригласить стенографиста. Описы-
вая интервью только в общих чертах, вы можете упустить из виду существенную ин-
формацию.
Могу ли я что-то упустить из виду, если буду записывать все сам?
Безусловно. И поэтому лучше, если записи будут вести несколько человек. Тогда
один отметит то, что упустит другой. Помните, что ваши заметки могут быть частью
документации, которую вы отдадите клиенту. Делайте их более полными, тогда будет
легче проследить развитие идеи.
16-й час. Знакомство с конкретным примером
247
Практические занятия
Чтобы реально уловить суть всего вышесказанного, ответьте на вопросы теста и
выполните упражнения. Ответы находятся в приложении А.
Тесты
1. Какая диаграмма UML больше всего подходит для моделирования бизнес-
процесса?
2. Как модифицировать эту диаграмму, чтобы с ее помощью описать роли раз-
личных действующих лиц?
3. Что означает термин “бизнес-логика” ?
Упражнения
1. Попробуйте применить принципы, описанные в этой главе, к иной предмет-
ной области. Предположим, LaHudra, Nar и Goniff предложили вам возглавить
коллектив разработчиков по созданию системы для корпоративной библиоте-
ки. Начните с формулирования требований для того, чтобы понять и смодели-
ровать происходящие здесь бизнес-процессы. Для этого вам необходимо ис-
пользовать собственные познания о библиотечном деле. Сохраните свои запи-
си, поскольку пример с библиотекой будет использован для выполнения
упражнений в последующих главах этой части.
2. Просмотрите интервью из этой главы. Какие аспекты бизнес-логики всплы-
вают в ходе его проведения?
3. Приведенные в этой главе диаграммы видов деятельности достаточно полно
описывают рассмотренные бизнес-процессы. Однако в качестве упражнения
попробуйте применить другие приемы из UML 2.0. Вернемся к рис. 16.5. Ка-
кие узлы объектов можно добавить к этой диаграмме?
248
Часть II. Конкретный пример
17-й час
Анализ предметной области
Из этого часа вы узнаете
> Как анализировать результаты интервью
> Как разработать исходную диаграмму классов
> Как выявлять ассоциации между классами
> Как определить кратность ассоциаций
> Как создавать композиты
> Как расширить описание классов
Продолжим концептуальный анализ на этапе формулирования требований в кон-
тексте процесса GRAPPLE.
Первые две операции процесса GRAPPLE связаны скорее с предметной областью,
чем с самой системой. В предыдущей главе речь не шла о предлагаемой системе. В
этой главе о ней тоже ничего не будет сказано. Действительно, пока лишь было полу-
чено задание от компаний LaHudra, Nar и Goniff использовать компьютерную техно-
логию для улучшения качества обслуживания в ресторане.
Цель этой и предыдущей глав заключается в углублении понимания предметной
области. Нужно разобраться в специфике процессов, которые должны быть усовер-
шенствованы, и в сущности того мира, где происходят эти процессы. Изучение биз-
нес-процессов даст мощный толчок для повышения знаний коллектива разработчи-
ков. В результате при общении с экспертами сети ресторанов LNG разработчики
смогут пользоваться терминологией предметной области. Это обеспечит основу для
дальнейшего углубления знаний в процессе развития проекта.
Анализ интервью
Команда разработчиков продолжит беседы с экспертами, но сначала необходимо
проанализировать результаты проведенного интервью. Цель заключается в том, чтобы
построить исходную диаграмму классов. Аналитик делает это либо во время интервью,
либо на основе его результатов. На этом этапе разработчик модели изучает существи-
тельные и глаголы. Некоторые из существительных становятся классами, некото-
рые — атрибутами. Глаголы могут стать операциями или именами ассоциаций.
Рассмотрим интервью из предыдущей главы. Какие существительные и глаголы
использовал администратор ресторана?
Употреблялись такие существительные, как клиент, верхняя одежда, гардероб, но-
мерок, головной убор, очередь, список обслуживания, резервирование, имя, коктейль-
бар, спиртное, обед, столики, обслуживаемые официантом, столик, уборщик, ска-
терть, метрдотель, официант, клиент, меню, помощник, поднос, хлеб, масло, стакан,
вода, прием, обслуживающий персонал, выбор меню, выбор, постоянное блюдо, рес-
торан, шеф-повар, блюдо, кухня, заказ, место для курящих, форма, время, закуски,
основное блюдо, десерт, меню десертов, кофе, чашка, счет, наличность, кредитные
карточки, квитанция об оплате, чаевые, сдача, столовые приборы, салфетка, комната,
прачечная.
Заметим, что все существительные употребляются в единственном числе.
Также использовались следующие глаголы: иметь, помогать, хранить, дать, стано-
виться в очередь, подзывать, присесть, покидать, сидеть, обслуживать, подходить, ос-
вободиться, усаживать, расхаживать, звать, прохаживаться, видеть, жестикулировать,
показывать, спрашивать, заказывать, решать, подзывать, приносить, наливать, заказы-
вать, идти, получать, приносить, закончить, резервировать, отказываться, перечислять,
спрашивать, рекомендовать, поддерживать, предпочитать, рассказывать, высказывать,
смотреть, возвращаться, пить, читать, предоставлять, делать выбор, привлекать вни-
мание, говорить, поручать, описывать, определять, уведомлять, записывать, давать,
отдавать предпочтение, состоять из, готовить, приносить, заканчивать, координиро-
вать, готовить (пищу), забирать, есть, приходить, начинать работу, удостоверяться,
стоить, терять деньги, терять клиента, проходить, спрашивать, хотеть, обеспечить,
принять заказ, наливать, получать, покидать, звать, убирать, подготовить, наблюдать,
предвкушать, говорить, выходить, позвать, возвращаться, выяснять, рассказывать,
обеспечивать, предпочитать, получать, проверять, полагаться, оставаться, не упускать
из виду, убирать, удостоверяться, заботиться, охотиться, сменять, сворачивать, скла-
дывать, сервировать, паковать, отправлять.
Эти существительные и глаголы составляют довольно внушительный список. Нуж-
но ли разработчику модели использовать все эти слова? Нет. Здравый смысл подска-
жет, какие использовать, а какие нет.
Разработка исходной диаграммы классов
Представим себя в роли аналитика и начнем разработку диаграммы классов. Здесь,
как было сказано выше, нужно руководствоваться здравым смыслом. Начнем с ис-
ключения некоторых существительных.
Как видно из интервью, слова “обслуживающий персонал” и “официант” — сино-
нимы. Таким образом, одно из них можно исключить. Поскольку интервьюер и оп-
рашиваемый сошлись на “обслуживающем персонале”, исключаем слово “официант”
“Клиент” и “посетитель” — также синонимы, поэтому исключаем одно из этих слов
Остановимся на “клиенте”. “Выбор меню” и “выбор” означают одно и то же, поэто
250
Часть II. Конкретный приме
му исключаем одно из них. Слово “выбор” звучит более определенно (правда, это за-
висит от точки зрения), поэтому оставим именно его.
Можно ли исключить другие слова? Некоторые существительные относятся, ско-
рее, к атрибутам, чем к классам. Например, “имя”, “время” и “резервирование”. Сло-
во “прачечная” не относится к ресторану, поэтому его тоже исключаем.
Теперь посмотрим с другой стороны: можно добавить один или два новых класса.
Просмотрев интервью, можно заметить, что администратор ресторана ссылается на
“закрепленную часть зала” и “чередование обслуживающего персонала”. Кто занима-
ется “закреплением” и “чередованием”? Чтобы внести ясность, введем в список класс
“управляющий”. Об этом классе могло не говориться в интервью, поскольку внима-
ние аналитика было сосредоточено на клиенте, обслуживающем персонале, шеф-
поваре и уборщике.
Добавление класса (абстрактного класса, как мы увидим позже) отражает развитие
понимания процесса.
После отбраковки синонимов и атрибутов и добавления нового класса получим
следующий список существительных, которые могут стать классами: клиент, верхняя
одежда, гардероб, номерок, головной убор, очередь, список, коктейль-бар, спиртное,
обед, место ожидания, столик, уборщик, скатерть, метрдотель, площадь обслужива-
ния, меню, помощник, поднос, хлеб, масло, стакан, вода, компания, обслуживающий
персонал, выбор, постоянное блюдо, ресторан, шеф-повар, блюдо, кухня, заказ, место
для курящих, форма, закуски, основное блюдо, десерт, десертное меню, кофе, чашка,
счет, наличность, кредитные карточки, квитанция об оплате, чаевые, сдача, столовое
серебро, салфетка, комната, управляющий, резервирование.
Теперь используем эти понятия для построения диаграммы классов, как показано
на рис. 17.1. Имя каждого класса будем писать с прописной буквы. Если в имени
класса присутствует несколько слов, соединим их, начиная с прописной буквы каждое
слово в имени.
Группирование классов
Теперь попробуем сформировать конкретные группы. Одна состоит из людей: кли-
ент, компания, уборщик, метрдотель, помощник, шеф-повар, обслуживающий персо-
нал и управляющий. Эту группу можно было бы разделить на несколько других, по-
скольку все ее участники, за исключением клиента и компании, являются служащими.
Другая группа складывается из пищевых продуктов: спиртное, обед, хлеб, масло,
вода, постоянное блюдо, блюдо, закуски, основное блюдо, десерт и кофе.
Третья группа состоит из утвари: стакан, столовые приборы, поднос, чашка, сал-
фетка и скатерть.
Четвертая группа содержит элементы оплаты: номерок гардероба, счет, сдача, кре-
дитная карточка, квитанция об оплате и чаевые.
Еще одна группа состоит из площадей ресторана: холл, место для курящих, кок-
тейль-бар, гардероб, кухня, площадь обслуживания и служебное помещение
(комната). Имеется в виду комната, где хранятся скатерти (и, по-видимому, другие
вещи), которые отправляются из ресторана в прачечную. Чтобы описать это помещение
более определенно, назовем его “комната для использованных скатертей и салфеток”.
И, наконец, можем объединить в группу бланки ресторана: меню, меню десертов,
номерок гардероба, счет и бланк. Под бланком подразумевается документ, который
официант отдает шеф-повару при поступлении заказа на кухню. Для большей опреде-
ленности назовем его “бланком заказа”.
Заметим, что некоторые элементы входят в две группы (бланки и элементы опла-
ты). Как будет видно из дальнейшего, это вполне допустимо.
17-й час. Анализ предметной области
251
Клиент
ВерхняяОдежда
Гардероб
НомерокГардероба
ГоловнойУбор
Очередь
СписокОжидающих
КоктейльБар
Выпивка Обед
Холл
Столик
Уборщик
Скатерть
Метрдотель
ПлощадьОбслуживания
Меню
Помощник
Поднос Хлеб
Масло
Стакан
Компания
ОбслуживающийПерсонал
ШефПовар
Блюдо
Бланк
Чашка
ОсновноеБлюдо
КредитнаяКарточка
Наличные
Чаевые
КвитанцияОбОплате
СтоловыеПриборы
Салфетка
Комната
Управляющий
Резервирование
Рис. 17.1. Исходная диаграмма классов для предметной области ресторана
Что делать с этими группами? Любое название группы может стать абстрактным
классом — классом, не имеющим экземпляров, но выступающим прародителем для
подклассов. Таким образом, абстрактный класс Площадь Ресторана имеет таких по-
томков, как КоктейльБар, ПлощадьОбслуживания, Столик, Холл, Гардероб и Кухня.
252
Часть II. Конкретный пример
Можно модифицировать диаграмму классов, изображенную на рис. 17.1, и постро-
ить другую (рис. 17.2).
Рис. 17.2. Абстрактные классы позволяют выделить на диаграмме классов конкретные
группы
Формирование ассоциаций
Выявим ассоциации между некоторыми классами. Глаголы помогут в разметке, но
не будем ограничиваться глаголами из интервью. Можно использовать имена ассо-
циаций, которые более точно определяют суть.
Можно взять несколько классов и попытаться выявить ассоциации между ними,
затем перейти к другой группе, пока перечень классов не закончится. Потом выявля-
ют агрегаты и композиты. Таким образом, глаголы преобразуются в операции классов.
17-й час. Анализ предметной области
253
Ассоциации класса Клиент
Начнем с класса клиент. Какие классы связаны с ним ассоциациями? Это Резер-
вирование, Меню, Пища, МенюДесертов, Десерт, Заказ, Счет, Чаевые, ВерхняяОдеж-
да и ГоловнойУбор. На рис. 17.3 изображены эти ассоциации.
Рис. 17.3. Исходные ассоциации класса Клиент
На этом этапе можно принять некоторые соглашения. Действительно ли так необ-
ходимо вводить классы ВерхняяОдежда и ГоловнойУбор? Как-никак нас интересует
обслуживание в ресторане. После обсуждения вопроса можно для полноты оставить
эти классы в модели. Можно даже добавить еще один класс Гардеробщик, поскольку
кто-то должен обеспечивать сохранность верхней одежды и головного убора клиента.
Пометим ассоциации фразами, которые их характеризуют:
Клиент осуществляет Резервирование;
Клиента обслуживает ОбслуживающийПерсонал;
Клиент ест Пищу;
Клиент ест Десерт;
Клиент делает Заказ;
Клиент выбирает из Меню;
Клиент выбирает из МенюДесертов;
Клиент оплачивает Счет;
Клиент оставляет Чаевые;
254
Часть II. Конкретный пример
Клиент забирает ВерхнююОдежду у Гардеробщика;
Клиент забирает ГоловнойУбор у Гардеробщика.
На рис. 17.4 изображены ассоциации с указанием имен.
Рис. 17.4. Ассоциации класса Клиент
Теперь остановимся на вопросе кратности ассоциаций. Она фиксирует количество
экземпляров класса Б, которые связаны с одним экземпляром класса А.
В большинстве выделенных фраз объект класса Клиент имеет дело с одним экзем-
пляром другого класса. В некоторых фразах присутствует пассивный залог
(“обслуживается”), в то время как в других используется активный залог (“платит” и
“оставляет”). Это означает, что на другом конце ассоциации могут быть разные объ-
екты. Если вернуться к ассоциации, связанной с объектом ОбслуживащийПерсонал
(“ОбслуживающийПерсонал обслуживает Клиента”), то станет ясно, что Обслуживаю-
щийПерсонал может обслуживать много объектов Клиент.
В двух последних фразах появляется новый тип ассоциации.
Клиент забирает ВерхнююОдежду у СлужащегоГардероба.
Клиент забирает ГоловнойУбор у СлужащегоГардероба.
Как ее моделировать?
Этот тип ассоциации называется тернарной ассоциацией. Слово “тернарная” в на-
звании означает, что она имеет отношение к трем классам. Этот тип ассоциации изо-
бражается путем соединения классов с ромбиком, а имя ассоциации размещается воз-
ле этого ромбика, как показано на рис. 17.5. В тернарной ассоциации с помощью
значений кратности фиксируется количество экземпляров двух классов при условиях,
которые содержит третий класс. В этом примере один Клиент может сдать на хране-
17-й час. Анализ предметной области
255
ние несколько объектов ВерхняяОдежда и ГоловнойУбор. (В одной ассоциации мо-
жет быть задействовано более трех классов. Для этого в UML используется название
“n-арная ассоциация”.)
Рис. 17.5. Тернарная ассоциация
В следующем подразделе рассмотрим другой способ формирования ассоциаций.
На рис. 17.6 изображены все ассоциации класса Клиент с указанием кратности.
Рис. 17.6. Ассоциации класса Клиент с указанием кратности
256
Часть II. Конкретный пример
Ассоциации класса
ОбслуживающийПерсонал
Используем связь между классами Клиент и ОбслуживающийПерсонал для форми-
рования набора ассоциаций класса ОбслуживающийПерсонал.
Одним из способов моделирования многих ассоциаций класса Обслуживающий'
Персонал является представление их в виде тернарных ассоциаций:
ОбслуживающийПерсонал принимает Заказ у Клиента;
ОбслуживающийПерсонал передает Заказ ШефПовару;
ОбслуживающийПерсонал обслуживает Клиента во время ПриемаПищи;
ОбслуживающийПерсонал обслуживает Клиента во время приема Десерта;
ОбслуживающийПерсонал приносит Меню Клиенту;
ОбслуживающийПерсонал приносит ДесертноеМеню Клиенту;
ОбслуживающийПерсонал приносит Клиенту Счет;
ОбслуживающийПерсонал берет Наличные Клиента.
ОбслуживающийПерсонал берет КредитныеКарточки Клиента.
Это может внести неразбериху в модель и затруднить понимание. Более удобный
способ заключается в том, чтобы минимизировать число ассоциаций, введя соответст-
вующие классы.
Работа объекта ОбслуживающийПерсонал заключается в том, чтобы приносить и
брать какие-то вещи. Введем класс ассоциаций ЗапрпашиваемыйПредмет, в котором
определим, что приносится и берется. Для этого добавим к классу ассоциаций атрибут
под названием предмет и отнесем его к перечислимому типу. Возможные значения
атрибута — это предметы, которые ОбслуживающийПерсонал может приносить или
брать (рис. 17.7).
Рис. 17.7. Использование классов ассоциаций для класса Обслуживаю-
щийПерсонал
Между классами ОбслуживающийПерсонал, Помощник и Уборщик тоже присутст-
вуют ассоциации, что и изображено на рис. 17.8.
17-й час. Анализ предметной области
257
ОбслуживающийПерсонал
Помощник
Рис. 17.8. Дополнительные ассоциации класса ОбслуживающийПер-
сонал
Ассоциации класса ШефПовар
На рис. 17.9 изображены ассоциации класса ШефПовар с классами Обслуживаю-
щийПерсонал, Помощник и Пища. Класс ассоциаций Заказ является моделью реаль-
ного заказа, который обслуживающий персонал приносит шеф-повару, а его атрибут
(перечислимого типа) отражает статус заказа.
Рис. 17.9. Связь класса ШефПовар с классами ОбслуживающийПерсонал, По-
мощник и Пища
258
Часть II. Конкретный пример
Ассоциации класса Уборщик
Как видно из рис. 17.10, класс Уборщик имеет две ассоциации. Первая свидетель-
ствует о том, что ОбслуживающийПерсонал может вызывать Уборщика, а кратность
этой ассоциации означает, что вызывать его могут несколько разных официантов.
Другая ассоциация связывает уборщика с несколькими разными столами.
Рис. 17.10. Ассоциации класса Уборщик
Ассоциации класса Управляющий
Управляющий является новым классом, который введен в процессе анализа пред-
метной области. Этот класс имеет ассоциации со многими другими классами, которые
можно описать следующими фразами:
Управляющий руководит Рестораном;
Управляющий наблюдает за Служащими;
Управляющий наблюдает за Кухней;
Управляющий общается с Клиентом.
Эти ассоциации показаны на рис. 17.11.
Отступление
В некоторых школах моделирования считается, что при выявлении ассоциаций не-
обходимо исключить существительные, описывающие действующих лиц, и довольст-
воваться только обобщенным классом Служащий. Тогда имя действующего лица нуж-
но размещать в соответствующем конце линии ассоциации.
В некоторых системах (например, платежных) это довольно удобно. Но в данном
случае это не так. Рассмотрим такие ассоциации:
ОбслуживающийПерсонал приносит Клиенту;
ОбслуживающийПерсонал берет у Клиента;
ОбслуживающийПерсонал приносит ШефПовару;
ОбслуживающийПерсонал забирает у ШефПовара;
ОбслуживающийПерсонал вызывает Уборщика.
17-й час. Анализ предметной области
259
Рис. 17.11. Ассоциации класса Управляющий
На рис. 17.12 изображена такая диаграмма.
Вызывает
Приносит
Рис. 17.12. Моделирование класса Служащий
На этой диаграмме обозначения классов расположены слишком плотно, что не по-
зволяет даже включить классы ассоциаций.
Пусть же нашим руководящим принципом в моделировании будет доходчивость.
Формирование агрегатов и композитов
До сих пор рассматривались лишь абстрактные классы, а другие организационные
аспекты пока не затрагивались. Следующим этапом работы будет нахождение классов,
которые станут компонентами других классов. Для данной предметной области это
несложно. Например, пища состоит из закусок, основного блюда, напитков и десерта.
Закуски и десерт необязательны. Поскольку компоненты расположены в определен-
ной очередности, ее необходимо отразить и в модели.
Вот некоторые композиты:
Заказ состоит из нескольких объектов ВыборИзМеню;
260
Часть II. Конкретный пример
Ресторан состоит из Кухни, одной или нескольких ПлощадейОбслужива-
ния, КоктейльБара и КомнатыСтирки;
ПлощадьОбслуживания состоит из одного или нескольких Столиков;
Компания состоит из одного или нескольких Клиентов.
В каждом случае компонент является членом только одного агрегата. На рис. 17.13
эти взаимосвязи показаны в виде композитов.
Рис. 17.13. Композиты предметной области ресторана
Конкретизация классов
Дальнейшие интервью помогут конкретизировать классы. Следует помнить, что на
этом и дальнейших этапах работы разработчик модели должен присутствовать на всех
интервью и вносить уточнения в модель по ходу дела. Начнем уточнение с добавле-
ния некоторых атрибутов и операций.
17-й час. Анализ предметной области
261
Наиболее важными классами являются Клиент, ОбслуживающийПерсонал, ШефПо-
вар, Управляющий и Помощник. Еще одним важным классом является Счет.
Клиент
Вот очевидные атрибуты класса Клиент:
имя;
времяПрихода;
заказ;
времяОбслуживания.
Что касается операций, то здесь поможет список глаголов. У класса Клиент име-
ются следующие операции:
есть();
пить();
пьянеть(шутка!);
заказать();
оплатить().
На рис. 17.14 изображен класс Клиент.
Клиент
имя
времяПрихода
заказ
времяОбслуживания
есть()
пить()
заказать()
оплатить()
Рис. 17.14. Класс Клиент
Служащий
Обслуживающий персонал, шеф-повар и помощник являются потомками абст-
рактного класса Служащий. На основе этой информации можно определить атрибуты
класса Служащий и его потомков, наследующих эти атрибуты. Вот некоторые атрибу-
ты этого класса:
имя;
адрес;
номерСтраховки;
опытРаботы;
стаж;
оклад.
Для помощника все несколько усложняется. Для начала необходимо выделить ат-
рибут, называемый работаС, поскольку Помощник может помогать либо обслуживаю-
щему персоналу, либо шеф-повару. Этот атрибут перечислимого типа.
262
Часть II. Конкретный пример
Каждый класс-потомок имеет собственные операции. Классу ОбслуживающийПер-
сонал, как видно из рис. 17.15, соответствуют следующие операции:
провожать();
наливать();
собирать();
вызывать();
контролироватьЗаказ().
Операции шеф-повара такие:
готовитьЗакуски();
готовитьОсновноеБлюдо();
ускорить();
создатьРецепт().
Операции помощника:
готовитьЗакуски();
готовитьОсновноеБлюдо();
податьХлеб();
податьВоду().
Операции управляющего:
наблюдать();
управлятьРестораном();
назначать();
чередовать().
Рис. 17.15. Класс Служащий и его потомки
17-й час. Анализ предметной области
263
Счет
Понятно, что Счет является важным классом, поскольку в нем содержится ин-
формация о накоплении стоимости заказа. Его атрибутами являются:
заказ;
налог;
общая стоимость.
Поскольку общая стоимость состоит из стоимости заказа и налога, она является
вторичной переменной. Это отражено в модели, показанной на рис. 17.16. Операциям
класса Счет являются вычислитьОбщуюстоимость(заказ, налог) и отобразитьОб-
щуюстоимость().
Счет
заказ
налог
/общая стоимость
вычислитьОбщуюСтоимость()
отобразитьОбщуюСтоимость()
Рис. 17.16. Класс Счет
Общие вопросы
Итак, уже собрано достаточно информации. Приведем некоторые советы по общей
организации работы.
Словарь модели
В процессе анализа результатов интервью, бизнес-процессов и предметной области
необходимо составить словарь модели. Это глоссарий по всей терминологии предмет-
ной области. Он поможет слаженно работать и избежать неопределенности.
Например, в предметной области ресторана следует обратить внимание на термин
“меню”. Ведь для администратора ресторана он означает одно, а для разработчика
пользовательского графического интерфейса — совсем другое. Далее: в английском
языке официант, официантка и обслуживающий персонал вообще обозначается сло-
вом “server”, значение которого в лексиконе компьютерных пользователей приобрета-
ет совершенно иной смысл. Общепринятые определения или определения многознач-
ных терминов следует поместить в словарь. Благодаря этому можно избежать недора-
зумений и трудностей. В большинстве инструментальных средств по моделированию
есть возможность создать словарь при построении модели.
Организация диаграмм
Другой совет касается организации диаграмм. Сводить все элементы модели клас-
сов в одну громадную диаграмму довольно неудобно. Необходимо построить главную
диаграмму, на которой будут изображены все связи, ассоциации и обобщения, без
указания атрибутов и операций. Некоторые классы можно разместить на отдельной
диаграмме. Средства моделирования позволяют объединять подобные диаграммы.
264
Часть II. Конкретный пример
Полученные уроки
Итак, что же было изучено в процессе анализа предметной области?
Беседы о бизнес-процессах обеспечивают основу для анализа предметной
области.
Существительные из беседы являются кандидатами на роль классов.
Из модели классов нужно исключить те существительные, которые являются
атрибутами, синонимами других существительных из списка или представ-
ляют классы, не относящиеся к предметной области.
Необходимо своевременно добавить классы, которые не обсуждались во
время беседы с клиентом.
Некоторые глаголы и глагольные связки из интервью используются в каче-
стве имен ассоциаций.
Некоторые классы можно группировать, а имена групп использовать в каче-
стве абстрактных классов.
Группировать классы в агрегаты и/или композиты.
Переименовывать классы для большей ясности.
Некоторые ассоциации могут быть тернарными (т.е. связанными с тремя
классами).
При именовании операций и определении кратности нужно руководство-
ваться соображениями здравого смысла.
В следующей главе мы завершим изучение общих понятий и перейдем к элемен-
там, связанными с системой.
Резюме
В этой главе мы продолжили концептуальный анализ. Результаты бесед о бизнес-
процессе обеспечивают основу для анализа предметной области. Существительные и
глаголы из интервью являются кандидатами для элементов диаграммы концептуаль-
ных классов, описывающих предметную область ресторана. Исходя из здравого смыс-
ла, можно решить, какие слова использовать, а какие исключить. В процессе анализа
можно также добавлять классы.
Разработчик модели укрупняет содержимое диаграммы путем выявления абстракт-
ных классов, ассоциаций и множеств. Выявление агрегатов и/или композитов помога-
ет в организации модели. Для большей полноты модели необходимо проводить до-
полнительные интервью и встречи, но на этом этапе уже можно добавлять атрибуты и
операции.
Вопросы и ответы
Как узнать, какие именно классы исключать из списка кандидатов в классы?
Исключайте лишние названия классов, исходя из соображений здравого смысла, и
помните о названиях, которые являются атрибутами. Исключайте названия классов,
не относящихся к предметной области. И помните, что можно также добавлять собст-
венные классы.
17-й час. Анализ предметной области
265
Практические занятия
Практические задания помогут проверить умение анализировать предметную об-
ласть для создания и совершенствования диаграммы классов. Ответы находятся в
приложении А.
Тесты
1. Как использовать существительные из интервью с экспертом?
2. Как использовать глаголы?
3. Что такое “тернарная” ассоциация?
4. Как моделировать тернарную ассоциацию?
Упражнения
1. Вернитесь к тернарным ассоциациям клиента с гардеробщиком. Используйте
класс ассоциаций для моделирования этих ассоциаций более эффективным
способом.
2. Если вы тщательно изучили интервью и результаты анализа предметной об-
ласти, то можете описать классы, которые не рассматривались. Один из них —
Кассир. Сформируйте ассоциации между классами ОбслуживающийПерсонал
и Кассир. При необходимости используйте класс ассоциаций. Если можно
придумать другие классы, включите в анализ предметной области и их.
3. В композите Ресторан (см. рис. 17.13) присутствуют только “физические”
классы — площади вроде кухни и коктейль-бара. Конечно, можно сказать, что
Ресторан состоит и из людей. Пересмотрите композит Ресторан и включите
в диаграмму служащих. Не будет ли включение служащих означать преобразо-
вание композита в агрегат?
4. В главе 3, “Использование концепций объектно-ориентированного проекти-
рования”, говорилось об обязанностях классов. Добавьте на диаграмму класса
ОбслуживающийПерсонал его обязанности.
5. Обратимся к классам ассоциаций, показанным на рис. 17.7 и 17.9. При упо-
минании каждого из них речь шла об атрибутах перечислимого типа. Промо-
делируйте эти перечислимые типы.
6. Постройте диаграмму классов для предметной области библиотеки из первого
упражнения главы 16, “Знакомство с конкретным примером”.
266
Часть II. Конкретный пример
18-й час
Формирование системных требований
1/1з этого часа вы узнаете
> Что такое видение системы
> Как организовать сеанс совместной разработки приложения JAD (Joint Application
Development)
> Что такое организация системных требований
> Как использовать прецеденты
Заказчики из компаний LaHudra, Nar и Goniff поражены. Они видят результаты
деятельности группы разработчиков и знают, что работа ведется в верном направле-
нии. Все члены команды хорошо понимают предметную область ресторана, причем их
понимание настолько глубоко, что работники ресторанной сети LNG говорят, что на
диаграммах отображены все их суждения об операциях ресторана.
Теперь наступило время работы над технической основой ресторана будущего.
Коллектив располагает знанием бизнес-процессов и диаграммами классов. Поэтому
можно заняться программированием, не так ли? А вот и нет. Группа даже и близко не
подошла к написанию программ. Сначала нужно разработать общее видение системы.
Большинство проектов начинают с такого заявления: “Сконструируем базу данных
таким образом, чтобы служащие смогли ею пользоваться при наличии минимальной
практики” или: “Создадим компьютерный “справочный стол”, при помощи которого
проблемы будут решаться мгновенно”. Сейчас задача команды довольно неопреде-
ленная и звучит как “Использование компьютерной технологии для организации рес-
торана будущего.” Таким образом, необходимо составить представление о техноло-
гичном ресторане. Для начала необходимо выяснить, как персонал ресторана будет
работать с этой технологией. Ведь персонал работает на том уровне, который команда
разработчиков обычно не затрагивает.
Разработчики на основе знания бизнеса-процесса и предметной области должны
понять, как именно улучшится качество обслуживания после внедрения технологии.
Давайте поприсутствуем на семинаре коллектива. В нем участвуют аналитик, разра-
ботчик модели, сотрудник ресторана, официант, шеф-повар и системный инженер.
Семинар ведет его председатель.
Председатель раздает копии диаграммы бизнес-процессов “Обслуживание клиен-
та” (рис. 18.1) и “Приготовление пищи” (рис. 18.2).
Рис, 18,1, а. Диаграмма бизнес-процесса “Обслуживание клиента ” (первая часть)
268
Часть II. Конкретный пример
Клиент
(/Изучает менк^1
(ест закуски
(Продолжение^
Официант
Шеф-повар
Помощник
Уборщик
Метрдотель
(делает выбор
Приносит закуски
Описывает
постоянные блюда
Информирует
шеф-повара
Приносит
сновное блюдо
Т
I
Готовит
основное блюдо,
Показано на
отдельной
диаграмме
(рис. 16.5)
(Ёст основное блюд )
<елает десерт]
(желает Тофе]
Наливает кофе)
Приносит
меню десертов
1ыбирает десер'
Приносит десер^
Приносит C46TJ
Оплачивает счет
вставляет чаевые,
[одежда/головной убор сданы]
абирает одежду
головной убор.
( Уходит
Рис, 18.1, б. Диаграмма бизнес-процесса “Обслуживание клиента”(вторая часть)
Разработка видения системы
Председатель: “Я думаю, из диаграмм бизнес-процесса можно выявить участки,
где пригодится компьютерная технология. На доске будем вести протокол. Итак, кто
желает выступить первым?”
Аналитик: “Ясно, что ресторанный бизнес, как и любой другой, зависит от переда-
чи информации. Если сможем ускорить этот процесс — насколько позволит техно-
логия, — то добьемся своей цели”.
Сотрудник ресторана: “Возможно, я не совсем понимаю. Что вы подразумеваете
под выражением “передача информации”? Мне всегда казалось, что мой бизнес зави-
сит от передачи пищи”.
Системный инженер: “Думаю, я могу помочь. Когда клиент делает заказ, он пере-
дает информацию обслуживающему персоналу (кстати, давайте примем к сведению,
18-й час. Формирование системных требований
269
что “Официант” — это некто, кто обслуживает столик), а тот, в свою очередь, переда-
ет заказ шеф-повару. Таким образом, обслуживающий персонал передает информа-
цию дальше.
Председатель: “Где еще осуществляется передача информации?”.
Официант: “Мне кажется, я понимаю. Когда клиент спрашивает меня, в каком со-
стоянии заказ, а я спрашиваю об этом шеф-повара, то это и есть передача информа-
ции, я прав?”.
Аналитик: “Абсолютно”.
Шеф-повар: “Передача, раздача. Тоже мне, камень преткновения. Меня вообще
раздражает, когда официант околачивается на кухне и задает всякие дурацкие вопро-
сы на предмет того, долго ли еще я буду готовить блюдо. Оно готовится ровно столь-
ко, сколько его нужно готовить, хоть я на голове буду стоять”.
Председатель (пытается утихомирить разбушевавшегося шеф-повара, поэтому во-
влекает в разговор других участников): “Может быть, мы сможем найти способ свести
к минимуму эту проблему. Как насчет других примеров передачи информации?”.
Сотрудник ресторана: “Как насчет того момента, когда официант рассказывает о
фирменных блюдах? Или когда он отвечает на вопросы по поводу меню?”.
270
Часть II. Конкретный пример
Председатель: “Действительно”.
Шеф-повар: “Ну, иногда я все-таки отвечаю на вопросы. Люди отправляют офи-
цианта, чтобы разузнать подробнее о каком-нибудь блюде. Я или передаю информа-
цию официанту, или, если не очень занят, выхожу и сам общаюсь с клиентом. Они
это любят”.
Официант: “Я расскажу о такой передаче информации, которая меня никогда не
радует. Клиент делает заказ, я иду и передаю его дальше, а через пятнадцать минут,
когда я захожу на кухню, мне сообщают, что у нас нет всех ингредиентов для выпол-
нения этого заказа. Я должен вернуться к клиенту и предложить ему заказать что-
нибудь другое. Естественно, его это раздражает, да и меня тоже, поскольку я вынуж-
ден распрощаться со своими чаевыми”.
Аналитик: “Мы должны это включить в бизнес-процесс...”.
Председатель (пытается не уклоняться от темы разговора, поэтому избегает фраз
наподобие “Да-да, конечно, но...”, выводящих собеседников из себя): “Возможно.
Я думаю, что это надо сделать на следующей встрече”.
Аналитик: “Да. Я не собирался отклоняться от темы”.
Председатель (останавливаясь и подводя итоги): “Давайте посмотрим, насколько
мы продвинулись. Согласно моим записям, информация передается в следующих слу-
чаях:
клиент делает заказ;
официант передает заказ шеф-повару;
клиент просит официанта проследить за состоянием заказа;
официант рассказывает о фирменных блюдах;
официант отвечает на вопросы по поводу меню;
шеф-повар отвечает на вопросы о составе блюда.
Аналитик: “Я знаю, что этого нет на диаграммах бизнес-процессов, но неужели у
клиента никогда не возникает вопросов по поводу счета? Ведь когда официант на них
отвечает, речь тоже идет о передаче информации”.
Председатель: “Определенно. Есть еще вопросы по бизнес-процессам?”.
Системный инженер: “У меня есть. Как насчет координирования между официан-
том и шеф-поваром? Они же должны удостовериться, что все члены компании уже
доели свои закуски, чтобы вынести основное блюдо горячим. Это ведь тоже пример
передачи информации”.
Аналитик: “Согласен. Здесь мы имеем два разных способа перемещения информации”.
Сотрудник ресторана: “Вы дали нам только две диаграммы бизнес-процессов. По-
моему, мы создавали еще одну”.
Председатель: “Вы правы. Вот еще одна диаграмма для бизнес-процесса “Серви-
ровка стола” (рис. 18.3).
Аналитик: “Похоже, здесь передается только один блок информации, но я готов
поспорить, что этот блок очень важен. Официант вызывает уборщика, когда приходит
время очистить стол”.
Сотрудник ресторана: “Да, эта информация чрезвычайно важна. Мы не сможем
усадить новую компанию до тех пор, пока столик не будет подготовлен. Если уборка
не всегда начинается и заканчивается вовремя, то у нас в баре и на площади ожида-
ния будут не только голодные, но и недовольные клиенты”.
Разработчик модели: “Я работал над своей диаграммой классов, выслушав всех вас.
Могу я внести предложение? Было бы очень неплохо, если бы наша система — как
бы она ни выглядела — позволяла повысить эффективность обслуживания клиентов”.
Сотрудник ресторана: “Конечно. Тогда мы знали бы, где и что именно улучшать.
Но что вы конкретно имеете в виду?”.
18-й час. Формирование системных требований
271
, ?,
^Вызов уборщика^
^Снятие скатерт^
( Замена скатерти j
ZZEZ
(Сервировка стола)
I
Упаковка старой скатерти для прачечной
Рис. 18.3. Диаграмма бизнес-процесса
“Сервировка стола”
Разработчик модели: “В классе Клиент присутствуют атрибуты времяПрихода и
времяОбслуживания. Я хочу добавить производный атрибут времяОжидания, который
будет вычисляться как разность между значениями времяОбслуживания и времяПри-
хода. Что вы думаете по этому поводу?”.
Сотрудник ресторана: “Хорошая идея. Тогда мы будем знать, насколько эффек-
тивно мы работаем с нашими клиентами”.
Аналитик: “Да. Теперь есть масса данных для обработки, — например, можно вы-
яснить изменение времени обслуживания в зависимости от времени дня, числа офи-
циантов, которые работали в это время, и т.п.”.
Разработчик модели: “Существует и другая возможность. Предположим, у нас есть
атрибут времяУхода и производный атрибут под названием времяПриемаПищи, кото-
рый будет ВЫЧИСЛЯТЬСЯ как разность значений ВремяУхода и времяОбслуживания”.
Председатель: “Я думаю, что наш друг шеф-повар не обидится, если я скажу, что
вы тоже в некотором смысле повар. Есть еще какие-нибудь идеи?”.
Разработчик модели: “Пока мы работаем с атрибутами, основанными на времени,
а что вы скажете о других атрибутах классов ОбслуживающийПерсонал, Помощник И
ШефПовар, при помощи которых управляющий будет знать, как долго каждый служа-
щий выполняет свою работу?”.
Сотрудник ресторана: “Честно говоря, не стоит. Служащие вряд ли придут в вос-
торг от такой идеи тотального наблюдения, да и я, кстати, тоже. Не в том смысле, что
им хочется отлынивать — это вовсе не так, — но слишком уж это напоминает слежку
КГБ. Кому понравится, если кто-то через плечо наблюдает за твоей работой с секун-
домером? Да и что это будет за работа, если постоянно присутствует риск опоздать на
секунду здесь или не успеть там? Ведь если служащие будут довольны, то и клиенты
будут рады, а ресторан от этого только выиграет”.
Шеф-повар: “Это точно. Как я уже говорил, блюдо готовится ровно столько,
сколько его нужно готовить. Мне не хотелось бы видеть эти пачки распечаток и вы-
272
Часть II. Конкретный пример
слушивать указания управляющего, что я должен готовить форель альмандин на 4,5
минуты быстрее”.
Официант: “Мне тоже не хотелось бы получать нагоняи за то, что я слишком
долго несу меню десертов, когда клиент покончил с основным блюдом. Все должно
идти своим чередом”.
Разработчик модели: “Нет проблем. Отбросим эту идею. Действительно, после оз-
накомления с вашим мнением, мой долг — исключить “наблюдение” как операцию
из класса Управляющий. А вы тем временем взгляните на общий вид класса Клиент
(рис. 18.4)”.
Клиент
имя
времяПрихода
заказ
времяОбслуживания
/времяОжидания
времяУхода
/времяПриемаПищи
есть()
пить()
заказать()
оплатить()
Рис. 18.4. Усовершенствован-
ный класс Клиент
Несколько замечаний
Разработчик модели постоянно совершенствует диаграммы классов.
Дискуссия между разработчиком модели, сотрудником ресторана и официантом выявляет
ключевой момент: участие в разработке системы людей, занятых в этом бизнесе, абсолютно
необходимо. Без мнения сотрудника ресторана и официанта было бы потрачено время и
деньги на разработку дополнительных функций наблюдения, которые, в конечном счете, бы-
ли бы исключены. Служащие отреагировали бы на это негативно, повлияв тем самым на
систему и в конечном счете на работу ресторана.
Председатель: “Все это наводит меня на мысль, что можно определить различия
между двумя способами ускорения обслуживания. Первый способ заключается в том,
чтобы увеличить скорость передачи информации. Ну а второй — в увеличении скоро-
сти выполнения задач каждым служащим. Общее мнение группы: первый способ —
хороший, а второй — гораздо хуже. Я прав?”.
(Все дружно соглашаются.)
Аналитик: “Ну а теперь, поскольку мы определились, можно перейти к рассмотре-
нию более конкретных идей, касающихся системы”.
Председатель: “Конечно. Какие идеи?”.
Официант: “Когда я передаю всю эту информацию, то очень много хожу в течение
вечера. Иногда приходится работать достаточно далеко от кухни. Пробежки туда-сюда
отнимают много времени, не говоря уже об усталости”.
Аналитик: “Похоже, нам придется исключить или по крайней мере облегчить эти
пробежки. Таким образом, мы увеличим скорость передачи информации”.
Председатель: “Пробежки?”.
Аналитик: “Да. Наша система должна оградить обслуживающий персонал от необ-
ходимости ходить так много. Понятно, что официанты должны ходить на кухню за
заказом и выносить его к столику. Нужно сделать так, чтобы официанту пришлось
ходить на кухню только за готовыми блюдами”.
18-й час. Формирование системных требований
273
Системный инженер: “Кажется, в этом что-то есть. Как насчет того, чтобы ввести
что-то наподобие локальной сети, соединяющей официантов с кухней или официан-
тов с уборщиком? Тогда информация будет передаваться очень быстро”.
Аналитик: “Терпеть не могу быть занудным, но... локальная сеть? Они ведь будут
постоянно цепляться за провода, ведущие к терминалам. Вместо постоянного хожде-
ния на кухню, официанты будут носиться вокруг терминала. Это уже получится тех-
нология ради технологии. Кому такое нужно?”.
Системный инженер: “Да, если мы сделаем все таким образом, как вы только что
описали, то я согласен — это никому не надо. Так можно даже все ухудшить. Но я
имел в виду не это”.
Аналитик: “А что тогда?”.
Системный инженер: “Предположим, каждый официант и уборщик снабжен тер-
миналом — карманным компьютером. И, представим, мы установили беспроводную
сеть. Можно расположить настольные терминалы на кухне и в офисе управляющего.
Кстати, официант и уборщик могут пользоваться карманным компьютером, но у кар-
манного компьютера экран и клавиатура несколько больше, что поможет обеспечить
большую гибкость в перспективе”.
Аналитик: “Так-так... Это мне нравится. Система, о которой вы говорите, решит
много проблем. Например, когда компания выберет себе блюда, официант наберет их
названия на своем карманном компьютере, и заказ появится на терминале кухни. Это
исключит необходимость передвижения от столика на кухню”.
Официант: “Мне это нравится. Опять же, когда компания закончит с закусками, я
дам знать об этом повару путем ввода соответствующего сообщения в карманном
компьютере. Это избавит меня от необходимости возвращаться на кухню и говорить
шеф-повару, чтобы тот заканчивал приготовление основного блюда”.
Шеф-повар: “А я получу сообщение на кухне. В сущности, все мои помощники
одновременно увидят его на одном большом экране или двух-трех. Мне не придется
постоянно помнить, какой именно помощник готовит данное блюдо, и говорить ему,
сколько времени он должен это блюдо готовить. Они могли бы сами отвечать за свою
работу”.
Системный инженер: “А когда заказ будет готов, вы могли бы отправить сообще-
ние с кухни на карманной компьютер официанта. И ему не нужно будет бегать на
кухню проверять состояние заказа”.
Официант: “Прекрасно. Я мог бы также отправлять сигнал уборщику, чтобы тот
подошел и прибрал столик. Мне не придется бегать по ресторану и искать его. Это бы
действительно ускорило работу”.
Сотрудник ресторана: “А как вы собираетесь все это воплотить в жизнь?”.
Системный инженер: “Сейчас об этом не стоит беспокоиться”.
Председатель: “Таким образом, мы решили все вопросы повестки дня? Наша сис-
тема будет представлять собой беспроводную локальную компьютерную сеть с кар-
манными компьютерами для официантов и уборщиков и настольными компьютерами
на кухне и в офисе управляющего. Но мы упустили еще одно”.
Аналитик: “Что?”.
Председатель: “Надо придумать броское название для системы”.
Шеф-повар: “Можно назвать систему “ВЕЛИКИЙ ШЕФ-ПОВАР”.
Председатель: “Вы на что намекаете?”.
Шеф-повар: “Да так, ни на что. Мне просто нравится такое название”.
Аналитик: “Как насчет названия “беспроводная интерактивная сеть для рестора-
нов”? Аббревиатура — WINER (Wireless Interactive Network for Restaurants)”.
Председатель: “Представляю, что о нас подумают”. (Winer — любитель вина, пья-
ница. — Прим, перев.)
Системный инженер: “Давайте несколько сократим название: беспроводная инте-
рактивная сеть — WIN (Wireless Interactive Network)”.
274
Часть II. Конкретный пример
Шеф-повар: “Лично мне нравится”.
Аналитик: “Мне тоже. WIN — это звучит солидно” (Win — победа. — Прим, перев.)
Председатель: “Все согласны с названием WIN? Хорошо. Думаю, на этом можно
закончить”.
Формулирование системных требований
Команда передает результаты встречи руководителям корпораций. Директор ком-
пании LaHudra просто не может поверить своему счастью в освоении огромной новой
области. Шеф Nar вообще в шоке. Перед глазами руководителя Goniff пляшут денеж-
ные знаки. Они дают команде “зеленую улицу” для дальнейшей работы.
Ну а теперь, когда видение системы сформировано, программисты и системные
инженеры могут приступить к своим прямым обязанностям? Никоим образом. Ко-
манда должна строить систему в соответствии с требованиями пользователей, а не ог-
раничиваться модной технологией. Хотя после встречи уровень понимания значи-
тельно повысился, в концепции системы WIN все еще не учтены идеи и точки зрения
служащих и управляющих, которые будут пользователями этой системы.
Следующая операция процесса GRAPPLE посвящена решению именно этих во-
просов. В течение сеанса JAD (Joint Application Development — совместная разработка
приложения) коллектив будет разбирать и документировать системные требования.
Выяснив эти требования, команда сможет определить сроки и стоимость работ.
Семинар проходит в конференц-зале. Им руководит председатель. Обязательно
присутствие членов команды разработчиков, потенциальных пользователей и экспер-
тов предметной области. Команда разработчиков представлена двумя аналитиками для
дублирования заметок, разработчиком модели, двумя программистами и системным
инженером. В качестве потенциальных пользователей на семинаре присутствуют три
официанта, два шеф-повара, два сотрудника ресторана и два уборщика.
Цель этой встречи состоит в том, чтобы построить диаграмму пакетов, на которой
будут изображены все функции системы. Наборы функций будут представлены в виде
пакетов с указанием прецедентов, относящихся к каждому пакету.
Итак, начнем семинар.
Семинар по формулированию
требований
Председатель: “Для начала я хотел бы поблагодарить присутствующих за то, что
все нашли время посетить наш семинар. Не спорю, эти семинары отнимают много
времени, но они необходимы. Цель нашей встречи — выяснить системные требования
для системы WIN (Wireless Interactive Network — беспроводная интерактивная сеть).
Концепция WIN довольно проста. Мы представляем ее следующим образом: офи-
цианты снабжены карманными компьютерами, при помощи которых они связывают-
ся с кухней и с уборщиками. Такими же компьютерами снабжены и уборщики. На
кухне установлен настольный терминал и один или несколько экранов. Такой же тер-
минал находится в офисе управляющего. Вот примерная схема такой системы”
(рис. 18.5).
Председатель (продолжает): “Мы надеемся установить систему WIN в сети ресто-
ранов LNG, чтобы помочь вам в работе. Для этого необходимо знать, чего вы ожидае-
те от системы. Другими словами, как вы собираетесь использовать систему, когда она
будет установлена?
18-й час. Формирование системных требований
275
Мы будем задавать этот вопрос снова и снова. К концу семинара, думаю, сможем
сформировать набор требований, с которым будет согласен каждый из вас. Представь-
те себе это в виде четкого списка пожеланий. Мы учтем ваши требования при созда-
нии проектного решения, на котором будет основана система. Помните следующее:
нам нужны мнения и идеи каждого из вас, независимо от того, в чем заключается ва-
ша работа”.
Первый аналитик: “Мы можем начать с выяснения основных выполняемых функ-
ций?”.
Председатель: “Конечно можем, если группа согласна”.
Второй сотрудник ресторана: “Я не присутствовал на предыдущих встречах, но ду-
маю, что это хорошая идея. Можем ли мы составить список требований, скажем, в
соответствии с ресторанными площадями? Понимаете, для площадей обслуживания
набор требований один, для кухни — другой, для места ожидания — третий”.
Председатель: “Можно и так”.
Второй аналитик: “Когда я смотрю на диаграммы бизнес-процессов, мне кажется,
что у нас уже есть структура списка”.
Первый программист: “В смысле?”.
Второй аналитик: “В смысле распределения работы. Шеф-повар должен выпол-
нять одну работу, официант — другую и т.д.”.
Председатель: “Звучит хорошо. Можем ли мы согласиться с таким способом орга-
низации?”.
(Все дружно соглашаются.)
Председатель: “Отлично! Исходя из диаграмм бизнес-процессов и диаграмм клас-
сов, получаем следующее распределение обязанностей: обязанности официанта, шеф-
повара, уборщика, помощника и управляющего”.
Второй сотрудник ресторана: “Вы никого не забыли? Как насчет гардеробщика и
бармена?”.
Первый сотрудник ресторана: “Да-а-а. Как же мы их пропустили?”.
Председатель: “Я добавлю их в список, используя обозначения пакетов UML
(рис. 18.6)”.
276
Часть II. Конкретный пример
Функции системы WIN
Рис. 18.6. Пакеты выполняемых функций для системы WIN
Разработчик модели: “Я — за. Только, вот, добавлю кое-какую информацию на
диаграммы классов. Класс Гардеробщик уже есть. Я внесу уточнения и добавлю класс
Бармен”.
Второй сотрудник ресторана: “Я вижу, вы делаете все это на переносном компью-
тере. Не могли бы вы показать нам эти “классы”?”.
Разработчик модели: “Нет проблем. Вот они” (рис. 18.7).
Гардеробщик
Бармен
хранитьОдежду()
хранитьГоловнойУбор()
выдатьНомерок()
принятьЗаказНаСпиртное()
готовитьНапиток()
выдатьЧек()
Рис. 18.7. Классы Гардеробщик и Бармен
Второй сотрудник ресторана: “Как интересно. Может, в перерыве вы объясните
мне, что все это значит?”.
Председатель: “Теперь, поскольку у нас имеются все основные элементы, с кого
начнем?”.
Первый официант: “Как насчет функций официанта?”.
Председатель: “Прекрасно. Итак, какие из функций вы хотели бы видеть в этом
пакете? И помните, мы будем рады выслушать мнение каждого”.
Второй официант: “Мне хочется иметь возможность заносить заказ в свой мини-
компьютер и передавать его на кухню”.
Председатель: “Хорошо. Что еще?”.
18-й час. Формирование системных требований
277
Первый официант: “Могу ли я выяснить состояние заказа?”.
Второй шеф-повар: “А могу ли я информировать официанта о готовности заказа?”.
Председатель: “Да, да и еще раз да. Вы видите, я записываю ваши пожелания в
виде прецедентов. К тому же мы попросим некоторых из вас помочь в их анализе. Но
это уже на другой встрече”.
Итог
Семинар длился в течение дня. В завершение был сформирован набор требований,
которые представили в виде пакетов прецедентов.
Для пакета Официант определены следующие прецеденты:
Прием заказа;
Передача заказа на кухню;
Изменение заказа;
Получение сообщения с кухни;
Контроль состояния заказа;
Уведомление шеф-повара о состоянии компании;
Подготовка счета;
Распечатка счета;
Вызов помощника;
Вызов уборщика;
Прием заказа на спиртное;
Передача заказа на спиртное в бар;
Получение уведомления;
Получение сообщения из бара.
Прецеденты для пакета Шеф-повар:
Хранение рецепта;
Извлечение рецепта;
Информирование официанта;
Получение заявки;
Подтверждение заявки;
Ввод времени приготовления;
Распределение заказа.
Прецеденты для пакета Уборщик:
Получение задания от официанта;
Подтверждение задания;
Сигнал об окончании сервировки.
Прецеденты для пакета Помощник:
Получение задания от официанта;
Получение задания от шеф-повара;
Подтверждение задания;
Сигнал о выполнении задания.
278
Часть II. Конкретный пример
Прецеденты для пакета Бармен:
Ввод состава напитка;
Извлечение состава напитка;
Получение сообщения от официанта;
Получение заявки от официанта;
Подтверждение заявки;
Сигнал о выполнении заявки.
И, наконец, для класса Гардеробщик можно выделить прецеденты:
Выдача номерка для верхней одежды;
Выдача номерка для головного убора.
На рис. 18.8 эта информация представлена на языке UML.
Функции системы WIN
Шеф-повар |
Помощник
Получение
задания от
^официанта
Подтверждение'
задания У
Сигнал
о выполнении
задания
Получение'
задания от
шеф-повара
Бармен
Подтверждение
заявки
< официанта
Извлечение
^пецепта -
Ввод времени
приготовление
Получениеу**—
_ заявки У
'аспределение
заказа
Уборщик |
Получение заявки
от официанта-
^Сигнал об
окончании
гервировкг
Гардеробщик |
Подтверждение]
Ч. задания У
Выдача номерка
для верхней
Ч^. одежды -X
Извлечение
рецепта
. напитка
Получение заявки
от
официанта
Подтверждение
заявки
Получение
сообщения
от официанта
Выдача номерка
для головного
убора -
"'Ввод
рецепта
.напитка.
Подтверждение
заявки
а
Рис. 18.8. Диаграмма пакетов выполняемых функций
Разработчик модели усовершенствовал диаграммы классов путем добавления двух
классов и ассоциаций. Это отображено на рис. 18.9.
18-й час. Формирование системных требований
279
Рис. 18.9. Обновленная информация о классах
Что дальше
Документация проекта растет не по дням, а по часам. В ней описаны бизнес-
процессы, диаграммы классов и набор пакетов выполняемых функций.
Ну а теперь, наверное, можно приступить к программированию? Никоим образом.
В следующей главе еще необходимо проанализировать содержимое пакетов.
Резюме
Команда разработчиков должна представить общий вид компьютерной системы
ресторана будущего. Члены команды приняли решение о том, что ключом успеха ра-
боты системы является ускорение передачи информации, и они добиваются этого при
помощи компьютерной технологии.
На семинаре команда разработчиков встретилась с потенциальными пользователя-
ми и экспертами по предметной области для выяснения системных требований. Ре-
зультатом этой встречи стала диаграмма пакетов, в каждом из которых описан набор
выполняемых функций. Добавление прецедентов в пакеты конкретизирует выполняе-
мые функции.
Вопросы и ответы
Могут ли в семинаре участвовать те же люди, которые были участниками предыдущих
встреч коллектива?
Да. Это целесообразно. Они обычно помнят важные детали, которые могли быть
упущены в записях.
Я заметил, что директора компаний LaHudra, Nar и Goniff не участвуют в этих встре-
чах. Могут ли принимать участие во встречах или семинарах руководители такого уровня?
Нет, не могут. Однако в некоторых организациях высшее руководство принимает
активное участие в семинарах, по крайней мере некоторых. Добиться присутствия ру-
ководства высокого уровня на семинаре довольно сложно.
280
Часть II. Конкретный пример
Всегда ли нужно организовывать функции системы путем распределения функций ме-
жду действующими лицами, как в данном случае?
Нет, не всегда. Способ организации должен соответствовать предметной области.
В сущности, можно было бы пойти альтернативным путем организации ресторанов,
основываясь на другом типе разбиения. Например, в качестве пакетов могут высту-
пать Прием звонков, Решение проблемы, Обратный звонок. Кроме того, в каждый
пакет можно добавить набор прецедентов.
Практические занятия
Проверьте свои знания по формулировке требований. Ответы можно найти в при-
ложении А.
Тесты
1. Как описываются системные требования?
2. Прекращается ли моделирование классов после анализа предметной области?
3. Что такое “фактор пробежек”?
Упражнение
1. Продолжите работу над предметной областью библиотеки из упражнений в
главах 16 и 17. Какие основные пакеты функций здесь присутствуют? Какие
прецеденты можно выделить в этой системе?
18-й час. Формирование системных требований
281
19-й час
Разработка прецедентов
Из этого часа вы узнаете
> Что такое уточнение прецедентов
> Как описывать прецеденты, определять предусловия и постусловия
> Как задавать последовательности действий
> Как строить диаграммы прецедентов
Прецеденты в диаграммы пакетов из главы 18, “Формирование системных требо-
ваний“, дают полное представление о том, какие функции должна выполнять система.
Каждый из этих прецедентов необходимо проанализировать и понять. Таким образом,
группа разработчиков постепенно продвинулась от понимания предметной области к
пониманию системы. Этот результат обеспечили прецеденты.
Если проект разработки системы развивается на основе прецедентов, то будет дос-
тигнуто глубокое понимание всего процесса.
Заметим, что во время семинара команда разработчиков не обсуждала виды дея-
тельности. Были перечислены лишь все возможные прецеденты. Только после того
как прецеденты приобретут конкретный вид (что будет сделано в этой главе), компо-
ненты системы WIN начнут претворяться в жизнь.
Итак, займем место в команде разработчиков и начнем работать с прецедентами.
Изучение прецедентов
Для анализа прецедентов необходимо провести очередной семинар, цель которого
заключается в анализе каждого прецедента.
Предупреждение: семинар по анализу прецедентов обычно является самым слож-
ным, поскольку его участники — потенциальные пользователи конечной системы —
вынуждены выполнять функции аналитиков. Каждый из них является экспертом в
своей предметной области, и разработчикам необходимо воспользоваться их опытом и
знаниями. Как правило, им никогда не приходилось рассказывать и анализировать, и
они не участвовали в проектировании системы, поэтому им будет сложно понять, ка-
кая именно помощь требуется от системы.
Чтобы как-то снять напряжение, лучше организовать семинар таким образом, что-
бы работать с отдельными группами в разное время, например провести один семинар
только с официантами. Тогда другие участники не будут сидеть, сложа руки, пока
официанты анализируют свои прецеденты. Сотрудники ресторана — эксперты в сово-
купной предметной области могут объяснить, как данная группа связана с остальны-
ми. Такое разделение пользователей может пригодиться при работе с пакетом Клиент.
Прецедентов много. В этой главе будут рассмотрены только первые девять преце-
дентов пакета Официант. Если читатель поймет, как проводится такой анализ, он
сможет проанализировать оставшиеся прецеденты этого и других пакетов. (Это будет
предложено сделать в качестве упражнения в конце главы.)
Анализ прецедентов
Вспомним (глава 7, “Использование диаграмм прецедентов44), что каждый преце-
дент — это набор сценариев, и каждый сценарий является последовательностью ша-
гов. Для отдельно взятого сценария каждого прецедента необходимо выделить сле-
дующие аспекты.
Краткое описание сценария.
Предположения для сценария.
Действующее лицо, инициирующее прецедент.
Предусловия прецедента.
Шаги сценария, связанные с системой.
Постусловия выполнения сценария.
Действующее лицо, использующее результаты сценария.
(Сценарий может содержать любые взаимоисключающие условия или альтерна-
тивные потоки. Однако в данном примере сценарии должны быть несложными.)
Нет никакого “корректного” способа проведения анализа прецедентов. Перечислен-
ные элементы, как правило, обеспечивают построение полной картины прецедентов.
В проектном документе (который будет роздан клиентам и программистам) анализ
каждого прецедента должен проводиться на отдельном листе. В этом документе мож-
но изобразить диаграмму прецедентов, дополненную действующими лицами.
Шаги сценария, связанные с системой, имеют очень большое значение. С их по-
мощью станет в общих чертах понятно, как будет работать система. Когда участники
семинара описывают эти шаги, они на самом деле описывают, как будет выглядеть
система. После этого семинара у нас появится ясное представление о компонентах
системы.
Предположения также имеют большое значение. Как будет видно из дальнейшего,
свои соображения о проекте можно вносить в список предпосылок.
Это все подразумевается под выражением “проект разработки системы развивается
на основе прецедентов”. В конечном счете с помощью прецедентов будет разработано
поведение системы.
19-й час. Разработка прецедентов
283
Пакет Официант
Класс Официант содержит огромное количество видов деятельности, поскольку
официант взаимодействует со всеми остальными классами.
Прецеденты класса Официант следующие:
Прием заказа;
Передача заказа на кухню;
Изменение заказа;
Получение сообщения с кухни;
Контроль состояния заказа;
Уведомление шеф-повара о состоянии компании;
Подготовка счета;
Распечатка счета;
Вызов помощника;
Вызов уборщика;
Прием заказа на спиртное;
Передача заказа на спиртное в бар;
Получение уведомления;
Получение сообщения из бара.
Прецедент Прием заказа
Начнем с прецедента Прием заказа. Квалифицированный официант может пре-
доставить описание, предположения, предусловия, шаги и постусловия этого преце-
дента. В пакете и подпакете уже обозначено действующее лицо (официант) и лицо,
для которого выполняются действия (клиент).
Лаконичным описанием может быть такое: “Официант вводит заказ клиента в
карманный компьютер и передает заказ на кухню”. Предположения можно сформу-
лировать так: поскольку клиент голоден, он должен изучить меню и сделать выбор.
Другая предпосылка заключается в том, что в карманном компьютере официанта име-
ется пользовательский интерфейс, предназначенный для ввода заказа.
Имеем следующие предусловия: клиента следует усадить и дать ему меню. Посту-
словие таково: заказ введен в систему WIN.
Шагами прецедента являются следующие.
1. Официант активизирует пользовательский интерфейс карманного компьютера
для ввода заказа.
2. Активизируется интерфейс для ввода заказа.
3. Официант вводит выбранные клиентом блюда в систему WIN.
4. Система передает заказ на компьютер кухни.
Хотя предполагается существование интерфейса для ввода заказа, мы до сих пор не
определились, как будет выглядеть этот интерфейс или как на деле будет происходить
ввод заказа. Неизвестны также интерфейс кухонного компьютера и технические дета-
ли передачи заказа.
Когда будут точно определены все предпосылки проекта, можно прорабатывать
предполагаемые виды деятельности системы, а также выявлять способы их реализа-
ции. Важно помнить, что прецеденты предназначены для того, чтобы показать, как
выглядит система с точки зрения пользователя.
284
Часть II. Конкретный пример
Прецедент Передача заказа на кухню
Этот прецедент связан по крайней мере с двумя другими — предыдущим и Изме-
нение заказа.
Вот его описание: “Заказ вводится в карманный компьютер и передается на ком-
пьютер кухни”. Имеем следующие предпосылки: существуют способы для сообщения
о заказе (посредством беспроводной сети), опять же, интерфейс для ввода заказа.
Нужно ли повторять последнюю предпосылку? Да, нужно. В конце каждый прецедент
будет описан на отдельном листе проектного документа, который будет служить в ка-
честве справочника системы. Для полной ясности необходимо записывать все предпо-
сылки для каждого прецедента, даже если какие-то из них придется не раз повторять.
Предусловием является ввод заказа в карманный компьютер. Постусловием — по-
лучение заказа на кухне. Лицом, для которого выполняются эти действия, является
клиент.
Имеем следующие шаги.
1. Официант нажимает кнопку передачи заказа на кухню.
2. Система WIN передает заказ через беспроводную локальную сеть.
3. Заказ поступает на кухню.
4. В пользовательском интерфейсе карманного компьютера появляется сообще-
ние о том, что кухня приняла заказ.
Очевидно, для пакета клиента придется изменить диаграмму прецедентов. На ней
должна быть изображена зависимость «включает» между этим прецедентом и пре-
цедентом Прием заказа, а также между этим прецедентом и прецедентом Изменение
заказа. На рис. 19.1 изображена диаграмма прецедентов пакета Официант.
Официант
одготовка
счета >
Передача заказа
:а
спиртное в ба;
Получение
ведомления
Прием
заказа^
включает»
Контроль
состояния
_ заказа _
Уведомление
шеф-повара о
состоянии
компании
Передача
заказа
на кухнк
дрием заказа
на спиртное.
Получение
сообщения
с кухни
ХГ«включает»
зменение
заказа
аспечатка
счета
Вызов
помощника
Вызов
уборщика
Получение
сообщения
„из бара,
Рис. 19.1. Обновленная диаграмма прецедентов пакета Официант
Прецедент Изменение заказа
Теперь рассмотрим прецедент Изменение заказа. Его описание следующее:
“Внести поправки в заказ, уже введенный в систему WIN”. Вот предположение для
этого прецедента: заказ сделан и отправлен на кухню, но клиент захотел внести изме-
нения. Допускается также следующее: в системе WIN существует база данных заказов,
с помощью которой можно узнать, какой именно официант вводил тот или иной за-
каз и для какого столика предназначен этот заказ. Официант имеет доступ к этой базе
данных. При помощи системы WIN можно осуществлять передачу данных с карман-
ного компьютера на кухню и обратно, а в карманном компьютере имеется пользова-
тельский интерфейс для изменения заказа.
19-й час. Разработка прецедентов
285
Предусловием является предварительно размещенный заказ. Постусловием — пе-
редача модифицированного заказа на кухню. Лицом, для которого выполняются эти
действия, является клиент.
Шаги этого прецедента следующие.
1. Официант активизирует пользовательский интерфейс для изменения заказа.
2. В окне появляется список заказов, переданных на кухню этим официантом.
3. Официант выбирает заказ, который необходимо изменить.
4. Официант вносит изменения в заказ.
5. Система передает заказ на компьютер кухни.
(Пятый пункт включает предыдущий прецедент Передача заказа на кухню.)
Прецедент Контроль состояния заказа
На семинарах, посвященных ресторану будущего, обсуждался вопрос о том, когда
заказ клиента надо забирать с кухни. В этом и состоит суть данного прецедента. Его
внедрение в систему не сразу приведет к облегчению работы официанта.
Вот его описание: “Контроль состояния (времени выполнения) заказа, уже вве-
денного в систему WIN.” Предпосылка состоит в том, что заказ уже сделан и отправ-
лен на кухню, а клиент хочет знать, как долго ему ожидать блюда. Повторяются также
два предыдущих предположения: наличие базы данных заказов и возможность обмена
сообщениями между кухней и карманным компьютером. Еще допускается существо-
вание окна пользовательского интерфейса на карманном компьютере для передачи
заказа и окна пользовательского интерфейса на кухонном компьютере для той же цели.
Предусловием является предварительно размещенный заказ. Постусловием — по-
лучение официантом информации о состоянии заказа. Лицом, для которого выпол-
няются эти действия, является клиент.
Имеем следующие шаги.
1. Официант активизирует окно пользовательского интерфейса карманного ком-
пьютера для отслеживания состояния заказа.
2. В окне появляется список заказов, переданных на кухню этим официантом.
3. Официант выбирает заказ для контроля его состояния.
4. Система передает запрос на кухонный компьютер.
5. Кухонный компьютер получает это сообщение.
6. Шеф-повар активизирует интерфейс кухонного компьютера.
7. Шеф-повар вводит время, необходимое для завершения выполнения заказа.
8. Система передает время, необходимое для завершения выполнения заказа, на
карманный компьютер официанта.
Прецедент Уведомление шеф-повара
о состоянии компании
Начиная с этого раздела будем использовать подразделы более низкого уровня, от-
ражающие отдельные аспекты анализа прецедентов. При этом для выделения переч-
ней по-прежнему будем использовать маркированные списки, а для перечисления ос-
новных действий — нумерованные.
286
Часть II. Конкретный пример
Описание
Официант по сети сообщает шеф-повару, что компания практически закончила с
закусками.
Предположения
Официант находится на площади обслуживания клиентов.
Официант может оценивать процесс приема пищи клиентом.
В системе есть окно пользовательского интерфейса для ввода информации о
состоянии клиента.
Система передает сообщения с карманного компьютера на кухонный и об-
ратно.
Предусловия
Клиент доедает закуски.
Постусловия
Шеф-повар приступает к завершению приготовления основного блюда.
Основные действия
1. Официант активизирует окно пользователя для определения состояния клиента.
2. В окне появляется список столиков, расположенных на площади обслужива-
ния официанта.
3. Официант выбирает интересующий его столик.
4. Официант отправляет сообщение “закуски практически съедены” для данного
столика на кухонный компьютер.
5. Кухонный компьютер получает это сообщение.
6. Официант получает уведомление о получении сообщения с кухонного компь-
ютера.
В последнем пункте использован прецедент Получение уведомления, который
содержится в пакете Официант. На рис. 19.2 изображена диаграмма прецедента Уве-
домление шеф-повара о состоянии компании. (По традиции на этой диаграмме
показаны исполнители. Многие специалисты по моделированию в настоящее время
не утруждают себя изображением исполнителей.)
Клиент
Рис. 19.2. Диаграмма прецедента Уведомле-
ние шеф-повара о состоянии компании
19-й час. Разработка прецедентов
287
Лицо, для которого выполняются действия
Клиент.
Прецедент Подготовка счета
Это очень важный прецедент. Без него ресторан не получит прибыль.
Описание
Вычисление общей стоимости заказа.
Предположения
Существует база данных заказов, связанная с карманным компьютером
официанта.
Каждому пункту заказа соответствует его стоимость.
Предусловия
Компания закончила обед.
Постусловия
Сформирован итоговый счет.
Основные действия
1. Официант открывает список заказов на карманном компьютере.
2. Официант выбирает соответствующий заказ.
3. Официант нажимает клавишу на карманном компьютере для вычисления об-
щей стоимости заказа.
4. Система вычисляет общую стоимость заказа.
Лицо, для которого выполняются действия
Клиент.
Прецедент Распечатка счета
Этот прецедент может показаться тривиальным, но он является важной деталью
взаимодействия.
Описание
Распечатка общего счета.
Предположения
Наличие сетевого принтера на площади обслуживания.
Предусловия
Общий счет.
288
Часть II. Конкретный пример
Постусловия
Распечатанный счет.
Основные действия
1. Официант нажимает клавишу на карманном компьютере для распечатки счета.
2. Сетевой принтер на площади обслуживания распечатывает счет.
3. Официант нажимает клавишу на карманном компьютере для удаления этого
заказа из списка действующих.
Лицо, для которого выполняются действия
Клиент.
Прецедент Вызов уборщика
Это очень важный прецедент, поскольку уборщик приводит в порядок стол после
очередного клиента.
Описание
Уборщику дается задание на подготовку стола для следующего клиента.
Предположения
Система обеспечивает беспроводную связь между служащими.
В системе имеется окно пользовательского интерфейса для передачи сооб-
щения уборщику.
Предусловия
Освободившийся столик, который должен быть убран и вновь сервирован.
Постусловия
Уборщик должен подойти к столику для уборки и сервировки.
Основные действия
1. Официант активизирует интерфейс для отправки сообщения уборщику.
2. Официант получает уведомление от уборщика.
Как и в случае с прецедентом Уведомление шеф-повара о состоянии компа-
нии, в последнем пункте использован прецедент Получение уведомления.
Лицо, для которого выполняются действия
Уборщик.
Анализируя прецеденты пакета Помощник, легко прийти к выводу, что класс По-
мощник можно разбить на два класса: ПомощникОфицианта и ПомощникШефПовара.
Это хорошая идея, поскольку тогда все станет яснее. Могут ли эти два класса быть
потомками абстрактного класса Помощник? Вполне, но не стоит добавлять на диа-
грамму еще один абстрактный класс.
Создание двух новых классов потребует пересмотра результатов анализа предмет-
ной области. Придется усовершенствовать диаграмму классов (рис. 19.3).
19-й час. Разработка прецедентов
289
Рис. 19.3. Усовершенствованная диаграмма классов
Необходимо также модифицировать диаграмму пакетов, включив пакеты Помощни-
кОфицианта и ПомощникШефПовара.
Это пример того, как различные этапы процесса GRAPPLE дополняют друг друга.
Знания, полученные в результате анализа прецедентов, дают возможность расширить
результаты анализа предметной области.
Остальные прецеденты
Остальные прецеденты пакета Официант анализируются примерно так же, как и
рассмотренные выше. Проделайте это в качестве упражнения. (См. упражнение 2 в
разделе практических занятий.)
Компоненты системы
Важный аспект анализа прецедентов заключается в определении компонентов сис-
темы. Отметим компоненты, которые были выявлены во время анализа прецедентов
пакета Официант, Они содержатся в разделе “Предположения” анализа каждого пре-
цедента. (Дополнительные компоненты определятся во время выполнения упражне-
ний.)
Что касается программного обеспечения, то, очевидно, потребуется несколько
окон пользовательского интерфейса. Системе WIN нужны пользовательские интер-
фейсы карманного компьютера для ввода заказа, изменения заказа, контроля состоя-
ния заказа, состояния клиента и отправки сообщений помощнику и уборщику. Для
организации всех этих интерфейсных окон понадобится нечто вроде интерфейса
“начальной страницы”. Системе WIN также необходим пользовательский интерфейс
для кухонного компьютера, чтобы шеф-повар мог отслеживать заказ. В целом пользо-
вательский интерфейс должен отображать начальную страницу, принимать сообщения
от пользователя и выдавать сообщения. Если ресторан действительно хочет угодить
своим клиентам, система должна отслеживать состояние заказа и клиента. Следова-
тельно, каждый пользователь системы WIN должен иметь возможность ответить на
вопросы клиента и отследить его состояние.
290
Часть II. Конкретный пример
Судя по всему, необходима еще и база данных для записи всех заказов. Каждая за-
пись будет содержать номер столика, пункты заказа, время внесения заказа, имя офи-
цианта, статус заказа (действителен или нет) и т.п.
Конечно, понадобится подсистема обработки заказов, позволяющая передать заказ
по назначению и зарегистрировать его в базе данных.
На рис. 19.4 показана диаграмма классов, моделирующая описанный выше интер-
фейс, базу данных и обработчик заказов. На диаграмме показаны некоторые опера-
ции. Они пригодятся при изучении материала следующей главы, посвященной моде-
лированию взаимодействия между компонентами.
Что касается аппаратных средств, то необходима беспроводная сеть, карманные
компьютеры для служащих (официантов, помощников официантов и уборщиков), на-
стольный компьютер на кухне и еще один в баре. На каждой площади обслуживания
должен находиться сетевой принтер. Также, возможно, понадобится компьютер и
принтер для служащего гардероба.
Обработчик заказов и база данных должны располагаться на компьютере. Их мож-
но разместить на центральной машине, к которой имеют доступ остальные компьюте-
ры сети. В беспроводной сети карманные компьютеры будут связываться с централь-
ной машиной на основе беспроводного соединения.
Довольно сложная проектная документация начинает обретать форму. В следую-
щей главе анализ прецедентов будет продолжен.
Рис. 19.4. Моделирование компонентов системы WIN
Резюме
Просто составить список прецедентов недостаточно. Для более четкого понимания
системы команда разработчиков должна надлежащим образом понять все детали каж-
дого из них. В этой главе пройден сложный лабиринт анализа прецедентов.
Анализ прецедентов включает в себя описание прецедента, определение предусло-
вий и постусловий, а также основных действий. Важный аспект анализа прецедентов
заключается в выявлении компонентов системы.
19-й час. Разработка прецедентов
291
Вопросы и ответы
При описании процесса GRAPPLE была пропущена операция определения взаимодей-
ствующих систем. Почему?
Как мы помним, команда разработчиков начинала работу с чистого листа бумаги.
Никаких систем тогда еще не существовало. Однако в следующей системе, разрабаты-
ваемой для сети ресторанов LNG, в качестве такой системы может выступить WIN.
В этой главе мы модифицировали диаграммы прецедентов и диаграмму классов. Все-
гда ли это делается?
Конечно, стоит внести изменения при получении дополнительной информации.
Первичный список прецедентов охватывает все знания, полученные к этому этапу, и
является “мгновенным снимком” этого этапа. В модифицированных диаграммах от-
ражены самые последние идеи команды разработчиков.
Практические занятия
Практические задания этой главы дадут возможность проверить знания в области
конкретизации прецедентов. Ответы находятся в приложении А.
Тесты
1. Из каких частей состоит типичная диаграмма прецедентов?
2. Что означает для прецедентов отношение <<включает>>?
Упражнения
1. Постройте диаграмму прецедента Вызов помощника.
2. Проанализируйте оставшиеся прецеденты пакета официант и постройте диа-
граммы прецедентов.
3. Проанализируйте прецеденты пакета ШефПовар и постройте соответствующие
диаграммы прецедентов.
4. То же самое сделайте для пакетов Бармен, Помощник и Уборщик.
5. Проанализируйте рис. 19.4. Какие дополнительные классы интерфейсов необ-
ходимо включить в эту модель? Какими должны быть их операции?
292
Часть II. Конкретный пример
20-й час
Взаимодействие элементов системы
и изменение их состояния
Из этого часа вы узнаете
> Как выделить составные части системы
> Как проанализировать взаимодействие между элементами системы
> Зачем модифицировать прецеденты
Анализ прецедентов в предыдущей главе позволил продвинуться далеко вперед в
деле воплощения системы в жизнь. Однако одного анализа недостаточно для написа-
ния программы.
Целью этого анализа является формирование представления об элементах системы.
Теперь необходимо создать модель взаимодействия рабочих элементов системы, а
также определить, как (и когда) изменяется их состояние. При наличии такой инфор-
мации работа программистов существенно упростится, поскольку они смогут понять,
как именно запрограммировать классы и обеспечить их совместную работу.
Элементы системы
Сначала перечислим компоненты системы, определенные в процессе анализа каж-
дого пакета прецедентов. Несмотря на то что в предыдущей главе тщательно анализи-
ровались не все прецеденты пакета, можно выделить системные компоненты, соответ-
ствующие этим прецедентам. Естественно, в реальной работе команда разработчиков
должна проанализировать все прецеденты.
Пакет Официант
В конце предыдущей главы на основании анализа первых девяти прецедентов па-
кета Официант были выделены следующие элементы программного обеспечения сис-
темы: для карманных компьютеров системы WIN необходимы окна пользовательского
интерфейса для ввода заказа, изменения заказа, контроля состояния заказа, состояния
клиента и отправки сообщений. Также необходимо создать главное окно пользова-
тельского интерфейса. Из результатов анализа ясно, что для кухонного компьютера
тоже необходимо окно пользовательского интерфейса, чтобы отслеживать состояние
заказа. А для системы WIN необходима база данных для хранения заказов.
Анализ еще не рассмотренных прецедентов поможет выявить системные компо-
ненты. Напомним эти прецеденты:
Вызов уборщика;
Прием заказа на спиртное;
Передача заказа на спиртное в бар;
Получение уведомления;
Получение сообщения из бара;
Получение сообщения из кухни.
Эти прецеденты определяют необходимые компоненты системы. Из первого пре-
цедента ясно, что в пользовательском интерфейсе официанта должна быть предусмот-
рена возможность вызвать уборщика. Из второго понятно, что требуется окно для
приема заказа на спиртное (аналогичное окну приема заказа на блюда). В пользова-
тельском интерфейсе должна быть возможность получать уведомление (о том, что
уборщик получил задание) и сообщение из бара о том, что спиртной напиток приго-
товлен.
Исходя из специфики работы официанта можно заключить, что основными ком-
понентами этого пакета являются окна пользовательского интерфейса для приема за-
каза, а также отправки и приема сообщений.
Пакет Шеф-повар
Прецеденты для пакета Шеф-повар:
Хранение рецепта;
Извлечение рецепта;
Информирование официанта;
Получение заявки;
Подтверждение заявки;
Ввод времени приготовления;
Распределение заказа.
Какие компоненты определяются этими прецедентами? Это несложно выяснить,
проанализировав их выполнение.
Пакет Уборщик
Прецеденты для этого пакета такие:
Получение задания от официанта;
294
Часть II. Конкретный пример
Подтверждение задания;
Сигнал об окончании сервировки.
Пакет ПомощникОфицианта
В предыдущей главе было решено разбить пакет Помощник на два пакета: Помощ-
никОфицианта и ПомощникШефПовара. Прецедентами пакета ПомощникОфицианта бу-
дут следующие:
Получение задания от официанта;
Подтверждение задания;
Сигнал о выполнении задания.
Пакет ПомощникШефПовара
Прецеденты для пакета ПомощникШефПовара следующие:
Получение задания от шеф-повара;
Подтверждение задания;
Сигнал о выполнении задания.
Очевидно, что помощнику шеф-повара не требуется отдельный компьютер, по-
скольку он находится на кухне в непосредственной близости от шеф-повара. Однако
если кухня имеет очень большие размеры, то обзавестись электронной связью было
бы неплохо.
Пакет Бармен
Прецеденты пакета Бармен следующие:
Ввод состава напитка;
Извлечение состава напитка;
Получение сообщения от официанта;
Получение заявки от официанта;
Подтверждение заявки;
Сигнал о выполнении заявки.
Эти прецеденты аналогичны прецедентам пакета Шеф-повар, соответственно, ана-
логичны и компоненты программного обеспечения. Аппаратные средства тоже схожи:
в баре имеет смысл установить настольный компьютер, а не использовать карманный.
Бармену необходима база данных состава спиртных напитков и окно пользователь-
ского интерфейса — д ля обеспечения доступа к этой базе данных и извлечения рецеп-
тов. Пользовательский интерфейс бармена должен отображать сообщения от офици-
анта (что столик для клиента подготовлен) и заявки от официанта на спиртное. Бар-
мен должен иметь возможность отправить подтверждение о получении заявки и
информировать официанта о том, что напиток приготовлен.
Пакет Гардеробщик
Прецеденты пакета Гардеробщик следующие:
Выдача номерка для верхней одежды;
Выдача номерка для головного убора.
20-й час. Взаимодействие элементов системы и изменение их состояния 295
Программное обеспечение карманного компьютера гардеробщика должно вклю-
чать в себя окно пользовательского интерфейса для вывода соответственного номерка.
На номерке должно приводиться время и описание предмета одежды. Возможно, гар-
деробщику также понадобится база данных вещей, сданных на хранение.
Взаимодействия в системе
Задача этой стадии проекта заключается в том, чтобы определить, как системные
компоненты должны взаимодействовать при выполнении шагов каждого прецедента.
Смоделируем взаимодействия двух прецедентов пакета Официант. Дело в том, что на-
бор прецедентов этого пакета слишком велик, поэтому проанализировать взаимодей-
ствие всех прецедентов в книге не представляется возможным. Но в реальном проекте
команда разработчиков должна это сделать.
Прием заказа
Начнем с прецедента Прием заказа. Как было сказано в главе 19, “Разработка
прецедентов”, он включает следующие действия.
1. Официант активизирует пользовательский интерфейс карманного компьютера
для ввода заказа.
2. Активизируется интерфейс для ввода заказа.
3. Официант вводит выбранные клиентом блюда в систему WIN.
4. Система передает заказ на компьютер кухни.
В модели, разработанной в предыдущей главе, этот прецедент включает в себя
прецедент Передача заказа на кухню, предполагающий выполнение следующих
действий.
1. Официант нажимает кнопку передачи заказа на кухню.
2. Система WIN передает заказ через беспроводную локальную сеть.
3. Заказ поступает на кухню.
4. В пользовательском интерфейсе карманного компьютера появляется сообще-
ние о том, что кухня приняла заказ.
Взаимодействие этих прецедентов удобно изобразить на диаграмме последователь-
ностей. (А также на диаграмме кооперации, которую нужно будет построить в упраж-
нении 1.) Чтобы изобразить диаграмму, следует остановиться на нескольких аспектах.
Первый: когда официант принимает заказ клиента, он, в сущности, создает заказ!
Этот заказ является объектом системы WIN. (Он также является экземпляром класса
Заказ, судя по результатам анализа предметной области в главе 17.) Шеф-повар будет
использовать этот факт в качестве директивы для активизации и выполнения набора
операций. Официант сможет подсчитать полную стоимость этого заказа. Клиент оп-
латит этот счет. Таким образом, созданный заказ является важным элементом.
Прецеденты Изменение заказа и Контроль состояния заказа тоже ссылаются
на список заказов. Этот список содержится в базе данных заказов, о которой шла речь
в конце главы 19. Каким образом заказ попадает в базу данных? Это должно происхо-
дить в ходе данного прецедента.
Можно рассуждать и по-другому. Во включенном прецеденте термин “кухня” не-
сколько неясен. Поскольку речь идет о модели компонентов программного обеспече-
ния, то необходимо определиться с этим термином. Попытка представить, как могут
выполняться шаги прецедента, приводит к заключению, что заказ как-то должен поя-
296
Часть II. Конкретный пример
виться в пользовательском интерфейсе шеф-повара на кухонном компьютере. Как
именно это произойдет, пока не важно.
В результате этих размышлений прецедент Прием заказа можно описать так.
1. Официант активизирует пользовательский интерфейс карманного компьютера
для ввода заказа.
2. Активизируется интерфейс для ввода заказа.
3. Официант вводит заказ клиента в систему WIN.
4. Обработчик заказов создает заказ.
5. Обработчик заказов передает заказ в пользовательский интерфейс кухонного
компьютера.
6. Обработчик заказов добавляет заказ в базу данных.
7. Обработчик заказов уведомляет официанта об отправке заказа на кухню и до-
бавлении его в базу данных.
Чтобы создать диаграмму последовательностей для этого прецедента, необходимо
воспользоваться диаграммой классов, представленной в главе 19. Операции классов
этой модели становятся сообщениями на диаграмме последовательностей.
На рис. 20.1 изображена диаграмма последовательностей, в которой учтено новое
представление об этом прецеденте. Напомним, что объекты, находящиеся в верхней
части этой диаграммы, описывают компоненты прецедента. Пунктирная линия, иду-
щая вниз от каждого объекта, является линией жизни объекта. Ось времени направ-
лена сверху вниз. Маленькие прямоугольники на линиях жизни называются точками
активации. Каждая точка активации описывает период времени, в течение которого
объект выполняет операцию. Линии со стрелками, соединяющие линии жизни двух
объектов, представляют собой сообщения, передаваемые между этими объектами. Тип
стрелки определяет тип сообщения. Объект Заказ создается в ходе прецедента, по-
этому он расположен ниже остальных объектов. По этой причине сообщение, направ-
ленное этому объекту, содержит стереотип «создает>>.
Рис. 20.1. Диаграмма последовательностей для прецедента Прием заказа
Изменение заказа
Рассмотрим другой прецедент. В предыдущей главе приводилась следующая после-
довательность шагов прецедента Изменение заказа.
20-й час. Взаимодействие элементов системы и изменение их состояния
297
1. Официант активизирует пользовательский интерфейс для изменения заказа.
2. В окне появляется список заказов, переданных на кухню этим официантом.
3. Официант выбирает заказ, который необходимо изменить.
4. Официант вносит изменения в заказ.
5. Система передает заказ на компьютер кухни.
Построение диаграммы поможет в осмыслении и некоторой модификации преце-
дента. После п. 4 необходимо изменить объект заказа. А после п. 5 система должна
внести измененный заказ в базу данных заказов.
Таким образом, новый прецедент будет выглядеть так.
1. Официант активизирует пользовательский интерфейс карманного компьютера
для изменения заказа.
2. В окне появляется список заказов, переданных на кухню этим официантом.
3. Официант выбирает заказ, который необходимо изменить.
4. Официант вносит изменения в заказ.
5. Обработчик заказов передает модифицированный заказ на кухонный компьютер.
6. Обработчик заказов вносит новый заказ в базу данных заказов.
На рис. 20.2 изображена диаграмма последовательностей, соответствующая этому
прецеденту.
Контроль состояния заказа
Рассмотрим еще один прецедент Контроль состояния заказа. Он состоит из та-
кой последовательности шагов.
1. Официант активизирует окно пользовательского интерфейса карманного ком-
пьютера для отслеживания состояния заказа.
2. В окне появляется список заказов, переданных на кухню этим официантом.
3. Официант выбирает заказ для контроля его состояния.
4. Система передает запрос на кухонный компьютер.
5. Кухонный компьютер получает это сообщение.
6. Шеф-повар активизирует интерфейс кухонного компьютера.
7. Шеф-повар вводит время, необходимое для завершения выполнения заказа.
8. Система передает время, необходимое для выполнения заказа, на карманный
компьютер официанта.
Операцию, указанную в п. 5, можно определить иначе: “Сообщение попадает в
пользовательский интерфейс шеф-повара на компьютере кухни”. При этом исчезает
необходимость выполнения шага 6. Кроме того, термин “система”, используемый в
исходном прецеденте, следует заменить на термин “обработчик заказов”.
Возможно, для выяснения способов определения необходимого времени потребу-
ется провести еще одно или два интервью с шеф-поваром. Возможно придется разра-
ботать программное обеспечение, позволяющее автоматизировать выполнение этой
задачи.
На рис. 20.3 изображены все детали этого прецедента.
298
Часть II. Конкретный пример
:Официант
:СШОфицианта
:ОбработчикЗаказов
:С1ЛШефПовара :БДЗаказов
вывестиФормуВводаЗаказа()
«беспроводная»
найти(моиЗаказы)
принятьСообщениеОт
Пользователя(изменениеЗаказа)
получитьЗаказ(моиЗаказы)
Найдены
«беспроводная»
вывестиСообщение(моиЗаказы)J
«беспроводная» J
обработатьДанныеОт
Официанта(изменениеЗаказа)
обновить(Заказ)
Обновлен
।
вывестиЗаказ(изменениеЗаказа)
«беспроводная»
вывестиСообщение(Заказ обновлен")
I
I
Рис. 20.2. Диаграмма последовательностей для прецедента Контроль состояния заказа
: Официант : СШОфицианта
:ОбработчикЗаказов
:БДЗаказов :СЦ1ШефПовара :ШефПовар
вывестиФорму
КонтооляЗаказа()
принятьСообщение
ОтПользователя
(контрольЗаказа)
«беспроводная»_______
получитьЗаказ(моиЗаказы)
«беспроводная»
I I
• найти(моиЗаказы) ।
. .Найдены
вывестиСообщение (моиЗаказы^)
«беспроводная» !
обработатьДанныеОт
Официанта(контрольЗаказа)
вывестиФормуКонтроля
Заказа(контрольЗаказа)
принятьСообщениеОтШеф
Повара(контрольЗаказа,время)
обработатьДанныебтШеф
Повара(контрольЗаказа,время)
«беспроводная»
вывестиСообщение(контрольЗаказа,время)
Рис. 20.3. Диаграмма последовательностей для прецедента Контроль состояния заказа
Итоги
Просматривая результаты работы, заказчики из компаний LaHudra, Nar и Goniff
крайне удивились.
— Слушайте, ведь так можно полностью изменить сущность ресторанного бизне-
са, — заявляет представитель Nar.
— Согласен, мы что-то нащупали”,— говорит представитель LaHudra. — Но что вы
имеете в виду под “полным изменением сущности ресторанного бизнеса”?
— Давайте подумаем вместе, — продолжает представитель Nar. — Изменится вся
работа официанта, а также работа шеф-повара. Официантам не придется так много
бегать, как они это делают сейчас. Для клиентов они будут выполнять роль источни-
ков информации, поскольку всегда будут находиться на своей площади обслуживания.
В бар или на кухню им придется ходить только в исключительных ситуациях. С по-
мощью своих карманных компьютеров они смогут наблюдать непосредственно за
процессом выполнения заказа и контролировать свои площади. Они станут уже не
20-й час. Взаимодействие элементов системы и изменение их состояния
299
просто официантами. В сущности, они даже смогут отдохнуть в процессе работы, по-
скольку в понятие “работа” теперь не будет входить беготня туда-сюда для выяснения
текущих вопросов.
— А шеф-повар?
— Его работа также приобретет административный характер. Он будет использо-
вать свой компьютер для распределения заказов между помощниками и координиро-
вать общую деятельность кухни. Это очень удобно для больших кухонь и крупных
ресторанов. Ведь теперь будет перемещаться информация, а не люди.
— Это производит впечатление, — говорит представитель LaHudra. — Вне всяких
сомнений, это позволит сократить количество обслуживающего персонала. Неплохо.
— Совсем неплохо, — подтверждает представитель Goniff, рисуя следующую диа-
грамму.
Резюме
После анализа прецедентов команда разработчиков уделяет пристальное внимание
системным компонентам, выявленным на основе анализа этих прецедентов. Что они
собой представляют? Как взаимодействуют? В этой главе было описано, как в контек-
сте разработки системы WIN находить ответы на эти вопросы.
Целью последнего этапа работы является обеспечение программистов информаци-
ей, которая существенно упростит их работу. Результаты такого анализа должны об-
легчить программную реализацию системных объектов и их взаимосвязей.
После создания модели взаимодействия компонентов общий вид системы сущест-
венно приблизится к реальности. По мере моделирования взаимодействий может по-
требоваться модификация прецедентов.
Вопросы и ответы
В процессе выявления взаимодействий были модифицированы некоторые прецеденты.
Делается ли это в реальных проектах?
Как правило, да. Описанные примеры могут показаться несколько надуманными.
Например, в реальной работе, возможно, придется определиться с базой данных уже в
процессе анализа первого прецедента. Это сделано, чтобы показать эволюцию позна-
ний в данной области и усовершенствовать модель в процессе работы.
Почему исходные прецеденты не охватывают все нюансы?
Дело в том, что они строятся по результатам семинара с участием пользователей
системы, а не ее разработчиков. Можно заметить, что все добавления и изменения
связаны с системой, а не с бизнес-процессами. Поэтому неудивительно, что эти мо-
дификации делаются после завершения встреч с потенциальными пользователями и в
результате анализа прецедентов.
На приведенных диаграммах последовательностей используются линии с разными
стрелками. Для чего это нужно?
С помощью закрашенной стрелки представляется вызов одного объекта другим
объектом. При этом отправитель сообщения ожидает, пока получатель не выполнит
требуемые действия. Второй тип стрелок также используется для представления пере-
дачи сообщений. Однако в этом случае отправитель сообщения передает управление
объекту-получателю и не ожидает, пока им будут выполнены требуемые операции.
На диаграммах последовательностей иногда используются большие прямоугольники
активации, а иногда —* нет. Чем это объясняется?
Эти прямоугольники представляют выполнение объектом одной из своих опера-
ций. Зачастую эти операции выполняются в ответ на сообщение, переданное другим
300
Часть II. Конкретный пример
объектом. Длина прямоугольника соответствует периоду времени, отводимому на вы-
полнение операции. Самые большие прямоугольники относятся к пользовательскому
интерфейсу официанта. Официант отправляет пользовательскому интерфейсу запрос
на отображение конкретной информации. Величина прямоугольника отражает время,
в течение которого информация остается на экране.
Еще один вопрос о диаграммах последовательности. На первых двух диаграммах объ-
ект : БД Зака зов находится справа, а на третьей — в другом месте. Правильно ли это?
Да. Напомним, что расположение объектов в верхней части диаграммы ничего не
означает. На самом деле все диаграммы начинаются с сообщения, отправляемого са-
мым левым объектом — официантом. Однако даже это правило не является обяза-
тельным. Это хороший стиль моделирования, но не жестко регламентированный.
Практические занятия
Теперь можно заняться моделированием взаимодействий между системными ком-
понентами. Ответив на вопросы, “пообщайтесь” с приложением А. Кстати, перечис-
ленные в этой главе компоненты можно использовать для выполнения приведенных
ниже упражнений и построения дополнительных диаграмм последовательностей и
диаграмм коммуникации.
Тесты
1. Как на диаграмме последовательностей изображается объект, созданный в
процессе выполнения шагов прецедента?
2. Как на диаграмме последовательностей отражается время?
3. Что такое линия жизни?
4. Как на диаграмме последовательностей изобразить точку активации, и что она
описывает?
Упражнения
1. Разработайте диаграмму коммуникации, эквивалентную диаграмме последова-
тельности для прецедента Прием заказа пакета Официант.
2. Создайте диаграмму последовательностей для прецедента Прием заказа на
спиртное.
3. Выберите как минимум один прецедент пакета Шеф-повар и постройте диа-
грамму последовательностей. Используйте список компонентов, упомянутых в
этой главе. Необходимы ли дополнительные компоненты?
4. Прецеденты пакета Гардеробщик выглядят до смешного примитивно. Про-
явите свою фантазию. Можно ли “украсить” каждый прецедент, добавив к
нему один-два шага? Помогут ли в этом вопросе дополнительные компонен-
ты? Изобразите диаграмму последовательностей для одного такого прецедента.
5. Обратимся к трем диаграммам последовательностей. Есть ли в них повторе-
ния? Если — да, то используйте приемы UML 2.0, описанные в главе 9, для
повторного использования и включения информации из одной диаграммы в
другую.
20-й час. Взаимодействие элементов системы и изменение их состояния
301
21-й час
Проектирование интерфейса
пользователя и развертывание системы
Из этого часа вы узнаете
> Основные принципы проектирования графического интерфейса пользователя
> Как провести семинар, посвященный GUI
> Как перейти от описания прецедентов к интерфейсу пользователя
> Что такое диаграммы UML для проектирования GUI
> Как спланировать развертывание системы
До сих пор большое внимание уделялось анализу на основе прецедентов. В этой
главе будут рассмотрены два важных аспекта проектирования системы. Оба они име-
ют прямое отношение к прецедентам и чрезвычайно важны для конечного продукта.
Графический пользовательский интерфейс (GUI) определяет удобство использования
системы. При развертывании запланированная системная архитектура воплощается в
реальность.
Некоторые принципы
проектирования GUI
При разработке проекта пользовательского интерфейса учитывается мнение ху-
дожника, человеческий фактор и интуиция потенциального пользователя. Некоторые
основные принципы построения оконных интерфейсов проясняются после длитель-
ной работы с ними. Вот несколько самых важных принципов.
1. Необходимо понять, в чем состоит работа пользователя. Как правило, проек-
тировщики интерфейсов проводят анализ заданий для понимания сути работы
пользователя. Наш подход к характеристике прецедентов приблизительно со-
ответствует такому анализу заданий.
2. Нужно сделать так, чтобы клиент чувствовал, что он контролирует взаимодей-
ствие. Интерфейс пользователя должен обеспечивать возможность отмены
действий.
3. Желательно предоставить клиенту несколько вариантов завершения каждой
операции, связанной с интерфейсом (наподобие закрытия окна или файла), и
не обращать внимания на его ошибки.
4. Внимание пользователя привлекает верхний левый угол экрана. Поэтому са-
мую важную информацию необходимо размещать именно там.
5. Нужно учитывать пространственное расположение элементов. Связанные друг
с другом компоненты экрана следует размещать рядом, например в одной
рамке.
6. Необходимо обращать особое внимание на удобочитаемость и ясность элемен-
тов интерфейса (использовать понятные всем и простые слова!). Для передачи
идей и понятий используйте активный залог.
7. Надо ограничивать количество используемых цветов. Из всего многообразия
необходимо остановиться на нескольких. Чрезмерное множество цветов будет
отвлекать пользователя от выполняемых задач. Кстати, очень неплохо предос-
тавить клиенту возможность самому изменять цвета.
8. Тем, кто подумывает об использовании цвета для выделения содержания, не-
обходимо помнить, что пользователю не всегда легко ассоциировать цвет с со-
держанием. Также следует знать, что некоторые пользователи (около 10%
взрослых мужчин) плохо различают цвета, поэтому им будет сложно отличить
один цвет от другого.
9. Как и в случае с цветами, необходимо ограничивать число шрифтов. Жела-
тельно избегать курсивов и витиеватых шрифтов. Шрифт под названием
“Haettenschweiler” довольно приятен, но не стоит его использовать постоянно.
10. Старайтесь создавать компоненты (типа кнопок и списков) одинакового раз-
мера. При использовании компонентов различных размеров, разнообразии
цветов и шрифтов создается мешанина или даже мозаика, которую специали-
сты в области GUI называют дизайном в стиле “клоунских штанов”.
И. Выравнивайте компоненты и поля данных по левому краю. Это уменьшает
нагрузку на глаза при просмотре экрана.
12. Если пользователь после прочтения и обработки определенного блока инфор-
мации должен щелкать на кнопках, то лучше разместить их справа от блока
информации или же под этим блоком, и опять-таки справа. Это соответствует
естественной тенденции (присущей нашей культуре) читать слева направо.
Если имеется кнопка по умолчанию, то ее нужно выделить и сделать первой в
группе элементов управления.
Перечисленным не исчерпываются все принципы, но здесь учтены важные аспек-
ты в процессе проектирования GUI. Задача заключается в том, чтобы предоставлять со-
ответствующую информацию в простом, доступном, понятном наглядном контексте.
На рис. 21.1 отражены некоторые из этих принципов.
21-й час. Проектирование интерфейса пользователя и развертывание системы
303
Рис. 21.1. Результат применения
принципов проектирования GUI
На рис. 21.2 показано, что происходит, если не придерживаться необходимых правил.
При создании Web-страниц советуем познакомиться с известными решениями
Джейкоба Нильсена (Jakob Nielsen), которые можно найти по адресу www.useit.com.
Здесь вы получите дополнительную информацию о проектировании пользователь-
ского интерфейса
Рис. 21.2. Результат отхода от
принципов проектирования GUI
Сеанс JAD, посвященный GUI
Хотя это и не имеет прямого отношения к UML, но было бы неплохо обсудить
представление о GUI его потенциальных пользователей. Для этого необходимо снова
провести семинар.
На этот семинар нужно пригласить потенциальных пользователей системы. Для
разработки системы WIN обратимся к официантам, шеф-поварам, помощникам офи-
циантов, помощникам шеф-поваров, уборщикам и служащим гардероба. Команду
разработчиков будут представлять программисты, аналитики, разработчики модели и
руководитель семинара. Цель заключается в том, чтобы понять требования пользова-
телей и разработать на основе этих требований интерфейс, дающий системе возмож-
ность беспрепятственно интегрировать бизнес-процессы. Старый способ разработки
системы, который заключался в написании программы без всякой предварительной
подготовки, в формировании поведения пользователей и согласовании бизнес-
процессов с этим поведением, в настоящее время устарел.
304 Часть II. Конкретный пример
Для большей эффективности семинара необходимо разбить пользователей на
группы в соответствии с их обязанностями. Надо распланировать длительность каж-
дого семинара согласно количеству прецедентов в пакете для каждого исполнителя.
Естественно, эти рекомендации довольно приблизительны, поскольку степень слож-
ности прецедентов различна, и, соответственно, время на рассмотрение каждого из
них понадобится разное. Тем не менее необходимо помнить, что в процессе проекти-
рования GUI могут выявиться новые прецеденты.
Участие пользователей в сеансе состоит из двух этапов. На первом — разрабатыва-
ют окна пользовательского интерфейса. На втором — утверждают прототипы, создан-
ные командой разработчиков.
Как пользователи создают окна? Руководитель семинара предлагает для начала
рассмотреть прецедент, и пользователи обсуждают способы реализации этого преце-
дента в системе. Когда клиенты уже готовы определиться с видом окна, они рисуют
его макеты на бумаге. В пояснениях описываются компоненты GUI (например, кон-
текстное меню, кнопки, переключатели, списки). Задача пользователей заключается в
том, чтобы сообща разработать подходящую схему расположения компонентов.
Когда пользователи определятся в вопросе о том, какие компоненты должны при-
сутствовать на экране и где именно они должны быть расположены, члены команды
разработчиков создают прототипы окон. В своей работе они используют соответст-
вующие принципы проектирования GUI, описанные в предыдущем разделе. Затем
выводят эти окна на экран, и пользователи вносят все необходимые изменения.
Главный принцип такой работы заключается в том, чтобы дать пользователям (а не
разработчикам) максимальную возможность самим управлять процессом. Таким обра-
зом, в реальном деловом мире система будет работать оптимально.
От прецедентов к пользовательским
интерфейсам
Прецеденты описывают использование системы. Поэтому пользовательский ин-
терфейс должен служить средством реализации этих прецедентов.
Рассмотрим диаграмму последовательностей как один из ракурсов прецедента. Ес-
ли бы можно было “вращать” эту картину вокруг трех осей таким образом, чтобы
крайняя левая часть диаграммы последовательностей вышла за пределы экрана в сто-
рону пользователя, то можно было бы увидеть место пользовательского интерфейса в
этой диаграмме последовательности (рис. 21.3).
Давайте исследуем прецеденты пакета Официант и посмотрим, как их отобразить в
пользовательском интерфейсе системы WIN. Вот эти прецеденты:
Прием заказа;
Передача заказа на кухню;
Изменение заказа;
Контроль состояния заказа;
Уведомление шеф-повара о состоянии компании;
Подготовка счета;
Распечатка счета;
Вызов помощника;
Вызов уборщика;
Прием заказа на спиртное;
21-й час. Проектирование интерфейса пользователя и развертывание системы
305
Рис. 21.3. Место пользовательского интер-
фейса на диаграмме последовательностей
Передача заказа на спиртное в бар;
Получение уведомления;
Получение сообщения из бара;
Получение сообщения с кухни.
Интерфейс официанта должен соответствовать всем этим прецедентам.
Для начала работы над интерфейсом разобьем набор прецедентов на группы. Дос-
таточно трех групп. Первая имеет отношение к заказам (Прием заказа, Изменение
заказа, Контроль состояния заказа, Прием заказа на спиртное). Вторая группа
связана со счетами (Подготовка счета, Распечатка счета). Ну, а третья ориенти-
рована на передачу и прием сообщений (Уведомление шеф-повара о состоянии
компании, Вызов помощника, Вызов уборщика, Передача заказа на спиртное в
бар, Получение уведомления, Получение сообщения из бара).
Начнем с основного окна, которое официант открывает для реализации остальных
групп прецедентов. Хотелось бы иметь возможность перемещения от одной группы к
другой, от одного прецедента к другому в пределах одной группы. На рис. 21.4 изо-
бражен исходный вид главного окна. (Система предназначена для использования во
всемирной сети ресторанов, имена элементов интерфейса указаны на английском
языке.) Выводиться оно будет на экране карманного компьютера, поэтому хорошо бы
иметь возможность изменять его размеры.
Рис. 21.4. Исходный вид основного
окна для пакета Официант
306
Часть II. Конкретный пример
На семинаре может быть достигнута договоренность о том, что перемещения в
пределах группы будут осуществляться при помощи кнопок, расположенных с правой
стороны окна, а перемещение между группами — при помощи кнопок, расположен-
ных в нижней части окна. На рис. 21.5 изображен исходный вид окна интерфейса
официанта, которое предназначено для работы с заказами.
Рис. 21.5. Окно для прецедентов,
связанных с заказами
Такое окно предназначено для работы с заказами. В большом текстовом поле будет
помещено ресторанное меню. Блюда, выбранные клиентом, официант отмечает
флажками (работая над интерфейсом, нужно помнить, что речь идет о ресторане, и
соблюдать максимальную осторожность при использовании слова “меню”).
При щелчке на кнопке в нижней части окна появляется отдельная группа возмож-
ностей. Например, с помощью кнопки Messages (Сообщения) открывается окно, изо-
браженное на рис. 21.6. Кстати, пользовательский интерфейс не должен быть только
визуальным. Он может быть также снабжен звуковым сигналом для оповещения офи-
цианта о получении сообщения. Чтобы прочитать список сообщений, ему нужно бу-
дет щелкнуть на кнопке Read (Чтение).
Рис. 21.6. Окно для реализации
прецедентов, связанных с сообще-
ниями
Диаграммы UML-для проектирования GUI
В языке UML не существует определенных рекомендаций касательно диаграмм
для проектирования GUI. Однако в предыдущих главах некоторые возможности уже
упоминались. Вспомним главу 8, “Диаграммы состояний”, где приводился пример
изменений состояния в GUI. Хотя этот пример относился к механизму работы GUI,
легко понять, что при обсуждении пользовательских интерфейсов неплохо обратиться
к диаграммам состояний.
21-й час. Проектирование интерфейса пользователя и развертывание системы
307
Используем для описания работы пользовательского интерфейса диаграмму со-
стояний. На рис. 21.7 показано, как связаны друг с другом окна верхнего уровня ин-
терфейса официанта.
Рис. 21.7. Диаграмма состояний для окон верхнего
уровня интерфейса официанта
Поскольку каждое окно состоит из определенного количества компонентов, для
его моделирования хорошо подойдет диаграмма агрегации классов (диаграмма компо-
зитов). На рис. 21.8 изображена диаграмма композитов, соответствующая окну, пред-
ставленному на рис. 21.5.
Рис. 21.8. Диаграмма композитов, соответствующая окну из рис. 21.5
Планирование развертывания системы
После этапа анализа, в результате которого должна быть разработана основная
концепция системы WIN, системный инженер приступает к разработке общей физи-
ческой архитектуры. Он начинает с выяснения возможных топологий сетей и их бес-
проводных вариантов, а затем распределяет компоненты программного обеспечения
по узлам сети. Для того чтобы приступать к этапу проектирования, не нужно ожидать
завершения анализа. Его операции будут выполняться параллельно с операциями
других этапов процесса GRAPPLE, таких как проектирование GUI.
Для руководителя проекта самое главное — отслеживать выполнение операций
всех этапов.
308
Часть II. Конкретный пример
Сеть
Системный инженер стоит перед выбором типа локальной сети (различные архи-
тектуры сетей рассмотрены в главе 13, “Работа с диаграммами развертывания”). Цель
заключается в том, чтобы выбрать тип сети, которая больше всего подходит для орга-
низации беспроводного доступа к карманным компьютерам.
Для того чтобы понять некоторые решения, принимаемые системным инженером,
давайте разберемся в специфике беспроводных локальных сетей WLAN (Wireless Local
Area Network). Обычно радиопередатчик, называемый точкой доступа, размещается в
определенном месте сети и соединяется со стандартной локальной сетью. В точку дос-
тупа поступают сообщения от одних беспроводных устройств и передаются другим
беспроводным устройствам. В этой точке полученные сообщения преобразуются в
формат, понятный для обычной сети. Чем больше точек доступа, тем шире область
действия WLAN и больше количество пользователей, имеющих к ней доступ.
Системный инженер должен решить, какое количество точек доступа должно быть
в ресторане, каким беспроводным сетевым адаптером необходимо снабдить карман-
ные компьютеры, а также выбрать тип и конфигурацию обычной локальной сети.
Предположим, системный инженер остановился на сети Ethernet (см. главу 13).
Диаграмма развертывания
Рассмотрим основные узлы разрабатываемой системы. Официанты, помощники
официантов и уборщики обладают карманными компьютерами. Выбор карманных
компьютеров (под управлением операционной системы Windows СЕ) в данном случае
очень удачен.
Кухня, гардероб и бар оснащены настольными компьютерами. Каждый настоль-
ный компьютер соединен с принтером. Кроме того, на площади обслуживания каж-
дого официанта устанавливается настольный компьютер, оснащенный принтером, так
что официант сможет распечатать счет, не отходя далеко от своей площади.
Для того чтобы проиллюстрировать план развертывания, системный инженер пре-
доставляет диаграмму развертывания, которая изображена на рис. 21.9.
Следующие шаги
Итак, команда разработчиков вступила на путь разработки интерфейса пользовате-
ля. Что же делать дальше?
Для начала аналитики приводят в порядок модель. Они используют словарь моде-
ли и выявляют все неясности. Аналитики должны удостовериться в том, что все тер-
мины использованы соответствующим образом на диаграммах и проблемы с терми-
нами наподобие “меню” и “официант” не возникнут. (Напомним, что в английском
языке слово “официант” (server) и слово “меню” (menu) имеют несколько значений.)
Когда соответствующий анализ и проектирование завершатся, команда объединит все
результаты в проектном документе и передаст его копии клиенту и программистам.
Затем начинается работа для программистов, которые должны реализовать проект-
ное решение в программном коде. Сам процесс программирования в данной книге не
рассматривается. Программы будут протестированы, переписаны в соответствии с ре-
зультатами тестов, затем снова проведут тестирование — процесс будет длиться до тех
пор, пока программы не пройдут все тесты, основа для которых формируется в про-
цессе анализа прецедентов.
Специалисты по документации начнут создавать ее для системы, они же будут соз-
давать обучающий материал. Процесс создания документов должен проходить так же,
21-й час. Проектирование интерфейса пользователя и развертывание системы
309
как и разработка системы, — с тщательным планированием, анализом и тестировани-
ем. Он также должен начинаться на ранней стадии процесса разработки.
При проведении основательного анализа и проектирования, а также при создании
информативной и хорошо организованной документации проекта последующие этапы
развертывания должны пройти легко и гладко.
Главная идея заключается в том, чтобы уделить максимум внимания анализу и
проектированию и минимизировать возможные проблемы. В результате получится
система, которая будет полностью соответствовать требованиям клиента.
Принтер
Терминатор
«артефакт»
Пользовательский
интерфейс
шеф-повара
Кухонный ПК
Т-коннектор
Т-коннектор
Беспроводный
адаптер
Повторитель
Терминатор
Терминатор
Т-коннектор
Т-коннектор
«беспроводная»
Точка
доступа
Карманный ПК
«артефакт»
Пользовательский
интерфейс
уборщика
^беспроводная»
Карманный ПК
Беспроводный
адаптер
ПК управляющего
Принтер
Т-коннектор *
ПК гардеробщика
Принтер
«артефакт»
Пользовательский
интерфейс
официанта
Т-коннектор
ПК площади 1
обслуживания
Т-коннектор
Т-коннектор
Т-коннектор
Терминатор
Принтер
Центральный ПК
«артефакт»
Обработчик
заказов
Принтер
ПК бара
«артефакт»
База данных
заказов
Рис. 21.9. Диаграмма развертывания для системы WIN
...А сейчас, несколько слов от спонсора
Представители компаний LaHudra, Nar и Goniff невероятно заинтригованы ходом
разработки новой системы. Ведь команда разработчиков ничего не сообщает им по
ходу процесса, а представляет только планы, основанные на UML, где описано на-
правление развития проекта. Их радует даже стратегическое решение системного ин-
женера о том, какой тип мобильного устройства использовать.
Приложенные усилия настолько поразили их воображение, что они стали выиски-
вать новые способы применения технологии — даже вне ресторанного мира. Предста-
310
Часть II. Конкретный пример
вители названных компаний осознают, что движение информации играет большую
роль в большинстве бизнес-процессов. Внедрение технологии, ускоряющей это дви-
жение, обеспечит огромное преимущество перед конкурентами.
Обеспечение возможностей продавцов
Потенциальную возможность повторного использования идей беспроводной ло-
кальной сети предприниматели видят не только в мире ресторанов, но и в огромных
супермаркетах. Спроектировать такую систему несложно, поскольку вся информация
по моделированию сохранена.
Одним из возможных применений этой идеи могут стать гигантские магазины то-
варов для дома, основанные на самообслуживании. Продавцам, работающим в зале
такого магазина, будет очень удобно пользоваться карманным устройством, предос-
тавляющим доступ к информации о продукции через беспроводную локальную сеть.
Система наподобие вышеописанной поможет продавцу отвечать на вопросы о распо-
ложении продукции в магазине независимо от того, присутствует ли этот товар в ас-
сортименте, а также рекомендовать использовать тот или иной товар.
Такая система будет очень полезна и продавцам, и покупателям. Ведь покупатели
могут быть уверены в том, что они получат от продавцов последнюю и самую точную
информацию. А новый продавец обучится работе с системой и, имея минимальную
подготовку, сможет гораздо быстрее работать.
Поэтому компании LaHudra, Nar и Goniff вскоре появятся в мире торговли.
Без комментариев
Несмотря на то что компании LaHudra, Nar и Goniff являются новаторами, они уже не одино-
ки в своих мыслях о мобильных устройствах и беспроводных локальных сетях.
Как было сказано выше, планшетные компьютеры действительно вторгаются в мир рестора-
нов. В одном ресторане беспроводный планшетный компьютер используется в качестве
цифровой карты вин, в которой собрана информация об этих винах. Вместо того чтобы вы-
нуждать посетителей выслушивать сомнительное описание вина как “чего-то страстного с
живым букетом”, посетитель сможет положиться на планшетный компьютер и беспроволоч-
ную локальную сеть.
В ресторанах и кофейнях часто организуют точки доступа к беспроводным сетям. Приносите
свой переносной компьютер, подключайтесь к Internet и читайте свою электронную почту че-
рез локальную сеть ресторана.
А что можно сказать об использовании карманных компьютеров для передачи заказов от
официанта на кухню? Излагая свои мечты о подобной ситуации в первом издании этой кни-
ги, я надеялся, что когда-нибудь они воплотятся в жизнь. И этот день настал. Например, в
израильском ресторане Zozobra официанты уже забыли о ручках и записных книжках. Те-
перь они пользуются карманными компьютерами. При этом счастливы и официанты, и посе-
тители.
Развитие ресторанного бизнеса
Идеей улучшения обслуживания компании LaHudra, Nar и Goniff не ограничива-
ются: они хотят совершить революцию в ресторанном бизнесе и верят, что смогут по-
строить рестораны, основанные на системе WIN, в крупных городах по всему миру.
Ведь существует мнение, что компьютерная технология поможет улучшить качество
обслуживания посетителей.
Представитель Gonif, который даже для распилки дров ищет новые методики, все
это время размышляет о новой технологии (по крайней мере с окончания главы 20!).
21-й час. Проектирование интерфейса пользователя и развертывание системы
311
— Послушайте, парни — говорит он своим партнерам, — построив рестораны в
крупных городах, мы сможем вывести технологию на новый виток и распространять
информацию повсюду.
— Это как? — спрашивает представитель Nar, отличающийся изрядным тугодумием.
— Раз мы представляем интернациональную корпорацию, то можем зайти в Web и...
В разговор вмешивается представитель LaHudra:
— Одну секунду. У нас и так имеется Web-страница. На наш узел
www. lahudranargonif f . com обращаются круглые сутки, разве не так?
— Слушай, ты, LaHudra, дай мне закончить. Мы можем использовать Web-
страницу для того, чтобы люди посещали наши рестораны. Посетителям Web-
страницы можно давать бесплатный сэндвич.
— Чего-чего?! — недоверчиво спрашивают представители Nar и LaHudra одновре-
менно.
— Давайте поразмыслим. Мы посвятим страницу Web-узла нашей сети ресторанов.
Посетитель этой страницы сможет оставить свое имя и другую информацию о себе и
выбрать сэндвич на свой вкус. Если окажется, что он делает это впервые, то попадает
на другую страницу, где сможет распечатать купон для сэндвича. С этим купоном он
и сможет пойти в ближайший ресторан, где получит свой сандвич, съест его, насла-
дится обслуживанием, а затем снова придет в качестве клиента, который платит.
— Звучит здорово, но Web-узел можно посетить откуда угодно, — говорит предста-
витель Nar. — Предположим, кто-то живет далеко от наших ресторанов, а сэндвич
тоже хочет?
— Стойте! Я знаю! — вступает в диалог LaHudra. — На Web-странице клиенты
смогут использовать свою кредитную карточку для оплаты взноса за транспортировку,
а ближайший ресторан нашей сети за небольшую плату доставит все прямо им на дом
в контейнере. Они смогут разогреть свой сэндвич в микроволновой печи. Таким обра-
зом, всегда можно рассчитывать на обслуживание в сети ресторанов LaHudra-Nar-
Goniff, где бы они ни находились. А потом, когда клиент переедет в город, где есть
один из наших ресторанов, он с удовольствием придет туда.
— Кстати, что вы имели в виду под словами “другая информация”, которую они
введут для получения купона? — спрашивает представитель Nar.
— У меня все продумано (чего о вас не скажешь), отвечает представитель
Goniff. — Мы используем эту информацию для отправки по электронной почте рек-
ламы о других наших сферах деятельности, в соответствии со сведениями о клиенте.
— Кстати, а чем занимается группа разработчиков? У нас есть для них работа.
Резюме
Когда проект переходит к стадии проектирования, внимание программистов фоку-
сируется на пользовательском интерфейсе и развертывании системы. И то, и другое, в
конечном счете, разрабатывается на основе прецедентов и имеет чрезвычайную важ-
ность.
Проект пользовательского интерфейса зависит от художественного видения и про-
веденных научных исследований. Набор принципов проектирования пользователь-
ского интерфейса формируется после долгих лет работы с оконными интерфейсами. В
этой главе описаны некоторые из них. Если команда разработчиков проектирует GUI,
то нужно помнить эти принципы.
Пользовательский интерфейс проектируется на основе прецедентов. Система
должна обеспечивать выполнение пользователем каждого прецедента, а пользователь-
ский интерфейс должен способствовать их реализации.
Параллельно с разработкой проекта команда разработчиков планирует физическую
архитектуру, которая строится на основе прецедентов, поскольку физическая сущ-
312
Часть II. Конкретный пример
ность и структура системы определяется удобством ее использования. Системный ин-
женер строит диаграмму развертывания UML, на ней изображаются узлы, компонен-
ты программного обеспечения каждого узла и соединения между узлами. Несмотря на
то что процесс развертывания будет рассмотрен позже, лучше подумать об этом сразу.
Как показано в данной главе, в этой сфере могут возникнуть фундаментальные про-
блемы, которые нужно будет разрешить.
По завершении моделирования системы эту информацию можно использовать по-
вторно в различных контекстах. Эта модель может стать источником новых идей.
Вопросы и ответы
После того как пользователи разработали модель интерфейса на бумаге, действитель-
но ли так необходимо создавать его прототип на экране? Разве пользователи не могут
просто подождать, пока появится интерфейс уже работающей системы?
Пользователям просто необходимо показать реальный интерфейс на экране ком-
пьютера. Во-первых, они могут увидеть на экране то, чего не видели на бумаге. Во-
вторых, размеры рисунка на бумаге только приблизительно соответствуют размерам
компонентов на экране. Размещение элементов интерфейса на бумаге может не соот-
ветствовать взаимному расположению элементов на экране. Вид экрана, как правило,
несколько отличается от бумажного прототипа. К тому же моментальные снимки эк-
рана (screen shots) станут важной частью проектной документации.
Хотя это и не имеет прямого отношения к UML, но одним из принципов GUI является
предоставление пользователю различных способов для выполнения операций, связанных с
интерфейсом. Почему это так важно?
Это важно, поскольку нельзя предсказать все ситуации, где пользователь будет вы-
полнять операцию. Иногда он будет нажимать комбинации клавиш на клавиатуре, что
гораздо удобнее, чем щелкать мышью. Иногда лучше воспользоваться мышью. Обес-
печение обоих способов выполнения одних и тех же операций облегчает работу поль-
зователя.
Опять вопрос, не связанный непосредственно с UML. Почему активный залог так
принципиален для GUI?
Исследования показывают, что люди понимают активный залог быстрее, чем пас-
сивный. Кроме того, активный залог, как правило, требует меньшего количества слов
и, таким образом, занимает меньше драгоценного места на экране, чем пассивный.
Пользователям (как издателям и редакторам) больше понравится подсказка “Для про-
должения щелкните на кнопке Далее”, чем “Для продолжения процесса вами должен
быть выполнен щелчок на кнопке Далее”.
И еще один вопрос. Где можно получить детальную информацию о сетях WLAN?
Если читателя интересуют сети WLAN, советуем ему посетить Web-узел
www.wlana.com ассоциации WLANA (Wireless LAN Association). WLANA — это кон-
сорциум корпораций, которые поставляют компоненты WLAN.
Практические занятия
Эти практические задания помогут проверить полученные знания в области проек-
тирования внешнего вида системы и ее развертывания, а также планирования физи-
ческой архитектуры системы. Ответы на вопросы содержатся в приложении А.
21-й час. Проектирование интерфейса пользователя и развертывание системы
313
Тесты
1. В чем состоит анализ заданий?
2. Какой из уже выполненных видов анализа больше всего соответствует анализу
заданий?
3. Что представляет собой дизайн в стиле “клоунских штанов”?
4. Назовите три причины для ограничения использования цветов для GUI.
Упражнения
1. С помощью диаграммы состояний UML смоделируйте пользовательский ин-
терфейс управляющего.
2. Спроектируйте хотя бы одно из окон пользовательского интерфейса управ-
ляющего. Начните с группирования прецедентов, а затем представьте себе се-
минар с участием пользователей. Если вы имеете доступ к Visual Basic или к
другим визуальным средствам проектирования окон, попробуйте использовать
их для выполнения этого упражнения.
3. Поставьте себя на место системного инженера и найдите альтернативы (кроме
выбранной сетевой платы и точки доступа) для связи элементов беспроводной
сети с обычной сетью.
4. Предположим, команда разработчиков приняла решение использовать кар-
манные компьютеры. Снова поставьте себя на место системного инженера и
перечислите все последствия такого выбора. Исследуйте потенциальные спо-
собы реализации сетей WLAN на основе устройств PALM или Pocket PC. Вне-
сите соответствующие изменения в рис. 21.9.
314
Часть II. Конкретный пример
22-й час
Знакомство с шаблонами
проектирования
Из этого часа вы узнаете
> Как параметризовать класс
> Что такое шаблоны проектирования
> Как применять шаблоны проектирования
> Как создать собственный шаблон проектирования
> Каковы преимущества шаблонов проектирования
Теперь, изучив основы UML и способы их использования в контексте проекта
разработки, рассмотрим вопрос применения UML для поддержки важной области —
шаблонов проектирования.
В предыдущей главе рассматривалось много вопросов. Диаграммы классов и по-
следовательностей, диаграммы состояний и семинары способствовали применению
UML для решения реальных задач.
Теперь немного изменим направление исследований. В этой главе подробно рас-
смотрим одно из приложений UML, популярность которого неуклонно возрастает.
Это приложение — представление шаблонов проектирования — охватывает суть ре-
шений, часто принимаемых в реальных проектах и ситуациях.
Параметризация
В главе 2, “Знакомство с объектно-ориентированным подходом”, упоминалось о
том, что класс является шаблоном для создания объектов. Класс можно рассматривать
как формочку для печенья, с помощью которой штампуют новые объекты. Напом-
ним, что объект является экземпляром класса.
Чтобы освежить память, вернемся к примеру со стиральной машиной. Определе-
ние класса СтиральнаяМашина с атрибутами производитель, модель, серийныйНо-
мер и мощность, а также операциями положитьБелье(), засыпатьПорошок () и
включить () дает возможность создавать новые объекты, относящиеся к классу сти-
ральных машин. Каждый раз при создании объекта задаются значения атрибутов.
UML позволяет всегда находиться на шаг впереди, т.к. предоставляет механизм
создания классов, аналогичный созданию объектов. Разница заключается в том, что
значения присваиваются не всем атрибутам, а только некоторому их подмножеству. В
итоге получается не объект, а класс. Такой класс называется параметризированным . В
UML он изображается так, как показано на рис. 22.1. Перфорированный блок в верх-
нем правом углу содержит параметры, которым присваиваются значения, соответст-
вующие создаваемому классу. Они называются неопределенными параметрами. При
создании реального класса им необходимо присвоить значения. Обозначение т в пер-
форированном блоке является классификатором, который определяет этот класс как
шаблон для создания других классов.
Рассмотрим пример. Предположим, существует параметризированный класс жи-
воеСущество. Неопределенными параметрами могут быть род и вид, а стандартными
атрибутами — название, рост и вес, что отображено на рис. 22.2.
Если параметру род присвоить значение homo, а параметру вид — sapiens, полу-
чим класс Человек. Название класса соответствует букве т. На рис. 22.3 изображен
один из способов представления такого связывания. Этот способ называется явным
связыванием, поскольку в нем явно показан созданный класс с собственным именем
во взаимосвязи с параметризованным классом.
—[ Т,род:String,вид:String*
ЖивоеСущество
название: String
рост: Integer
вес: Integer
Рис. 22.1. Пиктограмма Рис. 22.2. Параметризирован-
UML для параметризи- ный класс ЖивоеСущество
рованного класса
—[ Т,род:String,вид:String*
ЖивоеСущество
название: String
рост: Integer
вес: Integer
А
<<связывание>>
(Человек, homo, sapiens)
Человек
Рис. 22.3. Явное связывание парамет-
ризированного класса ЖивоеСущество
316
Часть II. Конкретный пример
Взаимосвязь между классами Человек и ЖивоеСущество является отношением
реализации, которое уже упоминалось ранее при обсуждении интерфейсов. Напом-
ним, что интерфейс — это просто набор операций, и при связывании интерфейса с
классом эти операции реализуются. Аналогично, человек “вдыхает жизнь” в абстракт-
ное живое существо. Эта аналогия является неполной. Чтобы подчеркнуть особую
природу этого отношения к линии взаимосвязи добавляется ключевое слово
<<связывание>>.
Другой способ связывания называется неявным связыванием. При его использова-
нии отношение зависимости не отображается, а значения параметров заключают в уг-
ловые скобки и помещают в одной строке с именем созданного класса (рис. 22.4).
—[ Т,род:String,вид:String^
ЖивоеСущество
название: String
рост: Integer
вес: Integer
ЖивоеСущество<Человек, homo, sapiens>
Рис. 22.4. Неявное связывание парамет-
ризированного класса ЖивоеСущество
В любом случае можно, задав значения атрибутов имени, роста и веса, создать
объект класса Человек.
Шаблоны проектирования
Идею параметризации можно расширить. Любой классификатор UML может быть
параметризирован. В сущности, можно параметризировать группу взаимосвязанных
классификаторов, и это довольно интересно.
После нескольких десятилетий активного использования объектно-ориентирован-
ного подхода сформировался набор устойчивых решений для типичных задач. Эти
решения, называемые шаблонами проектирования, в последнее время получили широ-
кое распространение. Поскольку шаблоны проектирования вышли из объектно-
ориентированного мира, их легко понять, построить их диаграммы и повторно ис-
пользовать. Благодаря UML мы располагаем общим языком моделирования для объ-
яснения и распространения этих шаблонов.
Первая книга по шаблонам проектирования вышла в издательстве Addison-Wesley в
1995 году. Ее авторами являются Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон
Влиссидес (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) — которые хо-
рошо известны как “Союз четырех”.
Шаблон проектирования, в сущности, является проектным решением, выработан-
ным в процессе практической работы над множеством проектов. Такой шаблон может
вполне подойти команде разработчиков в различных контекстах. В каждом шаблоне
проектирования описан набор взаимосвязанных объектов и классов, который можно
подгонять для решения конкретной проблемы в определенном контексте.
22-й час. Знакомство с шаблонами проектирования
317
В своей книге авторы (“Союз четырех”) перечислили и охарактеризовали 23 ос-
новных шаблона проектирования. Они разбили эти шаблоны на три категории в соот-
ветствии с назначением', шаблоны создания, имеющие отношение к процессу создания
объектов, структурные шаблоны, относящиеся к композиции объектов и классов, и
поведенческие шаблоны, определяющие взаимодействие и распределение обязанностей
между классами и объектами. Авторы продолжают разбивать шаблоны проектирова-
ния в зависимости от того, к чему они применяются — к объектам или классам. Этот
критерий называется областью действия, которая в случае большинства шаблонов на-
ходится на уровне объектов.
В каждом шаблоне проектирования имеется четыре элемента: имя, которое дает
возможность кратко описать задачу, проблема, определяющая область применения
этого шаблона, решение, выявляющее составные части проектного решения и их взаи-
мосвязи, а также результаты применения шаблона.
Шаблон проектирования в модели можно представить в виде параметризирован-
ной диаграммы коммуникации элементов UML. Шаблон проектирования в общем
виде описывает решение проблемы. Присвоение имен, соответствующих предметной
области, позволяет применять шаблон к модели конкретной системы. Параметризи-
рованная диаграмма коммуникации поможет увидеть эти особенности в контексте
шаблона.
Шаблон Цепочка обязанностей
Давайте рассмотрим один из шаблонов проектирования, и вы поймете, что имеет-
ся в виду.
Шаблон Цепочка обязанностей (Chain of Responsibility) является поведенческим
шаблоном, который применяется к различным предметным областям. Этот шаблон
определяет взаимосвязь между набором объектов и запросом. Он применяется в том
случае, если выполнить запрос могут несколько объектов. Первый объект цепочки по-
лучает запрос и передает его другому объекту для выполнения или передачи по це-
почке до тех пор, пока один из объектов не выполнит этот запрос. Первому объекту,
получившему запрос, не известно, какой из объектов выполнит запрос. Объект, кото-
рый выполняет запрос, называется скрытым получателем.
На этом методе основана работа ресторанов, а также агентств по продаже автомо-
билей в кредит. В ресторане клиент, как правило, не отправляет запрос непосредст-
венно шеф-повару и обычно не объясняет шеф-повару, как должен выполняться его
запрос. Он делает заказ официанту, который передает этот заказ шеф-повару. Тот, в
свою очередь, может сам выполнить заказ или передать его своему помощнику. (Так и
происходит в ресторанах LaHudra, Nar, и GonifF.) В агентстве по продаже автомобилей
дилер передает кредитную информацию финансовым ведомствам до тех пор, пока од-
но из них не примет этот кредит.
После нескольких примеров можно рассмотреть шаблон проектирования Цепочка
обязанностей в абстрактном виде. В реализации этого шаблона участвуют объекты
Клиент, АбстрактныйОбработчик и КонкретныйОбработчик. Объекты Конкретный-
Обработчик являются потомками класса АбстрактныйОбработчик. Объект Клиент
инициирует запрос. Если объект КонкретныйОбработчик может выполнить требова-
ние, то он делает это. Если не может, то передает это требование следующему объекту
КонкретныйОбработчик. На рис. 22.5 показан вид данной структуры.
Идея, на которой основан этот шаблон, состоит в том, чтобы освободить объект от
необходимости знать, какой из других объектов выполнит его запрос. Это придает до-
полнительную гибкость при распределении обязанностей между объектами. Обратная
сторона медали состоит в том, что шаблон не дает гарантии выполнения запроса. На-
318
Часть II. Конкретный пример
пример, возможно, что ни одна финансовая организация не предоставит кредит на
покупку автомобиля в ответ на соответствующий запрос.
Обратите внимание на рефлексивную ассоциацию абстрактного класса Абстракт-
ныйОбработчик с самим собой. Авторы шаблона из “Союза четырех” хотели показать
возможность реализации наследников абстрактных обработчиков. (В некотором смыс-
ле, объекту известно, как найти своих наследников.) На рис. 22.5 это показано с по-
мощью класса ассоциации, чтобы обеспечить дополнительную возможность добавле-
ния атрибутов к объекту-наследнику.
Рис. 22.5. Структура шаблона проектирования Цепочка
обязанностей
Шаблон Цепочка обязанностей
в предметной области ресторана
В предметной области ресторана класс АбстрактныйОбработчик является классом
Служащий, а объекты КонкретныйОбработчик — это официант, шеф-повар и помощ-
ник шеф-повара. Класс Клиент соответствует клиенту ресторана, который может
инициировать запрос (сделать заказ), и не обладает информацией, кто будет его вы-
полнять.
Структура шаблона в данной предметной области отражена на рис. 22.6.
На рис. 22.6 не показано, как объекты данной предметной области соответствуют
именам объектов-участников шаблона. Чтобы изобразить этот контекст, воспользуем-
ся параметризованной диаграммой коммуникации (рис. 22.7).
На рис. 22.7 эллипс с пунктирным контуром описывает шаблон проектирования,
имя которого указано внутри эллипса. Окружающие блоки соответствуют объектам,
принимающим участие во взаимодействии. Отношение зависимости показывает, что
шаблон зависит от других участников. Метка рядом со стрелкой описывает роль уча-
стника в шаблоне. Параметризация проводится с помощью добавления имен, харак-
терных для классов предметной области.
22-й час. Знакомство с шаблонами проектирования
319
Рис. 22.6. Шаблон проектирования Цепочка обязанностей в
предметной области ресторана
Служащий
АбстрактныйОбработчик
( Цепочка обязанностей I
КонкретныйОбработчик!
КонкретныйОбработчикЗ
I *
I
I
Конкретный0бработчик2
Рис. 22.7. Параметризированная диаграмма коммуникации для описания шаблона
Цепочка обязанностей в предметной области ресторана
Применение шаблона Цепочка
обязанностей для моделирования событий
в Web-браузере
При разработке интерактивной Web-страницы проектировщик должен смоделиро-
вать событие открытия браузера. В Internet Explorer для обработки события, напри-
мер, нажатия кнопки, используются сценарии JavaScript или VBScript. Такой сцена-
рий, называемый обработчиком событий, определяет изменения, которые должны
произойти при нажатии кнопки.
320
Часть II. Конкретный пример
В документе HTML страницу можно разделить на области, в которые помещают
формы. На форме можно расположить кнопки. Не напоминает ли это композит? Так
оно и есть. Каждый элемент является компонентом документа, а некоторые компо-
ненты являются подкомпонентами других компонентов. Эрих Гамма, Ричард Хелм,
Ральф Джонсон и Джон Влиссидес выделили Композит (Composite) как один из своих
шаблонов проектирования и подметили, что он часто используется в связке с шабло-
ном Цепочка обязанностей. Взаимосвязь “компонент-композит” реализует связь с
объектом-наследником. При описании диаграммы классов для шаблона Цепочка
обязанностей мимоходом было упомянуто, что в некоторых случаях объектам из-
вестно, как находить своих наследников. Это именно такой случай.
Если кнопка размещена на форме в некоторой области документа, который откры-
вается в Internet Explorer, обработка события “щелчок на кнопке” начинается с кноп-
ки, передается форме, затем — области документа и, наконец, — самому документу. В
каждом из этих объектов может быть определен свой обработчик события “щелчок на
кнопке”.
Если сценарий документа-резидента динамически определяет, обработчик какого
элемента был запущен, то этот сценарий является реализацией шаблона проектирова-
ния Цепочка обязанностей. На рис. 22.8 изображена диаграмма классов, а на
рис. 22.9 — параметризированная диаграмма коммуникации для этого шаблона проек-
тирования, применяемого к моделированию события в Internet Explorer.
Рис. 22.8. Диаграмма классов для реализации шаблона Цепочка обязанностей на
Web-странице, которая открывается в Internet Explorer
В Netscape Navigator также имеется модель обработки событий, которая противо-
положна модели Internet Explorer. В Navigator элемент высшего уровня (документ)
первым фиксирует событие и передает его дальше до тех пор, пока оно не достигнет
элемента, который его инициировал. Как изменить диаграмму классов из рис. 22.8
для моделирования события в Navigator? (В упражнении в конце этой главы вам будет
предложено это сделать.)
22-й час. Знакомство с шаблонами проектирования
321
Рис. 22.9. Параметризированная диаграмма коммуникации для шаб-
лона Цепочка обязанностей, реализованного для Web-страницы в
Internet Explorer
Разработка собственного шаблона
проектирования
Несмотря на вполне заслуженное признание шаблонов проектирования, разработан-
ных “Союзом четырех”, они не являются единственно возможными. Наоборот, в наме-
рения авторов входило поощрение дальнейших разработок и использования шаблонов.
Для того чтобы понять идею определения шаблонов, вспомним главу 11,
“Диаграммы видов деятельности”, в которой рассматривался пример с числами Фи-
боначчи и выполнялось упражнение с “треугольными” числами.
Какие общие особенности этих задач можно выделить? Решение каждой из них
начиналось с исходного значения или набора значений, затем выполнялась некая по-
следовательность вычислений, приводящая к получению n-го члена ряда.
Давайте назовем этот шаблон Вычисление ряда. Его можно было бы представить
одним объектом, но мы попытаемся все-таки построить набор взаимодействующих
объектов для иллюстрации концепции шаблонов проектирования.
Можно выделить три объекта, имеющих отношение к шаблону Вычисление ряда:
ИсходноеЗначение (которое может содержать одну и больше величин), ПравилоНа-
копления и ОкончательноеЗначение. На рис. 22.10 изображена диаграмма классов
для этого шаблона. Начальное значение определяется атрибутом первое. Если необ-
ходимо еще одно начальное значение, как в случае с числами Фибоначчи, то оно по-
мещается в атрибут второе. Иногда, как в случае с факториалами, требуется значение
нулевого элемента. Для его хранения предназначен атрибут нулевое. Алгоритм по-
следовательного вычисления изображен как операция вычислить () объекта Правило-
Накопления. Количество вычисляемых членов ряда определяется атрибутом пый объ-
екта ПравилоНакопления.
Что касается взаимодействия, то объект ПравилоНакопления начинает вычисление
членов ряда со значений, определяемых атрибутами объекта ИсходноеЗначение, и
отправляет результат объекту ОкончательноеЗначение (рис. 22.11).
322
Часть II. Конкретный пример
Рис. 22.10. Структура классов шаблона проектирования Вычисление ряда
Рис. 22.11. Взаимодействие объектов в рамках шаблона проектирования Вычис-
ление ряда
Чтобы применить этот шаблон проектирования для вычисления ряда треугольных
чисел, присвоим классам соответствующие имена и построим параметризированную
диаграмму коммуникации (рис. 22.12). (Естественно, здесь не учтено “тривиальное”
решение, описанное в упражнении 3 главы 11.)
Заодно изобразим параметризированную диаграмму коммуникации для вычисле-
ния факториала (рис. 22.13).
22-й час. Знакомство с шаблонами проектирования
323
Рис. 22.12. Параметризированная диаграмма коммуникации
для вычисления членов ряда треугольных чисел
НачальныйФакториал
ИсходноеЗначение
/_ \
।Вычисление членов pHflaz
Рис. 22.13. Параметризированная диаграмма коммуникации
для вычисления факториала
Преимущества шаблонов
п роекти рован ия
Шаблоны проектирования удобны для применения во многих ситуациях. Во-
первых, их можно неоднократно использовать. Если описать солидный проект в виде
шаблона, то можно облегчить жизнь себе и другим, работая с ним снова. Кроме того,
они обеспечивают возможность четкого и краткого описания набора классов или объ-
ектов, которые взаимодействуют при решении задачи. Таким образом, повышается
вероятность использования шаблона как компонента проекта. И, наконец, используя
шаблоны при разработке проекта, легче документировать создаваемую систему.
Резюме
Параметризированный класс имеет неопределенные параметры. Связывание этих
параметров приводит к созданию класса. Можно параметризировать любой классифи-
324
Часть II. Конкретный пример
катор UML. Параметризированная диаграмма коммуникации служит для описания
шаблона проектирования — решение, удобное для множества предметных областей.
Шаблон проектирования Цепочка обязанностей применяется к объектам, пере-
дающим запрос друг другу до тех пор, пока один из объектов не выполнит его. Этот
шаблон взят из хорошо известной книги о шаблонах проектирования.
Собственный шаблон проектирования получен на основе диаграмм видов деятель-
ности, созданных в главе 11. Можно создать шаблон проектирования для вычисления
членов ряда. В этом шаблоне участвуют объекты ИсходноеЗначение, ПравилоНакоп-
ления и ОкончательноеЗначение.
Шаблоны проектирования имеют ряд преимуществ. Их применение может облег-
чить проектировщикам повторное использование проверенных решений, внедрение
сложных компонентов в проекты и упрощение документирования создаваемых систем.
Вопросы и ответы
Насколько сложно разрабатывать шаблоны проектирования?
Вопрос не в сложности, а скорее в наличии практики. Работая в качестве аналити-
ка или проектировщика, вы заметите определенные закономерности, которые будут
выявляться снова и снова. Через некоторое время станете мыслить категориями этих
закономерностей. Исследования показывают, что эксперты в отдельных предметных
областях мыслят языком шаблонов и применяют эти шаблоны в большинстве ситуа-
ций. Это является основой кажущейся легкости и успеха их работы.
Шаблоны используются только в проектах или где-то еще?
Нет, не только. Шаблоны можно найти на любой стадии процесса разработки и в
любых других областях. Кстати, “Союз четырех” вдохновила работа архитектора, ко-
торый увидел повторяющиеся шаблоны в проектах зданий.
Практические занятия
Вопросы и упражнения дадут возможность подумать о дополнительных возможно-
стях UML. Ответы находятся в приложении А.
Тесты
1. Как представить параметризированный класс?
2. Что такое “связывание”, и какие существуют типы связывания?
3. Что такое “шаблон проектирования”?
4. Что представляет собой шаблон проектирования Цепочка обязанностей?
Упражнения
1. Внесите изменения в диаграмму классов на рис. 22.8 для визуализации модели
обработки событий в Netscape Navigator. Как было сказано в этой главе, обра-
ботка события в Netscape Navigator начинается на уровне документа и переда-
ется дальше до тех пор, пока не дойдет до элемента, который инициировал это
событие. Такой элемент может быть расположен на самых нижних уровнях
иерархии объектов в документе HTML.
22-й час. Знакомство с шаблонами проектирования
325
Часть III
Взгляд в будущее
Темы занятий
23. Моделирование встроенных систем
24. Картина будущего UML
23-й час
Моделирование встроенных систем
Из этого часа вы узнаете
> Что такое встроенные системы
> Моделирование встроенной системы в UML
Рассмотрим применение UML в новой очень важной области. В этой главе рас-
сматриваются компьютерные системы, которые не устанавливаются на настольные,
портативные и ручные компьютеры. Такие системы являются неотъемлемой частью
приборов в самолетах, поездах и автомобилях.
Назад к ресторану
Предположим, компания LaHudra и ее бравые партнеры Nar и Goniff получили
немыслимые прибыли от сети ресторанов будущего. Обслуживание настолько качест-
венное, а пища такая вкусная, что люди собираются со всей округи, чтобы попробо-
вать восхитительные блюда в приятной дружеской атмосфере.
Однако счастье омрачают две вещи. Как стало ясно из ежемесячных отчетов, поя-
вились некоторые негативные моменты.
— Вы посмотрите на это, — говорит представитель Nar, передавая распечатки
представителям Goniff и LaHudra. — Мы набиваем полные карманы денег, но нам нуж-
но еще больше. Официанты почему-то стали ронять тарелки с едой чаще обычного.
— Да, я тоже это заметил, — говорит представитель Goniff. — Всякий раз, когда
они роняют тарелку с едой, шеф-повар вынужден готовить снова. А мы должны опла-
чивать новое блюдо.
— Действительно ли так важно, что у некоторых официантов жирные пальцы? —
спрашивает LaHudra.
— Как ни странно, да. — отвечает Goniff. — Несколько тарелок здесь, несколько —
там, и мы теряем реальные деньги. Но кое-что беспокоит меня еще больше.
— Вы о чем? — спрашивает представитель Nar.
— Судя по отчетам, что-то много болеет наш обслуживающий персонал. Это хо-
рошо, что у нас в ресторанах теперь используется компьютерная технология. С ее по-
мощью нам удается выкрутиться, “навесив” на других официантов дополнительный
объем обслуживания.
— Давайте выясним, что не так, — говорит LaHudra.
Голь на выдумки хитра
Трое партнеров опросили нескольких официантов, которые болели накануне, и
сделали поразительное открытие: разбитые блюда и дни болезни связаны. Официанты
так крепко держатся за свои ручные компьютеры, что их пальцы начинают уставать.
При переноске края тарелок выскальзывают у них из рук, и тарелки падают. Более
того, руки начинают так болеть, что официанты не могут работать.
— Можем ли мы как-то помочь этим людям? — волнуется представитель Nar.
— А заодно и себе, — добавляет Goniff.
— Существует ли какой-то способ помочь им укрепить пальцы и запястья? —
спрашивает участник от LaHudra.
— И что мы должны делать? Купить им эспандеры для рук? — недоумевает Goniff.
— Замечательно, — говорит представитель LaHudra, — но я не знаю, насколько
эффективны эти устройства. Может быть, такие упражнения придется выполнять
слишком долго, и процесс накачивания мышц займет всю оставшуюся жизнь.
— Но все же идея хороша, — говорит участник от Nar. — Может только следует
улучшить конструкцию эспандера?
— А как мы можем усилить эспандер? — спрашивает LaHudra.
Ему не пришлось слишком долго ждать ответа. Разговор продолжил представитель Nar.
— Как мне помнится, многие люди верят в то, что самое лучшее и эффективное
упражнение — это то, при котором нагрузка на мускулы максимальна. Если мы смо-
жем создать эспандер, который увеличит нагрузку на предплечья, то готов держать
пари, что мы сможем укрепить запястья наших официантов раза в два быстрее, чем с
помощью стандартного эспандера.
— И как это сделать? — удивляется прагматичный сотрудник LaHudra.
— Так же, как мы произвели революцию в ресторанном бизнесе, — отвечает пред-
ставитель Nar, — с помощью технологии.
— Секундочку, — говорит его оппонент, — то, что мы сделали в ресторанах, мы
сделали с помощью компьютеров. Вы всерьез считаете, что мы будем монтировать
компьютеры в эспандеры?
— Почему бы и нет? — отвечает представитель Nar.
— Действительно, почему бы и нет, — соглашается руководитель Goniff. — Я с то-
бой, Nar. А когда мы закончим создание этой штуковины, то сможем ее продавать. Я
даже придумал подходящее название: как насчет “ВозьмиИСожми”?
— Кажется, мне это начинает нравиться, — осторожно говорит сотрудник LaHudra.
— Мне тоже, — добавляет представитель Nar с энтузиазмом. — Где же команда
разработчиков?
Детализация проекта ВозьмиИСожми
И пришлось команде разработчиков WIN снова собраться вместе. Теперь их новой
миссией стало осуществление проекта ВозьмиИСожми — разработка “умного” уст-
ройства для укрепления запястий и предплечий, которое обеспечивает различные на-
23-й час. Моделирование встроенных систем
329
грузки в ходе упражнений: для увеличения работы мускулов необходимо сильнее
сжимать устройство ВозьмиИСожми.
В ходе выработки своего представления команда проводила некоторые исследова-
ния по оценке нагрузки на мускулы. Она изучала электрические сигналы, идущие из
активных мышечных волокон. Эти электромиографические сигналы EMG
(electromyographic signals) положены в основу замечательных устройств, которые дают
возможность слабым физически людям управлять электронным оборудованием.
Работа с сигналами EMG
Этот пример не из области научной фантастики. В 1990-х годах нейролог Дэвид Уорнер
(David Warner) из медицинского центра университета Loma Linda разместил электроды на
лице мальчика и подсоединил их к компьютеру. Мальчик, парализованный в результате ав-
токатастрофы от шеи и ниже, мог передвигать объекты на экране компьютера с помощью
напряжения лицевых мышц.
Более подробно об этих экспериментах можно прочесть в статье Хью С. Ластеда (Hugh S.
Lusted) и Р. Бенджамина Henna (R. Benjamin Knapp) Controlling Computers with Neural Signals,
опубликованной в журнале Scientific American в октябре 1996 года.
К моменту написания этой книги появились интерфейсы компьютеров с биосенсорами. В ча-
стности, один из сенсоров можно взять в руку, подключить к компьютеру и мериться силой с
воображаемым соперником через Internet. Более подробную информацию об этом можно
найти ПО адресу www. sgspartners . com.
Команда разработчиков пришла к заключению, что такие сигналы EMG можно
фиксировать посредством закрепленного на предплечье недорогого поверхностного
электрода, пропуская зафиксированные сигналы EMG через компьютер и, таким об-
разом, использовать их в качестве основы для регулирования компьютером нагрузки в
ручном эспандере. При этом приходится фиксировать и анализировать данные в ре-
альном времени, поскольку регулирование должно происходить одновременно с со-
кращениями мышц.
Одним из проектных решений является закрепление поверхностного электрода на
предплечье, подключение его к настольному компьютеру, анализ сигналов EMG по-
средством этого компьютера и обеспечение необходимого управления эспандером.
Положительной стороной такого проекта является возможность вывода всех типов
данных на экран, получение информативных отчетов по развитию и анализ измене-
ний. Отрицательный момент заключается в том, что выполняющий упражнения чело-
век привязан к компьютеру.
Другая возможность такова: встроить микрокомпьютер непосредственно в устрой-
ство эспандера, благодаря чему выполняющий упражнения человек будет свободен в
передвижении. На рис. 23.1 показано, как может выглядеть подобное устройство. При
каждом повторении упражнения человек сжимает подвижную планку эспандера и пе-
редвигает ее в направлении основной планки.
Положительная сторона встроенной системы заключается в том, что подобное уст-
ройство можно использовать практически где угодно (если компьютер работает от ба-
тарей). Отрицательный момент, естественно, — потеря всей потенциальной информа-
ции, которая могла бы выводиться и сохраняться на настольном компьютере.
Во время семинара было установлено, что предпочтительнее реализовать второй
проект. Таким образом, команде разработчиков придется погрузиться в замечатель-
ный мир встроенных систем.
330
Часть III. Взгляд в будущее
Встроенный компьютер
Пружинный интерфейс
и исполнительный механизм
Пружины
Подвижная планка
Неподвижная планка
Поверхностный электрод
Рис. 23.1. Версия встроенной системы в устройстве ВозьмиИСожми
Что представляет собой встроенная
система
Ни для кого не секрет, что компьютеры применяются везде. Но что означает
“везде”? Те компьютеры, которые мы видим вокруг себя, являются только верхушкой
айсберга. Многие из них скрыты в таких местах, где их трудно разглядеть. Они нахо-
дятся внутри приборов, машин, самолетов, заводского оборудования, биомедицинских
устройств и т.д. Довольно мощные процессоры находятся внутри принтеров.
Все эти невидимые невооруженным глазом компьютеры являются примером
встроенных систем. Любое “умное” устройство содержит встроенный компьютер.
Во встроенных системах нет клавиатуры и мониторов для взаимодействия с чело-
веком. Каждая из них представляет собой чип (микросхему), который находится внут-
ри устройства (например, бытовой техники), и это устройство совсем не похоже на
компьютер. Встроенные системы определяют суть работы этого устройства.
При использовании системы такого типа человек не ощущает, что работает с ком-
пьютером. Он всего лишь взаимодействуем с этим устройством. Если пользователю не
известно, что внутри устройства находится компьютерная микросхема, то это даже
лучше. Человека, готовящего хлебные тосты, не интересует, что встроенная компью-
терная микросхема распределяет тепло, — ему лишь необходимо подрумянить хлебцы.
По окончании работы на настольном компьютере его необходимо отключить. При
работе со встроенной системой такая роскошь обычно непозволительна. Встроенная
система должна работать днями, а то и годами (как, например, в электрокардиостиму-
ляторе).
23-й час. Моделирование встроенных систем
331
Если текстовый процессор или программа обработки электронных таблиц создают
проблемы и приводят к отказу настольного компьютера, его можно перезагрузить. Ес-
ли же выходит из строя программное обеспечение встроенной системы, то результаты
могут оказаться губительными.
Таким образом, встроенная система не является вычислительным устройством в
привычном смысле. Она предназначена для обеспечения работы устройств другого
типа. С пользователем и окружающей средой связано другое, внешнее устройство.
Как можно догадаться, программирование встроенных систем не для слабонерв-
ных. Для этого требуется глубокое знание устройства, в котором находится система,
типа передаваемых сигналов, типа временных параметров и т.д.
Принципы организации встроенных
систем
Давайте подробнее рассмотрим встроенные системы и их функции. В последующих
разделах будут изучены наиболее важные принципы организации встроенных систем.
Время
Если отвлечься от темы обсуждения, то можно заметить, что в мире встроенных
систем заметную роль играет временной фактор. Действительно, на основе времени
встроенные системы можно подразделить на нестрогие и строгие.
Нестрогая система работает с максимальным быстродействием, но не должна укла-
дываться в определенные временные рамки. Строгая система также должна работать с
максимальным быстродействием, но при этом обязана завершить выполнение задачи
точно в срок.
Процессы
В мире встроенных систем процесс (называемый также задачей) является элемен-
тарной программой. Она составляет часть приложения и выполняет некоторую функ-
цию внутри этого приложения. Поэтому необходимо уделить максимум внимания
центральному процессору (ЦП). Под многозадачностью понимают распределение ра-
боты центрального процессора по различным процессам и переключение его внима-
ния от одного к другому.
Каждый процесс имеет номер, которым определяется его приоритет в приложе-
нии, и, как правило, пребывает в одном из шести состояний:
бездействие — находится в памяти и не имеет доступа к операционной системе;
готовность к действию — может запускаться, но текущий процесс имеет
больший приоритет;
задержка — отложен на определенный промежуток времени;
ожидание события — для его запуска должно произойти некоторое событие;
выполнение — занимает время центрального процессора;
прерывание — центральный процесс прервал его выполнение.
На рис. 23.2 изображена диаграмма состояний UML, отражающая указанные со-
стояния и переходы между ними. Отметим отсутствие символов начала и завершения.
Это говорит о том, что процесс протекает от состояния к состоянию по бесконечному
циклу.
332
Часть III. Взгляд в будущее
Рис. 23.2. Состояния процесса в приложении встроенной системы
Кстати, рассмотрим, что такое прерывание.
Прерывания
Прерывание является важным малым элементом встроенной системы. Оно пред-
ставляет собой аппаратный механизм, который сообщает центральному процессору о
происшедшем асинхронном событии. Событие является асинхронным, если оно не-
предсказуемо (т.е. не синхронизировано). Например, в устройстве ВозьмиИСожми
сигналы EMG являются асинхронными.
Если центральный процессор фиксирует прерывание, то он сохраняет результаты
своей работы и обращается к стандартной программе обслуживания прерываний ISR
(Interrupt Service Routine), которая обрабатывает это событие. Когда ISR завершает ра-
боту, центральный процессор возвращается к той задаче, которая выполнялась в мо-
мент получения сигнала прерывания.
Как увидим в дальнейшем, действия центрального процессора после обработки
прерывания определяются типом операционной системы, которая управляет цен-
тральным процессором.
Роль прерываний заключается в том, что они дают возможность центральному
процессору прервать любой протекающий процесс и обработать событие. Это чрезвы-
чайно важно для системы, работающей в реальном времени, которая должна своевре-
менно реагировать на внешние события.
Поскольку обработку события нужно осуществлять своевременно, встроенные сис-
темы должны учитывать промежуток времени обработки прерывания, даже если он
бесконечно мал. Центральному процессору требуется некоторое время от момента по-
лучения сообщения о прерывании до начала сохранения выполняемой им работы
(которая является его контекстом). Этот период называется задержкой (обработки)
прерывания. Реакцией на прерывание называется промежуток времени между получени-
ем запроса на прерывание и запуском центральным процессором ISR. После завер-
шения работы ISR наступает время восстановления после прерывания, когда централь-
ный процессор возвращается к работе, выполняемой в момент начала прерывания, —
к своему контексту.
23-й час. Моделирование встроенных систем
333
Можно выделить отдельный тип прерываний: такт системных часов, напоминаю-
щий “биение сердца” системы. Это прерывание происходит через регулярные интер-
валы, определяемые в зависимости от типа приложения (такой интервал, как правило,
составляет от 10 до 200 микросекунд). Такт системных часов указывает на временнь/е
рамки встроенной системы. Например, процесс остается в состоянии задержки опре-
деленное количество тактов системных часов.
Операционная система
Операционная система, работающая в реальном времени, выполняет роль поли-
цейского, регулирующего уличное движение среди процессов и прерываний, а также
является связующим звеном между процессами и между прерыванием и процессом.
Ядро — это часть операционной системы, которая управляет временем, затрачиваемым
процессором на отдельные процессы. Планировщик (программ) ядра определяет, какой
из процессов будет выполняться далее. Как было уже сказано, каждый процесс имеет
свой приоритет.
Ядро может быть либо с приоритетным прерыванием, либо с неприоритетным пре-
рыванием. В ядре с неприоритетным прерыванием при завершении работы ISR цен-
тральный процессор возвращается к процессу, который протекал в момент получения
запроса на прерывание. Говорят, что ядро с неприоритетным прерыванием работает в
режиме кооперативной многозадачности. На рис. 23.2 показаны состояния именно для
ядра с неприоритетным прерыванием.
При использовании ядра с приоритетным прерыванием после завершения работы
ISR центральный процессор определяет приоритеты процессов, находящихся в со-
стоянии готовности. Если один из процессов в состоянии готовности имеет более вы-
сокий приоритет, чем прерванный процесс, центральный процессор выполняет задачу
с более высоким приоритетом, а не ту, которая выполнялась в момент получения за-
проса на прерывание. Таким образом, задача с более высоким приоритетом занимает
место прерванной задачи. На рис. 23.3 показана модифицированная диаграмма со-
стояний для модели ядра с приоритетным прерыванием.
Эти два типа ядер полезно промоделировать на диаграмме последовательностей. На
рис. 23.4 показаны классы, экземпляры которых принимают участие во взаимодействии.
Выполнение
Изменение контекста
Наивысший приоритет
Готов
Рис. 23.3. Модификация переходов между состояниями для
ядра с приоритетным прерыванием
На рис. 23.5 изображена модель ядра с неприоритетным прерыванием в виде диа-
граммы последовательностей, а на рис. 23.6 в таком же виде изображена модель ядра с
приоритетным прерыванием.
На рис. 23.5 используется ограничение длительности — новый элемент, связанный
с моделированием времени в UML 2.0. Он позволяет визуализировать процессы, свя-
занные с прерываниями. В фигурных скобках параметр d означает длительность.
Каждая диаграмма в этом примере является гибридной, поскольку к обычным обо-
значениям диаграммы последовательностей добавлены пиктограммы состояний, пред-
ставленных на рис. 23.2. Обратите внимание, что ключевое слово <<становится>>
означает переход объекта из одного состояния в другое.
Несмотря на большое количество рассмотренных вопросов, мы только слегка кос-
нулись области встроенных систем.
334
Часть III. Взгляд в будущее
Рис. 23.4. Экземпляры этих классов принимают участие во взаимодействии, представ-
ленном ниже на диаграмме последовательности
Прерывание Процессор
обработатьЗапросНаПрерывание()
(а=длительность задержки)
:ЯдроСНеприоритетнымПрерыванием текушийПроцесс:Процесс
1 1
Выполнение
| сохранитьКонтекст()
{б=время отклика)
изменитьСостояниеПроцесса(прерван)
изменитьСостояние(прерван)
«становится>>
запустить!SR()
получитьСледующийПроцесс()
получитьТекущийПроцесс()
{d=длительность
восстановления)
изменитьСостояние(выполнение) 1
А
«становится>>1
______________L
v
Выполнение
Рис. 23.5. Диаграмма последовательностей для ядра с неприоритетным прерыванием
23-й час. Моделирование встроенных систем
335
Рис. 23.6. Диаграмма последовательностей для ядра с приоритетным прерыванием
Моделирование устройства
Возьми Й Сожми
Вернемся к задаче построения модели устройства Возьми ИСожми. Хотя встроен-
ные системы не обязательно являются объектно-ориентированными, выберем для мо-
делирования системы и ее взаимодействия с окружающим миром объектно-ориенти-
рованный подход.
Исходя из приведенного выше обсуждения встроенных систем, необходимо при-
нять решение о синхронизации событий, изменении состояний и последовательности
выполнения действий.
Классы
Как и для любой другой системы, начнем разработку системы с выделения клас-
сов. Чтобы понять структуру классов, обратимся к общему описанию устройства
ВозьмиИСожми и сути его работы. Это описание должно быть получено в результате
анализа предметной области.
ВозьмиИСожми состоит из поверхностного электрода, центрального процессора,
исполнительного механизма (для выполнения команд центрального процессора по
регулировке) и набора из пяти пружин. Исполнительный механизм подсоединен к
пружинам посредством связующего звена (интерфейса). Устройство ВозьмиИСожми
получает асинхронные сигналы EMG от поверхностного электрода и передает их цен-
тральному процессору. Каждый сигнал EMG вызывает запрос на прерывание. Про-
граммное обеспечение центрального процессора анализирует эти сигналы. Завершив
анализ, процессор передает сигнал на исполнительный механизм для регулировки на-
336
Часть III. Взгляд в будущее
пряжения пружин. Исполнительный механизм осуществляет регулировку за счет на-
стройки механического связующего звена (интерфейса) пружин.
На рис. 23.7 изображена диаграмма классов, реализующих описанные операции.
Обратите внимание на утолщенный контур объекта Процессор. Он означает, что
это — активный класс. Идея заключается в том, что центральный процессор всегда
контролирует процессы, получает и анализирует сигналы, а также осуществляет регу-
лировку. Он также выполняет общие функции управления системой. Отметим также
использование класса ассоциаций для управляющего сообщения, который определяет
параметры сообщения.
Рис. 23.7. Структура классов для устройства ВозьмиИСожми
Объекты СигналЕМС и УправляющееСообщение весьма важны, поэтому рассмот-
рим их подробнее. Для системы имеет значение время получения сигнала и его мощ-
ность; таким образом, времяПолучения и мощность являются вполне обоснованными
атрибутами для объекта сигналЕМС. Этот объект, бесспорно, будет также обладать
комплексом характеристик, которые не относятся к теме обсуждения.
Атрибутами объекта УправляющееСообщение являются времяГенерирования и
степеньРегулировки.
На рис. 23.8 показаны атрибуты этих классов.
<<Асинхронный>>
СигналЕМС
времяПолучения
мощность
характеристикиСигнала
УправляющееСообщение
времяГенерирования
степеньРегулировки
Рис. 23.8. Классы СигналЕМС и Управляющее-
Сообщение, а также их атрибуты
23-й час. Моделирование встроенных систем
337
Прецеденты
Как уже отмечалось, в результате семинара (в ходе которого было принято реше-
ние использовать встроенные системы, а не настольные компьютеры) было выделено
множество прецедентов. Они отображены на рис. 23.9.
Рис. 23.9. Прецеденты для устройства ВозьмиИСожми
Эти прецеденты определяют потенциальные возможности встроенной системы.
Прецедент Включение включает прецедент Выполнение самотестирования, кото-
рый, в свою очередь, включает прецеденты Тестирование электрода и Тестирова-
ние процессора.
Прецедент Выбор режима ссылается на множество различных режимов работы
устройства ВозьмиИСожми — режимов, о которых сотрудник Nar не имел представ-
ления, когда придумывал это устройство. Например, участники семинара выразили
желание иметь возможность снижать нагрузку.
Это означает, что к объекту УправляющееСообщение необходимо добавить атрибут,
определяющий режим работы системы. Мы можем назвать его алгоритмИспользева-
ния и присваивать ему возможные значения увеличениеНагрузки и снижениеНагруз-
ки. Модифицированный класс УправляющееСообщение изображен на рис. 23.10.
УправляющееСообщение
времяГенерирования
степеньРегулировки
алгоритмИспользования
Рис. 23.10. Модифици-
рованный класс Управ-
ляющее еСоо бще ние
Взаимодействия
Рассмотрим прецедент Сжимание планки и предположим, что выбран исходный
режим, т.е. нагрузка увеличивается с увеличением активности мускулов. В этой части
модели необходимо учесть временнь/е ограничения и изменения состояний. Предпо-
338
Часть III. Взгляд в будущее
ложим, интервал между тактами системных часов составляет 20 микросекунд, а время
между получением сигнала и отправлением сообщения о регулировке не превышает
10 тактов системных часов.
Еще одно предположение: операционная система может работать с приоритетным
прерыванием. Это влечет за собой несколько проектных решений. Для того чтобы
реагировать на операции ядра, необходимо рассмотреть функции центрального про-
цессора— анализировать(), настроить() и выполнитьОбщиеФункции() — как
процессы, и назначить им приоритеты.
Чтобы описать их в модели, необходимо представить их в виде классов, чего
обычно не делалось для операций. Это пример использования сложного понятия
UML, которое называется материализацией, т.е. представление в виде класса (или в
виде объекта) сущности, которую обычно не представляют таким способом. При этом
обогащается модель системы, поскольку материализованные классы имеют связи с
другими классами, собственные атрибуты и являются структурой, которой можно
управлять. В данном случае материализация позволяет описать приоритеты процессов
как атрибуты и использовать их на диаграммах взаимодействий.
На рис. 23.11 изображена структура классов для процессов устройства ВозьмиИСожми.
Как распределить приоритеты процессов? При получении запроса на прерывание
процессор должен прервать работу и обратиться к ISR. Операция обработатьisr( ) по-
лучает амплитуду сигнала EMG и другие его характеристики и помещает их в память
для выполнения операции анализировать (). Таким образом, операция анализиро-
вать () имеет высший приоритет. Следующей должна выполняться операция настро-
ить (). Операция выполнитьОбщиеФункции () должна иметь самый низкий приоритет.
Это пример того, как распределить приоритеты процессов. Если в момент получе-
ния сигнала процессор выполнял общие функции, то операция прерывается. Процес-
сор выполняет операцию обработать ISR () и извлекает соответствующие значения
сигнала. Что происходит дальше? Вернемся к прерванной операции. Теперь процес-
сор должен выполнить операцию с наивысшим приоритетом анализировать (), а за-
тем — операцию настроить().
На рис. 23.12 изображена диаграмма последовательностей для прецедента Сжима-
ние планки. Здесь снова используются ограничения. Первое отражает длительность
такта часов, а второе — верхний предел времени (в терминах тактов) от получения
сигнала до уведомления центрального процессора о завершении его настройки.
Процесс
приоритет: Integer
изменитьСостояние()
понизитьПриоритет()
---------Д---------
Рис. 23.11. Структура классов для процессов устройства ВозьмиИСожми
23-й час. Моделирование встроенных систем
339
На этой диаграмме показана последовательность событий вплоть до завершения
настройки. В четвертом упражнении в конце этой главы вы сможете дополнить эту
диаграмму самостоятельно.
Теперь самое время построить временную диаграмму (появившуюся в UML 2.0).
На рис. 23.13 показана такая диаграмма для процесса настройки с учетом ограниче-
ний, представленных на рис. 23.12. При создании этой диаграммы предполагалось,
что на рис. 23.12 содержится шкала, представляющая десять тактов времени.
:Прерывание I :Процессор :ЯдроСПриоритетнымПрерыванием 1 :ОбщиеФункции 1 :Анализ • :Настройка 1
I
в
• • {d 1 такт системных
• 1
обработатьЗапросНаПрерывание(етд)• часов = 20 микросекунд)
^~] сохранитьКонтекст() •
изменитьСостояниеПроцесса(прерван)
Выполнение
Готов
изменитьСостояние(прерван)
запустить15И()
«становится» •
получитьСледующийПроцесс() ।
Прерван
4—1—7
{d <= 10 тактов
системных часов)
I
проверитьПриоритеты(готов)
изменитьСостояние(выполнение)
। «становится»
* Прерван
Ч—— ->
• I
проанализироватьСигнал(emg)
।
обработатьРезул ьг ’атыАнализа(амплитуда) « понизитьПриоритет
------------------:-----------га :
изме! in гьСостояниеПроцесса(готов)) изменитьСостояние(выполнение^ * ,
Г :
получитьСледующийПроцесс () проверитьПриоритеты (готов) ’«становится»
------------------------“П • /------Ч •
• I Готов :
изменитьСостояние (выполнение )j I
। । ^1—1
1 «становится»?
1 1 1
* 1 (
• • Готов
обновитьПараметрыПружины(значение) । •
Рис. 23.12. Диаграмма последовательностей для прецедента Сжимание планки
Выполнение
:Настройка
Готов
Такты системных часов
Рис. 23.13. Временная диаграмма, моделирующая изменение со-
стояний в процессе настройки
340
Часть III. Взгляд в будущее
Общие изменения состояния
В дополнение к изменениям состояния в процессе взаимодействия можно рассмот-
реть изменение состояния всей системы. В принципе устройство ВозьмиИСожми долж-
но пребывать либо в рабочем состоянии, либо в состоянии ожидания (например, между
последовательностями упражнений). Устройство также может находиться в отключен-
ном состоянии. Будем считать, что рабочее состояние является композитом (рис. 23.14).
Рис. 23.14. Изменение состояний устройства ВозьмиИСожми
Развертывание
Как будет выглядеть устройство ВозьмиИСожми в готовом виде? На рис. 23.15
изображена диаграмма развертывания, в которой показаны части системы, в том чис-
ле и батареи питания.
Рис. 23.15. Диаграмма развертывания для устройства ВозьмиИСожми
23-й час. Моделирование встроенных систем
341
Напряжение мышц
Когда представители компаний получили диаграммы UML для устройства Возь-
миИСожми, разработка проекта перешла в новую фазу.
— Это идея, которую мы можем раскрутить, — говорит Goniff.
— Каким образом? — спрашивает Nar.
— Давайте подумаем. Сколько мышц в человеческом теле? Мы можем создать ум-
ный тренажер для развития многих из них.
— Серьезно? — воодушевляется Nar.
— Однозначно, — говорит Goniff. — Развив идею электрод-процессор-пружины,
можно разработать умный портативный тренажер. Он не будет много весить, по-
скольку в нем будут облегченные пружины и управляющий процессор. Мы могли бы
назвать его УкрепиСебя.
— Да, — говорит Nar, — а еще мы могли бы двигаться в другом направлении и
создать отдельный аппарат для каждой части тела.
— Точно. Что-то типа УкрепиГрудь.
— Или Укрепи Руки.
— Или УкрепиНоги.
Теперь представитель LaHudra уже ничего не понимает.
— По-моему, мне придется укрепить одно и то же для вас обоих, — говорит пред-
ставитель LaHudra своим партнерам.
— Что именно? — спрашивают они хором.
— Укрепить жизнь.
Резюме
Встроенная система — это компьютер, который находится внутри другого устрой-
ства, наподобие электроприбора. Программирование встроенных систем требует хо-
рошего знания характеристик того устройства, в которое встраивается система. Встро-
енная система может быть нестрогой, т.е. она работает с максимальным быстродейст-
вием без необходимости укладываться в определенные временнь/е рамки, или строгой,
т.е. она должна завершить выполнение задачи точно в срок.
Фактор времени, процессы (элементарные программы, которые являются частями
приложения) и прерывания (аппаратные механизмы, которые сообщают процессору о
происходящих событиях) — очень важны для встроенной системы. Существует осо-
бый тип прерывания, такт системных часов, которое происходит через регулярные
интервалы и напоминает “сердцебиение” системы.
Операционные системы, работающие в реальном времени, регулируют процессы и
прерывания. Ядро является частью операционной системы, которая управляет време-
нем, необходимым процессору для выполнения отдельных процессов. Планировщик
(программ) ядра определяет очередность выполнения процессов. Ядро может быть с
приоритетным прерыванием (в нем процесс с более высоким приоритетом занимает
место прерванного процесса с более низким приоритетом) или с неприоритетным
прерыванием (в нем прерванный процесс возобновляет свое выполнение после за-
вершения соответствующего прерывания).
Эти понятия применялись при моделировании “умного” тренажера, в котором
нагрузка варьируется в зависимости от напряжения мышц во время работы.
342
Часть III. Взгляд в будущее
Вопросы и ответы
В этой главе упоминались “умные” устройства. Относятся ли к ним системы искусст-
венного интеллекта?
Естественно. Один из разделов искусственного интеллекта, называемый “нечеткой
логикой”, является основой многочисленных типов встроенных систем.
Какие операционные системы больше подходят для реализации встроенных систем?
Встроенные системы работают под управлением простейшей операционной систе-
мы. Она часто находится, например, в игрушках. А в сложные системы обычно
встраивается операционная система с приоритетным прерыванием.
Практические занятия
Вот некоторые вопросы для проверки новых знаний, ответы на которые содержат-
ся в приложении А.
Тесты
1. Что такое встроенная система?
2. Что такое асинхронное событие?
3. Что такое строгая и нестрогая система в терминах встроенных систем?
4. Как работает ядро с приоритетным прерыванием?
Упражнения
1. Представьте себе встроенную систему для тостера. Предположим, в тостере
имеется датчик, следящий за ломтиком хлеба и определяющий степень его го-
товности. Предположим также, что нужный уровень готовности можно уста-
навливать. Изобразите диаграмму классов для этой системы. Включите в нее
датчик, центральный процессор и нагревательный элемент (ну и, конечно,
ломтик хлеба!).
2. Постройте диаграмму последовательностей для встроенной в тостер системы.
Объясните ваш выбор ядра с приоритетным или неприоритетным прерывани-
ем. Для полноты картины создайте также диаграмму развертывания.
3. Постройте диаграмму коммуникации, соответствующую рис. 23.12.
4. Модифицируйте диаграмму, представленную на рис. 23.12, таким образом,
чтобы процесс настройки завершался состоянием готовности, а система пере-
ходила в состояние выполнения общих функций.
5. На основе результатов выполнения упражнения 4 постройте временную диа-
грамму для изменения состояния анализа. Воспользуйтесь для этого шкалой
из рис. 23.12.
23-й час. Моделирование встроенных систем
343
24-й час
Картина будущего UML
Из этого часа вы узнаете
> Как создать расширения для области бизнеса
> Какие выводы следуют из бизнес-расширений
> Как моделировать пользовательский интерфейс (GUI)
> Как моделировать экспертные системы
Эта глава завершает книгу. Процесс ее изучения был довольно долгим, но зато он
охватывает большую часть UML. В последних двух главах рассматривались приложе-
ния UML к важным областям. В заключение будет изучено общеизвестное расшире-
ние UML и рассмотрено несколько других областей применения UML.
В главе 14, “Пакеты и принципы построения UML”, обсуждались расширения
UML. Цель этой главы заключается в развитии представления о применении UML в
новой предметной области. Как и любой язык, UML развивается. Его будущее зави-
сит от того, как разработчики модели используют и расширяют UML.
Расширения в области бизнеса
Одно из популярных расширений представляет собой набор стереотипов для моде-
лирования экономической деятельности (или бизнес-процессов). Стереотипы иллюст-
рируют основные идеи представления бизнес-процессов. Их можно описать уже из-
вестными символами UML или специализированными обозначениями (созданными
одним из “трех товарищей” Айваром Якобсоном (Ivar Jacobson)). Назначение стерео-
типов состоит скорее в моделировании ситуаций делового мира, чем в обеспечении
основы для конструирования программного обеспечения.
При моделировании бизнес-процессов, очевидно, потребуется класс Работник.
В контексте расширения UML работник занимается экономической деятельностью,
взаимодействует с другими и принимает участие в прецедентах. Работник может быть
штатным либо внештатным. Штатный сотрудник взаимодействует с другими работ-
никами внутри данной организации, а внештатный — с исполнителями вне органи-
зации. Сущность (entity) не инициирует никаких взаимодействий, но принимает уча-
стие в прецедентах. Работники взаимодействуют с сущностями.
На рис. 24.1 приведены обозначения для этих стереотипов. Каждый из них проил-
люстрирован примером из предметной области ресторана.
<<работник>>
Управляющий
<<штатный сотрудник>>
Шеф-повар
Управляющий
Шеф-повар
<<сущность»
Заказ
<<внештатный сотрудник>>
Метрдотель
Метрдотель
Рис. 24.1. Стереотипы для моделирования биз-
нес-процессов
Расширение для сферы бизнеса включает два стереотипа ассоциаций —
<<общается>> и <<подписывается>>. Первый стереотип предназначен для описания
взаимодействия между объектами. Второй — описывает ассоциацию между источни-
ком (подписчиком) и целью (издателем). Источник определяет набор событий, на ин-
формацию о которых он подписывается. Когда в объекте цели происходит одно из
этих событий, источник получает уведомление.
Набор сущностей составляет рабочую единицу, которая является проблемно-
ориентированным набором объектов. Рабочие единицы, классы и ассоциации состав-
ляют организационную единицу. Организационная единица (которая может включать и
другие организационные единицы) соответствует организационной единице бизнеса.
24-й час. Картина будущего UML
345
Выводы из расширений для бизнеса
Расширения для бизнеса дают возможность сделать важные выводы. Во-первых,
очевидно, что при наличии фантазии можно работать с простыми обозначениями и
описаниями, охватывающими фундаментальные аспекты предметной области. Суще-
ственное значение имеет слово “простые”. Во-вторых, описания помогают обдумы-
вать и принимать решения в предметной области.
Эти выводы помогут применить язык UML в решении двух важных задач — по-
строения графического пользовательского интерфейса и экспертных систем.
Графический пользовательский
интерфейс
Визитной карточкой пакетов программного обеспечения является графический
пользовательский интерфейс (GUI). Для разработки GUI приложения в рамках про-
цесса GRAPPLE и других методик предлагается провести семинар.
В проектный документ, как правило, включаются копии экранов (screen shots),
чтобы показать клиенту и разработчикам, как будет выглядеть интерфейс для пользо-
вателей. Желательно также построить специализированные диаграммы для моделиро-
вания пользовательского интерфейса. Такая потребность определяется несколькими
причинами.
Подключение прецедентов
Первая причина заключается в необходимости работать с прецедентами. Как и
большинство этапов процесса разработки, разработка GUI зависит от прецедентов. В
сущности, пользовательский интерфейс непосредственно имеет дело с прецедентами,
поскольку он представляет окно (просим прощения за игру слов), через которое ко-
нечный пользователь инициирует и реализует прецеденты. Вполне вероятно, что ис-
пользовать копии экрана для определения связи между окнами и прецедентами весь-
ма непросто.
Другая причина заключается в необходимости зафиксировать процесс разработки и
воплощения GUI. В процессе GRAPPLE разработка начинается тогда, когда конеч-
ные пользователи, участвующие в семинаре, работают с документами, которые опи-
сывают настройки экрана на бумаге. Было бы неплохо располагать таким типом диа-
грамм, в которых непосредственно отражаются результаты этой работы. В такую диа-
грамму разработчик модели сможет легко вносить изменения по ходу выполнения
проекта.
Диаграмма, на которой показана связь окон с прецедентами, поможет участникам
семинара осознавать, что они принимают участие в разработке интерфейса системы.
Описание связи с прецедентами позволит гарантировать, что все прецеденты будут
воплощены в окончательном проекте.
Моделирование пользовательского
интерфейса
В модели UML отдельные окна приложения описываются как композиты, состоя-
щие из множества управляющих элементов (рис. 24.2).
346
Часть III. Взгляд в будущее
Рис. 24.2. Модель UML окна
Для добавления к модели информации о пространственном расположении каждого
компонента можно использовать атрибуты. Два атрибута могут описывать координаты
объекта по горизонтали и вертикали, измеряемые в пикселях (минимальные элементы
изображения). Другая пара атрибутов могла бы описывать размеры компонента
(высоту и ширину). Эти параметры легче осмыслить, если представить их наглядно.
Можно считать, что окно описывается пакетом, а расположение и размеры объектов
внутри пакета отражают их расположение и размеры в окне (рис. 24.3).
Окно
СтрокаМеню
ТекстовоеПоле
Рис. 24.3. Модель окна, в которой указано расположение ком-
понентов
На рис. 24.4 изображена смешанная диаграмма, отображающая связь GUI-интер-
фейса с прецедентами.
Такой тип моделирования не заменяет собой создание копий экрана. Но здесь
имеется полезное дополнение — схематическая диаграмма, в которой хранится опи-
сание общей картины.
Экспертные системы
Пик популярности экспертных систем пришелся на 1980-е годы. И хотя при пер-
вом своем появлении они выглядели несколько непривычно, сейчас составляют одну
из основных тенденций развития компьютерного мира.
24-й час. Картина будущего UML
347
Окно
Рис. 24.4. Модель окна с описанием связи оконных компонентов с
прецедентами
Экспертные системы позволяют использовать интуицию и практический опыт лю-
дей, являющихся экспертами в определенных предметных областях. Они используют
этот опыт в компьютерной программе. Цель состоит в применении экспертной систе-
мы для получения ответов на повторяющиеся вопросы, чтобы не отвлекать экспертов,
или же для использования опыта в случае отсутствия эксперта.
Компоненты экспертной системы
В экспертных системах практический опыт хранится в базе знаний в виде набора
правил импликации (если, то). Часть если правила описывает некоторые ситуации из
предметной области эксперта. Часть то правила указывает на направление действий.
Каким образом практический опыт помещают в базу знаний? Специалист в области
проектирования базы знаний проводит исчерпывающие беседы с экспертом, записывает
результаты и представляет их в программном обеспечении. Это напоминает интервью
со специалистами в процессе анализа предметной области, однако, как правило, се-
минары с экспертами являются более длительными.
База знаний представляет собой не просто компонент экспертной системы. Если
бы так было, то экспертная система осталась бы всего лишь длинным списком правил
импликации. Здесь необходим еще и механизм решения проблемы посредством базы
знаний. Такой механизм называется механизмом логического вывода. Другим необхо-
димым элементом системы является рабочая область, в которой содержатся условия
поставленной задачи. Еще одним компонентом для ввода условий задачи является, ес-
тественно, пользовательский интерфейс. Ввод условий может осуществляться посред-
ством анкетирования, опрашивания с предложением вариантов ответов или с исполь-
зованием современной системы, основанной на анализе естественного языка. На
рис. 24.5 изображена диаграмма классов для экспертной системы.
348
Часть III. Взгляд в будущее
Для взаимодействия с экспертной системой пользователь вводит условия задачи,
которые хранятся в рабочей области. Механизм логического вывода использует эти
условия, чтобы войти в базу знаний и найти решение. На рис. 24.6 отображена диа-
грамма последовательностей для этого процесса.
Рис. 24.5. Диаграмма классов для экспертной системы
Рис. 24.6. Взаимодействие с экспертной системой
24-й час. Картина будущего UML
349
Очень легко провести аналогию между экспертной системой и человеком: рабочая
область очень схожа с кратковременной памятью человека, база знаний подобна дол-
говременной памяти, а механизм логического вывода определяет процесс решения за-
дачи. Когда человек “напрягает свои мозги”, чтобы найти решение сложной задачи,
то он занимаемся чем-то похожим на работу экспертной системы.
Пример
Механизм логического вывода обычно обращается к базе знаний (“напрягает
мозги”) одним из двух способов, что лучше всего продемонстрировать на примере.
Предположим, имеется экспертная система, в которой зафиксирован практический
опыт водопроводчика. Если протекает кран, то в эту экспертную систему нужно вве-
сти информацию об утечке воды. Остальное сделает механизм логического вывода.
Два правила базы знаний могут выглядеть следующим образом.
Правило 1:
ЕСЛИ протекает кран
И кран компрессионный
И кран протекает у основания,
ТО затяните герметизирующую гайку.
Правило 2:
ЕСЛИ герметизирующая гайка плотно затянута
И утечка продолжается,
ТО смените прокладку.
Не вдаваясь в специфику работы водопроводов, достаточно сказать, что эти два
правила явно связаны — подметим сходство между частью “то” правила 1 и частью
“если” правила 2. Это сходство является основой для работы с базой знаний (в кото-
рой, как правило, имеется, мягко говоря, гораздо больше двух правил). Механизм
логического вывода может начать работу с выделения потенциального решения напо-
добие “сменить прокладку” в правиле 2, а затем работать в обратном направлении для
того, чтобы определить соответствие специфики задачи с выделенным решением.
Каким образом механизм логического вывода работает в обратном направлении?
Это видно в части “если” правила, которое имеет решение и пытается найти правило
с соответствующей частью “то”. В нашем примере двух правил это легко увидеть:
правило 1 имеет соответствующую часть “то”. В мощных приложениях индустрии это
сделать не так легко, поскольку база знаний может хранить сотни, если не тысячи
правил.
После того как механизм логического вывода найдет правило, он проверяет, схо-
дятся ли условия части “если” с условиями задачи. Если это так, то механизм про-
должает работу в этом направлении — проверяет соответствие всем условиям “если”.
Когда механизм логического вывода проверит все правила, он запрашивает у пользо-
вателя дополнительную информацию. Суть всего этого заключается в том, что, если
прогон всех правил завершается успешно (т.е. правила согласуются с условиями зада-
чи), то экспертная система предлагает свое решение в качестве решения задачи.
В противном случае система начинает поиск соответствий заново.
Эта методика нахождения решения и проверки согласования условий с условиями
задачи называется обратным (логическим) выводом — “обратным”, потому что работа
начинается с частей “то” и продолжается проверкой частей “если”.
Как можно догадаться, согласно другой методике, работа начинается с частей
“если” и продолжается проверкой согласования частей “то”. Такая методика называ-
ется прямым (логическим) выводом. Рассмотрим, как она работает. Пользователь вводит
условия задачи, и механизм логического вывода находит правило, в котором части
“если” совпадают с условиями. Он проверяет часть “то” этого правила и ищет прави-
350
Часть III. Взгляд в будущее
ло, в котором часть “если” соответствует указанной части “то”. Предположим, в на-
шем примере часть “если” правила 1 соответствует условиям задачи. Механизм логи-
ческого вывода проверяет часть “то” правила 1, а затем ищет правило с соответст-
вующей частью “если”. В нашем случае это несложно, поскольку имеется всего лишь
два правила. Когда система заканчивает поиск соответствующих правил, она предла-
гает часть “то” конечного правила как решение. Слово “прямой” в названии “прямой
логический вывод” подразумевает это движение от части “если” к части “то”.
При моделировании экспертной системы, представленной на рис. 24.5, очень по-
лезным оказался бы стереотип, обозначающий тип механизма логического вывода. К
композитному классу ЭкспертнаяСистема следует добавить стереотип <<прямой вы-
вод» либо <<обратный вывод».
Цепочка
Оба типа логического вывода являются примером изученного ранее шаблона проектирова-
ния цепочка обязанностей. В каждом случае система ищет наследника правила.
Иногда шаблон Цепочка обязанностей завершает работу, не найдя наследника, т.е.
экспертная система не всегда позволяет найти решение.
Моделирование базы знаний
Что можно добавить к этому описанию с помощью UML, и для чего это может
понадобиться? Одним из сложных моментов в разработке экспертной системы являет-
ся отсутствие строгих стандартов для визуального представления правил базы знаний.
Описанию на основе UML предстоит пройти долгий путь по стандартизации и выра-
ботке удачных методов работы с документацией. Недостаточно разместить и сохра-
нить сведения в базе знаний — все правила необходимо представить также в форме
документа.
Другая сложность заключается в том, что анализ прецедентов редко завершается в
течение разработки экспертной системы. Анализ прецедентов, дополненный диаграм-
мами прецедентов UML, может помочь в определении лучшего типа механизма логи-
ческого вывода для экспертной системы. Диаграмма развертывания UML также может
пригодиться для разработки экспертной системы. Несмотря на самостоятельную цен-
ность экспертных систем, современные экспертные системы, как правило, должны
работать в корпоративных компьютерных структурах и свободно взаимодействовать с
другими системами. Диаграммы развертывания можно использовать для описания
размещения экспертной системы и ее зависимости (поддержки) от другой области
информационных технологий. Подобно тому как в роли исполнителя на диаграмме
прецедентов может выступать другая система, диаграмма развертывания и диаграмма
прецедентов могут совместно обеспечить представление экспертной системы в кон-
тексте корпорации.
Давайте рассмотрим базу знаний. Как описать ее в духе UML? Одна из возможно-
стей, естественно, заключается в том, чтобы описать каждое правило в виде объекта.
Одним атрибутом будет часть “если”, другим — часть “то”. Такая схема изображена
на рис. 24.7.
Несмотря на допустимость такого решения (многие разработчики проектируют
экспертные системы именно так), важно обеспечивать собственное описание правил,
и не только потому, что они служат в качестве основы базы знаний экспертной сис-
темы. Рост значения управления сведениями в организациях и ведомствах вынуждает
описывать правила специальным образом.
Как может выглядеть это специальное описание? Во-первых, необходимо обеспе-
чить представление для части “если” и для части “то”. Исходя из необходимости та-
кого описания, нужно также визуализировать внутренние связи между правилами.
24-й час. Картина будущего UML
351
правило!:Правило
частьЕсли = "протекает кран & компрессионный & протекает у основания"
частьТо = "затяните герметизирующую гайку"
Рис. 24.7. Описание правил в виде объектов
Все это может очень быстро усложниться. Многочисленные стратегические прави-
ла обычно включают гораздо больше информации, чем приведенные выше два прави-
ла починки водопроводного крана. Кроме того, правила имеют тенденцию к разрас-
танию. Необходимо сбалансировать детализацию и простоту описания правил.
Давайте для начала создадим простую пиктограмму для описания правила. Начнем
с прямоугольника, разделенного по центру вертикальной линией. В левой части пря-
моугольника можно описать часть “если”, а в правой — часть “то”. Внутри каждой
части прямоугольника можно кратко записать содержимое. На рис. 24.8 в таких обо-
значениях представлены правила починки водопроводного крана.
протекает кран протекает у основания затяните гермети- зирующую гайку
герметизирующая гайка плотно затянута утечка продолжается смените прокладку
Рис. 24.8. Визуальное описание двух правил для починки водопроводного крана
Теперь необходимо включить опознавательную информацию для каждого правила.
Давайте добавим горизонтальные отсеки в верхней части каждого прямоугольника, в
которых будет содержаться числовой идентификатор. Та мы убьем двух зайцев: каж-
дое правило станет однозначным, и прояснится, где именно искать в каталоге правил
полное описание, а также разъяснение этого правила. Если правило является частью
подгруппы правил (как подмножество “кран” в нашей базе знаний о водопроводах),
то эту подгруппу можно описать в виде пакета. Затем информацию о пакете можно
добавить в идентификатор обычным для UML способом — название пакета ставится
перед парой двоеточий, за которыми следует идентификатор (рис. 24.9).
Краны::правило!:Правило
протекает кран протекает у основания затяните гермети- зирующую гайку
герметизирующая гайка
плотно затянута
утечка продолжается
Краны: : правилс>2: Правило
смените
прокладку
Рис. 24.9. Добавление идентификатора в каждое правило
352
Часть III. Взгляд в будущее
Теперь представим связь между двумя правилами в виде линии, соединяющей
часть “то” правила 1 и часть “если” правила 2 (рис. 24.10).
Краны:;правило!;Правило
протекает кран протекает у основания затяните гермети- зирующую гайку
Краны::правило2:Правило
герметизирующая гайка плотно затянута утечка продолжается смените прокладку
Рис. 24.10. Связь части “то ” одного правила с частью “если ” другого правила
В отличие от набора из двух правил в нашем примере правило в реальной эксперт-
ной системе обычно связано с несколькими другими правилами. Если эти правила не
расположены рядом — в базе знаний или в документации, — то неплохо найти способ
описания связи даже в том случае, если нельзя начертить соединительные линии.
Эту информацию можно поместить в нижней части обозначения правила. Если
имеющиеся отсеки разделить горизонтальной чертой, то в нижней части описывают
идентификаторы других правил, как показано на рис. 24.11.
Краны::правило!:Правило
протекает кран протекает у основания затяните гермети- зирующую гайку
10,11,15, Водопровод::22 2,6, Мойщик::22
Краны::правило2:Правило
герметизирующая гайка плотно затянута утечка продолжается смените прокладку
2,13, Водопровод:: 15 17,18,31
Рис. 24.11. В отсеках нижней части обозначения правила можно указать связанные с
ним правила
В нижнем отсеке слева указаны правила, части “то” которых связаны с частью
“если” данного правила. В нижнем отсеке справа указаны правила, части “если” ко-
торых соединяются с частью “то” данного правила.
Как и в случае с диаграммами классов, иногда можно использовать упрощенные
обозначения правила. Идея заключается в том, чтобы кратко описать внутренние свя-
зи правил и их содержимое, т.е. отчетливо определить характер базы знаний.
Модель экспертной системы интереснее, чем модель GUI-интерфейса, поскольку
в ней предлагается новый “элемент представления” (обозначение правил) для UML, в
то время как модель GUI является смешанной диаграммой, которая состоит из рас-
пространенных элементов UML.
Web-приложения
После выхода в свет первого издания этой книги создано множество расширений
UML для важных предметных областей. В этом разделе будет рассмотрена одна из та-
ких разработок — расширение для моделирования Web-приложений.
Web-система позволяет конечному пользователю с помощью браузера (прикладное
программное обеспечение на компьютере клиента) получить доступ к документу, раз-
мещенному на главном компьютере (сервере). Web-приложение отличается от обычной
24-й час. Картина будущего UML
353
Web-системы наличием бизнес-логики, в частности возможностью выбирать товары в
магазине и осуществлять транзакции посредством кредитной карточки.
Расширение для разработки Web-приложений WAE (Web Application Extension) в
UML является детищем Джима Коналлена (Jim Conalen), сотрудника компании
Rational. Расширение WAE включает около дюжины графических стереотипов, допол-
нительных стереотипированных ассоциаций, атрибутов и правил по использованию
этих элементов при создании модели.
Каждый элемент может быть связан с несколькими тегированными значениями. В
главе 14 было сказано, что тегированное значение представляет собой помещенную в
скобки последовательность из дескриптора, знака равенства (=) и значения. Они
предназначены для добавления важной информации об элементе. Например, в рас-
ширении WAE тегированное значение для Web-страницы описывает ее местонахож-
дение на Web-сервере.
На рис. 24.12 изображено обозначение WAE для Web-страницы.
Рис. 24.12. Обозначение WAE для Web-страницы
Подметим сходство между этим обозначением и обозначением комментария. За-
гнутый угол усиливает ассоциацию со “страницей”. Нужно помнить, что Web-
страница вообще является классом с атрибутами и операциями, а определенная Web-
страница — объектом (см. упражнение 1).
На рис. 24.13 изображены обозначения WAE для трех типов страниц, используе-
мых в Web-приложениях: серверной страницы, страницы JSP (Java Server Page) и ак-
тивной серверной страницы ASP (Active Server Page). На рис. 24.14 изображены еще
три страницы: клиентская страница, набор фреймов и сервлет.
Рис. 24.13. Пиктограммы WAE (слева на-
право) для серверной страницы, страницы
JSP и активной серверной страницы ASP
Рис. 24.14. Пиктограммы WAE (слева на-
право) для клиентской страницы, набора
фреймов и сервлета
354
Часть III. Взгляд в будущее
В расширении WAE имеются пиктограммы и для других структур, не только для
страниц. Например, в Web зачастую встречаются страницы, компоненты которых по-
зволяют вводить пользовательскую информацию (флажки, переключатели, списки и
т.п.). Набор этих компонентов для отдельной страницы называется формой. На
рис. 24.15 изображена пиктограмма WAE для формы.
В расширении WAE, конечно, есть не только то, что описано в этом разделе. Более
подробную информацию о расширении WAE вы найдете в книге Джима Коналлена
“Разработка Web-приложений с использованием UML” (Издательский дом “Вильямс”,
2001). Чтобы загрузить пиктограммы WAE и использовать их в системах моделирова-
ния, поддерживающих язык UML, в том числе системах Rational Rose или Visio, посе-
тите узел www . wae-uml. org.
Рис. 24.15. Пиктограмма WAE для формы
Вот и все, друзья
Наш совместный путь подошел к концу. Теперь, поскольку читатель обладает пол-
ным багажом приемов использования UML, он уже готов выйти на собственный путь
и применять их в своей предметной области. С приобретением практических навыков
этот набор приемов будет дополняться. Читатель даже сможет давать советы по рас-
ширению UML. В таком случае, он поддержит великую традицию.
В начале двадцатого столетия известный математик Альфред Норт Уайтхэд (Alfred
North Whitehead) обратил внимание на важность символики. По его словам, символ
обозначает идею: важность символа состоит в том, что он быстро и лаконично описы-
вает связь идеи с огромным множеством других.
Лишь с началом XXI столетия наблюдения Уайтхэда подтвердились при разработке
систем. Тщательно отобранные символы описывают мыслительные процессы и слож-
ные понятия, на основе которых предлагается создавать замечательные системы и га-
рантировать успех разработки.
Резюме
При расширении и формировании UML в соответствии со своими требованиями
разработчики моделей смотрят в будущее. В этой главе описаны расширения для мо-
делирования бизнес-процессов и способы применения UML в других областях. Вни-
мание уделено также расширению UML для разработки Web-приложений WAE (Web
Application Extension).
Мы показали необходимость выработки простых расширений для бизнес-
процессов, а затем рассмотрели способы моделирования пользовательского интерфей-
са и экспертных систем. Для моделирования GUI была построена смешанная диа-
грамма, описывающая пространственное расположение экранных компонентов и их
связь с прецедентами. Такой способ дает преимущество в описании процесса разви-
тия GUI с учетом соответствующих прецедентов.
В экспертной системе правило если, то является стандартным блоком базы зна-
ний, компонентом, который содержит знания эксперта в предметной области. Была
24-й час. Картина будущего UML
355
предложена диаграмма, содержащая наглядное представление правил и их внутренних
связей. На этой диаграмме прямоугольник, являющийся моделью правила, делится на
отсеки. В одном отсеке содержится идентификатор правила, в другом — части “если”,
в третьем — части “то”, а в еще двух описываются правила, связанные с данным.
Связи между близлежащими правилами изображаются в виде линий, соединяющих
соответствующие части правил.
В расширении WAE содержится набор графических стереотипов, стереотипиро-
ванных ассоциаций, атрибутов и правил моделирования Web-приложений. Многие
обозначения спроектированы с учетом усиления ассоциации со страницей.
Вопросы и ответы
Создается впечатление, что моделировать экспертные системы несложно, гораздо
сложнее реализовать их в виде программных систем.
Несомненно, если бы приходилось начинать с чистого листа. Но к счастью, боль-
шая часть программного решения уже заложена в пакете, называемом оболочкой экс-
пертной системы. Все компоненты созданы заранее. Необходимо только добавить све-
дения. Однако получение знаний от эксперта не всегда является легкой задачей.
Должны ли производители оболочек экспертных систем составлять рекомендации по
представлению правил?
Да, и это является проблемой. Единых стандартных рекомендаций не существует.
Эта область олицетворяет утверждение (приписываемое известному ученому Эдсгеру
Дийкстра (Edsger Dijkstra)): “Все, что можно сказать о стандартах, — это то, что их
слишком много”.
Практические занятия
С помощью вопросов из этих практических заданий можно проверить свои знания
о применении UML для моделирования GUI-интерфейса и экспертных систем. Отве-
ты находятся в приложении А.
Тесты
1. В чем преимущества разработанной выше модели GUI?
2. Из каких компонентов состоит экспертная система?
3. Какие возможности экспертной системы отражает построенная выше диаграмма?
Упражнения
1. Посетите начальную страницу издательства Sams Publishing (www.
samspublishing. com) и используйте обозначение Web-страницы из расши-
рения WAE для ее моделирования. Затем смоделируйте страницу без исполь-
зования обозначения WAE, т.е. с помощью стандартной пиктограммы UML.
2. Представьте, что некий производитель хочет создать экспертную систему на
основе Web-технологии, которая обеспечивает поиск информации о неис-
правностях. При выходе аппаратного средства из строя владелец устройства
мог бы посетить эту Web-страницу, ввести симптомы и получить совет о том,
что делать дальше. Проведите анализ прецедентов и используйте информацию
об экспертных системах и расширении WAE из этой главы для создания эле-
ментарной модели Web-страницы.
356
Часть III. Взгляд в будущее
Часть IV
Приложения
А. Ответы
Б. Использование средств моделирования, поддерживающих язык UML
В. Резюме в картинках
Приложение А
Ответы
1 -й час
1. Зачем строить различные диаграммы в модели системы?
С любой системой связано несколько заинтересованных лиц. Каждый тип
диаграммы UML позволяет разработать отдельное представление, наиболее
полезное для одного или нескольких заинтересованных лиц.
2. Какие диаграммы соответствуют статическому представлению системы?
Статическое представление можно создать с помощью использования диа-
грамм классов, объектов, компонентов и развертывания.
3. Какие диаграммы обеспечивают динамическое представление системы (т.е.
показывают изменения во времени)?
Динамическое представление можно создать с помощью диаграмм прецеден-
тов, состояний, последовательностей, видов деятельности и коммуникации.
4. Какие типы объектов показаны на рис. 1.5?
На рис. 1.5 показаны анонимные объекты.
2-й час
1. Что такое объект?
Объект — это экземпляр класса.
2. Как объекты взаимодействуют друг с другом?
Объекты взаимодействуют друг с другом посредством передачи сообщений.
3. На что указывает кратность?
Кратность определяет количество объектов одного класса, связанных с объек-
том другого класса.
4. Могут ли два объекта связываться друг с другом несколькими способами?
Да. Например, два человека могут ассоциироваться друг с другом как друзья и
как сослуживцы.
5. Что такое наследование?
Наследование — это отношение между двумя классами. Один класс содержит
все операции и атрибуты другого класса, а также включает несколько собст-
венных операций. Класс, содержащий наследуемые операции и атрибуты, на-
зывается суперклассом. Класс, включающий наследуемые операции и атрибу-
ты, а также свои собственные свойства, называется подклассом.
6. Что такое инкапсуляция?
Инкапсуляция означает сокрытие информации. Объект не показывает, как он
выполняет операцию.
3-й час
1. Как изображается класс в UML?
Для представления класса используется прямоугольник. Внутри этого прямо-
угольника, ближе к верху, указывается имя класса.
2. Какую информацию можно разместить на изображении класса?
На изображении класса можно показать его атрибуты, операции и обязанности.
3. Что такое ограничение?
Ограничение помещается в фигурные скобки и представляет собой набор од-
ного или нескольких правил, которым подчиняется класс.
4. Зачем для класса используется комментарий?
К обозначению класса можно присоединить пиктограмму примечания, чтобы
добавить информацию, не относящуюся к атрибутам, операциям и обязанно-
стям. Например, если необходимо сослаться на определенный документ, со-
держащий дополнительную информацию о классе.
4-й час
1. Что такое кратность?
С одного конца линии ассоциации можно указать число объектов данного
класса, связанных с объектом класса другого конца линии.
2. Как бы вы описали наследование?
В списке классов исходной модели найдите два или несколько классов с об-
щими атрибутами и операциями. Тогда либо другой класс исходной модели
будет “родителем” этих классов, либо вы сможете создать родительский класс
самостоятельно.
3. Что такое абстрактные классы?
Абстрактный класс служит основой для реализации отношения наследования.
Абстрактный класс не может иметь экземпляров.
Приложение А. Ответы
359
4. Каково назначение квалификатора?
Квалификатор предназначен для снижения кратности “один ко многим” до
кратности “один к одному”.
5-й час
1. В чем состоит различие между агрегатным и композитным объектом?
И агрегат, и композит определяют ассоциацию “часть-целое” между компо-
нентными классами и целым. В отношении агрегации один компонент может
быть частью более чем одного целого. В композиции компонент может быть
частью лишь одного целого.
2. Что такое реализация? В чем сходство реализации с наследованием? В чем от-
личие реализации от наследования?
Реализация — это связь класса с интерфейсом. Говорится, что класс реализует
операции интерфейса. Реализация аналогична наследованию в том смысле,
что класс “получает” операции от своего интерфейса и может наследовать
операции от родительского класса. Реализация отличается от наследования
тем, что класс не “получает” атрибуты от интерфейса (поскольку их у него
нет), однако может их наследовать от родительского класса.
3. Как промоделировать взаимодействие классов через интерфейс?
Взаимодействие классов через интерфейс моделируется как зависимость.
4. Перечислите три области видимости и опишите их свойства.
Если атрибуты и операции являются открытыми (public), то другой класс мо-
жет их использовать. Защищенные (protected) атрибуты и операции могут ис-
пользоваться дочерними классами.
6-й час
1. Как называется сущность, инициирующая прецедент?
Сущность, инициирующая прецедент, называется исполнителем.
2. Что означает термин “включение прецедента”?
“Включение прецедента” означает, что некоторые шаги сценария одного пре-
цедента совпадают с шагами другого прецедента. Вместо нескольких описаний
одних и тех же шагов можно просто указать, что один прецедент является ча-
стью другого.
3. Что означает термин “расширение прецедента”?
“Расширение прецедента” позволяет добавить шаги к существующему преце-
денту. Для этого нужно создать новый прецедент.
4. Можно ли сказать, что прецедент — это сценарий?
Нет. Прецедент — это набор сценариев использования системы.
7-й час
1. Назовите два преимущества визуализации прецедентов.
360
Часть IV. Приложения
При визуализации прецедентов можно (1) показать их пользователям и полу-
чить от них дополнительную информацию и (2) использовать эти обозначения
на диаграммах других типов.
2. Опишите обобщение и группирование — взаимосвязи прецедентов, изученные
в главе. Назовите две ситуации, требующие группирования прецедентов.
При обобщении один прецедент наследует значение и поведение другого.
Группирование — это распределение прецедентов по отдельным пакетам.
3. В чем сходство классов и прецедентов? В чем их отличие?
Сходства. Оба являются структурными элементами, которые могут участвовать
в отношении наследования.
Отличия. В классе содержатся атрибуты и операции. В прецеденте содержатся
сценарии, каждый из которых является последовательностью шагов. Класс
обеспечивает статическое представление частей системы, в то время как пре-
цедент используется для динамического представления поведения. Класс при-
меняется для отображения “внутренней структуры” системы. Прецедент опи-
сывает внешний вид системы с точки зрения пользователей.
4. Как промоделировать включение и расширение?
Включение и расширение обозначаются отношением зависимости. При вклю-
чении линия связи помечается ключевым словом <<включает>>, а при рас-
ширении — <<расширяет>>.
8-й час
1. Какое важное отличие существует между диаграммами состояний и диаграм-
мами классов, объектов или прецедентов?
На диаграмме состояний моделируются состояния лишь одного объекта. На
диаграммах классов, объектов или прецедентов моделируется вся система или
как минимум одна из ее частей.
2. Дайте определение терминов: переход, событие и действие.
Переход — это изменение состояния объекта с одного на другое. Событие
приводит к переходу. Действие — это выполняемое вычисление, приводящее к
изменению состояния.
3. Что такое безусловный перехода
Безусловный переход осуществляется по причине выполнения всех видов дея-
тельности в данном состоянии, а не в ответ на какое-либо событие.
4. Чем отличаются последовательные и параллельные подчиненные состояния?
Подчиненные состояния относятся к одному более общему состоянию. По-
следовательные подчиненные состояния наступают по очереди, а параллель-
ные — одновременно.
9-й час
1. Дайте определение синхронным и асинхронным сообщениям.
При передаче объектом синхронного сообщения он ожидает ответа и, получив
его, продолжает выполнение своих действий. При передаче асинхронного со-
общения объект не ждет ответа.
Приложение А. Ответы
361
2. Что такое фрагмент взаимодействия в UML 2.0?
Фрагмент взаимодействия — это часть диаграммы последовательностей.
3. Что означает в UML 2.0 оператор par?
Оператор par означает параллельное использование фрагментов взаимодействия.
4. Как на диаграмме последовательности представляется вновь созданный объект?
Вновь созданный объект отображается в виде обычного именованного прямо-
угольника, смещенного по линии жизни к моменту его создания. При этом
возле соответствующей линии со стрелкой можно отразить передачу сообще-
ния создать () или стереотип <<создать>>.
10-й час
1. Как представить сообщение на диаграмме коммуникации?
С помощью стрелки, помещенной вблизи линии ассоциации, связывающей
два объекта. Направление стрелки указывает на объект, к которому обращаются.
2. Как на диаграмме коммуникации представить последовательную информацию?
К метке сообщения можно присоединить порядковый номер. Этот номер со-
ответствует порядку передачи сообщений.
3. Как представить изменения состояния?
Один способ состоит в добавлении к объекту атрибута, описывающего состоя-
ние. Свяжите объект с его копией. В копии объекта задайте значение атрибу-
та, соответствующее новому состоянию. Рядом с линией связи поместите мет-
ку <<становится>>. Сообщение должно передаваться от исходного состояния
к новому.
Есть еще один способ. Внутри прямоугольника объекта можно указать его со-
стояние рядом с именем объекта. Добавьте копию объекта и покажите изме-
нение состояния. Соедините объекты пунктирной линией со стрелкой, указы-
вающей на измененное состояние. Пометьте линию связи стереотипом
<<становится>>.
4. Что подразумевается под “семантической эквивалентностью двух типов диа-
грамм”?
Эти два типа диаграмм представляют одну и ту же информацию и их можно
преобразовывать друг к другу.
11-й час
1. Назовите два способа описания точки принятия решений.
Первый способ заключается в использовании маленького ромбика, из кото-
рого выходят возможные пути. Второй способ позволяет просто указать воз-
можные пути развития событий после завершения данного вида деятельности.
В любом случае возле каждой ветви в квадратных скобках можно поместить
требуемое условие.
2. Что такое “плавательная дорожка”?
На диаграммах видов деятельности “плавательная дорожка” позволяет указать
виды деятельности, связанные с определенной ролью.
362
Часть IV. Приложения
3. Как описать передачу и получение сигнала?
Выпуклый пятиугольник символизирует исходящее событие, а вогнутый мно-
гоугольник — входящее.
4. Что такое действие?
Действие — это компонент вида деятельности.
5. Что такое узел объекта?
Узел объекта — это фрагмент информации, представляющий вход или выход
вида деятельности. В UML 2.0 на диаграммах видов деятельности зачастую
представляют и объекты.
6. Что такое маркер?
Маркер — это узел объекта для определенного действия.
12-й час
1. В чем разница между компонентом и артефактом?
Компонент — это модульная, заменяемая часть системы. Компоненты опреде-
ляют функциональность системы. Артефакты — это фрагменты информации,
которые система использует или создает.
2. Назовите два способа представления связи между компонентом и его интер-
фейсом.
Интерфейс можно представить в виде прямоугольника (как класс), а связь с
компонентом — в виде пунктирной линии со стрелкой, направленной к ин-
терфейсу (обычное отношение реализации). Интерфейс можно изобразить
также в виде маленького кружка, соединенного с компонентом сплошной ли-
нией.
3. Что такое экспортируемый интерфейс! Что такое импортируемый интерфейс!
Экспортируемый интерфейс — это интерфейс, который компонент предостав-
ляет для доступа службам другого компонента. Для компонента, который
пользуется таким доступом, этот интерфейс называется импортируемым.
13-й час
1. Как изображается узел на диаграмме развертывания?
На диаграмме развертывания узел представляется в виде куба.
2. Информацию какого характера можно добавлять к изображению узла?
К изображению узла можно добавить его имя, имя пакета, а также имена раз-
вернутых на нем компонентов.
3. Как работает сеть с кольцевой архитектурой?
В кольцевой сети с маркерным доступом компьютеры подсоединяются к уст-
ройствам множественного доступа (MSAU), соединенным в кольцо. MSAU-
устройства используют сигнал, называемый маркером. Маркер идентифициру-
ет компьютер, который может передавать информацию в любой момент.
Приложение А. Ответы
363
14-й час
1. Что такое метамодель?
Метамодель — это модель, определяющая язык описания модели.
2. Что такое классификатор?
Классификатором является любой элемент, который описывает структуру и
поведение.
3. Почему так важно иметь возможность расширения UML?
При использовании UML для моделирования реальных систем можно ока-
заться в гораздо более сложной и неоднозначной ситуации по сравнению с
примерами, приводимыми в различных книгах. Если вы способны расширить
язык UML, то сможете лучше отразить природу моделируемой предметной
области.
4. Что собой представляют механизмы расширения UML?
Механизмами расширения UML являются стереотипы, ограничения и тегиро-
ванные значения.
15-й час
1. Что обычно интересует клиента?
Правильно ли понимает группа разработчиков стоящую проблему? Понимают
ли члены этой группы видение клиентом путей ее решения? Каких результа-
тов клиент ожидает от разработчиков? Какие виды отчетности должен предос-
тавлять менеджер проекта? Можно ли в любой момент времени определить,
насколько далеко продвинулись разработчики?
2. Что подразумевается под методикой разработки?
Методика разработки определяет структуру и характер шагов, выполняемых в
ходе реализации проекта.
3. Что собой представляет каскадный метод разработки? В чем его недостатки?
Каскадный метод разработки заключается в том, что анализ, проектирование,
программирование и развертывание следуют друг за другом.
4. Что такое сегменты GRAPPLE?
Процесс GRAPPLE включает следующие сегменты: выяснение набора требо-
ваний, анализ, проектирование, разработка и развертывание.
5. Что такое сеанс JAD?
В сеансе (семинаре) JAD участвуют представители организации заказчика,
принимающие решения, потенциальные пользователи и члены коллектива
разработчиков. В некоторых семинарах JAD участвуют члены группы разра-
ботки и обычные пользователи будущей системы.
16-й час
1. Какая диаграмма UML больше всего подходит для моделирования бизнес-
процесса?
364
Часть IV. Приложения
Для моделирования бизнес-процессов можно воспользоваться диаграммой ви-
дов деятельности.
2. Как модифицировать эту диаграмму, чтобы с ее помощью описать роли дейст-
вующих лиц?
Диаграмму видов деятельности можно преобразовать в диаграмму с
“плавательными дорожками”. Каждая из дорожек связана с ролью определен-
ного действующего лица бизнес-процесса.
3. Что означает термин “бизнес-логика”?
Бизнес-логика — это набор правил из предметной области, выполняемых в
определенных ситуациях.
17-й час
1. Как использовать существительные из интервью с экспертом?
Существительные впоследствии используются в качестве имен классов и атри-
бутов.
2. Как использовать глаголы?
Глаголы используются в качестве имен операций и ассоциаций.
3. Что такое тернарная ассоциация?
Тернарная ассоциация имеет отношение к трем классам.
4. Как моделировать тернарную ассоциацию?
Тернарная ассоциация изображается путем соединения каждого класса с ром-
биком. Имя ассоциации размещается возле этого ромбика. Значения кратно-
сти определяют количество экземпляров двух классов, ассоциированных с за-
данным числом экземпляров третьего класса.
18-й час
1. Как описываются системные требования?
Для представления системных требований используется диаграмма пакетов
UML вместе с прецедентами.
2. Прекращается ли моделирование классов после анализа предметной области?
После анализа предметной области процесс моделирования классов продолжа-
ется.
3. Что такое “фактор пробежек”?
Эта фраза прозвучала в отношении обслуживающего персонала, вынужден-
ного ходить по различным помещениям ресторана. Просто хотелось прове-
рить, насколько вы внимательны.
19-й час
1. Из каких частей состоит типичная диаграмма прецедентов?
Приложение А. Ответы
365
На типичной диаграмме прецедентов помещается обозначение самих преце-
дентов, инициирующий исполнитель, а также действующее лицо, которое ис-
пользует результаты прецедента.
2. Что означает для прецедентов отношение «включает»?
Отношение «включает» означает, что один прецедент содержит шаги дру-
гого.
20-й час
1. Как на диаграмме последовательностей изображается объект, созданный в
процессе выполнения шагов прецедента?
Создаваемый объект располагается ниже уровня остальных объектов. Ясность
диаграммы можно повысить, добавив стереотип «создает» к сообщению,
направляемому этому объекту.
2. Как на диаграмме последовательностей отражается время?
Ось времени направляется сверху вниз.
3. Что такое “линия жизни”?
Линия жизни — это пунктирная линия, идущая вниз от каждого объекта. Она
представляет существование объекта во времени.
4. Как на диаграмме последовательностей изобразить точку активации, и что она
описывает?
Маленький прямоугольник на линиях жизни называется точкой активации.
Она описывает период времени, в течение которого объект выполняет опера-
цию.
21-й час
1. В чем состоит анализ заданий?
Анализ заданий — это анализ, который проектировщик интерфейса выполняет
для понимания сути работы пользователя.
2. Какой из уже выполненных видов анализа больше всего соответствует анализу
заданий?
Анализу заданий приблизительно соответствует анализ прецедентов.
3. Что представляет собой дизайн в стиле “клоунских штанов”?
Под дизайном в стиле “клоунских штанов” подразумевается использование
компонентов различных размеров, разнообразия цветов и шрифтов.
4. Назовите три причины для ограничения использования цветов в GUI.
Ограничение использования цветов в GUI-интерфейсе обусловлено тремя
следующими причинами.
Пользователю не всегда легко ассоциировать цветом с содержанием.
Чрезмерное множество цветов будет отвлекать пользователя от выполняе-
мых им задач.
Некоторые пользователи плохо различают цвета, поэтому им сложно отли-
чить один цвет от другого.
366
Часть IV. Приложения
22-й час
1. Как представить параметризированный класс?
Для обозначения параметризованного класса используется символ обычного
класса, на правый верхний угол которого наложен небольшой прямоугольник.
Этот прямоугольник состоит из пунктирных линий.
2. Что такое связывание и какие существуют его типы?
Связывание — это присваивание значения параметру. Связывание может быть
явным и неявным.
3. Что такое шаблон проектирования?
Шаблон проектирования — это проверенное решение типичной задачи. Шаб-
лон может оказаться полезным в различных ситуациях. На языке UML шаб-
лон можно представить как параметризованную диаграмму кооперации.
4. Что представляет собой шаблон проектирования Цепочка обязанностей?
Шаблон Цепочка обязанностей определяет взаимосвязь между набором объ-
ектов и запросом. При этом клиентский объект инициирует запрос и передает
его первому объекту цепочки. Если этот объект не может обработать запрос,
то он передает его следующему объекту цепочки. Так происходит до тех пор,
пока один из объектов не выполнит запрос.
23-й час
1. Что такое встроенная система?
Встроенной называется компьютерная система, находящаяся внутри уст-
ройств, например бытовых.
2. Что такое асинхронное событие?
Событие является асинхронным, если нельзя предсказать момент, когда оно
произойдет.
3. Что такое строгая и нестрогая система в терминах встроенных систем?
Строгая система должна завершить выполнение задачи точно в срок, а от не-
строгой системы этого не требуется.
4. Как работает ядро с приоритетным прерыванием?
При использовании ядра с приоритетным прерыванием после завершения ра-
боты ISR центральный процессор не возвращается обратно к прерванному
процессу, если один из процессов в состоянии готовности имеет более высо-
кий приоритет. Вместо этого центральный процессор выполняет задачу с бо-
лее высоким приоритетом.
24-й час
1. В чем преимущества разработанной выше модели GUI?
Разработанная модель позволяет отслеживать эволюцию пользовательского
интерфейса и уделять внимание прецедентам, связанным с каждой копией эк-
рана.
2. Из каких компонентов состоит экспертная система?
Приложение А. Ответы
367
Компонентами экспертной системы являются база знаний, рабочая область и
механизм логического вывода.
3. Какие возможности экспертной системы отражает построенная диаграмма?
На построенной диаграмме показаны части правил, правила вывода и их
взаимосвязь с правилами.
368
Часть IV. Приложения
Приложение Б
Использование средств моделирования,
поддерживающих язык UML
В процессе выполнения упражнений по этой книге для создания диаграмм можно
воспользоваться карандашом и бумагой. Однако при моделировании в рамках реаль-
ного проекта такой подход слишком неэффективен. Помимо хлопот, связанных с ри-
сованием линий, кругов, эллипсов и прямоугольников, возникнут проблемы при их
перемещении и изменении уже завершенных диаграмм.
К счастью, именно в этот момент на помощь приходят современные технологии.
В настоящее время имеется большое количество средств, помогающих строить модели
UML.
Какие возможности предоставляют
средства моделирования
Одной из отличительных особенностей средств моделирования являются палитры
элементов UML. Выбрав и перетащив мышью требуемый элемент палитры в область
рисования, можно создавать различные диаграммы. Создайте связь между двумя эле-
ментами, и с этого момента она будет настраиваться в соответствии с перемещением
этих элементов по экрану.
Другая особенность пакетов моделирования заключается в возможности использо-
вания диалоговых окон редактирования. То есть, если нужно модифицировать какой-
то из элементов диаграммы, можно открыть соответствующее диалоговое окно и вве-
сти требуемые параметры в его поля. Отсюда следует одно важное свойство. Оно за-
ключается в том, что модель, построенная с использованием специализированного
программного пакета, состоит не только из самих диаграмм. Большое количество ин-
формации содержится также и за их “пределами”. Доступ к этим данным и можно
получить через диалоговые окна.
Еще одно преимущество заключается в гибкости форматирования. Для этого дос-
таточно просто в ранее созданных диаграммах перетащить мышью требуемые элемен-
ты в новое положение на экране.
Возможно, самым важным отличительным свойств средств моделирования являет-
ся словарь. В нем содержатся записи обо всех созданных элементах и их свойствах.
Кроме отслеживания информации о создаваемых элементах словарь позволяет также
повторно использовать их в новых диаграммах. Другими словами, если вы создали
класс для одной диаграммы, то его можно использовать еще раз, выбрав соответст-
вующий элемент в словаре и перетащив его на другую диаграмму.
И, наконец, некоторые профессиональные (и, как следствие, дорогостоящие) сред-
ства моделирования на основе построенных моделей позволяют генерировать про-
граммный код. В частности, к таким пакетам относится Together, недавно приобре-
тенный компанией Borland, и Poseidon, программный продукт компании Gentleware.
В оставшейся части этого приложения будет подробно рассмотрено одно из совре-
менных средств моделирования — Microsoft Visio Professional Edition. Если у вас уже
есть опыт по его использованию, он окажется весьма полезным, если же практиче-
ские навыки у вас отсутствуют, то большую часть требуемой информации вы сможете
найти ниже.
Использование UML в Visio Professional
Edition
Visio Processional Edition — одно из хорошо известных средств построения диа-
грамм, которое позволяет достаточно строго выполнять все действия, связанные с мо-
делированием. Обозначения UML представляют собой лишь одну нотацию, которая
поддерживается в этом программном продукте.
В данном разделе будет рассмотрено построение с использованием Visio Profes-
sional Edition диаграмм классов, объектов и последовательностей. Представленный ма-
териал позволит лучше познакомиться с отличительными особенностями этого про-
граммного продукта компании Microsoft.
Для начала рассмотрим уже построенную диаграмму нашей солнечной системы.
Поскольку основная цель данного приложения заключается в рассмотрении основных
возможностей средств моделирования, а не самого языка UML, представленная диа-
грамма является достаточно простой.
Поскольку наша планетарная система является экземпляром планетарной системы
как таковой, рассмотрим соответствующую диаграмму классов, показанную на
рис. Б.1.
На рис. Б.2 представлена диаграмма объектов Земли и Солнца. При желании на
эту диаграмму можно добавить и другие планеты солнечной системы.
На диаграмме последовательности (рис. Б.З) показано одно сообщение, передан-
ное от Солнца Земле (не забывайте о том, что рассматриваются чрезвычайно простые
модели).
370
Часть IV. Приложения
Рис. Б. 1. Диаграмма классов планетарной системы
Рис. Б.2. Диаграмма объектов Земли и Солнца
earth:HabitablePlanet
theSun:Star
Рис. Б.З. Диаграмма последовательности, на
которой представлено взаимодействие между
Солнцем и Землей
Приложение Б. Использование средств моделирования, поддерживающих язык UML 371
Итак, начнем
На рис. Б.4 показано основное диалоговое окно Visio, готовое для моделирования
на языке UML. Для рисования предназначена большая белая область. Доступ к слова-
рю Visio можно получить с помощью панели Model Explorer (слева вверху). Под ней
расположена панель элементов UML Shapes с несколькими вложенными страницами.
На каждой такой странице содержатся пиктограммы, соответствующие определенной
диаграмме UML. При запуске Visio в режиме моделирования на языке UML всегда
отображается страница UML Static Structure. С помощью пиктограмм этой страницы
можно строить диаграммы классов и объектов.
'Не?' Insert Format Tools Shape фй. g£ndo* ЦЫр 'ми zm»sc-f г_ dF X
I D ’ &,й (< £i ’ Ф Щб-9 - A ’ -1 О -
4 C) Ё ||E0 |Е§ ® E w ' \ ' ' ' -' 4 ' ' ' - '
f>todelExplorer OX:;/
UML System 1 I
ig ^3 Stott Model
ЙЭ TopFadcape h
C++ Data Types Ь.
\ SB- G) IDL Data Types t
l(B-G] VB Data Types t
Shapes _ ~ о. X i
j a UML Activity_________
iSUWL<oW^>oration
§UMLCmpcngtt_________________
fQu^Oepfevnent
;§(Ж5едиелсе . - - :
flSJUMLStatediart
iljlM. Static Stncture ;'j.
Рис. Б.4. Все готово для моделирования на языке UML
Диаграмма классов
Сначала нужно выбрать пиктограмму класса на странице UML Static Structure и пе-
ретащить ее в область рисования. При этом диалоговое окно Visio примет вид, пока-
занный на рис. Б.5.
После этого выделенному изображению класса нужно присвоить новое имя
PlanetarySystem (рис. Б.6).
При этом новые классы будут добавляться в словарь Visio (на панель Model
Explorer), как показано на рис. Б.7.
Теперь можно добавить класс Planet (рис. Б.8).
В этот класс добавим два атрибута и операцию (как на рис. Б.1) и сделаем класс
Planet абстрактным. Для этого нужно дважды щелкнуть на этом классе, чтобы от-
крылось диалоговое окно свойств UML Class Properties (рис. Б.9).
372
Часть IV. Приложения
Рис. Б. 5. Начало построения диаграммы классов
Рис. Б. 6. Переименование класса
Приложение Б. Использование средств моделирования, поддерживающих язык UML 373
Model ЕкрЬгег вМ; X
£b IM. System 1 j®
|&<j| Static Model Ш
• Ё -^21 Top Package Ш
;••• StaticStrucb-еЧ.»
L § PlanetarySystem
Рис. Б.7. Класс PlanetarySystem
добавлен на панель Model Explorer
Рис. Б.8. Добавление класса Planet
Рис. Б.9. Диалоговое окно свойств UML Class
Properties
Установите флажок IsAbstract и выберите в списке Categories элемент Attributes,
чтобы открыть в диалоговом окне таблицу Attributes (рис. Б. 10).
374
Часть IV. Приложения
Рис. Б. 10. Таблица Attributes для класса Planet
Введите в этой таблице имена атрибутов diameter и distanceFromStar. Затем
выберите в списке категорий элемент Operations, чтобы открыть соответствующую
таблицу. В этой таблице введите имя receiveLight, как показано на рис. Б. 11.
Рис. Б. 11. Таблица Operations для класса Planet
Щелкните на кнопке ОК, чтобы завершить добавление в класс Planet атрибутов и
операций (рис. Б. 12).
Обратите внимание на символ “минус” (-) слева от имени каждого атрибута и
символ “плюс” (+) слева от имени операции. Эти символы определяют видимость
членов класса. Для того чтобы “разгрузить” диаграмму, эти символы можно удалить.
Для этого щелкните правой кнопкой мыши на классе Planet для отображения на эк-
ране контекстного меню (рис. Б. 13).
Planet
>diameter
‘detanceFramStar
♦receiveLlghtn
Рис. Б. 12. Абстрактный класс
Planet с атрибутами и опе-
рациями
Приложение Б. Использование средств моделирования, поддерживающих язык UML 375
Рис. Б. 13. При щелчке правой
кнопкой мыши на экране по-
является контекстное меню
В появившемся меню выберите команду Shape Display Options, чтобы открыть диа-
логовое окно UML Shape Display Options (рис. Б. 14).
Рис. Б. 14. Диалоговое окно UML Shape
Display Options
Сбросьте флажок Visibility и щелкните на кнопке ОК, чтобы класс Planet принял
вид, как показано на рис. Б. 15. Если внимательно посмотреть на рис. Б. 14, то в ниж-
ней части диалогового окна можно заметить два флажка. С их помощью вносимые
изменения можно различным образом применять и к группе элементов диаграммы
классов.
Обратите внимание, что класс Planet вместе с атрибутами и операцией содержит-
ся в иерархии на панели Model Explorer (рис. Б. 16).
376
Часть IV. Приложения
^••<23 Top Padcage
| \..Static Structure-1 |
Pfanet
Ptonet
diameter
dtelarrceFromStar
race IveUghtO
..0 diameter |||
]- 0 cfctanceFromStar
..0 reoeiveLight
5
Рис. Б.15. Класс Planet
без отображения види-
мости его элементов
Рис. Б. 16. На панель
Model Explorer авто-
матически добавлены
атрибуты и опера-
ции класса Planet
Следующий шаг заключается в перетаскивании на диаграмму оставшихся классов
(рис. Б. 17).
Рис. Б. 17. Все классы модели
Конечно, это еще далеко не все. На диаграмму нужно добавить отношения компо-
зиции и наследования. Начнем с композиции. Перетащите соответствующую пикто-
грамму с панели Shapes в область рисования и соедините закрашенный ромб с обо-
значением класса PlanetarySystem, а другой конец связующего элемента — с клас-
сом Star (рис. Б. 18).
С каждым концом линии связи, обозначающей композицию, можно связать зна-
чение кратности, видимость и имя. Для того чтобы удалить с диаграммы значения по
умолчанию (-Endl и -End2), щелкните правой кнопкой мыши на линии связи и вы-
берите в контекстном меню команду Shape Display Options. В появившемся диалого-
вом окне свойств UML Shape Display Options сбросьте флажки First end name, Second
end name и End visibilities (рис. Б.19).
Приложение Б. Использование средств моделирования, поддерживающих язык UML 377
Рис. Б. 18. Добавление отношения композиции
Рис. Б. 19. Диалоговое окно UML Shape
Display Options со свойствами композиции
Теперь можно задать кратность отношения. Дважды щелкните на изображении
композиции, чтобы открыть диалоговое окно UML Association Properties (рис. Б.20).
В таблице Association Ends выберите имя End2 и щелкните в поле Multiplicity. Щел-
кая на стрелке появившегося раскрывающегося списка, можно выбрать требуемое
значение кратности. Для рассматриваемого примера выберите кратность 1 (рис. Б.21).
378
Часть IV. Приложения
Рис. Б. 20. Диалоговое окно UML Association
Properties
Рис. Б.21. Список возможных значений кратности
Поработав с отношением композиции еще, можно получить следующий фрагмент
(рис. Б.22). Теперь с классом PlanetarySystem связан и класс Planet. Обратите
внимание на то, что второе отношение композиции уже имеет кратность один ко
многим (*).
И, наконец, на диаграмму осталось добавить отношения наследования. Найдите на
панели Shapes соответствующий элемент обобщения и перетащите его в область ри-
сования. Соедините стрелку соединительной линии с классом Planet, а ее второй
конец — с классом HabitablePlanet. Аналогичным образом соедините классы
Planet и NonHabitablePlanet. В результате диаграмма классов примет вид, как по-
казано на рис. Б.23.
Однако, как уже упоминалось выше, при построении диаграмм с помощью про-
граммы моделирования информация содержится не только в самой диаграмме. Ее не-
видимую часть можно найти также и в диалоговых окнах. Сейчас вы узнаете об этом
немного больше. При двойном щелчке на изображении класса HabitablePlanet на
экране появится диалоговое окно UML Class Properties. При выборе в списке
Categories элемента Attributes откроется таблица Attributes, как показано на рис. Б.24.
Приложение Б. Использование средств моделирования, поддерживающих язык UML 379
Рис. Б. 22. Два отношения композиции
Рис. Б. 23. Завершенная диаграмма классов
В нижней части таблицы Attributes можно заметить вкладку. Это свидетельствует о
том, что в данный момент активной является страница с атрибутами класса
HabitablePlanet. Конечно, эта страница сейчас пуста, поскольку для класса не бы-
ли заданы никакие атрибуты. Однако класс HabitablePlanet наследует атрибуты
класса Planet, и в таблице их можно увидеть. Как легко заметить, вкладки таблиц
можно прокручивать. Если воспользоваться этой возможностью, легко найти соответ-
380
Часть IV. Приложения
ствующую вкладку для класса Planet. При щелчке на ней можно просмотреть стра-
ницу с атрибутами (рис. Б.25).
Таким образом, если в диаграмме классов используется отношение наследования,
то в соответствующих диалоговых окнах можно найти атрибуты, наследуемые от дру-
гих классов. (В Visio то же самое можно проделывать и для операций.)
Рис. Б.24. Таблица Attributes для класса
HabitablePlanet
Рис. Б.25. Таблица атрибутов класса Planet, от-
крытая в диалоговом окне свойств класса
HabitablePlanet
Диаграмма объектов
Для того чтобы приступить к созданию диаграммы объектов, щелкните правой
кнопкой мыши на элементе Top Package панели Model Explorer. В появившемся кон-
текстном меню можно выбрать команду создания новой статической диаграммы
UML. На странице UML Static Structure панели Shapes выберите пиктограмму Object и
перетащите ее в область рисования. На рис. Б.26 показано, как после проделанных
действий будет выглядеть область рисования.
Приложение Б. Использование средств моделирования, поддерживающих язык UML 381
Рис. Б.26. Область рисования после добавления пиктограммы но-
вого объекта
После двойного щелчка на изображении объекта на экране появится диалоговое
окно UML Object Properties (рис. Б.27).
В поле Name введите имя the Sun, чтобы заменить используемое по умолчанию
имя Objectl. Необходимо также указать, что объект theSun является экземпляром
класса star. Для этого перейдите в поле Class диалогового окна UML Object Properties и
в появившемся раскрывающемся списке выберите имя требуемого класса (рис. Б.28).
Рис. Б.27. Диалоговое окно свойств UML Object
Properties
Выберите в списке класс star и щелкните на кнопке ОК. Объект будет выглядеть
так, как показано на рис. Б.29.
382
Часть IV. Приложения
Рис. Б. 28. Диалоговое окно свойств UML Object
Properties с измененным именем объекта и раскры-
тым списком классов
theSun: Star
Рис. Б. 29. Переименованный объект,
на изображении которого указан со-
ответствующий класс
После этого аналогичные действия следует проделать и для создания объекта
earth. На рис. Б.30 показано диалоговое окно UML Object Properties после изменения
имени класса по умолчанию и выбора соответствующего класса.
Рис. Б. 30. Диалоговое окно UML Object Properties
после изменения имени объекта и выбора класса
При выборе элемента Attribute Values в списке Categories в диалоговом окне поя-
вится таблица Attribute values. В этой таблице можно ввести значения для атрибутов
diameter И distanceFromTheStar, которые унаследованы ОТ класса Planet
(рис. Б.31). Имейте в виду, что вы не сможете то же самое сделать для класса
HabitablePlanet, поскольку на диаграммах классов лишь определяются отношения
наследования (за этим “следит” программа моделирования).
Приложение Б. Использование средств моделирования, поддерживающих язык UML 383
Рис. Б.31. Задание значений для атрибутов объектов
Как видно из приведенного рисунка, в столбце Value заданы значения 8, 000 и
93, 000, 000. После щелчка на кнопке ОК объект earth будет выглядеть следующим
образом (рис. Б.32).
earth: HabitablePlanet
Летаии = $.000
distencaPromStar • 93,000,000
Рис. Б.32. Объект earth с задан-
ными значениями для атрибутов
В завершение осталось добавить между двумя объектами связь. Перетащите в об-
ласть рисования требуемую пиктограмму с панели UML Static Structure и соедините с
ее помощью оба объекта. По умолчанию концы линии будут именованы как Endl и
End2. Однако можно щелкнуть правой кнопкой мыши на связи, выбрать в контекст-
ном меню команду Shape Display Options и в появившемся диалоговом окне внести
требуемые изменения. Законченная диаграмма объектов представлена на рис. Б.33.
Диаграмма последовательности
Как и в прошлый раз, щелкните правой кнопкой мыши на элементе Top Package
панели Model Explorer и выберите в контекстном меню команду создания новой диа-
граммы. После этого откройте страницу UML Sequence панели Shapes.
Перетащите пиктограмму Object Lifeline в область рисования. Основное окно Visio
будет выглядеть следующим образом (рис. Б.34).
Как и при построении диаграммы объектов, нужно переименовать пиктограмму и
указать требуемый класс. Для этого дважды щелкните на ней, чтобы открылось диа-
логовое окно UML Classifier Role Properties (рис. Б.35).
После переименования объекта в поле Name и выбора соответствующего класса в
раскрывающемся списке Classifier диалоговое окно UML Classifier Role Properties будет
выглядеть следующим образом (рис. Б.36).
384
Часть IV. Приложения
Рис, Б.ЗЗ. Завершенная диаграмма объектов
Рис, Б.34, Построение диаграммы последовательности начните с
перетаскивания в область рисования пиктограммы Object Lifeline
Приложение Б. Использование средств моделирования, поддерживающих язык UML 385
Рис. Б. 35. Диалоговое окно UML Classifier Role
Properties
Рис. Б. 36. Диалоговое окно UML Classifier Role
Properties после переименования объекта и выбора
класса
После щелчка на кнопке ОК пиктограмма Object Lifeline в области рисования будет
иметь следующий вид (рис. Б.37).
ф IbeSun ф
I
I
I
I
I
Ь
Рис. Б.37. Пиктограмма Object
Lifeline с именем объекта и класса
Щелкнув правой кнопкой мыши и выбрав в контекстном меню команду Shape
Display Options, можно отобразить на диаграмме также имена классов. После выпол-
нения аналогичных действий для объекта earth диаграмма последовательности при-
мет вид, как на рис. Б.38.
386
Часть IV. Приложения
1-1«
^1§Q 0е git" JJw Insert Format loots i?»pe. UH- ijjndow, tteti " > * ^'yr' fi *>w? - -
i d * & я & ..ef а-й V Ц^ж^И x»л.жЩн4л4р4 zm> 4'«»* ?. t© -,.
iOfigBj'fi, 4 '' '\' ?' /\<''-?'/'*' '\' --
>••• ••<••• < .'.>•>>' ' •‘‘f. *. *........ — * .Pillai II ! »' M .....”
Model Explorer .- -;С.-:Л jC'.
>Л/»>|Ц<*<ЛГГ"<<|<*Г*1 >«W«. *»•»«***'***•>>*. >*,£•£
•Й ££3 Tap Package
•?d Static Structure'1
? '^Й Sbfc Structure-! О
: ; U SSsqiie^i*!:
i j- -g HabitabWtenet
I t § htonHabMbtebnet i
i Й @ Pianet W
Ш иммщ
'heSun: Star
tarth;Hrtfrtwasn£i
i^UMStatedwt" ч
?@lJ№^te*Stnii^ ill
.......V.'.Vi ..'•‘a. "•«a..'*.. .‘r.Va'.f.l'i *. .Wa*A'PkV<<*a.‘r^./.'.V^
“__________--- > -
Рис. Б.38. Два изображения Object Lifeline с именами объектов и
классов
Теперь пришло время для добавления на диаграмму последовательности сообще-
ний, передаваемых между объектами theSun и earth. Выберите пиктограмму
Message на странице UML Sequence панели Shapes, перетащите ее в область рисова-
ния и соедините с ее помощью линии жизни объектов theSun и earth. При этом
стрелка должна быть направлена к объекту earth (рис. Б.39).
t®| 0® - fity J9e*< Insert - Fgrmet, Joofe 9®?® !?<• ' = ^x'4 X
>o’g?нй£!фаVI£ j*0;rx\;®?a-vc- /-e;;ио%\।-
: й ![Щ® ® я , ' \ ( , s, ; 1';V ‘ ,
МмЫ ЕхрЬгег Q X
IS-Is Top Pedage rf(
| -Яр Static Structured
j Static Structize-2 O:
i :f(Sequence-l Я:
! - g HabitabtePianet
> -• @ NonHabtiablePtenet (
| » @ Planet
h; ggiga«^
Shapes a X
/_________jj
i @UMtCofaborat»n ' , <i
>...... *<y*"\t r«rrr>^'
UK Component '_______. j;
iheSwvStar
I
I
I
I
I
Mm eage 1
i
t
i
I
«MLLHa^Sa^sElanfii
i
Рис. Б.39. Соединение двух линий жизни на диаграмме последова-
тельности
Приложение Б. Использование средств моделирования, поддерживающих язык UML 387
Для того чтобы изменить метку, используемую по умолчанию, дважды щелкните
на пиктограмме сообщения и откройте диалоговое окно UML Message Properties
(рис. Б.40).
Рис. Б.40. Диалоговое окно UML Message Properties
Поскольку в соответствующем классе ранее была определена лишь одна операция,
то в диалоговом окне UML Message Properties будет автоматически выбрано имя сооб-
щения (в поле Name). (Если бы в классе было задано больше операций, то при по-
строении диаграммы последовательности в соответствующем раскрывающемся списке
можно было бы выбрать любую из них.) После щелчка на кнопке ОК диаграмма при-
мет вид, показанный на рис. Б.41.
Рис. Б.41. Переименованное сообщение, связывающее две линии
жизни
После выбора и перетаскивания пиктограммы Activation диаграмма последователь-
ности примет полностью завершенный вид (рис. Б.42).
388
Часть IV. Приложения
Рис, Б.42. Завершенная диаграмма последовательности
Другие средства моделирования
В данном разделе очень кратко рассматриваются хорошо известные программные
средства, которые уже давно активно применяются для моделирования. В момент вы-
хода этой книги все эти приложения по-прежнему поддерживали только стандарт
UML 1.x.
Rational Rose
И в настоящее время пакет Rational Rose является “золотым” стандартом в мире
средств моделирования на языке UML. Этот пакет представляет собой программный
продукт, который был разработан компанией, созданной тремя создателями языка
UML1. Не так давно Rational Rose был приобретен компанией IBM и стал называться
IBM Rose XDE Modeler. Сейчас с его помощью можно проводить моделирование в
самых разнообразных контекстах, например проектировать базы данных, использовать
совместно с Microsoft Visual Studio или применять в процессе разработки программ-
ных систем на Java. Для получения более подробной информации об этом пакете об-
ращайтесь по адресу http://www.ibm.com/rational.
Select Component Architect
Эта программная система представляет собой обновленную и расширенную вер-
сию пакета Select Enterprise, который по праву считается одним из первых средств мо-
делирования на языке UML. Об этом пакете рассказывалось в предыдущих изданиях
этой книги. Component Architect предназначен для разработки программных систем
на основе повторно используемых компонентов, поэтому в его состав входят соответ-
1 Имеются ввиду Буч, Румбах и Якобсон. — Прим. ред.
Приложение Б. Использование средств моделирования, поддерживающих язык UML 389
ствующие расширения UML. С помощью Component Architect можно также строить
диаграммы сущность-связь и проектировать базы данных.
Одним из направлений, активно развиваемых и поддерживаемых в программном
продукте Select Component, является компонентная разработка программных систем.
Более подробную информацию можно получить по адресу http: //www.selectbs.com.
Visual UML
Последней версией Visual UML является 3.2. Этот пакет по-прежнему чаще всего
выбирается для личного использования. В частности, многие диаграммы к первому
изданию этой книги были созданы именно с использованием Visual UML.
Диалоговые окна этого программного пакета очень просто использовать. После его
установки можно сразу приступать к построению диаграмм. Для получения более под-
робной информации о Visual UML обращайтесь по адресу http: //www. visualuml.com.
Там же можно найти и соответствующую пробную версию.
390
Часть IV. Приложения
Приложение В
Резюме в картинках
В этом приложении представлены ключевые аспекты каждой диаграммы языка
UML.
Диаграмма видов деятельности
392
Часть IV. Приложения
Рис. В. 2.
Передача сигнала
^^Получение сигнала
Рис. В.З.
Приложение В. Резюме в картинках
393
Диаграмма классов
ИмяКласса
атрибут: тип
/производныйАтрибут
операция()
АбстрактныйКласс
Ассоциация:
Кратность:
Имя роли
в ассоциации:
Ассоциация
с квалификатором:
Интерфейсы:
Рис. В. 4.
394
Часть IV. Приложения
Тернарная ассоциация:
Агрегация:
Композит:
Целое
Часть
---------------------1 Т 1
к J
ПараметризованныйКласс
Рис. В. 5.
Диаграмма коммуникации
Рис. В. 6.
Приложение В. Резюме в картинках
395
Диаграмма компонентов
I ИмяКомпонента
I I
UML1.X
UML2.0
Структурная композитная диаграмма
Класс!
Класс2
КлассЗ
Рис. В. 8.
396
Часть IV. Приложения
Диаграмма развертывания
Узел 1
Рис. В. 9.
Диаграмма объектов
Рис. В. 10.
Приложение В. Резюме в картинках
397
Диаграмма пакетов
Пакет!
Рис. В. 11.
Параметризованная диаграмма
взаимодействия
КлассА
Параметризованная
диаграмма кооперации
КлассВ
Рис. В. 12.
398
Часть IV. Приложения
Диаграмма последовательности
:Knacci I :Класс2 I I :КлассЗ
““h—i “
II I
II I
, Блок активации Рис. В. 13. Синхронное сообщение \ Обратное сообщение те .<<создает>> ' „ , . ;Класс4 1 1 1 1 1 1 1 1 1 1 1 1 1 । <<уничтожает>>^;
Приложение В. Резюме в картинках
399
Диаграмма состояний
Рис. В. 14.
Временная диаграмма
Состояние
Состояние
Состояние
:ИмяКласса
Рис. В. 15.
400
Часть IV. Приложения
Диаграмма прецедентов
Рис. В. 16.
Приложение В. Резюме в картинках
401
Предметный указатель
А
Actor, 29; 90
с
Chain of Responsibility, шаблон, 318
Composite
structure diagram, 36
шаблон, 321
CORBA, 207
G
Generalization, 99
GRAPPLE, процесс разработки, 224; 234; 249
Grouping, 99
I
IBM Rose XDE Modeler, 389
Inheritance, 46
Instance sequence diagram, 131
Interaction
diagram, 32
fragment, 137
к
Keyword, 35
L
Lifeline, 124
N
Note, 34
О
Object
Constraint Language (OCL), 61
Management Group (OMG), 26
p
Poseidon, 370
R
RAD, сегменты процесса GRAPPLE, 225
Rational
Rose, 389
Unified Process (RUP), 224
s
Select Component Architect, 389
Stereotype, 35
Timing diagram, 38
Together, 370
u
UML (Unified Modeling Language), 24; 26
структурные элементы, 108
Use case analysis, 90
V
Visio Professional Edition, 370
Visual UML, 390
w
Web Application Extension (WAE), 354
Web-приложение, 353
Абстрактный класс, 73
Абстракция, 46
Автомат состояний, 113
Агрегат, 52
Агрегация, 46; 52; 79
Активный
класс, 337
объект, 151
Анализ
бизнес-процесса, 235
интервью, 250
на основе прецедентов, 302
предметной области, 226; 265
прецедентов, 90; 228
Анонимный объект, 28
Ансамблевый коннектор, 183
Артефакт, 176
Архитектура UML, 205
Асинхронное
событие, 333
сообщение, 125
Ассоциация, 50; 66
п-арная, 256
рефлексивная, 71
тернарная, 255
часть-целое, 79
Атрибут, 27; 57; 372
Б
База знаний, 348
Базовый класс, 72
Безусловный переход, 115
Бизнес-логика, 106
Бизнес-процесс, 223; 226
Блок-схема, 755
Быстрое проектирование, 224
в
Вид деятельности, 755; 156
Видение, 269
системы, 20
Включение прецедента, 93
Временная диаграмма, 38; 400
Встроенная система, 331
г
Генерация программного кода, 370
Граница системы, 98
Графический
пользовательский интерфейс, 302; 346
стереотип, 218
Группирование, 99
д
Деструктор, 217
Диаграмма, 27
взаимодействия, 32
видов деятельности, 32; 155; 226; 392
временная, 38
классов, 27; 228; 250; 372; 394
коммуникации, 32; 142; 395
параметризованная, 318
композитная структурная, 36
композитов, 308
компонентов, 33; 178; 396
контекстная, 81
кооперации, 143
объектов, 28; 75; 229; 381; 397
пакетов, 39; 201; 280; 282; 398
последовательности, 30; 123; 384; 399
частная, 131
прецедентов, 28; 401
развертывания, 34; 189; 217; 397
состояний, 29; 113; 119; 400
начальная точка, 773
структурная композитная, 81
сущность-связь, 390
Фейнмана, 26
Динамический класс, 86
Дополнительный прецедент, 93
3
Завершающий узел, 167
Зависимость, 74; 181; 217
и
Иерархия наследования, 72
Импортируемый интерфейс, 178
Инкапсуляция, 48; 81; 177
Интерфейс, 35; 49; 82; 177; 216
Инфраструктура UML, 208
Исключение, 765
Исполнитель, 29; 90; 228
инициирующий, 97
к
Кадрирование, 735
Каскадный процесс разработки, 222
Квалификатор, 70
Класс, 27; 62; 315
абстрактный, 73; 252
активный, 337
ассоциации, 68
базовый, 72
динамический, 86
материализованный, 339
параметризованный, 376
полное имя, 56
статический, 86
Классификатор, 217
Ключевое слово, 35
Комментарий, 61
Композит, шаблон, 321
Композитная структурная диаграмма, 36
Композитное состояние, 118
Композитный объект, 81
Композиция, 52
Компонент, 776
Компонентная разработка, 390
Компонентный подход, 43
Предметный указатель
403
Коннектор делегирования, 183
Конструктор, 217
Контекстная диаграмма, 81
Кооперативная многозадачность, 334
Корневой класс, 72
Кратность, 378
ассоциации, 50; 69
л
Линия жизни объекта, 124; 297
м
Материализация, 339
Материализованный класс, 339
Метамодель, 205
Методика, 222
Механизм логического вывода, 348
Многозадачность, 332
Модель, 27
MOF, 207
прецедентов, 98
программных компонентов, 189
н
Наследование, 46; 71
Нестрогая система, 332
Неявное связывание, 317
о
Обзорная диаграмма взаимодействия, 37; 169
Область видимости, 85
Обобщение, 7/; 99
Обработчик исключения, 165
Обратный логический вывод, 350
Общая диаграмма последовательностей, 131
Объект, 28; 44; 315
активный, 151
композитный, 52
Объектно-ориентированная система, 24
Объектно-ориентированный подход, 43
Обязанность, 60
Ограничение, 60; 218
ассоциации, 67
Оператор, 135
Операция, 27; 44; 58; 372
сигнатура, 59
Организационная единица, 345
п
Пакет, 39; 56; 103; 201
понятий, 204
Палитра элементов UML, 369
Параметризированный класс, 316
Параметризованная диаграмма
взаимодействия, 398
Передача сообщений, 49
Переключающее событие, 115
Перечислимый тип, 58
План разработки, 25
Поведение системы, 112
Подкласс, 46
Подчиненное состояние, 116
Полиморфизм, 47
Полное имя, 56
Полностью определенное имя, 201
Порт, 85; 216
Постусловие, 90
Правило импликации, 348
Предметная область, 226
Предусловие, 90
Прерывание, 332
Прецедент, 28; 89; 97; 228; 282; 283
базовый, 100
дополнительный, 93
дочерний, 102
расширение, 95
Примечание, 34
Приоритет процесса, 332
Программа обслуживания прерываний, 333
Проектирование пользовательского
интерфейса, 302
Пространство имен, 201
Прототип пользовательского интерфейса, 229
Процесс разработки
GRAPPLE, 224
RUP, 224
каскадный, 222
с обратной связью между этапами работ,
224
Процессор, 190
Прямой логический вывод, 350
р
Рабочая
единица, 345
область, 348
Разработка системы, 25
Распределение обязанностей, 318
Расширение
UML, 216
для моделирования Web-приложений
(WAE), 353
Реализация, 177
Рефлексивная ассоциация, 71
Роль, 160
в ассоциации, 67
404
Предметный указатель
Свойство, 44
Связь, 68
Сегмент процесса GRAPPLE, 225
Сигнал, 158
Сигнатура
операции, 59
сообщения, 150
Синхронное сообщение, 124
Система, 25
объектно-ориентированная, 24
Скрытый получатель, 318
Словарь, 55; 370
модели, 264
Смешанная диаграмма, 160
Событие, асинхронное, 333
Сокрытие информации, 48; 177
Сообщение, 82; 124
Состояние, 113
композитное, 118
подчиненное, 116
Спецификация развертывания, 190
Средство
контроля версий, 231
моделирования, 370
Статический класс, 86
Стереотип, 55; 59; 216
графический, 218
для моделирования бизнес-процессов,
344
Строгая система, 332
Структурная композитная диаграмма, 396
Суперкласс, 46
Суперструктура UML, 214
Сущность, 345
Сценарий использования системы, 90
т
Тегированное значение, 218; 354
Тернарная ассоциация, 255
Тестирование программного обеспечения,
230
Точка
активации, 124; 297
доступа, 309
расширения, 100
соединения, 119
Узел, 189
объекта, 164
Унифицированный язык моделирования,
UML, 24
Уровень
метамодели, 205
модели, 205
моделирования метамодели, 205
пользовательских объектов, 205
Условие перехода, 116
Устройство, 190
Формулировка требований, 226; 235
Фрагмент взаимодействия, 137
Функция, 58
ч
Частная диаграмма последовательности, 131
ш
Шаблон
Композит, 321
проектирования, 317
Цепочка обязанностей, 318; 351
э
Экспертная система, 347
Экспортируемый интерфейс, 178
я
Явное связывание, 316
Ядро, 334
с приоритетным прерыванием, 334
Язык
OCL, 61
моделирования, 20
Предметный указатель
405
Научно-популярное издание
Джозеф Шмуллер
Освой самостоятельно UML за 24 часа,
3-е издание
Литературный редактор
Верстка
Художественный редактор
Корректоры
Ж.Е. Прусакова
А.Н. Полинчик
В.Г. Павлютин
З.В. Александрова, В.В. Смоляр
Издательский дом “Вильямс”.
101509, Москва, ул. Лесная, д. 43, стр. 1.
Подписано в печать 12.07.2005. Формат 70X100/16.
Гарнитура Times. Печать офсетная.
Усл. печ. л. 33,5. Уч.-изд. л. 24,6.
Тираж 3000 экз. Заказ № 2469.
Отпечатано с диапозитивов
в ФГУП “Печатный двор” им. А. М. Горького
Федерального агентства по печати
и массовым коммуникациям.
197110, Санкт-Петербург, Чкаловский пр., 15.