2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 16
Текст из файла (страница 16)
Так, имеяассоциацию между двумя классами, вы можете соединить объектыодного класса с объектами другого. Вполне допустимо, чтобы обаконца ассоциации соединяли один и тот же класс – иными словами,один объект класса может связываться с другим объектом того жекласса.
Ассоциация, связывающая два класса, называется бинарной.Связи80Не путайтенаправлениеименис навигациейпо ассоциации (см. главу 10).Базовые понятияХоть и нечасто, но все же встречаются так называемые n9арные ассоциации, которые соединяют более двух классов .Графически ассоциация представлена сплошной линией, дваконца которой соединяют один или разные классы.
Применяйте ассоциацию, когда хотите показать структурные связи.Выше мы описали базовый вариант. Но существуют еще пятьдополнений, применяемых к ассоциациям.Ассоциация может иметь имя, используемое для описания природы связи. Поэтому значение имени не должно быть двусмысленным. Используя стрелочку в форме треугольника, вы можете указать направление, в котором следует читать это имя (см.
рис. 5.4).81Рис. 5.5. Конечные имена ассоциации (имена ролей)На заметку. Один и тот же класс может играть в разных ассоциациях одну и ту же роль или разные роли.На заметку. Атрибут может рассматриваться как односторонняя ассоциация, принадлежащая классу. Имя атрибутасоответствует конечному имени ассоциации вне класса.Рис.
5.4. Имена ассоциацииНа заметку. Хотя ассоциация может быть поименована, обычнонет необходимости указывать ее имя, если указаны конечные имена ассоциации. Если в вашей модели присутствуетнесколько ассоциаций, связывающих одни и те же классы,необходимо использовать или имена ассоциаций, или конечные имена, чтобы различать их. Если ассоциация имеетнесколько концов для одного и того же класса, требуетсяв обязательном порядке указывать ее конечные имена, чтобыразличать эти концы. При наличии только одной ассоциации,соединяющей пару классов, некоторые авторы моделей опускают имена, но все же лучше указать их, чтобы прояснитьназначение ассоциации.Роли имеютотношениек семантикеинтерфейсов, какпоказанов главе 11.Когда класс участвует в ассоциации, он выполняет в этой связи конкретную роль.
Роль – это «лицо» класса, который находитсяна дальнем конце ассоциации, представленное классу, находящемуся на ее ближнем конце. Вы можете явно именовать роль, которуювыполняет класс в ассоциации.Роль, которую играет класс, находящийся на конце ассоциации,называется конечным именем (в первой версии UML она называлась именем роли). На рис. 5.5 класс Person (Человек), играющийроль employee (работник), ассоциирован с классом Company (Компания), играющим роль employer (работодатель).Экземплярассоциацииназываетсяссылкой (см.главу 16).Ассоциация представляет структурную связь между объектами. Во многих ситуациях моделирования важно знать, сколькообъектов может быть соединено одним экземпляром ассоциации.Этот параметр называется множественностью роли ассоциации.Множественность (multiplicity) представляет диапазон целых чисел, указывающий возможное количество связанных объектов.
Онзаписывается в виде выражения с минимальным и максимальнымзначением, которые могут быть равны; для их разделения используются две точки. Устанавливая множественность дальнего концаассоциации, вы указываете, сколько объектов может существоватьна дальнем конце ассоциации для каждого объекта класса, находящегося на ближнем ее конце. Количество объектов должно находиться в пределах заданного диапазона. Множественность можетбыть определена как единица (1), ноль или один (0..1), много (0..*),один или несколько (1..*). Вы можете задавать диапазон целых значений, например 2..5, или устанавливать точное число, например 3(эквивалент записи 3..3).Рис.
5.6. МножественностьСвязи82В примере на рис. 5.6 каждая компания может нанимать одногоили нескольких человек (множественность 1..*); каждому человекусопоставлено 0 или более компанийFработодателей (множественность * – эквивалент записи 0..*).Простая ассоциация между двумя классами представляет струкСуществуеттурную связь между равноправными элементами: оба класса коннескольковажных раз- цептуально находятся на одном уровне – ни один из них не можетновидностей считаться важнее другого.
Рано или поздно вам понадобится смоделировать связь «целоеFчасть», в которой один класс представляетагрегации.крупную сущность (целое), содержащую в себе более мелкие (часО нихпойдет речь ти). Этот тип связей, основанных на отношениях обладания, называется агрегацией и подразумевает, что объектFцелое обладаетв главе 10.объектамиFчастями. По сути, агрегация – это особый вид ассоциации, поэтому изображается она линией простой ассоциации, к которой добавлен пустой ромбик со стороны объектаFцелого (см.
рис. 5.7).Рис. 5.7. АгрегацияНа заметку. Простая форма агрегации выглядит так не случайно: пустой ромбик отличает целое от части – ни большени меньше. Это означает, что простая агрегация не изменяетсмысла навигации по ассоциации между целым и его частями. Более строгая форма агрегации описывается в разделе «Ассоциации» главы 10.Прочие свойстваСложныепонятиясвязей обсуждаютсяв главе 10.Простые зависимости, обобщения и ассоциации с именами,показателями множественности и ролями – это наиболее общиесредства, с которыми вы имеете дело, создавая абстракции.
Основных форм этих трех абстракций достаточно, чтобы выразить наиболее важную семантику связей в большинстве моделей. Однакоиногда вам нужно будет визуализировать или специфицироватьдругие свойства – такие как композитная агрегация, навигация,дискриминанты, ассоциацииFклассы, некоторые разновидности зависимостей и обобщений.
Эти и многие другие свойства можно выразить на UML, но обычно их трактуют как более сложные и, соответственно, менее употребительные понятия.Типичные приемы моделированияДиаграммыклассоврассматриваютсяв главе 6.Ссылки обсуждаютсяв главе 16.83Зависимости, обобщения и ассоциации являются статическими сущностями, определенными на уровне классов. В UML эти связи обычно визуализируются в диаграммах классов.Начиная моделировать на уровне объектов (особенно когда приходится работать с их динамическими кооперациями), вы сталкиваетесь со ссылками – экземплярами ассоциаций, представляющими соединения между объектами, по которым можно отправлятьсообщения.Стили изображенияСвязи изображаются на диаграммах линиями, соединяющимиодни пиктограммы с другими.
Для различения типов связей к этимлиниям добавляются разнообразные элементы, например стрелкиили ромбики. Как правило, авторы моделей выбирают один из двухстилей рисования линий: наклонные линии под любым углом. Используются линии изодного сегмента (если только не нужно несколько, чтобы миновать другие пиктограммы); линии, образующие квадрат и проведенные параллельно краям страницы. Если только линии не соединяют две выровненные пиктограммы, они должны быть прорисованы строгопо горизонтали и вертикали, соединяясь друг с другом подпрямым углом. В данной книге главным образом используется именно этот стиль.Если постараться, пересечения линий в большинстве случаевможно избежать.
Если оно всеFтаки неизбежно и есть опасностьдвусмысленной интерпретации связей, стоит отметить место пересечения линий маленьким полукругом (рис. 5.8).Рис. 5.8. Символ пересечения линийТипичные приемы моделированияМоделирование простых зависимостейЧасто встречающийся вид зависимости – это связь класса, который использует другой класс в качестве параметра своей операции. Чтобы смоделировать эту связь использования, необходимосоздать зависимость, направленную от класса с операцией к классу,используемому в качестве ее параметра.Связи84В примере на рис. 5.9 показан набор классов, составляющихсистему, которая управляет назначением студентов и преподавателей на курсы в университете. Этот рисунок изображает зависимостьот CourseSchedule (РасписаниеКурсов) к Course (Курс), поскольку Courseиспользуется в операциях add (добавить) и remove (удалить) классаCourseSchedule.Если вы представите полную сигнатуру операций, подобнотому как это сделано на рисунке, вам, скорее всего, необязательно показывать эту зависимость, потому что использование классауже присутствует в сигнатуре.
Однако иногда показать такую зависимость необходимо, особенно если вы не приводите сигнатуруопераций или ваша модель показывает другие связи с используемым классом.Рис. 5.9. Связи зависимостиДругиестереотипысвязей обсуждаютсяв главе 16.Кроме того, рис. 5.9 демонстрирует зависимость, которая не связана с классами в операциях, а моделирует одну общую идиому C++.Зависимость от Iterator (Итератор) говорит о том, что Iterator использует CourseSchedule, то есть CourseSchedule ничего не знает об Iterator.
Зависимость помечена стереотипом <permit> (<разрешить>), которыйподобен предложению friend (друг) в C++.Моделирование одиночного наследованияВ моделировании словаря вашей системы вы часто будете сталкиваться с классами, которые структурно или по своему поведению похожи на другие классы.
Каждый из них можно смоделировать как отдельную независимую абстракцию. Но лучше извлечьиз них общие структурные или поведенческие части и поместитьих в более общие классы, от которых эти классы будут унаследованы.Чтобы смоделировать связи наследования, необходимо: Найти в наборе классов обязанности, атрибуты и операции,общие для нескольких классов.Типичные приемы моделирования85 Перенести эти обязанности, атрибуты и операции в более общий класс. Если необходимо, создать такой класс (но будьтеосторожны – не создавайте слишком много уровней). Назначить более специализированные классы потомкамиобщих классов, проведя связь обобщения от каждого специализированного класса к его родителю.Рис.
5.10. Связи наследованияНа рис. 5.10 представлен ряд классов, формирующих приложение управления торговлей. Вы найдете здесь связь обобщения, проведенную от четырех классов – CashAccount (РасчетныйСчет), Stock(Акция), Bond (Облигация) и Property (Собственность), – к болееобщему классу Security (ЦенныеБумаги). Класс Security является родителем, а CashAccount, Stock, Bond и Property – потомками (дочернимиклассами).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
