AN EMPIRICAL ASSESSMENT OF THE IMPACT OF

ASPECT-ORIENTED PROGRAMMING ON SOFTWARE

MODULARITY

Adam Przybylek

Department of Business Informatics, University of Gdansk, Piaskowa 9, 81-824, Sopot, Poland

Keywords: Aspect-oriented programming, AOP, Separation of concerns, Modular programming.

Abstract: The term “crosscutting concern” describes a piece of system that cannot be cleanly modularized because of

the limited abstractions offered by the traditional programming paradigms. Symptoms of implementing

crosscutting concerns in the languages like C, C# or Java are “code scattering” and “code tangling” that

both degrade software modularity. Aspect-oriented programming (AOP) was proposed as a new paradigm

to overcome these problems. Although it is known that AOP allows programmers to separate crosscutting

concerns, the impact of AOP on software modularity is not yet well investigated. This paper reports a

quantitative study comparing OO and AO implementations with respect to modularity.

1 INTRODUCTION

A software system can be seen as a set of modules.

Each module implements a concern, or a part of a

concern. A concern is a specific requirement or an

interest which pertains to the system’s development.

Kiczales et al. (Kiczales et al., 1997) found that

the abstractions offered by the traditional

programming paradigms (e.g. structured

programming, OOP, functional programming) are

insufficient to express some kind of concerns in a

modular way. Concerns like logging, persistence,

concurrency control, or failure recovery tend to be

scattered and tangled throughout the system

modules, what adversely affect software modularity.

These concerns are known as crosscutting concerns

because they cross-cut the system’s basic

functionality (Przybylek , 2007).

Efforts to deal with crosscutting concerns have

resulted in aspect-oriented programming (AOP).

AOP brings new abstraction such as an aspect, a

joinpoint, a pointcut, an advice, an introduction, and

a parent declaration (Kiczales et al., 2001).

An aspect is a module that encapsulates the

behaviour and structure of a crosscutting concern. It

can, like a class, realize interfaces, extend classes

and declare attributes and operations. In addition, it

can extend other aspects and declare advices,

pointcuts, introductions and parent declarations.

A joinpoint is an identifiable location in the

program flow where the implementation of a

crosscutting concern can be plugged in. Typical

examples of joinpoints include a throw of an

exception, a call to a method and an object

instantiation.

A pointcut is a language construct designed to

specify a set of join-points and obtain the context

(e.g. the target object and the operation arguments)

surrounding the join-points as well.

An advice is a method-like construct used to

define an additional behaviour that has to be inserted

at all joinpoint picked out by the associated pointcut.

The body of an advice is the implementation of a

crosscutting functionality. The advice is able to

access values in the execution context of the

pointcut. Depending on the type of advice, whether

“before”, “after” or “around,” the body of an advice

is executed before, after or in place of the selected

joinpoints. An around advice may cancel the

captured call, may wrap it or may execute it with the

changed context (Przybylek , 2007).

An introduction is used to crosscut the static-type

structure of a given class. It allows a programmer to

add attributes and methods to the class without

having to modify it explicitly. The power of

introduction comes from the introduction being able

to add methods to the interface.

A parent declaration may change the class's

super-class or add implemented interfaces by

139

Przybylek A. (2010).

AN EMPIRICAL ASSESSMENT OF THE IMPACT OF ASPECT-ORIENTED PROGRAMMING ON SOFTWARE MODULARITY.

In Proceedings of the Fifth International Conference on Evaluation of Novel Approaches to Software Engineering, pages 139-148

DOI: 10.5220/0003000801390148

 SciTePress

defining an extends/implements relationship.

2 MOTIVATIONS AND GOALS

It is often taken as a given that AOP improves

modularity (Kiczales et al., 2001, Lesiecki, 2002,

Munoz et al., 2008, Soares, 2004, Guyomarc'h and

Guéhéneuc, 2005). However, there is no empirical

evidence to support this assumption. The aim of this

research is to perform a metrics-based comparison

among AO and OO software with respect to

modularity.

To date, there has been relatively little work in

the area of developing methodologies for assessing

the modularity of AO systems and for providing a

means of comparison between AO systems and their

OO equivalents (Tsang et al., 2004). To support such

comparison we propose an approach based on

coupling and cohesion.

In addition, the advent of a new paradigm

requires defining new metrics to measure software

quality. Ceccato & Tonella (Ceccato and Tonella,

2004) and Sant’Anna et al. (Sant’Anna et al., 2003)

refined the Chidamber & Kemerer metrics suite

(Chidamber and Kemerer, 1994) regarding the

effects of AOP, but they took into account only a

subset of the dependencies that exist in AO systems.

Hence, the coupling measured with their metrics is

underestimated. We intend to revise the coupling

metrics introduced by Ceccato & Tonella (Ceccato

and Tonella, 2004) to support a fair comparison

between OO and AO implementations.

3 RATIONALE FOR THE STUDY

The effect of a new paradigm on software

modularity can be evaluated through empirical

studies. This section performs a quantitative

assessment of Java and AspectJ implementations for

the 23 GoF design patterns. As several design

patterns involve crosscutting concerns (Hannemann

and Kiczales, 2002), their implementations are good

candidates for subjects of the study. Prior studies

(Hannemann and Kiczales, 2002, Garcia et al., 2005)

have shown that the AO implementations separate

some concerns that are tangled and scattered in the

OO decomposition counterpart. Hannemann &

Kiczales report (Hannemann and Kiczales, 2002)

that “AspectJ implementations of the GoF design

patterns show modularity improvements in 17 of 23

cases”. However, these modularity improvements

“are manifested in terms of better code locality,

reusability, composability, and (un)pluggability”.

Moreover, much of their assessment is based on

intuition and gut-feelings, rather than empirical

support.

In this paper, the implementations are compared

with regard to coupling and cohesion. This pair of

attributes was firstly suggested to measure software

modularity by Yourdon & Constantine (Yourdon

and Constantine, 1979) as part of their structured

design methodology and then advocated by other

software engineers (Booch, 1994, Meyer, 1989,

Mancoridis et al., 1998). Also, several empirical

studies (Briand et al., 1999, Briand et al., 2001, Hitz

and Montazeri, 1995, Ponnambalam, 1997) have

found that improvements in coupling and cohesion

are linked to improved modularity.

4 MODULARITY METRICS

Despite cohesion and coupling being concepts in

software design for almost 50 years, we still don’t

have widely-accepted metrics for them. However the

most well-known and widely used for OO

assessment are CBO (Coupling Between Object

classes) and LCOM (Lack of Cohesion in Methods),

defined by Chidamber & Kemerer in their metrics

suite (Chidamber and Kemerer, 1994). CBO is a

count of the number of other modules to which a

module is coupled. Two classes are coupled when

methods declared in one class use methods or

instance variables of the other class Chidamber and

Kemerer, 1994). LCOM is the degree to which

methods within a module are related to one another.

It is measured as the number of pairs of methods

working on different attributes minus pairs of

methods working on at least one shared attribute

(zero if negative). Lack of cohesion implies a

module should probably be split into two or more

sub-modules. CBO and LCOM complement each

other, and because of their dual nature (Hitz and

Montazeri, 1995), they are useful only when

analyzed together.

Since AOP provides new programming

constructs, existing OO measures cannot be directly

applied to AO software. Ceccato & Tonella (Ceccato

and Tonella, 2004) and Sant’Anna et al. (Sant’Anna

et al., 2003) generalized the CK metrics suite to be

applied in a paradigm-independent way, supporting

the generation of comparable results between OO

and AO solutions. The general suggestion is to treat

advices as methods and to consider introductions as

members of the aspect that defines them. Although

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

140

this suggestion is enough to adapt LCOM, the

adjustment of CBO requires further explanation.

Ceccato & Tonella defined the following metrics to

measure different kinds of coupling (Ceccato and

Tonella, 2004):

– CMC (Coupling on Method Call) is a number of

modules declaring methods that are possibly

called by a given module;

– CFA (Coupling on Field Access) is a number of

modules declaring fields that are accessed by a

given module;

– CAE (Coupling on Advice Execution) is a

number of aspects containing advices possibly

triggered by the execution of operations in a

given module;

– CIM (Coupling on Intercepted Modules) is a

number of modules explicitly named in the

pointcuts belonging to a given aspect;

– CDA (Crosscutting Degree of an Aspect) is a

number of modules affected by the pointcuts and

by the introductions in a given aspect.

Nevertheless, to make the coupling comparable

between the two paradigms, an AO counterpart to

the CBO metric must be defined. For this purpose,

we extrapolate the original CK definition according

to the question that underlies coupling: „How much

of one module must be known in order to understand

another module?” (Yourdon and Constantine, 1979).

Our CBO metric considers a module M to be

coupled to N if:

– M accesses attributes of N (A);

– M calls methods of N (M);

– M potentially captures messages to N (C);

– messages to M are potentially captured by N

(C_by);

– M declares an inter-type declaration for N (I);

– M is affected by an inter-type declaration

declared in N (I_by);

– M uses pointcuts of N, excluding the case where

N is an ancestor of M (P).

This metric gives a view of the overall effort needed

to understand the module. It should be noted that the

dependencies C_by and I_by are implicit. A

dependency is implicit when it can be implied from

the source code though is not directly expressed.

Such kind of dependency makes maintenance

impossible without a tool that warns about

extensions to a certain piece of code (Kästner et al.,

2007).

The coupling metric that seems to be similar to

ours is the one of Sant’Anna et al. (Sant’Anna et al.,

2003). Their metric is broader than the original CBO

in the sense that it additionally counts modules

declared in formal parameters, return types, throws

declarations and local variables. However, it is not

complete, since it does take into account neither the

implicit dependencies, nor the dependency that

occurs when an advice refers to a pointcut defined in

other, non-ancestor module.

5 STUDY SETTING

This study uses implementations of the GoF design

patterns made freely available

(http://hannemann.pbworks.com/Design-Patterns) by

Hannemann & Kiczales. For each pattern they

created a small example that makes use of the

pattern, and implemented the example in both Java

and AspectJ. The AspectJ implementations are

considered as „one of the nearest things to examples

of good AOP style and design” (Monteiro and

Fernandes, 2005). The Java implementations

correspond to the sample C++ implementations in

the GoF book.

In the measurement process, the data was

gathered by the AOPmetrics tool (Stochmialek,

2005). To the best of our knowledge AOPmetrics is

the sole tool to compute coupling metrics for AO

systems. This tool implements the metric suite

proposed by Ceccato & Tonella (Ceccato and

Tonella, 2004). Although several researchers have

used AOPmetrics (Hoffman and Eugster, 2007),

(Madeyski and Szala, 2007), they are not aware of

its bugs. First of all, the implementation of CDA

metric does not count modules coupled by pointcuts.

A relationship between pointcut and the matched

modules is typed by

org.aspectj.weaver.AsmRelationshipProvider and

marked by the MATCHES_DECLARE constant.

The reverse relationship is marked by

MATCHED_BY. However, all relationships

counted by the code-walker in AOPmetrics are typed

by org.aspectj.asm.IRelationship, which does not

include any equivalent neither to

MATCHES_DECLARE nor to MATCHED_BY.

Secondly, the values displayed as CDA should be

displayed as CAE and vice versa. To fix this bug it

is enough to swap the lines 107 and 109 in

AspectualAffectedAndEffectedCalculator.java. We

extended AOPmetrics to support the CBO metric as

defined in the previous Section except capturing the

coupling introduced by pointcuts (the extended

version is available at:

http://przybylek.wzr.pl/AOP/). This is due to the

inherent nature of the implementation as mentioned

above. Hence, we manually revised the CBO values.

AN EMPIRICAL ASSESSMENT OF THE IMPACT OF ASPECT-ORIENTED PROGRAMMING ON SOFTWARE

MODULARITY

141

Table 1: Modularity metrics computed as arithmetic means.

6 RESULTS

The CBO and LCOM (LCO in AOPmetrics) values

were collected for each of the 128 modules across

the OO implementations and 179 modules across the

AO implementations. Table 1 presents the mean

values of the metrics, over all modules per pattern.

The lower numbers are better. The sixth and seventh

column indicates the superior implementation with

regard to the CBO and LCOM metric, respectively.

The last column indicates the winning

implementation. An implementation is winning if it

is better in at least one metric and not worse in the

other.

According to the last column, the patterns can be

classified into two groups. Group 1 represents 15

patterns at which the OO implementations are better.

All 8 remaining patterns belong to the second group.

In this group, each implementation is superior with

regard to one metric but inferior with regard to the

other (except Adapter, which has the same metrics

for both implementations). To our surprise, there

was no pattern whose AO implementations exhibits

better modularity.

The linear Pearson's correlation between CBO

and LCOM on a class-by-class level is weak. It

amounts to -0,04 for the OO implementations and

0,07 for the AO implementations. It means that the

analyzed metrics do not capture redundant

information.

The problem with the arithmetic mean is that

each of the modules contributes equally to the final

result. Intuitively, modules which are more complex

should contribute more. In addition, LCOM is not

normalized, which means that the cohesion measures

of different modules (as they all have different

numbers of methods and attributes) should not be

compared. Thus, the weighted arithmetic mean is

also calculated. The individual CBO and LCOM

values are weighted by the number of methods

defined in the module, plus one. Table 2 presents the

averages calculated in this way. As it turns out, no

pattern has changed its group. The conclusion is

that, the claim that AOP makes software more

modular is not true.

7 DEEPER INSIGHT INTO

MODULARITY

An established technique for analysing the

dependencies among the modules of a system is

Dependency Structure Matrix (DSM). A DSM is a

square matrix in which the columns and rows are

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

142

Table 2: Modularity metrics computed as weighted arithmetic means.

labelled with modules and a non-empty cell models

that the module on the row depends on the module

on the column. The type of dependency is

represented by the value of the cell (the shortcuts are

introduced in Section 4). The CBO metric for a

module can be calculated from a DSM by counting

non-empty cells in the row. To provide complex

insight into modularity, LCOM for each module is

also presented. The differences between modularity

in the OO and AO implementations are shown on

the Observer pattern. Figure 1 shows the

dependency matrixes for this pattern.

The participants in the Observer pattern are

subjects and observers. The subject is a data

structure which changes over time (such as a point),

and the observer (a screen) is an object whose own

invariants depend on the state of the subject. The

intention of the Observer pattern is to define a one-

to-many dependency between a subject and multiple

observers, so that when the subject changes its state,

all its observers are notified (Hannemann and

Kiczales, 2002).

In the OO implementation, the business logic and

the pattern context are tangled within the participant

classes. As a result, Point and Screen have a poor

cohesion. Moreover, code for implementing the

pattern is spread across all participants. In the AO

implementation, all code pertaining to the

relationship between observers and subjects is

moved into aspects. Hence, the participant classes

are entirely free of the pattern context, and as a

consequence they are much more cohesive. In the

OO version, a point directly informs its observers by

sending a message to them. In the AO version, even

though Point does not have any reference to its

observers, the coupling has not disappeared. The

coupling has changed its form from explicit method

call to implicit join-points matching. Whenever a

point changes its state, the relevant advice is

triggered and the observers are notified.

Since not all the dependencies between the modules

are explicit, an AO programmer has to perform more

efforts to get a mental model of the source code.

8 THREATS TO VALIDITY

There are a number of limitations of this study that

are worth stating. Firstly, we could be criticised for

narrowing the software modularity to cohesion and

coupling. Although cohesion and coupling are

considered as main factors related to the goodness of

modularization (Booch, 1994, Meyer, 1989, Briand

et al., 1999, Briand et al., 2001, Hitz and Montazeri,

1995, Ponnambalam, 1997) other factors like

obviousness, information hiding, and separation of

AN EMPIRICAL ASSESSMENT OF THE IMPACT OF ASPECT-ORIENTED PROGRAMMING ON SOFTWARE

MODULARITY

143

Figure 1: DSMs for the Observer pattern.

concerns are also notable. However any reasonable

model to estimate modularity has never been

proposed and we do not make an effort to build ours.

Instead, we assumed restrictive criteria to decide

whether implementation in a given paradigm can be

considered more modular: it must be better in at

least one metric and not worse in the other.

Secondly, we could be criticised for applying

metrics that are theoretically flawed. Briand et al.

demonstrate (Briand et al., 1998) that LCOM is

neither normalized nor monotonic. Normalization is

intended to allow for comparison between modules

of different size. To avoid this anomaly we weighted

LCOM by the number of methods. Monotonicity

states that adding a method which shares an attribute

with any other method of the same module, must not

increase LCOM. If we drop the very rare case where

the methods of a module do not reference any of the

attributes, the monotonicity anomaly disappears. The

other problem with LCOM is that it does not

differentiate modules well (Basili et al., 1996). This

is partly due to the fact that LCOM is set to zero

whenever there are more pairs of methods which use

an attribute in common than pairs of methods which

do not (Briand et al., 1998). In addition, the presence

of access methods artificially decreases this metric.

Access methods typically reference only one

attribute, namely the one they provide access to,

therefore they increase the number of pairs of

methods in the class that do not use attributes in

common (Briand et al., 1998). The CBO metric also

indicates inherent weakness. Briand et al. illustrate

(Briand et al., 1999) that merging two unconnected

modules may affect the overall coupling.

Nevertheless, CBO as well as LCOM are widely

applied (even at NASA Goddard Space Flight

Center) and have been validated in many empirical

studies (Basili et al., 1996, Briand et al., 1999), and

(Briand et al., 1999).

Thirdly, the applied metrics address only one

possible dimension of cohesion and coupling.

Moreover, CBO implicitly assumes that all basic

couples are of equal strength (Hitz and Montazeri,

1995). In addition, it takes a binary approach to

coupling between modules: two modules are either

coupled or not. Multiple connections to the same

module are counted as one (Briand et al., 1999). In

our defence we would point out that even the OO

community has yet to arrive at a consensus about the

appropriate measurement of coupling and cohesion.

The interested reader is referred to (Hitz and

Montazeri, 1995, Briand et al., 1998), and (Briand et

al., 1999) where an extensive surveys have been

presented.

Fourthly, we could be criticised for generalizing

findings from AspectJ to AOP. In our defence, most

of the claims about the superiority of the AO

modularization have been made in the context of

AspectJ. It also should be noted that AspectJ is the

only production-ready general purpose AO

language.

Finally, although „the GoF patterns effectively

comprise a microcosm of many possible systems”

(Srivisut and Muenchaisri, 2006), the conclusions

obtained from our study are restricted to small-sized

systems only. However, our experience indicates

that in case of larger systems, when multiple advices

apply to the same join point and when different

aspects influence each other, modularity is even

harder to achieve. The similar observation was

reported by Kästner et al. (Kästner et al., 2007). We

would also like to mention that the chosen sample

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

144

favours AOP. This is due to the facts that: (1) a

number of design patterns intensively involve

crosscutting concerns (Hannemann and Kiczales,

2002); and (2) recent studies have shown that OO

constructs are not able to modularize these pattern-

specific concerns and tend to lead to programs with

poor modularity (Garcia et al., 2005).

To conclude, we are mindful that the limited size

of the examples restricts the extrapolation of our

results. We are also well aware that CBO and

LCOM suffer from several disadvantages. We also

known that the modularity evaluated in our setting

may differ from the real modularity. The reason is

that, it is not yet clear neither how to best measure

attributes such as coupling and cohesion, nor how to

compare modularity between systems that were

developed in different paradigms. Nevertheless, the

examples provide enough evidence to challenge the

claim that AOP enables to achieve a better

modularization.

9 RELATED WORK

There are a few studies focusing on the quantitative

assessment of the AO modularization. However, to

the best of our knowledge, they use an incomplete

metric of coupling. It should be also noted that most

researchers compare aggregate coupling and

cohesion between an OO and AO version of the

same systems. Aggregate coupling (cohesion) for a

system is calculated as the sum of coupling

(cohesion) taken over all modules. However,

aggregate coupling (cohesion) says nothing about

the goodness of modularization. In addition,

aggregate coupling does not satisfy the second

axiom of Fenton & Melton (Fenton and Melton,

1990) for coupling measures. This axiom states that

system coupling should be independent from the

number of modules in the system. If a module is

added and shows the same level of pairwise

coupling as the already existing modules, then the

coupling of the system remains constant.

The experiment closest to ours is the one

conducted by Garcia et al. (Garcia et al., 2005).

They also compared the AO and OO

implementations of the Gang-of-Four patterns but in

different settings. Firstly, they applied the metrics

suite of Sant’Anna et al. (Sant’Anna et al., 2003).

Secondly, their results “represent the tally of metric

values associated with all the classes and aspects for

each pattern implementation”, while our results

represent the average of metric values. Thirdly, they

performed two studies, one on the original

implementations from Hannemann & Kiczales and

the other on the implementations with introduced

changes. These changes were introduced because the

H&K implementations encompass few participant

classes to play pattern roles (Garcia et al., 2005).

Garcia and his team conclude their study as follows:

”We have found that most AO solutions improved

the separation of pattern related concerns. In

addition, we have found that: the use of aspects

helped to improve the coupling and cohesion of

some pattern implementations.” However this

conclusion may be misleading, according to the

metrics they collected. The measures before the

application of the changes exhibit that only

Composite and Mediator present lower coupling for

the AO solutions. The implementations of Adapter

and State have the same coupling in the both

paradigms. In cases of the other patterns, the OO

solutions indicate lower coupling. The superiority of

OO solutions decreased a little after the changes

were introduced. Although the AO implementations

of Observer, Chain of responsibility, State and

Visitor became better with respect to coupling than

their OO counterparts, there are still 16 patterns for

which the OO implementations provide superior

results.

Sant’Anna et al. (Sant’Anna et al., 2003)

conducted a semi-controlled experiment to compare

the use of an OO approach (based on design

patterns) and an AO approach to implement

Portalware (about 60 modules and over 1 KLOC), a

multi-agent system. Portalware is a web-based

environment that supports the development and

management of Internet portals. The collected

metrics show that the AO version incorporates

modules with higher coupling and lower cohesion.

The other studies either do not consider the

coupling introduced by pointcuts at all (Madeyski

and Szała, 2007, Filho et al., 2006, Greenwood et

al., 2007) or consider it only if a module is explicitly

named by the pointcut expression (Tsang et al.,

2004, Hoffman and Eugster, 2007). No matter which

of these two categories the study belongs to, the

measured coupling is underestimated.

Greenwood et al. (Greenwood et al., 2007) chose

the Health Watcher (HW) system (about 100

modules and over 5 KLOC) as the base for their

study. HW is a web-based information system that

was developed by Soares (Soares, 2004) for the

healthcare bureau of the city of Recife, Brazil. It

involves a number of recurring concerns and

technologies common in day-to-day software

development, such as GUI, persistence, concurrency,

RMI, Servlets and JDBC. Both the OO and AO

AN EMPIRICAL ASSESSMENT OF THE IMPACT OF ASPECT-ORIENTED PROGRAMMING ON SOFTWARE

MODULARITY

145

designs of the HW system were developed with

modularity and changeability principles as main

driving design criteria. Greenwood et al. found that

“modularity” is improved with AOP; the average

coupling as well as cohesion were increased by 17%

in the base version.

Madeyski & Szała (Madeyski and Szała, 2007)

examined the impact of AOP on software

development efficiency and design quality in the

context of a web-based manuscript submission and a

review system (about 80 modules and 4 KLOC).

Three students took part in their study. Two of them

developed the system (labelled as OO1 and OO2)

using Java, whilst one implemented the system using

AspectJ. The observed results show that the AO

version is 24% better than the others with regard to

“coupling” and it is 60% (3%) better then OO1

(OO2) with regard to cohesion.

Filho et al. (Filho et al., 2006) investigated how

metrics were affected in three real-world

applications when exception handling was

implemented using AspectJ instead of Java. The first

application is a subset (224 modules) of Telestrada,

a traveller information system being developed for a

Brazilian national highway administrator. The

second application is Pet Store (339 modules), a

demo for the J2EE platform that is representative of

existing e-commerce applications. The last

application is CVS Core Plugin (257 modules), part

of the basic distribution of the Eclipse platform.

Filho and his team analyzed the aggregate values.

After dividing these values by the number of

modules, it turns out that the average “coupling” was

decreased by 6%, 9%, and 1%. At the same time, the

average cohesion was decreased by 3% for the

second system and increased by 19% and 4% for the

others. Filho et al. (Filho et al., 2006) are aware that

their study does not consider the coupling introduced

by pointcuts: “a closer examination on the code (...)

reveals a subtle kind of coupling that is not captured

by the employed metrics.”

The Telestrada and Pet Store systems were also

used by Hoffman & Eugster. In their study

(Hoffman and Eugster, 2007), they manually

calculated the CIM metrics. Unfortunately, they do

not provide an overall metric for coupling. However,

it seems that the overall coupling is not much

affected with the change of paradigm.

Tsang et al. (Tsang et al., 2004) compared AO

vs. OO solutions in the context of real time traffic

simulator. They found that aspects improved

modularity by reducing “coupling” and cohesion.

They considered aspects coupled to classes only if

the aspects explicitly named the classes. “For

instance, if we have the joinpoint call (* *(..)), then

the aspect is not coupled to any classes. However, if

we have the joinpoint call(void

Test.methodName(..)), then the aspect is coupled to

Test.” In conclusion of their work, they recommend

the use of wildcards to maximise modularity

improvements. Following this reasoning, one could

recommend to replace the previous pointcut by

call(void Test.methodNam*(..)), where ‘*’ instead of

‘e’ eliminates „coupling”.

10 SUMMARY

This paper presented an empirical study in which we

compared the OO and AO implementations of the

GoF patterns with respect to modularity. The

evaluation is performed applying the CBO and

LCOM metrics from the CK suite, which were

adapted for use on AO systems.

The contribution of this research can be

summarized as follows. Firstly, we defined a new

metric for coupling. The existing metrics are invalid

for evaluating coupling in AO systems, since they do

not take into account implicit dependencies between

the system modules. Our metric can be applied to

OO as well as AO systems. Furthermore, we

improved AOPmetrics whose objective is to collect

metrics of Java and AspectJ source code.

Secondly, we demonstrated how to compare

modularity between OO and AO implementations.

We also gave several theoretical and intuitive

arguments to support our approach.

Finally, we found that the claim that AOP

promotes better modularity of software than OOP is

a myth. Only 1 out of 23 designs used in our study is

superior with regard to coupling, while 21 are

inferior. The reason is that aspects are tightly

connected with the affected classes. With regard to

cohesion the OO implementations were superior in 9

cases, while the AO ones in 6 cases. 8 patterns

exhibit the same cohesion in both implementations.

To our surprise, there was no pattern whose AO

implementation brings better modularity. As far as

we know, this is the first presentation of empirical

evidence to this effect. Although some empirical

studies were undertaken in the context of AO

modularity, none of them took into account all the

significant dependencies. Hence, they favoured

AOP. In our future work, we would like to perform

further empirical evaluations on larger AO systems.

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

146

REFERENCES

Basili, V. R., Briand, L. C., Melo, W. L., 1996. A

Validation of Object-Oriented Design Metrics as

Quality Indicators. IEEE Transactions on Software

Engineering vol. 22(10), pp. 751-761

Briand, L. C., Daly, J. W., Wüst, J., 1998. A Unified

Framework for Cohesion Measurement in Object-

Oriented Systems. Empirical Softw. Engg. vol. 3(1),

pp. 65-117

Briand, L. C., Daly, J. W., Wüst, J. K., 1999. A Unified

Framework for Coupling Measurement in Object-

Oriented Systems. IEEE Transactions on Software

Engineering vol. 25(1), pp. 91-121

Briand, L. C., Morasca, S., Basili, V. R., 1999. Defining

and Validating Measures for Object-Based High-Level

Design. IEEE Trans. Softw. Eng. vol. 25(5), pp. 722-

743

Briand, L. C., Wüst, J. K., Lounis, H., 2001. Replicated

Case Studies for Investigating Quality Factors in

Object-Oriented Designs. Empirical Software Eng.,

vol. 6(1), pp. 11-58

Booch, G., 1994. Object-oriented Analysis and Design

with Applications. Benjamin-Cummings, Redwood

City, California

Ceccato, M., Tonella, P., 2004. Measuring the Effects of

Software Aspectization. In: 1st Workshop on Aspect

Reverse Engineering, Delft, Netherlands

Chidamber, S. R., Kemerer, C. F., 1994. A Metrics Suite

for Object Oriented Design. IEEE Trans. Softw. Eng.

20, 6 (Jun. 1994), pp. 476-493

Fenton, N., Melton, A., 1990. Deriving Structurally Based

Software Measures. J. Syst. Software vol. 12, pp. 177-

187

Filho, F. C., Cacho, N., Figueiredo, E., Maranhão, R.,

Garcia, A., Rubira, C. M., 2006. Exceptions and

aspects: the devil is in the details. In: 14th ACM

SIGSOFT international Symposium on Foundations of

Software Engineering, Portland, Oregon

Garcia, A., Sant'Anna, C., Figueiredo, E., Kulesza, U.,

Lucena, C., von Staa, A., 2005. Modularizing design

patterns with aspects: a quantitative study. In: 4th

international Conference on Aspect-Oriented Software

Development (AOSD'05), Chicago, Illinois

Greenwood, P., Bartolomei, T. T., Figueiredo, E., Dósea,

M., Garcia, A. F., Cacho, N., Sant'Anna, C., Soares,

S., Borba, P., Kulesza, U., Rashid, A., 2007. On the

Impact of Aspectual Decompositions on Design

Stability: An Empirical Study. In: 21st European

Conference on Object-Oriented Programming

(ECOOP'07), Berlin, Germany

Guyomarc'h, J., Guéhéneuc, Y., 2005. On the Impact of

Aspect-Oriented Programming on Object-Oriented

Metrics. In: Workshop on Quantitative Approaches in

Object-Oriented Software Engineering at ECOOP'05,

Glasgow, UK

Hannemann, J., Kiczales, G., 2002. Design Pattern

Implementation in Java and AspectJ. In: 17th

Conference on Object-Oriented Programming

Systems, Languages, and Applications, Seattle

Hitz, M., Montazeri, B., 1995. Measuring Coupling and

Cohesion in Object-Oriented Systems. In: 3rd

International Symposium on Applied Corporate

Computing, Monterrey, Mexico

Hoffman, K., Eugster, P., 2007. Bridging Java and

AspectJ through explicit join points. In: 5th

international Symposium on Principles and Practice

of Programming in Java, Lisboa, Portugal

Kästner, C., Apel, S., Batory, D., 2007. A Case Study

Implementing Features using AspectJ. In: 11th

International Conference of Software Product Line

Conference (SPLC'07), Kyoto, Japan

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, Ch.,

Lopes, C. V., Loingtier, J., Irwin, J., 1997. Aspect-

Oriented Programming. LNCS, vol. 1241, pp. 220-242.

Springer, New York

Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm,

J., Griswold, W. G., 2001. An Overview of AspectJ.

In: 15th European Conference on Object-Oriented

Programming (ECOOP’01), Budapest, Hungary

Lesiecki, N., 2002. Improve modularity with aspect-

oriented programming. http://www.ibm.com/

developerworks/library/j-aspectj/

Madeyski, L., Szała, Ł., 2007. Impact of aspect-oriented

programming on software development efficiency and

design quality: an empirical study. IET Software

Journal, vol. 1(5), pp. 180–187

Mancoridis, S., Mitchell, B. S., Rorres, C., Chen, Y.,

Gansner, E. R., 1998. Using Automatic Clustering to

Produce High-Level System Organizations of Source

Code. In: 6th international Workshop on Program

Comprehension (IWPC'98), Ischia, Italy

Meyer B., 1989. Object-oriented Software Construction,

Prentice Hall

Monteiro, M. P., Fernandes, J. M., 2005. Towards a

Catalog of Aspect-Oriented Refactorings. In: 4th

international Conference on Aspect-Oriented Software

Development (AOSD'05), Chicago, Illinois

Munoz, F., Baudry, B., Barais, O., 2008. A classification

of invasive patterns in AOP. In: 24th IEEE

International Conference on Software Maintenance

(ICSM’08), Beijing, China

Ponnambalam, K., 1997. Characterization and Selection of

Good Object-Oriented Design. In: Workshop on OO

Design at OOPSLA’97, Atlanta, Georgia

Przybylek, A., 2007. Post Object-Oriented Paradigms in

Software Development: a Comparative Analysis. In:

1st Workshop on Advances in Programming

Languages at IMCSIT'07, Wisła, Poland

Sant’Anna, C., Garcia, A., Chavez, C. Lucena, C., von

Staa, A., 2003. On the Reuse and Maintenance of

Aspect-Oriented Software: An Assessment

Framework. In: 17th Brazilian Symposium on

Software Engineering (SEES'03), Manaus, Brazil

Soares, S., 2004. An Aspect-Oriented Implementation

Method. PhD thesis, Federal University of

Pernambuco, Brazil

Srivisut, K., Muenchaisri, P., 2006. Determining

Threshold of Aspect-Oriented Software Metrics. In:

AN EMPIRICAL ASSESSMENT OF THE IMPACT OF ASPECT-ORIENTED PROGRAMMING ON SOFTWARE

MODULARITY

147

3rd International Joint Conference on Computer

Science and Software Engineering, Bangkok, Thailand

Stochmiałek, M., 2005. AOPmetrics.

http://aopmetrics.tigris.org

Tsang, S. L., Clarke, S., Baniassad, E., 2004. Object

metrics for aspect systems: Limiting empirical

inference based on modularity. Technical Report,

Trinity College Dublin

Yourdon, E., Constantine, L. L., 1979. Structured Design:

Fundamentals of a Discipline of Computer Program

and System Design. Prentice-Hall, New York

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

148