Analyse d'une application héritée avec Altova UModel – Partie 1

Un jour ou l'autre, presque tous les développeurs professionnels se retrouveront à devoir corriger des erreurs ou à ajouter des fonctionnalités à une application existante dont ils n'ont pas participé à la création. Dans ces situations, une documentation inexacte ou incomplète, ainsi que le manque d'accès à l'équipe de développement d'origine, peuvent constituer des obstacles majeurs. Heureusement, Altova UModel peut réaliser une rétro-ingénierie de logiciels existants afin de créer un modèle visuel qui accélère l'analyse et améliore la compréhension d'une application existante. Voici la première d'une série d'articles dans lesquels nous allons utiliser UModel, la solution d'Altova Outil UML pour la modélisation de logiciels et au développement, afin d'analyser une simulation de distributeur automatique (ATM) rédigée en Java. L'application est basée sur plusieurs exemples de distributeurs automatiques tirés de tutoriels Java populaires. Étant donné que le système est simple et que le fonctionnement d'un distributeur automatique est bien connu, nous nous concentrerons davantage sur les techniques que vous pouvez appliquer à vos propres projets Java, C# et Visual Basic, plutôt que sur le code exemple. Voici une capture d'écran de l'application héritée en cours d'exécution dans une fenêtre de commande :

Le développeur initial a gracieusement fourni les informations de connexion d'un compte de démonstration, ce qui nous permet de nous connecter. L'application affiche ensuite un menu de transactions de distributeur automatique familier :

Si nous examinons le dossier contenant l'application, nous constatons la présence de fichiers sources Java et de fichiers .class compilés, mais aucun fichier de projet.

Ce n'est pas un problème. Le menu du projet UModel nous permet d'importer un projet, un répertoire de code source, ou même les fichiers binaires d'une application compilée. Le code source de projets très volumineux est généralement organisé dans plusieurs dossiers, donc, même si vous avez un fichier de projet, il peut être utile d'examiner un dossier à la fois.

Avant de commencer, nous allons nous assurer de configurer les options de UModel pour qu'il dessine automatiquement toutes les associations de classes définies dans le code source

Lorsque nous importons le dossier, nous souhaitons également inclure tous les commentaires JavaDoc présents dans le code source, afin de les utiliser comme documentation pour notre projet UModel

Pour notre première exploration de cette application existante, nous souhaitons avoir une vue d'ensemble, nous n'ouvrirons donc pas tous les modules optionnels :

UModel importe le projet en quelques secondes, et la fenêtre de messages indique qu'il n'y a aucune erreur. L'arborescence des diagrammes contient deux diagrammes :

Nous pouvons cliquer sur l'onglet "Arbre des modèles" et développer le dossier source pour afficher les icônes représentant toutes les classes Java importées par UModel

Nous pouvons revenir à l'arborescence des diagrammes pour ouvrir le contenu du diagramme de classes UML source UML class diagram. Après avoir défini tous les styles de lignes comme étant orthogonaux et après avoir repositionné certaines lignes et classes pour éviter les chevauchements, nous constatons que le diagramme illustre clairement les classes de l'application et leurs relations :

Notez que le nom de la classe "Transaction" est en italique, ce qui indique qu'il s'agit d'une classe abstraite (ou classe mère), et que les sous-classes "BalanceInquiry", "Withdrawal" et "Deposit" héritent de ses caractéristiques. Si vous cliquez sur la classe "Transaction" pour la sélectionner, l'héritage est illustré dans la fenêtre d'aide "Hiérarchie" de UModel, et tous les commentaires JavaDoc apparaissant dans le code source immédiatement avant la définition de la classe sont affichés dans la fenêtre de documentation

Si nous utilisions uniquement un éditeur de texte pour examiner l'application existante, nous devrions examiner chaque fichier de code source pour comprendre la hiérarchie illustrée ci-dessus. En effet, la classe Transaction ne reconnaît pas ses sous-classes en interne. Lorsqu'on identifie une sous-classe, elle ne reconnaît pas ses classes sœurs. Et nous ne pouvons pas être sûrs qu'une autre classe, dont le nom est illogique, ne soit pas une sous-classe de Transaction, tant que nous ne les avons pas toutes examinées. Vous pouvez également sélectionner chaque classe individuellement pour consulter sa documentation dans la fenêtre de documentation. Ou, si vous préférez un schéma plus clair, vous pouvez supprimer les étiquettes d'association du schéma uniquement :

Maintenant, l'astérisque représentant la multiplicité "de zéro à plusieurs" des comptes dans la base de données bancaire est beaucoup plus visible.

Un autre membre de notre équipe de développement a trouvé un diagramme de classes partiel, censé représenter l'ancien projet, et nous l'a transmis. Nous constatons immédiatement qu'il ne ressemble pas au diagramme généré par UModel :

La documentation de notre ancienne application ne correspond pas au code – un problème regrettable, mais courant ! Il existe plusieurs différences entre l'ancien schéma et celui que nous avons généré :

· The associations between ATM and the physical components are shown as composition associations

· The association between ATM and the BankDatabase is described by a text annotation

· The association between ATM and Transaction also has a text annotation, and it does not even exist in the UModel diagram

· Multiplicity is defined at each end of each association, but none were created by UModel

Examinons chaque point :

· The representation of composition in the Java language is identical to ordinary association, so UModel could not deduce the composition characteristic. Of course the ATM “is composed of” a keypad, screen, cash dispenser, and deposit slot, so we can update the diagram to show composition.

· We can add a text annotation to any UModel association arrow. Simply click the arrow and start typing.

· If UModel did not create an association arrow between the ATM class and the Transaction, one must not be defined in the source code. We will postpone further investigation of this anomaly for now. · Multiplicity as shown in the legacy diagram would also require specific definition in the source code. We’ll leave this for investigation later too. Maybe that old diagram was left in the back of the file cabinet for a reason!

Nous allons ajouter l'annotation, puis mettre à jour la caractéristique d'agrégation de chaque association ATM dans la fenêtre des propriétés de UModel. Utilisons également la barre d'outils de mise en page de UModel pour rendre les rectangles représentant toutes les classes de la même taille. Notre diagramme de classes ressemble maintenant à ceci :

Le diagramme de classes finalisé ne fait que nous permettre de commencer notre analyse. Dans les prochains chapitres, nous approfondirons l'étude du code de l'application et générerons automatiquement davantage de Diagrammes UML, et créer de nouveaux schémas au fur et à mesure que notre compréhension du code existant s'améliore.

Si vous souhaitez immédiatement commencer à analyser et à modifier vos anciennes applications Java, C# ou Visual Basic, cliquez ici pour télécharger une version d'essai gratuite et entièrement fonctionnelle de 30 jours de Altova UModel.