Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
214 Глава 9. Отношения
Даже если нет возможности навигации по ассоциации, все равно может
существовать возможность прохода по ассоциации, но затраты на это
будут высокими.
Даже если нет возможности навигации по ассоциации, все равно мо
жет существовать возможность установления отношения в этом на
правлении. Но вычислительные затраты на это, скорее всего, будут
очень высокими. В примере на рис. 9.13, несмотря на отсутствие воз
можности прямой навигации от Product к Order, просмотрев по очереди
все объекты Order, можно найти Order, ассоциированный с конкретным
объектом Product. То есть можно пройти не допускающее навигации от
ношение, но с большими вычислительными затратами. Односторон
няя возможность навигации подобна улице с односторонним движени
ем: по ней нельзя пойти против движения напролом, но чтобы до
браться до ее конца, можно найти другие (более длинные) пути.
Если на целевом конце отношения указано имя роли, объекты исходно
го класса могут ссылаться на объекты целевого класса по имени роли.
С точки зрения реализации на ОО языках программирования возмож
ность навигации подразумевает, что у исходного объекта есть объект
ная ссылка на целевой объект. Исходный объект может использовать
эту ссылку для отправки сообщений целевому объекту. На диаграмме
объектов это можно представить в виде однонаправленной связи с ас
социированным сообщением.
9.4.4. Ассоциации и атрибуты
Существует тесная связь между ассоциациями класса и атрибутами
класса.
Ассоциация между исходным и целевым классами означает, что объ
екты исходного класса могут сохранять объектную ссылку на объекты
целевого класса. Иначе это можно представить так, что ассоциация эк
вивалентна исходному классу, имеющему псевдоатрибут целевого
класса. Объект исходного класса может ссылаться на объект целевого
класса с помощью псевдоатрибута (рис. 9.16).
House Address
1
address
источник цель
House
Задание имени роли для допускающего навигацию отношения аналогично тому,
что у исходного класса есть псевдоатрибут с тем же именем, что и имя роли,
и того же типа, что и целевой класс
1
address:Address
Рис. 9.16. Объект исходного класса ссылается на объект целевого класса
посредством псевдоатрибута
9.4. Что такое ассоциация? 215
Нет широко используемого ОО языка программирования, имеющего
специальную языковую конструкцию для поддержки ассоциаций. По
этому при автоматическом генерировании кода из UMLмодели ассо
циации одинкодному превращаются в атрибуты исходного класса.
На рис. 9.17 в сгенерированном коде есть класс House с атрибутом ad
dress типа Address. Обратите внимание, как имя роли обеспечивает имя
атрибуту, а класс, находящийся на другом конце ассоциации, обеспе
чивает класс атрибута. Приведенный ниже код на Java был сгенериро
ван из модели, представленной на рис. 9.17:
public class House
{
private Address address;
}
Как видите, есть класс House, имеющий один атрибут address типа Add
ress. Обратите внимание, что видимость атрибута address – private; она
применяется по умолчанию в большинстве случаев генерации кода.
Если кратность целевого класса больше 1, она реализуется одним из
следующих способов:
• как атрибут типа array (массив) (конструкция, поддерживаемая
большинством языков программирования);
• как атрибут некоторого типа, являющегося коллекцией.
Коллекции – это просто классы, экземпляры которых имеют особое
поведение, заключающееся в способности сохранять и возвращать ссыл
ки на другие объекты. Самым обычным примером коллекции в Java яв
ляется Vector, но есть и многие другие. Более подробно коллекции обсу
ждаются в разделе 18.10.
Псевдоатрибуты хороши для отношений одинкодному и одинко
многим, но для отношений многиекомногим возникают проблемы.
Их реализация будет показана в главе 18.
Ассоциации используются только тогда, когда целевой класс является
важной частью модели, в противном случае отношения моделируются
с помощью атрибутов. Важными являются бизнесклассы, описываю
щие часть прикладной области. Не имеющими большого значения
классами являются компоненты библиотеки, такие как классы String,
Date и Time.
=
псевдоатрибут атрибут
AddressHouse
House
address
address:Address
11
Рис. 9.17. Из этой модели сгенерирован код, в котором есть класс House
с атрибутом address типа Address
216 Глава 9. Отношения
До известной степени выбор явного указания ассоциации или атрибу
тов является вопросом стиля. Лучшим всегда будет тот подход, в кото
ром модель и диаграммы выражают задачу ясно и точно. Часто пред
ставленная на диаграмме ассоциация с другим классом более понятна,
чем это же отношение, смоделированное как атрибут, который заме
тить намного сложнее. Если кратность цели больше 1, это ясно пока
зывает, что целевой класс важен для модели. Таким образом, для мо
делирования такого отношения используются ассоциации.
Если кратность целевого класса равна 1, целевой объект может быть
только частью исходного, и поэтому не стоит показывать отношение
с ним как ассоциацию. Возможно, лучше смоделировать его как атри
бут. Это особенно справедливо, если кратность равна 1 на обоих кон
цах отношения (как на рис. 9.17), когда ни источник, ни цель не могут
существовать самостоятельно.
9.4.5. Классыассоциации
В ОО моделировании распространена следующая проблема: когда ме
жду классами установлено отношение многиекомногим, встречают
ся такие атрибуты, которые не удается поместить ни в один из клас
сов. Проиллюстрируем это примером, приведенным на рис. 9.18.
На первый взгляд это довольно безобидная модель:
• каждый человек (объект Person) может работать во многих компани
ях (объект Company);
• каждая компания (Company) может нанимать много людей (объект
Person).
Однако что происходит, если добавить бизнесправило, заключающее
ся в том, что каждый Person получает зарплату в каждой нанявшей его
Company? Где должна быть записана эта зарплата: в классе Person или
в классе Company?
Действительно, нельзя сделать зарплату Person атрибутом класса Person,
потому что каждый экземпляр Person может работать на многие Company
и в каждой получать разную зарплату. Аналогично нельзя сделать зар
плату атрибутом Company, поскольку каждый экземпляр Company нани
мает множество Person, зарплата которых может быть разной.
Решение кроется в том, что зарплата на самом деле является собствен+
ностью самой ассоциации. У каждой ассоциации найма, устанавли
ваемой между объектом Person и объектом Company, своя индивидуаль
ная зарплата.
Company Person
*
*
Рис. 9.18. Отношение многие+ко+многим
9.4. Что такое ассоциация? 217
UML позволяет моделировать эту ситуацию с помощью классаассоциа
ции (рис. 9.19). Важно понимать этот синтаксис: многие люди думают,
что классассоциация – это всего лишь прямоугольник, свисающий
с ассоциации. Но ничто не могло бы быть дальше от истины, чем это.
На самом деле классассоциация – это линия ассоциации (включая все
имена ролей и кратности), пунктирная нисходящая линия и прямо
угольник класса на конце пунктирной линии. Короче говоря, классас
социация – все, что входит в затемненную область (рис. 9.19).
Классассоциация – это ассоциация, являющаяся еще и классом.
По сути, классассоциация – это ассоциация, являющаяся еще и клас
сом. Она не только соединяет два класса, как обычная ассоциация, она
определяет набор характеристик, принадлежащих самой ассоциации.
У классовассоциаций могут быть атрибуты, операции и другие ассо
циации.
Классассоциация означает, что в любой момент времени между любы
ми двумя объектами может существовать только одна связь.
Экземпляры классаассоциации – это на самом деле связи, у которых
есть атрибуты и операции. Уникальная идентификация этих связей оп
ределяется исключительно индивидуальностью объектов, находящихся
на каждом конце. Этот фактор ограничивает семантику классаассоциа
ции: его можно использовать только тогда, когда между двумя объекта
ми в любой момент времени установлена единственная уникальная
связь. Это обусловлено тем, что каждая связь, которая является экземп
ляром классаассоциации, должна быть уникальной. На рис. 9.19 при
менение классаассоциации означает, что на модель накладывается сле
дующее ограничение: для данного объекта Person и данного объекта Com
pany может существовать только один объект Job (должность). Иначе го
воря, каждый Person может занимать только одну Job в данной Company.
Однако если ситуация такова, что данный объект Person может зани
мать несколько Job в данном объекте Company, классассоциацию ис
пользовать нельзя – семантика не соответствует!
Но нам попрежнему надо кудато сохранять зарплату для каждой
группы Company/Job/Person. Поэтому мы материализуем (делаем реаль
класс!ассоциация состоит из класса,
ассоциации и пунктирной линии
класс!ассоциация
**
Job
salary:double
Company Person
Рис. 9.19. Класс+ассоциация
218 Глава 9. Отношения
ным) отношение, представляя его в виде обычного класса. На рис. 9.20
Job является обычным классом. Как видите, у Person может быть не
сколько Job, каждая Job в каждой конкретной Company.
Материализованное отношение делает возможным существование бо
лее одной связи между любыми двумя объектами в конкретный момент
времени.
Откровенно говоря, многие разработчики объектных моделей просто
не понимают семантической разницы между классамиассоциациями
и материализованными отношениями. Поэтому одни часто подменя
ются другими. Однако разница на самом деле очевидна: классыассо
циации могут использоваться только в том случае, когда каждая связь
имеет уникальную индивидуальность. Надо просто запомнить, что ин
дивидуальность связи определяется индивидуальностью объектов,
располагающихся на ее концах.
9.4.6. Квалифицированные ассоциации
Квалифицированные ассоциации могут использоваться для превраще
ния ассоциации nкомногим в ассоциацию nкодному путем задания
одного объекта (или группы объектов) из целевого набора. Это очень
полезные элементы модели, поскольку они показывают, как можно
вести поиск или осуществлять навигацию к конкретным объектам
коллекции.
Рассмотрим модель, изображенную на рис. 9.21. Объект Club (клуб)
связан с набором объектов Member (член), а объект Member подобным же
образом связан с только одним объектом Club.
Company Person
Job
salary:double
**11
Рис. 9.20. Материализованное отношение в виде обычного класса
Club
Member
memberId:String
1
*
Рис. 9.21. Отношение один+ко+многим
9.5. Что такое зависимость? 219
Квалифицированная ассоциация выбирает один объект из целевого
набора.
Возникает следующий вопрос: как от объекта Club, связанного с набо
ром объектов Member, перейти к одному конкретному объекту Member?
Очевидно, что необходим некоторый уникальный ключ, который
можно использовать для поиска определенного объекта Member из на
бора. Такой ключ называют квалификатором (qualifier). Квалифика
торы могут быть разными (имя, номер кредитной карточки, номер со
циальной страховки). В приведенном выше примере у каждого объек
та Member есть значение атрибута memberId, уникальное для данного
объекта. Это и есть ключ поиска в данной модели.
В модели такой поиск можно обозначить путем добавления квалифи
катора на конце ассоциации со стороны Club. Важно понимать, что этот
квалификатор принадлежит концу ассоциации, а не классу Club. Этот
квалификатор задает уникальный ключ и таким образом превращает
отношение одинкомногим в отношение одинкодному, как показано
на рис. 9.22.
Квалифицированные ассоциации – замечательный способ показать,
как с помощью уникального ключа происходит выбор определенного
объекта из набора. Квалификаторы обычно ссылаются на атрибут це
левого класса, но возможны и другие выражения, с помощью которых
выбирается один объект из набора.
9.5. Что такое зависимость?
Зависимость обозначает отношение между двумя или более элемента
ми модели, при котором изменение одного элемента (поставщика) мо
жет повлиять или предоставить информацию, необходимую другому
элементу (клиенту). Иначе говоря, клиент некоторым образом зависит
memberId:String
Member
memberId
Club
0..1
1
квалификатор
комбинация {Club, memberId} задает уникальную цель
заданная кратность
Рис. 9.22. Квалификатор превращает отношение один+ко+многим
в отношение один+к+одному
220 Глава 9. Отношения
от поставщика. Зависимости используются для моделирования отно
шений между классификаторами, когда один классификатор зависит
от другого, но отношение не является ни ассоциацией, ни обобщением.
В отношении зависимости клиент некоторым образом зависит от по
ставщика.
Например, объект одного класса передается как параметр в операцию
объекта другого класса. Очевидно, что между классами этих объектов
существует отношение некоторого рода, но это не совсем обычная ассо
циация. Отношение зависимости (специализированное некоторыми
предопределенными стереотипами) можно использовать как универ
сальное средство для моделирования данного вида отношений. Мы
уже приводили один из типов зависимостей – отношение «instantiate»,
но существуют и многие другие. Общепринятые стереотипы зависимо
стей рассматриваются в следующих разделах.
UML 2 определяет три основных типа зависимостей (табл. 9.2). Мы
включили их в обсуждение для полноты информации, но в повседнев
ном моделировании редко используется чтолибо кроме простой пунк
тирной стрелки зависимости. Обычно разработчики моделей не утру
ждают себя определением типа зависимости.
Таблица 9.2
Зависимости также могут существовать не только между классами.
Как правило, они могут устанавливаться между:
• пакетами и пакетами;
• объектами и классами.
Зависимости могут устанавливаться между операцией и классом. Но
эти отношения довольно редко отображаются на диаграммах, по
скольку это приводит к слишком большому уровню детализации. Не
Тип Семантика
Usage
(Использование)
Клиент использует некоторые из доступных сервисов по
ставщика для реализации собственного поведения; это са
мый распространенный тип зависимости.
Abstraction
(Абстракция)
Обозначает отношение между клиентом и поставщиком,
где поставщик более абстрактный, чем клиент.
Что подразумевается под «более абстрактный»? Это мо
жет означать, что поставщик находится на другой стадии
разработки, чем клиент (например, в аналитической мо
дели, а не в проектной модели).
Permission
(Доступ)
Поставщик предоставляет клиенту разрешение на доступ
к своему содержимому – это дает возможность поставщи
ку контролировать и ограничивать доступ к своему содер
жимому.
9.5. Что такое зависимость? 221
которые примеры различных типов зависимостей приведены на
рис. 9.23. Они обсуждаются в оставшихся разделах данной главы.
Чаще всего для обозначения зависимости используется обычная пунк
тирная линия со стрелкой без указания типа зависимости. По сути,
тип зависимости часто понятен и без стереотипа – из контекста. Если
же возникает желание или необходимость конкретизировать тип зави
симости, UML определяет целый ряд стандартных стереотипов.
9.5.1. Зависимости использования
Существует пять зависимостей использования: «use», «call», «parame
ter», «send» и «instantiate», каждая из которых рассматривается в следу
ющих подразделах.
9.5.1.1. Зависимость «use»
Самым распространенным стереотипом зависимости является «use»,
который просто обозначает, что клиент какимто образом использует
поставщика. Если на диаграмме указана просто пунктирная линия со
стрелкой зависимости без стереотипа, можно быть совершенно уверен
ным, что подразумевается зависимость «use».
На рис. 9.24 показаны два класса, А и В, между которыми установлено
отношение зависимости «use». Эта зависимость генерируется любой
из следующих ситуаций.
1. Операции класса A необходим параметр класса B.
2. Операция класса A возвращает значение класса B.
ClassD
foo ()
ClassA
«permit»
:ClassA
ClassC
поставщик
клиент
клиент
«use»
зависимость от операции
к классу
«instantiate»
Рис. 9.23. Типы зависимостей
поставщик
стереотип часто
опускается
клиент
«use»
AB
doSomething( )
bar( ):B
foo(b:B)
Рис. 9.24. Два класса с отношением зависимости типа «use»
222 Глава 9. Отношения
3. Операция класса A гдето в своей реализации использует объект
класса B, но не в качестве атрибута.
Варианты 1 и 2 довольно просты, а вот вариант 3 представляет больший
интерес. Такая ситуация возможна, если одна из операций класса А
создала временный объект класса В. Ниже приводится фрагмент Java
кода для этого случая:
class A
{
...
void doSomething()
{
B myB = new B();
// используем myB некоторым образом
...
}
}
Хотя одна зависимость «use» может использоваться как универсальная
для всех трех перечисленных случаев, есть и другие, более специали
зированные стереотипы зависимостей, которые можно было бы приме
нить.
Ситуации 1 и 2 можно более точно смоделировать с помощью зависи
мости «parameter», а ситуацию 3 – с помощью зависимости «call». Однако
от UMLмодели не часто требуется такой уровень детализации, и боль
шинство разработчиков моделей считают, что намного понятней и про
ще просто устанавливать между соответствующими классами зависи
мость «use», как показано выше.
9.5.1.2. Зависимость «call»
Зависимость «call» (вызов) устанавливается между операциями – опе
рацияклиент вызывает операциюпоставщик. Этот тип зависимости
в UMLмоделировании используется не очень широко. Он применяет
ся на уровне детализации, более глубоком, чем тот, на который боль
шинство разработчиков готовы пойти. Кроме того, в настоящее время
очень немногие средства моделирования поддерживают зависимости
между операциями.
9.5.1.3. Зависимость «parameter»
Поставщик является параметром операции клиента.
9.5.1.4. Зависимость «send»
Клиент – это операция, посылающая поставщика (который должен быть
сигналом) в некоторую неопределенную цель. Сигналы рассматривают
ся в разделе 15.6, а пока будем представлять их как особые типы клас
сов, используемые для передачи данных между клиентом и целью.
9.5. Что такое зависимость? 223
9.5.1.5. Зависимость «instantiate»
Клиент – это экземпляр поставщика.
9.5.2. Зависимости абстракции
Зависимости абстракции моделируют зависимости между сущностя
ми, находящимися на разных уровнях абстракции. В качестве приме
ра можно привести класс аналитической модели и тот же класс в про
ектной модели. Существует четыре зависимости абстракции: «trace»,
«substitute», «refine» и «derive».
9.5.2.1. Зависимость «trace»
Зависимость «trace» часто используется, чтобы проиллюстрировать от
ношение, в котором поставщик и клиент представляют одно понятие,
но находятся в разных моделях. Например, поставщик и клиент могут
находиться на разных стадиях разработки. Поставщик мог бы быть
аналитическим представлением класса, а клиент – более детальным
проектным представлением. Также «trace» можно использовать, чтобы
показать отношение между функциональным требованием, таким как
«банкомат должен обеспечивать возможность снятия наличных денег
вплоть до достижения кредитного лимита карты», и прецедентом,
поддерживающим это требование.
9.5.2.2. Зависимость «substitute»
Зависимость «substitute» (заместить) показывает, что клиент во время
выполнения может заменять поставщика. Замещаемость основывает
ся на общности контрактов и интерфейсов клиента и поставщика, т. е.
они должны предоставлять один и тот же набор сервисов. Обратите
внимание, что замещаемость не достигается посредством отношений
специализации/обобщения между клиентом и поставщиком (специа
лизация/обобщение обсуждаются в разделе 10.2). В сущности, «substi
tute» специально разработана для использования в средах, не поддер
живающих специализации/обобщения.
9.5.2.3. Зависимость «refine»
Тогда как зависимость «trace» устанавливается между элементами раз
ных моделей, «refine» (уточнить) может использоваться между элемен
тами одной и той же модели. Например, в модели может быть две вер
сии класса, одна из которых оптимизирована по производительности.
Поскольку оптимизация производительности является разновидно
стью уточнения, это отношение между двумя классами можно смоде
лировать как зависимость «refine» с примечанием, описывающим суть
уточнения.