Quality Attributes

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

Functionality vs Quality Attributes

Functionality

Qualit

y

Some QualitiesUsabilityModifiabilityPerformanceSecurityTestabilityAvailability

Time to marketCost and benefitProjected System lifetimeTargeted MarketRollout ScheduleIntegration / Legacy

Architectural QualitiesConceptual IntegrityCorrectness and CompletenessBuildability

Qualities & Trade-offsThe qualities are all goodThe qualities value is project specificThe qualities are not independent

Quality Attribute ScenariosSource of stimulusStimulusEnvironmentArtifactResponseResponse measure

(see inside front cover)

In the environment, the source throws the stimulus and hits the system in the artifact

Example from cars

Artifact:Tires

Environment:Highway driving

Source of stimulus:Road

Response:Control maintainedSmooth rideLow noise

Stimulus:Bumps

ResponseMeasure:

Deflection < N%Noise < M dB

…

RememberOne stimulus per scenarioOne environment per scenarioOne artifact per scenarioMultiple response measures are OK

Example from software

Artifact:User

interface

Environment:Normaloperation

Source of stimulus:Shift change

Response:Security maintainedAcceptable delays

Stimulus:Dozens ofsimultaneouslogins

ResponseMeasure: 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 stepAssume some of the critical quality attribute scenarios have been definedWhat next?

Tactics: how to accomplish a quality attribute scenario

Air-filled tiresBig old springsShock absorbers… (I’m no auto engineer)

Tactics for shift changeSeparate authentication+authorization from environment setupShow progress indicator(s)Precompute expensive structuresDefer at-login-time processing to backgroundThin clients + shared servicesDeploy workstationsMinimize other load on the system at shift change timesWhat BC&K tactics are these? (refer to handout)

Tactics for QualitiesTactics 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

Environment

ResponseStimulus

Tactic

Tactics example: performance

Database

Normal ops

Promptresults

25 req/sec

Max delay < 2 sec

Introduceconcurrency

Fault

Fault Maskedor

Repair Madeor

Fault Detected(not enough

by itself)

Qualities categorize tactics

Availability

Availability

Fault Detection RecoveryPrep and Repeat

Recovery-Reintroduction

Prevention

EchoPingException

VotingActive RedundancyPassive RedundancySpare

ShadowState ReSyncRollback

Removal from serviceTransactionsProcess Monitor

Tactics can interfere with each other

Modifiability: use an intermediaryPerformance: reduce computational overheadModifiability/Performance conflicts are common

Patterns package tacticsAn architectural pattern usually applies a set of compatible tacticsBetter yet, mutually reinforcing tacticsOr 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 PatternsModifiability tactics used include m1. Semantic coherence m2. Anticipate changes m3. Generalize module m5. Abstract common services

Example 2: Reactor includesModifiability: 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

StylesStyles (Shaw and Garlan) are recurring partial architecturesStyles 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

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)

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 paths• m12. polymorphism• m13. component replacement• m14. adherence to defined protocols• t2. separate interface from implementation

Tools of the architect’s tradeQuality 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