Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d

03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 1/8 ACCUEIL CURSUS COURS ADMISSIONS CAMPUS DOCUMENTATION ANCIENS ENTREPRISES LIBRAIRIES PUBLICATIONS 1 - Recherche des besoins fonctionnels : Les cas d’utilisation 2 - Analyse fonctionnelle : description des scénarios des cas d’utilisation 3 - Les besoins non fonctionnels : Les spéciÕcations Supplémentaires UML : Recherche et analyse des besoins Jérôme RALITE Dans le développement d’applications, on distingue deux types de besoins : 1. Les besoins fonctionnels 2. Les besoins non fonctionnels, c’est-à-dire tout ce qui concerne la qualité, la Õabilité, les performances, les aspects juridiques, …. Les cas d’utilisation (use case) sont une technique qui permet de définir les exigences fonctionnelles des utilisateurs. Le processus unifié (UP, cf. https://fr.wikipedia.org/wiki/Unified_process ) encourage le développement piloté par les cas d’utilisation, c’est-à-dire que les cas d’utilisation sont utilisés lors des différentes étapes du processus de développement logiciel (de l’analyse jusqu’aux tests). Les principales méthodes agiles, comme Extreme programming (XP) ou Scrum, n’utilisent pas explicitement les cas d’utilisation mais décrivent des scénarios utilisateur (User story) qui ont beaucoup de similitudes avec les cas d’utilisation. Une fois les différents scénarios recensés, ils peuvent être décrits de manière textuelle. Cependant ils peuvent également être représenté sous d’autres forme en utilisant différentes notations UML (cf. https://fr.wikipedia.org/wiki/UML_(informatique)) : 1. Diagramme de cas d’utilisation 2. Diagramme de séquences 3. … Quant aux exigences non fonctionnelles, elles peuvent être regroupées dans un document textuel que l’on appelle « Spécification supplémentaires » dans le processus unifié. 1 - Recherche des besoins fonctionnels : Les cas d’utilisation Un cas d’utilisation est une description de l’application qui privilégie le point de vue de l’utilisateur. Il décrit de façon textuelle et éventuellement graphique comment un acteur va utiliser l’application pour atteindre un objectif. L’élaboration et la description des cas d’utilisation vont permettre aux développeurs de recenser et prendre en compte les exigences de tous les utilisateurs de l’application et pas uniquement les exigences du client. Nous allons voir comment rédiger des cas d’utilisation efficaces et voir comment il est possible d’enrichir un diagramme de cas d’utilisation en y faisant figurer diverses relations (inclusion, extension et héritage). Ensuite nous verrons l’une des principales difficultés dans la modélisation des cas d’utilisation, qui est de délimiter le périmètre de l’application. En effet, l’informaticien ne doit pas négliger l’incidence que peut causer sa solution sur l’organisation du système d’information. Pour finir, nous verrons comment les cas d’utilisation peuvent être utilisés pour planifier un processus de développement itératif ou un projet plus traditionnel en cascade (cf. https://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement_(logiciel)). 1.1 - Elaboration et description des cas d’utilisation La première étape consiste à déterminer les acteurs, c’est-à-dire les différents utilisateurs de l’application. Une fois cela fait, il faut définir ce qu’ils attendent de l’application. Pour cela, il faut les interroger pour savoir comment ils souhaitent utiliser l’application. En effet, on ne demande pas aux utilisateurs de s’adapter aux fonctionnalités de l’application, mais on demande à l’application de répondre aux Accéder à Open-Campus Par Jérôme RALITE • Publié le 15/11/2017 à 19:16:15 • Noter cet article: ☆☆☆☆☆ (0 votes) Avis favorable du comité de lecture 03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 2/8 fonctions utiles du point de vue de l’acteur. On parle d’approche orientée utilisateur. De tout cela, vont découler différents scénarios que l’on va regrouper dans des cas d’utilisation. Ces cas doivent être décrirs de façon textuelle, mais ils peuvent également être décrits de façon graphique sous forme de diagramme de cas d’utilisation. Ce diagramme doit être suffisamment intuitif et accessible pour être lu par des non-informaticiens. 1.1.1 - Les acteurs Un acteur représente un rôle joué par une personne ou un autre système qui interagit directement avec l’application. Donc, un acteur peut être un utilisateur physique de l’application, mais également un responsable d’exploitation, de maintenance ou un autre système. Attention, une même personne physique peut jouer le rôle de plusieurs acteurs, et réciproquement un acteur peut concerner plusieurs personnes. En UML tout est objet, c’est-à-dire que les acteurs sont représentés par des classes auxquelles on ajoute le stéréotype « acteur ». Une deuxième notation existe, qui consiste à représenter un acteur sous la forme d’un stick man. La bonne pratique veut qu’on utilise le stick man pour représenter des acteurs humains et les classes pour représenter les autres systèmes qui interagissent avec l’application. 1.1.2 - Les cas d’utilisation Selon Jacobson (cf. https://fr.wikipedia.org/wiki/Ivar_Jacobson), un cas d’utilisation représente un ensemble de séquences d’actions qui est réalisé par le système et qui produit un résultat observable intéressant pour un acteur particulier. C’est-à-dire qu’un cas d’utilisation doit avoir une granularité moins fine que la fonctionnalité de l’application (il ne peut pas se limiter qu’a une seule action). Un cas d’utilisation ne doit pas non plus être trop vaste (il doit se dérouler d’une seule traite). Pour mieux comprendre, une autre définition selon Fowler (cf. https://fr.wikipedia.org/wiki/Martin_Fowler) : Un cas d’utilisation permet de regrouper différents scénarios qui ont un objectif utilisateur commun. Cela signifie qu’un cas d’utilisation permet aux utilisateurs de structurer leurs exigences suivant leurs objectifs en utilisant une terminologie proche du métier. Jacobson indique que pour un gros projet, il ne doit pas y avoir plus de vingt cas d’utilisation (une douzaine pour un projet de taille moyenne). S’il y en a plus, il faut se remettre en question pour savoir si l’on n’est pas en train de décrire des fonctionnalités plutôt que des cas d’utilisation. Pour réduire le nombre de cas, jacobson conseille de n’avoir qu’un seul cas d’utilisation CRUD (Create, Read, Update, Delete) par entité. Les bonnes pratiques veulent que le nom d’un cas d’utilisation commence par un verbe à l’infinitif (objectif de l’acteur) et soit suivi d’un complément. Lors de la représentation graphique, un cas d’utilisation est illustré grâce à une ellipse. Les acteurs qui sont concernés par ce cas sont reliés avec une association. Cette association peut avoir un sens de navigation ou non. Un acteur peut réaliser un ou plusieurs cas d’utilisation et inversement. Exemple: représentation d'un cas d'utilisation Attention, tous les acteurs n’utilisent pas l’application de la même façon. On appelle acteur principal celui pour qui le cas d’utilisation produit une action observable et acteur secondaire s’il est juste sollicité par le cas (ex : acteur qui consulte ou qui est juste informé par l’application). 03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 3/8 1.1.3 - Le diagramme des cas d’utilisation Le diagramme des cas d’utilisation permet de regrouper sur un même schéma plusieurs cas d’utilisation. Ce diagramme est un outil de communication entre les informations qui réalise l’application et les utilisateurs. C’est pourquoi, il doit être simple, intuitif et privilégier la lisibilité (pas plus de huit cas d’utilisation sur un diagramme). Graphiquement, dans le diagramme des cas d’utilisation, les cas sont contenus dans un rectangle qui correspond au périmètre de l’application. Les acteurs sont donc à l’extérieur du rectangle, par convention on place les acteurs principaux à droite du rectangle et les autres à gauche. Exemple: diagramme des cas d'utilisation 1.1.4 - Description d’un cas d’utilisation Le diagramme des cas d’utilisation est donc très intuitif, cependant il décrit l’application de façon trop grossière pour être exploité lors de la suite de l’analyse. Il est donc indispensable que chaque cas d’utilisation soit détaillé plus précisément textuellement, mais il est également possible d’utiliser d’autres diagrammes UML (diagramme d’activité, diagramme global d’interaction). Roques (cf. https://www.babelio.com/auteur/Pascal-Roques/28343), définit le diagramme des cas d’utilisation comme un « sommaire visuel » de la description des cas d’utilisation. Représentation textuelle La description textuelle des cas d’utilisation est très importante, parce que dans le processus unifié, ces descriptions vont être utilisées dans toutes les étapes du processus (jusqu’aux tests). Il faut donc soigner le style et l’orthographe afin que ces cas soient le plus lisible possible. Les bonnes pratiques : 1. Privilégier les phrases courtes (sujet, verbe complément) 2. Le sujet de la phrase est soit un acteur, soit le système 3. Eviter la voix passive On appelle scénario nominal, le scénario qui répond aux objectifs des acteurs par le chemin le plus direct. C’est-à-dire, le scénario qui est supposé être le plus fréquent, où aucune erreur s’est produite. Les scénarios qui aboutissent quand même à une fin normale mais par un autre chemin sont appelé les scénarios alternatifs. Les scénarios d’erreurs sont les scénarios qui n’aboutissent pas. En UML, il n’y a pas de façon standard pour rédiger un cas d’utilisation. Cependant, deux bonnes pratiques sont reconnues : 1. La description abrégée 2. La description détaillée Exemple: description abrégée Exemple: description détaillée 03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 4/8 Mais quel format utiliser en phase d’analyse ? Dans le processus en cascade où au commencement du projet il faut définir le cahier des charges, la description détaillée est privilégiée. Dans ce cas de figure il faut aussi essayer de décrire un maximum de scénarios alternatifs (il n’est pas possible de tous les décrire). Il est aussi utile d’utiliser une description uploads/Management/ 0000uml-recherche-et-analyse-des-besoins-supinfo-ecole-superieure-d-x27-informatique-pdf.pdf