1. Aspect Validation: Connecting Aspects and Formal Methods
Shmuel Katz
The Technion
(This term at Lancaster University)
(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 AspectJ—looks 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 computed—so hard to evaluate)
Hard to find sufficient tests—due 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

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 VS’s:
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 A+B,
No harm: Apply Spec to A+B, activate model checker
Achieves result: Apply Res to A+B, 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 VS’s are built, the rest is automatic
VS’s use same bindings as the Application!

17. Case study: Monitoring’s 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. Monitoring’s Asm Validation Superimposition

19. Monitoring’s 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

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 VS’s 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 combination…conclude 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;
Verification…Festschrift for Zohar Manna, LNCS 2772 (appearing Nov. 2003)