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

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

PDF-файл Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 43, который располагается в категории "книги и методические указания" в предмете "объектно-ориентированный анализ и проектирование" изседьмого семестра. Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 43 - СтудИзба 2019-09-18 СтудИзба

Описание файла

PDF-файл из архива "Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование", который расположен в категории "книги и методические указания". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из седьмого семестра, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .

Просмотр PDF-файла онлайн

Текст 43 страницы из PDF

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(Доступ)Поставщик предоставляет клиенту разрешение на доступк своему содержимому – это дает возможность поставщику контролировать и ограничивать доступ к своему содержимому.Зависимости также могут существовать не только между классами.Как правило, они могут устанавливаться между:• пакетами и пакетами;• объектами и классами.Зависимости могут устанавливаться между операцией и классом.

Ноэти отношения довольно редко отображаются на диаграммах, поскольку это приводит к слишком большому уровню детализации. Не2219.5. Что такое зависимость?клиентпоставщикClassDfoo ()«permit»клиент«use»ClassAзависимость от операциик классуClassC«instantiate»:ClassAРис. 9.23. Типы зависимостейкоторые примеры различных типов зависимостей приведены нарис. 9.23.

Они обсуждаются в оставшихся разделах данной главы.Чаще всего для обозначения зависимости используется обычная пунктирная линия со стрелкой без указания типа зависимости. По сути,тип зависимости часто понятен и без стереотипа – из контекста. Еслиже возникает желание или необходимость конкретизировать тип зависимости, UML определяет целый ряд стандартных стереотипов.9.5.1. Зависимости использованияСуществует пять зависимостей использования: «use», «call», «parameter», «send» и «instantiate», каждая из которых рассматривается в следующих подразделах.9.5.1.1.

Зависимость «use»Самым распространенным стереотипом зависимости является «use»,который просто обозначает, что клиент какимто образом используетпоставщика. Если на диаграмме указана просто пунктирная линия сострелкой зависимости без стереотипа, можно быть совершенно уверенным, что подразумевается зависимость «use».На рис. 9.24 показаны два класса, А и В, между которыми установленоотношение зависимости «use».

Эта зависимость генерируется любойиз следующих ситуаций.1. Операции класса A необходим параметр класса B.2. Операция класса A возвращает значение класса B.клиентAfoo(b:B)bar( ):BdoSomething( )«use»поставщикBстереотип частоопускаетсяРис. 9.24. Два класса с отношением зависимости типа «use»222Глава 9. Отношения3. Операция класса A гдето в своей реализации использует объекткласса B, но не в качестве атрибута.Варианты 1 и 2 довольно просты, а вот вариант 3 представляет большийинтерес. Такая ситуация возможна, если одна из операций класса Асоздала временный объект класса В.

Ниже приводится фрагмент Javaкода для этого случая:class A{...void doSomething(){B myB = new B();// используем myB некоторым образом...}}Хотя одна зависимость «use» может использоваться как универсальнаядля всех трех перечисленных случаев, есть и другие, более специализированные стереотипы зависимостей, которые можно было бы применить.Ситуации 1 и 2 можно более точно смоделировать с помощью зависимости «parameter», а ситуацию 3 – с помощью зависимости «call». Однакоот UMLмодели не часто требуется такой уровень детализации, и большинство разработчиков моделей считают, что намного понятней и проще просто устанавливать между соответствующими классами зависимость «use», как показано выше.9.5.1.2. Зависимость «call»Зависимость «call» (вызов) устанавливается между операциями – операцияклиент вызывает операциюпоставщик.

Этот тип зависимостив UMLмоделировании используется не очень широко. Он применяется на уровне детализации, более глубоком, чем тот, на который большинство разработчиков готовы пойти. Кроме того, в настоящее времяочень немногие средства моделирования поддерживают зависимостимежду операциями.9.5.1.3.

Зависимость «parameter»Поставщик является параметром операции клиента.9.5.1.4. Зависимость «send»Клиент – это операция, посылающая поставщика (который должен бытьсигналом) в некоторую неопределенную цель. Сигналы рассматриваются в разделе 15.6, а пока будем представлять их как особые типы классов, используемые для передачи данных между клиентом и целью.9.5. Что такое зависимость?2239.5.1.5. Зависимость «instantiate»Клиент – это экземпляр поставщика.9.5.2. Зависимости абстракцииЗависимости абстракции моделируют зависимости между сущностями, находящимися на разных уровнях абстракции. В качестве примера можно привести класс аналитической модели и тот же класс в проектной модели.

Существует четыре зависимости абстракции: «trace»,«substitute», «refine» и «derive».9.5.2.1. Зависимость «trace»Зависимость «trace» часто используется, чтобы проиллюстрировать отношение, в котором поставщик и клиент представляют одно понятие,но находятся в разных моделях. Например, поставщик и клиент могутнаходиться на разных стадиях разработки. Поставщик мог бы бытьаналитическим представлением класса, а клиент – более детальнымпроектным представлением. Также «trace» можно использовать, чтобыпоказать отношение между функциональным требованием, таким как«банкомат должен обеспечивать возможность снятия наличных денегвплоть до достижения кредитного лимита карты», и прецедентом,поддерживающим это требование.9.5.2.2.

Зависимость «substitute»Зависимость «substitute» (заместить) показывает, что клиент во времявыполнения может заменять поставщика. Замещаемость основывается на общности контрактов и интерфейсов клиента и поставщика, т. е.они должны предоставлять один и тот же набор сервисов. Обратитевнимание, что замещаемость не достигается посредством отношенийспециализации/обобщения между клиентом и поставщиком (специализация/обобщение обсуждаются в разделе 10.2).

В сущности, «substitute» специально разработана для использования в средах, не поддерживающих специализации/обобщения.9.5.2.3. Зависимость «refine»Тогда как зависимость «trace» устанавливается между элементами разных моделей, «refine» (уточнить) может использоваться между элементами одной и той же модели. Например, в модели может быть две версии класса, одна из которых оптимизирована по производительности.Поскольку оптимизация производительности является разновидностью уточнения, это отношение между двумя классами можно смоделировать как зависимость «refine» с примечанием, описывающим сутьуточнения.224Глава 9. Отношения9.5.2.4.

Зависимость «derive»Стереотип «derive» (получить) используется, когда необходимо явно показать возможность получения одной сущности как производнойот другой. Например, в имеющемся классе BankAccount есть список Transaction (транзакция), в котором каждая Transaction содержит Quantity(количество) денег. По требованию всегда можно вычислить текущийбаланс, суммируя Quantity по всем Transaction. Существует три способапоказать, что balance (баланс) счета (его Quantity) может быть производной сущностью. Они приведены в табл. 9.3.Таблица 9.3МодельBankAccountОписание10..*Transaction11«derive»balance 1BankAccount10..*1QuantityTransaction111/balance 1BankAccount/balance:Quantity10..*QuantityTransaction11QuantityКласс BankAccount имеет «derive» ассоциацию с Quantity, где Quantity играетроль баланса банковского счета.Эта модель подчеркивает, что balanceявляется производным от коллекции Transaction класса BankAccount.В данном случае в имени роли используется слэш, чтобы показать,что между BankAccount и Quantity установлено отношение «derive».Такое обозначение менее явное, поскольку не показывает, производным чего является balance.Здесь balance показан как производный атрибут, что обозначено слэшем, предваряющим имя атрибута.Это самое краткое выражение зависимости «derive».Все перечисленные способы обозначения балансов как производныхсущностей эквивалентны, хотя первая модель в табл.

9.3 являетсянаиболее явной. Мы предпочитаем явные модели.9.5.3. Зависимости доступаЗависимости доступа выражают способность доступа одной сущностик другой. Существует три зависимости доступа: «access», «import»и «permit».9.5.3.1. Зависимость «access»Зависимость «access» (доступ) устанавливается между пакетами. В UMLпакеты используются для группировки сущностей. Самое главное9.6. Что мы узнали225здесь то, что «access» разрешает одному пакету доступ ко всему открытому содержимому другого пакета.

Однако каждый пакет определяетпространство имен, и с установлением отношения «access» пространства имен остаются изолированными. Это означает, что элементы клиентского пакета должны использовать имена путей (pathnames), когдахотят обратиться к элементам пакетапоставщика. Более подробноеобсуждение данного вопроса представлено в глОднако иве 11.9.5.3.2. Зависимость «import»Зависимость «import» концептуально аналогична «access», за исключением того, что пространство имен поставщика объединяется с пространством имен клиента. Это обеспечивает возможность элементамклиента организовывать доступ к элементам поставщика без необходимости указывать в именах элементов имя пакета. Однако иногда этоможет приводить к конфликтам имен, если имена элемента клиентаи элемента поставщика совпадают.

Свежие статьи
Популярно сейчас