SEG 3601 Élaboration de cas d`utilisations avec UCEd
publicité
SEG 3601 Élaboration de cas d'utilisation avec UCEd Stéphane S. Somé SITE, Université d' Ottawa Use Case Editor (UCEd) •Objectif: aider à la capture/validation de cas d'utilisation ― Edition de cas d'utilisation ― Edition du modèle de domaine ― Edition de scénarios ― Validation de cas d'utilisation du modèle de domaine ― Combinaison de cas d'utilisation en modèles à états ― Simulation de modèles exécutables dérivés de cas d'utilisation ― Génération de scénarios Éléments d'UCEd •UCEd inclus ― Outil d'édition de cas d'utilisation – pour écrire les cas d'utilisation ― Outil d'édition du modèle du domaine – pour édition du domaine ― Outil d'édition de scénarios – pour spécification de scénarios ― Outil de simulation – pour validation de cas d'utilisation et du domaine Édition de cas d'utilisation Modèle de cas d'utilisation Description de cas d'utilisation Modèle de cas d'utilisation Inclus Cas d'utilisation cas normal cas d'extension Relations “include” “extend” condition d'extension Acteurs Description de cas d'utilisation (1) Cas d'utilisation normal Description de cas d'utilisation (2) • Title: label identifiant le cas d'utilisation de façon unique • Description: texte qui fait un sommaire du cas d’usage • System Under Design: spécifie le système (l’entité qui réagi aux stimuli des acteurs externes) • Scope: spécifie ce qui est considéré comme boîte noire selon le design (ex: entreprise, système, sous-système, fonction…) • Level: niveau de détail du cas d'utilisation • Primary Actor: l'acteur qui initie le cas d'utilisation • Participants: autre acteurs participant au cas d'utilisation • Goal: énoncé de l'attente de l'acteur primaire lors de la complétion du cas d'utilisation Description de cas d'utilisation (3) • Following Use Cases: une liste des cas d’usage qui peuvent suivre directement • Invariant: condition devant être vérifiée tout au long de l'exécution d'une instance du cas d'utilisation • Precondition: condition devant être vérifiée avant l'exécution • Postcondition: condition devant être vérifiée à la fin de l'exécution • Steps: séquence d'étapes (blocs répétés et de steps) constituant le cas d'utilisation • Alternatives: étapes alternatives Description de cas d'utilisation - Conditions •Plusieurs types ― Conditions simples – Entity bound conditions: basées sur les entités du domaine – Non-Entity bound conditions: déclarées verbatim dans le modèle du domaine ― Conditions complexes – négation, conjonction, disjonction de conditions simples Description de cas d'utilisation - Conditions • Condition simple (entity-bound) ' [déterminant] entité verbe valeur ● Déterminant: a, an, ou the ● Entité: séquence de mots nommant une entité du modèle du domaine (voir plus loin) ● Verbe: un parmi is, isn't, is not, are, aren't, are not, has, hasn't, has not, have, haven't, have not ● Valeur: – séquence de mots définie comme une valeur possible de l'entité dans le modèle du domaine – comparaison Description de cas d'utilisation - Conditions •Exemples de conditions simples The User Card is not valid User number of attempts is > 3 The System Display is blinking System registered users are less than 10 .... Description de cas d'utilisation - Conditions •Conditions complexes ― Négation NO condition NOT condition ex: Not User identification is valid. ― Conjonction condition AND condition ― Disjonction condition OR condition Description de cas d'utilisation - Étapes •Types d'étapes (step) ― instance d'opération – Peuvent comprendre des extensions ― branchement, ou ― inclusion de cas d'utilisation Description de cas d'utilisation - Étapes •Instance d'opération ― exécution d'opération par un concept (acteur ou système) [spécification de délai] [expression conditionnelle] [déterminant] entité référence_opération Description de cas d'utilisation - Étapes •Spécification de délai before valeur unité after valeur unité •Peuvent être combinés •Unité : mmsec, microsecond, msec, millisecond, sec, second, min, minute, h, hour, day •Exemples ― after 10 sec ― before 60 sec AND after 20 sec Description de cas d'utilisation - Étapes •Expression conditionnelle IF condition THEN Description de cas d'utilisation - Étapes • Déclaration d'opération ― Opérations doivent être déclarées comme suit dans le modèle du domaine action_verbe [action_objet] – action_verbe - verbe à l'infinitive – action_objet – séquence de mots ex: insert card, display personal identification enter personal identification number ... Description de cas d'utilisation - Étapes • Référence d'opération verbe_action_conjugué [mot_relation] objet_action ― verbe_action_conjugué : verbe d’action au présent ― mot_relation: – adjectif his, her ou its – article a, an, the – préposition to, for Description de cas d'utilisation - Étapes •Exemples ― before 60 sec, the user inserts a card ― IF the system is ON THEN, the operator turns the system OFF ― System displays pin enter prompt to Customer ― after 2 min, the ATM ejects the user card Description de cas d'utilisation - Étapes •Branchements [spécification_délai] [expression_conditionnelle] GOTO STEP référence_étape • Exemples ― IF User number of attempts > 4 THEN GOTO STEP 4 ― after 10 sec, GOTO STEP 1 ― GOTO STEP 3 Description de cas d'utilisation - Inclusions •Inclusion de cas d'utilisation [expression_conditionnelle] include [use case] nom_cas_usage •Exemples ― include use case login user ― If USER identification is not valid THEN include login failure Description de cas d'utilisation - Inclusions •Instruction de continuation [expression_conditionnelle] continue [use case] •Dans un cas d’usage inclus, spécifie à partir d’un scénario particulier que le cas d’usage parent se continuera. ― Par défaut, l’exécution continue seulement du scénario principal d’un cas d’usage inclus. Including Use Case IncludedUC 1. ... 2. ... 3. include includedUC 4. ... STEPS 1. ... 2. ALTERNATIVES 1.a. ... 1.a.1 ... 2.a. ... branches to continue Including Use Case IncludedUC 1. ... 2. ... 3. include includedUC 4. ... STEPS 1. ... 2. ALTERNATIVES 1.a. ... 1.a.1 ... 1.a.2 continue 2.a. ... branches to continue continue Description de cas d'utilisation - Inclusions • Instruction resume [expression_conditionnelle] resume [in parallel] [use case] nom_cas_usage • Exemples ―resume withdraw cash, deposit cash, print record ―resume in parallel ship goods, send invoice 1. ... 2. ... 3. resume uc1, uc2 if event1 UC1 1. ... event1 2. ... 3. ... 4. ... 1. ... 2. ... 3. resume in parallel uc1, uc2 if event2 UC2 1. event2 2. ... 3. ... 4. ... Only one use case executes UC1 1. ... event1 2. ... 3. ... 4. ... UC2 1. event2 2. ... 3. ... 4. ... Both use cases execute in parallel Description de cas d'utilisation – Extensions • Comportement alternatif pouvant suivre l'étape • Inclus ● ● ● Condition d'extension – Condition selon laquelle l'extension a lieu Étapes (steps) ● Les alternatives ne peuvent pas avoir d’autres alternatives Postcondition alternative ● Postcondition de l’alternative Description de cas d'utilisation – Extensions • Condition d'extension – peut être ● ● ● ● ● délai before, délai after combinaison de délais before et after condition, combinaison de délais et expression conditionnelle • Exemples ● ● ● ● after 30 sec before 2 min AND after 20 sec The User identification is not valid after 60 sec, IF Bank hasn't responded Exemple de description de cas d'utilisation Title: User login System Under Design: PMSystem Description: This use case describes a login process in the PMSystem. The use case is executed by a User (Doctor or Nurse). Scope: Outermost Scope Level: User Primary Actor: User Participants: Goal: A User want to identify herself in order to use a PM system. Precondition: System is ON AND NO user is logged in Following Use Cases: log out, admit patient, discharge patient Steps: 1: The User inserts a Card in the card slot Extension Point ==> card inserted 2: The PMSystem asks for PIN 3: The User types a PIN Extension Point ==> pin entered 4: The PMSystem validates the USER identification 5: IF the USER identification is valid THEN The PMSystem displays a welcome message to the USER 6: After 60 sec The PMSystem ejects the Card Success Postcondition: User is logged in Alternatives: 1a: User Card is inserted 1a1: User presses cancel button 1b1: PMSystem ejects Card Alternative Postcondition: User is not logged in 1b: The Card is not regular 1b1: The PMSystem emits an alarm 1b2: After 20 sec The System ejects the Card Alternative Postcondition: User is not logged in 2a: after 60 seconds 2a1: PMSystem emits alarm 2b1: After 20 sec PMSystem ejects Card Alternative Postcondition: User is not logged in 4a: The user identification is invalid AND number of attempts is less than 4 4a1: Goto Step 2 4b: User identification is invalid AND number of attempts is equal to 4 4b1: The PMSystem emits an alarm 4b2: After 20 sec The PMSystem ejects the Card Alternative Postcondition: User is not logged in Description de cas d’usage: répétitions repeat while condition étapes repeat every spécification_durée étapes repeat every spécification_durée while condition étapes Title: Monitor Patient Precondition: PMSystem is ON AND Patient status is monitoring Success Postcondition: PMSystem is ON AND Patient status is monitoring STEPS 1. Repeat every 10 sec 1.1.PMSystem reads vital signs 1.2.PMSystem checks vital signs 1.3.PMSystem displays vital signs REPEAT BLOCK ALTERNATIVES 1.1.a.Patient vital sign is unreadable 1.1.a.1.PMSystem starts a System status alarm 1.2.a.Patient vital sign status is out of physiologic limits 1.2.a.1.PMSystem starts a Patient status alarm Cas d'utilisation d'extensions •Utilisés pour étendre des cas d'utilisation normaux à des points d'extensions (extension points) •Inclus ― Titre ― Une ou plusieurs parties (Parts) avec – référence à un point d'extension (défini dans le cas d'utilisation de base en référence à une étape), – séquence d'étapes (steps) Exemple de cas d'utilisation d'extension Title: Login secure Parts: At extension point card inserted 1: The PMSystem logs the transaction At extension point pin entered 1: The PMSystem logs the transaction Modèle du domaine •Sert comme: ― Glossaire pour les concepts – System Concept – représente le système considération – Ensemble de Concepts – représentant les acteurs ― Spécification des opération – préconditions – postconditions Modèle du domaine • Description de concepts ● ● ● liste de valeurs possibles attributs – avec valeurs possibles opérations – précondition – postcondition ● ● ● ● added-conditions (conditions ajoutées) withdrawn-conditions (conditions retirées) Sous-concepts (relation d'héritage) Sous-composantes (relation d'agrégation) Modèle du domaine •Valeurs possibles ― caractéristiques pouvant être utilisées pour qualifier une entité ― définissent un attribut sur la valeur d’état d’un objet ― ex: pour condition – The User identification is valid – valid doit être déclaré comme valeur possible de User identification Modèle du domaine •Précondition d'opération ― doit être vérifiée pour que l'opération soit possible ― ex: Opération eject card d'un guichet automatique – une Card doit être insérée – on pourrait avoir la précondition: User Card is inserted Modèle du domaine • added-condition d'opération ― Qu’est-ce qui devient vrai après l'opération ? ― ex: Opération display pin enter prompt du GA – display (l'écran) affichera le prompt – on pourrait avoir comme condition-ajoutée ATM Display is pin enter prompt (suppose que pin enter prompt est une valeur possible d'ATM Display) Modèle du domaine • withdrawn-condition d'opération ― quelle condition est retirée après l'opération ? ― était vraie avant, mais n'est plus pertinent après ― ex: Opération eject card du GA – après éjection de sa Carte l'identification de l'usager (User identification) n'est plus pertinente (besoin de la réinitialiser) – on pourrait avoir la condition-retirée (withdrawncondition) User identification is valid – si User identification is valid est vrai après l'opération eject card, cette condition est retirée (User identification devient unknown) Modèle du domaine •withdrawn-condition d'opération ― pour retirer toutes les conditions liées à une entité ANY ON entité ex: ANY ON User ― pour retirer toutes les conditions liées à une entité ainsi qu'à ces sous-entités (attributs, composantes, etc) ANY ON entité* ex: ANY ON User* Exemple de modèle du domaine UML Effets d'opérations ● ask for PIN – ● Add: Display is pin enter prompt validate USER identification – Add: USER identification is valid OR USER identification is invalid – Withdraw: Display is pin enter prompt ● eject Card – Pre: USER Card is inserted – Add: No Card is inserted – Withdraw: ANY ON USER* ● insert Card – Add: USER CARD is Représentation UCEd du domaine Génération d'éléments du domaine à partir de cas d'utilisation wizard ● aide à extraire ● Concepts, ●Attributs, ●Valeurs Possibles ●Noms d'opérations à partie de cas d’usage ● Machines à états •Générés de cas d'utilisation et opérations valides Deux approches pour les générer: basée sur les flots de contrôle des cas d’usage basée sur les opérations (preconditions et postconditions) Scénarios • Séquence d'interactions impliquant un système et ses acteurs • Un cas d'utilisation inclus plusieurs scénarios • Un scénario peut traverser plusieurs cas d'utilisation • Les scénarios sont utiles pour ― documenter les interactions d'intérêt voulues ou pas – scénario positif – doit être supporté – scénario négatif – devrais pas être supporté ― pour servir comme scripts répétables de simulation Scénarios • Ce qui est inclus: ― Description textuelle ― Triggers : opérations d'acteurs (concept du modèle de domaine) ― System reactions : opérations du système considéré (system concept du modèle de domaine) ― Waiting delays: points où un certain temps passe sans trigger ou system reaction ― Guard realizations: conditions devenant vraies à un certain point du scénario ― Assertions: conditions devant être vraies à un certain point du scénario Scénarios Assertion Trigger Guard Reaction Delay Simulation •Pour valider les cas d'utilisation et opérations •Simulation de machines à états générées •Simulation manuelle ― en utilisant un GUI généré par UCEd ― simulations enregistrées comme scénarios •Simulation automatisée ― simulation de scénarios Simulation opération d'acteurs résultats Simulation Simulation de Scénario Processus d'élaboration des exigences statement of requirements use cases use case creation domain information preliminary domain extraction operation effects specification of operations scenarios state machine generation operation effects use cases validation no more use cases ? use cases integration Processus d'élaboration des exigences • Élaborez un cas d'utilisation à la fois ― pour cas d'utilisation complexes, quelque scénarios à la fois • Ré-initialiser (Reset) la machine à états entre cas d'utilisation • Intégrez les cas d'utilisation à la fin Processus d'élaboration des exigences (I) • Pour chacun des cas d'utilisation 1. utilisez l'outil d'édition pour écrire le cas d'utilisation 2. extrayez les éléments du domaine du cas d'utilisation 3. générez des machines à états à partir des cas d’utilisation • Validez par simulation/inspection Processus d'élaboration des exigences 4. ajoutez des effets aux opérations • • déterminez des effets pour chaque opération peut nécessiter l'introduction de plus d'éléments (ex: attributs, valeurs possibles au domaine) 5. créer une machine à états basée sur les opérations 6. valider la machine à états • • • par inspection de la machine générée par simulation manuelle par simulation de scénarios (possiblement générés de simulations précédentes) Processus d'élaboration des exigences: Problèmes courants • Erreurs de Génération (ex: non-déterminisme) • Simulation n'est pas conforme aux attentes • Généralement ― provoqué par un manque d'effets des opérations nécessaires pour faire la distinction entre états ― important de spécifier les conditions ajoutées et retirées • Vérifier manuellement la machine à états finis Sources •Pour ― Télécharger UCEd ― Obtenir le guide de l’utilisateur ― Obtenir des articles sur UCEd http://www.site.uottawa.ca/~ssome/Use_Case_Editor_UCEd.html
