Inline Visualization of Concerns Nalin Saigal, Jay Ligatti Department of Computer Science and Engineering, University of South Florida 1/56.

Inline Visualization of Inline Visualization of ConcernsConcerns

Nalin Saigal, Jay Ligatti

Department of Computer Science and Engineering,

University of South Florida

1/56

IntroductionIntroductionCode modularization provides

software-engineering benefitsModularizing code helps separate

different functionalities of software from one another

2/56

More Specifically…More Specifically…

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, and maintain

GUI

Security

Authentication

Networking

Modularize

3/56

Stack ExampleStack Exampleint stack[MAX_SIZE];

int size = 0;

...

//Pushing a onto stack

stack[size] = a;

size++;

//Pushing b onto stack

stack[size] = b;

size++;

//Popping b

size--;

int a1 = stack[size];

//Popping a

size--;

int a2 = stack[size];

...

We can modularize the operations being performed here by defining a class called stack.

4/56

Stack ExampleStack Exampleclass stack {

int a[MAX_SIZE];

int size = 0;

void push(int data) {

stack[size] = data;

size++;

}

int pop() {

size--;

return stack[size];

}

}my_stack;

...

my_stack.push(a);

my_stack.push(b);

int a1 = my_stack.pop();


...

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

Modularized stack implementation

Application developer’s code

5/56

Stack ExampleStack Exampleclass stack {

int a[MAX_SIZE];

int size = 0;

void push(int data) {

if (size == MAX_SIZE–1)

printErr(“Overflow”);

stack[size] = data;

size++;

}

int pop() {

if (size == 0)

printErr(“Underflow”);

size--;

return stack[size];

}

}my_stack;

...

my_stack.push(a);

my_stack.push(b);



...

Observe that code written by the application developer doesn’t change

6/56

ProblemProblemConventionally, software engineers try to

separate code segments that are orthogonal in their functionality into distinct modules

In practice, this doesn’t happenExample

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 ProblemConverse ProblemPrevious problem: one code segment

may implement many concernsConverse 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

ExampleExampleString 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

ExampleExampleA 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 (IVCon (IInline nline VVisualization of isualization of ConConcerns)cerns)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 IVCon Feature: Relationships between Concerns and Codebetween Concerns and CodeUsers 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: Another IVCon Feature: Concern-assignment Concern-assignment GranularityGranularityIVCon enforces token-level

granularity in concern assignmentsCode 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());15/56

Motivation for Token-level Motivation for Token-level GranularityGranularity

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

OutlineOutlineIntroduction

Motivation Related work

User Interface Woven view Unwoven view Display of Multi-concern code

Implementation Data structures Performance evaluation

Conclusion and Future Work17/56

Related WorkRelated WorkIVCon relates most closely to

Aspect-oriented programming (AOP) and aspect-visualization tools

AOP strives to ease the specification and manipulation of CCCs in software

AOPLs use aspects to do soAspect Advice

Code that implements CCCs

Joinpoints

Locations in programwhere the advice

should be executed18/56

Related Work: AOPLsRelated Work: AOPLsTypical Aspect-oriented program:

Aspects

Core progra

m

Programmer’s view View during execution

AOPLCompiler

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-Related Work: Aspect-visualization Toolsvisualization ToolsUnlike 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 GUI20/56

Comparison of IVCon with Comparison of IVCon with Related WorkRelated Work

21/56






Woven ViewWoven View

Woven-body panel is where users

write and view their complete code.

23/56


Concern-legend panel lists all the

concerns defined by the user

24/56


Concerns-at-current-position panel displays the concerns implemented by the code at the current cursor position.

25/56

26/56

Woven ViewWoven ViewUsers explicitly assign code to

concernsEach time users assigns code to a

concern, they define a regionCode gets displayed in color of the

concern it implementsIf code implements multiple

concerns, it’s displayed in white text over a multi-concern background

Users can edit code, including concern code, without restrictions

Other Operations in IVCon’s Other Operations in IVCon’s Woven ViewWoven ViewEdit concerns (name and/or

color)De-assign concerns from code.Remove concernsRename code regionsChange multi-concern

background

27/56






Unwoven ViewUnwoven View

The concern-legend panel and the concerns-at-current-position 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-body panel displays the core of the

user’s program i.e., code that has not been assigned to any

concerns

30/56

Unwoven-concerns panel shows

each concern in an isolated module


31/56

32/56

Concern ModulesConcern ModulesConcern modules display various code segments that implement a concern along with the names of the regions where they appear

33/56

Concern ModulesConcern ModulesConcern modules can also contain constructs called Flags, which are used to indicate overlap between concerns

Centralized Code UpdatesCentralized Code UpdatesSyntactically 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 - Centralized Code Updates - ExampleExample

35/56

if (buffer.getSize() > 512) buffer.truncate(512);if (getTimeElapsed() > 2000) JOptionPane.showMessageDialog(frame, "Request timed out","Error", JOptionPane.ERROR_MESSAGE);

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 §}

Unweave

36/56

if (buffer.getSize() > 1024) buffer.truncate(1024);if (getTimeElapsed() > 2000) JOptionPane.showMessageDialog(frame, "Request timed out","Error", JOptionPane.ERROR_MESSAGE);

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 §}

Weave

Centralized Code Updates - Centralized Code Updates - ExampleExample






Display of Multi-concern Code: Woven Display of Multi-concern Code: Woven viewview

Displayed in white text over multi-concern background

Concern information is present in concerns-at-current-position panel

38/56

Display of Multi-concern Code: Display of Multi-concern Code: Unwoven viewUnwoven viewUnwoven-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

40/56

Flags – An ExampleFlags – An Example

We assign all this code to the security concern


41/56

We assign the two accessLog.append(..) statements to the audit concern


42/56






Data StructuresData StructuresIVCon stores information about

concern assignments in three key data structures: regionMap concernMap regionTree

44/56

regionMapregionMap (HashTable) (HashTable)

45/56

concernMapconcernMap (HashTable) (HashTable)

46/56

regionTreeregionTree (R-tree) (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






Performance EvaluationPerformance EvaluationTested 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 CharacteristicsTest-file Characteristics

Measured time taken for the following operations: assign code to a concern, edit a concern, remove a concern, weaving, and unweaving

50/56

Performance EvaluationPerformance Evaluation

File Name

AssignCodeto a

Concern

(ms)

Edit aConcer

n(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.java312,51

92,276 3,742

465,000

481,737IVCon performed all operations

tolerably quickly on reasonably-sized files.

51/56






ConclusionConclusionIVCon 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 WorkFuture WorkCase 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?Thanks/Questions?

55/56

ReferencesReferences

56/56

[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.

Inline Visualization of Concerns Nalin Saigal, Jay Ligatti Department of Computer Science and Engineering, University of South Florida 1/56.

Documents