Software Architecture in Practice

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

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. Evolutionary Delivery Life Cycle Software Concept Deliver Final Version Preliminary Requirements Analysis Design of Architecture and System Core Develop a Version Deliver the Version Incorporate Customer Feedback Elicit Customer Feedback

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

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

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

7. Designing the Architecture :: Chapter 7 Attribute-Driven Design • 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. Designing the Architecture :: Chapter 7 Attribute-Driven Design (cont.) • 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. 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. 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 Subsystem System Subsystem

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. 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. 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. References • L. Bass, P. C. Clements, R. Kazman. Software Architecture in Practice. Second Edition, Addison-Wesley, 2003.