Hospital management system

Department of Computer Science &

Information Technology

The hospital management system

Final Project Guide Book

Version 1.0

Revision History
This section describes the revision history of this document.

Date Version Description of Change Author

September 1.0 First Draft of Final Project Deliverable Project

25, 2012 Guideline Coordination
Office

Distribution List
This section describes the distribution list for the recipients of this document.

Recipient Role / Designation Office Contact Details

Dr. MA Chairman Chairman, Department marpasha@yahoo.com

Pasha of Computer Science
& Information
Hospital management system

Technology

Table of Contents
CHAPTER 1 - FINAL PROJECT PROPOSAL.............................................................1
1.2 PROJECT TITLE...........................................................................................................2
1.3 PROJECT OVERVIEW STATEMENT................................................................................2
1.4 HIGH-LEVEL SYSTEM COMPONENTS.........................................................................3
1.5 APPLICATION ARCHITECTURE.....................................................................................4
WE BUILD THREE TIER ARCHITECTURE IN OUR SYSTEM..................................................4
1.6 HARDWARE AND SOFTWARE SPECIFICATION..............................................................4
1.7 TOOLS AND TECHNOLOGIES USED WITH REASONING................................................5
CHAPTER 2 - FIRST DELIVERABLE..........................................................................6
2.1 INTRODUCTION...........................................................................................................7
2.2 PROJECT FEASIBILITY REPORT...................................................................................7
2.2.1 Technical Feasibility..........................................................................................7
2.2.2 Operational Feasibility......................................................................................7
2.2.3 Economic Feasibility..........................................................................................7
2.2.4 Schedule Feasibility...........................................................................................8
Hospital management system

2.2.5 Specification Feasibility.....................................................................................8

2.2.6 Motivational Feasibility.....................................................................................8
2.2.7 Legal & Ethical Feasibility................................................................................9
2.3 PROJECT / PRODUCT SCOPE.......................................................................................9
2.5 RISK LIST.................................................................................................................10
2.6 PRODUCT FEATURES / PRODUCT DECOMPOSITION..................................................10
CHAPTER 3 - SECOND DELIVERABLE FOR OBJECT ORIENTED
APPROACH.....................................................................................................................11
3.1 INTRODUCTION.........................................................................................................12
3.1.1 Systems Specifications......................................................................................13
3.1.2 Identifying External Entities.............................................................................14
3.1.3 Context Level Data Flow Diagram..................................................................14
3.1.4 Capture "shall" Statements...............................................................................14
3.1.5. Allocate Requirements:....................................................................................15
3.1.6. Priorities Requirements:.................................................................................16
3.2. USE CASE MODEL DESCRIPTION.............................................................................16
Use case Description.................................................................................................19
CHAPTER 4 - THIRD DELIVERABLE FOR OBJECT ORIENTED APPROACH
...........................................................................................................................................26
4.1 INTRODUCTION.........................................................................................................27
4.2 DOMAIN MODEL.......................................................................................................27
4.3 SYSTEM SEQUENCE DIAGRAM.................................................................................27
4.4 SEQUENCE DIAGRAM...............................................................................................27
4.4.1 Basic Sequence Diagram Symbols and Notations............................................28
4.4.2 Sequence Diagram of Online Airline Reservation System...............................29
4.4.3 Distributing Control Flow in Sequence Diagram............................................30
4.5 COLLABORATION DIAGRAM.....................................................................................30
WHAT IS A COLLABORATION ?.......................................................................................30
STEPS FOR CREATING COLLABORATION DIAGRAMS.....................................................31
4.5.1 Contents of Collaboration Diagrams...............................................................31
4.5.2 Constructs of Collaboration Diagram:............................................................32
Example.....................................................................................................................34
4.6 OPERATION CONTRACTS..........................................................................................35
4.7 CLASS DIAGRAM......................................................................................................35
4.7.1 PURPOSE OF CLASS DIAGRAMS...................................................................................35
4.7.2 HOW TO DRAW A CLASS DIAGRAM?...........................................................................36
 THE NAME OF THE CLASS DIAGRAM SHOULD BE MEANINGFUL TO DESCRIBE THE
ASPECT OF THE SYSTEM.................................................................................................36
4.7.3 Relationships between Classes.........................................................................37
4.7.3.1 GENERALIZATION (INHERITANCE) RELATIONSHIPS............................................37
4.7.3.2 ASSOCIATIONAL RELATIONSHIPS........................................................................37
4.7.4 MULTIPLICITY OF ASSOCIATIONS..........................................................................37
4.7.5 ASSOCIATION TYPES..............................................................................................37
4.8 STATE CHART DIAGRAM..........................................................................................37
Hospital management system

4.8.1 STATE CHART DIAGRAM SYMBOLS.......................................................................38

4.9 DATA MODEL...........................................................................................................38
4.9.1 THE RELATIONAL DATA MODEL...........................................................................39
4.9.2 ENTITY-RELATIONSHIP MODEL....................................................................................39
CHAPTER 5: 2ND & 3RD DELIVERABLE FOR STRUCTURED APPROACH...40
5.1. INTRODUCTION:.......................................................................................................41
5.2. ENTITY RELATIONSHIP DIAGRAM:..........................................................................41
5.3. DATA FLOW DIAGRAM (FUNCTIONAL MODEL).......................................................42
5.4. STATE TRANSITION DIAGRAM.................................................................................48
5.5. ARCHITECTURAL DESIGN.........................................................................................49
5.6. Component Level Design.......................................................................................53
Hospital management system
Hospital management system

Chapter 1 - Final Project Proposal

<

1
Hospital management system

1.1 Introduction
The world has seen the most technological boom in the last fifty years, with the
inventions in every field made possible now for making the human life easier and more
comfortable. An airport is providing facility where passenger connect from ground
transportation to air transportation.
The hospital is the essential part of our lives, providing best medical
facility to people suffering from various element.
The main aim of our project is to provide a paper less hospital up to 90% .it
also aims a providing low cost reliable automation of the existing
system.Thy also provides excellent security of at every level of ualsoser
system interaction also provide reliable storage and and backup facility.

1.2 Project Title

Our project title is “Hospital management system”

1.3 Project Overview statement

This project is to reduce the manual errors.
Hospital management software is one of the successful product of company. The hospital
Management software or the software for hospital management commonly incorporates
various essential feature which help to run efficiently day to day operation of any
hospital.
The hospital management information system is very useful of running the hospital in the
cost effective way.
Some common feature of this type of software:
 The software facilities complete and running of the reception.
 It manage the day to day scheduling of nurses and doctors and allocating the
schedule of their duties.
 It also manage the laboratory and the equipment.
 It manage the treatment as well as the history of patient.
The biggest benefit of the hospital management is that it can be used at the
same time through a number of users.
Project Overview Statement Template

Project title Hospital management system

Project Manager
Project Members
Name Registration Email Address Signature
#
Madiha kiran 538 kiran madiiha180@gmail.com Madiha
Misbah parveen 530 misbahparveen510@gmail.com Misbah

2
Hospital management system

Project goal
 Hospital management system manage automation of hospital tasks and services.
 To improve decision making.
 To make the technology add to the bottom-line of company.
 To control credit.
 Provides efficient consultation to patients.

Objectives
The project hospital manage system is aimed to develop to maintain the day-
to-day state of admission or discharge of patient .list of doctors reports
generation and etc. It is designed to achieve the following objectives.
1 To computerize all details regarding patient details.
2 Scheduling the appointment of patients with doctors to make it convenient
for both.
3 Scheduling the doctors and emergency properly so that facilities provide by
hospital are fully utilized in efficient manner.
4 If medical store issues medicines to patients .It should reduce the stock status
of the medical store.
5 The information of the patients should be kept up to date and there record
should kept in the system for historical purposes.
Type of project Research Development
Target End users

Development Technology Object Oriented Structured

Platform Web Based Distribut
Desktop Based Setup Configurations
Other_____________________
Approved By

High level system components:-

1.5 Application Architecture

We build three tier architecture in our system

3
Hospital management system

1.6 Hardware and Software Specification

 Hardware Requirement

Processor : Intel inside core™ i5

Processor Speed : 2.80 GHZ

Main Storage : 512 MB RAM

Hard Disk Capacity : 80 GB

 Software Requirement

Front End : HTML

Back End : PHP

Operating System : Window 10

1.7 Tools and Technologies used with Reasoning

 PHP for Backend Use
 HTML & CSS for Frontend
 XAMPP for use of Database
 Notepad++ use for Coding

4
Hospital management system

Chapter 2 - First Deliverable

5
Hospital management system

2.1 Introduction
Introduction First deliverable is all about planning and scheduling of project. Our project
hospital management system is feasible to develop. Technically it is feasible. Our project
can perform many functional operations that is useful for patients and doctors. This
chapter describe the functional feasibility of system. We use open source software we do
not purchase extra hardware for our system. Our system is web based and it can run on
servers so the scope of our system is global any one can use this system. Gantt chart is
used to estimate the use of corresponding time to perform the essential activates of the
project.

2.2 Project Feasibility Report

There are many types of feasibilities:

 Technical
 Operational
 Economic
 Schedule
 Specification
 Information Motivational
 Legal and Ethical

6
Hospital management system

2.2.1 Technical Feasibility

The technically feasible since there are no extra hardware requirement.Technical
feasibility on the existing computer system (hardware and software etc) and what extend
it can support the proposed system .
In case of this system the required infrastructure i-e hardware ,software application and
technical known-how already exist .Thus the project is then technically feasible.

2.2.2 Operational Feasibility

The system working is quite easy to use and learn due to its simple but attractive
interface. User requires no special training for using the system.It is mainly realited to
human organizational and political ascept. The points to be considered are:
 What changes will be brought with the system?
 What organizational structures are distributed ?
 What how skills will be required?
The proposed system is feasibility because of following reasons.
The system reduce the work load of the staff because on a mouse click he/ she
desired result ,work can be done with help of keyboard and mouse watching the
computer screen nit on paper .The system will be built on the technology of GUI so that
interaction to system not be boring as like writing /maintaining data into the from of
the manual paper .Users that work into the GUI envirornment work more interestingly
than the paper based .This result work more efficiently.

2.2.3 Economic Feasibility

 We use open source software that are free of cost and easily available. Economic
analysis is the most frequently used method for evaluating the effectiveness of
a HRM system .Most commonly known as cost /benefit analysis ,the procedure is
to determind the benefit and saving that are expected from a system and compare
with cost involve.
The proposed system is financially feasible because of the following reason:
 The cost of the system development is not much because of module/department
wise automation .
 Then organization wants to implement wise so this system cannot take a heavy
amount the system into the from of hardware investment.
 The proposed system is economic ,as the investment in running the daily
transaction.

7
Hospital management system

2.2.4 Schedule Feasibility

We have 8 months to accomplish our project. We complete every phase of our system in
estimated time. The System is completed in proposed time with available resources, time
deadlines and resources should keep in mind.
 Requirement gathering takes 3 weeks
 Requirement analysis takes 3 weeks
 Designee takes 6 weeks
 Development takes 7 weeks
 Testing takes 3 weeks
 Maintenance take 3 weeks
In our project we adopted software model ‘RAD’. It stands for “rapid application
development model”. In this model the system is breached into different modules and
then develop these modules step by step. We use RAD because in this model changes are
acceptable easily.7

2.2.5 Specification Feasibility

Requirement are the feature that the system must have. The requirement of the system is
clear and definite.no complex module is added into the system because of shortage of
time. Project is sophisticated and simple .The project lies with thin the scope boundaries
of the system.

2.2.6 Motivational Feasibility

Our system is more effective and motivational.

2.2.7 Legal & Ethical Feasibility

In our system the software that we use are registered and legal. We do not use pirated
software. This software is ethically correct. We are not used copied software. This
software cannot arise any difficulty in our system.
Software that we use in our system are bellow.
 Notepad++
 MS word
 Open office
 XAMPP server
 SQL server

This software is legal and ethical correct. These are open source software.

2.3 Project / Product Scope

Scope is very important factor. The basic purpose f developing this type of application is
to get information easily on a single plateform.Daily function like patient registration,
scheduling, monitoring managing admission and overall management of various
department can be performed easily with higher accuracy after instalion of hospital
software.

8
Hospital management system

The project aimed is to developing a hospital management system APP that can be used
in the hospitals, which will help the staff to, simplified their daily operational task as well
as medicate the patients in the effective and more convenient way.

2.4. Gantt chart

We complete our project in the given time.

2.5 Risk List

Database risks:
 Loss of database integrity and availability
 Unauthorized activates by database administrator
 Unauthorized access to the database
 Poor database performance
 Inconsistence use of database resources
Front end risks:
 User interaction heavy app
 Poor planning
 Complicated front- end designee
 Graphical description of front end is not decent
Back end risks:
 Static data
 No early feedback
 High cost change management
 Hard to mock real functionality
 Overcomplicate backend
 Inaccurate estimation
 Dummy application

2.6 Product Features / Product Decomposition

The services, tasks or the functions of the system that it can perform are as follows:
 Maintain passenger record: that is used to maintain the passenger records in the
system.
 Maintain flight schedule: this function shows the details of flights and update the
flight schedule.
 The login function: this function is used to login the admin into the system.
 Book ticket: in this service passenger can book the ticket online.
 Make payment: this service is performed to make payment. Passenger can make
payment using different methods like make payment online and using debit card.

9
Hospital management system

Chapter 3 - Second Deliverable For Object Oriented Approach

10
Hospital management system

3.1 Introduction
Requirements engineering process provides the appropriate mechanism for understanding
what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable
solution, specifying the solution unambiguously, validating the specification and
managing the requirements as they are transformed into an operational system. The task
of capturing, structuring, and accurately representing the user's requirements so that they
can be correctly embodied in systems which meet those requirements (i.e. are of good
quality).

 Requirements elicitation
 Requirements analysis and negotiation
 Requirements specification
 System modeling
 Requirements validation
 Requirements management

11
Hospital management system

Here, requirements specification is to be discussed. Requirements specification would

lead to the following four steps:
 Identify external interfaces
 Development of context diagram
 Capture “shall statements
 Allocate requirements
 Prioritize requirements
 Development of requirements traceability matrix
3.1.1 Systems Specifications
The following are the clauses that must be included while describing the system
specifications.
Introduction
Airport is gateway for country. They open door for tour and trade. Economy of country
depend on tourism and trade in other words trade and tourism depend on airport. A

12
Hospital management system

country without national transporters can still trade. But the country without airport will
be handicapped. So airport become very important for every country.
Universe is based on principle of dependence, everything depends on another thing. The
question arise that airline depend on airport or airport depend on airline, the answer is
quite questionable. It is phenomenon that airport always need airlines.
In our project we discuss about reservation detail, passenger detail, and flight detail Staff
detail time schedule. User can reserve seats online.
Existing System
The existing system is very time consuming. This system is more poor to errors and
sometime the approach to various problems is unstructured.
If any old data or information is to be fetched, then it is a great problem for passengers to
get the information in short period of time as to get information from files is not an easy
task.
As everything is done manually, so if any record is misplaced then system has to take full
responsibility.
 Much time is required in giving correct information.
 Less reliability and maintainability of data.
 Manual procedure of providing information is not reliable.
Secrecy of information may not be maintained due to visible facts on paper
Organizational Chart
Organizational chart will be very much supportive to get a better overview of the
organization’s business areas and their decomposition into different departments.
Scope of the System
This project design and implementation online airline reservation system. It is well design
database, all available flight information, ticket booking, cancel ticket is integrated
together and can be accessed easily.
“Online Airline Reservation System” provide user friendly interface. To use our system
there is not require extra knowledge of hardware and software.
Summary of Requirements (Initial Requirements)
 Login function
 Managing passenger Record
 Manage flight schedule
 Manage ticket booking
3.1.2 Identifying External Entities
The identification of the external entities will be based on the information contained in
your Abstract. This identification is done after two phases. We will map the “Green
wood” case study to make things more comprehensible.
The Identification of External Entities is done in two phases.
a. Over Specify Entities from Abstract
On the basis of the Abstract, one might identify the entities from the problem.
 Passenger
 Booking

13
 Hospital management system

 Order for booking

 ticket
 Confirmation message
 Flight
 manager
 Request
 Payment
 Aircraft
 Airport
b. Perform Refinement
After over specifying the entities, you have to refine them on the basis of your business
logic. For example, in this example we found the following entities more related to our
business logic.
 Passenger
 Booking
 Manager
 Login
3.1.3 Context Level Data Flow Diagram
Context level data flow diagram contains only one process, representing the entire
system. The process is given the number zero and all external entities are shown on the
context diagram as well as major data flow to and from them. The diagram does not
contain any data stores.

3.1.4 Capture "shall" Statements

Identify “shall” statements, as they would be all functional requirements.
Para Initial Requirements
#
1.0 A passenger “shall” place request for book ticket.
1.0 System “shall” accept, reject and temporarily waive the requests on the basis of
credentials provided.
1.0 System “shall” update the passenger Request.
1.0 System “shall” process different types of updating e.g. updating of his personal and
ticket details, or upgrading of his status from registration.
1.0 System “shall” search any passenger details.
2.0 System “shall” generate confirmation receipt and finally will book ticket.
2.0 User “shall” view the status of their booking by providing the ticket id and ticket no.
3.0 An action event "shall" be generated for administrator when a request is placed for
updating of booking or passenger details etc.
3.0 Corresponding administrator "shall" view his Action List containing different actions,

14
 Hospital management system

and correspondingly process these pending actions

3.0 When the action processing is completed or if the action is just a notification message
then administrator "shall" delete these actions from the action list

3.1.5. Allocate Requirements:

Initial Requirements Use Case Name
1.0 A passenger “will” place request for bookUC_book_ticket
ticket.
1.0 System “shall” accept, reject the requests onUC_registration_Request
the basis of credentials provided.
1.0 System “shall” update the passenger Request. UC_Update_Request
1.0 System “shall” process different types ofUC_update_Status
updating e.g. updating of his personal/booking
details, or upgrading of his status from
registered.
1.0 A passenger “shall” view his details forUC_search_Details
verification purposes.
1.0 System “shall” search any passenger details UC_Serach_details
1.0 System “shall” accept, reject the requests onUC_Accept_Customer_Request
the basis of credentials provided. UC_Reject_Customer_Request
UC_View_Customer_Request
2.0 System “will” generate confirmation receiptUC_conformation_message
when ticket is booked.

3.1.6. Priorities Requirements:

Para Rank Initial Use Use Case Name

Requirements Case ID
1.0 Highest Acustomer “will”UC_1 UC_book ticket
place request for
book ticket.
2.0 Highest System “will”UC_3 UC_confirmantion message
generate
confirmation
message and finally
will book ticket.
1.0 Medium Administrator UC_6 UC_View_Customer_Request
“shall”accept,
reject the requests

15
Hospital management system

on the basis of
credentials
provided.
1.0 Medium System “shall”UC_7 UC_Update_Request
update the
passenger Request.
1.0 Medium System “shall”UC_8 UC_Change_Personal_Details
process different
types of updating
e.g. updating of his
personal/booking
or upgrading of his
status from
registered.

3.2. Use Case Model Description

The main purpose of a use case diagram is to show what system functions are
performed for which actor. Roles of the actors in the system can be depicted.
Use Case diagrams are formally included in two modeling languages defined by
the OMG: the Unified Modeling Language (UML) and the Systems Modeling
Language (SysML).A use case analysis is the most common technique used to identify
the requirements of a system (normally associated with software/process design) and
the information used to both define processes used and classes (which are a collection
of actors and processes) which will be used both in the use case diagram and the
overall use case in the development or redesign of a software system or program.

16
Hospital management system

3.2.1. Analysis Level Use case Diagram:

17
Hospital management system

Use case Description

User:

18
Hospital management system

Use case ID UC-01

Use case name Check flight detail.
Actor Passenger
Description Passenger can search for flight details.
Primary scenario User action System response
1. User click on search
engine. 1. System provide
2. Selects origination interface for search
city. flights.
3. Select destination 2. System display UI
city. for user to search
4. Selects type of available flights.
flights.
5. Selects departure
date.

Secondary scenario 1. User selects the invalid city, time and date of flights
for search.
Exception Invalid data is entered for search.
Post condition Passenger get the required information from the
system.

19
Hospital management system

Use case ID UC-02

Use case name Check flight schedule.
Actor Passenger
Description Passenger can search for flight schedule.
Primary scenario User action System response
1. User click on
schedule button. 1. System provide the
page.
2. User select the
destinations city
or country. 2. System accept
requirements and
3. User also select provide the flight
dates. Then click schedule.
proceed button.

Secondary scenario 1. User selects the invalid city, time and date of flights
for search.
Exception Invalid data is entered for search.
Post condition Passenger get the required information from the
system.

20
Hospital management system

Use case id UC-03

Use case name Book ticket
Actor Passenger
Description In this use case passenger book the ticket for traveling
Precondition Passenger must access to the system or website
Primary scenario: User action System response

1. Passenger request 1. System accept the

for ticket booking. request and provide
interface.
2. Passenger select
city from and
destination.

3. Passenger must
select the date and 2. System accept
time. details if details
4. Passenger enter true system show
their details to the confirmation
system. message otherwise
system generate
error.

Secondary scenario: Passenger enter invalid personal details.

Exception: Ticket is not booked.
Post condition: Ticket book successful.

Admin:

21
Hospital management system

Use case ID: UC-04

Use case name: Update & mange schedule
Actor: Administrator
Description: If flight schedule is changed manger will update new flight
detail in system.
Pre-condition: Manger access the system through password
Primary scenario:
User action: System response:

1. Manger request 1. System show a flight

to system show detail page.
flight schedule.
2. Manger 2. System will update a
change/update new flight schedule.
new flight detail
and click on
update button.
Secondary scenario: 1. Manger close web form.
2. Manger put wrong information.
Exception: 1. Required information is not updated
Post condition: The flight details are updated successfully

22
Hospital management system

Use case ID: UC-05

Use case name: Update & manage flight info
Actor: Administrator
Description: If flight details are, changed manger will update new
flight detail in system.
Pre-condition: Manager must access the system
Primary scenario User action: System response:

1. Administrator 1. System show a

request to system flight detail page.
show flight info.
2. Administrator
change/update
new flight detail
and click on update 2. System will update
button. a new flight
schedule.

Secondary scenario: 1. Manger close web form.

2. Manger put wrong information.
Exception: Required information is not updated
Post condition: The flight details are updated successfully

23
Hospital management system

Use case ID: UC-06

Use case name: View passenger list
Actor: Administrator
Description: Administrator view passenger list confirm all booked
seats and cancel seats.
Pre-condition: Administrator must access the system
Primary scenario User action System response

1. Administrator 1. System provide

request for view passengers list.
passenger list.
2. System validate the
2. Administrator passenger list.
confirm all
booked and
cancel tickets

Secondary scenario User selects the invalid city, time and date of flights
for search.
Exception Invalid data is entered for search.
Post condition Administrator get the required information from the
system.

24
Hospital management system

Use case ID: UC-07

Use case name: View flight info
Actor: Administrator
Description: Administrator view flight booking
Pre-condition: Administrator must access to the system
Primary scenario User action System action

1. Administrator 1. System provide

request for view flight booking.
flight booking.

2. Administrator
confirmed all the
seats are booked.

Secondary scenario: User selects the invalid city, time and date of flights
for search.
Exception: Invalid data is entered for search.
Post condition: Administrator get the required information from the
system.

25
Hospital management system

3.3 Scope of the System

The established procedure is for online airline reservation as given in the below block
diagram

26
Hospital management system

Chapter 4 - Third Deliverable For Object Oriented Approach

27
Hospital management system

4.1 Introduction
3rd deliverable is all about the software design. In the previous deliverable, analysis of the
system is completed. So we understand the current situation of the problem domain. Now
we are ready to strive for a solution for the problem domain by using object-oriented
approach. Following artifacts must be included in the 3rd deliverable.
1. Domain Model
2. System Sequence Diagram
3. Sequence Diagram
4. Collaboration Diagram
5. Operation Contracts
6. Design Class Diagram
7. State Transition Diagram
8. Data Model
Now we discuss these artifacts one by one as follows

4.2 Domain Model

Domain models represent the set of requirements that are common to systems within a
product line. There may be many domains, or areas of expertise, represented in a single
product line and a single domain may span multiple product lines. The requirements
represented in a domain model include:
 Definition of scope for the domain
 Information or objects
 Features or use cases, including factors that lead to variation
 Operational/behavioral characteristics
A product line definition will describe the domains necessary to build systems in the
product line.

4.3 System Sequence Diagram

The UML system sequence diagram (SSD) illustrates events sequentially input from an
external source to the system. The SSD will define the system events and operations.
System sequence diagrams are a timeline drawing of an expanded use case. Events are
related by time with the top events occurring first.
System events are the important items. These are events that cause a system response.
There may be more than one actor to the system. An actor may be an external automated
system that the system may communicate with.

28
Hospital management system

4.4 Sequence Diagram

A Sequence diagram depicts the sequence of actions that occur in a system. A Sequence
diagram is two-dimensional in nature. On the horizontal axis, it shows the life of the
object that it represents, while on the vertical axis, it shows the sequence of the creation
or invocation of these objects.
A sequence diagram is made up of objects and messages. Objects are represented exactly
how they have been represented in all UML diagrams—as rectangles with the underlined
class name within the rectangle.
Hence, the Sequence diagram is one of the most widely used dynamic diagrams in UML.

4.4.1 Basic Sequence Diagram Symbols and Notations

Class Roles
Class roles describe the way an object will behave in context. Use the UML object
symbol to illustrate class roles, but don't list object attributes.

Activation or Execution Occurrence

Activation boxes represent the time an object needs to complete a task. When an object is
busy executing a process or waiting for a reply message, use a thin gray rectangle placed
vertically on its lifeline.

Messages
Messages are arrows that represent communication between objects. Use half-arrowed
lines to represent asynchronous messages. Asynchronous messages are sent from an
object that will not wait for a response from the receiver before continuing its tasks. For
message types, see below.

Types of Messages in Sequence Diagrams

Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over time.

Destroying Objects
Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an
X. This object is removed from memory. When that object's lifeline ends, you can place
an X at the end of its lifeline to denote a destruction occurrence.

Loops
A repetition or loop within a sequence diagram is depicted as a rectangle. Place the
condition for exiting the loop at the bottom left corner in square brackets [ ].

29
Hospital management system

4.4.2 Sequence Diagram of Online Airline Reservation System

30
Hospital management system

4.4.3 Distributing Control Flow in Sequence Diagram

Centralized control of a flow of events or part of the flow of events means that a few
objects steer the flow by sending messages to, and receiving messages from other objects.
These controlling objects decide the order in which other objects will be activated in the
use case. Interaction among the rest of the objects is very minor or does not exist.

A Decentralized Structure is Appropriate

 If the sub-event phases are tightly coupled. This will be the case if the
participating objects:
 Form a part-of or consists-of hierarchy, such as Country - State - City;
 Form an information hierarchy, such as CEO - Division Manager - Section
Manager;
 Represent a fixed chronological progression (the sequence of sub-event phases
will always be performed in the same order), such as Advertisement - Order -
Invoice -Delivery - Payment; or
 Form a conceptual inheritance hierarchy, such as Animal - Mammal - Cat.
 If you want to encapsulate, and thereby make abstractions of, functionality. This is
good for someone who always wants to use the whole functionality, because the
functionality can become unnecessarily hard to grasp if the behavior structure is
centralized.

A Centralized Structure is Appropriate

 If the order in which the sub-event phases will be performed is likely to change.
 If you expect to insert new sub-event phases.
 If you want to keep parts of the functionality reusable as separate pieces.

4.5 Collaboration Diagram

Collaboration diagrams (known as Communication Diagram in UML 2.x) are used to
show how objects interact to perform the behavior of a particular use case, or a part of a
use case. Along with sequence diagrams, collaboration are used by designers to define
and clarify the roles of the objects that perform a particular flow of events of a use
case. They are the primary source of information used to determining class
responsibilities and interfaces.

What is a Collaboration?
 A Collaboration is a collection of named objects and actors with links
connecting them. They collaborate in performing some task.
 A Collaboration defines a set of participants and relationships that are
meaningful for a given set of purposes
 A Collaboration between objects working together provides emergent desirable
functionalities in Object-Oriented systems

31
Hospital management system

 Each object (responsibility) partially supports emergent functionalities

 Objects are able to produce (usable) high-level functionalities by working
together
 Objects collaborate by communicating (passing messages) with one another in
order to work together

Steps for Creating Collaboration Diagrams

1. Identify behavior whose realization and implementation is specified
2. Identify the structural elements (class roles, objects, subsystems) necessary to
carry out the functionality of the collaboration
 Decide on the context of interaction: system, subsystem, use case and
operation
3. Model structural relationships between those elements to produce a diagram
showing the context of the interaction
4. Consider the alternative scenarios that may be required
 Draw instance level collaboration diagrams, if required.
 Optionally draw a specification level collaboration diagram to
summarize the alternative scenarios in the instance level sequence
diagrams.

4.5.1 Contents of Collaboration Diagrams

You can have objects and actor instances in collaboration diagrams, together with links
and messages describing how they are related and how they interact. The diagram
describes what takes place in the participating objects, in terms of how the objects
communicate by sending messages to one another. You can make a collaboration diagram
for each variant of a use case's flow of events.

32
Hospital management system

A collaboration diagram that describes part of the flow of events of the Online Airline
Reservation System.
4.5.2 Constructs of Collaboration Diagram:
Objects
You can use objects in collaboration diagrams in the following ways:
 Each object in the collaboration is named and has its class specified

Object_name : class_name

 Not all classes need to appear

 There may be more than one object of a class

33
Hospital management system

 An object’s class can be unspecified. Normally you create a collaboration

diagram with objects first and specify their classes later.
 The objects can be unnamed, but you should name them if you want to
discriminate different objects of the same class.

Actors
 Each Actor is named and has a role
 One actor will be the initiator of the use case

Links
 A link is a relationship among objects across which messages can be sent. In
collaboration diagrams, a link is shown as a solid line between two objects.
 An object interacts with, or navigates to, other objects through its links to these
objects.
 A link can be an instance of an association, or it can be anonymous, meaning that
its association is unspecified.
 Message flows are attached to links.

Messages
A message is a communication between objects that conveys information with the
expectation that activity will ensue. In collaboration diagrams, a message is shown as a
labeled arrow placed near a link.

34
Hospital management system

Example

A sequence diagram that describes part of the flow of events of the use case Place Local
Call in a simple Phone Switch.

35
Hospital management system

4.6 Operation Contracts

Operation Contracts are defined in terms of system operations. Operations (say, methods)
that the system offers as a whole. The system is still a black box at this stage. The System
Sequence Diagrams show system events i.e., the SSD's messages. System operations
handle system events.

Operation Contract Syntax

 Name: AppropriateName
 Responsibilities: Perform a function
 Cross References: System functions and Use Cases
 Exceptions: None
 Pre-Conditions: Something or some relationship exists
 Post-Conditions: An association was formed

4.7 Class Diagram

Class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing, and documenting different aspects
of a system but also for constructing executable code of the software application. Class
diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of object
oriented systems because they are the only UML diagrams, which can be mapped
directly with object-oriented languages. Class diagram shows a collection of classes,
interfaces, associations, collaborations, and constraints. It is also known as a structural
diagram.
4.7.1 Purpose of Class Diagrams
The purpose of class diagram is to model the static view of an application. Class
diagrams are the only diagrams which can be directly mapped with object-oriented
languages and thus widely used at the time of construction. UML diagrams like activity
diagram, sequence diagram can only give the sequence flow of the application, however
class diagram is a bit different. It is the most popular UML diagram in the coder
community. The purpose of the class diagram can be summarized as
 Analysis and design of the static view of an application.

 Describe responsibilities of a system.

 Base for component and deployment diagrams.

 Forward and reverse engineering.

36
Hospital management system

4.7.2 How to Draw a Class Diagram?

 The name of the class diagram should be meaningful to describe the aspect of
the system.
 Each element and their relationships should be identified in advance.

 Responsibility (attributes and methods) of each class should be clearly

identified
 For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. At the
end of the drawing it should be understandable to the developer/coder.
 Finally, before making the final version, the diagram should be drawn on plain
paper and reworked as many times as possible to make it correct.
Class Diagram

37
Hospital management system

4.7.3 Relationships between Classes

 Generalization - an inheritance relationship

 inheritance between classes
 interface implementation
 Association - a usage relationship
 dependency
 aggregation
 composition

4.7.3.1 Generalization (Inheritance) Relationships

Class - solid line, black arrow
Abstract Class - solid line, white arrow

38
Hospital management system

Interface - dashed line, white arrow

4.7.3.2 Associational Relationships

1. Multiplicity (how many are used)
 * ⇒ 0, 1, or more
 1 ⇒ 1 exactly
 2..4 ⇒ between 2 and 4, inclusive
 3..* ⇒ 3 or more (also written as “3..”)
2. Name (What relationship the objects have)
3. Navigability (Direction)

4.7.4 Multiplicity of Associations

 One-to-One
Each student must carry exactly one ID card
 One-to-Many
One rectangle list can contain many rectangles

4.7.5 Association Types

Aggregation - “is part of” – symbolized by a clear white diamond.
Composition - “is entirely made of” – stronger version of aggregation – the parts live and
die with the whole – symbolized by a black diamond.
Dependency - “uses temporarily” – symbolized by dotted line – often is an
implementation detail, not an intrinsic part of that object's state.

4.8 State Chart Diagram

A state machine is a tool for describing the states the object can assume and the events
that cause the object to move from one state to another. State machines are most useful
for describing active classes. The use of state machines is particularly important for
defining the behavior. An example of a simple state machine is shown below:

39
Hospital management system

4.8.1 State Chart Diagram Symbols

States
States represent situations during the life of an object. You can easily illustrate a state in
Smart Draw by using a rectangle with rounded corners.

Transition
A solid arrow represents the path between different states of an object. A state can have a
transition that points back to itself.

Initial State
A filled circle followed by an arrow represents the object's initial state.

Final State
An arrow pointing to a filled circle nested inside another circle represents the object's
final state.

4.9 Data Model

The data model is a subset of the implementation model, which describes the logical and
physical representation of persistent data in the system.

4.9.1 The Relational Data Model

The most popular data model in DBMS is the Relational Model. It is more scientific a
model than others. This model is based on first-order predicate logic and defines a table
as an n-array relation.

 Data is stored in tables called relations.

40
Hospital management system

 Relations can be normalized.

 In normalized relations, values saved are atomic values.
 Each row in a relation contains a unique value.
 Each column in a relation contains values from a same domain.

4.9.2 Entity-Relationship Model

Entity-Relationship (ER) Model is based on the notion of real-world entities and
relationships among them. ER Model is best used for the conceptual design of a
database. ER Model is based on
 Entities and their Attributes.
 Relationship among Entities.
Entity - An entity in an ER Model is a real-world entity having properties
called attributes. Every attribute is defined by its set of values called domain. An entity in
an ER Model is a real-world entity having properties called attributes. Every attribute is
defined by its set of values called domain.

Relationship - The logical association among entities is called relationship. Relationships

are mapped with entities in various ways.

41
Hospital management system

Chapter 5: 2nd & 3rd Deliverable For structured Approach

5.1. Introduction:
Analysis & Design Model for structured approach must contain following artifacts:

1. Entity Relationship Diagram

2. Data Flow Diagram (Functional Model)
3. State Transition Diagram (Behavioral Model)
4. Architecture Design
5. Component Level Design

42
Hospital management system

5.2. Entity Relationship Diagram:

In the analysis model, Entity Relationship Diagram is used to understand the system
under consideration with respect to entities involved and their relationships. Each entity is
documented by extracted its attributes, cardinality, and modality.

Identify Attributes
The only attributes indicated are the names of the passengers, flights, bookings and
tickets.

5.3. Data flow diagram (Functional Model)

DFD is all about to identify the major processes in your system and develop Data Flow
Diagram up to required level.

DFD Constructs:

43
Hospital management system

Context Level DFD

A context diagram shows the context into which the business process fits. It also shows
the overall business process as just one process and shows all the outside entities that
receive information from or contribute information to the system.

44
Hospital management system

Level 1 Diagram
This diagram shows all the processes that comprise the overall system and how
information moves from and to each process. Data stores are added to it.

Level 2 Diagram

45
Hospital management system

This diagram shows all the processes that comprise a single process on the level 1
diagram and how information moves from and to each of these processes. It also shows in
more detail the content of higher-level process. Level 2 diagrams may not be needed for
all level 1 processes.

Level 3 Diagram
This diagram shows all processes that comprise a single process on the level 2 diagram
and how information moves from and to each of these processes. Level 3 diagrams may
not be needed for all level 2 processes. Correctly numbering each process helps the user
understand where the process fits into the overall system.

46
Hospital management system

Integrating Scenario Descriptions

DFDs generally integrate scenario descriptions
Names of use cases become processes
Names of inputs and outputs become data flows
Combining “small” data inputs and outputs into a single flow

Steps in Building DFDs

 Build the context level DFD

 Create DFD fragments for each scenario
 Organize DFD fragments into level 1
 Decompose level 1 DFDs as needed
 Validate DFDs with user

DFD Fragment Tips

 All process names must be verb phrases
 Maintain organization’s viewpoint in naming processes
 Layouts often place
 Processes in the center
 Inputs from the left
 Outputs to the right
 Stores beneath the processes

A DFD Fragment Example

47
Hospital management system

Context Level DFD

Context Level DFD

Context Level DFD

Level 1 DFD

48
Hospital management system

Illegal Data Flows:

49
Hospital management system

5.4. State Transition Diagram

State Transition Diagram is developed to represent the behavior of the system under
consideration. The constructs of STD are as follows:

State
A set of observable circum-stances that characterizes the behavior of a system at a given
time

State transition
The movement from one state to another

Event
An occurrence that causes the system to exhibit some predictable form of behavior

Action
Process that occurs as a consequence of making a transition

Guidelines for developing a state transition diagram

 Make a list of the different states of a system (How does the system behave?)
 Indicate how the system makes a transition from one state to another (How does the
system change state?)
 Indicate event
 Indicate action
 Draw a state transition diagram

50
Hospital management system

State Transition Diagram for Microwave

5.5. Architectural design

The Focus of architecture design is the Mapping of Requirements into Software
Architecture. DFD prepared in analysis model is analyzed to do it.

Two major structural patterns or two major alternatives are Transform (Flow) Analysis
and Transaction (Flow) Analysis.

Beginning the Design Process

 Review the fundamental system model i.e. DFD and Software Requirement
Specification document.
 Review and refine data flow diagrams for the software
 Determine whether DFD exhibits transform or transaction characteristics

Example
 There is a string conversion system.
 It has the ability to reverse strings, count number of characters, and append new
strings with an old string.
 A user would be using this system and would be providing the string to it. The
string would be validated. If approved the system would be displaying different
choices including reversal of string, character counting and appending of strings.

51
 Hospital management system

 The user would select a choice and enter the appropriate selection. According to
the selected choice the system would perform the required action.
 If “Reverse String” is selected the valid string is attained and reversed.
 If “Count Characters” is selected the valid string is attained and the number of
characters are counted.
 If “Append String” is selected the valid string is attained and the user also enters a
new string. Both the strings are appended together and the result produced.
 Whatever the choice selected the result is displayed.

See the diagrams on next page.

Context Level DFD

User Input Reversed String

Character Count
User Selection
User String Conversion System User

New String Appended String

User selection
1 2
User input Validat Display 3
Valid input choices
e the choice Ge t
input s user
selecti
on

String
Reverse String
Selection

4
Character
Revers
Count Append String
e
Selection Selection
String
Reversed String
String

5
Count New String
Charac 6
ters String
Appen
d
Character
String
Count
Appended
String

52
Hospital management system

Level 1 DFD

Level 2 DFD

4.1 4.2
String Get String String Reverse Reversed String
the String

5.2
5.1 Count
String String Character Count
Get String Characters
in String

6.3
6.1
String String Combine Appended String
Get String
Strings

6.2
Get new New String
String

53
 Hospital management system

Program Structure/Design Architecture

String Conversion
Executive Append
String
Display Controlle
Choices r

Get User Input

String Appen
Selection
Controlle d Str
Validate the
Input Count r
String Get
Controll Get
new
er Str
Str
Reverse
Processing
String
Controller
Controller
Read
Char. Display
Output
Increment
Reverse Count
String

54
Hospital management system

5.6. Component Level Design

Every component, which is appearing in program structure/design architecture, is
logically analyzed and pseudocode or flow chart is prepared for each module. This flow
chart is then given to programmer who translates it into a machine-readable code. The
options available for component level design are:

 Flow chart
 Box Diagram
 Decision Table
 Psuedocode

55