Software Architecture in Practice

Part Two:
Creating an Architecture

2nd Ed.
Len Bass, Paul Clements, Rick Kazman
 Chapter 4:
Understanding Quality Attributes
• ABC: business considerations determine qualities
that must be accommodated in a system’s
architecture.
• Systems are frequently redesigned not because
they’re functionally deficient - the replacements are
often functionally identical - but because they are
difficult to maintain, port, or scale, or are too slow, or
have been compromised by network hackers.

2
Functionality, Architecture, and Quality
Attributes

• Functionality and quality attributes are

orthogonal.
• Achieving quality attributes must be
considered throughout design,
implementation, and deployment.
• Satisfactory results depend on getting the big
picture (architecture) & the details
(implementation) right.
3
Functionality, Architecture, and Quality
Attributes
• Ex: Performance depends partially on
– how much communication is necessary among
components (Arch)
– what functionality has been allocated to each component
(Arch)
– how shared resources are allocated (Arch)
– the choice of algorithms to implement selected
functionality (Non-arch)
– how these algorithms are coded (Non-arch)

4
 Key Message
• Architecture is critical to deliver quality
requirements, and these qualities should be designed
in and can be evaluated at the architectural level.
• Architecture, by itself, is unable to achieve qualities -
attention must be paid to the details.
• Within complex systems, quality attributes can never
be achieved in isolation. The achievement of one
will have an effect, positive or negative, on others.

5
 Classes of Quality Attributes

• Qualities of the system

– availability, modifiability, performance, security,
testability, and usability.
• Business qualities
– time to market, cost & benefit, projected life,
target market, rollout schedule, legacy integration.
• Architectural qualities
– conceptual integrity, correctness & completeness,
buildability 6
 System Quality Attributes
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.
A solution to the first two of these problems (nonoperational definitions and overlapping
attribute concerns) is to use quality attribute scenarios as a means of characterizing quality
attributes. A solution to the third problem is to provide a brief discussion of each
attribute—concentrating on its underlying concerns—to illustrate the concepts that are
fundamental to that attribute community. 7
Quality Attribute Scenarios

Figure 4.1

8
 A QA-specific Requirement
• Source of stimulus - generating entity
• Stimulus - arriving condition needing consideration
• Environment - system condition
• Artifact - part of or entire system
• Response - activity caused by the stimulus
• Response measure - measurable results that tests the
requirements

9
10
Modifiability Scenario

11
 QUALITY ATTRIBUTE
SCENARIO GENERATION

• In theory this is done in a project's

requirements elicitation, but in practice this
is seldom rigorously enforced.
• We remedy this situation by generating
concrete quality attribute scenarios.
• we use the quality-attribute-specific tables
to create general scenarios and from these
derive system-specific scenarios.
12
 Quality Attribute Scenarios in Practice

• To make the general scenarios useful for a

particular system, you must make them system
specific.
• A general scenario is "A request arrives for a
change in functionality, and the change must be
made at a particular time within the development
process within a specified period." A system-
specific version might be "A request arrives to add
support for a new browser to a Web-based system,
and the change must be made within two weeks."
13
 AVAILABILITY
• Availability is concerned with system failure and its
associated consequences. A system failure occurs when the
system no longer delivers a service consistent with its
specification.
• Among the areas of concern are how system failure is
detected, how frequently system failure may occur, what
happens when a failure occurs, how long a system is
allowed to be out of operation, when failures may occur
safely, how failures can be prevented, and what kinds of
notifications are required when a failure occurs.

14
 failures and faults

• A fault may become a failure if not

corrected or masked. That is, a failure is
observable by the system's user and a fault
is not. When a fault does become
observable, it becomes a failure. For
example, a fault can be choosing the wrong
algorithm for a computation, resulting in a
miscalculation that causes the system to fail.
15
 Time to repair

• Once a system fails, an important related

concept becomes the time it takes to repair it.
Since a system failure is observable by users,
the time to repair is the time until the failure
is no longer observable. This may be a brief
delay in the response time or it may be the
time it takes someone to fly to a remote
location in the mountains of Peru to repair a
piece of mining machinery
16
• The availability of a system is the
probability that it will be operational when
it is needed

17
 Availability General Scenarios

• Already discussed

18
 Failure classes

- omission. A component fails to respond to

an input.
- crash. The component repeatedly suffers
omission faults.
- timing. A component responds but the
response is early or late.
- response. A component responds with an
incorrect value.
19
20
 MODIFIABILITY

• Modifiability is about the cost of change. It

brings up two concerns.
• What can change (the artifact)?
• When is the change made and who makes it
(the environment)?

21
 Modifiability General Scenarios
• Source of stimulus. This portion specifies who makes the
changes—the developer, a system administrator, or an end user.
Clearly, there must be machinery in place to allow the system
administrator or end user to modify a system, but this is a
common occurrence. In Figure 4.4, the modification is to be
made by the developer.
• Stimulus. This portion specifies the changes to be made. A
change can be the addition of a function, the modification of an
existing function, or the deletion of a function. It can also be
made to the qualities of the system—making it more responsive,
increasing its availability, and so forth. The capacity of the
system may also change. Increasing the number of simultaneous
users is a frequent requirement. In our example, the stimulus is a
request to make a modification, which can be to the function,
quality, or capacity. 22
• Artifact. This portion specifies what is to be changed—the functionality
of a system, its platform, its user interface, its environment, or another
system with which it interoperates. In Figure 4.4, the modification is to the
user interface.
• Environment. This portion specifies when the change can be made—
design time, compile time, build time, initiation time, or runtime. In our
example, the modification is to occur at design time.
• Response. Whoever makes the change must understand how to make it,
and then make it, test it and deploy it. In our example, the modification is
made with no side effects.
• Response measure. All of the possible responses take time and cost
money, and so time and cost are the most desirable measures. Time is not
always possible to predict, however, and so less ideal measures are
frequently used, such as the extent of the change (number of modules
affected). In our example, the time to perform the modification should be
less than three hours. 23
24
 Performance (p. 82)
• Performance is about timing:
– interrupts, messages, requests from users, or the passage of
time
– basically: how long it takes the system to respond when an
event occurs
• Complexity:
– number of event sources & arrival patterns
– this characterization is the language to construct general
performance scenarios

25
 Performance Scenarios
• Performance Scenarios:
– Start with a request for service arriving at the system.
Satisfying the request consumes resources. Usually
events are handled in parallel.
• Arrival Patterns:
– periodic - most often seen in real-time systems
– stochastic - events arrive according to some
probabilistic distribution
– sporadic - a pattern that can’t be represented by either

26
Sample Performance Scenario

Figure 4.5

27
 General Scenarios

Table 4.3

28
 Usability (p. 90)

• How easy is it for the user to accomplish a

desired task & what kind of user support
does the system provide.
– Learning system features
– Using a system efficiently
– Minimizing the impact of errors
– Adapting the system to user needs
– Increasing confidence & satisfaction
29
Sample Usability Scenario

Figure 4.8

30
31
32
33
 Communicating Concepts
• Each attribute community has its own vocabulary;
different terms can mean the same thing.
• The problem is for the architect to understand
which stimuli represent the same occurrence,
which are aggregates of other stimuli, and which
are independent.
– Ex: a performance event may be atomic or an aggregate
of other lower-level occurrences.

34
 General Scenarios

Table 4.7

35
Exercise: Quality attribute scenarios

• Time: 15 minutes, 10 minutes discussion

• Exercise:
– Select two types of the "General Scenario"
from the tables 4.1-4.6. Create a concrete
scenario for each using the class project. Use
something other than the Examples on pp. 76-
77.
• Reference: Bass pp 75-94
36
 Exercise: Quality Attributes

• Refer to the Bookstore Requirement Spec

handout
• Following the Quality Attribute Workshop
handout’s process:
– Define the high level quality attributes
– Define the key quality attribute scenarios

37
 Chapter 5:
Achieving Qualities
• The tactics used by the architect to create a design
using design patterns, architectural patterns, or
architectural strategies.
• An architectural pattern or strategy implements a
collection of tactics.

38
 Introducing Tactics
• A tactic is a design decision that influences the
control of a quality attribute response.
• A collection of tactics is an architectural strategy
(more in Ch. 12).
• Tactics can refine other tactics: redundancy can be
refined into data or computational redundancy.
• Patterns package tactics: an availability pattern
uses both redundancy & synchronization tactics.

39
 Availability Tactics
• Fault Detection
– Ping/echo
– Heartbeat
– Exceptions
• Fault Recovery
– Voting – space shuttle
– Active redundancy (hot restart)
– Passive redundancy (warm restart)
– Spare
– Shadow operation • Fault Prevention
– State synchronization – Removal from service
– Checkpoint/rollback – Transactions
– Process monitor
40
 Modifiability Tactics
• Localize modifications
– Maintain semantic coherence
– Anticipate expected changes
– Generalize the module
– Limit possible options

41
 Modifiability, con’t
• Prevent Ripple Effects
– There are eight types of dependencies:
1. Syntax of data and service
2. Semantics of data and service
3. Sequence of data and control
4. Identity of an interface of A
5. Location of A (runtime)
6. Quality of service/data provided by A
7. Existence of A
8. Resource behavior of A

42
 Ripple Effects, con’t

• Hide information
• Maintain existing interfaces
– Adding interfaces
– Adding adapter
– Providing a stub A
• Restrict communication paths
• Use an intermediary
– Data (syntax)
– Service (syntax)
– Identity of an interface of A
– Location of A (runtime)
– Resource behavior of A or Resource controlled by A
– Existence of A

43
 Modifiability, con’t
• Defer Binding Time
– Runtime registration
– Configuration files
– Polymorphism
– Component replacement
– Adherence to defined protocols

44
General Definition & Performance

Definition of tactics

Performance tactics (p. 111)

45
 Performance Tactics
• The goal is to generate a response to an arriving
event within some time constraint.
– Event: single or stream; message, expiration of a time
interval, detection of a state change, etc.
• Performance tactics control the time within which
a response is generated.
• Latency is the time between the arrival of an event
& the generation of a response.

46
 Response Time
• Two basic contributors:
– resource consumption
• CPU, data stores, network communication bandwidth,
memory, buffers, etc.
– blocked time
• contention for resources
• availability of resources
• dependency on other computation

47
 Resource Demand
• Event streams are the source of resource demand.
• Two characteristics:
– time between events in a stream
– how much of a resource is consumed by each request
• Tactic: reduce resources required to process an
event stream
– increase computational efficiency
– reduce computational overhead

48
 Resource Demand, con’t
• Tactic: reduce the number of events processed
– manage event rate
– control frequency of sampling
• Tactic: control use of resources
– bound execution times
– bound queue lengths

49
 Resource Management
• If the demand for resources isn’t controllable, they
might be managed by these tactics:
– introduce concurrency
– maintain multiple copies of either data or computations
– increase available resources

50
 Resource Arbitration
• When there is contention for a resource, the
resource must be scheduled:
– processors, buffers, networks are all scheduled
• A scheduling policy has two parts:
– a priority assignment
– dispatching

51
 Common Scheduling Policies
• First-in/First-out all requests are equal
• Fixed-priority scheduling are prioritized based on:
– semantic importance - statically assigned based on
domain characteristics (mainframes)
– deadline monotonic - statically assigned with higher
priority to streams with shorter deadlines (real-time)
– rate monotonic - statically assigned with higher priority
to streams with shorter periods (real-time)

52
 Scheduling Policies, con’t
• Dynamic priority scheduling
– round robin
– earliest deadline first
• Static scheduling - cyclic executive schedule with
pre-emption points & sequence determined offline

53
Performance Tactic Hierarchy

Figure 5.7

54
 Additional Tactics
• Security
– Resisting attacks
– Detecting attacks
– Recovering from attacks
• Testability
– Input/Output
– Internal monitoring
• Usability
– Runtime
– Design-time

55
 Tactics & Patterns
• An architect usually chooses a pattern or collection of
patterns, but any pattern implements several tactics.
• Each of these is often concerned with different quality
attributes, & any implementation of the pattern makes
choices about tactics.
• So, the analysis process involves understanding all tactics
embedded in an implementation.
• The design process involves making a judicious choice of
what combination of tactics will achieve the system’s
desired goals.

56
 Patterns & Styles
• Key features & rules for combining them to
preserve architectural integrity:
– a set of element types
– a topological layout indicating their
relationships
– a set of semantic constraints
– a set of interaction mechanisms that determine
coordination

57
 Categorized Patterns

Figure 514

58
 Chapter 6:
Air Traffic Control
• One of the most demanding of software
applications:
– Hard real time – timing deadlines must be met
absolutely
– Safety critical – human lives at stake
– Highly distributed – dozens of controllers at
wide geographic locations
– Intense public visibility – multibillion dollar
investment of public funds
59
 ISSS
1. Ultrahigh availability - .99999 = unavailable for less than 5
minutes/year
2. High performance – process up to 2,440 aircraft without
“losing” any
3. Additional drivers:
• Openness – commercial components
• Designed for incremental deployment
• Modifiability in functionality and hardware upgrades
• Integratable with a bewildering set of external systems, some decades
old, others not yet built
• Users could reject delivery, even if operational requirements
were met!
60
 Views
• Physical view – hardware, networks, peripherals
(Figure 6.5)
• Module decomposition view – CSCIs based on
semantic coherence:
– Display Management
– Common System Services – abstract common services
– Recording, Analysis, and Playback – testing
– Two others

61
 Views, con’t
• Process view – uses several availability tactics:
– State resynchronization
– Shadowing
– Active redundancy
– Removal from service
• Layered view
• Fault tolerance view – C&C view identifying
exception handling and monitoring

62
 Code Template
• Has architectural implications:
– Simple to add new applications to the system
– Developers don’t need to know details of message-
handling
– Developers don’t ensure fault tolerance
• Details in Figure 6.10
• Refinement of the “abstract common services”
tactic.

63