Your SlideShare is downloading. ×
Bayesian Artifical Intelligence for Tackling Uncertainty in Self-Adaptive Systems
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Bayesian Artifical Intelligence for Tackling Uncertainty in Self-Adaptive Systems

501
views

Published on

Nelly Bencomo, RAISE 2013

Nelly Bencomo, RAISE 2013

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
501
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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(xii∑ | 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)  Evidencedependson stateX2  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 NightChance node) (Softgoals - non functional requirements)M : Minimize Energy Cost A : Avoid Tripping Hazardcollect  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( )eDt  E  Decision  SP      FH  U     Evidence  e  EU j = EU(dj | e) = P(xii∑ | e, dj )U(xi | dj )j = 1, 2The  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 andunavailabilityCase  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    Evidencemonitoredas True  “C1  =  Redundancy  prevents  the  networks  parAAons”    
  • 31. U+lity  Table            
  • 32. Experiment  2-­‐  Effects  of  Weights  on  Decision-­‐Making  Evidence  monitored  as  False    Evidencemonitoredas 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?  
  • 41. 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          
  • 42.    ThanksDiscussion time