1. Quality Attributes Or, what’s wrong with this:
Exterminator kit – place bug on block, strike with mallet

2. Functionality vs Quality Attributes

3. Some Qualities Usability Modifiability Performance Security
Testability
Availability
Time to market
Cost and benefit
Projected System lifetime
Targeted Market
Rollout Schedule
Integration / Legacy

4. Architectural Qualities
Conceptual Integrity
Correctness and Completeness
Buildability

5. Qualities & Trade-offs
The qualities are all good
The qualities value is project specific
The qualities are not independent

6. Quality Attribute Scenarios
Source of stimulus
Stimulus
Environment
Artifact
Response
Response measure
(see inside front cover)
In the environment, the source throws the stimulus and hits the system in the artifact

7. Example from cars Response Measure: Deflection < N% Artifact:
Noise < M dB …
Artifact:
Tires
Stimulus:
Bumps
Environment:
Highway driving
Source of stimulus:
Road
Response:
Control maintained
Smooth ride
Low noise

8. Remember One stimulus per scenario One environment per scenario
One artifact per scenario
Multiple response measures are OK

9. Measure: No unauthorized
Example from software
Response
Measure: No unauthorized
users,
login < 1 min
Artifact:
User
interface
Stimulus:
Dozens of
simultaneous
logins
Environment:
Normal
operation
Response:
Security maintained
Acceptable delays
Source of stimulus:
Shift change

10. 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

11. Activity: define quality attribute scenarios

12. Next step
Assume some of the critical quality attribute scenarios have been defined
What next?

13. Tactics: how to accomplish a quality attribute scenario
Air-filled tires
Big old springs
Shock absorbers
… (I’m no auto engineer)

14. 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)

15. 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

16. Tactics are ways to get the desired response in a scenario
Artifact
Response
Stimulus
Environment

17. Tactics example: performance
Introduce
concurrency
Max delay
< 2 sec
Database
Prompt
results
25 req/sec
Normal ops

18. Qualities categorize tactics
Fault Masked or
Repair Made
Fault Detected
(not enough
by itself)
Availability
Fault

19. Availability Recovery Prep and Repeat Fault Detection Recovery-
Reintroduction
Prevention
Removal
from service
Transactions
Process Monitor
Voting
Active
Redundancy
Passive
Spare
Shadow
State
ReSync
Rollback
Echo
Ping
Exception

20. Tactics can interfere with each other
Modifiability: use an intermediary
Performance: reduce computational overhead
Modifiability/Performance conflicts are common

21. 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

22. Example 1: tactics in Money (488)
This is one of Fowler’s Base Patterns
Modifiability tactics used include
m1. Semantic coherence
m2. Anticipate changes
m3. Generalize module
m5. Abstract common services

23. Example 2: Reactor includes
Modifiability:
m3. Generalize module
m5. Abstract common services
m6. Hide information
Performance:
p3. Manage event rate
p2. Reduce computational overhead
p5. Introduce concurrency
p8. Scheduling policy

24. 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

25. 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

26. Style example: Service-Oriented Architecture (SOA)
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
app
app
service
service
service
service

27. 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