Příklady UML diagramů tříd

The diagram above is worth reading relationship by relationship. Book and DVD generalize LibraryItem, which is drawn as a hollow triangle pointing at the parent - and the reason to draw it that way rather than as two unrelated classes with duplicated attributes is the association below it. Loan points at exactly one LibraryItem, and because it points at the abstract parent it can lend either subtype without knowing which.

That is the whole test for inheritance in a domain model: not "do these two things feel similar", but is there somewhere in the model that wants to hold either one without caring which. If nothing does, two separate classes are the smaller and more honest answer.

Note the multiplicities on the Member-to-Loan association: 1 to 0..*. A member with no loans is a member; a loan with no member is a bug. That asymmetry is a real fact about the domain and it is stated on the line rather than left to a comment. The class diagram article covers how each of those symbols is drawn.

This one contains no inheritance at all, and that is the point of showing it beside the library. What it has instead is a composition and an interface, and each is there for a reason the other diagram had no use for.

The filled diamond between Basket and BasketLine is a claim: delete the basket and the lines go with it, because a basket line is meaningless on its own. Compare it with the plain association from BasketLine to Product, where the product obviously outlives the line - the same shape of relationship, two different lifetimes, and the notation distinguishes them.

PricingRule is the extension point. Two realizations are drawn because one realization is not an abstraction, it is a class with an extra step - and the moment there are two, adding a third promotion is a new class rather than a new branch in an existing method.

Both diagrams reward the same reading order, and it is not left to right. Start with the multiplicities, because they are the decisions: they say what the system permits and they are the hardest thing to change later. Then read the diamonds, which say what gets deleted with what. Then the triangles, which say what can stand in for what. Attributes last, and only the ones you doubt.

A diagram that survives that reading is worth keeping. One where the multiplicities are blank is not finished, however many attributes it lists - and that is by far the most common state to find a class diagram in.

Next: how to draw one from scratch, and the symbol reference for checking a mark you are unsure of.