Information Hiding Interfaces for Aspect-Oriented Design∗

Kevin Sullivanφ William G. Griswoldλ Yuanyuan Songφ Yuanfang Caiφ

Macneil Shonle λ
Nishit Tewari φ
Hridesh Rajanφ
φ λ
Computer Science Computer Science & Engineering
University of Virginia UC San Diego
Charlottesville, VA 22903 La Jolla, CA 92093-0114
fsullivan,ys8a,yc7a,nt6x,[email protected] fwgg,[email protected]

ABSTRACT aspects. JPs are points in a concrete program execution, such as

The growing popularity of aspect-oriented languages, such as As- method calls and executions, that, by the definition of the join
pectJ, and of corresponding design approaches, makes it important point model of the AO language, are subject to advising. Advis-
to learn how best to modularize programs in which aspect-oriented ing extends or overrides the action at a join point with a CLOS-
composition mechanisms are used. We contribute an approach to like [22, Ch. 28] before, after, or around anonymous method called
information hiding modularity in programs that use quantified ad- an advice. A PCD is a declarative expression that matches a set of
vising as a module composition mechanism. Our approach rests on JPs. An advice extends or overrides the action at each join point
a new kind of interface: one that abstracts a crosscutting behavior, matched by a given PCD. Because a PCD can select JPs that span
decouples the design of code that advises such a behavior from the unrelated classes, an advice can have effects that cut across a class
design of the code to be advised, and that can stipulate behavioral hierarchy. Advice, pointcuts and ordinary data members and meth-
contracts. Our interfaces establish design rules that govern how ods are grouped into class-like modules called aspects.1 Aspects
specific points in program execution are exposed through a given are intended to support the modular representation of crosscutting
join point model and how conforming code on either side should concerns [13], although they admit other uses.
behave. In a case study of the HyperCast overlay network mid- Thirty-three years ago, seeing the opportunities afforded by the
dleware system, including a real options analysis, we compare the new module composition mechanisms of procedural programming
widely cited oblivious design approach with our own, showing sig- and separate compilation, David Parnas asked the question, by what
nificant weaknesses in the former and benefits in the latter. criteria should systems be decomposed into modules [19]? Tak-
ing comprehensibility, parallel development and ease of change as
Categories and Subject Descriptors: D.2.10 [Software Engineer- goals, he used a comparative analysis to argue that the prevailing
ing]: Design criterion for modularizing systems according to stages of process-
General Terms: Design ing in their flow charts performed poorly relative to his new ap-
Keywords: Aspect-oriented programming, design rules, options proach, information hiding. Under this approach, “one begins with
a list of difficult design decisions or design decisions that are likely
to change. Each module is then designed to hide such a design
1. INTRODUCTION decision from the others [19, p. 1058].” The idea is that stable
Aspect-oriented (AO) programming languages aim to improve interfaces should abstract and decouple such decisions. As an ex-
the ability of designers to modularize concerns that cannot be mod- ample Parnas cites the choice of a data representation, the hiding
ularized using traditional procedural or object-oriented (OO) meth- of which is accomplished by an abstract data type interface. In this
ods. Examples of crosscutting concerns include tracing, logging, paper, seeing opportunities afforded by the new mechanisms of AO
transactionality, caching and resource pooling. The ability to mod- programming, we revisit Parnas’s question with a twist: by what
ularize such concerns is expected to improve comprehensibility, criteria should systems be decomposed into aspects?
parallel development, reuse and ease of change, reducing devel- A widely cited method of aspect-oriented design, popularly called
opment costs, increasing dependability and adaptability and ulti- obliviousness, advocates that the designers and developers of base
mately creating more value for producers and consumers alike. functionality2 need not be aware of, anticipate or design code to
The most prominent AOP model today is that of AspectJ [2, 12]. be advised by aspects. Filman and Friedman say, “Just program
AspectJ extends Java with several complementary mechanisms, no- like always, and we’ll be able to add the aspects later [7, p. 31].”
tably join points (JPs), pointcut descriptors (PCDs), advice and This idea is widely taken as partially defining, and as a design
∗This research was supported in part by NSF grants FCA-0429947 process and architectural style for, AO design: first separate base
and FCA-0429786. and crosscutting concerns; next implement base concerns in an OO
style ignoring crosscutting concerns; finally implement the cross-
cutting concerns as aspects that advise the base code directly. Is this
straightforward AO modularization criterion the best to be found?
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are 1
not made or distributed for profit or commercial advantage and that copies Named pointcuts can be declared in classes, but other AspectJ
bear this notice and the full citation on the first page. To copy otherwise, to constructs are restricted to aspects.
2
republish, to post on servers or to redistribute to lists, requires prior specific The term base in the AOP community refers to the advised, usu-
permission and/or a fee. ally non-aspect-oriented elements of the system. Base code more
ESEC-FSE’05, September 5–9, 2005, Lisbon, Portugal specifically refers to the actual program text, either as implementa-
Copyright 2005 ACM 1-59593-014-0/05/0009 ...$5.00. tion or design.

166
 Aided by a case study of a modern OO system—the HyperCast 2. BACKGROUND
overlay network middleware implementation [10]—we address this
question by comparing the oblivious method to a new one based on 2.1 Obliviousness
design rules [3] as generalized information hiding interfaces. We Obliviousness as a distinguishing characteristic of AOP was first
find that although the oblivious method allows base code design- proposed by Filman and Friedman [6, p. 2]:
ers to ignore aspect design, it leaves important abstractions implicit AOP can be understood as the desire to make quanti-
in program details and does not decouple design decisions in the fied statements about the behavior of programs, and to
other direction. In particular, the freedom afforded to base code have these quantifications hold over programs written
designers comes at considerable cost to aspect designers, who are by oblivious programmers.
thwarted by a lack of constraints on the code they need to advise.
The above-cited paper, whose purpose is to justify this definition,
Results include unnecessarily complex aspects (especially point-
has at least 50 citations in the literature. The vast majority use this
cut descriptors); in some cases the inability to integrate aspect and
paper’s definition of AOP, while a few distinguish their work from
base code at all without changes to the base code; the implicit rep-
this definition.
resentation of important abstractions; and tight coupling of aspect
Quantification needs to be understood before obliviousness can
code to complex and changeable details of base code. AO lan-
be discussed. One distinguishing feature of AspectJ is the abil-
guage researchers have sought solutions in extensions to [20] and
ity to select sets of join points declaratively. For example, the
constraints on [1] join point models and advising. However, pro-
PCD, call(* *State(..)), refers to all calls to methods with
viding new language features is costly and incurs risks in semantic
names ending in State and having any parameter list. Not only do
complications, runtime costs and ultimately lack of adoption.
PCDs save programming effort, but to the extent that they exploit
Our software engineering approach, by contrast, is to impose de-
coding conventions they automatically match desired join points in
sign rules as abstract, design-decoupling interfaces between aspects
new code that follows the conventions. Some have referred to this
and advised code. These interfaces govern how code has to be writ-
intensional property of properly quantified aspects as shyness [18].
ten to reveal specified execution points through the join point model
In the terminology of obliviousness, such aspects are oblivious of
of a language and how aspects can use these interaces. Concretely,
base code.
our rules specify (1) the behaviors to be exposed; (2) constraints on
Quantification’s link to obliviousness is that more expressive-
program implementation to ensure that these behaviors are exposed
ness in the quantification language—for example extending the join
by join points with specific properties, including type (e.g., field ac-
point model and pointcut language of AspectJ—provides for more
cess versus method call) and signature (e.g., method names); and
obliviousness. That is, more power in the hands of aspect design-
(3) behavioral contracts subject to enforcement at the discretion of
ers means that less help is required from base code developers to
the engineer. The first point ensures that the join points that as-
add aspects to a system. As often is the case, greater power can be
pects need are visible. The first two constrain base code designers
a double-edged sword, as we discuss in Section 4. The desire for
and inform aspect designers so that PCDs can be written that re-
greater expressiveness in the quantification language and its atten-
main stable as base code evolves. The last allows the engineer to
dant difficulties have been drivers of aspect-oriented programming
trade between behavioral assurances at interfaces and the openness
language research.
of programs to new advising relationships.
Many variants and degrees of obliviousness can be found in the
We document these rules in interface specifications that base
literature, each of which carries different implications. We list the
code designers “implement” and that aspects may depend upon.
definitions most relevant to the current paper in an approximate
Once these interfaces are defined, designers can develop aspect and
hierarchy from weakest to strongest, and give them appropriate
base code independently and concurrently, with each side aware of
names:
the shared rules but “oblivious” to each others’ detailed decisions.
Language-level obliviousness is what is allowed when advis-
We find that formulating rules in terms of application-specific ab-
ing constructs are introduced to a programming language. Filman
stract state and behavior, not just in terms of concrete execution
and Friedman provide an apt definition, arguing that “...the distin-
events (e.g., method calls), helps to reveal important abstractions,
guishing characteristic of aspect-oriented programming (AOP) lan-
better separate concerns and improve the resilience of designs.
guages is that they allow quantified programmatic assertions over
Unlike some alternative approaches, ours does not generally re-
programs that lack local notation indicating the invocation of these
quire any of the following: that auxiliary code be added to base
assertions” [7, p. 21]. Specifically, the language enables the base
code (e.g., to signal events); references from base code to aspect or
code developer to write code without needing to use callback hooks
other code; new programming languages, mechanisms or semantics
or macros.
(although tools for design rule checking are sometimes valuable);
Feature obliviousness is when the base code developer is un-
either extensions to or constrains on join point models (JPMs); or
aware of the features that aspects implement. A base code designer
prior constraints on the ability to advise join points.
can prepare code for aspects, e.g., with event hooks, sacrificing
The rest of this paper is organized as follows. The next section
language-level obliviousness but retaining feature obliviousness.
provides background on the concept of obliviousness and on the use
From an information-hiding perspective [19], feature obliviousness
of design structure matrices and design rules in modeling modular-
matches the classic notion of obliviousness: services are unaware
ity in design. Next we introduce the HyperCast case study, includ-
of their clients, but are obliged to serve clients that meet the given
ing its design considerations and crosscutting concerns. Then we
preconditions. Our approach provides for what amounts to a com-
consider designing, developing, and extending HyperCast through
bination of both language-level and feature obliviousness as well
the oblivious aspect-oriented design approach. We then repeat the
as shyness through naming, syntactic, procedure calling and simi-
exercise with the information-hiding design-rules approach. Fi-
lar conventions. One result is that aspects can be more “base code
nally, we compare the two approaches, first qualitatively, from the
shy” and hence not have to change when the base code evolves.
designer’s perspective, then quantitatively using an economic anal-
Designer obliviousness is when the designers of the base code
ysis based on the theory of real options [3].
can be oblivious to the existence of aspects; in particular, not de-
signing any differently than they normally would. As Filman and

167
Friedman say “For true AOP, we want our system to work with a chain of dependences. In such a structure, upstream design deci-
oblivious programmers—ones who don’t have to expend any addi- sions have to be resolved before downstream decisions that depend
tional effort to make the AOP mechanism work” [6, p. 2]. In ad- on them. A design and its implementation process are called cou-
dressing the properties of AOP that aid decoupling (i.e., separation pled if its elements depend on each other in cyclic relations.
of concerns), Erad, Filman, and Bader note [5, p. 31]: It is common for different dependence structures to prevail in
different stages of a software process and in different parts or at
This includes obliviousness, whether the writer of the different levels of a design. In a waterfall process, for example, the
main code be aware that aspects will be applied to relationship between the architectural design and implementation
it; intimacy, what the programmer has to do to pre- processes is hierarchical, but the implementation task is modular, in
pare code for aspects; and globality versus locality, that the identified modules can be developed independently subject
whether aspects apply to the program as a whole or to the prevailing rules (e.g., the syntax, behavioral, performance,
only parts of it. and dependability specifications).
Intimacy, as used here, is at the other end of the spectrum from Following Baldwin and Clark [3] and the subsequent work of
obliviousness: the oblivious base code developer would not prepare Sullivan et al. [24], we represent design dependence structures us-
code for aspects. To satisfy designer obliviousness, however, the ing Design Structure Matrices (DSMs) [23]. DSMs present in a
developer has to meet the stronger criterion of not even needing to graphical form the pair-wise dependence structures of designs and
be aware that aspects will be applied to it. This would generally and of their corresponding development and evolution process.
rule out communication with aspect designers. Figures 1, 2, and 4 in the following sections are examples. The
The adoption of this definition of AOP has reached the popular rows and columns of a DSM are labeled with design variables.
press. In Laddad’s widely acclaimed book on programming with These are the design elements or dimensions for which the design-
AspectJ, he says of AspectJ, “AOP modularizes the individual as- ers must make design decisions: e.g., the selection of an algorithm,
pects and makes core modules oblivious to the aspects. Adding a the naming of a class, the formulation of an interface or the choice
new functionality is now a matter of including a new aspect and of minimum acceptable reliability. Cells in a DSM are marked
requires no change to the core modules” [14, p. 28]. to represent dependences among these decisions. For a given row
Pure obliviousness is the limit where perfect obliviousness and (e.g., a design variable A), the marks in that row show which de-
shyness are achieved, allowing for total, symmetric separation of sign decisions A depends upon. The choices made for, or changes
concerns. Filman and Friedman laid it out as the ultimate goal to to, those design variables influence the best choice for A. In Fig-
be sought by AOP researchers [7, p. 31]: ure 1, for example, variable 28, socket impl, depends on 3, 14, 29,
and 30 (socket spec, socket interface, exception logging impl and
It’s a really nice bumper sticker to say “Just program non exception logging impl, respectively). For a given column for
like always, and we’ll be able to add the aspects later.” B, the marks show which variables depend upon B.
(And change policies later, and we’ll painlessly trans- Carefully ordering and clustering the rows and columns of a
form the code for that, too.)3 DSM can reveal large- and small-scale dependence structures in
patterns of marked cells. Consider as an example Figure 1, which
Such a degree of obliviousness is viewed as a far-off ideal by oth- we discuss in detail in the next section. At the outermost level of
ers [4]. In the presence of “harmful aspects” [11], however, com- aggregation, the upper left part of the DSM represents abstract de-
plete obliviousness might not be desirable. sign concerns, and the lower right, the code base that implements
them. The code base comprises both interface and implementation
2.2 Design Structure elements. The marks below the concerns and to the left of the code
The analysis in this paper depends heavily on the notion of de- base indicate a hierarchical structure: the code base depends on the
pendences between elements in a software design, and especially abstract concerns. Similarly, within the code base, the implemen-
on the structure of dependences in a given design. We say that an tation modules depend on the interfaces. The block diagonal struc-
element B depends upon an element A iff B makes assumptions ture of the implementation reveals a modular structure. The ab-
about A that, if invalid, can cause B not to satisfy its specifica- sence of off-diagonal marks indicates no dependences between the
tion. Invalid assumptions can arise for many reasons, including nested smaller boxes (each representing the interdependent design
the following: A’s developer misimplements A’s specification; A’s decisions within an implementation module). The dense marks in
specification changes but A’s developer is not aware of the change; each implementation module reflect internally coupled structures.
B’s developer misunderstands A’s specification; or B is unaware of An interface is an agreement about properties that an element B
changes in properties of A on which B depends. should have and that other elements, such as A, may depend upon.
These design dependences are de facto dependences among the An interface thus comprises a set of design rules to which B is sub-
developers involved in the system design and evolution task. The ject and which A may assume to be followed. One of the central
depends-upon relation is critical for our analysis because changes operations in a design activity is to create interfaces to decouple
to any property of A on which B depends create possible obliga- otherwise coupled design elements and corresponding processes.
tions for B to change. The structure of dependences on design ele- Both elements come to depend on an interface, but are made in-
ments largely determines the dynamics of the design task. dependent of each other. This property is what would commonly
We say that a design or a part of a design is modular if its ele- be called a modular design. However, by Parnas’s criterion, a de-
ments do not depend on each other (although they may depend on sign exhibits information hiding modularity only if the interfaces
external design rules that serve to decouple them). The correspond- themselves are relatively immune to change. By modeling the ex-
ing work in realizing the design is parallel in that these elements can ternal forces of change on a system as a special class of design vari-
be developed or changed independently, modulo their conformance ables that we call environment variables, it is possible to literally
to any prevailing rules. A design and its corresponding implemen- see whether the design is modular in this sense [24]. The interface
tation process are said to be hierarchical if elements are linked in cluster should not depend on the environment cluster; only imple-
3 mentation variables should depend on the environment variables.
A similar quotation can be found in their 2000 paper [6, p. 6].

168
In Figure 1 the environment variables are modeled as elements of 1.protocol_spec
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
.
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

the system requirements specification (or concerns) that the Hyper- 2.service_spec
3.socket_spec
. Basic
.
Concerns
4.monitor_spec .
cast designers believe will change. 5.adapter_spec
6.event_spec
.
.
7.protocol_event_policy .
8.service_event_policy Crosscutting
.
9.info_logging_policy Concerns
.
3. THE HYPERCAST CASE STUDY 10.exception_logging_policy
11.non_exception_logging_policy
.
.
12.protocol_interface .
This paper centers around a comparative analysis of three de- 13.service_interface
14.socket_interface
.OO Interfaces
.

signs for HyperCast, a scalable, self-organizing overlay network 15.monitor_interface

16.adapter_interface
.
.
17.event_interface .
system [10, 15, 16]. The three designs are (1) its actual OO design, 18.protocol_impl
19.protocol_event_impl
x
x
x x x .
x
x
.
x
x
x
x
x
x
(2) an oblivious AO design that we produced by moving scattered 20.info_logging_impl
21.exception_logging_impl
x
x
x
x
x
x
.
x
x
.
x
x
OO modules tangled with
Crosscuting Concerns
22.non_exception_logging_impl x x x x x .
code into aspects using oblivious design, and (3) one based on the 23.service_impl x x x x . x x x x
24.services_event_impl x x . x x x
design rules approach. HyperCast is a real system developed inde- 25.info_logging_impl
26.exception_logging_impl
x
x
x
x
x
x
.
x
x
.
x
x

pendently of the analysis reported in this paper. It includes scat- 27.non_exception_logging_impl

28.socket_impl x
x
x
x x x x .
. x x
29.exception_logging_impl x x . x
tered code fragments for classic crosscutting concerns, including 30.non_exception_logging_impl x x x .
31.monitor_impl x x x x x x . x x
logging. The placement of each fragment indicates objectively and 32.exception_logging_impl
33.non_exception_logging_impl
x
x
x
x
.
x
x
.

precisely where aspects need to advise in order to factor concern- 34.adapter_impl

35.exception_logging_impl
x
x
x x .
x
x
.
x
x
36.non_exception_logging_impl x x x .
related code into aspects using an oblivious approach. 37.event_impl x x x x .

3.1 What HyperCast Does

The key abstraction provided by HyperCast is the overlay socket.
Figure 1: Basic Object-Oriented Design of HyperCast.
An overlay socket supports point-to-point and multicast commu-
nication in overlay networks. HyperCast integrates overlay sock-
ets, viewed as nodes, into networks in a decentralized manner. It
also offers network services including naming, reliable transport cerns. Tangling is seen by reading rows. For example, the protocol
and network management. implementation module depends on the protocol specification but
Key concerns in the design of HyperCast include the follow- also on that of protocol events and each of the logging concerns.
ing: Socket—the design of the overlay socket API; Protocol—the Scattering is seen by reading columns. Changes in the exception
protocols for maintaining various network topologies; Monitor— logging policy (parameter 10), for example, would likely effect ev-
a HyperCast network management capability; Service—network ery implementation module in the system. AOP is meant to enable
mechanisms for end-to-end service; Adapter—a layer that virtu- improved modularity.
alizes underlying networks; Logging—a mechanism to record se-
lected events. These concerns map to loosely coupled classes in the
implementation. 3.3 Comparative Methodology
There are several areas in which scattering and tangling of code We compare the actual HyperCast design with two AO alterna-
is evident. In this case study we address two. The first is log- tives: an oblivious design and one produced using the design rule
ging. A careful study of the logging code in HyperCast revealed method. We produced and tested both alternatives by refactoring
three sub-concerns: logging of informational messages, of raised HyperCast. We produced an oblivious design by assuming that,
exceptions, and of errors that do not raise exceptions. Second, sev- had the developers been able to ignore crosscutting concerns, they
eral HyperCast modules use implicit invocation to notify clients of would have written the same code but with code for the crosscutting
key events. The protocol module, for example, announces events concerns left out. The results is a perfectly reasonable design for
for some transitions in the state machine that implements the self- the base concerns. We then wrote aspects that advise this code in
organizing behavior of HyperCast. The Service module announces precisely the places where scattered fragments appear in the origi-
end-to-end service-related events. We thus inferred the following nal design.
additional concerns: Information logging, Exception logging, Non- It was easy to find scattered code for the concerns of interest:
exception error logging, State machine events, and Service events. they made explicit calls to methods for logging or event notifica-
tion. We refactored the system to move such code (or functional
3.2 The Design Structure of HyperCast equivalents) into aspects using AspectJ 1.2 [2]. The aspects had to
Each concern leads to specification and corresponding imple- advise the new base code with PCDs that caused the given frag-
mentation decisions, which we model as design variables. For ex- ments, now in the form of advice bodies, to be executed at the
ample, one must specify a set of supported underlay networks. This points from which they had been removed.
information is passed to the Adapter developer who then produces The design rules approach is different: Here we asked the ques-
an implementation. Figure 1 presents a DSM showing that design tion, what constraints on the code would shape it to make it rela-
structure in terms of these design variables. We view the specifi- tively easy to write the aspects at hand, as well as support future
cations as environment parameters. They are grouped as the first aspects? We thus not only moved fragments from the original code
major module, in the block on the upper left. We distinguish the to aspects, but refactored the original code in ways dictated by the
crosscutting concerns from non-crosscutting concerns. Implemen- design rule interfaces that we designed. In the following sections,
tation decisions are grouped in the lower right. we compare the results in order to gain insights into the properties
In terms of these large blocks, we have a classic hierarchical of the respective design methods and resulting designs.
(lower triangular) structure: Specification precedes implementa- The phenomena we sought to understand include the difficulty
tion. The implementation block, by contrast, is classically mod- of writing the aspects in the first place, their sensitivity to changes
ular (block diagonal). Once the specifications are fixed, the im- in the base code, and the value of the oblivious approach relative
plementations can be developed and changed independently. How- to the design rule interfaces method. For our design rule method,
ever, each implementation module exhibits serious scattering and we also ask how intrusive it is into the developer’s practice and the
tangling internally due to the influences of the crosscutting con- resulting code.

169
4. THE OBLIVIOUS APPROACH (PROPERTY_NAME_PREFIX + "." + addrType +
We first explore the benefits and costs of a commitment to the ".Address",":0:0");
}
notion of oblivious design. Following the method outlined in the String[] paFields = addrStr.split(":");
previous section, we refactored HyperCast into an oblivious aspect- ...
oriented design. We assume—reasonably, we believe—that the for (int i = 0; i < paFields.length; i++) {
developers could plausibly have written essentially the same OO paStr[i] = paFields[i].trim();
code, just leaving out the scattered parts that implement crosscut- }
ting concerns. We removed the scattered fragments and localized if (paFields.length > 3) {
//logging code
them in new aspect modules: ao protocol events, ao service events, config.err("String" + addrStr + "
ao info logging, ao exception logging, and ao non exception logging. has wrong format for a physical address.");
With implicit invocation now replaced by aspect-oriented advising, }
we also eliminated the whole OO events module. There are a few possible ways to capture the IP address. First,
In writing aspects that would result in these fragments being wo- a two-stage advising sequence could be programmed, in which
ven back into the base code we encountered a number of issues, one advice advises calls to config.getStringProperty to
which we describe below. We give code for each example in its save the IP address, and a separate advice advises the logging join
original form to convey what behavior is required and where. point. Not only is this possibly computationally costly, but its
We studied the HyperCast code to try to characterize the join complexity is sensitive to both whether the local variable com-
points that we’d have to advise to weave the extracted code frag- putation dominates the logging statement and whether such a se-
ments back into the system. We found out that the context of these quence could be nested (which would require a stack to capture all
join points was in one of the following four categories. the relevant state). Two, the aspect developer could perhaps write
1. Private join points. In many cases, fragments had to be wo- a method in the aspect to compute the IP address from scratch.
ven where there were no public join points (e.g., calls to public This would introduce unwanted scattering of IP address compu-
methods). In some cases, code had to be woven into nested switch tations: in essence, base code is being copied in the aspect code.
or if statements, but join points were available, such as setting of a Finally, stepping outside the options available to the developer, the
data member. To identify these join points, we often used the set join point model of AspectJ could be extended for access to local
and withincode pointcut designators. Below is an example. variables. However, this approach would only exacerbate the cou-
pointcut HCLogicalAddrChanged(HC_Node node): pling problems observed in category 1.
set(I_LogicalAddress HC_Node.MyLogicalAddress) 3. Inaccessible join point. This category includes join points
&& (withincode(void HC_Node. within nested switch and if statements, where there is no proxy
messageArrivedFromAdapter(I_Message)) join point to advise. The check-and-branch sequence alone defines
|| withincode(void HC_Node.timerExpired(Object))
|| withincode(void HC_Node.resetNeighborhood())) the join point. Here is an example:
&& target(node); switch(MyState) {
case WaitforACK: {
The pointcut works, but tightly couples the aspect to hidden de- switch(e.getType()) {
tails that the base code developer is free to change. If the devel- case FULL_E2E_ACK: {
oper changes the field name, MyLogicalAddress, the aspect will processAck(msg.getSourceAddress());
not compile, and the aspect must be rewritten. In other words, the if(ACKExpected.isEmpty()) {
MyState = Done;
base code change is non-modular. Unless the base code developer MStore.setTimer(...);
can wait for the aspect developer to discover that the application no /* Notification concern - removed
longer compiles, the base code developer will need to either make if(mylogicaladdress==root) {
the change herself or notify the aspect developer. Here we high- notifyApplication();
light either the lack of obliviousness of the base code developer }
or the potential for high coordination costs, and chaotic, continual */
}
introduction of incompatibilities (bugs) into code. }
2. State–point separation. In many cases, the setting of a vari- break;
able of interest and the join point at which weaving is needed are case {
separated, and the given variable is not accessible to advice through ...
the AspectJ join point model. For example, we need to access an IP }
address error at certain place in order to construct a log message. Here notifyApplication() notifies the application of cer-
The required value is stored in the local variable addrStr, which tain events. We want to replace the use of event notification with
advice cannot access. It is computed earlier by an inlined block advising. The AspectJ JPM does not provide visibility into branches
of code, which is neither governed by the same nesting of if and taken by a program. The solution of recreating these conditionals
switch statements as the logging code, nor solely reserved for use in the advice body at best only scatters the concern, would make
by the logging concern: advice complex and hard to understand, and might not always be
String addrStr; feasible.
InetAddress ipAddr 4. Quantification failure. Many join points that have to be ad-
if (AddrString != null) { vised in the same way cannot be captured by a quantified PCD, e.g.,
addrStr = AddrString; using wild-card notations. A separate PCD is required for each join
} point. There were about 180 places in the base code where logging
else {
String addrType = config.getStringProperty
was required. Most of the join points do not follow a common pat-
(PROPERTY_NAME_PREFIX + ".PhyAddr", tern. Not only is there a lack of meaningful naming conventions
"INETV4AndTwoPorts"); across the set of join points, but also variation in syntax: method
addrStr = config.getStringProperty calls, field setting, etc. One failure mode here is that creating many

170
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
to coordinate with the aspect developers on the proper way to pre-
1.protocol_spec . pare the base code for aspects.
2.service_spec . Basic
3.socket_spec Concerns
. Yet, as the previous section highlights, obliviousness in the de-
4.monitor_spec .
5.adapter_spec .
sign of the base code can cause numerous problems. The question,
6.protocol_event_policy .Crosscutting then, is whether a new method can be devised that realizes the ben-
7.service_event_policy .
Concerns
8.info_logging_policy . efits of AO design and yet minimizes or eliminates these problems.
9.exception_logging_policy .
10.non_exception_logging_policy .
The first two issues could be addressed with a method that molds
11.protocol_interface . OO Interfaces base code in ways that help aspect designers but without the need
12.service_interface .
13.socket_interface . for any auxiliary code, such as event notifications, method calls, or
14.monitor_interface .
15.adapter_interface .
tags. The OO design would be uncompromised, and there would
16.protocol_impl x x x . be no tangling. The third problem in fact highlights an opportunity:
17.service_impl x x x . OO
18.socket_impl x x Implementations
.
the freedom afforded to base code designers by obliviousness de-
19.monitor_impl x x x x x x . lays aspect design because it flows precisely from the hierarchical
20.adapter_impl x x x .
21.ao_protocol_events x x x . nature of the design process. In the oblivious approach, pointcuts
22.ao_services_events x x x . Aspects cannot be written and advice parameter lists cannot be formulated
23.ao_info_logging x x x x x .
24.ao_exception_logging x x x x x x x x x x x . until the base code is written. A short design phase that establishes
25.ao_non_exception_logging x x x x x x x x x x x . symmetric separation of concerns between base designers and as-
pect designers could actually increase overall parallel development.
The design rules methodology provides the basis for such a method.
Figure 2: Obliviousness Aspect-Oriented Design of HyperCast. An essential idea is that for each crosscutting concern, a crosscut-
ting design rule interface is established to decouple the base design
and the aspect design. The constraints imposed by a design rule
PCDs is costly. More seriously, extensions to the base code that govern three things: (1) which execution phenomena must be ex-
should be logged will require the logging pointcut to be updated to posed as join points, (2) how they are exposed through the JPM
capture the new logging points. If the pointcut is not updated, it of the given language (e.g., in AspectJ, rules could govern syntax,
will silently malfunction, as the non-advising of a join point does name, and stack shapes), (3) constraints on behavior across join
not manifest a syntax or type error that can be reported at compile points (e.g., pre- and post-conditions for the execution of advice
time. In this case, then, it is imperative that the base code developer compositions). These elements ensure two important properties.
communicate the changes to the aspect developer. One, the PCDs required by aspects can be constructed and will not
The common theme that runs through all of these problems is have to change when the base code is evolved. Two, the state at
that the oblivious approach might simplify the task of the base code a join point is the actual behavioral point in the execution of in-
designer, but it can significantly complicate overall system devel- terest to the aspect, and that the system state after advice has re-
opment because there is no agreement between the base and aspect turned is not compromised. Our method is thus an instance of the
code developers about how their respective parts will be integrated. information hiding approach, but for crosscutting join-point-based
Rather, the base code developer proceeds to blithely implement “as interfaces.
he would anyway,” and the resulting design decisions then dictate A base/aspect design rule should result in easy-to-use join points
the conditions to which the aspect developers must conform. that give base designers considerable implementation freedom. For
In a nutshell, the oblivious design process is a hierarchical pro- ADT design, the key to an easy-to-use interface that provides free-
cess. Specifications are provided for base and aspect code modules. dom in implementation is that the interface should place reasonably
Then the base code is written. Finally the aspect code is written un- minimal assumptions (constraints) on both the implementation and
der the constraints imposed by both the external specifications and the clients. For example, an associative memory abstraction should
the coding decisions made by the base developer. not have an accessor method that reports the average collision chain
Figure 2, which presents a DSM for the oblivious AO version of length. Nor should the interface make assumptions about clients’
HyperCast, highlights this design structure. The base code mod- intents, say by calling it a Dictionary and limiting use to short string
ules no longer depend on the crosscutting concerns, but the aspect inputs and outputs. For base/aspect design rules, then, we provide
modules now strongly depend on the base implementation mod- the dictum that the quantification of join points and the states at
ules. The cell for (row 21, column 16), for example, indicates those points should be characterized in terms of the application’s
that ao protocol event depends on protocol impl. This dependence own concepts and abstractions, rather in terms of implementation-
arises because the PCD of the aspect module depends on the form dependent aspect or base code details that are subject to change.
of the join points that signal protocol events in the base code, en- In HyperCast, for example, the design rules are best stated not
tirely under the control of an oblivious base code designer. in terms of the logging or notification aspects, but rather in terms
of interesting abstract states and behaviors of the system, e.g., the
5. THE DESIGN RULES APPROACH abstract states of the finite state machine that tracks and manages
the configuration and use of the overlay network. This reflective,
The oblivious design process assumes that it’s bad for base de-
application-centric view allows the base code designer to be obliv-
velopers to be aware of aspects, and that intimacy—the explicit
ious to logging and other aspects, per se, and creates options for
preparation of code for advising by aspects—is even worse. Why?
several possible aspect-oriented extensions to HyperCast such as
For one, the comprehensibility of the base code could be compro-
mirroring and caching. Because design rules are formulated in
mised: it might not manifest a design that matches the designer’s
terms of the abstract system model, the resulting syntactic, nam-
conceptions of the base functionality. Two, the base code could
ing and other constraints are consistent with the base code’s natural
contain tangled concern code, compromising ease of change. Sim-
OO ontology. Although there is scattered work that has to be car-
ilarly, explicit measures in the base code to anticipate certain exten-
ried out to satisfy the rule, and the result is a crosscutting interface,
sions might effectively exclude others. Three, parallel development
we hypothesize that the result is practically indistinguishable from
could be compromised, in that the base code designers would have

171
pure OO design. The following is a description and comparative Protocol

evaluation of our method through our case study application. E v e n ts

Protocol

5.1 Experimental application to HyperCast



To create interfaces for the two crosscutting concerns of logging

I n f o L og g i n g
and notification, we formulated eight major design rules. They con-
stitute five interfaces (with rules 1–4 comprising one interface). S e rv i ce s 

1. State Update. DR1: HyperCast’s functionality is driven by

S e rv i ce s
the abstract state transitions of the protocol’s finite state ma-
S ock e t
chine (FSM). This rule ensures that these transitions are vis- 

ible to clients of HyperCast and it prohibits clients from in-

terfering with HyperCast’s core FSM behavior. E x cp t L og g i n g

M on i tor


2. Update Logical Address. DR2: The changing of a Node’s

logical address is essential to the transition function. This
rules ensures that the changes of logical address are visible, 

N on - E x cp t
A d a p te rs
and it prohibits interference with base behavior. log g i n g

3. Update Neighborhood. DR3: The changing of overlay topol-

ogy is essential to the transition function. This rule ensures Figure 3: The crosscutting interface in HyperCast. The de-
that changes of topology are visible to HyperCast clients, and pendences of base and aspects on DRs is indicated by the arcs.
it prohibits them from interfering with base protocol behav- Base functionality is on the left, design rules in the middle, and
ior. aspects on the right.
4. Join and Leave Overlay. DR4: Expose the leaving and join-
ing of the overlay and aspect modules are removed. Instead, both the aspect modules
5. Update Message Store State. DR5: HyperCast’s services and the basic modules now depend on the design rules.
are driven by abstract state transitions in a component called We now compare the aspects implemented over the two different
the MessageStore FSM. This rule ensures that these transi- versions of the base code. In the oblivious AO design, the aspect
tions are visible to clients of HyperCast. modules are an average 240 lines each in length, whereas for the
design-rules AO design the aspects average only 30 lines each for
6. Throw Exception. DR6: Expose exceptions with context the same functionality. For example, Figure 6 shows the aspects
information. This rule ensures that context information for for handling logical address events, using the two approaches. We
exceptions is available to clients, and it prohibits clients from observe that the aspect in design rules approach is much simpler
interfering with the base code behavior. because specific naming conventions were followed and interest-
7. Error Handler. DR7: This design rule provides a unified ing abstract states were implicitly exposed in all protocol modules.
error handling approach in HyperCast. Without design rules, the aspect had to compute complex pointcuts
by going through lots of details of base code. Moreover, the design-
8. Non-Exception Error Handling. DR8: This rule ensures rule pointcut will capture newly-coded address changes, because it
that error handling is done by the approach defined in DR7. is quantified and base code designers are constrained to write new
Thus all error states are exposed to HyperCast clients. code following the design rule.
Figure 3 presents the resulting structure, with base code on the
left, design rules in the middle, aspects on the right, and depen-
6. QUANTITATIVE ANALYSIS WITH NET
dences of base and aspect codes on DRs indicated by arcs. OPTION VALUE
We refactored HyperCast to implement these rules. We modified Sullivan et al. [24] and Lopes [17], have previously used the
65 places in the Protocol module to follow DRs 1–4, mostly in six net option value model of Baldwin and Clark [3] to characterize
classes, especially in MessageArrivedFromAdapter. We modified and quantitatively compare modular software designs modeled by
21 places in the service classes to follow DR 5. All the modifi- DSMs. In this section, we evaluate HyperCast similarly based on
cations are simple, as the finite state machines were already im- the DSMs introduced in previous sections.
plemented and we only used methods with naming conventions to Given a product, the visible properties of which have a market
expose them. We also removed the old event notification method, value of S0 , the model estimates the additional value due to mod-
which occurred in 41 places across 10 classes. For DRs 7–8, we ularity in its hidden design. The idea is that modularity creates a
first identified 14 error types according to the specification. We portfolio of valuable real options, one per module—options to re-
then create a template to implement DR 7 and DR 8. The refactor- place existing modules with ones that capture new sources of value.
ing involved 55 error occurrences across 18 classes. The model treats the cost of attaining modularity as sunk. The
Such design rules would be used extensively by the aspect de- model thus gives a partial picture—of the value of the flexibilty
signers. Unlike APIs, our interfaces do not have any explicit rep- created by modularity but not of the costs of designing a modular-
resentation in the source code. Rather, they simply constrain the ization. The value of a product including the value of m options
manner in which the code is written. We document these interfaces embedded in its design is modeled as follows.
in a style reminiscent of design patterns [8], as shown in Figure 5.
V = S0 + NOV 1 + . . . + NOV m , where
Figure 4 shows how the design rules decouple the base and as- 1/2
NOV i = max ki {σi ni Q(ki ) − Ci (ni )ki − Zi }
pect elements. Compared to the oblivious design’s DSM in Fig-
ure 2, we observe that all dependences between the basic modules The value of modularity is modeled as the sum of the net options

172
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 privileged aspect EventTest {
1.protocol_spec .
2.service_spec .
// have to compute pointcuts for each protocols
Basic
3.socket_spec
4.monitor_spec
.
Concerns
.
pointcut DTLogicalAddrChanged():
5.adapter_spec . (execution(* DT_Neighborhood.
6.protocol_event_policy .
7.service_event_policy Crosscutting
. DT_randomShiftMyCoordinates())||
8.info_logging_policy Concerns
.
9.exception_logging_policy . execution(* DT_Neighborhood.
10.non_exception_logging_policy .
11.StateUpdate .
updateNodeAddress(DT_LogicalAddress)));
12.UpdateLogicalAddress .
13.UpdateNeighborhood .
14.LeaveAndJoinOverlay . Rules
Design
pointcut HCLogicalAddrChanged():
15.UpdateMessageStoreState .
Interfaces
16.ThrowException . set(I_LogicalAddress HC_Node.MyLogicalAddress)&&
17.ErrorHandler .
18.NonExceptionErrorHandling .
(withincode (void HC_Node.
19.protocol_interface
20.service_interface
x x x x x x x
x x x x
.
.
messageArrivedFromAdapter(I_Message))||
21.socket_interface x x x OO Interfaces
. withincode(void HC_Node.timerExpired(Object))||
22.monitor_interface x x x .
23.adapter_interface x x x . withincode(void HC_Node.resetNeighborhood()));
24.protocol_impl x x x x x x x x x x .
25.service_impl x x x x x x x . OO
26.socket_impl x x x x x .
Implementations pointcut SPTLogicalAddrChanged():
27.monitor_impl x x x x x x x x x .
28.adapter_impl x x x x x x . execution (* SPT_Node.setLogicalAddress
29.ao_protocol_events
30.ao_services_events
x
x
x x x x
x
.
. Aspects
(I_LogicalAddress));
31.ao_info_logging x x x x x x .
32.ao_exception_logging x x .
33.ao_non_exception_logging x x x .
// advice
after() : DTLogicalAddrChanged() || ... {
// handle address changes here
}
Figure 4: Design Rules Aspect-Oriented Design of HyperCast. // for other events...
}
Name: State Update (a)
Rationale: HyperCast’s functionality is driven by the abstract privileged aspect DREventTest {
state transitions of the protocol FSM. This de- pointcut logicalAddrChanged(I_LogicalAddress):
sign rule ensures that these transitions are visible execution(* I_Node+.
to clients of HyperCast and alert clients that they setMyLogicalAddress(I_LogicalAddress));
may not interfere with HyperCast’s code behavior.
after() : logicalAddrChanged() {
Depends upon: none // handle address changes here
}
Base code scope: implements // for other events...
edu.virginia.cs.mng.hypercast.I Node+ }
(b)
Design Rule: Provides: Call to void setState(byte) at the
conclusion of performing a state transition. Figure 6: Aspect for LogicalAddressChanged Events, (a) with-
Requires: No changes to the trace of out design rules, and (b) with design rules.
edu.virginia.cs.mng.hypercast.I Node+

Example: A pointcut for advising all state transitions might the dependences on the current module. Finally, the max selects
be: the value of ki that maximizes the gain for module i. In a nutshell,
pointcut NodeStateChanged () : this is an options pricing formula meant to estimate the value of the
call (void I Node+.setState(*)); real option created by a module in a design.
The two key parameters are technical potential, σ, and complex-
Figure 5: Specification of DR 1, Update State. ity, n. In this paper, we operationalize technical potential as a
stream of change demands, with a percentage of demands imping-
ing on base modules and the rest on the aspect modules. A choice
values (NOV i , i = 1 . . . m) of the modules. The NOV of a mod- of σ thus models a judgment as to where value can be created by
ule is defined as the payoff on a research and development (R&D) changing modules: in the base code or in the aspects.
investment that, for an optimal choice of k explores k candidate re- We estimate complexity using lines of code (LOC) relative to
placements for the current module and that replaces it with the best the LOC of the overall system as a proxy. Recognizing that code
provided that a better one is found. The NOV formula assumes that can have siginificant inessential complexity, we used the LOC of
as k increases, the R&D costs increase linearly but that the benefits the smallest version of each module amongst our three systems.
diminish. In detail, the model assumes a normal distribution, cen- Oblivious aspects were, on average, eight times larger than design
tered at 0, on the values of the k R&D experimental results. Q(k) rule aspects. We thus used the design-rules version sizes to estimate
is the expected maximum positive of k draws from a standard nor- essential complexity.
1/2
mal distribution. For module i, σi ni Q(ki ) is the expected value We computed the value of the embedded options for each design,
of the best of k positive-valued new candidates relative to the value varying σ, the change demands impinging on the base concerns rel-
1/2
of the current module. The standard deviation, σi ni , models the ative to crosscutting concerns, from low to high. Table 1 presents
richness of the design space around the current module as the prod- our results. The OO row presents the summed NOV “value of mod-
uct of a factor, the technical potential, σi , of the module, and the ularity” as a fraction of the base system value S0 for each value of
square root of its complexity, ni , viewed as the number of major σ. The next two rows present value of modularity for the oblivi-
design decisions in the module. Ci (ni )ki models the cost to run ous and design rule designs, respectively (the upper number in each
ki experiments as a function Ci of the module’s complexity ni . row), and this number as a percentage of the corresponding number
Zi = Σjseesi cnj models the cost to substitute in a module given for the base OO design.

173
 The values cannot be taken as economic truths but only as indi- Of course our approach is not a panacea. No approach on the
cators. The development and validation of Baldwin and Clark’s horizon is likely to accommodate unplanned changes at a predictably
model is still at an early stage, even in the economics commu- reasonable cost. It is thus not surprising that our study does not sup-
nity, and it remains an open problem to justify precise estimates port the obliviousness proposition, that AOP fulfills a promise that
for σ, both in general and for software design [24], in particular. at a predictable and reasonable cost one can “Just program like al-
The model does provide for back-of-the envelope exploration of ways, and . . . add the aspects later.” Nor will our approach. Rather,
the consequences of various assumptions, plausibly valid ordinal ours promises benefits when relevant crosscutting behaviors are an-
comparisons and useful insights. ticipated and when new code, anticipated or not, can be written
We first observe that the more likely it is for the crosscutting against existing interfaces.
concerns to change (the left side of the table), the more relative If existing interfaces are inadequate, the designer will, as always,
value is added by either AO design. The value of the modularity in have no choice but to dig into existing code to determine how best
the OO design goes to zero because its modularity is unused. The to integrate the new code. Oblivious AO design provides an op-
value of the two AO designs similarly converges to the same value, tion to integrate new code without changing existing code, pro-
because they only differ in how they relate to the base code. vided that the relevant behaviors are exposed through the join point
Towards the right of the table, as the relative change rate of the model (which is not assured in general). However, integration can
base functionality goes above 90%, the oblivious design becomes be complex and the resulting code subject to disruption by seeming
even worse than the OO design. This is because the oblivious de- innocuous changes in implementation. Our approach would have
sign’s aspects are dependent on the base modules, which are chang- the designer develop a new interface and refactor the code to bring
ing at a high rate, thus producing a high Z. it into conformance. In the face of unanticipated change we thus
In the middle to upper middle part of the table, presumably closer trade non-invasiveness for much simpler aspect code (PCDs) and
to where the relative base change rate is likely to lie, we see that the the preservation of a modular design with abstract interfaces. Of
design-rule design outperforms oblivious design, chiefly because course, our approach does not preclude an oblivious approach.
its Z is zero when the base functionality evolves due to the join Parnas’s interfaces are procedural and hierarchical. Ours fall in
point design rules. Both aspect-oriented designs outperform the the more general class of design rules: constraints that serve to
OO design in the value of flexibility. decouple otherwise coupled design decisions. Our interfaces are
non-procedural and non-hierarchical. They modularize decisions
7. CONCLUSION that generally would be scattered by OO design or subject to change
when base code changes in oblivious design. It’s better for our
In his seminal paper on information hiding [19], Parnas showed
interfaces to crosscut than the design decisions themselves. First,
the deleterious effects of dependences on design decisions that are
our interfaces are stable and simple; the design decisions are not.
complex or likely to change. They make programs hard to under-
Second, our interfaces say only how to write code, not to write
stand, develop in parallel, and change at a reasonable, predictable
more code. No extra or tangled code is left in the base code.
cost. Parnas then showed designers how to do better using abstract
Recently, in a paper on the nature of crosscutting interfaces and
interfaces to decouple such design decisions. In this paper, we
modularity in AO design, Kiczales and Mezini wrote [13]:
revisited Parnas’s ideas in light of the addition of join points and
quantified advising to the programmer’s toolkit. The question we Aspects cut new interfaces through the primary decom-
have addressed is straightforward: what form of information hid- position of a system. This implies that in the pres-
ing interface is needed to expose crosscutting abstract behaviors to ence of aspects, the complete interface of a module can
AO quantified advising while hiding the complex, changeable and only be determined once the complete configuration of
inessential design decisions on either side? modules in the system is known. While this may seem
An AOP language like AspectJ implicitly publishes a vast array anti-modular, it is an inherent property of crosscutting
of join points for any given program. Unless their use is managed concerns, and using aspect-oriented programming en-
carefully, complex integration problems and proliferating depen- ables modular reasoning in the presence of such con-
dences of PCDs on unstable, complex and arbitrary implementa- cerns.
tion decisions result. The oblivious approach dictates that design-
ers make no preparations for aspects. The problem is that aspect This definition supposes that aspects change the interfaces of ad-
code then has to conform to the arbitrary decisions of the base code vised modules by the join points they use. What Kiczales and
designer and cannot count on the presence, regularity or semantics Mezini really compute and document are dependences on join points
of join points. in a given system configuration. In the absence of agreement on
Our approach provides an alternative design criterion. Identify the assumptions that aspect designers may make about join points,
the important, abstract crosscutting behaviors whose implementa- revealing those they do make is an important enabler of modular
tions are complex or likely to change. For each, define an interface reasoning and change. With our approach, sets of permissible as-
that at once constrains the exposure of join points and the behavior sumptions are specified explicitly as interfaces. There is no need
expected and allowed by the interface. Our study of HyperCast sug- for a concept of unstable interfaces inferred ex post from system
gests this approach provides qualitatively and quantitatively better configurations.
modularity than obliviousness (or regular OO design). Our inter- Aldrich recently proposed scoping constructs and a formal se-
faces modularize base and aspect code, decoupling them symmet- mantics that relate to our design rules. The Open Modules system
rically. Oblivious design creates hierarhical dependence of aspect focuses on the exposure of join points such that module state that is
code on base code. Our interfaces also make important crosscutting intended to be hidden cannot be advised [1]. A module has to de-
concerns explicit, that remain implicit in oblivious and OO design. clare a pointcut to export join points on private state. This approach
Our approach abandons design obliviousness but preserves feature permits the evolution of module implementations without rework
obliviousness. Base code designers must be aware of and adapt of aspects. The semantics also supports checking these properties.
their code to crosscutting interfaces, but need not be aware of the However, the resulting interfaces pertain to individual modules and
aspects that use these interfaces. are not crosscutting, so Open Modules do not directly support ex-

174
 σ 1% 10% 20% 30% 40% 50% 60% 70% 80% 90% 95% 99%
OO 0 0 0 0.00164 0.077 0.17 0.31 0.50 0.78 1.09 1.26 1.402
Oblivious 0.537 0.483 0.423 0.375 0.375 0.41 0.49 0.62 0.83 1.10 1.255 1.391
% impr. N/A N/A N/A 2179.55 386.89 141.18 58.06 24.00 6.41 0.92 -0.40 -0.78
Design Rules 0.537 0.483 0.423 0.385 0.389 0.42 0.51 0.66 0.87 1.14 1.29 1.422
% impr. N/A N/A N/A 2244.62 404.78 147.06 64.52 32.00 11.54 4.59 2.38 1.43

Table 1: Net option values for the base OO, oblivious, and design rule designs as a function of the fraction of change demand
impinging on base as opposed to crosscutting concerns.

posure of join points across non-hierarchical parts of a system. [6] R. E. Filman and D. P. Friedman. Aspect-oriented programming is
Today, prominent industrial development teams are reporting suc- quantification and obliviousness. In Workshop on Advanced Separation of
Concerns (OOPSLA 2000), Oct. 2000.
cesses with AOP. How can this be if the oblivious approach has [7] R. E. Filman and D. P. Friedman. Aspect-oriented programming is
such problems? Our informal discussions with insiders suggest that quantification and obliviousness. In Aspect-Oriented Software Development,
some do formulate and follow coding rules that aspect designers de- pages 21–35. Addison-Wesley, 2005.
pend upon. Our approach recognizes such good practice, raises it [8] E. Gamma, R. Helm, J. Vlissides, and R. E. Johnson. Design Patterns: Elements
of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995.
to the level of a principle, and has the benefit of producing explicit [9] W. G. Griswold. Coping with crosscutting software changes using information
abstractions of important crosscutting concerns behaviors against transparency. In Reflection 2001: The Third International Conference on
which aspects are written. Metalevel Architectures and Separation of Crosscutting Concerns, pages
Crosscutting interfaces are not wholly new. Designers of dis- 250–265, Kyoto, Sept. 2001.
[10] Hypercast project. http://www.cs.virginia.edu/ mngroup/hypercast/.
tributed and real-time systems have long provided programming [11] S. Katz. Diagnosis of harmful aspects using regression verification. In
rules to ensure that protocols, although not modularized, are writ- C. Clifton, R. Lämmel, and G. T. Leavens, editors, FOAL: Foundations Of
ten in a consistent manner so as to achieve the desired result. Nam- Aspect-Oriented Languages, pages 1–6, Mar. 2004.
ing and coding rules enforced on a project also serve as implicit [12] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold.
An overview of AspectJ. In 15th European Conference on Object-Oriented
crosscutting interfaces, aiding comprehension and the use of tools Programming (ECOOP 2001), pages 327–353, June 2001.
to manipulate crosscutting code [9]. Our work with HyperCast sug- [13] G. Kiczales and M. Mezini. Aspect-oriented programming and modular
gests that the consistency imposed by our designs rules can have reasoning. In ICSE ’05: Proceedings of the 27th international conference on
similar positive effects on comprehensibility. software engineering, 2005.
[14] R. Laddad. AspectJ in Action: Practical Aspect-Oriented Programming.
The need for the aspect as distinct from the class is a matter Manning Publications, 2003.
of on-going debate in the AOP community. Our study shows that [15] J. Liebeherr and T. K. Beam. Hypercast: A protocol for maintaining multicast
distinguishing between base and aspect code can be counterproduc- group members in a logical hypercube topology. In Networked Group
tive. Rajan and Sullivan similarly showed that in the programming Communication, pages 72–89, 1999.
[16] J. Liebeherr, M. Nahas, and W. Si. Application-layer multicasting with
language context, the dichotomy might have helped promote early delaunay triangulation overlays. EEE Journal on Selected Areas in
adoption of AOP but it also has drawbacks [21]. Not all approaches Communications, 20(8), oct 2002.
manifest a dichotomy: e.g., Eos [21], HyperSlices [25]. In either [17] C. V. Lopes and S. K. Bajracharya. An analysis of modularity in aspect oriented
case, the question remains: how to modularize designs when ad- design. In AOSD ’05: Proceedings of the 4th international conference on
Aspect-oriented software development, pages 15–26. ACM Press, 2005.
vising over join points is available as a programming mechanism? [18] J. Marshall, D. Orleans, and K. J. Lieberherr. DJ: Dynamic structure-shy
Our work provides a basis for an answer. traversal in pure Java. Technical report, Northeastern University, May 1999.
Open questions remain, constituting our future research agenda. [19] D. L. Parnas. On the criteria to be used in decomposing systems into modules.
With what notations and semantics should our interfaces be speci- Commun. ACM, 15(12):1053–1058, Dec. 1972.
[20] H. Rajan and K. Sullivan. Aspect language features for concern coverage
fied? Section 5 suggests a possibility, but it has not been fleshed out profiling. In the Fourth International Conference on Aspect-Oriented Software
or tested. To what extent and how can our interfaces be checked? Development (AOSD 2005), March 2005.
AspectJ’s declare error construct can be used to check some [21] H. Rajan and K. Sullivan. Classpects: Unifying aspect- and object-oriented
rules, especially prohibitions. Can environments such as Eclipse’s language design. In Proceedings of the 27th International Conference on
Software Engineering ICSE 2005), page To appear, May 2005.
AJDT make crosscutting rules more visible and ease their mainte- [22] G. Steele. Common LISP: The Language. Digital Press, 2nd edition, 1990.
nance? AJDT has an effective model for exposing advising; what [23] D. V. Steward. The design structure system: A method for managing the design
about rules governing advising, if written as pointcut descriptors? of complex systems. IEEE Transactions on Engineering Management,
Forthcoming work will address syntactic and behavioral contract 28(3):71–84, 1981.
[24] K. J. Sullivan, W. G. Griswold, Y. Cai, and B. Hallen. The structure and value
specification and checking, in particular. of modularity in software design. SIGSOFT Softw. Eng. Notes, 26(5):99–108,
2001.
[25] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton. N degrees of separation:
8. REFERENCES Multi-dimensional separation of concerns. In Proceedings of the 1999
[1] J. Aldrich. Open modules: Modular reasoning about advice. In 2005 European International Conference on Software Engineering, pages 107–119, May 1999.
Conference on Object-Oriented Programming (ECOOP’05, to appear), July
2005.
[2] AspectJ project. http://www.eclipse.org/aspectj/.
[3] C. Y. Baldwin and K. B. Clark. Design Rules: The Power of Modularity. MIT
Press, Cambridge, MA, 2000.
[4] C. Constantinides and T. Skotiniotis. Reasoning about a classification of
cross-cutting concerns in object-oriented systems. In P. Costanza, G. Kniesel,
K. Mehner, E. Pulvermüller, and A. Speck, editors, Second Workshop on
Aspect-Oriented Software Development of the German Information Society.
Institut für Informatik III, Universität Bonn, Feb. 2002. Technical report
IAI-TR-2002-1.
[5] T. Elrad, R. E. Filman, and A. Bader. Aspect-oriented programming:
Introduction. Commun. ACM, 44(10):29–32, 2001.

175