CSCE 742 Software Architectures Lecture 9 z Case

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

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: 1. The existence of a strong architectural vision and 2. The application of a well-managed iterative and incremental development cycle. ” – 2– CSCE 742 Summer 2017

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

Software Life Cycle Models l Waterfall model l Spiral model l Others? Where does the architecture fit in? What is the place for the software architecture? – 4– CSCE 742 Summer 2017

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

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

Determining Architectural Drivers To identify the Architectural Drivers l Identify the highest priority Business Goals n Only a few of these l Turn these into scenarios or use cases l Choose the ones that have the most impact on the architecture n n 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 – 7– CSCE 742 Summer 2017

Attribute Driven 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 – 8– CSCE 742 Summer 2017

Garage Door Opener Example: Design a product line architecture for a garage door opener with a larger home information system Input to ADD: a set of requirements n n n Functional requirements as use cases Constraints Quality requirements expressed as system-specific quality scenarios Scenarios for Garage door system n n – 9– 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 CSCE 742 Summer 2017

ADD Overview Steps involved in Attribute Driven Design (ADD) 1. Choose the module to decompose n n start with entire system Inputs for this module need to be available l Constraints, functional and quality requirements 2. Refine the module a. b. c. d. e. 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 3. Repeat for every module that needs further CSCE 742 Summer 2017 – 10 – decomposition

Choose the Module to Decompose System subsytem submodule Example constraint for the Garage Door opener system n Interoperate with the Home Information System Steps in example 1. Start with the entire system as the module 2. Refine the module 3. Repeats for every module that needs further refining – 11 – CSCE 742 Summer 2017

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

Refine Module 2 b: Choose Arch. Pattern Recall an architectural pattern is determined by: n A set of elements n n A topological layout of the elements indicating relationships A set of semantic constraints n 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? – 13 – CSCE 742 Summer 2017

Refine Module 2 b: 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: n n 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 CSCE 742 Summer 2017 We might use interpreter for portion of the design – 14 –

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

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

Refine Module 2 b: Figure 7. 2 One Architectural Pattern that utilizes tactics to achieve garage door architectural drivers User Interface Nonperformance Critical Computation Virtual Machine – 17 – Performance Critical Computation Scheduler that Guarantees Deadlines CSCE 742 Summer 2017

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

Refine Module 2 c: Instantiate Modules and Allocate Functionality using Multiple Views In the previous step (2 b) 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 n n – 19 – Raising/lower door (normal mode) - non-critical Managing obstacle detection - critical Virtual machine sensors Virtual machine communication CSCE 742 Summer 2017

Refine Module 2 c: Instantiate Modules Fig 7. 3 User Interface Diagnosis Communication Virtual Machine – 20 – Raising. Lowering Door Sensor/Actuator Virtual Machine Obstacle Detection Scheduler that Guarantees Deadlines CSCE 742 Summer 2017

Refine Module 2 c: Instantiate Modules and Allocate Functionality using Multiple Views Next step is to verify the decomposition achieves the desired functionality Allocate functionality n n n 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 l E. g. use of a “publish-subscribe” intermediary introduces pattern “publish” for one module “subscribe” for the other – 21 – CSCE 742 Summer 2017

Represent the Architecture with Multiple Views: module decomposition, concurrency, and deployment l Module decomposition view n Provide containers for functionality l Concurrency view n n n 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” l Deployment view – 22 – CSCE 742 Summer 2017

Use cases Illustrating Concurrency l Two uses doing similar things at the same time l One user performing multiple activities simultaneously l Starting up the system l Shutting down the system – 23 – CSCE 742 Summer 2017

Refine Module 2 d: Define interfaces of child modules – 24 – CSCE 742 Summer 2017

Refine Module 2 e: Verify and refine use cases and quality scenarios as constraints for the child modules – 25 – CSCE 742 Summer 2017

Summary ISSS References n http: //www. tc. faa. gov/atclabs/essf. html n http: //home. columbus. rr. com/lusch/blharris. html Use Case Maps n n n – 26 – http: //www. usecasemaps. org/pub/index. shtml http: //www. usecasemaps. org/pub/oopsla. UCwrkshp. pdf http: //www. usecasemaps. org/pub/UCM_book 95. pdf CSCE 742 Summer 2017