In a UML class diagram, what does the multiplicity at each end of an association tell you?
answer
- Numbers written at the ends of a line
- A range: lowest allowed, highest allowed
- Read the end away from where you stand
- Zero as the lower bound changes everything
basics
~20 sMultiplicity at an association end says how many objects of that end's class may be linked to one object at the far end. It is a range: 0..1 optional, 1 exactly one, 1..* one or more, * any number.
solid answer
~50 sEvery association end may carry a **multiplicity**: a lower and an upper bound written `lower..upper`, where `1` is shorthand for `1..1` and `*` is shorthand for `0..*`. Read it from the *opposite* end — the number written next to a class says how many of that class one object at the other end is linked to. So `GroceryOrder 1 —— 1..* OrderLine` says an order has at least one line and each line belongs to exactly one order. A lower bound of zero makes the link **optional**, and that is the bound that changes code, because every traversal now has to handle absence. An upper bound above one turns the end into a collection, and `{ordered}` or `{unique}` beside it say whether position matters and whether duplicates are allowed. Attributes take multiplicity too, written in brackets after the type.
code
pseudocode · 7 lines[ DeliverySlot ] 0..1 ---------------- 0..23 [ GroceryOrder ]
one order sits in at most one delivery slot
one delivery slot holds up to twenty-three orders
[ GroceryOrder ] 1 ------------------- 1..* [ OrderLine ]
one line belongs to exactly one grocery order
one grocery order has at least one linego deeper
Be able to read the common forms on sight — 1, 0..1, star and 1..star — and say which end of the line each one applies to. Interviewers usually hand you a small diagram and ask you to say it back in one sentence.
Explain the lower and upper bound form, what an optional end costs in code, and what the ordered and unique constraints add. Expect to be asked to write the multiplicities yourself for a small domain.
Show that multiplicity is where the diagram carries what the source does not: a collection type says many, not at least one and not at most twenty-three. Be ready to say which bounds you would actually enforce and where.
Own the convention. Decide whether unmarked ends are acceptable on your team's diagrams at all, since an unstated bound is the cheapest way for two reviewers to walk out agreeing on different designs.
## What a multiplicity is An **association** in a UML class diagram is a line between two classifiers, and each **end** of that line may carry a **multiplicity**: a range written `lower..upper` constraining how many objects may sit at that end of a single link. `1` is shorthand for `1..1`. `*` is shorthand for `0..*` and means any number, including none. These bounds are part of the model, not decoration — they are often the most informative marks on the page, because they state facts the source code leaves implicit. ## Which end do you read? The rule that catches people out: **a multiplicity applies to the class at its own end, and answers the question 'how many of these, for one object at the far end?'** On `GroceryOrder 1 ————— 1..* OrderLine` the `1..*` next to *OrderLine* says one grocery order has one or more lines, and the `1` next to *GroceryOrder* says each line belongs to exactly one order. To read a line, stand on one class and look at the number written at the **other** end. Getting this backwards inverts the design, and it is the single most common misreading of a class diagram. ## The notations you will meet | Written | Reads as | What it usually implies | | --- | --- | --- | | `1` | exactly one | the link is mandatory and single | | `0..1` | at most one | an optional single link; every read must handle absence | | `*` | zero or more | a possibly empty collection | | `1..*` | one or more | a collection that may never be empty | | `0..23` | up to twenty-three | a bounded collection whose ceiling somebody must enforce | | `2..4` | between two and four | both bounds are rules, not hints | ## The lower bound is the half that changes the code Raising or lowering the upper bound is a typing change; moving the lower bound is a semantic one. - Moving an end from `1` to `0..1` legalises absence. Every traversal becomes conditional, and somebody has to decide what a missing link *means* — not yet assigned, deliberately unassigned, or an error. - Moving `1..*` to `*` legalises the empty collection, which is a different question from the collection being absent, and screens and reports have to render both. - A specific upper bound is a business rule the diagram is stating. In a regional grocery-delivery product, a delivery slot marked `0..23` at the order end says a slot holds at most twenty-three orders — a claim the diagram makes and some part of the system must enforce, because no collection type enforces it for you. ## Multiplicity on attributes, and the constraints beside it Multiplicity is not only for association ends. An attribute takes one in brackets after its type — `notes : Text [0..2]` says up to two notes. Two constraints commonly ride alongside an end whose upper bound exceeds one: - **`{ordered}`** — the position of the linked objects is part of the model, so the end is a sequence rather than an unordered group. - **`{unique}`** — the same object may not appear twice at that end. Read together they separate a sequence, a set and a collection that allows repeats. Where the distinction matters to the design, write the constraint rather than relying on a reader to assume a default; two readers will assume different ones. ## An end left unmarked An end drawn with no multiplicity leaves the count **unstated** rather than asserting one. Readers fill the gap, and they fill it differently: some read exactly one, some read many. If the count carries design weight — above all the difference between a mandatory and an optional end — write it. An unmarked end is the cheapest way for two people to leave the same review agreeing on different designs. ## What multiplicity does not say - **Nothing about ordering**, unless `{ordered}` is written next to it. - **Nothing about lifetime or ownership.** That two objects must be linked says nothing about which of them is responsible for the other's existence. - **Nothing about which side stores the reference.** How the link is realised is a separate question, and navigability marks on the line, not multiplicity, speak to direction. - **Nothing about the total population.** `0..23` bounds one slot's orders, not the number of orders in the system. - **Nothing about enforcement.** A bound on a diagram is a claim; validation, storage constraints and code are where it becomes true. ## Why interviewers ask it Multiplicity is where a class diagram carries information the source rarely states plainly. A collection-typed member says *many*; it does not say *at least one*, and it does not say *at most twenty-three*. A single reference does not say whether absence is legal. Reading and writing these bounds accurately is the difference between a diagram that answers questions and one that decorates a page.
- An association end is left with no multiplicity at all. What may a reader conclude?Nothing reliable. An unmarked end leaves the count unstated, and readers fill the gap with different assumptions — some read exactly one, others read many. Where the count carries design weight, and especially where the difference between a mandatory and an optional end matters, write it on the diagram rather than leaving it to be inferred.
- Which half of a multiplicity range usually has the larger effect on the resulting code?The lower bound. Moving an end from one to zero-or-one makes every traversal conditional and forces a decision about what absence means, which ripples through validation, storage and every screen that shows the link. Raising the upper bound turns a single reference into a collection, which is a bigger typing change but a smaller semantic one.
- What do the constraints ordered and unique add to an end whose upper bound is above one?Ordered says the position of the linked objects is part of the model, so the end is a sequence rather than an unordered group. Unique says the same object may not appear twice at that end. Together they separate a sequence, a set and a collection allowing repeats, which a bare star leaves entirely open.
saying these in an interview costs you the question
- Says an unmarked end implicitly means exactly one
- Treats 0..1 and 1 as equivalent in practice
- Reads star as many rather than zero or more
- Reads a multiplicity as the total number of objects
- Assumes multiplicity says which side stores the reference
- Thinks an upper bound above one implies an ordered collection