University of Azad Jammu and Kashmir

Muzaffarabad

SOFTWARE ARCHITECTURE
DESIGN DOCUMENT
For
PROFESSIONAL HEALTH CARE NETWORK
By
AAFAQ ZAIB 17-SE-03
MEHRAN ISHTIAQ 17-SE-22
MUHAMMAD ADIL 17-SE-26

SESSION: 2017-21
Supervisor:
ENGR. SAAD MUJAHID KHAN

Bachelor of Science in Software Engineering

Table of Contents
Table of Contents Revision
History
1 Introduction
2 Background
3 Functional Requirements
4 Quality Attributes
4.1 Usability
4.2 Availability
4.3 Maintainability
4.4 Testability
5 Architecture Overview
5.1 Big Picture
5.1.1 System Context
5.1.2 User Interactions
5.1.3 Data Flow
5.2 View Introduction
5.3 Patterns and Tactics
5.3.1 Architectural Drivers and Tactics
Usability
Availability
Maintainability
Testability
5.3.2 Patterns Service
Oriented Pattern
Domain Model and Data Mapper Patterns
Client-server Pattern Modelviewcontroller
Pattern
6 Views
6.1 Logical (Layered) View
6.1.1 View Diagram
Notation Explanation
6.1.2 Element Catalog
Elements
Presentation Layer
Application Logic Layer
Service Layer
Domain Model Layer Data
Access Layer (DAL) Data
Source Layer
Relations
 Presentation Layer to Application Logic Layer
Application Logic Layer to Domain Layer Domain
Layer to DAL to Data Source Layer
Interfaces
Interface Identity Services
Provided
Syntax Semantics
Data Input and Output
Other Considerations
Exception Definitions
Quality Attribute Characteristics
Design Rationale
6.1.3 Rationale
6.2 Process View
6.2.1 View Diagram
6.2.2 Element Catalog
Elements
Client
Server
Request/Reply Connector Relations
Client to Server Interfaces
Interface Identity Services
Provided
Syntax Semantics
Data Input and Output
Other Considerations
6.2.3 Rationale
7 Acknowledgements
8 References
9 Appendices Appendix
A: Glossary
Appendix B: Issues List
 INTRODUCTION

1.2 STATEMENT OF THE PROBLEM:

The purpose of this document is to define features of health care network
and the IT services that will be provided. In our project we will develop a
custom designed, responsive and visually attractive website for
Healthcare Network. General visitor of the site will be able to browse the
healthcare services and use payment gateway to book an appointment.
Admin would be able to add, modify and edit generic content on the site.

1.3 PURPOSE OF PROJECT:

Being the students of engineering and technology, we have a passion for
technology. We take on big challenges and pride ourselves on seeing
them through and are looking forward to develop an attractive and user-
friendly website. Expert Healthcare community is an internet marketplace
for healthcare. We accomplice with trusted nearby vendors to offer
exceptional healthcare at honest prices. The process charges encompass
related prices so your handiest pay one inclusive rate and not using a
wonder bill. In case you do no longer receive take care of your purchased
technique, we are able to refund your price in full.

1.4 APPLICATION OF PROJECT:

The ease of online1scheduling software enables it to be applied for a
variety of different applications and act at scientific, healthcare and health
facilities, which includes:
• Scheduling patient appointments, remedies and offerings.
• Scheduling on-website seminars and activities

The benefits a web scheduling gadget for both administrative body of

workers and patients and other reserving people encompass:
• Time financial savings: Personnel spend less time at the phone
reserving and managing appointments, thereby releasing up their
schedule for more crucial and urgent duties. Reserving people
additionally store time, as they not must devote part of their busy
schedule to calling their clinical, healthcare or wellbeing issuer (or
continue to be on preserve, which provides mines to the scheduling
process). “

• Monetary1savings: The time financial savings experienced by a

facility can translate into economic savings, as both group of
workers time and offerings translate into prices and revenue,
respectively. As body of workers sources can now be directed at
other responsibilities, a scheduling device can take away the need
for a personnel member to work time beyond regulation or for
management to hire new group of workers participants to handle
the paintings overload created with the aid of the appointment-
scheduling technique.

• 24-Hour comfort: Scheduling appointments over the telephone

commonly requires a person to smartphone in throughout office
hours, as few centres offer round-the-clock telephone reserving.
That is an inconvenience for most patients, as they too are working
at the moment. Additionally, many people opt to time table their
appointments on line in preference to over the phone. An online
scheduling machine lets in for twenty-four-hour scheduling, now
not just for the duration of regular facility or workplace hours.”
1.5 SUMMARY:
In this chapter, we discuss about the introduction of Health care Network.
We also mention the problems that why we choose the project and what’s
the scope of project. We have designed a website-based Health Care
Network in order to save time and doctor availability in order to ease for
both patient and doctor. Simply we design the website-based Health Care
Network.

Background:
Statistics system has emerged as a vital factor for any growing enterprise
in latest years. Because the growing enterprise desires to have correct
information and essential generation for solving troubles and to trap up
with ever growing customer wishes, facts machine technology has been a
key force for corporations to determine their commercial enterprise
criteria. companies these days use records machine and use the to be had
technology because they apprehend the importance of retaining and
updating facts electronically [1] using facts system for managing
information inside the fitness care along with patient file, patient
appointment machine, sufferers scheduling appointment and physician
schedule isn't only a less complicated way to save time and decrease
price, however additionally a manner to support and enhance the fitness
care information to be greater handy and bendy (editing, saving, deleting,
updating) for system users and storing information successfully.
Similarly, it improves the satisfactory of information manage [1].
Enhancing patient care management is one of the fundamental aims of
healthcare industry these days to improve the healthcare system
international. This goal is to be similarly if no longer greater vital as the
alternative keys of improving the fitness of the population and managing
per capita price of care [2] because the population keeps to grow, so too
does the need for healthcare offerings and alternatives. (The blessings Of
online Appointment Scheduling. 1st ed) fitness Care carrier companies
globally are experiencing an boom in pressure to concurrently reduce cost
and enhance accessibility and high-quality of care they supply particularly
resolving long waiting times, delays and queue of sufferers. [2]
Consequently a patient Scheduling gadget is launched as a critical issue of
scheduling and dealing with appointments. Especially on line scheduling
software has simplified and automatic the manner of clinic management
for all length of corporations.”

1. Requirements:

Functional Requirements:
Table 1.1
Identifier FR1
Title Registration
Requirement Patient wants to register his account
Source Stakeholders
Rationale To register an account to login.
Business Rule (if Not Applicable
required)
Dependencies Not Applicable
Priority Medium

Table 2.2
Identifier FR2
Title Login
Requirement Patient wants to login
Source Stakeholders
Rationale To login and use the application
Business Rule (if Not Applicable
required)
Dependencies FR1
 Priority Medium

Table 3.3
Identifier FR3
Title Registered Practicing Doctors
Requirement Practicing Doctors must be registered onto the Application
and Patients can access their data example phone number
address etc. and view their profile.
Source Stakeholders
Rationale To have access with Doctor on the application.
Business Rule (if Not Applicable
required)
Dependencies FR2
Priority High

Table 4.4
Identifier FR4
Title Practicing Doctor categories
Requirement There should be different categories of doctors for instance
Orthopaedic, Cosmetic services, Primary care physician
etc.
Source Stakeholders
Rationale To have different categories of Doctor on the application.
Business Rule (if Not Applicable
required)
Dependencies FR2
Priority High

Table 5.5
Identifier FR5
 Title Appointment with Practicing Doctors
Requirement The application must provide Patients to make appointment
with doctors. Doctors can check their upcoming
appointments with clients and can cancel them.
Source Stakeholders
Rationale Clients can have appointment with Doctor.
Business Rule (if Not Applicable
required)
Dependencies FR4, FR3
Priority High

Table 6.6
Identifier FR6
Title Payment Method
Requirement There should be a payment method for all Doctors before
physical check-up.
Source Stakeholders
Rationale Client can pay the Doctor for appointment
Business Rule (if Not Applicable
required)
Dependencies FR3, FR4
Priority Medium

Quality Attributes:
 i. Usability

Usability requirements deal with ease of learning, ease of use, error avoidance and
recovery, efficiency of interactions, and accessibility. The usability requirements
specified here will help the Patient interface designer create the optimum Patient
experience.
 USE-1: The Patient must get familiar with the application in less than 5
seconds.
 USE-2: Patient will be able to use the application without getting confused or
difficulty.
 USE-3: The Patient should be able to understand every functionality of the
system without any inconvenience.
 USE-4: System shall be designed using consistent ad standardized approaches.
 USE-5: High internet connection is needed for this application.

4.2 Availability:

A bug or fault in the application causes a system wide

Scenario
failure.
Source Internal to system
Stimulus A bug or fault in the application
Artefact The component in which the bug or fault occurred
Environment Degraded
The system handles any and all exceptions that may occur,
Response
so that the system may fail gracefully.
A meaningful error message is logged, indicating what it
Response Measure
was that caused the application to fail.

Architecture Overview:
1.1 Big Picture:
The major subsystems are described in high-level details below in Section
Views. In short, they are divided up by layers. There is the view, business logic,
domain model, data interaction layer, and data source. Each of these divisions is
vital for the system to operate.

1.2 User Interactions:

Figure 2. User interaction with the Coop Evaluation System

The diagram above show a high-level view of the user interaction with the
system as well as the interaction between technologies involved.

1.1.1 Data Flow

The above diagram shows the basic flow of data into and out of the system.

1.1 Patterns and Tactics:

1.1.1 Architectural Drivers and Tactics:
Usability:
In order to maintain our focus on usability and iterate quickly on our user interface,
we will be using the tactic Separate User Interface. This allows us to keep the user
interface separated from the backend business logic and data source, thus enabling
changes to be made easier or even for the user interface to be swapped out in the
future, if another modernization is needed. The team will utilize a modelview-
controller architectural pattern to accomplish this task.

Availability
Availability is an important architectural driver for the system, as the system
must be available in order for students and employers to submit evaluations.
Additionally, the system must be available for coops to be approved or denied,
and for administrators to perform various managerial tasks. If the system is
unavailable for any of these tasks, cascading delays may occur during any stage
of the coop evaluation process.

Maintainability
Maintainability is an important architectural driver for the system because the
system will be maintained by ITS on regular basis once the system is deployed in
production. This is also an important service at RIT so if defects arise, fixes must be
able to be deployed as quickly as possible.

Testability
Testability must be determined in early stages of development. Due to the
iterative nature of our methodology, regression testing will be one of the primary
forms of testing conducted.
Therefore, the tactic Able to Stub/Mock is highly valued to us. This tactic will
allow us to create tests and quickly use them to test the system when changes are
made or new features are added to the system.
Another tactic for testing our team plans to conduct is Separating the Interface
from Implementation, which is a form of providing input and capturing output.
Separating the interface from the implementation allows substitution of
implementations for various testing purposes. This will also allow us to write
tests without having to touch the interface itself.

1.1.2 Patterns
Service-Oriented Pattern
The service oriented pattern compartmentalizes different features within the
application. This pattern describes a collection of distributed components that
provide and/or consume services. Service consumers are able to use these
services without any detailed knowledge of their implementation.

This allows for easy maintainability, as each service can be altered without affecting
the other services of the system. Additionally, each service can be tested
independently of each other, which can be useful in pinpointing potential defects.
Domain Model and Data Mapper Patterns
The domain model pattern incorporates both behavior and data into an object-
oriented model of the application domain. When using this pattern, the model of
the domain is organized primarily around the nouns in the domain. The domain
model is then separated from the database with the use of the data mapper
pattern.

The data mapper is a layer that sits between the database and the domain model,
which handles the loading and storing between the database and the domain
model; Therefore allowing both to vary independently. This separation of the
database and domain model means that the domain objects do not have any
knowledge that that database exists, and the domain model does not know that
the data mapper exists.

The separation introduced by the data mapper pattern supports modifiability, as

either entity can be modified independently of each other. The use of the domain
model pattern supports increasing complexity and thus enhances extensibility as
well.

Client-Server Pattern
Clients initiate interactions with servers, which provide a set of services. The
clients invoke services as needed from those servers, and then wait for the results
of those requests.
Client is responsible for displaying and performing small updates on the data,
while the server handles data management.
The client-server pattern supports modifiability and reuse, as it factors out
common services, allowing them to be modified in a single location. This pattern
also supports scalability and availability by centralizing the control of these
resources and servers.

Model-View-Controller Pattern
The modelviewcontroller (MVC) pattern separates user interface functionality
from application functionality. With MVC, application functionality is divided
into three types of components: models, which contain the application data;
Views, which display the underlying data and interact with the user; And
controllers, which mediate between the model and the view and manage state
changes.

The MVC pattern supports usability, as it allows the user interface to be designed
and implemented separately from the rest of the application.

2 Views
2.1 Logical (Layered) View
2.1.1 View Diagram
Figure 4. A layered view of the Coop Evaluation System
2.1.2 Element Catalog
Elements

Presentation Layer
The presentation layer will provide the user with a graphical interface for
interacting with the system. It will be composed of HTML, CSS, JavaScript, and
other related files that will run in the user’s web browser of choice. The main
goal of this layer is to provide everything the user needs to complete their tasks in
the system. The quality attributes that pertain to usability and frontend design
will have the biggest pull on the presentation.
Application Logic Layer
The role of the application logic layer is to encapsulate the system controllers,
which implement much of the core business logic. It will also serve as the
connection between the user interface and the domain model, thus maintaining
the separation of concerns.
Service Layer
The service layer is in charge of modularizing different features (services) of the
application. Certain features, such as reporting, require access to external APIs;
the service layer will be in charge of interacting with those external APIs. An
individual service can also use the application logic layer to perform core
business logic.

Each service will act as a facade, serving as a general interface for a feature that
can be accessed by the presentation layer. These facades (interfaces) will provide
the ability to manipulate or fix the code underneath each service without
affecting the way in which that service is called by other layers.
Modularizing the services within the system will also make it easier to
pinpoint potential defects, allowing for easy maintainability. Each service
can be tested individually, which allows for good system wide testability.
Domain Model Layer
The domain model contains all of the system’s object representations of data in
the system. This also includes associated methods for any objects that contain
their own functionality.
Data Access Layer (DAL)
The data access layer contains all of the mappers to the data in the system. The
mappers are in charge of the coordination of all communication between the
objects in the domain layer and their corresponding tables in the database. This
ensures that domain layer objects have no knowledge of the database, its schema,
or any SQL interface.

Data Source Layer

All persistent information and any external API integration (e.g. SIS, Simplicity)
make up the data source layer. This includes the Oracle database that will contain
all of the data for the system. At this time there is no expectation for integration
with external systems, but the system should be architected to accommodate such
integrations in the future, as there are a few options on the table.

Data Input and Output

The user inputs their information through forms displayed in their web browser
of choice. The client then sends that data to the server through the service layer to
the application logic layer for processing, manipulation, and transformation
before being written to the domain model layer. The information may be
forwarded on through the data access layer to the data source layer to be written
out to the database for more permanent persistence through the use of CRUD
operations. Data may also be retrieved from the data source and manipulated by
the application logic layer before being displayed on the view to the user. Of
course, any and all transformation of data only occurs as necessary, and there
may be a case where the unformatted data is called for, such as displaying all the
information in a given table.
2.1.3 Element Catalog
Elements

Client
A client is a component that invokes services of a server component. Clients have
ports that describe the services they require. In the context of the Coop
Evaluation System, the client is a web browser being used to access the system.
The client makes HTTP requests using Restful web services.
Server
A server is a component that provides services to clients. Servers have ports that
describe the services they provide. The Coop Evaluation System will be deployed
on an Apache Tomcat web server. Tomcat implements the Java Servlet and Java
Server Pages (JSP) specifications from Oracle, and provides a Java web server
environment for Java code to run in. The server provides web services through
HTTP, a TCP/IP application layer protocol.
Request/Reply Connector
Request and reply connectors are data connector employing a request/reply
protocol, used by a client to invoke services on a server. For the Coop Evaluation
System, the client and server will communicate using Restful web services. The
client will request information from the server using HTTP for normal requests,
and HTTPS for secure transactions. In return, the server will respond using
HTTP responses.

The server will communicate with the Oracle SQL database using a data
persistence framework for mapping Java objects to database records. This
communication takes place in the form of SQL statements and stored procedures.

Relations

Client to Server
The client and server communicate with each other using a request response
messaging pattern. The client sends a request to the server, and the server sends a
response in return. The client and server use a common language of Restful web
services, so that both the client and server know what to expect. To handle
multiple requests at once, the server uses a scheduling system to prioritize
incoming requests from clients. The server also limits how a client can use the
server’s resources in order to prevent a denial of service attack.
Interfaces

Interface Identity
Both the client and external APIs interface with the server through the service
layer. A variety of services will be defined so that the user interface and external
APIs may be swapped in and out without having to modify the business logic
of the application. By defining a common interface for each service,
communication of the user interface and external APIs with the system is kept
consistent, and easily modifiable.

8. References:

The project on which we are working is related to following references:

1) https://oladoc.com/
2) https://www.zocdoc.com/
3) https://www.marham.pk/
4) https://aaci.org/
5) https://harbourmedical.com/
21