S'il y a bien un dessin qui parle à tout le monde, c'est le dessin représentant une personne.
Découvrez l'UML
Pour nous, cette icône représente un utilisateur, un acteur d'un programme. Comme je vous l'avais dit dans la première partie, un modèle de domaine peut prendre plusieurs formes. Nous verrons ensemble plusieurs approches possibles, mais plus particulièrement les diagrammes de cas d'utilisation (ou use case en anglais). Cette approche fait partie du standard UML.
Et c'est quoi, l'UML ?
UML signifie Unified Modeling Language (langage unifié de modélisation). C'est un standard de notation que vous pouvez utiliser pour modéliser ou représenter de manière visuelle une application informatique.
Au début, il existait de nombreuses manières de représenter un programme. Chacun avait sa façon de procéder. Certains utilisaient des cercles, d'autres des rectangles, ou des nuages en pointillés... Aucune cohérence. 🙄 Finalement, un consensus a été trouvé sur les images qui devraient être utilisées pour modéliser telle ou telle idée (comme le personnage en bâtons pour un acteur). Vous comprenez donc maintenant d'où vient le terme "unifié" dans l'appellation langage unifié de modélisation.
Avec les informations que vous avez recueillies jusqu'ici, vous êtes en mesure de construire un type de diagramme UML : le diagramme de cas d'utilisation. C'est un moyen de capturer, en image, ce que votre programme peut faire pour plusieurs utilisateurs. Il permet de représenter les informations que vous avez récoltées jusqu'à maintenant sur les utilisateurs de l'application, et ce qu'ils veulent qu'elle exécute pour eux.
Ce diagramme doit être créé assez tôt dans le projet et doit ensuite être tenu à jour à mesure que vous en apprenez davantage sur ce que l'utilisateur veut accomplir.
Concevez un diagramme de cas d'utilisation
J'imagine que vous avez hâte de créer votre premier diagramme de cas d'utilisation. Alors au travail ! Pour ce faire, nous allons suivre les étapes suivantes :
Identifier les acteurs.
Définir les cas d'utilisation (use cases).
Ajouter les relations.
C'est aussi facile que de compter jusqu'à trois !
Étape 1 : identifiez les acteurs
De quoi vous ai-je parlé en premier dans ce chapitre ? Des acteurs !
Un acteur est représenté dans un diagramme sous la forme d'un personnage en bâtons, accompagné d'une description rapide du type d'utilisateur (son rôle).
Revenons à notre exemple de l'application pour la bibliothèque.
Pour créer le diagramme correspondant, il faut ajouter les acteurs identifiés qui vont utiliser la solution.
OK, parfait ! Maintenant, passons à l'étape suivante : définir les objectifs des acteurs, en passant par les cas d'utilisation.
Étape 2 : identifiez les cas d'utilisation
Ici, nous voulons identifier ce que les utilisateurs veulent faire : les cas d'utilisation (ou use cases). Pour les obtenir, il suffit d'analyser les conversations que vous avez eues avec les bibliothécaires et les usagers.
Représentez un cas d'utilisation sous la forme d'un ovale, en notant l'objectif de l'utilisateur à l'intérieur. Attention à ne pas tourner les objectifs du point de vue du programme.
Par exemple, vous écrirez « récupérer un livre » (c'est ce que la bibliothécaire veut faire) au lieu de « mettre à jour le statut du livre dans l'enregistrement de base de données » ou « enregistrement du livre mis à jour dans la base de données ». (Ça, c'est ce que l'application fera.) Pour le moment, la seule chose qui vous intéresse ce n'est pas de savoir comment cela sera fait, mais seulement que l'utilisateur souhaite que cela soit fait.
Vous pouvez voir sur l'image ci-dessus que les cas d’utilisation des bibliothécaires sont à gauche et ceux des usagers, à droite. Voilà, vous avez vos cas d’utilisation, mais comment allez-vous les relier à vos acteurs ?
Vous auriez pu aller chercher la solution juste en-dessous, mais je vous le dis tout de suite pour casser le suspense : avec des relations ! 🤓
Étape 3 : reliez le tout avec les relations
L'objectif ici est de montrer quels acteurs sont intéressés par quel(s) objectif(s). Pour cela, nous allons utiliser un trait pour les lier, appelé relation.
C'est aussi simple que cela. Ajoutez des personnages en bâtons à votre diagramme au fur et à mesure que vous identifiez de nouveaux types d'utilisateur. Ajoutez des ovales et des relations au fur et à mesure que vous identifiez de nouvelles fonctionnalités souhaitées par les utilisateurs. Il y a deux utilisateurs dans le diagramme ci-dessus, chacun avec des objectifs distincts. Cela vous donne un indice plus général sur votre application : son modèle sera probablement composé de deux domaines ou au moins de deux sous-domaines.
Parfois, vous pouvez remarquer que certaines étapes se répètent dans plusieurs cas. Par exemple, plusieurs cas d'utilisation peuvent indiquer « envoyer ensuite un e-mail à quelqu'un ». Il peut être utile de distinguer cette activité partagée de manière visuelle : il s'agit de dépendances et elles sont indiquées avec des flèches.
Dans notre exemple, « Infliger des amendes pour retard » dépend de « Envoyer un e-mail » pour l'exécution de la tâche. Et d'autres flèches en pointillés partant d'autres use cases pointeraient également vers « Envoyer un e-mail ».
La flèche sur le diagramme indique une dépendance. Comme c'est une flèche, il est facile de la confondre avec un flux de données ou d'exécution. Mais souvenez-vous : ce n'est pas la même chose. Cela signifie simplement que « Infliger des amendes pour retard » dépend de « Envoyer un e-mail » pour l'exécution de la tâche.
Même s'il est tout à fait possible (et même probable) que des données soient échangées, ce n'est pas le but de les représenter ici dans ce diagramme. En revanche, le langage unifié de modélisation propose d'autres types de diagrammes pour représenter les échanges de données.
Dans notre exemple, nous avons pu faire apparaître deux sous-domaines (bibliothécaire et usager), mais cela ne signifie pas qu'ils n'interagissent pas. En jetant un coup d’œil au diagramme, on voit bien qu'il existe une connexion entre « Payer l'amende pour un retard » et « Acheter un livre de remplacement ». Il est encore trop tôt pour déterminer précisément comment ces deux cas d’utilisation seront amenés à interagir l'un avec l'autre, mais vous pouvez indiquer dès maintenant qu'une interaction est anticipée.
Mission accomplie : vous avez maintenant un diagramme qui représente les acteurs, les cas d’utilisation et les relations entre eux. Beau travail ! 🦸♀️
En résumé
Les diagrammes de cas d’utilisation permettent de représenter visuellement les objectifs des utilisateurs. Ils montrent les relations entre les acteurs et les cas d’utilisation, entre acteurs et acteurs, et enfin entre différents cas d’utilisation.
Les diagrammes de cas d'utilisation sont souvent dessinés en utilisant le langage unifié de modélisation.
Les acteurs sont représentés par des personnages en bâtons.
Les cas d'utilisation sont représentés par un ovale dans lequel est écrit un objectif.
Les dépendances sont représentées par une flèche en pointillés.
J'ai mon diagramme. C'est bien beau. Et maintenant ?
Vous vous en doutez sûrement : il reste encore du travail.
Dans le prochain chapitre, nous verrons comment préciser davantage les objectifs des utilisateurs. Pour cela, nous allons détailler sous forme de texte comment réagit notre programme aux actions de l'utilisateur. Vous pourrez ensuite analyser ces textes descriptifs pour déterminer les classes et les objets qui doivent exister.
