1. Evaluating Software Architectures RiSE’s Seminars Clement’s book :: Chapters 05 Eduardo Cruz

2. 2 Summary About Software Architecture Quality Attribute Characterizations  Performance  Availability  Modifiability  Characterizations Inspire Questions Using Quality Attributes Characterizations in ATAM  Attribute-Based Architectural Styles

3. 3 About software architecture

4. 4 What is software architecture ? It is the manifestation of the earliest design decisions It is a reusable, transferable abstraction of a system

5. 5 Why software architecture is important Is a vehicle for communication among stakeholders  Architectural View  Functional View  Concurrency View  Code View  Development view  Physical View

6. 6 Why evaluate an architecture ? The sooner, the better Avoid disasters

7. 7 Who’s involved Evaluation team Stakeholders

8. 8 Understanding Quality Attributes Quality Attributes - Prerequisite of an evaluation Common incomplete quality atribute requirements and architecture documentation

9. 9 Architecture Evaluation  Focus on Quality Attributes Evaluate the architecural design decisions to determine if they address the quality attribute scenarios Understanding Quality Attributes

10. 10 Quality attribute parts Availability Modifiability Performance Security Testability Usability Designing the Architecture :: Chapter 7 ARTIFACT STIMULUSRESPONSE MEASURE SOURCE OF STIMULUS ENVIRONMENT

11. 11 Functionality and Quality Attributes Must be considered throughout: design, implementation and deployment  Usability, Modifiability, Performance Architecture itself is unable to achieve quality if attention is not paid to the details With complex systems, quality attributes can never be achieved in isolation Software architecture in Practice Chapter 4 – Understanding Quality Attributes

12. 12 Quality attribute characterizations

13. 13 Quality Attribute Characterizations Different in its stimuli  Performance – Arrival of events  Availability – Fault occuring Different in its responses  Modifiability – persons-day required to make a requested change  Security – how many intruders will break into the systems and what resources they will be able to access

14. 14 Performance Ability of a system to allocate its computational resources to requests for service in a manner that will satisfy timing requirements Resource types  Uni/multi processors, memory, devices Resource arbitration  On-line/Off-line Scheduling, Synchronization Resource Allocation  Load Balancing Resource consumption  Execution Time, Memory Size, Network Bandwith

15. 15 Availability Concerned with system failure and its consequence Failure concerns  How is detected  How frequently may occur  Consequences  How long is out of operation  How to prevent Software architecture in Practice Chapter 4 – Understanding Quality Attributes

16. 16 Sample Availability-related questions Stimuli  How are hadware and software failures identified ?  Can active as well passive failures be identified ? Architectural decisions  If redundancy is used in the architecture … what type of redundancy (analytic, replication, functional) ? How many replicas of each critical component and connection are used ? Responses  Are there levels of service available ?  How quickly ca a backup be made/restored ?

17. 17 Modifiability Ability of a system to be changed after is implemented

18. 18 Modifiability Cost of change  What to change Hardware, OS, Performance, number of users  When and Who Compile, build, setup, execution  Specify, design, implement, test, deploy Time and money, measured Software architecture in Practice Chapter 4 – Understanding Quality Attributes

19. 19 Security System's ability to resist to unauthorized usage while still providing its service to legitimate users Attack – Attempt to breach security  Access data, modify data, deny service Characteristics  Nonrepudiation You did (Transaction)  Confidentiality Protected data (income tax)  Integrity Cannot change data  Assurance You are who purport to be (credit card)  Availability Free of DOS  Auditing Keep track of activities Software architecture in Practice Chapter 4 – Understanding Quality Attributes

20. 20 Usability How easy it is for the user to accomplish a desired task and the kind of support the system provides  Learning system features  Using system efficiently  Minimizing the impact of errors  Adapting the system to user needs  Increasing confidence and satisfaction “Usability is not architectural” Software architecture in Practice Chapter 4 – Understanding Quality Attributes

21. 21 Using Quality Attributes Characterizations in ATAM

22. 22 Modifiability Characterization Stimuli Chage Request Function Platform Quality Attribute Operating Environment Architectural Decisions Indirection Encapsulation Separations Responses Addition Modification Deletion Characterization inspires questions

23. 23 Characterization inspires questions A beginner can make use of existing questions It requires more expertise in a quality attribute to devise new questions from the characterizations It requires still more expertise to understand how to respond to the questions

24. Template for Analysis of an Architectural Approach Scenario #: A12Scenario: Detect and recover from HW failure of main switch AttributesAvailability EnvironmentNormal Operations StimulusOne of the CPUs fails Response0.999999 availability of the swith Architectural Decisions SensitivityTradeoffRiskNonrisk Backup CPUS2R8 No backup data channel S3T3R9 HeartbeatS5N12 Reasoning Ensures no common mode failure by using different hardware and operating systems (see Risk R8) Worst case rollover is accomplished in 4 seconds as computing state takes that long at worst Guaranteed to detect failure with 2 seconds based on rates of heartbeat and watchdog Primary CPU (OS1) Backup CPU w/ watchdog (OS2) Primary CPU (OS1) Architecural diagram

25. 25 Quality Scenarios Source of stimulus  Some entity: Human, computer Stimulus  Condition that need to be considered when it arrives at a system Environment  Stimulus occurs within certain conditions Artifact  What is stimulated. The whole system or some pieces of it Response  Activity undertaken after the arrival of the stimulus Response measure  Response should be measurable, so that the requirement can be tested. Software architecture in Practice Chapter 4 – Understanding Quality Attributes

26. 26 ABAS – Attribute-Based Architectural Styles Related architectural and analysis techniques in a package  Problem description  Stimuli/responses  Architectural style  Analysis Another source of inspiration and reference when criating the attribute specific questions

27. 27 Business Qualities System Qualities x Business Qualities Cost, schedule, market, marketing  Time to market Commercial off-the-shelf (COTS)  Cost and benefit Exceed budget  Projected lifetime of the system Portability/usability  Targeted market  Rollout schedule Base functionality w/ features later  Integration with legacy system Software architecture in Practice Chapter 4 – Understanding Quality Attributes

28. 28 References [Clements, 2001] P. Clements, R. Kazman, M. Klein, Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley, 2001, pp. 368. [Bass, 2003] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 2nd Edition, Addison-Wesley, 2003, pp. 560. Images: Stock.XCHNG