2. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Solving the evolution problems using Composition Filters Mehmet Aksit and Lodewijk Bergmans TRESE Group Department of Computer Science P.O. Box 217 7500 AE Enschede, The Netherlands aksit@cs.utwente.nl; bergmans@cs.utwente.nl http://trese.cs.utwente.nl

3. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Copyright statement You are not allowed to use part or whole of the tutorial material for any commercial purpose unless a written permission 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 a reference to our web-site "taken from http://trese.cs.utwente.nl" and always include these two copyright conditions. http://trese.cs.utwente.nl

4. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Table of contents Introduction Dynamic behavior Synchronization History sensitivity Multiple views Evaluation Monitoring

5. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF If you want to know more about the evolution problems, please refer to the e-tutorial 01 http://trese.cs.utwente.nl/courses/e_tutorials/evolution_problems.ppt Introduction to CF Evolution problems

6. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Instead of providing dedicated solutions by modifying class descriptions, Composition Filters offers modular extensions to class abstractions expressed in languages like Java, C++ and Smalltalk. a filter A modular extension a class Filters are modular extensions Introduction to CF

7. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF In case more than one concern is needed, multiple filters can be used. Modular & independent extensions a class filter1 filter2 filter3 filter4 Each filter transforms incoming and/or outgoing messages to/from object. message Filters specifications are independent of each other! Filters are independent extensions introduction to CF

8. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Crosscutting concerns error meta dispatch error meta dispatch error meta dispatch Superimposition blue_guys <- multiple_views error meta dispatch Super imposition Multiple_views introduction to CF Filters are attached to objects (classes) using the superimposition construct. a class

9. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF New filter types can be defined by programmers or may be provided as libraries. However, filter definitions must be carried out carefully. introduction to CF Filters are open-ended

10. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Filters have well-defined semantics. For example we have defined the following filters: ConcernFilter type Pre-post conditionsError Multiple viewsError Dynamic inheritanceDispatch DelegationDispatch Layered architectureMeta History sensitivityMeta + history class ProtocolMeta + protocol class SynchronizationWait Real timeRealTime introduction to CF Well-defined semantics

11. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Filters are expressed using declarative specifications. a filter specification interpreter compiler run-time solutioncompile-time solution Filters can be interpreted, providing run-time solutions, or they may be compiled, providing faster solutions. introduction to CF Declarative specifications

12. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF MonitoringDynamicMailLockingMail I will now implement the evolution scenario using the Composition Filters model. This scenario was presented in: http://trese.cs.utwente.nl/courses/e_tutorials/evolution_problems.ppt Warning2Mail ORViewMail USViewMail EMail Lets try to reuse the classes as much as possible. Evolution scenario multiple views

13. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Assume that USViewMail aggregates Email for reuse. In addition, 2 filters called multipleViews and invoke, and two new operations userView and systemView are defined. USViewMail userView; systemview; EMail putOriginator(anOriginator); putReceiver(aReceiver); putContent(aContent); getContent; send; reply; approve; putRoute(aRoute); deliver; getOriginator; getReceiver; getRoute; isDelivered; isApproved; Implementation of USViewMail using CF’s multiple views Filter: invoke Filter: multipleViews

14. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF USViewMail using CF’s (cont’ed) multiple views This is the specification of the first filter! multipleViews: Error = { userView => {putOriginator, putReceiver, putContent, getContent, send, reply}, systemView => {approve, putRoute, deliver}, True => {getOriginator, getReceiver, isApproved, getRoute, isDelivered} }

15. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF USViewMail using CF’s (cont’ed) multiple views This is how it works: Assume that the received message is putOriginator, and userView is True. multipleViews: Error = { userView => {putOriginator, putReceiver, putContent, getContent, send, reply}, systemView => {approve, putRoute, deliver}, True => {getOriginator, getReceiver, isApproved, getRoute, isDelivered} } putOriginator(anOriginator) Filters are evaluated from left to right. Since the condition userView is True, the message is tried to match the userView specification. userView True match If there is a match, in case of an error filter, the message is passed to the next filter. putOriginator(anOriginator)

16. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF USViewMail using CF’s (cont’ed) multiple views Here is another example. Assume that the received message is approve, and userView is False and systemView is True. multipleViews: Error = { userView => {putOriginator, putReceiver, putContent, getContent, send, reply}, systemView => {approve, putRoute, deliver}, True => {getOriginator, getReceiver, isApproved, getRoute, isDelivered} } approve Since the condition userView is False, the specification of the systemView is matched. The comma here is a Conditional-Or operator. userView False match Since there is a match, the message approve is passed to the next filter. approve systemView True

17. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF USViewMail using CF’s (cont’ed) multiple views Here is the 3rd. example. Assume that the received message is deliver, and userView is True and systemView is False. multipleViews: Error = { userView => {putOriginator, putReceiver, putContent, getContent, send, reply}, systemView => {approve, putRoute, deliver}, True => {getOriginator, getReceiver, isApproved, getRoute, isDelivered} } deliver Since the condition userView is True, the specification of the userView is tried to match. userView True no match Since there is no match, the message is tried to match the following specifications. systemView False no match The message is rejected and error condition is generated! ERROR

18. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF USViewMail using CF’s (cont’ed) multiple views This is the specification of the second filter! Here, mail is an instance of Email. invoke: Dispatch = { True=> inner.*, mail.*};

19. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF USViewMail using CF’s (cont’ed) multiple views Assume that the received message is putOriginator, and the Error filter has accepted the message. putOriginator(anOriginator) Since the condition is True, the message is tried to match the operations of inner and mail. The evaluation is from left to right. no match Here inner represents the operations declared by USViewMail. putOriginator does not match. putOriginator(anOriginator) invoke: Dispatch = { True=> inner.*, mail.*}; True True mail is an instance of Email. putOriginator matches putOriginator of Email and the message is dispatched to mail. match

20. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF 2 x filters 2 x operations USViewMail userView; systemview; EMail putOriginator(anOriginator); putReceiver(aReceiver); putContent(aContent); getContent; send; reply; approve; putRoute(aRoute); deliver; getOriginator; getReceiver; getRoute; isDelivered; isApproved; Evaluation of USViewMail multiple views Filter: invoke Filter: multipleViews In CF based implementation to add 2 views, 2 filters and 2 operations has to be defined!

21. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Assume that ORViewMail aggregates USViewMail for reuse. Here, 3 filters: origView, recView and invoke, and two new operations originatorView and receiverView are defined. ORViewMail originatorView; receiverview; USViewMail Implementation of ORViewMail using CF’s multiple views Filter: invoke Filter:recView Filter: origView

22. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF ORViewMail using CF’s (cont’ed) multiple views This is the specification of these filters. I could use a notation like I used for USViewMail, however, for a change, I specified this time the error filters in a different way. origView: Error= {originatorView => {putOriginator, putReceiver, putContent, send}, True ~> {putOriginator, putReceiver, putContent, send} }; recView: Error= {receiverView => { reply }, True ~> reply }; invoke: Dispatch = { True=> inner.*, usvmail.*};

23. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF ORViewMail using CF’s (cont’ed) multiple views Assume that the received message is reply, and receiverView is True. Since the condition originatorView is false, the message is tried to match True part of the first filter. The operator ~> means, everything except the following operations are accepted. Thus reply is accepted by the first filter. origView: Error= {originatorView => {putOriginator, putReceiver, putContent, send}, True ~> {putOriginator, putReceiver, putContent, send} }; recView: Error= {receiverView => { reply }, True ~> reply }; invoke: Dispatch = { True=> inner.*, usvmail.*}; False reply originatorView accept True receiverView match The second filter accepts reply only if receiverView is True. The third filter dispatches to usvmail object. This is a more open specification.

24. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF 3 x filters 2 x operations ORViewMail userView; systemview; USViewMail Evaluation of ORViewMail multiple views The CF based implementation of ORViewMail requires 3 filters and 2 new operations! Filter: invoke Filter:recView Filter: origView

25. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Assume that Warning2Mail aggregates ORViewMail for reuse. Warning2Mail ORViewMail Implementation of Warning2Mail using CF’s history sensitivity Filter: invoke Filter: messageReify Counter In addition, 2 filters: messageReify and invoke, and a new class called Counter is defined. Counter has an operation called count. count

26. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Warning2Mail using CF’s (cont’ed) Here is the specification of these filters. The first filter is a Meta filter and used for reasoning about messages. The second filter is used for execution. messageReify: Meta= { userView=> [*] count.input }; invoke: Dispatch = { True=> inner.*, orvmail.*}; history sensitivity

27. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Warning2Mail using CF’s (cont’ed) Assume that the received message is send, and userView is True. Since the condition is true, the message is tried to match the first filter. The [*] means that every message matches. send In the Meta filter, this means the message is reified and passed as an argument of the message count.input. Here. count is an instance of class Counter, which has operation input. messageReify: Meta= { userView=> [*] count.input }; invoke: Dispatch = { True=> inner.*, orvmail.*}; userView True count.input match count.input(originalMessage) count: Counter input history sensitivity

28. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF if selector == lastCall then self.error(‘warning the same operation invoked twice”); lastCall = selector; aMessage.fire; selector = aMessage.selector; Warning2Mail using CF’s (cont’ed) messageReify: Meta= { userView=> [*] count.input }; invoke: Dispatch = { True=> inner.*, orvmail.*}; input(aMassage); if selector == lastCall lastCall = selector; aMessage.fire; count.input (originalMessage) The operation input reads the selector of the call, which is send in this case. If this is the same as lastCall, error is generated. Assume the last call was putOriginator. lastCall is set to the selector of the message. Then, message is fired, which means, message is set back to its original form, and passed to invoke filter. The message is then executed. lastCall= putOriginator selector = aMessage.selector; lastCall= send False history sensitivity

29. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Warning2Mail (cont’ed) send messageReify: Meta= { userView=> [*] count.input }; invoke: Dispatch = { True=> inner.*, orvmail.*}; count.input (originalMessage) Assume that send is received again! lastCall= send userView True count.input match warning the same operation invoked twice if selector == lastCall then self.error(‘warning the same operation invoked twice”); lastCall = selector; aMessage.fire; selector = aMessage.selector; input(aMassage); if selector == lastCall then self.error(‘warning the same operation invoked twice”); selector = aMessage.selector; True history sensitivity

30. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF 2 x filters 2 x classes + 1 operation Evaluation of Warning2Mail The CF based implementation of Warning2Mail requires 2 filters, a new class and an operation! history sensitivity Warning2Mail ORViewMail Filter: invoke Filter: messageReify Counter count

31. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Assume that LockingMail aggregates Warning2Mail for reuse. Here, 2 filters: sync and invoke and two new operations lock, and unLock are defined. LockingMail lock; unLock; Warning2Mail Implementation of LockingMail using CF’s synchronization Filter: invoke Filter: sync

32. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF LockingMail using CF’s (cont’ed) This is the specification of the filters. Here, Wait filter is used for synchronization purposes. sync: Wait= { locked=>unlocked, not.locked=> * }; invoke: Dispatch = { True=> inner.*, w2mail.*}; synchronization

33. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF LockingMail using CF’s (cont’ed) sync: Wait= { locked=>unlocked, not.locked=> * }; invoke: Dispatch = { True=> inner.*, w2mail.*}; synchronization Assume that the received message is lock, and locked is False. Since not.locked is true, the message is tried to match the second part of the filter and it matches “*”. lock If there is a match in the Wait filter, the message is passed to the next filter, otherwise the message is queued until it can match the filter. The message lock matches inner.* and it is dispatched to lock of LockingMail. The condition locked is set to True. locked False match not.locked True lock

34. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF LockingMail using CF’s (cont’ed) sync: Wait= { locked=>unlocked, not.locked=> * }; invoke: Dispatch = { True=> inner.*, w2mail.*}; synchronization Assume that the received message is putOriginator, and locked is True. Since locked is true, the message is tried to match the first part of the filter and it does not match. putOriginator If there is no match in the Wait filter, the message is queued until it can match the filter. locked True no match not.locked False message queue putOriginator

35. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF LockingMail using CF’s (cont’ed) sync: Wait= { locked=>unlocked, not.locked=> * }; invoke: Dispatch = { True=> inner.*, w2mail.*}; synchronization Assume that unlocked is received, and locked is True. Since locked is true, the message is tried to match the first part of the filter and it matches. unlock locked True match not.locked False message queue putOriginator If there is a match in the Wait filter, the message is passed to the next filter, otherwise the message is queued until it can match the filter. The message unlock matches inner.* and it is dispatched to unlock of LockingMail. The condition locked is set to False. unlock putOriginator putOriginator putOriginator is then removed from the queue and dispatched to w2Mail. False locked True not.locked putOriginator

36. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF 2 x filters 2 x operations Evaluation of LockingMail The CF based implementation of LockingMail requires 2 filters and 2 operations. LockingMail lock; unLock; Warning2Mail Filter: invoke Filter: sync synchronization

37. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Assume that DynamicMail aggregates LockingMail for reuse. Class Inspector is used for checking the document type. Implementation of DynamicMail using CF’s dynamic behavior Filter: dynamicDispatch In addition, 2 filters called messageReify and dynamicDispatch and four new send protocols are defined. DynamicMail textProt(aContent); audioProt(aContent) videoProt(aContent); graphProt(aContent); Filter: messageReify LockingMail Inspector inspect

38. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF DynamicMail using CF’s (cont’ed) Here is the specification of the these filters. dynamic behavior dynamicDispatch: Dispatch = { text=> [send] textProt, audio=> [send] audioProt, video=> [send] videoProt, graphics=> graphProt, True ~> send}; messageReify: Meta= { True=> [putDocument] inspectDoc.inspect};

39. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF dynamicDispatch: Dispatch = { text=> [send] textProt, audio=> [send] audioProt, video=> [send] videoProt, graphics=> graphProt, True ~> send}; messageReify: Meta= { True=> [putDocument] inspectDoc.inspect}; DynamicMail using CF’s (cont’ed) Assume that the received message is putDocument. putDocument matches the first filter and it is reified and passes to object inspectDoc. match dynamic behavior putDocument(aText) inspectDoc.inspect insteptDoc: Inspector Inspect(aMessage) putDocument test the document type and fire The message than passes the next filter. putDocument Here text is true, but only matches send. The last element accepts everything but send. So it dispatches through the last filter element. everything accept send

40. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF dynamicDispatch: Dispatch = { text=> [send] textProt, audio=> [send] audioProt, video=> [send] videoProt, graphics=> graphProt, True ~> send}; messageReify: Meta= { True=> [putDocument] inspectDoc.inspect}; DynamicMail using CF’s (cont’ed) Assume that the received message is send. no match dynamic behavior send text textProt Here text is true, and only matches send. The message is replaced by textProt and dispatches. True It does not match the meta filter, meta filter passes then to the next filter. send send match textProt replace

41. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF 2 x filters 2 x classes + 5 operations Evaluation of DynamicMail The CF based implementation of DynamicMail requires 2 filters, a new class and a 5 new operations dynamic behavior Filter: dynamicDispatch DynamicMail textProt(aContent); audioProt(aContent) videoProt(aContent); graphProt(aContent); Filter: messageReify LockingMail Inspector inspect

42. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Adding monitoring Monitor Now I will explain how multiple object crosscutting aspects can be expressed using Composition Filters! monitoring originator DynamicMail MailDelivery Receiver io io io io

43. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Expressing the monitoring concern Here is the specification of the filters that have to be inserted in all the objects accept the monitoring object. logMessages: Meta= {loggingEnabled=> [*] logger.log }; disLogMethods: Dispatch = { True=> logginOn, loggingOff}; monitoring

44. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Specification of the crosscutting concerns monitoring Concerns in the Composition Filters model are declared as so-called concerns. concern logging begin end concern logging; Filter interface declaration is used to declare one or more filter sets. filterinterface notifyLogger begin end filterinterface notifyLogger; …….. Weaving filtersets into one or more objects are specified using the superimposition declaration. superimposition begin end superimposition; If necessary concern specific implementations are specified here as well. Implementation in Java end implementation;

45. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Specification of filterinterface monitoring Filters are specified here. First the objects used in the concern must be declared. filterinterface notifyLogger begin Objects that are declared as externals represent shared objects of this concern. Objects that are declared as internals are created when this concern is superimposed. externals logger: Monitor; internals logon: boolean;

46. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Specification of filterinterface (cont’ed) monitoring Methods that are used in filters are declared as well. filterinterface notifyLogger begin externals logger: Monitor; internals logon: boolean; filterinterface notifyLogger begin externals logger: Monitor; internals logon: boolean; filterinterface notifyLogger begin externals logger: Monitor; internals logon: boolean; methods loggingOn(); logginOff(); log(Message);

47. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Specification of filterinterface (cont’ed) monitoring Conditions that are used in filters must be declared too. filterinterface notifyLogger begin externals logger: Monitor; internals logon: boolean; methods loggingOn(); logginOff(); log(Message); Then filters are declared. filterinterface notifyLogger begin externals logger: Monitor; internals logon: boolean; methods loggingOn(); logginOff(); log(Message); conditions loggingEnabled; filterinterface notifyLogger begin externals logger: Monitor; internals logon: boolean; methods loggingOn(); logginOff(); log(Message); conditions loggingEnabled; inputfilters logMessages: Meta= {loggingEnabled=> [*] logger.log }; disLogMethods: Dispatch = { True=> logginOn, loggingOff}; end filterinterface notifyLogger;

48. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF Specification of superimposition monitoring Here, first jointpoints are declared. All objects except the instances of class Logging are declared as allselectors. superimposition begin selectors allselectors = { *!= Logging}; conditions allselectors <- loggingEnabled; Then conditions and/or filters are superimposed onto the jointpoints. filterinterfaces allConcerns <- notifyLogger; end superimposition;

49. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF For inheritance and aggregation based implementations 106 and 134 operations had to be defined, respectively. The Composition Filters model requires only 29 operations and 14 filter declarations. Evaluation of CF’s evaluation ClassInheritanceAggregation Composition Filters Model Email14 op. + 1 class14 op. + 1 class14 op. + 1 class USViewMail11 op. + 1 class16 op. + 1 class 2 op. + 2 filters + 1 class ORViewMail 7 op.+ 1 class16 op. + 1 class 2 op. + 3 filters + 1 class Warning2Mail15 op. + 1 class15 op. + 1 class 1 op. + 2 filters + 2 class’ LockingMail16 op. + 1 class16 op. + 1 class 2 op. + 2 filters + 1 class DynamicMail 5 op.+ 1 class19 op. + 1 class 5 op. + 2 filters + 2 class’ Monitoring38 op. + 5 classes 38 op. + 5 classes 3 op. + 2 filters + 5 class’ Total106 op.+ 11 class’134 op. + 11 class’29 op. + 14 filters + 12 class’

50. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF An analogy to Composition Filters is presented as an e-tutorial: http://trese.cs.utwente.nl/courses/e_tutorials/analogy_cf.ppthttp://trese.cs.utwente.nl/courses/e_tutorials/analogy_cf.ppt. If you want to read more about Composition Filters, please refer to: http://trese.cs.utwente.nl/composition_filters/ References evaluation

51. © 2001 TRESE Group, University of Twente TRESE e-tutorial series 02Software the evolution problems using CF These are the characteristics of the Composition-Filters model. Conclusions Can express crosscutting concerns per object or multiple objects; Modular extensions; Independent extensions; Open-ended solutions; Well-defined semantics; Switching between run-time or compile-time solutions. evaluation