Practical 6: Sequence diagrams

Sequence diagram

It represents the behavioural aspects of a system. Sequence diagram shows the

Elements in sequence diagram

Sequence diagram contains the objects of a system and their life-line bar and the
messages passing between them.

Object

Objects appear at the top portion of sequence diagram. Object is shown in a rectangle box.
Name of object precedes a colon ‘:’ and the class name, from which the object is
instantiated. The whole string is underlined and appears in a rectangle box. Also, we may
use only class name or only instance name.

Objects which are created at the time of execution of use case and are involved in
message passing, are appear in diagram, at the point of their creation.

Life-line bar

A down-ward vertical line from object-box is shown as the life-line of the object. A
rectangle bar on life-line indicates that it is active at that point of time.

Messages
Messages are shown as an arrow from the life-line of sender object to the life-line of receiver
object and labelled with the message name. Chronological order of the messages passing
throughout the objects’ life-line show the sequence in which they occur . There may exist some
different types of messages:

• Synchronous messages: Receiver start processing the message after receiving it and
sender needs to wait until it is made. A straight arrow with close and fill arrow-head from
sender life-line bar to receiver end, represent a synchronous message.
• Asynchronous messages: For asynchronous message sender needs not to wait for the
receiver to process the message. A function call that creates thread can be represented
as an asynchronous message in sequence diagram. A straight arrow with open arrow-
head from sender life-line bar to receiver end, represent an asynchronous message.
 • Return message: For a function call when we need to return a value to the object, from
which it was called, then we use return message. But it is optional, and we are using it
when we are going to model our system in much detail. A dashed arrow with open arrow-
head from sender life-line bar to receiver end, represent that message.
• Response message: One object can send a message to self. We use this message when we
need to show the interaction between the same object.

Case Study: Patient Tracking Application

This is the Login Sequence Diagram of Patient Information System, where admin

will be able to login in their account using their credentials. After login user can

manage all the operations on Medicine, Treatment, Appoitments, Doctors, Patient.

All the pages such as Appoitments, Doctors, Patient are secure and user can access

these page after login. The diagram below helps demonstrate how the login page

works in a Patient Information System. The various objects in the Doctors,

Medicine, Treatment, Appoitments, and Patient page-interact over the course of

the sequence, and user will not be able to access this page without verifying their

identity.
 Figure 1: Sequence diagram for "Patient tracking"

A sequence diagram in a patient management system can help illustrate how different components or
actors within the system interact and communicate to achieve specific functionalities. Here's a
theoretical example of a sequence diagram for a patient management system:

**Title: Patient Appointment Booking**

**Participants:**
1. **Patient:** The individual seeking a medical appointment.
2. **Receptionist:** The staff member responsible for booking appointments.
3. **Doctor:** The healthcare provider who will attend to the patient.
4. **Database:** Represents the patient records and appointment data stored in the system.

**Sequence Diagram:**

1. **Patient -> Receptionist:** The patient arrives at the clinic and approaches the receptionist to
request an appointment.
- Message: "Request Appointment"

2. **Receptionist -> Database:** The receptionist checks the availability of appointments in the
database.
- Message: "Check Appointment Availability"

3. **Database -> Receptionist:** The database responds with available appointment slots.
- Message: "Available Appointments"

4. **Receptionist -> Patient:** The receptionist informs the patient about available appointment slots
and asks for their preferred time.
- Message: "Available Times"
5. **Patient -> Receptionist:** The patient selects a preferred appointment time.
- Message: "Select Time"

6. **Receptionist -> Database:** The receptionist books the selected appointment time in the database.
- Message: "Book Appointment"

7. **Database -> Receptionist:** The database confirms the appointment booking.

8. **Receptionist -> Patient:** The receptionist confirms the appointment with the patient and provides
any additional instructions.
- Message: "Appointment Confirmed"

9. **Patient -> Doctor:** On the scheduled appointment day and time, the patient visits the clinic and
meets with the doctor.
- Message: "Visit Doctor"

10. **Doctor -> Patient:** The doctor examines the patient and provides medical advice or treatment.
- Message: "Medical Examination"

11. **Patient -> Receptionist:** After the appointment, the patient returns to the reception desk to
settle any bills or schedule a follow-up appointment.
- Message: "Follow-up/Checkout"

12. **Receptionist -> Database:** The receptionist updates the patient's record in the database to
reflect the appointment status.
- Message: "Update Patient Record"

13. **Database -> Receptionist:** The database confirms the update of the patient's record.
- Message: "Record Updated"

14. **Receptionist -> Patient:** The receptionist provides any necessary documents, receipts, or follow-
up instructions to the patient.
- Message: "Provide Documents"

This sequence diagram illustrates the steps involved in booking and attending a medical appointment
within a patient management system. It demonstrates the interactions between the patient,
receptionist, doctor, and the database to facilitate a seamless patient management process. Depending
on the complexity of the system and the specific functionalities it offers, the sequence diagram can be
expanded or modified to cover additional scenarios and interactions.