I.
La méthode UML
Au milieu des années 90, les auteurs de Booch, OOSE et OMT ont décidé de créer un langage de modélisation unifié
avec pour objectifs :
Modéliser un système des concepts à l'exécutable, en utilisant les techniques orientée objet ;
Réduire la complexité de la modélisation ;
Utilisable par l'homme comme la machine.
Ce langage repose sur deux concepts essentiels: la modélisation du monde réel au moyen de l'approche orientée objet
et l'élaboration d'une série de diagrammes.
1. La modélisation du monde réel au moyen de l'approche orientée objet.
a) Rappels sur les concepts objets
Orientation objet : organisation d’un logiciel sous la forme d’une collection d’objets qui incorporent
structure de données et comportement.
Objet : regroupe identité, état (valeurs des attributs) et comportement (méthodes).
Identité : tout objet possède une identité unique et invariable, qui permet de le distinguer des autres objets.
Cette identité est indépendante des valeurs des attributs.
Attributs : variables stockant des informations d’état de l’objet.
Méthodes: opérations que l’objet est à même de réaliser et qui caractérisent son comportement. Ces
opérations permettent de faire réagir l’objet aux solicitations extérieures et d’agir sur les autres objets.
Les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des valeurs des attributs et/ou
les modifier.
Classification: regroupement dans des classes des objets ayant même structure de données (attributs) et
même comportement (opérations).
Classe: abstraction décrivant un ensemble d’objets potentiellement infini partageant la même structure et le
même comportement. Génératrice d’instances conformes au modèle qu’elle définit.
Instance d’une classe : objet appartenant à la classe.
Héritage ou généralisation/spécialisation : on peut définir une classe (la sous-classe ou classe fille) à partir
d’une autre classe (la superclasse ou classe mère). Les objets de la sous-classe héritent de tous les attributs et
de toutes les méthodes de la superclasse et peuvent en ajouter d’autres.
La sous-classe est une spécialisation de la superclasse. La superclasse est une généralisation de la sous-classe.
Polymorphisme: possibilité de comportements différents d’une même opération selon les situations (vient
du grec ancien polús qui signifie nombreux et morphê qui signifie forme).
Le polymorphisme s’appuie sur le fait que les méthodes sont appelées en fonction du type réel (dynamique) de l’objet,
c’est-à-dire la classe dont il est instance, et non pas du type de la variable dans laquelle il est stocké (type statique).
Le polymorphisme permet que certaines parties du code, écrites de manière « générique » avec les types statiques,
soient exécutées de manières différentes en fonction des types réels des objets.
Exemple: la classe « Animal » peut avoir une méthode « son » qui produit des sons différents selon le type d'animal.
Délégation: on parle de délégation quand une classe (cliente) délègue à une autre classe (serveuse) une partie
de son activité. Il y a donc réutilisation de code. Une raison peut être le souhait de séparer du reste ce qui est
susceptible d’évoluer souvent.
La délégation s’implante grâce à un attribut de la classe cliente contenant une reference vers la classe serveuse. En
changeant la référence on peut changer le comportement, y compris pendant l’exécution.
Interface: une interface est la définition abstraite d’un type, indépendamment de la façon dont il est implanté
(type abstrait). Concrètement, c’est un ensemble de méthodes publiques abstraites.
Il est très conseillé de typer aux maximum les variables par des interfaces (qui évoluent peu) plutôt que par des
implantations (qui sont susceptibles d’évoluer plus souvent).
Association: une association représente une relation sémantique particulière entre des classes, qui porte un
nom.
La relation d’héritage ci-dessus et d’agrégation/composition ci-après sont des forms particulières d’association qui ne
portent pas de nom.
Agrégation: une agrégation est une association avec une sémantique du type « un tout (un agrégat) vers les
parties de ce tout ».
Composition: est une agrégation particulière dans laquelle la durée de vie des parties est liée à celle du tout:
les parties ne peuvent exister que si l’agrégat existe. Si l’agrégat est supprimé les parties le sont aussi.
2. L'élaboration d'une série de diagrammes facilitant l'analyse et la conception des systèmes, et permettant
de représenter les aspects statiques et dynamiques (représente l'aspect comportement ou communication d'un
système) du domaine à modéliser ou à informatiser.
Catégorie statique Catégorie dynamique
Diagramme de classes Diagramme des cas d'utilisation
Diagramme d'objets Diagramme d'activité
Diagramme de composants Diagramme d'états-transition
Diagramme de structure composite Diagramme diagramme de sequence
Diagramme de déploiement Diagramme Vue générale d'interaction
Diagramme de paquetages Diagramme de communication
Diagramme de profils (UML 2.2) Diagramme de temps
I. Le diagramme des cas d’utilisation
Le diagramme des cas d'utilisation (Use Case Diagram) constitue la première étape de l’analyse UML. Il permet de :
Modéliser les besoins des utilisateurs.
Identifier les grandes fonctionnalités et les limites du système.
Représenter les interactions entre le système et ses utilisateurs.
Le diagramme des cas d’utilisation apporte une vision utilisateur et absolument pas une vision informatique. Il ne
nécessite aucun connaissance informatique et l’idéal serait qu’il soit réalisé par le client. Le diagramme des cas
d’utilisation n’est pas un inventaire exhaustif de toutes les fonctions du système. Il ne liste que des fonctions générales
essentielles et principales sans rentrer dans les détails.
a) Les éléments d’un diagramme des cas d’utilisation :
i. Un acteur est un utilisateur externe au système. Cela peut être : une personne, du matériel (capteurs, moteurs,
relais…), un autre système.
Nous utilisons :
Le stick man si l’acteur est humain
Le classeur si l’acteur est du matériel ou un autre système.
ii. Les cas d’utilisation : le cas d’utilisation représente une fonctionnalité du
système (visible de l’extérieur du système). Un cas d’utilisation se représente
par une ellipse contenant le nom du cas d’utilisation (phrase commençant par
un verbe à l’infinitif) et optionnellement un stéréotype au-dessus du nom.
Les différents cas d’utilisation peuvent être représentés à l’intérieur d’un même rectangle représentant les limites du
système.
iii. Relation entre acteurs et cas d’utilisation :
La relation d’association : A chaque acteur est associé un ou plusieurs cas d’utilisations, la relation
d’association peut aussi être appelée relation de communication. Elle est représentée par un trait reliant
l’acteur et le cas d’utilisation. Nous pouvons rajouter sur ce trait un stéréotype qui va préciser la relation de
communication (« communicate »).
Multiplicité : lorsqu’un acteur peut interagir plusieurs fois avec un cas d’utilisation, il est possible d’ajouter
une multiplicité sur l’association du côté du cas d’utilisation. Le symbole * signifie plusieurs. Exactement n
s’écrit tout simplement n, n..m signifie entre n et m, etc. Préciser une multiplicité sur une relation n’implique
pas nécessairement que les cas sont utilisés en même temps.
iv. Les relations entre cas d’utilisation :
La relation d’inclusion sert à enrichir un cas d’utilisation par un autre cas d’utilisation (c’est une sous
fonction). Un cas d'utilisation (le cas d'utilisation de base) inclut les fonctionnalités d'un autre cas d'utilisation
(le cas d'utilisation inclus)
Dans un diagramme des cas d’utilisation, cette relation est représentée par une flèche pointillée reliant les 2 cas
d’utilisation et munie du stéréotype « include ».
L’inclusion permet de : partager une fonctionnalité commune entre plusieurs cas d’utilisation et de décomposer un cas
d’utilisation complexe en décrivant ses sous fonctions.
La relation d’extension comme la relation d’inclusion, la relation d’extension enrichit un cas d’utilisation
par un autre cas d’utilisation de sous fonction mais celui-ci est optionnel (c’est-à-dire que le cas étendu n’est
une option du cas qu’il étend).
Cette relation est représentée par une flèche en pointillée reliant les 2 cas d’utilisation et munie du stéréotype « extend
».
v. Relation de généralisation ou de spécialisation : il est possible de spécialiser un cas d’utilisation en un
autre cas d’utilisation. Nous obtenons alors un sous-cas d’utilisation. Le sous-cas d’utilisation hérite aussi de
toutes les associations du sur-cas (relations d’association avec les acteurs, relations d’inclusions, et relations
d’extensions).
Quelquefois, le sur-cas d’utilisation est abstrait (c’est-à-dire qu’il ne peut pas être instancié). Il correspond
à un comportement partiel et sert uniquement de base pour les sous-cas d’utilisation qui en hériteront.
La relation de généralisation est représentée par une flèche avec une extrémité triangulaire.
Le nom d’un cas d’utilisation abstrait est écrit en italique (ou accompagné du stéréotype « abstract »).
vi. Type d’acteurs et relation entre acteurs :
Acteurs principaux et secondaires : A chaque cas d’utilisation est associé un ou plusieurs acteurs.
- Un acteur est principal pour le cas d’utilisation auquel il est lié si ce cas d’utilisation lui rend un
service.
- Les autres acteurs liés à ce cas d’utilisation sont dits secondaires. Normalement, Il ne peut y avoir
qu’un seul acteur principal par cas d’utilisation.
- En général, l’acteur principal sollicite le cas d’utilisation alors que l’acteur secondaire est sollicité
par le cas d’utilisation.
- Un acteur peut être principal pour un cas d’utilisation et secondaire pour un autre cas d’utilisation.
- Si nous désirons indiquer si l’acteur est principal ou secondaire pour un cas d’utilisation, nous
pouvons ajouter les stéréotypes « primary » ou « secondary » sur la relation d’association entre
l’acteur et le cas d’utilisation.
La relation de généralisation : La seule relation possible entre 2 acteurs est la généralisation (même
comportement et même représentation graphique que la relation de généralisation entre 2 cas d’utilisation).
b) Description textuelle des cas d’utilisation : Ce n’est pas obligatoire, mais il est recommandé de rédiger une
description textuelle de chaque cas d’utilisation afin de les détailler. Une description textuelle classique se
compose de trois parties :
Partie 1 : Identification.
- Titre : Nom du cas d’utilisation
- Résumé : description du cas d’utilisation.
- Acteurs : descriptions des acteurs principaux et secondaires.
- Dates : Date de création et date de mise à jour.
- Responsable : Noms du ou des responsables.
- Version : Numéro de la version.
Partie 2 : Description des scénarios.
- Les pré-conditions : État du système avant que le cas d’utilisation puisse être déclenché.
- Les Scénarios (un scénario est une instance d’un cas d’utilisation dans lequel tous les paramètres ont été
fixés). Il y a plusieurs types de scénarios :
o Le scénario nominal qui correspond à un déroulement normale d’un cas d’utilisation.
o Les scénarios alternatifs qui sont des variantes du scénario normal.
o Les scénarios d’exceptions qui décrivent ce qui se passe lors d’une erreur.
- Les post-conditions : Elles décrivent l’état du système après l’issue de chaque scénario.
Partie 3 : Exigence non fonctionnelle.
La partie 3 peut être omise, mais si elle est présente, elle permet de préciser des spécifications non fonctionnelles
(fréquence, fiabilité, type d’interface homme-machine...).
