Domain Speci c Languages (DSLs) are programming languages customized for a problem/solution domain, which allow development of software modules in high-level speci cations. Code generation is a common practice for making DSL programs executable: A DSL speci cation is transformed to a functionally equivalent GPL (general-purpose programing language) representation. Integrating the module generated from a DSL speci cation to a base system poses a challenge, especially in a case where the DSL and the base system are developed independently. In this paper we describe the problem of integrating domainspeci c modules to a system non-intrusively and promote loose coupling between these to allow software evolution. We present our on-going work on aspect-oriented language mechanisms for de ning object selectors and object adapters as a solution to this problem.
Complex systems are created by assembling software components of various types and functions. Reuse is essential and components created for a system are required to continue working after the system has evolved. Some components may be domain-speci c, meaning their structure and functionality can be de ned using the fundamental concepts of the relevant domains. A domain-speci c language (DSL) provides expressive power over a particular domain. It allows software development with high-level speci cations; if general-purpose programming languages are used, development may take a considerable programming e ort.
The speci cations written in a DSL can be processed in various ways. These
are comprehensively described in [
In this paper we focus on the integration of components into target systems. \Component" is a very general concept and it can be realized in di erent forms, depending on the system. We particularly focus on a subset of components, domain-speci c components, which are instances of domain-speci c meta-models. The component structure is described with a DSL and the semantics are embedded into code generation templates, which are used to generate a component that is tailored towards a base system's requirements.
Integrating a generated component into a system poses three main challenges. (1) When adding unforeseen functionality to a system, no explicit hooks exist for attaching the generated component. In this case it may be necessary to modify the generated code, the system code or both to make the connection, which will expose the system developer to the implementation details of the generated code. (2) The interfaces of the generated component and the target system should be compatible to work together, which is generally not the case. Then one of the interfaces should be adapted, possibly by modifying the system's or the component's implementation or their type-system. (3) When the component or the target system evolves, the links between them must be re-established.
Current aspect-oriented languages o er mechanisms to modularly implement solutions for the rst challenge. It can be solved by de ning pointcuts that are used as hooks to a system. The second challenge is our main focus. Existing AO-languages o er limited mechanisms for implementing adapters between interfaces. AspectJ inter-type declarations can be used to make system classes to implement appropriate interfaces, however this approach is type-invasive. CaesarJ o ers a more declarative approach with wrappers, but their instantiation requires pointcut declarations or they should be explicitly instantiated in the base system. The links mentioned in the third challenge are the adapter implementations mentioned in the second challenge and they represent the binding between two components. However current AO languages do not o er a declarative way for describing such a binding; an imperative programming language will lead to less readable and less maintainable implementation, which is fragile against software evolution. 2
In order to overcome the shortcomings of the existing approaches we intend to design a declarative way of implementing object adapters which is used together with a specialized pointcut for selecting objects. The object adapter pattern is common practice for binding two components that have incompatible interfaces. Our approach is aspect-oriented and it will provide the means to non-intrusively de ne and instantiate object adapters, inside aspects. These adapters represent links between the component and the system; their declarative design requires a declarative way of selecting the adaptee objects.
In order to select objects to be adapted, we have designed a new pointcut mechanism called instance pointcut which selects sets of objects based on the execution history. An instance pointcut de nition consists of three parts: an identi er, a type which is the upper bound for all objects in the selected set, and a speci cation of relevant objects. The speci cation utilizes pointcut expressions to select events that de ne the begin and end of life-cycle phases and to expose the object. At these events, an object is added or removed from the set representing the instance pointcut. It is possible to access all objects currently selected by an instance pointcut and to be noti ed, when an object is added or removed. New instance pointcuts can be derived from existing ones in several ways. Firstly, a new instance pointcut can be derived from another one by restricting the type of selected objects. Secondly, a subset or a super-set of an existing instance pointcut can be declared whereby the speci cation of the life-cycle phase is either narrowed down or broadened. Finally, instance pointcut declarations can be composed arbitrarily by means of boolean operators.
Adapter declarations refer to the sets selected by instance pointcuts, and automatically instantiate adapters for each object in the referred set. Unlike intertype declarations, adapter declarations are not type invasive; they are compiled to the object adapter pattern and they do not change the type hierarchy of the contained object. They also do not require explicit instantiations. (a) The shapes hierarchy (b) ShapeInfo class that requires two unsupported interfaces
The header of an adapter declaration consists of an identi er, the list of interfaces the adapter implements and an instance pointcut reference which contains the adaptee objects. In the body of an adapter declaration implementation of the interface methods is provided. In Figure 1a a Shape hierarchy and the interfaces o ered by the classes in this hierarchy is shown. The ShapeInfo class uses ShapeArea and ShapeCircumference interfaces to query existing Shapes (Figure 1b). However none of the classes in the shapes hierarchy implements these interfaces, hence they should be adapted. Assume that there is a class called CircleCreator which has two methods: createLargeCircle and createSmallCircle. We can de ne an instance pointcut called largeCircles which selects the set of Circle objects that are created by the createLargeCircle method. Here instance pointcuts give us expressive power over selecting speci c objects as adaptees. Listing 1 shows an example of an adapter declaration. The name of the adapter is CircleAdapter and it implements the interfaces de ned in the square brackets; CircleAdapter adapts the objects selected by the circles instance pointcut. In the body of the adapter the implementations of the two declared interfaces are provided. The adaptee keyword refers to an object in the circles set. f r e t u r n 2* adaptee . g e t R a d i u s ( ) *Math . PI ; r e t u r n Math . pow ( adaptee . g e t R a d i u s ( ) , 2 ) *Math . PI ;
Listing 1: The adapter declaration for Circle objects
In our prototype implementation instance pointcuts are compiled to AspectJ and Java code. Roughly, an instance pointcut is transformed to several AspectJ pointcuts, advice declarations, a set structure and methods for altering this set. Adapter declarations will also be compiled to AspectJ. According to our initial analysis an adapter declaration will map to a Java class for the adapter and advice bodies for initializing adapters. These advice bodies will reference the pointcuts generated from the instance pointcut which is referenced by the adapter declaration.
We intend to provide run-time support for retrieving adapter instances. Adapters are automatically initialized when an adaptee object satisfying the referenced instance pointcut's conditions become available. These adapter instances can be indexed and accessed through a run-time library. To do this, we have the requirement that the results of a retrieval will always be non-ambiguous e.g. if a query to retrieve a single adapter instance, matches two adapters, then there should be appropriate resolution mechanisms or user feedback to overcome the issue.