Advisor(s): Bruno De Fraine, Wim Vanderperren.
Promotor: Viviane Jonckers
Aspect-Oriented Software Development (AOSD) [1,2] is a recent software programming paradigm that aims at providing a better separation of concerns. At its root is the observation that some concerns will inherently crosscut traditional abstraction mechanisms such as classes or components. AOP languages such as AspectJ [3] allows to cleanly modularize these so-called crosscutting concerns by implementing them as aspects.
The Gang-of-Four (GoF) design patterns [4] offer flexible solutions to common software development problems. The original Design Patterns book presents elements of reusable software in object-oriented languages; it can be noted that the structure of the proposed solutions often involves crosscutting of some sort. It is therefore beneficial to attempt aspect-oriented solutions for the pattern problems. Concrete implementations of the GoF design patterns in AspectJ [5] offer improvements in modularity properties such as locality, reusability, composability and pluggability.
However, despite the relative success, design patterns are not textbook applications of current aspect-oriented technology either. The existing design pattern implementations have been criticized in literature as awkward and suboptimal [6,7]. We believe this observation stems (at least partially) from the fact that current aspect-oriented languages restrict the flexibility of aspect deployment and instantiation. This is particularly problematic in the context of this application since design patterns emphasis flexible design (besides reuse).
As an illustration, consider this explanation of the purpose of design patterns from [4]: “Design Patterns help you identify less-obvious abstractions and the objects that can capture them. For example, objects that represent a process or algorithm don't occur in nature, yet they are a crucial part of flexible designs. The Strategy pattern describes how to implement interchangeable families of algorithms. The State pattern represents each state of an entity as an object. These objects are seldom found during analysis or even the early stages of design; they're discovered later in the course of making a design more flexible and reusable.” Making designs more flexible is thus part of the primary goals of a large number of the proposed design patterns. Yet aspect-oriented technologies do not provide means for sufficiently flexible aspect usage. Aspect-oriented implementations of design patterns can hence not achieve their full potential.
The Eco and EcoSys research [8] aims at improving the means for aspect deployment in current AOP technologies. In this work, we contribute to both the expressiveness of deployment logic (and allows e.g. to describe more flexible aspect instantiation strategies) as well as to the status of its specification (e.g. deployment logic can be abstracted and reused). These benefits are achieved on a conceptual level through the Eco-model, which outlines the proposed concepts for AOP with better support for deployment logic. Examples of these concepts are logically pure entities, unrestricted dynamic entity creation and possible integration of deployment logic with the base application upon which the aspect are applied. The concepts of this model are concretely brought about in EcoSys, an AOP framework for the Java platform. EcoSys presents the concrete interfaces and types which we propose for aspect-oriented programming with support for expressive and first-class deployment logic.
The objective of the thesis would be to validate (or contradict) that aspect-oriented implementations of design patterns indeed benefit from better means for aspect deployment. To this end, a number of implementations of design patterns will be conducted using the EcoSys framework. This thesis fits well with prior experience at the SSEL lab regarding aspect-oriented implementations of design patterns: previous endeavours include AO versions of the GoF design patterns in JAsCo [9] and FuseJ [10].
From the EcoSys implementations of these design patterns, it will be possible to analyse exactly what kind of flexibility certain patterns require, and how it can be supported. These results can possibly be generalized towards new proposals for Eco and EcoSys, or other aspect-oriented technologies.
System and Software Engineering Lab, Vrije Universiteit Brussel, Brussels, Belgium.
[1] Kiczales, G., Lamping, J., Lopes, C.V., Maeda, C., Mendhekar, A. and Murphy, A. Aspect-Oriented Programming. In proceedings of the 19th International Conference on Software Engineering (ICSE), Boston, USA. ACM Press. May 1997.
[2] AOP/AOSD website : http://www.aosd.net
[3] AspectJ website: http://www.eclipse.org/aspectj
[4] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Addison-Wesley, 1995.
[5] Jan Hannemann and Gregor Kiczales. Design pattern implementation in Java and AspectJ. In Proceedings of the 17th ACM conference on Object-oriented programming, systems, languages, and applications, pages 161-173. ACM Press, 2002.
[6] Klaus Ostermann and Mira Mezini. Conquering aspects with Caesar. In Proc. 2nd Int' Conf. on Aspect-Oriented Software Development (AOSD-2003), pages 90-99. ACM Press, March 2003.
[7] Kouhei Sakurai, Hidehiko Masuhara, Naoyasu Ubayashi, Saeko Matsuura, and Seiichi Komiya. Association aspects. In Proc. 3rd Int' Conf. on Aspect-Oriented Software Development (AOSD-2004), pages 16-25. ACM Press, March 2004.
[8] De Fraine, B., Vanderperren, W. and Suvee, D. Eco: A Flexible, Open and Type-Safe Framework for Aspect-Oriented Programming. Technical Report SSEL 01/2006/a. download paper
[9] JAsCo website. http://ssel.vub.ac.be/jasco/
[10] FuseJ website. http://ssel.vub.ac.be/fusej/