So your designing some application, let’s say for a library. Being the DDD guy that you are, you talk to a clerk at the library and she tells you that the system under development should save the fact that a book is lent out by a specific reader. So you choose to model that fact like this:

You present this diagram to the library manager and he’s slightly confused: “What’s that? Our books are lent out by hundreds or thousands of people. Your design supports only one reader!”

You answer: “No, no. This model only says that a book is lent out by a single reader at a given time.

What happened here is that the library manager and you had a different idea of what portion of time the UML model represented. For you, the cardinalities shown in the diagram represented so called Snapshot Cardinalities, ie. cardinalities that occur at a single point in time. E.g. at any given moment, a book is lent by not more than one reader. The manager looked from a different perspective and interpreted the cardinalities as being historic. Throughout the lifetime of a book it is lent out by many readers, therefore his confusion.

The moral of the story

• don’t assume that everyone looking at an UML diagram has the same idea of the semantics of numbers (or arrows for that matter).
• be aware that we can have snapshot cardinalities as well as historic cardinalities. Most of the time you’ll use snapshot cardinalities because that’s what you’ll probably use in your code later on. Nevertheless, make that clear to the people with which you’re talking about the diagram
• don’t mix different types of cardinalities, or be very explicit if you do so

For the interested reader I recommend R.J. Wieringa, Design Methods for Reactive Systems (Amazon)