Quality Attributes Or whats wrong with this Exterminator

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 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 d. B … 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 n (just like any other requirement) Therefore, the Stimulus n Artifact n Environment n Response measure(s) must be clear and specific n

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 n n n 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 Recovery. Reintroduction Shadow State Re. Sync 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 n n m 1. m 2. m 3. m 5. Semantic coherence Anticipate changes Generalize module Abstract common services

Example 2: Reactor includes Modifiability: n n n m 3. Generalize module m 5. Abstract common services m 6. Hide information Performance: n n p 3. p 2. p 5. p 8. Manage event rate Reduce computational overhead Introduce concurrency Scheduling policy

Styles (Shaw and Garlan) are recurring partial architectures Styles are sometimes also called “patterns” n n Like patterns, they package tactics But they’re not usually linked with a problem A style consists of n n Set of element types Element topology Set of semantic constraints Set of interaction mechanisms

Style example: pipes and filters Tactics include: • m 2. anticipate expected changes • m 5. abstract common services • m 6. hide information • m 7. maintain existing interface • m 8. restrict communication paths • m 12. polymorphism • m 13. component replacement • p 3. manage event rate

Style example: Service-Oriented Architecture (SOA) app service Tactics include: • m 2. anticipate expected changes • m 5. abstract common services • m 6. hide information • m 7. maintain existing interface • m 8. restrict communication paths • m 12. polymorphism • m 13. component replacement • m 14. adherence to defined protocols • t 2. 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