[aosd-discuss] Paper: Roles and Aspects: Similarities, Differences, and Synergetic Potential

[Juri Memmert]

Am Mit, 2002-10-30 um 21.47 schrieb Gregor Kiczales:

Hi Gregor,


> Juri said:
> > 
> > An aspect is a cleanly encapsulated set of functions 
> > pertaining to only one concern. 
> 
> and...
> 
> > Aspects are clearly defined conceptual entities that can be identified
> > on all levels of the development process.
> 
> As I said before, I think it is essential that any kind of definition of
> aspect distinguish it from other things, like procedures and objects.

Yes.


> I think your first definition above is closer to a definition of
> "modular implementation of a concern" than aspect.  My own definition of
> "modular implementation of a concern" would be something like "cleanly
> encapsulated code pertaining to only one concern".  Your second
> definition, to me, looks like a definition of "concern", not aspect.

Well... I have an easy time to understand an aspect on the mere code
level... but I resent the idea of looking at aspects on one level as X
and on other levels of the development as something else.

I think it's a statement of Siobhan Clarke (but I could very much be
wrong) that part of the benefit of aspect orientation is to allow the
structure of your requirements, design, and code to look alike, to
facilitate traceability.

So, I do not like definitions that are different on different levels.

And yes, I have a hard time distinguishing concern and aspect on
anything else than the code level as I see them as interchangeable. But,
as always, I could be wrong. ;-)


> Its critical that aspect be the same kind of word as object, rather than
> a synonym for concern. We wouldn't need a new word for it, if aspect was
> going to mean the same thing as concern.

Yes. It is critical that we identify aspects and treat them like
objects.
But no. I either want to see aspects on all levels of the implementation
process... and aspects are not really there yet, as far as I can tell.

Please correct me, if I'm wrong.


> The way I think about it is that design starts with a muddle of
> concerns.  Gradually, you tease those out.  As you do so, there are many
> forces acting on how to carve the muddle into individual concerns --
> conceptual, technical, social, cost...

Yes.


> One kind of force is SE/PL obstacles to identifying certain kinds of
> things as individual concerns. This comes from a lack of
> concept/tool/language support for making such a concern be a modular
> unit throughout design and implementation.  So for example, before
> design patterns, it was hard to think about the subject observer pattern
> as individual concern.  After pattersn you could at least think about it
> that way, even it was hard to implement in a modular way.

Yes.


> OO[P/D] gave us a set of concepts and tools for cleanly modularizing
> certain kinds of concerns as "objects".  So when we say object, what we
> are talking about is a concern that, within our current system, is
> amenable to modularization as an object.  Here I mean modularization in
> the design and code.

Yes. *grins* So far, we're talking about the same.


> Now that we have AO[P/d] we have a set of concepts and tools for cleanly
> modularizing other kinds of concerns as "aspects".  So when we say
> aspect, what we are talking about is a concern that, within our current
> system, is amenable to modularization as an aspect. Again here I mean
> modularization in the design and code.

What is the difference? Certain kinds of concerns are encapsulated as
objects. Certain other concerns are encapsulated as aspects.
In an base-aspect dichotomy, there is indeed a distinction between
aspect and concern.
In a hyperspace approach, the dichotomy doesn't exist and there is no
conceptual difference between "aspect" and "base"... and so:

Concerns are encapsulated as objects / aspects / code concerns.

There is no difference.


> Note that this definition of aspect (and object) is relative.  That is
> what the phrase "within our current system" is doing.  We all know that
> sometimes you can rework an OOP design to make something that wasn't
> modular using objects become modular.  The same is true with aspects of
> course.

Yes, of course. Refactoring is always my first choice when looking at
enhancing the separation of concerns. Only if this doesn't take me all
the way (which means: very often), AOSD approaches get used.


> I guess my summary is that concerns are concerns; we want to separate
> them, OO and AO are complementary techniques for doing that; its
> critical not to confuse aspect with concern, just as its critical not to
> confuse object with concern.

As stated above, there is no real difference.

As for not confusing objects with concerns... objects are the physical
manifestation (as much as bits and bytes are a physical manifestation)
of concerns and in themselves are what Cosmos calls "physical concerns"
that have a physically_implements relationship with some "logical
concern".


> The reason I make this point is that when thinking about these issues, I
> think its relevant to always make the parallel with OO (and procedural
> programming) and ask what did and didn't work there.

Yes, here, we're back together again. I fully agree... but one thin that
didn't work in OO was (and is) that there is a chasm between the
different phases of the development.

Let me illustrate this:
A requirement is analyzed and some design is made which then is
implemented.
Sounds good. Is wrong, though.

A set of requirement documents is written, generating artifact type a.
Some analysis documents are written, of artifact type b. The design is
generated in a different format, artifact type c, and the implementation
is yet another type of artifact (d).

The resulting system contains several groups of disjunct artifacts.
Traceability between these artifacts is limited at best. Evolution on
the different levels is possible, but evolution has to be propagated
across artifact groups. And this is much more complicated and causes us
lots of problems.

Looking at these artifacts and considering them all concern within a
meaningful universe that is the application and reasoning about them all
in conjunction is important... and what is lacking in OO.

So, I do not see the dichotomy described above... and thus don't see why
we should replicate that error.


Regards,

	Juri