The short answer: a UML class diagram is ready for review when a reader can identify the model's scope, tell what each class is responsible for, read every property and operation without guessing, and translate every relationship end into a plain-language rule. Boxes alone are not a model. The important information is in the types, multiplicities, role names, and relationship semantics between them.
This checklist applies to a design-level domain model: a diagram used to discuss object structure before or during implementation. It is not an ERD, a runtime object snapshot, or a promise that every box maps one-to-one to a source file. The Object Management Group still lists UML 2.5.1 as the current formal UML specification as of August 30, 2026.
Start with the question the diagram must answer
Write one sentence above the drawing before adding a class. For the example, the question is: what object structure is required to price an order and preserve its line items? That scope justifies Customer, Order, LineItem, and Product. It does not justify adding controllers, API routes, repositories, tables, or every field in the production system.
A class diagram becomes unreadable when it tries to answer several review questions at once. If the team also needs to show request order, retries, state transitions, deployment boundaries, or database indexes, use a sequence, state, component, deployment, or ER diagram beside it. Do not force those concerns into more class boxes.
The OMG UML 2.5.1 specification defines a class as a kind of classifier whose features can include properties and operations. That definition gives a practical boundary: a class box should describe what instances know, expose, or do—not merely repeat nouns found in a requirements document.
Review the class boxes before the lines
Use three questions for every class:
- Does the name describe one coherent kind of instance?
Orderdoes;OrderAndPaymentUtilitiesprobably combines responsibilities. - Do the properties describe state that belongs to that instance? The worked
Orderownsstatus, while its customer relationship is drawn once as an association instead of being repeated as a second, possibly contradictory attribute. - Do the operations express behavior at the right level?
total(): Moneystates a responsibility. A long inventory of getters, setters, framework callbacks, and generated methods adds code volume without clarifying the model.
UML property notation can include visibility, name, type, multiplicity, default, and modifiers. Operation notation can include visibility, parameters, return type, multiplicity, and modifiers. Use only the details the review needs, but be consistent. In the figure, - marks private properties and + marks public operations; every shown property has a type, and every shown operation has an explicit return type.
Suppression is allowed. UML says that a compartment or feature can be hidden and that no conclusion should be drawn about omitted content. That is useful only when the drawing states its purpose. “Public contract only” is a defensible filter; silently hiding inconvenient fields is not.
Read multiplicity from the opposite instance
Multiplicity is the most consequential small text on many class diagrams. UML defines it as a constraint on valid collection cardinalities, bounded by a lower and upper value. 1 is equivalent to 1..1; 0..* means zero or more; 1..* means at least one with no stated upper limit.
Read each label from the instance at the other end:
- At the
Orderend ofCustomer—Order,0..*means one customer may be linked to zero or more orders. - At the
Customerend,1means each order is linked to exactly one customer in this model. - At the
LineItemend of the composition,1..*means an order must contain at least one line item. - At the
Orderend,1means each line item is part of exactly one order.
Do not choose multiplicities from today's database sample. “We have never seen an empty order” is not the same as “an empty order is invalid.” Ask about the business rule at every lifecycle point: draft creation, import, deletion, migration, and failure recovery. If the rule changes by state, a note, constraint, or state model may be needed.
Also do not assume that a missing label means 1. For association ends, UML explicitly says that when multiplicity is not shown on the diagram, no conclusion may be drawn about the model's multiplicity. A review drawing should show the values whenever they affect a decision.
Choose association, composition, and generalization deliberately
A plain association says that links may exist between typed instances. Add role names when they make the relationship readable in both directions. Add navigability only when efficient access from one side is part of the model; UML does not make an unmarked end automatically navigable or non-navigable.
Use composite aggregation—the filled diamond—only for a real whole/part lifecycle rule. UML says a part may belong to at most one composite at a time and that deleting the composite deletes its object parts. In the example, Order compositionally owns LineItem: a line item is not retained independently after its order is deleted. Product is a plain association because deleting an order must not delete the catalog product it referenced.
Be cautious with the hollow shared-aggregation diamond. UML says its precise semantics vary by application area and modeler. If the diagram cannot state what the hollow diamond adds beyond a plain association, remove it.
Use generalization—a hollow triangle pointing to the general classifier—when every instance of the specific class is also an instance of the general class and inherits its features. DigitalProduct can specialize Product because every digital product is a product. “Checkout uses Product” is not generalization; it is a dependency or association. “Table A has the same columns as Table B” is not enough either.
The 12-point review checklist
| Review question | Pass condition | Typical failure |
|---|---|---|
| 1. Scope | One sentence says what decision the model supports. | The drawing mixes domain, database, API, and deployment views. |
| 2. Audience | The detail level matches the people reviewing it. | Business reviewers receive framework internals. |
| 3. Class identity | Each class names one coherent kind of instance. | Utility, manager, and data-holder responsibilities are bundled. |
| 4. Responsibilities | Properties and operations explain why the class exists. | Boxes contain nouns but no useful contract. |
| 5. Types | Every displayed property and return value has an understood type. | Names such as data or value hide meaning. |
| 6. Visibility | Visibility is shown consistently or intentionally suppressed. | Some symbols use +/- and others leave readers guessing. |
| 7. Association meaning | Each line can be stated as a sentence about instances. | A line exists only because two source files import each other. |
| 8. End roles | Role names remove directional ambiguity where needed. | Two associations between the same classes are indistinguishable. |
| 9. Multiplicity | Both ends express business-valid cardinalities. | Counts are copied from sample data or labels are reversed. |
| 10. Lifecycle | Every filled diamond has a defensible ownership and deletion rule. | Composition is used as a decorative “strong relationship.” |
| 11. Generalization | Every specific instance is valid wherever the general type is expected. | Inheritance is used for code reuse without an is-a relationship. |
| 12. Traceability | Important rules map back to a requirement, decision, or constraint. | The diagram looks precise but no reviewer can approve its claims. |
Common failure modes
Turning an ERD into a class diagram by changing the box title. A relational model emphasizes tables, keys, and normalization. A UML class model can show behavior, inheritance, navigability, and object lifecycle. The views can inform each other, but foreign-key columns should not be duplicated beside an association unless the implementation mapping is the actual review subject.
Drawing every code class. Generated clients, adapters, exceptions, framework base classes, and DTOs can swamp the domain relationships. Create a separate implementation view if those types matter.
Treating layout as semantics. Proximity, color, and left-to-right placement help reading but do not replace relationship notation. A close box is not associated; a box above another is not its superclass.
Using composition without a deletion rule. Ask what happens to the part when the whole is removed and whether the part can move between wholes. If the answers are unknown, use a plain association until the lifecycle decision is made.
Letting the diagram drift. A design model can be intentionally conceptual, but it should say so. If it claims to describe the implemented public contract, review it with the same change that alters that contract.
Limits and next step
This checklist does not prove that a design is correct, thread-safe, secure, performant, or faithfully implemented. UML permits suppressed details and extension mechanisms, and project conventions can narrow or extend the notation. Record those conventions beside the model and verify consequential behavior in code, tests, schemas, and runtime evidence.
For the next review, write the scope sentence and five instance-level rules before opening a diagram tool. Then draft the model in ChatDiagram's class diagram maker, label both ends of every consequential relationship, and have a reviewer read each one aloud. Any line that cannot be translated into an unambiguous sentence is not finished.