quality attribute scenarios and architectural tacticsaldrich/courses/15-313/17-qualities.pdf ·...
TRANSCRIPT
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