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
[email protected]
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
1
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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
2
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3
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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
4
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
5
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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
6
Example: Observer pattern
Observer
Subject
+ update();
+ attach(observer);
+ detach(observer);
An observer
attaches itself to
a subject.
An observer detaches
itself from a subject
if it no longer needs
update notification.
attach
update
When the state of a
subject is updated,
the subject calls update.
detach
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
7
Relationship among Objects
Observer 1
Subject 1
Observer 2
Subject 2
Observer 3
Observer 4
Subject 3
The pattern allows many-to-many relation.
Several observers can watch one subject.
An observer can watch several subjects.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
8
one subject-to-many observers constraint
A constraint: one subject – to – many observers
prohibits an observer attached to several subjects.
Observer 1
Observer 2
attached
Subject 1
Subject 2
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
9
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
10
Problem in this approach
Broken encapsulation of Observer
attach
Subject
Observer
must not
modify
subject
read/write
Only attach and detach methods of Subject can
modify the subject field of Observer.
An observer must not modify its field.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
11
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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
12
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
13
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
14
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
15
Constraint aspect for Observer
The beginning of
aspect definition
Advice for Subject.attach (Next)
Advice for Subject.detach (omitted)
The end of aspect definition
Inter-type
declaration
(AspectJ style)
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
16
Advice for Subject.attach
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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
17
Modularizing assertion in aspect
Inter-type
declaration
advice
Aspect adds an additional field to Observer and
assertions using the field to Subject.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
18
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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
19
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
20
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.
Experimental
Code
Well-tested
Component
Strict checking aspect
A component
The assertion is not checked when the component is called from a
well-tested component.
A developer can explicitly separate additional assertions.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
21
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-tomany relationship when a developer remove one-tomany constraint aspect.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
22
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
23
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
24
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
25
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
26
Behavioral Subtyping
A component with additional assertion is out
of the behavioral subtype.
Assertion Aspect
Strong
Specialized
Implementation
Original
Component
require
(precondition)
Weak
Simple
Implementation
Weak
Extension
Behavioral Subtyping
Generalization
ensure (postcondition)
Strong
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
27
Moxa’s approach
Instead of listing assertions for each method,
lisitng methods for each assertion.
JML
Method 1
Assert A
Assert B
Moxa
Assert A
Assert A
Method 2
Method 3
Assert B
Method 1
Method 2
Assert B
Assert A
Assert C
Method 3
Assert C
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
28
Implementation of Translator
Using Racc, Parser Generator for Ruby.
Simple rules are defined.
before(): pointcut {
Pre X;
assert(X);
{ Block 1 }
Block 1;
Post Y;
}
{ Block 2 }
after(): pointcut {
Z;
assert(Y);
Block 2;
assert(Z);
}
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
29
Implementation of Translator (2)
Pointcut translation
A calls B.signature(C)
call(* ClassOfB.signature(..))
&& this(A)
&& target(B)
&& args(C)
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
30