[aosd-discuss] Protection against anti-aspects

[Roger T. Alexander]

On Mar 25, 2005, at 3:08 AM, Juri Memmert wrote:

>
>>> No. The compiler needs to know what he weaves. And the compiler 
>>> needs to
>>> tell me.
>>
>>
>> Agreed on both counts. Of course, a correct implementation of the 
>> weaver
>> will know what it weaves, but the problem, as I pointed out above, is 
>> that
>> the current compiler doesn't tell us what it does (at least in any 
>> really
>> useful sense).
>
> Check out what Hyper/J does when asked to be verbose. Or look at what
> the Plainway spec is for the CME. I think it's quite usable.

Thanks, I will.

>> YES!!! So, how do we get this message through to the guys building the
>> tools??
>
> Well... in the case of the CME, you did. Send me suggestions and we'll
> see what can be done.

I will when I get a chance. This week has been particularly busy.

> In the case of the other tools... I don't know...

Me neither.  Anybody else out there know??

> I assume that a case study with a large customer in a territory that is
> less than friendly to AOSD, so that they throw only almost impossible
> problems at the tools, might be an option.

We certainly need this, and badly. Any thoughts on who/where?


>>
>> I'm not sure what a "concern model" is (let alone a good one).
>
> I sent the reference in an earlier message, but here it is again...
>
> Cosmos, which I use has been developed by Stan Sutton and Isabelle
> Rouvellou at IBM (S. Sutton Jr. and I. Rouvellou, ?Modeling of software
> concerns in Cosmos?, In 1st Int'l Conf. Aspect-Oriented Soft. Dev., 
> ACM,
> 127?133, 2002.)
>
> I use an implementation of that model in Java to handle my models
> (including an analysis engine).


Sorry, I missed the reference, but thanks for providing it again.

>
>>> Because you have a clear knowledge of how to write an interface that
>>> others can use, how to minimize dependencies, how to document the
>>> functionality, assumptions and the function of your framework.
>>
>>
>> I have yet to meet a developer that has the ability to express these 
>> things
>> in such a manner as to ensure that the reader gains the complete 
>> meaning
>> and intent. This is truly hard.
>
> I agree. Most can't. I have, on the other hand, received an interface
> from a very good developer. It contained the methods, the reasons why 
> to
> call the methods, what parameters they expect (not just the types, but
> the content) and what return values can be expected, how errors are
> created and how to react to them. A few methods and about 10 pages of
> JavaDoc. Itr was truly amazing and I never had any trouble with that
> (functionally complex) interface. So it can be done... but it is
> admittedly hard.

Any chance I could get a copy of that to use for instructional purposes?
Any thoughts on how to make that problem easier?

>
>>  But, I do recognize that we do manage to
>> write components (in the most general sense) and reuse them all the 
>> time,
>> some more effectively than others. I would dare say that all 
>> components are
>> reusable to some extent, regardless of their form (i.e., procedures,
>> classes,
>> interfaces, methods, aspects, and so on). The challenge is in reusing 
>> them
>> effectively, and we have learned how to influence this through crisp 
>> and
>> minimal
>> interfaces,  and the like (what you said above). But, aspects bring
>> additional
>> complexity to the table, particularly AspectJ.
>
> I agree that we reusew components... but in most cases not very well,
> regardless of the interface... this is mostly due to some innate
> shortcomings of OO (reuse of callgraphs instead of methods), but that 
> is
> a different discussion.

Ah yes, but surely it would be an interesting discussion!

> I also agree that AOSD adds complexity. But AOSD approaches also add to
> the number of modules and with a good approach, the complexity of the
> individual modules goes down as well as the complexity of how they
> interact...

I don't disagree, and I think (hope) that the benefits will ultimately
outweigh the costs. I can certainly see benefits in many of the examples
folks commonly point out as evidence. However, my concern is is the
more complex and subtle cases where the effects are not so easy to
discern. Of course, the choice of language features can add to
(e.g., AspectJ) the costs.


>
>
>> Please give a succinct description of what you mean by "concern 
>> model". To
>> my knowledge this is not a commonly used term, and I do want to 
>> understand
>> what you mean.
>
> Reference is above and more details are best done on a more personal
> level (much to explain). Will you be at ICSE?

Yes I will! We should meet up!!

>
>
>>> I know. The thing is that all these subtle interactions are there...
>>> they're clearly visible if you take a look at the interactions of 
>>> your
>>> code and aspects on _all_ levels, from the requirements down to the
>>> implementation (and beyond).
>>
>>
>> Not always, at least in my experience. Further, it is not clear that 
>> an
>> what an aspect is at the requirements or modeling level, or whether it
>> translates into an aspect at the implementation level.
>
> It better does, or traceability is lost.

Agreed, but sadly it happens far too often. I'm curious, how are you
using aspect technology for requirements and modeling?

> But most users of AspectJ seem
> to have different uses for the tool than I have for an AOSD tool.
> I need to provide traceability that links each and every requirement
> down to each class (at least, oreferrably method level) over all
> artifacts in the project (or at least those that concern me).

Hmm, this argument applies equally to traditional approaches (i.e.,
non-AOSD) to software development. Are you finding that AOSD makes
it easier?

> I also do
> not need AOSD to simplify coding structures unless that makes a
> requirement easier. I do not, for instance, replace an Observer with 
> its
> AOSD counterpart unless it is justified on a level different form the
> code level.

It's good to hear someone expressing some common sense!

>
>
>>> Most people simply do not make them
>>> explicit... and that's because they do not think about it from the
>>> framework perspective, where every interaction and assumption needs 
>>> to
>>> be clear to the user of the framework... but in most cases isn't.
>>
>>
>> Thinking is hard, and description is even harder.
>
> Huh? You lost me at "thinking". ;-)
> Yes, I agree. But surprisingly, the meta-information is in people's 
> head
> and you can pull it out there and create a meta-model of the 
> application
> and its interactions.
> In some of my projects, I need to find a "Heisenbug" (the closer you
> look, the harder the bugh is to find) in a short time (say 96 hours)
> where the development team has spent 20 man-days looking. In most 
> cases,
> I just need a concern model of the new features added and the features
> touched by these concerns and in the places where they overlap, the
> error lies... Broken contracts account for 99% of the errors.
> Working with the developers, it is possible to do that in surprisingly
> short time... they just need to be shown how.

I couldn't agree more.  However, I am always amazed at how difficult it
is to teach developers this stuff, particularly the ones that have been
working in the "real world" for a while.

>
>
>>> Yes. I have hundreds of them in my applications and they are all 
>>> tied to
>>> the things they apply so that I can identify inconsistencies.
>>
>>
>> A contract is not the same as the assertion (or condition) used to 
>> check
>> it.
>> Contracts are logical properties that must hold at well-defined 
>> points in
>> the behavior of an entity (e.g. procedure, method, class, and so on).
>> Assertions,
>> whether expressed as advice in Aspects, using a built-in assertion
>> mechanism, or
>> a simple conditional expression, are concrete expressions that we 
>> write
>> to state
>> that a particular logical property holds at a particular location in 
>> the
>> control
>> flow. And it is often the case that we cannot write the assertions
>> necessary to
>> completely check that a logical property holds under a particular data
>> representation
>> and control implementation.
>
> Well... we can not write it in one place... but if you write the
> assertion as a hyperslice with multiple classes, multiple methods and
> fields, it can be done.

Good point -- my comments above were fairly myopic. Of course, the 
notion
of a contract spans far beyond method and class boundaries, and this is
often one of the more difficult "aspects" of a system to manage.


>
>
>> So, how do we get the AOP language community to take heed?
>
> As mentioned above, a tough project with impossible tasks might be a
> start... a few spectacular failures would also help.
> The major issue is that AspectJ is a code-centric tool and the problems
> we discuss are not really code-level anymore. It is hard to reason 
> about
> interactions that are basically on the concern level, base don its 
> code.

Interesting observation.

>
>
>>> | This leads to another problem: what constitutes adequate testing 
>>> when
>>> | aspects
>>> | are used in the development?
>>>
>>> Now THAT's a tough one.
>>
>>
>> And it is the crux of my current research agenda.
>
> I will send you a mail I wrote about this topic a while ago. It's not
> right on topic, but might be a start for discussion.

Please do!!


Roger.