1.2.1. Les éléments de modélisation
des cas d'utilisation
a. Acteur
Un acteur représente l'abstraction d'un rôle
joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le
système étudié27. Un acteur est un rôle
joué par une personne externe, un processus ou une chose qui Interagit
avec un système. Il se représente par un petit bonhomme avec son
nom (son rôle) inscrit dessous.
Un acteur est l'idéalisation d'un rôle
joué par une personne externe, un processus ou une chose qui interagit
avec un système. Il se représente par un petit bonhomme avec son
nom (son rôle) inscrit dessous. Il est également possible de
représenter un acteur sous la forme d'un classement
stéréotypé « acteur ».
Un acteur est l'idéalisation d'un rôle
joué par une personne externe, un processus ou une chose qui Interagit
avec un système. Il se représente par un petit bonhomme avec son
nom (son rôle) inscrit dessous.
Figure 11 : Représentation d'un
acteur
b. Cas d'utilisateur
Un cas d'utilisation est une unité cohérente
d'une fonctionnalité visible de l'extérieur. Il réalise un
service de bout en bout, avec un déclenchement, un déroulement et
une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc
un service rendu par le système, sans imposer le mode de
réalisation de ce service28.
Chaque cas d'utilisation spécifie un comportement
attendu du système considéré comme un tout, sans imposer
le mode de réalisation de ce comportement. Il permet de décrire
ce que le futur système devra faire, sans spécifier comment il le
fera. Dans le cadre de la branche fonctionnelle, le cas d'utilisation doit
mettre en valeur les interactions métier entre les acteurs et le
système. On exprimera donc des actions effectuées dans le cadre
du métier de l'utilisateur, par opposition à des manipulations de
l'application ou à des comportements techniques. Par exemple, on ne
développe ni la manipulation d'une IHM (Interface Homme Machine), ni la
gestion d'erreurs matérielles au travers d'un cas d'utilisation.
L'objectif est le suivant : l'ensemble des cas d'utilisation
doit décrire exhaustivement les exigences fonctionnelles du
système. Chaque cas d'utilisation
27 PASCAL ROQUES. FRANCK VALLEE, UML 2 en Action de
l'analyse des besoins à la conception, 4è édition
28 MUSANGU LUKA, p47
42
correspond donc à une fonction métier du
système, selon le point de vue d'un de ses acteurs.
Pour chaque acteur identifié durant l'étude
préliminaire, il convient de :
· Rechercher les différentes intentions
métier avec lesquelles il utilise le système ;
· Déterminer dans le cahier des charges les services
fonctionnels attendus du système.
Un cas d'utilisation est une unité cohérente
d'une fonctionnalité visible de l'extérieur. Il réalise un
service de bout en bout, avec un déclenchement, un déroulement et
une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc
un service rendu par le système, sans imposer le mode de
réalisation de ce service.
29 Nathanaël KASORO MULENDA, Notes des cours
de la Programmation Orienté Objet, G3 Info ISP/Gombe, 20192020, p23
Figure 12 : Formalisme de base de représentation
d'un cas d'utilisation
L'interaction entre un acteur et un cas d'utilisation se
représente comme une association. Il existe quatre catégories
d'acteurs 29 :
· Les acteurs principaux ;
· Les acteurs secondaires ;
· Le matériel externe ;
· Les autres systèmes.
Un cas d'utilisation se représente par une ellipse
contenant le nom du cas (un verbe à l'infinitif), et optionnellement,
au-dessus du nom, un stéréotype.
| 
