State Machine Diagrams in UML

• Each class has objects that may have status conditions known as "states".
• Object behavior consists of the various states and the movement between these states.
• State is a condition during an object's life when it satisfies a criterion, performs an action, or waits for an event.
• Transition involves the movement of an object from one state to another
• A State Machine is an abstract concept used to identify objects behaving like a "Machine" that can be in one of many finite states

State Machine Diagrams

• A State Machine Diagram is a type of behavioral diagram within UML that represents the different states of an object and the transitions based on events.
• It originated from the finite state machine (FSM) concept in computer science.
• A Finite State Machine stores the state of something and will change based on inputs, providing output for implemented changes.
• The concept was introduced in the early 20th century.
• Claude Shannon and Warren Weaver contributed to automata theory in the 1940s in their work on Information Theory, which had influence over finite state machines.

David Harel's Contribution (1987)

• In 1987, David Harel introduced Statecharts, an extension of state machines that allows for hierarchical states, parallelism, and other complex features.
• Harel published "Statecharts: A Visual Formalism for Complex Systems," which laid the foundation for state diagrams used today
• Harel's approach was intended to better model complex reactive systems, especially in software design

Incorporation into UML (1990s)

• In the 1990s, Grady Booch, Ivar Jacobson, and James Rumbaugh, creators of UML, adopted and adapted Harel's statecharts for use in UML, leading to the State Machine Diagrams used today.
• UML version 1.0 introduced in 1997, formally incorporated State Machine Diagrams to model object behavior.

Today's Usage

• State Machine Diagrams are widely used in system analysis, designing, and documenting dynamic behaviors in software systems.
• These diagrams are applied in event-driven systems, embedded systems, communication protocols, and workflow modeling.
• A state machine is anything that can have different states.
• States consist of different combinations of information hold by an object

Applications of a State Machine Diagram

• For depicting event-driven objects in a reactive system
• For illustrating use case scenarios in a business context.
• To describe how an object moves through various states within its lifetime.
• It shows overall behavior

State Machine Diagram Components

• State Machine Diagram shows the life of an object in states and transitions
• Origin state is the original state of an object before a transition.
• Destination state is the state to which an object moves after completing a transition.
• Pseudostate is a state machine diagram's starting point, denoted by a black circle.
• Action-expression is an activity completed as part of a transition.
• Guard-condition is a true/false test to determine whether a transition can occur.
• A transition-name can include a trigger, a guard, and an action-expression.

Transition Statement Syntax

• transition-name(parameters, ...)[guard-condition] / action-expression

Concurrency

• Concurrent states exist when an object is in one or more states simultaneously.
• Concurrent states are in State Machine Diagrams to represent multiple states that can exist and operate independently at the same time.
• Concurrency is similar to multitasking in computer systems.
• It is a way of representing parallelism and can be useful in modeling software systems where concurrently running components are needed.

Concurrent State Example: Elevator

• Main Control State consists of Idle, MovingUp, and MovingDown states.
• Transitions for the Main Control State include:
  • Idle goes to MovingUp when the "Up" button pressed.
  • Idle goes to MovingDown when the "Down" button pressed.
  • MovingUp goes to Idle when the desired floor is reached.
  • MovingDown goes to Idle when the desired floor is reached.
• Door Control State has Open and Closed states.
• Transitions for the Door Control State include:
  • Closed goes to Open when the "Open" button is pressed.
  • Open goes to Closed after a certain amount of time or when the "Close" button is pressed.
• Elevator's Main Control and Door Control states can exist concurrently.
• Where one aspect doesn't affect the other

Types of States

• Composite States contain other states and transitions.
  • For example, a Printer can be On, and either Idle or Working.
• Concurrent Paths exist as multiple paths in a composite state where the Printer's On paths are independent.
• Path is a sequential set of connected states and transitions.
• Concurrent Paths are followed concurrently where states in one path are parallel to another path.
• Concurrent paths are shown by synchronization bars, similar to Activity Diagrams.
• Multiple exits from a state indicate an "OR" condition.
• Multiple exits from a synchronization bar indicate an "AND" condition.

Creating a State Machine Diagram Process

• Review the class diagram and select classes needing state machine diagrams.
• Create status conditions/states
• Transitions cause an object to leave the identified state
• Sequence states and aggregate combinations into larger fragments
• Review path for independent and concurrent paths
• Include additional transitions and test both directions.
• Expand each transition with messages, events, guard conditions, and action expressions.
• Review and Test

RMO Example - SaleItem

• Status conditions are tracked
• The states are Open, Ready to Ship, On back order, and Shipped

InventoryItem

• The states are Normal stock, Low stock, Zero stock, On order, and Not on order.

Process Sale

• Waiting For Sale, Entering Items, and Waiting for Payment
• These arise from Process Sale use case
• Transitions are system events

Bank Account States

• The states include active, overdrawn, closed, and deleted
• Account starts as active. The account can:
  • Remain active
  • Become overdrawn
  • Be closed
• trx stands for “transaction" which represents a deposit or withdrawal
• [pos] indicates the balance is positive
• [neg] indicates balance is negative

Machine Diagram Exercise

• The machine can accept coins, dispense, the drink, and give change

Steps to follow:

Identify states of the vending machine

• Idle (Waiting for user input)
• Accepting Coins
• Ready to Dispense
• Dispensing Drink
• Returning Change

Identify Transitions between states

• From Idle to Accepting Coins (user coin insertion)
• From Accepting Coins to Ready to Dispense (correct amount reached)
• From Ready to Dispense to Dispensing Drink (user selects drink)
• From Dispensing Drink to Returning Change (extra coins inserted)
• To Idle (after completing/returning transaction)
• The states are Idle, Accepting Coins, Ready to Dispense, Dispensing Drink, and Returning Change

States and Transitions

• Event (State Change)
• Coin inserted (Move to Accepting Coins)
• Correct amount entered (Move to Ready to Dispense)
• Insufficient amount entered (Stay in Accepting Coins)
• User selects a drink (Move to Dispensing Drink)
• Drink is dispensed (Move to Returning Change)
• Change returned/no change needed (Move to Idle)

UML for Dispensing Machine

• Coin inserted (Transitions to Accepting Coins)
• Correct amount inserted (Transitions to Ready to Dispense)
• Insufficient amount inserted (Stay in Accepting Coins)
• User selects a drink (Transitioning to Dispensing Drink)
• Drink dispensed (Transitioning to Returning Change if change needed)
• Change returned (Transitioning back to Idle)

From State Machine Diagram to a Class Diagram

• Vending machine capabilities encapsulate machine diagrams behavior

Mapping States to Attributes

• Transitions occur through different Attributes

Attributes

• States usually captured in the design class:
• Public class for the Machine
  • Has private enum State
  • Private State currentState

Events as Transitions or Methods as Methods

• State Change maps events and methods modifying the object's behaviour

Events

• Events triggered correspond to methods (ex: Coin Inserted corresponds with function insertCoin)
• The object transitions from methods based on conditions/input

Adding Transitions Logic

• Machine triggers transitions based on transitions through events
• Transitions between states are reflected in the methods
• If (currentState = RDY to Disp), currentState = State.DISPENSING

Guard Conditions and State Constraints

• Guard conditions are modeled as methods

Actions on Entry and Exit

• State Diagram's states might have entry/exit actions.
• In class diagrams these are like that occur upon entering or leaving a state, and execute with state transitions.
• Entry Actions are called upon transitioning from states.
• Upon new state, the state transitions
• Upon entering a state to reset values and initialize

States

• Attributes/Enumerations in a class diagram.
• Transitions are modeled after methods
• Methods trigger events
• Guard conditions modeled as logic within the process
• Actions in the class diagram are methods that run when transitioning from one state to another.