# Common Class Diagram Modeling Mistakes

**In short:** Class diagrams often repeat the same errors: impossible multiplicities, shared parts in a composition, missing multiplicity, and wrong arrows. Knowing them helps you review diagrams, even though tools catch some automatically.

## Explanation

A class diagram (see UML Class Diagram) shows classes and the links between them. A few mistakes appear again and again. A reviewer can check for them one by one.

**Invalid multiplicity.** Multiplicity says how many objects take part in a link. It has a lower bound (the minimum) and an upper bound (the maximum). The upper bound must be at least as large as the lower bound. A range such as "5 to 2" is invalid.

**Missing multiplicity.** Some diagrams leave multiplicity off association lines. Developers then have to guess the rules of the system.

**Composition errors.** Composition is drawn with a filled diamond. It means exclusive ownership. A part cannot belong to several wholes. Deleting the whole deletes its parts. A part shared by two wholes breaks this rule.

**Aggregation.** A hollow diamond marks a whole-part grouping without exclusive ownership. If you are unsure that composition applies, a plain association is the safer choice. See Aggregation vs. Composition.

**Inheritance mixed up with whole-part.** Designers often confuse "is-a" (inheritance) with "has-a" (whole-part). Generalization then appears where composition or association was meant. See UML Generalization and Specialization.

**Wrong arrows.** Dependency, realization and generalization each have their own arrow. A wrong arrow changes the meaning. A dashed arrow is a dependency. A dashed line with a hollow triangle is realization. A stored reference should be an association. A dependency is a transient use, such as a parameter. Mixing these up is a typical error.

**Tool support.** Modeling tools can catch some errors. The Umple compiler, for example, reports a multiplicity error and highlights the offending line.

## Example

A shop diagram links Order to Customer with the multiplicity "3..1". A reviewer flags it, because the upper bound is below the lower bound. The same diagram draws a filled diamond from both Order and Shipment to Address. The reviewer flags this too: a composed part cannot have two wholes. The team changes both links to plain associations and adds a multiplicity to each.

## Trade-offs

Tools find mechanical errors such as an invalid multiplicity. They cannot tell whether a link means the right thing. Choosing between composition, aggregation and plain association still needs human judgment. When unsure, the plain association is the safer choice. It claims less about ownership.

Invalid composition: one part has two wholes.

```plantuml
@startuml
class Order
class Address
class Shipment
Order "1" *-- "1..*" Address : wrong
Shipment "1" *-- "1..*" Address : wrong
note bottom of Address : One part with two wholes
@enduml
```

## Checks

- No multiplicity has a lower bound greater than its upper bound.
- Every association line states its multiplicity.
- No part in a composition (filled diamond) belongs to more than one whole.
- Dependency, realization and generalization arrows match their intended meaning.
- Generalization is used only for is-a relationships, not for whole-part ones.

## Related

- [UML Class Diagram](https://arc.fuet.ch/concepts/modeling-uml/class-diagram.md)
- [UML Class Diagram Relationship](https://arc.fuet.ch/concepts/modeling-uml/class-diagram-relationships.md)
- [Aggregation vs. Composition](https://arc.fuet.ch/concepts/modeling-uml/composition-versus-aggregation.md)
- [UML Association](https://arc.fuet.ch/concepts/modeling-uml/association.md)
- [UML Generalization and Specialization](https://arc.fuet.ch/concepts/modeling-uml/generalization-and-specialization.md)
- [UML Modeling Anti-Pattern](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-anti-patterns.md)
- [UML Modeling Best Practice](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-best-practice.md)
- [Common Component Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/component-diagram-modeling-mistakes.md)

## Sources

- [](https://site.uottawa.ca/~tcl/gradtheses/mnojoumian/ThesisFiles/FinalSpec/UML/7.3.32.html) — site.uottawa.ca, accessed 2026-11-09
- [Umple User Manual: Multiplicity](https://cruise.umple.org/umple/Multiplicity.html) — cruise.umple.org, accessed 2026-11-09
- [UML Class Diagrams | SE Book](https://tobiasduerschmid.github.io/SEBook/uml_class_diagram.html) — tobiasduerschmid.github.io, accessed 2026-11-09
- [The Comprehensive Guide to UML 2.5 for Modern Software Teams](https://www.visual-paradigm.com/guide/the-comprehensive-guide-to-uml-2-5-for-modern-software-teams/) — visual-paradigm.com, accessed 2026-11-09