[aosd-discuss] defining modular reasoning

[Jonathan Aldrich]

What is modularity?  Gregor stated:

> As I see it, what's underlying AOP is the claim that the old definitions
> of modularity and modular reasoning (MMR) were wrong. They were well
> worked out, and highly technical. But they failed to do justice to (at
> least) one problem that arises in real systems, the problem of modular
> implementation of crosscutting concerns (CCC).

I'm an empiricist about modularity.  That is, I only care about a 
"technical" definition of modularity to the extent that it helps me with 
real problems.  These problems have led to at least three commonly-cited 
rationales for modularity:

(1) I can understand a system better if it's cleanly broken into modules.

(2) I can verify the internal invariants of a module if it has a 
well-defined, enforced interface that I can see.

(3) If I have a well-defined interface for a module, I can change that 
module's code in any way that still implements that (behavioral) interface 
and no external code will be affected.

Following Parnas, I find the third rationale (ease of change) especially 
compelling, but I think practicing software developers value all three. 
Furthermore, I believe these fundamental motivations for modularity remain 
unchanged with AOP--you still need to understand code, enforce invariants, 
and evolve code.

------

Does the technical definition of modularity need to change?

Gregor claims the technical definition of modularity and modular reasoning 
needs to change.  I agree, in part (see below).  But any such change cannot 
violate any of the three rationales above.  AOP without tool support can in 
some cases compromise the fundamental rationales for modularity listed 
above--while aiding these rationales in other cases--and any "redefinition" 
of modularity that denies this cannot possibly be correct.  For instance:

Rationale (1): In AOP without tool support, I can't understand a base code 
module as well as in a non-AOP language because aspects that I don't see 
affect its semantics (but yes, I can understand crosscutting concern modules 
better).

Rationale (2): In AOP without tool support, I cannot easily verify the 
internal invariants of a base code module because they might be violated by 
advice that I don't see (but yes, I can verify the invariants of 
crosscutting concern modules better).

Rationale (3): In AOP without tool support, I cannot change the 
implementation of a base code module in behavior-preserving ways with 
confidence that this will not affect clients, because some of my clients may 
be aspects that depend on that internal implementation, not just the visible 
interface (but yes, it is easier to change crosscutting concern modules).

------

Do the "old technical definitions" of modularity still apply?

In work originally outlined in FOAL 2004 and to appear fully fleshed out in 
ECOOP 2005, I've applied "contextual equivalence," one of the "old technical 
definitions" of modularity, to a simple, formal system with AOP-style 
advice.  That definition has a lot of greek in it, but what it comes down to 
is encoding Rationale (3) directly: a system is modular if I can specify the 
interface of a chunk of code, and change the implementation in any way that 
preserves the behavior of that interface, without affecting clients of that 
interface.  The main result of the paper is that if you put a few 
constraints on aspects that advise an interface from outside, you get the 
ease of change benefit of modularity as specified in Rationale (3) while 
still maintaining part of (much of?) the expressiveness of AOP.  You can 
look at an advance copy of the paper (I'm still making final changes) at:

Jonathan Aldrich. Open Modules: Modular Reasoning about Advice. To appear in 
ECOOP 2005.  http://www.cs.cmu.edu/~aldrich/papers/open-modules.pdf

What's interesting to me is how tools change the picture.  With tool 
support, I can place *no* restrictions on aspects, and simply have the tool 
"virtually" add new pointcuts to the interface of a module.  This is roughly 
what systems like the AJDT already do, and it's also pretty close to what 
Gregor and Mira propose as an "aspect-aware interface" in their upcoming 
ICSE '05 paper.  What I find very cool about this is that the technical 
modularity result still holds in the new setting--but it holds for the 
tool-augmented view of the system only, not for the unrestricted AOP code 
alone.

So I would argue that the old technical definitions are still relevant, to 
the extent that they directly capture the main rationales for modularity. 
What we need to do is *reinterpret* these definitions in the light of what 
good tool support can provide in AOP systems.  I did this by analyzing the 
language as a tool presents it to the user, but one could imagine doing it 
by modeling the tool itself.  Furthermore, we need to *extend* these 
definitions to show not only what modularity means for base code, but also 
for aspect code.  I did this only for a few, core, limited advice 
constructs, and only for modularity Rationale #3.  As Gregor says, there's 
still a lot of work to be done here!

Jonathan