Inline Visualization of Concerns
Nalin Saigal, Jay Ligatti
Department of Computer Science and Engineering,
University of South Florida
1/56
Introduction
Code modularization provides softwareengineering benefits
 Modularizing code helps separate
different functionalities of software from
one another

2/56
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/56
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/56
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/56
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/56
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/56
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/56
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/56
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/56
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/56
1. Woven view: Displays program code in colors
that indicate which concerns various code
segments implement
12/56
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/56
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/56
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/56
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
 IVCon is the first concern-management tool we
know of that enforces token-level granularity

Coarser granularity in concern assignment
would reduce precision in concern
assignments
16/56
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view
 Display of Multi-concern code

Implementation
 Data structures
 Performance evaluation

Conclusion and Future Work
17/56
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/56
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/56
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
 Enables users to modify identical concern-code in
one place
 Isolates concerns into modules
 Enables users to define many-to-many
relationships between concerns and code
 Provides a GUI
20/56
Comparison of IVCon with Related
Work
Tool
Edit
code
in
dual
views
AspectBrowser
No
Characterlevel
No
No
One-to-many
Yes
Aspect-jEdit
Yes
Line-level
No
Yes
One-to-many
Yes
Visualizer
No
Line-level
No
No
One-to-many
Yes
CIDE
No
Nodes in
ASTs
No
No
Many-to-many
Yes
Hyper/J
No
Declarationlevel
No
Yes
Many-to-many
No
C4
Yes
Line-level
No
Yes
One-to-many
No
IVCon
Yes
Token-level
Yes
Yes
Many-to-many
Yes
Level of
granularity
Modify
identical
concern
code in
one place
Isolates
concerns
Relationship
between
concerns and
code
GUI
21/56
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view
 Display of Multi-concern code

Implementation
 Data structures
 Performance evaluation

Conclusion and Future Work
22/56
Woven View
Woven-body panel is where users
write and view their complete code.
23/56
Woven View
Concern-legend panel lists all the
concerns defined by the user
24/56
Woven View
Concerns-at-current-position panel
displays the concerns implemented
by the code at the current cursor
position.
25/56
Woven View

Users explicitly assign code to concerns
 Each time users assigns code to a concern,
they define a region
 Code gets displayed in color of the concern it
implements
 If code implements multiple concerns, it’s
displayed in white text over a multi-concern
background

Users can edit code, including concern
code, without restrictions
26/56
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/56
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view
 Display of Multi-concern code

Implementation
 Data structures
 Performance evaluation

Conclusion and Future Work
28/56
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/56
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/56
Unwoven View
Unwoven-concerns panel shows
each concern in an isolated module
31/56
Concern Modules
Concern modules
display various
code segments
that implement a
concern along
with the names of
the regions where
they appear
32/56
Concern Modules
Concern modules
can also contain
constructs called
Flags, which are
used to indicate
overlap between
concerns
33/56
Centralized Code Updates
Syntactically equal code assigned to the
same concern gets displayed only once in
the unwoven-concerns panel
 Enables users to modify syntactically equal
code segments centrally

34/56
Centralized Code Updates - Example
if (buffer.getSize() > 512)
buffer.truncate(512);
if (getTimeElapsed() > 2000)
JOptionPane.showMessageDialog(frame,
"Request timed out","Error",
JOptionPane.ERROR_MESSAGE);
Unweave
if (buffer.getSize() > □)
buffer.truncate(□);
if (getTimeElapsed() > □)
JOptionPane.showMessageDialog(frame,
"Request timed
out","Error",
JOptionPane.ERROR_MESSAGE);
concern constant
{
subconcern @ max_buffer_size_0
@ max_buffer_size_1
§
512
§
subconcern @ timeout_ms_0
§
2000
§
}
35/56
Centralized Code Updates - Example
if (buffer.getSize() > 1024)
buffer.truncate(1024);
if (getTimeElapsed() > 2000)
JOptionPane.showMessageDialog(frame,
"Request timed out","Error",
JOptionPane.ERROR_MESSAGE);
Weave
if (buffer.getSize() > □)
buffer.truncate(□);
if (getTimeElapsed() > □)
JOptionPane.showMessageDialog(frame,
"Request timed
out","Error",
JOptionPane.ERROR_MESSAGE);
concern constant
{
subconcern @ max_buffer_size_0
@ max_buffer_size_1
§
1024
§
subconcern @ timeout_ms_0
§
2000
§
}
36/56
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view
 Display of Multi-concern code

Implementation
 Data structures
 Performance evaluation

Conclusion and Future Work
37/56
Display of Multi-concern Code: Woven view
Displayed in white text over multiconcern background
 Concern information is present in
concerns-at-current-position panel

38/56
Display of Multi-concern Code: Unwoven view
Unwoven-body panel uses white holes(□)
over the multi-concern background
 Unwoven-concerns panel uses Flags

 Appear when there is overlap between two
concerns
 Two types of flags: Green Flags and Red Flags
 Green flags indicate the beginning of nested
concerns
 Red flags indicate the end of nested concerns
39/56
Flags – An Example
We assign all this code to the security concern
40/56
Flags – An Example
We assign the two accessLog.append(..) statements
to the audit concern
41/56
Flags – An Example
42/56
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view
 Display of Multi-concern code

Implementation
 Data structures
 Performance evaluation

Conclusion and Future Work
43/56
Data Structures

IVCon stores information about concern
assignments in three key data structures:
 regionMap
 concernMap
 regionTree
44/56
regionMap (HashTable)
User-visible name
Unique Region
Indentifier
Beginning and
ending positions
of the region
List of concerns
to which region
has been assigned
45/56
concernMap (HashTable)
Unique
Concern Name
Concern’s
display color
List of regions
assigned to that
concern
46/56
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.
47/56
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view
 Display of Multi-concern code

Implementation
 Data structures
 Performance evaluation

Conclusion and Future Work
48/56
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
49/56
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
50/56
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.
51/56
Outline

Introduction
 Motivation
 Related work

User Interface
 Woven view
 Unwoven view
 Display of Multi-concern code

Implementation
 Data structures
 Performance evaluation

Conclusion and Future Work
52/56
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
 Central code-updates for syntactically equal code
segments
 Isolation of concerns into distinct modules
 Many-to-many relationships between concerns and
code
 GUI designed to make all of the above convenient
53/56
Future Work
Case study: Gain experience using IVCon
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
54/56
Thanks/Questions?
55/56
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.
56/56