ABLaUML es un trabajo derivado de ABL2UML (http://www.oehive.org/ABL2UML) de Thomas Mercer-Hursh (thomas@cintegrity.com).
Lo que se hizo fue tomar ABL2UML y utilizarlo para modelar sistemas procedimentales heredados. Para ello se modificó el código original convirtiéndolo a código orientado a objetos, cambiando el modelo de generación monolítico en uno de generación en etapas discretas secuenciales.
Se agregó la generación del xml que alimenta la generación, a partir de la información contenida en una base de datos. Como en nuestro caso tomamos toda la información de generación a partir de una compilacíón XREF, la base de datos la hemos llamdos xrefsrc. A partir de la información de la base de datos se generan uno o más archivos xml, que serán utilizados, posteriormente, para la generación del UML.
En nuestro caso generamos tres archivos xml:
- para los .p y .i, sus relaciones y acceso a bd
- para las notas de los .p
- para los alias de los .p
Para la generación del UML del modelo de datos (de las bases de datos), se comienza también por la generación de uno o más archivos xml con la estructura de las bases de datos. Luego se utilizan estos archivos para la generación del UML correspondiente.
Se separó la lógica de procesamiento, del manejo del repositorio, utilizando una interfaz, lo que posibilitaría el uso del mismo proceso de generación de UML para la generación en otra herramienta de modelado (en teoría).
De esta forma, la lógica queda separada en tres capas:
- Generación de xml
- Procesamiento del xml para generar UML
- Manipulación del repositorio
El proceso completo de generación del UML queda dividido en tres etapas básicas:
- Recopilación de información y llenado de base de datos xrefsrc
- Generación de xml a partir de xrefsrc y de la estructura de las bases de datos
- Procesamiento del xml y generación del repositorio UML
La última etapa (generación del UML) quedará dividida en múltiples etapas discretas, cada una implementada por una clase trabajadora (Worker). Cada clase trabajadora se encarga de una parte, lo más pequeña posible, del proceso de generación. Por ejemplo, nosotros utilizamos las siguientes clases:
- Para la creación de paquetes y componentes que representan los .p e .i
- Para relacionar los .p e .i entre si
- Para mover los paquetes dentro de otro paquete cuando hay una relación padre-hijo
- Para establecer las notas de los componentes y paquetes
- Para establecer los alias de los componentes y paquetes
- Para crear el diagrama de cada paquete
- Para eliminar las relaciones que no pertenecen al diagrama, en cada diagrama
- Para construir el modelo de datos completo
- Para eliminar del modelo de datos, las tablas que no tienen ninguna relación
- Para completar el modelo de datos
Como puede verse, hay dependencias entre las clases, pero ello no impide que cualquiera de ellas pueda ejecutarse en cualquier orden, independientemente de las demás (lo cual, sin duda, afecta el UML resultante).
Una ventaja del nuevo modelo es que permite la generación incremental del UML.
Para la ejecución de la etapa de generación del UML, se utiliza un objeto UMLBuilder, al que se la pasa una lista de nombres de clases trabajadoras a ejecutar, y el nombre del xml que éstas deben procesar. Esta clase utiliza objetos IXMLParser (XMLParser), IUtils (EAUtils) y un StMapper. El UMLBuilder instancia un objeto de cada clase trabajadora (en el orden especificado), lo asigna al IXMLParser y se procesa el xml, de forma que el objeto trabajador genere el UML utilizando IUtils (EAUtils).
Las clases trabajadoras son una jerarquía de clases que contienen un conjunto de puntos de entrada (interfaz IWorker) que se invocan a medida que se procesa un xml. Cada una de estas clases espera una estructura específica de xml y realiza una manipulación particular del repositorio UML. XMLParser lee un archivo xml (utilizando SAX) y va invocando el método apropiado del trabajador asociado. EAUtils implementa toda la lógica específica de Enterprise Architect para la generación y manipulación del repositorio UML (la mayor parte del código corresponde al código de ABL2UML).
Para la generación de los archivos xml se utilizan clases derivadas de XMLWriter, la cual es una clase genérica de generación de xml. Cada archivo xml que debe generarse requiere una clase que lo genere. En este caso pueden verse las clases:
- XRefwriter
- Aliaswriter
- Notaswriter
- DDictwriter
La generación del UML utiliza estereotipos fijos para cada elemento del modelo, por lo cual se provee de un mapeador de estereotipos (StMapper), que permite utilizar cualquier estereotipo, en lugar de los utilizados internamente. Hay que tener cuidado cuando se mapean estereotipos, ya que éstos se utilizan para diferenciar los elementos del modelo, lo que implica que si se mapea un estereotipo interno a otro estereotipo interno, se pierde la capacidad de distinguir entre estos dos tipos de elementos.
NOTAS:
- al día de hoy no hemos encontrado uso a la tabla xref del repositorio UML, y muchas veces la transferencia del repositorio a archivo EAP falla a causa de esta tabla. Vaciar la tabla soluciona el problema (en la mayoría de los casos), sin efectos adversos sobre el modelo.
- La versión 7.5 y 8.0 tienen un problema con las notas de los conectores, que hace que se pierdan al transferir un EAP al repositorio (la transferencia inversa funciona bien), este problema no es constante, algunas veces lo hace bien y otra mal.
English version
Se utilizan dos bases de datos (por lo menos), la base para los datos respecto del código ABL (xrefsrc) y la base para el repositorio UML (Repository).
Como archivos adjuntos se encuentra el archivo de definición de xrefsrc, la base del repositorio es un tema aparte (bastante complicado) que puede verse en la información de ABL2UML.
Para la base de repositorio, si se utiliza la estructura original provista, es necesario cambiar el tipo de FIXCHAR a CHARACTER para algunos campos en
algunas tablas. Dado que el asunto de la base de repositorio UML ya está detallado en el proyecto ABL2UML no se profundizará aquí.
La base xrefsrc tiene dos tablas:
- xrfdat
- xrfprg
xrfdat contiene el detalle de las relaciones entre componentes de código, es decir las inclusiones, invocaciones y acceso a datos. xrfprg contiene información que permite saber cuándo un componente (.p) es considerado una unidad funcional en sí mismo (el componente "inicial" de la unidad funcional correspondiente) o parte de una unidad funcional, y dos descripciones del componente que se utilizarán para generar las notas y los alias.
Adicionalmente a las anteriores, en nuestro caso utilizamos una tercer base de datos con la información de la estructura de menú (mapsissrc), se provee la estructura de tabla utilizada, para poder ejecutar el código provisto.
También se adjunta la definición sql modificada para el repositorio y el sql de creación de las secuencias necesarias (también en el repositorio).
En los archivos adjuntos se encuentran los datos correspondientes a las tablas de la base de datos xrefsrc, los xml generados a partir de estos datos y la exportación a EAP de cada etapa de la generación.