UML Class Diagram

What this diagram shows

A UML class diagram represents the static structure of a software system by showing classes, their attributes, methods, and the relationships between them. It displays how objects are organised and interact at design time, including inheritance hierarchies, associations, compositions, and dependencies. The diagram maps conceptual entities and their contracts, forming the blueprint that guides implementation across multiple classes and modules.

Key components

• Class — A rectangle divided into three sections showing the class name, attributes with types, and methods with signatures and return types.
• Attribute — A named property with a data type and visibility modifier that represents the state stored in an instance of the class.
• Method — A named function with parameters, return type, and visibility modifier that defines the behaviour a class can perform.
• Inheritance — A solid line with a hollow triangle pointing from the child class to the parent class, showing an is-a relationship.
• Association — A solid line connecting two classes with optional cardinality notation, representing how instances of one class relate to instances of another.
• Composition — A solid line with a filled diamond at the owner end, indicating a strong whole-part relationship where the part cannot exist independently.
• Dependency — A dashed line with an open arrowhead from one class to another, showing that one class uses or depends on the other without ownership.

When to use it

Use a UML class diagram during the design phase to plan the architecture of an object-oriented system before writing code. It is valuable when designing complex domains, communicating designs to team members, or reverse-engineering existing code to understand its structure. It works well for systems with multiple interacting classes where relationships and hierarchies are important to document.

Common mistakes

• Drawing every association with the same cardinality without thinking through whether a relationship is truly one-to-many, one-to-one, or zero-to-many at each end.
• Including implementation details like getter and setter methods or trivial helper functions that clutter the diagram and obscure the core design intent.
• Using inheritance instead of composition when modelling code reuse, leading to brittle hierarchies that are difficult to maintain and extend without affecting subclasses.

Adapting it to your system

Start by identifying the main entities or concepts in your domain and create a class for each one. Add the attributes that define state and methods that represent behaviour. Then draw relationships between classes: use inheritance for specialisation hierarchies, associations for regular connections, composition for ownership, and dependencies for weaker relationships. Adjust visibility modifiers (public, protected, private) to match your design decisions. Remove or simplify classes that are implementation details rather than design decisions.