[aosd-discuss] Fw: invasives aspects

[Chitchyan, Ruzanna]

To provide some more "food for thought": there was a panel on AOP and
modular reasoning at the ADI 2006 workshop at ECOOP. The summary of the
panel will appear in the workshop report in the ECOOP workshop reader,
but below is the relevant extract

Thanks

R.

 

 

****Extract (section 5)  from the ADI'06 workshop report*****

5. Do aspectual dependencies and interactions prevent modular reasoning?

A panel of experts from the AOSD-Europe project discussed the question
Do aspectual dependencies and interactions prevent modular reasoning?
Each of the four panellists presented a specific view on the issue,
which are briefly outlined below.

5. 1. Panel Positions

Adrian Colyer questioned how could an approach that gives better
modularity not improve modular reasoning? This is a contradiction. He
pointed out that any new modularity mechanism, by virtue of allowing new
ways of modularity, will have to provide new ways of composition. So if
the aspectual modules and compositions "break modular reasoning", then
what kind of reasoning is broken? He argued that it is the "old"
modularity that will be broken, but a new form of modular reasoning will
arise from new modular representation and composition. Adrian drew a
parallel of the AOSD acceptance with that of past paradigm shifts by
recounting that before procedures the developers had needed to do global
reasoning. With procedures they could do local reasoning, but still had
global data. With objects they could also locally define data. Aspects
are the next step in this ladder of evolution, allowing to locally
define functionality and data used in multiple locations by objects or
procedures. 

Adrian summarised the argument of AO opponents as "if we need to know
about all aspects to reason about a module, how can we have modular
reasoning"? He then explained that, in his view, such argument means
that modular reasoning implies complete locality. However, modular
reasoning is not "all or nothing", but a mechanism to support partial
reasoning about partially localised code or modules in the same way as,
for instance, procedures allow useful analysis about the procedure
content, but they do need to refer to the instance variables. Thus, AOP
supports better partial modular reasoning.

Awais Rashid stated that aspects are about abstraction (abstracting away
from the details of how that aspect might be scattered and tangled with
other functionality), modularity (allowing to modularise the details of
interest, hence facilitating modular reasoning), and composability [11].
He noted that in his view composability is of a paramount importance as
modules need to relate to each other in a systematic and coherent
fashion. Aspects provide advancement in composition mechanisms, thus
complementing the traditional modular reasoning with compositional
reasoning, i.e., the ability to reason about global and emergent
properties of the system using the modularised information. Awais
underlined that in his view, the important contribution of AOP is the
support for this compositional reasoning, which helps developers to more
effectively reason about dependencies and interactions compared to
traditional software engineering techniques. Hence, aspects do not
prevent modular reasoning as this is supported via the abstraction and
modularity support. Furthermore, the composability properties of
aspect-oriented techniques enhance the compositional reasoning support
available to developers.

Theo D'Hondt suggested that maybe such questions as the topic of this
panel were rising because the AO community has approached the notion of
aspects from the wrong perspective. Theo pointed out that historically
Computer Science has developed by increasing the level of abstraction of
the main elements used in development. However, this progression trend
was broken in case of aspects.  The break was in that historically each
new theory had worked to show that the newly proposed abstraction (e.g.,
procedure, object) is the "rule" for the development in that suggested
paradigm. However, in case of AO, aspects are treated as "an exception"
to the existing abstractions. Thus, Theo asked if the AO community
should try and view objects and hierarchical decomposition as a
"specialisation" of aspects? He proposed that, aspects should be more
general abstractions than those of the previous theory. In conclusion,
Theo suggested that aspects should be studies "on their own" as modules,
along with their reasoning support. However, this will only be possible
if aspects are viewed as more general, subsuming previous abstraction
types, so the view on aspects should be revisited.

Mario Sudholt was sceptical that modularity and full obliviousness were
possible with aspects. Mario explained that traditionally, when writing
a system, one would start with modules and interfaces and when writing
them he or she would have a good knowledge of the program structure and
behaviour. However, with AOP, as it is today, the development is moving
from this modular development, into the style of evolutionary
development. He concluded that he does not believe that the current
state of art provides any proof that AO supports an adequate modularity.
Current approaches to  modular properties in the presence of aspects
(e.g.,[1, 7]) are either too restrictive or not powerful/systematic
enough to render a solution. He suggested that this point will remain to
be seen in the future. 

5.2 Discussion

The discussion turned to the question of what is the simplest mental
image of aspect. It was suggested that in most cases aspect is
understood as "interrupt routine plus interrupt processing". However,
this is a very primitive view and the community should work to move away
from this primitive image of aspect to more appropriate image for a
fully fledged module. Indeed, an aspect has state and behaviour, as a
class has state and methods. A class has called methods running over
variables, and aspect has pointcuts, advice and state, with advice
running when the pointcut is matched. So aspect is as much a module as a
class. 

The workshop participants also agreed that one should not think that "an
aspect belongs to a class". Aspects are for modular reasoning about the
aspects themselves, not the class. The claim that aspects change the
classes in an unintended way can be equally well stated about the
classes changing each other as well. The claim that the class does not
know which aspects will apply on it, is also valid about the call to
procedures: one does not know which procedure will be called,
particularly in cases of late binding.

Adrian Colyer also argued that successive levels of modular reasoning
are possible with AspectJ, looking at the aspect only; then at aspects
with the type of applying advice, i.e., before, after or around; after
this the details about the body of the advice can be included into the
reasoning. Thus, different levels of detail for reasoning can be
available at the different element consideration views.

The discussants talked about global versus local design with aspects
versus OO. It was argued that in OO the global design is hard but the
local effects are very clear. On the other hand, with AO global design
is clear and relatively easy, though its effects on local reasoning are
more difficult to account for. Tool support can help in assisting local
reasoning by completing the local details recovered from global
compositions. However, no tool support can adequately recover the global
details from local ones, supporting global reasoning. Thus, AO seems to
progress along the right path. 

Additionally, the participants agreed that aspects bring into
programming languages the notions of quantification over temporal and
conditional references which are broadly used in natural language (e.g.,
notions about history of the programme execution, etc.). Thus aspects
enrich the current programming languages.

After a lively discussion, in summary, most workshop participants agreed
that aspect interactions need to be addressed, but they do not, in
principle, prevent modular reasoning.  

 

*********

 

 

 

 

________________________________

From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On
Behalf Of Ashley at Metamaxim
Sent: 09 January 2007 16:55
To: Gregor Kiczales; AOSD discuss
Subject: Re: [aosd-discuss] Fw: invasives aspects

 

Gregor

 

> The various arguments that AOP does not support modular reasoning
invariably rest on the notion that we ought to be 

> able to do modular reasoning without even simple machine support -- to
be able to print code out and reason about it 

> effectively from the printouts. Since no practicing developer tries to
reason about code today without tool support, even 

> for OO programming, it seems an unrealistic constraint to place on
AOP.

 

The paper I cited does not suggest that reasoning must/should be
possible without tool support. I can see that using a tool might make
reasoning easier, but it is difficult to imagine that it can affect
whether reasoning is theoretically possible.

 

> IMHO all of these arguments against 'invasive' advice miss the key
point: without AOP modularity constructs, true 

> crosscutting concerns cannot be reasoned about in a modular way. With
AOP constructs they can.

 

I did not understand this comment. Can you elucidate, please?

 

Rgds

Ashley

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20070109/19e1487d/attachment.html