---
title: "Parte 3: Análisis de una aplicación heredada con Altova UModel"
date: "2009-05-01"
tags: 
  - "altova"
  - "c"
  - "java"
  - "missionkit"
  - "software-modeling"
  - "uml"
  - "uml-tool"
  - "umodel"
  - "visual-basic"
description: Descubra cómo analizar aplicaciones heredadas utilizando diagramas de máquinas de estados UML en Altova UModel, lo que le permitirá comprender mejor los estados y las transiciones del sistema.
---
Status: #blog

Tags:  #altova #c #java #missionkit #software-modeling #uml #uml-tool #umodel #visual-basic

Categories: [Altova](/blog/es/category/altova.md) 
# Parte 3: Análisis de una aplicación heredada con Altova UModel

En [Parte 1](https://www.altova.com/blog/2009/04/analyzing-legacy-application-with.html) de esta serie, aplicamos [ingeniería inversa](https://www.altova.com/es/features_reverse_engineer.html) funcionalidad de [Altova UModel](https://www.altova.com/es/products/umodel/uml_tool.html) para importar el código fuente de una aplicación de simulación de cajeros automáticos existente. Creamos un diagrama UML [diagrama de clases](https://www.altova.com/es/features_class_diagram.html) para ilustrar la jerarquía de clases y las relaciones entre clases de la aplicación. En [Parte 2](https://www.altova.com/blog/2009/04/part-2-analyzing-legacy-application.html) Hicimos un diagrama UML [diagrama de casos de uso](https://www.altova.com/es/features_use_case.html) Para documentar las interacciones de los usuarios con el sistema, elaboramos varios diagramas de casos de uso adicionales para detallar las interacciones y describir una mejora planificada. En esta entrega, analizaremos el cajero automático desde una perspectiva diferente. 

En una calurosa tarde de verano, un conductor agotado divisa un puesto de helados con una zona de acceso para vehículos. Solo hay un problema: ¡no tiene efectivo! Así que se desvía hacia el estacionamiento de un centro comercial y aparca junto a un cajero automático en un quiosco de vidrio. Aún antes de salir del coche, nuestro cliente bancario, afectado por el calor, se pregunta sobre el estado del cajero. ¿Está ya en uso por otro cliente que tiene asuntos bancarios complejos? Incluso si no hay nadie dentro del quiosco, ¿podría el cajero automático estar fuera de servicio? 

Un diagrama de máquina de estados UML [(también llamado diagrama de estados)](https://www.altova.com/es/features_state_machine_diagram.html) nos permitirá mapear los estados de nuestro simulador de cajero automático, así como los desencadenantes, los eventos y las transiciones entre estados, para que podamos comprender mejor cómo funciona nuestra aplicación heredada. Volvamos a nuestra experiencia ejecutando la simulación para empezar: 

[![Menú de inicio de sesión para la simulación de cajeros automáticos](https://lh5.ggpht.com/_REdrfeVqYdU/Sfsxmyu-x6I/AAAAAAAAAFc/1ttoVt3gF-Q/image1_thumb%5B1%5D.gif?imgmax=800 "ATM Simulation Log In menu")](http://lh6.ggpht.com/_REdrfeVqYdU/Sfsxm31zkpI/AAAAAAAAAFY/DTDB2hmhH48/s1600-h/image1%5B3%5D.gif)

[![Menú de transacciones de simulación de cajero automático](https://lh3.ggpht.com/_REdrfeVqYdU/SfsxoBbTouI/AAAAAAAAAFk/05wRGaLq5P0/image2_thumb%5B2%5D.gif?imgmax=800 "ATM Simulation Transaction Menu")](http://lh3.ggpht.com/_REdrfeVqYdU/SfsxnsG1tVI/AAAAAAAAAFg/hHwOLukZxYk/s1600-h/image2%5B4%5D.gif) 

Cuando lanzamos la aplicación heredada, nuestro simulador de cajero automático entró en su estado de inactividad, esperando al primer cliente: 

[![Diagrama de máquina de estados UML](https://lh5.ggpht.com/_REdrfeVqYdU/SfsxoWNUKRI/AAAAAAAAAFs/MpZ4Vt9WJ5o/image3_thumb%5B1%5D.gif?imgmax=800 "UML State Machine Diagram start")](http://lh5.ggpht.com/_REdrfeVqYdU/SfsxoA_hNqI/AAAAAAAAAFo/bm_h5hrfDLI/s1600-h/image3%5B3%5D.gif) 

A continuación, puede ser útil identificar y dibujar estados adicionales en óvalos separados. Podremos mover estos óvalos como piezas de un rompecabezas para encontrar la secuencia lógica, sin preocuparnos por las transiciones de un estado a otro.

[![Diagrama de máquina de estados UML - preliminar](https://lh3.ggpht.com/_REdrfeVqYdU/Sfsxo2BkWJI/AAAAAAAAAF0/fymyDQyuM9E/image4_thumb%5B1%5D.gif?imgmax=800 "UML state machine diagram - preliminary")](http://lh6.ggpht.com/_REdrfeVqYdU/Sfsxor2MyNI/AAAAAAAAAFw/bFiRGAyCknE/s1600-h/image4%5B3%5D.gif) 

Esta lista preliminar de los estados del cajero automático es solo nuestro primer borrador. Las descripciones de los estados fueron sugeridas por las opciones del menú de nuestra aplicación existente, y es evidente que podemos simplificar:

*   No hay diferencia entre "Seleccionar primera transacción" y "Seleccionar siguiente transacción", por lo que estas opciones deberían combinarse.
*   "Cerrar sesión" probablemente no es un estado, sino una transición instantánea cuando nuestro usuario presiona el número 4 en el menú de transacciones.
*   Podemos asignar la introducción por parte del usuario de una cantidad de retiro o una cantidad de depósito como subestados dentro del estado "Realizando transacción".

El tercer punto simplifica nuestro diagrama y también sería coherente con nuestra forma de tratar la introducción del número de cuenta y el PIN como parte del proceso de "Autenticación del usuario".

Después de realizar estos cambios y añadir las transiciones, nuestro diagrama se verá así: 

[![Diagrama de máquina de estados UML con transiciones](https://lh3.ggpht.com/_REdrfeVqYdU/SfsxpSLK3aI/AAAAAAAAAF8/Mw8IcBdYQco/image5_thumb%5B1%5D.gif?imgmax=800 "UML state amachine diagram with transitions")](http://lh5.ggpht.com/_REdrfeVqYdU/Sfsxo2pmqZI/AAAAAAAAAF4/Vrgu1Fxt8P8/s1600-h/image5%5B3%5D.gif)

Las transiciones simples que hemos añadido son elementos que activan el cambio del cajero automático de un estado a otro. Además, observe que cada estado tiene al menos una entrada y una salida; de lo contrario, la aplicación heredada podría llevar a nuestro usuario a un punto muerto. El elemento en forma de diamante entre "Seleccionar transacción" y "Ejecutar transacción" es el símbolo UML que representa una opción de flujos. Inicialmente, puede parecer ilógico que la aplicación permita al usuario cerrar sesión antes de realizar cualquier transacción, pero esa es una opción que ofrece nuestra aplicación heredada en el menú de transacciones. ¡Y en el mundo real, los usuarios a veces cambian de opinión en el último momento! Nos hemos esforzado por utilizar un lenguaje coherente siempre que ha sido posible para los nombres y las descripciones de nuestros elementos. Los estados se nombran con verbos en presente que terminan en "-ing". Las transiciones están etiquetadas para indicar la finalización de la acción que provoca el cambio de estado. El uso coherente en la denominación de los elementos mejora la claridad del diagrama. 

Una vez que tengamos un diagrama de estados funcional como el que se muestra arriba, es útil considerar qué sucede si se intenta una transición, pero no se completa con éxito. El usuario del cajero automático podría ingresar una combinación de número de cuenta/PIN inválida, o un usuario autenticado podría solicitar un monto de retiro que exceda el saldo de la cuenta. Podemos mejorar nuestro diagrama de estados para incluir estas posibilidades: 

[![Diagrama completo de máquina de estados UML](https://lh3.ggpht.com/_REdrfeVqYdU/SfsxpgAdy6I/AAAAAAAAAGE/9yJi6CFcN-M/image6_thumb%5B1%5D.gif?imgmax=800 "Complete UML state machine diagram")](http://lh6.ggpht.com/_REdrfeVqYdU/SfsxpSQ190I/AAAAAAAAAGA/xtG56Cmeogs/s1600-h/image6%5B3%5D.gif) 

Ahora, nuestro diagrama de máquina de estados muestra muchas rutas alternativas a través de la ejecución de la aplicación, no solo la única ruta "ideal" y sin errores. Hemos optado por una orientación vertical para el diseño de nuestro diagrama, pero no existe ninguna regla que imponga esa forma. Algunas aplicaciones se adaptarán mejor a un diseño horizontal, o quizás eso simplemente sea su preferencia personal. Esta ilustración muestra una pequeña parte de nuestro diagrama de máquina de estados en formato horizontal: 

[![Diagrama de máquina de estados UML en disposición horizontal](https://lh6.ggpht.com/_REdrfeVqYdU/SfsxqJJG08I/AAAAAAAAAGM/kpCKzjysbwI/image7_thumb%5B1%5D.gif?imgmax=800 "UML state machine diagram in horizontal layout")](http://lh4.ggpht.com/_REdrfeVqYdU/Sfsxp61lanI/AAAAAAAAAGI/jd9Ogb8-01k/s1600-h/image7%5B3%5D.gif) 

Independientemente del diseño que elija para el diagrama de máquina de estados, no debe dibujar líneas de transición que se crucen o se superpongan. Dibujar un diagrama de máquina de estados UML puede parecer excesivo para nuestra simulación de cajeros automáticos, ya que la aplicación existente es pequeña y todos estamos familiarizados con el funcionamiento de los cajeros automáticos. Sin embargo, estas técnicas pueden ser muy útiles cuando se trabaja en una aplicación mucho más grande que opera en un área temática desconocida o compleja. 

Si está listo para crear diagramas de máquinas de estados UML para su propia aplicación heredada en Java, C# o Visual Basic, [haga clic aquí para descargar una versión de prueba gratuita y completamente funcional de 30 días de Altova UModel](https://www.altova.com/es/download/umodel/uml_tool_enterprise.html). En nuestra próxima entrega, analizaremos en detalle la transacción de retiro y la nueva función que presentamos en la Parte 2.
