Transcript IVCon: A GUI-Based Tool for Visualizing and Modularizing

IVCon: A GUI-based Tool for
Visualizing and Modularizing
Crosscutting Concerns
Nalin Saigal, Jay Ligatti
1/46
Introduction
Code modularization provides softwareengineering benefits
 Modularizing code helps separate
different functionalities of software from
one another

2/46
More Specifically…
GUI
Modularize
Security
Authentication
Networking



All the code implementing one functionality, which
otherwise might be scattered, gets organized into
the same module, e.g., function, class, package, or
aspect
The programmer can deal with all invariants of one
functionality in one place
This makes code easier to write, locate, understand,
3/46
and maintain
Stack Example
int stack[MAX_SIZE];
int size = 0;
...
//Pushing a onto stack
stack[size] = a;
size++;
//Pushing b onto stack
stack[size] = b;
size++;

We can
modularize the
operations being
performed here by
defining a class
called stack.
//Popping b
size--;
int a1 = stack[size];
//Popping a
size--;
int a2 = stack[size];
...
4/46
Stack Example
...
class stack
{
my_stack.push(a);
int a[MAX_SIZE];
my_stack.push(b);
int size = 0;
int a1 = my_stack.pop();
void push(int data)
int a2 = my_stack.pop();
stack[size] = data;
...
size++;
{
}
Application developer’s code
Modularized stack
implementation
int pop()
{
size--;
return stack[size];
}
}my_stack;


An application developer does not need to know how
the stack is implemented
We can make changes to the stack implementation
without even letting the application developer know
5/46
Stack Example
...
class stack
{
my_stack.push(a);
int a[MAX_SIZE];
my_stack.push(b);
int size = 0;
int a1 = my_stack.pop();
void push(int data)
int a2 = my_stack.pop();
{
if (size == MAX_SIZE–1)
printErr(“Overflow”);
...
stack[size] = data;
size++;
Observe that code
written by the
application developer
doesn’t change
}
int pop()
{
if (size == 0)
printErr(“Underflow”);
size--;
return stack[size];
}
}my_stack;
6/46
Problem



Conventionally, software engineers try to separate code
segments that are orthogonal in their functionality into
distinct modules
In practice, this doesn’t happen
Example
 This code implements login, security, GUI, and
authentication concerns:
JOptionPane.showMessageDialog(null,“Login Attempt
Failed.”,“Error”,JOptionPane.ERROR_MESSAGE);


Which module out of login, security, GUI, and
authentication should this code be present in?
Peri Tarr et al. call this problem the “tyranny of
dominant decomposition”
7/46
Converse Problem
Previous problem: one code segment may
implement many concerns
 Converse problem: one concern may be
implemented by many code segments
(i.e., the concern is scattered)
 If the code implementing C is scattered
throughout code implementing other
concerns, we say that C crosscuts
through other functional concerns

8/46
Example
String passWord
=(String)JOptionPane.showInputDialog(...);
boolean allow = this.authenticate(passWord);
File file = new File(“output.log”);
if (allow)
{
file.write(“Access granted.”);
file.close();
else
}
{
file.write(“Access Denied”);
file.close();
return;


}
The security concern crosscuts the rest of
the code
Therefore, the security concern is called a
CrossCutting Concern (CCC).
9/46
Example

A security engineer
would have to go
through the whole
program to locate
code that
implements security

However, if code is
isolated, the security
engineer only needs
to locate the security
module
Security
10/46
IVCon (Inline Visualization of Concerns)
GUI-based tool to modularize CCCs.
 Users can switch back and forth between
two equivalent views of their code:

 Woven view
 Unwoven view

Users can also edit code in both these
views
11/46
1. Woven view: Displays program code in colors
that indicate which concerns various code
segments implement
12/46
2. Unwoven view: Displays code in two panels,
one showing the core of the program, and the
other showing all the modularized concerns
(each displayed in isolation)
13/46
IVCon Feature: Relationships between
Concerns and Code

Users can assign scattered code to the same concern

The same code can be assigned to multiple concerns

IVCon allows users to define many-to-many relationships
between concerns and code
14/46
Another IVCon Feature: Concernassignment Granularity

IVCon enforces token-level granularity in
concern assignments
Code assigned to a concern must begin
and end at the beginning and ending of
language-level tokens
accessLog.append("About to read from file “ + this.toString());
accessLog.append("About to read from file “ + this.toString());
accessLog.append("About to read from file “ + this.toString());
accessLog.append("About to read from file “ + this.toString());
accessLog.append("About to read from file “ + this.toString());
15/46
Motivation for Token-level Granularity

Finer granularity levels are inappropriate
because tokens are the core semantic
units of programming languages
 It won’t make sense to start concerns from
the middle of a token

Coarser granularity in concern
assignment would reduce precision in
concern assignments
16/46
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view

Implementation
 Data structures
 Performance Evaluation

Conclusion and Future Work
17/46
Related Work
IVCon relates most closely to Aspectoriented programming (AOP) and aspectvisualization tools
 AOP strives to ease the specification and
manipulation of CCCs in software
 AOPLs use aspects to do so

Aspect
Advice
Code that
implements CCCs
Joinpoints
Locations in program
where the advice
should be executed
18/46
Related Work: AOPLs

Typical Aspect-oriented program:
Aspects
AOPL
Compiler
Core
program
Programmer’s view
View during execution
IVCon’s unwoven view corresponds to a
programmer’s view of an aspect-oriented
program
 IVCon’s woven view corresponds to the
runtime view of the aspect-oriented program

19/46
Related Work: Aspect-visualization
Tools

Unlike existing tools, IVCon does all of
the following:
 Provides dual views (woven and unwoven) of
user code
 Enforces token-level granularity in concern
assignments
 Isolates concerns into modules
 Enables users to define many-to-many
relationships between concerns and code
 Provides a GUI
20/46
Comparison of IVCon with Related
Work
Tool
Edit code
in dual
views
AspectBrowser
Relationship
between
concerns and
code
Level of
granularity
Concern
isolation
No
Characterlevel
No
One-to-many
Yes
Aspect-jEdit
Yes
Line-level
Yes
One-to-many
Yes
Visualizer
No
Line-level
No
One-to-many
Yes
CIDE
No
Nodes in
ASTs
No
Many-to-many
Yes
Hyper/J
No
Declarationlevel
Yes
Many-to-many
No
C4
Yes
Line-level
Yes
One-to-many
No
IVCon
Yes
Token-level
Yes
Many-to-many
Yes
GUI
21/46
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view

Implementation
 Data structures
 Performance Evaluation

Conclusion and Future Work
22/46
Woven View
Woven-body panel is where users
write and view their complete code.
23/46
Woven View
Concern-legend panel lists all the
concerns defined by the user
24/46
Woven View
Concerns-at-current-position panel
displays the concerns implemented
by the code at the current cursor
position.
25/46
External link to woven view movie
26/46
Other Operations in IVCon’s
Woven View
Edit concerns (name and/or color)
 De-assign concerns from code.
 Remove concerns
 Rename code regions
 Change multi-concern background

27/46
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view

Implementation
 Data structures
 Performance Evaluation

Conclusion and Future Work
28/46
Unwoven View


The concern-legend panel and the concerns-at-currentposition panel remain the same as in the woven view
The woven-body panel gets divides into two panels: the
unwoven-body panel, and the unwoven-concerns panel 29/46
Unwoven View
Unwoven-body panel displays
the core of the user’s program
i.e., code that has not been
assigned to any concerns
30/46
Unwoven view
Unwoven-concerns panel shows
each concern in an isolated module
31/46
External link to unwoven view movie
32/46
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view

Implementation
 Data structures
 Performance Evaluation

Conclusion and Future Work
33/46
Data Structures

IVCon stores information about concern
assignments in three key data structures:
 regionMap
 concernMap
 regionTree
34/46
regionMap (HashTable)
User-visible name
Unique Region
Indentifier
Beginning and
ending positions
of the region
List of concerns
to which region
has been assigned
35/46
concernMap (HashTable)
Unique
Concern Name
Concern’s
display color
List of regions
assigned to that
concern
36/46
regionTree (R-tree)




R-trees dynamically store data about
potentially overlapping regions in space.
Upon querying about a region r, an R-tree
can efficiently return the set of stored
regions that overlap r.
We use R-trees to determine the regions
that overlap the current cursor position.
From those regions, regionMap tells us the
concerns assigned to the current cursor
position.
37/46
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view

Implementation
 Data structures
 Performance Evaluation

Conclusion and Future Work
38/46
Performance Evaluation

Tested IVCon by assigning code to
concerns in three of IVCon’s source-code
files:
 IVCON.java
 FileUtilities.java
 ConcernManipulation.java

Also, created an impractically large file
(StressTest.java) of 100,000 lines,
each containing 20 randomly generated
single-character tokens
39/46
Test-file Characteristics
Total #
of
Regions
Avg
Region
Size
(chars)
Max
Region
Size
(chars)
File Name
File Size
(LoC)
Total #
of
Concerns
IVCON.java
49
5
7
135.9
337
FileUtilities.java
313
11
25
155.7
788
ConcernManipulation.java
3,342
36
182
269.9
3,461
StressTest.java
100,000
1,000
5,000
1,016
1,996

Measured time taken for the following
operations: assign code to a concern, edit a
concern, remove a concern, weaving, and
unweaving
40/46
Performance Evaluation
File Name
Assign
Code
Edit a
to a
Concern
Concern
(ms)
(ms)
Remove a
Concern
(ms)
Weaving
(ms)
Unweaving
(ms)
IVCON.java
17.35
5.31
7.02
20.7
4.37
FileUtilities.java
50.58
14.49
20.58
88.71
21.7
ConcernManipulation.java
519.1
30
84.02
566.8
501.9
StressTest.java
312,519
2,276
3,742
465,000
481,737

IVCon performed all operations tolerably
quickly on reasonably-sized files.
41/46
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view

Implementation
 Data structures
 Performance Evaluation

Conclusion and Future Work
42/46
Conclusion
IVCon attempts to help users conveniently
create, examine, and modify code in the presence
of crosscutting concerns
 IVCon differs from existing aspect-visualization
tools by providing a combination of:

Translations between woven and unwoven views
Token-level granularity in concern assignment
Isolation of concerns into distinct modules
Many-to-many relationships between concerns and
code
 GUI designed to make all of the above convenient




43/46
Future Work
Case study: Test IVCon’s usability by
using IVCon to extend IVCon
 New features to add in case study

 Search for text in code (ctrl-f)
 Handle multiple source-code files
simultaneously
 Display flags in the woven view
 Use tooltips to display concerns implemented
by the code at the current cursor position
44/46
Thanks/Questions?
45/46
References
[1] C. Kastner. CIDE: Decomposing legacy applications into features. In Proceedings of
the 11th International Software Product Line Conference (SPLC), second volume
(Demonstration), pages 149–150, 2007.
[2] H. Ossher and P. Tarr. Hyper/J: Multi-dimensional separation of concerns for Java. In
Proceedings of the International Conference on Software Engineering, pages 734–737,
2000.
[3] T. Panas, J. Karlsson, and M. Hogberg. Aspect-jEdit for inline aspect support. In
Proceedings of the Third German Workshop on Aspect Oriented Software Development,
2003.
[4] M. Shonle, J. Neddenriep, andW. Griswold. AspectBrowser for eclipse: A case study in
plug-in retargeting. In Proceedings of the 2004 OOPSLA workshop on eclipse technology
eXchange, pages 78–82, 2004.
[5] The Visualiser, 2008. http://www.eclipse.org/ajdt/visualiser/.
[6] M.Yuen, M. E. Fiuczynski, R. Grimm, Y. Coady, and D. Walker. Making extensibility of
system software practical with the C4 toolkit. In Proceedings of the Workshop on
Software Engineering Properties of Languages and Aspect Technologies, March 2006.
46/46