next up previous
Next: Computational Reflection Up: The Reflective Architecture of Previous: The Reflective Architecture of

Introduction

As the size and complexity of systems increase, so does the need for mechanisms to deal with such complexity. Object-oriented design is based on abstraction and information hiding (encapsulation) [4,13,30,31]. These concepts have provided an effective framework for the management of complexity of applications. Within this framework, software developers strive to obtain applications that are highly coherent and loosely coupled. High coherence translates into narrow and easy-to-understand interfaces, as highly coherent components tend to do just one thing, leading to functional simplicity and component autonomy. Loosely coupled components are components that are connected by simple communication structures, thus their relationships are easy to understand and less prone to domino effects caused when errors occur at one location and propagate through the application. Unfortunately, object-oriented design alone does not address the development of software that can be easily adapted. Adaptability and transparency of coupling is playing an increasingly important role in the software development process, that is now carried out in a much more dynamic market where requirement shifts force developers to adapt already existent software to originally unforeseen conditions (requirements). The next two paragraphs review solutions that have been proposed to these two problems, respectively. After presenting these solutions, we argue that our reflective software architecture, Guaranį, represents a step forward towards the construction of open, easily adaptable applications.

The concept of open architectures [14,15] has been proposed as a partial solution to the problem of creating software that is not only modular, well-structured, but also easier to adapt. Open architectures are based on the existence of an additional component (object) interface that allows them--acting as servers--to dynamically adapt to new requirements presented by their clients. Open architectures encourage a modular design where there is a clear separation of policy, that is, what a module has been designed for, from the mechanisms that implement a policy, that is, how a policy is materialized. Although open architectures might seem to confront the modular design approach by exposing parts of their designs, in fact, the opposite is valid. Open architectures may provide elegant solutions to the design and implementation of highly adaptable software. In particular, the implementation of system-oriented mechanisms such as concurrency control, distribution, persistence and fault-tolerance can benefit from this approach to software construction.

Computational reflection [21,33] (henceforth just reflection) has been proposed as a solution to the problem of creating applications that are able to maintain, use and change representations of their own designs (structural or behavioral). Reflective systems are able to use self-representations to extend and adapt their computation. Due to this property, they are being used to implement open software architectures. Additionally, the mechanisms used to implement reflective systems can also be used to partially solve the problem of coupling software components transparently. In reflective architectures, components that deal with the processing of self-representation and management of an application reside in a software layer called meta-layer or meta-level. Components that deal with the functionality of the application are assigned to a software layer called base-layer or base-level. The transparent coupling of the base-level to its meta-level is implemented using interception mechanisms. In object-oriented reflective systems, objects that reside in the meta-level and base-level are called meta-level objects and base-level objects, respectively.

A comparative study of existent object-oriented reflective architectures reveal that some associate every base-level object with a single meta-level object called meta-object [21,39]. Several offer class-wide reflective facilities: each class is associated with a single meta-class [7,8,11,16]. Some allow groups of objects to be attached to groups of meta-objects [12,23,24,25,41], by giving every meta-object the responsibility for handling a specific aspect of the system-object interaction. Also, hybrid models [22] exist.

Due to their inherent structure, the existing reflective architectures may induce developers to create complex meta-objects that, in an all-in-one approach, implement many policies (management aspects) of an application or, alternatively, to construct coherent but tightly coupled meta-objects and objects. Both alternatives harden reuse, maintenance, and adaptation of an application, especially of its meta-level, as it is where most of the adaptations tend to occur in an open architecture. There is certainly room for improvement of the mechanisms that give support to adaptation and transparent loose coupling.

This paper describes the reflective architecture of Guaranį, a flexible language-independent meta-protocol that encourages the creation of highly coherent, loosely and transparently coupled meta-level objects. An application developed within Guaranį's framework is easily adapted to conform to new requirements, and the implementation of meta-level requirements can be easily reused in other applications. Section 2 contains an introduction to computational reflection, as used to support open architectures. Section 3 describes the software architecture and meta-level protocol of Guaranį. Finally, in Section 4, we present some conclusions and discuss future work.

Along the text, we are going use diagrams to illustrate the main characteristics of Guaranį. The graphical conventions used in these diagrams are those of UML (Unified Modeling Language) sequential diagrams [30]. Figure 1 specifies the semantics of such diagrams.


  
Figure 1: UML Sequence Diagrams
\begin{figure*}
\begin{center}
\par\setlength{\unitlength}{0.00083333in}
\be...
... the object; the latter initializes (constructs) it.
\end{quote}
\end{figure*}


next up previous
Next: Computational Reflection Up: The Reflective Architecture of Previous: The Reflective Architecture of
contact the authors