[PPT] - Engineering Self-Adap0ve Systems An Architectural Perspec0ve PowerPoint Presentation

SLIDE 1

Engineering ¡Self-‑Adap0ve ¡Systems ¡– ¡ An ¡Architectural ¡Perspec0ve ¡

Danny ¡Weyns ¡ ¡ Automated ¡So>ware ¡Engineering ¡– ¡ASE ¡ ¡ Lincoln, ¡Nebraska ¡November ¡9, ¡2015 ¡

SLIDE 2

Your ¡tutor ¡today ¡

Linnaeus ¡University ¡ ¡ Växjö, ¡Sweden ¡ KU ¡Leuven ¡ Belgium ¡ Lincoln, ¡Nebraska ¡

SLIDE 3

Your ¡tutor ¡today ¡

2006: ¡PhD ¡KU ¡Leuven; ¡research ¡on ¡middleware ¡and ¡

architectures ¡for ¡mul0-‑agent ¡systems ¡

2006-‑2011: ¡postdoc ¡at ¡KU ¡Leuven ¡with ¡focus ¡on ¡

so>ware ¡architecture ¡and ¡self-‑adapta0on ¡

2011-‑2015: ¡prof. ¡at ¡Linnaeus ¡University ¡with ¡focus ¡
n ¡engineering ¡self-‑adap0ve ¡systems ¡
Since ¡Oct. ¡2015: ¡prof. ¡at ¡KU ¡Leuven; ¡current ¡focus: ¡

– Handling ¡mul0ple ¡concerns ¡in ¡self-‑adap0ve ¡systems ¡ – Applying ¡control ¡theory ¡to ¡adapt ¡so>ware ¡ – Executable ¡formal ¡models ¡for ¡self-‑adapta0on ¡ ¡

¡

SLIDE 4

Objec0ves ¡of ¡this ¡tutorial ¡

SLIDE 5

1. Understand ¡the ¡mo0va0on ¡and ¡need ¡for ¡self-‑

adapta0on; ¡

¡

2. Get ¡familiar ¡with ¡the ¡state-‑of-‑the-‑art ¡principles ¡
f ¡realizing ¡architecture-‑based ¡self-‑adapta0on; ¡

¡

3. Get ¡insight ¡in ¡the ¡paradox ¡between ¡uncertainty ¡

and ¡assurances ¡and ¡how ¡self-‑adapta0on ¡can ¡ help ¡to ¡tackle ¡this; ¡ ¡

¡

4. Learn ¡about ¡some ¡open ¡challenges ¡in ¡the ¡

domain ¡of ¡self-‑adap0ve ¡systems. ¡

SLIDE 6

Outline ¡of ¡the ¡tutorial ¡

1. Mo0va0on ¡for ¡self-‑adapta0on ¡
2. Architecture-‑based ¡approaches ¡to ¡self-‑

adapta0on ¡

3. Assurances ¡for ¡self-‑adap0ve ¡systems ¡
4. Towards ¡"Design ¡for ¡Sustainability" ¡

SLIDE 7

Mo0va0on ¡for ¡Self-‑Adapta0on ¡

The ¡blurring ¡boundaries ¡between ¡design ¡0me ¡

and ¡run0me ¡ ¡

What ¡is ¡self-‑adapta0on ¡ ¡
Why ¡do ¡we ¡need ¡self-‑adapta0on? ¡

SLIDE 8

Blurring ¡boundaries ¡design ¡and ¡run0me ¡ ¡

Some ¡observa0ons ¡

– Mobile ¡apps ¡require ¡resources ¡but ¡the ¡availability ¡ may ¡change ¡con0nuously ¡ – Behavior ¡of ¡users ¡in ¡the ¡smart ¡grid ¡may ¡change ¡ unexpectedly ¡ – The ¡goals ¡automa0on ¡system ¡in ¡a ¡factory ¡may ¡ change ¡in ¡ways ¡that ¡are ¡difficult ¡to ¡predict ¡ ¡ – … ¡ ¡

SLIDE 9

Blurring ¡boundaries ¡design ¡and ¡run0me ¡ ¡

In ¡sum: ¡ ¡

– Modern ¡so>ware ¡systems ¡o>en ¡have ¡to ¡operate ¡ under ¡highly ¡dynamic ¡condi0ons ¡ ¡ – These ¡condi0ons ¡introduce ¡uncertain0es ¡

Changing ¡availability ¡of ¡resources ¡ ¡
User ¡behavior ¡that ¡is ¡difficult ¡to ¡predict ¡

¡ ¡

Goals ¡may ¡dynamically ¡be ¡changed ¡

¡

SLIDE 10

Blurring ¡boundaries ¡design ¡and ¡run0me ¡ ¡

Uncertainty ¡leads ¡to ¡incomplete ¡knowledge ¡at ¡

design ¡0me ¡ ¡

Business ¡con0nuity ¡requires ¡that ¡uncertainty ¡

is ¡handled ¡at ¡run0me ¡

Leads ¡to ¡blur ¡in ¡tradi0onal ¡engineering ¡phases ¡

SLIDE 11

Blurring ¡boundaries ¡design ¡and ¡run0me ¡ ¡

Tradi0onal ¡evolu0on ¡perspec0ve ¡

¡

SLIDE 12

Blurring ¡boundaries ¡design ¡and ¡run0me ¡ ¡

Tradi0onal ¡evolu0on ¡perspec0ve ¡

¡

Development ¡ ¡ Running ¡ Evolu0on ¡ Running ¡ Running ¡ Evolu0on ¡

SLIDE 13

Blurring ¡boundaries ¡design ¡and ¡run0me ¡ ¡

Tradi0onal ¡evolu0on ¡perspec0ve ¡
System ¡engineering ¡becomes ¡a ¡perpetual ¡process ¡

Development ¡ ¡ Running ¡ Evolu0on ¡ Running ¡ Running ¡ Evolu0on ¡ Human-‑driven ¡

ffline ¡ac0vi0es ¡

Machine-‑driven ¡

nline ¡ac0vi0es ¡

SLIDE 14

Blurring ¡boundaries ¡design ¡and ¡run0me ¡ ¡

How ¡to ¡engineer ¡such ¡systems ¡and ¡ guarantee ¡the ¡required ¡system ¡goals? ¡ ¡ ¡

SLIDE 15

Mo0va0on ¡for ¡Self-‑Adapta0on ¡

The ¡blurring ¡boundaries ¡between ¡design ¡0me ¡

and ¡run0me ¡ ¡

What ¡is ¡self-‑adapta0on ¡ ¡
Why ¡do ¡we ¡need ¡self-‑adapta0on? ¡

SLIDE 16

What ¡is ¡Self-‑Adapta0on? ¡ ¡

¡

Self-‑adapta0on ¡is ¡one ¡prominent ¡approach ¡to ¡

deal ¡with ¡uncertainty ¡and ¡business ¡con0nuity ¡

Key ¡idea: ¡let ¡the ¡system ¡gather ¡knowledge ¡at ¡

run0me, ¡reason ¡about ¡itself ¡and ¡its ¡context ¡ and ¡adapt ¡to ¡realize ¡goals ¡

SLIDE 17

Environment ¡

input ¡ effect ¡ Non-‑controllable ¡so>ware, ¡ ¡ hardware, ¡network, ¡physical ¡context ¡

What ¡is ¡Self-‑Adapta0on? ¡ ¡

So>ware ¡system ¡

SLIDE 18

Environment ¡

input ¡ effect ¡ Non-‑controllable ¡so>ware, ¡ ¡ hardware, ¡network, ¡physical ¡context ¡

What ¡is ¡Self-‑Adapta0on? ¡ ¡

Self-‑adap0ve ¡so>ware ¡system ¡

SLIDE 19

Managed ¡system ¡ Managing ¡system ¡ Self-‑adap0ve ¡so>ware ¡system ¡

monitor ¡ adapt ¡ Controllable ¡so>ware ¡ monitor ¡

What ¡is ¡Self-‑Adapta0on? ¡ ¡

Environment ¡

input ¡ effect ¡ Non-‑controllable ¡so>ware, ¡ ¡ hardware, ¡network, ¡physical ¡context ¡

SLIDE 20

Self-‑adapta0on ¡is ¡in ¡essence ¡a ¡reflec0ve ¡

capability ¡

¡

Design ¡of ¡self-‑adapta0on ¡ ¡

– Legacy ¡systems ¡

Add ¡feedback ¡loop(s) ¡to ¡deal ¡with ¡adapta0on ¡concerns ¡
E.g., ¡improve ¡performance, ¡make ¡system ¡robust ¡to ¡

par0cular ¡types ¡of ¡failures ¡ ¡

– Greenfield ¡design ¡

Domain ¡concerns ¡handled ¡by ¡managing ¡system ¡
Adapta0on ¡concerns ¡by ¡the ¡managed ¡system ¡ ¡

What ¡is ¡Self-‑Adapta0on? ¡

SLIDE 21

What ¡is ¡Self-‑Adapta0on? ¡ ¡

Different ¡approaches ¡exist ¡to ¡realize ¡managing ¡

system ¡ ¡

– Architecture-‑based ¡approaches: ¡managing ¡system ¡exploits ¡ architectural ¡model ¡of ¡system ¡under ¡adapta0on ¡ ¡ – Control-‑theory ¡based ¡approaches: ¡controller ¡design ¡based ¡

n ¡principles ¡of ¡control ¡theory ¡ ¡

– Self-‑organizing ¡approaches: ¡adapta0on ¡based ¡on ¡local ¡ interac0ons ¡of ¡en00es ¡typically ¡with ¡emergent ¡behavior ¡

SLIDE 22

What ¡is ¡Self-‑Adapta0on? ¡ ¡

Different ¡approaches ¡exist ¡to ¡realize ¡managing ¡

system ¡ ¡

– Architecture-‑based ¡approaches: ¡managing ¡system ¡exploits ¡ architectural ¡model ¡of ¡system ¡under ¡adapta0on ¡ ¡ – Control-‑theory ¡based ¡approaches: ¡controller ¡design ¡based ¡

n ¡principles ¡of ¡control ¡theory ¡ ¡

– Self-‑organizing ¡approaches: ¡adapta0on ¡based ¡on ¡local ¡ interac0ons ¡of ¡en00es ¡typically ¡with ¡emergent ¡behavior ¡

SLIDE 23

¡ Architecture-‑based ¡self-‑adapta0on ¡ ¡

¡ ¡

Control-‑based ¡self-‑adapta0on ¡ ¡

Target ¡system ¡ Controller ¡ disturbance ¡input ¡ reference ¡ input ¡

utput ¡

Transducer ¡ Managed ¡system ¡ Environment ¡ Managing ¡system ¡ effect ¡ adapt ¡ monitor ¡ control ¡

What ¡is ¡Self-‑Adapta0on? ¡

SLIDE 24

Managed ¡system ¡ Environment ¡ Managing ¡system ¡ effect ¡ adapt ¡ monitor ¡

Architecture-‑based ¡Approaches ¡

¡

Managing ¡system ¡

Composed ¡of ¡components ¡that ¡realize ¡ adapta0on ¡func0ons ¡ Components ¡share ¡run0me ¡models ¡of: ¡

‑ Managed ¡system ¡
‑ Opera0ng ¡environment ¡ ¡
‑ Adapta0on ¡goals ¡

¡ Managed ¡system ¡

Provide ¡features ¡for ¡monitoring ¡and ¡ performing ¡adapta0on ¡ac0ons ¡

SLIDE 25

Architecture-‑based ¡Approaches ¡ ¡

Variety ¡of ¡goal ¡models ¡

– RELAX* ¡captures ¡uncertainty ¡(e.g. ¡“may” ¡vs. ¡“shall”) ¡ ¡ – FLAGS** ¡includes ¡fuzzy ¡goals ¡specified ¡using ¡fuzzy ¡constraints ¡ – Awareness ¡requirements*: ¡meta ¡requirements ¡ ¡

¡ * ¡J. ¡Whisle, ¡P. ¡Sawyer, ¡N. ¡Bencomo, ¡B. ¡H. ¡Cheng, ¡and ¡J.-‑M. ¡Bruel. ¡RELAX: ¡Incorpora0ng ¡Uncertainty ¡into ¡the ¡Specifica0on ¡of ¡Self-‑Adap0ve ¡ Systems, ¡Requirements ¡Engineering ¡2009 ¡ ** ¡L. ¡Baresi, ¡L. ¡Pasquale, ¡and ¡P. ¡Spole0ni. ¡Fuzzy ¡goals ¡for ¡requirements-‑driven ¡adapta0on, ¡Requirements ¡Engineering, ¡2010 ¡ *** ¡V. ¡E. ¡Silva ¡Souza, ¡A. ¡Lapouchnian, ¡W. ¡N. ¡Robinson, ¡and ¡J. ¡Mylopoulos, ¡ ¡Awareness ¡requirements ¡for ¡adap0ve ¡Systems, ¡SEAMS ¡2011 ¡ ¡

SLIDE 26

Classic PID-type control (Abdelzaher et al. 2003) ¡ Decentralized ¡control ¡ ¡ (X. ¡Wang ¡et ¡al., ¡2007; ¡R. ¡Wang ¡et ¡al ¡2012) ¡ Nested ¡and ¡layered ¡architectures ¡ (Zhu ¡et ¡al, ¡2006; ¡Kusic ¡et ¡al. ¡2009) ¡

Approximate System Model Performance Error Correction Performance Set Point Controller Actuator (Resource Allocator) Resource Allocation Software System Actual Performance Performance Sensor Measured Performance (b) &

Controlling ¡so>ware ¡vs. ¡hardware/resources ¡ ¡ (e.g. ¡Filieri ¡et ¡al. ¡2014, ¡Shevtsov ¡et ¡al. ¡2015) ¡ MIMO ¡systems ¡ (Dio ¡et ¡al., ¡2002, ¡Lu ¡et ¡al. ¡2005) ¡

Control signal 1 Setpoint 1 Measured

utput

Plant Error 1 Disturbances Controller 1 Simplex Simplex signal Control signal n Setpoint n Error n Controller n Parameters O1...On O1 On

MB C(z) P(z) ˜ µ +

Control (normal) mode Model Building mode

η µ −

Control-‑based ¡Approaches ¡

SLIDE 27

Mo0va0on ¡for ¡Self-‑Adapta0on ¡

The ¡blurring ¡boundaries ¡between ¡design ¡0me ¡

and ¡run0me ¡ ¡

What ¡is ¡self-‑adapta0on ¡ ¡
Why ¡do ¡we ¡need ¡self-‑adapta0on? ¡

SLIDE 28

Why ¡do ¡we ¡Need ¡Self-‑Adapta0on? ¡ ¡

Handling ¡uncertainty ¡upfront ¡o>en ¡infeasible ¡(or ¡very ¡expensive) ¡

hence ¡deal ¡with ¡it ¡when ¡the ¡knowledge ¡becomes ¡available ¡ ¡

Architecture ¡offers ¡appropriate ¡level ¡of ¡abstrac0on ¡and ¡generality ¡to ¡

deal ¡with ¡adapta0on ¡ ¡

Manage ¡complexity ¡by ¡separa0on ¡of ¡domain ¡concerns ¡from ¡

adapta0on ¡concerns ¡

– External ¡control ¡mechanisms ¡provide ¡a ¡more ¡effec0ve ¡engineering ¡ solu0on ¡than ¡internal ¡mechanisms ¡for ¡self-‑adapta0on* ¡

No ¡free ¡lunch: ¡very ¡challenging ¡area ¡

¡

*D. ¡Garlan, ¡S-‑W. ¡Cheng, ¡A.C. ¡Huang, ¡B. ¡Schmerl, ¡P. ¡Steenkiste, ¡Rainbow: ¡Architecture-‑ ¡Based ¡Self-‑ Adapta0on ¡with ¡Reusable ¡Infrastructure, ¡IEEE ¡Computer, ¡October ¡2004 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

SLIDE 29

Outline ¡of ¡the ¡tutorial ¡

1. Mo0va0on ¡for ¡self-‑adapta0on ¡
2. Architecture-‑based ¡approaches ¡to ¡self-‑

adapta0on ¡

3. Assurances ¡for ¡self-‑adap0ve ¡systems ¡
4. Towards ¡"Design ¡for ¡Sustainability" ¡

SLIDE 30

Architecture-‑based ¡Approaches ¡to ¡ Self-‑adapta0on ¡

Oreizy ¡et ¡al. ¡pioneering ¡work ¡
MAPE-‑K ¡reference ¡model ¡
Rainbow ¡framework ¡ ¡
3-‑layer ¡model ¡
FORMS ¡reference ¡model ¡

SLIDE 31

Oreizy ¡et ¡al. ¡pioneering ¡work ¡

“…so>ware’s ¡original ¡promise—applica0ons ¡that ¡

retain ¡full ¡plas0city ¡throughout ¡their ¡lifecycle ¡and ¡that ¡ are ¡as ¡easy ¡to ¡modify ¡in ¡the ¡field ¡as ¡they ¡are ¡on ¡the ¡ drawing ¡board.” ¡ ¡

“…So>ware ¡engineers ¡have ¡pursued ¡many ¡techniques ¡

for ¡achieving ¡this ¡goal ¡… ¡while ¡each ¡contributes ¡to ¡the ¡ goal, ¡the ¡sum ¡total ¡s0ll ¡falls ¡short.” ¡ ¡

“Self-‑adap0ve ¡so>ware ¡will ¡provide ¡the ¡key.” ¡

¡

P. ¡Oreizy, ¡M. ¡Gorlick, ¡R. ¡Taylor, ¡D. ¡Heimbigner, ¡G. ¡Johnson, ¡N. ¡Medvidovic, ¡A. ¡Quilici, ¡D. ¡Rosenblum, ¡and ¡A. ¡

Wolf, ¡An ¡Architecture-‑Based ¡Approach ¡to ¡Self-‑Adap0ve ¡So>ware, ¡IEEE ¡Intelligent ¡Systems, ¡May/June ¡1999 ¡

SLIDE 32

Oreizy ¡et ¡al. ¡pioneering ¡work ¡

¡

¡Adapta0on ¡management ¡

¡Life ¡cycle ¡of ¡self-‑adapta0on ¡

¡ ¡

¡

¡Evolu0on ¡management ¡

¡Change ¡of ¡applica0on ¡so>ware ¡

SLIDE 33

Oreizy ¡et ¡al. ¡pioneering ¡work ¡

¡

¡Adapta0on ¡management ¡

¡Life ¡cycle ¡of ¡self-‑adapta0on ¡

¡ ¡

SLIDE 34

Oreizy ¡et ¡al. ¡pioneering ¡work ¡

Observing ¡and ¡evalua0ng ¡ applica0on’s ¡execu0on ¡

¡

E.g., ¡performance ¡monitoring, ¡ safety ¡inspec0ons, ¡constraint ¡ verifica0on ¡ ¡ ¡

SLIDE 35

Oreizy ¡et ¡al. ¡pioneering ¡work ¡

Accep0ng ¡the ¡evalua0ons ¡

¡

Defining ¡an ¡appropriate ¡ adapta0on ¡

¡

Construc0ng ¡a ¡blueprint ¡for ¡ execu0ng ¡that ¡adapta0on. ¡ ¡

SLIDE 36

Oreizy ¡et ¡al. ¡pioneering ¡work ¡

Coordinated ¡conveyance ¡of: ¡ ¡ ¡

‑

change ¡descrip0ons ¡ ¡

‑

possibly ¡new ¡observers ¡or ¡ evaluators ¡

SLIDE 37

Oreizy ¡et ¡al. ¡pioneering ¡work ¡

¡

¡Evolu0on ¡management ¡

¡Change ¡of ¡applica0on ¡so>ware ¡

SLIDE 38

Oreizy ¡et ¡al. ¡pioneering ¡work ¡

Changes ¡to ¡the ¡architectural ¡ model ¡are ¡consistently ¡reflected ¡ in ¡modifica0ons ¡to ¡the ¡ applica0on’s ¡implementa0on ¡

SLIDE 39

Oreizy ¡et ¡al. ¡pioneering ¡work ¡

Feeds ¡informa0on ¡back ¡to ¡ adapta0on ¡management ¡

SLIDE 40

Oreizy ¡et ¡al. ¡pioneering ¡work ¡

Visionary ¡model ¡

– Run0me ¡architecture ¡model ¡ ¡ – Adapta0on ¡management ¡as ¡separate ¡concern ¡ – Integra0on ¡of ¡adapta0on ¡and ¡evolu0on ¡ – Distributed ¡perspec0ve ¡ ¡

Some ¡notes ¡ ¡

– Conceptual ¡model ¡ ¡ – Run0me ¡model ¡focus ¡on ¡managed ¡system ¡ – Goals ¡and ¡uncertain0es ¡not ¡first ¡class ¡ci0zens ¡ ¡ – Focus ¡on ¡consistency ¡and ¡system ¡integrity ¡ ¡

SLIDE 41

Architecture-‑based ¡Approaches ¡to ¡ Self-‑adapta0on ¡

Oreizy ¡et ¡al. ¡pioneering ¡work ¡
MAPE-‑K ¡reference ¡model ¡
Rainbow ¡framework ¡ ¡
3-‑layer ¡model ¡
FORMS ¡reference ¡model ¡

SLIDE 42

MAPE-‑K ¡Reference ¡Model ¡

“…systems ¡manage ¡themselves ¡according ¡to ¡an ¡

administrator’s ¡goals.” ¡ ¡

“New ¡components ¡integrate ¡as ¡effortlessly ¡as ¡a ¡new ¡

cell ¡establishes ¡itself ¡in ¡the ¡human ¡body.” ¡ ¡

“These ¡ideas ¡are ¡not ¡science ¡fic0on, ¡but ¡elements ¡of ¡

the ¡grand ¡challenge ¡to ¡create ¡self-‑managing ¡ compu0ng ¡systems.” ¡ ¡ ¡

Kephart ¡and ¡Chess, ¡The ¡Vision ¡of ¡Autonomic ¡Compu0ng, ¡IEEE ¡Computer, ¡January ¡2003 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

SLIDE 43

MAPE-‑K ¡Reference ¡Model ¡

¡

Autonomic ¡manager ¡

Relieves ¡humans ¡of ¡responsibility ¡

f ¡ ¡directly ¡managing ¡the ¡

managed ¡element ¡

¡

Managed ¡element ¡

Principle ¡reference ¡model ¡for ¡self-‑adapta0on ¡ ¡

– Primary ¡func0ons ¡of ¡self-‑adapta0on ¡and ¡their ¡interac0ons ¡ – Design ¡= ¡mapping ¡of ¡MAPE ¡func0ons ¡to ¡components ¡ ¡ – Four ¡classes ¡of ¡self-‑management ¡

Self-‑configura0on, ¡self-‑op0miza0on, ¡self-‑healing ¡and ¡self-‑protec0on ¡ ¡
Some ¡notes ¡ ¡

– Knowledge ¡abstractly ¡defined ¡ ¡ ¡ – Interac0on ¡with ¡human ¡administrator ¡implicit ¡ ¡ – Rela0onships ¡among ¡autonomic ¡elements ¡implicit ¡ – Controlling ¡hardware ¡versus ¡controlling ¡so>ware ¡

SLIDE 50

Architecture-‑based ¡Approaches ¡to ¡ Self-‑adapta0on ¡

Oreizy ¡et ¡al. ¡pioneering ¡work ¡
MAPE-‑K ¡reference ¡model ¡
Rainbow ¡framework ¡ ¡
3-‑layer ¡model ¡
FORMS ¡reference ¡model ¡

SLIDE 51

Rainbow ¡Framework ¡

“Reusable ¡infrastructure ¡to ¡support ¡self-‑adapta0on ¡of ¡

so>ware ¡systems.” ¡ ¡

“The ¡use ¡of ¡external ¡adapta0on ¡mechanisms ¡allows ¡

the ¡explicit ¡specifica0on ¡of ¡adapta0on ¡strategies.” ¡ ¡

“Using ¡a ¡system’s ¡architecture ¡as ¡a ¡control ¡model ¡can ¡

make ¡topological ¡and ¡behavioral ¡constraints ¡explicit, ¡ establishing ¡an ¡envelope ¡of ¡allowed ¡changes ¡and ¡ helping ¡to ¡ensure ¡the ¡validity ¡of ¡a ¡change.” ¡ ¡ ¡

D. ¡Garlan, ¡S-‑W. ¡Cheng, ¡A.C. ¡Huang, ¡B. ¡Schmerl, ¡P. ¡Steenkiste, ¡Rainbow: ¡Architecture-‑ ¡Based ¡Self-‑

Adapta0on ¡with ¡Reusable ¡Infrastructure, ¡IEEE ¡Computer, ¡October ¡2004 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

SLIDE 52

Rainbow ¡Framework ¡

Translation infrastructure Executing system Architecture layer System API Constraint evaluator Adaptation engine Model manager Mappings Strategies and tactics Rules Adaptation executor Types and properties System layer Operators Discovery Probes Resource discovery Effectors Gauges

¡

Architecture ¡layer ¡

Aggregates ¡informa0on ¡and ¡ applies ¡adapta0ons ¡when ¡needed ¡

¡

Transla0on ¡infrastructure ¡

Mediates ¡the ¡mapping ¡of ¡ informa0on ¡across ¡abstrac0on ¡ gap ¡system-‑model ¡and ¡vice ¡versa ¡

¡

System ¡layer ¡

System ¡access ¡interface ¡with ¡ infrastructure ¡that ¡implements ¡it ¡

SLIDE 53

Rainbow ¡Framework ¡

Translation infrastructure Executing system Architecture layer System API Constraint evaluator Adaptation engine Model manager Mappings Strategies and tactics Rules Adaptation executor Types and properties System layer Operators Discovery Probes Resource discovery Effectors Gauges

Plug ¡in ¡(Hot ¡spot) ¡ Reusable ¡ ¡elements ¡ (Frozen ¡spot) ¡

¡

Architecture ¡layer ¡

Aggregates ¡informa0on ¡and ¡ applies ¡adapta0ons ¡when ¡needed ¡

¡

Transla0on ¡infrastructure ¡

Mediates ¡the ¡mapping ¡of ¡ informa0on ¡across ¡abstrac0on ¡ gap ¡system-‑model ¡and ¡vice ¡versa ¡

¡

System ¡layer ¡

System ¡access ¡interface ¡with ¡ infrastructure ¡that ¡implements ¡it ¡

SLIDE 54

Rainbow ¡Framework ¡

Translation infrastructure Executing system Architecture layer System API Constraint evaluator Adaptation engine Model manager Mappings Strategies and tactics Rules Adaptation executor Types and properties System layer Operators Discovery Probes Resource discovery Effectors Gauges

Measurement ¡mechanism ¡ Observes ¡and ¡measures ¡ various ¡system ¡states ¡

SLIDE 55

Rainbow ¡Framework ¡

Translation infrastructure Executing system Architecture layer System API Constraint evaluator Adaptation engine Model manager Mappings Strategies and tactics Rules Adaptation executor Types and properties System layer Operators Discovery Probes Resource discovery Effectors Gauges

Measurement ¡mechanism ¡ Observes ¡and ¡measures ¡ various ¡system ¡states ¡ Mechanism ¡that ¡can ¡be ¡queried ¡for ¡new ¡resources ¡ based ¡on ¡e.g. ¡resource ¡type ¡

Pioneering ¡realiza0on ¡of ¡architecture-‑based ¡self-‑

adapta0on ¡ ¡

– Maps ¡MAPE-‑K ¡to ¡concrete ¡reusable ¡realiza0on ¡elements ¡ ¡ – Goals ¡realized ¡via ¡invariants; ¡explicit ¡adapta0on ¡strategies ¡ – Importance ¡of ¡probing ¡and ¡effec0ng ¡

Some ¡notes ¡ ¡

– Reference ¡realiza0on ¡ ¡ ¡ – Various ¡extensions ¡(e.g., ¡S0tch ¡language ¡repair ¡strategies*) ¡ ¡ – Centralized ¡approach; ¡“heavy” ¡ ¡ ¡

*S-‑W. ¡Cheng ¡and ¡D. ¡Garlan, ¡S0tch: ¡A ¡Language ¡for ¡Architecture-‑Based ¡Self-‑Adapta0on, ¡Journal ¡of ¡Systems ¡and ¡ So>ware, ¡Editors ¡Weyns ¡et ¡al., ¡Special ¡Issue ¡on ¡State ¡of ¡the ¡Art ¡in ¡Self-‑Adap0ve ¡Systems, ¡Vol. ¡85(12), ¡December ¡2012 ¡

SLIDE 62

Architecture-‑based ¡Approaches ¡to ¡ Self-‑adapta0on ¡

Oreizy ¡et ¡al. ¡pioneering ¡work ¡
MAPE-‑K ¡reference ¡model ¡
Rainbow ¡framework ¡ ¡
3-‑layer ¡model ¡
FORMS ¡reference ¡model ¡

SLIDE 63

3-‑Layer ¡Model ¡

“[A ¡self-‑managed ¡system] ¡is ¡one ¡in ¡which ¡components ¡

automa0cally ¡configure ¡their ¡interac0on ¡in ¡a ¡way ¡that ¡ is ¡compa0ble ¡with ¡an ¡overall ¡architectural ¡ specifica0on ¡and ¡achieves ¡the ¡goals ¡of ¡the ¡system.” ¡ ¡

“… ¡the ¡architectural ¡level ¡seems ¡to ¡provide ¡the ¡

required ¡level ¡of ¡abstrac0on ¡and ¡generality ¡to ¡deal ¡ with ¡the ¡challenges ¡posed ¡by ¡self-‑adap0on.” ¡ ¡ ¡

Kramer ¡and ¡Magee, ¡Self-‑adapta0on: ¡an ¡architecture ¡challenge, ¡Future ¡of ¡So>ware ¡Engineering, ¡ FOSE ¡2007 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

SLIDE 64

3-‑Layer ¡Model ¡

¡

Goal ¡management ¡

Responsible ¡for ¡re-‑planning ¡ ¡

¡

Change ¡management ¡

Responsible ¡for ¡execu0ng ¡ changes ¡in ¡the ¡lower ¡layer ¡ based ¡on ¡status ¡changes ¡

¡

Component ¡control ¡

Accomplishes ¡the ¡applica0on ¡ func0on ¡of ¡the ¡system ¡

Goal Management Change Management Component Control

Status Change Actions C1 C2 P1 P2 Change Plans Plan Request G G’ G”

Goal Management Change Management Component Control

Status Change Actions C1 C2 P1 P2 Change Plans Plan Request G G’ G”

Figure 1 – Three Layer Architecture Model for

SLIDE 65

3-‑Layer ¡Model ¡

Set ¡of ¡interconnected ¡ components ¡accomplishing ¡ the ¡applica0on ¡func0on ¡

¡

Facili0es ¡to ¡report ¡current ¡ status ¡of ¡components ¡and ¡ perform ¡adapta0ons ¡

Goal Management Change Management Component Control

Status Change Actions C1 C2 P1 P2 Change Plans Plan Request G G’ G”

Goal Management Change Management Component Control

Status Change Actions C1 C2 P1 P2 Change Plans Plan Request G G’ G”

Figure 1 – Three Layer Architecture Model for

SLIDE 66

3-‑Layer ¡Model ¡

Set ¡of ¡interconnected ¡ components ¡accomplishing ¡ the ¡applica0on ¡func0on ¡

¡

Facili0es ¡to ¡report ¡current ¡ status ¡of ¡components ¡and ¡ perform ¡adapta0ons ¡ Reacts ¡to ¡changes ¡in ¡state ¡

f ¡the ¡lower ¡level ¡by ¡

execu0on ¡ac0ons ¡to ¡handle ¡ the ¡new ¡situa0on ¡ ¡

Goal Management Change Management Component Control

Status Change Actions C1 C2 P1 P2 Change Plans Plan Request G G’ G”

Goal Management Change Management Component Control

Status Change Actions C1 C2 P1 P2 Change Plans Plan Request G G’ G”

Figure 1 – Three Layer Architecture Model for

SLIDE 67

3-‑Layer ¡Model ¡

Components ¡accomplishing ¡the ¡ applica0on ¡func0on ¡

¡

Facili0es ¡to ¡report ¡current ¡status ¡ and ¡perform ¡adapta0ons ¡ Handles ¡requests ¡from ¡the ¡layer ¡ below ¡and ¡introduc0on ¡new ¡goals ¡

¡

Takes ¡state ¡and ¡high-‑level ¡goal ¡to ¡ produce ¡plan ¡to ¡achieve ¡goal ¡ ¡

Goal Management Change Management Component Control

Status Change Actions C1 C2 P1 P2 Change Plans Plan Request G G’ G”

Goal Management Change Management Component Control

Status Change Actions C1 C2 P1 P2 Change Plans Plan Request G G’ G”

Figure 1 – Three Layer Architecture Model for

Reacts ¡to ¡changes ¡in ¡state ¡

f ¡the ¡lower ¡level ¡by ¡

execu0on ¡ac0ons ¡to ¡handle ¡ the ¡new ¡situa0on ¡ ¡

SLIDE 68

3-‑Layer ¡Model ¡

Ra0onal ¡for ¡self-‑adapta0on ¡at ¡the ¡architecture ¡level ¡ ¡
Dis0nc0on ¡between ¡adapta0on ¡and ¡goal ¡management ¡ ¡

– Goals ¡as ¡first-‑class ¡ci0zens ¡ ¡ – Different ¡layers ¡work ¡on ¡different ¡0me ¡scales ¡

Some ¡notes ¡ ¡

– Based ¡on ¡robo0cs ¡model ¡of ¡Gat* ¡ – Focus ¡in ¡planning ¡ ¡ – Recent ¡related ¡effort: ¡MORPH ¡model ¡-‑ ¡dis0nc0on ¡between ¡ dynamic ¡reconfigura0on ¡and ¡behavior ¡adapta0on** ¡ ¡

¡

* ¡E. ¡Gat, ¡Three-‑layer ¡Architectures, ¡Ar0ficial ¡Intelligence ¡and ¡Mobile ¡Robots, ¡MIT/AAAI ¡Press, ¡1997 ¡ ** ¡hsp://arxiv.org/pdf/1504.08339v1.pdf ¡

SLIDE 69

Architecture-‑based ¡Approaches ¡to ¡ Self-‑adapta0on ¡

Oreizy ¡et ¡al. ¡pioneering ¡work ¡
MAPE-‑K ¡reference ¡model ¡
Rainbow ¡framework ¡ ¡
3-‑layer ¡model ¡
FORMS ¡reference ¡model ¡

SLIDE 70

FORMS ¡ ¡

FOrmal ¡Reference ¡Model ¡for ¡Self-‑adapta0on ¡ ¡

“… ¡lack ¡of ¡a ¡precise ¡vocabulary ¡to ¡describe ¡and ¡reason ¡

about ¡key ¡architectural ¡characteris0cs ¡of ¡self-‑adap0ve ¡ systems.” ¡ ¡

“… ¡exis0ng ¡frameworks ¡do ¡not ¡provide ¡encompassing ¡

perspec0ve ¡on ¡different ¡concerns ¡[of ¡self-‑adapta0on]” ¡ ¡

“[FORMS] ¡provides ¡rigor ¡in ¡the ¡manner ¡such ¡systems ¡

can ¡be ¡described ¡and ¡reasoned ¡about” ¡

¡

D. ¡Weyns, ¡S. ¡Malek, ¡J. ¡Andersson, ¡ ¡FORMS: ¡Formal ¡reference ¡model ¡for ¡self-‑adapta0on, ¡ACM ¡Transac0ons ¡
n ¡Autonomous ¡and ¡Adap0ve ¡Systems, ¡TAAS ¡7(1), ¡2012 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

SLIDE 71

FORMS ¡Reference ¡Model ¡

Integrates ¡different ¡perspec0ves ¡on ¡self-‑

adapta0on ¡

– Reflec0on ¡perspec0ve ¡ ¡ – MAPE-‑K ¡perspec0ve ¡ – Distribu0on ¡perspec0ve ¡

UML ¡models ¡with ¡formal ¡specifica0on ¡in ¡Z ¡

language ¡

SLIDE 72

FORMS: ¡Running ¡Example ¡ Traffic ¡jam ¡monitoring ¡

72 ¡

¡

D. ¡Weyns, ¡R. ¡Haesevoets, ¡A. ¡Helleboogh, ¡T. ¡Holvoet, ¡W. ¡Joosen, ¡The ¡MACODO ¡Middleware ¡for ¡Context-‑Driven ¡

Dynamic ¡Agent ¡Organza0ons, ¡ACM ¡Transac0on ¡on ¡Autonomous ¡and ¡Adap0ve ¡Systems, ¡5(1):3.1–3.29, ¡2010. ¡ ¡

SLIDE 73

73 ¡

Running ¡Example: ¡traffic ¡jam ¡monitoring ¡

SLIDE 74

74 ¡

Running ¡Example: ¡traffic ¡jam ¡monitoring ¡

SLIDE 75

FORMS ¡Reflec0on ¡Perspec0ve ¡

75 ¡

SLIDE 76

76 ¡

FORMS ¡Reflec0on ¡Perspec0ve ¡

Self-‑adap0ve ¡system ¡

SLIDE 77

FORMS ¡Reflec0on ¡Perspec0ve ¡

77 ¡

Self-‑adap0ve ¡system ¡

SLIDE 78

78 ¡

FORMS ¡Reflec0on ¡Perspec0ve ¡

Environment ¡

SLIDE 79

79 ¡

FORMS ¡Reflec0on ¡Perspec0ve ¡

Environment ¡

SLIDE 80

80 ¡

FORMS ¡Reflec0on ¡Perspec0ve ¡

Base-‑Level ¡Subsystem ¡

SLIDE 81

81 ¡

FORMS ¡Reflec0on ¡Perspec0ve ¡

Base-‑Level ¡Subsystem ¡

SLIDE 82

82 ¡

Reflec0ve ¡Subsystem ¡

FORMS ¡Reflec0on ¡Perspec0ve ¡

SLIDE 83

83 ¡

Reflec0ve ¡Subsystem ¡

FORMS ¡Reflec0on ¡Perspec0ve ¡

SLIDE 84

84 ¡

FORMS ¡Distributed ¡Coordina0on ¡Perspec0ve ¡

SLIDE 85

85 ¡

FORMS ¡Distributed ¡Coordina0on ¡Perspec0ve ¡

Local ¡Self-‑Adap0ve ¡System ¡

SLIDE 86

86 ¡

FORMS ¡Distributed ¡Coordina0on ¡Perspec0ve ¡

Local ¡Managed ¡System ¡– ¡Self-‑Adap0ve ¡Unit ¡

SLIDE 87

87 ¡

FORMS ¡Distributed ¡Coordina0on ¡Perspec0ve ¡

Local ¡Managed ¡System ¡– ¡Self-‑Adap0ve ¡Unit ¡

SLIDE 88

88 ¡

FORMS ¡Distributed ¡Coordina0on ¡Perspec0ve ¡

Coordina0on ¡Mechanism ¡

SLIDE 89

89 ¡

ping/echo ¡messages ¡

FORMS ¡Distributed ¡Coordina0on ¡Perspec0ve ¡

Coordina0on ¡Mechanism ¡

SLIDE 90

FORMS ¡MAPE ¡Perspec0ve ¡

90 ¡

SLIDE 91

91 ¡

FORMS ¡MAPE ¡Perspec0ve ¡

Local ¡Reflec0ve ¡Computa0ons ¡

SLIDE 92

92 ¡

FORMS ¡MAPE ¡Perspec0ve ¡

Local ¡Reflec0ve ¡Computa0ons ¡

SLIDE 93

93 ¡

sense ¡ adapt ¡ perceive ¡

FORMS ¡MAPE ¡Perspec0ve ¡

Local ¡Reflec0ve ¡Computa0ons ¡

SLIDE 94

94 ¡

FORMS ¡MAPE ¡Perspec0ve ¡

Reflec0on ¡Models ¡

SLIDE 95

95 ¡

FORMS ¡MAPE ¡Perspec0ve ¡

Reflec0on ¡Models ¡

SLIDE 96

(A ¡glimpse ¡of) ¡FORMS ¡in ¡ac0on ¡

96 ¡

SLIDE 97

(A ¡glimpse ¡of) ¡FORMS ¡in ¡ac0on ¡

97 ¡

traffic domain attributes == {camera1 , camera2 , camera3 , freeflow zone1 ,

congested zone1 , freeflow zone2 , congested zone2 , freeflow zone3 , congested zone3}

traffic domain processes == {traffic1 , traffic2 , traffic3 , monitor camera1 , monitor camera2 , monitor camera3 , transmit}

TrafficEnvironment Environment attributes ✓ traffic domain attributes processes ✓ traffic domain processes

The traffic environment at T0 in the example (Figure 0??) is defined as:

TrafficEnvironmentT0 TrafficEnvironment attributes = {camera1 , camera2 , camera3 , freeflow zone1 , freeflow zone2 , congested zone3} processes = traffic domain processes

Environment attributes : P Attribute processes : P Process attributes 6= ∅

SLIDE 98

FORMS ¡in ¡ac0on ¡

98 ¡

... ¡ ... ¡ ... ¡

SLIDE 99

FORMS ¡in ¡ac0on ¡

99 ¡

SLIDE 100

FORMS ¡in ¡ac0on ¡

... ¡

SLIDE 101

FORMS ¡Reference ¡Model ¡

Integrates ¡different ¡exis0ng ¡perspec0ves ¡
n ¡self-‑adapta0on ¡ ¡

– Extensible ¡model ¡ – Formal ¡underpinning ¡avoids ¡ambiguity ¡ ¡

Some ¡notes ¡ ¡

– Focus ¡on ¡modeling ¡and ¡reasoning ¡of ¡structural ¡aspects ¡

f ¡self-‑adap0ve ¡systems ¡

– Z ¡specifica0ons ¡are ¡easy ¡to ¡read ¡but ¡extensive ¡ ¡ ¡

SLIDE 102

Outline ¡of ¡the ¡tutorial ¡

1. Mo0va0on ¡for ¡self-‑adapta0on ¡
2. Architecture-‑based ¡approaches ¡to ¡self-‑

adapta0on ¡

3. Assurances ¡for ¡self-‑adap0ve ¡systems ¡
4. Towards ¡"Design ¡for ¡Sustainability" ¡

SLIDE 103

Assurances ¡for ¡Self-‑adap0ve ¡Systems ¡

Mo0va0on ¡to ¡assurances ¡for ¡self-‑adapta0on ¡ ¡
A ¡selec0on ¡of ¡formal ¡approaches ¡to ¡self-‑

adapta0on ¡ ¡

Perpetual ¡assurances ¡

SLIDE 104

Mo0va0on ¡to ¡Assurances ¡for ¡ Self-‑adapta0on ¡

Uncertainty ¡<> ¡assurances ¡
Par0cularly ¡relevant ¡in ¡domains ¡with ¡certain ¡

levels ¡of ¡cri0cality ¡ ¡

– E.g., ¡healthcare, ¡automa0on, ¡defense, ¡etc. ¡ ¡

With ¡need ¡for ¡self-‑adap0on ¡in ¡these ¡domains ¡

assurance ¡has ¡become ¡a ¡major ¡concern ¡ ¡ ¡

SLIDE 105

Variety ¡of ¡techniques ¡available* ¡

– From ¡regular ¡tes0ng ¡to ¡formal ¡proofs ¡ ¡ – Focus ¡on ¡specific ¡aspects ¡of ¡the ¡self-‑adap0on ¡ ¡ – Most ¡current ¡approaches ¡rely ¡on ¡formal ¡ techniques ¡ ¡

Key ¡challenge: ¡what ¡are ¡suitable ¡techniques ¡to ¡

provide ¡assurances ¡at ¡run0me? ¡ ¡

¡

*D. ¡Weyns, ¡U. ¡I>ikhar, ¡D. ¡Gil ¡de ¡la ¡Iglesia, ¡T. ¡Ahmad, ¡A ¡Survey ¡of ¡Formal ¡Methods ¡in ¡Self-‑Adap0ve ¡Systems, ¡Fi>h ¡ Interna0onal ¡C* ¡Conference ¡on ¡Computer ¡Science ¡and ¡So>ware ¡Engineering, ¡2012 ¡

Mo0va0on ¡to ¡Assurances ¡for ¡ Self-‑adapta0on ¡

SLIDE 106

Assurances ¡for ¡Self-‑adap0ve ¡Systems ¡

Mo0va0on ¡to ¡assurances ¡for ¡self-‑adap0ve ¡

systems ¡

A ¡selec0on ¡of ¡formal ¡approaches ¡to ¡self-‑

adapta0on ¡ ¡

Perpetual ¡assurances ¡

SLIDE 107

A ¡Selec0on ¡of ¡Formal ¡Approaches ¡to ¡ Architecture-‑based ¡Self-‑adapta0on ¡ ¡

2006: ¡Zhang ¡& ¡Cheng ¡(design ¡0me ¡verifica0on ¡

and ¡model ¡transforma0on) ¡

2009: ¡Epifani ¡et ¡al. ¡(models ¡at ¡run0me) ¡ ¡
2011: ¡Calinescu ¡et ¡al. ¡(verifica0on ¡at ¡run0me) ¡
2013: ¡Ghezzy ¡et ¡al. ¡(model ¡interpreta0on) ¡
2014: ¡I>ikhar ¡et ¡al. ¡(executable ¡formal ¡models) ¡

SLIDE 108

Design ¡Time ¡Verifica0on ¡and ¡Model ¡ Transforma0on ¡

Ensure ¡that ¡adap0ve ¡program ¡func0ons ¡

correctly ¡during ¡and ¡a(er ¡adapta0ons ¡ ¡

Process ¡to ¡construct ¡and ¡verify ¡adapta0on ¡

models, ¡and ¡then ¡generate ¡adap0ve ¡programs ¡ ¡

Model-‑driven ¡process ¡with ¡focus ¡on ¡behavior ¡
f ¡adap0ve ¡programs ¡

¡

J. ¡Zhang ¡and ¡B. ¡Cheng, ¡Model-‑based ¡development ¡of ¡dynamically ¡adap0ve ¡so>ware, ¡Interna0onal ¡

Conference ¡on ¡So>ware ¡Engineering, ¡ICSE ¡2006 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

SLIDE 109

Design ¡Time ¡Verifica0on ¡and ¡ ¡ Model ¡Transforma0on ¡

gsm(x) x x x x x z x y [i,x,y,z] dataX index dataSource x [i,x,y,z] i send encode network 1 i+1 shiftY dataY shiftX dataZ encodedData

place transition shared place arc

readData inputData x GSM(x) x x x y y x y [i,x,y,z,t] inputData dataX x [i,x,y,z,t] z z z x encodedData send 1 i+1 network t shiftY shiftZ dataZ dataT dataY shiftX encode i readData dataSource index

Sender ¡of ¡audio ¡stream ¡applica0on ¡ has ¡to ¡work ¡in ¡domains ¡with ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ low ¡loss ¡rate ¡and ¡higher ¡loss ¡rate ¡

SLIDE 110

Design ¡Time ¡Verifica0on ¡and ¡ ¡ Model ¡Transforma0on ¡

One-‑point ¡adapta0on: ¡source ¡ behavior ¡should ¡complete, ¡before ¡ the ¡target ¡behavior ¡should ¡start ¡ ¡ The ¡“adapt” ¡transi0on ¡models ¡the ¡ set ¡of ¡adap0ve ¡transi0ons ¡ ¡ Quiescent ¡states ¡are ¡the ¡markings ¡ that ¡enable ¡the ¡“adapt” ¡transi0on ¡ ¡ Model ¡checking ¡allows ¡verifying ¡the ¡ model; ¡e.g., ¡

dataX dataY send network readData inputData dataX dataY dataZ dataT 1 network send y1 z1 1 [i,x,y,z] z z1 y1 empty Sender Source Model Sender Target Model readData dataSource i+1 index inputData encode x dataSource

adapt

encodedData dataZ [i,x,y,z,0] encodedData encode index

♦(dataSource = empty) ∧ ✷(read(x) → ♦send(x))

SLIDE 111

Design ¡Time ¡Verifica0on ¡and ¡ ¡ Model ¡Transforma0on ¡

Alterna0ve ¡types ¡of ¡adapta0on ¡are ¡“guided ¡

adapta0on” ¡(temporal ¡restricted ¡mode) ¡and ¡ “overlap ¡adapta0on” ¡(temporal ¡parallel) ¡ ¡

Models ¡are ¡used ¡to ¡generate ¡executable ¡code ¡

– adapt ¡transi0on ¡is ¡mapped ¡to ¡adapt ¡func0on ¡

Model-‑based ¡tes0ng ¡allows ¡assuring ¡that ¡the ¡

model ¡is ¡correctly ¡implemented ¡

SLIDE 112

A ¡Selec0on ¡of ¡Formal ¡Approaches ¡to ¡ Architecture-‑based ¡Self-‑adapta0on ¡ ¡

2006: ¡Zhang ¡& ¡Cheng ¡(design ¡0me ¡verifica0on ¡

and ¡model ¡transforma0on) ¡

2009: ¡Epifani ¡et ¡al. ¡(models ¡at ¡run0me) ¡ ¡
2011: ¡Calinescu ¡et ¡al. ¡(verifica0on ¡at ¡run0me) ¡
2013: ¡Ghezzy ¡et ¡al. ¡(model ¡interpreta0on) ¡
2014: ¡I>ikhar ¡et ¡al. ¡(executable ¡formal ¡models) ¡

SLIDE 113

Probabilis0c ¡Models ¡at ¡Run0me ¡

Model ¡es0mates ¡are ¡seldom ¡correct ¡ ¡
In ¡dynamic ¡environments, ¡the ¡values ¡of ¡model ¡

parameters ¡may ¡change ¡over ¡0me ¡

Run0me ¡models ¡updated ¡with ¡data ¡collected ¡

from ¡the ¡running ¡system ¡

Supports ¡run0me ¡analysis ¡of ¡the ¡model ¡

¡

I. ¡Epifani, ¡C. ¡Ghezzi, ¡R. ¡Mirandola, ¡and ¡G. ¡Tamburrelli. ¡2009. ¡Model ¡evolu0on ¡by ¡run-‑0me ¡parameter ¡

adapta0on, ¡Interna0onal ¡Conference ¡on ¡So>ware ¡Engineering, ¡ICSE ¡2009 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

SLIDE 114

Probabilis0c ¡Models ¡at ¡Run0me ¡

KAMI: ¡Keep ¡Alive ¡Models ¡with ¡Implementa0ons ¡
Focus ¡on ¡non-‑func0onal ¡proper0es ¡modeled ¡e.g., ¡

with ¡Discrete ¡Time ¡Markov ¡Chains ¡

Verifiable ¡with ¡probabilis0c ¡model ¡checker ¡ ¡
Bayesian ¡technique ¡to ¡re-‑es0mate ¡probabili0es ¡

Modeling Initial Estimates Implementation Bayesian Estimation Refined Estimates Runtime Data QoS Requirements

SLIDE 115

Probabilis0c ¡Models ¡at ¡Run0me ¡

Example: ¡Tele ¡Assistance ¡Service ¡(TAS) ¡ ¡
Model ¡represents ¡the ¡structure ¡of ¡the ¡ ¡ ¡ ¡

TAS ¡process ¡

Probabili0es ¡to ¡branches ¡and ¡failure ¡

probabili0es ¡to ¡service ¡invoca0ons ¡ ¡

Allows ¡verifying ¡proper0es ¡such ¡as: ¡ ¡

– The ¡probability ¡P1 ¡that ¡no ¡failures ¡ever ¡

ccurs ¡is ¡greater ¡then ¡0.7 ¡ ¡
Run0me ¡detec0ng ¡or ¡predic0ng ¡of ¡

viola0ons ¡of ¡desired ¡proper0es ¡

a

0.1

b d

0.6 vitalParamsMsg

c

stopMsg

h

1 0.3

l m

0.41 0.45

g

1

1

0.04 0.02 0.01

f

Exit 1 1 0.99 0.98 Init 0.02

n

FailedAlarm 1

p

1

q

1 FailedChangeDrug FailedChangeDose changeDrug FailedAnlysis 0.12

i

FAS 0.96 1 pButtonMsg analyzeData

e

1 notifyPA alarm changeDoses

SLIDE 116

A ¡Selec0on ¡of ¡Formal ¡Approaches ¡to ¡ Architecture-‑based ¡Self-‑adapta0on ¡ ¡

2006: ¡Zhang ¡& ¡Cheng ¡(design ¡0me ¡verifica0on ¡

and ¡model ¡transforma0on) ¡

2009: ¡Epifani ¡et ¡al. ¡(models ¡at ¡run0me) ¡ ¡
2011: ¡Calinescu ¡et ¡al. ¡(verifica0on ¡at ¡run0me) ¡
2013: ¡Ghezzy ¡et ¡al. ¡(model ¡interpreta0on) ¡
2014: ¡I>ikhar ¡et ¡al. ¡(executable ¡formal ¡models) ¡

SLIDE 117

Quan0ta0ve ¡Verifica0on ¡at ¡Run0me ¡

Monitoring ¡and ¡Bayesian-‑based ¡parameter ¡

adap0on ¡of ¡the ¡(Markovian) ¡QoS ¡models ¡ ¡

Formal ¡specifica0on ¡of ¡QoS ¡requirements ¡with ¡

probabilis0c ¡temporal ¡logics ¡

Techniques ¡for ¡verifica0on ¡of ¡goals ¡at ¡run-‑0me ¡ ¡
Run-‑0me ¡reconfigura0on ¡and ¡resource ¡

assignment ¡

¡

R. ¡Calinescu, ¡L. ¡Grunske, ¡M. ¡Kwiatkowska, ¡R. ¡Mirandola, ¡and ¡G. ¡Tamburrelli. ¡Dynamic ¡QoS ¡Management ¡

and ¡Op0miza0on ¡in ¡Service-‑Based ¡Systems, ¡IEEE ¡Transac0ons ¡on ¡So>ware ¡Engineering, ¡TSE ¡2011 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

SLIDE 118

Quan0ta0ve ¡Verifica0on ¡at ¡Run0me ¡

Monitoring ¡performance ¡(e.g., ¡response ¡0me) ¡and ¡dependability ¡

(e.g., ¡failure ¡rate) ¡+ ¡workload ¡and ¡allocated ¡resources ¡ ¡

Periodically ¡or ¡event-‑based ¡ ¡
Update ¡QoS ¡model ¡ ¡

SLIDE 119

Quan0ta0ve ¡Verifica0on ¡at ¡Run0me ¡

Verify ¡QoS ¡requirements ¡with ¡updated ¡QoS ¡model ¡using ¡model ¡checking ¡at ¡run0me ¡
Configura0ons ¡that ¡sa0sfy ¡the ¡QoS ¡requirements ¡for ¡the ¡system ¡

SLIDE 120

Quan0ta0ve ¡Verifica0on ¡at ¡Run0me ¡

¡

Build ¡a ¡plan ¡for ¡adap0ng ¡the ¡system ¡configura0on ¡ ¡
E.g. ¡change ¡workflow ¡or ¡modify ¡resources ¡allocated ¡to ¡services ¡

SLIDE 121

Quan0ta0ve ¡Verifica0on ¡at ¡Run0me ¡

¡

Execute ¡the ¡plan ¡
E.g. ¡dynamically ¡adapt ¡the ¡workflow ¡using ¡the ¡underlying ¡pla‚orm; ¡start, ¡stop ¡or ¡

migrate ¡virtual ¡machines, ¡or ¡use ¡dedicated ¡resource ¡management ¡mechanisms ¡

SLIDE 122

A ¡Selec0on ¡of ¡Formal ¡Approaches ¡to ¡ Architecture-‑based ¡Self-‑adapta0on ¡ ¡

2006: ¡Zhang ¡& ¡Cheng ¡(design ¡0me ¡verifica0on ¡

and ¡model ¡transforma0on) ¡

2009: ¡Epifani ¡et ¡al. ¡(models ¡at ¡run0me) ¡ ¡
2011: ¡Calinescu ¡et ¡al. ¡(verifica0on ¡at ¡run0me) ¡
2013: ¡Ghezzy ¡et ¡al. ¡(model ¡interpreta0on) ¡
2014: ¡I>ikhar ¡et ¡al. ¡(executable ¡formal ¡models) ¡

SLIDE 123

Model ¡Interpreta0on ¡

Derives ¡from ¡an ¡ini0al ¡system ¡model ¡a ¡finite ¡

state ¡automaton ¡augmented ¡with ¡probabili0es ¡

Interpreter ¡navigates ¡automaton ¡and ¡invokes ¡

components ¡associated ¡to ¡states ¡it ¡traverses ¡

Interpreter ¡chooses ¡among ¡alterna0ve ¡paths ¡of ¡

automaton ¡maximizing ¡the ¡system’s ¡u0lity ¡ ¡ ¡

¡

C. ¡Ghezzi, ¡L.S. ¡Pinto, ¡P. ¡Spole0ni, ¡G. ¡Tamburrelli: ¡Managing ¡non-‑func0onal ¡uncertainty ¡via ¡model-‑driven ¡

adap0vity, ¡Interna0onal ¡Conference ¡on ¡So>ware ¡Engineering, ¡ICSE ¡2013 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

SLIDE 124

Model ¡Interpreta0on ¡

¡

Annotated ¡UML ¡diagram ¡models ¡response ¡0me, ¡etc. ¡of ¡different ¡execu0on ¡paths ¡ ¡
Diagram ¡is ¡automa0cally ¡translated ¡to ¡Markov ¡decision ¡process ¡
Interpreter ¡guides ¡the ¡execu0on ¡of ¡the ¡system ¡using ¡the ¡model ¡ ¡
Cumula0ve ¡reward ¡is ¡used ¡to ¡select ¡path ¡with ¡highest ¡u0lity ¡
Adapta0on ¡logic ¡is ¡encoded ¡in ¡ad-‑hoc ¡interpreter ¡ ¡

7 c g h

RT=0.5s E=2 U=1 RT=0.3s E=1 U=1 RT=0.8s E=2 U=1 RT=2s E=3 U=1

8

RT=0.6s E=2 U=1

6a 12 e f 13

RT=0s E=1 U=0 0.7 0.3

5a 5b

RT=0s E=1 U=0

d Developer UML Activity Diagrams Implementations

generates

invokes executes uses annotates designs uses Embedded Model … … … … … … Interpreter PRISM uses Generator

SLIDE 125

A ¡Selec0on ¡of ¡Formal ¡Approaches ¡to ¡ Architecture-‑based ¡Self-‑adapta0on ¡ ¡

2006: ¡Zhang ¡& ¡Cheng ¡(design ¡0me ¡verifica0on ¡

and ¡model ¡transforma0on) ¡

2009: ¡Epifani ¡et ¡al. ¡(models ¡at ¡run0me) ¡ ¡
2011: ¡Calinescu ¡et ¡al. ¡(verifica0on ¡at ¡run0me) ¡
2013: ¡Ghezzy ¡et ¡al. ¡(model ¡interpreta0on) ¡
2014: ¡I>ikhar ¡et ¡al. ¡(executable ¡formal ¡models) ¡

SLIDE 126

Executable ¡Formal ¡Models ¡

¡

Focus ¡on ¡guarantees ¡of ¡adapta0on ¡func0ons ¡

(compared ¡to ¡QoS ¡requirements) ¡ ¡

MAPE ¡func0ons ¡formally ¡specified ¡and ¡verified ¡ ¡
Models ¡directly ¡executed ¡using ¡virtual ¡machine ¡
No ¡error-‑prone ¡process ¡of ¡coding ¡
Formal ¡run0me ¡models ¡support ¡con0nuous ¡

verifica0on ¡ ¡

¡

M. ¡U. ¡I>ikhar, ¡D. ¡Weyns: ¡Ac0vFORMS: ¡ac0ve ¡formal ¡models ¡for ¡self-‑adapta0on, ¡Interna0onal ¡Symposium ¡

in ¡So>ware ¡Engineering ¡of ¡Adap0ve ¡and ¡Self-‑Managing ¡Systems, ¡SEAMS ¡2014 ¡ ¡

SLIDE 127

Executable ¡ Formal ¡Models ¡

SLIDE 128

Executable ¡ Formal ¡Models ¡

Digital ¡Story ¡Telling ¡Applica0on ¡ ¡

SLIDE 129

Executable ¡Formal ¡Models ¡

Digital ¡Story ¡Telling ¡Applica0on ¡ ¡

F

r

P e e r R e v i e w

F

r

P e e r R e v i e w

For Peer Review

//Managed System Knowledge const int TOTAL_NB_OF_ALGS = 11; const int REQUIRED_NB_OF_ALGS_USED = 5; typedef struct { ... } Algorithm; Algorithm algs[TOTAL_NB_OF_ALGS]; int currentNbOfAlgsUsed; //number of algorithms bool gpsStatus; //TRUE=on, FALSE=off

F

r

P e e r R e v i e w

For Peer Review

... } Algorithm;

SLIDE 130

Executable ¡Formal ¡Models ¡

For Peer Review

P2r MonitorRatings.PhotoPickedByUser --> Analyze.AlgorithmsSorted P2s MonitorGPS.ChangeGPS_Status --> Analyze.GPS_FlickrStatusAnalyzed P3 Analyze.AdaptationNeeded --> Planning.CreatePlan

Digital ¡Story ¡Telling ¡Applica0on ¡ ¡

F

r

P e e r R e v i e w

F

r

P e e r R e v i e w

For Peer Review

//Managed System Knowledge const int TOTAL_NB_OF_ALGS = 11; const int REQUIRED_NB_OF_ALGS_USED = 5; typedef struct { ... } Algorithm; Algorithm algs[TOTAL_NB_OF_ALGS]; int currentNbOfAlgsUsed; //number of algorithms bool gpsStatus; //TRUE=on, FALSE=off

F

r

P e e r R e v i e w

For Peer Review

... } Algorithm;

SLIDE 131

P8 A[] currentNbOfAlgsUsed==5

Executable ¡Formal ¡Models ¡

For Peer Review

P2r MonitorRatings.PhotoPickedByUser --> Analyze.AlgorithmsSorted P2s MonitorGPS.ChangeGPS_Status --> Analyze.GPS_FlickrStatusAnalyzed P3 Analyze.AdaptationNeeded --> Planning.CreatePlan

Digital ¡Story ¡Telling ¡Applica0on ¡ ¡

F

r

P e e r R e v i e w

F

r

P e e r R e v i e w

For Peer Review

//Managed System Knowledge const int TOTAL_NB_OF_ALGS = 11; const int REQUIRED_NB_OF_ALGS_USED = 5; typedef struct { ... } Algorithm; Algorithm algs[TOTAL_NB_OF_ALGS]; int currentNbOfAlgsUsed; //number of algorithms bool gpsStatus; //TRUE=on, FALSE=off

F

r

P e e r R e v i e w

For Peer Review

... } Algorithm;

SLIDE 132

Executable ¡ Formal ¡Models ¡

Com pl ete Redundant I ncom pl ete SH_MVD_Com pl ete[Mi d]! SH_MVD_Redundant[Mi d]! Anal yz i ng SAm vdStruct[Mi d]. acti vi ty1 . num ber_GP S < SAm vdStruct[Mi d]. nMem bers SAm vdStruct[Mi d]. acti vi ty1 . num ber_GP S == SAm vdStruct[Mi d]. nMem bers SAm vdStruct[Mi d]. acti vi ty1 . num ber_GP S > SAm vdStruct[Mi d]. nMem bers SH_MVD_I ncom pl ete[Mi d]!

SH_MVD_Redundant[Mi d]? SH_MVD_Redundant[Mi d]? SH_MVD_Com pl ete[Mi d]? SH_MVD_I ncom pl ete[Mi d]? SH_MVD_Com pl ete[Mi d]? addP hone[found_P hone]! L

ok

F

rF

reeGP S Al l F i ne NoF reeGP S found_P hone ! = NOP HONE targetedMVD = Mi d found_P hone == NOP HONE found_P hone = getF reeP hone() found_P hone = getF reeP hone() GPS Accuracy Error Time 10 20 30 40 50 60 3 6 9 12 15 Task-2 req. Task-1 req. Task-1 Task-2

MVDSHPlan(1).LookForFreeGPS R5: MVDSHPlan(1).LookForFreeGPS --> MVDSHPlan(1).AllFine R6: MVDSHAnalyze(1).Incomplete -->

R8: MASphoneStruct[2].GPS_Service == DEACTIVATED && MVDSHPlan(1).found_Phone == 2 --> MASmvdStruct[1].member[2] == NOT_USED && MVDSHPlan(1).found_Phone != 2 R9:A[] forall(Pid:phone_id) forall(Mid1:MVD_id)

Mobile ¡Learning ¡Applica0on ¡ ¡

SLIDE 133

Assurances ¡for ¡Self-‑adap0ve ¡Systems ¡

Mo0va0on ¡to ¡assurances ¡for ¡self-‑adapta0on ¡
A ¡selec0on ¡of ¡formal ¡approaches ¡to ¡self-‑

adapta0on ¡ ¡

Perpetual ¡assurances ¡

SLIDE 134

Perpetual ¡Assurances ¡

“Providing ¡evidence ¡for ¡requirements ¡compliance ¡through ¡an ¡ enduring ¡process ¡that ¡con8nuously ¡provides ¡new ¡evidence ¡by ¡ combining ¡system-‑driven ¡and ¡human-‑driven ¡ac8vi8es ¡to ¡deal ¡ with ¡the ¡uncertain8es ¡that ¡the ¡system ¡faces ¡across ¡its ¡life8me.” ¡ ¡

D. ¡Weyns, ¡N. ¡Bencomo, ¡R. ¡Calinescu, ¡J. ¡Camara, ¡C. ¡Ghezzi, ¡V. ¡Grassi, ¡L. ¡Grunske, ¡P. ¡Inverardi, ¡J.M. ¡Jezequel, ¡
S. ¡Malek, ¡R. ¡Mirandola, ¡M. ¡Mori, ¡and ¡G. ¡Tamburrelli, ¡Perpetual ¡Assurances ¡in ¡Self-‑Adap0ve ¡Systems, ¡

Working ¡Group ¡Report ¡-‑ ¡Dagstuhl ¡Seminar ¡13511, ¡2015 ¡

¡

SLIDE 135

Perpetual ¡Assurances ¡

Table&2

Requirement Brief description

R1: Monitor uncertainty A perpetual assurance solution must continually observe the sources of uncertainty affecting the self-adaptive system. R2: Quantify uncertainty A perpetual assurance solution must use its observations of uncertainty sources to continually quantify and potentially reduce the uncertainties affecting its ability to provide assurance evidence. R3: Manage overlapping uncertainty sources A perpetual assurance solution must continually deal with overlapping sources of uncertainty and may need to treat these sources in a composable fashion. R4: Derive new evidence A perpetual assurance solution must continually derive new assurance evidence arguments. R5: Integrate new evidence A perpetual assurance solution must continually integrate new evidence into the assurance arguments for the safe behavior of the assured self-managing system. R6: Combine heterogeneous evidence A perpetual assurance solution may need to continually combine new assurance evidence synthesized automatically and provided by human experts. R7: Provide evidence for the elements and activities that realize R1-R6 A perpetual assurance solution must provide assurance evidence for the system components, the human activities, and the processes used to meet the previous set of requirements. R8: Produce timely updates The activities carried out by a perpetual assurance solution must produce timely updates of the assurance arguments. R9: Limited overhead The activities of the perpetual assurance solution and their overheads must not impact the operation of the assured self-adaptive system. R10: Auditable arguments The assurance evidence produced by a solution and the associated assurance arguments must be auditable by human stakeholders.

SLIDE 136

Perpetual ¡Assurances ¡

Variety ¡of ¡assurance ¡approaches, ¡including: ¡
Key ¡challenge: ¡turn ¡these ¡approaches ¡into ¡a ¡

working ¡reality ¡for ¡perpetual ¡assurances ¡

Group Approaches

Human-driven approaches

Formal proof
Simulation

System-driven approaches

Runtime verification
Sanity checks
Contracts

Hybrid approaches

Model checking
Testing

SLIDE 137

Perpetual ¡Assurances ¡

Func0onal ¡requirements ¡(R1 ¡to ¡R7) ¡

– How ¡to ¡collect ¡assurance ¡evidence ¡arguments ¡at ¡ run0me ¡and ¡compose ¡them ¡with ¡the ¡evidence ¡ acquired ¡throughout ¡the ¡life0me ¡of ¡the ¡system? ¡

Quality ¡requirements ¡(R8 ¡to ¡R10) ¡ ¡

– How ¡to ¡make ¡solu0ons ¡efficient ¡and ¡support ¡the ¡ interchange ¡of ¡evidence ¡arguments ¡between ¡the ¡ system ¡and ¡users ¡ ¡

SLIDE 138

Outline ¡of ¡the ¡tutorial ¡

1. Mo0va0on ¡for ¡self-‑adapta0on ¡
2. Architecture-‑based ¡approaches ¡to ¡self-‑

adapta0on ¡

3. Assurances ¡for ¡self-‑adap0ve ¡systems ¡
4. Towards ¡"Design ¡for ¡Sustainability" ¡

SLIDE 139

Towards ¡“Design ¡for ¡Sustainability” ¡

Posi0on ¡& ¡mo0va0on ¡
AdEpS ¡model ¡ ¡
Engineering ¡principles ¡ ¡
Reflec0ons ¡

SLIDE 140

Posi0on ¡

“Con0nuous ¡change ¡changes ¡everything” ¡
Uncertain0es ¡may ¡harm ¡the ¡sustainability ¡of ¡so>ware ¡systems ¡ ¡
Calls ¡for ¡a ¡radical ¡change ¡in ¡the ¡way ¡so>ware ¡is ¡developed ¡and ¡
perated ¡ ¡

Sustainability ¡of ¡so>ware ¡systems ¡requires ¡design ¡for ¡sustainability ¡

D. ¡Weyns, ¡M. ¡Caporuscio, ¡B. ¡Vogel, ¡A. ¡Kur0, ¡Design ¡for ¡Sustainability ¡= ¡Run0me ¡Adapta0on ¡U ¡Evolu0on, ¡

Sustainable ¡Architecture: ¡Global ¡collabora0on, ¡Requirements, ¡Analysis, ¡SAGRA ¡2015 ¡

SLIDE 141

Mo0va0on ¡

Tradi0onal ¡driving ¡engineering ¡principle ¡= ¡ ¡

¡ ¡ ¡ ¡ ¡Design ¡for ¡Reuse ¡ ¡

Reuse ¡puts ¡the ¡stable ¡parts ¡of ¡so>ware ¡central ¡
Domina0ng ¡parts ¡of ¡modern ¡so>ware ¡systems ¡

are ¡the ¡changing ¡parts ¡

Con0nuous ¡change ¡calls ¡for ¡adapta0on ¡and ¡

evolu0on ¡as ¡drivers ¡in ¡so>ware ¡design ¡ ¡ ¡

SLIDE 142

Mo0va0on ¡

Evolu0on ¡and ¡adapta0on ¡mainly ¡tackled ¡

separately ¡(at ¡design ¡and ¡run0me ¡respec0vely) ¡

Design ¡for ¡Sustainability ¡ ¡

¡

– Seamless ¡integra0on ¡of ¡run0me ¡adapta0on ¡and ¡ evolu0on ¡(AdEpS ¡model) ¡ – Design ¡so>ware ¡to ¡facilitate ¡this ¡seamless ¡ integra0on ¡(engineering ¡principles) ¡

¡

SLIDE 143

Towards ¡“Design ¡for ¡Sustainability” ¡

Posi0on ¡& ¡mo0va0on ¡
AdEpS ¡model ¡ ¡
Engineering ¡principles ¡ ¡
Reflec0ons ¡

SLIDE 144

AdEpS ¡model ¡ ¡

Grounded ¡in ¡Oreizy`s ¡

model ¡

Adapta0on ¡management: ¡

keep ¡sa0sfying ¡goals ¡

Evolu0on ¡management: ¡

handle ¡goal ¡changes ¡ ¡

SLIDE 145

AdEpS ¡model ¡ ¡

Grounded ¡in ¡model ¡of ¡

[Oreizy ¡et ¡al. ¡1999] ¡

Adapta0on ¡management: ¡

keep ¡sa0sfying ¡goals ¡

Evolu0on ¡management: ¡

handle ¡goal ¡changes ¡ ¡

Running ¡ robot ¡code ¡ Reflec0ve ¡model ¡ for ¡env. ¡explora0on ¡ Robot ¡code ¡ Architectural ¡views ¡ robot ¡system ¡ ¡

SLIDE 146

AdEpS ¡model ¡ ¡

Grounded ¡in ¡model ¡of ¡

[Oreizy ¡et ¡al. ¡1999] ¡

Adapta0on ¡management: ¡

keep ¡sa0sfying ¡goals ¡

Evolu0on ¡management: ¡

handle ¡goal ¡changes ¡ ¡

SLIDE 147

AdEpS ¡model ¡ ¡

Grounded ¡in ¡model ¡of ¡

[Oreizy ¡et ¡al. ¡1999] ¡

Adapta0on ¡management: ¡

keep ¡sa0sfying ¡goals ¡

Evolu0on ¡management: ¡

handle ¡goal ¡changes ¡ ¡

1. ¡Detect ¡need ¡for ¡

new ¡roadmap ¡

SLIDE 148

AdEpS ¡model ¡ ¡

Grounded ¡in ¡model ¡of ¡

[Oreizy ¡et ¡al. ¡1999] ¡

Adapta0on ¡management: ¡

keep ¡sa0sfying ¡goals ¡

Evolu0on ¡management: ¡

handle ¡goal ¡changes ¡ ¡

1. ¡Detect ¡need ¡for ¡

new ¡roadmap ¡

2. ¡Analyze ¡context ¡ ¡

SLIDE 149

AdEpS ¡model ¡ ¡

Grounded ¡in ¡model ¡of ¡

[Oreizy ¡et ¡al. ¡1999] ¡

Adapta0on ¡management: ¡

keep ¡sa0sfying ¡goals ¡

Evolu0on ¡management: ¡

handle ¡goal ¡changes ¡ ¡

1. ¡Detect ¡need ¡for ¡

new ¡roadmap ¡

3. ¡Compute ¡new ¡roadmap ¡ ¡
2. ¡Analyze ¡context ¡ ¡

SLIDE 150

AdEpS ¡model ¡ ¡

Grounded ¡in ¡model ¡of ¡

[Oreizy ¡et ¡al. ¡1999] ¡

Adapta0on ¡management: ¡

keep ¡sa0sfying ¡goals ¡

Evolu0on ¡management: ¡

handle ¡goal ¡changes ¡ ¡

4. ¡Update ¡roadmap ¡
1. ¡Detect ¡need ¡for ¡

new ¡roadmap ¡

3. ¡Compute ¡new ¡roadmap ¡ ¡
2. ¡Analyze ¡context ¡ ¡

SLIDE 151

AdEpS ¡model ¡ ¡

Grounded ¡in ¡model ¡of ¡

[Oreizy ¡et ¡al. ¡1999] ¡

Adapta0on ¡management: ¡

keep ¡sa0sfying ¡goals ¡

Evolu0on ¡management: ¡

handle ¡goal ¡changes ¡ ¡

4. ¡Update ¡roadmap ¡
1. ¡Detect ¡need ¡for ¡

new ¡roadmap ¡

3. ¡Compute ¡new ¡roadmap ¡ ¡
2. ¡Analyze ¡context ¡ ¡

SLIDE 152