ABLaUML is an Thomas Mercer-Hursh (email@example.com) ABL2UML (http://www.oehive.org/ABL2UML) derivative work.
We use ABLaUML to model legacy procedural systems. In order to do that we take the original code and convert it to object oriented code, changing the monolitic generation model into a model of discret succesive generation tasks.
We added xml file generation based on database content. This xml files are then used to build the UML model. We fill the database with information taken from an XREF compilation, due to that we call the database 'xrefsrc'.
In our case we are generation three xml files:
- for .p and .i, their relations and db access
- for .p notes
- for .p aliases
The generation of the data model (database structure) is made with an xml file too. This xml file (or files) contains the database structure definition.
UML repository manipulation logic was segregated from the generation logic, using an interface, wich allows the use of the same processing logic to build a repository for a different tool (other than Enterprise Architect - in theory).
So, the logic gets split in three layers:
- xml generation
- xml processing for UML generation
- uml repository manipulation
The full generation process is also divided in three basic steps:
- Information gathering and xrefsrc db filling
- xml generation based on xrefsrc data and databases structure
- xml processing and uml repository generation
This last step (UML generation) is splitted in several discrete steps, each of wich is implemented by a worker class. Each worker class is responsable for a piece, as smaller as possible, of the generation process. We use the following worker classes:
- Packages and components creation, to represent .p and .i
- Relations between components and packages (.p, .i)
- Packages moving, to locate child packages inside their parent
- Notes for components and packages
- Alias for components and packages
- Package diagram creation
- Diagram relations hidding
- Full data model building
- Data model cleaning, by eliminating non referenced tables
- Data model filling
There are depencies between workers, but that is no problem for the execution of any of them in any order, it will just affect the resulting UML.
An advantage of the new model is the capability of doing incremental builds.
To execute the UML generation process, an UMLBuilder object is needed. It get passed a list of worker classes to instantiate, and the xml file that each worker has to process. The UMLBuilder class uses IXMLParser (XMLParser), IUtils (EAUtils) and a StMapper object. The UMLBuilder object, instantiates each worker class (in the specified order), assigns it to the IXMLParser and process the xml file, then the worker generates the UML using IUtils (EAUtils) object.
Worker classes are a hierarchy that has a number of entry points (IWorker interface) that gets invoked through the xml processing. Each worker class expects a specific xml structure and makes a particular UML repository manipulation. XMLParser reads an xml file (using SAX) and invokes the appropied associated worker method. EAUtils implements all the Enterprise Architect UML repository generation, and manipulation, logic (most of this codes is taken from ABL2UML).
To generate xml files, XMLWriter derived classes are used. XMLWriter is a generic xml writing class. Each xml file to be generated, requires a class to generate it. In our case these classes are:
UML generation uses fixed stereotypes for each model element, to be able to change the stereotypes of the UML model, an stereotype mapper is provided (StMapper). Care has to be taken when mapping stereotypes because they are used internally to identify model elements, this implies that if an internal stereotype is mapped to another internal stereotype, the ability to distinguish between this two elements is lost.
- so far we haven't found UML repository xref table use, and many times this table is the cause of a Repository to EAP transfer failure. Emptying this table usually solves the transfer problem, without negative effects on the model (we have seen no change in the model, whether this table has data or not).
- Enterprise Architect versions 7.5 and 8.0 have problems with connectors notes. They usually gets lost when transfering an EAP to a Repository (Repository to EAP has no problems with notes), this is not a constant problem.