Is this UML class diagram correct?

Question

I have been struggling to get my system into a class diagram. I tend to make relationship mistakes by thinking too much in database structure. I have a class diagram:

So to explain the situation I need:

The employee part:

• An employee can be assigned to 0 or more projects by a project phase

The project part:

• A project is of a certain type (I can get confused with if a project HAS or IS of a certain type).
• A project type consists of 1 or more project phases
• A project phase IS of a certain phase

To explain what the system must do:

An employee can be assigned to a certain phase of a project. The project should be of a certain type and that type consists of certain project phases. The project phase is a certain phase.

Because an employee needs to see all of his current projects etc I made a link to employee and project too. I don't know if this is correct or that it is the project phase it's responsibility to provide the right project to the employee.

Answer 1

As a rule of thumb - there is no such thing as the only correct method of drawing diagram.

Aggregation

An obvious mistake is your usage of composite aggregation. With such usage you assume that a ProjectPhase is attached to one Employee and cannot be shared with other Employees and definitely that's not what you want to depict here.

If you want to show that the project is build of several employees, you could eventually use shared aggregation which means you should have an opposite direction and an open diamond.

In case of ProjectPhase and ProjectType this is a composite aggregation but in opposite direction (ProjectType is build of specific ProjectPhases and a ProjectPhase is a part of exactly one ProjectType).

Generalization

Project to ProjectType and Phase to ProjectPhase are places where several options exist.

1. If you assume that a Project is build of Phases and then you want to model specific types of Projects (eg ProjectWaterfall, ProjectScrum, ProjectXP, ProjectRUP, ProjectPrince2) which will specialise the Project having specific structure, then you can use generalization, however Project and Phase would be on the generalized end (the one with arrow) while a specific ProjectType and ProjectPhase would be on the specialized end (without arrow). If you follow this method you are able to show detailed structure of each ProjectType. See the example for details. Note also how some additional constrains are used to more precisely define how to understand the logic of modelled system. Finally be aware that in my diagram I made an assumption that each Project as well as Phase has to be of a specific type. You cannot have a Project as such (which not necessarily has to be true) and thus I made them abstract. Here a Project IS of a certain ProjetType .

2. The other option is to use the ProjectType and PhaseType as attributes of respectively Project and Phase and keep the logic of which types should be in a specific type of Project elsewhere. In such case you usually model ProjectType and PhaseType as enumerators and then put them as attributes in respectively Project and Phase linking respective elements with Dependency. Here Project HAS certain ProjetType .

Notes

• Given choices does not create a complete list of possibilities. These are only two most commonly used approaches.
• You can mix approaches in the same model depending on what serves better your purpose. However quite often at this level of dependency between classes you will use the same approach as it will benefit on diagram (see examples).

Employee - Project relationship

Evidently the assignment of Employee to the Project is done only through the Phase so the direct relationship is redundant. You can eventually depict it as a derived relationship.

Examples

Specialized types

This example uses the first approach. Note that I define exact, specific types of Projects, not some undefined general ProjectType (same for Phases).

I completely omit a redundant information about a relationship between Employee and Phase in this example.

Types as enumeration

This example does not provide details about structure of specific type. You will probably want to add here additional classes that create a template for your Project to define how should Project structure look like (which Phases are included). This classes are not presented on the example diagram. Moreover I've added the direct derived association between Employee and Project.

Answer 2

Some obvious errors:

• Remove the composition in both cases. They are wrong and in general do not add enough semantics to be used at all (almost all times).
• Change the generalization to simple association. It's not inheritance here but an attribution.

As I see it, this will fit your explanation:

You don't need an association from Employee to Project since it's linked via phase and type. There is no explanation of the phase so I just added a simple attribute. I'd guess it's an enumeration or a string. Eventually ProjectType is also a simple enum and could be replaced by an attribute within Project (would need investigation).

Answer 3

I think this is the class diagram that suits your requirements:

I have modeled composition associations between Project/ProjectPhase and between ProjectType/Phase, because a Project consists of ProjectPhases and ProjectPhases cannot exist without their Projects and the same is true for ProjectType/Phase.

Employees and ProjectPhases neither have a part-of relationship nor an existency dependency, hence a compositions association is not appropriate here.

In my diagram, an Employee is implicitly assigned to Projects via ProjectPhases, but if you want to stress the relationship between Employees and Projects, you may very well draw an association between these classes explicitly.