Aspect-Oriented Software Development (236608)
2
Today: Composition Filters
• Filter types
• Superimposition of filters
• Examples
Aspect-Oriented Software Development (236608)
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
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 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”
Aspect-Oriented Software Development (236608)
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
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 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
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
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;
Aspect-Oriented Software Development (236608)
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
Aspect-Oriented Software Development (236608)
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?
Aspect-Oriented Software Development (236608)
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…
Aspect-Oriented Software Development (236608)
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…
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 – 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!