Software Architecture and Detailed Design

advertisement
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
Download