AOP Metrics by ozlerhakan

Master Thesis: Measuring Aspect-Oriented Software In Practice

Abstract. Aspect-oriented programming (AOP) is a way of modularizing a software system by means of new kind of modules called aspects in software development. To this end AOP helps in alleviating crosscutting concerns of system modules by separating into several aspect modules, thereby aiming to improve separation of concerns. On the other hand, aspects can bring unexpected behaviour to a system while attempting to alter the system’s concerns. They can modify the behaviour of the base system without warning. Following to this, such impact can limit to achieve modular reasoning in an aspect-oriented system properly.

Obtaining the valuable data, we try to get an idea of how difficult it is to achieve modular reasoning. In this thesis, we analyse the existing ten AspectJ systems by answering six research questions. These six questions were derived from our general question: "how AspectJ is used in practice?". In order to answer each one of them, we have implemented a metrics suite including both aspect-oriented and object-oriented features using Ekeko. Next to modular reasoning, we also acquire other usefulness about AOP constructs and coupling between classes and aspects. These results can then be used to influence the design of existing or new AOP languages, or to improve existing analysis tools of AOP.

Hierarchy of the research questions

How large is the system?
- Lines of Code (LOC)
- Vocabulary Size (VS)
- Number of Attributes (NOA)
- Number of Methods (NOM)
How often are AOP constructs used compared to OOP features?
- Number of Intertypes (NOI)
- Number of Advice (NOAd)
Which AOP constructs are typically used?
- Inherited Aspects (InA)
- Singleton Aspects (SA)
- Non-Singleton Aspects (nSA)
- Advice-Advanced Pointcut Dependence (AAP)
- Advice-Basic Pointcut Dependence (ABP)
- Number of Around Advice (NOAr)
- Number of Before/After Advice (NOBA)
- Number of After Throwing/Returning Advice (NOTR)
- Number of Call (NOC)
- Number of Execution (NOE)
- Adviceexecution-Advice Dependence (AE)
- Number of Wildcards (NOW)
- Number of non-Wildcards (NOnW)
- Argument size of Args-Advice (AAd)
- Argument size of Args-Advice-args (AAda)
How many types and members of a system are advised by AOP?
- Percentage of Advised Classes (AdC)
- Percentage of non-Advised Classes (nAdC)
- Number of Advised Methods (AdM)
- Number of non-Advised Methods (nAdM)
- Classes and Subclasses (CsC)
- Average of Subclasses of Classes (ScC)
Is there a connection between the amount of coupling in an aspect, and how many shadows it advises?
- Advice-Join Point Shadow Dependence (AJ)
- Number of thisJoinPoint/Static (tJPS)
- Number of Modified Args (MoA)
- Number of Accessed Args (AcA)
- Around Advice - non-Proceed Call Dependence (AnP)
How many dependencies are there between classes and aspects?
- Attribute-Class Dependence (AtC)
- Advice-Class Dependence (AC)
- Intertype-Class Dependence (IC)
- Method-Class Dependence (MC)
- Pointcut-Class Dependence (PC)
- Advice-Method Dependence (AM)
- IntertypeMethod-Method Dependence (IM)
- Method-Method Dependence (MM)
- Pointcut-Method Dependence (PM)

Have a look at an example

One of the questions we examine is: how many aspects extend to an abstract aspect in a given aspect-oriented project?

The Metric representation of the question is: the number of inherited aspects in a given aspect-oriented project.

 (defn NOInheritedAspects [?aspectname ?abstractname]
         (l/fresh [?aspect ?source ?super]
                   (NOAspects ?aspect ?source)
                   (w/aspect-declaredsuper ?aspect ?super)
                   (equals ?aspectname (str "Aspect {"(.getSimpleName ?aspect)"}"))
                   (equals ?abstractname (str "From Abstract Aspect -> "(.getSimpleName ?super)))
                   (succeeds (.isAbstract ?super))))

Selected aspect-oriented systems

HealthWatcher
HyperCast
AJHotDraw
AJHSQLDB
Contract4J5
MobileMedia
iBatis
Telestrada
SpaceWar
- Comes bundled with the AJDT
TetrisAJ

Some charts mentioned in this thesis

All the related charts are available in Thesis Text/diagrams.

The Percentage of Advised Classes against non-Advised Classes AAd vs AAda

Advice-Advanced Pointcut Dependency versus Advice-Basic Pointcut Dependency per System The Average of Advice-Join Point Shadow Dependency per System

How the metrics work

First of all, make sure that you have all the dependencies about the Ekeko plug-in in your Eclipse Luna 4.4 IDE, if not, you first need to download the dependencies:

AST View i.e. org.eclipse.jdt.astview
Counterclockwise

Downloading the dependencies, you are now ready to install the prebuilt Ekeko plug-in:

Go to: Help > Install New Software... in your Eclipse IDE.
Copy and paste this url: http://soft.vub.ac.be/~cderoove/eclipse/ in the Work with text field.
Hit Enter.
Select all plug-ins including Ekeko and GASR in Ekeko-based program Analysis (required), the rest are (optional) and install all of them.
After installing both Ekeko and the Ekeko's AspectJ extension, you are ready to downdload the metrics.
Import the project (i.e. the aopmetrics project) in your Eclipse workspace. Eclipse Luna will automatically detect this project as a Clojure project.
Select an AspectJ project that you want to analyse then, right-click on the project, apply these steps: Configure > Include in Ekeko Queries
The metrics also need soot analyses in order to run properly. To do that, we need to configure the selected AspectJ project once as follows:
- Right-click on the project : Properties > Ekeko properties.
- Click the Select button and now choose the class that contains the main() method of the AspectJ project. (e.g. you can find an example of a main() method in our AJTestMetrics project (MainTST).
  - If your AspectJ project does not have a main() method, just create a new one to set it as an execution point of soot analysis.
- Write the following line into the "Soot arguments:" one-line text box: -no-bodies-for-excluded -src-prec c -f jimple -keep-line-number -app -w -p cg.cha
- Click OK
- Finally, right-click the project > Configure > Enable Ekeko Soot Analyses.
Activate an Ekeko-hosted REPL by doing Ekeko > Start nRepl from the main Eclipse menu. A dialog shows the port on which the nRepl server listens (e.g. nrepl://localhost:51721)
Connect to the Ekeko-hosted REPL: Go to: Window > Connect to REPL to connect to this port (i.e. nrepl://localhost:51721). A Counterclockwise REPL view now opens.
There are 2 steps to run the metrics:
- First, Open the aopmetrics/metrics.clj file and right-click somewhere on the file and choose Clojure > Load file in REPL. After obtaining #'aopmetrics.metrics/AcA in the REPL, follow the second step.
- Second, Open the aopmetrics/core.clj file and right-click somewhere on the file and choose Clojure > Load file in REPL.
  - You will see nil in the REPL which means that everything goes correctly and the metric framework has likewise been loaded in the REPL.
  - After disabling the comment block, you can now run the metrics. For example, if we look at (metrics/VSize), the alias name of our AOPMetrics is metrics that helps in reaching the implemented metrics in a short way rather than typing the totally qualified name (i.e. AOPMetrics). metrics/Vsize simply retrieves the vocabulary size of the project.

Note: The AcA and MoA metrics need different soot arguments to obtain the exact data. Thus, you need to change the current arguments with the following one: -no-bodies-for-excluded -src-prec c -f jimple -keep-line-number -app -w -p jb use-original-names:true -p cg.cha and run again Ekeko Soot Analyses.