Analizando una aplicación heredada con Altova UModel: Parte 1

Eventualmente, casi todos los desarrolladores profesionales se verán asignados a depurar o añadir funcionalidades a una aplicación existente en la que no participaron en su creación. En estas situaciones, la documentación inexacta o incompleta, así como la falta de acceso al equipo de desarrollo original, pueden representar grandes obstáculos. Afortunadamente, Altova UModel puede realizar ingeniería inversa de software existente para crear un modelo visual que acelera el análisis y mejora la comprensión de una aplicación heredada. Esta es la primera de una serie de publicaciones en las que aplicaremos UModel, el producto de Altova Herramienta UML para el modelado de software y desarrollo, para analizar una simulación de un cajero automático (ATM) escrita en Java. La aplicación se basa en varios ejemplos de cajeros automáticos (ATM) extraídos de populares tutoriales de Java. Dado que el programa es pequeño y el funcionamiento de un cajero automático es conocido, nos centraremos más en las técnicas que pueden aplicarse a sus propios proyectos de Java, C# y Visual Basic, en lugar de en el código de ejemplo. Aquí se muestra una vista de la aplicación heredada ejecutándose en una ventana de comandos:

El desarrollador original proporcionó convenientemente la información de la cuenta de ejemplo, por lo que podemos iniciar sesión. La aplicación luego muestra un menú de transacciones de cajero automático familiar:

Si examinamos la carpeta que contiene la aplicación, vemos archivos de código fuente de Java y archivos .class compilados, pero no encontramos ningún archivo de proyecto.

No es un problema. El menú del proyecto UModel nos permite importar un proyecto, un directorio de código fuente, o incluso los archivos binarios de una aplicación compilada. El código fuente de proyectos muy grandes probablemente esté organizado en múltiples carpetas, por lo que, incluso si tiene un archivo de proyecto, es posible que desee explorar una carpeta a la vez.

Antes de comenzar, es importante configurar las opciones de UModel para que dibuje automáticamente todas las asociaciones de clases definidas en el código fuente

Al importar la carpeta, también queremos incluir cualquier comentario de JavaDoc en el código fuente, para utilizarlos como documentación para nuestro proyecto UModel

Para nuestra primera revisión de la aplicación heredada, necesitamos una visión general, por lo que no abriremos todos los módulos opcionales:

UModel importa el proyecto en cuestión de segundos, y la ventana de mensajes no muestra ningún error. El árbol de diagramas contiene dos diagramas:

Podemos hacer clic en la pestaña "Árbol de modelos" y expandir la carpeta de origen para ver los iconos que representan todas las clases Java que UModel ha importado

Podemos volver al Árbol de Diagramas para abrir el contenido del diagrama de clases UML de la fuente UML class diagram. Después de establecer todos los estilos de línea como líneas rectas y de reposicionar algunas líneas y clases para evitar superposiciones, vemos que el diagrama ilustra claramente las clases de la aplicación y sus relaciones:

Tenga en cuenta que el nombre de la clase "Transaction" está en cursiva, lo que indica que es una clase abstracta (o clase principal), y que las subclases "BalanceInquiry", "Withdrawal" y "Deposit" heredan sus características. Si hace clic en la clase "Transaction" para seleccionarla, la ventana de ayuda "Jerarquía" de UModel ilustra la herencia, y cualquier comentario de JavaDoc que aparezca en el código fuente inmediatamente antes de la definición de la clase se mostrará en la ventana de documentación

Si utilizáramos únicamente un editor de texto para analizar la aplicación heredada, tendríamos que revisar cada archivo de código fuente para comprender la estructura jerárquica que se muestra arriba. Esto se debe a que la clase "Transaction" no identifica internamente sus subclases. Cuando encontramos una subclase, esta tampoco identifica sus clases hermanas. Y no podemos estar seguros de que otra clase, con un nombre ilógico, no sea una subclase de "Transaction" hasta que la revisemos todas. También puede seleccionar cada clase individualmente para examinar su documentación en la ventana de documentación. O, si prefiere un diagrama más claro, puede eliminar las etiquetas de asociación del diagrama:

Ahora, el asterisco que representa la multiplicidad "de cero a muchos" de cuentas en la base de datos bancaria es mucho más evidente.

Otro miembro de nuestro equipo de desarrollo encontró un diagrama de clases parcial que, según él, representaba el proyecto heredado, y nos lo hizo llegar. Podemos ver de inmediato que no se parece al diagrama que generó UModel:

La documentación de nuestra aplicación heredada no coincide con el código, ¡un problema desafortunado pero común! Existen varias diferencias entre el diagrama antiguo y el que hemos generado:

· 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

Analicemos cada uno de los puntos:

· 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!

Añadiremos la anotación y, a continuación, actualizaremos la característica de agregación de cada asociación de cajero automático en la ventana de propiedades de UModel. También utilizaremos la barra de herramientas de diseño de UModel para que los rectángulos que representan todas las clases tengan el mismo tamaño. Ahora, nuestro diagrama de clases se verá así:

El diagrama de clases completado es solo el punto de partida de nuestro análisis. En las próximas entregas, profundizaremos en el código de la aplicación y generaremos automáticamente más Diagramas UML, y crear algunos nuevos diagramas propios a medida que nuestra comprensión del código existente vaya aumentando.

Si desea comenzar de inmediato y analizar a fondo sus propias aplicaciones heredadas de Java, C# o Visual Basic, haga clic aquí para descargar una versión de prueba gratuita y completamente funcional de 30 días de <2>Altova UModel</2>.