11/11/2009
UML
(Unified Modeling Language)
langage de modélisation objet unifié
Philippe Chochois
2007/2008
3 4
UML: historique

1997: Version 1.1 d’UML adopté par l’OMG.

1998-1999: Versions 1.2 et 1.3 d’UML.

2001: Sortie des versions suivantes 1.4

2003: Versions 1.5

2002-2003: Préparation de la V2

2004: Sortie de la version V2.1 le 10 octobre 2004

Sortie de la version 2.1.1 le 5/02/07
5 6
UML: caractéristiques

Un standard incontournable et incontesté

En évolution permanente mais avec une stabilité grâce
à l’OMG (réunit les principaux acteurs du monde objet)

UML n’est pas une méthode mais un langage

UML permet de cadrer l’analyse

UML est un support de communication

Avantages d’UML: langage de communication formel,
normalisé et performant

Inconvénients: Nécessite une période d’apprentissage
et UML ne se suffit pas à lui-même.
UML: historique

Né de la fusion des méthodes objet dominantes (OMT,
Booch et OOSE), puis normalisé par l'OMG en 1997,
UML est rapidement devenu un standard
incontournable.

UML n'est pas à l'origine des concepts objet, mais il en
donne une définition plus formelle et apporte la
dimension méthodologique qui faisait défaut à
l'approche objet.
UML: Définition

UML (Unified Modeling Langage) est un langage
graphique de modélisation objet qui permet à divers
intervenants d'échanger de l'information.

Le langage a été normalisé par l'OMG –Object
Management Group).
Il ne s'agit pas d'une méthode, mais d'un outil de
communication.

UML offre 9 diagrammes principaux différents
(Version1), couvrant divers domaines touchant aux
systèmes d‘Information.
Dans sa version 2, 13 diagrammes sont disponibles
UML: les diagrammes

Vue statique du système

Diagramme d’objets  Briques de base

Diagramme de classes  Vue statique du système

Diagramme de composants  Organisation des composants

Diagramme de déploiement  Déploiement des composants

Diagramme de paquetage  Vue d’ensemble du système

Diagramme de structure composite  Vue des liens
entre les sous-ensembles
1
 11/11/2009

7 8

UML: les diagrammes UML: les diagrammes

Vue dynamique du système
Utilisation des diagrammes:

Compte-tenu du nombre important de diagrammes, tous les
diagrammes ne sont pas systématiquement utilisés. Il faut choisir les

Diagramme de cas d’utilisation  Les besoins diagrammes les mieux adaptés au cas étudié, au niveau de détail

Diagramme de collaboration (ou communication) souhaité et aux habitudes des utilisateurs et organisations concernées
 Interactions entre objets

Diagramme de séquences  Interactions entre objets
Les diagrammes peuvent être enrichis de manière incrémentale. Au fur

Diagrammes d’états-transitions  Comportement (Etat des objets en et à mesure de l’avancement du projet, les diagrammes sont affinés,
réaction aux événements) complétés, voire corrigés.

Diagrammes d’activités  Cycle de vie

Diagramme global d’interaction  Vue générale des interactions
Les règles d’utilisation sont donc souples.
(Séquence + activité) C’est un langage: Pour exprimer une idée, il y a une infinité de façons

Diagramme de temps  Etats et interactions avec le temps de le faire… mais certaines sont évidemment préférables à d’autres !
comme contrainte primordiale

9 10

UML: les diagrammes UML: Cas d’utilisation (use-case)

Deux formes : Une forme graphique (très typique), et une forme
textuelle.

La finalité du use-case est de détecter et de décrire les besoins
fonctionnels -> Comment un système est utilisé par un utilisateur

Premier diagramme: Les cas d’utilisation (Use Case) pour atteindre ses objectifs.

Il y a toujours un (ou plusieurs) acteur(s), et le use-case montre les
scénarii entre ce(s) acteur(s) et le système décrit. Certains scénarii
sont des succès, et d'autres des échecs...

Les use-cases peuvent être abrégés, ou plus détaillés...

Le cas d’utilisation est un diagramme qui convient parfaitement au

dialogue avec les utilisateurs car son formalisme est simple et
proche du langage naturel.

11 12

UML: Cas d’utilisation UML: Exemple de cas d’utilisation

Mettre en évidence les fonctionnalités du système existant ou à
Le ou les acteurs principaux sont habituellement à
mettre en œuvre gauche, les acteurs auxiliaires à droite. Le cas

Point de vue des utilisateurs. d'utilisation est indiqué dans un ovale.

Fil à plomb.

Acteurs externes du système

Interactions entre le système et les acteurs externes

Un même acteur peut jouer plusieurs rôles

Enregistrer un mandat

Délivrer une
lettre recommandée

2
 11/11/2009

13 14

Exemple de description textuelle Cas d’utilisation: cas « include »

Saisie d’une commande dans une grande surface Cas « GAB » (Guichet Automatique Bancaire)

Acteur principal : le vendeur

Pré-condition : le vendeur peut se loguer au système
Cas d’utilisation: Retrait d’argent

Déclencheur : un client commande un appareil
Acteur: Client

Scénario nominal:

Niveau : utilisateur
1. Le client saisit son code

Scénario nominal :
2. Le système contrôle le code

1. Le vendeur demande un formulaire de commande
3. Le client saisit son montant

2. Le système retourne le formulaire de commande
4. …

3. Le vendeur sélectionne le produit commandé

4. Le système indique l’état de stock et le date de disponibilité
Cas d’utilisation: Visualisation du compte

5. Le vendeur saisit les informations du client
Acteur: Client

6. Le système demande la confirmation de la commande
Scénario nominal:

7. Le vendeur confirme la command 1. Le client saisit son code

8. Le système enregistre et imprime la commande 2. Le système contrôle le code

Extensions : 3. Le client saisit la période de visualisation

4.1 Le système indique en plus un état de stock d’alerte du fournisseur 4. …

4.1.1 Le vendeur alerte la gestion de stock

4.2 Le client annule sa commande. Fin
Des interactions sont factorisables

15 16

Cas d’utilisation: cas « include » Cas d’utilisation: cas « extends »

Cas « Saisie d’un sinistre immobilier »
Retrait
Scénario nominal:
« include »
1 L’assureur saisit les références de l’assuré

2 Le système retourne le dossier de l’assuré

3 L’assuré saisit les éléments du sinistre

4 Le système retourne le montant évalué
Visualisation
5 L’assureur transmet le dossier au gestionnaire
Contrôle login
« include »

Extensions:

4.1 Le montant dépasse le plafond sans expertise

4.1.1 L’assureur contacte l’expert.

4.1.2 …

Les cas « include » sont exécutés systématiquement !

On ne peut pas retirer de l’argent ou visualiser un compte si le login
n’est pas contrôlé !

17 18

Cas d’utilisation: cas « extends » Cas d’utilisation: Exercice

Cas « Saisie d’un sinistre immobilier »
L’ampleur des extensions autorise à faire apparaître un cas spécifique
« étendant » le cas d’origine
Saisie d’un sinistre
« extends »
Point d’extension: Montant dépassant le plafond
Les cas « Extends » répondent à des cas particuliers.
La demande d’expertise n’a pas lieu pour tous les sinistres !
Cas « Bonveto »:
Un vétérinaire veut créer une application informatique qui lui permettrait de
gérer l’activité de son cabinet.Il reçoit en consultation des animaux pour
lesquels il établit, lors de la première visite, une fiche individuelle de
renseignements. Chaque consultation est enregistrée sur un journal
chronologique des consultations et mentionnée sur la fiche de l’animal. Les
hospitalisations sont consignées dans un classeur particulier. Lorsque
quelqu’un amène un animal trouvé, le vétérinaire doit parfois rechercher le
maître de l’animal en consultant le fichier National des animaux
Demande domestiques (en saisissant le numéro de tatouage de l’animal ou en lisant
d’expertise sa puce d’identification). Si cette première recherche est infructueuse, il
peut aussi s’adresser au fichier international d’identification.
a) Recherchez les acteurs du cas « Bonveto »
b) Etablissez la liste des fonctionnalités auxquelles devrait répondre
une application qui gérerait cette activité
c) Représentez le diagramme des cas d’utilisation de « bonveto »
d) Ecrivez le cas d’utilisation « Identifier un animal » sous forme
textuelle. On précise que la procédure d’identification au fichier national ne
doit pas excéder 30 secondes pour être acceptable.

3
 11/11/2009

19 20

Cas d’utilisation: Exercice corrigé Cas d’utilisation: exercice corrigé

Cas d’utilisation : « Identifier un animal »
Acteur : Le vétérinaire
A p pl i cati o
n "V E T O "
Evénement déclencheur : demande de recherche de l’identité d’un animal (perdu par exemple)
But : Retrouver le propriétaire de l’animal
A cte ur
E nreg i strer u n an i m a l e xterne Niveau : Utilisateur
Portée/Priorité : Moyenne
<< a cteu r> > Pré-conditions : L’animal est tatoué ou porte une puce d’identification et l’adresse du propriétaire
V étéri na i re
n’a pas changé
A cte ur O NI Scénario nominal :
1. Le vétérinaire relève le numéro d’identification de l’animal avec le lecteur de puce ou lit le
E nreg i strer u ne co nsu l ta ti on tatouage
2. Le vétérinaire saisit le numéro
3. L’application demande une recherche sur ce numéro auprès du fichier national d’identification
< < acte u r>>
4. L’animal est reconnu
A cte ur O II 5. Le fichier national renvoie les coordonnées du propriétaire de l’animal
E n re gi stre r u n e ho spi ta l i sa ti o n Extensions
Alternatives :
1.1 Le fichier national ne connaît pas ce numéro
1.2 Le système indique au vétérinaire de faire une recherche sur le fichier international
Exceptions :
Ide nti fi er un a n i m al 1.1 Le numéro est illisible
1.2 Le cas s’arrête
5.1 L’animal n’est pas reconnu
5.2 Le cas s’arrête
Contraintes non fonctionnelles : La recherche du point 3 ne doit pas excéder 30 secondes

21 22

Cas d’utilisation: Généralisation Cas d’utilisation: Généralisation

Cas « GAB »: Cas « GAB »:

Nouvelle règle à prendre en compte: Seuls, les clients de la banque

propriétaire du GAB peuvent visualiser leur compte mais tous peuvent Nous avons représenté les 2 types d’utilisateurs.
retirer de l’argent. Le client de la banque est un porteur de carte. A ce titre, il bénéficie de
toutes les possibilités offertes au porteur de carte (Dans notre exemple, il
Il faut donc différencier les acteurs. n’y en a qu’une mais il pourrait y en avoir plusieurs).
Nous allons dire que l’utilisateur « Client Banque » est un porteur de carte
spécial. C’est la notion de spécialisation.
Par opposition, on peut dire que le porteur de carte est un cas général qui
regroupe les clients et les non clients. C’est la notion de généralisation.

23 24

Cas d’utilisation: Généralisation Cas d’utilisation: Généralisation

Cas « GAB »: Cas « GAB »:
Nous allons dire que l’utilisateur « Client Banque » est un porteur de carte spécial. On peut utiliser la notion d’héritage pour les cas d’utilisation eux-mêmes.
C’est la notion de spécialisation. Nous pouvons spécialiser le cas « Visualisation » en 2 sous cas: 1 pour les
Par opposition, on peut dire que le porteur de carte est un cas général qui regroupe comptes courants et l’autre pour les comptes épargnes.
les clients et les non clients. C’est la notion de généralisation.
On dit que « Client Banque » hérite de « Porteur de Carte ».
Un utilisateur qui hérite d’un autre hérite automatiquement de ses droits. On peut
donc supprimer la représentation « Client Banque effectue un retrait ».

Si la cas d’utilisation général ne peut pas se produire sans le cas d’utilisation

spécialisé, on dit que ce cas est abstrait. On fait figurer le terme « abstract » au
niveau du cas d’utilisation.

4
 11/11/2009

25 26

Cas d’utilisation: Exercice Cas d’utilisation: Exercice

Cas « Réservation »:

Dans un établissement scolaire, on désire gérer la réservation des
salles de cours ainsi que du matériel pédagogique (ordinateur portable
ou/et Vidéo projecteur).

Seuls les enseignants sont habilités à effectuer des réservations (sous
réserve de disponibilité de la salle ou du matériel).

Le planning des salles peut quant à lui être consulté par tout le monde
(enseignants et étudiants).

Par contre, le récapitulatif horaire par enseignant (calculé à partir du
planning des salles) ne peut être consulté que par les enseignants.

Enfin, il existe pour chaque formation un enseignant responsable qui
seul peut éditer le récapitulatif horaire pour l’ensemble de la formation.

Modéliser cette situation par un diagramme de cas d’utilisation
Cas « Hippodrome »:

Un hippodrome offre à ses clients la possibilité de suivre les courses
et/ou de parier.

Pour suivre les courses, il faut payer son billet d’entrée.

Pour parier, il faut miser. En cas de pari gagnant, on peut toucher un
prix.

On peut différencier les différentes épreuves (galop, trot, obstacle…).

Modéliser cette situation par un diagramme de cas d’utilisation