1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice
Welcome to our Education website, plz like our page facebook to support us. Thank You and wish you good navigation

Diagramme de cas d’utilisation

abdelouafiSep 16, 2016

    1. abdelouafi

      abdelouafi Administrator Staff Member

      Messages:
      287
      Likes Received:
      9
      Trophy Points:
      18
      Joined
      Sep 13, 2016
      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.
      1- L’importance de bien recu eillir 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 e • t exprimer les besoins ;
      • valider les solutions proposées par le maître d’oeuvre ;
      • valider le produit livré.
      2- Le diagramme d e 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 fi gure 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.
      upload_2016-9-16_16-36-57.png
      L’ensemble des cas d’utilisation contenus dans le cadre constitue « un sujet ». Les petits
      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éfi nition
      Un cas d’utilisation est une manière spécifi que 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écifi cation
      Un cas d’utilisation se représente par une ellipse (fi gure 1.2). Le nom du cas est inclus dans l’ellipse
      ou bien il fi gure dessous. Un stéréotype (voir la défi nition 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 (fi gure 1.3).
      Un acteur se représente par un petit bonhomme ayant son nom inscrit dessous (fi gure 1.1) ou
      par un rectangle contenant le stéréotype acteur avec son nom juste en dessous (fi gure 1.4). Il est
      recommandé d’ajouter un commentaire sur l’acteur pour préciser son rôle.
      upload_2016-9-16_16-37-50.png
      upload_2016-9-16_16-38-7.png
      Défi nition
      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.
      upload_2016-9-16_16-39-35.png
      Le rectangle de la figure 1.5 est appelé « classeur ».
      Défi nition
      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
      fi gure 1.6 montre comment il est possible de faire fi gurer explicitement des cas d’utilisation dans
      un classeur).
      upload_2016-9-16_16-39-59.png
      2.2 Relations entre acteurs et cas d’utilisation
      Un acteur peut utiliser plusieurs fois le même cas d’utilisation.
      Exemple
      La fi gure 1.7 montre un internaute qui télécharge plusieurs morceaux de musique sur Internet.
      upload_2016-9-16_16-41-29.png

      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.
      2.3 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 fi gure 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écifi cation
      Une dépendance se représente par une fl èche pointillée. Un stéréotype est souvent ajouté audessus
      du trait.
      Le stéréotype inclut indique que la relation de dépendance est une inclusion (fi gures 1.8 et 1.9).
      Le stéréotype étend indique une extension (fi gure 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 fi gure 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 (fi gure 1.8).

      upload_2016-9-16_16-42-55.png

      upload_2016-9-16_16-43-9.png

      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éfi nition
      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 fi gure 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.
      upload_2016-9-16_16-44-22.png

      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.
       

      Attached Files:

      Loading...

Share This Page

Share