PhD Defense

Transcript

1. Brice MORIN, Ph. D. Defense, September 17th 2010 Advisor: Jean-Marc

   JEZEQUEL Co-Advisor: Olivier BARAIS 1

2. 2

3.  Complex Adaptive Systems  e.g. DiVA project  Available

   24/7  Should adapt to the current context  Long-living systems  Should adapt to the evolving needs of users 3

4.  Dynamic Customer Relationship Management system (from DiVA, by CAS)

    When the user (sales man) works in his office  Rich UI  No filter on the notifications  All communication channels available  …  When the user is driving (to visit a client)  Reduced UI on his SmartPhone  Filter on the notifications  Communication channel = SmartPhone  …  When the user is meeting his client  … 4

5. 5

6. 1. Combinatorial explosion  millions or billions configurations/transitions  rules

   to describe the adaptation logic 2. Adaptation logic  how to avoid continuous oscillation (stability Vs reactivity) 3. Validation, automation  how to validate every configuration before actual adaptation, with no need to specify all the possible configurations  how to fully automate the actual reconfiguration, with no need to write low-level platform-specific scripts 6

7.  Compositional Adaptation, Reflective Middleware  Philip K. McKinley, Composing

   Adaptive Software, IEEE Computer, July 2004  Gordon S. Blair et al., The Role of Software Architecture in Constraining Adaptation in Component-based Middleware Platforms, Middleware 2000.  Focus on two types of approaches  MDE for developing adaptive systems  Aspect-Oriented approaches  More approaches in the manuscript 7 We rely on these platform-level adaptation mechanisms. - no new adaptation mechanism -  offer abstraction and control over these mechanisms

8.  Explicit representation of  All possible configurations  All

   possible transitions  See Zhang et al., Bencomo et al. + + - - • Extensive validation at design-time • Code generation • Not scalable • Not so dynamic 8

9.  Here, an aspect is either  The encapsulation of

   a reconfiguration script (SAFRAN)  An AspectJ-like aspect (FAC, AOpenCOM)  See David et al., Pessemier et al. + + - - •Variability Management • Rather low-level • Script/Aspect interaction • No validation a priori 9

10. 10

11.  Introspection is the ability of a program to observe

    and therefore reason about its own state.  Intercession is the ability of a program to modify its own execution state or alter its own interpretation or meaning. - Daniel G. Bobrow et al. 11  If you know your enemies and know yourself, you can win a hundred battles without a single loss.  If you only know yourself, but not your opponent, you may win or may lose.  If you know neither yourself nor your enemy, you will always endanger ourself. - Sun Tzu, The Art of War, 6th Century BC

12. Running System Meta-level (‘‘model’’) (Strong) Causal Link 12

13. “Modeling allows us to use something that is simpler, safer

    or cheaper than reality to avoid the complexity, danger and irreversibility of reality.’’ 13 Jeff Rothenberg

14. Running System Reflection Model  “Thinking allows beings to model

    the world and to deal with it according to their objectives, plans, ends and desires” –Wikipedia 14 Uncoupled Model

15. REFLECTION  What happens if I do…?  Just do

    it!  Two possible results  OK  Not OK  Rollback, Retry «INTELLIGENT» REFLECTION  What would happen if I would do…?  Just think about it!  Two possible results  OK  Not OK  Discard the model, Build another model 15

16. 16

17. 1. Precise Modeling of DAS Taming DAS via Abstraction 2.

    AOM to refine and Compose Features Taming DAS via (De)Composition 3. MDE to link design-time and runtime Taming DAS via Automation 17
18. None
19. None

20. 20

21. 21

22. 22

23. 23

24. 24

25. F(Variability, Env/Context) 25

26. Available rules: variant implies context e.g. PHON implies not(MODE=BUSY) Required

    rules: context implies variant e.g. MODE=DRIV implies PHON 26

27. F(Variability, Env/Context) 27

28. 28

29. 29 D-CRM Notification Comm. Channel … POPN MAILN SMSN PHON

    Text Voice [1..1] [0..n] Aspect Model Model Composition Woven Configuration Variability Model SmartAdapters

30.  Generic/Generative AOM   AOM for any DSML 

    Aspect Model  Where?  Pointcut model = model fragment  What?  Advice model = model fragment  How?  Composition protocol = imperative script 30

31. 31 DrivingNotifier Forward Telephony VoiceChannel Advice model AddressDB Pointcut model

    ? INotification INotification

32.  Performances  AOM usually employed at design-time  Expressiveness

     Multiple join points  Adoption/Ease of use and Tool Support  Approach and Tools to be used by external people ▪ e.g. , industrial partners of the DiVA project  Agility  Evolution of metamodels, platforms  Iterative approach (research project) 32

33. 33 Meta-code generator code generator Metamodel (conforms to MOF) Aspect

    Model (conforms to Metamodel) MOF (M3 Level) Metamodel (M2 Level) require require Java EMF + Drools* code produces produces *Drools (JBoss Rules) (meta-) metamodels input (meta-)models Written in Kermeta/KET Visitor on the metamodel: - 2 passes for the pointcut - 2 passes for the advice

34. 34 Java EMF +Drools code Runtime AOM Weaver In memory

    base model In memory woven model

35. Logger Any Pointcut Advice + Composition Protocol Logger Logger A

    B C Logger A B C Logger is unique Binding are « per join point »

36. A B C D E Logger

37. A B C D E Logger Logger Logger is unique

    in the scope of a composite component. Bindings are per join points

38. 38 Morin, Klein, Kienzle and Jézéquel, MODELS’10

39.  Adoption/Ease of Use   Directly rely on domain

    concepts (here, architecture)  Expressiveness  Flexible pointcut language (model snippet)  Advice Sharing  Performances   Compilation to Java/EMF + Drools  Weaving «in memory»  Agility   Generative techniques  Tool support   Integrated into DiVA Studio   Pointcut compiler also integrated into GeKo 39

40. 40 Architecture Metamodel Reflection model (source) Woven model (target) Conforms

    to Analyzer The running system adapts Causal link Strong synchronization introspection + listeners Delayed synchronization Validation Reasoning Context info. Context model Design- models

41. 41 Reflection Model (source) Target Model Removed Kept / Updated

    Added Migration Command Factory Platform-specific reconfiguration script validation STOP Component A STOP Component B … REMOVE Binding B1 REMOVE Binding B2 … REMOVE Component A REMOVE Component B … UPDATE Attribute A1 … ADD Component C ADD Component D … ADD Binding B3 ADD Binding B4 … START Component C START Component D

42.  Reflection model = a mirror of the reality 

    Target Model = independent from the reality, to avoid “the complexity, danger and irreversibility”  Seamless synchronization  Platform-independent  Generated Scripts  Safe w.r.t. lifecycle issues, client/server dependencies  Not obtimal ▪ Tend to maximize the unavailability of components that should be stopped and restarted 42

43.  Platform-independent, model-based layer  Causal link  Business system

     Components exchange models 43

44. 44 Reasoner Weaver Checker Monitoring Causal Link variability context reasoning

    variability architecture architecture Business System Platform-independent, Model-Based layer Proxy-Layer Business Layer Config. Cache architecture

45. 45

46. 1. CMS: Crisis Management System 2. EnTiMid: Home-Automation System 46

47.  Goal: handle crisis situations in an airport  Runs

    on FuseESB, based on OSGi  Designed and Implemented by Thales 47

48.  5 variability dimensions  20 variants/aspect models  Use

    the notion of advice sharing   30 720 possible configurations   943 687 680 possible transitions  20 ECA-like rules  8 Goals 48

49. 49 0 20 40 60 80 100 120 1 2

    3 4 5 3 aspects; 4 join points 6;16 Time to weave one aspect (ms) 8;26 9;32 6;16

50.  Home-automation system  Runs on OSGi on a MSI

    Wind (Intel Atom230@1.6GHz, 1Gb, Linux)  Developped within the Triskell team  Currently incubated 50

51. 51 1 2-a) 2-b) 2-c) 2-d) 2-a) 2-b) 2-c) 2-d)

52. 52 0 50 100 150 200 250 300 350 400

    450 500 1 2 3 4 5 6 7 8 9 Comparison Reconfiguration Time in ms

53. 53

54.  Architecture  Variability  Environment/Context  Reasoning (ECA-like +

    Goals) 54

55.  Both at design-time and runtime  Aspect-models to refine

    features  MDE to generate reconfiguration scripts 55

56.  Case-study conducted by external people  EnTiMid: Triskell’s home-automation

    system  DiVA (EU project) industrial partners  Initial contacts  Luxembourg: Resilient System + AOM  Spain: Robotics 56

57. 57

58.  Current generated reconfiguration scripts  Safe, but  Sub-optimal

     Use well-known planning algorithm  Parallel execution of actions  Minimize unavailability  PhD Thesis in Triskell/Myriads 58

59.  Use dual view aspects  Structure (architecture)  Behavior

     More advanced validation  Possibly more advanced adaptation See Kienzle, Klein et al. 59

60.  Infer the architecture from domain models, e.g., access control

     Flexible and Dynamic access control policies See Morin et al., ASE’10 60 RoleY UserX ResourceZ (any user of) RoleY can access the actionW of the ResourceZ actionW actionW UserX (of RoleY) can access the actionW of the ResourceZ

61.  Sensor networks can dynamically evolve  New device, device

    with no more battery  The software system should consider the evolution of the hardware  The software system could also drive the reconfiguration of the hardware  FPGA, turn on/off sensors, upload code to micro- controllers, etc My future work at SINTEF (MODERATES internal project) 61

62.  Book Chapter  Contribution to the AMPLE book (to

    be published in 2010)  Journal  IEEE Computer Special Issue on Models@Run.Time  Conferences (10)  ASE’10  ICSE’09  6 papers at MODELS since 2007  SEAA’10, CIT’09  Workshops/Demos (7)  Forum Demo at AOSD’10  3 papers/demos at Models@Runtime  + 3 others  Project Deliverables (6)  Reviews for journals, conferences, workshops (17) 62