CHAPITRE 3 : LA CONSTRUCTION DE LA DÉMARCHE DE MODÉLISATION :
42. Un formalisme : l’Unified Modelling Langage (UML)
UML se présente comme un outil complémentaire du processus de modélisation orienté objet. Issu de la volonté de BOOCH et RUMBAUGH de synthétiser une méthode de modélisation commune à partir de la diversité des méthodes orientées objet existantes13, il apparaît en 1995 sous la forme d’un langage permettant de transcrire les résultats du processus de modélisation (BOOCH G. et al., 2000). Il est important de noter qu’il est proposé comme un langage et non comme une méthode de modélisation. Le principe du langage UML est de permettre de formaliser tous les aspects à prendre en compte pour la réalisation d’un logiciel. Trois types de vues sont mobilisables : (i) la vue fonctionnelle : elle représente les interactions entre les utilisateurs et le système modélisé, nécessairement de façon chronologique, à l’aide des diagrammes de séquences et/ou des cas d’utilisation ; (ii) la vue statique : elle décrit la structure du système modélisé, c’est-à-dire les objets, leurs relations, leurs caractéristiques et leurs comportements, sous la forme de diagrammes de classes et/ou de packages ; (iii) la vue dynamique : elle permet de représenter la dynamique des objets du système, c’est-à-dire l’évolution de leur état au fil du temps, ainsi que les processus à l’origine de cette dynamique, d’où l’utilisation de diagrammes d’états et/ou de diagrammes d’activités. (MULLER P.A., 1997; SIGAUD O., 2005; ROQUES P., 2006)
Ce travail a pour vocation principale la description du modèle réalisé, c’est-à-dire une proposition visuelle d’une conception particulière de la réalité observée. Une présentation technique détaillée, utile à
13
Dans les années 1990, on recense plus d’une cinquantaine de méthodes de modélisation orientée objet. Trois principales sont à l’origine d’UML : l’Object Modeling Technique (OMT) de RUMBAUGH, la méthode BOOCH de BOOCH et l’Object Oriented Software Engineering (OOSE) de JACOBSON.
l’implémentation informatique du simulateur réalisé, n’est pas l’objet ;de fait, seuls les diagrammes et les éléments du formalisme UML utiles à la compréhension de cette représentation du système et utilisés dans ce travail sont présentés14 : le diagramme de classe, le diagramme d’activités et le diagramme d’états.
421. La représentation statique : le diagramme de classes
Le diagramme de classes, dont la Figure 3.8 donne un aperçu, décrit la structure statique d’un système, c’est-à-dire les classes et leurs relations.
Une classe peut être considérée comme une représentation abstraite d’un ensemble d’objets du domaine étudié. Outre son nom, elle est composée de deux parties :
8 Ses attributs : ils rassemblent les caractéristiques propres des objets instanciés. Selon les conventions, chaque attribut est défini par son nom, son type de données (entier, chaîne de caractères, liste, booléen…), sa valeur initiale et sa visibilité15 (public, privé, protégé).
8 Ses méthodes : elles rassemblent les opérations que la classe peut réaliser sous l’effet de messages échangés avec d’autres classes. Selon les conventions, chaque méthode est définie par sa visibilité, son nom, une liste de paramètres et le type de retour généré (lecture de données, modification de données…).
Les relations entre les classes sont appelées des associations. Une association, dessinée par un trait rectiligne entre deux classes, peut comporter plusieurs informations importantes. Au sein de ce travail, apparaissent (i) la notion de multiplicité16 : chaque extrémité d’une association peut comporter une indication de multiplicité qui indique combien d’objets de la classe considérée peuvent être associés à un
14
Le formalisme UML est très riche. Ne sont abordés succinctement ici que les éléments de terminologie et de graphisme utilisés pour la construction des différents diagrammes présentés dans ce travail.
15
La visibilité indique qui peut avoir accès et/ou modifier les propriétés décrites.
objet de l’autre classe, (ii) la notion de contrainte : toute information entre accolades indique une contrainte sur l’association qui peut-être de différentes natures, – par exemple, la contrainte {ordonnée} signifie l’obligation d’un ordonnancement des objets de la collection.
Des types d’associations spécifiques sont aussi régulièrement utilisées par le langage UML, permettant d’organiser les classes entre elles. Au sein de ce travail, apparaissent (i) l’agrégation : représentée par un losange vide, cette association représente une relation dominante entre une classe et une autre, c’est-à-dire que cette classe fait partie d’une autre, (ii) la composition : représentée par un losange plein, cette association est une agrégation particulière où la classe dominante n’existe pas sans l’autre classe considérée, (iii) la généralisation ou l’héritage : représentée par un triangle vide, cette association indique une relation hiérarchique entre deux classes.
422. La représentation dynamique : les diagrammes d’états et d’activités
Le diagramme d’états, dont la Figure 3.9 donne un aperçu, décrit tous les états possibles d’un objet durant son cycle de vie, c’est-à-dire de son état initial, représenté par un cercle noir, à son état final, représenté par un cercle blanc entouré d’un cercle noir. Entre ces deux états, il existe des états intermédiaires matérialisés par des rectangles arrondis portant le nom de l’état. La transition d’un état à un autre est représentée par une flèche portant le sens de la transition, ainsi que l’évènement qui la déclenche. Au sein de ce travail, la complexité d’un objet a impliqué l’utilisation d’un super-état, généralisation de plusieurs états. Le diagramme d’état est finalement un graphe dirigé de la dynamique d’un objet particulier du modèle.
Le diagramme d’activité, dont la Figure 3.10 donne un aperçu, est un cas particulier de diagramme d’états, qui représente non plus la dynamique d’un objet mais le comportement interne d’une méthode ou d’une partie du système modélisé pendant une période donnée. Il se présente sous la forme d’une série de rectangles arrondis, les activités, ordonnées entre elles selon des transitions. Les transitions peuvent comporter des conditions nécessaires à la réalisation de l’activité suivante ; celles-ci sont soit inscrites sur la transition, soit matérialisées sous la forme d’un losange vide, indiquant un choix. Normalement réalisées dans un ordre chronologique précis, plusieurs activités sont parfois amenées à se réaliser en parallèle ; ce phénomène est matérialisée par des barres de synchronisation. Le diagramme d’état est finalement un graphe dirigé de la dynamique d’une partie du système.