UML

Unified Modeling Language (UML)

Langage de modélisation graphique.

Permet de bien définir les besoins clients et d’éviter le coût d’un logiciel non conforme au besoin.

Permet de vulgariser les aspects liés à la conception et à l'architecture au client.

Apporte une compréhension rapide du programme à d'autres développeurs externes en cas de reprise du
logiciel et facilite sa maintenance

UML est conçu pour modéliser divers types de systèmes, de taille quelconque et pour tous les domaines
d’application.
Unified Modeling Language (UML)

La version actuelle, UML 2.5, propose 14 types de diagrammes dont sept structurels et sept
comportementaux. À titre de comparaison, UML 1.3 comportait 25 types de diagrammes.

UML n'étant pas une méthode, l'utilisation des diagrammes est laissée à l'appréciation de chacun.

En UML 2.5, les diagrammes sont représentés sous deux types de vue :

● Statique ou structurelle du domaine avec les diagrammes de structure (Structure Diagrams).

● Dynamique avec les diagrammes de comportement (Behavior Diagrams) et les diagrammes
d’interactions (Interaction Diagrams).
Diagrammes UML
Diagrammes de structure ou diagrammes statiques

● Diagramme de classes (class diagram) : représentation des classes intervenant dans le système.
● Diagramme d'objets (object diagram) : représentation des instances de classes (objets) utilisées
dans le système.
● Diagramme de composants (component diagram) : représentation des composants du système
d'un point de vue physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases de
données…)
● Diagramme de déploiement (deployment diagram) : représentation des éléments matériels
(ordinateurs, périphériques, réseaux, systèmes de stockage…) et la manière dont les composants
du système sont répartis sur ces éléments matériels et interagissent entre eux.
Diagrammes de structure ou diagrammes statiques

● Diagramme des paquets (package diagram) : représentation des dépendances entre les paquets
(un paquet étant un conteneur logique permettant de regrouper et d'organiser les éléments dans le
modèle UML), c'est-à-dire entre les ensembles de définitions.
● Diagramme de structure composite (composite structure diagram) : représentation sous forme
de boîte blanche des relations entre composants d'une classe (depuis UML 2.x).
● Diagramme de profils (profile diagram) : spécialisation et personnalisation pour un domaine
particulier d'un meta-modèle de référence d'UML (depuis UML 2.2).
Diagrammes de comportement

● Diagramme des cas d'utilisation (use-case diagram) : représentation des possibilités d'interaction
entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire de toutes les
fonctionnalités que doit fournir le système.
● Diagramme états-transitions (state machine diagram) : représentation sous forme de machine à
états finis du comportement du système ou de ses composants.
● Diagramme d'activité (activity diagram) : représentation sous forme de flux ou d'enchaînement
d'activités du comportement du système ou de ses composants.
Diagrammes d'interaction ou dynamiques

● Diagramme de séquence (sequence diagram) : représentation de façon séquentielle du

déroulement des traitements et des interactions entre les éléments du système et/ou de ses
acteurs.
● Diagramme de communication (communication diagram) : représentation de façon simplifiée d'un
diagramme de séquence se concentrant sur les échanges de messages entre les objets (depuis UML
2.x).
● Diagramme global d'interaction (interaction overview diagram) : représentation des
enchaînements possibles entre les scénarios préalablement identifiés sous forme de diagrammes
de séquences (variante du diagramme d'activité) (depuis UML 2.x).
● Diagramme de temps (timing diagram) : représentation des variations d'une donnée au cours du
temps (depuis UML 2.3).
Diagramme des cas d’utilisations
Diagramme de cas d'utilisation

Il peut servir à résumer les informations des utilisateurs de votre système (également appelés acteurs) et
leurs interactions avec ce dernier.

La création de ce type de diagramme UML requiert un ensemble de symboles et de connecteurs

spécifiques. Lorsqu'ils sont bien conçus, les diagrammes de cas d'utilisation peuvent aider votre équipe à
collaborer et représenter :

● les scénarios dans lesquels votre système ou application interagit avec des personnes, des
organisations ou des systèmes externes ;
● les objectifs que votre système ou application permet aux entités (appelées acteurs) d'atteindre ;
Diagramme de cas d'utilisation

Il n'a pas vocation à entrer dans les détails.

Par exemple, ne vous attendez pas à ce qu'il illustre l'ordre dans lequel les étapes sont exécutées. Au
contraire, un diagramme de cas d'utilisation bien conçu donne une vue d'ensemble des relations entre les
cas d'utilisation, les acteurs et les systèmes.

Les experts recommandent que les diagrammes de cas d'utilisation soient utilisés pour compléter une
description textuelle plus approfondie.
Diagramme de cas d'utilisation

Les diagrammes de cas d'utilisation UML sont parfaits pour :

● représenter les objectifs des interactions entre le système et les utilisateurs ;

● définir et organiser les exigences fonctionnelles dans un système ;
● préciser le contexte et les exigences d'un système ;
● modéliser le flux de base des événements dans un cas d'utilisation.
Eléments d’un diagramme de cas d'utilisation

Les éléments qui composent un diagramme de cas d’utilisation incluent généralement :

● Les acteurs : utilisateurs qui interagissent avec un système. Un acteur peut être une personne, une
organisation ou un système externe qui interagit avec votre application ou votre système. Il s'agit
nécessairement d'objets externes qui produisent ou consomment des données.
● Le système : séquence spécifique d'actions et d'interactions entre les acteurs et le système. Un
système peut également être appelé scénario.
● Les objectifs : résultat final de la plupart des cas d'utilisation. Un diagramme réussi doit décrire les
activités et les variantes utilisées pour atteindre l'objectif.
Notation d’un diagramme de cas d'utilisation

● Cas d'utilisation : formes ovales horizontales qui représentent les différentes applications
possibles pour un utilisateur.
● Acteurs : bonshommes représentant les personnes qui se servent réellement des cas d'utilisation.
● Associations : lignes reliant les acteurs aux cas d'utilisation. Dans les diagrammes complexes, il est
important de pouvoir identifier les acteurs associés à chaque cas d'utilisation.
● Frontières de systèmes : cadres indiquant le champ d'application des cas d'utilisation présents
dans un système. Tous les cas d'utilisation situés en dehors du cadre n'entrent pas dans le champ
d'application de ce système.
● Paquets : une forme UML qui vous permet de regrouper différents éléments. Ces groupes sont
représentés sous forme de dossiers de fichiers.
Notation d’un diagramme de cas d'utilisation
Acteurs

Un acteur représente un rôle d'un utilisateur qui interagit avec le système que
vous modélisez. L'utilisateur peut être un utilisateur humain, une organisation,
une machine ou un autre système externe.

● Acteur primaire: il initie l’interaction avec le système. Généralement, il est

représenté à gauche du système
● Acteur secondaire: il réagit à une interaction initiée par le système.
Généralement, il est représenté à droite du système.
Relations

● Association: relation entre deux éléments, Une relation simple entre un acteur et une utilisation
est un trait simple.
● Généralisation: Le cas d'utilisation A est une généralisation de B, si B est un cas particulier de A.
● Inclusion: le premier cas d'utilisation inclut le second et son issue dépend souvent de la résolution
du second. Elle est représentée par une flèche en pointillé et le terme include.
● Extension: un cas d'utilisation A étend un cas d'utilisation B lorsque le cas d'utilisation A peut être
appelé au cours de l'exécution du cas d'utilisation B. Elle est représentée par une flèche en
pointillée avec le terme extend.
Exemple
Exemple
Exemple
Exemple
Diagramme de classes
Diagramme de classes

● Le diagramme de classes est un schéma utilisé pour présenter les classes et les interfaces des
systèmes ainsi que leurs relations.
● Une classe représente une catégorie d'objets. Elle décrit les responsabilités, le comportement et le
type d'un ensemble d'objets.
● Une classe est comme un moule à partir duquel il est possible de créer des objets. L’objet ainsi créé
s’appelle instance de la classe ( il a les propriétés de la classe).
Diagramme de classes

● Il décrit ce qui doit être présent dans le système modélisé.

● Utilisé pour modéliser les objets qui constituent le système, pour afficher les relations entre les
objets et pour décrire ce que ces objets font et les services qu'ils fournissent.
● Utilisé pour documenter l'architecture des logiciels.
Classe

Une classe est représentée par un rectangle séparé en trois parties :

● La première partie contient le nom de la classe. Cette section
est obligatoire.
● La seconde contient les attributs de la classe. C’est pour
décrire les propriétés de la classe.
● La dernière contient les méthodes de la classe. Les méthodes
décrivent la manière dont une classe interagit avec les
données.
Attribut

La syntaxe d'un attribut est la suivante :

Visibilité nomAttribut [multiplicité] : typeAttribut = Initialisation ;

La notion de visibilité indique qui peut avoir accès à l'attribut:

Symbole Mot clé Description

+ public Toutes les autres classes ont accès à cet attribut.

# protected Seules la classe elle-même et les classes filles (héritage) ont accès à cet attribut.

~ package Classe visible uniquement dans le package.

- private Seule la classe elle-même a accès à cet attribut.

Méthode

La syntaxe d'une méthode est la suivante :

Visibilité nomFonction(directionParamètreN nomParamètreN : typeParamètreN) : typeRetour

Visibilité
La notion de visibilité est la même que celle des attributs.

Direction du paramètre
Indique si le paramètre est rentrant (in), s'il est sortant (out) ou s'il est rentrant et sortant (inou)

Exemple
//méthode publique yg() prenant comme paramètres taxRate et prix de types réels retournant un double
+ calculerTaxe(in taxeRate: float, in prix: float) : double
Relations entre les classes - Héritage

Représenté par un trait reliant les deux classes et dont l'extrémité du côté
de la classe mère comporte un triangle.

La classe fille hérite de tous les attributs et méthodes, qu'ils soient publics,
protégés ou privés. Cependant, elle ne peut pas utiliser directement les
attributs et méthodes privés (que ce soit en lecture ou en écriture), sauf par
l'intermédiaire d'une méthode héritée (publique ou protégée).

Exemple en Java:

class Car extends Vehicle {...}

Relations entre les classes - Association

Une association représente une relation possible entre les objets d’une
classe.

Elle peut être binaire, dans ce cas elle est représentée par un simple trait,
ou n-aire, les classes sont reliées à un losange par des traits simples.

● multiplicité : donne le nombre minimum et maximum d'instances

de chaque classe dans la relation liant 2 ou plusieurs classes.
● navigabilité : les associations sont bidirectionnelles. Lorsque
l’association est contrainte pour devenir unidirectionnelle, le sens
de navigation qui reste possible est spécifié par une flèche.
Relations entre les classes - Association

Exemple en Java:

class Child {
Mother mother;
}
class Mother {
List<Child> children;
}
Relations entre les classes - Agrégation

L'agrégation est une relation de type "ensemble / élément".

Représentée par un trait avec un losange vide côté classe

contenant.
Relations entre les classes - Agrégation

Exemple en Java:

//we can model this with separate classes

class Wheel {}
class Car {
List<Wheel> wheels;
}
//or use a static inner class
class Car {
List<Wheel> wheels;
static class Wheel {}
}
Relations entre les classes - Composition

Une relation de composition décrit une relation de

contenance et d’appartenance. Cela signifie que si nous
détruisons l'objet contenant, ses membres seront
également détruits avec lui.

L'objet contenant par contre peut exister sans aucune

de ses parties.

Représentée par un trait avec un losange rempli côté

classe contenant.
Relations entre les classes - Composition

Exemple en Java:

//we can model this with a non-static inner class

class Building {
class Room {}
}
Exemple
Exemple
Exemple
Diagramme de séquences
Diagramme de séquence

Un diagramme de séquence décrit comment et dans quel ordre plusieurs objets fonctionnent ensemble.

Il sert à:

● Représenter les détails d'un cas d'utilisation UML

● Modéliser le déroulement logique d'une procédure, fonction ou opération complexe
● Voir comment les objets et les composants interagissent entre eux pour effectuer un processus.
● Schématiser et comprendre le fonctionnement détaillé d'un scénario existant ou à venir
Représentation du diagramme de séquence

● Délimitation du diagramme de séquence

● L’objet
● La ligne de vie
● Les messages
Représentation du diagramme de séquence

Délimitation du diagramme de séquence :

Le diagramme de séquence est placé dans un rectangle qui dispose d’une étiquette sd en haut à gauche
(qui signifie sequence diagram) suivi du nom du diagramme.
Représentation du diagramme de séquence

L’objet :

Représenté par un rectangle dans lequel figure le nom de l’objet. Il peut prendre l’une des quatre formes
suivantes :
Représentation du diagramme de séquence

La ligne de vie :

Le diagramme de séquence fait entrer en action les instances de classes intervenant dans la réalisation
d’un cas d’utilisation particulier.

• A chaque objet est associée une ligne de vie (en trait pointillés à la verticale de l’objet) qui peut
être considérée comme un axe temporel (le temps s’écoule du haut vers le bas).

• La ligne de vie indique les périodes d’activité de l’objet (généralement, les moments où l’objet
exécute une de ces méthodes).

• Lorsque l’objet est détruit, la ligne de vie s’achève par une croix.
Représentation du diagramme de séquence
Représentation du diagramme de séquence

Les messages :

Un message est une communication d’un objet vers un autre objet. Plusieurs types de messages existent,
les plus communs sont :

❏ L’invocation d’une opération : message synchrone (appel d’une méthode de l’objet cible).
❏ L’envoi d’un signal : message asynchrone (typiquement utilisé pour la gestion événementielle).
❏ La création ou la destruction d’une instance de classe au cours du cycle principal.
Représentation du diagramme de séquence

Les envois de messages sont représentés par des flèches horizontales qui vont de la ligne de vie de l’objet
émetteur vers la ligne de vie de l’objet récepteur du message.

❏ Les messages synchrones : (flèche avec un triangle plein à son extrémité).

❏ Les messages asynchrones : (simple flèche)
❏ Les messages de retour (réponses) : (simple flèche en pointillés).
Représentation du diagramme de séquence
Représentation du diagramme de séquence

Une séquence peut aussi contenir la création ou la destruction d’un objet :

❏ La création d’un objet est matérialisée par un appel d’un constructeur, accompagné du stéréotype «
create » qui pointe sur le début (le sommet) de la ligne de vie de l’objet créé.
❏ La destruction d’un objet est représentée par une croix à la fin de sa ligne de vie. Le message porte le
stéréotype « destroy ».
Représentation du diagramme de séquence
Représentation du diagramme de séquence

Messages récursifs:

Un objet peut s’envoyer un message à lui-même (utilisation d’une autre méthode du même objet). Cela se
représente là aussi par un dédoublement de la bande d’activation.
Représentation du diagramme de séquence

Fragments d’interactions combinés :

Un fragment d’interactions est une partie du diagramme de séquence (délimitée par un rectangle)
associée à une étiquette (dans le coin supérieur gauche). L’étiquette contient un opérateur d’interaction
qui permet de décrire des modalités d’exécution des messages à l’intérieur du cadre.
Représentation du diagramme de séquence

Fragment d’interaction avec opérateur « opt » :

L’opérateur option (opt) comporte un opérande et une condition de garde associée. Le sous fragment
s’exécute si la condition de garde est vraie et ne s’exécute pas dans le cas contraire.
Représentation du diagramme de séquence

Fragment d’interaction avec opérateur « alt » :

L’opérateur alternatives (alt) est un opérateur

conditionnel possédant plusieurs opérandes séparés
par des pointillés.

C’est l’équivalent d’une exécution à choix multiples.

Chaque opérande détient une condition de garde.

Seul le sous-fragment dont la condition est vraie est
exécuté. La condition else n’est exécutée que si
aucune autre condition n’est valide.
Représentation du diagramme de séquence

Fragment d’interaction avec opérateur « loop » :

L’opérateur de boucle (loop) exécute une itérative dont la

séquence qu’elle contient est exécutée tant que la garde qui lui
est associée est vraie.

La garde s’écrit de la façon suivante : loop [min, max, condition]

Le contenu du cadre est exécuté min fois, puis continue à

s’exécuter tant que la condition et que le nombre d’exécution
de la boucle ne dépasse pas max fois.