Notation UML (Unified Modelling Language)

Voici les éléments de la notation UML (Unified Modelling Language) nécessaires pour la compréhension des diagrammes présentés. Pour une description exhaustive de la notation, on pourra se référer aux ouvrages spécialisés ( UML, 1997 ; Muller, 1997 ; Quatrani, 1998 ). La notation UML est une notation conçue pour la modélisation objet d'applications et fait suite notamment aux notations des méthodes OMT et Booch. Sont décrits ici plus précisément les principes des diagrammes de cas d'utilisation, de classes, d'objets et de séquence.

1 Diagramme de cas d'utilisation

2 Diagramme de classes

3 Diagramme d'objets

4 Diagramme de séquence

Les cas d'utilisation permettent de modéliser et de structurer les interactions entre les utilisateurs au sens large, appelés acteurs, et un système. Les cas d'utilisation représentent un moyen d'analyse des besoins utilisateurs et permettent de relier les actions faites par un utilisateur avec les réactions attendues d'un système. Plus précisément, un cas d'utilisation unitaire est une abstraction d'un ensemble de scénarios concrets effectués sur l'initiative d'un type d'utilisateurs (cf. Figure 1).

Figure 1 : cas d'utilisation

Les cas d'utilisation peuvent être structurés et reliés par deux types principaux de relations : les relations d'utilisation (uses) et les relations d'extension (extends). Une relation d'utilisation permet de décomposer un cas d'utilisation en sous-cas d'utilisation. Une relation d'extension indique une spécialisation. Dans la Figure 2, l'interaction définie par le cas d'utilisation A comprend celle du cas d'utilisation B, et le cas d'utilisation C est un cas particulier du cas d'utilisation B.

Figure 2 : types de relations entre cas d'utilisation

Par exemple (cf. Figure 3), si l'on désire modéliser les opérations de virements bancaires, on peut identifier deux types d'acteurs : les clients distants et les clients locaux. Les deux types de clients effectuent un virement, mais les clients distants utilisent un Minitel qui engendre une interaction spécifique (relation d'extension). Dans tous les cas, l'opération de virement comprend une phase d'identification (relation d'utilisation).

Figure 3 : exemple de cas d'utilisation (Muller, 1997, page 127)

Dans le cadre de la plate-forme à objet CBR*Tools , nous avons utilisé les cas d'utilisation pour exprimer les interactions entre un utilisateur et le système formé par la plate-forme elle-même complétée de son environnement de manipulation. Un cas d'utilisation peut alors être relié à des points d'ouverture qui participent dans la réalisation du cas d'utilisation (cf. Figure 4).

Figure 4 : points d'ouverture et cas d'utilisation

Les cas d'utilisation nous permettent également de préciser le type de la configuration d'un point d'ouverture dans la réalisation d'une application faite avec CBR*Tools , tout en gardant la structure d'analyse initiale (cf. Figure 5). Trois types de configuration sont identifiés : spécialisation (point d'ouverture à boîte transparente), instanciation (point d'ouverture à boîte noire), ou utilisation du comportement par défaut. Si un même point d'ouverture est utilisé plusieurs fois avec différents types de configuration, on ne retient que le plus spécifique suivant cet ordre. On utilise alors les stéréotypes de UML pour indiquer le type de la configuration sur les relations entre les points d'ouverture et les cas d'utilisation.

Figure 5 : utilisation des points d'ouverture

Une classe d'objets est représentée par un rectangle comprenant trois parties (cf. Figure 6) : nom de la classe, attributs et opérations (ou méthodes). Les listes des attributs et des opérations sont toutefois optionnelles suivant le degré de détail recherché dans un diagramme : ces parties peuvent être vides ou même absentes. Les attributs et les opérations possèdent une visibilité (notamment publique ou protégée) qui est indiquée par un symbole précédent leur nom : si la forme d'une clef est dessinée, l'accès est dit protégé car il est réduit à la classe courante et à ses sous-classes.

Figure 6 : attributs et opérations d'une classe

Trois types de classes sont utilisés : les classes concrètes, les classes abstraites et les interfaces. Contrairement à une classe concrète, une classe abstraite dont la définition est en italique (cf. Figure 7), ne peut pas être instanciée. Une interface est une classe ne définissant que des opérations et ne contient aucun code. Une interface est identifiée par l'indication du stéréotype « Interface » accolé à son nom.

Figure 7 : classe abstraite et interface

Une association représente une relation structurelle entre différentes classes. Une association est généralement bidirectionnelle mais nous précisons à chaque fois le sens de la navigation. L'association est alors dite unidirectionnelle (cf. Figure 8) et indique également le sens de lecture de l'association. Chaque classe joue un rôle dans l'association qui porte une indication de multiplicité (1 pour un et un seul objet, et une étoile pour zéro à plusieurs objets). Par exemple, la Figure 8 indique qu'un objet de classe C1 est associé à un ensemble d'objets de classe C2, sachant qu'un même objet de classe C2 est associé à un unique objet de classe C1.

Figure 8 : association binaire unidirectionnelle

Différents types d'associations sont également définis (cf. Figure 9) : associations qualifiées, associations dérivées, associations avec classe et agrégations. Une association qualifiée est une association qui permet de restreindre les objets référencés dans une association grâce à une clef. Une association dérivée est une association calculée à partir d'une autre association. Une association avec classe est une association elle-même gérée par une classe qui peut ainsi fournir des attributs ou des opérations spécifiques pour l'association. Enfin, une agrégation est une association fortement asymétrique.

Figure 9 : type d'associations

Des contraintes peuvent être posées sur les associations (cf. Figure 10) : contrainte sur le rôle d'une association (par exemple, les objets sont ordonnés), ou entre associations (par exemple, une association est un sous-ensemble d'une autre).

Figure 10 : contraintes et relations

Enfin, les classes peuvent être reliées par la relation d'héritage simple ou multiple (cf. Figure 11).

Figure 11 : relation d'héritage

Un diagramme d'objets permet de montrer concrètement un assemblage entre objets. Un objet (ou instance) est représenté par un rectangle qui comporte généralement le nom de l'objet et sa classe (cf. Figure 12). Toutefois, la classe ou le nom de l'objet peuvent être omis.

Figure 12 : représentations d'un objet

La Figure 13 donne l'exemple d'un diagramme d'objets montrant les relations d'agrégation entre une voiture, ses roues et son moteur.

Figure 13 : diagramme d'objets (Muller, 1997, page 136)

Un diagramme de séquence montre chronologiquement (de haut en bas) les interactions entre un ensemble d'objets (cf. Figure 14). Chaque objet dispose d'une ligne de vie (ligne verticale). Sur ces lignes de vie, des périodes d'activité sont indiquées par des rectangles fins qui sont superposés en cas d'appel récursif.

Figure 14 : diagramme de séquence

Muller, 1997

P.A. Muller. Modélisation objet avec UML. Eyrolles, 421 pages, 1997.

T. Quatrani. Visual Modeling with Rational Rose and UML. Addison-Wesley, 222 pages, 1998.

UML Notation Guide. Rational Software, 142 pages, 1997.

Brigitte Trousse

Last modified: Fri Oct 5 17:25:25 MEST 2001