ishavasya

14. Mermaid Diagrams

Aug 4, 2026

ER Diagrams

Lesson ER.1 - Declaring Entities and a Relationship

erDiagram
    CUSTOMER ||--o{ ORDER : places

erDiagram
    CUSTOMER ||--o{ ORDER : places
  • erDiagram tells Mermaid that this is an Entity-Relationship (ER) diagram.
  • CUSTOMER and ORDER are entities (typically database tables).
  • : places labels the relationship between the entities.
  • ||--o{ defines the relationship and its cardinality

Lesson ER.2 - Common Cardinalities

erDiagram
    PERSON ||--|| PASSPORT : has
    CUSTOMER ||--o{ ORDER : places
    STUDENT }o--o{ COURSE : enrolls
    MANAGER |o--|| DEPARTMENT : manages

erDiagram
    PERSON ||--|| PASSPORT : has
    CUSTOMER ||--o{ ORDER : places
    STUDENT }o--o{ COURSE : enrolls
    MANAGER |o--|| DEPARTMENT : manages
  • Cardinality is described using symbols at both ends of a relationship.
  • || → exactly one
  • o| or |o → zero or one
  • |{ or }| → one or more
  • o{ or }o → zero or more
  • These symbols can be combined to describe relationships such as one-to-one, one-to-many, many-to-many, and optional one-to-one.

Lesson ER.3 - Defining Entity Attributes

erDiagram
    CUSTOMER {
        int customerId
        string name
        string email
    }

    ORDER {
        int orderId
        date orderDate
        decimal total
    }

    CUSTOMER ||--o{ ORDER : places

erDiagram
    CUSTOMER {
        int customerId
        string name
        string email
    }

    ORDER {
        int orderId
        date orderDate
        decimal total
    }

    CUSTOMER ||--o{ ORDER : places
  • Attributes are defined inside {} after an entity name.
  • Each attribute is written as Type attributeName.
  • Entities can be declared separately and then connected using relationships.

Lesson ER.4 - Attribute Keys (PK, FK, UK)

erDiagram
    CUSTOMER {
        int customerId PK
        string name
        string email UK
    }

    ORDER {
        int orderId PK
        int customerId FK
        date orderDate
    }

    CUSTOMER ||--o{ ORDER : places

erDiagram
    CUSTOMER {
        int customerId PK
        string name
        string email UK
    }

    ORDER {
        int orderId PK
        int customerId FK
        date orderDate
    }

    CUSTOMER ||--o{ ORDER : places
  • Mermaid lets you mark important attributes using key annotations.
  • PK → Primary Key
  • FK → Foreign Key
  • UK → Unique Key
  • These annotations appear after the attribute declaration.

Lesson ER.5 - Attribute Comments

erDiagram
    CUSTOMER {
        int customerId PK
        string name
        string email "Must be unique"
        date createdOn "Account creation date"
    }

erDiagram
    CUSTOMER {
        int customerId PK
        string name
        string email "Must be unique"
        date createdOn "Account creation date"
    }
  • Attributes can include comments enclosed in double quotes (").
  • Comments are displayed alongside the attribute in the diagram.
  • This is useful for documenting constraints, descriptions, or business rules.

Lesson ER.6 - Composite Primary Keys

erDiagram
    ENROLLMENT {
        int studentId PK
        int courseId PK
        date enrolledOn
    }

erDiagram
    ENROLLMENT {
        int studentId PK
        int courseId PK
        date enrolledOn
    }
  • An entity can have multiple attributes marked as PK.
  • Together, they form a composite primary key.
  • This is commonly used in junction (bridge) tables for many-to-many relationships.

Lesson ER.7 - Multiple Relationships

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_ITEM : contains
    PRODUCT ||--o{ ORDER_ITEM : appears_in

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_ITEM : contains
    PRODUCT ||--o{ ORDER_ITEM : appears_in
  • An ER diagram can contain multiple relationships between different entities.
  • Each relationship is declared on its own line.
  • Together, these relationships form a connected data model.

Lesson ER.8 - Recursive (Self) Relationship

erDiagram
    EMPLOYEE ||--o{ EMPLOYEE : manages

erDiagram
    EMPLOYEE ||--o{ EMPLOYEE : manages
  • An entity can have a relationship with itself.
  • This is called a recursive or self-referencing relationship.
  • Read it as: “One EMPLOYEE manages zero or more EMPLOYEEs.”
  • Common examples: Employee–Manager, Category–Subcategory, Folder–Subfolder.

Lesson ER.9 - Many-to-Many Relationship Using a Junction Table

erDiagram
    STUDENT ||--o{ ENROLLMENT : has
    COURSE ||--o{ ENROLLMENT : has

    ENROLLMENT {
        int studentId PK, FK
        int courseId PK, FK
        date enrolledOn
    }

erDiagram
    STUDENT ||--o{ ENROLLMENT : has
    COURSE ||--o{ ENROLLMENT : has

    ENROLLMENT {
        int studentId PK, FK
        int courseId PK, FK
        date enrolledOn
    }
  • A many-to-many relationship is typically modeled using a junction (bridge) table.
  • ENROLLMENT connects STUDENT and COURSE.
  • studentId and courseId together form a composite primary key and are also foreign keys.
  • Additional relationship-specific data (such as enrolledOn) belongs in the junction table.

Lesson ER.10 - Complete ER Diagram (Putting It All Together)

erDiagram
    CUSTOMER {
        int customerId PK
        string name
        string email UK
    }

    ORDER {
        int orderId PK
        int customerId FK
        date orderDate
        decimal total
    }

    PRODUCT {
        int productId PK
        string name
        decimal price
    }

    ORDER_ITEM {
        int orderId PK, FK
        int productId PK, FK
        int quantity
    }

    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_ITEM : contains
    PRODUCT ||--o{ ORDER_ITEM : appears_in

erDiagram
    CUSTOMER {
        int customerId PK
        string name
        string email UK
    }

    ORDER {
        int orderId PK
        int customerId FK
        date orderDate
        decimal total
    }

    PRODUCT {
        int productId PK
        string name
        decimal price
    }

    ORDER_ITEM {
        int orderId PK, FK
        int productId PK, FK
        int quantity
    }

    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_ITEM : contains
    PRODUCT ||--o{ ORDER_ITEM : appears_in
  • This example combines the most important ER diagram concepts into a single realistic model.
  • It demonstrates entities, attributes, primary keys, foreign keys, composite primary keys, and multiple relationships.
  • ORDER_ITEM acts as a junction table to model the many-to-many relationship between ORDER and PRODUCT.

Class Diagrams

Lesson CD.1 - Declaring a Class

classDiagram
    class Person

classDiagram
    class Person
  • classDiagram tells Mermaid that this is a UML class diagram.
  • class Person declares a class named Person.
  • This is the smallest valid class diagram.
  • Think of it as the Mermaid equivalent of class Person { } in C#.

Lesson CD.2 - Class Body (Attributes & Methods)

classDiagram
    class Person {
        name
        age
        greet()
    }

classDiagram
    class Person {
        name
        age
        greet()
    }
  • Curly braces {} define the contents of a class.
  • Lines without () are attributes (fields/properties).
  • Lines with () are methods (functions/operations).

Lesson CD.3 - Attribute & Method Types

classDiagram
    class Person {
        string name
        int age
        void greet()
        bool isAdult()
    }

classDiagram
    class Person {
        string name
        int age
        void greet()
        bool isAdult()
    }
  • Attributes can include a type before the name: string name, int age.
  • Methods can specify a return type before the method name: void greet(), bool isAdult().

Lesson CD.4 - Method Parameters

classDiagram
    class Person {
        string name
        void greet(string message)
        void celebrateBirthday(int years)
        bool canVote(int minimumAge)
    }

classDiagram
    class Person {
        string name
        void greet(string message)
        void celebrateBirthday(int years)
        bool canVote(int minimumAge)
    }
  • Methods can accept one or more parameters inside ().
  • Each parameter is written as Type parameterName.

Lesson CD.5 - Visibility (+, -, #, ~)

classDiagram
    class Person {
        +string name
        -int age
        #void calculateAge()
        ~void printDetails()
    }

classDiagram
    class Person {
        +string name
        -int age
        #void calculateAge()
        ~void printDetails()
    }
  • + → public
  • - → private
  • # → protected
  • ~ → package/internal (rarely used in C#; closest concept is internal)
  • Visibility can be applied to both attributes and methods.

Lesson CD.6 - Multiple Classes

classDiagram
    class Person {
        +string name
    }

    class Car {
        +string model
    }

    class Book {
        +string title
    }

classDiagram
    class Person {
        +string name
    }

    class Car {
        +string model
    }

    class Book {
        +string title
    }
  • A class diagram can contain any number of classes.
  • Simply declare each class using another class <ClassName> block.
  • At this point, the classes are independent—there are no relationships between them yet.

Lesson CD.7 - Association (Relationship Between Classes)

classDiagram
    class Person
    class Car

    Person --> Car

classDiagram
    class Person
    class Car

    Person --> Car
  • --> creates an association from one class to another.
  • Read it as: “Person is associated with Car.”
  • This is the simplest way to connect two classes.
  • The arrow indicates navigability (from Person to Car).

Lesson CD.8 - Naming a Relationship

classDiagram
    class Person
    class Car

    Person --> Car : owns

classDiagram
    class Person
    class Car

    Person --> Car : owns
  • Add : label after a relationship to describe its meaning.
  • Read it as: “Person owns Car.”
  • Relationship labels make diagrams much easier to understand.

Lesson CD.9 - Multiplicity (Cardinality)

classDiagram
    class Person
    class Car

    Person "1" --> "0..*" Car : owns

classDiagram
    class Person
    class Car

    Person "1" --> "0..*" Car : owns
  • Multiplicity specifies how many objects can participate in the relationship.
  • "1" means exactly one.
  • "0..*" means zero or more.
  • Read this as: “One Person can own zero or more Cars.”
  • Common multiplicities:
    • "1" → exactly one
    • "0..1" → zero or one (optional)
    • "*" or "0..*" → zero or more
    • "1..*" → one or more

Lesson CD.10 - Inheritance (Generalization)

classDiagram
    class Animal
    class Dog
    class Cat

    Animal <|-- Dog
    Animal <|-- Cat

classDiagram
    class Animal
    class Dog
    class Cat

    Animal <|-- Dog
    Animal <|-- Cat
  • <|-- represents inheritance (generalization).
  • Read it as: “Dog inherits from Animal” and “Cat inherits from Animal.”

Lesson CD.11 - Interface Realization (Implements)

classDiagram
    class IShape {
        <<interface>>
        +draw()
    }

    class Circle

    IShape <|.. Circle

classDiagram
    class IShape {
        <<interface>>
        +draw()
    }

    class Circle

    IShape <|.. Circle
  • <<interface>> marks a class as an interface.
  • <|.. means implements (realization).
  • Read it as: “Circle implements IShape.”

Lesson CD.12 - Dependency (Uses)

classDiagram
    class OrderService
    class EmailService

    OrderService ..> EmailService : uses

classDiagram
    class OrderService
    class EmailService

    OrderService ..> EmailService : uses
  • ..> represents a dependency.
  • Read it as: “OrderService uses EmailService.”
  • A dependency means one class temporarily depends on another (e.g., as a method parameter, local variable, or temporary object), rather than owning it as a field.

Lesson CD.13 - Aggregation (Has-a, Weak Ownership)

classDiagram
    class Team
    class Player

    Team o-- Player : has

classDiagram
    class Team
    class Player

    Team o-- Player : has
  • o-- represents aggregation.
  • Read it as: “Team has Players.”
  • The hollow diamond (o) indicates weak ownership—the Player can exist independently of the Team.
  • Example: If a team is deleted, the players still exist and can join another team.

Lesson CD.14 - Composition (Has-a, Strong Ownership)

classDiagram
    class House
    class Room

    House *-- Room : contains

classDiagram
    class House
    class Room

    House *-- Room : contains
  • *-- represents composition.
  • Read it as: “House contains Rooms.”
  • The filled diamond (*) indicates strong ownership—the Room’s lifetime depends on the House.
  • Example: If the House is destroyed, its Rooms conceptually cease to exist as part of that house.

Lesson CD.15 - Relationship Arrow Cheat Sheet

classDiagram
    class A
    class B

    A --> B : association
    A ..> B : dependency
    A <|-- B : inheritance
    A <|.. B : implements
    A o-- B : aggregation
    A *-- B : composition

classDiagram
    class A
    class B

    A --> B : association
    A ..> B : dependency
    A <|-- B : inheritance
    A <|.. B : implements
    A o-- B : aggregation
    A *-- B : composition
  • --> → Association (knows/has a reference to)
  • ..> → Dependency (uses temporarily)
  • <|-- → Inheritance (extends / : in C#)
  • <|.. → Interface realization (implements)
  • o-- → Aggregation (weak ownership)
  • *-- → Composition (strong ownership)
  • This lesson summarizes all six core UML class relationships you’ll use most often.

Lesson CD.16 - Relationship Direction

classDiagram
    class Customer
    class Order

    Customer --> Order : places
    Order --> Customer : belongs to

classDiagram
    class Customer
    class Order

    Customer --> Order : places
    Order --> Customer : belongs to
  • The arrow direction matters.
  • Customer --> Order means Customer knows about / navigates to Order.
  • Order --> Customer means Order knows about / navigates to Customer.
  • You can even have arrows in both directions if both classes reference each other.

Lesson CD.17 - Association Without an Arrow (Bidirectional)

classDiagram
    class Customer
    class Supplier

    Customer -- Supplier : does business with

classDiagram
    class Customer
    class Supplier

    Customer -- Supplier : does business with
  • -- represents an association without navigability.
  • Read it simply as: “Customer does business with Supplier.”
  • Unlike -->, neither class is shown as “knowing” the other.
  • Use this when the relationship exists, but direction isn’t important.

Lesson CD.18 - Constructors

classDiagram
    class Person {
        +Person()
        +Person(string name, int age)
        +string name
        +int age
    }

classDiagram
    class Person {
        +Person()
        +Person(string name, int age)
        +string name
        +int age
    }
  • Constructors are written like methods, but their name is the same as the class.
  • Constructors do not have a return type (void is not used).
  • Multiple constructors can be shown to represent constructor overloading.

Lesson CD.19 - Static Members

classDiagram
    class Math {
        +double PI$
        +int Abs(int value)$
        +int Max(int a, int b)$
    }

classDiagram
    class Math {
        +double PI$
        +int Abs(int value)$
        +int Max(int a, int b)$
    }
  • $ denotes a static attribute or method.
  • A static member belongs to the class, not to an instance (object).
  • Static members can still have visibility (+, -, #, ~).

Lesson CD.20 - Abstract Classes & Abstract Methods

classDiagram
    class Animal {
        <<abstract>>
        +void makeSound()*
        +void sleep()
    }

    class Dog {
        +void makeSound()
    }

    Animal <|-- Dog

classDiagram
    class Animal {
        <<abstract>>
        +void makeSound()*
        +void sleep()
    }

    class Dog {
        +void makeSound()
    }

    Animal <|-- Dog
  • <<abstract>> marks a class as abstract.
  • * after a method marks it as an abstract method.
  • Dog inherits from Animal and provides its own implementation of makeSound().
  • sleep() is a normal (concrete) method inherited as-is.

Lesson CD.21 - Generic Classes

classDiagram
    class Repository~T~ {
        +T getById(int id)
        +void save(T item)
    }

classDiagram
    class Repository~T~ {
        +T getById(int id)
        +void save(T item)
    }
  • Mermaid represents generic types using ~ instead of < and >.
  • Repository~T~ is rendered as Repository<T>.
  • Generic type parameters can be used in attributes and method signatures.

Sequence Diagrams

Lesson SQ.1 - Basic Message Between Participants

sequenceDiagram
    Alice->>Bob: Hello Bob

sequenceDiagram
    Alice->>Bob: Hello Bob
  • sequenceDiagram tells Mermaid that this is a sequence diagram.
  • Alice and Bob are automatically created as participants.
  • ->> sends a message from one participant to another.
  • : Hello Bob labels the message.
  • Time flows from top to bottom, so later messages appear lower in the diagram.

Lesson SQ.2 - Multiple Messages

sequenceDiagram
    Alice->>Bob: Hello
    Bob->>Alice: Hi
    Alice->>Bob: How are you?

sequenceDiagram
    Alice->>Bob: Hello
    Bob->>Alice: Hi
    Alice->>Bob: How are you?
  • Messages are drawn from top to bottom in the order they occur.
  • Each new message is placed below the previous one, representing the passage of time.
  • Participants remain active throughout the conversation.

Lesson SQ.3 - Different Message Arrows

sequenceDiagram
    Alice->Bob: Synchronous
    Alice->>Bob: Asynchronous
    Bob-->>Alice: Reply

sequenceDiagram
    Alice->Bob: Synchronous
    Alice->>Bob: Asynchronous
    Bob-->>Alice: Reply
  • Mermaid supports different message arrow styles.
  • -> → Simple (solid) message.
  • ->> → Asynchronous message (commonly used as the default).
  • -->> → Reply/return message.

Lesson SQ.4 - Activation Boxes

sequenceDiagram
    Alice->>Bob: Request
    activate Bob
    Bob-->>Alice: Response
    deactivate Bob

sequenceDiagram
    Alice->>Bob: Request
    activate Bob
    Bob-->>Alice: Response
    deactivate Bob
  • An activation box (thin rectangle) shows that a participant is actively executing or processing a request.
  • activate <Participant> starts the activation.
  • deactivate <Participant> ends the activation.
  • Activation boxes help visualize when a participant is busy handling a message.

Lesson SQ.5 - Self Message

sequenceDiagram
    Alice->>Alice: Validate Input

sequenceDiagram
    Alice->>Alice: Validate Input
  • A participant can send a message to itself.
  • This is called a self message (or self call).
  • It is commonly used to represent an internal method call or processing step within the same object.

Lesson SQ.6 - Notes

sequenceDiagram
    Alice->>Bob: Login Request
    Note right of Bob: Validate credentials
    Bob-->>Alice: Login Successful

sequenceDiagram
    Alice->>Bob: Login Request
    Note right of Bob: Validate credentials
    Bob-->>Alice: Login Successful
  • Note adds explanatory text to a sequence diagram.
  • Notes can be placed left or right of a participant.
  • Use notes to document important details without making them part of the message flow.

Lesson SQ.7 - Notes Across Multiple Participants

sequenceDiagram
    Alice->>Bob: Process Payment
    Note over Alice,Bob: Communication happens over HTTPS
    Bob-->>Alice: Payment Successful

sequenceDiagram
    Alice->>Bob: Process Payment
    Note over Alice,Bob: Communication happens over HTTPS
    Bob-->>Alice: Payment Successful
  • Note over places a note spanning one or more participants.
  • Separate multiple participants with a comma.
  • This is useful for documenting assumptions, protocols, or shared context.

Lesson SQ.8 - Loop

sequenceDiagram
    loop For each item
        Alice->>Bob: Process Item
        Bob-->>Alice: Done
    end

sequenceDiagram
    loop For each item
        Alice->>Bob: Process Item
        Bob-->>Alice: Done
    end
  • loop represents a sequence of interactions that repeats.
  • The text after loop describes the loop condition or purpose.
  • end marks the end of the loop block.

Lesson SQ.9 - Alternative Paths (alt)

sequenceDiagram
    Alice->>Bob: Login Request

    alt Valid Credentials
        Bob-->>Alice: Login Successful
    else Invalid Credentials
        Bob-->>Alice: Login Failed
    end

sequenceDiagram
    Alice->>Bob: Login Request

    alt Valid Credentials
        Bob-->>Alice: Login Successful
    else Invalid Credentials
        Bob-->>Alice: Login Failed
    end
  • alt represents conditional branching (similar to an if-else statement).
  • else defines an alternative path.
  • end closes the alt block.

Lesson SQ.10 - Optional Block (opt)

sequenceDiagram
    Alice->>Bob: Login Request

    opt Remember Me Checked
        Bob->>Bob: Generate Persistent Token
    end

    Bob-->>Alice: Login Successful

sequenceDiagram
    Alice->>Bob: Login Request

    opt Remember Me Checked
        Bob->>Bob: Generate Persistent Token
    end

    Bob-->>Alice: Login Successful
  • opt represents an optional sequence of interactions.
  • Unlike alt, there is no else branch.
  • Use it when a block executes only if a condition is true.
  • end closes the optional block.

Lesson SQ.11 - Parallel Execution (par)

sequenceDiagram
    par Send Email
        Alice->>EmailService: Send Email
    and Send SMS
        Alice->>SmsService: Send SMS
    end

sequenceDiagram
    par Send Email
        Alice->>EmailService: Send Email
    and Send SMS
        Alice->>SmsService: Send SMS
    end
  • par represents parallel (concurrent) execution.
  • and separates parallel branches.
  • end closes the parallel block.
  • Use this when multiple actions can occur simultaneously rather than one after another.

Lesson SQ.12 - Break Block (break)

sequenceDiagram
    Alice->>Bob: Login Request

    break Invalid Credentials
        Bob-->>Alice: Login Failed
    end

    Bob-->>Alice: Login Successful

sequenceDiagram
    Alice->>Bob: Login Request

    break Invalid Credentials
        Bob-->>Alice: Login Failed
    end

    Bob-->>Alice: Login Successful
  • break represents a condition that terminates the normal interaction flow.
  • If the break condition is met, the remaining sequence is skipped.
  • It is useful for modeling early exits such as validation failures or errors.

Lesson SQ.13 - Creating a Participant

sequenceDiagram
    create participant Order
    Alice->>Order: Create Order

sequenceDiagram
    create participant Order
    Alice->>Order: Create Order
  • create participant indicates that a participant is created during the interaction, rather than existing from the beginning.
  • This is useful for modeling object creation (e.g., new Order()).
  • The participant appears in the diagram at the point it is created.

Lesson SQ.14 - Complete Sequence Diagram (Putting It All Together)

sequenceDiagram
    Alice->>Bob: Login Request
    activate Bob

    alt Valid Credentials
        Bob->>Bob: Validate Password

        opt Remember Me Checked
            Bob->>Bob: Generate Token
        end

        par Send Email
            Bob->>EmailService: Send Email
        and Write Audit Log
            Bob->>AuditService: Save Log
        end

        Bob-->>Alice: Login Successful

    else Invalid Credentials
        Bob-->>Alice: Login Failed
    end

    deactivate Bob

sequenceDiagram
    Alice->>Bob: Login Request
    activate Bob

    alt Valid Credentials
        Bob->>Bob: Validate Password

        opt Remember Me Checked
            Bob->>Bob: Generate Token
        end

        par Send Email
            Bob->>EmailService: Send Email
        and Write Audit Log
            Bob->>AuditService: Save Log
        end

        Bob-->>Alice: Login Successful

    else Invalid Credentials
        Bob-->>Alice: Login Failed
    end

    deactivate Bob
  • This example combines the most important sequence diagram concepts into a single realistic interaction.
  • It demonstrates messages, reply messages, activation, self messages, alt, opt, and par.
  • Time flows from top to bottom, showing the order in which interactions occur.

State Diagrams

Lesson ST.1 - Initial State and Transition

stateDiagram-v2
    [*] --> Idle

stateDiagram-v2
    [*] --> Idle
  • stateDiagram-v2 tells Mermaid that this is a state diagram.
  • [*] represents the initial state.
  • --> defines a transition from one state to another.
  • Every state machine typically begins from a single initial state.

Lesson ST.2 - Multiple States and Transitions

stateDiagram-v2
    [*] --> Idle
    Idle --> Processing
    Processing --> Completed

stateDiagram-v2
    [*] --> Idle
    Idle --> Processing
    Processing --> Completed
  • A state diagram models how an object moves between different states.
  • Each arrow represents a possible state transition.
  • The order of transitions defines the lifecycle of the object.

Lesson ST.3 - Transition Labels

stateDiagram-v2
    [*] --> Idle
    Idle --> Processing : Start
    Processing --> Completed : Finish

stateDiagram-v2
    [*] --> Idle
    Idle --> Processing : Start
    Processing --> Completed : Finish
  • A transition may have a label describing what triggers it.
  • Labels are written after :.
  • Typical labels are events such as Start, Cancel, or Timeout.

Lesson ST.4 - Final State

stateDiagram-v2
    [*] --> Idle
    Idle --> Processing
    Processing --> [*]

stateDiagram-v2
    [*] --> Idle
    Idle --> Processing
    Processing --> [*]
  • [*] can also represent the final state.
  • A transition into the final state indicates that the state machine has finished.
  • Most state diagrams have one initial state and zero or more final states.

Lesson ST.5 - Choice (Decision)

stateDiagram-v2
    [*] --> Validate

    Validate --> Approved : Valid
    Validate --> Rejected : Invalid

stateDiagram-v2
    [*] --> Validate

    Validate --> Approved : Valid
    Validate --> Rejected : Invalid
  • A state can transition to different next states.
  • Transition labels describe the condition or event leading to each path.
  • This models a simple decision in the workflow.

Lesson ST.6 - Composite State

stateDiagram-v2
    [*] --> Authentication

    state Authentication {
        [*] --> EnterCredentials
        EnterCredentials --> Verify
        Verify --> Success
    }

    Authentication --> Dashboard

stateDiagram-v2
    [*] --> Authentication

    state Authentication {
        [*] --> EnterCredentials
        EnterCredentials --> Verify
        Verify --> Success
    }

    Authentication --> Dashboard
  • A state can contain its own nested state machine.
  • Such a state is called a composite state.
  • Composite states help organize large workflows into smaller pieces.

Lesson ST.7 - Composite State with an Exit Transition

stateDiagram-v2
    [*] --> Authentication

    state Authentication {
        [*] --> EnterCredentials
        EnterCredentials --> Verify
        Verify --> Success
    }

    Success --> Dashboard

stateDiagram-v2
    [*] --> Authentication

    state Authentication {
        [*] --> EnterCredentials
        EnterCredentials --> Verify
        Verify --> Success
    }

    Success --> Dashboard
  • A transition can leave a nested state and move to a state outside the composite state.
  • This shows how control exits a composite state after its internal workflow completes.
  • Composite states help organize complex state machines into smaller, manageable sections.

Lesson ST.8 - Notes

stateDiagram-v2
    [*] --> Processing

    note right of Processing
        Waiting for payment
    end note

    Processing --> Completed

stateDiagram-v2
    [*] --> Processing

    note right of Processing
        Waiting for payment
    end note

    Processing --> Completed
  • Notes provide additional information without affecting the state machine.
  • Notes can be placed beside a state.
  • Use notes to document assumptions or implementation details.

Lesson ST.9 - Self Transition

stateDiagram-v2
    [*] --> Processing
    Processing --> Processing : Retry

stateDiagram-v2
    [*] --> Processing
    Processing --> Processing : Retry
  • A state may transition back to itself.
  • This is called a self transition.
  • It is commonly used for retries, repeated validation, or polling.

Lesson ST.10 - Complete State Diagram (Putting It All Together)

stateDiagram-v2
    [*] --> Idle

    Idle --> Processing : Start
    Processing --> Processing : Retry
    Processing --> Completed : Success
    Processing --> Failed : Error

    note right of Processing
        Waiting for response
    end note

    Completed --> [*]
    Failed --> [*]

stateDiagram-v2
    [*] --> Idle

    Idle --> Processing : Start
    Processing --> Processing : Retry
    Processing --> Completed : Success
    Processing --> Failed : Error

    note right of Processing
        Waiting for response
    end note

    Completed --> [*]
    Failed --> [*]
  • This example combines the most important state diagram concepts into a single realistic state machine.
  • It demonstrates initial state, final state, transitions, transition labels, self transitions, and notes.
  • State diagrams model the lifecycle of an object by showing how it moves from one state to another in response to events.

Graph View