www.iepacongo.edu.
cg
INSTITUT D'ENSEIGNEMENT
PROFESSIONNEL APPLIQUE
Année scolaire 2024-2025
COURS DE
CONCEPTION
ORIENTEE OBJET
LICENCE 2
M.KAYA GOMA PONTIEN | DEVELOPPEUR FULL-STACK,
CONSULTANT SEO/SEA & FORMATEUR EN INFORMATIQUE
[email protected] | 066803598 / 050956316
1
CHAPITRE 2 : LE DIAGRAMME DE CAS D’UTILISATION
I-INTRODUCTION
Le diagramme de cas d’utilisation est un type de diagramme UML
comportemental et est fréquemment utilisé pour analyser divers
systèmes. Ils vous permettent de visualiser les différents types de rôles
dans un système et la façon dont ces rôles interagissent avec le
système. UML n’est donc pas un langage de programmation, mais un
langage de modélisation. C’est une méthode standardisée qui décrit un
système en cours de conception, ou déjà existant. Cela se fait à l’aide
de diagrammes, dans lesquels tous les objets impliqués sont structurés
et liés les uns aux autres.
I.1-IMPORTANCE DES DIAGRAMMES DE CAS D’UTILISATION
Les diagrammes de cas d’utilisation sont utilisés pour recueillir les
exigences d’utilisation d’un système. En fonction de vos besoins, vous
pouvez utiliser ces données de différentes manières.
• Identifier les fonctions et la façon dont les rôles interagissent
avec elles – L’objectif premier de l’utilisation des diagrammes de
cas.
• Pour une vision de haut niveau du système – Particulièrement
utile lors de la présentation aux gestionnaires ou aux parties
prenantes. Vous pouvez mettre en évidence les rôles qui
interagissent avec le système et les fonctionnalités fournies par
le système sans avoir à vous plonger dans les rouages internes
du système.
2
• Identifier les facteurs internes et externes – Cela peut sembler
simple mais dans le cadre de grands projets complexes, un
système peut être identifié comme un rôle externe dans un autre
cas d’utilisation.
II-LES ELEMENTS D’UN DIAGRAMME DES CAS D’UTILISATION
Les diagrammes de cas d’utilisation se composent de 4 objets.
• Acteur
• Cas d’utilisation
• Les relations
• Paquet
II.1-L'ACTEUR
Il représente un élément externe qui interagit avec le système. Cet
élément peut être un utilisateur ou un système tiers (autre ordinateur,
autre programme, base de données).
Tous les éléments extérieurs qui stimulent le système et tous les
éléments extérieurs qui sont utilisés par le système sont représentés
par des acteurs.
Dans le cas d'acteurs non-humains il est possible de définir une «
Interface » qui représente les opérations offertes par cet acteur.
Il est possible de représenter un acteur sous forme d'un bonhomme
comme ci-dessous à gauche ou sous forme d'un classeur comme ci-
dessous à droite.
3
II.2-LE CAS D'UTILISATION
Un cas d'utilisation représente une fonctionnalité du système.
Cette fonctionnalité est définie par une action déclenchante, un ou
plusieurs déroulements possibles et éventuellement une fin.
Les différents déroulements aussi appelés scénarii seront modéliser
par des diagrammes de séquence, d'activité ou d'état.
Le cas d'utilisation se représente par une ellipse contenant un nom
décrivant la fonctionnalité et éventuellement un stéréotype.
NB: Le nom du use case doit se composer d'un verbe à l'infinitif qui
décrit une action. Pour que l'ensemble du modèle soit cohérent il faut
choisir tous les verbes soit du point de vue du système soit du point de
vue de l'utilisateur (ce qui est généralement préférable).
II.3-LES RELATIONS DES DIAGRAMMES DE CAS D'UTILISATION
En langage UML, une relation est une connexion entre des éléments
de modèle. Une relation UML est un type d'élément de modèle qui
4
ajoute une sémantique à un modèle en définissant la structure et le
comportement entre les éléments de modèle.
II.3.1-RELATIONS D'ASSOCIATION
Dans les modèles UML, une association est une relation entre deux
discriminants, tels que des classes ou des cas d'utilisation, qui décrit
les causes de la relation et les règles qui régissent la relation.
II.3.2-RELATIONS DE GENERALISATION
Dans la modélisation UML, une relation de généralisation est une
relation dans laquelle un élément de modèle (l'enfant) est basé sur un
autre élément de modèle (le parent). Les relations de généralisation
sont utilisées dans les diagrammes de classes, de composants, de
déploiement et de cas d'utilisation pour indiquer que l'enfant reçoit
tous les attributs, opérations et relations qui sont définis dans le
parent.
5
II.3.3-RELATIONS D'INCLUSION
Dans la modélisation UML, une relation d'inclusion est une relation
dans laquelle 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).
La relation d'inclusion prend en charge la réutilisation des
fonctionnalités dans un modèle de cas d'utilisation.
II.3.4-RELATIONS D'EXTENSION
Dans la modélisation UML, vous pouvez utiliser une relation
d'extension pour spécifier qu'un cas d'utilisation (l'extension) étend le
comportement d'un autre cas d'utilisation (la base). Ce type de relation
révèle des détails sur un système ou une application qui est
généralement masqué dans un cas d'utilisation.
6
II.3.5-PAQUET
Le paquet est un autre élément optionnel extrêmement utile dans les
diagrammes complexes. Tout comme les diagrammes de classe, les
packages sont utilisés pour regrouper les cas d’utilisation. Ils sont
dessinés comme l’image ci-dessous.
II.4-COMMENT CREER UN DIAGRAMME DE CAS D’UTILISATION
Identification des acteurs
Les acteurs sont des entités externes qui interagissent avec votre
système. Il peut s’agir d’une personne, d’un autre système ou d’une
organisation. Dans un système bancaire, l’acteur le plus évident est le
client. Les autres acteurs peuvent être employés de banque ou
caissiers, selon le rôle que vous essayez de jouer dans le cas
d’utilisation.
Identification des cas d’utilisation
7
Une bonne façon de le faire est d’identifier ce dont les acteurs ont
besoin de la part du système. Dans un système bancaire, un client
devra ouvrir des comptes, déposer et retirer des fonds, demander des
carnets de chèques et autres fonctions similaires. Tous ces éléments
peuvent donc être considérés comme des cas d’utilisation.
Les cas d’utilisation de haut niveau devraient toujours fournir une
fonction complète requise par un acteur. Vous pouvez étendre ou
inclure des cas d’utilisation en fonction de la complexité du système.
Une fois que vous avez identifié les acteurs et le cas d’utilisation de
haut niveau, vous avez une idée de base du système. Vous pouvez
maintenant l’affiner et y ajouter des couches de détails
supplémentaires.
Rechercher une fonctionnalité commune à utiliser Inclure
Recherchez des fonctionnalités communes qui peuvent être réutilisées
dans l’ensemble du système. Si vous trouvez deux ou plusieurs cas
d’utilisation qui partagent une fonctionnalité commune, vous pouvez
extraire les fonctions communes et les ajouter à un cas d’utilisation
distinct. Vous pouvez ensuite le connecter via la relation d’inclusion
pour montrer qu’il est toujours appelé lorsque le cas d’utilisation
original est exécuté.
Est-il possible de généraliser les acteurs et les cas d’utilisation
Il peut y avoir des cas où les acteurs sont associés à des cas
d’utilisation similaires tout en déclenchant quelques cas d’utilisation
qui leur sont propres. Dans de tels cas, vous pouvez généraliser l’acteur
8
pour montrer l’héritage des fonctions. Vous pouvez également faire une
chose similaire pour les cas d’utilisation.
L’un des meilleurs exemples est le cas d’utilisation “Effectuer un
paiement” dans un système de paiement. Vous pouvez également le
généraliser à “Payer par carte de crédit”, “Payer en espèces”, “Payer
par chèque”, etc. Tous ces cas ont les attributs et la fonctionnalité du
paiement avec des scénarios spéciaux qui leur sont propres.
Fonctions optionnelles ou fonctions supplémentaires
Certaines fonctions sont déclenchées de manière optionnelle. Dans ce
cas, vous pouvez utiliser la relation d’extension et lui associer une règle
d’extension. Dans l’exemple de système bancaire ci-dessous, la
fonction “Calculer le bonus” est facultative et ne se déclenche que
lorsqu’une certaine condition est remplie.
L’extension ne signifie pas toujours qu’elle est facultative. Parfois, le
cas d’utilisation lié par l’extension peut compléter le cas d’utilisation
de base. Ce qu’il faut retenir, c’est que le cas d’utilisation de base doit
pouvoir remplir une fonction par lui-même, même si le cas d’utilisation
étendu n’est pas appelé.
II.4.1-REPRESENTATION D’UN DIAGRAMME DE CAS
D’UTILISATION
Dans un diagramme de cas d’utilisation :
• Les acteurs sont représentés par des stick figures (personnages
stick).
• Les cas d’utilisation sont représentés par des ellipses.
9
• Les relations entre acteurs et cas d’utilisation sont représentées
par des lignes de communication.
Diagramme de cas d'utilisation Un cas d'utilisation est une séquence
d'actions et ses variantes nommées scénarii. Le scénario correspond à
un chemin d'exécution du cas d'utilisation.
II.5-MODELISATION DES BESOINS AVEC UML
Comment identifier les acteurs ?
Les acteurs peuvent être identifiés en observant les utilisateurs ou
systèmes externes qui interagissent avec le système. Ces acteurs
doivent avoir des besoins ou des objectifs spécifiques à accomplir à
l'aide du système.
Comment recenser les cas d’utilisation ?
Les cas d’utilisation peuvent être identifiés en se concentrant sur les
besoins des acteurs. Chaque cas d’utilisation doit correspondre à une
fonction ou action que l'acteur doit accomplir pour atteindre son
objectif.
10
Description textuelle des cas d’utilisation
Chaque cas d’utilisation doit être décrit textuellement, en détaillant les
préconditions, les flux d’événements (scénarios principaux et
alternatifs), les postconditions et les exceptions.
III-DESCRIPTION TEXTUELLE DE CAS D’UTILISATION
Un nom ne suffit pas à comprendre le détail de ce que recouvre un cas
d’utilisation. Il est donc nécessaire d’adjoindre à chaque cas
d’utilisation une description détaillée. Cette description est parfois
textuelle et composée de plusieurs rubriques dont les plus importantes
sont :
Le scénario nominal : enchaînement d’actions typiques dans le cas où
les choses se passent comme prévu.
Les enchaînements alternatifs : enchaînements dans des cas
particuliers.
NB : A ce jour, aucune normalisation n'a été proposée pour la
description textuelle. Celle-ci doit inclure :
- le titre, le résumé, la date de création et de modification, la
version, le responsable et les acteurs participants, etc.
III.1-NOTIONS GENERALES DU LANGAGE UML
Paquetage
Un paquetage (Package) est un mécanisme de regroupement pour
organiser un modèle. Il permet de diviser un grand modèle en sections
plus petites et plus compréhensibles.
Espace de noms
11
L’espace de noms définit la portée des éléments dans un modèle,
permettant de résoudre les conflits de noms entre éléments
similaires.
Classeur
Un classeur est un regroupement logique des éléments du modèle,
permettant de les organiser par catégorie.
Stéréotype
Un stéréotype est un mécanisme qui permet d'étendre le langage
UML en créant de nouveaux types d'éléments. Par exemple, un cas
d’utilisation peut être stéréotypé comme <<interface>>.
Note
Les notes sont utilisées pour ajouter des explications textuelles dans
un diagramme UML.
IV-CONCLUSION
Au cours des dernières années, les diagrammes UML sont devenus un
outil beaucoup plus puissant pour documenter divers processus
d’entreprise ou flux de travail. Au départ, seuls les développeurs de
logiciels et les professionnels du secteur informatique utilisaient
l’UML, mais aujourd’hui, de nombreuses personnes utilisent les
diagrammes UML dans leur travail quotidien et les ont adoptés dans
différents secteurs d’activité.
12
