1. Lecture 9z Case Study ADD: Garage Door
CSCE 742 Software Architectures
Lecture 9z Case Study ADD: Garage Door
Topics
Garage Door case Study
Flight Simulator (next Time)
June 14, 2017

2. Traits of Successful OO Systems
Grady Booch on traits of successful OO Systems
“We have observed two traits common to virtually all of the successful OO systems we have encountered, and noticeably absent from the ones that we count as failures:
The existence of a strong architectural vision and
The application of a well-managed iterative and incremental development cycle.”

3. Context Review Previously we have examined:
Architecture views
Quality attributes
Documenting Software Architectures
Architectural tactics and patterns for achieving quality attributes
Case Studies
Now Focus on Design of an Architecture
Architecture in the software life cycle
Designing the architecture
Teams and their relationship to the architecture
Creating a skeletal system
Future
Use-Case Maps, Reconstructing SA, Evaluating SA, Case Studies including Web-based

4. Software Life Cycle Software Life Cycle Models Waterfall model
Spiral model
Others?
Where does the architecture fit in?
What is the place for the software architecture?

5. Evolutionary Delivery Life cycle
Software
Concept
Deliver
The Final
Version
Preliminary
Requirements
Analysis
Design of
Architecture
And System
Core
Develop
A Version
Incorporate
Customer
Feedback
Deliver
The Version
Elicit
Customer
Feedback

6. When do we start Developing the SA?
Requirements come first
But not all requirements are necessary to get started
Architecture shaped by
Functional requirements
Quality requirements
Business requirements
Expertise and experience of architects
We call these requirements “architectural drivers”
The A-7E architecture shaped by modifiability and performance requirements
The architecture of the ATC was driven by its … requirement

7. Determining Architectural Drivers
To identify the Architectural Drivers
Identify the highest priority Business Goals
Only a few of these
Turn these into scenarios or use cases
Choose the ones that have the most impact on the architecture
These are the architectural drivers
There should be less than 10 of these
Architecture Tradeoff Analysis Method uses a utility tree to map business drivers into quality scenarios

8. Attribute Driven Design
Design architecture to support both functional requirements and quality requirements.
The authors call their methods Attribute Driven Design ADD
Alternatives, Rational Unified Process (RUP) Kruchten
Hybrid: ADD for SA then following RUP for the rest of the design

9. Garage Door Opener Example
Example: Design a product line architecture for a garage door opener with a larger home information system
Input to ADD: a set of requirements
Functional requirements as use cases
Constraints
Quality requirements expressed as system-specific quality scenarios
Scenarios for Garage door system
Device and controls are different for the various products in the product line
The processor will differ
If an obstacle is perceived during descent it must stop within .1 seconds
The door opener system needs to be accessible from the home information system for diagnosis and control

10. ADD Overview Steps involved in Attribute Driven Design (ADD)
Choose the module to decompose
start with entire system
Inputs for this module need to be available
Constraints, functional and quality requirements
Refine the module
Choose architectural drivers relevant to this decomposition
Choose architectural pattern that satisfies these drivers
Instantiate modules and allocate functionality from use cases representing using multiple views
Define interfaces of child modules
Verify and refine use cases and quality scenarios
Repeat for every module that needs further decomposition

11. Choose the Module to Decompose
System  subsytem  submodule
Example constraint for the Garage Door opener system
Interoperate with the Home Information System
Steps in example
Start with the entire system as the module
Refine the module
Repeats for every module that needs further refining

12. Refine the module 2a: Applied to the Garage Door Opener System
2a. Choose the architectural drivers from the quality scenarios and functional requirements
The drivers will be among the top priority requirements for the module.
In the Garage System, the 4 scenarios were architectural drivers, lots more not given (e.g., usability)
Examining them
Real-time performance requirement
Modifiability requirement
Requirements are not treated as equals
Less important requirements are satisfied within constraints obtained by satisfying more important requirements
This is a difference of ADD from other SA design methods

13. Refine Module 2b: Choose Arch. Pattern
Recall an architectural pattern is determined by:
A set of elements
A topological layout of the elements indicating relationships
A set of semantic constraints
A set of interaction mechanisms
Shaw and Garlan’s list of architectural patterns
For each quality requirement there are identifiable tactics and then identifiable patterns that implement these tactics.
However, patterns have an impact of several quality attributes. How do we balance?

14. Refine Module2b: Choose Arch. Pattern
The goal of this step is to establish an overall architectural Pattern for the module
The pattern needs to satisfy the architectural drivers and is built by “composing” the tactics selected to satisfy the drivers
Two factors involved in selecting tactics:
Architectural drivers themselves of course
Side effects of the pattern implementing the tactic on other requirements
Example: to achieve Modifiability Quality Attribute use “Generalize the module” Tactic yielding “Interpreter” pattern
Examples of interpreters: HTML, macro recording/playback
Note use of interpreters adversely affects performance
We might use interpreter for portion of the design

15. Refine Module2b: Choose Arch. Pattern
Reexamine performance and modifiability tactics (chap 5)
Modifiability Tactic categories
Localize changes
Prevent ripple effects
Defer binding time
Since the modifiability scenarios are primarily concerned with design time changes  primary tactic is “localize changes”
Performance Tactic categories
Resource demand category
Resource arbitration category
Why not Resource Management?
From each primary category select one tactic

16. Refine Module2b: Choose Arch. Pattern
From each primary category select one tactic
Localize changes
Semantic coherence and information hiding
Separate responsibilities dealing with
User interface
Communication
Sensors
Call each of these virtual machines and expect variation within product line
Resource demand category
Increase computational efficiency
Resource arbitration category
Schedule wisely

17. Refine Module2b: Figure 7.2
One Architectural Pattern that utilizes tactics to achieve garage door architectural drivers
User Interface
Non-performance Critical Computation
Performance Critical Computation
Scheduler that Guarantees Deadlines
Virtual Machine

18. First level Decomposition Figure 7.3
User Interface
Non-performance-critical computation
Applications running on top of virtual machine
E.g. normal raising/lowering the door
Virtual machine
This manages communication and sensor interactions
Performance-critical computation
e.g., Managing obstacle detection
Scheduler that Guarantees Deadlines

19. Refine Module 2c: Instantiate Modules and Allocate Functionality using Multiple Views
In the previous step (2b) we established the module types of the decomposition
In this step we instantiate these module types
The criterion we use for allocating functionality is similar to that used in traditional OO designs
Functionality to be provided
Raising/lower door (normal mode) - non-critical
Managing obstacle detection - critical
Virtual machine sensors
Virtual machine communication

20. Refine Module2c: Instantiate Modules Fig 7.3
User Interface
Raising-Lowering Door
Obstacle Detection
Diagnosis
Scheduler that Guarantees Deadlines
Communication Virtual Machine
Sensor/Actuator
Virtual Machine

21. Refine Module 2c: Instantiate Modules and Allocate Functionality using Multiple Views
Next step is to verify the decomposition achieves the desired functionality
Allocate functionality
Applying use cases may modify decomposition
In the end every use case of the parent module must be representable by sequence of responsibilities within children
Assigning these responsibilities to the children will also determine communications: producer/consumer relationship
How the information is exchanged is not critical at this point
Some tactics will introduce specific patterns of interaction
E.g. use of a “publish-subscribe” intermediary introduces pattern “publish” for one module “subscribe” for the other

22. Represent the Architecture with Multiple Views
Views: module decomposition, concurrency, and deployment
Module decomposition view
Provide containers for functionality
Concurrency view
Parallel activities such as resource contention, deadlock
Likely will lead to the discovery of new responsibilities
Possibly new modules – e.g. a resource manager
Virtual threads describe execution paths through the system
Synchronization: “starts,” “stops,” “synchronizes with,” “cancels,” “communicates with”
Deployment view

23. Use cases Illustrating Concurrency
Two uses doing similar things at the same time
One user performing multiple activities simultaneously
Starting up the system
Shutting down the system

24. Refine Module 2d: Define interfaces of child modules

25. Refine Module 2e: Verify and refine use cases and quality scenarios as constraints for the child modules

26. Summary ISSS References Use Case Maps
Use Case Maps