Диаграмма классов UML о типах отношений в управлении проектами

Question

Я пытаюсь нарисовать диаграмму классов для моей программы управления проектами описывая следующее. Он содержит следующие классы:

• Project - программные проекты
• ProjectManager - тот, кто руководит проектом
• Employee - люди, которые занимаются проектной работой

и следующие отношения / ассоциации:

1. менеджеру проекта может понадобиться управлять более чем одним проектом, в то время как проектом может управлять только один менеджер проекта

2. менеджер проекта может назначить сотрудника для проекта, которым он / она управляет

Для перечисленных выше ассоциаций я создал следующую диаграмму классов:

• Понятно, как смоделировать первую ассоциацию (между ProjectManager и Project)
• Понятия не имею, как смоделировать вторую ассоциацию
  ( как реализовать, чтобы руководитель проекта мог назначать проекты только тем сотрудникам, которыми он отвечает за управление? )

Answer 1

Ваш вопрос близок к приведенному выше примеру, который мы использовали в течение многих лет в наших тренингах по UML в моей компании BITPlan.

В этом примере есть класс ProjectAssignment, и правило состоит в том, что для каждого момента времени может быть только один ProjectAssignment с «liability = true». Сотрудник с этим присвоением Project является ProjectManager. Этот стиль также может быть применен, когда подпроект вступает в игру, и вы хотите смоделировать целую иерархию менеджеров, которая может меняться со временем.

Лично я думаю, что зачастую гораздо лучше указывать такие ограничения в прозе в документации модели, чем пытаться показать ее в структуре с использованием наследования и количества элементов.

Answer 2

Вы просто добавляете операцию к Project с именем assignEmployee, которая добавляет сотрудника в список назначенных сотрудников:

Неясно, как можно назначить сотрудника, будь то один или несколько проектов. Также вам, вероятно, потребуется операция отмены назначения.

Конечно, вы также можете использовать ассоциативный класс, как предложено @ WolfgangFahl.

Answer 3

Более общий подход к моделированию вашей проблемы заключается в использовании типа объекта Person (или Employee) как для руководителей проектов, так и для сотрудников. Это будет означать, что руководители проектов также являются сотрудниками и могут быть назначены для некоторых проектов в качестве руководителей, в то время как они назначены для других проектов в качестве обычных сотрудников.

При таком подходе у вас будет два класса Employee и Project с двумя ассоциациями между ними:

1. Ассоциация Employee -works-for- Project (или лучше использовать имя роли, например worker в конце ассоциации).
2. Ассоциация Employee -is-manager-of- Project, где manager - это имя роли.

Если вам действительно нужно смоделировать / записать назначение сотрудников для проектов менеджерами проектов, то вам нужно заменить первую ассоциацию (Employee -works-for- Project) на тройную ассоциацию Employee - назначен на Project -by- Employee -as- assigner, где последний сотрудник (цессионарий) должен быть руководителем назначенного проекта. Это условие может быть зафиксировано с помощью соответствующего инварианта , присоединенного к классу Employee.