� Modeling Aspects with AP�P Components

In this section� we outline the elements of APPC construct and show how APPCs can be usedto model aspects� We will start with a small set of APPC concepts� illustrate the use of theseconcepts in modeling aspects and then inttroduce the rest of the concepts by presenting moresophisticated examples� In order to facilitate the comparison� a good part of the examples inthis section are taken� eventually slightly modi�ed� from the tutorial on AspectJ ���� which isthe �rst extension of Java designed and implemented to bridge the gap between object andaspectual decomposition in Java�

��� AP�P Components as a Language Construct

An AP�P component is a module construct for object�oriented languages on top of classes thatserves to capture behavior that aects several classes� However� the captured behavior is writtenin terms of an ideal class graph and not to a concrete application� An AP�P component consistsof the following elements

� A set of participants� A participant is a formal class �or a class in an ideal class graph�ICG�� which stands at the same level as a formal argument in a procedure declaration Ineeds to be later bound to classes in a concrete class graph� CCG�

� Instead of type constraints to be satis�ed by the CCG classes� a participant de�nitionmerely lists a set of operation signatures� preceded by the keyword expected�

� Expected operations are used in the appc�speci�c de�nition of the participant� This de��nition includes

�a� reimplementations� of the expected operations� denoted by the keyword replace�

�b� de�nitions of new operations � all operations in the de�nition of a participant thatare declared public�

�c� new �eld de�nitions that would extend the structure of the CCG classes to be boundto this participant�

�e� In order to implements replacements or new functionality� a participant de�nitionmight include local� de�nitions �operations as well as �elds�� These are denoted bythe same keywords as in Java private� protected�

The key idea behind APPCs as a construct for reconciling object�based and aspect�baseddecomposition of the systems is to add a new dimension in the organization of object�orientedsoftware� as illustrated in Fig� �� The software is �rst decomposed based on aspects which aresymbolically represented by rectangle areas with dierent grey scales in Fig� �� Each aspectde�nition has its own object�based decomposition� Dierent data types involved in an aspectde�nition are represented by dierent shapes in Fig� �� Aspect de�nitions are based on the as�sumption that other aspects or�and the concrete application will supply part of the functionalityof the involved data which is then modi�ed�extended by the aspect� The expected interface ofaspect de�nitions is represented by the transparent �colorless� shapes on the left hand side ofall but one colored area in Fig� ��

The left most colored area in Fig� � represents a concrete application� It is self�contained inthat it does not expect anything to be supplied from the outside and provides the basic imple�mentation of the application functionality� It is generally much richer in data type de�nitionsthan the aspect de�nitions� The modi�cations and�or extensions of the expected interface byaspect de�nitions are illustrated by the shape towers on the right hand side of each grey scale

�

area there are generally more shapes of each kind on the right hand side than on the left handside� Colorless shapes on the left hand side are replaced by colored shapes on the right handside� In addition� some new shapes are added to each tower�

Figure � Aspect Decomposition with APPCs

For illutrating the concepts so far� we start with a very simple example� The aspect con�sidered here is a trivial one instrumenting access operations on data types� A description ofthe aspect in informal English would be For any data type in an application� say DataToAc�

cess� any read access operation� AnyType readOp�� de�ned for DataToAccess� and any invocationof this operation on an instance of DataToAccess� dataInstance� display Read access on �string

representation of dataInstance�� Sure enough� the description is reusable in dierent contexts�since it does not make any commitment about its application context� It is obvious that anaspect de�nition language that allows to delay binding aspects to their deployment contexts isdesirable� This is in fact the key point about using APPCs to model aspects�

The code in the ShowReadAccess appc below is actually as free of details about concretedeployment contexts as the informal English description above is� It simply states that whateverclasses in an application will be assigned to implement �play� the single participant in the aspectde�nition� DataToAccess� and whatever methods in these classes will be assigned to implementthe interface expected from DataToAccess� readOp in this case� the latter methods will be replacedby implementations that �rst print out a message and then execute the original methods �seethe replace statement below��

ShowAccesses package �

appc ShowReadAccesses f

participant DataToAccess fexpected Object readOp � � �

replace Object readOp � � fSystem � out � p r in t ln � �Read access on � � this � toStr ing � � �return expected � read op � � �

gg

g

�

� � �

The meaning of the pseudo�variable this is the same as in a Java program� In the de�nitionabove� it denotes the application instance being instrumented� If there are no ambiguities� thereis no need to explicitly refer to the pseudo�variable this� Any invocation without an explicitreceiver is considered to be a self�invocation� A method for this invocation is �rst looked�up inthe aspect�speci�c de�nition of the participant� If no method is found there� the class in theapplication assigned to play the participant role is searched for�

Now� given a concrete application the programmer needs to deploy the aspect with the ap�plication by assigning classes in the application to aspect participants and by specifying howthe interface expected by the aspect is implemented in terms of the application� Specifying amapping for the expected interface of an aspect occurs apart of the de�nition of an aspect bymeans of so�called connector constructs� In abstract terms� the deployment process is schemati�cally presented in Fig� �� The connector is symbolically represented by the two colored rectanglebetween the application and the aspect� It transforms a part of the application de�nition intothe expected interface of the appc� The result of the deployment is equivalent to the set of shapetowers on the right hand side of Fig� �� Partial de�nitions from the application and the aspectare mixed together into the �nal de�nition of each object�

Figure � Deploying Aspects with Applications

For illustration consider the trivial example of an application that models graphical shapes�the Shapes package below�� and a simple deployment scenario in which we are interested ininstrumenting only read accesses on point objects�

Shapes package �

class Point fprivate int x � �private int y � �

void set � int x int y � f x � x � y � y �g

�

void setX � int x � f x � x � gvoid setY � int y � f y � y � gint getX � �f return x � gint getY � �f return y � g

g

class Line f � � � g

class Rectangle f � � � g� � �

The deployment of ShowReadAccesses with the class Point is speci�ed by the ShowReadAc�

cessConn� connector below�

Deployment package �

import ShowAccesses �� �import Shapes �� �

connector ShowReadAccessesConn� fPoint i s DataToAccess with f readOp � get �g �

g

� � �

The connector in the example above is simple� It contains only one implement statement�In general� a connector consists of several scopes� where each scope contains several implementsstatements� A simpli�ed grammar of the struture of connector is given in Fig� ��� The class�to�participant mapping in an implements statement is in general many to one� as it will beillustrated in the following� An implement statement has one or more mapping clauses for theexpected interfaces associated with it� In the example above the mappping is done based onpattern matching on operation names� with the pattern being speci�ed by the regular expressionget�� In general� this mapping can also take a more programmatic� form� i�e�� an implemen�tation of the expected signature is given by means of composing functionality provided by theapplication� Later in this section� we will present more sophisticated examples that give a morecomplete picture of the structure of connectors�

For the moment being� it should be noted that specifying deployment details apart of anaspect de�nition� make the aspect reusable with other classes without changing its de�nition�Rather� what is needed is the de�nition of a new connector� For illustration� assume thatafter having de�ned ShowReadAccessesConn�� we realize that read accesses on lines need also beinstrumented as well� For this purpose the ShowReadAccessesConn� connector is de�ned belowas an extension of ShowReadAccessesConn��

connector ShowReadAccessesConn� extends ShowReadAccessesConn� fLine i s DataToAccess with f readOp � get �g �

g

� � �

On the other side� if we knew from the very beginning that whatever classes are included inthe application� we would like to instrument all read access operations� we would have de�nedShowReadAccessesConn�� rather than ShowReadAccessesConn�� If this was the case� no modi��cation of the aspect or extension of the connectors would be needed� if we extend the applicationwith a new data type� say Circle�

connector ShowReadAccessesConn f

�

Shapes �� i s DataToAccess with freadOp � set � �

gg

An aspect can be de�ned that aects several operation categories of the same class in dierentways� For illustration� assume that in addition to read accesses� we would like to instrumentwrite accesses� This is expressed by the ShowReadWriteAccesses component below� The aspectis then deployed with the shape package by ShowReadWriteAccessesConn��

ShowAccesses package �

appc ShowReadWriteAccesses f

participant DataToAccess fexpected Object readOp � � �expected void writeOp � Object � � args � �

replace Object readOp � � fSystem � out � p r in t ln � �Read � � d i sp laySt r ing � � � �return expected � read op � � �

g

replace void writeOp � Object � � args � fSystem � out � p r in t ln � �Write � � d i sp laySt r ing � � � �expected � wr i te op � Object � � args � �

g

private Str ing d i sp l aySt r ing � � freturn � access on � � this � toStr ing � � �

g

gg

� � �

Deployment package �

import ShowAccesses �� �import Shapes �� �

connector ShowReadWriteAccessesConn� fShapes �� i s DataToAccess with f

readOp � set � �writeOp � get � �

gg

Assuming that ShowReadAccesses was already de�ned� we could also de�ne ShowReadWriteAc�

cesses as an extension of ShowReadAccesses� and the corresponding connector as an extensionof the ShowReadAccessesConn� connector� thus supporting reuse at the level of both aspect andconnector de�nitions�

appc ShowReadWriteAccesses extends ShowReadAccesses f

participant DataToAccess f

�

expected void writeOp � Object � � args � �

replace void writeOp � Object � � args � fSystem � out � p r in t ln � �Write access on � � this � toStr ing � � � �expected � writeOp � Object � � args � �

g

gg

connector ShowReadWriteAccessesConn� extends ShowReadAccessesConn fShapes �� i s DataToAccess with f

writeOp � get � �g

��� AP�P Components versus Frameworks

��� Composing Aspects

The example discussed so far illustrated the basic elements of the AP�P Component languagefor aspect de�nition� deployment� and reuse� In the following� we show a few more details re�lated to aspect de�nition and concentrate on how aspects can be composed� The �rst exampleillustrates how aspects can be composed by being deployed simultaneously with the same appli�cation� For illustrating this case� two new aspects are de�ned below� The �rst aspect is aboutlogging new instances in a system� called NewInstanceLogging below� The NewInstanceLoggingcomponent illustrates the de�nition�initialization and use of aspect related state which is sharedby all application classes that will be assigned to participant roles of the aspect for a certain de�ployment� For instance� equally how many application classes will be assigned to be DataToLogduring a deployment� they all will share the logObject variable de�ned in NewInstanceLogging�

appc NewInstanceLogging f

participant DataToLog f

expected public DataToLog� Object � � args � �

replace public DataToLog� Object � � args � fexpected � DataToLog� args � �long time � System � currentTimeMi l l i s � � �try f

Str ing class � this � class � getName �� � � � �logObject � writeBytes � �New instance of � � class � at � � � time � � � n n � �

g catch � IOException e � f System � out � p r in t ln � e � toStr ing � � � � gg

g

protected static DataOutputStream logObject � null �

public static i n i t � � ftry f logObject � new DataOutputStream �new FileOutputStream � log � � �gcatch � IOException e � f System � out � p r in t ln � e � toStr ing � � � � g

gg

The second aspect is about automatically resetting values of certain data types after a certainnumber of accesses on that data has occurred� This second aspect� called AutoReset� is de�ned

�

below It introduces a new instance variable to each application object that will be mapped tothe DataToReset participant role in the component� called count� It is an instance variable� sinceit is declared as non�static within the aspect�speci�c de�nition of DataToReset� The AutoReset

component illustrates another feature of AP�P Components there are two kinds of expectedoperations� The �rst kind� represented by setOp� includes operations which are expected inorder to be replaced by the aspect �expected operations preceded by the keyword replaced��Operations of the second kind� represented by reset are expected in order to be used by theaspect�speci�c de�nition of the participants� Expected operations of the �rst kind constitutethe so�called modi�cation interface between aspects and application� This corresponds to theconcept of joint points in AspectJ� Expected operations of the second case constitute what wecall usage interface between aspects and application�

appc AutoReset f

participant DataToReset fexpected void setOp � Object � � args � �expected void r e s e t � � �

protected int count � �

replace void setOp � Object � � args � fi f � ��count �� � � f

expected � setOp � args � �count � �r e s e t � � �

gg

gg

Let us now consider how these aspects are composed by being deployed with the Shapes

application� we have been using so far� Assume that we want �a� all three aspects to applyto points� �b� ShowReadWriteAccesses and NewInstanceLogging to apply to Line� and �c� onlyNewInstanceLogging to apply to Rectangles� This is expressed by the connector CompositionConn�

below� This connector illustrates that besides specifying mappings for expected operations bymeans of pattern matchings on method names� the deployment programmer can also directlyimplement an operation in the expected interface in terms of operations and�or state de�ned inthe application� This is illustrated by the de�nition of reset�� in CompositionConn�� i�e�� in thiscase the mapping is programmatic� rather than declarative�

connector CompositionConn� ff Line Point g i s DataToAccess with f

readOp � set � �writeOp � get � �

g �

Point i s DataToReset with fresetOp � set � �void r e s e t � � f

x � �y � � g

g �

Shapes �� i s DataToLog �

�

g

The composition structure expressed by CompositionConn� is symbolically represented inFig� �� The composed deployment is presented on the left hand side of Fig� �� On the right handside the result of the deployment is shown by the towers of shapes� representing the resultingweaved code for points �represented by triangles in the �gure�� lines �represented by xxx in the�gure�� respectively rectangles �represented by circles in the �gure��

Figure � Deploying Several Aspects with the Same Application

Specifying connections apart of the de�nitions of the individual aspects� makes aspect def�initions more reusable� For instance� we can later add new connection statements to specifyadditional joint points� between an application and aspects� as illustrated by the Composition�

Conn� connector below� which deployes the AutoReset aspect also with lines�

connector CompositionConn� extends CompositionConn� f

Line i s DataToReset with fresetOp � set � �void r e s e t � � f i n i t � � �gg �

g

Besides adding new connection statements� one can also modify existing ones� This is il�lustrated by the connector CompositionConn� below� It rede�nes the connection Composition�

Conn��s statement for Point� to distinguish between the reset policy for operations that changeboth coordinates simultaneously and operations that change only one of the coordinates� Threedierent cases are distinguished by specifying three dierent connection clauses� This connectionstatement overrides the respective connection statement for the class Point� in CompositionConn��

connector CompositionConn extends CompositionConn� f

Point i s DataToReset with ff resetOp � set �

�

void r e s e t � � fx � � y � � g

g

f resetOp � setX �void r e s e t � � f x � �g

g

fresetOp � setY �void r e s e t � � f y � �g

gg �

g

In the example considered so far� the aspects to be composed are independent form eachother� The connector CompositionConn� is equivalent to specifying three independent connectors�actually this is what Fig� � suggests�� The order of deploying the individual aspects beingcomposed is not important� In the following� we will illustrate how the expected interface ofan aspect can be partly implemented by the application and partly connected to the providedinterface of another aspect after the latter has been itself deployed with classes in the concreteapplication� Consider �rst the following two components�

aspect package �

appc DataWithCounter f

participant Counter fvoid r e s e t � � �void inc � � �void dec � � �

gparticipant DataStructure f

protected Counter counter �expected void in i tCounter � � �

�� the method for i n i t i a l i z i n g the count f i e l d i s l e t to be bound�� at deployment time � when the concrete type of Counter i s known

expected void make empty � � �expected void push � Object a � �expected void pop � � �

replace void make empty � � fcounter � r e s e t � � �expected � empty � � �

greplace void push � Object a � f

counter � inc � � �expected � push � Object a � �

greplace void pop � � f

counter � dec � � �expected � pop � � �

g

�

gg

appc DataWithLock f

participant Data f

Lock lock �expected void in i tLock � � �expected AnyType method to wrap � Object � � args � �

replace AnyType method to wrap � Object � � args � fi f � lock � i s un locked � � � f

lock � lock � � �expected � method to wrap � Object � � args � �lock � unlock � � � g

gg

participant Lock fexpected void lock � � �expected void unlock � � �expected boolean i s un locked � � �

gg

The �rst aspect adds functionality for counting the elements included in a container datatype� such stacks� queues� etc� The second aspect adds functionality for synchronizing invoca�tions of certain operations on a given data type by means of a lock� Now assume the followingapplication� which provides implementations for data types� such as stacks� queues� counters�locks� etc� We can now model stack and queue objects that count their elements and theoperations of which are synchronized by means of a lock by specifying the connectors in thedeployment package below� This kind of composition is schematically presented in Fig� ��

appl package �

class StackImpl fStr ing s � new Str ing � � �void empty � � f s � �� �gvoid push � char a � f s � Str ing � valueOf � a � � concat � s � �gvoid pop � � f s � s � substr ing � � � � gchar top � � f return � s � charAt � � � �g

g

class QueueImpl f � � � g

class CounterImpl fint i � �void reset Impl � � f i� �g �� � �

g

class LockImpl fboolean l � true �boolean i s un locked � � f return l �g� � �

��

g

deployment package �

connector addCounter fCounter � CounterImpl i s DataWithCounter � Counter �

Stack � StackImpl i s DataWithCounter � DataStructure with fvoid in i tCounter � � f counter � new Counter � � �gvoid push � Object obj � f push � � � Str ing � obj � � charValue � � � � gObject top � � f return � Object � Str ing � valueOf � top � � � � g� � �

g �

Queue � QueueImpl implements DataWithCounter � DataStructure with f� � � g �

g

connector addLock faddCounter � Stack i s DataWithLock � Data with f

method to wrap � f pop push top make emptygg �

addCounter � Queue i s DataWithLock � Data with f � � � g �

LockImpl i s DataWithLock � Lock �g

Figure � Deploying Several Aspects with the Same Application ���

Alternatively� one can create composed aspects prior to deployment with any concrete ap�plication by connecting part of the expected interface of one aspect to part of the provided

��

interface of another� The remaining unbound parts of the expected interfaces are connectedto appliciations during deployment� Creating composed aspects prior to deployment is illus�trated by the following code� First� DataWithStack is composed with DataWithLock into a newaspect� DataWithCounterLock� Later DataWithCounterLock get deployed with the concreteapplication� The process of creating DataWithCounterLock is schematically presented in Fig� ��

aspect package �� � �appc DataWithCounter�Lock f

participant Data � DataWithCounter � DataStructure i s DataWithLock � Data with fmethod�to�wrap � fmake empty pop top push gg �

participant Counter � DataWithCounter � Counter �

participant Lock � DataWithLock � Lock �g

� � �

deployment package �

conector addCounter�Lock f

CounterImpl i s DataWithCounter�Lock � Counter with f� � � g �

StackImpl i s DataWithCounter�Lock � Data with fvoid make empty � � f empty � � �gvoid in i tCounter � � f

counter � new Counter � � �g

void push � Object obj � f push � � � Str ing � obj � � charValue � � � � g� � �

g �

QueueImpl i s DataWithCounter�Lock � Data with f � � � g �LockImpl i s DataWithCounter�Lock � Lock with f � � � g �

g

Figure � Deploying Several Aspects with the Same Application ���

��

��� De�ning New Behavior� The PublisherSubscriber Aspect

In the examples considered so far� there has always been a single deployement of an aspectto a certain application� In the following we will illustrate that due to separate deploymentspeci�cation� an aspect can be multiply deployed with the same application� each deploymentwith its own mappings� For illustration� a publisher�subscriber protocol aspect is modeled inthe appc below�

appc Pub l i she rSubsc r ibe rPro toco l f

participant Publ i sher fexpected void changeOp� Object � � args � �

protected Vector subsc r ibe r s � new Vector � � �

public void attach � Subscr iber subsc � fsubsc r ibe r s � addElement � subsc � �g

public void detach � Subscr iber subsc � fsubsc r ibe r s � removeElement � subsc � �g

replace void changeOp � � fexpected � changeOp � � �for � int i � � i � subsc r ibe r s � s i z e � � � i ��� f

� � Subscr iber � subsc r ibe r s � elementAt � i � � � update � this � �gg

participant Subscr iber fexpected void subUpdate � Publ i sher publ � �protected Publ i sher publ �

public void update � Publ i sher aPubl � fpubl � aPubl �expected � subUpdate � publ � �g

gg

g

In addition to replacing existing methods with enhancements� PublisherSubscriberProtocolde�nes new �elds and methods that are involved in the protocol and establishes the structuralrelationship between the protocol participants� Note that the protocol in PublisherSubscriber�

Protocol is de�ned for two hypothetical participants and not in terms of particular classes� Assuch� it can be applied to dierent publisher�subscribers pairs� as illustrated by the followingtwo connectors� In the �rst case� the publisher role is played by the class Point� while thesubscriber role is played by a simple class� called ChangePrinter� shown below� Establishingthe publisher�subscriber protocol between Point and ChangePrinter is realized by the connectorPubSubConn��

Output package �

class ChangePrinter fvoid public printR � � f

System � out � p r in t ln � � Pr inter � � � this � toStr ing �� �� read access has occurred � � � � � nn � �

gvoid public printW �� f

System � out � p r in t ln � � Pr inter � � � this � toStr ing �� �

��

� write access has occurred � � � � � nn � �gvoid public notifyChange � � f System � out � p r in t ln � �CHANGE � � � � � �g

g

� � �

Deployment package �� � �

connector PubSubConn� fPoint i s Publ i sher with

f changeOp � f set � get �g �gChangePrinter i s Subscr iber with f

void subUpdate � Publ i sher publ � fnotifyChange � � �System � out � p r in t ln � �on point object � � �� Point � publ � � toStr ing � � � �

gg

g

In a similar way� the following code� illustrates the deployment of the protocol de�ned by thePublisherSubscriberProtocol aspect with another application this time a game package includinga class for the TicTacToe game and a class for the graphical interface� GUI� with the latter beingan aggregate of two other classes� BoardDisplay and StatusDisplay� as shown in Fig� ���

connector PubSubConn� f

TicTacToe i s Publ i sher with fchangeOp � f startGame newPlayer putMark endGamegg �

f BoardDisplay StatusDisp lay g i s Subscr iber with fvoid update � Publ i sher publ � f

setGame ��Game� publ � �repa int � � �

gg �

g

Both deployments of the publisher�subscriber aspect shown so far� result in the standardpublisher�subscriber protocol� i�e�� the protocol with one publisher being subscribed by a singleset of subscribers� uniformly interested in any change in the publisher�s state� One can also realizemodi�ed versions of the standard protocol by simply de�ning new connectors� For instance�the connectors� PubSubConn� and PubSubConn� deploy the protocol with the same classes asPubSubConn�� but now two dierent connection clauses distinguish the noti�cation operationsthat are invoked on the subscribers depending on which access operations are invoked on thepublisher� This corresponds to a variation on the publisher�subscriber pattern� where there areseveral lists of subscribers for one publisher� distinguished by the events they are interested in�

connector PubSubConn f

Point i s Publ i sher with f changeOp � set � �g

ChangePrinter i s Subscr iber with fvoid subUpdate � Publ i sher publ � f

��

printW � � �System � out � p r in t ln � �on point object � � �� Point � publ � � toStr ing � � � �g

gg

connector PubSubConn� f

Point i s Publ i sher with f changeOp � get � �g

ChangePrinter i s Subscr iber with fvoid subUpdate � Publ i sher publ � f

printR � � �System � out � p r in t ln � �on point object � � �� Point � publ � � toStr ing � � � �

gg

g

The sets of operations of Point that are mapped to dierent noti�cation operations of thesubscriber participant need not be disjoint� For instance� we may want to distinguish between setoperations that aect the x�coordinate� respectively� the y�coordinate of a point� The set�int� int��however� will then fall in both categories� This is expressed by the connectors PubSubConn���and PubSubConn��� below�

connector PubSubConn � � f

Point i s Publ i sher with f changeOp � f set setX g �g

ChangePrinter i s Subscr iber with fvoid subUpdate � Publ i sher publ � f

printW � � �System � out � p r in t ln � �on the X coord inate of

point object � � �� Point � publ � � toStr ing � � � �g

gg

connector PubSubConn � � fPoint i s Publ i sher with f changeOp � f set setY g � gChangePrinter i s Subscr iber with f

void subUpdate � Publ i sher publ � fprintW � � �System � out � p r in t ln � �on the Y coord inate of

point object � � �� Point � publ � � toStr ing � � � �g

gg

�� Activating�Deactivating Aspects

There are two possible levels of applying aspects object versus class level� which correspond totwo dierent operations in the interface of connectors� Plugging an aspect into an instance of aclass is realized by invoking adapt�ClassForParticipant instance� on the corresponding connector�On the contrary� all instances of a class that plays a participant role in an aspect accordingto the connector c are automatically adapted to their role in the program scope between the

��

pair of invocations c�activate�� and c�deactivate��� Object level application is illustrated by theclient class �client in the sense that it uses Point ChangePrinter and PublisherSubscriberProtocol�Client�� while class level application is illustrated by Client� in the following�

class Cl ient� f� � �public static void main � Str ing � � args � f

� � �Point p � new Point � � �Point p� � new Point � � �p � PubSubConn � adapt � p � �p� � PubSubConn � adapt � p� � �

ChangePrinter ch � new ChangePrinter � � �ChangePrinter ch� � new ChangePrinter � � �

PubSubConn � addSubscr iber � ch p � �

p � setX � �� � ��� w i l l pr in t� � Printer ChangePrinter���� � wr i te access has occurred � � �� � in point ob j e c t Point��

p� � setY � �� � ��� nothing w i l l be pr inted

PubSubConn � addSubscr iber � ch� p� � �p� � setY � � � �

�� w i l l pr in t �� � Printer ChangePrinter���� � wr i te access has occurred � � �� � in point ob j e c t Point���� � �PubSubConn � remove � p � � �� p w i l l not reac t as a pub l i s h e r anymorePubSubConn � removeSubscr iber � ch� p� � �� � �

g� � �

g

class Cl ient� f� � �public static void main � Str ing � � args � f

� � �ShowReadWriteAccessesConn� � ac t i va t e � � �Point p� � new Point � �� � �Point p� � new Point � � � � �Line l � new Line � p� p� � �p� � setX � � � ��� W w i l l be pr inted on the screenPoint p � l � getSource � � ��� R w i l l be pr inted on the screen� � �ShowReadWriteAccessesConn� � deac t i va t e � � �p � getY � � � �

��

�� nothing w i l l be pr inted out� � �

gg

��� Comparison with AspectJ

� less tangled aspects

� aspects easier to understand

� aspects easier to reuse

� aspects easier to modify

� better modularity by separating aspect de�nition from aspect deployment

� Application and aspects could be even developed by dierent programmers�

�

��