Nelly Bencomo, RAISE 2013

1. Bayesian
Ar+ficial
Intelligence
for
Tackling
Uncertainty
in
Self-­‐Adap+ve
Systems:
the
Case
of
Dynamic
Decision
Networks
2nd
Interna*onal
NSF
sponsored
Workshop
on
Realizing
Ar*ficial
Intelligence
Synergies
in
So=ware
Engineering
(RAISE2013)
San
Francisco
May,
21
2013
Nelly
Bencomo
Aston
University,
UK
Inria,
France
hKp://www.nellybencomo.me/
Amel
Belaggoun
Inria,
France
Valerie
Issarny
Inria,
France

2. Agenda
• Mo+va+on
– Role
of
non-­‐func+onal
requirements
in
the
decision
making
for
self-­‐
adapta+on
– Impact
of
architectural
decisions
on
the
sa+sficement
of
non-­‐
func+onal
requirements
(NFRs)
• Dynamic
Decision
Networks
to
support
decision-­‐
making
under
uncertainty
• Case
Study
• Conclusions
and
Future
Work

3. SoUware
of
the
Future
Increasingly
self-­‐managing
Requirements-­‐aware
Systems:
a
Research
Vision

4. SoUware
of
the
Future
Will
need
to
adapt
to
changing
environmental
condi+ons
Uncertainty:
these
changes
are
difficult
to
predict
and
an+cipate,
and
their
occurrence
is
out
of
control
of
the
applica+on
developers
!!
Requirements-­‐aware
Systems:
a
Research
Vision

5. Let’s
focus
on
• Impact
of
architectural
decisions
(configura+ons)
on
the
sa+sficement
of
non-­‐func+onal
requirements
CostsReliability
Performance
Configura*on
1
+
+
-­‐
CostsReliability
Performance
Configura*on
2
+
-­‐
+

6. • func+onal
requirement
“collect
data
about
a
volcano”
• Non-­‐func+onal
requirements
(NFRs)
B
:
“conserve
baOery
power”
C
:
“collect
data
frequently”
• 2
contexts:
quiescent
and
erup*on
– “conserve
baKery
power”
priori+zed
during
a
quiescent
context
– “collect
data
frequently”
priori+zed
during
erup*on
• Decisions
to
make:
– Network
design
• Decision
1:
Shortest
path
(SP)
(less
efficient
but
may
conserve
baKery)
• Decision
2:
Fewest
Hops
(FH)
(more
efficient
but
may
drain
baKery
faster)
Mo+va+ng
Example:
a
sensor
network
of
a
volcano
ß
SP
ß
HP
quiescent
erup*on

7. Goal
model
for
the
example
collect
data
Shortest
path
(SP)
Fewest
Hops
(FH)
energy
efficiency
collect
data
frequently
++
-­‐-­‐
++
-­‐-­‐
goal
goal
realizaAon
strategy
soBgoals
(NFRs)

8. Goal
model
for
the
example
collect
data
Shortest
path
(SP)
Fewest
Hops
(FH)
energy
efficiency
collect
data
frequently
++
-­‐-­‐
++
-­‐-­‐
goal
goal
realizaAon
strategy
soBgoals
(NFRs)
design
assumpAon
(claim)
C1
C1:
SP
is
too
risky
False

9. During
execu+on
collect
data
Shortest
path
(SP)
Fewest
Hops
(FH)
energy
efficiency
collect
data
frequently
++
-­‐-­‐
++
-­‐-­‐
goal
goal
realizaAon
strategy
soBgoals
(NFRs)
design
assumpAon
(claim)
C1
C1:
SP
is
too
risky
False

10. During
execu+on
collect
data
Shortest
path
(SP)
Fewest
Hops
(FH)
energy
efficiency
collect
data
frequently
++
-­‐-­‐
++
-­‐-­‐
goal
goal
realizaAon
strategy
soBgoals
(NFRs)
design
assumpAon
(claim)
C1
C1:
SP
is
too
risky
True

11. Claim
Refinement
Model
Faults
Likely
SP
is
less
resilient
than
FH
SP
is
too
risky
AND

12. Non-­‐func+onal
Requirements:
• Not
easy
to
reason
about
their
fulfillment
– "tension"
between
them
– tensions
need
to
be
iden+fied
and
resolved
in
an
op+mal
way
• Measurement
of
sa+sfac+on
of
NFRs
is
difficult
– NFRs
are
vague
or
fuzzy
– NFRs
may
not
be
absolutely
fulfilled
(they
can
be
labeled
as
sufficiently
sa+sficed)
NFR1
Performance
NFR2
Cost
not
easy
guys
to
deal
with

13. Non-­‐func+onal
Requirements:
• Not
easy
to
reason
about
their
fulfillment
– "tension"
between
them
– tensions
need
to
be
iden+fied
and
resolved
in
an
op+mal
way
• Measurement
of
sa+sfac+on
of
NFRs
is
difficult
– NFRs
are
vague
or
fuzzy
– NFRs
may
not
be
absolutely
fulfilled
(they
can
be
labeled
as
sufficiently
sa+sficed)
NFR1
Performance
NFR2
Cost
not
easy
guys
to
deal
with
All
is
exacerbated
in
the
case
the
running
system
needs
to
make
such
decisions
by
itself
during
run+me
Uncertainty
about
the
environment
makes
it
difficult
to
predict
the
effect
of
the
impact
of
architectural
decisions
on
the
sa+sficement
of
non-­‐func+onal
requirements

14. Non-­‐func+onal
Requirements:
fuzzy
guys
• Should
we
use
probability
theory
to
describe
the
lack
of
crispness
and
the
uncertainty
about
the
sa+sfiability
nature
of
NFRs?
Given
an
architectural
decision
dj
that
requires
a
certain
configura+on,
the
sa+sficement
of
a
NFRi
can
be
modeled
using
probability
distribu+ons
P(NFRi
saAsficed
|
dj)

15. Probability
to
express
the
lack
of
crispness
of
NFRs.
collect
data
Shortest
path
(SP)
Fewest
Hops
(FH)
energy
efficiency
(E)
collect
data
Frequently
(D)
++
-­‐-­‐
++
-­‐-­‐
P(D|FH)
P(E|FH)
P(D
|
FH)
=
P
(
D
saAsficed
/
architectural
decision
FH)
P(E
|
FH)
=
P
(
E
saAsficed
/
architectural
decision
FH)
P(D|FH)
>
P(E|FH)

16. • Extension
of
Bayesian
Networks
to
support
decision-­‐making
• Directed
Acyclic
Graph
(DAG)
associated
• Types
of
nodes:
• Chance
nodes:
labeled
by
random
variables
Xi
that
represent
the
states
of
the
world
• Decision
nodes:
with
the
set
of
choices
• UAlity
nodes:
that
state
the
preferences
about
the
states
of
the
world
• Evidence
nodes:
to
denote
the
observable
variables
The
condi+onal
probabili+es
quan+fy
the
effects
of
decisions
on
states
of
the
world
Tackling
Decision-­‐making
with
Dynamic
Decision
Networks
for
Self-­‐adapta+on
Random
X2
Random
X1
Decision
D1
D2
U
Evidence
E
P(X1|dj)
P(X2|dj)
EU j = EU(dj | e) = P(xi
i
∑ | e, dj )U(xi | dj )
j = 1, 2

17. X1(t)
X(t+1)
D(t)
D(t+1)
U(t+1)U(t)
E(t)
E(t+1)
Evidence
depends
on state
X2
X2
….
….
….
Time
t
Time
t+1
Time
t+n
Dynamics
Decision
Networks
(DDNs)

18. Characteris+cs
of
decision-­‐making
problems
addressed
by
DDNs:
• Environment
changes
over
+me
• Informa+on
is
available
to
the
DDN
(as
a
decision
maker)
based
on
data
provided
by
monitorables
and
also
by
human-­‐made
reports
(monitorable:
en+ty
in
the
environment
and
the
system
itself
that
can
be
monitored)
• The
DDN
can
be
prompted
to
make
a
decision
at
specific
+mes
(known
or
unknown
before
the
DDN
is
built)
• These
decisions
are
best
characterized
as
choices
associated
with
mee+ng
a
goal
Crucially,
the
above
are
characteris*cs
exposed
by
self-­‐adap*ve
systems

19. U
Evidence
Collect
Data
Frequently
(D)
Energy
Efficiency
(E)
Decision
SP
FH
22
Dynamic
Decision
Networks
for
the
example
Decisions (goal realizations)
SP: Clean when Empty SH: Clean at Night
Chance node) (Softgoals - non functional requirements)
M : Minimize Energy Cost A : Avoid Tripping Hazard
collect
data
Shortest
path
(SP)
Fewest
Hops
(FH)
energy
Efficiency
(E)
collect
data
frequently
(D)
++
-­‐-­‐
++
-­‐-­‐
P(D|SP)

20. available
evidence
the
condi+onal
probability
U+lity
(i.e.
preferences)
P xi e,dj( )
U xi dj( )
e
Dt
E
Decision
SP
FH
U
Evidence
e
EU j = EU(dj | e) = P(xi
i
∑ | e, dj )U(xi | dj )
j = 1, 2
The
decision
made
is
that
with
max
EUj
Decision
P(E|
dj)
SP
P(E|SP)=
0.8
FH
P(E|FH)=
0.4
Decision
P(D|
dj)
SP
P(D|SP)=
0.6
FH
P(D|FH)=
0.75
Decision
E
D
Weight
SP
F
F
0
SP
F
T
75
SP
T
F
70
SP
T
T
100
FH
F
F
0
FH
F
T
65
FH
T
F
70
FH
T
T
80
Preparing
the
ini+al
values
of
the
DDN
Sensor
model
P(
et|
Dt)
E
:
energy
Efficiency
(E)
Dt
:
collect
data
frequently
(D)
SP
Shortest
Path
FH:
Fewest
Hopes
NFRs
decisions


21. Remote
Data
Mirroring
(1)
Copies
of
important
data
are
stored
at
one
or
more
secondary
loca+ons
Goal: Protect data against loss and
unavailability
Case
Study
• Design
choices
• Remote
mirroring
protocols
e.g.
Minimum
spanning
tree
(MST)
vs
Redundant
topology
(RT)
(1)
“Relaxing
claims:Coping
with
uncertainty
while
evalua*ng
assump*ons
at
run
*me,”
A.
Ramirez,
B.
Cheng,
N.
Bencomo,
and
P.
Sawyer,
ACM/IEEE
Int.
Conference
on
Model
Driven
Engineering
Languages
&
Systems
MODELS,
2012.

22. Goal
model
for
the
RDM
applica+on
(1)
3
3
(1)
“Relaxing
claims:Coping
with
uncertainty
while
evalua*ng
assump*ons
at
run
*me,”
A.
Ramirez,
B.
Cheng,
N.
Bencomo,
and
P.
Sawyer,
ACM/IEEE
Int.
Conference
on
Model
Driven
Engineering
Languages
&
Systems
MODELS,
2012.

23. DDN
for
RDM
applica+on
Decisions:
MST:
Minimum
Spanning
Tree
RT
:
Redundant
Topology
Non-­‐func*onal
requirements
NFRs:
MR_t:
Maximize
Reliability
MP:
Maximize
Performance
MO:
Minimize
Opera+onal
costs
Et:
design
assump+on
Redundancy
prevents
networks
par++ons.

24. Uncertainty
Factors
• When
does
the
DDN
is
re-­‐evaluated
to
make
a
decision?
When
condi+onal
probability
func+ons
and
its
values
(i.e.,
beliefs)
have
changed
due
to
learned
informa+on
• Environmental
and
context
proper*es
that
can
cause
changes
on
the
probability
need
to
be
iden*fied
accordingly
We
call
those
environmental
proper+es:
uncertainty
factors

25. Uncertainty
Factors
3
Design
assump+on
C1=
“Redundancy
prevents
networks
par++ons”
Its
validity
can
be
monitored
at
run+me
This
assump+on
C1
is
falsified
if
two
or
more
network
links
fail
simultaneously
3

26. How
decisions
are
made?
Suppose
the
chance
nodes
are
MRt,
MP,MO
and
UAlity
depends
on
them,
and
the
evidence
node
is
E
this
generates
the
best
decision
D
that
maximizes
the
expected
u+lity
Markov
property
ObservaAon/Sensor
Model
TransiAon
Model

27. Experiments
• Tool:
Ne+ca
development
environment
hKp://www.norsys.com
Ne+ca
is
a
soUware
to
model
and
run
Decision
and
Bayesian
Networks
• Generic
scenario
“C1
=
Redundancy
prevents
the
networks
parAAons”
is
monitored.
At
design
+me,
C1
has
been
considered
valid
(true
)
and
MST
is
chosen
However,
during
run+me
a
change
on
this
value
is
monitored,
specifically
at
+me
slice
– t
=
3
,
the
value
false
is
observed,
which
means
that
the
design
assump+on
has
been
falsified.
– t
=
7,
according
to
the
monitoring
infrastructure
the
design
– assump+on
C1
is
true
again

28. Experiments
• Exp
1-­‐
Decision-­‐Making
• Exp
2-­‐
Effects
of
Weights
on
Decision-­‐Making
• Exp
3-­‐
Levels
of
Confidence
on
the
Monitoring
Infrastructure

29. U+lity
Table






30. Experiment
1-­‐
Decision-­‐Making
Evidence
monitored
as
False
Evidence
monitored
as True
“C1
=
Redundancy
prevents
the
networks
parAAons”

31. U+lity
Table






32. Experiment
2-­‐
Effects
of
Weights
on
Decision-­‐Making
Evidence
monitored
as
False
Evidence
monitored
as True

33. Experiment
3-­‐
Levels
of
Confidence
on
the
Monitoring
Infrastructure
Design
decision
“C1
=
Redundancy
prevents
the
networks
par++ons”
is
monitored
P(e|C1=true)
=
0.9
P(e|C1=true)
=
0.8
P(e|C1=true)
=
0.4

34. State
of
the
art
Approach
Model/Formalism
used
Design
*me
Run*me
Learning
GuideArch
[Esfahani+FSE1’2]
Possibility
theory
[Letier+FSE’04]
Probability
theory
RELAX
[Whittle+RE’09]
Fuzzy
logics
REAssure
[Welsh+ ASE ’11]
Goal
models+
Claims
RELAXing-­‐Claims
[
Ramirez+MRT’12]
Fuzzy
logics
POISED
[Esfahani+FSE’11].
Possibility
theory
+Fuzzy
logics
[Liaskos+RE’10] Goal
models
KAMI
[Filieri’11]
Marcov
chains+
Bayesian
inference
Our approach DDNs+
Bayesian
inference
When
Uncertainty
is
solved
X
√
X
√
X
X
X
X
X
X
√
√
√
√
√
√
√
√
√
√
√
√
√
√
X
X
√

35. Summary
DDN-­‐based
approach
• Uses
Bayesian
networks
to
guide
decision-­‐making
processes
• Defines
the
uncertainty
associated
with
the
current
situa+on
in
terms
of
the
condi+onal
probabili+es
• Balances
different
conflic+ng
sofgoals
according
to
given
preferences
u+li+es
• Maintains
the
defini+on
of
uncertainty
over
+me
as
new
informa+on
arrive
in
a
consistent
way
with
the
past
• Incorporates
risk
preferences
(i.e.
rewards
and
penal+es)
that
properly
address
the
current
situa+on
modeled

36. Summary
• DDNs
can
provide
a
quan+ta+ve
technique
to
make
informed
decisions
due
to
the
arrival
of
new
evidence
during
either
run+me
or
during
a
process
to
explore
the
opera*ng
environment
to
elicit
requirements.

37. Future
Work
 Use
the
DDNs
to
explore
and
improve
our
understanding
of
the
opera+ng
environment
and
to
elicit
requirements
 Use
the
DDNs
to
explore
requirements
scenarios
with
the
goal
of
quan+fy
requirements
P(Cost
<40)
>
0.9
 More
work
on
how
iden+fy
uncertainty
factors

38. Claim
Refinement
Model
Faults
Likely
SP
is
less
resilient
than
FH
SP
is
too
risky
AND

39. Ongoing
Work
on
Bayesian
Surprise
Theory
for
SASs
A
surprise
measures
how
new
evidence
affects
the
models
or
assump+ons
of
the
world.
The
key
idea
is
that
a
“surprising"
event
can
be
defined
as
one
that
causes
a
large
divergence
between
the
beliefs
distribu+ons
prior
and
posterior
to
the
event
that
has
been
observed.
According
to
how
big/small
the
surprise
is,
the
running
system
may
decide
to
either
dynamically
adapt
accordingly
or
to
highlight
the
fact
that
an
abnormal
situa+on
has
been
found.

40. Ongoing
Work
on
Bayesian
Surprise
Theory
for
SASs
• the
surprise
can
be
measured
using
the
Kullback-­‐
Leibler
divergence
(KL),
which
es+mates
the
divergence
between
the
prior
and
posterior
distribu+ons
• Among
other
several
ques+ons
we
want
to
answer,
we
have:
– how
big
or
small
a
surprise
can
be
considered
given
an
absolute
value?
– are
there
other
alterna+ve
ways
to
measure
a
surprise?

42. A
bit
of
reflec+on
• The
algorithms
applied
take
+me
• We
need
tools
(and
we
do
not
necessarily
want
to
construct
them
from
scratch)
• We
(soUware
engineers)
need
to
create
synergies
with
people
of
Ar+ficial
Intelligence

43.
Thanks
Discussion time