Modularization of Assertion Crosscutting Objects

1. Modularization of Assertion Crosscutting Objects Takashi Ishio†，Toshihiro Kamiya‡， Shinji Kusumoto†，Katsuro Inoue† †Osaka University ‡ National Institute of Advanced Industrial Science and Technology {t-isio, kusumoto, inoue}@ist.osaka-u.ac.jp t-kamiya@aist.go.jp

2. Overview • Assertion and Design by Contract • Assertion crosscutting objects • Example: Observer pattern with an inter-object constraint • Our proposal: Aspect for Crosscutting Assertion • Rewriting inter-object constraint using aspect • Discussions • Effect on software quality • Related work

3. Assertion statement • An assertion statement describes a condition must be true at the statement. Assertion Statement in Java: assert ( Boolean expression ); assert(true) means the system works well. assert( false ) indicates a failure.

4. Assertion as document • Assertion placed before/after a program element is a part of documents for the element. • An element: a statement, a code block or a method. • Preconditions to be satisfied • before the element is executed. assert(X); { // do something } assert(Y); assert(Z); • Postconditionsto be satisfied • after the element is executed. execute

5. Effectiveness of assertion • Explicit responsibility: Design by Contract • Contract consists of pre/post-conditions for each method. • Contract explicitly defines the responsibility of the module. • Contract tells a developer the specification to be implemented. • Early detection of a failure • Assertion stops the system in invalid state before the system breaks important data. • An assertion failure provides a hint for developers to debug the system.

6. Assertion is effective. However … • Assertion and Design by Contract • Assertion crosscutting objects • Example: Observer pattern with an inter-object constraint • Aspect for Assertion • Rewriting inter-object constraint using aspect • Discussions • Effect on software quality • Related work

7. Example: Observer pattern Subject + attach(observer); + detach(observer); Observer + update(); An observer attaches itself to a subject. attach update When the state of a subject is updated, the subject calls update. An observer detaches itself from a subject if it no longer needs update notification. detach

8. Relationship among Objects The pattern allows many-to-many relation. • Several observers can watch one subject. • An observer can watch several subjects. Observer 1 Subject 1 Observer 2 Subject 2 Observer 3 Subject 3 Observer 4

9. one subject-to-many observers constraint • A constraint: one subject – to – many observers prohibits an observer attached to several subjects. • This constraint is hard to describe in usual assertion. • An observer has no information about attached subjects. A subject cannot know whether an observer is already attached to other subjects. Subject 1 attached Observer 1 Subject 2 Observer 2

10. Implementation using traditional assertion • This implementation adds the field “subject” recording an attached subject to Observer. • Subject.attach checks and updates the field. • Subject.detach method resets the field.

11. Problem in this approach • Broken encapsulation of Observer • Only attach and detach methods of Subject can modify the subject field of Observer. • An observer must not modify its field. attach Subject Observer must not modify read/write subject

12. Our approach • Assertion and Design by Contract • Assertion crosscutting objects • Example: Observer pattern with an inter-object constraint • Aspect for Assertion • Rewriting inter-object constraint using aspect • Discussions • Effect on software quality • Related work

13. Aspect for assertion • Aspect modularizing crosscutting assertion • We use our simple aspect-oriented language. • We only need a subset of AspectJ to describe assertion. • not the full set of AspectJ or other AOP implementation. • For prototyping, we have developed a translator for our language to AspectJ.

14. Our language construct • Join Point Model • AspectJ Join Point Model is suitable. • Pre/post-conditions are usually checked before/after a method call. • State-based join point model might make other model of assertion. • Pointcut • call pointcut is main construct. • Context exposure is important. • this, target, args pointcuts in AspectJ • Because assertion usually access contextual information. • We did not use other powerful pointcuts such as cflow. • Evaluating effectiveness of such pointcuts is a future work.

15. Advice and inter-type declaration • Advice • An advice can define pre-/post-conditions, and code blocks. • Both pre-/post-conditions are usually defined for one pointcut. • An advice might need to execute some code to record or to calculate data for assertion. • Inter-type declaration • Aspect needs additional fields and methods. • Fields to record the inter-mediate state, • Methods to inspect the complex state and to update fields.

16. The beginning of aspect definition Inter-type declaration (AspectJ style) The end of aspect definition Constraint aspect for Observer Advice for Subject.attach (Next) Advice for Subject.detach (omitted)

17. The beginning of advice definition Pointcut declaration this calls target.method(args) Preconditions (before advice in AspectJ) code block executed after the postconditions are checked. The end of advice definition Advice for Subject.attach

18. Modularizing assertion in aspect Aspect adds an additional field to Observer and assertions using the field to Subject. Inter-type declaration advice

19. Effect on software quality • Assertion and Design by Contract • Assertion crosscutting objects • Example: Observer pattern with an inter-object constraint • Aspect for Assertion • Rewriting inter-object constraint using aspect • Discussions • Effect on software quality • Related work

20. Improved modularity (1/2) • Related assertions, fields and methods groups together. • In observer example, the subject field is separated from classes. • An aspect prevents developers from misusing such fields and methods for other purposes.

21. Improved modularity (2/2) • Context-specific assertions can be defined in each aspect. • An example: additional assertion checked when a component is called from an experimental code. • The assertion is not checked when the component is called from a well-tested component. • A developer can explicitly separate additional assertions. Experimental Code Strict checking aspect A component Well-tested Component

22. Improved reusability • A developer can easily add and remove • specific purpose assertion, e.g. for testing and debugging. • A developer can reuse assertion modules for debugging developed in the past debugging task. • application-specific constraints for a generic component. • Observer pattern implementation is usable for many-to-many relationship when a developer remove one-to-many constraint aspect.

23. Drawback: reduced readability • Multiple aspects define assertions for a component. • Q. Does a developer have to inspect all aspects to understand a component ? • If a developer want to know all possible behavior of the component, yes, he or she has to inspect all aspects. • When a developer inspects a pair of a component and its client, the developer has to inspect assertions only for the pair. • Tool-support for developers to manage and inspect aspects is important. • For the safety, we set a limit to aspect: an aspect can add assertions, but cannot remove. • Even if a developer has no information about aspects, testing reveals violated assertions added by aspects.

24. Related work • Behavioral Specification Language • JML, Larch, … • Useful and practical in OOP • Our proposal is an AOP extension for them. • Other extensions for behavioral specification • Temporal Invariants (Gibbs et al.) • It introduces temporal logic to describe assertion. • It can specify assertions for a sequence of method calls. • Pipa (Zhao et al.) • JML extension for advices in AspectJ. • Moxa (Yamada et al.) • JML extension for common contract to a set of methods.

25. Summary and future work • Assertion is a useful tool for software development. • However, some assertion crosscuts objects. • We propose aspect-oriented modularization of assertion. • AOP improves modularity of assertion, reusability of assertion and reusability of components. • Future work • Evaluating how features contribute expressive and powerful assertion. • control and data flow pointcut • annotation-based pointcut • temporal logic • state-based join point model • Detecting and modularizing a common constraint among modules. • To support program understanding.

27. Behavioral Subtyping • A component with additional assertion is out of the behavioral subtype. Assertion Aspect Strong Specialized Implementation Original Component require (pre- condition) Extension Behavioral Subtyping Simple Implementation Generalization Weak Weak ensure (postcondition) Strong

28. Moxa JML Moxa’s approach • Instead of listing assertions for each method, lisitng methods for each assertion. Assert A Method 1 Method 1 AssertB AssertA Method 2 AssertA Method 2 AssertB AssertB Method 3 AssertC AssertA Method 3 AssertC

29. Implementation of Translator Using Racc, Parser Generator for Ruby. Simple rules are defined. before(): pointcut { assert(X); Block 1; } after(): pointcut { assert(Y); Block 2; assert(Z); } Pre X; { Block 1 } Post Y; { Block 2 } Z;

30. Implementation of Translator (2) • Pointcut translation call(* ClassOfB.signature(..)) && this(A) && target(B) && args(C) A calls B.signature(C)