Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование

Подождите немного. Документ загружается.

394 Глава 18. Уточнение отношений, выявленных при анализе

Очень полезно помнить об этих простых аналогиях при дальнейшем

более подробном рассмотрении семантики агрегации и композиции.

18.4. Семантика агрегации

Агрегация – это тип отношения целоечасть, в котором агрегат образу

ется многими частями. В отношении целоечасть один объект (целое)

использует сервисы другого объекта (части). По существу, целое явля

ется доминантной и управляющей стороной отношения, тогда как

часть просто обслуживает запросы целого и, следовательно, играет бо

лее пассивную роль. Действительно, если навигацию можно осуществ

лять только от целого к части, последняя даже не знает, что является

частью целого.

Рассмотрим конкретный пример агрегации (рис. 18.3). Мы видим сле

дующее:

• компьютер (класс Computer) может быть присоединен к 0 или более

принтерам (класс Printer);

• в любой момент времени принтер соединен с 0 или 1 компьютером;

• в ходе времени конкретный принтер может использоваться многи

ми компьютерами;

• принтер может существовать, даже если не подключен ни к одному

компьютеру;

• принтер фактически не зависит от компьютера.

Композиция

Агрегация

UML определяет два типа ассоциации

Некоторые объекты тесно взаимосвязаны,

как дерево и его листья

Некоторые объекты слабо взаимосвязаны

друг с другом, как компьютер

и его периферийное оборудование

Рис. 18.2. Два типа ассоциации в UML

частьцелое, или агрегат

агрегация

Computer Printer

0..1 0..*

Рис. 18.3. Пример агрегации

18.4. Семантика агрегации 395

Агрегация – это отношение целоечасть.

Семантику агрегации можно подытожить следующим образом:

• агрегат может существовать как независимо от частей, так и вместе

с ними;

• части могут существовать независимо от агрегата;

• агрегат является в некотором смысле неполным в случае отсутст

вия некоторых частей;

• части могут принадлежать одновременно нескольким агрегатам.

Агрегация транзитивна. Рассмотрим пример на рис. 18.4. Транзитив

ность означает, что если C является частью B, и B является частью A,

тогда C также является частью A.

Агрегация транзитивна.

Агрегация асимметрична. Это означает, что объект никогда – ни пря

мо, ни косвенно – не может быть частью самого себя. Это ограничивает

способы использования агрегации в моделях. В примере на рис. 18.5 по

казано, что объекты Product могут состоять из других объектов Product.

В данном случае ошибки нет, потому что это разные объекты, и огра

ничение асимметрии не нарушено.

грегация транзитивна: если C является частью B, и B является частью A, тогда C также является частью A

AB C

Рис. 18.4. Агрегация транзитивна

рефлексивная агрегация

циклы

НЕдопустимы

a:Product

b:ProductProduct c:Product

d:Product

Рис. 18.5. Ограничение асимметрии для агрегации не нарушено, т. к. здесь

представлены разные объекты

Product

396 Глава 18. Уточнение отношений, выявленных при анализе

Агрегация асимметрична. Объект никогда не может быть частью самого

себя.

Продолжим рассмотрение рис. 18.5. Иногда может понадобиться смо

делировать ситуацию, когда между объектами d

и a существует связь,

как показано на рисунке. Такое может случиться, если объекту d

необ

ходимо осуществить обратный вызов и использовать некоторые сер

висы объектаагрегата a

. Но как это смоделировать на диаграмме клас

сов? Рефлексивная агрегация (reflexive aggregation) с классом Product

не подходит, потому что согласно ограничению асимметрии для агре

гации объект a не может быть частью самого себя ни прямо, ни косвен

но. Поэтому для обработки связи между объектами d

и a необходимо

использовать рефлексивную неуточненную ассоциацию класса Product

с самим собой, как показано на рис. 18.6.

Ассоциация симметрична. Объект может быть ассоциирован с самим

собой.

На рис. 18.7 показан другой типичный пример агрегации. Домашний

компьютер (целое) может быть смоделирован как набор частей. Эти

части довольно слабо взаимосвязаны с целым. Их можно переносить

с компьютера на компьютер или использовать совместно с другими

компьютерами, поэтому в этой модели применима семантика агрега

ции. Согласно этой модели домашний компьютер можно рассматри

вать как совокупность следующих частей: Mouse (мышь), Keyboard (кла

виатура), CPU (центральный процессор), Monitor (монитор) и два объек

та Speaker (колонка). CPU, в свою очередь, может быть смоделирован

как совокупность различных аппаратных компонентов, таких как RAM

(ОЗУ), HardDrive (жесткий диск) и т. д.

a:Product

d:Product

Product

c:Productb:Product

рефлексивная агрегация

Рис. 18.6. Связь между объектами a и d реализована посредством

рефлексивной неуточненной ассоциации

18.5. Семантика композиции 397

18.5. Семантика композиции

Композиция – более строгая форма агрегации. Она имеет сходную

(но более ограниченную) семантику. Как и агрегация, это отношение це

лоечасть, являющееся как транзитивным, так и асимметричным.

Ключевое различие между агрегацией и композицией в том, что в ком

позиции у частей нет независимой жизни вне целого. Более того, в ком

позиции каждая часть принадлежит максимум одному и только одно

му целому, тогда как при агрегации часть может совместно использо

ваться несколькими целыми.

Композиция – это строгая форма агрегации.

В примере на рис. 18.8 объекты Button (кнопка) не могут существовать

независимо от владеющего ими объекта Mouse. Если уничтожается

объект Mouse, уничтожаются и принадлежащие ему объекты Button,

потому что они являются его неотъемлемой частью. Каждый объект

Button может принадлежать только одному объекту Mouse. Так же и ли

стья на деревьях – жизнь листа определяется жизнью дерева, и лист

может принадлежать только одному дереву.

* 1..*

connectedTo

HomeComputer

1111

111

CDRomHardDriveFloppyDriveRAM GraphicsCardSoundCard

SpeakerMonitorCPUKeyboardMouse

Рис. 18.7. Типичный пример агрегации: компьютер как совокупность его частей

ButtonMouse

1 1..4

частькомпозит

всегда 0..1 или 1

композиция

Рис. 18.8. Пример композиции

398 Глава 18. Уточнение отношений, выявленных при анализе

Композит имеет исключительное право владения и ответственности

за свои части.

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

• одновременно части могут принадлежать только одному композиту –

совместное владение частями невозможно;

• композит обладает исключительной ответственностью за все свои

части; это означает, что он отвечает за их создание и уничтожение;

• композит может высвобождать части, передавая ответственность

за них другому объекту;

• в случае уничтожения композита он должен или уничтожить все

свои части, или передать ответственность за них другому объекту.

Поскольку композит обладает исключительной ответственностью за

жизненный цикл и управление своими частями, то при создании объ

ект композита часто создает и свои части. Аналогично при уничтоже

нии композита он должен уничтожить все свои части или организо

вать их передачу другому композиту.

Несмотря на то, что существуют и иерархии, и сети рефлексивной аг

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

В этом состоит еще одно отличие между агрегацией и композицией,

которое объясняется тем, что в композиции объектчасть в любой мо

мент времени может быть частью только одного композита.

18.5.1. Композиция и атрибуты

Часть композита эквивалентна атрибуту.

Рассматривая семантику композиции, можно заметить, что она очень

похожа на семантику атрибутов. Жизненный цикл в обоих случаях

контролируется владельцами. И части, и атрибуты не могут независи

мо существовать вне своих владельцев. В сущности, атрибуты – это

точный эквивалент отношения композиции между классом композита

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

и того же? На это есть две причины:

• Типом атрибута может быть простой тип данных. В некоторых гиб

ридных ОО языках программирования, таких как C++ и Java, есть

простые типы, например int и double, которые не являются класса

ми. Их можно было бы моделировать как классы, обозначенные

стереотипом «primitive», но это загромождало бы модель. Простые

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

• Существуют определенные, широко используемые утилитные клас

сы, такие как Time, Date и String. Если бы каждый раз приходилось

моделировать эти классы с помощью отношения композиции класса

18.6. Как уточнять отношения уровня анализа 399

с самим собой, очень скоро модели стали бы абсолютно непонятны

ми. Намного лучше моделировать такие классы как атрибуты.

Вывод состоит в следующем: если имеется простой тип, или утилит

ный класс, или даже класс, который не стоит явно показывать в моде

ли, поскольку он не представляет особого интереса либо от него мало

пользы, необходимо рассмотреть возможность применения атрибута,

а не отношения композиции. Здесь нет никакого конкретного и твер

дого правила, но главное, о чем надо всегда помнить, – это понятность,

полезность и удобочитаемость модели.

18.6. Как уточнять отношения уровня анализа

При анализе использовались простые ассоциации без какоголибо по

дробного рассмотрения семантики отношения (или того, каким обра

зом отношение должно быть реализовано). Однако при проектирова

нии необходимо всегда пытаться достичь максимальной конкретиза

ции и уточнить ассоциации до одного из отношений агрегации везде,

где это возможно. Фактически ассоциация должна использоваться

в проектировании, только если в противном случае в схеме агрегации

образуется цикл (см. раздел 18.4). Такая ситуация встречается редко,

поэтому большинство аналитических ассоциаций превращаются или

в агрегацию, или в композицию.

Аналитические ассоциации должны быть уточнены до одного из отно

шений агрегации везде, где это возможно.

После того как принято решение о применении агрегации или компо

зиции, необходимо действовать следующим образом:

• добавить в ассоциации кратности и имена ролей, если они отсутст

вуют;

• выбрать, какой конец ассоциации является целым, а какой – частью;

• посмотреть на кратность связи со стороны целого; если это 0..1 или 1,

вероятно, можно использовать композицию; в противном случае

должна использоваться агрегация;

• добавить возможность навигации от целого к части – ассоциации

уровня проектирования должны быть однонаправленными.

Таким образом, происходит уточнение ассоциации до агрегации или

композиции.

Если кратности целого или части больше 1, необходимо принять реше

ние, как это будет реализовываться. Это второй шаг уточнения.

400 Глава 18. Уточнение отношений, выявленных при анализе

18.7. Ассоциации одинкодному

Практически всегда ассоциация одинкодному превращается в компо

зицию. По сути, ассоциация одинкодному подразумевает настолько

строгое отношение между двумя классами, что зачастую стоит рассмот

реть возможность их объединения в один класс без нарушения правил

проектирования для проектных классов (раздел 17.5). Если классы

нельзя объединить, отношение одинкодному уточняется до компози

ции, как показано на рис. 18.9.

Обычно ассоциации одинкодному подразумевают композицию.

Также можно было бы рассмотреть возможность превращения Party

Identifier (идентификатор партии) в атрибут класса Party (партия), если

PartyIdentifier не является особо важным классом. Это, конечно, упро

щает диаграмму (рис. 18.10), но имеет и недостаток: нельзя показать

атрибуты или операции, принадлежащие классу PartyIdentifier.

18.8. Ассоциации многиекодному

В ассоциации многиекодному целое имеет кратность «много», а крат

ность части равна 1.

Party PartyIdentifier

«trace»

анализ

проектирование

Рис. 18.9. Ассоциация один+к+одному уточняется до композиции

анализ

проектирование

Party

PartyIdentifier

id:PartyIdentifier

«trace»

Рис. 18.10. Класс PartyIdentifier превращен в атрибут класса Party

18.9. Ассоциации одинBкоBмногим 401

Поскольку со стороны целого кратность равна «много», сразу понят

но, что композиции невозможна, потому что часть используется со

вместно многими целыми. Но, вероятно, возможна агрегация. Здесь

необходимо провести проверку на наличие циклов в схеме агрегации

(см. раздел 18.4). Если таковых не обнаружено, аналитическую ассо

циацию можно уточнять до агрегации, как показано на рис. 18.11.

Как видно из этого примера, один объект Currency (валюта) совместно

используется многими объектами Money (деньги). Это абсолютно верно

отражает отношение между деньгами и валютой: деньги – это сумма

в некоторой валюте. Намного более полную модель денег можно найти

в книге [Arlow 1].

Ассоциации многиекодному подразумевают агрегацию, если в схеме

агрегации нет цикла.

18.9. Ассоциации одинкомногим

В ассоциации одинкомногим со стороны части присутствует коллек+

ция объектов. Чтобы реализовать такое отношение, необходимо ис

пользовать или поддержку коллекций, предоставляемую языком реа

лизации, или классыколлекции.

Большинство ОО языков программирования имеют минимальную

встроенную поддержку коллекций объектов. В сущности, большинство

языков предлагают только массивы. Массив – это индексированная

коллекция объектных ссылок, обычно ограниченная некоторым макси

мальным размером. Преимущество встроенных массивов, как правило,

состоит в их высокой производительности. Однако это преимущество

нивелируется их малой гибкостью в сравнении с другими типами кол

лекций.

Классыколлекции обычно характеризуются намного большей мощью

и гибкостью, чем массивы. Они предлагают разнообразные семантики,

в которых массив является лишь одним из возможных вариантов. Да

лее вся глава посвящена классамколлекций.

целое часть

анализ

проектирование

Currency

Money

«trace»

Рис. 18.11. Ассоциация многие+к+одному уточняется до агрегации

402 Глава 18. Уточнение отношений, выявленных при анализе

18.10. Коллекции

Классколлекции – это класс, экземпляры которого специализируют

ся на управлении коллекциями других объектов. В большинстве язы

ков программирования есть стандартные библиотеки классовколлек

ций (и других утилит).

Классыколлекции – это классы, экземпляры которых содержат коллек

ции объектов.

Одним из ключей к отличному ОО проектированию и реализации явля

ется совершенное владение классамиколлекций. У всех таких классов

есть операции для:

• добавления объектов в коллекцию;

• удаления объектов из коллекции;

• извлечения ссылки на объект, находящийся в коллекции;

• обход коллекции, т. е. проход по коллекции от первого объекта до по

следнего.

Существует много типов коллекций, поразному обрабатывающих кол

лекции объектов. Важным аспектом ОО проектирования и реализации

является правильный выбор типа коллекции (обсуждается далее).

В качестве примера использования коллекций на рис. 18.12 показана

ассоциация одинкомногим уровня анализа, реализованная с помо

щью классаколлекции Vector. Это класс стандартной библиотеки Java

java.util. Как правило, между целым (классом Order (заказ)) и классом

Vector устанавливается отношение композиции, поскольку Vector обыч

но является всего лишь частью реализации целого и не может сущест

вовать вне него. Однако между классом Vector и его частями (OrderLine

(строка заказа)) может существовать отношение агрегации или компо

зиции. Если целое несет ответственность за жизненный цикл частей,

как в данном примере, можно использовать композицию. В противном

случае должна использоваться агрегация.

Order OrderLine

Vector

1*1

целое часть

«trace»

анализ

проектирование

Рис. 18.12. Реализация ассоциации один+ко+многим с помощью

класса+коллекции

Vector

18.10. Коллекции 403

Классыколлекции реализуют ассоциации одинкомногим.

С точки зрения моделирования с использованием коллекций сущест

вует четыре фундаментальные стратегии:

• Классколлекции моделируется явно; этот вариант представлен

на рис. 18.12. Его преимущество в чрезвычайной детализации,

однако есть и большой недостаток – загроможденность проектной

модели. Если ассоциация одинкомногим заменяется классомкол

лекции, модель быстро становится очень раздутой. Выбор класса

коллекции обычно является тактическим решением реализации,

и право это сделать можно передать программистам. Мы рекомен

дуем заменять ассоциации одинкомногим конкретными класса

миколлекций, только если выбор коллекции является стратегиче

ски важным.

• Инструментальному средству моделирования сообщается о том,

как будет реализовываться каждая конкретная ассоциация один

комногим. Многие инструменты моделирования, генерирующие

код, позволяют назначать конкретный классколлекции для каж

дой ассоциации одинкомногим. Обычно это осуществляется путем

добавления в ассоциацию помеченных значений, определяющих

свойства генерации кода для данного отношения. Этот подход ото

бражен на рис. 18.13. Здесь на соответствующем конце отношения

указано свойство {Vector}. Обратите внимание, что используется толь

ко именная часть помеченного значения – часть «значение» в дан

ном случае является излишней.

Опасайтесь «переусердствовать» при использовании коллекций.

• Путем добавления свойства к отношению определяется семантика

коллекции, но не указывается какойлибо конкретный класс реа

лизации (рис. 18.14). При использовании коллекций важно не «пе

реусердствовать». Как говорилось, фактически используемый тип

коллекции – часто тактическое, а не стратегическое решение, кото

рое может быть принято программистами во время реализации.

Order OrderLine

1 {ordered}*

Рис. 18.14. Добавление в ассоциацию свойства без указания конкретного

класса реализации

Order OrderLine

1 {Vector}*

Рис. 18.13. Добавление в ассоциацию помеченного значения