2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 29
Текст из файла (страница 29)
Расширенные связиВ этой главе:Расширенные связи: зависимости, обобщения, ассоциации,реализации и уточненияМоделирование систем связейСоздание систем связейМоделируя сущности, формирующие словарь вашей системы, выдолжны также показать, как эти сущности связаны друг с другом.Связи, однако, могут быть достаточно сложными. Визуализация,специфицирование, конструирование и документирование системсвязей требуют ряда расширенных свойств.Зависимости, обобщения и ассоциации – наиболее важныестроительные блоки связей в UML.
Эти связи обладают множеством свойств помимо тех, что уже были описаны в предыдущейчасти. Также вы можете моделировать множественное наследование, навигацию, композицию, уточнение и другие характеристики.Используя четвертый вид связей – реализацию, можно моделировать соединение между интерфейсом и классом или компонентомлибо между вариантом использования и кооперацией.
UML допускает моделирование семантики связей на любом уровне формальности.Управление сложными системами связей требует использования правильных связей на правильном уровне детализации, чтобыне имело место ни чрезмерное упрощение, ни излишнее усложнение вашей системы.ВведениеВариантыиспользованияи сценарииобсуждаются в главе 17.Когда вы проектируете дом, важно определить, как будут располагаться комнаты по отношению друг к другу. Скажем, вы решаетепоместить главную ванную комнату на первом этаже, подальше отфасада дома.
Дальше надлежит продумать общий план расположения комнат (например, учесть необходимость вноса продуктов из гаража на кухню: было бы неразумно, если бы на этом пути151пришлось проходить через ванную, поэтому такой вариант вы отвергнете).Можно составить достаточно подробный план дома, простоучитывая эти основные связи и варианты использования. Однакоесли не учитывать в проекте более сложных связей, в конце концоввы столкнетесь с серьезными трудностями. Допустим, вас вполнеустраивает расположение комнат на каждом этаже, но комнаты наразных этажах соседствуют неудачно. В частности, комнату вашейдочери вы поместили прямо над своей ванной, а девочка учится играть на барабане. Понятно, что изначальную схему придется пересмотреть.Аналогичным образом вы должны установить, как скрытые механизмы дома (коммуникации, проводка, несущие конструкциии т.п.) могут повлиять на поэтажный план.
Так, например, стоимость конструкции значительно возрастет, если вы не разместитекомнаты таким образом, чтобы они имели общие стены, в которыхможно проложить трубы и водостоки.ПрямоеТо же самое происходит, когда вы создаете программное обеси обратноепечение. Зависимости, обобщения и ассоциации – наиболее общиепроектиросвязи, с которыми вы сталкиваетесь при моделировании програмвание обсуж- мных систем, но вам понадобится немало расширенных средствдаютсядля описания таких связей. В результате вам удастся охватить элев главах 8,менты многих систем, что позволит избежать недоработок в ди14, 18, 19, 20, зайне.25, 30 и 31.С этой целью UML обеспечивает представление множества дополнительных свойств (рис.
10.1). Данная нотация позволяет вамвизуализировать, специфицировать и документировать системысвязей на любом уровне детализации по вашему желанию, – дажедостаточном для осуществления прямого и обратного проектирования моделей и кода.направление ассоциации«interface»Connectabledisconnect()«permit»disconnect()зависимость со стереотипомРис. 10.1. Расширенные связиРасширенные связи152Базовые понятияСвязь – это соединение сущностей. В объектноFориентированноммоделировании существуют четыре наиболее важных типа связей:зависимости, обобщения, ассоциации и реализации. Связи изображаются линиями разного начертания.ЗависимостиБазовыесвойства зависимостейобсуждаются в главе 5.МеханизмырасширенияUML обсуждаютсяв главе 6.Диаграммыклассовобсуждаютсяв главе 8.Зависимость – это связь использования, указывающая, что изменение спецификаций одной сущности, например класса SetTopController(УстановитьВерхнийКонтроллер) на рис.
10.1, может повлиятьна другие сущности, которые используют ее, например на классChannelIterator (ИтераторКанала, – но не наоборот. Зависимостьизображается в виде пунктирной линии со стрелкой, направленнойк той сущности, от которой зависит еще одна. Применяйте зависимости, когда хотите показать, что некая сущность использует другую.Простая, без дополнений, связь зависимости встречается чащевсего. Однако, если вы хотите подчеркнуть некие смысловые оттенки, UML предоставляет вам набор стереотипов, которые могут бытьприложены к связи зависимости. Имеющиеся стереотипы можноразделить на несколько групп.ВоFпервых, есть стереотип, который касается связей зависимости между классами и объектами на диаграмме классов:1. bind – показывает, что исходный объект создает экземплярцелевого, используя заданные реальные параметры.Используйте bind, когда нужно уточнить подробности, касаюШаблоныщиеся шаблонных классов.
Например, связь между шаблонными зависиконтейнерным классом и экземпляром этого класса должна момость bindделироваться зависимостью bind. Она включает список действиобсуждают- тельных аргументов, соответствующих формальным аргументамся в главе 9.шаблона.2. derive – показывает, что источник может быть вычисленпо цели.Использовать derive следует при моделировании связи междуАтрибутыобсуждают- двумя атрибутами или двумя ассоциациями, одна из которых конкся в главах 4 ретна, а вторая – концептуальна. Например, класс Person (Человек)и 9, ассоциа- может иметь конкретный атрибут BirthDate (ДатаРождения), а такжеции – в главе атрибут Age (Возраст), который происходит от BirthDate, поэтомуне объявлен отдельно в классе. Связь между BirthDate и Age выража5 и нижев настоящей ется зависимостью derive, то есть Age выводится из BirthDate.главе.3.
permit – показывает, что источник имеет заданную видимостьдля цели.Базовые понятияЗависимости типаpermit обсуждаютсяв главе 5.153Такая зависимость пригодится вам, если вы захотите обеспечить классу доступ к закрытым свойствам другого класса. В C++для этих же целей предусмотрены классыFдрузья (friends).4. instanceOf – показывает, что исходный объект является экземпляром целевого.
Обычно отображается в текстовой нотации вида исходный объект : Целевой объект.5. instantiate – показывает, что источник создает экземплярыцели.ДихотомияДва последних стереотипа позволяют вам явно моделировать«класс/объ- связи «класс/объект». Можно использовать instanceOf при моделироект» обсуж- вании связи между классом и объектом на одной и той же диаграмдаютсяме либо связи между классом и его метаклассом; однако последняяв главе 2.обычно отображается в текстовом синтаксисе.
Стереотип instantiateсвидетельствует о том, что один класс создает объекты другого.Логическоемоделирование базданныхобсуждаетсяв главе 8, моделированиефизическихбаз данных –в главе 30.Пакетыобсуждаютсяв главе 12.6. powertype – сообщает, что целевой объект является супертипом исходного. Супертип – это классификатор, объектыкоторого являются дочерними по отношению к заданномуродительскому.Следует использовать powertype, когда нужно моделировать теклассы, которые по отношению к другим являются классификаторами (как иногда бывает при моделировании баз данных).7. refine – показывает, что источник находится на более тонкомуровне абстракции, чем цель.Используется при моделировании классов, представляющиходно и то же понятие на разных уровнях абстракции.
Например,в процессе анализа вы можете определить класс Customer (Покупатель), который в процессе проектирования будет уточнен до болеедетализированного класса Customer и завершен реализацией.8. use – специфицирует, что семантика исходного элемента зависит от семантики открытой части целевого.Применяйте use, когда хотите явно обозначить зависимость каксвязь использования, в противовес прочим значениям зависимостей, представленным в стереотипах.Упомянем два стереотипа, касающихся связей зависимости между пакетами:1. import – показывает, что открытое содержимое целевого пакета входит в открытое пространство имен исходного пакета,как если бы они были декларированы в исходном;2.
access – показывает, что открытое содержимое целевого пакета входит в закрытое пространство имен исходного. Неквалифицированные имена могут применяться внутри исходного, но не могут реэкспортироваться.154Вариантыиспользования обсуждаютсяв главе 17.Расширенные связиБазовые понятияИспользуйте import и access, когда захотите задействовать элементы, объявленные в других пакетах. Импорт элементов позволяет отказаться от применения полных квалифицированных имендля ссылок на элементы других пакетов в текстовых выражениях.Два стереотипа относятся к связям использования между вариантами использования:нюансы зависимостей, каждая из которых наделена своейсобственной семантикой, но не настолько семантическиудалена от обычной зависимости, чтобы представлять ее какособый вид связи.
В какомQто смысле это не очень отвечаетидеологии UML, но опыт показывает, что подобный подходпозволяет достичь баланса в определении важных видов связей, с которыми вы можете столкнуться и избежанием избыточного числа вариантов выбора для разработчика модели.Вы не ошибетесь, если сначала смоделируете обобщения,ассоциации и реализации, а все остальные виды связей обозначите зависимостями.1.
extend – показывает, что целевой вариант использования расширяет поведение исходного;2. include – показывает, что исходный вариант использованияявно включает в себя поведение другого варианта использования в месте, указанном в исходном.Используйте extend и include, а также простое обобщение, когдавам требуется выполнить декомпозицию вариантов использованияна повторно использ уемые части.ИнтерфейсыОдин из стереотипов вы будете встречать в контексте взаимообсуждают- действия объектов:ся в главе 16. send – показывает, что исходный класс посылает сообщениецелевому.Машинысостояний(конечныеавтоматы)обсуждаются в главе 22.Системыи моделиобсуждаютсяв главе 32.Используйте send, когда вам предстоит смоделировать операцию(такую как действие, связанное с переходом между состояниями),передающую данное событие целевому объекту, который, в своюочередь, может иметь ассоциированный конечный автомат.
Зависимость send позволяет вам эффективно связать друг с другом дванезависимых автомата.И наконец, еще один стереотип вы встретите в контексте организации элементов вашей системы в подсистемы и модели:Пять представленийархитектуры обсуждаютсяв главе 2.Используйте trace, когда нужно смоделировать связи между элементами различных моделей. Например, в контексте архитектурысистемы вариант использования в модели вариантов использования,представляющий функциональное требование, может трассироваться в пакет соответствующей модели дизайна, представляющей артефакты, которые реализуют данный вариант использования.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
