Éléments de base du langage UML

Cette page vous permettra d'assimiler quelques notions générales d'UML, qui seront utilisées régulièrement par la suite. Si certaines notions ou mécanismes vous paraissent difficiles, pas de panique : les sections suivantes permettront de le mettre en application plus concrètement.

Architecture générale

Avant de présenter les éléments du langage, voyons comment tout ceci est architecturé. Cela peut paraître un peu compliqué de prime abord, mais le principe général est finalement assez simple.

Les choses sont construites selon 4 couches, comme le montre la figure suivante :

CoucheResponsabilitéExemple de concept défini
Méta-métamodèleMOFMétaClasse
MétamodèleUMLClasse, Attribut, Methode
ModèleVousPersonne, prenom, direBonjour()
ObjetsL’utilisateur de votre modèle : souvent, vous !personne_1, pascal, 12

UML définit donc une sorte de moule, qui vous permettra de créer des modèles. On appelle ce « moule » un métamodèle. À partir de vos modèles, vous créerez des instances.

Par curiosité, vous pouvez remarquer qu’UML lui-même est défini sur la base d’un « moule » de plus haut niveau encore, un méta-métamodèle, qui est en l’occurrence le MOF : MetaObject Facility, lui aussi maintenu par l’OMG.

Types de données

UML définit, dans son méta-modèle, un ensemble de types de données qui seront utilisés pour la modélisation.

Le type de base, qui sert de parent à tous les autres, est le DataType.

À première vue, on pourrait se dire qu’un DataType ressemble à une classe. Ce n’est pas tout à fait la même chose : les instances de DataType ne sont identifiées que par leur valeur, ce qui veut dire qu’il est impossible de distinguer deux instances d’un DataType qui ont les mêmes valeurs.

Par exemple, 6 et 6 ne sont pas deux instances de types représentant le même entier six, ils sont considérés en interne comme la même instance !

Les DataTypes sont spécialisés en deux catégories :

  • Les types données primitifs (PrimitiveType) : pensez par exemple aux littéraux (Boolean, Integer, Real, String…).
  • Les énumérations (Enumeration) : des types dont les valeurs sont choisies dans un ensemble limité de littéraux.

Voici comment tout ceci est défini dans le métamodèle UML (extrait de la spécification UML 2.5) :

Le métamodèle UML : types de données

Le métamodèle UML : types de données

Note – Remarquez que les Datatypes, comme beaucoup de choses en UML, sont des Classifiers, c’est à dire un ensemble d’éléments qui ont des caractéristiques communes (comme des propriétés ou des méthodes).

Éléments et mécanismes communs

Tous les modèles UML sont constitués d’éléments (Element). Un Element a la capacité de détenir d’autres éléments. Il existe des éléments nommés, des éléments typés…

Les associations et liens

Une association (Association) permet de modéliser un ensemble de liens, chacun de ces liens étant une instance de l’association.

Plusieurs types d’associations sont définies et utilisables dans différents types de diagrammes, comme la relation d’héritage (Generalization), l’agrégation ou la composition.

Les stereotypes

Un stéréotype (Stereotype) permet de compléter (étendre) le métamodèle en réutilisant une classe existante avec des notions propres à un domaine. Il est ainsi possible de définir de nouvelles constructions et règles d’utilisation, dans l’optique d’une utilisation spécifique du langage.

Un stéréotype peut préciser la représentation graphique que peut prendre un certain type d’élément, mais aussi les contraintes qui doivent lui être appliquées (la séamntique) : quelles relations il est possible de créer entre l’élément et d’autres éléments, etc.

Dans le cadre d’une utilisation « normale » d’UML, il est peu probable que vous ayez à définir vos propres stéréotypes. Néanmoins, vous en utiliserez souvent (et nous allons le faire régulièrement au cours de cette formation). Vous devez donc savoir les repérer.

Heu oui, et concrètement ça donne quoi ?

Un stéréotype bien concret et facile à comprendre est celui d’acteur ! En UML (vous en avez déjà vu un exemple dans une section précédente), on représente les cas d’utilisation d’un système en reliant des petits bonhommes à des patates (c’est joli). Les bonhommes sont des acteurs (des rôles dans le système), et les patates sont les fonctionnalités. Et bien figurez-vous que la notion d’acteur est un stéréotype ! C’est un stéréotype qui est fourni « de base » avec UML, vous pouvez donc l’utiliser sans vous poser de questions (sauf en lisant cette section…).

Les stéréotypes dont « attachés » aux éléments en utilisant un nom encadré par de gros guillemets (<< MonStéréotype >>), que l’on place généralement au dessus de l’élément à qualifier. En voici un exemple :

Stéréotypes UML

Les stéréotypes sont un mécanisme très intéressant et puissant, qui permet par exemple de spécialiser UML à un domaine d’activité (ex. : les applications de sécurité, la banque, les bases de données, etc.). Les stéréotypes sont définis dans des descriptions exportables et distribuables que l’on appelle « profils ».

Les relations de dépendance

Les relations de dépendance permettent de spécifier… une dépendance entre un élément et un autre. Si B dépend de A, alors un changement au niveau de A aura un impact sur B.

Les relations de dépendances se représentent comme suit :

Dépendance UML

Les commentaires

Le commentaire (Comment) est une description textuelle qui peut être attachée à un ou plusieurs éléments.

commentaire UML

Les packages et espaces de nommage

Modéliser un système complexe fait très rapidement intervenir un grand nombre de diagrammes et de modèles, ce qui peut à la longue s’avérer difficile à gérer.

Pour organiser tout ce contenu, le modélisateur peut notamment faire utilisation des paquetages ou packages (Package), qui sont des espaces de noms (Namespace) pouvant contenir d’autres éléments. Un package peut lui même contenir d’autres packages.

Voici un exemple :

Package UML

Remarque – Comme les packages définissent des espaces de nom, le package Authentification peut contenir un élément (package, classe…) ayant le même nom que le package Commande.

Les contraintes

Une contrainte Constraint est une assertion qui permet de spécifier une restriction pour toute instantiation valide du système qui contient la contrainte. Il s’agit là d’une relation sémantique (qui ajoute des éléments de sens aux modèles).

Ces contraintes peuvent être exprimées en langage naturel dans des commentaires, ou encore en utilisant un langage spécifique, lui aussi proposé par l’OMG, et appelé OCL : Object Constrainst Language.

Les contraintes sont utilisées de manière intensives dans le métamodèle UML, mais au niveau de vos modèles métier, vous devriez en avoir assez rarement besoin. Généralement, si votre système est bien architecturé, vous n’aurez pas beaucoup recours au contraintes : si vous avez besoin de placer des contraintes un peu partout dans vos modèles, de deux choses l’une :

  • Soit vous êtes en train de modéliser quelque chose de très compliqué (ça peut arriver…).
  • Soit vous êtes en train de modéliser de manière compliquée quelque chose qui pourrait l’être beaucoup plus simplement (ça arrive souvent…).

Voici un exemple de définition de contraintes :

Contraintes UML

On peut notamment placer des contraintes sur certaines relations, comme le montre la figure ci-dessous :

Contraintes UML relations

Note – Nous aurons recours au contraintes, à petite dose, au cours cette formation, mais ce n’est pas un élément fondamental de l’utilisation que nous ferons d’UML. Le lecteur intéressé par un peu plus de détail peut trouver une description du langage de contraintes ici : spécification d’OCL.

Testez-vous !

À quoi sert un métamodèle ?
  • Il définit les éléments qui peuvent être utilisés par les modèles. Le métamodèle est une instance du modèle.
  • Il permet de favoriser l’interopérabilité des modèle en les contraignant à reposer sur les mêmes classes de base.
  • Ça ne sert à rien !
Qu’est-ce que le MOF ?
  • Le méta-métamodèle d’UML
  • MetaObject Facility
  • Meta Occurrence Feature
  • Une abstraction très générale, modélisant des concepts de haut niveau utiles pour décrire des métamodèles
Le MOF (MetaObject Facility) est le méta-modèle d’UML, ce qui veut dire qu’UML est une instance du MOF. Les classes d’UML sont par exemple des instances de méta-classes définies par le MOF.

Ceci veut donc dire qu’on peut imaginer d’autres langages qu’UML, qui partageraient les mêmes fondations (ces langages existent, comme par exemple QVT – Query/View/Transformation).

Qu’est-ce qu’un stéréotype ?
  • Un type de diagramme
  • Une manière d’étendre UML
  • Un mécanisme permettant de spécifier comment certains éléments doivent être utilisés
  • Un mécanisme permettant de spécifier quel aspect graphique peuvent prendre certains éléments
  • Un super-type de données
Les stéréotypes permettent d’ajouter des éléments de sémantique, en spécifiant comment un type d’élément doit interagir avec les autres dans les diagrammes, et potentiellement quel aspect graphique il doit avoir.

Pour bien retenir le concept, pensez aux acteurs : ils sont représentés par des bonhommes, ils peuvent être rattachés à des use-cases, etc. : tout ceci est spécifié dans un stéréotype, <<Actor>>.

Tout utilisateur d’UML peut définir ses propres stéréotypes, et bien sûr utiliser ceux qui sont fournis par défaut avec le langage.

Que signifie la contrainte self.titre->isEmpty() = false ?
  • L’attribut isEmpty a pour valeur false.
  • L’attribut titre ne doit pas être vide.
  • La classe Titre a pour a pour attribut isEmpty.
Quel est l’intérêt d’utiliser des packages en UML ?
  • Il permet d’avoir une idée précise de la manière dont sera structuré le code cible.
  • Il n’y a aucun intérêt, c’est un artifice du langage.
  • Les packages permettent de définir des espaces de noms distincts.
  • Un package est un ensemble de contraintes.
Souvenez-vous qu’un package est un espace de nom : deux éléments (classes, acteurs…) ne peuvent pas avoir le même nom au sein d’un même package (ou du package par défaut), mais c’est possible s’ils appartiennent à des packages différents.
Que signifie la notion de dépendance en UML ?
  • Si B dépend de A, alors tout changement de A a des conséquences sur B.
  • Si A dépend de B, alors tout changement de A a des conséquences sur B.
  • Si A dépend de B, alors tout changement de B a des conséquences sur A.
  • Aucune de ces choix n’est vrai.

Commentaires