Quality Attributes
Or, what’s wrong with this:
Exterminator kit – place bug on
block, strike with mallet
Functionality vs Quality Attributes
Quality
Functionality
Some Qualities
Usability
Modifiability
Performance
Security
Testability
Availability
Time to market
Cost and benefit
Projected System
lifetime
Targeted Market
Rollout Schedule
Integration / Legacy
Architectural Qualities
Conceptual Integrity
Correctness and Completeness
Buildability
Qualities & Trade-offs
The qualities are all good
The qualities value is project specific
The qualities are not independent
Quality Attribute Scenarios
Source of stimulus
Stimulus
Environment
Artifact
Response
Response measure
In the environment,
the source throws the
stimulus and hits the
(see inside front cover) system in the artifact
Example from cars
Stimulus:
Bumps
Source of stimulus:
Road
Artifact:
Tires
Environment:
Highway driving
Response
Measure:
Deflection < N%
Noise < M dB
…
Response:
Control maintained
Smooth ride
Low noise
Remember
One stimulus per scenario
One environment per scenario
One artifact per scenario
Multiple response measures are OK
Example from software
Artifact:
User
interface
Response
Measure: No
unauthorized
users,
login < 1 min
Stimulus:
Dozens of
simultaneous Environment:
Normal
logins
operation
Response:
Source of stimulus:
Security maintained
Shift change
Acceptable delays
If you remember one thing …
To be effective, quality attribute scenarios
must be testable

(just like any other requirement)
Therefore, the
Stimulus
 Artifact
 Environment
 Response measure(s)
must be clear and specific

Activity: define quality
attribute scenarios
Next step
Assume some of the critical quality
attribute scenarios have been defined
What next?
Tactics: how to accomplish a
quality attribute scenario
Air-filled tires
Big old springs
Shock absorbers
… (I’m no auto engineer)
Tactics for shift change
Separate authentication+authorization from
environment setup
Show progress indicator(s)
Precompute expensive structures
Defer at-login-time processing to background
Thin clients + shared services
Deploy workstations
Minimize other load on the system at shift
change times
What BC&K tactics are these? (refer to handout)
Tactics for Qualities
Tactics are a guide to design!
Tactics are design choices oriented
toward achieving qualities



Tactics can refine other tactics
Patterns package tactics
Tactics can interfere!
Next week: a way to use quality
attribute scenarios and tactics to drive
module decomposition
Tactics are ways to get the
desired response in a scenario
Tactic
Artifact
Response
Stimulus
Environment
Tactics example: performance
Introduce
concurrency
Database
25 req/sec
Normal ops
Prompt
results
Max
delay
< 2 sec
Qualities categorize tactics
Fault
Availability
Fault Masked
or
Repair Made
or
Fault Detected
(not enough
by itself)
Availability
Fault Detection
Echo
Ping
Exception
Recovery
Prep and
Repeat
Voting
Active
Redundancy
Passive
Redundancy
Spare
RecoveryReintroduction
Shadow
State
ReSync
Rollback
Prevention
Removal
from service
Transactions
Process Monitor
Tactics can interfere with each other
Modifiability: use an intermediary
Performance: reduce computational
overhead
Modifiability/Performance conflicts are
common
Patterns package tactics
An architectural pattern usually applies a
set of compatible tactics
Better yet, mutually reinforcing tactics
Or at least, the pattern may give advice on
balancing tactics that tend to conflict
Example 1: tactics in Money (488)
This is one of Fowler’s Base Patterns
Modifiability tactics used include




m1.
m2.
m3.
m5.
Semantic coherence
Anticipate changes
Generalize module
Abstract common services
Example 2: Reactor includes
Modifiability:



m3. Generalize module
m5. Abstract common services
m6. Hide information
Performance:




p3.
p2.
p5.
p8.
Manage event rate
Reduce computational overhead
Introduce concurrency
Scheduling policy
Styles
Styles (Shaw and Garlan) are recurring partial
architectures
Styles are sometimes also called “patterns”


Like patterns, they package tactics
But they’re not usually linked with a problem
A style consists of




Set of element types
Element topology
Set of semantic constraints
Set of interaction mechanisms
Style example: pipes and filters
Tactics include:
• m2. anticipate expected changes
• m5. abstract common services
• m6. hide information
• m7. maintain existing interface
• m8. restrict communication paths
• m12. polymorphism
• m13. component replacement
• p3. manage event rate
Style example: Service-Oriented
Architecture (SOA)
app
app
service
service
service
service
Tactics include:
• m2. anticipate expected changes
• m5. abstract common services
• m6. hide information
• m7. maintain existing interface
• m8. restrict communication paths
• m12. polymorphism
• m13. component replacement
• m14. adherence to defined
protocols
• t2. separate interface from
implementation
Tools of the architect’s trade
Quality attribute scenarios
… A way of defining testable quality
requirements
Tactics
… Bags of tricks you can apply
Patterns and styles
… Sets of tactics that usually fit together well
and are often applied together