IVCon : A GUI-based Tool for Visualizing and Modularizing Crosscutting Concerns

1. IVCon: A GUI-based Tool for Visualizing and Modularizing Crosscutting Concerns NalinSaigal, Jay Ligatti

2. Introduction • Code modularization provides software-engineering benefits • Modularizing code helps separate different functionalities of software from one another

3. 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 Modularize Security Authentication Networking

4. Stack Example • We can modularize the operations being performed here by defining a class called stack. int 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]; ...

5. Stack Example class 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(); int a2 = my_stack.pop(); ... Application developer’s code Modularized stack implementation • 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

6. Stack Example class 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); int a1 = my_stack.pop(); int a2 = my_stack.pop(); ... Observe that code written by the application developer doesn’t change

7. 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? • PeriTarr et al. call this problem the “tyranny of dominant decomposition”

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

9. 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).

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

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

12. 1. Woven view: Displays program code in colors that indicate which concerns various code segments implement

13. 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)

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

15. Another IVCon Feature: Concern-assignment 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()); X accessLog.append("About to read from file “ + this.toString()); X accessLog.append("About to read from file “ + this.toString());

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

17. Outline • Introduction • Motivation • Related work • User Interface • Woven view • Unwoven view • Implementation • Data structures • Performance Evaluation • Conclusion and Future Work

18. Aspect Advice Joinpoints Related Work • IVCon 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 so Code that implements CCCs Locations in program where the advice should be executed

19. Related Work: AOPLs • Typical Aspect-oriented program: Aspects AOPL Compiler Core program • 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 Programmer’s view View during execution

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

21. Comparison of IVCon with Related Work

22. Outline • Introduction • Motivation • Related work • User Interface • Woven view • Unwoven view • Implementation • Data structures • Performance Evaluation • Conclusion and Future Work

23. Woven View Woven-body panel is where users write and view their complete code.

24. Woven View Concern-legend panel lists all the concerns defined by the user

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

26. External link to woven view movie

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

28. Outline • Introduction • Motivation • Related work • User Interface • Woven view • Unwoven view • Implementation • Data structures • Performance Evaluation • Conclusion and Future Work

29. Unwoven 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

30. Unwoven View Unwoven-body panel displays the core of the user’s program i.e., code that has not been assigned to any concerns

31. Unwoven view Unwoven-concerns panel shows each concern in an isolated module

32. External link to unwoven view movie

33. Outline • Introduction • Motivation • Related work • User Interface • Woven view • Unwoven view • Implementation • Data structures • Performance Evaluation • Conclusion and Future Work

34. Data Structures • IVCon stores information about concern assignments in three key data structures: • regionMap • concernMap • regionTree

35. regionMap (HashTable)

36. concernMap (HashTable)

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

38. Outline • Introduction • Motivation • Related work • User Interface • Woven view • Unwoven view • Implementation • Data structures • Performance Evaluation • Conclusion and Future Work

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

40. Test-file Characteristics • Measured time taken for the following operations: assign code to a concern, edit a concern, remove a concern, weaving, and unweaving

41. Performance Evaluation • IVCon performed all operations tolerably quickly on reasonably-sized files.

42. Outline • Introduction • Motivation • Related work • User Interface • Woven view • Unwoven view • Implementation • Data structures • Performance Evaluation • Conclusion and Future Work

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

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

45. Thanks/Questions?

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.