1. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 1 T-76.5150 Software Architectures Introduction to quality attributes

2. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 2 Outline  Overview and motivation  Concepts and classifications  Quality attributes in architecture design

3. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 3 Quality Attributes Overview and motivation

4. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 4 To get things started...  Discuss within a group  Identify some example real-life systems and their quality attribute requirements. These examples could be systems you have used, or systems you have developed.  Can you find an example of a system that has no QA requirements, or the QA requirements are so insignificant that they pose no constraints on the system implementation?

5. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 5 Why are quality attributes important?  Are often more critical than functional requirements (Sommerville, 2004)  E.g., if an aircraft system does not meet its reliability requirements, it will not be taken into use  Affect how user perceives the quality of the product  E.g., awkward usability is a sure way to annoy user  Often cross-cutting throughout many functions, difficult to avoid or find countermeasures  Despite this, the software development in many companies is feature-driven  Perhaps functionality is easier to be marketed…?

6. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 6 Why should an architect care about QAs?  Software architecture substantially determines many of the system quality attributes  If the architecture hasn’t been designed to support certain quality attributes, it is hard to add support through detailed design only  Changes to quality attributes may require changes to system architecture  In other words, many quality attributes are architecturally sensitive  However, some quality attributes are more sensitive to the architecture than others  Compare e.g. modifiability and usability

7. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 7 But isn’t functionality more important for SA?  The mapping of system’s functionality onto software structures determines the architecture’s support for quality attributes  However, functionality itself is not architecturally sensitive  Functionality is orthogonal to structure  Any number of possible structures can be conceived to implement any given functionality  If achievement of functionality is the only requirement, the system could exist as a single monolithic component with no internal structure at all (Bass et al., 2003)

8. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 8 Why are quality attributes challenging?  Firstly, quality attributes often depend on the system as a whole, not on a single service or subsystem  How to pinpoint the location in the system where reliability is realised?  That is why architects should care about QAs!  Secondly, quality attributes interrelate with functionality  Thirdly, quality attributes are often in conflict with each other  Fourthly, it is often surprisingly difficult to pinpoint quality attribute needs as requirements

9. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 9 Challenge: interrelation with functionality  Many QAs cannot be cleanly separated from raw behaviour  Often impossible to say: ”quality of system is X” without reference to system functions  Functionality tells what the system does, quality attributes specify how the system does it  Quality attributes act as constraints on functionality (Sommerville, 2004)  The choice of functions does not dictate the level of quality attributes  However, functionality affects the achievement of quality attributes  Often, in order to achieve quality attributes, certain functionality is added to the system  Quality is transformed into functionality in the development lifecycle

10. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 10 Challenge: QAs can be in tradeoff with each other (Barbacci et al., 1995)

11. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 11... And with business qualities Low cost Short time-to-market High quality Inexpensive; lower quality; longer time-to-market More expensive; moderate quality; moderate time-to-market Expensive; high quality; longer time-to-market (Rozanski and Woods, 2005)

12. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 12 Challenge: QA requirements  Three typical situations in companies 1. QA requirements are not explicitly recorded, but exist as domain knowledge in employees’ heads 2. QA requirements are explicitly recorded, but not in a verifiable manner  Symptoms  ”The system shall be robust.”  ”The system shall be highly modifiable.”  ”The system shall be secure from unauthorised break-in.”  ”The system shall exhibit acceptable performance.”  Scenarios are a good way of concretising QA requirements!

13. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 13 Challenge: QA requirements 3. QA requirements are recorded as solutions  Symptoms  ”System shall use IPsec for point-to-point communication.”  ”System shall use 4-digit PINs as passwords.”  Benefit: easy to understand and implement  Drawbacks  Do we understand the user needs properly?  How do we keep track when user needs or available solutions change?  Do we know enough to justify the solution at the requirements level, when other solutions are still open?

14. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 14 Quality Attributes Concepts and classifications

15. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 15 Diversity of quality attributes Reliability Interoperability Performance Usability Scalability Security Availability Maintainability Modifiability Testability Safety Survivability Confidentiality Portability Dependability Timeliness Integrity ? Fault-tolerance Robustness

16. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 16 Quality attribute, quality property  Often used as synonyms  IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990)  Quality attribute: A feature or characteristic that affects an item’s quality  Quality: (1) The degree to which a system, component, or process meets specified requirements (2) The degree to which a system, component, or process meets customer or user needs and expectations  A quality property is an externally visible, non-functional property of a system such a performance, security, or scalability (Rozanski & Woods, 2005).

17. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 17 Using classifications for defining QAs  Previous definitions are perhaps not self-explanatory  Quality attributes are often defined by enumerating and classifying them, and then giving more concrete definitions to sub-attributes  Different classifications exist  However, classifications are not unambiguous  Is availability a characteristic of security or reliability?  Classifications are good for increasing our understanding, not so good for dividing things cleanly into separate containers

18. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 18 ISO/IEC 9126 Quality model for internal and external attributes

19. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 19 ISO/IEC 9216 Quality model framework process quality internal quality attributes external quality attributes quality in use attributes process measures internal measures external measures quality in use measures ProcessSoftware product Effect of software product influences depends on contexts of use

20. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 20 Classification of Bass et al., 2003  System quality attributes  Observable via execution  Performance, security, reliability, usability, etc.  Not observable via execution  Maintainability, testability, portability, etc.  These classes behave quite differently!  Other qualities not related to the external properties of the system  Business quality  Cost, time-to-market, etc.  Quality of the architecture  Conceptual integrity, buildability, etc.

21. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 21 Classification of dependability and security  An integration of dependability and security (Avizienis et al., 2004)  Stems from decades of work within dependability and security community  Is based on the idea that both have similar threats and can be achieved with similar means  Faults, errors and failures Confidentiality Maintainability Integrity Safety Availability Reliability Dependability Security

22. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 22 Quality Attributes QAs in architecture design

23. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 23 QAs in architecture design Requirements Scenarios Means of achieving Tactics, patterns Pitfalls, antipatterns Design decisions Documented using architectural views Technologies Styles, patterns Architecture design process Activities, checklists

24. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 24 Perspectives and quality attributes  Perspectives collect many of the items in the previous slide into one knowledge pool  An architectural perspective  consists of activities, tactics, pitfalls, checklists  aims to ensure the achievement of a particular quality attribute or cross-cutting concern  Many quality attributes span across many arhitectural views  Motivation for perspectives

25. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 25 Summary  Quality attributes form an important part of software architects’ work  Next week, we will go through individual quality attributes and discuss  What they are  How to specify them  How to achieve them  How to apply perspectives to views are discussed later

26. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 26 References Avizienis, Algirdas; Laprie, Jean-Claude; Randell, Brian and Landwehr, Carl. Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 2004. Barbacci, Mario; Longstaff, Thomas; Klein, Mark and Weinstock, Charles. Quality Attributes. SEI Technical Report CMU/SEI-95-TR-021. 1995. Bass, Len; Clements, Paul and Kazman, Rick. Software Architecture in Practice. 2nd edition. Addison- Wesley, 2003. Folmer, Eelke and Bosch, Jan. Architecting for Usability: A Survey. Journal of Systems and Software 70, 2004. IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology. 1990. ISO/IEC 15408-1. Information technology – Security techniques – Evaluation criteria for IT security – Part 1: Introduction and general model. ISO/IEC Standard 15408-1, 1999. ISO/IEC 9126-1. Software engineering – Product quality – Part 1: Quality model. ISO/IEC Standard 9126-1:2001, 2001. Matinlassi, Mari and Niemelä, Eila. The Impact of Maintainability on Component-based Software Systems. Proc. of EUROMICRO Conference (EUROMICRO’03). 2003. Rozanski, Nick and Woods, Eoin. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2005. Sommerville, Ian. Software Engineering. 7th edition. Addison-Wesley, 2004.