Overview
Last week we learned how the design workflow is used to create a design model.
Specifically, we looked at modeling static system behavior via the design-level class
diagram.
This week we focus on how we model dynamic system behavior in the design workflow.
This is accomplished by implementing the sequence diagram, activity diagram, and state
diagram. This is also referred to as "realizing the behavioral aspects of a use-case" within
the design model. Each of these behavior modeling methods will be discussed in detail
and pointers for constructing these diagrams are outlined.
Outcomes
After completing this week, you should be able to:

Define the rules and style guidelines for sequence, activity and state diagrams.

Describe the processes used to create sequence, activity and state diagrams.

Be able to create sequence, activity, and state diagrams.

Be able to compare and contrast the behavioral models and the structural models
in UML.
4.1 Behavior Models
Behavior models describe the internal dynamic aspects of an information system that
supports the business processes in an organization. During the analysis workflow,
behavioral models describe what the internal logic of the processes is without specifying
how the processes are to be implemented. We did not define analysis-level behavior
models for the Regis Credit Union but we could have. Depending on the modeling
requirements of a project, you may or may not have these models defined. Last week, we
used structural models to depict the static view if the system. This week we will be using
behavior models in the design workflow to represent the internal behavior or dynamic
view of an information system.
There are two types of behavioral models. First, there are behavioral models that are used
to represent the underlying details of a business process portrayed by a use-case model.
1
In UML, interaction (sequence and communication) and activity diagrams are used for
this type of behavioral model. You were introduced to communication diagrams in Week
2. Second, there is a behavioral model that is used to represent changes that occur in the
underlying data. UML uses behavioral state machines for this. Our focus this week is on
what the dynamic view of the evolving system is and not on how the dynamic aspect of
the system will be implemented. Using behavioral models, it is possible to give a
complete view of the dynamic aspects of the evolving system.
One of the primary purposes of behavioral models is to show how the underlying objects
of the problem domain will collaborate to support each of the use cases. Whereas
structural models represent the objects and the relationships between them, behavioral
models depict the internal view of the business processes that a use case describes. The
process can be shown by the interaction that takes place between the objects that
collaborate to support a use case through the use of interaction diagrams. It is also
possible to show the effect that the set of use cases that make up the system has on the
objects in the system through the use of behavioral state machines.
Creating behavioral models is an iterative process that not only iterates over the
individual behavioral models but also over the use-case and structural models. As the
behavior models are created, it is not unusual to make changes to the use cases and class
diagrams.
4.2 The Sequence Diagram
One of the primary differences between the class diagram and the sequence diagram,
besides the obvious difference that one describes structure and the other behavior, is that
the modeling focus on the class diagram is at the class level, while the sequence diagram
focuses on the object level.
Let’s review for a moment. An object is defined as an instantiation of a class, that is, an
actual person, place, or event about which we want to capture information. Each object
has attributes that describe information about the object. Also, each object has behaviors
which we define as operations. An operation is nothing more than an action that an object
can perform. Each object can send and receive messages. Messages are information sent
to objects to tell an object to execute one of its defined behaviors. Essentially, a message
is a function or procedure call from one object to another object.
Sequence diagrams are one of two types of interaction diagrams. They illustrate the
objects that participate in a use case and the messages that pass between them over time
for one use case. A sequence diagram is a dynamic model that shows the explicit
sequence of messages that are passes between objects in a defined interaction. Since
sequence diagrams emphasize the time-based ordering of the activity that takes place
among a set of objects, they are very helpful for understanding real-time specifications
and complex use cases.
2
The sequence diagram can be a generic diagram that shows all possible scenarios for a
use case, but usually the analyst develops a set of instance sequence diagrams, each of
which depicts a single scenario within the use case. If you are interested in understanding
the flow of control of a scenario by time, you should use a sequence diagram to depict
this information. As mentioned previously, the diagrams are used throughout both the
analysis and design workflows. However, the design diagrams are very implementationspecific, often including database objects or specific GUI components as the classes. The
following section presents the elements of a sequence diagram.
4.2.1 Elements of a Sequence Diagram
The figure below shows an instance (or object) sequence diagram that depicts the objects
and messages for the Authenticate use case of the Regis Credit Union, which describes
the process by which a customer is authorized to access the Regis Credit Union.
3
Actors and objects that participate in the sequence are placed across the top of the
diagram using actor symbols from the use-case diagram, and objects from the class
diagram. Notice that the actor and objects in the figure are numerous – Customer,
Selection Panel, ATM, etc. They are usually placed in a particular order which is the
order in which they participate in the sequence at the top of the sequence diagram. Each
object is underlined to indicate that the box refers to an individual object and not to the
class of all similar objects. Sometimes a colon is placed before the underlined name but is
optional.
4
A dotted line runs vertically below each actor and object to denote the lifeline of the
actors/objects over time. Sometimes an object creates a temporary object, and in this case
an “X” is placed at the end of the lifeline at the point the object is destroyed (not shown).
For example, think about a shopping cart object for a Web commerce application. The
shopping cart is used for temporarily capturing line items for an order, but once the order
is confirmed, the shopping cart is no longer needed. In this case, an “X” would be located
at the point at which the shopping cart was destroyed. When objects continue to exist in
the system after they are used in the sequence diagram, then the lifeline continues to the
bottom of the diagram (see figure above).
A thin rectangular box, called the execution occurrence, is overlaid onto the lifeline to
show when the classes are sending and receiving messages. There are many different
types of messages that can be portrayed on a sequence diagram. However, in the case of
using sequence diagrams to model use cases, two types of messages are typically used:
Operation Call and Return. Operation call messages passed between classes are shown
using solid lines connecting two objects with an arrow on the line showing which way the
message is being passed. Argument values for the message are placed in parentheses next
to the message’s name. The order of messages goes from the top to the bottom of the
page, so messages located higher on the diagram represent messages that occur earlier on
in the sequence, versus the lower messages that occur later. A return message is depicted
as a dashed line with an arrow on the end of the line portraying the direction of the return.
The information being returned is used to label the arrow. However, since adding return
messages tends to clutter the diagram, unless the return messages add a lot of information
to the diagram, they can be omitted. In this course for the sake of learning, you will
define return messages on your sequence diagram.
At times a message is sent only if a condition is met. In those cases, the condition is
placed between a set of [ ] and the condition is placed in front of the message name.
However, when using a sequence diagram to model a specific scenario, conditions
typically are not shown on any single sequence diagram. Instead, conditions are implied
only through the existence of different sequence diagrams. Additionally, there are times
that a message is repeated. This is designated with an “*” in front of the message name
(not shown). Also, an object can send a message to itself. This is known as selfdelegation . Sometimes, an object will create another object. This is shown by the
message being sent directly to an object instead of its lifeline. In the preceding figure, the
Transaction Factory creates the Login object.
The following figure represents the standard UML 2.0 sequence diagram syntax:
5
An Actor:





Acts as a person or system
Derives benefit from and is external
to the subject
Participates in a sequence by
sending/receiving messages
Placed across the top of the diagram
Depicted as either a stick figure
(default), or, if involving a nonhuman entity, as a rectangle with
<<actor>> in it (alternative)
An Object:


Participates in a sequence by
sending/receiving messages
Placed across the top of the diagram
A Lifeline:


Represents the life of an object
during a sequence
Contains an “X” at the point at
which the class no longer interacts
An Execution Occurrence:


Placed on top of a lifeline
Shows when an object is sending or
receiving messages
A Message:


Conveys information from one
object to another
Labeled with the message sent as a
solid arrow, and the return as a
dashed arrow
6
Object Destruction:
X

Placed at the end of an object’s
lifeline to show the end of its
existence
A Frame:

Indicates the context of the
sequence diagram
4.2.2 Guidelines for Building Sequence Diagrams
This section describes a six-step process used to create a sequence diagram.
1. Determine the context of the sequence diagram. The context of a diagram can be a
system, a use case, a scenario of a use case, or an operation of a class. The context
of the diagram is depicted as a labeled frame around the diagram. Most
commonly, it is a single use-case scenario.
2. Identify the objects that participate in the sequence being modeled – that is, the
objects that interact with each other during the use-case scenario. The objects are
identified during the development of the structural model (class diagram). These
are the classes on which the objects of the sequence diagram for this scenario will
be based. However, during this process, it is likely that new classes, and hence
new objects, will be uncovered. Remember that behavioral modeling is iterative.
3. Set the lifeline for each object. To do this, you need to draw a vertical dotted line
below each class to represent the class’s existence during the sequence. An “X”
should be placed below the object at the point on the lifeline where the object
goes out of existence.
4. Add messages to the diagram. This is done by drawing arrows to represent the
messages being passed from object to object, with the arrow pointing in the
message’s transmission direction. The arrows should be placed in order from the
first message (at the top) to the last (at the bottom) to show time sequence. Any
parameters passed along with the messages should be placed in parentheses next
to the message’s name. If a message is expected to be returned as a response to a
message, then the return message either can be or not be shown on the diagram.
5. Place the execution occurrence of each object’s lifeline by drawing a narrow
rectangle box over the top of the lifelines to represent when the classes are
sending and receiving messages.
6. Finally, validate the sequence diagram. The purpose of this step is to guarantee
that the sequence diagram completely represents the underlying processes. This is
done by guaranteeing that the diagram depicts all the steps in the process. You
should refer back to the scenario’s use-case details and your static class diagram.
7
NOTE: All methods on the class diagram should be shown as messages on the sequence
diagram.
4.2.3 Beyond the Basics
Loops
Occasionally you will need to model a repetitive sequence. In UML 2, modeling a
repeating sequence has been improved with the addition of the loop combination
fragment. You draw a frame, and in the frame’s namebox the text “loop” is placed. Inside
the frame’s content area the loop’s guard is placed towards the top left corner, on top of a
lifeline. Then the loop’s sequence of messages is placed in the remainder of the frame’s
content area.
Branching or Alternatives
Alternatives are used to designate a mutually exclusive choice between two or more
message sequences. Alternatives allow the modeling of the classic “if then else” logic.
8
9
As you will notice in the figure above, an alternative combination fragment element is
drawn using a frame. The word “alt” is placed inside the frame’s namebox. The larger
rectangle is then divided into what UML 2 calls operands. Operands are separated by a
dashed line. Each operand is given a guard to test against, and this guard is placed
towards the top left section of the operand on top of a lifeline. If an operand’s guard
equates to “true,” then that operand is the operand to follow.
As an example to show how an alternative combination fragment is read, the above figure
shows the sequence starting at the top, with the bank object getting the check’s amount
and the account’s balance. At this point in the sequence the alternative combination
fragment takes over. Because of the guard “[balance >= amount],” if the account’s
balance is greater than or equal to the amount, then the sequence continues with the bank
object sending the addDebitTransaction and storePhotoOfCheck messages to the account
object. However, if the balance is not greater than or equal to the amount, then the
sequence proceeds with the bank object sending the addInsuffientFundFee and
noteReturnedCheck message to the account object and the returnCheck message to itself.
The second sequence is called when the balance is not greater than or equal to the amount
because of the “[else]” guard.
In alternative combination fragments, the “[else]” guard is not required; and if an operand
does not have an explicit guard on it, then the “[else]” guard is to be assumed.
Alternative combination fragments are not limited to simple “if then else” tests. There
can be as many alternative paths as are needed. If more alternatives are needed, all you
must do is add an operand to the rectangle with that sequence’s guard and messages.
Referencing another Sequence Diagram
When doing sequence diagrams, developers love to reuse existing sequence diagrams in
their diagram’s sequences. Starting in UML 2, the ”Interaction Occurrence” element was
introduced. The addition of interaction occurrences is arguably the most important
innovation in UML 2 interactions modeling. Interaction occurrences add the ability to
compose primitive sequence diagrams into complex sequence diagrams. With these you
can combine (reuse) the simpler sequences to produce more complex sequences. This
means that you can abstract out a complete, and possibly complex, sequence as a single
conceptual unit. See the figure below for an example of this.
10
An interaction occurrence element is drawn using a frame. The text “ref” is placed inside
the frame’s namebox, and the name of the sequence diagram being referenced is placed
inside the frame’s content area along with any parameters to the sequence diagram. The
notation of the referenced sequence diagram’s name follows the pattern:
sequence diagram name[(arguments)] [: return value]
Two examples:
1. Retrieve Borrower Credit Report(ssn) : borrowerCreditReport
or
2. Process Credit Card(name, number, expirationDate, amount : 100)
In example 1, the syntax calls the sequence diagram called Retrieve Borrower Credit
Report and passes it the parameter ssn. The Retreive Borrower Credit Report sequence
returns the variable borrowerCreditReport.
In example 2, the syntax calls the sequence diagram called Process Credit Card and
passes it the parameters of name, number, expiration date, and amount. However, in
example 2 the amount parameter will be a value of 100. And since example 2 does not
have a return value labeled, the sequence does not return a value (presumably, the
sequence being modeled does not need the return value).
The figure above shows a sequence diagram that references the sequence diagrams
“Balance Lookup” and “Debit Account.” The sequence starts at the top left, with the
customer sending a message to the teller object. The teller object sends a message to the
theirBank object. At that point, the Balance Lookup sequence diagram is called, with the
accountNumber passed as a parameter. The Balance Lookup sequence diagram returns
11
the balance variable. Then the option combination fragment’s guard condition is checked
to verify the balance is greater then the amount variable. In cases where the balance is
greater than the amount, the Debit Account sequence diagram is called,
passing it the accountNumber and the amount as parameters. After that sequence is
complete, the withdrawCash message returns cash to the customer.
It is important to notice in the above figure that the lifeline of theirBank is hidden by the
interaction occurrence Balance Lookup. Because the interaction occurrence hides the
lifeline, the theirBank lifeline is referenced in the “Balance Lookup” sequence diagram.
In addition to hiding the lifeline in the interaction occurrence, UML 2 also specifies that
the lifeline must have the same theirBank in its own “Balance Lookup” sequence.
There will be times when you model sequence diagrams that an interaction occurrence
will overlap lifelines that are not referenced in the interaction occurrence. In such cases
the lifeline is shown as a normal lifeline and is not hidden by the overlapping interaction
occurrence.
4.2.4 Building the Library Book Checkout Sequence Diagram
The following diagram represents the sequence diagram for the Free Library book
checkout scenario. Review this diagram and make sure you understand it.
12
Regis Credit Union
Withdraw Sequence
Client
Bank
CustomerMgr
AccountMgr
Customer
DBMgr
authenticate(int,int)
find(customerId)
loadCustomer(customerId,CustomerClass)
new
Customer
Customer
getPin
pin
true/false
withdraw(int,int,amt)
find(customerId,accountId)
load(accountId,AccountClass)
Account
new
Account
Account
withdraw(amt)
save(account)
save(account)
balance
balance
13
4.3 The Activity Diagram
Activity diagrams are sometimes called “object-oriented flowcharts”. They allow you to
model a process as a collection of activities and transitions between those activities.
Activity diagrams are really just special cases of state diagrams (see section 4.4) where
every state has an entry action that specifies some process or function that occurs when
the state is entered. Activity diagrams are used to document workflows in a system, from
the business level down to the operational level. The general purpose of activity diagrams
is to focus on flows driven by internal processing versus external events.
4.3.1 Elements of an Activity Diagram
Activity diagrams portray the primary activities and the relationships among the activities
in a process. The figure below shows the syntax of an activity diagram.
An Action:

Labeled by its name as a simple, non-decomposable piece of behavior
An Activity:

Labeled by its name and used to represent a set of actions
An Object Node:

Labeled by its class name and used to represent an object connected to a set of
Object Flows
14
A Control Flow:

Shows the sequence of execution
An Object Flow:

Shows the flow of an object from one activity (or action) to another
An Initial Node:

Shows the beginning of a set of actions or activities
A Final-Activity Node:

Used to stop all control flows and object flows in an activity (or action)
A Final-Flow Node:

Used to stop all specific control flow or object flow
A Decision Node:

Labeled with the decision criteria to continue down a specific path, and used to
represent a test condition to insure the control or objects flows go down one path
15
A Merge Node:

Used to bring back together different decision paths, created using a decisionnode
A Fork Node:

Used to split behavior into a set of parallel or concurrent flows of activities (or
actions)
A Join Node:

Used to bring back together a set of parallel or concurrent flows of activities (or
actions)
A Swimlane:

Labeled with the name of the individual or object responsible, and used to break
up an activity into rows and columns, assigning individual activities (or actions)
to the individuals or objects responsible for executing the activity (or action)
16
Actions and Activities: Actions and activities are performed for some specific business
reason. Actions and activities can represent manual or computerized behavior. They are
depicted in an activity diagram as a rounded rectangle. Furthermore, they should have a
name that begins with a verb and ends with a noun (e.g. “Enter Amount”). Names should
be short, yet contain enough information so that the reader can easily understand exactly
what they do. The only difference between an action and an activity is that an activity can
be decomposed further into a set of activities and/or actions, whereas an action represents
a simple non-decomposable piece of the overall behavior being modeled. Typically, only
activities are used for business process or workflow modeling. In addition, each activity
will be associated with a use case.
Object Nodes: Activities and actions typically modify or transform objects. Object nodes
model these objects on the activity diagram. Essentially, object nodes represent the flow
of information from one activity to another activity.
Control Flows and Object Flows: There are two different types of “flows” in activity
diagrams: control and object. Control flows model the paths of execution through a
business process. Control flows are portrayed as a solid line with an arrowhead on it
showing the direction of the flow. Control flows can only be attached to actions or
activities. Object flows model the flow of objects through a business process. Since
activities and actions modify or transform objects, object flows are necessary to show the
actual objects that flow into and out of the actions or activities. Object flows are depicted
as a dashed line with an arrowhead on it showing the direction of the flow. An individual
object must be attached to an action or activity on one end and an object node on the
other end.
Control Nodes: There are seven different types of control nodes in an activity diagram:
initial, final-activity, final-flow, decision, merge, fork, and join. An initial node portrays
the beginning of a set of actions or activities. A final-activity node is used to “stop the
process” being modeled. When a final-activity node is reached, all actions and activities
are ended immediately, regardless of whether they are completed. A final-flow node is
similar to a final-activity node, except that it stops a specific path of execution through
the business process, but allows the other concurrent or parallel paths to continue.
The decision and merge nodes support the decision structure of a business process. The
decision node is used to represent the actual test condition that is used to determine which
of the paths exiting the decision node is to be traversed. In this case, each of the exiting
paths must be labeled with a guard condition.The merge node is used to bring back
together multiple mutually exclusive paths that have been split based on an earlier
decision. The fork and join nodded allow parallel and concurrent processes to be
modeled. The fork node is used to split the behavior of the business process into multiple
parallel or concurrent flows. Unlike the decision node, the paths are not mutually
exclusive (i.e., both paths are executed concurrently). The join node simply brings back
together the separate parallel or concurrent flows in the business process into a single
flow.
17
Swimlanes: Sometimes it is useful to break up an activity diagram in a manner that is
useful in assigning responsibility to objects or individuals that would actually perform the
activity. Swimlanes are commonly used to represent:





use cases;
classes;
components;
organization units (business modeling);
roles (in workflow modeling).
You can also use swimlanes to model the distribution of processes across physical
machines. It is very common that separate departments or business units perform
concurrent lines of work and then have all of them come back together at some point. See
the figure below for an example of this type of activity diagram.
18
4.3.2 Guidelines for Building Activity Diagrams
This section describes a five-step process used to create an activity diagram.
1. Since the activity diagram can be used to model any kind of process, you should
first set the context or scope of the activity being modeled. Once you have
determined the scope, you should give the diagram an appropriate title.
2. You must identify the activities, control flows, and object flows that occur
between the activities.
3. You should identify any decisions that are part of the process being modeled.
4. You should attempt to identify any prospects for parallelism in the process.
5. You should draw the activity diagram.
Here are some other things to keep in mind when drawing your activity diagram:







Limit the diagram to a single node that starts the process to be modeled and one
final-activity node.
When modeling high-level business processes or workflows, you should only
include the most important decisions. Make sure that the guard conditions
associated with the outflows of decisions are mutually exclusive (i.e., all potential
values of a decision are associated with one of the flows).
When decision modeling, you should only include forks and joins to represent the
more important parallel activities in the process.
When laying out the activity diagram, you should attempt to minimize line
crossings to enhance readability.
You should lay out the activities on the diagram in a left to right and/or top to
bottom order based on the order that the activities are executed.
Swimlanes should only be used to simplify the understanding of the diagram and
you should not have more than five lanes.
Finally, you should challenge any activity that does not have any outflows or any
inflows. Activities with no outflows are referred to as black-hole activities. An
activity that does not have any inflow is known as a miracle activity.
4.3.3 Building the Withdraw Scenario Activity Diagram
The following link contains an activity diagram for the Regis Credit Union.
19
Activity Diagram
Withdraw Use Case Scenario
Swimlane
Customer
ATM Machine
Bank
Start
Activity
Insert Card
Enter PIN
Authorize
[valid PIN]
[Invalid PIN]
Enter Amount
Branch
Check Account Balance
[balance >= amount]]
[balance <
amount]
Fork
Debit Account
Join
Take Money from Slot
Show Balance
Merge
Eject Card
Take Card
The End!
In this activity diagram, the different activities and interactions for the ATM Withdraw
scenario are shown. The activity is “Withdraw money from a back account through an
ATM”. The three classes involved in the activity are Customer, ATM machine, and
20
Bank. The process begins at the black start circle at the top and ends at the concentric
white/black stop circle at the bottom. The activities are rounded rectangles. Activity
diagrams can be divided into object swimlanes that determine which object is responsible
for which activity. A single transition comes out of each activity, connecting it to the next
activity. A transition may branch into two or more mutually exclusive transitions. Guard
expressions (inside []) label the transitions coming out of a branch. A branch and its
subsequent merge marking the end of the branch appear in the diagram as hollow
diamonds. A transition may fork into two or more parallel activities. The fork and
subsequent join of the threads coming out of the fork appear in the diagram as solid bars.
4.4 The Statechart Diagram
The activity diagram from the previous section is a special case of a statechart diagram.
In this case, the states are action and the transitions are triggered automatically by the
completion of a state’s action and activities.
Statechart diagrams also model the dynamic behavior aspects of a system. Statechart
diagrams tend to be used for modeling the lifecycle history of a single object in the
system. Some objects are incredibly complicated, so complex that developers can have
difficulty understanding them. To understand complex classes better, particularly those
that act in different manners depending on their state, you should develop one or more
statechart diagrams. In business applications it seems that a very small proportion of
classes, perhaps 5% at most, are complex enough to warrant the creation of a statechart
diagram.
A statechart contains exactly one state machine. A state machine depicts the various
states that an object may be in and the transitions between those states.
4.4.1 States, Events, Transitions, Actions, and Activities
The state of an object is defined by the value of its attributes and its relationships with
other objects at a particular point in time. The attributes of an object affect the state it is
in. However, not all attribute changes will make a difference. For example, think about a
bank customer’s address. Those attributes make very little difference as to changes in the
bank account’s state. However, if the states were based on a customer’s address (i.e., intown customers were treated differently than out-of-town customers), changes to the
customer’s address would influence state changes. The key to successful statechart
modeling is to identify the states that make a difference to your system.
An event is something that takes place at a certain point in time and changes a value(s)
that describes an object, which, in turn, changes the object’s state. It can be a designated
condition becoming true, the receipt of the call for a method by an object, or the passage
of a designated time period. The state of the object determines exactly what the response
will be.
21
A transition is a relationship that represents the movement of an object from one state to
another state. Some transitions will have a guard condition. An object typically moves
from one state to another based on the outcome of an action that is triggered by an event.
An action is an atomic, non-decomposable process that cannot be interrupted. From a
practical perspective, actions take zero time, and they are associated with a transition. In
contrast, an activity is a decomposable process that can be interrupted. Activities take a
long period of time to complete, they can be started or stopped by an action, and they are
associated with states.
22
4.4.2 Elements of a Statechart Diagram
A State:

Depicted as a rectangle with round
corners, with a name representing
the state of the object
An Initial State:

Depicted as a small, filled-in circle,
and representing the point at which
an object begins to exist
An Final State:

Depicted as a circle surrounding a
small, solid, filed-in circle (bull’s
eye), and representing the
completion of an activity
An Event:


Designates a condition becoming
true, the receipt of an explicit signal
from one object to another, or the
passage of a specific period of time
Used to label a transition, or
noteworthy occurrence that triggers
a change of state
anEvent
A Transition:


Depicted as a solid arrow from one
state to another, labeled by the
event name
Shows an object in the first state
will enter the second, and triggered
by the occurrence of the event
23
labeling the transition
A Frame:

Indicates the context of the
behavioral state machine
Object state is determined by:



object attribute values
relationships to other objects
activities the object is performing
State syntax:




entry action – performed immediately on entry to the state
exit action – performed immediately on exit from the state
internal transitions – these are caused by events that are not significant enough to
warrant a transition to a new state; the event is processed by an internal transition
within the state
internal activity – a piece of work that takes a finite amount of time and which
may be interrupted
Transition – a movement between two states
24



event – the event that triggers the transition
guard condition – a Boolean expression that must be true before the transition
occurs
action – an action that occurs instantaneously with the transition
Event – something of note that occurs to a reactive object that triggers a state transition.
The types of event are as follows:
Call event – a call for a set of actions to occur or a request for a specific method to be
invoked on an instance of a class. It should have the same signature as a method of the
class that provides the context for the statechart. The example shows a fragment of a
statechart of the Account class with its corresponding methods “deposit” and “withdraw”.
Signal event – a package of information that is sent asynchronously between objects.
You model a signal as a stereotyped class that contains all the communicated information
in its attributes. The example above shows the sending of a “OverdrawnAccount” signal
to another object in the bank system.
25
Change event – occurs when some Boolean condition changes from False to True.
The action associated with the event is performed when the Boolean expression is true.
The example above represents a change to an “Overdrawn” state when the balance goes
below zero.
26
Time event – occurs after a time period. The keyword when specifies a particular
moment in time that the event is triggered. In this example, you can see that after an
Account object has been in the state “Overdrawn” for three months, it transitions to the
state “Frozen”.
4.4.3 Building a Statechart Diagram
Statechart diagrams are drawn to depict a single class from a class diagram. Typically,
the classes are very dynamic and complex, requiring a good understanding of their states
over time and events triggering changes. You should examine your class diagram to
identify which classes will need to undergo a complex series of state changes and draw a
diagram for each of them.
Here are the steps in drawing a statechart diagram:
1. Determine the context of the statechart diagram – which class?
2. Identify the various states that an object will have over its lifetime. This includes
establishing the initial and final states of the object. You must also identify the
stable states of the object. The information necessary to perform this is gleaned
from reading the use-case detail descriptions, talking with users, and relying on
the requirements gathering techniques you have learned. An easy way to identify
the states of an object is to write the steps of what happens to an object over time,
from start to finish, similar to how you would create the flow of events for a use
case. You can also find states by looking at the boundary values of your attributes.
For example, a bank account will transition to the “overdrawn” state when the
cash balance < zero.
3. Determine the sequence of the states the object will pass through during its
lifetime. Using this sequence, the states are placed onto the statechart diagram in a
left-to-right order.
4. Identify the events, actions, and guard conditions associated with the transitions
between the states of the object. The events are the triggers that cause an object to
move from one state to the next state. In other words, an event causes an action to
execute that changes the value of an object’s attribute(s) in a significant manner.
You can ask yourself how the object can get out of it’s current state. The actions
are typically operations contained within the class. Also, guard conditions can
model a set of test conditions that must be met for the transition to occur.
5. Validate the statechart diagram. Make sure that each state is reachable and that it
is possible to leave all states except for final states. If an identified state is
unreachable, either a transition is missing or the state was identified in error.
Furthermore, only final states can be a dead end from the perspective of the
object-life cycle.
27
4.4.4 Building the Regis Credit Union ATM Authentication
Session Statechart Diagram
The following figure shows a simple statechart diagram for the Regis Credit Union. In
this statechart diagram, the different states of an authentication scenario are shown. At a
high level, the ATM goes back and forth between two states – RUNNING and
STPOPPED. More interesting, though, is the series of states an individual session goes
through as it gets the customer’s PIN and repeatedly gets transactions choices and
performs them. You could also construct similar diagrams for the different transactions.
The Initial State is represented by the solid black circle and represents the beginning of
the statechart. As the customer’s card is read by the card reader in the ATM, the session
state transitions to “Asking for PIN”. Once the customer enters his/her/ PIN, the session
state transitions to “Asking for transaction choice”. The customer chooses the type of
transaction and the state transitions to “Performing transaction”. If the transaction was
successful, the state transitions to “Transaction successful”. If not, the state transitions to
an error state called “Reporting failure”. The customer is asked if he/she wants another
transaction and the state transitions to the prior “Asking for transaction choice” state or
the session terminates and the state becomes “Session over”.
28