Early Aspects Blog

Recently I have had some discussions where people queried me about requirements-level aspect composition. One person went as far as suggesting that aspect composition at this level is simplistic and trivial compared to doing so in programming languages. I agree that aspect composition, especially if one is using something like a high-level join point model (e.g., a state-based join point model that we are working on [1]) is a non-trivial task. Dynamic aspect composition brings its own challenges. However, this does not imply that requirements-level aspect composition is a trival task. The problem, no doubt, is somewhat different but is, at least, equally challenging if not harder. The main issue is that at the programming level one has at least a clearly defined structured model of the system (even if some polymorphic elements are unknown due to being determined at runtime). The same is not true for requirements. Requirements tend to be pieces of text which are often difficult to interpret. Furthermore, they do not have a strong structure and their sources may often be ambiguous or the information from which they are derived may be incomplete. This makes the specification of composition rules (or pointcuts if you prefer) all the more difficult. Furthermore, the actual composition is a non-trivial task as there is no strong, formally defined structure in most instances. The semantics need to be infered from the requirements text and one cannot rely on program semantics as in the case of programming languages. There have been positive results from using XML to provide semi-structured representations of requirements as well as composition rules [2][3][4]. This makes it possible to do automated processing of the specification and identify trade-off points. But these works have also shown the requirements composition is a non-trivial task especially in a multi-dimensional model.

[1] N. Mohd Ali, A. Rashid (2005) A State-based Join Point Model for AOP. Workshop on Views, Aspects and Roles at ECOOP 2005 (http://swt.cs.tu-berlin.de/~stephan/VAR05/accepted.html)
[2] A. Moreira, A. Rashid, J. Araujo (2005) Multi-dimensional Separation of Concerns in Requirements Engineering. International Conference on Requirements Engineering, Paris, France, 20 August-2 September (To Appear). IEEE Computer Society.
[3] A. Moreira, J. Araujo, A. Rashid (2005) A Concern-Oriented Requirements Engineering Model. International Conference on Advanced Information Systems Engineering, Porto, Portugal, June 13-17. Editor(s): O. Pastor, J. Falcão e Cunha, Springer-Verlag. Volume 3520, Pages 293-308.
[4] 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. (Available from: http://www.comp.lancs.ac.uk/computing/aose/EarlyAspects.php)

I was at ECOOP a couple of weeks back and ended up in an interesting workshop discussion. Someone gave the following example: We need to implement Security. We then decide to do so via role-based access control. So we need to implement this in an aspect. I won't go into the discussion that ensued but rather comment on some of the misconceptions about aspects at requirements-level. The first question the above statement raises is: How do we know that we need Security in our system? . The second question is: How did we realise that we need to do so using role-based access control? Of course, we can do so only by effective requirements engineering. Aspect-oriented requirements engineering would be helpful as it would support us to analyse the broadly scoped influence of our Security requirements on other requirements for our system. Analysis of our Security aspect requirements and their trade-offs with other requirements-level aspects would give us early insights into our architectural and design choices, hence leading us to the role-based access control. They key for me here is that aspects do not materialise out of the blue at implementation level. Aspects need to be discovered during requirements engineering, they need to be analysed and as we move to architecture, design and implementation (or in the case of agile approaches directly to test cases and implementation) these requirements-level aspects might get refined into more fine-grained aspects or could even be best implemented as objects (if they are not crosscutting in design and implementation).

One of the exciting developments that have happened our the past year is the launch of AOSD-Europe: European Network of Excellence on Aspect-Oriented Software Development. The network aims to integrate the work of nine academic sites and two industrial organisations with a view to undertaking large scale research on AOSD. As part of the network's activities, a detailed survey of aspect-oriented and non-aspect-oriented approaches handling crosscutting concerns in requirements, architecture and design has been conducted. The survey also provides initial insights into a methodology for aspect-oriented analysis and design. The survey is available publicly from AOSD-Europe Web site and is a good resource for those new to early aspects as well as those who are already working in the field.

The Early Aspects portal has had a makeover. One of the great things about the new site is an extensive bibliography (and in many cases links to online versions) of papers on Early Aspects topics. If you haven't already looked at the site, please do check it out at:

http://www.early-aspects.net

The plan is to keep the Web site and bibliography up to date. So if you spot any missing papers please email the site admin address (which will eventually bounce forward to my mailbox :) ).

Quite a few people, mainly postgraduate students, have been querying me about good starting points for reading on early aspects. So I thought it might be a good idea to post something here. A more complete early aspects bibliography will be available from www.early-aspects.net shortly. If you are just starting to look into the topic, then the following will be good starting points.

For aspect-oriented requirements engineering:

• Awais Rashid, Ana M. D. Moreira, João Araújo: Modularisation and composition of aspectual requirements. AOSD 2003: 11-20. Available from: http://www.comp.lancs.ac.uk/computing/aose/papers/AORE-AOSD2003.pdf
• Elisa L. A. Baniassad, Siobhán Clarke: Theme: An Approach for Aspect-Oriented Analysis and Design. ICSE 2004: 158-167. Available from: http://www.cs.tcd.ie/Elisa.Baniassad/theme.pdf
• Stanley M. Sutton Jr., Isabelle Rouvellou: Modeling of software concerns in Cosmos. AOSD 2002: 127-133.

For aspect-oriented architecture design:

• Bedir Tekinerdogan: ASAAM: Aspectual Software Architecture Analysis Method. WICSA 2004: 5-14.

Also, it might be good to have a look at the following papers.

• John C. Grundy: Aspect-Oriented Requirements Engineering for Component-Based Software Systems. RE 1999: 84-91. (Note: This was the first paper to mention the term "aspect-oriented requirements engineering"). Available from: http://www.cs.auckland.ac.nz/~john-g/papers/re99.ps.gz
• Awais Rashid, Peter Sawyer, Ana M. D. Moreira, João Araújo: Early Aspects: A Model for Aspect-Oriented Requirements Engineerin. RE 2002: 199-202. (Note: This was the first paper to mention the term "early aspects"). Available from: http://www.comp.lancs.ac.uk/computing/aose/papers/AORE_RE2002.pdf

Furthermore, the early aspects landscape report being developed jointly by the organisers of the workshop series (Joao Araujo, Elisa Baniassad, Paul Clements, Ana Moreira, Awais Rashid, Bedir Tekinerdogan) is also a good source. It is aimed to be a living and evolving document contributed to/commented on by the community (people who contribute substantially can be added as co-authors). The initial draft of the report was circulated at the Early Aspects Workshop at AOSD 2005 for comments from the wider community. It is available from: http://trese.cs.utwente.nl/early-aspects-AOSD2005/Papers/EarlyAspects-LandscapePaper-FirstDraft-2005.pdf.

Of course, the Early Aspects series of workshops as well as papers in other venues are useful resources for further reading. These are listed on www.early-aspects.net.

Over recent weeks, during project meetings as well as the Early Aspects workshop at AOSD, the notion of an architectural aspect has been discussed. Many people often ask the question: what does an aspect look like at the architecture level? Some feel that aspects should serve as first class modelling elements at the architecture level. This is, of course, valuable as one can clearly observe the aspects crosscutting one's architectural elements. However, what other purpose does an architectural aspect serve beyond this visual representation of a crosscutting influence?

I find it appealing to think of aspects manifesting themselves in the architecture in a variety of ways. Of course, they can appear as entities that are clearly modelled in a visual representation. However, at the same time, they can be more implicit, for instance, in the form of influencing certain architectural choices or design decisions. If there is an Availability aspect at the requirements level, then it is not likely to directly appear at the architecture or subsequent stages in its own right. It might be refined or drive the identification of new aspects as we look to realise our availability requirements. However, at the same time, it is likely to play a signficant role in our choice of an architecture [1]. Dealing with the crosscutting influences of such, more implicit, aspects is a significant challenge. It would be very interesting to see how aspect-oriented software architecture approaches address this challenge.

[1] Awais Rashid, Ana M. D. Moreira, João Araújo: Modularisation and composition of aspectual requirements. Proceedings of AOSD 2003: 11-20.

There is a very interesting discussion thread at present on the aosd-dicuss list. A number of people, including Pascal Costanza and myself, have been debating whether an AOP language can be classed as a meta-programming language. The supporters of the idea feel that it makes sense as AOP languages, after all, manipulate object graphs in base OO programs. However, some (including myself) find this a very restrictive view of AOP and AOSD in general. In my opinion, AOSD is first and foremost about systematic separation of crosscutting concerns. You could use meta-programming as a means of implementing AOP but classing AOP as a meta-programming technique takes away this strong emphasis on systematic treatment of crosscutting concerns.

Moreover, aspect-orientation is not just about programming. The term AOSD covers techniques that treat crosscutting concerns throughout the software life cycle. I find that the notion of AOSD as a meta language does not necessarily make sense in terms of early aspects. At this level, do I really care about meta languages? I don't think so. They might come in handy but
that is not my first and foremost concern. For instance, at the requirements level, one key use of aspects (there are others) is to develop a better understanding of the problem domain. One would like to understand how aspectual requirements constrain or influence other requirements in the system. Composition in such an instance is concerned with taking projections
of concern influences over other concerns and you don't necessarily need a meta language to do that.

We (Myself, Ana Moreira and Joao Araujo) proposed a composition language for aspect-oriented requirements engineering in [1] and another one for multi-dimensional separation of concerns in requirements engineering in the upcoming paper at CAiSE 2005 [2]. The aim is not to provide meta languages that manipulate requirements representations. Instead we want to specify composition relationships and semantics of aspectual requirements to understand and analyse their semantic influences.

[1] Awais Rashid, Ana M. D. Moreira, João Araújo: Modularisation and composition of aspectual requirements. Proceedings of AOSD 2003: 11-20.
[2] Ana M. D. Moreira, João Araújo, Awais Rashid: A Concern-Oriented Requirements Engineering Model. To Appear in CAiSE 2005.

So I suppose the first question is why have an early aspects blog and why now? Aspect-oriented software development (AOSD) is growing in popularity (if you are new to AOSD then the quick link on the side is a good place to start looking for more information). However, a significant body of work has mainly concentrated on developing suitable programming abstractions and composition mechanisms for the purpose. There is also work on (mainly UML) modelling of aspect-oriented design elements.

A subset of researchers in this community are, however, focusing on addressing crosscutting concerns from very early on in the software life cycle, i.e., during requirements engineering and architecture design. A better understanding of crosscutting concerns at the requirements level ensures that one has a clearer understanding of the problem domain especially the impact and influence, as well as trade-offs, of crosscutting concerns on other system requirements. Explicitly catering for crosscutting concerns at the architecture level ensures that such influences and trade-offs are effectively reflected in the solution domain from very early on.

Early aspects researchers have regularly met since the first AOSD conference in 2002 when the first workshop on the topic was organised. Since then each of the AOSD conferences has had a workshop on the topic. There was also a workshop at the OOPSLA conference last year. The early-aspects.net site is a portal (due to undergo a serious overhaul shortly) for useful information on the topic. A first draft of a landscape report edited by the organisers of the Early Aspects series of workshops was also circulated at the workshop at AOSD 2005 last week. It was, in fact, at the workshop that I thought about starting a blog on the topic. A number of publications on the topic (especially aspect-oriented requirements engineering) are available including a number involving myself (mainly joint work conducted with Ana Moreira and Joao Araujo at Universidade Nova de Lisboa). However, a number of questions are often raised which do not readily find answers in the published work. These often pertain to the effectiveness of early aspects, composition models at this level and so on. Moreover, like the early days of AOP, the question: "What is an Early Aspect" is also raised frequently. In this blog, I intend to provide my perspective on these questions and other topics relating to early aspects with a view to engaging other researchers in a constructive debate.