Oose Clearing House

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


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


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


4/73

Clearing House

Software Requirement

specificationIntroduction

Overall Description of proposed systemSystem features

Other Non-functional requirements

Interfaces

Use case model

4 ANITS-CSE


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


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


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/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


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


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


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


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


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


14/73

Clearing House

verify_druggist

View Patient Prescription

Login_druggist

Deliver medicines

Update Patient Acc Details

Druggist

Verify_tech


15/73

Clearing House

Analysis DocumentSequence DiagramsCollaboration Diagrams

State Chart Diagram

15 ANITS-CSE


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


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


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


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


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



9: show medicines

10: shows medicines

11: gives medicines

12: update account

13: updated

20 ANITS-CSE


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



9: show medicines

10: shows medicines

11: gives medicines

12: update account

13: updated

21 ANITS-CSE


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



9: views tests

10: perform tests

11: updates account

12: updated

22 ANITS-CSE


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


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


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


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


9: views tests

11: updates account


8: shows patient account12: updated

24 ANITS-CSE


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


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


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


28/73

Clearing House

System Design

DocumentClass Diagram

Database Design

Activity Diagram

Component Diagram

Deployment Diagram

28 ANITS-CSE


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


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


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


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


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


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


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


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


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


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.


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:



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:


38 ANITS-CSE


39/73

Clearing House


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


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


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


receptionist

2 Rusername Varchar2 10 Not Null


receptionist

3 Rpassword Varchar2 10 Not Null


the receptionist

3. Druggist:

41 ANITS-CSE


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


druggist

3 DGpassword Varchar2 10 Not Null


the druggist

4. Technician:

S.No FIELD

NAME

DATA

TYPE

MEMORY

ALLOCATION

RANGE Not Null

constraint

REMARKS

1 TID Number

5

Not Null


technician

2 Tusername Varchar2 10 Not Null


technician

3 Tpassword Varchar2 10 Not Null


the technician

5. Patient details:

42 ANITS-CSE


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


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



patient

2 DID Number 5 Not Null


doctor

3 Disease Varchar2 22 Gives the name of the

disease

43 ANITS-CSE


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



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


45/73

Clearing House

RANGE constraint



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


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


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


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


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


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


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


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


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


54/73

Clearing House

Screen Shots

Homepage

54 ANITS-CSE


55/73

Clearing House

Creating a New patient

55 ANITS-CSE


56/73

Clearing House

Login Page for Doctor

56 ANITS-CSE


57/73

Clearing House

Viewing Prescribed Medicines

57 ANITS-CSE


58/73

Clearing House

Updating the Medicine Bill

58 ANITS-CSE


59/73

Clearing House

Updating the patient test bills

59 ANITS-CSE


60/73

Clearing House

60 ANITS-CSE


61/73

Clearing House

Test Cases

Definition:

61 ANITS-CSE


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


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


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


65/73

Clearing House

Test Case for Login Doctor Module

Result For above module

65 ANITS-CSE


66/73

Clearing House

Test Case for Prescribe Medicines Module

66 ANITS-CSE


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


68/73

Clearing House

Test Case for Suggest tests Module

68 ANITS-CSE


69/73

Clearing House

Result for the above module when Patient Id is valid

69 ANITS-CSE


70/73

Clearing House

Result for the above module when Patient Id is invalid

70 ANITS-CSE


71/73

Clearing House

Test Case for Create Patient Module

71 ANITS-CSE


72/73

Clearing House

Test Case for Create Patient Module

72 ANITS-CSE


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

Documents

Oose Clearing House