UML class diagram about relationship types in project management

2
votes

I'm trying to draw an class diagram for my project management software describing the following. It contains the following classes:

  • Project - software projects
  • ProjectManager - he/she who manage the project
  • Employee - people who are engage in project work

and the following relationships/associations:

  1. a project manager may have to manage more than one project, while a project can only be managed by one project manager

  2. a project manager can assign an employee to a project that he/she manages

For the above associations I created this class diagram:

enter image description here

  • It's clear how to model the first association (between ProjectManager and Project)
  • I have no idea how to model the second association
    (how to implement that a project manager is only able to assign projects to employees that he is responsible to manage ?)
3
classoopumlassociationsooad
As i know the arrow shown in the diagram is not an association, it's a stereotype definition ... And what ever your schema is, you need to model a constraint if possible in OCL. – granier

3 Answers

1
votes

You just add an operation to Project called assignEmployee which will add the employee to its list of assigned employees:

enter image description here

It's unclear how an employee can be assigned, whether to just one or multiple projects. Also you will likely need a de-assign operation.

Of course you can also use an association class like suggested by @WolfgangFahl.

3
votes

Example

Your question is close to the example above that we have been using for many years in our UML Trainings at my company BITPlan.

In this example there is a ProjectAssignment class and the rule is that for each point in time there may be only one ProjectAssignment with "responsible=true". The Employee with this ProjectAssignment is the ProjectManager. This style can also be applied when subproject come into play and you'd like to model a whole hierarchy of managers that may vary over time.

Personally I think it is quite often much better to state such restrictions in prose in the documentation of a model instead of trying to show it in the structure using inheritance and cardinalities.

0
votes

A more general approach to model your problem is using an object type Person (or Employee) both for project managers and employees. This would express that project managers are also employees and can be assigned to some projects as managers while they are assigned to other projects as ordinary employees.

In such an approach, you would have the two classes Employee and Project with two associations between them:

  1. An association Employee-works-for-Project (or better use a role name like worker at the association end).
  2. An association Employee-is-manager-of-Project, where manager is the role name.

If you really need to model/record the assignment of employees to projects by project managers, then you need to replace the first association (Employee-works-for-Project) with a ternary association Employee-is-assigned-to-Project-by-Employee-as-assigner where the latter employee (the assigner) is required to be the manager of the assigned project. This condition can be captured with a corresponding invariant attached to the Employee class.