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

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

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

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

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

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

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

введите описание изображения здесь

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

Всего 3 ответа


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

введите описание изображения здесь

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

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


пример

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

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

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


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

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

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

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


Есть идеи?

10000