A Framework for the Development of Multi-Level Reflective Applications Federico Valentino, Andrés Ramos, Claudia Marcos and Jane Pryor ISISTAN Research Institute Fac. de Ciencias Exactas, UNICEN Pje. Arroyo Seco, B7001BBO Tandil, Bs. As., Argentina Tel/Fax: +54-2293-440362/3 E-mail: {fvalenti,aramos,cmarcos,jpryor}@exa.unicen.edu.ar URL: http://www.exa.unicen.edu.ar/~isistan Abstract. Computational reflection has become a useful technique for developing applications that are able to observe and modify their behaviour. Reflection has evolved to the point where it is being used to address a variety of application domains. This paper presents a reflective architecture that has been developed as a framework that provides a flexible reflective mechanism for the development of a wide range of applications. This architecture supports many meta-levels, where each one may contain one or more planes. A plane groups components that deal with the same functionality, and so enhances the separation of concerns in the system. The reflective mechanism permits different types of reflection, and also incorporates the runtime handling of potential conflicts between competing system components. The design and implementation of this framework are described, and an example illustrates its characteristics. 1. Introduction Reflective architectures provide a degree of flexibility that allows designers to adapt and add functionality to software systems in a transparent fashion. Since its onset, computational reflection has been proposed and used for the solving of many different problem domains in software engineering: aspect-oriented programming [PDF99, PBC00], multi-agent systems [Zun00], concurrency programming [WY88, MMY93], distributed systems [Str93, OI94, OIT92], and others. A reflective system has the ability to reason about and act upon itself and adjust to changing conditions [Mae87]. Reflection is a technique that has gained applicability with the increasing use of object-oriented languages. In an object-oriented reflective architecture a system has more than one level: a base level consisting of the application itself, and a reflective level or meta-level that observes and introduces additional functionality that is dependent on the state of the program during execution. A reflective architecture therefore promotes the separation of concerns [Par72] by distinguishing and organizing the software components according to their functionality. However, the separation of concerns offered by most reflective architectures is limited to the base and meta levels. The meta or reflective level may contain metaobjects with very different functionality, such as synchronization, logging, exception handling, and so on. In consequence the benefits of an adequate separation of concerns – greater comprehension, reduced complexity, adaptability, customisability, reuse, etc. - is lost. Another limitation arises when more than one metaobject is associated to the same object, as problems of ordering, exclusion, and other conflicts may arise between them. This may be solved in a static way by following the order in which they are associated, but in some cases this will not be sufficient as their activation may depend on more complex issues. It is also important to support different reflective capabilities in order to offer greater flexibility to the developer. This would permit the design of systems where the types of reflection are applied in accordance to the functional requirements. Current reflective systems do not provide the means to adequately handle these issues. This paper describes a framework for the development of reflective systems that include flexible reflective mechanisms for the separation of concerns and for the solving of conflicts between competing metaobjects. The framework supports a multi-level architecture where groups of components that share the same basic functionality are grouped together in planes that observe and interact with each other, supporting the separation of concerns down to the code level in cases of crosscutting functionality. Different types and levels of conflicts between metaobjects have been studied and identified in this work. The framework supports the declaration and the handling of the above-mentioned categories of conflicts. The following section provides a brief description of computational reflection. Section 3 describes the concept of planes in a reflective architecture, and the next section consists of a description and categorisation of conflicts. The reflective architecture is covered in section 5, followed by an example of an application. The implementation is described in section 7, and the conclusions presented in section 8. 2. Computational Reflection Computational reflection permits a system to observe and modify the properties of its own behaviour, specially those properties that can be observed externally. Reflection is a solution to the problem of creating applications capable of maintaining, using or changing the representation of their own designs [Mae87, DS84, Coi88]. Reflective systems are therefore capable of extending, modifying or analysing their behaviour. In conventional systems, the data that is computed represents entities that are external to the computational system. On the other hand, in reflective systems, the computation is carried out on data that represents structural and computational aspects of the same system. In an object-oriented reflective architecture, the components that represent the application and those that represent the system itself reside on two different levels: the base level and the meta level (Figure 1). · The base level contains the objects that solve a problem and return information about the domain of the application or the external domain. · The meta level contains objects that carry out computation about the system that resides on the base level. The objects on the meta level are called metaobjects. metaobjects Meta Level Association between base level and meta-level. Base Level Objects at the Communication base level between objects Fig. 1. Reflective architecture. This two level hierarchy can be generalised to include many meta-levels, becoming an N-level architecture. In this type of architecture, each level carries out different computation on the previous level. As the functionality of the meta-level is orthogonal to the base level - i.e. it crosscuts the basic functionality of the system - an association between the base and the meta-level is defined in order to determine the points at which these levels interact with each other. This association is established between the corresponding metaobject of the meta-level and one or more elements (classes, methods and/or objects) at the base level. At runtime, when an object at the base level receives a message, the reflection mechanism redirects the control to the associated metaobject. Four different reflective strategies which make up a reflection taxonomy have been identified: class reflection, method reflection, object reflection, and method- object reflection [Mar01]: - Class reflection is that which is used when all instances of a class interact with an orthogonal functionality. - When only one method or set of methods of the class needs to incorporate this functionality, method reflection is used. - In some cases it is necessary to analyse a particular object of a class, where only this object is associated to a metaobject of the meta-level: object reflection is then used. - It is also possible to combine method and object reflection when reflective behaviour is added to a particular method of a specific object. This is known as method-object reflection. Another important characteristic in a reflective system is that which permits the designer to determine when and how the meta-level is invoked: before the base object, after the base object, and omitting the invocation of the method of the base object. The framework described in this work supports the different types of reflection specified in the taxonomy. It also permits invocation of the meta-level before and/or after the base method, with or without the invocation of the base method. 3. Planes in a Reflective Architecture The architecture of a reflective application varies according to the reflection requirements that are to be considered. In some cases it may be convenient for the architecture to have various levels, where each level observes and interacts with the others. Additionally, as there may be multiple functions at each level, the concept of planes is introduced in order to obtain a clearer separation of concerns. A plane is a set of metaobjects which carry out a specific functionality, as for example logging or synchronisation of the system. Planes will ease the handling of these groups of metaobjects, their re-use, their interaction with the rest of the system, their maintainability, and so on. The concept of plane is not to be confused with the concept of level or hierarchy of levels. A level is a more abstract entity which may contain one or more planes which observe other planes at inferior levels; this would be the case in a hierarchical structure. blo BaseLevelObserver dbo META LEVEL 2 so DBObserver StatisticObserver LOGGING PLANE dbr META LEVEL 1 DBReader pStore stud collect ProfessorStore StudentObserver DataCollector sStore STORAGE PLANE STATISTIC PLANE StudentStore BASE LEVEL Metaobject Nicholas Anderson Advisor Mitchel Message Student Metaobject association Professor Peter Collins Invocation John BASE PLANE Fig. 2. Reflective