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).