Order model — aggregation, composition, and dependency
A small domain model that exercises every relationship-end adornment that confuses first-time UML readers — filled diamond for composition, hollow diamond for aggregation, plain association, and a dashed dependency.
For the domain modeller
Why the diamonds are not interchangeable
UML's two diamond shapes encode genuinely different lifetime semantics, and they're the single most-confused pair on the notation.
Composition (filled diamond) means the part dies with the whole: when an Order is deleted, its LineItems are deleted with it — the line items have no independent existence. The filled diamond sits at the Order (whole) end of *--, regardless of which id the author typed first.
Aggregation (hollow diamond) means the part outlives the whole: an Address exists in its own right and a Customer aggregating it is just a structural reference — deleting the customer should not delete the address.
Plain association (no diamond) is just "these two types are structurally linked" — the line carries multiplicity (1 ↔ *) and a name (places) but makes no claim about ownership.
Dependency (dashed + open arrow) says Order uses TaxPolicy without holding a reference to it — typically a method parameter or a transient call. The dashed line distinguishes a using-relationship from a structural one at a glance.
The {readOnly}, {static}, and {abstract} property strings render as the standard UML annotations; count is underlined to mark it as class-scope.