Re: Competing Crosscuts

Agreed.  
 
Requirements analysis should ideally include identification of requirements-level interdependencies to help reduce the possibility of "competing crosscuts".  However, I also think that competing elements can be usefully identified at different stages throughout the development process  - from the initial conceptual framework right down into elements of the detailed design.  
 
Perhaps the effect of competing headline influences during this 'process' could be progressively reduced (or rationalised) during software development?  Therfore, reduction still seems the best way of dealing with complex crosscut issues.  
 
Maybe Early Aspects (EA) analysis should incoporate this idea?
 
Regards
 
Charles
 

________________________________

From: Awais Rashid on behalf of Awais Rashid
Sent: Wed 16/05/2007 17:09
To: Donisthorpe C (AT); 'Markus Elfring'
Cc: [email protected]
Subject: RE: [aosd-discuss] Competing Crosscuts


I would go a step further and say that such "competing crosscuts" arise from the inherent interdependencies in the stakeholders' requirements and this is where one should start to address them. Of course, understanding such requirements-level interdependencies allows one to make more informed choices about the architecture.

Awais.


________________________________

	From: [email protected] [mailto:[email protected]] On Behalf Of Donisthorpe C (AT)
	Sent: 16 May 2007 11:41
	To: Markus Elfring
	Cc: [email protected]
	Subject: Re: [aosd-discuss] Competing Crosscuts
	
	
	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