1 / 16

Rigorous Fault Tolerance Using Aspects and Formal Methods

Rigorous Fault Tolerance Using Aspects and Formal Methods. Shmuel Katz Computer Science Department The Technion Haifa, Israel katz@cs.technion.ac.il. Basic claim of Aspect Oriented Programming (AOP). Pure Object-Oriented doesn’t work!!!

plato
Download Presentation

Rigorous Fault Tolerance Using Aspects and Formal Methods

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related