Re: Competing Crosscuts

Hey Charles,

Its amazing to see someone so enthusiastic towards aspects these  
days! :)

> I think it will not always be easy to spot this sort of problem in  
> large systems because the operation can be represented by a  
> combination of several states changes during its operation.  Thus  
> resulting effects from competing crosscuts could have several  
> triggers - a compound effect?
It depends on the capabilities of the aspect language you are using.  
Some allow you to limit the interaction of other aspects within a  
certain control flow so the resulting effects exclude the triggering  
of other aspects. I think some AOP languages like Jasco allow you to  
specify the triggering relative to the context or state of an  
application?

> However, to respond productively to the problem of competing  
> crosscuts, and fragile pointcuts for that matter,  it would be  
> easier to identify triggers at the architectural level prior to  
> implemetation.

Not sure on this one! A software system should be understood and  
evolve based on the inherent relationships between the concerns and  
not on the specific platform on which it is to be deployed on. I  
believe the influence of AspectJ is a plague on early aspects. In my  
opinion, the introduction of such low level platform-specific  
constructs have no place in high level design, where a more semantic  
representation can enrich comprehensibility and composition. The  
paper you quoted suggests a more compositional (symmetric?) approach  
is better and their follow up paper demonstrates a more "composition- 
centric mapping" from a requirements specification to architecture.

The general idea is, think about the problem first and then gradually  
refine the solution until you have something which you can deploy.  
Don't decide that just because your deployment environment is an AO  
one that you should restrict the solution in terms of low-level  
aspect constructs throughout the whole software process. Likewise,  
the stages of a software process shouldn't be oriented around the  
idea of aspects, rather it should be expressive enough to capture any  
kind of environment, including AO. So my final thoughts on this are  
Early Aspects should augment the software process without restricting  
it to AO languages.

Best Regards,
Andrew.

Dé Céadaoin, 16 Bealtaine 2007 11:40, scríobh Donisthorpe C (AT),

> Markus
>
> I'm not sure about tools to identify the problem at the code level.
>
> I think it will not always be easy to spot this sort of problem in  
> large systems because the operation can be represented by a  
> combination of several states changes during its operation.  Thus  
> resulting effects from competing crosscuts could have several  
> triggers - a compound effect?
>
> However, to respond productively to the problem of competing  
> crosscuts, and fragile pointcuts for that matter,  it would be  
> easier to identify triggers at the architectural level prior to  
> implemetation.
>
> I think trying to identify these types of problems within  
> instrumented code is too late in the development process and can  
> make problem solving complex or impossible.  You might end up  
> substantially changing the software design by trying to resolve  
> crosscut issues at the implementation stage.  Such activity can  
> potentially introduce other design errors into the software.
>
> There is some support for this view from Chitchyan, R et al (2007)  
> "Semantics-based Composition for Aspect-Oriented Requirements  
> Engineering".
>
>
> Regards
>
> Charles
>
>
> From: [email protected] on behalf of Markus Elfring
> Sent: Tue 15/05/2007 17:50
> To: [email protected]
> Subject: Re: [aosd-discuss] Competing Crosscuts
>
> > In the context of large complex software systems, can competing
> > crosscuts influence the order of operation in a software system?
> > If so, what evidence exists for this?
>
> Are there any tools available that can show if the same place in a
> source file will be affected by multiple pointcut expressions from
> different aspects?
> Would you like to filter the conditions on the source code if any  
> rules
> will be designed that specify opposite goals?
>
> Regards,
> Markus
>
> _______________________________________________
> 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

_______________________________________________
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