Re: can you have interception w/o aop?

So many misconceptions! :-)
I could reply by saying that there is an equal number of mis-misconceptions
in the note below, including the a narrow concept of ADT,  but let me zoom
in to the core of the matter: the definition of modular system.
 
> 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.

I said the following: "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." I stand by my comment.
 

  _____  

From: Kevin Sullivan [mailto:[email protected]] 
Sent: Wednesday, April 05, 2006 11:27 AM
To: Cristina Videira Lopes
Cc: Eric Eide; AOSD Discuss Mailing List
Subject: Re: [aosd-discuss] can you have interception w/o aop?


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 <[email protected]> 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    -    [email protected]
To unsubscribe go to http://aosd.net

Check out the AOSD.net Wiki: http://aosd.net/wiki





-- 
Kevin Sullivan

__________________________________________________
AOSD Discuss mailing list    -    [email protected]
To unsubscribe go to http://aosd.net

Check out the AOSD.net Wiki: http://aosd.net/wiki