Activity Diagrams in UML
Overview
Activity diagrams (活动图) model the flow of activities in a system, showing the sequence of actions from start to finish.
Key Definition: An activity is a state of doing something - either a real-world process or software execution.
4 Main Purposes of Activity Diagrams
1. Model Business Processes (High Level)
- Used early in SDLC (Software Development Life Cycle)
- Can model both existing (manual) systems and new computerized systems
- Swimlanes (泳道) show responsibilities: who (people), where (location), hardware, or departments
- Set clear context/scope with appropriate diagram title
2. Describe System Functions (Use Cases)
- Details how a specific use case works
- Used during requirements elaboration phase
- Shows step-by-step process of system functions
3. Describe Operation Logic
- Models low-level details of specific operations
- Shows how particular methods/functions execute
- Example:
Campaign:calculateCost()operation
4. Model USDP Activities
- USDP = Unified Software Development Process
- Shows how development activities relate and organize
Core Components & Notation
Basic Elements
| Component | Symbol | Purpose |
|---|---|---|
| Start State | ● (filled circle) | Beginning of process |
| End State | ⊙ (circle with dot) | End of process |
| Activity | Rounded rectangle | Action/task being performed |
| Transition | → (arrow) | Flow between activities |
| Decision | ◇ (diamond) | Branching point with conditions |
| Guard Condition | [condition] | Text in brackets showing branch condition |
Advanced Elements
| Component | Symbol | Purpose |
|---|---|---|
| Synchronization Bar (Fork) | ━ with multiple arrows out | Start parallel activities |
| Synchronization Bar (Join) | ━ with multiple arrows in | Wait for all parallel activities to complete |
| Swimlanes | Vertical/horizontal sections | Show responsibilities/actors |
| Object Flow | Dashed arrow to/from object | Shows object state changes |
| Object | :ClassName[state] | Represents object instances |
Object Flows
Object flows (对象流) show dependencies between objects and activities that change object states.
- Format:
:ClassName[state] - Example:
:Stock[old]→ Activity →:Stock[updated] - Not all activities change object states
Creating Activity Diagrams - Step by Step
Basic Steps
- Identify activities - List all actions/tasks
- Organize in sequence - Add transitions between activities
- Identify alternatives - Find decision points and conditions
- Add guard conditions - Label branches with [conditions]
- Identify repetitions - Find loops and iterative processes
- Add loop conditions - Show when to repeat/exit
Adding Swimlanes
- Check responsibilities - Are all activities done by same actor?
- Name swimlanes - Label each lane with actor/department
- Place activities - Put each activity in correct swimlane
Adding Objects
- Identify object flows - Find objects that change state
- Add objects and flows - Show state changes with dashed arrows
Key Concepts for Exams
Synchronization Bars
- Fork: Starts multiple parallel activities (order doesn’t matter)
- Join: Waits for ALL parallel activities to complete before continuing
Decision Points
- Diamond shape with multiple outgoing transitions
- Each transition has a guard condition in [brackets]
- Alternative notation: Activity can have multiple exits with conditions
Swimlanes
- Organize activities by responsibility
- Can represent: people, departments, systems, locations
- Activities flow across lanes showing handoffs
Object States
- Show how activities change object states
- Format:
:ClassName[stateName] - Connected with dashed arrows (object flows)
Common Examples
Business Process Example
- Video rental shop: Customer → Staff swimlanes
- Book production: Author → Reviewer → Typesetter → Printer
- Airline check-in: Passenger → Passenger Services
Use Case Example
- RMO telephone order system
- Shows interaction between Customer, Clerk, and System
- Includes decisions like “Available?” and “Good credit?”
Operation Example
calculateCost()method showing object method calls- Uses operation signatures as activities
Important Tips
- Start with black filled circle, end with circle containing dot
- Guard conditions must be mutually exclusive and complete
- Swimlanes clarify responsibilities and handoffs
- Object flows only needed when state changes occur
- Keep activities at consistent level of detail