You are on page 1of 27

Quality Attributes

Or, whats wrong with this:

Exterminator kit place bug on block, strike with mallet

Functionality vs Quality Attributes


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

Artifact: Tires Response Measure: Deflection < N% Noise < M dB

Stimulus: Bumps

Environment: Highway driving

Source of stimulus: Road

Response: Control maintained Smooth ride Low noise

One stimulus per scenario One environment per scenario One artifact per scenario Multiple response measures are OK

Example from software

Artifact: User interface

Stimulus: Dozens of simultaneous Environment: Normal logins operation Response: Source of stimulus: Security maintained Shift change Acceptable delays

Response Measure: No unauthorized users, login < 1 min

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 (Im 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


Artifact Stimulus Environment Response

Tactics example: performance

Introduce concurrency

Database 25 req/sec Normal ops

Prompt results

Max delay < 2 sec

Qualities categorize tactics

Fault Masked or Repair Made or Fault Detected (not enough by itself)




Fault Detection

Recovery Prep and Repeat



Echo Ping Exception

Voting Active Redundancy Passive Redundancy Spare

Shadow State ReSync Rollback

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 Fowlers Base Patterns Modifiability tactics used include

m1. m2. m3. m5.

Semantic coherence Anticipate changes Generalize module Abstract common services

Example 2: Reactor includes


m3. Generalize module m5. Abstract common services m6. Hide information p3. p2. p5. p8. Manage event rate Reduce computational overhead Introduce concurrency Scheduling policy


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 Set of element types Element topology Set of semantic constraints Set of interaction mechanisms

A style consists of

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





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 architects trade

Quality attribute scenarios
A way of defining testable quality requirements

Bags of tricks you can apply

Patterns and styles

Sets of tactics that usually fit together well and are often applied together