Aspect Validation: Connecting Aspects and Formal Methods

1
Aspect Validation Connecting Aspects and Formal
Methods

• Shmuel Katz
• The Technion
• katz_at_cs.technion.ac.il
• (This term at Lancaster University)
  s.katz_at_lancaster.ac.uk
• (joint work with Marcelo Sihman)

2
What is an Aspect?

• Modular unit to treat otherwise cross-cutting
  concerns of object-oriented systems
• Augment/change existing code by describing
• Where to change---joinpoints
• How to change---advice
• For Composition Filters you are experts
• For AspectJlooks like a class declaration with
  extra elements
• Add Security, Fault tolerance, Monitoring,...

3
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

4
The Problem Impracticality

• Such a proof must be inductive
• No one really does inductive proofs for software
  using existing tools
• Requires generalizations hard to express on every
  software architecture within a class, or every
  weaving of a certain type
• (Still valuable for defining semantics)

5
One way testing

• Regression testing to show previous test still
  passed (perhaps with different values computedso
  hard to evaluate)
• Hard to find sufficient testsdue to global
  nature of the weaving of aspect and underlying
  system
• The aspect cannot be executed by itself (an
  aspect is not a program)

6
Another Way Aspect Validation

• Show each application of an aspect over a system
  is correct
• Still formal verification, but for each instance
• Key idea set-up is manual, but then the proof
  for each instance is automatic
• Proves that applications so far are correct
• First used for Compiler Validation Pnueli,
  et.al.

7
Detour Compiler Validation

• It is too hard to verify a compiler
• Instead, each time the compiler is activated,
  automatically generate assertions about the
  source and target code
• If the assertions are true, the translation is
  proven correct this time
• Checking the assertions can be done automatically
  (simple implications)

8
Key ideas of Aspect Validation

• Use an existing software model checking tool
• Define collections of aspects, with
  specifications (we call them superimpositions)
• Use aspects and superimpositions themselves to
  express the augmentations to systems needed for
  various model checking tasks
• Manual set-up is done once, then a sequence of
  automatically generated tasks are done each time
  the collection of aspects is woven into a basic
  system.

9
Superimpositions and Aspects

• Generic aspect has parameters that allow binding
  to any appropriate context have one type of
  additions
• Superimposition collection of aspects that
  together treat a concern or give an added
  algorithm (ex. Root, Internal, Leaf aspects that
  add a spanning tree over objects)
• Have specification Assumptions about basic New
  functionality

10
Case study Monitoring Super (over a Basic
Bounded Buffer)

• Monitoring that also stops the basic if a
  condition is violated regulatory
• It could affect liveness properties of the Buffer
• Monitoring has a joint aspect, one extension
  aspect for Mutable base classes and one for
  Constant base classes
• Records the number of external method calls
• If basic attempts to change constant class the
  monitor intercedes and stops the system

11
(No Transcript)
12
What is model checking?

• Given a finite representation of a model (a
  program), and an assertion about execution paths
  in temporal logic, check whether the assertion
  holds for every possible execution path (even
  infinite ones!) and thus is a property of the
  model
• Generate compact representations, use clever
  algorithms to check, restrict assertion language,
  use abstractions to get smaller models,

13
Software model checking

• Tool that allows augmenting (Java) code,
  abstracting domains, expressing properties to be
  checked
• Bandera (or others) generate input to existing
  tools like SMV, Spin,
• For proper abstractions, success means the
  checked property holds for every execution
• Often ends with a counter-example
• Can fail due to state explosion, giving no info
• Algorithmic (except for finding abstractions)

14
Validation Superimpositions

• Augmentations to be added to Applications of
  Aspects over Basic Systems
• For each Application Super, build 2 VSs
• Asm Assumptions of the Application
• Res Desired results of the Application
• Contain new fields, predicates,for each
  application aspect and for the super.
• For each Basic system, need another VS
• Spec specification of the Basic system

15
The Validation process

• Correctness of Basic Apply Spec to Basic, and
  activate model checker (done earlier)
• Basic is appropriate Apply Asm to Basic,
  activate model checker
• Apply Application over Basic giving AB,
• No harm Apply Spec to AB, activate model
  checker
• Achieves result Apply Res to AB, activate model
  checker

16
How to Validate Aspects/Superimpositions

• Build Validation Superimpositions (manual)
• Apply the stages for each combination
• Activate model checker
• Apply appropriate Validation Superimposition
• use Bandera to generate model checker input
• apply appropriate model checker to input
• Once the VSs are built, the rest is automatic
• VSs use same bindings as the Application!

17
Case study Monitorings Assumption about Basic

• For each class instance, the Method bound to
  parameter EM is eventually called
• That will be the last method called by that class
  instance
• (because the monitoring then reports the total of
  the external method calls made)

18
Monitorings Asm Validation Superimposition
19
Monitorings Results Validation superimposition

• TotCalls must always equal totConCalls
  totMutCalls, except inside methods
• TotCalls will equal number of external method
  calls in all basic objects bound
• If attempt is made to modify a constant, the
  combined system prints an error message and stops

20
(No Transcript)
21
(No Transcript)
22
Validation gives a practical path to routine
application

• Only expert needs to write Bandera (once)
• Practical limitations
• Tools have arbitrary restrictions
• Need abstractions
• Counter-examples can find bugs
• The key full modularization of the VSs allows
  automatic application
• Superimpositions provide right module for
  specifications and reuse

23
Can we verify once-and-for-all with model
checking?

• Model checking needs a model
• Complete aspect/super. with a dummy program that
  satisfies the assumptions
• Verify for that combinationconclude all are OK
  (need inductive reasoning here)
• Connects to parametric model checking, and
  checking model-generating graph grammars.
• Easy for spectative, hard for invasive

24
Conclusions on Aspect Validation

• Once-and-for-all verification is good but hard
• Validation of each instance is also formal, and
  seems more practical
• Future vision library of application
  superimpositions, each with associated
  validation superimpositions
• References
• FOAL 2003
• VerificationFestschrift for Zohar Manna, LNCS
  2772 (appearing Nov. 2003)