icare software architecture description: principles, decisions and contradictions team a aggarwal...
TRANSCRIPT
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