Класс-ассоциация

Классы-ассоциации (association classes) позволяют дополнительно оп­ределять для ассоциаций атрибуты, операции и другие свойства, как показано на рис. 5.12. Из данной диаграммы видно, что Person (Лич­ность) может принимать участие в нескольких совещаниях (Meeting). При этом необходимо каким-то образом хранить информацию о том, насколько внимательной была данная личность; это можно сделать, добавив к ассоциации атрибут attentiveness (внимательность).

На рис. 5.13 показан другой способ представления данной информа­ции: образование самостоятельного класса Attendance (Присутствие). Обратите внимание, как при этом изменили свои значения кратности.

Какие же преимущества может дать класс-ассоциация в качестве ком­пенсации за необходимость помнить еще один вариант уже описанной нотации? Класс-ассоциация дает возможность определить дополни­тельное ограничение, согласно которому двум участвующим в ассо­циации объектам может соответствовать только один экземпляр клас­са-ассоциации. Мне кажется, необходимо привести еще один пример.

Посмотрим на две диаграммы, изображенные на рис. 5.14. Форма этих диаграмм практически одинакова. Хотя можно себе представить ком­панию (Company), играющую различные роли (Role) в одном и том же контракте (Contract), но трудно вообразить личность (Person), имею­щую различные уровни компетенции в одном и том же навыке (Skill); действительно, скорее всего, это можно считать ошибкой.

В языке UML допустим только последний вариант. Может существо­вать только один уровень компетенции для каждой комбинации лич­ности и навыка. Верхняя диаграмма на рис. 5.14 не допускает участия компании более чем в одной роли в одном и том же контракте. Если без этого не обойтись, надо превратить Role в полный класс, как это сдела­но на рис. 5.13.

Реализация классов-ассоциаций не слишком очевидна. Мой совет: реализовывать класс-ассоциацию так, как будто это обычный класс, но методы, предоставляющие информацию связанным классам, долж­ны принадлежать классу-ассоциации. Поэтому для случая, изобра­женного на рис, 5.12, я бы представил следующие методы класса Per­son:

class Person

List getAttendances()

List getMeetings()

Таким образом, клиенты объекта Person могут обнаружить сотрудни­ков на совещании; если им требуются детали, то они могут получить собственно часы работы (Attendance). Если вы так делаете, не забудьте об ограничении, при котором для любой пары объектов Person (Лич­ность) и Meeting (Совещание) может существовать только один объект Attendance (Присутствие).

Часто этот вид конструкции можно встретить там, где речь идет о вре­менных изменениях (см., например, рис. 5.15). Однако я считаю, что создание дополнительных классов или классов-ассоциаций может сде­лать модель сложной для понимания, а также направить реализацию в неправильное русло.

Если я встречаю временную информацию такого типа, то использую для ассоциации ключевое слово «temporal» (временной) (рис. 5.16). Мо­дель означает, что некоторое время личность может работать только в одной компании. Однако по прошествии времени личность сможет работать в нескольких компаниях. Это предполагает интерфейс, опи­сываемый следующими строками:

class Person …

Company getEmployer(); // определение текущего работодателя

Company getEmployer(Date); // определение работодателя на указанный момент

void changeEinployer(Company newEmployer.Date changeDate);

void leaveEmployer (Date changeDate);

Ключевое слово «temporal» не входит в состав языка UML, но я упомя­нул его здесь по двум причинам. Во-первых, это понятие часто оказы­валось полезным для меня как проектировщика. Во-вторых, это де­монстрирует, как можно применять ключевые слова для расширения языка UML. Дополнительную информацию по данному вопросу мож­но найти на https://maHinfowler.com/ap2/timeNarrative.html