Scorpio : Software COmponent stRuctural adaPtatIOn
KeyWords : Software component, structural adaptation, static adaptation, software reuse, runtime adaptation, self-adaptation, restructuration, distribution, refactoring, composite-component, object-oriented.
Mots clefs : Composant logiciel, adaptation, adaptation statique, réutilisation, adaptation dynamique, auto-adaptation, restructuration, distribution, refactoring, composant-composite, orienté objet.
Definition and motivations
Structural adaptation of software components
The structural adaptation of a software component consists in the capacity to modify the structure of this one while preserving its behaviour and its services. In fact, the structural adaptation is interested in modifying neither the behaviour of the component nor its services, but rather to reorganize its structure. Indeed, the structure of the component which has to be adapted consists of the list of the structural elements, defined in this component, as well as their links. For example, a component can be seen as collections of ports, interfaces, sub-components, classes, etc. Thus, the structural adaptation can consist of updating the list of a component interfaces by modifying the content of each of these interfaces or restructuring the content of the component ports (i.e. external adaptation). Also, the structural adaptation can consist in the decomposition of a software component in some sub-components where the set of provided services must be the same as the one provided by the initial component before its adaptation (i.e. internal adaptation).
Motivations: structural adaptation applications
Adapting the structure of a software component can be useful in many cases. For example, external structural adaptation can be used in order to increase component reuse and internal structural adaptation for a flexible component deployment.
First, component restructuring can be used in order to match heterogeneous component external structures (Fig. 1 Case A). In fact, the assembly of two components or the integration of a component into an existing application needs to restructure their provided and required interfaces (or/and ports) if it proposes all required services but when these ones are not structured in interfaces permitting to match them. For example, figure 1 Case A shows that the C1 and C2 components cannot be assembled because C1 required ports do not match with those provided by C2 although C2 provides all required services. So, using our approach for restructuring ports, matching between C1 and C2 becomes possible.
Moreover, the component structure adaptation by its fragmentation in some generated components can be used to prepare a flexible deployment strategy. Indeed, this adaptation permits to organize component services in separate sub-sets and defining each sub-set in a new component generated by fragmenting the original one. Then, the generated components can be deployed on one machine or separately on different ones which can be distributed or not. These possibilities are very useful for load balancing and increased performance (Fig. 1 Case B).
The SCORPIO project
In SCORPIO project, we focus on adapting a component by its fragmentation in some sub-components where the set of provided services must be the same ones as those provided by the component before its adaptation. Each generated sub-component can be considered as a deployment unit which can be handled independently. This property is useful for adapting components to their deployment environment, taken into account constrained-resources, network performance evolutions, resource availability, etc.
We study the structural adaptation following different axes:
- Static structural adaptation
Software component adaptation, from a monolithic implementation to a composite one, is achieved through a transformation which is based on two phases. The first one is the decomposition phase which consists in fragmenting component code according to a given specification where each generated code-part matches with a new generated component implementation. The second phase is the recomposition which consists in assembling components generated during the first phase and integrating them into a new generated composite-component.
Topics studied :
* The static structural adaptation process
* Transformation of centralized software components into distributed ones
* Transformation of centralized software components into configurable ones
- The runtime structural adaptation
In prevous works, structural adaptation has been achieved by a static way. In this case, a component has to be stopped for adapting it. Nevertheless, in many cases where service continuity is required, the proposed approach cannot be used. Therefore, we proposed an approach allowing runtime structural adaptation. In this case, adaptation is achieved through a process based on two phases. The first one, achieved before deployment, consists in generating components whose structure is runtime-adaptable, from existing components. This component generation called re-engineering phase is based on source-code analysis and code-generation. The second phase, achieved since runtime, allows the application administrator to adapt a runtime-adaptable component according to the use needs, by the reconfiguration of its internal structure.