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

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 41)

Если кратность цели больше 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. Отношение многие+ко+многим2179.4. Что такое ассоциация?UML позволяет моделировать эту ситуацию с помощью классаассоциации (рис. 9.19). Важно понимать этот синтаксис: многие люди думают,что классассоциация – это всего лишь прямоугольник, свисающийс ассоциации. Но ничто не могло бы быть дальше от истины, чем это.На самом деле классассоциация – это линия ассоциации (включая всеимена ролей и кратности), пунктирная нисходящая линия и прямоугольник класса на конце пунктирной линии. Короче говоря, классассоциация – все, что входит в затемненную область (рис.

9.19).Классассоциация – это ассоциация, являющаяся еще и классом.По сути, классассоциация – это ассоциация, являющаяся еще и классом. Она не только соединяет два класса, как обычная ассоциация, онаопределяет набор характеристик, принадлежащих самой ассоциации.У классовассоциаций могут быть атрибуты, операции и другие ассоциации.Классассоциация означает, что в любой момент времени между любыми двумя объектами может существовать только одна связь.Экземпляры классаассоциации – это на самом деле связи, у которыхесть атрибуты и операции.

Уникальная идентификация этих связей определяется исключительно индивидуальностью объектов, находящихсяна каждом конце. Этот фактор ограничивает семантику классаассоциации: его можно использовать только тогда, когда между двумя объектами в любой момент времени установлена единственная уникальнаясвязь.

Это обусловлено тем, что каждая связь, которая является экземпляром классаассоциации, должна быть уникальной. На рис. 9.19 применение классаассоциации означает, что на модель накладывается следующее ограничение: для данного объекта Person и данного объекта Company может существовать только один объект Job (должность). Иначе говоря, каждый Person может занимать только одну Job в данной Company.Однако если ситуация такова, что данный объект Person может занимать несколько Job в данном объекте Company, классассоциацию использовать нельзя – семантика не соответствует!Но нам попрежнему надо кудато сохранять зарплату для каждойгруппы Company/Job/Person.

Поэтому мы материализуем (делаем реальCompany**PersonJobкласс!ассоциацияsalary:doubleРис. 9.19. Класс+ассоциациякласс!ассоциация состоит из класса,ассоциации и пунктирной линии218Глава 9. Отношения1Company*Job*1Personsalary:doubleРис. 9.20. Материализованное отношение в виде обычного классаным) отношение, представляя его в виде обычного класса. На рис.

9.20Job является обычным классом. Как видите, у Person может быть несколько Job, каждая Job в каждой конкретной Company.Материализованное отношение делает возможным существование более одной связи между любыми двумя объектами в конкретный моментвремени.Откровенно говоря, многие разработчики объектных моделей простоне понимают семантической разницы между классамиассоциациямии материализованными отношениями. Поэтому одни часто подменяются другими. Однако разница на самом деле очевидна: классыассоциации могут использоваться только в том случае, когда каждая связьимеет уникальную индивидуальность.

Надо просто запомнить, что индивидуальность связи определяется индивидуальностью объектов,располагающихся на ее концах.9.4.6. Квалифицированные ассоциацииКвалифицированные ассоциации могут использоваться для превращения ассоциации nкомногим в ассоциацию nкодному путем заданияодного объекта (или группы объектов) из целевого набора. Это оченьполезные элементы модели, поскольку они показывают, как можновести поиск или осуществлять навигацию к конкретным объектамколлекции.Рассмотрим модель, изображенную на рис. 9.21.

Объект Club (клуб)связан с набором объектов Member (член), а объект Member подобным жеобразом связан с только одним объектом Club.Club1*MembermemberId:StringРис. 9.21. Отношение один+ко+многим9.5. Что такое зависимость?219Квалифицированная ассоциация выбирает один объект из целевогонабора.Возникает следующий вопрос: как от объекта Club, связанного с набором объектов Member, перейти к одному конкретному объекту Member?Очевидно, что необходим некоторый уникальный ключ, которыйможно использовать для поиска определенного объекта Member из набора. Такой ключ называют квалификатором (qualifier).

Квалификаторы могут быть разными (имя, номер кредитной карточки, номер социальной страховки). В приведенном выше примере у каждого объекта Member есть значение атрибута memberId, уникальное для данногообъекта. Это и есть ключ поиска в данной модели.В модели такой поиск можно обозначить путем добавления квалификатора на конце ассоциации со стороны Club. Важно понимать, что этотквалификатор принадлежит концу ассоциации, а не классу Club. Этотквалификатор задает уникальный ключ и таким образом превращаетотношение одинкомногим в отношение одинкодному, как показанона рис.

9.22.ClubmemberIdквалификатор10..1заданная кратностьMembermemberId:Stringкомбинация {Club, memberId} задает уникальную цельРис. 9.22. Квалификатор превращает отношение один+ко+многимв отношение один+к+одномуКвалифицированные ассоциации – замечательный способ показать,как с помощью уникального ключа происходит выбор определенногообъекта из набора. Квалификаторы обычно ссылаются на атрибут целевого класса, но возможны и другие выражения, с помощью которыхвыбирается один объект из набора.9.5. Что такое зависимость?Зависимость обозначает отношение между двумя или более элементами модели, при котором изменение одного элемента (поставщика) может повлиять или предоставить информацию, необходимую другомуэлементу (клиенту). Иначе говоря, клиент некоторым образом зависит220Глава 9. Отношенияот поставщика.

Зависимости используются для моделирования отношений между классификаторами, когда один классификатор зависитот другого, но отношение не является ни ассоциацией, ни обобщением.В отношении зависимости клиент некоторым образом зависит от поставщика.Например, объект одного класса передается как параметр в операциюобъекта другого класса. Очевидно, что между классами этих объектовсуществует отношение некоторого рода, но это не совсем обычная ассоциация. Отношение зависимости (специализированное некоторымипредопределенными стереотипами) можно использовать как универсальное средство для моделирования данного вида отношений.

Мыуже приводили один из типов зависимостей – отношение «instantiate»,но существуют и многие другие. Общепринятые стереотипы зависимостей рассматриваются в следующих разделах.UML 2 определяет три основных типа зависимостей (табл. 9.2). Мывключили их в обсуждение для полноты информации, но в повседневном моделировании редко используется чтолибо кроме простой пунктирной стрелки зависимости. Обычно разработчики моделей не утруждают себя определением типа зависимости.Таблица 9.2ТипСемантикаUsage(Использование)Клиент использует некоторые из доступных сервисов поставщика для реализации собственного поведения; это самый распространенный тип зависимости.Abstraction(Абстракция)Обозначает отношение между клиентом и поставщиком,где поставщик более абстрактный, чем клиент.Что подразумевается под «более абстрактный»? Это может означать, что поставщик находится на другой стадииразработки, чем клиент (например, в аналитической модели, а не в проектной модели).Permission(Доступ)Поставщик предоставляет клиенту разрешение на доступк своему содержимому – это дает возможность поставщику контролировать и ограничивать доступ к своему содержимому.Зависимости также могут существовать не только между классами.Как правило, они могут устанавливаться между:• пакетами и пакетами;• объектами и классами.Зависимости могут устанавливаться между операцией и классом.

Характеристики

Список файлов книги