{"title":"State Machine Diagram","description":null,"content":"A **State Diagram** (also called a **State Machine Diagram**) is a UML diagram that shows how an object or system **changes its state over time** in response to events.\n\nIt answers three key questions:\n\n- **What states can the system be in?**\n- **What events cause transitions between states?**\n- **What actions happen during those transitions?**\n\n\n```mermaid\nstateDiagram-v2\n [*] --> StateA: Initial\n\n StateA --> StateB: action1()\n StateB --> StateC: action2()\n StateC --> StateA: action3()\n\n StateB --> StateA: cancel()\n\n classDef stateA fill:#00ceff,stroke:#000,color:#000\n classDef stateB fill:#ffa94d,stroke:#000,color:#000\n classDef stateC fill:#69db7c,stroke:#000,color:#000\n\n class StateA stateA\n class StateB stateB\n class StateC stateC\n```\n\n\nInstead of focusing on *what steps are performed* (like an activity diagram), a state diagram focuses on *how behavior changes depending on the current state*.\n\nFor example, an order can move through states like **Placed → Paid → Shipped → Delivered → Cancelled**, with specific events triggering each transition.\n\n---\n\n# 1. Benefits of State Diagrams?\n\nSome objects in a system are fundamentally about states. A vending machine is either idle, collecting money, dispensing, or out of stock. An order is pending, confirmed, shipped, or delivered. An elevator is idle, moving up, moving down, or stopped at a floor. \n\nFor these objects, understanding the states and transitions is more important than understanding the class hierarchy. \n\nHere's why state diagrams are worth mastering.\n\n#### **1. Model object lifecycles clearly**\n\nSome objects have complex lifecycles where the valid operations depend entirely on the current state. You can cancel an order that's pending, but not one that's already delivered. You can insert money into a vending machine that's idle, but not one that's currently dispensing. State diagrams make these rules explicit and visual. Every valid operation is an arrow on the diagram.\n\n#### **2. Catch missing transitions and invalid states**\n\nWhen you draw a state diagram, gaps in your design become obvious. What happens if the payment gateway times out while the order is in the \"Processing Payment\" state? What if the vending machine runs out of stock while a user has already inserted money? Without a state diagram, these edge cases hide in your mental model. On a diagram, missing transitions are visible as states with no outgoing arrow for a particular event.\n\n#### **3. Bridge between requirements and implementation**\n\nStates map directly to enums in code. Transitions map to methods. Guard conditions map to if-statements. A state diagram for an order system translates almost line-for-line into a `OrderState` enum, a `transition()` method, and validation logic. This makes state diagrams one of the most implementation-ready UML diagrams you can draw.\n\n---\n\n# 2. Components of a State Machine Diagram\n\nEvery state diagram is built from a small set of standard components. Once you know these, you can read and draw any state diagram.\n\n### 2.1 State\n\nA **state** represents a condition or situation during the life of an object. It's a period of time during which the object satisfies a particular condition, performs an activity, or waits for an event. States are drawn as rounded rectangles with the state name inside.\n\nA state can also have **internal activities** that describe behavior associated with the state:\n\n- **entry /** action performed when entering the state\n- **do /** action performed while in the state (ongoing activity)\n- **exit /** action performed when leaving the state\n\n\n```mermaid\nstateDiagram-v2\n state \"Idle\" as IDLE\n state \"HasMoney\" as HAS_MONEY\n state \"Dispensing\" as DISPENSING\n\n IDLE --> HAS_MONEY: insertMoney\n HAS_MONEY --> DISPENSING: selectProduct\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n\n class IDLE primary\n class HAS_MONEY orange\n class DISPENSING green\n```\n\n\nEach rounded rectangle is a state. The labels on the arrows are the events that trigger transitions. Notice that states are named with nouns or adjectives (Idle, HasMoney, Dispensing), not verbs. A state is a condition the object is in, not something it does.\n\n### 2.2 Initial State\n\nThe **initial state** marks where the lifecycle begins. It's drawn as a small filled circle (solid black dot). Every state diagram must have exactly one initial state. It has no incoming transitions and exactly one outgoing transition (with no event label, since the object starts here automatically).\n\n\n```mermaid\nstateDiagram-v2\n [*] --> IDLE: system starts\n\n state \"Idle\" as IDLE\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n class IDLE primary\n```\n\n\nThe `[*]` on the left is the initial state. It immediately transitions to the first real state (Idle) when the object is created. You don't label the initial transition with an event because no event triggers it. The object simply begins its lifecycle in this state.\n\n### 2.3 Final State\n\nThe **final state** marks where the lifecycle ends. It's drawn as a bullseye (a filled circle inside a larger circle). Not every state diagram needs a final state. An elevator, for instance, never truly terminates. But an order eventually reaches Delivered or Cancelled, and those are terminal states.\n\n\n```mermaid\nstateDiagram-v2\n state \"Delivered\" as DELIVERED\n state \"Cancelled\" as CANCELLED\n\n DELIVERED --> [*]\n CANCELLED --> [*]\n\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n\n class DELIVERED green\n class CANCELLED red\n```\n\n\nBoth Delivered and Cancelled are terminal states. Once an order reaches either, its lifecycle is over. The `[*]` on the right is the final state. An object can have multiple paths to the final state (an order can end by being delivered or cancelled), but the final state itself is a single termination point.\n\n### 2.4 Transition\n\nA **transition** is an arrow from one state to another, representing a change triggered by an event. The arrow is labeled with the event (and optionally a guard condition and action). A transition fires instantaneously. The object is in the source state, the event occurs, and the object is now in the target state.\n\n\n```mermaid\nstateDiagram-v2\n state \"Pending\" as PENDING\n state \"Confirmed\" as CONFIRMED\n state \"Cancelled\" as CANCELLED\n\n PENDING --> CONFIRMED: restaurantAccepts\n PENDING --> CANCELLED: restaurantRejects\n\n classDef yellow fill:#ffd43b,stroke:#000,color:#000\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n\n class PENDING yellow\n class CONFIRMED primary\n class CANCELLED red\n```\n\n\nFrom the Pending state, two transitions are possible. If the restaurant accepts, the order moves to Confirmed. If the restaurant rejects, it moves to Cancelled. The event labels (restaurantAccepts, restaurantRejects) are the triggers. No other transitions are valid from Pending, which means the order stays in Pending until one of these events occurs.\n\n### 2.5 Event\n\nAn **event** is an occurrence that triggers a transition. Events are written on the transition arrow. They can be:\n\n- **Signal events:** external inputs (userClicksCancel, paymentReceived)\n- **Call events:** method invocations (processPayment(), validateOrder())\n- **Time events:** timeouts (after 30 seconds, after 24 hours)\n- **Change events:** when a condition becomes true (when balance == 0)\n\n\n```mermaid\nstateDiagram-v2\n Idle --> Running: start()\n Running --> Paused: pause()\n Paused --> Running: resume()\n Running --> Stopped: stop()\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n\tclassDef yellow fill:#ffd43b,stroke:#000,color:#000\n\tclassDef green fill:#69db7c,stroke:#000,color:#000\n\tclassDef red fill:#ff8787,stroke:#000,color:#000\n\t\n class Idle primary\n\tclass Paused yellow\n\tclass Running green\n\tclass Stopped red\n```\n\n\nThe naming convention matters. Use camelCase verbs that clearly describe what happened: `insertMoney`, `selectProduct`, `timeout`, `paymentApproved`. The event name should be specific enough that someone reading the diagram knows exactly what triggers the transition.\n\n### 2.6 Guard Condition\n\nA **guard condition** is a boolean expression written in square brackets on a transition. The transition only fires if the event occurs AND the guard condition is true. Guards are your way of saying \"this transition is only valid when...\"\n\n\n```mermaid\nstateDiagram-v2\n state \"HasMoney\" as HAS_MONEY\n state \"Dispensing\" as DISPENSING\n state \"Refunding\" as REFUNDING\n\n HAS_MONEY --> DISPENSING: selectProduct
[itemInStock]\n HAS_MONEY --> REFUNDING: selectProduct
[itemOutOfStock]\n\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n\n class HAS_MONEY orange\n class DISPENSING green\n class REFUNDING red\n```\n\n\nBoth transitions are triggered by the same event (selectProduct), but the guard condition determines which transition fires. If the selected item is in stock, the machine moves to Dispensing. If not, it moves to Refunding. Without guard conditions, you'd have ambiguous transitions: two arrows from the same state triggered by the same event, with no way to know which one fires.\n\n### 2.7 Action\n\nAn **action** is behavior executed during a transition. Written after a `/`.\n\n\n```mermaid\nstateDiagram-v2\n Pending --> Shipped: ship / sendNotification()\n Shipped --> Delivered: deliver / updateInventory()\n\t\n classDef primary fill:#00ceff,stroke:#000,color:#000\n\tclassDef yellow fill:#ffd43b,stroke:#000,color:#000\n\tclassDef green fill:#69db7c,stroke:#000,color:#000\n\t\n class Pending primary\n\tclass Shipped yellow\n\tclass Delivered green\n\n```\n\n\n---\n\n# 3. Types of States\n\nNot all states are simple boxes. UML state diagrams support several types of states that help you model complex lifecycles without cluttering the diagram.\n\n## Simple States\n\nA simple state has no internal structure. It's just a named condition with incoming and outgoing transitions. Most states in a typical state diagram are simple states.\n\n\n```mermaid\nstateDiagram-v2\n state \"Idle\" as IDLE\n state \"Processing\" as PROCESSING\n state \"Complete\" as COMPLETE\n\n [*] --> IDLE\n IDLE --> PROCESSING: startJob\n PROCESSING --> COMPLETE: jobFinished\n COMPLETE --> [*]\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n\n class IDLE primary\n class PROCESSING orange\n class COMPLETE green\n```\n\n\nThree simple states, linear progression, no nesting. This is sufficient for most straightforward lifecycles.\n\n## Composite (Nested) States\n\nA **composite state** contains sub-states within it. This is useful when a high-level state has its own internal lifecycle. For example, an \"Active\" state in a user account might contain sub-states like \"Standard\" and \"Premium.\"\n\n\n```mermaid\nstateDiagram-v2\n [*] --> Inactive\n\n state \"Inactive\" as Inactive\n state \"Active\" as Active {\n [*] --> Standard\n Standard --> Premium: upgrade\n Premium --> Standard: downgrade\n }\n state \"Suspended\" as Suspended\n\n Inactive --> Active: activate\n Active --> Suspended: violatePolicy\n Suspended --> Active: appealApproved\n Suspended --> Inactive: accountDeleted\n Active --> Inactive: deactivate\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n\n class Inactive primary\n class Active green\n class Standard teal\n class Premium orange\n class Suspended red\n```\n\n\nThe Active state is a composite state containing Standard and Premium as sub-states. When a user activates their account, they enter the Active state, which starts in the Standard sub-state. They can upgrade to Premium or downgrade back to Standard without leaving the Active state. But if they violate a policy, they leave the entire Active state (regardless of whether they were Standard or Premium) and move to Suspended.\n\nComposite states are powerful because they let you model hierarchical behavior. The outer transitions (Active to Suspended) apply to all sub-states. The inner transitions (Standard to Premium) are only relevant within the composite state.\n\n## Self-Transitions\n\nA **self-transition** is a transition where the source and target state are the same. The object leaves the state and re-enters it, which triggers exit and entry actions.\n\n\n```mermaid\nstateDiagram-v2\n state \"HasMoney\" as HAS_MONEY\n\n [*] --> HAS_MONEY: insertMoney\n HAS_MONEY --> HAS_MONEY: insertMoreMoney
/ updateBalance\n\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n class HAS_MONEY orange\n```\n\n\nIn a vending machine, after inserting money, the user can insert more money. The machine stays in the HasMoney state but updates the balance. The self-transition arrow loops back to the same state, indicating that the event is handled without changing states.\n\nSelf-transitions are common in real systems. A chat application in the \"Connected\" state might receive a new message (self-transition with a \"displayMessage\" action). A game character in the \"Moving\" state might change direction (self-transition with an \"updateDirection\" action).\n\n## Choice Pseudo-State\n\nA **choice pseudo-state** is a diamond-shaped node that evaluates conditions dynamically and routes the flow to different states based on the result. It's similar to a decision node in activity diagrams but used within state diagrams for dynamic branching.\n\n\n```mermaid\nstateDiagram-v2\n state \"Validating\" as VALIDATING\n state check <>\n state \"Approved\" as APPROVED\n state \"Rejected\" as REJECTED\n state \"ManualReview\" as MANUAL\n\n VALIDATING --> check: validationComplete\n check --> APPROVED: [score > 80]\n check --> REJECTED: [score < 30]\n check --> MANUAL: [30 <= score <= 80]\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef yellow fill:#ffd43b,stroke:#000,color:#000\n\n class VALIDATING primary\n class APPROVED green\n class REJECTED red\n class MANUAL yellow\n```\n\n\nAfter validation, the choice pseudo-state evaluates the score and routes to one of three states. This is useful when the target state depends on a runtime value rather than a simple binary condition.\n\n---\n\n# 4. How to Create a State Diagram: Step by Step\n\nHere's a repeatable process for creating state diagrams for any object. We'll use a food delivery order as the running example.\n\n#### **Step 1: Identify the object**\n\nPick the single object whose lifecycle you want to model. Don't try to model the entire system. State diagrams are about one object at a time. For a food delivery system, the object is the Order.\n\n#### **Step 2: List all possible states**\n\nAsk yourself: what conditions can this object be in during its lifetime? For a food delivery order: Placed, Confirmed, Preparing, ReadyForPickup, PickedUp, Delivered, Cancelled.\n\n#### **Step 3: Identify the initial and final states**\n\nWhere does the lifecycle begin? (Placed.) Where does it end? (Delivered and Cancelled are both terminal states.)\n\n#### **Step 4: Define the transitions**\n\nFor each state, ask: what events can cause the object to leave this state, and where does it go? Placed can transition to Confirmed (restaurant accepts) or Cancelled (restaurant rejects). Confirmed transitions to Preparing (kitchen starts). And so on.\n\n#### **Step 5: Add guard conditions**\n\nAre there any transitions where the same event can lead to different states? For example, a customer cancelling might lead to Cancelled with a full refund (if the order hasn't been prepared yet) or Cancelled with a partial refund (if preparation has started). That's a guard condition.\n\n#### **Step 6: Validate the diagram**\n\nCheck every state: does it have at least one outgoing transition (unless it's a final state)? Does it have at least one incoming transition (unless it's the initial state)? Is every event handled, or are there events that have no effect in certain states? If a user tries to cancel a delivered order, what happens? If the diagram doesn't answer that, you have a gap.","pageType":"lld-interviews"}

Get Premium