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 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

22. © 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