Comment trouviez vous ce cours ?

0(0%)
0
0(0%)

Appéciations du lecteurs :

Visualisations : 192
Appreciations : 0

A propos de l'auteur :

R@chid
Email: victrachild@yahoo.com
Validation du cour :

UML - Diagramme de cas d'utilisation

Diagramme de cas d’utilisation cours et exemples

 

 

Diagramme de cas d’utilisation

    UML permet de construire plusieurs modèles d’un système : certains montrent le système du point de vue des utilisateurs, d’autres montrent sa structure interne, d’autres encore en donnent une vision globale ou détaillée. Les modèles se complètent et peuvent être assemblés.

     Ils sont élaborés tout au long du cycle de vie du développement d’un système (depuis le recueil des besoins jusqu’à la phase de conception). Dans ce chapitre, nous allons étudier un des modèles , en l’occurrence le premier à construire : le diagramme de cas d’utilisation.

 

Il permet de recueillir, d’analyser et d’organiser les besoins. Avec lui débute l’étape d’analyse d’un système.

 

L’importance de bien recueillir les besoins

    Le développement d’un nouveau système, ou l’amélioration d’un système existant, doit répondre à un ou à plusieurs besoins. Par exemple, une banque a besoin d’un guichet automatique pour que ses clients puissent retirer de l’argent même en dehors des heures d’ouverture de la banque. Celui qui commande le logiciel est le maître d’ouvrage. Celui qui réalise le logiciel est le maître d’oeuvre.

 

Le maître d’ouvrage intervient constamment au cours du projet, notamment pour :

• définir et exprimer les besoins ;

• valider les solutions proposées par le maître d’oeuvre ;

• valider le produit livré.

   Le maître d’oeuvre est, par exemple, une société de services en informatique (SSII). Il a été choisi, avant tout, pour ses compétences techniques. Mais son savoir-faire va bien au-delà. Au début du projet, il est capable de recueillir les besoins auprès du maître d’ouvrage. Le recueil des besoins implique une bonne compréhension des métiers concernés. Réaliser un logiciel pour une banque, par exemple, implique la connaissance du domaine bancaire et l’intégration de toutes les contraintes et exigences de ce métier.

    Cette condition est nécessaire pour bien cerner les cas d’utilisation exprimés par le client afin d’apporter les solutions adéquates.

    Chaque cas a ses particularités liées au métier du client. Le recueil des besoins peut s’opérer de différentes façons. Cela dit, il est recommandé de compléter le cahier des charges par des discussions approfondies avec le maître d’ouvrage et les futurs utilisateurs du système. Il convient également d’utiliser tous les documents produits à propos du sujet (rapports techniques, étude de marché…) et d’étudier les procédures administratives des fonctions de l’entreprise qui seront prises en charge par le système. La question que doit se poser le maître d’oeuvre durant le recueil des besoins est la suivante :

ai-je toutes les connaissances et les informations pour définir ce que doit faire le système ?

 

1. Le diagramme de cas d’utilisation

    1.1. Les cas d’utilisation

Parlons à présent d’UML et voyons quelle aide il peut apporter lors du recueil des besoins. UML n’est qu’un langage et il ne sert ici qu’à formaliser les besoins, c’est-à-dire à les représenter sous une forme graphique suffisamment simple pour être compréhensible par toutes les personnes impliquées dans le projet. N’oublions pas que bien souvent, le maître d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d’exprimer leurs besoins. C’est précisément le rôle des diagrammes de cas d’utilisation. Ils permettent de recenser les grandes fonctionnalités d’un système.

        Exemple

La figure 1.1 modélise une borne interactive qui permet d’accéder à une banque. Le système à modéliser apparaît dans un cadre (cela permet de séparer le système à modéliser du monde extérieur). Les utilisateurs sont représentés par des petits bonshommes, et les grandes fonctionnalités (les cas d’utilisation) par des ellipses.

Figure 1.1
Diagramme de cas d’utilisation modélisant une borne d’accès à une banque.
 

bonshommes sont appelés « acteurs ». Ils sont connectés par de simples traits (appelés « associations ») aux cas d’utilisation et mettent en évidence les interactions possibles entre le système et le monde extérieur. Chaque cas modélise une façon particulière et cohérente d’utiliser un système pour un acteur donné.

        Définition

Un cas d’utilisation est une manière spécifique d’utiliser un système. Les acteurs sont à l’extérieur du système ; ils modélisent tout ce qui interagit avec lui. Un cas d’utilisation réalise un service de bout en bout, avec un déclenchement, un déroulement et une fi n, pour l’acteur qui l’initie.

        Notation et spécification

Un cas d’utilisation se représente par une ellipse (figure 1.2). Le nom du cas est inclus dans l’ellipse ou bien il figure dessous. Un stéréotype (voir la définition ci-après), peut être ajouté optionnellement au-dessus du nom, et une liste de propriétés placée au-dessous.

Un cas d’utilisation se représente aussi sous la forme d’un rectangle à deux compartiments : celui du haut contient le nom du cas ainsi qu’une ellipse (symbole d’un cas d’utilisation) ; celui du bas est optionnel et peut contenir une liste de propriétés (figure 1.3).

Un acteur se représente par un petit bonhomme ayant son nom inscrit dessous (figure 1.1) ou par un rectangle contenant le stéréotype acteur avec son nom juste en dessous (figure 1.4). Il est recommandé d’ajouter un commentaire sur l’acteur pour préciser son rôle.

 
 
 representation-use-case
Figure 1.2 et 1.3
Représentations d’un cas d’utilisation.
 representation-acteur
Figure 1.4
Autre représentation d’un acteur.
 

La figure 1.4 représente un acteur par un rectangle. UML utilise aussi les rectangles pour représenter des classes, et plus généralement des classeurs. Pour autant, la notation n’est pas ambiguë puisque le stéréotype acteur indique que le rectangle désigne un acteur. Les stéréotypes permettent d’adapter le langage à des situations particulières.

        Définition

Un stéréotype représente une variation d’un élément de modèle existant. À un niveau d’abstraction plus élevé, UML permet de représenter tous les cas d’utilisation d’un système par un simple rectangle. La figure 1.5 montre comment un tel rectangle peut remplacer tous les cas d’utilisation de la figure 1.1.

 representation-use-case
 
Figure 1.5
Représentation des cas d’utilisation à un niveau d’abstraction élevé.
 

Le rectangle de la figure 1.5 est appelé « classeur ».

       Définition

Un classeur est un élément de modélisation qui décrit une unité comportementale ou structurelle. Les acteurs et les cas d’utilisation sont des classeurs. Tout au long de ce livre, on retrouvera le terme « classeur » car cette notion englobe aussi les classes, des parties d’un système, etc.

        Notation

Un classeur se représente par un rectangle contenant éventuellement des compartiments (la figure 1.6 montre comment il est possible de faire figurer explicitement des cas d’utilisation dans un classeur).

 classeur-uml
Figure 1.6
Les compartiments d’un classeur.
 

Un acteur peut utiliser plusieurs fois le même cas d’utilisation.

        Exemple

La figure 1.7 montre un internaute qui télécharge plusieurs morceaux de musique sur Internet.

 association-multiplicite
Figure 1.7
Association avec multiplicité.
 

Le symbole * qui signifie « plusieurs » est ajouté à l’extrémité du cas et s’appelle une multiplicité. Plusieurs valeurs sont possibles pour la multiplicité : exactement n s’écrit tout simplement n, m..n signifie entre m et n, etc. Préciser une multiplicité sur une relation n’implique pas nécessairement que les cas sont utilisés en même temps.

    1.2.  Relations entre cas d’utilisation

Pour clarifier un diagramme, UML permet d’établir des relations entre les cas d’utilisation. Il existe principalement deux types de relations : les dépendances stéréotypées et la généralisation/spécialisation. Les dépendances stéréotypées sont des dépendances dont la portée est explicitée par le nom du stéréotype. Les stéréotypes les plus utilisés sont l’inclusion et l’extension.

• La relation d’inclusion . Un cas A est inclus dans un cas B si le comportement décrit par le cas A est inclus dans le comportement du cas B : on dit alors que le cas B dépend de A. Cette dépendance est symbolisée par le stéréotype inclut. Par exemple, l’accès aux informations d’un compte bancaire inclut nécessairement une phase d’authentification avec un mot de passe (figure 1.8).

• La relation d’extension . Si le comportement de B peut être étendu par le comportement de A, on dit alors que A étend B. Une extension est souvent soumise à condition. Graphiquement, la condition est exprimée sous la forme d’une note. La figure 1.8 présente l’exemple d’une banque où la vérification du solde du compte n’intervient que si la demande de retrait d’argent dépasse 20 euros.

• La relation de généralisation. Un cas A est une généralisation d’un cas B si B est un cas particulier de A. À la figure 1.8, la consultation d’un compte bancaire via Internet est un cas particulier de la consultation. Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés objet.

Les inclusions permettent aussi de décomposer un cas complexe en sous-cas plus simples.

        Exemple

À la figure 1.9, le modélisateur a jugé que la vente d’un article par correspondance est un problème complexe et qu’il est important de faire apparaître dans le modèle une décomposition en sous-cas.

       Notation et spécification

Une dépendance se représente par une flèche pointillée. Un stéréotype est souvent ajouté au-dessus du trait. 

Le stéréotype inclut indique que la relation de dépendance est une inclusion (figures 1.8 et 1.9).

Le stéréotype étend indique une extension (figure 1.8). L’extension peut intervenir à un point précis du cas étendu ; ce point s’appelle le point d’extension ; il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique « point d’extension », et est éventuellement associé à une contrainte indiquant le moment où l’extension intervient. Une extension est souvent soumise à une condition (indiquée dans une note attachée à la flèche pointillée).

Le symbole utilisé pour la généralisation est une flèche en traits pleins dont la pointe est un triangle fermé. La flèche pointe vers le cas le plus général (figure 1.8). 

 relation-cas-utilisation

Figure 1.8
Relations entre cas dans un diagramme de cas d’utilisation.
 
 relations-acteurs
 
Figure 1.9
Relations entre cas pour décomposer un cas complexe.
 

Un cas relié à un autre cas peut ne pas être directement accessible à un acteur (figure 1.9).

Un tel cas est appelé « cas interne ».

        Définition

    Un cas d’utilisation est dit « interne » s’il n’est pas relié directement à un acteur. Les relations entre cas ne sont pas obligatoires. Elles permettent de clarifier et d’enrichir les cas d’utilisation. Par exemple, à la figure 1.8, rien n’empêche de regrouper les cas « Consulter comptes » et « Consulter sur Internet » en un seul cas. Cependant, indiquer dès la phase de recueil des besoins qu’il y a des cas particuliers apporte une information

    supplémentaire pertinente. La question à se poser est : faut-il la faire figurer dans le diagramme de cas d’utilisation ou la prendre en compte plus tard ? La réponse à cette question ne sera pas toujours la même selon le contexte du projet.

        Remarque

    Attention à l’orientation des flèches : si le cas A inclut B on trace la flèche de A vers B, mais si B étend A, la flèche est dirigée de B vers A.

    2.4. Relations entre acteurs

    La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B (tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai).

        Exemple

La figure 1.10 montre que le directeur des ventes est un préposé aux commandes avec un pouvoir supplémentaire (en plus de pouvoir passer et suivre une commande, il peut gérer le stock). Le préposé aux commandes ne peut pas gérer le stock.

 relations-acteurs
Figure 1.10
Relations entre acteurs.

            Notation

Le symbole utilisé pour la généralisation entre acteurs est une flèche en traits pleins dont la pointe est un triangle fermé. La flèche pointe vers l’acteur le plus général. 

    1.3.  des cas d’utilisation en paquetages

UML permet de regrouper des cas d’utilisation dans une entité appelée « paquetage ». Le regroupement peut se faire par acteur ou par domaine fonctionnel. Un diagramme de cas d’utilisation peut contenir plusieurs paquetages et des paquetages peuvent être inclus dans d’autres paquetages.

        Définition

Un paquetage permet d’organiser des éléments de modélisation en groupe. Un paquetage peut contenir des classes, des cas d’utilisations, des interfaces, etc.

        Exemple

À la figure 1.11, trois paquetages ont été créés : Client, Stock et Support. Ces paquetages contiennent les cas d’utilisation du diagramme de la figure 1.10 (Client contient les cas « Passer une commande » et « Suivre une commande », Stock contient le cas « Gérer le stock », tandis que le cas « Rechercher article » est inclus dans le paquetage Support.

 case-use-paquetage
Figure 1.11
Regroupement des cas d’utilisation en paquetage.
 

En tant que langage, UML est soumis à des règles de nommage qu’il faut strictement respecter : pour accéder au contenu de paquetages imbriqués les uns dans les autres, il faut utiliser des deux-points comme séparateur des noms de paquetage. Par exemple, si un paquetage B inclus dans un paquetage A contient une classe X, il faut écrire A::B::X utiliser la classe X en dehors du contexte des paquetages.

 




Téléchargement ...