Revision History - personal.utdallas.educhung/SP... · Web viewIntegrated the Architecture and Detailed Design analysis due to the having a very concurrent design process concerning

Software Architecture And Detailed Design Phase 1

H.O.P.E.Version 1.0October 13, 2011

SE 6v81 .002 – Think For You (TFY)

Caitlin Fowler [email protected] Blackburn [email protected] (Zhenzhou Sun) [email protected] Araujo [email protected] Legunsen [email protected] Shaw [email protected] Wilson [email protected]

http://www.utdallas.edu/~sas071100/hope

TFY Software Architecture And Detailed Design Version 1.0

Revision History

Version Changes Date Modified0.1 Used an existing template to structure the document. Added

initial architectural analysis.10/09/2011

0.1 Used an existing template to structure the document. Added initial architectural analysis.

10/11/2011

0.3 Added architectural design diagrams, completed architectural analysis description.

10/13/2011

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

11/13/2011

Page 2 of 21


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

9. Detailed Design view points 18

9.1. Static perspective 18

9.2. Interaction perspective 19

Page 3 of 21


Appendix A. Current Implementation (System AS-IS) 20

A.1 Static perspective 20

A.2 Interaction perspective 21

Page 4 of 21


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 EasilySAAM – Software Architecture Analysis Method

Page 5 of 21


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


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


Eric BlackburnOwolabi Legunsen

Requirements Engineer

Sam Shaw (Chief)Zhenzhou SunFrederico Araujo

ArchitectDetailed Design

Sam ShawZhenzhou SunFrederico Araujo (Chief)

Development Engineer

Caitlin FowlerSean WilsonZhenzhou 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


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


4. Comparison criteria and scenariosThis 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. Indirect1.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. Direct2.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. Direct3.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. Direct4.2. Evaluation

Option 1 outperforms both Option 2 (architectural design refactoring) and Option 3 (scattered modifications across the current implementation).

Page 10 of 21


5. Enabling/Disabling of the context-aware sorting feature 5.1. Direct5.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


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 1Delegate

Option 2 Refactor

Option 3Map

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 context-aware 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


Reasonable time to implement, given the project time constraints and resources.

Page 13 of 21


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 Architectural Specification

FR2.3.1.1 Frequency statistic Module Contextualizer sets criterion for frequency statistic

FR2.3.1.2 The order the options placed Module ThingsContextualizer and ActionsContextualizer decides the order

FR2.3.1.2.1 Tie for frequency statisticModule ThingsContextualizer and ActionsContextualizer decides the order when there is a tie

FR2.3.1.3 Configuration options Module Preference gets user’s setting and turns on/ off frequency sorting

FR2.3.1.3.1 Turning on/off frequency sorting Module Preference gets user’s setting and turns on/ off frequency sorting

FR2.3.1.4 Increase on frequency statistic of an option

Module ThingsContextualizer and ActionsContextualizer listen to the trigger and make the increasement

FR2.3.1.4.1 Ceiling value an option can reach Module Contextualizer sets criterion for ceiling value an option can reach

FR2.3.1.4.1.1 Decrement by an amount for unselected options

Module Contextualizer sets criterion for this decrement and Module ThingsContextualizer and ActionsContextualizer makes the decrement

I-NFR Issues NFR

NFR2.4.1.1 Speed of the sortingModule ThingsContextualizer and ActionsContextualizer contains good sorting algorithm

NFR2.4.1.2 Speed of the update for sorting results

Module ThingsContextualizer and ActionsContextualizer updates the results quickly

NFR2.4.1.3 Easy to useThe whole architecture designed to present options likely desired by the user closer to the top of the list

NFR2.4.1.4 SafetyModule ThingsContextualizer and ActionsContextualizer doesn't involve anything about Emergency

NFR2.4.1.5 No redundancy Module ThingsContextualizer and ActionsContextualizer just involves

Page 14 of 21


necessary targets to sort

7. Use Case

View Fruit Options Sorted by Frequency DataScope: HOPE SystemLevel: user goalPrimary 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. Speaker clicks Food option.2. System displays sorted Food options.3. Speaker clicks Fruit option.4. System updates frequency statistics for Things category.5. 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


8. Architectural view points

8.1. Static perspective

Figure 2 –Architecture level class diagram showing dependencies amongst classes.

Page 16 of 21


8.2. Interaction perspective

Figure 2 – Architectural level Sequence diagram for things after user click event.

Page 17 of 21


9. Detailed Design view points

9.1. Static perspective

ThingsActivity ActionsActivity

Communication

+increment : int+ceiling : int+decrementRate : double

Contextualizer

+findAllThings() : Cursor+findAllThingsBy(in action : string) : Cursor+updateThing(in position : int) : void+updateVerbThing(in verb : string, in thing : string) : void

ThingsContextualizer+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

ActionsContextualizer

+currentDisplayedThings : string+currentDisplayedActions : string+rootTable : string+verb : string+question : string

HopeApplication

SQLiteDatabase

android.app.Activity

Figure 4 – Class diagram showing details of the frequency sorting feature.

Page 18 of 21


9.2. Interaction perspective

Figure 5 – Detailed Design level Sequence diagram for things after user click event.

Page 19 of 21


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


A.2 Interaction perspective

Figure 7 –OnCreate method of class ThingsActivity reverse engineered

Page 21 of 21

Documents

Revision History - personal.utdallas.educhung/SP... · Web viewIntegrated the Architecture and Detailed Design analysis due to the having a very concurrent design process concerning