Hossein Tajalli Joshua Garcia Motivation

Hossein Tajalli & Joshua Garcia

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

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

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

Software Modeling • SADEL: a Software Architecture Description and Evaluation Language • C 2 SADEL: C 2 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

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 • Domain Model Description We use this technique • To generate application plans • To generate plans for Adaptation Goal MBP Plan

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 (George 09)

System Requirements • Application Domain Model

System Requirements • Adaptation Domain Model

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

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

PLASMA Architecture

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

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 21 st 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 selfmanagement 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.

Non-deterministic Domain

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

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

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.