Académique Documents
Professionnel Documents
Culture Documents
OF
Submitted by:
MOHITH K : 16NMSB7024
Project Guide
SINDHI COLLEGE
#33/2B, Hebbal, Kempapura, Bangalore.
PROJECT REPORT ON
Submitted by:
MOHITH K :16NMSB7024
Project Guide
SINDHI COLLEGE
#33/2B, Hebbal, Kempapura, Bangalore.
SINDHI COLLEGE
SINDHI COLLEGE
CERTIFICATE
CERTIFICATE
Awarded to _________________________________________________
1. ____________
2. _____________
GUIDE CERTIFICATE
“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.
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. for giving us this opportunity to take up this research. We
thank them for being a constant of inspiration and encouragement.
DATE :
PLACE : BANGALORE
DECLARATION
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 Prof.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:
MOHITH K :16NMSB7024
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
2) PROBLEM DEFINITION
3) SYSTEM ANALYSIS
4. FEASIBILITY STUDY
5) SYSTEM DESIGN
5.4) ER-Diagrams
6) TECHNOLOGIES USED
6.1) JAVA
6.4) JDBC
6.5) Servlets
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
What is SRS?
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
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:
Hardware Requirements:
Pentium 4 processor
1 GB RAM
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.
Technical feasibility
Operational feasibility
Economical feasibility
To determine whether the proposed system is technically feasible, we should take into
consideration the technical issues involved behind the system.
To decide whether a project is economically feasible, we have to consider various factors as:
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
Input design is a part of overall system design. The main objective during the input design is
as given below:
INPUT STAGES:
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:
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
For Example
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 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
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.
The outputs of the requirements definition stage include the requirements document, the
RTM, and an updated project plan.
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.
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.
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.
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).
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 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
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.
SOFTWARE DESIGN
MODULES:
Admin module
User module
Government module
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.
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.
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.
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.
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.
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.
Java Technology
Java technology is both a programming language and a platform.
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.
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.
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.
ODBC
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.
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.
TCP/IP stack
IP datagram’s
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
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
#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.
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.,
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:
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.
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.
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 objectives
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.
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.
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.
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
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>
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
Websites
www.eci.gov.in
www.google.com
www.apeci.com
www.askjeeves.com