PROJECT REPORT ON

“HOSPITAL MANAGMENT SYSTEM”

Report submitted in partial fulfilment of the requirement for the project work of V semester

Bachelor of Computer Applications [BCA]

OF

BANGALORE UNIVERSITY, BANGALORE

Submitted by:

1. VICTOR S : 16NMSB7077

2. MOHITH K : 16NMSB7024

3. SANTHOSH KUMAR YADAV : 16NMSB7050

Project Guide

Ms. PRIYA HARI ,MCA

Dept of Computer Science

Sindhi College, Kempapura

DEPARTMENT OF COMPUTER SCIENCE

 SINDHI COLLEGE
#33/2B, Hebbal, Kempapura, Bangalore.

PROJECT REPORT ON

“HOSPITAL MANAGEMENT SYSTEM”

Report submitted in partial fulfilment of the requirement for the project work of V semester
Bachelor of Computer Applications [BCA]
OF

BANGALORE UNIVERSITY, BANGALORE

Submitted by:

1.VICTOR S :16NMSB7077

2.MOHITH K :16NMSB7024

3.SANTHOSH KUMAR YADAV :16NMSB7050

Project Guide

Ms. PRIYA HARI , MCA

Dept of Computer Science

Sindhi College, Kempapura

DEPARTMENT OF COMPUTER SCIENCE

 SINDHI COLLEGE
#33/2B, Hebbal, Kempapura, Bangalore.
SINDHI COLLEGE

SINDHI COLLEGE

32/2B Hebbal Kempapura,Bangalore-560024

Phone:080-2363 7543/7544,4177 8288,Tele fax:23637544

Email:mail@sindhicollege.com, web: www.sindhicollege.com

CERTIFICATE

This is to certify that the project entitled

“HOSPITAL MANAGEMENT SYSTEM”

Submitted in partial fulfilment of the requirement for the award of the degree

Bachelor of Computer Applications [BCA]

Is a result of the bonafide work carried out by:

1.VICTOR S :16NMSB7077

2.MOHITH K :16NMSB7024

3.SANTHOSH KUMAR YADAV :16NMSB7050

During the academic year: 2018-19

Guide H.O.D Principal

Register Number: 16NMSB7077, 16NMSB7024,16NMSB7050
Date :
 SINDHI COLLEGE
Department of Computer Science [BCA]
(Permanently Affiliated to Bangalore University)
#32/2A,Kempapura,Hebbal,Bangalore-560024

CERTIFICATE
Awarded to _________________________________________________

This is to certify that the project entitled _______________________________

_________________________________________in practical fulfilment of the

requirement for the degree of Bachelor of Computer Applications of Bangalore

University.

Guide H.O.D Principal

Signature of Examiners

1. ____________

2. _____________
 GUIDE CERTIFICATE

This is a certificate that VICTOR S (16NMSB7077), MOHITH K (16NMSB7024)

,SANTHOSH SUMAR YADAV (16NMSB7050), of V Sem BCA, SINDHI COLLEGE --
Hebbal have successfully completed project entitled in partial fulfillment of the requirement
of the award of project.

“HOSPITAL
MANAGEMENT SYSTEM”
This project is based on original and independent work carried out under my
guidance and supervisor. This has formed the basis for the reward of any degree
or diploma of any other University or institution.

DATE: Ms.PRIYA HARI , MCA

PLACE: BANGALORE (Project Guide)

 ACKNOWLEDGEMENT

It gives me immense pleasure to mention the name of the people who made our project
report Possible .We sincerely thank Dr. B.S. Srikanta B.Sc(Hons) , M.Sc. ,Ph.D.
honourable principal of SINDHI COLLEGE, Vice principal Prof.Asha N
M.Com,MBA,M.Phil.,[Ph.D] for giving us this opportunity to take up this research. We
thank them for being a constant of inspiration and encouragement.

We immensely thank Prof.E.K Radhika MS(IT),[Ph.D], HOD, Computer Science

Dept., Ms.PRIYA HARI,MCA, Asst. Professor, Computer Science Dept. SINDHI
COLLEGE, for their guidance throughout the project without their continuous help,
suggestions and encouragement it would not have been possible for us to complete the
project effectively.

DATE :

PLACE : BANGALORE
 DECLARATION

We VICTOR S (16NMSB7077), MOHITH K (16NMSB7024), SANTHOSH

KUMAR YADAV (16NMSB7050) students of V Sem BCA, Sindhi College,
Bangalore do hereby declare that this project report on:

“HOSPITAL MANGEMENT SYSTEM”

Has been prepared by us, as partial fulfillment of the requirement of the BCA
program of Bangalore University (Batch of 2016-19). Our guide for the training is
Ms.PRIYA HARI ,MCA, Computer Science Dept. Sindhi College.

We further declare that this project report has not been submitted earlier to any
other University or Institution for the award of any Degree or Diploma.

Submitted by:
1.VICTOR S :16NMSB7077

2.MOHITH K :16NMSB7024

3.SANTHOSH KUMAR YADAV :16NMSB7050

DATE:

PLACE: BANGALORE
ABSTRACT
 ABSTRACT

Cloud computing as an emerging computing mode can be applied to the District Medical Data
Center. This is a new proposal raised in the paper. The rudiment of District Medical Data Center
based on cloud computing is established. A comparison is made between the samples from the
rudiment and the samples from the general systems. XML is suitable to both express the multi-
element unstructured data and exchange the complex data. The various standards for DMDC are
established. The advanced model of District Medical Data Center based on cloud computing is
described. The idea is also showed that the District Medical Data Center is as a service on the
cloud computing platform. In the future, cloud computing may be better approach to the next
generation of District Medical Data Center.
 INDEX
1) INTRODUCTION

1.1) About the Project

2) PROBLEM DEFINITION

2.1) Existing Project

2.2) Proposed System

3) SYSTEM ANALYSIS

3.1) Hardware and Software Specification

4. FEASIBILITY STUDY

4.1) Technical Feasibility

4.2) Economic Feasibility

4.3) Operational Feasibility

5) SYSTEM DESIGN

5.1) Data Flow Diagrams

5.2) DFD Symbols and Diagrams

653) UML Diagrams

5.4) ER-Diagrams

5.5) Database Design

6) TECHNOLOGIES USED

6.1) JAVA

6.2) About HTML

6.3) JAVA SCRIPT

6.4) JDBC

6.5) Servlets

6.6) About Oracle

7)TESTING

8) SCREEN SHOTS

9) CONCLUSION

10) SCOPE

11) BIBLIOGRAPHY
INTRODUCTION
INTRODUCTION

PROJECT OVERVIEW

The DMDC refer to the District Medical Data Center ,is infrastructure for the healthcare system
are many problems to be solved and many difficulties to be overcome in constructing the
national healthcare information system now, though great progress was made over the last 20
years. The essential reason is the lack of information integration. In various medical institutions
the clinical information for the patients is scattered, fragmented and isolated, it results at least
that obtaining useful information is very difficult meanwhile available information is idle. A lot
of information is reduplicate but inconsistent. In public health agencies, the basic information is
lacking for healthy people, it results at least that no database supported our decision that should
be made as soon as possible when major disaster or epidemic comes suddenly . The lack of
information integration makes high cost and low efficiency.
1.1 PROJECT DESCRIPTION

To construct DMDC, the common platform must be built, because a lot of heterogeneous
systems are serving now as the hospital systems in the large medical therapy units. Meanwhile
the heterogeneous management information systems are running in the government sectors.
Similar to the community health units are holding the different small-scale information
systems. These systems run well to support the daily work. It is very difficult and very cost to
integrate the heterogeneous systems because of the different servers, different databases and
different software architectures. The problems of maintenance are followed for the difference of
ownerships of systems. However a solution is present in the model of DMDC above, it’s not
standing effectively for long time. The reason is that the case is relatively closed system based
mainly on the intranet rather than opened system based on the Internet. No department can afford
independently not only the running expense but also technology for the DMDC. Cloud
computing can be the ability to rent servers and run the huge applications on the most powerful
systems available anywhere in Internet. Even to rent a virtual server, load software on it, turn it
on and off at will, or clone it many times to meet a sudden workload demand. The cloud
computing can be supported by a cloud provider that sets up a platform that includes the different
frameworks, the different OS, the different database and the different programming languages.
PROBLEM DEFINITION

2.1 Existing System:

In the existing system there is lack of information integration. In various medical

institutions the clinical information for the patients is scattered, fragmented and isolated; it
results difficult to obtain the meaningful information.

2.2 Proposed System:

The proposed system is aimed at integrating information on population in some region, including
various clinical diagnosis information and treatment information on patients in the different
medical institutions, also covering the various basic information on health
SYSTEM ANALYSIS
SYSTEM ANALYSIS

SOFTWARE REQUIREMENT SPECIFICATION

What is SRS?

Software Requirement Specification (SRS) is the starting point of the software

developing activity. As system grew more complex it became evident that the goal of the entire
system cannot be easily comprehended. Hence the need for the requirement phase arose. The
software project is initiated by the client needs. The SRS is the means of translating the ideas of
the minds of clients (the input) into a formal document (the output of the requirement phase.)

The SRS phase consists of two basic activities:

1) Problem/Requirement Analysis:

The process is order and more nebulous of the two, deals with understand the
problem, the goal and constraints.

2) Requirement Specification:

Here, the focus is on specifying what has been found giving analysis such as
representation, specification languages and tools, and checking the specifications are
addressed during this activity.

The Requirement phase terminates with the production of the validate SRS
document. Producing the SRS document is the basic goal of this phase.

ROLE OF SRS

The purpose of the Software Requirement Specification is to reduce the communication

gap between the clients and the developers. Software Requirement Specification is the medium
though which the client and user needs are accurately specified. It forms the basis of software
development. A good SRS should satisfy all the parties involved in the system.

SCOPE

This document is the only one that describes the requirements of the system. It is meant for the
use by the developers, and will also be the basis for validating the final delivered system. Any
changes made to the requirements in the future will have to go through a formal change approval
process. The developer is responsible for asking for clarifications, where necessary, and will not
make any alterations without the permission of the client.
SOFTWARE REQUIREMENT
SPECIFICATION
SOFTWARE REQUIREMENT SPECIFICATION

Software Requirements:

 Operating System : Windows XP

 Web Server : Tomcat
 Server side Technology : Servlets, JSP
 Client Side Technology : HTML, JavaScript
 Database : MySQL

Hardware Requirements:

 Pentium 4 processor

 1 GB RAM

 80 GB Hard Disk Space

FEASIBILITY STUDY
4. FEASIBILITY STUDY:

The next step in analysis is to verify the feasibility of the proposed system. “All projects
are feasible given unlimited resources and infinite time“. But in reality both resources and time
are scarce. Project should confirm to time bounce and should be optimal in there consumption of
resources. This place a constant is approval of any project.

Feasibility has applied to Digital Tune pertains to the following areas:

 Technical feasibility
 Operational feasibility
 Economical feasibility

4.1 TECHNICAL FEASIBILITY:

To determine whether the proposed system is technically feasible, we should take into
consideration the technical issues involved behind the system.

4.2 OPERATIONAL FEASIBILITY:

To determine the operational feasibility of the system we should take into

consideration the awareness level of the users. This system is operational feasible since the users
are familiar with the technologies and hence there is no need to gear up the personnel to use
system. Also the system is very friendly and to use.

4.3. ECONOMIC FEASIBILITY

To decide whether a project is economically feasible, we have to consider various factors as:

 Cost benefit analysis

 Long-term returns
 Maintenance costs
5.1 STUDY OF THE SYSTEM

To provide flexibility to the users, the interfaces have been developed that are accessible through
a browser. The GUI’S at the top level have been categorized as

1. Administrative user interface

2. The operational or generic user interface

The ‘administrative user interface’ concentrates on the consistent information that is practically,
part of the organizational activities and which needs proper authentication for the data collection.
These interfaces help the administrators with all the transactional states like Data insertion, Data
deletion and Date updation along with the extensive data search capabilities.

The ‘operational or generic user interface’ helps the end users of the system in transactions
through the existing data and required services. The operational user interface also helps the
ordinary users in managing their own information in a customized manner as per the included
flexibilities

5.2 INPUT & OUTPOUT REPRESENTETION

Input design is a part of overall system design. The main objective during the input design is as
given below:

 To produce a cost-effective method of input.

 To achieve the highest possible level of accuracy.
 To ensure that the input is acceptable and understood by the user.

INPUT STAGES:

The main input stages can be listed as below:

 Data recording
 Data transcription
  Data conversion
 Data verification
 Data control
 Data transmission
 Data validation
 Data correction

INPUT TYPES:

It is necessary to determine the various types of inputs. Inputs can be categorized as follows:

 External inputs, which are prime inputs for the system.

 Internal inputs, which are user communications with the system.
 Operational, which are computer department’s communications to the system?
 Interactive, which are inputs entered during a dialogue.

INPUT MEDIA:

At this stage choice has to be made about the input media. To conclude about the input
media consideration has to be given to;

 Type of input
 Flexibility of format
 Speed
 Accuracy
 Verification methods
 Rejection rates
 Ease of correction
 Storage and handling requirements
 Security
 Easy to use
  Portability
Keeping in view the above description of the input types and input media, it can be said that
most of the inputs are of the form of internal and interactive. As

Input data is to be the directly keyed in by the user, the keyboard can be considered to be the
most suitable input device.

OUTPUT DEFINITION

The outputs should be defined in terms of the following points:

 Type of the output
 Content of the output
 Format of the output
 Location of the output
 Frequency of the output
 Volume of the output
 Sequence of the output
It is not always desirable to print or display data as it is held on a computer. It should be decided
as which form of the output is the most suitable.

For Example

 Will decimal points need to be inserted

 Should leading zeros be suppressed.

OUTPUT MEDIA:

In the next stage it is to be decided that which medium is the most appropriate for the output. The
main considerations when deciding about the output media are:
  The suitability for the device to the particular application.
 The need for a hard copy.
 The response time required.
 The location of the users
 The software and hardware available.
Keeping in view the above description the project is to have outputs mainly coming under
the category of internal outputs. The main outputs desired according to the requirement
specification are:

The outputs were needed to be generated as a hard copy and as well as queries to be viewed on
the screen. Keeping in view these outputs, the format for the output is taken from the outputs,
which are currently being obtained after manual processing. The standard printer is to be used as
output media for hard copies.
 5.3 PROCESS MODEL USED WITH JUSTIFICATION

SDLC (Umbrella Model):

Umbrella
DOCUMENT CONTROL
Activity

Umbrella
Business Requirement Activity
Documentation

• Feasibility Study
Requirements • TEAM FORMATION
• Project ANALYSIS & CODE UNIT TEST ASSESSMENT
Gathering
Specification DESIGN
PREPARATION

INTEGRATION ACCEPTANCE
& SYSTEM TEST
DELIVERY/INS
TESTING
TALLATION

Umbrella
TRAINING
Activity
SDLC is nothing but Software Development Life Cycle. It is a standard which is used by
software industry to develop good software.

Stages in SDLC:

 Requirement Gathering
 Analysis
 Designing
 Coding
 Testing
 Maintenance
Requirements Gathering stage:

The requirements gathering process takes as its input the goals identified in the high-level
requirements section of the project plan. Each goal will be refined into a set of one or more
requirements. These requirements define the major functions of the intended application, define

operational data areas and reference data areas, and define the initial data entities. Major
functions include critical processes to be managed, as well as mission critical inputs, outputs and
reports. A user class hierarchy is developed and associated with these major functions, data
areas, and data entities. Each of these definitions is termed a Requirement. Requirements are
identified by unique requirement identifiers and, at minimum, contain a requirement title and

textual description.
 These requirements are fully described in the primary deliverables for this stage: the
Requirements Document and the Requirements Traceability Matrix (RTM). The requirements
document contains complete descriptions of each requirement, including diagrams and
references to external documents as necessary. Note that detailed listings of database tables and
fields are not included in the requirements document.

The title of each requirement is also placed into the first version of the RTM, along with
the title of each goal from the project plan. The purpose of the RTM is to show that the product
components developed during each stage of the software development lifecycle are formally
connected to the components developed in prior stages.

In the requirements stage, the RTM consists of a list of high-level requirements, or goals,
by title, with a listing of associated requirements for each goal, listed by requirement title. In this
hierarchical listing, the RTM shows that each requirement developed during this stage is
formally linked to a specific product goal. In this format, each requirement can be traced to a
specific product goal, hence the term requirements traceability.
 The outputs of the requirements definition stage include the requirements document, the
RTM, and an updated project plan.

 Feasibility study is all about identification of problems in a project.

 No. of staff required to handle a project is represented as Team Formation, in this case only
modules are individual tasks will be assigned to employees who are working for that project.
 Project Specifications are all about representing of various possible inputs submitting to the
server and corresponding outputs along with reports maintained by administrator
Analysis Stage:

The planning stage establishes a bird's eye view of the intended software product, and uses
this to establish the basic project structure, evaluate feasibility and risks associated with the
project, and describe appropriate management and technical approaches.

The most critical section of the project plan is a listing of high-level product requirements, also
referred to as goals. All of the software product requirements to be developed during the
requirements definition stage flow from one or more of these goals. The minimum information
for each goal consists of a title and textual description, although additional information and
references to external documents may be included. The outputs of the project planning stage are
the configuration management plan, the quality assurance plan, and the project plan and
schedule, with a detailed listing of scheduled activities for the upcoming Requirements stage,
and high level estimates of effort for the out stages.

Designing Stage:

The design stage takes as its initial input the requirements identified in the approved
requirements document. For each requirement, a set of one or more design elements will be
produced as a result of interviews, workshops, and/or prototype efforts. Design elements
describe the desired software features in detail, and generally include functional hierarchy
diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudo
code, and a complete entity-relationship diagram with a full data dictionary. These design
elements are intended to describe the software in sufficient detail that skilled programmers may
develop the software with minimal additional input.

When the design document is finalized and accepted, the RTM is updated to show that each
design element is formally associated with a specific requirement. The outputs of the design
stage are the design document, an updated RTM, and an updated project plan.
Development (Coding) Stage:

The development stage takes as its primary input the design elements described in the
approved design document. For each design element, a set of one or more software artifacts will
be produced. Software artifacts include but are not limited to menus, dialogs, data management
forms, data reporting formats, and specialized procedures and functions. Appropriate test cases
will be developed for each set of functionally related software artifacts, and an online help
system will be developed to guide users in their interactions with the software.

The RTM will be updated to show that each developed artifact is linked to a specific design
element, and that each developed artifact has one or more corresponding test case items. At this
point, the RTM is in its final configuration. The outputs of the development stage include a fully
functional set of software that satisfies the requirements and design elements previously
documented, an online help system that describes the operation of the software, an
implementation map that identifies the primary code entry points for all major system functions,
a test plan that describes the test cases to be used to validate the correctness and completeness of
the software, an updated RTM, and an updated project plan.
Integration & Test Stage:

During the integration and test stage, the software artifacts, online help, and test data are
migrated from the development environment to a separate test environment. At this point, all test
cases are run to verify the correctness and completeness of the software. Successful execution of
the test suite confirms a robust and complete migration capability. During this stage, reference
data is finalized for production use and production users are identified and linked to their
appropriate roles. The final reference data (or links to reference data source files) and production
user list are compiled into the Production Initiation Plan.

The outputs of the integration and test stage include an integrated set of software, an online
help system, an implementation map, a production initiation plan that describes reference data
and production users, an acceptance plan which contains the final suite of test cases, and an
updated project plan.

 Installation & Acceptance Test:

During the installation and acceptance stage, the software artifacts, online help, and initial
production data are loaded onto the production server. At this point, all test cases are run to
verify the correctness and completeness of the software. Successful execution of the test suite is
a prerequisite to acceptance of the software by the customer.

After customer personnel have verified that the initial production data load is correct and
the test suite has been executed with satisfactory results, the customer formally accepts the
delivery of the software.

The primary outputs of the installation and acceptance stage include a production
application, a completed acceptance test suite, and a memorandum of customer acceptance of the
software. Finally, the PDR enters the last of the actual labor data into the project schedule and
locks the project as a permanent project record. At this point the PDR "locks" the project by
archiving all software items, the implementation map, the source code, and the documentation
for future reference.

Maintenance:

Outer rectangle represents maintenance of a project, Maintenance team will start with
requirement study, understanding of documentation later employees will be assigned work and
they will under go training on that particular assigned category.

For this life cycle there is no end, it will be continued so on like an umbrella (no ending point to
umbrella sticks).

5.4 SYSTEM ARCHITECTURE

Architecture flow:

Below architecture diagram represents mainly flow of requests from users to database through
servers. In this scenario overall system is designed in three tires separately using three layers
called presentation layer, business logic layer and data link layer. This project was developed
using 3-tire architecture.

User

SERVER
Request Response

Data
Base
URL Pattern:

Presentation
Layer
Response sent URL Request
from the sent through the
servlet browser
SERVLETS
AT THE
SERVER
Reply from the SIDE Verifying or
database updating the
according to the database through a
statement statement

DATABASE

URL pattern represents how the requests are flowing through one layer to another layer and how
the responses are getting by other layers to presentation layer through server in architecture
diagram.
UML Diagrams

Class Diagram:
Sequence Diagram for Admin:

Admin HospitalDetails DoctorDetails patientDetails

Sequence Diagram for Patient:

patient login search register prescription schedule

Sequence Diagram for Doctor:

Doctor patient profile prescription schedule

CollaborationDiagram for Admin:

Admin Hospital
Details

Doctor patient
Details Details
Collaboration Diagram for Patient:

login

register

patient
schedule

prescript
ion

search
Collaboration Diagram for Doctor:

patient
profile

Doctor prescript
ion

schedule
Usecase Diagram for Admin:

Doctor details

patient details
Admin

hospital details
Usecase Diagram for Patient:

search

register
patient

login
Usecase Diagram for Doctor:

patientdetails

Doctor
schedule

prescrijption
Component Diagram for Admin:

Doctor
Details

patient
Admin Deatials

Hospital
Details
Component Diagram for Patient:

Login

patient Register

search
Component Diagram for Doctor:

patient
Details

Doctor prescription

schedule
Deployment Diagram for Admin:

Doctor
Details

patient
Details
Admin

Hospital
Details
Deployment Diagram for Patient:

Login

patient Register

Search

Component Diagram for Doctor:

patient
Details

prescrip
tion
Doctor

schedul
e
Object Diagram for Admin:
Object Diagram for Patient:
Object Diagram for Doctor:
Dataflow Diagram for DMDC:
StateDiagram for Admin:
State Diagram for Patien
Context Level Data Flow Diagram:
5. SYSTEM DESIGN

System design is transition from a user oriented document to programmers or data base
personnel. The design is a solution, how to approach to the creation of a new system. This is
composed of several steps. It provides the understanding and procedural details necessary for
implementing the system recommended in the feasibility study. Designing goes through logical
and physical stages of development, logical design reviews the present physical system, prepare
input and output specification, details of implementation plan and prepare a logical design
walkthrough.

The database tables are designed by analyzing functions involved in the system
and format of the fields is also designed. The fields in the database tables should define their role
in the system. The unnecessary fields should be avoided because it affects the storage areas of
the system. Then in the input and output screen design, the design should be made user friendly.
The menu should be precise and compact.

SOFTWARE DESIGN

MODULES:

 Admin module
 User module
 Government module

Modules of the Project:

There are mainly three modules in this project. They are,

1) Admin:
This module will maintain the Data of each Hospital, Doctor and Patients. Admin
will add Hospital Details like where exactly the Hospital is and address details of the
hospital etc. Then he will enter doctor details like Doctor Name, Doctor Designation
followed by in which area he is specialized in. These details will be shown to Patient who
are searching for specialist doctor for particular disease. Doctor won’t register directly in
our application Admin will make him register and Admin will pass Authenticated details
 like user id and password to Doctor with which Doctor will login and make interactions
with patients.

2) User:
This module is to search for the needed Data. Here User is referred to the Normal
Patient who is making use of our medical application. The Main purpose of our
application is to provide needed data like which doctor is specialized for the disease
patient suffering from. And patients are of two types, Namely Registered User and
Unregistered User.

Registered User: Registered user is one kind of patient in our application. He

will make use of our medical application in order to make interactions with
doctor. First Patient will make request to doctor in order to make prescription and
if doctor is interested he can make prescriptions and can make appointment with
the interested patient.

Unregistered User: This user can gain the information like which doctor is best
for giving treatment for particular disease. Unregistered User won’t make use of
all services provided by our application. Unregistered user will only searches for
the information. Like information needed for patient like which doctor is best in
giving treatment for particular disease. And unregistered user can’t access all
services provided by this application. If he wants he can register through our
application and can access the services provided by the application.
3) Government:
This module gives survey of patients suffering from different diseases. Here we
will get the details like how many patients are suffering from different diseases. This will
be helpful for the Government employees who will gather information for making
surveys on people who are suffering from different diseases. In our application we will
give authenticated user id and password for Government Employees with which they can
login and gain the services like finding number of people suffering from different
diseases.
Non functional requirements:

Performance:

The performance of the developed applications can be calculated by using following methods:

Measuring enables you to identify how the performance of your application stands in relation to
your defined performance goals and helps you to identify the bottlenecks that affect your
application performance. It helps you identify whether your application is moving toward or
away from your performance goals. Defining what you will measure, that is, your metrics, and
defining the objectives for each metric is a critical part of your testing plan.

Performance objectives include the following:

 Response time or latency

 Throughput
 Resource utilization

5.2Safty& Security:

The security design process is cyclical. The security of an application depends upon the vigilance
of the developers and administrators not just during the design phase but also for the life of the
application. Since new threats arise almost daily, an application must be scrutinized constantly
for potential security flaws. However, the initial design of an application determines how often
those flaws are likely to occur.

Security threats are any potential occurrence, malicious or otherwise, that can have an
undesirable effect on the application. Vulnerabilities in the application or operating system make
a threat possible. An attack on the application is an action taken by a malicious intruder to
exploit certain vulnerabilities in order to enact the threat. The risk involved is the potential
damage that attack can inflict on the application or even the business.
5.3Repudiability

Reputability is the notion of denying that an action occurred. Denying that you received an item,
when in fact you did, and expecting the vendor to supply you another is an example of
repudiability.

Actions that you would otherwise not want an unauthorized user to perform should be logged.
Such non-repudiability can also be obtained through the use of digital signatures and timestamps.
Additionally, digital signatures can be used to help provide non-repudiability.

5.4 Maintainability:

The increased complexity of modern software applications also increases the difficulty of
making the code reliable and maintainable. In recent years, many software measures, known as
code metrics, have been developed that can help developers understand where their code needs
rework or increased testing.

Developers can use Visual Studio Application Lifecycle Management to generate code metrics
data that measure the complexity and maintainability of their managed code. Code metrics data
can be generated for an entire solution or a single project.

5.6 Portability:

Portability is one of the key concepts of high-level programming. Portability is the software
codebase feature to be able to reuse the existing code instead of creating new code when moving
software from an environment to another. The prerequirement for portability is the generalized
abstraction between the application logic and system interfaces. When one is targeting several
platforms with the same application, portability is the key issue for development cost reduction.
TECHNOLOGIES USED
6) TECHNOLOGIES USED

System design is transition from a user oriented document to programmers or data base
personnel. The design is a solution, how to approach to the creation of a new system. This is
composed of several steps. It provides the understanding and procedural details necessary for
implementing the system recommended in the feasibility study. Designing goes through logical
and physical stages of development, logical design reviews the present physical system, prepare
input and output specification, details of implementation plan and prepare a logical design
walkthrough.

The database tables are designed by analyzing functions involved in the system
and format of the fields is also designed. The fields in the database tables should define their role
in the system. The unnecessary fields should be avoided because it affects the storage areas of
the system. Then in the input and output screen design, the design should be made user friendly.
The menu should be precise and compact.

SOFTWARE DESIGN

Modules:
There are mainly three modules in this project. They are,

1) Admin:
This module will maintain the Data of each Hospital, Doctor and Patients. Admin
will add Hospital Details like where exactly the Hospital is and address details of the
hospital etc. Then he will enter doctor details like Doctor Name, Doctor Designation
followed by in which area he is specialized in. These details will be shown to Patient who
are searching for specialist doctor for particular disease. Doctor won’t register directly in
our application Admin will make him register and Admin will pass Authenticated details
like user id and password to Doctor with which Doctor will login and make interactions
with patients.

2) User:
 This module is to search for the needed Data. Here User is referred to the Normal
Patient who is making use of our medical application. The Main purpose of our
application is to provide needed data like which doctor is specialized for the disease
patient suffering from. And patients are of two types, Namely Registered User and
Unregistered User.

Registered User: Registered user is one kind of patient in our application. He

will make use of our medical application in order to make interactions with
doctor. First Patient will make request to doctor in order to make prescription and
if doctor is interested he can make prescriptions and can make appointment with
the interested patient.
Unregistered User: This user can gain the information like which doctor is best
for giving treatment for particular disease. Unregistered User won’t make use of
all services provided by our application. Unregistered user will only searches for
the information. Like information needed for patient like which doctor is best in
giving treatment for particular disease. And unregistered user can’t access all
services provided by this application. If he wants he can register through our
application and can access the services provided by the application.

3) Government:
This module gives survey of patients suffering from different diseases. Here we
will get the details like how many patients are suffering from different diseases. This will
be helpful for the Government employees who will gather information for making
surveys on people who are suffering from different diseases. In our application we will
give authenticated user id and password for Government Employees with which they can
login and gain the services like finding number of people suffering from different
diseases.
 5.2 INPUT/OUTPUT DESIGN

Input design: considering the requirements, procedures to collect the necessary input data in
most efficiently designed. The input design has been done keeping in view that, the interaction
of the user with the system being the most effective and simplified way.

Also the measures are taken for the following

 Controlling the amount of input

 Avoid unauthorized access to the Music Store
 Eliminating extra steps
 Keeping the process simple
 At this stage the input forms and screens are designed.
Output design: All the screens of the system are designed with a view to provide the user with
easy operations in simpler and efficient way, minimum key strokes possible. Instructions and
important information is emphasized on the screen. Almost every screen is provided with no
error and important messages and option selection facilitates. Emphasis is given for speedy
processing and speedy transaction between the screens. Each screen assigned to make it as much
user friendly as possible by using interactive procedures. So to say user can operate the system
without much help from the operating manual.
OVERVIEW OF SOFTWARE
DEVELOPMENT TOOLS
7 OVERVIEW OF SOFTWARE DEVELOPMENT TOOLS

Java Technology
Java technology is both a programming language and a platform.

The Java Programming Language

The Java programming language is a high-level language that can be characterized by all
of the following buzzwords:

 Simple
 Architecture neutral
 Object oriented
 Portable
 Distributed
 High performance
 Interpreted
 Multithreaded
 Robust
 Dynamic
 Secure
With most programming languages, you either compile or interpret a program so that you can
run it on your computer. The Java programming language is unusual in that a program is both
compiled and interpreted. With the compiler, first you translate a program into an intermediate
language called Java byte codes —the platform-independent codes interpreted by the interpreter
on the Java platform. The interpreter parses and runs each Java byte code instruction on the
computer. Compilation happens just once; interpretation occurs each time the program is
executed. The following figure illustrates how this works.
 FIGURE 2- WORKING OF JAVA

You can think of Java bytecodes as the machine code instructions for the Java Virtual
Machine (Java VM). Every Java interpreter, whether it’s a development tool or a Web browser
that can run applets, is an implementation of the Java VM. Java bytecodes help make “write
once, run anywhere” possible. You can compile your program into bytecodes on any platform
that has a Java compiler. The bytecodes can then be run on any implementation of the Java VM.
That means that as long as a computer has a Java VM, the same program written in the Java
programming language can run on Windows 2000, a Solaris workstation, or on an iMac.

The Java Platform

A platform is the hardware or software environment in which a program runs. We’ve

already mentioned some of the most popular platforms like Windows 2000, Linux, Solaris, and
MacOS. Most platforms can be described as a combination of the operating system and
hardware. The Java platform differs from most other platforms in that it’s a software-only
platform that runs on top of other hardware-based platforms.

The Java platform has two components:

 The Java Virtual Machine (Java VM)
 The Java Application Programming Interface (Java API)
You’ve already been introduced to the Java VM. It’s the base for the Java platform and is
ported onto various hardware-based platforms.

The Java API is a large collection of ready-made software components that provide many useful
capabilities, such as graphical user interface (GUI) widgets. The Java API is grouped into
libraries of related classes and interfaces; these libraries are known as packages. The next
section, What Can Java Technology Do?, highlights what functionality some of the packages in
the Java API provide.
The following figure depicts a program that’s running on the Java platform. As the figure
shows, the Java API and the virtual machine insulate the program from the hardware.

FIGURE 3- THE JAVA PLATFORM

Native code is code that after you compile it, the compiled code runs on a specific
hardware platform. As a platform-independent environment, the Java platform can be a bit
slower than native code. However, smart compilers, well-tuned interpreters, and just-in-time
bytecode compilers can bring performance close to that of native code without threatening
portability.
What Can Java Technology Do?
The most common types of programs written in the Java programming language are
applets and applications. If you’ve surfed the Web, you’re probably already familiar with
applets. An applet is a program that adheres to certain conventions that allow it to run within a
Java-enabled browser.

However, the Java programming language is not just for writing cute, entertaining applets
for the Web. The general-purpose, high-level Java programming language is also a powerful
software platform. Using the generous API, you can write many types of programs.
An application is a standalone program that runs directly on the Java platform. A special
kind of application known as a server serves and supports clients on a network. Examples of
servers are Web servers, proxy servers, mail servers, and print servers. Another specialized
program is a servlet. A servlet can almost be thought of as an applet that runs on the server side.
Java Servlets are a popular choice for building interactive web applications, replacing the use of
CGI scripts. Servlets are similar to applets in that they are runtime extensions of applications.
Instead of working in browsers, though, servlets run within Java Web servers, configuring or
tailoring the server.
 How does the API support all these kinds of programs? It does so with packages of
software components that provide a wide range of functionality. Every full implementation of the
Java platform gives you the following features:
 The essentials: Objects, strings, threads, numbers, input and output, data structures,
system properties, date and time, and so on.
 Applets: The set of conventions used by applets.
 Networking: URLs, TCP (Transmission Control Protocol), UDP (User Data gram
Protocol) sockets, and IP (Internet Protocol) addresses.
 Internationalization: Help for writing programs that can be localized for users
worldwide. Programs can automatically adapt to specific locales and be displayed in the
appropriate language.
 Security: Both low level and high level, including electronic signatures, public and
private key management, access control, and certificates.
 Software components: Known as JavaBeansTM, can plug into existing component
architectures.
 Object serialization: Allows lightweight persistence and communication via Remote
Method Invocation (RMI).
 Java Database Connectivity (JDBCTM): Provides uniform access to a wide range of
relational databases.
The Java platform also has APIs for 2D and 3D graphics, accessibility, servers, collaboration,
telephony, speech, animation, and more. The following figure depicts what is included in the
Java 2 SDK.
FIGURE 4 – JAVA 2 SDK

ODBC

Microsoft Open Database Connectivity (ODBC) is a standard programming interface for

application developers and database systems providers. Before ODBC became a de facto
standard for Windows programs to interface with database systems, programmers had to use
proprietary languages for each database they wanted to connect to. Now, ODBC has made the
choice of the database system almost irrelevant from a coding perspective, which is as it should
be. Application developers have much more important things to worry about than the syntax that
is needed to port their program from one database to another when business needs suddenly
change.
Through the ODBC Administrator in Control Panel, you can specify the particular
database that is associated with a data source that an ODBC application program is written to
use. Think of an ODBC data source as a door with a name on it. Each door will lead you to a
particular database. For example, the data source named Sales Figures might be a SQL Server
database, whereas the Accounts Payable data source could refer to an Access database. The
physical database referred to by a data source can reside anywhere on the LAN.
The ODBC system files are not installed on your system by Windows 95. Rather, they
are installed when you setup a separate database application, such as SQL Server Client or
Visual Basic 4.0. When the ODBC icon is installed in Control Panel, it uses a file called
ODBCINST.DLL. It is also possible to administer your ODBC data sources through a stand-
alone program called ODBCADM.EXE. There is a 16-bit and a 32-bit version of this program,
and each maintains a separate list of ODBC data sources.

From a programming perspective, the beauty of ODBC is that the application can be
written to use the same set of function calls to interface with any data source, regardless of the
database vendor. The source code of the application doesn’t change whether it talks to Oracle or
SQL Server. We only mention these two as an example. There are ODBC drivers available for
several dozen popular database systems. Even Excel spreadsheets and plain text files can be
turned into data sources. The operating system uses the Registry information written by ODBC
Administrator to determine which low-level ODBC drivers are needed to talk to the data source
(such as the interface to Oracle or SQL Server). The loading of the ODBC drivers is transparent
to the ODBC application program. In a client/server environment, the ODBC API even handles
many of the network issues for the application programmer.

The advantages of this scheme are so numerous that you are probably thinking there must
be some catch. The only disadvantage of ODBC is that it isn’t as efficient as talking directly to
the native database interface. ODBC has had many detractors make the charge that it is too slow.
Microsoft has always claimed that the critical factor in performance is the quality of the driver
software that is used. In our humble opinion, this is true. The availability of good ODBC drivers
has improved a great deal recently. And anyway, the criticism about performance is somewhat
analogous to those who said that compilers would never match the speed of pure assembly
language. Maybe not, but the compiler (or ODBC) gives you the opportunity to write cleaner
programs, which means you finish sooner. Meanwhile, computers get faster every year.

JDBC
In an effort to set an independent database standard API for Java, Sun Microsystems
developed Java Database Connectivity, or JDBC. JDBC offers a generic SQL database access
mechanism that provides a consistent interface to a variety of RDBMSs. This consistent interface
is achieved through the use of “plug-in” database connectivity modules, or drivers. If a database
vendor wishes to have JDBC support, he or she must provide the driver for each platform that the
database and Java run on.
To gain a wider acceptance of JDBC, Sun based JDBC’s framework on ODBC. As you
discovered earlier in this chapter, ODBC has widespread support on a variety of platforms.
Basing JDBC on ODBC will allow vendors to bring JDBC drivers to market much faster than
developing a completely new connectivity solution.
JDBC was announced in March of 1996. It was released for a 90 day public review that ended
June 8, 1996. Because of user input, the final JDBC v1.0 specification was released soon after.
The remainder of this section will cover enough information about JDBC for you to know
what it is about and how to use it effectively. This is by no means a complete overview of JDBC.
That would fill an entire book.

JDBC Goals

Few software packages are designed without goals in mind. JDBC is one that, because of
its many goals, drove the development of the API. These goals, in conjunction with early
reviewer feedback, have finalized the JDBC class library into a solid framework for building
database applications in Java.
The goals that were set for JDBC are important. They will give you some insight as to
why certain classes and functionalities behave the way they do. The eight design goals for JDBC
are as follows:
1. SQL Level API
The designers felt that their main goal was to define a SQL interface for Java. Although not
the lowest database interface level possible, it is at a low enough level for higher-level tools and
APIs to be created. Conversely, it is at a high enough level for application programmers to use it
confidently. Attaining this goal allows for future tool vendors to “generate” JDBC code and to
hide many of JDBC’s complexities from the end user.

2. SQL Conformance
SQL syntax varies as you move from database vendor to database vendor. In an effort to
support a wide variety of vendors, JDBC will allow any query statement to be passed through it
to the underlying database driver. This allows the connectivity module to handle non-standard
functionality in a manner that is suitable for its users.

3. JDBC must be implemental on top of common database interfaces

The JDBC SQL API must “sit” on top of other common SQL level APIs. This goal allows
JDBC to use existing ODBC level drivers by the use of a software interface. This interface
would translate JDBC calls to ODBC and vice versa.
4. Provide a Java interface that is consistent with the rest of the Java system
Because of Java’s acceptance in the user community thus far, the designers feel that they should
not stray from the current design of the core Java system.

5. Keep it simple
This goal probably appears in all software design goal listings. JDBC is no exception.
Sun felt that the design of JDBC should be very simple, allowing for only one method of
completing a task per mechanism. Allowing duplicate functionality only serves to confuse the
users of the API.

6. Use strong, static typing wherever possible

Strong typing allows for more error checking to be done at compile time; also, less errors
appear at runtime.

7. Keep the common cases simple

Because more often than not, the usual SQL calls used by the programmer are simple
SELECT’s, INSERT’s, DELETE’s and UPDATE’s, these queries should be simple to perform
with JDBC. However, more complex SQL statements should also be possible.
Networking
Networking

TCP/IP stack

The TCP/IP stack is shorter than the OSI one:

FIGURE 5 – TCP/IP STACK

TCP is a connection-oriented protocol; UDP (User Datagram Protocol) is a connectionless

protocol.

IP datagram’s

The IP layer provides a connectionless and unreliable delivery system. It considers each
datagram independently of the others. Any association between datagram must be supplied by
the higher layers. The IP layer supplies a checksum that includes its own header. The header
includes the source and destination addresses. The IP layer handles routing through an Internet. It
is also responsible for breaking up large datagram into smaller ones for transmission and
reassembling them at the other end.
TCP

TCP supplies logic to give a reliable connection-oriented protocol above IP. It provides a
virtual circuit that two processes can use to communicate.

Internet addresses

In order to use a service, you must be able to find it. The Internet uses an address scheme
for machines so that they can be located. The address is a 32 bit integer which gives the IP
address. This encodes a network ID and more addressing. The network ID falls into various
classes according to the size of the network address.

Network address

Class A uses 8 bits for the network address with 24 bits left over for other addressing.
Class B uses 16 bit network addressing. Class C uses 24 bit network addressing and class D uses
all 32.

Subnet address

Internally, the UNIX network is divided into sub networks. Building 11 is currently on
one sub network and uses 10-bit addressing, allowing 1024 different hosts.

Host address

8 bits are finally used for host addresses within our subnet. This places a limit of 256
machines that can be on the subnet.
Total address

FIGURE 6 - IP ADDRESSING

The 32 bit address is usually written as 4 integers separated by dots.

Port addresses

A service exists on a host, and is identified by its port. This is a 16 bit number. To send a
message to a server, you send it to the port for that service of the host that it is running on. This
is not location transparency! Certain of these ports are "well known".

Sockets

A socket is a data structure maintained by the system to handle network connections. A

socket is created using the call socket. It returns an integer that is like a file descriptor. In fact,
under Windows, this handle can be used with Read File and Write File functions.

#include <sys/types.h>
#include <sys/socket.h>
int socket(int family, int type, int protocol);

Here "family" will be AF_INET for IP communications, protocol will be zero, and type will
depend on whether TCP or UDP is used. Two processes wishing to communicate over a network
create a socket each. These are similar to two ends of a pipe - but the actual pipe does not yet
exist.
SOFTWARE TESTING
7 .SOFTWARE TESTING

Testing
Software testing is a critical element of software quality assurance and
represents the ultimate review of specification, design and code generation.

7.1 TESTING OBJECTIVES

 To ensure that during operation the system will perform as per specification.
 TO make sure that system meets the user requirements during operation
 To make sure that during the operation, incorrect input, processing and output will
be detected
 To see that when correct inputs are fed to the system the outputs are correct
 To verify that the controls incorporated in the same system as intended
 Testing is a process of executing a program with the intent of finding an error
 A good test case is one that has a high probability of finding an as yet
undiscovered error

The software developed has been tested successfully using the following testing
strategies and any errors that are encountered are corrected and again the part of the program or
the procedure or function is put to testing until all the errors are removed. A successful test is one
that uncovers an as yet undiscovered error.

Note that the result of the system testing will prove that the system is working correctly.
It will give confidence to system designer, users of the system, prevent frustration during
implementation process etc.,
7.2 TEST CASE DESIGN:

White box testing

White box testing is a testing case design method that uses the control structure of the
procedure design to derive test cases. All independents path in a module are exercised at least
once, all logical decisions are exercised at once, execute all loops at boundaries and within their
operational bounds exercise internal data structure to ensure their validity. Here the customer is
given three chances to enter a valid choice out of the given menu. After which the control exits
the current menu.

Black Box Testing

Black Box Testing attempts to find errors in following areas or categories, incorrect or
missing functions, interface error, errors in data structures, performance error and initialization
and termination error. Here all the input data must match the data type to become a valid entry.

The following are the different tests at various levels:

Unit Testing:

Unit testing is essentially for the verification of the code produced during the
coding phase and the goal is test the internal logic of the module/program. In the Generic
code project, the unit testing is done during coding phase of data entry forms whether the
functions are working properly or not. In this phase all the drivers are tested they are rightly
connected or not.

Integration Testing:

All the tested modules are combined into sub systems, which are then tested. The goal is to
see if the modules are properly integrated, and the emphasis being on the testing interfaces
between the modules. In the generic code integration testing is done mainly on table
creation module and insertion module.
Validation Testing
This testing concentrates on confirming that the software is error-free in all respects. All the
specified validations are verified and the software is subjected to hard-core testing. It also aims at
determining the degree of deviation that exists in the software designed from the specification;
they are listed out and are corrected.

System Testing
This testing is a series of different tests whose primary is to fully exercise the computer-based
system. This involves:

 Implementing the system in a simulated production environment and testing it.

 Introducing errors and testing for error handling.

TYPES OF TESTS

Unit testing

Unit testing involves the design of test cases that validate that the internal program logicis
functioning properly, and that program input produce valid outputs.

All decisionbranches and internal code flow should be validated. It is the testing of individual
software units of the application .it is done after the completion of an individual unitefore
integration.
This is a structural testing, that relies on knowledge of its construction and is invasive. Unit tests
perform basic tests at component level and test a specific business process, application, and/or
system configuration. Unit tests ensure that each unique path of a business process performs
accurately to the documented specifications and contains clearly defined inputs and expected
results.

Integration testing
Integration tests are designed to test integrated software components to determine if they
actually run as one program. Testing is event driven and is more concerned with the basic
outcome of screens or fields. Integration tests demonstrate that although the components were
individually satisfaction, as shown by successfully unit testing, the combination of components is
correct and consistent. Integration testing is specifically aimed at exposing the problems that
arise from the combination of components.

Functional test
Functional tests provide a systematic demonstrations that functions tested are available as
specified by the business and technical requirements, system documentation , and user manuals.

Functional testing is centered on the following items:

Valid Input : identified classes of valid input must be accepted.

Invalid Input : identified classes of invalid input must be rejected.

Functions : identified functions must be exercised.

Output : identified classes of application outputs must be exercised.

Systems/Procedures : interfacing systems or procedures must be invoked.

Organization and preparation of functional tests is focused on requirements, key functions, or

special test cases. In addition, systematic coverage pertaining to identify

Business process flows; data fields, predefined processes, and successive processes must be
considered for testing. Before functional testing is complete, additional tests are identified and
the effective value of current tests is determined.

System Test
System testing ensures that the entire integrated software system meets requirements. It tests a
configuration to ensure known and predictable results. An example of system testing is the
configuration oriented system integration test. System testing is based on process descriptions
and flows, emphasizing pre-driven process links and integration points.
White Box Testing
White Box Testing is a testing in which in which the software tester has knowledge of the
inner workings, structure and language of the software, or at least its purpose. It is purpose. It is
used to test areas that cannot be reached from a black box level .

Black Box Testing

Black Box Testing is testing the software without any knowledge of the inner workings,
structure or language of the module being tested . Black box tests, as most other kinds of tests,
must be written from a definitive source document, such as specification or requirements
document, such as specification or requirements document. It is a testing in which the software
under test is treated, as a black box .you cannot “see” into it. The test provides inputs and
responds to outputs without considering how the software works.

7.1 Unit Testing:

Unit testing is usually conducted as part of a combined code and unit test phase of the
software lifecycle, although it is not uncommon for coding and unit testing to be conducted as
two distinct phases.

Test strategy and approach

Field testing will be performed manually and functional tests will be written in detail.

Test objectives

 All field entries must work properly.

 Pages must be activated from the identified link.
 The entry screen, messages and responses must not be delayed.
Features to be tested

 Verify that the entries are of the correct format

 No duplicate entries should be allowed
 All links should take the user to the correct page.
7.2 Integration Testing
Software integration testing is the incremental integration testing of two or more
integrated software components on a single platform to produce failures caused by interface
defects.

The task of the integration test is to check that components or software applications, e.g.
components in a software system or – one step up – software applications at the company level –
interact without error.

Integration testing for Database Synchronization:

 Testing the links that call the Change Username & password, Migration and
Synchronization screens etc.
 The username should be retained throughout the application in the form of hidden
variables or by using cookies.
 If the login user does not have enough privileges to invoke a screen, the link should be
disabled.
 Any modification in the Master server should be reflected in the Slave server.
 The XML file should retrieve only the records, which have been modified.

Test Results: All the test cases mentioned above passed successfully. No defects encountered.

7.3 Acceptance Testing

User Acceptance Testing is a critical phase of any project and requires significant
participation by the end user. It also ensures that the system meets the functional requirements.

Acceptance testing for Data Synchronization:

 Users have separate roles to modify the database tables.

 The timestamp for all insertions and updating should be maintained.
 Users should have the ability to modify the privilege for a screen.
 Once the Synchronization starts, the Master server or Slave Server should not be stopped
without notifying the other.
 The XML file should be generated in short time, i.e., before the next modification occurs.
Test Results: All the test cases mentioned above passed successfully. No defects encountered.
OUTPUT SCREENS
OUTPUT SCREENS
System Security
System Security:

Setting Up Authentication for Web Applications

Introduction:
To configure authentication for this project we provide login facility. In this element we define
the security realm containing the user credentials, the method of authentication, and the location
of resources for authentication.

8.2 SECURITY IN SOFTWARE

To set up authentication for Web Applications:

1. Open the web.xml deployment descriptor in a text editor or use the Administration
Console. Specify the authentication method using the <auth-method> element. The
available options are:

BASIC

Basic authentication uses the Web Browser to display a username/password dialog box.
This username and password is authenticated against the realm.

FORM

Form-based authentication requires that you return an HTML form containing the
username and password. The fields returned from the form elements must be: j_username
and j_password, and the action attribute must be j_security_check. Here is an example of
the HTML coding for using FORM authentication:

<form method="POST" action="j_security_check">

<input type="text" name="j_username">

<input type="password" name="j_password">

</form>
The resource used to generate the HTML form may be an HTML page, a JSP, or a
servlet. You define this resource with the <form-login-page> element.

The HTTP session object is created when the login page is served. Therefore, the
session.isNew () method returns FALSE when called from pages served after successful
authentication.
Conclusion
Conclusion:

The DMDC is related to the government the objective insuring the services of both the medical
and the healthcare of each citizen. So it’s also one of the major projects of “11th Five-Year Plan”
worked out by the Ministry of Science and Technology. The model of inchoate DMDC should
be built the “two layers” and the “duplex channels” through the “two lines”. It’s regarded as a
rudiment of District Medical Data Center based on cloud computing. As a case, “The Xiamen
Citizen Health Information System” shows the effect even though it’s based on not absolute
DMDC. The cloud computing is an emerging computing mode. It promises to increase the
velocity with which applications are deployed, increase innovation, and lower costs, all while
increasing business agility. The nature of cloud computing is useful for constructing the data
center. To the new generation of DMDC, cloud computing is better approach in the future.
BIBLIOGRAPHY
BIBLIOGRAPHY

Advanced Java Programming - Dietel and Dietel

Mastering JAVA 2 - John Zukowski

Java Server Programming - Apress

Software Engineering - Roger S Pressman

Análysis & Design of InformationSystems – Senn

Websites

www.eci.gov.in

www.google.com

www.apeci.com

www.askjeeves.com
THANKYOU 