In a UML class diagram, how do line styles and arrowheads distinguish generalization, realization, association and dependency?

## Two variables, four relationships Every relationship line in a UML class diagram is decided by two things: the **line style** (solid or dashed) and the **end decoration** (a hollow closed triangle, a thin open arrowhead, or nothing). Learn the two variables and the four common relationships fall out of them, rather than needing to be memorised as four unrelated pictures. | Relationship | Line | End decoration | Points at | What the reader may infer | | --- | --- | --- | --- | --- | | Generalization | solid | hollow closed triangle | the more general classifier | substitutability | | Realization | dashed | hollow closed triangle | the interface | the contract is satisfied | | Association | solid | none, or an open arrow for navigability | — | a link that persists between calls | | Dependency | dashed | thin open arrowhead | the supplier | a transient use; nothing is stored | ## Generalization: the solid triangle A solid line ending in a hollow closed triangle points from the **specific** classifier to the **general** one. The claim is substitutability: anywhere the general type is expected, an instance of the specific one is acceptable, and it arrives carrying the general type's structure and behaviour. That is a strong claim, and it is why the triangle points *up* the hierarchy — the arrow names the type being conformed to, not the direction anything moves at run time. A reader is entitled to infer from it that changes to the general classifier reach every specialization, which makes it the most coupling-heavy of the four lines. ## Realization: the dashed triangle The same hollow closed triangle on a **dashed** line means realization: the classifier at the tail claims to satisfy the contract declared at the head, usually a classifier marked `«interface»`. Nothing is inherited. One class may realize several unrelated contracts without any shared ancestry, and two classes realizing the same contract need have nothing else in common. Collapsing realization into generalization — drawing both solid — is a common error, and it is not cosmetic: it tells a reader the classes are bound together by a shared ancestor when in fact they share only a declared surface. ## Association: the plain line A solid line with no triangle is an association: a **structural** link. The objects know each other over time, which is exactly why the association is the line that carries the extra vocabulary: - **Multiplicity** at each end, saying how many objects participate per object at the far end. - **Role names** at each end, naming the part the class plays in this particular relationship. A class can appear in several associations and play a different role in each, and the role name is what lets a reader say which link is being discussed. - **A name** on the line itself, usually a verb phrase, read in a stated direction. - **Navigability**: an open stick arrowhead on one end says you can get from the tail to the head. An **undirected** line is very often the honest drawing — it says either that both directions are reachable, or that the team has not decided. Drawing an arrow you have not verified asserts a design decision nobody made, and readers will build on it. Diamond decorations may also appear at one end of an association to mark a whole-part reading; the diamond is notation, and what that ownership means for the design is a modelling question in its own right rather than a question about lines. ## Dependency: the dashed open arrow A dashed line with a thin open arrowhead points from the **client** to the **supplier** and says the client uses the supplier *transiently*: as a parameter type, as a return type, or as an object created and discarded within a call. Its whole value is what it refuses to promise — no stored reference, no lifetime obligation, nothing to traverse later. A dependency may be narrowed by a keyword in guillemets, which should be read as the author clarifying what kind of use is meant. Using an association where a dependency is true overstates coupling and sends readers hunting for a stored member that does not exist. Using a dependency where an association is true understates it and hides a link that the design actually keeps. ## What none of these lines entitle you to infer - **Not data flow.** A class diagram is static; an arrowhead names the direction of the *relationship*, never a runtime movement of values. - **Not call order.** Nothing on these lines says what happens first. - **Not implementation.** An association may be realised as a stored member, a lookup, or a query; the line says the link exists, not how it is kept. - **Not completeness.** A page showing three relationships does not claim there are only three. ## Reading an unfamiliar diagram 1. Sort the lines into **solid** and **dashed** — you have just separated structure from claims and uses. 2. Find the triangles, and follow them to identify the type hierarchies and the contracts. 3. Read the remaining solid lines as associations, and read their multiplicities and role names. 4. Read the dashed open arrows last: they are the lightest coupling on the page and rarely change your understanding of the shape.