[aosd-discuss] discuss Digest, Vol 40, Issue 4

Wed Jan 10 04:23:04 EST 2007

  Introducing AOP
  AOP builds on top of existing methodologies such as OOP and procedural programming,augmenting them with concepts and constructs in order to modularize crosscutting concerns. With AOP, you implement the core concerns using the chosen base methodology. For example, if OOP is the base methodology, you implement core concerns as classes. The aspects in the system encapsulate the crosscutting concerns; they stipulate how the different modules in the system need to be woven together to form the final system.
  The most fundamental way that AOP differs from OOP in managing crosscutting concerns is that in AOP, the implementation of each concern is oblivious to the crosscutting behavior being introduced into it. For example, a business logic module is unaware that its operations are being logged or authorized. As a result, the implementation of each individual concern evolves independently.
  ok in genrale i want any one explane the relation bowtteen AOSD and  Access control .

  Thanks

Rgds
munir

discuss-request at aosd.net wrote:
  Send discuss mailing list submissions to
discuss at aosd.net

To subscribe or unsubscribe via the World Wide Web, visit
http://aosd.net/mailman/listinfo/discuss_aosd.net
or, via email, send a message with subject or body 'help' to
discuss-request at aosd.net

You can reach the person managing the list at
discuss-owner at aosd.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of discuss digest..."

Today's Topics:

1. Re: Fw: invasives aspects (Chitchyan, Ruzanna)
2. Re: Fw: invasives aspects (Gregor Kiczales)

----------------------------------------------------------------------

Message: 1
Date: Tue, 9 Jan 2007 17:42:58 -0000
From: "Chitchyan, Ruzanna" 
Subject: Re: [aosd-discuss] Fw: invasives aspects
To: "Ashley at Metamaxim" , "Gregor
Kiczales" , "AOSD discuss" 
Message-ID:

Content-Type: text/plain; charset="us-ascii"

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-0001.html 

------------------------------

Message: 2
Date: Tue, 9 Jan 2007 10:15:17 -0800
From: "Gregor Kiczales" 
Subject: Re: [aosd-discuss] Fw: invasives aspects
To: "Ashley at Metamaxim" 
Cc: AOSD discuss 
Message-ID:
<8479ff9d0701091015k726351e2ke8a0dde4bb6c06b at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On 1/9/07, Ashley at Metamaxim wrote:

>
> > 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.
>

I believe that it does actually. Consider:

obliviousness threatens conventional modularity
principles and undermines a programmer's ability to reason
locally about the behavior of their code.
...
to understand
the semantics of code in an aspect-oriented language such as AspectJ,
programmers will have to examine all external aspects that
might modify local data structures or control flow.

The idea that you have to manually examine all aspects that might affect the
behavior at a join point comes directly from the idea of not being able to
use tool support to do it. The theme underlying this is that OO, by
comparison, is amenable to modular reasoning because you can follow an
explicit chain of named reference links (calls, instantiations etc.) to see
what is happening. But, if you allow even very simple AOP tool support, then
you recover the exact same sense of being able to follow explicit references
to code that might run at the join point.

> 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?
>

In the paper that Mira and I wrote (AOP and Modular Reasoning) we show that
the canonical display updating concern, implemented without AOP, requires
whole program searching in order to reason about it. By contrast, AOP
supports modular reasoning for display updating, as long as you allow simple
tool support. This part of the paper -- the demonstration of the failure of
non-AOP to be able to support modular reasoning in some cases, is I believe
critical. Unfortunately it seems we weren't clear about that.

P.S. Note that the central technical contribution of the Harmless Advice
paper is not at question. Its great stuff in terms of reasoning about the
interaction between crosscutting concerns at a join point.

Rgds
> Ashley
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20070109/7b949642/attachment.html 

------------------------------

__________________________________________________
AOSD Discuss mailing list - discuss at aosd.net
To unsubscribe go to http://aosd.net

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

End of discuss Digest, Vol 40, Issue 4
**************************************

---------------------------------
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20070110/7d87ce75/attachment-0001.html 