Modularizing Crosscutting Concerns in Software

1. Modularizing Crosscutting Concerns in Software NalinSaigal

2. Joint work with Publications • Jay Ligatti • Adriana Iamnitchi • Joshua Finnis [1] Nalin Saigal and Jay Ligatti. Modularizing crosscutting, overlapping concerns with IVCon. Journal of Computer Science and Technology. In submission. [2] Joshua Finnis, Nalin Saigal, Adriana Iamnitchi, and Jay Ligatti. A location-based policy-specification language for mobile devices. Pervasive and Mobile Computing Journal. In press. [3] Nalin Saigal and Jay Ligatti. Inline visualization of concerns. In Proceedings of the International Conference on Software Engineering Research, Management, and Applications, 2009. [4] Jay Ligatti, Billy Rickey, and Nalin Saigal. LoPSiL: A location-based policy-specification language. In International ICST Conference on Security and Privacy in Mobile Information and Communication Systems (MobiSec), June 2009.

3. Software Development Lifecycle • Design • Create a structure for the software • Implement • Write code for the software • Test • Ensure it works correctly

4. Software Development Lifecycle • Design • Create a structure for the software • Organize software’s functionality into various modules • Final software is modularized.

5. Code Modularization The practice of organizing code into modules Helps separate different functionalities of software from one another

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

7. 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]; ...

8. Stack Example ... 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 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;

9. Stack Example ... 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 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;

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

11. Crosscutting Concerns • 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

12. Example • The security concern crosscuts the rest of the code • Therefore, the security concern is called a CrossCutting Concern (CCC). 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; }

13. Example • However, if code is isolated, the security engineer only needs to locate the security module Security A security engineer would have to go through the whole program to locate code that implements security

14. Refactoring *Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999 • Restructuring code to improve readability, without changing its functionality • An iterative process • Martin Fowler mentions 72 refactoring techniques in his book* • For example: • Extract into Method • Extract into Class

15. Extract into Method(Example) Refactor void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; printDetails(); } void printDetails() { System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); } void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); }

16. Extract into Method(Example) Refactor void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; printDetails(); } void printDetails() { System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); } void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); }

17. Extract into Method(Example) Refactor void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; printDetails(); } void printDetails() { System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); } void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); }

18. However… • Ultimately leads to relocation of code • So, if changes need to be made to withdrawAndDisplay’s functionality, we would have to locate printDetails also and then edit it • Unless withdrawAndDisplay’s functionality was completely unrelated to that of printDetails i.e., they were functionally orthogonal • But it’s not • Ultimately adds to the code-scattering problem discussed earlier

19. Affects Code Maintenance • Traditional modularization constructs and code refactoring hinder code maintenance • We observed this while working on a case study with JHotDraw (framework for developing graphical editors) • Recursively refactored/modularized code • Implemented in ~ 33,000 LoC • To add one feature to JHotDraw, we had to make changes in 5 files

20. Reason • The problem stems from these two properties of code: • A particular functionality is implemented by multiple code segments • A particular code segment implements multiple functionalities • Thus, there exist many-to-many relationships between code and concerns • Traditional modularization constructs and refactoring techniques only allow users to encapsulate the 1st property

21. Outline • Introduction • Motivation • Inline Visualization of Concerns • A Location-based Policy-specification Language • An Implementation of IVCon • User Interface • Implementation Details • Modularizing Runtime Security Policies • LoPSiL • An Implementation of LoPSiL • Validation of Approach • IVCon • LoPSiL • Conclusions and Future Work

22. IVCon (Inline Visualization of Concerns) • GUI-based tool to modularize CCCs in the presence of multi-concern code • 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

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

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

25. IVCon Feature: Relationships between Concerns and Code • The same code can be assigned to multiple concerns • IVCon allows users to define many-to-many relationships between concerns and code Users can assign scattered code to the same concern

26. Another IVCon Feature: Concern-assignment Granularity 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()); • 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

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

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

29. Related Work: AOPLs 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 Typical Aspect-oriented program:

30. Related Work: Concern 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

31. Comparison of IVCon with Related Work

32. Outline • Introduction • Motivation • Inline Visualization of Concerns • A Location-based Policy-specification Language • An Implementation of IVCon • User Interface • Implementation Details • Modularizing Runtime Security Policies • LoPSiL • An Implementation of LoPSiL • Validation of Approach • IVCon • LoPSiL • Conclusions and Future Work

33. Policy-specification Languages policy allowOnlyHTTP(Socket s) { if (s.getPort() == 80 || s.getPort() == 443) then ALLOW else DISALLOW } • Policy-specification languages are domain-specific programming languages designed to make it easier to specify and enforce sound security policies

34. Policy-specification Languages • Useful for modularizing security implementations • Security is a functionally orthogonal concern • Thus, security implementations could be effectively modularized using traditional modularization techniques • To examine this claim further, we have designed and implemented a policy-specification language for mobile devices • Based off traditional modularization constructs (aspects)

35. Motivation • Increased computation power of phones • Users need to treat and secure their phones like computers • However, this doesn’t happen • Makes it easier for a motivated malicious user to gain access to a phone and private information on that phone

36. Motivation (contd…) Open mobile platforms (iPhone, Android, etc.) allow any programmer to write software for phones Most programmers might not test their software to ensure minimal security holes Thus, even when a software developer’s intent may be good, it does not necessarily translate into secure software.

37. LoPSiL: A Location-based Policy-specification Language • LoPSiL is a location-based policy-specification language • As far as we are aware, LoPSiL is the first expressive (Turing-complete) policy-specification language that targets location-based policies • LoPSiL’s novelty is that it provides abstractions for conveniently accessing and manipulating location information in policies • Location constructs make LoPSiL ideal for mobile devices

38. Related Work Policy Trusted Application Program Compiler Untrusted Application Program • The trusted application program is equivalent to the untrusted program except that it contains inlined code that enforces the policy at runtime Many expressive policy-specification languages and systems have been implemented Implemented as compilers that convert untrusted into trusted applications

39. Related Work • Several languages and systems employ this architecture • E.g., Naccio, PoET/PSLang, Polymer • But it can be inconvenient to specify mobile-device policies in these languages because they lack primitives for managing location information • On the other hand, some policy-specification languages do provide primitives for managing location information • E.g., OpenAmbient, Geo-RBAC • But these languages are Turing-incomplete and limited to access-control policies

40. Comparison of LoPSiL with Related Work

41. Outline • Introduction • Motivation • Inline Visualization of Concerns • A Location-based Policy-specification Language • An Implementation of IVCon • User Interface • Implementation Details • Modularizing Runtime Security Policies • LoPSiL • An Implementation of LoPSiL • Validation of Approach • IVCon • LoPSiL • Conclusions and Future Work

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

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

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

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

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

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

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

49. Unwoven View Replaces code assigned to concerns with holes (□) of the appropriate color.

50. Unwoven View Unwoven-concerns panel shows each concern in an isolated module