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

Dans Première partie De cette série, nous avons appliqué.. rétro-ingénierie fonctionnalité de Altova UModel pour importer le code source d'une application de simulation de distributeur automatique existante. Nous avons créé un diagramme UML diagramme de classes pour illustrer la hiérarchie des classes et les relations entre les classes de l'application Deuxième partie Nous avons créé un diagramme UML diagramme de cas d'utilisation pour documenter les interactions des utilisateurs avec le système, et nous avons créé plusieurs diagrammes de cas d'utilisation supplémentaires afin de détailler ces interactions et de présenter une amélioration prévue. Dans cet article, nous allons examiner le distributeur automatique sous un autre angle.

Par une chaude après-midi d'été, un automobiliste pressé aperçoit une échoppe de glaces avec une voie de passage pour les voitures. Mais il y a un problème : il n'a pas de liquide ! Il se gare donc sur le parking d'un centre commercial et se dirige vers un distributeur automatique de billets situé dans une cabine en verre. Avant même de sortir de sa voiture, ce client de banque, déjà agité par la chaleur, se demande quel est l'état du distributeur. Est-ce qu'un autre client, avec des opérations bancaires complexes, l'utilise déjà ? Et même s'il n'y a personne dans la cabine, le distributeur pourrait-il être hors service ?

Un diagramme d'état UML (également appelé diagramme d'états) nous permettra de représenter les états de notre simulateur de distributeur automatique, ainsi que les déclencheurs, les événements et les transitions entre ces états, afin de mieux comprendre le fonctionnement de notre application existante. Reprenons notre expérience de simulation pour commencer :

Lors du lancement de l'application existante, notre simulateur de distributeur automatique est entré dans son état de veille, en attendant le premier client :

Ensuite, il peut être utile d'identifier et de représenter des états supplémentaires sous forme d'ovales isolés. Nous pourrons déplacer ces ovales comme des pièces de puzzle afin de trouver la séquence logique, sans nous soucier des transitions entre les différents états.

Cette liste préliminaire des états de l'automate à états n'est qu'une première version. Les descriptions des états ont été suggérées par les éléments du menu de notre application existante, et il est évident que nous pouvons les simplifier :

Il n'y a pas de différence entre "Sélectionner la première transaction" et "Sélectionner la transaction suivante", donc ces options devraient être combinées.
"Déconnexion" n'est probablement pas un état, mais une transition instantanée lorsque notre utilisateur appuie sur le chiffre 4 dans le menu des transactions.
Nous pouvons attribuer la saisie par l'utilisateur d'un montant de retrait ou d'un montant de dépôt comme des sous-états au sein de l'état "Exécution de la transaction".

Le troisième point simplifie notre diagramme et serait également cohérent avec notre approche concernant la saisie du numéro de compte et du code PIN par l'utilisateur, qui font partie du processus d'authentification de l'utilisateur.

Après avoir apporté ces modifications et ajouté les transitions, notre diagramme ressemble à ceci :

Les transitions simples que nous avons ajoutées sont des déclencheurs qui font passer le distributeur automatique de billets (DAB) d'un état à l'autre. Notez également que chaque état possède au moins une entrée et une sortie ; sinon, l'application existante pourrait piéger nos utilisateurs dans une impasse. L'élément en forme de losange entre "Sélectionner une transaction" et "Effectuer une transaction" est le symbole UML qui indique un choix de flux. Au premier abord, il peut sembler illogique que l'application permette à l'utilisateur de se déconnecter avant d'effectuer une transaction, mais c'est une option que notre application existante propose dans le menu des transactions. Et il est bien connu que les utilisateurs, dans la réalité, peuvent changer d'avis à la dernière minute ! Nous avons veillé à utiliser un langage cohérent dans la mesure du possible pour les noms et les descriptions de nos éléments. Les états sont nommés avec des verbes au présent qui se terminent par "-ing". Les transitions sont étiquetées pour indiquer l'achèvement de l'action qui provoque le changement d'état. L'utilisation de noms d'éléments cohérents améliore la clarté du diagramme.

Une fois que nous avons un diagramme d'états fonctionnel, comme celui ci-dessus, il est utile de réfléchir à ce qui se passe lorsqu'une transition est tentée, mais ne se réalise pas avec succès. L'utilisateur d'un distributeur automatique de billets (DAB) peut saisir une combinaison de numéro de compte/code PIN incorrecte, ou un utilisateur authentifié peut demander un montant de retrait qui dépasse le solde du compte. Nous pouvons améliorer notre diagramme d'états pour inclure ces possibilités :

Notre diagramme d'état machine illustre désormais de nombreux chemins alternatifs dans l'exécution de l'application, et non plus seulement le chemin unique et sans erreur que l'on appelle souvent le "chemin idéal". Nous avons choisi une orientation verticale pour la présentation de notre diagramme, mais il n'existe aucune règle qui impose cette forme. Certaines applications se prêtent mieux à une présentation horizontale, ou peut-être que c'est simplement une question de préférence personnelle. Cette illustration montre une petite partie de notre diagramme d'état machine, présentée horizontalement :

Quel que soit le type de diagramme d'état que vous choisissez, vous ne devez pas dessiner de lignes de transition qui se croisent ou se chevauchent. La création d'un diagramme d'état UML peut sembler excessive pour notre simulation de distributeur automatique, étant donné que l'application existante est petite et que nous connaissons tous le fonctionnement des distributeurs automatiques. Cependant, ces techniques peuvent être très utiles lorsque vous devez travailler sur une application beaucoup plus importante, opérant dans un domaine complexe ou peu familier.

Si vous êtes prêt à créer des diagrammes d'automates d'états UML pour vos propres applications Java, C# ou Visual Basic existantes, cliquez ici pour télécharger une version d'essai gratuite et entièrement fonctionnelle de 30 jours d'Altova UModel. Dans notre prochaine partie, nous examinerons en détail la transaction de retrait et la nouvelle fonctionnalité que nous avions prévue dans la partie 2.