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

9. THE RECOMBINER:
RECOMBINING A SEQUENCE
Condition?
TRUE
SEQUENCE?
Condition?
TRUE
SEQUENCE?
RECOMBINER
9

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

12. THANKS FOR YOUR ATTENTION
12