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_at_cs.technion.ac.il

2
Basic claim of Aspect Oriented Programming (AOP)

• Pure Object-Oriented doesnt work!!!
• Gives one central decompositionbut 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 SuperimpositionsModularity 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 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

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