Modularization of Assertion Crosscutting Objects

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

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}@[email protected]


OverviewAssertion and Design by Contract

Assertion crosscutting objectsExample: Observer pattern with an inter-object constraint

Our proposal: Aspect for Crosscutting AssertionRewriting inter-object constraint using aspect

DiscussionsEffect on software qualityRelated work


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.


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 satisfiedbefore the element is

executed.

Postconditions to be satisfied after the element is executed.

execute


Effectiveness of assertionExplicit 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.


Assertion is effective. However …Assertion and Design by Contract


Aspect for AssertionRewriting inter-object constraint using aspect



Example: Observer pattern

Observer

+ update();

Subject

+ attach(observer);+ detach(observer);

attach

update

detach

An observer attaches itself to a subject.

When the state of asubject is updated,the subject calls update.

An observer detaches itself from a subject if it no longer needs update notification.


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


one subject-to-many observers constraint

A constraint: one subject – to – many observersprohibits 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.

attachedObserver 1

Observer 2

Subject 1

Subject 2


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.


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 notmodify


Our approachAssertion and Design by Contract





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.


Our language constructJoin 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.

Pointcutcall pointcut is main construct.Context exposure is important.

this, target, args pointcuts in AspectJBecause assertion usually access contextual information.

We did not use other powerful pointcuts such as cflow.Evaluating effectiveness of such pointcuts is a future work.


Advice and inter-type declaration

AdviceAn 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 declarationAspect needs additional fields and methods.

Fields to record the inter-mediate state,Methods to inspect the complex state and to update fields.


Constraint aspect for Observer

Advice for Subject.detach (omitted)

Inter-typedeclaration(AspectJ style)

The beginning of aspect definition

The end of aspect definition

Advice for Subject.attach (Next)


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 ofadvice definition

The end ofadvice definition


Modularizing assertion in aspect

Aspect adds an additional field to Observer and assertions using the field to Subject.

Inter-typedeclaration advice


Effect on software qualityAssertion and Design by Contract





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.


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 componentWell-testedComponent

ExperimentalCode

Strict checking aspect


Improved reusability

A developer can easily add and removespecific 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.


Drawback: reduced readabilityMultiple 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.


Related workBehavioral Specification Language

JML, Larch, … Useful and practical in OOPOur proposal is an AOP extension for them.

Other extensions for behavioral specificationTemporal 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.


Summary and future workAssertion 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 workEvaluating how features contribute expressive and powerful assertion.

control and data flow pointcutannotation-based pointcuttemporal logicstate-based join point model

Detecting and modularizing a common constraint among modules.To support program understanding.


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

OriginalComponent

SimpleImplementation Generalization

Extension

Assertion Aspect


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 A

Assert C

Assert B

Method 1

Method 2

Method 3

JML Moxa


Implementation of Translator

Using Racc, Parser Generator for Ruby.

Simple rules are defined.

Pre X; { Block 1 }Post Y;

{ Block 2 }Z;

before(): pointcut {assert(X);Block 1;

}after(): pointcut {

assert(Y); Block 2;assert(Z);

}


Implementation of Translator (2)

Pointcut translation

A calls B.signature(C)

call(* ClassOfB.signature(..))&& this(A) && target(B)&& args(C)

Modularization of Assertion Crosscutting Objects

Documents

Transcript of Modularization of Assertion Crosscutting Objects