EarlyAspects

From SPA Wiki

Hot Topic - Early Aspects

Slides available here File:EarlyAspects1.pdf

My own personal motivation for studying Early Aspects (http://www.early-aspects.net) is to see whether it can help with my work in Software Product Lines (http://www.software-acumen.com/). I'd participated in a workshop at SPLC 2005 where we investigated this idea and it seems to show promise.

So, the idea of the session was to give a 'taster' on the emerging subject of Early Aspects - a research area that aims to move the idea of identifying, encapsulating and manipulating Aspects when programming earlier in the software lifecycle - e.g. into Requirements Engineering and Architecture definition.

I began the session by describing what the terms Concern and Aspect meant:

Concern:

This is a very general term. I gave the examples of Maintainability and Varianbility in a Software Product Line. Other examples could be Use Cases, Requirements, Contracts, Packages, Patterns etc.

Aspect:

This is a special kind of concern that is said to crosscut the dominant decomposition. What this means is that for any way you've decomposed your system an aspect will cut across some or all of the decomposed <a href =http://www.fordpartsgateway.co.uk>ford parts</a>.

Some of the comments after the presentation indicated that I didn't get the idea of Aspect across particularly well - I really wanted to come up with some metaphor that involved the people in the room reorganising themselves in some way possibly using string or silly hats but in the end I just used the standard example of logging - probably just as well as we would have only had 15 minutes to mill around and untangle ourselves. (Aside - Speaking with Rob Day beforehand aspects seem to be similar to the concept of Domain Pollution in Shlaer-Mellor.) So, if anyone has a good way of explaining Aspect then please let me know.

I described work on three projects, one each from Aspect-Oriented Requirements Engineering, Aspect-Oriented Architecture Definition and Aspect-Oriented Design. These were Theme (http://www.dsg.cs.tcd.ie/index.php?category_id=363), ASAAM(http://trese.cs.utwente.nl/taosad/index.htm) and Feature C%2b%2b (http://wwwiti.cs.uni-magdeburg.de/iti_db/forschung/fop/featurec/) respectively. These all projects that are on-going and there are plans to apply them all industrially.

There were a number of comments and questions in the follow-up and some discussion on the desirability of using Aspect-Oriented techniques when programming and at other lifecycle stages. Only a couple of people in the room had used AOP and had had mixed experiences. One issue was how Aspects get composed with the artefacts they crosscut.

I had some backup questions arranged but in the end we didn't need these. I'd still be interested in people's opinions though so here they are:

If you have used aspect-oriented programming (AOP), would these sorts of tools help address some of the issues you've faced when using AOP?

For anyone not using AOP? Does the idea of Early Aspects resonate with you? Why? Why not?

Would Early Aspects be useful even if you don’t plan to use AOP?

Note to future 'Hot Topic' session wannabees - don't try and be too ambitious in the amount of material you cover. In particular, don't try and condense the work of hundreds of man-hours of research into 15 minutes. You will end up having a few sleepless nights as you do your best to present a good-quality SPA session.