Отношения в диаграммах классов

Дела, применяемые в диаграммах классов, показаны на рис. 11.5.

Рис. 11.5. Дела в диаграммах классов

Ассоциации показывают структурные дела меж экземплярами классов, другими словами соединения меж объектами. Любая ассоциация может иметь метку — имя, которое обрисовывает природу дела. Как показано на рис. 11.6, имени можно придать направление — довольно добавить треугольник направления, который показывает направление, данное для Отношения в диаграммах классов чтения имени.

Рис. 11.6. Имена ассоциаций

Когда класс участвует в ассоциации, он играет тут определенную роль. Как показано на рис. 11.7, роль определяет, каким представляется класс на одном конце ассоциации для класса на обратном конце ассоциации.

Рис. 11.7.Роли

Один и тот же класс в различных ассоциациях может играть различные роли. Нередко принципиально Отношения в диаграммах классов знать, как много объектов может соединяться через экземпляр ассоциации. Это количество именуется ложностью роли в ассоциации, записывается в виде выражения, задающего спектр величин либо одну величину (рис. 11.8).

Запись мощности на одном конце ассоциации определяет количество объектов, соединяемых с каждым объектом на обратном конце ассоциации. К примеру, можно задать Отношения в диаграммах классов последующие варианты мощности:

q 5 — точно 5;

q * — огромное количество;

q 0..* — ноль либо более;

q 1..* — один либо более;

q 3..7 — определенный спектр;

q 1..3, 7 — определенный спектр либо число.

Рис. 11. 8. Мощность

Довольно нередко появляется последующая неувязка — как для объекта на одном конце ассоциации выделить набор объектов на обратном конце? К примеру, разглядим взаимодействие меж банком и клиентом — вкладчиком Отношения в диаграммах классов. Как показано на рис. 11.9, мы устанавливаем ассоциацию меж классом Банк и классом Клиент. В контексте Банка мы имеем НомерСчета, который позволяет идентифицировать определенного Клиента. В этом смысле НомерСчета является атрибутом ассоциации. Он не является чертой Клиента, потому что Клиенту не непременно знать служебные характеристики его счета. Сейчас для данного Отношения в диаграммах классов экземпляра Банка и данного значения НомераСчета можно выявить ноль либо один экземпляр Клиента. В UML для решения этой препядствия вводится квалификатор — атрибут ассоциации, чьи значения выделяют набор объектов, связанных с объектом через ассоциацию. Квалификатор изображается небольшим прямоугольником, присоединенным к концу ассоциации. В прямоугольник вписывается свойство — атрибут ассоциации Отношения в диаграммах классов.

Рис. 11.9. Квалификация

Не считая того, роли в ассоциациях могут иметь пометки видимости. К примеру, на рис. 11.10 показаны ассоциации меж Начальником и Дамой, также меж Дамой и Загадкой. Для данного экземпляра Начальника можно найти надлежащие экземпляры Дамы. С другой стороны, Загадка приватна для Дамы, потому она недосягаема снаружи. Как показано Отношения в диаграммах классов на рисунке, из объекта Начальника можно передвигаться к экземплярам Дамы (и напротив), но нельзя созидать экземпляры Загадки для объектов Дамы.

Рис. 11.10. Видимость

На конце ассоциации можно задать три уровня видимости, добавляя знак видимости к имени роли:

q по дефлоту для роли задается общественная видимость;

q приватная видимость показывает, что объекты на Отношения в диаграммах классов данном конце недосягаемы хоть каким объектам вне ассоциации;

q защищенная видимость (protected) показывает, что объекты на данном конце недосягаемы хоть каким объектам вне ассоциации, кроме потомков того класса, который указан на обратном конце ассоциации.

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

Рис. 11.11.Класс-ассоциация

Характеристики класса-ассоциации охарактеризовывают не один, а пару объектов, в этом случае — пару экземпляров, Доктор и Институт.

Дела агрегации и композиции в языке Отношения в диаграммах классов UML числятся разновидностями ассоциации, используемыми для отображения структурных отношений меж «целым» (агрегатом) и его «частями». Агрегация указывает отношение по ссылке (в агрегат включены только указатели на части), композиция — отношение физического включения (в агрегат включены сами части).

Зависимость является отношением использования меж клиентом (зависимым элементом) и поставщиком (независящим элементом Отношения в диаграммах классов). Обычно операции клиента:

q вызывают операции поставщика;

q имеют сигнатуры, в каких возвращаемое значение либо аргументы принадлежат классу поставщика.

К примеру, на рис. 11.12 показана зависимость класса Заказ от класса Книжка, потому что Книжка употребляется в операциях проверкаДоступности, добавить и удалить класса Заказ.

Рис. 11.12.Дела зависимости

На этом рисунке изображена еще одна Отношения в диаграммах классов зависимость, которая указывает, что класс Просмотр Заказа употребляет класс Заказ. При этом Заказ ничего не знает о Просмотре Заказа. Данная зависимость помечена стереотипом «friend», который расширяет ординарную зависимость, определенную в языке. Отметим, что отношение зависимости очень многообразно — в текущее время язык предугадывает 17 разновидностей зависимости, различаемых по стереотипам.

Обобщение — отношение меж Отношения в диаграммах классов общим предметом (суперклассом) и спец разновидностью этого предмета (подклассом). Подкласс может иметь 1-го родителя (один суперкласс) либо несколько родителей (несколько суперклассов). Во 2-м случае молвят о множественном наследовании.

Как показано на рис. 11.13, подкласс Летающий шкаф является наследником суперклассов Летающий предмет и Хранилище вещей. Этому подклассу достаются в наследие Отношения в диаграммах классов все характеристики и операции 2-ух классов-родителей.

Множественное наследование довольно трудно и каверзно, имеет много «подводных камней». К примеру, подкласс Яблочный_Пирог не следует создавать от суперклассов Пирог и Яблоко. Это обычное неверное внедрение множественного наследования: потомок наследует все характеристики от его родителя, хотя обычно не все характеристики применимы к потомку Отношения в диаграммах классов. Разумеется, что Яблочный_Пирог является Пирогом, но не является Яблоком, потому что пироги не вырастают на деревьях.

Рис. 11.13.Множественное наследование

Еще больше сложные задачи появляются при наследовании от 2-ух классов, имеющих общего родителя. Молвят, что в итоге появляется ромбовидная решетка наследования (рис. 11.14).

Рис. 11.14.Ромбовидная решетка наследования

Полагаем, что в подклассах Официант Отношения в диаграммах классов и Певец операция работать суперкласса Работник переопределена в согласовании с обязанностью подкласса (работа официанта состоит в обслуживании пищей, а певца — в пении). Появляется вопрос — какую версию операции работать унаследует Поющий_официант? А что делать со качествами, доставшимися в наследие от родителей и общего прародителя? Желаем ли мы иметь Отношения в диаграммах классов несколько копий характеристики либо только одну?

Все эти трудности наращивают сложность реализации, приводят к введению бессчетных правил для обработки особенных случаев.

Реализация — семантическое отношение меж классами, в каком класс-приемник делает реализацию операций интерфейса класса-источника. К примеру, на рис. 11.15 показано, что класс Каталог должен воплотить интерфейс Обработчик Отношения в диаграммах классов каталога, другими словами Обработчик каталога рассматривается как источник, а Каталог — как приемник.

Рис. 11.15.Реализация интерфейса

Интерфейс Обработчик каталога позволяет клиентам вести взаимодействие с объектами класса Каталог без познания той дисциплины доступа, которая тут реализована (LIFO — последний вошел, 1-ый вышел; FIFO — 1-ый вошел, 1-ый вышел и т. д.).

Деревья наследования

При использовании отношений Отношения в диаграммах классов обобщения строится иерархия классов. Некие классы в этой иерархии могут быть абстрактными. Абстрактным именуют класс, который не может иметь экземпляров. Имена абстрактных классов записываются курсивом. К примеру, на рис. 11.16 показаны абстрактные классы Млекопитающие, Собаки, Кошки.

Рис. 11.16.Абстрактность и полиморфизм

Не считая того, тут имеются определенные классы ОхотничьиСобаки, Сеттер Отношения в диаграммах классов, любой из которых может иметь экземпляры.

Обычно класс наследует какие-то свойства класса-родителя и передает свои свойства классу-потомку. Время от времени требуется найти конечный класс, который не может иметь деток. Такие классы помечаются теговой величиной (чертой) leaf, записываемой за именованием класса. К примеру, на рисунке показан конечный класс Сеттер.

Время Отношения в диаграммах классов от времени полезно отметить корневой класс, который не может иметь родителей. Таковой класс помечается теговой величиной (чертой) root, записываемой за именованием класса. К примеру, на рисунке показан корневой класс Млекопитающие.

Подобные характеристики имеют и операции. Обычно операция является полиморфной, это означает, что в разных точках иерархии можно определять операции Отношения в диаграммах классов с похожей сигнатурой. Такие операции из дочерних классов переопределяют поведение соответственных операций из родительских классов. При обработке сообщения (в период выполнения) делается полиморфный выбор одной из операций иерархии в согласовании с типом объекта. К примеру, ОтображатьВнешнийВид () и ВлезатьНаДерево (дуб) — полиморфные операции. К тому же операция Млекопитающие Отношения в диаграммах классов::ОтображатьВнешнийВид ( ) является абстрактной, другими словами неполной и требующей для собственной реализации потомка. Имя абстрактной операции записывается курсивом (как и имя класса). С другой стороны, Млекопитающие::УзнатьВес () — конечная операция, что отмечается чертой leaf. Это означает, что операция не полиморфна и не может перекрываться.


otnositelnie-statisticheskie-pokazateli.html
otnositelnie-velichini-ih-vidi-sposobi-rascheta-primenenie-v-analize.html
otnositelnij-pokazatel-sravneniya.html