Processus d’injection d’algorithmes distribués dans un médium
Notre utilisation d’algorithmes distribués dans un médium
In a medium, distributed algorithms are essential for managing distributed data For instance, in a reservation medium, after the introduction of process managers in the refinement stage, identifiers are stored in the available variable of the ReservationMedium However, in the distributed version of the next step, identifiers are spread among reservation managers, with each manager holding a set of identifiers represented by the localAvailable variable Since the reserve service of a manager aims to return an available identifier from the entire set, it must search other managers if the localAvailable variable is empty This search is conducted using a distributed algorithm.
In the implementation phase, the variables localAvailable and available serve as specific data types, such as lists or tables, each providing an interface to their respective managers Our goal is to replace the localAvailable variable with a distributed variable that implements the same interface as the previous available variable This distributed variable is the implementation of the chosen algorithm with a defined interface In the ReservationMedium from the introduction phase of the managers, there may be constraints between the available variable and others, preventing an immediate replacement To address this issue, we utilize a data manager named DataManager (availableDataManager in the case of the reservation medium) to fully manage the available variable Subsequently, we introduce a step called in which we replace this data manager with a distributed data manager using a distributed algorithm This replacement is feasible because both classes of these variables implement the same interface.
Figure 3.1 illustrates the generic relationships between a medium, a role manager, and a data manager The distributed data manager will be integrated into the medium during the strategy selection phase.
La section suivante présente en détail les étapes du nouveau processus que nous appelons ô processus d’injection d’algorithmes distribuộs dans un mộdium ằ.
3.2 Processus d’injection d’algorithmes distribués dans un médium 24
IComponent Service IMediumServices
/ Manager Medium
Bibliotheque L_ -4 DataManager d'algorithmes
Fic 3.1 — Injection d’un gestionnaire de données distribuées dans un médium
Etapes du processus d’injection d’algorithmes distribués dans un médium 24
This process involves the refinement of the medium discussed in the previous section We are introducing a new step called "algorithm selection" and implementing several modifications in the introduction of the managers.
Nous allons présenter chaque étape par son principe et l’exemple du médium de réservation dans cette étape
C’est la premiére étape du processus de raffinement de médium, il n’y a pas de notre modification ici La spécification abstraite du médium de réservation est montrée dans la figure 2.9
The process of refining medium has been established since the introduction of process managers, with the addition of two key steps: the introduction of data managers and the replacement of abstract types.
3.2 Processus d’injection d’algorithmes distribués dans un médium 25
Etape 1.1 : Introduction des gestionnaires de réle
Le but de cette étape est de représenter le médium comme une agrégation des gestionnaires de réle La figure 2.13 illustre la spécification du médium de réservation aprés cette étape
Etape 1.2 : Introduction des gesttonnaires de données distribuées
DataServices is a crucial component of our process, encompassing fundamental operations for data collection management It includes functions such as init to initialize the collection, insert to add an element, remove to delete an element, select to retrieve an element, and size to return the total number of elements in the collection.
Data partitioning strategy: In this phase, we introduce a new concept: the data partitioning strategy A model of this strategy is utilized to illustrate the designer's decision-making process in developing a distributed application During this stage, the designer determines which data within the medium will be distributed among various managers and selects the appropriate distributed algorithm for this purpose For instance, in the reservation medium, the designer may decide to distribute the identifiers in the available variable of the ReservationMedium across the reservers' managers using the Chord algorithm.
This step is implemented to separate the source codes from the ReservationMedium related to the selected data for distribution In this phase, we integrate a data manager with each chosen data set Figure 3.3 illustrates the generic relationship between a medium, a manager, and a data manager.
Dans cette spécification, une classe nommée DataManger représentant le gestionnaire de données est associé au médium ReservationMedium,, il implémente l’interface
Figure 2.15 illustrates the reservation medium after this stage In this specification, an AvailableDataManager class has been added, which implements the AvailableDataServices interface The collection of available identifiers processed by the ReservationMedium is now handled by the AvailableDataManager The ReserverManager utilizes the services provided by the AvailableDataServices interface to implement its reservation service.
Etape 1.3 : Remplacement des types abstraits
This step aims to assign a chosen abstract data type (from the data distribution strategy) to a medium variable In terms of implementation, a specific type is utilized, such as a list or table.
Dans la version abstraite du médium, nous utilisons un type abstrait commun pour toutes
3.2 Processus d’injection d’algorithmes distribués dans un médium 26
/source SourceManager | _ {>| setReserveIdSet(Reserveld[], Boolean) initO insert(Reserveld) mm sera s sos en >| remove(ReserveTd)
/observer Observer Manager TObserverComponentServices
Figure 3.2 illustrates the introduction of role managers and data managers within the collaboration diagram of the reservation medium, referred to as MediumSet In this phase, the common type implementing the defined DataServices interface is replaced by another type selected from an abstract types library The abstract types available in this library also provide the services outlined in the defined interface This concept is further depicted in Figure 3.3.
This step aims to eliminate the medium representation class Data managers are now linked to role managers responsible for data distribution These role managers are specified in the data distribution strategy introduced in step 1.2.
In this new phase, we are transitioning from traditional data managers to distributed data managers implemented within an algorithm library To facilitate this replacement, the distributed data managers must deliver services through the DataServices interface.
La figure 3.4 représente la relation générique entre un réle, un gestionnaire de réle et un gestionnaire de données distribuées d’un médium aprés cette étape.
3.2 Processus d’injection d’algorithmes distribués dans un médium 27
1 1 wo ke 1 ôinterface | ObserverManager TObserverComponent Services
Boolean usable nbAvailable(Integer) i Reserveld reserve() AA
Fic 3.5 — Diagramme de collaboration du médium de réservation, version distribuée, lago- rithme Chord est utilisé pour la gestion des identificateurs sur les gestionnaires de réserveur
The objective and principle of this stage are consistent with those of the medium refinement process deployment phase A distributed data manager is implemented at the same location as the associated role manager Figure 3.6 illustrates the deployment architecture of the reservation medium, utilizing the Chord algorithm to manage identifiers effectively.
Résumé du processus .0 00 ee HQ HH ga 28
We have outlined our data distribution algorithm injection process within a medium Figure 3.7 summarizes this process specifically for the reservation medium.
Les points importants dans notre processus sont les suivants :
— Définition d’une interface nommé DataServices pour une collection de données.
3.2 Processus d’injection d’algorithmes distribués dans un médium 29
Introduction des données distribuées gestionnaires
Choix de déploiement PR > | ry) LR y mmƒE DDM H fqmgE
Fic 3.7 — Résumé du processus d’injection d’algorithmes dans un médium appliquant dans le médium de réservation
Conclusion 2 ee 30
— Définition de stratégie de répartition de données Cette stratégie est utilisée comme don- nées entrées du processus
— Définition d’un type abstrait commun implémentant l’interface DataServices
— Construction d’une bibliothéque de types abstraits implémentant l’interface DataSer- vices
— Construction d’une bibliothéque d’algorithmes distribués implémentant l’interface Data- Services
— Introduction des gestionnaires de données dans le médium afin de séparer des codes sources du médium concernant l’ensemble de données choisi pour la distribution
— Remplacement de types abstraits et de gestionnaires de données
The distributed algorithm process outlined in this chapter is developed by modifying Eric Cariou's medium refinement process A key aspect of this approach is the definition of a DataServices interface, which serves as a common abstract type This interface is implemented by abstract types within the abstract types library, data managers, and distributed data managers, allowing for the seamless replacement of a data manager with a distributed data manager or a common type with a specific abstract type In aspect-oriented programming terminology, the DataServices interface acts as a junction point.
Programme de transformation de médium
Dans ce chapitre, nous présentons notre travail de réifier le processus d’injection d’algo- rithmes distribués présenté dans le chapitre 3 par un programme de transformation de modéle.
Choix de langage de transformation: Kermeta
Architecture du Kermeta 2.00000 eee eee 32
5 Typed Element nes Ing Package owned TypeDefiniion
Package a: Enum era tionLiteral nes kdPackaye +“ — ũ 1 | line Ei Ty pe De finifian œw nelibrd | *
Ej Mulfiplicity Ele m e n† Type super hype
< i Ty pe Variable © isOrdered: Book an a 0 1 © isUrique: Boolean % isks lance) 0.7 0.7 | lypePa ame kr
3 low er: We ger Tp : hy pe Parameler | © upper: Unimikd Waura — li Ẫ Super Type § Cla ssDe finition
_ & [ata Type rasedExceplion ow ningt lass © BAbslracl: Bodean
0.1 © isRead0 nh: Boolean erumerafon|0 1 from packaje ; kermela: danguaye: behavior 2 super peraton
Fic 4.1 — Package kermeta::language::structure
Kerketa est développé par l’équipe Triskell 4 INRIA Rennes (France) C’est un langage de métamodélisation qui permet de décrire la structure ainsi que le comportement de modeéles.
Les programmes en Kermeta sont exécutés dans |’Eclipse
Kermeta language is designed in compliance with the EMOF metamodeling language standard and Ecore The aim is to utilize MOF to define the language structure while incorporating an action model As MOF is an object-oriented concept, Kermeta integrates most object-oriented mechanisms In Kermeta, MOF is employed to describe structures, and the operational semantics are defined within Kermeta Consequently, Kermeta's metamodel is organized into two separate packages.
Figure 4.1 illustrates the main classes of the structure package, which is designed to enhance VEMOF The choice of EMOF is significant as it is endorsed by OMG and utilized in tools like Eclipse/EMF.
Transformation de modéle utilisant Kermeta
Grace au Kermeta, on peut créer des modéles EMF et les manipuler La démarche d’une transformation de modéle est la suivante :
To define a metamodel, one can write the metamodel in Kermeta source code and translate it into Ecore using the kermeta2ecore tool, or alternatively, utilize the Omondo/Eclipse UML graphical editor to directly manipulate the Ecore metamodel.
To create an EMF 4 model from a metamodel, Kermeta can be utilized to generate a reflective editor based on an Ecore metamodel This editor allows for the creation of models, and developers can also leverage Kermeta source code for model generation The resulting models can be saved in XMI or KM format.
- Manipuler les modéles dans un programme exécutable Kermeta
La figure 4.2 montre la démarche d’une transformation
To develop the program that streamlines the injection process, we select the Kermeta language due to its essential features and its development by the Triskell team, which is part of our Amadéus project.
Analyse 2 ee 33
Les programmes en Kermeta sont exécutés dans |’Eclipse
Kermeta language is designed in compliance with the EMOF metamodeling language standard and Ecore The core idea is to leverage MOF to describe the language structure while incorporating an action model Since MOF is an object-oriented concept, Kermeta integrates most object-oriented mechanisms In Kermeta, MOF is utilized to define structures, with operational semantics articulated in Kermeta Consequently, the Kermeta metamodel is organized into two packages.
Figure 4.1 illustrates the main classes of the structure package, designed to enhance VEMOF EMOF is selected due to its endorsement by OMG and its integration in tools like Eclipse/EMF.
4.1.2 Transformation de modéle utilisant Kermeta
Grace au Kermeta, on peut créer des modéles EMF et les manipuler La démarche d’une transformation de modéle est la suivante :
To define a metamodel, one can write the metamodel in Kermeta source code and translate it into Ecore using the kermeta2ecore tool, or alternatively, utilize the Omondo/Eclipse UML graphical editor to directly manipulate the Ecore metamodel.
To create an EMF 4 model from a metamodel, Kermeta can be utilized to generate a reflective editor based on an Ecore metamodel This editor allows for the creation of models, and users can also leverage Kermeta source code for model generation The resulting models are saved in XMI or KM format.
- Manipuler les modéles dans un programme exécutable Kermeta
La figure 4.2 montre la démarche d’une transformation
To develop the program that streamlines the injection process, we select the Kermeta language due to its essential features, which are supported by the Triskell team, a key group within our Amadéus project.
The process of injecting distributed algorithms consists of five stages, starting with an abstract specification of the input medium in the first stage Following the subsequent stages, multiple output specifications are generated In the design choice, algorithm choice, and deployment choice stages, various output specifications emerge Figure 4.3 illustrates this process.
Métamodéle Modéle de Mé†amodèle
Modéle | Exécution de source transformation
Figure 4.2 illustrates the model-to-model transformation in Kermeta, highlighting the relationship between input specifications and output specifications in the process The nodes in this figure represent medium specifications after each stage, with the yellow nodes (*) indicating the results of the additional step we have incorporated.
To develop a Kermeta program that can transform an abstract medium specification into detailed specifications during the injection process, it is essential to understand how to represent medium specifications using UML in Kermeta and how to execute the transformations between these specifications effectively.
Représentation générique d’un diagramme UML en Kermeta
Au point de vue de langage Kermeta, il y a deux couches :
— Couche ô mộtamodộle ằ : On peut dộfinir un mộtamodộle en Kermeta, l’exporter en forme ecore (ou l’inverse) Les opérations peuvent étre implémenté en Kermeta 4 ce niveau
The model layer serves as a foundation for creating instances, which are structured sets of objects managed by Kermeta These models can be saved in XMI format, allowing for various operations to be executed at the metamodel level In this context, the model becomes executable, enhancing its functionality and usability.
To develop a medium transformation program, it is essential to define medium metamodels A UML specification of a medium serves as an instance model Subsequently, we can create small transformation programs for these models.
From the perspective of the medium transformation program, it is essential to conduct a test of the program In other words, we need to create an instance of the output specification to simulate the process effectively.
Conception 1 ee 30
Structure du programme 000022 eee eee 39
La figure 4.4 représente la structure du programme construit qui se compose de plusicurs petites transformations :
— Transformation T1 introduit les gestionnaires de réle dan la spécification abstraite MO (Ventrée du programme)
Transformation T2.1 aims to develop a strategy model, referred to as Strategy 1, which includes a comprehensive list of algorithm names, abstract type names, role manager names, and variable names within the class representing the medium The "Choice" phase involves the designer creating tasks, where each task comprises a variable (representing a dataset), an abstract type associated with that variable, several role managers distributing the dataset, and the algorithm utilized The outcome of this phase is encapsulated in the Strategy 2 model, which also features an attribute indicating the design choice made.
— Transformation T2.2 remplace le type commun MediumSet dans le médium par le type abstrait choisi qui est indiqué dans le modéle de stratégie
The Transformation T3 eliminates the class that represents the medium and introduces data managers that correspond to the variables specified in the Strategy 2 model within the distributed version of the medium.
— Transformation T4 remplace les gestionnaires de données par les gestionnaires de don- nées distribuées choisis
Fic 4.4 — Chaine des transformations réifiant le processus d’injection
Démarche du programme en Kermeta 36 4.3.3 Métamodéles de médium 2.2-.000- 38
Dans notre programme, chaque médium est représenté par son diagramme de collaboration avec les opérations exécutables
Afin de résoudre le probléme présenté dans la section 4.2, dans notre programme, pour représenter un médium, nous utilisons les modéles suivants :
— Un métamodéle en Kermeta (ou ecore) qui décrit la spécification de médium (Medium Metamodel, MM).
It seems the provided text is unclear and may contain errors or nonsensical content To assist you effectively, please provide a more coherent version of the article or clarify the key points you would like to focus on for rewriting.
4, lÍ MMO |]| MMI || MME || mm | tO ỳ
Modèle kermeta: :language: :structure (kermeta/lib/framework.ecore)
* corps de méthode: EAnotation(String) o
Fic 4.5 — Démarche du programme de transformation du médium en Kermeta
A model M is an instance of the metamodel MM, representing the structure of a collaboration diagram It includes objects that symbolize classes within the diagram, while the attributes of these objects illustrate the relationships between the classes.
A model M' is exported from a Kermeta implementation using the Voutil kmt2xmi tool This model includes classes within the collaboration diagram, complete with method bodies As such, it represents an instance of the Kermeta language metamodel.
Figure 4.5 illustrates our transformation program approach, where each medium is depicted through two models undergoing a series of transformations The processes involved are detailed as follows:
— Construction des six métamodéles de médium correspondant aux six modéles de médium (voir la figure 4.4)
Dans ce travail, nous avons défini un grand métamodéle pour tous les six modéles de médium Pour différencier les médium, nous utilisons des contraintes (opérations en Ker- meta)
— Implémentation d’algorithmes en respectant l’interface DataServices
Implémentation de types abstraits de données en respectant l’interface DataServices
— Création d’un modéle de médium de réservation au niveau de spécification abstraite pour
Implémentation les corps des méthodes de ce modéle de réservation au niveau de spécifi- cation abstraite
— Construction des transformations T1, T2.1, T2.2, T3, T4 (voir la figure 4.4)
Dans ces transformations, on utilise les modéle de stratégic, donc on doit aussi définir le métamodéle de stratégie par avance
The transformation program includes six mediums, necessitating the construction of six medium metamodels We establish a comprehensive common metamodel for all these mediums and employ constraints to differentiate between them Essentially, the overarching metamodel and a set of constraints collectively represent a four-level medium metamodel Figure A.1 in the appendix illustrates this comprehensive metamodel of mediums.
Notre programme est réalisé en Kermeta a l’aide de l’Eclipse Dans notre programme, nous utilisons le médium de réservation et implémentons un algorithme trés simple pour le test
La figure 4.6 illustre la structure des packages et des fichiers de code source du programme
Le package /medium/src contient les fichiers des codes sources en Kermeta, il se compose des packages suivants :
The package metamodel includes Kermeta files that are essential for constructing the metamodel of media, constraints, and the strategic metamodel Utilizing the Kermeta tool kmt2ecore, these files are exported to Ecore files located in the package /medium/models/metamodel.
The package model includes files essential for implementing the method bodies of the entry reservation medium, managing distributed data handlers, defining abstract type methods, and providing DataServices interface functionalities These files are exported to xmi/km files located in the /medium/models/model package.
— Package transformations conticnt les petites transformations présentées dans la section 4.3.1
Le package /medium/models contient donc les modéles exportés depuis les fichiers des codes sources Kermeta du package /medium/src
Le package /medium/test contient les fichiers pour le test.
> abstracttype.km algorithm.km dataservices.km
=e abstracttype.kmt algorithm kmt dataservices.kmt operatingsystem.kmt reservation, abstract implement kmt reservation, abstract struct kmt
='- transformation basicoper.kmt rn0tom 1 krnt mitom2.kmt mZtom3c.kmnt mZtom3d.kmt rn3dtom4d.kmt rnndeloper krnt strategyexport.kmt transfo 1 kmt transfa2.kmt
Fic 4.6 — Structure des fichiers de code source du programme
43 centralized_strategy.xmi distributed_strategy.xmi outstrategy.xmi reservationl xmi put2 reservation2 xmi reservation3c.xmi reservatian3d.xmi reservation4d, xmi
Fic 4.7 — Structure des fichiers de test du programme
To test the execution of an injected algorithm, we utilize the example of the reservation medium The package located at /medium/test/input contains the input models, which include the abstract types library (abstracttype.km), the algorithms library (algorithm.km), the common abstract type (dataservices.km), and the abstract medium MO (reservation0.km and reservation0.xmi).
The small transformations are divided into two programs corresponding to the files transfol.km and transfo2.km The first program includes transformations T1 and T2.1, producing medium M1 and a strategic model, which are stored in the package /medium/test/output1l The second program encompasses the remaining transformations, with the resulting models saved in the package /medium/test/output2.
Quelques montres des métamodéles, des modéles et des codes sources du programme sont présentés dans annexe de ce mémoire.
Our program is designed to test the automatic transformation of medium models It verifies the process of injecting data distribution algorithms into a medium that is enhanced by improving the medium refinement process This transformation occurs at the modeling level and serves to integrate code components effectively.
We tested the transformation of reservation mediums The program inputs include an abstract specification of the reservation medium and a strategy model that illustrates the data distribution strategy of the designer The abstract specification is depicted through a UML collaboration diagram and a model representing the method bodies of the classes within the diagram The program outputs consist of specifications corresponding to the steps of the injection process.
We presented our work on researching a process for injecting data distribution algorithms into a communication component and developed a program to implement this process This internship involved two main tasks.
We proposed a solution for injecting distributed algorithms into a medium by integrating these algorithms into the medium's specifications A key aspect of our solution is the definition of an interface called DataServices, which acts as a junction point Both the algorithms and abstract data types implement this interface, allowing us to incorporate an additional refinement step where data-representing classes are replaced with classes representing data distribution algorithms This process is referred to as the injection of distributed algorithms into a medium To develop the program that realizes this injection process, we utilized the Kermeta model transformation language, created by another team within our project.
The program consists of a chain of transformations, with each transformation corresponding to a step in the process The output model of one transformation serves as the input model for the next transformation Within the program, Kermeta actions are utilized to describe the operational semantics of medium models.
Notre solution d’injection d’algorithmes distribués dans un médium est utilisée au niveau d’implémentation Dans notre travail, il n’y a pas encore de solution pour faciliter ’implémen- tation des algorithmes
De plus, dans les systémes distribués, les données sont réparties de plusieurs maniéres dif-
There are 43 different algorithms, including non-replication, partial replication, and replication Consequently, various classes of algorithms are utilized However, our solution does not yet specify these algorithm choices, indicating that the data distribution strategies remain insufficiently defined.