T02: Transitions and Composite States

5.2.1 Understanding Transitions

In a state diagram:

• States represent conditions of an entity.

• Transitions represent movement between states.

• Events trigger transitions.

• Composite states organize complex lifecycles.

A transition answers:

What event causes the system to move from one state to another?

Basic syntax:

StateA --> StateB : Event

Example:

Here:

• Start triggers movement from Idle to Processing.

• Finish triggers transition to Completed.

---

5.2.2 Event-Driven Transitions

Transitions should be labeled with meaningful events.

Poor practice:

Better:

Events clarify intent.

---

5.2.3 Guarded Transitions (Conditional Logic)

Guard conditions restrict transitions.

Mermaid represents guards inside the label.

Example:

Though Mermaid does not enforce UML guard brackets ([condition]), textual labeling conveys conditional logic clearly.

---

5.2.4 Internal vs External Transitions

A self-transition keeps the system in the same state.

Example:

This models retry behavior without state change.

Use self-transitions for:

• Polling

• Validation loops

• Error handling retries

---

5.2.5 Entry and Exit Actions (Conceptual Modeling)

Mermaid supports entry and exit behaviors inside states.

Example:

stateDiagram-v2
    state Active {
        [*] --> Running
        Running --> Stopped : Stop
    }

    Active : entry / logStart()
    Active : exit / logStop()

This indicates:

• When entering Active, logStart() executes.

• When exiting, logStop() executes.

Use entry/exit actions for documentation clarity.

---

5.2.6 Composite States

Composite states contain substates.

Syntax:

state ParentState {
    SubState1
    SubState2
}

Example:

This models:

• Order as a parent lifecycle

• Internal workflow stages

Composite states reduce diagram clutter.

---

5.2.7 Nested Composite States

States can contain nested hierarchies.

Example:

This separates:

• Payment lifecycle

• Fulfillment lifecycle

Nested modeling is useful for large systems.

---

5.2.8 Parallel (Orthogonal) States

Parallel states allow simultaneous state progression.

Syntax uses -- separator.

Example:

This models:

• Payment and Shipping occurring independently.

Parallel states are powerful for distributed workflows.

---

5.2.9 Transition Between Composite States

Transitions can cross boundaries.

Example:

This shows:

• Internal transitions inside Account

• External transition to Closed

Understanding scope is essential.

---

5.2.10 Real-World Example — User Account Lifecycle

This models a realistic SaaS account lifecycle.

---

5.2.11 Complex Example — Subscription System

This demonstrates:

• Composite state

• Event-driven transitions

• Conditional recovery paths

---

5.2.12 Common Modeling Mistakes

1. Treating states as process steps

2. Overloading a single state with too many transitions

3. Failing to define start/end states

4. Using flowchart logic inside state diagrams

5. Ignoring composite structuring for complex lifecycles

Remember:

State diagrams model conditions, not procedural steps.

---

5.2.13 Refactoring Exercise (Hands-On)

Start simple:

Refactor into composite structure:

Observe:

• Clear lifecycle grouping

• Better semantic meaning

• Reduced diagram clutter

---

5.2.14 Hands-On Assignment

Design a Loan Processing Lifecycle:

States:

• Applied

• UnderReview

• Approved

• Rejected

• Disbursed

• Closed

Requirements:

• Use event-labeled transitions

• Include at least one composite state

• Include at least one self-transition

• Include start and end

Focus on lifecycle realism.

---

5.2.15 Best Practices

• Model states as stable conditions

• Use events to trigger transitions

• Group complexity using composite states

• Use parallel states only when truly independent

• Keep naming consistent and domain-specific

---

5.2.16 Key Takeaways

Transitions define:

• How and why state changes occur.

Composite states define:

• Hierarchical organization of complex lifecycles.

Together, they allow you to model:

• Payment systems

• Order workflows

• User account states

• Subscription models

• Protocol behavior

In the next topic, we will explore Gantt Chart Structure, where Mermaid shifts from lifecycle modeling to time-based project planning visualization.