社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

アスペクトマイニングを自動的に行うツールの提案
Livieri

Simone†

石尾

隆†

楠本

真二†

井上 克郎†† 大阪大学 大学院情報科学研究科 コンピュータサイエンス専攻 〒 560-8531 豊中市待兼山町 1-3
E-mail: †{simone,t-isio,kusumoto,inoue}@ist.osaka-u.ac.jp
あらまし ソフトウェアは，その規模が増大し，より複雑なものとなってきている．ソフトウェアが複雑化するに従って，保守性，モジュール性が悪化することから，これらの品質を改善するための変更作業がしばしば行われている．
これに伴って，アスペクト指向プログラミングへの注目も高まっており，既存のシステムをアスペクト指向設計に改変する作業も増加している．このような問題に対して，アスペクトマイニングと呼ばれる，横断的関心事の候補をソ
フトウェア中から発見し，リファクタリングを支援するための手法が研究されている．本稿では，アスペクトマイニ
ングを自動化する試験的な手法について述べる．
キーワード

アスペクト, アスペクトマイニング, アスペクト指向プログラミング, 分析

Planning an Automated Aspect Mining Tool
Simone LIVIERI† , Takashi ISHIO† , Shinji KUSUMOTO† , and Katsuro INOUE†† Graduate School of Information Science and Technology, Osaka University, 1-3, Machikaneyama-cho,
Toyonaka, Osaka, 560-8531, Japan
E-mail: †{simone,t-isio,kusumoto,inoue}@ist.osaka-u.ac.jp
Abstract Software systems are growing in size and complexity. Increased complexity often leads to decresed
mainainability and bad modularity, and re-engineering tasks is often performed in order to increase the key qualitiesof the system. With the incentive of a growing attention to aspect-oriented programming, the eﬀorts to devise
new techniques for refactoring legacy system into an aspect-oriented design have multiplied. Aspect mining tries to
identify possible cross-cutting concerns in software systems and thus support this kind of refactoring. In this paper,
we present a tentative approach to automated aspect mining analysis aiming at ﬁnding cross-cutting concerns thatcan be easily refactored to aspect-oriented artifacts.
Key words Aspect, aspect mining, aspect-oriented programming, analysis

1. Introduction
As software systems grow in size, they grow in complexity.
Increasing complexity often leads to decreased readability
and maintainability, and to bad modularity. Decomposing
large systems into small parts, more easy to manage, comprehend and maintain, is what developers community currently
do; but, while some behaviors of the systems can be easily
decomposed and isolated, some other ones, by their very nature, are not: error-handling, logging, and tracing are typicalexamples of intrinsically cross-cutting concerns [1] whose implementing code exists in a redundant way, scattered acrossthe code base.
Aspect-Oriented Programming (AOP) [2] aims at easing themodularization of such complex concerns. While retaining
the beneﬁts of the Object-Oriented approach, AOP intends
to free the developer from the so-called Tyranny of the Dominant Decomposition: with the traditional programming languages, a program can be modularized in only one way at atime, and the many kinds of concerns that do not align withthat modularization end up scattered across many modules
and tangled with one another.
Since its inception in the late 90s, AOP has gained relevant
support and attracted the attention of research community
and a lot of diﬀerent approaches that permit aspect-oriented
software development have been developed; among them, themost mentioned are AspectJ [3], developed by the same people that coined the term Aspet-Oriented Programming [2],HyperJ [4], an oﬀspring of subject-oriented programming [5],and AspectWerkz [6].
The increased attention also raised the question about how
AOP can aid the re-engineering of legacy systems to improvetheir key quality attributes, like evolvability and reusability:
tangled code implementing a speciﬁc concern has to be foundand isolated and thereafter extracted into a modular artifact.
These tasks are called aspect-mining and aspect refactoring
respectively.
Our approach to automatic aspect mining exploits meth-—1—

ods aggregation for narrowing the search space and speed-up
the mining process.
Section 2. presents an overview of the current status of
aspect mining research. Section 3. describes our approach.
Section 4. discusses conclusions and open issues.

2. Aspect Mining
Aspect-Mining is the task of searching for candidate aspects in existing system and isolating them into modular
artifacts. To date, a number of research groups are working
on this topic, and a number of tools and methods for aspectmining have been proposed.
One of the ﬁrst eﬀort in identifying cross-cutting concerns was the Aspect Mining Tool (AMT) of Hannemann
and Kiczales [7]. AMT supports both text and type-based
analysis and can be extended with other types of analysis.
Because each of these analyzes has beneﬁts and drawbacks,
AMT has been set as a multi-modal analysis tool. The tool
allows user deﬁned queries based on type usage and regularexpressions, displaying matching lines in speciﬁc colours inthe source code.
FEAT [8] utilizes concern graphs to represent and document cross-cutting concerns. They are based on localizing
an abstracted representation of the program elements contributing to the implementation of the concern. The structure of a concern is stored in a concern graph and, at thesame time, the relationships between the concern’s elements,
such as classes, methods and ﬁelds are documented. FEAT
supports the analysis of the dependencies between a concern
and the rest of the program and allows the viewing of thesource code, in a Java system, associated to a concern graphelement. For concern identiﬁcation, FEAT supports the useof structural queries and integrated lexical searches. The
tool displays a concern graph as a collection of trees withrespect to certain convention, e.g. the root of each tree is aclass that contributes to the implementation of the concern.
FEAT is also implemented as an Eclipse plug-in.
PRISM [9] is a framework for aspect mining based on theassumption that aspects can be deﬁned in terms of structuresin the source code. It uses two extensible concepts to represent aspects in software systems. The ﬁrst concept is the
aspect ﬁngerprint: an aspect ﬁngerprint abstracts a pattern,a structure in the source code, which can be used to locate
aspects. The second concept is an aspect footprint: an aspect
footprint is an abstraction of the location of a particular aspect ﬁngerprint. The aspect mining is performed selecting
a collection of aspect ﬁngerprints and walking through thesource code decomposition units generating a collection of
aspect footprint. PRISM exists also as a plug-in for Eclipse:
this speciﬁc extension of the framework implements a decomposition based on AMTEX an extension to AMT.
DynAMiT [10] is a dynamic aspect mining approach basedon program traces that are generated during the executionof a program. These traces are investigated for recurring
execution relations that describes certain classes of aspectsof the software. The main classes considered are insideaspects, when the call of a method m1 occurs always inside
a call of a method m2 , and outside-aspects, when the callof a method m1 occurs always before (or after) the call of amethod m2 . Furthermore they distinguish subclasses such as
inside-methods that can be ﬁrst-in or last-in inside a speciﬁc

method call, and outside-method than can be after or before
a speciﬁc method call.
Ophir [11] identiﬁes initial refactoring candidates using acontrol-based comparison, followed by a ﬁltering based ondata dependence information. The initial identiﬁcations
phase uses Program Dependence Graphs (PDG) to detect
code clones that are successively ﬁltered in order to eliminate undesirable refactoring candidates. The output of theﬁlter phase is a set of candidate pairs, where each memberof a pair is a from a diﬀerent method, that are coalesced into
sets of similar candidates.
While the tools currently available for aspect mining provide support for the process of identiﬁcation of aspects inexisting software, each approach suﬀers from one or more of
the following drawbacks:• users are required to have considerable amount ofknowledge about the program being analyzed;• search seeds need to be speciﬁed as an explicit input
to the analysis;• the identiﬁcation and ﬁltering phase is not fully automatic;• the identiﬁcation analysis can miss desiderable aspects;• the analysis can take a large amount of time;
The main downfall of lexical searches is the requirement ofa user to input a seed. Formulating a signiﬁcative seed is a
non-trivial task that requires the user to have great understanding of the code base. Even is a good seed is formed, thefragility of the lexical search limits its eﬀectiveness. Lexical
search is just a look for copy of the seed, while often duplicate code means, methods, statements or group of statementswith the same semantics.
Exploratory tools can be of great help in aiding the identiﬁcation of the aspects candidate and system comprehension,
but the main drawback is that they require a lot of time tocomplete the identiﬁcation due to the necessary interaction
with the user.
Exhaustive approaches like [11] have the drawback or requiring a lot of time to complete.
In this paper we present an aspect mining analysis withthe following properties:• desiderable candidates for refactoring are identiﬁed
automatically• no input from the user is required
Our approach to automatic aspect mining exploits code clone
analysis of portion of the code base that could contain aspect
candidates. The next section presents some insights of the
proposed technique.

3. Automated Aspect Mining
Detection of aspect candidates can be conducted in two
ways: in a top-down approach, where the code that implements well-known aspects is searched, and in a bottom-up
way, where symptoms of the lack of proper aspect support
in the language used are searched. More speciﬁcally, these
symptoms are code scattering and code tangling. Suitable
techniques for identifying such symptoms may be clone detection (for scattering) or slicing (for untangling functionality).
Detecting aspect candidates can mean detecting very shortcode clones: for example, the code implementing the logging—2—

concern is often a simple line of code inserted in many different locations of the source code. Diﬀerent techniques forcode clone detections have been proposed, each with its advantages and disadvantages: if applied to large code bases,
more precise detection methods, like AST or PDG based
ones, can be slow, and fast detection methods, like token
based ones [12], can miss signiﬁcative clones（注 1）. It is natural to think that devising a way for narrowing the search
space will be of sure beneﬁt to the code clone analysis. In our
approach we narrow the search space through the indentiﬁcation of so-called cross-cut unit set that are a subsets of theset containing all the methods of the code base containing
cross-cutting code.
The proposed automated aspect mining analysis is basedon AspectJ. In AspectJ there are several type of advice, suchas: before and after. This advice can be execute at a speciﬁed
joint-point. Joint-points are the points that one can specify
within a program to execute a code segment, points such as
the beginning of a method or before an access to a ﬁeld.
What we pursue is to eﬀectively discover aspect candidates
that can be easily refactored into before aspects at the beginning of a method.
Our algorithm consists of four phases:（ 1 ） Construct cross-cut unit sets.
（ 2 ） Identify code clones (token based).
（ 3 ） Prune the set of code clones (constraint based).
（ 4 ） Classify the aspect candidates (dependence based).
3. 1 Constructing cross-cut unit sets
We call cross-cut unit a method or a class containing code
implementing some cross-cutting concern. Scattered code iscalled from diﬀerent places throughout the software system,
and it is likely to have a very high value of the fan-in metric,deﬁned in [13] as:“[...]the number of distinct method bodies that can
invoke [a method] m[...]”
The analysis is made in three consecutive steps (the ﬁrst
two steps are taken from [13]):
Step 1 Automatic computation of the fan-in metric for all
the methods in the target code base.
Step 2 Filtering of the result of the ﬁrst step:• Restrict the set of methods to those having a fan-in
above a certain threshold.
• Remove accessor methods.
• Remove known utility methods
Step 3 For each method m in the restricted set compute
X
whose elements are all the meththe cross-cut units set Cm
ods containing a call to m. A method can belong to morethan a cross-cut unit: this is absolutely not a problem because, as we will see soon, it just means that that method
may contain more than one aspect candidate.
Figure 1 outlines a small example to illustrate this step.
The methods m1 , m2 invoke method mX
1 , method m3 invokes
X
X
methods mX
1 and m2 , and method m4 invokes method m2 .
In this scenario the methods m1 , m2 and m3 belongs to thesame cross-cut unit set, similarly the methods m3 and m4
are in the same set.

（注 1）：Token based methods for code detection, detect clones with aminimum length of a given number of tokens: a small length value will
result in too many reported clones, making them useless.

m1

m2

m3

m4

mX
1

mX
2

図 1 Cross-cut unit sets

3. 2 Identifying code clones
Scattered code can span more than the call site of a highfan-in method, thus it is reasonable to thoroughly conduct
X
a code clone analysis on each of the set Cm
As statedX.
before, code clone analysis can be performed in several way.
For our approach we decided that, for comparison purpose,
two techniques will be evaluated:• the ﬁrst will be token based and will rely on the useof the tool CCFinder;• the second will use a Program Dependence Graph andwill borrow, and eventually tailor to our speciﬁc needs, thealgorithm outlined in [14].
The identiﬁcation process can be split in 2 steps:
Step 1 Let n be the total number of cross-cut unit sets.
X
For each of the n cross-cut unit set Cm
X (i = 0, 1, . . . , n),iperform a code clone analysis with targets all the methods
X
CLON E
of codem ∈ Cm
X . The result of this step is the set Cm,mXiclones contained in the body of the method m;
Step 2 Compute the complete set of code clones for eachmethod m0 as:
CLON E=
Cmn∪

CLON E
Cm,m
X
i

i=0

3. 3 Pruning the clone sets
The result of the preceding step are nm code clone sets
CLON E
with nm being the number of methods in the tarCm
get code base. We can expect that a code clone set may
contain code clones that are not cross-cut by any of the mXiand, for this reason, of no interest to us. Hence, from each of
CLON E
we remove those code clones
the nm code clone set Cmthat don’t comprise a call of a method mX
i for some i in
{0, 1, . . . , n}.
3. 4 Classifying the aspect candidates
Aspect candidates, that is, code clones that don’t present
data dependencies with the surrounding code are obviously
more easy to refactor than code that has data dependencies.
Candidates can then be ranked proportionally to the numberof dependencies, with rank 0 being the highest rank.
More speciﬁcally, data dependencies can be of two kinds:• dependencies to some data outside the clone (outgoingdependencies);• dependencies from some data outside the clone(incoming-dependencies).
Outgoing dependencies are less strict than incoming dependencies, and this can be expressed assigning a weight wO
to each outgoing dependency, and a weight wI to each incoming dependency, with wI À wO . Let nIc and nO
c be thenumber of incoming dependencies and the number of outgoing dependencies respectively of a code clone c, the rank r of—3—

c can be computed as:r(c) = nIc wI + nO
c wO

[14] J. Krinke, “Identifying similar code with program dependence graphs,” Proc. Eigth Working Conference on Reverse
Engineering, pp.301–309, 2001.

The result of this step is an ordered list of code clones
c0 , c1 , . . . cn with r(c0 ) <= r(c1 ) <= ... <= r(cn )Clones at the head of the list are considered better candidates for an aspect-oriented refactoring.

4. Conclusion
This short paper presented a tentative approach at automating the mining of aspects in existing software systems.
While we are conﬁdent of the soundness of the approach,at the time of writing there are no experimental data forvalidating it. Some questions can be answered only after
thoroughly experimentation:• what is the percentage of false positives?
• what is the percentage of false negatives?
• what are the performance of the approach in terms oftime and memory usage?
文献[1] P.L. Tarr, H. Ossher, W.H. Harrison, and S.M.S. Jr., “N
degrees of separation: Multi-dimensional separation of concerns,” Proceedings of the International Conference on Software Engineering, pp.107–119, 1999.
[2] G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda,
C. Lopes, J.M. Loingtier, and J. Irwin, “Aspect-oriented
programming,” Proceedings of the European Conference on
Object-Oriented Programming, ed. M. Akşit and S. Matsuoka, Berlin, Heidelberg, and New York, pp.220–242,
Springer-Verlag, 1997.
[3] AspectJ-Team, “The aspectj programming guide.”[4] P. Tarr, H. Ossher, V. Kruskal, and M. Kaplan, “The hyperj
homepage.” http://www.alphaworks.ibm.com/tech/hyperj.
[5] W. Harrison and H. Ossher, “Subject-oriented programming: a critique of pure objects,” Proceedings of the Conference on Object Oriented Programming Systems Languages
and Applications, pp.411–428, 1993.
[6] J. Bonzr and A. Vasseur, “The aspectwerkz homepage.”
http://aspectwerkz.codehaus.org.
[7] J. Hannemann and G. Kiczales, “Overcoming the prevalentdecomposition of legacy code,” Proceedings of the Workshop on Advanced Separation of Concerns, 2001.
[8] M.P. Robillard and G.C. Murphy, “Concern graphs: ﬁnding and describing concerns using structural program dependencies,” Proceedings of the International Conference
on Software Engineering.
[9] C. Zhang and H.A. Jacobsen, “A prism for research insoftware modularization through aspect mining.” Technical Communications, Middleware System Research Group,
University of Toronto, September 2003.
[10] S. Breu and J. Krinke, “Aspect mining using event traces,”
Proceedings of the 19th Conference on Automated Software
Engineering, IEEE Press, 2004.
[11] D. Shepherd, L. Pollock, and E. Gibson, “Design and evaluation of an automated aspect mining tool,” Proceeding of
the International Conference on Software Engineering Research and Practice, 2004.
[12] T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: A
multi-linguistic token-based code clone detection system forlarge scale source code,” IEEE Transactions on Software
Engineering, vol.28, pp.654–670, July 2002.
[13] M. Marin, A.v. Deursen, and L. Moonen, “Identifying
aspects using fan-in analysis,” Proceedings of the 11th
Working Conference on Reverse Engineering (WCRE2004).,
pp.132–141, IEEE Computer Society, 2004.

—4—