Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Modularization.

Similar presentations


Presentation on theme: "Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Modularization."— Presentation transcript:

1 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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,

2 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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. assert(X); { // do something } assert(Y); assert(Z); Preconditions to be satisfied before the element is executed. Postconditions to be satisfied after the element is executed. execute

5 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 7 Example: Observer pattern Observer + update(); Subject + attach(observer); + detach(observer); attach update detach An observer attaches itself to a subject. 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.

8 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Observer 2 Observer 3 Observer 4 Subject 1 Subject 2 Subject 3

9 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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. attached Observer 1 Observer 2 Subject 1 Subject 2

10 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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. Observer Subject subject read/write attach must not modify

12 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 16 Constraint aspect for Observer Advice for Subject.detach (omitted) Inter-type declaration (AspectJ style) The beginning of aspect definition The end of aspect definition Advice for Subject.attach (Next)

17 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 17 Advice for Subject.attach Pointcut declaration this calls target.method(args) Preconditions (before advice in AspectJ) code block executed after the postconditions are checked. The beginning of advice definition The end of advice definition

18 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 18 Modularizing assertion in aspect Aspect adds an additional field to Observer and assertions using the field to Subject. Inter-type declaration advice

19 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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. A component Well-tested Component Experimental Code Strict checking aspect

22 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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.

26 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 26

27 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 27 Behavioral Subtyping A component with additional assertion is out of the behavioral subtype. require (pre- condition) ensure (postcondition) Strong Weak Strong Weak Behavioral Subtyping Specialized Implementation Original Component Simple Implementation Generalization Extension Assertion Aspect

28 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 28 Moxa’s approach Instead of listing assertions for each method, lisitng methods for each assertion. Method 1 Method 2 Method 3 Assert A Assert B Assert C Assert A Assert B Assert A Assert C Assert B Method 1 Method 2 Method 3 JMLMoxa

29 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 29 Implementation of Translator Using Racc, Parser Generator for Ruby. Simple rules are defined. PreX; { Block 1 } PostY; { Block 2 } Z; before(): pointcut { assert(X); Block 1; } after(): pointcut { assert(Y); Block 2; assert(Z); }

30 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 30 Implementation of Translator (2) Pointcut translation A calls B.signature(C) call(* ClassOfB.signature(..)) && this(A) && target(B) && args(C)


Download ppt "Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Modularization."

Similar presentations


Ads by Google