Software Engineering Design &

Modeling
Sequence Diagram
Communication Diagram
Timing Diagram
 Introduction
 We started looking at the static aspects of
UML models in the earlier chapters – classes
and objects diagrams
 In previous chapter, we began to explore the
dynamic aspects of UML model – use case
diagrams
 In this chapter, we are going to see how to
look at the static and dynamic aspects of a
system in parallel.

2
 Chapter Outline
 Interactions
 Definition
 Messages and actions
 Sequencing
 Modelling an interaction
 Interaction diagram
 Sequence diagram
 Collaboration diagram
 Timing diagram
 Robustness Analysis
 Case Study

3
Interactions
 Introduction
 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

5
 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

6
 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

7
 There are 5 kinds of actions that the UML
explicitly supports: -
 Call and Return
 Create and Destroy

 Send

8
 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

A call action that involves
action name two objects

A lifeline
action name
A call action from an object
to itself

9
 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

10
Example :- Call and Return action

: Customer : CustomerReview
assignRating()

computeAvgRating()

average rating

11
  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 Object: Class

<<create>> create an object

: Class

UML 1.x UML 2.0

12
 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>> (UML 1.x) 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>>
X

13
 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 : Class Object: Class

action name action name

UML 1.x UML 2.0

14
 In the UML, a signal is represented as stereotyped classes
or as signals that objects belonging to a given class can
respond to.
<<signal>> Class
Signal

attribute : type
Signals
Signal

 The attributes of a signal serve as the signal’s parameters when an

object sends the signal to another object
 The extra compartment in the class box contains the names of the
signals to which objects of a given class can respond to.
 Will learn more about signals in later chapters…

15
Example: A send action, with its sample signal

: Login Page : Exception

Handler

BadPassword(userID)

<<signal>> ExceptionHandler
BadPassword

userID : String
Signals
BadPassword

16
 Asynchronous message
 A message is sent by one object to another but the first object does not wait
until the resulting action has completed, it carries on with the next step in its
own sequence of actions.
 Synchronous message
 A message is sent by one object to another and the first object waits until the
resulting action has been completed.
 Creation message
 Represents a message that causes the creation of an object instance to which
the message is sent.
 Reply message
 Represents the explicit return of control from the object to which the message
was sent.
 Lost message
 Have a send event but the receive event is unknown, normally because they do
not reach their destination.
 Found message
 Have a receive event, but their origin is unknown, possibly, because it is
outside the scope of the description.
17
 Sequencing
 When an object passes a message to another object,
the receiving object might in turn send a message to
another object, which might send a message to yet a
different object, and so on.
 This stream of messages forms a sequence
 Any sequence
 must have a beginning: the start of every sequence is
rooted in some process or thread
 will continue as long as the process or thread that owns it
lives

18
 Each process or thread within a system
defines a distinct flow of control, and within
each flow, messages are ordered in sequence
by time
 The order of the message relative to the start of
the sequence can be modelled by prefixing the
message with a sequence number, set apart by a
colon separator
 A filled solid arrowhead is used to specify a procedural
or nested flow of control
 A stick arrowhead is used to specify a flat flow of
control, to model the non-procedural progression of
control from step to step

19
 sequence number message

2 : clickAt() 2.2 : putRecentPick()

: View c : Controller : Cache

nested flow of control

2.1 : findAt()

link

sequence number message

1 : liftHandset() 2 : assertCall()
c : Caller : Telephone : Exchange

flat flow of control

20
 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
 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 : communication diagram
 Both sequence and communication diagram are examples of
interaction diagrams

21
Interactions diagram
 Introduction
 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
 Interaction diagrams can also be attached to
 use cases : to model scenarios
 collaborations : to model the dynamic aspects of a society
of objects

23
 Definition
 An interaction diagram shows an interaction,
consisting of a set of objects and their relationships,
including the messages that may be dispatched
among them.
 An interaction diagram contains: -
 objects
 links
 messages
 may also contain notes and constraints.

24
 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 and Timing Diagram are 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
 Communication Diagram is used to model this

25
 Sequence diagram
 A sequence diagram is an interaction diagram
that emphasizes the time ordering of messages
(sequence of calls).
 A sequence diagram is formed by: -
1. Placing the objects that participate in the interaction at
the top of the diagram, along the X-axis
 The object that initiates the interaction is placed on the left
most, and the other subordinate objects are placed to the right
2. Placing the messages that these objects send and
receive along the Y-axis, in order of increasing time
from top to bottom

26
 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
 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

27
Notations of Sequence Diagrams
 Frames
 Sequence diagrams are drawn in frames. Frames
are new in UML 2.0.
lifeline
heading
sd Interanction name

Content
time area

28
 Lifelines
 Participating instances are represented in a
sequence diagram by a dashed vertical line with,
usually, a rectangle representing an object at the
top of the line.
lifeline name

29
 Messages
 As previous slide

30
 Combined fragments
 alt
 Alternatives : a choice in which at most one operand’s
condition will evaluate to true.
 opt
 Option : a choice in which either this fragment will
execute or it will not, depending on whether the
operand’s condition evaluates to true.
 loop
 Loop : used to show that a fragment will be executed
repeatedly

31
 break
 par
 seq
 strict
 neg
 critical
 ignore
 consider
 assert

32
 Interaction occurrences
 Another way of hiding detail in sequence diagrams
has been introduced in UML 2.0 with the use of
interaction occurrences.

ref

33
 States
 States can be placed on a lifeline to indicate the
state that an object must be in as a pre-condition of
an action or that it makes a transition to as the
post-condition of an action.

idle

Messages that take times to reach

their destinations
34
 objects

C : Client p : ODBCProxy

create a transaction
: Transaction

setActions(a, d, o)
setValues(d, 3, 4)

time setValues(a, “CO”)

committed

<<destroy>> lifeline
X
focus of control

Example of a sequence diagram

35
 Communication diagram
 A communication diagram is an interaction diagram
that emphasizes the structural organization of the
objects that participate in an interaction (send and
receive messages) (emphasize on links).
 A communication diagram is formed by:-
1. Placing the objects that participate in the interaction as the
vertices in a graph
2. Rendering the links that connect these objects as the arcs
of this graph
3. Adorning these links with the massages that the objects
send and receive

36
 A communication has four key elements: -
 Objects appear at the vertices of the graph
 Paths that indicate how one object is linked to another
 A path stereotype can be attached to the far end of a link, e.g.
<<local>>, <<parameter>>, <<global>>, and <<self>>

 Sequence number to indicate the time order of a message

 Each message is prefixed with a unique sequence number
 The UML standard is decimal numbering ( 1 is the first message;
1.1 is the first message nested in the first message; and so on)
 Messages show the actions that objects perform on each
other and on themselves

37
 objects
C : Client

link 1 : <<create>>
2 : setActions(a, d, o)
3 : <<destroy>>
<<local>>
<<global>
: Transaction > p : ODBCProxy
2.1 : setValues(d, 3, 4)
message
path stereotype 2.2 : setValues(a, “CO”)

sequence number

Example of a collaboration diagram

38
 A communication may also show iteration
and branching
 To model an iteration, prefix the sequence
number of a message with an expression that
begins with *, e.g. *[ i := 1..n ], or with just an *
 To model a condition, prefix the sequence
number of a message with a condition clause, e.g
[x>0]

39
 Semantic Equivalence
 Both sequence and communication diagrams
are semantically equivalent
 A sequence diagram can be converted into a
communication diagram, and vice versa, without
any loss of information
 However, this does not mean that both diagrams
will explicitly visualize the same information

40
C : Client p : ODBCProxy

transaction : Transaction

setActions(a, d, o) semantically
setValues(d, 3, 4)
equivalent
setValues(a, “CO”)
committed

C : Client

1 : <<create>>
2 : setActions(a, d, o)
3 : <<destroy>>
<<local>>
<<global>>
: Transaction p : ODBCProxy
2.1 : setValues(d, 3, 4)
2.2 : setValues(a, “CO”)

41
 You built sequence diagrams or communication
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 communication 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 communication diagram, MUST have
its corresponding class in the class diagram

42
 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

43
 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
44
 :Customer :HomePage :LoginPage :Account

The Customer clicks clickLogin( )

the Login button on
the Home Page display( )
The system displays
the Login Page

The Customer enters

enter userID
his or her user ID and password
and password, and
then clicks the OK clickOK( )
button. validateLogin(userID
, password)
The system validates
the login information login OK
against the persistent
Account data …
display( )
… and then returns the
Customer to the Home
Page.

Sequence Diagram
45
 1 : clickLogin( )
:HomePage
:Customer
3 : enter userID and password
4 : clickOK( )

6 : display( ) 2 : display( )

:Account :LoginPage
5 : validateLogin(userID, password)

Communication Diagram

46
 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.
 In the previous example, we discovered that the only object in the
interaction diagrams that has its corresponding class in the class
diagram in Account.
 There is no HomePage and Log-in Page class in the class diagram
(refer to Case Study in Chapter 5)
 To solve this problem, we can perform robustness analysis
47
 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.

48
 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

49
 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

50
 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

51
 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.
 We need to also modify our previous class diagram to
reflect this changes.
 Analysing our previous class diagram, we would realised
that we have only included entity objects.
 We now need to also include our boundary objects.
 The changes is reflected in the Case Study

52
 :Customer :HomePage :LoginPage :Account

The Customer clicks clickLogin( )

the Login button on
the Home Page display( )
The system displays
the Login Page

The Customer enters

enter userID
his or her user ID and password
and password, and
then clicks the OK clickOK( )
button. validateLogin(userID
, password)
The system validates
the login information login OK
against the persistent
Account data …
display( )
… and then returns the
Customer to the Home
Page.

Sequence Diagram
53
 1 : clickLogin( )
:HomePage
:Customer
3 : enter userID and password
4 : clickOK( )

6 : display( ) 2 : display( )

5 : validateLogin(userID, password)
:Account :LoginPage

Communication Diagram

54
 Expressing time on Interaction
Diagram
 It is often useful to enhanced interaction diagram by
specifying time-related requirements, esp. when the
system being modelled involves real-time operation
or geographic distribution.
 The UML defines the following time specific term: -
 Time expression
 Timing mark
 Timing constraint

55
 Definitions: -
 A time expression is an expression that resolves
to a relative or absolute value of time once it’s
evaluated
 A timing mark is a time related name or label on
a message
 A timing constraint is a condition that must be
satisfied with regard to time. It usually contains
 a time expression
 a timing mark

56
Example: - Timing on a Sequence diagram

timing mark

v : validateLogin(userID, password)
: LoginPage : Account
{ v.executionTime < 3 sec}

time expression

timing constraint

 There exist a timing mark on the message validateLogin(…).

 The timing constraint in the above example, uses a timing mark
(v) and a time expression (executionTime < 3).

57
 Timing Diagram
 Timing diagrams are another form of interaction
diagram, where the focus is on timing constraints:
either for a single object or, more usefully, for a
bunch of objects.
 When to use timing diagram?
 Timing diagrams are useful for showing timing constraints
between state changes on different objects.
 The diagrams are particularly familiar to hardware
engineers.

58
 Graphic nodes and paths
 Frame
 Notation
 Focuses on the observable exchange of information
between connectable elements.
 Message
 Notation
 Messages come in different variants depending on what
kind of Message they convey.
 There are 5 types of messages in this diagram.

59
 1. Asynchronous Messages
2. Synchronous Messages
3. Object creation Message
4. Lost Messages
5. Found Messages
 Message Label
 Notation
 Labels are only notational shorthands used to prevent cluttering
of the diagrams with a number of messages crisscrossing the
diagram between Lifelines that are far apart.
 The labels denote that a message may be disrupted by introducing
labels with the same name.

60
 State or condition timeline
 Notation
 This is the state of the classifier or attribute, or some
testable condition, such as an discrete enumerable
value. It is also permissible to let the state-dimension be
continuous as well as discrete. This is illustrative for
scenarios where certain entities undergo continuous
state changes, such as temperature or density.
initialising

acquiring
reporting
idle
61
 General value lifeline
 Notation On Off
 Shows the value of the connectable element as a
function of time. Value is explicitly denoted as text.
Crossing reflects the event where the value changed.
 Lifeline
 GeneralOrdering
 Notation
 To describe that one occurrence must occur before the
other in a valid trace.
 Destruction Event
62
Example

63
64
 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.

65
 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

66
 To model a communication diagram: -
 Set the context for the interaction
 Whether it is a system, subsystem, operation, class or a scenario of a
use case or communication
 Identify which objects play a role in the interaction
 Place them as vertices in the graph
 May set the initial properties (e.g attribute values, tagged values, state
or role) for each of the object
 Specify the links among these objects, along which messages
may be passed
 Starting with the message that initiates the interaction, attach
each subsequent message to the appropriate link, setting its
sequence number as appropriate
 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

67
Case Study: On-Line
Bookstore (cont…)
 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

69
 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
 Remember that each object MUST have its
corresponding classes in the class diagram

70
 On-line Bookstore System

Register

<<extend>>
(CustID) Check out

Customer Order books

<<include>>

<<include>>
Sell used books Log-in

<<include>>

Use Case Functional Review books

Requirements
Diagram
71
 Book
bookId: String 1 has
title: String
…

Order 1..* 1..*

orderId: String UsedBook Review
bookId: String
userId: String bookId: String
userId: String
quality: String review: String
quantity:
… …

order
Integer
status: String
calcAvgRating()
1..* 1..* 1..*
Customer

sell

make
Account userId: String
has name: String 1
userId: String
password: String 1..* 1 e-mail: String
… 1

checkPassword()

72
 Log-in

:Customer :HomePage :LoginPage :Account

The Customer clicks clickLogin( )

the Login button on
the Home Page display( )
The system displays
the Login Page

The Customer enters

enter userID
his or her user ID and password
and password, and
then clicks the OK clickOK( )
button. validateLogin(userID
, password)
The system validates
the login information login OK
against the persistent
Account data …
display( )
… and then returns the
Customer to the Home
Page.
73
 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

74
 Register

:Customer :HomePage :RegisterPage

The customer clicks
the REGISTER button clickRegister( )
on the Home Page
The system displays
the Register Page display( )

The Customer enters

the required
information and enter information
then clicks the
SEND button.
clickSEND( ) verify info
The system checks
that all of the required
information were
entered. If yes, the create
system updates the :Account
CUSTOMER’s record
in the CUSTOMER create
and ACCOUNT tables display( ) :Customer
in the database. The
system displays OK 75
message
 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
76
 Order books

:Customer :HomePage :Book :Order

The CUSTOMER
enters the keyword for
a book and clicks the enters keyword
SEARCH button on the
personal Home Page
clickSearch( )
search( )
The system displays
the matching books on displayMatch( )
the web Page
The CUSTOMER
chooses the desired
book and clicks the
ADD TO choose books
SHOPPING CART
button on the web clickAdd()
page.
create
The system adds the
book into the
CUSTOMER’s Order
addBook( )
table in the database.

77
 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
 Customer and Order: entity objects 78
:Customer :HomePage :Order :InvoicePage :Customer :DeliveryPage
clickCheckOut( )
retrieve()
display( )

verify info
clickProceed( )
display( )

enter credit card info

clickOK()
validate( )

display( )

choose destination
clickOK()
display()
confirm and clickOK () 79
 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

80
Sell used books

:Customer :HomePage :UsedBooksPage :ConfPage :Customer :UsedBook

clickUsedBooks( )

display( )

enter book info

clickSend( )
display( )

verify info
clickOK( )
add( )

add( )
81
 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?
82
 The class diagram that was built before needs
to be changed in order to reflect the changes
that took place.
 We need to add the boundary objects into the class
diagram, and also the relationships between the old
objects and the added ones.
 Each operations performed in the sequence
diagram must be shown in the respective classes
 Each data entered must also be shown in the
respective classes
83
 The objects identified: -
 Entity objects:
 Account, Customer, Book, Used Book, Order, Review
 Boundary objects
 Home Page, Log-in Page, Register Page, Invoice Page,
Delivery Page, Used Book Page, Confirm Page, Book
Detail Page and Review Page
 The modified class diagram

84
85
The End