Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
204 Глава 9. Отношения
ясной и понятной. Мы, как и многие разработчики моделей, обычно
используем прямоугольный стиль.
На рис. 9.4 использован прямоугольный стиль, и пути объединены
в дерево. Объединять можно только пути, имеющие одинаковые свой
ства. В данном случае все пути представляют связи, поэтому вполне
законно могут быть объединены.
Визуальная четкость, легкость прочтения и общая привлекательность
диаграмм имеют огромное значение. Необходимо всегда помнить, что
основная масса диаграмм создается для когото. Таким образом, не
важно, какой стиль используется, важны четкость и ясность.
9.4. Что такое ассоциация?
Ассоциации – это отношения между классами. Аналогично связям,
соединяющим объекты, ассоциации соединяют классы. Самое глав
ное: для того чтобы между двумя объектами была связь, между клас
сами этих объектов должна существовать ассоциация. Потому что
связь – это экземпляр ассоциации. Так же как объект – экземпляр
класса.
Ассоциации – это соединения между классами.
На рис. 9.5 показаны отношения между классами и объектами и меж
ду связями и ассоциациями. Поскольку не может быть связи без ассо
циации, очевидно, что связи зависят от ассоциаций. Это можно смоде
лировать как отношение зависимости (пунктирная стрелка), которое
более подробно рассматривается в разделе 9.5. Чтобы явно обозначить
семантику зависимости между ассоциациями и связями, зависимость
помечается стереотипом «instantiate».
Объекты – это экземпляры классов, а связи – экземпляры ассоциаций.
chairperson
secretary
member
BookClub
bookClub:Club erica:Person
ila:Person
naomi:Person
Рис. 9.4. Прямоугольный стиль отображения путей
9.4. Что такое ассоциация? 205
Семантика базовой, неуточненной ассоциации чрезвычайно проста: ас
социация между классами указывает на то, что между объектами этих
классов могут устанавливаться связи. Существуют другие, более кон
кретные формы ассоциаций (агрегация и композиция), которые рас
сматриваются в разделе 18.3 при обсуждении процесса проектирования.
9.4.1. Синтаксис ассоциации
Ассоциации могут иметь:
• имя ассоциации
• имена ролей
• кратность
• возможность навигации
Поскольку ассоциации обозначают действие, производимое исходным
объектом над целевым объектом, в качестве их имен должны исполь
зоваться глагольные группы. Перед именем или после него может при
меняться маленькая черная стрелка, указывающая направление, в ко
тором должно читаться имя ассоциации. Имя ассоциации записывает
ся в стиле lowerCamelCase.
В примере на рис. 9.6 ассоциация читается следующим образом:
«Компания (Company) нанимает много Человек (Persons)». Хотя стрелка
указывает направление чтения ассоциации, всегда можно прочитать
ее в обратном направлении. Таким образом, в примере на рис. 9.6 мож
chairperson
Club
ассоциация
cвязь
«instantiate»
«instantiate»
«instantiate»
ila:Person
bookClub:Club
Person
Рис. 9.5. Отношения между классами и объектами и между связями
и ассоциациями
Company Person
employs
1
возможность навигацииимя ассоциации
кратность
*
Рис. 9.6. Отображение ассоциации с использованием ее имени
206 Глава 9. Отношения
но сказать, что в любой момент времени «каждый Человек (Person) на
нят только одной Компанией (Company)».
Имена ассоциаций – это глагольные группы, указывающие на семантику
ассоциации.
Альтернативный вариант – классам на обоих концах ассоциации мо
гут быть присвоены имена ролей. Эти имена указывают на роли, ис
полняемые объектами классов, когда они связаны экземплярами дан
ной ассоциации. На рис. 9.7 можно видеть, что объект Company будет
играть роль employer (работодатель), а объекты Person – роль employee
(служащие), если они связаны экземплярами этой ассоциации. Имена
ролей называют роль, которую могут играть объекты, поэтому они
должны быть существительными или именными группами.
Ассоциация может иметь или имя ассоциации, или имя роли. Указа
ние и имени роли, и имени ассоциации для одной и той же ассоциации
теоретически допустимо, но считается очень плохим стилем. Это уже
перебор!
Признак хороших имен ассоциаций и ролей – они должны легко чи
таться. На рис. 9.6 ассоциация «Company employs many Persons» (Компа
ния нанимает много Человек) звучит на самом деле замечательно. Ес
ли прочитать ассоциацию в обратном направлении, получается «Person
is employed by exactly one Company at any point in time» (Человек нанят
только одной Компанией в любой момент времени). Тоже звучит не
плохо. Аналогичным образом имена на рис. 9.7 ясно указывают роли,
которые будут играть объекты этих классов, связанные именно таким
образом.
Имена ролей – это именные группы, указывающие на роли, исполняе
мые объектами, связанными экземплярами этой ассоциации.
9.4.2. Кратность
Ограничения – один из трех механизмов расширения UML, и крат
ность – первый из рассматриваемых нами типов ограничений. Это так
же самый распространенный тип ограничений. Кратность ограничи
вает число объектов класса, которые могут быть вовлечены в конкрет
Company Person
employer
1
возможность навигацииимя роли
кратность
employee
*
Рис. 9.7. Отображение ассоциации с использованием имен ролей
9.4. Что такое ассоциация? 207
ное отношение в любой момент времени. Фраза «в любой момент вре
мени» – решающая для понимания кратностей. На рис. 9.8 можно
увидеть, что в любой момент времени объект Person нанят только од
ним объектом Company. Однако с течением времени объект Person мо
жет быть нанят несколькими объектами Company.
На рис. 9.8 можно найти еще коекакие любопытные вещи. Объект
Person не может быть безработным, он всегда нанят только одним объ
ектом Company. Таким образом, ограничение включает в себя два биз
несправила данной модели:
• объекты Person в данный момент времени могут быть наняты только
одним объектом Company;
• объекты Person не могут быть безработными.
Не важно, зависят или нет эти допустимые ограничения всецело от
требований, предъявляемых к моделируемой системе, но это именно
то, что выражает модель.
Как видим, ограничения кратности имеют большое значение, в них
могут быть закодированы ключевые бизнесправила модели. Однако
эти правила «скрыты» в деталях модели. Грамотные разработчики мо
делей называют такое сокрытие ключевых бизнесправил и требова
ний «тривиализацией» (trivialization). Намного более глубокое обсуж
дение этого феномена можно найти в книге [Arlow 1].
Кратность задается в виде разделенного запятыми списка интервалов,
в котором каждый интервал представлен в форме:
минимум..максимум
где минимум и максимум – целые числа или любое выражение, возвраща
ющее целое число.
Если кратность не задана явно, значит, решение о ней еще не принято.
Если кратность не задана явно, значит, решение о ней еще не принято.
В UML нет «применяемой по умолчанию» кратности. В моделирова
нии широко распространена ошибка, состоящая в том, что незаданная
Company Person
employer employee
Компания нанимает много Человек
Каждый Человек работает на одну Компанию
1
*
Рис. 9.8. Отображение кратности на диаграмме
208 Глава 9. Отношения
кратность по умолчанию предполагается равной 1. Некоторые приме
ры синтаксиса кратности приведены в табл. 9.1.
Кратность задает число объектов, которые могут принимать участие
в отношении в любой момент времени.
Таблица 9.1
Модель всегда необходимо читать так, как написано.
Пример на рис. 9.9 иллюстрирует, что кратность действительно явля
ется мощным ограничением, которое часто имеет огромное влияние
на бизнессемантику модели.
Если прочитать пример внимательно, можно увидеть, что:
• у Company может быть ровно семь employee;
• Person может быть нанят только одной Company (т. е. в данной модели
Person не может одновременно иметь больше одной должности);
• у BankAccount может быть только один owner (владелец);
• у BankAccount может быть один или много operator (операторов);
• у Person может быть от нуля до множества BankAccount;
• Person может управлять от нуля до множества BankAccount.
При прочтении UMLмодели крайне важно понять, что именно выра
жает модель, а не прибегать к предположениям или догадкам. Мы на
зываем это «прочтением модели как есть».
Например, рис. 9.9 утверждает, что у Company может быть именно семь
employee, не больше и не меньше. Большинству такая семантика пока
жется странной или даже неверной (если только это не очень странная
компания), но именно так гласит модель. Об этом никогда нельзя за
бывать.
Существуют некоторые разногласия по поводу того, нужно ли показы
вать кратность в аналитических моделях. Мы думаем, да, потому что
Дополнение Семантика
0..1 Нуль или 1
1 Ровно 1
0..* Нуль или более
* Нуль или более
1..* 1 или более
1..6 От 1 до 6
1..3, 7..10, 15, 19..* От 1 до 3, или от 7 до 10, или ровно 15, или от 19
до множества
9.4. Что такое ассоциация? 209
кратность описывает бизнесправила, требования и ограничения и мо
жет вскрыть необоснованные предположения относительно предмет
ной области. Очевидно, что такие предположения необходимо выяв
лять и устранять как можно раньше.
9.4.2.1. Рефлексивные ассоциации
Если класс имеет ассоциацию с самим собой, это рефлексивная ассо
циация.
Очень распространено явление, когда класс имеет ассоциацию с самим
собой. Это называется рефлексивной ассоциацией и означает, что объ
екты данного класса имеют связи с другими объектами этого же клас
са. Замечательный пример рефлексивной ассоциации приведен на
рис. 9.10. Каждый объект Directory (каталог) может иметь связи с объ
ектами Directory, выступающими в роли subdirectory (подкаталог), число
Company Person
employer
1
employee
BankAccount
1 1..*
0..* 0..*
owner operator
7
Рис. 9.9. Кратность – мощное ограничение
Directory File
0..*10..*
0..1
C:Directory
Windows:Directory My Documents:Directory Corel:Directory
Command:Directory
autoexec:File
config:File
To John:File
каталоги файлы
parent
subdirectory
рефлексивная ассоциация
Рис. 9.10. Пример рефлексивной ассоциации: вверху – диаграмма классов,
внизу – диаграмма объектов
210 Глава 9. Отношения
которых может меняться от нуля до некоторой величины (0..*), а так
же с нулем или одним (0..1) объектом Directory, выступающим в роли
parent (родитель). Кроме того, каждый объект Directory ассоциирован
с нулем или более объектов File (файл). В этом примере рефлексивные
ассоциации превосходно моделируют универсальную структуру ката
логов, хотя следует заметить, что у конкретных файловых систем (на
пример, Windows) могут быть другие ограничения кратности.
Верхняя половина рис. 9.10 представляет диаграмму классов. В ниж
ней половине приведен пример диаграммы объектов, соответствую
щей этой диаграмме классов.
9.4.2.2. Иерархии и сети
В процессе моделирования вы обнаружите, что часто объекты органи
зуются в иерархии или сети. Иерархия имеет один корневой объект.
У каждого последующего узла иерархии только один прямой предше
ственник. Деревья каталогов обычно формируют иерархии. То же са
мое можно сказать о классификации в машиностроении и о элементах
XML и HTMLдокументов. Иерархия – это очень упорядоченный,
структурированный и довольно негибкий способ организации объек
тов. Пример иерархии показан на рис. 9.11.
В иерархии объект может иметь один прямой объектпредок или не
иметь ни одного.
Однако в сети обычно нет корневого объекта, хотя это не исключено.
В сетях каждый объект может быть непосредственно соединен с мно
гими объектами. В сети нет строгого представления «над» или «под».
Это намного более гибкая структура, в которой возможно равенство
между узлами. World Wide Web образует сложную сеть узлов, упро
щенное представление которой показано на рис. 9.12.
В сети объект может быть непосредственно соединен с многими объек
тами или вообще не иметь соединения.
a1: A
c1: A d1: Ab1: A
e1: A f1: A g1: A
A
0..*
0..1
Диаграмма классов Пример диаграммы объектов
иерархия ассоциаций
Рис. 9.11. Пример иерархии
9.4. Что такое ассоциация? 211
Давайте рассмотрим товары в качестве примера, иллюстрирующего
иерархии и сети. Существует две фундаментальные абстракции:
• ProductType (тип товара) – тип продукта, например «Струйный прин
тер»;
• ProductItem (товарная позиция) – конкретный струйный принтер с се
рийным номером 0001123430.
ProductType и ProductItem очень подробно рассматриваются в книге [Ar
low 1]. Типы товаров обычно образуют сети. Таким образом, Product
Type, например комплект вычислительного оборудования, может со
стоять из ЦП, монитора, клавиатуры, мыши, видеокарты и других ти
пов товаров (ProductType). Каждый из этих ProductType описывает тип
товара, а не конкретную товарную позицию, и эти типы товаров могут
входить в другие составные ProductType, например в разные комплекты
вычислительного оборудования.
Если же рассматриваются товарные позиции (ProductItem), которые яв
ляются конкретными экземплярами ProductType, любая позиция Pro
ductItem (например, конкретный ЦП) может быть продана и поставле
на как часть одного комплекта товаров только один раз. Следователь
но, товарные позиции образуют иерархии.
9.4.3. Возможность навигации
Возможность навигации (navigability) указывает на возможность про
хода от объекта исходного класса к одному или более объектам в зави
симости от кратности целевого класса. Смысл навигации в том, что
«сообщения могут посылаться только в направлении, в котором ука
зывает стрелка». На рис. 9.13 объекты Order могут посылать сообще
ния объектам Product, но не наоборот.
Возможность навигации показывает, что объекты исходного класса
«знают об» объектах целевого класса.
Одна из целей хорошего ОО анализа и проектирования – минимизиро
вать количество взаимосвязей между классами. И применение возмож
Диаграмма классов
A
0..*
0..*
сеть ассоциаций
Пример диаграммы объектов
f1: A
a1: A
c1: A
d1: A
e1: A
b1: A
g1: A
Рис. 9.12. Упрощенное представление сети WWW
212 Глава 9. Отношения
ности навигации – верное средство достижения этой цели. Сделав ассо
циацию между Order и Product однонаправленной, можно обеспечить воз
можность свободной навигации от объектов Order к объектам Product, но
не в обратном направлении – от объектов Product к объектам Order. Та
ким образом, объекты Product не знают о своем возможном участии
вконкретном Order и, следовательно, не имеют связанности с Order.
Возможность навигации обозначается крестом или стрелкой на кон
цах отношения, как показано на рис. 9.13.
Спецификация UML 2.0 [UML2S] предлагает три стиля обозначения
возможности навигации на диаграммах модели.
1. Сделать возможность навигации абсолютно явной. Должны быть
обозначены все стрелки и кресты.
2. Сделать возможность навигации абсолютно скрытой. Стрелки и кре
сты не обозначаются.
3. Опускать все кресты. Двунаправленная ассоциация обозначается
без стрелок. Однонаправленная ассоциация обозначается с одной
стрелкой.
Эти три стиля представлены на рис. 9.14.
Стиль 1 делает возможность навигации полностью видимой, что, одна
ко, может сделать диаграмму слишком громоздкой.
Стиля 2 следует избегать, потому что он скрывает слишком много зна
чимой информации.
Стиль 3 – разумный компромисс. На практике чаще всего используется
стиль 3. И поскольку он представляет лучший на данный момент вари
ант, именно он применяется в этой книге. Основные преимущества сти
ля 3: при его использовании диаграммы не загромождаются слишком
большим количеством стрелок и крестов; он обратно совместим с пре
дыдущими версиями UML. Однако у этого стиля есть и недостатки.
Order Product
**
допускает навигацию
не допускает навигации
возможность навигации возможность навигации
объект Order хранит список объектов Product
объект Product не хранит списка объектов Order
Рис. 9.13. Варианты обозначения возможности навигации
9.4. Что такое ассоциация? 213
• Глядя на диаграмму, нельзя сказать, указана ли на ней возмож
ность навигации или она еще не определена.
• Значение связи с одной стрелкой меняется с «есть/не определена»
возможность навигации на «есть/нет» возможности навигации. Это
недостаток, с которым приходится мириться.
• Нельзя показать ассоциации, в которых отсутствует возможность
навигации в обоих направлениях (кресты на обоих концах). Такие
связи бесполезны в повседневном моделировании, поэтому особой
проблемы это не создает.
Обзор стиля 3 можно увидеть на рис. 9.15.
Есть возможность
навигации от B к A
Есть возможность
навигации от A к B
Нет возможности
навигации от B к A
Есть возможность
навигации от A к B
Возможность навигации
от B к A не определена
Возможность навигации
от A к B не определена
Возможность навигации
от B к A не определена
Нет возможности
навигации от A к B
Нет возможности
навигации от B к A
Стиль 1:
Строгое обозначение
возможности навигации в UML 2
Синтаксис UML 2
B
B
B
B
B
A
A
A
A
A
Есть возможность
навигации от A к B
Стили представления возможности навигации в UML 2
Стиль 3:
Общепринятая
практика
Есть возможность
навигации от A к B
Нет возможности
навигации от B к A
Есть возможность
навигации от A к B
Есть возможность
навигации от B к A
Возможность навигации
от A к B не определена
Возможность навигации
от B к A не определена
Стиль 2:
Возможность навигации
не обозначается
Рис. 9.14. Стили представления возможности навигации в UML 2
Однонаправленная ассоциация:
Есть возможность навигации от A к B
Нет возможности навигации от B к A
Двунаправленная ассоциация:
Есть возможность навигации от A к B
Есть возможность навигации от B к A
Стиль представления 3 чаще всего используется на практике
A
AB
B
Рис. 9.15. Стиль 3