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

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

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

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 //fields //methods ClaimDocument //more fields //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 concern ProtectedClaimDocument begin filterinterface documentWithViews begin internals document: ClaimDocument; externals // no externals defined by this class conditions inactiveRH; inactiveRD; inactiveMC; inactiveP; inactiveOH; methods activeTask(); inputfilters … outputfilters … end filterinterface DocumentWithViews; … // implementation in Java end concern ProtectedClaimDocument; Objects on which we work; created together with the filter Objects passed to the filter as parameters Conditions used to define the filters ( = boolean methods in implementation) Methods used to implement the filters Implementation Meaning: “the view … is NOT active”

Aspect-Oriented Software Development (236608) 9 Documents Protection Task –contd. 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 Conditions used to define the filters

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 “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 }; inner = implementation object document = internal instance of ClaimDocument exclusion operator enable operator what if inactiveP=false?

Aspect-Oriented Software Development (236608) 12 Documents Protection – contd. Order of the input filters = ? 1.Error(s) 2.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. abstraction instantitation filterinterfaces can be superimposed on this concern and on other concerns

Aspect-Oriented Software Development (236608) 15 Superimposition Syntax 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 join point selectors (abstract), define sets of concerns name of concern in which it is defined (if in the current concern, then “self” or empty) objects, methods and conditions can be superimposed in the same way

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 end filterinterface 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; if logging is enabled… log every message is the order correc t?

Aspect-Oriented Software Development (236608) 21 Logging – Implementation (contd.) concern Logging begin … superimposition begin selectors allConcerns = { *!=Logging }; conditions allConcerns <- LoggingEnabled; filterinterfaces allConcerns <- notifyLogger; self <- logger; end superimposition; … end concern Logging; everything except instances of 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.) 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; Where is “fire” of the Meta filter? “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!