Quality Attributes

Architecture and Quality Attributes

Achieving quality attributes must be considered throughout design, implementation, and
deployment. No quality attribute is entirely dependent on design, nor is it entirely
dependent on implementation or deployment. Satisfactory results are a matter of getting
the big picture (architecture) as well as the details (implementation) correct. For example:

 Usability involves both architectural and nonarchitectural aspects. The nonarchitectural

aspects include making the user interface clear and easy to use. Should you provide a
radio button or a check box? What screen layout is most intuitive? What typeface is
most clear? Although these details matter tremendously to the end user and influence
usability, they are not architectural because they belong to the details of design.
Whether a system provides the user with the ability to cancel operations, to undo
operations, or to re-use data previously entered is architectural, however. These
requirements involve the cooperation of multiple elements.

 Modifiability is determined by how functionality is divided (architectural) and by coding

techniques within a module (nonarchitectural). Thus, a system is modifiable if changes
involve the fewest possible number of distinct elements.

 Performance involves both architectural and nonarchitectural dependencies. It depends

partially on how much communication is necessary among components (architectural),
partially on what functionality has been allocated to each component (architectural),
partially on how shared resources are allocated (architectural), partially on the choice of
algorithms to implement selected functionality (nonarchitectural), and partially on how
these algorithms are coded (nonarchitectural).

The message of this section is twofold:

1. Architecture is critical to the realization of many qualities of interest in a system, and

these qualities should be designed in and can be evaluated at the architectural level.

2. Architecture, by itself, is unable to achieve qualities. It provides the foundation for

achieving quality, but this foundation will be to no avail if attention is not paid to the
details.
Let's begin our tour of quality attributes. We will examine the following three classes:

1. Qualities of the system. We will focus on availability, modifiability, performance,

security, testability, and usability.

2. Business qualities (such as time to market) that are affected by the architecture.

3. Qualities, such as conceptual integrity, that are about the architecture itself although
they indirectly affect other qualities, such as modifiability.

System Quality Attributes

System quality attributes have been of interest to the software community at least since the
1970s. There are a variety of published taxonomies and definitions, and many of them have
their own research and practitioner communities. From an architect's perspective, there are
three problems with previous discussions of system quality attributes:

 The definitions provided for an attribute are not operational. It is meaningless to say
that a system will be modifiable. Every system is modifiable with respect to one set of
changes and not modifiable with respect to another. The other attributes are similar.

 A focus of discussion is often on which quality a particular aspect belongs to. Is a system
failure an aspect of availability, an aspect of security, or an aspect of usability? All three
attribute communities would claim ownership of a system failure.

 Each attribute community has developed its own vocabulary. The performance
community has "events" arriving at a system, the security community has "attacks"
arriving at a system, the availability community has "failures" of a system, and the
usability community has "user input." All of these may actually refer to the same
occurrence, but are described using different terms.

QUALITY ATTRIBUTE SCENARIOS

A quality attribute scenario is a quality-attribute-specific requirement. It consists of six
parts.

 Source of stimulus. This is some entity (a human, a computer system, or any other
actuator) that generated the stimulus.

 Stimulus. The stimulus is a condition that needs to be considered when it arrives at a

 system.

 Environment. The stimulus occurs within certain conditions. The system may be in an
overload condition or may be running when the stimulus occurs, or some other condition
may be true.

 Artifact. Some artifact is stimulated. This may be the whole system or some pieces of it.

 Response. The response is the activity undertaken after the arrival of the stimulus.

Response measure. When the response occurs, it should be measurable in some fashion
so that the requirement can be tested.

Quality attribute parts

Quality Attribute Scenarios in Practice

General scenarios provide a framework for generating a large number of generic, system- independent, quality-
attribute-specific scenarios. Each is potentially but not necessarily relevant to the system you are concerned with.
To make the general scenarios useful for a particular system, you must make them system specific.
We now discuss the six most common and important system quality attributes, with the twin goals of identifying
the concepts used by the attribute community and providing a way

to generate general scenarios for that attribute.

AVAILABILITY

MODIFIABILITY

PERFORMANCE

SECURITY

TESTABILITY

USABILITY

Achieving Qualities
Introducing Tactics
Availability Tactics
Modifiability Tactics
Performance Tactics
Security Tactics
Testability Tactics
Usability Tactics
Relationship of Tactics to Architectural Patterns

INTRODUCTION TACTICS

A tactic is a design decision that influences the control of a quality attribute

response. A system design consists of a collection of decisions. Some of these
decisions help control the quality attribute responses; others ensure achievement of
system functionality. The tactics are those that architects have been using for years,
and we isolate and describe them. We are not inventing tactics here, just capturing
what architects do in practice.
 Tactics are intended to control responses to stimuli.

Each tactic is a design option for the architect. For example, one of the tactics introduces redundancy to increase
the availability of a system. This is one option the architect has to increase availability, but not the only one. Usually
achieving high availability through redundancy implies a concomitant need for synchronization (to ensure that the
redundant copy can be used if the original fails). We see two immediate ramifications of this example.

1. Tactics can refine other

tactics. 2.Patterns package

tactics.

Availability Tactics
Goal of availability tactics

Many of the tactics we discuss are available within standard execution environments such as
operating systems, application servers, and database management systems. It is still
important to understand the tactics used so that the effects of using a particular one can be
considered during design and evaluation. All approaches to maintaining availability involve
some type of redundancy, some type of health monitoring to detect a failure, and some
type of recovery when a failure is detected.
 Summary of availability tactics

Modifiability Tactics
We organize the tactics for modifiability in sets according to their goals. One set has as its
goal reducing the number of modules that are directly affected by a change. We call this set
"localize modifications." A second set has as its goal limiting modifications to the localized
modules. We use this set of tactics to "prevent the ripple effect." Implicit in this distinction
is that there are modules directly affected (those whose responsibilities are adjusted to
accomplish the change) and modules indirectly affected by a change (those whose
responsibilities remain unchanged but whose implementation must be changed to
accommodate the directly affected modules). A third set of tactics has as its goal controlling
deployment time and cost. We call this set "defer binding time."

Goal of modifiability tactics

9
Performance Tactics
the goal of performance tactics is to generate a response to an event arriving at the system
within some time constraint. The event can be single or a stream and is the trigger for a
request to perform computation. It can be the arrival of a message, the expiration of a time
interval, the detection of a significant change of state in the system's environment, and so
forth. The system processes the events and generates a response. Performance tactics
control the time within which a response is generated. This is shown in Figure 5.6. Latency
is the time between the arrival of an event and the generation of a response to it.

Goal of performance tactics

Summary of performance tactics

Security Tactics
Tactics for achieving security can be divided into those concerned with resisting attacks,
those concerned with detecting attacks, and those concerned with recovering from attacks.
All three categories are important. Using a familiar analogy, putting a lock on your door is a
form of resisting an attack, having a motion sensor inside of your house is a form of
detecting an attack, and having insurance is a form of recovering from an attack. Figure 5.8
shows the goals of the security tactics.

. Goal of security tactics

Summary of tactics for security

Testability Tactics
The goal of tactics for testability is to allow for easier testing when an increment of software
development is completed. Figure 5.10 displays the use of tactics for testability.
Architectural techniques for enhancing the software testability have not received as much
attention as more mature fields such as modifiability, performance, and availability, but, as
we stated in Chapter 4, since testing consumes such a high percentage of system
development cost, anything the architect can do to reduce this cost will yield a significant
benefit.

Goal of testability tactics

Summary of testability tactics

Usability Tactics
usability is concerned with how easy it is for the user to accomplish a desired task and the kind of support the
system provides to the user. Two types of tactics support usability, each intended for two categories of "users." The
first category, runtime, includes those that support the user during system execution. The second category is based
on the iterative nature of user interface design and supports the interface developer at design time. It is strongly
related to the modifiability tactics already presented.
Goal of runtime usability tactics
Summary of runtime usability tactics