Partie 4 : Analyse d'une application existante avec Altova UModel

Dans la première partie de cette série, nous avons importé du code source dans Altova UModel afin de créer un projet UML, et nous avons examiné un diagramme de classes de notre application ATM existante.

Dans la partie 2, nous avons créé une série de diagrammes de cas d'utilisation UML pour décrire les interactions des utilisateurs avec le système, et nous avons prévu une amélioration de l'application pour mettre en œuvre des frais de retrait.

Dans la partie 3, nous avons conçu un diagramme d'état UML afin d'analyser et de documenter plus en détail le fonctionnement de notre système. Dans cet épisode, nous reviendrons sur l'amélioration que nous avions prévue. Nous avons pour mission de mettre en œuvre des frais de retrait aux distributeurs automatiques : 2 dollars pour les retraits inférieurs à 100 dollars et 4 dollars pour les retraits de 100 dollars ou plus. Dans la partie 2, nous avons créé un diagramme de cas d'utilisation pour illustrer la manière dont les utilisateurs interagiront avec cette nouvelle fonctionnalité :

À partir de notre analyse initiale des classes orientées objet présentée dans la première partie, nous savons que notre système contient une classe "Retrait", qui est l'endroit logique pour implémenter notre nouvelle fonctionnalité. Nous pouvons afficher un nouveau diagramme de classe pour la classe "Retrait" en la sélectionnant dans l'arborescence des modèles et en choisissant l'option appropriée dans le menu contextuel qui apparaît en faisant un clic droit pour créer un nouveau diagramme.

Nous avons choisi de créer un diagramme hiérarchique afin que toutes les propriétés de la classe "Retrait" soient visibles, y compris les propriétés héritées de la classe "Transaction". Avant de mettre en œuvre la fonctionnalité de frais, nous avons une question connexe à examiner. Nous voulions vérifier que le code actuel inclut un test pour s'assurer que le montant de retrait demandé par l'utilisateur ne dépasse pas le solde actuel du compte. Un diagramme de séquence UML nous permettra de suivre le déroulement de l'exécution d'un retrait. UModel peut générer automatiquement des diagrammes de séquence à partir des opérations des classes inversées. Nous pouvons sélectionner l'opération "exécuter" dans notre diagramme de classes et choisir "Générer un diagramme de séquence" dans le menu contextuel de UModel pour créer le diagramme dont nous avons besoin.

La fenêtre de dialogue de génération de diagrammes de séquence UModel propose plusieurs options qui faciliteront la mise en œuvre de cette nouvelle fonctionnalité. Nous avons sélectionné l'option "Mettre à jour automatiquement" car nous souhaiterons mettre à jour le diagramme ultérieurement, après avoir modifié le code. Afficher le code dans une couche distincte peut nous aider à nous concentrer sur la logique de retrait.

La taille des barres de défilement indique que nous ne voyons qu'une petite partie du diagramme de séquence dans la fenêtre actuelle. Nous pouvons réduire l'affichage pour qu'il s'adapte à la fenêtre, mais le texte sera probablement illisible. Au lieu de cela, profitons de l'interface utilisateur flexible de UModel pour masquer automatiquement l'arborescence des diagrammes et les fenêtres de propriétés, ce qui nous permet d'agrandir la fenêtre d'aide "Aperçu" :

Nous pouvons explorer le diagramme de séquence en faisant glisser le carré rouge dans la fenêtre de vue d'ensemble. Cela nous permet de localiser rapidement la comparaison du montant du retrait et du solde du compte.

Nous pouvons également voir les messages d'erreur qui s'affichent si le distributeur automatique de billets ne contient pas suffisamment d'argent ou si le solde du compte est trop faible.

En revenant au diagramme de classes de retrait, nous pouvons ajouter la propriété "frais" et définir sa valeur par défaut :

Nous allons procéder à une première phase de mise en œuvre de la logique de calcul des frais, sans pour l'instant inclure l'option d'annulation par l'utilisateur. La modification du code source, basée sur notre modèle, ajoute la propriété des frais à la classe "Withdrawal". Ensuite, nous utiliserons notre éditeur de code source préféré pour implémenter directement la logique de calcul des frais dans le fichier "Withdrawal.java". Les tests de notre application recompilée montrent les résultats suivants :

Le solde initial était de 147 $. Après avoir retiré 100 $, le nouveau solde est de 43 $. Les frais sont affichés dans un nouveau message, et le solde final est correct. Cependant, le diagramme de séquence dans notre modèle UML est inexact car il ne prend pas en compte la fonctionnalité des frais. Nous pouvons corriger le diagramme de séquence en mettant à jour le projet UML à partir du code source modifié. La fenêtre "Messages UModel" indique que des modifications dans le fichier Withdrawal.java ont entraîné la régénération du diagramme de séquence. De plus, nous pouvons facilement naviguer dans le diagramme pour localiser notre nouveau test du montant du retrait et vérifier si les frais doivent être augmentés à 4 $.

Maintenant que notre diagramme de séquence modifié représente graphiquement le fonctionnement mis à jour du distributeur automatique, nous pouvons être assurés que le conducteur stressé que nous avons rencontré dans la troisième partie de cette série a suffisamment d'argent pour acheter ce cornet de glace ! Dans la prochaine partie, nous profiterons d'une autre fonctionnalité de UModel pour générer une documentation détaillée de notre projet, couvrant le travail effectué jusqu'à présent. C'est un avantage supplémentaire de maintenir notre modèle UML et le code source de l'application synchronisés.

Si vous souhaitez essayer Altova UModel sur votre propre application Java, C# ou Visual Basic existante, cliquez ici pour télécharger une version d'essai gratuite et entièrement fonctionnelle pendant 30 jours.