Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 40
Текст из файла (страница 40)
На рис. 9.13 объекты Order могут посылать сообще ния объектам Product, но не наоборот.Возможность навигации показывает, что объекты исходного класса«знают об» объектах целевого класса.Одна из целей хорошего ОО анализа и проектирования – минимизиро вать количество взаимосвязей между классами.
И применение возмож 212Глава 9. Отношенияобъект Order хранит список объектов Productдопускает навигацию*Order*возможность навигацииProductвозможность навигациине допускает навигацииобъект Product не хранит списка объектов OrderРис. 9.13. Варианты обозначения возможности навигацииности навигации – верное средство достижения этой цели. Сделав ассо циацию между Order и Product однонаправленной, можно обеспечить воз можность свободной навигации от объектов Order к объектам Product, ноне в обратном направлении – от объектов Product к объектам Order. Та ким образом, объекты Product не знают о своем возможном участиив конкретном Order и, следовательно, не имеют связанности с Order.Возможность навигации обозначается крестом или стрелкой на кон цах отношения, как показано на рис. 9.13.Спецификация UML 2.0 [UML2S] предлагает три стиля обозначениявозможности навигации на диаграммах модели.1.
Сделать возможность навигации абсолютно явной. Должны бытьобозначены все стрелки и кресты.2. Сделать возможность навигации абсолютно скрытой. Стрелки и кре сты не обозначаются.3. Опускать все кресты. Двунаправленная ассоциация обозначаетсябез стрелок. Однонаправленная ассоциация обозначается с однойстрелкой.Эти три стиля представлены на рис. 9.14.Стиль 1 делает возможность навигации полностью видимой, что, одна ко, может сделать диаграмму слишком громоздкой.Стиля 2 следует избегать, потому что он скрывает слишком много зна чимой информации.Стиль 3 – разумный компромисс.
На практике чаще всего используетсястиль 3. И поскольку он представляет лучший на данный момент вари ант, именно он применяется в этой книге. Основные преимущества сти ля 3: при его использовании диаграммы не загромождаются слишкомбольшим количеством стрелок и крестов; он обратно совместим с пре дыдущими версиями UML. Однако у этого стиля есть и недостатки.2139.4.
Что такое ассоциация?Стили представления возможности навигации в UML 2Стиль 1:Строгое обозначениевозможности навигации в UML 2Синтаксис UML 2BЕсть возможностьнавигации от A к BЕсть возможностьнавигации от B к ABЕсть возможностьнавигации от A к BНет возможностинавигации от B к ABЕсть возможностьнавигации от A к BВозможность навигацииот B к A не определенаABВозможность навигацииот A к B не определенаВозможность навигацииот B к A не определенаABНет возможностинавигации от A к BНет возможностинавигации от B к AAAAСтиль 2:Возможность навигациине обозначаетсяСтиль 3:ОбщепринятаяпрактикаЕсть возможностьнавигации от A к BНет возможностинавигации от B к AВозможность навигацииот A к B не определенаВозможность навигацииот B к A не определенаЕсть возможностьнавигации от A к BЕсть возможностьнавигации от B к AРис. 9.14.
Стили представления возможности навигации в UML 2•Глядя на диаграмму, нельзя сказать, указана ли на ней возмож ность навигации или она еще не определена.•Значение связи с одной стрелкой меняется с «есть/не определена»возможность навигации на «есть/нет» возможности навигации. Этонедостаток, с которым приходится мириться.•Нельзя показать ассоциации, в которых отсутствует возможностьнавигации в обоих направлениях (кресты на обоих концах). Такиесвязи бесполезны в повседневном моделировании, поэтому особойпроблемы это не создает.Обзор стиля 3 можно увидеть на рис. 9.15.Стиль представления 3 чаще всего используется на практикеABОднонаправленная ассоциация:Есть возможность навигации от A к BНет возможности навигации от B к AABДвунаправленная ассоциация:Есть возможность навигации от A к BЕсть возможность навигации от B к AРис. 9.15.
Стиль 3214Глава 9. ОтношенияДаже если нет возможности навигации по ассоциации, все равно можетсуществовать возможность прохода по ассоциации, но затраты на этобудут высокими.Даже если нет возможности навигации по ассоциации, все равно мо жет существовать возможность установления отношения в этом на правлении. Но вычислительные затраты на это, скорее всего, будуточень высокими. В примере на рис. 9.13, несмотря на отсутствие воз можности прямой навигации от Product к Order, просмотрев по очередивсе объекты Order, можно найти Order, ассоциированный с конкретнымобъектом Product.
То есть можно пройти не допускающее навигации от ношение, но с большими вычислительными затратами. Односторон няя возможность навигации подобна улице с односторонним движени ем: по ней нельзя пойти против движения напролом, но чтобы до браться до ее конца, можно найти другие (более длинные) пути.Если на целевом конце отношения указано имя роли, объекты исходно го класса могут ссылаться на объекты целевого класса по имени роли.С точки зрения реализации на ОО языках программирования возмож ность навигации подразумевает, что у исходного объекта есть объект ная ссылка на целевой объект. Исходный объект может использоватьэту ссылку для отправки сообщений целевому объекту.
На диаграммеобъектов это можно представить в виде однонаправленной связи с ас социированным сообщением.9.4.4. Ассоциации и атрибутыСуществует тесная связь между ассоциациями класса и атрибутамикласса.Ассоциация между исходным и целевым классами означает, что объ екты исходного класса могут сохранять объектную ссылку на объектыцелевого класса. Иначе это можно представить так, что ассоциация эк вивалентна исходному классу, имеющему псевдоатрибут целевогокласса. Объект исходного класса может ссылаться на объект целевогокласса с помощью псевдоатрибута (рис.
9.16).источникHouseцельaddress11HouseAddressaddress:AddressЗадание имени роли для допускающего навигацию отношения аналогично тому,что у исходного класса есть псевдоатрибут с тем же именем, что и имя роли,и того же типа, что и целевой классРис. 9.16. Объект исходного класса ссылается на объект целевого классапосредством псевдоатрибута2159.4. Что такое ассоциация?Нет широко используемого ОО языка программирования, имеющегоспециальную языковую конструкцию для поддержки ассоциаций.
По этому при автоматическом генерировании кода из UML модели ассо циации один к одному превращаются в атрибуты исходного класса.На рис. 9.17 в сгенерированном коде есть класс House с атрибутом address типа Address. Обратите внимание, как имя роли обеспечивает имяатрибуту, а класс, находящийся на другом конце ассоциации, обеспе чивает класс атрибута. Приведенный ниже код на Java был сгенериро ван из модели, представленной на рис.
9.17:public class House{private Address address;}Как видите, есть класс House, имеющий один атрибут address типа Address. Обратите внимание, что видимость атрибута address – private; онаприменяется по умолчанию в большинстве случаев генерации кода.Если кратность целевого класса больше 1, она реализуется одним изследующих способов:•как атрибут типа array (массив) (конструкция, поддерживаемаябольшинством языков программирования);•как атрибут некоторого типа, являющегося коллекцией.Коллекции – это просто классы, экземпляры которых имеют особоеповедение, заключающееся в способности сохранять и возвращать ссыл ки на другие объекты.
Самым обычным примером коллекции в Java яв ляется Vector, но есть и многие другие. Более подробно коллекции обсу ждаются в разделе 18.10.Псевдоатрибуты хороши для отношений один к одному и один ко многим, но для отношений многие ко многим возникают проблемы.Их реализация будет показана в главе 18.Ассоциации используются только тогда, когда целевой класс являетсяважной частью модели, в противном случае отношения моделируютсяс помощью атрибутов. Важными являются бизнес классы, описываю щие часть прикладной области.
Не имеющими большого значенияклассами являются компоненты библиотеки, такие как классы String,Date и Time.Houseaddress11псевдоатрибутAddress=Houseaddress:AddressатрибутРис. 9.17. Из этой модели сгенерирован код, в котором есть класс Houseс атрибутом address типа Address216Глава 9. ОтношенияДо известной степени выбор явного указания ассоциации или атрибу тов является вопросом стиля. Лучшим всегда будет тот подход, в кото ром модель и диаграммы выражают задачу ясно и точно. Часто пред ставленная на диаграмме ассоциация с другим классом более понятна,чем это же отношение, смоделированное как атрибут, который заме тить намного сложнее.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
