Re: Fw: invasives aspects

There is also a book written by Uwe Assman on invasive composition. That 
book is not specific to aspect-orientation though:

http://www.amazon.com/Invasive-Software-Composition-Uwe-Assman/dp/3540443851

Ramy


Chitchyan, Ruzanna wrote:
>
> 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:* [email protected] [mailto:[email protected]] *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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> discuss mailing list    -    [email protected]
>
> To unsubscribe and change options, go to:
> http://aosd.net/mailman/listinfo/discuss_aosd.net
>
> Check out the AOSD.net Wiki: http://aosd.net/wiki
>

_______________________________________________
discuss mailing list    -    [email protected]

To unsubscribe and change options, go to:
http://aosd.net/mailman/listinfo/discuss_aosd.net

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