ISOM3210

Information Systems Analysis and Design

Lecture 10:
Sequence Diagram

Agenda
Understand the rules and style guidelines for
sequence diagram
Understand the processes used to create
sequence diagram

Sequence Diagrams
Visualize how actors participate in an use
case and how messages trigger methods
of different classes in sequence
One sequence diagram usually shows a
single scenario of a use case
Must be consistent with the underlying
use case and class diagram
Note: Sequence diagram can include important messages transmitted
between actors
3

Sample Sequence Diagram

Patient

Receptionist

Patient

Unpaid Bill

Appointment

Lookup_Patient()
Lookup_Bills()

Timeslot Inquiry
Appointment Timeslot
Search_Appointment_Timeslot()
Insert_Appointment()
Confirmation
4

Sequence Diagram Syntax

Messages in Sequence Diagram

Actor-Actor: Simple information
Actor-Class: Actor trigger the methods of a
Class
Class-Actor: Class returns information to Actor
(it can be dropped if this message is the direct
response of immediately preceding methods)
Class-Class: One class triggers the method of
the other class
6

Sequence Diagram (Sunny Day): Handle Reservations (UC004)

System Boundary
Staff
Member

Member

Reservation

Administrator
login()

request for
resident card
resident card
scan/retrieve()
viewReservation
Detail()

confirmation of
reservation
acknowledgement

updateStatus()
notification after
using the facility
updateStatus()
logoff()
7

Use Case Diagram

Class Diagram

Whole System
STUDENT
STU_ID
STU_LName
STU_FName
STU_Uid
STU_Pwd

Creates/created by

SERVICE_STAFF
SRV_StaffID
SRV_LastName
SRV_FirstName
SRV_Username
SRV_Password
Login ()
Logout()

Login()
Logout()

OWNER
OWN_ID (Email)
OWN_LName
OWN_FName
OWN_Phone

Sequence Diagram

0..*

owns/is owned by
1

Insert_Owner()
Read_Contact()

0..10

SHORTLISTING_RECORD
SR_ID
SR_STU_ID
SR_APT_ID
SR_Date
SR_Status
Add_Record()
Delete_Record()
Update_Status()
Retrieve_List()

1..*

Includes/is included in
1
APARTMENT
APT_ID
APT_Loc
APT_Bedroom
APT_Rent
APT_PostingDate
APT_OWN_ID
Insert_Apartment()
Email_Owner()
Delete_Apartment()
Match_Search_Criteria()

Sunny Day Scenario of UC-004 Handle Reservation Use Case

Agenda
Understand the rules and style guidelines for
sequence diagram
Understand the processes used to create
sequence diagram

Steps to Build Sequence Diagrams

1. Select one use case scenario

E.g., Making a new appointment for an existing patient for

the Make Appointment use case
There can be another scenario in the same use case, e.g.,
Making a new appointment for a new patient

2. Identify actors and classes (objects) involved in the

scenario

E.g., Actor: Patient, Receptionist

Class: Patient, Appointment, Unpaid Bills

3. Add messages

Send information from one actor/object to another

A message can be either in the form of information or method

No parentheses () for the labels of information

Look for methods relevant to the use case scenario

10

Sequence Diagram Consistent with Use

Case and Class Diagram

Use Cases
UC-004
Handle Reservations

Actors
Administrator
Member

Classes and Methods

Staff
: login(), logout()
Member : scan/retrieve()
Reservation: viewReservationDetail()
updateStatus()

1
1

Exercise #1

Create sequence diagrams for the use cases of

the campus housing system (Sunny day only)
Campus Housing System
UC-100
Search
Apartment

Student

UC-200
Add
Apartment
Service Staff

UC-300
Delete
Apartment

Owner
IUC-001
Validate
Login

EUC-001
Shortlist
Apartment
12

Class Diagram
STUDENT
STU_ID
STU_LName
STU_FName
STU_Uid
STU_Pwd

Creates/created by
1

SERVICE_STAFF
SRV_StaffID
SRV_LastName
SRV_FirstName
SRV_Username
SRV_Password
Login ()
Logout()

Login()
Logout()

OWNER
OWN_ID
OWN_LName
OWN_FName
OWN_Phone
OWN_Email

Insert_Owner()
Read_Contact()

0..10

0..*
Includes/is included in

owns/is owned by
1

SHORTLISTING_RECORD
SR_ID
SR_STU_ID
SR_APT_ID
SR_Date
SR_Status
Retrieve_List()
Add_Record()
Delete_Record()
Update_Status()

1..*

1
APARTMENT
APT_ID
APT_Loc
APT_Bedroom
APT_Rent
APT_PostingDate
APT_OWN_ID
Insert_Apartment()
Email_Owner()
Match_Search_Criteria()
Delete_Apartment()
13

UC-100: Search for Apartment

1.
2.
3.
4.
5.
6.
7.

8.
9.
10.

Include IUC-001 validate login

System presents student the main menu
Student selects the Search for Apartments option
System asks student to enter the criteria (e.g., desired location, number of bedrooms, and
price range)
Student enters the criteria and presses Search
System checks the availability of apartments that match the criteria in the database
If no matching apartments
7.1 System notifies student there is no matching apartment
7.2 Exit use case
System displays a list of all matched apartments and the contact information of the
apartment owners
If student wants to add apartments to a favorite list, extend to EUC-001
Student logs off the system

14

IUC-001: Validate Login

Use Case ID

IUC-001

Use Case

Validate Login

Description

User logs in and gets authenticated

Including Use
Cases

UC-100 Search Apartment; UC-200 Add Apartment; UC-300

Delete Apartment

Flow of Events

1.
2.
3.
4.

Alternative Flows

NA

Priority

High

Non-Functional
Requirements

NA

Assumptions

NA

System prompts user for username and password

User enters username and password
System verifies user
If password is incorrect
4.1 Go back to step 1

15

EUC-001: Shortlist Apartment

Use Case ID

EUC-001

Use Case

Shortlist Apartment

Actors

(P) Student

Description

Students can add or remove apartments to or from a favorite list.

Students can add up to 10 apartments to the favorite list.

Use Cases being

Extended

UC-100 Search Apartment

Flow of Events

1 System displays the favorite list

2 Student adds or removes apartments to or from the list
3 If student adds more than 10 apartments
3.1 System notifies student a favorite list contains no more than
10 records
3.2 Back to step 1

Alternative Flows

NA

Priority

Low

Non-Functional
Requirements

The interface is user friendly, easy to add or remove apartments to

or from a favorite list

Assumptions

NA

16

Sequence Diagram: UC-100 Search

Apartment without Shortlist Function
Student

Student

Apartment

Owner

Login()
Match_Search_Criteria()
Read_Contact()

Logout()

17

Sequence Diagram Consistent with Use

Case and Class Diagram
Use Cases

Actors

Classes and Methods

Student : login(), logout()
Apartment: Match_Search_Criteria()
Owner
: Read_Contact()

Search for Apartment Student

Student

Student

Apartment

Owner

Login()
Match_Search_Criteria()

Read_Contact()
Logout()

18

UC-200: Add Apartment

1.
2.
3.
4.
5.

6.
7.
8.
9.
10.
11.

12.
13.
14.

Include IUC-001 validate login

System presents service staff the main menu
Service staff selects the Add Apartments option
Service staff enters owners telephone number (assuming no typos) to retrieve owners information
from the system for verification
If owner is not found
5.1 System notifies service staff owner is not found and directs service staff to a screen that allows
service staff to enter new owners information
5.2 Service staff enters owners information (e.g., owner first name and last name, telephone number
and email address) into the database (assuming no typos)
5.3 Go to step 8
System displays owners information
Service staff verifies owner by comparing owners information retrieved from the system with that in
the Add Apartment Request Form (assuming the information always matches)
System asks service staff to enter apartments information (e.g., owner, location, number of bedrooms,
and monthly rent) with posting date
Service staff enters apartments information
Service staff presses Add Record to complete the transaction
If an existing record for the apartment to be inserted is found
12.1 System notifies service staff that a record for the apartment to be inserted already exists
12.2 Go to step 2
System inserts apartments information into the database
System notifies owner via email that apartments information has been successfully added
Service staff logs off the system
19

Sequence Diagram: UC-200 Add Apartment

Owner

Service Staff

Service_Staff

Owner

Apartment

Login()
Read_Contact()
Insert_Apartment()
Email_Owner()
Read_Contact()
Email_Notification
Logout()

20

Sequence Diagram Consistent with Use

Case and Class Diagram
Use Cases

Actors

Add Apartment

Owner
Service Staff

Owner

Service Staff

Classes and Methods

Service_Staff: login(), logout()
Owner
: Read_Contact(),
Apartment : Insert_Apartment()
Email_Owner()

Service_Staff

Owner

Apartment

Login()
Read_Contact()
Insert_Apartment()

Email_Owner()
Read_Contact()

Email_Notification
Logout()

21

UC-300: Delete Apartment

1.
2.
3.
4.

Include IUC-001 validate login

System presents service staff the main menu
Service staff selects the Delete Apartments option
Service staff enters owners phone number (assuming no typos) to retrieve
owners information from the system for verification
5. If owner is not found
5.1 System notifies service staff owner is not found
5.2 Exit use case
8. Service staff deletes apartment from the database accordingly
9. The corresponding entry in the shortlisting record will be updated as expired
10. System notifies owner via email that apartments information is successfully
deleted
11. Service staff logs off the system

22

Sequence Diagram: Delete Apartment

Owner

Service Staff

Service_Staff

Owner

Apartment

Shortlisting_
Record

Login()

Read_Contact()

Delete_Apartment()
Update_Status()

Read_Contact()

Email_Owner()

Email_Notification
Logout()

23

Sequence Diagram Consistent with Use

Case and Class Diagram
Use Cases

Actors

Delete Apartment

Owner

Owner
Service Staff

Service Staff

Classes and Methods

Service_Staff
Owner
Apartment

: login(), logout()
: Read_Contact()
: Delete_Apartment()
Email_Owner()
Shortlisting_Record: Update_Status()

Service_Staff

Owner

Apartment

Shortlisting_
Record

Login()
Read_Contact()
Delete_Apartment()

Update_Status()
Read_Contact()
Email_Notification

Email_Owner()

Logout()
24

Side Note: When a Method is Initiated within the

System, Which Object Should be Chosen as the Initiator

The enclosing method starts or calls the enclosed method. The initiator of the
enclosed method thus is the owner of the enclosing method.

A sequence of
instructions

Delete_Apartment()
{

Update_Status()
Email_Owner()

Update_Status()
{

The nested structure

for the third exercise

Read_Contact()
{

Email_Owner()
{

}
Read_Contact()

}
A simple rule that works generally well: use the recipient of the last method as the
25
initiator of the current method.

Summary
After todays class, you should
Be able to create sequence diagrams based on use
cases and class diagrams

26

Next Class
Behavioral state machine diagram
Reading:
Textbook Ch. 6

27