Parte 2: Análisis de una aplicación heredada con Altova UModel
En la Parte 1 de la serie "Analizando una aplicación heredada", presentamos nuestra aplicación de simulación de cajeros automáticos, importamos el código fuente de Java a un proyecto de UModel y refinamos un diagrama de clases para obtener una visión general de las clases de la aplicación y sus relaciones. En esta entrada, crearemos diagramas de casos de uso para documentar la funcionalidad actual de nuestra aplicación de cajeros automáticos, y añadiremos un caso de uso para planificar una futura mejora. Como vimos en la Parte 1, cuando un usuario ejecuta nuestra simulación de cajero automático, se le solicita que inicie sesión con un número de cuenta y un PIN, y luego se le presenta un menú de transacciones que resume todas las interacciones disponibles con la aplicación:
Utilizando el menú de transacciones como guía, podemos crear un diagrama de casos de uso general que documente las interacciones del usuario con la simulación del cajero automático:
Si está familiarizado con la notación UML, lo primero que quizás haya notado es que el "actor" en nuestro diagrama no se parece a la figura esquemática típica de UML. UModel permite a los modeladores de software asignar cualquier archivo de imagen .bmp de Windows para representar a un actor en un diagrama de casos de uso. Utilizamos la ventana de ayuda de "Propiedades" para asignar una imagen de la biblioteca que se proporciona con UModel.
Un diagrama de casos de uso no es el lugar adecuado para definir el flujo de la aplicación ni las clases orientadas a objetos, sino simplemente para documentar cómo un usuario (un "actor" en la terminología UML) interactúa con el sistema. Podemos crear diagramas de casos de uso adicionales para mostrar más detalles sobre cada interacción. Expandir cada interacción en un diagrama separado mejora la claridad al mantener cada esquema simple y ordenado, y deja suficiente espacio para probar diferentes opciones.
Hemos añadido la autenticación del número de cuenta y el PIN en una nota, en lugar de en un diagrama de caso de uso, porque el usuario del cajero automático no es el agente que realiza ese paso. Basándonos en la experiencia real con los cajeros automáticos, podemos suponer (aunque aún no hemos revisado el código) que un retiro se cancelará si el monto solicitado es mayor que el saldo de la cuenta. Sin embargo, la comparación entre el monto del retiro y el saldo de la cuenta no la realiza el usuario, por lo que esa actividad tampoco se representa en un diagrama de caso de uso.
La flecha dentro del caso de uso "Retirar efectivo" indica un hipervínculo. UModel permite adjuntar uno o varios hipervínculos a cualquier elemento de sus diagramas. Un hipervínculo puede referenciar una URL, un archivo externo o incluso otro diagrama. El cuadro de diálogo de hipervínculos también le permite definir texto de ayuda para sus hipervínculos.
Si define más de un hipervínculo, el texto de ayuda se convertirá en un menú de selección emergente. Supongamos que se nos ha asignado la tarea de modificar la simulación existente de cajeros automáticos para cobrar una tarifa por cada retiro. Si el monto del retiro es inferior a 100 dólares, la tarifa será de 2 dólares. Si el monto del retiro es de 100 dólares o más, la tarifa será de 4 dólares. Dado que el cajero automático no dispensa billetes de un dólar, la tarifa debe cobrarse a la cuenta, no deducirse del efectivo retirado. La tarifa se mostrará antes de que se dispense cualquier efectivo, y el usuario podrá cancelar la transacción. Podemos añadir este nuevo requisito a nuestro diagrama de casos de uso de "Retiro de efectivo en cajero automático".
Hemos cambiado el color del óvalo correspondiente al caso de uso "Aprobar tarifa" para indicar que esta es una funcionalidad planificada que aún no está implementada. Algunos desarrolladores podrían argumentar que la nota adjunta al óvalo de "Aprobar tarifa" es redundante, ya que la propia indicación de "incluir" ya señala que "Aprobar tarifa" es un componente necesario para "Retirar efectivo". Sin embargo, muchas personas se confunden con la diferencia entre "incluir" y "extender", por lo que es mejor ser absolutamente claros. También podemos aprovechar la función de "Capas" de UModel para colocar todos los elementos relacionados con la nueva funcionalidad en una capa separada.
Ahora, la ventana de ayuda de "Capas" nos permite mostrar u ocultar la función planificada en nuestra vista del diagrama.
La experiencia real con los cajeros automáticos nos indica que falta una transacción en la simulación actual. El menú de transacciones no ofrece la opción de transferir fondos entre cuentas. A partir de los diagramas que ya hemos creado, podemos ver que el diseño original de la aplicación dificultará la implementación de una operación de transferencia. El inicio de sesión del usuario se basa en el número de cuenta, y parece que la aplicación actual no comprende el concepto de un cliente bancario que tenga tanto una cuenta corriente como una cuenta de ahorros. Si nuestro gerente solicita la función de transferencia de fondos, necesitaremos hablar con el arquitecto de software empresarial de nuestra empresa. Será necesario implementar un identificador de usuario vinculado a múltiples cuentas, no solo en nuestra aplicación de simulación de cajeros automáticos, sino también en la base de datos del banco.
El Premio Jolt, galardonado Altova MissionKit para arquitectos de sistemas empresariales Es una colección de ocho herramientas en formato XML, para bases de datos y UML, diseñada para el arquitecto de software empresarial que pueda necesitar herramientas de modelado UML y de gestión de bases de datos, además de capacidades avanzadas de XML, servicios web e integración de datos.
Haga clic aquí para descargar una versión de prueba completamente funcional de 30 días. En la próxima entrega, analizaremos la simulación de cajeros automáticos desde una perspectiva completamente diferente, mientras nos preparamos para profundizar en el código.