1. Software Architecture in Practice RiSE’s Seminars Bass’s book :: Chapters 07 Eduardo Santana de Almeida

2. 2 Summary Designing the Architecture (Chapter 7)  Evolutionary Delivery Life Cycle  When Can I begin Designing?  How to identify the architectural drivers?  Attribute-Driven Design

3. 3 Evolutionary Delivery Life Cycle Software Concept Preliminary Requirements Analysis Design of Architecture and System Core Develop a Version Incorporate Customer Feedback Elicit Customer Feedback Deliver the Version Deliver Final Version

4. 4 Evolutionary Delivery Life Cycle Goal  To get user and customer feedback Microsoft strategy  Skeletal system Early Low-fidelity Updates Designing the Architecture :: Chapter 7

5. 5 When Can I begin Designing? Architecture  Shape Functionality Quality Business requirements Examples  Avionic system Availability, Performance, Security...  COMPGOV Availability, Performance, Security... Designing the Architecture :: Chapter 7 Architectural drivers

6. 6 How to identify the architectural drivers? Designing the Architecture :: Chapter 7 To priorize business goals {few} To put these business goals into quality scenarios or use cases  Scenary’s template To choose the most importants  Impact on the architecture

7. 7 Attribute-Driven Design Designing the Architecture :: Chapter 7 Approach to define a software architecture that bases the decomposition process on the quality attributes the software has to fulfill Recursive decomposition process Use  Tatics  Architectural Patterns Systematic approach

8. 8 Attribute-Driven Design (cont.) Designing the Architecture :: Chapter 7 To satisfy quality attributes and functional requirements RUP’s extension  High-level design  Detailed design and implementation ADD  Detailed {high-level} + Rational Input  Functional requirements (expressed as use cases)  Constraints  Quality attributes scenarios

9. 9 ADD Steps (p. 157) Choose the module to decompose  Module: the system  Inputs: requirements, quality attributes, constraints  Quality attributes scenarios Refine the module  Choose the architectural drivers from the set of concrete quality scenarios and functional requirements  Choose an architectural pattern that satisfies the architectural drivers  Instantiate modules and allocate functionality from the use cases  Define interfaces of the child modules  Verify and refine use cases and quality scenaries Repeat the steps above for every module that needs further decomposition

10. 10 ADD Steps Choose the module to decompose  System  Subsystem  Submodules Choose the architectural drivers  Combination of functional and quality requirements that “shape” the architecture or the particular module under considerations  It is not always a top-down process Prototype  Decomposition criterias Based on architectural drivers Requirements priorization System Subsystem

11. 11 ADD Steps (cont.) Choose an Architectural Pattern  Goal: To establish an overall architectural pattern consisting of module types  Quality attributes -> Tatics -> Patterns Instantiate Modules and Allocate Functionality using Multiple Views  Instantiate module Use of responsability  Allocate functionality Based on Use cases  Represent the architecture with views (flexibility) Iterative process One view is normally sufficient  Module decomposition  Concurrency  Deployment  Others aspects can be used

12. 12 ADD Steps (cont.) Define Interfaces of the Child Modules  Documentation aspects Verify and Refine Use cases and Quality Scenarios as Constraints for the Child Modules  Functional requirements Requirements + use cases -> module  Constraints The decomposition satisfies the constraint The constraint is satisfied by a single child module The constraint is satisfied by multiple child module

13. 13 ADD Steps (cont.)  Quality scenarios A quality scenario may be completely satisfied by the decomposition without any additional impact A quality scenario may be satisfied by the current decomposition with constraints on child modules The decomposition may be neutral with respect to a quality scenario A quality scenario may not be satisfiable with the current decompostion  Result Child module  Responsability  Use cases  Interfaces  Quality scenario  Constraints

14. 14 References L. Bass, P. C. Clements, R. Kazman. Software Architecture in Practice. Second Edition, Addison- Wesley, 2003.