Software Architecture And Detailed Design Phase 1 H.O.P.E. Version 1.0 October 13, 2011 SE 6v81 .002 – Think For You (TFY) Caitlin Fowler Eric Blackburn Frank (Zhenzhou Sun) Frederico Araujo Owolabi Legunsen Sam Shaw Sean Wilson cmf067000@utdallas.edu ejb022000@utdallas.edu zxs101020@utdallas.edu fxs105020@utdallas.edu ool090020@utdallas.edu sas071100@utdallas.edu srw051000@utdallas.edu http://www.utdallas.edu/~sas071100/hope TFY Software Architecture And Detailed Design Version 1.0 Revision History Version 0.1 0.1 0.3 1.0 Changes Used an existing template to structure the document. Added initial architectural analysis. Used an existing template to structure the document. Added initial architectural analysis. Added architectural design diagrams, completed architectural analysis description. Integrated the Architecture and Detailed Design analysis due to the having a very concurrent design process concerning the views of the Architecture and the views of the Detailed Design. Date Modified 10/09/2011 10/11/2011 10/13/2011 11/13/2011 Page 2 of 21 TFY Software Architecture And Detailed Design Version 1.0 Table of Contents Revision History 2 Table of Contents 3 1. Introduction 5 1.1 Project overview 5 1.2 Purpose 5 1.3 Evolution of this document 5 1.4 References 5 1.5 Definitions, acronyms, and abbreviations 5 1.6 Architectural and Detailed Design representation 6 1.7 Architectural and Detailed Design goals and constraints 6 2. Architectural and Detailed Design process 7 2.1 Methodology 7 2.2 Organizational chart 7 3. Architectural candidates 9 3.1 Initial Architectural Evaluation 9 3.2 Candidate alternatives 9 4. Comparison criteria and scenarios 10 5. Architectural and Detailed Design selection 12 5.1 Architectural and Detailed Design evaluation 12 5.2 Selected alternative 12 6. Traceability matrix 14 7. Use Case 15 8. Architectural view points 16 8.1. Static perspective 16 8.2. Interaction perspective 17 Detailed Design view points 18 9. 9.1. Static perspective 18 9.2. Interaction perspective 19 Page 3 of 21 TFY Software Architecture And Detailed Design Appendix A. Current Implementation (System AS-IS) Version 1.0 20 A.1 Static perspective 20 A.2 Interaction perspective 21 Page 4 of 21 TFY Software Architecture And Detailed Design Version 1.0 1. Introduction 1.1 Project overview Part of the world’s population has difficulty communicating and interacting with their environment due to physical and mental disabilities. Difficulties with hearing loss, memory loss, and vision and speech impairment are common problems encountered amongst the disabled population. H.O.P.E is an application developed by the University of Texas at Dallas and Dr. Lawrence Chung in order to assist this population with interacting and communicating with the world around them. TFY is developing an application, which will integrate with the current H.O.P.E. application and allow the user to sort icons based on contextual information. The icons will be sorted based on characteristics such as time of year, location and frequency of use. The user will have the option to turn on and off the module based on their preference. 1.2 Purpose This document provides an architectural overview of the context-aware sorting feature that will extend the current version of the H.O.P.E. application. Multiple architectural views are present to highlight particular aspects of the system as seen from various perspectives. 1.3 Evolution of this document See Revision History section for the document’s revision history. 1.4 References Project Plan: Project plan containing expected deliverables, deadlines, and project organization. http://www.utdallas.edu/~sas071100/hope/Project_Plan_v1.0.doc (please refer to latest version) WRS: Requirements specification document. http://www.utdallas.edu/~sas071100/hope/WRSv04.doc (please refer for latest version) HOPE Website: http://www.utdallas.edu/~rym071000/index.html 1.5 Definitions, acronyms, and abbreviations H.O.P.E. – Helping Our People Easily SAAM – Software Architecture Analysis Method Page 5 of 21 TFY Software Architecture And Detailed Design Version 1.0 1.6 Architectural and Detailed Design representation This document presents the system’s architecture in the form of “4+1” views, including the use-case view, logical view, process view, development view, and physical view. These views are based largely on the system’s underlying model as expressed in Unified Modeling Language (UML). 1.7 Architectural and Detailed Design goals and constraints This section lists the architectural goals and constraints with respect to the new context-aware sorting feature for the H.O.P.E. application. Performance of the new feature must not suffer from architectural limitations. The system architecture must be mostly reusable (with respect to the new feature). It must be possible to enhance the new feature with additional functionality while encountering few if any complications regarding existing components. The new feature should not comprise integration with legacy H.O.P.E. application and concurrent features being developed by other teams. Page 6 of 21 TFY Software Architecture And Detailed Design Version 1.0 2. Architectural and Detailed Design process 2.1 Methodology TFY used the Software Architecture Analysis Method (SAAM) as a basis upon which to systematically decide upon the ideal architecture for the new feature under development. The purpose of this practice is to formally weigh the benefits and drawbacks of architectural candidates, thus providing a way to objectively determine the best design. There are six main steps in the SAAM process. These are: 1. Develop scenarios 2. Describe candidate architecture 3. Classify and prioritize scenarios 4. Perform scenario evaluation 5. Assess scenario interaction 6. Generate overall evaluation The candidate architectures in step two are described in detail immediately following the Architectural Process section of this document. Scenarios were developed in step one and elaborated upon in steps 35 regarding likely potential uses of the context-aware sorting feature. These are listed following the description of candidate architectures. In this section, these scenarios are evaluated with regard to individual architectural candidates. The overall evaluation of step six immediately follows the assessment of scenario interaction. The ideal architectural candidate is identified in this section, as well as rationale explaining the reasons for our selection. 2.2 Organizational chart Team members assumed the roles described in Table 1 for analysis and design: Table 1 – Team organization Team Members Project Role Page 7 of 21 TFY Eric Blackburn Owolabi Legunsen Software Architecture And Detailed Design Version 1.0 Requirements Engineer Sam Shaw (Chief) Zhenzhou Sun Frederico Araujo Architect Detailed Design Sam Shaw Zhenzhou Sun Frederico Araujo (Chief) Development Engineer Caitlin Fowler Sean Wilson Zhenzhou Sun Quality Assurance Engineer Eric Blackburn Project Manager Figure 1 – Roles organization chart The diagram illustrated in Figure 1 depicts the relationships between roles with respect to the process architecture. Black arrows indicate traceability between products of effort, while blue arrows indicate coordination. Page 8 of 21 TFY Software Architecture And Detailed Design Version 1.0 3. Architectural candidates 3.1 Initial Architectural Evaluation This project involves the creation of a new feature for an existent application, the H.O.P.E. application. Based on this fact, the architectural process presented is not concerned with the overall architecture style selection (since this is given on premise by the legacy or already existent application). Therefore, the main outcome of the tradeoff analysis carried in this document is for the selection of the design alternative to considered for the new sorting feature to be integrated to the H.O.P.E. application (application TO-BE). In this light, it was also important for the quality of the architectural process to assess the current implementation of the H.O.P.E application (application AS-IS). For this matter, a technique called Reverse Engineering has been applied. See Appendix A for the static and interaction perspectives of the current HOPE application with respect to sentence completion for things. 3.2 Candidate alternatives The candidate alternatives considered for our architectural design are listed in the form of options. Each option gives an overall view of the intended architectural approach for later evaluation in Section 4. Option1: Delegate the responsibility of filtering things and actions to a module that would wrap the data access layer and updates the frequency for things and actions. Option 2: Refactor the existing architecture into a multilayer configuration with separate data access, business logic and presentation layers. The frequency sorting feature would then extend the business logic layer. Option 3: Map all the points of change in the current system to extend with frequency sorting logic. Page 9 of 21 TFY Software Architecture And Detailed Design Version 1.0 4. Comparison criteria and scenarios This section describes the main scenarios considered for selecting among the architectural alternatives already presented. They are presented in order of descended priority. 1. Ease of integration with current application implementation, in terms of concurrent features under development [Integrability] 1.1. Indirect 1.2. Evaluation Option 2 includes architectural design and code refactoring. Because the sorting feature has direct implication on the core of the H.O.P.E application, this option does not perform well in terms of integrability, due to a high risk of impacting other features being developed at the same time. Option 3 also suffers from critical limitations, such as the possibility of overlapping with other concurrent developed features. Therefore, in view of ease of future integration Option 1 performs better than the other options, by reducing coupling between the context-aware sorting feature and the current implemented logic. 2. Ease of understand, track changes, and trace bugs [Maintainability] 2.1. Direct 2.2. Evaluation Option 2 and Option 1 both performs well on this criterion. Option 2 outperforms Option 1 in the sense that the architectural refactoring of the current implementation would enhance separation of concerns between application modules and make modules more cohesive, thus positively reflecting in greater understandability and maintainability not only for the new context-aware sorting feature but for the overall application. Option 3 would just reduce the quality of the already existent implementation in terms of understandability by adding scattered modifications throughout the application. 3. Addition/removal of contextual rules (e.g. time, location) [Extensibility] 3.1. Direct 3.2. Evaluation Addition/Removal of contextual rules is better achieved by Option 1 and Option 2 because of separation of concerns; however Option 3 would imply in increased levels of complexity for each additional rule (as well as for removal), due to high level of coupling and low level of cohesiveness. 4. Time and cost of implementation of the new feature [Implementation Cost] 4.1. Direct 4.2. Evaluation Option 1 outperforms both Option 2 (architectural design refactoring) and Option 3 (scattered modifications across the current implementation). 5. Enabling/Disabling of the context-aware sorting feature Page 10 of 21 TFY Software Architecture And Detailed Design Version 1.0 5.1. Direct 5.2. Evaluation Enabling/Disabling of the contextual-feature is better achieved by Option 1 and Option 2 because of separation of concerns; however Option 3 would imply in increased levels of complexity for each additional rule (as well as for removal), due to high level of coupling and low level of cohesiveness. Page 11 of 21 TFY Software Architecture And Detailed Design Version 1.0 5. Architectural and Detailed Design selection 5.1 Architectural and Detailed Design evaluation Table 2 presents the architectural evaluation and tradeoff analysis based on the selected scenarios presented in Section 4. This table summarizes the comparison based on the four main criteria chosen to guide the architectural design: Maintainability, Integrability, Implementation Cost, and Extensibility. Table 2 – Architectural evaluation and tradeoff analysis based on selected scenarios Criterion\Option Option 1 Option 2 Option 3 Delegate Refactor Map + ++ -- ++ -- +- + -- - + ++ -- Maintainability (e.g., understandability, ease of...) Integrability (e.g., in terms of concurrent features under development) Implementation Cost (e.g., time) Extensibility (e.g., add, change, future growth) ++ = 100% + = 75% +- = 50% - = 25% -- = 0% Option1: 80% Option2: 50% Option3: 20% 5.2 Selected alternative Based on the tradeoff analysis (see Section 5.1) guided by the evaluation of the different scenarios presented in Section 5, the alternative chosen to guide the architectural design of the new contextaware sorting feature is Option 1. The summarized reasons that justify this choice are: High level of integrability with concurrent features under development for the existent HOPE application. High level of maintainability due to reduced coupling with current implementation. Ease of adding, removing, and changing the new feature, accommodating future growth. Page 12 of 21 TFY Software Architecture And Detailed Design Version 1.0 Reasonable time to implement, given the project time constraints and resources. Page 13 of 21 TFY Software Architecture And Detailed Design Version 1.0 6. Traceability matrix Table 3 shows the traceability between the specified requirements and the architectural specification. Table 3 – Traceability matrix between requirements specification and architectural specification I-FR Issues FR FR2.3.1.1 Frequency statistic FR2.3.1.2 The order the options placed FR2.3.1.2.1 Tie for frequency statistic FR2.3.1.3 Configuration options FR2.3.1.3.1 Turning on/off frequency sorting FR2.3.1.4 Increase on frequency statistic of an option FR2.3.1.4.1 Ceiling value an option can reach FR2.3.1.4.1.1 Decrement by an amount for unselected options I-NFR Issues NFR NFR2.4.1.1 Speed of the sorting NFR2.4.1.2 Speed of the update for sorting results NFR2.4.1.3 Easy to use NFR2.4.1.4 Safety NFR2.4.1.5 No redundancy Architectural Specification Module Contextualizer sets criterion for frequency statistic Module ThingsContextualizer and ActionsContextualizer decides the order Module ThingsContextualizer and ActionsContextualizer decides the order when there is a tie Module Preference gets user’s setting and turns on/ off frequency sorting Module Preference gets user’s setting and turns on/ off frequency sorting Module ThingsContextualizer and ActionsContextualizer listen to the trigger and make the increasement Module Contextualizer sets criterion for ceiling value an option can reach Module Contextualizer sets criterion for this decrement and Module ThingsContextualizer and ActionsContextualizer makes the decrement Module ThingsContextualizer and ActionsContextualizer contains good sorting algorithm Module ThingsContextualizer and ActionsContextualizer updates the results quickly The whole architecture designed to present options likely desired by the user closer to the top of the list Module ThingsContextualizer and ActionsContextualizer doesn't involve anything about Emergency Module ThingsContextualizer and ActionsContextualizer just involves necessary targets to sort Page 14 of 21 TFY Software Architecture And Detailed Design Version 1.0 7. Use Case View Fruit Options Sorted by Frequency Data Scope: HOPE System Level: user goal Primary Actor: Hope User (Speaker) Stakeholders and Interests: Speaker: Want an easy to navigate system, with minimum scrolling. Want to be able to express correct needs through system. Assistive Person: Want to be able to care for and understand the Speaker. Listener: Want to be able to understand the listener without a substantial wait. Speaker Family Members: Want Speaker to live a happy life, have Speaker’s needs met. Preconditions: Speaker has logged into the HOPE system and clicked sentence. The Speaker has selected an option before in the Fruit category so that usage frequency information has been gathered in the system and the information gathered has not been reset since gathering recent information. The frequency sorting feature is On. Postconditions: The system presents the selected fruit option to be ready for the speak command. Main Success Scenario: 1. 2. 3. 4. 5. Speaker clicks Food option. System displays sorted Food options. Speaker clicks Fruit option. System updates frequency statistics for Things category. System displays sorted Fruit with the fruit option the Speaker chooses most frequently, as well as recently, is the first choice on screen. 6. Speaker clicks banana option. 7. System updates frequency statistics for Food category. Extensions: This is an abstract simple scenario and extension situation will not be covered. Special Requirements: Speaker must be able to turn the system off Technology and Data Variations List: Any phone running the Android operating system Developers can add icons Developers can add categories Frequency of Occurrence: Almost continuous. Page 15 of 21 TFY Software Architecture And Detailed Design Version 1.0 8. Architectural view points 8.1. Static perspective Figure 2 –Architecture level class diagram showing dependencies amongst classes. Page 16 of 21 TFY Software Architecture And Detailed Design 8.2. Version 1.0 Interaction perspective Figure 2 – Architectural level Sequence diagram for things after user click event. Page 17 of 21 TFY Software Architecture And Detailed Design Version 1.0 9. Detailed Design view points 9.1. Static perspective android.app.Activity Communication ThingsActivity ActionsActivity HopeApplication +currentDisplayedThings : string +currentDisplayedActions : string +rootTable : string +verb : string +question : string SQLiteDatabase Contextualizer +increment : int +ceiling : int +decrementRate : double ActionsContextualizer ThingsContextualizer +findAllThings() : Cursor +findAllThingsBy(in action : string) : Cursor +updateThing(in position : int) : void +updateVerbThing(in verb : string, in thing : string) : void +findAllActions() : Cursor +findAllActionsBy(in thing : string) : Cursor +findAllCommentsBy(in thing : string) : Cursor +findAllComments() : Cursor +findAllVerbs() : Cursor +updateAction(in table : string, in action : string) : void +updateThingVerb(in thing : string, in verb : string) : void +updateThingComment(in thing : string, in comment : string) : void Figure 4 – Class diagram showing details of the frequency sorting feature. Page 18 of 21 TFY Software Architecture And Detailed Design 9.2. Version 1.0 Interaction perspective Figure 5 – Detailed Design level Sequence diagram for things after user click event. Page 19 of 21 TFY Software Architecture And Detailed Design Version 1.0 Appendix A. Current Implementation (System AS-IS) A.1 Static perspective Figure 6 – Sketch for structural view point of sentence completion feature (things perspective) Page 20 of 21 TFY Software Architecture And Detailed Design Version 1.0 A.2 Interaction perspective Figure 7 –OnCreate method of class ThingsActivity reverse engineered Page 21 of 21