Outline Overview and motivation Concepts and classifications Quality attributes in architecture design
Quality Attributes
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 - 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
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.
Dostları ilə paylaş: |