Re: Competing Crosscuts

Awais,
The 'Proof Obligations' paper is a clear statement of the Aspects problem though I think that AOSD techniques on their own cannot entirely resolve the range of problems generated by aspects in normal development methods (pre-aspects).

It is difficult to ignore the reduction and partitionoing effects of the waterfall model, or similar.  Whilst only parts of the conceptual framework are likely to relate to aspects and only some aspects generate crosscut effects, the development method still provides a framework against which to map system aspects. 

Problems can arise when we try to bridge the aspectual gap between the static and dynamic models generated during development. Dynamic models are likely to be conditional whereas static models mainly represent the structure for software operations. These provide different views of the system under development which help the developer to visualise the system. Each model has different attributes which will inform the design under different conditions or states. 

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?

 
Regards
 
Charles
 

________________________________

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