Towards the Adaptation of Component-based Architectures by Model Transformation
Some current software systems require their functioning and structure to adapt to requirements that were not detected at design time. Model-Driven Engineering provides software construction mechanisms from analysis to implementation, but its techniques can also be made use of for adaptation, by transforming system models at runtime. Component-based software architectures are an ideal target for these techniques, since manipulation of the architectural models representing the system can adapt their functionality when their structure is updated by adding or removing components, or by modifying the relationships between them. Our proposal attempts to find a solution for adapting component-based architectures by making use of model transformations. They are also dynamic, since the rules that describe their behavior are not preset, but are selected at runtime based on a repository of rules, depending on the system context. As part of our proposal, an adaptation schema based on model transformations has been developed that provides a solution to this dynamic transformation. It has been developed a case study in the domain of adaptable user interfaces and a web tool for validation of the proposal and demonstration of its applicability.
The interest of our research work in adaptation emerges from the application of software engineering techniques at runtime. This use is not intended to design and build the software system, but to provide a mechanism for self-adaptation at runtime. In order to better explain the process, it is important to clarify what kind of adaptation we want to achieve, how we are going to carry out this adaptation and where we want to apply the adaptation process. It is also shown the adaptation process in an example scenario and the developed tool for the validation and verification of our proposal.
- What kind of adaptation do we want to achieve?
- How can we carry out this adaptation?
- How much do we improve the performance of previous implementations?
- Where do we want to apply the adaptation process?
- Case study: component-based GUIs adaptation
- Mashup GUI example
- Adaptation Tool
What kind of adaptation do we want to achieve?
The adaptation process is intended to adapt component-based software systems at runtime. Our proposal is only valid for this type of systems and it is not applicable for any other system which is not defined as a component-based architecture.
Our research work is based on adapting an initial architecture from the changes occurring in the system context. Depending on the state of the initial architecture and the context information obtained, the system solves the adaptation requirements that should be carried out.
Furthermore, adaptation rules are stored separately in a repository and it has been developed a selection process that filters this repository using the adaptation requirements previously calculated and generating a rule subset.
Applying this subset of adaptation rules to the initial architecture, adapted architecture is obtained. The functionality of the architecture comes from the structure of the components that comprise it. Therefore, the obtained adaptation arises due to the reconfiguration that is performed in the component architecture. The next figure shows the behavior of the adaptation process.
Therefore, our goal is to provide a process for adapting component-based software architectures. This is achieved by applying a set of adaptation rules (insert, delete, reconnect, etc ...) on the components, which cause the reconfiguration of the architecture. Furthermore, the applied adaptation rules are not preset, but are selected at runtime from a rule repository depending on the information obtained from the system context.
How can we carry out this adaptation?
The adaptation process is carried out at an abstract level as to the representation of the system is concerned. Therefore, we made use of MDE techniques for the definition and manipulation of all the elements of the adaptation process.
Each element which serves as an input, which is generated in intermediate steps, or which is performed as output in the adaptation process, is defined by a model. In turn, each model is defined according to its metamodel and meets the syntactic and semantic constraints that are described in it.
On the other hand, model-to-model transformation processes are used to manipulate input models and for obtaining the output models at runtime. In addition, a TCS extraction is used for the dynamic generation of the ATL code of the M2M transformation that is responsible for adapting the initial architectural model.
The following figure shows our adaptation schema proposed for implementing the adaptation process. We can see all the models and metamodels involved in it and the set of transformations taking place to adapt the architectural model.
These are the models:
- observer model : contains the context information
- adaptation operations model : defines the desired adaptation operations
- rule repository : defines all the available rules
- selected rules model : contains the selected rules subset
- ATL model : describes the transformation model
- TCS for ATL : contains the correspondence between the transformation model and the ATL code
- architectural model (in) : initial architectural model
- architectural model (out) : adapted architectural model
These are the M2M transformations and the TCS extraction:
- context processing : transformation responsible for processing the context information
- rule repository rating : transformation in charge of scoring the rules
- rule selection : transformations which selects the appropriate adaptation rules
- repository update : transformation that updates the attributes of the rules
- HOT transformation : HOT-type M2M which generates the transformation model from the selected rules
- TCS extraction process : extraction of the ATL code from the transformation model
- Abstract Model Transformation : transformation that generates the adapted architectural
For futher details about the source of the elements of this adaptation schema (i.e. metamodel definitions, implementations of the model transformations, code extractions and model examples), you can browse the following link.
How much do we improve the performance of previous implementations?
Our proposal has undergone a series of improvements from previous implementations (published paper) in which the rules selected from the repository were translated by using model-to-text (M2T) transformation techniques with EMF JET instead of M2M. The main reason for changing the technology is that JET libraries require transformation to be done in the Eclipse framework.
In our attempt at making execution of the adaptation process independent of the platform, we sought transformations that could be run in a web environment and deployed in a server, so that in the future, cloud computing techniques can be applied to our process and the models that represent the architectures. Another reason for the change is that formalization provided by HOT for constructing M2M transformations is better than generating transformation code with M2T transformations, and better execution times are achieved.
The following figure shows a comparison of execution times between our current proposal making use of HOT and the previous implementation in which JET was used to transform the rule model to ATL code.
The figure shows times achieved in an experiment which ran 100 iterations of the adaptation process, generating random changes in the context variables and with a rule repository of 100 elements. When the M2M transformation process was used, execution times for the total process were around 500 milliseconds. On the contrary, in the previous version, making use of an M2T transformation, times were around 1.2 seconds, demonstrating a significant improvement in the process.
Where do we want to apply the adaptation process?
Because the description of our proposal, we think it is possible to apply the adaptation process in a diversity of software systems where component-based architectures must be adapted.
Examples of systems with this type of architecture could be:
- Component-based Graphical User Interfaces
- Smart Homes
- Smart Buildings
- Communication Networks
We assume that in such systems, the components existing in the architecture provide the functionality required and this architecure satisfies the system requirements. But, due to changes in the context of application, a reconfiguration of the architecture could be necessary to satisfy the new requirements. This reconfiguration operation may not have been foreseen at design time and, therefore, must be resolved dynamically at runtime.
Case study: component-based GUIs adaptation
As the particular domain for application of our adaptation proposal, we have chosen graphical user interfaces. Our interest in this domain is due to the trend toward Social Semantic Web or Web 3.0, in which user interfaces make use of technologies to favor exchange of information within the Web community and incorporate capacities that allow users to cooperate and share information.
In this context, we understand that it could be useful to have component-based user interfaces that can adapt their functionality depending on the circumstances. It is also intended to achieve smart graphical user interfaces, or what we call SmartGUI, which learn from interaction with the user or group of users, changing and evolving their behavior. Therefore, GUIs are described by means of architectural models containing the specication of user-interface components. These architectural models can vary at runtime due to certain changes in the context (e.g., user interaction, a temporal event, visual condition, etc).
For example, let's suppose two users in the system which are performing a communication task by means of a chat, an email, an audio and a high quality video. Consequently, the graphical user interface offered by the system contains the GUI components that provided these services. Let's suppose now that a new user profile role is connected to the system and requires the use of new services. This requirement involves the GUI automatically change to adapt its architecture to the new situation: i.e., removing the high quality video while a video low quality component, a blackboard component and a filesharing component are inserted (see the following figure).
To validate our proposal, we have developed a tool that enables us to execute the adaptation process on the architectural models that take part in an scenario within the domain of graphical user interfaces.
Our tool was implemented using the Eclipse EMF, ATL and TCS libraries, and was deployed in a web server so it can be tested from any platform without having to install any application or plugin. A snapshot of the tool is shown in the next figure.
The web tool enables us to test input of different context variable values. In our case study scenario, it is possible to choose between different user profiles (normal user, technician or politician). In addition, it is also possible to vary the values of the available bandwidh, the available main memory of the system, and the average size of the files are being shared by the user interacting with the graphical user interface.
Moreover, the tool shows information about the repository rules that are being used. The values of the name, action, is_priority, weight, run_counter, selection_counter, and ratio attributes are shown for each rule of repository.
In addition, the tool makes it possible to select the rule repository that is going to be used from a series of predefined models, or else provide our own repository of transformation rule models.
It has been offered two example repositories. The rule repository model A offers adaptation rules for adding and removing the following components: Email, Chat, Audio, low quality Video, high quality Video, Blackboard and FileSharing. Otherwise, the rule repository model B offers additional adaptation rules for adding and removing a Recorder component and for connecting and disconnecting such component with the high quality Video one, besides the rules provided by the repository A. Both repositories are available at the following links, if one wanted to experiment with creating a new repository from them to prove it with the web tool.
Once the rule repository has been selected and the context variables have been set to the desired value, we can execute the adaptation process by pressing the "LAUNCH ADAPTATION" button. Then we can see how the rule repository values have been updated in the execution of the process, and how is the adapted architectural model which is obtained as output.
Furthermore, log information on the rules run in the model-to-model transformations of the adaptation schema is shown at the bottom of the tool.
As an execution example, suppose a user starts with a graphical user interface with three components: Email, Chat and Audio. The user profile is techinician, the available bandwidth is 750 kbps, the available memory is 1,500 MB and the average size of the files are shared is 50 MB. Then the following changes in the values of the context variables occur: the new available bandwith is 1,500 kbps, the available memory is 3,000 MB and the user is sharing files with an average size of 200 MB. Consequently, complying with adaptation logic and using the rule repository A, the new adapted architectural model will incorporate low quality Video and FileSharing components, because the available resources have increased and the file sharing component will be beneficial for the user, since large files are being exchanged. We can see the adaptation example in the next figure.
In a next adaptation step, let us suppose that the user interacting with the graphical user interface change its profile from technician to politician. Then, applying the adaptation process and using again the rule repository A, the resulting architectural model will remove the low quality Video component and will insert a high quality Video component. This is because, for the technical profile, the high quality video component is not available.
However, starting from the previous initial interface, if the repository B is used, the resulting architectural model will be obtained removing the low quality Video component, inserting a high quality Video and a Recorder component, and connecting both. This occurs because the repository B provides these additional adaptation rules for the case where it is chosen the adaptation operation which indicates to inserts a video in high quality component (i.e., InsertVideoHighQ).
Starting from the latter architectural model, let us suppose the following changes occur in the context variables: the available bandwith is 1,250 kbps, the available memory is 2,500 MB and the user is sharing files with an average size of 100 MB. Therefore, the architectural model generated after performing the adaptation process (using the rule repository B) will be obtained by removing the FileSharing, high quality Video and Recorder component, and also by inserting the low quality Video component. We can see this adaptation step in the following figure.
--------------- The adaptation tool is available on: [link] ---------------