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
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