[aosd-discuss] Developing software with AOSD

Sat Jan 10 12:34:24 EST 2004

Discussion is always good :)

> Refering to your statement: "What about a situation where a set
> of NFRs only
> influences a single use-case or viewpoint?"
> 1.	First and foremost, would you consider that single use-case itself,
> an aspect of the system?

That's a good point. I guess we are approaching this from two different
perspectives. You seem to be looking at use cases as aspects themselves
while I was implying concerns that would cut across use cases. Viewpoints
and use cases do capture often overlapping perspectives on a system and, in
a way, are crosscutting (if you consider the "system" as the base). However,
there is no reason to rebrand these as aspects. IMO aspects or AO mechanisms
are very useful where there are requirements that cut across an already base
separation done using something like viewpoints and use cases. This is
pretty much similar to what we do at the design or programming level, i.e.,
consider crosscutting concerns with reference to a base OO separation. Of
course, multi-dimensional models such as hyperspaces remove a strict base
separation but you still need to consider a set of hyperslices as a base to
see the crosscutting impact of another (set of) hyperslice on them.

> 2.	Would you model it as an aspect? And under what situations.

It would depend on the nature of the system and the context in which such
NFRs appear (or were you referring to the use case in 1?). So it is an
engineering question, whether you feel it is more effective to model it as
an aspect or not.

Awais.

>
> pan-wei
>
>
> -----Original Message-----
> From: Awais Rashid [mailto:marash at comp.lancs.ac.uk]
> Sent: Friday, January 09, 2004 10:20 PM
> To: Pan-Wei Ng; 'Richard'; discuss at aosd.net
> Subject: RE: [aosd-discuss] Developing software with AOSD
>
> I wasn't implying that identifying aspects is difficult. You are
> absolutely
> right that we have known about crosscutting NFRs for a long time. However,
> aspect identification is a cognitive task and we do not currently have
> systematic means to identify aspects. What about a situation
> where a set of
> NFRs only influences a single use-case or viewpoint? Would one model it as
> an aspect or not. Here other factors come into play, e.g., analysing risks
> associated with modularising or not modularising such a set or
> evolvability
> and adaptability of the specification and/or the system.
>
> Furthermore, while some of the aspects, e.g., security, persistence, etc.
> may be obvious others are not. Also, the more fine-grained
> requirements that
> an aspect encapsulates at the RE-level or the functionality it captures at
> the design or implementation-level is harder to identify and it is even
> harder to ensure that the identified requirements are complete and fully
> capture the intentions of the stakeholders.
>
> Awais.
>
> > -----Original Message-----
> > From: Pan-Wei Ng [mailto:pwng at aspecting.com]
> > Sent: 09 January 2004 13:37
> > To: marash at comp.lancs.ac.uk; 'Richard'; discuss at aosd.net
> > Subject: RE: [aosd-discuss] Developing software with AOSD
> >
> >
> > Actually, identifying aspects is not that difficult. In fact we have
> > been doing that for years, except that we have not been implementing
> > them with AOP. We had all sort of other techniques, we use patterns,
> > we use frameworks, or we directly modify them in our codes. Now we
> > have another implementation technology - AOP, which is better than
> > what we have previously.
> >
> > If you look at ivar's paper on use cases and aspect, you can find that
> > use cases can be kept separate as aspects, so are extension use cases,
> > infrastructure use cases, etc. In fact the way use cases are written
> > are aspect oriented as well. Aspects help align implementation towards
> > concerns (organized through use cases) and with that the need to have
> > explicit traceability will be reduced significantly.
> >
> > Ivar's papers can be found in
> > http://www.ivarjacobson.com/pub/Aspect-Oriented%2520Software%2520D
> evelopment
> > .html
> > In general, you will find is publications in www.ivarjacobson.com
> >
> > -----Original Message-----
> > From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On
> > Behalf Of Awais Rashid
> > Sent: Friday, January 09, 2004 6:39 PM
> > To: Richard; discuss at aosd.net
> > Subject: RE: [aosd-discuss] Developing software with AOSD
> >
> > Richard,
> >
> > AOSD is in the same situation as OO was at one point i.e. how to
> > identify an aspect? At present, this is largely based on experience
> > and intuition.
> > However, the earlier you identify your aspects the better it is as you
> > can carry out trade-off analysis and also identify some early mappings
> > to aspects at the design and implementation level. This also helps
> > maintain traceability of crosscutting concerns. Of course, the big
> > question is how does one identify the aspects? As Karthik pointed out,
> > mostly NFRs tend to be crosscutting. So that's a good starting point.
> > However, FRs can also be crosscutting. One way to deal with
> > identification of aspects is to use an existing RE mechanism, e.g.,
> > viewpoints, use cases, scenarios, etc. and then analyse the
> > specification for tell-tale signs of crosscutting. An example of this
> > can be seen in [1] where the viewpoint-oriend RE method, PREView, is
> > used to assist in identification of aspects. There is also work at
> > Trinity College on identification of aspects [2].
> >
> > Hope this helps,
> >
> > Awais.
> >
> > [1] Rashid, A. Moreira, and J. Araujo (2003) Modularisation and
> > Composition of Aspectual Requirements. 2nd International Conference on
> > Aspect-Oriented Software Development. ACM. Pages 11-20.
> >
> > [2] http://www.dsg.cs.tcd.ie/index.php?category_id=353
> >
> >
> > -----Original Message-----
> > From: discuss-bounces at aosd.net
> > [mailto:discuss-bounces at aosd.net]On Behalf Of Richard
> > Sent: 08 January 2004 21:11
> > To: discuss at aosd.net
> > Subject: [aosd-discuss] Developing software with AOSD
> >
> >
> > Hi everyone,
> > I am new to aspect orientation and I am trying to develop an application
> > using aspect orientation. I got the requirements specification
> > and i want to
> > design the aspect oriented architecture. My problem is I am not able to
> > decide on where and how I can identify the aspects. Should I be
> doing this
> > from the requirements spec and based on that, design the components and
> > aspects separately or is there some other mechanism to do this in the
> > architecture stage itself? I read some papers which mentioned
> that aspects
> > should be identified in requirements stage. I also read papers which
> > mentioned how aspects should be designed in the architecture stage.
> >
> > Please guide me on what might be a considerable procedure to follow.
> >
> > Thanks and Regards,
> > Richard
> >
> >
> > Do you Yahoo!?
> > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> >
> >
> > __________________________________________________
> > AOSD Discuss mailing list    -    discuss at aosd.net
> > To unsubscribe go to http://aosd.net
> >
>
>