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.
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.
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.