![](bgc.png)
2. Selected operations at the end of a message se-
quence in the RAI set. In this case we can remove
them from the set the same as case 1
3. Selected operations are in the middle of a message
sequence in the RAI set. In this case we can divide
the RAI set into two sets (or more) by removing
selected operations from step 1.
Step 3: We deploy the RAI algorithm to the new
set of message sequences. Here, we stress the impor-
tance of maintaining the precedence of aspect execu-
tion in order to preserve the semantics of the original
object-oriented system.
6 RELATED WORK
A number of studies of software metrics such as cou-
pling and cohesion to evaluate the complexity of soft-
ware have been carried out. However, none of these
proposals directly address the calculation software
metrics at run-time in order to identify aspects.
In (Gupta and Rao, 2001), the authors measure
module cohesion in legacy software. They compared
statically calculated metrics against a program execu-
tion based approach of measuring the levels of mod-
ule cohesion. In (Mitchell and Power, 2003), the au-
thors adapt two common object-oriented metrics, cou-
pling and cohesion, and apply them at run-time. In
(Moldovan and Serban, 2006), the authors describe
a new approach in aspect mining that uses clustering
to identify the methods that have the code scattering
symptom. In this method, for a method, they consider
a large numbers of calling methods and a large num-
bers of calling classes as indications of code scatter-
ing. In order to group the best methods (candidates)
they use a vector-space model for defining the similar-
ity between methods. In (Breu and Krinke, 2004), the
authors describe an automatic dynamic aspect min-
ing approach which deploys program traces gener-
ated in different program executions. These traces
are then investigated for recurring execution patterns
based on different constraints, such as the requirement
that the patterns have to exist in a different calling
context in the program trace. In (Krinke and Breu,
2004), the authors describe an automatic static as-
pect mining approach, where the control flow graphs
of a program are investigated for recurring execu-
tions based on different constraints, such as the re-
quirement that the patterns have to exist in a differ-
ent calling context. In (Robillard and Murphy, 2002),
the authors introduce a concern graph representation
that abstracts the implementation details of a con-
cern and it makes explicit the relationships between
different elements of the concern for the purpose of
documenting and analyzing concerns. To investigate
the practical tradeoffs related to this approach, they
developed the Feature Exploration and Analysis tool
(FEAT) that allows a developer to manipulate a con-
cern representation extracted from a Java system, and
to analyze the relationships of that concern to the code
base. In (Robillard and Murphy, 2001), the authors
describe concerns based on class members. This de-
scription involves three levels of concern elements:
use of classes, use of class members, and class mem-
ber behavior elements (use of fields and classes within
method bodies). Use of classes is expressed by the
class-use production rules. The rules specify that
a concern either uses the entire class to implement
its behavior or only part of a class, as well as what
parts of the class participate in the implementation of
the particular concern. In (Bruntink, 2004), the au-
thors define certain clone class metrics that measure
known maintainability problems such as code dupli-
cation and code scattering. Subsequently, these clone
class metrics are combined into a grading scheme
designed to identify interesting clone classes for the
purpose of improving maintainability using aspects.
In (Baxter et al., 1998), the authors use an abstract
syntax tree (AST) to detect duplicated code (clones).
This technique uses parsers to first obtain a syntac-
tical representation of the source code, typically an
AST. The clone detection algorithms then search for
similar subtrees in the AST. In (Jr., 2002), the au-
thors introduce a general-purpose, multidimensional,
concern-space modeling schema that can be used to
model early-stage concerns.
7 CONCLUSION AND FUTURE
WORK
In this paper we described the theoretical component
of an approach to identifying anomalies in object-
oriented implementations based on observations of
patterns of messages in a legacy object-oriented sys-
tem. The term “anomaly” is used to refer to any phe-
nomenon that can negatively affect software quality
such as low cohesion, high coupling and crosscutting.
Our technique is based on the capture of execution
traces (paths) into a relational database in order to ex-
tract knowledge of anomalies in the system. We de-
veloped strategies to identify anomalies. In the case of
ambiguities in the presence of multiple candidate as-
pects, we deployed dynamic programming to identify
optimal solutions in order to group the strongest as-
pect candidates. We believe that our work can aid de-
velopers to find potential anomalies in object-oriented
systems. Equally, the work can aid maintainers.
For future work, we intend to provide an imple-
mentation through a case study. A tracing mecha-
nism (perhaps deploying AOP) can be used to capture
execution traces into a relational database schema.
ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES
188