Architectural Modelling
State Chart Diagram
State chart Diagrams
Introduction
• Using a state machine, you can model the behavior
of an individual object.
• A state machine is a behavior that specifies the
sequences of states an object goes through during its
lifetime in response to events.
States
• A state is a condition or situation during the life of
an object
• An object remains in a state for a finite amount of
time
– It satisfies some condition, performs some activity,
or waits for some event.
A state has several parts.
1. Name:
A textual string that distinguishes the state from other states;
2. Entry/exit actions
Actions executed on entering and exiting the state, respectively
3. Internal transitions:
Transitions that are handled without causing a change in state
4. Substate :
The nested structure of a state, involving disjoint (sequentially
active) or concurrent (concurrently active) substates
5. Deferred events
A list of events that are not handled in that state but, rather, are
postponed and queued for handling by the object in another state
Initial and Final States
• An initial state, which indicates the default starting
place for the state machine or substate.
• An initial state is represented as a filled black circle.
• The final state, which indicates that the execution of
the state machine or the enclosing state has been
completed.
• A final state is represented as a filled black circle
surrounded by an unfilled circle.
Transition
• A transition is a relationship between two states
indicating that
– an object in the first state will perform certain actions
and
– enter the second state when a specified event occurs
and specified conditions are satisfied.
– On such a change of state, the transition is said to fire.
• Until the transition fires, the object is said to be in the
source state; after it fires, it is said to be in the target state.
The transition has five parts:
1. Source state
– if an object is in the source state, an outgoing transition may fire when
the object receives the trigger event of the transition and providing its
guard condition is satisfied
2. Event trigger
– The event whose reception by the object in the source state makes the
transition eligible to fire, providing its guard condition is satisfied
3. Guard condition
– A Boolean expression that is evaluated when the transition is triggered
by the reception of the event trigger;
• if the expression evaluates True, the transition is eligible to fire;
• if the expression evaluates False, the transition does not fire and
• if there is no other transition that could be triggered by that same
event, the event is lost
4. Action
– An executable atomic computation that may directly act on the object that
owns the state machine, and indirectly on other objects that are visible to
the object
5. Target state
– The state that is active after the completion of the transition
State Chart Diagrams
Introduction :
• Statechart diagrams are important for modeling the dynamic aspects of
systems.
• A Statechart diagram shows a state machine.
• An activity diagram is a special case of a Statechart diagram in which all
or most of the states are activity states and all or most of the transitions
triggered by completion of activities in the source state.
• Thus, both activity and Statechart diagrams are useful in modeling the
lifetime of an object.
• NOTE:
– An activity diagram shows flow of control from activity to activity
– A Statechart diagram shows flow of control from state to state.
State Chart Diagrams
Contents:
• Statechart diagrams commonly contain
– Simple states and composite states
– Transitions, including events and actions
• Like all other diagrams, Statechart diagrams may contain
– Notes
– Constraints.
Common uses:
• You use Statechart diagrams to model the dynamic aspects of a system.
These dynamic aspects may involve the event-ordered behavior of any kind
of object in any view of a system’s architecture.
• When you model the dynamic aspects of a system, a class, or a use case,
you will typically use Statechart diagrams in one way:
1) To model reactive objects
Modeling Reactive Objects
1. Choose the context for the state machine, whether it is a class, a use case, or
the system as a whole.
2. Choose the initial and final states for the object
3. Decide on the stable states of the object by considering the conditions in
which the object may exist for some identifiable period of time.
4. Decide on the meaningful partial ordering of stable states over the life time
of the object.
5. Decide on the events that may trigger a transition from state to state.
6. Attach actions to these transitions
7. Consider ways to simplify your machine by using sub states, branches,
forks, and joins.
8. Check that all states are reachable under some combination of events.
9. Trace through the state machine, either manually or by using tools, to
check it against expected sequences of events and their responses.
Forward and Reverse Engineering
Forward Engineering
• Forward engineering is possible for Statechart
diagrams, especially if the context of the diagram is a
class.
Reverse Engineering:
• Reverse engineering is theoretically possible, but
practically not very useful
• Reverse engineering tools have no capacity for
abstraction and therefore cannot automatically
produce meaningful Statechart diagrams.
ATM System
Online Shopping System
Reference:
1. Booch, Grady. The unified modeling language user guide.
Pearson Education India, 2005.
