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

Аналогично при уничтожении композита он должен уничтожить все свои части или организовать их передачу другому композиту.Несмотря на то, что существуют и иерархии, и сети рефлексивной агрегации, для рефлексивной композиции возможны только иерархии.В этом состоит еще одно отличие между агрегацией и композицией,которое объясняется тем, что в композиции объектчасть в любой момент времени может быть частью только одного композита.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.анализParty11PartyIdentifier«trace»1проектирование1PartyPartyIdentifierРис. 18.9.

Ассоциация один+к+одному уточняется до композицииОбычно ассоциации одинкодному подразумевают композицию.Также можно было бы рассмотреть возможность превращения PartyIdentifier (идентификатор партии) в атрибут класса Party (партия), еслиPartyIdentifier не является особо важным классом. Это, конечно, упрощает диаграмму (рис. 18.10), но имеет и недостаток: нельзя показатьатрибуты или операции, принадлежащие классу PartyIdentifier.анализParty11PartyIdentifier«trace»проектированиеPartyid:PartyIdentifierРис. 18.10.

Класс PartyIdentifier превращен в атрибут класса Party18.8. Ассоциации многиекодномуВ ассоциации многиекодному целое имеет кратность «много», а кратность части равна 1.40118.9. Ассоциации одинBкоBмногимцелоеанализMoneyчасть*1Currency«trace»проектированиеMoney*1CurrencyРис. 18.11. Ассоциация многие+к+одному уточняется до агрегацииПоскольку со стороны целого кратность равна «много», сразу понятно, что композиции невозможна, потому что часть используется совместно многими целыми. Но, вероятно, возможна агрегация.

Здесьнеобходимо провести проверку на наличие циклов в схеме агрегации(см. раздел 18.4). Если таковых не обнаружено, аналитическую ассоциацию можно уточнять до агрегации, как показано на рис. 18.11.Как видно из этого примера, один объект Currency (валюта) совместноиспользуется многими объектами Money (деньги). Это абсолютно верноотражает отношение между деньгами и валютой: деньги – это суммав некоторой валюте. Намного более полную модель денег можно найтив книге [Arlow 1].Ассоциации многиекодному подразумевают агрегацию, если в схемеагрегации нет цикла.18.9.

Ассоциации одинкомногимВ ассоциации одинкомногим со стороны части присутствует коллек+ция объектов. Чтобы реализовать такое отношение, необходимо использовать или поддержку коллекций, предоставляемую языком реализации, или классыколлекции.Большинство ОО языков программирования имеют минимальнуювстроенную поддержку коллекций объектов. В сущности, большинствоязыков предлагают только массивы. Массив – это индексированнаяколлекция объектных ссылок, обычно ограниченная некоторым максимальным размером. Преимущество встроенных массивов, как правило,состоит в их высокой производительности. Однако это преимуществонивелируется их малой гибкостью в сравнении с другими типами коллекций.Классыколлекции обычно характеризуются намного большей мощьюи гибкостью, чем массивы.

Они предлагают разнообразные семантики,в которых массив является лишь одним из возможных вариантов. Далее вся глава посвящена классамколлекций.402Глава 18. Уточнение отношений, выявленных при анализе18.10. КоллекцииКлассколлекции – это класс, экземпляры которого специализируются на управлении коллекциями других объектов.

В большинстве языков программирования есть стандартные библиотеки классовколлекций (и других утилит).Классыколлекции – это классы, экземпляры которых содержат коллекции объектов.Одним из ключей к отличному ОО проектированию и реализации является совершенное владение классамиколлекций. У всех таких классовесть операции для:• добавления объектов в коллекцию;• удаления объектов из коллекции;• извлечения ссылки на объект, находящийся в коллекции;• обход коллекции, т. е. проход по коллекции от первого объекта до последнего.Существует много типов коллекций, поразному обрабатывающих коллекции объектов.

Важным аспектом ОО проектирования и реализацииявляется правильный выбор типа коллекции (обсуждается далее).В качестве примера использования коллекций на рис. 18.12 показанаассоциация одинкомногим уровня анализа, реализованная с помощью классаколлекции Vector. Это класс стандартной библиотеки Javajava.util. Как правило, между целым (классом Order (заказ)) и классомVector устанавливается отношение композиции, поскольку Vector обычно является всего лишь частью реализации целого и не может существовать вне него.

Однако между классом Vector и его частями (OrderLine(строка заказа)) может существовать отношение агрегации или композиции. Если целое несет ответственность за жизненный цикл частей,как в данном примере, можно использовать композицию. В противномслучае должна использоваться агрегация.целоеOrderанализчасть1*OrderLine«trace»1проектированиеOrder11*VectorРис. 18.12. Реализация ассоциации один+ко+многим с помощьюкласса+коллекции VectorOrderLine40318.10. КоллекцииКлассыколлекции реализуют ассоциации одинкомногим.С точки зрения моделирования с использованием коллекций существует четыре фундаментальные стратегии:• Классколлекции моделируется явно; этот вариант представленна рис.

18.12. Его преимущество в чрезвычайной детализации,однако есть и большой недостаток – загроможденность проектноймодели. Если ассоциация одинкомногим заменяется классомколлекции, модель быстро становится очень раздутой. Выбор классаколлекции обычно является тактическим решением реализации,и право это сделать можно передать программистам. Мы рекомендуем заменять ассоциации одинкомногим конкретными классамиколлекций, только если выбор коллекции является стратегически важным.• Инструментальному средству моделирования сообщается о том,как будет реализовываться каждая конкретная ассоциация одинкомногим.