Quality Attribute Scenarios and Architectural Tacticsaldrich/courses/15-313/17-qualities.pdf ·...

27
1 Quality Attribute Scenarios and Architectural Tactics 15-313: Foundations of Software Engineering Jonathan Aldrich

Transcript of Quality Attribute Scenarios and Architectural Tacticsaldrich/courses/15-313/17-qualities.pdf ·...

1

Qualit

y A

ttribute

Scenari

os a

nd

A

rchitectu

ral T

actics

15

-31

3:

Fo

un

da

tio

ns o

f S

oft

wa

re E

ng

ine

eri

ng

Jo

na

tha

n A

ldri

ch

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

2

Sourc

e

[BC

K0

3]

Bass,

Cle

me

nts

, and K

azm

an. Software

Architecture in Practice.

Addis

on

-Wesle

y,

2003.

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

3

Qualit

y A

ttribute

Scenarios [B

CK

03

]

•S

tim

ulu

s•

A c

on

ditio

n th

at

affe

cts

a s

yste

m

•S

ourc

e o

f stim

ulu

s•

Th

e e

ntity

th

at g

en

era

tes th

e

stim

ulu

s

•E

nvironm

ent

•T

he

co

nd

itio

n u

nde

r w

hic

h th

e

stim

ulu

s o

ccu

rre

d

•A

rtifact

•T

he

art

ifa

ct th

at w

as s

tim

ula

ted

•R

esponse

•T

he

activi

ty t

ha

t m

ust re

su

lt fro

m

the s

tim

ulu

s

•R

esponse m

easure

•T

he

me

asu

re b

y w

hic

h th

e

resp

on

se is e

valu

ate

d

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

4

Availa

bili

ty

•Is

th

e s

yste

m a

ble

to

pro

vid

e s

erv

ices t

o u

se

rs?

•O

ften m

easure

d a

s a

pro

ba

bili

ty

•Is

su

es

•fa

ults �

failu

res

•can inte

rvene to a

void

this

•fa

ult/f

ailu

re d

ete

ction

•fa

ilure

notification

•fa

ilure

reco

very

•how

long to r

epair?

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

5

Availa

bili

ty S

cenarios

Tim

e inte

rval a

vaila

ble

, availa

bili

ty %

, re

pair tim

e,

unavaila

bili

ty t

ime inte

rval

Measure

Log the failu

re, notify

users

/opera

tors

, dis

able

sourc

e o

f fa

ilure

, be u

navaila

ble

, continue

(norm

al or

degra

ded m

ode)

Response

Norm

al opera

tion; degra

ded m

ode

Environm

ent

Syste

m’s

pro

cessors

, com

munic

ation c

hannels

, pers

iste

nt sto

rage, pro

cesses

Art

ifact

Cra

sh, om

issio

n, tim

ing, in

corr

ect re

sponse

Stim

ulu

s

Inte

rnal vs. exte

rnal to

sys

tem

S

ourc

e

Possible Values

Scenario Portion

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

6

How

to Incre

ase A

vaila

bili

ty?

•A

rchitectu

ral T

actic

•str

ate

gy fo

r p

rom

otin

g q

ua

lity a

ttri

bu

te•

ind

ep

en

de

nt

of

imp

lem

en

tatio

n t

ech

no

log

y•

ind

ep

en

de

nt

of

exa

ct

arc

hite

ctu

ral str

uctu

re

•T

hre

e k

inds o

f A

vaila

bili

ty T

actic

•F

au

lt d

ete

ctio

n•

Fa

ult r

eco

ve

ry•

Fa

ult p

reve

ntio

n

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

7

Availa

bili

ty T

actics: F

ault D

ete

ction

•p

ing

/ech

o•

pin

g a

noth

er

com

pon

ent

•expect

an e

cho b

efo

re a

tim

eout

•h

ea

rtb

ea

t•

expect

peri

od

ic m

essage

•e

xce

ptio

ns

•dete

ct

genera

ted e

xceptio

n

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

8

Availa

bili

ty T

actics: F

ault R

ecovery

•voting

•m

ultip

le c

om

ponents

pro

duce a

nsw

er

•giv

e c

lient th

e a

nsw

er

with the m

ost vote

s•

most usefu

l fo

r hard

ware

failu

res

•bugg

y soft

ware

will

fail

in t

he s

am

e w

ay

•occurs

even if built

by

diffe

ren

t te

am

s!

•active r

eplic

as

•all

replic

as r

espond to a

ll m

essages

•passiv

e r

eplic

as

•passiv

e r

eplic

as p

eriodic

ally

update

d w

ith c

urr

ent sta

te•

requires lim

ited r

epla

y

•spare

•m

ust boot, load c

heckpoin

t, a

nd r

epla

y r

ecent m

essages

•checkp

oin

t/ro

llback

•allo

ws u

ndoin

g o

pera

tions a

fter

a failu

re

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

9

Availa

bili

ty T

actics: F

ault P

revention

•re

mo

ve

fro

m s

erv

ice

•e.g

. re

boot a c

om

pon

ent th

at’s g

ettin

g low

on

m

em

ory

•surp

risin

gly

effective for

OS

drivers

•tr

an

sa

ctio

ns

•avo

ids f

ailu

res/inconsis

tencie

s w

hen p

art

of an

opera

tion f

ails

•p

roce

ss m

on

ito

r•

dete

ct fa

ult in r

unnin

g p

rocess,

then r

esta

rt a

nd

rein

itia

lize b

efo

re e

rrors

pro

pagate

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

10

What is

the c

ost of th

ese tactics?

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

11

Modifia

bili

ty

•W

ha

t is

th

e c

ost

of ch

an

ge

?

•Is

su

es

•W

hat

is c

hang

ing

?•

functions, pla

tform

s, hard

ware

, pro

tocols

…•

qualit

y a

ttribute

s

•W

ho c

hang

es it?

•W

hen is it chan

gin

g?

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

12

Modifia

bili

ty S

cenarios

Cost in

effort

, m

oney, tim

e, exte

nt affects

oth

er

syste

m functions o

r qualit

ies

Measure

Locate

pla

ces in a

rchitectu

re for

modifyin

g,

modify, te

st m

odific

ation, deplo

ys m

odifi

cation

Response

At ru

ntim

e, com

pile

tim

e, build

tim

e, desig

n-t

ime

Environm

ent

Syste

m u

ser

inte

rface, pla

tform

, environm

ent

Art

ifact

Add/d

ele

te/m

odify functionalit

y o

r qualit

y

attribute

sS

tim

ulu

s

End-u

ser,

develo

per,

syste

m-a

dm

inis

trato

r S

ourc

e

Possible Values

Scenario Portion

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

13

Modifia

bili

ty T

actics

•Loca

lize m

od

ific

ations

•M

odific

ations a

ffect th

e r

equirem

ents

of as few

mod

ule

s a

s

possib

le

•P

revent

rip

ple

eff

ect

s•

Lim

it e

ffect of changin

g o

ne m

odule

on o

ther

module

s

•D

efe

r bin

din

g t

ime

•A

llow

modific

ations late

in p

rocess a

t lo

w c

ost

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

14

Modifia

bili

ty T

actics: Localiz

ation

•M

ain

tain

sem

antic c

ohere

nce

•gro

up r

esponsib

ilities that are

lik

ely

to c

hange to

geth

er

in the

sam

e m

odule

•H

ide info

rmation b

ased o

n a

nticip

ate

d c

ha

nges

•org

aniz

e a

rchitectu

re to m

inim

ize n

um

ber

of m

odule

s

affecte

d b

y specific c

hanges

•G

enera

lize

the m

odule

s•

the m

ore

genera

l th

e m

odule

’s inte

rface, th

e m

ore

lik

ely

changes in r

equirem

ents

won’t r

equire c

hangin

g the in

terf

ace

or

the im

ple

menta

tion

•B

UT

–genera

lity

cre

ate

s c

om

ple

xity

an

d c

ost,

so o

nly

use it

if

you n

ee

d it

•Lim

it p

ossib

le o

ptio

ns

•R

estr

ict th

e s

et of possib

le c

hanges s

o that you c

an p

lan

better

for

the s

upport

ed c

hanges

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

15

Modifia

bili

ty T

actic

s: P

revent R

ipple

s

•K

ey issu

e: N

otion o

f in

terf

aces

•ty

pes a

nd s

ignatu

res, sem

antics, sequences

•id

entity

, lo

catio

n, exis

tence

•qualit

y o

f serv

ice, re

sourc

e u

se

•T

actics

•H

ide info

rmatio

n (

like the a

bove)

within

a m

odule

•M

ain

tain

inte

rfaces

•E

xten

d in b

ackw

ard

s c

om

patible

wa

y, a

dd a

n a

dapte

r

•R

estr

ict com

munic

ation p

ath

s•

Fe

we

r conn

ections a

long w

hic

h r

ipple

s c

an p

ropag

ate

•A

dd a

n inte

rmedia

ry•

Convert

data

types,

repla

ce inte

rfaces w

ith a

pro

xy

•H

ide identity

usin

g b

roker,

location u

sin

g n

am

e s

erv

er

•R

esourc

e m

an

ager

hid

es r

esourc

e b

ehavio

r

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

16

Modifia

bili

ty T

actic

s: D

efe

rrin

g B

indin

g

•E

vent

regis

tration

•P

lug-a

nd-p

lay c

onnection b

etw

een c

om

ponents

•C

ost in

unders

tandabili

ty

•P

oly

morp

his

m•

Late

bin

din

g o

f m

eth

od c

alls

•C

ost in

perf

orm

ance

•C

onfig

ura

tion f

iles

•B

ind a

t deplo

ym

ent

•C

ost in

com

ple

xity

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

17

Perf

orm

ance

•H

ow

lo

ng

do

es it ta

ke

th

e s

yste

m t

o r

esp

on

d

to a

n e

ven

t?•

Genera

lize

s to thro

ug

hput,

etc

.

•Is

su

es

•S

ourc

es o

f events

•end u

sers

, in

terr

upts

, tim

ers

, m

essages

•A

rriv

al pattern

s•

periodic

, spora

dic

, sto

chastic

•R

espo

nse c

rite

ria

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

18

Perf

orm

ance S

cenarios

Late

ncy, deadlin

e, th

roughput, jitte

r, m

iss r

ate

, data

loss

Measure

Pro

cess s

tim

uli;

change level of serv

ice

Response

Norm

al m

ode; overload m

ode

Environm

ent

Syste

m o

r com

ponent

Art

ifact

Periodic

events

, spora

dic

events

, sto

chastic

events

S

tim

ulu

s

A n

um

ber

of sourc

es b

oth

exte

rnal and inte

rnal

Sourc

e

Possible Values

Scenario Portion

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

19

Perf

orm

ance T

actics

•F

un

da

me

nta

l is

su

es

•R

esourc

e u

se

•com

puta

tion, m

em

ory

, bandw

idth

, syste

m-s

pecific

re

sourc

es

•B

lockin

g f

or

resourc

es

•conte

ntion, availa

bili

ty, dependencie

s

•S

tra

teg

ies

•R

educe r

esourc

e d

em

and

•In

cre

ase e

ffic

iency, lo

wer

perf

orm

ance e

xpecta

tions

•In

cre

ase r

esourc

es

•T

hro

w m

oney

at th

e p

roble

m

•C

oord

inate

resourc

es

•S

hare

more

effic

iently

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

20

Perf

orm

ance T

actics: R

educe D

em

and

•In

cre

ase e

ffic

iency

•B

etter

alg

orith

ms

•T

rade s

pace for

tim

e

•R

educe o

verh

ea

d•

Avoid

costly o

pera

tions, e.g

. in

direction

•T

ypic

ally

co

nflic

ts w

ith o

ther

qualit

y att

ribute

s!

•R

educe e

vent

rate

•S

am

ple

environm

enta

l data

less fre

quently

•M

ay

reduce p

recis

ion

•D

iscard

events

•S

am

ple

fro

m in

put str

eam

•C

ost:

som

e r

eq

uests

are

lost

•B

ou

nd e

xecution t

ime

•e.g

. num

ber

of itera

tions in p

roble

m•

Cost:

solu

tion m

ay

be less p

recis

e

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

21

Perf

orm

ance T

actics: In

cre

ase R

esourc

es

•In

tro

du

ce

co

ncu

rre

ncy

•A

dds c

om

ple

xity,

but gets

thin

gs d

one f

aste

r if

there

is inh

ere

nt

para

llelis

m

•D

up

lica

te d

ata

or

co

mp

uta

tio

n•

Avo

id c

onte

ntio

n f

or

share

d r

eso

urc

es

•C

ache d

ata

fro

m a

rem

ote

serv

er

•B

uy m

ore

re

so

urc

es

•F

aste

r C

PU

, m

ore

CP

Us,

more

mem

ory

, fa

ste

r netw

ork

•O

nly

barr

ier

is $

$$

•S

o, does the v

alu

e o

f th

e a

dditio

nal perf

orm

ance e

xceed

its c

ost?

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

22

Perf

orm

ance T

actics:

Coord

inate

Resourc

es

•T

yp

ica

lly s

ch

ed

ulin

g s

tra

teg

ies

•F

IFO

•fa

ir w

hen a

ll re

quests

are

equiv

ale

nt

•fixe

d p

riori

ties

•m

ost im

port

ant

•short

est deadlin

e

•dynam

ic p

riori

ties

•earlie

st deadlin

e first

•sta

tic s

chedu

ling

•allo

cate

every

thin

g u

p fro

nt

•good for

real-tim

e / e

mbedded s

yste

ms

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

23

Security

•A

bili

ty t

o r

esis

t a

ttack w

hile

re

ma

inin

g

fun

ctio

na

l

•Is

su

es

•C

onfid

entia

lity –

can’t s

ee p

rivate

data

•In

tegrity

–can

’t m

odify d

ata

without

perm

issio

n•

No

nre

pud

iation

–can

’t d

eny m

alic

ious a

ctio

n•

Ava

ilab

ility

–no d

en

ial of serv

ice

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

24

Security

Scenarios

Cost/benefit of attack to a

ttacker,

cost of attack to

defe

nder

and u

sers

; pro

babili

ty o

f id

entify

ing

attacker;

availa

bili

ty d

uring D

OS

attack; …

Measure

Gra

nt/blo

ck a

ccess; audit r

equests

; encry

pt data

; dete

ct attack; ente

r degra

ded m

ode

Response

Onlin

e/o

fflin

e, connecte

d/d

isconnecte

d,

fire

walle

d/o

pen

Environm

ent

Syste

m s

erv

ices, data

A

rtifact

Attem

pt to

dis

pla

y/m

odify d

ata

; access s

erv

ices;

reduce a

vaila

bili

tyS

tim

ulu

s

User/

syste

m that is

identified c

orr

ectly/incorr

ectly

or

unknow

n, w

ho is inte

rnal/exte

rnal and

auth

orized o

r not, w

ith full/

limited a

ccess

Sourc

e

Possible Values

Scenario Portion

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

25

Security

Tactics: R

esis

ting A

ttacks

•A

uth

en

tica

tio

n•

User

identification –

often u

sern

am

e/p

assw

ord

•A

uth

ori

za

tio

n•

Whic

h u

sers

can p

erf

orm

whic

h o

pera

tio

ns?

•E

ncry

ptio

n•

Pro

tect

confidentia

l da

ta

•C

he

cksu

ms /

sig

na

ture

s•

Ensure

inte

grity

of data

•P

rin

cip

le o

f le

ast

pri

vile

ge

•R

educe d

am

age a

ttacker

can d

o

•L

imit a

cce

ss

•F

ire

wa

lls,

etc

.

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

26

Security

Tactic

s: D

ete

ctio

n/R

ecovery

•In

trusio

n d

ete

ction s

yste

ms

•A

udit tra

ils

•A

vaila

bili

ty tactic

s

9 September 2008

15-313: Foundations of Software Engineering

Software Architecture

27

More

Qualit

y A

ttribute

s

•T

esta

bili

ty

•U

sabili

ty

•In

tero

pera

bili

ty

•S

cala

bili

ty (

Perf

orm

ance? M

odifia

bili

ty?)

•P

ort

abili

ty (

Modifia

bili

ty)