© 2001 trese group, university of twente trese e-tutorial series 01software evolution problems...
Post on 17-Jan-2016
214 Views
Preview:
TRANSCRIPT
© 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 Netherlandsaksit@cs.utwente.nl; bergmans@cs.utwente.nl
http://trese.cs.utwente.nl
Software evolution problemsin case of inheritance andaggregation based reuse
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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.
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
Table of contents
Introduction Adding monitoring
Adding synchronization
Adding history
Adding multiple views
Basic concern: email
Problems
Aspect-oriented programming
Evaluation
Adding dynamic behavior
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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.
Exampleexample
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
getOriginator getReceiver isApproved getRoute isDelivered
These operations arenot restricted;
user and systemobjects can invokethese operations!
Operations without viewsmultiple views
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
Lets try to reuse class EMailas much as possible.
How would you implementclass USViewMail?
Implementation of USViewMailmultiple views
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
userView return client.category = ‘user’;
view checking
execute
errorelse self.error;
putOriginator(anOriginator)
if self.userView
then imp.putOriginator(anOriginator)
multiple views
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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.
userView return client.category = ‘user’;
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);
getContent;send;reply;
approve;putRoute(aRoute);
delivergetOriginator;getReceiver;
getRoute;isDeliveredisApproved;
The remaining 5operations are inherited!
Implementation of USViewMail
multiple views
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
6 x user views
Let us evaluate the aggregation-basedimplementation.
5 x forwarding
3 x system views
USViewMail
putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);
getContent;send;reply;
approve;putRoute(aRoute);
delivergetOriginator;getReceiver;
getRoute;isDeliveredisApproved;userView;
systemview;
putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);
getContent;send;reply;
approve;putRoute(aRoute);
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
USViewMail
putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);
getContent;send;reply;
approve;putRoute(aRoute);
delivergetOriginator;getReceiver;
getRoute;isDeliveredisApproved;userView;
systemview;
putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);
getContent;send;reply;
approve;putRoute(aRoute);
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
Warning2Mail,
LockingMail, DynamicMail
ORViewMail,
Lets try to reusethe classes as
much as possible.
Evolution scenariomultiple views
& Monitoring
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);
send;reply;
originatorViewreceiverView
USViewMail
Implementation ofORViewMail
multiple views
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
ORViewMail
putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);
getContent;send;reply;
approve;putRoute(aRoute);
delivergetOriginator;getReceiver;
getRoute;isDeliveredisApproved;
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.
Implementation ofORViewMail
multiple views
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
Let me explain inmore detail.
originatorView return client.category = ‘originator’;
else self.error;
ORViewMail:: putOriginator(anOriginator) if self.originatorView
then super.putOriginator(anOriginator)
userView return client.category = ‘user’;
else self.error;
USViewMail:: putOriginator(anOriginator) if self.userView
then super.putOriginator(anOriginator)
OriginatoranORVMail
putOriginator(.)
Email executesputOriginator
Here is myinheritance-basedimplementationof the operationputOriginator of
ORViewMail!
Implementation ofORViewMail
multiple views
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
The aggregationbased
implementationis similar!
originatorView return client.category = ‘originator’;
else self.error;
anORVMail:ORViewMail:: putOriginator(anOriginator) if self.originatorView
then imp.putOriginator(anOriginator)
userView return client.category = ‘user’;
else self.error;
imp:USViewMail:: putOriginator(anOriginator) if self.userView
then imp.putOriginator(anOriginator)
an Email object executesputOriginator
Originator
putOriginator(.)
anORVMail
Implementation ofORViewMail
multiple views
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
ORViewMail
USViewMail
Ok, Here is myinheritance-basedimplementationof the operationputOriginator of
ORViewMail!
originatorView return client.category = ‘originator’;
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
14 x history administration
Let us evaluate the inheritance-basedimplementation.
Warning2Mail
putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);
getContent;send;reply;
approve;putRoute(aRoute);
delivergetOriginator;getReceiver;
getRoute;isDeliveredisApproved;
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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”
locked = falsequeue={ }
“I am now executingsend”
unlock();
locked = falsequeue={ }
LockingMailsynchronization
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
14 x semaphore operations
Let us evaluate the inheritance-basedimplementation.
Assume thatsynchronization is
realized usingwait and continue
functions on asemaphore.
LockingMail
putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);
getContent;send;reply;
approve;putRoute(aRoute);
delivergetOriginator;getReceiver;
getRoute;isDeliveredisApproved;
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
1 x redefinition
14 x forwarding
4 x protocols
DynamicMail
putOriginator(anOriginator);putReceiver(aReceiver);putContent(aContent);
getContent;send;reply;
approve;putRoute(aRoute);
delivergetOriginator;getReceiver;
getRoute;isDeliveredisApproved;
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
Are the compositionproblems always related
to inheritanceor aggregation?
No, certain composition problemsemerge across multi-objects.
Multi-object crosscutting aspectsmonitoring
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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;
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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;
userView returns Booleanreturn client.category = ‘user’;
systemView returns Booleanreturn client.category = ‘system’;
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
Crosscutting and tangling
This red-colored code,must be repeated in
every monitored class.
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;
userView returns Booleanreturn client.category = ‘user’;
systemView returns Booleanreturn client.category = ‘system’;
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’);
Complexity increases.
Monitor
You cannot easily extendand/or adapt this
tangled code
evaluation
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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!
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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>;
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;
userView returns Booleanreturn client.category = ‘user’;
systemView returns Booleanreturn client.category = ‘system’;
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.
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;
userView returns Booleanreturn client.category = ‘user’;
systemView returns Booleanreturn client.category = ‘system’;
Aspect weaver
AOP
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
Crosscuttingin Email for monitoringThis is the
logging aspect.
Imp.monitor(<operation name>);
If weaving isprovided, logging can be
removed from thecode of 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;
userView returns Booleanreturn client.category = ‘user’;
systemView returns Booleanreturn client.category = ‘system’;
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’);
Aspect weaver
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;
userView returns Booleanreturn client.category = ‘user’;
systemView returns Booleanreturn client.category = ‘system’;
AOP
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
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
© 2001 TRESE Group, University of Twente TRESE e-tutorial series 01Software evolution problems
If you want to have moreinformation, just send an email:
Mehmet Aksit: aksit@cs.utwente.nlorLodewijk Bergmans: bergmans@cs.utwente.nl
references
More information?
top related