Quality Attributes in Software Architecture
If you are trying to architect a green field software product or project, the quality attributes of the software are one of the major attribute that you need to consider. What are the software quality attributes ?
A quality attribute is a measurable or testable property of a system that is used to indicate how well the system satisfy the needs of stakeholders.
The most commons software quality attributes are as follows.
The ISO25010 standard specifies the software quality attributes as follows.
We will discuss each of these attributes in-detail in preceding posts. This post is mainly focusing on describe the general specifications of software quality attributes.
The software quality attributes can be dissected into main two parts.
- Quality Attributes that are describes system’s runtime property : These are attributes such as availability , usability , performance etc..
- Quality attributes that are describes the development of the system : These attributes are such as modifiability and testability.
Quality Attribute Considerations
The quality attributes are not standing alone. Mainly those are tightly coupled with required functionality and other architectural constraints. As an example if there is a requirement like “When user clicks the load button, all customers should get loaded into the page”. So the requirement should define “how soon” this data loading should happen. So this requirement is tightly coupled with the performance quality attribute. Might be coupled with scaling as well if our system is going to be a distributed one.
Within complex systems, quality attributes can never be achieved in isolation. The achievement of any one will have an effect, sometimes positive and sometimes negative, on the achievement of others. For example, almost every quality attribute negatively affects performance. Take portability. The main
technique for achieving portable software is to isolate system dependencies, which introduces overhead into the system’s execution, typically as process or procedure boundaries, and this hurts performance.
A quality attribute requirement should be very clear and testable. We can identify the following as quality attribute stimulus.
Stimulus : A stimulus can be defined as an event or input to a system. The stimulus can be an event to the performance community, a user operation to the usability community, or an attack to the security community. We use the same term to describe a motivating action for developmental qualities. Thus, a stimulus for modifiability is a request for a modification; a stimulus for testability is the completion of a phase of development.
Stimulus Source : Stimulus source is where the event or the input originated. This could be from a system’s user or another system’s output as well.
Response to Stimulus : The response consists of the responsibilities that the system (for runtime qualities) or the developers (for development-time qualities) should perform in response to the stimulus.For example, in a performance scenario, an event arrives (the stimulus) and the system should process that event and generate a response. In a modifiability scenario, a request for a modification arrives (the stimulus) and the developers should implement the modification without side effects and then test and deploy the modification.
Response measure : This attribute is the check whether the response to the Stimulus if satisfactory or not. As an example, is the response to the request is correct, if its correct does it satisfied the latency threshold. Are the security measures of the request is achieved etc..
Environment : The environment of a requirement is the set of circumstances in which the scenario takes place. The environment acts as a qualifier on the stimulus. For example, a request for a modification that arrives after the code has been frozen for a release may be treated differently than one that arrives before the freeze.
Artifact : Artifact is the portion of the system to which the requirement applies.
The following diagram depicts how quality attribute considerations are associate with each other.
According to this definition, the response is the ultimate outcome of a stimulus. So how can we achieve a “good” response in the context of the system that we are going to design ?
This can be achieved applying tactics to the environment or to the artifact for a given stimulus. So what are those tactics? There can be vary from well defined design/architectural patterns or some solution very specific to your solution. Hence these tactics can be easily lead into design decisions.
Following are some guides to quality design decisions which can be applied to select a better tactic for a given quality attributes’s stimulus.
- Allocation of responsibilities
- Coordination model
3. Data model
4. Management of resources
5. Mapping among architectural elements
6. Binding time decisions
7. Choice of technology
These categories are not the only way to classify architectural design decisions, but they do provide a rational division of concerns. These categories might overlap, but it’s all right if a particular decision exists in two different categories, because the concern of the architect is to ensure that every important decision is considered.
Stay tuned for detailed discussions of Software Quality attributes.
Reference : Software Architecture in Practice
