UML
(Unified Modeling Language)
Langage standardisé pour la modélisation des
systèmes logiciels
la Modélisation Orient e Objet
La Conception Oriente Objet (COO) est la méthode qui
conduit des architectures logicielles fondes sur les objets du
système, plutôt que sur une décomposition fonctionnelle.
Qu’est-ce que UML ?
- UML (Unified Modeling Language) est un langage visuel
standardisé.
- Permet de représenter les différents aspects d’un système
(logiciel ou autre).
- Créé dans les années 1990 par Grady Booch, Ivar Jacobson et
James Rumbaugh.
- Standardisé par l’OMG (Object Management Group).
Pourquoi utiliser UML ?
- Clarifier les idées et visualiser les systèmes complexes.
- Fournir un langage commun pour les développeurs, analystes,
et parties prenantes.
- Standardiser la modélisation des systèmes logiciels.
- Documenter les besoins, les conceptions et les fonctionnalités
des systèmes.
Objectifs d'UML
- Modéliser visuellement les composants d’un système.
- Décrire les besoins fonctionnels et non fonctionnels.
- Faciliter la communication entre les équipes.
- Standardiser les pratiques de conception et d’analyse.
Types de diagrammes UML
1. Diagrammes structurels :
- Diagramme de classes
- Diagramme de composants
- Diagramme de déploiement
2. Diagrammes comportementaux :
- Diagramme de cas d’utilisation
- Diagramme de séquence
- Diagramme d’activités
- Diagramme d’états
Types de diagrammes UML
Diagramme de cas
d’utilisation
Définition et intérêt
• Le développement d’un logiciel permet de répondre à un
ensemble de besoins exprimés par l’utilisateur futur du
système.
Définition
• Par exemple, l’EMSI demande un logiciel pour :
Gérer les salles de cours et de tp;
Gérer les absences des étudiants
Assurer le suivi des stages
Etc.
• Chacun des besoins exprimés par l’utilisateur futur
du logiciel (que nous appelons acteur en UML) est
un cas d’utilisation.
Un cas d’utilisation
Un cas d’utilisation est un ensemble de séquences d’actions
exécutées par le système pour rendre un service à un ou
plusieurs acteurs.
Un cas d’utilisation
modélise un aspect dynamique du système.
permet de visualiser le comportement d’un système ou d’un
sous-système
exprime les interactions entre les acteurs et le système (sauf
exceptions)
décrit le comportement attendu sans imposer le mode de
réalisation
Correspond à une fonction métier du système selon le point
de vue des acteurs.
un cas d’utilisation
• ne décrit pas la manipulation de l’IHM (interface homme
machine)
• ne décrit pas la gestion des problèmes matériels
• n’est pas une fonction
• ne doit pas se réduire à une seule séquence d’actions
Un acteur
• Un acteurs est une entité extérieure au système modélise , et
qui interagit directement avec lui.
• Les acteurs impliqués dans un cas d'utilisation lui sont liés par
une association.
Un acteur
Les principaux acteurs sont les utilisateurs du système.
Un acteur correspond à un rôle, pas à une personne physique.
Une même personne physique peut être représentée par plusieurs
acteurs si elle a plusieurs rôles.
Si plusieurs personnes jouent le même rôle vis-à-vis du système,
elles seront représentées par un seul acteur.
En plus des utilisateurs, les acteurs peuvent être :
• Des périphériques manipulés par le système (imprimantes...) ;
• Des logiciels déjà disponibles à intégrer dans le projet ;
• Des systèmes informatiques externes au système mais qui
interagissent avec lui, etc.
Pour faciliter la recherche des acteurs, on se fonde sur les frontières
du système.
Exemple
• Considérons une station-service de distribution d'essence. Les
clients se servent de l'essence et le pompiste remplit les
cuves.
• Question : Le client se sert de l'essence de la façon suivante : il
prend un pistolet accroché à une pompe et appuie sur la
gâchette pour prendre de l'essence. Qui est l'acteur du
système ? Est-ce le client, le pistolet?
Exercice : Système de Vente en Ligne
Un site de vente en ligne permet aux utilisateurs de parcourir
des produits, les ajouter à un panier, effectuer un paiement, et
suivre leurs commandes. Les administrateurs peuvent gérer les
produits et vérifier les statistiques de vente.
Elaborer un diagramme de cas d’utilisation
Exemple:
• Considérons une station-service de distribution d'essence. Les clients se servent de
l'essence et le pompiste remplit les cuves.
• Le pompiste, peut se servir de l'essence pour sa voiture. Pour
modéliser cette activité de pompiste, doit-on définir un nouvel
acteur ? Comment modélise-t-on ça ?
Exemple:
• Certains pompistes sont aussi qualifiés pour opérer des
opérations de maintenance en plus
• des opérations habituelles des pompistes telles que le
remplissage des réservoirs. Ils sont donc réparateurs
• en plus d'être pompistes. Comment modéliser cela ?
Généralisation , Héritage
• Généralisation : Le directeur peut faire tout ce que fait le
commercial
Exercice1 : Gestion des Commandes d’un
Système de Livraison
• Un système de livraison permet à ses utilisateurs de passer
des commandes et de suivre leurs livraisons. Les
administrateurs du système peuvent gérer les utilisateurs et
superviser les livraisons. Parmi les utilisateurs, il y a deux sous-
types spécifiques : Client régulier : Peut passer des
commandes et suivre ses livraisons. Entreprise : Peut passer
des commandes en gros, suivre ses livraisons, et consulter des
rapports sur les commandes.
• Identifiez les acteurs
• Identifiez les cas d’utilisation pour chaque acteur.
• Dessinez un diagramme de cas d’utilisation
Relations entre cas d'utilisation
• Inclusion : le cas A inclut le cas B (B est une partie obligatoire de A).
• La notion d'« include » est utilisée pour modéliser une
dépendance obligatoire entre deux cas d'utilisation. Elle indique
qu’un cas d’utilisation principal inclut un autre cas d’utilisation
secondaire à un moment donné de son déroulement.
Inclusion: Exemple
Inclusion
• Cas principal et cas inclus :
Le cas principal représente une fonction ou une action de haut
niveau.
Le cas inclus est une fonctionnalité ou une action qui doit être
exécutée dans le cadre du cas principal.
• Relation obligatoire :
Le cas inclus est toujours exécuté lorsque le cas principal est
activé.
Inclusion
Extension
Extension : le cas B tend le cas A (B est une partie optionnelle de A).
La notion d'« extend » est utilisée pour modéliser une relation
optionnelle ou conditionnelle entre deux cas d'utilisation. Elle
indique qu’un cas d’utilisation secondaire peut ajouter un
comportement spécifique au cas d’utilisation principal sous
certaines conditions.
Extension
• Cas principal : C'est le cas de base qui représente une fonction
principale du système.
• Cas étendu : C'est un cas d'utilisation qui ajoute des comportements
supplémentaires ou des fonctionnalités optionnelles au cas principal.
• Relation optionnelle ou conditionnelle :
Contrairement à « include », le cas étendu n’est pas systématiquement
exécuté.
Différence entre « include » et « extend »
Aspect Include Extend
Relation Obligatoire Optionnelle / conditionnelle
Le cas principal inclut le cas
Sens Le cas secondaire étend le principal.
secondaire.
Réutiliser une fonctionnalité Ajouter une fonctionnalité spécifique
Utilisation
commune. selon une condition.
Différence visuelle entre
<<include>> et <<extend>> :
Relation Direction de la flèche Exemple
<<include>> Cas principal → Cas inclus Passer une commande → S’identifier
Passer une commande-> Profiter d’une
<<extend>> Cas étendu → Cas principal
promotion
Relations entre cas d'utilisation
Généralisation
• Généralisation : le cas A est une généralisation du cas B (B est
une sorte de A).
Héritage
Généralisation : ‘Paiement CB ‘ est un cas particulier de ‘Payer’
‘Virement ‘ est un cas particulier de ‘Payer’
Relations entre cas d'utilisation
Exemple: