Affectation des propriétés : cette partie sert à déclarer les propriétés qui peuvent être attachées à tous les concepts et relations définis dans la spécification sémantique. Les

propriétés ne peuvent pas être attachées à n’importe quel type de concept ; chaque concept a des types de propriétés qui lui sont propres.

3. Spécification des formes : GraphTalk étant un méta-éditeur de formalismes gra-phiques, cette partie sert à spécifier les formes externes que doivent avoir chacun des composants d’une modélisation lors de l’utilisation d’une instance de l’atelier généré. On peut aussi attacher des propriétés à ces formes (ex : une propriété texte qui définit le nom d’un concept).

4. Spécification des fenêtres : la spécification de l’interface homme-machine particu-lière à l’AGL créé est déclarée. Ici, on peut définir les menus de l’atelier, attribuer des actions particulières aux composants de l’atelier, créer des sous-menus, etc.

La figure 5.1 présente le méta-outil GraphTalk avec deux de ses fenêtres. La fenêtre “GraphTalk - Essai” est la fenêtre principale de l’outil et la fenêtre “GraphTalk - Test” une instance du modèle unique GraphTalk de la fenêtre principale.

Le modèle unique GraphTalk fait en sorte de garder une compatibilité avec d’anciennes versions de l’outil ; il comporte la totalité des composants des quatre autres parties. La fenêtre “GraphTalk - Test” présente les composants de base (entité, graphe, lien, etc.) offerts par l’outil pour la modélisation d’une méthode. On peut voir aussi les types de propriétés (association, booléen, nombre, etc.) et les actions (menu, requête, etc.) qu’on peut attacher aux composants d’une modélisation.

L’utilisation de GraphTalk se fait à deux niveaux différents : le niveau méta-modélisation où est créé l’AGL propre à une méthode et le niveau modélisation où un modèle d’un SI est créé en utilisant l’AGL.

La méta-modélisation est réalisée avec un langage graphique de type méta-langage dans lequel sont pré-définies par GraphTalk quatre méta-classes : objet, lien, dispatcher et pro-priété. Autour des instances de ces méta-classes, est construit le méta-modèle qui décrit une méthode en offrant le cadre de l’AGL généré.

5.1 Les Outils Utilisés 121





Figure 5.1 - Méta-Outil GraphTalk

Dans la figure 5.1, on peut voir, dans le menu Classes, des instances de la méta-classe objet : Hyper(qui représente un modèle d’une méthode dans sa totalité en tant que composé d’autres modèles),Graphe(qui représente les modèles d’une méthode),Entité (qui sert à factoriser des comportements communs à différents composants d’une modélisa-tion),Objet(qui sert à déclarer les concepts qui font partie d’une méthode) etMéthode (équivalent des méthodes ou fonctions de la programmation orientée objet). La méta-classe lien, appelée Lien, permet la définition de la sémantique des relations entre instances de la méta-classe objet ; elle peut avoir, comme instances, différents types de liens : héritage, composition, connexion, etc. La méta-classe Dispatcherreprésente un type particulier de lien et permet la création d’arbres. Les composants du menuClassessont appelés gé-néralement, les nœuds d’une modélisation. Dans la fenêtre “GraphTalk - Test” de la figure 5.1, on peut voir aussi la notation utilisée par ces nœuds dans GraphTalk.

De plus, la figure 5.1 présente les différentes instances de la méta-classe propriété. Ces instances peuvent être attachées aux nœuds d’une modélisation. Nous présentons ci-dessous quelques unes de ces propriétés. La propriété Textepar exemple, lorsqu’elle est attachée

à un nœud, ajoute un attribut de type texte à ce nœud. C’est une propriété de ce type qu’on utilise lorsqu’on veut définir qu’un nœud a un composant de nature spécification informelle. La propriété Objets sert à déclarer qu’un nœud est composé d’autres nœuds ; c’est le cas par exemple d’une classe avec ses attributs et ses opérations. Pour finaliser, nous citons la propriétéTexte structuréqui est utilisée pour faire le lien entre une spécification semi-formelle (un modèle GraphTalk) et une spécification formelle (un éditeur LEdit). Le fait d’attacher une telle propriété à un nœud d’un modèle GraphTalk permet simplement de déclarer le lien. Pour mettre en place la conversion GraphTalk-LEdit et vice versa, ainsi que pour assurer la cohérence entre les deux représentations, il est nécessaire de définir des démons (modules de programmes) qui exécuteront cette transformation.

L’optionActiondu sous-menuClassesest présentée aussi dans la figure avec ses composants. C’est avec ces composants que nous pouvons redéfinir l’interface homme-machine proposée dans un atelier généré par GraphTalk. Comme exemple, nous pouvons citer les Sous menu standardset lesActions standards qui permettent la re-définition des composants standards de l’interface homme-machine et l’action Action, à travers laquelle nous pouvons faire appel à des “démons” écrits en C/C++. Ces démons peuvent utiliser l’API GraphTalk afin d’augmenter la puissance du méta-outil. Enfin, l’ac-tionRequêtepermet la réalisation de requêtes sur les composants d’une modélisation, en utilisant le langage GQL (similaire a SQL) qui est propre à GraphTalk.

5.1.2 LEdit

Le méta-outil LEdit [Par94] est un méta-éditeur qui offre une interface de programma-tion utilisable lors de la définiprogramma-tion d’un éditeur syntaxique pour des langages définis par des grammaires en BNF (cf. figure 5.2). L’intégration de GraphTalk et LEdit dans un en-vironnement de méta-outils permet au développeur d’AGL de spécifier respectivement les représentations graphiques et les représentations textuelles de l’outil qui est créé.

Dans la figure 5.2, la fenêtre “ledit - ledit.le” présente la définition syntaxique de l’édi-teur affiché dans la fenêtre “ledit - Essai”. La grammaire d’un langage en LEdit du type BNF (“Backus Naur Form”). Il existe aussi un autre éditeur appelé REdit qui sert à la défi-nition de l’interface homme-machine. À travers REdit, on peut aussi attacher des actions à des nœuds particuliers de la grammaire de la même façon qu’on le fait sur les nœeuds des graphes décrits sous GraphTalk.

5.1 Les Outils Utilisés 123







 Figure 5.2 - Méta-Outil LEdit

Le méta-outil LEdit permet de décrire les langages cibles dans le cas d’une génération de code à partir d’un modèle de SI : comme par exemple, une génération de code de type sque-lettes de classes C++, ou langage de définition de données pour un environnement SGBD, ou enfin dans notre contexte squelettes de schémas Z ou Object-Z.

5.1.3 Thot

L’outil Thot est un éditeur de documents structurés. Dans le cadre de l’atelier présenté dans ce travail, il fonctionne comme éditeur hyper-texte à travers lequel un texte descriptif peut accéder aux différentes modélisations. Dans ce prototype d’atelier, il accomplit la tâche de regrouper les trois types de modélisation (informelle, semi-formelle et formelle). En tant qu’éditeur hyper-texte, on peut le classer comme étant du type rédaction (“authoring”) et non navigation (“browsing”), selon l’une des dimensions de la classification proposée par F. G. Halasz [Hal88], dans la mesure où on va l’utiliser pour la composition d’un document de spécification.

L’utilisation de l’éditeur Thot passe par la définition de deux types de schémas différents, qui sont présentés ci-dessous.

Schéma de Structure

Ces schémas spécifient principalement les types des éléments utilisables et les rela-tions qui peuvent les relier [QRRV95] ; ils définissent une structure hiérarchique dont les éléments terminaux sont du texte, des images, des graphiques, etc. Ces schémas sont définis avec le langage S offert par l’outil. En utilisant ce schéma de structure, l’utilisateur peut construire un document qui suit une structure logique pré-définie.

La figure 5.3 présente un exemple d’un schéma de structure. Un document créé se-lon la structure hiérarchique présentée dans la figure, est composé par un En-tête composé d’un Titre, d’une liste d’Auteurset d’un Résumé. Après l’en-tête, le Corps du document est composé d’unPréambule et d’une Suite sections. Il faut noter que cette définition n’est pas complète car il manque la définition de plusieurs composants (Auteur, Paragraphe, etc).

STRUCTURE Rapport ; DEFPRES RapportP ; ATTR

Réservé = Integer ; STRUCT

Rapport (ATTR Numéro page = Integer ; BEGIN

En-tête =

Titre = Contenu ;

Auteurs = LIST OF (Auteur) ; Résumé = LIST OF (Paragraphe) ; END ;

Corps = BEGIN

Préambule = Suite paragraphes ; Suite sections ;

END ; END ;

5.1 Les Outils Utilisés 125

Schéma de Présentation

Ces schémas spécifient comment chacun des composants d’un document doit être présenté. Les schémas de présentation sont décrits en langage P offert par l’outil.

Le schéma de présentation (cf. figure 5.4) définit la présentation des composants du schéma de structure ; il déclare aussi entre autres, quelles vues (sous-documents) se-ront présentées et quels documents sese-ront proposés à l’impression. Les compteurs d’un document (numéro de page, numéro de section, etc.) sont aussi déclarés ici. C’est avec les BOXES que le schéma de présentation définit effectivement la forme des éléments d’un document. Dans la figure 5.4, on peut voir ainsi la forme que doit avoir leTitred’un document.

PRESENTATION Rapport ; VIEWS

Texte integral, Table des matières ; PRINT

Texte integral, Table des matieres ; COUNTERS

CptSect1 : Rank of Section 1 Init Numéro prem section ; BOXES

BoiteTitre : BEGIN

Content : Text ’Titre haut de page : ’ ; Style : Bold ;

Font : Creator = ; Size : Creator = ; END ;

Figure 5.4 - Thot - Exemple de Schéma de Présentation

Les deux exemples de schémas, des figures 5.3 et 5.3, sont des simplifications du schéma Rapport fourni avec l’outil. La figure 5.5 présente un document vierge qui utilise les définitions des schémas ci-dessus. On peut voir, dans cette figure, la fenêtre principale de l’éditeur ainsi que les trois vues différentes qui sont définies dans le schéma de présentation.

 Figure 5.5 - Éditeur et Méta-Éditeur Thot

L’interface de programmation et son mécanisme d’appels externes sont conçus pour fa-ciliter une intégration à d’autres applications ; c’est la raison principale du choix de l’utili-sation de Thot comme composant de l’atelier.

5.2 La Réalisation d’un Prototype d’Atelier

Cette section décrit comment l’atelier a été développé grâce aux outils présentés à la section 5.1 et en respectant le méta-modèle proposé à la section 4.2.

5.2.1 Le Gestionnaire de Modèles

Le Gestionnaire de Modèles est adapté aux différents niveaux de modélisation (méta-modélisation et multi-(méta-modélisation) à travers trois ateliers : A2M, A2M’ et AM. On ne présente dans cette section que des détails de l’implantation de l’atelier A2M, car les deux autres ateliers sont générés à partir de la modélisation initiale produite par A2M pour une méthode spécifique. Dans la section 5.3.1, l’atelier A2M’ est décrit lors de la présentation

5.2 La Réalisation d’un Prototype d’Atelier 127

d’un exemple de méta-modélisation pour les méthodes OMT et OOA. L’atelier AM est illustré dans la section 5.3.3 avec un exemple de multi-modélisation de la méthode OMT.

5.2.1.1 L’Atelier A2M

L’atelier A2M est utilisé dans la modélisation de méthodes orientées objets. Il est construit avec six graphes différents que nous générons sur GraphTalk pour guider ce processus de modélisation en l’adaptant au méta-modèle proposé (cf. section 4.2). Ces graphes sont défi-nis à partir des types de graphes offerts par l’outil GraphTalk : GraphTalk, Spécification sé-mantique, Affectation des propriétés, Spécification des formes et Spécification des fenêtres (cf. fenêtre “GraphTalk - Essai” de la figure 5.1).

Le premier graphe, de type GraphTalk est utilisé pour donner une vue de l’ensemble des modèles utilisés. Les graphes de type Spécification sémantique, sont utilisés pour déclarer les composants de l’atelier ainsi que les relations entre ces composants. Les graphes de type Affectation des propriétés, sont utilisés pour déclarer les propriétés des composants. Le cinquième, de type Spécification de formes, est utilisé pour définir la notation que les composants de l’atelier généré devront respecter. Finalement, le dernier graphe, de type Spécification de fenêtres, est utilisé dans la définition de l’interface homme-machine de l’atelier qui sera généré.

Nous présentons ci-dessous, chacun de ces six graphes. Ils ne sont pas décrits avec tous leurs composants. Seules les parties les plus importantes pour la compréhension y sont in-troduites.