UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Рис. 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 A B B Рис. 9.15. Стиль 3 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. = псевдоатрибут атрибут Address House House address address:Address 1 1 Рис. 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 * * 1 1 Рис. 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» |