Hamid Azzi
Les Cas d'Utilisation
Introduction au langage UML
1 Introduction
Les cas d'utilisation décrivent sous la forme d'actions et de réactions le
comportement d'un système du point de vue d'un utilisateur.
Ils permettent de définir :
1. les limites du système en fonction des utilisateurs.
2. la frontière entre le système est le monde extérieur formé par les utilisateurs ou les autres systèmes amenés à interagir avec lui.
Un cas d'utilisation est une manière spécifique d'utiliser le système.
Le système est complètement défini fonctionnellement quand on a dressé la liste de tous ses cas d'utilisation.
Les cas d'utilisation se déterminent en observant et en précisant, acteur par acteur, les scénarios (séquences d'interactions) d'utilisation du système, étape par étape. Une famille de scénarios, regroupée suivant un critère fonctionnel, forme un cas d'utilisation.
Ainsi, un cas d'utilisation est une sorte de classe dont l'instance serait le scénario.
2 Historique des Cas d’utilisation
C’est à Ivar Jacobson, auteur de la méthode Objectory que l’on doit les premières formulations.
Cette méthode a ensuite été complétée notamment par les Use case pour devenir OOSE : Object-Oriented Software Engineering.
Jacobson fait des cas d'utilisation un guide pour l'analyse des besoins et l'architecture complète d'un système logiciel.
Les cas d'utilisation recentrent l'expression des besoins sur les utilisateurs, en partant du point de vue qu'un système est construit pour eux.
La structuration de la démarche s'effectue par rapport aux interactions d'une seule catégorie d'utilisateurs à la fois ; cette partition de l'ensemble des besoins réduit considérablement la complexité de la détermination des besoins.
Hamid Azzi
Le bénéfice de cette démarche simplificatrice est double. D'une part, tous les acteurs du projet ont une meilleure compréhension du système à développer, d'autre part, les besoins des utilisateurs, une fois clarifiés, serviront de fil rouge, tout au long du cycle de développement.
A chaque itération de la phase d'analyse, on clarifie, affine et valide les
besoins des utilisateurs ;
à chaque itération de la phase de conception et de réalisation, on veille à
la prise en compte des besoins des utilisateurs
et à chaque itération de la phase de test, on vérifie que les besoins des
utilisateurs sont satisfaits.
Conclusion : il faut clarifier et organiser les besoins des clients (les modéliser).
Jacobson identifie les caractéristiques suivantes pour les modèles :
Un modèle est une simplification de la réalité.
Il permet de mieux comprendre le système qu'on doit
développer. Les meilleurs modèles sont proches de la réalité.
Les use cases, permettent de modéliser les besoins des clients d'un système et doivent aussi posséder ces caractéristiques.
Ils ne doivent pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins!
Une fois identifiés et structurés, ces besoins :
• définissent le contour du système à modéliser (ils
précisent le but à atteindre),
• permettent d'identifier les fonctionnalités principales (critiques) du
système.
Les use cases ne doivent donc en aucun cas décrire
des solutions d'implémentation.
Leur but est justement d'éviter de tomber dans la dérive d'une approche fonctionnelle, où l'on liste une litanie de fonctions que le système doit
réaliser.
3 Les cas d’utilisation
Le formalisme des cas d'utilisation -- basé sur la description de scénarios en langage naturel -- est accessible pour les utilisateurs, qui peuvent ainsi exprimer leurs attentes et leurs besoins en communiquant facilement avec les experts du domaine et les informaticiens.
La terminologie employée dans la rédaction des scénarios est celle employée par les utilisateurs dans leur vie de tous les jours, de sorte que l'expression des besoins s'en trouve grandement facilitée.
Les cas d'utilisation permettent aux utilisateurs :
• de structurer et d'articuler leurs demandes ;
• de définir la manière dont ils voudraient interagir avec le système,
• à préciser quelles informations ils entendent échanger et à décrire ce qui doit être fait pour obtenir le résultat escompté.
Les cas d'utilisation concrétisent le futur système dans une formalisation proche de l'utilisateur.
Hamid Azzi Ils favorisent la définition d’un cahier des charges qui reflète réellement les besoins, même en l’absence d’un système à critiquer.
3.1 Les flots d’événements
Chaque cas d’utilisation est décrit par un flot d’évènements.
Il s’agit de la suite des évènements qui permettent d’accomplir la fonctionnalité requise par le cas d’utilisation.
Celle-ci est réalisée dans le langage du domaine en faisant référence aux objets du domaine.
En phase d’analyse, c’est une démarche efficace pour faire apparaître les objets du domaine.
Le langage du domaine est le langage du Client ou du spécialiste avec lequel on décrit le modèle des besoins.
Il est en général nécessaire de créer un Glossaire des termes utilisés, ce glossaire définit le langage du domaine.
Les Objets du domaine sont les entités réelles ou conceptuelles que manipule le client et le système.
Ils sont utilisés à la fois pour écrire le modèle des besoins mais constituent également un bon point de départ pour faire émerger les classes du système. Les Flots d’évènements décrivent ce que le système doit faire et non pas comment il le fait.
Les flots d’évènements doivent intégrer :
• Quand et comment le cas d'utilisation commence et se termine • Les interactions du cas d'utilisation et des acteurs
• Les données nécessaires au cas d'utilisation • La séquence normale d’évènements
• La description de tous les flots d’événements alternatifs ou exceptionnels (erreurs).
La description du flot d’évènements est une opération importante qui doit être menée de façon itérative avec le client.
Une première itération consiste à décrire brièvement les étapes nécessaires pour réaliser le scénario standard du cas d’utilisation (ce qui est fourni par le cas d’utilisation).
Un scénario est un chemin particulier au travers de la description abstraite et générale fournie par le cas d’utilisation.
Les scénarios traversent le cas d’utilisation, en suivant le chemin nominal des chemins alternatifs et exceptionnels.
L’explosion combinatoire fait qu’il est bien souvent impossible de dérouler tous les scénarios (toutes les combinaison du chemin principal avec les chemins alternatifs et exceptionnels).
Avec la progression de l’analyse, les différentes étapes sont raffinées. Finalement les scénarios de gestion d’exceptions sont créés.
Hamid Azzi Un projet doit définir un modèle de création de flots d’événements qui possède la structure suivante :
1. Flot d’évènements pour le cas d’utilisation<<nom du cas>> 2. Pré conditions
3. Flot Principal
4. Flots Alternatif (si nécessaire) 5. Flots d’exceptions
3.2 Formalisme de représentation
Le modèle des cas d’utilisation comprend au moins quatre éléments : 1. les acteurs
2. le système
3. le ou les cas d’utilisation par eux-mêmes. 4. les liens entre ces différents éléments
Ainsi, les fonctionnalités d’un système sont déterminées en examinant les besoins fonctionnels de chaque acteur, exprimés sous la forme de familles d’interactions dans les cas d’utilisation.
3.2.1 Les acteurs
Ils sont représentés sous la forme de petits personnages qui déclenchent des cas d’utilisation représentés par des ellipses contenues par le système.
Un acteur A un acteur B
Figure 1: Représentation des acteurs
Les acteurs se déterminent en observant les utilisateurs directs du système, ceux qui sont responsables de son exploitation ou de sa maintenance, ainsi que les autres systèmes qui interagissent avec le système en question.
Un acteur étant défini par son rôle dans l’interaction avec le scénario d’utilisation, il peut être constitué par un autre sous-système interne et donc modélisé par un autre scénario d’utilisation.
Les acteurs potentiels se recrutent parmi les utilisateurs, les partenaires, les autres systèmes, c’est à dire, les personnes et les éléments extérieurs à un système qui interagissent avec lui en échangeant de l’information.
Un diagramme de cas d’utilisation ne se construit pas en une seule fois. La détermination des acteurs permet de préciser les limites du système de manière progressive : floues au départ, elles se précisent au fur et à mesure de l’élaboration des différents cas d’utilisation.
Hamid Azzi contractuelle où est signalé ce qui doit être fait, ce qui fait partie du système à développer.
Elle précise également les éléments intangibles, que l’équipe de développement ne peut pas modifier.
Il existe quatre grandes catégories d’acteurs :
1. Les acteurs principaux qui regroupent les personnes utilisant les fonctions
principales du système.
2. Les acteurs secondaires qui regroupent les personnes réalisant des tâches
nécessaires au fonctionnement du système, mais n’étant pas à l’origine de son activation
3. Les autres systèmes regroupant les systèmes avec lesquels le système doit interagir.
4. Le matériel externe. Il ne s’agit pas de l’ordinateur sur lequel s’exécute l’application, mais des autres dispositifs matériels.
3.2.2 Les Cas d’utilisation
Un cas d’utilisation regroupe une famille de scénarios d’utilisation selon un critère fonctionnel.
Les cas d’utilisation sont des abstractions du dialogue entre les acteurs et le système : ils décrivent des interactions potentielles, sans entrer dans les détails de chaque scénario.
Ils peuvent être vus comme des classes dont les instances sont les scénarios.
UN CAS D’UTILISATION X
Figure 2:Un Cas d’Utilisation se représente sous la forme d’un ovale
Chaque fois qu’un acteur interagit avec le système, le cas d’utilisation instancie un scénario ; ce scénario correspond au flot de messages échangés par les objets durant l’interaction particulière qui correspond au scénario.
L’analyse des besoins par les cas d’utilisation correspond à une approche itérative et incrémentale.
Hamid Azzi 3.2.3 Notion de scénario
Un scénario est une séquence d’événements se déroulant dans le temps. C’est une instance d’un cas d’utilisation du système.
En général, un cas d’utilisation comporte plusieurs scénarios.
Figure 4 : Représentation de scénarios alternatifs d'un cas d'utilisation
Un événement est une transmission d’information, une communication soit entre : • un acteur et un objet,
• un objet et un autre objet, • un objet et lui- même.
En général on formalise un scénario par une liste numérotée d’actions. Bien que ne faisant pas partie directement du formalisme UML,
les scénarios ont fait l’objet d’une normalisation, sous la forme de fiche standardisées.
Voici le cas d’utilisation « téléphoner » avec pour acteur principal « Pierre » et comme acteur secondaire « Paul »
Hamid Azzi Un des scénarios possibles est le suivant :
1. Pierre décroche son téléphone 2. Le téléphone active la ligne du RTC 3. Le réseau envoie la tonalité
4. Pierre compose le numéro de Paul 5. Le réseau valide le numéro
6. Le réseau recherche le correspondant 7. Le téléphone de Paul sonne
8. Au bout de quelques sonneries, Pierre raccroche 9. La ligne de Pierre est libérée
En général, un scénario est formalisé à l’aide d’un diagramme de séquence d’objets. Ce diagramme fera l’objet d’une description détaillée dans le document à venir. Les cas d’utilisations font l’objet de raffinage par un processus itératif. Le développement de plusieurs scénarios permet de faire apparaître des séquences particulières de communication entre objets :
1. des séquences communes à des scénarios différents
2. des séquences particulières liées à un ou des scénarios particuliers
Cela conduit à créer d’autres cas d’utilisation, que l’on peut considérer comme des « sous-cas » et qui sont reliés au cas principal par des relations qui ont été normalisées. On les appelle « stéréotypes »
3.2.4 Les relations dans les cas d’utilisation
UML prédéfinit quatre types particuliers de relations dans un diagramme de cas d’utilisation.
Voici, à titre d’exemple, un ensemble de cas d’utilisation d’un système que l’on appelle « Etablissement commercial ».
Dans une première phase d’analyse, les différents cas sont définis, sans que l’on puisse détecter de façon certaine les relations qui peuvent exister entre eux. Ce sont les scénarios, illustrés par des diagrammes de séquence d’objets qui permettront de mettre en évidence ces relations particulières, grâce à des séquences communes ou optionnelles.
Hamid Azzi Figure 6 : Les différents cas d'utilisation du système « Etablissement commercial »
Hamid Azzi L’analyse des diagrammes de séquence d’objet correspondant à chacun des cas fait apparaître les relations suivantes :
Figure 7 : Les mêmes cas raffinés et reliés 3.2.4.1 La relation <<Association>>
C’est la seule relation autorisée entre un acteur et un cas d’utilisation. C’est une relation de communication. La participation de l ’ a c t e u r est signalée par un trait ou une flèche entre l ’ a c t e u r et le cas d’utilisation.
Elle peut porter des cardinalités.
Figure 8: Une relation stéréotypée «association »
Hamid Azzi 3.2.4.2 La relation <<Extend>>
Une relation d’extension entre cas d’utilisation signifie que le cas d’utilisation source étend le comportement du cas d’utilisation destination.
C’est une relation entre deux instances de scénarios telle que A étend B signifie que le comportement d’un scénario B peut être complété par le développement d’un scénario A. Par exemple dans la figure 8 ci-dessous, le cas d’utilisation « Acheter à crédit » étend le cas d’utilisation « Acheter ». « Acheter à crédit » comporte les mêmes opérations que« acheter », mais également des opérations supplémentaires liées à la demande et la mise en œuvre du crédit.
La relation <<Extend>> doit spécifier à la fois : la condition de l’extension
le point d’extension, c’est à dire l’endroit où l’extension doit être faite dans le cas d’utilisation général.
La relation <<Extend>> spécifie donc une possibilité, une option.
Figure 9: La relation stéréotypée "extend"
Hamid Azzi 3.2.4.3 La relation <<Include>>
Une relation <<include>> entre cas d’utilisation signifie qu’une instance du cas d’utilisation « source » comprend également le comportement décrit par le cas d’utilisation « destination ».
C’est une relation entre deux instances de scénarios
d’utilisations, telle que la réalisation de la fonction de l’un nécessite la réalisation de la fonction de l’autre.
Elle signifie donc qu’une instance du cas d’utilisation « source » comprend (inclut) également le comportement décrit par le cas d’utilisation de destination.
Dans la figure 9, le cas d’utilisation « Acheter » inclut le cas d’utilisation « Payer ».
Figure 11 : La relation stéréotypée "Include"
Hamid Azzi Elle exprime la relation de « généralisation / spécialisation » qui sera présentée en détail lors de l’étude du diagramme de classes.
Elle est souvent désignée par le concept "est une sorte de".
A l’inverse des précédentes, il s’agit d’une relation entre deux cas d’utilisation et non entre des instances.
Figure 13 : La relation stéréotypée "Génaralize"
En effet, les cas d’utilisation interviennent tout au long du cycle de vie, depuis le cahier des charges jusqu’aux tests, en passant par l’analyse,la conception, la réalisation et la rédaction de la documentation pour l’utilisateur.
De ce point de vue, il est possible de naviguer vers les classes et les objets qui collaborent pour satisfaire un besoin, puis vers les tests qui vérifient que le système s’acquitte correctement de sa tâche.
Hamid Azzi 3.3.1 Les Scénarios
Comme nous l’avons déjà vu, un cas d’utilisation correspond à un ensemble de scénarios, chacun d’entre eux étant formalisé par un diagramme de séquence d’objet ou un diagramme de collaboration.
Bien qu’UML ne préconise pas explicitement un cycle de développement particulier, les cas d’utilisation induisent un enchaînement particulier dans l’utilisation des diagrammes.
Cet enchaînement consiste à regarder le système à construire de l’extérieur, du point de vue de l’utilisateur et des fonctionnalités qu’il en attend.
Chaque cas d’utilisation consiste en un ensemble de « scénarios possibles ».
C’est leur étude qui permettra de mettre en évidence des factorisations possibles dans le cas des <<include>>, des options dans le cas des <<extend>> et des généralisations spécialisations.
Un scénario peut être employé de deux manières :
comme une spécification de ce qu’il sera possible de demander de l’extérieur à l’entité ainsi représentée comme une spécification de la fonctionnalité offerte par cette même entité (déjà réalisée).
D’un point de vue méthodologique, il décrit un ensemble cohérent de fonctions pour l'utilisateur.
Les diagrammes des scénarios d'utilisation modélisent donc à la fois des activités (fonctionnalités) et des communications (interactions) pour les entités concernées.
3.3.2 Processus d’élaboration des Cas d’Utilisation
Au moment la construction des cas d'utilisation, il faut se demander : 1. quelles sont les responsabilités de l'acteur vis à vis du système?
2. quelles sont les informations qu’il devra créer, sauvegarder, modifier, détruire ou simplement lire ?
3. devra-t-il informer le système des changements externes ?
4. le système devra-t-il informer l'acteur de l’évolution interne du système ? Les cas d'utilisation peuvent être présentés aux travers de vues multiples :
un acteur avec tous ses cas d'utilisation un cas d'utilisation avec tous ses acteurs
Les cas d'utilisation peuvent également être groupés selon leurs séquences de déclenchement types, c'est-à-dire en fonction de leurs enchaînements, ou encore en fonction des différents points de vue, souvent corrélés aux grandes catégories d'acteurs (client, fournisseur, maintenance...).
Hamid Azzi 3.3.3 Règles de mise en œuvre
Un cas d'utilisation décrit non seulement une fonctionnalité ou une motivation, mais aussi une interaction entre un acteur et un système sous la forme d'un flot d’événements.
La description de l'interaction se concentre sur ce qui doit être fait dans le cas d'utilisation, pas sur la manière de le faire.
Un cas d'utilisation doit rester simple et compréhensible par le donneur d’ordre qui n’est pas obligatoirement un spécialiste de la modélisation conceptuelle.
La description d'un cas d'utilisation comprend les éléments suivants :
1. le début du cas d'utilisation, c’est à dire l'événement qui le déclenche. Il doit être clairement exprimé avec une assertion du type : « Le cas débute quand l’événement X se produit. » ;
2. de façon symétrique, la fin de celui-ci, c’est à dire l'événement qui cause l'arrêt du cas d'utilisation. Lui aussi doit être clairement identifié et documenté par une assertion du type : « Quand l’événement Y se produit, le cas d'utilisation est terminé. » ;
3. l'interaction entre le cas d'utilisation et les acteurs qui décrit clairement les limites du système ;
4. les échanges d'informations entre le système et les acteurs. Une formulation en langage naturel est préférable à toute autre, par exemple : « Le Client demande des renseignements concernant les compositions florales au vendeur» ;
5. la chronologie et l'origine des informations qui décrivent quand le système a besoin d'informations internes ou externes et quand il les enregistre à l'intérieur ou à l'extérieur ;
6. les comportements répétitifs
7. les situations optionnelles qui doivent apparaître clairement à l’aide de
formulations du type de: «L'acteur choisit l'un des éléments suivants, éventuellement plusieurs fois de suite »
Ces points ne suffisent pas pour obtenir un bon cas d'utilisation. Il est également primordial de trouver le bon niveau de granularité, c'est-à-dire la quantité de détails qui doivent apparaître, et de faire la distinction entre un cas d'utilisation qui est obligatoirement conceptuel et un scénario qui est nécessairement contingent. Il n’existe pas de méthodologie apportant une aide dans ce domaine. L'appréciation du niveau de granularité repose essentiellement sur l'expérience.
3.3.4 LeCas d’Utilisation : un processus d'élaboration itératif et contractuel
La modélisation par les Cas d’Utilisation est une technique imprécise, assez difficile à mettre en œuvre.
Néanmoins, elle apparaît comme un document contractuel sur lequel le donneur d'ordre et l'exécutant peuvent travailler.
Elle permet de vérifier qualitativement la conformité du produit avec les spécifications.
Ce « mal nécessaire » vient du fait que le donneur d'ordre ignore la façon dont le produit sera conçu et que le donneur d'ordre pense essentiellement aux « fonctionnalités » du futur système.
La modélisation par Cas d’Utilisation adopte un formalisme assez simpliste, ce qui facilite la compréhension par tout le monde, surtout aux non initiés aux pratiques objet.
Hamid Azzi Une bonne modélisation par les Cas d’Utilisation doit répondre à la question : que fait le système à un haut niveau et jamais comment il le fait (WHAT et NOT HOW) ?
Doit-on décomposer les Cas d’Utilisation et partir dans les techniques de réduction de complexité ?
Réponses:
1. NON lorsqu’on est capable, avec les Cas d’Utilisation en place, d’estimer l’ampleur du projet.
2. OUI en considérant les sous-systèmes comme des systèmes « indépendants » en soi. Avec cette démarche, on s’assure que la décomposition respecte le principe d’indépendance des sous systèmes. On s’assurera que les sous-systèmes peuvent être considérés comme des objets à part entière.
Quelques recettes pour établir les cas d’utilisation
Étape 1: Identifiez les « usagers » du système. Ce sont les acteurs avec le stéréotype « acteur ». Lorsqu’un système est subdivisé en sous-systèmes plus élémentaires, un sous-système peut devenir un acteur pour un autre sous système et n’a rien d’humain. Dans ce cas, servez-vous du stéréotype « classe » pour l’acteur si le sous-système qui agit en tant qu’acteur s’apparente à un objet.
Étape 2: Différenciez les acteurs si la nature du problème l’exige. Cherchez les propriétés communes de ces acteurs. Factorisez éventuellement un acteur commun et dérivez (si possible) les autres acteurs à partir de cet acteur commun
Étape 3: Choisissez l'acteur type ou l'acteur le plus important. Cherchez ce que cet acteur peut faire avec votre système et identifiez les premiers Cas d’Utilisation de base
Étapes 4: Étudiez chaque Cas d’Utilisation de base. S'il a l'air complexe et ne vous permet pas d'estimer l'ampleur du projet, identifiez les Cas d’Utilisation sous-jacents les plus importants sans caractériser à cette étape-ci les relations entre les Cas d’Utilisation (include, extend, etc.)
Étape 5: Décrivez en détail chaque Cas d’Utilisation, aussi bien des Cas d’Utilisation de base que les Cas d’Utilisation sous-jacents. C'est une étape importante car elle permet de clarifier ce que vous voulez confier comme tâches à votre système. Cette description est consultée, d'un côté, par le donneur d'ordre, de l'autre, par les développeurs. Bien que la description soit TEXTUELLE, restez PRÉCIS, CONCIS
Ne pas faire mention de l'interface usager dans cette description car ce faisant, vous ligotez les bras du développeur.
Étape 6: Trouvez maintenant les traitements communs dans les descriptions et cherchez les possibilités de factorisation. Dégagez si possible les Cas d’Utilisation « factorisés »
Étape 7: Établissez maintenant les liens stéréotypés pour préciser la sémantique de votre analyse un peu plus technique de la spécification.
Étape 8: Vous devez recommencer les étapes 4 à 7 pour tous les Cas d’Utilisation de base.
Étape 9: Identifiez les acteurs secondaires (par exemple, les acteurs de maintenance et recommencez les étapes de 2 à 8 pour les acteurs secondaires)
Hamid Azzi
4 Conclusion
Ce document est une première présentation de l’articulation entre les trois éléments qui constituent toujours une première approche d’un processus d’analyse « objet » utilisant les digrammes UML :
1. Cas d’utilisation (généraliste) 2. Scénarios correspondants
3. Pour chacun des scénarios, diagramme de séquence d’objets
L’observation des diagrammes de séquences va nous amener à considérer qu’il existe parfois des séquences de messages entre objets qui se retrouvent d’un diagramme à l’autre.
Il faut alors envisager un regroupement de ces séquences en une séquence unique qui constituera un « sous-cas d’utilisation » relié au cas principal par un <<include>>.
A l’opposé, il peut se trouver une sous séquence particulière renvoyant plutôt à une option possible.
Ce sera alors un sous cas d’utilisation correspondant à une extension du cas principal. Il sera relié par une relation <<extend>>.
Tout cela n’est possible que par une approche itérative entre les trois composants déjà cités (Cas d’utilisation, scénarios, diagrammes de séquences). L’objectif est de raffiner le cas d’utilisation jusqu’à obtenir un niveau de décomposition et de granularité pertinents au regard de l’analyse que nous conduisons.
Enfin, une dernière précision qui peut paraître évidente pour tout le monde, mais l’expérience montre qu’il est souvent nécessaire de la reformuler.
Dans un premier temps, les scénarios et les diagrammes de séquence représentent l’activité des objets de la réalité, c’est à dire des choses, des gens, etc….Ce n’est que dans un second temps qu’ils donneront naissance à des objets informatiques.
Garder cela présent à l’esprit, c’est garantir que le futur système sera une image fidèle (aussi fidèle que possible !) de la réalité
Hamid Azzi
5 Annexe :
Fiche de description d’un scénario de cas d’utilisation Préparation du diagramme de séquence d’objets Nom du Cas d’Utilisation
Inclut Est inclus Etend Spécialise Généralise Acteur principal Acteur(s) secondaire(s) Pré condition(s) Scénario
Liste des objets Description
Exceptions Post condition(s)
Hamid Azzi Index du texte :
1 Introduction... 1
2 Historique des Cas d’utilisation ... 1
3 Les cas d’utilisation ... 3
3.1 Les flots d’événements... 4
3.2 Formalisme de représentation... 5
3.2.1 Les acteurs... 5
3.2.2 Les Cas d’utilisation ... 6
3.2.3 Notion de scénario ... 6
3.2.4 Les relations dans les cas d’utilisation ... 8
3.3 Construction des Cas d’utilisation ... 14
3.3.1 Les Scénarios ... 14
3.3.2 Processus d’élaboration des Cas d’Utilisation... 15
3.3.3 Règles de mise en œuvre ... 15
3.3.4 LeCas d’Utilisation : un processus d'élaboration itératif et contractuel 16 4 Conclusion... 18
5 Annexe : ... 20
Index des figures : Figure 1: Représentation des acteurs... 5
Figure 2:Un Cas d’Utilisation se représente sous la forme d’un ovale... 6
Figure 3: Un scénario d'un cas d'utilisation... 6
Figure 4 : Représentation de scénarios alternatifs d'un cas d'utilisation... 7
Figure 5 : le cas d'utilisation "Téléphoner" ... 7
Figure 6 : Les différents cas d'utilisation du système « Etablissement commercial » . 9 Figure 7 : Les mêmes cas raffinés et reliés ... 10
Figure 8: Une relation stéréotypée «association »... 11
Figure 9: La relation stéréotypée "extend" ... 12
Figure 10 : Exemple d’extension à partir d’un scénario nominal... 12
Figure 11 : La relation stéréotypée "Include" ... 13
Figure 12 : Exemple d'inclusion dans un scénario nominal ... 13
