The OpenEdge Hive

The attached code represents the initial release of the ABL2UML open source tool set. This is an evolving project, so expect this code to evolve and expand over time.

The core code in this toolset is designed to be installed in the com/cintegrity/ABLtoUML directory with the error handling utilities in com/cintegrity/lib.

All code in this release is compatible with any Progress release starting with 10.1A. The only obvious dependence on 10.1A features is the error handling class, which would not be difficult to replace, if there is market demand. All other code is not class-based, but has been written as super-procedures in order to make it easy to understand and modify by those without an OO background.

This code relies on an XML "Bill of Materials" file which is output by Joanju's Analyst product. Contact me at thomas@cintegrity.com for pricing and options on this commercial product.

The main ABLtoUML directory contains a startup.p which is the program which is run to build the model. This must be run in a session with the Dictionary database for the application connected with -ld DictSource and the EA Repository database connected with -ld Repository. This is a OpenEdge repository setup as described here. The dictionary should be connected first, i.e., should be DICTDB.

The code in the dict subdirectory is run to import the schema information into the data model. It is possible this may need some minor adjustment for versions prior to 10.1A. The current implementation is quite complete relative to the Profile except for handling dataservers, which will be added when there is market demand.

The code in the code subdirectory is then run to build the code structures in the Component model and the links within the code structures and to the data structures. The bulk of this is built around two passes with a SAX reader reading the Bill of Materials file.

All manipulation of the repository occurs via a superprocedure in the util directory. It is the portion of this code least likely to be readily understood by a casual reader since it is manipulating the undocumented schema of the EA repository.

The site subdirectory is provided for site-specific customizations. The intent is that this is the only code which should require modification on a site by site basis. A minimum skeleton is provided in the core package and there are sample implementations for two code sets also provided in the attachments. This code covers a number of common issues including:

* Many legacy ABL applications contain a large number of tables and it is often possible to group these in some way into packages to make them easier to navigate in the model.

* Code also can often be assigned to a package on some basis.

* Essentially all such legacy applications will have some kind of menu structure, but the implementation of this varies widely, so a structure is provided here to take input from whatever form and build the standard structures used to build the model.

* Many systems have some system for providing some descriptive information about programs, whether from an external system or directly from the source code, so a structure is provided here for reading whatever form is available and providing a standard interface for attaching this information to code structures.

All of this code uses an instance of my Simple Exception Stack class, which is provided here in a 10.1A implementation that does not use the static features in 10.1C. This class builds a stack of trace and error messages which is periodically output to a disk file called ABLtoUMLLog.txt. The disk file is only updated at key transitions in the processing.

The attachments include two sample "site specific" implementations. One is for the Kal Tire KINS system and the other for ProLint. Both are provided with their own startup routine so if the three are installed, for example, as three projects under OEA, then one can run the startup routine in the project containing the custom code and that in turn runs the standard startup routine, thus allowing all custom work to be in its own project. Further details on PROPATHs and such will be documented as work continues, although this should be fairly apparent to anyone familiar with OEA. There is also a set of data files provided to correspond to the inputs for ProLint, including the bom.xml which came from Analyst. This corresponds to release 72 of ProLint.