From mezini@informatik.tu-darmstadt.de  Wed Apr 25 15:03:34 2001

Hi Karl,

YES, you are right. Having traversal strategies in the adapter code
is one way to minimize the dependency of the adapter (connector) code
on the implementation details (= structural details) of the concerns
being connected. Introspective examination is another very general way
of "talking" about "point of interest (= joint points in AspectJ
terminology) within a module.

Mira

(good to get back to these nice inter-atlantic discussions :-))


> Betreff: LAC and replacement specs
>
>
> Hi Mira and Stephan:
>
> I enjoyed reading your paper for the ASoC workshop at
> ICSE 2001 that you sent to the AIRES list. A great paper.
> /proj/adaptive/www/papers/mira
> http://www.ccs.neu.edu/research/demeter/papers/mira/
>
> I found your paragraph about the mechanism for selecting methods
> for replacement very interesting. You say that a function
> could be allowed that by introspective examination selects
> methods for replacement.
>
> This is an important topic because their is a tradeoff:
> When we modularise one concern, we might scatter information
> from another concern and those replacement-selection
> functions you mention allow to
> reduce the scattering.
>
> An example: The ReadersWriters component that replaces
> the read and write method of a participant. When we apply
> the pattern ReadersWriters to the HashTable class, the
> adapter contains some of the details of the HashTable
> class, for example, by enumerating all readers and all writers.
> A function, as you suggest, could compute the readers
> and writers, making the adapter more robust.
>
> Robustness of adapters is one of our focal points; that
> is why we use traversal strategies to map participant graphs
> to classes.
>
> I think that designs should be done in such a way
> so that your replacement-selection functions can be written
> elegantly, keeping the adapters free from too many details.
>
> For a similar reason, we design class graphs in such a way
> that traversal strategies can be written easily,
> keeping the adapters free from too many details.
>
> -- Karl
>

From stephan@laus.cs.tu-berlin.de  Wed Apr 25 19:44:35 2001
Hi,

> YES, you are right. Having traversal strategies in the adapter code
> is one way to minimize the dependency of the adapter (connector) code
> on the implementation details (= structural details) of the concerns
> being connected. Introspective examination is another very general way
> of "talking" about "point of interest (= joint points in AspectJ
> terminology) within a module.
Ok, this is about, how to retrieve information about "points of
interest". All agreed.
But what information is in there?
I personally like the idea, to connect to the capabilities of design,
like annotating methods by "isQuery", "isUpdate" etc, 
(I think the aspectj-mailinglist had such a discussion and 
 dropped the topic ..)
I.e, to make connector specifications more concise, we need richer
models at the base. How about a join point like, all methods that
are allowed in state 'empty' (= no precondition 'state != empty')
etc.pp. I.e, if we want to hook into the "meaning" of host classes,
(instead of the structure they happen to show today)
we must have a way to refer to that meaning.

Has there been research about "semantic-based introspection"?

Stephan