UML Behavioral Diagrams
Model system behavior using Use Case, Activity, and Sequence diagrams
Objectives
By the end of this practical work, you will be able to:
- Create Use Case diagrams to capture system requirements
- Model business processes with Activity diagrams
- Design object interactions using Sequence diagrams
- Choose the appropriate diagram type for different scenarios
- Document system behavior clearly for stakeholders
Prerequisites
- Completed Practical Work 1 (UML Class Diagrams)
- Understanding of basic UML notation
- Access to a diagramming tool
Diagram Types Overview
Use Case Diagram
Purpose: Show what the system does from a user's perspective
Components:
┌─────────────────────────────────────────────┐
│ System │
│ ┌────────┐ │
│ │ Use │ ←─── Oval = Use Case │
│ │ Case │ │
│ └────────┘ │
│ │ │
│ │ ←─── Line = Association │
└───────│─────────────────────────────────────┘
│
┌───┴───┐
│ O │ ←─── Stick figure = Actor
│ /|\ │
│ / \ │
└───────┘
Key elements: Actors, Use Cases, System boundary, Relationships (include, extend)
Activity Diagram
Purpose: Show the flow of activities/actions in a process
Components:
● ←─── Start node (filled circle)
│
▼
┌───────────┐
│ Action │ ←─── Action (rounded rectangle)
└───────────┘
│
▼
◇ ←─── Decision (diamond)
/ \
/ \
▼ ▼
[Yes] [No] ←─── Guards (conditions)
│ │
▼ ▼
┌───┐ ┌───┐
│ │ │ │
└───┘ └───┘
│
▼
◉ ←─── End node (circle with dot)
Sequence Diagram
Purpose: Show how objects interact over time
Components:
┌────────┐ ┌────────┐ ┌────────┐
│ Object1│ │ Object2│ │ Object3│ ←─── Participants
└───┬────┘ └───┬────┘ └───┬────┘
│ │ │
│──message1()──> │ ←─── Synchronous message
│ │ │
│ │──message2()──> ←─── Message to next object
│ │ │
│ │<──response──── ←─── Return message
│ │ │
│<─────────────│ │
│ │ │
▼ ▼ ▼ ←─── Lifelines
Exercise 1: ATM Cash Withdrawal
Scenario
Model the process of withdrawing cash from an ATM. The flow is:
- Customer inserts card
- ATM prompts for PIN
- Customer enters PIN
- ATM validates PIN with bank
- If invalid: Display error, allow retry (max 3 attempts), eject card
- If valid: Continue
- Customer selects "Withdraw Cash"
- Customer enters amount
- ATM checks balance with bank
- If insufficient: Display error, return to menu
- If sufficient: Continue
- ATM dispenses cash
- ATM prints receipt (optional)
- ATM ejects card
Your Task: Create an Activity Diagram
Include:
- All actions in the workflow
- Decision points (PIN validation, balance check)
- Loops for PIN retry
- Fork/join for parallel actions if applicable
PlantUML Starting Point
@startuml
start
:Insert Card;
:Enter PIN;
if (PIN Valid?) then (yes)
:Display Main Menu;
:Select Withdraw;
:Enter Amount;
if (Sufficient Balance?) then (yes)
:Dispense Cash;
:Print Receipt;
else (no)
:Display Insufficient Funds;
endif
else (no)
:Display Invalid PIN;
note right: Max 3 attempts
endif
:Eject Card;
stop
@enduml
Enhance this diagram with the retry logic and all edge cases.
Exercise 2: Online Shopping Checkout
Scenario
Model the interaction between objects during an e-commerce checkout:
- Participants: Customer, ShoppingCart, OrderService, PaymentGateway, InventoryService, EmailService
- Flow:
- Customer clicks "Checkout"
- ShoppingCart validates items are still in stock (calls InventoryService)
- OrderService creates a new Order from cart items
- Customer enters payment details
- PaymentGateway processes payment
- On success: InventoryService reduces stock
- OrderService updates order status
- EmailService sends confirmation
Your Task: Create a Sequence Diagram
Include:
- All participants as lifelines
- Messages with meaningful names
- Return values where appropriate
- Alternative fragment (alt) for payment success/failure
- Activation boxes showing when objects are active
Mermaid Starting Point
sequenceDiagram
participant C as Customer
participant Cart as ShoppingCart
participant Order as OrderService
participant Pay as PaymentGateway
participant Inv as InventoryService
participant Email as EmailService
C->>Cart: checkout()
Cart->>Inv: checkAvailability(items)
Inv-->>Cart: availability status
alt All items available
Cart->>Order: createOrder(items, customer)
Order-->>Cart: order
C->>Pay: submitPayment(orderTotal)
alt Payment successful
Pay-->>C: paymentConfirmation
Order->>Inv: reduceStock(items)
Order->>Email: sendConfirmation(order, customer)
else Payment failed
Pay-->>C: paymentError
Order->>Order: cancelOrder()
end
else Items unavailable
Cart-->>C: stockError
end
Add more detail such as specific method parameters and return types.
Exercise 3: Hotel Reservation System
Scenario
A hotel reservation system with the following capabilities:
Actors:
- Guest - Can search rooms, make/cancel reservations, check in/out
- Receptionist - Same as guest plus: manage rooms, process payments
- Admin - All of above plus: manage staff, view reports
- Payment System - External system for processing payments
Use Cases:
- Search Available Rooms
- Make Reservation
- Cancel Reservation
- Check In
- Check Out
- Process Payment (includes Validate Card)
- Manage Room Status
- Generate Reports
Your Tasks
- Use Case Diagram: Show all actors, use cases, and relationships (include, extend, generalization)
- Activity Diagram: Model the "Make Reservation" process in detail
- Sequence Diagram: Model the "Check Out" process including payment
Use Case Diagram Hints
- Guest, Receptionist, Admin have inheritance relationship (Admin extends Receptionist extends Guest)
- "Process Payment" includes "Validate Card"
- "Make Reservation" extends to "Apply Discount" (optional)
- Payment System is an external actor (secondary actor)
Activity Diagram - Make Reservation
Consider these steps:
- Guest searches for rooms (dates, type, guests)
- System displays available rooms
- Guest selects room
- Guest enters personal details
- System calculates total price
- Guest confirms booking
- System requests payment
- Payment processed (success/failure paths)
- Confirmation sent to guest
Sequence Diagram - Check Out
Participants:
- Guest
- Receptionist
- ReservationSystem
- RoomService
- BillingSystem
- PaymentGateway
Consider: minibar charges, room damage check, receipt generation
Diagram Comparison Guide
| Question | Diagram Type |
|---|---|
| What can users do with the system? | Use Case |
| What are the steps in this process? | Activity |
| How do objects collaborate? | Sequence |
| What states can an object be in? | State Machine |
| How is the system structured? | Class |
Deliverables
Evaluation Criteria
| Criterion | Points | Description |
|---|---|---|
| Completeness | 25% | All required scenarios and paths covered |
| Correct Notation | 25% | Proper use of UML symbols and conventions |
| Clarity | 20% | Diagrams are readable and well-organized |
| Error Handling | 15% | Alternative and exception flows modeled |
| Consistency | 15% | Diagrams align with each other (same concepts) |