Implantation et Expérimentations
5. Graphe M Général : Général
Diagramme_État État Conn_Message Condition Transition_État Action R18 R19 R20 R21 Transition_État
Figure 5.33 - A2M-OOA’ - Modèle Dynamique - Graphe (MD)Spéc-Concepts
4. Graphe M Dynamique : (MD)Spéc-Associations
La figure 5.34 présente la sémantique des relations utilisées pour décrire la dy-namique dans OOA’. Le lienConn MessageentreClassesreprésente la de-mande d’un service d’une classe à une autre. Entre uneClasseet unObjet, il représente l’instanciation d’un objet.
État État Objet Classe Classe Classe Transition_État R22 R23 R24 R25 R26 R27 Conn_Message Conn_Message
Figure 5.34 - A2M-OOA’ - Modèle Dynamique - Graphe (MD)Spéc-Associations
5. Graphe M Général : Général
Le seul lien sémantique entre concepts différents existants dans OOA’ est pré-senté dans la figure 5.35 et montre qu’unObjetest lié à unDiagramme Etat.
, Objet Diagramme_État R28
Spécification Formelle
Une partie de l’“image formelle” du modèle créé lors du processus de méta-modélisation exécuté avec l’atelier A2M est présentée dans la figure 5.36. Dans cette figure nous pouvons voir le schéma S Spécification pour le graphe (MO)Spéc-Concepts(cf. figure 5.31). Tous les concepts et liens existants entre ces concepts pour ce graphe sont représentés.
Figure 5.36 - A2M-OOA’ - Spécification Formelle pour (MO)Spéc-Concepts
Spécification Informelle
Dans la figure 5.37 nous pouvons voir la spécification informelle attachée au sous-graphe(MO)Spéc-Conceptsdu grapheS Statique.
5.3 Des Études de Cas 155
Figure 5.37 - A2M-OOA’ - Spécification Informelle pour (MO)Spéc-Concepts
Atelier A2M’
La finalisation de la méta-modélisation qui doit être exécutée avec l’atelier A2M’ ne sera pas présentée ici car elle est du même genre que celle exécutée pour la méthode OMT’ (cf. page 146). Comme pour la méthode OMT’, il faut ajouter la forme des concepts déclarés dans A2M ainsi que quelques concepts GraphTalk nécessaires à la génération, par l’atelier A2M’, d’un atelier AM compatible avec la méthode OOA’.
5.3.2 Cadre pour la Comparaison des Méthodes
Dans la section 3.2.5, nous avons comparé quatre méthodes orientées objets à l’aide de tables. La réflexion sur cette comparaison (cf. section 3.2.5.5) présente quelques travaux qui utilisent un méta-modèle pour la comparaison des méthodes dans la mesure où cette comparaison est rendue plus facile lorsqu’une approche basée sur les méta-modèles est uti-lisée. Dans cette section, nous utilisons des concepts de notre méta-modèle afin d’illustrer une comparaison des méthodes. Cette illustration porte sur les méthodes OMT’ et OOA’ méta-modélisées dans la section 5.3.1.
L’utilisation d’un méta-modèle pour la comparaison de méthodes a été proposée par di-vers auteurs. Nous pouvons citer par exemple le travail de G. Eckert et P. Golder [EG93]. Dans ce travail, après une analyse textuelle mettant en évidence les aspects de l’analyse et de la spécification d’un système, chaque méthode est représentée et étudiée graphiquement par un diagramme entité-relation des concepts employés. Une table est utilisée ensuite pour comparer les méthodes. Pour finir G. Eckert et P. Golder proposent une “méthode globa-le” (le méta-modèle) qui utilise ou perfectionne les concepts des méthodes orientées objet étudiées.
Un autre travail qui utilise l’approche des méta-modèles est celui de S. Hong, G. Goor et S. Brinkkemper [HvdGB93]. Après avoir introduit chacune des méthodes par un texte bref, celles-ci sont présentées à travers d’une part un modèle graphique de données (un diagramme entité-relation), d’autre part un modèle graphique de la procédure de dévelop-pement (un diagramme de flux). Les auteurs suggèrent que toutes les méthodes peuvent être considérées comme des sous-modèles d’un méta-modèle général et comparent, à l’aide de tables, chaque méthode étudiée par rapport à ce méta-modèle.
Nous proposons ici une approche semblable basée sur la création automatique d’un méta-modèle général (le méta-méta-modèle) pour les modèles de méthodes orientées objets. Il est possible de créer, à l’aide de l’atelier A2M, un tel méta-méta-modèle afin de décrire la méthode globale dans laquelle tous les concepts proposés par les modèles des méthodes à comparer sont présents.
Même si on ne présente pas ici un exemple complet pour illustrer cette approche (un tel méta-méta-modèle complet peut être inféré du processus de méta-modélisation des mé-thodes OMT’ et OOA’), on peut cependant démontrer l’utilité d’une telle approche en ana-lysant les concepts d’une partie du modèle dynamique (les diagrammes d’états) de deux méthodes.
Cette approche de création automatique d’un méta-méta-modèle général est basée sur la compréhension de la sémantique des modèles de chaque méthode : les diagrammes d’états d’une méthode peuvent aussi s’appeler diagrammes de transitions d’états dans une autre méthode. La création du méta-méta-modèle doit donc être exécutée sous contrôle humain. Un processus de guidage de la construction du méta-méta-modèle peut être créé dans notre atelier à l’aide de démons : après une première génération semi-automatique des concepts présents dans les deux méta-modèles et possédant la même sémantique et le même nom (ex : le concept Classe), le processus de construction du méta-méta-modèle est achevé manuelle-ment sous contrôle humain.
La figure 5.38 présente un méta-méta-modèle des méta-modèles des diagrammes d’états de deux méthodes issus de l’atelier A2M lors de la méta-modélisation d’OMT’ et d’OOA’. Les éléments encadrés en ligne pleine sont communs aux deux méthodes ; les éléments encadrés en pointillé sont propres à la méthode OOA’ ; les autres sont propres à la méthode OMT’.
5.3 Des Études de Cas 157 Diagramme_État Transition_État État_Initial État État_final R19 R20 R21 Conn_Message Condition Action R18 R20 R21 Transition_État OOA’ OMT’ OMT’-OOA’
Figure 5.38 - Comparaison OMT’/OOA’ - Diagramme d’États
Ci-dessous, en analysant la figure 5.38, nous faisons quelques remarques sur la compa-raison de méthodes.
– quelques éléments utilisés par les deux méthodes sont communs et d’autres complé-mentaires. Les éléments communs aux deux méthodes, et qui peuvent alors être gé-nérés automatiquement dans un méta-méta-modèle commun sontÉtat, Transi-tion ÉtatetDiagramme État;
– la méthode OOA’ offre un cadre plus étendu que la méthode OMT’ pour utiliser les conditions/actions dans les diagrammes d’états. En regardant la figure on peut re-marquer que seulement la méthode OOA’ attache des conditions et des actions aux transitions d’états ;
– même si la figure fait croire que la représentation de la dynamique dans la méthode OOA est plus complète que dans OMT, ce n’est pas le cas. En réalité, les diagrammes de transition d’états de la méthode OMT complète sont plus complexes que ceux présentés pour OMT’, et en plus, la méthode OMT utilise un autre diagramme pour la dynamique, le modèle fonctionnel, qui n’existe pas dans OOA. Cette vue fonctionnelle dans OOA est représentée uniquement par les connexions de messages.
Nous devons prendre en compte le fait que l’analyse présentée ici est basée sur des mo-dèles restreints des méthodes OMT’ et OOA’, et que le méta-méta-modèle cité en exemple dans la figure 5.38 est un reflet de ces modèles. L’analyse de la figure 5.38 permet seulement
une “comparaison visuelle” des deux méthodes. En utilisant la totalité du méta-modèle pro-posé (les trois approches : semi-formelle, informelle et formelle), on peut avoir un cadre de comparaison plus complet et plus rigoureux.
Il est clair qu’aujourd’hui une bonne définition d’une méthode passe par la description du méta-modèle de chacun de ses modèles. C’était l’un des handicaps de la première version d’OMT : le premier ouvrage était très déclaratif et ne contenait aucun méta-modèle.
5.3.3 Multi-Modélisation avec la Méthode OMT
Le processus de méta-modélisation conduit sous les ateliers A2M et A2M’ a pour but la génération d’un atelier AM particulier à une méthode. On présente ici le résultat du proces-sus de méta-modélisation de la méthode OMT’ de la section 5.3.1.
La définition de l’hyper-graphe composé des trois graphes Modèle Objet, Diagramme Etat etModèle Fonctionnel (cf. figure 5.27) génère un ate-lier AM où ces trois modèles sont les graphes de base autour desquels une modélisation est construite (cf. fenêtre “Atelier OMT - Essai” de la figure 5.39).
5.3 Des Études de Cas 159
Les éléments offerts par chacun de ces graphes pour la modélisation d’un système sont ceux qui ont été déclarés dans l’atelier A2M’ pour chacun des modèles, soit dans la par-tie spécification sémantique, soit dans la parpar-tie spécification des fenêtres (à travers une action). Ainsi, on a pour le modèle objet le nœud Classe, pour le diagramme d’états les nœuds État, État Initial et État Final et pour le modèle fonctionnel les nœuds Processus, Acteur et Mémoire (cf. fenêtres “Modèle Objet - MO Essai”, “Diagramme État - DE Essai” et “Modèle Fonctionnel - MF Essai” de la figure 5.39).
Les formes déclarées dans l’atelier A2M’ pour les composants de la méthode OMT’ sont celles présentées dans les fenêtres de la figure 5.39. La sémantique des liens est déclarée dans A2M et adaptée dans A2M’.
Dans la fenêtre “Modèle Objet - MO Essai”, on peut voir aussi la raison pour laquelle il est nécessaire de rajouter le dispatcher à la définition de la sémantique du lien entre les conceptsClasseetHéritage(cf. figure 5.28) : cela permet la construction de structures arborescentes comme la structure d’héritage présentée dans la fenêtre.
Ces aspects (modèle objet, diagramme d’états, modèle fonctionnel) constituent la forme la plus courante de multi-modélisation : modélisation d’un SI à l’aide de plusieurs modèles à coordonner.
Le processus de modélisation sous l’atelier AM génère aussi une spécification formelle de cette modélisation à travers les éditeurs syntaxiques qui ont été présentés à la section 5.2.1.3. Dans ce processus de modélisation nous pouvons aussi gérer des spécifications in-formelles. Dans la figure 5.40 nous présentons ces deux types de spécifications correspon-dant aux exemples de la figure 5.39. Nous pouvons voir la spécification formelle, donnée par la partie du schéma S Global qui modélise l’arbre d’héritage H1ainsi que la spécification informelle, donnée par la remarque textuelle à propos de cet arbre.
La deuxième forme de multi-modélisation, celle qui combine et coordonne des modéli-sations informelles, semi-formelles et formelles n’est pas présente dans la plupart des ate-liers commerciaux. Elle est offerte par notre atelier à travers les interactions possibles entre les quatre types de schémas S Global, S Concepts, S Spécifications et S Remarques.
La prochaine section présente une application de l’atelier OMT’ générée à travers son utilisation par le Gestionnaire de Modèles pour la modélisation de STORM. Cette utilisation introduit une illustration de spécifications formelles et informelles coordonnées avec des spécifications semi-formelles.
5.3.4 Modélisation de STORM
Le processus qui, partant de la méta-modélisation d’une méthode avec l’atelier A2M, arrive à la génération d’un atelier AM pour cette méthode, a pour but d’offrir l’outil de base du Gestionnaire de Modèles de l’atelier de modélisation proposé. En fait, c’est à partir des modèles semi-formels, informels et formels générés par l’atelier AM et gérés par le Gestion-naire de Modèles que l’atelier de modélisation peut construire un document de spécification global.
Le modèle STORM est un modèle basé sur une approche objet [Adi95] qui propose une solution aux problèmes de modélisation et de gestion des données multimédias (image, texte, audio et vidéo) dans le cadre d’un SGBD orienté objet. Ce modèle est présenté en détails dans l’Annexe E.
Nous présentons, dans cette section, un document de spécification globale pour une par-tie du modèle STORM ; cette parpar-tie comprend la “Structure Algébrique” du modèle STORM telle qu’elle est présentée dans l’Annexe E (cf. figure E.5).
La construction d’un document de spécification globale pour un système passe toujours par un processus de multi-modélisation de ce système exécuté avec l’atelier AM. Pour arri-ver à la présentation d’un document de spécification globale pour la structure algébrique du modèle STORM, on doit donc utiliser l’atelier AM-OMT’ afin de générer les composants de cette spécification.
Le processus de modélisation semi-formelle d’un système conduit sous AM-OMT gé-nère en même temps sa spécification formelle. La fenêtre “Modèle Objet - Struc Algébrique” de la figure 5.41 présente une reproduction de la structure algébrique présentée dans la figure E.5. La construction de cette modélisation produit la spécification formelle représentée dans la fenêtre “gclasseZ - STORM.le”. Cette fenêtre correspond au schéma S Global qui représente la vue Modèle Formel du méta-modèle proposé. On ne présente pas
5.3 Des Études de Cas 161
la partie introductive où les types de bases et les relations utilisés dans la spécification sont déclarés. On peut voir dans cette fenêtre la spécification formelle des éléments modélisés de manière semi-formelle dans la fenêtre “Modèle Objet - Struc Algébrique”. Ainsi, on a la déclaration formelle des classes, des liens, des deux structures d’héritage et de la struc-ture d’agrégation. On peut voir aussi une spécification informelle donnée par la remarque textuelle qui est déclarée pour la structure d’héritageH1.
Figure 5.41 - Structure Algébrique de STORM - Modélisation avec AM-OMT
La fenêtre “Modèle Objet - Struc Algébrique” montre aussi le contrôle de vues dans l’atelier. Cela est réalisé avec le composant Vues, élément à travers lequel est réalisé le
lien entre le Gestionnaire de Modèles et le Gestionnaire de Documents. Dans cette fe-nêtre deux vues sont définies, l’une qui englobe les classes Tree, TerminalNode et OperatorNode (la vue Str H1) et l’autre qui englobe les classes OperatorNode, ParNodeetSeqNode. Lorsqu’on définit une vue dans l’atelier, on doit choisir les classes qui font partie de cette vue à travers leur sélection avec la souris. Ainsi tous les liens ainsi que toutes les structures auxquels ces classes participent sont rattachés aussi à la vue. Grâce à cela, et au choix des classes, la vue Str H1 est composée des classes Tree, TerminalNodeetOperatorNodedu lienparticipe aet des structuresH1etA1. La vueStr H2est composée des classesOperatorNode, ParNodeetSeqNodeet de la structureH2. Le lienparticipe an’en fait pas partie car la classeTerminalNode n’est pas définie dans la vue.
Figure 5.42 -Structure Algébrique de STORM - S Spécification de la Classe TerminalNode
À chaque fois qu’une classe est déclarée dans le modèle semi-formel, l’atelier AM-OMT’ lui attache automatiquement une spécification formelle basée sur le langage Object-Z, grâce à un démon déclenché systématiquement lorsqu’une classes est créée. Cette
spécifi-5.3 Des Études de Cas 163
cation formelle est gérée avec l’éditeur syntaxique LEdit et constitue un simple squelette de schéma Object-Z qui doit ensuite être complété. Elle présente cependant tous les élé-ments déclarés dans le langage. La figure 5.42 présente une telle spécification pour la classe TerminalNodede la structure algébrique (cf. figure 5.42).
Après avoir créé les modélisations présentées ci-dessus avec l’atelier AM-OMT, on est prêt pour la production du document de spécification globale qui est construit par l’atelier de modélisation. La figure 5.43 présente une fenêtre qui montre le document de spécification globale pour une partie de la Structure Algébrique du modèle STORM qui a été modélisée (cf. figure 5.41). Dans ce document de spécification globale, la partie modélisée correspond à la vueStr H1qui a été définie dans le modèle semi-formel.
Dans cet exemple, deux relations entre fragments de modélisation ont été utilisées : expliquer une modélisation semi-formelle par un texte informel et transformer une modéli-sation semi-formelle en spécification formelle.
5.4 Conclusion
De nombreux facteurs freinent l’utilisation des ateliers de modélisation, en particulier, leur prix et leur spécialisation vis-à-vis d’une méthode. Ce dernier facteur a beaucoup évolué depuis le début des années 90 avec le développement d’ateliers intégrant un méta-référentiel pour proposer des interfaces pour différentes méthodes. Mais ces ateliers ont cependant deux limites fortes. D’une part, ils permettent rarement de combiner, pour un même SI, des modélisations selon des méthodes différentes, et d’autre part, ils ne sont pas adaptés à la coordination de spécifications semi-formelles, formelles et informelles.
Un atelier construit avec des outils existants peut d’une certaine manière contourner le problème de coût. L’atelier de modélisation, dont l’implantation et l’utilisation ont été traitées dans ce chapitre, utilise d’autres outils dans la construction d’un nouvel atelier de modélisation. Ces outils ont été présentés au début du chapitre afin de démontrer leurs ca-pacités.
L’aspect multi-méthodes a été pris en compte par l’implantation de l’atelier de modé-lisation dont l’architecture a été présentée à la section 4.3. Cette architecture est basée sur deux gestionnaires (un de modèles et un autre de documents). Cette implantation est ensuite détaillée selon chacun des outils présentés antérieurement en offrant deux niveaux d’utilisa-tion : méta-modélisad’utilisa-tion et multi-modélisad’utilisa-tion. Ces deux niveaux permettent d’intégrer des spécifications formelles aux spécifications semi-formelles et informelles.
P. Facon et R. Laleau [FL95] présentent une classification de la manière dont les spéci-fications semi-formelles sont “transformées” en spécispéci-fications formelles. Selon les auteurs deux processus existent :
– la compilation : à travers un guide méthodologique, une traduction entre les deux types de spécifications est produite, soit manuellement, soit avec un assistant (“un outil qui génère un squelette de spécification formelle à compléter) ;
– l’interprétation : la traduction s’exécute en passant par la définition d’un méta-modèle formel du système d’information, où les concepts de celui-ci sont définis avec des types abstraits, des ensembles, etc ; après la définition de ce méta-modèle, les concepts du système d’information sont modélisés par rapport à ce méta-modèle.
5.4 Conclusion 165
L’approche proposée dans ce travail utilise, d’une part, la traduction automatique pour la génération d’un squelette conformément à un méta-modèle (les types de base Concept, Relation, Propriété et Modèle ainsi que la définition des structures et des relations) et, d’autre part, une interprétation de ces spécifications toujours autour d’un méta-modèle.
L’utilité d’un tel atelier est ensuite présentée à travers d’études de cas. On présente quatre exemples d’utilisation de l’atelier à deux niveaux différents. Un AGL dédié à la méthode OMT est utilisé pour la production partielle du document de spécification globale pour le modèle STORM. Cet exemple permet d’illustrer les capacités de notre prototype d’atelier à combiner simplement des modèles graphiques, textuels et formels, d’une part dans la mo-délisation d’une méthode (OMT) et d’autre part dans la momo-délisation d’un système d’infor-mation (STORM).