1. 1 Naoyasu Ubayashi (Toshiba Corporation) Tetsuo Tamai (University of Tokyo) AOSD 2002 1st International Conference on Aspect-Oriented Software Development Enschede, The Netherlands April 22 – 26, 2002 Aspect-Oriented Programming with Model Checking

2. 2 Overview 1. Introduction 2. Issues on AOP 3. AOP verification with model checking 4. AOP-based checking framework 5. Future works 6. Conclusions

3. 3 1. Introduction

4. 4 Motivation AOP is a programming paradigm such that crosscutting concerns over objects can be modularized as aspects that are separated from objects. However, it is not easy to verify the correctness of a woven program because crucial behaviors including performance and synchronization are strongly influenced by aspect descriptions. Bugs affecting requirements specifications, safety, liveness and fairness may be hidden in individual aspects and classes. Bugs may emerge in a program woven by a weaver even if bugs do not exist in individual aspects and classes. Bugs affecting requirements specifications, safety, liveness and fairness may be hidden in individual aspects and classes. Bugs may emerge in a program woven by a weaver even if bugs do not exist in individual aspects and classes.

5. 5 Our approach This research proposes an automatic verification approach using model checking that verifies whether a woven program contains unexpected behaviors such as deadlocks. Model checking is useful for AOP validation because it can be used to check global properties across multiple aspects. class aspect find bugs using model checking bug

6. 6 Objectives to verify the correctness of AOP-based programs using model checking to provide AOP-based checking frameworks A verification description is considered as a crosscutting concern and separated as an aspect. class aspect for model checking

7. 7 2. Issues on AOP

8. 8 Gap between design/programming and testing In the design & programming phases of AOP, a programmer can define aspects without considering weaving processes. In the testing phase, however, the programmer has to consider weaving processes and imagine how the woven program behaves, because targets of testing are not individual classes and aspects but the woven program. Design Phase Programming Phase Testing Phase Gap!

9. 9 Example in AspectJ (Error logging) class Foo { public void m1() {} } class Bar extends Foo { public void m1() { super.m1(); } private void m2() {} } class Log { void write(Object o) {} } class Foo { public void m1() {} } class Bar extends Foo { public void m1() { super.m1(); } private void m2() {} } class Log { void write(Object o) {} } aspect PublicErrorLogging { static Log log = new Log(); // join point pointcut publicInterface (): target (mypackage..*) && call (public * *(..)); // Advices after() returning (Object o): publicInterface() { System.out.println(thisJoinPoint); } after() throwing (Error e): publicInterface() { log.write(e); } aspect PublicErrorLogging { static Log log = new Log(); // join point pointcut publicInterface (): target (mypackage..*) && call (public * *(..)); // Advices after() returning (Object o): publicInterface() { System.out.println(thisJoinPoint); } after() throwing (Error e): publicInterface() { log.write(e); } Is an error logged when an exception is thrown in the method m1 of the class Bar ? Is an error logged when an exception is thrown in the method m2 of the class Bar ? weaving YES NO It is easy to check these properties in this case. However, it is not easy to check complex properties in general AOP.

10. 10 Issues on AOP It is difficult to verify the correctness of AOP-based programs. We need verification methods for AOP ! class aspect bug aspect correc t?

11. 11 3. AOP verification with model checking

12. 12 Model Checking Model checking is a formal method that checks whether a structure (system) satisfies a property or not. If a structure M satisfies a formula φ in a state s, M is called a model of φ and is expressed as M, s |= φ. Usually, M is defined as a finite state automaton and φis expressed as a temporal logic formula. Temporal logic formalizes sequences of transitions between states in a system. M φ satisfies Model (Finite state automaton) Formula (Temporal logic)

13. 13 Temporal Logic ・ CTL* (Computation Tree Logic ） ・ CTL - temporal operators quantify over the paths that are possible from a given state ・ LTL （ Linear Temporal Logic ） - temporal operators are provided for describing events along a single computation path ・ path quantifier A(for all computation paths) E(for some computation path) ・ temporal operator X(next time) F(in the future) G(globally) U(until) R(release) M, s 0 |= EG g M, s 0 |= AF g s0s0 s0s0 temporal logics CTL* A tree is formed by designating an initial state in the structure as the root and then unwinding the structure into an infinite tree

14. 14 Example of CTL* formula (Error logging) M, s |= AG( ) ThrowingException-Bar-m1 → AF ErrorLogging-Bar-m1 ThrowingException-Bar-m1 ErrorLogging-Bar-m1 This CTL* formula shows the following property: for all paths starting from s, any state satisfies the property that an exception is logged eventually (ErrorLogging-Bar-m1) if the exception is thrown in the method m1 of the class Bar(ThrowingException-Bar-m1). s Using model checking, we can verify whether this formula is true or not. M,s |= AG(ThrowingException-Bar-m1 → AF ErrorLogging-Bar-m1) M,s |= AG(ThrowingException-Bar-m1 → AF ErrorLogging-Bar-m1)

15. 15 Example in AspectJ (Error logging) class Foo { public void m1() {} } class Bar extends Foo { public void m1() { super.m1(); } private void m2() {} } class Log { void write(Object o) {} } class Foo { public void m1() {} } class Bar extends Foo { public void m1() { super.m1(); } private void m2() {} } class Log { void write(Object o) {} } aspect PublicErrorLogging { static Log log = new Log(); // join point pointcut publicInterface (): target (mypackage..*) && call (public * *(..)); // Advices after() returning (Object o): publicInterface() { System.out.println(thisJoinPoint); } after() throwing (Error e): publicInterface() { log.write(e); } aspect PublicErrorLogging { static Log log = new Log(); // join point pointcut publicInterface (): target (mypackage..*) && call (public * *(..)); // Advices after() returning (Object o): publicInterface() { System.out.println(thisJoinPoint); } after() throwing (Error e): publicInterface() { log.write(e); } Is an error logged when an exception is thrown in the method m1 of the class Bar ? weaving We can answer this question using model checking.

16. 16 Model Checkers ToolModeling Lang.Property Spec. SPIN( Bell Lab.) PROMELALTL 、 assertion Java PathFinder( NASA) Javaassertion Bandera( Kansas State Univ.) JavaLTL ESC ／ Java( Compaq) Javaassertion Some kinds of model checkers treat a source program as a model. Using these checkers, programmers are released from writing models specific to model checking. Methods of specifying property specifications are categorized into two approaches. One is an approach that specifies an LTL formula directly from a command line, and another is an approach that embeds assertions in a model.

17. 17 AOP verification with model checking Model checking is applied to verify automatically whether a program composed of aspects and classes satisfies properties specified as a temporal logic formula. Model checking is applied to a result of weaving aspects and classes. classesaspects weaving model checking LTL assertion

18. 18 Example (Producer/Consumer Problem) Producer Consumer ０ １ ２ put halt get HaltException Buffer This example is a program in which a producer puts data into a buffer and a consumer gets the data from the buffer. The buffer is used cyclically. The producer puts data in if the buffer is not full. Otherwise, the producer waits until the buffer is not full. The consumer gets data if the buffer is not empty. Otherwise, the consumer waits until the buffer is not empty. The producer sets the halt- flag when it puts all data into the buffer. The exception HaltException is thrown if the consumer wants to get data but the halt-flag is set.

19. 19 Description in AspectJ class Buffer { static final int SIZE = 3; Object[] array = new Object[SIZE]; int putPtr = 0; int getPtr = 0; public synchronized void put(Object x){ array[putPtr] = x; putPtr = (putPtr + 1) % SIZE; } public synchronized Object get() throws HaltException { Object x = array[getPtr]; array[getPtr] = null; getPtr = (getPtr + 1) % SIZE; return x; } ｝ Concurrent Aspect Other Aspects Buffer Class basic function Producer Class Consumer Class Assertion The number of data put in from the producer equals the number of the data received by the consumer. weaving

20. 20 Checking crosscutting concerns It is not easy to understand the behavior of the woven program as a whole although the program is very short. Actually, violations are detected at the assertions. From the viewpoint of temporal logic, there is at least one transition path that starts from the initial state and does not reach states satisfying the assertions in the example's state transition space.

21. 21 Counter example The producer puts three values into the buffer in the positions 0, 1, 2. After that, it calls the method wait. The consumer gets the first value and then notifies the producer. After that, the consumer gets the second and the third values. Producer Consumer ０ １ ２ put halt get HaltException Buffer The producer puts the fourth value into the position 0, the fifth value into the position 1 and the sixth value into the position 2. Then the producer sets the halt-flag. When the consumer calls the method get, the exception HaltException is thrown because halted-flag is set. The consumer cannot get the remaining three values and the assertions are violated.

22. 22 Advantages using model checking This counter example is not always detected at runtime. If the consumer gets the remaining three values before the producer sets the halt-flag, the assertions are valid. It is very difficult to remove these kinds of bugs completely just by runtime testings. Model checking is very useful !!

23. 23 4. AOP-based checking framework

24. 24 Objectives of AOP-based checking framework An AOP-based checking framework is proposed in order to use model checkers efficiently. Using this checking framework, properties to be checked that crosscut over classes can be described as an aspect and separated from a program body. aspect class When model checking is applied to AOP, assertions may be scattered across classes. separates as aspects

25. 25 No.Checking feature Pre/post – condition Join pointAdvice 1.method invocationpre-conditioncall(Signature ) before post-conditioncall(Signature ) after 2.state transitionpre-conditionset(Signature)before post-conditionset(Signature)after 3.change of a specified condition pre-conditionif(BooleanExp ) before post-conditionif(BooleanExp ) after Join points for AOP-based checking framework Using these join points, properties to be checked can be separated as aspects. (in the case of AspectJ) The first pattern is a join point corresponding to method invocation. This join point is expressed using call in AspectJ. The second pattern is a join point corresponding to the field settings. This join point expressed using set in AspectJ can be used to catch a state transition. The third pattern is a join point expressed using if in AspectJ. This can be used to catch a change of a specified condition.

26. 26 Structure of checking framework method invocation Pre- condition checking aspect class state transition change of condition Check crosscutting concerns Post- condition Pre- condition Post- condition Pre- condition Post- condition DBC Test Story Pre- condition Post- condition Pre- condition Post- condition (join point) Test Story checking aspect super checking aspect A checking aspect is defined corresponding to a test story. A checking aspect is described based on DBC (Design by Contract). A super checking aspect can be defined if there are common properties.

27. 27 Description of checking aspect A checking property is expressed as an aspect that describes pre- and post-conditions using join points. aspect Sample { // specify a join point pointcut fooPointcut(Foo o): call(public void bar()) && target(o); before(Foo o): fooPointcut(o){ // specify a pre-condition } after(Foo o): fooPointcut(o){ // specify a post-condition } aspect Sample { // specify a join point pointcut fooPointcut(Foo o): call(public void bar()) && target(o); before(Foo o): fooPointcut(o){ // specify a pre-condition } after(Foo o): fooPointcut(o){ // specify a post-condition } Join point Pre-condition Post-condition

28. 28 Application of multiple checking tools Using this checking framework, multiple checking tools can be applied. As description styles of assertions and facilities of checking differ corresponding to checking tools, it is necessary to choose tools to be used and describe assertions corresponding to the syntax of the tool. It is only necessary to weave aspects that describe checking features corresponding to checking viewpoints. It is not necessary to change program code even if checking tools are changed. Checking Aspect (Tool C) Checking Aspect (Tool B) Checking Aspect (Tool A) join point class Test Story

29. 29 Advantages using checking framework Readability is improved because checking properties can be separated from original functions. Checking properties that crosscut over classes can be encapsulated into an aspect. It is not necessary to modify program code whenever new checking features are added. It is only necessary to weave aspects that describe the checking features. Aspects are defined corresponding to checking viewpoints. Both a unit testing that weaves only one aspect and an integrated testing that weaves multiple aspects are possible. The AOP-based checking framework can be used not only with model checking but also with runtime testing.

30. 30 5. Future works

31. 31 Future works Problems such as performance and memory efficiency are unavoidable to model checking. The space explosion problem cannot be ignored. Various approaches should be explored and combined to tackle this problem. model checking There are problems to be resolved in the future as follows. --- Bandera extracts a finite state model only related to a checking feature specified by an LTL formula from Java source code using program slicing.

32. 32 Future works (cont’ed) Our approach applies model checking to a result of weaving classes and aspects. [for integrated checking] There could be an approach that classes and aspects are checked separately. [for unit checking] Unit checking --- An approach such that model checking is applied to a result of weaving an aspect and stub objects generated from the aspect may be one of the solutions to this problem.

33. 33 6. Conclusions

34. 34 Conclusions We proposed 1) AOP verification using model checking 2) AOP-based checking frameworks