Dans le chapitre précédent, nous avons imaginé quelques user stories à implémenter. Nous allons maintenant nous intéresser aux classes que nous devons modifier ou créer pour supporter les nouvelles fonctionnalités. Pour ce faire, nous allons traduire les user stories en descriptions de cas d’usage.
Très bien, voyons un peu où nous en sommes :
Nous avons un nouvel ensemble de fonctionnalités à intégrer (grâce à nos user stories).
Nous avons une application existante dans laquelle intégrer les nouvelles fonctionnalités.
Nous avons besoin d’une approche ou d’une méthodologie raisonnée.
Et maintenant ? Un excellent point de départ sera de trouver les entités, ou les composants architecturaux principaux de l’application. Autrement dit, déterminons quels éléments feront le gros du travail.
Comment allons-nous procéder ?
Nous allons suivre plusieurs étapes :
Nous allons décrire des cas d’usage pour déterminer nos entités.
Cela nous permettra de savoir quelles entités sont nouvelles et quelles entités existantes ont besoin d’être modifiées.
Générez des descriptions de cas d’usage pour définir vos entités
Regardons de plus près un cas d’usage et amusons-nous à définir les entités :
« En tant que pilote, je veux saisir tout problème de maintenance mineur dès l’atterrissage, pour qu’il puisse être réparé rapidement ».
Le pilote se connecte au système.
Le système valide le login.
Le pilote sélectionne nouveau problème de maintenance.
Le système présente l’écran de sélection de la maintenance.
Le pilote sélectionne le problème de maintenance mineur.
Le système présente l’écran de saisie de la maintenance.
Le pilote sélectionne l’avion qui a le problème.
Le pilote sélectionne le sous-système concerné.
Le pilote saisit les détails concernant le sous-système qui ne fonctionne pas correctement.
Le système enregistre le problème de maintenance mineur associé à l’avion.
Vous remarquerez que j’ai écrit tous les noms en majuscules. Ces noms vont potentiellement devenir des entités métiers.
Déterminez quelles entités sont nouvelles ou ont besoin d’être modifiées
Très bien, nous allons maintenant regarder le système actuel pour voir quelles entités métiers existent déjà.
Maintenant, regardons le cas d’usage de plus près. Il fait référence à des problèmes de maintenance mineurs. Le terme “mineur” suppose qu’il existe également un niveau de problème “majeur”... et peut-être un niveau “modéré”. Nous devons donc prendre en compte ces autres niveaux.
De plus, notre cas d’usage nous montre que les avions possèdent des sous-systèmes qui ont besoin de maintenance. Nous devrons également ajouter cette idée. On voit aussi que les archives de maintenance sont associées à des avions précis. Ceci constitue une idée nouvelle qui doit être reflétée dans notre diagramme :
Si nous poursuivons l’architecture actuelle, nous devons lier ces nouvelles entités à Java Swing et SQLite également. Voici à quoi ressemble un diagramme mis à jour.
Oulala, ça se complique ! 😱
C’est pourquoi nous allons le nettoyer dans les chapitres suivants.
À vous de jouer : définissez et analysez des entités
Allez, essayez par vous-même !
Tout d’abord, nous allons nous intéresser à notre autre nouvelle user story. « En tant que mécanicien en charge de la maintenance de l'avion, je veux mettre à jour tout problème dès qu’il a été traité, pour que l’avion puisse être considéré comme apte à voler. » Lisez le cas d’usage ci-dessous. Repérez tout nouveau nom qui doit être ajouté à notre système, puis voyez si vous pouvez l’ajouter à notre diagramme existant.
Le mécanicien de l'avion se connecte au système.
Le système valide le login.
Le mécanicien sélectionne “voir tous les problèmes de maintenance avion”.
Le système présente l’écran des problèmes de maintenance en cours.
Le mécanicien sélectionne un problème de maintenance en cours.
Le système présente l’écran de saisie de mise à jour de maintenance.
Le mécanicien coche l’indicateur de réparation, et confirme la date des mises à jour.
Le système met à jour le problème de maintenance.
Réponse
Voici les noms que vous devriez avoir repérés : mécanicien de l'avion, login, problèmes de maintenance, réparation, date de mise à jour.
Avant de consulter ma version, voyez si vous pouvez cartographier les nouvelles entités. Voici de nouveaux éléments ajoutés au diagramme de classe :
Et maintenant, regardez le cas d’usage par lequel tout a commencé : « En tant qu’opérateur d’agence de voyage, je veux réserver un vol pouvant transporter jusqu’à 12 personnes pour qu’elles puissent découvrir un lieu unique ». Encore une fois, lisez le cas d’usage ci-dessous. Repérez tous les nouveaux noms qui doivent être ajoutés à notre système, puis voyez si vous pouvez les ajouter à notre diagramme existant.
L’opérateur sélectionne l’option “réserver un voyage”.
Le système demande quel est le nombre de touristes.
L’opérateur saisit le nombre de touristes.
Le système demande quelle est la destination.
L’opérateur saisit la destination.
Le système détermine si un avion a la capacité de gérer ce voyage, en fonction du poids et de la distance estimés.
Le système répond en indiquant si le voyage peut se faire.
Le système demande les dates de départ (à destination de) et de retour (retour à la maison).
Le système enregistre le voyage.
Le système demande des informations concernant les touristes (étape réitérée).
Le système recherche un pilote pouvant être disponible.
Le système réserve l’avion et le pilote.
Réponse
On dirait que nous avons besoin de « voyage » et de « touristes ». Nous pouvons maintenant mettre à jour notre système avec les entités pertinentes.
Étant donné que notre diagramme est en train de devenir trop complexe, à cause de notre mauvaise architecture, je n’en montrerai qu’une partie.
Le fait de continuer sur ce chemin architectural nous entraîne vers une application qui deviendra encore plus difficile à tester et à modifier.
En résumé
On crée généralement une description de cas d’usage pour chaque user story.
Dans les descriptions, il y a des mots-clés qui ressortent. Ils deviendront des entités.
Il faut bien déterminer si les entités sont nouvelles, ou s’il y a de possibles modifications d’entités existantes.
Maintenant que nous savons ce qui doit être ajouté ou modifié, nous pouvons examiner les faiblesses de notre système actuel. En avant !
