Master Informatique 2ème Année SAR Année 2007-2008 RAPPORT FINAL Livrable # 3 (Document de 14 pages) Participants Fabrice Douchant Xuan-Tuong Le Encadrants Nicolas Gibelin Lom Messan Hillah UFR 922 - Informatique Campus de Jussieu Maison de la Pédagogie, 2ème étage, Bureau C205 4 Place Jussieu 75252 PARIS CEDEX 05
Rapport final CONTACTS N O M P R É N O M E M A I L F O N C T I O N Douchant Fabrice fabrice.douchant@free.fr Etudiant M2 Informatique SAR Le Xuan-Tuong lxtuong@gmail.com Etudiant M2 Informatique SAR Version : 1.0 Page 2/14
Rapport final SUIVI DU DOCUMENT N O M P R É N O M D A T E V E R S I O N C O M M E N T A I R E S Douchant Fabrice 08/11/07 1.0 Création LE Xuan Tuong 10/11/07 1.0 Lecture finale T Y P E Version : 1.0 Page 3/14
Rapport final TABLE DES MATIÈRES 1Introduction......5 2Premier Langage : Agence......5 2.1Méta-Modèle......6 2.2Exemple......7 2.3Synthèse......7 3Second Langage : International......8 3.1Méta-Modèle......8 3.2Exemple......9 3.3Synthèse......9 4Validation des modèles....10 4.1Règles des modèles......10 4.2Règles des liens entre les modèles...10 4.3Synthèse......11 5La transformation......12 6Conclusion......12 Version : 1.0 Page 4/14
Introduction 1 Introduction Ce projet vise à fournir un environnement de développement support à l ingénierie logiciel guidée par les modèles, ou MDA (Model Driven Architecture) dédié à la construction d applications réparties de gestion d agents secrets. Il met en œuvre des composants hétérogènes communicants. Cet environnement sera appelé Distributed Intelligent Agency (DIA). L approche envisagée dans ce projet consiste à définir un environnement de développement, de déploiement et d exécution de scénarios sur des composants hétérogènes légers, par deux langages de modélisation. Ainsi, nous avons défini deux méta-modèles, ou deux langages «Agence» et «International». Le premier langage «Agence» définit des composants de chaque type d acteur, de leurs interfaces ainsi que des proxies de communication. Le deuxième langage «International» définit des scénarios d interactions entre les agences. Cette approche permet d'utiliser le principe de vues indépendantes qui n'ont à priori aucun lien entre elles. A partir de ces méta-modèles, l'utilisateur va pouvoir définir des modèles instances qui seront par la suite reliées et vérifiées par les opérations de validation pour générer du code Java ou Python. Dans un premier temps, nous étudierons nos deux langages et le processus de validation de chaque langage. Puis nous verrons l'étape de transformation et nous finirons par donner des exemples d'utilisation de DIA. 2 Premier Langage : Agence Le langage «Agence» permet à l'utilisateur de définir une agence avec ses ressources. Il pourra ainsi obtenir des modèles d'agences indépendants. Cette partie donne la spécification du méta-modèle «Agence» à travers un diagramme de classe, un exemple de modèle généré et une synthèse de notre langage du point de vue MDA. Version : 1.0 Page 5/14
Premier Langage : Agence 2.1 Méta-Modèle Illustration 1: Méta-Modèle «Agence» : Diagramme de classes Définitions des classes du méta-modèle (méta-classes) : Agence : une entité qui gère ses ressources. Matériel : une ressource peut être utilisée lors d'une activité. Un matériel hérite de ressource. Agent : un «employé» d'une agence à qui il ne peut pas communiquer car on voudrait que les agences coopèrent pour mener une mission commune en faisant effectivement agir tous les agents concernés sans communiquer entre elles leurs identités et sans que ceux-ci n aient de vision globale de la mission. Mission : une ressource définie par l'agence lors d'un scénario qui est une suite de missions. Une mission se compose d'une suite ordonnée d'activités et une mission hérite de ressource. Activité : une action lors d'une mission qui est effectuée par un agent et qui peut utiliser un matériel. Authentification : il y a deux façons d'utiliser cette méta-classe : la façon concrète qui permet à un agent créer des authentifications afin de conserver ses «couples d'authentification» : < Ressource, Clé >. la façon statique : le mécanisme d'authentification d'une agence. La méta- Version : 1.0 Page 6/14
Premier Langage : Agence classe statique Authentification est alors utilisée comme une base de données permettant de vérifier qu'un agent possède bien la bonne clé pour s' authentifier à une ressource. 2.2 Exemple Illustration 2: Exemple de modèle du langage Agence : Diagramme d'objets Dans cette exemple d'agence CIA, on a créé trois agents A1, A2 et A3. Ces trois agents ont des activités correspondantes qui appartiennent aux missions indiquées par l'agence. Via l'activité, l'agent sera capable de connaître son matériel. On peut observer que l'agent A3 peut être en stand-by. On peut associer ensuite des authentifications à chaque agent en introduisant une clé. 2.3 Synthèse Ce méta-modèle représente bien le langage Agence. Les agences sont totalement indépendantes entre elles car elles sont libres de définir ses composants sans avoir Version : 1.0 Page 7/14
Premier Langage : Agence aucune connaissance des autres agences. 3 Second Langage : International Dans une optique répartie, nous souhaitons que différentes organisations puissent synchroniser leurs objectifs. Cette partie donne la spécification du méta-modèle «International» à travers un diagramme de classe, un exemple de modèle généré et une synthèse sur la pertinence de notre méta-modèle. 3.1 Méta-Modèle Illustration 3: Méta-Modèle International : Diagramme de classes Définitions des classes du méta-modèle (méta-classes) : International : une entité où se situe des organisations. Cette entité est implicite, i.e on peut faire une analogie à la notion «univers» qui couvre tout. Organisation : une entité qui effectue des objectifs dans un ordre donné. Pour permettre la communication via le réseau, on a introduit le champ «host» qui indique l'adresse IP de l'organisation. Le champ «langage» permet à l'utilisateur d'indiquer le langage qu'il souhaite générer comme code. Version : 1.0 Page 8/14
Second Langage : International Objectif : appartient à une organisation. 3.2 Exemple Illustration 4: Exemple de modèle du langage International : Diagramme d'objets Explications : Org1 est une organisation en Java qui est située sur l'host (hôte : machine) 127.0.0.1:5001. Elle n'a qu'un seul objectif Obj1 et se termine. Org2 est une organisation en Python qui est située sur l'host 127.0.0.1:5000. Son premier objectif consiste à attendre que Org1 finisse son objectif Obj1 avant d'effectuer son propre objectif Obj1 puis se termine. 3.3 Synthèse Ce deuxième langage a pour contrainte d'être indépendant du premier langage : dans une approche multi-vues, les vues sont différentes. Seules les intérpretations de ces vues sont égales. A priori, nos deux langages n'ont pas la même syntaxe car les termes utilisés sont différents : organisation, objectif, agence, mission, etc. Cependant, nous pouvons observer des similitudes entre nos méta-modèles : les agences (premier langage) et les organisations (second langage) ainsi que les missions et les objectifs dans le deuxième avec chacun des attributs communs. On observe donc qu'il existe implicitement des liens que nous verrons plus loin l'impact d'un tel choix. Version : 1.0 Page 9/14
Second Langage : International Cependant, selon plusieurs points de vue, ce projet est difficile à scinder en deux langages indépendants, surtout pour une première approche MDA. Une deuxième constatation est la faiblesse de notre langage qui ne permet pas d'effectuer beaucoup d'actions. Cependant, nous avons considéré que le but du projet n'était pas de rendre un produit fini mais d'apprendre à utiliser une nouvelle approche de conception et de développement qui est MDA et de prendre du recul quant à son utilisation. 4 Validation des modèles Les modèles doivent suivre des règles syntaxiques et sémantiques suivant la description du méta-modèle mais aussi des règles logiques définies par le concepteur. Dans cette partie nous verrons comment définir des règles pour chacun des modèles et pour l'interaction entre les modèles. 4.1 Règles des modèles Lors de la création des modèles par l'utilisateur (c.f le manuel d'utilisation), une grande partie des règles de validation sont définies par EMF. Ainsi, si l'utilisateur ne spécifie pas de clé lors de la création d'une Authentification dans le premier langage, le modèle ne sera pas validé par EMF. Il existe plusieurs manière de définir des règles pour la création de modèles : spécifier des contraintes lors de la création du méta-modèle : cardinalitées. configurer le générateur de modèles pour qu'il force l'utilisateur à valider certaines règles : dans le cas de EMF : modifier le fichier.genmodel. créer des profils UML pour définir au niveau du méta-modèle des contraintes de construction des modèles. Les profils d'uml ciblant des plates-formes d'exécution permettent, par définition, d'adapter UML à des plates-formes d'exécutions. Le point intéressant à souligner dans un contexte MDA est que les modèles réalisés selon ces profils ne sont plus des modèles indépendants des plates-formes d'exécution mais, au contraire, des modèles dépendants de ces plates-formes. Ces modèles ne sont donc plus des PIM mais des PSM (Platform Specific Model). écrire les règles à la main : les développer. Dans notre cas, nous avons choisi de configurer le générateur de modèles et avons développé d'autres règles. 4.2 Règles des liens entre les modèles Version : 1.0 Page 10/14
Validation des modèles Il existe de nombreuses manières de définir des règles à appliquer lors de la création des modèles. Il existe cependant des règles logiques : des prédicats que le concepteur doit définir afin de s'assurer de la cohérence des modèles entre eux. On parle des liens entre les modèles. Dans notre projet, nous avons choisi de lier les organisations aux agences et les objectifs aux missions. Soit les deux règles suivantes : toute organisation doit avoir sa représentation sous forme d'agence. tout objectif appartenant à une organisation doit avoir sa correspondance dans les missions de l'agence représentant l'organisation. Nous avons donc établi des liens entre chaque entité définie dans les règles. Ainsi le lien entre organisation et agence est son nom, de même pour les objectifs et les missions. 4.3 Synthèse En ce qui concerne les profils UML pour définir les règles à appliquer aux modèles, il nous semble que notre projet n'est pas assez riche pour qu'il y ait de besoin d'éditer des profils. Cette approche reste néanmoins très intéressante pour des projets de plus grosse taille avec un délai de conception limité. Notre choix de règles semble assez logique au vu de nos méta-modèles. Cependant nous ne pensons pas avoir fait le bon choix. En effet ces règles sont beaucoup trop contraignantes et empêchent la flexibilité de l'utilisation des modèles : i.e une organisation ayant quatre objectifs qui lui appartiennent doit obligatoirement être lié à une agence ayant quatre missions. Ceci rejoint notre problème soulevé dans la synthèse du deuxième langage (3.3). Un autre choix de second langage aurait été préférable. En voici un exemple : Illustration 5: Méta-Modèle International Bis : Diagramme de classes Dans ce méta-modèle, il aurait seulement fallu appliquer une règle : chaque Version : 1.0 Page 11/14
Validation des modèles objectif doit correspondre à une mission d'une agence. Ainsi, on aurait disposé d'une plus grande flexibilité en oubliant le lien entre l'organisation et l'agence qui nous pénalise. De cette manière, les objectifs peuvent être affectés à n'importe quelles missions de n'importe quelles agences. Cependant nous n'avons pas pu avoir assez de recul sur ce problème avant d'y être vraiment confronté. Ayant déjà fini la génération du code, nous ne pouvons que constater ce manque de flexibilité. Une deuxième critique de notre validation est la gestion des liens. Dans notre cas, l'utilisateur crée les liens implicitement lors de la création des modèles en spécifiant les mêmes noms pour les agences/organisations qu'il souhaite lier, de même pour les missions/objectifs. Nous aurions dû utiliser une table de correspondance entre les entités à relier. Cependant, étant donné la forte contrainte liée à nos règles de validation, l'utilisateur doit connaître les différents modèles pour pouvoir les associer (le nombre de missions et le nombre d'objectifs) et les associations auraient été une associations d'arbres : i.e : Agence Y : Organisation X Agence Y. Mission A : Organisations X. Mission L Agence Y. Mission B : Organisations X. Mission M etc. Une autre méthode aurait été de définir un troisième langage permettant de définir ces liens. 5 La transformation Cette étape permet de générer du code. A la suite de la validation, elle se sert des liens entre les modèles pour générer un code respectant les contraintes vérifiées auparavant et scinde le tout. Dans notre projet, la transformation consiste à produire du code Java ou Python à partir des modèles «Agence» et de celui «International». Ce code tient en plusieurs fichiers Java ou Python qui représente chacun une agence et qui utilisera une API par langage que nous avons développées pour exécuter. 6 Conclusion Lors de la conception de ce projet, le travail a été réparti de sorte à être le plus productif possible. Dans un premier temps, nous avons défini ensemble les deux langages du projet et les règles de validation. Puis une personne s'est occupé de la vérification et la génération du code alors que l'autre a travaillé sur les APIs Java et Version : 1.0 Page 12/14
Conclusion Python. Nous avons également mis en oeuvre un serveur SVN permettant une collaboration plus efficace. Lors de la rédaction des rapports, nous avons respectivement fait le manuel d'utilisation et ce rapport final. Enfin, chacun à corrigé la partie de l'autre afin d'avoir une vision globale du projet. Selon notre opinion concernant l'approche MDA, l'un des points fort du multi-vues est que chacun aurait pu travailler sur son méta-modèle sans se soucier de l'autre et juste définir les règles de transformations ensemble une fois les méta-modèles définis. Durant quelques semaines, nous avons eu du mal à cerner le projet : son objectif, son ampleur ainsi que les deux langages. A la suite de quoi nous avons été suivi par les responsables du projet qui nous ont beaucoup aidés à comprendre leur demandes et l'approche MDA elle-même. Cependant nous n'avons pu avoir de recul sur notre projet qu'une fois les règles de validation terminées : le temps mis à développer les APIs et les règles de validation lors de notre projet est beaucoup plus important que le temps à développer directement les applications nécessaire. C'est pourquoi nous pensons que l'utilisation de l'approche MDA pour le développement d'un projet doit être mûrement réfléchi. Le MDA est une bonne approche si le projet est assez conséquent pour qu'il vaille la peine de passer par toutes les étapes de la conception «orientée modèles». Version : 1.0 Page 13/14
Conclusion INDEX DES ILLUSTRATIONS Illustration 1: Méta-Modèle «Agence» : Diagramme de classes...6 Illustration 2: Exemple de modèle du langage Agence : Diagramme d'objets...7 Illustration 3: Méta-Modèle International : Diagramme de classes...8 Illustration 4: Exemple de modèle du langage International : Diagramme d'objets...9 Illustration 5: Méta-Modèle International Bis : Diagramme de classes...11 Version : 1.0 Page 14/14