Aspect-Oriented Software Development (AOSD) Tutorial #8

1. Aspect-Oriented Software Development (AOSD)Tutorial #8 Composition Filters

2. Today: Composition Filters • Filter types • Superimposition of filters • Examples Aspect-Oriented Software Development (236608)

3. Example: Social Security System Document flow: Communicates with clients Creates client’s entry (claim document) in the system Forwards the request to the appropriate handler Evaluates client’s disablement Issues bank orders Aspect-Oriented Software Development (236608)

4. Social Security System – contd. • Main classes in the system: • Document – implemented by Claim Document • Task Processor – implemented by all the handlers Document ClaimDocument //fields //more fields //methods //more methods Aspect-Oriented Software Development (236608)

5. Social Security System – contd. TaskProcessor is implemented by all the handlers Overridden methods: processDocument, forwardDocument Aspect-Oriented Software Development (236608)

6. Implement System Evolution by Composition Filters • Task1: Adding documents protection. In the initial system, any clerk could edit any field in a document. We need to ensure the fields each clerk is able to edit are exactly the fields needed for his task. Solution: add message filters! Aspect-Oriented Software Development (236608)

7. Documents Protection - Restrictions Part of the restrictions are as follows: “Payment” can invoke the functions (= treat the messages): • putApprovedClaim • approvedClaim(): Currency “MedicalCheck” can invoke the functions: • putMedicalCheckData(medCData: DocumentData) • medicalCheckData(): DocumentData The restrictions for the other modules are defined similarly. Aspect-Oriented Software Development (236608)

8. Documents Protection Task Objects on which we work; created together with the filter concernProtectedClaimDocumentbegin filterinterfacedocumentWithViewsbegin internals document: ClaimDocument; externals // no externals defined by this class conditions inactiveRH; inactiveRD; inactiveMC; inactiveP; inactiveOH; methods activeTask(); inputfilters … outputfilters … end filterinterfaceDocumentWithViews; … // implementation in Java end concernProtectedClaimDocument; Objects passed to the filter as parameters Methods used to implement the filters Conditions used to define the filters ( = boolean methods in implementation) Implementation Meaning: “the view … is NOT active” Aspect-Oriented Software Development (236608)

9. Documents Protection Task –contd. Conditions used to define the filters The “Implementation” part: implementation in Java // for example class ProtectedClaimDocument { boolean inactiveRH() { return this.activeTask().class()!=RequestHandler }; boolean inactiveRD() { … }; boolean inactiveMC() { … }; boolean inactiveP() { … }; boolean inactiveOH() { … }; String activeTask() { … }; } end implementation The task currently performed Aspect-Oriented Software Development (236608)

10. Documents Protection – Input Filters • Which filter types do we need? • Error? • Substitution? • Send? • Dispatch? • Wait? • Meta? block unauthorized modifications ✔ ✘ Implement inheritance (from Document) ✘ ✔ ✘ ✘ Aspect-Oriented Software Development (236608)

11. Documents Protection – Input Filters document = internal instance of ClaimDocument inner = implementation object “inheritance”: inh:Dispatch = { inner.* , document.* }; “Error” Try1: viewP :Error = {inactiveP ~> {putApprovedClaim, approvedClaim} }; viewMC:Error = {inactiveMC ~> {putMedicalCheckData,medicalCheckData} }; // etc. for the other views Implement “Error” with the “=>” operator: protection: Error = { PaymentActive => {putApprovedClaim, approvedClaim}, MedicalCheckActive => {putMedicalCheckData, medicalCheckData}, … // etc. for the other views }; what if inactiveP=false? exclusion operator enable operator Aspect-Oriented Software Development (236608)

12. Documents Protection – contd. Order of the input filters = ? • Error(s) • Inheritance Output filters = ? • No output filters needed Aspect-Oriented Software Development (236608)

13. Superimposition • Without superimposition: Each filter applies to one object only => Behavior crosscutting a number of methods within one object • Superimposition: One filter applies to many objects Enables abstraction and (possibly multiple) instantiation Aspect-Oriented Software Development (236608)

14. Superimposition – contd. instantitation filterinterfaces can be superimposed on this concern and on other concerns abstraction Aspect-Oriented Software Development (236608)

15. Superimposition Syntax join point selectors (abstract), define sets of concerns superimposition begin selectors Set1 = {…} Set2 = {…} … filterinterfaces Set1 <- concern1::filterinterface1; Set2 <- concern2::filterinterface2; … concern4::Set4 <- concern3::filterinterface3; end superimposition; For each superimposed filterinterface, define the set of its join-points objects, methods and conditions can be superimposed in the same way name of concern in which it is defined (if in the current concern, then “self” or empty) Aspect-Oriented Software Development (236608)

16. Task2: Adding Logging • Assume a workflow control has been added the system • The goal: monitor the process, detect the bottlenecks and reschedule and/or reallocate the resources, if necessary • Implementation: register all the interactions among objects Aspect-Oriented Software Development (236608)

17. Adding Logging – Implementation Add the class Logger. Main functionality: • loggingEnabled – activate the logging • loggingDisabled – deactivate the logging • log(message) – extract the necessary info Additional functionality – retrieve information from the log Aspect-Oriented Software Development (236608)

18. Logging – Implementation (contd.) concern Logging begin // introduces centralized logger filterinterface notifyLogger begin // this part declares the crosscutting code externals logger : Logging; // *declare* a shared instance of this concern internals logOn : boolean; // created when the filterinterface is imposed methods loggingOn(); // turn logging for this object on logginOff(); // turn logging for this object off log(Message); // declared here for typing purposes only conditions … // to be defined inputfilters … // to be defined outputfilters … //not needed end filterinterface notifyLogger; … end concern Logging; Aspect-Oriented Software Development (236608)

19. Logging – Implementation (contd.) filterinterface logger begin externals //not needed internals //not needed methods log(Message); // various methods to retrieve info. from the log inputfilters disp : Dispatch = { inner.* }; outputfilters //not needed endfilterinterface logger; accept all methods implemented by the object to which the logger is applied Aspect-Oriented Software Development (236608)

20. Logging – Implementation (contd.) filterinterface notifyLogger begin // this part declares the crosscutting code externals logger : Logging; // *declare* a shared instance of this concern internals logOn : boolean; // created when the filterinterface is imposed methods loggingOn(); // turn logging for this object on logginOff(); // turn logging for this object off log(Message); // declared here for typing purposes only conditions LoggingEnabled; inputfilters logMessages : Meta = { LoggingEnabled=>[*]logger.log }; dispLogMethods : Dispatch = { loggingOn, loggingOff }; end filterinterface notifyLogger; is the order correct? if logging is enabled… log every message Aspect-Oriented Software Development (236608)

21. Logging – Implementation (contd.) everything except instances of Logging concern Logging begin … superimposition begin selectors allConcerns = { *!=Logging }; conditions allConcerns <- LoggingEnabled; filterinterfaces allConcerns <- notifyLogger; self <- logger; end superimposition; … end concern Logging; the applicability of Logging should be defined separately for each concern other than Logging Every concern (except for Logging) is crosscut by notifyLogger So that the logger will be able to retrieve info from the log… Aspect-Oriented Software Development (236608)

22. Logging – Implementation (contd.) Where is “fire” of the Meta filter? concern Logging begin … // the only part left: implementation in Java class LoggerClass { boolean LoggingEnabled() { return logOn }; void loggingOn() { logOn:=true; }; void loggingOff() { logOn:=false; }; void log(Message msg) { … }; // get information from message and store } end implementation end concern Logging; “fire” is here… Aspect-Oriented Software Development (236608)

23. HW1 – comments • Each aspect should be defined separately, in a separate class (and, probably, in a separate file)! Modularity is important! • Is this a good comment? “This pointcut does something (reduces the fractions, etc.)” - No! The advice does the action, and not the pointcut. Aspect-Oriented Software Development (236608)

24. Rational Exam (reminder) private void doExam() { while (true) { r1 = randomRational(); r2 = randomRational(); result = r1.add(r2); answer = getAnswer(r1, r2); if (answer == null) break; checkAnswer(answer, result); } } public static void main(String[] args) { RationalExam exam = new RationalExam(); exam.doExam(); } Aspect-Oriented Software Development (236608)

25. HW1 – comments Is this a correct pointcut for Reduction aspect? pointcut createRational(int x, int y): (args(x,y) && call(Rational.new(..)) && !cflow(call(* RationalExam.getAnswer(..)))); How to refine it? For example, define the pointcut to catch the call to the “getAnswer” function from “doExam”, and then reduce the parameters in the advice Catches all the non-user-given fractions creations, and not only the fractions that appear in the questions of the exam! Aspect-Oriented Software Development (236608)