ISOM3210 Information Systems Analysis and Design Lecture 10: Sequence Diagram 1
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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()
Sequence Diagram Consistent with Use Case and Class Diagram
Use Cases Actors Classes and Methods
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()
Sequence Diagram Consistent with Use Case and Class Diagram
Use Cases Actors Classes and Methods
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()
Sequence Diagram Consistent with Use Case and Class Diagram
Use Cases Actors Classes and Methods
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
Related Documents
