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

Aspect-Oriented Software Development (AOSD)

Tutorial #8

Composition Filters

Aspect-Oriented Software Development (236608)

2

Today: Composition Filters

• Filter types

• Superimposition of filters

• Examples


3

Example: Social Security SystemDocument

flow:Creates client’s entry (claim document) in

the system

Forwards the request to the appropriate

handlerEvaluates client’s

disablement

Issues bank orders

Communicates with clients


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


5

Social Security System – contd.TaskProcessor is implemented by all the handlers

Overridden methods: processDocument, forwardDocument


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!


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.


8

Documents Protection Taskconcern ProtectedClaimDocument begin

filterinterface documentWithViews begininternals

document: ClaimDocument;externals

// no externals defined by this classconditions

inactiveRH; inactiveRD; inactiveMC; inactiveP; inactiveOH;

methodsactiveTask();

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”


9

Documents Protection Task –contd.The “Implementation” part:

implementation in Java // for exampleclass 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


10

Documents Protection – Input Filters

• Which filter types do we need?– Error? – Substitution?– Send?– Dispatch?– Wait?– Meta?

✔

block unauthorized modifications

✘

✘

✘

✘

✔

Implement inheritance (from

Document)


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?


12

Documents Protection – contd.

Order of the input filters = ?

1. Error(s)

2. Inheritance

Output filters = ?

• No output filters needed


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


14

Superimposition – contd.

abstraction

instantitation

filterinterfaces can be superimposed on this concern and on

other concerns


15

Superimposition Syntaxsuperimposition begin

selectorsSet1 = {…}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


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


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


18

Logging – Implementation (contd.)concern Logging begin // introduces centralized logger

filterinterface notifyLogger begin // this part declares the crosscutting code

externalslogger : Logging; // *declare* a shared instance of this

concerninternals

logOn : boolean; // created when the filterinterface is imposed

methodsloggingOn(); // turn logging for this object onlogginOff(); // turn logging for this object offlog(Message); // declared here for typing purposes only

conditions… // to be defined

inputfilters… // to be defined

outputfilters… //not needed

end filterinterface notifyLogger;…end concern Logging;


19

Logging – Implementation (contd.)filterinterface logger begin

externals//not neededinternals//not neededmethods

log(Message);// various methods to retrieve info. from the

loginputfilters

disp : Dispatch = { inner.* };outputfilters

//not neededend filterinterface logger;

accept all methods implemented by the object to which the logger is applied


20

Logging – Implementation (contd.)filterinterface notifyLogger begin // this part declares the crosscutting

codeexternals

logger : Logging; // *declare* a shared instance of this concern

internalslogOn : boolean; // created when the filterinterface is

imposedmethods

loggingOn(); // turn logging for this object onlogginOff(); // turn logging for this object offlog(Message); // declared here for typing purposes only

conditionsLoggingEnabled;

inputfilterslogMessages :

Meta = { LoggingEnabled=>[*]logger.log };dispLogMethods :

Dispatch = { loggingOn, loggingOff };end filterinterface notifyLogger;

if logging is enabled…

log every message

is the order correc

t?


21

Logging – Implementation (contd.)concern Logging begin

…superimposition begin

selectorsallConcerns = { *!=Logging };

conditionsallConcerns <- LoggingEnabled;

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


22

Logging – Implementation (contd.)concern Logging begin

…// the only part left:

implementation in Javaclass 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…


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.


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();

}


25

HW1 – commentsIs 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!