Assertion with Aspect (about Predictability)

Assertion with Aspect(about Predictability) Takashi Ishio†, Toshihiro Kamiya‡, Shinji Kusumoto† and Katsuro Inoue† † Osaka University ‡ Japan Science and Technology Agency {t-isio, kamiya, kusumoto, inoue}@ist.osaka-u.ac.jp

Introduction • A programmer has assumptions for the usage or the purpose of a method. • A programmer express such assumptions as assertion statements. • Certain assumptions are hard to be described in OO programming. • a context-specific assumption • an assumption crosscutting objects

Assertion with Aspect • Combine assertion statements with aspects: • In a class: assert(aPredicateMethod()); • A predicate method returns a boolean value. • In an aspect: boolean aPredicateMethod() { return ... ; } Class Aspect Check a property of the component assert(A1) assert(A2) Check a context-specific property of the component assert(A2)

Advantages of Assertion using Aspect • Programmers can add a new constaint to an assertion statement. • A reusable (generic) component + application-specific constraint aspects • Aspects can add assertion statements checking pre/post-conditions to a class.

How does assertion support predictability ? • Assertion statements • check the state of the program, • do not modify the state. • Programmers can understand what properties are held in the program execution. • Pre/post-conditions express method functionalities.

boolean isSorted (Array array) { if (!array.sorted()) array.sort(); return true; } How does assertion reduce predictability ? • An assertion may have a side effect. array = getUnsortedArray(); assert( isSorted (array) ); doSomethingUsingSortedArray(array);

To be side-effect free assertion • Assertion is an executable document for programmers. • It is not a part of a function. • How does we enforce programmers to implement the assertion without side-effects ? • const keyword in C++ is hopeful.

Summary • Writing assertion supports predictability when the programmers use assertion to express assumptions. • An assertion with a side-effect is problematic. • Enforcing programmers to write predicate methods without side-effects is important.

A context-specific assumption(A simple example) • A programmer wants to use HashMap as a map from String which is length() > 0 to arbitrary Object. • HashMap Object  Object is available. • Following assertion is added to the program. before (Object o): within(AClass) && call(* HashMap.put(Object, Object)) && args(o,..) { assert ( (o instanceof String) && (((String)o).length() > 0) ); }

Behavioral Subtyping • A: HashMap (Object  Object) B: HashMap (String  Object) • A is a behavioral subtype of B. (B is not a behavioral subtype of A) • If B is a wrapper object, it needs to prohibit a direct access to A.

Another example: control-flow assumption m: public method m1: private method, a worker method for m. “m1 is called from m.” before(): call(void m1()) && cflow(execution(void m())) { // set aCallerFlag about caller } before(): execution(void m1()) { assert ( aCallerFlag ) }

Assertion with Aspect (about Predictability)