ABL2UML - Modeling Existing ABL Systems with UML
Overview
Given the need to enhance or transform a large existing ABL application, one is often hampered in the task by limited or out of date documentation. This project seeks to create a tool set that will read existing ABL code and the corresponding database to build a UML model of the application. This model can then be used for analysis and potentially can serve as the basis for future changes.
This project will consist of three stages:
1. Defining a UML "Profile" for ABL so that there are appropriate UML stereotypes to express the structural realities and relationships of ABL code and the corresponding dictionary.
2. Creating a tool for loading Progress dictionary information into a UML modeling tool using these stereotypes.
3. Creating a tool which will read and analyze ABL code and then load this information into a UML modeling tool using the stereotypes of the Profile.
This work is now in production and is described in the presentation attached below which will be given at the 2008 Progress Exchange conference.
The model created will be a Platform-Specific Model (PSM) in UML terms, i.e., one that is very closely tied to the specifics of the implementation and language. Once this has been accomplished, we will move on to five additional stages:
4. Creating tools to generate ABL code from the PSM so that the model can be changed and revised code generated without having to modify the source by hand.
5. Creating tools to create Platform-Independent Models (PIM) and Computation Independent Models (CIM) from the PSM so that the model can be analyzed and worked on at greater levels of abstraction.
6. Creating tools for transforming various aspects of the models to modernize the structure.
7. Creating tools for generating new PSM models with a revised architecture from the transformed CIMs and PIMs.
8. Generating code with modernized architecture from the transformed models.
These latter stages will evolve over a period of time providing immediate benefit for analysis.
Contact Thomas Mercer-Hursh at thomas@cintegrity.com for information on the current status of this project or for interest in participating in the development.
The PDF of my talk at Exchange 2008 on this topic is below. For the audio, please see here
Make sure that you join the UML group so that you can be notified of new postings and updates since there will be a lot of new stuff coming here soon
For services related to this material, see my website.
Stage 1: UML Profile for ABL
This stage is directed at defining a UML Profile for ABL Code and Progress dictionary information. The goal is to arrive at an open standard since there will be far greater potential synergy if all people working on UML modeling are using a common vocabulary. This stage will occur in three phases:
1. Defining the UML Profile itself, i.e., establishing stereotypes for ABL constructs and a mapping between the stereotypes, constraints, and rules of "well-formedness" to the underlying UML components and elements. This phase will be completed in a series of sub-phases which are documented in the working document.
2. Creating an XML file containing the stereotypes in the Profile so that these can be easily loaded into a UML modeling tool.
3. Defining the XMI specifications which implement the Profile, which will thus provide a target format for any tools which are intended to extract information from ABL code and dictionaries for loading into a UML model.
Our initial target UML tool for this work will be Enterprise Architect from Sparx Systems. We will be considering the option of using the automation facilities in EA as an alternative to XMI if it will allow faster creation of the tool, although we perceive XMI to be a more general solution usable with all UML modeling tools of sufficient sophistication.
Please leave comments here as appropriate. Contact Thomas Mercer-Hursh of Computing Integrity, Inc. at thomas@cintegrity.com for information on the current progress of this work.
Phase 1: Defining the UML Profile for ABL
A UML profile is intended to provide a mapping from a particular domain language or the language of a particular methodology onto underlying UML constructs. This mapping is a combination of “stereotypes”, which are terms from the domain or methodology equated to a particular UML constructs, as well as additional constraints, rules of “well-formedness”, and identification of which particular elements will be used to model the elements associated with the domain or methodology. A typical example is the relationship between the stereotype «table» in a relational database and the UML Class. This is not to say that a table *is* a class, but that Class makes the best base for modeling the characteristics of a table. The columns of a table become attributes in the class; validation rules on the columns become constraints; and triggers become operations.
One doesn’t normally define a UML Profile for a programming language. Ideally, UML models are initially created as Computationally Independent Models (CIM) which are completely separated, not only from the programming language of the implementation, but also from any specifics of the architecture. These CIMs are then evolved manually or through Model-Driven Architecture (MDA) to create Platform-Independent Models (PIMs) and eventually Platform-Specific Models (PSMs) and it is only at the later stages of this process that the model is translated into the form of any one specific programming language. Since the target language from most UML modeling is typically an OO language like C++, C#, or Java, there tends to be a fairly straightforward correspondence between the model and the corresponding language expression.
However, the motivation behind the current work is the desire to import existing Progress Advanced Business Logic (ABL) code into UML for the purpose of analysis and transformation and possibly eventually for generation of a revised system. This task presents certain challenges because the typical legacy ABL system is not written using OO constructs and UML is inherently OO in orientation. Therefore, it has been decided that it is appropriate to define a UML Profile in order to map the constructs found in ABL onto underlying UML elements. This will provide us with ABL appropriate vocabulary on top of the UML tools. As a part of the analysis and transformation process we might later abstract the model away from these ABL-specific stereotypes, but the initial model constructed will be based on terminology which will clearly and unambiguously connect back to the underlying ABL code.
To provide this clarity and connection, we will define more stereotypes than might seem to be absolutely necessary and it is possible that later revisions will simplify this vocabulary, but it is felt at this time that the clarity and connection provided by a richer vocabulary in which each term has its own ABL-appropriate characteristics will provide a superior basis for analysis than would a more minimal set. Since this profile is very language specific, we will prefix each stereotype with “OE” for OpenEdge to make it clear that the characteristics of that stereotype are specific to the Progress database and ABL language. E.g., «OETable» will clearly relate to the specifics of a table in a Progress database and may or may not relate to any other stereotype of «Table» which applies to any other database or which might be database independent.
This initial profile will describe the vocabulary and the mapping onto the target UML. Specification of the details of an XML Metadata Interchange (XMI) implementation of this profile will be deferred to a subsequent document.
This profile will consist of four sections. The first of these sections will relate to the Progress database. The intent in this section will be to provide a complete specification such that sufficient information can be extracted from an existing Progress database to analyze and modify the model and then export a Progress .df such that a database conforming to the modify model can be constructed. The second section will deal with the ABL code. The third section will deal with connections between that code and the database. The fourth section will deal with the visual aspects of the user interface.
Download the complete document to continue reading.
26 June 2007 A revised profile is provided with some additional stereotypes to handle functional and structural groupings in the code. The TC version has change bars and color to show differences from the prior version.
Phase 2: Stereotypes for Enterprise Architect
To load the Profile into Enterprise Architect, start by loading the datatypes for OpenEdge found here.
To install each set of desired stereotypes, open a project in EA, select Tools from the menu, select Import Reference Data, browse for the downloaded file, select, highlight the dataset for "Stereotypes for OpenEdge Database" or other label as appropriate, and press button to complete. To avoid having to do this for every project, do the addition in EABase or other suitable base project from which new projects will be derived.
If desired, one can delete all entries in the t_stereotypes table prior to loading these stereotypes and then the list of stereotypes will contain only those appropriate to OpenEdge.
In addition to sets for Data, Code, and Links, a set is provided with all non-OpenEdge stereotypes in case the user wishes to add back something from the standard set. These can be simply copied from that file to another file using the same structure in order to be loaded in the same way.
These stereotypes are provided with shape scripts for use in Enterprise Architect in order to give them intuitive relationships without the need for labels. The use of color, line type, and weight are summarized in the attached PDF. More work is needed to make these ideal, but the scripts should provide a good starting point for anyone wishing to develop their own patterns.
Stage 2. ABL2UML Initial Release
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.