QAs in SA Context

In this section I discuss Quality Attribute (QA) standardisation, complexity, challenges, categorisations, sensitivity point, and trade-off in the context of Software Architecture (SA).

2.5.4.1 Complexity of quality attributes

During the 1970s, the software community already showed interest in quality attributes. Various taxonomies and definitions have been published, many of which have their own re- search and practitioner communities. Software quality is defined by the IEEE standard 1061 (IEEE 1998) as“the degree to which software possesses a desired combination of attributes.”. Different schools and standards have defined and categorised QAs. This variations of QAs def- initions and categorizations increase the complexity of the quality system.

According toBass et al.[2013], from an architect’s perspective, there are three problems of quality attribute descriptions:

1. Operational definitions for an attribute were not provided. Therefore, saying that a system is modifiable is rather non-significant. Specific systems may be modifiable with respect to one quality attribute but may not be modifiable to another.

2. Some relationships between quality attributes can fall under the same aspect. For example, a system failure can fall under several attributes, such as availability, security or usability, which make QAs categorisation more complex.

3. Each attribute community may consist of its own set of words that are understood by a specific (vocabulary). Also, the same occurrence may be called by different names in each community. For a given occurrence performance may call it “events, ” security will call it

2.5. EVALUATING SOFTWARE ARCHITECTURE

“attacks”, availability will call it “failures” while usability will call it “user input.” As all these refer to the same occurrence. This situation is ambiguous and confusing compara- tively.

Using quality attribute scenarios to characterise quality attributes to solve the first two prob- lems mentioned above (non-operational definitions and overlapping attribute concerns), is a so- lution proposed byBass et al. [2013]. To solve the third problem, a brief discussion of each attribute should be presented. To demonstrate the concepts which are fundamental to the at- tribute community, one must concentrate on each attribute’s fundamental concerns.

Judging architecture for suitability based on the names of the attributes is not sufficient. Requirement statements, such as:

• High security is required.

• The system shall exhibit acceptable performance.

If not elaborated, statements like these may be interpreted differently and misunderstood. Also, these interpenetrations could be based on different QAs categories and definitions, which existed as explained in Appendix C. Another aspect is how the current literature categorises them (QAs)? Is it based on the context of the problem, the interpretations of the quality attribute name, problem domain, different quality dependency trees, and/or categorizations?

Quality attributes are not absolute quantities. For example, a system should be protected from intrusions therefore a password is set to prevent unauthorised users from using the system. However, it does not have virus protection mechanisms which results in another kind of intru- sion. This illustrates that the existence of quality attributes is based on the context of specific goals.

2.5.4.2 Understanding quality attributes

The architecture of non-trivial systems determines its quality attributes. A statement of the quality attribute requirements motivated by key business goals and specification of archi- tecture is a prerequisite of an evaluation. This prerequisite is often unmet. Quality attribute requirements and architecture documentation are commonly incomplete, vague and ambiguous therefore it is necessary to apply two main processes, in order to determine if the evaluation of architectural design decisions address the quality attribute requirements as follows:

1. A precise statement of quality attribute requirements must be elicited and refined 2. A precise statement of architectural design decisions must be elicited and refined.

For the purpose of this thesis, and to achieve (partially) the objectives of the two points above, the following are some suggestions to be applied:

• The evaluation of any quality attribute shall be based on:

– a known standardised definition for that QA;

– and identification of the metric input and output.

• The use of clear notations and standardised rich languages, such as (ACME and SysML), to create architectural models, shall help to make an accurate artefact with correct decisions. • The use of architectural frameworks guidelines such as (IEEE-42010 and DoDAF) for developing a new architecture, shall help during the development process, views, and the related entities, which need to be constructed.

Styles/Patterns could be utilized much better, if they were documented well. However, it is important to have clear and informative characterisations for each quality attribute since architecture evaluation focuses on them. Hence, the quality attribute requirements need to be concrete and measurable or at least observable during evaluation for adherence.

2.5.4.3 Quality attribute characterisations

The classification of QAs should follow a clear criteria, standards, and guidelines, in order to help different disciplines to communicate easier. The more clear descriptions as to how the categorization is done, the more the acceptance there will be, for the categorization schema. The advantages of codifying the relationship between architecture and quality attributes are to enhance the design and analysis process; reuse of existing analysis and determine tradeoffs explicitly by engineer; aids in reconfiguring architectures to provide specified levels of a quality attribute; and, to help in the new modelling and automation approaches to apply quality analysis. According toBass et al.[2013], every quality attribute has different considerations to be taken into account for its stimuli, responses, and the architectural decisions used by the design- ers. few examples are listed below:

Stimuli

• Modifiability – a change request

• Performance – the arrival of events at the system

• Availability – a fault occurring in some portion of the system

Responses

• Modifiability – person-days or -months required to make a requested change. • Security – intruders breaking into the system and what resources will be accessed.

Architectural decisions

• Performance – the allocation of processes to processors and priorities • Availability – replication and fault detection and failure protocols

The quality categorization table included in the database (Chapter 3) illustrates the differ- ences between quality attributes that are explained by three schools namely, ISO-9126, SEI, and POSA. While, Table 2.12 illustrates another three respected approaches (as examples), with three different views of quality characteristics (ISO/IEC 9126-1991, IEEE Standard 1061-1992, and FURPSI,Krasner[1999] andGrady[1992]).

2.5. EVALUATING SOFTWARE ARCHITECTURE

Table 2.12: Software quality characterisation,Futrell et al.2002. They are basically based on McCall Model (1977), which was developed based upon three objectives: to specify (Factors), to build (Criteria), and to control (Metrics).

Quality ISO /IEC IEEE Standard FURPSIKrasner1999 /

Characteristic 9126-1991 1061-1992 Grady1992

Efficiency

Time Behaviour X X (Time Economy)

Resource Utilisation X X (Resource Economy)

Functionality Accuracy X Adequacy X Compatibility X Completeness X Compliance X Correctness X X Customisability X Evolvability X Extensiveness X Interoperability X X Security X X Suitability X Value/Satisfaction X Integratability Applicability X Compatibility X Evolvability X Expressability X Integrity X Openness X

Quality of the Parts X

Requirements Enabler X Special Topics X Maintainability Analysability X Changeability X Correctability X Expandability X Stability X Testability X X Performance Time-Constrained X Resource-Constrained X Portability Adaptability X

Table 2.12: (continued)

Quality ISO /IEC IEEE Standard FURPSIKrasner1999 /

Characteristic 9126-1991 1061-1992 Grady1992 Installability X X Conformance X Hardware Independence X Software Independence X Reusability X Replaceability X Reliability Availability X X Failure Rate X Fault tolerance X X X Maturity X Nondeficiency X Recoverability X X Supportability Maintainable X Reusable X Support Response X Testable X Usability Understandability X X X

Learnability X X X (Easy to Learn and Use)

Communicativeness X X

Operability X X X (Easy to Operate)

Key – X: included in the standard

2.5.4.4 Sensitivity points and trade-off points

According toBass et al.[2013], the key architectural decisions are sensitivity points and trade-off points. An architectural decision that has elements that are parts of two or more ar- chitectural components is calleda sensitivity point. These components are critical in accom- plishing a specific quality attribute response measure. The response measure is sensitive for changing the decision. For example,certain levels of encapsulation determine the length and scale of effort in person-days that is required to maintain a specific system.

When an architect, a designer, or analyst tries to comprehend the achievement of a quality goal, they identify where to focus their attention through the help of sensitivity points.

A trade-off pointis an architectural decision that affects more than one attribute by some other attributes, and sensitivity points as well. For example, security and performance can be greatly influenced by changing the level of encryption the predicted security can be improved by increasing the level of encryption but processing time can take longer than usual. An example