1. iCare Software Architecture Description: Principles, Decisions and Contradictions Team A Aggarwal Ashutosh Alungh Suman Appiah Stella Baddam Bhaskar Baghaie Ali Bansal Dollar Kumar Behrouzy Niloufar

2. 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

3. 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.

4. Why Lyme Disease  Prominent disease in Montreal.  Long lasting disease requiring continuous supervision.  Wide spreading due to rapid environmental changes.

5. iCare Features  Maintaining patients health record.  Manage tests.  Schedule appointments.  Retrieve medical information like ePrescription etc.

6. Stakeholders and Concerns Based on the ISO/IEC/IEEE 42010:2011 standard the stakeholder classes identified in the current context are:  User  Acquirer  Operator  Owner  Developer  Maintainer  Negative Stakeholder

7. Users StakeholderConcernsQuality Attributes Stakeholder Class: User  Patient  Hospital Administration  Doctor  Nurse  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

8. Acquirer, Operator & Owner StakeholderConcernsQuality Attributes Stakeholder Class: Acquirer  Hospital Stakeholder Class: Operator  Hospital iCare Administrator Stakeholder Class: Owner  Local Government  Organization  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

9. Developer StakeholdersConcernsQuality 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

10. Maintainer Stakeholder Class: MaintainerConcernsQuality 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

11. 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.NOStakeholder ClassView Model 1.User, MaintainerLogical View 2.Hospital iCare AdministratorProcess View 3.DeveloperImplementation View 4.OperatorDeployment View 5.User, AcquirerUse Case View

12. System Functionality

13. Architectural Decisions Principles  Separation 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.

14. Architectural Patterns Model 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.

15. 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..

16. 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..

17. Contradictions to Architecture Description Review CriteriaQuestionWeightScoreRemarks ConsistencyAre views presenting different viewpoints in the description consistent with each other? 4.774.25The viewpoints mentioned describes the concerns of the stakeholders. Intuitiveness of the presentation Does the description have an intuitive structure for the stakeholder? 3.182.25 The stakeholder’s classes are well structured as per ISO/IEC/IEEE 42010:2011 standard.

18. CriteriaQuestionWeightScoreRemarks Definition of the notation and structures Does the description use a defined notation? 4.774Notation 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.773Stakeholders and concerns are clearly mapped. However, the 4+1 view model needs to be elaborated. Contradictions Contd..

19. CriteriaQuestionWeightScoreRemarks 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.773Architectural views are well described and focused towards mapping the concerns of the stakeholders. Contradictions Contd..

20. 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.

21. 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

22. Thank you