A Systematic Review on Evaluation of Aspect Oriented Programming

using Software Metrics

Joyce M. S. Franc¸a and Michel dos Santos Soares

Computing Faculty, Federal University of Uberlˆandia, Uberlˆandia, Brazil

Keywords:

Aspect-oriented Programming, Systematic Review, Software Metrics.

Abstract:

Aspect oriented software development has been applied in past years with the promise of improving mod-

ularization by addressing crosscutting concerns. Many studies have been published, with varying degree of

success on using this paradigm. Software metrics have been presented with the purpose of evaluating the ﬁnal

results. However, too few studies on empirical evidence of the beneﬁts of aspect-oriented paradigm were pub-

lished, results are frequently subjective, and some studies are non-conclusive. A systematic review on aspect

oriented software development and metrics is proposed in this article.

1 INTRODUCTION

Object-Oriented Programming (OOP) emerged with

the promise of improving modularization and increas-

ing the abstraction level to programming and design.

Despite the success of OOP, the beneﬁts are still not

enough in the sense that it did not solve issues of

modularity. OOP is appropriate at modularizing core

concerns, but fails when modularizing crosscutting

concerns, i.e., concerns scattered throughout imple-

mentation (Filman et al., 2005). For instance, when

dealing with behaviours that span many, often unre-

lated modules, OOP can be inadequate. The negative

impact of code tangling and code scattering affects

software development in many ways, including poor

traceability, low productivity, problems when trying

to reuse code, poor overall quality and increased ef-

forts for software maintenance (Laddad, 2003). A

new implementation construct, the aspect (Kiczales

et al., 1997), was introduced in order to deal with

these issues.

Two main problems motivated this study. The

ﬁrst one is considering the fact that too few stud-

ies on empirical evidence of the beneﬁts of Aspect-

Oriented Programming (AOP) were published. In ad-

dition to this ﬁrst problem, a derived problem is that

studies are non-conclusive. For instance, researchers

came to conclusions that AOP present many beneﬁts,

despite drawbacks such as decreased performance

(Mortensen et al., 2012). Other results have shown

that AOP does not provide real beneﬁts or the bene-

ﬁts are marginal (Madeyski and Szala, 2007) (Bartsch

and Harrison, 2008), and there are yet other publica-

tions clearly advising against AOP (Przybylek, 2010)

(Przybylek, 2011). Another issue is that beneﬁts are

normally shown without explicit measurements or re-

sults are subjective (Ali et al., 2010).

2 RESEARCH METHOD

The main research question that motivated this re-

search is: What evidence currently exist in the lit-

erature that aspect-oriented software development is

beneﬁcial? A derived research question is “how the

evidence of beneﬁts of AOP has been measured?”.

The answer to this question is related to what met-

rics have been applied in order to evaluate AOP, and

how AOP compares with OOP.

In order to answer both questions, the proposal is

to perform a systematic review (Kitchenham, 2004)

with the purpose of identifying what type of re-

search has been performed within AOP. The sys-

tematic review started with a search in a number of

software engineering conferences and journals. The

search was performed starting on January 2006 up

until January 2012, i.e., the past 6 years. The cho-

sen conferences were: CSMR (European Conference

on Software Maintenance and Reengineering), ICSE

(International Conference on Software Engineering),

AOSD (International Conference on Aspect-Oriented

Software Development), ECOOP (European Confer-

ence on Object-Oriented Programming), and OOP-

M. S. França J. and dos Santos Soares M..

A Systematic Review on Evaluation of Aspect Oriented Programming using Software Metrics.

DOI: 10.5220/0003985300770083

In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 77-83

ISBN: 978-989-8565-11-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

Table 1: Overview of Search Results and selected papers.

Venues Retrieved Papers Pre-selected papers Selected Papers Search Method Data source

CSMR 4 3 0 automatic IEEExplorer

ECOOP 5 2 2 manual -

ICSE 26 6 2 automatic IEEExplorer

AOSD 33 9 4 automatic ACM digital library

OOPSLA 13 0 0 automatic ACM digital library

JSS 40 5 2 automatic ScienceDirect

TOSEM 4 1 0 automatic ACM digital library

TSE 4 1 1 automatic IEEExplorer

IST 32 6 2 automatic ScienceDirect

Total 161 33 13

Table 2: Selected papers.

Venue/year Reference

1 AOSD/06 (Cacho et al., 2006)

2 AOSD/08 (Cacho et al., 2008)

3 AOSD/11 (Ramirez et al., 2011)

4 AOSD/10 (Hovsepyan et al., 2010)

5 ECOOP/08 (Coelho et al., 2008)

6 ECOOP/07 (Greenwood et al., 2007)

7 ICSE/08 (Hoffman and Eugster, 2008)

8 ICSE/08 (Figueiredo et al., 2008)

9 IST/08 (Malta and Valente, 2009)

10 IST/10 (Tizzei et al., 2011)

11 TSE/10 (Mortensen et al., 2012)

12 JSS/08 (Kouskouras et al., 2008)

13 JSS/11 (d’Amorim and Borba, 2010)

SLA (International Conference on Object Oriented

Programming, Systems, Languages and Application).

Papers published on speciﬁc workshops held together

with these conferences were not considered. The cho-

sen journals were: JSS (Journal of Systems and Soft-

ware), TOSEM (ACM Transactions on Software En-

gineering Methodology), TSE IEEE (IEEE Transac-

tions on Software Engineering), and IST (Information

and Software Technology).

The chosen search string was (“aspect oriented”

AND “metrics”). The total number of retrieved pa-

pers was 161. The criteria to include a paper was di-

vided into two steps. In the ﬁrst step, for each paper,

the title, the keywords and the abstract were read in

order to make the selection. When in doubt if the pa-

per should be added, also the introduction and/or the

conclusion were read. In this ﬁrst step, articles with

focus on AOP as main concern and with some mea-

surements as results were considered. Even though a

large number of papers were retrieved, only a small

part was fully read (33 papers). The reason is because

many “false positives” were retrieved. The word “as-

pect” is generally used in another context. For the

second step, the criteria for consideration was to fully

read the 33 papers with focus on the application of

software metrics in the ﬁrst version of at least one

software, then the identiﬁcation of crosscutting con-

cerns followed by software refactoring with aspects,

followed by the application of software metrics in the

refactored software version and a comparison of met-

rics for each software version (OOP and AOP). As a

result, thirteen papers were chosen for further analy-

sis, as described in table 2. Within these, twenty-nine

studies were considered. The other 20 papers were

not selected mainly because, although presented AOP

issues, their focus was not on software metrics or the

evaluation was poor or non-existent.

3 CRITERIA FOR EVALUATION

The selected papers were evaluated based on criteria

of type of evaluation, number of studies, properties

and metrics, and which crosscutting concerns were

implemented as aspects, as described in this section.

3.1 Type of Evaluation

The evaluation of each one of the selected papers was

classiﬁed in: real industrial environment, controlled

experiment, case study, and toy application. In this

article, real industrial environment means that the re-

search was applied in practice in a company, when

engineering real software products. This is different

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

Table 3: Summary of studies.

Type of

evaluation

Article Number

of studies

Application Size

(LOC)

Original

Aspect

Industrial

(Ramirez et al., 2011)

1 Plato 1212 Java AspectJ

(Mortensen et al., 2012) 3

InstanceDrivers 1600

C++ AspectC++

environment PowerAnalyzer 13900

ErcChecker 51600

(Kouskouras et al., 2008)

1 Telecom 1700 Java AspectJ

Controlled (Hovsepyan et al., 2010) 2

Toll System 363

Java AspectJ

experiment Pacemaker 369

Case study

(Hovsepyan et al., 2010) 2

Toll System 363

Java AspectJ

Pacemaker 369

(Cacho et al., 2006) 3

Middleware

NA Java AspectJ

Measurement tool

Agent-based

(Cacho et al., 2008)

1 MobileMedia 4000 Java ME AspectJ

(Coelho et al., 2008) 3

Health Watcher 8825

Java AspectJ

Mobile Photo 1571

JHotDraw 21027

(Greenwood et al., 2007)

1 Health Watcher 4000 Java AspectJ,

CaesarJ

(Hoffman and Eugster, 2008) 3

Telestrada 3400

Java AspectJ

Pet Store J2EE 17800

Health Watcher 4000

(Figueiredo et al., 2008) 2

MobileMedia 3000

Java AspectJ

BestLab 10000

(Malta and Valente, 2009) 4

Jaccounting 11676

Java AspectJ

JHotDraw 40022

Prevayler 2418

Tomcat 45107

(Tizzei et al., 2011)

1 MobileMedia 11000 Java ME AspectJ

(d’Amorim and Borba, 2010)

1 Health Watcher 5500 Java AspectJ

Toy App

(d’Amorim and Borba, 2010) 1 Library System 600 Java AspectJ

from a case study, which involves working with some

sample application, often an open-source project. A

controlled experiment means that an experimental ap-

proach for evaluation was followed with human sub-

jects participating and being evaluated when execut-

ing tasks. A toy application is normally a software

tool developed in academia in order to prove research

concepts.

Other ﬁelds of comparison include the total num-

ber of studies presented in each article, the name of

the application(s) developed and presented in the ar-

ticle, the size of the application given in LOC (NA

means not available), the original programming lan-

guage in which the application was developed, and the

AOP language used in the refactoring process. Some

of the selected articles present more than one appli-

cation as study. Therefore, Table 3 presents the num-

ber of studies in one column. When the article had

more than one study, the results of each metric are

compared for each study. For example, if the article

has two studies, and the result of the metric was posi-

tive/negative for both, for this metric the article obtain

positive/negative conclusion. However, if one study

has positive result and the other one negative result,

then this article receive inconclusive mark.

3.2 Considered Crosscutting Concerns

The list of the most common crosscutting concerns

considered (Filman et al., 2005) 4 and the acronyms

used in this article are: S - Security, P - Persistence, C

- Caching, T - Tracing, NPC - Null Pointer Checking,

EH - Exception Handling, RTC - Run-Time Conﬁg-

urations, Sy - Synchronization, CC - Concurrency

Control, TM - Transaction Management, CIC - Class

Initialization Checking, DS - Domain Speciﬁc.

ASystematicReviewonEvaluationofAspectOrientedProgrammingusingSoftwareMetrics

Table 4: Crosscutting Concerns implemented in the studies.

Articles Types of Crosscuting Concerns transformed in aspects

S P C T NPC EH RTC Sy CC TM CIC DS

(Cacho et al., 2006)

(Cacho et al., 2008)

(Ramirez et al., 2011)

(Hovsepyan et al., 2010)

(Coelho et al., 2008)

(Greenwood et al., 2007)

(Hoffman and Eugster, 2008)

(Figueiredo et al., 2008)

(Malta and Valente, 2009)

(Tizzei et al., 2011)

(Mortensen et al., 2012)

(Kouskouras et al., 2008)

(d’Amorim and Borba, 2010)

Total 1 4 1 1 1 8 1 1 4 1 1 7

Table 5: Properties and Metrics - 1.

Property Metric Articles Conclusion Total

Code Size

Lines of Code (LOC)

(Greenwood et al., 2007) +

2+, 7-, 3?

(Mortensen et al., 2012) +

(Cacho et al., 2006) -

(Cacho et al., 2008) -

(Ramirez et al., 2011) -

(Coelho et al., 2008) -

(Figueiredo et al., 2008) -

(Malta and Valente, 2009) -

(Tizzei et al., 2011) -

(Hovsepyan et al., 2010) ?

(d’Amorim and Borba, 2010) ?

(Hoffman and Eugster, 2008) ?

Vocabulary Size (VS)

(Cacho et al., 2006) +

1+, 6-

(Cacho et al., 2008) -

(Greenwood et al., 2007) -

(Figueiredo et al., 2008) -

(d’Amorim and Borba, 2010) -

(Coelho et al., 2008) -

(Tizzei et al., 2011) -

Number of attributes (NOA)

(Cacho et al., 2006) +

3+, 1?

(Ramirez et al., 2011) +

(Hovsepyan et al., 2010) +

(Cacho et al., 2008) ?

Number of operations (NOO) (Hoffman and Eugster, 2008) - 1-

Weighted operations per component (WOC)

(Cacho et al., 2006) +

3+, 2-

(Ramirez et al., 2011) +

(Hovsepyan et al., 2010) +

(Cacho et al., 2008) -

(Greenwood et al., 2007) -

Complexity Ciclomatic Complexity per component (Ramirez et al., 2011) + 1+

3.3 Properties and Metrics

Metrics were grouped into properties. Properties such

as code size, cohesion and coupling are useful to eval-

uate the chosen architecture design. Tables 5 and 6

present the ﬁnal list of properties and metrics. We

extracted from each article which metrics were used.

Moreover, we came to this conclusion obtained from

each article about comparing AOP applications and

non-AOP applications. The conclusion could be posi-

tive (+), negative (-) or inconclusive (?). Inconclusive

results are based on two possibilities. Either metrics

were applied in two different applications and the re-

sults are nearly the same, or one application obtained

positive conclusions and the other one negative con-

clusions.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

Table 6: Properties and Metrics - 2.

Property Metric Articles Conclusion Total

Coupling

Coupling between Components (CBC)

(Hovsepyan et al., 2010) +

3+, 3-, 1?

(Greenwood et al., 2007) +

(Figueiredo et al., 2008) +

(Cacho et al., 2006) -

(Cacho et al., 2008) -

(d’Amorim and Borba, 2010) -

(Hoffman and Eugster, 2008) ?

Depth of Inheritance Tree (DIT)

(Ramirez et al., 2011) +

1+, 2-(Cacho et al., 2008) -

(d’Amorim and Borba, 2010) -

Efferent Coupling (EC)

(Ramirez et al., 2011) +

1+, 2-(Tizzei et al., 2011) -

(Kouskouras et al., 2008) -

Cohesion

Lack of Cohesion over Operations (LCOO)

(Cacho et al., 2006) +

6+, 3-

(Ramirez et al., 2011) +

(Hovsepyan et al., 2010) +

(Greenwood et al., 2007) +

(Tizzei et al., 2011) +

(d’Amorim and Borba, 2010) +

(Cacho et al., 2008) -

(Hoffman and Eugster, 2008) -

(Figueiredo et al., 2008) -

Concern diffusion over components(CDC)

(Hovsepyan et al., 2010) +

3+, 3-

(Tizzei et al., 2011) +

(d’Amorim and Borba, 2010) +

(Cacho et al., 2008) -

(Greenwood et al., 2007) -

(Figueiredo et al., 2008) -

Concern diffusion over operations (CDO)

(Hovsepyan et al., 2010) +

3+, 2-

(Greenwood et al., 2007) +

Separation (Tizzei et al., 2011) +

of Con-

cerns

(Cacho et al., 2008) -

(Figueiredo et al., 2008) -

Concern diffusion over LOC (CDLOC)

(Cacho et al., 2008) +

(Hovsepyan et al., 2010) +

(Greenwood et al., 2007) +

(Figueiredo et al., 2008) +

(Tizzei et al., 2011) +

(Mortensen et al., 2012) +

Number of added/changed/removed components

(d’Amorim and Borba, 2010) +

1+, 2-, 2?

(Tizzei et al., 2011) -

Change (Greenwood et al., 2007) ?

Impact (Figueiredo et al., 2008) ?

Number of added/changed/removed operations

(Greenwood et al., 2007) +

2+, 1-(Figueiredo et al., 2008) +

(Tizzei et al., 2011) -

4 DISCUSSION

Even after performing the systematic research, the

ﬁrst research question: What evidence currently ex-

ist in the literature that aspect-oriented software de-

velopment is beneﬁcial? still cannot be properly an-

swered. Most works implement less than three cross-

cutting concerns as aspects, which means that too

many crosscutting concerns were not considered. For

instance, considering that 26 applications were per-

formed within these 13 articles, the important concern

of logging was not implemented. The research ques-

tion: “how the evidence of beneﬁts of AOP has been

measured?”, has been answered mainly with the ap-

plication of metrics proposed for object-oriented pro-

gramming. However, many important metrics, such

ASystematicReviewonEvaluationofAspectOrientedProgrammingusingSoftwareMetrics

as “Response for a component” and “Operation cohe-

sion”, which are related to the Modularity property,

were not considered at all. Another issue is that few

speciﬁc aspect-oriented metrics were applied in the

studies.

In general, it was difﬁcult to conclude the beneﬁts

of AOP in terms of the code size property. Seven stud-

ies presented negative results (the number of lines of

code increased with AOP), two positives, and three

inconclusive. According to these results, for most

studies AOP increased LOC after refactoring with as-

pects. This result is surprising, as it should be ex-

pected that with better modularization with aspects,

and the deletion of lines of code corresponding to

crosscutting concerns, the number of LOC should de-

crease. The metric vocabulary size had negative re-

sults for three studies, which means that the number

of elements such as classes, interfaces and conﬁgura-

tion ﬁles increased in the AOP version. This is natu-

ral, as with the introduction of aspects further connec-

tion between code elements is necessary. The met-

ric “number of attributes” has positive results when

refactoring with AOP. As only one article mentioned

the metric “number of operations”, it is not possible

to draw conclusions. The metric “weighted opera-

tions per component (WOC)” was mentioned in ﬁve

articles, and eight studies, with six positives and two

negatives. It seems that AOP decreases WOC, i.e., de-

creases complexity of a component. However, further

analysis is necessary.

With only one article, and only one application,

it is not possible to draw conclusions on complexity.

Also, all metrics about coupling (CBC, DIT, EC) are

inconclusive, which means that it was not possible to

state that AOP will have any beneﬁt in terms of de-

creasing coupling. DIT and EC had one positive, and

one negative each. CBC had two negatives, three pos-

itives, and one inconclusive result. Cohesion was in-

vestigated in fourteen applications. It was improved

in eight applications, but negative in six applications.

Based on this, although it seems that cohesion is in-

creased with AOP, it is not possible to draw strong

conclusions. About the “Separation of Concerns”,

three metrics were considered: CDC, CDO, and CD-

LOC. The ﬁrst two are inconclusive, but the metric of

concern diffusion over LOC was positive for all six

articles.

Change impact was deﬁned through two metrics.

The ﬁrst one, “Number of added/changed/removed

class (modules)”, is insigniﬁcant for two articles, and

negative for one article. Based on this, is seems that

the application of AOP does not have a strong impact

on classes, but further analysis is necessary. The sec-

ond one, “Number of added/changed/removed opera-

tions”, is positive (AOP makes few changes) for two

articles, and negative (AOP makes many changes) for

one. Based on this, it is difﬁcult to come to strong

conclusions. From Table 4, it is clear that most im-

plemented crosscutting concern was “Exception Han-

dling”. Therefore, it can be inferred that aspects are

very used to modularize exceptions. Only four out

of thirteen papers implemented three or more cross-

cutting concerns, i.e., most researchers are not intro-

ducing aspects in substitution of many crosscutting

concerns. The reason for this policy is not clear and

should be further investigated.

5 CONCLUSIONS

The results of the systematic review proposed in this

article are that too few studies on empirical evidence

of the beneﬁts of aspect-oriented paradigm were pub-

lished, results are frequently subjective, and some

studies are non-conclusive. Only a small number of

crosscutting concerns are actually being considered

by most researches. In addition, too few software

metrics were applied, which makes it difﬁcult to draw

strong conclusions, and speciﬁc AOP metrics were

applied in only few studies. In terms of type of eval-

uation, much more has to be done. Only two studies

were held in a real industrial environment, and only

one controlled experiment was performed. It is sur-

prising that for most studies, the number of lines of

code increased. As the introduction of aspects in-

crease modularity, it could be expected that the num-

ber of lines of code would decrease. It is also surpris-

ing that software metrics that are important for archi-

tectural properties, such as coupling and modularity,

were not investigated in any of the searched papers.

Much more can be done on evaluating AOP. One

important result is that the introduction of AOP in in-

dustry is still in its infancy, as only ﬁve out of twenty-

nine studies were performed in a real industrial en-

vironment. Controlled experiments with developers

is also not common (only one article), which means

that there is a large path to follow on this matter. Fur-

ther studies are necessary to understand what happens

with complexity with the introduction of aspects in

an OO code, as only one article mentioned the cyclo-

matic complexity metric.

REFERENCES

Ali, M. S., Ali Babar, M., Chen, L., and Stol, K.-J. (2010).

A Systematic Review of Comparative Evidence of

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

Aspect-Oriented Programming. Information and Soft-

ware Technology, 52:871–887.

Bartsch, M. and Harrison, R. (2008). An Exploratory

Study of the Effect of Aspect-Oriented Programming

on Maintainability. Software Quality Control, 16:23–

44.

Cacho, N., Filho, F. C., Garcia, A., and Figueiredo, E.

(2008). EJFlow: Taming Exceptional Control Flows

in Aspect-Oriented Programming. In Proc. of the 7th

International Conference on Aspect-Oriented Soft-

ware Development, pages 72–83.

Cacho, N., Sant’Anna, C., Figueiredo, E., Garcia, A.,

Batista, T., and Lucena, C. (2006). Composing De-

sign Patterns: a Scalability Study of Aspect-Oriented

Programming. In Proc. of the 5th International Con-

ference on Aspect-Oriented Software Development,

pages 109–121.

Coelho, R., Rashid, A., Garcia, A., Ferrari, F. C., Cacho,

N., Kulesza, U., von Staa, A., and de Lucena, C. J. P.

(2008). Assessing the Impact of Aspects on Exception

Flows: An Exploratory Study. In ECOOP, pages 207–

234.

d’Amorim, F. and Borba, P. (2010). Modularity Analy-

sis of Use Case Implementations. In Brazilian Sym-

posium on Software Components, Architectures and

Reuse, pages 11–20.

Figueiredo, E., Cacho, N., Sant’Anna, C., Monteiro, M.,

Kulesza, U., Garcia, A., Soares, S., Ferrari, F., Khan,

S., Castor Filho, F., and Dantas, F. (2008). Evolving

Software Product Lines with Aspects: An Empirical

Study on Design Stability. In Proc. of the 30th inter-

national conference on Software engineering, pages

261–270.

Filman, R. E., Elrad, T., Clarke, S., and Aks¸it, M., edi-

tors (2005). Aspect-Oriented Software Development.

Addison-Wesley, Boston.

Greenwood, P., Bartolomei, T. T., Figueiredo, E., D´osea,

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

S., Borba, P., Kulesza, U., and Rashid, A. (2007).

On the Impact of Aspectual Decompositions on De-

sign Stability: An Empirical Study. In ECOOP, pages

176–200.

Hoffman, K. and Eugster, P. (2008). Towards Reusable

Components with Aspects: An Empirical Study on

Modularity and Obliviousness. In Proc. of the 30th

International Conference on Software Engineering,

pages 91–100.

Hovsepyan, A., Scandariato, R., Van Baelen, S., Berbers,

Y., and Joosen, W. (2010). From Aspect-Oriented

Models to Aspect-Oriented Code?: The Maintenance

Perspective. In Proc. of the 9th International Con-

ference on Aspect-Oriented Software Development,

pages 85–96.

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

Lopes, C., Loingtier, J.-M., and Irwin, J. (1997).

Aspect-Oriented Programming. volume 1241 of Lec-

ture Notes in Computer Science, chapter 10, pages

220–242.

Kitchenham, B. (2004). Procedures for Performing Sys-

tematic Reviews. Keele university. technical report

tr/se-0401, Department of Computer Science, Keele

University, UK.

Kouskouras, K. G., Chatzigeorgiou, A., and Stephanides, G.

(2008). Facilitating Software Extension with Design

Patterns and Aspect-Oriented Programming. Journal

of Systems and Software, 81:1725–1737.

Laddad, R. (2003). AspectJ in Action. Manning, USA, 1

edition.

Madeyski, L. and Szala, L. (2007). Impact of Aspect-

Oriented Programming on Software Development Ef-

ﬁciency and Design Quality: an Empirical Study. IET

Software, 1(5):180–187.

Malta, M. N. and Valente, M. T. O. (2009). Object-Oriented

Transformations for Extracting Aspects. Information

and Software Technology, 51(1):138–149.

Mortensen, M., Ghosh, S., and Bieman, J. M. (2012).

Aspect-Oriented Refactoring of Legacy Applications:

An Evaluation. IEEE Transactions on Software Engi-

neering, 38:118–140.

Przybylek, A. (2010). What is Wrong with AOP? In IC-

SOFT (2), pages 125–130.

Przybylek, A. (2011). Impact of Aspect-Oriented Program-

ming on Software Modularity. In Proc. of the 15th

European Conference on Software Maintenance and

Reengineering, pages 369–372.

Ramirez, A. J., Jensen, A. C., and Cheng, B. H. (2011).

An Aspect-Oriented Approach for Implementing Evo-

lutionary Computation Applications. In Proc. of the

Tenth International Conference on Aspect-Oriented

Software Development, pages 153–164.

Tizzei, L. P., Dias, M. O., Rubira, C. M. F., Garcia, A., and

Lee, J. (2011). Components Meet Aspects: Assessing

Design Stability of a Software Product Line. Informa-

tion & Software Technology, 53(2):121–136.

ASystematicReviewonEvaluationofAspectOrientedProgrammingusingSoftwareMetrics