2-Modélisation des besoins

Chapitre 2

Modélisation des besoins






Introduction
I. Définition et spécification des besoins
II. Identification des acteurs et des scénarios
III. Identification et représentation des cas d’utilisation
IV. Raffinement des cas d’utilisation
V. Etude de cas
Introduction
La connaissance d’un langage de modélisation comme UML et la mise en œuvre d’un processus de développement adaptatif comme UP ne disent pas ce que doit faire le système ni comment le modéliser ! Nous avons alors besoin de techniques pour le spécifier, l’analyser et le concevoir.
Tout au long des chapitres suivants de ce cours, nous essayerons de présenter ces techniques à travers les principaux artefacts de UP en suivant une démarche légère et simple puisque notre but est d’utiliser un processus de développement basé sur une modélisation objet non bureautique et de montrer à chaque étape comment les diagrammes UML permettent de décrire les divers aspects de modélisation. Rappelons que notre démarche doit être pilotée par les cas d’utilisation, centrée sur l’architecture, itérative et incrémentale.
1. Définition et spécification des besoins
1. 1 Définition
Un besoin est une caractéristique que le système doit avoir ou une contrainte qu’il doit satisfaire pour être accepté par le client ou les utilisateurs.
Dans UP, les besoins sont classés selon le modèle FURPS+ (Functionality, Usability, Performance, Reliability, Supportability) + (implémentation, interface, exploration, conditionnement, aspects juridiques). En d’autres termes, les besoins sont de types fonctionnels et non fonctionnels.
1. 2 Recueil des besoins
L’une des plus importantes « bonnes pratiques » de UP est la gestion des besoins. Dans un contexte itératif et incrémental, il ne s’agit pas comme dans les méthodes en cascades, de définir et de stabiliser les besoins une fois pour toutes dès la première phase du projet avant de commencer à développer, mais dans un contexte où les souhaits des intéressés peuvent ne pas être dès le départ explicites et donc changent inévitablement. C’est un travail systématique de recherche, de documentation, d’organisation et de suivi des besoins évolutifs du système (environ 25% des besoins changent durant le développement des projets logiciels).
Ainsi, l’analyse des besoins impose de faire face à des difficultés de recherche, de communication et de mémorisation sous une forme compréhensible par le client, les utilisateurs et l’équipe de développement. Les besoins du système sont déterminés à partir des informations recueillies durant les rencontres entre informaticiens et client/utilisateurs du futur système. Aux utilisateurs de dire ce qu’ils veulent et aux informaticiens de réaliser ce que demandent les utilisateurs. Ils doivent dons savoir se parler et surtout s’écouter.
Au début d’un projet à réaliser, l’important est de définir de quoi les utilisateurs on vraiment besoin, dans quel contexte, et ce qu’ils comptent en faire. La première opération consiste alors à se doter d’une vision générale (Quoi + Pourquoi + Combien) du produit afin de le mieux caractériser et de dégager des éléments d’appréciation. Cette vision est généralement exprimée dans un cahier des charges préliminaire.
1. 3 Représentation des besoins
Les besoins peuvent être exprimés sous la forme de cas d’utilisation dans un langage très proche des utilisateurs.
Les cas d’utilisations sont des boîtes noires qui décrivent ce que fera le système et non comment il le fera.
Pour une raison de simplification et de compréhension, l’espace des besoins est segmenté selon des points de vue de chaque catégorie d’utilisateurs (acteurs). Cela permet d’exprimer, acteur par acteur, les services ou fonctions attendus vis-à-vis du système. Cette démarche par cas d’utilisation est basée sur l’interaction (entre acteurs et système) et est très efficace.
Chaque cas d’utilisation est représenté par une classe de scénarios (instances de cas d’utilisation). Chaque scénario peut être représenté par un diagramme de séquence en termes d’évènements définissant l’interaction entre l’acteur et le système. Ce scénario nominal ne représente ni le cas d’erreur, ni les comportements marginaux (qui font l’objet de scénarios secondaires, alternatifs ou d’exception (échecs)).
L’étude des cas d’utilisation nécessite le choix de granularité des informations représentées dans les interactions. Si les variations de comportements (scénarios secondaires) autour du cas nominal sont importantes, il est plus judicieux d’opter pour une représentation plus abstraite du comportement, au moyen par exemple d’automate à états représentés en UML par des diagrammes d’états/transitions.
Comment découvrir les cas d’utilisation ?
Etape 1 : Délimiter le système. S’agit-il d’une application logicielle, de l’ensemble matériel et application, de cet ensemble plus la personne qui l’utilise ou de toute une organisation ? La frontière du système devient plus nette après la définition de ce qui lui est extérieur (i.e. les acteurs).
Etape 2 : identifier les acteurs
Etapes 3 : définir les cas d’utilisation. Si l’application est complexe, organiser les cas d’utilisation en paquetages.
2. Identification des acteurs et des scénarios
2. 1 Les acteurs
Ce sont les utilisateurs directs du système. Ils doivent avoir une bonne connaissance des fonctionnalités du système. Ce sont des entités externes au système qui interagissent ou dialoguent avec lui. Ils sont identifiés par des rôles joués par des personnes ou d’autres systèmes logiciels. On distingue :
− Des acteurs primaires (ou principaux) : utilisateurs du système pour l’accomplissement de leurs buts.
− Des acteurs secondaires : autres participants qui peuvent fournir ou recevoir de l’information, ou s’occuper de la supervision ou de l’entretien du système.
Pour trouver les acteurs d’un système, il faut identifier quels sont les différents rôles qui vont devoir jouer ses utilisateurs. Il faut vérifier que les acteurs communiquent bien directement avec le système par émission et réception de messages.
2. 2 Les scénarios
Pour chaque acteur, il faut établir ses objectifs. L’ensemble des scénarios liés à un objectif constituera un cas d’utilisation. Un scénario est une suite spécifique d’actions et d’interactions entre acteur et système.
Les scénarios sont explicités sous forme textuelle et sous forme graphique au moyen de diagrammes de séquence.
3. Identification et représentation des cas d’utilisation
Les cas d’utilisation et les scénarios expriment un point de vue fonctionnel sur le système. Ils constituent la base de la spécification initiale du système.
Chaque cas d’utilisation correspond à une fonction métier du système selon le point de vue de l’un de ses acteurs.
Un cas d’utilisation doit être défini en se situant à un bon niveau d’abstraction et en le nommant par un verbe à l’infinitif (côté acteur) suivi d’un complément (exp : pour un distributeur de billets, on définit le cas « retirer de l’argent » et non pas « distribuer de l’argent »)
Bien que nombreux diagrammes d’UML permettent de décrire un cas, il est recommandé de rédiger une description textuelle. Le plus souvent, elle comporte :









Représenter ensuite l’ensemble des cas d’utilisation et les acteurs par un diagramme de cas d’utilisation tout en s’assurant que chaque cas représente bien une fonctionnalité de haut niveau et non une opération marginale.
Établir la priorité des cas. On recommande généralement de développer d’abord les cas primaires, principalement ceux mettant en cause l’acteur principal. Les cas secondaires et les cas optionnels seront déterminés ultérieurement.
Valider avec le client. Les cas d’utilisation facilitent la compréhension des besoins et du système par toutes les parties prenantes. Comme ils sont la base des développements ultérieurs, il est important qu’ils traduisent bien les opérations voulues. De là, la nécessité de valider d’abord la pertinence des cas choisis.
Remarque Importante :
Il faut noter que les cas d’utilisation ne constituent pas une fin en soi. Leur objectif est de :
• dialoguer avec le client,
• analyser les besoins métier,
• disposer d’un support d’analyse de la valeur,
• aider à démarrer l’analyse orientée objet en identifiant les classes candidates (Voir chapitre suivant).

4. Raffinement des cas d’utilisation
Une fois cette première itération complétée, d’autres itérations peuvent être indispensables pour un éventuel raffinement des cas d’utilisation. En effet, il faut noter que nombreux cas sont réécrits plusieurs fois, d’autres raffinés et d’autres encore complètement supprimés.
Le raffinement des cas d’utilisation produit plus de détails sur les caractéristiques fournies par le système et les contraintes qui leurs sont associées.
Quelques aspects des cas d’utilisation, ignorés initialement et détaillés pendant le raffinement :
− Des éléments manipulés par le système,
− Les interactions de bas niveau,
− Des exceptions oubliées et
− Des fonctionnalités communes entre cas d’utilisation.
L’identification des exceptions concerne les conditions de succès et d’échec.
L’ajout de relations d’extension ou d’inclusion permet de réduire ou de supprimer des redondances du modèle des cas d’utilisation et donc, d’éliminer des inconsistances potentielles.
Dans une relation d’extension entre cas d’utilisations, le cas étendu doit avoir besoin du cas extension sous certaines conditions.
Une relation d’inclusion entre cas d’utilisation et définie suite à la détermination de redondances (éléments communs à plusieurs cas).
Une nouvelle validation des cas est alors nécessaire.
Remarque importante : Il ne faut détailler et compléter qu’au besoin pour que les cas ne deviennent pas démesurablement complexes.
5. Etude de cas