Software Engineering

Lecture 7
UML Sequence & state Diagrams

Reading:
UML Distilled, Ch. 4, M. Fowler(seq)
UML Distilled, Ch. 10, M. Fowler(state)
 UML sequence diagrams
• sequence diagram: an "interaction diagram" that models a
single use case executing in the system
– Shows what messages (method calls) are sent between objects
and when
• Class diagrams were static, sequence diagrams are dynamic
– perhaps 2nd most used UML diagram (behind class diagram)

• relation of UML diagrams to other exercises:

– CRC cards  class diagram
– use cases  sequence diagrams

2
 Key parts of a Sequence diag.
• participant: object or entity that acts in the diagram
– diagram starts with an unattached "found message" arrow

• message: communication between

participant objects

• the axes in a sequence diagram:

– Horizontal: which object/participant
is acting
– Vertical: time (down = forward
in time)

3
 Key parts of a Sequence diag.
• participant: object or entity that acts in the diagram
– diagram starts with an unattached "found message" arrow

• message: communication between

participant objects

• the axes in a sequence diagram:

– Horizontal: which object/participant
is acting
– Vertical: time (down = forward
in time)

4
 Sequence diagram from a use case
• The user presses the “check email”.
• The client first sends all unsent
email to the server.
• After receiving an
acknowledgement, the client asks
the server if there is any new
email.
• If so, it downloads the new email.
• Next, it deletes old thrashed email
from the server.

5
 Why Sequence Diagrams
• Showing dynamic interactions between objects using sequence
diagrams

• Purpose
– See if our class diagram can satisfy each step of the use case
• Identify more classes that we may have missed in class diagram
• Identify methods of those classes

6
 Representing objects
• Squares with object type, optionally preceded by "name :"
– write object's name if it clarifies the diagram
– object's "life line" represented by dashed vert. line

7
 Messages between objects
• messages (method calls) indicated by arrow to other object
– write message name and arguments above arrow

8
 Messages, continued
• messages (method calls) indicated by arrow to other object
– dashed arrow back indicates return
– different arrowheads for normal / concurrent (asynchronous) calls

9
 Lifetime of objects
• creation: arrow with 'new'
written above it
– notice that an object created
after the start of the scenario
appears lower than the others

• deletion: an X at bottom of
object's lifeline
– Java doesn't explicitly delete
objects; they fall out of scope
and are garbage-collected

10
 Indicating method calls
• activation: thick box over object's life line; drawn when
object's method is on the stack
– either that object is running its code,
or it is on the stack waiting for another object's method to finish

Activation

Nesting

11
 Example: Use case
• UC1: Comment Document
• Flow of events
– The advisor wants to comment a document
– The advisor clicks the “comment document” link
– The system displays list of documents for comment
– The advisor selects a specific document
– The system displays the “comment document” form
– The advisor fills out the form and clicks submit button.
– The system adds the comment and displays a confirmation
message
– The use case ends

12
 Selection and loops
• frame: box around part of diagram to indicate if or loop
– if -> (opt) [condition]
– if/else -> (alt) [condition], separated by horizontal dashed
line
– loop -> (loop) [condition or items to loop over]

13
 Linking sequence diagrams
• If one diagram is too large or refers to another, indicate with:
– an unfinished arrow and comment,
– or a "ref" frame that names the other diagram

Customer Info ref

Verify customer credit

Approved?

14
 Example sequence diagram
sd Example

StoreFront Cart Inventory

loop
AddItem
ReserveItem

Checkout

ProcessOrder
ConfirmOrder

PlaceItemInOrder

15
 Why not just code it?
• Sequence diagrams can be somewhat close to the code level.

• So why not just code up that algorithm rather than drawing it

as a sequence diagram?
– a good sequence diagram is still a bit above the level of the real
code (not all code is drawn on diagram)
– sequence diagrams are language-agnostic (can be implemented in
many different languages
– non-coders can do sequence diagrams
– easier to do sequence diagrams as a team
– can see many objects/classes at a time on same page (visual
bandwidth)

16
 Recap: Three different Types of
objects
1. Boundary Objects
Model the system boundary (often multiple)
User Interface elements (entire screens,
but not individual ui elements)

2. Control Objects
Represents an entity or manager that makes decisions (e.g. figures
out what to do when a button is pressed)
In simple systems, this is usually the application itself, and there
is typically only a single Control Object
3. Entity Objects
A data store or persistence element that captures or represents information
(often multiple objects)

17
Boundary, Entity, and Control elements
must obey the following relationships
1. Actors can only talk to
boundary objects.

2. Boundary objects can

usually only talk to
controllers and actors.

3. Entity objects can usually

only talk to controllers and
boundary objects.

4. Controllers can talk to

boundary objects and entity
objects, and to other
controllers, but not to actors

18
The following relationships are generally
restricted or not permitted
1. Actors can only talk to boundary
objects.

2. Entity objects can communicate

Allowed with with an another Entity that it
reservations
“owns” (e.g. an Collection owns
Allowed with reservations Items in the Collection)
Allowed with
reservations
3. Boundary objects can talk to
certain Entity objects (UI gets
Items from a Collection to display),
and other Boundary objects it
“owns” (e.g. a popup dialog).

4. Controllers can talk to boundary

objects and entity objects, and to
other controllers, but not to actors

19
 Example ReportEmergency use case
Report Manage
EmergencyButton EmergencyControl
FieldOfficer

press() «create»
ReportEmergency
Control

«create» ReportEmergency
Form

fillContents()

submit()
submitReport
«create»
Emergency
Report

submitReportToDispatcher()
«destroy»

20
 UML state diagrams
• state diagram: Depicts data and behavior of a single object
throughout its lifetime.
– set of states (including a start state and end states)
– transitions between states due to an event
– entire diagram is drawn from that object's perspective

• Here is a State chart for a Phone Line object state

initial State

event
transition

21
 State diagram example 2
– removing candle reveals lock, which you can open using key
– Otherwise get devoured by a killer rabbit

22
 When to develop a state chart?
• Model objects that have change state in interesting ways:
– Devices (microwave oven, Ipod)
– Complex user interfaces (e.g., menus)
– Transactions (databases, banks, etc.)
– Stateful sessions (server-side objects)
– Controllers for other objects
– large, complex objects with a long lifespan

• Not useful to do state diagrams for every class in the system!

23
 States
• state: conceptual description of the data in the object
– represented by object's field values
– E.g If Lock class has an isWaiting field
and it is set to true – we can say we are
in Waiting state.

• entire diagram is drawn from the

central object's perspective
– only include states / concepts that
this object can see and influence
– don't include every possible value
for the fields; only ones that are
conceptually different

24
 Transitions
• transition: movement from one state to another

• signature [guard] / activity

– signature: event that triggers (potential) state change
– guard: boolean condition that must be true
– activity: any behavior executed during transition
(optional)

25
 Internal activities
• internal activity: events that the
central object takes on itself
– sometimes drawn as self-transitions
(events that stay in same state)

• entry/exit activities
– reasons to start/stop being in that state

26
State diagram example
User account management

27
 Exercise
• Draw a state diagram for an order object.

28
 Super/substates
• If there are states share common transitions and internal
activities
– You can make them substates
• Caution: Don't over-use this feature.
– easy to confuse separate states for sub-states within one state

29