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

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

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

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?

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

Refine Module 2d: Define interfaces of child modules

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

Summary ISSS References Use Case Maps http://www.tc.faa.gov/atclabs/essf.html http://home.columbus.rr.com/lusch/blharris.html Use Case Maps http://www.usecasemaps.org/pub/index.shtml http://www.usecasemaps.org/pub/oopslaUCwrkshp.pdf http://www.usecasemaps.org/pub/UCM_book95.pdf