UML Class Diagram

Complete guide to UML Class Diagrams: learn how to model system structure with classes, attributes, methods, and relationships. Master the most fundamental UML diagram type for object-oriented design.

Table of Contents

• 1. What are Class Diagrams?
• 2. Class Syntax and Notation
• 3. Attributes
• 4. Methods (Operations)
• 5. Relationships
• 6. Visibility Modifiers
• 7. Advanced Concepts
• 8. Best Practices
• 9. Conclusion

1. What are Class Diagrams?

Class diagrams are the most common and fundamental UML diagrams. They show the static structure of a system by depicting classes, their attributes, methods, and the relationships between classes.

Class diagrams are used throughout the software development lifecycle:

• Analysis: Understanding domain concepts and their relationships
• Design: Designing object-oriented systems and APIs
• Implementation: Guiding code structure and organization
• Documentation: Documenting system architecture and design decisions

A class diagram shows what classes exist, what attributes and methods they have, and how classes relate to each other. It does not show the dynamic behavior or the flow of execution.

2. Class Syntax and Notation

2.1 Basic Class Representation

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

1. Name compartment: Contains the class name (required)
2. Attributes compartment: Lists the class attributes (optional)
3. Methods compartment: Lists the class methods/operations (optional)

@startuml class ClassName { - attribute1 + attribute2 + method1() - method2() } note right of ClassName Name compartment: ClassName Attributes compartment: attribute1, attribute2 Methods compartment: method1(), method2() end note @enduml

2.2 Class Name

The class name should:

• Be a noun or noun phrase
• Start with an uppercase letter
• Use PascalCase (e.g., CustomerOrder, PaymentProcessor)
• Be descriptive and meaningful

2.3 Abstract Classes

Abstract classes cannot be instantiated directly. They are shown with the class name in italics or with the keyword {abstract}:

@startuml abstract class AbstractClass { + abstractMethod() } note right of AbstractClass Abstract classes are shown with {abstract} keyword or italic name end note @enduml

2.4 Interfaces

Interfaces define contracts that classes can implement. They are shown with the keyword <> or a circle notation:

@startuml interface IRepository { + save() + findById() } note right of IRepository Interfaces define contracts that classes can implement end note @enduml

3. Attributes

3.1 Attribute Syntax

Attributes are written in the format:

visibility name : type [multiplicity] [= default value]

Example:

- customerId : String
+ balance : Double = 0.0
- items : List<OrderItem> [1..*]
# status : OrderStatus

3.2 Attribute Components

• Visibility: + (public), - (private), # (protected), ~ (package)
• Name: Descriptive name in camelCase
• Type: Data type (String, Integer, Customer, etc.)
• Multiplicity: [1], [0..1], [1..*], [0..*], etc.
• Default Value: Initial value (optional)

3.3 Derived Attributes

Derived attributes are calculated from other attributes. They are shown with a forward slash (/):

+ totalPrice : Double
+ /discountedPrice : Double  ← Derived attribute

3.4 Static Attributes

Static (class-level) attributes are shown with underline or {static}:

+ MAX_ITEMS : Integer {static}
+ instanceCount : Integer  ← Underlined

4. Methods (Operations)

4.1 Method Syntax

Methods are written in the format:

visibility name(parameter1 : type1, parameter2 : type2) : returnType

Example:

+ calculateTotal() : Double
- validateOrder() : Boolean
+ addItem(item : OrderItem) : void
+ findById(id : String) : Order

4.2 Method Components

• Visibility: +, -, #, ~ (same as attributes)
• Name: Verb or verb phrase in camelCase
• Parameters: name : type pairs in parentheses
• Return Type: Data type returned (void if nothing)

4.3 Abstract Methods

Abstract methods have no implementation. They are shown in italics or with {abstract}:

+ calculatePrice() : Double {abstract}
+ processPayment() : void  ← Italic

4.4 Static Methods

Static methods are shown with underline or {static}:

+ getInstance() : Singleton {static}
+ createDefault() : Order  ← Underlined

5. Relationships

5.1 Association

Association represents a general relationship between classes. It's shown as a solid line connecting classes.

@startuml class Order class Customer Order "1" -- "*" Customer : placedBy note right of Order Association represents a general relationship between classes end note @enduml

Properties:

• Can have role names (e.g., "placedBy", "hasOrders")
• Can have multiplicity (1, *, 1..*, 0..1)
• Can be bidirectional or unidirectional (arrow)

5.2 Aggregation

Aggregation represents a "has-a" relationship with weak ownership. The part can exist independently. Shown with a hollow diamond.

@startuml class Team class Member Team "1" o-- "*" Member : has note right of Team Aggregation: "has-a" relationship with weak ownership. The part can exist independently. end note @enduml

5.3 Composition

Composition represents a "has-a" relationship with strong ownership. The part cannot exist without the whole. Shown with a filled diamond.

@startuml class Order class OrderItem Order "1" *-- "*" OrderItem : contains note right of Order Composition: "has-a" relationship with strong ownership. The part cannot exist without the whole. end note @enduml

5.4 Generalization (Inheritance)

Generalization represents an "is-a" relationship (inheritance). Shown with a hollow triangle arrow.

@startuml class Animal { + move() } class Dog { + bark() } Dog --|> Animal note right of Animal Generalization: "is-a" relationship (inheritance). Shown with hollow triangle arrow. end note @enduml

5.5 Realization (Implementation)

Realization represents a class implementing an interface. Shown with a dashed line and hollow triangle.

@startuml interface IRepository { + save() + findById() } class OrderRepository { + save() + findById() } OrderRepository ..|> IRepository note right of IRepository Realization: class implementing an interface. Shown with dashed line and hollow triangle. end note @enduml

5.6 Dependency

Dependency represents a "uses" relationship where one class depends on another. Shown with a dashed arrow.

@startuml class Order { + placeOrder() } class Logger { + log() } Order ..> Logger : uses note right of Order Dependency: "uses" relationship where one class depends on another. Shown with dashed arrow. end note @enduml

6. Visibility Modifiers

Symbol	Name	Description
+	Public	Accessible from anywhere
-	Private	Accessible only within the class
#	Protected	Accessible within the class and subclasses
~	Package	Accessible within the same package

7. Advanced Concepts

7.1 Multiplicity

Multiplicity specifies how many instances participate in a relationship:

• 1: Exactly one
• 0..1: Zero or one (optional)
• 1..*: One or more
• 0..* or *: Zero or more
• 2..5: Between 2 and 5

7.2 Constraints

Constraints specify rules that must be satisfied. Shown in curly braces:

{ordered}  - Elements are ordered
{unique}   - Elements are unique
{readOnly} - Cannot be modified
{immutable} - Cannot change after creation

7.3 Stereotypes

Stereotypes extend UML vocabulary. Shown with guillemets:

<>
<>
<>
<>

7.4 Notes

Notes provide additional information. Shown as a rectangle with a folded corner:

@startuml class Order { + placeOrder() } note right of Order Notes provide additional information about classes or relationships end note @enduml

8. Best Practices

8.1 Naming Conventions

• Use PascalCase for class names (CustomerOrder)
• Use camelCase for attributes and methods (customerId, calculateTotal)
• Use descriptive names that clearly indicate purpose
• Avoid abbreviations unless widely understood

8.2 Organization

• Group related classes together
• Use packages to organize large diagrams
• Show only essential relationships to avoid clutter
• Create multiple diagrams for different views

8.3 Detail Level

• Show only relevant attributes and methods
• Use different diagrams for different audiences
• Hide implementation details when not needed
• Focus on public interface for high-level views

8.4 Relationships

• Use appropriate relationship types (don't use inheritance for "has-a")
• Show multiplicity when it's not obvious
• Use role names to clarify relationships
• Avoid circular dependencies

9. Conclusion

Class diagrams are the foundation of UML modeling. They provide a clear, visual representation of system structure that helps teams communicate, design, and document software systems effectively.

Mastery of class diagrams involves understanding not just the syntax, but also when and how to use different relationship types, how much detail to include, and how to organize diagrams for maximum clarity and usefulness.

Next Topic: Object Diagrams - Learn how to show object instances and runtime snapshots of your system.