Un Nouvel Atelier de Modélisation
4.5 Des Relations entre Éléments de Modélisation
Dans cet exemple, le niveau Modélisation décrit l’utilisation de l’atelier de modélisa-tion AM généré à travers la présentamodélisa-tion du schéma S Concept qui montre trois classes, Véhicule, Voiture et Camion, liées par une structure d’héritage. Le schéma S Spécification montre une partie du schéma S Global pour le schéma S Concept. Pour simplifier, la spéci-fication des classes n’est pas présentée.
Nous reviendrons sur ces différents éléments lors de la présentation de la réalisation de notre atelier (cf. chapitre 5).
4.5 Des Relations entre Éléments de Modélisation
Les deux modules principaux de l’atelier Gestion de Modèles et Gestion de Documents interagissent avec des spécifications de types différents : informelle, semi-formelle ou for-melle. Les relations entre ces différents types de spécifications ainsi que les relations entre ces types de spécification et les modules sont développées dans les sections suivantes.
Ces relations sont essentielles dans la perspective d’une multi-modélisation introduite pour utiliser à un moment donné, pour un comportement donné d’un système donné, la forme de modélisation la mieux adaptée.
Dans un premier temps, les relations existantes entre les trois types de spécifications sont traitées dans l’optique du gestionnaire de modèles et ensuite ce sont les relations entre ces spécifications et les modules de l’atelier.
4.5.1 Relations entre Modèles
Cette section présente des types de relations pertinentes entre des fragments de spécifi-cation des trois approches de modélisation (cf. figure 4.13). Dans l’optique du méta-modèle proposé (section 4.2), ces relations existent entre différents schémas S Concept, S
Spécifica-tion et S Remarque d’un même modèle : ces relaSpécifica-tions maintiennent une “orientaSpécifica-tion
hori-zontale” car S Concept, S Spécification et S Remarque modélisent le même sujet.
Les flèches de la figure 4.13 expriment les types utiles de relations. Ces flèches partent de la Modélisation Source vers la Modélisation Résultat.
Semi-Formelle Spécification Informelle Spécification Formelle Spécification 1. Expliquer 2. Compléter 7. Expliquer 8. Compléter 3. Transformer 4. Transformer 5. Compléter 6. Vérifier 9. Grouper
Figure 4.13 - Des Relations entre Spécifications
Par Modélisation Source, on entend la modélisation sur laquelle porte l’acte exécuté par la relation et, par Modélisation Résultat, on veut dire la modélisation qui présente le résultat de l’exécution de l’acte. Par exemple, la flèche 1 exprime le fait que la spécification informelle (la Modélisation Résultat) explique une spécification formelle (la Modélisation Source) et la flèche 4 exprime le fait qu’une spécification semi-formelle est transformée en une spécification formelle.
La table 4.2 présente pour chaque relation de la figure 4.13 différentes informations : (a)
pourquoi ces relations existent, (b) comment elles sont implantées dans l’atelier, un bilan
(c) qui présente s’il peut exister une perte “P”, un ajout “A” ou si rien ne se passe “-” entre l’information de la Modélisation Résultat et la Modélisation Source lorsqu’on change de représentation ; (d) le type de la relation. La notion d’ajout ou perte d’information est fortement liée à la cohérence de la modélisation.
4.5 Des Relations entre Éléments de Modélisation 109
“Rel” Pourquoi Comment “Bilan” Type
1 expliquer les aspects d’une mo-délisation formelle.
génération de “notes textuelles” créées avec le gestionnaire de modèles.
- expliquer
2
compléter les aspects d’une mo-délisation formelle qu’on n’ar-rive pas ou qu’on ne souhaite pas représenter formellement.
introduction de “notes textuel-les” créées avec le gestionnaire de modèles.
A compléter
3
fournir une “image” de la spéci-fication semi-formelle, laquelle se traduit par une spécifica-tion formelle qui correspond à la spécification semi-formelle d’origine.
génération d’une spécification formelle à travers la passerelle GraphTalk/LEdit.
P transformer
4
maintenir la cohérence entre la spécification semi-formelle et la spécification formelle en chan-geant cette dernière, à chaque fois qu’un changement s’opère sur la première.
mise à jour d’une spécifica-tion formelle déjà transfor-mée à travers la passerelle GraphTalk/LEdit.
P transformer
5
faire ressortir des aspects in-ternes d’une spécification semi-formelle à travers la spécifi-cation formelle d’une manière à augmenter/assurer la cohé-rence.
création ou modification d’une spécification formelle compo-sée d’éléments qui complètent une spécification semi-formelle.
A compléter
6
générer une modélisation for-melle qui correspond à la spé-cification semi-formelle et qui puisse être vérifiée par un “type-checker”, par rapport aux types de base aux structures définies.
génération d’une spécification formelle à travers la passerelle GraphTalk/LEdit suivie d’un appel à un “type-checker”.
P vérifier
7
expliquer les aspects d’une modélisation semi-formelle qu’on n’arrive pas ou qu’on ne souhaite pas représenter graphiquement.
génération de “notes textuelles” créées avec le gestionnaire de modèles.
- expliquer
8
compléter les aspects d’une modélisation semi-formelle qu’on n’arrive pas ou qu’on ne souhaite pas représenter graphiquement.
introduction de “notes textuel-les” créées avec le gestionnaire de modèles.
A compléter
9
fournir une vue sur une par-tie d’une modélisation dans le but d’améliorer la compréhen-sion de celle-ci.
manipulation réalisée avec le gestionnaire de modèles sur les éléments internes d’une spécification.
- grouper
Les types des relations exprimées par les flèches de la figure 4.13 sont décrits dans les sous-sections suivantes. Pour les exemples donnés, les Modélisations Sources sont présen-tées à gauche avec à droite les Modélisations Résultats. Ces exemples utilisent des niveaux différents de modélisation. Par la suite, le terme schéma est utilisé pour exprimer un élément modélisé ou un fragment de spécification.
4.5.1.1 Relation Expliquer
Un schéma peut expliquer un autre schéma (cf. figure 4.14). Ces deux schémas sont décrits selon deux paradigmes différents (par exemple : formel et formel, ou semi-formel et insemi-formel). Il n’y a pas d’ajout d’information (cf. relations 1 et 7 de la figure 4.13).
Modèle_Objet Classe Héritage L2 L1
modèle objet d’OMT.
pour représenter les concepts du modèle La notation employée utilise les ellipses Ce schéma présente deux concepts du
et les diodes pour représenter les relations du type composition.
Figure 4.14 - Relation Expliquer
4.5.1.2 Relation Compléter
Un schéma peut compléter un autre schéma (ou une partie de celui-ci) par un ajout d’information qu’il serait difficile d’exprimer autrement (cf. figure 4.15) (cf. relations 2, 5 et 7 de la figure 4.13). Malade Chambre Maladie a
est placé tiennent à la relation "a", ne peuvent Certains couples d’objets qui appar-pas appartenir à la même relation "est placé".
4.5 Des Relations entre Éléments de Modélisation 111
4.5.1.3 Relation Transformer
Un schéma peut être le résultat d’une transformation appliquée sur un autre schéma (cf. figure 4.16). Il n’y a pas d’ajout d’information et il peut même exister une perte, selon le contenu du schéma source. La réversibilité entre les deux représentations n’est pas toujours assurée même s’il n’y a pas de perte d’information dans la première transformation (cf. relations 3 et 4 de la figure 4.13). Voiture Véhicule
| {(Voiture,Véhicule)} subset subSuper | Véhicule, Voiture : CLASSE
Figure 4.16 - Relation Transformer
4.5.1.4 Relation Vérifier
C’est un type de relation existant seulement entre des spécifications formelles et semi-formelles. Ce type de relation (cf. figure 4.17) s’appuie fortement sur un contrôleur de typage (“type-checker”) qui exécute le processus de vérification. Le schéma S Spécification sert à vérifier les composants du schéma S Concept associé par rapport à la syntaxe du langage for-mel employé (Z) ainsi que par rapport aux structures forfor-melles pré-définies dans le schéma de la vue Modèle Formel. Pour arriver au schéma présenté à droite de la figure 4.17, il faut faire une transformation de la représentation de gauche vers un schéma S Spécification pour rendre possible la manipulation de celui-ci par le contrôleur de typage . De cette manière il peut exister une perte d’information, comme par exemple les cardinalités MN d’un lien, dans ce type de relation (cf. relation 6 de la figure 4.13).
This is ZTC (version 2.02)
Copyright (c) Xiaoping Jia, 1993-1995 ... Initializing.
... Loading Z mathematical tools library Parsing main file: schema1.zed
... Type checking Schema Box: Schema1 ... Type checking Given Set.
End of main file: schema1.zed Log written in schema1.log
Classe
Objet
Instanciation
Figure 4.17 - Relation Vérifier
4.5.1.5 Relation Grouper
Certains éléments d’un schéma S Concept sont groupés dans un autre schéma, de ma-nière à fournir une vue sur le premier schéma (cf. figure 4.18). Il n’y a pas d’ajout d’infor-mation (cf. relation 9 de la figure 4.13).
Chambre Malade Maladie a est placé Malade Maladie a est placé Chambre
Figure 4.18 - Relation Grouper
4.5.2 Relations entre Modules
Dans cette section nous présentons les relations qui peuvent exister entre les deux mo-dules principaux de l’atelier et les schémas d’une modélisation (cf. figure 4.19).
4.5 Des Relations entre Éléments de Modélisation 113 Informelle Spécification de Modèles Spécification Formelle Spécification Spécifications Semi-Formelle Gestionnaire Gestionnaire de Documents A. Modéliser C. Modéliser D. Composer G. Composer B. Modéliser E. Composer F. Indexer
Figure 4.19 - Relations entre Modules et Modèles
La table 4.3 présentée ci-dessous utilise les mêmes notations que la table 4.2 pour résu-mer les relations de la figure 4.19.
“Rel” Pourquoi Comment “Bilan” Type
A
générer et maintenir la spé-cification d’un modèle d’un schéma S Spécification.
l’outil GraphTalk est utilisé à travers le gestionnaire de modèles.
A modéliser
B
générer et maintenir la spé-cification d’un modèle d’un schéma S Concept.
l’outil GraphTalk est utilisé à travers le gestionnaire de modèles.
A modéliser
C
générer et maintenir la spé-cification d’un modèle d’un schéma S Remarque.
l’outil GraphTalk est utilisé à travers le gestionnaire de modèles.
A modéliser
D
fournir les “notes formelles” qui seront des composants du texte structuré maintenu par le ges-tionnaire de documents.
importation des composants for-mels de la structure de stockage générée lors de l’utilisation du gestionnaire de modèles.
- composer
E
fournir les “notes graphiques” qui seront des composants du texte structuré maintenu par le gestionnaire de documents.
utilisation de l’éditeur gra-phique qui génère une figure à partir de la structure de stockage.
- composer
F
fournir les composants d’une modélisation qui guideront la construction du Modèle For-mel par le gestionnaire de documents.
importation de la structure de stockage générée lors de l’utilisation du gestionnaire de modèles.
- indexer
G
fournir les “notes textuelles” qui seront des composants du texte structuré qui est maintenu par le gestionnaire de documents.
importation des composants in-formels de la structure de sto-ckage générée lors de l’utilisa-tion du gesl’utilisa-tionnaire de modèles.
- composer
Table 4.3 - Relations entre Modules et Modèles
Les relations exprimées par les flèches de la figure 4.19 sont décrites dans les sous-sections suivantes.
4.5.2.1 Relation Composer
Les schémas présents dans une modélisation sont utilisés comme des composants du document structuré manipulé par le gestionnaire de documents. Il n’y a pas d’ajout d’infor-mation (cf. figure 4.20) (cf. relations D, E et G de la figure 4.19).
Voiture Véhicule Voiture Véhicule
La figure 1 ci-dessous présente la
de Véhicule.
structure d’héritage utilisée pour la représentation de la spécialisation
Figure 1 : Spécialisation Véhicule
Figure 4.20 - Relation Composer
4.5.2.2 Relation Modéliser
Cette relation représente la création et la maintenance des différents types de schémas de modélisation par le gestionnaire de modèles. Il y a ajout d’information (cf. figure 4.21) (cf. relations A, B et C de la figure 4.19). Méthode OMT Modèle_Objet Classe Héritage L2 L1