Modularizing Crosscutting Concerns in Software

Modularizing Modularizing Crosscutting Concerns Crosscutting Concerns

in Softwarein Software

Nalin Saigal

/128

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

2

• Jay Ligatti• Adriana Iamnitchi• Joshua Finnis

Joint work withJoint work with

/128

Software Development Software Development LifecycleLifecycleDesign

◦Create a structure for the softwareImplement

◦Write code for the softwareTest

◦Ensure it works correctly

3

/128

Software Development Software Development LifecycleLifecycleDesign

◦Create a structure for the software◦Organize software’s functionality into

various modules◦Final software is modularized.

4

/128

Code ModularizationCode ModularizationThe practice of organizing code

into modules Helps separate different

functionalities of software from one another

5

/128

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

6

/128

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.

7

/128

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

8

/128

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

9

/128

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”

10

/128

Crosscutting ConcernsCrosscutting ConcernsPrevious 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

11

/128

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

12

/128

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

13

/128

RefactoringRefactoringRestructuring 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

14 *Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999

/128

Extract into Extract into Method(Example)Method(Example)void withdrawAndDisplay(float amt) {

this.balance = this.balance - amt;

System.out.println("Name: " + this.name);

System.out.println("Balance: " + this.balance);

}

void withdrawAndDisplay(float amt) {


printDetails();

}

void printDetails() {



}

Refactor

15

/128

Extract into Extract into Method(Example)Method(Example)



printDetails();

}




}

Refactor

16





}

/128

Extract into Extract into Method(Example)Method(Example)



printDetails();

}




}

Refactor

17





}

/128

However…However…Ultimately leads to relocation of codeSo, 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 notUltimately adds to the code-

scattering problem discussed earlier

18

/128

Affects Code MaintenanceAffects Code MaintenanceTraditional 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 files19

/128

ReasonReasonThe problem stems from these two

properties of code:1. A particular functionality is implemented

by multiple code segments2. A particular code segment implements

multiple functionalitiesThus, there exist many-to-many

relationships between code and concerns

Traditional modularization constructs and refactoring techniques only allow users to encapsulate the 1st property

20

/128

OutlineOutlineIntroduction

◦Motivation◦Inline Visualization of Concerns◦A Location-based Policy-specification

LanguageAn 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 21

/128

IVCon (IVCon (IInline nline VVisualization of isualization of ConConcerns)cerns)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

22

/128

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

23

/128

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)

24

/128

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

25

/128

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());





26

/128

Motivation for Token-level Motivation for Token-level GranularityGranularityFiner 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 tokenCoarser granularity in concern

assignment would reduce precision in concern assignments

27

/128

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 executed28

/128

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 29

/128

Related Work: Concern Related Work: Concern Visualization ToolsVisualization 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 GUI30

/128

Comparison of IVCon with Related Comparison of IVCon with Related WorkWork

31

/128








/128

Policy-specification Policy-specification LanguagesLanguages

Policy-specification languages are domain-specific programming languages designed to make it easier to specify and enforce sound security policiespolicy allowOnlyHTTP(Socket s) {if (s.getPort() == 80 ||

s.getPort() == 443) then ALLOW else DISALLOW

}33

/128

Policy-specification Policy-specification LanguagesLanguages

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) 34

/128

MotivationMotivationIncreased 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

35

/128

Motivation (contd…)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.

36

/128

LoPSiL: A Location-based Policy-LoPSiL: A Location-based Policy-specification Languagespecification LanguageLoPSiL 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

37

/128

Related WorkRelated WorkMany expressive policy-specification languages

and systems have been implemented Implemented as compilers that convert

untrusted into trusted applications

Policy

UntrustedApplication Program

CompilerTrusted

Application Program

The trusted application program is equivalent to the untrusted program except that it contains inlined code that enforces the policy at runtime

38

/128

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

Related WorkRelated Work

39

/128

Comparison of LoPSiL with Comparison of LoPSiL with Related WorkRelated WorkLanguage

Provides LocationConstruct

s

TuringComplet

e

Allows flexiblemanipulation of

location information

Providespolicy

composition

Ponder No Yes No No

XACML No No No No

PoET/PSLang

No Yes No No

Naccio No Yes No No

Polymer No Yes No Yes

Deeds No Yes No No

SpatialP Yes Yes No No

OpenAmbient

Yes No Yes No

Geo-RBAC Yes No Yes No

Android Yes No Yes No

LoPSiL Yes Yes Yes No40

/128








/128

Woven ViewWoven View

Woven-body panel is where users

write and view their complete code.

42

/128


Concern-legend panel lists all the

concerns defined by the user

43

/128


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

44

/128

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

45

/128

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

46

/128

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

47

/128

Unwoven-body panel displays the core of the

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

concerns


48

/128

Replaces code assigned to concerns with holes (□) of the appropriate

color.


49

/128

Unwoven-concerns panel shows

each concern in an isolated module


50

/128

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

51

/128

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

52

/128

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

53

/128

Centralized Code Updates - Centralized Code Updates - ExampleExample

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

54

/128

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

55

/128

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

Users can move mouse pointer over the code to see those concerns in a tool-tip

56

/128

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 57

/128

Flags – An ExampleFlags – An Example

We assign all this code to the security concern

58

/128


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

59

/128


60

/128








/128

Data StructuresData StructuresIVCon stores information about

concern assignments in three key data structures:◦regionMap◦concernMap◦regionTree

62

/128

regionMapregionMap (HashTable) (HashTable)

63

/128

concernMapconcernMap (HashTable) (HashTable)

64

/128

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.

65

/128








/128

Language OverviewLanguage OverviewDue to the popularity of Java

(particularly Java ME) as an application programming language for mobile devices, we’ll talk about (and we’ve implemented) LoPSiL in the context of Java

However, LoPSiL is based on six core abstractions (each implemented as a Java class) that we expect to be portable to other languages and platforms

67

/128

Core Linguistic Construct Core Linguistic Construct 11Location

◦May refer to a room, chair, floor, building, campus, GPS coordinates, region of a network topology, etc. Definition of locations is not “baked in” Users can define their own (possibly abstract)

locations by extending the Location classLocations have an identity (e.g.,

name or GPS coordinates)LoPSiL provides many built-in utility

methods for manipulating GPS locations (e.g., calculate distance between two locations)◦Users are free to define others

68

/128

Core Linguistic Construct Core Linguistic Construct 22LocationDevice

Is LoPSiL’s interface to real-time location information

LocationDevices must implement two methods:1.To return the device’s current location2.To return the device’s location

granularity: with what precision/accuracy the current location is known (e.g., within 0.5m, 2km, 1 room etc.)

Policies can require devices to provide location information with particular granularity thresholds

69

/128

Core Linguistic Construct Core Linguistic Construct 33PolicyAssumptions

◦Encapsulates two assumptions made by policies about a LocationDevice: LocationGranularityAssumption: Policy may

require location information with a particular accuracy

FrequencyOfUpdatesAssumption: Policy may require that location updates arrive with a particular frequency

A LoPSiL policy gets notified automatically whenever a LocationDevice violates that policy’s granularity or frequency-of-updates assumptions

70

/128

Core Linguistic Construct Core Linguistic Construct 44Action

◦ Encapsulates information (method signature, run-time arguments, calling object, return value, etc.) about a security-relevant method

An Action object gets passed to a policy before and after every security-relevant method executes

The policy can analyze an Action object passed to it to determine which security-relevant method is being invoked or has just been invoked

Policies get to decide whether and how the Actions passed to it will execute

71

/128

Core Linguistic Construct Core Linguistic Construct 55Reaction

◦Conveys a policy’s decision about whether and how an action is allowed to execute

Policies can react to a given Action a by returning one of four Reactions1.OK: a is safe to execute2.Exception: a is unsafe; exception should

be raised3.Replace: a is unsafe; a precomputed

return value should be returned instead of executing a

4.Halt: a is unsafe; program should be halted

72

/128

Core Linguistic Construct Core Linguistic Construct 66Policy

◦Specifies constraints on untrusted software

Five parts to a LoPSiL Policy1.PolicyAssumptions2.void handleGranularityViolation()3.void handleFrequencyViolation()4.void onLocationUpdate()

Invoked when any LocationDevice associated with the policy updates its Location information

5.Reaction react(Action a) Return a reaction to any security-relevant action

73

/128

Example Policy: Example Policy: AllowAllAllowAllpublic class AllowAll extends Policy {

public LocationDevice[] devices = {new

LopsilGPS(LopsilGPS.GARMIN)};

public LocationGranularityAssumption lga =

new LocationGranularityAssumption(15, Units.METERS);

public FrequencyOfUpdatesAssumption foua =

new FrequencyOfUpdatesAssumption(10, Units.SECONDS);

public PolicyAssumptions pa =

new PolicyAssumptions(this, devices, lga, foua);

public void handleGranularityViolation(){System.exit(1);}

public void handleFrequencyViolation(){System.exit(1);}

public synchronized void onLocationUpdate() {

System.out.println("new location = " +

devices[0].getLocation()); }

public synchronized Reaction react(Action a) {

return new Reaction("ok"); }

}74

/128

















}75

/128

















}76

/128

















}77

/128

















}78

/128

















}79

/128

















}80

/128

















}81

/128








/128

Compiler ArchitectureCompiler ArchitectureA LoPSiL compiler needs to input a policy, a list

of security-relevant methods, and an untrusted application

A LoPSiL compiler needs to output a trusted application formed by inserting (inlining) policy code before and after every security-relevant method in the untrusted application

List ofsecurity-relevant

methods

LoPSiL Policy

LoPSiL Compiler

TrustedApplication

UntrustedApplication

83

/128

We use AspectJ as a convenient tool for inlining policy code into the untrusted application

LoPSiL inherits AspectJ’s limitation that it can only inline code into application files (and not standard Java libraries)◦ So, LoPSiL monitors can’t make

decisions about the execution of security-relevant methods invoked by (non-application) library classes

Compiler ArchitectureCompiler Architecture

84

/128

User specifies desired policy in a .lopsil file User creates a listing of security-relevant methods in .srm file

LoPSiL policy(.lopsil)

Security-relevantmethods (.srm)


85

/128

LoPSiL Compiler



lopsil2aj

converter

User inputs the .lopsil and the .srm file into a lopsil2aj converter, because it converts LoPSiL files into files that can be input into an AspectJ compiler


86

/128

LoPSiL Compiler

AspectJ pointcut definition for

security-relevant methods (.aj)

Policy-enforcementcode (.java)

The compiler converts the .lopsil file to Java version (.java) of the policy by inserting three lines of code to import LoPSiL-library classes

The compiler converts the .srm file to an AspectJ-code file (.aj) that has definitions indicating

1. which policy code is to be executed and

2. when should that policy code be executed



lopsil2aj

converter


87

/128

LoPSiL Compiler




Untrusted application(.class)

AspectJcompile

r

The compiler inputs the .java file, the .aj file, and the untrusted application (.class) into a standard AspectJ compiler



lopsil2aj

converter


88

/128

LoPSiL Compiler




Trustedapplication

(.class)

Untrusted application(.class)

AspectJcompile

r

AspectJ compiler inlines policy code before and after all security-relevant methods and produces an application that is secure w.r.t. the original LoPSiL policy



lopsil2aj

converter


89

/128








/128

Case StudiesCase StudiesAdded features to several

applications:◦IVCon, JHotDraw, Java Scientific

CalculatorPurpose: To improve our

understanding of IVCon’s software engineering advantages

91

/128

Extending IVConExtending IVConAdded the following features to IVCon:

◦Search for text in code◦Jump to a line number◦Open multiple files simultaneously◦Show in a tool-tip, concerns implemented at

the current mouse cursor position◦Linked editing in the unwoven-concerns panel◦View flags in the woven view◦Jump to a specified concern module in

unwoven-concerns panel◦Compile and execute code directly from IVCon

92

/128

Implementation EffortImplementation EffortAdded 1591 lines of code to our

existing implementationTotal time spent implementing:

45 hours, 13 minutesTime spent defining and

assigning code to concerns: 28 minutes

Defined 43 concerns across 125 regions in 7 files

93

(1.03% overhead)

/128

Extending JHotDraw and Java Extending JHotDraw and Java Scientific CalculatorScientific CalculatorTo JHotDraw (a framework for

developing graphics editors) we added:◦A feature for asking users, before exiting

the program without saving changes to open files, whether they wish to save those changes

To Java Scientific Calculator we added:◦Three extra memory slots◦Grades as a unit for measuring angles◦A button that displays the modulus of a

complex number94

/128

Implementation EffortImplementation EffortAdded a total of 851 lines of codeTotal time spent implementing: 14

hours, 42 minutesTime spent defining and assigning

code to concerns: 14 minutesFor JHotDraw, defined 8 concerns in

18 regions across 5 filesFor Java Scientific Calculator, defined

10 concerns in 27 regions across 19 files

95

(1.59% overhead)

/128

Feature-specific concerns◦e.g., FindText, MultiFiles (in

IVCon); AskUsersForSave (in JHotDraw); GradeAngle (in Java Scientific Calculator)

◦Helped readily locate code segments we were working on

◦Particularly helpful because of code-scattering, e.g., MultiFile crosscut several classes and methods Allowed us to view all code implementing

Multiple-file feature in one place.

Experiential ObservationsExperiential Observations

96

/128

Experiential Observations Experiential Observations (contd…)(contd…)Other concerns defined were for

implementations that we were referring to regularly◦e.g., RTreeFunctions, LexerFunctions

Overlapping concerns: e.g., MultiFile overlapped with OpenFile and SaveFile◦Flags helped identify where to make

changes in unwoven-concerns.97

/128

Experiential Observations Experiential Observations (contd…)(contd…)To implement the Multiple-file

feature, IVCon maintains state information for each open file◦Code that saves/updates this

information is present in three different places.

◦Each instance is partially similar to the other

◦Assigning each one of those instances to a concern helped because we could centrally update it in the unwoven view 98

/128

Performance EvaluationPerformance EvaluationTested IVCon by assigning code to

concerns in two of IVCon’s source-code files: ◦IVCON.java◦Windows.java

Also, created an impractically large file (StressTest.java) of 100,000 lines, each containing 20 randomly generated single-character tokens

99

/128

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

100

/128

ResultsResults

File Name

AssignCodeto a

Concern

(ms)

Edit aConcer

n(ms)

Remove a

Concern(ms)

Weaving

(ms)

Unweaving

(ms)

IVCON.java 23.78 7.34 9.41 7.03 18.76

Windows.java 295.51 30.15 98.40 943.22 625.45

StressTest.java104,97

6810 1,050

537,959

89,534

IVCon performed all operations tolerably quickly on reasonably-sized files.

101

/128








/128

Case StudyCase StudyImplemented and tested several

interesting location-based policies

Purpose: To test the usefulness of LoPSiL’s location constructs

103

/128

Access-control PolicyAccess-control Policy•Prevents an application from reading GPS data outside of work hourspublic class NoGpsOutsideWorkTime extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa = ... public synchronized Reaction react(Action a) { if(ActionPatterns.matchesLocationRead(a) && !TimeUtils.isWorkTime()) //return a null location to the application return new Reaction("replace", null); else return new Reaction("ok"); } }

104

/128


105

/128


106

/128


107

/128


108

/128


109

/128

Deviation-from-path PolicyDeviation-from-path Policy

public class ShowNavigation extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa = ... public synchronized void onLocationUpdate() { if(devices[0].getLocation(). distance(getExpectedCurrentLocation(), Units.METERS)>10) AppGUI.displayNavigationalAid(); }}

•Requires that navigational aid appear when thedevice’s current location deviates from its expected path

110

/128




111

/128




112

/128




113

/128




114

/128




115

/128

Other PoliciesOther Policies

Safe-region Policy:◦Requires a robot to encrypt all outgoing

communications when the robot’s location is outside a secure-region perimeter

Social-networking Policy: ◦If the policy infers that the device has

completed a journey of at least 100km over the past 2 hours, then all friends in the user’s address book who are located within 20km of the new location get invited to rendezvous

116

/128

Experiential ObservationsExperiential ObservationsOur location-dependent policies

consistently based policy decisions on:◦Absolute location of the device◦Geographic relationship of device’s location

with another location, or with a region of locations

◦Velocity or acceleration of the deviceTherefore, LoPSiL provides several utility

methods for calculating distances, boundaries, velocities, and acceleration

Users can access all these methods and can implement other custom operators when built-in methods are insufficient

117

/128

Experiential ObservationsExperiential ObservationsWe found that LoPSiL was sufficiently

expressive to specify all the location-dependent policies we considered enforcing

None of the example policies mentioned earlier took much time (more than a few hours) to design, specify, and test

Therefore, we believe that the six core constructs underlying LoPSiL serve as good abstractions for specifying location-dependent policies

118

/128

Performance EvaluationPerformance EvaluationTested overhead (on an Android

Phone) from four LoPSiL policies:◦AllowAll◦AccessControl◦ShowNavigation◦SocialNetworking

Recorded the following metrics for the base application vs. the policy-enforced application:◦Time taken to execute◦Memory usage◦Battery usage◦Code size

119

/128

ResultsResultsPolicy Time

taken(ms)

Memory

Usage(Bytes)

Battery

Usage(%age

)

Codesize

(Bytes)

AllowAll Base 36.981 2,967 16.25 13,379w/

Policy37.725 3,211

16.88 68,939Overhea

d0.744 244

0.63 55,560AccessControl Base 86.203 3,976 27 14,386

w/ Policy

102.458 4,168 26.88 70,394

Overhead

16.255192 -0.12 56,008

ShowNavigation Base 3.258 4,821 6.38 15,419w/

Policy26.254

5,196 10.5 71,602Overhea

d22.996

375 4.12 56,183SocialNetworking Base 2.450 4,679 5.38 14,142

w/ Policy

82.8605,035 9.88 71,357

Overhead

80.410356 4.5 57,215

120

/128








/128

ConclusionsConclusionsModularizing CCCs in the presence of

multi-concern code involves augmenting traditional modularization constructs with extra information about the multi-concern code:◦ IVCon utilizes a GUI to encapsulate that

informationTraditional modularization constructs

are appropriate for modularizing funtionally orthogonal CCCs◦LoPSiL uses aspects to modularize

security implementations.

122

/128

IVCon SummaryIVCon SummaryIVCon 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

convenient123

/128

LoPSiL SummaryLoPSiL SummaryLoPSiL is a language for specifying

location-dependent runtime security policies

LoPSiL is Turing-completeIts novelty lies in its expressive

abstractions for accessing and manipulating location information in policies

124

/128

Future Work: IVConFuture Work: IVConGet usage data and feedback from

more usersProvide support for multiple

languagesUse concern information in files to see

relations between different concerns◦Could possibly help improve suggestions

for Eclipse’s Extract into Method/Class refactorings

IVCon programming language◦Annotations to indicate concern-

assignments 125

/128

Future Work: LoPSiLFuture Work: LoPSiLProvide support for composeable

policies◦Users would have to write effectless

policies◦We would have to define combinators

Write our own code-inliner◦Enforce complete mediation of security-

relevant methodsModel LoPSiL into a formal calculus

126

Thanks/Questions?Thanks/Questions?

/128

ContributionsContributionsWhat benefits does a dual view of software

and the ability for programmers to define multi-concern code provide?

In terms of user effort, can these benefits be achieved with reasonable overheads?

What kind of language constructs are useful for policies that reason about a program's execution based on a system's location?◦ Does LoPSiL provide useful constructs for specifying such

policies?

What kind of policies would be useful to specify and implement in a language that enables users to specify location-based policies?◦ How convenient is it to specify those policies in LoPSiL?

128

Documents

Modularizing Crosscutting Concerns in Software