Justin Mazzola Paluska

1
Structured Decomposition of Adaptive Applications

• Justin Mazzola Paluska
• MIT Oxygen
• Percom 2008

2
Introduction

• Adaptability
• Main Requirements
• Make implementation decisions at runtime, rather
  than at design-time or compile-time.
• Revising previously made implementation decisions
• Decision making logic must be open-ended
• Applicationlevel design
• Application programmers declare what they
  need, a runtime system determines how to
  satisfy

3
Main Contributions

• Goals Techniques Framework
• Goals are bound to Techniques at runtime by the
  Planner
• Two Details
• Incremental evaluation of decision logic
• Caching decision-making
• Four widely-varying applications
• JustPlay Audio Video
• User Proxies
• Crisis Management
• Recipe

4
Features

• Three Salient Features
• Hierarchical decomposition with extensible
  constrained evaluation
• An additive universe of code modules
• Adding Tech. without changing existing code
• Separation of decision logic from components
• Tech. are separate from the description
  components

5
Programming Model

• Goal Goal Properties
• Goal a parameterized decision point
• Properties Restrict the semantics of the Goal
• Concretely, a Goal refers to a spec. file
• formal parameters of the Goal itself
• what Properties must be provided by Tech.

6
Goal Example
7
Programming Model

• Techniques
• A small script mixing declarative and arbitrary
  imperative code broken up into a series of stages
• Stage
• Sub-Goal declarations
• Evaluation code
• Commit code

8
Goal Lifecycles
9
Goal Lifecycle

• Goal Exploration
• Building a Goal Tree
• Evaluating Techniques
• Goal Commitment
• By running the chosen Techniques
• Goal Monitoring and Shutdown
• Activation or deactivation of Goal Trees
• Startup, failover, upgrade or shutdown of
  components

10
(No Transcript)
11
Architecture

• Additivity
• Technique sub-Goal search selection
• Runtime adaptativity
• Technique factories and external events

12
Additivity

• Additive universe
• Each Tech. describes a way of achieving some Goal
• Decision-making algorithm must be generic
• Satisfaction
• System computes a score based on the Tech.s
  report
• default formula for each Goal Spec
• Local policy can modify the formula
• Goals must be immutable (Update)

13
Techniques sub-Goal Search Selection
Search-narrowing Goal Parameters
Dependent Subgoal Binding
14
Tree Search Exploration
15
Run-time Adaptivity

• Exception Failover, Roll back
• Instead, The planner keeps track of what Goal
  parameters and sub-Goal properties each stage of
  each Techniques uses.
• When a tracked variable changes
• Find the first stage that depends on the variable
• Reset the previous stages found above

16
Technique Factories External Events
17
Applications

• JustPlay Audio Video Applications
• Voice Shell
• A custom in house DNSSD discovery system
• User Proxies
• Device can access the network conveniently
• Crisis Management
• Adding new strategies
• Recipe
• What ingredients are available
• User preferences

18
Implementation and Performance

• Language Python
• Commond line tool or Application
• Tested on
• GNU / Linux,
• Apple OS,
• Windows(cygwin)

19
(No Transcript)
20
Conclusion

• Providing application programmers with a way of
  managing implementation decisions and component
  writers with an extensible way of expressing
  particular implementation plans in a way that
  allows extensible, but domain-specific,
  evaluation of alternatives.