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 opLoad:{
pre \not(loaded)) \and
(\not(locked));
post (loaded);
}
prov opunLoad:{
pre (loaded)\and(\not(locked));
post \not (loaded);
}
}
….
}
Plan
Layered Self-Management and SelfAdaptation Architecture
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
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
Domain
Model
Description
• 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
(George09)
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
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 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 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
•
Plans are Sets of State-Actions to get to a goal state
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.