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:

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:

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).