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

Многие инструменты моделирования, генерирующиекод, позволяют назначать конкретный классколлекции для каждой ассоциации одинкомногим. Обычно это осуществляется путемдобавления в ассоциацию помеченных значений, определяющихсвойства генерации кода для данного отношения. Этот подход отображен на рис. 18.13. Здесь на соответствующем конце отношенияуказано свойство {Vector}. Обратите внимание, что используется только именная часть помеченного значения – часть «значение» в данном случае является излишней.Order1{Vector}*OrderLineРис. 18.13.

Добавление в ассоциацию помеченного значенияОпасайтесь «переусердствовать» при использовании коллекций.•Путем добавления свойства к отношению определяется семантикаколлекции, но не указывается какойлибо конкретный класс реализации (рис. 18.14). При использовании коллекций важно не «переусердствовать». Как говорилось, фактически используемый типколлекции – часто тактическое, а не стратегическое решение, которое может быть принято программистами во время реализации.Order1{ordered}*OrderLineРис.

18.14. Добавление в ассоциацию свойства без указания конкретногокласса реализации404Глава 18. Уточнение отношений, выявленных при анализеЭтот вариант хорош тем, что сохраняется лаконичность модели,и программистам могут быть предоставлены подсказки по поводутого, какой классколлекции должен использоваться.

Однако такой подход обычно исключает автоматическую генерацию кода.•Уточнением отношения одинкомногим до классовколлекций незанимаются – решение этой задачи передается программистам.UML предоставляет стандартные свойства, которые могут применяться к кратностям для обозначения требуемой семантики коллекции.Они представлены в табл. 18.1.Упорядоченность определяет, как располагаются элементы в коллекции: в строгом порядке относительно друг друга или нет. Уникальность определяет единичность каждого объекта коллекции. Для отношения одинкомногим по умолчанию применяется семантика {unordered, unique} ({неупорядоченный, уникальный}).Таблица 18.1Стандартное свойство Семантика{ordered}Существует строгий порядок расположения элементов коллекции.{unordered}Элементы в коллекции располагаются в произвольном порядке.{unique}Все элементы коллекции уникальны – один и тот жеобъект появляется в коллекции максимум один раз.{nonunique}В коллекции допускается дублирование элементов.Например, если необходима упорядоченная коллекция объектов OrderLines, то изображенное на рис.

18.13 можно показать, как представлено на рис. 18.14.Сочетания свойств упорядочения и уникальности создают набор коллекций, перечисленных в табл. 18.2. Эти коллекции являются частьюOCL (объектный язык ограничений) (см. главу 25), хотя аналогичныйнабор коллекций есть во всех языках программирования.Таблица 18.2СвойствоКоллекция OCL{unordered, nonunique}Bag (мультимножество){unordered, unique}Set (множество){ordered, unique}OrderedSet (упорядоченное множество){ordered, nonunique}Sequence (последовательность)40518.10. Коллекции18.10.1.

КартаКарты оптимизированы с целью быстрого получения значения по ключу.Еще один очень полезный тип класса коллекции – карта (map). Иногдаего называют словарем (dictionary).1 Эти классы немного похожи натаблицу базы данных с двумя столбцами – ключ и значение. Картыспроектированы таким образом, чтобы по заданному ключу можно было быстро найти соответствующее значение.

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

Они оптимизированы так, чтобы быстро находить объектзначение по заданному объектуключу.m:HashMapkey1node1value1key2node2value2key3node3value3Рис. 18.15. Пример картыНа рис. 18.15 показано упрощенное представление Javaкласса HashMap.Поиск значения (по заданному ключу) осуществляется очень быстро, поскольку коллекция проиндексирована с использованием хештаблицы.В UML нет стандартного свойства для обозначения карты, и карты неявляются частью OCL. Если в проектной модели необходимо обозначитьприменение карты, указывается конкретный тип коллекции (например, {HashMap}) или используется следующее помеченное значение:{map имяКлюча}Если принято решение использовать это нестандартное обозначение,в модель необходимо добавить поясняющее примечание!1Еще известно как «ассоциативный массив».

– Примеч. науч. ред.406Глава 18. Уточнение отношений, выявленных при анализе18.11. Конкретизированные отношенияНекоторые типы отношений являются исключительно артефактамианализа и не поддерживаются напрямую ни одним из широко используемых ОО языков программирования. Процесс реализации таких отношений уровня анализа называют конкретизацией (reification) (т. е.превращение в нечто конкретное). Конкретизации подвергаются следующие отношения уровня анализа:•ассоциации многиекомногим;•двунаправленные ассоциации;•классыассоциации.18.11.1. Ассоциации многиекомногимНи один из широко используемых ОО языков программирования неподдерживает напрямую ассоциации многиекомногим (хотя некоторые объектные базы данных всетаки их поддерживают).

Поэтому этиассоциации необходимо конкретизировать в обычные классы, отношения агрегации, композиции и зависимости. При анализе такие вопросы, как владение и навигация, могли бы оставаться неясными, нов проектировании такая неопределенность невозможна. Это тот случай, когда сначала надо решить, какая из сторон ассоциации многиекомногим является целым, а затем применять соответственно агрегацию или композицию.В примере на рис. 18.16 отношение allocation (распределение) былоконкретизировано в класс Allocation.

Это превращает ассоциацию многиекомногим в два отношения агрегации. Исходя из требований,предъявляемых к системе, было принято решение, что Resource (ресурс) – это целое. Система главным образом занимается управлениемпотоками работ, ассоциированными с Resource, т. е. является ресурсоцентричной. Однако если бы система была задачецентричной, целымбыл бы сделан объект Task (задача), что изменило бы направление отношений, представленных на рисунке.Было также решено возложить ответственность за жизненный циклобъектов Allocation на Resource, и поэтому используется отношение композиции.анализTaskallocation**Resource«trace»1проектированиеTask**Allocation1ResourceРис.

18.16. Ассоциация многие+ко+многим конкретизирована в класс Allocation40718.11. Конкретизированные отношенияЕсли система пытается представить обе точки зрения, ее можно былобы назвать ориентированной на распределение ресурсов. Тогда был бывведен новый объект (возможно, AllocationManager (менеджер распределения)), обслуживающий список объектов Allocation, каждый объекткоторого указывает как на объект Resource, так и на объект Task.18.11.2. Двунаправленные ассоциацииЧасто необходимо смоделировать обстоятельства, в которых объект акласса А использует сервисы объекта b класса В, и объекту b необходимо делать обратный вызов и использовать сервисы объекта а.

В качестве примера можно привести элемент управления GUI Window с однимили более объектами Button, где каждому объекту Button надо выполнять обратный вызов и использовать сервисы Window, которому онипринадлежат.При анализе все просто – такая ситуация моделируется как единственная двунаправленная ассоциация. Однако ни один из широко используемых ОО языков программирования реально не поддерживает двунаправленные ассоциации. Поэтому при проектировании такая ассоциация должна быть конкретизирована в две однонаправленные ассоциации или зависимости, как показано на рис.

18.17.При моделировании обратных вызовов необходимо помнить об асимметрии агрегации и композиции – объект никогда – ни прямо, ни косвенно – не может быть частью самого себя. Это значит, что если класс Аимеет отношение агрегации или композиции с классом В, обратныйвызов от В к А должен быть смоделирован как неконкретизированнаяассоциация.