Uml Proektirovanie

ХассанГома
UML
Проектирование систем реального времени,
параллельных и распределенных приложений
Designing
Concurrent,
Distributed,
and Real-Time
Applications
with UML
Hassan Gomaa
▼V
Addison-Wesley
Boston * San Francisco • New York • Toronto • M ontreal
London • Munich • Paris • M adrid
Capetown • Sydney • Tokyo • Singapore • Mexico City
Серия «Объектно-
ориентированные технологии
в программировании»
г-
«!
UML
Проектирование
т М ЗХЛ
систем реального
времени,
параллельных
и распределенных
приложений
Хассан Гома
Издание второе
№
Москва, 2011
У Д К 004.415.2
ББК 32.973.26-018.1
Г64
Г64 ГомаХ.
UML. Проектирование систем реального времени, параллельных и распре
деленных приложений: Пер. с англ. - М.: ДМ К Пресс, 2011. - 704 с.: ил.
(Серия «Объектно-ориентированные технологии в программировании»).
ISBN 9785-94074-723-9
Данная книга описывает процесс создания распределенных, параллель

ных систем и систем реального времени с точки зрения проектирования
архитектуры системы. Подробно рассмотрены ключевые вопросы, возника
ющие в процессе разработки: управление временем отклика, синхрониза
ция, актуальность и непротиворечивость данных. На многочисленных при
мерах автор показывает, как с помощью одной и той же универсальной
нотации UML описать такие, казалось бы, далекие области, как автомати
зированная банковская система, бортовой компьютер автомобиля и систе
ма управления лифтами в многоэтажном здании - без привязки к какой-
либо программной или аппаратной платформе и языку программирования.
Издание будет чрезвычайно полезно аналитикам, менеджерам предпри
ятий и информационных систем, руководителям и архитекторам проектов,
а также программистам, которые имеют дело с приложениями UML: книга
поможет изложить свои идеи так, чтобы можно было реализовать проект,
практически не зная той предметной области, для которой пишется система.
Translation copyright - by DMK Press

(D esigning Concurrent, D istributed, and Real-time Applications with UML, First
Edition by Hassan Gomaa, Copyright, All Rights Reserved)
Публикуется по согласованию с издательством, выпустившим оригинал: ADDISON-

WESLEY LONGMAN, Pearson Education Inc.
Все права защищены. Любая часть этой книги не может быть воспроизведена в какой бы то
ни было форме и какими бы то ни было средствами без письменного разрешения владельцев
авторских прав.
Материал, изложенный в данной книге, многократно проверен. Но, поскольку вероятность
технических ошибок все равно существует, издательство не может гарантировать абсолютную
точность и правильность приводимых сведений. В связи с этим издательство не несет ответ
ственности за возможные ошибки, связанные с использованием книги.
ISBN 0-201-65793-7 (англ.) Copyright © by Hassan Gomaa

ISBN 9785-94074-723-9 (рус.) © Перевод на русский язык, оформление
ДМ К Пресс, 2011
С в д е р ж а м и е
Предисловие ....................................................................................... 25
ЧАСТЬ I. Нотация UML, концепции проектирования,

технологии, жизненные циклы и м етоды ..... 35
Г л а в а 1. В в е д е н и е ............................................................................................ 36
1.1. Объектно-ориентированные методы и UML ............................. 37
1.2. Метод и нотация .............................................................................38
1.3. Параллельные приложения ......................................................... 38
1.3.1. Последовательные и параллельные программы .................................39
1.3.2. Последовательные и параллельные приложения ............................... 39
1.3.3. Параллельные задачи ............................................................................ 40
1.4. Системы и приложения реального времени ............................. 40
1.5. Распределенные системы и приложения ................................. 42
1.6. Резюме .......................... .................. .............................................. 43
Глава 2. О б з о р н о т а ц и и U M L ..........................................................44
2.1. Диаграммы UML ............................................................................44

2.2. Диаграммы прецедентов ............................................................. 45
2.3. Нотация UML для классов и объектов ..................... ..................45
2.4. Диаграммы классов ........ ....................................... .................... 46
2.5. Диаграммы взаимодействия .......................................................47
2.5.1. Диаграммы кооперации ........................................................................ 47
2.5.2. Диаграммы последовательности ..................................................48
2.6. Диаграммы состояний ................................................................. 48
2.7. Пакеты .............................................................................................50
2.8. Диаграммы параллельной кооперации ......................................51
2.8.1 . Обмен сообщениями на диаграммах параллельной кооперации .... 51
2.9. Диаграммы развертывания......................................................... 51
2.10. Механизмы расширения UML ...................................................53
■ ■ ■ 1 - UM L Проектирование систем
2 .1 1 . U M L как с т а н д а р т .....................................................................................54
2 .1 2 . Р е зю м е ......................................... ..... ............ .............. ......................... 55
Г лава 3. К о н ц е п ц и и п р о е к ти р о в а н и я
П О и а р х и т е к т у р ы .........................................................................56
3 .1. О б ъ е к тн о -о р и е н ти р о в а н н ы е к о н ц е п ц и и ......................................... 56
3.1.1. Основные концепции ..............................................................................56
3.1.2. Объекты и классы ................................................................................... 57
3 .2 . С о кр ы ти е и н ф о р м а ц и и ............................................................................58
3.2.1. Сокрытие информации
в объектно-ориентированном проектировании .................................. 59
в применении к внутренним структурам данных ................................. 59
3.2.3. Сокрытие информации при проектировании интерфейса
с устройствами ввода/вывода ............................................................... 62
3.2.4. Проектирование объектов, скрывающих информацию ................. 63
3 .3. Н а с л е д о в а н и е .......................... ..................... ............................................ 64
3 .4 . А к ти в н ы е и п а с с и в н ы е о бъ екты .......................................................... 65
3 .5 . П ар ал л ел ьн ая о б р а б о тк а ............. ..........................................................66
3.5.1. Преимущества параллельного выполнения задач ................... ........66
3.5.2. Тяжеловесные и облегченные процессы ................. .......... ..................67
3 .6 . К о о п е р а ц и я м е ж д у п а р ал л ел ьны м и за д а ча м и ............................. 68
3.6.1. Проблема взаимного исключения ........................................................ 68
3.6.2. Пример взаимного исключения ............................................................ 69
3.6.3. Проблема синхронизации задач ........................................................... 70
3.6.4. Пример синхронизации задач ............................................................... 70
3.6.5. Проблема производителя/потребителя ................. ..............................72
3.6.6. Слабо связанный обмен сообщениями ................................................ 73
3.6.7. Сильно связанный обмен сообщениями с ответом ............................. 74
3.6.8. Сильно связанный обмен сообщениями без ответа ............................74
3.6.9. Пример обмена сообщениями
между производителем и потребителем .............................................. 75
3.7. С о к р ы т и е и н ф о р м а ц и и
в п р и м е н е н и и к с и н х р о н и з а ц и и д о с т у п а ......................................... 76
3.7.1. Классы и объекты, скрывающие информацию .................. ................. 76
3 .8. М о н и то р ы ......................................................................................................77
3.8.1. Пример монитора................................................................................... 77
3.8.2. Условная синхронизация ....................................................................... 78
3 .9. Ш а б л о н ы п р о е к ти р о в а н и я ..................................................................... 79
Содержание ттшш
3.10. П р о гр а м м н ы е а р х и те ктур ы и к о м п о н е н т н ы е с и с те м ы .........80
3.10.1. Компоненты и разъемы ..................................................................... 81
3.10.2. Компонентные системы ..................................................................... 81
3 .1 1 . Р е зю м е ......................... ............................................................................81
Глава 4. Т е хн о л о ги и
параллельны х и распределенны х систем ................83
4.1. С ре д ы д л я па р а л л е л ьн о й о б р а б о тк и ................................................ 83
4.1.1. Мультипрограммная среда ........................ ........................................ 83
4.1.2. Симметричная мультипроцессорная среда ............. ........................ 83
4.1.3. Распределенная среда .........................................................................84
4 .2 . П о д д е р ж к а и с п о л н е н и я
в м у л ь т и п р о гр а м м н о й и м у л ь т и п р о ц е с с о р н о й с р е д а х ............. 85
4.2.1. Сервисы операционной системы ........................................................85
4.2.2. Стандарт POSIX ..................................................................................... 86
4.2.3. Операционные системы реального времени ..................................... 87
4 .3 . П л а н и р о в а н и е задач ................................................................................ 88
4.3.1. Алгоритмы планирования задач ........................................................... 88
4.3.2. Состояния задач ................................................................................... 89
4.3.3. Контекстное переключение задач .........................................................90
4 .4 . В о п р о с ы в в о д а /в ы в о д а в о п е р а ц и о н н о й с и с т е м е ......... ......... 90
4.4.1. Контроллеры устройств ....................................................................... 90
4.4.2. Обработка прерываний .......................................................................... 91
4.4.3. Ввод/вывод с опросом ........................... ............................................... 92
4 .5. Т е х н о л о ги и к л и е н т -с е р в е р н ы х и р а с п р е д е л е н н ы х с и с те м ... 93
4.5.1. Конфигурации клиент-серверных и распределенных систем ..........93
4.5.2. Коммуникационные сетевые протоколы ..............................................95
4 .6 . Т е х н о л о ги я W o rld W ide W eb .................................................................. 97
4.6.1. Язык Java и World Wide Web ................................................................. 98
4 .7 . С е р в и с ы р а с п р е д е л е н н ы х о п е р а ц и о н н ы х с и с те м ..................... 98
4.7.1. Служба имен .......................................................................................... 99
4.7.2. Связывание клиентов и серверов ......................................................... 99
4.7.3. Сервисы распределенного обмена сообщениями .......................... 100
4.7.4. Сервисы сокетов ................................................................................. 101
4.7.5. Обмен сообщениями через порты .................................................... 101
4.7.6. Восстановление после ош ибок.......................................................... 101
4 .8 . ПО п р о м е ж у т о ч н о го с л о я ................................................................... 102
4.8.1. Платформы для распределенных вычислений ................................ 102
4.8.2. Вызовы удаленных процедур ............................................................ 102
4.8.3. Вызов удаленных методов в языке Java ............... ........................... 104
UM L Проектирование систем
4 .9 . С та н д а р т C O R B A .................................................................................... 104
4.9.1. Брокер объектных запросов .............................................................. 104
4.9.2. Язык определения интерфейса в CORBA ........................................ 105
4.9.3. Статическое и динамическое связывание ....................................... 106
4.9.4. Сервисы CORBA ................................................................................. 107
4.9.5. Интеграция унаследованных приложений
в каркас распределенных объектов .................................................. 107
4 .1 0 . Д р у ги е к о м п о н е н тн ы е те х н о л о ги и .............................................. 108
4.10.1. Технология СОМ ............................................................................... 108
4.10.2. Технология JavaBeans ........................................ .......................... 108
4.10.3. Технология Jini ................................................................................. 108
4 .1 1 . С и с те м ы о б р а б о тк и т р а н з а к ц и й ................................................... 109
4.11.1. Характеристики транзакций ........................................................... 109
4.11.2. Мониторы обработки транзакций .................................................. 110
4 .1 2 . Р е зю м е .................................... ................................................................ 111
Г л а ва 5. Ж и з н е н н ы е ц и кл ы и м е то д ы р а з р а б о тк и
п р о г р а м м н о г о о б е с п е ч е н и я ............................................и 2
5.1. О п р е д е л е н и е ж и з н е н н о го цикла П О ............................................. 112
5.1.1. Модель водопада ............................................................................... 112
5.1.2. Недостатки модели водопада .......................................................... 113
5.1.3. Временные прототипы .................................................................... 114
5.1.4. Создание эволюционирующих прототипов
в ходе инкрементной разработки ..................................................... 115
5.1.5. Комбинирование временных прототипов
и инкрементной разработки .............................................................. 116
5.1.6. Спиральная модель ........................................................................... 117
5.1.7. Унифицированный процесс разработки ПО .................................. 118
5 .2 . В е р и ф и к а ц и я и у тв е р ж д е н и е п р о е к та ......................................... 118
5.2.1. Контроль качества ПО .................. ..................................................... 119
5.2.2. Анализ производительности ............................................................. 119
5 .3 . Т е с т и р о в а н и е п р о гр а м м н о го о б е с п е ч е н и я .............................. 119
5.3.1. Автономное тестирование .................. ............................................. 120
5.3.2. Тестирование сопряжений ................................................................ 120
5.3.3. Комплексное тестирование ............................................................... 120
5.3.4. Приемо-сдаточные испытания ......................................................... 121
5 .4 . Э в о л ю ц и я м е то д о в п р о е к т и р о в а н и я ПО .................................... 121
5 .5 . Э в о л ю ц и я м е то д о в
о б ъ е к тн о -о р и е н ти р о в а н н о го ана л и за и п р о е к ти р о в а н и я ..... 123
Содержание
5.6. О б з о р с о в р е м е н н ы х м е то д о в п р о е к т и р о в а н и я
параллельных систем и систем реального времени ............ 125
5.7. Резюме ......................................................................................... 126
ЧАСТЬ II. COMET - метод архитектурного

проектирования и моделирования
параллельных объектов
с применением U M L ......................................... 127
Глава 6. В ведение в метод C O M E T ........................................... 128
6.1. Ж и зн е н н ы й цикл разр а б о тки
о б ъ е к тн о -о р и е н ти р о в а н н о го ПО в м е то д е C O M E T ................... 128
6.1.1. Моделирование требований ............................................................ 128
6.1.2. Аналитическое моделирование ........................................................ 128
6.1.3. Проектное моделирование ............................................................... 129
6.1.4. Инкрементное конструирование ПО ................................................ 130
6.1.5. Инкрементная интеграция ПО .......................................................... 130
6.1.6. Комплексное тестирование .............................................................. 130
6 .2. С р а в н е н и е ж и з н е н н о го цикла C O M ET
с д р у ги м и п р о ц е с с а м и р а зр а б о тк и П О ......................... .............. 131
6.2.1. Сравнение жизненного цикла COMET с USDP ................................. 131
6.2.2. Сравнение жизненного цикла COMET со спиральной моделью .... 131
6.3. М од ел ь тр е б о в а н и й , анал и ти че ска я и п р о е к тн а я м о д ел и ... 131
6.3.1. Виды деятельности при моделировании требований ..................... 132
6.3.2. Виды деятельности при аналитическом моделировании .............. 132
6.3.3. Виды деятельности при проектном моделировании ...................... 133
6 .4. О сн о в ы C O M E T ...................................................................................... 134
6.4.1. Разработка модели требований ....................................................... 134
6.4.2. Разработка аналитической модели ................................................... 134
6.4.3. Разработка проектной модели .......................................................... 135
6.5. Р е зю м е ....................................................................................................... 137
Глава 7. М о д ел иро ва ни е п р е ц е д е н т о в .................................. 138
7.1. П р е ц е д е н т ы .............................................................................................. 138
7 .2. А ктер ы ........................................................................................................ 139
7.3. А кте ры , р о л и и п о л ьзо в а те л и ............................................................ 141
7.4. В ы я в л е н и е п р е ц е д е н то в .................................................................... 141
■ ■ H i , . UML. Проектирование систем
7 .5 . Д о к у м е н т и р о в а н и е п р е ц е д е н то в в м о д е л и п р е ц е д е н то в .... 142
7 .6 . П р и м е р ы п р е ц е д е н то в ........................................................................ 143
7.6.1. Прецедент «Снять Деньги» ................................................................ 143
7.6.2. Прецедент «Получить Справку» ........................................................ 145
7.6.3. Прецедент «Перевести Деньги» ......................... .............................. 146
7 .7. О тн о ш е н и я п р е ц е д е н то в ................................................................... 147
7.7.1. Отношение расширения .................................................................... 147
7.7.2. Отношение включения ...................................................................... 149
7.7.3. Некоторые рекомендации ................................................................ 150
7.8. П акеты п р е ц е д е н то в ........................................................................... 150
7.9. Р е зю м е ..................................................................................................... 151
Г л а в а 8 . С т а т и ч е с к о е м о д е л и р о в а н и е ......................................... 152
8.1. А с с о ц и а ц и и м е ж д у к л а сса м и .......................................................... 152
8.1.1. Изображение ассоциаций на диаграммах классов ........................ 153
8.1.2. Кратность ассоциаций ...................................................................... 153
8.1.3. Другие ассоциации ........ ...................... ............................................ 155
8.1.4. Атрибуты связи .................................................................................. 155
8.1.5. Классы-ассоциации ........................................................................... 156
8 .2. И е р а р х и и к о м п о з и ц и и и а гр е ги р о в а н и я .................................... 157
8 .3. И е р а р х и я о б о б щ е н и я /с п е ц и а л и з а ц и и ........................................ 159
8.4 . О гр а н и ч е н и я .......................................................................................... 160
8 .5. С та ти ч е с к о е м о д е л и р о в а н и е и язы к U M L .................................. 160
8.5.1. Статическое моделирование предметной области ........................ 161
8 .6 . С та ти ч е с к о е м о д е л и р о в а н и е к о н те к ста с и с т е м ы .................. 162
8.6.1. Внешние классы .............................. ................................................... 163
8.6.2. Пример разработки диаграммы классов контекста системы
с внешними классами ........................................................................ 164
8.6.3. Актеры и внешние классы ........................ .......................................... 165
8.6.4. Пример разработки диаграммы классов контекста системы
на основе рассмотрения актеров ..................................................... 165
8 .7. С та ти ч е с к о е м о д е л и р о в а н и е с у щ н о с тн ы х к л а ссо в .............. 166
8.8. Р е з ю м е ....................................................................................................... 167
Г л а в а 9 . Р а з б и е н и е н а к л а с с ы и о б ъ е к т ы .................................. 168
9.1. К р и те р и и р а зб и е н и я на объ екты .................................................... 168
9.2. К а те го р и и кл а ссо в п р и л о ж е н и я ....................................................... 169
9.3 . С тр у к ту р и р о в а н и е к а т е го р и й об ъ екто в ....................................... 170
9.4 . В н е ш н и е и и н те р ф е й с н ы е классы ............................................... . 171
9.4.1. Категории внешних классов ........................ ....................................... 171
9.4.2. Идентификация интерфейсных классов ........................................... 172
Содержание _ __ - -."Щ
9.5. И н т е р ф е й с н ы е о бъ екты .................................................................... 173
9.5.1. Объекты интерфейса устройства ..................................................... 173
9.5.2. Объекты интерфейса пользователя ................................................. 175
9.5.3. Объекты интерфейса системы ......................................................... 176
9.5.4. Изображение внешних и интерфейсных классов ............................ 177
9.6. С у щ н о с тн ы е объ екты .......................................................................... 178
9.7. У п р а в л я ю щ и е объ екты ....................................................................... 180
9.7.1. Объекты-координаторы .................................................................... 180
9.7.2. Управляющие объекты, зависящие от состояния ......... ................. 181
9.7.3. Объекты-таймеры ............................................................................. 182
9.8. О бъекты п р и кл а д н о й л о ги к и ........................................................... 182
9.8.1, Объекты бизнес-логики .................................................................... 182
9.8.2. Объекты-алгоритмы .......................................................................... 183
9.9. П о д с и с те м ы ............................................................................................ 183
9.9.1. Пакеты для изображения подсистем ....................... ....................... 184
9.9.2. Вопросы, связанные с разбиением на подсистемы ....................... 185
9.10. Р езю м е ................................................................................................... 186
Г л а в а 10. К о н е ч н ы е а в то м а ты
и д и а г р а м м ы с о с т о я н и й ................................. ................ 187
10.1. К он е чн ы е а в то м а ты ....................................................... .......... ......... 187

10.2. С о б ы ти я и с о с т о я н и я ....................................................................... 188
10.2.1. События ........................................................................................ . 188
10.2.2. Состояния ........................................................................................ 188
10.3. К о н е ч н ы е ав то м а ты и объ екты ..................................................... 188
10.4. П р и м е р ы д и а гр а м м с о с т о я н и й .................................... ............... 189
10.4.1. Пример диаграммы состояний счета ................ ............................. 189
10.4.2. Пример диаграммы состояний банкомата ..................................... 189
10.4.3. Пример диаграммы состояний системы круиз-контроля ............ 191
10.5. С о б ы ти я и у с л о в и я ............................................................................ 191
10.6. Д е й с т в и я ............................................................................................... 193
10.6.1. Деятельности ................................................................................... 194
10.6.2. Действия при входе и выходе ......................................................... 197
10.7. М о д е л и р о в а н и е р азл и ч ны х а с п е кто в с и с т е м ы .................... 200
10 .8 . И е р а р х и ч е с к и е д и а гр а м м ы с о с т о я н и й .................................... 201
10.8.1. Иерархическая декомпозиция состояний ..................................... 201
10.8.2. Агрегирование переходов состояний ............................................ 203
10.9. П а р а л л е л ьн ы е д и а гр а м м ы с о с т о я н и й .......................................203
10.10. Р е к о м е н д а ц и и по р а з р а б о тк е д и а гр а м м с о с т о я н и й ........ 205
j^ UML. Проектирование систем
10.11. Построение диаграмм состоянии

на основе прецедентов.............. ......................................... 206
10.12. Пример разработки диаграммы состояний
на основе прецедента ...........................................................207
10.12.1. Прецедент «Управление Скоростью» ............................ ............... 207
10.12.2. Разработка диаграммы состояний .............................................. 208
10.12.3. Рассмотрение альтернативных внешних событий ...................... 210
10.12.4. Разработка иерархической диаграммы состояний ...................... 211
10.12.5. Разработка ортогональной диаграммы состояний ...................... 213
10.13 . Р езю м е ........................................... .......................................................214
Глава 11. Д инам ическое м о д е л и р о в а н и е ............................. 215

11.1. Моделирование взаимодействий объектов ..................... 215
11.1.1. Диаграммы кооперации .......................... ........................................ 216
11.1.2. Диаграммы последовательности ..................................................... 217
11.1.3. Сравнение диаграмм последовательности и кооперации ............ 218
11.1.4. Прецеденты и сценарии ................................................................... 218
11.1.5. Обобщенные и конкретные формы диаграмм взаимодействия ..... 219
11.2. Сообщения-метки на диаграммах взаимодействия ............219
11.2.1. Порядковая нумерация сообщений ................................................ 220
11.2.2. Описание последовательности сообщений ................................... 222
11.3. Динамический анализ ............................................................... 223
11.4. Динамический анализ, не зависящий от состояния ............223
11.5. Пример динамического анализа,
не зависящего от состояния.................................................... 225
11.6. Динамический анализ, зависящий от состояния ................. 225
11.6.1. Определение объектов и взаимодействий .................................... 226
11.6.2. Исполнение диаграммы состояний ................................................ 227
11.6.3. Рассмотрение альтернативных последовательностей .................. 229
зависящего от состояния: банковская система ................... 229
11.7.1. Главная последовательность ........................................................... 229
11.7.2. Альтернативные последовательности ............................................. 232
зависящего от состояния: система круиз-контроля ............237
11.9. Резюме ........................................................................................ 246
Глава 12. Проектирование архитектуры системы .......... 250

12.1. Архитектурные стили .............................................................. 250
12.1.1. Архитектура клиент-сервер .............................................................. 250
12.1.2. Архитектура с несколькими уровнями абстракции ....................... 251
12.1.3. Архитектура взаимодействующих задач ......................................... 252
12.1.4. Смешение архитектурных стилей .................................................... 252
12.2. Декомпозиция системы .......................................................... 253
12.3. Рекомендации по выявлению подсистем ............................255
12.4. Консолидированные диаграммы кооперации .................... 255
12.5. Архитектура подсистем .......................................................... 256
12.6. Разделение обязанностей
при проектировании подсистем ........................................... 258
12.7. Критерии разбиения на подсистемы ................................... 260
12.8. Примеры разбиения на подсистемы .................................... 263
12.9. Статическое моделирование
на уровне проектирования ........ ............................................ 264
12.10. Резюме ....................................................................................266
Глава 13. Проектирование
а р х и т е к т у р ы р а с п р е д е л е н н ы х п р и л о ж е н и й .... 268
13.1. Конфигурируемые архитектуры

и программные компоненты.................................................. 269
13.2. Шаги проектирования распределенного приложения ..... 269
13.3. Декомпозиция системы ..........................................................270
13.3.1. Проектирование распределенных подсистем .............................. 270
13.3.2. Агрегированные и составные подсистемы в COMET .................... 272
13.3.3. Проектирование
конфигурируемых распределенных подсистем ............................ 274
13.3.4. Критерии конфигурируемости распределенных компонентов .... 274
13.4. Проектирование интерфейсов подсистем ........ ................ 276
13.4.1. Слабо связанный (асинхронный) обмен сообщениями ................ 276
13.4.2. Сильно связанный (синхронный) обмен сообщениями ................ 277
13.4.3. Обмен сообщениями
между несколькими клиентами и сервером .................................. 277
13.4.4. Коммуникации типа подписка/извещение
и групповой обмен сообщениями .................................................. 278
13.4.5. Коммуникации с участием брокера ............................................... 279

13.4.6. Коммуникации с обговариванием условий ................................... 281
13.5. У пра вл е н и е тр а н за кц и я м и ............................................................ 283
13.5.1. Протокол двухфазной фиксации
в системах обработки транзакций ................................................ 283
13.5.2. Вопросы проектирования транзакций .......................................... 284
13.6. П р о е к ти р о в а н и е с е р в е р н ы х п о д с и с т е м ................................... 285
13.6.1. Последовательная серверная подсистема ................................... 286
13.6.2. Параллельная серверная подсистема ........................................... 287
13.7. Р а с п р е д е л е н и е д а н н ы х ....................................................................290
13.7.1. Распределенный сервер ................................................................. 290
13.7.2. Репликация данных ............................ ............................................. 290
13.8. К о н ф и гур и р о в а н и е си с те м ы .........................................................290
13.8.1. Вопросы конфигурирования системы ............................................ 290
13.8.2. Пример конфигурирования целевой системы .............................. 291
13.9. Р е зю м е ................................................................................................... 292
Г л а в а 1 4 . Р а з б и е н и е н а з а д а ч и .........................................................293
14.1. В о п р о с ы р а з б и е н и я на п а р а л л е л ьн ы е задачи .......................294
14.2. К а те го р и и к р и те р и е в р а з б и е н и я на зад ачи ............................294
14.3. К р и те р и и вы д е лен ия задач в в о д а /в ы в о д а .............................295
14.3.1. Характеристики устройств ввода/вывода ..................................... 295
14.3.2. Асинхронные задачи интерфейса
с устройствами ввода/вывода .................................................. . 296
14.3.3. Периодические задачи интерфейса
с устройством ввода/вывода .......................................................... 297
14.3.4. Пассивные задачи интерфейса
с устройствами ввода/вывода ........................................................ 300
14.3.5. Задачи-мониторы ресурсов ............................................................ 302
14.4. К р и те р и и в ы д елен ия в н у тр е н н и х задач ..................................... 302
14.4.1. Периодические задачи ....................... . .......................................... 302
14.4.2. Асинхронные задачи ........................................................................ 304
14.4.3. Управляющие задачи ......................... ............................................ 306
14.4.4. Задачи интерфейса пользователя .................................................. 307
14.4.5. Множественные однотипные задачи ............................................. 308
14.5. К р и те р и и назначения п р и о р и те т о в задачам ................... . 309
14.5.1. Критические по времени задачи .................................................... 309
14.5.2. Некритические по времени расчетные задачи .............................. 310
14.6. К р и те р и и гр у п п и р о в к и задач ..........................................................310
14.6.1. Темпоральная группировка .............................................................. 311
14.6.2. Последовательная группировка ...................................................... 314
14.6.3, Группировка по управлению ........................................................... 316

14.6.4. Группировка по взаимному исключению ....................................... 318
14.7. П е р е с м о тр п р о е кта путем и н в е р с и и з а д а ч ............................. 319
14.7.1. Инверсия нескольких экземпляров задачи ............ ...................... 319
14.7.2. Инверсия последовательных задач ................. ............................. 321
14.7.3. Темпоральная инверсия задач ........................................................ 321
14.8, Р азра б о тка а р х и те к ту р ы задач .................................................... 324
14.8.1. Начальная диаграмма параллельной кооперации ................... . 327
1 4 .9 К о м м у н и к а ц и и м е ж д у за д а ч а м и и с и н х р о н и з а ц и я ............. 327
14.9.1. Слабо связанный (асинхронный) обмен сообщениями ................ 327
14.9.2. Сильно связанный (синхронный)
обмен сообщениями с ответом ....................................................... 329
14.9.3. Сильно связанный (синхронный)
обмен сообщениями без ответа ...................................................... 330
14.9.4. Синхронизация по событию ............................................................. 331
14.9.5. Взаимодействие задач
с помощью скрывающего информацию объекта .......................... 333
14.9.6. Пересмотренная диаграмма параллельной кооперации ............. 334
14.10. С п е ц и ф и к а ц и я п о в е д е н и я задачи .............................................. 334
14.10.1. Пример спецификации поведения
для задачи «Банковский Сервер» .................................................. 336
14.10.2. Пример спецификации поведения
для задачи «Интерфейс Устройства Считывания Карточек» ...... 337
1 4.11 . Р е зю м е .............. .................................................................................... 338
Глава 15. Проектирование классов....................................ззэ

15.1. П р о е к ти р о в а н и е кл ассов, с к р ы в а ю щ и х и н ф о р м а ц и ю ...... 339
15.2. П р о е к т и р о в а н и е о п е р а ц и й к л а с с о в ..............................................340
15.2.1. Проектирование операций классов
на основе модели взаимодействия ................................................ 341
на основе конечного автомата ..................... .................................... 342
на основе статической модели .................... ........ ......................... 343
15.3. К лассы а б с т р а ги р о в а н и я д а н н ы х .................................................. 343
15.3.1. Пример класса абстрагирования данных ...................................... 343
15.4. Классы и н те р ф е й с а у с т р о й с т в а .....................................................344
15.4.1. Проектирование операций классов интерфейса устройств 346
15.4.2. Классы интерфейса устройства ввода ........................................... 346
15.4.3. Классы интерфейса устройства вывода ........................................ 348
15.5. К лассы , з а в и с я щ и е о т с о с т о я н и я ................................................. 350
15.6. К лассы , с к р ы в а ю щ и е а л го р и тм ы ................................................... 352

15.7. К л ассы и н те р ф е й с а п о л ьзо в а те л я ................................................352
15.8. К л ассы б и з н е с -л о ги к и ........................................................................355
15.9. К л а с с ы -о б е р тк и базы д а н н ы х ......................................................... 356
15.10 . В н у тр е н н и е п р о гр а м м н ы е кл а ссы ...............................................358
15.11. П р и м е н е н и е н а с л е д о в а н и я п ри п р о е к т и р о в а н и и ..............358
15.11.1. Иерархии классов .......................................................................... 358
15.11.2. Абстрактные классы ..................................................... ................... 358
15.11.3. Полиморфизм и динамическое связывание ................................ 359
15.12. П р и м е р ы н а с л е д о в а н и я ............................................................................... 359
15.12.1. Примеры суперклассов и подклассов .......................................... 359
15.12.2. Пример полиморфизма и динамического связывания ............... 362
15.12.3. Пример наследования абстрактному классу ................... .......... 363
15.13. С п е ц и ф и к а ц и я и н те р ф е й с а кл а сса ............................................ 364
15.13.1. Пример спецификации интерфейса класса ........... ..................... 364
15.14. Р езю м е ....................................................................................................366
Г л а в а 1 6 . Д е т а л ь н о е п р о е к т и р о в а н и е П О ................................ 367
16.1. П р о е к т и р о в а н и е с о с т а в н ы х зад ач .................................................367
16.1.1. Отношения между задачами и классами ....................................... 367
16.1.2. Разделение обязанностей между задачами и классами ................ 368
16.1.3. Темпоральная группировка и объекты интерфейса устройств .... 369
16.1.4. Группировка по управлению
и объекты, скрывающие информацию ............................................. 372
16.2. С и н х р о н и з а ц и я д о с ту п а к кл а сса м ....... .............................. . 374
16.2.1. Пример синхронизации доступа к классу ...................................... 374
16.2.2. Операции класса абстрагирования данных ................................... 374
16.2.3. Синхронизация методом взаимного исключения ......................... 375
16.2.4. Синхронизация нескольких читателей и писателей ...................... 376
16.2.5. Синхронизация нескольких читателей и писателей
с помощью монитора ....................................................................... 377
16.2.6. Синхронизация нескольких читателей и писателей
без ущемления писателей ............................................................... 380
16.3. П р о е к ти р о в а н и е разъ ем о в
для м е ж зад ач ны х к о м м ун и ка ц и й .............................................................. 381
16.3.1. Проектирование разъема, реализующего очередь сообщений ..... 382
16.3.2. Проектирование разъема, реализующего буфер сообщений ..... 383
16.3.3. Проектирование разъема,
реализующего буфер сообщений с ответом ..................................................... 384
16.3.4. Проектирование кооперативных задач
с использованием разъемов .......................................................... 385
................. Содержание j 'ШШШШШ
16.4. Логика упорядочения собы тий..............................................386
16.4.1. Пример логики упорядочения событий
для задач отправителя и получателя .............................................. 386
16.5. Резюме ..................................................................................... 387
Глава 17. А н а л и з п р о и з в о д и те л ь н о с ти
п р о е к т а п а р а л л е л ь н о й с и с т е м ы р е а л ь н о г о в р е м е н и ...... 388
17.1. Теория планирования в реальном врем ени........................388
17.1.1. Планирование периодических задач ................ ............................ 389
17.1.2. Теорема о верхней границе коэффициента использования ЦП ..... 389
17.1.3. Теорема о времени завершения .................................................... 391
17.1 А. Строгая формулировки теоремы о времени завершения ............ 392
17.1.5. Планирование периодических и апериодических задач ............. 394
17.1.6. Планирование с синхронизацией задач ............. ......................... 395
17.2. Развитие теории планирования в реальном времени ...... 395
17.2.1. Инверсия приоритетов ................................................................... 396
17.2.2. Обобщенная теорема
о верхней границе коэффициента использования ЦП ................. 397
17.2.3. Обобщенная теорема о времени завершения .............................. 398
17.2.4. Планирование в реальном времени и проектирование ................ 398
17.2.5. Пример применения
обобщенной теории планирования в реальном времени ............ 399
17.3. Анализ производительности
с помощью анализа последовательности событий ............. 400
с помощью теории планирования в реальном времени
и анализа последовательности событий ................................401
17.5. Пример анализа производительности
с помощью анализа последовательности событий ............. 402
17.6. Пример анализа производительности с применением
теории планирования в реальном времени .......................... 406
по теории планирования в реальном времени
и анализа последовательности событий ...............................408
17.7.1. Эквивалентная апериодическая задааа™»^............. ....................... 408
17.7.2. Назначение других n p n o p n T e jp ^ 3 ^ l.WJ’:^ t t 2 ^ ^ - 44 -................... 410
17.7.3. Детальный анализ апериояШЭркйЗГзадач ...*??>», ................... 411
17.8. Пересмотр проекта ........ .тпггтгг.. ................................414
1 7.9. Оценка и измерение параметро^эддаййш^гельности .... 415
17.10. Резюме .....................................................................................416
ЧАСТЬ III. Примеры проектирования параллельных

приложений, распределенных
приложений и приложений
реального врем ени...........................................417
Г л а в а 1 8 . П р и м е р с и с т е м ы у п р а в л е н и я л и ф т а м и .............. 418
18.1. О п и с а н и е за д а чи ................................................................................... 418

18.2. М о д е л ь п р е ц е д е н то в ....................................................................... 419
18.2.1. Прецедент «Выбор Этажа Назначения» ............................................ 419
18.2.2. Прецедент «Вызов Лифта» ............................................................... 420
18.2.3. Абстрактные прецеденты ......................................................... .......420
18.2.4. Абстрактный прецедент «Остановка Лифта на Этаже» .................. 421
18.2.5. Абстрактный прецедент «Планирование Лифта» ........................... 421
18.2.6. Конкретный прецедент «Выбор Этажа Назначения» ........................ 421
18.2.7. Конкретный прецедент «Вызов Лифта» ............................................ 422
18.3. С та ти ч е ска я м о д е ль п р е д м е тн о й о б л а с ти ................................. 422
18.4. Р а з б и е н и е на о бъ екты ........................................................................ 424
18.5. Д и н а м и ч е ск а я м о д е л ь ........................................................................424
18.5.1. Диаграмма кооперации
для прецедента «Выбор Этажа Назначения» ....................................425
18.5.2. Диаграмма кооперации для прецедента «Вызов Лифта» .............. 425
18.5.3. Диаграмма кооперации
для прецедента «Остановка Лифта на Этаже» ...... ......................... 426
18.5.4. Абстрактный прецедент «Отправить Лифт» ................................... 430
18.6. М о д е л ь с о с т о я н и й ................................................................................432
18.7. К о н со л и д а ц и я д и а гр а м м к о о п е р а ц и и .................................. . 434
18.8. Р а з б и е н и е на п о д с и с те м ы ............................................................... 437
18.9. Р а зб и е н и е с и с те м ы на задачи ........................................................ 440
18.9.1. Выделение задач в подсистеме лифта ............................................. 442
18.9.2. Выделение задач в подсистеме этажа ................ ............................ 444
18.0.3, Выделение з &д й ч в подсистеме плзнировщикв ......... .................... 444
18.9.4. Определение интерфейсов задач .................................................... 444
18.9.5. Проектирование класса абстрагирования данных ........ ............... 446
18.9.6. Обсуждение альтернативных архитектур .......................... .......... 449
18.10. П р о е к т р а с п р е д е л е н н о й с и с те м ы
у п р а в л е н и я л и ф та м и .........................................................................449
18.10.1. Структура подсистемы лифта ........................................................ 451
18.10.2. Структура подсистемы этажа ......................................................... 451
Содержание .i £ 1Н Ш
18.10.3. Структура подсистемы планировщика ........................................ 455
18.10.4. Интерфейсы подсистем ................................................................ 455
18.11. Проектирование скрывающих информацию классов..... 456
18.11.1. Проектирование классов интерфейса устройств ................ 456
18.11.2. Проектирование класса, зависящего от состояния ................... 459
18.12. Разработка детального проекта программы ....................459
18.12.1. Проектирование объектов-разъемов для лифта ........................ 459
18.12.2. Проектирование составных задач ................. ............................. 461
18.13. Конфигурирование целевой системы ............................... 463
нераспределенной системы управления лифтами ......... 464
18.14.1. Сценарий для анализа производительности .............................. 464
18.14.2. Последовательности событий .......................................................464
18.14.3. Назначение приоритетов .............................................................. 466
18.14.4. Планирование в реальном времени
для нераспределенной архитектуры ................ ............................468
18.14.5. Последовательность событий «Остановка Лифта на Этаже» .....469
18.14.6. Последовательность событий «Выбор Этажа Назначения» ....... 470
18.14.7. Последовательность событий «Вызов Лифта» ............................471
распределенной системы управления лифтами ............. 472
18.15.1. Сценарий для анализа производительности .............................. 472
18.15.2. Планирование в реальном времени
для распределенной архитектуры ............................................... 473
18.15.3. Последовательность событий «Остановка Лифта на Этаже» ..... 477
18.15.4. Последовательность событий «Выбор Этажа Назначения» ....... 479
18.15.5. Последовательность событий «Вызов Лифта» ........................ 480
Г л а в а 1 9 . П р и м е р б а н к о в с к о й с и с т е м ы ...... ...............................483
19.1. Описание задачи .....................................................................483

19.2. Модель прецедентов...............................................................484
19.2.1. Абстрактный прецедент «Проверить ПИН-код» .......................... . 485
19.2.2. Конкретный прецедент «Снять Деньги» ......................................... 485
19.2.3. Конкретный прецедент «Получить Справку» .................................486
19.2.4. Прецедент «Перевести Деньги» ..................................................... 487
19.3. Статическое моделирование ................................................ 487
19.3.1. Статическое моделирование предметной области ......................487
19.3.2. Статическое моделирование контекста системы ........ ................488
19.3.3. Статическое моделирование сущностных классов ......................488
20 UM L Проектирование систем
19.4. Разбиение на объекты ................................ ...........................491

19.4.1. Выделение клиентской и серверной подсистем ............ .............. 491
19.4.2. Выделение клиентских объектов: интерфейсные объекты .......... 493
19.4.3. Выделение клиентских объектов:
объекты, участвующие в прецедентах ......... ................................. 493
19.4.4. Выделение объектов в серверной подсистеме ............................. 495
19.5. Динамическое моделирование .............................................496
19.5.1. Описание последовательности сообщений
для прецедента «Проверить ПИН-код наКлиенте» ....................... 497
для прецедента «Проверить ПИН-код на Сервере» ....................... 500
для прецедента «Снять Деньги на Клиенте» ................................... 502
для прецедента «Снять Деньги на Сервере» ................................. 506
19.6. Диаграмма состояний банкомата.......................................... 508
19.7. Проектирование банковской системы ............................. 512
19.8. Создание консолидированной
диаграммы кооперации ............................ ............................... 513
19.9. Разбиение на подсистемы ...................................................... 515
19.10. Проект подсистемы банкомата ............................ ................ 517
19.10.1. Проектирование архитектуры задач
для подсистемы банкомата ............. ........................................... 517
19.10.2. Определение интерфейсов задач в подсистеме банкомата ..... 521
19.10.3. Проектирование скрывающих информацию классов
в подсистеме банкомата .............................................................. 523
19.10.4. Разработка детального проекта подсистемы банкомата ........... 524
19.11. Проектирование подсистемы банковского сервера .......526
19.11.1. Проектирование архитектуры параллельных задач
в подсистеме банковского сервера ........................ .................... 527
19.11.2. Проектирование скрывающих информацию классов
в банковском сервере ................... ............................................... 528
19.11.3. Проектирование интерфейсов банковского сервера ................. 530
19.12. Конфигурирование банковской системы ...........................534
19.13. Альтернативные варианты..................................................... 534
19.14. Спецификации поведения задач ..........................................534
для задачи «Интерфейс Устройства Считывания Карточек» ...... 534
для задачи «Контроллер Банкомата» ........................................... 536
... И я 1икввйаВИР
•
19,14.3. Пример логики упорядочения событий
для задачи «Банковский Сервер» ................................................ 538
Глава 20. П р и м е р си сте м ы

КРУИЗ-КОНТРОЛЯ И М О Н И ТО рИ Н Га ................................. 540
20.1. Описание задачи .....................................................................540

20.1.1. Круиз-контроль как задача управления процессами ................... 541
20.2. Модель прецедентов ............................................................. 542
20.2.1. Прецеденты круиз-контроля .......................................................... 543
20.2.2. Прецеденты мониторинга ............................................................... 544
20.3. Описание прецедентов .......................................................... 544
20.3.1. Прецеденты, инициируемые водителем ........................................ 544
20.3.2. Прецеденты, инициируемые таймером ......................................... 546
20.3.3. Прецеденты, инициируемые механиком ....................................... 548
20.4. Статическое моделирование предметной области .......... 548
20.5. Динамическое моделирование .............................................549
20.5.1. Начальное разбиение на подсистемы ................ ........................... 550
20.5.2. Динамическое моделирование
не зависящих от состояния аспектов подсистемы
круиз-контроля ................................................................................ 551
зависящих от состояния аспектов подсистемы
круиз-контроля ................................................................................ 553
20.5.4. Зависящее от состояния динамическое моделирование:
управление калибровкой ................................................................. 554
20.5.5. Динамическое моделирование подсистемы мониторинга:
прецеденты, связанные со средней скоростью ............................ 558
20.5.6. Динамическое моделирование подсистемы мониторинга:
прецеденты, связанные с расходом топлива ............................... 560
прецедентов технического обслуживания .................................... 562
20.6. Разбиение на подсистемы .................................................... 564
20.6.1. Разбиение подсистемы круиз-контроля
на более мелкие подсистемы ......................................................... 564
20.6.2. Разбиение подсистемы мониторинга
на более мелкие подсистемы ......................................................... 565
20.6.3. Зависимости между подсистемами ............................................... 566
20.7. Уточненная статическая модель ...........................................571
20.8. Разбиение системы на задачи ..............................................572
20.8.1. Определение характеристик устройств ввода/вывода ................ 575
20.8.2. Определение задач в подсистеме вала ......................................... 575
« « u I UML. Проектирование систем
20.8.3. Определение задач в подсистеме калибровки ............. ........... . 575
20.8.4. Определение задач в подсистеме пути и скорости ...................... 577
20.8.5. Определение задач
в подсистеме автоматического управления .................................. 580
20.8.6. Определение задач в подсистеме круиз-контроля ...................... 583
20.8.7. Проектирование классов абстрагирования данных .................... 585
20.8.8. Проектирование интерфейсов
между задачами и объектами абстрагирования данных ............. 587
20.8.9. Определение задач в подсистеме мониторинга .......................... 587
20.8.10. Разработка архитектуры и интерфейсов
задач подсистемы мониторинга ................................................... 592
20.9. Проектирование скрывающих информацию классов....... 592
20.9.1. Определение классов интерфейса устройств .............................. 596
20.9.2. Определение зависящих от состояния классов ............................ 598
20.9.3. Определение классов-алгоритмов ........................................ 600
20.10. Разработка детального проекта программы ....................602
20.10.1. Проектирование сгруппированных задач ................................... 602
20.10.2. Проектирование объектов-разъемов .......................................... 606
20.11. Проектирование архитектуры
распределенной автомобильной системы .......................607
Глава 21. П рим ер ра спределенной систем ы
автом атизации производ ства ............................ 609
21.1. Описание задачи ........... .......................................... .............. 609
21.2. Модель прецедентов ............................................................. 611
21.3. Концептуальная статическая модель
предметной области ............................ .................................. 613
21.4. Разбиение на объекты ........................................................... 614
21.5. Динамическая модель ........................................................... 617
21.5.1. Диаграммы кооперации
для клиент-серверных прецедентов дежурного оператора 617
для прецедентов подписки на извещения .................................... 618
для клиент-серверных прецедентов управления
производством ............. .................................................................. 620
21.5.4. Прецеденты распределенного управления ................................... 623
21.5.5. Диаграмма состояний
контроллера линейной рабочей станции ...................................... 624
21.5.6. Прецеденты изготовления детали ................................................. 626
21.6. Разбиение на подсистемы .................................................... 630
Содержание тттт
21.7. Архитектура распределенной программы .............................634
21.7.1. Применение критериев конфигурируемости компонентов .......... 635
21.7.2. Обмен сообщениями между подсистемами .............................. . 638
2 1 .8 . Конфигурирование системы .................................................... 641
Глава 22. П р и м е р си сте м ы эл е ктр о н н о й ко м м е р ц и и .....644

22.1. Задача электронной коммерции.... .........................................644
22.2. Модель прецедентов ................................................................ 644
22.3. Агенты, поддерживающие систему
электронной коммерции........................................................... 645
22.4. Поддержка системы электронной коммерции
со стороны брокеров объектов ............ ...................................647
22.5. Статическое моделирование предметной области ............. 648
22.6. Модель кооперации .................................................................. 648
22.6.1. Модель кооперации для просмотра каталога ................................. 649
22.6.2. Модель кооперации для размещения заявки .................................. 649
22.6.3. Модель кооперации для обработки заказа ..................................... 651
22.6.4. Модель кооперации для подтверждения отгрузки ....... ............. . 651
22.6.5. Модель кооперации для подтверждения доставки ........................ 652
22.6.6. Модель кооперации для отправки счета-фактуры ........................ 653
22.7. Архитектура распределенной программы .............................655
Г л о с с а р и й ............................................................................................................. 663
Б и б л и о гр а ф и я ........ ......................................................................................... 675
П редм етны й указатель 684

Посвящается Джилл, Уильяму, Александру,
Аманде, Эдуарду и моей матери Джоанне
условие
Предисловие Питера Фримена

Недавние успехи в области разработки аппаратного обеспечения и средств
связи привели к лавинообразному росту числа параллельных и распределенных
систем, а также систем реального времени. Это, в свою очередь, способствовало
изменению требований, предъявляемых к программному обеспечению. Широкое
распространение объектно-ориентированных методов, а теперь еще и применение
языка UML, разумеется, влияют на сложившуюся практику, однако темпы, к со
жалению, отстают от требований времени.
Одна из причин такого отставания - отсутствие добротных практических ру
ководств по объектно-ориентированному анализу и проектированию параллель
ных приложений (в особенности таких, которые одновременно являются распре
деленными и/или должны работать в режиме реального времени). Книга, которую
вы держите в руках, призвана восполнить этот пробел.
Я не знаю человека, который мог бы написать авторитетный учебник по дан
ному предмету лучше, чем Хассан Гома, Более 20 лет Хассан изучал природу сис
тем реального времени, параллельных и распределенных, работая проектировщи
ком, проводя исследования в области новых методов проектирования подобных
систем и преподавая в университете. Результаты его деятельности перед вами.
Книга прекрасно организована, поскольку написал ее опытный преподаватель.
В ней продемонстрирована такая глубина понимания технологии, которая появ
ляется только в результате длительных исследований в данной области. А рисун
ки и практические рекомендации свидетельствуют о наличии у автора непосред
ственного опыта проектирования программных систем.
Надеюсь, что вы получите от чтения этой книги такое лее удовольствие, как
и я, и будете пользоваться ею еще много лет.
Предисловие Брана Селика

В условиях недостаточности данных
допускается куда меньше ошибок,
чем при полном отсутствии данных.
Чарльз Бэббидж
Недавно, произведя поиск на Web-сайте, специализирующемся в области кни
готорговли, я обнаружил 1188 названий в категории «проектирование программ
ного обеспечения», и число книг на эту тему постоянно растет. Несмотря на такое
26 т т ш ш к Предисловие
изобилие, в большинстве подобных изданий почти ничего не говорится собствен
но о теории и практике проектирования, а потому огромное количество программ
в наши дни создается людьми, плохо знакомыми с предметом.
В традиционных инженерных дисциплинах всегда использовались последние
достижения прикладной математики, гарантирующие, что проект будет отвечать
поставленным требованиям при приемлемых затратах. Основываясь на оценках,
полученных с помощью математической модели, можно достаточно уверенно при
ступать, например, к конструированию моста. Однако применительно к программ
ному обеспечению проектирование оказывается преимущественно неформаль
ным процессом, для которого зачастую нет моделей и методов прогнозирования
результата. С этой точки зрения весьма поучительно было бы сравнить эволюцию
программного и аппаратного обеспечения на протяжении нескольких последних
десятилетий. Если аппаратные устройства со временем становились миниатюр
нее, быстрее и дешевле, то программы, напротив, оказывались все более объемны
ми, медленными, дорогими и менее надежными. Одна из основных причин такого
положения состоит в том, что в основе проектирования, современной аппаратуры
лежит использование прогностических моделей.
Отсутствие фундаментальных инженерных принципов в практике разработ
ки ПО можно отчасти объяснить изменчивой, в чем-то даже хаотичной природой
программ, что сильно затрудняет математическое моделирование. Тем не менее
имеется немало весьма полезных аналитических методик. Особенно активно та
кие методики развивш ись в области создания систем реального времени: здесь
надежное предсказание временных характеристик программы часто оказывается
критически важным, поскольку от этого зависит человеческая жизнь. И все же,
вопреки доказанной на опыте эффективности, подобные методы распространены
не очень широко. По сути дела, многие разработчики систем реального времени
даже не подозревают об их существовании.
Написание программы - это в основном интеллектуальное упражнение, не
ограниченное такими физическими факторами, как необходимость обрабатывать
сырье и затрачивать много энергии. У большинства практикующих программис
тов, соблазненных кажущимся отсутствием сопротивления, создается впечатле
ние, что важен только сам код, а потому они не разделяют процессы проектирова
ния и кодирования. Как это ни странно, те же самые люди прекрасно понимают
разницу между проектированием и сборкой авиалайнера.
Дополнительным препятствием к внедрению вышеупомянутых методик в прак
тику создания ПО служит то, что некоторые из них ориентированы на традици
онное процедурное программирование. Хотя никаких фундаментальных зависи
мостей от такой модели не имеется, проблема привязки к более современной
объектно-ориентированной модели все же существует, и тем, кто ценит преиму
щества, заложенные в новой парадигме, это мешает пользоваться старыми мето
дами проектирования.
Книга Хассана Гома - первая из известных мне, в которой эти вопросы рас
сматриваются систематически и всесторонне. Она представляет собой не собра
ние разнородных паттернов и методик, а ясное и подробное изложение способов
Метод COMET _ ■i | J 27
объединения традиционных методов инженерного проектирования с унифициро
ванным языком моделирования (UM L), который уже обрел статус стандарта.
Кроме того, демонстрируется роль данных методов в процессе создания конкрет
ных систем: параллельных, распределенных и реального времени. (Опытные раз
работчики знают, какие трудности стоят за каждым из этих терминов по отдель
ности, а создание систем, обладающих всеми тремя характеристиками, - одна из
наиболее сложных инженерных задач.)
В соответствии с хорошо известным принципом, что обучаться лучше всего
на практике, значительную часть книги занимают детально продуманные нетри
виальные примеры. Вам будет очень полезно полностью разобраться хотя бы в од
ном из них, тогда вы по-настоящему оцепите и удобство предлагаемого подхода,
и то, как на самом деле должно выглядеть инженерное проектирование программ
ною обеспечения.
Нотация UML и методы проектирования программ

В этой книге рассматривается объектно-ориентированный анализ и проекти
рование параллельных приложений, в частности распределенных систем и сис
тем реального времени. Объектно-ориентированные концепции играют огромную
роль в анализе и проектировании программного обеспечения, поскольку касают
ся фундаментальных вопросов адаптируемости и развития. На протяжении неко
торого времени существовало множество разнообразных нотаций и методов
объектно-ориентированного анализа и проектирования программных систем, но
йотом появился унифицированный язык моделирования (UM L), который предо
ставляет стандартизованную нотацию для описания таких моделей. Однако UML
лучше использовать в сочетании с методами объектно-ориентированного анализа
и проектирования.
В большинстве изданий, посвященных объектно-ориентированному анализу
и проектированию, рассматриваются только последовательные системы, а важные
вопросы, которые возникают в связи с разработкой распределенных систем и сис
тем реального времени, опускаются. Для создания такого рода приложений нуж
но объединить объектно-ориентированные концепции с методами параллельной
обработки. Поскольку на сегодняшний день стандартной нотацией для описания
подобных моделей является UML, то именно этим языком мы и будем пользо
ваться далее.
COMET - метод архитектурного проектирования

и моделирования параллельных объектов
COM ET (C oncurrent Object Modeling and Architectural Design M ethod) - это
метод разработки параллельных приложений, в частности распределенных сис
тем и систем реального времени. В основе создания объектно-ориентированного
ПО по методу C O M ET лежит концепция прецедентов, а его жизненный цикл ха
рактеризуется большим числом итераций. Н а этапе моделирования требований
т шш' ■ Предисловие
(Requirements Modeling) система рассматривается как черный ящик. Формирует
ся модель прецедентов, где определяются функциональные требования к системе
в терминах актеров и прецедентов.
На этапе аналитического моделирования (Analysis Modeling) строятся стати
ческая и динамическая модели системы. Статическая модель описывает структур
ные отношения между классами предметной области. Д ля выявления объектов,
рассматриваемых в аналитической модели, применяется критерий разбиения на
объекты. После этого разрабатывается динамическая модель и уточняются опи
санные в модели требований прецеденты с целью представить объекты, участвую
щие в каждом прецеденте, и взаимодействия между ними. В динамической модели
с помощью диаграмм состояний определяются объекты, зависящие от состояния.
На этапе проектного моделирования (Design Modeling) продумывается архи
тектура системы. Аналитическая модель, в которой основное внимание уделялось
предметной области, соотносится со средой, где будет эксплуатироваться про
грамма, и с проектной моделью, где акцент ставится на область решения. Форму
лируются критерии разбиения системы на подсистемы. В случае распределенной
системы наиболее важным является разделение ответственности между клиента
ми и серверами, в том числе с точки зрения централизации и распределения дан
ных и управления. Кроме того, проектируются интерфейсы для обмена сообще
ниями, рассматриваются синхронные, асинхронные, групповые коммуникации
и брокерские сервисы. Затем наступает черед проектирования отдельных подсис
тем. Проектирование параллельных приложений, в том числе и систем реального
времени, сводится в основном к выделению параллельно выполняемых объектно-
ориентированных задач. Создаются интерфейсы для обмена данными между зада
чами и синхронизации. При анализе производительности новой системы реаль
ного времени используется метод монотонного анализа частот, предложенный
Институтом проектирования программных систем (Software Engineering Institute).
Особенности книги
Существует несколько книг, описывающих концепции и методы объектно-
ориентированного анализа для приложений общего вида. Однако распределенные
системы и системы реального времени имеют специфические особенности, кото
рые в большинстве изданий рассматриваются лишь поверхностно. Здесь вы най
дете исчерпывающие сведения о том, как фундаментальные объектно-ориентиро
ванные концепции применяются к анализу и проектированию распределенных
программ (включая клиент-серверные приложения) и программ реального вре
мени. Помимо таких объектно-ориентированных концепций, как сокрытие инфор
мации, классы и наследование, в этой книге рассказывается о конечных автоматах,
параллельных задачах, технологии распределенных объектов и планировании в ре
жиме реального времени. Подробно описывается метод COMET, представляющий
собой специализацию основанного на UM L подхода к объектно-ориентированно
му анализу и проектированию параллельных и распределенных систем, а также
систем реального времени. Чтобы продемонстрировать применение COM ET на
Структура книги
практике, в издание включено несколько примеров из разных областей: система
реального времени, система клиент-сервер и распределенная система.
Отличительные черты данной книги состоят в следующем:
□ здесь рассказывается о критериях разбиения, призванных помочь програм
мисту выявлять подсистемы, объекты и параллельно выполняемые задачи
на разных стадиях процесса анализа и проектирования;
□ с помощью динамического моделирования взаимодействия объектов и ко
нечных автоматов описываются способы совместного использования диа
грамм кооперации и диаграмм состояний;
□ делается акцент на параллельности - приводятся характеристики активных
и пассивных объектов;
□ рассматриваются проектирование распределенных приложений и методы
взаимодействия распределенных компонентов;
□ анализируется производительность системы реального времени с помощью
теории планирования в реальном времени;
□ приводятся развернутые примеры различных приложений, иллюстрирую
щие применение изложенных концепций и методов.
Структура книги
Книга состоит из трех частей. Первая часть содержит обзор различных концеп
ций, технологий, жизненных циклов и методов проектирования систем реального
времени, параллельных и распределенных систем. Глава 1 начинается с краткого
описания различий между методом и нотацией, за которым следует обсуждение ха
рактеристик распределенных систем и систем реального времени. В главе 2 изла
гаются те аспекты нотации UML, которые задействованы в методе COMET. Далее
рассматриваются важные концепции проектирования (глава 3) и необходимой тех
нологической поддержки (глава 4) для параллельных и распределенных систем. За
тем в главе 5 рассказывается о жизненных циклах ПО и методах проектирования.
Во второй части речь идет о методе COMET. В главе 6 анализируется жизнен
ный цикл ПО, созданного с использованием COMET. В главе 7 говорится об этапе
моделирования требований в COMET и, в частности, о моделировании прецеден
тов. В главах 8-11 описываются этапы аналитического моделирования в COMET.
Главы 12-16 посвящены этану проектного моделирования. Предмет главы 17 -
расчет производительности созданной системы с помощью теории планирования
в реальном времени и метода монотонного анализа частот.
В третьей части метод COM ET демонстрируется на пяти подробных примерах
проектирования распределенных приложений (две системы реального времени,
система клиент-сервер и две распределенные системы). В главе 18 рассматривается
система управления лифтами и предлагаются два решения: одно распределенное,
другое - нет. В главе 19 исследуется банковская клиент-серверная система. Гла
ва 20 посвящена автомобильной системе круиз-контроля, глава 21 - распределен
ной системе автоматизации производства, а глава 22 - распределенной системе
электронной коммерции.
ЕЭДМШг Предисловие
Как работать с книгой

Эту книгу можно читать по-разному. Допустимо читать подряд: главы 1-5 яв
ляются введением в используемые концепции и технологии, в главе 6 приводится
обзор метода COMET, главы 7-17 посвящены углубленному изучению порядка
проектирования приложений с помощью COMET, а главы 18-22 включают' при
меры и их анализ.
Первая часть - вводная. Если вы владеете предметом, можете пропустить ее
и сразу перейти к описанию метода C OM ET во второй части. Тем, кто знаком
с языком UML, не понадобится глава 2. Зная концепции проектирования ПО, вы
не станете читать главу 3. Если вы обладаете сведениями о технологиях, применя
емых в параллельных и распределенных системах, пропустите главу 4; если же вам
известны жизненные циклы ПО и методы проектирования, пропустите главу 5.
Читателям, которые заинтересованы главным образом в методе COMET, удобнее
сразу перейти ко второй и третьей частям книги. Тем, чья работа связана с проек
тированием распределенных приложений, следует прочесть главы 4, 12 и 13 (до
полнительная информация о параллельных системах приводится в главах 14 -16),
а также изучить примеры распределенных приложений в главах 18, 19, 21 и 22.
Желающим познакомиться с проектированием систем реального времени и тео
рией планирования в реальном времени необходимо прочесть главы 4 ,14-17 и ра
зобрать примеры в главах 18 и 20.
Опытные проектировщики могут использовать это издание в качестве спра
вочника, обращаясь к тем или иным главам на разных этапах анализа или проек
тирования проекта. Главы мало связаны друг с другом. Например, краткое описа
ние прецедентов вы найдете в главе 7, при проектировании диаграмм состояний
можете заглянуть в главу 10, а при разработке динамической модели - в главу И ,
проектирование распределенных компонентов рассматривается в главе 13, проек
тирование параллельно выполняемых задач - в главе 14, а информацию о плани
ровании в реальном времени вы найдете в главе 17. Разобраться в том, как исполь
зуется метод COMET, несложно и путем изучения примеров, поскольку в каждом
из них объясняются мотивы принятия решений на каждом этапе проектирования.
Благодарности
Я очень признателен рецензентам ранних редакций рукописи. Особая благо
дарность Джеффу Мейджи (Jeff Magee), Ларри МакАлистеру (Larry McAlister),
Кевину Миллсу (Kevin Mills), Роберту Дж. Петтиту IV (Robert G. Pettit: IV) и Ма
рии Эрикссон (M aria Ericsson) за проницательные замечания. Хочу также побла
годарить Антуана К. Дина (Antuan Q. Dinh), Гулама Ахмада Фаруха (Ghulam
Ahmad Farukh), Йохана Галле (Johan Galle), Келли Хьюстона (Kelli Houston),
Джишну Мукерджи (Jishnu Mokerji), Лесли Пробаско (Leslee Probasco), Санджи-
ва Сетия (Sanjeev Setia) и Думинду Виджесекера (Duminda Wijesekera) за ценные
рецензии.
Типографские соглашения ■ 1п т т ш
Спасибо Кевину Миллсу за вклад в использование стереотипов в COMET, Ши-
геру Оцуки (Schigeru Otsuki) - за помощь в работе над материалом по паттернам
проектирования, Роджеру Александру (Roger Alexander) - за участие в работе над
одним из примеров главы 15, Ларри МакАлистеру, помогавшему сделать рис. 21.1.
Особая благодарность - Тиррелл Элбо (Tyrrell Albaugh) за самоотверженный труд
по координации процесса выпуска книги, Кристин Эрикссон (Kristin Ericsson) -
за организацию издательского процесса и Мелинде МакКейн (Melinda McCain) -
за тщательную корректуру рукописи.
Я признателен студентам, принимавшим участие в семинаре по проектирова
нию программных систем в Университете Джорджа Мейсона, за энтузиазм, пре
данность и ценные замечания, а также Институту проектирования программных
систем (Software Engineering Institute - SEI) за предоставленный материал по
планированию в реальном времени, частично положенный в основу главы 17.
Необходимо поблагодарить и Консорциум по повышению производительности
разработки ПО (Software Productivity Consortium) за спонсорскую помощь, ока
занную при работе над первой редакцией глав 9-11 этой книги. Спасибо Арману
Анвару (Arman Anwar), Хуа Линь (H ua Lin) и Майклу Ш ину (Michael Shin) за
изготовление ранних версий рисунков.
И, разумеется, я хочу поблагодарить свою жену Д жилл за понимание, ободре
ние и поддержку.
Типографские соглашения
и альтернативная нотация
В этом разделе описываются использованные в книге типографские соглаше
ния. Здесь же приводится альтернативная нотация UML для обозначения стерео
типов и активных объектов.
Принятые обозначения
Для улучшения восприятия соглашения, применяемые для записи имен клас
сов, объектов и т.д. на рисунках, иногда отличаются от записи тех асе имен в тек
сте. На рисунках имена набраны шрифтом Times Roman, а в тексте - шрифтом
Courier (этим же моноширинным шрифтом в книге набраны листинги - фраг
менты программного кода). Основные термины в тексте выделены курсивом, но
тации U ML отмечены полужирным шрифтом. Используемые обозначения во
многом определяются этапом проектирования. Заглавные буквы в названиях
употребляются по-разному в зависимости от того, об аналитической (менее фор
мальной) или проектной (более формальной) моделях идет речь.
Моделированиетребований
Имена прецедентов набраны шрифтом Courier, первые буквы каждого сло
ва в имени - заглавные, например Снять Деньги.
ЕСТИШЙ^-;| , Предисловие
Аналитическая модель
Ниже приведены соглашения, применяемые в аналитических моделях.
Классы
Имена классов набраны шрифтом Courier с начальными заглавными буква
ми. На рисунках отдельные слова в именах классов не разделяются пробелами
(ЧековыйСчет), а в тексте - разделяются для удобства чтения (Чековый Счет).
Имена атрибутов начинаются с маленькой буквы, например баланс. Если
имя атрибута состоит из нескольких слов, то на рисунках они не разделяются про
белами, а в тексте - разделяются. Первое слово имени начинается с маленькой
буквы, остальные - с большой, допустим номер Счета.
Тип атрибута пишется с большой буквы, скажем Boolean, Integer или Real.
Объекты
Имена объектов записываются по-разному. На рисунках, в отличие от текста,
они всегда подчеркиваются. Кроме того, применяются следующие соглашения:
□ отдельный именованный объект. В этом случае первая буква в первом слове
имени - маленькая, а в последующих словах - большая. Н а рисунках имя
объекта выглядит так: чековыйСчет или другойЧ ековы йС чет. В тексте
те же объекты обозначаются иначе: чековый Счет или другой Чековый
Счет;
□ отдельный неименованный объект. Иногда объекты на рисунках показаны
как неименованные экземпляры класса, например : ЧековыйСчет. В тексте
такой объект будет обозначен как Чековый Счет. Д ля удобства восприятия
двоеточие опускается, а между словами в составном имени вставляются
пробелы.
Таким образом, в зависимости от способа изображения объекта на рисунке его
имя в тексте иногда начинается с большой, а иногда с маленькой буквы.
Сообщения
В аналитической модели все сообщения являются простыми (см. рис. 2.11),
поскольку решение об их типе еще не принято. Имена сообщений начинаются
с большой буквы. Если имя состоит из нескольких слов, то они разделяются про
белами, например Имя Простого Сообщения.
Обозначения на диаграммах состояний
Имена состояний, событий, условий, действий и деятельностей начинаются
с большой буквы, слова в составном имени разделяются запятыми, например со
стояние Ожидание ПИН-код а, событие Наличные Выданы и действие Выдать
Наличные.
Проектная модель
Ниже приведены соглашения, применяемые в проектных моделях.
Активные и пассивные классы
Соглашения об именовании активных и пассивных классов такие же, как для
классов в аналитической модели.
Типографские соглашения |>1 1 8 1 Н Н М Е 1]
Активные и пассивные объекты
Соглашения об именовании активных и пассивных объектов такие же, как для
объектов в аналитической модели.
Сообщения
В проектной модели первое слово в имени сообщения начинается с малень
кой буквы, остальные - с большой. На рисунках слова не разделяются пробелами
(тревожноеСообщение), а в тексте пробелы между ними есть (тревожное Со
общение).
Имена параметров сообщений начинаются с маленькой буквы, например ско
рость. Если имя состоит из нескольких слов, то на рисунках оно записывается
без разделительных пробелов, а в тексте - с ними. Первое слово в составном име
ни начинается с маленькой буквы, остальные - с большой, скажем полныйПро-
бег (на рисунке) или полный Пробег (в тексте).
Альтернативная нотация для стереотипов

В UML нотация, принятая для стереотипов, позволяет адаптировать элемен
ты модели к особенностям конкретной предметной области. С одной стороны,
стереотипы можно обозначать с помощью двойных угловых кавычек внутри эле
мента модели (например, класса или объекта), как показано на рис. 1а. С другой
стороны, в UM L допускается изображение стереотипа в виде графического сим
вола. Наиболее распространенные на сегодняшний день пиктограммы были вве
дены Джекобсоном [Jacobson 1992] и применяются в унифицированном процессе
разработки программ [Jacobson, Booch, and Rumbaugh 1999] на этапе аналитичес
кого моделирования. Стереотипы используются для представления классов-сущ
ностей (entity), граничных классов (boundary, в методе COM ET им соответствуют
классы со стереотипом «интерфейс») и управляющих классов (control). На рис. 16
с помощью графических стереотипов Джекобсона изображены сущностный класс
а) «сущность» «управление» «граница»

Технологическая Управление Интерфейс
Карта Лифтом Датчика
Технологическая Управление Интерфейс

Карта Лифтом Датчика
Рис. 1. Альтернативные нотации для стереотипов в UML:

а - стандартная нотация UML для стереотипов; б - нотация для стереотипов,
применяемая в унифицированном процессе разработки программ
ш тм ш ш к Предисловие
Технологическая Карта, управляющий класс Управление Лифтом и гранич
ный класс Интерфейс Датчика.
Альтернативная нотация для активных объектов

В этой книге применяется стандартная нотация UML для обозначения актив
ных (в методе COM ET они называются задачами) и пассивных объектов. В UML
прямоугольник активного объекта рисуется с жирной рамкой, а прямоугольник
пассивного объекта - с тонкой (см. главу 2). Некоторые CASE-средства не под
держивают такой стандарт, поэтому активные и пассивные объекты оказываются
визуально неразличимыми. В COM ET слово «задача» обычно не употребляется
в имени стереотипа активного объекта. Как показано на рис. 2а на примере объек
та Генератор Отчетов, для этой цели достаточно прямоугольника с жирной рам
кой. Если же такой визуальный эффект не поддерживается, то в имя стереотипа
можно вставить слово «задача» (см. рис. 26).
а)
«периодическим»
:ГенераторОтчетов
б)
«периодическая задача»
:ГенераторОтчетов
Рис. 2. Альтернативные нотации для активных объектов (задач) в UML:

а - стандартная нотация UML для активных объектов; б - вариант, используемый,
если стандартная нотация активных объектов не поддерживается
1
Нотация UML,
концепции
проектирования,
технологии,
жизненные циклы
и методы
Гла Т тл ш т 4 .
Введение Технологии параллельны х
и распределенных систем
Г лаы л
Обзор нотации UML Глаии* 5;-
Жизненные циклы и методы
Г иевна 3 . разработки программного
Концепции обеспечения
проектирования ПО
и архитектуры
.*1 . L 4 V ," "r -
Значительное понижение цен на микропроцессоры и полупроводниковые микро

схемы и столь же существенное увеличение производительности микропроцессо
ров, наблюдаемые на протяжении нескольких лет, сделали рентабельными распре
деленные системы и системы реального времени на базе микрокомпьютеров.
Сегодня большинство коммерческих, промышленных, военных, медицинских
и потребительских продуктов снабжаются микропроцессорами и целиком либо
в значительной части управляются программами. Такие системы встречаются
в микроволновых печах и видеомагнитофонах, в телефонах и телевизорах, в авто
мобилях и самолетах, в подводных лодках и космических кораблях, в автоматах
по продаже газированных напитков и банкоматах, в системах диагностики паци
ентов и системах управления производством, в контроллерах роботов и системах
управления лифтами, в системах управления городским и воздушным транспор
том, в электронной почте и коммерции, в «интеллектуальных» транспортных
и информационных магистралях... Список можно продолжать до бесконечности.
Все это параллельные системы, а многие из них являются к тому же распределен
ными или системами реального времени.
Объектно-ориентированные концепции особенно важны для анализа и про
ектирования программного обеспечения, поскольку они касаются фундаменталь
ных вопросов адаптируемости и развития. Сравнительно недавно появившийся
унифицированный язык моделирования (U M L) предлагает стандартизованную
нотацию для описания объектно-ориентированных моделей [Booch, Rumbaugh,
Jacobson 1998; Eriksson and Penker 1998; Fowler and Scott 1999; Jacobson, Booch
and Rumbaugh 1999; Rumbaugh, Booch and Jacobson 1999]. Однако в большинстве
книг, посвященных данным темам, рассматриваются только последовательные
приложения и опускаются существенные вопросы, связанные с проектированием
систем реального времени, параллельных и распределенных систем. Объединение
концепций объектно-ориентированного проектирования с концепциями парал
лельного выполнения необходимо для успешного создания распределенных при
ложений, работающих в реальном масштабе времени. Поскольку UML содержит
стандартную нотацию для описания объектно-ориентированных моделей, в кни
ге будет использоваться именно этот язык. Особое внимание уделяется модели
рованию динамики системы, представляющему интерес для приложений реаль
ного времени и распределенных приложений.
В книге рассматривается объектно-ориентированный анализ и проектирова
ние параллельных систем с использованием нотации UML. В частности, описы
ваются две важнейшие категории параллельных приложений: распределенные
Объектно-ориентированные методы и UML * ш т 37
и реального времени. Издание предназначено для тех, кто хочет научиться проек
тировать и оценивать программное обеспечение параллельных и распределенных
систем и систем реального времени.
В этой главе вводятся объектно-ориентированные концепции и обсуждаются
общие характеристики трех вышеупомянутых категорий программных систем.
1.1. Объектно-ориентированные методы и UML

Объектно-ориентированные методы основаны на концепциях сокрытия ин
формации, классов и наследования [Wegner 1990]. Сокрытие информации [Parnas
1972, Parnas 1979] позволяет получить замкнутые, а оттого в большей степени
поддающиеся модификации и сопровождению системы. Наследование [Меуег
1987, Меуег 1997, Wegner 1990] - это систематический способ адаптации классов.
Язык UML, пришедший на смену многочисленным системам нотации и мето
дикам проектирования [Booch 1994; Coad and Yourdon 1991; Jacobson 1992;
Rumbaugh et al. 1991; Shlaer and Mellor 1988; Wirfs-Brock, Wickerson, and Wiener
1990 и др.], предложил нотацию для описания объектно-ориентированных моде
лей, которая стала промышленным стандартом. Однако для эффективного при
менения нотации UML необходимо сочетать ее с каким-либо методом объектно-
ориентированного анализа и проектирования.
В описываемом методе C O M E T сочетаются прецеденты использования
[Jacobson 1992], статическое моделирование [Rumbaugh et al. 1991, Booch 1994],
диаграммы состояний [Harel 1988, Harel and P oliti 1998, Coleman et al. 1994,
Rumbaugh et al. 1991] и диаграммы последовательности событий, которые встре
чаются в нескольких методах [Booch 1994, Gomaa 1993, Jacobson 1992, Rumbaugh
et al. 1991]. П рименяемая нотация основана на UM L [Booch, Rumbaugh, and
Jacobson 1998; Eriksson and Penker 1998; Fowler and Scott 1999; Jacobson, Booch
and Rumbaugh 1999; Rumbaugh, Booch and Jacobson 1999]. В ходе моделирования
прецедентов использования определяются функциональные требования к системе
в терминах актеров и прецедентов. Статическая модель предлагает статический
взгляд на информационные аспекты системы. Класс определяется в терминах сво
их атрибутов и взаимоотношений с другими классами. Результатом динамическо
го моделирования является динамический взгляд на систему. Уточняются сфор
мулированные ранее прецеденты с целью показать взаимодействие объектов,
участвующих в каждом из них. Разрабатываются диаграммы кооперации и после
довательности, отражающие кооперацию объектов в каждом прецеденте. Завися
щие от состояния аспекты системы описываются с помощью диаграмм состояний,
причем для каждого объекта составляется своя диаграмма.
В аналитической модели основное внимание уделяется пониманию пробле
мы: выявлению объектов предметной области и передаваемой между ними инфор
мации. Объекты и классы предметной области группируются на основе критери
ев выделения объектов. Рассмотрение вопросов, активен объект или пассивен,
синхронно или асинхронно посылаемое сообщение и какая вызывается операция
у объекта-получателя, откладывается до стадии проектирования.
||Щ _ Введение
На этапе проектирования среди объектов выявляются активные (их называ
ют задачами) и пассивные (их называют объектами). Для определения задач при
меняются критерии разбиения на задачи. Разрабатываются также интерфейсы за
дач и описываются операции каждого пассивного класса.
1.2. Метод и нотация

Метод проектирования и нотация проектирования - это разные вещи. Нота
ция проектирования ПО предназначена для описания самого проекта. Хотя она
и предполагает наличие определенного подхода к проектированию, сам подход
остается за ее рамками. Метод проектирования ПО представляет собой система
тическое описание этапов создания проекта.
Нотация проектирования ПО описывает проект программы в графическом
или текстовом виде. В частности, диаграммы классов - это графическая нотация,
а псевдокод - текстовая.
Концепция проектирования ПО - это фундаментальная идея, применимая
к проектированию всей системы, например сокрытие информации.
Стратегия проектирования ПО - общий план и методика выполнения проек
та. Одной из стратегий является объектно-ориентированная декомпозиция.
Критерии структурирования ПО - это эвристические или формальные пра
вила, помогающие проектировщику разбить систему на отдельные компоненты.
Так, критерии разбиения на объекты - это правила декомпозиции системы на
объекты.
Метод проектирования ПО описывает последовательность шагов, выполняе
мых при работе над проектом при условии, что требования к системе уже сформу
лированы. Он помогает выявить, какие решения предстоит принять, в каком по
рядке это следует делать и на основе каких критериев. Метод проектирования
базируется на наборе соответствующих концепций, использует одну или несколь
ко стратегий, а также ту или иную нотацию для документирования результатов.
При выполнении определенных шагов метод может подсказать разработчику, ка
кие критерии наиболее удобны для декомпозиции системы.
В методе COM ET для описания проекта применяется нотация UML. Метод
основан ira следующих концепциях: сокрытие информации, наследование и па
раллельные задачи. Стратегия проектирования параллельно работающих объектов
состоит в разбиении системы на активные и пассивные объекты и определении ин
терфейсов между ними. Метод COM ET также содержит критерии разбиения, по
могающие выделить объекты в системе на этапе анализа, а затем на этапе проек
тирования выявить отдельные подсистемы и параллельно выполняемые задачи.
1.3, Параллельные приложения

На заре развития вычислительной техники компьютерные приложения явля
лись в основном пакетными заданиями. Все программы были последовательны
ми и работали в автономном режиме. Теперь же, когда имеется огромное число
Параллельные приложения , ъ тш
интерактивных программ и отчетливо прослеживается тенденция перехода к рас
пределенным микрокомпьютерным системам, многие приложения по природе
своей параллельны.
Растет количество систем, в том числе распределенных и реального времени,
в которых роль параллелизма очень велика. Для параллельного приложения ха
рактерно наличие многих задач, выполняемых одновременно. При этом порядок
следования внешних событий часто непредсказуем, и периоды обработки таких
событий могут перекрываться.
1.3.1. Последовательные и параллельные программы

Все действия последовательной программы производятся строго поочередно.
Например, традиционный последовательный компилятор выполняет одну за дру
гой несколько фаз для получения конечной программы. Пакетная программа рас
чета зарплаты по очереди обрабатывает записи о служащих и для каждого печата
ет соответствующий листок.
В параллельных программах многие задачи функционируют одновременно.
Так, с многопользовательской интерактивной системой работают сразу несколь
ко человек, и невозможно предсказать, от кого придет следующее событие ввода.
Система управления воздушным движением отслеживает несколько самолетов
одновременно, поэтому ряд операций происходит параллельно. Изменение погод
ных условий способно привести к неожиданному изменению нагрузки, вероятны
и другие непредсказуемые ситуации.
Дейкстра f 19681 понял, что некоторые приложения параллельны по самой сво
ей природе, поскольку определенные виды деятельности в них происходят логи
чески одновременно. Представление такого параллелизма в последовательной
программе ведет к усложнению ее структуры, гораздо проще назначить каждому
виду деятельности отдельную задачу - процесс. Несколько подобных задач вы
полняется одновременно, то есть параллельно; нередко они взаимодействуют: об
мениваются информацией или синхронизируют свою работу [Gomaa 1993].
1.3.2. Последовательные и параллельные приложения

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

Концепция параллельных задач, называемых также параллельными процесса
ми., служит основой проектирования параллельных приложений. Параллельное
приложение состоит из многих задач, выполняемых одновременно. Концепции
проектирования параллельных задач применимы также к распределенным при
ложениям и приложениям реального времени.
Концепция параллельной работы задач широко распространена при проекти
ровании операционных систем, баз данных, систем реального времени, интерак
тивных и распределенных систем [Басон 1997]. Основная сложность заключается
в том, чтобы разбить приложение на параллельно выполняемые задачи и предо
ставить средства обмена сообщениями и синхронизации этих задач между собой.
Д ля распределенных приложений и приложений реального времени нужно поза
ботиться и о других характеристиках (см. разделы 1,4 и 1.5).
1,4. Системы и приложения реального времени

Системы реального времени (рис. 1.1) - это параллельные системы с времен
ными ограничениями. Они широко распространены в промышленных, коммер
ческих и военных приложениях. Термин «система реального времени» обычно
относится к системе в целом, включающей приложение реального времени, опе
рационную систему реального времени и подсистему ввода/вывода реального
времени. В состав такой системы входят также драйверы специальных устройств,
управляющие работой различных датчиков и приводов. Поскольку здесь речь
идет в основном о проектировании приложений, мы будем пользоваться терми
ном «приложение реального времени», а не «система реального времени». Одна
ко в этом разделе приложения реального времени рассматриваются в более широ
ком контексте систем реального времени.
Входная Информация ог Датчиков
Система
реального времени
Выходная Информация для Приводов
Привод 1 Привод 2 Привод N
Рис. 1.1. Система реального времени

Системы и приложения реального времени ||( Ц Н Н
Системы реального часто очень сложны, так как их работа связана
с многочисленными независимыми потоками входных событий и продуцирова
нием различной выходной информации. Частота поступления событий обычно
непредсказуема, однако реагировать необходимо достаточно быстро, чтобы со
блюсти временные ограничения, сформулированные в требованиях к программе.
Нередко нельзя предугадать и порядок поступления событий. Кроме того, вход
ная нагрузка может с течением времени значительно и неожиданно изменяться.
Системы реального времени часто дополнительно подразделяются на систе
мы с жесткими и слабыми временными ограничениями. Система с жесткими
ограничениями обязана отреагировать на событие в пределах установленного вре
менного интервала, в противном случае возможен аварийный отказ. Для систем
со слабыми ограничениями выход за пределы допустимого интервала считается
нежелательным, но все же не катастрофическим явлением.
Программные системы реального времени имеют дополнительные характери
стики, отличающие их от прочих систем:
□ встраиваемые системы. Система реального времени часто является частью
более крупной программно-аппаратной системы. Примером может служить
контроллер робота, входящий в состав робототехнического комплекса, име
ющего одну или несколько механических рук.
Обычно программная система реального времени состоит из приложения
реального времени, операционной системы реального времени и, возможно,
дополнительного системного ПО: коммуникационных программ, программ
промежуточного слоя или драйверов специальных устройств;
□ взаимодействие с внешней средой. Как правило, система реального време
ни осуществляет такое взаимодействие без участия человека. Например, она
может управлять механизмами или процессом производства, следить за
протеканием химических реакций или поднимать тревогу. Для получения
информации о внешней среде обычно требуются датчики, а для управления
средой - приводы (см. рис. 1.1);
□ временные ограничения. Системы реального времени обязаны тратить на
обработку события время, не превышающее заранее заданное. Если в интер
активной системе недостаточно быстрая реакция способна лишь вызвать не
довольство, то в системе реального времени последствия бывают катастро
фическими. Например, в системе управления воздушным движением это
может привести к столкновению самолетов в воздухе. Необходимое время
реакции зависит от приложения: иногда оно измеряется миллисекундами,
иногда - секундами, а иногда - даже минутами;
□ управление в реальном масштабе времени. Часто системе реального време
ни приходится принимать управляющие решения на основе входных дан
ных, без участия человека. Так, автомобильная система круиз-контроля,
призванная поддерживать постоянную скорость машины, должна управ
лять дросселем в зависимости от текущей скорости.
Однако могут быть и некритичные по времени компоненты. Например, сис
тема сбора данных в реальном времени должна принимать информацию
Ш Ш ЯШ Ж . Введение- .
сразу, иначе она будет потеряна, но анализ полученных сведений допустим
и позже;
□ реактивные системы [Harel and Politi 1998] управляются событиями и долж
ны реагировать на внешние стимулы. Обычно реакция системы зависит от
ее текущего состояния, то есть не только от самого внешнего стимула, но
и от того, что происходило в системе раньше.
1.5. Распределенные системы и приложения

Распределенное приложение - это параллельное приложение, которое ис
полняется в среде, состоящей из нескольких географически разнесенных узлов
(рис. 1.2). Каждый узел представляет собой отдельную вычислительную систему,
причем эти системы связаны локальной или глобальной сетью. Поскольку про
граммное обеспечение, необходимое для поддержки распределенных приложений,
очень сложно, то термином «распределенная система» обычно обозначают распре
деленные операционные системы, распределенные файловые системы и распре
деленные базы данных. Ниже рассказывается в основном о проектировании рас
пределенных приложений, включающих все названные сервисы, поэтому мы будем
пользоваться термином «распределенное приложение», а не «распределенная сис
тема».
Узел 2
«локальная сеть»
г ---------- Г
Узел 3 Узел 4
Рис. 1.2. Распределенная среда обработки
Распределенная обработка имеет следующие преимущества:

□ повышенная доступность. Если некоторые узлы временно недоступны, то
операция выполняется в редуцированной конфигурации. Отсутствует еди
ная точка отказа;
□ гибкая конфигурация. Одно и то же приложение допустимо сконфигуриро
вать различными способами, разместив его на подходящем числе узлов;
□ более локализованное управление и администрирование. Распределенную
подсистему, выполняемую на своем собственном узле, можно спроектиро
вать так, что она будет автономной, то есть практически независимой от
других подсистем, работающих на прочих узлах;
□ постепенное расширение системы. Если нагрузка сильно возрастает, систе
му легко расширить за счет добавления новых узлов;
Резюме
□ уменьшение затрат. Зачастую распределенное решение оказывается дешев

ле централизованного, особенно если принять во внимание стремительно
уменьшающуюся стоимость и возрастающую производительность микро
компьютеров;
□ балансирование нагрузки. В некоторых приложениях общая нагрузка на
систему может быть распределена между различными узлами;
□ уменьшение времени отклика. Запросы пользователей локальных систем
обрабатываются быстрее.
1.6. Резюме
В этой главе описывались характеристики параллельных приложений, в том
числе особенности двух важных классов: распределенных и реального времени.
Было сказано о различии между методом и нотацией и объяснено, как метод
C OM ET соотносится с нотацией языка UML. В главе 2 речь пойдет о тех аспектах
нотации UML, которые применяются в COMET. В главе 3 приведены дополни
тельные сведения о фундаментальных концепциях, лежащих в основе объектно-
ориентированного проектирования параллельных приложений. Более детально
рассматривается концепция параллельно выполняемых задач, в частности механиз
ма обмена сообщениями и синхронизации. Кроме того, параллелизм должен под
держиваться операционной системой или языком программирования (см. главу 4).
I s^ n U v* ? , ;^ Л :< ч Г п :ч г > p г/ \
В методе COM ET используется нотация из унифицированного языка моделиро

вания UML, которая объединила нотации, предложенные Бучем [Booch 1994],
Джекобсоном [Jacobson 1992), Рамбо [Rumbaugh et al. 1991] и Харелом [Harel
1988, 1998]. В данном разделе представлен краткий обзор нотации UML. Подроб
нее она описана в разных книгах, например «The Unified Modeling Language User
Guide» [Booch, Rumbaugh, and Jacobson 19981 и «UML Distilled» [Fowler 1999],
а полностью - в справочном руководстве «The Unified Modeling Language Reference
Manual» [Rumbaugh, Booch, and Jacobson 1998]. Все три названные книги согла
суются с версией языка UML 1.3, равно как и издание, которое вы держите в ру
ках. Есть и другие работы, в которых нотация UM L описана с разной степенью
детализации, в частности [Eriksson 1998], [Jacobson, Booch, and Rumbaugh 1999;
Pooley 1999].
Со временем нотация UML расширялась, и теперь в ней поддерживается много
различных диаграмм. Здесь принят такой же подход, как в книге [Fowler 1999 ]: ис
пользуются лишь необходимые аспекты нотации. В этой главе рассматриваются
возможности нотации UML, которые находяi применение в методе COMET. Мы
не стремимся полностью описать язык UML, поскольку существуют и другие кни
ги; ниже представлен только краткий обзор. Речь пойдет об основных свойствах
названных в настоящем издании диаграмм; те же, что задействованы редко, мы
опускаем.
2.1. Диаграммы UML

В нотации UM L поддерживаются девять видов диаграмм:
□ диаграммы прецедентов (см. раздел 2.2);
□ диаграммы классов (см. раздел 2.4);
□ диаграммы объектов, являющиеся вариантом диаграмм классов в примене
нии к экземплярам. В методе COM ET вместо них работают консолидиро
ванные диаграммы кос перации (см. главу 12);
□ диаграммы кооперации (см. раздел 2.5);
□ диаграммы последовательности (см. раз/юл 2.5);
□ диаграммы состояний (см. раздел 2.6);
□ диаграммы деятельности (в COM ET не используются);
□ диаграммы компонентов (в C OM ET не используются). Термин «компо
нент» в этой книге обозначает распределенный компонент в том смысле,
Нотация UML для классов и объектов I ВЙШИ Ш И М К Я
в каком он понимается в компонентных технологиях, а не в UML (см, гла»

вы 4 и 13);
□ диаграммы развертывания (см. раздел 2.9).
Описание того, как перечисленные диаграммы применяются в методе COMET,
содержится в последующих главах.
2.2. Диаграммы прецедентов

Актер (actor) инициирует прецедент. Прецедент (use case) описывает после
довательность взаимодействий между актером и системой. Актер изображается
на диаграмме прецедентов в виде фигуры человечка, система - в виде прямоуголь
ника, прецедент - в виде эллипса внутри этого прямоугольника. Коммуникаци
онные ассоциации связывают актеров с теми прецедентами, в которых они участ
вуют. Между прецедентами могут быть отношения include (включает) и extend
(расширяет). Пример диаграммы прецедентов представлен на рис. 2.1.
П рец ед ент^)
Актер
( ^ Прецедент~А^ )
/ \
«extend» , \ «extend»
С Прецедент В J )
/ \
«include» / \ «include»
/ \
( ^ П рецедентУ^ ) (^ П р е ц е д е н т ? ^ )
Рис. 2,1. Диаграммы прецедентов в нотации UML
2.3. Нотация UML для классов и объектов

Классы и объекты изображаются в UML прямоугольниками, как показано на
рис. 2.2. В прямоугольнике класса всегда вписано имя класса. Дополнительно
могут быть указаны атрибуты и операции класса. Когда присутствуют все три эле
мента, то в верхней секции прямоугольника находится имя класса, в средней -
атрибуты, а в нижней - операции.
Чтобы отличить класс (тип) от объекта (экземпляра типа), имя объекта под
черкивается. Объект может обозначаться как a n O b ie c t. a n o t h e r O b i e c t : C l a s s
или : C l a s s . Классы и объекты встречаются в разных диаграммах UML.
mmm>s Обзор нотации UML
Класс
Класс
Класс атрибуты
атрибуты
операции
Класс Класс с атрибутами Класс с атрибутами

и операциями
обьект другойОбъект: Класс :Класс
Объект ы
Рис. 2.2. Объекты и классы в нотации UML

2.4. Диаграммы классов
На такой диаграмме классы изображаются в виде прямоугольников, а стати
ческие (постоянные) отношения между ними - в форме дуг. Поддерживаются три
основных типа отношений между классами (рис. 2.3):
□ ассоциации. Ассоциация между двумя классами (бинарная ассоциация)
изображается в виде линии, соединяющей прямоугольники классов. У нее
есть имя и, возможно, стрелка, поясняющая, в каком направлении следует
это имя читать. На каждом конце ассоциации проставляется кратность -
число, свидетельствующее, сколько экземпляров одного класса связано с од
ним экземпляром другого класса. Дополнительно на каждом конце ассоци
ации может присутствовать стрелка, указывающая направление навигации
вдоль данной ассоциации.
Допустимы следующие кратности ассоциации: ровно один (1), присутствие
экземпляра класса необязательно (0..1), нуль или более (*), один или более
(1..*) и точное задание числа экземпляров классов (m..n), где т и п - числа;
□ иерархии агрегирования и композиции. Это отношения вида целое/часть.
Отношение композиции (изображается закрашенным ромбом) накладыва
ет более сильные ограничения на экземпляры классов, чем отношение агре
гирования (показывается незакрашенным ромбом). Ромб одной вершиной
примыкает к прямоугольнику класса, являющегося частью в отношении
вида «часть/целое»;
□ иерархия обобщения/специализации. Это отношение вида «является». Обоб
щение изображается в виде стрелки, ведущей от подкласса (потомка) к су
перклассу (родителю), причем стрелка упирается в прямоугольник супер
класса.
Четвертое отношение - зависимости - часто применяется для передачи отно
шений между пакетами (см. раздел 2.7).
Видимость определяет, доступен ли элемент класса вие самого класса (рис. 2.4).
Показывать видимость на диаграмме необязательно. Открытая видимость, изобра
жаемая символом + (плюс), означает, что элемент виден извне класса. Закрытая
Диаграммы взаимодействия ■■■1
Ровно один
Необязательно (нуль или один)
Много (нуль или более)
Много (один или более)

Ассоциация Ассоциация
(в направлении (в направлении Класс Точное задание
чтения имени навигации)
ассоциации)
Обобщение/специализация Иерархия агрегирования Иерархия композиции
Рис. 2.3. Нотация UML для связей на диаграмме классов
Суперкласс
# защищенныеАтрибутыКласса
ИмяКласса
- закрытыеАтрибутыКласса ±
+ открытыеОперацииКласса ПодклассА1 ПодклассА1
- закрытыеОперацииКласса
- закрытыеАтрибутыКласса - закрытыеАтрибутыКласса
Обобщение/специализация
Рис. 2.4. Нотация иМ1для обозначения видимости на диаграмме классов
видимость, отмеченная знаком - (минус), свидетельствует о том, что элемент ви

ден только внутри класса, в котором он определен, а от других классов скрыт. З а
щищенная видимость, показываемая знаком #, говорит о том, что элемент ви
ден внутри класса, в котором определен, а также во всех подклассах этого класса.
2.5. Диаграммы взаимодействия

В UML есть два вида диаграмм взаимодействия: диаграммы кооперации (col
laboration diagram) и диаграммы последовательности (sequence diagram). Семан
тически они эквивалентны. Н иже описываются основные свойства этих диа
грамм.

Н а диаграмме кооперации показывается, как объекты динамически общают
ся между собой, посылая и получая сообщения. Эта диаграмма представляет
структурную организацию взаимодействующих объектов, изображаемых в виде
Ш И В ^ , I, Обзор нотации UML
прямоугольников и соединяющих их дуг. Помеченные стрелки рядом с дугами
обозначают имя сообщения и направление его передачи между объектами. От
дельные сообщения в последовательности сообщений, отправляемых от одного
объекта к другому, нумеруются. Нотация диаграмм кооперации представлена на
рис. 2.5. Необязательное повторение обозначается символом *, свидетельствую
щим, что информация посылается более одного раза. Необязательное условие
означает, что сообщение посылается только тогда, когда условие истинно.
Рис. 2.5. Диаграмма кооперации в нотации UML
2.5.2. Диаграммы последовательности

Другой способ показать взаимодействие объектов - воспользоваться диаграм
мой последовательности (рис. 2.6). На ней обмен объектов сообщениями пред
ставлен во времени более точно и наглядно. Диаграмма последовательности дву
мерна: участвующие объекты изображаются вдоль горизонтальной оси, а время
откладывается вдоль вертикальной. От прямоугольника каждого объекта идет
вниз вертикальная пунктирная линия, называемая линией жизни. Период, в тече
ние которого объект выполняет операцию, именуется активизацией. На протяже
нии этого ггериода линия жизни изображается двойной сплошной линией.
Актер обычно изображается в левом верхнем углу диаграммы. Помеченные
горизонтальные линии представляют пересылку сообщений. Существенны толь
ко отправитель и получатель сообщения. Сообщение посылается объектом-отпра-
вителем объекту-получателю. Время возрастает в направлении сверху вниз. Рас
стояние по вертикали между сообщениями не имеет значения.
2.6. Диаграммы состояний

В нотации UML диаграмма перехода состояний называется диаграммой со
стояний. На ней состояния представляются прямоугольниками со скругленными
углами, а переходы - соединяющими их дугами (рис. 2.7). Начальное состояние
обозначается дугой, исходящей из маленького закрашенного кружка. Может также
присутствовать необязательное конечное состояние, изображаемое закрашенным
кружком внутри незакрашенного (иногда его называют «бычий глаз»). Диаграмму
состояний разрешается подвергнуть иерархической декомпозиции, так что надсо-
стояние разлагается на подсостояиия.
Диаграммы состояний -штт
1: Входное
Сообщение
2: Внутреннее 1 i
Сообщение 1 1
1
3*: Повторяющееся . 1
Сообщение . 1
!
4 [Условие]: 5
Условное 1
Сообщение 1
V1
т
i l
т
l !
и
Рис. 2.6. Диаграмма последовательности в нотации UML
Конечное Состояние
Рис. 2.7. Диаграмма состояний в нотации UML:

надсостояние с последовательными подсостояниями
Рядом с дугой, представляющей переход, находится условие перехода в виде:

Событие [условие] / Действие. Событие вызывает переход в новое состояние.
Если задано необязательное булевское условие, то переход осуществится, когда
оно истинно. В результате перехода может быть выполнено необязательное дей
ствие. Дополнительно с состоянием иногда ассоциируются:
□ действие при входе в состояние;
□ деятельность, выполняемая во время нахождения внутри состояния;
□ действие при выходе из состояния.
50 ттшшь l Обзор нотации UML
На рис. 2.7 показано пндсостоянне А, разложенное на два последовательных
подсостояния - А1 и А2. В этом случае диаграмма в каждый момент времени мо
жет находиться только в одном состоянии, то есть сначала будет вход в подсосто-
яние А1, а затем - в подсостояние А2. На рис. 2.8 изображено надсостояние В,
разложенное на два параллельных подсостояния - ВС и BD. Здесь объект, описы
ваемый диаграммой, одновременно находится в каждом из подсостояний ВС
и BD. Далее каждое параллельное подсостояние раскладывается на последова
тельные. Таким образом, вход в надсостояние В сопровождается одновременным
входом в подсостояния В1 и ВЗ.
Рис. 2.8. Нотация UML для диаграммы состояний:

надсостояние с параллельными подсостояниями
2 .7. Пакеты
В UML пакетом называется группа элементов модели, используемая, напри
мер, для представления системы или подсистемы. Такая группа изображается
пиктограммой капки - большим прямоугольником, над которым находится пря
моугольник поменьше (рис. 2.9). Пакеты бывают вложенными; между ними мо
гут существовать отношения зависимости и обобщения/специализации. Пакеты
способны содержать классы, объекты или прецеденты.
«система»
ПакетСистемы
4,----------------Зависимость
Рис. 2.9. Нотация UML для пакетов

Диаграммы развертывания
2.8. Диаграммы параллельной кооперации

В нотации U ML активный объект или задача изображается прямоугольником
с жирной границей. Активный объект имеет собственный поток управления и ис
полняется параллельно с другими объектами. Этим он отличается от пассивного
объекта, не имеющего своего потока управления.
Пассивный объект исполняется только тогда, когда другой объект (активный
или пассивный) вызовет одну из его операций. В данной книге мы будем называть
активный объект задачей, а пассивный - просто объектом. Задачи отмечаются на
диаграммах параллельной кооперации, которые позволяют наглядно представить
параллелизм в системе [Douglass 1999Ь]. На такой диаграмме задача показывается
в виде прямоугольника с жирной границей, а пассивный объект - в виде прямо
угольника с тонкой границей (рис. 2.10, здесь представлена также нотация для
множества объектов, возникающих при порождении нескольких объектов одного
класса).
Активный объект I «задача» I мул“ ъект | 'задача*
Пассивный объект «объект» Пассивный «объект»

мультиобъект
Ри с . 2.10. Нотация UML для активных и пассивных объектов
2.8.1 Обмен сообщениями

на диаграммах параллельной кооперации
Интерфейс для обмена сообщениями на диаграмме параллельной кооперации
может быть слабо связанным (loosely coupled) или сильно связанным (tightly
coupled). В последнем случае производитель посылает сообщение потребителю
и ожидает немедленного подтверждения. Сильно связанный обмен бывает двух
видов: сильно связанный обмен сообщениями с ответом и сильно связанный обмен
сообщениями без ответа.
Нотация UM L для нескольких видов обмена сообщениями представлена на
рис. 2.11. На рис. 2.12 изображен вариант диаграммы кооперации с активными
объектами (параллельными задачами или процессами), а также разные типы пе
редачи информации между ними.
2.9. Диаграммы развертывания

На диаграмме развертывания очерчивается физическая, конфигурация системы,
то есть физические узлы и соединения между ними (например, связывающая их
сеть). Узел представляется в виде куба, а соединение - в виде линии, ведущей от
одного куба к другому. По сути, диаграмма развертывания - не что иное, как диа
грамма классов с акцентом на узлах системы [Booch, Rumbaugh, and Jacobson 1998].
Обзор нотации UML
Простое сообщение «простое сообщение»
Решение о типе сообщения пока не принято Имя Сообщения
С лабо связанны й (асинхронны й) обм ен со о б щ е н и я м и

«асинхронное сообщение»
имяСообщения (список аргумент ов)
Сильно связанны й (синхронны й) обм ен сообщениями б ез ответа

«синхронное сообщение»
имяСообщения (список аргументов)
Сильно связанны й (синхронны й) обм ен с о о б щ е н и я м и с ответом

Вариант 1:
«синхронное сообщение с ответом»
имяСообщения (in список ар^ментов, o u t список аргументов)
Вариант 2:
«синхронное сообщение»
имяСообщения (списокаргументов)
Рис. 2.11. Нотация UML для сообщений
1 :входное
Сообщение
£
-folgP 2 : асинхронное j
«задача»
объектА
Сообщение j
3 : синхронное
Сообщение
4: синхронное
Сообщение
Рис. 2.12. Нотация UML для параллельной диаграммы кооперации
В настоящей книге узлом, как правило, является компьютер, при этом макси
мальное число экземпляров узла может быть ограничено (см. раздел 2.10). Для
физического соединения имеется стереотип, задающий тип соединения, например
«локальная сеть» или «глобальная сеть». На рис. 2.13 показаны узлы двух ти
пов: банкомат (каждый такой клиент занимает ровно один узел), соединенный
Рис. 2.13. Нотация UML для диаграммы развертывания
с банковским сервером, который также размещен в одном узле, В кубе, представ

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

В UML имеется три механизма расширения языка [Booch, Rumbaugh, and
Jacobson 1998; Rumbaugh, Booch, and Jacobson 1999]:
□ стереотипы. Стереотип определяет новый строительный блок, производ
ный от существующего в UM L элемента моделирования, но адаптирован
ный к решаемой задаче [Booch, Rumbaugh, and Jacobson 1998]. Ниже сте
реотипы будут использоваться очень широко. В UM L определено несколько
стандартных стереотипов, но проектировщик может создавать и собствен
ные. В этой главе мы встретимся с некоторыми стереотипами: стандартными
и созданными специально для COMET. Названия стереотипов заключаются
в кавычки. На рис. 2.1 два вида зависимостей между прецедентами отмече
ны стереотипами «include» и «extend». На рис. 2.9 представлены стереоти
пы «система» и «подсистема» для обозначения разных видов пакетов. На
рис. 2.10 стереотипы помогают отличить активные объекты от пассивных: ак
тивному объекту соответствует стереотип «задача», а пассивному - «объект».
На рис. 2.11 с помощью стереотипов задаются разные виды сообщений;
□ помеченные значения. Помеченное значение расширяет свойства строитель
ного блока UM L [Booch, Rumbaugh, and Jacobson 1998], сообщая тем самым
54 т т и ш м ! Обзор нотации UML
новую информацию, Оно заключается в фигурные скобки {метка = значе
ние}. Друг от друга помеченные значения отделяются занятыми. Например,
класс на рис. 2,14 имеет два помеченных значения (номер версии и автор):
{версия = 1.0, автор = Gill};
□ ограничения. Ограничение задает условие, которое должно выполняться.
В UML ограничение семантически расширяет элемент, добавляя новые пра
вила или изменяя существующие [Booch, Rumbaugh, and Jacobson 1998].
Например, в классе Счет на рис. 2.14 есть ограничение на атрибут баланс,
состоящее в том, что баланс не должен быть отрицательным {баланс > 0}.
Помимо этого, в состав UML входит объектный язык ограничений Object
C onstraint Language [Warmer 1999].
Счет
{версия =1.0, автор = Gii!}
- номерСчета: integer
- баланс: Rea!
{баланс >0}
Р и с . 2.14. Нотация UML

для помеченных значений и ограничений
2.11. UML как стандарт

В данном разделе вкратце представлена эволюция UML до уровня стандарта.
История развития UML подробно описана в работе [Cobryn 1999]. В UML 0.9
унифицированы нотации Буча, Джекобсоиа и Рамбо, применявшиеся ранее для
моделирования. Эта версия легла в основу работы но стандартизации, в которой
принимали участие многие поставщики и системные интеграторы. Плодом их
усилий стала версия UM L 1.0, поданная на рассмотрение рабочей группы по раз
витию стандартов объектного программирования (O bject Management Group -
О MG) в сентябре 1997 года. После нескольких доделок в ноябре того же года на
свет появилась окончательная версия UML 1.1. С тех пор она подверглась Tie-
скольким незначительным изменениям. На момент написания этой книги теку
щей была версия UM L 1.3. В книгах «The Unified Modeling Language User Guide»
[Booch, Rumbaugh, and Jacobson 1998], «UML Distilled» [Fowler, 1999] и «The
Unified Modeling Language Reference Manual» [Rumbaugh, Booch, and Jacobson
1998], а равно и в настоящем издании описывается именно версия UML 1.3. Име
ется множество предложений по развитию стандарта UML, выход новой версии
UML 2.0 ожидается в 2001 году.
2.12. Резюме
В этой главе были описаны нотация UML и основные характеристики диа
грамм, применяемых в нашей книге. На диаграмме прецедентов изображены ак
теры и прецеденты использования. Как они работают в методе COMET, расска
зывается в главе 7. На диаграмме классов отмечены классы и отношения между
ними; использование диаграмм классов в COM ET па этапе анализа представлено
в главе 8, а на этапе проектирования - в главе 15. Диаграмма состояний показыва
ет, как можно построить модель класса с помощью конечного автомата. В главе 10
вы найдете дополнительные сведения о роли диаграмм состояний в COMET. Су
ществует два вида диаграмм взаимодействия: диаграммы кооперации и диаграм
мы последовательности. На них показывается динамика обмена сообщениями
между объектами. В главе 11 проводится сравнение этих семантически эквива
лентных подходов и рассказывается об их применении в COMET. О пакетах для
изображения подсистем речь пойдет в главе 9. На диаграммах развертывания
представлена физическая конфигурация системы, особенно полезны они для мо
делирования распределенных приложений (см. главу 13). Диаграммы параллель
ной кооперации нужны для описания архитектуры распределенных приложений
(см. главу 13) и архитектуры задач (см. главу 14). Из предоставляемых UM L ме
ханизмов расширения в COM ET задействованы главным образом стереотипы -
в частности, для изображения объектов, подсистем и критериев разбиения на от
дельные задачи. Об этом говорится в главах 9, 12 и 14 соответственно.
Дополнительные сведения о нотации UM L можно почерпнуть в книгах
[Fowler 1999] и [Booch, Rumbaugh, and Jacobson 1998]. В качестве подробного
справочного руководства по языку UML рекомендуем книгу [Rumbaugh, Booch,
and Jacobson 1999].
I ' w a y * ' ;4J( ‘j * \ , - !•*;?<: - \ ; ; • ;*
В этой главе излагаются основные методы проектирования параллельных объект -
но-ориеитированных систем, а также важные концепции, применяемые при раз
работке архитектуры таких систем. Сначала речь пойдет об объектно-ориентиро
ванных концепциях, в том числе о классах и объектах, а также о роли сокрытия
информации и наследования. Затем мы расскажем о концепциях параллельной
обработки, в частности об обмене информацией между параллельно выполняемы
ми задачами и о синхронизации между ними.
Названные концепции являются основными строительными блоками при
проектировании архитектуры системы, ее разбиении на компоненты и определе
нии интерфейсов между компонентами.
3.1. Объектно-ориентированные концепции

Термин «объектно-ориентированный» появился в связи с объектно-ориенти
рованным программированием вообще и языком Smalltalk в частности [Goldberg
and Robson 1983), хотя концепции сокрытия информации и наследования были
известны и раньше. Идея сокрытия информации и ее применения для проектиро
вания программ впервые встречается в работе Парнаса [Parnas 1972], предложив
шего сокрытие информации для создания замкнутых модулей, которые можно
было бы изменять, не затрагивая (или почти не затрагивая) другие модули. Кон
цепции классов и наследования были введены в языке Simula 67 [Dahl and Hoare
1972], но получили широкое распространение только с появлением языка Smalltalk.
В этом разделе мы опишем объектно-ориентированные концепции на уровне
задачи (анализ) и решения (проект).
3.1.1, Основные концепции

Объект - это физическая или умозрительная сущность, облегчающая пони
мание реального мира и составляющая тем самым основу программного решения.
Объект в реальном мире может обладать физическими свойствами (его можно
увидеть или потрогать). Примерами могут служить дверь, двигатель или лампа.
Умозрительный, или концептуальный, объект - это более абстрактное понятие, до
пустим банковский счет или транзакция.
Объектно-ориентированные приложения состоят из объектов. С точки зрения
проектировщика, в объекте присутствуют как данные, так и процедуры для рабо
ты с ними. Процедуры обычно называют операциями или методами. Иногда, в том
Объектно-ориентированные концепции гИ Й И И И
числе в языке UML, операцией именуют спецификацию функции, выполняемой
объектом, а методом - реализацию этой функции [Rumbaugh, Booch, and Jacobson
1999J. Здесь мы будем пользоваться термином операция для обозначения как спе
цификации, так и реализации. Аналогичный подход принят в работах [Gamma
1995; Meyer 1997 и др.].
Сигнатура операции состоит из ее названия, параметров и возвращаемого зна
чения. Интерфейс объекта - это набор предоставляемых им операций, описывае
мый с помощью сигнатур. Тин объекта определяется его интерфейсом, а реализа
ция - классом. В частности, Мейер определяет класс как реализацию абстрактного
типа данных [Meyer 1997].
3.1.2. Объекты и классы

Объект (называемый также экземпляром класса) - это единичная сущность,
например автомобиль Джона или счет Мери. Класс (или класс объектов) - это на
бор объектов с одинаковыми характеристиками, скажем счет, служащий, автомо
биль, клиент. На рис. 3.1 представлен класс К лиент и два объекта: кл и ен т и д р у
гойК лиент, являющиеся экземплярами этого класса. Точно так же объекты счет
и Счет являются экземплярами класса Счет.
Класс
Клиент Счет
Объекты
клиент: Клиент другойКлиент: Клиент
счет :Счет
Рис . 3.1. Пример классов и объектов
Атрибут - это значение, хранящееся в объекте класса. У каждого объекта мо

гут быть разные значения одного и того же атрибута. На рис. 3.2 показан класс
с атрибутами. У класса Счет есть два атрибута: номерСчета и баланс. Изобра
жены два объекта класса Счет: счет и другойСчет. Значения атрибутов разных
счетов различны. Так, номер счета для объекта счет равен 1234, а для объекта
другойСчет - 5678. Баланс первого объекта составляет 525,36 долларов, а вто
рого - 1897,44. И мя атрибута уникально внутри данного класса, хотя в разных
классах возможны атрибуты с одинаковыми именами. Например, и в классе
Клиент, и в классе Служащий есть атрибуты фамилия и адрес.
Операция - это спецификация функции, выполняемой объектом. У объекта
может быть одна или несколько операций. Операции манипулируют значениями
атрибутов, хранящихся в объекте, и имеют входные и выходные параметры. На
бор операций у всех объектов одного класса одинаков. Например, в классе Счет
определены операции читатьБаланс, кредитовать, дебетовать, открыть
и закрыть. На рис. 3.3 представлен класс Счет и его операции.
(И М »* I Концепции проектирования ПО и архитектуры
Класс с атрибутами
Счет
номерСчета: Integer
баланс : Real
Объекты со значениями
сч е т: Счет другойС чет: Счет
номерСчета = 1234 номерСчета = 5678

баланс = 525,36 баланс = 1897,44
Рис. 3.2. Пример класса с атрибутами
Счет
баланс: Real
читатьБаланс(): Real
кредитовать сумма : Real)
дебетовать(сумма; Real)
открыть(номерСчета : Integer)
закрытьО
Рис. 3.3. Класс с атрибутами и операциями
Объект - это экземпляр класса. В языке Pascal можно определить тип записи,
но которому создаются конкретные экземпляры записей. Языки, основанные на
классах, обобщают концепцию, позволяя определять типы объектов, которые ин
капсулируют данные и выполняемые над ними операции. Индивидуальные объек
ты, являющиеся экземплярами класса, создаются при необходимости во время
выполнения.
Все объекты отличаются друг от друга. Иногда у объектов бывают уникаль
ные идентификаторы (допустим, номер счета или фамилия клиента), но это не
обязательно. Возьмите, к примеру, два синих мячика - они совершенно одинако
вы, но тем не менее это два предмета, а не один.
3.2. Сокрытие информации

Сокрытие информации - это фундаментальная концепция проектирования
ПО, применимая ко всем программным системам. Прежние системы зачастую
были уязвимы для ошибок, с трудом поддавались модификации, поскольку ши
роко использовались глобальные данные. Парнас [Parnas, 1972, 1979] показал,
что сокрытие информации позволяет проектировать гораздо более простые для
Сокрытие информации
сопровождения системы за счет резкого сокращения числа глобальных данных,
а впоследствии и полного отказа от них. Парнас пропагандировал сокрытие ин
формации в качестве критерия для разбиения системы на модули. Каждый мо
дуль должен скрывать проектные решения, которые в дальнейшем могли бы из
мениться (изменяемое решение он называл секретом модуля). Таким образом
можно достичь проекта, рассчитанного на изменения.

в объектно-ориентированном проектировании
Сокрытие информации - это базовая концепция объектно-ориентированного
проектирования. Она используется при проектировании объектов и, в частности,
при решении вопроса о том, какая информация должна быть доступной, а какая -
скрытой. Те аспекты объекта, которые не должны быть видны другим объектам,
прячутся. Следовательно, если в процессе развития внутреннее устройство объек
та изменится, это отразится только на данном объекте. Д ля описания сокрытия
объектом информации применяется термин инкапсуляция.
Принцип сокрытия информации требует, чтобы данные, потенциально под
верженные изменениям, инкапсулировались (то есть скрывались) внутри объек
та. Доступ к этим сведениям извне возможен лишь опосредованно - путем вы
полнения операций (процедур или функций), являющ ихся частью объекта.
Только сами операции имеют прямой доступ к скрытой информации. Таким обра
зом, скрытая информация и манипулирующие ею операции составляют единое
целое - объект, скрывающий информацию. Спецификации операций (то есть име
на и параметры) называются интерфейсом объекта. Интерфейс объекта именуют
также абстрактным, виртуальным или внешним интерфейсом. Интерфейс пред
ставляет видимую часть объекта: она раскрывается пользователям объекта.
Ниже мы приведем два примера сокрытия информации при проектировании
ПО и сравним их с функциональным подходом, когда сведения доступны. Пер
вый пример касается проектирования внутренних структур данных, а второй -
проектирования интерфейсов устройств ввода/вывода. Затем мы сформулируем
некоторые правила проектирования объектов.
3.2.2.
в применении к внутренним структурам данных
Одна из проблем, возникающих при разработке прикладного ПО, состоит
в том, что иногда приходится изменять важные структуры данных, к которым
имеют доступ несколько объектов. Если бы не сокрытие информации, то любая
корректировка такой структуры, скорее всего, привела бы к необходимости моди
фицировать все обращающиеся к ней объекты. Подобный подход позволяет
скрыть проектные решения, касающиеся структуры данных, все внутренние свя
зи и детали работающих с ней операций. Решение заключается в том, чтобы ин
капсулировать структуру данных в объекте; тогда напрямую к ней смогут обра
щаться только операции, предоставляемые объектом.
Ш Н И М .... Концепции проектирования ПО и архитектуры
Другие объекты пол\ х о осредоваш тн доступ к инкапсулированной струк
туре данных путем вызова операций объекта. Поэтому, если структура изменится,
это затронет лишь объект, содержащий ее. Внешний интерфейс, поддерживаемый
таким объектом, останется прежним, и объекты, имевшие опосредованный доступ
к структуре, модифицировать не придется. Описанная форма сокрытия инфор
мации называется абстрагированием данных.
Для иллюстрации преимуществ, которые дает сокрытие информации при про
ектировании структур данных, рассмотрим функциональное и объектное решение
следующей задачи. Со стеком работают несколько модулей; при функциональном
подходе модули - это процедуры или функции, а при объектном - объекты. Для
функционального решения стек представляет собой глобальную структуру данных,
к которой каждый модуль обращается напрямую. Поэтому каждый модуль должен
знать о представлении стека (в виде массива или связанного списка), если хочет
манипулировать им (рис. 3,4).
Массив, представляющий стек

Примечание. В этой диаграмме не используется нотация UML.
Рис. 3.4. Пример глобального доступа к массиву, представляющему стек
Объектное решение позволяет скрыть представление стека от объектов, ис

пользующих его. Проект скрывающего информацию стека выглядит так (рис. 3.5):
□ уточняется набор операций для манипулирования структурой данных.
В случае стека это операции p u sh , pop, f u l 1 и em pty;
□ задается сама структура данных, например одномерный массив. Определя
ется переменная, указывающая на вершину стека, а также неременная, в ко
торой хранится размер массива;
□ другим объектам не разрешается напрямую обращаться к структуре данных.
Они могут получить только опосредованный доступ путем вызова операций
объекта.
Сокрытие информации .а Н И И И И Я '
Скрывающий
информацию
объект стека
Примечание. В этой диаграмме не используется нотация UM L
Рис. 3.5. Пример скрывающего информацию объекта стека,

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

как это отразится на функциональном и объектном решениях. В обоих случаях
придется изменить структуру данных для представления стека. Но в функцио
нальном решении стек реализован как глобальная структура, поэтому потребует
ся изменить все модули, обращающиеся к нему, так как они непосредственно ма
нипулировали этой структурой. Теперь вместо индексов в массиве модуль должен
работать с указателями в связанном списке (рис. 3.6).
Стек, реализованный в виде связанного списка
Примечание. В этой диаграмме не используется нотация UML..
Рис. 3.6. Пример глобального доступа к стеку, реализованному

в виде связанного списка
62 Концепции проектирования ПО и архитектуры
При объектном подходе также необходимо изменить ipwm ( 1р о и с т о
операций объекта, скрывающего информацию, поскольку теперь они должны ра
ботать со связанным списком, а не с массивом (рис. 3.7). Однако внешний интер
фейс, видимый остальным объектам, остается тем же. Следовательно, объекты,
пользующиеся стеком, это изменение не затрагивает, они продолжают вызывать
операции стека, даже не зная о произведенной модификации.
Примечание, В этой диаграмме не используется нотация UML.
Рис. 3.7. Пример стека, скрывающего информацию объекта

и реализованного в виде связанного списка
Те же идеи применимы к проектированию класса стека, являющегося шабло

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

с устройствами ввода/вывода
Сокрытием информации можно воспользоваться и при решении вопроса
о том, как должен выглядеть интерфейс с конкретным устройством ввода/выво
да. Решение заключается в создании виртуального интерфейса с устройством, ко
торый скрывает все специфичные для устройства детали. Если проектировщик
впоследствии решит заменить устройство другим, имеющим сходную функцио
нальность, то внутренние детали интерфейса, конечно, придется переделать. В част
ности, потребуется модифицировать операции объекта, так как они тесно связаны
с реализацией конкретной аппаратуры. Однако виртуальный интерфейс, описан
ный в спецификации операций, останется прежним (рис. 3.8), и объекты, пользу
ющиеся этим интерфейсом к устройству, трансформировать не придется.
Прикладная Программа
Программное
Обеспечение
Интерфейс Виртуального
Устройства (Операции)
Интерфейс
Реального Устройства
Аппаратное
Обеспечение
Реальное Устройство
Ввода/Вывода
Примечание. В этой диаграмме не используется нотация UML.
Рис. 3.8. Сокрытие информации при проектировании

интерфейса с устройством ввода/вывода
В качестве примера сокрытия информации в устройствах ввода/вывода рас

смотрим автомобильный дисплей, на который выводится средняя скорость и рас
ход топлива. Можно спроектировать виртуальное устройство, которое будет
скрывать детали форматирования данных и интерфейс с конкретным дисплеем.
Такое устройство поддерживает следующие операции:
displayAvarageSpeed (speed) // Вывести среднюю
// скорость.
diaplayAverageMPG (fuelConsumption) // Вывести средний расход
// в милях на галлон.
Сведения о том, как данные размещаются на экране, какие используются управ
ляющие символы, и прочая специфичная информация скрывается от пользователя
объекта. Если мы заменим это устройство другим, обеспечивающим те же функ
ции, то внутреннюю реализацию операций потребуется модифицировать - в отли
чие от виртуального интерфейса. Таким образом, пользователи объекта не узнают
о замене.
3.2.4. Проектирование объектов, скрывающих информацию

В приведенных примерах мы хотел и показать достоинства сокрытия инфор
мации. И нкапсуляция повышает уровень абстракции, маскируя внутреннюю
сложность объекта, что увеличивает уровень модульности системы. Необходимо
рассматривать лишь интерфейс, а не внутреннее устройство. Так, в примере со
стеком мы могли полностью игнорировать детали его реализации. Н а самом деле
проектирование объекта, скрывающего информацию, следовало бы начать с во
проса, какой интерфейс должен предоставлять новый объект. Допустим, для сте
ка существенными аспектами интерфейса являются операции p u sh , pop, em pty
и f u l l . Для очереди сообщений это были бы операции постановки сообщения
ШШЩЖШ,' v [ Концепции проектирования ПО и архитектуры
в очередь и изъятия из j «.реди; о том, с поме щью какой структуры данных будет
представлена очередь, можно подумать и позже. При проектировании интерфей
са с устройством ввода/вывода главное - определить спецификацию операций,
составляющих интерфейс виртуального устройства, а не особенности его взаимо
действия с реальным устройством.
Таким образом, проектирование объекта (или класса) - это двухступенчатый
процесс. Сначала разрабатывается интерфейс, то есть вид объекта извне, а затем
уже внутреннее строение. Первый шаг - это часть этапа высокоуровневого проек
тирования, а второй - этапа детального проектирования. Весь процесс, скорее все
го, окажется итеративным, поскольку обычно приходится принимать компро
миссные решения по поводу того, что должно быть видимо, а что - нет. В общем
случае не стоит раскрывать все переменные, инкапсулированные в объекте, - на
пример, с помощью операций чтения (get) и установки (sel) —поскольку это озна
чает, что почти вся информация доступна.
33. Наследование
Наследование - это полезный механизм абстрагирования, применяемый в ана
лизе и проектировании. С помощью наследования естественно моделируются
объекты, похожие в некоторых отношениях, то есть имеющие ряд общих свойств
и несколько специфичных. Наследование - механизм классификации, широко
используемый и в других областях. Возьмите, например, зоологическую класси
фикацию, в соответствии с которой животные подразделяются на млекопитающих,
рыб, рептилий и т.д. У собак и кошек есть общие свойства, поэтому тех и других
относят к млекопитающим. Однако имеются и различия: например, собака лает,
а кошка мяукает.
Наследование - это механизм разделения и повторного использования одного
и того же кода в разных классах. Класс-нотомок наследует' свойства (инкапсули
рованные данные и операции) от родительского класса. Но он может модифици
ровать структуру (то есть инкапсулированные данные) и поведение (операции)
своего родителя. Родительский класс называется суперклассом или базовым клас
сом, класс-потомок - подклассом или производным классом. Адаптация родитель
ского класса для нужд потомка называется специализацией. Классы-потомки
можно специализировать и дальше, создавая иерархии классов, или иерархии
обобщения/специализации.
Наследование классов - это меха! ним расширения функциональности при
ложения путем повторного использования возможностей, реализованных в роди
тельских классах. Таким образом, новый класс допустимо частично определять
через уже существующий. Класс-потомок способен адаптировать инкапсулиро
ванные данные (переменные экземпляра) и операции своего родителя. Адаптация
инкапсулированных данных достигается путем определения новых переменных
экземпляра. Адаптация операций состоит в добавлении новых или переопреде
лении имеющихся операций. Класс-потомок может также подавить некоторые
Активные и пассивные объекты ..л в м п ш
операции родителя, однако делать это не рекомендуется, поскольку подкласс и су
перкласс в таком случае не будут иметь общего интерфейса.
Концепция наследования очень эффективна в объектно-ориентированном
программировании. Она используется для разделения кода и как механизм адап
тации, при котором новый класс базируется на определении существующего без
необходимости вручную копировать код. Преимущества такого подхода особенно
ясно видны на этапе детального проектирования и кодирования, поскольку имен
но там можно получить максимальный выигрыш от разделения кода [Meyer 1997].
Применение наследования в проектировании подробно рассматривается в главе 15.
3.4. Активные и пассивные объекты

Объект может быть активным или пассивным. Обычно объекты пассивны: они
ждут сообщения, запускающего операцию, не инициируя никаких действий. Но
в некоторых объектно-ориентированных методах и языках, например в Ada и Java,
поддерживаются также и активные объекты. Активным называется автономный
объект, исполняемый независимо от других активных объектов.
Активные объекты - это параллельные задачи [Wegner 1990; Booch, Rumbaugh,
and Jacobson 1998; Douglass 1999b], У задачи есть собственный поток управления
(иногда говорят о «своей жизни»), и она может инициировать действия, затраги
вающие другие объекты. У пассивных объектов имеются операции, вызываемые
активными объектами; они способны вызывать операции других пассивных объек
тов. У пассивного объекта нет своего потока управления, поэтому такие объекты
являются экземплярами пассивных классов. Операция пассивного объекта, ини
циированная активным объектом (задачей), выполняется в контексте потока управ
ления этого активного объекта.
Во многих вариантах объектно-ориентированного проектирования и програм
мирования объекты концептуально взаимодействуют друг с другом посредством
обмена сообщениями. Для каждого вида сообщений, посылаемых объекту, суще
ствует операция, обрабатывающая его. Имя и параметры сообщения соответству
ют имени и параметрам операции. В большинстве объектно-ориентированных
языков такая форма обмена сообщениями накладывает значительные ограниче
ния, поскольку является синхронной (сильно связанной) и фактически ничем не
отличается от вызова процедур. При подобном подходе все объекты пассивны
и в момент прихода сообщения гарантированно ничем не заняты. С другой сторо
ны, активный объект может что-то делать, когда поступает сообщение, поэтому
примет его, только завершив обработку предыдущего сообщения.
В языке Java объект способен инкапсулировать поток и при этом иметь еще
и операции (в терминологии Java - методы), вызываемые из других потоков. Эти
операции не обязательно должны быть синхронизированы с внутренним потоком.
Такая конструкция имеет черты и активного, и пассивного объекта. Однако в на
стоящей книге проводится четкое различие между активными и пассивными
объектами: любой объект рассматривается либо как пассивный, либо как актив
ный, но не как тот и другой одновременно.
Концепции проектирования ПО и архитектуры
3.5. Параллельная обработка

Задача представляет собой выполнение последовательной программы или
последовательной части параллельной программы. Каждая задача связана с од
ним потоком управления, то есть внутри задачи параллелизма нет. Параллелизм
системы в целом достигается за счет наличия нескольких параллельно выполняе
мых задач. Часто задачи выполняются асинхронно (с разными скоростями) и на
протяжении длительных промежутков времени не зависят друг от друга. Но иног
да они должны обмениваться информацией и синхронизировать свои действия.
Число монографий по кооперативным параллельным задачам значительно
возросло с момента выхода основополагающей работы Дейкстры [Dijkstra 1968].
В числе первых исследователей нельзя не упомянуть Бринч Хансена [ 1973], кото
рый разработал операционную систему с семафорами и механизмом обмена сооб
щениями, и Хоара [1974], создавшего концепцию монитора, которая реализует
принцип сокрытия информации применительно к синхронизации задач. Для под
держки взаимодействия и синхронизации параллельных задач было предложено
несколько алгоритмов для предотвращения тупиковых ситуаций, в частности ал
горитм нескольких читателей и писателей, алгоритм спящего парикмахера, алго
ритм обедающих философов и алгоритм банкира. Многие оригинальные труды
уже не переиздаются. Но поскольку идеи параллельной обработки имеют фун
даментальный характер, на протяжении трех десятилетий они многократно опи
сывались в разных учебниках. Лучший источник информации о параллелизме -
это книги по операционным системам, например [Silberschatz and Galvin 1998;
Tanenbaum 1992], или по параллельным языкам программирования, таким как Java
[Lea 1999] или Ada [Barnes 1995]. Следует упомянуть также два прекрасных спра
вочных руководства: книгу [Bacon 1997], в которой описываются параллельные сис
темы - как централизованные, так и распределенные, и издание [Magee and Kramer
1999], посвященное параллельному программированию на языке Java.
3.5.1. Преимущества параллельного выполнения задач

Параллельное выполнение задач (многозадачность) имеет следующие пре
имущества:
□ многозадачность естественно возникает во многих реальных приложениях,
поскольку отражает параллелизм, имеющий место в предметной области,
когда несколько процессов протекают одновременно. Для таких приложе
ний целевую систему лучше всего с самого начала проектировать с явным
определением параллелизма. Проект, в котором явно выделены параллель
ные задачи, оказывается прозрачнее и проще для понимания, поскольку
дает более реалистичную модель предметной области, нежели последова
тельная программа;
Q разбиение параллельной системы на задачи позволяет отделить вопрос
о том, что делает задача, от вопроса о том, когда она это делает. Обычно при
этом получается система, которую проще понять, создавать и сопровождать;
Параллельная обработка г'. й й Ц -Ц
□ в систел up дставленной в виде совокупности параллельных задач, общее
время выполнения может оказаться меньше. При работе на одном процес
соре повышение производительности достигается за счет выполнения опе
раций ввода/вывода параллельно с вычислениями. Задействуя несколько
процессоров, тот же результат можно получить за счет реального паралле
лизма, поскольку разные задачи исполняются на разных процессорах;
□ разбиение системы на параллельные задачи повышает гибкость планирова
ния, так как критичным по времени задачам легко назначить более высокий
приоритет;
□ выделение параллельных задач на ранних стадиях проектирования помога
ет своевременно провести анализ производительности системы. Многие
предназначенные для этого инструменты и методики (например, сети Пет
ри и планирование в реальном времени) принципиально основаны на ана
лизе параллельных задач.
Следует, однако, подчеркнуть, что, хотя многозадачность и рекомендуется для
многих реальных приложений, наличие слишком большого числа задач может
неоправданно увеличить сложность и накладные расходы из-за дополнительных
затрат на взаимодействие и синхронизацию. О том, как справиться с этой пробле
мой, рассказано в главе 14.
3.5.2. Тяжеловесные и облегченные процессы

Термин процесс применяется в операционных системах для обозначения еди
ницы выделения ресурсов процессора и памяти. В традиционной операционной
системе процесс представлял собой один поток управления и потому не обладал
внутренним параллелизмом, В некоторых более современных ОС процесс (назы
ваемый тяжеловесным процессом - heavyweight process) может иметь несколько
потоков управления (threads), что создает предпосылки для внутреннего паралле
лизма. Тяжеловесному процессу выделяется память. Каждый поток управления,
называемый также облегченным процессом (lightweight process), делит эту память
с тяжеловесным процессом. Поэтому разные потоки в тяжеловесном процессе
могут обращаться к разделяемым данным в памяти процесса, хотя такой доступ
необходимо синхронизировать.
Термины «тяжеловесный» и «облегченный» относятся к величине накладных
расходов на контекстное переключение. Когда операционная система переключа
ется с одного тяжеловесного процесса на другой, накладные расходы оказывают
ся довольно заметными, причем требуются как ресурсы процессора, так и память.
Для облегченного процесса достаточно выделить только процессор, что значи
тельно дешевле.
Терминология, применяемая в разных ОС, различается, но обычно тяжеловес
ный процесс называют просто процессом (или задачей), а облегченный процесс -
потоком. Например, виртуальная машина Java в большинстве случаев исполня
ется как процесс операционной системы, поддерживающий несколько потоков
68 Концепции проектирования ПО и архитектуры
[ Magee and Kramer 1999]. Однако в некоторых операционных системах отсутству
ет информация о том, что в тяжеловесном процессе есть внутренние потоки, и про
цессор выделяется только для процесса в целом. В таком случае процесс должен
самостоятельно планировать потоки.
Бейкон (Bacon) использует термин «процесс» для обозначения динамической
сущности, исполняемой процессором и имеющей собственный поток управления.
Он не различает тяжеловесный процесс и поток внутри него. В данной книге для
обозначения такой динамической сущности применяется термин задача. Задача
соответствует потоку внутри тяжеловесного процесса (то есть процессор испол
няет именно задачу) или однопоточиому тяжеловесному процессу. Многие дета
ли, касающиеся взаимодействия задач, не зависят от того, идет речь о потоках
внутри одного или нескольких процессов. Планирование задач и контекстное пе
реключение более подробно обсуждаются в следующей главе.
3.6, Кооперация между параллельными задачами

При проектировании параллельных систем приходится рассматривать вопро
сы, которые не возникают в последовательных системах. В большинстве парал
лельных систем задачи должны работать совместно для предоставления сервисов,
необходимых приложению. Обычно при организации такого кооперативного по
ведения задач появляются следующие проблемы:
□ проблема взаимного исключения. Она возникает, когда задачам нужен моно
польный доступ к некоторому ресурсу, скажем к разделяемым данным или
физическому устройству. Иногда ограничение взаимного исключения мож
но ослабить, как, например, в задаче о нескольких читателях и писателях;
□ проблема синхронизации задач. Две задачи должны синхронизировать свою
работу;
□ проблема производителя/потребителя. Актуальна, когда задачи должны пе
редавать друг другу данные. Такой обмен сведениями между задачами часто
называют межпроцессной коммуникацией (Inter-Process Communication -
IPC).
Методы решения этих проблем описываются ниже.
3.6.1. Проблема взаимного исключения

Взаимное исключение возникает, если необходимо, чтобы в каждый момент
времени только одна задача имела доступ к некоторому ресурсу. В параллельных
системах несколько задач могут одновременно затребовать ресурс. Рассмотрим,
например, следующие ситуации:
□ если двум или более задачам разрешено одновременно выводить данные на
принтер, то посылаемая ими информация будет случайным образом чере
доваться, так что в результате получится нечитаемый документ;
Кооперация между параллельными задачами iйЯ И И И Ш Я
□ если двум или более задачам разрешено одновременно записывать данные
в некоторое хранилище, то там окажутся несогласованные или некоррект
ные данные.
Для решения этой проблемы необходимо предоставить механизм синхрониза
ции, который гарантирует, что доступ к критическому ресурсу будет в каждый мо
мент времени разрешен только одной задаче (взаимное исключение). Задача долж
на сначала захватить ресурс, получив разрешение на доступ, использовать его,
а затем освободить. После того как задача А освободит ресурс, его может захватить
другая задача В. Если ресурс используется задачей А в момент, когда В пытается
захватить его, то В будет вынуждена ждать, пока А не закончит работу с ресурсом.
В классическом решении проблемы взаимного исключения, впервые предло
женном Дейкстрой [Dijkstra 1968], использовались двоичные семафоры. Двоич
ный семафор - это булевская переменная, для доступа к которой существуют
только две атомарные (то есть неделимые) операции: acquire (semaphore) -
захватить, release (semaphore) - освободить. Дейкстра называл эти операции
Р (захват) и V (освобождение).
Задача выполняет неделимую операцию acquire (semaphore), когда хочет
захватить ресурс. Первоначально семафор установлен в единицу - ресурс свобо
ден. После выполнения операции acquire значение семафора становится рав
ным нулю, и ресурс передается задаче. Если семафор уже равен нулю в момент
выполнения операции acquire задачей А, значит, его захватила какая-то другая
задача В. В таком случае задача А приостанавливается до тех пор, пока задача В
не освободит семафор, выполнив операцию release. Затем ресурс поступает
в распоряжение задачи А. Следует отметить, что задача, выполняющая операцию
acquire, приостанавливается только тогда, когда ресурс уже захвачен другой за
дачей. Код, выполняемый задачей в тот интервал времени, когда она монопольно
владеет ресурсом, называется критической секцией или критической областью.
3.6.2. Пример взаимного исключения

В качестве примера взаимного исключения рассмотрим разделяемое храни
лище, в которое помещаются данные, считываемые с различных датчиков. Одни
задачи берут данные из хранилища для обработки или отображения, другие
опрашивают датчики и записывают в хранилище последние показания. Чтобы
обеспечить взаимное исключение, заведем семафор sensor Data Repository
Semaphore, защищающий хранилище. Прежде чем получить доступ к хранили
щу данных, каждая задача должна выполнить операцию acquire, а после завер
шения работы с хранилищем - операцию release. Вот псевдокод для захвата
семафора перед входом в критическую секцию и освобождения его после выхода:
acquire (sensorDataRepositorySemaphore)
Обратиться к хранилищу показаний датчиков (это критическая
секция)
release (sensorDataRepositorySemaphore)
70 тшшА: Концепции проектирования ПО и архитектуры
В приведенном решении предполагается, что начальные значения счетчиков
уже сохранены перед тем, как производится попытка их чтения.
В некоторых параллельных приложениях запрет на любой одновременный
доступ к разделяемому ресурсу - слишком сильное ограничение. Так, в только что
рассмотренном примере задача-писатель безусловно должна иметь монопольный
доступ к хранилищу на все время записи. Но читать из хранилища могут сразу
несколько задач при условии, что никакая задача не будет в это время обновлять
его. Перед нами классическая проблема нескольких читателей и писателей [Bacon
1997; Silberschatz and Galvin 1998; Tanenbaum 1992]. Ее тоже допустимо решить
с помощью семафоров, о чем речь пойдет в главе 16.
3.6.3. Проблема синхронизации задач

Синхронизация по событию используется тогда, когда две задачи должны син
хронизировать свою работу, не обмениваясь при этом данными. Одна из задач
выполняет операцию s i g n a l ( e v e n t ), которая сигнализирует о факте наступле
ния события. Синхронизация по событию асинхронна. В UML две такие задачи
изображаются в виде активных объектов и асинхронного события-сигнала, кото
рое отправитель посылает получателю (рис. 3.9).
Задача-получатель выполняет операцию w a i t ( e v e n t ), приостанавливая тем
самым свою работу до получения события от отправителя. Если сигнал о поступ
лении события уже пришел, задача-получатель не приостанавливается.
signal (event) wait (event)
Рис. 3.9. Синхронизация события с помощью сигнала о наступлении события
3.6.4. Пример синхронизации задач

Рассмотрим пример синхронизации по событию, взятый из параллельной ро
бототехнической системы. Каждая подсистема, спроектированная как параллель
ная задача., управляет движением механической руки. Подъемно-транспортный
робот подносит деталь к рабочей зоне, чтобы другой робот просверлил в ней от
верстия. Когда это сделано, первый робот убирает деталь.
Необходимо разрешить несколько проблем синхронизации. Во-первых, есть
зона конфликта, в которой руки подъемно-транслортного и сверлильного робота
могут столкнуться. Во-вторых, рука подъемно-транспортного робота должна поло
жить деталь, прежде чем сверлильный робот приступит к работе. В-третьих, подъем
но-транспортный робот должен убрать деталь только после того, как сверлильный
закончит работу. Решение заключается в использовании события синхронизации.
Кооперация между параллельными задачами | 71
Подъемно-транспортный робот перемещает деталь в рабочую зону, выводит
руку из зоны конфликта и сигнализирует событию детальПодготовлена. Это
приводит в действие сверлильный робот, который перемещается в рабочую зону
и сверлит отверстия. Закончив, он выходит из зоны конфликта и сигнализирует
другому событию детальОбработана, которого ожидает подъемно-транспорт
ный робот. Получив сигнал, этот робот убирает деталь. Каждая задача робота ис
полняется в цикле, поскольку машины бесконечно повторяют данные операции.
Решение можно записать следующим образом (рис. 3.10):
Подъемно-транспортный робот:
while естьРабота do
Взять деталь
Переместить деталь в рабочую зону
Отпустить деталь
Переместить руку в безопасное положение
signal (детальПодготовлена)
wait (детальОбработана)
Убрать деталь из рабочей зоны
end while;
Сверлильный робот:
wait (детальПодготовлена)
Переместить руку в рабочую зону
просверлить четыре отверстия
Переместить руку в безопасное положение
signal (детальОбработана)
end while;
детальПодготовлена
«задача»
«задача»
подъемно
ч------ ---- сверлильныйРобот
ТранспортныйРобот
детальОбработана
Рис. 3.10. Пример синхронизации с двумя событиями
Рассмотрим теперь ситуацию, когда подающий робот передает деталь прини

мающему роботу. Здесь тоже возможно столкновение двух рук в зоне конфликта,
по теперь мы уже не в состоянии запретить это, поскольку в момент передачи оба
робота держат одну и ту же деталь.
В таком случае следует разрешить двигаться в зоне конфликта только одному
роботу. Сначала один робот перемещается в зону конфликта. Затем он сигнализи
рует другому, что достиг точки передачи, после чего тот также входит в зону кон
фликта. Д ля этой цели используется событие зонаКонфликтаВезопасна. По
дающий робот сигнализирует второму событию - детальПодготовлена, чтобы
известить принимающего робота о том, что он готов к передаче. Во время пере
дачи применяются еще два события - детальЗахвачена и детальОтпущена.
Н *-' Концепции проектирования ПО и архитектуры
Передача детали должна осуществляться так же точно, как передача эстафетной
палочки. Решение показано на рис. 3.11 и описывается следующим псевдокодом:
Подающий робот (робот А ) :
Переместиться к границе зоны конфликта
wait (зонаКонфликтаБезопасна)
Переместиться в точку передачи
signal (детальПодготовлена)
wait (детальЗахвачена)
Раскрыть захват для освобождения детали
signal (детальОтпущена)
wait (зонаКонфликтаБезопасна)
Выйти из зоны конфликта
end while;
Принимающий робот (робот В ) :
Переместиться в точку передачи
signal (зонаКонфликтаБезопасна)
wait (детальПодготовлена)
Сомкнуть захват для взятия детали
signal (детальЗахвачена)
Выйти из зоны конфликта
signal (зонаКонфликтаБезопасна)
Переместить деталь
end while;
детальПодготовлена детальОтпущена
л. -------- л
«задача» «задача»
роботА ---------- роботВ
зонаКонфликта детальЗахвачена
Рис. 3.11. Пример синхронизации с четырьмя событиями
Синхронизировать задачи можно также с помощью обмена сообщениями,

о чем будет сказано ниже.
3.6.5. Проблема производителя/потребителя

Проблема производителя/потребителя часто встречается в параллельных сис
темах. Задача-производитель выдает информацию, которая затем используется
задачей-потребителем. Таким образом, необходимо передать данные от произво
дителя потребителю. В последовательной программе вызывающая операция (про
цедура) транслирует данные вызываемой операции в качестве параметров. Одна
ко при этом вместе с данными передается и управление.
В параллельной системе у каждой задачи есть свой поток управления, и зада
чи выполняются асинхронно. Поэтому, если задачи хотят обменяться данными,
Кооперация между параллельными задачами ..Л Н 1 Ш Ш
им необходимо синхронизироваться: производитель должен выработать инфор
мацию до того, как потребитель задействует ее. Если потребитель готов принять
данные, но у производителя их еще нет, потребитель должен ждать производите
ля. Если производитель имеет данные, а потребитель еще не готов их принять, то
либо производитель должен подождать, либо данные следует поместить в очередь
для потребителя. В последнем случае производитель может продолжать работу.
Обычно для решения описанной проблемы используется обмен сообщениями
между производителем и потребителем. Он служит двум целям: передаче данных
от производителя (источника) потребителю (получателю), а также синхрониза
ции производителя и получателя (если сообщения нет, то потребитель должен
ждать его прибытия; в некоторых случаях производитель ожидает ответа от по
требителя).
Обмен сообщениями между задачами может быть слабо или сильно связан
ным. Задачи способны разворачиваться в одном узле или в разных, если речь идет
о распределенном приложении.
В случае слабо связанного обмена производитель посылает сообщение потре
бителю и продолжает работу, не дожидаясь ответа. Слабо связанный обмен сооб
щениями еще называют асинхронным.
В случае сильно связанного обмена производитель отправляет сообщение
и продолжает работу, а затем приостанавливается до тех пор, пока не получит от
вет. Слабо связанный обмен сообщениями называют также синхронным или ран
деву (в языке Ada).
3.6.6. Слабо связанный обмен сообщениями

В случае слабо связанного (асинхронного) обмена сообщениями производитель
посылает потребителю сообщение и либо вовсе не интересуется ответом, либо
продолжает работать, рассчитывая получить ответ позже. Потребитель принима
ет сообщение. Поскольку задачи производителя и потребителя работают с различ
ной скоростью, то для буферизации сообщений между ними используется F IF O -
очередь (первым пришел, первым обслужен). Если в момент, когда потребитель
запрашивает сообщение, его не оказывается, потребитель приостанавливается.
Пример слабо связанного обмена сообщениями приведен на рис. 3.12. Задача-
производитель посылает сообщения задаче-потребителю. Между ними может су
ществовать очередь. Сообщение помечено стереотипом «асинхронное сообще
ние». Параметры сообщения заключаются в скобки: m e s s a g e ( p a r a m e t e r ] .,
p a ra m e te r2 ).
сообщение
«задача»
----- Jb «задача»
задачаПроизводитель задачаПотребитель
send (message) receive (message)
Р ис. 3.12. Слабо связанный (асинхронный) обмен сообщениями

74 ■ ■ 1 1 1
Концепции проектирования ПО и архитектуры
3.6.7. Сильно связанный обмен сообщениями с ответом

В случае сильно связанного (сигарочного) обмена сообщениями с ответом про
изводитель посылает сообщение потребителю и ждет ответа. Приняв сообщение,
потребитель обрабатывает его, формирует ответ и отправляет производителю.
После этого и производитель, и потребитель продолжают прерванное действие.
Производитель приостанавливается до тех пор, пока не получит ответ. Потреби
тель приостанавливается, если нет никакого сообщения. Между данной парой
производитель/потребитель очереди не существует.
Пример сильно связанного (синхронного) обмена сообщениями с ответом
представлен на рис. 3.13. Производитель посылает сообщение потребителю. По
лучив сообщение, потребитель отправляет производителю ответ. Сообщение по
мечено стереотипом «синхронное сообщение с ответом». Параметры сообщения
вносятся в скобки: m e s s a g e ( p a r a m e t e r ! , p a r a m e te r 2 ). Ответ изображается
в виде отдельного сообщения со стрелкой, которая указывает в сторону, противо
положную направлению исходного сообщения.
«синхронное сообщение с ответом»

сообщение
«задача» «задача»
задачаПроизводитель ----- задачаПотребитель
ответ

ждать ответа send (reply)
Рис . 3.13. Сильно связанный ( синхронный) обмен сообщениями с ответом
3.6.8. Сильно связанный обмен сообщениями без ответа

В случае сильно связанного (синхронного) обмена сообщениями без ответа про
изводитель посылает сообщение потребителю и ждет, пока адресат его получит.
Приняв сообщение, потребитель подтверждает получение, тем самым освобождая
производителя. После этого и производитель, и потребитель продолжают работу.
Потребитель приостанавливается, если нет никакого сообщения. Между данной
парой производитель/потребитель не существует никакой очереди.
Пример сильно связанного (синхронного) обмена сообщениями без ответа
представлен на рис. 3.14. Производитель отправляет сообщение потребителю
и ждет подтверждения. Сообщение помечено стереотипом «синхронное сообщение
«синхронное сооощение оез ответа»

сообщение
«задача» — ► «задача»
задачаПроизводитель задачаПотребитель
Р и с. 3.14. Сильно связанный ( синхронный) обмен сообщениями без ответа

Кооперация между параллельными задачами ..» ■ ■ ■ ■ ! 75
без ответа». Параметры сообщения записываю тся в скобках: m e s s a g e ( p a
r a m e t e r ] ., parameter2).
3.6.9. Пример обмена сообщениями

между производителем и потребителем
В качестве примера сильно связанного обмена сообщениями с ответом рас
смотрим систему машинного зрения, которая информирует робота о типе детали
на конвейере, например о том, пришел ли кузов «Седана» или «Универсала». Для
каждого типа кузова у робота есть своя программа сварки. Кроме того, система
машинного зрения должна передать роботу сведения о положении и ориентации
детали на конвейере. Обычно такая информация представляется в виде смещения
относительно точки, известной обеим системам. Система машинного зрения посы
лает роботу сильно связанное сообщение идентификаторАвтомобиля, которое
содержит идентиф икаторМ одели и идентиф икаторС м ещ енияК узова, а затем
ждет ответа. Робот извещает о завершении сварки посылкой сообщения Готово.
Кроме того, нужна синхронизация по событию. В начальный момент датчик
сигнализирует внешнему событию поступилАвтомобиль, извещая систему ма
шинного зрения. В конце система машинного зрения сигнализирует событию
убратьАвтомобиль, которое приводит в действие привод, перемещающий кон
вейер. Это решение представлено на рис. 3.15 и пояснено псевдокодом ниже.
идентификаторАвтомобиля
I
... «задача»
системаРобота
...............................................................■..
4— ---------- .
Рис. 3.15. Пример Готово
обмена сообщениями
Система машинного зрения:

wait (поступилАвтомобиль)
Распознать корпус автомобиля
Идентифицировать модель
Определить положение и ориентацию корпуса
s e n d идентификаторАвтомобиля (идентификаторМодели,
смещениеКорпуса) Системе робота
wait f o r reply-
signal (убратьАвтомобиль)
end while;
Система робота:
Ждать сообщения от системы машинного зрения
receive идентификаторАвтомобиля (идентификаторМодели,
смещениеКорпуса)
76 1 И Г-: Концепции проектирования ПО и архитектуры
Выбрать программу сварки для указанной модели
Выполнить программу сварки, учитывая положение, заданное
параметром смещениеКорпуса
send (Готово) Системе машинного зрения
end w h ile ;
3.7. Сокрытие информации

в применении к синхронизации доступа
Описанное выше решение проблемы взаимного исключения уязвимо для оши
бок. Неточность в коде одной из задач, осуществляющих доступ к разделяемым дан
ным, может послужить причиной серьезных сбоев синхронизации во время ис
полнения. Рассмотрим, например, проблему взаимного исключения, описанную
в разделе 3.6.2. Если случайно поменять местами операции захвата и освобождения,
то псевдокод будет выглядеть так:
r e l e a s e (sensorDataRepositorySemaphore)
Обратиться к хранилищу показаний датчиков (это критическая
секция)
acquire (sensorDataReposi torySemaphore)
В результате задача войдет в критическую секцию, не захватив предваритель
но семафор. Это значит, что в критической секции разрешено одновременное ис
полнение двух задач, что нарушает принцип взаимного исключения. Вероятна
и другая ошибка:
acquire (sensorDataRepositorySemaphore)
Обратиться к хранилищу показаний датчиков (ото критическая
секция)
a c q u i r e (sensorDataRepositorySemaphore)
Теперь в первый раз задача входит в критическую секцию, но затем не может

ее покинуть, так как пытается захватить семафор, которым уже владеет. Более
того, она не дает войти в критическую секцию другим задачам, что приводит к т у
пиковой ситуации, когда ни одна задача не в состоянии продолжать выполнение.
В этих примерах синхронизация оказывается глобальным фактором, о кото
ром должны помнить все задачи, что снижает надежность решения. С помощью
сокрытия информации проблема глобальной синхронизации сводится к локаль
ной задаче, уменьшая вероятность ошибок. При таком подходе о синхронизации
должен беспокоиться только объект, скрывающий информацию, - его часто на
зывают монитором [Ноаге 1974], см. раздел 3.8.
3.7.1. Классы и объекты, скрывающие информацию

Скрывающие информацию классы используются для инкапсуляции хранилищ
данных, то есть сокрытия их содержимого и внутреннего представления. Задача
получает доступ к хранилищу опосредованно, с помощью операций (процедур или
„..М ож еторы .. <■ Л И 77
функций доступа), которые им манипулируют. Ьсли к скрывающему информа

цию классу обращается сразу несколько задач, то его операции синхронизируют
доступ к данным.
Скрывающий информацию объект - это экземпляр скрывающего информа
цию класса, он изображается на диаграмме кооперации. Пример такого объекта,
к которому обращаются две задачи, показан на рис. 3.16. Задача Писатель запи
сывает данные в объект, а задача Читатель считывает их. В обоих случаях для
обозначения синхронизации применяется нотация UML, причем стрелка направ
лена от задачи к объекту. Важно отметить, что в данном контексте сообщение - это
на самом деле вызов операции. Объект предоставляет две операции - read и write.
Писатель вызывает операцию write, а Читатель - операцию read. При вызове
read данные возвращаются вызывающей задаче в виде выходного параметра.
write read
Рис. 3.16. Обмен данными между задачами с помощью объекта,

скрывающего информацию
3.8. Мониторы
М онитор объединяет концепции сокрытия информации и синхронизации.
Монитор - это объект, который инкапсулирует данные и имеет взаимно исклю
чающие операции. Критическая секция каждой задачи заменяется вызовом опе
рации монитора. С каждым монитором неявно ассоциируется семафор, который
называется замком монитора. Таким образом, в любой момент времени в монито
ре может находиться не более одной задачи. Обращение к любой операции мони
тора приводит к тому, что вызывающая задача захватывает ассоциированный
с ним замок. Однако, если замок уже захвачен, задача блокируется до тех пор, пока
не сможет получить его. Выход из монитора приводит к освобождению замка,
который может быть захвачен другой задачей. Взаимно исключающие операции
монитора называют еще охраняемыми операциями или синхронизированными ме
тодами (в языке Java).
3.8,1. Пример монитора

Рассмотрим описанное выше хранилище данных. Инкапсулируем его в скры
вающий информацию объект Хранилище Аналогового Датчика, который под
держивает операции чтения и обновления. Эти операции вызываются любой за
дачей, которой нужен доступ к хранилищу. Детали синхронизации скрыты от
вызывающих задач.
ш т ш ш ш у Концепции проектирования ПО и архитектуры
Монитор предоставляет взаимно а п иочающий доступ к хранилищу показа
ний аналоговых датчиков, Имеются две взаимно исключающие операции для чте
ния и обновления содержимого хранилища. Вот первая из них:
readAnalogSensor (in sensorlD, out sensorValue, out sensorValue,
out lowerLimit, out alarmCondition)
Описанная операция вызывается задачами, которые хотят прочитать данные
из хранилища. По указанному идентификатору датчика операция возвращает зна
чение показателя, верхний и нижний пределы и условие тревоги клиенту, жела
ющему обработать или отобразить эту информацию. Диапазон между нижним
и верхним пределом - область, в которой показания не свидетельствуют об ава
рии. Если же значение показателя меньше нижнего или больше верхнего предела,
то условие тревоги принимает значение нижнего или верхнего предела соответ
ственно. Вторая операция
updateAnalogSensor (in sensorld, in sensorValue)
вызывается задачами, которые хотят записать показания датчика в хранилище.
Операция проверяет, не оказалось ли значение показателя меньше нижнего или
больше верхнего предела, и, если это так, устанавливает условие тревоги равным
верхнему или нижнему пределу соответственно. Если же значение находится
в безопасном диапазоне, то условие тревоги сбрасывается.
Псевдокод взаимно исключающих операций выглядит так:
m o n i t o r Ana.1оg Sen sor R ер оs it;о гу
readAnalogSensor (in sensorlD, out sensorValue, out sensorValue,
out lowerLimit, out alarmCondition)
sensorValue := sensorDataRepository (sensorlD, value);
upperLimit := sensorDataRepository (sensorlD, upLim);
lowerLimit := sensorDataRepository (sensorlD, loLim);
alarmCondition := sensorDataRepository (sensorlD, alarm);
end readAnalogSensor;
updateAnalogSensor (in sensorld, in sensorValue)
sensorDataRepository (sensorlD, value) := high;
if sensorValue >= sensorDataRepository (sensorlD, upLim)
t h e n sensorDataRepository (sensorlD, alarm) := high;
e l s e if sensorValue <= sensorDataRepository (sensorlD, loLim)
then sensorDataRepository (sensorlD, alarm) ;= low;
e l s e sensorDataRepository (sensorlD, alarm) := normal;
end i f ;
end updateAnalogSensor;
e n d AnalogSensorRepository;
3.8.2. Условная синхронизация

Помимо синхронизированных операций мониторы поддерживают также услов
ную синхронизацию. Это позволяег задаче, выполняющей взаимно исключающую
операцию, заблокировать себя, закончив операцию w a it, которая будет ждать, пока
Шаблоны проектирования ■ г ш ш т 79
не станет истинным некоторое булевское условие: например, пока не заполнится
буфер или, наоборот, пока он не станет пустым. Когда находящаяся в мониторе за
дача блокируется, она освобождает замок, позволяя захватить его другой задаче.
Заблокированная в мониторе задача пробуждается другой задачей, закончившей
операцию s i g n a l (в языке Java она называется n o t i f y ) . Например, если задача-
читатель хочет прочитать данные из буфера, а буфер пуст, она выполняет wa i t . Чи
татель остается заблокированным, пока писатель не поместит в буфер информа
цию и не пошлет s i g n a l .
Если операционная среда не поддерживает семафоров, то взаимно исключаю
щий доступ к ресурсам можно реализовать с помощью мониторов с условной син
хронизацией. В таком случае монитор инкапсулирует булевскую переменную
b u sy , которая описывает состояние ресурса. Задача, которая хочет захватить ре
сурс, вызывает операцию a c q u ir e . Если ресурс занят, эта задача приостанавлива
ется в результате выполнения w a it. По завершении ожидания задача устанавлива
ет флаг b u s y в t r u e , тем самым захватывая ресурс. Закончив работу с ресурсом,
задача вызывает операцию r e l e a s e , которая сбрасывает b u s y в f a l s e и вызывает
s i g n a l для пробуждения ожидающей задачи (если таковая имеется).
Вот как выглядит схема применения монитора для реализации взаимно ис
ключающего доступа к ресурсу:
monitor Semaphore
-- Объявляем булевскую переменную busy
-- и инициализируем ее значением false,
private busy : Boolean = false;
-- Вызываем acquire для захвата ресурса.
-- Вызывающая задача приостанавливается, если ресурс занят,
public acquire ()
while busy = true d o w a i t ;
busy := true;
end acquire;
-- Вызываем release для освобождения ресурса.
-- Если другая задача ждет ресурса, она продолжит выполнение,
public release ()
busy := false;
s ig n a l;
e n d release;
e n d Semaphore;
Другие примеры мониторов и условной синхронизации приведены в главе 16.
3.9. Шаблоны проектирования

Шаблон проектирования описывает некую распространенную проблему проек
тирования, способ ее решения и контекст, в котором это решение используется
| Buschmann et al. 1996; Gamma et al. 1995J. Описание дается в терминах взаимодей
ствующих объектов и классов, адаптированных для решения конкретной задачи
ттшт Концепции проектирования ПО и архитектуры
в данном контексте. Шаблон проектирования - это более i р) иное образование, чем
класс, поскольку включает несколько классов и схему взаимодействия объектов
различных классов. Иногда такой шаблон называют микроархитектурой.
Обычно в описании шаблона приводятся:
□ название шаблона;
□ синонимы;
□ контекст, в котором следует применять шаблон;
□ краткое описание проблемы;
□ краткое описание решения;
□ сильные стороны решения;
□ слабые стороны решения;
□ ситуации, в которых можно использовать шаблон;
□ родственные шаблоны.
Проблема производителя/потребителя, о которой шла речь в разделе 3.6, - это
пример постоянно возникающей в проектировании задачи, которую можно доку
ментировать в виде шаблона. Так, шаблон слабо связанного обмена сообщениями
описывается следующим образом:
□ название шаблона. Слабо связанный обмен сообщениями;
□ синоним. Асинхронный обмен сообщениями;
□ контекст. Параллельные системы;
□ проблема. Приложение с параллельными задачами, которые должны взаи
модействовать друг с другом. Производитель не обязан дожидаться ответа
от потребителя, он вовсе не нуждается в ответе;
□ краткое описание решения. Использовать очередь сообщений между зада
чами производителя и потребителя. Производитель посылает сообщение
потребителю и продолжает работу. Потребитель получает сообщение. Со
общения могут помещаться в F IF O -очередь, если потребитель занят. Потре
битель приостанавливается, если сообщений нет;
□ сильные стороны. Потребитель не задерживает производителя;
□ слабые стороны. Если производитель продуцирует сообщения быстрее, чем
потребитель способен их обрабатывать, то в конечном итоге возникнет пе
реполнение очереди;
□ применимость. Централизованные и распределенные среды: системы реаль
ного времени, клиент-серверные и распре/деленные приложения;
□ родственные шаблоны. Сильно связанный обмен сообщениями с ответом
или без ответа.
3.10. Программные архитектуры

и компонентные системы
Программная архитектура [Shaw and Garlan 1996; Bass, Clements, and Kazman
1998] отделяет общую структуру системы, выраженную в терминах компонентов
. . .. -....... ........... рез,олле ... т ш т ш т
и взаимодействий между ними, от внутренних деталей реализации отдельных
компонентов. Акцент на компонентах и взаимодействиях иногда называют про
граммированием в общем, а детальное проектирование отдельных компонентов -
программированием частностей.
3.10.1. Компоненты и разъемы

Чтобы полностью описать компонент, необходимо определить операции, ко
торые он предоставляет, и операции, которые он потребляет [Magee, Dulay, and
Kramer 1994; Shaw and Garlan 1996]. При традиционном объектно-ориентирован-
ном подходе нужно описать лишь операции, которые объект предоставляет. Од
нако, если мы хотим интегрировать готовый компонент в систему, составленную
из компонентов, то не менее важно знать, а стало быть, и явно документировать
операции, которые ему требуются.
Помимо компонентов, в программной архитектуре должны быть определены
разъемы, с помощью которых компоненты объединяются. Разъем (connector) ин
капсулирует протокол взаимодействия двух или более компонентов. Некоторые
виды обмена сообщениями между задачами были описаны в разделе 3.6, в том
числе слабо связанный и сильно связанный обмен. Протоколы взаимодействия
для каждого вида коммуникаций можно инкапсулировать в разъеме. Разъем, ин
капсулирующий коммуникацию между задачами, которые работают в одном узле
(к примеру, на основе буферов в разделяемой памяти), может отличаться от разъ
ема между задачами, функционирующими в разных узлах (при этом сообщения
п о с ы л а л и с ь б ы ПО ССТИ), ХОТЯ о б а ОНИ ЛОГИЧЕСКИ ЭКВИВаЛбНТКЫ С Л аб о СВ Я 3 ciН К ОМ V
обмену сообщениями. Разъемы для распределенных приложений описываются
в главе 13. Проектирование разъемов с помощью мониторов и условной синхро
низации составляет содержание главы 16.
3.10.2. Компонентные системы

В компонентных системах существует инфраструктура, специально предна
значенная для использования готовых компонентов. Ранее созданные компонен
ты интегрируются с другими. Чтобы это стало возможным, они должны соответ
ствовать конкретному стандарту, выдвигаемому программной архитектурой.
Д ля взаимодействия между объектами, работающими на гетерогенных плат
формах, проектируются механизмы брокеров, например CORBA [Mowbray and
Ruh 1997]. Серверные объекты предоставляют сервисы, которые могут быть за
прошены клиентами через посредство брокера объектных запросов (Object Re
quest Broker - ORB). Инфраструктура для поддержки компонентных систем по
дробно рассматривается в следующей главе.
3.11. Резюме
В этой главе описаны ключевые концепции проектирования параллельных объект-
но-ориентированных систем, а также некоторые важные концепции, относящиеся
82 ! « H № Концепции проектирования ПО и архитектуры
к разработке архитектуры таких систем. Упомянутые здесь объоктно-ориентирован-
ные концепции закладывают основу для нескольких последующих глав. Стати
ческие структурные аспекты классов с точки зрения анализа подробнее рассмотре
ны в главе 8 (статическое моделирование) и в главе 9 (структурирование классов
и объектов); о динамических аспектах взаимодействия объектов говорится в гла
ве 11. Взгляд на классы с точки зрения проектирования представлен в главе 15.
О выделении параллельных задач и проблемах взаимодействия между ними речь
пойдет в главе 13, посвященной архитектуре распределенных приложений. Про
ектирование отдельных задач описано в главах 12 и 13. И наконец, инфраструкту
ра для поддержки параллельных и распределенных приложений рассматривается
в главе 4.
Глава 4 „ Технологии иараяяеяьиыж
и расиредеяеииыж смстеи
В этой главе мы остановимся на инфраструктуре, то есть технологии параллель
ной и распределенной обработки, которая нужна в приложениях реального вре
мени и в распределенных приложениях. Инфраструктуру обеспечивают операци
онная система, вычислительная сеть и ПО промежуточного слоя. Сначала мы
рассмотрим поддержку мультипрограммирования и симметричного мультипро
цессирования со стороны операционной системы и дадим дополнительную ин
формацию о планировании задач и устройствах ввода/вывода. Затем опишем тех
нологию организации сред распределенной обработки. Сюда входят технологии
клиент-сервер и W W W (World Wide Web - Всемирная паутина). В этой главе
рассказывается также о стеках сетевых протоколов ISO и TC P/IP, рассматрива
ются сервисы распределенных операционных систем и технологии создания про
межуточного ПО, в частности RPC, RMI, CORBA и Java Beans. Кроме того, речь
пойдет о системах обработки транзакций.
4.1. Среды для параллельной обработки

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

В мультипрограммной (или многозадачной) среде несколько задач разделяют
единственный процессор. Виртуальный параллелизм обеспечивается операцион
ной системой, которая управляет выделением процессора отдельным задачам, так
что создается иллюзия, будто у каждой задачи есть свой процессор. Пример муль
типрограммной среды приведен на рис. 4.1. Здесь изображены плата процессора
(Ц П ) и плата памяти (их может быть несколько). В памяти хранятся коды и дан
ные каждой задачи, а также самой операционной системы. Платы соединены меж
ду собой системной шиной. В примере система включает также два устройства
ввода/вывода, дисплей и датчик, все они подключаются к шине с помощью ин
терфейсных карт, на каждой из которых имеется контроллер устройства.
4.1.2. Симметричная мультипроцессорная среда

В симметричной мультипроцессорной среде есть два или несколько процес
соров с общей памятью. Д ля всех процессоров существует единое физическое
шшттшш Параллельные и распределенные системы
Рис. 4.1. Мультипрограммная среда (с одним процессором)
адресное пространство, поэтому все процессы находятся в общей памяти. В такой

среде поддерживается реальный параллелизм, поскольку процессоры работают
одновременно. Задачи, исполняемые на разных процессорах, могут обмениваться
информацией с помощью разделяемой памяти. Мультипроцессорная среда пока
зана на рис. 4.2.
Рис. 4.2. Симметричная мультипроцессорная среда
4.1.3, Распределенная среда

На рис. 4.3 показана типичная распределенная среда, где есть несколько уз
лов, связанных между собой сетью, Каждый узел - это компьютер с собственной
локальной памятью, который обычно представляет собой мультипрограммную
(см. рис. 4.1) или симметричную мультипроцессорную (см. рис. 4.2) среду. Кроме
того, в каждом узле имеется сетевая карта. Важным отличием распределенной
среды является то, что у узлов нет общей памяти. Следовательно, распределенное
приложение состоит из параллельных процессов, работающих в разных узлах.
Каждый процесс может иметь несколько потоков, исполняемых в том же узле. По
скольку разделяемой памяти нет, то процессы в разных узлах должны обменивать
ся информацией, посылая сообщения по сети.
Поддержка мультипрограммной среды ЩЩШШШШШКШ
Рис. 4.3. Распределенная среда
4.2. Поддержка исполнения в мультипрограммной

и мультипроцессорной средах
Поддержка исполнения параллельных вычислений реализуется:
□ ядром операционной системы. Оно предоставляет сервисы, необходимые
для параллельной обработки. В некоторых современных операционных сис
темах минимальную поддержку дает микроядро, а все остальное - систем
ные задачи;
□ системой времени исполнения в языке программирования, поддерживаю
щем параллелизм;
□ пакетом для поддержки потоков. Предоставляет сервисы, необходимые для
управления потоками (облегченными процессами) внутри тяжеловесного
процесса.
В языках, ориентированных на последовательное программирование, напри
мер С, C++, Pascal и Fortran, нет встроенной поддержки параллелизма. Поэтому
при разработке параллельных многозадачных приложений на этих языках прихо
дится прибегать к помощи ядра или библиотеки потоков.
В параллельных языках программирования, скажем Ada или Java, имеются
конструкции для поддержки взаимодействия и синхронизации задач. В таком
случае система времени выполнения, являющаяся частью языка, отвечает за пла
нирование задач и предоставление необходимых сервисов.
4.2.1. Сервисы операционной системы

Ядро операционной системы обычно предоставляет следующие сервисы:
□ вытесняющее планирование с приоритетами. Задача с наивысшим приори
тетом исполняется, как только она будет готова, - например, если ее акти
визирует прерывание ввода/вывода;
□ межзадачную коммуникацию посредством сообщений;
□ взаимное исключение с помощью семафоров;
тттшмш^ Параллельные и распределенные системы
□ синхронизацию по событию с использованием сигналов. Вместо этого для
синхронизации могут применяться сообщения;
□ обработку прерываний и базовые сервисы ввода/вывода;
□ управление памятью. Эта подсистема отвечает за отображение виртуальной
памяти каждой задачи на физическую память.
В качестве примеров широко распространенных систем с поддержкой парал
лелизма в ядре можно назвать несколько версий UNIX (в том числе Linux, Solaris
и AIX), Windows 98, Windows NT и Windows 2000.
Если имеется поддержка в ядре, то операции send m e s s a g e и receive
message для обмена сообщениями, а также wait и signal для синхронизации
по событию реализуются как прямые вызовы ядра. Взаимно исключающий до
ступ к критическим секциям обеспечивается операциями над семафорами acquire
и release, которые также предоставляет ядро.
4.2.2. Стандарт POSIX

POSIX (Portable Operating System Interface Standard - стандарт переносимо
го интерфейса операционной системы) - это стандарт разработки программного
обеспечения операционных систем, принятый IEEE. Обычно его называют POSTX
1003. POSIX основан на операционной системе UNIX - наиболее распространен
ной переносимой ОС. POSIX 1003.1 определяет базовые сервисы операционной
системы, POSIX 1003.1 b - расширения для режима реального времени, a POSIX
1003.1с - расширения для параллельной обработки.
Стандарт POSIX 1003.1 задает библиотечные функции, которые должна поддер
живать любая POSIX-совместимая система UNIX, например open, read и fork.
POSIX 1003.1b определяет стандартный интерфейс операционной системы реаль
ного времени: системные вызовы, списки параметров и информацию о состоянии,
возвращаемую каждым вызовом.
В стандарте POSIX 1003. lb указаны следующие сервисы:
□ сервисы для управления параллельными задачами.
Следующие три сервиса предоставляют средства для обмена информацией
между задачами и для синхронизации:
- двоичные семафоры;
- сигналы реального времени;
- передача сообщений. Этот сервис позволяет задаче с наивысшим приори
тетом получать процессор по первому запросу, а значит, гарантирует быс
трую реакцию для наиболее критичных по времени задач;
- вытесняющее планирование с приоритетами;
□ сервисы времени.
Следующий сервис важен для реализации событий таймера с высоким раз
решением и выполнения измерений в системах реального времени:
- часы и таймеры реального времени;
Поддержка мультипрограммной среды * 3
□ сервис л ^арчвления память о:
- захват памяти задачей (см. следующий раздел);
- файлы, проецируемые на память, и разделяемая намять;
□ сервисы ввода/вывода:
- синхронный ввод/вывод;
- асинхронный ввод/вывод. Этот сервис необходим для реализации пере
крытия между процессорными вычислениями и вводом/выводом.
Стандарт POSIX 1003.1с добавляет к PO SIX спецификацию параллельных
потоков, которые позволяют программе запускать несколько экземпляров проце
дуры, выполняемых в раздельных потоках управления (задачах). Исполняемая
программа представляет собой тяжеловесный процесс, имеющий собственное ад
ресное пространство. Поток внутри него - это облегченный процесс.
В терминологии POS1X тяжеловесные процессы называются просто процес
сами, а облегченные процессы - потоками (thread). Все потоки внутри данного
процесса функционируют в одном и том же адресном пространстве.
4.2.3. Операционные системы реального времени

Многие функции, применяемые в параллельных операционных системах, необ
ходимы также и в распределенных. Большинство систем реального времени поддер
живают ядро или микроядро. Однако у распределенных систем есть особые характе
ристики, связанные главным образом с необходимостью обеспечить предсказуемое
поведение. Полезнее рассмотреть требования к операционной системе реального
времени, чем пытаться дать обзор существующих систем, поскольку их число посто
янно изменяется. Итак, операционная система реального времени должна:
□ поддерживать многозадачность;
□ реализовывать вытесняющее планирование с приоритетами. Это означает,
в частности, что у каждой задачи должен быть свой приоритет;
□ предоставлять механизмы синхронизации и обмена информацией между
задачами;
□ давать задачам возможность захвата памяти. В системах реального времени
с жесткими временными ограничениями параллельные задачи обычно на
ходятся в памяти целиком. Это устраняет неопределенность и разброс во
времени отклика, обусловленные подкачкой страниц. Механизм захвата па
мяти позволяет задаче с жесткими ограничениями по времени выполнения
разместиться в оперативной памяти, не опасаясь, что операционная систе
ма выгрузит ее;
□ включать механизм наследования приоритета. Когда задача А входит в кри
тическую секцию, ее приоритет должен быть повышен (см. главу 17). В про
тивном случае задача А может быть вытеснена другой высокоприоритетной
задачей, которая не сумеет войти в эту же критическую секцию, поскольку
она занята задачей А Таким образом, высокоприоритетная задача окажется
навечно заблокированной;
88 Параллельные и распределенные системы
□ иметь предсказуемое поведение (например, при выполнении контекстного
переключения, синхронизации задач и обработке прерываний). Это означа
ет, что максимальное время отклика должно быть прогнозируемо при лю
бой ожидаемой нагрузке на систему.
Недавнее исследование системы Windows NT 4.0 показало, что она не удовлет
воряет требованиям, предъявляемым к системе реального времени [Timmerman
1998b], и что Windows СЕ 2.0 удобнее для небольших встраиваемых приложений
[Timmerman 1998а]. Однако существует много специализированных операцион
ных систем реального времени, в том числе pSOS, VRTX и iRMX. Растет также
число систем реального времени, совместимых со стандартом POS1X: это, напри
мер, LynxOS, QNX и HP-RT. Кроме того, есть системы, доводящие Windows NT
до уровня системы реального времени: RTX, INTime и Hyperkernel [Timmerman
1998b],
4.3. Планирование задач

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

Цель циклического алгоритма планирования - обеспечить справедливое вы
деление ресурсов. Задача ставится в очередь, поддерживающую принцип «первым
пришел - первым обслужен» (FIFO ). Задаче, находящейся в начале списка гото
вых, назначается процессор, которым она может' владеть в течение фиксирован
ного промежутка времени, называемого квантом. Если квант времени истек до
того, как задача приостановилась сама (например, в ожидании завершения ввода/
вывода или сообщения), то ее приостанавливает ядро, после чего задача помеща
ется в конец списка готовых. Затем ЦП выделяется другой задаче, оказавшейся
в начале списка.
Д ля систем реального времени циклическое планирование не годится. Спра
ведливое распределение ресурсов - это не главное, задачам нужно назначать при
оритеты в соответствии с важностью выполняемых операций. Так, критичные по
времени задачи обязательно должны уложиться в отведенные временные рамки.
Поэтому для систем реального времени больше подходит алгоритм вытесняюще
го планирования с приоритетами. Каждой задаче назначается приоритет, и спи
сок готовых упорядочивается по значению этого приоритета. ЦП выделяется за
даче с наивысшим приоритетом. Затем эта задача выполняется до тех пор, пока не
приостановится сама либо не будет вытеснена задачей с большим приоритетом
(которая только что возобновила работу). Задачам с одинаковыми приоритетами
ЦП выделяется по циклическому алгоритму. Следует отметить, что при вытесня
ющем планировании с приоритетами квантование времени не применяется.
Планирование задач !1 1 Ц Ц ^ |
4.3,2. Состояния задач

Рассмотрим различные состояния, которые проходит задача с момента созда
ния до момента завершения (рис. 4,4), Эти СОСТОЯНИЯ поддерживаются многоза
дачным ядром, где применяется алгоритм вытесняющего планирования с приори
тетами.
Рис. 4.4. Диаграмма состояний параллельной задачи
Новая задача сразу оказывается в состоянии «Готова» и помещается в список

готовых. Когда она передвигается в начало данного списка, ей выделяется ЦП,
и задача переходит в состояние «Исполняется». Потом она может быть вытеснена
другой задачей и снова окажется в состоянии «Готова»; в этот момент операцион
ная система перенесет ее в нужное место в списке готовых.
Случается и так, что находящаяся в состоянии «Исполняется» задача будет заб
локирована и перейдет в то или иное состояние блокировки. Блокировка вызывает
ся ожиданием завершения ввода/вывода, ожиданием сообщения от другой задачи
или ожиданием разрешения войти в критическую секцию. Заблокированная задача
перейдет в состояние «Готова», как только будет устранена причина блокировки.
-м щ , Параллельные и распределенные системы
4.3.3. Контекстное переключение задач

Если задача приостанавливается из-за блокировки или потому что ее вытес
нили, необходимо сохранить текущий контекст, то есть состояние процессора.
Сюда относятся аппаратные регистры, счетчик команд задачи (который указыва
ет на следующую команду, подлежащую выполнению) и другая информация. Ког
да задача снова получит ЦП, контекст требуется восстановить. Эта последователь
ность операций называется контекстным, переключением.
В мультипроцессорной среде с разделяемой памятью копия ядра обычно вы
полняется на каждом процессоре. Процессор выбирает задачу, находящуюся в на
чале списка готовых. Взаимно исключающий доступ к списку обеспечивает аппа
ратный семафор, который обычно реализуется с помощью команды Test and Set
Lock (проверить и установить замок). Таким образом, одна и та же задача может
в разные моменты времени исполняться на разных процессорах. В некоторых
мультипроцессорных средах потоки одного многопоточного процесса могут па
раллельно выполняться на разных процессорах. Подробнее о планировании за
дач рассказывается в книгах по операционным системам, например [N utt 1991;
Silberschatz and Galvin 1998; Tanenbaum 1992J, или в книгах по распределенным
системам, в частности [Bacon 1997].
4.4. Вопросы ввода/вывода

в операционной системе
Ниже рассматриваются способы, которые операционная система применяет
для работы с устройствами ввода/вывода. Существует два механизма выполне
ния ввода/вывода: прерывания и опрос. Цель этого раздела - рассказать о том,
как параллельные задачи взаимодействуют с внешними устройствами. Подроб
нее о вводе/выводе можно прочитать в [Bacon 1997; Tanenbaum 1992], а примени
тельно к распределенным системам - в [Burns and Wellings 1996].
4.4.1. Контроллеры устройств

Устройства ввода/вывода общаются с операционной системой при помощи кон
троллеров, которые находятся на интерфейсных платах устройства (см. рис. 4.1
и 4.2). Центральный процессор работает именно с контроллером, а не с самим ус
тройством. У контроллера есть набор регистров, используемых для обмена инфор
мацией с ЦП. В некоторых компьютерах имеются специальные команды для дос
тупа к регистрам контроллера. Если же применяется отображение устройств на
память, то регистры контроллера представляются в виде обычных ячеек адресно
го пространства.
Пример простого контроллера устройства ввода/вывода приведен на рис. 4.5.
Здесь показаны буфер ввода, в котором может храниться один входной символ,
и буфер вывода, также позволяющий хранить не более одного выходного симво
ла. Кроме того, есть регистры управления и состояния. Поместив символ в буфер
Ввод/вывод в операционной системе | 91
цп
«системная шина»
Контроллер Устройства
Ввода/Вывода
Буфер Ввода
Буфер Вывода
Регистр Управления
Терминал
Регистр Состояния Ввода/Вывода
Рис. 4.5. Организация контроллера устройства ввода/вывода
ввода, контроллер взводит бит в регистре состояния, показывающий, что буфер

ввода полон. При выводе используется другой бит, свидетельствующий, что по
лон буфер вывода. После вывода символа контроллер сбрасывает этот бит. Биты
состояния применяются для управления передачей данных между процессором
и устройством (см. следующий раздел).
В регистре управления есть бит, разрешающий или запрещающий прерыва
ния. Если они разрешены, то контроллер генерирует прерывание, как описано
ниже. В противном случае процессор должен опрашивать устройство, проверяя
биты состояния.
Драйверы устройств исполняются центральным процессором и отвечают за
работу с устройствами ввода/вывода через их контроллеры. Обычно для каждого
типа устройства существует один драйвер. Драйверы стандартных устройств, та
ких как клавиатура, дисплей, диск и строчный принтер, поддерживаются ядром;
драйверы специализированных устройств, которые часто встречаются в распре
деленных приложениях, обычно входят в состав прикладного ПО.
4.4.2. Обработка прерываний

Если ввод/вывод управляется прерываниями, то при поступлении входных
данных и завершении операции вывода генерируется прерывание. Есть множест
во способов, но наиболее распространены ввод/вы вод с управлением от про
граммы и ввод/вывод, запускаемый программой. В первом случае прерывание
обычно генерируется после чтения или записи каждого символа, во втором между
устройством ввода/вывода и основной памятью помещается устройство прямого
доступа к памяти (D irect Memory Access - DMA), управляющее передачей бло
ков данных между ними. По завершении передачи устройство DMA генерирует
прерывание.
При поступлении прерывания ЦП приостанавливает выполнение текущей
задачи, сохраняет ее контекст и вызывает обработчик прерывания (предполагает
ся, что приоритет такого обработчика выше, чем приоритет задачи). Когда обра
ботка закончена, контекст прерванной задачи восстанавливается и она может про
должать функционирование.
В подсистеме ввода/вывода, которая является частью ядра, обработчики пре
рываний (или программы обслуживания прерываний) занимают низший уровень.
Обработчик должен определить, какую задачу следует активизировать при поступ
лении прерывания, и передать ей управление с помощью одного из поддерживае
мых ядром механизмов синхронизации. При таком подходе драйве]) устройства
можно реализовать в виде параллельной задачи. Драйвер обязан знать специфику
обращения с контроллером данного устройства ввода/вывода.
Рассмотрим обмен данными между задачей и контроллером устройства посред
ством описанных выше регистров контроллера. В случае ввода драйвер устройства
ввода посылает контроллеру команду прочитать символ, а затем приостанавлива
ется до тех пор, пока снова не будет активизирован обработчиком прерывания. Кон
троллер получает символ от внешнего устройства, помещает его в буфер ввода,
устанавливает в регистре состояния бит «буфер ввода полон» и генерирует пре
рывание. Обработчик получает ото прерывание и пробуждает задачу драйвера.
Драйвер считывает символ из буфера ввода и устанавливает в регистре состояния
бит «буфер ввода пуст».
В случае вывода драйвер устройства вывода помещает символ в буфер выво
да, взводит в регистре состояния бит занятости и посылает контроллеру команду
вывести символ. Затем драйвер приостанавливается. Контроллер выводит сим
вол из буфера на внешнее устройство, сбрасывает бит занятости и генерирует пре
рывание. Обработчик получает прерывание и пробуждает задачу драйвера, кото
рая может вывести следующий символ.
В некоторых системах поступление прерывания сразу активизирует задачу
драйвера без вмешательства низкоуровневого обработчика прерываний. В таком
случае драйвер обрабатывает прерывания самостоятельно.
4.4.3. Ввод/вывод с опросом

Когда используется ввод/вывод с опросом, прерывания отсутствуют. Поэто
му система должна периодически проверять устройство ввода, чтобы понять, не
пришли ли новые данные, или устройство вывода, чтобы выяснить, завершилась
ли операция.
При вводе с опросом задача драйвера должна опрашивать устройство ввода, то
есть периодически проверять, не поднят ли бит «буфер ввода полон» в регистре
состояния. Контроллер взводит этот бит, когда есть новые входные данные. Обна
ружив, что бит поднят, драйвер устройства считывает символ и сбрасывает бит.
Технологии клиент-серверных систем [^ Щ Н Я Н Е З
При выводе драйвер устройства инициир; а затем периодически про
веряет бит «буфер вывода пуст», чтобы узнать, когда завершилась операция. Об
наружив, что бит поднят, драйвер может приступить к выводу следующего сим
вола.
4.5. Технологии клиент-серверных

Распределенные приложения исполняются на географически разнесенных
узлах, соединенных локальной или глобальной сетью. Типичные примеры - при
ложения клиент-сервер, распределенные приложения сбора данных в реальном
времени и распределенные приложения, занимающиеся управлением. В остав
шейся части этой главы мы расскажем о технологии, применяемой для создания
клиент-серверных и распределенных приложений.
4.5.1. Конфигурации клиент-серверных

Клиент-серверная система логически состоит из двух компонентов: клиента,
который запрашивает сервисы, и сервера, который эти сервисы предоставляет.
Таким образом, сервер выступает в роли производителя, а клиент - в роли потре
бителя сервисов. Клиент-серверная система - это распределенное приложение,
в котором клиент и сервер (или серверы) географически удалены друг от друга
(рис. 4.6). Сеть, соединяющая клиентов с серверами, может быть локальной или
глобальной. Клиент посылает серверу запрос по сети. Сервер выполняет этот за
прос и возвращает клиенту результаты.
Рис. 4.6. Базовая конфигурация системы клиент-сервер
Обычно клиенты и серверы работают на разных машинах. Они могут быть реа
лизованы на разных платформах, под разными операционными системами и в раз
личных сетях. Клиент - это, как правило, настольный ПК или рабочая станция.
Часто он поддерживает графический интерфейс пользователя (ГИП). У сервера
обычно имеется большой объем памяти н дисков, мощный процессор и средства
повышения надежности, Помимо управления данными, он предоставляет услуги
прикладного характера, В простейшей системе клиент-сервер имеется один сер
вер и много клиентов. Типичный пример такого рода - приложение, которое об
служивает банкоматы, принадлежащие одному банку. Здесь банкоматы разме
щены на территории одного штата и обмениваются данными с центральным
банковским сервером.
В более сложной системе работает несколько серверов. Клиент может обра
щаться к различным серверам, а сами серверы -- друг к другу (рис. 4.7). Если
продолжить пример с банкоматами, то в качестве многосерверного приложения
допустимо рассмотреть систему федерального уровня, где любой банкомат в со
стоянии общаться с любым банковским сервером, входящим в систему. В много
уровневых клиент-серверных системах сервер иногда выступает в роли клиента
другого сервера.
Рис. 4.7. Конфигурация для распределенной обработки
В распределенном приложении помимо трафика между клиентом и сервером

обычно присутствует’ обширный трафик между равноправными узлами на основе
асинхронного обмена сообщениями. Примером такого приложения может слу
жить система автоматизации производства, описанная в главе 21.
Рост числа клиент-серверных и распределенных систем вызван некоторыми
тенденциями в производстве оборудования, в частности увеличением мощности
процессоров настольных ПК, снижением стоимости микросхем и ростом объема
памяти - как оперативной, так и дисковой. Кроме того, повышается быстродей
ствие вычислительных сетей, стремительно развивается Internet.
Что касается ПО, следует отметить широкое распространение реляционных
баз данных, предоставляющих распределенный доступ к информации, графичес
ких интерфейсов и многозадачных приложений на платформе Windows, а также
технологий ПО промежуточного слоя, которые упрощают соединение распреде
ленных гетерогенных систем (см. раздел 4.8).
На рис. 4.8 приведен пример возможной конфигурации системы клиент-сервер.
В одном узле развернуто клиентское приложение с графическим интерфейсом
Технологии клиент-серверных систем B H I
пользователя. О но работает под управлением стандартной ОС типа Windows 98
и пользуется стандартным коммуникационным ПО, например T C P/IP. Поверх
операционной системы и коммуникационного ПО имеется программный слой, об
разующий ПО промежуточного слоя (middleware). В другом узле развернуто сер
верное приложение, пользующееся сервисами, которые предоставляет аналогич
ное ПО промежуточного слоя, размещенное поверх операционной системы (UNIX
или Windows NT). Для долговременного хранения информации применяется фай
ловая система или СУБД.
Клиентский Узел Серверный Узел
Клиентское Прикладное
ПО / Графический Интерфейс Серверное Прикладное ПО
ПО Промежуточного Слоя ПО Промежуточного Слоя
Операционная Система Операционная Система, СУБД
Коммуникационное ПО Коммуникационное ПО
У
«сеть»
Рис. 4.8. Технология клиент-сервер
4.5.2. Коммуникационные сетевые протоколы

Чаще всего в книгах по программированию упоминается эталонная много
уровневая архитектура взаимодействия открытых систем, разработанная Между
народной организацией по стандартизации (ISO OSI). Она является стандартом
сетевых коммуникаций между открытыми системами1 (рис. 4.9). В модели ISO
семь уровней, каждый из которых отвечает за определенный аспект сетевых ком
муникаций и предоставляет интерфейс в виде набора операций уровню, располо
женному непосредственно над ним [Tanenbaum 1996]. Д ля каждого уровня в узле-
отправителе есть эквивалентный уровень в узле-получателе.
В модели ISO нет специального уровня для протоколов Internet. В сети
Internet наиболее широкое распространение получил набор протоколов T C P /IP
[Comer 1999]. Этот стек концептуально состоит из пяти уровней, показанных на
рис. 4.10. Уровни 1 и 2 - физический и интерфейсный - соответствуют модели
ISO. Физический уровень имеет дело с базовым сетевым оборудованием. Интер
фейсный уровень определяет, как данные группируются во фреймы и как такие
фреймы передаются но сети. На третьем - межсетевом - уровне определяется
формат пакетов данных, передаваемых через Internet, и механизмы прохождения
1Это явное преувеличение. Модель ISO OSI называется эталонной и когда-то претендова
ла па роль стандарта, по в современных сетях практически не используется, будучи вы
теснена стеком протоколов T C P/IP. - Прим. перев.
Рис. 4.9. Семиуровневая эталонная модель ISO
Рис. 4,10. Пять уровней модели TCP/IP
пакетов через цепочку маршрутизаторов от отправителя к получателю. Узел марш

рутизатора на рис. 4.1] - это шлюз, соединяющий локальную сеть с глобальной.
Транспортный уровень собирает пакеты в том порядке, в каком они были по
сланы, и формирует из них сообщение. TC P (Transmission Control Protocol) - это
протокол транспортного уровня, работающий совместно с протоколом IP (Internet
Protocol) межсетевого уровня. Уровень IP предоставляет ненадежный сервис от
правки датаграмм, TC P должен на его основе предоставить надежный сервис. Он
организует виртуальное соединение между приложениями в двух узлах, то есть яв
ляется так называемым сквозным (end-to-end) протоколом (см. рис. 4.11). Для
транспорта сообщений TCP пользуется протоколом 1Р. Уровень 5 называется при
кладным, на нем реализованы различные сетевые приложения, например переда
ча файлов (FTP), электронная почта и W W W .
Технология World Wide W e: ^ ШШШ1
Уровень 5 I Прикладной Уровень 5 Прикладной
Транспортный Транспортный
Уровень 4 Уровень 4
(TCP) (TCP)
Уровень 3 Межсетевой (IP) Уровень 3^ Межсетевой (IP) У р о в е н ь ^ Межсетевой (IP)
Уровень 2 Интерфейсный Уровень 2 Интерфейсный Уровень 2 Интерфейсный
Уровень 1 Физический Уровень 1 Физический Уровень 1 Физический
Узел маршрутизатора
«локальная сеть» «глобальная сеть»
Примечание. Пунктирные стрелки на этом рисунке нарисованы только для иллюстрации и не имеют отношения к нотации UML.
Рис. 4.11. Обмен данными через сеть Internet по протоколам TCP/IP
4.6. Технология World Wide Web

Огромная популярность Всемирной паутины (W W W ), придуманной Бернер-
сом-Ли [Berners-Lee et а,1.1994] из Европейской организации по ядерным исследо
ваниям (CERN) в Женеве привела к очень быстрому росту сети Internet. Пользова
тель просматривает W W W с помощью браузера типа Netscape Communicator или
Internet Explorer, работающего на машине пользователя. Страницы W W W разме
щены на Web-серверах. Каждая страница обычно содержит графику и ссылки на
другие страницы.
Web-страница создается с помощью язы ка разметки, например широко рас
пространенного языка HTM L (HyperText M arkup Language - язык разметки ги
пертекста) или начавшего приобретать популярность язы ка XML (extensible
M arkup Language - расширяемый язык разметки). Каждая страница помечается
унифицированным указателем ресурса (URL), который используется в составе
любой ссылки на эту страницу. Когда пользователь хочет просмотреть страницу,
браузер берет из URL адрес сервера и обращается к нему с просьбой загрузить
необходимые данные (рис. 4.12). Затем браузер отображает полученную страни
цу на экране. Web-браузер и Web-сервер общаются друг с другом по протоколу
HTTP (HyperText Transfer Protocol - протокол передачи гипертекстовых файлов).
Web-сервер принимает запросы на страницы одновременно от многих клиентов.
Внешний модуль, или вставка (plug-in), - это программа, которая помещается
в браузер и расширяет его возможности - скажем, позволяет обрабатывать аудио-
и видеоданные, посылаемые сервером. Внешний модуль может входить в дистри
бутив браузера или загружаться отдельно с определенного сервера.
ЖШШШ?f Параллельные и распределенные системы
Клиентский Узел vveo Серверный Узел Web
Рис. 4.12. Web-браузвр и Web-сервер в приложении WWW
4.6.1. Язык Java и World Wide Web

С появлением W W W и Web-браузеров в начале 90-х годов браузер стал рас
пространенным пользовательским интерфейсом для распределенных приложе
ний. Рост популярности Всемирной паутины вывел на авансцену язык програм
мирования Java, который широко применяется для создания апплетов.
Java-апплет - это программа на языке Java, которая загружается клиентом
с сервера в виде так называемого байт-кода. Апплет работает совместно с браузе
ром, который интерпретирует полученный код. Чтобы Web-браузер мог успешно
принимать апплеты, он должен поддерживать язык Java. Интерпретатор на сто
роне клиента обрабатывает промежуточный байт-код и генерирует объектный
код, исполняемый клиентом. Итак, Java-апплет - это объект, который загружается
с Web-cepeepa и исполняется клиентом (рис. 4.13). Java-aniuie™ часто используют
ся для анимации Web-страниц. Клиентский Java-объект может также взаимодей
ствовать с серверным объектом, расположенным на том же сервере, с которого был
загружен апплет. Коммуникации между распределенными J ауа-объектами обыч
но осуществляются с помощью технологии RMI (Remote Method Invocation -
вызов удаленных методов), описанной в разделе 4.8.
Java-nporpaM M bi способны работать и на Web-cepeepe, тогда они называются
сервлетами. Сервлеты, как и апплеты, часто тесно интегрированы с Web-серве
ром, чтобы удовлетворить требованиям безопасности и производительности. В на
ши дни, когда к сети Internet стали подключать такие нетрадиционные устрой
ства, как телефоны и банкоматы, появилась острая нужда в сверхтонких клиентах.
Такой клиент состоит из одного браузера. Объекты уровня представления пользо
вательского интерфейса остаются на сервере вместе с бизнес-объектами, реализо
ванными в виде сервлетов.
4.7. Сервисы распределенных

операционных систем
Распределенная система состоит из компьютеров, соединенных коммуни
кационной средой, например локальной сетью [Bacon 1997]. В этом разделе
Распределенные операционные системы Ц
Клиентский Узел Web Серверный Узел Web
Рис. 4.13. Java-эпплет, загружаемый с Web-сервера в приложении WWW
рассматриваются некоторые базовые сервисы, предоставляемые распределенной

операционной системой, дополнительные по отношению к описанным ранее.
4.7.1. Служба имен

В распределенной среде желательно обеспечить независимость сервисов от
местоположения. Это значит, что компонент, желающий послать сообщение дру
гому компоненту, не обязан знать, где находится адресат. Если требовать, чтобы
компонент А явно указывал местоположение компонента В, система получится
негибкой) при перемещении компонента В придется обновлять компонент А. По-
этому необходима глобальная служба именования, обеспечивающая отделение
имен о т местоположения сервисов.
При наличии службы именования сервер имен хранит имена глобальных сер
висов. Предполагается, что местоположение самого сервера имен хорошо извест
но. Каждый сервер регистрирует имена и местоположения предоставляемых им
сервисов у сервера имен. Если клиент хочет получить доступ к некоторому серви
су, он запрашивает информацию о нем у сервера имен.
Пример службы имен - это система доменных имен (DNS), используемая в се
ти Internet [Comer 1999]. Узлам здесь присваиваются уникальные 32-битовые
идентификаторы, называемые 1Р-адресами. IP -адрес записывается в десятичной
нотации, в которой каждые восемь бит кодируются десятичным числом, а сами
числа разделяю тся точками, например 128.174.40.15. Узлу назначается также
уникальное символическое имя, например ise.gnu.edu. Серверы In te rn e t-имен
хранят таблицы, с помощью которых символические имена (называемые также
доменными именами) отображаются на IP -адреса. Поскольку число пользовате
лей Internet очень велико, служба имен распределена между многими серверами.
4.7.2. Связывание клиентов и серверов

Термин связывание относится к ассоциации между клиентом и сервером. Ста
тическое связывание выполняется на этапе компиляции и означает, что все обра
щения клиента к серверу жестко «зашиты» в код.
Динамическое связывание производится во время выполнения. Оно характе
ризуется большей гибкостью, чем статическое, но меньшей эффективностью. Для
динамического связывания необходимо указать имя сервера, который ведет спра
вочник имен и адресов серверов. Каждый сервер регистрирует свое местоположе
ние и предоставляемые сервисы у сервера имен. Клиент посылает запрос серверу
имен, передавая имя серверного объекта, и получает ссылку на него. Затем эта
ссылка используется для доступа к удаленному серверу.
4.7.3. Сервисы распределенного обмена сообщениями

Прозрачный обмен сообщениями между распределенными задачами можно
реализовать с помощью распределенного ядра распределенной операционной сис
темы. На рис. 4.14 приведен пример межзадачной коммуникации с использовани
ем такого ядра. В каждом узле существует один экземпляр распределенного ядра.
Сервер имен хранит главную копию таблицы имен. В тех распределенных прило
жениях, где число задач относительно постоянно, каждое распределенное ядро
также может содержать собственную копию этой таблицы. Н а стадии начальной
загрузки системы распределенное ядро посылает запрос серверу имен с просьбой
загрузить таблицу имен.
Когда задача-отправитель посылает сообщение задаче-получателю, локальное
ядро определяет местоположение адресата по своей таблице имен. Если получа
тель находится в том же узле, что и отправитель, то локальное ядро направляет
сообщение непосредственно по назначению. Так, на рис. 4.14 сообщение от задачи В
доставляется напрямую задаче С, так как обе они работают в узле 1. Если же зада
ча-получатель находится в другом узле, то локальное ядро посылает сообщение
удаленному ядру, расположенному на нужном узле. Получив сообщение, удален
ное ядро переправляет его задаче-получателю. Такая ситуация проиллюстрирова
на на примере задачи А в узле 1, которая посылает сообщение задаче D в узле 2.
ЗадачаА ЗадачаВ ЗадачаС
отправить | отправить h принять принять i

Сообщение 4 Сообщение % I Сообщение Сообщение [
:РаспределенноеЯдро :РаспределенноеЯдро
сообщение •
Рис. 4.14. Прозрачный поиск сервисов в распределенных приложениях

Распределенные операционные системы н м м 101
4.7.4. Сервисы сокетов

Сокеты - это интерфейс прикладных программ (API), предоставляемый мно
гими операционными системами. Он определяет набор операций, доступных при
ложению для организации обмена данными по сети с другим приложением (на
пример, между клиентом и сервером) по заданному протоколу, например TC P/IP.
Сокеты - низкоуровневый механизм коммуникаций, поэтому впоследствии были
разработаны более абстрактные интерфейсы, снимающие с приложения заботу
о низкоуровневых деталях. К их числу относятся RPC (Remote Procedure Call -
вызов удаленных процедур) и различные технологии ПО промежуточного слоя.
4.7.5. Обмен сообщениями через порты

В некоторых распределенных системах обмен сообщениями между удаленны
ми узлами реализован с помощью портов, что позволяет максимально ослабить
связанность. Компонент (процесс или поток) в одном узле посылает сообщение,
не указывая явно имя получателя, а задавая выходной порт. Компонент-получа
тель забирает сообщения из своего входного порта. На стадии конфигурации сис
темы выходной порт одного компонента подключается к входному порту другого
компонента (это называется связыванием). Подобная организация повышает гиб
кость и имеет больше шансов на повторное использование, поскольку на этапе
проектирования компонент не должен явно знать, с кем он будет соединен. Такие
решения принимаются позднее, поэтому экземпляры одного и того же компонен
та могут исполняться в различных средах и приложениях. Механизм обмена со
общениями через порты реализован в нескольких операционных системах, в том
числе V, Mach, CHORUS и Amoeba [Bacon 1997]. В качестве примеров распреде
ленных сред программирования, предоставляющих порты и средства гибкой кон
фигурации, можно назвать Conic [Kramer 1985; Magee, Kramer, and Sloman 1989]
и Regis [Magee, Dulay, and Kramer 1994].
4.7.6. Восстановление после ошибок

Предполагается, что при условии нормальной работы сети сообщение будет
доставлено на удаленный узел. Например, если произошла ошибка четности, то
сетевое коммуникационное ПО (мы включаем его в состав распределенной опе
рационной системы) передаст сообщение повторно. Однако, если удаленный узел
не отвечает в течение заданного времени - из-за разрыва соединения или потому,
что он вышел из строя, - передача будет прекращена по причине тайм-аута. В та
ком случае локальное ядро получит отрицательное подтверждение от коммуни
кационного ПО, свидетельствующее о том, что удаленный узел не получил сооб
щения. При этом локальное ядро известит о неудаче задачу-отправителя. Если
сообщение не доставлено на удаленный узел, то сам отправитель должен решить,
что делать дальше, поскольку такое решение зависит от логики приложения. По
дробнее о распределенных операционных системах рассказывается в изданиях
[Bacon 1997; Tanenbaum 1992].
102 ■ ■ ■ в - Параллельные и распределенные системы
4.8. ПО промежуточного слоя

Распределенным системам часто приходится работать в гетерогенных средах,
когда в разных узлах установлено различное оборудование и операционные сис
темы. Например, когда клиенту на ПК под управлением Windows нужно общать
ся с сервером под управлением системы UNIX. ПО промежуточного слоя - это
слой программного обеспечения, располагаемый поверх ОС с целыо создания од
нородной платформы, на которой могут функционировать распределенные при
ложения [Bacon 1997]. Одной из ранних форм ПО промежуточного слоя был ме
ханизм вызова удаленных процедур RPC. Другие примеры [Orfali, Harkey, and
Edwards 1999] - это система DCE (D istributed Computing Environment - среда
распределенных вычислений), основанная на RPC, технология вызова удаленных
мегодов (R M I) в языке Java, а также технологии СОМ и CORBA.
Предоставляя единообразный метод взаимодействия объектов, технологии
ПО промежуточного слоя, такие как CORBA, СОМ и Java Beans, поощряют по
вторное использование компонентов, поэтому их часто называют компонентны
ми технологиями [Szyperski 1997].
4.8.1. Платформы для распределенных вычислений

Изначально платформы для распределенных вычислений базировались на
модели клиент-сервер. Но в последнее время все большую популярность завое
вывает объектная модель [Bacon 1997]. Коммуникации в модели клиент-сервер
часто основаны на вызове удаленных процедур. При таком подходе процедуры
находятся в адресном пространство ссрвбрй и дистанционно зшгрнш ившотся КЛИ“
ептами. Сервер получает от клиента запрос, активизирует нужную процедуру
и возвращает ответ.
В объектной модели объекты получают глобальные имена и могут вызывать
ся непосредственно на сервере. Существует два подхода к распределенным вычис
лениям: модель распределенных объектов и модель мобильного кода [Bacon 1997].
В первом случае объекты размещаются на сервере и вызываются дистанционно,
как в Java RMI и CORBA. Во втором случае требуемые объекты мигрируют с сер
вера на клиент - ярким примером такого метода служат Jav a-апплеты.
4.8.2. Вызовы удаленных процедур

Некоторые распределенные системы поддерживают механизм вызова удален
ных процедур (R PC). Клиент в одном узле запрашивает удаленную процедуру
сервера, находящегося в другом узле [Bacon 1997; Orfali, Harkey, and Edwards
1999]. Вызов удаленной процедуры аналогичен вызову локальной процедуры,
поэтому тот факт, что сервер находится далеко, скрыт от клиента. Процедура,
необходимая клиенту, часто называется клиентской заглушкой (Client Stub). Она
принимает запрос и произвольные параметры, упаковывает их в сообщение (дан
ный процесс называется маршалингом) и отправляет сообщение серверу.
Удаленная серверная заглушка (Server Stub) распаковывает сообщение (это
действие носит имя демаршалинга) и вызывает нужную процедуру, передавая ей
ПО промежуточного слоя .. ' U lM E l
параметры. Когда серверная „ ^ ^ д у р а заканчивает обработку запроса, она воз
вращает результаты серверной заглушке, которая упаковывает их в ответное со
общение и отправляет клиентской заглушке. Клиентская заглушка извлекает ре
зультаты из сообщения и возвращает их клиенту в виде выходных параметров.
Таким образом, роль клиентской и серверной заглушек сводится к тому, что
бы представить вызовы удаленных процедур так, как если бы они были локаль
ными. На рис. 4.15а изображен объект, обращающийся к локальной процедуре дру
гого объекта. На рис. 4.156 представлено распределенное решение той же задачи,
когда объект на клиентском узле вызывает удаленную процедуру, принадлежащую
объекту на удаленном серверном узле. Локально вызывается клиентская заглуш
ка, которая упаковывает имя и параметры процедуры в сообщение, отправляемое
но сети. Интерфейсный уровень удаленного узла получает сообщение и передает
его серверной заглушке, которая распаковывает сообщение и вызывает указанную
а)
Клиентский Узел
сервис | t (
(запрос) 1 сервис (запрос)
: клиентская
Заглушка
1ие |
сообщение t сообщение сервер
Запрос =т I Ответ
: сетевой
Интерфейс
(ие I
сообщение
Запрос
= t
сообщение f
Ответ
:сетевои
Интерфейс
сообщение I t сообщение
Запрос 4 Ответ
серверная
Заглушка
сервис
1C ,I t!
(запрос)
)С)| |
Серверный Узел
сервер
Рис. 4.15. Вызов процедур: а - локальной; б - удаленной

ГС Е Н Ш , Параллельные и распределенные системы
процедуру серверного объекта. После завершение процедуры серверная заглушка
упаковывает ответ и посылает его по сети. Затем клиентская заглушка распако
вывает сообщение и передает его клиентскому объекту.
4.8.3, Вызов удаленных методов в языке Java

Среда программирования на языке Java (она называется Java Development
Kit - JD K ) поддерживает технологию ПО промежуточного слоя RM1 (Remote
Method Invocation - вызов удаленных методов), которая позволяет распределен
ным Java-объектом общаться друг с другом [Orfali and Harkey 1998]. В этом слу
чае вместо отправки сообщения некоторой процедуре (как в R PC ) клиентский
объект посылает сообщение другому объекту и вызывает метод этого объекта
(процедуру или функцию).
Роль клиентской заглушки из RPC играет клиентский заместитель (Client
proxy) - рис. 4.16. Заместитель предоставляет клиентскому объекту тот же интер
фейс, что и серверный объект, и скрывает от клиента все детали коммуникации.
Соответственно серверный заместитель выполняет функцию серверной заглуш
ки, пряча детали коммуникации от серверного объекта. Серверный заместитель
вызывает метод объекта. Если серверного объекта не существует, заместитель со
здает его.
Разные серверные объекты могут предоставлять один и тот же интерфейс,
а значит, и обслуживать данный запрос клиента. Серверный объект, который бу
дет обрабатывать запрос, выбирается во время выполнения.
4.9. Стандарт CORBA

CORBA (Common Object Request Broker Architecture - единая архитектура
брокера объектных запросов) - это стандарт открытых систем, разработанный
группой Object Management Group (OM G ), который обеспечивает взаимодей
ствие между объектами на гетерогенной платформе [M owbray and Ruh, 1997;
Orfali, Harkey and Edwards 1996]. Брокер объектных запросов (O RB) выполняет
функции ПО промежуточного слоя, поддерживающего отношения вида клиент-
сервер между распределенными объектами. Серверные объекты предоставляют
сервисы, которые клиенты могут запрашивать с помощью ORB. В общем случае
клиенты и серверы - это всего лишь роли объектов. Таким образом, объект спо
собен выступать в роли клиента в отношениях с одним объектом и в роли серве
ра - в отношениях с другим. С помощью ORB клиентский объект в состоянии
вызывать операции серверного объекта, не зная, где тот находится, на какой
платформе (аппаратной или программной) исполняется, какие коммуникацион
ные протоколы нужны для связи с ним и на каком языке он написан.
4.9.1. Брокер объектных запросов

Клиент, имеющий ссылку на серверный объект, может вызывать любые сер
висы (операции интерфейса), поддерживаемые этим объектом, через посредство
ORB. ORB обладает следующими достоинствами:
Стандарт CORBA i.
Клиентский Узел
сервис
(запрос)
:клиентскии
Заместитель
сообщение
ine | Т с сообщение
Запрос= т I Ответ
:сетевои
Интерфейс
сообщенine I
Запрос
= I
сообщение
Ответ
:сетевои
Интерфейс
сообщение I сообщение
Запрос # Ответ
1”
•.серверный
Заместитель
сервисD I Т
(запрос) Серверный Узел
S> t I
сервер
Рис. 4.16. Вызов удаленных методов ( RMI)
□ прозрачностью местоположения. ORB определяет местоположение объекта

по ссылке на него;
□ прозрачностью реализации. Клиент не должен знать, как реализован сервер
ный объект, на каком языке он написан, на какой аппаратной и программ
ной платформе исполняется;
□ прозрачностью состояния выполнения объекта. Если серверный объект не
активен, то ORB активизирует его перед доставкой запроса;
□ прозрачностью коммуникационного механизма. Клиент не знает, какой про
токол будет использовать ORB.
4.9.2. Язык определения интерфейса в CORBA

Интерфейс серверного объекта описывается на языке определения интерфей -
ов (Interface Definition Language - IDL), не зависящем от конкретных языков
Ш И И 1 ». , Параллельные и распределенные системы
программирования. Интерфейс определяется независимо от реализации. Специ
фикации, записанные на IDL, затем переводятся на язык реализации. Реализация
объекта кодируется сразу на целевом языке. Группа OM G разработала стандарт
ные отображения IDL на различные языки программирования, в том числе С,
C++, Ada 95 и Java. Компиляторы IDL генерируют клиентские заглушки и сер
верные каркасы, аналогичные описанным выше клиентским и серверным замес
тителям. Клиентская заглушка создает запрос и передает его от имени клиента.
Серверный каркас получает запрос и доставляет его объекту, реализация которо
го должна удовлетворять правилам CORBA. Функциональность, обеспечиваемая
заглушками и каркасами в CORBA, похожа на заглушки, применяемые в RPC.
Программная заглушка выполняет маршалинг параметров примерно так же,
как при вызовах удаленных процедур. Высокоуровневые типы данных перед от
правкой необходимо упаковать в такие структуры, которые можно передать по
сети, например в поток байтов. Принимающий каркас должен распаковать входя
щее сообщение и вызвать запрошенную операцию серверного объекта.
4.9.3. Статическое и динамическое связывание

В случае статического вызова заглушки и каркасы заранее скомпонованы с ис
полняемыми файлами. Статические интерфейсы определены в TDL-описапиях,
созданных разработчиком. Эти описания транслируются в код заглушек, карка
сов и заголовочных файлов, как определено в правилах отображения на конкрет
ный язык. Такой подход проиллюстрирован на рис. 4.17.
Большую гибкость обеспечивает динамическое связывание. В этом случае
клиентский объект во время выполнения решает, с каким серверным объектом он
Клиентский Узел Клиентский Узел

Серверный Узел
со Статическим Вызовом с Динамическим Вызовом
PI
Реализация
Клиент Клиент
Обьекта
Интерфейс Интерфейс
Клиентская Серверный
Динамического Динамического
IDL-Заглушка IDL-Каркас
Вызова Вызова
Базовые Средства
I
Базовые Средства Базовые Средства
ORB на Стороне ORB на Стороне ORB на Стороне
Сервера Клиента Сервера
Рис. 4.17. Архитектура CORBA

Стандарт CORBA 107
будет общаться. Сервер регистрирует IDL-описания в репозитарии интерфейсов,
который можно опрашивать во время выполнения.
Клиент пользуется интерфейсом динамического вызова (см. рис. 4.17), кото
рый представляет собой обобщенную заглушку, не зависящую от IDL-описания
интерфейса вызываемого объекта. Подобный подход позволяет клиенту обра
щаться к объекту во время выполнения, ничего не зная о его интерфейсе на ста
дии компиляции.
CORBA поддерживает также интерфейс динамического каркаса на стороне
сервера, то есть механизм динамического связывания для серверов, которые долж
ны обрабатывать входящие запросы на обслуживание от объектов, не имеющих
скомпилированных из IDL-описаний каркасов. Это полезно для общения с таки
ми внешними объектами, как шлюзы или браузеры [Midway and Ruh 1997].
4.9.4. Сервисы CORBA

Брокер объектных запросов позволяет клиенту прозрачно вызывать операцию
серверного объекта, предоставляя службу имен. Когда создается объект CORBA,
ему присваивается уникальная объектная ссылка. Получить ссылку можно с по
мощью просмотра каталога. Иными словами, служба имен CORBA дает ссылку
на поименованный объект, а клиент затем вызывает операцию этого объекта.
Служба имен включает такой сервис каталогов, который аналогичен телефонно
му каталогу «белые страницы».
Другой сервис, предоставляемый CORBA - это трейдинг. Он позволяет по
лучить ссылку на объект путем сопоставления характеристик известных объек
тов (например, тина обслуживания) с характеристиками, посланными клиентом.
Сервис трейдинга, следовательно, сводится к сервису каталогов, аналогичному
телефонным «желтым страницам».
4.9.5. Интеграция унаследованных приложений

в каркас распределенных объектов
Многие унаследованные приложения достаточно сложно интегрировать в кар
кас, состоящий из распределенных объектов. Один из применяемых для этой цели
методов состоит в написании объектов-оберток (wrappers). Объект-обертка - это
объект распределенного приложения, который обрабатывает запросы клиентов
к унаследованной программе [Mowbray and Ruh 1997]. Обертки регистрируют
свои сервисы в службе имен, поэтому в состоянии получать запросы от клиентов.
Большинство унаследованных приложений создавались как автономные про
граммы. В некоторых случаях унаследованный код допустимо модифицировать,
чтобы объекты-обертки могли получить доступ к нему. Однако часто это непри
емлемо, так как документации практически нет, а разработчики уже недоступны.
Поэтому обертки обычно общаются с унаследованным кодом при помощи таких
грубых механизмов, как файлы - последовательные или индексированные. Обер
тывающий объект должен читать и модифицировать файлы, создаваемые уна
следованным приложением. Если унаследованное приложение пользуется базой
I
Параллельные и распределенные системы
данных, то к ней легко обратиться с помощью оберто , р вающпх детали до
ступа. Например, в случае реляционной базы данных обертка способна содержать
предложения на языке SQL для доступа к базе. Возможен и такой вариант, когда
обертка имитирует ввод с клавиатуры или переадресует на себя вывод, направ
ленный на экран или принтер.
4.10. Другие компонентные технологии

Помимо CORBA, существуют и другие распределенные технологии, напри
мер ActiveX и СОМ от компании Microsoft и JavaBeans и Jini от компании Sun.
4.10.1. Технология СОМ

DCOM - это предложенная Microsoft распределенная объектная технология,
построенная на основе архитектуры COM (Component Object Model - компонент
ная модель объектов) [Box 1998]. СОМ предоставляет каркас для взаимодействия
приложений в среде Windows. DCOM позволяет клиенту общаться с компонен
том, находящимся в удаленном узле, перехватывая вызовы клиента и переадре-
суя их серверу. И СОМ, и CORBA включают язык 1DL, но CORBA задумана как
стандарт, тогда как СОМ - патентованная технология, работающая только на
платформе Windows.
Компоненты ActiveX - это исполняемые программы, которые согласуются со
стандартом Microsoft СОМ и функционируют на платформе Windows [Shan and
Earle 1998]. Их молено загрузить и выполнить внутри COM -совместимых контей
неров. Примером такого контейнера служит Web-браузер Internet Explorer.
4.10.2. Технология JavaBeans

JavaBeans представляет собой компонентную технологию на базе языка Java,
предназначенную для специализированных приложений [Orfali and Harkey 1998;
Szyperski 1997]. JavaBeans - это компоненты пользовательского интерфейса на
стороне клиента, a Enterprise JavaBeans - компоненты на стороне сервера. Bean -
компонент, состоящий из набора классов и ресурсов.
Из Ьеап-объектов удобно собирать приложения с помощью специального ин
струментального средства. Во время сборки разрешается наблюдать за поведени
ем объекта (это называется интроспекцией) и адаптировать его для конкретных
нужд. Веап-объекты могут генерировать или обрабатывать входящие события.
Инструмент сборки способен определять, какие события генерирует и получает
объект, а также связывать объекты-отправители с объектами-получателями. Адап
тированные и связанные bean-объекты допустимо сохранить для последующего
использования.
4.10.3. Технология Jini

Jini (Java Intelligent Network Infrastructure - сетевая интеллектуальная инфра
структура Java) - это технология соединения для встроенных систем и сетевых
приложений, цель которых - упростить взаимодействие компьютеров и других
Системы обработки транзакций Л 1 Ш :109
устройств. Jini предназначена для сотовых телефонов, цифровых камер, телеви
зоров и видеомагнитофонов. Она использует технологию Java, а устройства со
единяются посредством Java RMI.
Jini предоставляет службу поиска, выступающую в роли брокера между сер-
вис-провайдерами и клиентами. В состав данной технологии, входят также прото
колы для обнаружения, присоединения и поиска ресурсов. Сервис-провайдер, на
пример цифровой видеомагнитофон, регистрируется в службе имен Jini. Поэтому
новый провайдер должен сначала динамически найти службу поиска (эта процеду
ра называется обнаружением), а затем зарегистрироваться в ней (процедура присо
единения). Д ля каждого сервиса, который собирается предоставлять провайдер, он
должен загрузить Java-объект, обеспечивающий интерфейс к данному сервису.
Клиент Jini, скажем цифровая видеокамера, отыскивает службу имен, пользу
ясь протоколом обнаружения. Затем с помощью этой службы клиент находит
нужный сервис - допустим, сервис записи, предоставляемый видеомагнитофо
ном, - после чего загружает из службы поиска Java-объект, который позволит ему
напрямую взаимодействовать с устройством. Таким образом, видеокамера пользу
ется службой имен для поиска сервиса видеомагнитофона, загружает объект за
писи на магнитофон, а затем работает уже непосредственно с магнитофоном.
4.11. Системы обработки транзакций

Приложения для обработки транзакций (или просто транзакционные прило
жения) относятся к классу критических для бизнеса или иной деятельности
[Bacon 1997; Orfali, Hai'key, and Edwards 1999], Сюда входят системы ввода зака
зов, резервирования авиабилетов и кассовые терминалы. Транзакционное прило
жение занимается обновлением информации в базе данных. Нагрузка на такое
приложение обычно предсказуема, значительную долю в ней занимают запросы
на обновление. Известны также требования в периоды пиковой нагрузки, поэто
му можно оценить структуру множества запросов к базе. Некоторые транзакци
онные приложения должны работать постоянно, в других допустимы короткие пе
рерывы.
4.11.1. Характеристики транзакций

Транзакция - это запрос клиента к серверу, состоящий из двух или более опе
раций, которые образуют единую логическую функцию, причем она должна быть
либо выполнена полностью, либо не выполнена вовсе. Транзакции порождаются
клиентом и посылаются серверу для обработки. В классической конфигурации
клиента и сервера обработка целиком возлагается на сервер. В распределенных
приложениях сервер может делегировать одну или несколько операций другим
серверам.
Рассмотрим, к примеру, электронный перевод денежных средств. Чтобы транз
акция считалась завершенной, требуется успешно провести все операции. Если ка-
кую-то операцию осуществить не удается, транзакцию следует отменить. Это озна
чает, что результаты выполнения отдельных составляющих операций необходимо
аннулировать, чтобы система пришла в t п и сост >ш т как будто данная транз
акция и не начиналась.
У транзакций выделяются следующие свойства:
□ атомарность. Транзакция - это неделимая единица работы. Она либо вы
полняется полностью (фиксируется), либо не выполняется вовсе (откаты
вается);
□ непротиворечивость. После завершения транзакции система должна ока
заться в непротиворечивом состоянии;
□ изолированность. На поведение транзакции не должны оказывать влияния
другие транзакции;
□ долговечность, или устойчивость. Изменения сохраняются после заверше
ния транзакции, даже если за ним последует сбой системы.
4.11.2. Мониторы обработки транзакций

Монитор обработки транзакций (T P -монитор) координирует поток инфор
мации между различными клиентами, инициирующими запросы, и приложением
обработки транзакций, которое отвечает на эти запросы. ТР-моииторы уже много
лет существуют на больших ЭВМ. Наиболее широко известна программа CICS
компании IBM, функционирующая с операционными системами и СУБД, кото
рые поставляет IBM.
В гетерогенной клиент-серверной среде T P -мониторы выполняют следующие
действия:
□ посылают и принимают сообщения от клиентов и серверов;
□ управляют потоком транзакций и распределя ют нагрузку между серверами;
□ поддерживают глобальные транзакции, которые относятся к нескольким
распределенным базам данных, в частности гарантируют резервное копиро
вание и восстановление глобальных транзакций;
□ реализуют интерфейс с менеджерами ресурсов, например с ОС и СУБД;
□ предоставляют средства для администрирования системы.
Современные ТР-моииторы, такие как Tuxedo или Enema [Orfali, Harkey, and
Edwards 1999], поддерживают трехуровневую архитектуру клиент-сервер:
□ функциональность клиента. Представление информации и взаимодействие
с пользователем. Например, клиент может находиться на персональном
компьютере;
□ функциональность сервера приложений, поддерживающего бизнес-логику.
Клиент общается с сервером приложений посредством сообщений;
□ управление данными. В частности, реляционная база данных под управле
нием СУБД Oracle может быть распределена между несколькими узлами.
Изоляция клиента от сервера приложений позволяет раздельно проектиро
вать и разрабатывать пользовательский интерфейс и бизнес-логику.
4.12. Резюме
В этой главе представлен обзор технологий параллельной и распределенной
обработки, требующихся для создания параллельных и распределенных прило
жений, а также приложений реального времени. Необходимая инфраструктура
обеспечивается совместно операционной системой, сетью и ПО промежуточного
слоя. Здесь описана поддержка мультипрограммных и симметричных мультипро
цессорных сред со стороны операционной системы, основное внимание уделялось
планированию задач и работе с устройствами ввода/вывода. Более подробную ин
формацию по этим темам можно найти в книгах [Bacon 1997; Silberschatz and
Galvin 1998; Tanenbaum 1992]. Проектирование параллельных задач с использо
ванием перечисленных технологий рассматривается в главе 14. Вопрос о том, как
назначать приоритеты параллельным задачам с жесткими временными ограниче
ниями, детально обсуждается в главе 17 о планировании в реальном масштабе
времени.
Рассказывалось также о технологиях, применяемых для создания сред распре
деленной обработки: к ним относятся технологии клиент-сервер и World Wide
Web. Рассматривались сетевые протоколы ISO и T C P/IP. Кроме того, был приве
ден краткий обзор распределенных операционных систем, а также технологий ПО
промежуточного слоя (RPC, RM I и CORBA) и систем обработки транзакций.
Подробнее о распределенных системах говорится в изданиях [Coulouris, Dollimore,
and Kindberg 1994]; о вычислительных сетях - в [Comer 1999; Tanenbaum 1996];
о распределенных операционных системах - в [Bacon 1997; Silberschatz and Galvin
1998; Tanenbaum 1994]. Информацию о системах клиент-сервер и системах обра
ботки транзакций можно найти в книге [Orfali, Harkey, and Edwards 1999]; о рас
пределенных объектных технологиях - в [Orfali, Harkey, and Edwards 1996; Shan
and Earle 1998; Szyperski 1997]; о CORBA - в [Mowbray and Ruh 1997; Orfali, and
Harkey 1998]; о COM - в [Box 1998]. Проектирование распределенных приложе
ний с применением этих технологий описывается в главе 13.
ГЛ йа! & $ \ );> ЛН ' L Г>ьЧ |! - V'LWM
и методы разраСвтиси
цу> 01 с ^ ’м-- ^
В этой главе разработка программного обеспечения рассматривается с точки зре
ния жизненного цикла. Мы кратко опишем и сравним различные модели жизнен
ного цикла ПО (их еще называют моделями процесса разработки ПО), в том чис
ле спиральную модель и унифицированный процесс разработки IIO, расскажем
о роли верификации и утверждения проекта, а также тестирования программ. Б у
дет рассматриваться эволюция методов разработки ПО, объектно-ориентирован
ного анализа и проектирования, равно как и методы создания параллельных про
грамм и программ реального времени.
5.1. Определение жизненного цикла ПО

Как и все остальные программные продукты, параллельные системы и систе
мы реального времени следует проектировать с помощью той или иной модели
жизненного цикла. Наибольшее распространение получила модель водопада
[Boehm 1976; Fairley 1985]. Ниже речь пойдет о ее основных характеристиках. З а
тем будут рассмотрены и другие модели жизненного цикла, которые создавались
для преодоления недостатков, свойственных модели водопада. Это модели вре
менных прототипов [Agresti 1986; Gomaa 1981b], модель инкрементной разработ
ки (называемая также моделью эволюционирующих прототипов) [Basili and
Turner 1975; Gomaa 1086a] и спиральная модель [Boehm 1988].
5.1.1, Модель водопада
За последние тридцать лет стоимость разработки программного обеспечения
устойчиво росла, тогда как стоимость создания и приобретения аппаратных
средств столь хсе неуклонно падала. Теперь доля ПО в общей стоимости проекта
оценивается примерно в 80%, тогда как ранее безусловно доминировала аппарат
ная составляющая [Boehm 1976; Boehm 1981].
Тридцать лет назад проблема организации создания IIO еще столь ясно не
осознавалась. В конце 60-х годов пришло понимание того, что разработка ПО на
ходится в кризисном состоянии. Тогда и появился термин software engineering
(программотехника, инженерное проектирование программ), которым обознача
ли совокупность административных и технических методов, процедур и инстру
ментальных средств, необходимых для эффективного написания крупномас
штабных программных систем. Идеи программотехники были использованы для
Определение жизненного цикла ПО 113
создания многих крупных проектов, и одной из них стала концепция жизненного
цикла, в основе которой лежит поэтапный подход к разработке ПО, Наибольшее
распространение получила модель водопада, изображенная на рис. 5,1, Обычно ее
считают традиционной, классической моделью жизненного цикла ПО, Эта модель
идеализирует процесс, предполагая, что каждый этап проекта завершается до на
чала следующего и проект поступательно продвигается от одного этапа к другому
без возвратов и перекрытий.
Рис. 5.1. Модель водопада
5.1.2. Недостатки модели водопада

Модель водопада - это, конечно, большой шаг вперед по сравнению с полным
отсутствием модели при работе над ранними программными проектами. На прак
тике, однако, необходимо некоторое перекрытие между последовательными эта
пами жизненного цикла, а также возвраты на предыдущие этапы в случае обнару
жения ошибок. Кроме того, для многих программных проектов применение модели
водопада сопровождается следующими трудностями:
□ требования к программе - ключевой фактор в любом проекте разработки
ПО - не могут быть полностью протестированы, пока не готова система, ко
торую допустимо продемонстрировать пользователям. На самом деле, как
показали некоторые исследования [Boehm 1976], ошибки в спецификациях
требований обычно обнаруживаются в последнюю очередь (зачастую толь
ко на этане тестирования системы или приемо-сдаточных испытаний), а сто
имость их устранения особенно велика;
114 Жизненные циклы и методы разработки ПО
□ работающая система появляется только на поздних атаках жизненного цик
ла. Поэтому серьезная ошибка проектирования или низкая производитель
ность часто остаются незамеченными до момента, когда система будет почти
готова к эксплуатации, - а тогда уже поздно принимать кардинальные меры.
Для программных проектов, в которых велик риск появления ошибок, напри
мер из-за того, что требования не до конца осознаны или могут измениться, были
предложены модели, альтернативные описанной.
С целью преодоления недостатков модели водопада использовались два под
хода к созданию прототипов ПО: временные прототипы (throw aw ay prototypes)
и эволюционирующие прототипы (evolutionary prototypes). Временные прототи
пы позволяют решить первую из двух названных проблем, а эволюционирую
щие - вторую.
5.1.3. Временные прототипы

Временные прототипы можно применять для уточнения требований пользо
вателя [Agresti 1986; Gornaa 1981b]. Особенно полезен этот подход для выясне
ния реакции пользователя на проект интерфейса, так что его стоит задействовать
при создании систем со сложным интерфейсом.
Приступать к разработке временных прототипов лучше после предваритель
ной спецификации требований (рис. 5.2). Дав пользователю возможность поэкс
периментировать с прототипом, вы получите ценнейшую информацию, раздобыть
которую иным способом весьма затруднительно. Высказанные замечания помогут
Рис. 5.2. Использование временных прототипов для уточнения требований

Определение жизненного цикла ПО ^Л$9*|| 115
скорректировать спецификации требований. Дальнейшая разработка протекает
в соответствии с традиционным жизненным циклом.
Временные прототипы (в особенности пользовательского интерфейса) дока
зали свою эффективность при решении проблемы определения требования к ин
терактивным информационным системам. В работе [Gomaa 1981b] описано, как
временный прототип использовался для уточнения требований к системе управ
ления производством с высокой степенью интерактивности. Прежде всего он по
мог устранить коммуникационный барьер между пользователями и разработчи
ками.
Этот подход можно также применять для создания экспериментальных про
тотипов проекта (рис. 5.3). Он способствует решению вопроса о том, являются ли
выбранные алгоритмы логически правильными и достигнута ли требуемая про
изводительность.
Рис. 5.3. Использование временных прототипов

для проверки архитектурных решений
5.1.4. Создание эволюционирующих прототипов

в ходе инкрементной разработки
Подход на основе эволюционирующих прототипов - один из видов инкремент
ной разработки, когда последовательно создаются промежуточные прототипы со
все более широкой функциональностью (рис. 5.4), пока не будет получена готовая
система [McCracken 1982; Gomaa 1986а]. Этот подход помогает при решении во
проса о том, достигнуты ли требуемые показатели производительности, а также при
Рис, 5.4. Жизненный цикл инкрементной разработки ПО
тестировании критически важных компонентов системы. Он также уменьшает

степень риска, растягивая реализацию на более длительный период. При выделе
нии подмножества системы, включаемого в очередное расширение, удобно ис
пользовать диаграммы последовательности событий.
Одна из целей создания эволюционирующих прототипов - получить работа
ющее подмножество системы как можно раньше, а затем наращивать его. Особен
но хорошо, если первую версию системы удается полностью протестировать - от
приема входных данных до получения результата.
Пример создания эволюционирующих прототипов в ходе инкрементной раз
работки описан в книге [Gomaa 1986а]. Применение этого похода к проектирова
нию контроллера робота, функционирующего в реальном масштабе времени
[Gomaa 1986а], позволило получить раннюю действующую версию, что стало
серьезным моральным стимулом для коллектива разработчиков и руководства.
Кроме того, к числу преимуществ следует отнести верификацию проекта систе
мы, уверенность в том, что некоторые ключевые алгоритмы позволяют достичь
требуемой производительности, и постепенное наращивание системы.
5.1.5. Комбинирование временных прототипов

и инкрементной разработки
Применение модели инкрементной разработки позволяет получить действу
ющую систему в виде эволюционирующего прототипа значительно раньше, чем
в случае традиционной модели водопада. Однако на создание таких прототипов
нужно затратить гораздо больше усилий, поскольку на этом этапе закладывается
основа готового продукта, и, значит, на качество IIO надо обращать внимание с са
мого начала. В частности, следует тщательно проектировать архитектуру ПО и ак
куратно специфицировать все интерфейсы.
Внедрение временных прототипов или инкрементной разработки оказывает
серьезное воздействие на традиционный жизненный цикл, основанный на моде
ли водопада. Можно также сочетать оба подхода, как показано на рис. 5.5. Для
- 1r-
Определение жизненного цикла ПО i51И И И Н И Н
Рис. 5.5. Модель жизненного цикла,

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

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

Спиральную модель, основанную на управлении рисками, предложил Боэм
[Boehm 1988] для разрешения известных проблем, свойственных предшествую
щим моделям и, в частности, модели водопада. В спиральной модели радиальная
координата соответствует затратам, а угловая - степени завершенности цикла
модели. Каждый цикл пересекает четыре квадранта (рис. 5.6). В первом квадран
те определяются цели, альтернативы и ограничения на данном цикле. Второй
квадрант - это анализ рисков и оценка альтернатив. В третьем квадранте проис
ходит разработка и верификация продукта очередного уровня. В четвертом пла
нируются задачи, решаемые на следующих этапах.
Рис. 5.6. Спиральная модель процесса разработки

Спиральная модель призвана вобрать в себя другие модели жи ш ни л и ц

ла, в том числе модели водопада, инкрементной разработки и временных прото
типов. На этапе анализа рисков задаются ключевые характеристики проекта -
движители процесса, которые используются при определении того, какая модель
лучше всего подходит для данного проекта. Таким образом, спиральную модель
можно рассматривать в качестве генератора моделей процесса [Boehm 1989].
На каждом цикле спиральной модели осуществляется обход всех четырех
квадрантов. Число циклов зависит от проекта, поэтому описание деятельности
в каждом квадранте намеренно представлено в весьма общей форме, пригодной
для любого цикла.
Цель спиральной модели - управление рисками. Следовательно, анализ рис
ков выполняется в первом квадранте каждого цикла. При управлении рисками
можно запланировать дополнительные виды деятельности, специфичные для
каждого проекта, например создание прототипа требований, если при анализе рис
ков выяснилось, что требования к программному продукту не до конца ясны. Такие
зависящие от проекта риски и называются движителями процесса. Для каждого из
них необходимо предусмотреть те или иные меры, позволяющие снизить риск.
5.1.7. Унифицированный процесс разработки ПО

Унифицированный процесс разработки ПО (The Unified Software Development
Process - USDP) описан в книге [Jacobson, Booch, and Rumbaugh 1999]. В его ос
нове лежат прецеденты использования, а для документирования применяется но
тация U ML. USDP состоит из пяти основных технологических процедур и четы
рех этапов и является итеративным. На каждом цикле выполняются все четыре
этапа и рассматривается, как далеко удалось продвинуться в технологических
процедурах. Выделяются следующие технологические процедуры и их продукты:
□ требования. Продуктом дайной процедуры является модель прецедентов;
□ анализ. Продукт - аналитическая модель;
□ проектирование. Продуктами являются проектная модель и модель развер
тывания;
□ реализация. Продукт - модель реализации;
□ тестирование. Продуктом служит модель тестирования.
Как и спиральная модель, процесс USDP управляется рисками. Этапы жиз
ненного цикла в USDP таковы:
1. Начало (inception).
2. Исследование (elaboration).
3. Построение (construction).
4. Внедрение (transition).
5.2. Верификация и утверждение проекта

Боэм [Boehm 1981] разделяет верификацию и утверждение проекта. Утверж
дение проекта дает возможность убедиться, что коллектив разработчиков «делает
Тестирование программного обеспечения '^ -Р И И И И 119
правильную систему», то есть систему, удовлетворяющую требованиям пользова
теля. Цель верификации проекта - удостовериться, что коллектив «делает систе
му правильно»: на каждом этапе создается система, удовлетворяющая специфи
кациям, которые были приняты на предыдущем этапе.
В данном разделе будут обсуждаться вопросы контроля качества и анализа
производительности спроектированного ПО. Еще один важный вид деятельнос
ти - тестирование полностью собранной системы на предмет соответствия требо
ваниям. Это делается на этане тестирования системы, о котором мы поговорим
в разделе 5.3.
5.2.1. Контроль качества ПО

Контролем качества ПО называется совокупность мер, призванных гаранти
ровать качество созданного программного продукта. Верификация и утверждение
проекта - важные составные части контроля качества.
Для проверки соответствия системы требованиям пользователя (до начала
разработки) можно использовать временные прототипы. Они позволят проекти
ровщикам «сделать правильную систему», то есть систему, отвечающую потреб
ностям пользователей. Временные прототипы допустимо применять и для созда
ния экспериментальных вариантов проекта.
Большую помощь в верификации и утверждении проекта способны оказать
технические рецензии. При верификации ПО важно убедиться, что проект соот
ветствует спецификации требований. В этом поможет совместное рассмотрение
требований и технические рецензии [Fagan 1976].
5.2.2. Анализ производительности

Для приложений реального времени необходим анализ производительности,
проводимый на этапе проектирования, еще до начала реализации, так как он по
зволяет оценить, будет ли проект отвечать требованиям к производительности.
Если потенциальные проблемы удастся обнаружить на ранних этапах жизненно
го цикла, можно предпринять меры для их преодоления. В главе 17 этой книги
описан подход к анализу производительности проекта систем реального времени
на основе теории планирования в реальном времени.
При других подходах к оценке проекта используется теория массового обслу
живания [Kleinrock 1975; MenascM, Almeida, and Dowdy 1994; Menascfiand Almeida
1998; Menascfi, Gomaa, and Kerschberg 1995; Menasc.ft and Gomaa 1998] и имитаци
онное моделирование [Smith 1990]. Д ля моделирования и анализа параллельных
систем можно использовать сети Петри [Peterson 1981; David 1994; Jensen 1997;
P ettit and Gomaa 1996; Stansifer 1994], для анализа проектов параллельных сис
тем с временными ограничениями применяются сети Петри с конечным време
нем [Coolahan 1983; Elmstrom 1993].
5.3. Тестирование программного обеспечения

В некоторых отношениях тестирование параллельных систем и систем ре
ального времени ничем не отличается от проверки других систем. Различия, как
ШВШШЯкт . : Жизненные циклы и методы разработки ПО
правило, обусловлены тем, что система состоит из нескольких параллельных за
дач, или тем, что она работает с несколькими внешними устройствами. Общим
вопросам тестирования ПО посвящена обширная литература - например, [ Beizer
1990; Myers 1979].
Главная трудность при тестировании параллельной системы связана с тем, что
ее выполнение недетерминированно, то есть реакция системы на входные данные
может непредсказуемо изменяться. Подход к детерминированному тестированию
параллельных систем описан в работе fTai 1991].
Из-за сложности выявления и последующей локализации и устранения оши
бок программные системы обычно тестируют поэтапно. Автономное тестирова
ние и тестирование сопряжений - это подходы на основе принципа прозрачного
ящика, когда необходимо знать внутреннее устройство программы. На этапе ком
плексного тестирования система рассматривается как черный ящик, о котором
известно лишь то, что написано в спецификации требований.
5.3.1. Автономное тестирование

При автономном тестировании проверке подвергаются отдельные компонен
ты, еще не объединенные с другими компонентами [Beizer 1990; Myers 1979]. Для
этой цели применяют критерии тестового покрытия, например критерии покры
тия предложений и покрытия путей. Первый требует, чтобы каждое предложе
ние было реализовано хотя бы один раз; второй - чтобы каждая ветвь программы
была исполнена хотя бы единожды.
Так как при автономном тестировании речь идет о компонентах меньших, чем
одна параллельно выполняемая задача, то далее обсуждать эту тему мы не будем.
5.3.2. Тестирование сопряжений

При тестировании сопряжений предварительно проверенные компоненты объ
единяются во все более сложные комбинации, и эти комбинации исследуются до
тех пор, пока не будет собрана вся система и проанализированы все интерфейсы.
Отличительной особенностью тестирования сопряжений в параллельных
системах является необходимость проверки интерфейсов параллельных задач.
Систематический подход к тестированию сопряжений параллельных задач опи
сан в работе [Gomaa 1986b],
5.3.3. Комплексное тестирование

Комплексное тестирование - это процесс тестирования всего комплекса аппа
ратных и программных средств, который должен доказать, что система отвечает
специфицированным требованиям [IEEE 1990]. Для получения более объектив
ных результатов разумно проводить комплексное тестирование силами независи
мой команды.
Статистическое тестирование использования [Cobb 1990], при котором не
зависимой командой разрабатываются сценарии тестирования черного ящика на
основе ожидаемых способов применения системы, рекомендуется как для тести
рования сопряжений, так и для комплексного тестирования.
Эволюция методов проектирования ПО тш тттт
На этапе комплексного т е с т и р с л е о б х о д и м о проверить следующие ас
пекты поведения системы - параллельной или реального времени [Beizer 1995]:
□ функциональное тестирование. Убедиться, что система выполняет все функ
ции, описанные в спецификации требований;
□ нагрузочное тестирование. Удостовериться, что система способна справ
ляться с большой и переменной нагрузкой, ожидаемой в ходе эксплуатации;
□ тестирование производительности. Доказать, что система отвечает требова
ниям, предъявляемым к времени реакции.
При комплексном тестировании систем реального времени удобно использо
вать имитаторы окружения [Gomaa 1986b], моделирующие поведение внешней
среды. С их помощью ПО можно протестировать в контролируемых и воспроиз
водимых условиях.
5.3.4. Приемо-сдаточные испытания

Приемо-сдаточные испытания обычно проводит организация заказчика или
ее представитель. Как правило, это происходит на площадке заказчика до сдачи
системы в эксплуатацию. Соображения, относящиеся к комплексному тестирова
нию, по большей части применимы и к приемо-сдаточным испытаниям.
5.4. Эволюция методов проектирования ПО

В 60-х годах программы создавались практически без анализа требований
и без проектирования. Часто в качестве инструмента документирования или
проектирования использовались графические нотации, например блок-схемы.
Подпрограммы первоначально создавались только для того, чтобы можно было
вызывать общий блок кода из разных мест программы, но вскоре превратились
в инструмент конструирования модульных систем и были приняты на вооруже
ние как средство управления проектом. Таким образом, появилась возможность
разбить программу на модули и поручить реализацию модуля в виде подпрограм
мы или функции отдельному человеку.
По мере развития структурного программирования (начало 70-х годов) в ос
нову проектирования программ легли идеи разработки сверху вниз и пошагового
уточнения [Dahl 1972; W irth 1974]. При этом ставилась цель выработать система
тический подход к структурированному проектированию. Один из первых мето
дов для такого ПО предложил Дейкстра при работе над операционной системой
Т.Н.Е. [Dijkstra 1968], в которой использовалась иерархическая архитектура. Это
был первый пример методологии проектирования параллельного приложения,
а именно операционной системы.
С середины до конца 70-х годов широко распространились две разные стра
тегии проектирования ПО: проектирование на основе потоков данных и проек
тирование ни основе структурирования данных. Первый подход, который нашел
применение в методике, получившей название S tructured Design (структурное
проектирование) [Yourdon 1979; Page-Jones 1988], стал одним из основных все
сторонне и хорошо документированных методов проектирования. Идея состояла
Жизненные циклы и методы разработки ПО
в том, чтобы достичь лучшего понимания функций системы, проанализировав по
токи циркулирующих в ней данных. Эта методика предложила систематический
способ разработки диаграмм потоков данных и последующего отображения на
структурные схемы. Метод структурного проектирования ввел в оборот критерии
связанности (coupling) и сцепленности (cohesion) для оценки качества проекта.
При таком подходе особое внимание уделялось функциональной декомпозиции
системы на модули и определению их интерфейсов. Первая часть методики струк
турного проектирования, трактующая разработку диаграмм потоков данных, за
тем была усовершенствована и получила дальнейшее развитие, превратившись во
всеобъемлющий метод анализа, названный структурным (Structured Analysis)
[DeMarco 1978; Gane 1979].
Альтернативный подход был основан на структурировании данных. Его идея
заключалась в том, чтобы получить полное представление о структуре проблемы
путем рассмотрения структур соответствующих данных. Поэтому предлагалось
сначала спроектировать структуры данных, а затем уже структуру программы. Два
основных метода, в которых применялась такая стратегия, - это метод структур
ного программирования Джексона [Jackson 1975] и метод Вернье-Орра [Огг 1977].
В области баз данных ключевой стала концепция разделения логической
и физической структуры данных. Предлагались различные подходы к проектиро
ванию логической структуры баз данных, в том числе диаграммы сущность-связь,
придуманные Ченом [Chen 1976].
Большой вклад в проектирование ПО внес Парнас [Parnas 1972], сформули
ровавший идею сокрытия информации. Серьезной проблемой в ранних системах,
даже тех, которые изначально задумывались как модульные, было изобилие гло
бальных данных. Сокрытие информации позволяло значительно уменьшить их
количество, а иногда даже свес ти к нулю.
Существенное продвижение в области проектирования параллельных систем
и систем реального времени пришлось на конец 70-х годов с появлением нотации
M ASCOT [Simpson 1979], а затем и метода проектирования MASCOT [Simpson
1986]. На основе техники анализа потоков данных метод MASCOT формализо
вал способы взаимодействия между задачами, введя два механизма: каналы для
обмена сообщениями и пулы (скрывающие информацию модули, которые инкап
сулировали разделяемые структуры данных). К данным, находящимся в канале
или в пуле, задача могла получить доступ только косвенно, вызвав соответствую
щие процедуры канала или пула. Такие процедуры доступа заодно синхронизиро
вали доступ к данным, обычно с помощью семафоров, так что все проблемы син
хронизации оказывались скрытыми от задачи.
В 80-х годах методы проектирования программ окончательно определились.
Работа Парнаса в Научно-исследовательской лаборатории ВМ Ф, где он занимал
ся использованием концепции сокрытия информации в проектах крупномасштаб
ных программных систем, привела к созданию метода NRL (Naval Research Lab)
сокращения стоимости ПО (Software Cost Reduction M ethod) [Parnas, Clements,
and Weiss 1984]. В результате работ по применению методов структурного анали
за и структурного проектирования к параллельным системам и системам реаль
ного времени появился метод структурного анализа и проектирования систем
Эволюция методов ООА и ООП ; [ | f | Н Н ! 123
реального времени (Real-Time S lm ctm ed Analysis and Design - RTS AD) [Ward
1985; Hatley 1988], а также подход к проектированию систем реального времени
(Design Approach for Real-Time Systems - DARTS) [Gomaa 1984].
В начале 80-х годов возник и еще один метод разработки программ - метод
разработки систем Джексона (Jackson System Development - JSD ) [Jackson 1983].
В методе Джексона проектирование рассматривается как моделирование реаль
ного мира, а моделируемые сущности предметной области представляются в виде
параллельных задач. Метод Джексона одним из первых развивал идею о том, что
проект должен, прежде всего, моделировать реальность, и в этом отношении JSD
оказался предтечей объектно-ориентированных методов анализа. Метод Джексо
на также бросил вызов доминировавшим тогда представлениям о проектирова
нии сверху вниз, предлагая подход изнутри наружу, основанный на анализе по
ведения системы. Он стал предшественником моделирования взаимодействия
объектов - важной составной части современных методик объектно-ориентиро
ванной разработки.
5.5. Эволюция методов

объектно-ориентированного анализа
и проектирования
В середине 80-х годов успехи объектно-ориентированного программирова
ния привели к появлению нескольких объектно-ориентированных методов про
ектирования, в том числе Буча [Booch 1986, 1991], Вирфс-Брока [Wirfs-Brock,
Wilkenson, and W iener 1990], Рамбо [Rumbaugh et al. 1991], Ш лаера-М еллора
[Shlaer and Mellor 1988, 1992] и Коада-Йордана [Coad and Yourdon 1991, 1992].
Акцент в них ставился на моделировании предметной области, сокрытии инфор
мации и наследовании.
Парнас выдвинул идею сокрытия информации как средство проектирования
более замкнутых модулей, которые молено изменять, не затрагивая или почти не
затрагивая другие модули. Буч предложил ввести в проектирование объектно-
ориентированные концепции [Booch 1986], сначала сформулировав метод объект
ного проектирования систем на базе языка Ada (включавший сокрытие информа
ции), а затем обобщив его до метода объектно-ориентированного проектирования
с применением сокрытия информации, классов и наследования [Booch 1991,1994].
Шлаер и Меллор [Shlaer and Mellor 1988], Коад и другие внедрили объектно-ори
ентированные концепции в анализ. Как известно, объектно-ориентированный
подход обеспечивает более плавный переход от анализа к проектированию, неже
ли функциональный.
Методы объектно-ориентированного анализа применяют объектно-ориентиро
ванные концепции на этане анализа, который является частью жизненного цикла
разработки ПО. Акцент ставится на выявлении объектов реального мира в пред
метной области и отображении их на объекты программы. Исторически первой по
пыткой моделирования объектов был метод статического моделирования, который
уходил корнями в моделирование информации и, в частности, в моделирование
I
Жизненные циклы и методы разработки ПО
сущностей и связей (E-R-модели) [Chen 1976J и более ебщес се м атл leiKtt. мо
делирование данных [Peckham 1988], применявшееся при проектировании логи
ческой структуры баз данных. Сущности в E-R-моделях - это информационно
насыщенные объекты предметной области. Сами сущности, их атрибуты и свя
зи между ними определяются и изображаются с помощью E-R-диаграмм, кото
рые относятся исключительно к моделированию данных. На этапе проектиро
вания E-R -модель отображается на базу данных, обычно реляционную. При
объектно-ориентированном анализе идентифицируются объекты в предметной об
ласти, которые затем моделируются как классы программы; одновременно опре
деляются атрибуты каждого класса и связи между классами [Booch 1994; Coad 1991;
Rumbaugh et al. 1991; Shlaer and Mellor 1988j.
Основное различие между классами в статических объектно-ориентирован
ных моделях и типами сущностей в E-R-моделях состоит в том, что у классов есть
операции, а у типов сущностей их пет. Кроме того, при информационном модели
ровании рассматриваются только устойчивые сущности, подлежащие сохранению
в базе данных, тогда как в статических объектно-ориентированных моделях нахо
дят отражение и другие классы из предметной области [Booch 1,994]. Использу
ются и такие развитые концепции информационного моделирования, как агреги
рование и обобщ ение/специализация. Наиболее популярной для статических
объектно-ориентированных моделей до появления UML была нотация ОМТ
(Object Modeling Technique) [Rumbaugh et al. 1991].
Статическое объектное моделирование называют также моделированием клас
сов и моделированием объектов, поскольку его составной частью служит выявле-
кис классов, которым принадлежат объекты, и изображение этих классов и отно
шений между ними на диаграммах классов. Термин моделирование предметной
области (domain modeling) тоже относится к статическому моделированию [Shlaer
and Mellor 1992; Rosenberg and Scott 1999].
В ранних методах объектно-ориентирован! юга анализа и проектирования ос
новное внимание уделялось структурным аспектам разработки ПО, для чего при
менялись сокрытие информации и наследование; динамическими же аспектами
пренебрегали. Главным вкладом методики Object Modeling Technique стала убе
дительная демонстрация того, что моделирование динамики не менее важно. По
мимо введения нотации статического моделирования для диаграмм объектов
в ОМ Т было показано, как можно моделировать динамические аспекты с помо
щью диаграмм состояний, на которых отражается зависящее от состояния пове
дение активных объектов, и диаграмм последовательности, иллюстрирующих
порядок взаимодействия объектов. В работе [Rumbaugh et al. 1991] для модели
рования активных объектов использовались иерархические диаграммы состоя
ний, предложенные Харелом [Harel 1988, 1998]. В книге [Shlaer and Mellor 1992]
диаграммы перехода состояний также служили для моделирования активных
объектов. Буч первым применил диаграммы объектов для показа кооперации
между объектами на уровне экземпляров [Booch 1991], а позднее стал присваи
вать взаимодействиям порядковые номера, чтобы яснее представить общую схему.
Обзор современных методов проектирования |'Ц В И И 1 125
Джекобсон [Jacobson 1992] ввел в рассмотрение....,„г .щию прецедентов (use
case) для моделирования функциональных требований к системе. Он же начал
использовать диаграммы последовательности для описания порядка взаимодей
ствий между объектами, участвующими в прецеденте. Концепция прецедентов
лежала в основе всех этапов жизненного цикла объектно-ориентированных про
грамм по Джекобсону. Эта концепция, которую можно в равной мере применять
как к объектно-ориентированным, так и к иным системам, оказала огромное вли
яние на современные методы разработки объектно-ориентированного ПО.
Еще до появления UML предпринимались попытки унифицировать различ
ные объектно-ориентированные методы и нотации, например в системе Fusion
[Coleman et al. 1993] и в работе [Texel and Williams 1997]. Нотация унифициро
ванного языка моделирования была создана Бучем, Джекобсоном и Рамбо с це
лью объединения нотаций для моделирования прецедентов, статического и ди
намического моделирования (с помощью моделей состояния и взаимодействия
объектов). Свои идеи по развитию UML предлагали и другие методологи. Инте
ресное обсуждение истории развития UML и вероятных путей его дальнейшей
эволюции можно найти в книгах [Cobryn 1999; Selic 1999].
5.6. Обзор современных методов проектирования

параллельных систем и систем реального времени
Метод CODARTS (Concurrent Design Approach for Real-Time Systems) [Gomaa
1993] объединил достоинства ранних методик проектирования параллельных сис
тем, проектирования систем реального времени и объектно-ориентированного
проектирования. Это и метод NRL (Naval Research Laboratory Software Cost
Reduction M ethod) Парнаса [Parnas, Clements, and Weiss 1984], и ранний метод
объектно-ориентированного проектирования Буча [Booch 1991], и метод Джек
сона [jacson 1983], и метод DARTS (Design Approach for Real-Time Systems)
[Gomaa 1984, 1986b]. Основное внимание здесь уделялось структурированию мо
дулей на основе сокрытия информации и структурированию задач.
В методе CODARTS вопросы параллельности и синхронизации рассматрива
ются в ходе проектирования задач, а вопросы сокрытия информации - в ходе про
ектирования модулей. Таким образом, задачи считаются активными объектами,
а скрывающие информацию модули - пассивными. Система реального времени
изучается с точки зрения ее статических и динамических характеристик. Дина
мические аспекты представлены параллельными задачами, которые выделяются
посредством критериев структурирования задач. Статические аспекты переданы
скрывающими информацию модулями, которые вычленяются с помощью крите
риев структурирования модулей. Предлагаются также приемы объединения
взглядов на систему с позиции задач и модулей.
Octopus [Awad, Kuusela, and Ziegler 1996] - это метод проектирования систем
реального времени, основанный на использовании прецедентов, статического
моделирования, взаимодействий объектов и диаграмм состояний. Объединив
126 МШ*ь Жизненные циклы и методы разработки ПО
концепции прецедентов Джекобсона со статическим моделированием Рамбо
и диаграммами состояний, метод Octopus предвосхитил слияние нотаций, кото
рое привело к появлению UML. В применении к проектированию систем реаль
ного времени Octopus делал акцент на интерфейсе с внешними устройствами и на
структурировании параллельных задач.
ROOM [Selic, Gullekson, and Ward 1994] - это метод проектирования систем
реального времени, тесно связанный с инструментальным CASE-средством
ObjecTime. В основу ROOM положены актеры, представляющие собой активные
объекты, которые моделируются с помощью варианта диаграмм состояний,
известных под названием ROOM charts. Диаграмма ROOM chart описывает состо
яния актера, сигналы, но которым осуществляется переход в новое состояние,
и действия, выполняемые при переходе. Актеры связаны между собой портами.
С помощью особого протокола специфицируются зависящие от направления сооб
щения, которыми обмениваются актеры. Если модель ROOM описана достаточно
детально, то ее можно выполнить. Таким образом, модель ROOM допустимо рас
сматривать как ранний прототип системы.
Бур [Buhr 1996] ввел интересную концепцию карты прецедентов для дина
мического моделирования больших систем. С помощью такой карты описывают
ся взаимодействия между объектами (или агрегированными объектами - подсис
темами), но на более высоком уровне, чем позволяют диаграммы кооперации.
Изучая создание систем реального времени с помощью UML, Дуглас [Doug
lass 1999b, 1999а] предложил детальный анализ способов использования и М Е для
решения этой задачи. В первой книге говорится о применении нотации UME
к разработке систем реального времени. Вторая книга представляет собой подроб
ный справочник, освещающий широкий спектр вопросов проектирования систем
реального времени, в том числе: системы с повышенными требованиями к безо
пасности, взаимодействие с операционными системами реального времени, пла
нирование в реальном времени, паттерны поведения, каркасы для систем реаль
ного времени, отладка и тестирование.
5.7. Резюме
В этой главе рассматривалась проблема разработки ПО с точки зрения жиз
ненных циклов. Мы вкратце описали и сравнили различные модели жизненных
циклов ПО, в частности спиральную модель и унифицированный процесс разра
ботки ПО. Рассказывалось о роли верификации, утверждения и тестирования
ПО. Затем были проанализированы основные этапы развития методов проекти
рования ПО, методов объектно-ориентированного анализа и проектирования
и методов проектирования систем реального времени. В главе 6 речь пойдет
о жизненном цикле объектно-ориентированного ПО для метода COMET.
I
ВВЯЩашв COMET - метод

архитектурного
проектирования
и моделирования
параллельных
объектов
с применением UML
Г я а в а 12 .
Введение в метод COMET Проектирование
архитектуры системы
.лава 7 .
М оделирование Г я т т т КЗ»
прецедентов Проектирование архитектуры
распределенных приложений
Г л а в а 8»
Статическое моделирование Г яа ва 14-
Разбиение на задачи
Гят
Разбиение на классы Глава 15.
и объекты Проектирование классов
Wmmtm. 1*Й, Глава 16.

Конечные автоматы Детальное
и диаграммы состояний проектирование ПО
Глава 11. Г л а в а 17»
Динамическое Анализ производительности
моделирование проекта параллельной
системы реального времени
^ -лЬШ si г и и и»ъУ-',<! ' ' |v' |Г
COM ET - это метод проектирования параллельных приложений, в том числе рас
пределенных и реального времени. В данной главе метод C O M ET рассматрива
ется с точки зрения жизненного цикла разработки ПО. Процесс разработки
в COM ET - объектно-ориентированный процесс, совместимый с унифицирован
ным процессом разработки ПО (U S D P ) [Jacobson, Booch, and Rumbaugh 1999]
и со спиральной моделью [Boehm 1988|. Ниже описывается объектно-ориентиро
ванный жизненный цикл ПО в COM ET и использование этого метода совместно
с унифицированным процессом разработки ПО и со спиральной моделью, расска
зывается о основных видах деятельности в методе COM ET и о его применении.
6.1. Жизненный цикл разработки

объектно-ориентированного ПО в методе COMET
Модель жизненного цикла в COM ET - это итеративный процесс разработки
на основе концепции прецедентов. Каждый прецедент описывает последователь
ность взаимодействий между несколькими актерами.
Прецедент можно анализировать на нескольких уровнях детализации. В мо
дели требований задаются функциональные требования к системе в терминах ак
теров и прецедентов. В аналитической модели прецедент уточняется с помощью
характеристик участвующих объектов и взаимодействий между ними. В проект
ной модели создается архитектура системы, здесь рассматриваются вопросы рас
пределенности, параллелизма и сокрытия информации. Полный жизненный цикл
разработки объектно-ориентированного ПО на основе метода COM ET представ
лен на рис. 6 .1 и подробно описан ниже.
6.1.1. Моделирование требований

На этане моделирования требований разрабатывается модель, в которой опре
деляются функциональные требования к системе в терминах актеров и прецеден
тов. Формулируется словесное описание каждого прецедента - для этого необхо
димо активное участие пользователей. Если требования не вполне понятны, то
можно создать временный прототип (см. главу 5).
6.1.2. Аналитическое моделирование

На этапе аналитического моделирования строятся статическая и динамичес
кая модели системы. Статическая модель задает структурные отношения между
Цикл разработки ПО в методе COMET ш Н И М Ш Ш
Пользователь
Ассоциации между этапами жизненного цикла в COMET

(этапы изображены в виде классов в модели жизненного цикла ПО в COMET)
1 Предоставляет исходные данные 9 Предоставляет оттестированное расширение ПО
2 Продогл авляо'! модель требований 10 Предоставляет исходные данные для следующ его шага
3 Предоставляет модель требований 11 Предоставляет исходные данные для следующ его шага
4 Предоставляет замечания пользователя 12 Предоставляет исходные данные для следующ его шага
5 Предоставляет аналитическую модель 13 Предоставляет исходные данные для следующ его шага
6 Предоставляв г проектную модель 14 Предоставляет работающую систему
7 Предост авляет очередное расширение ПО 15 Предоставляет работающую систему
S Предоставляет оттестированное расширение ПО
Рис. 6.1. Модель жизненного цикла

разработки объектно-ориентированного ПО в методе COMET
классами предметной области. Классы и отношения между ними изображаются

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

На этапе проектного моделирования разрабатывается программная архитекту
ра системы, при этом аналитическая модель отображается на эксплуатационную
среду. Аналитическая модель, в которой наиболее важной являлась предметная
130 Щ Щ Щ Вредение в метод COMET
область, переносится на проектную модель, где главной становится область реше

ния. Для декомпозиции системы применяются критерии разбиения па подсисте
мы, последние рассматриваются как агрегированные или составные объекты.
Особое внимание уделяется проектированию распределенных подсистем в виде
конфигурируемых компонентов, которые взаимодействуют путем обмена сообще
ниями. Затем проектируется каждая подсистема. Для последовательных систем
акцент делается на объектно-ориентированных концепциях сокрытия информа
ции, классов и наследования. При проектировании параллельных систем - ре
ального времени, клиент-серверных и распределенных - помимо объектно-ори
ентированных концепций необходимо принять во внимание также концепции
параллелизма.
6.1.4. Инкрементное конструирование ПО

После завершения этапа проектирования архитектуры наступает черед ин
крементного конструирования 110. При этом определяется, какое подмножество
системы будет реализовано на каждом шаге. Подмножество выбирается с учетом
того, какие прецеденты и участвующие в них объекты следует добавить. Инкре
ментное конструирование включает детальное проектирование, кодирование и ав
тономное тестирование классов, вошедших в отобранное подмножество. Такой
поэтапный подход позволяет постепенно создавать и объединять фрагменты сис
темы, пока она не будет собрана целиком.
6.1.5. Инкрементная интеграция ПО

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

На этапе комплексного тестирования производится функциональное тестиро
вание системы в целом, то есть проверка на соответствие функциональным требо
ваниям. Здесь система рассматривается как черный ящик и создается комплект
тестов для каждого прецедента ее использования в таком качестве. Любое расши
рение системы, передаваемое заказчику, должно пройти этап комплексного тести
рования.
Сравнение C uM tT с другими процессами 131
6,2. Сравнение жизненного цикла COMET

с другими процессами разработки ПО
В этом разделе мы сравним жизненный цикл COM ET с унифицированным
процессом разработки ПО (U S D P ) и со спиральной моделью. Метод COM ET
можно сочетать и с тем, и с другим.
6.2.1. Сравнение жизненного цикла COMET с USDP

В описании USDP (Unified Software Development Process - унифицирован
ный процесс разработки 110), данном в работе [Jacobson, Booch, and Rumbaugh
1999J и кратко представленном в главе 5, акцент делается на процессе и в мень
шей степени на методе. USDP достаточно подробно трактует аспекты жизненного
цикла и едва касается используемого метода. Метод COM ET совместим с USDP.
Технологические процессы в USDP - это требования, анализ, проектирование,
реализация и тестирование.
Каждый этап жизненного цикла COM ET соответствует одному из технологи
ческих процессов USDP. Первые три этапа даже называются одинаково, что не
удивительно, так как на устройство жизненного цикла в COM ET сильное влияние
оказала ранняя работа Джекобсона [Jacobson 1992J. Инкрементное конструирова
ние ПО в COM ET соответствует процессу реализации в USDP, этапы инкремент
ной интеграции и комплексного тестирования - процессу тестирования. В COMET
эти виды деятельности разделены, поскольку тестирование сопряжений считает
ся обязанностью группы разработчиков, а комплексное тестирование выполняет
ся силами отдельной группы тестировщиков.
6.2.2. Сравнение жизненного цикла COMET

со спиральной моделью
Метод C O M ET можно использовать и в сочетании со спиральной моделью
| Boehm 1988]. При планировании очередного цикла в спиральной модели руко
водитель проекта, решает, что в третьем квадранте (создание продукта) должна
быть проведена, определенная техническая работа, например моделирование тре
бований, аналитическое или проектное моделирование. На стадии анализа рис
ков, выполняемой во втором квадранте, или на стадии планирования цикла, осу
ществляемой в четвертом квадранте, определяется, сколько итераций требуется
для каждого вида такой работы.
6.3. Модель требований,

аналитическая и проектная модели
Нотация UML поддерживает концепции требований, анализа и проектирования.
Метод COMET, являющийся предметом данной книги, разграничивает деятельнос
ти, связанные с формулированием требований, анализом и проектированием.
132 Введение в метод COMET
На этапе моделирования требований должны быть определ ч i 1 ункцио-
нальные требования к системе. Разделение между анализом и проектированием
в COM ET осуществляется так: анализ ~ это декомпозиция проблемы, то есть раз
биение ее на более простые для понимания фрагменты; проектирование - это син
тез, или композиция (сборка), решения. Подробнее данные виды деятельности
описаны в последующих разделах.
6.3.1. Виды деятельности при моделировании требований

В модели требований система рассматривается как черный ящик. Разрабаты
вается модель прецедентов:
□ моделирование прецедентов. Определение актеров и прецедентов использо
вания черного ящика. Функциональные требования к системе указываются
в терминах прецедентов и актеров. Описания прецедентов дают картину по
ведения, характеристика отношений между ними - представление о струк
туре. Моделирование прецедентов рассматривается в главе 7.
6.3.2. Виды деятельности при аналитическом моделировании

В аналитической модели акцент ставится на понимании проблемы, то есть на
идентификации объектов предметной области и передаваемой между ними ин
формации. Вопросы о том, является объект активным или пассивным, сообще
ние - синхронным или асинхронным и какая операция вызывается объектом при
получении сообщения, откладываются до этапа проектирования.
На этапе аналитического моделирования рассматривается предметная область.
Основные виды деятельности здесь таковы:
□ статическое моделирование (см. главу 8 ). Построение статической модели
предметной области. Это структурное представление информационных ас
пектов системы. Задаются классы, их атрибуты и отношения между ними.
Операции классов будут указаны позже, в проектной модели. Для информа
ционно насыщенных систем такое представление играет важнейшую роль.
Основное внимание уделяется информационному моделированию классов
реального мира, встречающихся в предметной области;
□ разбиение иа объекты (см. главу 6 ). Определение объектов, участвующих
в каждом прецеденте. При выявлении объектов используются критерии раз
биения иа объекты. Объекты могут быть сущностными, интерфейсными,
управляющими и связанными с прикладной логикой. Динамические отно
шения между выявленными объектами изображаются в виде динамической
модели;
□ моделирование состояний. С помощью иерархических диаграмм состояний
задаются аспекты системы, зависящие от состояния. Каждый зависящий от
состояния объект описывается своей диаграммой. Конечные автоматы,
изображаемые на диаграммах состояний, рассматриваются в главе 1 0 ;
Модели COMET мшштт 133
□ динамическое моделирование. Выявленные ранее прецеденты уточняются
с целью показать взаимодействие между участвующими в них объектами.
Д ля этого применяются диаграммы кооперации или последовательности.
В главе 11 рассматривается, в числе прочего, подход к анализу динамики
системы, помогающий определить, как объекты взаимодействуют в каждом
прецеденте. В случае, когда имеется зависимость от состояния, необходи
мо явно промоделировать управляющие объекты, зависящие от состояния,
и диаграммы их состояний.
6.3.3. Виды деятельности при проектном моделировании

На этапе проектного моделирования рассматривается область решения. Зада
ча состоит в отображении аналитической модели на проектную. Для параллель
ных приложений, в том числе распределенных и реального времени, выполняют
ся следующие виды деятельности:
□ консолидация модели кооперации объектов. Разработка консолидированных
диаграмм кооперации (см. главу 1 2 );
□ принятие решения о структуре подсистем и интерфейсов между ними. Со
здание общей архитектуры программы. Разделение приложения на подсис
темы (см. главу 1 2 );
□ разбиение распределенного приложения на распределенные подсистемы, про
ектируемые как конфигурируемые компоненты. Проектирование архитек
туры распределенной программы для распределенного приложения, при
помощи разделения системы на распределенные подсистемы и указания
интерфейсов передачи сообщений между ними (см. главу 13);
□ определение характеристик объектов, в частности пассивности и активнос
ти. Разделение каждой подсистемы на параллельные задачи (активные объек
ты) с помощью критериев разбиения на задачи. Указание интерфейсов каж
дой задачи (см. главу 14);
□ уточнение характеристик сообщений: какие из них являются синхронными
(с ответом или без ответа), а какие - асинхронными (см. главу 14);
□ принятие решения об интерфейсах классов. Проектирование классов, скры
вающих информацию (пассивных классов), для каждой подсистемы. Зада
ние операций каждого класса и параметров каждой операции (см. главу 15);
□ разработка деталыюго проекта программы с учетом вопросов синхрониза
ции задач и обмена информацией между ними, а также внутренней струк
туры параллельных задач (см. главу 16).
Среди прочего, в методе COMET большое внимание уделяется критериям де
композиции на различных стадиях процессов анализа и проектирования. Критерии
разбиения на объекты служат для выявления объектов в системе; критерии разбие
ния на подсистемы - для определения подсистем, а критерии выделения параллель
ных задач помогают найти задачи (активные объекты) в системе. Чтобы яснее по
казать применение критериев декомпозиции, используются стереотипы UML.
134 Ш Ш т . i Введение в метод COMET
6.4. Основы COMET

Следуя практике, введенной Розенбергом [Rosenberg 1999], который описал
свой подход «в двух словах», мы приведем в этом разделе столь же беглый обзор
метода COMET: все шаги, а также результаты завершения каждого этапа, включа
ющие различные модели в нотации UML (см. главу 2) вместе с дополнительной
документацией, которая описывается ниже.
6.4.1. Разработка модели требований

На этапе моделирования требований выполняются следующие шаги:
1. Разработка модели прецедентов, в том числе:
1.1. Создание диаграмм прецедентов, на которых изображаются актеры
и прецеденты. Прецеденты могут объединяться в группы для представ
ления крупных функциональных образований.
1.2. Документирование каждого прецедента в словесной форме.
6.4.2. Разработка аналитической модели

На этапе аналитического моделирования проводятся следующие шаги:
2. Разработка аналитической модели, в том числе:
2.1. Создание статической модели предметной области (реального мира).
Анализ статического взгляда на систему в терминах классов, их атрибу
тов и отношений между ними. Этот шаг включает следующие этапы:
2.1.1. Проектирование статической модели предметной области с помо
щью диаграмм классов, па которых отражены отношения между
классами, встречающимися в предметной области.
2.1.2. Уточнение модели контекста системы с помощью диаграмм классов,
на которых отражены интерфейсы между системой и внешними
классами. Эта модель выводится из вышеупомянутой статической
модели предметной области (шаг 2.1.1). Данный этап необходим
для систем, управляющих разнообразными внешними устройства
ми ввода/вывода, к примеру датчиками и приводами, а также внеш
ними системами.
2.1.3. Разработка статической модели сущностных классов предметной
области, в которой отражены отношения между информационно на
сыщенными классами, то есть такими, которые предназначены глав
ным образом для хранения данных. Такой шаг требуется для сис
тем, включающих много сущностных классов.
2.1.4. Определение словаря классов, в котором представлены атрибуты
всех классов.
2.2. Разбиение системы на классы и объекты. Применение критериев раз
биения на объекты для выявления классов и объектов в системе. Опре
деление высокоуровневых подсистем, например вида клиент-сервер.
Основы COMET !; ш т ш т ш т
Добавление этих классов в словарь. Данный шаг можно также выпол
нять итеративно в составе шага 2.3.1.
2.3. Создание динамической модели. Д ля каждого прецедента выполняют
ся следующие шаги:
2.3.1. Определение участвующих в прецеденте объектов.
2.3.2. Разработка диаграммы взаимодействия объектов (кооперации или
последовательности), на которой представлен порядок взаимодей
ствий между объектами-участниками прецедента. Анализ последо
вательности взаимодействий между объектами. Рассмотрение ин
формации, которой обмениваются объекты.
2.3.3. Определение диаграммы состояний для каждого зависящего от со
стояния объекта, участвующего в зависящей от состояния коопера
ции. События и действия, показанные на диаграмме состояний,
должны согласовываться с входными и выходными сообщениями
объекта, исполняющего эту диаграмму.
2.3.4. Описание последовательностей сообщений для каждой диаграммы
взаимодействий, в котором документируется порядок этих взаимо
действий.
6.4.3. Разработка проектной модели

На этапе проектного моделирования выполняются следующие шаги:
3. Разработка аналитической модели, в том числе:
3.1. Синтез артефактов аналитической модели для получения предвари
тельной архитектуры программы. На этом этапе осуществляется пере
ход от анализа к проектированию, он соответствует шагу анализа надеж
ности в терминологии работы [Rosenberg 1999]. Если на стадии синтеза
обнаруживаются ошибки, то происходит возврат к этапу аналитическо
го моделирования. Синтез включает:
3.1.1. Синтез диаграмм состояний. Из основанных на прецедентах частич
ных диаграмм состояний каждого зависящего от состояния объекта
получается общая диаграмма состояний данного объекта. Это не
обходимо сделать для каждого зависящего от состояния объекта,
участвующего более чем в одном прецеденте. Описанный шаг мож
но также выполнить на завершающей стадии шага 2.3.3.
3.1.2. Синтез модели кооперации. Консолидация всех диаграмм коопера
ции в единую модель кооперации для системы в целом. Д ля боль
ших систем необходимо разработать модель кооперации подсистем.
Может потребоваться возврат на этот шаг с шага 3.2.
3.1.3. Синтез статической модели. Определение классов и отношений
между ними. Такая уточненная статическая модель является про
дуктом переработки статической модели предметной области, а ес
ли последняя слишком концептуальна, то синтез производится на
т т т 1 Введение в метод COMET
основе консолидированной модели кооперации. Возможно и соче
тание обоих подходов.
3.2. Проектирование общей архитектуры системы. Разбиение приложения на
подсистемы. Указание интерфейсов подсистем. Для выделения подсис
тем применяются критерии разбиения на i юдсистемы. Разработка для
каждой подсистемы диаграмм кооперации, а также высокоуровневой
диаграммы кооперации для системы в целом.
3.3. Проектирование архитектуры программы, основанной на распределен
ных компонентах. Для распределенных приложений разбиение на рас
пределенные подсистемы происходит на основе критериев распределен
ности. Требуется также определить интерфейс между компонентами
системы на основе обмена сообщениями. Такой шаг необходим только
при проектировании распределенных приложений.
3.4. Проектирование архитектуры параллельных задач для каждой подсис
темы. Этот шаг включает:
3.4.1. Разбиение подсистемы на параллельные задачи путем применения
соответствующих критериев декомпозиции.
3.4.2. Определение задач и их интерфейсов.
3.4.3. Разработка для каждой подсистемы диаграмм параллельных коопе
раций, на которых изображаются задачи и их интерфейсы.
3.4.4. Документирование проекта каждой задачи в виде спецификации по
ведения задачи.
•3.5. Анализ производительности проекта. Применение метода планирова
ния в реальном времени для определения того, отвечает ли проект тре
бованиям, предъявляемым к производительности. При необходимости
можно несколько раз повторить шаги 3.3 и 3.4. Подобный шаг- нужен
только при проектировании приложений реального времени.
3.6. Проектирование классов в каждой подсистеме. Разработка интерфей
сов классов, в том числе и всех их операций, а также иерархий насле
дования. Для приложений, нуждающихся в базе данных, необходимо
создать структуру базы данных и классы-обертки (эти вопросы затра
гиваются в настоящей книге очень кратко). Д ля каждого класса требу
ется спецификация интерфейса.
3.7. Разработка детального проекта каждой подсистемы, в том числе:
3.7.1. Создание внутренней структуры составных задач, которые содержат
вложенные пассивные объекты.
3.7.2. Уточнение деталей механизмов синхронизации для объектов, к ко
торым возможен доступ со стороны нескольких задач.
3.7.3. Выделение классов-разъемов, инкапсулирующих детали межзадач
ной коммуникации.
3.7.4. Выявление и документирование внутренней для каждой задачи ло
гики возникновения и обработки событий.
137
3.8. Более детальный анализ производительности каждой подсистемы при
ложения реального времени. Если необходимо, МОЖНО повторить шаги
3.4-3.7. Этот шаг нужен только при проектировании приложений ре
ального времени.
6.5. Резюме
В данной главе был онисан применяемый в методе COM ET жизненный цикл
объектно-ориентированной разработки параллельных приложений, в частности
распределенных и реального времени. Сравнивался жизненный цикл COM ET
с унифицированным процессом разработки ПО и со спиральной моделью, расска
зывалось о способах использования COM ET в сочетании с этими методиками,
а также об основных видах деятельности, выполняемых в методе COMET, и ша
гах его применения.
ирещ '«&е>-№^4
Функциональные требования к системе (или, как их еще называют, внешние тре
бования) определяют, что система должна делать для пользователя. При указа
нии внешних требований систему следует рассматривать как черный ящик, то есть
принимать во внимание лишь ее внешние характеристики.
В этой главе описывается подход к заданию функциональных требований
с помощью прецедентов, объясняются понятия актера и прецедента. Здесь также
будут рассмотрены отношения между прецедентами, в частности отношения рас
ширяет (extend) и включает (include). Приводится несколько примеров.
7.1. Прецеденты
При использовании подхода на основе прецедентов функциональные требо
вания задаются в терминах актеров (actor), в роли которых выступают пользова
тели системы, и прецедентов (use case). Актер участвует в прецеденте. Прецедент
устанавливает последовательность взаимодействий между одним или нескольки
ми актерами и системой. На этапе определения требований модель прецедентов
описывает систему как черный ящик, а взаимодействие между актерами и систе
мой, то есть действия пользователя и реакция на них системы, указываются в сло
весной форме. Прецеденты в данной модели выражают внешние требования
к системе. Каждый прецедент описывает поведение некоторой части системы,
не раскрывая ее внутренней структуры. На следующем этапе аналитического мо
делирования определяются объекты, участвующие в каждом прецеденте.
Рассмотрим простой пример из области банковского дела - банкомат, позво
ляющий клиентам снимать наличные деньги со своего счета. Имеется один актер -
Клиент Банкомата, и один прецедент - Снять Деньги (рис. 7.1). Прецедент
Снять Деньги описывает последовательность взаимодействий между клиентом
и системой, начиная с момента, когда клиент вставляет карточку в банкомат, и за
канчивая выдачей наличных.
Р и с . 7 .1 . Пример актера и прецедента

Актеры . 4
7,2. Актеры
Актер представляет одного или нескольких внешних пользователей, взаимо
действующих с системой [Rumbaugh, Booch, and Jacobson 1999]. В модели преце
дентов актеры - это единственные внешние сущности, взаимодействующие с сис
темой.
Есть несколько способов моделирования актеров [Fowler and Scott 1999]. Час
то в роли актера выступает человек. Во многих информационных системах нет
никаких других актеров, кроме людей. Но актером бывает и внешняя система.
В приложениях реального времени и в распределенных приложениях актером мо
жет стать внешнее устройство ввода/вывода или таймер. Такие актеры чаще всего
встречаются во встраиваемых системах реального времени, где система взаимо
действует с внешней средой посредством датчиков и приводов.
Главный актер (primary actor) инициирует прецедент, то есть некоторые дей
ствия в системе. Другие актеры, называемые второстепенными (secondary actors),
также могут участвовать в прецеденте, получая результаты и генерируя исходные
данные. По меньшей мере один актер (обычно главный) должен иметь какой-то
результат от прецедента. Однако в системах реального времени, когда в роли глав
ного актера выступает внешнее устройство ввода/вывода или таймер, бенефици
арием становится второстепенный актер-человек, получающий от системы ту или
иную информацию.
Актер-человек использует для взаимодействия с системой различные внеш
ние устройства ввода/вывода: стандартные (клавиатуру, дисплей или мышь) либо
нестандартные (скажем, различные датчики). В любом случае актером является
человек, а не эти устройства.
Рассмотрим несколько примеров актеров-людей. В банковской системе акте
ром является, например, кассир, который взаимодействует с системой посред
ством стандартной клавиатуры, дисплея и мыши. Другой пример актера - клиент,
общающийся с системой через банкомат. В этом случае клиент применяет для
взаимодействия, помимо клавиатуры и дисплея, и другие устройства ввода/вы
вода: устройство считывания карточки, устройство выдачи наличных, устройство
для печати чеков.
Иногда, впрочем, в роли актера выступает устройство. Так бывает, когда люди
в прецеденте не участвуют, что типично для приложений реального времени. Обыч
но такой актер взаимодействует с системой посредством датчика. Примером мо
жет служить Датчик Прибытия в системе управления лифтами (рис. 7.2). Этот
датчик показывает, что лифт приближается к этажу, на котором следует оста
новиться. Тем самым он инициирует прецедент Остановка Лифта на Этаже.
Другим актером в системе управления лифтами является пассажир, который об
щается с системой с помощью кнопок выбора этажа и управления лифтом. Дей
ствия этою актера фиксируют датчики кнопок.
Актером может быть также таймер, который периодически посылает события
системе. Когда система должна выводить некую информацию на регулярной ос
нове, возникает нужда в регулярных прецедентах. Особенно важно это в системах
ШШШЖЫ; Моделирование прецедентов
Рис. 7.2. Пример устройства ввода в качестве актера
реального времени, но часто оказывается полезным и в информационных систе

мах. Некоторые методологи относят таймеры к внутренним элементам системы,
но при проектировании приложения реального времени удобно рассматривать их
как логически внешние по отношению к системе, считая главными актерами, ини
циирующими действия. Например, в системе круиз-контроля таймер иницииру
ет несколько разных прецедентов. Так, в примере на рис. 7.3 актер Таймер задает
прецедент Вычислить Скорость Движения, в котором периодически рассчиты
вается средняя скорость, а полученное значение отображается на дисплее Води
теля. В этом случае таймер - главный актер, а водитель - второстепенный.
Актером может быть также внешняя система, которая либо инициирует пре
цедент (в качестве главного актера), либо участвует в нем (в качестве второсте
пенного). Пример такого рода - Заводской Робот в системе автоматизации про
изводства. Он начинает прецедент Поднять Тревогу и Известить, показанный
на рис. 7.4. Робот генерирует сигнал тревоги, который посылается операторам,
уполномоченным реагировать на этот сигнал. В данном случае Заводской Ро
бот является главным актером, инициирующим прецедент, а Дежурный Опера
тор - второстепенным, принимающим сигналы тревоги.
/ ^ П о д н я т ь Тревогу~'"'ч\и_
Л и Известить Операторау
Заводской Робот Дежурный Оператор

(внешняя система - (второстепенный акгер)
главный актер)
Рис. 7.4. Пример внешней системы в роли актера

Выявление прецедентов I''11ЯМ 1Н 11 141
7.3. Актеры, роли и пользователи

Актер - это роль в предметной области, которую обычно играет пользователь.
Пользователь - это конкретная личность, тогда как актер - роль, которую играют
все пользователи данного типа. Например, в системе автоматизации производства
есть три актера-человека: Дежурный Оператор, Инженер-Технолог и Началь
ник Производства. Если один и тот же человек в состоянии играть несколько
независимых ролей, то в каждой роли он представляется отдельным актером. Н а
пример, в разные моменты времени некто способен выступать в роли Начальни
ка Производства или Дежурного Оператора, и для моделирования такой си
туации нужны два актера.
Возможно также, что в одной и той же роли выступают несколько пользовате
лей. К примеру, на заводе может быть несколько операторов. Тогда актер модели
рует тип пользователя, а конкретные пользователи являются экземплярами этого
актера.
7.4. Выявление прецедентов

Прецедент начинается с некоторого действия актера и представляет собой за
вершенную последовательность событий, начатую этим действием и описываю
щую один из вариантов взаимодействия актера с системой. Простой прецедент
может состоять из единственного взаимодействия, а более сложные содержат не
сколько взаимодействий. Допустимо также, чтобы в прецеденте участвовали не
сколько актеров.
Для выявления прецедентов в системе полезно начать с рассмотрения акте
ров и инициируемых ими действий. Каждый прецедент описывает последователь
ность взаимодействий между актером и системой. Прецедент должен приводить
к получению актером какого-либо результата.
Таким образом, функциональные требования к системе определяются в тер
минах прецедентов, составляющих в совокупности внешнюю спецификацию сис
темы. Однако при исследовании прецедентов важно избегать декомпозиции на
несколько мелких прецедентов, описывающих отдельные функции системы. Нуж
но описывать последовательность событий, приносящих актеру определенную
пользу.
Вернемся еще раз к банковской системе. Помимо снятия наличных, Клиент
Банкомата может получить справку о счете или перевести деньги с одного счета
на другой. Поскольку это разные функции, дающие клиенту различные результа
ты, их следует моделировать как разные прецеденты, а не как части одного более
крупного прецедента. Итак, клиент способен инициировать три прецедента, изоб
раженных на рис. 7.5: Снять Деньги, Получить Справку и Перевести Деньги.
Главная последовательность прецедента - это наиболее часто встречающаяся
в нем очередность взаимодействий между актером и системой. От главной после
довательности могут отходить ветви, описывающие взаимодействия, которые
происходят реже. Такие отклонения от главной последовательности вероятны
■ N M i^ Моделирование прецедентов
Рис. 7.5. Актеры и прецеденты в банковской системе
только при определенных условиях - например, если актер вводит в систему не
корректные данные. В зависимости от особенностей приложения альтернативные
ветви позже могут снова сливаться с главной последовательностью. Альтернатив
ные ветви составляют часть описания прецедента.
В прецеденте Снять Деньги главная последовательность - это цепочка ша
гов, приводящая к получению наличных. Альтернативные ветви соответствуют раз
личным ошибкам. Например, если клиент ввел некорректный ПИН-код (П И Н -
персональный идентификационный номер), система должна потребовать повтор
ного ввода. Банкомат может также не опознать карточку, определить, что она во
рованная, и т.д.
7.5. Документирование прецедентов

в модели прецедентов
Прецеденты документируются в модели следующим образом:
□ имя прецедента. Каждому прецеденту присваивается имя;
□ сводка. Краткое описание прецедента, обычно состоящее из одной-двух фраз;
□ зависимости. Этот раздел необязателен, в нем указывается, зависит ли пре
цедент от других прецедентов, и если да, то каков характер зависимости:
включение или расширение;
□ актеры. В данном разделе именуются актеры, участвующие в прецеденте.
Всегда существует главный актер, инициирующий прецедент. Кроме того,
могуг быть второстепенные актеры. Например, в прецеденте Снять День
ги актером является Клиент Банкомата;
□ предусловия. Одно или несколько условий, которые должны быть истинны
ми в начале прецедента. В нашем примере банкомат должен быть свободен
(в таком случае на его экране отображается сообщение «Добро пожаловать»);
□ описание. Основная часть документации прецедента - это словесное оп и
сание главной последовательности. Здесь перечисляются действия актера
Примеры прецедентов 143
и реакция системы на них. Система рассматривается как черный ящик: зна
чение имеют ответы системы на действия актера, а не ее внутреннее устрой
ство;
□ альтернативы. Словесное описание альтернативных ветвей. От главной
последовательности может отходить несколько таких ветвей. Например,
если на счете клиента недостаточно средств, то следует принести извине
ния и вернуть карточку:
□ постусловие. Условие, которое должно быть истинным в конце прецедента,
если исполнение шло по главной последовательности. Например, клиенту
выданы наличные;
□ неясные вопросы. Вопросы по поводу прецедента документируются для об
суждения с пользователями.
7.6. Примеры прецедентов

В этом разделе мы приведем примеры прецедентов для банковской системы
(они являются частью большого примера, которому посвящена глава 19). На
рис. 7.5 показана первая попытка нарисовать диаграмму для банковской системы.
Здесь имеется один актер - Клиент Банкомата - и три прецедента, представля
ющие основные функции, которые инициируются актером, - Снять Деньги, По
лучить Справку и Перевести Деньги.
Клиент взаимодействует с системой посредством устройства считывания кар
точек и клавиатуры. Актером является именно клиент, а не какие-либо устрой
ства, последние служат лишь средствами, с помощью которых клиент иницииру
ет прецедент и отвечает на вопросы системы. Устройства печати чеков и выдачи
наличных - это устройства вывода; они не будут актерами, поскольку именно кли
ент выполняет функцию бенефициария прецедента.
Так как существует три вида транзакций, мы начнем с рассмотрения трех пре
цедентов: Снять Деньги, Получить Справку и Перевести Деньги - по одному
для каждой транзакции. Сначала разберем прецедент Снять Деньги. В этом слу
чае главная последовательность приводит к успешному получению наличных кли
ентом. Сюда входят: считывание карточки, проверка ПИН-кода клиента, контроль
наличия средств на счете и - при условии, что все проверки прошли успешно, -
выдача наличных, печать чека и возврат карточки.
Альтернативные ветви относятся к различным ошибкам, например клиент
ввел неправильный ПИН-код и должен повторить ввод, карточка не опознана или
призвана украденной, и т.д. Поскольку описать их несложно, нет смысла отме
чать отдельные прецеденты. В следующих трех подразделах об этих прецедентах
рассказывается детально.
7.6.1. Прецедент « Снять Деньги»

Имя прецедента. Снять Деньги.
Сводка. Клиент снимает указанную сумму с существующего банковского счета.
Моделирование прецедентов
Актер. Клиент банкомата.
Предусловие. Банкомат свободен, на экране сообщение «Добро пожаловать».
Описание:
1. Клиент вставляет карточку в устройство считывания.
2. Если система опознает карточку, она считывает ее номер.
3. Система предлагает набрать ПИИ-код.
4. Клиент вводит ПИН-код.
5. Система проверяет срок действия, а также не является ли карточка утерян
ной или украденной.
6 . Если карточка действительна, система сравнивает указанный клиентом
П ИН -код с тем, что хранится в системе.
7. Если ПИН-коды совпади, система выя вляет, какие счета доступны владель
цу карточки.
8 . Система отображает номера счетов и предлагает клиенту на выбор три транз
акции: Снять деньги, Получить справку и Перевести деньги.
9. Клиент выбирает «Снять деньги», вводит сумму и выбирает номер счета.
10. Система проверяет, достаточно ли средств на счете клиента и не превышен
ли суточный лимит.
11. Если все проверки прошли успешно, система разрешает выдачу наличных.
12. Система выдает наличные.
13. Система печатает чек, в котором указаны номер и тип транзакции, снятая
сумма и баланс счета.
14. Система возвращает карточку.
15. Система выводит на экран сообщение «Добро пожаловать».
Альтернативы:
□ если карточка не опознается системой, вернуть карточку;
□ если система определяет, что срок действия карточки истек, конфисковать
карточку;
□ если система устанавливает, что карточка утеряна или украдена, конфиско
вать карточку;
□ если набранный клиентом ПИН-код не совпадает с ПИН-кодом карточки,
предложить ввести ПИН-код повторно;
□ если клиент три раза подряд указывает неправильный ПИН-код, конфис
ковать карточку;
□ если система определяет, что номер счета неверен, вывести на экран диагно
стическое сообщение и вернуть карточку;
□ если система выявляет, что на счете клиента недостаточно средств, выра
зить сожаление и вернуть карточку;
□ если система устанавливает, что превышен суточный лимит снятия налич
ных, выразить сожаление и вернуть карточку;
□ если в банкомате недостаточно наличных, принести извинения, вернуть кар
точку и отключить банкомат;
Примеры прецедентов.. | 145
□ если клиент нажим tei 1 тавишу отмены, прервать транзакцию и вернуть
карточку.
Постусловие. Деньги сняты со счета клиента.
7.6.2. Прецедент «Получить Справку»

Имя прецедента. Получить Справку.
Сводка. Клиент получает справку о состоянии существующего банковского
счета.
Описание:
3. Система предлагает указать ПИН-код.
6 . Если карточка действительна, система сравнивает набранный клиентом
ПИН-код с тем, что хранится в системе.
7. Если ПИН -коды совпали, система выясняет, какие счета доступны владель
9. Клиент выбирает «Получить справку» и вводит номер счета.
10. Система считывает баланс счета.
11. Система печатает чек, в котором указаны номер и тип транзакции, снятая
сумма и баланс счета.
Альтернативы:
карточку;
□ если клиент три раза подряд указывает неправильный ПИН-код, конфис
□ если система определяет, что номер счета неверен, вывести на экран диагно
стическое сообщение и вернуть карточку;
Н Ш Я Н м к !» Моделирование прецедентов
□ если клиент нажимает клавишу отмены, прервать транзакцию и вернуть
карточку.
Постусловие. Клиенту выдана справка по счету.
7,6.3, Прецедент «Перевести Деньги»

Имя прецедента. Перевести Деньги.
Сводка. Клиент переводит деньги с одного существующего банковского счета на
другой.
Описание.
3. Система предлагает указать ПИН-код.
6 . Если карточка действительна, система сравнивает набранный клиентом
ПИН -код с тем, что хранится в системе.
7. Если ПИН-коды совпали, система выясняет, какие счета доступны владель
9. Клиент выбирает «Перевести деньги» и вводит сумму, номер исходного сче
та и номер целевого счета.
10. Если система определяет, что на исходном счете достаточно средств, то осу
ществляется перевод.
11. Система печатает чек, в котором указаны номер и тип транзакции, переве
денная сумма и баланс счета.
Альтернативы.
карточку;
□ если клиент три раза подряд указывает неправильный ПИН -код, конфис
□ если система определяет, что номер исходного счета неверен, вывести на эк
ран сообщение об ошибке и вернуть карточку;
Отношения прецедентов .f.'j 147
□ если система выявляет, что номер целевого счета неверен, вывести на экран
сообщение об ошибке и вернуть карточку;
□ если система распознает, что на исходном счете недостаточно средств, вы
разить сожаление и вернуть карточку;
□ если клиент нажимает клавишу отмены, прервать транзакцию и вернуть
карточку.
Постусловие. Деньги клиента переведены с одного счета на другой.
7.7. Отношения прецедентов

Если прецеденты становятся слишком сложными, то можно определить зави
симости между ними, пользуясь отношениями включения и расширения: таким
образом увеличивается расширяемость и пригодность прецедентов для повторно
го использования. При обозначении общих для нескольких прецедентов паттер
нов определяются абстрактные прецеденты, которые в дальнейшем допустимо
применять повторно.
Еще одно отношение между прецедентами, определенное в UML, - это обоб
щение/специализация. Обобщение прецедента сродни отношению расширения,
поскольку оно также предназначено для работы с вариантами. Однако пользова
телей концепция обобщения прецедентов часто настораживает, поэтому в методе
COM ET она задействована только для классов. Варианты же прецедентов вполне
можно учесть с помощью отношения расширения.
7.7.1. Отношение расширения

Иногда прецедент становится чрезмерно сложным и имеет много альтернатив
ных ветвей. Отношение расширения позволяет промоделировать альтернативные
ветви основного прецедента. Сложность прецедента обусловлена большим чис
лом альтернативных, необязательных и исключительных последовательностей
событий. Эта проблема решается путем вычленения таких последовательностей
в отдельный прецедент. Ф ункция нового прецедента состоит в том, чтобы расши
рить старый в случае, когда выполнены определенные условия. Расширяемый
прецедент называется базовым, а расширяющий - расширением.
Например, при некоторых условиях базовый прецедент В можно расширить
в описани и, входящем в расширение Е. Расширять базовый прецедент можно по-
разному, в зависимости от условий. Отношение расширения используется следу
ющим образом:
□ чтобы показать условную часть базового прецедента (выполняемую только
при соблюдении заданных условий);
□ чтобы промоделировать сложные или альтернативные пути.
Важно отметить, что базовый прецедент не зависит от расширения и способен
функционировать и без него. С другой стороны, расширяющий прецедент будет
выполняться только тогда, когда оказалось истинным некоторое условие в базо
вом. Без базового прецедента расширение функционировать не может. Обычно
■M i Моделирование прецедентов
расширение дополняет только один баз j b i ш нрец дп т, хотя это и н б (Тельно:
оно в состоянии расширять сразу несколько прецедентов.
Допустимо определить точки расширения, которые точно задают места, куда
следует добавить расширения базового прецедента. Тогда расширение дополнит
базовый прецедент только в этих точках [Fowler and Scott 1999; Rumbaugh, Booch,
and Jacobson 1999].
Проиллюстрируем отношение расширения на примере из системы автомати
зации производства. Инженер-технолог определяет несколько производственных
операций, а затем составляет технологическую карту процесса, в которой фикси
руется последовательность операций при изготовлении детали. Это можно про
моделировать с помощью одного прецедента. Однако большая гибкость достига
ется, если воспользоваться расширяющим прецедентом, как показано на рис. 7.6.
Создать/Изменить Операцию - базовый прецедент, который исполняется при
создании каждой операции. Прецедент Создать/Изменить Технологическую
Карту расширяет базовый. Таким образом, технолог может провести несколько
операций с помощью базового прецедента, а затем при необходимости разрабо
тать технологическую карту посредством прецедента расширения. В разделе
«Альтернативы» описания прецедента Создать/Изменить Операцию будет ска
зано, что технолог вправе создать технологическую карту процесса, объединяю
щую ранее определенные операции в последовательность.
‘extend-
Рис. 7.6. Пример отношения расширения
На рис. 7.6 продемонстрирован также способ уменьшить число прецедентов.

Некоторые прецеденты следуют шаблону Создать/Прочитать/Изменить.
Можно подготовить отдельный прецедент для каждой функции: Создать Опе
рацию, Изменить Операцию, Прочитать Операцию. Однако удобнее сократить
объем работы, объединив все три функции в один прецедент под названием Со
здать/Изменить Операцию. По той же причине имеется только один прецедент
Создать/Изменить Технологическую Карту. В этих примерах допустимо вы
брать, какие из функций создания, чтения и изменения будут помещены в главную
последовательность. Первый вариант - оставить в главной последовательности
функцию создания, поскольку она содержит больше взаимодействий, а функции
изменения и чтения вынести в альтернативную ветвь. Второй вариант - включить
Отношения прецедентов ! Ш 1 Ш
в главную последовательность как создание, так и изменение, при этом в преце
денте появится такая строка:
Если это новая операция, предложить оператору ввести ее название.
Подобные простые ветвления можно включать в главную последовательность,
поскольку они не затемняют ее сути. Предложения же типа «если-то-ииаче» вклю
чать в описание не рекомендуется: это сделает его похожим на псевдокод.
7.7.2. Отношение включения

После разработки первого варианта прецедентов часто выявляются последо
вательности взаимодействий между актером и системой, общие для нескольких
прецедентов. Они отражают функциональность, свойственную более чем одному
прецеденту. Общий фрагмент можно изъять и превратить в отдельный прецедент,
называемый включаемым. Включаемый прецедент является абстрактным в том
смысле, что не может исполняться независимо, а лишь в составе конкретного пре
цедента.
Вынеся общую функциональность во включаемый прецедент, ее легко исполь
зовать в нескольких прецедентах. Следовательно, можно сократить описания ста
рых прецедентов, убрав из них включаемую часть. Такая сокращенная версия на
зывается конкретным (или базовым) прецедентом, включающим абстрактный
прецедент.
Абстрактные прецеденты всегда отражают функциональность, общую для
нескольких прецедентов. Если общая функциональность абстрагируется, то аб
страктный прецедент допустимо включать в различные конкретные прецеденты.
Обычно абстрактные прецеденты удается выделить только после первой итера
ции, на которой несколько прецедентов уже разработано. Лишь тогда становятся
заметны повторяющиеся цепочки взаимодействий.
Абстрактный прецедент никогда не исполняется изолированно, а лишь в со
четании с конкретным прецедентом, который его включает, а значит, и исполняет.
Если провести аналогию с программированием, то абстрактный прецедент похож
на библиотечную процедуру, а конкретный - на вызывающую ее программу.
В абстрактном прецеденте может и не быть никакого актера. Актер присут
ствует в конкретном прецеденте, включающем абстрактный. Поскольку абстракт
ный прецедент способен включаться в разные конкретные, то им могут пользо
ваться различные актеры.
Проиллюстрируем применение абстрактных прецедентов на примере ранее
описанных прецедентов Снять Деньги, Получить Справку и Перевести День
ги. Нетрудно заметить, что первая часть - проверка ПИН-кода клиента - во всех
случаях одинакова. Нет смысла повторять ее в каждом прецеденте. Удобнее выде
лить проверку ПИН-кода в абстрактный прецедент, называемый Проверить ПИН-
код, и использовать во всех трех вышеупомянутых прецедентах. Получившаяся
диаграмма прецедентов показана на рис. 7.7. Абстрактный прецедент Проверить
ПИН-код и конкретные прецеденты Снять Деньги, Получить Справку и Пере
вести Деньги подробно описаны в примере банковской системы (глава 19).
т т ы , - Моделирование прецедентов
Проверить ПИ!
/ \
/
/
•include» \
'include»
// ч «include»
/ \
( Пере
Перевести fl
Рис, 7.7, Пример абстрактного прецедента и отношения включения
7.7.3. Некоторые рекомендации

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

В больших системах работа с огромным числом прецедентов становится за
труднительной. Решить эту проблему можно с помощью пакетов прецедентов,
включающих группы взаимосвязанных прецедентов. Такой пакет может представ
лять высокоуровневые требования, предъявляемые к крупным подсистемам. По
скольку зачастую инициируют и участвуют в логически связанных прецедентах
одни и те же актеры, то объединение прецедентов в пакеты удобно осуществить
на основе участвующих в них актеров.
Например, в системе автоматизации производства главные актеры - это ин
женер-технолог, дежурный оператор и начальник производства, и каждый из них
инициирует несколько прецедентов и участвует в них. Следовательно, допустимо
создать пакеты прецедентов, обозначив их именами главных актеров: «Прецеден
ты инженера-технолога», «Прецеденты дежурного оператора» и «Прецеденты на
чальника производства». На рис. 7.8 приведен пример Пакета Прецедентов
Дежурного Оператора, состоящего из четырех прецедентов. Дежурный Опе
ратор является главным актером в прецедентах Следить за Сигналами Тре
воги и Следить за Состоянием Рабочей Станции и второстепенным - в ос
тальных прецедентах. Заводской Робот - главный актер в прецедентах Поднять
Тревогу и Известить и Изменить Состояние Рабочей Станции и Известить.
Резюме ..H ill
Рис. 7.8. Пример пакета прецедентов
7.9. Резюме
В этой главе описывалось формулирование функциональных требований
к системе на основе прецедентов. Рассматривались концепции актера и прецеден-
тн, рассказывалось об отнолюпиях между прецедентами, в частности об от'
-1 т> и г Т I т р _
пнях расширения и включения.

Модель прецедентов оказывает сильное влияние на последующие этапы раз
работки ПО. Прецеденты затем уточняются в аналитической модели иа этапе ди
намического моделирования (см. главу 11). Для каждого прецедента выявляются
участвующие в нем объекты с помощью критериев структурирования объектов,
описанных в главе 9, и определяется последовательность взаимодействий между
объектами. Разработку ПО можно вести постепенно, выделяя прецеденты, кото
рые будут реализованы на каждой стадии (см. главу 5). Н а основе прецедентов
также составляются тесты сопряжений и комплексные тесты.
■вделиреванш©
Н а этапе статического моделирования рассматриваются структурные аспекты за
дачи путем моделирования классов реального мира. Статическая модель описы
вает статическую структуру системы, изменение которой менее вероятно, чем из
менение функций системы. В этой главе под статическим моделированием мы
будем понимать как сам процесс моделирования, так и описывающую модель диа
грамму классов в нотации UML.
В статической модели определяются классы объектов системы, их атрибуты,
операции и отношения между классами. Концепции классов и объектов представ
лены в главе 3. В этой главе речь пойдет об отношениях между классами. Будут
рассматриваться следующие типы отношений: ассоциация, композиция, агреги
рование и обобщение/специализация. Кроме того, описываются некоторые спе
циальные вопросы моделирования предметной области, а именно: статическое
моделирование контекста системы и статическое моделирование сущностных
классов. Проектирование операций классов мы отложим до главы 15, рассказыва
ющей об этапе проектирования.
Статические модели изображаются на диаграммах классов, проанализирован
ных в главе 2. Кроме того, классу может быть приписан стереотип. Многие из при
веденных в этой главе примеров иллюстрируют сущностные классы, которые на
сыщены данными и имеют стереотип «сущность».
8.1. Ассоциации между классами

Ассоциация определяет статическое структурное отношение между двумя или
более классами. Например, Служащий Работает-в Отделе. Здесь Служащий
и Отдел - классы, а Работаете - ассоциация.
Связь (link) - это соединение между экземплярами объектов, она является
экземпляром ассоциации между классами. Например, Джейн Работает-в Про
изводственном Отделе - это связь между Джейн (экземпляром класса Служа
щий) и Производственным Отделом (экземпляром класса Отдел). Связь между
двумя объектами может существовать тогда и только тогда, когда между их клас
сами существует ассоциация.
Н а диаграммах классов имена ассоциаций обычно читаются слева направо
и сверху вниз. Ассоциации но природе своей двунаправленны. Имя ассоциации
читается в прямом направлении: Служащий Работает-в Отделе. В обратном на
правлении эта ассоциация выглядит так: Отдел Имеет Служащих. Ассоциации ча
сто являются бинарными, то есть представляют отношение между двумя классами.
Ассоциации между классами J■ ■ ■ ■ ■ 153
Однако встречаются также унарные (класса с самим собой) и тернарные (трех
сторонние) ассоциации, а также ассоциации более высокого порядка.
8.1.1. Изображение ассоциаций на диаграммах классов

Н а диаграммах классов ассоциация изображается в виде линии, соединяющей
два прямоугольника классов. Рядом с линией записывается имя ассоциации. Так,
на рис. 8.1 приведен пример ассоциации Компания Имеет Президента. На диа
граммах с большим числом классов они обычно расположены друг относительно
друга по-разному. Чтобы не было неоднозначности при чтении диаграмм классов,
можно следовать таким соглашениям:
□ при чтении ассоциации сверху (Компания) вниз (Президент) имя ассоци
ации (Имеет) изображается справа от линии (см. рис. 8.1);
□ при чтении снизу вверх имя записывается слева от линии;
□ при чтении слева направо имя находится под линией;
□ при чтении справа налево имя располагается над линией.
► Направление ассоциации
Рис. 8.1. Пример ассоциации один-к-одному
Во избежание путаницы можно также рисовать маленькую стрелку в направ

лении чтения ассоциации, как показано на рис. 8.1. Видеть направление чтения
обычно проще, чем запоминать соглашения. Поэтому нотация стрелок, допускае
мая UML, применяется в COM ET для изображения направления ассоциаций
в статической модели предметной области.
8.1.2. Кратность ассоциаций

Кратность ассоциации определяет, сколько экземпляров одного класса может
быть соотнесено с одним экземпляром другого класса. Возможны следующие крат
ности:
□ ассоциация один-к-одному. В случае такой ассоциации объект одного класса
связан ровно с одним объектом другого класса. Например, в ассоциации
154 ■ ■ ■ i t . ' Статическое моделирование
Компания Имеет Президента у конкретной компании есть только один пре
зидент, и наоборот, президент возглавляет только одну компанию. Так, у ком
пании Microsoft есть президент Стив Балмер, Нотация, применяемая в ста
тической модели для ассоциаций один-к-одному, показана на рис. 8 ,1 ;
□ ассоциация один-ко-многгш. В этом случае имеется ассоциация один-к-од-
ному в одном направлении и ассоциация один-ко-многим - в другом. Н а
пример, в ассоциации Банк Управляет Счетом один банк управляет мно
гими счетами, но каждый счет управляется только одним банком. Нотация
для изображения ассоциаций один-ко-многим показана на рис. 8 .2 ;
□ ассоциации с заданной кратностью. В таком случае для ассоциации задает
ся конкретное числовое значение кратности. Например, в случае ассоциа
ции Автомобиль Имеет Дверь у одного автомобиля может быть две или
четыре двери (обозначается в виде 2,4), но не одна, не три и не пять дверей.
В противоположном направлении ассоциация имеет тип один-к-одному, то
есть дверь принадлежит ровно одной машине. Отметим, что решение о том,
сколько дверей должно быть у машины, принимает компания-изготовитель,
другая компания может сделать иначе. Нотация для ассоциаций с заданной
кратностью показана на рис. 8.3;
□ необязательная ассоциация. В этом случае объект одного класса может не
быть связанным с объектом другого класса. Например, в ассоциации Кли
ент Владеет Дебетовой Картой клиент сам решает, приобретать ему де
бетовую карту или нет. Необязательная (с кратностью один или нуль) ассо
циация показана на рис. 8.4. Возможна также ассоциация типа «нуль, один
или много». Например, в случае ассоциации Клиент Владеет Кредитной
Картой у клиента может вовсе не быть кредитной карты, он может обла
дать одной или несколькими такими картами (рис. 8.5);
Рис. 8.2. Пример ассоциации Рис. 8.3. Пример ассоциации

о д и н -к о -м н о ги м с заданной кратностью
Ассоциации между классами 155
□ ассоциация многие-ко-лтагим. В этом случае ассоциация в каждом направле
нии имеет тип одии-ко-многим. Например, ассоциация Курс Посещается
Студентами имеет тип одии-ко-многим, поскольку на курс может записать
ся много студентов. Но и тип ассоциации в обратном направлении Студент
Посещает Курс также один-ко-многим, так как студент может записаться на
несколько курсов. Это показано на рис. 8 .6 .
Рис. 8.4. Необязательная Рис. 8.5. Необязательная Рис. 8.6. Ассоциация

ассоциация ( с кратностью ассоциация ( с кратностью многие-ко-многим
нуль или один) нуль, один или много)
8.1.3. Другие ассоциации

Тернарной называется трехсторонняя ассоциация между классами, например
между классами Покупатель, Продавец и Агент. Смысл ассоциации состоит
н том, что Покупатель договаривается о цене с Продавцом при посредничестве
Агента (рис. 8.7). Тернарная ассоциация изображается в виде ромба, соединяю
щего все три класса. Ассоциации высоких порядков между четырьмя и более клас
сами встречаются редко.
Унарная ассоциация, которую еще называют самоассоциацией, - это ассоциа
ция между двумя объектами одного и того же класса. Примеры: Человек есть-
ребенок Человека, Человек состоит-в-браке с Человеком и Служащий
есть-начальник Служащего.
8.1.4. Атрибуты связи

В сложных ассоциациях между двумя и более классами связь может иметь
атрибуты. Чаще всего так бывает с ассоциациями многие-ко-многим, когда атри
бут нельзя отнести ни к какому классу, а только к самой ассоциации. Рассмотрим,
в частности, ассоциацию многие-ко-миогим между классами Проект и Работник:
156 | i- Статическое моделирование
«сущность» «сущность»
Покупатель Продавец
имя : String — ................... / Д О Г О R 8 р !Л R 8 6 Т 0 Я \ ........................... имя : String

ад ре с: String N. о цене / а д р е с: String
телефон: String телефон: String
датаПрибытия: Date ценаПродажи: Integer
начальнаяЦена: integer
«сущность»
Агент
имя : String
ад ре с: String
компания : String
рабочийТелефон: Siring
домашнийТелефон : String
Рис. 8.7. Пример тернарной ассоциации
Проект Включает Работников

Работник Участвует-в Проекте
В проекте может быть занято много работников, и каждый работник способен
участвовать в нескольких проектах.
Атрибут Отработано Часов не относится ни к Проекту, ни к Работнику.
Это атрибут ассоциации между классами Проект и Работник, так как он обозна
чает количество часов, отработанных конкретным человеком по конкретному про
екту (рис. 8 .8 ).
Рис. 8.8. Пример атрибута связи
8.1.5. Классы-ассоциации
Альтернативой использованию атрибутов связи служит класс-ассоциация.
Так называется класс, который моделирует ассоциацию между двумя или более
классами. Как правило, эта концепция оказывается полезной для ассоциаций мно-
гие-ко-многим. Атрибутами класса-ассоциации являются атрибуты ассоциации.
Иерархии композиции и агрегирования - й | И В И И В Ш
Класс-ассоциация предпочтительнее атрибутов связи, так как он поднимает слож

ные ассоциации с собственными атрибутами на уровень класса. Кроме того,
в большинстве СУБД класс-ассоциация легко моделируется как отношение в базе
данных.
В предыдущем примере вместо атрибутов связи допустимо было использовать
и класс-ассоциацию, атрибутами которого стали бы атрибуты связи. На рис. 8.9
показан класс-ассоциация Часы для ассоциации многие-ко-многим между клас
сами Проект и Работник.
Рис. 8.9. Пример класса-ассоциации
8.2. Иерархии композиции и агрегирования

И иерархия композиции, и иерархия агрегирования предназначены для описа
ния класса, составленного из других классов. Композиция и агрегирование - это
частные случаи ситуации, в которой классы сильно связаны отношением целое/
часть. В обоих случаях отношение между частями и целым выражается фразой «яв
ляется частью».
Композиция - более сильная форма агрегирования, а агрегирование сильнее,
чем ассоциация. Иными словами, композиция описывает более тесную связь меж
ду частями и целым, чем агрегирование. Она является также отношением между
экземплярами. Это означает, что объекты-части создаются, живут и уничтожают
ся вместе с объектом-целым. Объект-часть может принадлежать только одному
целому.
Составной класс часто подразумевает физическое отношение между целым
и частями. Так, в примерах статических моделей и лифт, и банкомат являются со
ставными классами. Дверь, мотор, кнопки и лампочки лифта можно промодели
ровать как части составного объекта «лифт». Следовательно, составной класс Лифт
содержит четыре части: Кнопка Лифта, Лампочка Лифта, Мотор и Дверь. Каж
дый объект класса Лифт состоит из одного объекта Мотор, одного объекта Дверь,
п объектов Кнопка Лифта и п объектов Лампочка Лифта. Поэтому на рис. 8.10 со
ставной класс Лифт связан ассоциацией один-к-одному с классами Мотор и Дверь
и ассоциациями один-ко-многим с классами Кнопка Лифта и Лампочка Лифта.
Щ Ш Ш М Ш S" Статическое моделирование
Рис. 8.10. Пример иерархии композиции
Иерархия агрегирования - это более слабая форма отношения целое/часть.

При агрегировании экземпляры-части разрешается добавлять и исключать из э к
земпляра-целого (агрегата). Поэтому агрегрирование чаще используется для мо
делирования концептуальных, а не физических классов. Кроме того, часть может
принадлежать сразу нескольким агрегатам. В качестве примера иерархии агреги
рования рассмотрим Колледж (рис. 8.11), частями которого являются Админис
трация, несколько Факультетов и несколько Исследовательских Центров.
Иногда создаются новые факультеты или ликвидируются старые, а иногда не
сколько факультетов объединяются. Исследовательские центры также допустимо
создавать, удалять и объединять.
И при композиции, и при агрегировании атрибуты распространяются от це
лого к части. Это означает, что конкретный лифт определяет также и конкретные
дверь и мотор, являю щ иеся его частями. Однако для точной идентификации
кнопки или лампочки нужен также дополнительный атрибут - Этаж.
Рис. 8.11. Пример иерархии агрегирования

Иерархия обобщения/специализации / ( Н 'Л Ш И Н Б О
8.3. Иерархия обобщения/специализации

Некоторые классы похожи, но не идентичны, У них есть общие и специфичес
кие атрибуты. В иерархии обобщения/специализации общие атрибуты выносят
ся в обобщенный класс, который называется суперклассом (а также родительским
классом или классом -предком). Специфические атрибуты остаются свойствами
специализированного класса, который носит имя подкласса (порожденный класс,
класс-потомок). Между подклассом и суперклассом существует отношение ЯВ
ЛЯЕТСЯ.
Каждый подкласс наследует свойства суперкласса, но затем расширяет их
удобным для себя способом. Свойствами класса считаются его атрибуты и опера
ции. При наследовании подклассу разрешается модифицировать суперкласс. Под
класс наследует атрибуты и операции от суперкласса, но может добавить новые
атрибуты и операции, а также переопределить существующие операции. Любой
подкласс способен, в свою очередь, стать суперклассом, порождающим еще более
специализированные подклассы.
В качестве примера рассмотрим банковские счета на рис. 8.12. У чекового
и сберегательного счета есть ряд общих атрибутов и некоторые специфические.
Атрибуты, общие для счета любого вида, - номер Счета и баланс - становятся
атрибутами суперкласса Счет. Атрибуты, существующие только у сберегательно
го счета, например процентные Начисления (по чековым счетам проценты не
начисляются), переносятся в подкласс Сберегательный Счет. Атрибуты, суще
ствующие только у чекового счета, в частности сумма Последнего Вклада, ста
новятся атрибутами класса Чековый Счет.
Сберегательный Счет ЯВЛЯЕТСЯ Счетом
Чековый Счет ЯВЛЯЕТСЯ Счетом
Дискриминант - это атрибут, показывающий, какое свойство объекта абстраги
ровано отношением обобщения. Например, для иерархии счетов дискриминантом
будет тип Счета, именно он отличает Сберегательный Счет от Чекового Сче
та. (рис. 8.13),
Р ис. 8.12. Иерархия обобщения/специализации

Статическое моделирование
Счет
номерСчета : Integer
баланс •. Real
типСчета
«сущность» «сущность»
ЧековыйСчет СберегательныйСчет
суммаДепозита: Real процент: Reai
Рис. 8.13. Дискриминант в иерархии обобщения/специализации
8.4. Ограничения
Ограничение (constraint) задает условие, которое должно быть выполнено
[Rumbaugh, Booch, and Jacobson 1999]. Ограничение выражается в произволь
ной словесной форме. UM L также включает язык описания ограничений Object
C onstraint Language (О CL) [Warner and Kleppe 1999], использование которого,
впрочем, факультативно.
Один из видов ограничений - ограничения иа атрибуты. Так, в примере с бан
ком можно потребовать, чтобы баланс счета никогда не был отрицательным. Это
выражается в виде ограничения на атрибут баланс класса Счет: [б ал ан с > 0].
На диаграмме классов ограничение на атрибут показывается рядом с соответству
ющим классом (рис. 8.14).
Другой вид ограничений - ограничение иа связь. Обычно объекты со стороны
«многие» не упорядочены. Но в некоторых случаях предметная область предпо
лагает наличие порядка между объектами, и данное требование желательно отра
зить в модели. Рассмотрим, к примеру, такую ассоциацию один-ко-многим:
Счет Модифицирован Транзакцией Банкомата
В подобной ассоциации транзакции упорядочены по времени, и, значит, огра
ничение легко выразить в виде {упорядочены по времени}. Такое ограничение
можно изобразить на диаграмме классов, как показано на рис. 8.15.
8.5. Статическое моделирование и язык UML

Хотя диаграммы классов являются в UM L стандартными, нет единого мне
ния о том, как их следует применять при построении статической модели, то есть
каким методом пользоваться для их разработки. Некоторые методологи советуют
включать в статическую модель все классы [Booch 1994]. Другие считают, что
в статической модели должны быть отражены только сущностные [Rosenberg and
Scott 1999], то есть информационно насыщенные классы, которые обычно отобра
жаются на базу данных. Третьи рекомендуют различные уровни статического
Статическое моделирование и язык UML
Счет
баланс: Real
_____ ^
М одифицирован
f
{упорядочены
по времени}
ТранзакцияБанкомата
«сущность» идТранзакции: Integer
Счет идКарточки: Integer
номерСчета: Integer ПИН-код: String
баланс : Real д а та : Date
время : Time
статус: Integer
{баланс > 0}
Рис. 8.14. Пример Рис. 8.15. Пример

ограничений на объекты упорядочения ассоциации
моделирования - начиная с концептуальною на этапе анализа и заканчивая бо

лее детальным на этане проектирования [Fowler and Scott 1999].
В методе COM ET концептуальная статическая модель строится на раннем
этапе анализа и используется для лучшего освоения предметной области. Цель
состоит в том, чтобы сосредоточить внимание на тех аспектах предметной облас
ти, которые наиболее заметны в статической модели, в частности на физических
и информационно насыщенных классах, которые называю тся сущностными.
В этом разделе описывается процесс создания черновой концептуальной ста
тической модели, выполняемый на этапе анализа; более подробная статическая
модель строится позже, на этапе проектирования (см. главы 12 и 15).
8.5.1. Статическое моделирование предметной области

При построении статической модели предметной области в методе COM ET
сначала моделируются физические и сущностные классы. К физическим, клас
сам относятся классы, обладающие физическими характеристиками, то есть
описывающие предметы, которые можно увидеть или потрогать. Это физичес
кие устройства (нередко являющиеся частью предметной области во встраивае
мых приложениях), пользователи, внешние системы и таймеры. Сущностными на
зываются концептуальные информационно насыщенные классы, которые обычно
являются устойчивыми, то есть долго живущими. Сущностные классы особенно
часто встречаются в информационных системах. Так, в банковских системах бы
вают дебетовые карточки, счета и транзакции.
Для встраиваемых систем, где есть датчики и приводы, диаграммы классов по
могают моделировать реальные устройства. Например, в системе управления лиф
тами полезно промоделировать физические устройства (мотор, дверь, кнопки
162 Статическое моделирование
и лампочки), их ассоциации и кратности ассоциаций. Д ля изображения состав
ных частей класса, отражающего некий аспект реального мира, обычно пользуют
ся составными классами. Так, лифт - это составной класс, включающий в себя
мотор, дверь, несколько кнопок и лампочек (см. рис. 8 . 1 0 ).
Рассмотрим статическую модель предметной области для банковской систе
мы. У банка есть несколько банкоматов (рис. 8.16). Каждый банкомат - это со
ставной класс, содержащий Устройство Считы вания Карточек, Устройство
Выдачи Наличных, Устройство Печати Чеков и Клиента Банкомата, кото
рый взаимодействует с системой посредством клавиатуры и дисплея. Устрой
ство Считывания Карточек читает пластиковую Карточку, являющуюся фи
зической сущностью. Устройство Выдачи Наличных выдает Наличные, то есть
бумажные купюры определенного достоинства, которые также вполне осязаемы.
Устройство Печати Чеков распечатывает Чек - тоже физическую сущность
в виде листка бумаги. Физические сущности представляют собой классы пред
метной области, для которых в программе требуется построить концептуальное
представление. В большинстве случаев нужно создать программные классы, от
ражающие данные физические сущности. Такие решения принимаются во вре
мя проектирования классов и объектов, как описано в главе 9. Помимо этого есть
еще Оператор, также являющийся пользователем, в обязанности которого вхо
дит обслуживание банкомата. Как и клиент Банкомата, Оператор взаимодей
ствует с системой при помощи клавиатуры и дисплея.
Рис. 8.16. Концептуальная статическая модель банковской системы
8.6. Статическое моделирование контекста системы

Важно хорошо понимать интерфейс между системой и внешней средой - кон
текст системы. В структурном анализе он изображается па диаграмме тнтег.стс
системы. Нотация UM L не пред оставляет явкой поддержки для таки \ диаграмм,
однакс кош t-кстсис темы можно изобра и,> l посредством статической модели или
модели кооперации [Douglass 1999b], При моделировании предметной области
Статическое моделирование контекста : 163
полезно выявить границы системы, для чего разрабатывается диаграмма классов
контекста системы, дающая более детальное представление о границах, чем диа
грамма прецедентов.
Диаграмму классов контекста системы можно построить путем статического
моделирования внешних классов, соединенных с системой. В частности, физичес
кие классы, о которых речь шла в предыдущем разделе, - это зачастую устройства
ввода/вывода, которые выступают в роли внешних для системы классов. Можно
также воспользоваться диаграммой прецедентов, рассмотрев актеров и устрой
ства, которыми они пользуются для взаимодействия с системой. Ниже описыва
ются оба подхода.
8.6.1 Внешние классы

С помощью нотации UML контекст системы моделируется так: система изоб
ражается в виде агрегатного класса со стереотипом «система», а внешняя среда -
в виде набора внешних классов, с которыми система должна взаимодействовать.
Внешние классы характеризуются с помощью стереотипов. Внешний класс
можно назвать «внешним устройством ввода», «внешним устройством вывода»,
«внешним устройством ввода/вывода», «внешним пользователем» «внешней сис
темой» или «внешним таймером». Применение стереотипов для классификации
внешних классов гораздо подробнее описано в главе 9.
Д ля систем реального времени желательно выявить низкоуровневые классы,
соответствующие физическим устройствам ввода/вывода. Эти внешние классы
изображаются со стереотипом «внешнее устройство ввода/вывода». Примерами
могут служить Вал в системе круиз-контроля и Мотор в системе управления лиф
тами.
Человек часто взаимодействует с системой посредством стандартных устройств
ввода/вывода. Характеристики данных устройств несущественны, так как с ними
работает операционная система. Гораздо полезнее описать интерфейс с точки зре
ния того, какую информацию пользователь получает, а какую - вводит. Поэтому
внешний пользователь, взаимодействующий с системой при помощи стандартных
устройств, моделируется как «внешний пользователь», а не как устройство.
Общая рекомендация такова: пользователя-человека следует представлять
классом внешнего пользователя, если для работы с системой он применяет толь
ко стандартные устройства. С другой стороны, если ему приходится использовать
специализированные устройства ввода/вывода, то их нужно представлять клас
сами внешних устройств.
Класс «внешнего таймера» используется, если приложение должно следить
за временем или если события внешнего таймера инициируют какие-то собы
тия в системе. Чаще всего класс «внешнего таймера» бывает полезен в системах
реального времени. Примером может служить Тактовый Генератор в системе
круиз-контроля: он нужен для того, чтобы система могла вести отсчет времени
при вычислении скорости движения, и для запуска различных периодических
видов деятельности. Иногда потребность в таких видах деятельности становится
очевидной только на этапе проектирования.
I Статическое моделирование
Класс «внешней системы» необходим в случаях, когда система обменивается
данными с другими системами. Так, система автоматизации производства взаи
модействует с двумя внешними: Подъемно -Транспортным Роботом и Сбороч
ным Роботом.
Ассоциации между системными агрегатными классами и внешними класса
ми, а также их кратности изображаются на диаграмме классов контекста системы.
Таким ассоциациям присваиваются стандартные имена: Вводит, Выводит, Со
единен, Взаимодействует и Пробуждает, например:
«внешнее устройство ввода» Вводит-в «систему»
«система» Выводит-на «внешнее устройство вывода»
«внешний пользователь» Взаимодействует-с «системой»
«внешняя система» Соединена-с «системой»
«внешний таймер» Пробуждает «систему»
8.6.2. Пример разработки диаграммы классов

контекста системы с внешними классами
Пример диаграммы классов контекста системы приведен на рис. 8Л7, где изоб
ражены внешние классы, с которыми должна связываться банковская система.
Внешние классы определяются непосредственно из ранее описанной статической
модели предметной области.
С точки зрения общей программно-аппаратной структуры системы клиент бан
комата является внешним по отношению к системе, тогда как устройства ввода/вы
вода - частями самой системы. С точки зрения только программного обеспечения
устройства ввода/вывода для программы являются внешними, поэтому модели
руются как внешние классы,
В данном примере выделяются три класса внешних устройств: Устройство
Считывания Карточек, Устройство Печати Чеков и Устройство Выдачи
Рис. 8.17. Диаграмма классов контекста банковской системы

Статическое моделирование контекста I— 165
Наличных. Есть также два класса внешних пользователей: К лиент Б ан к о м ата
и Оператор, которые взаимодействуют с системой посредством клавиатуры
и дисплея. Д ля каждого банкомата имеется ровно по одному экземпляру этих
внешних классов.
8.6.3. Актеры и внешние классы

Рассмотрим, как можно вывести диаграмму классов контекста системы путем
анализа взаимодействующих с ней актеров. Актеры - это более абстрактная кон
цепция, нежели внешние классы. Между актерами и внешними классами суще
ствуют следующие отношения:
□ акт,ер-устройство ввода/вывода эквивалентен классу внешнего устройства
ввода/вывода. Это значит, что такой актер связан с системой посредством
класса внешнего устройства;
□ актер-внешняя система эквивалентен классу внешней системы;
□ актер-таймер связан с системой посредством класса внешнего таймера, ге
нерирующего для системы события;
□ актер-человек обладает наибольшей гибкостью. В простейшем случае он об
щается с системой при помощи стандартного устройства ввода/вывода.
Внешнему классу присваивается имя актера-человека, поскольку интерес
представляет именно логическая структура информации, поставляемой че
ловеком. В более сложных случаях такой актер способен общаться с систе
мой посредством различных внешних классов. Примером может служить
актер-клиент в банковской системе.
8.6.4. Пример разработки диаграммы классов

контекста системы на основе рассмотрения актеров
Чтобы определить внешние классы по актерам, необходимо ясно представлять
себе характеристики каждого актера и его взаимодействие с системой. Эту инфор
мацию можно почерпнуть из описания прецедентов. Рассмотрим случай, когда
актерами являются люди, В банковской системе есть два актера-человека: Кли
ент Банкомата и Оператор.
На рис. 8.17 показана диаграмма классов контекста банковской системы. Бан
ковская система представлена в виде одного агрегатного класса и соединенных
с ним внешних классов. Оператор общается с системой с помощью стандартного
устройства и потому изображен как внешний пользователь: характеристики
пользователя в таком случае важнее характеристик устройства. Что касается
клиента, то он взаимодействует с системой посредством одного стандартного
и трех специализированных устройств. К нестандартным относится одно внешнее
устройство ввода/вывода (Устройство Считывания Карточек) и два внешних
устройства ввода (Устройство Печати Чеков и Устройство Выдачи Налич
ных). Все пять внешних классов связаны с банковской системой ассоциациями
один-ко-многим. Н а рис. 8.17 представлено, как актеры соотносятся с внешними
классами (в общем случае показывать актеров на диаграммах классов контекста
системы необязательно).
И Ш Ш Ш Ш -v ! Статическое моделирование
8.7. Статическое моделирование

сущностных классов
Сущностными называются концептуальные информационно насыщенные клас
сы. В них хранятся устойчивые (долго живущие) данные, к которым имеются обра
щения из нескольких прецедентов. Чаще всего сущностные классы встречаются
в информационных системах, но многие распределенные приложения и приложе
ния реального времени тоже нуждаются в информации. Сущностные классы неред
ко отображаются на базу данных на этане проектирования (см. главу 15).
При построении статической модели предметной области акцент ставится на
выявлении сущностных классов, их атрибутов и взаимоотношений. В частности,
в банковской системе есть банки, счета, клиенты, дебетовые карточки и транзак
ции. Каждая из этих сущностей реального мира моделируется в виде сущностно
го класса и изображается со стереотипом «сущность». Затем определяются атри
буты таких классов и отношения между ними.
Пример концептуальной статической модели сущностных классов в банков
ской системе приведен на рис. 8.18 и подробно описан в главе 19. На этом рисунке
изображен класс Банк, который находится в отношении один-ко-многим с клас
сами Клиент и Дебетовая Карточка. Между классами Клиент и Счет имеется
отношение многие-ко-многим. У класса Счет есть специализации Чековый Счет
Рис. 8.18. Концептуальная статическая модель банковской системы:

сущностные классы
Резюме i$&J 167
и Сберегательный Счет. В случае, когда атрибуты принадлежат ассоциации, а не

связанным ею классам, могут понадобиться классы-ассоциации. Так, для ассоци
ации многие-ко-многим между Дебетовой Карточкой и Счетом индивидуаль
ные счета, доступные по данной карточке, - это атрибуты класса-ассоциации Кар
точный Счет, а не классов Дебетовая Карточка или Счет. Другой пример
сущностного класса - Транзакция Банкомата, у него есть специализации для
разных типов транзакций. Такая диаграмма классов подробно описана в главе 19,
где рассматриваются также атрибуты каждого класса.
8.8. Резюме
В этой главе описывались некоторые основные аспекты статического модели
рования, в том числе отношения между классами. Были упомянуты три типа от
ношений: ассоциация, композиция/агрегирование и обобщение/специализация.
Кроме того, показывалось, как статическая модель используется для моделирова
ния структурных аспектов предметной области. Сюда относится статическое мо
делирование контекста системы, целью которого является изображение внешних
для системы классов, и статическое моделирование сущностных классов.
Статическое моделирование области решения откладывается до этапа проек
тирования. Хотя в состав статической модели входит характеристика операций
каждого класса, их проще выявить после построения динамической модели, по
этому определение операций переносится на этап проектирования классов, опи
санный в главе 15. Вопросы, касающиеся навигации между классами, также будут
решаться на этапе проектирования, речь об этом пойдет в главе 1 2 .
иа к
После определения прецедентов и построения статической модели делается пер
вая попытка выявить программные объекты, участвующие в системе. На данном
этапе обратить внимание следует, прежде всего, на объекты программы, соответ
ствующие реальным объектам из предметной области.
Программные объекты обычно определяются на базе прецедентов и статичес
кой модели предметной области. В настоящей главе приводятся рекомендации по
поводу того, как это лучше делать. Предлагаются критерии разбиения на объек
ты, а сами объекты классифицируются с помощью стереотипов. Основной инте
рес будут представлять реальные объекты предметной области, а не объекты из
области решения, которые рассматриваются на этапе проектирования.
Описанная в предыдущей главе статическая модель применялась для опреде
ления внешних классов, изображаемых на диаграмме классов контекста системы.
Внешние классы помогают выявить программные классы, описывающие интер
фейс с внешней средой. Во время статического моделирования были также опре
делены сущностные классы и отношения между ними. В этой главе мы выявим
и дадим классификацию объектам и классам, необходимым в программной систе
ме. В частности, речь пойдет о тех дополнительных объектах и классах, которые
не видны на этапе построения статической модели предметной области.
Совокупность статических отношений между классами рассматривае тся в ста
тической модели, описанной в предыдущей главе, а совокупность динамических
отношений между объектами - в динамической модели, о которой рассказывает
ся в двух последующих главах.
9.1. Критерии разбиения на объекты

Способов разложить систему на объекты несколько, декомпозиция зависит от
пристрастий аналитика и особенностей задачи. Природа задачи определяет и то,
будут ли объекты относиться к одному или к разным классам. Например, с точки
зрения автомобильного каталога легковые машины, фургоны и грузовики можно
считать объектами одного и того же класса. Но для производителя это, скорее все
го, будут объекты разных классов.
Критерии разбиения на объекты помогают проектировщику выделить объек
ты системы. Чтобы их идентифицировать, предлагается найти реальные объекты
Категории классов приложения ШШЯ Ш 169
в предметной области и спроектировать моделирующие их объекты программы.
После того как объекты идентифицированы, в динамической модели изображают
ся взаимодействия между ними, для чего используются диаграммы кооперации
или диаграммы последовательности (см. главу И ). В ходе построения динамичес
кой модели определяются также сообщения, которыми обмениваются объекты.
Есть несколько объектных и объектно-ориентированных методов анализа,
предлагающих критерии выявления объектов в предметной области; они описа
ны в работах [Booch 1994; Coad and Yourdon 1991; Gomaa 1993; Jacobson 1992;
Parnas, Clements, and Weiss 1984; Shlaer and Mellor 1988]. Критерии, представлен
ные в этой главе, основаны на этих методах.
9.2. Категории классов приложения

Под категорией понимается специфически определенный раздел в системе
классификации. В применении к структурированию объектов мы указываем их
категории, чтобы сгруппировать объекты со сходными характеристиками. Хотя
классификация, основанная на наследовании, и является смыслом объектно-ори
ентированного моделирования, она имеет, по сути дела, тактический характер.
Так, мы полагаем, что разделение счетов на чековые и сберегательные - это хоро
шо, поскольку у тех и других есть рад общих и несколько специфических атрибу
тов. Категоризация, однако, - это стратегическая классификация, то есть решение
организовать классы в определенные группы принимается потому, что в большин
стве программных систем такие классы есть, а следование образцу поможет луч
ше понять разрабатываемую систему. Конечно, в разных системах преобладают
классы той или другой категории. Например, в информационно насыщенных сис
темах явно больше сущностных классов, поэтому для таких систем так важно ста
тическое моделирование. С другой стороны, в системах реального времени мно
го классов, описывающих интерфейсы с различными устройствами (датчиками
и приводами). Встречаются в них и сложные зависящ ие от состояния управ
ляющие классы, поскольку в самой природе этих систем заложена зависимость
от состояния.
На рис. 9.1 показаны категории классов приложения. Чтобы различать виды
классов, применяются стереотипы. Стереотип - это подкласс существующего
элемента модели (в данном случае класса приложения), который употребляется
для обозначения способа использования (в данном случае вида класса). Описа
ние стереотипа заключается в кавычки, например стереотип «интерфейс».
Каждый прямоугольник на рис. 9.1 представляет отдельную категорию клас
сов приложения, между которыми существуют отношения наследования. Так,
имеются классы вида «сущность», «интерфейс», «управляющий» и «прикладная
логика». Последние три стереотипа классифицируются более детально, как пока
зано на рис. 9.1 и объяснено ниже. Экземпляр стереотипного класса - это стерео
типный объект, который также можно изображать в кавычках, например объект
стереотипа «сущность».
Рис. 9.1. Характеристика классов приложения с помощью стереотипов
9.3. Структурирование категорий объектов

Объекты классифицируются по роли, которую они играют в приложении.
Четыре основные категории объектов показаны на рис. 9.1. В большинстве при
ложений имеются объекты из каждой категории. Ниже представлены критерии
отнесения объекта к той или иной категории:
□ интерфейсный, или граничный, объект. Объект, реализующий интерфейс
с внешней средой. Интерфейсные объекты можно далее подразделить на:
- объект интерфейса с устройством. Предоставляет интерфейсы с аппарат
ными устройствами ввода/вывода;
- объект интерфейса с пользователем. Реализует человеко-машинный ин
терфейс;
- объект интерфейса с системой. Осуществляет интерфейс с внешней сис
темой или подсистемой;
□ сущностный объект. Долгоживущий объект, в котором хранится информа
ция. Такие классы обычно моделируются как сущности в модели сущность-
связь;
□ управляющий объект. Координирует работу других объектов, участвующих
в прецеденте. Управляющие объекты подразделяются на объекты-координа-
торы, управляющие объекты, зависящие от состояния и объекты-таймеры.
Внешние и интерфейсные классы
Поскольку управляющие объекты осуществляют взаимодействие несколь
ких объектов, их обычно рассматривают только при разработке динамичес
кой модели, а не в ходе создания первой версии концептуальной статичес
кой модели;
□ объекты прикладной логики. Содержат детали логики приложения. Необхо
димы, когда нужно отделить логику обработки от обрабатываемых данных,
поскольку есть вероятность, что они будут изменяться независимо друг от
друга. В информационных системах объектами прикладной логики обычно
являются объекты бизнес-логики, тогда как в приложениях реального вре
мени, научных и инженерных приложениях это, как правило, объекты-ал-
горитмы. Объекты прикладной логики, как и управляющие, обычно рас
сматриваются во время создания динамической, а не статической модели.
В большинстве случаев сразу ясно, к какой категории относится объект. Но
иногда объект удовлетворяет нескольким из вышеперечисленных критериев. На
пример, он одновременно может быть сущностным, то есть инкапсулирующим
данные, и алгоритмом. В такой ситуации объект относят к той категории, которая
представляется наиболее подходящей. Заметим, что важнее выявить все объекты
в системе, чем ломать голову над пограничными случаями.
9.4. Внешние и интерфейсные классы

Внешние классы являются внешними по отношению к системе и взаимодей
ствуют с ней. Интерфейсные классы находятся внутри системы и реализуют ин
терфейс с внешними классами. Чтобы выявить интерфейсные классы, полезно
рассмотреть те внешние классы, с которыми они взаимодействуют.
9.4.1. Категории внешних классов

Внешние классы можно охарактеризовать с помощью стереотипов. Из рис. 9.2
видно, что внешний класс может относиться к категориям «внешний пользова
тель», «внешнее устройство» или «внешний таймер». Внешний пользователь вза
имодействует с системой посредством стандартных устройств ввода/вывода, на
пример клавиатуры, дисплея и мыши, которыми обычно управляет операционная
система. Внешнее устройство - это такое устройство, о котором операционная
система не знает и для которого, следовательно, нужен объект интерфейса устрой
ства. Особенно часто внешние устройства встречаются в системах реального вре
мени; их можно классифицировать следующим образом:
□ внешнее устройство ввода. Устройство, поддерживающее только ввод дан
ных в систему, например датчик;
□ внешнее устройство вывода. Устройство, которое способно только получать
данные от системы, допустим привод;
□ внешнее устройство ввода/вывода. Устройство, которое может как вводить
данные в систему, так и получать из нее информацию, в частности устрой
ство считывания карточек в банкомате.
Рис. 9.2. Описание внешних классов с помощью стереотипов
В главе 8 обсуждается, как разрабатывать диаграммы классов контекста сис

темы, на которых можно представить интерфейсы между внешними классами
и системой.
9.4.2. Идентификация интерфейсных классов

Идентификация внешних классов, взаимодействующих с системой, помогает
выявить некоторые из классов внутри системы, а именно интерфейсные классы.
Каждый внешний класс взаимодействует с некоторым интерфейсным классом.
Между внешними и соответствующими им интерфейсными классами существует
взаимно-однозначное соответствие (при условии, что внешние классы правильно
идентифицированы). Внешние классы взаимодействуют с интерфейсными следу
ющим образом:
□ класс внешней системы взаимодействует с классом интерфейса системы.
В этом случае класс внешней системы эквивалентен актеру - внешней сис
теме;
□ класс внешнего устройства взаимодействует с классом интерфейса устрой
ства. Эта классификация может быть продолжена:
- класс внешнего устройства ввода взаимодействует с классом интерфейса
устройства ввода;
- класс внешнего устройства вывода взаимодействует с классом интерфей
са устройства вывода;
- класс внешнего устройства ввода/вывода взаимодействует с классом ин
терфейса устройства ввода/вывода;
□ класс внешнего пользователя взаимодействует с классом интерфейса пользо
вателя;
□ класс внешнего таймера взаимодействует с внутренним классом таймера.
Класс внешнего устройства описывает тин устройства ввода/вывода. Объект
внешнего устройства ввода/вывода соответствует конкретному устройству, то
есть экземпляру типа устройства. В следующем разделе мы рассмотрим внутрен
ние интерфейсные объекты, которые взаимодействуют с внешними объектами.
Интерфейсные объекты }
9.5. Интерфейсные объекты

В этом разделе описываются характеристики трех разных видов интерфейс
ных объектов: интерфейса устройства, интерфейса пользователя и интерфейса
системы.
9.5.1. Объекты интерфейса устройства

Объект интерфейса устройства представляет собой программный интерфейс
с аппаратным устройством ввода/вывода. Для нестандартных устройств требуют
ся объекты интерфейса устройства, относящиеся к уровню приложения. Чаще они
встречаются в системах реального времени, хотя бывают необходимыми и в других
системах.
Физический объект, иногда называемый конкретным, - это объект предмет
ной области, имеющий аналог в реальном мире и обладающий некоторыми физи
ческими характеристиками; к примеру, его можно увидегь или потрогать. Для
[.аждого объекта реального мира, включенного в приложение, в системе должен
существовать соответствующий программный объект. Допустим, в системе управ
ления лифтами моторы, двери, кнопки и лампочки - это реальные физические
объекты, входящие в состав системы. С другой стороны, шахта и кабина лифта,
хотя и являются физическими объектами, прямого отношения к системе управ
ления не имеют.
Реальные физические объекты обычно взаимодействуют с системой при по
мощи датчиков и приводов. Такие объекты либо ПСрСДыЮТ информацию в систему
посредством датчиков, либо получают от нее управляющие воздействия на при
воды. С точки зрения программной системы объекты реального мира - это, по
сути дела, устройства ввода/вывода, поставляющие в систему входную информа
цию и получающие от нее выходную. Поскольку объекты реального мира соот
ветствуют устройствам ввода/вывода, то осуществляющие интерфейс с ними
программные объекты называются объектами интерфейса устройств [Parnas,
Clements, and Weiss 1984].
Например, в системе управления лифтами кнопка этажа и индикатор прибы
тия на этаж - это объекты реального мира, обладающие датчиками (устройства вво
да), которые передают данные в систему. Мотор и дверь - объекты, управляемые
приводами (устройства вывода), которые получают информацию из системы.
Н а рис. 9.3 приведен пример объекта интерфейса устройства ввода на диа
грамме кооперации. Объект интерфейса устройства ввода - Интерфейс Датчи
ка Температуры - получает информацию о температуре от объекта, представля
ющего физическое устройство ввода, - Датчика Температуры. Здесь также
показана граница между программным и аппаратным обеспечением и стереотипы
для аппаратного объекта «внешнее устройство ввода» и программного объекта
«интерфейс устройства ввода». Таким образом, объект интерфейса устройства
описывает программный интерфейс с внешним аппаратным устройством.
Подчеркнем, что на рисунке представлена логическая модель задачи, в кото
рой входные данные посылаются аппаратным устройством ввода программному
Разбиение на классы и объекты
Входные данные Данные
температуры температуры
«внешнее устройство
«интерфейс устройства
ввода»
ввода»
физический
датчикТемпературы
ДатчикТемпературы
Аппаратный Программный объект

объект в реальном мире
Граница между программой и аппаратурой
Примечание. Пуню ирную линию, обозначающую границу между программой и аппаратурой,

не следует интерпретировать как часть нотации UML.
Рис. 9.3. Пример объекта интерфейса устройства ввода
объекту интерфейса устройства. Во время проектирования принимается решение,

должно устройство быть активным (само посылать программному объекту вход
ные данные) или пассивным (программный объект должен его опрашивать). Эти
вопросы рассматриваются в главе 14.
На рис. 9.4 представлен объект интерфейса устройства вывода - И нтерфейс
Красной Лампочки, который передаст информацию внешнему объекту реально
го мира - Приводу Красной Лампочки. Программный объект Интерфейс Крас
ной Лампочки получает запросы Включить и Выключить, которые он передает
в виде команды устройству Привод Красной Лампочки. На рисунке показана
также граница между программным и аппаратным обеспечением.
Выключить «интерфейс устройства Зажечь «внешнее устройство

£
вывода» вывода»
:ИнтерфейсКрасной :ПриводКрасной
Лампочки Лампочки
Программный объект Аппаратный

объект в реальном мире
Примечание, Пунктирную линию, обозначающую границу между программой и аппаратурой,

Рис. 9.4. Пример объекта интерфейса устройства вывода

Интерфейсные объекты 'I 175
Аппаратное устройство может реализовывать одновременно функции ввода
и вывода. Ему соответствует программный объект интерфейса устройства ввода/
вывода. Именно так обстоит дело в случае объекта Интерфейс Устройства Чте
ния Карточек в банкомате; он получает данные от внешнего Устройства Счи
тывания Карточек, а также команды Вернуть и Конфисковать от системы,
которые передает устройству (рис. 9.5).
Данные от устройства
считывания,
I
1 Карточка вставлена,
Входные данные Карточка возвращена,
от устройства Карточка конфискована
«внешнее устройство «интерфейс устройства
ввода/вывода»
— -— » ввода/вывода»
— -— »
:УстройствоСчитывания :ИнтерфейсУстройства
Карточек Выходные данные СчитыванизКарточек Вернуть,
для устройства Конфисковать
Аппаратный
I Программный объект
I
объект в реальном мире I
I
I
f
Примечание. Пунктирную линию, обозначающую границу между программой и аппаратурой,

нис. 9.5. Пример объекта интерфейса ввода/вывода
Каждый программный объект должен скрывать детали интерфейса со «сво

им» объектом реального мира, моделируя при этом события, которые происходят
с соответствующим реальным объектом. Под событиями в данном случае понима
ется входная информация, поступающая в систему, а конкретно - программному
интерфейсному объекту. Тогда программный объект сможет эмулировать поведе
ние объекта реального мира. Если объект реального мира управляется системой, то
программный объект генерирует событие, определяющее поведение объекта ре
ального мира.
Некоторые приложения включают в себя множество однородных физических
объектов. Для их моделирования необходимо иметь по одному интерфейсному
объекту для каждого физического, причем все такие объекты принадлежат одно
му и тому же классу. Например, в системе управления лифтами есть много одина
ковых кнопок и лампочек. Они моделируются с помощью классов Интерфейс
Лампочки и Интерфейс Кнопки, причем для каждого класса создается несколь
ко объектов.
9.5.2. Объекты интерфейса пользователя

Объект интерфейса пользователя описывает интерфейс с человеком на ос
нове таких стандартных устройств, как клавиатура, дисплей и мышь. Стандарт
ные устройства ввода/вывода обычно управляются операционной системой, так
176 Ц . ! Разбиение на классы и объекты
что в приложение не нужно включать специальные объекты для интерфейса с ни
ми. В зависимости от применяемой технологии интерфейс пользователя бывает
очень простым (в виде командной строки) или очень сложным (графический ин
терфейс пользователя - ГИП). Объект интерфейса пользователя может быть со
ставным и включать несколько более простых объектов. Это значит, что актеры
взаимодействуют с системой при помощи нескольких объектов интерфейса пользо
вателя, последовательно или параллельно. Для таких объектов предусмотрен сте
реотип «интерфейс пользователя».
Примером простого объекта интерфейса пользователя является Интерфейс
Оператора (рис. 9.6), который принимает команды оператора, запрашивает по
казания датчика от сущностного объекта Хранилище Показаний Датчика и отоб
ражает полученные данные на дисплее. Возможны и более сложные объекты ин
терфейса пользователя. Например, объект Интерфейс Оператора способен
включать несколько более простых. В таком случае оператор увидит в одном окне
динамически обновляемое состояние рабочей станции, в другом - состояние тре
вожных датчиков, а в третьем будет вводить команды для системы. Каждое окно
состоит из нескольких элементов управления: меню, кнопок и более простых окон.
Заметим, что в аналитическую модель включается только составной объект, дизайн
внутренних объектов ГИП откладывается до этапа проектирования (см. главу 15).
Команды Запрос
Оператора к датчику
---- «интерфейс «сущность»
пользователя» :ХранилищеПоказаний
:ИнтерфейсОператора Датчика
:Актер Данные,
отображаемые
на дисплее
!
I
I
Граница системы
Примечание. Пунктирную линию, обозначающую границу системы,

Рис, 9.6, Пример объекта интерфейса пользователя
9.5.3. Объекты интерфейса системы

Объект интерфейса системы осуществляет взаимодействие с внешней систе
мой, которая должна общаться с разрабатываемой системой, и скрывает детали
такого взаимодействия.
Пример объекта интерфейса системы - это объект Интерфейс Подъемно-
Транспортного Робота в системе автоматизации производства (рис. 9.7), ко
торый осуществляет интерфейс с Подъемно-Транспортным Роботом. Объект
Интерфейсные объекты 11И1И
Команда
подъемно
Поднять, транспортному
Переместить роботу
«интерфейс системы» — ___ > «внешняя система»
:ИнтерфейсПодъемно- :ВнешнийПодъемно-
ТранспортногоРобота *■ ТранспортныйРобот
Поднят, Ответ
Перемещен подъемно-
Программный объект транспортного Аппаратный объект
робота в реальном мире
Граница системы
Примечание. Пунктирную линию, обозначающую границу системы,

Рис. 9.7. Пример объекта интерфейса системы
Интерфейс Подъемно-Транспортного Робота получает запросы Поднять

и Переместить, которые посылает в виде команд внешнему объекту Подъемно-
Транспортный Робот. Робот реагирует на команды, а объект интерфейса систе
мы транслирует реакцию источнику запросов.
Каждый объект интерфейса системы скрывает детали взаимодействия с кон
кретной внешней системой. Вероятнее всего, для этого будут использоваться со
общения, посылаемые внешней управляемой компьютером системе, а не датчики
и приводы, как в случае с объектами интерфейса устройств. Подобные вопросы
рассматриваются на этапе проектирования.
9.5.4. Изображение внешних и интерфейсных классов

В главе 8 мы говорили о том, как провести границу системы и разработать
диаграмму классов контекста системы, на которой представлены все внешние
классы, взаимодействующие с системой. Полезно уточнить эту диаграмму, пока
зав интерфейсные и внешние классы. Интерфейсные классы расположены внут
ри системы - точнее, на границе между системой и внешней средой. Система
показана в виде пакета, внутри которого изображены интерфейсные классы, яв
ляющиеся частью системы. Каждый внешний класс взаимно-однозначно связан
с каким-либо интерфейсным (см. раздел 9.4.2). Таким образом, начав с внешних
классов, изображенных иа рассматриваемой диаграмме, мы упростим задачу вы
явления интерфейсных классов.
На диаграмме классов контекста банковской системы видно, что каждый внеш
ний класс ассоциирован с каким-то интерфейсным (рис. 9.8). Система изображе
на в виде пакета, который содержит интерфейсные классы для связи с внешними.
В этом приложении есть три класса интерфейса устройств и два класса интерфей
са пользователя. Классы интерфейсов устройств - это Интерфейс Устройства
Чтения Карточек, Интерфейс Устройства Выдачи Наличных и Интерфейс
178 1Ш
&Шit
IflHWHHSWewW&mH i i f c ч
Разбиение на
........ ........
классы и .объекты
....... ..
«система»
БанковскаяСистема
I j «внешний
------- пользователь»
Оператор
ГГ
9:
Оператор
Рис. 9.8. Внешние и интерфейсные классы в банковской системе
Устройства Печати Чеков. Интерфейс Клиента - это класс интерфейса

пользователя, который отображает текстовые сообщения и подсказки, а затем по
лучает от клиента входные данные. Класс Интерфейс Оператора реализует
пользовательский интерфейс оператора банкомата, который пополняет запас на
личных. В каждом банкомате имеется по одному экземпляру названных интер
фейсных классов.
9.6. Сущностные объекты

Сущностным называется долго живущий объект, в котором хранится инфор
мация. Обычно такой объект участвует во многих прецедентах. Информация, со
держащаяся в нем, не пропадает и после завершения прецедента. Сущностные
объекты - это экземпляры сущностных классов, атрибуты которых и отношения
с другими классами определяются на этапе статического моделирования, как рас
сказывалось в главе 8 .
Сущностные объекты хранят данные и предоставляют ограниченный доступ
к ним с помощью своих операций. Иногда сущностному объекту может понадобить
ся доступ к информации, инкапсулированной в других аналогичных объектах.
В системах реального времени такие объекты часто располагаются в опера
тивной памяти. Во многих информационных системах инкапсулированные ими
данные находятся в базе данных. Эти вопросы рассматриваются на этапе проек
тирования в главе 15.
Сущностные объекты < '№^Ш¥Ш
Примьр 3,щностного клас хи 1оанковского приложения - класс Счет (рис. 9.9).
Чтобы подчеркнуть вид класса, мы употребили стереотип «сущность». Экземпля
ры класса Счет - сущностные объекты, которые также снабжены стереотипом
«сущность». Атрибутами класса Счет являю тся номер Счета и баланс. На
рис. 9.9, представляющем собой фрагмент диаграммы кооперации, объект Счет
получает сообщения Открыть, Закрыть, Кредитовать, Дебетовать и Прочи
тать и отвечает на них, предоставляя информацию о Балансе и Состоянии.
Объект Счет - это устойчивый (долго живущий) объект, который участвует в не
скольких прецедентах, в том числе инициированных клиентом (снятие денег, по
лучение справки и перевод денег посредством банкомата) или кассиром (откры
тие и закрытие счета, кредитование и дебетование). Счет также используется
в прецеденте ежемесячной подготовки и печати выписок из счета для клиентов.
Открыть,
Закрыть,
' Баланс,
Кредитовать,
Состояние
«сущность» Дебетовать, ,,
Счет Прочитать
б аланс: Real
Рис. 9.9. Пример сущностного класса и объекта
Примером сущностного класса в приложении, которое занимается монито

рингом датчика реального времени, может служить класс Показания Датчика
(рис. 9.10), где хранится информация об аналоговых датчиках. Его атрибуты -
имя Датчика, значение Датчика, верхний Предел, нижний Предел и состо
яние Тревоги. Экземпляром этого класса может быть объект показания Дат
чика Температуры, который получает сообщения Прочитать и Обновить и от
вечает, возвращая Текущие Показания Датчика. Как показано на рисунке, объект,
нуждающийся в получении последних показаний датчика, посылает сообщение
Прочитать. Объект, который считал показания реального датчика и хочет обно
вить объект показания Датчика Температуры, посылает сообщение Обновить.
v Текущие
ПоказанияДатчика Прочитать,
Показания
Обновить
Датчика
названиеДатчика; String
значениеДатчика: Real
верхнийПредел: Rea! «сущность»
показания
нижнийПредел: Rea!
Датчика
статусОповещения: Boolean
Температуры
Рис. 9.10. Пример сущностного класса и объекта

Разбиение на классы и объекты
9.7. Управляющие объекты

Управляющий объект обеспечивает общую координацию исполнения преце
дента. Для простых прецедентов управляющие объекты не нужны, но для более
сложных могут понадобиться. Управляющий объект похож на дирижера оркес
тра, который распоряжается поведением других объектов, участвующих в преце
денте, говоря каждому из них, что и когда он должен делать. В зависимости от
особенностей прецедента управляющий объект может зависеть от состояния.
Ниже описаны несколько видов управляющих объектов.
9.7.1. Объекты-координаторы
Объект-координатор задает весь порядок работы набора взаимосвязанных
объектов на основе поступающих входных данных, вне зависимости от состояния.
Он устанавливает, когда и в какой последовательности будут действовать другие
объекты, участвующие в прецеденте. Координатор принимает решение только на
основе поступающих входных данных и не завш-iи от состояния. Иными слова
ми, действие, инициированное координатором, определяется исключительно ин
формацией во входном сообщении, а не тем, что происходило с системой раньше.
Пример объекта-координатора - Банковский Координатор, который полу
чает клиентскую транзакцию от банкомата. В зависимости от типа транзакции
Банковский Координатор посылает ее некоторому объекту для исполнения.
В банковской системе такими объектами являются Менеджер Транзакций Сня
тия, Менеджер Транзакций Перевода, Менеджер Транзакций Получения
Справки и Менеджер Транзакций Проверки ПИН-кода (рис. 9.11).
Транзакция Банкомата
Запрос
на Проверку
■координатор» ПИН-кода
б а н к овский
Ответ Ответ Байка «бизнес-логика»
Координатор
Ответ на Запрос :М А н е л ж тТ п а н з а к ц и й
ПроверкиПИН-кода
О те
Транзакция
«бизнес-логика» на Тран;
Получения
:МенеджерТранзакций Полу-
Справки
Перевода Спр;
«бизнес-логика» «бизнес-логика»
:МенеджерТранз акций :МеиеджерТранзакций
Справки Снятия
Рис . 9.11. Пример объекта-координатора и объектов бизнес-логики

Управляющие объект
9.7.2. Управляющие объекты, зависящие от состояния

Поведение управляющего объекта, зависящего от состояния, различно в каж
дом из возможных состояний. Для определения такого объекта применяется ко
нечный автомат, и графически он изображается на диаграмме состояний. Диа
граммы состояний, впервые предложенные Харелом [Harel 1988, 1998], могут
быть плоскими или иерархическими (см. главу 10). В этом разделе мы лишь слег
ка коснемся управляющих объектов, зависящих от состояния, отложив подроб
ное рассмотрение до главы 1 1 .
Управляющий объект, зависящий от состояния, получает входные события,
которые вызывают переходы между состояниями, и генерирует выходные собы
тия, управляющие работой других объектов. Выходное событие зависит не толь
ко от входного, но и от текущего состояния объекта. Примером управляющего
объекта, зависящего от состояния, служит объект Управление Банкоматом
(рис. 9.12), определяемый с помощью диаграммы состояний. Из рисунка видно, что
этот объект управляет двумя объектами интерфейса устройства - Интерфейсом
Устройства Печати Чеков и Интерфейсом Устройства Выдачи Наличных.
^интерфейс устройства
вывода»
Устройств о Печати
Чеков
^интерфейс устройства
вывода»
•.УстройствоВыдачи
Наличных
Рис. 9.12. Пример управляющего объекта, зависящего от состояния
В системах реального времени обычно есть один или несколько управляющих

объектов, зависящих от состояния. Может существовать даже несколько объек
тов одного типа. Каждый объект исполняет экземпляр одного и того же конечно
го автомата (изображаемого в виде диаграммы состояний), хотя в каждый момент
времени эти объекты, скорее всего, оказываются в разных состояниях. В банков
ской системе примерами такого рода являются банкоматы, имеющие собственный
зависящий от состояния управляющий объект Управление Банкоматом, кото
рый исполняет свой экземпляр диаграммы состояний. Другой пример можно най
ти в системе управления лифтами, моделируемой с помощью управляющего
объекта Управление Лифтом посредством диаграммы состояний. Очевидно, что
182 ж ж ш т л \ Разбиение на классы и объекты
у любого лифта есть свой объект Управление Лифтом. Подробнее об управляю
щих объектах, зависящих от состояния, рассказывается в главе 1 1 .
9.7.3. Объекты-таймеры
Объект-таймер - это управляющий объект, активизируемый внешним тай
мером, например тактовым генератором или часами операционной системы.
Объект-таймер либо сам осуществляет некоторое действие, либо активизирует
другой объект, который выполнит нужное действие.
Пример объекта-таймера приведен на рис. 9.13. Объект Таймер Пути активи
зируется событием, которое генерирует внешний таймер Тактовый Генератор.
Объект-таймер посылает сообщение Вычислить объекту Путь, который вычис
ляет общее пройденное автомобилем расстояние.
Событие
Рис. 9.13, Пример объекта-таймера
9.8. Объекты прикладной логики

В этом разделе описываются два вида объектов прикладной логики: объекты
бизнес-логики и объекты-алгоритмы.
9.8.1. Объекты бизнес-логики

Объекты бшнес-лошки определяют логику обработки приложением запросов
клиентов. Их назначение заключается в инкапсуляции бизнес-правил, которые
могут изменяться независимо друг от друга. Обычно во время выполнения объек
ты бизнес-логики обращаются к сущностным объектам.
Объекты бизнес-логики нужны только в некоторых ситуациях. Иногда биз
нес-логику разумно инкапсулировать в отдельный объект, а иногда она настолько
проста, что ее можно реализовать в виде операции сущностного объекта. Общая
рекомендация такова: если для выполнения бизнес-правила приходится обра
щаться к двум или более сущностным объектам, вводите отдельный объект био-
нес-логики; если же для выполнения правила достаточно одного сущностного
объекта, предоставьте это операции самого объекта.
Подсистемы 183
Пример объекта бизнес-логики - Менеджер Транзакций Снятия - приве
ден на рис. 9.11. Он обслуживает запросы клиентов на снятие денег. Например,
первое бизнес-правило может состоять в том, что после снятия на счету клиента
должно остаться не менее 50 долларов. Второе правило гласит, что по дебетовой
карточке клиент не имеет права снимать более 250 долларов в день. Менеджер
Транзакций Снятия обращается к объекту Счет, чтобы удостовериться в выпол
нении условий первого правила. Для проверки второго правила он запрашивает
объект Дебетовая Карточка, который хранит накопительный итог сумм, сня
тых клиентом банкомата в течение дня. Если хотя бы одно правило не выполняет
ся, запрос на снятие денег отклоняется.
Для выполнения бизнес-правил объект бизнес-логики обычно должен взаи
модействовать с сущностными объектами. В этом отношении он напоминает
объект-координатор. Однако, если в обязанности координатора входит управле
ние работой других объектов, объект бизнес-логики отвечает, прежде всего, за
выполнение бизнес-правил.
9.8.2. Объекты-алгоритмы
Объект-алгоритм инкапсулирует алгоритм, применяемый в данной предмет
ной области. Такие объекты чаще всего встречаются в приложениях реального
времени, а также научных и инженерных задачах в тех случаях, когда в предмет
ной области имеется нетривиальный алгоритм, который может изменяться неза
висимо от других ее аспектов. Простые алгоритмы обычно реализуются как опе
рации сущностного объекта, работающие с хранящ имися в нем данными. Во
многих научных и инженерных приложениях алгоритмы уточняются итеративно,
поскольку их совершенствование, например с точки зрения производительности
и точности вычислений, не зависит от данных.
Так, iiсистеме круиз-контроля объект-алгоритм Крейсер вычисляет, как надо
изменить тягу путем сравнения текущей скорости автомобиля с требуемой крей
серской скоростью (рис. 9.14). Алгоритм достаточно сложен, поскольку требуется
плавно разгонять или притормаживать автомобиль, чтобы пассажиры не испыты
вали неудобств.
Объект-алгоритм часто инкапсулирует данные, необходимые для выполнения
алгоритма. Это могут быть начальная информация, промежуточные результаты
и /ш пороговые данные, например максимальные и минимальные значения.
Объект-алгоритм обычно взаимодействует с другими объектами. В этом от
ношении он напоминает объект-координатор. Но в отличие от координатора, ко
торый должен управлять другими объектами, назначение объекта-алгоритма со
стоит, прежде всего, в инкапсуляции и выполнении алгоритма.
9.9. Подсистемы
Система разбивается на подсистемы, которые содержат объекты, функциональ
но зависящие друг от друга. Смысл разбиевия заключается в том, чтобы сильно
связанные между собой объекты поместить в одну подсистему, а слабо связанные
Рис. 9.14. Пример объекта -алгоритма
оставить в разных. Подсистема - это составной или агрегатный объект, содер

жащий простые объекты. Может быть несколько подсистем одного и того же типа.
Для изображения всей системы и разбиения ее на подсистемы мы будем исполь
зовать пакеты.
9.9.1 Пакеты для изображения подсистем

Д ля представления подсистем разрешается задействовать пакеты. Так, в од
ном пакете можно показать всю систему, разбитую на подсистемы, каждая из ко
торых изображается в виде вложенного пакета. В примере на рис. 9.15 банковская
система представляет собой один пакет, состоящий их двух подсистем: Подсис
тема Банкомата и Подсистема Банковского Сервера. Обе подсистемы пока
заны в виде пакетов, вложенных в пакет, который описывает систему в целом.
Допустимо также показать отношения между пакетами, в частности описать
зависимости пакетов друг от друга. На диаграмме пакетов зависимости изобра
жаются пунктирными линиями.
«система»
БанковскаяСистема |
«подсистема» «подсистема»
Подсистема Подсистема
Банкомата БанковскогоСервера
Рис. 9.15. Основные подсистемы в виде пакетов

......Подсистемы....
Так, в примере банковской системы Под<_____ а Банкомата зависит от Под
системы Банковского Сервера, На первый взгляд кажется разумным показать
отношения агрегирования, обобщения/специализации и прочие ассоциации, но
между пакетами в UML разрешены только отношения зависимости и обобщения/
специализации. Поэтому для моделирования иных отношений между подсисте
мами следует пользоваться диаграммами классов, как показано в следующем
примере.
На рис. 9.16 показана декомпозиция банковской системы на подсистемы, кото
рые изображены в виде агрегатных классов. Между Подсистемой Банковского
Сервера и Подсистемой Банкомата существует ассоциация один-ко-многим. Все
внешние классы взаимодействуют только с Подсистемой Банкомата и связаны
с ней ассоциацией один-к-одному.
Рис, 9.16. Банковская система; основные подсистемы и их связи
9.9.2. Вопросы, связанные с разбиением на подсистемы

В некоторых приложениях, например в системах клиент-сервер, подсистемы
выделяются легко. Так, в банковском приложении, показанном на рис. 9.15, есть
подсистема Банкомат, развернутая в каждом банкомате, и центральная Подсис
тема Банковского Сервера. Это пример географического структурирования
подсистем.
В других приложениях разбиение системы на подсистемы может оказаться
не столь очевидным. Поскольку целыо структурирования подсистем является
186 тт-л ' i Разбиение на классы и объекты
группировка в рамках одной подсистемы тесно связанных объектов, объединен
ных общей функциональностью, то приступать к решению такой задачи лучше
с анализа прецедентов, Объекты, участвующие в одном прецеденте, становятся не
плохими кандидатурами на включение в состав подсистемы. Поэтому к структу
рированию подсистем часто переходят после определения взаимодействий объек
тов в каждом прецеденте на этапе динамического моделирования. Подходящее
время для подобного анализа - ранние фазы этапа проектирования (см. главу 1 2 ).
9.10. Резюме
В этой главе было описано, как выявлять в системе программные объекты.
Предлагались критерии разбиения па объекты и классификация объектов с помо
щью стереотипов. Особое внимание уделялось объектам предметной области,
имеющим аналоги в реальном мире, а не объектам области решения, которые вы
являются на этапе проектирования. Критерии разбиения на объекты обычно по
следовательно применяются к каждому прецеденту на этапе создания динамичес
кой модели, как описано в главе 11. Затем определяется порядок взаимодействий.
В главе 12 речь пойдет о критериях разбиения на подсистемы. Вопрос о том, яв
ляется объект активным или пассивным, рассматривается на этапе проектирова
ния; который составляет предмет глав 14-16. Проектирование операций каждого
класса описывается в главе J5.
Глава 10 . К о те ч ты е автоматы
И - ‘^ С Т О Я Н И И
Конечные автоматы используются для моделирования динамических аспектов
системы. Многие системы и, в частности, системы реального времени очень силь
но зависят от состояния. Это означает, что их работа определяется не только по
ступающими на вход данными, но и тем, что происходило с системой раньше.
Д ля описания конечных автоматов применяются диаграммы и таблицы пере
хода состояний. Диаграмма перехода состояний - это представление конечного
автомата в виде графа, вершины которого соответствуют состояниям, а ребра -
переходам между ними. Таблица переходов состояний ~ это табличное представ
ление конечного автомата.
В системах с высокой степенью зависимости от состояния диаграммы или таб
лицы переходов состояний могут оказаться очень полезными для понимания функ
ционирования системы. Такая спецификация конечного автомата зачастую более
точна и понятна, чем словесное описание.
В нотации I) М Г. диаграмму перехода состояхгии называют просто диагрсиммои
состояний (statechart diagram). Эта часть нотации позаимствована из работ Харе-
ла [Harel 1988, 1998j. Традиционную неиерархическую диаграмму состояний мы
будем называть плоской диаграммой, а для обозначения концепции декомпозиции
иерархических состояний употребим термин иерархическая диаграмма состояний.
Чтобы продемонстрировать преимущества иерархических диаграмм, начнем с рас
смотрения простейшей плоской диаграммы состояний и станем совершенствовать
ее, пока не увидим, какие возможности открывают иерархические диаграммы.
Мы также дадим рекомендации по разработке диаграмм состояний, в том чис
ле на основе анализа прецедентов. На протяжении этой главы излагаемые кон
цепции будут сопровождаться примерами конечных автоматов для банковской
системы и для системы круиз-контроля.
10.1. Конечные автоматы

Конечный автомат - это автомат с конечным числом состояний. В любой
момент времени он находится только в одном состоянии. Переход состояний - это
изменение текущего состояния, вызванное внешним событием. В ответ на посту
пившее событие автомат может перейти в новое состояние или остаться в пре
жнем. То, в какое состояние перейдет автомат, зависит как от текущего состояния,
так и от события. Побочным результатом перехода в новое состояние иногда бы
вает выполнение некоторого действия.
188 Конечные автоматы и диаграммы состояний
10.2. События и состояния

Прежде чем приводить примеры диаграмм состояний, расскажем об основных
концепциях события и состояния.
10.2.1. События
Событие (его также называют дискретным сигналом или стимулом) - это не
которое явление, происходящее в определенный момент времени. Событие ато
марно (то есть не прерываемо) и концептуально имеет нулевую продолжитель
ность. Примеры событий: Карточка Вставлена в Банкомат, Введен ПИН-код,
Нажат Тормоз, Лифт Уехал.
События могут зависеть друг от друга. Например, событие Карточка Встав
лена в Банкомат всегда предшествует событию Введен ПИН-код. С другой сто
роны, события бывают и совершенно независимыми. Например, событие Карточ
ка Вставлена в Банкомат в Вене не зависит от события Карточка Вставлена
в Банкомат в Ричмонде.
Событие таймера - это особое событие, описываемое ключевым словом after,
которое говорит, что событие происходит по истечении промежутка времени, за
данного выражением в скобках, например: after (10 с) или after (промежу
ток времени). Н а диаграмме состояний событие таймера вызывает выход из дан
ного состояния. Промежуток времени измеряется от момента входа в состояние
до момента выхода из него, обусловленного событием таймера.
10.2.2. С о сто ян и я
Состояние описывает некоторую конкретную ситуацию, характеризуемую
протяженностью во времени. Наступление события обычно приводит к переходу
конечного автомата из одного состояния в другое. Но событие может и не иметь
никаких последствий, то есть после его наступления автомат останется в прежнем
состоянии. Теоретически переход в новое состояние занимает нулевое время. На
практике время, необходимое для перехода в новое состояние, пренебрежимо мало
по сравнению со временем, проведенным в данном состоянии.
Начальное состояние - это то состояние, в котором оказывается диаграмма
состояний сразу после активизации.
10.3. Конечные автоматы и объекты

Хотя с помощью конечных автоматов можно построить модель всей системы,
в объектно-ориентированном анализе и проектировании конечный автомат ин
капсулируется в некотором объекте. Другими словами, этот объект зависит от
состояния и всегда находится в одном из состояний, определенных конечным ав
томатом. Конечный автомат объекта изображается в виде диаграммы состояний.
В объектно-ориентированной модели зависящие от состояния аспекты системы
описываются одним или несколькими конечными автоматами, каждый из кото
рых инкапсулирован в отдельный объект. Взаимодействие конечных автоматов
Примеры диаграмм состояний [,
происходит опосредованно, путем обмена сооощениями между содержащими их
объектами (см. главу 11 ).
10.4. Примеры диаграмм состояний

Использование плоских диаграмм состояний показано на трех примерах: диа
грамма состояний счета, диаграмма состояний банкомата и диаграмма состояний
системы круиз-контроля.
10,4.1 Пример диаграммы состояний счета

В первом примере показана простая диаграмма из двух состояний: начально
го и конечного (рис. 10.1). Когда открывается счет с положительным балансом,
событие Счет Открыт вызывает переход в начальное состояние Счет Хороший.
Последующие события Вклад и Обычное Снятие Денег не изменяют состояния
при условии, что баланс счета остается положительным. Однако событие Разре
шенное Снятие Денег, приводящее к отрицательному балансу, вызывает пере
ход в состояние Превышены Расходы по Счету. В этом состоянии могут произой
ти другие события Разрешенное Снятие Денег. Последующее событие Долг
Погашен вызывает обратный переход в состояние Счет Хороший. Наконец, при
закрытии счета производится переход в конечное состояние, изображаемое в виде
закрашенного круга внутри незакрашенного («бычий глаз»).
10.4.2. Пример диаграммы состояний банкомата

Рассмотрим показанный на рис. 10.2 пример диаграммы состояний банкомата.
Начальное состояние для нее - Простаивает. При получении события Карточка
Вставлена банкомат переходит в состояние Ожидание ПИН-кода, в котором ждет,
пока клиент введет ПИН-код. При получении события ПИН-код Введен банкомат
переходит в состояние Проверка ПИН-кода, в котором выясняет, совпадает ли
введенный клиентом П И Н -код с тем, что хранится в базе данных банковского сер
вера. Из состояния Проверка ПИН-кода возможно четыре перехода. Если ПИН-
коды совпадают, осуществляется переход по ветке Правильный ПИН-код в состо
яние Ожидание Выбора Клиента. Если ПИН-коды не совпадают, то по ветке
Ш ЯЯНВЬш , Конечные автоматы и диаграммы состояний
Неправильный ПИН-код осуществляется возврат в состояние Ожидание ПИН-
кода, и система предлагает клиенту повторить ввод. Если и после третьей попыт
ки клиент указывает неправильный код, то совершается переход Три Неудачи
в состояние Конфискация. Туда же мы попадаем, если карточка оказалась утерян
ной или украденной. Кроме того, клиент может нажать клавишу отмены, после
чего карточка будет возвращена, а транзакция прервана.
Рис. 10.2. Пример диаграммы состояний банкомата
В состоянии Ожидание Выбора Клиента клиент может выбрать нужную опе

рацию, например снятие денег. Диаграмма состояний получает событие Выбрано
Снятие Денег и переходит в состояние Обработка Запроса на Снятие. Если
снятие разрешено, то диаграмма оказывается в состоянии Выдача Наличных.
После получения события Наличные Выданы банкомат переходит в состояние
Печать, в котором печатается чек, а затем в состояние Возврат. После возврата
карточки, о чем сигнализирует событие Карточка Возвращена, мы попадаем
в состояние Завершение.
Из состояния Завершение производится переход в начальное состояние Про
стаивает после получения события таймера. Событие таймера обозначается
After (Промежуток Времени, где Промежуток Времени - это продолжитель
ность нахождения в состоянии Завершение (от момента входа в это состояние до
момента выхода, вызванного событием таймера).
События и условия
10.4.3. Пример диаграммы состояний системы круиз-контроля
На рис. 10.3 показана упрощенная диаграмма состояний для объекта Круиз-
Контроль. Первоначально диаграмма находится в состоянии Простаивает. Ког
да водитель включает зажигание, совершается событие Двигатель Включен,
и диаграмма переходит в состояние Начало. Когда водитель переводит ручку
круиз-контроля в положение «Разгон», происходит событие Разогнаться, и диа
грамма переходит в состояние Разгон. Если затем водитель отпускает ручку кру
из-контроля, то происходит событие Круиз, и система оказывается в состоянии
Крейсерский Режим. Когда водитель нажимает на педаль тормоза, событие На
жат Тормоз приводит к переходу в состояние Отмена Крейсерского Режима.
Двигатель
Включен
1
Начальное Простаивает
Разогнаться Двигатель
Выключен
/ X Нажат Тормоз
Круиз-Контроль
Разгон
Отключен
ч J Отключить
Возобновить Выход
на Крейсерский
Режим
Возобновление
Режим
Рис. 10.3. Упрощенный пример диаграммы состояний

для системы круиз-контроля
Диаграмма на рис. 10.3 допускает переход из состояния Начало в состояние

Разгон, даже если водитель нажал педаль тормоза. Очевидно, что это нежелатель
но, поскольку нажатие тормоза должно отключать систему круиз-контроля. И з
бежать такой ситуации можно, введя два состояния: Начало без Торможения
и Начало с Торможением, как показано на рис. 10.4. Переход в состояние Раз
гон разрешен только из состояния Начало без торможения. Поэтому диаграм
ма не реагирует на событие Разогнаться, если она находилась в состоянии На
чало с Торможением, но переходит в состояние Разгон, если перед этим была
в состоянии Начало без Торможения. Событие Нажат Тормоз приводит к пере
ходу из состояния Начало без Торможения в состояние Начало с Торможени
ем, а событие Тормоз Отпущен - к обратному переходу.
10.5. События и условия

Хотя описанный выше подход устраняет одну проблему, при этом возникает
другая. Если всегда нужно различать состояния с нажатой и отпущенной педалью
Illll Конечные автоматы и диаграммы состояний
Нажат
Рис. 10.4. Частичная диаграмма состояний
тормоза, общее число состояний удвоится. Существует другой способ: ввести

в рассмотрение не только события, но и условия. Условие, или переменная состоя
ния, определяет некий аспект системы, который способен оставаться истинным
или ложным на протяжении конечного промежутка времени. Таким образом, оно
представляется значением булевской переменной. Например, допустимо опреде
лить условие торможения, принимающее два значение: Нажат Тормоз или Тор
моз Отпущен. Условие молсет представлять состояние какой-то другой части сис
темы, в данном случае педали тормоза.
На рис. 10.5 показано отношение между событиями и условиями. Первона
чально условие принимает значение Торможения Нет. Когда происходит собы
тие Нажат Тормоз, означающее, что водитель поставил ногу на педаль тормоза,
условие изменяется на Торможение Есть. При возникновении события Тормоз
Отпущен условие вновь принимает значение Торможения Нет. Событие занима
ет пренебрежимо малое время, но условие сохраняет значение в течение конечно
го промежутка времени.
Условие Торможение Есть
Условие Торможения Нет Условие Торможения Нет
Время
Событие Событие
Нажат Тормоз Тормоз Отпущен
Примечание. В этой диаграмме нотация UML не используется.
Рис. 10.5. Отношения между событиями и условиями
События и условия разрешается применять совместно для определения пере

хода состояния. Д ля этого используется нотация событие [условие], означающая,
что событие может вызвать переход в новое состояние только тогда, когда усло
вие в скобках истинно.
событий и условий
в диаграмме состояния Рис. 10.7. Пример событий и условий
Бывает так, что возникшее событие не должно приводить к немедленному пе

реходу состояний, однако его присутствие необходимо, поскольку это может по
влиять на будущее изменение состояния. Тогда информацию о том, что событие
имело место, можно сохранить в виде условия, которое будет проверено позже.
На рис. 10.6 показано использование условия торможения. Состояния Нача
ло без Торможения и Начало с Торможением объединяются в одно состояние
Начало. Когда происходит событие Разогнаться, проверяется условие Тормо
жение. Если оно принимает значение Торможения Нет (водитель отпустил пе
даль тормоза), то разрешается переход в состояние Разгон. Если же значение
равно Торможения Нет, то такой переход запрещен, и диаграмма остается в со
стоянии Начало.
Другой пример применения условий приведен на рис. 10.7. Он относится к си
туации, когда банкомат нужно закрыть на обслуживание. Если в данный момент
банкоматом пользуется какой-то клиент, то необходимо дать ему возможность
завершить транзакцию, установив булевское условие Запрошен Останов в исти
ну в момент поступления запроса на обслуживание. Если в момент поступления
события Остановить банкомат простаивал, он сразу же переходит в состояние
Остановлен. Если же он находился в любом другом состоянии, то событие
Остановить не вызывает немедленной реакции, а устанавливает в истину усло
вие Запрошен Останов.
Это условие проверяется, когда начатая клиентом транзакция завершится.
Оно используется совместно с событием таймера after (промежуток време
ни) . Когда возникает это событие, а банкомат находится в состоянии Заверше
ние, проверяется условие Запрошен Останов. Если оно истинно, банкомат пере
ходит в состояние Остановлен. В противном случае банкомат возвращается
в состояние Простаивает и готов к выполнению следующей транзакции.
10.6. Действия
С переходом состояний может быть ассоциировано действие. Действие (action) -
это некоторое вычисление, осуществляемое в результате перехода в новое состоя
ние. Действие инициируется переходом. Оно производится, а затем закапчивается.
Конечные автоматы и диаграммы состояний
Действие выполняется мгновенно в момент перехода, то есть концептуально его

продолжительность равна нулю. На практике время, затрачиваемое на выпол
нение действия, очень мало по сравнению с длительностью пребывания автома
та в некотором состоянии.
На диаграмме состояний действие изображается путем пометки перехода сле
дующим образом: событие [условие] / действие. Например, когда банкомат пе
реходит из состояния Ожидание ПИН-кода в состояние Проверка ПИН-кода
в результате события ПИН-код Введен, выполняется действие Проверить ПИН-
код. Этот переход помечен так: ПИН-код введен / Проверить ПИН-код. Дан
ный пример показан на рис. 1 0 .8 , содержащем частичную диаграмму состояний
банкомата (см. рис. 10.2) с добавленными действиями. С переходом может быть
ассоциировано несколько действий. Эти действия выполняются одновременно,
следовательно, между ними не должно быть никаких зависимостей. Например,
было бы неправильно включать два одновременных действия: Рассчитать Из
менение и Показать Изменение. В таком случае имеется подчиненность од
ного действия другому, поскольку нельзя показать изменение до того, как оно
рассчитано. Д ля решения данной проблемы введите промежуточное состояние
Расчет Изменения. Действие Рассчитать Изменение выполняется при входе
в это состояние, а действие Показать Изменение -- при выходе из него.
Рис, 10.8. Пример действий
В качестве еще одного примера на рис. 10.9 показана первоначальная диаграм

ма состояний для объекта Круиз -Контроль (см. рис. 10.3) с добавленными усло
виями и действиями. Здесь изображена полная диаграмма состояний, в нее при
шлось включить несколько переходов.
10,6,1. Деятельности
Помимо действий в результате перехода состояния могут выполняться деятель
ности. Деятельность (activities) - это некоторое вычисление, выполняемое, пока
Рис. 10.9. Детальная диаграмма состояний системы круиз-контроля
Двигатель Включен /
Сбросить Значение Требуемой Скорости
Двигатель Выключен
Разогнаться [Торможения Н ет],/
Enable «Увеличить Скорость»
Двигатель Выключен / Disable «Увеличить Скорость» Двигатель Выключен /

Disable «Поддерживать
Двигатель Выключен Скорость»
Разогнаться [Торможения Нет] / Нажат Тормоз / Disable

Enable «Увеличить Скорость» «Поддерживать Скорость»
Простаивает
Отключен Выключить / Disable
Нажат Тормоз / Disable «Увеличить Скорость». «Поддерживать Скорость»
Установить Значение Требуемой Скорости
Нажат Тормоз / Disable
«Возобновление Круиз-Контроля»
Возобновить [Торможении Нет] /

Enable «Возобновление Круиз-Контроля» Выключить / Disable >3э
«Возобновление Круиз-Контроля» го
<5<
Разогнаться /
Disable «Возобновление Круиз-Контроля»,
Enable «Увеличить Скорость»
Двигатель Выключен / Disable ж
«Возобновление Круиз-Контроля»
Крейсерский
а
Режим
—/ Выход на Крейсерский Режим /
Disable «Возобновление Круиз-Контроля»,
Enable «Поддерживать Скорость»
Разогнаться / Disable «Поддерживать Скорость», Enable «Увеличить Скорость»
Круиз / Disable «Увеличить Скорость», Установить Значение Требуемой Скорости, Enable «Поддерживать Скорость»
автомат находится в данном состоянии. Поэтому, в отличие от действия, деятель
ность занимает конечное время. Деятельность начинается при входе в состояние
и заканчивается при выходе из него. Причина изменения состояния, приводящего
к прекращению деятельности, обычно состоит в приходе некоторого события из
источника, не связанного с деятельностью. Однако иногда сама деятельность воз
буждает событие, приводящее к изменению состояния.
Один из способов показать деятельность на диаграмме состояний - пометить
переход в состояние, где она протекает: событие / enable деятельность, а также
переход из этого состояния: событие / disable деятельность. Однако, чтобы
сократить запись, можно вместо слов enable и disable ассоциировать деятель
ность с самим состоянием. Д ля этого в прямоугольнике, представляющем состоя
ние, записывают имя состояния и имя деятельности, разделяя их горизонтальной
чертой. Деятельность изображают в виде do / деятельность (здесь do - зарезер
вированное слово). Это означает, что деятельность начинается при входе в состо
яние и завершается при выходе из него.
В качестве примера деятельности опишем переход из состояния Начало в со
стояние Разгон на диаграмме состояний объекта Круиз-Контроль, показанной
на рис. 10.9. Деятельность Увеличить Скорость начинается при входе в состоя
ние Разгон. Она выполняется, пока диаграмма находится в этом состоянии, и за
вершается при выходе из него.
Если при переходе в новое состояние встречается сочетание действий и завер
шенных и начатых деятельностей, то порядок выполнения определяется следую
щими правилами:
1. Прекращается деятельность, начатая в прежнем состоянии.
2. Выполняется действие (или действия).
3. Начинается деятельность в новом состоянии.
Рассмотрим, например, событие Круиз, которое вызывает переход из состоя
ния Разгон в состояние Крейсерский Режим. Сначала прекращается деятель
ность Увеличить Скорость, затем начинается деятельность Поддерживать
Скорость, которая продолжается все время, пока диаграмма находится в состоя
нии Крейсерский Режим. Кроме того, выполняется действие Установить Зна
чение Требуемой Скорости. Семантика этого перехода состояний такова:
1. Деятельность Увеличить Скорость прекращается при выходе из состоя
ния Разгон.
2. Действие Установить Значение Требуемой Скорости выполняется при
переходе из состояния Разгон в состояние Крейсерский Режим.
3. Деятельность Поддерживать Скорость начинается при входе в состояние
Крейсерский Режим.
Более краткая запись тех же деятельностей показана на рис. 10.10. Вместо того
чтобы писать, что деятельность начинается при входе в состояние и завершается при
выходе из него, использована нотация do / деятельность. Это сделано для трех дея
тельностей: Увеличить Скорость, Поддерживать Скорость и Возобновить Кру
из-Контроль. Сравнение рисунков 10.9 и 10.10 показывает, что нотация do / дея
тельность позволяет упростить диаграмму, не загромождая ее лишними словами.
Действия и- Я Н И И 1 Ш
Рис. 10.10. Диаграмма состояний системы круиз-контроля с деятельностями
10.6.2. Действия при входе и выходе

Некоторые действия можно записать более кратко, если ассоциировать их с са
мим состоянием, а не с переходами. Это так называемые действия при входе и при
выходе, для которых зарезервированы слова entry и exit. Мгновенное действие,
выполняемое При входе в состояние, оболы ыется как entry / действие, а мгно
венное действие, выполняемое при выходе из него, - как ex it / действие.
Обычно в действиях при входе и выходе нужды не возникает, вместо этого
помечаются переходы в данное состояние и из него. Лучше всего применять дей
ствие при входе, когда:
□ есть несколько переходов в данное состояние;
□ при каждом переходе нужно выполнить одно и то же действие;
□ действие связано именно с входом в данное состояние, а не с выходом из
предыдущего.
В этой ситуации действие изображается только в прямоугольнике состояния,
а не на каждом ведущем в него переходе.
Действие при выходе удобно в случаях, когда:
□ есть несколько переходов из данного состояния;
□ при каждом переходе требуется одно и то же действие;
а)
1 Недостаточно Наличных /
Вернуть, Индицировать Останов Системы
Остановлен
After {Промежуток Времени) [Запрошен Останов] /
Индицировать Останов Системы
Запуск/ Отобразить Остановить/ Индицировать
Приветствие Останов Системы
After {Промежуток Времени)
[Останов Не Запрошен] /
Отобразить Приветствие Завершение
Транзакции
Рис. 10.11. Пример действий при входе:

а - на переходах; б - внутри состояния
Действия | 199
□ действие связано именно с выходом из данного состояния, а не с входом
в следующее.
В такой ситуации действие изображается только в прямоугольнике состояния,
а не на каждом исходящем из него переходе.
Пример действия при входе приведен на рис. 10.11. Н а рис. 10.11а действия
изображены на переходах. Видно, что действие Индицировать Останов Систе
мы связано со всеми тремя переходами в состояние Останов, а действие Отобра
зить Приветствие - с двумя переходами в состояние Простаивает. Альтерна
тивный подход к изображению действий продемонстрирован на рис. 10.116: при
входе в состояние Останов выполняется мгновенное действие Индицировать
Останов Системы, а при входе в состояние Простаивает - мгновенное действие
Отобразить Приветствие. Отметим, что действие Вернуть по-прежнему пока
зано на переходе из состояния Завершение Транзакции в состояние Останов,
поскольку оно выполняется только на этом переходе.
В качестве примера действия при выходе рассмотрим действие Установить
Значение Требуешой Скорости, показанное на рис. 10.12а. Оно должно
Требуемой Скорости
Рис. 10.12. Пример действия при выходе:

а - на переходах; б - внутри состояния
осуществляется после увеличения скорости в состоянии Разгон в ходе выпол

нения деятельности Увеличить Скорость, поэтому изображено на обоих пере
ходах из состояния Разгон. Можно записать и короче - в виде действия при вы
ходе из состояния Разгон, как показано на рис. 10.126. Деятельность Увеличить
Скорость выполняется в течение всего времени пребывания в состоянии Раз
гон. При выходе из этого состояния сначала прекращается деятельность в нем,
а затем выполняется действие при выходе.
Деятельность, выполняемая, пока автомат находится в данном состоянии, мо
жет сама возбуждать событие, вызывающее переход в новое состояние. Например,
деятельность Возобновить Круиз-Контроль, которая осуществляется в состо
янии Возобновление (см. рис. 10.10), возбуждает событие Выход на Крейсер
ский Режим, которое переводит диаграмму в состояние Крейсерский Режим.
Выход из состояния Возобновление может быть обусловлен и другим событи
ем, в частности Нажат Тормоз, полученным из внешней среды.
10.7. Моделирование различных аспектов системы

Другой способ упростить моделирование сложных систем состоит в том, что
бы построить отдельные диаграммы состояний для разных аспектов системы.
Например, диаграмма «Круиз-контроль» на рис. 10.10 моделирует аспекты, свя
занные с круиз-контролем. Для моделирования аспектов, касающихся торможе
ния, допустимо нарисовать другую диаграмму (рис. 10.13), у которой будут два
возможных состояния: Торможение Есть и Торможения Нет. Вначале она нахо
дится в состоянии Торможения Нет. Событие На
жат Тормоз вызывает переход в состояние Тормо
жение Есть. Событие Тормоз Отпущен приводит
к возврату в состояние Торможения Нет.
В зависимости от особенностей задачи диаграм
мы «Торможение» и «Круиз-контроль» могут быть
как связанными между собой, так и совершенно не
зависимыми. Диаграммы состояний будут связаны,
если, например, выходное событие одной диаграм
мы соответствует входному событию другой. В та
ком случае выходное событие оказывается причи
Рис. 10.13. Пример ной, а входное - следствием. Применение отдельных
диаграммы состояний диаграмм состояний для моделирования различных
« Торможение»
объектов системы означает, что любое взаимодей
ствие между диаграммами требует аналогичного
взаимодействия между описываемыми с их помощью объектами. Эта сторона ди
намического моделирования представлена в главе 1 1 .
Другой подход, позволяющий справиться со сложностью модели, предлагает
нотация иерархических диаграмм состояний, которая будет рассмотрена ниже.
Особенно интересна предоставляемая ею возможность моделирования параллель
ных диаграмм состояний.
Иерархические диаграммы состояний д зм н п и ш о
10.8. Иерархические диаграммы состояний
Одним из недостатков плоских диаграмм состояний является чрезмерно
большое число состояний и переходов, в результате диаграммы становятся гро
моздкими и их трудно читать. Применение условий, действий при входе и вы
ходе и деятельностей позволяет сделать диаграмму менее громоздкой, но этого
часто недостаточно. Принципиально иной способ упростить диаграммы и одно
временно повысить степень их выразительности связан с введением в рассмот
рение надсостояний и иерархической декомпозиции диаграмм. При таком под
ходе надсостояние на некотором уровне диаграммы раскладывается на несколько
подсостояний, принадлежащих более низким уровням.
Цель иерархических диаграмм состоит в том, чтобы воспользоваться основ
ными идеями и визуальными преимуществами, которые дают плоские диаграм
мы, но в то же время избавиться от присущих им недостатков. Основные особен
ности иерархических диаграмм описываются далее и иллюстрируются примерами
из систем управления банкоматом и круиз-контроля.
Следует отметить, что любой иерархической диаграмме можно поставить в со
ответствие плоскую, поэтому семантически те и другие эквивалентны.
10.8.1. Иерархическая декомпозиция состояний

Существенного упрощения диаграмм состояний можно достичь за счет исполь
зования иерархической декомпозиции состояний, когда надсостояние раскладыва
ется на одно или несколько взаимосвязанных подсостояний. Иногда такую опера
цию называют декомпозицией ИЛИ, так как пребывание в некотором надсостоянии
означает, что диаграмма находится в одном и только одном из его подсостояний.
Нотация позволяет показать надсостояние и подсостояния на одной или несколь
ких диаграммах в зависимости от уровня сложности.
Пример иерархической декомпозиции состояния приведен на рис. 10.14. Здесь
надсостояние Обработка Ввода Клиента состоит из подсостояний Ожидание
ПИН-кода, Проверка ПИН-кода и Ожидание Выбора Клиента. (В иерархичес
кой диаграмме надсостояние изображается в виде внешнего прямоугольника
с закругленными углами, в левом верхнем углу которого записывается имя над-
состояния. Подсостояния изображаются внутренними прямоугольниками с за
кругленными углами.) Когда система оказывается в надсостоянии Обработка
Ввода Клиента, она находится в одном и только одном из подсостояний Ожида
ние ПИН-кода, Проверка ПИН-кода или Ожидание Выбора Клиента. Отсюда
и термин «декомпозиция ИЛИ».
Отметим, что каждый переход в надсостояние Обработка Ввода Клиента -
это переход в одно и только одно подсостояние диаграммы нижнего уровня. Лю
бой выход из надсостояния - это выход из какого-то его подсостояния. Так, вход
ное событие Карточка Вставлена вызывает переход в подсостояние Ожидание
ПИН-кода, внутреннего для надсостояния Обработка Ввода Клиента.
Ш*ь
Рис. 10.14. Пример иерархической диаграммы
1 Недостаточно Наличных
Остановлен
After (Промежуток Времени)
[Запрошен Останов]
Запуск Остановлен
Карточка After (Промежуток Времени)

Вставлена [Останов не Запрошен]
Обработка
Ввода Клиента
Карточка
Ожидание Конфискована
ПИН-кода Завершение
ПИН-код Неправильный Отмена Карточка

ПИН-код Возвращена
Проверка Три Неудачи, Украдена

ПИН-кода Конфискация Возврат
Правильный Обработка
транзакций Отвергнут Чек
ПИН-код Напечатан
Выбран
Перевод
Ожидание Перевод ^ Обработка З а п р о с а ] Выполнен Успешно
Выбора Клиента на Перевод у Печать
состояний
Справка
Обработка Запроса Наличные
Получена Успешно
Выбрано Получение Справки на Получение Справки Выданы
Снятие Разрешено Выдача

^О б р а б о тка Запроса Наличных
Выбрано Снятие \ на Снятие
Параллельные диаграммы состояний
10.8.2. Агрегирование переходов состояний

Нотация иерархических диаграмм состояний позволяет также агрегировать
переходы из всех подсостояний в переход из надсостояния. Разумное применение
этой возможности способствует значительному уменьшению числа переходов
в диаграмме.
Рассмотрим пример ситуации, когда агрегирование переходов оказывается
полезным. На плоской диаграмме (см. рис. 10.2) клиент может нажать кнопку от
мены в любом из состояний Ожидание ПИН-кода, Проверка ПИН-кода и Ожи
дание Выбора Клиента. В любом случае событие Отмена приводит к переходу
банкомата в состояние Возврат. На диаграмме показано, что от каждого из ука
занных состояний исходят ребра, помеченные словом Отмена, которые ведут в со
стояние Возврат.
То же самое допустимо выразить короче с помощью иерархической диаграм
мы состояний. Входное событие Отмена вызывает переход в состояние Возврат
из каждого из трех подсостояний, входящих в надсостояние Обработка Ввода
Клиента. Поскольку событие Отмена вероятно в любом из подсостояний состо
яния Обработка Ввода Клиента, то соответствующие переходы могут покидать
каждое из них. Однако проще показать один переход Отмена, исходящий из над
состояния Обработка Ввода Клиента (см. рис. 10.14). Переходы же из подсо
стояний не показаны вовсе. Подобные переходы по одному и тому же событию из
разных состояний в одно обычно приводят к появлению множества ребер на плос
ких диаграммах.
ГГГ\\ГТ/"\'М Т ГгПТ.Т£1 Ф г ч т д L J ,'-44 т тт —> т ГТ/Г Г - Г \ ГГТ I T l f i ТТ V4
w Vi U ii V- j C vJ w iji i П ^_уXдИГ<"\
и .МГ ТТ/Л Т / - » п Т_ Ту'/Л Г>
~iyi w i OJlEHYw и lu li U>i iJ . i 4 . r t j.i.jw’C'
верка ПИН-кода, поэтому для него показан переход, идущий именно из этого
состояния, а не его надсостояния.
10.9. Параллельные диаграммы состояний

Поддерживается также еще один вид иерархических диаграмм состояний -
декомпозиция И, позволяющая разложить одно состояние на два или более па
раллельных подсостояний. Два параллельных подсостояиия отделяются друг от
друга пунктирной линией. Рассмотрим случай надсостояния на диаграмме, раз
ложенной на две параллельные диаграммы более низкого уровня. Когда диаграм
ма верхнего уровня находится в надсостоянии, она одновременно находится
в некотором подсостоянии первой диаграммы нижнего уровня и в некотором
подсостоянии второй диаграммы нижнего уровня.
Название «параллельные диаграммы» наводит на мысль о том, что в объекте,
описываемом диаграммой состояний, протекает некая параллельная деятельность,
но это необязательно: декомпозиция И удобна для показа различных аспектов од
ного объекта, которые могут и не быть параллельными. Для обозначения парал
лельной диаграммы, на которой изображены состояния, относящиеся к различным
204 IM F ..... Конечные автоматы и диаграммы состояний
сторонам функционирования объекта, применяется термин ортогональная диа
грамма состояний. В методе COM ET термин параллельная диаграмма состояний
зарезервирован для случаев, когда в объекте действительно имеет место какая-то
форма параллелизма. Проектирование объектов с одним потоком управления
проще, для отражения параллелизма следует использовать несколько параллель
но исполняемых объектов. Поэтому нотация параллельных диаграмм рекоменду
ется для изображения ортогональных диаграмм, показывающих различные аспек
ты объекта, но не параллелизм внутри него. Если же необходимо отразить именно
параллелизм, удобнее взять два отдельных объекта и для каждого определить соб
ственную диаграмму состояний.
Ортогональными диаграммами состояний можно воспользоваться в примере
банкомата для изображения условий. Это показано на рис. 10.15, где диаграмма
Управление Банкоматом разложена на две ортогональные диаграммы: Обра
ботка и Условие Запроса на Останов. Обе диаграммы изображены внутри
диаграммы верхнего уровня и разделены пунктирной линией.
Рис . 10.15. Пример ортогональных диаграмм состояний

для описания банкомата
Отметим, что в любой момент времени надсостояние Управление Банкома

том находится ровно в одном из подсостояний диаграммы Обработка и в одном
из подсостояний диаграммы Условие Запроса на Останов. Условие Запроса
на Останов - это простая диаграмма всего с двумя состояниями, показывающи
ми, имел место запрос на останов банкомата или нет. При этом начальным в ней
является состояние Останов Не Запрошен. Событие Останов вызывает пере
ход в состояние Останов Запрошен, а событие Запуск - переход в состояние
Останов Не Запрошен. Н а диаграмме Обработка (см. рис. 10.14) изображены
Разработка диаграмм состояний / к Ц И Н Н Н Б З Э
состояния, через которые проходит банкомат, выполняя обработку запроса кли
ента. Диаграмма Управление Банкоматом объединяет диаграммы О б раб отка
и Условие Запроса на Останов. Отсюда термин «декомпозиция И».
Состояния Останов Запрошен и Останов Не Запрошен —это условия, прове
ряемые в диаграмме Обработка при получении события after (промежуток
времени) в состоянии Завершение (см. рис. 10.14). Отметим, что состояние Ос
тановлен - это на самом деле состояние, принадлежащее диаграмме Обработка.
10.10. Рекомендации по разработке

диаграмм состояний
Следующие рекомендации относятся и к плоским, и к иерархическим диа
граммам, если не оговорено противное:
□ имя состояния должно отражать такую ситуацию или такой промежуток
времени, когда в системе что-то происходит. Поэтому имя часто бывает су
ществительным или прилагательным (например, Начало или Начальное)
либо глаголом в третьем лице (Лифт Движется). Не следует употреблять
для именования состояний глаголы в неопределенной форме (например,
Двигать Лифт);
□ в пределах одной диаграммы имена всех состояний должны различаться.
Наличие двух состояний с одним и тем же именем приводит к неоднознач
ности. Теоретически подсостояния разных надсостояний могут иметь оди
наковые имена, но на практике это влечет за собой недоразумения, которых
лучше избегать;
□ из каждого состояния должен быть выход. Очень часто встречаются диа
граммы, в которых нет конечного состояния;
□ плоская диаграмма в любой момент времени находится только в одном со
стоянии. Два состояния, например Лифт Движется и Лифт на Этаже, не
могут быть активными одновременно. Одно состояние должно следовать за
другим;
□ для иерархических диаграмм применимы следующие правила:
- если речь идет о последовательной иерархической диаграмме (декомпо
зиция И Л И ), то пребывание в некотором надсостоянии означает пребы
вание в одном и только одном из его подсостояний;
- если используется параллельная иерархическая диаграмма (декомпози
ция И), то пребывание в некотором надсостоянии означает пребывание
в одном из подсостояний каждой диаграммы нижнего уровня;
□ не следует путать события и действия. Событие - это причина перехода со
стояний, а действие - его следствие;
□ событие происходит в некоторый момент времени. И мя события должно по
яснять, что именно произошло, например: Вызов Вверх, Дверь Закрылась;
□ действие - это команда, допустим: Остановить, Закрыть Дверь, Поддер
живать Скорость;
206 Ж Ш Ш Ш & ,. Конечные автоматы и диаграммы состояний
□ действие выполняется мгновенно. Деятельность продолжается все время,
пока диаграмма находится в данном состоянии;
□ с одним переходом состояний может быть ассоциировано несколько дей
ствий. Концептуально все эти действия выполняются одновременно, поэто
му нельзя говорить о порядке их выполнения. Следовательно, между действи
ями не может быть никаких зависимостей. Если же зависимость существует,
то необходимо ввести промежуточное состояние;
□ условие - это булевское значение. Если переход помечен конструкцией со
бытие [условие], то он происходит только тогда, когда в момент возникно
вения события условие истинно. Условие остается истинным на протяже
нии конечного промежутка времени. Переход Разогнаться [Торможения
Нет] предназначен специально для того, чтобы предотвратить смену состо
яния в случае, если в момент возникновения события Разогнаться нажа
та педаль тормоза;
□ действия, деятельности и условия необязательны. Используйте их только
при необходимости.
10,11. Построение диаграмм состояний

на основе прецедентов
Чтобы построить диаграмму состояний на основе прецедента, начните с наи
более типичного сценария, описываемого прецедентом, то есть с важнейшего пути.
В идеале это должен быть такой путь, который соответствует самой распространен
ной последовательности взаимодействий между актером (или актерами) и сис
темой. Затем рассмотрите, какие внешние события возникают в данном сценарии.
В каждом случае входное событие вызывает переход в новое состояние, которому
присваивается имя, отражающее то, что происходит в данном состоянии. Если
с переходом ассоциировано действие, оно выполняется при переходе из прежнего
состояния в новое. Если в этом состоянии должна выполняться некоторая дея
тельность, она начинается при входе в состояние и завершается при выходе из
него. Действия и деятельности определяются путем анализа той реакции системы
на входное событие, которая описана в прецеденте.
Сначала строится плоская модель, которая отражает последовательность со
бытий, описанную в сценарии. Все состояния, изображаемые на диаграмме, долж
ны быть видимы извне, следовательно, актер должен знать о каждом состоянии.
По сути дела, состояние - это не что иное, как представление порядка действий,
предпринимаемых актером прямо или косвенно. Мы проиллюстрируем сказан
ное примером в следующем разделе.
Чтобы закончить построение диаграммы, нужно рассмотреть все возможные
внешние события, которые могли бы стать для нее входными. Обратите внимание
иа описания альтернативных путей в прецеденте. Альтернативы задают реакцию
системы на нестандартные действия актера. Определите, как влияет поступление
каждого из этих событий на состояния, включенные в уже готовую диаграмму;
часто некоторое событие просто не может произойти в определенном состоянии
Пример разработки диаграммы состояний 1, 207
или не имеет в нем никаких последствий. Но иногда поступление события вызы
вает переход в одно из существующих или же в новое состояние, в последнем слу
чае его придется добавить в диаграмму. Необходимо также проанализировать дей
ствия, связанные с каждым переходом, взяв за основу описание реакции системы
на альтернативное событие, изложенное в прецеденте.
10.12. Пример разработки диаграммы состояний

на основе прецедента
Чтобы показать, как строится диаграмма состояний на основе прецедента, рас
смотрим прецедент Управление Скоростью, который описывает последователь
ность взаимодействий между актером (водителем) и системой. Затем мы присту
пим к синтезу диаграммы состояний на его основе.
10.12.1, Прецедент «Управление Скоростью»

Актер. Водитель.
Сводка. Прецедент описывает поведение автоматической системы круиз-кон
троля в автомобиле, получающей входную информацию от следующих внешних
устройств ввода, которыми манипулирует водитель: ручки круиз-контроля, тор
моза, двигателя.
Предусловие. Водитель включил двигатель и управляет машиной в ручном ре
жиме.
Описание.
Этот прецедент представлен в виде типичного сценария, состоящего из после
довательности внешних событий:
1. Водитель перемещает ручку круиз-контроля в положение «Разгон» и удер
живает ее в таком положении. Система автоматически начинает разгонять
автомобиль.
2. Набрав нужную скорость, водитель отпускает ручку круиз-контроля. Сис
тема прекращает разгон, поддерживая достигнутую крейсерскую скорость.
Значение крейсерской скорости запоминается для дальнейшего использо
вания.
3. Водитель нажимает тормоз, чтобы отключить круиз-контроль. Система пе
рестает сохранять заданную скорость, переводя тем самым управление ав
томобилем в ручной режим.
4. Водитель перемещает ручку круиз-контроля в положение «Возобновить»,
возвращая управление системе круиз-контроля. Система начинает разгон
(или торможение) для достижения ранее сохраненной крейсерской ско
рости.
5. Как только крейсерская скорость достигнута, система прекращает разгон
(или торможение) и поддерживает скорость.
6 . Водитель перемещает ручку круиз-контроля в положение «Выкл». Система
отключает круиз-контроль, так что автомобиль вновь управляется вручную.
7. Водитель останавливает машину и выключает двигатель.
Альтернативы.
Актер-водитель взаимодействует с системой, пользуясь тремя внешними
устройствами ввода: ручкой круиз-контроля, тормозами и двигателем. Ниже пе
речислены все входные события, которые может инициировать водитель, и реак
ция на них системы:
□ внешние события Разогнаться, Круиз, Возобновить и Отключить от
ручки круиз-контроля. Событие Разогнаться приводит к автоматическо
му набору скорости, если не нажата педаль тормоза. Событие Круиз следу
ет только за событием Разогнаться. Событие Возобновить возможно
лишь в том случае, если круиз-контроль был предварительно отключен
и в памяти сохранена предыдущая крейсерская скорость. Событие Отклю
чить всегда выключает круиз-контроль;
□ внешние события Нажат Тормоз и Тормоз Отпущен от педали тормоза. Со
бытие Нажат Тормоз всегда отключает круиз-контроль. При нажатом тор
мозе автоматическое управление автомобилем невозможно. После отпуска
ния тормоза автоматическое управление возобновляется;
□ внешние события Двигатель Включен и Двигатель Выключен от двига
теля. Событие Двигатель Выключен прерывает все виды деятельности
в системе.
Постусловие. Машина неподвижна, двигатель выключен.
10.12.2, Разработка диаграммы состояний

Н а основе только что изложенного прецедента можно построить диаграмму
состояний, показанную на рис. 10.16 (числами обозначены последовательные
Сбросить Значение
1: Разогнаться [Торможения Нет] / 16: Двигатель

2Е: Enable «Увеличить Скорость» Выключен
7: Нажат Тормоз /
8D: Disable «Поддерживать Скорость»
Разгон
Отключен
14: Отключить /
9: Возобновить [Торможения Нет] / 15D: Disable «Поддерживать Скорость»
10Е: Enable «Возобновить
Круиз-Контроль» _____
Крейсерский
Режим
11: Выход на Крейсерский Режим /

12D: Disable «Возобновить Круиз-Контроль»
13Е: Enable «Поддерживать Скорость»
3: Круиз /4 D : Disable «Увеличить Скорость»,

5: Установить Значение Требуемой Скорости,
6Е: Enable «Поддерживать Скорость»
Рис. 10.16. Пример построения диаграммы состояний на основе прецедента

Пример разработки диаграммы состояний ^ Ц И Н Н И И 209
события). чально диаграмма находится в состоянии Простаивает. Ког

да включается двигатель, диаграмма переходит в состояние Начальное. Этим
удовлетворяется предусловие прецедента. Рассмотрим теперь последовательность
событий, описанную в сценарии.
Когда водитель переводит ручку круиз-контроля в положение «Разгон», воз
никает событие Разогнаться (событие 1). При условии, что педаль тормоза не
нажата, система долж на начать автоматический набор скорости. Поэтому следу
ющее состояние, в которое переходит диаграмма, мы назовем Разгон. Находясь
в этом состоянии, система увеличивает скорость движения. Следовательно, при
входе в данное состояние нужно начать деятельность Увеличить Скорость; на
рисунке она обозначена символом 2Е (Е - enable).
Следующее внешнее событие возникает, когда водитель отпускает ручку кру
из-контроля, ж елая, чтобы машина дальше двигалась с постоянной скоростью. Fla
рисунке этому соответствует событие Круиз (событие 3), которое вызывает пере
ход из состояния Разгон в состояние, которое мы назвали Крейсерский Режим.
Этот переход сопровождается следующими действиями:
1. Система должна прекратить автоматический разгон, поэтому деятельность
Увеличить Скорость при выходе из состояния Разгон завершается (4D
на рисунке).
2. Набранная скорость сохраняется для использования в будущем, поэтому
при выходе из состояния Разгон выполняется действие Установить Зна
чение Требуемой Скорости (событие 5). Этот акт трактуется как дей
ствие, а не деятельность, поскольку сохранение значения скорости считает
ся одномоментным, а не продолжительным.
3. Система должна поддерживать набранную крейсерскую скорость, поэтому
при входе в состояние Крейсерский Режим выполняется деятельность
Поддерживать Скорость ( 6 Е), не прекращаясь, пока система находится
в таком состоянии.
Новое внешнее событие - нажатие водителем педали тормоза (событие 7),
которое отключает автоматическое управление машиной. Поэтому очередное со
стояние мы назовем Круиз-Контроль Отключен, так что событие Нажат Тор
моз вызовет переход из состояния Крейсерский Режим в состояние Круиз-Кон
троль Отключен. Одновременно деятельность Поддерживать Скорость ( 8 D)
прекращается, поскольку в состоянии Круиз-Контроль Отключен машина
управляется вручную.
Согласно сценарию, следующим является внешнее событие, возникающее при
переводе ручки в положение «Возобновить». Событие Возобновить (событие 9)
вызывает переход в состояние, которое мы назвали Возобновление, при этом
начинается деятельность Возобновить Круиз-Контроль (10Е), в ходе которой
система разгоняет или притормаживает автомобиль до ранее сохраненной скоро
сти. Когда в ходе выполнения данной деятельности нужная скорость достигается,
генерируется событие Выход на Крейсерский Режим (событие 11), которое вызы
вает возврат в состояние Крейсерский Режим. Сначала прекращается деятельность
Возобновить Круиз-Контроль (12D), а затем при входе в состояние Крейсер
ский Режим начинается деятельность Поддерживать Скорость (13Е).
210 !■ ■ ■ ■ ! Конечные автоматы и диаграммы состояний
Очередное внешнее с,о( ревод ручки круиз-контроля в положение
«Выкл». Событие Отключить (событие 14) вызывает переход в состояние Круиз-
Контроль Отключен (машина управляется вручную) и прекращение деятельно
сти Поддерживать Скорость (15D). Наконец, когда двигатель выключается (со
бытие 16), осуществляется переход в состояние Простаивает.
В разобранном примере все состояния на диаграмме Управление Скорос
тью видимы, то есть водитель знает о каждом из них. По сути дела, состояния со
ответствуют действиям водителя, предпринимаемым прямо или косвенно. Все
переходы состояний, кроме одного, вытекают непосредственно из действий водите
ля. Единственное исключение - это переход из состояния Возобновление в со
стояние Крейсерский Режим. Он происходит спустя некоторое время после того,
как водитель переведет ручку круиз-контроля в положение «Возобновить», - когда
будет достигнута требуемая скорость.
10.123. Рассмотрение альтернативных внешних событий

Когда первый вариант диаграммы состояний создан, можно приступать к дета
лизации. Сначала имеет смысл несколько упростить диаграмму. Н а рис. 10.16 все
три деятельности: Увеличить Скорость, Поддерживать Скорость и Возобно
вить Круиз-Контроль - начинаются при входе в состояние и заканчиваются при
выходе из него. Начало деятельности изображено в виде действия при переходе
в состояние, а завершение - в виде действия при переходе из состояния. Допусти
мо записать это короче, воспользовавшись нотацией для деятельностей, ассоцииро
ванных с состояниями. Например, деятельность Увеличить Скорость протекает,
пока диаграмма находится в состоянии Разгон, поэтому она изображена в прямо
угольнике данного состояния (do / Увеличить Скорость на рис. 10.17). Когда мы
входим в состояние Разгон, деятельность начинается (событие 2Е), а когда выхо
дим из него (событие 4D) - прекращается.
Чтобы завершить построение диаграммы, надо рассмотреть последствия каж
дого из внешних событий, описанных в разделе «Альтернативы» прецедента. Так,
событие Разогнаться вероятно и тогда, когда диаграмма на рис. 10.17 находит
ся в состояниях Возобновление Круиз-Контроля или Круиз-Контроль От
ключен. Это событие вызывает переход в состояние Разгон, а также начало дея
тельности Увеличить Скорость. Тормоз может быть нажат в состояниях
Разгон, Крейсерский Режим и Возобновление. В таком случае прекращается
текущая деятельность по автоматическому управлению и осуществляется пере
ход в состояние Круиз-Контроль Отключен. Событие Отключить иногда воз
никает в состояниях Возобновление и Крейсерский Режим и также приводит
к прекращению текущей деятельности. Событие Двигатель Выключен возмож
но в любом состоянии, кроме Простаивает. Результатом его является переход
в состояние Простаивает и прекращение всех видов деятельности. На диаграм
ме состояний (см. рис. 1 0 . 1 0 ) показан результат добавления переходов, вызван
ных этими событиями. Никаких новых состояний вводить не потребовалось.
Рис. 10.17. Пример построения диаграммы состояний
на основе прецедента с деятельностью
10.12,4. Разработка иерархической диаграммы состояний

Обычно начинают с разработки плоской диаграммы состояний. После ее рас
ширения за счет анализа альтернативных событий нужно упростить получившу
юся диаграмму, преобразовав ее в иерархическую. Поищите состояния, которые
можно агрегировать, i юскольку у них имеется естественное надеостояние. Особое
внимание обратите на ситуации, в которых агрегирование переходов делает диа
грамму менее громоздкой. Если с этой точки зрения взглянуть на рис. 10.10, то
обнаружится, что состояния Разгон, Крейсерский Режим и Возобновление
можно считать подсостояниями состояния Автоматическое Управление
(рис. 10.18). У названных подсостояний есть общая черта: в каждом из них скорость
машины контролируется системой. Кроме того, событие Тормоз Отпущен, которое
вызывает переход в каждое из этих подсостояний, можно агрегировать в событие,
вызывающее переход из состояния Автоматическое Управление без измене
ния семантики. И наконец, все состояния плоской диаграммы (кроме Простаи
вает) допустимо агрегировать в надсостояние с именем Двигатель Работает.
Поскольку из любого подсостояния имеется переход Двигатель Выключен, то
все переходы легко агрегировать в один, ведущий из надсостояния двигатель
Работает в состояние Простаивает.
Рассмотрим иерархическую диаграмму «Круиз-контроль» (см. рис. 10.18)
подробнее. Имеется надсостояние Двигатель Работает, включающее подсо
стояния Начальное, Круиз-Контроль Отключен и Автоматическое Управ
ление. Подсостояние Автоматическое Управление само является надсосто-
янием, которое разлагается на подсостояния Разгон, Крейсерский Режим
ж Конечные автоматы и диаграммы состоянии
Сбросить Значение
Двигатель Выключен
Двигатель
Работает
Начальное
Разогнаться Отключить
[Торможения Нет] Круиз-Контроль
Отключен
Возобновить Возобновить Нажат

[Торможения Нет] [Торможения Нет] Тормоз
Автоматическое Отключить
Управление г ( Л
Разгон Разогнаться Возобновление
do / Увеличить do / Возобновить
Скорость Круиз-Контроль
\ __ _ _
Разогнаться Выход
на Крейсерский
Крейсерский Режим Режим
Круиз / Установить Значение
do / Поддерживать
Скорость
Рис. 10.18. Иерархическая диаграмма состояния

для системы круиз-контроля с деятельностями
и Возобновление. Таким образом, если система находится в надсостоянии Ав

томатическое Управление, то реально она оказывается в одном и только од
ном из подсостояний Начальное, Круиз-Контроль Отключен и Автомати
ческое Управление.
На данном примере также видны достоинства агрегирования переходов со
стояний. Так, событие Двигатель Выключен вызывает переход из каждого
подсостояния внутри надсостояния Двигатель Работает в состояние Про
стаивает, Вместо этого мы изображаем один переход из надсостояния Двига
тель Работает, семантически эквивалентный всему множеству переходов из
подсостояний. Теперь переходы из подсостояний можно не показывать. Здесь же
продемонстрировано агрегирование событий: именно событие Нажат Тормоз
способно возникать в каждом из подсостояний, входящих в надсостояние Ав
томатическое Управление, но показано оно только один раз для всего над
состояния.
При внимательном сравнении рис. 10.10 и 10.18 выявляется одно тонкое разли
чие. На рис. 10.10 с переходом Нажат Тормоз из состояния Разгон ассоциировано
действие Установить Значение Требуемой Скорости, но с тем же переходом из
Пример разработки диаграммы состоянии
Рис. 10.19. Иерархическая диаграмма «Круиз-контроль»

с деятельностями и действием при выходе
состояний Крейсерский Режим и Возобновление названное действие не ас

социируется. Д ля агрегирования таких переходов на иерархической диаграмме
они должны быть полностью идентичными. Этого можно добиться, если сделать
действие Установить Значение Требуемой Скорости действием при выходе из
состояния Разгон, а не действием на переходе, как показано на рис. 10.12 и 10.19.
10.12.5. Разработка ортогональной диаграммы состояний

В некоторых случаях можно разработать ортогональную диаграмму для моде
лирования различных аспектов зависящего от состояния объекта. Ортогональная
диаграмма, изображенная на рис. 1 0 .2 0 , используется для моделирования одной
стороны объекта Круиз-Контроль - условия торможения. Надсостояние Кру-
из-Контроль разлагается иа две ортогональные диаграммы; Круиз-Контроль
Автомобиля и Условие Торможения. Заметим, что в любой момент времени
надсостояние Круиз-Контроль находится в одном из подсостояний диаграммы
Условие Торможения и в одном из подсостояний диаграммы Круиз-Контроль
Автомобиля. Диаграмма Круиз-Контроль объединяет диаграммы Условие
Торможения и Круиз-Контроль Автомобиля.
Круиз-Контроль Автомобиля
Надсостояние
«Круиз-Контроль
Автомобиля»
Условие Торможения
Торможения Нет
Нажат Тормоз Тормоз Отпущен
Торможение Есть
Рис. 10.20. Пример ортогональных диаграмм состояний

для задачи о контроле скорости
Условие торможение изображено в виде двух возможных состояний: Тормо

жение Есть и Торможения Нет. Событие Нажат Тормоз вызывает изменения
условия с Торможения Нет на Торможение Есть, а событие Тормоз Отпущен -
обратную модификацию.
10.13. Резюме
В настоящей главе описаны особенности плоских и иерархических диаграмм
состояний. Приведены рекомендации по составлению диаграмм состояний, по
дробно описан процесс построения диаграммы состояний на основе прецедента.
Диаграмма состояний может поддерживать также несколько прецедентов, каждый
из которых отображается на некоторое подмножество диаграммы. Такие случаи
проще моделировать, если рассматривать диаграмму состояний в сочетании с мо
делью взаимодействия объектов, которая описывает, как зависящий от состояния
объект исполняет диаграмму состояний. Об этом речь пойдет в следующей главе.
Дополнительные примеры диаграмм состояний приведены также в части III.
Н а этапе динамического моделирования рассматриваются динамические, или
поведенческие, аспекты системы. Динамическая модель является одновременно
межобъектной (описывающей взаимодействие объектов) и внутриобъектной
(характеризующей, как зависящий от состояния объект определяется конечным
автоматом и изображается на диаграмме состояний). Внутриобъектная сторона
динамического моделирования имеет отношение к конечным автоматам и диа
граммам состояний, о которых шла речь в главе 10. Здесь мы будем говорить о мо
делировании взаимодействий объектов и о том, как использовать диаграммы со
стояний для описания взаимодействий зависящих от состояния объектов.
В основе построения динамической модели лежат ранее разработанные пре
цеденты. Для каждого прецедента надо определить участвующие в нем объекты
и то, как они общаются в этом прецеденте. Взаимодействие графически изобра
жается на диаграмме взаимодействия. Следует применять один из двух видов та
ких диаграмм: диаграммы кооперации или диаграммы последовательности. Не
обходимо также составить словесное описание взаимодействий объектов в виде
описания последовательности сообщений. Если во взаимодействии участвует за
висящий от состояния управляющий объект, то требуется разработать исполняе
мую им диаграмму состояний и показать соответствующие события как на диа
грамме состояний, так и на диаграмме взаимодействий.
Сначала рассмотрим, каким образом моделируется взаимодействие объектов
с помощью диаграмм кооперации и последовательности. Затем мы обратимся
к деталям метода динамического анализа, позволяющего понять кооперацию объек
тов. Анализ зависящей от состояния динамики относится к зависящим от состоя
ния кооперациям, управляемым диаграммой состояния. Анализ не зависящей от
состояния динамики не связан с диаграммами состояний.
В случае больших систем необходимо предварительно выделить подсистемы,
например по географическому признаку (см. главу 9, описание систем клиент-сер-
вер), а затем путем анализа выявить кооперацию объектов в каждой подсистеме.
Более детальное разбиение на подсистемы выполняется на этапе проектирования.
11.1. Моделирование взаимодействий объектов

Динамическое моделирование сильно зависит от сообщений и событий. Сооб
щение - это событие вместе с данными, которые ему сопутствуют; они называют
ся атрибутами сообщения. Например, у события Карточка Вставлена есть два
216 IIH f f iih " i Динамическое моделирование
атрибута: Номер Карточки и Срок Действия. Они считываются с магнитной по
лоски, которая нанесена на карточку, вставленную в банкомат. Сообщение запи
сывается так:
сообщение = событие (атрибуты сообщения);
допустим,
Карточка Вставлена (Номер Карточки, Срок Действия)
С событием могут и не ассоциироваться никакие данные. Так, у события Кар
точка Возвращена нет атрибутов.
Имя сообщения соответствует имени события, а параметры сообщения - его
атрибутам. Таким образом, в контексте диаграмм взаимодействия термины «по
следовательность событий» и «последовательность сообщений» являются сино
нимами. Чтобы разобраться с порядком взаимодействий между объектами, обычно
приходится начинать с изучения события; так возник термин анализ последователь
ности собгятий.

Когда с помощью критериев разбиения на объекты (глава 9) выявлены объек
ты в системе, можно приступать к изображению их динамических взаимодействий
на диаграммах кооперации.
В аналитической модели сообщения описывают информацию, транслируемую
между объектами. Диаграммы кооперации помогают идентифицировать операции
объектов, поскольку приход сообщения объекту обычно приводит к вызову од
ной из его операций. Однако в методе COM ET основное внимание уделяется ана
лизу передаваемой информации, а не вызываемым операциям. На этапе проекти
рования мы можем предполагать, что два разных сообщения, пришедшие объекту,
вызывают разные операции или одну и ту же операцию, которой имя сообщения
передается в качестве параметра. Однако решение следует отложить до этапа про
ектирования. Должно быть сообщение синхронным или асинхронным, определя
ется в ходе проектирования. На стадии анализа все сообщения, которыми обме
ниваются объекты, выглядят просто сообщениями, не более.
Диаграмма кооперации разрабатывается для каждого прецедента, на ней изоб
ражаются только объекты, участвующие в этом прецеденте. Некоторые объекты
могут присутствовать только на одной диаграмме кооперации, другие - сразу иа
нескольких. Такая диаграмма описывает последовательность участия объектов
в прецеденте, для ее предст

Язык

Uml Proektirovanie

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Uml Proektirovanie

Загружено:

Авторское право:

Доступные форматы

ХассанГома

Данная книга описывает процесс создания распределенных, параллель­

Translation copyright - by DMK Press

Публикуется по согласованию с издательством, выпустившим оригинал: ADDISON-

ISBN 0-201-65793-7 (англ.) Copyright © by Hassan Gomaa

ЧАСТЬ I. Нотация UML, концепции проектирования,

2.1. Диаграммы UML ............................................................................44

ЧАСТЬ II. COMET - метод архитектурного

10.1. К он е чн ы е а в то м а ты ....................................................... .......... ......... 187

10.11. Построение диаграмм состоянии

Глава 11. Д инам ическое м о д е л и р о в а н и е ............................. 215

Глава 12. Проектирование архитектуры системы .......... 250

13.1. Конфигурируемые архитектуры

13.4.5. Коммуникации с участием брокера ............................................... 279

14.6.3, Группировка по управлению ........................................................... 316

Глава 15. Проектирование классов....................................ззэ

15.6. К лассы , с к р ы в а ю щ и е а л го р и тм ы ................................................... 352

ЧАСТЬ III. Примеры проектирования параллельных

18.1. О п и с а н и е за д а чи ................................................................................... 418

19.1. Описание задачи .....................................................................483

19.4. Разбиение на объекты ................................ ...........................491

Глава 20. П р и м е р си сте м ы

20.1. Описание задачи .....................................................................540

Глава 22. П р и м е р си сте м ы эл е ктр о н н о й ко м м е р ц и и .....644

Б и б л и о гр а ф и я ........ ......................................................................................... 675

П редм етны й указатель 684

Предисловие Питера Фримена

Предисловие Брана Селика

Нотация UML и методы проектирования программ

COMET - метод архитектурного проектирования

Как работать с книгой

Альтернативная нотация для стереотипов

а) «сущность» «управление» «граница»

Технологическая Управление Интерфейс

Рис. 1. Альтернативные нотации для стереотипов в UML:

Альтернативная нотация для активных объектов

Рис. 2. Альтернативные нотации для активных объектов (задач) в UML:

Значительное понижение цен на микропроцессоры и полупроводниковые микро­

1.1. Объектно-ориентированные методы и UML

1.2. Метод и нотация

1.3, Параллельные приложения

1.3.1. Последовательные и параллельные программы

1.3.2. Последовательные и параллельные приложения

1.3.3. Параллельные задачи

1,4. Системы и приложения реального времени

Входная Информация ог Датчиков

Выходная Информация для Приводов

Привод 1 Привод 2 Привод N

Рис. 1.1. Система реального времени

1.5. Распределенные системы и приложения

Рис. 1.2. Распределенная среда обработки

Распределенная обработка имеет следующие преимущества:

□ уменьшение затрат. Зачастую распределенное решение оказывается дешев­

В методе COM ET используется нотация из унифицированного языка моделиро­

2.1. Диаграммы UML

в каком он понимается в компонентных технологиях, а не в UML (см, гла»

2.2. Диаграммы прецедентов

Рис. 2,1. Диаграммы прецедентов в нотации UML

2.3. Нотация UML для классов и объектов

Класс Класс с атрибутами Класс с атрибутами

обьект другойОбъект: Класс :Класс

Рис. 2.2. Объекты и классы в нотации UML

Необязательно (нуль или один)

Данная книга описывает процесс создания распределенных, параллель

Значительное понижение цен на микропроцессоры и полупроводниковые микро

□ уменьшение затрат. Зачастую распределенное решение оказывается дешев

В методе COM ET используется нотация из унифицированного языка моделиро

видимость, отмеченная знаком - (минус), свидетельствует о том, что элемент ви

с банковским сервером, который также размещен в одном узле, В кубе, представ

Атрибут - это значение, хранящееся в объекте класса. У каждого объекта мо

Объектное решение позволяет скрыть представление стека от объектов, ис

Те же идеи применимы к проектированию класса стека, являющегося шабло

В качестве примера сокрытия информации в устройствах ввода/вывода рас