The OpenEdge Hive

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.