[aosd-discuss] can you have interception w/o aop?

Kevin Sullivan sullivan.kevinj at gmail.com
Wed Apr 5 13:26:47 EST 2006

There are a few misconceptions about our paper and our definitions
embedded in the note below. Let me see if I can clear them up.

On 4/5/06, Cristina Videira Lopes <lopes at ics.uci.edu> wrote:
> > -----Original Message-----
> > To briefly quote from the paper:
> >
> >       "We say that a design or a part of a design is modular
> > if its elements
> >       do not depend on each other (although they may depend
> > on external
> >       design rules that serve to decouple them)."
> Maybe I'm interpreting this out of context, but this is the strictest
> definition of modularization that I have ever seen...
> Under this definition, my laptop doesn't seem to be a modular system. For
> example, the main body depends on both the power cord and the battery to
> function properly. There is no design rule that decouples the power cord
> and
> the battery from the main body -- the computer industry seems to make a
> point in creating an endless variety of power cords and batteries that are
> specific to every laptop model out there.

The misconception here is that independence of the design tasks (modulo the
design rules) equites to functional independence of the designed components
the actual artifact. That's not true. A laptop obviously depends on the
of power to work. However, that doesn't mean that the engineering group
tasked to design the motherboard depends on decisions made by the group that
is tasked to design the power cord, or vice versa. Appropriate design
that modularize the design and the design tasks--allow these design tasks to

proceed independently. What do the design rules look like in this case? They

specify power levels and physical plug configuration (and probably other
I'm not an electrical engineer and I haven't actually studied this kind of
Once the cord designers know these parameters, they can go ahead and make
their design decisions independently of those being made by the motherboard
group ( e.g., they can select and change their decisions about wire gauge
conducting material without having to coordinate with the motherboard
and the laptop "main body" group can go ahead and make decisions without
ever having to coordinate with the power cord design group (e.g., the main
group can make decisions about how to allocate the available power to
without ever having to talk to the power cord designers, precisely because
is a decoupling design rule in place: "here's how much power (a) the cord
supply, (b) the body can consume").

You may say, of course, that there are different design rules decoupling the
> power cord and the battery for every laptop model. Well, yes, but this
> seems
> to trivialize the concept of design rule. Applying this to software, it
> would mean that you go from a non-modular to a modular design simply by
> proliferating interfaces, with the sole purpose of "decoupling" every pair
> of interacting components.

The misconception here is that our paper advocates indiscriminate decoupling
design decisions. That is not true. We very clearly state criteria for
design into modules. At a technical level, one does this by using a
information hiding approach in which decisions are decoupled in a principled
for a variety of reasons, e.g., for parallelism in design, abstraction from
 and ease of evolution. At a business level, one does this in part driven by
the goal
of increasing the net (financial) options value of a design -- (net of the
direct and
opportunity costs of modularity). A cursory reading of the paper will make
points clear, and the the underlying theories and literature are adequately

While we can do that, those interfaces / design
> rules / decoupling are an illusion, they serve no real purpose, because
> some
> implementation dependencies are an inherent part of the problem
> formulation.
> There are many purposes for modularization, not just the ADT-ing purpose,
> which is what this definition seems to imply.

The misconception here is that our notion of design rules is equivalent to
imposition of an abstract data type interface. That is not true. In fact,
the main
focus of the paper is on a new and very non-ADT-like concept of interface
of modularity for AOP, which in later work (see Griswold et al., IEEE
January/February 2006) we called the crosscut programming interface or XPI.
The power core example should also make clear that design rules in our view
are not equivalent in our conception to ADT-based API's. In the power cord
the rules stipulate power levels, physical form factors, and probably other
properties, such as corrosion resistance under electrical current at the

In the case of my laptop, it's
> very convenient to dettach the power cord and the battery from the main
> body
> when I travel, even if they only work for my laptop and no other laptop in
> the world. The battery-as-module is particularly convenient, as its
> performance degrades over time; it's good to be able to replace it with
> another one of exactly the same type, rather than having to buy a new
> laptop
> when the battery dies.

The misconception here is that modularity in design and modularity in use
are the
same. That is not true. It's possible to have neither, either or both. A
coupled design task could produce an artifact that is modular in use. A
design task could produce an artifact that is completely integral in use.
Etc. Of
course in practice there is often a close alignment between the modular
of the design and design task and of the artfact-in-use (as in the PC
industry, in
the audiophile industry, etc).

In the computer industry, non-ADT-ing modularizations work to the financial
> advantage of market leaders... "Buy a complete modular system where some
> modules may break; you can get a replacement from us only, at $50!"
> Standardizing the technology of power cords and batteries -- technically
> simple -- would disrupt the market.
> Establishing design rules in a modular design has effects which you may or
> may not want. But that doesn't mean that a system isn't modular until all
> of
> its components depend only on design rules.

The misconception here is that that is what we said :-) That's not true.
we said is the following: "We say that a design or a part of a design is
if its elements do not depend on each other (although they may depend on
external design rules that serve to decouple them)." We stand by this

Best regards,
Kevin Sullivan
University of Virginia

I would claim that the whole art
> of modular design is in deciding what is *and what isn't* a design rule.
> The
> proliferation of trivial design rules can have a negative effect on the
> value of the design.
> -Crista
> PS. ADT = Abstract Data Type, roughly, an interface that can have many
> implementations.
> __________________________________________________
> AOSD Discuss mailing list    -    discuss at aosd.net
> To unsubscribe go to http://aosd.net
> Check out the AOSD.net Wiki: http://aosd.net/wiki

Kevin Sullivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20060405/b4a4f581/attachment.htm

More information about the discuss mailing list