Computer Science Homework Help

TU Healthcare System Software Engineering Project

 

2.1. Log-in

  • Use case name: Login
  • Summary: Existing patients can log in to their accounts.
  • Actor: Patient
  • Precondition: Idle interface displayed on the screen
  • Description of the main sequence:
  1. User select Log-in button
  2. The user provides an account ID and password and proceeds to log in to the system
  3. The system retrieves patient’s account information and checks if the account is valid
  4. If the account is valid, System continues to check if the password matches the account ID
  5. If the password matches with the account ID, the system grants access to the user
  6. The system rolls back to the homepage interface
  • Alternatives:
  • Step 1: The user doesn’t have an account yet and clicks on the sign-up button
  • Step 2: If the account ID doesn’t exist, then roll back to the log-in interface. The system raises notification of invalid accounts and requires to retype of the information.
  • Step 3: If the password doesn’t match with the account ID, then roll back to the log-in interface. The system raises notifications of incorrect passwords and requires to retype of the information.
  • Postcondition: User has logged in into the system

2.2. Sign up

  • Use Case Name: Sign up
  • Summary: Patient signs up for an account to access the healthcare system by creating a username and password.
  • Actor: Patient
  • Precondition: Patient access the sign-up interface
  • Description:
  1. The patient provides the mandated information( account ID, password, date of birth, full name, email) and unmandated information(medical history, address, phone number,…)
  2. System checks if all the mandated information has been filled up
  3. The system verifies if accountID is available
  4. The system verifies if the password meets the security requirement
  5. System checks if the re-typed password matches the password
  6. After meeting all the registration requirements, the user is given access to the online system.
  • Postcondition: User has registered a new account on the system

2.3. Appointment

  • Use Case Name: Appointment
  • Summary: Customer or Staff select “Appointment” section in the application
  • Actor: Customer, Staff
  • Precondition: Idle interface displayed on the screen
  • Description of the main sequence:

1. Tap in the Appointment button in the interface

2. System loads the Appointment interface

3. User access the Appointment section

  • Postcondition: The user has accessed the Appointment section and can proceed to take further actions pertaining to the appointment.

2.4. Make an Appointment

  • Use Case Name: Make Appointment
  • Summary: User schedules appointment for a patient with an available doctor in the hospital via the system
  • Dependency: Extends Appointment
  • Actor: Customer, Staff
  • Precondition: System displays Appointment interface
  • Description of the main sequence:
  1. <Appointment>
  2. User selects Make Appointment
  3. The user provides the patient’s information(Full name, phone number)
  4. Check doctor’s available time, and choose the selected date and time
  5. Once finishing opting the information needed, the user completes the process by select Submit
  6. The system saves the appointment record
  • Postcondition: The user has scheduled an appointment with the doctor. The system saves the appointment record under an auto-generated appointment ID.

2.5. Cancel Appointment

  • Use Case Name: Cancel Appointment
  • Summary: User cancel appointments
  • Dependency: Extends Appointment
  • Actor: Patient, Staff
  • Precondition: System displays Appointment interface
  • Description of the main sequence:
  1. <Appointment>
  2. User selects Cancel Appointment
  3. The user provides the patient’s information(Full name, phone number)
  4. The system retrieves information, check if the patient’s information correct
  5. If the provided patient’s information is corrected, display the correspondent appointment which has been scheduled.
  6. The User cancel an appointment by select Cancel
  7. System display the message of the cancel request has been sent
  • Alternative:
  • Step 4: If the patient’s information is not correct, roll back to the Cancel Appointment interface and display a notification showing that the user has provided incorrect information
  • Step 5: If the patient has scheduled more than one appointment, then display the scheduled appointments in order respectively. The patient can opt for one or more than one selection
  • Postcondition: The scheduled appointment has been canceled

2.6. Update Appointment

  • Use Case Name: Update Appointment
  • Summary: Patient updates/changes the appointment details
  • Dependency: Appointment
  • Actor: Patient
  • Precondition: System displays appointment interface
  • Description:
  1. Patient select Update Appointment
  2. The system displays a list of doctors, the patient can opt for the same doctor as before updating or another one
  3. After the select a doctor, the patient can choose the date/time that the doctor is available
  4. Patient commits update by select Update
  5. The update has been saved into the system
  • Postcondition: The appointment has been updated

2.7. Read Payment Information

  • Use Case Name: Read Payment Information
  • Summary: Staff access the payment information
  • Dependency: Include Login
  • Actor: Staff
  • Precondition: Idle interface displayed on the screen
  • Description of the main sequence:
  1. Staff selects Payment Information
  2. Staff searches up either the patient’s information or the payment ID to check the payment information
  3. System traverses through the database and retrieves the information
  4. The system displays the correspondent results
  5. Staff select a specific payment that needed to be looked up
  6. The system displays the payment information details
  • Postcondition: The payment information has been fetch

2.8. Create Record

  • Use Case Name: Create Record
  • Summary: Staff create a record for the new patient who just arrives at the hospital
  • Dependency: Include Login
  • Actor: Staff
  • Precondition: Idle interface displayed on the screen
  • Description of the main sequence:
  1. Staff clicks onto Create Record, system loads into Create Record session
  2. Staff fills in the patient’s information(name, address, phone number, email, SSN, insurance name)
  3. System checks if the identification(SSN) is unique
  4. If patient’s identification is unique, the system displays the message the record is successfully created and loads the patient’s record information that just has been created
  • Alternative:
  • Step 4: If the identification is unique, the system displays a message showing that the patient’s record has already been registered
  • Postcondition: The patient’s record has been created

2.9. Check Record

  • Use Case Name: Check Record
  • Summary: Staff checks the patient’s record
  • Dependency: Include Login
  • Actor: Staff
  • Precondition: Idle interface displayed on the screen
  • Description of the main sequence:
  1. Staff selects Check Record, systems loads the Check Record session
  2. Staff enters the patient’s information to look up for the record. The system retrieves the information
  3. If the system finds out the patient’s record, the system displays the patient’s record on screen
  • Alternatives:
  • Step 3: If the system cannot retrieve the patient’s record, displays a message that the system could not find any corresponding patient’s record
  • Step 3: If the system cannot retrieve the patient’s record, staff can select Sign Up to create a new record
  • Postcondition: The patient’s record has been fetch and displayed

2.10. Add Patient Record Into Doctor List

  • Use Case Name: Add Patient Record Into Doctor List
  • Summary: Staff adds a patient’s record into the list of patients for a doctors
  • Dependency: Include Check Record
  • Actor: Staff
  • Precondition: Patient record is displayed on the screen
  • Description of the main sequence:
  1. Staff click onto Add Patient Record
  2. The system loads a list of doctors, staff select one doctor who has an appointment with the patient
  3. The system displays messages of adding the record into the list successfully
  • Postcondition: Patient record has been added to the doctor’s list

2.11. Update Record

  • Use Case Name: Update Record
  • Summary: Staff update patient’s record
  • Dependency: Include Check Record
  • Actor: Staff
  • Precondition: Patient record is displayed on the screen
  • Description of the main sequence:
  1. Staff selects Update Record
  2. Staff updates the details of the patient’s record
  3. Once finished, staff saves records into the system
  4. The system rolls back to the patient’s record interface
  • Nonfunctional requirement:
  1. Update record constraint: Staff can update any field in a patient’s record but Treatment and Measurements.
  • Postcondition: The patient’s record has been updated

2.12. Deposit Customer’s Cash

  • Use Case Name: Deposit Customer’s Cash
  • Summary: Staff deposit customer’s cash for the treatment payment
  • Actor: Staff
  • Precondition: Idle interface displayed on the screen
  • Description of the main sequence:
  1. Staff selects Deposit Cash
  2. Staff inserts an amount of cash into the cash counter. The counter will display the amount of money that is already deposited
  3. Once finished, staff can hit the Done button
  4. System display message of successful deposit.
  • Postcondition: Cash has been deposited into the system.

————————————————————————————————————————————————-

4.1. Log-in

  • Use case name: Login
  • Summary: Nurse login into their accounts.
  • Actor: Nurse
  • Precondition: Idle interface displayed on screen
  • Description of main sequence:
  1. User select Log-in button
  2. User provide account ID and password, and proceed to log in the system
  3. System retrieve patient’s account information and check if the account is valid
  4. If the account is valid, System continue to check if the password matches with the account ID
  5. If password matches with account ID, system grants access for the user
  6. System rolls back to the homepage interface
  • Alternatives:
  • Step 1: User doesn’t have account yet and clicks on sign-up button
  • Step 2: If the account ID doesn’t exist, then roll back to the log-in interface. System raises notification of invalid account and require to retype the information. .
  • Step 3: If the password doesn’t match with the account ID, then roll back to the log-in interface. System raises notification of incorrect password and require to retype the information.
  • Postcondition: User has logged in into the system

4.2. Sign Up

  • Use Case Name: Sign up
  • Summary: Nurse signs up for an account to access the healthcare system by creating a username and password.
  • Actor: Nurse
  • Precondition: Patient access the sign-up interface
  • Description:
  1. Patient provides the mandated information( account ID, password, date of birth, full name, email) and unmandated information(medical history, address, phone number,…)
  2. System checks if all the mandated information has been filled up
  3. System verifies if accountID is available
  4. System verifies if the password meets the security requirement
  5. System checks if the re-typed password matches the password
  6. After meeting all the registration requirements, the user is given access to the online system.
  • Alternatives:
  • Step 3: Systems raises an error that accountID is invalid, requires user to retype
  • Step 4: The password doesn’t meet the security requirement, system requires user to retype
  • Step 5: Re-typed password doesn’t match the password, system requires user to retype the re-typed password
  • Postcondition: User has registered a new account on the system

4.3. Update Record

  • Use Case Name: Update Record
  • Summary : Doctor update patient’s record
  • Dependency: Include Check Record
  • Actor: Doctor
  • Precondition: Patient record is displayed on screen
  • Description of main sequence:
  1. Doctor selects Update Record
  2. Doctor updates the details of the patient’s record
  3. Once finished, staff saves record into system
  4. System rolls back to the patient’s record interface
  • Nonfunctional requirement:
  1. Update record constraint: Doctor can only update the treatment in a patient’s record
  • Postcondition: Patient’s record has been updated

4.4. Check Record

  • Use Case Name: Check Record
  • Summary : Doctor checks the patient’s record
  • Dependency: Include Login
  • Actor: Doctor
  • Precondition: Idle interface displayed on screen
  • Description of main sequence:
  1. Doctor selects Check Record, systems loads the Check Record session
  2. Doctor enters the patient’s information to look up for the record. The system retrieves the information
  3. If system finds out the patient’s record, system displays the patient’s record on screen
  • Alternatives:
  • Step 3: If the system cannot retrieve the patient’s record, displays a message that system could not find any corresponding patient’s record
  • Step 3: If the system cannot retrieve the patient’s record, staff can select Sign Up to create a new record
  • Postcondition: The patient’s record has been fetch and displayed

4.5. Read Payment Information

  • Use Case Name: Read Payment Information
  • Summary : Staff access the payment information
  • Dependency: Include Login
  • Actor: Staff
  • Precondition: Idle interface displayed on screen
  • Description of main sequence:
  1. Doctor selects Payment Information
  2. Doctor searches up either the patients information or the payment ID to check the payment information
  3. System traverses through the database and retrieve the information
  4. System displays the correspondent results
  5. Doctor select a specific payment which needed to be looked up
  6. System displays the payment information details
  • Alternative
  • Step 3: The looked-up input doesn’t match with any data. System shows a message of “No Result”.
  • Postcondition: The payment information has been fetch

————————————————————————————————————————————————–

*NOTE: Each part like: 2.1, 2.2, 2.3,…,2.10 and 4.1, 4.2, 4.3 4.4, 4.5 need a communication diagram EACH.

Below is the whole project description (pdf file) and above are Phase 1 of the project which I’ve done the use cases and now I need to draw a communication diagram for each use case.

Here is the example format from my friend, he did the Patient Use case and did these communication diagrams, you should follow the format and draw with the website: draw.io

  1. Register

2. Login

3. Appointment