Title: Rigorous Fault Tolerance Using Aspects and Formal Methods
1Rigorous Fault Tolerance Using Aspects and Formal
Methods
- Shmuel Katz
- Computer Science Department
- The Technion
- Haifa, Israel
- katz_at_cs.technion.ac.il
2Basic 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
3Aspects (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)
4Types 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)
5Aspects 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
6Aspects 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
7Self-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
8AOSD-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
9Issues 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
10Ideal 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
11Overcoming 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
12Static 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
13Using 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
14Some 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
15Connections 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?
16A 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