# Time consideration in multiplicity of classes

In the following image, regarding a CD shop that rents its music CDs.

My question is regarding the correct multiplicity of X. I can think of several possibilities for X:

1. X= 1..1 as each copy of CD can rented by one member only at one time. All copies are assumed to be rented at some point.
2. X= 0..1 as each copy of CD may be rented by one member only at one time. Perhaps some CDs are never rented out.
3. X= 0..N as each copy of CD may be rented to any member during CD's lifetime at the shop (but it should not be at the same time)

Could you please clarify this point for me?

• Seems to me you are missing an entity, Rental, which would serve as a junction table between Member and CD, and include the start and end dates, among other things. Your business rule is that the rentals for a CD may not overlap, i.e. only one member can rent a CD at a time. Commented Nov 18, 2021 at 0:56

The multiplicities represent the number of possible links between instances of the associated classes, i.e. at any guiven moment in time.

1. 1..1 is highly improbable here since it would mean that every `CD` is rented out at any given moment in time to exactly one `Member`. This would require that for every CD returned to the shop there’s immediately another customer ready to rent it instantly.

2. 0..1 is a very reasonable approach if your design intends to show the current situation of CD with no history: at any moment in time a CD is either rented by a member or not, but the same CD would not be linked anymore to the members who previously rented it. This kind of design could make sense in many cases. But in a rental business it's less practical: you sometimes need to find the customer who rented it before the cursomer who is on the phone because she realised the jacket is empty.

3. 0..* is also a very reasonable approach, especially if you want to keep track of the rental history. It does not say however what the multiple members mean. You could therefore enrich the diagram with a constraint specifying that there cannot be overlaps in the rental periods.

• Thanks for the answer. I did not know about constraints in class diagrams. If multiplicities represent the number of possible links between instances of the associated classes, i.e. at any given moment in time, doesn't that mean option 3 (as is and without constraints) is not correct? How would one show history and constraints then (whether in design or implementation)? Commented Nov 17, 2021 at 3:44
• @user17302 option 3 would not be incorrect without constraints. It's the meaning of the association that is different. For option 2 it would mean "(now still) renting" whereas in option 3 it would mean "rented (including the ones not yet returned)". The constraint is not required for option 3, it's just a possibility we have to express additional knowledge. In a real-world renting application, I'd probably go for 3 (many to many association), and would make it an association class, to keep track of the renting periods, billing details and other time dependent properties. Commented Nov 17, 2021 at 7:59
• @user17302 unfortunately the name of the association doesn't help to disambiguate: "rent" is in the present which is common practice for association names regardless of the chronolgy of the association. "rented by" could suggest an historical perspective ("by whom was this CD rented last year") but one can argue that it's just the passive of "rent". If it's an exercise you'd need to find some other clues. In the real life, you'd disambiguate in a conversation with the shop owner. Commented Nov 17, 2021 at 8:06
• There could even be two relationships, one 0..1 for who is renting it now, and also a 0..N for the rental history. Commented Nov 17, 2021 at 10:43
• @SimonB indeed. And one could even be a subsetting of the other (or a derived of the other, with the / notation) Commented Nov 17, 2021 at 13:20