[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
in
the actual artifact. That's not true. A laptop obviously depends on the
presence
of power to work. However, that doesn't mean that the engineering group
that's
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
rules--rules
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
things:
I'm not an electrical engineer and I haven't actually studied this kind of
interface).
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
and
conducting material without having to coordinate with the motherboard
group);
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
body
group can make decisions about how to allocate the available power to
devices
without ever having to talk to the power cord designers, precisely because
there
is a decoupling design rule in place: "here's how much power (a) the cord
must
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
of
design decisions. That is not true. We very clearly state criteria for
decomposing
design into modules. At a technical level, one does this by using a
generalized
information hiding approach in which decisions are decoupled in a principled
way
for a variety of reasons, e.g., for parallelism in design, abstraction from
complexity,
 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
these
points clear, and the the underlying theories and literature are adequately
cited.

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
the
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
and
of modularity for AOP, which in later work (see Griswold et al., IEEE
Software,
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
case,
the rules stipulate power levels, physical form factors, and probably other
key
properties, such as corrosion resistance under electrical current at the
contact
points.


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
completely
coupled design task could produce an artifact that is modular in use. A
modular
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
structure
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.
What
we said is the following: "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)." We stand by this
definition.

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