© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems...

© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems

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

Software evolution problemsin case of inheritance andaggregation based reuse


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 contents

Introduction Adding monitoring

Adding synchronization

Adding history

Adding multiple views

Basic concern: email

Problems

Aspect-oriented programming

Evaluation

Adding dynamic behavior


Does object-orientedprogramming really fulfil

all the promises?Yes, object-orientation may help you

in realizing robust, adaptable and reusable software. There are many good

examples in the literature!

Object orientationexample


However,You may experience

composition problemssometimes.

Composition problems are:sometimes you cannot reuse

or extend the code,although intuitively you feel

it should be possible!

Let me illustrate this by means of anexample! The purpose of this

example is to understand how muchreuse is possible in object-oriented

programming.

Modeling problemsexample


MailDeliveryOriginator Receiver

Consider a simple mail system, which

consists of classes Originator,MailDelivery, Receiver and EMail.

Here, EMail represents the electronic

messages sent in this system and

provides operations for defining,

delivering and reading mails.

EMail

Exampleexample


Here is theinterface

specificationof EMail!

Class Email interfaceputOriginator(anOriginator);getOriginator returns anOriginator;putReceiver(aReceiver);getReceiver returns aReceiver;putContent(aContent);getContent returns aContent;send;reply;approve;isApproved returns Boolean;putRoute(aRoute);getRoute returns aRoute;deliver;isDelivered returns Boolean;

That’seasy!

Interface of EMailexample


I wouldn’t say that!During the life-cycle

of a software productmany extensionsmay be required.

Class Email interface…………..

I will now presenta number of

possible extensionsto class Email.

Extensions to EMailexample


X putOriginatorX putReceiverX putContentX getContentX sendX reply

Let me introduce a new class: USViewMail.Originator and receiver objects are

classified as user objects. MailDelivery objects are

classified as system objects.

Now assume that USViewMailreuses EMail but does not allow

the system objects toinvoke the following 6 operations!You also wouldn't like the postman

read your mails, right?

User viewmultiple views


X approveX putRouteX deliver

But, USViewMaildoes not allow the user

objects to invokethe following 3 operations!

Postman doesn’t wantyou to approve your own mails!

System viewmultiple views


getOriginator getReceiver isApproved getRoute isDelivered

These operations arenot restricted;

user and systemobjects can invokethese operations!

Operations without viewsmultiple views


Lets try to reuse class EMailas much as possible.

How would you implementclass USViewMail?

Implementation of USViewMailmultiple views


EMail

USViewMail

Here is myimplementationof the operationputOriginator!

userView return client.category = ‘user’;

view checking

execute

errorelse self.error;

putOriginator(anOriginator)

if self.userView

then super.putOriginator(anOriginator)

To reuse the operationsof EMail, USViewMail

may inheritfrom it.

Implementation of USViewMailmultiple views


USViewMail

Imp:EMail

Here is myaggregation-based

implementationof the operationputOriginator!

Here is the second option!To reuse the operations

of EMail, USViewMailmay aggregate

an instance of EMailand redirect the calls

to this object.

Implementation of USViewMail


view checking

execute

errorelse self.error;

putOriginator(anOriginator)

if self.userView

then imp.putOriginator(anOriginator)

multiple views


Wait a minute!How does the server detect the identityof the client object

The server object must test the id of theclient object.

This is not always easy!

In languages like C++ and Java, thisinformation is generally not accessible

by the programmer.


The client can pass the id but thenthe call will have an extra argument;in some languages this is considered

as a different call. Andthe client may lie too!

This is what one might call“lack of expression power problem!”

Identity of the client objectmultiple views


6 x user views

3 x system views

All these 9 operationsmust be re-defined!

+ 2 operations for theviews, in total 11 new

operations must be defined!

Lets assume that userViewcan be computed.

I want to evaluate the inheritance-basedimplementation.

USViewMail

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

getContent;send;reply;

approve;putRoute(aRoute);

deliver;userView

systemView

EMail




delivergetOriginator;getReceiver;

getRoute;isDeliveredisApproved;

The remaining 5operations are inherited!

Implementation of USViewMail

multiple views


6 x user views

Let us evaluate the aggregation-basedimplementation.

5 x forwarding

3 x system views

USViewMail





getRoute;isDeliveredisApproved;userView;

systemview;

EMail




deliver;getOriginator;getReceiver;

getRoute;isDelivered;isApproved;

In the aggregation-basedimplementation to

add 2 views, 16 operationsmust be defined!

These are 6 user and 3 system views + 2 viewimplementations and+ 5 forwarding = 16

operations.

Implementation ofUSViewMail

multiple views


USViewMail





getRoute;isDeliveredisApproved;userView;

systemview;

EMail




deliver;getOriginator;getReceiver;

getRoute;isDelivered;isApproved;

Here is anforwarding example:

getOriginator:: returnimp.getOriginator;

How would you otherwiseaccess the

operations of Email, which do

not enforce any views?

Implementation ofUSViewMail

multiple views


Monitoring

DynamicMail

LockingMail

You know USViewMail isnot the only possible extension

to EMail. As an example,I will introduce the following

classes as extensions:

Warning2Mail

ORViewMail

USViewMail

EMail

Warning2Mail,

LockingMail, DynamicMail

ORViewMail,

Lets try to reusethe classes as

much as possible.

Evolution scenariomultiple views

& Monitoring


I will now introduce a new classcalled ORViewMail.

ClassORViewMail…………..

Now assume thatORViewMail reuses USViewMailbut partitions the user view intooriginator and receiver views.

The originator is not allowedto invoke the operation reply.

The receiver is not allowed toinvoke putOrginator,

putReceiver, putContent and send.

X putOriginatorX putReceiverX putContentX send

X reply

I am theoriginator

I am thereceiver

Originator & receiverviews

multiple views


4 x originator views

1 x receiver view

Now let’s implementORViewMail

using inheritance

Here only 5 operationsmust be re-defined!

and + 2 operations for theviews, in total 7

operations must be defined!The remaining 9

operations are inherited!Inheritance provides

transitive reuse!

ORViewMail


send;reply;

originatorViewreceiverView

EMail

USViewMail

Implementation ofORViewMail

multiple views


ORViewMail






originatorView;receiverView;

USViewMail

4 x originator views

Let us evaluate the aggregation-basedimplementation.

9 x forwarding

1 x receiver view

In the aggregation-basedimplementation

to add the originator andreceiver views, 16

operationsmust be defined!

2 views + 4 originator + 1 receiver

+ 9 forwarding = 16 operations.


multiple views


Let me explain inmore detail.

originatorView return client.category = ‘originator’;

else self.error;

ORViewMail:: putOriginator(anOriginator) if self.originatorView



else self.error;

USViewMail:: putOriginator(anOriginator) if self.userView


OriginatoranORVMail

putOriginator(.)

Email executesputOriginator

Here is myinheritance-basedimplementationof the operationputOriginator of

ORViewMail!


multiple views


The aggregationbased

implementationis similar!


else self.error;

anORVMail:ORViewMail:: putOriginator(anOriginator) if self.originatorView



else self.error;

imp:USViewMail:: putOriginator(anOriginator) if self.userView


an Email object executesputOriginator

Originator

putOriginator(.)

anORVMail


multiple views


I have a problemwith these implementations!

I think it is more logicalto check the general

condition user/system viewfirst and then the more specific

condition originator/receiverview.

You are right!In the inheritance-based

approach, if we change theorder of view checking,

ORViewMail must first callon the super super

class EMail, and then then on thesuper class USViewMail. This may not

be possible in every language.

In the aggregation-basedapproach, this means ORViewMail

must first call on the part class EMail of its part class

USViewMail.This is normally not possible.If the interfaces are fixed, one

may reorganize the aggregation structure using the Decorator

pattern.This is, however, a very special

and restricted case.

Reversing the ordermultiple views


ORViewMail

USViewMail

EMail

Ok, Here is myinheritance-basedimplementationof the operationputOriginator of

ORViewMail!


else self.error;

ORViewMail:: putOriginator(anOriginator) if super.userView

then if self.orginatorView

Email executesputOriginator

The order of viewchecking is reversed.

It is assumedthat the adoptedlanguage allowsmaking calls onany operation

in the hierarchy!

then Email::putOriginator(anOriginator);

Reversing the orderin ORViewMail

multiple views


I will now introduce a new classcalled Warning2Mail.

Now assume thatWarning2Mail reuses

ORViewMailand it gives a warning message

if in the user view,the same operation is

invoked twice or more forthe same mail object

subsequently.

OriginatoraWarning2Mail

putOriginator(anOriginator);

putContent(aContent);

send;

send;

Youinvoked

onsend

more thanonce!

Warning2Mailhistory sensitivity


Here is myinheritance-basedimplementationof the operationputOriginator ofWarning2Mail!

giveWarning(anOperation); self.display(‘you invoked on’, anOperation, ‘more than once!’);

lastCall= ‘putOriginator’;

Warning2Mail:: putOriginator(anOriginator) if lastcall = ‘putOriginator’;

then self.warning(‘putOriginator’);

OriginatoranORVMail

putOriginator(.)

super.putOriginator(anOriginator);

ORViewMail

…..Warning2Mail

history sensitivity


14 x history administration

Let us evaluate the inheritance-basedimplementation.

Warning2Mail






giveWarning(anOperation);

In the inheritance-basedimplementation, to

add history-sensitivity,all the 14 operationsmust be re-defined!

And + 1 warning message,in total

15 operations mustbe defined!

ORViewMail

…..Implementation of Warning2Mail

history sensitivity


Aggregation-basedimplementation

would be similar.In total 15 operations

must be defined!

I know, I know.This is similar to theprevious discussion.

Possibly, there will notbe any reuse at all.You simply have to

re-implement allthe 14 mail operations!

What if I want toreverse the

order of checking?

I think it islogical to check

first the user/systemview, and then

originator/receiver view,

and then more thanonce invocation!

Implementation of Warning2Mailhistory sensitivity


I will now introduce a new classcalled LockingMail.

Now assume thatLockingMail reuses

Warning2Mailand it implements two

operations.The operation lock queues all

theinvocations on a mail object until the unlock is invoked.

If the mail object is unlocked,then then the invocation of

unlock has no affect!

lock();putOriginator(.);putContent(.);send()

locked = falsequeue={ }

aLockingMail

aLockingMail: LockingMail

………...lock;

unlock;

locked = truequeue={ }

locked = truequeue={putOriginator}

locked = truequeue={putOriginator,

putContent}

locked = truequeue={putOriginator,

putContent,send}

locked = falsequeue={putOriginator,

putContent,send}

locked = falsequeue={putContent,

send}

“I am now executingputOriginator”

locked = falsequeue={send}

“I am now executingputContent”


“I am now executingsend”

unlock();


LockingMailsynchronization


14 x semaphore operations

Let us evaluate the inheritance-basedimplementation.

Assume thatsynchronization is

realized usingwait and continue

functions on asemaphore.

LockingMail






lock;unlock;

In the inheritance-basedimplementation to

add synchronization,all the 14 operationsmust be re-defined!

And plus lock andunlock operations, intotal 16 operations

mustbe defined!

putOriginator(anOrginator);aSemaphore.wait;….

unlock();aSemaphore.continue;….

Implementation ofLockingMail

synchronization


Aggregation-basedimplementation

would be similar.In total 16 operations

must be defined!

As I said before,if you reverse

the order of checking,possibly you have toreimplement all the

operations!

Again, what if I want toreverse the

order of checking?

I think it islogical to check

first the user/systemview, and then

originator/receiver view,

and then more thanonce invocation,

and thensynchronize the

calls!

Implementation ofLockingMail

synchronization


My next extensionis DynamicMail.

OriginatoraDynamicMail

putContent(aText);

putContent(aVideo);

send;

send;

DynamicMail adapts theimplementation of the operation

send based onthe type of the mail data.

I am usinga text protocol

I am usinga video protocol

Example protocols are:text, audio, video, graphics.

DynamicMaildynamic behavior


Here is myinheritance-basedimplementationof the operation

send ofDynamicMail!

DynamicMail:: send if content.type = ‘text’;

then self.textProt(content)

Originator

aDynamicMail

send()

LockingMail

…..

if content.type = ‘audio’;

then self.audioProt(content)

if content.type = ‘video’;

then self.videoProt(content)

if content.type = ‘graphics’;

then self.graphProt(content);

Implementation of DynamicMail

dynamic behavior


1 x redefinition

4 x protocols

Now let’s evaluatethe implementation

of DynamicMailusing inheritance

DynamicMail

sendtextProt(aContent);

audioProt(aContent); videoProt(aContent); graphProt(aContent);

LockingMail

One limitation of myimplementation is theif-then-else structure.I cannot introduce anew protocol without

recompilation.If the data types are fixed,

I could implement theprotocols as visitors

as defined by thevisitor pattern, however.

Implementation ofDynamicMail

Here only the operationsend must be re-defined!

Also 4 new protocolsmust be implemented.

All other operationsare inherited.

Inheritance providestransitive reuse.

dynamic behavior


1 x redefinition

14 x forwarding

4 x protocols

DynamicMail






textProt(aContent); audioProt(aContent); videoProt(aContent); graphProt(aContent);

LockingMail

Implementation ofDynamicMail

Like inheritance, hereonly the operation

send must be re-defined!Also 4 new protocols

must be implemented.Unfortunately, 14

operations must beforwarded to the

part object of classLockingMail!

Now let’s evaluatethe implementation

of DynamicMailin case of

aggregation-basedreuse!

dynamic behavior


Are the compositionproblems always related

to inheritanceor aggregation?

No, certain composition problemsemerge across multi-objects.

Multi-object crosscutting aspectsmonitoring


Adding monitoring

originator

DynamicMail

MailDelivery

Receiver

Monitori o

i o

i o

i o

Monitoring crosscutsmultiple objects

Now assume thatwe want to monitorthe activities in the

system.Now, for every incomingand outgoing message,

a logging codemust be implemented!

monitoring


Adding monitoringThe exact number of

operation implementationsdepends on the number of

operations of these classes.If we assume that EMail hasat least 14 operations, and

all other classes have 5operations each, then

the total number of monitoringcode will be at least 29.

We also define 2 operationsfor enabling and disabling

monitoring for every class. In addition, a monitor classwith a monitor operation

has to be defined.Here, I counted input and

output monitoring as asingle operation.

monitoring


How manyoperations

must be definedto implementthe scenario!

Lets countthe number of

operations in casenew classes areintroduced forevolution using

inheritanceof aggregations

Class Inheritance AggregationEmail 14 op. + 1 class14 op. + 1 classUSViewMail 11 op. + 1 class16 op. + 1 classORViewMail 7 op. + 1 class 16 op. + 1 classWarning2Mail 15 op. + 1 class15 op. + 1 classLockingMail 16 op. + 1 class16 op. + 1 classDynamicMail 5 op. + 1 class 19 op. + 1 classMonitoring 38 op. + 5 class’ 38 op. + 5 classesTotal 106 op.+11 class’ 134 op.+ 11 class’

For inheritance andaggregation based

extensions 106 and 134operations must be defined,respectively. Aggregation

may provide run-timeadaptability, however, aconsiderable number ofcalls must be forwarded.

Of course, inheritance andaggregation based

approaches could becombined, resulting

a number between 106 and 134.

Evaluationevaluation


Not really,the number of

operation definitionswould be more or

less the same.

If we change the orderof class definitions,

say, first Email, thenLockingMail, USViewMail,

etc, would thenumber of operationdefinitions different?

Evaluationevaluation


What is theorigin or these

evolution problems?

I will illustrate you why sometimes, the

current object-orientedlanguages do not

perform well!

Understanding the evolution problemsevaluation


Class Email interfaceputOriginator(anOriginator);

getOriginator returns anOriginator;

putReceiver(aReceiver);

getReceiver returns aReceiver;


getContent returns aContent;

send;

reply;

approve;

isApproved returns Boolean;

putRoute(aRoute);

getRoute returns aRoute;

deliver;

isDelivered returns Boolean;

userView returns Booleanreturn client.category = ‘user’;

systemView returns Booleanreturn client.category = ‘system’;

Not separated concers in USViewMail

Look at the operations ofUSViewMail.

if self.userView then imp.putOriginator(anOriginator) else self.error;

if self.userView then imp.putReceiver(aReceiver) else self.error;

if self.userView then imp.Content(aContent) else self.error;

if self.userView then imp.getContent else self.error;

if self.userView then imp.send else self.error;

if self.userView then imp.reply else self.error;

if self.systemView then imp.approve else self.error;

if self.systemView then imp.putRoute(aRoute) else self.error;

if self.systemView then imp.deliver else self.error;

return imp.getOriginator;

return imp.getReceiver;

return imp.isApproved;

return imp.getRoute;

return imp.isDelivered;

This is code isnecessary for

verifyingthe user view.

This is code isnecessary for

verifyingthe system view.

This is code isnecessary forforwarding!

evaluation








send;

reply;

approve;


putRoute(aRoute);


deliver;




Not separated concerns in EMail

Again look at theoperations of

EMail.

This is code isnecessary forlogging the

calls.The code logging

must be inserted in otherclasses as well.

aMonitor.monitor(‘putOriginator’);

aMonitor.monitor(‘getOriginator’);

aMonitor.monitor(‘putReceiver’);

aMonitor.monitor(‘getReceiver’);

aMonitor.monitor(‘putContent’);

aMonitor.monitor(‘getContent’);

aMonitor.monitor(‘send’);

aMonitor.monitor(‘reply’);

aMonitor.monitor(‘approve’);

aMonitor.monitor(‘isApproved’);

aMonitor.monitor(‘putRoute’);

aMonitor.monitor(‘getRoute’);

aMonitor.monitor(‘deliver’);

aMonitor.monitor(‘isDelivered’);

evaluation


Crosscutting and tangling

This red-colored code,must be repeated in

every monitored class.







send;

reply;

approve;


putRoute(aRoute);


deliver;


















Complexity increases.

Monitor

You cannot easily extendand/or adapt this

tangled code

evaluation


If a concern code isrepeated and

tangled with multipleoperations, then it iscalled: the concern

crosscuts theoperation

implementations!

For example, the multipleviews concern in

USViewMail and ORViewMailis replicated and tangled

with the operationsthat require to enforce

views.

Similarly, history sensitivityand synchronization

concerns in Warning2Mailand LockingMail crosscut

all the operations of Email.

Crosscuttingobject’s methods

evaluation

Monitoring crosscutsall the operations!


Another problem may bethe lack of expression-power

problem.If the adopted languagecannot express certainconcerns in a straight

forward manner,then the lack of expression

power problem may beexperienced!

For example, referring tothe client object by a

server without passingthe client’s identity to

the server cannotbe expressed directlyin most languages!

In our scenario, this problemwas experienced in

defining views.

Lack of expression powerevaluation


Lack of semantic supportis a form of lack

of expression-power.Separating concerns,

although fundamental,may not be sufficient

for achieving thedesired support for

evolution.For example, enforcing

multiple views may requirehigh-level support for

error-handling, the synchronization concern

may demand high-levelsupport for expressingvarious synchronization

mechanisms, etc.

It is generally not sufficientto implement concerns

as separate code blocks.

We may need tohave high-level

language supportfor certain concerns.

Lack of semanticsupport

evaluation


Can you summarizethe composition

problems?The composition problems are:

2) Lack of expression power;

1) Crosscutting;

3) Lack of semantic support;

Understanding the evolution problemsevaluation


Referencesover the scenario

Actually, a similar scenario has been implementedin various object-oriented environments:

• S. de Bruijn, Composable Objects with Multiple Views and Layering, MSc. thesis, Dept. of Computer Science, University of Twente, March 1998.

Do you havereferences?

An impelementation on a CORBA platform can be found here:

• A. Burggraaf, Solving Modelling Problems of CORBA Using Composition Filters, MSc. thesis, Dept. of Computer Science, University of Twente, August 1997.

http://trese.cs.utwente.nl/publications/msc_theses/burggraa.thesis.pdf

http://trese.cs.utwente.nl/publications/msc_theses/debruijn.thesis.pdf

evaluation


There are a number of publications:

see http://trese.cs.utwente.nl/obstacles

• M. Aksit, B. Tekinerdogan, F. Marcelloni and L. Bergmans, Deriving Object-Oriented Frameworks from Domain Knowledge, in Building Application Frameworks: Object-Oriented Foundations of Framework Design, M. Fayad, D. Schmidt, R. Johnson (Eds.), John Wiley & Sons Inc., pp. 169-198, 1999.

• M. Aksit and L. Bergmans, Guidelines for identifying obstacles when composing distributed systems from components, to be published in Software Architectures and Component Technology: The State of the Art in Research and Practice, M. Aksit (Ed.), Kluwer Academic Publishers, January 2001.

• M. Aksit and L. Bergmans, Obstacles in Object-Oriented Software Development, Proceedings OOPSLA '92, ACM SIGPPLAN Notices, Vol. 27, No. 10, pp. 341-358, October 1992.

What aboutthe description

of the problems? References over problems

evaluation


The Advanced Separation of Concerns/Aspect-orientedtechniques can be used to overcome some of the problemspresented in this tutorial.We have developed Composition Filters as a possiblesolution to the obstacles presented in this tutorial. Thedynamic version of the scenario can be implemented usingComposition Filters with only 43 operations instead of 134operations of aggregation-based implementation.

What about thepossible solutions

See our tutorial solving the modeling problems usingcomposition filters.

References over the solution techniques

Related work on AOP techniques can be foundat http://www.parc.xerox.com/csl/projects/aop/groups.shtml

AOP


Crosscuttingin USViewMail

The AOP languagesaim at managing the

tangling code.

if self.userView then imp.<this method>(<these args>) else self.error;

if self.systemView then imp.<this method>(<these args>) else self.error;

Return imp.<this method>;







send;

reply;

approve;


putRoute(aRoute);


deliver;




if self.userView then imp.putOriginator(anOriginator) else self.error;

if self.userView then imp.putReceiver(aReceiver) else self.error;

if self.userView then imp.Content(aContent) else self.error;

if self.userView then imp.getContent else self.error;

if self.userView then imp.send else self.error;

if self.userView then imp.reply else self.error;

if self.systemView then imp.approve else self.error;

if self.systemView then imp.putRoute(aRoute) else self.error;

if self.systemView then imp.deliver else self.error;

return imp.getOriginator;

return imp.getReceiver;

return imp.isApproved;

return imp.getRoute;

return imp.isDelivered;

They provideabstractionsfor aspects.

They provideweaving mechanismsso that tangling code

can be separated.







send;

reply;

approve;


putRoute(aRoute);


deliver;




Aspect weaver

AOP


Crosscuttingin Email for monitoringThis is the

logging aspect.

Imp.monitor(<operation name>);

If weaving isprovided, logging can be

removed from thecode of Email!







send;

reply;

approve;


putRoute(aRoute);


deliver;


















Aspect weaver







send;

reply;

approve;


putRoute(aRoute);


deliver;




AOP


History of AOP languagesOO languages

MOP(1985)

CLOS-MOP

Crosscuttingaspects (1996)

AspectJ(1997)

Scripts (Francez 81)

Reflection(Smith 81)

Sinainterface predicates

(1988)

Composition Filters(1992)

AI (semantic

networks 79)

Composition Filterswith superimposition

(2001)

Law of Demeter(1988)

Adaptiveprogramming

(1992)

AspectJ(2000)

AOP


Are thereworkshops

on this topic?

• Adaptability in Object-Oriented Software Development, ECOOP’96 workshop, Linz, July 1996.

• Composability issues in object orientation, ECOOP’96 workshop, Linz, July 1996.

• Aspect-oriented programming, ECOOP’97 workshop, Yveskila, June 1997.

• Aspect-oriented programming, ECOOP’98 workshop, Brussels, July 1998.

• Aspect-oriented programming, ECOOP’99 workshop, Lisbon, June 1999.

• Multi-Dimensional Separation of Concerns in Software Engineering, ICSE 2000 workshop, Limerick, June 2000.

• First Workshop on Multi-Dimensional Separation of Concerns in Object-oriented Systems, OOPSLA’99 workshop, Denver, November 1999.

• Aspects and Dimensions of Concerns, ECOOP’00 workshop, Sophia Antipolis and Cannes, June, 2000.

• Advanced Separation of Concerns, OOPSLA’00 workshop, Minneapolis, October, 2000.

• Advanced Separation of Concerns in Software Engineering, ICSE’2001 workshop, Toronto, May, 2001.

• Advanced Separation of Concerns, ECOOP’2001 workshop, Budapest, June, 2001.

Workshopsreferences


If you want to have moreinformation, just send an email:

Mehmet Aksit: [email protected] Bergmans: [email protected]

references

More information?

Date post:	17-Jan-2016
Category:	Documents
Upload:	donald-campbell
View:	213 times
Download:	0 times

© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems...

Documents