L’utilisation d’une infrastructure de transformation générique basée sur des modèles de plates-formes d’exécution explicites a apporté un degré de flexibilité supplémentaire par rapport aux infrastructures de transformation spécifique. Pour une même transformation et pour un même modèle applicatif (Producteur/Consommateur), plusieurs modèles applicatifs cibles sont générés. Les modèles de plates-formes paramètrent les exécutions des transformations et donc capitalisent les descriptions de ces transformations.
Cependant, la comparaison entre les modèles générés par une transformation spécifique et ceux générés par une transformation générique reflète que les transformations génériques n’ont permis qu’une simple transition structurelle du modèle applicatif indépendant de la plate-forme vers les modèles spécifiques aux plates-formes. Des tels modèles sont insuffisants pour la génération automatique d’un code applicatif complet et exécutable. Dans cet objectif, nous devons affiner l’analyse afin d’obtenir une synthèse des supplémentaires. Le but sera de pouvoir générer des modèles applicatifs cibles complet1 permettant la
génération du code exécutable. Ces modèles générés doivent être identique en niveau de 1. Un modèle spécifique à la plate-forme est complet si le code généré à partir de ce modèle ne nécessite aucune intervention humaine pour l’exécuter
complétude à ceux générés par des transformations spécifiques.
2.2.1 Analyse
Afin de pouvoir obtenir des modèles spécifiques à la plate-forme complet et permettant la génération du code exécutable à partir d’une transformation générique, on peut identifier les problématiques suivantes :
Implémentations spécifiques à la plate-forme :
Une implémentation spécifique à la plate-forme est un code spécifique au langage de programmation de la plate-forme cible. Il sert à réaliser un service ou un comportement spécifique à une ressource de la plate-forme ou encore un patron de conception imposé par la plate-forme. Par exemple, dans les modèles générés par des transformations spécifiques (figures 4.7 et 4.8), plusieurs implémentations spécifiques à la plate- forme peuvent être identifiées. Les opérations init et create sont des implémentations spécifiques qui servent à créer les threads et les sémaphores. Les opérations run et staticOp et leurs comportements périodiques associés sont caractéristiques de l’impact des patrons de conception imposés par les plates-formes Java et C++/POSIX respectivement.
Appels des services offerts par les ressources des plates-formes :
Les appels des services des ressources de la plate-forme peuvent être divisés en deux types.
1. Le premier type concerne les appels qui sont émis depuis le code métier de l’application. C’est le concepteur de l’application qui précise le service qu’il faut appeler pour avoir le comportement désiré. Par exemple, dans l’application Producteur/Consommateur, si le consommateur décide d’arrêter la production après un certain nombre de mesures, alors l’appel d’un service permettant d’arrêter le thread du producteur doit être effectué.
2. Le deuxième type des appels concerne les appels qui doivent absolument être effectué pour réaliser un certain mécanisme de communication ou de synchronisation dans l’application. Par exemple, pour réaliser le mécanisme de synchronisation des appels des opérations de l’objet protégé counter, les services acquire (met l’appelant en attente jusqu’à ce que la ressource soit disponible) et release (rend une ressource disponible à nouveau après que l’appelant a terminé de l’utiliser) de la ressource sémaphores doivent être appelés, comme indiqué dans la figure 4.10.
Ces deux besoins représentent les limites principales envers l’adoption des trans- formations génériques. Une approche visant à adopter des transformations réutilisables et portables doit premièrement offrir des heuristiques de modélisation pertinentes et efficaces permettant d’extraire toutes les implémentations spécifiques à la plate-forme des transformations de modèles. Deuxièmement, elle doit offrir la possibilité de gérer les appels vers les services des ressources de la plate-forme d’une manière indépendante
3 Gestion des implémentations spécifiques à la plate-forme 53
de la plate-forme. Une fois que les solutions sont trouvées, la spécification d’un cadre méthodologique et technologique pour le développement des systèmes multitâches à base des transformations génériques réutilisables et portables sera possible.
On laisse volontairement de coté, dans cette étude, les appels des services d’une manière indépendante de la plate-forme depuis le code métier de l’application.
2.3 Bilan
Dans cette section, une comparaison a été effectué entre un modèle d’une application généré avec des transformations de modèles spécifiques et un autre modèle pour de la même application généré avec l’infrastructure de transformation générique à base de SRM proposé dans [75]. A l’issue de cette comparaison, nous avons identifié deux problématiques pour lesquelles il faut trouver une solution afin de pouvoir utiliser les transformations génériques pour le déploiement des systèmes multitâches et, par conséquence la génération du code exécutable.
La section suivante traite la première problématique, elle propose ainsi des heuristiques de modélisation permettant d’extraire les implémentations spécifiques à la plate-forme des transformations et de les supporter dans un modèle de cette plate-forme. La deuxième problématique sera traitée dans le chapitre suivant.
3
Gestion des implémentations spécifiques à la plate-forme
Afin de fournir une gestion modulaire des implémentations spécifiques à la plate-forme, une approche étendue de modélisation des plates-formes est proposée. L’idée principale de cette approche consiste à décrire, comme proposé dans [75], avec SRM, la structure des ressources et des services offerts par les plates-formes d’exécution et, en plus, à décrire les comportements (ou sémantiques d’exécution) de ces ressources et ces services. Le but sera, d’une part, d’abstraire les concepteurs des transformations des implémentations spécifiques à la plate-forme, et d’autre part, d’offrir aux fournisseurs de plates-formes ou aux experts de plates-formes, une approche de modélisation à suivre pour fournir des modèles détaillés de leurs plates-formes encapsulant toutes les implémentations spécifiques.
L’approche de modélisation proposée est une approche itérative et chaque itération permet de modéliser entièrement une ressource de la plate-forme logicielle. Cela comprend aussi la modélisation des services, des propriétés et des patrons d’utilisation de la ressource. Cette approche de modélisation emploie principalement le diagramme de classe d’UML car il permet de modéliser explicitement les ressources, les services, les propriétés et les implémentations spécifiques notamment à l’aide des classes (Class) constituées des opérations (Operation), des propriétés (Property) et des comportements opaques (OpaqueBehavior).
En considérant que la modélisation en UML avec application de profils n’est pas une pratique courante chez les fournisseurs de plates-formes, des heuristiques de modélisations sont proposées pour les guider dans la modélisation de leurs plates-formes logicielles.
Choisir le concept SRM
Identification des comportements de la ressource
Modélisation des services fournis Modélisation des éléments
typés
Identification des impacts de modélisation Ajout des services
manquants Modélisation de la ressource existante Modélisation de la ressource manquante [Ressource non trouvée] [Ressource trouvée]
[Autre concept] [Aucun concept]
[Services non trouvée] [Services
trouvée]
FIGURE4.13 – Séquencement des étapes de modélisation