Modèle

<< Modèle >> fait référence à une terminologie orientée objet (e.g. MVC). Il concerne la partie logique (souvent mentionnée comme statique) et persistante du système, par opposition à la partie interactive (souvent mentionnée comme dynamique^5.12) d'une ou plusieurs vues^5.13 sur le système (cf. l'annexe A).

En effet, que doit-on représenter dans le modèle ? La question est fondamentale et généralement difficile à répondre. La philologie abondante sur la méthodologie objet à suivre pour obtenir une séparation optimale des responsabilités (separation of concerns) sans faire exploser le nombre de classes, en est la meilleure preuve.

Restant sur cette voie, d'une modularité optimale, nous proposons un modèle statique indépendant, avec sa propre structuration et dynamique interne et, d'autre part, des applications qui utilisent et modifient les données dans ce modèle à l'aide de méthodes prévues à ce propos au sein du modèle.

Plus précisément, et respectivement aux objectifs posés en p., nous avons choisi de représenter dans le modèle les informations suivantes :  

• Les données persistantes, obligatoires pour la représentation et la sauvegarde de toute l'information sémique déjà explicitée.

• Les contraintes qui garantissent une cohérence structurelle entre les données du modèle.

  Ceci inclut aussi la dynamique interne responsable des modifications dans le modèle, implantée à l'aide d'un ensemble de méthodes de constitution et d'interdépendance des données.

  C'est précisément à l'aide de ces méthodes que nous implantons l'aspect encadrant (framework) du modèle : dans le modèle sont incluses, non seulement les données mais aussi les méthodes d'accès à ces données et les méthodes de leur organisation structurelle et modification.

• Quelques données supplémentaires qui sont nécessaires pour les appels entre les méthodes que nous venons de mentionner. De plus, quelques données qui sont généralement utiles pour l'accélération de la phase d'initialisation du système, après une sauvegarde du modèle.

Pour présenter le modèle nous utilisons la même méthodologie qui nous a assistés tout le long du processus de modélisation objet. Il s'agit du langage unifié de description objet, UML^5.14, mis en uvre par la collaboration de trois spécialistes du domaine : J. Rumbaugh (langage de modélisation OMT^5.15), G. Booch et I. Jacobson (technique OOSE^5.16. Vu que le nombre de langages de modélisation objet augmentait très vite (de 10 à plus de 50 pendant la période 1989-1994) ce qui ne faisait que troubler les utilisateurs, G. Booch et J. Rumbaugh ont commencé, en Octobre 1994 et au sein de la société Rational Software Corporation, l'entreprise d'une unification des méthodes Booch et OMT. Un premier résultat de cet effort apparaît en Octobre 1995 : UML 0.8. À cette période, I. Jacobson, avec la méthode OOSE rejoint ces efforts. Une année plus tard une deuxième pré-version d'UML apparaît et, après la demande officielle de l'organisme responsable de la standardisation en technologie objet, le groupe OMG^5.17, la première version d'UML (UML 1.0) apparaît, début 1997. Actuellement nous sommes à la version UML 1.1^5.18, une version sortie en Septembre 1997, qui a été acceptée par OMG en tant que standard industriel et qui rassemble autour d'elle un bon nombre d'entreprises collaboratrices^5.19.

Le langage UML, en proposant des étapes dans la démarche de modélisation -- e.g. les cas d'utilisation^5.20 -- propose une assistance combinée tant sur le plan de l'organisation objet que sur le plan du processus de conception objet. Dans la présentation qui suit nous ne montrons que la partie finale de la vue logique^5.21 (modèle statique) de la modélisation, et nous ne présentons pas les étapes importantes de la conception du modèle, notamment les cas d'utilisation, qui constituent une exploration des possibilités du système au cas par cas, avant la construction finale d'un modèle de classes. Nous ne présentons pas non plus les diagrammes d'UML qui sont plus proches à l'implémentation physique (i.e. le modèle de composants et modèle de déploiement) car nous pensons que les détails de la mise en uvre, même s'ils ont été nécessaires pour ce travail, n'ont pas normalement une place dans ce document.

Ensuite, nous présentons le diagramme de classes (modèle statique) avec quelques diagrammes d'interaction concernant la dynamique interne du modèle.