🎯 Complete UML & Software Engineering Diagrams Guide
Use Case Diagram
Behavioral • Requirements📍 When to Use:
Use when you need to show WHO (actors) can do WHAT (use cases) with the system. Perfect for capturing functional requirements and system boundaries.
Example Use Case diagram (ATM system) from the course slides.
Actor
External entity (user, system, or time) that interacts with the system
Use Case
A distinct functionality or action the system performs
System Boundary
Rectangle that defines the scope of the system
Relationships:
→
Association: Simple line connecting actor to use case
--→ <<include>>
Include: Dotted arrow - base use case ALWAYS includes the included use case
--→ <<extend>>
Extend: Dotted arrow - extending use case MAY be triggered conditionally
─▷
Generalization: Solid arrow with hollow triangle - inheritance relationship
Real Exam Example - ATM System
"An ATM system allows the bank customer to withdraw cash, deposit funds, and transfer funds. Any time the customer wants to make these transactions, the system should validate the user. When withdrawing cash, if insufficient funds, a separate use case handles this. If withdrawing above daily limit, 'exceeds limits' case runs. A maintenance person refills the ATM periodically."
Solution Approach:
- Actors: Customer, Maintenance Person, Bank System
- Main Use Cases: Withdraw Cash, Deposit Funds, Transfer Funds
- Include: Validate User (included by all transactions)
- Extend: Handle Insufficient Funds, Exceeds Daily Limit (extend Withdraw Cash)
- Additional: Refill ATM (by Maintenance Person)
💡 Exam Tips & Tricks:
- Always identify ALL actors first - look for roles, not specific people
- Use INCLUDE when something MUST happen (validation, authentication)
- Use EXTEND for optional/conditional scenarios (error handling, special cases)
- System boundary contains use cases ONLY, actors stay outside
- Name use cases as verb + noun (e.g., "Withdraw Cash", "Validate User")
Class Diagram
Structural • Static📍 When to Use:
Use to show the STRUCTURE of the system - classes, their attributes, methods, and relationships. Essential for object-oriented design.
Example UML Class diagram (Bank / ATM / Account) from the course slides.
Class
Rectangle with 3 sections: Name, Attributes, Operations
+ public
- private
# protected
~ package
Visibility
Access modifiers for attributes and methods
Relationships:
──────
Association: Simple line with multiplicity (1, 0..1, *, 1..*, etc.)
- - - - →
Dependency: Dashed arrow - one class uses another temporarily
──▷
Generalization: Solid line with hollow triangle - inheritance (IS-A)
──◇
Aggregation: Line with hollow diamond - HAS-A (parts can exist independently)
──◆
Composition: Line with filled diamond - OWNS (parts cannot exist without whole)
Real Exam Example - Company Employee System
"A system tracks companies and their employees, managers and contractors. Each company has one or more employees. For each employee: employee number, name, salary. Each company has name and address. Each manager is an employee that supervises other employees. Some employees are contractors with contract length."
Solution Approach:
- Classes: Company, Employee, Manager, Contractor
- Inheritance: Manager and Contractor inherit from Employee
- Aggregation: Company has Employees (1..*)
- Association: Manager supervises Employees (1..*)
- Attributes: Company (name, address), Employee (empNumber, name, salary), Contractor (+contractLength)
💡 Exam Tips & Tricks:
- Always check multiplicity: 1 (exactly one), 0..1 (optional), * (many), 1..* (at least one)
- Aggregation (◇) = "uses a" - Team HAS Players (players can exist without team)
- Composition (◆) = "is part of" - House HAS Rooms (rooms can't exist without house)
- Look for IS-A relationships for inheritance (Manager IS-A Employee)
- Derived attributes start with "/" (e.g., /age calculated from birthDate)
Sequence Diagram
Behavioral • Dynamic📍 When to Use:
Use to show HOW objects interact over TIME. Perfect for modeling the flow of messages in a specific scenario.
Example Sequence diagram (View patient information) from the course slides.
Lifeline
Object/Actor with vertical dashed line showing time
Activation Box
Rectangle showing when object is active/processing
Synchronous Message
Solid arrow - sender waits for response
Asynchronous Message
Line arrow - sender doesn't wait
Return Message
Dashed arrow returning to sender
Real Exam Example - Database Transaction
"Consider a sequence diagram with c:Client and p:ODBCProxy. Client creates Transaction, sets actions(a,d,o), sets values(d,3,4), sets values(a,'CO'), then commits."
Key Elements to Identify:
- c:Client is the notation for an object named 'c' of class 'Client'
- The vertical dotted line is the lifeline
- The narrow rectangle on lifeline is activation (when object is processing)
- setValues(d,3,4) is a method call with parameters
- ODBCProxy is the suitable class for database operations
💡 Exam Tips & Tricks:
- Time flows from TOP to BOTTOM - earlier messages are higher
- Alt frame = if-then-else, Loop frame = repetition, Opt frame = optional
- Self-message: arrow that loops back to same object
- Object creation: message pointing to object box (not lifeline)
- Object destruction: X at end of lifeline
Activity Diagram
Behavioral • Flow📍 When to Use:
Use to show WORKFLOW or PROCESS FLOW. Like an advanced flowchart with parallel activities and swimlanes.
Example Activity diagram (Reservation process) from the course slides.
Initial Node
Filled circle - starting point
Final Node
Bull's eye - end point
Activity/Action
Rounded rectangle - a task or action
Decision Node
Diamond - conditional branching
Fork/Join Bar
Thick line - split/merge parallel flows
Swimlanes
Vertical/horizontal partitions for different actors
Real Exam Example - Flight Check-in Process
"A passenger checks in before flight. Shows ticket at check-in desk. Passenger services verify ticket. If OK, passenger checks luggage and services accept it. If not OK, referred to customer service. Once luggage accepted, check if subject to fees. If yes, passenger pays fees then gets boarding pass, otherwise gets boarding pass directly."
Solution with Swimlanes:
- Swimlane 1: Passenger - Show Ticket, Check Luggage, Pay Fees
- Swimlane 2: Passenger Services - Verify Ticket, Accept Luggage, Check Fees, Issue Boarding Pass
- Swimlane 3: Customer Service - Handle Invalid Tickets
- Decision Points: [Ticket OK?], [Fees Required?]
- Flow: Sequential with conditional branches
💡 Exam Tips & Tricks:
- Fork (─) splits into parallel activities, Join (─) merges them back
- Decision (◇) has ONE input, MULTIPLE outputs with guards [condition]
- Merge (◇) has MULTIPLE inputs, ONE output (no conditions)
- Swimlanes group activities by actor/department - use when multiple actors involved
- Object nodes [rectangles] show data flowing between activities
State Machine/Statechart Diagram
Behavioral • State Transitions📍 When to Use:
Use to show how an object changes STATES in response to EVENTS. Perfect for modeling lifecycle of objects.
Example State diagram from the course slides.
Initial State
Filled circle - starting state
Final State
Bull's eye - ending state
State
Rounded rectangle - a condition/situation
Transition
Arrow with event, optional guard and action
Composite State
State with internal activities
Real Exam Example - Microwave Oven
"A microwave has a switch for full/half power, numeric keypad for cooking time, start/stop button, and alphanumeric display."
States & Transitions:
- States: Idle, Set Power, Set Time, Cooking, Paused, Complete
- Initial State → Idle: System starts
- Idle → Set Power: Power button pressed
- Set Power → Set Time: Time button pressed
- Set Time → Cooking: Start button pressed
- Cooking → Paused: Stop button pressed
- Cooking → Complete: Timer expires
💡 Exam Tips & Tricks:
- Self-transition: arrow loops back to same state (state doesn't change)
- Guard conditions in square brackets: [balance > 0]
- Actions after slash: buttonPressed/lightOn
- Entry/Exit actions: performed when entering/leaving state
- Fork (─) and Join (─) for concurrent states
Exam Strategy: Choosing the Right Diagram
📝 Read the Scenario Keywords:
- "actors", "users", "system functions" → Use Case Diagram
- "classes", "attributes", "inheritance", "has-a" → Class Diagram
- "message flow", "interaction", "time sequence" → Sequence Diagram
- "workflow", "process", "parallel activities" → Activity Diagram
- "states", "transitions", "events", "lifecycle" → State Diagram
🏆 Universal Exam Tips:
- Always draw a rough sketch first before the final diagram
- Label EVERYTHING - no unlabeled arrows or relationships
- Show multiplicity in class and use case diagrams (1, *, 0..1, 1..*)
- Use proper UML notation - don't invent your own symbols
- Include a legend if using any non-standard notation
- For scenarios, identify actors/objects FIRST, then actions/relationships
- When in doubt, add a note to explain your reasoning