Lecture 10 - Sequence Diagrams _v3

ISOM3210Information Systems Analysis and Design

Lecture 10:

Sequence Diagram

1

Agenda

• Understand the rules and style guidelines for sequence diagram

• Understand the processes used to create sequence diagram

2

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

3

Note: Sequence diagram can include important messages transmitted between actors

Sample Sequence Diagram

4

PatientUnpaid Bill

Receptionist

Lookup_Bills()

Appointment

Insert_Appointment()

Patient

Lookup_Patient()

Confirmation

Search_Appointment_Timeslot()

Appointment Timeslot

Timeslot Inquiry

Sequence Diagram Syntax

5

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

MemberReservation

Sequence Diagram (Sunny Day): Handle Reservations (UC-004)

Administrator

viewReservationDetail()

request for resident card

Member

scan/retrieve()

7

Staff

login()

logoff()

resident card

confirmation ofreservation

acknowledgementupdateStatus()

notification afterusing the facility

updateStatus()

System Boundary

Use Case Diagram

8

Class Diagram

Sunny Day Scenario of UC-004 Handle Reservation Use Case

Whole System

Sequence Diagram

0..*

1

STUDENTSTU_IDSTU_LNameSTU_FNameSTU_UidSTU_Pwd

Login()Logout()

OWNEROWN_ID (Email)OWN_LNameOWN_FNameOWN_Phone

Insert_Owner()Read_Contact()

APARTMENTAPT_IDAPT_LocAPT_BedroomAPT_RentAPT_PostingDateAPT_OWN_ID

Insert_Apartment()Email_Owner()Delete_Apartment()Match_Search_Criteria()

SHORTLISTING_RECORDSR_IDSR_STU_IDSR_APT_IDSR_DateSR_StatusAdd_Record()Delete_Record()Update_Status()Retrieve_List()

Creates/created by

1 0..10

owns/is owned by

1 1..*

Includes/is included in

SERVICE_STAFFSRV_StaffIDSRV_LastNameSRV_FirstNameSRV_UsernameSRV_PasswordLogin ()Logout()

Agenda

• Understand the rules and style guidelines for sequence diagram

• Understand the processes used to create sequence diagram

9

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 Actors Classes and Methods

UC-004 Handle Reservations

AdministratorMember

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

updateStatus()

11

Exercise #1• Create sequence diagrams for the use cases of

the campus housing system (Sunny day only)

12

UC-100Search

Apartment

UC-200Add

Apartment

UC-300Delete

Apartment

Student

Owner

Service Staff

Campus Housing System

EUC-001Shortlist

ApartmentIUC-001Validate

Login

0..*

1

STUDENTSTU_IDSTU_LNameSTU_FNameSTU_UidSTU_Pwd

Login()Logout()

OWNEROWN_IDOWN_LNameOWN_FNameOWN_PhoneOWN_Email

Insert_Owner()Read_Contact()

APARTMENTAPT_IDAPT_LocAPT_BedroomAPT_RentAPT_PostingDateAPT_OWN_ID

Insert_Apartment()Email_Owner()Match_Search_Criteria()Delete_Apartment()

Class Diagram

SHORTLISTING_RECORDSR_IDSR_STU_IDSR_APT_IDSR_DateSR_StatusRetrieve_List()Add_Record()Delete_Record()Update_Status()

Creates/created by

1 0..10

owns/is owned by

1 1..*

Includes/is included in

13

SERVICE_STAFFSRV_StaffIDSRV_LastNameSRV_FirstNameSRV_UsernameSRV_PasswordLogin ()Logout()

UC-100: Search for Apartment

1. Include IUC-001 validate login

2. System presents student the main menu

3. Student selects the “Search for Apartments” option

4. System asks student to enter the criteria (e.g., desired location, number of bedrooms, and price range)

5. Student enters the criteria and presses “Search”

6. System checks the availability of apartments that match the criteria in the database

7. If no matching apartments

7.1 System notifies student there is no matching apartment

7.2 Exit use case

8. System displays a list of all matched apartments and the contact information of the apartment owners

9. If student wants to add apartments to a favorite list, extend to EUC-001

10. Student logs off the system

14

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. System prompts user for username and password

2. User enters username and password

3. System verifies user

4. If password is incorrect

4.1 Go back to step 1

Alternative Flows NA

Priority High

Non-Functional

Requirements

NA

Assumptions NA

15

IUC-001: Validate Login

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

EUC-001: “Shortlist Apartment”

16

17

Sequence Diagram: UC-100 Search Apartment without Shortlist Function

Student Student Owner

Login()

Match_Search_Criteria()

Read_Contact()

Apartment

Logout()



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

18

Student Student Owner

Login()

Match_Search_Criteria()

Read_Contact()

Apartment

Logout()

UC-200: Add Apartment1. Include IUC-001 validate login

2. System presents service staff the main menu

3. Service staff selects the “Add Apartments” option

4. Service staff enters owner’s telephone number (assuming no typos) to retrieve owner’s information from the system for verification

5. 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 owner’s information

5.2 Service staff enters owner’s 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

6. System displays owner’s information

7. Service staff verifies owner by comparing owner’s information retrieved from the system with that in the “Add Apartment Request Form” (assuming the information always matches)

8. System asks service staff to enter apartment’s information (e.g., owner, location, number of bedrooms, and monthly rent) with posting date

9. Service staff enters apartment’s information

10. Service staff presses “Add Record” to complete the transaction

11. If an existing record for the apartment to be inserted is found12.1 System notifies service staff that a record for the apartment to be inserted already exists12.2 Go to step 2

12. System inserts apartment’s information into the database

13. System notifies owner via email that apartment’s information has been successfully added

14. Service staff logs off the system 19

Owner

Sequence Diagram: UC-200 Add Apartment

Service Staff

Email_Owner()

Insert_Apartment()

Apartment

20

Service_Staff

Login()

Logout()

Owner

Read_Contact()

Email_Notification

Read_Contact()



Add Apartment OwnerService Staff

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

Email_Owner()

21

Owner ApartmentService Staff

Read_Contact()

OwnerService_Staff

Login()

Logout()

Email_Owner()

Email_Notification

Insert_Apartment()

Read_Contact()

UC-300: Delete Apartment

1. Include IUC-001 validate login

2. System presents service staff the main menu

3. Service staff selects the “Delete Apartments” option

4. Service staff enters owner’s phone number (assuming no typos) to retrieve owner’s 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 apartment’s information is successfully deleted

11. Service staff logs off the system

22

OwnerOwner Apartment

Shortlisting_Record

Read_Contact()

Sequence Diagram: Delete Apartment

Service Staff

Delete_Apartment()

Update_Status()

23

Service_Staff

Login()

Logout()

Email_Notification

Email_Owner()Read_Contact()



Delete Apartment OwnerService Staff

Service_Staff : login(), logout()Owner : Read_Contact() Apartment : Delete_Apartment()

Email_Owner()Shortlisting_Record: Update_Status()

24

Owner Owner Apartment

Shortlisting_Record

Read_Contact()

Service Staff

Delete_Apartment()

Update_Status()

Service_Staff

Login()

Logout()

Email_Owner()Email_Notification

Read_Contact()

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 simple rule that works generally well: use the recipient of the last method as the initiator of the current method. 25

Delete_Apartment(){

… … …… … …Update_Status()Email_Owner()… … …… … …

}

Update_Status(){

… … …… … …

}A sequence of instructions

Email_Owner(){

… … …… … …Read_Contact()… … …… … …

}

Read_Contact(){

… … …… … …

}

The nested structure for the third exercise

Summary

• After today’s 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

Lecture 10 - Sequence Diagrams _v3

Documents

Transcript of Lecture 10 - Sequence Diagrams _v3