Quality Attr

8/13/2019 Quality Attr

1/27

Quality Attributes

Or, whats wrong with this:

Exterminator kit place bug on

block, strike with mallet


2/27

Functionality vsQuality Attributes

Functionality

Qu

ality


3/27

Some Qualities

UsabilityModifiability

Performance

SecurityTestability

Availability

Time to marketCost and benefit

Projected System

lifetimeTargeted Market

Rollout Schedule

Integration / Legacy


4/27


5/27

Qualities & Trade-offs

The qualities are all goodThe qualities value is project specific

The qualities are not independent


6/27

Quality Attribute Scenarios

Source of stimulusStimulus

Environment

Artifact

Response

Response measure

(see inside front cover)

In the environment,

thesourcethrows thestimulusand hits the

system in the artifact


7/27

Example from cars

Artifact:

Tires

Environment:

Highway driving

Source of stimulus:

Road

Response:

Control maintainedSmooth ride

Low noise

Stimulus:

Bumps

Response

Measure:

Deflection < N%

Noise < M dB


8/27

Remember

One stimulus per scenarioOne environment per scenario

One artifact per scenario

Multiple response measures are OK


9/27

Example from software

Artifact:

User

interface

Environment:

Normal

operationSource of stimulus:

Shift change

Response:

Security maintainedAcceptable delays

Stimulus:

Dozens ofsimultaneous

logins

Response

Measure: No

unauthorized

users,

login < 1 min


10/27

If you remember one thing

To be effective, quality attribute scenariosmust be testable

(just like any other requirement)

Therefore, the Stimulus

Artifact

Environment

Response measure(s)

must be clear and specific


11/27

Activity: define qualityattribute scenarios


12/27

Next step

Assume some of the critical qualityattribute scenarios have been defined

What next?


13/27

Tactics: how to accomplish a

quality attribute scenarioAir-filled tires

Big old springs

Shock absorbers

(Im no auto engineer)


14/27

Tactics for shift change

Separate authentication+authorization fromenvironment setup

Show progress indicator(s)

Precompute expensive structures

Defer at-login-time processing to backgroundThin clients + shared services

Deploy workstations

Minimize other load on the system at shiftchange times

What BC&K tactics are these? (refer to handout)


15/27

Tactics for Qualities

Tactics are a guide to design!Tactics are design choices orientedtoward 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 drivemodule decomposition


16/27

Tactics are ways to get the

desired response in a scenario

Artifact

Environment

ResponseStimulus

Tactic


17/27

Tactics example: performance

Database

Normal ops

Prompt

results25 req/sec

Maxdelay

< 2 sec

Introduceconcurrency


18/27

Fault

Fault Masked

or

Repair Made

orFault Detected

(not enough

by itself)

Qualities categorize tactics

Availability


19/27

Availability

Fault DetectionRecovery

Prep and

Repeat

Recovery-

ReintroductionPrevention

Echo

Ping

Exception

Voting

Active

RedundancyPassive

Redundancy

Spare

Shadow

State

ReSyncRollback

Removal

from service

Transactions

Process Monitor


20/27

Tactics can interfere with each other

Modifiability: use an intermediaryPerformance: reduce computationaloverhead

Modifiability/Performance conflicts arecommon


21/27

Patterns package tactics

An architectural pattern usually applies aset of compatible tactics

Better yet, mutually reinforcing tactics

Or at least, the pattern may give advice onbalancing tactics that tend to conflict


22/27

Example 1: tactics in Money (488)

This is one of Fowlers Base PatternsModifiability tactics used include

m1. Semantic coherence

m2. Anticipate changes m3. Generalize module

m5. Abstract common services


23/27

Example 2: Reactorincludes

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
http://cs.franklin.edu/~swartoud/650/slides650/Pattern%20-%20Reactor.ppthttp://cs.franklin.edu/~swartoud/650/slides650/Pattern%20-%20Reactor.ppt


24/27

Styles

Styles (Shaw and Garlan) are recurring partialarchitectures

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

Style example: pipes and filters

Tactics include:

m2. anticipate expected changes

m5. abstract common services

m6. hide information

m7. maintain existing interfacem8. restrict communication paths

m12. polymorphism

m13. component replacement

p3. manage event rate

Style example: Service Oriented


26/27

Style example: Service-OrientedArchitecture (SOA)

service service service

service

app appTactics include:

m2. anticipate expected changes

m5. abstract common services

m6. hide information

m7. maintain existing interface

m8. restrict communication pathsm12. polymorphism

m13. component replacement

m14. adherence to defined

protocolst2. separate interface from

implementation


27/27

Tools of the architects trade

Quality attribute scenarios A way of defining testablequality

requirements

Tactics Bags of tricks you can apply

Patterns and styles Sets of tactics that usually fit together well

and are often applied together

Documents

Quality Attr