Un Canevas de Modélisation

4.5.2.3 Relation Indexer

Les éléments présents dans les S Concepts sont les “indices” à partir desquels le Ges-tionnaire de Modèles construit le texte descriptif afin d’assurer la cohérence entre les mo-dèles et le Document de Spécification Globale - DSG (cf. figure 4.22) (cf. relation F de la figure 4.19).     Voiture Véhicule Classes : Véhicule Voiture Relations :

Héritage <Véhicule, Voiture>

Figure 4.22 - Relation Indexer

4.6 Un Canevas de Modélisation

La section 4.3.2 a présenté le Gestionnaire de Documents qui, dans notre atelier, doit gérer le document de spécification d’un système. Cette gestion aura pour base un Canevas de Modélisation qui est présenté ci-dessous. Un tel canevas de modélisation constitue une solution partielle au guidage d’une démarche de modélisation d’un système d’information.

Dans la section 2.2.1, on a présenté le concept d’hypertexte afin de pouvoir l’utiliser comme base du Gestionnaire de Documents dans le but de construire un document structuré qui remplisse le rôle de document de spécification de systèmes.

L’un des buts de ce travail étant la présentation d’un prototype d’atelier qui intègre trois types différents de spécifications, le canevas adopté ici n’a pas pour objectif d’être un docu-ment qui traite toutes les étapes et détails d’une spécification de systèmes. Il s’agit simple-ment d’un cadre qui montre les possibilités et les bénéfices qu’une utilisation conjointe d’ap-proches différentes peut offrir. Pour un document complet pour la spécification de systèmes, on peut voir par exemple la norme AFNOR NF 67-100-3 [AFN94] qui est une proposition d’un “canevas de documents opérationnels convenant aux différentes mailles d’approche

que la vie des projets informatiques peut susciter selon que l’on s’intéresse à l’ensemble de l’entreprise ou de l’organisation, à un domaine particulier ou à un sous-ensemble ap-plicatif”. D’une manière très résumée, on peut dire que cette norme AFNOR préconise la création d’un document composé des sous-documents suivants : Relations Contractuelles, Gestion de Projet, Assurance Qualité, Développement et finalement Utilisation et Soutien.

Le canevas qui nous proposons pour l’atelier est partiellement issu de cette norme. Il constitue ce qu’on appelle le Document de Spécification Globale - DSG. La figure 4.23 présente le squelette d’un tel canevas.

1. Introduction 2. Contexte 2.1 Objectifs 2.2 Hypothèses 3. Besoins Détaillés 3.1 Modèle Formel 3.2 Les Vues 3.2.n.1 Les Concepts

Figure 4.23 - Canevas de Modélisation - Le Document de Spécification Globale

Dans les items 1 et 2 du DSG, une introduction textuelle descriptive du système à mo-déliser est produite. Ces items ne doivent pas entrer dans les détails ni de l’analyse ni de l’implantation, qui sont traités dans l’item 3.

Dans l’item 3, se concrétise l’interaction entre le Gestionnaire de Documents et le Ges-tionnaire de Modèles. Tous les composants présents dans cet item proviennent du Gestion-naire de Modèles. Ainsi les composants semi-formels sont la représentation des schémas S Concepts, les composants informels la représentation des schémas S Remarques et les composants formels la représentation des schémas S Spécifications et du schéma S Global. Nous pouvons aussi ajouter du texte informel “autour” de ces composants importés.

Dans le DSG, l’item 3.1 déclare la partie du schéma S Global qui introduit la défini-tion de types (dans le niveaux méta-modélisadéfini-tion et multi-modélisadéfini-tion) et les définidéfini-tions axiomatiques (dans le niveau multi-modélisation).

L’item 3.2 du DSG est utilisé pour la spécification, selon les trois formalismes, des re-lations entre composants de la modélisation (dans le niveaux méta-modélisation et modélisation) ainsi que des structures internes d’une modélisation (dans le niveau multi-modélisation). Pour cela nous devons définir dans le Gestionnaire de Modèles des vues qui correspondent aux relations et structures qui nous voulons inclure dans le DSG. Dans l’item

4.7 Conclusion 117

3.2.n.1 nous pouvons, pour chacune des vues, référencer les composants associés lorsqu’il est nécessaire de rajouter des détails de modélisation particuliers à un composant. À travers la définition de la vue présente dans la Structure de Stockage, nous pouvons accéder aux composants de celles-ci.

4.7 Conclusion

Afin de répondre à quelques uns des besoins des nouveaux ateliers de modélisation, un méta-modèle a été proposé. Celui-ci offre un cadre où des modélisations informelles, semi-formelles et semi-formelles sont utilisées conjointement dans une modélisation.

L’utilisation de ce méta-modèle dans l’atelier permet la représentation et la gestion de modèles à deux niveaux d’abstraction hiérarchisés :

– modèles de systèmes d’information selon ces formalismes variés ;

– “modèles de modèles” de systèmes d’information, c’est-à-dire méta-modèles.

L’atelier atteint ainsi l’orientation préconisée par des experts des langages formels dans la mesure où il intègre des spécifications formelles à d’autres types de spécifications.

L’architecture adoptée par l’atelier montre une certaine indépendance entre les deux modules principaux. On peut dire que le Gestionnaire de Modèles est chargé de la création de la modélisation, et que le Gestionnaire de Documents gère la mise en forme de cette modélisation.

L’utilisation d’un même méta-modèle à deux niveaux différents permet, même si on peut dire que cette utilisation est secondaire au niveau multi-modélisation (car elle se res-treint à l’utilisation des schémas), aux deux types de spécifications produites, d’avoir la même apparence dans la mesure où elles utilisent le même paradigme. Cela peut faciliter la compréhension des modélisations.

En résumé, les principales caractéristiques de l’atelier présenté dans ce chapitre sont :

1. une description de chaque modèle selon un même méta-modèle prenant en compte les trois dimensions, informelle, semi-formelle et formelle ;

2. une indépendance de toute représentation physique et graphique des modèles ;

3. une portabilité et une autonomie des trois composants (méta-outils) de l’architecture choisie ;

4. une combinaison de l’approche objet avec des aspects formels et une organisation en schémas ;

5. une généralisation de la multi-modélisation ;

6. une aide à la documentation ;

7. une possibilité de vérifier formellement une spécification semi-formelle.

L’étude sommaire réalisée sur les différents types de relations existantes entre les trois approches de modélisation permet d’imaginer des utilisations possibles de l’atelier en ré-ponse, par exemple, au besoin de transformation présenté par C. Rolland (cf. section 4.1). Cette étude permet aussi une meilleure compréhension des mécanismes internes de l’ate-lier. Cette étude peut être étendue à d’autres types de relations avec les mêmes objectifs ; ainsi on peut soit étudier l’existence d’autres types de relations comme la simplification ou la réécriture, soit étudier l’existence de relations possibles entre tous les types différents de modélisation : informels vers formels, formels vers formels, informels vers semi-formels ainsi que semi-formels vers semi-formels, semi-semi-formels vers semi-semi-formels et insemi-formels vers informels.

Chapitre 5