8/4/2019 Oose Clearing House
1/73
Clearing House
Index
Problem Statement 7
Software Requirements Specification 8
1. Introduction 9
1.1 Purpose 9
1.2 Document Conventions 9
1.3 Intended audience and Reading suggestions 91.4 Project Scope 9
1.5 References 9
1.6 Definitions and Acronyms 10
2. Overall Description of proposed system 11
2.1 Product Perspective 11
2.2 Product Features 112.3User Characteristics 11
2.4 Design and Implementation constraints 11
2.5 Operating Environment 122.6 User Documentation 12
3. Functional Requirements 13
4. Other Non-functional requirements
4.1 Usability 15
4.2 Reliability 15
4.3 Supportability 154.4 Performance Requirements 15
4.5 Security requirements 15
4.6 Software Quality Attributes 15
5. Interfaces
1 ANITS-CSE
8/4/2019 Oose Clearing House
2/73
Clearing House
5.1 User Interfaces 16
5.2 Hardware Interfaces 16
5.3 Software Interfaces 16
6. Use case model 17
6.1 Identifying Actors 186.2 Identifying Use cases 18
Analysis Document 21
7. Sequence Diagrams 22
8. Collaboration Diagrams 42
9. State Chart Diagram 46
System Design Document 48
10. Class Diagram 49
11. Database Design 55
12. Component Diagram 74
13. Deployment Diagram 78
Screen Shots 79
Test Cases 84
Conclusion 91
Appendix A: Glossary 91
Bibliography 91
2 ANITS-CSE
8/4/2019 Oose Clearing House
3/73
Clearing House
Problem Statement
The main aim of this project is to automate the process of identification of Insurance to the
In/out patients who are treated by the hospitals and to develop convenient user interface using theDBMS and User Interface design tools so that atomicity, durability of the system is achieved whencompared to the file management systems.
The Project deals with identification of Insurance to the in/out patients who are treated by
the hospitals. The System identifies the patient, the insurance details and the responsible party. The
responsible party is the person who admits the patient. The patient details are collected and stored.The Insured party deals with the details of the insurance. Multiple insurances are also associated.
Ailment deals with the illness details of the patient. It also keeps track of the attorney and
organization details.The hospital also keeps track of facility and client details. The various payment codes, type
of service and place of service are also kept track of. The information is then sent to the insurance
companies for collection of expenditure met by the hospital for the treatment of the patient. None ofthe patient pays to the hospital for treatment. Instead of the payment by the patient his insurer is
identified and the bills submitted to collect the payment.
3 ANITS-CSE
8/4/2019 Oose Clearing House
4/73
Clearing House
Software Requirement
specificationIntroduction
Overall Description of proposed systemSystem features
Other Non-functional requirements
Interfaces
Use case model
4 ANITS-CSE
8/4/2019 Oose Clearing House
5/73
Clearing House
1. Introduction
1.1 Purpose
The system deals with bridging the public who are treated by hospitals /clinics where theyare treated and the insurance companies who will bare the cost of the treatment .The public
identifies a hospitals/clinics for treatment, undergoes the treatment without making any direct
payments .Instead they surrender the policy that would make up the cost of the treatment. Thehospitals in turn perform the business logic that would compute the payments to be claimed based
on the treatment to the patient. The claim is then referred to the insurance company who then verifythe claim before releasing the payment.
1.2 Document Conventions
The topographical conventions followed in the document are:1. Font used is Times New Roman.
2. Main headings with font size 26 in bold withunderline.3. Sub headings with font size 16.4. Regular paragraph writing in font size 12
1.3 Intended Audience and Reading Suggestions
This document is intended and suggested reading for the developer and project managers
who may add new features to the proposed project. Marketing staff who markets the project need toknow the features of the project to market it. The project users or the customers, those who actually
uses of the product, testers those who test the product, different database designers designing the
interfacing databases to the have to go through this document.
1.4 Project Scope
The intended purpose of this product is to book tickets for the customers both online byproviding a convenient user interface. The benefits obtained from the project are that the convenient
user interface online and ease of ticket booking online attracts more number of customers to book
ticket online and reduces the queues and the inconvenience caused to the customers due to the longqueues at the railway station gets reduced.
1.5 References
5 ANITS-CSE
8/4/2019 Oose Clearing House
6/73
Clearing House
The references used in designing this project are studying the way the hospital manages the data manually,
and studying the various insurance policies available their characteristics.
1.6 Definitions and Acronyms
Some of the following are the acronyms used in this project.
1. HTML: Hypertext Markup Language
2. ID: Identification
2. Overall Description of Proposed System
2.1 Product Perspective
Earlier maintenance systems demanded high amount of time for managing the information
as the data in the fields increased. Data updating was a tough task and retrieval also had the sameeffect. The origin of the product is to address all kinds of drawbacks or problems that are being
encountered in the latter maintenance systems.
2.2 Product Features
The hospital keeps track of facility and client details. The various payment codes, type of
service and place of service are also kept track of. The information is then sent to the insurancecompanies for collection of expenditure met by the hospital for the treatment of the patient. None of
the patient pays to the hospital for treatment. Instead of the payment by the patient his insurer isidentified and the bills submitted to collect the payment.
The hospital also maintains information about physicians and reference physicians. This
helps them understand the links of references and treatment made. All information about the
physician and reference physician are stored in the databases. Various reports are generated later tothe requirement of the end user. The data is supported with backup and recovery options.
The hospital maintains information about all patients as this helps them to meet history
requirements later when required. The hospital also stores information about all the insurancecompanies identifying them and related details. Whenever a new company is identified it is added
to the existing list of companies.
2.3 User Classes and Characteristics
Every User should be:1. Comfortable of working with the computer.2. He must have knowledge in medical field.3. He must have basic knowledge of English too.
According to the role of the users of the database are classified as
6 ANITS-CSE
8/4/2019 Oose Clearing House
7/73
Clearing House
1. Receptionist: The receptionist is the one who is responsible for maintaining the overall
system in the hospital.2. Doctor: The doctor is responsible for maintain his patient details in the database.
Others: the personnel at the diagnostic center, medical store can also interact with the system to update to the
user details
2.4 Operating Environment
Front end of the application is developed using the Java Servlets. Due to the vast advantages the
back end is maintained by the Oracle10g.
Operating System : Win98, win-XP or any other higher versions
Software Requirements : Backend--- Oracle10g.
Hardware Platform : 256 MB and above Main Memory
Hard disk Capacity - 40GB or more.Processor --- Pentium II and above or its equivalent.
2.5 Design and Implementation Constraints
Certain issues limit the options available to the developers. The developer cannot provide a
uniform access to all the user groups to maintain a friendly environmentAs a primary measure they restrict the access to particular group to reduce the illegal access
and security intrusion. Some other restrictions are1. GUI is in English only2. Login and Password is used for identification of user and there is no facility for guest.
2.6 User Documentation
A complete user manual is provided with the end product to troubleshoot any problems that
occur during the lifecycle of the tool. It comprises of vital information regarding the distribution of
the access, backend information i.e. the E-R diagrams used in construction, the mappings, key
constraints and the general interface module prototypes.
3. Functional Requirements
The maintenance of the in/out patients and to automate the process of insurance clearancethe following functional requirements have been identified.1. Each patient is given a unique id pid.
2. If the patient has aarogyasri card then we need to record the details of the policy.
3. Each doctor is given a unique id and we have to record the reference physicians for every patient.
4. All the expenditures for the patient will be logged to the database.5. If patient doesnt have an aarogyasri card then the patient pays the bill directly to the hospital
7 ANITS-CSE
8/4/2019 Oose Clearing House
8/73
Clearing House
6. If the patient had an aarogyasri card then the hospital claims for the insurance on behalf of the
respective patient.
7. Each Druggist is given a unique id dgid.8. A druggist can supply the medicines to the patient and can update the medicines cost into the patient
account details.
9. Each Technician is given a unique id tid.
10. A technician can perform tests to the patients and he can update the diagnosis cost into the patient
account details.
11. Each Receptionist is given a unique id rid.
12. A Receptionist can maintain details about the patient and account details about the patient.
13. A Receptionist can also check whether the patient has paid the bill or not.
4. Other Nonfunctional Requirements
4.1 Usability
Our main criteria for making the system usable is the difficulty of performing each high frequency
use case. Difficulty depends on the number of steps, the knowledge that the user must have at eachstep, the decisions that the user must make at each step, and the mechanics of each step. The user
interface should be as familiar as possible to users who have used other web applications and
Windows desktop applications.
4.2 Reliability
The products automatic upgrade feature will help us easily deploy defect fixes to the end-users.
The user guide and product website will include troubleshooting guide and checklist of information
to have at hand before contacting technical support.
4.3 Supportability
Supportability is our ability to provide cost effective technical support.
4.4 Performance Requirements
There is a better component design to get better performance at peak time. Each and every
schema is normalized to the maximum normal form that can be attained to get better performanceand low redundancy.
4.5 Security Requirements
Secure access of confidential data (users details) and constrained access of information to
the regular NetUsers who can only book tickets. Only database administrator has the total access tothe system and requires authentication by the system.
8 ANITS-CSE
8/4/2019 Oose Clearing House
9/73
Clearing House
4.6 Software Quality Attributes
The project is designed based on a flexible service based architecture which will be helpful
for future extension
5. Interfaces
5.1 User Interfaces
The project provides GUI forms to the users for easy understanding and application. Thescreens are designed in JAVA. The project offers different menus to the user to select from the
given options.
5.2 Hardware Interfaces
Monitor screen the software shall display information to the user via the monitor screen.
Mouse the software shall interact with the movement of the mouse and the mouse buttons.The mouse shall activate areas for data input, command buttons and select options from
menus.
Keyboard the software shall interact with the keystrokes of the keyboard. The keyboard
will input data into the active area of the database.
5.3 Software Interfaces
Windows is the operating system employed in this project as a software interface.
6. Use case Model
Use cases are used during the requirements elicitation and analysis to represent functionality of
the system. Use cases focus on the behavior of the system from an external point of view. In its
simplest form, a use case can be described as a specific way of using the system from a users
(actors) perspective. Use cases describe the
1. a pattern of behavior the system exhibits
2. a sequence of related transactions performed by an actor and the system
3. delivering something of value to the actor
Use cases provide a means to
9 ANITS-CSE
8/4/2019 Oose Clearing House
10/73
Clearing House
1. capture system requirements
2. communicate with the end users and domain experts
3. test the system
Use cases are best discovered by examining the actors and defining what the actor will be ableto do with the system. Since all the needs of a system typically cannot be covered in one use case, it
is usual to have a collection of use cases. Together this use case collection specifies all the ways ofusing the system.
In a use case diagram there can be two kinds of relationships
1. Association Relationship
An association provides a pathway for communication. The communication can be between usecases, actors, classes or interfaces. Associations are the most general of all relationships and
consequentially the most semantically weak. If two objects are usually considered independently,
the relationship is an association
2. Generalization Relationship
A generalize relationship is a relationship between a more general class or use case and a more
specific class or use case. A generalization is shown as a solid-line path from the more specificelement to a more general element. The tip or a generalization is a large hollow triangle pointing to
the more general element.
Subclass Superclass
3. Extend Relationship
An extend relationship is a stereotyped relationship that specifies how the functionality of one
use case can be inserted into the functionality of another use case. Extend relationships between use
cases are modeled as dependencies by using the Extend stereotype.
10 ANITS-CSE
8/4/2019 Oose Clearing House
11/73
Clearing House
Extend relationships are important because they show optional functionality or system behavior.
For example, Rational Rose allows you to place crop marks on printed diagrams.
4. Include Relationship
An include relationship is a stereotyped relationship that connects a base use case to an
inclusion use case. An include relationship specifies how behavior in the inclusion use case is used
by the base use case.
Include relationships are important because they represent that the inclusion use case
functionality is used by the base use case.
6.1 Identifying Actors
1. Doctor: He is the one who prescribes medicines and suggests test to the patient. In order todo that he need to get registered with a valid user-ID and Password to login into his account.
2. Receptionist: He is the one who maintains the details of the patient. He also need to getregistered with a valid user-ID and Password to login into his account.
3. Druggist: He is the one who gives medicines to the patient prescribed by the doctor and
passes the bill to the receptionist.
4. Technician: He is the one who performs the required tests to the patient and passes the bill
to the receptionist.
6.2 Identifying Usecases
1. Doctor_Login: Login for doctor in order to treat the patient.
2. Receptionist_Login: Login for receptionist in order to view the patient details.
3. Druggist_Login: Login for druggist in order to give medicines to the patient.
4. Technician_Login: Login for technician in order to perform test to the patient.
5. register: In this the user is provided to get registered on the system in order to become a
legitimate user and access the services provided by the system. In order to get registered auser has to provide the details necessary for the registration as asked by the system.
11 ANITS-CSE
8/4/2019 Oose Clearing House
12/73
Clearing House
6. check PNR status: This functionality is the only operation provided to the anonymous
users. A user can anonymously check his PNR status by providing the PNR number in the
column provided.
7. enquiry: A user can perform the following enquiries on the system.
a) Availability Enquiry: Enquiring regarding the availability of berths in a particulartrain.
b) Cost Enquiry: User can provide the train no., destination and source directly to get
the cost of travel.
8. delete account: A user can delete his account if he wishes to.
9. bookTicket: A user can book ticket online by providing his credit card number.
10.cancellation: A user can cancel a ticket booked by him on the website by providing the
PNR No. of the ticket and his account number to which the cancellation amount is to be
credited.
11.requests by passenger: A passenger traveling by can make the following requests to the
Netuser
a) requestForReservation
b) requestForCancellation
c) requestForEnquiry
12 ANITS-CSE
8/4/2019 Oose Clearing House
13/73
Clearing House
Verify
Add
Delete
Update
View
login
Create patient acoount
Delete patient account
Patient acc details
Receptionist
Verify_doctor
Login_doctor
Patient Details
Doctor Prescribe Medicines
Update Patient acc details
Suggests Tests
Use Case Diagram for Receptionist and Doctor
13 ANITS-CSE
8/4/2019 Oose Clearing House
14/73
Clearing House
verify_druggist
View Patient Prescription
Login_druggist
Deliver medicines
Update Patient Acc Details
Druggist
Verify_tech
8/4/2019 Oose Clearing House
15/73
Clearing House
Analysis DocumentSequence DiagramsCollaboration Diagrams
State Chart Diagram
15 ANITS-CSE
8/4/2019 Oose Clearing House
16/73
Clearing House
7. Sequence Diagrams
Sequence diagrams represent the objects participating in the interaction horizontally and
time vertically. Each column represents an object that participates in the interaction. Messages areshown by solid arrows. Labels on solid arrows represent message names and may contain
arguments. Activations are depicted by the vertical rectangles. The actor who initiates theinteraction is shown in the use case diagrams. If other actors communicate with the system duringthe use case, these actors are represented on the right hand side and can receive messages. Although
for simplicity, interactions among objects and actors are uniformly represented as messages, the
modeler should keep in mind that interactions between actors and the system are of a differentnature than interactions among objects. These diagrams can be used to describe either an abstract
sequence or concrete sequences. When describing all possible interactions, sequence diagrams also
provide notations for conditionals and iterations. A condition on a message is denoted by anexpression in brackets before the message name. If the expression is true the message is sent.
Repetitive invocation of a message is denoted by a * before the message name.
16 ANITS-CSE
8/4/2019 Oose Clearing House
17/73
Clearing House
7.1 Create Patient Account:
:Patient :Receptionist :System
1: Approaches
2: Opens page
3: Enter name,pswd
4: R_name,****
5: Validates
6: Login successful
Create Patient Account
7: Opens Patient details form
8: Displays form
9: Asks details
10: Gives details
11: Fills form
12: Verifies and updates
13: Displays Patient acc form
14: Gives form
17 ANITS-CSE
8/4/2019 Oose Clearing House
18/73
Clearing House
7.2. Delete Patient Account:
:Patient :Receptionist :System
1: Approaches
2: Opens page
3: Enter name,pswd
4: R_name,****
5: Verifies
6: Login successful
7: Opens patient form
8: Displays form
9: Asks patient id
10: P_id
11: Delete patient account
12: VerifiesPatient acct details
13: Successfully deleted
18 ANITS-CSE
8/4/2019 Oose Clearing House
19/73
Clearing House
7.3. Doctor:
:patient :doctor :system
1: patient approaches doctor
2: asks for id
3: gives id
4: logins
5: login successful
6: enter patient id
7: enters patient id
8: shows patient account
9: prescribes medicines
10: updated medicines
11: tells how to use medicines
19 ANITS-CSE
8/4/2019 Oose Clearing House
20/73
Clearing House
7.4. Druggist:
:patient :druggist :system
1: patient approaches druggist
2: asks for id
3: gives id
4: logins
5: login successful
6: enter patient id
7: enters patient id
8: shows patient account
9: show medicines
10: shows medicines
11: gives medicines
12: update account
13: updated
20 ANITS-CSE
8/4/2019 Oose Clearing House
21/73
Clearing House
:patient :druggist :system
1: patient approaches druggist
2: asks for id
3: gives id
4: logins
5: login successful
6: enter patient id
7: enters patient id
8: shows patient account
9: show medicines
10: shows medicines
11: gives medicines
12: update account
13: updated
21 ANITS-CSE
8/4/2019 Oose Clearing House
22/73
Clearing House
7.5 Technician:
:patient :technician :system
1: patient approaches technician
2: asks for id
3: gives id
4: logins
5: login successful
6: enter patient id
7: enters patient id
8: shows patient account
9: views tests
10: perform tests
11: updates account
12: updated
22 ANITS-CSE
8/4/2019 Oose Clearing House
23/73
Clearing House
8. Collaboration Diagrams
A collaboration diagram also called a commutation diagram is an illustration of the
relationships and interactions among software objects in the unified modeling language (UML).This concept although more than a decade old, has been refined as a model paradigm and evolved.
A collaboration diagram resembles a flowchart that portrays the roles, functionality and
behavior of individual objects as well as the overall operation of the system in real time. Objects are
shown as rectangles with naming labels inside. These labels are preceded by colons and may beunderlined. The relationships between the objects are shown as arrows connecting the relevant
rectangles along with labels that define message sequencing.
They are best suited to the portrayal of simple interactions among relatively small numbers
of objects. As the number of objects and messages grow, a collaboration diagram can become
difficult to read.
8.1 Doctor:
:system:patient :doctor
1: patient approaches doctor
3: gives id
2: asks for id
11: tells how to use medicines
4: logins
7: enters patient id9: prescribes medicines
5: login successful6: enter patient id
8: shows patient account
10: updated medicines
8.2 Receptonist:
:receptionist
:system:patient
3: verifies
9: verifies and upates
2: enters username,password
5: opens new patient's form
8: enters patient details
4: login successful10: gives id no.
1: approaches
7: gives details
6: asks details11: gives id no
23 ANITS-CSE
8/4/2019 Oose Clearing House
24/73
Clearing House
8.3 Druggist:
:system:patient :druggist
1: patient approaches druggist3: gives id
2: asks for id11: gives medicines
4: logins7: enters patient id9: show medicines12: update account
5: login successful6: enter patient id
8: shows patient account10: shows medicines
13: updated
8.4Technician:
:patient :technici
an:system
1: patient approaches technician
3: gives id
2: asks for id
10: perform tests
4: logins
7: enters patient id
9: views tests
11: updates account
5: login successful6: enter patient id
8: shows patient account12: updated
24 ANITS-CSE
8/4/2019 Oose Clearing House
25/73
Clearing House
9. State Chart Diagrams
A state chart diagram is a graph that represents a state machine. State chart
diagrams represent the behavior of entities capable of dynamic behavior by specifying its responseto the receipt of event in stances.
State charts, often used more in real-time embedded systems than in information
systems, show for a class, the order in which incoming calls to operations normally occur and the
conditions under which the operations respond and the response. They are a class-centric view ofsystem functionality, as opposed to sequence and collaboration diagrams which are a use case-
centric view of functionality.
Purpose
To model dynamic aspect of a system.
To model life time of a reactive system.
Describe different states of an object during its life time.
To define a state machine to model states of an object.
Components of State Chart Diagrams
1. States - oblong boxes which indicate the stable states of the object between events
2. Transitions - the solid arrows which show possible changes of state
3. Events - the text on the transitions before the '/' showing the incoming call to the object interface
which causes the change of state.
4. Conditions - a Boolean statement in square brackets which qualifies the event
5. Actions - the text after the '/' which defines the objects response to the transition between states.
6. Extra syntax which defines state centric functionality.
9.1 Create account
takedetails
createsaccount
gives id
25 ANITS-CSE
8/4/2019 Oose Clearing House
26/73
Clearing House
9.2 View details
opensform
selects
optionviews
detailscloses
form
9.3 Update details
selects
option
opens
formupdates
detailscloses
form
9.4 Delete account
opensform
selectsoption
deletes
accountclose
9.5 Update medicine details
opens
form
collects
money
updates
detailsclose
9.6 Doctor views patient details
asks id takes id opensaccount
selectsoption
viewsdetailsclosesaccount
9.7 Doctor suggests medicines
asks id takes id opensaccount
selectsoption
suggestsmedi...
closesaccount
26 ANITS-CSE
8/4/2019 Oose Clearing House
27/73
Clearing House
9.7 Doctor suggests medicines
BMasks id takes id opensaccount
selectsoption
closesaccount
9.8 Druggist supplies medicines
asks id takes id opens
account
selects
optionview
medicinesrequired
gives medicinesrequiredclosesaccount
9.9 Technician performs tests
asks id takes id opens
account
selects
optionviews tests to be
done
performs testsupdates
accountclosesaccount
27 ANITS-CSE
8/4/2019 Oose Clearing House
28/73
Clearing House
System Design
DocumentClass Diagram
Database Design
Activity Diagram
Component Diagram
Deployment Diagram
28 ANITS-CSE
8/4/2019 Oose Clearing House
29/73
Clearing House
10. Class Diagram
Class diagrams describe the structure of the system in terms of classes and objects. Classes
are abstractions that specify the attributes and behavior of set of objects. A class is a collection ofobjects that share a set of attributes that distinguish the objects as members of the collection.
Objects are entities that encapsulate state and behavior. Each object is distinguishable from others.
Classes and objects are depicted by the boxes composed of three components. The top
compartment displays the name of the class or object. The centre compartment displays its attributes
and the bottom compartment displays the functions performed by it. The object names are
underlined to indicate that they are instances. By convention, class name starts with uppercase letter
and object name starts with lowercase letter. The type of an attribute is used to specify the validrange of the values the attribute can take. When attributes types are not essential to the definition of
the system, attribute type decisions can be delayed until object design.
Inheritance
A very important concept in object-oriented design, inheritance, refers to the ability of one
class (child class) to inheritthe identical functionality of another class (super class), and then add
new functionality of its own. To model inheritance on a class diagram, a solid line is drawn from
the child class (the class inheriting the behavior) with a closed arrowhead (or triangle) pointing to
the super class.
Association
There are 5 types of associations
Bi-directional (standard) association
An association is a linkage between two classes. Associations are assumed to be bi-
directional -- in other words, both classes are aware of their relationship and of the other class --
unless you qualify the association as some other type of association. A bi-directional association isindicated by a solid line between the two classes. At either end of the line, we place a role same and
a multiplicity value
Unidirectional association
29 ANITS-CSE
8/4/2019 Oose Clearing House
30/73
Clearing House
A unidirectional association shows that two classes are related, but only one class knows
that the relationship exists. A unidirectional association is drawn as a solid line with an open
arrowhead (not the closed arrowhead, or triangle, used to indicate inheritance) pointing to the
known class.
Association class
In modeling an association, there are times when you need to include another class because
it includes valuable information about the relationship. For this you would use an association class
that you tie to the primary association. An association class (also called a drop classby my former
professor) is represented like a normal class. The difference is that the association line between the
primary classes intersects a dotted line connected to the association class.
Aggregation
Aggregation is a special type of relationship used to model a "whole to its parts"
relationship. In basic aggregation relationships, the lifecycle of a partclass is independent from the
whole class's lifecycle.
Composition aggregation
The composition aggregation relationship is just another form of the aggregation
relationship, but the child class's instance lifecycle is dependent in the parent class's instance
lifecycle.
Description of various classes present in the project:
1). Class Name: Doctorcan prescribe medicines and suggest tests.
Attributes: 1) did : string
2) dpassword : string
3) dusername : string
Functions: 1) patientdetails()
2) prescrbemedicines()
3) suggesttests()
30 ANITS-CSE
8/4/2019 Oose Clearing House
31/73
Clearing House
2). Class Name: Druggistgives medicines to the patient and sends the bill to the receptionist.
Attributes: 1) dgid : string
2) dgpassword : string
3) dgusername : string
Functions: 1) addpatientmedicinedetails()
2) updatepatientmedicinedetails()
3). Class Name: Receptionistmaintains patient account details and patient details.Attributes: 1) rid : string
2) rpassword : string
3) rusername : string
Functions: 1) patientdetails()
2) patientaccountdetails()
4). Class Name: Techniciantperforms tests to the patient and passes bills to the receptionist.Attributes: 1) tid : string
2) tpassword : string
3) tusername : string
Functions: 1) addpatientdiagnosisdetails()
2) updatepatientdiagnosisdetails()
31 ANITS-CSE
8/4/2019 Oose Clearing House
32/73
Clearing House
10.1 Doctor:
prescribemedicians
patient id
medician name
read()
suggest tests
patient idtest name
read()
patient detailspatient name
patient id
select()
operationoperation name
select operation()
doctorname
password
login()
viewpatient id
display()
addpatient id
patient name
add()
deletepatient id
delete()
updatepatient id
update()
10.2 Druggist:
32 ANITS-CSE
8/4/2019 Oose Clearing House
33/73
Clearing House
add patient med details
patient id
patient name
med name
add()
delete patient med details
patient id
med name
delete()
update
patient id
med name
update()
operation
operation name
select operation()
druggist
name
password
login()
10.3 Receptionist:
33 ANITS-CSE
8/4/2019 Oose Clearing House
34/73
Clearing House
patient details
pd operation name
select pd()
patient account details
pad operation name
select pad()
add patient
patient id
patient name
add()
delete patient
patient id
delete()
update
patient id
update()
view
patient id
display()
add patientpatient id
patient name
add()
View
patient id
display()
delete patient
patient id
delete()
update
patient id
update()
operation
operation names
select operation()
receptionist
name
password
login()
10.4 Technician:
34 ANITS-CSE
8/4/2019 Oose Clearing House
35/73
Clearing House
add patient diag details
patient id
patient name
diag name
add()
delete patient diag details
patient id
diag name
delete()
update patientdiag details
patient id
diag name
update()
operation
operation name
select operation()
technician
name
password
login()
11. Database Design
11.1 Entity-Relation Ship Model
To start-off with the back end the essential structure that is to be considered is the E-
R diagram. The E-R, Entity-Relationship diagram is just an approximate description of the data,
constructed through a subjective evaluation of the information collected during requirement
analysis. The E-R diagram is constructed by the usage of the following symbols.
35 ANITS-CSE
8/4/2019 Oose Clearing House
36/73
Clearing House
11.2 Description of Entity sets
1. Doctor:
He is the one who prescribes medicines and suggests test to the patient. In order to
do that he need to get registered with a valid user-ID and Password to login into his account.
Doctor-id : Unique for given doctor.
36 ANITS-CSE
8/4/2019 Oose Clearing House
37/73
Clearing House
D-Password: Personal identification for the given doctor id.
Primary Key is d-id.
2. Receptionist:
He is the one who maintains the details of the patient. He also needs to get registered
with a valid user-ID and Password to login into his account. It has the following attributes.
Receptionist-id : Unique for the given receptionist.
R-Password : Personal identification for the given receptionist id.
Primary key is r-id.
3. Druggist:
He is the one who gives medicines to the patient prescribed by the doctor and passesthe bill to the receptionist.
Druggist-id : Unique for given druggist.
Dg-Password : Personal identification for the given druggist id.
Primary Key is dg-id.
4. Technician:
He is the one who performs the required tests to the patient and passes the bill to the
receptionist. It has the following attributes.
Technician-id : Unique for the given technician.
T-Password : Personal identification for the given technician id.
Primary key is t-id.
5. Patient details:
It is an entity set which has the following attributes.
pid : Unique number for patient.
Pname : Gives the name of the patient.
Page : Gives the age of the patient.
37 ANITS-CSE
8/4/2019 Oose Clearing House
38/73
Clearing House
Psex : Gives the sex of the patient.
Paddress : Gives the address of the patient.
Pphoneno : Gives the phone number of the patient.
pdoj : Tells about when the patient has joined in the hospital.
Primary key is pid.
6. Patient account details:
It has additional attributes.
pid : Unique number for patient.
did : Unique number for doctor.
disease : Gives the name of the disease of the patient.
mcost : Gives the total medicines cost of the patient.
hcost : Gives the total tests cost of the patient.
tcost : Gives the total cost of the patient.
Aarogyasri : Tells whether the patient has aarogyasri card or not.
Paid : Tells about whether the patient has paid the bill or not.
Foreign keys are pid and did.
7. Patient medicines details:
It is an entity set which has the following attributes.
pid : Unique number for patient.
Mname : Gives the name of the medicines.
Mnum : Gives the number of medicines taken by the patient.
Date1 : Gives the date when the patient has taken the medicines.
Foreign key is pid.
8. Patient medicines details:
It is an entity set which has the following attributes.
38 ANITS-CSE
8/4/2019 Oose Clearing House
39/73
Clearing House
pid : Unique number for patient.
Dname : Gives the name of the diagnosis.
Date2 : Gives the date when the patient has taken the tests.
Foreign key is pid.
11.3 Description of Relationship sets
1. Holds_acctdetails is a relationship between Receptionist and the Patient account details. It is
a 1: N cardinality relationship having one receptionist and may have N patient account
details.
2. Holds_details is a relationship between Receptionist and patient details. It is also a 1: Ncardinality relationship having one receptionist and N number of patients.
3. Update_medicinedetails is a relationship between the entities Druggist and the Patient
account details. It is a 1: N cardinality relationship with one Druggist and multiple patient
account details.
4. Update_diagnosisdetails is a relationship between the entities Technician and the Patient
account details. It is a 1: N cardinality relationship with one Technician and multiple patient
account details.
5. Supplies_medicines is a relationship between the entities Druggist and the Patient medicinedetails. It is a 1: N cardinality relationship with one druggist and multiple patient medicine
details.
6. Performs_tests is a relationship between the entities Technician and the Patient diagnosis
details. It is a 1: N cardinality relationship with one technician and multiple patient
diagnosis details.
7. Prescibes_medicines is a relationship between the entities Doctor and patient medicine
details. It is 1: N cardinality relationship with one Doctor and many patient medicine details.
8. Suggests_Tests is a relationship between the entities Doctor and Patient diagnosis details. It
is a 1: N cardinality relationship with one Doctor with many patient diagnosis details.
39 ANITS-CSE
8/4/2019 Oose Clearing House
40/73
Clearing House
ER Diagram for Clearing House
11.4 Final List of Tables
1. DOCTOR (DID,DUSERNAME,DPASSWORD )
2. DRUGGIST (DGID,DGUSERNAME,DGPASSWORD)
3. PATIENTDETAILS (PID, PNAME, PAGE, PSEX, PADDRESS, PPHONENO, PDOJ)
4. RECEPTIONIST (RID, RUSERNAME, RPASSWORD).
5. PATIENTACCOUNTDETAILS (PID, DID, DISEASE, MCOST, DCOST,HCOST,
TCOST, AROGYASRI, PAID)
6. PATIENTDIAGNOSISDETAILS (PID, DNAME, DATE2)
7. PATIENTMEDICINEDETAILS(PID, MNAME, MNUM,DATE1)
40 ANITS-CSE
8/4/2019 Oose Clearing House
41/73
Clearing House
11.5 Prototype Tables
1. Doctor:
S.No FIELD
NAME
DATA
TYPE
MEMORY
ALLOCATION
RANGE Not Null
constraint
REMARKS
1 DID Number
5
Not Null
Used to identify the
doctor
2 Dusername Varchar2 10 Not Null
Gives the name of the
doctor
3 DPassword Varchar2 10 Not Null
Gives the password of
the doctor
2. Receptionist:
S.No FIELD
NAME
DATATYPE
MEMORY
ALLOCATION
RANGE Not Nullconstraint
REMARKS
1 RID Number
5
Not Null
Used to identify the
receptionist
2 Rusername Varchar2 10 Not Null
Gives the name of the
receptionist
3 Rpassword Varchar2 10 Not Null
Gives the password of
the receptionist
3. Druggist:
41 ANITS-CSE
8/4/2019 Oose Clearing House
42/73
Clearing House
S.No FIELD
NAME
DATA
TYPE
MEMORY
ALLOCATION
RANGE Not Null
constraint
REMARKS
1 DGID Number
5
Not Null
Used to identify thedruggist
2 Dgusername Varchar2 10 Not Null
Gives the name of the
druggist
3 DGpassword Varchar2 10 Not Null
Gives the password of
the druggist
4. Technician:
S.No FIELD
NAME
DATA
TYPE
MEMORY
ALLOCATION
RANGE Not Null
constraint
REMARKS
1 TID Number
5
Not Null
Used to identify the
technician
2 Tusername Varchar2 10 Not Null
Gives the name of the
technician
3 Tpassword Varchar2 10 Not Null
Gives the password of
the technician
5. Patient details:
42 ANITS-CSE
8/4/2019 Oose Clearing House
43/73
Clearing House
S.No FIELD
NAME
DATA
TYPE
MEMORY
ALLOCATION
RANGE Not Null
constraint
REMARKS
1 PID Number 5 Not Null
Used to identify thepatient
2 Pname Varchar2 10 Not Null
Gives the name of the
patient
3 Page. Varchar2 2 Gives the age of the
patient
4 psex Varchar2 20 Gives the sex of the
patient
5 Paddress Varchar2 20 Gives the address of the
patient
6. Pphoneno Varchar2 10 Not Null Gives the phone
number of the patient
7. Pdoj Date Not Null Gives the date of when
the patient has joined in
the hospital
6. Patient account details:
S.No FIELD
NAME
DATA
TYPE
MEMORY
ALLOCATION
RANGE Not Null
constraint
REMARKS
1 PID Number 5 Not Null
Used to identify the
patient
2 DID Number 5 Not Null
Used to identify the
doctor
3 Disease Varchar2 22 Gives the name of the
disease
43 ANITS-CSE
8/4/2019 Oose Clearing House
44/73
Clearing House
4 Mcost Number 5 Gives the medicines cost
5 Dcost Number 5 Gives the diagnosis cost
6 Hcost Number 5 Gives the hospital cost
7 Tcost Number 5 Gives the total cost
8. Aarogyasri Varchar2 5 Specifies whether the
patient has aarogyasri
card or not
9. Paid Varchar2 5 Specifies whether the
patent had paid the bill
or not
7. Patient medicine details:
S.No FIELD
NAME
DATA
TYPE
MEMORY
ALLOCATION
RANGE
Not Null
constraint
REMARKS
1 PID Number 5 Not Null
Used to identify the
patient
2 Mname Varchar2 5
Gives the names of the
medicines
3 Mnum Varchar2 10
Gives the number of
medicines taken by the
patient
4 Date1 Date
Gives the date of
medicine purchased
8. Patient diagnosis details:
S.No FIELD
NAME
DATA
TYPE
MEMORY
ALLOCATIONNot Null REMARKS
44 ANITS-CSE
8/4/2019 Oose Clearing House
45/73
Clearing House
RANGE constraint
1 PID Number 5 Not Null
Used to identify the
patient
2 Dname Varchar2 5
Gives the names of the
diagnosis
3 Date2 Date
Gives the date of
diagnosis conducted
12. Activity Diagram
Activity diagrams are diagram technique showing workflows of stepwise activities and
actions, with support for choice, iteration and concurrency. In the UML, activity diagrams can be
used to describe the business and operational step-by-step workflows of components in a system.
An activity diagram shows the overall flow of control.
Activity diagrams should be used in conjunction with other modeling techniques such as
interaction diagrams and state diagrams The main reason to use activity diagrams is to model the
workflow behind the system being designed. Activity Diagrams are also useful for: analyzing a use
case by describing what actions needs to take place and when they should occur; describing a
complicated sequential algorithm; and modeling applications with parallel processes.
Components of Activity Diagrams
Activity diagrams are constructed with a limited set of building blocks, consisting of:
Nodes - like initial node and activity final node, and.
Activity building blocks, and
Sometimes activity diagrams also contain building block for decision-making, but it is
questionable if these diagrams should be called activity diagram.
The starting point of the diagram is the initial node, which is mostly located on top or on the
left. And the ending of the diagram with an activity final node is on the bottom or on the right. In
45 ANITS-CSE
8/4/2019 Oose Clearing House
46/73
Clearing House
between there can be zero, one or more activity building blocks, which can be represented by
rounded rectangles.
12.4. Doctor:
46 ANITS-CSE
8/4/2019 Oose Clearing House
47/73
Clearing House
start system
openhomepage
did,*****
pid
enters
suggests
entername,password
enter pid
pd
displaysdetails
entermedicines
suggest test
operationcompleted
valid
no
available
no
updated
updated indatabase
yes
yes
databasesystemdoctor
12.4. Druggist:
47 ANITS-CSE
8/4/2019 Oose Clearing House
48/73
Clearing House
yes
start system
openhomepage
dgid,****
pid
entername,password
enterpatient id
view patientmedicines update patientacc.details
operationcompleted
valid
available
updated
no
no
yes
databasesystemdruggist
12.3. Technician:
48 ANITS-CSE
8/4/2019 Oose Clearing House
49/73
Clearing House
start system
openhomepage
tid,****
pid
entername,password
enterpatient id
view patienttests
update patientacc.details
operationcompleted
valid
available
updated
no
no
yes
yes
databasesystemtechnician
12.4. Receptionist:
49 ANITS-CSE
8/4/2019 Oose Clearing House
50/73
Clearing House
NewAcstartthe system
open home
page
r_id,password
p_id
enters
pid
P_id
P_ id
enter nameand password
operations
enter p_id
display pid
enter patientdetails
enter pid
deletepatient
Enter p_id
updatedetails
enterp_id
displayPAD
operationcompleted
valid
no
yes
available
no
yes
updatedatabase
availyes no
Updatedatabase
availno
uPdatedatabase
Avail
yes
yes
no
data basesystemreceptionist
50 ANITS-CSE
8/4/2019 Oose Clearing House
51/73
Clearing House
13. Component Diagram
Component diagrams provide a physical view of the current model. A component diagram
shows the organizations and dependencies among software components, including source code
components, binary code components, and executable components. These diagrams also show theexternally-visible behavior of the components by displaying the interfaces of the components.
Calling dependencies among components are shown as dependency relationships between
components and interfaces on other components. Note that the interfaces actually belong to the
logical view, but they can occur both in class diagrams and in component diagrams
Component diagrams contains
Component packages
Components
Interfaces
Dependency relationships
Component packages represent clusters of logically related components, or major pieces of
your system. Component packages parallel the role played by logical packages for class diagrams.
They allow you to partition the physical model of the system.
A Component represents a software module (source code, binary code, executable, DLL,
etc.) with a well-defined interface. The interface of a component is represented by one or several
interface elements that the component provides. Components are used to show compiler and run-
time dependencies, as well as interface and calling dependencies among software modules. They
also show which components implement a specific class.
A system may be composed of several software modules of different kinds. Each software
module is represented by a component in the model. To distinguish different kinds of componentsfrom each other, stereotypes are used.
An interface specifies the externally-visible operations of a class and/or component, and has
no implementation of its own. An interface typically specifies only a limited part of the behavior of
a class or component.
51 ANITS-CSE
8/4/2019 Oose Clearing House
52/73
Clearing House
A Dependency is a relationship between two model elements in which a change to one
model element will affect the other model element. Use a dependency relationship to connect
model elements with the same level of meaning. Typically, on class diagrams, a dependency
relationship indicates that the operations of the client invoke operations of the supplier.
System
Doctor
Receptionist
Technician
Druggist
database
Patientdetails
Prescribe medicines
Suggest tests
Add patient medicine details
Update patient medicine details
Patient account details
Patient details
Add patient diagnosis details
Update patient diagnosis details
Component Diagram for Clearing House
52 ANITS-CSE
8/4/2019 Oose Clearing House
53/73
Clearing House
14. Deployment Diagram
A deployment diagram in the Unified Modeling Language serves to model the physicaldeployment of artifacts on deployment targets. Deployment diagrams show "the allocation of
Artifacts to Nodes according to the Deployments defined between them." Deployment of an artifact
to a node is indicated by placing the artifact inside the node.
Instances of nodes (and devices and execution environments) are used in deployment
diagrams to indicate multiplicity of these nodes. For example, multiple instances of an application
server execution environment may be deployed inside a single device node to represent application
server clustering.
Systemkeyboard
Printer
mouse
Deployment Diagram for Clearing House
53 ANITS-CSE
8/4/2019 Oose Clearing House
54/73
Clearing House
Screen Shots
Homepage
54 ANITS-CSE
8/4/2019 Oose Clearing House
55/73
Clearing House
Creating a New patient
55 ANITS-CSE
8/4/2019 Oose Clearing House
56/73
Clearing House
Login Page for Doctor
56 ANITS-CSE
8/4/2019 Oose Clearing House
57/73
Clearing House
Viewing Prescribed Medicines
57 ANITS-CSE
8/4/2019 Oose Clearing House
58/73
Clearing House
Updating the Medicine Bill
58 ANITS-CSE
8/4/2019 Oose Clearing House
59/73
Clearing House
Updating the patient test bills
59 ANITS-CSE
8/4/2019 Oose Clearing House
60/73
Clearing House
60 ANITS-CSE
8/4/2019 Oose Clearing House
61/73
Clearing House
Test Cases
Definition:
61 ANITS-CSE
8/4/2019 Oose Clearing House
62/73
Clearing House
Testing is the process of finding differences between the expected behavior specified by the
system model and the observed behavior of the implemented system.
Description:
It is a fault detection technique that tries to create failures or erroneous states in a plannedway. This allows the developer to detect failures in the system before it is released to the customer.
System testing is an expensive process but it is required in order to achieve a complete system.
Generally the users tend to think that the process of providing that there do not exist, any errors inthe system forms the testing part.
Types of Testing:
Unit Testing:
1. the most micro scale of testing.
2. A unit is smallest software component3. Objects and methods
4. Procedures and functions5. Performed by programmer and units are tested in isolation.
6. Ensure that system is working according build design.
7. Not to be confused with debugging.8. Also known as component, module testing
Integration Testing:
1. Testing of more than one (tested) unit together to determine if they function correctly.
2. Focuses on interfaces of Communication between units3. It is done using the integration test design prepared during the architecture design.4. Helps assembling incrementally a whole system, ensuring the correct flow of data
5. Done by developers/designers and testers in collaboration
6. Also called Interface Testing or Assembly Testing.
System Testing:
Testing the system as a whole - Black-box type testing that is based on overall requirements
specifications; covers all combined parts of a system.
1. Ensures that system meets all functional and business requirements.
2. Focus on verifying that specifications are met3. Validating that the system can be used for the intended purpose
4. The system test design is derived from the system design documents and is used in this phase.
5. It can involve a number of specialized types of tests to check performance, stress, documentationetc. Sometimes testing is automated using testing tools one by Independent testing group
Acceptance testing
1. To determine whether a system satisfies its acceptance criteria and business requirements or not.
62 ANITS-CSE
8/4/2019 Oose Clearing House
63/73
Clearing House
2. Similar to System testing in that the whole system is checked, but the important difference is the
change in focus.
3. Done by real business users.4. It enables the customer to determine whether to accept the system or not.
Test Cases:A test case is a set of input data and expected results that exercises the component with the
purpose of causing failures and detecting faults. Test cases are classified into black box test and
white box test. Black box test focuses on input/output behavior of the component. White box testfocuses on the internal structure of the components.
63 ANITS-CSE
Module Name Prescribe Medicines
Test Case To prescribe Medicines for a patient
Input Patient Id
Output A Page asking the medicine name and quantity fo the medicine
Module Name Login Doctor
Test Case To log on to the doctors account
Input Valid User name ,password
Output A page showing the Trains available operations that doctor can perform
Module Name Suggest tests
Test Case To suggest a test for the patient
Input Patient Id
Output A page asking the test name
8/4/2019 Oose Clearing House
64/73
Clearing House
64 ANITS-CSE
Module Name Create Patient
Test Case To create a new patient account
Input Patient Id,name,age sex,address,phone number,arogya sri, card
no,complaint,reference physician id
Output A page Showing that New patient account has been created
8/4/2019 Oose Clearing House
65/73
Clearing House
Test Case for Login Doctor Module
Result For above module
65 ANITS-CSE
8/4/2019 Oose Clearing House
66/73
Clearing House
Test Case for Prescribe Medicines Module
66 ANITS-CSE
8/4/2019 Oose Clearing House
67/73
Clearing House
Result for above module when Patient Id is valid
Result for above module when Patient Id is invalid
67 ANITS-CSE
8/4/2019 Oose Clearing House
68/73
Clearing House
Test Case for Suggest tests Module
68 ANITS-CSE
8/4/2019 Oose Clearing House
69/73
Clearing House
Result for the above module when Patient Id is valid
69 ANITS-CSE
8/4/2019 Oose Clearing House
70/73
Clearing House
Result for the above module when Patient Id is invalid
70 ANITS-CSE
8/4/2019 Oose Clearing House
71/73
Clearing House
Test Case for Create Patient Module
71 ANITS-CSE
8/4/2019 Oose Clearing House
72/73
Clearing House
Test Case for Create Patient Module
72 ANITS-CSE
8/4/2019 Oose Clearing House
73/73
Clearing House
Conclusion
The project can be applied for any kind of Railway reservation systems with simple modifications
and by interfacing with the Railway employee database and corresponding bank database which
provide the net banking services by the use of credit cards. The convenient user interface provided
is easy to use and increases the scope of use of the railway network making it easy to access andbook tickets.
Appendix A: Glossary
PNR is an important number that is written on the top left corner of a Rail Ticket. The
abbreviation PNR stands for Passenger Name Record. Actually, PNR is a travel record of a person
or a group of persons in the database of Computer Reservation System (CRS). In practical terms,PNR has five parts that are essential in order to get a booking done. The five parts or requisites of
PNR number are as follows.
1. Passenger(s) Name
2. Travel Agent's Contact Details3. Details of Ticket (could be a ticket number or ticketing time limit)
4. Itinerary as a minimum of one segment that should be similar for all passengers listed.
5. Person's Name, who makes the booking
Bibliography
1. The Unified Modeling Language Reference Manual - James Rumbaugh, Ivar Jacobson,Grady Booch- Addison Wesley
2. Object Oriented Software Engineering Using UML, Patterns and Java, Second Edition -Bernd Bruegge, Allen H. Dutoit, Pearson Education
3. Database Management Systems-Third Edition (IE) - Raghu Ramakrishnan, JohannesGerkhe, Mc Graw Hill Edition.
4. Database System concepts-Fifth Edition (IE) -Abraham Silberschatz, Henry F.Korth,
S.Sudarshan, Mc Graw Hill Edition.5. Fundamentals of Database Systems-Fifth Edition (IE) Ramez Elamasri, Shamkanth
B.Navathe, Pearson Education.
6. Oracle 9i, The Complete Reference Oracle Press - Kevin Loney, George Koch, Tata McGraw Hill Edition.
7. Head First Java Servlets and JSP - Bryan Basham, Kathy Sierra and Bert Bates, ORielly