1 / 46

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

IVCon : A GUI-based Tool for Visualizing and Modularizing Crosscutting Concerns. Nalin Saigal , Jay Ligatti. Introduction. Code modularization provides software-engineering benefits Modularizing code helps separate different functionalities of software from one another. More Specifically….

sveta
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related