Specifying Control

Based on Chapter 11 of Bennett, McRobb

and Farmer:
Object Oriented Systems Analysis and
Design Using UML, (2nd Edition), McGraw
Hill, 2002.
03/12/2001 © Bennett, McRobb and Farmer 2002 1
 In This Lecture You Will
Learn:
 How to identify requirements for control
in an application
 How to model object life cycles using
statecharts
 How to develop statechart diagrams
from interaction diagrams
 How to model concurrent behaviour in
an object
 How to ensure consistency with other
UML models
© Bennett, McRobb and Farmer 2002 2
 State
 The current state of an object is
determined by the current value of
the object’s attributes and the links
that it has with other objects
 For example the class StaffMember
has an attribute startDate which
determines whether a StaffMember
object is in the probationary state
© Bennett, McRobb and Farmer 2002 3
 State
 ‘A state is a condition during the life of
an object or an interaction during which
it satisfies some condition, performs
some action or waits for some event....
Conceptually, an object remains in a
state for an interval of time. However,
the semantics allow for modelling "flow-
through" states which are instantaneous
as well as transitions that are not
instantaneous.’
(OMG, 2001)
© Bennett, McRobb and Farmer 2002 4
 Statechart
 The current state of a GradeRate
object can be determined by the
two attributes rateStartDate and
rateFinishDate
 An enumerated state variable may
be used to hold the object state,
possible values would be Pending,
Active or Lapsed
© Bennett, McRobb and Farmer 2002 5
 GradeRate()
Pending

when [rateStartDate <=

Statechart
currentDate]
Initial state Statechart for
Change the class
event GradeRate.
Active

when [rateFinishDate <=

Transition
currentDate]
Movement
between from one
states
state to
Lapsed another is
dependen
after [1 year]
t upon
Elapsed-time events
event that occur
Final state
with the
passage
of time.
© Bennett, McRobb and Farmer 2002 6
 Types of Event
 A change event occurs when a condition
becomes true
 A call event occurs when an object receives a
call to one of its operations either from
another object or from itself
 A signal event occurs when an object receives
a signal (an asynchronous communication)
 An elapsed-time event is caused by the
passage of a designated period of time after a
specified event (frequently the entry to the
current state)

© Bennett, McRobb and Farmer 2002 7

 Events

This event must correspond to an

operation in the Campaign class
Commissioned

authorized(authorizationCode) [contract Signed]

/setCampaignActive( )

Active

© Bennett, McRobb and Farmer 2002 8

Actions and Activities
Internal actions and
activities for a state
Internal
transition Name
compartmen compartment
t
State Name

entry / action
A state may
expression
include a sub-
exit/ action expression
statechart
do / activity
include / submachine

© Bennett, McRobb and Farmer 2002 9

 Menu Visible State
Menu Visible state for a Event itemSelected()
DropDownMenu object triggers the action
highlightItem()
Entry action
causes the menu
to be displayed Menu Visible

itemSelected() / highlightItem()
entry / displayMenu
exit / hideMenu
do / playSoundClip
Exiting the state
triggers
While the object remains hideMenu()
in the Menu Visible
state, the activity causes a
sound clip to be played
© Bennett, McRobb and Farmer 2002 10
 /assignManager();
Action-expression
assignStaff()
assigning manager Commissioned
and staff on object
creation authorized(authorizationCode)
[contract signed]
/setCampaignActive() Recursive transition
Statechart models any payment
for the class Active event that does not
reduce the amount due
Campaign campaignCompleted() to zero or beyond
/prepareFinalStatement()
Guard condition
ensuring complete
payment before Completed
entering Paid
paymentReceived(payment)
paymentReceived(payment)
[paymentDue – payment <= zero]
[paymentDue - payment > zero]

Paid
archiveCampaign()
/unassignStaff();
unassignManager()
© Bennett, McRobb and Farmer 2002 11
 /assignManager();
assignStaff()
Commissioned

authorized(authorizationCode)
[contract signed]
/setCampaignActive()
A revised
statechart for Active
the class campaignCompleted()
Campaign /prepareFinalStatement()
paymentReceived(payment)
[paymentDue - payment < zero]
If the user
/generateRefund()
requirements were Completed
to change, so that
paymentReceived(payment)
an overpayment is [paymentDue - payment = zero] paymentReceived(payment)
now to result in the [paymentDue – payment > zero]
automatic
generation of a
Paid
refund, a new
archiveCampaign()
transition is added /unassignStaff();
unassignManager()
© Bennett, McRobb and Farmer 2002 12
 Nested Substates
The transition from the initial pseudostate
The Active state of symbol should not be labelled with an
Campaign showing nested event but may be labelled with an action,
though it is not required in this example
substates
Active

extendCampaign() advertsApproved()
/modify Budget() /authorize()
Advert Preparation

Running Adverts Scheduling

confirmSchedule()

campaignCompleted()
/prepareFinalStatement()

© Bennett, McRobb and Farmer 2002 13

 Nested States The submachine
Running is
The Active state of referenced using the
include statement
Campaign with the
detail hidden
Active

include / Running

Hidden
decomposition
indicator icon

© Bennett, McRobb and Farmer 2002 14

The Active State with
Concurrent Substates
Active

Running
extendCampaign() advertsApproved()
/modify Budget() Advert Preparation /authorize()

confirmSchedule()
Running Adverts Scheduling

campaignCompleted()
/prepareFinalStatement()

Monitoring
surveyComplete()
Survey

Evaluation
runSurvey()

© Bennett, McRobb and Farmer 2002 15

 Concurrent States
 A transition to a complex state is equivalent
to a simultaneous transition to the initial
states of each concurrent statechart
 An initial state must be specified in both
nested statecharts in order to avoid
ambiguity about which substate should first
be entered in each concurrent region
 A transition to the Active state means that
the Campaign object simultaneously enters
the Advert Preparation and Survey states

© Bennett, McRobb and Farmer 2002 16

 Concurrent States
 Once the composite states is
entered a transition may occur
within either concurrent region
without having any effect on the
state in the other concurrent region
 A transition out of the Active state
applies to all its substates (no
matter how deeply nested)
© Bennett, McRobb and Farmer 2002 17
 Synchronized Concurrent
Threads.
Synchronization bar

 Explicitly showing how an event triggering a

transition to a state with nested concurrent states
causes specific concurrent substates to be entered
 Shows that the composite state is not exited until
both concurrent nested statecharts are exited
© Bennett, McRobb and Farmer 2002 18
 Preparing Statecharts
 Two approaches may be used:
– Behavioural approach
– Life cycle approach

Allen and Frost (1998)

© Bennett, McRobb and Farmer 2002 19

 Behavioural Approach
1. Examine all interaction diagrams that involve
each class that has heavy messaging.
2. Identify the incoming messages on each
interaction diagram that may correspond to
events. Also identify the possible resulting
states.
3. Document these events and states on a
statechart.
4. Elaborate the statechart as necessary to
cater for additional interactions as these
become evident, and add any exceptions.

© Bennett, McRobb and Farmer 2002 20

 Behavioural Approach
5. Develop any nested statecharts (unless this
has already been done in an earlier step).
6. Review the statechart to ensure consistency
with use cases. In particular, check that any
constraints that are implied by the
statechart are appropriate.
7. Iterate steps 4, 5 and 6 until the statechart
captures the necessary level of detail.
8. Check the consistency of the statechart with
the class diagram, with interaction diagrams
and with any other statecharts and models.

© Bennett, McRobb and Farmer 2002 21

 Sequence Diagram with
Implicit States
Campaign Sequence diagram for use case
Manager Set Campaign Completed
:CompleteCampaign :Client :Campaign

:CompleteCampaignUI *getClient()
startInterface()

selectClient()
showClientCampaigns()
listCampaigns() Active state
*getCampaignDetails()

completeCampaign()
completeCampaign()
campaignCompleted()

Completed state

© Bennett, McRobb and Farmer 2002 22

 /assignManager();
assignStaff()
Commissioned

authorized(authorizationCode)
[contract signed]
/setCampaignActive()
Initial extendCampaign() advertsApproved()
/modify Budget()
statechart Advert Preparation /authorize()

for the Running Adverts

confirmSchedule()
Scheduling

Campaign campaignCompleted()
/prepareFinalStatement()
class—a paymentReceived(payment)
behavioural [paymentDue - payment < zero]
/generateRefund() Completed
approach paymentReceived(payment)
[paymentDue - payment = zero] paymentReceived(payment)
[paymentDue – payment > zero]

Paid
archiveCampaign()
/unassignStaff();
unassignManager()
© Bennett, McRobb and Farmer 2002 23
 /assignManager();
assignStaff()
Commissioned

authorized(authorizationCode)
[contract signed]
/setCampaignActive()

Active

Revised extendCampaign()
/modify Budget()
advertsApproved()
/authorize()
Advert Preparation
statechart
for the Running Adverts
confirmSchedule()
Scheduling

Campaign campaignCompleted()
/prepareFinalStatement()
class
paymentReceived(payment)
[paymentDue - payment < zero]
/generateRefund() Completed

paymentReceived(payment)
[paymentDue - payment = zero] paymentReceived(payment)
[paymentDue – payment > zero]

Paid
archiveCampaign()
© Bennett, McRobb and Farmer 2002 24
/unassignStaff();
unassignManager()
 /assignManager();
assignStaff()
Commissioned

authorized(authorizationCode)
[contract signed]
/setCampaignActive()
Active

Monitoring
surveyComplete()
Final Survey

version of runSurvey()
Evaluation

Campaign Running
extendCampaign() advertsApproved()
campaignCancelled()
statechar /calculateCosts();
prepareFinalStatement()
/modify Budget()
Advert Preparation /authorize()

t Running Adverts
confirmSchedule()
Scheduling

campaignCancelled()
/cancelSchedule() campaignCompleted()
calculateCosts(); /prepareFinalStatement()
prepareFinalStatement()
Completed
paymentReceived(payment)
paymentReceived(payment)
[paymentDue - payment < zero] paymentReceived(payment)
[paymentDue - payment = zero]
/generateRefund() [paymentDue – payment > zero]

archiveCampaign()
© Bennett, McRobb and Farmer 2002 Paid 25
/unassignStaff();
unassignManager()
 Life Cycle Approach
 Consider the life cycles for objects of
each class
 Events and states are identified directly
from use cases and from any other
requirements documentation that
happens to be available
 First, the main system events are listed
 Each event is then examined in order to
determine which objects are likely to
have a state dependent response to it
© Bennett, McRobb and Farmer 2002 26
Life Cycle Approach Steps
1. Identify major system events.
2. Identify each class that is likely to have a
state dependent response to these events.
3. For each of these classes produce a first-cut
statechart by considering the typical life
cycle of an instance of the class.
4. Examine the statechart and elaborate to
encompass more detailed event behaviour.

© Bennett, McRobb and Farmer 2002 27

Life Cycle Approach Steps
5. Enhance the statechart to include
alternative scenarios.
6. Review the statechart to ensure that is
consistent with the use cases. In particular,
check that the constraints that the
statechart implies are appropriate.
7. Iterate through steps 4, 5 and 6 until the
statechart captures the necessary level of
detail.
8. Ensure consistency with class diagram and
interaction diagrams and other statecharts.

© Bennett, McRobb and Farmer 2002 28

 Life Cycle Approach
 Less formal than the behavioural
approach in its initial identification
of events and relevant classes
 Often helpful to use a combination
of the two, since each provides
checks on the other

© Bennett, McRobb and Farmer 2002 29

 Consistency Checking
 Every event should appear as an incoming message
for the appropriate object on an interaction diagram
 Every action should correspond to the execution of
an operation on the appropriate class, and perhaps
also to the despatch of a message to another object
 Every event should correspond to an operation on
the appropriate class (but note that not all
operations correspond to events)
 Every outgoing message sent from a statechart
must correspond to an operation on another class

© Bennett, McRobb and Farmer 2002 30

 Consistency Checking
 Consistency checking is an
important task in the preparation
of a complete set of models
 Highlights omissions and errors,
and encourages the clarification of
any ambiguity or incompleteness
in the requirements

© Bennett, McRobb and Farmer 2002 31

 Summary
In this lecture you have learned about:
 How to identify requirements for control in an
application
 How to model object life cycles using
statecharts
 How to develop statechart diagrams from
interaction diagrams
 How to model concurrent behaviour in an object
 How to ensure consistency with other UML
models

© Bennett, McRobb and Farmer 2002 32

 References
 UML Reference Manual (OMG,
2001)
 Allen and Frost (1998)
(For full bibliographic details, see
Bennett, McRobb and Farmer)

© Bennett, McRobb and Farmer 2002 33