State Diagram

A state diagram (also called a state machine diagram or statechart diagram) models the dynamic behavior of a single object by showing its possible states, the events that trigger transitions between states, and the actions performed during those transitions. While class diagrams show structure and sequence diagrams show interactions between objects, state diagrams focus on how one object's internal state changes over its lifetime in response to external stimuli. They are invaluable for modeling objects with complex lifecycle behavior—orders that progress through stages, user sessions with various modes, or devices with multiple operational states.

Core Concepts

State: A condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event. An order might be in states like "Pending," "Confirmed," "Shipped," or "Delivered." Each state represents a period where the object behaves in a particular way.

Transition: A change from one state to another, triggered by an event. When a "Pending" order receives payment confirmation (event), it transitions to "Confirmed." Transitions are instantaneous—an object is always in some state, never between states.

Event: An occurrence that triggers a transition. Events can be signals (messages from other objects), time events (timeout after 30 minutes), change events (when a condition becomes true), or call events (invocation of an operation).

Guard Condition: A boolean condition that must be true for a transition to fire when its triggering event occurs. If the event occurs but the guard is false, the transition does not happen. For example: payment received [amount >= order total] — the payment event only triggers transition to Confirmed if the amount is sufficient.

Action: Activity performed during a transition or within a state. Entry actions execute when entering a state, exit actions when leaving, and do activities continue while in the state.

Notation

Real-World Example: Online Order Lifecycle

This diagram tells us:

• An order starts in "Created" state and can only become "Shopping" when items are added
• Checkout requires the cart to be non-empty (guard condition)
• Payment failure does not end the order—the customer can retry
• Returns are only possible within 30 days (guard)
• The lifecycle ends when the order is delivered (if not returned) or returned

Another Example: ATM Session

Composite States

Complex state diagrams use composite (nested) states to manage complexity. A composite state contains sub-states and sub-transitions:

The "Authenticated" state in the ATM example might contain sub-states for "Viewing Balance," "Withdrawing," "Depositing," and "Transferring." The composite state handles the common "timeout" event—regardless of which sub-state the user is in, a timeout transitions to "Idle" with card ejection.

When to Use State Diagrams

State diagrams are most valuable for:

• Protocol modeling: Objects that must follow specific message sequences (network protocols, communication handshakes)
• Lifecycle modeling: Entities with well-defined stages (orders, tickets, user accounts, insurance claims)
• Device behavior: Embedded systems, hardware controllers, and IoT devices with operational modes
• UI navigation: Screen flows with distinct modes and transitions between them
• Workflow engines: Business processes with defined states and rules governing transitions

State Diagrams vs. Activity Diagrams

State diagrams model the behavior of a single object responding to events. Activity diagrams model the flow of activities (potentially across multiple objects). Use state diagrams when the focus is "what states does this entity go through?" Use activity diagrams when the focus is "what steps does this process follow?"

Practical Guidelines

Keep diagrams focused on a single object's lifecycle. Avoid modeling more than 7-10 states in a single diagram—if complexity exceeds this, use composite states or split into multiple diagrams. Ensure every state is reachable from the initial state and can reach the final state (no orphan or dead-end states unless intentionally modeled). Name states with adjectives or past participles (Pending, Confirmed, Shipped) rather than verbs. Name transitions with the event that triggers them.

Common Mistakes

Confusing states with activities (states describe what the object IS, not what it's DOING—though states can have internal activities). Missing transitions for error cases (what happens when payment fails?). Having ambiguous transitions (two transitions from the same state triggered by the same event without distinguishing guards). Forgetting the initial and final states.