The OpenEdge Hive

English version

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.