The BRF models program behavior as sequences of actions and states changes. It defines primary behavioral sequences and rules for checking expected behavior. It allows defining alternate behaviors as rewriting rules that can alter the primary sequence when applied. A recombinator mixes the primary sequence with alternate behaviors by applying matching rules, recalculating the new program. This allows developing trusted adaptive behaviors and applications through constructive recombination of actions. Future work includes integrating requirements specification and using a high-level specification language.
1. TOWARDS A DEVELOPMENT
FRAMEWORK BASED ON BEHAVIOR
RECOMBINATION
Houman Younessi, RH, RPI, USA
Renaud Pawlak, LISITE, ISEP, France
Carlos E. Cuesta, VorTIC3, URJC, Spain
Hersonissos, Crete, Greece, 18/10/2011
2. CONTENTS
Introduction
Behavioral Recombination Framework (BRF)
Behavior Predicates
Abstracting Behavior
Recombining Behaviors
The Recombinator
Related work
Conclusions & Future work 2
3. INTRODUCTION:
THE NEED FOR VARIABILITY
Adaptation needs variability
Variation points imply a strategic choice
For instance, less consume over QoS
Variation + modularity = simple choice
Just activate/deactivate a certain module
Loose coupling: CBSE, AOSE
But modularity depends on architecture
Tyranny of the dominant decomposition
Related to architectural erosion
Proposal: define variation on behavior
To define trusted behavior adaptations
3
The structure is not important anymore
4. BEHAVIORAL RECOMBINATION FRAMEWORK
(BRF)
Program behavior is defined as a sequence of
actions (state changes or messages)
Adapting a program is changing the order of execution
(or adding new states)
Behavioral Recombination Framework (BRF)
Modeling the behavior using a recombinator
Using the “recombinant DNA” metaphor
Existing prototype: Recombinant Java
Defining trusted behaviors
Define primary behavioral sequence(s)
Define rules to check expected behavior
4
Define alternate behaviors (rewriting rules)
5. PRIMARY SEQUENCE:
THE EXPECTED BEHAVIOR
Relation to Use Cases
Primary Sequence = main scenario
Rewriting Rules = alternate scenarios
Relation to TDD and agile processes
Particularly, Continuosus Integration
Rewriting Rules = integration tests
For instance, consider a program
zip (f)
c= connect (s, user, pass)
r = send (c, f)
disconnect (c)
5
6. BEHAVIOR PREDICATES
Now we can check desired properties
In our example: always zip before sending
Done using behavior predicates
To some extent, similar to Pnueli’s LTL
But using a regular expression-based notation
For instance: A*; B
Can be translated to a Büchi automaton
All execution paths must match these predicates
These are invariants, or integration tests
For example:
(¬ (zip(f) send(?,f)))*; send(?,f) error 6
7. ABSTRACTING BEHAVIOR
Instead of using invocations to match behavior, we
can abstract in “predictive variables”
zip (f)
zipped = true
uploading = true
These abstract “meta-variables” play a similar role
to annotations in several languages
Rules can be rewritten using them
Avoids changing conditions due to changes in
programming sentences
For example:
7
uploading ¬ zipped error
8. RECOMBINING BEHAVIORS
The key point in the recombinant approach
Alternate behaviors are defined as rewriting rules which
may alter original ones
Following again a Use-Case-Driven approach
The recombiner mixes this behavior and the primary
sequence, re-calculating the entire program
Use of the sequence(n) and join operators
Process:
In every sequence, go to first action
WHILE a predicate matches current action
Apply this rule
Recalculate the new primary sequence
Once all have been applied, go to the next one 8
Loop
10. RELATED WORK
An obvious similarity to model checking
But the approach was not originally conceived as a
formal approach, and has avoided this
Behavior predicates (aka regular expressions) can be
compared to LTL formulae
Spin allows something similar using LTL
It allows multithreading while checking
It does not allow constructive rewriting
Similar to EAOP in the AOSD world
EAOP triggers events by using program traces
Event-driven aspects are similar to rewriting rules
This is essentially a language, ours a framework 10
11. CONCLUSIONS & FURTHER WORK
Developing a framework for constructing
applications
By recombining sequences of actions
Possible to develop trusted behaviors
And therefore trusted adaptations
Also for recombining “generic” sequences
Prototype: Recombinant Java
Generalizing into a methodolical framework
Future work
A requirements specification method (Manhattan)
Use a high-level specification language
Complements a “pure” CBSE approach 11