VADER 2011 (Younessi)

229 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
229
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

VADER 2011 (Younessi)

  1. 1. TOWARDS A DEVELOPMENTFRAMEWORK BASED ON BEHAVIORRECOMBINATION Houman Younessi, RH, RPI, USA Renaud Pawlak, LISITE, ISEP, France Carlos E. Cuesta, VorTIC3, URJC, Spain Hersonissos, Crete, Greece, 18/10/2011
  2. 2. CONTENTS Introduction Behavioral Recombination Framework (BRF)  Behavior Predicates  Abstracting Behavior  Recombining Behaviors  The Recombinator Related work Conclusions & Future work 2
  3. 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. 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. 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. 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. 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. 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. 9. THE RECOMBINER:RECOMBINING A SEQUENCE Condition? TRUE SEQUENCE? Condition? TRUE SEQUENCE? RECOMBINER 9
  10. 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. 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. 12. THANKS FOR YOUR ATTENTION 12

×