K. Mehner, A. Wagner

Aspect Oriented Programming
The development of a software system comprises amongst others the design and implementation of the basic functionality and of other system aspects such as synchronisation, distribution, error handling, memory optimisation and security management. While functional and object oriented decomposition are well suited for the design and implementation of the basic functionality, these techniques cannot cope well with the other aspects. When using these techniques, the aspects are spread over the system and tangled with the code for the basic functionality. They don't modularise well together with the decomposition of the basic functionality of a system and also cannot be modularised on their own with functional or object oriented decomposition techniques, i.e. separation of concern is not well supported for such aspects. Clearly, this situation has a negative impact on the quality of a software system.

Aspect oriented programming (AOP) aims at supporting the separation of concern for the above mentioned aspects. AOP is a continuous development of the object oriented paradigm, and as such it supports aspect oriented decomposition in addition to object oriented decomposition and functional decomposition. See [1,4] for an overview on AOP.

Requirements for Aspect Languages
The new paradigm of AOP is supported by so called aspect languages. The requirements for these languages follows from the aim of AOP: Aspect languages must support the separation of concern for aspects like synchronisation, distribution, error handling, memory optimisation and security management. This is achieved by providing means for the modularisation of system aspects which cross-cut the decomposition according to the basic functionality. Therefore, they provide new kinds of programming units called aspects, and language features to specify the aspect code contained in these units.

Aspect languages need to work together with a language for the basic functionality called the base language. Base languages are general purpose languages such as C++ or Java. In general one could imagine also non-imperative languages. The relation between aspects and modules of the base languages is not the same as between the modules of the base languages, whose exports and imports are based on type declarations and calls to methods or functions. Between aspects and the modules of the base language there is a special kind of interface which consists of join points. Join points are places in the base code which can be augmented by additional behaviour, which is specified in an aspect.

The State of the Art in Aspect Language Design
In the following we discuss different existing approaches for aspect languages. We especially focus on the question how they fulfil the above requirements.

Domain Specific vs. General Purpose Aspect Languages
So far, we can distinguish two different approaches to aspect language design: domain specific aspect languages and general purpose aspect languages. By domain specific we refer to the different system aspects like the ones identified in the introduction. Domain specific aspect languages support one or more of these system aspects, but cannot support aspects other than they were designed for. Domain specific aspect languages are usually more abstract than the base language and they express the domain specific concepts in a higher level representation. Usually, they impose restrictions on the use of the base language. This is to guarantee that domain concepts are programmed using the aspect language and to avoid interference, i.e. that domain aspects are programmed in both languages which can lead to a conflict. An example for a domain specific aspect language is COOL from Xerox [2], a language for the synchronisation of concurrent threads. The base language is a restricted version of Java. The synchronisation of threads is specified in a declarative manor and thus more abstract than the corresponding encoding in Java. However, the aspect of synchronisation is not fully supported by COOL.

General purpose aspect languages are designed to be used for every kind of aspect, not only for specific aspects. Therefore, they cannot impose restrictions on the base language. They mainly support the separate definition of aspects by providing aspect units. They usually have the same level of abstraction as the base language and also the same set of instructions, as it must be possible to express arbitrary code in the aspect units. An example is AspectJ [3]. It uses Java as a base, and the instructions in the aspects are also written in Java.

If we contrast these two approaches, it turns out, that general purpose aspect languages cannot completely fulfil the requirements. They have one severe drawback: They allow to separate code, but they cannot guarantee separation of concern, i.e. that only the aspect unit is used to programme the aspect. However, this is the central idea of AOP. In comparison to general purpose aspect languages, domain specific aspect languages force separation of concern.

The problem with existing base languages
For the design of aspect languages there are two alternatives concerning the base language. Either one can design a new base language together with the aspect language or one can take an existing language as a base which is possible, as the base needs to be a general purpose language. The latter has the advantage, that one has less work in designing and implementing languages for aspect oriented environments, and can use experienced languages, and secondly, that the programmer only has to learn the aspect languages but not a new language for the basic functionality, which still makes up the bigger part of aspect oriented programs.

So far, both, domain specific and general purpose aspect languages have been designed to be used with existing base languages. For instance, COOL and AspectJ  both use Java as a base. However, apart from the advantages such a decision raises some problems.

In the case of domain specific languages we encounter special impacts from the fact, that the base language is given. Concerning the interface between the aspect language and the base language one has to take into account, that the join points can only be those, which can be identified in the base language. One is not completely free to design the join points.

Secondly, if we require separation of concern, remember that the base language must be restricted after the aspects have been separated. This the most difficult part, as we have to take away elements from a complex system, i.e. the base language, where everything has its place and its responsibilities in coordination with others. While the design of a programming language is already a difficult and complex task, it is even more difficult when making changes to a language, which was not designed for such an evolution. For example, restrictions must not be too strong as it is the case with COOL.

General purpose aspect languages are less difficult to implement on top of an existing programming language, as they don't require the restriction of the base. Apart from this, the situation is the same as with domain specific languages, i.e. in the design of the join points one is limited to those, which can be identified in the base language.

Conclusion and Future Research
From the discussion we can conclude that domain specific aspect languages play a crucial role for AOP and that they are preferable to general purpose aspect languages, because they better support separation of concern. But there is still not enough experience with domain specific aspect languages. So far, there have been several prototypes of aspect oriented programming environments. If we examine the domain specific environments among them, we have to observe that none of them supports separation of concern to a sufficient extent. Either the language supports the aspect domain only partly or the restriction of the base is not well supported. It seems that the complete separation of concern has been out of sight when the first aspect languages were developed.

Our position is, that AOP can only succeed if enough attention is paid to separation of concern. We think, that the situation must be exploited, that domain specific aspect languages can guarantee separation of concern. We want to study, whether domain specific languages can meet their aims. However, there are still open questions. Especially it is not clear, if one can achieve separation of concern when using an existing base language. Therefore, we want to study for an example domain (the domain of synchronisation of concurrent threads) if this can be achieved. If we cannot succeed, the question is, if the problems will arise with any general purpose base language, or if we can construct new base languages which allow better separation of concern for certain aspects. The strategy could also be to restrict the problem to a certain application domain, i.e. one could try to achieve separation of concern for the use of a domain specific aspect language in a special application domain.

References

[1]
 G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. Loingtier, J. Irwin, Aspect-Oriented Programming, 
proceedings of the European Conference on Object-Oriented Programming (ECOOP), Finland. Springer-Verlag LNCS 1241.  June 1997.
 
[2]
C. Lopes, G. Kiczales, D: A Language Framework for Distributed Programming,
Technical report SPL97-010, P9710047 Xerox Palo Alto Research Center. February 1997.

[3]
C. Lopes, G. Kiczales, Aspect oriented programming with AspectJ,
Tutorial Paper, STJA'98, September 1998

[4]
Proceedings of the Workshop on Aspect Oriented Programming, ECOOP'99, June 1999.