Software Architecture and Design For Patient

Haramaya University
Software
Architecture and
Design Document
Template
For Documenting the Architectural and detailed Design of Graduating
Year Projects
Contents
1 INTRODUCTION...........................................................................................3
1.1 Purpose.........................................................................................................3
1.2 Scope........................................................................................................3
1.3 Overview..................................................................................................4
1.4 Reference Material...................................................................................4
1.5 Definitions, Acronyms and Abbreviations...............................................4
2. SYSTEM OVERVIEW..................................................................................5
3. SYSTEM ARCHITECTURE.........................................................................6
3.1 Architectural Design................................................................................6
3.2 Decomposition Description..............................................................11
3.3 Design Rationale....................................................................................17
4 DATA DESIGN............................................................................................18
4.2 Data Description.....................................................................................18
4.2 Data Dictionary......................................................................................19
5 COMPONENT DESIGN..............................................................................23
6. HUMAN INTERFACE DESIGN................................................................28
6.1 Overview of User Interface....................................................................28
6.2 Screen Images........................................................................................28
7 REQUIREMENTS MATRIX.......................................................................37
1 INTRODUCTION
1.1 Purpose
The purpose of this software architectural and design document provides a
comprehensive architectural overview of the system, using a number of different
architectural views to depict different aspects of the system. It is intended to capture
and convey the significant architectural decisions which have been made on the
system.
The development team can use this document to review the architecture of the system.
The Architecture document will be also useful for future development. It identifies
the top-level system architecture, hardware, software, communication, and interface
components.
1.2 Scope
The proposed software product is an android application of Patient

Appointment System (PAS). In this project we are going to design and build a
fully functional android based patient appointment system.
The aim of this project is to create mobile based patient appointment system.
System is providing communication between the patient and the doctor,
whereby a patient can register, login to the system, change his profile and
schedule appointment with doctor as per the doctor’s available, patient can
also interact with doctor through a message or email.
Doctors can also view his details, change his profile, view appointments and
set available time for appointment thereby making it more convenient for
them. Administrator also have access to the system and able to change
information of the system and have access to database.
1.3 Overview
The remaining sections of this document provide a general description include
characteristics of the users at this project, the product architecture and the functional
and data requirement of the product
General description of the project is discussed in section 2 of this document, section 3
gives the system architecture and Decomposition, description and Design Rationale
section 4 is for data design includes data description and data dictionary section is all
about component design and section 5 and 6 are Human Interface Design and
Requirements matrix respectively.
1.4 Reference Material
IEEE Standard 830-1998, IEEE Recommended Practice for Software

Requirements Specifications, 1998.
1.5 Definitions, Acronyms and Abbreviations
Acronyms/Abbreviatio Definition
n
PAA Patient Appointment Application
IEEE Institute of Electronics and Electrical
Engineering Standard
SRS Software Requirements Specification
Table 1: Definitions, Acronyms and Abbreviations
2. SYSTEM OVERVIEW
Even though the product, which is going to be, implemented (Patient Appointment
system) is a new product it can be used as enhancing solution for an existing system.
This system explained in this document is the first version. All the activity is done
from scratch: no prier version of the system is used for getting either functionality
being performed or specification defined.
Patient Appointment system is a new system that enhance the user of this system to
access adequate information about specified site he want to visit as well as posting his
status of view with their friends with internet connection using either mobile or
personal computer devices. Therefore, the user of this system is well satisfied since
the system is available for 7x24 hours in addition to since it does require internet
connection basically it relies on wide area networks.
3. SYSTEM ARCHITECTURE
Figure 1: patient Appointment System Architecture

3.1 Architectural Design
Figure 2: Architectural Design of System Architecture
3.1.2 Logical View
The User of this system will have the following functionalities from the system as
described by the following class diagram which will be implemented in the system.
Functionalities that the system will provide
Diagram 1: logical view of patient Appointment System
3.1.3 Process view
In this view, we try to describe the flow of activities which are mainly can be done by
this system. The process view is one of the components from the 4+1 architectural
view which can be described and illustrated using activity diagram. PAS system’s
process view has been illustrated using activity diagram.
Diagram 2: process of patient Appointment System
3.1.3 Deployment view

The deployment view of PAS is used to describe which components are
deployed on which device or hardware while deployment of the software is taken
places. The components of PAS are mainly placed on different device like on
computer and mobile such that they can request one another or they can
communicate within each other.
Diagram 3: deployment view for PAS

3.1.4 Development View
In this view model, we will illustrate a system from a programmer’s perspective and
is concerned with software management. This view will present the demonstration of
inter component relations and component wise representation of the system.
Diagram 4: deployment view for PAS

3.2 Decomposition Description
3.2.1 Admin
Identification Admin
Type Class
Purpose The purpose of this class is to enable the admin to manage hospital
Function Using this class, the admin of the system can able to add hospital, delete hospital,
add hospital manager and delete hospital manager to the system.
Subordinates This class has the following interface session and interface permeation
Dependencies This class is mainly depending on the database and the network connection.
Interface This class has the following interface

 Login
 Logout
 Forgot password
Resource Phone storage, firebase Database, Database Server, Local area network connection
Processing This class achieves the desired functionality through the following process
Deleting user from the system can be performed through deleteUser classes. So,
administrator of the system can able to delete unnecessary user from the system
by only filling username of the user after addUser class is launched
Data This class will fetch data from database and present it in plain text format.
And execute(delete) data from database that is requested by the admin
3.2.3 User
Identification Doctor, patient
Type Interface
Purpose The purpose of this Interface is to login and register for patient and doctor.
Function Using this class, the admin of the system can able to make call, receive call,
receive message and send message.
Subordinates This component has the following method
 Add doctor
 Delete doctor
 Delete patient
Dependencies This component mainly depends on the database and also depends on account
manager in some extent. This component is used foremost component of this
system because unless they have an account on this system they can’t able to
operate the functionality of this system.
 Login
 Logout
 Forgot password
Processing This component achieves the desired functionality through the following process
If user has no account on this system previously and they need to create their own
account on this system. First register User class will be launched then the user
should fill all the required filled to be registered successfully or to have a valid
account on the system.
Once they are successfully registered to the system they can access the system
using their username and password otherwise the system informs them please try
to fill all the required filled
If user forget their password, they do have a privilege to reset their password so
at this time reset class will be launched to perform this task If user is interested to
change their password the system provides a privilege to change their password
in a good way.
This component also achieves the desired functionality through the following
process Deleting user from the system can be performed through deleteUser
classes. So, administrator of the system can able to delete unnecessary user from
the system by only filling username of the user after DeactivateUser class is
launched.
3.2.4 Hospital
Identification Hospital
Type Class
Purpose The purpose of this class is to add doctor, delete doctor, update only data of his
hospital
Function Using this class, the admin of the system can able to add doctor, delete doctor,
update hospital information and delete patient of his hospital
Subordinates This class has the following interface session and interface permeation
 Login
 Logout
 Forgot password
If user has no account on this system previously and they need to create their own
account on this system. First register User class will be launched then the user
should fill all the required filled to be registered successfully or to have a valid
account on the system.
Once they are successfully registered to the system they can access the system
using their username and password otherwise the system informs them please try
to fill all the required filled
If user forget their password, they do have a privilege to reset their password so
at this time reset class will be launched to perform this task If user is interested to
change their password the system provides a privilege to change their password
in a good way so at this time Change Password method will be launched
3.2.5 Appointment
Identification Appointment
Type Class
Purpose The purpose of this class is to book appointment for doctor
Function Using this class, the admin of the system can able to send command and receive
commend
Subordinates This component has the following classes
 Send commend
 Receive command
 Responsibility
If doctor attach his free time, then the patient depending on free times send
appointment to doctor.
If schedule comfort to doctors, then confirm appointment.
3.2.6 Remainder
Identification Remainder
Type Class
Purpose The purpose of this class is to remind doctor and patient their appointment by
making alert or alarm depending on confirmation of appointment
Function Using this class, the admin of the system can able to send command and receive
commend
 Send commend
 Receive command
 Responsibility
If doctor attach his free time, then the patient depending on free times send
appointment to doctor.
If schedule comfort to doctors, then confirm appointment.
3.2.7 Time Slot

Identification Available Time
Type Class
Purpose The purpose of time slot is to providing free times to patient
Function Using this class, the doctor of the system can able to send command and receive
commend
 Send commend
 Receive command
 Responsibility
Add doctor from the system can be performed through add method. So, doctor of
the system can able to delete unnecessary patient from the system by only filling
username of the user after add user method is launched
3.3 Design Rationale

Because we are going to develop Android based which has to be more secure
and reliable system we prefer to use three tire client server architecture which
is suitable for system that involves distinct classes of services that can be
organized distributed among server and accessed from remote location that
means in our system core business logical transactions are organized or
communication are occur in distributed manner between distributed system
and they are provide information one after another and at different state in
the system facilities (e.g. authentication) can be provided in the system to
increase the security and dependability.
4 DATA DESIGN
In this section the data design description is presented as how data are
represented in this project and what type of data are used in this project.
Also, this section will discuss about available objects in the project with their
respective attributes.
We use third normal form to delete and handle any duplication of data from
the database
Diagram 5: Data design diagram
4.2 Data Description

PAS are mainly depending on database to perform the functionality required from it.
As described in the above PAS system has one databases namely PAS system
Databases. PAS system Databases has the following entities
 ADMIN table: used to store all information or attribute that are used for the
admin login in to the system
 Doctor table: used to store the attribute of the Doctor and used for identify
itself to the system in order to performs tasks.
 Patient: used to store the attribute of the patient and used for identify itself to
the system in order to performs tasks.
 Appointment table: used to store information relate to appointment.
 Hospital table used to store all information or attribute that are used in
hospital.
 Time slot: used to store the attribute of the doctor and available time of doctor.
4.2 Data Dictionary
The properties of database entities which are mentioned in the above section
will be described more in this section
Entity ADMIN
Function This is used to store all information or attribute that are used for the admin login in to
the system
Attribute It comprises of:

Admin ID: -used for identification of the row in a system
Username: -the unique name of the account that system known.
Frist Name: -the name of user
Middle Name: - father name of user
Last Name: - grandfather name of user.
Password: used to secure an application
Entity Doctor
Function This is used to store the attribute of doctor and used for identify all information

Doctor ID: -used for identification of doctor
Username: -the unique name of doctor in order to login
Frist Name: -the name of doctor
Middle Name: - father name doctor
Last Name: - grandfather doctor
Work place: - used to specify where doctor work
Department: - used to specify doctor special
Email: - used to send appointment
Phone:-used to call to patient
Entity Patient
Function This is used to store the attribute of patient and used for identify all information

Patient ID: -used for identification of patient
Username: -the unique name of patient in order to login
Frist Name: -the name of patient
Middle Name: - father name patient
Last Name: - grandfather patient
Email: - used to send appointment
Phone:-used to call to doctor
Entity Appointment
Function This is used to store the attribute of book appointment between doctor and patient

Patient ID: -used for identification of patient
Patient Name: -The Name of Patient that make Appointment
Doctor ID: -the Id of doctor
Doctor Name: - The Name of Doctor that make Appointment
Email: - the email of doctor and patient
Date: - used to show date appointment between doctor and patient
Phone: -used to call to doctor or patient
Time:- used to show time appointment between doctor and patient
Entity Hospital
Function This is used to store the attribute and information of Hospital

Hospital ID: -used for identification number of Hospital
Hospital Name: -The Name of Hospital where the doctor work in
Hospital Location: -the place where the Hospital is located
Entity Time slot

Function This is used to show available time of doctor

Date: -used to show available date of doctor
Time: - used to show available Time of doctor
5 COMPONENT DESIGN
5.1 Class Diagram of PAS
Diagram 6: Class diagram for PAS
5.2 Account Register

Diagram 7: sequence Diagram for account registration
Diagram 1: Activity Diagram for account registration
Diagram 9: Sequence Diagram for Login
Diagram 10: Activity Diagram for Login

5.3 Make Appointment
Diagram 11: sequence diagram for patient appointment

Diagram 12: Activity Diagram for patient appointment
6. HUMAN INTERFACE DESIGN
6.1 Overview of User Interface
The Graphical User Interface of our system is an interactive and responsive interface
which makes it easy to use. In the system buttons and icons will have a descriptive
verbs, menu items, list view, button, search icon, voice icon used in the interface are
user safe version and not sharp to eye, navigation bars are clearly provided for the
user in easy and simple way, it provides error messages in interactive way, protect any
wrong entry through validation, and we used aesthetic and minimalist design as a
result our system is flexible and efficient as it allows users to do frequent actions
easily and quickly.
6.2 Screen Images

Display screenshots showing the interface from the user’s perspective. These can be
hand drawn or you can use an automated drawing tool. Just make them as accurate as
possible. (Graph paper works well.)
7 REQUIREMENTS MATRIX
System component Req.ID Functional

Requirement
Appointment UR006-1 Display the available time of
the particular doctor to be
booked.
To check if the patient

is logged in or not.
Account Registration UR006-2 Display information about

Register how Doctor and
patient is to register
Doctor UR006 Collect the information of

Doctor and store it.
Patient UR005 Display information of

patient and store it

Software Architecture and Design For Patient

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Architecture and Design For Patient

Uploaded by

Copyright:

Available Formats

Haramaya University

1.4 Reference Material...................................................................................4

1.5 Definitions, Acronyms and Abbreviations...............................................4

3.1 Architectural Design................................................................................6

3.2 Decomposition Description..............................................................11

3.3 Design Rationale....................................................................................17

4.2 Data Description.....................................................................................18

4.2 Data Dictionary......................................................................................19

6. HUMAN INTERFACE DESIGN................................................................28

6.1 Overview of User Interface....................................................................28

6.2 Screen Images........................................................................................28

The proposed software product is an android application of Patient

1.4 Reference Material

IEEE Standard 830-1998, IEEE Recommended Practice for Software

1.5 Definitions, Acronyms and Abbreviations

Figure 1: patient Appointment System Architecture

Figure 2: Architectural Design of System Architecture

3.1.2 Logical View

3.1.3 Deployment view

Diagram 3: deployment view for PAS

Diagram 4: deployment view for PAS

Interface This class has the following interface

3.2.7 Time Slot

3.3 Design Rationale

4.2 Data Description

Databases. PAS system Databases has the following entities

Attribute It comprises of:

Attribute It comprises of:

Attribute It comprises of:

Attribute It comprises of:

Attribute It comprises of:

Entity Time slot

Attribute It comprises of:

5.2 Account Register

Diagram 10: Activity Diagram for Login

Diagram 11: sequence diagram for patient appointment

6.2 Screen Images

System component Req.ID Functional

To check if the patient

Account Registration UR006-2 Display information about

Doctor UR006 Collect the information of

Patient UR005 Display information of

You might also like