Wollo University

Kombolcha Institute of Technology (KIoT)

Project Title: clinic record management system

Department: software engineering

Prepared by:

Name Id

1, legesse nigat . . .………………….…………….…………1566/10

2, Yamlak Gebrie …………………………………………….0625/10

3, Mikiyas Tefera …………………………………………….1723/10

Summited date:

Submitted to: department of software engineering

Dassa ,wollo, Ethiopia

i
Acknowledgment
First of all, we would like to thank Almighty GOD for the strength, he has given us throughout
our life and this project; nothing could happen without the help of GOD. Secondly, we would
like to express our gratitude to our advisors Edome for his help, willingness and commitment in
giving his precious time to help us to accomplish this work. We are also very grateful and would
like to extend our sincere thanks to our staff members and students of our Department of
software engineering for sharing their ideas, suggestions, and support and especially for their
commitment. We really give a great respect and credit to everyone who involved in our project
tasks.

ii
Abstract
This project is mainly focus on online student clinic Management System for wollo university
specaily in desse campus.

In apparent program we develop cms for wollo university in desse campus to be computrized or
autometed or web based system .This system is solve the student problem and solve the staffs
who works in the clinic becouse if the system is web based the staffs who work in clinic treats
the paitent effectivly and decreses labour and time.

iii
Contents
Chapter 1.....................................................................................................................................................1
Introduction.............................................................................................................................................1
1.1 background........................................................................................................................................1
1.2 Project description.............................................................................................................................1
1.3 The proposed system.........................................................................................................................2
1.4 Objective......................................................................................................................................2
1.4.1general objective.........................................................................................................................2
1.4.2specific objective of the project...................................................................................................2
1.5 Scope.................................................................................................................................................2
1.6 methodology.....................................................................................................................................3
1.6.1 data collection method...............................................................................................................3
1.6.2 Development tool.......................................................................................................................3
1.7 Feasibility Analysis.............................................................................................................................4
1.7.1 Operational Feasibility................................................................................................................4
1.8.2 Technical Feasibility....................................................................................................................4
1.7.3 Economic Feasibility...................................................................................................................4
1.7.4 Schedule Feasibility....................................................................................................................4
1.8 Significance of the project.................................................................................................................6
1.8.1 Flexibility.....................................................................................................................................7
1.8.2 Cost Saving..................................................................................................................................7
1.8.3 Fast Service.................................................................................................................................7
1.9 constraint...........................................................................................................................................7
1.10 System Analysis and Design Approach.............................................................................................7
Chapter 2.....................................................................................................................................................9
System analysis............................................................................................................................................9
2.introduction..........................................................................................................................................9
2.1 existing system..................................................................................................................................9
2.1.1 Player of the Existing System......................................................................................................9
2.2 Business Rules.................................................................................................................................10
2.2.1 Business Rules Identified in the Existing System.......................................................................10
2.2.2 Business Rules in the proposed system....................................................................................10
2.3 Proposed System.............................................................................................................................11

iv
 2.3.1 The purpose of the new system................................................................................................11
2.4 Software Requirement Specification...............................................................................................11
2.4.1 functional requirement.............................................................................................................12
2.4.2 non-functional requirement.....................................................................................................13
2.5 Need for Computerization...............................................................................................................14
Chapter 3...................................................................................................................................................16
System Analysis.........................................................................................................................................16
3. system modeling................................................................................................................................16
3.1 Introduction.....................................................................................................................................16
3.2 use case modeling...........................................................................................................................17
3.2.1 Usecse description....................................................................................................................18
3.3 sequence diagram...........................................................................................................................21
3.4 activity diagram...............................................................................................................................26
3.5 State chart diagram.........................................................................................................................29
3.6 class diagram...................................................................................................................................31
Chapter 4...................................................................................................................................................32
System design............................................................................................................................................32
4.1 Introduction.....................................................................................................................................32
4.2 Design Goals and Objectives............................................................................................................32
4.3 architectural design:........................................................................................................................33
4.5 system decomposition.....................................................................................................................34
4.6 component design...........................................................................................................................35
4.7 deployment diagram.......................................................................................................................36
4.8 database design...............................................................................................................................37
Chapter five...............................................................................................................................................38
Implementation and Testing.....................................................................................................................38
5.1 Introduction.....................................................................................................................................38
5.2 Final Testing of the system..............................................................................................................38
5.3 Testing plan.....................................................................................................................................38
5.4 Unit testing......................................................................................................................................38
5.5 Integration testing...........................................................................................................................38
5.6 Features to be tested.......................................................................................................................39
5.7 Features not to be tested................................................................................................................39

v
 5.8 user interface design.......................................................................................................................39
5.8.1 over view of user interface.......................................................................................................40
5.8.2 screen image.............................................................................................................................41
5.9 Prototype Development..................................................................................................................43
Chapter Seven:..........................................................................................................................................49
Conclusion and Recommendation.............................................................................................................49
7.1 Conclusion.......................................................................................................................................49
7.2 Recommendation............................................................................................................................49
7.3 acronym...........................................................................................................................................50

Table
TABLE1. 1 SCHEDULE FEASIBILITY.................................................................................................................................5
TABLE1. 2 SCHEDULE FEASIBILITY................................................................................................................................6
TABLE1. 3 PROJECT TEAM PLAN......................................................................................................................................6

TABLE2. 1 FUNCTIONAL REQUIREMENT.........................................................................................................................13

TABLE2. 2 NON –FUNCTIONAL REQUIREMENT...............................................................................................................14

TABLE3. 1ACTORS AND USE CASE OF THE PROPOSED SYSTEM DESCRIPTION................................................................17

TABLE3. 2 USE CASE DESCRIPTION OF MANAGE DOCTOR..............................................................................................18
TABLE3. 3 USE CASE DESCRIPTION OF MANAGE PATIENT..............................................................................................19
TABLE3. 4 USE CASE DESCRIPTION OF VIEW APPOINTMENT..........................................................................................19
TABLE3. 5 USE CASE DESCRIPTION OF MANAGE PRESCRIPTION....................................................................................20
TABLE3. 6 USE CASE DESCRIPTION OF MANAGE ACCOUNT..........................................................................................20
TABLE3. 7 USE CASE DESCRIPTION OF MANAGE SERVICE.............................................................................................21

figures
FIGURE3. 1 USE CASE DIAGRAM OF CLINIC MANAGEMENT SYSTEM.............................................................................17
FIGURE3. 2 SEQUENCE DIAGRAM FOR LOGIN................................................................................................................22
FIGURE3. 3 SEQUENCE DIAGRAM FOR ADD NEW DOCTOR............................................................................................23
FIGURE3. 4 SEQUENCE DIAGRAM FOR ADD NEW APPOINTMENT..................................................................................24
FIGURE3. 5 SEQUENCE DIAGRAM FOR ADD NEW PATIEN..............................................................................................25
FIGURE3. 6 ACTIVITY DIAGRAM FOR LOGIN..................................................................................................................26
FIGURE3. 7 ACTIVITY DIAGRAM FOR MANAGE PATIENT...............................................................................................27
FIGURE3. 8 ACTIVITY DIAGRAM FOR APPOINTMENT.....................................................................................................28
FIGURE3. 9 LOGIN STATE CHART DIAGRAM...................................................................................................................29
FIGURE3. 10 UPDATE INFORMATION STATE CHART DIAGRAM......................................................................................30
FIGURE3. 11 CLASS DIAGRAM FOR CLINIC MANAGEMENT SYSTEM...............................................................................31

vi
FIGURE4. 1 ARCHITECTURAL DESIGN FOR CLINIC MANAGEMENT SYSTEM..................................................................33
FIGURE4. 2 SYSTEM DECOMPOSITION FOR CLINIC MANAGEMENT SYSTEM....................................................................34
FIGURE4. 3 COMPONENT DESIGN FOR CLINIC MANAGEMENT SYSTEM..........................................................................35
FIGURE4. 4 DEPLOYMENT DIAGRAM FOR CLINIC MANAGEMENT SYSTEM...................................................................36
FIGURE4.5 DATABASE DESIGN FOR CLINIC MANAGEMENT SYSTEM.............................................................................37

FIGURE5. 1USER INTERFACE FOR LOGIN.......................................................................................................................40

FIGURE5. 2 USER INTERFACE FOR ADD NEW DOCTOR...................................................................................................41
FIGURE5. 3 SCREEN IMAGE FOR NEW DOCTOR REGISTRATION....................................................................................42
FIGURE5. 4SCREEN IMAGE FOR LOGIN PAGE.................................................................................................................43

vii
Chapter 1
Introduction

1.1 background
Clinic is an organization that is responsible in providing a health medication and treatment for all
types of peoples. Surely, everyday there are people that need to use the clinic services. But how
can clinic provide a faster and efficient services if they are still using the traditional method on
their daily operation? The traditional method means the customers need to fill in their detail in
registration form manually and the information will only keep in files. After the registration, the
files will be place in the rack and this will cause problems like taking a longer time to retrieve
the information, make mistakes during writing or misplaced the files. Clinic Management
System is developed to support the clinic daily operation before this is done manually. This
system will involve all the clinic operation starting from patient registration until billing the
patient. The important thing is it will become easier for the data record and retrieval. This system
will be able to generate report regarding the clinic operation. Nowadays many systems have been
developed to make life easier. The system will include database that will record all the data. For
the private hospital, usually they are using digital system to record the patient information and
other information that related to the hospital. There are many systems for clinic management
system, but it does not meet the local user requirement that is still new in the electronic system.
Here, it will be more explanation of the system. This new system will replace the current system
that is used in clinic and surely this system will improve the clinic services and make their daily
operation running smoothly.

1.2 Project description

Clinic management System is developed to improve the clinic management and automates the
workflow that happens in the clinic. This system is considering all the activities in the clinic.
Patient will make registration first. If the patient never registered before, patient information
collected and stored in the database. However, if it is an existing patient the patient data is
search-using IC (identification card) no or by name of the patient. This will improve the record
of the patient and record of the doctor and save the time during the registration. At this time,

1
patient is assign to the doctor Once the patient gets the treatment, the doctor will send the report
including the medicine name.

1.3 The proposed system

Our web based clinic management software that is to be developed is to minimize the problem of current
system which is described in the problem statement. Some features of this system will be recording new
patient, storing patient data, and searching patients by name, view patient details, etc .

1.4Objective
1.4.1general objective
the main objective of this project is to develop a web based clinic management system for
wollo university desse student clinic.

1.4.2specific objective of the project

 to computerized and centralized all the information in order
to reduce the time in retrieving all the data and information
 schedule the appointment of patient with doctor to make it
convenient for both.
 To promote eco-friendly software what will reduce the usage
of paper.
 The information of the patient should be kept up to date and
there recorded be kept in the system
 To computerized all detail regarding patient detail and doctor
detail.

1.5 Scope
Basically clinic hospital management system comprises many tasks associated with health
care in the clinic. This includes patient treatment and management, employee
management, inventory management, patient diagnosis and other. But our proposed
system mainly focused on clinic management in case of Wollo University dessa campus
student clinic. It supports only patient related activities such as:
 registering new patient,

2
  searching for the existing patient,
 updating and accessing patient information
 Online appointment system for patient
 Manage doctor account
 Create, manage appointment with patient
 Create prescription for patient
 This environment of this system is based on web based
programing language.
But our system doesn’t include the following activities: -
 Bed reservation for patients
 Billing activities

1.6 methodology
The purpose of the methodology is to give an experienced investigator to get enough information
to replicate the study. For conducting our project, we will use the following methodologies .
1.6.1 data collection method
Interview: - we gathered necessary information about the background of the clinic, their
work activities and the function of their existing system using some structured (when did the
clinic was established, how does the existing system function, how many patients get services
per day, how many employers are there etc.) and unstructured interview questions.

Observation: - We also arrived to the clinic and observed how workers carrying out their work
activities in a natural setting. Observation allows us to collect data in real time where activities
are being performed.

Document analysis: - we also collected certain relevant information from written documents in
the clinic. Not only that but also we tried to review other relevant documents to develop our
project proposal.

Internet: - Internet is our main source of information for the requirement of our project.

1.6.2 Development tool

Hardware tools required: - flash 16GB, hp personal computer, paper and pen.

3
 Software tools required: - windows10s, chrome browser.
Web server:- xammp or wamp server.
Programming languages: -HTML, JavaScript, php and css.

1.7 Feasibility Analysis

Feasibility analysis is the process of confirming that a strategy, plan or design is possible and
makes sense. This can be used to validate assumptions, constraints, decisions, approaches and
business cases. Feasibility study is an important phase in the software development process of
this project. the four aspects of feasibility study need to be considered are:

1.7.1 Operational Feasibility

This system brings better achievement for the operations performed by the clinic by providing
efficient registration and storage of patient information, easy register, editor update and
modification etc. This intern increases the efficiency of work in the clinic. So that one can say
that the system is operationally feasible.

1.8.2 Technical Feasibility

The proposed system can be easily maintained and repaired, because the system was developed
by familiar programming language (environment). The project team members have learned
programming languages that required for the successful completion of the project such as java
script, CSS, HTML, PHP, MySQL. We also learned the OOSAD (Object Oriented System
Analysis and Design) methodology that we followed to develop this project. Team members
have the required skill to develop the system.

1.7.3 Economic Feasibility

Economic feasibility is the process of identifying the financial benefits and costs associated with
our project being developed

1.7.4 Schedule Feasibility

The schedule for this project will be feasible due to wealthy information exchange between the
developing team, advisor and the organization. And also the time set to develop the system is
enough to complete at the predefined date and time. The project team members expected the
project to be completed on time without any delay.

4
No Task Start date Finishing date Responsible
member
Requirement specification and project selection phase
1 Identify the problem 10/07/2013 15/07/2013 All members
2 Gathering information 13/07/2013 18/07/2013 All members
3 Requirement analysis 18/07/2013 19/07/2013 All members
4 Time schedule and planning All members
of project
Project analysis phase
1 Study of current system 15/07/2013 21/07/2013 All members
1.1 Constructing process 21/07/2013 21/07/2013 All members
modeling of current system
2 Study of proposed system 23/07/2013 24/07/2013 All members
2.1 Constructing process 24/07/2013 27/07/2013 All members
modeling of proposed system
Table1. 1 Schedule Feasibility

No Task Start date Finishing date Responsible

member
Project design phase
1 Logical design 27/07/2013 27/07/2013 All members
2 Physical design 27/07/2013 28/07/2013 All members
3 User interface design 28/07/2013 29/07/2013 All members
Implementation and coding phase
1 Developing the app 29/07/2013 02/08/2013 All members
2 Building the teachable machine 02/08/2013 02/08/2013 All members
3 Connecting the app to 03/08/2013 04/08/2013 All members
teachable machine/Tensor flow
Testing and maintenance
1 Testing and maintaining the 04/08/2013 06/08/2013 All members
implementation

5
 2 Project documentation 07/08/2013 13/08/2013 All members
Table1. 2 Schedule Feasibility

Project team plan

Date Mar/10/2013 Mar/17/2013 Mar/24/2013 Apr/05/2013 Apr/15/2013

Proposal
System analysis
System design
Implementation
Test
Table1. 3 project team plan

1.8 Significance of the project

 Minimize time delay in getting information for employees and patients.

 It avoids redundancy of data.

 Displays most secured and reliable patient information.

 It ensures fast & efficient sharing of critical information across the clinic.

 It ensuring the availability of documents in secured manner.

 Minimize cost by reducing number of employees.

 Fast data insertion of the patient information.

 Minimize employees’ workload

1.8.1 Flexibility
Even small clinics can harness the power of this type of software. As the business grows, the
software automatically scales itself to the clinic’s increasing needs without the user having to
provide for it. The software is easy use, at its fullest, right from the first day.

6
1.8.2 Cost Saving
Choosing to use clinic management software located on the cloud platform is cost effective for
the clinics. This highly optimized software is maintained, updated and configured in the cloud by
the skilled software experts. The users are, thus, spared from the burden. It leads to cost saving.

1.8.3 Fast Service

This software gives fast, easy and simple solutions for the clinics in managing their day-to-day
activities.

1.9 constraint
Project constraints are limiting factors for your project that can impact quality, delivery, and
overall project success. The following constraints are the main constraints that pulled as back
from building a perfect system.

Time and cost constraint: -As we have been back to class after the corona break, the
educational schedule has been changed into short period of a semester. As a result, time was the
main constraint we’ve faced to do our job. Where as to do this type of vast projects it needs
capital for different phases of the software development cycle, starting from requirement
gathering to deployment and maintenance.

Malicious attack: - can be removed by use of antivirus soft wares

Failure of system: back up mechanisms like use of flash disks, CD/DVD for storing data is
recommended to cope with this challenge.

1.10 System Analysis and Design Approach

This system is designed by using the object oriented system analysis and design approach
which is a popular technical approach for analyzing and designing an application, system, or
business by applying object-oriented programming, as well as using visual modeling throughout
the development life cycles to foster better stakeholder communication and product quality.

OOSAD in modern software engineering is best conducted in an iterative and incremental way.
Iteration by iteration, the outputs of OOAD activities, analysis models for OOA and design

7
models for OOD respectively, will be refined and evolve continuously driven by key factors like
risks and business value.

8
Chapter 2
System analysis
2.introduction
System analysis is conducted for the purpose of studying a system or its parts in order to
identify its objectives. It is a problem-solving technique that improves the system and
ensures that all the components of the system work efficiently to accomplish their
purpose. Analysis specifies what the system should do.

2.1 existing system

The existing system has many backside advancements over the proposed system in many
ways. Due to the existing clinic management system in it is difficult to store or record
patient details since all activities are done manually using paper. Not only are these but
also there many backsides related with this existing system such as:
 If patient data is lost there is no backup data for example patient
recorded paper may be burnt or due to other problems.
 The existing system is manual not automated or computerized.
 The system does not store patient data permanently because it is
paper or manual form.
 The system does not filter data redundancy may occur.

2.1.1 Player of the Existing System

The main players of the existing system and their activity described below:
I. Patient: - a person who has some medical problems or need medical advice from the
doctor. Also have the following activities: -
 Create account
 If the doctor accepts his/her appointment communicate with doctor
and after that change information needed.
 Take the treatment
 View their personal medication
 View their appointment
 View prescription
 View history

9
II. Doctor: - a person who have a medical knowledge or a specialist that can diagnosis the
patient symptoms and give medical advice to the patient. Also have the following
activities
 Command or take physical test.
 Command medicine.
 Medical advice.
 Write patient medical history in the patient medical file.
 take physical test.
 Give medicines.
 Give physical treatment.
 Care or hold the patient carefully.
 Generate patient medical file.
 view an appointment.
 View history
III. Admin: -a person who have medical knowledge or a specialist who manage all activity in
the clinic management system. Also the following activity: -
 Add new doctor
 Add different service
 Add medicine
 Take new appointment

2.2 Business Rules

2.2.1 Business Rules Identified in the Existing System
Br1: the patient must be registered on order to take the medicine.
Br2: patients can take the treatment after communicating with the doctor.
Br3: The Doctor should have to secure the patient personal file but it is
visible for others because of it are simply putted on the shelf.
Br4: The Doctor should have to respect their patients.
Br5: The Doctor secures the patient and them self from additional
diseases during giving the service.

10
2.2.2 Business Rules in the proposed system
Br1: the user must be registered.
Br2: patients can take the treatment after communicating with the doctor.
Br3: the patient must have valid username and password.
Br4: The Doctor should have valid user name and password.
Br5: The admin should manage doctor and patient.
Br6: The patient should fill the form properly.
Br7: The Doctor should fill the form properly.
Br8: The Doctor should fill the requirements care fully

2.3 Proposed System

Our web based patient record management software that is to be developed is to minimize the
problem of current system which is described in the problem statement. The system should be
effective at the time of registration, update, and search and generate report. In the requirement
analysis phase the document we stated describes the functionalities of the system in terms of use
case from the users’ point of view. But in the design phase those functionalities of the system
shall be decomposed into smaller sub system to easily handle by developer. Patient registration
system provides away for the physician and the manager to keep the patient information.

2.3.1 The purpose of the new system

The major purpose that the new proposed system to provide the following: -
 Reduce the work load: -reduce the work load for both patient and doctor.
 Improve the time wasting: -the users of the proposed system can use the system
using their electronic device this reduce the time wasting between doctor and
patient.
 Store patient medical file: - the proposed system registers and store patient
medical file in database this reduce the paper work, the loss of data and searching
patient fill manually. Also increase the work efficiency at the clinics.

2.4 Software Requirement Specification

A software requirements specification (SRS) is a document that describes what the software will
do and how it will be expected to perform. It also describes the functionality the product needs to
fulfill all stakeholders (business, users) needs. A requirement is a feature that the system must

11
have or a constraint that it must satisfy to be accepted by the clinic management system. It
determines the needs of everyone who will be the user of the proposed system of our project
users such as: doctor, patient, admin, etc. Generally, the requirement of the new system can be
viewed as:

2.4.1 functional requirement

here are a lot of software requirements specifications included in the functional requirements of
the clinic Management System, which contains various process, namely Registration, Check out,
Report Generation, and Database.

The functional requirement of our system is shown below:

FRid Requirements description Use cases description

FR01 The system shall allow to Withdraw/dropout High

doctor, patient And admin to
withdraw

FR02 The system shall allow to login to login Low

the system
FR03 The clinic Management Adding Patients High
enables the staff in the front
desk to include new patients
to the system.

FR04 The clinic management Assigning an ID Medium

system enables the staff in to the patients
the front desk to provide a
unique ID for each patient
and then add them to the
record sheet of the patient.

FR05 the admin and patient send a add appointment Medium

request to a new
appointment.

12
 FR06 the admin of clinic add High
management system add a treatment/medicin
new treatment and medicine. e

FR07 The clinic management Assigning an ID Medium

system enables the staff in to the doctor
the front desk to provide a
unique ID for each doctor
and then add them to the
record sheet of the doctor.

FR08 The administrative staff in Adding doctor High

the ward shall use system to
assign a doctor to a given
patient.

Fr9 The administrative staff in assign treatment High

the ward shall assign room to room
the patient for treatment.

table2. 1 functional requirement

2.4.2 non-functional requirement
Non-functional requirement defines the attributes such as security, reliability,
performance, maintainability, scalability and usability. Below there is a table that defines
the non-functionality of the system:

13
 NFRID Requirements description Use cases

NFR01 The system shall contain strong password to Security

hack

NFR02 The system is available all the time. The Availability

system must be available to the intended
users 24 hours per 7 days.

NFR03 The system needs to support at least 1000 Performance

people at once.

NFR04 The CMS is reliable than manual system. It reliability

consistently performs the specified functions
without failure. works are performed
properly.

NFR05 the application is also portable from one portability

system to another system.

NFR06 The system shall to handle increasing work loads Scalability

NFR07 There is also facility of maintenance in some maintainable

time. Programmer adds some features to
maintain the application.

table2. 2 non –functional requirement

2.5 Need for Computerization: - We all know the importance of

computerization. The world is moving ahead at lightning speed and everyone
needs to run „activities in short period of time. One always wants to get the
information and perform a task he/she/they desire(s) within a short period of
time and too with amount of efficiency and accuracy. The application areas for
the computerization have been selected on the basis of the following factors:

14
 Minimizing the manual records kept at different locations.
 There will be more data integrity.
 Facilitating desired information display, very quickly, by retrieving
information from database.
 Facilitating various statistical information which helps in decision-
making.
 To reduce manual efforts in activities that involved repetitive work.
 Updating and deletion of such a huge amount of data will become
easier.

15
Chapter 3
System Analysis
3. system modeling

3.1 Introduction
The project development team used an object oriented system development methodology.
Because the Object system development approach gives easier and natural way to break
down problems into simple, small and manageable components so that it reduces the
vague appearance of the big problem. Moreover, it is predominately used and popular
method in present software development trend. The major activities described in this
chapter are Constructing a use case model, Documenting the use case course of events,
constructing sequence and activity diagram analysis level class diagram about the
proposed system.
3.2 Scenarios

construct description Syntax

Use case A sequence of action including

the function that system can use case
perform to interact with actor of
the system

Actor A coherent set of role that users of

then use case play when
interacting with these use case
actor

System Represents boundary between

boundary physical system and the actor who
interact with the physical system

16
 Association The participation of actors in use
case that is instance of actor and
instance of use case communicate
with each other

Extended The relationship from an <-------------------

extension use case to base use <<extends>>
case specify how the behavior for
extension use case can be inserted
into behavioral defined for the
base use case.

Use or include inclusion use case specifying how <<include>>

the behaviors use case for the ---------------->
inclusion uses case inserted to the
behavior for the base use case.

table3. 1Actors and use case of the proposed system description

3.2 use case modeling

The use case diagram of the system is referred to as behavior diagram used to describe the
actions of all user in a clinic management system. All user describes in the use case are
actors and functionality as action of system. It is a set of activities that produce some
output results. Each use case describes how the system reacts to an event that triggers the
system. Below there is a use case diagram for clinic management system.

17
 figure3. 1 use case diagram of clinic management system

3.2.1 Usecse description

Use Case Name: manage doctor

Use case Id: UC01

Description: admin manages the doctor which are work in clinic.
Actors:Admin
Precondition: The admin must log in to the system.
Flow of action:
Actor Action:
Step1: The admin login to his/her page.
Step2: The admin clicks on doctor link.

18
 Step4: The admin clicks on the available manages options.
Step6: The admin fills or clicks the form to submit changes.
System Response:
Step3: The system displays the option to manage the users.
Step5: The system displays the selected manage user option form.
Step7: The system displays succeed information.
Step6: Use case ends.
Post condition: the doctor will be managed in a perspective way.
table3. 2 use case description of manage doctor

Use Case Name: Manage patient

Use case Id: UC02
Description: admin and doctor manages patient information
Actors: admin,doctor
Precondition: The Doctor and admin must log in to the system.
Flow of action:
Actor Action:
Step1: The doctor and admin log to his/her page.
Step2: The doctor or admin clicks on Manage patient link.
Step4: The doctor and admin clicks on view new or history link.
Step6: The doctor and doctor view patient information.

19
System Response:
Step3: The system displays the option to manage the patient.
Step5: The system displays the order patient form.
Step7: The system displays information of patient.
Step6: Use case ends
Post condition: the patient information is managed.
table3. 3 use case description of manage patient

Use case name: View appointment

Use case Id: UC03
Description: The patient and doctor views the appointment order from the Doctor.
Actor: patient, doctor
Precondition: The Doctor sends appointment request to the patient.
Flow of action:
Actor action
Step1: the patient or doctor login to the system.
Step2: the patient and doctor open view appointment.
System response
Step3: The system displays the view appointment form.
Step4: The system displays the patient appointment.
Step5: use case ends.
Post condition: The Patient and doctor views the appointment.
table3. 4 use case description of View appointment

Use Case Name: Manage prescription

Use case Id: UC04
Description: Doctor manages the patient prescription which are used to gain medicine
Actors: Doctor
Precondition: The Doctor must log in to the system.
Flow of action:
Actor Action:

20
 Step1: The doctor log to his/her page.
Step2: The doctor clicks on Manage prescription.
Step4: The doctor clicks on the available manages options.
Step6: The doctor fills or clicks the form to submit changes.
System Response:
Step3: The system displays the option to manage the patient prescription.
Step5: The system displays the selected manage user option form.
Step7: The system displays succeed information.
Step6: Use case ends.
Post condition: the patient prescription success managed.
table3. 5 use case description of Manage prescription

Use Case Name: Manage Account

Use case Id: UC05
Description: Patient,admin and doctor manages their own account.
Actors: Patient, admin,doctor
Precondition: The patient must log in to the system.
Flow of action:
Actor Action:
Step1: The patient log to his/her page.
Step2: The patient clicks on manage account link.
Step4: The patient clicks on the available manages options.
Step6: The patient fills or clicks the form.
System Response:
Step3: The system displays the option to manage account.
Step7: The system displays succeed information.
Step6: Use case ends.
Post condition: the user will be create account in a perspective way.
table3. 6 use case description of Manage Account

21
Use Case Name: Manage service
Use case Id: UC06
Description: admin manages the different service found in clinic like medicine
Actors:admin
Precondition: The admin must log in to the system.
Flow of action:
Actor Action:
Step1: The admin log to his/her page.
Step2: The admin clicks on Manage service link.
Step4: The admin clicks on the available manages options.
Step6: The admin fills or clicks the form to submit changes.
System Response:
Step3: The system displays the option to manage the users.
Step5: The system displays the selected manage service option form.
Step7: The system displays succeed information.
Step6: Use case ends.
Post condition: the service is successfully managed.
table3. 7 use case description of Manage service

3.3 sequence diagram

A Sequence Diagram is an interaction diagram that emphasis the time ordering of
messages. a collaboration diagram is an interaction diagram that emphasizes the structural
organization of the objects that send and receive messages. Sequence diagrams and
collaboration diagrams are isomorphic, meaning that you can take one and transform it
into the other.

22
figure3. 2 sequence diagram for login

23
figure3. 3 sequence diagram for add new doctor

24
figure3. 4 sequence diagram for add new appointment

25
figure3. 5 sequence diagram for add new patien

26
 3.4 activity diagram
Activity diagram is another important behavioral diagram in UML diagram to describe
dynamic aspects of the system. Activity diagram is essentially an advanced version of
flow chart that modeling the flow from one activity to another activity. Activity diagrams
are graphical representations of workflows of stepwise activities and actions with support
for choice, iteration and concurrency. In the unified modeling language, activity diagrams
can be used to describe the business and operational step-by-step workflows of
components in a system.

figure3. 6 activity diagram for login

27
figure3. 7 Activity diagram for manage patient

28
figure3. 8 Activity diagram for appointment

29
3.5 State chart diagram
State chart diagram describes the flow of control of the proposed system from one state to
another state to describe the system dynamically. States are defined as a condition in which an
object exists and it changes when some event is triggered.

figure3. 9 login state chart diagram

30
figure3. 10 update information state chart diagram

31
3.6 class diagram
The class diagram of the clinic management system describes structure of the system by
collaborating the classes, their attributes, operations or methods and relationship among different
objects. Department approve medicine appointment

figure3. 11 class diagram for clinic management system

32
Chapter 4
System design
4.1 Introduction
System design is the transformation of the analysis model into a system design model. Up to
now we were in the problem domain. System design is the first part to get into the solution
domain in a software development. This chapter focuses on transforming the analysis model
into the design model that takes into account the non-functional requirements and constraints
described in the problem statement and requirement analysis sections discussed earlier. The
purpose of designing is to show the direction how the system is built and to obtain clear and
enough information needed to drive the actual implementation of the system. It is based on
understanding of the model the software built on. The objectives of design are to model the
system with high quality. Implementing of high quality system depend on the nature of design
created by the designer. If one wants to change to the system after it has been put in to operation
depends on the quality of the system design. So if the system is design effetely, it will be easy to make
changes to it.

4.2 Design Goals and Objectives

The objectives of design are to model the system with high quality. The design goals are derived
from non-functional requirements that means non-functional requirement is the description of
the feature characteristics and attribute of the system as well as any constraints that may limit
the boundary of the proposed solution. Design goals describe the qualities of the system that
the developers should consider.

 Reliability: Patient Information Management system should be reliable.

 Fault Tolerance: Patient Information Management system should be fault tolerant to loss of
connectivity with the service

.  Security: Patient Information Management system should be secured, i.e., not allow other
users or unauthorized users to access data that has no the right to access it.

33
 Modifiability: Our system should be modifiable for further modification and enhancement of
the application. WEB BASED clinic management system.

 Cost: The system should be developed with minimum cost possible. In reality there is always
trade-offs or disadvantages and therefore from its previous experience the Hospital prefers to
invest more on material cost than maintenance cost to minimize bugs which may appear at the

later stage.

4.3 architectural design:

Architectural design defines the collection of hardware and software components and their
interfaces to establish the desired system framework. The architectural design of clinic
management system is shown below.

figure4. 1 architectural design for clinic management system

34
4.5 system decomposition
System decomposition is deals with breaking a complex problem or system into part that are
easier to conceive, understand, program, and maintain. To reduce the complexity of the solution
domain, we decompose a system into simpler parts, called subsystems. The main need of this
portion is to design the external part of the system. The system decomposition for clinic
management system describes package of the system can have different tasks under a single part.

figure4. 2 system decomposition for clinic management system

35
4.6 component design
Component diagrams show how the physical components of a system are organized. In this
Diagram components of the system will be wired showing that there is relation among
components, management of the system, database and operations performed on databases such
security issue. The diagram is simulated below.

figure4. 3 component design for clinic management system

36
4.7 deployment diagram
Deployment modeling is used to show the hardware of the system, the software that is installed in the
hardware and also the middleware that is used to connect the disparate machines to one and other. It
also shows how the software and the hardware components work together [8]. The diagram is
simulated below:

figure4. 4 deployment diagram for clinic management system

37
4.8 database design
Logical database design is meant to describe the relationship of the database in terms of its
entities in the form of tables and the existing relationship. Below is an illustration of system
logical design as generated by entity relationship diagram.

figure4.5 Database design for clinic management system

38
Chapter five
Implementation and Testing
5.1 Introduction
During this phase physical design specification must be turned into working computer code, and
provide help for current and future users and take care of the system. And then the code is tested
until most of the errors have been detected and corrected. The purpose of this activity is to
convert the final physical system specification into working model with reliable software and
hardware.

5.2 Final Testing of the system

Testing is a process to show the correctness of the program and designed to analyze the logic
used in the implementation of the System. In the case of our project we use unit and integration
testing method.

5.3 Testing plan

Even if it is hard to develop a system we try to eliminate all faults by test plan throughout the
project life cycle. To simplify the testing our project team followed different types of tests that
break the testing process up in to distinct level. The types of testing are unit testing and
integration testing.

5.4 Unit testing

Each module is tested alone in an attempt to discover any errors in its code. In unit testing, each
module (roughly a section of code that performs a single function) is tested alone in an attempt to
discover any errors that may exist in the module’s code. We have test the system as shown below
in the appendix.

5.5 Integration testing

The process of bringing together for testing purposes all of the modules that a program
comprises. Modules are typically integrated in a top-down, incremental fashion. If an error
occurs, the process stops, the error is identified and corrected, and the test is redone. The process

39
repeats until the entire program— all modules at all level is successfully integrated and tested
with no errors. After our team tested using unit testing the next step is integrating testing. In
integrated testing the team tested the system all modules that a program contains.

5.6 Features to be tested

In order to test a program, a test engineer must perform a sequence of testing activities. This
explanation focus on single test case.
 Input output functions
 Sub system communication
 Database connection
 User name
 Login capability
 User registration
 User interface and database interaction
 Coding structure style
 User guideline documentation

5.7 Features not to be tested

Features not be tested includes the feature of the system which cannot be measured directly or
indirectly. These features cannot make serious damage to system but indirectly have an influence
on our system performance and acceptance. These features include: -
 User satisfaction of the system
 Exact response time of the system

5.8 user interface design

User interface (UI) design is the process designers use to build interfaces in software
or computerized devices, focusing on looks or style. Designers aim to
create interfaces which users find easy to use and pleasurable.

40
5.8.1 over view of user interface
The user interface of the system the means in which a person controls a software
application or hardware device. Below there are some figures of the User Interface for
the system.

figure5. 1User interface for login

41
 figure5. 2 User interface for add new doctor
5.8.2 screen image
Screen image is a screenshot image that show how the user interacts with the user
interface.
Below there are some screen image user interface of the system.

42
figure5. 3 Screen image for new doctor registration

43
figure5. 4Screen image for login page

5.9 Prototype Development

The physical design specification created by the designers is turned in
to working computer code by the programmer using Php.
Sample code for login.php:

44
<?php session start();?>

<link rel="stylesheet" href="popup_style.css">

<!DOCTYPE html>
<html lang="en">

<meta http-equiv="content-type" content="text/html;charset=UTF-

8" />
<head>
<title>Admin Panel</title>
<link href="https://fonts.googleapis.com/css?
family=Open+Sans:400,600,800" rel="stylesheet">

<link rel="stylesheet" type="text/css"

href="files/bower_components/bootstrap/css/bootstrap.min.css">

<link rel="stylesheet" type="text/css" href="files/assets/icon/themify-

icons/themify-icons.css">

<link rel="stylesheet" type="text/css"

href="files/assets/icon/icofont/css/icofont.css">

<link rel="stylesheet" type="text/css" href="files/assets/css/style.css">

</head>
<body class="fix-menu">

<?php
include('connect.php');
extract($_POST);
if(isset($_POST['btn_login']))
{

45
 $passw = hash('sha256', $_POST['password']);
function createSalt()
{
return '2123293dsj2hu2nikhiljdsd';
}
$salt = createSalt();
$pass = hash('sha256', $salt . $passw);
//echo $pass;
if($_POST['user'] == 'admin'){
$sql = "SELECT * FROM admin WHERE loginid='" .$email . "'
and password = '". $pass."'";
$result = mysqli_query($conn,$sql);
$row = mysqli_fetch_array($result);
//print_r($row);
$_SESSION["adminid"] = $row['id'];
$_SESSION["id"] = $row['id'];
$_SESSION["username"] = $row['username'];
$_SESSION["password"] = $row['password'];
$_SESSION["email"] = $row['loginid'];
$_SESSION["fname"] = $row['fname'];
$_SESSION["lname"] = $row['lname'];
$_SESSION['image'] = $row['image'];
$_SESSION['user'] = $_POST['user'];
}else if($_POST['user'] == 'doctor'){
$sql = "SELECT * FROM doctor WHERE loginid='" .$email . "'
and password = '". $pass."'";
$result = mysqli_query($conn,$sql);
$row = mysqli_fetch_array($result);
//print_r($row);

$_SESSION["doctorid"] = $row['doctorid'];

46
 $_SESSION["id"] = $row['doctorid'];
$_SESSION["password"] = $row['password'];
$_SESSION["email"] = $row['loginid'];
$_SESSION["fname"] = $row['doctorname'];
$_SESSION['user'] = $_POST['user'];
}else if($_POST['user'] == 'patient'){
$sql = "SELECT * FROM patient WHERE loginid='" .$email . "'
and password = '". $pass."'";
$result = mysqli_query($conn,$sql);
$row = mysqli_fetch_array($result);
//print_r($row);
$_SESSION["patientid"] = $row['patientid'];
$_SESSION["id"] = $row['patientid'];
$_SESSION["password"] = $row['password'];
$_SESSION["email"] = $row['loginid'];
$_SESSION["fname"] = $row['patientname'];
$_SESSION['user'] = $_POST['user'];
}
else if($_POST['user'] == 'pharmacy'){
$sql = "SELECT * FROM pharmacy WHERE loginid='" .$email . "'
and password = '". $pass."'";
$result = mysqli_query($conn,$sql);
$row = mysqli_fetch_array($result);
//print_r($row);
$_SESSION["pharmacyid"] = $row['id'];
$_SESSION["id"] = $row['id'];
$_SESSION["username"] = $row['username'];
$_SESSION["password"] = $row['password'];
$_SESSION["email"] = $row['loginid'];
$_SESSION["fname"] = $row['fname'];
$_SESSION["lname"] = $row['lname'];

47
 $_SESSION['user'] = $_POST['user'];
}//print_r($row);
$count=mysqli_num_rows($result);
if($count==1 && isset($_SESSION["email"]) &&
isset($_SESSION["password"])) {
{

}
?>

<section class="login-block">

<div class="container-fluid">
<div class="row">
<div class="col-sm-12">
<div class="row m-b-20">
<div class="col-md-12">
<img src="upload Image\Logo\wollo logo.png" height="100"
width="100">
<h5 class="text-center txt-primary">Sign In</h5>
</div>
</div>
<form method="POST" >
<div class="form-group form-primary">
<select name="user" class="form-control" required="">
<option value="">-- Select One --</option>
<option value="admin">Admin</option>
<option value="doctor">Doctor</option>
<option value="patient">Patient</option>
<option value="pharmacy">Pharmacy</option>
</select>

48
 <span class="form-bar"></span>
</div>
<div class="form-group form-primary">
<input type="email" name="email" class="form-control"
required="" placeholder="Email">
<span class="form-bar"></span>
</div>
<div class="form-group form-primary">
<input type="password" name="password" class="form-control"
required="" placeholder="Password">
<span class="form-bar"></span>
</div>
<div class="row m-t-25 text-left">
<div class="col-12">
<div class="forgot-phone text-right f-right">
</div>
</div>
</div>
<div class="row m-t-30">
<div class="col-md-12">
<button type="submit" name="btn_login" class="btn btn-primary
btn-md btn-block waves-effect text-center m-b-20">LOGIN</button>
</div>
</div>
</form>

49
Chapter Seven:
Conclusion and Recommendation
7.1 Conclusion
clinic management system for wollo university in dessa campus is not familiar. This system is an
online application to serve the whole society want to gain online medication in different
direction.
On the truck of developing this clinic management system management system for ower campus,
we have learned a lot enough. When we have goes through the analysis, the analysis part we use
our knowledge on the system analysis & design, and software engineering. In this part we apply
our theoretical knowledge on the development practically. At the same time on the design part
we put forward our knowledge of object oriented design which supports iterative method
developing software. Our knowledge of designing DB also tested.
On the implementation session also we are beneficial; because we use currently accepted and
familiar programming language PHP and its complimentary data base MySQL sever. Generally,
passing through this development of these system give us a lot of knowledge in the area
computing science not only theoretically but also practically it shows us the challenge in the real
world to develop software and benefits from it. It also shows us the need for the software in the
society to adhere data management.

7.2 Recommendation
The system that we develop is a web based clinic management system for campus makes online
each individual task. While doing this system the team members has faced different challenges.
But by the cooperation of all the group members the team is now able to reach to the final result.
I.e. all the group members strongly fight these challenge and take the turn to the front. We
strongly recommend the doctor, Admin and patient; our new system has provided them a better
service than the existing system by forming better interaction with the patient information. Our
recommendation to other system developers is that to develop by php to clinic management
system.

50
7.3 acronym
 Action - An action is the fundamental unit of behavior specification and
represents some transformation or processing in the modeled system, such
as invoking a method of a class or a sub activity.
 Activity diagram - a diagram that describes procedural logic, business
process and work flow supporting parallelism.
 Association - a relationship with 2 or more ends, where each end is on a
class (or other classifier). Each end may have a Role, Multiplicity, and be
Navigable
 class - the primary declarative construct of Object-Oriented Programming;
a cohesive unit of Attributes and Operations; a compile-time template for
an Object
 Class diagram - a type of static structure diagram that describes the
structure of a system by showing the system's classes, their attributes, and
the relationships between the classes.
 Diagram - a visual representation of a subset of features of a UML Model
 Final state - the state at which an object ceases to exist flow - a
navigational connection between two Actions
 Initial node - the start point of an Activity diagram
 Sequence diagram - describes the Messages sent between a number of
participating Objects in a Scenario
 State - an Object exists at one of the States described in a State machine
diagram

REFERENCES
Books References
1. Introducing Microsoft .NET, Second Edition author David S. Platt.
2.KALAISANAKARAN B,refers to student attendance system
project.

WEBSITES
1. http://www.google.com
3. http://www.w3schools.com/asp.net/

51
4. http://www.codeproject.com
1. http://www.wikipedia.com

52