I am working on a class diagram for my internship. I have encountered a situation that I haven’t seen before, and I’m not entirely comfortable with the approach I’ve taken. Here are the relationships I need to model:
-
Employee and OrderMission:
- An Employee can be responsible for multiple OrderMissions, but each OrderMission can have only one responsible Employee.
- An Employee can participate in many OrderMissions as an accompanying person, and each OrderMission can have multiple accompanying Employees.
-
Employee and Department:
- An Employee is assigned to one Department only, but each Department can have many Employees.
- An Employee can be the chief of one Department only, and each Department can have only one chief.
I would greatly appreciate any guidance or suggestions on how to properly model these relationships in a class diagram.
this is what i tried.
Yassine Riahi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
5
I’ll use Mission instead of MissionOrder or OrderMission.
First of all an employee CAN be responsible or CAN accompany a Mission. This means that not all employees are necessarily linked to a mission (think for example of new employees before they get a role in their first mission). Consequently, on the Mission end, the multiplicities should be 0..* (or shortcut *).
We understand that any Mission requires a responsible, so 1 is ok. But do every missions have accompanying persons ? Moreover, in the lifecycle of a mission, when a new mission is created, are the accompanying persons known from the start? If the answer to either of these questions is no, the multiplicity on the Employee end should be 0..*.
On the employee/department it’s likewise. The 1 on the Department side of work is ok. But it is not clear feom yor narrative if a department must have at least one employee. Assuming that the chief is also working for the department 1..* is ok. If not sure (e.g. a department could be created and the chief os only assigned later) prefer 0..*.
The chef association is not ok: not all employees manage a department. So on the department end, it should be 0..1.
The + on the associations end are for public visibility. If you’d use it, better add the role name, i.e. the name you would give to the property of the class at the opposite end that would refer to the class at the end of the association. In other words, it’s much less ambiguous to write department next to the + on the end of the chief association on the Department class, than having an attribute department:Department.
8