Re: Competing Crosscuts

The idea of composition in this respect is interesting because I think how aspects are instantiated contributes to the composition problem at the early stages of development.  Perhaps, this is partly because early aspects analysis only identifies the existence of aspects and not always their composition - the 'process' can only analyse what's there in terms of specification. 
 
In addition, if the system definition is incomplete then it may be possible to that adverse (or competing) crosscuts are a result of erroneous composition?  At such an early stage of development logic has yet to be developed to determine a best fit for aspectual concerns.  Perhaps this is the next stage after early aspects analysis.
 
Regards
 
Charles
 

________________________________

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


 

	As such, perhaps it is this link between both system models that has to be developed to help create an accurate Early Aspects (EA) system view and help to more accurately identify competing crosscuts? 

	I would say so. I think this is an interesting area to explore especially as you can see the aspect composition problem at this level as a view composition problem. Hence revealing competing crosscuts (as you put it) is quite important. But I see that as an outcome of composition at this level as the goal is not to produce an executable specification but to undertake analysis and composition becomes a means to reveal conflicts (as well as positive influences or reinforcements).

	Kind regards,

	
	Awais. 

	 

________________________________

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

	Charles,
	
	This is an interesting point. Any reduction or rationalisation of such
	conflicting influences has to involve the stakeholders. I am not implying a
	waterfall model here anyway but ultimately a reduction implies addressing or
	managing (as you cannot always remove the conflicts) the inherent conflicts
	in requirements. Of course, any decisions/solutions wrt resolution or
	management of conflicts must be traced and refined during architecture and
	design. We explored some of these in the context of the PROBE project
	(involving Shmuel Katz from the Technion). That project was a first step IMO
	in the direction you mention as it looked at deriving proof obligations from
	the aspectual requirements and their trade-offs as well as their refinement
	in design. If you are interested there is a report and paper from RE '04 at:
	
	http://www.comp.lancs.ac.uk/computing/aose/Probe.php
	
	Awais.
	
	
	
	________________________________
	
	        From: Donisthorpe C (AT) [mailto:[email protected]]
	        Sent: 22 May 2007 02:20
	        To: [email protected]; Markus Elfring
	        Cc: [email protected]
	        Subject: RE: [aosd-discuss] 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