Modélisation et systèmes multi

Modélisation et systèmes multi

Sauvegarde des modèles

Qu’il s’agisse de MIMOSA ou de S-Edit la sauvegarde des modèles se fait dans le format XML. Ce choix est motivé de part et d’autre par les capacités de description du langage XML. Les fichiers XML s’ils servent de sauvegarde, n’en constituent pas moins des interfaces utilisateur de description des modèles. Ces capacités sont pleinement utilisées par S-Edit qui s’en sert pour décrire les catégories d’objets du modèle. Cependant, le langage XML bien qu’assez simple d’accès demeure assez rébarbatif pour les non informaticiens. Pour palier à cet inconvénient d’ordre « ergonomique » MIMOSA propose une interface graphique générique de description de catégories.

a) Sauvegarde MIMOSA

Chaque notion de la boite à outils MIMOSA, dans son implémentation dispose d’une méthode toXML() toXML() toXML() toXML(). Cette méthode dans sa définition de base sauvegarde au format XML l’état de la notion. Cette méthode est surdéfinie dés lors que la notion devient sémantique. Etant sémantique la description XML de la notion doit en refléter la spécificité. Il est évident que l’on retrouve une nouvelle implémentation de la boite à outils mais cette fois à travers le langage XML.

Sauvegarde des modèles S–Edit

Au niveau de S-Edit en ce qui concerne la sauvegarde il faut comprendre que le format XML est utilisé au même titre qu’une interface graphique pour décrire les catégories d’objets du discours. Cela implique que les concepts catégoriels ne font pas réellement l’objet de sauvegarde car ils sont décrits de façon statique à travers un fichier XML. Le modèle concret par contre fait l’objet de sauvegarde car il est construit pendant l’exécution par l’éditeur de diagrammes. Mais la démarche de sauvegarde manque de généricité car elle n’inclut pas de possibilité de surdéfinition ; la sauvegarde est plutôt géré par deux classes : la classe XMLStructureSaver XMLStructureSaver XMLStructureSaver XMLStructureSaver chargé de sauvegarder un modèle et tout ce qu’il contient (nœuds, arcs, connecteurs) et la classe XMLStructureLoader XMLStructureLoader XMLStructureLoader XMLStructureLoader qui permet de charger les modèles. Ce manque de généricité est compensé par la présence des propriétés, en effet les propriétés disposent d’une description XML il s’agit donc d’assimiler la spécialisation des concepts à l’adjonction de nouvelles propriétés. Définir un nouveau type c’est définir un nœud avec de nouvelles propriétés.

Comparaison

A titre de comparaison on retiendra seulement que le système S-Edit effectue une description statique des catégories du modèle alors que la plateforme MIMOSA effectue une description interactive des catégories du modèle. Etant interactive cette description se doit d’être sauvegardé dans le format XML au même titre que les concepts individuels.

Assimilation par héritage et interfaçage

Description

L’assimilation par héritage part du constat que la boite à outils S-Edit est une spécialisation légèrement plus sémantique de la boite à outils MIMOSA. D’où l’idée de fusionner les boites à outils à travers le mécanisme d’héritage. Dans la philosophie de la plateforme cette opération s’apparente à une création de formalisme, en l’occurrence un formalisme S-Edit. Cependant les concepts de ce formalisme ne constituent au final qu’une autre boite à outils car, asémantique, qui n’aura d’autre particularité que d’être graphique. Pour les puristes cette approche se trouve être la plus élégante car elle fusionne des éléments conceptuellement identiques. Un nœud se trouve être un composant, un arc se trouve être une relation intra composé et le graphe se trouve être un composé. Ainsi les notions basiques de MIMOSA se retrouvent enrichis de méta données permettant leurs affichage et édition graphique. L’héritage par ailleurs, contrairement à la réécriture, n’entraîne pas l’adjonction directe des méta données aux classes MIMOSA. Ces méta données peuvent être considérées comme encombrantes surtout lorsque l’on développe des formalismes qui ne nécessitent pas de représentations graphiques.

Implémentation

En ce qui concerne l’implémentation, la situation est moins idéale. Ce que l’on aimerait nous c’est placer immédiatement SNode SNode SNode SNode en tant que sous classe de Compo Compo Compo Component nent nent nent, SArrow SArrow SArrow SArrow en tant que sous classe de IntraCompoundRelation IntraCompoundRelation IntraCompoundRelation IntraCompoundRelation et de même pour les concepts catégoriels de nœud et d’arc. Mais les classes SElement SElement SElement SElement au niveau individuel et ElementDesc ElementDesc ElementDesc ElementDesc au niveau catégoriel nous font obstacles car elles généralisent l’ensemble des notions individuelles et catégorielles de nœud et d’arc — les nœuds et les arcs sont des éléments. Solution ? Nous ne pouvons pas supprimer ces classes car le contrôleur S-Edit (toujours au sens MVC) y fait référence. Nous n’avons donc qu’une seule solution transformer ces classes en interfaces et introduire de nouvelles classes pour implémenter ces interfaces. Nous utilisons de nouvelles classes car l’on ne veut pas modifier l’implémentation des classes S-Edit. On veut demeurer dans une optique de couplage même si l’on vient de violer de manière imperceptible (pour S-Edit) ce principe. Dans cet optique on introduit aussi des classes intermédiaires entre CompoundType CompoundType CompoundType CompoundType et Formalism Formalism Formalism Formalism et entre Compound et Structure, même s’il n’y a pas d’obstacle à ce niveau. En résumé les classes et interfaces que nous allons introduire sont les suivantes :
L’interface ElementDesc ’interface ElementDesc ’interface ElementDesc ’interface ElementDesc : elle se substitue à la classe du même nom définie par S-Edit.
L’interface SElement ’interface SElement ’interface SElement ’interface SElement : elle se substitue à la classe du même nom définie par S-Edit.
La classe a classe a classe a classe SEditComponentType SEditComponentType SEditComponentType SEditComponentType: cette classe implémente l’interface ElementDesc ElementDesc ElementDesc ElementDesc et hérite de la classe MIMOSA ComponentType ComponentType ComponentType ComponentType. De cette classe hérite la classe NodeDesc NodeDesc NodeDesc NodeDesc.
La classe SEditIntraCompoundR La classe SEditIntraCompoundR La classe SEditIntraCompoundR La classe SEditIntraCompoundRelationType elationType elationType elationType : cette classe implémente l’interface ElementDesc ElementDesc ElementDesc ElementDesc et hérite de la classe MIMOSA IntraCompoundRelationType IntraCompoundRelationType IntraCompoundRelationType IntraCompoundRelationType. De cette classe hérite la classe ArrowDesc ArrowDesc ArrowDesc ArrowDesc.
La classe SEditCompoundType La classe SEditCompoundType La classe SEditCompoundType La classe SEditCompoundType : cette classe sert uniquement à implémenter les méthodes abstraites des super classes MIMOSA dont elle hérite : elle hérite de la classe MIMOSA CompoundType CompoundType CompoundType CompoundType. De cette classe hérite la classe Formalism Formalism Formalism Formalism.
La classe SEditComponent a classe SEditComponent a classe SEditComponent a classe SEditComponent : cette classe implémente l’interface SElement SElement SElement SElement et hérite de la classe MIMOSA Component Component Component Component. De cette classe hérite la classe SNode SNode SNode SNode.
La classe SEditIntraCompoundRelation La classe SEditIntraCompoundRelation La classe SEditIntraCompoundRelation La classe SEditIntraCompoundRelation : cette classe implémente l’interface SElement SElement SElement SElement et hérite de la classe MIMOSA IntraCompoundRelation IntraCompoundRelation IntraCompoundRelation IntraCompoundRelation. De cette classe hérite la classe SArrow SArrow SArrow SArrow.
La classe SEditCompound La classe SEditCompound La classe SEditCompound La classe SEditCompound : cette classe sert uniquement à implémenter les méthodes abstraites des super classes MIMOSA dont elle hérite : elle hérite de la classe MIMOSA Compound Compound Compound Compound. De cette classe hérite la classe Structure Structu

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Avant—-propos 3
Table des illustrations
Introduction
Chapitre I. Modélisation et systèmes multi
I. Modélisation et systèmes multi—-agents agents agents agents
A. La modélisation
B. Le modèle
C. La modélisation informatique
D. Les systèmes multi-agents
1. Qu’est ce qu’un agent ?
2. Les systèmes multi-agents
3. Pourquoi parler des systèmes multi-agents ?
E. Les plateformes de modélisation et simulation existantes
F. La plateforme MIMOSA
Chapitre II. Les outils
A. La programmation orientée objet (POO)
B. Le langage Java
C. Le formalisme UML C
1. Le diagramme de classes
a) Les classes
b) Les associations
c) Les agrégations
d) Les compositions
e) La généralisation
2. Le diagramme de cas d’utilisation
a) Les acteurs
b) Les cas d’utilisation
c) La relation d’inclusion
3. Le diagramme de séquence
a) Les interactions
b) Les activations et envois de messages
D. Le format XML D. Le format XML D. Le format XML D. Le format XML
1. Le fichier XML
2. La DTD
3. Les API Java pour XML
4. L’API SAX
5. L’ API DOM
6. L’avantage du SAX
Chapitre III. Dossier technique Chapitre
A. La notion d’éditeur de modèle
B. Ce qu’il s’agit de faire B. Ce qu’il s’agit de faire B. Ce qu’il s’agit de faire B. Ce qu’il s’agit de faire
C. Généricit C. Généricit C. Généricit C. Généricité, boites à outils, formalismes é, boites à outils, formalismes é, boites à outils, formalismes é, boites à outils, formalismes
1. Concepts de modèles, abstractions et définitions
a) Notions structurelles et notions dynamiques
b) La boite à outils MIMOSA
c) La boite à outils S-Edit
d) Résultats des jeux : même boite à outils ?
2. Implémentations
a) Implémentation de la boite à outils MIMOSA
b) Implémentation de la boite à outils S-Edit
3. Sauvegarde des modèles
a) Sauvegarde des modèles MIMOSA
b) Sauvegarde des modèles S-Edit
c) Comparaison
4. Bilan.
Chapitre IV. Edition de modèles MIMOSA
A. Assimilations
B. Assimilation par héritage et interfaçage
1. Description
2. Implémentation
3. Dépendances
4. Protocole de description : création de catégories S-Edit
5. Sauvegarde XML
6. Bilan de l’assimilation par héritage
C. L’assimilation par délégation
1. Description
2. Implémentation
3. Dépendances
4. Bilan de l’assimilation par délégation
Chapitre V. Conclusion et perspectives
A. Résumé
B. Fonctionnalités supplémentaires
C. Développement de la plateforme
D. Conclusion
Annexe A. Bibliographie
Annexe B. DTD des fichiers XML de description de formalismes S—-Edit
Annexe C. Guide utilisateur de l’éditeur de modèles MIMOSA
Index