2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 30
Текст из файла (страница 30)
trace – показывает, что целевой элемент является историческим предшественником исходного (иначе говоря, тем жеэлементом, но на ранней стадии разработки).На заметку. Все связи, включая обобщение, ассоциациюи реализацию, являются концептуальными разновидностями зависимостей. Обобщение, ассоциация и реализация обладают довольно важной семантикой, достаточнойдля того, чтобы трактовать их как различные виды связейв UML.
Перечисленные выше стереотипы отражают тонкие155ОбобщенияОсновныесвойстваобобщенийобсуждаются в главе 5.Обобщение – это связь общего классификатора, называемогосуперклассом или родителем, и более конкретного, называемогоподклассом или дочерним классом. Например, у вас могут бытьобщий класс Window (Окно) и более конкретный – MultiPanelWindow(МногофорточноеОкно). Если установлена связь обобщения от дочернего к родительскому классу, то первый (MultiPanelWindow) унаследует всю структуру и поведение второго (Window).
Притом дочерний класс может в дополнение к этому представить новуюструктуру и поведение или даже переопределить поведение родителя. В связи обобщения экземпляры потомка могут быть использованы везде, где применимы экземпляры родителя – это означает,что экземпляр потомка может быть подставлен вместо экземплярародителя.В большинстве случаев вам будет достаточно одиночного наследования. О классе, который имеет только одного родителя, говорят, что он использует одиночное наследование.
Однако бывают случаи, когда один класс включает в себя аспекты множествадругих – тогда лучше смоделировать эти связи множественнымнаследованием. В качестве примера рассмотрим рис. 10.2, гдепоказан набор классов, составляющих приложение финансовыхуслуг. У класса Asset (Активы) три потомка: BankAccount (БанковскийСчет), RealEstate (Недвижимость) и Security (ЦенныеБумаги).Два из них – BankAccount и Security – имеют своих собственных потомков. Так, Stock (Акция) и Bond (Облигация) – дочерние классыSecurity.Дочерние классы BankAccount и RealEstate наследуют от множествародителей.
Например, RealEstate – это разновидность как Asset, таки InsurableItem (ОбъектСтрахования), а BankAccount – разновидностьAsset, InterestBearingItem (ОбъектНачисленияПроцентов), и InsurableItem.156Расширенные связиРис. 10.2. Множественное наследованиеНекоторые суперклассы используются только для того, чтобыдобавить, как правило, поведение и иногда – структуру к классам, которые наследуют свою основную структуру от обычных суперклассов. Эти дополнительные классы называются примесями (mixins);они не могут применяться автономно, всегда выступая в качестведобавочных суперклассов в связи множественного наследования.Например, InterestBearingItem и InsurableItem на рис.
10.2 – примеси.На заметку. Применяйте множественное наследование осторожно: вы можете столкнуться с проблемами, если дочернийкласс имеет нескольких родителей, структура и поведение которых перекрываются. Во многих случаях множественное наследование может быть заменено делегацией, когда дочернийкласс наследует только от одного родителя, а затем посредством агрегации перенимает структуру и поведение второстепенных родителей. Например, вместо специализации классаVehicle (Транспорт), с одной стороны, по принципу LandVehicle(НаземныйТранспорт), WaterVehicle (ВодныйТранспорт) и AirVehicle (ВоздушныйТранспорт), а с другой, по принципу GasPowered(НаГазовойЭнергии), WindPowered (НаВетровойЭнергии) и MusclePowered (НаМускульнойЭнергии), допустите, чтобы класс Vehicleсодержал в виде составной части meansOfPropulsion (движущаяСила).
Главный недостаток данного подхода в том, что для такихвторостепенных родителей утрачивается семантика подстановки.МеханизмырасширенияUML обсуждаютсяв главе 6.Простой, без дополнений, связи обобщения будет достаточнов большинстве случаев наследования, с которыми вы столкнетесь.Однако если вы хотите подчеркнуть тонкие смысловые оттенки,на помощь приходят существующие в UML ограничения, которыемогут быть наложены на связи обобщения:Базовые понятия1571. complete – показывает, что все д очерние классы в обобщенииспецифицированы в модели (хотя некоторые могут бытьне указаны на диаграмме) и никакие дополнительные дочерние классы не допускаются;2.
incomplete – показывает, что не все дочерние классы в обобщенииспецифицированы в модели (даже если некоторые и пропущены) и допускается создание дополнительных дочерних классов.Если только не указано иное, вы можете предполагать, что любаяОбщиедиаграмма показывает только частичное представление структурысвойстванаследования – остальная часть пропущена. Однако это не имеетдиаграммобсуждают- отношения к завершенности модели. В частности, ограничение complete следует использовать, когда вы хотите явно показать, что иеся в главе 7.рархия наследования в модели показана полностью (хотя вполневозможно, что ни одна диаграмма не отражает всю иерархию целиком).
Ограничение incomplete позволяет явно указать, что вы не устанавливаете полную иерархию в модели (хотя одна диаграмма может показать все, что в этой модели есть).3. disjoint – означает, что объект родительского класса может принадлежать только одному типу классовFпотомков. Например,класс Person (Человек) может быть специализирован путемсоздания disjointFклассов Man (Мужчина) и Woman (Женщина).4. overlapping – означает, что объект родительского класса можетпринадлежать нескольким типам классовFпотомков. И подклассы именно перекрывающиеся. Например, класс Vehicle(Транспорт) может быть специализирован путем созданияподклассов LandVehicle (НаземныйТранспорт) и WaterVehicle(ВодныйТранспорт); автомобильFамфибия относится к обоим.Типы и инПоследние два ограничения относятся только к ситуациям мнотерфейсыжественного наследования.
Используйте disjoint, чтобы показать, чтообсуждают- классы в наборе являются взаимно несовместимыми; подкласс не мося в главе 11, жет наследовать от нескольких родителей. Применяйте overlapping,взаимоесли нужно показать, что класс допускает множественное наследодействия –вание от более чем одного класса в наборе.в главе 16.На заметку. В большинстве случаев во время исполненияобъект имеет один тип – тогда мы имеем дело со статической классификацией. Если же объект может изменять свойтип во время исполнения, это пример динамической классификации.
Моделировать последнюю сложно, но в UML выможете вместо динамической классификации использоватьсочетание множественного наследования (чтобы показатьвозможные типы объекта), типов и взаимодействий (чтобыпоказать изменение типа объекта во время исполнения).Расширенные связи158Базовые понятия159АссоциацииОсновныесвойстваассоциацийобсуждаются в главе 5.Ассоциация – это структурная связь, показывающая, что объекты одной сущности соединены с объектами другой. Например, классLibrary (Библиотека) может иметь ассоциацию «одинFкоFмногим»с классом Book (Книга), сообщая таким образом, что каждый экземпляр Book принадлежит одному экземпляру Library. Более того, вы можете найти библиотеку, где содержится конкретная книга, а в рамках одной библиотеки можете осуществить навигацию по всем еекнигам.
Ассоциация изображается сплошной линией, соединяющей разные классы или же один – сам с собой. Используется, когданеобходимо показать структурные связи.Существуют четыре базовых дополнения, применимых к ассоциациям: имя, роль на каждом конце ассоциации, множественность каждого конца ассоциации и агрегация. Для расширенногоприменения предусмотрен ряд других свойств, которые вы можетеиспользовать при моделировании тонких деталей: навигация, квалификация и разные типы агрегаций.Навигация (navigation).
Имея простую, без дополнений, ассоциацию между двумя классами (наподобие Book и Library в вышерассмотренном примере), вы можете осуществлять навигацию от объектов одного вида к объектам другого. Если только не указано иное,навигация по ассоциации двунаправлена. Иногда требуется ограничить ее лишь одним направлением. Например, при моделированиислужб операционной системы (см. рис. 10.3) вы столкнетесь с ассоциацией между объектами User (Пользователь) и Password (Пароль).Для данного объекта User понадобится искать соответствующий емуобъект Password, но по объекту Password нет смысла находить соответствующий объект User.
Вы можете явно задать направление навигации, снабдив ассоциацию дополнением в виде стрелки, указывающей в нужную сторону.На заметку. Указание направления обхода не обязательноозначает, что вы не можете попасть от объекта, находящегосяна одном конце ассоциации, к объекту на другом ее конце.Скорее, навигация констатирует «знание» одного объектао другом. Так, в предыдущем примере можно найти объект User, ассоциированный с конкретным объектом Password,хотя ассоциации с другими классами не показаны.
Свойство«навигабельности» ассоциации говорит о том, что, имея объект на одном ее конце, вы можете легко и напрямую получитьобъекты на другом, – обычно потому, что исходный объектсохраняет некую ссылку на целевые.Рис. 10.3. НавигацияОткрытая,защищенная,закрытаяи пакетнаявидимостьобсуждается в главе 9.Видимость (visibility). При наличии ассоциации между двумяклассами объекты одного класса могут «видеть» объекты другогои допускать навигацию к ним, если только она не ограничена явнымобразом.
Однако иногда необходимо ограничить видимость однихобъектов по отношению к другим в пределах ассоциации. В примере на рис. 10.4 ассоциации установлены между UserGroup (ГруппаПользователей) и User (Пользователь), а также между User и Password(Пароль). Имея объект User, можно идентифицировать соответствующие ему объекты Password.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
