1. Hossein Tajalli & Joshua Garcia

2. Motivation Self-* or autonomic systems Self-configuration, self-adaptation, and self-healing Why we might want self-adaptive systems? Highly Available Changing Requirements Robust, flexible, scalable Dynamic composition Specification Components configuration should conform to specification Report that they cannot or degrade gracefully Architecture-based [Kramer and Magee] Generality Level of abstraction Scalability Builds on Existing Work

3. Introduction PLASMA: a Plan-based Architecture for Software Model-driven Adaptation Less burden on System Architect Architect only provides the component Models and goal of the system Architect does not need to design the Application Architecture Topology Architect does not need to design the adaptation policies Automated Adaptation Component failure Goal change System requirement change Automated planning for adaptation Adaptation plans are generated using MBP

4. PLASMA Components Software Architecture and Evaluation Language component loader is{ state { loaded : Boolean; locked : Boolean; } interface{ prov loading: load(); prov unloading: unload(); } operations{ prov opLoad:{ pre \not(loaded)) \and (\not(locked)); post (loaded); } prov opunLoad:{ pre (loaded)\and(\not(locked)); post \not (loaded); } …. } Layered Self-Management and Self- Adaptation Architecture Model-Based Planning MBP Plan

5. Software Modeling SADEL: a Software Architecture Description and Evaluation Language C2SADEL: C2 Style. (Medvidovic 99) Model Components, Connectors and topology Component Models: State Variables Component Interfaces Component Behavior (Operations) Pre –condition and Post-Condition Enables architectural consistency- and type-checking, and code generation

6. Planning Planning As Model Checking Technique (Giunchiglia & Traverso 99) generate plans by checking the correctness of formulas in a model. Can deal with non-determinisim Can deal with partial observablity Goals Reachability Maintainablity Failure or Preference Repeat Model Based Planner We use this technique To generate application plans To generate plans for Adaptation MBP Domain Model Description Goal Plan

7. Software Self-Adaptation and Self-Management Architecture Each layer manages and adapts the layer below it Meta-level Architecture Specialized Meta-Components Collector, Analyzer, Admin Arbitrary number of layers ( George09 )

8. System Requirements Application Domain Model

9. System Requirements Adaptation Domain Model

10. Drive Component Models from System Requirements Operations: lock unlock Locker Comp Operations: load unload Loader Comp System Requirements (Domain Model) Components SADEL Models

11. How Are Approach Works Planning Layer Adaptation Layer Application Layer Application Component Models Adaptation Component Models Application Goal Adaptation Plan Application Plan Set & Adapt Component Failure Component Failure

12. PLASMA Architecture

13. Conclusions Less burden on System Architect Architect only provides the component Models and goal of the system Architect does not need to design the Application Architecture Topology Architect does not need to design the adaptation policies Automated Adaptation Component failure Goal change System requirement change Automated planning for adaptation Adaptation plans are generated automatically

14. References F. Giunchiglia and P. Traverso. Planning as model checking. In ECP, pages 1-20, 1999 N. Medvidovic, D. S. Rosenblum, and R. N. Taylor. A language and environment for architecture-based software development and evolution. In ICSE '99: Proceedings of the 21st international conference on Software engineering, pages 44-53, New York, NY, USA, 1999. ACM. G. Edwards, J. Garcia, H. Tajalli, D. Popescu, N. Medvidovic, G. Sukhatme, and B. Petrus. Architecture-driven self-adaptation and self- management in robotics systems. In Software Engineering for Adaptive and Self-Managing Systems (SEAMS'09), pages 142-151, 2009. J. Kramer and J. Magee. Self-managed systems: an architectural challenge. 2007 Future of Software Engineering, pages 259-268, 2007.

15. Non-deterministic Domain

16. Details of planning Application Component Models ADL Model Parser Planner Problem Generator Code Generator Domain Model Application Problem Plan Executer (.class) Problem

17. Plans Plans are Sets of State-Actions to get to a goal state Plan= { {1,unlock} {2,load} {3,lock} {4, DONE} }

18. Plans to create Architecture Topology Application Plans Are used to drive the Architecture of the system. Algorithm: 1- Extract the required actions in the plan 2- Find the components which perform the required Actions 3- Check the component required interfaces and Include the components which provide those.