How to specify "one at a time" in UML?

Viewed 174

I'm making a class diagram with a Classroom and a Course class.

How can I indicate that a Classroom can only have one Course in it at a time? I know I can use multiplicities to specify that a classroom can have exactly one course, but that doesn't exactly specify that there can be other courses than that one course at different times.

2 Answers

First solution and temporal issues

Bruno's solution with a 0..1 multiplicity satisfies your explicit requirement: a Classroom can then indeed hold at most one Course at any given time. But it has as consequence that at this given time:

  • the Classroom doesn't know any other Course that has or will taken place in it.
  • Any other Course that will take place in this Classroom in future does not know at this moment where it will take place.

So if you're in the business of time-table and resource scheduling, this solution will not fulfil the other implicit needs that you didn't mention so far.

Where is the time in your design?

UML provides only limited built-in temporal semantics. You need to add time explicitly in your model. What is missing here is therefore the time slots:

  • the time slot is not necessarily bound to the Course; An "Initiation to C++" course may need several lessons, that could take place in several rooms at different times.
  • the time slot is obviously not either bound to the Classroom.

An intuitive solution

A TimeSlot can be viewed as related to the association of a Course and to a Classroom. For every course taking place in a room, you'll have to manage the start and end time. This is very natural to model as an association class:

enter image description here

This does not address your "unicity" requirement, but it facilitates its expression with a constraint expressed in natural languate: {Timeslots for a same Classroom cannot overlap}. You may also express it more formally in OCL.

An alternative approach

You may also analyse the time problem differently, and consider the Classroom as a service offer, composed of RoomSlots that correspond to time intervals. Each RoomSlot would then associated to 0..1 course as Bruno suggested:

enter image description here

This approach makes the management of the time slots more obvious and independent:

  • you may use fixed time slots of 1 hour, you may allow dynamic time slots by adding, splitting and merging time slots of a same room as needed, always enforcing absence of overlaps.
  • the management of the room availability can be analysed and implemented independently of the room usage
  • Unassociated RoomSlots explicitly shows available rooms (offer) at a given time, and unassigned Courses shows the needs (demand).

The multiplicity is the right way to do, and in your case it is 0..1 because a classroom can be unused => no associated course. A course can be made in different classrooms or even none if outside so I use *.

enter image description here

that doesn't exactly specify that there can be other courses than that one course at different times

I disagree, the association Classroom --- Course does not specify the associated course (and classroom(s)) cannot change, so without additional constraint or setting it readOnly it can change

Related