the object-oriented design workflow statechart diagrams
Post on 21-Dec-2015
233 views
TRANSCRIPT
THE OBJECT-ORIENTED DESIGN WORKFLOWStatechart Diagrams
Statechart Diagrams
Activity diagram versus a statechart diagram– Both model DYNAMIC behavior of a system– Activity diagrams are a special case of a statechart
diagram where the states are actions and the transitions are triggered automatically by the completion of a state’s action and activities
– Activity diagrams tend to be used for modeling business processes where several objects participate
– Statechart diagrams tend to be used for modeling the lifecyle history of a single reactive object (respond to external events, have states and transitions)
– Statechart most commonly used to model dynamic behavior of classes
Statechart Diagrams
Statechart Diagram– Statecharts (state diagrams) show the lifetime
behavior of a single object– Used to capture dynamic behavior by describing
all possible states and state changes as a result of events that reach the object
Finite State Machine (FSM)
A finite state machine is a conceptual machine with a finite number of states
It can be in only one of the states at any specific time
A state transition is a change in state that is caused by an input event
The next state depends on the current state as well as the input event
In UML, a state transition diagram is called a state chart
State Machines
States
The UML Reference Manual defines a state as, “a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event”.
The state of an object varies over time, but at any particular point it is determined by:– the object attribute values– the relationship it has to other objects– the activities it is performing
Key to successful statechart modeling is identifying the states that make a difference in your system
States
State Syntax
EnteringPassword
entry/display passwordexit/validate
alphaKeypress/echo “*”help/display
do/get
state name
entry and exit actions
internal transitions
internal activity
• Each state may contain zero or more actions and activities• Actions are instantaneous and uninterruptible• Activities take a finite amount of time and can be interrupted
Simple Example – Light Bulb
Off
On
turnOff turnOn
event trigger
Simple Example – Bank Account
Actions & Activities
Two special actions:– Entry action (associated with entry event)– Entry event occurs instantaneously and automatically on
entry into the state» It is the first thing that happens when the state is entered» Causes the associated entry action to execute
– Exit event is the last that happens instantaneously and automatically on exit from the state» Causes the associated exit action to execute
Activities take a finite time and may be interrupted by the receipt of an event– Keyword do indicates an activity– May not finish due to interruption
Transitions
UML Syntax
anEvent – this is an external or internal occurrence that triggers the transition
guardCondition – this is a Boolean expression the must evaluate to TRUE before a transition can occur
anAction – this is a piece of work associated with the transition and occurs when the transition fires
A BanEvent [guardCondition] / anAction
UML Transition Syntax
Transitions
Events and External Actions
State transitions occur in response to events If there is more than one transition out of a state, a guard
condition determines which transition is fired An action may occur when the transition fires (multiple
actions should be expressed in a comma separated list) If there is no action associated with a transition, the event
only causes the change of state, and there is no observable response from the object unless it has internal actions
State_1
State_2
entry / entry_actionexit / exit_action
do / activity
event [guard] / action
Types of Events
Call event– simplest type of event– the receipt of a call
event is a request for a set of actions to occur
– Really just a request for a specific method to be invoked
Call Events
deposit(m)/balance:=balance+mwithdraw(n)/balance:=balance-n;return balance
InCredit
deposit(m)/balance:=balance+mwithdraw(n)/balance:=balance-n;return balance
Overdrawn
[balance < 0] [balance >=0]
Bank Acccount
Types of Events
Signal Event– Package of information that is
sent asynchronously between objects
– Modeled as a stereotyped class that contains all of the communication information as its attributes
Signal Events
in date : charin accountNumber : longin amountOverdrawn : double
«signal»OverdrawnAccount
Types of Events
Change events– has the keyword
when, and then a Boolean expression
– action associated with the event is performed when the Boolean expression is true
– All values in the Boolean expression must be attributes of the context class
InCredit
when(balance<overdraftLimit/notifyManager
Overdrawn
[balance < 0] [balance >= 0]
Change event
keyword
Boolean expressionaction
Time Events
Time events are denoted by the keywords when and after– keyword when specifies a
particular moment in time that the event triggered
– keyword after specifies a threshold time after the event triggered» e.g. after (3 months) and
when (date = 08/04/04)
when(balance<overdraftLimit)/notifyManager
Overdrawn
Frozen
[after (3 months)]
Time events
Methods and attributes
The state of an object will be determined by the values of the attributes of the class– in many cases, only a subset of the attributes will be relevant for
modelling the state– looking at the attributes should help identify possible states– an event causing a change of state leads to a change in the object’s
attribute values Events can be implemented as public methods
– the object is notified of an event by receiving a message from another object
Actions and activities should be implemented as private methods– it should not be possible for actions to be invoked without a valid
event occurring Entry, exit and internal actions should also be private
methods
Guidelines for Developing Statecharts
Guidelines for Developing Statecharts
A state name must reflect an identifiable situation or an interval of time when something is happening in the system.
Each state must have a unique name. It must be possible to exit from every state. On a flat (not hierarchical, composite) statechart, the system
is in one state at a time. An event is the cause of the state transition. An action is the
effect of the state transition. An event happens at a moment of time; an action happens
instantaneously; an activity executes throughout a state. Actions, activities and conditions are optional. Use only as
necessary.
Developing Statecharts from Use Cases
To develop a statechart from a use case, start with a typical scenario given by the use case.– This scenario should be the most typical path through the
use case, involving the most usual sequence of interactions between the actor(s) and the system.
Then consider the sequence of external events given in the scenario.– In each case, an input event from the external
environment causes a transition to a new state.– An action or an activity may associate with the transition.– Actions and activities are determined by considering the
response of the system to the input event, as given in the use case description.
Developing Statecharts from Use Cases
Initially, a flat statechart is developed following the event sequence given in the scenario.
To complete the statechart, determine all the possible external events that could be input to the statechart.– You do this by considering the description of alternative
paths given in the use case.
Example of Developing a Statechart from a Use Case
Actor: Driver Summary: This use case describes the automated cruise
control of the car, given the driver inputs via the cruise control lever, brake, and engine external input devices.
Precondition: Driver has switched on the engine and is operating the car manually.
Description:– 1. Driver releases the cruise control lever in order to cruise at a
constant speed. The system stops automatic acceleration and starts maintaining the speed of the car at the cruising speed. The cruising speed is stored for future reference.
– 2. Driver presses the brake to disable cruise control. The system disables cruise control so that the car is once more under manual operation.
– 3. Driver moves the cruise control lever to the ACCEL position and holds the lever in this position. The system initiates automated acceleration so that the car automatically accelerates.
Example of Developing a Statechart from a Use Case
Description (continued):– 4. Driver moves the cruise control lever to the RESUME
position in order to resume cruising. The system initiates acceleration (or deceleration) toward the previously stored cruising speed.
– 5. When the system detects that the cruising speed has been reached, it stops automatic acceleration (or deceleration) and starts maintaining the speed of the car at the cruising speed.
– 6. Driver moves the cruise control lever to the OFF position. The system disables cruise control, so the car is once more under manual operation.
– 7. The driver stops the car and switches off the engine.
Example of Developing a Statechart from a Use Case
Alternatives:– 1. The Accel, Cruise, Resume, and Off external events from the cruise
control lever. The Accel event causes automated acceleration, providing the brake is not pressed. The Cruise event may only follow an Accel event. The Resume event may only occur after cruising has been disabled and the desired cruising speed has been stored. The Off event always disables cruise control.
– 2. The Brake Pressed and Brake Released external events from the brake. The Brake Pressed event always disables cruise control. Automated vehicle control is not possible as long as the brake is pressed. After the brake is released, automated vehicle control may be enabled.
– 3. The Engine On and Engine Off external events from the engine. The Engine Off event disables any activity in the system.
Postcondition:– The car is stationary, with the engine switched off.
Cruise Control Statechart
Statechart Example – SSN Pin Validation
ATM Example
ATM Example – Single Session
Loan Approval Example
ISP Dial-UP Example
Modeling the Lifetime of an Object