Activity & State Diagrams - Learning Module

Loading content...

0/246

State Diagrams — Object Lifecycle

Objects That Change Over Time

Every substantial object in a software system has a lifecycle—a sequence of states it passes through from creation to destruction, responding to events along the way. An Order transitions from Draft to Submitted to Approved to Shipped to Delivered. A Connection moves from Closed to Opening to Open to Closing. A User Account progresses from Pending to Active to Suspended to Deleted.

Understanding these lifecycles isn't optional—it's essential. Bugs in state management cause some of the most insidious defects: orders that can be paid twice, connections that hang forever, accounts that become inconsistent. State Diagrams (formally called State Machine Diagrams in UML) provide the rigorous vocabulary to model, validate, and communicate object behavior over time.

What You Will Learn

By the end of this page, you will master State Machine Diagrams—their notation, semantics, and advanced features. You'll understand states, transitions, events, guards, and actions. You'll learn to model composite states, concurrent regions, and entry/exit behaviors. Most importantly, you'll be able to design robust object lifecycles that prevent invalid state transitions.

What Are State Diagrams?

A State Machine Diagram (often simply called a State Diagram) models the discrete states an object can be in and the transitions between those states triggered by events. It answers fundamental questions:

What states can this object exist in?
What events cause state changes?
What conditions govern whether a transition occurs?
What actions happen when transitioning or while in a state?

Historical Context:

State machines have deep roots in computer science:

Finite Automata (1950s): Foundational theoretical model for computation
Mealy and Moore Machines: State machines with outputs on transitions or states
Statecharts (1987): David Harel's visual formalism with hierarchy and concurrency
UML State Machines: Standardized notation based on Statecharts

UML State Machine Diagrams inherit the power of Statecharts—particularly hierarchical (composite) states and concurrent regions—while providing standardized notation understood across the industry.

State Diagram Applications

•Protocol Modeling — Network protocols, handshakes, and communication sequences
•UI Component Behavior — Button states, form validation flows, modal dialogs
•Order/Transaction Processing — E-commerce orders, payment workflows, reservations
•Device Control — Hardware states, operating modes, power management
•Game Logic — Game states, character conditions, AI behaviors
•Business Entities — Customer lifecycle, subscription states, document approval workflows

State Diagrams vs Activity Diagrams

Both model dynamic behavior, but from different perspectives. Activity diagrams model the flow of control through a process—what activities happen in what order. State diagrams model the lifecycle of a single object—what states it can be in and how it responds to events. Use activity diagrams for workflows; use state diagrams for object behavior.

Core Notation — States and Transitions

State diagrams use a precise set of symbols with well-defined semantics. Understanding this vocabulary is essential for creating accurate models.

States:

A state represents a condition or situation during the life of an object in which it satisfies some condition, performs some activity, or waits for some event. States are drawn as rounded rectangles with the state name inside.

┌─────────────────────┐
│       Active        │
└─────────────────────┘

State characteristics:

An object is always in exactly one state (for simple state machines)
States are stable—an object remains in a state until an event triggers a transition
States often correspond to object attributes or business status values

Pseudo-States:

Pseudo-states are special notation elements that are not true states but control transition flow:

Initial pseudo-state (●): A filled circle indicating the starting point
Final state (◉): A circle with inner filled circle indicating termination
Choice pseudo-state (◇): A diamond for dynamic conditional branching
Junction pseudo-state (●): A small filled circle for merging/splitting transitions
History pseudo-state (H): Remembers the last active substate

State Diagram Notation Elements
Symbol	Name	Purpose
▢ (rounded)	State	A condition during object lifecycle
●	Initial Pseudo-state	Entry point to the state machine
◉	Final State	Termination of the state machine
→	Transition	Change from one state to another
◇	Choice Pseudo-state	Dynamic branching based on guard evaluation
H / H*	History Pseudo-state	Returns to last active substate (shallow/deep)
⊙	Entry/Exit Point	Named entry or exit from composite state

Transitions:

A transition represents a relationship between two states indicating that when a specified event occurs and certain conditions are met, the object moves from the first state to the second. Transitions are drawn as arrows with labels.

Transition label syntax:

event [guard] / action

event: The trigger that initiates the transition (may be omitted for "completion" transitions)
guard: A Boolean condition in square brackets that must be true for the transition to fire
action: Behavior executed during the transition (after the slash)

Example transitions:

submit [isValid] / sendConfirmation()
approve / notifyCustomer()
timeout
cancel [canCancel()]

Each component is optional:

Event only: click
Event + guard: submit [isValid]
Event + action: approve / logApproval()
Complete: payment [amount > 0] / processPayment()

Completion Transitions

A transition without an event trigger is called a 'completion transition' or 'triggerless transition'. It fires automatically when the source state completes all its internal activities. This is how states can flow naturally from one to the next without explicit external events.

Events — What Triggers Transitions

Events are the stimuli that trigger state transitions. Understanding event types is crucial for accurate state modeling.

Call Events:

The most common event type—a request to execute an operation on the object:

approve()   — Someone calls the approve operation
cancel()    — Someone calls the cancel operation
process(order)  — Called with parameter

Call events typically correspond to method invocations in your implementation.

Signal Events:

Asynchronous messages sent to the object (as opposed to synchronous calls):

PaymentReceived
TimeoutExpired
UserLoggedOut

Signals are named communications that don't require immediate response. They're queued if the object is busy.

Time Events:

Events based on time passage:

after(30 days)      — 30 days after entering the state
after(5 minutes)    — 5 minutes after entering the state
at(midnight)        — At a specific time

Time events are essential for modeling timeouts, expiration, and scheduled behaviors.

Event Types Summary

•Call Event — Synchronous operation invocation: submit(), cancel(reason)
•Signal Event — Asynchronous message receipt: PaymentConfirmed, StockDepleted
•Time Event — Relative: after(30 min) or absolute: at(2024-12-31)
•Change Event — Condition becomes true: when(balance < 0), when(stockLevel == 0)
•Completion Event — Implicit event when state's activity completes (no trigger shown)

Change Events:

Events that fire when a condition becomes true (continuous monitoring):

when(accountBalance < 0)
when(temperature > 100)
when(queue.size > maxCapacity)

Change events are evaluated continuously (conceptually). The transition fires the moment the condition becomes true.

Deferred Events:

Sometimes an event arrives when the object can't handle it immediately. UML supports deferring events:

┌─────────────────────────┐
│     Processing          │
│ ─────────────────────── │
│  cancel / defer         │
└─────────────────────────┘

Deferred events are queued and reconsidered when the object enters a state that can handle them. This prevents event loss without requiring immediate processing.

Event Parameters:

Events can carry data that influences transitions:

payment(amount, method) [amount > 0] / processPayment(amount, method)
update(newValue) / setValue(newValue)

Parameters are available to guards and actions on the transition.

Event Semantics Matter

A common design error is conflating different event types. Call events imply synchronous interaction; signal events imply asynchronous messaging. Time events require timer infrastructure. Change events require condition monitoring. Choose the event type that matches your actual system's communication patterns.

Guards — Conditional Transitions

Guards are Boolean expressions that determine whether a transition may fire when its triggering event occurs. They enable conditional behavior within state machines.

Guard Syntax:

Guards are enclosed in square brackets on the transition label:

[guard expression]

Examples:

approve [isManager]
submit [form.isValid()]
withdraw [balance >= amount]
ship [inventory.available(item) && !order.isCancelled()]

Evaluation Semantics:

Event occurs
All transitions with that event trigger are identified
Guards are evaluated (in no particular order)
If exactly one guard is true, that transition fires
If multiple guards are true, behavior is undefined (design error)
If no guards are true, the event is discarded (or deferred if specified)

Good Guard Practices

•Make guards mutually exclusive
•Ensure guards are exhaustive (cover all cases)
•Use meaningful, domain-language expressions
•Avoid side effects in guard evaluation
•Keep guards simple and readable

Guard Anti-Patterns

•Overlapping guards causing non-determinism
•Implementation-level expressions in models
•Complex guards that should be multiple states
•Guards that modify object state
•Implicit guards (forgetting [else])

Pattern: Mutually Exclusive Guards

When the same event can lead to different states based on conditions:

        ┌─────────────────────────────────┐
        │           Submitted             │
        └─────────────────────────────────┘
                      │
          review event occurs
                      ↓
        ┌─────────────────────────────────┐
        │         ◇ Choice                │
        └─────────────────────────────────┘
           ╱                 ╲
    [isApproved]         [isRejected]
         ↓                    ↓
    ┌─────────┐          ┌─────────┐
    │ Approved│          │ Rejected│
    └─────────┘          └─────────┘

The choice pseudo-state (◇) makes the branching explicit. Guards must be evaluated after the event but before committing to a target state.

Dynamic vs Static Guards:

Static guards: Evaluate to the same value during a state (object properties)
Dynamic guards: Depend on current moment (external conditions, clocks)

Dynamic guards require careful design—the system must handle cases where conditions change between event occurrence and guard evaluation.

The [else] Guard

UML supports an [else] guard that matches when no other guard is true. Use it sparingly—explicit conditions are clearer than implicit else logic. When you do use [else], ensure it's intentional and not masking forgotten cases.

Actions — Behavior During Transitions

Actions are behaviors that execute during state machine operation. UML distinguishes several types based on when they execute.

Transition Actions:

Actions specified on a transition execute during the transition—after leaving the source state but before entering the target state:

approve / sendNotification(); updateAuditLog()

Transition actions are atomic (conceptually instantaneous). They have access to:

The triggering event and its parameters
The object's current attributes
External services and dependencies

Entry Actions:

Actions that execute every time a state is entered, regardless of which transition led there:

┌─────────────────────────────────┐
│           Active                │
├─────────────────────────────────┤
│ entry / startMonitoring()       │
└─────────────────────────────────┘

Entry actions are perfect for initialization: starting timers, acquiring resources, sending notifications. They execute after any transition action.

Types of Actions in State Machines
Action Type	When It Executes	Notation	Use Case
Transition	During transition	event / action	Logging, notifications, data transformation
Entry	On entering state	entry / action	Initialization, resource acquisition, start timers
Exit	On leaving state	exit / action	Cleanup, resource release, stop timers
Do Activity	While in state	do / activity	Background processing, polling, monitoring

Exit Actions:

Actions that execute every time a state is exited, regardless of which transition is taken:

┌─────────────────────────────────┐
│           Active                │
├─────────────────────────────────┤
│ entry / startMonitoring()       │
│ exit / stopMonitoring()         │
└─────────────────────────────────┘

Exit actions handle cleanup: stopping timers, releasing resources, finalizing data. They execute before any transition action.

Do Activities:

Unlike instantaneous actions, do activities represent ongoing behavior while in a state:

┌─────────────────────────────────┐
│         Processing              │
├─────────────────────────────────┤
│ do / performBackgroundWork()    │
└─────────────────────────────────┘

Do activities:

Begin when the state is entered (after entry action)
Run until completion or until the state is exited
May be interrupted by transitions leaving the state

Execution Order:

For a transition from State A to State B with transition action T:

A's exit action executes
T (transition action) executes
B's entry action executes
B's do activity begins

Entry/Exit vs Transition Actions

Entry and exit actions are state-centric—they run regardless of which transition is used. Transition actions are transition-specific—they run only for that particular path. Use entry/exit for state-invariant behavior; use transition actions for path-specific behavior.

Composite States — Hierarchy

One of the most powerful features of UML State Machines (inherited from Harel Statecharts) is composite states—states that contain other states. This enables hierarchical modeling and dramatically reduces diagram complexity.

Why Composite States?

Without hierarchy, state machines suffer from state explosion. Consider a system with 5 main states and 3 error-handling states. In a flat state machine, you'd need 5 × 3 = 15 error transitions. With a composite state wrapping the main states, you need just 3 error transitions from the container.

Composite State Notation:

┌─────────────────────────────────────────────────────┐
│                    Processing                       │
├─────────────────────────────────────────────────────┤
│                                                     │
│    ● → [Validating] → [Calculating] → [Saving]     │
│                                                     │
│                           ↓                         │
│                    ┌──────────┐                     │
│                    │ Complete │                     │
│                    └──────────┘                     │
└─────────────────────────────────────────────────────┘
         │
         │ error
         ↓
    ┌─────────┐
    │  Error  │
    └─────────┘

The Processing state contains substates. The error transition from Processing can fire from any substate, exiting the entire composite.

Composite State Benefits

•Transition Sharing — Transitions from the composite apply to all substates, reducing redundant arrows
•Abstraction Levels — View high-level behavior (just the composite) or detail (expand to see substates)
•Entry/Exit Inheritance — Composite state entry/exit actions run when entering/leaving any substate
•Encapsulation — Internal substates can be hidden from external clients
•History States — Remember and return to the last active substate

Transitions Into and Out of Composites:

Into the composite (to boundary): Enters via the initial pseudo-state inside
Into a specific substate: Arrow goes directly to the substate
Out from composite (from boundary): Exits from any substate
Out from specific substate: Only exits from that substate

History States:

When re-entering a composite state, you might want to resume where you left off rather than starting over. History pseudo-states enable this:

Shallow History (H): Returns to the last direct substate
*Deep History (H)**: Returns to the last leaf state (recursively)

┌───────────────────────────────────────────────┐
│                  Editing                      │
├───────────────────────────────────────────────┤
│                                               │
│   ● → [Draft] → [Review] → [Finalize]        │
│                                               │
│       (H) ←── resume transition              │
└───────────────────────────────────────────────┘

When transitioning to the history pseudo-state (H), the state machine enters whichever substate was active when it last left the composite.

Submachine States:

For very complex substates, you can reference an entire separate state machine diagram:

┌─────────────────────────────────┐
│ Payment Processing : PaymentSM  │
└─────────────────────────────────┘

The : PaymentSM indicates this state's behavior is defined by the PaymentSM state machine.

Depth Limit

While UML allows unlimited nesting, practical readability limits hierarchy depth. Two or three levels are usually manageable. Beyond that, consider splitting into separate state machine diagrams connected via submachine references.

Orthogonal Regions — Concurrency

Objects sometimes have independent aspects of state that evolve concurrently. UML models this with orthogonal regions—multiple independent state machines operating in parallel within a composite state.

The Problem:

Consider a phone call that has:

Connection state: Connecting → Connected → Disconnecting → Disconnected
Audio state: Muted → Unmuted
Video state: Video On → Video Off

Without orthogonality, you'd need 4 × 2 × 2 = 16 states: ConnectingMutedVideoOn, ConnectingMutedVideoOff, etc. This is the Cartesian product explosion.

Orthogonal Region Notation:

Regions are separated by dashed lines within a composite state:

┌─────────────────────────────────────────────────────────────────┐
│                          Active Call                            │
├─────────────────────────────────────────────────────────────────┤
│ Connection                    ╎ Audio                          │
│ ─────────────────────         ╎ ─────────────────               │
│ ● → [Connecting] → [Stable]   ╎ ● → [Unmuted]                  │
│                                ╎       ↕ toggle                 │
│                                ╎     [Muted]                    │
├────────────────────────────────┼────────────────────────────────┤
│ Video                          ╎                                │
│ ─────────────                  ╎                                │
│ ● → [No Video] ↔ [Video On]   ╎                                │
└────────────────────────────────┴────────────────────────────────┘

The object is simultaneously in one state from each region: e.g., (Connecting, Unmuted, No Video).

Orthogonal Region Concepts
Concept	Description	Example
Region	Independent state machine within composite	Audio region, Video region
Configuration	Combination of active states across regions	(Connected, Muted, Video On)
Fork	Transition entering multiple regions simultaneously	● → Fork → (state in each region)
Join	Transition requiring all regions reach specific states	Join → (waits for all regions)
Synchronization	Events affecting multiple regions	disconnect affects all regions

Fork and Join in State Machines:

When entering an orthogonal composite, you may need to specify initial states for each region:

● → ▬ Fork
      ├→ [Region1: StateA]
      └→ [Region2: StateX]

Similarly, exiting may require all regions to reach specific states:

[Region1: StateB] →┐
                   ├→ ▬ Join → [Next State]
[Region2: StateY] →┘

Synchronization Semantics:

Events are broadcast to all regions
Each region processes the event independently
Transitions fire if their guards are satisfied
Actions from different regions are interleaved (order unspecified)

When to Use Orthogonal Regions:

Independent aspects: Mute state is independent of connection state
Different lifecycles: Subscription status vs user activity
Separate concerns: UI state vs data loading state

When NOT to Use:

Regions that frequently interact or constrain each other
Aspects where the Cartesian product IS the real state space
Simple models where regions add complexity without benefit

Practical Concurrency

Orthogonal regions model conceptual independence, not thread-level parallelism. The regions run in the same execution context, processing events atomically. True parallelism requires explicit threading architecture beyond the state machine model.

Self-Transitions and Internal Transitions

Two special transition types handle events that don't change the external state but may trigger actions.

Self-Transitions:

A self-transition is a transition where the source and target state are the same. The state is exited and re-entered:

┌──────────────────────────────────┐
│            Active                │
├──────────────────────────────────┤
│ entry / initialize()             │
│ exit / cleanup()                 │
└──────────────────────────────────┘
           │ ↑
           └─┘  refresh / reload()

When refresh occurs:

cleanup() executes (exit action)
reload() executes (transition action)
initialize() executes (entry action)

Self-transitions are useful when you need to reset or reinitialize a state.

Self-Transition

•State is exited then re-entered
•Exit and entry actions execute
•Do activity is interrupted and restarted
•Shown as arrow leaving and returning to state
•Use for: reset, reinitialize, restart

Internal Transition

•State is NOT exited
•Exit and entry actions do NOT execute
•Do activity continues uninterrupted
•Shown inside state compartment
•Use for: handle event, logging, updates

Internal Transitions:

An internal transition handles an event within a state without exiting or re-entering:

┌──────────────────────────────────────────────┐
│                   Active                     │
├──────────────────────────────────────────────┤
│ entry / initialize()                         │
│ update / processUpdate()    ← internal       │
│ log / writeToLog()          ← internal       │
│ exit / cleanup()                             │
└──────────────────────────────────────────────┘

When update occurs:

processUpdate() executes
That's it—no exit, no entry, do activity continues

Internal transitions are notated in the state's internal behavior compartment, not as arrows.

Choosing Between Self and Internal:

Scenario	Use Self-Transition	Use Internal Transition
Need to reinitialize	✓
Just handling an event		✓
Want exit/entry to run	✓
Want do activity to continue		✓
Timing-critical (avoid re-entry overhead)		✓

Internal Transition Notation

Internal transitions are listed inside the state, not as external arrows. The syntax is: event [guard] / action. They appear in the same compartment as entry/exit/do but represent responses to specific events rather than state lifecycle behaviors.

Designing Robust State Machines

Creating effective state machines requires systematic thinking about object behavior. Here's a disciplined approach:

Step 1: Identify the Object

Which object's lifecycle are you modeling? Not every class needs a state machine—only those with:

Multiple significant states
Event-driven behavior
State-dependent responses to events
Non-trivial lifecycle

Step 2: Enumerate States

List all distinct conditions the object can be in:

What are the "stable" situations?
What statuses would appear in a database column?
What are the user-visible conditions?

Avoid explosion: if you have 20+ states, consider hierarchical decomposition.

Step 3: Define Events

What stimuli affect this object?

User actions (submit, cancel, approve)
System events (timeout, payment received)
Time events (expiry, deadline)
Change events (threshold crossed)

State Machine Design Checklist

•Completeness — Every event in every state has defined behavior (transition, internal handling, or explicit ignore/defer)
•Determinism — Guards are mutually exclusive; no ambiguity about which transition fires
•Reachability — Every state is reachable from the initial state
•No Dead Ends — Every state can eventually reach a final state (if termination is expected)
•Level Consistency — States at the same level represent the same kind of distinction
•Guard Clarity — Conditions are expressed in domain language, not implementation details
•Action Atomicity — Actions are quick; long-running behavior uses do activities or external services

Step 4: Map Transitions

For each (state, event) pair, determine:

Does this event matter in this state?
If yes, what is the target state?
Are there conditions (guards)?
What actions should execute?

Step 5: Validate Completeness

Create a state-event matrix:

            | submit | approve | reject | timeout | cancel |
------------|--------|---------|--------|---------|--------|
Draft       |  →Pend |    -    |   -    |  →Exp   |  →Can  |
Pending     |   -    | →Apprv  | →Rej   |  →Exp   |  →Can  |
Approved    |   -    |    -    |   -    |    -    |   -    |
Rejected    |   -    |    -    |   -    |    -    |   -    |
Cancelled   |   -    |    -    |   -    |    -    |   -    |
Expired     |   -    |    -    |   -    |    -    |   -    |

Every cell should be intentionally decided: transition, internal action, or explicit "event ignored in this state".

Step 6: Consider Error Cases

Often forgotten: What happens when things go wrong?

Network failures
External service unavailable
Data validation errors
Concurrent modifications

Error states and recovery transitions are essential for robust designs.

The Implementation Connection

A well-designed state machine translates directly to implementation. Modern state machine libraries (XState for JavaScript, Spring State Machine for Java, etc.) can often implement diagrams almost 1:1. This means your state diagram isn't just documentation—it's an executable specification.

Summary and Key Takeaways

State Machine Diagrams provide a rigorous framework for modeling object lifecycles. They prevent state-related bugs by forcing explicit consideration of every state-event combination. Let's consolidate the key concepts:

Key Takeaways

•States are stable conditions — An object remains in a state until an event triggers a transition
•Events trigger transitions — Call events, signal events, time events, and change events can all cause state changes
•Guards enable conditional transitions — Multiple transitions from the same event are resolved by mutually exclusive guards
•Actions execute during transitions — Entry, exit, transition, and do activities have different timing semantics
•Composite states enable hierarchy — Reduce complexity by grouping states; transitions can cross boundaries
•Orthogonal regions model concurrency — Independent aspects of state evolve in parallel, avoiding Cartesian explosion
•Self vs internal transitions — Self-transitions exit/re-enter; internal transitions don't
•Systematic design prevents bugs — State-event matrices ensure completeness; validation catches dead ends

What's Next:

Now that we understand both Activity Diagrams (for workflows) and State Diagrams (for lifecycles), we need the wisdom to choose between them—and to know when simpler alternatives suffice. The next page provides a decision framework for selecting the appropriate diagram type for any modeling situation.

Page Complete

You now have comprehensive knowledge of UML State Machine Diagrams. You can model object lifecycles with states, transitions, guards, and actions. You understand composite states for hierarchy and orthogonal regions for concurrency. Next, we'll learn when to use each diagram type and how to keep diagrams appropriately simple.