Modélisation, Expression de Besoins avec UML

Modélisation, Expression de Besoins avec UML Thierry Cros http://etreagile.thierrycros.net Copyright Ce document est sous licence Creative Commons selon ces termes : vous pouvez reproduire, distribuer, communiquer et modifier ce document dans les conditions suivantes : citer l'origine de cet article en incluant l'information suivante : Auteur Thierry Cros, http://etreagile.thierrycros.net pas d'utilisation commerciale de ce document Distribuer, communiquer, adapter ce document en citant explicitement ce contrat initial CC/BY-NC-SA. Support UML v2 1/21

Illustrations Illustration 1: Modéliser pour mieux comprendre...3 Illustration 2: éléments, formalismes, diagrammes...4 Illustration 3: Acteurs et cas d'utilisation...5 Illustration 4: Navigateur : modèle, paquetages, éléments de modélisation et diagrammes...6 Illustration 5: Contexte Système...7 Illustration 6: Nouveau contexte...11 Illustration 7: Relation <<include>>...12 Illustration 8: Contenu du Navigateur avec relation include...13 Illustration 9: Héritage entre acteurs...16 Illustration 10: Navigateur contenant un héritage d'acteurs...16 Illustration 11: Relation <<extend>> entre cas...17 Illustration 12: Point d'extension...18 Illustration 13: Navigateur : extend...18 Illustration 14: Diagramme d'activité associé à un cas d'utilisation...19 Illustration 15: Classes du domaine...20 Illustration 16: Compte à Vue...20 Illustration 17: Etats Transitions d'un Compte à Vue...21 Illustration 18: Navigateur...21 Index des tables Tableau 1: Description d'un cas d'utilisation...8 Tableau 2: Description textuelle de "DialogueBanque"...10 Tableau 3: Gestion des cas d'utilisation...12 Tableau 4: Description de DialogueBanque avec <<include>>...13 Tableau 5: Tableau de bord des cas, y compris niveaux...14 Support UML v2 2/21

1. Introduction Ce support traite de l'expression de besoins avec UML, autrement dit avec les cas d'utilisation pour l'essentiel. Mais dans un premier temps, voyons ce qu'est un modèle UML. 2. Modéliser Illustration 1: Modéliser pour mieux comprendre Le système dont nous nous occupons ici est un logiciel ou, pour reprendre une expression issue du processus unifié : un système à forte composante logicielle, ce qui est plus précis, au vu de l'importance que prennent les matériels dans la solution complète. Un modèle, dans UML, représente le système selon un certain point de vue et est constitué : d'un paquetage principal qui représente le système lui-même selon le point de vue du modèle et donc contient tout le reste soit : des éléments de modélisation (les objets, les classes, les états...) des diagrammes qui représentent ces éléments (voir à ce sujet l'article Diagrammez correctement vos modèles!) des paquetages (qui sont donc des sous-paquetages). Un paquetage est l'élément d'organisation du modèle, tout comme un répertoire organise des fichiers dans un ordinateur. Un paquetage offre aussi Support UML v2 3/21

un espace de noms, un élément pouvant alors être public ou privé. Autre point important : un modèle repose sur deux visions complémentaires : aspect dynamique (communication, séquence...) structurel (classes, paquetages). C'est l'équilibre entre ces deux piliers qui forme un modèle pertinent. Les modeleurs n'implémentent que rarement la notion de modèle. Or, c'est pourtant l'unité du langage UML! Une solution est d'utiliser la notion de paquetage pour «simuler» le modèle, toujours présente. Illustration 2: éléments, formalismes, diagrammes... 3. Acteurs et cas d'utilisation Acteurs et cas d'utilisation sont les vedettes de l'expression de besoins avec UML. Or, la vérité est (juste un peu...) différente. La véritable star de l'expression de besoins est... l'interaction acteur / système dans une situation d'utilisation appelée «cas». Retenez bien ceci car c'est la clé non seulement de l'expression de besoins mais aussi du pilotage du projet (par les cas d'utilisation bien entendu). Cela ne vous rappelle rien? Bien sûr : l'interaction ou la communication, la collaboration... ce sont des concepts objet! Donc, considérez un acteur comme un objet, le système comme un autre objet, une boite noire actuellement. Cet objet assume des responsabilités qui se retrouvent dans les situations de son utilisation par l'acteur. Cela compris, vous avez acquis les ¾ de la compréhension de ces concepts. Support UML v2 4/21

Alors... acteurs, cas... voyons tout cela de plus près. Illustration 3: Acteurs et cas d'utilisation Rappel de la clé : Un cas d'utilisation est un ensemble d'interactions Si vous oubliez cela, vous obtiendrez quelque chose... et ce quelque chose ne sera certainement pas un modèle «cas d'utilisation» juste. Obtenir les acteurs et les cas Les acteurs sont externes au système (ce qui pose la question des frontières de ce système d'ailleurs). Un acteur peut être humain : acteur principal, bénéficiaire du système ou bien acteur secondaire tel que exploitant... autre système : une application ou un système avec lequel notre système dialogue est un acteur. La toute première question (mais le processus est itératif : nous obtenons une première réponse, plus tard nous reposerons la question) est donc : quels sont les acteurs de ce système? La réponse précise les frontières du système, qui peuvent être l'enjeu principal de la modélisation. La deuxième question est alors : quelles sont les situations dans lesquelles ces acteurs vont utiliser le système? Ces premières listes établies (qui n'est finalement à ce stade qu'une liste d'acteurs et situations candidates), nous pouvons les représenter dans une toute première version du modèle d'expression de besoins. Support UML v2 5/21

Etude de cas Cette étude porte sur l'information d'une agence bancaire. L'objectif est de proposer aux clients un logiciel de gestion de leur compte. La particularité (la nouveauté) de ce logiciel est qu'il offre, en plus des fonctionnalités habituelles de gestion de compte via internet ou minitel, une capacité à dialoguer avec la banque, via un système type dialogue simultané, couplé aux comptes du Client. Un Client possède nécessairement un «Compte à vue», éventuellement un livret et un «Plan Epargne Logement». Le logiciel modeleur possède plusieurs zones : menu, etc navigateur ou browser zone d'édition des diagrammes. Notez que le navigateur est un élément important de votre modeleur : c'est lui qui permet de naviguer facilement (ou non...) dans vos modèles. 4. Créer le modèle d'expression de besoins La saisie des éléments de modélisation obtenus dans une première recherche nous permet d'obtenir le contenu de navigation suivant. Illustration 4: Navigateur : modèle, paquetages, éléments de modélisation et diagrammes Ce navigateur présente le contenu : Système (souvent appelé projet dans le modeleur), ici GestionBancaire Le modèle d'expression de besoins (ici un paquetage) Support UML v2 6/21

Le système dans ce modèle (ici une «vue» dans le modeleur, appelée Gestion Bancaire en cas d'utilisation) un diagramme de contexte (voir ci-dessous) qui représente les cas d'utilisation ainsi que les acteurs, les éléments de modélisation : acteurs et cas d'utilisation. Plus tard, lorsque nous ajouterons des modèles, nous pourrons ainsi jouer sur le navigateur et ouvrir ou fermer les modèles, les paquetages, etc. Pour l'instant, voici le diagramme de contexte, à ce point de l'étude. Illustration 5: Contexte Système Ce diagramme indique les situations d'utilisation du système par deux acteurs : Banquier et Client. Ce sont des rôles joués par des personnes. Un cas d'utilisation est un ensemble d'interactions. Si ces interactions peuvent se modéliser par un diagramme de séquence, la quantité et la complexité des choix possibles rend cette solution insensée, sauf peut-être pour quelques cas particuliers de scénarios typiques. Un scénario est une lecture particulière, spécifique des interactions. La solution est le plus souvent une description textuelle. Cela n'empêche pas l'apport de concepts et formalismes UML pour consolider le modèle d'expression de besoins. Comme pour tout modèle, tout concept (à de rares exceptions près) et donc tout formalisme peut être utilisé. Cela tient au fait que les concepts de base (objet message) sont réellement universels. Voici donc un exemple de description textuelle simple. Notez que la longueur de cette description est un aspect important : au plus elle sera longue, au plus elle sera difficile à apprécier, voire à lire tout simplement. Quelques pages (2 ou 3) semblent donc être une bonne mesure. Bien entendu, cela dépend de la Support UML v2 7/21

nature du cas d'utilisation. Nous verrons un peu plus tard des possibilités les relations entre cas qui permettent de limiter cette question pragmatique. Une description textuelle est basée sur une expression en français des interactions, ce qui peut paraître verbeux dans un premier temps. Nom du cas d'utilisation Déclenchement/Résumé Acteurs Interactions normales Interactions alternatives Etat du système en fin de cas Commentaires sur la description Voir tout simplement le modèle Quelques infos concernant le contexte de déclenchement de cas : quand cette situation d'utilisation se produit-elle? Quel état du système? Voir aussi le modèle : quels sont les acteurs qui participent à ces interactions? L'ensemble des interactions quand tout se passe normalement Les cas «particuliers» dans les interactions Dans quel état se trouve le système? Que doit-il mémoriser par exemple? Tableau 1: Description d'un cas d'utilisation Prenons le cas de la situation DialogueBanque. Notez au passage qu'un cas d'utilisation est une situation, un nominatif si vous préférez. C'est pour cela qu'il me semble plus judicieux de nommer les cas par des noms plutôt que des verbes. L'obtention des interactions s'obtient en dialoguant avec un Utilisateur expert. Comment? Il s'agit de poser des questions qui lui permettent de voir le système comme une boite noire et donc d'imaginer les interactions. Notez que la description se concentre sur le contenu, la signification, des interactions et pas sur leur forme. En effet, une maquette de type IHM ou plus généralement des échanges entre système et acteurs peut être réalisée en parallèle afin de traiter de cet aspect de l'expression de besoins. On parle alors de cas d'utilisation essentiel, car il décrit l'essence des interactions. Quelques questions à poser à l'utilisateur expert (ou au collège d'utilisateurs qui participent à l'expression de besoins). Dans quels cas allez-vous utiliser GestionBancaire? Support UML v2 8/21

Quels cas souhaitez-vous décrire en priorité? (ici, le Commanditaire du logiciel peut faire des choix qui ne seraient pas nécessairement celui du Développeur) Quand ce cas est-il déclenché? Pourquoi? Quel est le processus métier dans lequel ce cas s'inscrit? Que souhaitez-vous que GestionBancaire vous présente comme information, comme choix...? Voici donc un exemple de description textuelle. DialogueBanque / version 1 Déclenché par le Client lorsqu'il souhaite dialoguer avec son banquier, en s'appuyant sur les infos de son compte (déclenchement aléatoire pendant les heures d'ouverture de la banque). Acteurs : Client et banquier pour dialoguer 1 1. Le Client se connecte (interactions à définir affichées en fond jaune) et déclenche ce cas en choisissant DialogueBanque ; 2. GestionBancaire envoie alors un message au Banquier atitré du Client ; 3. Le Banquier accepte la connexion [cas alternatif : le Banquier refuse] ; 4. GestionBancaire avertit alors le Client que le dialogue est établi avec le Banquier, pour cela une boite de dialogue est créée sur les deux écrans ; 5. GestionBancaire affiche le numéro et le solde de tous les comptes du Client (affiche pour le Client et pour le Banquier) 6. Le Client choisit, éventuellement plusieurs fois de suite, l'un des comptes sur lequel il veut dialoguer 7. GestionBancaire affiche les 10 dernières opérations de ce compte (client et banquier) ainsi que son solde ; 8. Eventuellement plusieurs fois de suite : 9. Le client envoie son message au banquier ; 10. GestionBancaire transcrit ce message au banquier ; 11. le Banquier répond au message; 12. le Client indique qu'il souhaite terminer le dialogue 13. GestionBancaire envoie un message de fin au Client et au Banquier. Le Banquier refuse le dialogue GestionBancaire envoie un message au Client lui indiquant que le dialogue est impossible (pas que le banquier refuse) / fin. En fin de dialogue, celui-ci est mémorisé par GestionBancaire. Les interactions de connexion ne sont pas encore définies, c'est un pb car c'est un aspect crucial du système (sécurité). Tableau 2: Description textuelle de "DialogueBanque" 1 Cela provoque alors une évolution du modèle : ajout d'une association de communication entre Banquier et DialogueBanque. Support UML v2 9/21

Illustration 6: Nouveau contexte Prévoyez dès le départ un tableau de gestion des situations d'utilisation. Ce tableau de bord permet de faire le point régulièrement sur les cas d'utilisation : Les cas en cours de rédaction, ou bien validés, ou encore plus tard en cours de développement... Et encore plus tard les cas en exploitation! Ce tableau est un embryon de «gestion de configuration» des cas d'utilisation. En effet, comme pour tout élément produit par le cycle de vie du projet, ces cas peuvent évoluer : une gestion de changement, même minimaliste au début, s'impose donc. Enfin, prévoyez une zone «Commentaires» qui permet de stocker toute info qui peut être utile. Ce tableau est important dans le cas d'un pilotage par les cas d'utilisation. Nous verrons un peu plus tard qu'il est plus judicieux de parler de Pilotage par les scénarios de cas d'utilisation. Si le besoin apparaît il sera alors possible d'équiper ce tableau de scénarios, afin de correspondre à la réalité du projet. Un peu d'excellerie (ou de tableur OpenOffice gratuit) est largement suffisante pour implémenter ce tableau. Souvenez-vous que ce tableau est un outil de gestion de projet : sa finalité est donc d'être lu et utilisé pour piloter le projet. Il pourra être présenté en Comité de Pilotage Projet, modifié en réunion d'avancement, etc. Support UML v2 10/21

Situation (cas) Etat Version Priorité V.A. Commentaires CreationCompte identifié - ++ Voir le processus métier 'création nouveau client' OpérationsCAV identifié - ++ Traiter en particulier le virement de compte à compte du client DialogueBanque En rédaction 1 +++ Le «plus» que l'on offre à nos clients OpérationsLivret identifié - + Vérifier le nombre de clients concernés OpérationsPEL - + idem Suppression - + On a toujours l'ancien système pour supprimer les comptes Tableau 3: Gestion des cas d'utilisation Avancons un peu. Quid des interactions de connexion au système? Si nous observons les différents cas d'utilisation, nous constatons que ces interactions sont obligatoires dans tous les cas. Nous pouvons attendre de les rédiger deux fois, dans deux descriptions textuelles ce qui serait le plus sûr pour justifier ce qui va suivre! Nous pouvons aussi décider de créer un cas d'utilisation un peu particulier, qui est simplement un ensemble d'interactions. Cela pose deux questions : 1. Comment représenter, modéliser, la relation entre tous ces cas? 2. Comment gérer cela, car nous pressentons que nous avons affaire à des cas d'utilisation de «niveau» différent? 5. Relations entre cas d'utilisation et niveaux des cas Relation include La relation d'inclusion d'interactions est parfaitement adaptée à la modélisation que nous sommes en train de réaliser. Illustration 7: Relation <<include>> Support UML v2 11/21

Cette relation qui prend un caractère obligatoire indique que les interactions de Connexion sont incluses à un point d'inclusion donné dans les interactions de DialogueBanque. Si vous connaissez le C++, c'est le même mécanisme d'inclusion qui s'applique avec la directive #include "fichier.h". Il reste simplement à préciser cette inclusion dans la description textuelle. DialogueBanque / version 1.1 Déclenché par le Client lorsqu'il souhaite dialoguer avec son banquier, en s'appuyant sur les infos de son compte (déclenchement aléatoire pendant les heures d'ouverture de la banque). Acteurs : Client et banquier pour dialoguer (include Connexion) GestionBancaire envoie un message au Banquier atitré...... Tableau 4: Description de DialogueBanque avec <<include>> La syntaxe de l'inclusion est une décision de modélisation ou description textuelle qui est à établir. Elle s'utilise à l'endroit où il faudrait normalement rédiger les interactions qui sont incluses. Le surlignage de couleur n'a rien d'obligatoire! Faisons un petit tour dans le navigateur de notre modeleur. Nous voyons que ce modèle possède maintenant deux diagrammes de cas. Le premier est celui de Contexte Système, le deuxième est celui créé particulièrement pour représenter les relations du cas DialogueBanque. Les niveaux des cas d'utilisation Illustration 8: Contenu du Navigateur avec relation include Cela pose la question des niveaux de cas d'utilisation tels que définis et Support UML v2 12/21

manipulés jusqu'à présent. Nous pouvons dire que le cas d'utilisation DialogueBanque est bien un cas système, autrement dit une situation d'utilisation volontaire du système alors que le cas Connexion a un côté souscas. Alistair Cockburn propose une représentation sympathique des niveaux que je reprends ici en adaptant la terminologie. 1. Niveau «métier» ou Mouette : ce sont des descriptions qui sont en fait des descriptions de processus métier ; il est normal que ces descriptions apparaissent car l'utilisateur expert invente (et donc exprime) actuellement un produit qui a des répercussions sur ces processus, ces protocoles ou procédures métier; parfois simplement sur les notes de services. 2. Niveau «système» ou Mer : se sont les cas tels que ceux inventés au départ, ils offrent une véritable valeur ajoutée en terme de métier. 3. Niveau «paquet d'interaction» ou sous-cas ou Crabe : ce sont les cas tels que Connexion qu'il faut bien gérer mais qui n'offrent pas toute la couverture d'un cas système. Ajoutons alors une colonne à notre tableau de bord. Situation (cas) Niveau Etat Version Priorité V.A. Commentaires CreationCompte Mer identifié - ++ Voir le processus métier 'création nouveau client' OpérationsCAV Mer identifié - ++ Traiter en particulier le virement de compte à compte du client DialogueBanque Mer En rédaction 1 +++ Le «plus» que l'on offre à nos clients Connexion Crabe identifié - +++ Justification : sécurité. Prévoir les interactions de modification de mot de passe OpérationsLivret Mer identifié - + Vérifier le nombre de clients concernés OpérationsPEL Mer identifié - + idem Suppression Mer identifié - + On a toujours l'ancien système pour supprimer les comptes Tableau 5: Tableau de bord des cas, y compris niveaux Rédigeons alors les interactions du cas Connexion. Notez qu'il apparaît un Utilisateur, qui recouvre aussi bien Client que Banquier. Le modèle sera alors à mettre à jour. Support UML v2 13/21

Connexion Déclenché par inclusion de DialogueBanque (à modifier) donc par le Client. 1. Pendant trois fois maximum [cas alternatif : trois erreurs] : 2. GestionBancaire demande le code utilisateur du système et le mot de passe numérique 3. L'utilisateur saisit ces informations 4. Si elles sont erronées, GestionBancaire envoie un message d'erreur Trois erreurs GestionBancaire envoie un message indiquant que la connexion est désormais impossible ; l'utilisateur est bloqué En fin de cas, l'utilisateur est connecté à GestionBancaire Il faudrait aussi prévoir une procédure pour imposer le changement régulier de mots de passe. Une question se pose à ce niveau : quid de la connexion du Banquier dans le cas DialogueBanque? Une modification dans le tableau 2 (description textuelle du cas DialogueBanque) : le pas numéro 4 des interactions mériterait alors un pas complémentaire : 4.1 include (Connexion) pour le Banquier ; Le modèle évolue pour tenir compte de ce pseudo acteur : Utilisateur. En fait, nous pourrions dire qu'il s'agit d'un acteur abstrait, au sens classe abstraite, donc non instanciable. Son nom apparaît alors en italiques. Illustration 9: Héritage entre acteurs Cela indique qu'il n'existe pas d'utilisateur du système en tant qu'utilisateur concret et heureusement : Utilisateur est certainement un nom d'acteur bien médiocre! Support UML v2 14/21

Notre modèle s'enrichit peu à peu. Nous constatons ici un phénomène tout à fait normal : nous travaillons sur plusieurs artefacts (ou «docs»). Ainsi, les uns consolident les autres. C'est ce que nous retrouvons aussi au niveau d'un modèle : l'aspect structurel permanent consolide l'aspect dynamique et inversément. De même, un modèle en consolide un autre : typiquement le modèle d'analyse consolide l'expression de besoins. Illustration 10: Navigateur contenant un héritage d'acteurs Etude de cas, suite Le commanditaire indique, à l'étude de la description textuelle du cas DialogueBanque, qu'il serait judicieux de présenter de nouveaux produits bancaires au Client, à l'occasion de cette situation du système. Ces informations Marketing sont optionnelles et sont à discrétion du banquier. Cette configuration d'interactions optionnelles est caractéristique de la relation <<extend>> entre cas d'utilisation. Support UML v2 15/21

Les conditions d'extension peuvent être précisées : Point d'extension : l'endroit dans la description du cas étendu où les interactions qui étendent peuvent prendre place (ce peut être une plage d'interactions dans le cas étendu) Condition d'extension : ce qui fait que ces interactions se déroulent. Le diagramme devient alors : Illustration 11: Relation <<extend>> entre cas Illustration 12: Point d'extension C'est en fin de dialogue que le Banquier peut décider ou non du déroulement des interactions du cas «crabe» InfosMarketing. Support UML v2 16/21

Le navigateur est alors le suivant : Illustration 13: Navigateur : extend... 6. Consolider le modèle d'expression de besoins Nous venons de voir les éléments de modélisation directement liés à l'expression de besoins par les cas d'utilisation. Or, il est bien souvent utile d'ajouter des artefacts qui viennent améliorer la compréhension du modèle. Un modèle «métier» est une ressource parfois utilisée (voir le document consacré à ce modèle), nous y reviendrons dans un instant. Un diagramme d'activité ou état-transition est un bon moyen de préciser le déroulement d'un cas d'utilisation, les activités sont celles du système et éventuellement celles des acteurs pendant la situation d'utilisation. Prenons un cas simple pour exhiber un premier diagramme d'activité dans ce support. Le commanditaire du projet explique que chaque compte à vue se voit attribuer une facilité de caisse, soit un seuil de solde négatif à ne pas dépasser. Si le solde résultant du débit est inférieur à ce seuil, le débit est impossible. Si le compte est en «facilité de caisse» pendant plus de 30 jours il est bloqué. Le débit est un ensemble de scénarios possibles du Cas d'utilisation OperationsCAV. Support UML v2 17/21

Ce déroulement d'interactions est modélisé par un diagramme d'activités. Un diagramme Etat-Transition pourrait aussi être associé à un cas d'utilisation, pour indiquer les états et leurs changements dans le déroulement des interactions du cas. Illustration 14: Diagramme d'activité associé à un cas d'utilisation Ci diagramme présente les formalismes suivants : pseudo état initial de démarrage de l'activité activités : calcul nouveausolde, etc une décision (ce losange est aussi une fusion de transitions) qui se traduit par deux transitions qui visualisent l'algorithme du débit. Note : la pertinence et la valeur ajoutée de ce type de diagramme reste à valider : parfois un texte vaut mieux que 1000 dessins! Revenons au modèle métier. Si un modèle métier complet n'est pas toujours nécessaire, il peut être toutefois utile de préciser, dans le modèle d'expression de besoins, quelques objets du domaine, voire quelques processus métier, en termes de consolidation de l'expression de besoins. Support UML v2 18/21

Illustration 15: Classes du domaine Finalement, un diagramme Etat/Transition peut être associé à une classe afin de préciser la nature des objets de cette classe. Illustration 16: Compte à Vue Support UML v2 19/21

Illustration 17: Etats Transitions d'un Compte à Vue Le modèle d'expression s'enrichit donc rapidement. Illustration 18: Navigateur Le modèle ici est constitué de deux paquetages (illustration 18), ce qui est formellement un déviance par rapport à UML. Nous touchons ici du doigt la différence entre le langage UML «normé» d'une part et le langage UML pratiqué d'autre part. Cette différence est due en particulier aux interprétations que font les concepteurs de modeleurs en fonction de leur compréhension de l'uml... et aussi en fonction des impératifs marketing de leur société 2! 2 Pour être honnête, j'interprète moi aussi UML finalement! Pour une vision de l'uml véritablement standard consultez le site OMG : Introduction to the OMG's UML Support UML v2 20/21

Dans cet exemple, nous n'avons pas traité la question de la réorganisation du modèle. Nous en reparlerons à propos du modèle de conception zéro (ou analyse). Les copies-écran du navigateur au fur et à mesure de l'avancement du modèle ont pour but de montrer l'importance stratégique (en terme de modélisation) de cet aspect du modeleur. Je vous invite donc à bien étudier cette progression dans la navigation et à prendre le temps de bien maîtriser l'organisation de la navigation de vos modèles. Support UML v2 21/21