Object-Oriented System Anaysis
and Design
Chapter 2-Part III
Behavioral Models:
Sequence diagram and Activity Diagram
Interaction Diagram Expressing How Things Work Together
Sequences Diagram
Overview
 In every system, objects do not just sit idle; they
interact with one another by passing messages.
 In the UML, the dynamic aspects of a system is
modelled using interactions
 An interaction sets the stage for its behaviour by
introducing
 all the objects that work together to carry out some action, and
 the messages that are dispatched from object to object
3
Definition
 An interaction is a behaviour that comprises a set
of messages exchanged among a set of objects
within a context to accomplish a purpose
 Interactions can be found wherever objects are
linked to one another, e.g.
 in the collaboration of objects that exist in the context
of a system and subsystem as a whole
 among objects in the implementation of an operation
 in the context of a class in order to visualize, specify,
construct and document the semantic of a class
4
Messages & Actions
 A message is a communication between two
objects, or within an object, that is designed to
result in some activity.
 This activity involves one or more actions, which
are executable statements that result in
 changes in the values of one or more attributes of an
object,
 or the return of some value(s) to the object that sent
the message,
 or both
5
 There are 5 kinds of actions that the UML
explicitly supports:  Call and Return
 Create and Destroy
 Send
6
 Call action
 A call action invokes an operation on an object
 It is synchronous, meaning that
 the sender assumes that the receiver is ready to accept the message,
 and the sender waits for a response from the receiver before proceeding
 The UML represents a call action as an arrow from the calling
object to the receiving object
: Class
Object: Class
action name
A call action that involves
two objects
A lifeline
action name
A call action from an object
to itself
7
 Return action
 A return action is the return of a value to the caller, in response to
a call action
 The UML represents a return action as a dashed arrow from the
object returning the value to the object receiving the value
: Class
Object: Class
return value
8
Example :- Call and Return action
: Customer
: CustomerReview
assignRating()
computeAvgRating()
average rating
9
 Create action
 A create action creates an object
 It tells a class to create an instance of itself
 In the UML, create action is represented as an arrow with the
stereotype <<create>> from the object that invokes the create action
to the created object
Object: Class
: Class
<<create>>
Object: Class
<<create>>
: Class
Alternate Create Action notation
10
 Destroy action
 A destroy action destroys an object
 It tells an object to destroy itself
 An object can perform a destroy action on another object, or on itself
 In the UML, a destroy action is represented as an arrow with the
stereotype <<destroy>> from the object that invokes the action to the
destroyed object. A large X is also added at the end of the destroy arrow
to denote that the object’s lifeline has been terminated
Object: Class
: Class
<<destroy>>
11
X
 Send action
 A send action sends a signal to an object
 A signal is an asynchronous communication between objects
 One object “throws” a signal to another object that “catches” the signal
 The sender of the signal does not expect a response from the receiver (unlike
the sender of a call action)
 Exceptions are the most common type of signals
 In the UML, a send action is represented as an arrow with a half
arrowhead at the lifeline of the receiving object
: Class
Object: Class
action name
12
Modelling an interaction
 When modelling an interaction, we
need to include both objects and
messages
 each object plays a specific role
 each message represents the
communication between objects, with
some resulting action
13
Cont…
 We can visualize objects and messages in an
interaction in two ways: -
 by emphasizing the time ordering of its message
: sequence diagram
 by emphasizing the structural organization of
the objects that send and receive messages :
collaboration diagram
 Both sequence and collaboration diagram
are examples of interaction diagrams
Cont…
 In the UML, an interaction diagram is used to
model the dynamic aspect of a system.
 These dynamic aspect may involve : -
 the interaction of any kind of instance in any view
of a system’s architecture, including instances of
a class, interface, components and nodes.
 a system as a whole, a subsystem, an operation or
a class
15
 An interaction diagram can be used in two ways:  To model flows of control by time ordering
 emphasizes the passing of messages as they unfold over
time
 Sequence Diagram is used to model this
 To model flows of control by organization
 emphasizes the structural relationships among the
instances in the interaction, along which messages may be
passed
 Collaboration Diagram is used to model this
16
Sequence diagram
 A sequence diagram is an interaction diagram
that emphasizes the time ordering of messages
 A sequence diagram is formed by:  Placing the objects that participate in the
interaction at the top of the diagram, along the Xaxis
 The object that initiates the interaction is placed on
the left most, and the other subordinate objects are
placed to the right
17
Cont..
 Placing the messages that these objects send
and receive along the Y-axis, in order of
increasing time from top to bottom
 A sequence diagram has four key
elements:  Objects appear along the top margin
 Each object has a lifeline, which is a dashed
line that represent the life and perhaps death
of the object
 Most objects will be in existence for the
duration of the interaction
 Objects may also be created during the
interaction, or destroyed
19
Cont…
 A focus of control, which is a tall thin
rectangle that sits on top of an object’s lifeline
 It shows the period of time during which an object is
performing an action, either directly or through
subordinate procedure
 The bottom part of a focus of control can be marked
by a return message
 Messages show the actions that objects
perform on each other and on themselves
objects
C : Client
p : ODBCProxy
<<create>>
: Transaction
setActions(a, d, o)
setValues(d, 3, 4)
setValues(a, “CO”)
time
committed
<<destroy>>
lifeline
X
focus of control
Example of a sequence diagram
21
 You built sequence diagrams or collaboration
diagrams from the use-case and class diagrams that
were built before.
 Each use cases in a use-case diagram has its
corresponding sequence or collaboration
diagram
 You model the diagrams from the main flow of
events, or the alternate flow of events, or the
scenarios, of each use case
 Every object that you have identified in the
sequence or collaboration diagram, MUST have its
22
corresponding class in the class diagram
 Example: - Modelling a sequence diagram for the log-in use
case from the on-line Bookstore Case Study.
 The main-flow of events that are involved is: 1. The CUSTOMER clicks the Log-in button on the Home Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password. The
CUSTOMER clicks the OK button.
4. The system validates the log-in information against the ACCOUNT
table in the database.
5. CUSTOMER is an authorised user; the system displays the Personal
Home Page to the CUSTOMER
23
 Actors: Customer
 Messages and Objects
1. The CUSTOMER clicks the Log-in button on the Home Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password. The
CUSTOMER clicks the OK button.
5. The system validates the log-in information against the
ACCOUNT table in the database.
6. CUSTOMER is an authorised user; the system displays the
Personal Home Page to the CUSTOMER
24
:Customer
The Customer clicks
the Login button on
the Home Page
:LoginPage
:HomePage
:Account
clickLogin( )
display( )
The system displays
the Login Page
The Customer enters
his or her user ID
and password, and
then clicks the OK
button.
The system validates
the login information
against the persistent
Account data …
enter userID
and password
clickOK( )
validateLogin(userID,
password)
login OK
display( )
… and then returns the
Customer to the Home
Page.
25
Sequence Diagram
Robustness Analysis
 Sometimes when drawing an interaction diagram,
we may be confused about the objects that are
involved.
 Because each object that we use in an interaction
diagram MUST have its corresponding classes in
the class diagram, we may find ourselves in a
situation where we have already determined the
objects that are needed in an interaction diagram
but the objects do not have their corresponding
classes in our class diagram.
26
 Robustness analysis involves analysing the text of a
use case and identifying a first-guess set of objects
that will participate in the use case, and then
classifying these objects based on their
characteristics.
 It involves defining analysis classes
 There are 3 types of analysis classes:
 boundary classes
 entity classes
 control classes
Instances of each of these analysis classes are called objects.
27
 Boundary objects
 is an object with which an actor associated with a
use case interacts.
 if the actor is human, the boundary object may be a
window, screen, dialog box, or menu
 if the actor is non-human, the boundary object may be
application program interfaces (APIs)
boundary object
28
 Entity objects
 is an object that contains long-lived information,
such as that associated with databases.
 will be mapped to a table (part of the database) in the
design phase
 It can also contain transient objects, i.e. contents
of lists in windows, or search results.
entity object
29
 Control objects
 is an object that embodies application logic
 correspond with system actions (not actions taken by
actors)
 are often used to handle things such as coordination and
sequencing
 are also useful for calculations involving multiple entity objects
 will be mapped to codes during implementation phase
 used as a connecting tissue between boundary objects and
entity objects.
control object
30
 Using the previous example (the log-in use
case of the Online Bookstore), we can identify
that
 the HomePage and Log-in Page objects are
boundary objects,
 whereas the Account object is an entity object.
 Therefore, taking this into account, we can
draw a new interaction diagram.
31
:Customer
The Customer clicks
the Login button on
the Home Page
:LoginPage
:HomePage
:Account
clickLogin( )
display( )
The system displays
the Login Page
The Customer enters
his or her user ID
and password, and
then clicks the OK
button.
The system validates
the login information
against the persistent
Account data …
enter userID
and password
clickOK( )
validateLogin(userID,
password)
login OK
display( )
… and then returns the
Customer to the Home
Page.
32
Sequence Diagram
Summary
 No single interaction diagram can capture
everything about a system’s dynamic aspect
 may need to use many interaction diagrams to
model the dynamic aspects of a system as a
whole, as well as its subsystem, operations,
classes, use cases and collaborations.
33
 To model a sequence diagram:  Set the context for the interaction
 Whether it is a system, subsystem, operation, class or a scenario of
a use case or collaboration
 Identify which objects play a role in the interaction
 Place them from left-to-right, at the top of the diagram
 Set the lifeline for each object
 Starting with the message that initiates the interaction,
layout each subsequent message from top to bottom
between each lifelines
 May adorn each object’s lifeline with its focus of control
 May also adorn each message with a timing mark and attach suitable
time or space constraints
 May also attach pre or post-conditions to each message
34
 On-line Bookstore is a web application that can be accessed
by the store’s registered customer, whereby each customer
can order books, review one or more books sold in the book
store, and sell used books to other customers. Before
performing any one of these transactions, the customer must
first log-in into the system using their user id and password
kept in their account.
 Problem: Draw the sequence diagram for the above system
35
 From previous discussions, we know that the
functional requirements for the Online Bookstore
can be seen from the use case diagram (as shown in
the next slide)
 Each of the use cases in the use case diagram must have its
corresponding interaction diagram
 We will use the scenarios in the ‘Main flow of events’ for
each use case to model the interaction diagram
36
On-line Bookstore System
Register
<<extend>>
(CustID)
Customer
Check out
Order books
<<include>>
<<include>>
Log-in
Sell used
books
<<include>>
Use Case
Functional
Requirements
37
Diagram
Review books
Log-in
:Customer
The Customer clicks
the Login button on
the Home Page
:LoginPage
:HomePage
:Account
clickLogin( )
display( )
The system displays
the Login Page
The Customer enters
his or her user ID
and password, and
then clicks the OK
button.
The system validates
the login information
against the persistent
Account data …
… and then returns the
Customer to the Home
38
Page.
enter userID
and password
clickOK( )
validateLogin(userID,
password)
login OK
display( )
 Use Case: Register
 Main flow of events:
1. The CUSTOMER clicks the REGISTER button on the Home Page.
2. The system displays the Register Page.
3. The CUSTOMER enters all of the required information.
4. The CUSTOMER clicks the SEND button.
5. The system checks that all of the required information were entered. If
yes, the system update the CUSTOMER’s record in the CUSTOMER
and ACCOUNT tables in the database. System displays OK message.
 Objects: CUSTOMER: actor
 CUSTOMER and ACCOUNT: entity objects
 Home Page and Register Page: boundary objects
39
Register
:Customer
The customer clicks
the REGISTER button
on the Home Page
The system displays
the Register Page
The Customer enters
the required
information and then
clicks the SEND
button.
The system checks
that all of the required
information were
entered. If yes, the
system updates the
CUSTOMER’s record
in the CUSTOMER
and ACCOUNT tables
in the database. The
40
system displays OK
message
:HomePage
:RegisterPage
clickRegister( )
display( )
enter information
clickSEND( )
verify info
<<create>>
display( )
:Account
<<create>>
:Customer
 Case Study: Order Books
 Main Flow of events: 1. The CUSTOMER enters the keyword for a book and clicks the
SEARCH button on the personal Home Page.
2. The system displays the matching books on the web Page.
3. The CUSTOMER chooses the desired book and clicks the ADD TO
SHOPPING CART button on the web page.
4. The system adds the book into the CUSTOMER’s Order table in the
database.
 Objects:
 Customer: actor
 Home Page: boundary object
 Book and Order: entity object
41
Order
books
:Customer
The CUSTOMER
enters the keyword for
a book and clicks the
SEARCH button on the
personal Home Page
The system adds the
book into the
CUSTOMER’s Order
table in the database.
42
:Order
enters keyword
clickSearch( )
search( )
The system displays
the matching books on
the web Page
The CUSTOMER
chooses the desired
book and clicks the
ADD TO
SHOPPING CART
button on the web
page.
:Book
:HomePage
displayMatch( )
choose books
clickAdd()
<<create>>)
addBook( )
 Use Case: Check-out
 Main flow of events
1. The CUSTOMER clicks the Check out button on the Home Page
2. The system displays the books in the ORDER table of the CUSTOMER on
the web Page.
3. The CUSTOMER checks the order list for any inconsistency. If nothing was
found, CUSTOMER clicks the PROCEED button.
4. The system displays the Invoice page.
5. The Customer enters the relevant credit card information and clicks OK.
6. The system checks that the credit card is valid. Then, the system displays the
Delivery Details page.
7. The CUSTOMER chooses destination for delivery, along with delivery
options. Then, he/she clicks the PROCEED button.
8. The system will display the check-out information for confirmation.
7. The CUSTOMER checks that all information is correct and then clicks the
OK button.
8. The system sends a confirmation via CUSTOMER’s e-mail.
 Objects:  Home Page, Invoice Page and Delivery Page: boundary objects
43
 Customer and Order: entity objects
:Customer
:Order
:HomePage
:InvoicePage
:Customer :DeliveryPage
clickCheckOut( )
retrieve()
display( )
verify info
clickProceed( )
display( )
enter credit card info
clickOK()
validate( )
display( )
choose destination
clickOK()
display()
44
confirm and clickOK ()
 Use case: Sell used books
 Main flow of events: 1. The CUSTOMER clicks the Sell Used Books button on the Home
Page.
2. The system displays the sell used books web page.
3. The CUSTOMER enters the required information on the used books
that he/she wants to sell.
4. The CUSTOMER clicks the SEND button on the webpage.
5. The system displays a confirmation page listing the information that
the CUSTOMER has entered.
6. The CUSTOMER checks that the information displayed are accurate.
If yes, the CUSTOMER clicks the OK button on the web page.
7. The system updates the USED BOOKS table in the database.
 Objects:
 Home Page, Used Books Page and Confirmation Page: boundary objects
 Customer and Used Books: entity objects
45
Sell used
books
:Customer
:HomePage
clickUsedBooks( )
:UsedBooksPa :ConfPage :Customer :UsedBook
ge
display( )
enter book info
clickSend( )
display( )
verify info
clickOK( )
add( )
46
add( )
 Use case: Review
 Main flow of events: 1. The CUSTOMER enters the keyword to search for a book and then
clicks the SEARCH button on the Personal Web Page.
2. The system displays the matching books on the web Page.
3. The CUSTOMER checks for the desired book and clicks on the
chosen book icon.
4. The system displays the book’s detail in the Book Detail web page.
5. The CUSTOMER clicks the REVIEW button on the web page.
6. The system displays the Review Book web page.
7. The CUSTOMER clicks on the desired star button and the click the
OK button on the web page.
8. The system calculates the overall rating of the book and updates the
Book table in the database.
9. The system displays the Book Detail web pages that have been
updated.
 Objects?
 Diagram?
47
Recall
Commonly Used UML Diagrams
The most commonly used UML diagrams
are:
 Use case diagram, describing how the
system is used.
 The starting point for UML modeling.
 Activity diagram.
 Each use case may create one activity
diagram.
18-49
Commonly Used UML Diagrams
 Sequence diagram, showing the sequence
of activities and class relationships.
 Each use case may create one or more
sequence diagrams.
 A collaboration diagram is an alternative to a
sequence diagram.
18-50
Commonly Used UML Diagrams
 Class diagram, showing classes and
relationships.
 Sequence diagrams and CRC cards are used to
determine classes.
 Statechart diagram.
 Each class may create a statechart diagram, useful for
determining class methods.
18-51
Overview of UML Diagrams
18-52
Activity Diagram
Activity Modeling
 Activity diagrams describe the workflow
behavior of a system.
 They are typically used for business process
modeling, for modeling the logic captured
by a single use case or usage scenario, or for
modeling the detailed logic of a business
rule.
Cont…
 UML activity diagrams could potentially
model the internal logic of a complex
operation.
 In many ways UML activity diagrams are the
object-oriented equivalent of flow charts.
Cont…
 Activity diagrams do not give detail about
how objects behave or how objects
collaborate.
 Diagrams are read from top to bottom and
have branches and forks to describe
conditions and parallel activities.
 A fork (diverge) is used when multiple
activities are occurring at the same time.
Cont…
 Activity diagrams show the sequence of activities
in a process, including sequential and parallel
activities.
 Symbols are used for activities, decisions and so
on.
 Arrows represent events that connect the
activities.
18-57
Cont…
 The diagram above shows a fork after
activity1.
 This indicates that both activity2 and
activity3 are occurring at the same time.
 After activity2 there is a branch. The
branch describes what activities will take
place based on a set of conditions.
Cont…
 All branches at some point are followed by a
merge to indicate the end of the conditional
behavior started by that branch.
 After the merge all of the parallel activities
must be combined by a join before
transitioning into the final activity state.
Activity Diagram Symbols
18-61
Example to illustrate the activity of performing selling an
item to a customer.
Creating Activity Diagrams
 Ask what happens first, second, and so
on.
 Determine if the activities happen in
sequence or parallel.
 Examine all the scenarios for a use case.
18-63
Swimlanes
 Included on activity diagrams to show
partitioning
 Show which activities:
 Occur on a browser
 Occur on a server
 Happen on a mainframe
 Are done by external partners
 Help to divide tasks among team members
18-64
Swimlane Boundaries
When an event crosses swimlane boundaries,
data must be transmitted.
 A Web form is sent to a server.
 Data are placed into middleware to
transmit it between a server and a
mainframe.
 Data are transmitted to and from an
external partner.
18-65
More on Activity Diagrams
 An activity diagram is like a state diagram.
 Except most transitions are caused by internal
events, such as the completion of a computation.
 An activity diagram
 Can be used to understand the flow of work that an
object or component performs.
 Can also be used to visualize the interrelation and
interaction between different use cases.
 Is most often associated with several classes.
66
Cont…
 One of the strengths of activity diagrams is the
representation of concurrent activities.
Activity diagrams – an example
68
Representing concurrency
 Concurrency is shown using forks, joins and
rendezvous (Convergent).
 A fork has one incoming transition and multiple
outgoing transitions.
 The execution splits into two concurrent threads.
 A rendezvous has multiple incoming and multiple
outgoing transitions.
 Once all the incoming transitions occur all the
outgoing transitions may occur.
69
Representing concurrency
 A join has multiple incoming transitions and
one outgoing transition.
 The outgoing transition will be taken when
all incoming transitions have occurred.
 The incoming transitions must be triggered
in separate threads.
 If one incoming transition occurs, a wait
condition occurs at the join until the other
transitions occur.
70
Swimlanes
 Activity diagrams are most often associated with
several classes.
 The partition of activities among the existing
classes can be explicitly shown using swimlanes.
71
Activity diagrams – an example
with swimlanes
72
Final Remark
 Other diagrams (will be covered in their respective chapters)
 State chart/ Activity
 Collaboration/ Sequence
 Component
 Deployment
End of Chapter 2
Exercises
 (1) Sketch a sequence diagram for the “normal” operation of an
ATM (i.e. a customer inserts the card, enters his/her PIN, enters
the amount, takes the card, and takes the money). The sequence
diagram should show the interaction between the different
components of the ATM.
 (2) Online customer can browse or search items, view specific
item, add it to shopping cart, view and update shopping cart, do
checkout. User can view shopping cart at any time. Design an
activity diagram for the above scenario.
 (3) The sequence diagram below (see slide no 78) models an
interaction that occurs when a customer orders a product . After
carefully reviewing the diagram, explain in English what is
happening in the interaction.
ATM machine sequence diagram
Online Shopping activity diagram
Process order Activity diagram
/Alpine
Exercise 2
 The user chooses to add a new appointment in the UI. The UI
notices which part of the calendar is active and pops up an Add
Appointment window for that date and time. The user enters the
necessary information about the appointment's name, location,
start and end times. The UI will prevent the user from entering an
appointment that has invalid information, such as an empty name or
negative duration. The calendar records the new appointment in the
user's list of appointments.
 Any reminder selected by the user is added to the list of reminders.
If the user already has an appointment at that time, the user is
shown a warning message and asked to choose an available time or
replace the previous appointment. If the user enters an
appointment with the same name and duration as an existing group
meeting, the calendar asks the user whether he/she intended to join
that group meeting instead. If so, the user is added to that group