0.0 by Claude

Chapter 9: Specifying Control - State Diagrams & Events

1.0 Introduction to State Diagrams

1.1 Purpose of State Diagrams

• Model dynamic behavior of classes
• Define object responses to messages (object behavior)
• Show how objects change states throughout their lifecycle

1.2 When to Use State Diagrams

• When object’s life changes from state to state (状态到状态)
• Only for entity classes with complex life cycles
• Not needed for all entity classes

1.3 How to Identify States

Look for status conditions that may need to be reported to:

• Management
• Customers
• Other stakeholders

Important: Draw one statechart for one entity class

2.0 State Diagram Components

2.1 States

State = A condition during an object’s life where it:

• Satisfies criteria
• Performs an action
• Waits for an event

Key characteristics:

• Semi-permanent conditions
• External events cause transitions to new states

2.2 State Naming Conventions

States can be named as:

• Simple conditions: ‘on’, ‘off’
• Active names using:
  • Gerunds (动名词): verbal nouns ending in -ing
  • Verb phrases: describing ongoing activities

2.3 Basic Notation

[Start] ●──→ [State A] ──→ [State B] ──→ ◉ [End]

• Filled circle (●): Initial/start state
• Rectangle: State
• Arrow: Transition
• Circle with dot (◉): Final/end state

3.0 Transitions

3.1 Definition

Transition = Movement that causes an object to leave one state and enter another

3.2 Transition Format

Event-name(parameter)[guard condition]/action-expression

The transition consists of three parts:

Part 1: Event-name(parameter)

• The trigger that causes the transition
• Can include parameters passed with the event

Part 2: [Guard Condition]

• Boolean condition that must be true for transition to occur
• Enclosed in square brackets []
• Examples: [balance > 0], [authorization = approved]

Part 3: /Action-expression

• Procedural statement describing action performed
• Executes when the transition fires
• Preceded by forward slash /

Important: A transition must have at least one of these three parts

3.3 Example Transition

dismissClass()[time >= 12:00]/student.packBag()

• Event: dismissClass()
• Guard: [time >= 12:00]
• Action: student.packBag()

4.0 Types of Events

4.1 Simple Events

Regular events triggered by messages or user actions

• Example: turnOn(), submit(), cancel()

4.2 Change Events

Triggered when a condition becomes true

• Format: when [condition]
• Example: when [rateStartDate <= currentDate]

4.3 Elapsed-Time Events

Triggered after a specific time period

• Format: after [time period]
• Example: after [1 year], after [5 years]

5.0 Common State Diagram Examples

5.1 Simple Light Bulb

[Start] ●──→ [Off] ──turnOn()──→ [On]
              ↑                    ↓
              └──turnOff()─────────┘
                                  ↓ burnOut()
                                  ◉ [End]

5.2 Payment Class

●──→ [Unpaid] ──partialPay()──→ [Partly Paid]
        ↓                            ↓
        └─────fullPay()──────→ [Fully Paid]

5.3 Order Processing

●──→ [Processing] ──[approved]──→ [Placed] ──→ [Shipped] ──→ [Received] ──→ ◉
          ↓
    [denied]
          ↓
      [Denied] ──withdraw()──→ ◉

6.0 Relationship with Other UML Models

State diagrams connect with:

• Use Case Diagrams: States reflect use case scenarios
• Class Diagrams: Each state diagram represents one class
• Sequence Diagrams: Events in state diagrams correspond to messages in sequence diagrams

7.0 State Diagram Development Process

7.1 Step-by-Step Approach

1. Review class diagram and select classes needing statecharts
2. Identify input messages across all sequence diagrams for selected class
3. List all states for each selected class
4. Build statechart fragments in correct order
5. Review paths for independent concurrent paths
6. Expand transitions with:
   • Message events
   • Guard conditions
   • Action expressions
7. Review and test each statechart

7.2 Selection Criteria

Create state diagrams for classes that have:

• Complex lifecycles
• Multiple states that need tracking
• Important status changes to report

8.0 Practice Examples

8.1 ATM Machine States

●──→ [Idle] ──cardIn()──→ [Active]
       ↑                      ↓
       └────done()────────────┘
       ↓                      ↓
    service()             cancel()
       ↓                      ↓
  [Out of Service]           [Idle]
       ↓
    fixed()
       ↓
    [Idle]

8.2 Patient Class

●──→ [Admitted] ──[Diagnosis=Healthy]──→ [Released]
         ↓
  [Diagnosis=Unhealthy]
         ↓
   [Observation] ──[Diagnosis=Healthy]──→ [Released]
         ↓
     [>5 years]
         ↓
    [Released]

9.0 Key Points for Exams

9.1 Essential Concepts

• State = semi-permanent condition in object’s life
• Transition = movement between states
• Event = trigger for transition
• Guard condition = boolean test for transition
• Action = operation performed during transition

9.2 Remember the Format

event(parameters)[guard]/action

• At least one component required
• Guards in square brackets
• Actions after forward slash

9.3 Common Patterns

• Initial state → Working states → Final state
• States represent conditions, not actions
• Transitions represent changes, triggered by events
• Guard conditions control when transitions can occur

9.4 Development Tips

• Start with sequence diagrams to identify messages/events
• Each complex entity class gets one state diagram
• Test all possible paths through the diagram
• Ensure consistency with other UML models