1. INTRODUCTION 1.1 About the organization A major healthcare center chain spread across many locations in India has opened a 200-bed hospital in a coastal town in Andhra Pradesh. There are no such healthcare centers in 200 km radius and thus this center became the main hospital to nearly 7 lakh people in and around that town. Being part of a major chain it has its own software implemented across all departments. They are outpatient department, inpatient department, nursing stations, billing counter, pharmacies, central drug stores, diagnostic center, ambulance, intensive care units, operation theatres, emergency ward, mortuary, patient room management, staff management and training departments. Each department has its own manager and few staff given to it to manage its operations. All staff are trained to use the healthcare software provided by the management. The staff can never afford to forget data entry as otherwise they will not be able to fulfill their duties with appropriate inputs.
1.2 Introduction to project Diagnostic center is used to store the information of the test details in a hospital or a clinic. Here actor is the Lab-Technician or Doctor and he/she should be registered in the Diagnostic center login account first then only he/she will do anything. When patient visited Diagnostic center then the Lab-Technician will register the patient and give appointment to take prescription from Doctor. Doctor examines the patient and gives the list of tests to be taken by patient. Lab-Technician gives appointment to the test for the patient. Lab-Technician calculates the bill to be paid by the patient and adds 12% tax to it and specify total amount. Patient pays the bill and Lab-technician must generate the receipt based on the pay method (cash, credit card, check) and issue it to the patient. Lab-Technician will then conducts tests to the patient and specify the time to collect the Reports according to the type of the test.
1.
1.2.1 Project Objectives •
Computerize the Operations of Diagnostic center.
•
Diagnostic center provides all test facilities to the patient.
1.2.2 Scope •
Lab-Technician can give appointment to patient.
•
Doctor can recommend tests to the patient.
•
To specify the Time to collect the reports.
•
To calculate the amount to be paid by the patient.
•
To register the patient details in the database.
•
To print receipt for the patient.
1.3 Literature Survey 1.3.1 Disadvantages of the existing system: The present system uses manual methods and the disadvantages of the present existing system are as listed below: There is no protection for the records and files.
Retrieval and storage of information will take much time during accessing. Communication between the organization levels is quite less and slow.
Deleting, adding, modifying, updating and inserting of individual records will take much time. Security and protection is much less.
2.
1.3.2 Advantages of the proposed system: The advantages of the proposed system are as listed below: Easy to maintain the records.
No wastage of time and energy.
Calculations can be performed very accurately and quickly.
Modifications can be done easily.
Data can be retrieved as and when required depending on the necessity. Data entry is very easy.
3.
2. Software Development Life cycle 2.1 Phases of Software Development Life cycle Requirement Specification Requirement Specification is the first and most important phase of the SDLC. During this phase our Project Manager is in constant contact with the Customer to find out requirements of the project in detail. Main tasks in this phase include Requirement Determination, Risk Analysis, Setting up Schedules, and deciding Deliverables. Communication with the Customer is carried out using any of the following means of communication, such as Instant Messenger, Email, Phone, Voice Chat or personal meeting. A System Requirement Specification Document is prepared at the end of this phase. Requirement Analysis and design Project Manager and System Analyst after reviewing the Customers requirements analyze the requirement and start designing of the project. System Architecture, Database Design, Program Specifications and Test Scenarios are determined. A Detail Design Document is prepared at the end of analysis that can be used by the programmers to perform the coding. Coding and Testing Programmers begin programming in this phase using the Detail Design Document. As project progress programmer's progresses is monitored by Project Manager and Project Leader respectively. Project Manager is in constant contact with the customer and provides updates on the progress of the project using MS Project. Project Leader helps the programmers with their coding problems and guides them to the solutions. Testing is done by the QA Team simultaneously for the finished modules and approval is given to the modules once they have passed their initial tests before integration. Deployment and support This phase starts with Deployment of the Project. Initial hardware and software setup necessary to run the project is a very critical phase of the project. After project is completed Project Manager contacts the customer and prepares for the set-up. Software is handed over to the customer for acceptance testing only after complete internal testing. Support to the project is provided for a limited number of days during which any minor customer changes are finished. 4.
2.2 Rational Unified Process Model Among the modern process models, Rational Unified Process (RUP) developed by Rational Corporation is noteworthy. It is an iterative model and captures many of the best practices of modern software development. The IBM Rational Unified Process Model, is a software engineering process which provides a disciplined approach to assigning tasks and responsibilities within a software development organisation for the successful development of software. Iterative and Incremental The Unified Process is an iterative and incremental development process. The Elaboration, Construction and Transition phases are divided into a series of iterations. Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release.
Use Case Driven In the Unified Process, use cases are used to capture the functional requirements and to define the contents of the iterations. Each iteration takes a set of use cases or scenarios from requirements all the way through implementation, test and deployment.
5.
Architecture Centric One of the most important deliverables of the process is the executable architecture baseline which is created during the Elaboration phase. The Unified Process insists that architecture sit at the heart of the project team's efforts to shape the system. Since no single model is sufficient to cover all aspects of a system, the Unified Process supports multiple architectural models and views. Risk Focused The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.
Inception: The inception phase is concerned with establishing the scope of the project and generally defining a vision for the project. By communicating with the customer & end user •
Business requirements for the software are identified.
•
Rough architecture for the system is prepared.
•
Plan for the project is developed.
The key activities in the phase are:
Specify the vision for the product 6.
Produce a business case
Define the scope of the project
Estimate the overall cost of the project
Elaboration (communication + modeling) The purpose of elaboration is to analyze the problem, develop the project plan further, and eliminate the riskier areas of the project. To eliminate the risks prototypes will be prepared. The key activities of this phase are •
Refine and expand the preliminary use cases developed in inception phase.
•
Expand the architectural representation to include five different views o Use case model o Analysis model o Design model o Implementation model o Deployment model
Construction It is identical to the Construction phase of the Generic frame work activities. Using the architectural model as input this phase develops the software components. To accomplish this, analysis & design models that were started during the Elaboration phase are completed. All necessary and required features and functions of the software increment are then implemented in source code. As components are being implemented, unit tests are designed and executed for each.
Transition (customer delivery + feedback)
The final phase is concerned with moving the final product across to the
customers. Typical activities in this phase include:
Beta-releases for testing by the user community
Factory testing, or running the product in parallel with the legacy system that the product is replacing
Data take on (i.e. converting existing databases across to new formats, importing data, etc)
Training the new users 7.
Marketing, Distribution and Sales
3. INCEPTION PHASE
3.1 Communication In this phase developer will go to the customer and gathers requirements by asking some simple questions Requirements are the descriptions of system structure and behavior. Requirements are gathered by interacting with the customers or the end users. They will describe the system from their point of view i.e. at high level of abstraction or with out including any implementation details. Software engineers will convert these requirements, which are relatively at lower level of abstraction. These requirements can be divided under three heads depending on “what they describe” User Requirements: These are the requirements specified by customer or the end user. Generally they will be natural language sentences. They did not include implementation details, because their inclusion may lead to confusion of non-technical people. So they will be at high level of abstraction. System Requirements: User requirements, which are in natural language, will be taken by the system analyst and are converted to system requirements. They prescribe the implementation details of the User Requirements; hence, they are the certain extent related to them; but at the same time they are more detailed than them. The data with in the system requirements should be complete as well as consistent.
Domain requirements: Before entering into a project, the software team should have some knowledge about the domain in which they are working. Requirements of 8.
that domain are Domain Requirements. The user will specify these Requirements. In this project our domain is Diagnostic Center. The domain requirements for the Diagnostic Center are •
What are the tests available in that Diagnostic Center?
•
What are the test timings in that Diagnostic Center?
Requirements for Diagnostic Center: O1: The diagnostic center has facilities and personnel to conduct all common tests and provide test reports within minimum time periods as mentioned below: 1. blood report (8 hr) 2. urine report (8 hr) 3. lipid profile (8 hr) 4. Thyroid test (16 hr) 5. Ultra sound test (2hr) 6. x ray (2 hr) 7. ECG (0.5 hr) 8. EEG (1 hr) 02: Test facilities for conducting 1-4 tests are available for only 16 hr (6 am – 10 pm) in a day. But, 5-8 tests are available for 24 hr every day. It normally receives requisitions for various test reports from nursing stations and out patients and it manages its operations through its own software module. 03: A doctor orders certain specific reports for his patient and then the tests are conducted on him after noting – Patient name Age Tests to be done Referred by doctor Reports required immediately 04: Once the payment for the tests is done, the patient (or his caretaker) is duly examined and samples are collected within a maximum time of 1 hr. 05: Then the patient’s caretaker / nursing station is informed of the time to collect reports that are required immediately, and those others at a different time. 9.
06: The diagnostic center then provides the same at the given time precisely.
3.2 Planning Effective management of a software project depends on thoroughly planning the progress of the project. The project manager must anticipate problems which might arise and prepare tentative solutions to those problems. A plan, drawn up at the start of a project, should be as the driver for the project. The initial plan should be the best possible plan given the available information. It evolves as the project progresses and better information becomes available. The project plan sets out the resources available to the project, the work break down and a schedule for carrying out the work. The project plan is solely concerned with the development process. The details of the project plan vary depending on the type of project and organization. The project plan structure is as shown Introduction: In this we will set out the constraints (budget, time etc) which effect the project management. Project Organization: This describes the way in which the development team is organized, the people involved and their roles in the team. Risk Analysis: This describes possible project risks, the likelihood of these risks arising and the risk reduction strategies which are proposed. A risk is defined as the probability of missing a cost, schedule, future extendibility, quality.
Hardware and software resource requirements: This describes the hard ware and software requirements. If hardware is to be purchased estimates the prices and delivery schedule. 10.
Monitoring and reporting mechanisms: This describes the management reports which should be produced, when these should be produced and the project monitoring mechanisms used. The project plan should be regularly revised during the project. Some parts, such as the project schedule will change frequently; other parts will be more stable.
11.
4. ELABORATION PHASE
4.1 Communication Initially in the inception phase requirements will be gathered by communicating with the customer. After analyzing the requirements the software team will again go to the customer and they will finalize the requirements. After this stage the project will be moved to the modeling phase.
4.2 Modeling In this the finalized requirements will be modeled using two models. They are •
Analysis Modeling
•
Design Modeling
12.
4.2.1 Analysis Model The Analysis model is the first technical representation of the system. Analysis modeling uses a combination of text and diagrams to represent software requirements in an understandable way. Building analysis model make it easier to uncover requirement inconsistencies and omissions. Analysis models represent the customer requirements by depicting the software in three different domains.
Requirements Documents In this all user requirements are written in a specified format, which will be very easy for the designers, coders and testers to understand. This can be divided into two parts basing on “how they are described”. •
URD (User Requirement Document): In this the requirements are at high level of abstraction. No technical words are used here. This document will be given to the customer who validates that. Here each requirement will be given an ID.
•
SRS (System Requirement Specification): After getting conformation from the customer the URD will be converted to SRS. It contains the technical details which makes the software engineer comfortable
13.
4.2.1.1 User Requirement Document (URD) Introduction This section mainly briefs about who is the customer and what is customer business and the problems customer is facing in the existing business. It also gives information on business aspects considered for automation, goals of the project.
Target audience Customer Developers Lab-Technician Doctor Project manager and project leader Project guide
Look-up table S.No
Requirement
Requirement Name
ID 1. 2.
DC-UC01 DC-UC02
3.
DC-UC03
4.
DC-UC04
5. 6.
DC-UC05 DC-UC06
Login Configure Test Appointment for test Generate Test Reports Generate Bill Payment
Source
Stable
(Customer/Vendor)
(Y/N)
Customer Customer
Y Y
Customer
Y
Customer
Y
Customer Customer
Y Y
14.
Requirement description Requirements ID DC-UC01 Title Description Actor Input:
Behavior
Output Pre-conditions
Login The purpose of this use case is to authorize users before they access features of applications Lab-Technician, Doctor LoginID, password --Verify ID exists or not --If ID exists retrieve password --Compare password --If password match then allow user to access the application --Else display error message Home page Lab Technician registered
Post-conditions
----nil---
Login
Use-case
Special Instructions
Lab Technician
--nil--
15.
Requirements DC-UC02 ID Title Configure Test This usecase is used to specify the test details and store Description the details in the database Actor Lab-Technician Input: Behavior Output Preconditions Postconditions
Test name, Duration, cost, Regular or fulltime Store test details in the application Success or failure message Lab-Technician login --nil--
Configure test
Use-case
Lab Technician uses
Login
Special Instructions
Regular(6AM-10PM hours) , Full time(24 hours)
16.
Requirements DC-UC03 ID Title
Appointment for test
Actor
This usecase is used to specify the date and time for the appointment and calculate the time for collecting reports Lab-Technician
Input:
Patient ID, Test name, Date and time
Description
Behavior Output Preconditions Postconditions
Store test details in the application and calculate the time to collect the reports Specifying the time to collect the reports Lab-Technician login --nil--
Appointment for Test
Use-case
Lab Technician uses
Login
Special Instructions
Regular(6AM-10PM hours) , Full time(24 hours)
17.
Requirements DC-UC04 ID Title Description
Generate test reports This usecase is used to store the test details and generating test reports
Actor
Lab-Technician
Input:
Patient name, age, Test name, Doctor name, Test details
Behavior Output Preconditions Postconditions
Store test details in the application and generating the report format Printing reports Lab-Technician login --nil--
Generate Test Reports
Use-case
Lab Technician uses
Generate report format
Special Instructions
Login
--nil--
18.
Requirements DC-UC05 ID Title Description
Generate Bill This usecase is used to calculate the cost of all details
Actor
Lab-Technician
Input:
Patient ID
Behavior Output Preconditions Postconditions
Calculate the cost of all details Amount Lab-Technician login --nil--
Generate Bill
Use-case
Lab Technician uses
Login
Special Instructions
--nil--
19.
Requirements DC-UC06 ID Title Description
Payment This usecase is used to record payment details and generating reports
Actor
Lab-Technician
Input:
Payment type(DD or Cheque or cash)
Behavior Output Preconditions Postconditions
Record Payment details and generate receipt Print receipt Lab-Technician login --nil--
payment
Use-case
Lab Technician uses
Print reciept
Special Instructions
Login
--nil--
4.2.1.2 System requirement specification (SRS) 20.
Introduction This section mainly briefs about giving appointment for the test, generating test reports, generating bill, printing the receipt to the patient .
Software and Hardware Requirements Hardware environment The minimum server configuration includes HDD-160GB RAM-1GB Processor- AMD Athlon The minimum Client Configuration includes HDD-80GB RAM-512MB Processor- Pentium - 4 Software environment At Server Side : : Operating System(Windows server 2003),One Web Browser, Oracle 9i, Jdbc, Odbc Drivers At Client Side : : Operating System(Windows XP),One Web Browser(Internet Explorer, Morzilla Firefox..Etc) Look up table S.no
System Feature ID
Title
1.
SF 01
Login
2.
SF 02
Configure Test
3.
SF 03
Recommend Test
4.
SF 04
View Reports
5.
SF 05
Appointment for the test
6.
SF 06
Generate Test reports
7.
SF 07
Generate Bill
8.
SF 08
Payment
System features SRS ID
DC-SF01
TITLE
Login 21.
DESCRIPTION INPUT
LOGIC
The purpose of this is to authorize users before they access features of applications ID , password •
Click login link in home page
•
Display login form
•
Enter input data
•
Submit form
•
Perform data validations
•
If errors found display error messages
•
Else call server program
•
Read from data
•
Connect to Database
•
On successful connection, retrieve password for given login ID from database
•
If resultset is empty then display loginID does not exist
•
Else compare password
•
If password matches with the password entered in the form then display user home page
•
Else display error message that the password is incorrect
OUTPUT
•
Close resultSet
•
Close database.
User home page/ error message •
CONDITIONS TO CHECK
User ID should be atleast 4 characters long and _ is only the special symbol allowed
•
Password should be more than 6 characters long
SRS ID TITLE DESCRIPTION
DC-SF02 Configure Test The purpose of this is to store test details and displaying success or failure message. 22.
INPUT
Tname, Duration, cost, Test timings(Regular or fulltime) • Click configure test link in home page •
Display form with Test name, Duration, cost, Test timings(Regular or fulltime)
•
Enter input data
•
Submit form
•
Perform data validations
•
If errors found display error messages
•
If cost is not in the floating point format then display error message.
LOGIC
•
Else call server program
•
Read from data
•
Connect to Database
•
Execute insert operation on database to store the details entered
•
Check return value of insert operation
•
If it is 0 then the insertion is failed and display error message
•
Else display message Test details stored successfully and click OK to return to user home page.
OUTPUT CONDITIONS TO CHECK
• Close database. Message: Test Details stored successfully/ error message •
Duration should be in between 0.5 hours and 16 hours
SRS ID
DC-SF03
TITLE
Recommend test
DESCRIPTION
The purpose of this is to store recommended test by doctor, Patient ID in the database. 23.
INPUT
Sno, PID, Tname •
Click Recommend Test link in home page
•
Display form with Test name, Sno, Patient ID
LOGIC
•
Enter input data
•
Submit form
•
Perform data validations
•
If errors found display error messages
•
Else call server program
•
Read from data
•
Connect to Database
•
Retrieve the Doctor ID from the login details through which the doctor logged in.
•
Store the details of the Sno, Test name given by doctor, Patient ID, Doctor ID by using insert operation.
•
If the return value for the insert operation is 0 then display error message
•
Else display message “Details registered successfully”
OUTPUT
• Close database. Message: Details stored successfully/ error message
CONDITIONS TO
---nil---
CHECK
SRS ID
DC-SF04
TITLE
View Reports
DESCRIPTION
The purpose of this is to retrieve report details from database and Display details in the form. 24.
INPUT
LOGIC
OUTPUT
Rno •
Click View Reports link in home page
•
Display form with Report no field
•
Enter input data
•
Submit form
•
Perform data validations
•
If errors found display error messages
•
Else call server program
•
Read from data
•
Connect to Database
•
Retrieve the Report details by using Report no
•
If result set is empty then display error message
•
Else Display the report details in the format
•
Close database.
Message: Details stored successfully/ error message
CONDITIONS TO
---nil---
CHECK
SRS ID
DC-SF05
TITLE
Appointment for the test
DESCRIPTION INPUT
The purpose of this is to store appointment details and calculate time to collect reports PID, Tname, date and time 25.
•
Click Appointment for test link in home page
•
Enter input data
•
Submit form
•
Perform data validations
•
If errors found display error messages
•
If Date and time are invalid then display error message in that form itself.
LOGIC
•
Else call server program
•
Read from data
•
Connect to Database
•
Execute insert operation on database to store details entered
•
Check return value of insert operation
•
If it is 0 then the insertion is failed and display error message
•
Else calculate time to collect reports based on Test timings in a day.
OUTPUT
•
Display that calculated time to collect reports
•
Close database.
Specifying time to collect reports/ error message •
CONDITIONS TO CHECK
We have to check whether the test is regular or full time from the test details table
•
If the test is from 6:00 AM to 10:00 PM then check whether the current time is in that limit and give the appointment.
SRS ID
DC-SF06
TITLE
Generate Test reports
DESCRIPTION
The purpose of this is to store test report details and generating report format
26.
INPUT
Pname, Age, Tname, Dname, TestDetails •
Click Generate Test reports link in home page
•
Display the form with the details such as Patient name, Age, Test name, Doctor name, TestDetails etc.
LOGIC
•
Enter input data
•
Submit form
•
Perform data validations
•
If errors found display error messages
•
Else call server program
•
Read from data
•
Connect to Database
•
Execute insert operation on database to store details entered
•
Check return value of insert operation
•
If it is 0 then the insertion is failed and display error message
•
Else Prepare the form with the details entered in the database in the report format
OUTPUT
•
Print the reports and take printout.
•
Close database.
Print reports/ error message
CONDITIONS TO
---nil---
CHECK
SRS ID
DC-SF07
TITLE
Generate Bill
DESCRIPTION
The purpose of this is to calculate the amount of test to be done and 27.
INPUT
LOGIC
PID •
Click Calculate Bill link in home page
•
Display the form to enter patient ID
•
Enter input data
•
Submit form
•
Perform data validations
•
If errors found display error messages
•
If invalid ID is entered then display error message
•
Else call server program
•
Read from data
•
Connect to Database
•
Retrieve the test name from the database
•
From that test name retrieve cost of the test
•
Add service tax to it
•
Display the amount and specify to patient to pay it
OUTPUT
CONDITIONS TO CHECK
SRS ID
Calculating bill/ error message
•
Add 12% service tax to the cost of the test and calculate bill
DC-SF08
28.
TITLE DESCRIPTION INPUT
Payment The purpose of this is to record payment details and generate receipt Payment type(DD, cheque, cash), details •
Click print receipt link in home page
•
Display the Payment form which consists of payment details
LOGIC
•
Enter input data
•
Submit form
•
Perform data validations
•
If errors found display error messages
•
Else call server program
•
Read from data
•
Connect to Database
•
Execute insert operation on database to store details entered
•
Check return value of insert operation
•
If it is 0 then the insertion is failed and display error message
OUTPUT
•
Else print receipt and issue to patient.
•
Display that calculated time to collect reports
•
Close database.
Print receipt/ error message
CONDITIONS TO CHECK
•
Check whether the payment type is cash or DD or cheque
4.2.2 Design Model Software design is a meaningful engineering representation of the software product that is to be built. A design can be traced to the customer’s 29.
requirements and can be assessed for quality against predefined criteria. During the design process the software requirements model is transformed into design models that describe the details of data structures, system architecture, interfaces and components. Each design product is reviewed for quality before moving to the next software engineering action. Design can be classified into two parts. This Classification is based on the things to be modeled.
4.2.2.1 High Level Design Architectural Design It is derived from o Information about application domain relevant to software o Relation ships and collaborations among specific analysis model elements o Availability of architectural styles and patterns Usually depicted as asset of interconnected systems that are often derived from the analysis packages
User with personal computer
Client User interface (Web Browser) App Database Web server Application runtime providers environment server (ADODB, (Classes, ODBC, WebWeb UI Database (HTML, Database Server Authentication authentication JSP, logical Java layer Script) (containers, JRE) interfaces) JDBC)
30.
Database physical layer
Flow Charts 1. Login
31.
Start
Click Login link
Enter ID,password
Submit form No Perform validtions
IS Data OK? yes Call Server Read from data
Connect to Database
No
Data base
IS Connection OK? yes Retrieve password for given IP
IS Result empty? No
Error ID incorrect Yes
IS password matches? Yes
No
Error ID incorrect
Display home page Close database connection
Stop
2. Appointment for test
32.
Start
Click Appointment for Test link
Display the time to collect the reports Enter Appointment details
Submit form
Stop
Perform validtions
IS Data OK? Yes
No
Error
Call Server Read from data
Connect to Database
IS Connection OK? Data base
Error
No
Yes
Retrieve Test for given patient ID
IS Result empty? Yes
Patient ID not exists
IS test name selected in result? Yes
Insert current date and time into database
Is insert operation success?
No
Insert Error
3. Generate Reports 33.
Start
Click Generate reports link Enter the patient ID,Test name details
Submit form Perform validtions
IS Data OK?
Yes
No
Error
No
Call Server
Read from data Connect to Database
Data base
IS Connection OK?
Error
Yes No Retrieve Test for given patient ID
IS Result empty? Yes
Patient ID not exists
IS test name selected in result? Yes Retrieve patient details for given patientID and other report details
Display the report details in new page
Stop
34.
4.2.2.2 Low Level Design ER Diagrams
StaffID Address
password
E-mail
dept
Doctor
checks
Phone no
address Patient ID
Patient
Phone no
name
pays cost
Recommends amount
Duration Test name
Tests
generates
Bill no
Bill
Pay ment method
ty pe
Details
conducts
Details
Phone no Address StaffID
Lab Technician
password
dept
generates
Reports
Report name
Report no
35.
Database Tables Table for Login Information
Column
Data
Size
name
type
loginID
varchar
Nulls
Constraints
Remarks
(y/n) 30
n
1.Should not
Primary Key
be null 2.Should be password
varchar
20
n
unique 1.Should not
N/A
be null 2.Should be minimum Confirm
varchar
20
n
password
6characters 1.Should not
N/A
be null 2.Should be minimum
Name
varchar
30
n
6characters N/A
N/A
RoleCode
varchar
20
n
Should be any
N/A
one of the role code given by the developer
Table for patient Registration
Column
Data
name
type
PID
number
Size
Nulls
Constraints
Remarks
(y/n) 10
n
1.Should not be null 2.Should be
Primary Key
unique Name
varchar
30
n
N/A
N/A
address Phno
varchar number
40 12
y n
N/A Should be in any
N/A N/A
one of the format 36.
given by the Age Email
number varchar
3 25
n
developer Should not be a
N/A
n
negative number Should be in any
N/A
one of the format given by the developer Table for Test details
Column
Data
name
type
Tname
varchar
Size
Nulls Constraints (y/n)
20
n
1.Should not be null 2.Should be
Cost address type
Float varchar varchar
Remarks
10 40 20
n n n
Primary Key
unique N/A N/A Should be
N/A N/A N/A
any one of the test type given by the Email
varchar
25
n
developer Should be in
N/A
the format given by the developer
Table for Bill details
Column
Data
name
type
bno
number
Size
Nulls
Constraints
Remarks
1.Should not be
Primary
(y/n) 10
n
null
Key
2.Should be 37.
amount date
float
10
date
20
n
unique Should not be a
N/A
n
negative number Should be in
N/A
any of the PID
varchar
30
n
Payment
varchar
20
n
details
format of date N/A
Foreign Key
Should be any one of the role code given by
N/A
the developer Table for Reports
Column
Data
name
type
Rno
number
Size
Nulls
Constraints
Remarks
(y/n) 10
n
1.Should not be null 2.Should be
name
varchar
20
n
PID
number
10
n
unique N/A Should be
Primary Key
N/A Foreign Key
foreign key for PID of Patient Tname
varchar
20
n
table Should be
Foreign Key
foreign key for Tname of Test details
varchar
50
y
table Should be in
N/A
the format given by the developer Table for Patient-Test details
Column
Data
name
type
Sno
number
Size
Nulls
Constraints
Remarks
(y/n) 10
n
1.Should not be
Primary 38.
null
Key
2.Should be PID
number
10
n
unique Should be foreign key for PID of
Tname
Did
varchar
varchar
20
20
n
n
Foreign Key
Patient table Should be foreign
Foreign
key for Tname of
Key
Test table Should be foreign
Foreign
key for LoginID of
Key
login table
4.3 UML Diagrams In the field of software engineering, the Unified/Universal Modeling Language (UML) is a standardized visual specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model. It is very important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphical representation of a system's model. The model also contains a "semantic backplane" — documentation such as written use cases that drive the model elements and diagrams.
4.3.1 Sequence diagram Sequence diagrams are an easy and intuitive way of describing the behavior of a system by viewing the interaction between the system and its environment. A sequence diagram shows an interaction arranged in a time sequence. It shows the objects participating in the interaction by their life lines and the messages they exchange, arranged in a time sequence. A sequence diagram has two dimensions: the vertical dimension represents time; the horizontal dimension represents different objects. The vertical line is called the objects lifeline. The lifeline represents the object’s existence during the interaction. An object is shown as a box at the top of a dashed 39.
vertical line. A role is a slot for an object within a collaboration that describes the type of object that may play the role and its relationships to other roles. However, a sequence diagram does not show the relationships among the roles or the association among the objects. An object role is shown as a vertical dashed line, the lifeline. An arrow between the lifelines of two objects represents each message. The Order in which these messages occur is show top to bottom on the page. Each message is labeled with the message name. The label also can include the argument and some control information and show self-delegation, a message that an objects sends to it, by sending the message arrow back to the same lifeline. The horizontal ordering of the lifelines is arbitrary. Often, call arrows are arranged to proceed in one direction across the page, but this is not always possible and the order conveys no information. Sequence diagrams are an easy and intuitive way of describing the behavior of a system by viewing the interaction between the system and its environment. A sequence diagram shows an interaction arranged in a time sequence. It shows the objects participating in the interaction by their life lines and the messages they exchange, arranged in a time sequence.
Sequence Diagram for Diagnostic Center
40.
4.3.2 Class design: Class design provides complete overview of the Diagnostic center. The class diagram is core to object-oriented design. It describes the types of objects in the system and the static relationships between them. Classes:- The core element of the class diagram is the class. In an object oriented system, classes are used to represent entities within the system; entities that often relate to real world objects. Classes are divided into three sections: Top: The name, package and stereotype are shown in the upper section of the class. You can optionally assign a stereotype to a class. 41.
Centre: The centre section contains the attributes of the class. Bottom: In the lower section are the operations that can be performed on the class. Attributes: An attribute is a property of a class.
It is generally understood
that when implementing the class, functionality is provided to set and retrieve the information stored in attributes. Methods to set and retrieve attribute data are often called accessor methods and need not be shown in your model as they are usually inferred. Operations: The operations listed in a class represent the functions or tasks that can be performed on the data in the class.
Class description Class id Class name Description Attributes Methods
DC-class01 Staff This class is used to login into their own home pages LoginID, password, name, rolecode register(), login()
Class id Class name Description
DC-class02 Tests This class is used to configure tests include adding,
Attributes Methods
deleting, updating Tname, cost, duration, type add(), delete(), update()
Class id Class name Description
DC-class03 Doctor This class is used to recommend tests to patient and
Attributes Methods
viewing reports of the particular patient ID, pwd, name, rolecode recommendTest(), viewReports()
Class id
DC-class04
Class name
Lab Technician
Description
This class is used to give appointment to patient for tests
Attributes
and generating reports ID, pwd, name, rolecode 42.
Methods
appointment()
Class id
DC-class05
Class name
Reports
Description
This class is used to generate the reports and print the
Attributes
report Rno, name, PID, tname, details
Methods
generateReport(), printReport()
Class id
DC-class06
Class name
Bill
Description
This class is used to store bill details into the database
Attributes
and print reciept Bno, amount, date, PID, paymentType
Methods
generateBill(), printReciept()
Class id
DC-class07
Class name
Patient
Description
This class is used to store patient details into the
Attributes
database PID, name, address, phno, email
Methods
N/A
Class Diagram
43.
checks
Staff
Doctor
Bill
ID pwd name rolecode
Bno amount date PID paymentTy pe
recommendTest() v iewReports()
generateBill() printReciept()
ID pwd name rolecode
pays
Patient PID Name Address Phno email
undergoes recommends generates
register() login()
LabTechnician ID pwd name rolecode appointment()
generates
Reports
Tests
Rno name PID tname details
Tname cost duration ty pe add() delete() update()
generateReport() printReport()
conducts
5. CONSTRUCTION 44.
public class Staff { char lid,password; char name,rolecode; public void login(char lid,char password) { } public void register(char lid,char password) { } } public class LabTechnician { char lid,password; char name,rolecode; public void appointment(int pid,char tname) { } } public class Doctor { char lid,password; char name,rolecode; public void recommendTest(int pid,char tname) { } public void viewReports(int pid,char tname) { } }
public class Report { 45.
int Rno,pid; char name,tname,details; public void generateReports(int pid,char tname) { } public void printReport() { } } public class Tests { char Tname, type; float cost; int duration; void add(){ } void update(){ } void delete(){ } } public class Bill { int Bno; float amount; Date date; char pid,paymentType; public void generateReport(){ } public void printReport(){ } }
6. TESTING 6.1 Introduction 46.
Testing begins at the component level and works out ward to ward the integration of entire computer based system. The software testing Life cycle consists of the following phases. •
Planning consists of analyzing the features of the product to be tested and detailing the scope of the test effort.
•
Design includes documenting and detailing the tests that will be necessary to validate the product.
•
Development involves creating or modifying the actual tests that will be used to validate the product.
•
Execution is concerned with actually exercising the tests against the product.
•
Analysis or review consists of evaluating the results and effectiveness of the test effort; the evaluation is then used during the planning stage of the next testing cycle. Reuse is focused on improving the development, and to a lesser extent the design, portions of the testing cycle.
6.2 Unit test cases In computer programming, unit testing is a method of testing that verifies the individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class.
In this
section write the test cases to test each of the methods in a class. Concentrate on whether those methods are created as per their pseudo code specification or not.
47.
Test case for Login ID Test Case ID:
Input
Expected Result
1.
minivja_cse
2.
864789
Invalid
3.
#@er143
Invalid
4.
raghukishore
Valid
5.
Administrator@
Invalid
6.
Valid
Invalid
7.
>30 characters
Invalid
8.
vivek.reddy537
valid
Test case for Patient name, Doctor name, Lab Technician name
Test Case ID:
Input
Expected Result
1. 2. 3.
B. Srinivas Ramesh123 MSSVR
valid Invalid valid
4.
Arjun_panday
Invalid
5.
Rajesh@
Invalid
6. 7. 8. 9. 10.
23vivek San^tosh 5763 >30 characters Vivek reddy
Invalid Invalid Invalid Invalid valid
Test case for E-mail ID
48.
Test case ID
Input
Expected Result
1. 2. 3. 4. 5.
[email protected] [email protected] A123@ A%B@ Blank
Valid Valid Valid Error Error
6.
Spaces
Error
7.
A
[email protected]
Error
8.
AB@c
Error
9.
[email protected]
Accept
11.
AB@c.
Reject
12.
[email protected]
Accept
m
Test case for Phone Number
49.
Test case ID
Input
1.
Ch99598868
Expected Result Error
2.
9959886840
Valid
3.
995988684
Error
4.
1298853074
Error
5.
99661435sa
Error
6.
1234567892
Error
7.
000995988689
Error
8.
08662531712
valid
7. SCREENS
50.
User interface Screen id: Login(S1)
Figure:7.1 Screen for Login
51.
Screen id: Register(S2)
Figure:7.2 Screen for Register Screen id: About us(S3)
Figure:7.3 Screen About their Diagnostic center 52.
Screen id: Tests(S4)
Figure:7.4 Screen for Test details Screen id: cost(S5)
Figure:7.5 Screen for cost of tests 53.
Screen id: Contact Us(S6)
Figure:7.6 Screen for contact information Screen id: Lab Technician Home page(S7)
Figure:7.7 Screen for Lab-Technician home page
54.
Screen id: Patient Registration(S8)
Figure:7.8 Screen for patient Registration Screen id: Configure Test(S9)
Figure:7.9 Screen for configuring test details 55.
Screen id: Add Test details(S10)
Figure:7.10 Screen for adding test details Screen id: Update Test details(S11)
Figure:7.11 Screen for updating test details
56.
Screen id: Appointment to test(S12)
Figure:7.12 Screen to give appointment for test Screen id: Report generation(S13)
Figure:7.13 Screen for generating reports 57.
Screen id: Print reports(S14)
Figure:7.14 Screen for printing reports Screen id: Bill generation(S15)
Figure:7.15 Screen for Generating Bill 58.
Screen id: Print receipt(S16)
Figure:7.16 Screen for Print reciept Screen id: Doctor’s Home page(S17)
Figure:7.17 Screen for Doctor’s Home page 59.
Screen id: Recommend test(S18)
Figure:7.18 Screen for Recommend test to patient Screen id: View test details(S19)
Figure:7.19 Screen for viewing Test details 60.
8. CONCLUSION The DIAGNOSTIC CENTER is an efficient tool which handles all the difficulties and complexity described above. Here no paper work will be alone. All the work will be handled by the Lab-Technician and Doctor. So this software is easy to use by a Lab-Technician and Doctor. But LabTechnician or Doctor should have minimum knowledge about the browsing, how to handle the errors and form submission.
61.
9. APPENDICES 9.1 AN OVERVIEW OF SERVLET AND JSP TECHNOLOGY The Java Database Connectivity (JDBC) API is the industry standard for database-independent connectivity between the Java programming language and a wide range of databases – SQL databases and other tabular data sources, such as spreadsheets or flat files. The JDBC API provides a calllevel API for SQL-based database access. JDBC API OVERVIEW: The JDBC API makes it possible to do three things:
Establish a connection with a database or access any tabular data source
Send SQL statements
Process the results JDBC has been part of the Java Standard Edition since the release of JDK 1.1. The JDBC classes are contained in the Java package java.sql. Starting with version 3.0, JDBC has been developed under the Java Community Process. JDBC allows multiple implementations to exist and be used by the same application. The API provides a mechanism for dynamically loading the correct Java packages and registering them with the JDBC Driver Manager. The Driver Manager is used as a connection factory for creating JDBC connections. JDBC connections support creating and executing statements. These may be update statements such as SQL's CREATE, INSERT, UPDATE and DELETE, or they may be query statements such as SELECT. Additionally, stored procedures may be invoked through a JDBC connection. JDBC represents statements using one of the following classes:
Statement – the statement is sent to the database server each and every time.
62.
Prepared Statement – the statement is cached and then the execution path is pre determined on the database server allowing it to be executed multiple times in an efficient manner.
Callable Statement – used for executing stored procedures on the database. Update statements such as INSERT, UPDATE and DELETE return an
update count that indicates how many rows were affected in the database. These statements do not return any other information. Query statements return a JDBC row result set. The row result set is used to walk over the result set. Individual columns in a row are retrieved either by name or by column number. There may be any number of rows in the result set. The row result set has metadata that describes the names of the columns and their types. SERVLETS: The Java Servlet API allows a software developer to add dynamic content to a Web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets are the Java counterpart to non-Java dynamic Web content technologies such as PHP, CGI and ASP.NET. Servlets can maintain state across many server transactions by using HTTP cookies, session variables or URL rewriting. The Servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of a Web container and a servlet. A Web container is essentially the component of a Web server that interacts with the servlets. The Web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights. A Servlet is an object that receives a request and generates a response based on that request. The basic servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlets configuration parameters and execution environment. The package javax.servlet.http defines HTTP-specific subclasses of the generic servlet elements, including session management objects that track multiple requests and responses between the Web server and a client. Servlets may be packaged in a WAR file as a Web application. 63.
Servlets can be generated automatically by JavaServer Pages (JSP), or alternately by template engines such as WebMacro. Often servlets are used in conjunction with JSP’s in a pattern called "Model 2", which is a flavor of the model-view-controller pattern. JSP TECHNOLOGY: JavaServer Pages (JSP) is a Java technology that allows software developers to dynamically generate HTML, XML or other types of documents in response to a Web client request. The technology allows Java code and certain pre-defined actions to be embedded into static content. The JSP syntax adds additional XML-like tags, called JSP actions, to be used to invoke built-in functionality. Additionally, the technology allows for the creation of JSP tag libraries that act as extensions to the standard HTML or XML tags. Tag libraries provide a platform independent way of extending the capabilities of a Web server. JSPs are compiled into Java Servlets by a JSP compiler. A JSP compiler may generate a servlet in Java code that is then compiled by the Java compiler, or it may generate byte code for the servlet directly. JSPs can also be interpreted on-the-fly reducing the time taken to reload changes.
9.2 INTRODUCTION TO HTML HTML, technically speaking is not a language. It is also not intended to be a comprehensible page-layout system. It is a set of mark-up tags used to format text and include other data formats in a hypermedia documents so that the web browsers can interpret and display them. Some of the standard things HTML allow the user to do: Publish documents to the internet in a platform independent format. Create links to related works form your document. Include graphics and multimedia data with your document. Link to non-world wide web information resources on the internet. HTML documents can be written by the user in a simple text editor like the notepad in windows or VI editor in UNIX environment. But there are number of editing tools in the market that speed up the process of writing up HTML documents. A note on the HTML editors follows. 64.
Web or HTML documents are typically written in HTML and are usually named with suffix “.html” or “.htm”. HTML documents are nothing more than standard 7-bit ASCII files with formatting codes that contain information about layout and hyperlinks. Basic Markup Tags HTML documents look a lot like word-processing documents with markup tags. Markup tags are text tags inserted into a document which are not visible to the reader, and are not part of the content, but enhance the document in many ways including adding hypertext capability. HTML tags are used to markup the structure of a document, and embed basic formatting information that the browser can use to decide how to display the content. HTML documents is made up of tags, which are commands written between<>(angle brackets). A tag with a slash(/) is known as a closing tag. Most openings tags require a following closing tag, but not all. Tags in HTML are NOT case sensitive. Basic Tags An HTML document start with < HTML > tag and ends with