Okapi MDA

Contents

1. Reverse Engineering
1.1. OpenEdge
1.1.4. Database Definition
1.1.4.1. Database
1.1.4.2. Table
1.1.4.3. Sequence
1.1.4.4. Foreign-Key
2. OpenEdge Profile
2.1. Database Definition
2.1.1. Database
2.1.2. Table
2.2. ABL
2.2.1. Classes
2.2.2. Properties
2.2.3. Operations
2.2.4. Associations
2.2.5. Data Structures
2.2.5.1. Temp Table
2.2.5.2. Dataset
2.3. Data Type
Okapi Reverse Engineering

1. Okapi Reverse Engineering

Reverse Engineering module of Okapi aims in helping mainly with extracting the application model from the source code for cases where the application lacks technical documentation, especially in the area of application modernization and transformation.

Please note that Okapi ABL code parser use an 'incomplete' grammar by only considering elements that represent the application API - mainly external procedures, internal entries for procedural code and classes and interfaces for object oriented code; data structures like temp-table and dataset definitions are also extracted. The Okapi code parser does not guarantee that the syntax is correct, if needed the application source code that does not compile can be taken out from the analyze code base otherwise it will be loaded into the model as well.

Because of the incomplete syntax approach there might be cases where the parser does not 'understand' a perfectly valid syntax leading to having missing information into the model, if you find such an unsupported syntax please let us know and we will try to adjust the parser accordingly.

Starting with the second public release the Reverse Engineering module of Okapi support also loading database definition files into the model, either using standard UML or optionally the Domain Specific Language (UML profile) defined for OpenEdge.

Object Oriented ABL

1.1.1. Object Oriented ABL

Because of the inherent object oriented nature of the UML itself the ABL OO code constructs are much easily mapped to UML correspondents, as such almost all ABL OO elements are being reverse-engineered:

  1. ABL Class
  2. ABL Interface

The following reverse engineering rules and conventions applies:

Procedural ABL

1.1.2. Procedural ABL

For procedural ABL code all syntax constructs are forcibly mapped to UML classes where all internal entries translates to UML operations.

  1. External Procedure
  2. Structured Procedure

The following reverse engineering rules and conventions applies:

Data Structures

1.1.3. Data Structures

Data structures elements supported by Open Edge ABL like temp-tables and datasets are being represented as classes in the UML model.

TEMP-TABLE

DATASET

Database Definition

1.1.4. Database Definition

OpenEdge database definition is fully supported by Okapi Reverse Engineering module, however the level of information detail loaded into the UML model is different depending on whether or not the OpenEdge profile is available to be used.

Database

1.1.4.1. Database

Database Table

1.1.4.2. Database Table

Database Sequence

1.1.4.3. Database Sequence

Foreign-Key Relations

1.1.4.4. Foreign-Key Relations

Because the OpenEdge RDBMS does not support foreign-key relations the reverse engineering module will try to infer those kind of relations between database tables using a very simple and somehow restrictive mechanism:

ABL Project Import Wizard

1.2. ABL Project Import Wizard

Reverse engineering with Okapi is implemented using a standard "Import" wizard that analyze and load in an UML model a full Open Edge project or simply a folder from the file system that contains all the source code to be analyzed.

The reverse engineering import wizard can be run against procedural or object oriented code, the only things that need to be taken care is to have the source code correctly arranged relative to the application source code root folder. If the application does not use relative paths when making references to objects in code but instead use multiple entries in the PROPATH then the application source code might need to be 'merged' in a single folder in order to have the references correctly created - for an Open Edge project that have the PROPATH property correctly set this is not necessary.

The Import Wizard can be started either by selecting the 'Import' entry from the 'File' menu or through the 'Import' contextual menu on projects in the Project Explorer panel (mouse right-click).

Import Wizard

Select "Import ABL Project to UML Model" wizard from Okapi Reverse Engineering category and click "Next".

Import ABL Project to UML Model

Select the project and specify the name of the UML model file, if needed adjust the import options to better suit your needs and click "Finish" to start the reverse engineering process.

The list of source code folders that are being analyzed and imported into the UML model is given by the project's ".propath" file for an Open Edge project; for non Open Edge projects the "src" folder is selected - proved it exist in the project structure - if not the project "root" is used.

Okapi Reverse Engineering Preferences

1.3. Okapi Reverse Engineering Preferences

For convenience this preferences page allows one to define the default values to be used when starting the import wizard. To access the preference page select Window->Preferences from the menu and move the left tab selection to the Okapi->Reverse Engineering entry.

Okapi OpenEdge Profile

2. Okapi OpenEdge Profile

OpenEdge Profile for Okapi is a extension of UML language in a form of Domain Specific Language (DSL) implemented as an UML profile.

The generic nature of UML specifications make it more appropriate for high-level models - Platform Independent Model, for specific implementation the UML specifications can be extended by using the UML stereotypes which allows for more low-level details to be added into the model - Platform Specific Model.

The OpenEdge Profile defined in Okapi covers two major areas, the database definition and the ABL language itself.

Having full database definition extensions open the road for using the UML model as graphical representation of the OpenEdge database much the same way as regular Entity Relationship Diagram (ERD) tools does.

For ABL language itself most of the extensions added were for "procedural" programming paradigm, the UML specifications being oriented more toward Object Oriented programming.

Database Definition

2.1. Database Definition

OpenEdge database definition is fully supported by Okapi OpenEdge Profile, however support for database structure was not added at this time.

The Reverse Engineering module of Okapi supports loading database definition into the UML model by parsing regular OpenEdge database definition files (.df).

Database

2.1.1. Database

Database Stereotypes

A database entity is represented in the UML model as a class having applied the database stereotype.

All database areas need to be defined as properties of the database class, this is not mandatory but the reverse engineering process loads all areas used by database tables and indexes.

All database tables and sequences need to be defined as inner classes of the database class, each having applied the db-table respectively db-sequence stereotypes. Each stereotype have properties mapped to the object's properties in database definition and are made available as extended UML properties of objects having applied that specific stereotype - also called tag-values.

Table

2.1.2. Table

Table Stereotypes

A database table entity is represented in the UML model as a inner-class of a database class having applied the db-table stereotype.

All table's properties specific to OpenEdge profile are available as tag-values, the table description is mapped to the class comment.

All table fields need to be defined as properties of the table class and have applied the db-field stereotype.

All table indexes need to be defined as operations of the table class and have applied the db-index stereotype.

OpenEdge ABL

2.2. OpenEdge ABL

For ABL language itself most of the extensions added were for "procedural" programming paradigm, the UML specifications being oriented more toward Object Oriented programming.

Stereotypes were also defined for more complex data structure objects available in OpenEdge ABL: temporary tables and datasets.

Class Stereotypes

2.2.1. Class Stereotypes

Stereotypes applicable to UML classes were only needed for procedural programming paradigm, for OO ABL entities can either be represented as UML class or interface.

Class Stereotypes Property Stereotypes

2.2.2. Property Stereotypes

Stereotypes applicable to UML properties were added mainly to differentiate between a ABL property and a variable but also some language specific properties were defined - although added for completeness, we highly recommend against using the 'display related' options for variables.

Property Stereotypes Operation Stereotypes

2.2.3. Operation Stereotypes

Stereotypes applicable to UML operations were required to support internal entries used by procedural programming paradigm (procedure, function and main-block) and to differentiate constructor and destructor methods in OO ABL.

Operation Stereotypes Association Stereotypes

2.2.4. Association Stereotypes

Stereotypes applicable to UML associations were only added to give a more 'visible' meaning for associations/dependencies between objects - depending on the type of object on the other end the association is necessarily a include if the object is a include file or an use if it it a class or interface.

Operation Stereotypes Temporary Table

2.2.5.1. Temporary Table

Temporary Table

A temporary table or work table entity is represented in the UML model as a class having applied the temp-table respectively work-table stereotype.

All table's properties specific to OpenEdge profile are available as tag-values, the table description is mapped to the class comment.

All table fields need to be defined as properties of the table class and have applied the field stereotype.

All table indexes need to be defined as operations of the table class and have applied the index stereotype.

For tables defined using the 'like' option the profile defines specific stereotypes for generalization link: like, like-sequential. A table defined as another table should extend - have a generalization link - a base class which is either a database table or another temporary table, the generalization can have one of the two like stereotypes applied.

For table fields defined using the 'like' option the profile defines a Like tag-value for the field stereotype.

Dataset

2.2.5.2. Dataset

Dataset

A dataset entity is represented in the UML model as a class having applied the dataset stereotype.

All dataset's properties specific to OpenEdge profile are available as tag-values, the dataset description is mapped to the class comment.

All dataset's tables need to be defined as properties of the dataset class and have applied the buffer stereotype.

All dataset's data relations need to be defined as operations of the dataset class and have applied the data-relation stereotype.

Data Type

2.3. Data Type

All primitive data-types as well as the more complex data structures available in OpenEdge language and database definition were defined in the OpenEdge profile.

Data Types

For convenience a number of enumerations were also defined to be used for properties having only a limited set of valid values.

Enumerations