DELHI TECHNOLOGICAL UNIVERSITY

DEPARTMENT OF COMPUTER SCIENCE AND

ENGINEERING

Object Oriented Software Engineering

CO326
Practical Lab File

Submitted By -: Submitted To –:
Manthan Singh(2K21/CO/274) Ms. Nidhi Vardhan
 INDEX

EXP.NO

1
Write the problem statement of the case study 1

2 3
Write the Initial Requirements Document (IRD) of the
case study.
5
3 Write the Software Requirement Specification Document
of the case study

4
18
Design use case diagram of the case study

20
5 Write use case description of your case study.

6 29
Draw Class Diagram of your case study.

7 Draw Sequence diagram of your case study. 31

8 35
Draw Collaboration diagram of your case study.

37
9 Draw Activity diagram of your case study.

10 44
Design Test Cases of your case study.
 EXPERIMENT – 1

CASE STUDY- Hospital Patient Management System

AIM: Write the problem statement of the case study.

THEORY: Hospital patient management systems (HPMS) are crucial for efficient healthcare
delivery. However, current systems often suffer from limitations that can hinder workflow, patient
care, and staff satisfaction. These limitations may include:

-Inaccurate or incomplete data: Manual data entry can lead to errors and inconsistencies, making it
difficult to access accurate patient information.
-Poor communication: Fragmented systems and lack of information sharing can lead to
communication breakdowns between departments and delays in care.
-Inefficient workflows: Repetitive tasks and cumbersome processes can waste staff time and
resources.
-Limited functionalities :Traditional HPMS may lack features to support modern healthcare needs,
Limited functionalities such as online appointment scheduling, patient portals, or remote patient
monitoring.

OBJECTIVE:
This experiment aims to evaluate the effectiveness of improvements designed to address the
limitations mentioned in the problem statement. The specific objectives may include:

-Reduced data entry errors: Implement features like auto-fill, pre-populated forms, and electronic
health record (EHR) integration to improve data accuracy and completeness.
-Enhanced communication: Explore features like secure messaging platforms, real-time
notifications, and integrated care plans to improve communication between staff and departments.
-Streamlined workflows: Evaluate the impact of automation tools, digital task management systems,
and appointment scheduling optimization on workflow efficiency.
-Expanded functionalities: Assess the benefits of implementing features like online appointment
scheduling, patient portals for secure communication and record access, and remote patient
monitoring tools.

EXPECTED OUTCOME:

By addressing the limitations of the current HPMS, the experiment aims to achieve positive outcomes
such as:
-Improved data accuracy and accessibility
-Enhanced communication and collaboration between staff
-Streamlined workflows and reduced administrative burden
-Increased patient satisfaction and improved quality of care

This can help identify effective strategies for optimizing hospital patient management systems,
leading to improved healthcare delivery for both patients and staff.
 EXPERIMENT – 2

AIM: Draw the Initial Requirements Document (IRD) of the case study i.e.
“Hospital Patient Management System (HPMS)”.

Initial Requirements Document (IRD):

Title of Project Hospital Patient Management System

StakeHolders Admin, Doctors, Nurses, Surgeons, Developers

Techniques Used 1. Interviews

2. Brainstorming
3. User Observation
4. Interface analysis
5. Document Analysis
6. Role-play
7. Surveys

Name of 1. HEAD ADMIN

Person/Designatio 2. PQR/Developer
n 3. ABC/Doctor
4. XYZ/Surgeons
5. PQR/Nurses

Date 10 August 2021

Version 1.0.00

Consolidated list of ● Catchy and user-friendly interface

Initial ● Smooth and fast user experience
Requirements ● All access in system for ADMIN
● ADMIN shall schedule and update the day/night employee shifts.
Administrators in the wards are responsible for assigning doctors
and nurses to patients.
● When a patient is admitted, the front-desk staff checks to see if
the patient is already registered with the hospital.
● The system shall allow front-desk staff to give each patient a ID
and add it to the patient’s record. This ID shall be used by the
patient throughout his/her stay in hospital.
● Create ERP account for all registration in DB and send login
credentials via email
● The consulting nurse shall use system to assign the patient to an
appropriate ward. The consulting nurse shall use system to
assign Patient to a waiting list if no bed is available.
● Maintain list of doctors, surgeons and nurses that are assigned
to patients in each ward.
● Collect patient fees & Maintain patients fee record and Generate
list of the patients who haven’t paid the fee for Finance Team
● If a patient checks out, the administrative staff shall delete his
PHN from the system and the just evacuated bed is included in
available-beds list.
● The system generates reports on the following information:
patients, bed availability and staff schedules after every six
hours.
 EXPERIMENT – 3
AIM: Write the Software Requirement Specification Document of the case study i.e.
“Hospital Patient Management System (HPMS)”.

SOFTWARE REQUIREMENT SPECIFICATION:

TABLE OF CONTENTS FOR SRS DOCUMENT:

1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, Acronyms and Abbreviations
1.4. References
1.5. Overview

2. Overall Description
2.1. Product perspective
2.1.1. System Interfaces
2.1.2. User Interfaces
2.1.3. Hardware Interfaces
2.1.4. Software Interfaces
2.1.5. Communication Interfaces
2.1.6. Memory Constraints
2.1.7. Operations
2.1.8. Site Adaptation Requirements

2.2. Product Functions

2.3. User Characteristics
2.4. Constraints
2.5. Assumptions for dependencies

3. Specific Requirements
3.1. External Interface Requirements
3.1.1. User Interfaces
3.1.2. Hardware Interfaces
3.1.3. Software Interfaces
3.1.4. Communication Interfaces
3.2. Functional Requirements
3.2.1. Registration
3.2.2. Consultation
3.2.3. Medical matter management
3.2.4. Check Out
3.2.5. Report Generation
3.2.6. Database
3.3. Performance Requirements
3.4. Software System Attributes
3.5. Design Constraints
1. Introduction
1.1 Purpose
The purpose is to describe all the requirements for the Hospital Management System. The
following are some of the stake holders:
• administrative staff
• doctors
• nurses
• surgeons
• developers.
The hospital management and its team members uses this document as the primary means to
communicate confirmed requirements to the development team. The development team
expects many face-to-face conversations that will undoubtedly be about requirements and
ideas for requirements. However only the requirements that appear in this document or a
future revision, will be used to define the scope of the system.

1.2 Scope
The software product is the Hospital Management System. The system will be used to
allocate beds to patients on a priority basis, and to assign doctors to patients in designated
wards as need arises. Doctors will also use the system to keep track of the patients assigned to
them. Nurses who are in direct contact with the patients will use the system to keep track of
available beds, the patients in the different wards, and the types of medication required for
each patient. Doctors must make rounds to pick up patients’ treatment cards in order to know
whether they have cases to treat or not. The intentions of the system are to reduce over-time
pay and increase the number of patients that can be treated accurately. Requirements
statements in this document are both functional and non-functional.

1.3 Definitions, acronyms and abbreviations SRS:

PHN Personal Health Number on health card
Report An account of patients
Database Collection of information in a structured form
Front-desk staff Administrative staff that work at reception desk
Logon ID A user identification number to enter the system
Password A word that enables one to gain admission into the system
ID Patient Identification number
GUI Graphical User Interface
SRS Software Requirements Specification

1.4 References
a) Lauesen, S, (2003),Task Descriptions as Functional Requirements, IEEE Computer
Society,Available:http://www.itu.dk/~slauesen/Papers/IEEEtasks.pdf
1.5 Overview
This Software Requirements Specification (SRS) is the requirements work product that
formally specifies Hospital Patient Info Management System (HPIMS). It includes the results
of both business analysis and systems analysis efforts. Various techniques were used to elicit
the requirements and we have identified your needs, analyzed and refined them. The
objective of this document therefore is to formally describe the system’s high level
requirements including functional requirements, non-functional requirements and business
rules and constraints. The sections of the SRS document that lies ahead are: Overall Description,
Specific Requirements and Supporting Information.
2. Overall Description
2.1. Product Perspective
The HPMS is a software developed for registration of patients and generating their
final reports. It is also responsible for ensuring smooth process of consultation for the
patients. It
makes life easy for the people running the hospital as two very big tasks that is
manual
registration and report generation with the help of the software. It also takes care of
database.

The administrator will have to maintain the following information:

• Patient Details
• Doctor Details
• Report Details

The administrator will perform the following functions:

• Complaint Resolution
• Report Generation
• Bed Allocation
• Payroll Management and patient management

The patient requires the following information from the system:

• Available Beds
• Final Reports

2.1.1 System Interfaces

None

2.1.2 User Interfaces

The HPMS will have the following user-friendly and menu-driven interfaces:

(a) Login: to allow the entry of only authorized patients/doctors through valid login ID and
password.
(b) Patient Details: to maintain database of patients.
(c) Report Details: to maintain patient reports.
(d) Bed Details: to make beds available for patient to avail.
(e) Complaint Registration: to register a complaint if any anomaly is found.

The software should generate the following information:

(a) Report of each patient.
(c) Patient registered for each bed.
2.1.3 Hardware Interfaces

 Laptop/Desktop PC
 core i5 processor
 4GB RAM
 500GB HDD
Purpose of this pc is to give information when Patients ask information about doctors,
medicine available lab tests etc. To perform such Action, it needs very efficient computer
otherwise due to that reason patients have to wait for a long time to get what they ask for.
 Display Unit (LED/LCD Monitor/TV)
This unit is for display the channel number when the patients come to see their
consultants. It will avoid chaos. And also display Hospital welcome screen, video,
information etc.
 Laser Printer (B/W)
Simply this device is for printing bills and view reports.
 Wi-Fi router
Wi-Fi router is used to for internetwork operations inside of a hospital and simply data
transmission from pc’s to sever.

2.1.4 Software Interfaces

(a) MS-Windows Operating System (XP/Vista/8/10)
(b) HTML and CSS for designing front end.
(c) PHP and MySQL for designing the back end.

2.1.5 Communication Interfaces

In the URMS, communication is via local area network (LAN) and it is a web-enabled
system.

2.1.6 Memory Constraints

At least 2 GB RAM and 1 GB space of hard disk will be required to run the software.

2.1.7 Operations
None

2.1.8 Site Adaptation Requirements

The terminal at the client side will have to support the hardware and software interfaces
specified in sections 2.1.3 and 2.1.4, respectively
2.2 Product Functions
The system functions can be described as follows:

Registration: When a patient is admitted, the front-desk staff checks to see if the patient is
already registered with the hospital. If he is, his/her Personal Health Number (PHN) is
entered into the computer. Otherwise a new Personal Health Number is given to this patient.
The patient’s information such as date of birth, address and telephone number is also entered
into computer system.

Consultation: The patient goes to consultation-desk to explain his/her condition so that the
consulting nurse can determine what kind of ward and bed should be assigned to him/her.
There are two possible circumstances:
a) If there is a bed then the patient will be sent to the bed to wait for the doctor to come.
b) If there is no bed, the patient is put on a waiting list until a bed becomes available.

Patient check out: If a patient checks out, the administrative staff shall delete his PHN
from the system and the just evacuated bed is included in available-beds list.

Report Generation: The system generates reports on the following information: patients,
bed availability and staff schedules after every six hours. It prints out all the information on
who has used which bed, when and the doctor that is taking care of a given patient as well as
expected medical expenses.

2.3 User Characteristics

The system will be used in the hospital. The administrators, doctors, nurses and front-desk
staff will be the main users. Given the condition that not all the users are computer-literate.
Some users may have to be trained on using the system. The system is also designed to be
user-friendly. It uses a Graphical User Interface (GUI).

Front-desk staff: They all have general reception and secretarial duties. Every staff has
some basic computer training. They are responsible for patient’s check-in or notification of
appropriate people (e.g. notify administrator or nurse when an event occurs).

Administrators: They all have post-secondary education relating to general business

administration practices. Every administrator has basic computer training. They are
responsible for all of the scheduling and updating day/night employee shifts. Administrators
in the wards are responsible for assigning doctors and nurses to patients.

Nurses: All nurses have post-secondary education in nursing. Some nurses are computer
literate. Consulting nurses to whom patients give short descriptions of their conditions are
also responsible for assigning patients to appropriate wards if the beds are available,
otherwise putting patients on the waiting list. Nurses in wards will use the system to check
their patient list

Doctors: All doctors have a medical degree. Some have further specialized training and are
computer literate. Doctors will use the system to check their patient’s list.

2.4 Constraints
 The system must be delivered by deadline.
 The system must be user-friendly

2.5 Assumptions for dependencies

 It is assumed that compatible computers will be available before the system is installed
and tested.
 It is assumed that the Hospital will have enough trained staff to take care of the system
3. Specific Requirements
This section contains the software requirements in detail along with the various forms to be
developed.

3.1 External Interface Requirements

3.1.1 User Interfaces

The HPMS will have the following user-friendly and menu-driven interfaces:

(a) Login: to allow the entry of only authorized patients/doctors through valid login ID and
password.
(b) Patient Details: to maintain database of patients.
(c) Report Details: to maintain patient reports.
(d) Bed Details: to make beds available for patient to avail.
(e) Complaint Registration: to register a complaint if any anomaly is found.

The software should generate the following information:

(a) Report of each patient.
(c) Patient registered for each bed.

3.1.2 Hardware Interfaces

 Laptop/Desktop PC
 core i5 processor
 4GB RAM
 500GB HDD
Purpose of this pc is to give information when Patients ask information about doctors,
medicine available lab tests etc. To perform such Action, it needs very efficient computer
otherwise due to that reason patients have to wait for a long time to get what they ask for.
 Display Unit (LED/LCD Monitor/TV)
This unit is for display the channel number when the patients come to see their
consultants. It will avoid chaos. And also display Hospital welcome screen, video,
information etc.
 Laser Printer (B/W)
Simply this device is for printing bills and view reports.
 Wi-Fi router
Wi-Fi router is used to for internetwork operations inside of a hospital and simply data
transmission from pc’s to sever.

3.1.3 Software Interfaces

(a) MS-Windows Operating System (XP/Vista/8/10)
(b) HTML and CSS for designing front end.
(c) PHP and MySQL for designing the back end.
(d) HTML/CSS to design the frontend.

3.1.4 Communication Interfaces

 NIC (Network Interface Card) – It is a computer hardware component that allows a

computer to connect to a network. NICs may be used for both wired and wireless
connections.
 CAT 5 network cable- for high signal integrity
 TCP/IP protocol- Internet service provider to access and share information over the
Internet
 Ethernet Communications Interface- Ethernet is a frame-based computer network
technology for local area networks (LANs)

 Ubiquitous, easy to set up and easy to use. Low cost and high data transmission rates.

3.2 Functional Requirements

3.2.1 Registration
 Add patients
The system shall allow front-desk staff to add new patients to the system.
 Assign ID
The system shall allow front-desk staff to give each patient a ID and add it to the
patient’s record. This ID shall be used by the patient throughout his/her stay in
hospital.

3.2.2 Consultation
 Assign Ward
The consulting nurse shall use system to assign the patient to an appropriate ward.
 Assign to Waiting List
The consulting nurse shall use system to assign Patient to a waiting list if no bed is
available.

3.2.3 Medical matter management

 Assign Doctor
The administrative staff in the ward shall use system to assign a doctor to a given
patient.
 Assign Nurse
The administration staff in the ward shall use system to assign a nurse to a given
patient.
 Inform Doctors
The system shall inform doctors of new patients.
 Inform Nurses
The system shall inform nurses of new patients.
 Emergency Case
In an emergency case, the administrative staff shall use system to assign an
emergency room, doctors and nurses to the patient immediately.
  Surgery case
In a surgery case, the administrative staff shall use system to assign a surgery room,
surgeon and nurses to the patient.
 Generate Report (normal)
The system shall generate the patient’s situation record every two hours for normal
patients.
 Generate Report (Severe)
The system shall generate patient’s situation record every half hour for severe
patients.
 Record procedure
The whole treatment procedure for the patient shall be recorded by the system.
 Inform patient
The system shall automatically inform the patients who are on the bed waiting list of
available beds whenever they become available.

3.2.4 Check Out

 Delete Patient ID
The administrative staff in the ward shall be allowed to delete the ID of the patient
from the system when the patient checks out.
 Add to beds-available list
The administrative staff in the ward shall be allowed to put the beds just evacuated in
beds-available list.

3.2.5 Report Generation

 Patient information
Every six hours the system shall generate reports on patients about the following
information: patient’s PHN, patient’s name, ward name, bed number and the doctor’s
name.
 Bed Aavailability
Every six hours the system shall generate reports on bed availability about the
following information: ward name, bed number, occupied/unoccupied
 Staff Schedule
Every six hours the system shall generate reports on staff schedule about the
following information: staff ID, staff name, staff type, duty shift.

3.2.6 Database
 Patient Mandatory Information
Each patient shall have the following mandatory information: first name, last name,
phone number, personal health number, address, postal code, city, country, patient
identification number.
 Update Patient Information
The system shall allow the user to update any of the patient’s information
 Search for Patient
The system shall allow the user to search for patient’s information by last name or
PHN or patient ID.
 Staff Mandatory Information
Each staff in hospital shall have the following mandatory information: identification
number, first name, last name, phone number, address, postal code, city, country,
employee type, duty schedule.
  Update Staff Information
The system shall allow the user to update any of the staff’s information as described
in SRS023.
 Employee Information
The system shall allow the user to search for employee information by last name, or
ID number.
 Ward Types
The ward is categorized into four types: Maternity, Surgical, Cancer and Cardiac.
 Ward Information
Each ward in system shall include the following mandatory information: ward name,
ward number, list of rooms in ward.
 Room Information
Each room in system shall include the following mandatory information: room
number, list of beds in room, full/not full.
 Bed Information
Each bed in system shall include the following information: bed number,
occupied/unoccupied, patient PHN.

3.3 Performance Requirements

 Response Time
The system shall give responses in 1 second after checking the patient’s information.
 Capacity
The System must support 1000 people at a time.
 User-interface
The user-interface screen shall respond within 5 seconds.
 Conformity
The systems must conform to the Microsoft Accessibility guidelines

3.4 Design Constraints

 Database
The system shall use the MySQL Database, which is open source and free.
 Operating System
The Development environment shall be Windows 2000.
 Web-Based
The system shall be a Web-based application.

3.5 Software System Attributes

 AVAILABILITY: The system shall be available all the time.
 CORRECTNESS: A bug free software which fulfil the correct need/requirements of
the client.
 MAINTAINABILITY: The ability to maintain, modify information and update fix
problems of the system

 USABILITY: software can be used again and again without distortion.

 ACCESSIBILITY: Administrator and many other users can access the system but
the access level is controlled for each user according to their work scope.
 EXPERIMENT – 4

AIM: Design use case diagram of the case study i.e. “Hospital Patient
Management System (HPMS)”.

Theory:
A use case diagram is a representation of a user’s interaction with the system
that shows the relationship between the user and different use cases in which the
user is involved. A use case diagram is used to represent the dynamic behavior
of a system. It encapsulates the system’s functionality by incorporating the use
cases, actors and their relationship. It models the tasks, services and function
required by a system/subsystem of an application. It depicts the high-level
functionality of a system and also tells how the user handles a system.
A use case diagram is typically used to portray the dynamic aspects of a system.
It gathered the system needs, depicted external view of system, recognized the
internal as well as external factors that influenced the system and represented
the interaction between actors.

This diagram consists of following components –

1) Actors: The users that interact with a system. An actor may be a person,
an organization or an outside system that interacts with application or
system and they appear outside the rectangle.
2) Use Case: It is a list of actions or event steps, typically defining the
interactions between a role/actor and a system, to achieve a goal. These
use cases are represented within rectangle providing functionality.
3) Relationships: It is basically a solid line that describes the relationship
between actors and use case or between the use cases.
Use Case Diagram:
 EXPERIMENT – 5
AIM: Write use case description of your case study i.e. “Hospital Patient
Management System (HPMS)”.

USE CASES DESCRIPTION:

3.2.1 Login Use Case Description:

Introduction: This use case allows the user to access the system.
Actors:
Patient
Doctor
Admin

Precondition: The user must have their login id and password with them.
Postcondition: If the use case is successful, the user is granted access to the
system.

Event Flow:
Basic Flow
1. The user enters his/her login id and password.
2. The user’s login id and password are matched with the system’s database.
3. The user’s credentials match and he is granted access of the system.

Alternative Flow 1: Unauthorized employee

If the system does not validate the user’s login id or password (due to user not being in the system or
user entering wrong credentials), then an error message is flagged and the use case returns to the
beginning of the basic flow.
Alternative Flow 2: User exits
This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None
Associated use cases:
All other use cases are executable only after this login use case.
3.2.2 Doctor Available Use Case Description:

Introduction: This use case allows the user to check the doctor’s available.

Actors:
Patient

Precondition: The user must have their login id and password with them.

Postcondition: If the use case is successful, the user is given the information if the
Doctor is available.

Event Flow:
Basic Flow
The user gets the access to the list of available doctors available in the database.

Alternative Flow: User exits

This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:

Login
3.2.3 Available Appointments Use Case Description:

Introduction: This use case allows the user to access the list of available
appointments.

Actors:
Patient

Precondition: The user must be logged into the system before the use case begins.

Postcondition: If the use case is successful, a list of available appointments is

successfully displayed.

Event Flow:
Basic Flow
The user gets the access to the list of available appointments available in the database.

Alternative Flow: User exits

This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:

Login
3.2.4 Book Appointment Use Case Description:

Introduction: This use case allows the users to book and appointment for meeting
a doctor.

Actors:
Patient

Precondition: The user must be logged onto the system before the use case begins.

Postcondition: If the use case is successful, details of appointment are

successfully entered into the system and maintained accordingly by the administrator.

Event Flow:
Basic Flow
The users enter the required details for booking an appointment which is to be maintained. Then
details of registration are updated in the database and maintained by the administrator.

Alternative Flow: User exits

This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
The details entered by the users should be in prescribed format (data handling).

Associated use cases:

Login
3.2.5 Manage Appointment Use Case Description:

Introduction: This use case allows the Patient and the Administrator to manage
appointments.

Actors:
Administrator

Patient

Precondition: The patient and the administrator must be logged onto the system before the use
case begins.
Postcondition: If the use case is successful, details of the appointment can be viewed and updated
by the Patient and the Administrator.

Event Flow:
Basic Flow
The patient/administrator enter their login details. Now they can update their appointment timings.

Alternative Flow: User exits

This allows the user to exit at any time during the use case. The use case ends without
registering into the application.

Special Requirements:
The details entered by the patient/administrator should be in prescribed format (data handling).

Associated use cases:

None
3.2.6 View Patient Records Use Case Description:

Introduction: This use case allows the admin to view all the user’s within the database

Actors:
Administrator

Precondition: The administrator must be logged onto the system before the use case begins.

Postcondition: If the use case is successful, details of all the patients are
successfully viewed by the administrator.

Event Flow:
Basic Flow
The administrator logs into the system and views the records of all the patients.

Alternative Flow: User exits

This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:

None
3.2.7 View All Appointments Use Case Description:

Introduction: This use case allows the doctor and the administrator to view
all the appointments for a specific doctor.

Actors:
Administrator
Doctor

Precondition: The doctor and admin must be logged onto the system before the use case begins.

Postcondition: If the use case is successful, details of appointments for a specific

doctor are viewed by the admin and the doctor.

Event Flow:
Basic Flow
The administrator/doctor enters the app and view their appointments.

Alternative Flow: User exits

This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:

Login
3.2.8 File Medical Reports Use Case Description:

Introduction: This use case allows the user to the doctor to file medical reports.

Actors:
Doctor

Precondition: The doctor must be logged onto the system before the use case begins.

Postcondition: If the use case is successful, a patient’s medical report

is saved in the system.

Event Flow:
Basic Flow
The administrator/data entry operator enters the required details of patient’s report which is to be
maintained.

Alternative Flow: User exits

This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:

None
3.2.9 Update/Delete Records Use Case Description:

Introduction: This use case allows the doctor to update/delete patient records
Actors:
Doctor

Precondition: The doctor must have their login id and password with them.
Postcondition: If the use case is successful, the patient record is deleted.

Event Flow:
Basic Flow
1. The doctor enters his/her login id and password.
2. The doctor’s login id and password are matched with the system’s database.
3. The doctor’s credentials match and he is granted access of the system.
4. Now as the doctor clicks the delete button, the patient’s record is deleted
Alternative Flow 1: Unauthorized doctor
If the system does not validate the doctor’s login id or password (due to user not being in the system
or user entering wrong credentials), then an error message is flagged and the use case returns to the
beginning of the basic flow.
Alternative Flow 2: User exits
This allows the doctor to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:

None
 EXPERIMENT – 6
AIM: Draw Class Diagram of your case study i.e. “Hospital Patient
Management System (HPMS)”.

Theory:

The class diagram represents a static view of an application. It depicts the types
of objects residing in the system and the relationships between them. A class
consists of its objects, and also it may inherit from other classes. This diagram is
used to visualize, describe, document various different aspects of the system,
and also to construct executable software code.
It comprises of class names, attributes, and functions in a separate compartment
that helps in software development. Since it is a collection of classes, interfaces,
associations, collaborations, and constraints, it is termed as a structural diagram.
The main purpose of class diagrams is to build a static view of an application. It
is the only diagram which is widely used for construction, and also it can be
mapped with object-oriented languages. It is one of the most popular UML
diagrams.
Hospital Management System Class Diagram helps in describing the structure
of a Hospital Management System classes, their attributes, operations (or
methods), and the relationships among objects. The main classes of the Hospital
Management System include Hospitals, Patient, Doctors, Prescription,
Appointments, Medicines.
Class Diagram:
 EXPERIMENT – 7

AIM: Draw Sequence diagram of your case study i.e. “Hospital Patient
Management System (HPMS)”.

Theory:

A sequence diagram simply depicts interaction between objects in a sequential

order i.e. the order in which these interactions take place. We can also use the
terms event diagrams or event scenarios to refer to a sequence diagram.
Sequence diagrams describe how and in what order the objects in a system
function. These diagrams are widely used by businessmen and software
developers to document and understand requirements for new and existing
systems.

It helps in envisioning several dynamic scenarios. It portrays the

communication between any two lifelines as a time-ordered sequence of events,
such that these lifelines took part at the run time. In UML, the lifeline is
represented by a vertical bar, whereas the message flow is represented by a
vertical dotted line that extends across the bottom of the page. It incorporates
the iterations as well as branching.

Uses of sequence diagrams –

 Used to model and visualise the logic behind a sophisticated function,
operation or procedure.
 They are also used to show details of UML use case diagrams.
 Used to understand the detailed functionality of current or future systems.
 Visualise how messages and tasks move between objects or components in a
system.
Sequence Diagram:
a) Login:

b) Appointment:
c) Register/Admit Patient:

d) Test and Operation:

e) Discharge:
 EXPERIMENT – 8

AIM: Draw Collaboration diagram of your case study i.e. “Hospital Patient
Management System (HPMS)”.

Theory:

A collaboration diagram, also known as a communication diagram, is an

illustration of the relationships and interactions among software objects in the
Unified Modeling Language (UML). These diagrams can be used to portray the
dynamic behavior of a particular use case and define the role of each object.
Both the sequence and the collaboration diagrams represent the same
information but differently. Instead of showing the flow of messages, it depicts
the architecture of the object residing in the system as it is based on object-
oriented programming. An object consists of several features. Multiple objects
present in the system are connected to each other. The collaboration diagram is
used to portray the object's architecture in the system.

Following are some of the use cases enlisted below for which the collaboration
diagram is implemented:

1. To model collaboration among the objects or roles that carry the

functionalities of use cases and operations.
2. To model the mechanism inside the architectural design of the system.
3. To capture the interactions that represent the flow of messages between the
objects and the roles inside the collaboration.
4. To model different scenarios within the use case or operation, involving a
collaboration of several objects and interactions.
5. To support the identification of objects participating in the use case.
Collaboration Diagram:
 EXPERIMENT – 9

AIM: Draw Activity diagram of your case study i.e. “Hospital Patient
Management System (HPMS)”.

Theory:

An activity diagram is a behavioral diagram i.e. it depicts the behavior of a

system. An activity diagram portrays the control flow from a start point to a
finish point showing the various decision paths that exist while the activity is
being executed. We can depict both sequential processing and concurrent
processing of activities using an activity diagram. They are used in business and
process modelling where their primary use is to depict the dynamic aspects of a
system.

Some of the most common components of an activity diagram include:

 Action: A step in the activity wherein the users or software perform a

given task. In Lucid chart, actions are symbolized with round-edged
rectangles.

 Decision node: A conditional branch in the flow that is represented by a

diamond. It includes a single input and two or more outputs.

 Control flows: Another name for the connectors that show the flow
between steps in the diagram.

 Start node: Symbolizes the beginning of the activity. The start node is
represented by a black circle.

 End node: Represents the final step in the activity. The end node is
represented by an outlined black circle.
Activity Diagram:
a) Login
b) Booking Appointment
c) Register Patient
d) Ward Allocation
e) Test and Operation
f) Discharge
 EXPERIMENT – 10

AIM: Design Test Cases of your case study i.e. “Hospital Patient Management
System (HPMS)”.

Theory:

Test cases are integral part of any testing activity. The creation of test cases and
executing them when the source code is available ensures that a robust, defect
free and high quality system is constructed. Testing is very important and
essential activity that continues throughout the software development life cycle.

Commonly used Testing Terminology:

 Test case: A test case may execute a particular path of the program or verify
a given requirement of the system. A test case consists of inputs given to the
program and its expected outputs from the program.
 Test suite: A test suite consists of set of test cases. Test suite may consist of
set of successful test cases and set of unsuccessful test cases.
 Test design and procedure: Test design and procedure consists of detailed set
of instruction for setting, designing and interpreting the results for a given
test case.
 Test coverage: Test coverage defines the extent to which the test cases are
covered by a given test for a given use case, class or system.
 Test results: Test results are a repository in which all the results and data
produced during the execution of a program are kept.
 Test Cases:
1. LOGIN

Test Scenario name INPUT 1 INPUT 2 Expected Remarks

Case ID and Description USER ID PASSWORD Output

TC1 Scenario 1 – Valid Valid User is -

Login allowed to
Login

TC2 Scenario 2 – Invalid Valid/ User ID is USER ID is not in

Login Invalid invalid specified format.
Alternative
flow: Invalid
entry
TC3 Invalid Valid User ID is User ID does not
Invalid exist in database.

TC4 Valid Invalid assword is Password is not in

Invalid the specified
format.

TC5 Valid Invalid assword is Password does not

Invalid exist in database.

TC6 Invalid Invalid User ID Login ID and

and password are not
Password in the specified
are invalid format.

TC7 Scenario 3 – * * User Comes -

Login out of the
Alternative system
flow: User
Exits
 2. SEARCH FOR APPOINTMENTS

Test Scenario Name INPUT INPUT 2 INPUT 3 Expected Remarks

Case and Description 1 Allergies Time of Output
ID Disease appointment
TC1 Scenario 1- Valid Valid Valid A Searched -
Search for Successfully
appointments
TC2 Scenario 2- Invalid Valid/ Valid/ Source City is Source City
Search for Invalid Invalid Invalid entered is
appointments invalid
Invalid Entry

TC3 Valid Invalid Valid/ Disease is Disease

Invalid Invalid entered is
Invalid

TC4 Valid Valid Invalid Time of Time of

Appointment Appointment
is invalid entered is
Invalid

TC5 Scenario 3- * * * User comes -

Search for out of the
appointment system
Alternative
Flow:
User Exits
 3. BOOK APPOINTMENT (Condition: Beds are Available)

Test Scenario INPUT INPUT 2 INPUT 3 INPUT 4 INPUT 5 Expected Remark

Case Name and 1 Doctors Consulta Date Time Output s
ID Descriptio Speciali ncy fees
n zation
TC1 Scenario Valid Valid Valid Valid Valid Ticket -
1- Booking
Appoint Successful
ment
TC2 Scenario Invalid Valid Valid/ Valid Valid/ Invalid Name is
2- / Invalid / Invalid Name not in
Appoint Invali Invali the
ment d d specified
Alternate format
Flow:
Invalid
Details
TC3 Valid Invali Valid/ Valid Valid/ Invalid Number
d Invalid / Invalid Number of pass
Invali of Passe enger s
d ngers is not in
the
specified
format

TC4 Valid Valid Invalid Valid Valid/ Invalid Source

/ Invalid Source is not in
Invali the
d specified
format
TC5 Valid Valid Valid Invalid Valid/ Invalid Destina
Invalid Destinatio tion is
n not in
the
specifie
d
format
TC6 Valid Valid Valid Valid Invalid Invalid Type of
Type of Flight is
Flight not in
the
specified
format
TC7 Scenario * Valid Valid/ Valid Valid/ User -
3- / Invalid / Invalid comes out
Appoint Invali Invali of the
ment d d system
Alternate
Flow:
User
Exits

4. WARD ALLOCATION

Test case enario Name and INPUT 1 Expected Remarks

ID Description Ward Output
Availability

TC1 Scenario 1- Valid Ward is -

Allocating Ward Allocated

TC2 Invalid Ward not Ask for new

available dates

TC3 Scenario 2- * User comes out of -

User Exits the system
 5. CANCEL BOOKED APPOINTMENT

Test Scenario INPUT 1 INPUT 2 FEES Expected Remarks

Case ID Name and Appoint User ID Condition Output
Descriptio ments Satisfied
n Number
TC1 Scenario 1- Valid Valid Yes Appointme -
Cancel nts
Booked Cancelled
Appointment and Refund
Initiated
TC2 Valid Valid No Appointme
nts
Cancelled

TC3 Scenario 2- Invalid Vali Appointm Appointm

Cancel d/ ents ents
Book Inval Number Number
Appointme id Invalid entered is
nts Invalid
Alternate
Flow:
Invalid
TC4 Valid Inval User ID User ID
Details
id Invalid entered is
Invalid

TC5 Scenario 3- * * User comes -

Cancel out of the
Booked System
Appointment
s Alternate
Flow:
User Exits
 6. TEST AND OPERATION

Test Scenario Name INPUT 1 INPUT 2 INPUT 3 Expected Remarks

Case and Description Prescription Test Disease Output
ID

TC1 Scenario 1- Valid Valid Valid A Searched -

Search for Tests Successfully

TC2 Scenario 2- Invalid Valid/ Valid/ Prescription Prescription is

Search for Invalid Invalid Is Invalid invalid
Tests Invalid
Entry

TC3 Valid Invalid Valid/ Test is Test entered is

Invalid Invalid Invalid

TC4 Valid Valid Invalid Disease Disease entered

is invalid is Invalid

TC5 Scenario 3- * * * User comes -

Search for out of the
Test system
Alternative
Flow:
User Exits
7. DISCHARGE

Test Scenario Name INPUT INPUT 2 INPUT 3 Expected Remarks

Case ID and Description 1 Discharge Bill Due Output
User ID Ticket
TC1 Scenario 1- Valid Valid Valid/ Discharged -
Request for Invalid Successfully
Discharge
TC2 Invalid Invalid Valid/ Discharge -
Invalid Invalid

TC3 Scenario 2- Invalid Invalid Valid/ - -

Check dues Invalid

TC4 Valid Invalid Valid/ Allocate -

Invalid Discharge
Ticket

TC5 Valid Valid Valid Pay the -

Pending
Dues

TC6 Valid Valid Invalid Discharge -

Given

TC7 Scenario 3- * * * User comes -

Search for out of the
appointment system
Alternative
Flow:
User Exits