Abstract International Workshop on Aliasing, Confinement and Ownership in object-oriented p

Uponaddingtheannotations,adevelopercanrealizethatthesetterisoverwritingtheexistingfieldsincetheparameterfigscannotbemarkedasownedandanyotherannotationwouldfailtheassignmentcheckwhenoverwritingthefFiguresfield.

Whenmanuallyaddingannotations,itispossibletomissmanyopportunitiesformakingobjectsowned.Indeed,weinitiallyanno-tatedfFigureswiththedomainparameterMinsteadofowned.Insomecases,objectsshouldbeownedbutarenot,andmakingthemownedmayrequirecodechanges,e.g.,toreturnacopyofanobjectinsteadofanaliastoaprivatefield.

2007/7/3

Visualizingtheannotationsencouragedustomakemoreuseoftheownedannotationsinceownedavoidsclutteringthetop-leveldomains[1].Perhapsbettertoolsupportcanpromptadevelopertoencapsulateafieldthatcouldbeannotatedwithownedbutisnot,e.g.,alightweightcompile-timeownershipinferencealgorithm[33]couldsuggestpossibleEclipse“quickfixes”.5.2

Ownershipdomainsspecifyarchitecturaltiers

AtieredarchitectureisoftenusedtoorganizeanapplicationintoaUserInterfacetier,aBusinessLogictier,andaDatatier.Ownershipdomainscanexpressandenforcesuchatieredruntimearchitecturebyrepresentingatierasanownershipdomain[3],andapermissionbetweentiersasadomainlinktoallowobjectsintheUserInterfacetiertorefertoobjectsintheBusinessLogictierbutnotviceversa.SuchanarchitecturalstructureandconstraintscannotbeeasilyexpressedinplainJavacode.

WeorganizedthecoreJHotDrawtypesinFigure6accordingtotheModel-View-Controllerdesignpatternasfollows:

•Model:consistsofDrawing,Figure,Connector,etc.ADrawingiscomposedofFigureswhichknowtheircontainingDrawing.AFigurehasalistofHandlestoallowuserinterac-tions.ADrawingalsoextendsFigureChangeListener(notshown)tolistentochangestoitsFigures.

•View:consistsofDrawingEditor,DrawingViewandassoci-atedtypes.DrawingViewextendsDrawingChangeListener(notshown)tolistentochangestoDrawingobjects.

•Controller:includesinterfacessuchasHandle,ToolandCommand.AToolisusedbyaDrawingViewtomanipulateaDrawing.ACommandencapsulatesanactiontobeexecuted—asimpleinstanceoftheCommanddesignpattern[22,p.233]withoutundosupport.

Oncewedefinedthethreetop-levelownershipdomains,Model,ViewandController,wepassedthecorrespondingdomainpa-rametersM,VandCtovarioustypesasdiscussedbelow.Avisual-izationoftheJHotDrawexecutionstructurebasedontheseowner-shipdomainannotationsisavailable[1].

InHillClimber,theapplicationwindowusesacanvastodis-playnodesandedgesofagraphinordertodemonstratealgo-rithmsforconstraintsatisfactionproblemsprovidedbytheengine.SoweorganizedtheHillClimbertypesinFigure12asfollows.Thedataownershipdomainstoresthegraphobjects(instancesofGraph,Node,etc.,andthoseoftheirsubclasses,HillGraph,HillNode,etc.).Theuidomainholdsuserinterfaceobjects.ThelogicdomainholdsinstancesofHillEngine,Search(andsub-classesthereof)objects,andassociatedobjects.AvisualizationoftheHillClimberexecutionstructurebasedontheseownershipdo-mainannotationsisavailable[1].5.3

Ownershipdomainsexposeimplicitcommunication

Designpatterns—suchasObserver[22,p.293],usedtodecoupleobject-orientedcodealsotendtomakethecommunicationbetweenobjectsimplicit.Addingownershipdomainannotationshelpsmakethatcommunicationmoreexplicit.

WeinitiallywantedtoparameterizeDrawing(SeeFigure7)withonlytheMdomainparameter,butDrawingChangeListenerisimplementedbyDrawingView.SoDrawingChangeListenerneededtobeannotatedwiththeVdomainparametercorrespond-ingtotheView.Bymakingimplicitcommunicationexplicit,anno-tationsseemtoprematurelyconstrainDrawingChangeListenerobjectstobeintheViewdomain.SinceDrawingwasacoreinter-facereferencedbyotherinterfacesinthecoreframeworkpackage,thisledtopassingallthreedomainparameterstomanyadditionalinterfacesandclasses.

ItistruethatifDrawinghadtobeparameterizedbydomainparameterVforsomeotherreason,theimplicitcommunicationin

6

/∗∗

∗DrawingisacontainerforFigures.Drawingsends∗outDrawingChangedeventstoDrawingChangeListeners∗wheneverapartofitsareawasinvalidated.

∗TheObserverpatternisusedtodecoupletheDrawing∗fromitsviewsandtoenablemultipleviews.∗/

@DomainParams({\"M\",\"V\"})

@DomainInherits({\"FigureChangeListener\",...})

interfaceDrawingextendsFigureChangeListener...{//Addsalistenerforthisdrawing.voidaddDrawingChangeListener(

@Domain(\"V\")DrawingChangeListenerl);//Addsafigureandsetsitscontainer//torefertothisdrawing.@Domain(\"M\")

Figureadd(@Domain(\"M\")Figurefigure);...}

Figure7.AddingannotationstoDrawing.

@DomainParams({\"M\",\"V\",\"C\"})interfaceHandle{

voidinvokeStart(@Domain(\"V\")DrawingViewv);...

@Domain(\"M\")UndoablegetUndoActivity();}

Figure8.HandlewithM,VandCdomainparameters.theobserverwouldnothavebeendiscoveredthisway.Ownershipdomainannotationshelpmakeimplicitcommunicationexplicitwhenareferencerequirespermissiontoaccessanewpartoftheprogramforthefirsttime.

InHillClimber,addingownershipdomainannotationsexposedcovertobjectcommunicationthroughbaseclassesfromtwopar-allelinheritancehierarchies.Duringanearlyiteration,weparam-eterizedthebaseclassGraphCanvasbytheuianddatado-mainparameters.WethenrealizedthatGraph,thebaseclassforHillGraph,requiredtheuidomainparameter(SeeFigure12).ClassGraphonlyneededtheuidomainparametertoproperlyan-notateaGraphCanvasfieldreferencethatwedidnotexpect.ThisinturnrevealedthatHillGraphandHillCanvaswerecommu-nicatingthroughtheirbaseclassesGraphandGraphCanvas.Intheend,thereferencetoGraphCanvaswasmovedfromGraphtoHillGraphandgeneralizedasanIHillCanvasreferencebyex-tractinganinterfaceIHillGraphfromHillGraph.5.4Ownershipdomainsexposetightcoupling

Letustemporarilyignoretheearlierlimitationwithaddinganno-tationstothelistenersandassumethatDrawingcouldbeparam-eterizedbyonlytheMdomainparameter.LetusconsiderwhetheritwouldbepossibletoparameterizeinterfaceHandle(SeeFigure8)withdomainsMandC.AHandlewouldbeintheCdomainandwouldaccessobjectsinthatdomainandinMdomain,i.e.,itshouldnotaccessobjectsintheVdomainparameter.NotethateveniftheexplicitparameterCwasnotprovided,thatdomainwouldstillbeaccessibletoHandleusingtheownerannotation.

AcommentinthecodeindicatedthatVersion4.1deprecatedtheoriginalinvokeStartmethodwhichtookaDrawingobjectasoneofitsparameters,infavorofaninvokeStartmethodthattakesinsteadaformalparameterDrawingViewparameterizedbyM,V,andC.ThisrequiredpassingtoHandletheadditionaldomainparameterV.SinceHandleisacoreinterfacereferencedbyotherinterfacesinthecoreframeworkpackage,thisalsoledtopassingallthreedomainparameterstomanyadditionaltypes.

2007/7/3

Figure6.SimplifiedclassdiagramforJHotDraw(AdaptedfrommanualclassdiagrambyRiehle[43,12]).

@DomainParams({\"M\",\"C\"})interfaceHandle{@DomainParams({\"V\"})

voidinvokeStart(@Domain(\"V\")DrawingViewv);...

@Domain(\"M\")UndoablegetUndoActivity();}

Figure9.HandlewithonlyMandCdomainparameters.

@DomainParams({\"M\",\"C\"})

@DomainInherits({\"Handle\"})

abstractclassAbstractHandleimplementsHandle{//Willnottypechecksince’V’unbound@Domain(\"V\")DrawingViewview;...

@DomainParams({\"V\"})

voidinvokeStart(@Domain(\"V\")DrawingViewv){//Cannotstoreargumentinfield’this.view’}}

Figure10.Methoddomainparameterscanenforcelifetime.5.5

Ownershipdomainsexposeandenforceobjectlifetime

Letusassumeinthissectionthattherefactoringwhichintroducedthetightercouplingwasneverperformed,i.e.,HandlestillneededaDrawinginsteadofaDrawingView.UndosupportwasaddedtoJHotDrawforthefirsttimeinVersion5.3.Inparticular,HandlenowhadareferencetoUndoable—whichinturnrequireddomainparametersM,VandCbecauseUndoable’sgetDrawingView()methodreturnedaDrawingView.

Now,letusseeifitwouldbepossibletoannotateUndoableandHandlewithonlythedomainparametersMandC(SeeFigure9)—thedomainparameterVcanthenbesuppliedtoinvokeStart()asamethoddomainparameter.

Usingamethoddomainparametertoannotatetheformalpa-rametervcouldenforcetheconstraintthatadevelopershouldnotstoreinafieldtheDrawingViewobjectpassedasanargumenttoinvokeStart(),asinFigure10.Ofcourse,adevelopercouldstoretheDrawingViewobjectinafieldoftypeObject,butthatfieldwouldhavetobecasttoaDrawingViewtobeofanyuse.

7

Insteadofamethoddomainparameter,thelentannotationcouldalsobeusedtoallowatemporaryaliastoanobjectwithinamethodboundary.WefoundafewsuchexamplesinJHotDraw.MethodsetAffectedFiguresinFigure11makesacopyofthelentargumentsoitcannotjustholdontoit.

Infact,lentcanbeformallymodeledasamethoddomainpa-rameter.However,thetypesystemdoesnotallowamethodtore-turnalentvaluebutitallowsamethodtoreturnanobjectinamethoddomainparameter.InthecaseofDrawingView,lentcan-notbeusedbecauseimplementationsofinvokeStart()constructUndoableobjectsthatmaintainaliasestotheDrawingViewandthusrequiretheVdomainparameter.

Forthatsamereason,theUndoableinterfacerequirestheVdo-mainparameterbecauseUndoablestorestheDrawingViewwheretheactivitytobeundonewasperformedinordertoundothechangestothatviewonly.ThismayslightlyviolatetheModel-View-Controllerdesign,wheremodelobjectsshouldnotholdontoviewobjects,becausetheremightbemultipleviewsthatneedtobeupdatedinresponsetochangesinthemodel.Atthesametime,itwouldbecounter-intuitiveforausertoundoachangeinoneviewandobservechangesinsomeotherview.Thus,ownershipdomainannotationsexposethetightercouplingthattheUndofeaturein-troduced.Figure11showsinmoredetailtheinteractionbetweenHandle,UndoableandDrawingView.

AnearlierempiricalstudyofJHotDrawmentionedthat“acom-monarchitecturalmistake[...]wastoprovideFigureswitharef-erencetotheDrawingortheDrawingView.FiguresdonotbydefaulthaveanyaccesstoeithertheDrawingortheDrawingViewinwhichtheyarecontained.Thispreventsthemfromaccessingin-formationsuchasthesizeoftheDrawing.However,itispossibletoovercomethisproblembypassingtheviewintotheconstructorofafigure,whichcanthenstoreandaccessthisasrequired”[28].StartingwithVersion5.3,onecouldgettotheFigure’sHandlesthroughitshandles()methodthengetaDrawingViewthroughaHandle’sUndoActivityobjects.

5.6Ownershipdomainspromotedecouplingcode

Ownershipdomainannotationshighlighttightcouplingandpro-moteprogrammingpracticesthatdecouplecode.

ProgrammingtoanInterface.Itisrecommendedto“refertoobjectsbytheirinterfaces”[7,Item#34]sinceinterfacescanreduce

2007/7/3

@DomainParams({\"M\",\"V\",\"C\"})

@DomainInherits({\"LocatorHandle\"})classResizeHandleextendsLocatorHandle{@Override

voidinvokeStart(intx,inty,

@Domain(\"V\")DrawingViewview){

setUndoActivity(createUndoActivity(view));...}/∗∗

∗Factorymethodforundoactivity.∗Tobeoverridenbysubclasses.∗/

protected@Domain(\"M\")UndoablecreateUndoActivity(

@Domain(\"V\")DrawingViewview){

@Domain(\"unique\")ResizeHandle.UndoActivity

undoable=newResizeHandle.UndoActivity(view);returnundoable;}

@DomainParams({\"M\",\"V\",\"C\"})

@DomainInherits(\"UndoableAdapter\")

staticclassUndoActivityextendsUndoableAdapter{...}

}/∗∗

∗BasicimplementationforanUndoableactivity∗/

@DomainParams({\"M\",\"V\",\"C\"})

@DomainInherits(\"Undoable\")

publicclassUndoableAdapterimplementsUndoable{@Domain(\"V\")DrawingViewmyDrawingView;

@DomainParams({\"ui\",\"logic\",\"data\"})@DomainInherits({\"Node\"})classHillNodeextendsNode{

@Domain(\"data\")HillGraphgraph;...}

Whenaddingannotations,anunexpecteddomainparameterof-tenindicatesunnecessarycoupling,e.g.,whyshouldHillNodehaveaccesstotheuidomain?Thusalengthydomainparameterlistcanbeanobjectivemeasureofacodesmell[2].Furthermore,own-ershipdomainannotationscanhelpadeveloperlowerthecouplingbysuggestingwhichspecifictypedeclarationsneedtobegeneral-izedtoshortenthelistofdomainparametersontheenclosingtype.InHillClimber,onesolutionwastoextractanIHillGraphin-terfacefromclassHillGraphthatonlyrequiresthedatadomainparameterandmakeaHillNodeobjectreferencetheHillGraphobjectthroughtheIHillGraphinterface.Wedecidedagainstcar-ryingthisrefactoringfurtherandeliminatingtheuiandlogicdo-mainparametersonHillGraphitself.

SincetheHillGraph,HillNode,etc.,formaparallelinheri-tancehierarchytoGraph,Node,etc.,asimilarrefactoringwasper-formedonGraphbyextractingaIGraphinterface–eventhoughGraphandIGrapharebothparameterizedbydata.

@DomainParams({\"ui\",\"logic\",\"data\"})@DomainInherits({\"Graph\",

\"IHillGraph\"})

classHillGraphextendsGraph

implementsIHillGraph{

...}

@DomainParams({\"data\"})UndoableAdapter(@Domain(\"V\")DrawingViewdv){

@DomainInherits({\"IGraph\"})setDrawingView(dv);

interfaceIHillGraphextendsIGraph{}

...@Domain(\"V\")DrawingViewgetDrawingView(){

}returnmyDrawingView;

@DomainParams({\"data\"})}

@DomainInherits({\"Node\"})voidsetDrawingView(@Domain(\"V\")DrawingViewdv){

classHillNodeextendsNode{myDrawingView=dv;

@Domain(\"data\")IHillGraphgraph;}

..voidsetAffectedFigures(@Domain(\"lent\")FigureEnumerationfe).{

//theenumerationisnotreusablethereforeacopyismade}//tobeabletoundo−redothecommandseveraltimerememberFigures(fe);}

}

Figure11.ConcreteimplementationclassofHandle.couplingbetweenclassesbysplittingintentfromimplementation.Whenfewerdomainparametersareneededtoannotateaninter-face(ascomparedtothecorrespondingclass),ownershipdomainannotationscanenforcethisidiom.

Inparticular,animplementationclasscanrequireaprivateownershipdomaintobepassedasanactualvalueforoneitsparameters.Sinceaprivateownershipdomaincannotbenamedbyanoutsideclient,theclientisthenforcedtousetheinterfacewhichdoesnotrequiretheseparameters.

Forinstance,intheearlierSequenceexample(Figure1),theSeqIteratorclassreceivestheSequence’sprivatedomainownedandhidestheextraparameterizationbehindtheIteratorinterface.ThisforcesaclientoftheSequencetoaccesstheitera-torobjectsonlythroughtheIteratorinterface.AclientmaynotevencasttheIteratorreferencetoaSeqIteratorclass.

WeusedasimilartechniquetodecouplethecodeinHillClimber(SeeFigure12fortheinheritancehierarchy).Theoriginalim-plementationforclassHillNodehadafieldreferenceoftypeHillGraph.However,HillGraphtookthethreedomainparam-etersui,logicanddata,whichrequiredpassingallthoseparam-eterstoHillNode.

8

TightlycoupledcodewasobservedthroughoutHillClimber.Similarly,weweresurprisedthatadialogclassFontDialogre-quiredthedatadomainparameter.ItturnedoutthatFontDialoghadafieldreferencedeclaredwithitsmostspecifictypeGraphCanvas.Insomecases,itispossibletogeneralizethetypeofthereference,e.g.,usejava.awt.Frametoeliminatetheneedforthedomainparameter.However,FontDialogneededaccesstosomeoftheGraphCanvasfunctionality,soadifferentsolutionwasneeded.MediatorPattern.Defininganinterfaceissometimesinsuffi-cienttodecouplecodesincereferringtoanobjectthroughitsinter-facestillrequiresaccesstothedomaintheobjectisin.OnesolutionistousetheMediatordesignpattern[22,p.273],asshownhere.IntheoriginalHillClimberimplementation,NodeobtainedareferencetoGraphCanvas,whichviolatestheLawofDemeter[32],i.e.,objectsshouldonlytalktotheirimmediateneighbors:

@DomainParams({\"data\"})abstractclassEntity{

@Domain(\"data\")Graphgraph;//parentgraph...}

@DomainParams({\"data\"})

@DomainInherits({\"Entity\"})classNodeextendsEntity{...

intgetHeight(){

returngraph.getCanvas().getFontMetrics()...;}}

2007/7/3

graphFramework::EdgegraphFramework::NodegraphFramework::GraphgraphFramework::GraphCanvasHillGraph0..1 - hillGraph - hillCanvasHillEdge0..1HillNode # node - currNode0..1Search0..1 # engine0..1Hill - hillEngine0..1 - hillWindowHillCanvas0..1HillEngineHillWindowGreRRSearchRandSearchSimpleSearchSimAnnealSearchSimRanSearchGreedySearchMCHSearchRdWkSearchFigure12.PartialUMLClassDiagramforHillClimberobtainedfromtheoriginalimplementationusingEclipseUML[39].Thisdiagramdoesnotreflectsomeofthetypesintroducedduringrefactoring,suchasIGraph,IHillGraphandICanvasMediator.ExtractinganinterfacefromGraphCanvaswouldnotwork,asthatreferencewouldstillneedtheuidomainparameter.Moreover,theimplementationofgetFontMetrics()couldnotbemovedtoGraphasitrequiredaccesstoobjectsintheuidomain.@DomainParams({\"data\"})abstractclassEntity{@Domain(\"ui\")IGraphCanvascanvas;//‘ui’unbound...}/∗∗∗DrawApplicationdefinesastandardpresentation∗forstandalonedrawingeditors∗/@DomainParams({\"M\",\"V\",\"C\"})@DomainInherits({\"DrawingEditor\",...)classDrawApplicationimplementsDrawingEditor...{//Opensanewwindowwithadrawingview.@DomainReceiver(\"unique\")protectedvoidopen(...){fIconkit=newIconkit(this);...}}classIconkit{static@Domain(\"unique\")IconkitfgIconkit=null;//ConstructsanIconkitthatusesthegiveneditor//toresolveimagepathnames.@DomainReceiver(\"unique\")

publicIconkit(@Domain(\"unique\")Componentcomp){fgIconkit=this;...}}

Amediatorwasdefinedasfollows:/∗∗∗Mediatorinterface∗/interfaceICanvasMediator{@Domain(\"shared\")FontMetricsgetFontMetrics();...}/∗∗

∗Mediatorimplementationclass∗/

@DomainParams({\"ui\",\"data\"})

classMediatorImplimplementsICanvasMediator{@Domain(\"ui\")GraphCanvascanvas;

MediatorImpl(@Domain(\"ui\")GraphCanvasc){this.canvas=c;}

@Domain(\"shared\")FontMetricsgetFontMetrics(){returncanvas.getFontMetrics();}...}

Figure13.Annotatingasingletonusingunique.

GraphCanvasinitializesthemediator:

@DomainParams({\"ui\",\"data\"})classGraphCanvasextends...{

@Domain(\"data\")MediatorImplmediator;...

@Domain(\"data\")ICanvasMediatorgetMediator(){

returnmediator;}}

@DomainParams({\"data\"})

@DomainInherits({\"Entity\"})classNodeextendsEntity{intgetHeight(){

returngetMediator().getFontMetrics()...;}

5.7OwnershipdomainscanhelpidentifysingletonsWhileaddingownershipdomainannotations,wediscoveredacu-riousinstanceoftheSingletondesignpattern:IconKit’sconstruc-torwasnotprivate,althoughithadastaticinstance()method.Indeed,thereisauniqueinstanceofDrawingEditor(theappli-cationitself)andauniqueIconKit(SeeFigure13)atruntime.

EntityandNodecanthenusethemediatorasfollows:

@DomainParams({\"data\"})abstractclassEntity{

@Domain(\"data\")ICanvasMediatormediator;...}

6.ExpressivenessChallenges

Inthissection,wediscusssomeoftheexpressivenessgapsthatweencountered,someofwhichhadbeenpreviouslymentioned.

9

2007/7/3

classDrawApplicationimplementsDrawingEditor...{...

classMDIDrawApplicationextendsDrawApplication...{...

@DomainParams({\"M\",\"V\",\"C\"})

@DomainInherits({\"MDI_DrawApplication\"})classJavaDrawAppextendsMDIDrawApplication{...

@Domains({\"Model\",\"View\",\"Controller\"})classMain{

@Domain(\"View\")JavaDrawAppapp=newJavaDrawApp();publicstaticvoidmain(

@Domain(\"lent[shared]\")Stringargs[]){@Domain(\"lent\")Mainsystem=newMain();}}

Figure14.Definingthetop-leveldomainsinaseparateclass.6.1

Anobjectcannotbeinmorethanoneownershipdomain

Ownershipdomains,asmostotherownershiptypesystems,supportonlysingleownership,i.e.,anobjectcannotbepartofmorethanoneownershiphierarchy.Proposalsformultipleownership[11]liftthisrestrictioninothertypesystems.Ownershipdomainsdonotsupportownershiptransfer[31]either,i.e.,anobject’sownerdoesnotchange—onlyuniqueobjectscanflowbetweenanytwodomains.Asaresult,manyfine-grainedownershipdomainscannotbedefinedtorepresentmultiplerolesindesignpatterns:e.g.,ifanobjectisbothamediatorintheMediatorpatternandaviewintheModel-View-Controllerpattern,itcannotbeinbothaMediatorownershipdomainandaViewownershipdomainatthesametime.Forinstance,creatingtop-levelownershipdomainstocorre-spondtothedesigninFigure6wouldhavebeenmorechalleng-ingthancreatingthethreetop-leveldomainsforModel,ViewandController:placingaDrawingEditorobjectinaMediatordo-mainwouldhaveprohibiteditfromalsobeingintheViewdomain.6.2

AnobjectcannotplaceitselfinadomainitdeclaresAnobjectcannotplaceitselfinanownershipdomainthatitde-clares.Thisisproblematicfortherootapplicationobject,i.e.,theJavaDrawAppinstance(JavaDrawAppextendsDrawApplicationwhichinturnextendsDrawingEditor).Truetoform,wesolvethisproblemwithanextralevelofindirectionbycreatingafaketop-levelclassMaintodeclaretheModel,ViewandControllertop-levelownershipdomainsanddeclaretheJavaDrawAppobjectintheViewdomain(SeeFigure14).6.3

Publicdomainsarehardtouse

Publicdomainsmaketheownershipdomainstypesystemmoreflexiblethanowner-as-dominatortypesystems[15].Also,publicdomainsareidealforvisualizationbecauseplacinganobjectinsideapublicdomainofanotherobjectrelatestheseobjectswithoutclutteringthetop-leveldomains[1].However,publicdomainsaretypicallyhardtousewithoutrefactoringthecode.Westartedusingtheminafewcasesbutquicklyabandonedthoseattempts.

SincetheObserverdesignpatterntendstomakecommunica-tionbetweenobjectsimplicit,weattemptedtorepresentlistenersmoreexplicitlyusingownershipdomainannotations.Forinstance,itmightmakesensetocreateapublicdomainLISTENERSasado-maintoholdtheListenerobjectsthatanObserverwillnotify—aListeneroftenneedsspecialaccesstotheObserver,butusuallydoesnotneedspecialaccesstotheSubject.

JHotDrawusesadelegation-basedeventmodel:forinstance,aDrawingViewcallsmethodfigureSelectionChangedtono-tifyaFigureSelectionListenerobserverofselectionchanges.SoitmightmakesensetodeclareaFIGURESELECTIONLISTENERS

10

/∗∗

∗DrawingViewrendersaDrawingandlistenstoits∗changes.Itreceivesuserinputanddelegates∗ittothecurrentTool.∗/

@DomainParams({\"M\",\"V\",\"C\"})

@DomainInherits({\"DrawingChangeListener\"})

interfaceDrawingViewextendsDrawingChangeListener...{//AddalistenerforselectionchangesvoidaddFigureSelectionListener(

@Domain(\"?\")FigureSelectionListenerfsl);...}

@Domains({\"owned\"})

@DomainParams({\"M\",\"V\",\"C\"})

@DomainInherits({\"DrawingView\"})

classStandardDrawingViewimplementsDrawingView...{//Registeredlistoflistenersforselectionchangesprivate@Domain(\"owned>\")

VectorfSelectionListeners;StandardDrawingView(

@Domain(\"V\")DrawingEditoreditor,...){//editorisin’V’domainparameter,not’C’!addFigureSelectionListener(editor);...}

//Addalistenerforselectionchanges.

//CommandimplementsFigureSelectionListener//butCommandisinthe’C’domainparameter!voidaddFigureSelectionListener(

@Domain(\"?\")FigureSelectionListenerfsl){fSelectionListeners.add(fsl);}

Figure15.HowtoannotateaddFigureSelectionListener?publicdomainonCommandtoholdtheFigureSelectionListenerobjects.ButCommandimplementsFigureSelectionListener,soaCommandis-aFigureSelectionListener.ThusaCommandobjectcannotsplitapartofitselfandplaceitinthepublicdomainFIGURESELECTIONLISTENERSthatitdeclares.6.4Listenerobjectsareparticularlychallenging

TherewereadditionalcomplicationswhentryingtohighlighttheeventsubsysteminJHotDrawusingownershipdomainannota-tions.Command,whichisintheControllerdomain,implementsFigureSelectionListener,andsodoesDrawingEditor,whichisintheViewdomain.

ConsidermethodaddFigureSelectionListenerin(See

Figure15).HowwouldoneannotatetheformalparameterFigureSelectionListTheparametershouldsupportbothannotationsCandV.Existentialownership[13,29,34]maybetheanswertoincreasetheexpressiveness,e.g.,byannotatingtheparameterwith“any”[34].Otherproblemsofaddingownershipdomainsannotationstolistenershadbeenpreviouslyidentified[44].6.5Staticcodecanbechallenging

Eveninsuchawell-designedprogramasJHotDraw,wefoundafewinstanceswhereownershipannotationscannotbemadetotype-check.Inparticular,inFigure16,thestaticHashtablecannothavetheM,V,andCdomainparametersbecausethedomainparametersdeclaredontheclassNullDrawingViewarenotinscopeforstaticmembers.Staticmemberscanonlybeannotatedwithsharedorunique,andthesevaluescannotflowtotheMx,VxorCxmethoddomainparameters.

AnnotatingthegenericHashtablealsorequiresnestedparam-eters:Hashtablehasthreedomainparametersforitskeys,valuesandentries.BothDrawingViewandDrawingEditortakeM,V,andCasparameters.Althoughthenumberofannotationsseemsexcessiveandmaybearguesinfavorofgenericownership[41],the

2007/7/3

@DomainParams({\"M\",\"V\",\"C\"})

@DomainInherits({\"DrawingView\"})

classNullDrawingViewimplementsDrawingView...{static@Domain(\"unique,?,?>\")

HashtabledvMgr=...;@DomainParams({\"Mx\",\"Vx\",\"Cx\"})

publicsynchronizedstatic@Domain(\"Vx\")DrawingViewgetManagedDrawingView(

@Domain(\"Vx\")DrawingEditored){if(dvMgr.containsKey(ed)){@Domain(\"Vx\")

DrawingViewdv=dvMgr.get(ed);returndv;}...}

Figure16.Howtoannotateobjectsythatarestoredinstaticfields?ownershipdomainsfortheHashtablekey,valueandentriesneednotcorrespondtotheM,VandCownershipdomains.

Asolutionthatisnottype-safewouldbetostoretheHashtableasObject,thencastdowntoaHashtableuponuse—theequiv-alentofrawtypesbutwithoutre-implementingthemintheown-ershipdomainstypesystem.Anothersolutionwouldbetorefactortheprogramtoeliminatethisstaticfieldsinceitgivesanyobjectac-cesstoalltheDrawingViewandDrawingEditorobjects.Sinceitisoftenunrealistictoperformsuchasignificantrefactoring,maybethebestsolutionwouldbetosupportpackage-levelstaticowner-shipdomains,similartoconfinedtypes[9].6.6

Annotationsmaybeunnecessarilyverbose

Ownershipdomainannotationstendtobeverbose:e.g.,formalmethodparametersneedtobefullyannotatedeveniftheyarenotusedinthemethodbodyorusedinarestrictedway.Thisproducesparticularlyunwieldyannotationsforcontainersofgenerictypes.InFigure17,methodclearStackVerboseindicatesthecur-rentlevelofannotationsneeded.Itshouldbepossibletoleaveoutdomainparameterswhentheyarenotreallyneeded.ThismayinvolveusingimplicitexistentialownershiptypesasinclearStackAny:i.e.,thereexistssomedomainparametersd1,d2,d3,d4,suchthattheformalmethodparameterscouldbean-notatedwithlent>.Usingappropriatedefaults,theannotationscouldprobablybereducedtothelevelneededtoannotatearawtype,asshowninclearStack.6.7

ManifestownershipcanreducetheannotationburdenThecurrentdefaultingtoolonlyaddsthesharedannotationtoStringobjects.However,duringtheannotationprocess,wefoundourselvesaddingthesharedannotationtomanyothertypessuchasFont,FontMetrics,Color,etc.Specifyingaper-typedefaultgloballyandnotforeveryinstance,asinmanifestownership[13],wouldhavereducedtheannotationburden.6.8

Reflectivecodecannotbeannotated

JHotDrawusesreflectivecodetoserializeanddeserializeitsstateandsuchcodecannotbeannotatedusingownershipdomains[6].6.9

AnnotateExceptionsaslent

Weannotatedexceptionswithlentsincewewerenotparticularlyinterestedinreasoningaboutthem.However,richerannotationsarepossible[45].

7.RelatedWork

Casestudiesapplyingownershiptypesystemsonrealcodearefewandfarbetween.H¨achler[25]documentedacasestudyapplying

11

@Domains({\"owned\"})

@DomainParams({\"M\",\"V\",\"C\"})publicclassUndoManager{/∗∗

∗Collectionofundoactivities∗/

@Domain(\"owned>\")VectorundoStack;voidclearStackVerbose(

@Domain(\"lent>\")Vectors){s.removeAllElements();}

voidclearStackAny(

@Domain(\"lent>\")Vectors){s.removeAllElements();}

voidclearStack(

@Domain(\"lent\")Vectors){s.removeAllElements();}}

Figure17.Reducingannotationswhentheyarenotreallyneeded.Universes[36,17]onanindustrialsoftwareapplicationandrefac-toringthecodeintheprocess.AlthoughthesubjectsysteminthecasestudyislargerthanJHotDraw(around55,000linesofcode),theauthorannotatedonlyaportionofthesystem.Theauthorman-uallygeneratedvisualizationsoftheownershipstructurewhereaswehadaccesstotoolsupporttovisualizetheownershipstructureandadjusttheannotationsaccordingly[1].N¨ageli[38]evaluatedhowtheUniversesandOwnershipDo-mainstypesystemsexpressthestandardobject-orienteddesignpat-terns[22].However,inrealworldcomplexobject-orientedcode,designpatternsrarelyoccurinisolation[43].Aswediscussedear-lier,thesesubtleinteractions,combinedwiththesingleownershipconstraintofthetypesystem,maketheannotationsdifficult.

Inapreviouscasestudy,were-engineeredHillClimberusingArchJava[4]tospecifyacomponent-and-connectorarchitectureincodeandownershipdomainannotationstospecifythedatasharing[2].Intheearliercasestudy,weperformedrefactoringssimilartotheonesdescribedhere.However,addingownershipdomainanno-tationstotheArchJavaprogramseemedeasier.Indeed,ArchJava’sportconstructeffectivelyreducescoupling;intheplainJavaim-plementation,thesameeffecthadtobeachievedusingprogram-mingtointerfaces,usingmediators,etc.

ArchJava’spropertiesareavailableattheexpenseofvariousre-strictionsonobject-orientedimplementations.Thepreviouscasestudyalsoidentifiedthataddingownershipdomainannotationsre-quiredlesseffortthanencodingthearchitecturalstructureinArch-Java[2,6].Fewerdefectsareintroducedsincecodethatpassesob-jectreferencesneednotbechangedandtheownershipannotationsneednotaffecttheruntimesemanticsoftheprogram.Moreover,theownershipdomainannotations,whiletedioustoaddmanually,arerelativelystraightforwardoncethetop-leveldomainsaredecided,comparedtore-engineeringtouseArchJava.

Addingownershipdomainsannotationsmanuallystillrequiredsignificanteffort,andresearchersarestilllookingatscalableinfer-enceofownershipdomainannotations[6,16].Currentinferencetechniques[35,33]howeveronlyinfertheequivalentofowned,shared,lentanduniqueannotations,i.e.,theyassumeastrictowner-as-dominatorhierarchywhichisnotflexibleenoughtorep-resentmanydesignpatterns.Someapproachesdonotmapthere-sultsoftheanalysisbacktoanownershiptypesystem[35,33].Afullyautomatedinferencecannotcreatemultiplepublicdomainsinoneobjectandmeaningfuldomainparameters,whicharecriticalforrepresentingtheabstractdesignintent,asinthethreetop-level

2007/7/3

Model,View,andControllerdomainsinJHotDraw.Existingin-ferencealgorithmsoftengenerateimpreciseannotations,producingforeachclassalonglistofdomainparameters,oftenplacingeachfieldinaseparatedomain,andannotatingmanymoreobjectsassharedorlentthannecessary[6,16].

8.Conclusion

Wepresentedanannotation-basedsystemthatre-implementstheownershipdomainstypesystemasasetofJava1.5annotations,usingtheEclipseinfrastructure.Usingannotationsimposesmanyrestrictionsandrequireschangingthecodeslightlytoaddanno-tationstoit,andtheannotationlanguagedoestakesomegettingusedto.Still,theannotation-basedsystemisanimprovementovercustominfrastructure,languageextensions,andtheresultinglim-itedtoolsupport:itenabledustoannotatelargerobject-orientedprograms“inthewild”tostudyhowownershipdomainscanex-pressandenforcedesignintentrelatedtoobjectencapsulationandcommunicationandtoidentifyexpressivenesslimitations.

Infuturework,weplanonmakingthetypesystemmoreflexibleandextendingtheannotationlanguageinanon-breakingway.

Acknowledgments

ThisworkwassupportedinpartbyNSFgrantCCF-0546550,DARPAcontractHR00110710019,theDepartmentofDefense,andtheSoftwareIndustryCenteratCarnegieMellonUniversityanditssponsors,especiallytheAlfredP.SloanFoundation.

References

[1]M.Abi-AntounandJ.Aldrich.Compile-TimeViewsofExecution

StructureBasedonOwnership.InIntl.WorkshoponAliasing,ConfinementandOwnership,2007.[2]M.Abi-Antoun,J.Aldrich,andW.Coelho.ACaseStudyinRe-engineeringtoEnforceArchitecturalControlFlowandDataSharing.J.SystemsandSoftware,80(2),2007.[3]J.AldrichandC.Chambers.OwnershipDomains:Separating

AliasingPolicyfromMechanism.InECOOP,2004.[4]J.Aldrich,C.Chambers,andD.Notkin.ArchJava:Connecting

SoftwareArchitecturetoImplementation.InICSE,2002.[5]J.AldrichandD.Dickey.TheCrystalDataFlowAnalysisFramework

2.0.http://www.cs.cmu.edu/~aldrich/courses/654/,2006.[6]J.Aldrich,V.Kostadinov,andC.Chambers.AliasAnnotationsfor

ProgramUnderstanding.InOOPSLA,2002.[7]J.Bloch.EffectiveJava.Addison-Wesley,2001.

[8]B.BokowskiandA.Spiegel.Barat—AFront–EndforJava.

TechnicalReportB-98-09,FreieUniversit¨atBerlin,1998.[9]B.BokowskiandJ.Vitek.ConfinedTypes.InOOPSLA,1999.[10]C.Boyapati,B.Liskov,andL.Shrira.OwnershipTypesforObjectEncapsulation.InPOPL,2003.[11]N.Cameron,S.Drossopoulou,J.Noble,andM.Smith.Multiple

Ownership.InOOPSLA,2007.Toappear.[12]H.B.Christensen.Frameworks:PuttingDesignPatternsinto

Perspective.InSIGCSEInnov.&Tech.inComp.Sci.Ed.,2004.[13]D.Clarke.ObjectOwnership&Containment.PhDthesis,University

ofNewSouthWales,2001.[14]D.ClarkeandT.Wrigstad.ExternalUniquenessisUniqueEnough.

InECOOP,2003.[15]D.G.Clarke,J.M.Potter,andJ.Noble.OwnershipTypesforFlexible

AliasProtection.InOOPSLA,1998.[16]W.Cooper.InteractiveOwnershipTypeInference.SeniorThesis,

CarnegieMellonUniversity,2005.[17]W.DietlandP.M¨uller.Universes:LightweightOwnershipforJML.

JournalofObjectTechnology,4(8),2005.

12[18]A.D.EisenbergandG.Kiczales.ExpressiveProgramsthrough

PresentationExtension.InAOSD,2007.[19]M.D.ErnstandD.Coward.JSR308:AnnotationsonJavatypes.

http://pag.csail.mit.edu/jsr308/,2006.[20]UniversesTools.www.sct.ethz.ch/research/universes/tools/,

2007.[21]R.M.Fuhrer,F.Tip,A.Kiezun,J.Dolby,andM.Keller.Efficiently

RefactoringJavaApplicationstoUseGenericLibraries.InECOOP,2005.[22]E.Gamma,R.Helm,R.Johnson,andJ.Vlissides.DesignPatterns:

ElementsofReusableObject-OrientedSoftware.Addison-Wesley,1994.[23]Gamma,E.etal.JHotDraw.http://www.jhotdraw.org/,1996.[24]G.Goth.BewarethemarchofthisIDE:Eclipseisovershadowing

othertooltechniques.IEEESoftware,22(4),2005.[25]T.H¨achler.ApplyingtheUniverseTypeSystemtoanIndustrial

Application:CaseStudy.Master’sthesis,ETHZurich,2005.[26]JavaCC.https://javacc.dev.java.net/,2006.

[27]JSR175:AMetadataFacilityfortheJavaProgrammingLanguage.

http://jcp.org/en/jsr/detail?id=175,2006.[28]D.Kirk,M.Roper,andM.Wood.IdentifyingandAddressing

ProblemsinObject-OrientedFrameworkReuse.EmpiricalSoftwareEngineering,2006.[29]N.KrishnaswamiandJ.Aldrich.Permission-BasedOwnership:

EncapsulatingStateinHigher-OrderTypedLanguages.InPLDI,2005.[30]G.T.Leavens,K.R.M.Leino,andP.M¨uller.Specificationand

VerificationChallengesforSequentialObject-OrientedPrograms.FormalAspectsofComputing,2007.Submitted.[31]K.R.M.LeinoandP.M¨uller.ObjectInvariantsinDynamicContexts.

InECOOP,2004.[32]K.J.LieberherrandI.M.Holland.AssuringGoodStyleforObject-OrientedPrograms.IEEESoftware,6(5),19.[33]Y.LiuandA.Milanova.OwnershipandImmutabilityInferencefor

UML-basedObjectAccessControl.InICSE,2007.[34]Y.LuandJ.Potter.ProtectingRepresentationwithEffectEncapsula-tion.InPOPL,2006.[35]K.-K.MaandJ.S.Foster.InferringAliasingandEncapsulation

PropertiesforJava.InOOPSLA,2007.Toappear.[36]P.M¨ullerandA.Poetzsch-Heffter.Universes:ATypeSystemfor

ControllingRepresentationExposure.InA.Poetzsch-HeffterandJ.Meyer,editors,ProgrammingLanguagesandFundamentalsofProgramming,1999.[37]G.C.Murphy,M.Kersten,andL.Findlater.HowareJavaSoftware

DevelopersUsingtheEclipseIDE?IEEESoftware,23(4),2006.[38]S.N¨ageli.OwnershipinDesignPatterns.Master’sthesis,Department

ofComputerScience,FederalInstituteofTechnologyZurich,2006.[39]Omondo.EclipseUML.http://www.omondo.com/,2006.

[40]A.Potanin.OwnershipGenericJava.www.mcs.vuw.ac.nz/~alex/ogj/,

2005.[41]A.Potanin,J.Noble,D.Clarke,andR.Biddle.GenericOwnership

forGenericJava.InOOPSLA,2006.

[42]AnnotationFileUtilities.http://pag.csail.mit.edu/jsr308/annotation-file

2006.[43]D.Riehle.FrameworkDesign:aRoleModelingApproach.PhD

thesis,FederalInstituteofTechnologyZurich,2000.[44]J.Sch¨aferandA.Poetzsch-Heffter.SimpleLooseOwnership

Domains.InFTfJP,2006.[45]D.Werner,,andP.M¨uller.ExceptionsinOwnershipTypeSystems.

InFTfJP,2004.[46]ArchJava.http://www.archjava.org/,2007.

2007/7/3