Upload
bat
View
38
Download
0
Embed Size (px)
DESCRIPTION
Reishi Yokomori Nanzan University, Japan Harvey Siy University of Nebraska at Omaha, USA Norihiro Yoshida Nara Institute of Science and Technology, Japan Masami Noro Nanzan University, Japan Katsuro Inoue Osaka University, Japan. - PowerPoint PPT Presentation
Citation preview
MEASURING THE EFFECTS OF ASPECT ORIENTED REFACTORING ON COMPONENT RELATIONSHIPS: TWO CASE STUDIES
Reishi Yokomori Nanzan University, Japan Harvey Siy University of Nebraska at Omaha, USA Norihiro Yoshida Nara Institute of Science and Technology, Japan Masami Noro Nanzan University, Japan Katsuro Inoue Osaka University, Japan
BACKGROUND Many software are maintained under a
cycle of incremental development. After each feature-addition, readability and
maintainability of the software can deteriorate.
Refactoring has become one of the essential activities in development of large software systems.
REFACTORING Refactoring improves software’s internal
structure without changing external behavior.
Refactoring is a suite of activities for Recovery of readability and maintainability,
etc. Preparation for future extensions.
Many approaches are suggested to perform the refactoring.
ASPECT-ORIENTED REFACTORING Extracting several features from existing
system into aspects. Features implemented in a crosscutting manner
would be separated from the structure of the base code.
These features are treated as aspects. Expected results
We can manage cross-cutting codein one aspect (or in one package).
We can manage a set of such features just before building it into the structure of the base code.
THE PURPOSE OF OUR STUDY We would like to investigate that
“How relationship between components changes through the aspect-oriented refactoring ?”
Q1 Is aspect-oriented refactoring effective for improving modularity and complexity?
Q2 What are the characteristics of classes likely to be strongly affected by such refactoring activities?
ACTUAL APPROACHES Study: Refactoring projects that use AspectJ
Inputs: software written in Java. Outputs:
Java programs as a base program Features are extracted as aspects from the base.
Aspects that describe about the extracted features. Code fragments and information for embedding.
We compare refactored programs against original ones from the perspective of use and clone relations.
THE PURPOSE OF OUR STUDY We would like to investigate that
“How relationship between components changes through the aspect-oriented refactoring ?”
Q1 Is aspect-oriented refactoring effective for improving modularity and complexity? Q1-1: between classes? Q1-2: between classes and aspects?
Q2 What are the characteristics of classes likely to be strongly affected by such refactoring activities? Q2-1: from the perspective of use relations? Q2-2: from the perspective of clone relations?
RELATIONSHIP BETWEEN COMPONENTS Use Relation (directed edge)
We used SPARS-J ‘s component registration. Use relation is used for navigating from search result.
Extracted Use Relation inheritance, implementation of abstract class and interface, declaration of variables, creation of instances, method calls, and class attribute references.
Clone Relation (undirected edge)
MEANING OF USE RELATION FROM A PERSPECTIVE OF PROGRAM-UNDERSTANDING
From class A Relations are used for
understanding how the class A performs.
To class A Relations are used for
understanding how the class A is used.
Class A
class
class
class
class
USE RELATION FROM CLASSES TO ASPECTS
We defined use relationbetween class & aspect. From class to aspect
Class A uses code defined in Aspect B
To understand A’s behavior, advices in Aspect B are necessary.
How does code in Class A spread into aspects?Class
AAspect
B
Weaves advices
Class A
Aspect B
USE RELATION FROM ASPECTS TO CLASSES
We defined use relationbetween class & aspect. From aspect to class
Advices woven by C uses Class A.
To understand how class A is used, advices in Aspect C are necessary.
How does usage of Class A spread into aspects?
Class A
Aspect C
Weaves
advices
Class A
Aspect C
Advice
CLONE RELATION Use Relation (directed edge) Clone Relation (undirected edge)
If class A and B have similar code fragments,there is a clone relation between A and B.
We detected clone relation by using CCFinder. Similar code fragments more than 25 tokens
Advices in each aspect are also analyzed. Clone relation between classes and aspects.
EXPERIMENTS: Target Refactoring Projects
AJHotDraw Aspectized Berkeley DB
AJHOTDRAW PROJECT JHotDraw : a Java-based GUI framework
for technical and structured graphics. The AJHotDraw project was formed to
identify and evaluate template-based solutions for refactoring object-oriented into aspect-oriented code. JHotDraw6.0 → AJHotDraw Ver. 0.2, 0.3 and
0.4.
AJHOTDRAW ( VER 0.2 ) A lot of read() & write() methods are
extracted from Figure-related classes. From a base program, some use-relations
and clone-relations are extracted. Most of extracted codes became advices in
aspect.
Text Area Figure
PertFigure
Clone relation
Ellipse Figure
Round Rectangle
Figure
Rectangle Figure
Text Figure
Image Figure
Composite Figure
Arrow Trip Draw Application
Poly LineFigure
not changed clone relation
removed clone relation modified components
Text Area Figure
PertFigure
Classes and Aspects
Ellipse Figure
Round Rectangle
Figure
Rectangle Figure
Text Figure
PersistentImageFigure
.aj
Composite Figure
Arrow Trip Draw Application
Poly LineFigure
unchanged clone relation clone between class and
aspect created aspects
PersistentText
Figure.aj
PersistentComposite Figure.aj
Image Figure
AJHOTDRAW ( VER 0.2 ) In Ver. 0.2, there are clone relations
between advices in aspects and classes in base program. There are 37 classes that have read() & write()
methods. However, developers extracted from only 5 classes.
Clone relations between classes moved into the ones between classes and aspects.
Only a part of similar code fragments are extracted as aspect.
AJHOTDRAW ( VER 0.3 ) Mainly, aspects superimposing an observer
pattern used for notifying and handling changes in selecting figures are added. Use relations to FigureSelectionListener are
extracted. Method call statements for its super-class are
eliminated. Manifested on 7 similar XXX-Command classes. Clone relations are decomposed.
They were strongly connected by clone relations in ver.02.
AJHOTDRAW ( VER 0.4 ) Features related Undo are extracted.
From several XXX-Command classes. Inner classes about Undo are also extracted by
aspects. Clone relations existed in the Undo feature.
Undo related Use & Clone relations are extracted. Most of extracted codes became advices.
However, clone relations exist between class and aspect. Only 7 of 26 inner-classes are extracted.
Only a part of similar code fragments are extracted as aspect. (The same as in the case of ver.0.2.)
Original Program
Connection Tool
PasteCommand Border
Tool
Text ToolJHD DragSource Listener
Select AllCommand
not changed clone relation
removed from base code modified components
Un GroupCommand
GroupCommandSend To
BackCommandBring To
FrontCommand
Change Attribute
Command
Undoable Adapter
Connected Text Tool
Cut CommandDelete
Command
Pert FigureAbstract
CommandAbstract Tool
Undoable Handle Undoable
CommandUndoable Tool
Align Command
Text Area Tool
Composite Figure
After refactoring
Connection Tool
PasteCommand Border
Tool
Text ToolJHD DragSource Listener
Select AllCommand
not changed clone relation
removed from base code modified components
Un GroupCommand
GroupCommandSend To
BackCommandBring To
FrontCommand
Change Attribute
Command
Undoable Adapter
Connected Text Tool
Cut CommandDelete
Command
Pert FigureAbstract
CommandAbstract Tool
Undoable Handle Undoable
CommandUndoable Tool
Align Command
Text Area Tool
Composite Figure
Classes and Aspects
Connection Tool
Paste Command Undo Border Tool
Text ToolJHD Drag
Source Listener
Select AllCommand
Un GroupCommand
Group Command UndoSend To Back
Command
Bring To FrontCommand
Undoable Adapter
Connected Text Tool
Cut CommandUndoDelete Command
Undo
Pert FigureCommandObserverAbstract Tool
Undoable Handle Undoable
CommandUndoable Tool
Text Area Tool
Composite Figure
unchanged clone relation clone between class and aspect created aspects disappeared relation
Align CommandAlign Command
Change AttributeChange Attribute
ASPECTIZED BERKELEY DB Several features are extracted to aspects.
107 aspects in 28 packages are extracted. Java base classes and related aspects are public. ABDB or ABDB with aspects
From publicly available versions, we select Berkeley DB Ver.2.1.30 as an original program. Most similar to the refactored one(ABDB). Some packages in BDB don’t exist in ABDB.
We removed them for comparison.
CHANGES IN USE RELATIONS (1/3) Considering only classes between BDB and ABDB.
Node(# of classes) : 331→336 Use Relation: 1977→1681 ( 15 % decrease )
Statistical analysis: Incoming edge: BDB > ABDB Outgoing edge: BDB > ABDB The reduction in relations is statistically
significant. Affected classes
Outgoing edge: classes that use the extracted features
Environment, Tree, Database Incoming edge: classes that control the extracted
features MemoryBudget, Latch, Transaction
CHANGES IN USE RELATIONS (2/3) Considering relations from/to aspects
From class to aspect The aspect weaves to the class.
From aspect to class Advices in the aspect uses the class.
Statistical analysis: Outgoing edges: BDB≒ ABDB + edges to aspects
The center of distribution of increasing / decreasing is around 0.
The extraction seems to be done by proper number of aspects.
Incoming edges: BDB < ABDB+ edges from aspects The center of distribution of increasing / decreasing is over 0.
CHANGES IN USE RELATIONS (3/3) Incoming edges: BDB < ABDB+edges from aspects
Classes related with extracted feature decreases its incoming edge, even if aspect is taken into account for.
Some classes are used a lot of times in aspects. Example : DababaseException : 81 / 107 aspects
Developers have to use an unified exception class because of constraints of AspectJ.
Example 2 : EnvironmentImpl : 60 / 107 aspects Developers uses this for parameter passing
in a lot of method calls. Use relations to these classes are not separated clearly.
Some of them move to the created aspect. The others still remain in the base program.
CHANGES IN CLONE RELATIONS Comparing clone relations between BDB and
ABDB. Inside of classes
Node (# of .java files) : 277 → 282 Clone Relations : 365 → 158
218 decreased, 11 newly added Between classes and aspects: 0 → 35
We cannot find any significant clones in them. Between aspects : 0 → 46
This refactoring was very effective from the perspective of clone removal.
DISCUSSION Q1-1,2: Is aspect-oriented refactoring effective for
improving modularity and complexity? A1-1: Considering only classes, aspect-refactoring
decreases complexities between components. A1-2: If edges from / to aspects are accounted for, in
many cases, total complexity seems to be preserved. We can say the same thing for AJHotDraw. However, certain classes show drastic increase in
incoming use relations. Such classes are global resources of the system. It arises if a scale of refactoring’s scope becomes
large. For such classes, it becomes more difficult to understand
how these classes are used.
DISCUSSION AQ1-2: Clone relations may spread also
into aspects. In some cases, we cannot avoid the situation that
produces clone relations between aspects. For future maintenance, clone between aspects
is better than clone between class and aspect. Clone between class and aspect occurs when the
scope considered for refactoring is too small. In the case of AJHotDraw, developers interest
about a scope of refactoring would be different. Can we define minimum scope of refactoring from
a distribution of clone? The scale of the scope becomes easily too
large.
DISCUSSION Q2:What are the characteristics of classes
likely to be strongly affected by such refactoring activities? A2-1: from the perspective of use
relations. Classes related to the extracted features
API related classes, Manager classes, Impl classes Implementing the feature, using the feature.
A2-2: from the perspective of clone relations.
Inner-class, pre-processing or post-processing code of the extracted feature.
DISCUSSION AQ1: Aspect refactoring seems to be
effective, however, it seems difficult to complete it. It is hard to decide the proper scope of refactoring.
If the scale is too small, it produces clones between classes and aspects.
If the scale is defined by a distribution of clone, the scope may be too large.
Hybrid approach seems to be effective. Use OO refactoring to decrease the number of clones. Then use aspect refactoring to separate features
implemented in a crosscutting manner.
CONCLUSION We examined the effectiveness of aspect-oriented
refactoring with respect to changes in component relations. Use relations Clone relations
We applied to AJHotDraw and ABDB. Complexity of base classes alone decreases. Total complexity of the system seems to be almost the
same. For some classes, complexity increases.
propagation of use relations for a certain set of classes. propagation of clone relations into aspects.
CONCLUSION For aspect refactoring, we need effort both
to identify the proper scope of refactoring, and to make the scope as small as possible.
Aspect refactoring seems to be effective but to be difficult also; prior preparations before refactoring is important. Collaboration between aspect refactoring experts and
experts of the target system is most important.
FUTURE WORKS Application to another project.
To support generality. To get new insights.
Further analysis to AJHotDraw and ABDB Component Rank analysis – examine indirect
relationships. Tool for analysis
“Use relations between classes” and “clone relations” are almost automatically collected by existing systems.
Use relation related with aspects and overall comparison is done by manually.
THANK YOU FOR YOUR ATTENTION