Rigorous Fault Tolerance Using Aspects and Formal Methods

1. Rigorous Fault Tolerance Using Aspects and Formal Methods Shmuel Katz Computer Science Department The Technion Haifa, Israel katz@cs.technion.ac.il

2. Basic claim of Aspect Oriented Programming (AOP) • Pure Object-Oriented doesn’t work!!! • Gives one central decomposition—but others are possible, and sometimes needed • Cross-cutting concern: one that involves many classes/methods • Tangling: code treating the concern is mixed with that for other concerns • Scattering: code treating the concern is scattered throughout the system

3. Aspects (and esp. AspectJ) • Aspects: modular units that crosscut classes • Aspects are defined by aspect declarations and may include • pointcut declarations: where to add/replace • advice declarations: what to add or do instead • Can introduce new methods, variables, code… • Weave (=bind) aspect to different systems (but not entirely separated yet…)

4. Types of joinpoints and changes • Method calls • Changes/uses of a field (variable) • Method calls while another method is active (relates to stack contents) • Add code before/after/around joinpoint • Replace previous with new code • Often use types, fieldnames,…, from the rest of the system (not fully generic)

5. Aspects and Superimpositions:Modularity for Cross-cutting • For distributed: • Termination detection • Monitoring and logging • Access control • For Object Oriented • Monitoring and debugging • Adding security • Preventing overflow • Enforcing a scheduling policy • Analyzing QOS and Performance

6. Aspects for Fault Tolerance • Transform a system that ignored faults to one that is tolerant for given fault models • Communication faults example: A message occasionally gets lost… • The solution idea: Whenever a message is to be sent using a send() method, send it twice with two different routing tables, and treat receiving() to avoid incorrect repeated receipt • Can be applied where applicable, not used when irrelevant--- allows changing fault models as conditions change

7. Self-stabilization using aspects • Self-stabilization: transient errors that are modeled by starting in an unreachable state; • Treatment requires reaching some legal state (returning to the envelope of normal computations) • One way: add self-stabilizing distributed snapshots that will reset to a “home” state when a fault is detected • Question: interactions of aspects…

8. AOSD-Europe • An EU Network of Excellence for Aspect Oriented Software Development • Four virtual research labs: • Analysis and Design (Early Aspects, Methodology) • Languages (Constructs, Implementation) • Applications (Middleware, Pervasive Computing) • Formal Methods (Semantics, Verification) • Atelier: a toolkit for developing and using aspects, to be developed in open source

9. Issues in Formal Methods for Aspects • How to express specifications for aspects? • How to define the semantics of aspects? • How to verify? • Static analysis • Model checking of just the aspect • Model checking of the augmented system • Theorem proving

10. Ideal Goal: verifying aspects • Show once and for all that: • For every possible underlying system satisfying Assumptions of the Aspect, • For any legal combination (weaving) of the aspect and the underlying system, • The New Functionality will be true for the combination, and • All previous desirable properties are still OK

11. Overcoming the Verification Problem: Divide and Conquer • Cause no harm versus add desired properties • Analyze just the aspect • For every possible weaving and classes of properties • For a specific weaving and given properties • Analyze the augmented system —automatically after a manual one-time set-up • Use static code analysis, restricted inductions, and model checking ---as needed

12. Static analysis to identify categories of aspects • Spectative: just gather information • Regulative: restrict previously possible behaviors • Weakly invasive: change values, but to states previously possible • Strongly invasive: changes that can create new states Each category has fine-tuned verifications

13. Using Aspect Validation for augmented system analysis For situations where original system has been proven correct for its specification using software model checking (e.g., Bandera) • Reprove for augmented system without new manual setup (just push a button…) • Reuse the specification and annotations, given as verification aspects • Treats all new paths/methods…. • In many cases uses the same abstractions

14. Some Interesting Goals • Identifying classes of aspects + systems + properties appropriate for static type analysis or inductive proofs or model checkingonly for the aspect • Analyzing when abstractions and reductions that were effective for model checking the original system and specification work for the augmented system • Discovering generic abstractions and reductions for an aspect that can be reused to model check the augmented system for new aspect properties • Analyzing interference / cooperation among aspects

15. Connections to RODIN? • Possible case studies on fault tolerance and reliability in AOSD Applications Lab? • Expressing RODIN designs as reusable aspects with the Analysis and Design Lab, and as code in AOP Languages? • Joint development of static analysis and verification tools with Formal Methods Lab? • Fault tolerance and reliability proofs using aspect verification and analysis tools?

16. A few references • S. Katz, K. Perry, Self-stabilizing extensions for message-passing systems, Distributed Computing, 1993. • M. Sihman and S. Katz, Superimpositions and Aspect-Oriented Programming, The Computer Journal, 2003 • M. Sihman and S. Katz, Aspect Validation Using Model Checking, LNCS 2772, 2003 • S. Katz, Diagnosis of Harmful Aspects Using Regression Verification, FOAL workshop in AOSD 2004 • Our surveys on aspect semantics and verification: www.aosd-europe.net