InformationHidingInterfacesforAspect-OrientedDesign∗Kevin SullivanφWilliamG.GriswoldλYuanyuan SongφYuanfang CaiφMacneil ShonleλNishit TewariφHridesh RajanφφComputer ScienceUniversity of VirginiaCharlottesville, VA 22903fsullivan,ys8a,yc7a,nt6x,[email protected]λComputerScience&EngineeringUC San DiegoLa Jolla, CA 92093-0114fwgg,[email protected] growing popularity of aspect-oriented languages, such as As-pectJ, and of corresponding design approaches, makes it importantto learn how best to modularize programs in which aspect-orientedcomposition mechanisms are used. We contribute an approach toinformation hiding modularity in programs that use quantified ad-vising as a module composition mechanism. Our approach rests ona new kind of interface: one that abstracts a crosscutting behavior,decouples the design of code that advises such a behavior from thedesign of the code to be advised, and that can stipulate behavioralcontracts. Our interfaces establish design rules that govern howspecific points in program execution are exposed through a givenjoin point model and how conforming code on either side shouldbehave. In a case study of the HyperCast overlay network mid-dleware system, including a real options analysis, we compare thewidely cited oblivious design approach with our own, showing sig-nificant weaknesses in the former and benefits in the latter.Categories and Subject Descriptors: D.2.10 [Software Engineer-ing]: DesignGeneral Terms: DesignKeywords: Aspect-oriented programming, design rules, options1. INTRODUCTIONAspect-oriented (AO) programming languages aim to improvethe ability of designers to modularize concerns that cannot be mod-ularized using traditional procedural or object-oriented (OO) meth-ods. Examples of crosscutting concerns include tracing, logging,transactionality, caching and resource pooling. The ability to mod-ularize such concerns is expected to improve comprehensibility,parallel development, reuse and ease of change, reducing devel-opment costs, increasing dependability and adaptability and ulti-mately creating more value for producers and consumers alike.The most prominent AOP model today is that of AspectJ [2, 12].AspectJ extends Java with several complementary mechanisms, no-tably join points (JPs), pointcut descriptors (PCDs), advice and∗This research was supported in part by NSF grants FCA-0429947and FCA-0429786.Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ESEC-FSE’05, September 5–9, 2005, Lisbon, PortugalCopyright 2005 ACM 1-59593-014-0/05/0009 ...$5.00.aspects. JPs are points in a concrete program execution, such asmethod calls and executions, that, by the definition of the joinpoint model of the AO language, are subject to advising. Advis-ing extends or overrides the action at a join point with a CLOS-like [22, Ch. 28] before, after, or around anonymous method calledan advice. A PCD is a declarative expression that matches a set ofJPs. An advice extends or overrides the action at each join pointmatched by a given PCD. Because a PCD can select JPs that spanunrelated classes, an advice can have effects that cut across a classhierarchy. Advice, pointcuts and ordinary data members and meth-ods are grouped into class-like modules called aspects.1Aspectsare intended to support the modular representation of crosscuttingconcerns [13], although they admit other uses.Thirty-three years ago, seeing the opportunities afforded by thenew module composition mechanisms of procedural programmingand separate compilation, David Parnas asked the question, by whatcriteria should systems be decomposed into modules [19]? Tak-ing comprehensibility, parallel development and ease of change asgoals, he used a comparative analysis to argue that the prevailingcriterion for modularizing systems according to stages of process-ing in their flow charts performed poorly relative to his new ap-proach, information hiding. Under this approach, “one begins witha list of difficult design decisions or design decisions that are likelyto change. Each module is then designed to hide such a designdecision from the others [19, p. 1058].” The idea is that stableinterfaces should abstract and decouple such decisions. As an ex-ample Parnas cites the choice of a data representation, the hidingof which is accomplished by an abstract data type interface. In thispaper, seeing opportunities afforded by the new mechanisms of AOprogramming, we revisit Parnas’s question with a twist: by whatcriteria should systems be decomposed into aspects?A widely cited method of aspect-oriented design, popularly calledobliviousness, advocates that the designers and developers of basefunctionality2need not be aware of, anticipate or design code tobe advised by aspects. Filman and Friedman say, “Just programlike always, and we’ll be able to add the aspects later [7, p. 31].”This idea is widely taken as partially defining, and as a designprocess and architectural style for, AO design: first separate baseand crosscutting concerns; next implement base concerns in an OOstyle ignoring crosscutting concerns; finally implement the cross-cutting concerns as aspects that advise the base code directly. Is thisstraightforward AO modularization criterion the best to be found?1Named pointcuts can be declared in classes, but other AspectJconstructs are restricted to aspects.2The term base in the AOP community refers to the advised, usu-ally non-aspect-oriented elements of the system. Base code morespecifically refers to the actual program text, either as implementa-tion or design.166Aided by a case study of a modern OO system—the HyperCastoverlay network middleware implementation [10]—we address thisquestion by comparing the oblivious method to a new one based ondesign rules [3] as generalized information hiding interfaces. Wefind that although the oblivious method allows base code design-ers to ignore aspect design, it leaves important abstractions implicitin program details and does not decouple design decisions in theother direction. In particular, the freedom afforded to base codedesigners comes at considerable cost to aspect