PA1301 1305 HT08 LP1 Assignment1

Health ‘R’ Us Group 17
Health 'R' US
Murtaza Ali Imtiaz, Mohsin Irshad, Muhmammad Nasir, Muhammad Mansur
Blekinge Tekniska Högskola Ronneby, Sweden
{maim07, moir08, mund07, mbmu08}@student.bth.se
TABLE OF CONTENTS
1. Introduction ...................................................................................................................................................................... 3

1.1 Quality Requirements .................................................................................................................................................. 3
2. System Architecture ......................................................................................................................................................... 4
2.1 Global Analysis ........................................................................................................................................................... 4
2.1.1 Product Factors Factor Table ........................................................................................................................... 4
2.1.2 Developing Strategies: Issue Cards ................................................................................................................. 6
2.1.3 Technology Factors Factor Table ..................................................................................................................... 9
2.1.4 Developing Strategies: Issue Cards ............................................................................................................... 10
2.2 Conceptual View ....................................................................................................................................................... 11
2.2.1 Global Analysis ............................................................................................................................................. 11
2.2.2 Central Design Tasks ..................................................................................................................................... 11
2.2.3 Final Design Tasks: Resource Budgeting ...................................................................................................... 28
2.2.4 Design Summary for Hospital R Us Conceptual View .................................................................................. 29
2.3 Module View ............................................................................................................................................................. 30
2.3.1 Global Analysis for Module View ................................................................................................................. 30
2.3.2 Central Design Tasks: Layers and Modules................................................................................................... 30
2.4 Execution Architecture View ..................................................................................................................................... 48
2.4.1 Global Analysis ............................................................................................................................................. 48
2.4.2 Central Design Task....................................................................................................................................... 48
2.4.4 Design Summary for Execution View ................................................................................................................... 57
3. Evaluation ...................................................................................................................................................................... 58
3.1 Chosen Evaluation Method and Motivations ............................................................................................................ 58
3.2 Problem Description .................................................................................................................................................. 58
3.3 Quality Attribute Measure ......................................................................................................................................... 59
3.4 Architectural Style ..................................................................................................................................................... 59
3.5 Quality Attribute Parameters ..................................................................................................................................... 59
3.6 Analysis ..................................................................................................................................................................... 59
3.7 Evaluation Results ..................................................................................................................................................... 61
4. Transformation ............................................................................................................................................................... 61
4.1 Imposing Architectural Styles ................................................................................................................................... 61
4.2 Imposing Architectural Patterns ................................................................................................................................ 61
4.3 Applying Design Patterns .......................................................................................................................................... 62
4.4 Converting Quality Requirements to Functionality ................................................................................................... 62
5. Second Evaluation .......................................................................................................................................................... 62
5.1 Analysis ..................................................................................................................................................................... 62
5.2 Evaluation Results ..................................................................................................................................................... 63
6. Transformed System Architecture .................................................................................................................................. 63
6.1 Availability in Disk Space ......................................................................................................................................... 63
Global Analysis .............................................................................................................................................................. 63
6.2 Network Bandwidth Reservation .............................................................................................................................. 63
Network Operations Center (cont.) ................................................................................................................................ 63
6.3 Additional Network Connection................................................................................................................................ 64
Network Operations Center (cont.) ................................................................................................................................ 64
6.4 Error Control ............................................................................................................................................................. 64
6.4.1 Global Analysis ............................................................................................................................................. 64
6.4.2 Conceptual View (cont.) ................................................................................................................................ 64
Page 1 of 73
6.4.3 Module View (cont.) ...................................................................................................................................... 65
6.5 Alerts and Display of Private Information ................................................................................................................ 66
6.5.1 Global Analysis ............................................................................................................................................. 66
6.5.3 Module View (cont.) ...................................................................................................................................... 67
6.6 Web Wallet ................................................................................................................................................................ 67
6.6.1 Global Analysis .................................................................................................................................................... 67
6.6.2 Implementation .............................................................................................................................................. 68
6.7 Backup Servers .......................................................................................................................................................... 68
7. Peer Evaluation .............................................................................................................................................................. 68
8. Transformation ............................................................................................................................................................... 69
8.1 Imposing Architectural Styles ................................................................................................................................... 69
8.2 Imposing Architectural Patterns ................................................................................................................................ 69
8.3 Applying Design Patterns .......................................................................................................................................... 69
8.4 Converting Quality Requirements to Functionality ................................................................................................... 69
9. Transformed System Architecture .................................................................................................................................. 69
9.1 Roles, Privileges and Administration ........................................................................................................................ 69
9.1.1 Global Analysis .................................................................................................................................................... 69
9.1.3 Module View (cont.) ...................................................................................................................................... 70
9.2 Session Management and Activity Logs ................................................................................................................... 71
9.2.1 Global Analysis .................................................................................................................................................... 71
9.2.2 Module View (cont.) ...................................................................................................................................... 71
9.3 Locking of Journals ................................................................................................................................................... 72
9.3.1 Global Analysis .................................................................................................................................................... 72
9.3.2 Implementation ..................................................................................................................................................... 72
9.4 Multithreading ........................................................................................................................................................... 72
9.5 Point and Click Performance ..................................................................................................................................... 72
10. Summary ........................................................................................................................................................................ 72
11. References ...................................................................................................................................................................... 73
Page 2 of 73
1. Introduction
This document describes the software architecture of a health system called “Health R US”. This health system consists of
different hospitals and healthcare institutions. These are inter-connected to share information in the form of journals. These
journals contain case history of patients. These journals accompany patients from their initial medical checkup till the end of
their treatment. Patients move from one healthcare institution or hospital to another. They need their journals to be accessed
at other hospitals or healthcare institutions. A software system is to be implemented to share journals and journals data
among all hospitals and healthcare institutions. This report consists of a proposed architecture of the system in the light of
Applied Software Architecture by Christine Hofmeister, Robert Nord, Dilip Soni foreward by Cris Kobryn [1]. Software
system has functional and non-functional which are also categorized as quality requirements. Detailed introduction about
the system is presented in the form of functional and quality requirements.
Journals with patient’s information are placed on centralized servers. Each centralized server contains information for
healthcare institution or hospital. Healthcare institutions and hospitals are connected to each other via internetwork. Users
connect to the system through their standard PCs and handheld devices. Unauthorized access not denied to users, whether
they access information within a single hospital of institution or between different healthcare institutions. System provides
concurrent access for multiple users. In such an access, updated changes must be visible to all users. These updates are
visible without any delay. The system contains complete information about patients. It also supports version management
for journals. Users are able to access information for which they are designated to perform operations. During updating
information it is possible to go back and view prior information. Images and videos are stored as a part of the journal data.
The contain ultrasounds, EKG graphics, X-rays etc. Backward compatibility is possible i.e. it is possible to add digitized
versions of paper based journals.
1.1 Quality Requirements

Increase in Data Size: Number of journals in the system can increase exponentially. It can be up to and exceeding ninety
hundred thousand, which is more than current population of Sweden.
Network Capability/Scalability: System provides capability of handling at least hundred, interconnected hospitals. Each
hospital can have more than ten departments.
Reliability: System operates safely, i.e. no erroneous data can be inserted into the system.
Dependability: System is able to survive both power and communication failures.
Confidentiality: Personal information about patients is kept secure i.e. nobody is able to view private confidential
information; their safety is in line with Swedish laws.
Information Security: Unauthorized access is not granted to any confidential or personal information.
Availability: Journals are available twenty four hours day, seven days a week and twelve months a year.
Performance: Typical search time for finding and receiving the journal must not exceed 2.5 seconds from the time request
is sent till the time journal is received.
Page 3 of 73
2. System Architecture
2.1 Global Analysis
2.1.1 Product Factors Factor Table
Product Factor Changeability / Flexibility Impact

P1: Functional Features
P1.1: Access to system
Users access the system is from variety New devices may be added in the This feature affects system in finding
of different devices like thin clients , system in later years. ways to support different types of
hand held computers etc. devices for access to the information.
P1.2: Concurrent access
It is possible for several persons present Number of users accessing a record can Access to a particular journal record is
at different locations access information be more than one at any given time. blocked when a user viewing that, it
at the same time. becomes unavailable for the other
users.
P1.3: Backward compatibility
The system has possibility to add Journals which may be added in the Entering the previous versions of the
digitized versions of previous paper- system can be in different formats and journals may cause the data to be saved
based journals. This enables backward different from our proposed format. in an unspecified way.
compatibility.
P1.4: Centralized servers
System is kept up to date and changes Servers will be present at different Updates are required on all the servers
made are updated as soon as they are geographical locations spread in the if any change is made on a given server.
saved on the server. These changes are country.
visible to other users of the system in
different hospitals.
P1.5: Version Management
Journals contain information about This feature is slightly flexible. This feature affects medical
ongoing and prior treatments. Version examination data storage, no rollback,
management system maintains the data and information systems security,
versions of previous and updated terminal data and internetwork.
journals.
P1.6: System security
The system supplier must be able to Data transferred to the systems on the This feature affects the system in
show that maximum security is network may be intercepted and used finding a mechanism to prevent theft of
achieved and that no unauthorized for malicious purposes. data from the network and from the
person can read journal data at any time server itself.
P1.7: Visual data
Images from X-ray, magnetic resonance Several other types of devices may be System should support not only the
imaging, ultra sound video clips, EKG added in the system in later years as the known test types and stores their output
graphics, etc. can be stored as part of new devices are invented to support the data but it should also provide
Page 4 of 73
the journal data medical examination. mechanism to support additional
devices.
P2: User Interface
P2.1: Different types of users
Users of system are doctors, nurses, and Different kinds of user interfaces and Authentication system of the
the patient himself. privileges are present for the users. application should not allow the users
of less privileged user to view or
modify the settings of more privileged
user.
P2.2: Ease of Use
The users of the system are personnel Users of the system are non-technical User interface should be kept simple
working at hospitals and other health persons and do not possess good and easy to use. Preferably a graphical
care institutions. knowledge of computer usage. interface is provided.
P3: Performance
P3.1: Search Time
The typical search time for finding and With increasing records in the system Searching facility should be optimized
receiving a journal may not exceed 2,5 the searching time may increase. to support the future requirements.
seconds from the request is sent until
the complete journal is received.
P4: Dependability
P4.1: Communication breakdown
System survives communication Server present at some location may Damage caused by communication
breakdown. become unavailable because of breakdown should be kept to minimum
unavoidable circumstances. and for this some mechanism should be
developed.
P4.2: Power failure
System should survive power failure. Power failure may cause loss of data In case of power failure the system
and other useful information. should try to get all the information
from other server which was updated
while it was down.
P4.3: Availability
Each journal is available 365 days a There is no flexibility. This feature effects centralized
year, 24 hours day, 7 days a week. database.
Page 5 of 73
2.1.2 Developing Strategies: Issue Cards

Next step is to analyze these factors along with their changeability and flexibility and impact on the software architecture.
Then we identify issues caused and the influencing factors. Further we develop strategies for solving these issues and
discuss if we have any related strategies developed. These are covered in the form of issue cards.
Clients can connect to system with different type of hardware devices with different operating systems installed. These users
should be able to access the system. It is not possible to develop a separate back end for each type of user platform. Let us
consider the scenario.
Platform Independence for Clients

Only standard PCs, thin computers and handheld computers clients are supported. Services are not provided for other
clients.
Influencing Factors
P1.1 Services are provided for selected clients machines.
Solutions
Use web application to make server side support platform independent for clients. Clients from any platform can access
journals through their web browser.
Strategy: Provide web applications support

Use web application support. Journals are available into the web browser, they do not need any third part software or
specific hardware machine for connectivity.
Related Strategies
No related strategies have been developed.
Users access to same journals concurrently. If this is read only then users do not have any problem. But if multiple users try
to access same journal with editing preferences then it becomes a problem. Such scenarios need to be solved. Similarly,
there can be a problem getting the update on the on a client machine whenever a user has updated patient information. Let
us consider issue card for this issue.
Concurrent Access to Single Journal

Whenever multiple users type to access journal that belongs to single patient, this becomes a problem. Two problems
originate in this case. First one is, when one user is editing a journal, others are viewing. Second one, when multiple users
try to access same journal in edit mode.
Influencing Factors
P1.2 Multiple clients request same journal at a same time.
P4.1 Network failure will stop the transfer.
Solutions
Use locking mechanism for locking edit controls for single journal, whenever one user has entered edit mode. Also, use
Ajax mechanism for bringing updates on client machines.
Strategy: Use Ajax

Ajax is used for web applications. This enables clients to view updated information without having their screens refreshed.
Updates are brought automatically whenever any user edits some patient information.
Related Strategies
If there is one server for all hospitals it becomes a mess. It is very difficult for a server to handle all requests locally, and
remotely. Main problem arises when remote users access information. Not only network bandwidth is kept busy, but also
time find and search journal become increasingly high. There must be some phenomenon for solving this problem. Web
Page 6 of 73
server has capability of handling heavy traffic. The main server which become very busy and is required for completing the
operation is database server. It contains information of all patients in the form of raw data and journals. Let us consider this
problem in the form of an issue card.
Time to Receive Journal

Due to centralized database, response time for the remote users is very slow. If journals are located locally, users can
access them quickly, but if the journals are located on remote location when they are to be fetched from other hospital or
institution, there is a delayed response for the user.
Influencing Factors
P1.4 Time for journal to reach the client depends on the distance of centralized server from the requesting client.
P1.2 Multiple clients request same journal at a same time.
P4.1 Network failure will stop the transfer.
Solutions
Use distributed database with each server containing information about other databases. Database server does not have to
fetch complete remote journal in case of client request.
Strategy: Use distributed database

Use distributed database at each hospital or health care institution. Each database server contains data and information
about other remote database server. This not only frees network bandwidth with repeated requests sent over the network
but also a faster response time for client is achieved. Distributed database eradicates the need of data backup as redundant
data is kept by remote servers.
Related Strategies
On a couple of occasions servers are needed to be brought offline. The reasons can be for testing new software, performing
maintenance operations, or others. In such cases, server access becomes unavailable. Let us consider issue card for this
issue.
Maintenance Operations for Servers

Database servers at centralized locations may be brought offline for maintenance operations.
Influencing Factors
P1.4 Local servers are dedicated but still maintenance operations are required.
P4.3 Availability becomes a problem.
Solutions
One backup server is placed at each centralized location. This backup is brought up at the place of primary database server
whenever the server is brought offline.
Strategy: Use backup servers

There is a secondary database controller at each hospital or health care institution. This server continuously synchronizes
with the primary database server. Whenever primary server is not available, this server automatically steps up and becomes
primary controller. This also provides fault tolerance mechanism, as journals were to be fetched from remote distributed
database in case of local server unavailability. This mechanism keeps network bandwidth free.
Related Strategies
There is one related Strategies which is use distributed database.
Page 7 of 73
There is a possibility that space for database servers becomes insufficient. This possibility can be due to the reason that
distributed databases not only contain data for server itself, but also data about other health care institutions as replication
updates are brought. Let us consider issue card.
Physical Storage
Physical storage can be insufficient as data size can become very large. Each centralized server is connected to its
distributed database on remote location. Data of each centralized server is distributed to other servers. In this way data
size becomes huge. There should be physical storage available for storing such data.
Influencing Factors
P1.4 Complete data for a hospital or health care institution is at a centralized location.
Solutions
Place extra physical storage at each central location.
Strategy: Use extensive secondary physical memory

On the database servers, extra secondary memory is attached. The size of total memory available should be at least twice
as minimum storage requirements.
Related Strategies
There is one related Strategies which is time to receive journal.
Now let us consider data and information systems security. Access to confidential data must be secure. Unauthorized users
must not be allowed to access the system. Users from outside world may not be able to access any kind of information.
System should also be safe from hacker’s attacks.
Secure System for Web

Since the system contains the private information of the patients so the system must be secure and un-authorized access
should be prevented. The data transferred over the internet should not be vulnerable.
Influencing Factors
P1.1 Access to system
P1.5 System Security
P1.4 Centralized server
Solutions
We can use cryptography protocols for securing our data.
Strategy: Use secure sockets Layer

Secure Sockets Layer is commonly used for preventing and hiding the data from unauthorized persons over the internet
while it is transferred from one place to another. We can introduce this encryption inside the hospital as well as when the
data is transferred during the replication procedure.
Strategy: Use hardware authentication

Only registered hardware machines are provided access to the system. New devices must first be registered, and then they
should be able to access.
Related Strategies
There are no related strategies.
Page 8 of 73
2.1.3 Technology Factors Factor Table
Technology Factor Flexibility and Changeability Impact

T1: General Purpose Hardware
T1.1 Processors
A standard processor i.e. Intel Core Processor speed increases every year High performance processor will
Due 1.66 GHz for client is selected so if required high performance result in better response time.
whereas for Servers high throughput processor would be used.
processor is recommended i.e. Intel
Quad Core Processor 2.93 GHz.
T1.2 Network
Within the Hospital LAN would be Coaxial cable can be replaced with High speed communication and better
good enough where as for connecting Fiber Optic for better speed or it can response time
to multiple servers be upgraded to wireless network.
Internet through DSL connection is
used.
T1.3 Memory
For clients 512 MB RAM is good Clients RAM can be increased to 1 Better Response Time with a minimal
enough where as for Server 2 GB GB whereas Server RAM can be increase in cost
RAM would be enough. upgraded to 4 GB depending on
requirements
T1.4 Disk
For clients 80 GB Hard disk is Server HD can be increased to 2-3 TB More records can be maintained
selected where as for a Server RAID based on requirements
Level 5 with 1 TB (Terabyte) is
chosen
T2: Domain Specific Hardware
T2.1 Probe Hardware
Scanner and Printers are used to scan New devices may be added. More maintainability issues for
and print X-Rays etc. Also Digital devices.
Cameras to make movies and photos.
T2.2 Probe Network
Network is based on distributed Network operations center equipment
database servers located
geographically at different locations.
T3: Software Technology
T3.1: Operating System
Unix is used as server for Main server Client operating system can be More stability and scalability
application while a window XP is upgraded to a better version of
used as Client Operating system. windows XP.
T3.2: User Interface
Web-based application is selected to Web site can be enhanced based on Better service and response time.
implement this system. user experience and feed back.
T3.3: Software Components
Application would use Oracle 10G Reporting tools and other tools which Better performance with little increase
server and Microsoft crystal reports implement Ajax can be replaced with in cost.
and Ajax and Telerik tools. better third party tools (COTS)
T3.4: Implementation Language
Implementation language would be Language can change. All dependencies may change.
PHP
T4: Architecture Technology
T4.1: Architecture Styles
Architecture style is similar to a web- Styles may change. All relevant details change.
Page 9 of 73
based database application.
T4.3: Domain Specific or reference architectures
Reference architecture is a web-based There is no flexibility. It is not possible to go to form based
application. application.
T5: Standards
T5.2: Database
Oracle 10g is selected as DBMS Database base can change. Platform dependencies also change
which include hardware, drivers and
other interoperable software.
T5.3: Data Formats
Data Formats are JPEG for images Other Formats of images like GIF and Better response time
and WMA for videos. Rest varchar video format like FLV can be used to
and nvarchar fields would be used for increase response time
text.
T5.4: Communication
LAN connection is there for local WAN service provider and service Better network speed can be achieved.
hospital or healthcare institution, and may change.
dedicated WAN connection is there
between different hospitals.
T5.5: Algorithm and Techniques
Application would be developed in Architecture pattern may change. Complete functionality changes.
layered architecture based on Object
Oriented programming techniques.
T5.6: Coding Conventions
Hungarian Notion is selected as
naming convention.
2.1.4 Developing Strategies: Issue Cards

Now we start analyzing technical factors, their changeability and impact on software architecture. Then we try to figure out
issues.
Availability and Usability

Since the system is always required by the user so it should be up and running all the time. It should also be easy to use as
the users of the system are not experienced computer users.
Influencing Factors
P4.1 Communication breakdown
P4.3 Power Failure
T5.4 Communication
T3.2 User Interface
Solutions
We can provide multiple replications of databases and web servers for availability and for usability we can use web
interfaces as most of the users are familiar with that
Strategy: Use Web based system

Web based system are normally available 24 hours a day and they are easy to use. In case if one server fails we can deploy
the system at several places and if one system fails user can use second available server over the internet.
Strategy: Make backup servers

Backup servers are available whenever the mains server goes offline.
Related Strategies
Related strategies are secure system for web, maintenance operations and platform independence for clients.
Page 10 of 73
2.2 Conceptual View
Three main activities that are involved in conceptual view are global analysis, central design tasks and final design task. Let
us go through each activity one by one.
2.2.1 Global Analysis

Let us analyze the issues and strategies developed for solving those issues so far.
Issue: Platform Independence for Clients

Strategy: Provide web application support
Issue: Concurrent Access to Single Journal
Strategy: Use locking mechanism
Strategy: Use Ajax
Issue: Time to Receive Journal
Issue: Maintenance Operations for Servers
Issue: Physical Storage
Issue: Secure System for Web
Strategy: Use secure socket layer
Issue: Availability and Usability
Strategy: Use web-based system
Now we continue with next activity which includes central design tasks.
2.2.2 Central Design Tasks
The Conceptual Configuration

On the basis of global analysis, we try to identify conceptual components. First activity that takes place is user
authentication and control. User gets authenticated, and then he request for operations to be performed. We categorize this
activity as single conceptual component named PresentationLogic. We say that end user authentication request comes in the
form of authentication request. When the user gets authenticated he gets user controls in the form of userControl. With these
controls he can perform operations, which he is authorized. Authorization is done on the basis of authentication.
Authentication and authorization involve interaction of other components, so they are explained later in this section.
Now, we assume that user is authenticated; now user performs a different operation which is the second major activity.
These operations can be different management tasks like create a new patient journal, make an appointment, initial medical
checkup, detailed medical examination, tests, operations etc. We categorize this activity as single conceptual component
called BusinessLogic. As the application web based, this component is placed on an external entity which is a web server.
Web server acts as a container for this component. Display can be sent directory to user screens.
All management activities taking place in the conceptual component needs data access for the completion of their tasks, as
journals other records are kept in a data repository. Data repository is a database containing data. We categorize this
conceptual component which facilitates communication with database as Data. Management requests and receives data from
database through this component. As database used is a distributed database [10], it communicates with other distributed
peers across the network. Database needs to be configured and maintained. These operations are performed by a third party
Distributed Database Management System (DDBMS). Data communication between databases takes place in wide area
network, as this communication is between different hospitals and health care institutions. This network also needs to be
configured and maintained. These operations are performed by a third party Network Operations Center (NOC). We
categorize this activity as data logic.
When user gets authenticated and is authorized to perform various operations. In this case there are two types of users. One
Page 11 of 73
type of users like administrative staff and nurses are allowed to view the journals only. Some of data for journals is changed
like appointments are added etc. but these changes are managed by system and maintained separately than other sensitive
data. Users like medical doctors have privileges to edit patient information. For this operation editing privileges are
required. These are second kind of users. Third kinds of users are administrative users. There users are allowed to perform
administrative tasks. These users have all privileges.
Page 12 of 73
Now let us consider initial high level architecture as mentioned in figure 1. Users send operations request through their web
controls available to them. These operations are sending at PresentationLogic component, which further forwards the
control to BusinessLogic component. BusinessLogic component is the place where actual activity is takes place. Request
data is send by BusinessLogic component to PresentationLogic to complete operations. BusinessLogic component is
responsible for complete management of the activity. Now, we wonder where does the data come from which is handled by
BusinessLogic. This data comes from the database logic component. This component contains the communications
mechanism with the database. The three categorized activities are recognized as components and represented in initial high
level architecture in Figure 1.
:Health R Us
userOperation :PresentationLogic
sender
businessControl
receiver
:Control
:Control
sender
receiver
presentationControl
webServer :BusinessLogic
rawDataIn displayDataOut
dest
:Data userDisplay
:Data
displayDataIn
source
rawDataOut
dDBMS :DatabaseLogic
NOC
Figure 1. Initial High Level Architecture
Page 13 of 73
In the next step we start decomposing these components. This will give the granular details of the process and activities
taking place. These activities are further categorized as components.
:Hospital R Us
receiver :PresentationLogic
:Control
sender
userOperation :JournalControl :ReportControl
:Authentication
sender Manager Manager
receiver
source
receiver
:Control
:Control
:Data
sender
dest
sender
`
:BusinessLogic
sender receiver source dest

webServer :Security
:Control :JournalManager :Data :ReportManager
Manager
receiver
dest
source
dest
source dest
userDisplay
:Data
:Data
:Data
:Data
source
source
dest
:DataLogic
:Database
dDBMS Manipulator
NOC
Figure 2. Refined High Level Architecture
First of all user authentication is required. User sends authentication request. The request is handled by Authentication
component. The request login information goes to BusinessLogic component for further processing. SecurityManager
component of BusinessLogic handles authentication. It further communicates with the data logic component. Data logic
component has DataManipulator which directly communicates with database. If login information is found in the database,
access is granted to the user. DatabaseManipulator component send user identification information to journal manager or
report manager component. Report Manager component deals with read only access to journals, where as JournalManager
component deals with edit mode access to journals. Control is transferred according to default privileges for user. Further
from BusinessLogic component, control is further transferred to JournalControlManager or ReportControlManager. These
components are responsible for complete journal management activities. Data is fetched from database through
DatabaseManipulator component, whereas these components communicate with DatabaseManipulator.
Page 14 of 73
PresentationLogic Component
The PresentationLogic component is responsible for the interaction with the user. This component consists of user controls
and operations. Display is available to the user and he can perform different operations with the help of controls available to
him. Figure3 demonstrates decomposition of PresentationLogic.
Figure 3. PresentationLogic
The three main components of the PresentationLogic are: Authentication, JournalControlManager and
ReportControlManager.
The main task of Authentication component is to allow the user to log in to the system and to create new account. It also
provides the user functionality of recovering the lost password. Since the system must be made secure and unauthorized
access is prevented this only provides the representation part of the security system which is present in the lower
component. When user gets authenticated he is granted access to JournalControl Manager. With the help of this component
user can perform operations which deals with journals access. JournalControlManager is responsible for handling the
journals and their build up. Build up includes the setting up user details and details of initial check up of user. This portion is
strictly for the Doctors or for the administrators of the system. Doctors can view and edit the details of the users whose
record is present in the system. The main responsibility of ReportControlManager is to show the journals to the users or to
the nurses. This does not allow anyone to edit the journal or different types of reports present in the system. A patient or
some other user can search the records of a patient's journal.
Authentication Component
Authentication component has the following architecture composed of three components as shown in the diagram.
Figure 4. Authentication component
Page 15 of 73
User login activity is demonstrated in the figure.
Figure 5. Login Component
Page 16 of 73
JournalControlManager Component
JournalControlManager is decomposed into two main components; these are accessible for the doctors only. Here the doctor
can initiate the initial check up of the user, as the doctor initiates the check up a journal is created for the user. This panel
also supports edit mode for the doctor to update the details of some previously existing user.
Figure 6. JournalControlManager Component
Find Journal component contains a component named View_data. It is meant for viewing journal.
View_data Component
Functionality of this component is demonstrated in figure.
Figure 7. View_data Component
Edit_initiate Component
Functionality of this component is demonstrated in the figure.
Figure 8. Edit_initiate Component

Page 17 of 73
ReportControlManager Component
ReportControlManager consists of functionality is the main component of this system where the nurses are able to search
the record of the user and also the previous versions can also be accessed by them. A ViewJournal component accepts the
input and then sends this input to the lower level components for fetching the search based results, the view component is
responsible for the viewing of data which was requested.
Figure 9. ReportControlManager Component
Search_Request Component
Figure 10. Search_Request Component
Page 18 of 73
View_data2 Component
Figure 11. View_data2 Component
Page 19 of 73
BusinessLogic Component
BusinessLogic is the brain of the system. The main tasks are performed here and its main components are SecurityManager,
JournalManager and ReportManager as shown in figure 6.
Figure 12. BusinessLogic Component
User login information is send to DataLogic component, for authentication. When user is authenticated successfully, user
role is determined which can be doctor, nurse administrative staff etc, is sent to SecurityManager component
SecurityManager component transfers control to JournalManager of ReportManager component along with the user role
information. JournalManager and ReportManager are components where the complete activity takes place.
SecurityManager Component
SecurityManager has two main components, the AuthenticationManager, Privilege Manager and AccountsManager
component. The AuthenticationManager is responsible for granting authentication of a user based on his user name and
password. When a user logged in successfully a session ID is provided to the client and based on that session ID the user is
authenticated to use any service. User access is provided on the basis of PrivilegeManager component which fetches
privileges of the user with unique userId. With these privileges user is authorized to perform operation on the system. The
AccountManager is responsible for the process of new account creation and also checks the validity of the user data in case
of the password forget. Information is provided to these components from PresentationLogic component whereas data is
fetched through DataLogic component.
loginInfoIn userPrivilegeDaaOut accountInfoIn
:SecurityManager
source dest
:Authentication :Privilege :Accounts
Manager :userId Manager Manager
loginDataOut
userPrivilegesDataIn accountInfoDataOut
Figure 13. Security Manager Component
AuthenticationManager further contains a component named Authentication. It deals with complete authentication activity.
This component consists of Authentication information for the user. It is further consists of granular components. These are
Page 20 of 73
Authentication, F_pass and New_Acc. The component Authentication is responsible for getting the user name and password
from the user and then sending this to the lower level components for authentication and other security checks based on his
input a message is displayed to him. Second component is F_pass provides the functionality on the user to recover
password. Here the user of the system is able to reset his password based on some security questions related to the user. The
third component New_Acc is responsible for creating new account for the new users. The account creation requires some
permission which is checked in the security manager component placed below.
Figure 14. Authentication
. Other activities recovery for forgotten password and creating new account demonstrated below.
Figure 15. F_Pass Component
New account creation in AccountsManager is demonstrated in the figure below:
Figure 16. New_Acc Component

Page 21 of 73
JournalManager Component
JournalManager can be categorized as heart or brain of the system, it is hard to decide between two, heart is a better choice.
This component has there chambers or subcomponents. First one is initial checkup; this component receives user
information, and deals with initial checkup of the user. Initial checkup is done normal medical doctor. Doctor examines the
patient and performs the diagnosis. Patient record is saved in the form of journal. If patients require detailed medical
examination, he is referred to specialist. Detailed checkup is handled by the specialist and the activity is performed by
Prescription component. Specialist performs detailed examination of the patient, if he finds that patient needs some medical
examination, patient is further referred for medical examination. Tests component deals with the activity that takes place in
medical examination department. Medical examination staff performs the medical examination, and results send to
ReportControlManager component in the form of results. Specialist obtains that information with appropriate version
managed by ReportControlManager component. Then recommendations and results are saved to user journal through
DatabaseLogic component.
Figure 17. Journal Manager Component
Some of the sub modules are listed explained under.
InitialCheckup Component
Functionality of JournalManager is explained in figure.
Figure 18. InitialCheckup Component
Functionality of detailed checkup is also similar. Let us demonstrate how prescription is given.
Page 22 of 73
Prescription Component
Figure 19. Prescription Component
Tests Component
Figure 20. Tests Component
Tests component has capability of adding images, X-ray, ultra sound, and other image and video component storage into the
database. This data is embedded into the journals.
Page 23 of 73
ReportManager Component
ReportControlManager is the control of ReportManager component. Search is handled by Searching component. When
specific record is found, it is checked whether a report already exists in the database. Communication with database through
out is conducted through DataLogic component. Searching component sends reportId to Reporting component. If report
does not already exist in the database then it is generated here. If it already exists then existing report is fetched. Reports are
maintained in the form of different versions. Versions contain data with time stamps. Versioning component handles this
capability.
Figure 21. Report Manager Component

Detailed components are explained.
Searching Component
Functionality of the component of explained in the figure.
Figure 22. Searching Component
Report_fetch Component
Functionality of the component of explained in the figure. Report_fetch component has capability of adding digitized
version of paper based journals to the system. Scanner are connected to this component and digitized copies of journals can
be generated.
Page 24 of 73
Figure 23. Report_fetch Component
VersionManager Component
Functionality of the component of explained in the figure.
Figure 24. VersionManager Component
Page 25 of 73
Database Logic Component

The database logic contains all the components which are responsible for connecting with the database and over all
supervising operations of the database. This component is connected to database directly.
Figure 25. Database Logic Component
DatabaseManipulator Component
DatabaseManipulator component is responsible for interoperating with the database. It has four subcomponents; these
components are Search, Insert, Update and QueryManager. Search has searching phenomenon implementation, Insert deals
with data insertion, whereas update deals with data updating. QueryManager component has query implementations so that
other components can perform corresponding operation. Data to Search, Insert and Delete component comes through
dataPipe. Similary, data to QueryManager component goes through QueryPipe. Funtionality of datapipe is covered in next
section.
userLoginDataIn userPrivlegesDataOut journalRawDataIn journalRawDataOut reportRawDataIn
userAccountDataIn :DataManipulator
source
reportRawDataOut
dest
:dataPipe
source
dest
:Update
:Search :Insert
:QueryPipe
:Query
Manager
DBMS
Figure 26. Database Manipulator Component
Page 26 of 73
Search Component
Details of Search component is demonstrated in figure.
Figure 27. Search Component
Insert Component
Details of Insert component is demonstrated in figure.
Figure 28. Insert Component
Update Component
Details of Search component is demonstrated in figure.
Figure 29. Update Component

Page 27 of 73
Defining Protocols and Behavior

Communication between components DatabaseLogic and BusinessLogic is mentioned in figure 12. User login data is send
by the subcomponent SecurityManager of BusinessLogic on the port usreLoginDataOut. Data is send to data pipe dataPipe.
This pipe is connected to Search, Insert and update sub components of DataLogic component. These components receive
this data on port userLoginDataIn from dataPipe. Ports directly connected with each other must follow same protocol.
userLoginDataOut port of BusinessLogic and source role of dataPipe follow protocol rawData protocol. Similarly, dest role
of dataPipe and userLoginDataIn port of DatabaseLogic component follow rawData protocol. With the help of these
protocols, they can communicate with each other.
Figure 30. Protocols for BusinessLogic(SecurityManager) and DatabaseLogic(Insert,Update and Search)
Similarly, journalDataIn, journalDataOut, reportDataIn, reportDataOut, privilegesDataIn and privilegesDataOut follow

protocol supported by the corresponding roles of their connector.
Distributed DBMS
Distributed Database Management System (dDBMS) is a third party solution which is best suited for requirements. It is
responsible for maintaining the replication of data. On database server database scripts are executed, which automatically
update all the databases around the country or locality for the changes which occur in the system. Because of the
performance issues the decision was made to execute the script once each day. Backup component is responsible for the
local backup of the system. This backup is scheduled in this component to be taken every weekend just to increase the
performance of the system.
Network Operations Center

Network Operations Center (NOC) is also a third party solution which is used for connectivity between different hospitals
and healthcare institutions. NOC consists of hardware and software including fiber cables, routers, switches, network
servers, etc need for wide area connectivity. dDBMS uses NOC to connect to other hospitals.
2.2.3 Final Design Tasks: Resource Budgeting

In system specification, there is no budget explicitly specified for development task. But we assume that target is to use
minimal of resources to satisfy requirement specifications. There are not big tradeoffs which a needed to be made as they
are no constraints for development budgets. dDBMS and NOC which are necessarily need consume heavy budget apart
from software development.
Page 28 of 73
2.2.4 Design Summary for Hospital R Us Conceptual View
Design Decision Rationale

Error logging mechanism introduced. Strategy: Maintain an error log to keep track of errors.
Mainly for operational errors.
Error recovery mechanism introduced. Strategy: Recover from error state and keep the system
functional. This is for technical errors. Whenever technical
problems error, with software in addition to maintaining a
log, recovery mechanism is introduced to keep system
functional.
Decompose Hospital R Us into three main components, Introducing main components for each type of functionality.
which are PresentationLogic, Business Logic and
DatabaseLogic.
Keep journal management separate for report management.
Journal management deals with managing journals
completely, whereas report management deals with report
generation mechanism mainly.
Decompose PresentationLogic into smaller components Introducing granular functionality for the component that
which are Authentication, JournalControlManager and has direct user interaction controls.
ReportControl.
Decompose BusinessLogic component granular Decompose component into smaller components based on
components. These components are SecurityManager, functionality.
JournalManager and ReportManager.
Identify granular components for DatabaseLogic. Decompose component into smaller components with
different functionality.
Role based access allowed for users of the system. Users have privileges over the system based on their
designated roles.
Separate authentication, from accounts management. Enables security for system. Authentication has no
interference with components which are not required for the
operation.
Limit checkup and medical examination activities to Medical doctors use journal management with access to add
JournalManager component. information to user journals. Medical test management staffs
receive test request in the form of report through
ReportsManager and send test results to same component.
This maximizes information security.
Separate searching from reporting. ReportsManager is Maximizes efficiency. Reporting receives no more
decomposed into components Searching and Reporting. information than report or record id to perform operations.
Reports generation and maintenance mechanism is Encapsulate reporting functionality.
maintained by Reporting component.
Versioning is done for journals, in the form of versioning. These are kept with timestamps. Multiple copies of journals
Versions are maintained for generated reports. are maintained by database.
Decompose DatabaseLogic into granular components. Split components based on different functionality.
Split DatabaseManipulator into Search, Update, and Insert. Different functionality
Separate query management into a separate component Different functionality.
named QueryManager.
Page 29 of 73
2.3 Module View
2.3.1 Global Analysis for Module View
Let us analyze the issues and strategies developed for solving those issues so far.
Issue: Platform Independence for Clients

Strategy: Provide web application support
Issue: Concurrent Access to Single Journal
Strategy: Use locking mechanism
Strategy: Use Ajax
Issue: Time to Receive Journal
Issue: Maintenance Operations for Servers
Issue: Physical Storage
Issue: Secure System for Web
Strategy: Use secure socket layer
Issue: Availability and Usability
Strategy: Use web-based system
We are not able to come up with new issue so we continue with central design tasks.
2.3.2 Central Design Tasks: Layers and Modules
The central design task includes the definition of layers and modules. We have to declare our layers keeping in view the
conceptual view which we made in the previous section. We check the initial high level conceptual view and then map
it to our strategy “Provide web applications support”. For web applications we need to take care of user view and user
interaction with the system; we have to separate our representation part from the processing part. We again apply the
strategy of “Time to Receive Journal” and identified that we need to have separate layer for the database as well since it
plays a crucial part and connects to the database locally as well as remotely for managing the replicas. Our strategy
“Time to Receive Journal” binds us that to connect to the network we need to have a separate communication layer.
Here are our four layers:
1. Representation layer
2. Application Layer
3. Dbase Layer
4. Communication layer
Our Representation layer consists of components which interact with the user and based on the user’s request provide
services to him. There are three kinds of services the Representation Layer provides are to allow the user to log on to the
system(Login) , allow the doctors to develop the journal of a patient(Journal Control Panel) and allow the nurses to view
reports / journals of patients (Report Control Panel). The Application Layer is contains three sub-systems. To increase the
security we have “Security Manager” which contains all the modules which are responsible for securing the system from the
unauthorized access. The “Journal Manager” interacts with the representation layer sub-system “Journal Control Panel” and
manages all the details which doctor instructs the system to perform. The “Report Manager” interacts with the report
“Report Control Panel” and fetches all reports which are required by the user. These three sub systems also interact with
each other to perform their functionalities. Dbase layer contains the sub systems which are responsible for executing the
different queries on the database and also keeps the database up to date to perform the normal operations. This layer is
Page 30 of 73
influenced by the strategy “Use distributed database” and it has to notify other databases and keep record of other databases
present over the internet for replication purposes. Communication layer is formed because of the strategy “ Use backup
servers ”. This strategy requires us to provide a way of locating alternate server if our main nearby server is not available. It
contains two subsystems, the Secure sub-system is used for providing reliable way of data transfer over the internet and the
“Server” sub system is used to locate the nearest server over the network.
These layers are shown in the figures below:
Figure 31. Initial creation of layers based on conceptual view
After defining the layers and the sub systems present in them we need to go to the conceptual view and find out the
correspondence of these sub systems and the components of conceptual view.
Page 31 of 73
Defining the Modules for DatabaseManipulator

We can map the components, connectors, ports and roles defined in the conceptual view to the modules preset in our sub-
system. The conceptual diagram of the system is shown in the section 4 of this document. The table is shown below:
Page 32 of 73
Now when we have defined the modules and mapped the responsibilities of the components to the modules, we can have a
figure which shows the interaction of the modules among them. Note that we have drawn this diagram keeping in view the
conventions used and defined in the book's chapter of Module View.
Figure 32. Database Manipulator subsystems
Subsystem for database manipulator is shown in the figure 1.1. This sub-system has three modules namely Insert_M for
database insertion management and Update_M for updation management. Third Module is Searching_M, which performs
the searching function for the parameters it will receive from the interface QG_Sr_I.
Module Insert_M has two sub modules QG_in_M for query generation and it provides an interface QG_UP_I for the query
parameters and DB_OPO_M manages the query execution and provides an interface BDI_I for database query input.
Module Update_M has two sub modules QG_up which provides an interface QG_In_I for update query parameters, second
module is DB_op01_M which executes the query and provides the interface DB11_I.
Third module in the database manipulation sub-system is searching_M. It has two more sub-modules. First one is QG_Sr
which generates the query for searching and accepts parameters through QG_Sr_I Interface. Second module in the sub-
system is DB_op00_M which manages the query execution and accepts the query through BD_11_I interface.
Page 33 of 73
Defining the Modules for Journal Manager Subsystem

Page 34 of 73
Figure 33. Journal Manager Subsystem
Journal Manager Subsystem has three modules Initial_chk_M for initial checkup, Pres_M for Prescription and Tests_M for
Tests details. Initial check up module has four sub modules New_form_M for entering new journal record which then
checks the previous records of the customer through Rec_Rq_M Record Request Module so find out whether patient has
any previous record or not. Req_Rq_M then refers the request to Pre_D_M previous data module and if there is any relevant
record it fetches from the database using DB_op31_M module.
Second module which exists in the Journal Manager Subsystem is Pres_M for Prescription of medicines and tests.
Prescription module also has Pres_Rec_M module for previous prescriptions record handling and it provides an interface
Pres_Rec_I for this purpose. Test_Pre_M module handles the tests prescription. Similarly there is module Gen_Pre_M
inside the subsystem for general medicine information and coordinates with Db_op32_M for data management.
The third module which we have in the subsystem is Tests_M which has two modules Test_D_M and Hardware_M.
Test_D_M provides an interface Test_D_I for providing information regarding the tests. Similarly Hardware_M module
provides information about the particular hard used in the test and information about it through Hardware_I interface.
Page 35 of 73
Defining the Modules for Journal Control Manager Subsystem

system. The conceptual diagram of the system is shown in the section 4 of this document.
The table is shown below:
Page 36 of 73
Figure 34. Journal Control Panel subsystems
Journal control panel subsystem is an interface for journal manager basically. It has two modules View_Data_M and
Edit_Initiate_M. These two modules respectively handle data view and data edit operations as their name suggests.
Veiw_data_M has two sub modules Grid_M and Req_R_M. Grid_M displays the data grid and provides an interface Grid_I
for data display request. Second sub module is Req_R_M which is basically receives the request for displaying data. It also
communicates with Interact_M module for displaying the data in edit mode. Also we have two other module in
Edit_Initiate_M module i.e. Edit_pg_M for editing a journal and New_JrPg_M for initiating and entering a new Journal
Page.
Page 37 of 73
Defining the Modules for Login Subsystem

Page 38 of 73
Figure 35. Login subsystems
Login subsystem has three modules Login for handling purpose and F_Pass_M for forgot password and retrieving it and last
one is NewAc_M which manages the new account. Now lets a closer look inside the Login module.
Login Module has three sub-modules up_ge_M for logging in and then it sends the User name and password to Validator
which check the authenticity of User name and password and provides this facility through Valid_I interface. If a user has
forgot password then that request is forwarded to F_Pass_M module and inside it Fpas_p_M module handles and after
resetting it send it to Validator2 module which authenticates whether user who is requesting password is valid if yes then
send password to his/her email account.
In case if the User is new and wants to sign up for a new account then his request is forwarded to NewAc_M module within
which NewAcc_p_M module creates new account and sends it for authentication of data to Ckh_D_M module. Chk_D_M
modules provide data authentication service through Chk_I interface.
Page 39 of 73
Defining the Modules for Security Manager Subsystem

Page 40 of 73
Figure 36. Security Manager Subsystems
Security Manager Subsystem has two modules Authentication Manager, Authentication_M and Account Manager
Accnt_Mang_M. Authentication Manager has three sub modules chk_rq_M for handling the authentication requests. If a
session ID is supposed to be generated then request is forwarded to SID_gen_M module and if a current session ID is
suppose to be checked then request is sent to SID_ch_M module. The fourth module is db_Op7_M handles the database
operations.
Account Manager Module, Accnt_Mang_M has three sub modules Accnt_chk_M, Account checking Manager and
Password Generator Check Module, pass_gen_chk_M. Account Check manager sends the data to db_Op6_M for checking
the data from database and uses the interface of Accn_I of Database operator. Password generator module generates the
password and sends the password to database for authentication to database operator using its Pass_I interface.
Page 41 of 73
Defining the Modules for Report Control Manager Subsystem

Page 42 of 73
Figure 37. Report Control Manager Subsystem
Report Control panel subsystem handles the Report control panel interface; it has two modules View Data Module,
Veiw_data2_M for viewing the reports and Search Request Module, Srch_frn_M for searching the information for report
generation.
View Data Module has two sub modules Grid_M for managing the data grid and Req_R_M for managing the requests for
report generation. Search_Req_M has also two modules UInteract_M for user control transfer and interaction and
srch_frn_M for searching particular detail records in the report and also for report generation.
Page 43 of 73
Defining the Modules for Report Manager Subsystem

Page 44 of 73
Figure 38. Report Manager Subsystem
Report Manager Subsystem handles the report generation; it has three modules Search Module search_M, Report_Fetch_M
module for fetching and generation of report and lastly Vj_M module for Version Management of journals while report
generation. Search_M, search module has three sub modules, QR_M, for Query Request which accepts the request for query
generation for search operation and forward this request to QG_M module for Query Generation Module, which generates
the query. Query Request and Query Generation both module interacts with data base module, Db_op41_M.
Second Module is for fetching the report, Report_fetch_M which has further three modules RP_Rc_M for report request
and RP_Ge_M Module for Report Generation. Report request module receives the request for report generation and forward
it to Report generation module and finally the query is forwarded to database Module, Db_op42_M for report generation.
Third module is VJ_M, Version manager for journal. It manages different detail versions of journal while report generation.
It has two sub modules VG_Rc_M, for handling Version Management requests and VJ_Gen_M for generating versions for
journal.
Page 45 of 73
Figure 39. Layered representation of Subsystem (Zoom In for resolution)
Figure shows the layered diagram for modules view. The presentation layer has three subsystem login, report control
manager and journal control panel. Presentation layer handles the user interface for user. Second layer is Business layer
which controls the business logic of the whole system, it has subsystems like Security manager, journal manager and report
manager.
The third and fourth layer is respectively Database and Network. Database has subsystems like replication manager and data
manipulation manager. Database layer is responsible for replication of back up server and peer servers and data
manipulation. Fourth layer is Network layer which has sub system like Secure and Server. Secure provides different
encryption facilities through SSL (Secure Socket Layer protocol) and transport layer. Network layer also has Server
subsystem which has two sub modules i.e. Web Server and Alternate. Web Server modules manages the issues related to
web server and Alternate sub module handles the data when local database server is down, it re-directs the data request to
the peer servers.
Page 46 of 73
Final Layer Diagram showing the dependencies between the layers

Similarly we can define the sub systems present in different layers and map them to the conceptual elements. This will gives
us the over all picture of the module view of our application. The final layer diagram is shown below:
Figure 40. Layered representation of Subsystem
Page 47 of 73
2.4 Execution Architecture View

We start our design view by first considering the global analysis and then moving to the central design task. In the central
design task we have divided the design into Communication Protocols, Defining the processes, and then the resource
allocation procedure. The overall interaction diagram showing all the processes which are taking place on our system is also
given at the end.

Before designing of execution view, we have to consider the following issues. These issues play a vital influential role in the
execution view of the system.
The main issues which we have to consider during the execution view are :
ISSUE: System response time increases with increase in request
Strategy: Modularize and divide the processes in such a way that concurrent requests can be handled at the same
time.
ISSUE: Data while transferred from one place to another is not captured by someone.
Strategy: Use SSL encryption for the data transferred.
Strategy: Separate client side from the server side.
ISSUE: Maintenance Operations for server
Strategy: Use a back up server or alternate server process
Our next phase is to develop mechanisms to accommodate these strategies in our design. For the first strategy we will divide
the system into large number of small processes which can run concurrently on the system to facilitate large number of
clients at the same time. Our design already has distributed databases present which are spread in different geographical
areas. For the next strategy we are using secure mechanisms of transfer and the browsers used by the client supports SSL
encryption and these things are dealt by the browser by default. In case our web server or the database went down we have
other servers present at different locations which can accommodate these maintenance operations of servers.
2.4.2 Central Design Task
Defining Runtime Entities

Our system is a web base system. It is driven by the input which is received from the client. There are at times many clients
accessing the system for different purposes. We divided our system into different logics in order to share the load among
different components of the system. Firstly, we need to identify the run time entities which are important for our design. The
entities which we identified are
● Web-server
● Database
● Our-own-Software
The interaction among these entities is key in order for the system to behave according to the requirements. We will
consider the interaction between the web-server and our own system first. Our software is deployed on the web server; each
request which comes for our software is through the web server. The database resides on the same system where our
software is deployed and the interaction between both is through simple IPC.
The presentation layer of our architecture is used by the client for interacting with the system. The requests which originate
from the client are handled by the presentation layer modules. This request is then transferred through Hyper Text Transfer
Protocol to the web-server where it is handled by the respected module of business layer. This request when transferred
from client side is encrypted using encryption technique and handled by the browser for decryption of the request. A simple
view of the above description is shown here:
Page 48 of 73
Figure 41. Client and Server interaction for request processing
Our system involves several modules which are spread in different layers. But these modules (present in different layers)
interact with each other to perform certain tasks. We will consider the example of login system which uses the services of
Authentication Module for authorizing any user to use the system. Moreover, the modules are spread over different
machines as well, since login module and authentication module are on client and server side respectively. So we need to
describe the client server communication path.
Communication Paths
This system is spread over a network. Communication path uses SSL for secure communication over the internet. This
methodology is commonly used over the internet for the safe transfer of data among different computers present at different
places. This will secure the system from any kind of data sniffing as the packets of data which are transferred are encrypted
and cannot be decrypted by any sniffers. Communication between the processes inside our software architecture takes place
through standard mechanisms of IPC. The messages or data which is to be transferred between the pages is sent by IPC. The
communication which can take place between the client and server is shown as:
Figure 42. Interaction between client and server

Page 49 of 73
Defining Processes
Our next step is to define the processes and the modules which are present in the processes. Firstly we will consider the
client side; it contains a separate process which is taking place in the client browser. This process involves client interacting
with the system for the authentication and for this he has to enter some detail in the login module or the client wants a new
account. All initial activities of client are mapped into process shown as in this diagram.
Figure 43. Login-Process
Client request is received by the web server and based on the request it is transferred to the required module present on the
server side. Here the processes are divided into logically so that no extra process is executed when some request is received.
AuthProcess is separate from the AccntProc since these two are not required at the same time. Either the client wants to
login or he wants some other activity like account creation or wants to recover his password. Web server is an independent
entity and runs on its own, the interaction between our system and the web server takes place through Wserver process
which takes control of each kind of data transfer and the security of data.
Our next step is to define the processes which are taking place on the server. For this we go into the detail interaction of our
AuthProcess and AccntProc processes with the modules present in the database layer. These module are responsible for the
updating, inserting and searching. Since all these tasks are related to databases so we introduce them into one process called
DBProcess as shown in the figure below:
Page 50 of 73
Figure 44. Interaction of Database Processes and Authentication,Accnt Processes
Keeping in mind the similar interaction between the other modules present in the layers we have the following architecture
present in the software.
Page 51 of 73
Figure 45. ReportClient interacting with the system
Page 52 of 73
Figure 46. ReportClient and journalClient interacting with the system
When a client accesses the journal part he has couple of options available, either he can edit a previously entered journal or
he can start a new journal for a new patient. Since these two options rarely are used at the same time by the same client so
we can have them in one process called JournalClient . This processes runs on the client side browser and fetches the
required information from the initProce process. Similarly, we have a ReportClient which is used by the nurses or staff for
the puroposes of searching and viewing a record present in the database. We separated JournalClient rom the Reporclient as
these are rarely used by the same person. This will give us added benefit in the form of modularity and security of the
system.
Similar to the defining of the database interaction of login procedure, we have a similar interaction diagrams for the
database part of other processes as well. This is shown in the diagram.
Page 53 of 73
Figure 48. Interaction of Database Processes with other processes
We have defined all the processes and shown their individual figures for the describing the processes involved in this
architecture. Next phase of our design was to come up with the overall diagram of the system where we can see the system
as a whole and can see the overall interaction of processes. This will help us to develop understanding of overall system
interaction and how the multiplicity of the processes takes place in our system. This diagram is shown on the next page.
Page 54 of 73
Figure 49. Complete Process interactions
Page 55 of 73
Resource Allocation
Our main resources include the database and the processor. We have one databases and one processor present for all the
requests. For our system we have to schedule our requests so that the resources are used in a proper manner. We now
consider two of our main functionalities for the resource allocation.
Our final design task is assigning resources to the processes. In our case there are two major functions which our system
perform, the first one includes the doctors work which includes log in by the doctor, perform some action and then each
action is saved in the database. Hence there is a databases interaction, first the request is allowed inside the system where
based on the verification by the database it is transferred to the next levels. On each level it uses the processor and at some
level it uses the Database. This is shown in the diagram below:
Figure 50. Interaction diagram of JournalClient Process
Our next explanation is about the ReportClient Process, this process is commonly used by the staff. This also requires
interaction with the database and also uses processor for the computation part of its interaction with the system. This
interaction is shown in the diagram below:
Page 56 of 73
Figure 51. Process Interaction Sequence
2.4.4 Design Summary for Execution View
Page 57 of 73
3. Evaluation
Architecture is complete till execution view using Christine Hofmeister [1] approach for developing software
architecture. The next activity is to evaluate the architecture developed, to identify loopholes and defects. Further we
need to validate that system developed meets system requirements. The very first step which is needed to be taken is
selecting an evaluation method. For that we must choose the right evaluation method suited for this scenario.
Let us check the evaluation methods which are available. We need to map our quality requirements to these evaluation
methods. Quality requirements against which we need to evaluation the system are increased data size, network
scalability, reliability, dependability, confidentiality, information security, availability and performance as mentioned in
section 1.1 of this report.
3.1 Chosen Evaluation Method and Motivations

First we determine quality requirements for the system. There are two basic types of requirements as categorized by Jan
Bosch & Peter Molin [8]. These are development quality requirements and operational quality requirements.
Development quality requirements are related to software development activities from software engineering
perspective. These requirements include maintainability, reusability, flexibility and demonstrability. Operational quality
recruitments are concerned with operations of the system. These qualities include performance, reliability, and
robustness etc. Requirements for this system are mainly operational quality requirements. [3]
Now let us consider types of evaluation methods available and check for suitability. There basic types of evaluation
methods available are experience-based, simulation-based, mathematical modeling and scenario-based. Experience-
based method involves experienced software architects with prior experience of working with architectures. These
architects evaluate architecture with objective and logical reasoning. This kind of method can be used with any kind of
requirements. This method cannot be used in this scenario as architecture experts are not available. Scenario-based
methods are found useful for requirements like maintainability, reusability etc. which are development quality
requirements. Scenario-based methods are not found very useful for operational quality requirements. Scenario-based
methods like SAAM, ATAM, CBAM, ALMA etc [4] are not selected. Simulation is found very useful for operational
quality requirements like robustness, but it is a huge activity and requirements a large amount of resources. It becomes
a complete project to conduct simulation and many tools and techniques are required for performing simulation. Due to
the limitation of time and resources simulation cannot be selected for evaluation. Mathematical modeling is found
useful for determine operational quality attributes like reliability. Mathematical modeling requires complex algorithms
and models for determining quality attributes. They give numeric values for quality attributes. These attributes may not
match the practical scenario. But this method is not selected for evaluation due to limitation of time. The basic type of
evaluation methods is almost complete. Now we have to look for some other quality evaluation methods or we have to
choose one existing evaluation method. [3]
We found ABAS (Attribute-based Styles) as one of analysis techniques [5]. ABAS is based on SAAM, which is
scenario-based architecture evaluation. ABAS is proven to be very useful for analyzing quality attributes like reliability,
availability and performance [6]. These are operational quality attributes. ABAS fulfills other evaluation requirements
like evaluating dependability and information security. System can be evaluated in an elaborated manner. This method
involves architectural styles, reasoning framework and attribute specific models [6].
3.2 Problem Description

System maintains information about electronic journals. Journals are maintained for complete country Sweden.
Redundant data and information is kept at different hospitals and healthcare institutions. Distributed database servers
are placed at each station. We summarize basic quality problems.
Exponential increase in size of Journals: There can be an incredible increase in size of journals. Total number of
journals can be exceeding 9,000,000 which are more than population of Sweden. System must be able to support large
amount of data size.
Capability of Network Operations Center (NOC): Network operations center may have to handle at least 100
interconnected hospitals. Single hospitals can have 10 or more departments.
Page 58 of 73
Power and Network Failure: Power or communication failure can occur.
Erroneous Data Insertion: Some data which contains errors or is unnecessary can be inserted.
Personal Integrity Threat: Users may try to access confidential information of patients.
Unauthorized Access: Some users may try to get access more than granted to them. Some users may get access to
unnecessary information.
All time Access: System can crash. Systems may be needed to bring offline for maintenance and other operations.
Time taken from Search till reception of Journal: users may have to wait for long time since the time of request till
they receive journals.
3.3 Quality Attribute Measure

Now we need to defined quality attributes for Health R Us ABAS. Identified quality attributes are:
Data Size: Data size includes size of data kept on servers and on database. Data size is measured in the form of mega
bytes, giga bytes or terra bytes.
Bandwidth: Bandwidth includes bandwidth of internal local area network as well as wide area network which includes
network operations center connectivity. As local area network bandwidth is proven to be satisfactory, we mainly focus
on bandwidth maintained between network operations centers of different hospitals.
Dependability: System can be dependable if it is able to survive both power and communication breakdown failure.
Reliability: This attributes is concerned with whether system performs error free operations. It can include faults
detectable, errors, exceptions and other erroneous problems.
Confidentiality: Confidentiality is about personal integrity and personal information kept at the system.
Security: Security is about remedial of threat to secure system information and data. This is mainly concerned with
unauthorized access of resources.
Availability: Availability is measured here in terms of Mean Time to Failure (MTTF) is the percentage the system is
comes offline in comparison with the time it is online.
Response Time: Response time is time taken from searching till time to receive data or journal. This is regardless of
whether data or journal is placed locally or remotely.
Stimuli for Health R Us ABAS are

Active Stimuli: Maintenance operation, load balancing, communication service, database, replication and updates.
Failure Stimuli: Data inserted into the system, network traffic, heavy load, communication services including WAN
service provider and web access to system.
3.4 Architectural Style

Architectural styles are used for reliability and dependability. Redundancy in styles is used to ensure that system
performs operations with stability. Some redundancy mechanism is used. Whenever query is sent one server, and it does
not respond, user is redirected to another web server on remote location. Similarly distributed database maintains
replication of other databases. In case if local server does not respond, user is redirected to remote server. Similarly
there can be some additional styles for error recovery and faster response time.
3.5 Quality Attribute Parameters

Parameters for quality attributes are:
Web Interface: User enters information through the web interface available to them.
Network Interface and Servers: Network interfaces, web server and database servers are responsible for any
information and data that flows over the network.
As we are using ABAS as an analysis tool rather than architecture development style, we do not mention redundancy
for servers and information, repeatedly in this evaluation process.
3.6 Analysis
Now let us demonstrate each quality scenario one by one and check whether system has capability of solving the
problem. Approach used is modeling system scenario into a model. Custom developed model is used in this evaluation.
Page 59 of 73
The model is adopted from Markov Models [6]. Let us consider each quality attribute one by one and visualize the
system capability in the form of model. Model consists of three states. First is running, in which system is working
perfectly. Second state is critical state. In this state, failure has occurred but system recovers from this state and goes
back to running state. Third state is dangerous state; this state is achieved, when system again has a failure when it is in
critical state.
Figure 52. Analysis Model for Hospital R Us
Now let us apply this model for the quality requirements. If data size grows to be very large, system does not do even to
critical state. Hard drives provided to the database servers and other server systems are sufficient. No additional space
is required. System has capability of handling ninety hundred thousand journals with each journal of size variable from
five megabyte to fifty megabyte.
Now let us consider the case when heavy traffic flows over the network. Traffic can be within the healthcare institution
of between two different healthcare institutions. Bandwidth is sufficient for communication. There is no need for
reserving additional bandwidth for data transfer. System does not go to even critical state, in case of even heavy traffic.
In case of power failure, uninterrupted power supplies are there, but in case of network communication breakdown,
system goes to critical state. System may recover from this state, when the network problem is solved. System may
come to dangerous state if network link is down more than one time. Some additional networks may be needed to keep
communication active in case of network failure.
If any changes are done with the journal data, patient journal data is updated for users with journal currently open,
without refreshing the screen by implementation of Ajax. Due to this functionality system does not go critical state and
if it does, it has capability of recovery, in case if update is a fraction slow.
There is a mechanism in the system for error and faults. It is accomplished with error recovery and logging mechanism.
If some error occurs in the system, system goes to critical state. System has capability to recover from this state and get
back to running state. If error occurs again in critical state then system enter into dangerous state. There is still a
phenomenon to recover from dangerous state but in that case system can face crash or erroneous data may be inserted
into the system. System tolerates faults and failures in operations but there is no phenomenon for automatic error
recovery.
Doctors and nurses are able to see personal information of patients. This is subject to confidentiality and personal
integrity. In this case they view information, system goes to critical state. In case if they edit information, like change in
address or other information, then system goes to dangerous state. There should be some mechanism, which at least
shows alerts and Swedish laws and regulations whenever any user tries to access such information. When information
editing is done system goes back from dangerous to error state. But previous information can be lost. But in such case
version manager maintains previous information, in the form of previous version. If wrong information is entered,
system can maintain its state or recover and go back to running state.
Web server is running on secure socket layer. Users from outside the system are automatically denied access. In this
case with outside attempts unauthorized users are automatically denied access. Users within the hospital or healthcare
institution are granted access on the basis of certificates. Differentiation between local and remote certificates is not
clearly elaborated i.e. whether users from other hospitals or healthcares institutions have same certificate, if they have
then this security violation must be handled, as system goes into critical state but there is no phenomenon to getting
back to running state. System may remain in critical or dangerous state.
Page 60 of 73
Sometimes web server can crash, database server can also crash. Then system enters critical state. There must be a
phenomenon to recovers from such a state. If local server fails, system goes back to running state, contacting remote
web server at closest hospital or healthcare institution. Similarly, if database server is down system web server fetches
data from remote database server. Still it recovers from critical state and comes back to running state. In case closest
server is also down, system goes to dangerous state, but still it can recover contacting next neighbor. Users suffer slow
communication in these cases. There can also be a need for bringing servers offline for maintenance operations. There
should be some redundant servers, or backup servers for faster response and being online in case if other servers are
offline locally.
3.7 Evaluation Results

Evaluation leads to results, which gives some measures for the steps to be taken to transform current architecture to
quality architecture.
Availability in Disk Space: There should be enough space available to take care of any increase in data size. Some
additional hard drivers should be placed with each database server. Availability of space should be there in terms of
terra bytes.
Reservation of Network Bandwidth for different processes: Some of the WAN network bandwidth may be reserved for
network operations like database synchronization and replication, remote request coming across the network in case of
local server failures etc. Data transmission can be limited on TCP ports to increase throughput.
Redundancy in Network Connection: Multiple WAN network connections should be available. Second network should
automatically be up, when first network is down. In case of network congestion and other network problems with one
network, NOC should automatically take use of other network available.
Error Control and Logging: Error control and logging mechanism should be properly introduced.
Alerts while Viewing Confidential Information: Proper alert messages should be displayed when user is viewing
confidential information of patients. User should be displayed Swedish Laws for personal integrity of patients.
Similarly, when user is editing sensitive information, he should be properly prompted and alerted.
Secure Socket Layer: There should be a mechanism of maintaining local and remote certificates separately.
Backups for Web Servers and Database Servers: Backups for web and database servers should be there. These servers
automatically come online in case of primary server unavailability.
4. Transformation
Evaluation leads to certain results. There results conclude that certain changes are to be brought in to the system. Some
changes are to be made in existing architecture, as well as some additional components are needed to be added to the
system. We have to follow a methodology to bring these changes. This activity is called transformation. For this
transformation there is a standard method that is followed. This includes imposing architectural styles, imposing
architectural patterns, applying design patterns and converting quality requirements into functionality. [3]
4.1 Imposing Architectural Styles

System already makes a layered architecture; implementation of layered approach is not required. Components are well
integrated in the form of client server architecture for Word Wide Web. Processes have been developed which
encapsulates similar functionalities. Hardware and software Resource utilization is efficient as explained in execution
view. Standard database is used. Database connectivity is fast, details are explained in distributed database section of
this report [10]. Pipelines are used for streaming and inter-process communication. Circuit switching is used for
avoiding network delays and congestion [11]. This kind of technique eliminates the possibility of slow network
response and delays due to heavy traffic. Multiple WAN networks are used with different service providers. Firewalls
are used at network operations centers to limit traffic related to different functionalities. Unauthorized access is blocked
through firewall. Web Wallet [12] is used for security; this kind of authentication reduces the need for multiple
certificates for external clients, as the communication across the network is safe. Web wallet makes authentication
process very secure. Unauthorized users are denied access in either case. This technique may not be used within a
healthcare institution or hospital. [9]
4.2 Imposing Architectural Patterns

Architectural pattern like Model View Controller (MVC) could be introduced [13]. But this is a tradeoff as enough
functionality has been implemented. Also the pattern formulated in this architecture is similar to Multitier and MVC.
This is a custom built architecture; there was not a necessity for using architectural styles like multitier or architectural
pattern like MVC. Tradeoff made here is that there is no necessity for any architectural pattern.
Page 61 of 73
4.3 Applying Design Patterns
No design patterns are applied at this stage.
4.4 Converting Quality Requirements to Functionality

Last step of architecture transformation is to convert quality requirements into functionality, if requirements have not
already been fulfilled. A separate component for error control is introduced explicitly. This component takes care of all
error that occurs during processing. Global analysis of this functionality was done but mechanism was not introduced in
the form of component of functionality. Components are introduced and functionality is implemented in modules.
Separate functionality is introduced for user whenever he enters some personal information of a patient. He is displayed
alert message while editing such information. Information backup is taken whenever user edits such information.
Similarly when he is viewing confidential information, dialog opens with Swedish Laws about personal security and
integrity. One backup server is placed for each web server, and one backup server for each database server. Incase
primary server is down, there is no need for user request to be sent across the network.
5. Second Evaluation
Second evaluation is done using same methodology. This evaluation is conducted to validate whether quality
requirements have been satisfied after transformations. It is done using same method that was used in first evaluation.
For this evaluation we have same problem statement, quality attribute measure, and architectural styles and attribute
parameters. Evaluation analysis is done which leads to conclusions.
5.1 Analysis
In case of requirement of additional disk space, system has additional hard drives places with large disk space like 1
terra byte etc. With no budget constraints this tradeoff is easily made and disks are placed. If system goes to critical or
dangerous state, it has capability of recovering automatically.
Network has bandwidth distributed into different pipelines for different operations and processes. Due to this reason
there is no network congestion problem. System does not go to critical state. In case if more network throughput is
required for specific processes, configuration can be changed. System may go to critical state but has capability of
recovering from it through network operations center. Different applications usage priority can be changed through
network firewall configuration. System has become fool proof in this aspect. It is capable of handling heavy network
traffic.
Additional network connection is present with different service provider. In case if network goes down system goes to
critical state but automatically recovers by switching to other network. Circuit switching supports better network path
determination. System automatically recovers from critical state and gets back to running state. In case if second
network goes down system switches to wireless network connection. Then system again recovers from dangerous state
and gets back to critical state.
Additional components for error control and recovery eliminates the problems occurring during operations. System
tolerates errors, they do not become faults. If any components produce errors system displays alert messages and
system gets back to running state from critical state. Operations may not be performing successfully, but errors are
logged and malfunctions are repaired.
Alerts are displayed for users while editing sensitive information and backups are taken before edit operations. Also,
while viewing personal information users are also informed about Swedish laws for personal integrity. Due to these
functionalities, system may go to critical state when users enters those states, but has capability of recovering old
information, from backups. User activities are logged whenever user performs such operations or view personal
information. With this activity logging, this can be ensured that user was viewing such information purposely.
Similarly, information and operations performed by user performing edit operation is also logged. These logs are view
by administrators.
Use of Web Wallet [12], which has recently implemented by facebook, youtube and many other web portals, ensures
that there is no security violation from outside the network. Network firewalls already blocks access for servers from
outside world as well as inside. But still there are threats for unwanted activity from World Wide Web. Such activities
are blocked using web wallet.
Page 62 of 73
Backups for web and database servers ensure availability of the system. Also user response time is not delayed even if
mains servers are offline.
5.2 Evaluation Results

Availability in Disk Space: Enough disk space is available.
Reservation of Network Bandwidth for different processes: Enough bandwidth available for every process.
Redundancy in Network Connection: Multiple networks available.
Error Control and Logging: Error control mechanism available.
Alerts while Viewing Confidential Information: Alerts are displayed, backup are taken and Swedish laws for personal
integrity displayed while viewing confidential personal information of patients.
Secure Socket Layer: Web Wallet [12] solves the problem.
Backups for Web Servers and Database Servers: Backup Server available.
6. Transformed System Architecture

After evaluation systems has been added with a couple of functionalities. There added functionalities are available in
this section.
6.1 Availability in Disk Space
Global Analysis
Physical Storage (cont.)

Physical storage requirements may become immensely large, such that there are multiple versions of same data, or
other redundant data.
Influencing Factors
P1.4 Complete data for a hospital or health care institution is at a centralized location.
Solutions
Place additional hard drivers with database servers.
Strategy: Place additional Hard drives.

These hard drives are places in addition to hard drives already placed with the servers.
Related Strategies
Physical storage.
There is no implementation of this in any view of the architecture, as hard drive is hardware component.
6.2 Network Bandwidth Reservation
Network Operations Center (cont.)

Firewalls are placed at each network operations center. These firewalls are configures to block undesired network
traffic. Also data transmission rate on each port is limited. Processes like database replication updates, remote queries,
and other network traffic is limited for data transmission over the network. This mechanism avoids network congestion
on the network and keeps bandwidth free for operations. Unnecessary ports are blocked for data transfer.
Page 63 of 73
6.3 Additional Network Connection
Network Operations Center (cont.)

Additional network connected is attached to network operations center for connection between hospitals. This network
is configured to automatically become active if primary network is down. A third slow speed wireless network is there
which become active in case of a disaster.
6.4 Error Control

This is the part of the software system. Let us start from global analysis.
Whenever an end user receives an error what should happen in such a scenario. In web user interface user is notified an
error message and control is transferred back to same state. But there must be a phenomenon to deal with such a state.
Let us consider this in the form of an issue card.
Error Control
If any kind error occurs in software. Errors are classified as operational errors and technical errors. Operational errors
occur due to some operational problems in the management system. Where as technical errors occur due to some
technical problems with the software.
Influencing Factors
P4.1 Communication breakdown
P4.3 Power Failure
T5.4 Communication
T3.2 User Interface
Solutions
Use error logging. Error logging contains categories of errors. These categories can vary from severe to minor.
Immediate actions must be taken for severe errors, considerations may be required for moderate errors, and minors
may be ignored.
Strategy: Use Error Logging

All kind of errors are maintained in the error log. Log contains complete details of about the error. Operational errors
are visible to end user in web interface, whereas technical errors log is also maintained but that is for software
improvement and maintenance.
Strategy: Use Error Recovery

Error recovery is a mechanism, to recover from error state automatically. This phenomenon is applied for technical
errors in software. In such errors software has capability to recover from error state and get back to operational state.
When user attempts same operation with technical errors three time, they operation is locked for the user, until
administrator enables that operation again.
Related Strategies
6.4.2 Conceptual View (cont.)
BusinessLogic Component (cont.)

This component is modified with additional error control component.
Page 64 of 73
Figure 53. BusinessLogic Component (cont.)
ErrorControlManager Component (cont.)

ErrorControlManager is automatically invoked by JournalManager and ReportManager whenever an error is
encountered. Error data is sent to Error Log component. This component logs error. Error recovery is the phenomenon
of transferring control back to the sender component.
Figure 54. ErrorControlManager Component
6.4.3 Module View (cont.)
Defining Modules for ErrorControlManager
Figure 55. ErrorControlManager_M Module
IErrorLog is connected to DataManipulator_M of module view. Whereas ineterface IError is to transfer control to error
recovery to transfer control back to where the error occurred.
Page 65 of 73
6.5 Alerts and Display of Private Information
Whenever private or personal information of patients is displayed to any user, this component is automatically invoked
to display Swedish laws for personal integrity. Similarly, if any user edits information of patients and that information is
related to personal information, this component is invoked automatically.
Alerts for Sensitive Data

When user tries to view personal data or some user edits personal information of a patient, there should be some
phenomenon for alert the user for sensitivity of information.
Influencing Factors
Solutions
User is displayed proper alerts and information about the sensitivity of the actions he is performing.
Strategy: Use alert messages

Alerts are displayed whenever user tries to access sensitive data of information.
Strategy: Display Swedish Laws relevant to personal integrity

Whenever user views personal and private information related to patient he is displayed alert and then Swedish laws
relevant to personal integrity.
Strategy: Perform data backup whenever user is in edit mode

Backup is taken for the current data which user is editing whenever user enters edit mode.
Related Strategies

This component is modified with additional error control component.

Page 66 of 73
Defining Modules for AlerterService
Calling Module
(ReportManager,
JournalManager)
ISensitiveInfo IPersonalData
SensitiveInfoAlert_M SwedishLawsAlert_M
Figure 57. ErrorControlManager_M Module
These modules are further connected to DataManipulator_M for fetching relevant data from the database.
6.6 Web Wallet

Let us consider see from global analysis why Web Wallet [12] has be implemented.
Certificates Handling for SSL

Web Server is running on secure socket layer. Users must have valid certificate for accessing web. Some of users get
access from outside hospital. Such users much be denied access.
Influencing Factors
P1.1 World Wide Web Access
P1.6 System Security
Solutions
Use Web Wallet for denying outside world access to system. Web wallet uses secure authentication phenomenon,
which is one level a head from https.
Strategy: Use web wallet

Web wallet secures users access, any unnecessary request are denied access to the system. Also authentication
becomes safer.
Related Strategies
Page 67 of 73
6.6.2 Implementation
Authentication Component (cont.)
Figure 58. Authentication Component (cont.)
Web wallet [12] is a third party component which is integrated into the system.
6.7 Backup Servers

One backup server is placed for each server and one backup server is placed for each web server. In case if database
server if offline or very busy, data is automatically retrieved from backup server. This backup server maintains updated
records through replication. There is a local backup web server at each hospital or healthcare institution. In case if web
server is down, users request is entertained locally. User request is given response instantly with no time, as WAN
connectivity is not involved for this operation.
7. Peer Evaluation
This is a BTH peer evaluation done by another group. Evaluation was done in an evaluation meeting. Meeting included
members from both teams. In the meeting high priority quality attributes were identified. Quality attributes were
prioritized. Tradeoffs were discussed. Quality requirements and system functionality were analyzed. Then meeting
came to some conclusions which are listed as:
User Roles and Privileges Customization: Some customization in user roles is needed. Some of the users may have to
perform operations in addition to their default privileges assigned to their roles.
Local Administrators: There is should be a super user who can perform all activities. He has complete privileges. This
user can remove problems related to version management and other tasks.
User Session Management: Users sessions must be maintained. Some additional activities like activity logging should
be there. This component maintains log of activities performed by each user.
Concurrency Control: There must be a mechanism for concurrency control. This control mechanism takes care of users
who try to perform edit operations on a journal which is already being edited.
Platform Support: System should be able to provide support for multiple platform clients; presentation interface should
be there which takes care of resolution and formatting for such clients.
Implement Multithreading: Multithreading can be implemented for managing multiple processes concurrently.
Faster Request Processing: Different techniques can be used for faster request processing.
Future Work: In future enhancements can be done like standardization, personalization, profiles management etc.
For detailed information please refer to Peer Evaluation report submitted by group 15.
NOTE: - This peer evaluation meeting took place before completion of internal evaluation. Many of the issues
discussed in the meeting, were already open in internal evaluation. Initial transformation already fixed those issues.
Transformation details are available in first transformation. That is also references in the next section.
Page 68 of 73
8. Transformation
8.1 Imposing Architectural Styles
Multithreading has been introduced for concurrency.
8.2 Imposing Architectural Patterns

No additional architectural patterns are felt necessary to be applied.
8.3 Applying Design Patterns

Design patterns are very useful for reusability and for leading to pattern oriented architecture [14]. Thread pooling is
implemented to support concurrency for processes [15]. Thread pooling enables multithreading or users connected to
network. By the use of this pattern resources are used optimally. Memory is utilized optimally and concurrency is
maximized by use of this process. If two users view same journal at time, there is no need to do processing for that
request.
8.4 Converting Quality Requirements to Functionality

User roles and privileges section is created. Users are assigned privileges on user basis in addition to their roles. Users
are able to perform operations which they are not authorized to perform by granting that privilege. If some users come
from outside hospital or healthcare institution they can be assigned custom privileges on journals and other resources.
Local administrators are explicitly added in each view. These administrators have complete privileges. They view user
logs and critical information, as well as they are involved in maintenance activities. Session management module is
optimized for removing possibility of multiple logins. Locking Mechanism is introduced. Whenever a user is editing
journal, it is locked for editing, until changes have been saved, and user exits edit mode. Multithreading has already
been introduced using thread pool pattern. Faster request processing has been accomplished during first transformation.
This is accomplished with local backup servers. There servers process request whenever server is overloaded. Load
sharing mechanism is introduced explicitly in this transformation. This architecture is flexible, and can easily be
enhanced with features like personal profiles for users, where users save their web settings, and customize their
interfaces. Generic functionality can be obtained by generalizing functionality and it can be transformed to make a
product. Policy management can also be introduced to enforce organizational limitations.
9. Transformed System Architecture

9.1 Roles, Privileges and Administration
We find a problem that user role information along with the privileges may be insufficient. User may have to perform
complicated operations. User rights may be needed to check whether he should perform medical test activity or not. He
should be authorized to perform tests operation only if he is properly trained for that. Now let us consider this in the
form of global analysis.
User based Access

Some of the users have extra privileges, which are addition to their roles. They must be authorized to perform these
operations. There role cannot be promoted.
Influencing Factors
P1.1 Users can access the system through any device
P1.6 Only authorized users should be granted access
Solutions
Make user based privileges apart from role based privileges. Users with additional access are granted access to the
resources.
Page 69 of 73
Strategy: Allow user based access

With user based access, user is checked for privileges for operation he is going to perform. These privileges may
differ from the privileges of their roles. These privileges may be mentioned while account creation, in addition to
their role.
Related Strategies
DataLogic component sends user authorization information along with unique user identification. On the basis of this
unique userId user authorization information can be obtained through DataLogic component. This authorization
information includes user role and privileges. Now JournalManager and ReportManager component can ask for user
role and privileges anytime. There is no possibility of assigning multiple roles to a single user. And also there is no
possibility of multiple privileges for a single resource.
With the help of these components users can be assigned any privileges. The easiest way to assign a temporary user
privileges is to assign him the role with minimum privileges, but grant him additional privileges. This section can
further be enhanced to completely customized users, roles and privileges along with policy manager, but requirements
do not demand such a system.
Defining Modules for PrivilegeManager
Figure 60. PrivilegeManager_M Module

Page 70 of 73
For roles privileges are granted by default. For users privileges can be granted. Users are allowed to perform operations
for which their role is not granted access, if they are granted privilege.
AccountsManager is managed totally by local administrators. Other users are not displayed accounts management
utility when they login. It deals with user accounts creation and removal along with assigning them roles and privileges.
Administrators have additional menus for solving problems for version management and other issues. They can view
the error logs and resolve issues with their web interface.
9.2 Session Management and Activity Logs
Session Management and Activity Logs

If multiple sessions are opened by a single user, there must be a phenomenon to deny second user the access. This is
only manageable with the session management activity that already exists. Also if user performs any sensitive
activity that should be logged with user information.
Influencing Factors
P1.6 Journal Editing done by users.
Solutions
Using existing components of session management allow only one session for a user. Use activity logging with
sensitive operations.
Strategy: Allow one session per user

Maximum of one concurrent session is allowed for a user.
Strategy: Maintain log for editing journal, view private personal information
Log activity whenever a user is alerted and performing sensitive operation. This log contains complete activity
description along with user information.
Related Strategies
Display Swedish Laws relevant to personal integrity and perform data backup whenever user is in edit mode.
Whenever AlerterService is invoked, user activity is logged. This automatically logs user activity whenever user tries is
reaching security boundaries. Administrators can check these logs. Administrators are automatically notified when
these logs are updated.
Defining Modules
Figure 61. UserActivityLogging_M Module
Page 71 of 73
9.3 Locking of Journals
Concurrent Edit Mode Access to Single Journal

Two or more users try to edit same journal at a same time. Sometimes, when a user is editing information in a
journal, another users attempts to edit same journal.
Influencing Factors
P1.6 Journal Editing done by users.
Solutions
Journal is locked for editing by other users whenever a user is performing edit operation.
Strategy: Locking of journal when edit operation is being performed

Whenever a journal is being editing other users are denied edit access with prompt information that it is already
being edited.
Related Strategies
Perform data backup whenever user is in edit mode.
9.3.2 Implementation
No additional implementation is required. A flag is maintained in the database for each journal. Whenever any user
opens that journal, its flag is checked. When this flag is checked no other user can perform edit operation. In such case
users is informed that journal is already in edit mode, he should try that operation at some later time.
9.4 Multithreading
Multithreading is achieved by design pattern usage.
9.5 Point and Click Performance

User is provided point and click response and journal is received earlier than 2.5 seconds since the time of request till
journal is received. This fast response is provided due to load balancing in primary and backup servers. Databases are
kept updated at every instance, with distributed database phenomenon. There is a secondary web server placed which
become active when main server is under heavy load. User is never sent over the network, to other healthcare
institution in case when server is down. User is entertained every time with prompt response.
10. Summary
Building architecture of Health ‘R’ Us, we have learnt a couple of things with our experiences. We found that design
method proposed by Hofmeister et al. is a flexible method for designing architectures for software. We were not able to
find any popularity of this method in enterprise architectures and we could not found any tools or language support for
the architectural notations and instrumentation used by Hofmeister. We can perform tradeoff analysis identifying
product specific and technology specific attributes (called factors by Hofmeister), that influence software architecture.
Problems solving approach, identifying issues and making strategies was a simplified way, to reduce gaps between
requirement and software architecture. Architectural views provide viewpoint analysis of architecture with different
aspects. Conceptual view reveals conceptual component specific architecture. Module view provides modularity and
layering into the architecture. Execution view gets close to machine leading to analysis and architecture design of
processes utilizing resources. Good quality using this approach is that it is easy to make design tradeoff analysis during
any phase, meeting functional and quality requirements. Architecture can be customized flexibly and molded to meet
the requirements at any phase. Evaluation techniques give idea of how to validate requirements fulfillments. At
evaluation stage normally it is understood that architecture already meets functional requirements and is ready to go for
quality evaluation. Transformation of architecture gives an approach, how to mold architecture to meet quality specific
requirements. Transformation may also involve additional construction of components, modules and processes.
Page 72 of 73
Transformed system architecture is validated again for quality satisfaction. Evaluation by third party or another peer
helps validate system, caching those system gaps from its quality requirements which could not be identified by
architecture development group internally. Transformed system architecture reveals a transformed architecture that
satisfies quality requirements.
11. References
[1] Applied Software Architecture by Christine Hofmeister, Robert Nord, Dilip Soni foreward by Cris Kobryn
[2] Software Architecture Evaluation Methods for Performance, Maintainability, Testability, and Portability, Michael
Mattsson, Håkan Grahn, and Frans Mårtensson, paper published by Institutionen för Datavetenskap och Ekonomi
(IDE), Blekinge Institute of Technology, P.O. Box 520, SE-372 25 Ronneby, Sweden.
[3] Software Architecture Design: Evaluation and Transformation, Jan Bosch & Peter Molin. Proceedings of the 1999
IEEE Engineering of Computer Based Systems Symposium (ECBS99), December 1999.
[4] Software Scenario-Based Software Architecture Evaluation Methods: An Overview, Prof. olstlaan, Department
Software Architectures, Philips Research, 4, 5656 AA Eindhoven, The Netherlands, MB, Eindhoven, Department
of Mathematics and Computing Science, Technical University Eindhoven, P.O. Box 513, Den Dolech 2, 5600, The
Netherlands.
[5] Architecture Styles. In Software Architecture, M.Klein, R.Kazman, L.Bass, J.Carriere, M.Barbacci, and H.Lipson,
AttributeBased, Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1), pages
225--243, San Antonio, TX, 1999. Vol. 140, ISBN:0-7923-8453-9
[6] Attribute-Based Architecture Styles, Mehrdad Guilani, Course: CSCI 210, Professor: Dr. A. Bellaachia,November
10th, 2004
[7] Attribute Based Architecture Styles. In Software Architecture, M.Klein, R.Kazman, L.Bass, J.Carriere, M.Barbacci,
and H.Lipson, Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1), pages 225--
243, San Antonio, TX, 1999.
[8] An Introduction to Hidden Markov Models, L.Rabiner, B.Juang, ASSP Magazine, IEEE, Publication Jan 1986,
Volume: 3, Issue: 1, Part 1, On page(s): 4- 16, ISSN: 0740-7467.
[9] Characteristics of Higher-Level Languages for Software Architecture. M. Shaw, D. Garlan, Technical Report
CMUCS- 94-210, Carnegie Mellon University, 1994.
[10] Concurrency Control in Distributed Database Systems, ACM Computing Surveys (CSUR), Volume 13, Issue 2,
Pages: 185 - 221, 1981, ISSN: 0360-0300.
[11] A Sampler of Circuit Switching Networks, G. M. Masson, G. C. Gingher, S. Nakamura, Volume 12 , Issue 6, Pages
32-48, 1979, ISSN:0018-9162.
[12] Web Wallet: Preventing Phishing Attacks By Revealing User Intentions, Min Wu, Robert C. Miller, Greg Little,
Source ACM International Conference Proceeding Series; Vol. 149, Proceedings of the second symposium on
Usable privacy and security, Pittsburgh, Pennsylvania, SESSION: Catching phish, Pages: 102 - 113, 2006, ISBN:1-
59593-448-0.
[13] http://www.ash-mvc.org/website/framework/framework.html
[14] Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, Douglas C. Schmidt,
Hans Rohnert, Michael Stal, Dieter Schultz, 2nd edition, Pages: 666, Year of Publication: 2000, ISBN:0471606952.
[15] Analysis Of Optimal Thread Pool Size, Yibei Ling, Tracy Mullen, Xiaola Lin, ACM SIGOPS Operating Systems
Review, Volume 34 , Issue 2, Pages: 42 - 55, Year of Publication: 2000, ISSN:0163-5980.
Page 73 of 73

PA1301 1305 HT08 LP1 Assignment1

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PA1301 1305 HT08 LP1 Assignment1

Caricato da

Copyright:

Formati disponibili

Health ‘R’ Us Group 17

1. Introduction ...................................................................................................................................................................... 3

1.1 Quality Requirements

2.1.1 Product Factors Factor Table

Product Factor Changeability / Flexibility Impact

2.1.2 Developing Strategies: Issue Cards

Platform Independence for Clients

Strategy: Provide web applications support

Concurrent Access to Single Journal

Strategy: Use Ajax

Time to Receive Journal

Strategy: Use distributed database

Maintenance Operations for Servers

Strategy: Use backup servers

Strategy: Use extensive secondary physical memory

Secure System for Web

Strategy: Use secure sockets Layer

Strategy: Use hardware authentication

2.1.3 Technology Factors Factor Table

Technology Factor Flexibility and Changeability Impact

2.1.4 Developing Strategies: Issue Cards

Availability and Usability

Strategy: Use Web based system

Strategy: Make backup servers

2.2.1 Global Analysis

Issue: Platform Independence for Clients

2.2.2 Central Design Tasks

The Conceptual Configuration

sender receiver source dest

Figure 2. Refined High Level Architecture

Figure 4. Authentication component

User login activity is demonstrated in the figure.

Figure 5. Login Component

Figure 6. JournalControlManager Component

Figure 7. View_data Component

Figure 8. Edit_initiate Component

Figure 9. ReportControlManager Component

Figure 10. Search_Request Component

Figure 11. View_data2 Component

Figure 12. BusinessLogic Component

Figure 13. Security Manager Component

Figure 14. Authentication

Figure 15. F_Pass Component

New account creation in AccountsManager is demonstrated in the figure below:

Figure 16. New_Acc Component

Figure 17. Journal Manager Component

Some of the sub modules are listed explained under.

Figure 18. InitialCheckup Component

Figure 19. Prescription Component

Figure 20. Tests Component

Figure 21. Report Manager Component

Figure 22. Searching Component

Figure 23. Report_fetch Component

Figure 24. VersionManager Component

Database Logic Component

Figure 25. Database Logic Component

userLoginDataIn userPrivlegesDataOut journalRawDataIn journalRawDataOut reportRawDataIn

Figure 26. Database Manipulator Component

Figure 27. Search Component

Figure 28. Insert Component

Figure 29. Update Component

Defining Protocols and Behavior

Figure 30. Protocols for BusinessLogic(SecurityManager) and DatabaseLogic(Insert,Update and Search)