[aosd-discuss] Competing Crosscuts
Awais Rashid
marash at comp.lancs.ac.uk
Wed May 30 12:30:57 EDT 2007
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: discuss at aosd.net
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:cdonisth at glam.ac.uk]
Sent: 22 May 2007 02:20
To: marash at comp.lancs.ac.uk; Markus Elfring
Cc: discuss at aosd.net
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: discuss at aosd.net
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: discuss-bounces at aosd.net
[mailto:discuss-bounces at aosd.net] On Behalf Of Donisthorpe C (AT)
Sent: 16 May 2007 11:41
To: Markus Elfring
Cc: discuss at aosd.net
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: discuss-bounces at aosd.net on behalf of Markus Elfring
Sent: Tue 15/05/2007 17:50
To: discuss at aosd.net
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 - discuss at aosd.net
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 14766 bytes
Desc: not available
Url : http://aosd.net/pipermail/discuss_aosd.net/attachments/20070530/c3686d37/attachment.bin
More information about the discuss
mailing list