• Aucun résultat trouvé

Liste des tableaux

2.3 Modélisation Semi-Formelle

données d’un document et les données des liens est une caractéristique de différenciation du produit [HKR+

92].

Intermedia, par sa caractéristique “d’outil d’agrégation” de documents, ne se prête pas très bien à la fonction d’hôte pour un système d’édition de modélisations basé sur un ca-nevas, à cause de l’absence d’une structure sur laquelle un document doit être construit. Cependant, ses caractéristiques, ses fonctionnalités d’éditeur hyper-texte et son interface sont remarquables.

2.3 Modélisation Semi-Formelle

Le processus de modélisation semi-formelle utilise comme outil de modélisation un lan-gage textuel ou graphique pour lequel une syntaxe précise est définie ainsi qu’une séman-tique ; cette sémanséman-tique assez faible permet une certaine dose de contrôle et l’automatisation de quelques tâches [And95].

La plupart des propositions semi-formelles s’appuient fortement sur un langage gra-phique. Cela peut se justifier par l’expressivité que peut avoir un modèle graphique bien dé-veloppé ; le langage textuel est utilisé normalement comme appui aux modèles graphiques. La modélisation semi-formelle en utilisant un langage graphique peut produire des modèles de compréhension facile. Cependant, le manque de sémantique est un fort handicap pour ce genre de modélisation ; le problème existant pour les langages informels, de manque de précision par rapport à la compréhension de la modélisation et d’ambiguïté, persiste pour les langages semi-formels.

L’utilisation de contraintes dans les modèles graphiques vise à améliorer les problèmes cités ci-dessus par rapport aux modèles semi-formels. Un exemple d’utilisation de contraintes textuelles sur un modèle graphique concerne le travail de J. J. Odell [Ode93], où des contraintes structurelles sont définies sur des relations afin d’éclaircir leur sémantique dans le cadre d’une modélisation basée sur des modèles orientés objets. Une autre proposition est celle de S. Cook et J. Daniels [CD94a]. Dans ce travail, le diagramme d’objets de la méthode OMT [RBP+

91] et les diagramme d’états de D. Harel [Har87] sont notés avec un sous ensemble du langage formel Z [Spi89] afin d’introduire des contraintes sur ces diagrammes.

Les modèles (semi-formels) orientés objets sont apparus pour “prendre la place” des modèles de l’analyse structurée qui ont vu leur utilisation se développer fortement avec les AGL de deuxième génération. À travers ces outils, plusieurs types de modélisation ont pu être utilisés de manière automatisée, ce qui en a développé leur utilisation.

Dans la section 2.1.4, les méthodes ont été classées en méthodes des années 60, méthodes cartésiennes, méthodes systémiques et méthodes objets. Ces méthodes orientées objets sont basées sur des langages semi-formels (ce qui leur donne une caractéristique de modélisation semi-formelle). Leur étude est reprise en détail au chapitre 3.

Approche Cartésienne

Le “Discours de la Méthode”, publié en 1637 par René Descartes, décrit les fon-dements du procédé de décomposition et pour cette raison les méthodes qui suivent une approche par décomposition fonctionnelle sont classées comme cartésiennes. Une méthode d’analyse suit une approche fonctionnelle quand son procédé d’analyse con-siste à décomposer hiérarchiquement un problème à résoudre en fonctions jusqu’à l’obtention par affinements successifs de sous-fonctions suffisamment simples [Bru93].

La plupart des méthodes cartésiennes utilisent des modèles graphiques basés sur les flux de données ; ces sont les “Diagrammes de Flux de Données - DFD”. Un exemple est présenté dans la figure 2.8. Ce diagramme reprend l’exemple présenté avec un langage informel standardisé (cf. figure 2.5).

Les diagrammes de flux de données ont comme composants des entités externes qui sont des éléments externes au système et avec lesquels celui-ci communique, des

processus ou fonctions qui représentent la partie du système qui transforme les

en-trées en sorties, des répertoires de données qui sont utilisés pour modéliser des don-nées en attente et des flux de dondon-nées qui sont utilisés pour représenter le mouvement des données dans le système. Les DFD peuvent être présentés avec plusieurs niveaux d’abstraction à travers la décomposition d’un processus selon un nouveau diagramme.

2.3 Modélisation Semi-Formelle 29   Bibliothèque 2. Vérifier 3. Disponibilité Demande 1. Traiter Livre Externe Lecteur Identifier Répertoire de Données Processus Entité (Fonctions) demande disponibilité réponse recherche données de livres Légende: Données Flux de

Figure 2.8 - Diagramme de Flux de Données

Approche Systémique

Les méthodes qui peuvent être classées comme systémiques sont basées sur la représentation de phénomènes pertinents de l’univers d’application à travers un mo-dèle conceptuel. Elles appréhendent la réalité comme un ensemble d’entités qui ont des relations et des interactions entre elles et qui évoluent au cours du temps [Bru93].

Ces méthodes sont particulièrement adaptées à l’étude des systèmes vis-à-vis de leur environnement. Il est tout aussi intéressent de représenter les interactions entre composants d’un système, que les interactions entre ce système et son environne-ment. La plupart des méthodes systémiques utilisent pour la représentation du modèle conceptuel des modèles graphiques basés sur des “Modèles Entité-Relation - ER” [Che76]. La figure 2.9 présente le modèle ER conforme à l’exemple présenté en fran-çais structuré (cf. figure 2.5).

Les modèles ER ont comme composants des types d’entités, des relations et des cardinalités. Les types d’entités représentent des définitions en intention des en-sembles d’entités du monde réel avec les caractéristiques suivantes : avoir une iden-tification unique, accomplir un rôle dans le système en développement et pouvoir être décrits par une ou plusieurs valeurs. Les relations représentent un ensemble de connexions entre entités et peuvent être précisées par des cardinalités.



Livre Appartenance Bibliothèque

Abonnement Lecteur d’Entité Types Relation Cardinalités : N:N N 1 N N Légende :

Figure 2.9 - Diagramme Entité-Relation