iCareSoftware Architecture Description: Principles, Decisions and

Contradictions

Team A

Aggarwal Ashutosh

Alungh Suman

Appiah Stella

Baddam Bhaskar

Baghaie Ali

Bansal Dollar Kumar

Behrouzy Niloufar

Agenda

Introduction Why Lyme Disease iCare Features Stakeholders and Concerns Architecture Views and Viewpoints Architectural Principles, Decisions & Patterns Contradictions to Architecture Description Review Lessons Learned

Introduction

What is iCare?

iCare is a mobile based Health Information System.

Enables exchange of information between patient and doctor.

Automates patients and staff management process.

Specific to medical ailments related to Lyme Disease.

Why Lyme Disease

Prominent disease in Montreal.

Long lasting disease requiring continuous supervision.

Wide spreading due to rapid environmental changes.

iCare Features

Maintaining patients health record.

Manage tests.

Schedule appointments.

Retrieve medical information like ePrescription etc.

Stakeholders and Concerns

Based on the ISO/IEC/IEEE 42010:2011 standard the stakeholder classes identified in the current context are:

 UserAcquirerOperatorOwnerDeveloperMaintainerNegative Stakeholder

UsersStakeholder Concerns Quality Attributes

Stakeholder Class: User

Patient Hospital AdministrationDoctorNurse

iCare should be easy to learn and use.

Data must be accessible and modifiable by only appropriate users.

Track medical history of the patient.

Must have constraint on wrong data input.

iCare must check for availability of doctor in hospital.

iCare should guide the patient appropriately.

Accessibility Availability Privacy Modifiability Traceability Functionality• Accuracy• Security

Usability• Understandability• Learnability• Operability

Acquirer, Operator & OwnerStakeholder Concerns Quality Attributes

Stakeholder Class: Acquirer

Hospital

Stakeholder Class: Operator

Hospital iCare Administrator

Stakeholder Class: Owner

Local GovernmentOrganization

iCare should be easy to access data.

Should provide security and safety.

Must be reliable.

Ease in data upload/update.

iCare should be easy to maintain.

Must be traceable.

Should provide brief set of rules and regulations for hospital, pharmacy and insurance company.

Should exemplify policies that are effective.

Security Safety Reliability

Functionality• Accuracy• Security• Interoperability Reliability• Fault-Tolerance• Recoverability

Standard Compliance

DeveloperStakeholders Concerns Quality Attributes

Stakeholder Class:

Developer

Access to the functional requirements of the users.

Knowledge about the external interface of iCare.

Access to the information to be added in the database.

Access to the source code of iCare.

System Properties Efficiency Reusability

Portability• Adaptability• Installability

Modularity

MaintainerStakeholder Class: Maintainer Concerns Quality Attributes

Stakeholder Class:

Maintainer

Knowledge about the organization of different modules.

Ability to recover the information.

Access to the data archives.

System should be adaptable to new environments.

Maintainability• Testability• Changeability• Analyzability

Modifiability Adaptability

Architecture Views and Viewpoints

iCare architecture is expressed using 4+1 View Model.

The view is expressed by considering the concerns of the associated stakeholders.

S.NO Stakeholder Class View Model

1. User, Maintainer Logical View

2. Hospital iCare Administrator Process View

3. Developer Implementation

View

4. Operator Deployment View

5. User, Acquirer Use Case View

System Functionality

Architectural DecisionsPrinciplesSeparation of Concerns: This principle reduces dependency and overlapping to ease

maintenance.

Maximize Cohesion and Minimize Coupling: This principle aims to reduce ripple effects or

cascading effects in the system.

Maximize Modularity and Reusability: This principle aims to reuse a particular business

concern and apply it to other health care customers.

Abstraction: This principle aims to reduce complexity and reduces the data to simplified

representation for different stakeholders.

Don’t repeat yourself: The functionality should not be repeated across the components.

Architectural PatternsModel View Controller Pattern

Problem: To support principles viz., Separation of Concerns, Abstraction etc. The idea is to

separate user interface from application data and logic. Testing of model and controller is

possible without depending on the view.

Solution: The Model-view-controller separates the application into three different components

i.e., Model, View, Controller. The view can be changed without impacting the model, as the view

is separated from the model.

Strengths of the solution

Supports Separation of Concerns.

Promotes organization, extensibility, scalability, flexibility and reuse.

Makes Parallel Development possible.

Layers Pattern

Problem: Increasing users should not lead to system faults. The addition or modification of

functionalities should not lead to failure of other components. Minimum effort is required to

reuse different modules.

Solution: The system is structured into layers: each layer provides a set of services to the layer

above and uses the services of the layer below. In each layer, all constituent components work

at the same level of abstraction.

Strengths of the solution:

Supports Abstraction and Encapsulation.

Provides clearly defined functional layers.

Supports reusability.

Architectural Patterns Contd..

Pipes and Filters Pattern

Problem: Conventional approach reduces the opportunities for refactoring the code, optimizing

it, or reusing it if parts of the same processing are required elsewhere within the application.

Solution: Use of Layers Pattern, where, a complex task is divided into several sequential

subtasks. This division eases refactoring and enables reuse of filters. Filters are independent,

which means different combination of filters can yield different results.

Strengths of the solution:

Process division into discrete and independent steps.

Supports processing that requires scalability requirements.

Supports distribution and processing in different servers.

Architectural Patterns Contd..

Contradictions to Architecture Description ReviewCriteria Question Weight Score Remarks

Consistency Are views presenting different viewpoints in the description consistent with each other?

4.77 4.25 The viewpoints mentioned describes the concerns of the stakeholders.

Intuitiveness of the presentation

Does the description have an intuitive structure for the stakeholder?

3.18 2.25 The stakeholder’s classes are well structured as per ISO/IEC/IEEE 42010:2011 standard.

Criteria Question Weight Score Remarks

Definition of the notation and structures

Does the description use a defined notation?

4.77 4 Notation structure is clearly defined and well understood by the stakeholders. As per the questions framework citations are not part of structure definition.

Clarity of the vocabulary and concepts

Are the terms used defined? Are the (new) concepts defined and explained?

4.77 3 Stakeholders and concerns are clearly mapped. However, the 4+1 view model needs to be elaborated.

Contradictions Contd..

Criteria Question Weight Score Remarks

Architectural views

Are the suitable architectural views chosen for the company or for the project?

Are the viewpoints well defined?

A Viewpoint name?

The stakeholders the viewpoint is aimed at? The concerns the viewpoint addresses?

4.77 3 Architectural views are well described and focused towards mapping the concerns of the stakeholders.

Contradictions Contd..

Lessons Learned

The following enhancements will be applied in response to the feedback regarding our architecture description document.

To achieve higher consistency in views, we will add Data Flow diagram in the next iteration of the document.

A domain diagram will be added to the document to communicate a certain level of domain knowledge.

References P.Kamthan, Winter 2015

http://users.encs.concordia.ca/~kamthan/courses/soen-6471/#resources

Architecture Patterns

https://msdn.microsoft.com/en-ca/library/ee658117.aspx Lyme Disease, Government of Canada: Public Health Agency of

Canada Act, 2006

Available at: http://www.phac-aspc.gc.ca/ Lyme Disease information, CBC News

Available at: http://www.cbc.ca/news/canada/montreal Deliverable Template

http://users.encs.concordia.ca/~kamthan/courses/soen- 6471

Thank you