Bass.

book Page 3 Thursday, March 20, 2003 7:21 PM

1
4
The Architecture
Understanding Quality
Attributes
Business Cycle
Between
Simply stated,stimulus and response,
competitive theretoisthe
success flows a space.
companyIn
that space is our power to choose our response.
that manages to establish proprietary architectural control In
our response
over lies
a broad, our growthcompetitive
fast-moving, and our freedom.
space.
Man’s
— C. Morris and Search for
C. Ferguson Meaning
[Morris 93]

For decades, software designers have been taught to build systems based exclu--
sively on the technical requirements. Conceptually, the requirements document is
tossed over the wall into the designer’s cubicle, and the designer must come forth-
with a satisfactory design. Requirements beget design, which begets system. Of-
course, modern software development methods recognize the naïveté of this
model and provide all sorts of feedback loops from designer to analyst. But they
still make the implicit assumption that design is a product of the system’s techni--
cal requirements, period.
Architecture has emerged as a crucial part of the design process and is the
subject of this book. Software architecture encompasses the structures of large
software systems. The architectural view of a system is abstract, distilling away
details of implementation, algorithm, and data representation and concentrating
on the behavior and interaction of “black box” elements. A software architecture
is developed as the first step toward designing a system that has a collection of
desired properties. We will discuss software architecture in detail in Chapter 2.
For now we provide, without comment, the following definition:
-
The software architecture of a program or computing system is the structure
or structures of the system, which comprise software elements, the externally
visible properties of those elements, and the relationships among them.
Chapter 2 will provide our working definitions and distinguish between archi-
tecture and other forms of design. For reasons we will see throughout, architecture
serves as an important communication, reasoning, analysis, and growth tool for
■
-
systems. Until now, however, architectural design has been discussed in the

633
64 Part Two Quality Attributes 4—Understanding Quality Attributes

4.1 Architecture and Requirements

-
architecturally significant requirement -

Functional requirements.

Quality attribute requirements.

limitation on operational costs.

-
-

-
-

more detail.
 4.3 Quality Attribute Considerations 65

4.2 Functionality

elements.

-
-

-
-

4.3 Quality Attribute Considerations

-
66 Part Two Quality Attributes 4—Understanding Quality Attributes

Functional Requirements
After more than 15 years of writing and discussing the distinction between
functional requirements and quality requirements, the definition of func-
tional requirements still eludes me. Quality attribute requirements are well
defined: performance has to do with the timing behavior of the system,
modifiability has to do with the ability of the system to support changes in
its behavior or other qualities after initial deployment, availability has to do
with the ability of the system to survive failures, and so forth.
Function, however, is much more slippery. An international standard
(ISO 25010) defines functional suitability as “the capability of the software
product to provide functions which meet stated and implied needs when
the software is used under specified conditions.” That is, functionality is the
ability to provide functions. One interpretation of this definition is that func-
tionality describes what the system does and quality describes how well
the system does its function. That is, qualities are attributes of the system
and function is the purpose of the system.
This distinction breaks down, however, when you consider the nature
of some of the “function.” If the function of the software is to control engine
behavior, how can the function be correctly implemented without consid-
ering timing behavior? Is the ability to control access through requiring a
user name/password combination not a function even though it is not the
purpose of any system?
I like much better the use of the word “responsibility” to describe com-
putations that a system must perform. Questions such as “What are the
timing constraints on that set of responsibilities?”, “What modifications are
anticipated with respect to that set of responsibilities?”, and “What class of
users is allowed to execute that set of responsibilities?” make sense and
are actionable.
The achievement of qualities induces responsibility; think of the user
name/password example just mentioned. Further, one can identify respon-
sibilities as being associated with a particular set of requirements.
So does this mean that the term “functional requirement” shouldn’t be
used? People have an understanding of the term, but when precision is
desired, we should talk about sets of specific responsibilities instead.
Paul Clements has long ranted against the careless use of the term
“nonfunctional,” and now it’s my turn to rant against the careless use of the
term “functional”—probably equally ineffectually.
—LB
 4.3 Quality Attribute Considerations 67

-
-

quality attribute scenarios -

-
-

-
68 Part Two Quality Attributes 4—Understanding Quality Attributes

4.4 Specifying Quality Attribute Requirements

■
Stimulus.

development.
■
Stimulus source. -
-

■
Response.

■
Response measure.

■
Environment.
 4.4 Specifying Quality Attribute Requirements 69

component.
■
Artifact.
-

is relevant.

Source of stimulus.

Stimulus. -
rives at a system.
Environment.
-
-

Artifact.

Response.

Response measure.

general

concrete -

-
70 Part Two Quality Attributes 4—Understanding Quality Attributes

1
2
Artifact
Stimulus Response 3
4
Environment Response
Source
of Stimulus Measure

FIGURE 4.1 The parts of a quality attribute scenario

Artifact
Processors, 1
communication 2
Stimulus channels, persistent Response 3
Fault: storage, processes Prevent fault from 4
omission, becoming failure
Source crash, Environment Detect fault: log, notify Response
of Stimulus incorrect Normal operation, Recover from fault: Measure
Internal/External: timing, startup, shutdown, disable event source, Time or time interval
people, hardware, incorrect repair mode, be unavailable, system must be available
software, physical response degraded fix/mask, degraded Availability percentage
infrastructure, operation, mode Time in degraded mode
physical overloaded Time to detect fault
environment operation Repair time
Proportion of faults
system handles

FIGURE 4.2 A general scenario for availability

4.5 Achieving Quality Attributes through Tactics

achieve -
architectural tactics.
 4.5 Achieving Quality Attributes through Tactics 71

Not My Problem
One time I was doing an architecture analysis on a complex system cre-
ated by and for Lawrence Livermore National Laboratory. If you visit their
website (www.llnl.gov) and try to figure out what Livermore Labs does, you
will see the word “security” mentioned over and over. The lab focuses on
nuclear security, international and domestic security, and environmental
and energy security. Serious stuff . . .
Keeping this emphasis in mind, I asked them to describe the quality
attributes of concern for the system that I was analyzing. I’m sure you can
imagine my surprise when security wasn’t mentioned once! The system
stakeholders mentioned performance, modifiability, evolvability, interoper-
ability, configurability, and portability, and one or two more, but the word
security never passed their lips.
Being a good analyst, I questioned this seemingly shocking and obvious
omission. Their answer was simple and, in retrospect, straightforward: “We
don’t care about it. Our systems are not connected to any external net-
work and we have barbed-wire fences and guards with machine guns.” Of
course, someone at Livermore Labs was very interested in security. But it
was clearly not the software architects.
—RK

-
72 Part Two Quality Attributes 4—Understanding Quality Attributes

Tactics
to Control
Stimulus Response Response

FIGURE 4.3 Tactics are intended to control responses to stimuli.

-
Schedule resources

Use an intermediary
-

-
Manage sampling rate is relevant in some real-time systems

4.6 Guiding Quality Design Decisions