© 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Solving the evolution problems using Composition.

© 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF

Solving the evolution problemsusing Composition Filters

Mehmet Aksit and Lodewijk BergmansTRESE Group

Department of Computer ScienceP.O. Box 217

7500 AE Enschede, The [email protected]; [email protected]

http://trese.cs.utwente.nl


Copyright statement

• You are not allowed to use part or whole of the tutorialmaterial for any commercial purpose unless a writtenpermission has been given by the TRESE group;

• If you use part or whole of the material for a non-commercial purpose, then you have to make areference to our web-site "taken from http://trese.cs.utwente.nl" and always include thesetwo copyright conditions.


Table of contentsIntroduction

Dynamic behavior

Synchronization

History sensitivity

Multiple views

Evaluation

Monitoring


If you want to know more about theevolution problems,

please refer to the e-tutorial 01http://trese.cs.utwente.nl/courses/e_tutorials/evolution_problems.ppt

Introduction to CF

Evolution problems


Instead of providingdedicated solutions

by modifyingclass descriptions, Composition Filters

offers modular extensions toclass abstractions

expressed in languages likeJava, C++ and Smalltalk.

a filter

A modularextensiona class

Filters are modularextensions

Introduction to CF


In case more than one concernis needed, multiplefilters can be used.

Modular &independentextensions

a class

filter1

filter2

filter3

filter4

Each filter transforms incomingand/or outgoing messages

to/from object.

message

Filters specificationsare independent of

each other!

Filters are independentextensions

introduction to CF


Crosscutting concerns

error

meta

dispatch

error

meta

dispatch

error

meta

dispatch

Superimpositionblue_guys <- multiple_views

error

meta

dispatch

Superimposition

Multiple_views

introduction to CF

Filters areattachedto objects

(classes) usingthe superimposition

construct.

a class

a class

a class


New filter types can bedefined by programmers or

may be provided as libraries.However, filter definitions must

be carried out carefully.

introduction to CF

Filters are open-ended


Filters have well-definedsemantics.

For example we havedefined the following filters:

Concern Filter typePre-post conditions ErrorMultiple views ErrorDynamic inheritance DispatchDelegation DispatchLayered architecture MetaHistory sensitivity Meta + history classProtocol Meta + protocol classSynchronization WaitReal time RealTime

introduction to CF

Well-defined semantics


Filters are expressed usingdeclarative specifications.

a filter specification

interpreter compiler

run-time solution compile-time solution

Filters can be interpreted,providing run-time solutions,

or they may be compiled,providing faster solutions.

introduction to CF

Declarative specifications


Monitoring

DynamicMail

LockingMail

I will now implement theevolution scenario using theComposition Filters model.

This scenario was presented in:http://trese.cs.utwente.nl/courses/e_tutorials/evolution_problems.ppt

Warning2Mail

ORViewMail

USViewMail

EMail

Lets try to reusethe classes as

much as possible.

Evolution scenariomultiple views


Assume that USViewMail aggregates

Email for reuse.In addition, 2 filters called multipleViews and invoke,and two new operations

userView and systemVieware defined.

USViewMail

userView;systemview;

EMail

putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);

getContent;send;reply;

approve;putRoute(aRoute);

deliver;getOriginator;getReceiver;

getRoute;isDelivered;isApproved;

Implementation ofUSViewMail using CF’s

multiple views

Filter: invoke

Filter: multipleViews


USViewMail using CF’s (cont’ed)

multiple views

This is thespecification

of the first filter!

multipleViews: Error = {

userView => {putOriginator, putReceiver, putContent, getContent, send, reply},

systemView => {approve, putRoute, deliver},

True => {getOriginator, getReceiver, isApproved, getRoute, isDelivered}

}



multiple views

This is how it works: Assume that the received message isputOriginator, and userView is True.





}

putOriginator(anOriginator)

Filters are evaluated from left to right. Since the conditionuserView is True, the message is tried to match the userViewspecification.

userView

Truematch

If there is a match, in case of an error filter, the message ispassed to the next filter.




multiple views

Here is another example. Assume that the received message isapprove, and userView is False and systemView is True.





}

approve

Since the condition userView is False, the specification of thesystemView is matched. The comma here is a Conditional-Oroperator.

userView

False match

Since there is a match, the message approve is passed to thenext filter.

approve

systemView

True



multiple views

Here is the 3rd. example. Assume that the received message isdeliver, and userView is True and systemView is False.





}

deliver

Since the condition userView is True, the specification of theuserView is tried to match.

userView

True no match

Since there is no match, the message is tried to match thefollowing specifications.

systemView

False

no match

The message is rejected and error condition is generated!

ERROR



multiple views

This is thespecification

of the second filter!Here, mail is an instance

of Email.

invoke: Dispatch = { True=> inner.*, mail.*};



multiple views

Assume that the received message is putOriginator, and the Error filter has accepted the message.


Since the condition is True, the message is tried to match theoperations of inner and mail. The evaluation is from left to right.

no match

Here inner represents the operations declared by USViewMail.putOriginator does not match.


invoke: Dispatch = { True=> inner.*, mail.*};True

True

mail is an instance of Email. putOriginator matches putOriginatorof Email and the message is dispatched to mail.

match


2 x filters

2 x operations

USViewMail

userView;systemview;

EMail

putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);

getContent;send;reply;

approve;putRoute(aRoute);

deliver;getOriginator;getReceiver;

getRoute;isDelivered;isApproved;

Evaluation ofUSViewMail

multiple views

Filter: invoke

Filter: multipleViews

In CF basedimplementation to

add 2 views, 2 filtersand 2 operations

has to be defined!


An analogy to Composition Filters ispresented as an e-tutorial:

http://trese.cs.utwente.nl/courses/e_tutorials/analogy_cf.ppt.

If you want to read more about Composition Filters,please refer to:

http://trese.cs.utwente.nl/composition_filters/

Referencesevaluation


These are thecharacteristics

of the Composition-Filters

model.

Conclusions

• Can express crosscuttingconcerns per object or multipleobjects;

• Modular extensions;• Independent extensions;• Open-ended solutions;• Well-defined semantics;• Switching between run-time or

compile-time solutions.

evaluation

© 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Solving the evolution problems using Composition.

Documents

cf evolution problems

cf slide

cf usviewmail

tutorial material

class filters

cf copyright statement

multiple filters

modular independent