Quality Attributes

1
Quality Attributes

• Or, whats wrong with this
• Exterminator kit place bug on block, strike
  with mallet

2
Functionality vs Quality Attributes
Quality
Functionality
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 lt N Noise lt 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
Example from software
Response Measure No unauthorized users, login lt
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
• (Im no auto engineer)

14
Tactics for shift change

• Separate authenticationauthorization 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 BCK 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
Tactic
Artifact
Response
Stimulus
Environment
17
Tactics example performance
Introduce concurrency
Max delay lt 2 sec
Database
Prompt results
25 req/sec
Normal ops
18
Qualities categorize tactics
Fault Masked or Repair Made or Fault
Detected (not enough by itself)
Availability
Fault
19
Availability
Recovery Prep and Repeat
Recovery- Reintroduction
Fault Detection
Prevention
Removal from service Transactions Process
Monitor
Voting Active Redundancy Passive
Redundancy 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 Fowlers 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 theyre 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 architects 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