Contents

1. Introduction ……………………………………………………………………………1
2. Problem Specification …………………………………………………………………1
2.1. Existing System
2.2. Proposed System
3. System Requirements & Analysis …………………………………………………….2
3.1. Requirements
3.1.1. Software Requirements
3.1.2. Hardware Requirements
3.1.3. Functional Requirements
3.2. Analysis …………………………………………………………………2
3.2.1. Use Case Diagram
3.2.2. Sequence Diagram
3.2.3. Collaboration Diagram
3.2.4. Activity Diagram
4. System Design ………………………………………………………………………….8
4.1. Class Diagram
4.2. State Chart Diagram
4.3. Component Diagram
4.4. Deployment Diagram
5. Coding ………………………………………………………………………………….12
6. Conclusion ……………………………………………………………………………...20

Bibliography ………………………………

Abstract
This project is designed to produce computerized system for medical diagnosis where there are
few or no doctors. It attempts to develop an interactive and user-friendly system, which can be
used by every user of the computer system. Software was developed for identifying the various
symptoms and different diagnosis as related to the diseases.

The necessary framework for the system design and implementation was given as well as
important information for security and maintenance. Data are collected from medical doctors who
are experts in medicine through short oral interview.

The Diagnostic and Treatment Expert System for Hypertension in Pregnancy has so far remained
at the testing phase of its life cycle and is yet to be implemented. During the research, it was
found that there is an acute shortage of specialist obstetricians in the Reproductive Health
Division which implies that there is also scarce expert knowledge on the diagnosis and treatment
of Hypertension in Pregnancy, yet the condition continues to kill many women of reproductive
age in Kenya, hence the need to develop the Medical Expert System (MES) as an expert
knowledge sharing tool to be used by other medical personnel within the Reproductive Health
Division who are not specialists in diagnosis and treatment of Hypertension .

1. INTRODUCTION

The existing system has few limitations which makes it inefficient and make it difficult to use.
So a new system is developed which help us to reduce over work and make it user friendly. The
system is developed from a new version of database which makes deletion insertion easy. The
system is used to perform all the activities carried out in a hospital. The proposed system is used
by the hospitals to give the details description of disease and the treatment with respect to
disease. The system is programmed is such a way that each time appointment time is over the
database updates automatically.

The advantage of the system is because system is developed using visual basic as front end and
access as back end. The design for the system is developed using rational rose. Using these
diagrams the system is developed.

The need for this system arises due to the major LIMITATION of the existing system. The
existing system uses an older version of database. This system is to slow and is inefficient and
can not be used nowadays. So the system that is being described can be used. The system was
not user friendly. So the system had many limitations and to overcome this disadvantage the
proposed system that being discussed came into use. This system uses a proposed version of
database which is too easy to use and very efficient.

2. Problem Specification

This system offers to know the details and treatment of disease. The patient gives the symptoms
to the system. The system analysis for treatment. The patient receives the prescription from
system.
2.1 present system:

The present system is inefficient and time consuming. Only one appointment cannot be changed.
The prescription is not specified after consulting in database. The receptionist cannot give proper
details of appointment.

2.2 proposed system:

The proposed system that is being developed is user friendly system. The processing speed is
very high when compared to the existing system. The space occupied by the proposed system in
the memory is also very less. The doctor details can be known. There is review of details of
disease treatment. The appointment can be made.

3. System Requirements & Analysis

3.1Requirements

3.1.1 Software Requirements

OPERATING SYSTEM: WIN2000/XP
PROGRAMMING PACKAGE: VISUAL BASIC 6.0
DATABASE: MICROSOFT ACCESS
DESIGING SOFTWARE: RATIONAL ROSE 4.2.0

3.1.2 Hardware Requirements

Ram 1GB
Hard Disk 160GB
Processor Pentium-4
Operating System WinXP/2000/98
Mother Board Intel d856
Keyboard Microsoft keyboard
Mouse Microsoft optical
Monitor LG 17”flatiron CRT

3.1.3 Functional Requirements

Functional requirements may be calculations, technical details, data manipulation and
processing and other specific functionality that define what a system is supposed to
accomplish. Behavioral requirements describing all the cases where the system uses the
functional requirements are captured in use cases. Functional requirements are supported
by non-functional requirements (also known as quality requirements), which impose
constraints on the design or implementation (such as performance requirements, security,
or reliability). Generally, functional requirements are expressed in the form "system must
do ", while non-functional requirements are "system shall be ".

The plan for implementing functional requirements is detailed in the system design. The
plan for implementing non-functional requirements.Non-Functional Requirement In
systems engineering and requirements engineering, a non-functional requirement is a
requirement that specifies criteria that can be used to judge the operation of a system,
rather than specific behaviors. This should be contrasted with functional requirements
 that define specific behavior or functions. The plan for implementing functional
requirements is detailed in the system design. The plan for implementing non-functional
requirements is detailed in the system architecture. Broadly, functional requirements
define what a system is supposed to do and nonfunctional requirements define how a
system is supposed to be. Functional requirements are usually in the form of "system
shall do ", an individual action of part of the system, perhaps explicitly in the sense of a
mathematical function, a black box description input, output, process and control
functional model or IPO Model. In contrast, non-functional requirements are in the form
of "system shall be ", an overall property of the system as a whole or of a particular
aspect and not a specific function.

3.2 Analysis

3.2.1

1.1.1 Use case diagram

 Use-case modeling is a specialized type of structural modeling concerned with
modeling the functionality of a system. Use-case modeling typically starts early in a
project and continues throughout a system development process. Two main elements are
Actors and Use cases.

An actor is a user or external system with which a system being modeled

interacts. An actor is external to a system, interacts with the system, may be a human
user or another system, and has goals and responsibilities to satisfy in interacting with the
system.

A use case defines a functional requirement that is described as a sequence of

steps, which include actions performed by a system and interactions between the system
and actors.

The identified actors are: patient, doctor

Use cases are:

3.2.2 Sequence diagram

A sequence diagram shows elements as they interact over time, showing an interaction or
interaction instance. Sequence diagrams are organized along two axes: the horizontal axis shows
the elements that are involved in the interaction, and the vertical axis represents time proceeding
down the page. The elements on the horizontal axis may appear in any order. Sequence-
diagrams are made up of a number of elements, including class roles, specific objects, lifelines,
and activations.

3.2.3 Collaboration diagram

A collaboration diagram shows elements as they interact over time and how they are related.
Collaboration diagrams are especially useful for visualizing the impact of an interaction on the
various elements, because you can place an element on a diagram and immediately see all the
other elements with which it interacts. Collaboration diagrams are made up of a number of
elements, including class roles, specific objects, association roles, and specific links.

3.2.4 Activity diagram

Activity diagrams are very similar to a flowchart because you can model a workflow from
activity to activity. An activity diagram is basically a special case of a state machine in which
most of the states are activities and most of the transitions are implicitly triggered by completion
of the actions in the source activities

4. System Design

4.1 Class diagram

 A class diagram is a picture for describing generic descriptions of possible systems.
Class diagrams and collaboration diagrams are alternate representations of object models.
Class diagrams contain classes and object diagrams contain objects, but it is possible to
mix classes and objects when dealing with various kinds of metadata, so the separation is
not rigid.

The identified classes are :patient, doctor

Identifying attributes: name, no, age, address.aos

Identifying Operations:add, delete, view, update

4.2 State chart diagram

 State chart diagrams model the dynamic behavior of individual classes or any other kind of
object. They show the sequences of states that an object goes through, the events that cause a
transition from one state to another and the actions that result from a state change.

Each state represents a named condition during the life of an object during which it satisfies
some condition or waits for some event. A state chart diagram typically contains one start
state and multiple end states. Transitions connect the various states on the diagram. As with
activity diagrams, decisions, synchronizations, and activities may also appear on state chart
diagrams

4.3 Component diagram

 Component diagrams provide a physical view of the current model. A component
diagram shows the organizations and dependencies among software components, including
source code components, binary code components, and executable components. These diagrams
also show the externally-visible behavior of the components by displaying the interfaces of the
components. Calling dependencies among components are shown as dependency relationships
between components and interfaces on other components.

administrator portal

database

4.4 Deployment diagram

A deployment diagram shows processors, devices, and connections. Each model contains
a single deployment diagram which shows the connections between its processors and devices,
and the allocation of its processes to processors.