T-76. 5150 Software Architectures Introduction to quality attributes

T-76.5150 Software Architectures

• Introduction to quality attributes

Outline

• Overview and motivation

• Concepts and classifications

• Quality attributes in architecture design

Quality Attributes

• Overview and motivation

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?

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…?

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

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)

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

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

Challenge: QAs can be in tradeoff with each other

... And with business qualities

Challenge: QA requirements

• Three typical situations in companies

• QA requirements are not explicitly recorded, but exist as domain knowledge in employees’ heads

• 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!

Challenge: QA requirements

• 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?

Quality Attributes

• Concepts and classifications

Diversity of quality attributes

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).

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

ISO/IEC 9126 Quality model for internal and external attributes

ISO/IEC 9216 Quality model framework

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.

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

Quality Attributes

• QAs in architecture design

QAs in architecture design

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

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

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.