USF Libraries
USF Digital Collections

Modularizing crosscutting concerns in software

MISSING IMAGE

Material Information

Title:
Modularizing crosscutting concerns in software
Physical Description:
Book
Language:
English
Creator:
Saigal, Nalin
Publisher:
University of South Florida
Place of Publication:
Tampa, Fla
Publication Date:

Subjects

Subjects / Keywords:
Aspect-oriented Programming
Code Maintenance
Policy-specification Languages
Security
Software Engineering
Dissertations, Academic -- Computer Science -- Doctoral -- USF   ( lcsh )
Genre:
bibliography   ( marcgt )
non-fiction   ( marcgt )

Notes

Summary:
ABSTRACT: Code modularization provides benefits throughout the software life cycle; however, the presence of crosscutting concerns (CCCs) in software hinders its complete modularization. Traditional modularization techniques work well under the assumption that code being modularized is functionally orthogonal to the rest of the code; as a result, software engineers try to separate code segments that are orthogonal in their functionality into distinct modules. However, in practice, software does not decompose neatly into modules with distinct, orthogonal functionality. In this thesis, we investigate the modularization of CCCs in software using two different techniques. Firstly, we discuss IVCon, a GUI-based tool that provides a novel approach to the modularization of CCCs. We have designed IVCon to capture the multi-concern nature of code. IVCon enables users to create, examine, and modify their code in two different views, the woven view and the unwoven view. The woven view displays program code in colors that indicate which CCCs various code segments implement, while the unwoven view displays code in two panels, one showing the core of the program and the other showing all the code implementing each concern in an isolated module. IVCon aims to provide an easy-to-use interface for conveniently creating, examining, and modifying code in, and translating between, the woven and unwoven views. Secondly, we discuss LoPSiL, which is a location-based policy-specification language. LoPSiL is Turing-complete and provides users with language constructs that enable them to manipulate location information; hence, LoPSiL can be used to specify and enforce generic policies that might involve location-based constraints. We have implemented a LoPSiL compiler using AspectJ, and we observe and discuss how the use of traditional units of modularization---aspects in this case---help modularize functionally orthogonal CCCs such as security and auditing.
Thesis:
Disseration (Ph.D.)--University of South Florida, 2011.
Bibliography:
Includes bibliographical references.
System Details:
Mode of access: World Wide Web.
System Details:
System requirements: World Wide Web browser and PDF reader.
Statement of Responsibility:
by Nalin Saigal.
General Note:
Title from PDF of title page.
General Note:
Document formatted into pages; contains 70 pages.
General Note:
Includes vita.

Record Information

Source Institution:
University of South Florida Library
Holding Location:
University of South Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
usfldc doi - E14-SFE0004971
usfldc handle - e14.4971
System ID:
SFS0028208:00001


This item is only available as the following downloads:


Full Text

PAGE 1

ModularizingCrosscuttingConcernsinSoftwarebyNalinSaigalAdissertationsubmittedinpartialfulllmentoftherequirementsforthedegreeofDoctorofPhilosophyDepartmentofComputerScienceandEngineeringCollegeofEngineeringUniversityofSouthFloridaMajorProfessor:JayLigatti,Ph.D.AdrianaIamnitchi,Ph.D.DeweyRundus,Ph.D.WilfridoMoreno,Ph.D.BrendanNagle,Ph.D.DateofApproval:March22,2011Keywords:SoftwareEngineering,CodeMaintenance,Aspect-OrientedProgramming,Security,Policy-SpecicationLanguagesCopyrightc2011,NalinSaigal

PAGE 2

DEDICATIONIdedicatemydissertationtomyfamilyandclosefriends.AspecialthanksgoesouttomyparentsSumeshandSumanSaigal,whohavebeenextremelysupportive,and,tomysister,Shalini,whoseencouragingwordshavealwayskeptmepositive.

PAGE 3

ACKNOWLEDGEMENTSIwouldliketothankmyadvisorJayLigatti,forgivingmetheopportunitytoworkwithhim,andforbeinganincredibleadvisor.Thedurationofmydoctoraldegreeunderhisguidancehasmadegraduateschoolamemorableacademicexperienceforme.MostoftheworkpresentedinthisdissertationisincollaborationwithJayLigatti,AdrianaIamnitchi,andJoshuaFinnis,andIwouldliketothankthemfortheirinputstothisresearch.IwouldalsolikethankthefacultyoftheComputerSciencedepartmentatUSFforteachingthevariouscoursesoeredbythedepartment.AbigpartofthelearningexperienceatUSFwasthroughcourses,andthefacultyatUSFmadeitanextremelyenjoyableexperience.Also,aspecialthanksgoesouttomycommitteemembers,forbeingpartofthegroupthatencouragedthisresearch.Finally,IwouldliketoacknowledgetheNationalScienceFoundationasmyresearchwassup-portedbythemundergrantsCNS-0742736,CNS-0831785,andCNS-0716343.

PAGE 4

TABLEOFCONTENTSLISTOFTABLESiiiLISTOFFIGURESivABSTRACTvCHAPTER1INTRODUCTION11.1Motivation31.2InlineVisualizationofConcerns41.2.1RelatedWork61.2.1.1Aspect-orientedProgramming61.2.1.2ConcernVisualizationTools71.2.1.3ProgrammingLanguages91.2.1.4Feature-orientedProgramming101.3ALocation-basedPolicy-specicationLanguage121.3.1RelatedWork131.3.1.1GeneralPolicy-specicationLanguages131.3.1.2FormalLanguages131.3.1.3Location-basedAccess-controlLanguages141.3.1.4Android'sBuilt-inSecurityMechanism151.4Contributions161.5ThesisOrganization17CHAPTER2ANIMPLEMENTATIONOFIVCON182.1UserInterface182.1.1WovenView182.1.2UnwovenView202.1.3DisplayofMulti-concernCode242.2ImplementationDetails252.2.1DataStructures252.2.2TranslationAlgorithms262.2.2.1Unweaving262.2.2.2Weaving272.2.3Third-partyLibraries27CHAPTER3MODULARIZINGRUNTIMESECURITYPOLICIES293.1LoPSiL303.1.1CoreLinguisticConstructs303.1.2ExampleLoPSiLPolicy33i

PAGE 5

3.2ALoPSiLCompiler333.2.1CompilerArchitecture34CHAPTER4VALIDATIONOFAPPROACH374.1IVCon374.1.1CaseStudies374.1.1.1ExtendingIVCon374.1.1.2ExtendingJHotDrawandJavaScienticCalculator394.1.2ExperientialObservations404.1.3PerformanceEvaluation424.2LoPSiL454.2.1CaseStudies454.2.2ExperientialObservations484.2.3PerformanceEvaluation49CHAPTER5CONCLUSIONS525.1Discussion525.2FutureWork54LISTOFREFERENCES58ii

PAGE 6

LISTOFTABLESTable1.1Comparisonofconcern-manipulationtools.7Table1.2Comparisonofpolicy-specicationlanguages.14Table4.1ImplementationeortforIVConcasestudy.39Table4.2ImplementationeortforJHotDrawandJavaScienticCalculatorcasestudies.40Table4.3Test-lecharacteristics.42Table4.4Performanceopeningandsavingles.43Table4.5Performanceassigningcodetoconcerns.43Table4.6Performanceeditingconcerncolorsandremovingconcerns.44Table4.7Performanceweavingandunweavingcode.44Table4.8OverheadincurredfromusingLoPSiL50iii

PAGE 7

LISTOFFIGURESFigure1.1Samplecodedemonstratingthemotivationbehindtoken-levelgranularity.6Figure2.1IVCon'swovenviewofthesamecodeshowninFigure2.2.19Figure2.2IVCon'sunwovenviewofthesamecodeshowninFigure2.1.20Figure2.3Concern-moduleformattinginIVCon.21Figure2.4UnwovenviewofthecodeinFigure2.5.22Figure2.5WovenviewofthecodeinFigure2.4.23Figure3.1SimpleLoPSiLPolicythatallowallactionstoexecute33Figure3.2Example.srmleindicatingthattheaccompanyingLoPSiLpolicyconsiderssecurityrelevantallvoid-returningjava.io.PrintStream.printlnmethods,allmethodsinthejavax.swing.JOptionPaneclass,andtheparameterlesscon-structorforjava.util.Dates.34Figure3.3OverviewoftheLoPSiLcompiler.35Figure4.1LoPSiLpolicypreventinganapplicationfromreadingGPSdataoutsideofworkhours.46Figure4.2AbbreviatedLoPSiLpolicyrequiringthatnavigationalaidappearwhenthedevice'scurrentlocationdeviatesfromitsexpectedpath.46Figure4.3AbbreviatedLoPSiLpolicyrequiringrobot-controlsoftwaretoencryptoutgoingmessageswhentherobotisoutsideasecure-regionperimeter.47Figure4.4Alocation-dependentsocial-networkingpolicyspeciedinLoPSiL.48Figure5.1IVCon'snewerinterfaceforreducedconcernassignmenttimes.55iv

PAGE 8

ABSTRACTCodemodularizationprovidesbenetsthroughoutthesoftwarelifecycle;however,thepresenceofcrosscuttingconcernsCCCsinsoftwarehindersitscompletemodularization.Traditionalmod-ularizationtechniquesworkwellundertheassumptionthatcodebeingmodularizedisfunctionallyorthogonaltotherestofthecode;asaresult,softwareengineerstrytoseparatecodesegmentsthatareorthogonalintheirfunctionalityintodistinctmodules.However,inpractice,softwaredoesnotdecomposeneatlyintomoduleswithdistinct,orthogonalfunctionality.Inthisthesis,weinvestigatethemodularizationofCCCsinsoftwareusingtwodierenttechniques.Firstly,wediscussIVCon,aGUI-basedtoolthatprovidesanovelapproachtothemodulariza-tionofCCCs.WehavedesignedIVContocapturethemulti-concernnatureofcode.IVConenablesuserstocreate,examine,andmodifytheircodeintwodierentviews,thewovenviewandtheunwovenview.ThewovenviewdisplaysprogramcodeincolorsthatindicatewhichCCCsvariouscodesegmentsimplement,whiletheunwovenviewdisplayscodeintwopanels,oneshowingthecoreoftheprogramandtheothershowingallthecodeimplementingeachconcerninanisolatedmodule.IVConaimstoprovideaneasy-to-useinterfaceforconvenientlycreating,examining,andmodifyingcodein,andtranslatingbetween,thewovenandunwovenviews.Secondly,wediscussLoPSiL,whichisalocation-basedpolicy-specicationlanguage.LoPSiLisTuring-completeandprovidesuserswithlanguageconstructsthatenablethemtomanipulatelocationinformation;hence,LoPSiLcanbeusedtospecifyandenforcegenericpoliciesthatmightinvolvelocation-basedconstraints.WehaveimplementedaLoPSiLcompilerusingAspectJ,andweobserveanddiscusshowtheuseoftraditionalunitsofmodularization|aspectsinthiscase|helpmodularizefunctionallyorthogonalCCCssuchassecurityandauditing.v

PAGE 9

CHAPTER1INTRODUCTIONInaccordancewithgoodsoftware-developmentpractices,softwareengineerstypicallyinvesttimedevisingthestructureofaprojectbeforetheycanstartworkingontheproject'simplementation.Duringthedesignphase,softwareengineersattempttomodularizetheircode;thatis,theytrytoorganizetheircodeintodistinctsoftwaremodules.Thispracticeinturnprovidesmultiplebenetstoprogrammers:Itmakescodeeasiertowrite.Becauseprogrammershaveinvestedtimeorganizingtheircodeintofunctionallyorthogonalmodules,dierentprogrammerscanworkondierentmodulesirrespectiveoftheimplementationofothermodules.Itmakescodeeasiertounderstand.ByprovidingAPIsandschematicdiagramsinwhichmodulesandinterfacesbetweenmodulesareclearlydepicted,programmerscanquicklycom-municatethestructureoftheirsoftwaretootherprogrammers.Itmakescodeeasiertomaintain.Again,becauseofthedesignprocess,programmersknowinwhichlestondrelevantcodesegmentswhentheywanttoaddoreditfeaturesintheirsoftware.Ideally,toreapthemaximumbenetsofmodularization,softwareengineerstrytoseparatecodesegmentsthatareorthogonalintheirfunctionalityintodistinctmodules.However,inpractice,softwaredoesnotdecomposeneatlyintomoduleswithdistinct,orthogonalfunctionality.Forexample,codethatdisplaysapopupwindownotifyingusersaboutafailedloginattemptmaybepresentinaloginmodule,whilepartiallyimplementingvariousotherfunctionalconcernssuchassecurity,GUI,andauthentication;itmaybeequallyreasonableforthewindow-popupcodetobelocatedinasecurity,GUI,orauthenticationmodule,andatvarioustimesitmaybemore1

PAGE 10

convenienttowrite,view,oreditthewindow-popupcodeinthecontextoftheseothermodules.Tarretal.callthisproblemthetyrannyofthedominantdecomposition"[1].Althoughitisusefultomodularizethesamecodesegmentinvariouswaysthroughoutthesoftwarelifecycle,currentprogrammingparadigmsonlyallowmodularizationinxedandlimitedwayse.g.,intofunctions,classes,oraspects.Whileonemodulemayimplementmultiplesoftwareconcernsi.e.,behaviorsrequiredofthesoftware,whichareimplementedinsourcecode,itis,conversely,commonforimplementationsofconcernstobescatteredthroughoutmultiplemodules.Forexample,codeimplementingasecurityconcernmaybescatteredthroughoutlogin,logout,andnetwork-socketmodules.Thus,codesegmentsimplementingaconcernmaycrosscutthroughimplementationsofotherconcerns;suchcodesegmentsimplementcrosscuttingconcernsCCCs.ModularizingaCCCinvolvescollectinganddisplayinginoneplaceallthescatteredcodeimplementingthatCCC.Isolatingconcerncodeinthiswaybenetsprogrammersbecauseitrelievesthemfromhavingtobrowsethroughthewholeprogramtond,study,orupdateasinglesoftwareconcern.AcommonexampleofaCCCissecurity.Codeimplementingsecurityoftentendstogetscatteredthroughoutprogramsintheformofsecuritycheckse.g.,checkingarraybounds,checkingaccesspermissionstoaleetc.,andbecausesecurityisfrequentlyfunctionallyorthogonaltotherestoftheprogram'sfunctionality,itmakessensetoisolatecodeimplementingsecurityintoamodulethatisdisjointfromtheimplementationofthecoresoftware.Toisolatesecurityimplementationsfromthecoresoftwareimplementation,securityengineersusepolicy-specicationlanguages.Policy-specicationlanguagessuchasPoET/PSLang[2],Nac-cio[3],Polymer[4,5]etc.aredomain-specicprogramminglanguagesintendedtosimplifythetasksofspecifyingandenforcingsoundsecuritypoliciesonuntrustedi.e.,potentiallyinsecuresoftware.Modularizingsecurityimplementationsusingpolicy-specicationlanguagesimpliesthatcodeimplementingsecurityinanapplication,whichwouldotherwisebescatteredthroughouttheapplication,isnowpresentinonemodulele.So,toanalyzeand/ormodifysuchanapplication'ssecurityimplementationwouldentaillocatingand/ormodifyingonlyonele,therebyreducingtheeortwhencomparedtoasysteminwhichapolicy-specicationlanguagewasnotbeingused,inwhichcase,asecurityengineerwouldhavetolocateeveryinstanceofasecuritycheckthroughout2

PAGE 11

theapplicationencompassingseverallesandmakechangesinmultipleles.WediscussthemodularizationofruntimesecuritypoliciesfurtherinChapter3.1.1MotivationInhisbookonrefactoringtechniques,Fowlerpresentsanddiscussesindetail,alistof72techniquesforreorganizingcodesothatcodebecomeseasiertocomprehend[6,7].Whileallthesetechniqueshelpprogrammersimprovethestructureandreadabilityoftheircode,someofthemgiverisetoanewproblem.ByusingrefactoringtechniquessuchasExtractintoMethod,ExtractintoClassetc.programmersessentiallyrelocatetheimplementationsoftheirprogram'sdierentfunctionalitiesintonewerles.Itwouldmakesensetodoso,ifthecodebeingextractedintoanewerclassornewermethodwerecompletelyorthogonalinfunctionalitytothecodesurroundingitsuchascodeimplementingsecurityorlogginginanapplication;however,asmentionedearliercodeoftendoesnotdecomposeintoorthogonally-denedfunctionalities.Asaresult,traditionalrefactoringtechniquesaddtotheproblemofcode-scatteringthatwediscussedearlierbyscatteringimplementationsoffunctionalitiesacrossmultipleles.This,inturnmakesitmoredicultforprogrammerstomodifyexistingapplications.WeobservedthisproblemwhiletryingtoaddafeaturetoJHotDraw[8],whichisaJava-basedframeworkthatfordevelopingdrawingeditorsfordesigningstructuredgraphics.JHotDrawisimplementedinapproximately33,000linesofcode,anditsimplementationiswell-structuredandeasytocomprehend.MostJHotDrawlesaresmallinsize,whichindicatesthatJHotDrawdevel-opershaveusedgoodsoftwaredevelopmentpracticesbyrecursivelymodularizingcodewhereverpossible.However,whilemodifyingitssourcecode,wefoundthatbyfollowingconventionally-goodmodularizationpractices,JHotDrawdevelopershaveindeedscatteredcodeimplementingasinglefunctionalityacrossmultipleles.Asaresult,wespentasignicantamountoftimeanalyzingJHotDraw'scodetolocatedierentlesinwhichthefunctionalitiesofourinterestwerepresent.Thus,whilecurrentmodularizationpracticesimprovecodestructure,theycanalsoimpedetheprocessofsoftwaremaintenance.3

PAGE 12

Theproblemsdescribedabovestemfromthefollowingtwopropertiesofcodefoundinsoftwaresystems:Aparticularcodesegmentimplementsmultiplefunctionalities.Aparticularfunctionalityisimplementedbycodethatisscatteredacrossmultiplemethodsandles.Thus,ifwethinkofconcernsandcodesegmentsasmathematicalsets,wecanseethattypicallyinsoftware,thereexistsamany-to-manyrelationshipbetweenconcernsandcodesegmentsimple-mentingthoseconcerns;thatis,aconcerncanbeimplementedbymultiplenon-contiguouscodesegments,andacodesegmentcanimplementmultipleconcerns.However,traditionalmodulariza-tiontechniquesrestrictusersintodeningone-to-manyrelationshipsbetweenconcernsandcode;thatis,aconcerncanbeimplementedbymultiplenon-contiguouscodesegments.1.2InlineVisualizationofConcernsTotargetthebehaviorofcodethattraditionalmodularizationtechniquesdonotcapture,cur-rentmodularizationtechniquesneedtobeaugmentedbyusingnewertechniquesduringsoftwaredevelopment.Correspondingly,wehaveimplemented,inJava,anIDEcalledIVConthataimstotargettheseproblemsbyprovidinguserswithmultipleviewsoftheircodesothatuserscan:Viewtheircompletecode,asitwillbeatruntime.Thisenablesuserstodebugcompleteprograms;ifcompleteprogramsarenotavailabletouserstheycouldbeoverlookinganaspectoftheirprogramsthatmightbecausinganundesiredeectatruntime.ViewtheircodeintheabsenceofCCCs.ThisenablesuserstoanalyzetheircodewhenCCCsarecompletelyorthogonaltothefunctionalityofthecoreprogram.ViewCCCsinisolation.Inthepresenceoffunctionallyorthogonalconcerns,thisenablesdierentprogrammerstoworkondierentmodules,independentoftheimplementationofothermodulesoneofthebenetsoftraditionalmodularizationtechniques.Viewandreadilyidentifycodethatimplementsmultipleconcerns.Thisenablesuserstounderstandthedierentfunctionalitiesoftheirprogramthatwillgetaectedwhenacode4

PAGE 13

segmentSismodiedalltheconcernsthatSimplementsgetaectedwhenausermodiesS.Viewconcernswhoseimplementationsarescatteredacrossmultiplelesreadily.Thisensuresthatusersdonothavetospendtimetryingtondimplementationsofparticularfunctional-ities.IVConpermitsmany-to-manyrelationshipsbetweenconcernsandcode.Thatis,userscanassignscatteredcodesegmentstothesameconcernandcanassignasinglecodesegmenttomultiple,overlappingconcerns.Wecallcodethathasbeenassignedtomultipleconcernsmulti-concerncode.Moreover,IVConenforcestoken-levelgranularityinconcernassignments:codeassignedtoaconcernmustbeginatthebeginningofasource-languagetokenandendattheendofasource-languagetoken.IVConenforcestoken-levelgranularitybecausetokensarethesmallest,atomicunitswithmean-inginaprogramminglanguage.Allowingnergranularityinconcernassignmente.g.,character-levelgranularitywouldbeinappropriatebecausetokensarethecoresemanticunitsofprogram-minglanguagesandofconcernsimplementedinthoselanguages.Ontheotherhand,requiringcoarsergranularityinconcernassignmente.g.,line-levelgranularitywouldbeinappropriateaswell.ConsiderthecodeinFigure1.1.Token-levelgranularityenablesassignmentofjusttheSystem.currentTimeMilliscodesegmenttoaSystemCallconcern,whilecoarserconcern-assignmentgranularities,suchasline-orstatement-levelgranularity,lacktheprecisionneededforsuchaconcernassignment.Withtoken-levelgranularity,ausercouldevenassignjustthemethodnamecurrentTimeMillistotheSystemCallconcern.Atthesametime,token-levelgranularitypreventsunreasonableconcernassignmentspossiblewithnere.g.,character-levelgranularities,suchasassigningjustthe`i'inJOptionPanetoitsownconcern;thiswouldbeunreasonablebe-causeif`i'implementsaconcernC,thentherestoftheJOptionPanetokenmustimplementCaswelltheatomicJOptionPanetokenhasmeaningintheprogramminglanguage,whilethe`i'alonedoesnot.Thusenforcingtoken-levelgranularityenablesne-grained,yetmeaningfulconcernassignments.5

PAGE 14

JOptionPane.showMessageDialogmainWindow.frame,"Welcome"+userName+".Currenttimeis"+formatSystem.currentTimeMillis,"Welcome",JOptionPane.INFORMATIONMESSAGE;Figure1.1.Samplecodedemonstratingthemotivationbehindtoken-levelgranularity.1.2.1RelatedWorkTherearemanyprojectsrelatedtoIVCon,whichwenextdiscussindetail.Table1.1summarizesthediscussion.1.2.1.1Aspect-orientedProgrammingAcloselyrelatedbodyofresearchisAspectOrientedProgrammingAOP[9];likeIVCon,AOPeasesthespecicationandmanipulationofCCCsinsoftware.AOPlanguagesAOPLssuchasAspectJ[10]andAspectC[11]deneanewunitofmodularization,theaspect,whichisacombinationofadvicecodethatimplementsaCCCandjoinpointspointsinaprogram'scontrolowwhereadvicegetsexecuted.Acompleteaspect-orientedprogramconsistsofacoreprogramandaspects,andAOPLcompilerstypicallyweaveadvicefromuser-denedaspectsintothecoreprogramatthejoinpointsspeciedbythoseaspects.Roughlyspeaking,then,IVCon'sunwovenviewcorrespondstoanaspect-orientedviewofaprogram,ascodeimplementingCCCsappearinisolatedmodules.However,unlikestandardAOPtools,IVCon:Allowscodetobewritten,examined,andeditedinbothwovenandunwovenviews.Allowsmulti-concerncode.Forexample,multi-concerncodeisimpossibleinAspectJbecauseasinglecodesegmentSinthewovenprogramcannotappearinmultipleAspectJadvicesorinboththeprogramcoreandsomeadvice|ifitdidthenSwouldhavetoappearmultipletimesnotonceinthewovenprogram.Enforcestoken-levelgranularityinconcerncode.Usesanovelinterfacetoaidconcernassignment,visualization,weaving,andunweaving.Ontheotherhand,IVConisabletoprovidesomeofthesefeaturesonlybecauseitdisallowsjoinpointscalledregionsinIVConfrombeingspeciedindirectlyi.e.,aspointcuts,whichAOPLs6

PAGE 15

Table1.1.Comparisonofconcern-manipulationtools. Tool Can IsoCan Allowsmanyedit lates modify to-many ProRegion Granularity code conidentical relationships vides i.e.,joinpoint of in cern concern between GUI specication concern dual code codein concerns assignment views oneplace andcode AspectBrowser p p RegularexpCharacterressionsover level concerncode Visualiser p AspectJpointLine-level cutlanguage FEAT p p RegularexpDeclarationressionsover level concerncode SoQueT p p RegularexpDeclarationressionsover level concerncode C4 p p AspectCpointLine-level cutlanguage Hyper/J p p Package,class, Declarationinterface,method, level oreldnames CIDE p p Explicit Nodesin ASTs WEB p p Explicit Characterlevel IVCon p p p p p Explicit Token-level typicallydoallow.IVConalsolacksconstructsforencapsulatingorinterfacingwithmodularizedcode,whichAOPLsdoprovidethislimitationisdiscussedfurtherinSection5.1.1.2.1.2ConcernVisualizationToolsTurningourattentiontospecicAOPtoolsrelatedtoIVCon,Aspect-jEdit[12]plugsintothejEdit[13]texteditorand,likeIVCon,allowsuserstoviewandeditconcerncodeinthecontextofthecoreprogram.AlsolikeIVCon,Aspect-jEditusersassigncodetoconcernsbyhighlightingcodeandexplicitlyassigningittotheconcernitimplements,anduserscanassignsyntacticallydierentcodesegmentstothesameconcern.Eachaspecti.e.,concerninAspect-jEditisassociatedwithacolor,andonassigningcodetoanaspect,thatcode'sbackgroundcolorchangestomatchitsaspectcolor.Aspect-jEdituserscanhideoneormoreaspectsandviewaspectsinisolation,butAspect-jEditdoesnotsupportmulti-concerncodewhichsimpliesitsinterfaceandtext-manipulationalgorithms.7

PAGE 16

Aspect-jEditdisplayssyntacticallyequaladvicemultipletimesinanaspect,asopposedtoIVCon'suseofsubconcernsdescribedinSection2.1.2;consequently,Aspect-jEdituserscannotmodifyallidenticalconcerncodeatonceinacentralconcernmodule.AspectBrowser[14,15,16],whichisbuiltonideasfromSeesoft[17],letsusersspecifyconcernsintheformofregularexpressionsovercharactersinthesourcecode.AspectBrowserdisplaysahigh-levelprogrammapinwhichcolorsindicatewhichlinescontainwhichCCCs.WhenaprogramlinecontainsmorethanoneCCC,AspectBrowsercolorsthecorrespondingmaplinered.Also,AspectBrowseruserscanzoomwithinthemaptoobtainamoredetailedviewandcanclickonacoloredlinetoviewthatline'sCCCanditscontexti.e.,thecorecodesurroundingtheCCC.IVCondoesnotbuildahigh-levelprogrammap,thoughitdoesgraphicallyidentifyallcoderegionsimplementingeachCCCusingcolors,ags,tooltips,andaconcern-at-current-positionpanelinthewovenview,aswellascolors,ags,andexplicitregionnamesintheunwovenview.Toolslikegrepcanalsobeusedtoidentifyanddisplayinasingleviewallthecodematchingregularexpressions[18].TheVisualiser[19]isanEclipse[20]pluginthathelpsAspectJprogrammersvisualizejoinpointsintheirprogramsusingahigh-levelprogrammap.Afterassigningcolorstoexistingaspects,theVisualiserperformsstaticanalysistogenerateaprogrammapsimilartothatofAspectBrowser.IntheVisualisermap,coloredlinesrepresentthelocationsofjoinpoints,andifmultipleaspectsshareajoinpointthentheVisualisersplitsthatlineintothecolorsofthoseaspects.ConcernsthatareimplementedinAspectJandusedwiththeVisualisercanmakeuseofAspectJ'srichjoinpointlanguage.DuetoitsrelianceonAspectJ,though,theVisualiserinheritsAspectJ'slimitationsofstatement-levelgranularityinconcernassignmentsandone-to-manyrelationshipsbetweenconcernsandcode.FEAT[21]andSoQueT[22]aretoolsavailableaspluginstoEclipsethathelpusersmodularizeCCCsinsimilarways.Inboththesetools,userssearchtheircodeusingregular-expressionqueriestoretrieveprogramelementse.g.,classes,datamembers,methodsetc.thatimplementconcerns.Userscanencapsulatetheseprogramelementsalongwithotherinformationintoconcernmodules.FEATandSoQueTdierintheconcernmodulesthattheyuseandtheinformationencapsulatedinthoseconcernmodules.FEATusesconcerngraphs,whichstoreprogramelementsandrelationsbetweendierentprogramelements,whereasSoQueTusescrosscuttingconcernsorts,whichdocu-8

PAGE 17

mentprogramelementsandthenatureofthecrosscuttingconcern.Bothtoolsallowmany-to-manyrelationshipsbetweenconcernsandcodeandallowuserstonavigatecodeimplementingconcernsinawovenview.Althoughthetoolsisolateconcernsatahighlevel,theydonotisolateallthecodeimplementingeachconcerninasinglemodule,sothesetoolsdonotsupportviewingoreditingcodeinafullyunwovenview.1.2.1.3ProgrammingLanguagesTheliterate-programmingtoolWEB[23],likeIVCon,allowsuserstodocumentwhichconcernscodeimplements.Actually,inliterateprogramming,documentationprecedescode;usersdocumentprogramsandcanwriteproseabbreviationsforcodesegmentsbeforeexpandingthoseabbreviationsbyspecifyingtheircodeimplementations.Hence,WEBabbreviationscouldbeviewedasconcernnames,towhichcodeimplementationsgetassigned.Abbreviationscanbenestedandscatteredthroughotherabbreviations,sointhisviewliterateprogrammingsupportsmany-to-manyrelation-shipsbetweenconcernsandcode.AWEBapplicationconsistsofallthedocumentationandcodeforthatprogram;whenWEBcompilestheapplicationitproducestwosortsofles:human-readablelesdocumentingtheprogramwitheachconcern"isolated,asinIVCon'sunwovenviewandsource-code/executablelesasinIVCon'swovenview.Thesetwosortsoflespresentalternateviewsoftheprogram,butuserscannoteditoneviewandthenseethosechangesreectedintheother.Interestingly,thedocumentationproducedbyWEBcross-referencesabbreviations,whichservesapurposesimilartoagsinIVCondescribedinSection2.1.3.TheC4toolkitprovidesanaspect-orientedapproachtosystem-levelprogramming[24].AswithIVCon,C4userscanexamineprogramsin,andtranslatebetween,twocodeviews.InC4,theseviewsarecalledtheAspectCviewinwhichusersdeneaspectsinAspectCandtheC4viewinwhichusersviewadviceinlinedintotheprogramcode;theseareanalogoustoIVCon'sunwovenandwovenviews.SimilartotheVisualiser,C4inheritsAspectC'slackofsupportformulti-concerncodeanditsstatement-levelgranularityinconcerncode.Hyper/JisaJava-basedAOPLthatintroducestheconceptofahyperspace,animaginaryspaceconsistingofmultipledimensionsofconcerns[25].Eachdimension,oraxis,inthehyperspacegroupsconcerns,whileeachcoordinateonanaxiscorrespondstoasingleconcern.Hence,acodesegment'spositioninthehyperspaceindicateswhichconcernsitimplementsoneconcernperaxis9

PAGE 18

inthehyperspace.TobuildsoftwarewithHyper/J,userscreateasetoftextlesthatspecifythesetoffeaturestoincludeintheprogram.ConcernsinHyper/Jaredenedcoarselyatthegranularityofdeclarationse.g.,methods,functions,variables,andclasses.Ifalldeclarationsinaprogramareassignedtoatleastoneconcern,thenaHyper/Jusercanviewanyconcerncinthatprograminisolation,butdoingsoinvolvesmodifyingatextualconcern-mappingletospecifythatonlycshouldbedisplayedi.e.,includedintheprogram.1.2.1.4Feature-orientedProgrammingCIDEColoredIntegratedDevelopmentEnvironment[26,27]isatoolforfeature-orientedprogrammingthatwasdevelopedconcurrentlywithIVCon.CIDEhasmanysimilaritieswithbothHyper/JandIVCon:aswithHyper/J,CIDEuserscanbuildprogramsbyselectingthesetsoffeatureswhichareanalogoustoCCCsinHyper/JandIVContoincludeinthoseprograms;aswithIVCon,CIDEuserscanhighlightcodetoassignittofeaturesbeingimplemented,candenemany-to-manyrelationshipsbetweenfeaturesandcode,canassigncolorstofeatures,andcanviewcodecoloredtoreectthefeaturesbeingimplemented.However,thereareatleastfourhigh-leveldierencesbetweenCIDEandIVCon:CIDEdisplayscodeassignedtoafeaturefasblacktextonthebackgroundcoloroff.Forcodethatimplementsmultiplefeatures,CIDEdisplaysabackgroundcolorequaltothechromaticblendingofthecolorsofallfeaturesbeingimplemented.Thisdesignreliesonauser'sabilitytodecomposeanydisplayedbackgroundcolorbintothefeaturecolorsthatcombinedtoproduceb,achallengingtaskwhenmanyfeaturecolorsexistsomeofwhichmayevenbesimilartocombinationsofotherfeaturecolors.IVConattemptstoavoidthisproblembydisplayingallmulti-concerncodeinadistinctivebutuniformmanner;usersdetermineexactlywhichconcernsmulti-concerncodeimplementsbylookingineitheraseparatepaneloratooltip.ThegranularityoffeatureassignmentinCIDEiscoarserthanthegranularityofconcernassignmentinIVCon.CIDEallowsuserstoassignconcernsatthegrammaticallevelofnodesinabstractsyntaxtreesASTs,ratherthanatthelexicalleveloftokens.EveryASTnodeisavalidsequenceoftokens,butthereareaninnitenumberoftokensequencesthatare10

PAGE 19

notASTnodese.g.,standardgrammarswouldnothaveASTnodesfortokensequenceslikemethodName,methodNameparamExpr1,methodNameparamExpr1,paramExpr2,etc.Token-levelgranularityissignicantlymoreexpressivethanAST-nodegranularity.BecauseCIDErequiresthatanysetoffeaturescanbecomposedtocreatealegalprogram,CIDEuserscanonlyassigncodesegmentstofeatureswhenthosesegmentsareoptionalaccordingtothelanguage'ssyntax.IVConlackstheabilitytocreateavalidprogrambyselectinganarbitrarysetofconcernstoincludeintheprogram;therefore,IVConhasnoneedforrestrictingconcerncodetosyntacticallyoptionalsegments.Forexample,anIVConusercouldassigntheconstantinthestatementpi=3.14toaconstantsconcerntoenableviewingandeditingalltheprogram'sconstantsinasinglemoduleintheunwovenview,butsuchanassignmentisimpossibleinCIDEbecausetheconstantisnotsyntacticallyoptional.Byspecifyingaprogramtocontainexactlyonefeature,CIDEuserscanviewthatonefeatureisolatedfromtheothersbutnotisolatedfromthecoreprogramcode.However,aswithAspect-jEdit,CIDEdisplayssyntacticallyequalcodeimplementingthesamefeaturemultipletimes,soCIDEuserscannotmodifyallidenticalfeaturecodeatonceinacentralmodule.MostofthesedierencesarisenaturallyfromthedistinctobjectivesofCIDEandIVCon:CIDEandrelatedtechnologiessuchasSoftwarePlans[28]focusesonconstructingsoftwareasasetoffeatures,whileIVConfocusesoncreating,viewing,andmodifyingCCCsinisolationaswellasintheregular,wovenviewofthecode.Finally,wenotethatalthoughIVConiscloselyrelatedtoAOPLsduetoitsemphasisonmodularizingandrefactoringconcerncode,IVConcouldnotbeconsideredanAOPLtoolaccordingtoFilmanandFriedman'sdenitionofAOPLs[29].FilmanandFriedmanspecifytwonecessarypropertiesofAOPLs,obliviousnessandquantication.IVCon'swovenviewisnotobliviousbecauseitrequiresaprogrammertodocumentconcernsdirectlyinthebodyofthecode.Also,IVCondoesnotsatisfythequanticationconditionbecauseitdoesnotletusersdenejoinpointsi.e.,IVConregionsasconditionsontheprogram'scontrolow.AllowingIVConuserstodenejoinpointsasconditionsoncontrolowcouldleadtoambiguousorderofexecutionwhenweavingconcerncodeintothecore;disambiguatingconcern-codeexecutionorderingwouldrequiresomemechanismforspecifyingconcern-codeprecedence,whichwouldcomplicateIVCon'sdesign.Nonetheless,IVCon's11

PAGE 20

lackofobliviousnessandquanticationdoesnotnecessarilypreventitfrombeingusedasabasisforstandardAOPtechnologies,giventhatpreviousworkhasshownhowtobuildanobliviousandquantiedAOPLontopofanunobliviousandunquantiedaspectlanguage[30].1.3ALocation-basedPolicy-specicationLanguageAsmentionedinSection1.1,traditionalmodularizationtechniquesworkwellundertheassump-tionthatcodebeingmodularizedimplementsfunctionallyorthogonalcrosscuttingconcernssuchassecurity,auditingetc.Toexaminethisclaimfurther,wehavedesignedandimplementedLoPSiL,whichisapolicy-specicationlanguageformobiledevices[31,32].Policy-specicationlanguagesareintendedtosimplifytheprocessofspecifyingandimplementingpoliciesandtypicallytheyoperatebystaticallyrewritinganapplicationsothatthemodiedapplicationsatisesinputpoliciesatruntime.Ensuringasecureenvironmentonmobiledeviceshasgainedalotofattentionwiththereleaseofopenmobile-computingplatformssuchasAndroid,iPhone,andWindowsPhone7.Beforetheirrelease,phonemanufacturersweremostlysolelyresponsiblefordevelopingsoftwareforphones.However,withtheadventoftheseplatforms,asignicantlylargersetofpeoplearenowdevelopingsoftwareforphones.Coupledwiththefactthatphonesnowhavesignicantlyincreasedcomputingpowers,usersneedtotreatandsecuretheirphonesliketheywouldtheircomputers.However,mostuserstendtoignorethis,whichinturn,makesiteasierforamalicioususertogainunautho-rizedaccesstoausersphoneandsensitiveinformationstoredinthephone.Additionally,manyprogrammersdevelopingapplicationsfortheseopen-mobileplatformsmightnottesttheirappli-cationscomprehensivelyenoughtobeabletoguaranteenooratleastminimalsecurityholes.Thus,evenwhenasoftwaredevelopersintentmaybegood,itdoesnotnecessarilytranslateintosecuresoftware.Asaresult,wehavedesignedandimplementedapolicy-specicationlanguagecalledLoPSiLthat:Allowsuserstospecifygenericpolicies:BecauseourlanguageisTuring-complete,program-merscanspecifypoliciesthatareastrictsupersetofaccess-controlsafetypolicies.12

PAGE 21

Enablesuserstoconvenientlyenforcelocation-basedconstraintsintheirsoftware:ToensurethatLoPSiLcaterstomobileplatforms,wehavebuilt-inlocationconstructsandincludedlibrariesinLoPSiLthatenablemanipulationoflocationinformatione.g.,computingcontain-mentwithinaregion,determiningauser'svelocityetc.,sothatuserscanmoreconvenientlyexpresslocation-basedconditionsinpolicies.Atitscore,LoPSiLusesaspectsforpoliciesalthoughprogrammersspecifypoliciesintheformofJavaclasslesandAspectJ'scompilerasitsrewriter.1.3.1RelatedWorkThereareseveralpolicy-specicationlanguagesandpolicyframeworksthatarerelatedtoLoPSiL,whichwenextdiscuss.Table1.2summarizesthisdiscussion.1.3.1.1GeneralPolicy-specicationLanguagesArichvarietyofpolicy-specicationlanguagesandsystemshasbeenimplemented,whichenableuserstocentrallyspecifysecurityandprivacypoliciestobeenforcedonuntrustedsoftwareatruntime.Ponder[33],XACML[34],PoET/PSLang[2],Naccio[3],Polymer[4],andDeeds[35]areexamplesofexpressivei.e.,Turing-completepolicy-specicationlanguages.However,noneoftheselanguagesprovideuserswithbuilt-inconstructsformanipulatinglocationinformation.1.3.1.2FormalLanguagesSpatialPisaTuring-completelanguageinwhichpoliciescanmakedecisionsaboutapro-gram'sactionsbasedonthelocationoftheuser[36].However,userscanspecifyonlyequalityandcontainmentconditionsonlocations,soSpatialPuserscanmanipulatelocationinformationinonlylimitedways.Forexample,userscannotspecifyconditionsthatcapturetheirbeingwithinacertaindistanceofaxedpoint.Thus,SpatialPcannotbeusedtospecifypoliciessuchastheDeviationFromPathandSocialNetworkingshowninFigures4.2and4.4,anddiscussedinSection4.2.1.Also,asfarasweareaware,SpatialPdoesnothaveanimplementation.13

PAGE 22

Table1.2.Comparisonofpolicy-specicationlanguages. Language Provides Turing Allowsexible Provides location complete manipulationof policy constructs locationinformation composition Ponder p XACML PoET/PSLang p Naccio p Polymer p p Deeds p SpatialP p p OpenAmbient p p Geo-RBAC p p Android'sbuilt-inSecurity p p LoPSiL p p p 1.3.1.3Location-basedAccess-controlLanguagesThereareotherpolicy-specicationlanguagesthatdohaveprimitivesformanipulatinglocationinformation,butasfarasweareaware,noneoftheselanguagesareTuring-complete,whichpreventsspecicationofarbitrarypolicies.Forexample,OpenAmbient,anaccess-controlarchitectureforwebservices,providesapolicy-specicationlanguageinwhichpoliciescanreasonaboutlocationinformationaspartofthesystem'sambientstatebutcannotmaintainastateoftheirown[37,38].Notbeingabletomaintainstatepreventspoliciesfrombasingdecisionsonpreviouspolicyactionsandexecutingarbitrarycodeinresponsetoapplicationactions.Forthesereasons,itwouldbeimpossibletospecifytheDeviationFromPathandSocialNetworkingpoliciesusingOpenAmbient.14

PAGE 23

Anotherlocation-basedbutTuring-incompletepolicy-specicationlanguageisGeo-RBAC[39].TheTuring-incompletenessofGeo-RBACderivesfromitstargetingonlyRBACrole-basedaccess-controlpolicies,whicharesafetypoliciesandthereforeapropersubsetofthepoliciesenforceableatruntime[40].Inaddition,roleassignmentandlocationinformationarexedpersessioninGeo-RBAC,sopoliciesonsystemswithdynamicallychangingrolesorlocationse.g.,thepoliciesinFigures4.2{4.4couldnotbespeciedwithGeo-RBAC.RayandKumardescribeaformal,Turing-incompletemodelthatextendsaMACsystemwithlocationprimitives[41].Theydescribehowthelocationofasubjectandanobjectcanbeusedtomakedecisionsaboutgrantingsubjectsaccesstoobjects,whilekeepingthelocationsofsubjectsandobjectsprivatefromeachother.However,becausetheirmodelisanaccess-controlsafetypolicymodel,userscannotspecifypoliciessuchasDeviationFromPathandSocialNetworking.1.3.1.4Android'sBuilt-inSecurityMechanismTheAndroidoperatingsystemenforcesmandatoryaccess-controlinAndroidapplications[42,43].Usersspecify,inanXMLmanifestle,permissionsthatmediatebothincomingandoutgoingrequestspertainingtothevariouscomponentsoftheirapplicationi.e.,usershavetospecifyre-sourcesthattheirapplicationwillaccess,andservicesthatcanaccesstheusers'application.Userscanalsospecifypoliciesthatrunarbitrarycodetodecidewhetherpermissiontoaresourceshouldbegrantedornot;thisisachievedbymodifyingamethodcalledcheckPermission.Also,be-causeAndroidprovidesuserswithprimitivestomanipulatelocationinformation,userscanutilizetheseprimitivesinthecheckPermissionmethodtospecifylocation-basedaccess-controlpoli-cies.However,theAndroidsecurityframeworkdoesnotenableuserstospecifyandenforceruntimepolicies,sotheexistingframeworkinAndroidcannotbeusedtointerceptuseractionsanddecidewhetherornottoallowthoseactionstobeexecuted.Asaresult,Android'sbuilt-inenforcementsystemislimitedtoaccess-controlpoliciesandthereforesimilarlytoGeo-RBACandthemodelofRayandKumar,cannotenforcemoregeneralruntimepoliciessuchasDeviationFromPathandSocialNetworking.15

PAGE 24

1.4ContributionsTherstpartofthisthesisdiscussesthemodularizationofcrosscuttingconcernsusingIVCon,anIDEthatenablinguserstoexiblyassignconcernsintheircodebyallowinguserstoexplicitlyassigndierentpartsoftheircodetotheconcernsthattheyimplement.IVCondiersfromexistingconcern-managementtoolsbyprovidingacombinationoftranslationsbetweenwovenandunwovenviewsmany-to-manyrelationshipsbetweenconcernsandcode,isolatingcon-cerncodeintheunwovenview,centrallymodifyingidenticalconcerncode,andtoken-levelgranularityinconcernassignment.Thereafter,wediscussthemodularizationofruntimesecuritypoliciesusingLoPSiL,apolicy-specicationlanguagethatusesaspectstomodularizesecurityimplementations.Asfarasweareaware,LoPSiListherstTuring-completelanguagethatprovideslanguageconstructsthatenableuserstomanipulatelocationinformationconveniently.Thisthesisderivesfromourearlierwork[44,31,45,46,47,48,32],buttiesittogethertopresentacompletetreatmenttothemodularizationofCCCsinsoftware.Morespecically,thisthesisextendspreviousworkbyansweringthefollowingquestions:Howadualviewofsoftwareandtheabilityforprogrammerstodenemulti-concerncodeaidssoftwarecomprehension,andhowthesefeatureshelpduringtheprocessofsoftwaremaintenance?Whetherornot,thebenetsachievedbyusingdualviewsofsoftwareandmulti-concerncodecanbeachievedwithinreasonableoverheads,intermsofauser'seort?Howsuitablearetraditionalmodularizationconstructsi.e.,methods,classes,andaspectsformodularizingcodethatimplementsmultipleconcerns?Additionally,howsuitablearethesameconstructsformodularizingfunctionallyorthogonalconcerncode?Whatkindoflanguageconstructsareusefulforpoliciesthatreasonaboutaprogram'sexe-cutionbasedonasystem'slocation?Morespecically,doesourlanguageLoPSiLprovideusefulconstructsforspecifyingsuchpolicies?16

PAGE 25

Whatkindofpolicieswouldbeusefultospecifyandimplementinalanguagethatenablesuserstospecifylocation-basedpolicies?Furthermore,howconvenientisittospecifythosepoliciesinLoPSiL?1.5ThesisOrganizationTherestofthisthesisisorganizedasfollows:Chapter2describestheuserinterfaceandimple-mentationdetailsofourprototypeofIVCon,Chapter3discussesthemodularizationofruntimepoliciesalongwithimplementationdetailsofourproof-of-conceptLoPSiLcompiler,Chapter4dis-cussesthevalidityofourapproachbyoutliningourexperiencesworkingwithIVConandLoPSiL,andananalysisoftheirperformanceoverheads,andChapter5concludes.17

PAGE 26

CHAPTER2ANIMPLEMENTATIONOFIVCONThischapterdescribestheuserinterfaceandimplementationdetailsofourprototypeimple-mentationofIVCon.2.1UserInterfaceIVCondisplayscodeintwodierentbutequivalentforms:thewovenviewFigure2.1andtheunwovenviewFigure2.2.Userscantranslatetheircodebetweenthetwoviewssimplybyselectingtheweaveorunweavemenuoptions,orbypressingor.2.1.1WovenViewInthewovenview,showninFigure2.1,userscanwritecodeastheynormallywouldinastandardtexteditorordevelopmentenvironment.Inaddition,userscandeneconcerns,associateacolorwitheachconcern,andhighlightandexplicitlyassigncodesegmentstoconcernsbyright-clickinghighlightedcodeandselectingtheconcerntowhichtoassignit.Uponassigningacodesegmenttoaconcern,IVConrecolorstheassignedcodetomatchtheconcernitimplements.IVCondisplayscodeassignedtomultipleconcernsinwhitetextonadarkbackground,thoughusersarefreetochangethismulti-concernbackgroundcolor.Byhighlightingacontiguouscodesegmentandassigningittoaconcern,auserdenesaregioninthecode.Everyregionstartsatthebeginningofcodeassignedtoaconcernandextendsasfarasthecodedoesthatimplementsthatconcern.Multipleconcernscansharethesameregionifcodeimplementingthoseconcernsbeginsandendsatexactlythesamepositionsintheprogramle.AlthoughIVConrequiresauser-speciednameforeveryuniqueregionauserdenes,italwaysprovidesadefaultnameforregionsbasedonthenameoftheconcerntowhichtheregionisbeingassigned.DefaultregionnamesprovidedbyIVConareoftheformatregion concernname i,18

PAGE 27

Figure2.1.IVCon'swovenviewofthesamecodeshowninFigure2.2.whereiisthenumberofregionsthathavebeenpreviouslydenedfortheconcernconcernname.Forexample,ifauserhasdenedthreeregionsforthesecurityconcerninale,thedefaultnamethatIVConprovidesforthenextregionthatgetsassignedtothesecurityconcernwouldberegion security 3.Also,ifapreviouslydenedregiongetsassignedtoanewconcern,IVConsimplyreusestheexistingregionname.Specifyingnamesforregionshelpsusersunderstandwheresubconcernsareimplemented,asdiscussedinSection2.1.2.Figure2.1showsthewoven-viewwindowdividedintothreepanels:concernslegend,wovenbody,andconcernsatcurrentposition.Theconcerns-legendpanellistsalltheuser-denedconcernsinthecurrentle.IVCondisplaysthenameofeachconcerninthecolorassociatedwiththatconcern.Thewoven-bodypanelcontainsusercodedisplayedincolorsthatindicateconcernassign-ments.Theconcerns-at-current-positionpanelliststheconcernsimplementedbythecodeatthecurrentcursorposition.Apartfromcreatingandmodifyingcode,deningconcerns,andassigningcodetoconcerns,userscaneditconcernnames,editconcerncolors,removeconcerns,de-assigncodefromconcerns,19

PAGE 28

Figure2.2.IVCon'sunwovenviewofthesamecodeshowninFigure2.1.changethemulti-concernbackground,renameregions,andopen,save,andcloselesinthewovenview.2.1.2UnwovenViewTheunwovenview,showninFigure2.2,displaystheprogramcoreandeachconcerninisolation.Theunwoven-viewwindowisthesameasthewoven-viewwindow,exceptthattheunwoven-viewdividesthewoven-bodypanelintotwosubpanels:unwovenbodyandunwovenconcerns.Theunwoven-bodypaneldisplaysthecoreoftheprogram.Codethathasbeenassignedtooneormoreconcernsisextractedintotheunwoven-concernspanelandreplacedbyholes2ofthesamecolorastheextractedcode.Everycontiguouscodesegmentthathasbeenassigned20

PAGE 29

Figure2.3.Concern-moduleformattinginIVCon.tothesamesetofconcernsgetsreplacedbyoneholeexplainedfurtherinSection2.2.2.1.Thus,holesintheunwoven-bodypanelindicateextractedconcerncode.Theunwoven-concernspaneldisplaysinisolationeachoftheprogram'sconcernsasextractedfromtheunwovenbody.Eachconcernisdividedintosubconcerns,whicharesyntacticallydierentcodesegmentsassignedtothesameconcern.IVCondisplayssubconcernsintwoparts:alistoftheregionsinwhichthesubconcernappearsandthenthesubconcerncodeitself.Asanexample,readerscanlookatFigure2.3toseeconcernmodulesforsecurityandauditconcernsfortheexamplecodefromFigure2.1.Onclickinganyregionnameintheunwoven-concernspanel,IVConautomaticallyfocusestheunwoven-bodypaneltoshowthatregion'slocationinthecontextoftheprogramcore.21

PAGE 30

UnwovenBody:ifbuffer.getSize>2buffer.truncate2;ifgetTimeElapsed>2JOptionPane.showMessageDialogframe,"Requesttimedout","Error",JOptionPane.ERROR MESSAGE;UnwovenConcerns:concernconstantfsubconcern@max buffer size 0@max buffer size 1x512xsubconcern@timeout ms 0x2000xgFigure2.4.UnwovenviewofthecodeinFigure2.5.CodeforthesecurityconcerninFigure2.3indicatesthepresenceoftwosubconcernsatregionsbefore protected readandafter protected read.ThecodesegmentsbeginningwithifcheckCredentialsandaccessLog.appendimplementthosesubconcerns.Similarly,codefortheauditconcernindicatesthepresenceofthreesubconcernsatregionsfile read granted,file read denied,andafter protected read.Theunwoven-concernspanelmayalsocontainconstructscalledagse.g.,securityjjjjjandjjjjjsecurity,whichconveyinformationaboutconcernas-signmentinmulti-concerncodesegments.Section2.1.3providesadditionalexplanationofIVConags.Figure2.3alsodemonstratestheusefulnessofhavingdescriptive,user-speciednamesforre-gions.Descriptiveregionnameshelpsoftwareengineersquicklyunderstandwheresubconcerncodeexistsinrelationtotherestoftheprogramlogic.Nonetheless,ifaregionnameprovidesinsucientcontextualinformation,theusercanalwaysclickonthenametoseethatregion'scontextintheunwoven-bodypanel.22

PAGE 31

WovenBody:ifbuffer.getSize>512buffer.truncate;ifgetTimeElapsed>2000JOptionPane.showMessageDialogframe,"Requesttimedout","Error",JOptionPane.ERROR MESSAGE;Figure2.5.WovenviewofthecodeinFigure2.4.Asanotherexample,letusconsiderFigure2.4,whichshowshowIVCongroupsintoonesub-concernallsyntacticallyequalcodeassignedtothesameconcern.Figure2.5containsthewovenviewofthesameprogram.Inthewovenview,theuserhasdenedaconcernnamedconstantandhasassignedthetwoconstants512and2000tothatconcernIVCon'stoken-levelgranularityinconcernassignmentenablessuchoperations.Normally,programmersusingstandardsoftware-developmenttoolswoulddenethesevaluesinmemorydeclaredimmutableandwouldalwaysrefertotheconstants'valueswithvariableslikeMAXBUFFERSIZEandTIMEOUTMS.Thistechniqueenablestheprogrammerstomakeaglobalchangetoaconstantvaluebymodifyingjustonecentraldef-inition.However,thisbenetcomesatthepriceofnotbeingabletoimmediatelyseethevaluesofconstantsinthesourcecode.Incontrast,IVCon'sdualwovenandunwovenviewsprovidebothbenets:userscanupdateconstantvaluescentrallyintheconstantconcernoftheunwoven-concernspanelandcanviewtheconstantvaluesdirectlyinthesourcecodeinthewoven-bodypanel.Actually,IVConprovidestheaddedbenetthatuserscanseeintheunwoven-concernspanelaregion-namereferencetoeveryuseofeveryconstantandcanclickanyofthoseregionnamestoseethecontextofthatuseintheunwoven-bodypanel.Ofcourse,thisexampleisjustaspecialcaseofthegeneraluseofIVContoprovidebothaglobali.e.,wovenviewofthecodeandaconcern-specici.e.,unwovenviewofthesamecode.IVCon'sunwovenviewallowsuserstocreateandeditcore-programcodeintheunwoven-bodypanelandconcerncodeintheunwoven-concernspanel.ToavoidambiguityintheweavingalgorithmdescribedinSection2.2.2.2,IVCondoesnotallowuserstodeleteholesintheunwoven-bodypanelortoeditnon-concerncodee.g.,concernandregionnamesintheunwoven-concernspanel.23

PAGE 32

2.1.3DisplayofMulti-concernCodeThewovenviewdisplaysmulti-concerncodeinwhitetextoverthemulti-concernbackground,whiletheconcerns-at-current-positionpanelindicateswhichconcernsthecodeatthecurrentcur-sorpositionimplements.Similarly,theunwovenviewdisplaysmulti-concerncodeintheunwoven-bodypanelasaholecoloredwhiteoverthemulti-concernbackground,whiletheconcerns-at-current-positionpanelcontinuestoindicatewhichconcernstheholeatthecurrentcursorpositionimplements.Inaddition,theunwoven-concernspanelusesagstoconveyinformationabouttheconcernsassociatedwithmulti-concerncodeasmentionedinSection2.1.2.Flagsserveasaquickreferenceforvisualizingwhereoverlappingconcernsbeginandend.Toillustratetheuseofags,considerthecodeinFigure2.2thatimplementsthesecurityconcernatregionbefore protected read.InthewovenviewFigure2.1,weassignedthiscodesegmenttothesecurityconcern,andweassignedthetwonestedstatementsbeginningwithaccessLog.appendtotheauditconcern.Asaresult,theunwoven-concernspanelinFigure2.2displaysgreenagsauditjjjjjandredagsjjjjjaudittoindicatethenestingofaudit-concerncodewithinthesecurity-concerncode.Greenandredagswithintheunwoven-concernspanelindicatethebeginningandendingofoverlappingconcerns.Greenandredagsdonotalwaysappeartogetherwithinasubconcern;dependingontheoverlapbetweenconcernregions,theremaybeagreenagonly,aredagonly,bothgreenandredags,ornoagsatallwithinsubconcerncode.Also,multipleredandgreenagsofthesameconcern,ormultipleagsofvariousconcerns,maybepresentwithinasubconcern.ThesyntaxofcodeinIVCon'sunwoven-concernspanelincludesags,sotwosubconcernsaresyntacticallyequalifandonlyifthetextofthosetwosubconcerns|includingagswithinthesubconcerns|isthesame.Thus,thesubconcernaccessLog.append``Filereadcomplete.''isnotsyntacticallyequaltosecurityjjjjjjaccessLog.append``Filereadcomplete.''jjjjjjsecurity.Thisdistinctionmattersbecause,asdescribedinSection2.1.2,syntacticallyequalsubconcernsaregroupedtogetherintheunwoven-concernspanel.IfIVCondidnotconsideragswhentestingforconcern-codeequality,itwouldgroupbothaccessLog.append``Filereadcomplete.''andsecurityjjjjjjaccessLog.append``Filereadcomplete.''jjjjjjsecurityintoasinglesubconcern,butthepresenceorabsenceofsecurityagsinsuchasubconcernwould24

PAGE 33

beconfusingbecauseoneoftheinstancesofthissubconcernhasanestedsecurityregion,whiletheotherdoesnot.2.2ImplementationDetailsWehaveimplementedaprototypeofIVConinJava;thesourcecodeisonline[49].ThecoreIVConapplicationconsistsof7961linesofcodeclassesin15les,ofwhich7788implementtheGUIand173implementbackenddatastructures.IVConalsousesseveralthird-partylibrariese.g.,clipboardandlexical-analysislibrariesforauxiliaryfunctions.2.2.1DataStructuresIVConmaintainsthreekeydatastructures.AregionMapisahashtablethatmapsanumericalregionidentierneededfortheRTreeimplementationdescribedbelowtothatregion'suser-visiblename,beginningandendingpositionsfortheregion,andalistoftheconcernstowhichtheregionhasbeenassigned.AconcernMapisahashtablethatmapsauniqueconcernnametothatconcern'sdisplaycolorandalistoftheregionsassignedtothatconcern.AregionTreeisanRTree,adynamicstructureforstoringdataaboutpotentiallyoverlappingregionsinspace[50,51].Whenqueriedaboutaparticularregionr,anRTreecanecientlyreturnthesetofstoredregionsthatoverlapr.RTreesareidealdatastructuresforIVConbecausetheyenableecientqueryingtodeterminewhichregionsaredenedatagivencharacterpositioninthesourcelee.g.,atthepositionofthecursororwithinanewlydenedregion.OnceIVCondetermineswhichregionsarepresentatagivenposition,itcanusetheregionMaptolookupalltheconcernsassignedtothoseregions.IVConusesthislook-upoperationwhileweavingandunweavingcode,andwhiledisplayingconcernsintheconcerns-at-current-positionpanel.TogetherthesestructuresenablereasonableperformanceinallofIVCon'scoreoperations.25

PAGE 34

2.2.2TranslationAlgorithmsGivenaregionMap,concernMap,andregionTree,itisgenerallystraightforwardtoimplementthetranslationsbetweenwovenandunwovenviews.2.2.2.1UnweavingUnweavingistheprocessoftranslatingawoven-viewprogramintoanequivalentunwoven-viewprogram.UnweavinginIVConbeginswithlexicalanalysistoenforcetoken-levelgranularityinconcernassignment.Afterlexicalanalysis,IVConstartswiththewovencodeintheunwoven-bodypanelanditeratesthroughallconcernsintheconcernMap,extractingthecodeinallofthatconcern'sregionsfromtheunwoven-bodypaneltotheunwoven-concernspanel.Extractedconcerncodegetsreplacedwithholes2oftheappropriatecolorintheunwoven-bodypanel.Duringtheextractionprocess,IVCongroupsconcerncodeintosyntacticallyequalsubconcernsintheunwoven-concernspanelanddisplaysisolatedconcernsintheformatdescribedinSection2.1.2.Althoughtheunweavingalgorithmjustdescribedisstraightforward,oneinterestingissuearoseduringimplementation.Theissueconcernshowtodisplayholesinplaceofoverlapping,butunequal,regions.Forexample,letusreconsiderthewoven-bodycodeofFigure2.1.Inthatgure,aprogrammerhasassignedanentireifstatementtothesecurityconcernandhasnestedtwoaudit-concernregionswithinthatsecurityregion.Therearetworeasonablealternativesforunweavingthisifstatement:Wecouldreplacetheentireifstatementwithoneholeofthemulti-concerncolortoindicatethatoneregionofcode,whichintotalimplementsmultipleconcerns,hasbeenextracted.Wecouldreplacetheentireifstatementwithveholesthatalternatebetweenthesecurity-concerncolorandthemulti-concerncolor,toindicatethattheextractedcoderstcontainssecurity-concerncode,thensomemulti-concerncode,thenmoresecurity-concerncode,andsoon.26

PAGE 35

Becauseitprovidesmorepreciseconcern-assignmentinformation,weimplementedthesecondofthesealternativesinIVCon.Figure2.2showstheresultingve-holeconcernextractionintheunwoven-bodypanel.2.2.2.2WeavingWeavingistheprocessoftranslatinganunwoven-viewprogramintoanequivalentwoven-viewprogram.Toweave,IVConbuildsthewovenbodyfromtheunwovenbodybyiteratingthroughalltheholesintheunwovenbodyandllingineachholewiththeappropriateconcerncode.Whiledesigningtheweavingalgorithm,oneinterestingissuearose,whichrelatestollingmulti-concernholeswithcode.Becauseacodesegmentthatllsinamulti-concernholehasbeenassignedtomultipleconcerns,itappearsinmultipleplacesintheunwoven-concernspanel.Theinterestingissueoccurswhentheusermodiesmulti-concerncodeinoneplacebutnotanotherintheunwoven-concernpanel.Suchamodicationleadstocodeinconsistencieswhenllingmulti-concernholesi.e.,whichoneoftheconcernmodulesshouldbeusedforllingamulti-concernhole.Toensurethatsuchcodeinconsistenciesdonotoccur,wehaveimplementedlinkededitingintheunwoven-concernspanel[52].Codesegmentsintheunwoven-concernspanelthatllinthesamemulti-concernholegetlinkedatruntime,soanychangesmadeinonecodelocationgetreectedimmediatelyinalltheothercodelocationsthatllinthesamehole.2.2.3Third-partyLibrariesIVConalsousesseverallibrariesandcodethatwedownloadedfromthird-partysources:RTrees:IVConuseRTreesasmentionedearlierinSection2.2.1toecientlydeterminewhatconcernsareassignedtoaparticularpointinauser'sprogram.WeresearchedotherspatialdatastructuressuchastheP-RTree[51],IBSTree[53]andskiplists[54].However,wehadaproblemndingacorrectimplementationoftheP-RTree;IBSTreeandskiplistswerenotsuitedtoourpurposebecausetheydonotallowdynamicadditionordeletionofintervals,whichisimportantforIVConasusersdeneregionsdynamically.IVConusesHadjieleftheriou'simplementationofRTrees[55].27

PAGE 36

JavaCC:IVConalsousesJavaCC,aJava-basedparsergenerator,whichisavailableon-line[56].JavaCC'sdownloadablepackageincludesseveralgrammars,includingthatofJava.BymodifyingthegrammarlesforJava,wewereabletogenerateaJavalexer,whichweuseinourweavingandunweavingalgorithmstoverifythelexicalvalidityofuserprogramsandtoenforcetoken-levelgranularity.Clipboard:IVConusesathird-partyclipboardimplementationtoimplementthecut,copy,andpastefunctionalitiesinallofIVCon'suser-editablepanelsi.e.,woven-body,unwoven-body,andconcerns-at-current-positionpanels[57].28

PAGE 37

CHAPTER3MODULARIZINGRUNTIMESECURITYPOLICIESInordertopreventmaliciousactivityoncomputers,programmershavetoensurethattheirsoftwarebehavesinwaysthatitisintendedto.Malicioususersoftenexploitsecurityholesinasystem'simplementationtogainunauthorizedaccesstocomputersortoexecutemaliciouscodeoncomputers.Forexample,amalicioususercanexploittheweaktype-safetyofaweakly-typedortype-unsafelanguagetolaunchabuer-overowattackonasystemimplementedinthatlanguage.However,byincorporatingsecuritychecksatappropriateplacesintheircode,userscanavoidsuchattacks.Forexample,tocounterthebuer-overowattackmentionedabove,auserwouldprecedeeveryinstanceofamemory-accesswithcodethatensuresthatthememoryisaccessedinsafeways.However,suchsecuritychecksoftenbecomescatteredacrossasoftware'simplementation,andtherebytedioustomaintain.Toensurethatsecuritychecksdonotgetscattered,securityengineersmodularizesuchsecuritychecksintopoliciesusingpolicy-specicationlanguages.Policy-specicationlanguagesaredomain-specicprogramminglanguagesintendedtosimplifythetasksofspecifyingandenforcingsoundsecuritypoliciesonuntrustedi.e.,potentiallyinsecuresoftware.Typically,theselanguagesareimplementedascompilersthatconvertuntrustedintotrustworthyapplicationsbyinputtingapolicyPandanapplicationprogramAandoutputtinganewapplicationprogramA0equivalenttoA,exceptthatA0containsinlinedenforcementcodethatensuresthatA0satisesPatruntime.Policy-specicationlanguagesenableuserstospecifypoliciescentrallyandprovideuserswithallothermodularizationbenetsi.e.,theymakesecuritycodeeasytoread,understand,andmain-tain.Traditionalmodularizationtechniquesthatdonotcapturethemulti-concernnatureofcodecanbeusedtomodularizesecuritypoliciesbecauseinmostapplications,securityisfunctionallyorthogonaltotherestofthecode.29

PAGE 38

Inthischapter,wediscussthemodularizationofruntimepoliciesusingLoPSiL,apolicy-specicationlanguagethatwehaveimplemented,whichasfarasweknow,istherstTuring-completepolicy-specicationlanguagethatprovidesuserswithlanguageconstructsthathelpuserstoconvenientlymanipulatelocationinformation.LoPSiLisshortforLocation-basedPolicy-specicationLanguage.WestartwithadiscussionofLoPSiL'slinguisticconstructsanduseanelementarypolicytoshowhowpoliciesareimplementedinLoPSiL.Thereafter,wedescribetheimplementationofourproof-of-conceptLoPSiLcompiler.3.1LoPSiLDuetothepopularityofJava,particularlyJavaME,asanapplicationprogramminglanguageformobiledevices[58],wehavechosentodesignandimplementLoPSiLconstructsinJavasourcecode.Also,tomakeiteasyforsecurityengineerstolearnanduseLoPSiL,andtosimplifytheimplementationofaLoPSiLcompiler,wehavepackagedLoPSiLasaJavalibrary,towhichLoPSiLpoliciesmayrefere.g.,aLoPSiLpolicymayrefertotheLocationclassintheLoPSiLlibrary.AlthoughwetreatLoPSiLinaJavacontextinthispaper,wehavebuiltLoPSiLonsixcoreabstractionsthatareapplication-languageindependent,soweexpectLoPSiLtobeportabletootherlanguagesandplatforms.3.1.1CoreLinguisticConstructsLoPSiLisbuiltonsixcoreabstractions;wedescribeeachinturn.Locations:InLoPSiL,Locationsarepossiblyabstractplaces.Theymayrefertorooms,chairs,oors,buildings,campuses,GPScoordinates,regionsofanetworktopology,etc.AllLocationshaveanidentitye.g.,aroomorbuildingname,orcoordinatesinGPS.LoPSiLprovidesmanybuilt-inutilitymethodsformanipulatingGPSlocationse.g.,tocalculatedistancesbetweenthem,astheexamplesinSection4.2.1demonstrate.However,LoPSiLusersarealwaysfreetoimplementcustommethodsformanipulatinglocationse.g.,todeneacontainmentrelationoverlocations,usefulfortestingwhetheraroomisinabuilding,abuildingisonacampus,etc.30

PAGE 39

LocationDevices:ALocationDeviceisLoPSiL'sinterfacetoreal-timelocationinformation.ConcreteLocationDevicesmustimplementtwoabstractmethods.Therstsimplyinformspoliciesofthedevice'scurrentlocation,whichcouldbedeterminedusingGPSorbyinputtinglocationinformationfromauser,ale,anothernetworkedhost,aTLTAdevice[59],etc.ThesecondabstractmethodLocationDevicesmustimplementinformsLoPSiLpoliciesofthedevice'sgranularity,thatis,withwhatprecisionisthedevice'slocationinformationaccuratee.g.,accuratewithin1meter,1room,1road,1building,1kilometer,etc.LoPSiLpoliciescanrequiredevicestoprovidelocationinformationwithparticulargranularitythresholds.OurLoPSiLimplementationincludesconcreteimplementationsoftwoLocationDevices,butusersarealwaysfreetoimplementothers.TherstLocationDeviceprovidedwithLoPSiLrepresentsandconnectstoaGarminGPSdeviceusingJava'scommunicationAPIandtheGPSLib4Jlibrary[60];thesecondLocationDevicerepresentsandconnectstoasimpleGUIwithwhichuserscanmanuallyselecttheircurrentlocationfromalistofknownlocations.PolicyAssumptions:LoPSiLpoliciesmaymaketwoimportantassumptionsaboutLocationDevices.First,asmentionedabove,apolicymayrequirelocationinformationwithaparticulargranularitye.g.,accuratewithin15m.Second,apolicymayrequirethatlocationupdatesarrivewithaparticularfrequencye.g.,anewupdatemustarrivewithin10softhepreviousupdate.LoPSiLpoliciesencapsulatetheseassumptions,alongwiththeLocationDeviceswhoselocationdatatheytrust,inaPolicyAssumptionsobject.ALoPSiLpolicygetsnotiedautomaticallywheneveraLocationDeviceviolatesthepolicy'sgranularityorfrequency-of-updatesassumptions.Actions:AnActionencapsulatesinformationaboutasecurity-relevantmethodi.e.,anyJavaapplicationorlibrarymethodofrelevancetoaLoPSiLpolicy.LoPSiLpoliciescaninterposebeforeandafteranysecurity-relevantactionexecutes;thepolicyspecicationthendetermineswhetherthatactionisallowedtoexecute.PoliciesmayanalyzeActionobjectstodeterminewhichsecurity-relevantmethodtheactionrepresents,thatmethod'ssignature,run-timearguments,andcallingobjectifoneexists,whetherthemethodisabouttoexecuteorhasjustnishedexecuting,andthereturnvalueoftheactionifithasnishedexecuting.31

PAGE 40

Reactions:LoPSiLpoliciesconveydecisionsaboutwhethertoallowsecurity-relevantActionstoexecutebyreturning,foreveryActionobject,aReactionobject.AnOKreactionindicatesthattheactionissafetoexecute;anexceptionreactionindicatesthattheactionisunsafe,soanexceptionshouldberaisedwhichtheapplicationmaycatchinsteadofallowingthemethodtoexecute;areplacereactionindicatesthattheactionisunsafe,soaprecomputedreturnvalueshouldbereturnedtotheapplicationinplaceofexecutingtheunsafeaction;andahaltreactionindicatesthattheactionisunsafe,sotheapplicationprogramshouldbehalted.Policies:LoPSiLpoliciesincorporateallofthepreviouslydescribedlanguageconstructs.TherearevepartstoaLoPSiLPolicyobject:{ApolicymaydeclarePolicyAssumptionsuponwhichitrelies.{ApolicymaydeneahandleGranularityViolationmethod,whichwillbeinvokedwheneverallLocationDevicesuponwhichthepolicyreliesviolatethepolicy'slocation-granularityassumption.{ApolicymaydeneahandleFrequencyViolationmethod,whichwillbeinvokedwhen-everallLocationDevicesuponwhichthepolicyreliesviolatethepolicy'sfrequency-of-updateassumption.LoPSiL'sPolicyAssumptionsclassimplementsthemultithreadingneededtotestforfrequency-of-updateviolations.{ApolicymaydeneanonLocationUpdatemethod,whichwillbeexecutedanytimeanyLocationDeviceassociatedwiththepolicyupdatesitsLocationinformation.Thismethodenablesapolicytoupdateitssecuritystateandtakeotheractionsaslocationupdatesoccurinrealtime.{Apolicymustdeneareactmethodtoindicatehowtoreacttoanysecurity-relevantmethod.LoPSiLrequireseverypolicytocontainareactmethod,ratherthanprovidingadefaultallow-allreactmethod;hence,policyauthorswantingtoallowallsecurity-relevantmethodstoexecuteunconditionallymustexplicitlyspecifytheirpolicytodoso.32

PAGE 41

publicclassAllowAllextendsPolicy{publicLocationDevice[]devices={newLopsilGPSLopsilGPS.GARMIN};publicLocationGranularityAssumptionlga=newLocationGranularityAssumption,Units.METERS;publicFrequencyOfUpdatesAssumptionfoua=newFrequencyOfUpdatesAssumption,Units.SECONDS;publicPolicyAssumptionspa=newPolicyAssumptionsthis,devices,lga,foua;publicvoidhandleGranularityViolation{System.exit;}publicvoidhandleFrequencyViolation{System.exit;}publicsynchronizedvoidonLocationUpdate{System.out.println"newlocation="+devices[0].getLocation;}publicsynchronizedReactionreactActiona{returnnewReaction"ok";}}Figure3.1.SimpleLoPSiLPolicythatallowallactionstoexecute3.1.2ExampleLoPSiLPolicyFigure3.1containsasimpleLoPSiLpolicycalledtheAllowAllpolicythatcontainsallveofthecomponentsillustratedintheprevioussection.TheAllowAllpolicyprintslocationin-formationasitisupdated,andallowsallsecurity-relevantmethodstoexecute,aslongasitslocation-granularityandfrequency-of-updateassumptionsarenotviolated.WedescribeseveralotherpoliciesimplementedinLoPSiLinSection4.2.1.Existingpolicy-specicationlanguages,suchasNaccio[3],PSLang[2],andPolymer[4,5],provideconstructssimilartoourActions,Reactions,andPolicymoduleswithreact-stylemeth-ods.LoPSiL'snoveltyisitsadditionofoptionallocation-relatedpolicycomponents:Locations,LocationDevices,granularityandfrequency-of-updateassumptions,andmethodstohandlegran-ularityandfrequency-of-updateviolationsandtotakeactionwhenlocationstategetsupdatedwiththeonLocationUpdatemethod.3.2ALoPSiLCompilerThissectiondescribesourimplementationofLoPSiLandbrieyreportsonourexperiencesdesigningandimplementingLoPSiLpolicies.TheimplementationsofLoPSiL'sbasicLocation,33

PAGE 42

voidjava.io.PrintStream.println..*javax.swing.JOptionPane.*..java.util.Date.newFigure3.2.Example.srmleindicatingthattheaccompanyingLoPSiLpolicyconsidersse-curityrelevantallvoid-returningjava.io.PrintStream.printlnmethods,allmethodsinthejavax.swing.JOptionPaneclass,andtheparameterlessconstructorforjava.util.Dates.LocationDevice,Action,Reaction,andPolicymodulesoccupy1588linesofJavacode,whiletheimplementationsofourGarminGpsDeviceandLopsilWindowDevicerespectivelyoccupy847and107linesofJavacode.Ourimplementationisavailableonline[61].3.2.1CompilerArchitectureALoPSiLcompilerneedstoinputaLoPSiLpolicyandanuntrustedapplication,buildatrustworthyapplicationbyinsertingcodeintotheuntrustedapplicationtoenforcetheinputpolicy,andthenoutputthetrustworthyapplication.Thestandardtechniqueforimplementingsuchacompilerinvolvesinliningpolicycodeintotheuntrustedapplication.Severaltoolsexistforinliningcodeintoanapplication;aconvenienttoolforourpurposesisanAspectJcompiler[62].AspectJcompilersinlinecallstoadviceatcontrol-owpointsspeciedbypointcuts.Inthedomainofruntimepolicyenforcement,advicereferstopolicy-enforcementcodeandpointcutstothesetofsecurity-relevantmethods.Wewishtointerposeandallowpolicy-enforcementcodetoexecutebeforeandafteranysecurity-relevantmethodinvokedbytheuntrustedapplication.LoPSiLusersconvertanuntrustedapplicationintoatrustworthyapplicationasfollows.Theusercreatesaspecicationofthedesiredpolicyina.lopsille.TheuseralsocreatesalistingofallthemethodsthedesiredLoPSiLpolicyconsiderssecurityrelevant.Thislistingindicatestothecompilerwhichapplicationandlibrarymethodsitneedstoinsertpolicy-enforcementcodearound.Policiesgettointerposeanddecidewhetherandhowallsecurity-relevantmethodsmayexecute.Thelistingofsecurity-relevantmethodsgoesintoa.srmle,onemethodsignatureperline.Figure3.2containsanexampleandillustrateshowwildcardscanbeusedin.srmles.34

PAGE 43

Figure3.3.OverviewoftheLoPSiLcompiler.TheLoPSiLcompilerinputsthepolicy.lopsilandsecurity-relevant-methods.srmintoalopsil2ajconverter,whichconvertsLoPSiLcodeintoAspectJcode.Theconverter,im-plementedin201linesofJava,beginsbyconvertingtheLoPSiLpolicytoJavasourceina.javalebysimplyinsertingthreelinesofcodetoimportLoPSiL-libraryclassesintothepolicy.TheconverterthencreatesanAspectJ-codele.ajthatdenestwothings.First,theAspectJcodedenesapointcutbasedonthedeclaredsecurity-relevantmethods.Second,theAspectJcodedenesadvicetobeexecutedwheneverthepointcutgetstriggeredi.e.,beforeandafteranysecurity-relevantmethodexecutes.ThisadvicebuildsanActionobjecttorepresenttheinvokedsecurity-relevantmethod,passesthatActiontotheLoPSiLpolicynowina.javale,obtainsthepolicy'sReactiontotheAction,andguidesexecutionappropriatelybasedonthatReaction.Finally,theLoPSiLcompilerinputstheuntrustedmobile-deviceapplicationcomprisedofasetof.classlesandthe.javaand.ajlescreatedinStep3intoastandardAspectJcompiler[62].TheAspectJcompilerinlinestheadviceintotheapplicationbeforeandafterallsecurity-relevantmethods,thusproducinganapplicationthatissecurewithrespecttotheoriginalLoPSiLpolicy.Figure3.3presentsanoverviewofthisarchitecture.BecauseLoPSiLusesAspectJasitsapplicationrewriter,LoPSiLinheritsAspectJ'slimitations.Mostimportantly,theAspectJcompilercannotrewritei.e.,inlinecodeintomethodsinstandardJavalibraries;itcanonlyrewriteapplicationles.Therefore,ourLoPSiLcompilercanonlyensurethatpolicy-enforcementcodeexecutesbeforeandaftersecurity-relevantmethodsinvokedbythe35

PAGE 44

applicationbeingmonitored.Theimportantconsequenceisthatourimplementationdoesnotallowenforcementmechanismstointerposeandmakedecisionsabouttheexecutionoflibrarymethodsinvokedbyotherlibrarymethods.WehavealsoimplementedLoPSiLontheAndroidplatform[42]1.TheAndroidimplementationisavailableonline[63]alongwithdetailsaboutourexperienceswithportingLoPSiLtotheAndroidplatform,andthevariousoverheadsinducedbyusingLoPSiLonamobilesystemthatismemory-andbattery-constrained[32]. 1WethankJoshuaFinnisfortheAndroidimplementationofLoPSiL.36

PAGE 45

CHAPTER4VALIDATIONOFAPPROACHThischapterdescribesourexperiencesworkingwithIVConandLoPSiL,alongwithevaluatingtheperformanceoverheadofthetwo.4.1IVConTovalidateourproposedapproachtothemodularizationofCCCs,weperformedcasestudiesandperformanceteststoconrm,1towhatextentIVConprovidessoftwareengineeringbenets,and2doesIVConperformitsvariousoperationsinreasonableamountsoftime.Thissectiondescribesthosecasestudiesandperformancetests.4.1.1CaseStudiesToimproveourunderstandingofIVCon'ssoftwareengineeringadvantagesanddisadvantages,weusedIVContoextendseveralapplications,includingIVConitself.4.1.1.1ExtendingIVConOurrstcasestudyinvolvedextendingIVConwiththefollowingfeatures:Searchfortextincode.Thisservesafeaturesimilartoincommoneditors.Jumptoaparticularlinenumberofcodespeciedbytheuser.Thishelpsusersdebug,ascompilerstypicallyreportwarningsanderrorsbylinenumber.Openmultiplelessimultaneously.Thisenablesuserstobuildprojectsthatspanmultipleles,withtheabilityforconcernstocrosscutmultipleles.37

PAGE 46

Showinatool-tiptheconcernsimplementedbythecodethatthemousepointerpointsto.ThisenablesuserstoseewhichconcernsacodesegmentSimplementswithoutactuallymovingthecursortoS.Integratelinkededitingintheunwoven-concernspanel.Thisensuresthattherearenocodeinconsistencieswhenllinginmulti-concernholesduringweavingasmentionedinSection2.2.2.2.Viewagsinthewovenview.Thisprovidesuserswiththesameclarityofconcernassignmentinthewovenviewthatcurrentlyexistsintheunwovenview.Becauseconcernassignmentsalsoserveascodedocumentation,thisfeaturecanimproveusers'comprehensionofwoven-viewcode.Inaddition,becauseagsstandoutwellfromtherestofthecode,thisfeaturehelpsusersquicklylocatecodeassignedtoparticularconcerns.Jumptoaspeciedconcernmoduleintheunwoven-concernspanel.Thisenablesuserstoeasilynavigateintheunwoven-concernspanel.CompileandexecutecodedirectlyfromIVCon.Thissavesusersfromhavingtoswitchtoexternaltoolsforcompilationandexecution.Afterimplementingeachofthesefeatures,werecompiledIVConandworkedinthenewerversiontoimplementthenextfeature.Thisbootstrappingapproachensuredthatwecoulddrawthebenetsofeachnewfeaturewhileimplementingsubsequentfeatures.AsshowninFigure4.1,implementingthecasestudyentailedadding1591linesofcodetoourinitialIVConprototype.Thetotaltimespentimplementingthecase-studyfeatureswas45hoursand13minutes,outofwhichwespent27minutesand31secondsdeningandassigningcodetoconcerns.Hence,1.03%ofthetotaldesignandimplementationtimeinvolvedperformingoverheadactionsnecessarytoreapIVCon'sbenetsofcreating,viewing,andeditingcodeinbothwovenandunwovenviews.Thecodeassignedtoconcernsinthecasestudyoccupied125regions,whichweassignedto43concerns.Takentogether,thesedatashowthatourcasestudywasapractical,medium-sizedimplementationeortaboutoneworkweekoftime,andonlyasmallportionaboutonepercentoftheimplementationtimehadtobespentdeningandassigningcodetoconcerns.38

PAGE 47

Table4.1.ImplementationeortforIVConcasestudy. Featureimplemented Numberof Timespent Linesof Timespent timesused deningand code implementing weaving assigningcode added hr:min and toconcerns unweaving hr:min Findtext 57 03:14 11 00:07 Gotoline 41 00:48 7 00:00 Multiplelesprojects 446 10:09 79 00:03 Tooltips 53 01:44 8 00:05 Linkedediting 364 15:39 93 00:09 Flagsinthewovenview 346 09:43 108 00:01 Jumptoaconcern 81 00:43 4 00:00 Compileandexecute 203 03:41 15 00:03 Total 1591 45:41 325 00:28 4.1.1.2ExtendingJHotDrawandJavaScienticCalculatorWealsousedIVContoextendotherprogrammers'projects:JHotDraw[8]andtheJavaScien-ticCalculator[64].JHotDrawisaframework,implementedinapproximately33,000linesofJavacode,fordevelopinggraphicseditors.TheJavaScienticCalculatorisimplementedinapproxi-mately25,000linesofcode.Weaddedthefollowingfeatures:ToJHotDrawweaddedafeatureforaskingusers,beforeexitingtheprogramwithoutsavingchangestoopenles,whethertheywishtosavethosechanges.TotheJavaScienticCalculatorweadded:{Threeextramemoryslotstothecalculator,whichinitsoriginalversionhadonlyonememoryslot.{Gradesasaunitformeasuringanglestocomplementdegreesandradians.{Abuttonthat,whenpressed,displaysthemodulusofacomplexnumber.Table4.2summarizesourimplementationeortfortheseadditionalcasestudies.Deningandassigningcodetoconcernsconsumedabout1.59%ofthetotalimplementationtime,upfromthe1.03%overheadwefoundintherstcasestudy.Weattributetheincreasedoverheadtotheextra39

PAGE 48

Table4.2.ImplementationeortforJHotDrawandJavaScienticCalculatorcasestudies. Featureimplemented Numberof Timespent Linesof Timespent timesused deningand code implementing weaving assigningcode added hr:min and toconcerns unweaving hr:min JHotDraw Asktosaveles 256 07:42 42 00:07 JavaScienticCalculator Additionalmemoryslots 542 04:41 18 00:05 Gradeangleunit 10 00:54 4 00:01 Modofcomplexnumbers 43 01:25 12 00:01 Total 851 14:42 76 00:14 eortrequiredforguringoutwhichconcernsarebeingimplementedincodewrittenbyanotherprogrammer.The1.59%overheadisstilllowandwasachievedwhiledeningandassigningcodetoseveralconcerns;wefounditusefultodene8concernsin18regionsthroughout5JHotDrawles,and10concernsin27regionsthroughout19JavaScienticCalculatorles.4.1.2ExperientialObservationsWhileaddingnewfeaturestoIVCon,IVConaidedcodeproductioninseveralways,bypro-vidingallthebenetsoutlinedinSections1.4and2.1,aswellasthebootstrappedbenetslistedinSection4.1.1.1.Assigningallcodeimplementingeachofthecase-studyfeaturestoafeature-specicconcernwasasignicantaidwhenlocatingcodeforeachconcernasitwasbe-ingimplementedandtested,particularlybecausesomeoftheconcernse.g.,MultiFilecrosscutseveralclassesandmethodse.g.,FileUtilities.newFile,FileUtilities.openIvcFile,Windows.stateChanged,etc.Itwassimilarlyhelpfultobeabletounweaveotherconcernsduringthecasestudy,aswefrequentlyneededtorefertotheirimplementations;forinstance,wealsodenedOpenFile,SaveFile,LexerFunctions,andRTreeFunctionsconcerns.Manyoftheconcernswedenedoverlappede.g.,MultiFileandOpenFile,soIVCon'sabilitytohandlemulti-concerncodewashelpful.Itwasalsousefulduringthecasestudytoassignsyntacticallyequalcodesegments,whichcrosscutvariousfunctions,tothesameconcern,sowecouldupdatethosecodesegmentscentrally.40

PAGE 49

Forexample,whileimplementingtheMultiFileconcern,wemade9centralizedupdatesto3instancesofalineofcodeusedforswitchingbetweenper-ledatastructures;these9updateswouldhaverequired27updatesinstandardcodeeditors.Asevidencethatthecrosscuttingandoverlappingconcernswedenedwerenaturalandnotenabledbypoorcodeorganization,weranIVCon'swovencodethroughEclipse'sautomaticclass-extractionrefactoringtool,whichonlysuggestedaminorrefactoringunrelatedtoourconcernassignmentsi.e.,tomovealldataeldsintoseparatedata-eld-onlyclasses.WhileautomatedrefactoringtoolsworkwithlesseortthanIVCon,theycannotingeneralpredictallthecodeaprogrammermightwantassignedtoconcerns.ToaddtheonefeaturetoJHotDraw,wedenedconcernsforseveraloperationsrelatedtothefeature,andmostoftheconcernswedenedwerescatteredinonewayortheother.Forinstance,concernssuchasOpenFileandSaveFilepertainingtoimplementationsofsavingandopeninglesrespectivelywerescatteredacrossmultipleles,whereasconcernssuchasEndAppcodethatgetsexecutedwhenaJHotDrawapplicationisterminatedandPanelOperationscodethatgetsexecutedwhenwindowswithintheapplicationareopenedorclosedwerescatteredwithinthesamele.OtherconcernsthatwedenedincludedcodethatimplementedthenewfeatureAskUsersForSaveconcernandcodethatimportedvariouspackagesImport.Codeimplementingthesetwoconcernswasnotscattered,butassigningthesecodesegmentstoaconcernprovedtobeusefulbecausewewereupdatingthesecodesegmentsfrequentlyanduponunweaving,itbecameeasiertolocatethem.SimilarlytotheJHotDrawcasestudy,mostoftheconcernsintheJavaScienticCalculatorcasestudywerescattered.However,contrarytoJHotDraw,theyweremostlyscatteredwithinthesameleitself.Again,amajorityoftheconcernsthatwedenedinthiscasestudywerefeature-specic,anddeningtheseconcernsenabledustoreadilylocatethecodethatwewerefrequentlyupdating.Forexample,toimplementtherstfeaturei.e.,additionalmemoryslots,wedenedconcernsnamedNewMemoryButtonforaddingnewbuttonstothecalculator,ButtonBackendforhandlingthebackendoperationsofbuttonse.g.,initializingbuttons,buttonlisteneretc.,andMemoryBackendforinitializingandaccessingmemorylocationsforthecalculator'smemorybuttons.TheonlyconcernthatwasscatteredacrossmultiplelesintheJavaScienticCalculator41

PAGE 50

Table4.3.Test-lecharacteristics. FileName FileSize TotalNo.of TotalNo.of Avg.Region Max.Region LoC Concerns Regions Sizechars Sizechars IVCON.java 61 5 7 135.9 337 Windows.java 2,849 20 84 914.4 24,902 StressTest.java 100,000 1,000 5,000 998.0 3,794 wasthefeature-specicconcernpertainingtotheadditionofthegradeunitforanglemeasurement,theGradeAngleconcern.IVConhelpedusinthesamewayforthiscasestudyasitdidfortherstcasestudy.Addition-ally,becauseofthelargercodebasesthatweworkingwithduringthiscasestudy,weencounteredmultiplecasesofaconcerncrosscuttingthroughseveralles.Forsuchconcerns,beingabletoopenmultiplelesaspartofaprojectprovedtobeuseful;wesavedalllesthataconcerncrosscutaspartofaproject,whichinturnensuredquickaccesstoeveryinstanceoftherelevantconcern.Moreover,weobservedthatfortheJHotDrawcasestudy,beingabletodenemulti-concerncodeprovedtobeuseful.Thefeature-specicconcernAskUsersForSavethatwewereimplementingoverlappedwithotherconcernssuchasOpenFile,SaveFile,PanelOperationsetc.,andagsintheAskUsersForSaveconcern-moduleservedasaquickaidtolocatethepositionwithintheconcern-modulewherewewantedtomakechanges.4.1.3PerformanceEvaluationToevaluatethepracticalityofourdesign,wetested1IVConbyassigningcodetoconcernsintwoofourownIVConsource-codeles:IVCON.javaandWindows.java,respectivelycontaining61and2849linesofJavacodeinthewovenviewand7and84regionsassignedto5and20totalconcerns.Wealsocreatedanimpracticallylargeleof100,000lines,eachcontaining20randomlygeneratedsingle-charactertokens,inordertostresstestIVCon'sperformance.Figure4.3summarizesourtest-lecharacteristics.WeemphasizethatStressTest.javawouldbeanunreasonablylarge1ThetestswereperformedonaDellLatitudeD830withdualIntelCore22.2GHzCPUsand2GBofRAM,runningWindowsXP.Thetimesrepresentrealtimeatlowaverageload.Weperformedeachtestinsetsof100;theresultsshownaretheaveragesofthosesets.Duringstresstesting,wehadtoincreasethevirtualmachine'sheapsizeto1.5GB.42

PAGE 51

Table4.4.Performanceopeningandsavingles. FileSize TypeofFile File-open File-save LoC Timems Timems .javale 12.96 9.09 61 .ivclenoconcerns 30.78 12.60 .ivcleconcerns 33.59 15.53 .javale 66.72 42.56 2,849 .ivclenoconcerns 367.81 216.29 .ivcleconcerns 413.22 250.14 .javale 11,582.80 474.36 100,000 .ivclenoconcerns 16,162.50 4,756.17 .ivcleconcerns 16,374.81 5,693.11 Table4.5.Performanceassigningcodetoconcerns. File Region Numberof ConcernSize Size Nested assignment LoC LoC Regions Timems 61 61 7 23.78 2,849 500 21 73.86 2,849 84 295.51 1,000 53 760.95 100,000 10,000 525 10,246.56 100,000 5,000 104,976.56 million-tokensource-codeleinpractice;weincludeditinourtestsuitetobetterunderstandIVCon'sperformancelimitations.IVConallowsuserstoopenandsaveJavasource-code.javalesandIVCon.ivcles.IVConlescontainseveralserializedobjects:theJavasource-codestringinthewovenviewwhichisstoredindependentlyofany.javales,plusIVCon'sregionMap,concernMap,andregionTreeforthatprogram.WemeasuredIVCon'sperformanceopeningandsavingourtestlesas.javales,.ivcleswithnoconcernsdened,and.ivcleswithallconcernsdened.Table4.4displaystheresults.IVConopensandsaves.javalesmorequicklythan.ivcleswhichcontainseveralpotentiallylarge,serializeddatastructures.Asexpected,IVCon'sle-openandle-savetimesareproportionaltothelengthoftheJavacodebeingprocessedandthesizesofobjectsbeingserialized.Thele-savetimesinTable4.4donotincludethetimetakentoclosetheles,butle-closingtimeswerenegligiblei.e.,unobservablysmallforallbuttheStressTestles,whichtookabout83mstoclose.43

PAGE 52

Table4.6.Performanceeditingconcerncolorsandremovingconcerns. FileSize NumberofCharacters Concern-edit Concern-removal LoC AssignedtoConcern Timems Timems 61 332 7.34 9.41 1,531 14.80 27.87 2,849 1,789 22.95 40.02 3,386 30.15 98.40 23,335 367.29 512.38 100,000 38,462 419.38 685.00 85,069 810.26 1,050.18 Table4.7.Performanceweavingandunweavingcode. Linesof Number Holesin Weaving Unweaving Woven of Unwoven Time Time Code Concerns Body ms ms 61 0 0 3.27 2.66 5 7 7.03 18.76 2,849 0 0 66.45 57.36 20 127 943.22 625.45 100,000 0 0 3,527.19 3,445.31 1,000 7,760 537,959.40 89,534.50 AlthoughcreatinganewconcerninIVContakesonlyaconstantamountoftimeandisafast0msto16msoperation,wenextdescribeIVCon'sperformanceduringthreeheavier-weightconcern-manipulationoperations.Tables4.5and4.6showIVCon'sperformanceduringconcernassignment,editing,andremoval.IVCon'sperformancewhenassigningcodetoaconcernTa-ble4.5dependsonthesizeoftheregionrbeingassignedtotheconcernandthenumberofregionsnestedwithinr;highervaluesforthesetwoparametersimplymoreconsiderationsofcode-colorchangesandthereforemoretimetocompletetheconcern-assignmentoperation.Becauseeditingconcernnamestakesanegligibleamountoftimemsto16ms,thebiggestfactorineditingaconcernisactuallychangingitscolorTable4.6,whichagaindependsontheamountoftexti.e.,thenumberandsizeofregionsassignedtotheconcernbeingrecolored.Similarly,whenausercompletelyremovesaconcerninthewovenview,mostofthetimeIVConspendscompletingthisoperationinvolvesrecoloringthecodethathadbeenassignedtothatconcern;hence,concernsassignedtomoreandlargerregionstakemoretimetoremovethanconcernsassignedtofewerandsmallerregions.44

PAGE 53

Finally,wemeasuredIVCon'sperformanceweavingandunweavingcode,aspresentedinTa-ble4.7.BasedonthedescriptionsofthesealgorithmsinSection2.2.2,wewouldexpectthatthebiggestfactorsdeterminingweavingandunweavingtimesarethenumberofconcernsbeingwovenorunwoven,thenumberofholesbeinglledinorcreated,andthenumberofcharactersllinginorbeingextractedfromholes.TheresultsinTable4.7matchtheseexpectations.Completelyweavingandunweavingcodeinallthereasonable-sizedtestlestooklessthanonesecond.Insummary,ourperformanceresultsdemonstratethattheprototypeimplementationisecientwhenoperatingonreasonablysizedsource-codeles.However,theimplementationwouldneedadditionaloptimizationstoperformtolerablyecientlyonextremelylargesource-codeles,suchasthosecontainingmillionsofsource-languagetokens.4.2LoPSiLThissectiondescribesourexperiencesworkingwithLoPSiLandsummarizestheperformanceoverheadincurredfromusingLoPSiLonamobiledevice2.4.2.1CaseStudiesTotesttheusefulnessofthelocationconstructsthatwehavedenedforLoPSiL,weimple-mentedandtestedseveralsmalllocation-basedpoliciesusingLoPSiL.Therstoftheseisanexam-pleofthesortofpolicyausermightwishtoenforceonuntrustedthird-partysoftware,whiletheotherthreeareexamplesofpoliciesthatapplicationdevelopersmightwishtoenforceontheirownsoftware.WehaveenforcedandtestedversionsofalltheseexamplepoliciesonJavaapplicationsexecutingonaroaminglaptop.Access-controlPolicy3:Ourrstexampleisaprivacy-basedaccess-controlpolicythatcon-strainsanapplication'sabilitytoreadlocationdataatparticulartimes.Thepolicy,showninFigure4.1,requiresthatmonitoredapplicationscanonlyaccessthedevice'sGPSdatafrom08:00amto18:00pmonworkdays.Ausermightwanttoenforcesuchapolicytopreventanemployer-providedapplicationfromlearningthedevice'slocationwhentheemployeeisnotatworke.g.,sotheemployerdoesnotknowwheretheemployeeshops,or 2Foradetailedanalysisofourperformancetests,wereferreaderstoourjournalarticle[32].3WethankSeanBarbeauforsuggestingthispolicy.45

PAGE 54

publicclassNoGpsOutsideWorkTimeextendsPolicy{publicsynchronizedReactionreactActiona{ifActionPatterns.matchesGpsReada&&!TimeUtils.isWorkTime//returnanulllocationtotheapplicationreturnnewReaction"replace",null;elsereturnnewReaction"ok";}}Figure4.1.LoPSiLpolicypreventinganapplicationfromreadingGPSdataoutsideofworkhours.publicclassShowNavigationextendsPolicy{publicLocationDevice[]devices={newLopsilGPSLopsilGPS.GARMIN};publicPolicyAssumptionspa=...publicsynchronizedvoidonLocationUpdate{ifdevices[0].getLocation.distancegetExpectedCurrentLocation,Units.METERS>10AppGUI.displayNavigationalAid;}}Figure4.2.AbbreviatedLoPSiLpolicyrequiringthatnavigationalaidappearwhenthedevice'scurrentlocationdeviatesfromitsexpectedpath.howmuchtimetheemployeespendsincertainplacesduringtheemployee'sohours.Infact,providingfortheenforcementofsuchapolicymightbetheonlywaytheemployercouldconvincetheemployeetorunawork-relatedapplicationontheemployee'smobiledevice.Deviation-from-pathPolicy:Oursecondexamplepolicyrequiresnavigationalaidtoappearwhenthedevice'slocationdeviatesmorethan10moitsexpectedpath.Thepolicycode,showninFigure4.2,invokesamethodcalledgetExpectedCurrentLocationtodeterminewherethepolicycurrentlyexpectsthedevicetobe.MethodgetExpectedCurrentLocationcouldreturnalocationbasedontheroutebeingdisplayedtotheuserasindashboard-mountedGPSsystems,ontracconditions,onthepaththeusernormallytravelsinthisarea,etc.46

PAGE 55

publicclassSafeRegionextendsPolicy{privateLocation[]safeRegionEndpoints;privatebooleaninRegion;publicSafeRegion{safeRegionEndpoints=getSafeRegionLocs;inRegion=devices[0].getLocation.inRegionsafeRegionEndpoints;}publicPolicyAssumptionspa=...publicsynchronizedvoidonLocationUpdate{inRegion=devices[0].getLocation.inRegionsafeRegionEndpoints;}publicsynchronizedReactionreactActiona{if!inRegion&&ActionPatterns.matchesPlainWritea{StringencMsg=encrypta.getArgs[0].toString;try{//toreplacetheunencryptedsendwithanencryptedsendBufferedWritera.getCaller.writeencMsg;}catchIOExceptione{...}returnnewReaction"replace",null;}elsereturnnewReaction"ok";}}Figure4.3.AbbreviatedLoPSiLpolicyrequiringrobot-controlsoftwaretoencryptoutgoingmes-sageswhentherobotisoutsideasecure-regionperimeter.Safe-regionPolicy4:AnotherinterestingsortofpolicyexpressibleinLoPSiLisshowninFigure4.3.Thispolicy,intendedtomonitorsoftwareonarobot,requirestherobottoencryptalloutgoingcommunicationswhentherobot'slocationisoutsideasecure-regionperimeter.Social-networkingPolicy:Ournalexampleisasocial-networkingpolicyinwhichtheuser'sfriendsgetinvitedtorendezvouswhentheusertravelstoanewarea.Specically,thepolicyrequiresthatif:{thedevicehastraveledmorethan100kmoverthepast2hoursi.e.,averagespeedhasbeenmorethan50km/hr,{thedevicehastraveledlessthan2kmoverthepast20minutesimplyingthattheuser'stravelshaveatleasttemporarilyended,and 4WethankRobinMurphyforsuggestingthispolicy.47

PAGE 56

publicclassInviteFriendsInNewAreaextendsPolicy{//maintainabufferoftwohours'worthoflocationdataprivateLocBufferlongBuf=newLocBuffer,Units.HOURS;//maintainanotherbufferoftwentyminutes'worthoflocationdataprivateLocBuffershortBuf=newLocBuffer,Units.MINUTES;privateTimetimeLastInvited=Time.NEVER;publicPolicyAssumptionspa=...publicsynchronizedvoidonLocationUpdate{LocationcurrentLoc=devices[0].getLocation;longBuf.addcurrentLoc;shortBuf.addcurrentLoc;iflongBuf.earliest.distancecurrentLoc,Units.KILOMETERS>100&&shortBuf.earliest.distancecurrentLoc,Units.KILOMETERS<2&&timeLastInvited.elapsedTime.getCurrentTime,Units.HOURS>1{Location[]friendLocs=getFriendLocations;inviteLocalFriendsfriendLocs,currentLoc,20,Units.KILOMETERS;timeLastInvited=Time.getCurrentTime;}}}Figure4.4.Alocation-dependentsocial-networkingpolicyspeciedinLoPSiL.{thepolicyenforcerhasnotsentinvitationstofriendsinthepasthour,thenthepolicyenforcermust:{broadcastaWhereareyou?"messagetoallfriendsintheuser'saddressbook,{collectresponsesfromthefriends,and{sendinvitationstomeettothosefriendsnowwithin20kmoftheuser.AnabbreviatedLoPSiLpolicyspecifyingsuchconstraintsappearsinFigure4.4.4.2.2ExperientialObservationsHavingimplementedtheexamplepoliciesdescribedinabove,webelievethatthesixcoreconstructsunderlyingLoPSiLserveasgoodabstractionsforspecifyinglocation-dependentruntimesecuritypolicies.ThisbeliefstemsfromthefactthatLoPSiLwassucientlyexpressiveforustospecifyeverylocation-dependentpolicyweconsideredenforcing.Inaddition,afterimplementing48

PAGE 57

LoPSiL,noneoftheexamplepoliciestookusmorethan2hourstodesign,specify,andtest.Althoughtheseresultsareencouraging,weneedmoreexperiencewithLoPSiL,andfeedbackfromotherusers,beforewecanmorecompletelyandobjectivelyevaluateitsexpressivenessandeaseofuse.Anotherinterestingoutcomeofdesigningtheseexamplepoliciesisthatwehaveobservedsomecommon,recurringusesoflocationinformationinsecurityandprivacypolicies.Ourlocation-dependentpoliciesconsistentlybasedpolicydecisionson:Thecurrentabsolutelocationofthedevicee.g.,whetherthedeviceisintheuser'soceThegeographicrelationshipofthedevice'scurrentlocationwithanotherlocatione.g.,whetherthedeviceisnorthoforwithin1kmofanotherlocationThegeographicrelationshipofthedevice'scurrentlocationwitharegionoflocationse.g.,whetherthedeviceisinanareaoftrustedterrainorwithin10mofanexpectedpathThevelocityoraccelerationofthedeviceBecauselocation-dependentpoliciesconsistentlyuselocationinformationintheseways,weprovideseveralutilitymethodsinLoPSiLforcalculatingdistances,boundaries,velocities,andaccelerationsbetweenlocations.AllpoliciescanaccesstheseutilitymethodsFigures4.2{4.4andcandenecustomoperatorsonlocationswhenthebuilt-inmethodsareinsucient.4.2.3PerformanceEvaluationToevaluatethepracticalityofourproof-of-conceptLoPSiLcompiler,wemeasuredtheover-headincurredfromusingfourofourLoPSiLpolicies,AllowAllFigure3.1,AccessControlFigure4.1,DeviationFromPathFigure4.2,andSocialNetworkingFigure4.45.Werecordedthefollowingmetricsfortheoriginalapplicationandfortherewrittenapplicationthatenforcesourpolicies:Timetakenfortheapplicationtonishexecution.Memoryusageoftheapplication. 5TestswereconductedonanunlockedHTCDream,thathada528MHzprocessor,192MBRAM,and1GBstorage.WethankJoshuaFinnisforperformingthevariousperformancetests.49

PAGE 58

Table4.8.OverheadincurredfromusingLoPSiL Time Memory Batteryusage Code Policy taken usage %ageof size ms Bytes totalbattery Bytes Base 36.981 2,967 16.25 13,379 AllowAll WithPolicy 37.725 3,211 16.88 68,939 Overhead 0.744 244 0.63 55,560 Base 86.203 3,976 27.00 14,386 AccessControl WithPolicy 102.458 4,168 26.88 70,394 Overhead 16.255 192 -0.12 56,008 Base 3.258 4,821 6.38 15,419 DeviationFromPath WithPolicy 26.254 5,196 10.50 71,602 Overhead 22.996 375 4.12 56,183 Base 2.450 4,679 5.38 14,142 SocialNetworking WithPolicy 82.860 5,035 9.88 71,357 Overhead 80.410 356 4.50 57,215 Batteryusageoftheapplication.Codesizeoftheapplication.TheresultsfromourexperimentsaresummarizedinTable4.8,inwhichwementionforeachpolicyandmetric,therecordedvaluefortheapplicationwithoutthepolicyenforcedmentionedasBase,therecordedvaluewiththepolicyenforcedmentionedasWithPolicy,andthedierencebetweenthetwovaluesmentionedasOverhead.Weobservethatintermsoftherunningtimeofanapplication,thebaseoverheadincurredfromusingLoPSiLwasapproximately2%.WemeasurethebaseoverheadofLoPSiLastheoverheadfromtheAllowAllpolicy,becausetheAllowAllpolicyallowsallactionsanddoesnotperformanyadditionalcomputations.Ontheotherhand,alltheotherpoliciesperformadditionalcomputationstodeterminetheresultofasecurity-relevantmethod,andthoseadditionalcomputationsincreasesignicantlytherunningtimeoftheapplicationwiththosepoliciesenforced.Additionally,onaverage,thememoryusageoverheadwasrecordedtobe6.5%,whichisseeminglyreasonable.Theaveragebatteryusageoverheadwas16.5%the95%condenceintervalisbetween-3.2%to36.4%.BatteryusageinAndroidisreportedwithagranularityof1%oftotalbatteryusage,whichexplainsthenegativeoverheadof-0.12%intheAccessControlpolicy.Anotherinterestingoverheadtoobserveistheincreasedcodesizeoftheapplication.Thisoverheadrangesapproximatelybetween50

PAGE 59

55kBand57kB,andmostoftheincreasedcodesizekB,ascanbeobservedfromtheAllowAllbasepolicyisattributedtotheLoPSiLlibraries.51

PAGE 60

CHAPTER5CONCLUSIONSWehavediscussedinthisthesis,twotoolsthatenableuserstomodularizetheircode:WehavediscussedIVCon,aGUI-basedtoolforconvenientlycreating,examining,andmodifyingcodein,andtranslatingbetween,wovenandunwovenviewsofcode.IVCondiersfromexistingaspect-visualizationtoolsbyprovidingacombinationoftranslationsbetweenwovenandunwovenviewsmany-to-manyrelationshipsbetweenconcernsandcode,token-levelgranularityinconcernassignment,andaGUIdesignedtomakeallofthisconvenient.WehavealsodiscussedLoPSiL,whichenablesuserstomodularizesecuritycodeusingtraditionalmodularizationunitsaspects.LoPSiLdiersfromexistingpolicy-specicationlanguagesbecause,asfarasweareaware,itistherstTuring-completepolicy-specicationlanguagethatprovidesuserswithlanguageconstructsforconvenientlyspecifyinglocation-basedconstraints.Thischapterconcludesthisthesisbydiscussingsomeofthelessonsthatwehavelearnedaboutcodemodularizationandprovidingseveralextensionstothiswork.5.1DiscussionEncapsulatingcodesegmentsintomethodsandreplacingthemwithcallstothosemethodspro-ducesawell-structuredprogram,andprovidedthatchosenmethodnamesaredescriptiveenough,itaidsprogramcomprehension.However,suchpracticesadverselyaectthecode-maintenanceprocess.WeobservedtheseproblemswhileworkingontheJHotDrawcasestudydescribedinSection4.1.1.2.Duringthecasestudy,althoughwecouldunderstandhowJHotDrawwasimple-mented,wehadtobrowsethroughseverallestolocatetheexactplaceinthecodewherewehadtomakechangestoimplementthedesiredfunctionalityinJHotDraw.This,weobserved,happensbecausetraditionalmodularizationtechniquessuchasExtractintoMethod,ExtractintoClassetc.ultimatelyleadtothescatteringofconcernimplementations.IVContargetsthis52

PAGE 61

scatteringproblembydisplayingconcernimplementationsinthecontextoftherestoftheprogrami.e,thecompleteprograminoneviewi.e,thewovenview,andprovidesthestandardbenetsofcodemodularizationbyisolatingconcernimplementationsfromtheprogramcoreintheotherviewi.e,theunwovenview.WhileworkingonthecasestudiesdescribedinSection4.1.1,wegainedfurtherinsightsintothebenetsofmodularizingcodeusingIVCon,includinghowIVConwouldbebestusedinapracticalsetting.ToreapmaximumbenetsfromIVCon,weproposethatprogrammersshoulduseIVConaspartofthedevelopmentprocess;programmersshouldassigncodetoconcernsastheyarewritingit.Weobservedwhilecreatingandimplementingfeature-specicconcernsfornewfeaturesthatassigningcodetoconcernswhilewritingitincursverylittleoverhead.Weexpectthisoverheadwouldbemuchlessthantheoverheadsof1.03%and1.59%thatwereportedinourcasestudiesSections4.1.1.1and4.1.1.2,respectively.Also,wecouldfurtherreducethisoverheadbyimplementinganinterfacethatismoreconducivetoconcernassignmentthanIVCon'scurrentinterface,whichisprimarilytargetedtowardsprovidingwovenandunwovenviewsofusercodeandconveyingthebenetofIVCon'sconcernmodules.WhileIVConprovidesmultiplesoftware-engineeringbenetsbymodularizingconcerncode,itprovidesnoconstructsforencapsulatingorinterfacingwiththatmodularizedcode.Thatis,programmersmaymodifyunwovenconcerncodearbitrarily,aslongastheresultingwovenprogramislexically,syntactically,andsemanticallyvalid.Thewovenandunwovenviewsareequivalent,butonlythewovenviewischeckedforvalidity|duringcompilationIVConchecksthatthewovenprogramisvalidJava,andafterweavingandbeforeunweavingIVConchecksthatalldeclaredregionsbeginattokenbeginningsandendattokenendings.Forexample,itispossibleintheunwovenviewtodeclareanewvariableforoneconcernthatanotherconcernwillthenimplicitlyhaveaccessto.Aslongasthewovenprogramisvalid,suchmodicationsareallowed,andIVCon'sinterfacecurrentlyprovidesnoindicationofwhichvariablesareinscopeatwhichpartsofunwovencodethoughonecouldimagineextendingIVConwithsuchafeature.Fornow,IVConuserscanonlyseewhichvariablesareinscopeintheunwovenviewbyswitchingto,andexaminingcodein,thewovenview.Ingeneral,weexpectthattherewillalwaysbesometasksthatareeasiertoperforminthewovenviewe.g.,understandingwhichvariablesareinscopeatgivenpositions,whileothersareeasiertoperformintheunwovenviewe.g.,changing53

PAGE 62

themessagesoutputinanauditconcern;afterall,thesedierencesarewhatmotivatedIVConanditsabilitytoworkinandtranslatebetweenthewovenandunwovenviews.Inthepresenceoffunctionallyorthogonalcodesegments,IVCon'sconcernmodulesprovidethesamebenetstousersastraditionalmodularizationtechniques.Forexample,ifweuseIVContoisolatecodeimplementingsecurityinaprogram,wecanviewallsecuritycodeinoneplaceintheunwoven-concernspanelintheunwovenview,whichoersprogramcomprehensionbenetssimilartothoseoeredbypolicy-specicationlanguages.Also,wehavederivedfromourexperiencesworkingwithLoPSiLthattraditionalmodulariza-tiontechniquesprovetobeagoodsolutionformodularizingCCCsthatarefunctionallyorthogonaltothefunctionalityoftherestoftheprogram.ThisiswhyweusedAspectJ,atraditionalmodu-larizationtechnique,toimplementLoPSiL.Ourbeliefisfurtherconrmedbythefactthataspect-orientedlanguagesaretypicallyusedtoimplementtheloggingfunctionalitywhichistypicallyafunctionally-orthogonalconcerninmanyapplications.5.2FutureWorkSeveralopportunitiesexistforimprovinguponworkthatwehavediscussedinthisthesis.Someofthedirectionsthatthisworkcouldtakeoninthefutureareenumeratedasfollows:WewouldliketocollectdatafromotheruserstomeasureIVCon'seectivenessatimprovingthesoftwaredevelopmentprocess.Moreover,wewouldliketofurtherevaluateIVCon'sempiricalperformancetodeterminewhetherandhowtheweavingandunweavingoperationscouldbeoptimized,especiallyforlargersource-codeles.ItwouldalsobeusefulforIVContoletusersselectasubsetofconcernstoexporttoanexternalle.ThiswouldprovideabenetsimilartoHyper/J'son-demandremodularization,withwhichuserscanspecifyasetoffeaturestoincludeintheirprogram[25].WeexpectthatimplementingthiscapabilitywouldrequireonlyminorchangestoIVCon'sunweavingalgorithm.Amorechallengingproblem,however,wouldbetodisplayinonelocation,concerncodefromCCCsthatspanmultiplelesinaproject.ThiswouldenableuserstoindependentlyreasonaboutandeditCCCsfromvariouslesinonelocation.54

PAGE 63

Figure5.1.IVCon'snewerinterfaceforreducedconcernassignmenttimes.AlthoughourprototypeversionofIVConisaimedtowardsusersprogramminginaJavaenvironment,webelievethattheprinciplesunderlyingIVConapplytosoftwareinanylan-guage.Tovalidateourbelief,wewouldliketoaddsupportforotherlanguagestoIVCon.Again,weexpectthatimplementingthiscapabilitywouldentailmakingminorchangestotheinterfacetoallowforuserstoselecttheenvironmenttheywishtoworkin,andaddingJavaCCgrammarsofotherlanguagestoIVCon'slexertolexicallyvalidateusercodeandenforcetoken-levelgranularity.Wecouldreducetheoverheadincurredfromtheconcern-assignmentprocessbymakingminorchangestoIVCon'sinterface.OneofthefeaturesthatwouldreducethisoverheadwouldbetoenableuserstoimportconcernsconcernnamesandcolorsfromotherIVConles;doingsowouldreducethetimetakentodeneconcernsbyeliminatingtheneedtospecifyanameandacolorforconcerns.Additionally,itwouldensureconsistencyinthechoiceofconcerncolorsacrossdierentles.Anotherfeaturethatwouldreducetheconcern-assignmentoverheadwouldbetheuseoftogglebuttonsforconcernassignments.Insuchaninterface,userswould55

PAGE 64

toggleaconcernbuttononeforeveryconcerntoON"toeitherassignselectedcodetotheconcern,de-assigntheconcernfromtheselectedcode,orassigntotheconcern,textthattheuserwilltype.Moreover,userswouldnotbepromptedtospecifynamesforregions;instead,thenewinterfacewouldconsistofanactivitypanelthatwouldinformusersthataregionwiththenameconcernname region i"hasbeendened,andwouldprovidealinktoallowuserstochangethenameoftheregion.Figure5.1illustratesthisproposedinterface.WewouldliketomodelourIVConlanguageinaformalcalculusandprovethatourtranslationalgorithmsareinversesofeachother,2ourtranslationsaresemanticspreservingi.e.,translationsoundness,andwecanunweaveanyconcerninanywovenprogramandweaveanyconcernintoanyunwovenprogrami.e.,translationcompleteness.Concerninformationobtainedbyusersexplicitlyassigningcodetoconcernscantellushowconcernsarerelatedtoeachother.Morespecically,itcanhelptelluswhetheraconcernisfunctionallyorthogonaltoanotherconcernornot.Usingthisinformationwecansuggesttouserswhetherornotitmakessensetorefactorcodesegmentsintodierentclassesornot.InsteadofusingaGUI-basedtooltodeneconcernassignmentsincode,wecouldalternativelyimplementalanguagethatallowsuserstocode"theconcernassignments.ThiscouldbemadepossiblebyusingJavaannotationsinordertomarkthebeginningandendofregions.Havingsuchalanguagewouldpossiblyreducetheoverheadofconcernassignmentthatwehavedescribedinourcasestudiesbyeliminatingthetimethatausertakestoselectcodebeforeassigningittoaconcern.WecouldextendLoPSiLtoallowuserstospecifyandenforcemultiplepoliciesontheirprograms.Aspreviousworkhasshown,thiswouldincreaseauser'seortwhilespecifyingpoliciesbecauseuserswillhavetoensurethattheirpoliciesareeectless[5,4].Moreover,wewouldhavetoprovidemechanismswithinLoPSiLthatcancombinedecisionsfromvariouspolicies.56

PAGE 65

AsmentionedinSection3.2.1,asaresultofusingAspectJasourapplication-rewriter,ourim-plementationdoesnotmakedecisionsabouttheexecutionoflibrarymethodsinvokedbyotherlibrarymethods.AsaresultLoPSiLdoesnotprovidecompletemediationofsecurity-relevantmethods.WecouldcircumventthislimitationbywritingourownLoPSiLenforcement-codeinlinere.g.,usingtoolsliketheBytecodeEngineeringLibrary[65],aspreviousworkhasdone[2,4,5],butatthepriceofsignicantlyincreasedimplementationcomplexity.Finally,wewouldliketomodelLoPSiLinaformallanguagesothatwehaveacompleteandimplementation-independentspecicationofourlanguage.57

PAGE 66

LISTOFREFERENCES[1]PeriTarr,HaroldOssher,StanleyM.Sutton,Jr.,andWilliamHarrison.Ndegreesofsepara-tion:Multi-dimensionalseparationofconcerns.InProceedingsoftheInternationalConferenceonSoftwareEngineering,1999.[2]UlfarErlingssonandFredB.Schneider.IRMenforcementofJavastackinspection.InIEEESymposiumonSecurityandPrivacy,Oakland,CA,May2000.[3]DavidEvansandAndrewTwyman.Flexiblepolicy-directedcodesafety.InIEEESecurityandPrivacy,Oakland,CA,May1999.[4]LujoBauer,JayLigatti,andDavidWalker.Composingsecuritypolicieswithpolymer.InProceedingsoftheACMSIGPLAN2005ConferenceonProgrammingLanguageDesignandImplementation,Chicago,June2005.[5]LujoBauer,JayLigatti,andDavidWalker.Composingexpressiveruntimesecuritypolicies.ACMTransactionsonSoftwareEngineeringandMethodology,18:1{43,2009.[6]MartinFowler.Refactoring:ImprovingtheDesignofExistingCode.Addison-Wesley,Boston,MA,USA,1999.[7]MartinFowler.RefactoringHome.http://www.refactoring.com/.[8]ErichGammaandThomasEggenschwiler.JHotDrawStartPage,1998.http://www.jhotdraw.org/.[9]GregorKiczales,JohnLamping,AnuragMenhdhekar,ChrisMaeda,CristinaLopes,Jean-MarcLoingtier,andJohnIrwin.Aspect-orientedprogramming.InProceedingsoftheEuropeanConferenceonObject-OrientedProgramming,1997.[10]GregorKiczales,ErikHilsdale,JimHugunin,MikKersten,JereyPalm,andWilliamG.Griswold.AnoverviewofAspectJ.InProceedingsoftheEuropeanConferenceonObject-OrientedProgrammingECOOP,pages327{353,2001.[11]MonicaYvonneCoady.ImprovingevolvabilityofoperatingsystemswithAspectC.PhDthesis,TheUniversityofBritishColumbia,2003.[12]T.Panas,J.Karlsson,andM.Hogberg.Aspect-jEditforinlineaspectsupport.InProceedingsoftheThirdGermanWorkshoponAspectOrientedSoftwareDevelopment,2003.[13]S.Pestovetal.jEdit-Programmer'sTextEditor-overview.http://www.jedit.org/.[14]W.G.Griswold,J.J.Yuan,andY.Kato.Exploitingthemapmetaphorinatoolforsoftwareevolution.InInternationalConferenceonSoftwareEngineering,pages265{274,May2001.58

PAGE 67

[15]W.G.Griswold,Y.Kato,andJ.J.Yuan.AspectBrowser:Toolsupportformanagingdispersedaspects.TechnicalReportCS1999-0640,UniversityofCaliforniaatSanDiego,LaJolla,CA,USA,1999.[16]MacneilShonle,JonathanNeddenriep,andWilliamGriswold.AspectBrowserforeclipse:Acasestudyinplug-inretargeting.InProceedingsofthe2004OOPSLAworkshoponeclipsetechnologyeXchange,pages78{82,2004.[17]SCEick,J.L.Steen,andE.E.SumnerJr.Seesoft-atoolforvisualizinglineorientedsoftwarestatistics.IEEETransactionsonSoftwareEngineering,pages957{968,1992.[18]WilliamG.Griswold.Copingwithcrosscuttingsoftwarechangesusinginformationtrans-parency.InInProceedingsoftheThirdInternationalConferenceonMetalevelArchitecturesandSeparationofCrosscuttingConcerns,pages250{265.Springer-Verlag,2001.[19]TheVisualiser.http://www.eclipse.org/ajdt/visualiser/.[20]EclipseFoundation.Eclipse,2006.http://www.eclipse.org/.[21]M.R.RobillardandG.C.Murphy.Concerngraphs:ndinganddescribingconcernsusingstructuralprogramdependencies.InProceedingsoftheInternationalConferenceonSoftwareEngineering,2002.[22]MariusMarin,LeonMoonen,andArievanDeursen.SoQueT:Query-baseddocumentationofcrosscuttingconcerns.InProceedingsoftheInternationalConferenceonSoftwareEngineering,2007.[23]DonaldE.Knuth.Literateprogramming.TheComputerJournal,27:97{111,1984.[24]MarcoYuen,MarcE.Fiuczynski,RobertGrimm,YvonneCoady,andDavidWalker.MakingextensibilityofsystemsoftwarepracticalwiththeC4toolkit.InProceedingsoftheWorkshoponSoftwareEngineeringPropertiesofLanguagesandAspectTechnologies,March2006.[25]HaroldOssherandPeriTarr.Hyper/J:Multi-dimensionalseparationofconcernsforJava.InProceedingsoftheInternationalConferenceonSoftwareEngineering,pages734{737,2000.[26]ChristianKastner.CIDE:Decomposinglegacyapplicationsintofeatures.InProceedingsofthe11thInternationalSoftwareProductLineConferenceSPLC,secondvolumeDemonstration,pages149{150,2007.[27]ChristianKastner,SvenApel,andMartinKuhlemann.Granularityinsoftwareproductlines.InProceedingsoftheInternationalConferenceonSoftwareEngineering,May2008.[28]RobertR.PainterandDavidCoppit.Amodelforsoftwareplans.InProceedingsoftheWorkshoponModelingandAnalysisofConcernsinSoftware,2005.[29]RobertE.FilmanandDanielP.Friedman.Aspect-orientedprogrammingisquanticationandobliviousness.TechnicalReport01.12,RIACS,2000.[30]JayLigatti,DavidWalker,andSteveZdancewic.Atype-theoreticinterpretationofpointcutsandadvice.ScienceofComputerProgramming:SpecialIssueonFoundationsofAspect-OrientedProgramming,63:240{266,December2006.59

PAGE 68

[31]JayLigatti,BillyRickey,andNalinSaigal.LoPSiL:Alocation-basedpolicy-specicationlanguage.InInternationalICSTConferenceonSecurityandPrivacyinMobileInformationandCommunicationSystemsMobiSec,June2009.[32]JoshuaFinnis,NalinSaigal,AdrianaIamnitchi,andJayLigatti.Alocation-basedpolicy-specicationlanguageformobiledevices.PervasiveandMobileComputingJournal.Inpress.[33]NicodemosDamianou,NarankerDulay,EmilLupu,andMorrisSloman.ThePonderpolicyspecicationlanguage.LectureNotesinComputerScience,1995:18{39,2001.[34]OASIS.eXtensibleAccessControlMarkupLanguageXACMLversion2.0,2005.http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf.[35]GuyEdjlali,AnuragAcharya,andVipinChaudhary.History-basedaccesscontrolformobilecode.InACMConferenceonComputerandCommunicationsSecurity,1998.[36]DavidScott,AlastairBeresford,andAlanMycroft.Spatialsecuritypoliciesformobileagentsinasentientcomputingenvironment.In6thFundamentalApproachestoSoftwareEngineeringFASE,volumeLNCS2621,pages102{117.Springer-Verlag,2003.[37]M.Anisetti,C.A.Ardagna,V.Bellandi,andE.Damiani.OpenAmbient:Apervasiveaccesscontrolarchitecture.InA.U.Schmidt,M.Kreutzer,andR.Accorsi,editors,Long-TermandDynamicalAspectsofInformationSecurity:EmergingTrendsinInformationandCommuni-cationSecurity.NovaSciencePublisher,Inc.,2007.[38]ClaudioA.Ardagna,MarcoCremonini,ErnestoDamiani,SabrinaDeCapitanidiVimercati,andPierangelaSamarati.Supportinglocation-basedconditionsinaccesscontrolpolicies.InSymposiumonInformation,ComputerandCommunicationsSecurity,2006.[39]ElisaBertino,BarbaraCatania,MariaLuisaDamiani,andPaoloPerlasca.GEO-RBAC:AspatiallyawareRBAC.InSACMAT'05:ProceedingsofthetenthACMsymposiumonAccesscontrolmodelsandtechnologies,pages29{37,NewYork,NY,USA,2005.ACM.[40]JayLigatti,LujoBauer,andDavidWalker.Editautomata:Enforcementmechanismsforrun-timesecuritypolicies.InternationalJournalofInformationSecurity,4{2:2{16,February2005.[41]IndrakshiRayandMahendraKumar.Towardsalocation-basedmandatoryaccesscontrolmodel.ComputersandSecurity,25:36{44,2006.[42]Google.AndroidDevelopers.http://developer.android.com/.[43]WilliamEnck,MachigarOngtang,andPatrickMcDaniel.Understandingandroidsecurity.IEEESecurityandPrivacy,7:50{57,2009.[44]NalinSaigalandJayLigatti.Deningandvisualizingmany-to-manyrelationshipsbetweenconcernsandcode.TechnicalReportCSE-090608-SE,UniversityofSouthFlorida,September2008.[45]NalinSaigal.IVCon:AGUI-basedtoolforvisualizingandmodularizingcrosscuttingconcerns.Master'sthesis,UniversityofSouthFlorida,August2009.[46]NalinSaigalandJayLigatti.Inlinevisualizationofconcerns.InProceedingsoftheInterna-tionalConferenceonSoftwareEngineeringResearch,Management,andApplications,2009.60

PAGE 69

[47]NalinSaigalandJayLigatti.IVCon:Inlinevisualizationofconcerns.TechnicalReportCSE-110909-SE,UniversityofSouthFlorida,November2009.[48]NalinSaigalandJayLigatti.Modularizingcrosscutting,overlappingconcernswithIVCon.JournalofComputerScienceandTechnology.Insubmission.[49]NalinSaigalandJayLigatti.IVCon|InlineVisualizationofConcerns,2008.http://www.cse.usf.edu/~ligatti/projects/ivcon/.[50]AntoninGuttman.R-trees:Adynamicindexstructureforspatialsearching.InProceedingsoftheACMSIGMODInternationalConferenceonManagementofData,pages47{57,1984.[51]L.Arge,M.D.Berg,H.Haverkort,andK.Yi.ThepriorityR-tree:Apracticallyecientandworst-caseoptimalR-tree.ACMTransactionsonAlgorithmsTALG,4:1{30,2008.[52]M.Toomim,A.Begel,andS.L.Graham.Managingduplicatedcodewithlinkedediting.InProceedingsoftheIEEESymposiumonVisualLanguagesandHumanCentricComputing,2004.[53]E.HansonandM.Chaabouni.TheIBStree:adatastructureforndingallintervalsthatoverlapapoint.TechnicalReportWSU-CS-90-11,WrightStateUniversity,1990.[54]W.Pugh.Skiplists:aprobabilisticalternativetobalancedtrees.CommunicationsoftheACM,33:668{676,1990.[55]MariosHadjieleftheriou.SpatialIndexLibrary.http://www.research.att.com/~marioh/spatialindex/.[56]javacc:JavaCCHome.https://javacc.dev.java.net/.[57]HirondelleSystems.JavaPractices->Clipboardcopyandpaste,2008.http://www.javapractices.com/topic/TopicAction.do?Id=82.[58]SunMicrosystems.TheJavaMEPlatform-theMostUbiquitousApplicationPlatformforMobileDevices.http://java.sun.com/javame/index.jsp.[59]A.U.Schmidt,N.Kuntze,andJ.Abendroth.Trustforlocation-basedauthorisation.InWirelessCommunicationsandNetworkingConference,pages3163{3168,2008.[60]GPSLib4Jv0.1.http://gpslib4j.sourceforge.net/.[61]BillyRickey,NalinSaigal,andJayLigatti.LoPSiLImplementation,2009.http://www.cse.usf.edu/~ligatti/projects/runtime/LoPSiL.zip.[62]AdrianCoyler,AndyClement,WesIsberg,MikKersten,AlexVasseur,andMatthewWebster.TheAspectJProject,2003.http://www.eclipse.org/aspectj/.[63]JoshuaFinnis,BillyRickey,NalinSaigal,AdrianaIamnitchi,andJayLigatti.LoPSiLImple-mentation,2009.http://www.cse.usf.edu/~ligatti/projects/runtime/LopsilAndroid.zip.[64]JohnD.Lamb.Javascienticcalculator.http://www.btinternet.com/~uyea/calculator.html.61

PAGE 70

[65]ApacheSoftwareFoundation.ByteCodeEngineeringLibrary,2003.http://jakarta.apache.org/bcel/.62


xml version 1.0 encoding UTF-8 standalone no
record xmlns http:www.loc.govMARC21slim xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmarcxmlschemaMARC21slim.xsd
leader nam 22 Ka 4500
controlfield tag 007 cr-bnu---uuuuu
008 s2011 flu ob 000 0 eng d
datafield ind1 8 ind2 024
subfield code a E14-SFE0004971
035
(OCoLC)
040
FHM
c FHM
049
FHMM
090
XX9999 (Online)
1 100
Saigal, Nalin
0 245
Modularizing crosscutting concerns in software
h [electronic resource] /
by Nalin Saigal.
260
[Tampa, Fla] :
b University of South Florida,
2011.
500
Title from PDF of title page.
Document formatted into pages; contains 70 pages.
Includes vita.
502
Disseration
(Ph.D.)--University of South Florida, 2011.
504
Includes bibliographical references.
516
Text (Electronic dissertation) in PDF format.
520
ABSTRACT: Code modularization provides benefits throughout the software life cycle; however, the presence of crosscutting concerns (CCCs) in software hinders its complete modularization. Traditional modularization techniques work well under the assumption that code being modularized is functionally orthogonal to the rest of the code; as a result, software engineers try to separate code segments that are orthogonal in their functionality into distinct modules. However, in practice, software does not decompose neatly into modules with distinct, orthogonal functionality. In this thesis, we investigate the modularization of CCCs in software using two different techniques. Firstly, we discuss IVCon, a GUI-based tool that provides a novel approach to the modularization of CCCs. We have designed IVCon to capture the multi-concern nature of code. IVCon enables users to create, examine, and modify their code in two different views, the woven view and the unwoven view. The woven view displays program code in colors that indicate which CCCs various code segments implement, while the unwoven view displays code in two panels, one showing the core of the program and the other showing all the code implementing each concern in an isolated module. IVCon aims to provide an easy-to-use interface for conveniently creating, examining, and modifying code in, and translating between, the woven and unwoven views. Secondly, we discuss LoPSiL, which is a location-based policy-specification language. LoPSiL is Turing-complete and provides users with language constructs that enable them to manipulate location information; hence, LoPSiL can be used to specify and enforce generic policies that might involve location-based constraints. We have implemented a LoPSiL compiler using AspectJ, and we observe and discuss how the use of traditional units of modularization---aspects in this case---help modularize functionally orthogonal CCCs such as security and auditing.
538
Mode of access: World Wide Web.
System requirements: World Wide Web browser and PDF reader.
590
Advisor:
Ligatti, Jay .
653
Aspect-oriented Programming
Code Maintenance
Policy-specification Languages
Security
Software Engineering
690
Dissertations, Academic
z USF
x Computer Science
Doctoral.
773
t USF Electronic Theses and Dissertations.
4 856
u http://digital.lib.usf.edu/?e14.4971