Rigorous Fault Tolerance Using Aspects and Formal Methods Shmuel Katz Computer Science Department The Technion Haifa, Israel

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

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…)

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)

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

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

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…

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

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

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

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

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

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

Some Interesting Goals Identifying classes of aspects + systems + properties appropriate for static type analysis or inductive proofs or model checking only 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

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?

A few references S. Katz, K. Perry, Self-stabilizing extensions for message-passing systems, Distributed Computing, 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: