Spcification dtaille des exigences Dcrire de faon dtaille

Spécification détaillée des exigences § Décrire de façon détaillée les cas d’utilisation § Remplir une fiche-type pour chaque cas d’utilisation § Cette description textuelle est complétée par une représentation graphique UML très utile : le diagramme de séquence « système » 1 Ref: Pascal Roques, UML 2 Modéliser une application web, Eyrolles, 4 e édition, 2008

2

Démarche § L’expression préliminaire des besoins donne lieu à ü une modélisation par les cas d’utilisation ü et à une maquette d’interface homme-machine (IHM) § Nous avons identifié les acteurs et les cas d’utilisation § Nous allons maintenant apprendre à les décrire de façon détaillée afin d’obtenir une expression précise des besoins avant d’attaquer l’analyse et la conception objet 3

Plan-type de description textuelle des cas d’utilisation § La fiche de description textuelle d’un cas d’utilisation n’est pas normalisée par UML § Scénarios 4 ü Un cas d’utilisation peut être défini comme une collection de scénarios de succès ou d’échec qui décrit la façon dont un acteur particulier utilise un système pour atteindre un objectif ü Pour détailler la dynamique du cas d’utilisation, la procédure la plus évidente consiste à recenser de façon textuelle toutes les interactions entre les acteurs et le système ü Le cas d’utilisation doit avoir un début et une fin clairement identifiés ü Il faut aussi préciser les variantes possibles tout en essayant d’ordonner séquentiellement les descriptions afin d’améliorer leur lisibilité

Scénario § Un scénario est une suite spécifique d’interactions entre les acteurs et le système à l’étude § On peut dire que c’est une « instance » du cas d’utilisation 5

Scénario (2) § Le scénario « nominal » , celui qui satisfait les objectifs des acteurs par le chemin le plus direct de succès § Des alternatives, qui comprennent tous les autres scénarios, de succès (fin normale) ou d’échec (erreur) 6

Scénario (3) § Chaque scénario est composé d’étapes qui peuvent être de trois sortes : ü un message d’un acteur vers le système ü une validation ou un changement d’état du système ü un message du système vers un acteur § Les étapes sont numérotées séquentiellement afin de pouvoir facilement indiquer par la suite les alternatives possibles. 7

Exemple: DAB – scénario nominal Cas d’utilisation : Retirer de l’argent au distributeur (DAB) avec une carte bancaire. 1. Le porteur de carte introduit sa carte dans le DAB 2. Le DAB vérifie que la carte introduite est bien une carte bancaire. 3. Le DAB demande au porteur de carte de fournir son code d’identification. 4. Le porteur de carte entre son code d’identification. 5. Le DAB valide le code d’identification (par rapport à celui qui est codé sur la puce de la carte). 6. Le DAB demande une autorisation au système d’autorisation externe. 7. Le système d’autorisation externe donne son accord et indique le solde hebdomadaire. 8. Le DAB demande au porteur de carte de saisir le montant désiré du retrait. 9. . 8

Les alternatives § Indiquent tous les autres scénarios ou branchements possibles, aussi bien de succès que d’échec. § Elles doivent se brancher sur le scénario nominal § A une étape « X » , une première alternative se notera « Xa » . Elle identifiera d’abord la condition qui provoque l’alternative, puis la réponse du système § Le principe consiste à décrire la condition comme quelque chose qui peut être détecté par le système § Ensuite la réponse du système peut être résumée en une seule étape ou comprendre également une séquence d’étapes 9

Exemple: DAB – alternatives 2 a. La carte introduite n’est pas reconnue par le DAB. 1. Le DAB éjecte la carte et le cas d’utilisation se termine en échec. 5 a. Le DAB détecte que le code saisi est erroné, pour la première ou deuxième fois. 1. Le DAB indique au porteur de carte que le code est erroné. 2. Le DAB enregistre l’échec sur la carte et le cas d’utilisation reprend à l’étape 5 du scénario nominal. 5 b. Le DAB détecte que le code saisi est erroné, pour la troisième fois. 1. Le DAB indique au porteur de carte que le code est erroné pour la troisième fois. 2. Le DAB confisque la carte. 3. Le DAB informe le système d’autorisation externe et le cas d’utilisation se termine en échec. 10

Préconditions et postconditions § Les préconditions ü Définissent ce qui doit être vrai en amont du cas d’utilisation pour que celui-ci puisse démarrer ü Elles ne sont pas testées à l’intérieur du cas d’utilisation, mais sont tenues pour acquises ü Souvent, une précondition implique le scénario nominal d’un autre cas d’utilisation s’est déroulé normalement ü Certaines préconditions triviales n’ont pas besoin d’être mentionnées ( « Le système doit être alimenté en courant électrique… » ) : seules celles que le rédacteur juge importantes et dignes d’intérêt doivent être répertoriées § Les postconditions ü définissent ce qui doit être vrai lorsque le cas d’utilisation se termine avec succès, qu’il s’agisse du scénario nominal ou d’un scénario alternatif 11

Exemple: Quelques conditions § Préconditions ü La caisse du DAB n’est pas vide. ü La connexion avec le système d’autorisation est opérationnelle § Postconditions ü La caisse du DAB contient moins de billets qu’au début du cas d’utilisation (le nombre de billets manquants est fonction du montant du retrait) ü Une opération de retrait a été archivée (en cas de succès comme en cas d’échec) 12

Exigences supplémentaires § Très souvent, les exigences non fonctionnelles et les contraintes de conception se rapportent spécifiquement à un cas d’utilisation plutôt qu’au système dans sa totalité § Dans ce cas, on les documente dans un paragraphe complémentaire § Il s’agit par exemple de performance, de sécurité ou d’ergonomie § Exemple d’exigences supplémentaires (pour le DAB) ü Un scénario nominal de retrait doit durer moins de 2 minutes dans 90 % des cas 13

Exemple de Spécification détaillée des cas d’utilisation Livre: UML 2 – Modéliser une application Web Pages 62 -71 14

Diagrammes de séquence système DSS § Nous utilisons le terme de diagramme de séquence « système » pour souligner le fait que nous considérons le système informatique comme une boîte noire § Le comportement du système est décrit vu de l’extérieur, sans préjuger de comment il le réalisera § Nous ouvrirons la boîte noire seulement en conception 15

Diagrammes de séquence système DSS (2) § Les cas d’utilisation décrivent les interactions des acteurs avec le system qu’on veut spécifier et concevoir § Lors de ces interactions, les acteurs produisent des messages qui affectent le système informatique et appellent généralement une réponse de celui-ci § Nous allons isoler ces messages et les représenter graphiquement sur des diagrammes de séquence UML 16

Diagrammes de séquence système DSS (3) § Pour les messages propres à un cas d’utilisation, les DSS montrent non seulement les acteurs externes qui interagissent directement avec le système, mais également ce système (en tant que boîte noire) et les événements système déclenchés par les acteurs § L’ordre chronologique se déroule vers le bas et l’ordre des messages doit suivre la séquence décrite dans le cas d’utilisation 17

Quelques exemples de DSS Pour plus d’exemples de DSS, voir Livre: UML 2 – Modéliser une application Web Pages 71 -77 18

Chercher des ouvrages § Il faut repartir de la description textuelle détaillée du cas d’utilisation et transformer chaque étape en une flèche représentant un message § L’acteur principal (Internaute) est représenté à gauche du diagramme et le système (Je. Bouquine) à droite. Notez le mot-clé «system» que nous avons utilisé dans la boîte représentant le système boîte noire pour le différencier encore plus nettement des acteurs (surtout lorsqu’il y aura des acteurs non humains dans les scénarios) 19

Ligne de vie Le système informatique n’est actif que lorsqu’il est sollicité par un acteur, alors que les acteurs sont a priori toujours actifs. Cette notation est optionnelle 20

Chercher des ouvrages (2) § UML 2 fournit quelques notations complémentaires très utiles § Des rectangles, appelés fragments d’interaction, sont ainsi utilisables pour indiquer qu’un groupe de messages est ü optionnel (mot-clé opt) ü répété (mot clé loop) ü alternatif (mot-clé alt) § Nous utilisons ces nouvelles notations pour indiquer que : ü On peut effectuer soit une recherche rapide soit une recherche avancée ü On peut optionnellement mettre l’ouvrage trouvé dans le panier ü La recherche d’ouvrages est répétable à volonté… 21

La précondition du cas d’utilisation peut également être matérialisée graphiquement grâce au symbole d’état sur la ligne de vie Optionnel 22

§ Il est possible de représenter le cas d’erreur où le système ne trouve pas d’ouvrage correspondant à la requête § Il suffit d’ajouter un cadre alt, contenant un cadre break (pour indiquer que les messages suivants, comme la sélection et la mise dans le panier, ne sont pas possibles) 23

Rappel § Enterprise Architect § Dreamweaver/Open. Element 24

Opérations systèmes § Les événements système envoyés par les acteurs déclenchent des traitements internes appelés : Opérations système § L’ensemble des opérations système de tous les cas d’utilisation définit: ü l’interface publique du système, ü qui visualise le système comme une entité unique, ü boîte noire offrant des services § En UML, le système peut être représenté par une classe, avec le mot-clé «system» 25

Opérations système (2) Opérations système du site web d’après les cas d’utilisation décrits Cette liste n’est pas exhaustive, Elle sera progressivement complétée au fur et à mesure des itérations successives On commence à voir apparaître les fonctionnalités majeures du système 26

Définition des interfaces § Il serait également possible de commencer à définir des interfaces § Pour découper l’ensemble des opérations en groupes cohérents 27

Opérations système du site web structurées en interfaces 28

Définition des interfaces (2) § Il est aussi possible d’ajouter un lien direct avec les cas d’utilisation 29

30 Opérations système structurées en interfaces et reliées aux UC