The University of Dodoma

Department of Computer Science

CS 314: Object Oriented Program Design and Analysis

Lecture 4: Unified Modeling Language (UML) (Sequence, Activity

and State Diagrams)
 Sequence Diagrams
● Before starting to code, we might want to
understand in more detail the steps involved in
each use case. One way to do this is to generate a
UML sequence diagram. A sequence diagram is
one of two kinds of UML interaction diagrams. The
other is the collaboration/communication diagram.
Both show how events unfold over time, but the
sequence diagram depicts time in a more graphical
way.
● A system sequence diagram shows the interaction
between an actor and the system for one use case
scenario. So there will be a system sequence
diagram for each use case scenario.
Sequence Diagrams
 Creating a System Sequence
Diagram
● Draw a rectangle representing the system. Label the
rectangle and draw a lifeline beneath it.
● At the left, draw a stick figure for each actor. Label it with
the actors name and draw a lifeline.
● For each system input, draw a message arrow from the
actors lifeline to the systems lifeline (i.e. Messages are
drawn from the sender to the receiver). Label it with the
message name and parameters.
● Confirm that the sequence of messages (from top to
bottom) is correct. Ordering is indicated by vertical position,
with the first message shown at the top of the diagram, and
the last message shown at the bottom. As a result,
sequence numbers aren't needed.
 Message Formats in System
Sequence Diagrams
● The UML format for a message consists of a
message name followed (in parentheses) by a
parameter list.
● All names begin with a lower-case letter.
● There are no spaces in a name.
● Upper-case letters separate the words within a
name.
● Names in the parameter list are separated by
commas.
 Note: General case
● Each use case is first carefully examined to
determine the objects in the use case.
● Then each object is drawn as a vertical as a
vertical line with the object name next to it.
● Then messages between objects are shown in
their time sequence, going from top to bottom.
● As a general rule, each actor becomes an
object in the sequence diagram.
● See next slide for another type of sequence
diagram.
Another Sequence Diagram
 Using Sequence Diagrams
● Sequence diagrams are often a good first step to object
class diagrams. That means we can get object classes
and methods.
● Each message in a sequence diagram states the
message parameters.
● Each of the objects in the sequence diagram eventually
becomes an object class; there must be a method to
manage each object class. The parameters carried by the
incoming and outgoing messages identify the properties
of the object class which becomes the attributes.
● Remember also to have sequence diagrams to handle
alternatives developed in use cases.
Alternatives
 Getting classes from use cases
● From the description of the use case identify nouns
which are going to be possible candidates for classes.
But some of the nouns are inappropriate class
candidates. Here you have to use experience to judge
which ones are not appropriate.
● Experience shows that most of the rejected nouns will
be candidates for attributes (member data) in classes.
● From Verbs to Messages
Discovering messages in the description, is the same
as discovering the member functions of the class
receiving the message. As with nouns, not every verb
is a candidate for a message.
 Some examples

● Verbs are bold

– The program displays the Tenant List, each row of
which contains an apartment number and the tenants
name
● displays means that the User Interface screen
sends a message to somewhere. Therefore we
can have a function say display().
● The contains verb does not correspond to a
message; it merely describes the contents.
 Some examples

● Verbs are bold

– The program presents the Tenant Input screen, which
prompts the user to enter the new tenants name and
apartment number. It then places this information on a new
row in the Tenant List. This list is sorted by apartment
number
● The presents verb represents a message which might
be a call to a member function in the Tenant Input
screen with a name like getTenant().
● Both prompts and enter refer to the Tenant Input
screens communication with the user. They don't
represent messages in the object-oriented sense.
 Some examples
● The verb places means that that the Tenant
Input screen sends a message to the Tenant
List class, probably with a new Tenant object as
an argument. The Tenant List object can then
insert this new object into its list. This function
might have a name like insertTenant().
● The is sorted verb is not a message or indeed
any kind of communication, but a description of
the Tenant List.
Activity Diagrams
 Activity Diagrams
● We have described the flow of a use case with text (the
use case specification).They are easy to create and
change (no complex tools are required).
● However, complex use cases can be difficult to
comprehend when captured in text.
● A visual representation of complex flows is much more
powerful. We can see potential problems visually that a
stack of textual specifications could never reveal.
● Activity diagrams provide visual depictions of the flow of
activities in a system. These diagrams focus on the
activities that are performed and who (or what) is
responsible for the performance of those activities.
Each use case may create one activity diagram
 Elements
● The elements of an activity diagram are action
nodes, control nodes, and object nodes.
● There are three types of control nodes: initial
and final (final nodes have two varieties, activity
final and flow final), decision and merge, and
fork and join.
 Actions
● Actions are the elemental unit of behavior in an
activity diagram.
● Activities can contain many actions which are
what activity diagrams depict. Symbol for action
is shown below
 Starting and Stopping
● Since an activity diagram shows a process flow,
that flow must start and stop somewhere. The
starting point (the initial node) for an activity
flow is shown as a solid dot, and the stopping
point (the activity final node) is shown as a
bulls-eye. See figure below.
 Starting and Stopping
● Another type of final node is the flow final node,
which is denoted by a circle with a nested ”X”
symbol. The flow final node, used to stop a
single flow without stopping the entire activity. It
will be depicted in the discussion of the merge
node.
 Decision and Merge Nodes
● Decision and merge nodes control the flow in an
activity diagram. Each node is represented by a
diamond shape with incoming and outgoing arrows.
● A decision node has one incoming flow and multiple
outgoing flows. Its purpose is to direct the one incoming
flow into one (and only one) of the nodes outgoing flows.
The outgoing flows usually have guard conditions that
determine which outgoing path is selected. There is no
waiting or synchronization at a decision node (see next
slide).
● Merge nodes take multiple input flows and direct any
and all of them to one outgoing flow. There is no waiting
or synchronization at a merge node ( see Next slide)
Decision and Merge Nodes
 Partitions
● The elements in an activity diagram can be
grouped by using partitions. The purpose of a
partition is to indicate where the responsibility
lies for performing specific activities.
● Each partition may be named to indicate the
responsible party.
● See next slide shows part of use cases diagram
of a certain Gardening system.
 Partitions

● Next slide shows how the various activities that

comprise the Maintain Storage Tanks use case
of a Gardening System are partitioned to the
Gardener, WaterTank, and NutrientTank.
Partitions
 Forks, Joins, and Concurrency
● Fork and join nodes are analogous to decision and
merge nodes, respectively. The critical difference is
concurrency. Forks have one flow in and multiple flows
out, as do decision nodes.
● The difference is, where a decision node selects a single
outbound flow, a single flow into a fork results in multiple
outbound flows. All the outbound flows occur
concurrently
● In next slide, a single flow goes from the Set Fill Levels
action into the fork, which is the first thick horizontal line.
Thereafter, the NutrientTank flow (with the Fill action)
and the WaterTank flow (with the Disable Heating, Fill,
and Enable Heating actions) both occur in parallel.
Forks, Joins, and Concurrency
 Joins
● A join has multiple incoming flows and a single
outbound flow, similar to merge nodes.
However, with a join, all the incoming flows
must be completed before the outbound flow
commences.
● In Figure of previous slide, the second thick
horizontal line is a join.
● Both of the incoming flows, NutrientTank and
WaterTank, must be complete before the
outbound flow continues to the Resume
Operations action.
Joins
State Diagrams
 State Diagrams: Definitions
● State Machine
A state machine is a behavior which specifies the sequence
of states an object visits during its lifetime in response to
events, together with its responses to those events
● State
A state is a condition during the life of an object during which
it satisfies some condition, performs some activity, or waits for
some external event
● Event
An event is the specification of a significant occurrence. For a
state machine, an event is the occurrence of a stimulus that
can trigger a state transition. For a Project Management
System, events are startup, shutdown, severe error and
Reset.
 State Diagrams: Definitions
● Transition
A transition is a relationship between two states
indicating that an object in the first state will,
when a specified set of events and conditions are
satisfied, perform certain actions and enter the
second state. A transition has:
● Transition Components
– a source state
– an event trigger
– an action
– a target state
 State Diagrams: Definitions
● Self-Transition
A self-transition is a transition whose source and
target states are the same
● Action
An action is an executable, atomic (with
reference to the state machine) computation.
Actions may include operations, the creation or
destruction of other objects, or the sending of
signals to other objects (events).
 Simple States
● A simple state indicates a condition or situation of
an element. For example, the project management
system may be in one of the following simple
states:
– Inactive which indicates that the project management
system is not available to its users, because it is not
started or has been shut down
– Active Indicates that the project management system
has been started and is available to its users
– Suspended Indicates that the project management
system has encountered some severe error, perhaps
because it is running low on secondary storage and
requires user intervention before becoming active again
 Simple states
● In the UML, a simple state is shown as a
rectangle with rounded corners and labeled
with the name of the state or a description of
the situation of the element. Figure in the next
slide shows the various states associated with
the project management system.
Simple states for the project
management system
Simple states : Alternative
representations
 Initial and Final States
● An initial state indicates the state of an element
when it is created. In the UML, an initial state is
shown using a small solid filled circle. A final
state indicates the state of an element when it
is destroyed. In the UML, a final state is shown
using a circle surrounding a small solid filled
circle (a bull’s eye). A state diagram may have
only one initial state, but may have any number
of final states.
Initial and Final States
 Transition with events
● In the UML, an event is described using the
following UML syntax: eventName
(parameterList) [guard]
● in which:
– eventName Is the name of the event.
– parameterList Is optional, and is a comma-
separated list that indicates the parameters passed
to the event.
– guard Is optional, and indicates a condition that
must be satisfied for the transition to fire, or occur.
The square brackets are not shown when a guard is
not specified.
Transition with events
 Transition with events and actions
● An action represents processing. For example, the project
management system may respond to events with the
actions like LogMessage and getDateAndTime
● In the UML, an action is described using the following UML
syntax:
– returnVariable := targetElement.actionName (argumentList)
● where:
– returnVariable is optional, and indicates a name for the value
returned by the action to be invoked in response to the event
– targetElement is the name of the element that will perform the
action
– actionName is the name of the action.
– argumentList is optional, and is a comma-separated list that
indicates the arguments passed to the action.
Transition with events and actions ...
● With the example from the previous section, the
following action passes the user’s time zone to
the operating system (OS) using the
getDateAndTime operation:
OS.getDateAndTime (TimeZone)
● If this action returns some output data (the
current date and time), you can update the
action to the following:
DT := OS.getDateAndTime (TimeZone)
Transition with events and actions ...

Create Destroy
Inactive

Shutdown(UserID)[System can shutdown] StartUp(UserID)[Enough memory is available]

/logMessage(UserID, “Shutdown”) /DT:=OS.getDateAndTime(Timezone)

Active

Reset Severe Error

Suspended
 More examples: Microwave Oven
● This simple microwave has a switch to select full
or half power, a numeric keypad to input the
cooking time, a start/stop button, and an
alphanumeric display. The assumption for the
sequence of actions in using the microwave is:
– Select the power level (either half power or full power).
– Input the cooking time using a numeric keypad.
– Press Start and the food is cooked for the given time.
● For safety reasons, the oven should not operate
when the door is open and, on completion of
cooking, a buzzer is sounded.
Microwave oven: Summary of states
State Diagram for the Microwave oven
 Advanced States
● UML allows us to put one or more state diagrams inside a
single state to indicate that when an element is in that
state, other elements inside of it have their own states.
Eg. within the Active state of the PMS, each object and
subsystem has its own state, and the state diagram for
each element is shown inside the Active state of the PMS
or by using the element’s own state diagram. The middle
compartment of a state may contain transitions for the
following special events:
– entry: Indicates the action to be performed when the element
enters the state
– exit: Indicates the action to be performed when the element
exits the state
– do: Indicates the action to be performed continuously while the
element is in the state
 Advanced States: Definitions
● Substate
– A substate is a state that is nested in another state.
– A state that has substates is called a composite state.
– A state that has no substates is called a simple state.
– Substates may be nested to any level.
● Transitions to a composite state
– If a transition is to a composite state, the nested state
machine must have an initial state
– If a transition is to a substate,the substate is entered
after any entry action for the enclosing composite
state is executed followed by any entry action for the
substate
 Advanced States
Transitions from a composite state
● If a transition is from a substate within the
composite state, any exit action for the substate
is executed followed by any exit action for the
enclosing composite state.
● A transition from the composite state may occur
from any of the substates and takes precedence
over any of the transitions for the current
substate
Advanced States: Sub states
Microwave oven: revisited
Advanced States: Another example