Capture des exigences - Cas d utilisation Hafedh Mili INF5151-30 2005 Plan 1. Capture des exigences 2. Cas d utilisation 3. Règles d affaires 4. Exigences non fonctionnelles Copyright Hafedh Mili 1999-2005 2 1
Capture des exigences Ce que le système doit faire Comment le système doit être En tant que produit (artéfact) À l exécution Copyright Hafedh Mili 1999-2005 3 Capture des exigences Dans RUP, c est un processus continu, mais concentré sur les phases inception et élaboration Le changement est inévitable: Organiser le développement en fonction du changement Copyright Hafedh Mili 1999-2005 4 2
Types d exigences FURPS+! Fonctionnelles: fonctionnalités, sécurité Utilisabilité: ergonomie, documentation, aide en ligne Reliability (fiabilité): fréquence de pannes, recouvrement, tolérance aux fautes Performance: temps réponse, débit, disponibilité, consommation de ressources (mémoire, connections, etc.) Supportability : portabilité, maintenabilité, internationalisation, configurabilité Copyright Hafedh Mili 1999-2005 5 Autres facteurs Implementation: contraintes au niveau des ressources (personnelles ou autre), du choix du languages et outils, machines Interfaces: avec les autres systèmes Operations: comment gérer le système quand il est en production Emballage (packaging) Legal: licensing, etc. Copyright Hafedh Mili 1999-2005 6 3
Livrables Vision: description de haut niveau du système et de son apport (business case) Modèle de cas d utilisation Règles d affaires (par domaine/industrie, reglementations pertinentes, etc.) Spécification supplémentaire (ce qui n est pas fonctionnel ou non-expressible comme cas d usage) Glossaire Copyright Hafedh Mili 1999-2005 7 Plan 1. Capture des exigences 2. Cas d utilisation 3. Règles d affaires 4. Exigences non fonctionnelles Copyright Hafedh Mili 1999-2005 8 4
Cas d'usage Cas d'usage: un cas d'usage (use-case) décrit une utilisation typique du système logiciel par un acteur ( usager ) Cette utilisation correspond à l atteinte d un objectif mesurable pour l acteur Copyright Hafedh Mili 1999-2005 9 Cas d usage Les cas d'usage sont utilisés pour éliciter les exigences de l'usager (ce que le logiciel doit faire pour l'usager au niveau des fonctionnalités d affaires) Les cas d usage sont aussi utilisés dans les étapes ultérieures de développement pour décrire le comportement du système. Copyright Hafedh Mili 1999-2005 10 5
Formats de cas d usage Les cas d usage peuvent se présenter sous différents formats, dépendant de: Objectif/utilisation qui en sera faite Étape de développement Trois formats: Paragraphe textuel ( identification) Semi-élaboré ( élaboration) Complet avec bébelles et whistles ( réalisation) Copyright Hafedh Mili 1999-2005 11 Cas d'usage La description d'un cas d'usage comprend: L'identification de l'usager(appelé acteur) L objectif poursuivi par le cas d usage Le déroulement de cet usage Copyright Hafedh Mili 1999-2005 12 6
Acteurs La chose qui déclenche le déroulement du système Souvent l usager (humain) Peut être un système externe (réception d un évènement/requête externe) Peut-être un acteur interne (e.g. horloge) Copyright Hafedh Mili 1999-2005 13 Acteurs Deux types d acteurs: Primaires: l acteur qui déclenche le cas d usage, et dont les objectifs font l objet du cas d usage Secondaires: des acteurs avec lesquels le système doit intéragir pour accomplir l objectif de l acteur primaire Larman ajoute l acteur en arrière scène: ne contribue pas à la fonction, mais est intéressé par le résultat du use case Tout ce qui est reporting Copyright Hafedh Mili 1999-2005 14 7
Objectifs d un cas d usage Trois portées: Global (summary) Effectue transactions en-ligne Object acteur (user goal) Effectuer retrait Sous-fonction Identification/authentification Copyright Hafedh Mili 1999-2005 15 Déroulement de l'usage Le déroulement de l'usage est décrit par une séquence d'intéractions entre les acteurs et le système Pour chaque intéraction, on décrit l'entrée de l'usager et la réponse (sortie) du système On ne décrit pas ce qui se passe à l'intérieur du système qui, pour le moment, est une boite noire Copyright Hafedh Mili 1999-2005 16 8
Cas d'usage et scénarios Un même cas d'usage peut avoir plusieurs scénarios: Une opération bancaire à une machine peut être soit un dépôt, soit un retrait. L'usager peut se tromper dans son NIP, et devoir le re-rentrer On décrit un cas d'usage avec un scénario principal et des variations Copyright Hafedh Mili 1999-2005 17 Exemple: Réseau de machines bancaire Cas d'usage: retrait Applicabilité: La machine contient encore de l'argent L'usager détient un carte permettant d'accéder à un réseau desservi par la machine Copyright Hafedh Mili 1999-2005 18 9
Exemple (suite): Déroulement Scénario principal: 1. Usager insère sa carte dans la machine 2. Usager s'identifie 3. Système valide l'identité de l'usager 4. Système propose des opérations à l'usager 5. Usager choisit d'effectuer un retrait 6. Usager spécifie compte et montant 7. Système valide disponibilité de montant dans le compte 8. Système remet l'argent 9. Système remet un relevé à l'usager 10. Système propose à l'usager de continuer avec d'autres opérations 11. Usager demande la terminaison de la session 12. Système remet la carte à l'usager Copyright Hafedh Mili 1999-2005 19 Exemple (suite): alternatives Variations sur l'étapes 3. A. Le système ne reconnaît pas l'identité de l'usager B. Le système demande à l'usager de re-saisir son NIP C. Aller vers étape 2 du scénario principal Copyright Hafedh Mili 1999-2005 20 10
Exemple (suite): Alternatives Variations sur l'étape 11 A. Usager choisit d'effectuer d'autres opérations B. Renvoi à l'étape 4 du scénario principal Copyright Hafedh Mili 1999-2005 21 Relations entre cas d'usage Les méthodologistes ont défini plusieurs relations possibles entre cas d'usage, permettant la mise en facteur d'aspects communs, et la réutilisation de parties de cas d'usage Relations principales: Utilise (includes) Étend (extends) Généralise Copyright Hafedh Mili 1999-2005 22 11
La relation Utilise Tout cas d'usage du réseau de machines bancaires va nécessairement commencer par les intéractions: 1. Usager insère sa carte dans la machine 2. Usager s'identifie 3. Système valide l'identité de l'usager 4. Système propose des opérations à l'usager Copyright Hafedh Mili 1999-2005 23 La relation Utilise Ces quatre étapes peuvent être mises dans un cas d'usage à part On peut y référer dans les autres cas d'usage comme si c'était une seule intéraction Appelons le: Usager rentre dans la système Copyright Hafedh Mili 1999-2005 24 12
Relation Utilise Le nouveau scénario principal du cas d'usage "retrait" est: 1. Usager rentre dans le système 2. Usager choisit d'effectuer un retrait 3. Usager spécifie compte et montant 4. Système valide disponibilité de montant dans le compte 5. Système remet l'argent 6. Système remet un relevé à l'usager 7. Système propose à l'usager de continuer avec d'autres opérations 8. Usager demande la terminaison de la session 9. Système remet la carte à l'usager Copyright Hafedh Mili 1999-2005 25 Relation Étend Un cas d'usage peut en étendre un autre en remplacant une intéraction par une séquence d'intéractions ayant le même point de départ et le même point d'arrivée Copyright Hafedh Mili 1999-2005 26 13
Relation Étend: exemple Cas d'usage consultation de solde: 1. Usager rentre dans le système 2. Usager choisit de consulter les soldes de ses comptes 3. Système remet un relevé à l'usager 4. Système propose à l'usager de continuer avec d'autres opérations 5. Usager demande la terminaison de la session 6. Système remet la carte à l'usager Copyright Hafedh Mili 1999-2005 27 Relation Étend: exemple (suite) La nouvelle étape 2 remplace les étapes 2 à 5 du scénario retrait Nous dirons que le scénario retrait étend le scénario consultation de solde au point 2 Copyright Hafedh Mili 1999-2005 28 14
Utilise versus Étend A B C D E F Étend Utilise C D A B E F Copyright Hafedh Mili 1999-2005 29 Relation généralise Cette relation relie un cas d'usage ayant un but X avec un cas d'usage ayant le même but X, mais des étapes plus générales (moins précises). L'extension est un cas particulier de généralisation Copyright Hafedh Mili 1999-2005 30 15
Relation généralise (exemple) 1. etc. 2. Usager s'identifie 3. Système valide l'identité de l'usager 4. Système propose un menu de transactions à l'usager 5. Usager choisit type de transaction 6. Usager saisit paramètres de transaction 7. etc 1. etc. 2. Usager rentre carte client 3. Usager saisit NIP 4. Système valide identité de l'usager 5. Système propose menu de transactions à l'usager 6. Usager sélectionne retrait 7. Usager saisit montant de la transaction 8. etc.. Copyright Hafedh Mili 1999-2005 31 Généralise versus étend Étend est une forme particulière de généralise où à des points particuliers (points d'extension) on remplace une transaction par plusieurs amenant le système au même état Généralise est moins précise que étend et devrait être évitée Copyright Hafedh Mili 1999-2005 32 16
La notation <<communicate>> retrait <<include>> <<communicate>> (from Use Cases) Usager <<extend>> RentrerSystème (from Use Cases) consultation_solde Copyright Hafedh Mili 1999-2005 33 Use-Case dans [Larman, 1999] Cas d'usage: nom du cas d'usage Acteurs: intervenants dans le cas d'usage (usager, évènements externes, déclencheurs internes) But: but du cas d'usage Résumé: résumé de haut niveau du cas d'usage Type: primaire, secondaire, ou optionnel Références croisées: cas d'usage et fonctions systèmes reliées (voir plus loin) Scénario typique Alternatives Copyright Hafedh Mili 1999-2005 34 17
Identifier les cas d'usage Approche centrée acteurs: 1. Identifier les acteurs reliés au système ou à l'organisation 2. Pour chaque acteur (usager), identifier les processus qu'ils initient ou dans lesquels ils participent Approche centrée évènements: 1. Identifier les évènements externes auxquels doit répondre le système 2. Relier les évènements à des acteurs et cas d'usage Copyright Hafedh Mili 1999-2005 35 Cas d'usage et fonctions système Typiquement, à chaque fonction système, il correspond plusieurs cas d'usage S'assurer que chaque cas d'usage rentre dans le cadre d'une fonction système, S'assurer que chaque fonction système est supporté par au moins un cas d'usage Copyright Hafedh Mili 1999-2005 36 18
Classification des cas d'usage et planification Les classer par ordre d'importance (primaires, puis secondaires, puis optionnels) Planifier les primaires pour le premier incrément Planifier les cas d'usage ayant une influence sur l'architecture [Jacobson et al., 1998] Copyright Hafedh Mili 1999-2005 37 19