State Machine Diagram

Introduction State chart diagram is used to visualize the reaction of a system by internal/external factors. Any real time system is expected to be reacted by some kind of internal/external events. These events are responsible for state change of the system. Statechart diagram is used to represent the event driven state change of a system. It basically describes the state change of a class, interface etc. It is a familiar technique to describe the behavior of a system. In OO approach, draw state machine diagram for a single class to show the lifetime behavior of a single object

Event Driven System The door can be in one of three states: "Opened", "Closed" or "Locked". It can respond to the events Open, Close, Lock and Unlock. Not all events are valid in all states; for example, if a door is opened, you cannot lock it until you close it.

Components of State Diagram States - A state is denoted by a round-cornered rectangle with the name of the state written inside it. Initial and Final States - The initial state is denoted by a filled black circle and may be labeled with a name. The final state is denoted by a circle with a dot inside and may also be labeled with a name.

Cond... Transitions - Transitions from one state to the next are denoted by lines with arrowheads. A transition may have a trigger, a guard and an effect, as below. "Trigger" is the cause of the transition, which could be a signal, an event, a change in some condition, or the passage of time. "Guard" is a condition which must be true in order for the trigger to cause the transition. "Effect" is an action which will be invoked directly on the object that owns the state machine as a result of the transition.

Cond... Self-Transitions - A state can have a transition that returns to itself. This is most useful when an effect is associated with the transition.

Example Scenario... I want to keep my valuables in a safe that's hard to find. So to reveal the lock to the safe, I have to remove a strategic candle from its holder, but this will reveal the lock only while the door is closed. Once I can see the lock, I can insert my key to open the safe. For extra safety, I make sure that I can open the safe only if I replace the candle first. If a thief neglects this precaution, I'll unleash a nasty monster to devour him.

Controller can be in three states: Wait, Lock, Open and have rules by which controller changes from state to state. These rules are in the form of transitions: the lines that connect the states. Transition indicates a movement from one state to another. Each transition has a label that comes in three parts: trigger-signature [guard]/activity The trigger-signature is an event that triggers a potential change of state. The guard is a Boolean condition that must be true for the transition to be taken. The activity is some behavior that's executed during the transition. It may be any behavioral expression.

Cond... All parts in transition are optional. The full form of a trigger-signature may include multiple events and parameters. A missing activity indicates that don't do anything during the transition. A missing guard indicates that always take the transition if the event occurs. A missing trigger-signature is rare but does occur. It indicates that take the transition immediately (called Activity states).

Cond... When an event occurs in a state, take only one transition out of it. So if you use multiple transitions with the same event then the guards must be mutually exclusive. Eg: Lock state If an event occurs and no transition is valid, then the event is ignored. Eg: a safe-closed event in the Wait state or a candle-removed event with the door closed. The final state indicates that the state machine is completed, implying the deletion of the controller object. Thus, if someone fall in trap, the controller object terminates. Eg: Final state need to put the rabbit in its cage and reboot the system.

Internal Activities States can react to events without transition, using internal activities: putting the event, guard, and activity inside the state box itself. An internal activity is similar to a self-transition: a transition that loops back to the same state.

Special activities Two special activities: the entry and exit activities. The entry activity is executed whenever you enter a state; The exit activity, whenever you leave. However, internal activities do not trigger the entry and exit activities; that is the difference between internal activities and self-transitions.

Activity States In states, the object is quiet and waiting for the next event before it does something. A special state called Activity state, in which the object is doing some ongoing work.

Activity States Cond... The ongoing activity is marked with the do/; hence the term do-activity. Once the search is completed, any transitions without an activity are taken. Eg: Display new hardware If the cancel event occurs during the activity, the do-activity is halted, and go back to the Update Hardware Window state. Both do-activities and regular activities carrying out some behavior. Regular activities occur "instantaneously" and cannot be interrupted by regular events, while do-activities can take finite time and can be interrupted. UML 1 used the term action for regular activities and used activity for do-activities.

Superstates with nested Substates Several states share common transitions and internal activities. Make them as substates and move the shared behavior into a superstate.

Concurrent States States can be broken into several orthogonal state diagrams that run concurrently. Eg: Consider a pathetically simple alarm clock that can play either CDs or the radio and show either the current time or the alarm time. The choices CD/radio and current/alarm time are orthogonal choices.

History pseudostate History state is used to remember the previous state of a state machine when it was interrupted. when the clock is switched on, the radio/CD choice goes back to the state, the clock was in when it was turned off. The arrow from the history pseudostate indicates what state to be in on the first time when there is no history.

Choice Pseudo-State A choice pseudo-state is shown as a diamond notation with one transition arriving and two or more transitions leaving.

Junction pseudo-states Used to chain together multiple transitions. A single junction can have one or more incoming, and one or more outgoing, transitions; a guard can be applied to each transition. Junctions are semantic-free. A junction which splits an incoming transition into multiple outgoing transitions realizes a static conditional branch, but in choice pseudo-state which realizes a dynamic conditional branch.

Terminate Pseudo-State Entering a terminate pseudo-state indicates that the lifeline of the state machine has ended. A terminate pseudo-state is notated as a big cross.

Implementing State Diagrams A state diagram can be implemented in three main ways: Nested switch State pattern State tables Nested switch-most direct approach to handling a state diagram. Although it's direct, it's long-winded, even for this simple case. For this approach, It is also very easy to get out of control.

Nested switch

Implementing State Diagrams Cond... State pattern creates a hierarchy of state classes to handle behavior of the states. Each state in the diagram has one state subclass. The controller has methods for each event, which simply forwards to the state class. The state pattern is easier to put together when you need it, and although it needs a new class for each state, it's a small amount of code to write in each case.

State pattern

Implementing State Diagrams Cond... State table approach captures the state diagram information as data in a table. We then build either an interpreter that uses the state table at runtime or a code generator that generates classes based on the state table. Obviously, the state table is more work to do once, but then you can use it every time you have a state problem to hold. A runtime state table can also be modified without recompilation.

State Table

When to Use State Diagrams? State diagrams are good at describing the behavior of an object across several use cases. State diagrams are not very good at describing behavior that involves a number of objects collaborating. Use state diagrams only for those classes that exhibit interesting behavior, where building the state diagram helps you understand what is going on.