HCSE211: Object Oriented Analysis and Design

Behavioral State Machines

1
 Introduction
• A behavioral state machine is a dynamic model that shows the different states
through which a single object passes during its life in response to events, along with
its responses and actions.
• Typically, behavioral state machines are not used for all objects; rather, behavioral
state machines are used with complex objects to further define them and to help
simplify the design of algorithms for their methods.
• The behavioral state machine shows the different states of the object and what events
cause the object to change from one state to another.
• They should be used to help understand the dynamic aspects of a single class and
how its instances evolve over time unlike interaction diagrams that show how a
particular use case or use-case scenario is executed over a set of classes.
2
 Introduction
• When we create a behavioral state machine for an object, it is possible that we will
uncover:
• additional events that need to be included in the functional model, and
• additional operations that need to be included in the structural model, so
• our interaction diagrams might have to be modified again.
• Because object-oriented development is iterative and incremental, this continuous
modification of the evolving models (functional, structural, and behavioral) of the
system is to be expected.

3
 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.
• E.g., a patient might have a state of new, current, or former.
• The attributes or properties of an object affect the state that it is in;
• however, not all attributes or attribute changes will make a difference.
• E.g., think about a patient’s address.
• Those attributes make very little difference to changes in a patient’s state.
• However, if states were based on a patient’s geographic location (e.g., in-town patients
were treated differently than out-of-town patients),
• changes to the patient’s address would influence state changes.
4
 States, Events, Transitions, Actions and Activities
• An event is something that takes place at a certain point in time and changes a value
or values that describe 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 period of time.
• The state of the object determines exactly what the response will be.

5
 States, Events, Transitions, Actions and Activities
• A transition is a relationship that represents the movement of an object from one state to
another state.
• Some transitions have a guard condition.
• A guard condition is a Boolean expression that includes attribute values, which allows a transition
to occur only if the condition is true.
• An object typically moves from one state to another based on the outcome of an action 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 non-atomic, decomposable process that can be interrupted.
• Activities take a long period of time to complete, and they can be started and stopped by an action.

6
 Elements of a Behavioral State Machine
• The Figure below presents an example of a behavioral state machine representing
the patient class in the context of a hospital environment.
• From this diagram, we can tell that a patient enters a hospital and is admitted after
checking in.
• If a doctor finds the patient to be healthy, he or she is released and is no longer
considered a patient after two weeks elapse.
• If a patient is found to be unhealthy, he or she remains under observation until the
diagnosis changes.

7
 Elements of a Behavioral State Machine
• Sample Behavioral State Machine Diagram:

8
 Elements of a Behavioral State Machine
• A state is a set of values that describes an object at a specific point in time and represents a point in an
object’s life in which it:
• satisfies some condition,
• performs some action, or
• waits for something to happen.
• In the Figure above states include entering, admitted, released, and under observation.
• A state is depicted by a state symbol, which is a rectangle with rounded corners with a descriptive label
that communicates a particular state.
• There are two exceptions:
• An initial state is shown using a small, filled-in circle, and
• an object’s final state is shown as a circle surrounding a small, filled-in circle.
• These exceptions depict when an object begins and ceases to exist, respectively.
9
 Elements of a Behavioral State Machine
• Behavioral State Machine Diagram Syntax:

10
 Elements of a Behavioral State Machine
• Arrows are used to connect the state symbols, representing the transitions between
states.
• Each arrow is labeled with the appropriate event name and any parameters or
conditions that may apply.
• E.g., the two transitions from admitted to released and under observation contain guard
conditions.
• As in the other behavioral diagrams, in many cases it is useful to explicitly show the
context of the behavioral state machine using a frame.

11
 Elements of a Behavioral State Machine
• The Figure below depicts two additional behavioral state machines.
• The first one is for the lunch object associated with the Make Lunch use-case scenario.
• The second behavioral state machine deals with the life cycle of an order.
• The order object is associated with the submit order use-case scenario.

12
 Elements of a Behavioral State Machine
• Additional Behavioral State Machine Diagrams:

13
 Guidelines for Creating Behavioral State Machines
• As with the sequence and communication diagrams, Amble suggests a set of
guidelines when drawing behavior state machines.
• In this case, we consider six of his recommendations:
• Create a behavioral state machine for objects whose behavior changes based on the state
of the object.
• In other words, do not create a behavioral state machine for an object whose behavior is
always the same regardless of its state.
• To adhere to the left-to-right and top-to-bottom reading conventions of Western cultures:
• the initial state should be drawn in the top left corner of the diagram and
• the final state should be drawn in the bottom right of the diagram.

14
 Guidelines for Creating Behavioral State Machines
• Make sure that the names of the states are simple, intuitively obvious, and descriptive.
• E.g., in the patient scenario, the state names of the patient object are Entering, Admitted,
Under Observation, and Released.
• Question black hole and miracle states.
• These types of states are problematic for the same reason black hole and miracle activities are
a problem for activity diagrams.
• Black hole states, states that an object goes into and never comes out of, most likely are actually
final states.
• Miracle states, states that an object comes out of but never went into, most likely are initial states.

15
 Guidelines for Creating Behavioral State Machines
• Be sure that all guard conditions are mutually exclusive (not overlapping).
• E.g, in the patient scenario, the guard condition [Diagnosis = Healthy] and the guard
condition [Diagnosis = Unhealthy] do not overlap.
• However, if you created a guard condition of [x >= 0] and a second guard condition [x <= 0],
• the guard conditions overlap when x = 0, and
• it is not clear to which state the object would transition.
• This would obviously cause confusion.
• All transitions should be associated with a message and operation.
• Otherwise, the state of the object could never change.
• Even though this may be stating the obvious, there have been numerous times that analysts
forget to go back and ensure that this is indeed true.

16
 Creating Behavioral State Machines
Set Context:
• Behavioral state machines are drawn to depict an instance of 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.
• Examine the class diagram to identify which classes undergo a complex series of
state changes and draw a diagram for each of them.
• Like the other behavioral models, the first step in the process is determining the
context of the behavioral state machine, which is shown in the label of the frame of
the diagram.

17
 Creating Behavioral State Machines
Set Context:
• The context of a behavioral state machine is usually a class.
• However, it also could be a set of classes, a subsystem, or an entire system.

18
 Creating Behavioral State Machines
Identify Object States:
• The second step is to identify the various states that an object will have over its
lifetime.
• This includes establishing the boundaries of the existence of an object by identifying
the initial and final states of an object.
• Also identify the states of an object.
• The information necessary to perform this is gleaned from reading the use-case
descriptions, talking with users, and relying on the requirements-gathering techniques.
• 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 the normal flow of events section of
a use-case description would be created.
19
 Creating Behavioral State Machines
Lay Out Diagram:
• The third step is to determine the sequence of the states that an object will pass
through during its lifetime.
• Using this sequence, the states are placed onto the behavioral state machine in a left
-to-right order.

20
 Creating Behavioral State Machines
Add Transitions:
• The fourth step is to identify the transitions between the states of the objects and to
add the events, actions, and guard conditions associated with the transitions.
• 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(s) of an
object’s attribute(s) in a significant manner.
• The actions are typically operations contained within the object.

21
 Creating Behavioral State Machines
Add Transitions:
• Also, guard conditions can model a set of test conditions that must be met for the
transition to occur.
• At this point in the process, the transitions are drawn between the relevant states and
labeled with the event, action, or guard condition.

22
 Creating Behavioral State Machines
Validate:
• The fifth step is to validate the behavioral state machine by making sure that each
state is reachable and that it is possible to leave all states except for final states.
• If an identified state is not reachable, either a transition is missing or the state was
identified in error.
• Only final states can be a dead end from the perspective of an object’s life cycle.

23
 Creating Behavioral State Machines: Library Example
Behavioral State Machine for an Instance of the Book Class in the Library Book
Collection Management System:

24
 Creating Behavioral State Machines: Library Example
Class Diagram for the Library Book Collection Management System:

25
 Creating Behavioral State Machines: Library Example
• The first step in drawing a behavioral state machine is to set the context.
• For our purposes, the context typically is an instance of a class that has multiple
states and whose behavior depends upon the state in which it currently resides.
• As suggested earlier, we should review the class diagram to identify the
“interesting” classes.
• In the case of the Library Book Collection Management System, the obvious class to
consider is the Book class.

26
 Creating Behavioral State Machines: Library Example
• The next step is to identify the different states through which an instance of the
Book class can traverse during its lifetime.
• Good places to look for possible state changes are the use-case descriptions, the
activity diagrams, the sequence diagrams, and the communication diagrams.
• In the case of a book, even though the states may be similar, you must be careful in
identifying the states associated with an instance of the Book class and not the states
associated with the physical book itself.

27
 Creating Behavioral State Machines: Library Example
• There are a number of implied states to consider.
• These include Checked Out, Overdue, Requested, Available, and Damaged.
• If the book is damaged:
• the book could either be repaired and put back into circulation or
• it could be too damaged to repair and be removed from circulation instead.
• Even though a Borrower could be fined for an overdue or damaged book, being fined is
not a state of a book, it is a state of a borrower.

28
 Creating Behavioral State Machines: Library Example
• Next, we lay out the diagram by ordering the states in a sequential manner based
on the life cycle of a book.
• E.g., it probably makes no sense to have a book to go from a repaired state to a
damaged state.
• However, going from a damaged state to a repaired state makes sense.
• Nor does it make sense for a book to go from an available state directly to an
overdue state.
• However, the converse makes sense.

29
 Creating Behavioral State Machines: Library Example
• The states we identified for a book object include:
• Available, Checked Out, Overdue, Requested, Damaged, and Being Repaired.
• Next we add the transitions between the states and label them with the appropriate
guard conditions.
• The behavioral state machine for an instance of the Book class is portrayed in the
Figure above.
• Finally, we validate the diagram by checking for missing states or transitions and
ensuring that there are no black hole or miracle states.

30