Transcript CSIS3600 System Analysis and Design

CSIS3600 System Analysis and
Design
Statechart Diagrams
Statecharts or
State Transition Diagram
• A Statechart Diagram (SCD) depicts a finite-statemachine that describes how the class responds to
different external stimuli (events). These stimuli
are the receipt of messages by instances of the
class, in the form of calls of the class’s operations.
• Given this statement, does it surprise you that
statecharts are the most complex elements of
object-oriented development?
Statechart Diagrams
• The statechart diagram shows the different
states of the object and what events cause the
object to change from one state to another.
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
Example Statechart Diagram
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
Purpose of the Statechart Diagrams
• To put it simply, the purpose of a statechart
diagram is to describe the internal workings of the
objects.
• Each class in the class diagram has its own unique
statechart diagram.
Use Case Diagram
Class Diagram
Shipment
Enter new customer
Order
Order Clerk
Enter new customer
Customer
Sequence Diagram
Order Clerk
Create
order
order
customer
Verify customer
Items being
entered
Ready to Ship
When to use Statecharts
• When you have a complex object
– and are not sure how it is going to function.
• When you REALLY need to know the states of an
object
– because it is vital to the success of the application you
are working on.
– Statecharts are brilliant for modeling the behavior of
user interface objects so that you can easily code from
them.
Understandings of State
• Each object is an instance of a class and has a complete life
cycle, from creation to destruction.
• An object comes into existence within the system. During
the period of its existence, it is “in” certain states and
makes transitions from state to state.
Object States
• A stable state represents a condition in which an object
may exist for some identifiable period of time.
• When an event occurs, the object may transition from state
to state.
• These events may also trigger self- and internal transitions,
in which the source and the target of the transition are the
same state.
• In reaction to an event or a state change, the object may
respond by dispatching an action.
• States of an object depend on its attributes’ values and
links to other objects.
Some Notes
• Events are noteworthy occurrences that trigger a state
transition.
• An Action is an activity that the object performs while in a
state.
Example
Computer monitor is in the ON state with the action of display.
• During the development of the Statechart, more detailed
analysis is done to determine the logic required to send the
messages and what happens when an object receives a
message.
More Notes
• States are represented as attributes on the class
diagram
• But note that a state of an object does not
necessarily change whenever an attribute changes
its value.
– Example: Fluctuations in a customer’s bank account
balance may not trigger an event. (However, if the
amount falls below a certain threshold, an event may
occur [bounced check].)
Identifying States
• Identify “states of being.”
• Think about status conditions (shipped, on hold,
etc.)
CreateItem
(ItemID, Qty)
Exists
ReadyToShip()
Waiting to
be shipped
ShipItem
(ItemID, QTY)
Shipped
Object Transitions
• A transition is the mechanism that causes an object to leave
a state and change to a new state.
• Transitions are short in duration and cannot be interrupted.
Once the transition begins, it runs to completion by taking
the object to the new state.
Origin State ---------------- TRANSITION -----------Destination State
Internal Transitions
• Normally, a transition causes an object to leave a state and
move to a new state or return to the same state.
• An internal transition is a special kind of transition that
does not cause the object to leave the state.
Paid
entry/calculate balance
do/display balance
exit/pay balance
Internal Transitions
Three versions of an internal transition are:
• Entry/action expression
– The entry/ internal transition is activated at the moment the object
enters the state.
• do/action expression
– The do/ executes while the object is within the state.
• exit/action expression
– The exit/ is activated just before the object
leaves the state.
Paid
entry/calculate balance
do/display balance
exit/pay balance
Modeling States
 A statechart diagram has one initial state and one
(or possibly more) final states.
• When modeling the behavior of a reactive object
with statecharts you are essentially specifying:
1. The stable state in which that object may live.
2. The events that trigger a transition from state to state.
3. The actions that occur on each state change.
 You can also model the creation and destruction of
the object.
Statechart Diagram Syntax
aState
A STATE
AN INITIAL STATE
A FINAL STATE
AN EVENT
anEvent
A TRANSITION
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
Components of Statechart
Diagrams
•
•
•
•
•
States
Events
Transitions
Actions
Activities
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
Statechart Diagrams
 States and the changes an object makes from state
to state are shown in a state chart diagram.
Statechart Symbols
State
A state is graphically
symbolized as a rounded
box as shown above. This
illustrates 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.
State Names
• States are named. The
name should depict the
state – often verb
phrases (if the name for
your state is a noun then
you probably have an
incorrect idea about the
state).
• State names are placed
inside the rounded box.
State Actions
• Actions that must be
performed during the period
the state is active are placed
beneath the state name.
• The details of a state’s actions
are shown as a set of lines of
the form: condition/operation
in which the conditions entry,
exit, and do are, by
convention, used to represent
processing an entry to a state,
processing whilst in a state,
and processing on exit from a
state.
Paid
entry/calculate balance
do/display balance
exit/pay balance
Initial State
• An initial state is
symbolized by a solid
circle and line connected
to a directional arrowhead
• This illustrates a condition
at the beginning of the life
of an object or an
interaction during which it
satisfies some condition,
performs some action, or
waits for some event.
Transition
• A transition is graphically
symbolized as a line with a
standard directional arrowhead.
• This illustrates a relationship
between two states, indicating
that an object in the first state
will enter the second state and
perform certain specified
actions when a specified event
occurs, if specified conditions
are satisfied.
• Transitions are named. The
name is the message event that
triggers the transition.
Transition Labels
• The full transition label consists of:
Transition-name (parameters,…) [guard condition] /action-expression
– Parameter list identifies parameters that the message is to pass to the object
– Guard-condition is a true/false test to see whether a transition can be taken.
(There are some transitions that only have a guard-condition and no event
trigger. In these cases, the event is constantly firing and whenever the
guard becomes true, the transition fires.)
– Action-expression is a procedural expression that executes when the
transition fires. It is the activity that occurs during the transition.
• Any of the three components may be empty.
• It is common practice to use the same name and parameter list for a
message and a transition.
Transition Label Examples
• Transition name only:
DeleteOrder()
• No guard condition:
Order item (ItemID,qty)/resest register
• Guard condition only:
[Credit no good]
• Multiple actions:
CreateOrder(Order Information) /Build order
information;Associate with Customer
• All components:
• PullNextItem(ItemID)[Item not Available]/ Mark
line ‘Backorder’
Internal Transition Labels
• For an internal transition, the appropriate
transitions are noted within the transition box
using the format:
Paid
– entry/action expression
– do/action expression
– exit/action expression
Checked
entry/calculate order total
do/display order total
entry/calculate balance
do/display balance
exit/pay balance
Verify Payment
do/Calculate total;
Verify credit
Using multiple
action expressions
Dot Notation
• The dot notation is used for messages sent by an
object. Using dot notation, the object or class to
which the message will be directed is placed first,
then a dot, then the name of the message:
ControlPanel.UpdateStatus(status)
• ControlPanel is the object to which the message
UpdateStatus with a parameter of status is sent.
Final State
• An final state is
symbolized by a solid
circle inside an empty
circle and is placed at
the end of a directional
arrowhead
• This illustrates a
condition at the end of
the life of an object or
an interaction during
which it satisfies some
condition, performs
some action, or waits for
some event.
Surrounding Rectangle - Superstate
• Rectangles are
used as borders to
identify groups of
associated states.
They make up a
superstate.
• Generally any
state outside a
rectangle can be
triggered at any
time from within
the superstate.
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
Nesting of States
• Statechart diagrams can be expanded to show
more detail – this is referenced as superstates and
substates.
• A superstate may have superstates nested within it,
each of which may in turn contain states and
transitions, and possibly other superstates. As
such, it is possible to create a hierarchy of states
within a statechart diagram by nesting states inside
superstates, and then nesting superstates inside
other superstates.
Nested in Statecharts
• At each level of state
nesting, there may be any
number of superstates.
For example, a statechart
diagram may contain
some states and two
superstates, each with
states nested inside it.
• A transition may be to a
superstate, in which case
the flow of control begins
at the initial state symbol
nested within the
superstate.
State Diagram for Student Object
Nested State Diagram for Matriculated State of Student Object
Nested State Diagram for the Accepts Admission Offer Event
Concurrent States
• A superstate may contain more than one set of
nested states and transitions, each set separated
from all other sets, and each set having its own
initial state and final state(s) symbols. These sets
are considered to run concurrently.
• Concurrent state is the condition of being in more
than one state at a time. These are represented as
two separate paths. These paths are independent.
Modeling Rules
• Remember the rules on modeling. Show only
what needs to be shown.
 Not all attributes are important in determining the
state of an object . Only those attributes which
effect its gross behavior are considered important.
 Student Class – student’s phone number may not be
important in state of the object.
 i.e., a change to a student’s phone number may not
impact the state of the object.
Steps to Get Started
Customer
Step 1:
Account No.
Name
BillingAddress
ShippingAddress
Day Phone
NightPhone
Order
1
OrderID
OrderDate
Priority Code
0..*
Shipping_Handling
Tax
GrandTotal
ProductID
Vendor
Description
Season
NormalPrice
SpecialPrice
1
1..*
Inventory Item
0..*
1
Review the class diagram
and select the classes that
will require statecharts. (Start
with the assumption all
classes need statecharts).
Begin with the classes that
appear to have the simplest
statecharts.
Product Item
Order Item
Quantity .
Price
BackorderStatus
0..*
Inv entory ID.
Size
Color
Options
Quantity onHand
1
Av erageCoste
ReorderQuantity
Step 2
Identify all the input messages across all sequence
diagrams from the selected cases. The use cases and
scenarios and sequence diagrams provide the basis for
identifying messages into and out of a class. One good
assumption is that each message will be the trigger for a
transition. Then you may add other transitions later on but
this gives you a good starting point.
Step 3
For each selected class in the group, make a list of all the states you can
identify. Begin by brainstromming. One effective way to start is to note
that each transition identified in Step 2 requires at least one origin state
and one destination state.
Remember a state is a semipermanent condition or state of being of an
object. Sometimes it is helpful to think of the physical object and translate
those that are appropriate into corresponding system states.
It is also helpful to think of the life of the object.
–
–
–
–
–
How does it come into existence?
When and how is it deleted?
Does it have active states?
Does it have inactive states?
Does it have states where it is waiting?
Think of activities done to the object or by the object. Begin associating
activities with states.
Step 4
Build statechart fragments
and sequence the fragments
in the correct order. From
steps 2 and 3, you should
have a fairly complete set of
transitions and states. Build
these individual states and
transitions into statechart
fragments. Build the life
cycle path from these
fragments and fill in missing
pieces.
Step 5
Review the paths and look
for independent, concurrent
paths. Take different pairings
of states and ask the question
“Can the object be in both of
these states at the same time?
Or does one state naturally
follow another state? These
are dependent states and
cannot be on current paths.
Concurrent vs Composite
• When an item can be in two states concurrently, there are
two possibilities – either the two states are on independent
paths, or one state in reality should be a composite state
and the two states should be nested, one inside the other.
• One way to identify a candidate as a composite state is if it
is concurrent with several other states. For example – a
customer will be active and have outstanding orders. But
what about the customer whose order has been shipped and
they have no outstanding orders? If this customer is also
considered active, then the active state is concurrent with
multiple other state and is a composite state.
Step 6
Expand upon each transition with
the appropriate message event,
guard-condition, and actionexpression. Include with each state
appropriate internal transitions and
action-expressions. (Much of this
may have been done as the
statechart fragments were being
built.) Ensure that every output
message identified is somewhere
within an action-expression for a
state or transition.
Step 7
Review and test each statechart by doing each of the
following:
– a. Make sure your states are really states of the object in the class.
– b. Follow the life cycle and be sure all combinations are covered
and the paths are accurate.
– c. Be sure your diagram covers all exceptions as well as the normal
course of action.
– d. For each transition, ask is it really permissible for the object to
go from state A to state B?
– e. Review messages and make sure they are handled somewhere in
the statechart.
– f. Review all possible actions and activities and make sure they are
included correctly in the statechart.
Once again the operative word is
iterative.
• As with the other forms of OOA modeling,
statechart modeling is iterative.
• The statechart diagram will initially show only
terse details for states, but as iterative
development progresses, the contents of statechart
diagrams and their states will become increasingly
detailed.