В UML атрибут «роль» относится к конкретной связи сотрудника с проектом, а не к сотруднику или проекту. Как смоделировать это без размещения атрибута на одном из классов?
Используйте класс ассоциации. Он представляет саму связь между сотрудником и проектом, поэтому может хранить атрибут «роль» и другие свойства этой связи.
Обычная ассоциация UML хорошо описывает факт связи объектов, но не предоставляет естественного места для свойств самой связи. Класс ассоциации появился как способ выразить отношения, которые имеют собственные данные или поведение.
Такой подход особенно важен для предметных моделей, где сведения нельзя корректно отнести только к одному из связанных объектов.
Если поместить «роль» в класс Сотрудник, один сотрудник сможет иметь только одну роль независимо от проекта. Если разместить атрибут в классе Проект, все сотрудники проекта фактически получат одну и ту же роль.
Оба решения искажают предметную область. Ошибка может привести к неправильным ограничениям данных, невозможности хранить историю участия сотрудника в разных проектах и неоднозначной логике требований.
Создайте ассоциацию между классами Сотрудник и Проект, затем представьте эту ассоциацию классом, например Участие в проекте. В нём размещаются атрибуты роль, дата начала, дата окончания, ставка или другие свойства конкретного участия.
Смысл модели будет таким: один сотрудник может участвовать во многих проектах, один проект может включать многих сотрудников, а каждая пара «сотрудник—проект» имеет собственные данные участия.
Класс ассоциации следует выбирать, когда свойства относятся именно к факту связи. Если связь получает самостоятельный жизненный цикл, сложные операции или на неё ссылаются другие сущности, иногда практичнее моделировать её как обычный класс с двумя явными ассоциациями.
Нельзя автоматически превращать каждую связь в класс. Это усложняет модель и может скрыть простые отношения. Критерий выбора — наличие значимых атрибутов, поведения, ограничений или идентичности у самой связи.
В системе управления проектами нужно хранить сотрудников, проекты и роли сотрудников в проектах. Один сотрудник работает аналитиком в одном проекте и руководителем в другом; кроме того, для участия нужно хранить даты начала и завершения.
Вариант с атрибутом «роль» в Сотруднике прост, но не поддерживает разные роли в разных проектах. Вариант с атрибутом в Проекте ещё сильнее искажает модель, поскольку роль стала бы общей для всех участников.
Можно оставить много-ко-многим ассоциацию без отдельного класса, но тогда для её атрибутов не будет явного владельца. Поэтому выбран класс Участие в проекте. В результате требования к ролям, срокам участия и проверке пересечений дат можно формулировать непосредственно для отдельного участия.
Класс ассоциации семантически подчёркивает, что объект представляет связь между экземплярами других классов. Обычный промежуточный класс может выглядеть похоже на уровне структуры, но его самостоятельная идентичность и жизненный цикл должны быть явно обоснованы предметной областью.
Если участие сотрудника в проекте можно создавать, изменять, закрывать и отдельно проверять, его часто удобнее моделировать обычным классом Участие с двумя ассоциациями. Это делает модель менее зависимой от специальных правил работы с классами ассоциаций.
Ограничение относится к экземплярам класса участия и к комбинации связанных объектов. Его нужно зафиксировать как ограничение предметной области, например: для одной пары «сотрудник—проект» не допускается более одной активной записи участия.
Само наличие класса ассоциации не гарантирует выполнение такого правила. Ограничение должно попасть в требования, модель данных или проверки приложения — в зависимости от архитектуры решения.
Нет. Это зависит от кратностей и бизнес-правил. Если сотрудник может несколько раз участвовать в одном проекте в разные периоды, модель должна допускать несколько объектов участия и различать их по датам, идентификатору или другому правилу.
Если повторные участия запрещены, это должно быть отдельным ограничением. Одних кратностей исходной ассоциации недостаточно, чтобы выразить все временные или условные правила.