Class Diagram

The class diagram is the most widely used UML diagram and the backbone of object-oriented design. It models the static structure of a system by showing classes (the blueprints for objects), their attributes (data they hold), their operations (behavior they provide), and the relationships between them. A class diagram is to software what a floor plan is to a building—it shows the structural elements and how they connect without describing the dynamic flow of activity within them.

Class Notation

A class is represented as a rectangle divided into three compartments:

Relationships

Association represents a structural relationship between classes—one class uses or knows about another. Drawn as a solid line between classes:

Multiplicity indicates how many objects participate:

• 1 — exactly one
• 0..1 — zero or one (optional)
• * or 0..* — zero or more
• 1..* — one or more
• 3..7 — specific range

Aggregation (hollow diamond ◇): A "has-a" relationship where the part can exist independently of the whole. A Department has Employees, but Employees exist independently of the Department.

Composition (filled diamond ◆): A stronger "has-a" relationship where the part cannot exist without the whole. If the whole is destroyed, the parts are destroyed too. A House has Rooms—rooms do not exist independently of the house.

Inheritance/Generalization (hollow triangle ▷): An "is-a" relationship. The subclass inherits attributes and operations from the superclass.

Dependency (dashed arrow - - →): A weaker relationship indicating that one class uses another temporarily (as a method parameter or local variable) without storing a reference.

Interface Realization (dashed arrow with hollow triangle): A class implements an interface, providing concrete behavior for the interface's declared operations.

Real-World Example: Online Bookstore

This diagram reveals: Books implement the Searchable interface. Each Book has one Author (who may have many Books). Orders contain OrderItems (composition—destroying the Order destroys its items). Each OrderItem references a Book. Customers have many Orders. The multiplicities and relationship types tell us about data lifecycle and ownership.

Abstract Classes and Interfaces

Abstract classes (italicized name or «abstract» stereotype) cannot be instantiated directly and often contain abstract methods that subclasses must implement.

Interfaces (<<interface>> stereotype) declare method signatures without implementation. Classes that realize an interface must implement all declared methods.

Design Patterns in Class Diagrams

Class diagrams naturally express design patterns. The Strategy pattern, for example:

Best Practices

Show only attributes and operations relevant to the design concern you are communicating. Include multiplicity on all associations. Use the appropriate relationship type (aggregation vs. composition vs. simple association). Keep diagrams focused—a single diagram should not try to show the entire system. Use packages to group related classes. Apply consistent naming conventions (PascalCase for classes, camelCase for methods).