1. Thesis defense presented by Cyril Ballagny Monday, March 8th 2010 Advisor: Franck Barbier Co-Advisor: Nabil Hameurlain MOCAS: a state-based component model for self-adaptation

2. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 2 Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

3. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 3 Management of systems The current complexity impedes the sole management by administrators Managed system SensorsEffectors Requires a control loop Requires a control loop Sensors for monitoring Administrator for taking decision Effectors for controlling Administrator Monitors Controls

4. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 4 Management system Autonomic systems Systems manage themselves [Horn, 2001] Systems manage themselves [Horn, 2001] In a closed control loop In an open control loop Managed system SensorsEffectors Administrator Monitors Controls Supervises Policy

5. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 5 Autonomic systems Minimize administrators intervention by Minimize administrators intervention by Self-Configuring to be ready to provide their services, whatever environment they are deployed in Self-Healing to prevent deficiencies and correct them if they occur Self-Optimizing to guarantee high performance Self-Protecting to defeat attacks Self-CHOP capabilities

6. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 6 Outline I.Context and problem 1.Self-managing systems 2.Adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

7. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 7 Self-adaptive systems Self-adaptation is the basis for enabling self-CHOP capabilities Self-adaptation is the basis for enabling self-CHOP capabilities Self-adaptive software evaluates its own behavior and changes behavior when the evaluation indicates that it is not accomplishing what the software is intended to do, or when better functionality or performance is possible. [Laddaga, 2000] Self-adaptive software modifies its own behavior in response to changes in its operating environment. [Oreizy et al., 1999] Self-adaptive systems modify their functioning in response to internal and external stimuli

8. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 8 Kinds of adaptation Structural adaptation Structural adaptation Logical: bindings between entities Spatial: locations of entities Behavioral adaptation Behavioral adaptation Implementation Interfaces Parameters

9. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 9 Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

10. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 10 System coherence [Moazami,1999] [Leger, 2009] Structural constraints must be respected (e.g. cardinality, matching of services) Structural constraints must be respected (e.g. cardinality, matching of services) Entities are in locally coherent states Entities are in locally coherent states Invariants of the system must hold true Invariants of the system must hold true

11. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 11 Moment for adapting a system Ad-hoc approach: particular execution points are tagged [Hofmeister, 1994] Ad-hoc approach: particular execution points are tagged [Hofmeister, 1994] General approach: condition of quiescence [Kramer & Magee,1990] General approach: condition of quiescence [Kramer & Magee,1990] Transactional approach Replacement of an entity depends on the state of other entities :A:B:C Adaptation is feasible

12. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 12 State transfert Transfert of attributes values (writing of exportation/importation operations) Transfert of attributes values (writing of exportation/importation operations) Transfert of execution point (e.g. saving call stack) Transfert of execution point (e.g. saving call stack) :A:B :C $i $j

13. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 13 Problems of current self-adaptive component-based systems Manage behavioral adaptation like structural adaptation Manage behavioral adaptation like structural adaptation Require passivation of several components Have control loops Have control loops Designed in an ad-hoc way With respect to the system to manage With respect to the desired self-* capabilities Centralized in a management infrastructure Closed (no support for unanticipated adaptation)

14. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 14 Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

15. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 15 Thesis: Reifying the structure and the behavior of software components as models improves adaptability of these components Thesis: Reifying the structure and the behavior of software components as models improves adaptability of these components Implication: Specification of the MOCAS component model relying on the UML component model and on UML state machines Implication: Specification of the MOCAS component model relying on the UML component model and on UML state machines Technologies & Tools: Technologies & Tools: MOCASEngine: an engine based on the Eclipse Modeling Framework for executing UML specification A complete toolkit for designing, developing and testing MOCAS components Overview of our contribution to the design of self-adaptive systems

16. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 16 Our vision of a software component Respects a component model Respects a component model Communicates through interfaces Communicates through interfaces Is configurable Is configurable Has an observable state Has an observable state Is composable Is composable A Provided interface Required interface Configuration interface

17. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 17 MOCAS component model a subset of the UML metamodel

18. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 18 Example of the dual clutch transmission system speedSensor: SpeedSensor gasSensor: GasSensor slopeSensor: SlopeSensor gearBox: GearBox lever: Lever

19. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 19 The GearBox component behavior GearBox /initMOCASProperties() Park Rear Neutral Drive Up Down Up Down Up Down First Second Third Fourth Fifth do/toFirst() do/toSecond() do/toFourth() do/toThird() do/toFifth() When f(speed,slope,gas)<-10 When f(speed,slope,gas)>10 When f(speed,slope,gas)>30 When f(speed,slope,gas)<-30 When f(speed,slope,gas)>20 When f(speed,slope,gas)<-40 When f(speed,slope,gas)<-20 When f(speed,slope,gas)>40

20. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 20 Structural composition of MOCAS components :GearBox:SpeedSensor :GasSensor :Lever :GearBox :Transmission « assembly » « delegate » Horizontal Horizontal Vertical (a.k.a hierarchic) Vertical (a.k.a hierarchic)

21. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 21 Behavioral composition of MOCAS components GearBox :Transmission « delegate »

22. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 22 First Second Event[guard]/effects entry/f1() do/toFirst() exit/f3() [speed>10] UML state machines: run-to-completion cycle Between two cycles, a MOCAS component is quiescent do/toSecond()

23. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 23 Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

24. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 24 Canonical behavior of a MOCAS component for managing adaptation: the container MOCASContainer /initMOCASProperties() behavior: MOCASBehavior AdaptMOCASComponent(attributes, context, behavior) [BehaviorIsConsistent and ContextIsConsistent and AttributesAreConsistent] /adaptMOCASComponent(attributs, context, behavior) DeferredAdaptMOCASComponent(attributes, context, behavior) /defer

25. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 25 Management of adaptation Adaptation is requested by sending a signal, in the same way as a functional service Adaptation is requested by sending a signal, in the same way as a functional service The component is quiescent between two run-to-completion cycles The component is quiescent between two run-to-completion cycles Adaptation is done without interrupting state activities (i.e. do/ notation) Adaptation is done without interrupting state activities (i.e. do/ notation)

26. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 26 Consistency of adaptation 1)The new state machine must own the last active state configuration Three variants of the behavior of a component V1 V2V3 A B C D A C E A C E F G

27. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 27 Consistency of adaptation 2)All the actions invoked by the state machine must exist in the functional context 3)All the attributes required by constraints are owned by the component or the triggering signal Drive First Second do/toFirst() do/toSecond() public class FunctionalContext{ public void toFirst(){…} public void toSecond(){…} } Drive First Second S[gas>10] [speed>0] OK OK GearBox speed : Integer gas : Integer OK OK

28. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 28 Ex.: Refinement of behavior New service New service Context with new actions Context with new actions New attributes New attributes

29. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 29 Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

30. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 30 MOCAS control loop profile

31. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 31 Structure of the autonomic container

32. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 32 Canonical behavior of the MOCAS evaluator MOCASEvaluator /initMOCASProperties() AdaptationPolicy policy: MOCASPolicy H* MOCASSignal/dispatcher^MOCASSignal effector: MOCASEffector MOCASSignal /defer /compose(effector, MOCASEffector) DeliverPolicy(mocasPolicy) /compose(policy,mocasPolicy)

33. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 33 Self-configuration Deployment of sensors Deployment of sensors Configuration of a well-fitting operating mode (attributes + functional context + behavior) Configuration of a well-fitting operating mode (attributes + functional context + behavior) Switching between operating modes Switching between operating modes

34. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 34 Ex. of a self-configuration policy

35. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 35 The dual-transmission gear box from automatic… Five gear mode Five gear modeor Six gear mode Six gear mode

36. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 36 The dual-transmission gear box …to manual

37. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 37 TrafficLight Ex. of self-healing After 30s After 10s Red:Light Green:Light Amber:LightRed:Light Red Green Amber Green:Light Amber:Light

38. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 38 TrafficLight Ex. of self-healing After 30s After 10s Red:Light Off Do/switchOff TurnOff Green:Light Amber:LightRed:Light Red Entry/red^TurnOn Exit/red^TurnOff [red.inState(On) & orange.inState(Off) & green.inState(Off)] Green Entry/green^TurnOn Exit/green^TurnOff [red.inState(Off) & orange.inState(Off) & green.inState(On)] Amber Entry/orange^TurnOn Exit/orange^TurnOff [red.inState(Off) & orange.inState(On) & green.inState(Off)] On Do/switchOn TurnOn Green:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn Amber:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn e.g. Deficiency

39. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 39 TrafficLight Ex. of self-healing: Reset After 30s After 10s Red:Light Off Do/switchOff TurnOff Green:Light Amber:LightRed:Light Red Entry/red^TurnOn Exit/red^TurnOff [red.inState(On) & orange.inState(Off) & green.inState(Off)] Green Entry/green^TurnOn Exit/green^TurnOff [red.inState(Off) & orange.inState(Off) & green.inState(On)] Amber Entry/orange^TurnOn Exit/orange^TurnOff [red.inState(Off) & orange.inState(On) & green.inState(Off)] On Do/switchOn TurnOn Green:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn Amber:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn

40. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 40 TrafficLight Ex. of self-healing: Activating a coherent state After 30s After 10s Red:Light Off Do/switchOff TurnOff Green:Light Amber:LightRed:Light Red Entry/red^TurnOn Exit/red^TurnOff [red.inState(On) & orange.inState(Off) & green.inState(Off)] Green Entry/green^TurnOn Exit/green^TurnOff [red.inState(Off) & orange.inState(Off) & green.inState(On)] Amber Entry/orange^TurnOn Exit/orange^TurnOff [red.inState(Off) & orange.inState(On) & green.inState(Off)] On Do/switchOn TurnOn Green:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn Amber:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn toState(Off)

41. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 41 Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

42. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 42 Tools for MOCAS components TopCased platform for design TopCased platform for design Plugin to generate Java classes for constraints and functional context and packaging MOCAS components MOCAS Engine for execution of models MOCAS Engine for execution of models Relies on Eclipse Modeling Framework MOCASA for test and management MOCASA for test and management Deployment of a MOCAS architecture Observation and control of components behavior Delivering of updates through adaptation Open source tools available at http://mocasengine.sourceforge.net/

43. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 43 Video: demo. of self-healing on traffic light component

44. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 44 Quantitative evaluation ImplementationComponentInstanciationState changeMemory Java SE + EMF Simple1083ms2498µs 4.4Mo Adaptive2341ms (x2.16)2954µs (x1.18) 8.8Mo (x2) Autonomic3555ms (x3.28)5320µs (x2.13) 13.3Mo (x3) Java ME + UML2ForJava http://uml2forjava.sourceforge.net/ Simple0.220ms 26µs0.040Mo Using a container costs one more component mitigated by behavioral composition Making a component autonomic costs two more components Most of the cost is due to EMF

45. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 45 Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

46. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 46 MOCAS is a UML-based component model for designing open self-adaptive systems MOCAS is a UML-based component model for designing open self-adaptive systems MOCAS is MOCAS is Generic: every kind of systems are concerned Uniform: all the non-functional components respect the MOCAS component model Reflexive: structure and behavior are discovered and modified at runtime Decentralized: each component embeds its control loop Conclusion

47. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 47 Conclusion MOCAS fosters MOCAS fosters Transparency of adaptation mechanisms by incorporating a component into a container which manages adaptation Flexibility of the control mechanism by dividing it into several MOCAS components Usability by relying on one formalism from design to administration MOCAS provides a set of tools which cover the software life cycle of a MOCAS system MOCAS provides a set of tools which cover the software life cycle of a MOCAS system

48. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 48 Limits and perspectives Focus on self-healing and self-configuration only Focus on self-healing and self-configuration only Performance of the MOCAS engine has to be improved (alternative to EMF) Performance of the MOCAS engine has to be improved (alternative to EMF) Coordination protocol to be enhanced Coordination protocol to be enhanced Validation to be enhanced (more case studies) Validation to be enhanced (more case studies)

49. PhD defense, Monday, March 8th 2010 cb@cyrilballagny.fr 49 Thank you for your attention Your questions