En ba rev modeling

From The Real BLU AGE® Wiki

Jump to: navigation, search

ACCES www.bluage.com

Netfective s.png

Contents

Company presentation

Netfective Technology SA was created in May of 2000 and has specialized from the start in the production and maintenance of business applications for JEE and/or .Net. In 2004, with the help of OSEO (http://www.oseo.fr ), it created an R&D structure for the putting together of the BLU AGE® software (http://www.bluage.com BLU AGE®)

Bluage s.png


This software respects the principles of MDA (Model Driven Architecture) as defined by the OMG (Object Management Group http://www.omg.org) and is available through Eclipse. It allows one to automatically transform functional needs into web applications (light client/rich client) without having to rely on the usual development phases. With this approach, production delays are cut back by 30 to 50 percent depending on the function complexity. The functional elements that allow one to specify the detailed needs of the applications are produced using XHTML screen mockups, which are complemented by the addition of UML2 diagrams (class diagrams for the entities, activity diagrams for management rules and the succession of screens, use-case diagrams for security policies).


Since 2009, additional functions have been added to the production of applications (called Forward Engineering) . These functions automatically extract the screen mockups and UML2 diagrams (including batch programs) that are needed for the production (Reverse Modeling) from pre-existing applications (written in COBOL, PACBASE, NATSTAR, JAVA, PL/SQL…). These software engineering capabilities have been further equipped with BLU AGE® tools allowing for the upgrading of databases and the transfer of data.
These technological innovations - drawn from iterative project methods - have allowed Netfective Technology and its partners to provide a holistic approach to the updgrading of older legacy applications to JEE or .Net – all this with 30 to 40 percent cuts in the overall budget compared to more traditional methods, like transmodeling or re-writing from specifications.

In 2010, Netfective Technology numbers 130 engineers, 35 of which work in R&D, in France (Paris, Bordeaux), Marocco (Casablanca), and the United States (Dallas), with a total annual turnover of 9 million Euros. Aside from the selling of BLU AGE® licenses and of technological expertise (including training sessions), the teams at Netfective Technology produce business applications (modernization or creation) base on a flat-rate and provides software maintenance services for applications build with BLU AGE®.
Netfective Technology's main customers are located in France and the United States, and they mostly represent the retailing, social organization, service, and administration sectors.


Quick Presentation of BLU AGE® Software

As far as application production is concerned, the main goal of BLU AGE® software is to allow its users to no longer be limited by the detailed knowledge of the different computer languages and technical architectures on which upgraded or modernized applications will be run. This task, which consists in translating/transforming functional needs into an application (a set of programs assembled and packaged according to standard industry techniques), is entrusted to BLU AGE® which acts as a development automaton. Using MDA language, the mock-ups and UML2 diagrams that describe these functional needs make up a PIM (Platform Independent Model according to the MDA).
This PIM is then transformed by BLU AGE® into a PSM (Platform Specific Model), all the while respecting the technical specifications of the target framework. The characteristic elements of the targeted Framework are described in a PDM (Platform Description Model) using production methods (BSP for BLU AGE® Shared Plugins). In order for the resulting application to eventually be deployed, this PSM is finally transformed into packaged code (EAR, WAR, etc…) according to the norms that are wished for during the production.

BLU AGE® is thus capable of generating programs that conform with the JEE or .Net Framework, using a simple mechanism of production methods organized to architecture layer. The codes produced by BLU AGE® are independent of the tool used to produce them, and if need be, they can be maintained using any JEE Eclipse or .Net IDE on the market.

Likewise, extracting UML2 diagrams and/or screen mockups from application source code is automatized using a knowledge base that is specific to each of the languages (automatic recognition and annotation of patterns). Netfective supplies and commercializes a certain number of production and extraction (cf. the figure) methods, each of which can freely be enriched or amended by users according to their project needs. It becomes a matter of allowing engineers who are familiar with object-oriented environments to modernize and upgrade their legacy code (for example: Cobol programs written manually and/or generated with Pacbase), without it being necessary for them to master the technological and functional world of their old code. According to the MDA, the process of Reverse Modeling proceeds as follows: Code to PSM and then from PSM to PIM. The PDM of the source platform is replaced by that of the targeted platform during the Forward Engineering phase. From a practical point-of-view, the PIM is also frequently amended to keep up with the new norms and constraints placed by the JEE or .Net environments.
The use of BLU AGE® essentially requires knowledge of the different types of UML2 diagrams being used. BLU AGE® does not integrate the UML 2 modeller butit does interface with those modelers, all the while respecting the XMI2.0 exchange norm set by the OMG. The IBM Rational Software tools and that of NoMagic Magic Draw have been certified. The tools offered by SPARX (Enterprise Architect), Softeam (Modelio), and SAP (PowerBuilder) are in the process of being certified.

Main tool functions

(demos are available on http://www.bluage.com, http://www.model2code.com et http://www.agile4r.com)

The goal of the project

In the context of its R&D modernization program, Netfective Technology has been targeting the modernization of Cobol in particular, in order to facilitate the transferring of legacy code towards object oriented technologies of the JEE or .Net type.

At stake was the ability to quickly modernize old code through the use of resources that do not make use of any specific knowledge of prior development techniques.

The objective is to reduce, in a substantial and durable way, the possession costs (TCO), by following the evolution curve - both of technologies and of computerized resources (human and material).

Because the source elements are made up of source code (or their generating parameters, if they are generated) as well as of functional use cases and test data, there is a reduction in the dependence on document-based or human (i.e. "knowledgeable") sources, which allows for off-site work on shared platforms by way of continuous integration techniques.

When the modernization work is completed, the application has been entirely re-written in a modern architecture using specifications that have been extracted automatically from the source code. It can be made to integrate - if need be - any new modifications or functional evolution, just like any other application that one maintains. As a result, the totality of the functions in these modernized applications (screens, management rules, data) are entirely rewritten and documented in a lasting and non-technical format (UML2 models). They can thereby be maintained by teams with standard technical competence, since the complexity of implementing and maintaining Frameworks is masked by the mechanisms for generating.

Pacbase applications – which are produced in a similar way – lend themselves particularly well to this type of treatment. The fact that the Cobol codes were generated from Pacbase tools really simplifies the detection of patterns and their automatic translation into UML2. In general, the closer the application's code is to the standard, the higher the automatization level will be (up to 80%) and the more the production costs will decrease.

To complement its automatic treatment, Netfective Technology – capitalizing on a number of customized projects – has put together an original project methodology that allows its consultants (or those of its partners/clients) to estimate the production time with precision, based on an analysis of the number of artifacts that need to be handled (batches, TP, tables and reports), organized according to level of complexity (number of lines of Cobol code generated). A detailed analysis of the source application is completed by an appropriate questionnaire to which several Batch and/or TP are systematically associated, to be used for calibration purposes. This sample test phase, limited to 3 weeks, allows for the validation – thanks, notably, to real data – of the percentage of automatization of processes, according to the representative elements of the application that is to be modernized.

The first iteration will consist, among other steps, in modernizing the database and the data (i.e. renormalizing of the database, reinforcing of referential integrity, adding/creating of relations between entities, changing the database motor and the generation of scripts for the transferring o f data). This aspect is essential to the success of modernization projects, in as much as the method of checking the quality of BLU AGE® consists in flawlessly reproducing a representative sample of the functional tests of the source application on the generated application, based on models extracted via BLU AGE®. The systematic use of continuous integration mechanisms as well as the automatization of tests (i.e. Hudson & Selenium) contribute to a smoothing out of the processes and to a net increase of process efficiency, by automatically and systematically checking the pertinence of results that are obtained as the functional iterations go along.

At http://www.netfective.com you will find forms which, once they have been filled, will allow Netfective Technology's experts to estimate, within a week, the costs of producing a modernization into J2EE or .Net of a PacBase application.


Once it has been modernized, the application generated via BLU AGE® can (unlike PacBase) be maintained using standard methods and tools. Every artifact produced by the modernized application is in conformity with naming norms and specified coding norms and does not feature additional BLU AGE® "runtime". This feature, unique to BLU AGE®, allows one to reap all the benefits of automatic generation without worrying about the technology eventually disappearing or about having to purchase BLU AGE® licenses. By the same principle, the modernized applications can, without any difficulty, be enhanced by all the technological innovations of the object-based world of J2EE and .NET, and, moreover, offer the possibility of moving away from IBM mainframe environments (i.e. IBM Rational's solution to the continuity of PacBase does not extend to other non-IBM environments) by easily transitioning to concurrent solutions in the worlds of JAVA and .Net. The most substantial advantage of modernizing into J2EE and .Net architectures is without a doubt the capacity to integrate (into the maintenance team) a work force that comes directly from engineering schools as well as the capacity to allow a work force anchored in PacBase to evolve towards technologies of the future.

The technical material components and software that belong to the JEE and .Net world, as proposed by IBM, ORACLE, HP, or MICROSOFT make the use of modernized applications perfectly secure and reliable. Because BLU AGE® has taken an interest in the professional and career knowledge that has been accumulating, oftentimes for decades, in these types of complex applications, it has been able to produce the means to value and preserve the expertise of an industry, and by its efficiency, has created the economic conditions needed for the relocalizing of the maintenance resources for these complex information systems.


Useful Links

http://www.netfective.com
http://www.bluage.com
http://www.model2code.com
http://www.agile4r.com

All brands named are the property of their respective owners. MDA, UML, and MDD are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.



Functional Description of the Offer

Introduction

BLU AGE Methodology (Reverse Elements for PACBASE in red)

The goal of the BLU AGE Reverse Modeling project is the production of a tool that, along with a methodology, allows one to reproduce a PACBASE application in the form of a BLU AGE model (a UML2 model and a parametrized mock-up). This methodology, called "Reverse then Forward", aims to produce an initial model that essentially contains a model of modernized entities and a parametrized mockup based on PACBASE inputs. Simultaneously, documentation is generated in order to help with the application that will be produced.

In a second phase, the modeling of service and presentation layers is done using a traditional process, that is, by manual modeling (in this document, it is done via MagicDraw from No Magic Inc) using available documentation either by the use of tools to produce UML diagrams (Transmodelling, pattern and macro automated transformation). The goal of this document is to describe the application that is used to make these operations.


How Functions Are Organized

Use Case – An Engineering Project

The functions are organized according to the different actions that are needed to, on the one hand, automatize the transformation of the PACBASE application into PIM BLU AGE models (UML2 models and screen mock-ups), and on the other hand to take these PIM as entries in a chain of generation and continuous integration so as to produce the equivalent modernized application and to proceed to these automatized tests.

These functions are used jointly during the different phases of a modernization process. These are explained throughout the document. The present document only provides details on the BLU AGE modernization for PACBASE and COBOL, that is to say the functions of the branches of "Analysis View", "Extractions and Transformation", "Enriching knowledge and automatization" and "Collaboration" [cf. the previous figure].

For the other functions, that is to say the "Choice of Entries", "Evolutions and Approvals", and "Continuous Integration" branches, the reader should refer to the user documentation for the BLU AGE Forward Engineering and its associated wiki.



Index of Functions

This chapter aims to give an overall view of the functions present in the reverse product. Links are systematically available in order to navigate more easily through the rest of the document.


Functions per Use Case

Functions through the BLU AGE Reverse Screens


Getting started

Installation

The installation of the BRM tool consists in decompressing or unzipping the archive into the desired directory. It is then a good idea to create a shortcut that points to [InstallDir]\eclipse\brm.exe.
Prerequisites: JDK 1.6 must also be installed.

MagicDraw 17 Integration

So that BLU AGE 3.6.2 is fully functional, MagicDraw 17 SP1 must be integrated into it.

For this purpose, once BLU AGE 3.6.2 has been installed, MagicDraw 17 SP1 must be integrated using the following procedure:

Vac integration md17 image4.png
Vac integration md17 image5.png
Vac integration md17 image6.png
Vac integration md17 image7.png


Launch

The reverse application launches via brm.exe or a shortcut to it. After the initial load, we are asked where we want to put our workspace.

Launch

In the case of the first launch, choose any space (the path cannot contain spaces). In the next launches, a reminder of the previously used workspaces will be available as a drop-down list.

Choice of Perspective

Choice of Perspective

Once the application is launched, click on Window > Open Perspective > Other....
Then choose the BLU AGE Legacy Modernization perspective.


PACBASE Project Initialization

The putting-together of reverse projects can be done by importing existing projects into the workspace (File > Import > General > Existing Projects into Workspace), or by using a wizard:

  1. Click on File > New > New REVERSE Project (flat files)
  2. Choose a project name (Initializing a project, Fig. 1)
  3. Select the entries (Fig. 2).
  4. Click on [Finish]. A project with required structure is created. The entries and workflows are copied to the appropriate places (Fig. 3).
PACBASE Project Initialization

Fig. 1.

Fig. 2.

Fig. 3.


COBOL Project Initialization

The creation of a COBOL reversal project is done through the following steps:

  1. Select File > New > Project > REVERSE Project > COBOL Reverse Project,
  2. Give a name to the project and optionnaly select a file repositoty (COBOL project initialization Fig. 1),
  3. Select an archive or repository where the inputs are stored (COBOL source code and Copybooks) for import. For both inputs the code will be copied whilst keeping its original tree structure. Any copied file will be renamed with the extension .cblmf (Fig. 2),
  4. As an option, the next page can be used to specify an extraction area from which the persisted entities will be generated (Fig. 3),
  5. The last page makes it possible to import a reference UML2 BLU AGE model. If it is not available at that time, the Blu Age profiles have to be imported in an EMF format in a similar way as with Blu Age Forward (Fig 3).
COBOL project initialization

Fig. 1.

Fig. 2.

Fig. 3.

Fig. 4.


Launching Workflows

Workflows perform transformations of the inputs (typically, a PACBASE flatfile) so as to generate a number of items: code, entities, mockups, documentation. They are detailed in the #Workflows section.
This part of the tooling is specific to PACBASE projects.

Launching all workflows of a given project in sequence is performed in the following way:

  1. Click on the Launch Workflows button (Fichier:vac065_b2_16.png) in the Eclipse button bar.
  2. Select the project, then click Next (launching workflows, see Fig. 1).
  3. The workflows to launch are displayed in the next wizard page. Excepted when asked otherwise, please ensure that all checkboxes are selected (Fig. 2).
  4. Click Finish to run, in sequence, the selected workflows.
Lancement des workflows

Fig. 1.

Fig. 2.

Fig. 3.


Launching a specific workflow

Lanching one workflow

To be able to control the BSPs executed by a workflow, or to examine it in details, it is required to launch it individually. Workflow files are stored in the workflows folder of PACBASE extraction projects.

The workflow is then launched in the following way:

  1. Right click on the workflow > Run As > BLU AGE Launch Generation.
  2. Excepted if asked otherwise, ensure that all checkboxes are selected.
  3. Click Finish.



Workflows

Ordering

Workflow Order

These workflows allow one to transform these models in order to yield a number of elements. To that end, they must succeed each other in a precise order.


P1_Extraction

The extraction workflow relies on the entries that are supplied during the creation of the reverse project to then produce a certain number of models that describe the entries:


P2_FilterAndRename

This workflow is based on extractions and it produces intermediate modifiable user documents.

P2_ LegacyMockup

This workflow generates mock-ups without renaming segments and rubrics.


P3_Interpretation

This workflow uses the preceding models and the Excel sheet that might be modified by the user (renaming, etc…) to create intermediate relabeled models.


P4_Dochtml

This workflow creates documentation using the preceding models.


P4_Representation

This workflow creates an entity diagram based on previous models.


P5_RepresentationBatch

This workflow generates two models that contain stereotyped classes that are meant to help restore a batch: one model in which all the classes bear the EBCDIC_ITEM stereotype, the other in which the stereotype is BatchQuery.




Collaborative Work

Use Case

A number of views and Wizards have been developed in order to allow for collaborative work: mutualizing of the "legacy" elements and the annotations that are made to them.

The annotations editor is documented in section #Default Editor. The consolidation and checkout wizards are deprecated in favor of direct sharing of reverse projects on SVN or CVS (see section #Alternatively : Converted Project).


Consolidation Wizard

This wizard allows for sharing and consolidation of the result of applying workflows (see chapter 4) to PACBASE entries. When this occurs, multiple tasks are performed:

The wizard can be found by right-clicking on an extraction project (to which the workflows must have been applied), and then clicking on VAP Reverse Modeling > Consolidate into repository. An eclipse preference page is used to indicate the CVS server connection information. To access it, go to Window > Preferences > BLUAGE MODEL REPOSITORY (Consolidation Wizard, Fig. 1).
One must then indicate the CVS connection URL, as well as the name of the sub-directory. Once the CVS server connection is made (it can take a few seconds to get started: you should see a "Loading…" message), the wizard welcome page appears (Fig. 2).
The next page in the wizard allows you to visualize the jobs/screens and the programs/batches that will be uploaded; you can also specify the name of the module under which these elements will be added to the CVS server (Fig. 3).
We can then follow the progress of the consolidation (the window closes once the process is over, Fig. 4).

Consolidation Wizard

Fig. 1.

Fig. 2.

Fig. 3.

Fig. 4.


Navigation View

Right click on the module

The navigation view allows one to consult the catalogue of modules that are already presents on the CVS. This view is available via Window > Show View… > BLM Views > Navigation View. Starting from that view, it is possible to launch the repatriation wizard by right-clicking on a module.


New Project Wizard (Repatriation)

This wizard allows for the creation, within a local workspace, of a "reverse" project based on a module that is available on the CVS. When the editor is started (cf. the preceding section), one must select the name of the "reverse" project that will be created locally.

New Project Wizard (Repatriation)

Project Creation.

Loading Screen.

One can then carry through with the creation of a local project (this can take some time given the communication with the CVS server) and then use the annotations editor and the different views in the context of this local project.

Alternatively : Converted Project

Since the 1.10.0RC4 version of the product, a project conversion is performed at the end of the workflows run. A 'reverse' nature project, identical to what is produced by the consolidation wizard, is created with the [PROJET]_CONVERTED name. If a similarly named project already exists,it will be created under the [PROJET]_CONVERTED(x) name.
This project conversion deprecates the previous wizards and views. Moreover, it makes the projects produced by the workflows locally usable by the tool without extra steps, while still enabling their sharing through the desired version control tool (CVS, SVN or other).

Synchronization Wizard

Synchronization Wizard Screen.

This wizard allows for the sharing and consolidation of code annotations, as well as for macro comments. You can find this wizard by right-clicking on a reverse project (a result of a repatriation process, see the #Consolidation Wizard section), then by going to VAP Reverse Modeling > Upload into repository.

If the CVS server connection information was not been updated (say in the case of a new workspace), a popup will appear when you open the wizard (see the #Consolidation Wizard section).
Once the CVS server connection has been established (it can take a few seconds to start, you will see the "Loading" message), the wizard welcome page will appear.
Once the "Finish" button has been clicked, the annotations and comments that were locally selected will be synchronized with the CVS server and made available to the other users of the product.


Mockup Recovering

Legacy inputs may contain UI descriptions. In this situation, tools are available to convert those to HTML mockups compatible with the BLU AGE tooling (GMarker, Forward generator).

As seem in section #P4_MockupGeneration, HTML mockups are generated from PACBASE screens descriptions durings extraction (workflows run).

COBOL TANDEM (S/COBOL SCREEN SECTION) and COBOL IDEAL (panel files, which must bear the .ideal extension) screens descriptions can be converted to an HTML mockup by right clicking on the project and selecting “Generate Mockup” in the contextual menu. Created HTML pages will be stored in the “mockup” folder of the current project.


Recovering Patterns (motifs)

Studying legacy code may reveal the existence of patterns or motifs. These patterns are portions of code that repeat themselves, to within a few parameters. They can be recovered in the form of UML2 BLU AGE models, the latter being parametrized by values taken from the pattern that has been identified (a segment name, for example).


Interface

A Contextual Menu

The set of detection and pattern recovery functions is available from a contextual menu on the "reverse" projects.


Definition of a Pattern

The pattern creation wizard allows one to define a pattern script that recognizes a repetitive portion of code and associated it with a parametrized UML2 template.
CThis wizard is available through the Pattern Matching > Define Pattern menu, or by right-clicking within the annotations editor over a block of highlighted code.

After having selected a block of code, one calls up the wizard. The first page allows one to define the pattern identifier (which must be unique), and a comment describing its function. The Browse button allows one to select a template (a parametrized UML2 model) to be associated with this pattern. The profiles of this template (obtained during its exporting from MagicDraw) must be present in the same directory. You also have the option to define the marker type for the bits of code that correspond to the pattern.
The following wizard page allows one to indicate the variable portions of the pattern via a token mechanism.

Clicking "Finish" creates a pattern (locally) and associates it (eventually) with its template. When it closes, the wizard analyzes the ECBL (Extended CBL) and compiles it in PSL (Pattern Specification Language). The PSL is the language that BLM uses to specify the patterns on the models.

Pattern

Definition of the Pattern Identifier

Variable Portions of the pattern


UML2 Templates

Piece of the Model Parametrized with MagicDraw

The piece of the model corresponding to the pattern – if the defined pattern is looking to generate a subset of the model – must be isolated within a minimalist model. This model, which only contains elements that are necessary for its coherence, in addition to elements that will be generated, is to be parametrized in such a way as to determine the variable positions within the model. This is done by way of tokens (<%parameter%>).

A few stereotypes are used to give a boost to UML2 templating system. For example, the <<pinList>> stereotype allows one to generate many pins using a single list of elements… Once the UML template has been parametrized with MagicDraw, it must be exported to BLU AGE.


Local Catalogue of Patterns

The local Catalogue of Patterns

The local catalogue of patterns is kept in a project directory within the patterns folder. For every pattern definition, a folder is created that holds the equivalence script. The template folder keeps the UML templates associated with defined patterns.

The ecbl files (or extended cbl files), allow one to specify a pattern of CBL code within a DSL that is very close to the CBL (called eCBL). The psl files are the matching scripts that are applied to the models in order to create the markers (PSL, Fig. 1).

A PSL rule defines a pattern. It is primarily composed of two parts. The "matching constraints" part and the "bindings" part that allow one to define the annotation parameters to be generated. The PSL scripts are automatically generated using the pattern specification written in eCBL. That being said, for complex patterns, manual editing of PSL becomes unavoidable. (CF #Advanced Functions).

To give an example, one can customize the content of the generated annotation corresponding to a given pattern by simply adding a message line inside the binding part of the PSL script (Fig. 2). The message text can reference other "binding" values.

One may also have to edit the PSL in the case where we must match the more complex patterns. The following example shows the PSL script to detect one more MOVE, followed by a PERFORM (Fig. 3). Notice the + modifier used in the declaration of the first constraint (Fig. 4).

PSL

Fig. 1.

Fig. 2.

Fig. 3.

Fig. 4.

Pattern Mutualizing

Once a pattern and its associated template have been defined, they can be made available to other users of the reverse product. To that end, we use the commit wizard (menu Pattern Matching > Commit Pattern) (Pattern, Fig. 1).

Only the patterns that are locally present and that are not yet shared are displayed. Select the patterns that should be shared, and then click on "Finish". There is then an option to consult the list of patterns (shared or not) via the Pattern Matching > Browse Patterns (Fig. 2).

It is also possible to consult the pattern comments by selecting them. Once they have been chosen, the patterns that need to be repatriated should be checked and then one can simply click on the "Checkout selected patterns" button.

Pattern

Fig. 1.

Fig. 2.


Pattern Recognition

The locally available patterns can be applied to source code so as to annotate all the occurrences of the recognized pattern. For that, we use the wizard that is available under Pattern Matching > Match Pattern (Pattern Recognition, Fig. 1).
Once the pattern that needs to be recognized has been selected, press "Finish" (Fig. 2).
The recognized patterns are then visible in the annotation editor (Fig. 3).

Fig. 1.

Fig. 2.

Fig. 3.

Pattern Modernization via a Template

Pattern Modernization via a Template

Once the patterns have been recognized and annotated, it is possible to generate associated UML2 models by using templates that are provided during the pattern definition. To that end, we use the wizard available in Pattern matching > Modernize Matches (Template Based).

Once the pattern that needs to be modified has been selected, click "Finish" to generate the UML2 models from the template and the annotations produced the during the recognition phase. The created models can be found in the generatedModels directory.

Fusion of Generated Models

Fusion of Generated Models

During the modernization phase, a UML2 model is created for each occurrence of a recognized pattern. In order to put together a single model that simplifies the import from MagicDraw, we can use the wizard found at Pattern Matching > Merge Modernized UML2 Models.

Once the models that need to be merged have been selected, click on "Finish" to obtain a unified model. It can be found in the reverse/finalPattern/finalPattern.uml.

Advanced Functions

For certain complex patterns, the resolution of the generating parameters is hard to express using PSL. In this case, it is possible to define Java binders and to call on them using the PSL script (Advanced Functions, Fig. 1).

The call to a JAVA method is done by using a JAVA keyword that replaces the equality operator in the binding part of the PSL script.
The JAVA methods that are called in bindings need to be defined within JAVA classes, to be kept in the patterns/javaMethods. These methods must respond to the public static String methode(EObject) signature.

The classes in the javaMethods folder are compiled using the matching script. The set of methods that are defined by the set of classes of the javaMethods folder is referenced in a local directory. One should not define two methods - responding to the given signature – with the same name, even within two different classes.
The java binding methods must return a chain of characters representing the binding value and which take, as their argument, an EObject that represents the corresponding instruction.

The classes in javaMethods are also required to contain an initialization method that responds to the public static void void init(IProject) signature.
The init emethod is called immediately after the compilation and allows to produce the initializations that the rest of the binding methods will be needing. (feeding a list, parsing an input, etc…. Fig. 2).

Advanced Functions

Fig. 1.

Fig. 2.


Transmodeling

Goal

The goal of the annotations-directed transmodeling mechanism is to allow a systematic recovery of pieces of legacy code as a set of "process" operations (see the chapter "Process services by activity diagram" in the documentation BLU AGE Forward Engineering reference guide).

Configuration

As a prerequisite, the transmodeling tool requires that the BLU AGE project which will host the generated diagrams is opened in BRM. For this purpose:

The opened project must have the following characteristics:

Important : the UML2_Reverse_Bluage_Profile.xml.zip profile (shipped for the first time with the 3.6.2 version of the BLU AGE product) is mandatory. It must be applied to any BLU AGE profile using BRM functionnalities.

Choosing the Code to Transmodel

Choosing a piece of code to transmodel is done using a legacy code editor (annotations editor, for example). A few mechanisms are thereby available:

In all cases, the generated operations will be grouped in a same interface.

Launching the Transmodeling

You can bring up transmodeling by right-clicking on the editor and then on the "Transcode to UML2" menu:

Invocation du Transmodelage

Transmodeling Wizard

At transmodeling launch, the following wizard is displayed:

Wizard de Transmodelage

Items to Process

The upper part of the wizard, "Items to Process", lists the "process" operations which will be generated from the selected legacy elements. Each line describes an operation which will be created (and its activity diagram). The following properties of the operations to generate can be edited through the columns of this table:


Input of Missing Mappings

When a block of code to transmodel references a legacy field for which no mapping was found in the currently opened MagicDraw model, this field is listed in the lower part of the wizard ("Missing Mappings" zone).

As an option, it is possible to use the "UML2 element" column of this table to add new mappings. Input is performed by picking an element in the currently opened model (see section #UML Picker Wizard). In this way, mappings can be incrementally enriched.

To store those new mappings in the model (by updating the "LegacyEntityMapping" tag of the associated entities) without lanching the transmodeling, click on the "Apply Mappings" button. Clicking on the "Finish" button implicitly perform the same operation and store the mappings.

If needed, those mappings can then be displayed and edited (see section #Mappings Visualization/Edition Wizard).

Notes:

UML Picker Wizard

Operations of the #Items to Process and #Input of Missing Mappings sections require the choice of UML types or elements. For this purpose they use an "UML Picker" in which items to use can be selected (in the BLU AGE profiles, and amongst already modeled UML elements:

UML Picker Wizard

Through this interface, an UML element of the currently opened model (see the "Configuration" section) can be chosen in a selection tree. An input field can be used to input a (case insensitive) filtering criteria so as to restrict the tree content.

In addition to this explicit criteria, the tree content is originally filtered with regard to the expected element (type or operation as an example).

To alleviate repetitive selections or modifications, the last selection position in the tree is retained between wizard invocations.


Result

Clicking on "Finish" in the wizard will launch the transmodeling. As a result, an interface is created in a transmodeled.target.service package created at the root of the currently opened model. This interface is named:

This interface contains:

Résultat du Transmodelage

Functions (and their diagrams) must then be moved to their final target interface in the project; if needed, their call must be modeled. The generated diagrams need no modification to generate a compilable application after application of the BLU AGE Forward workflow. Some checks and modifications will be needed for the generated code to generate in a way conform to the legacy behavior, though.

Instances

For each instance type used in the diagram, only one object node is modelized to bear the control flows to the getter and setter operations. The name of this object node is build from its type. Hence it may be needed to:

Assignments (MOVE)

In the legacy code, an assignment is typically a MOVE from a field A to a field B. Transmodeling of this instruction leads to 2 operations:

For each of those fields, the generated operation will depend on the availability of a mapping:

Vac move image53.png
Vac move image54.png

When assigning from a contant value, only the setter operation is modeled.

Assignemnts Transmodeling

Conditions (IF)

Each "IF" statement is transmodeled in the following way:

Conditions Transmodeling

Notes:

Here is a sample of code generated once comments are removed:
// Executing : ServicingProviderScreenParm-capProviderLevelMod = 'M'
// OR ServicingProviderScreenParm-capRatePackageIdMod = 'M' OR
// ServicingProviderScreenParm-withholdPercentageMod = 'M'
condition = capProviderLevelMod || capRatePackageIdMod || withholdPercentageMod;

Loops (WHILE, DO)

Each loop statement is transmodeled in the following way:

An an example:

WHILE(SP-NDX < WC-MAX-SP) {
ADD 1 SP-NDX
}
Loops Transmodeling

Function Calls (PERFORM)

Calling a (sub)function is transmodeled to an operation which can be of one of two types:

Vac perform image58.png
Vac perform image59.png

Mappings Visualization/Edition Wizard

Once mappings are created, they can be displayed, edited or deleted in a wizard available from legacy editors through Right Click > Show Mappings:

Mappings Wizard

As in the transmodeling wizard, the rightmost column can be used to edit the mapping (see section #Transmodeling Wizard). They also can be deleted here.


Reverse of Macros and Structure

Object

The goal of this feature is to assist in the modernisation of PACBASE macrostructures with parameters (MSP), to maximize the automation of legacy code modernization.

Prerequisite

Prerequisite

Relaunch the workflows with a version higher or equal to 1.10.0RC2. Then copy the resulting file, macro.msp in the associated reverse project.

MSP Editor

The first tab of the macro file includes MSP used in the program (Batch or Screen, left hand side section) (MSP Editor, Fig. 1). The right hand section allows the definition of the different instances of the MSP. Each instance is a call to the MSP. The concept of instance makes it possible to reverse a family of macro calls with a UML2 diagram, their use is described in section #Behavior. An instance has an associated UML2 template, a constraint, a marker type and a comment.


The second tab "code" makes it possible to see the generated code for the MSP in a given program. In this way for each Macro it is possible to see each line of generated code. (Fig. 2).

MSP Editor

Fig. 1.

Fig. 2.


Behavior

Instance creation

Instance creation

The modernisation of a given macro starts with the creation of an instance. To do this click on the button Add new instance in the right section.

Editing an MSP Instance

Once an instance is created, it has to be edited and parameterized. To do so select it in the instance list (Editing an MSP Instance, Fig. 1).

The instance name is carried by the comment linked to the instance. This same comment will be set on the annotation during the "matching" process. Once the comment is defined, link the instance to a marker type, previously defined in the Eclipse preferences (Window->Preferences->Marker types), (Fig. 2).

Editing an MSP Instance

Fig. 1.

Fig. 2.

Constraint definition

The constraint field of the MSP instance makes it possible to define a constraint on the MSP calls. The "constraint" field


Une MSP peut être appelée avec plusieurs paramètres différents, où chaque paramètre a un sens métier ou technique.

Exemple :

To do that a template has to be defined (see #UML2 Template Definition), then linked via the modernized instance to the following constraint :

//Marker[params[3]/@value='NOCODE' and params[4]/@value='STORE' and params[5]/@value='NOHOLD']

The constraint language used is Xpath.

Notes:

//Marker[ constraint ]

If an instance does not have a constraint, the constraint field must stay empty.

Evaluating a constraint

To facilitate the tuning of a constraint, a button enables its evaluation if it's possible. Click on evaluate makes it possible to check that the Xpath query is valid (Evaluating a constraint, Fig. 1).

If the constraint is evaluated without error, the button displays the number of lines identified by the constraint in the editor (Fig. 2).

If an error takes place during evaluation, the button displays Error (Fig. 3).

Evaluating a constraint

Fig. 1.

Fig. 2.

Fig. 3.

UML2 template definition

The definition of a UML2 template is done in the same way as with the pattern tool (cf. #Templates UML2). The association between a UML2 template and an instance is done through the template field. It contains the link towards the template relatively to that project Example : /template/macro/AGDBIO/monTemplate.uml.

Matching process

The matching process makes it possible to identify all the MSP calls that comply with the constraints defined in the instances that are modernised and to annotate automatically the lines generated by the MSP call.

To start the matching process, click on Launch Matching (action in the top right corner).
Matching launch

Launch Model generation

The diagram generation process has to be preceeded by the matching process, the generation and template application being based on the annotations generated during the matching process.

To launch the generationprocess, click on the action Launch UML2 Generation.
Launch model generation

The generated diagrams are placed in the repository /models/macro of the current project.

WCG - EBCDIC Projects Initialization Wizard

Goals

The wizard aims at helping in defining a reading and writing framework of an EBCDIC file for a given segment. For this purpose, it generates two "BLU AGE Forward WCG" projects with their associated UML MagicDraw model :

Prerequisites

Before the wizard can be used, some conditions must be met:

Shared Project

As shown above, its path must be « patterns/wcgJob/wcgTemplate.uml ».

Once those conditions are met, the wizard can be launched. In the contrary, an error message informs the user that the wizard cannot be used.

Execution

To launch the wizard, use File->New->Other (as shown below).

InitWCG EBCDIC image004.png

Then, select the "WCG EBCDIC Project" wizard:

InitWCG EBCDIC image006.png

Once the Wizard is launched, a first page is displayed:

InitWCG EBCDIC image010.png

Enter the name of the project to generate, then click "Next" to getr to the next page:

InitWCG EBCDIC image012.png

6 inputs are expected here:

Note : the wizard rely on the "entity" input (in the "Model location" UML model) for generation purpose. All other inputs must be coherent with this entity.

Generated Projects

Two BLU AGE "forward" projects are generated in the current workspace following the wizard execution. The « Reader » and « Writer » projects are populated in the following way:

InitWCG EBCDIC image016.png

Hence the « Reader » project contains:

The « Writer » project differs from the « Reader » in two ways:


Generated MagicDraw Wizards

The wizard creates two UML2 models in the current MagicDraw project. Those models are populated in the following way:

Created UML2 projects

Modèle Reader

Modèle Writer

Both projects are created at the root of the currently opened MagicDraw project. The project name, as provided on the first page of the wizard, can be found in the packages names (here, “projet”). Those MagicDraw elements are generated from the template contained in the shared project, expected the « entities » created from the UML model provided to the wizard.

PACBASE Reports Modernization

Functionality

PACBASE reports which may be available in inputs are modernized as Jasper reports. This step is performed during workflows execution (see #Launching Workflows), with no need for user interactions.

The following flatfile entries are interpreted:

The modernization mechanism builds a set of Jasper sheets (.jrxml extension) by merging and modernizing the static report and its fields. They can be found in a "reports" folder at the root of the reverse project (see #Alternatively : Converted Project). A "pacbasescriptlet.jar" scriptlet is also copied in this folder; it is required by the generated Jasper sheets.

Vac etats fonctionnalite image73.png

The reports folder will only be created if the processed PACBASE input contains reports.

Description of Generated Reports

Modernized reports are Jasper reports with the same structure and data alimentations as the PACBASE report. Static items are modernized as labels, dynamic fields as Fields.

Vac etats description image74.png

The PACBASE variables xxLC (number of lines, sum of the blocs sizes) and xxLCM (maximum number of lines) are properly update during report execution (they can be the target of tests or computations influencing the rendering of the report and of displayed elements).

Conditions which may be associated with PACBASE structures are modernized to the Jasper expressions language.

Items which could not be set (working elements, computations) are modernized as variables.


Breaks Representation

A Jasper group is created for each data structure break. The IBx ("beginning of break" indicator for the x break, PEx in the french PACBASE version) and FBx (end of x break, DEx in the french version of PACBASE) variables are simulated in the Jasper report using the included scriptlet and a generated request.

EBCDIC / Copybooks Tooling

In order to facilitate work with EBCDIC files, two components were added to the BRM tooling:

Copybook Size

The computed copybook size can be accessed from the « properties » of its file. As shown below, those are available through a right click on any « fileformat » file.

ToolsEBCDIC image002.png

Once those properties are displayed, the informaiton is available in the « Copybook » tab:

ToolsEBCDIC image004.png

EBCDIC Files Reduction

EBCDIC files can grow to huge sizes. It may hence be useful to extract from them a smaller sample. For this purpose, the « EBCDIC Splitting Wizard » can reduce an EBCDIC file to its « n » first segments. Those segments are written into a file created at the same location as the original EBCDIC file. To use this wizard, right click on the copybook describing the structure of the EBCDIC file to sample, then select « Split EBCDIC File » as shown below:

ToolsEBCDIC image006.png

The following wizard dialog is displayed:

ToolsEBCDIC image008.png

Four items are displayed on this dialog:

Once those fields are filled up, pressing "Finish" on the wizard will create the reduced file.

Eclipse Editors

Default Editor

Eclipse Editor

When you double click on source code with a .cbl extension (COBOL PACBASE) or a .cblmf (COBOL), the default editor is displayed.

The following functions are available:

Moreover, this editor can be used as a way to select views (#Eclipse Views) and as a basic component for the annotations editor (#Annotations Editor section section).


Annotations Editor

In order to facilitate the consulting and the annotations editing on legacy source code, a specific editor called “Annotations Editor” has been engineered. It is available by right-clicking (Open With > Annotation Editor) on a file with a known extension (Figure. 1).

The Annotations Editor (Figure 2) is made of two parts. The left side is the usual source code editor (with native functionalities such as navigation, syntactical coloring, etc.) and the right side which contains annotations (aka Markers) defined by the user.

Using Markers

The editor offers the following features (Figure 3):

The editor automatically saves any modification.

The marker types available in the "Add Annotation" contextual menu (Figure 4) are defined on the Markers preference page (Window > Preferences > Markers). See the next section for more details.

Annotations Editor

Fig. 1.

Fig. 2.

Fig. 3.

Fig. 4.

Using Categories

The user can create groups made of different marker types. These groups are called “Categories”. Each category will contains one or more markers types. The concept of « Categories » enables the users to filter the markers (annotations) of a given program file. Such filtering is useful mainly to only display targeted markers. In fact, the contextual menu enabled by a right click on the left side of the editor, lets the user select the category to display. Therefore, only marker types associated to this category will be visible on the editor (Figure below).

Select displayed categories

The customization of categories is possible thanks to the Markers preferences page. See the next section.

Managing Markers Preferences

Blu Age makes the customization of marker types and categories user-friendly via the Markers preferences page (Window > Preference > Markers). Three main features are available :

Marker Types Settings

Managing the markers types is possible via the « Marker Types » tab (see Figure below). Initially, this page is filled with default marker types. But it is possible to add new markers and to edit or remove existing ones.

Each marker is defined by:

Marker Types Setting
Categories Settings

The « Categories » tab enables the user to manage his groups of marker types (see Figure below). A category is a set of marker types (annotation types) chosen from the existing ones. A default category “ALL” is automatically created and contains all the marker types.

The user can add new categories and rename or remove existing ones. He can also change associated marker types for each category.

Categories Setting
Import/Export of a Configuration

A configuration is all the settings made by the user in his preferences page (all marker types and categories parameters). In order to make sharing and saving of such configurations more user-friendly, Blu Age enables the user to import existing one (files with mconfig extension) or export his own one.


Filtering Rules

This feature is an answer to the need of navigating legacy code straightforwardly by means of filtering rules (or filtering predicates). A filtering rule consists of a name, an action, a condition and a language to which the rule is applied for. The name is a string. So far, there are two types of actions:

Available conditions are classified by categories (e.g., paragraph, statement). Some examples of conditions are: empty paragraphs, specific statements. The category “Allcategories” groups conditions applicable to all listed categories (e.g., non-annotated paragraphs). A rule condition may consist of nested conditions related by the AND operator.

The creation, modification and deletion of filtering rules are available from the Eclipse preferences view: Windows > Preferences > Filtering rule configurations. As shown in Figure 1, the page consists of a table (that lists available filtering rules) and the following three buttons:

Figure 1

Let us take a look to the filtering rule creation wizard. The first page (see Figure 2) allows us to indicate a rule name, a language and an action. If the chosen action is Annotation addition, then it is mandatory to choose an annotation type from the combo box.

Figure 2

Figure 3 shows the second page which is devoted to choose rule conditions. At left side, one finds the categories on which conditions have been arranged. By selecting a given category, the list at the top right side shows the conditions associated to such a category. When one of these conditions is checked or unchecked, the condition is added/removed to/from the list at the bottom right side. Underlined blue words in conditions indicate that the condition evaluation depends on values introduced by the user.

Figure 3

The introduction of values is possible by means of dialogs which can appear at rule creation time or at rule execution time. Dialogs at rule creation time are opened by clicking the underlined words shown in the bottom right side list (see Figure 4). Dialogs at rule execution time are automatically opened. Some dialogs at rule execution time are opened only once since the value first entered (e.g., a keyword) can be reused next time. After choosing the conditions, one clicks the finish button and as a result the new rule appears in the configuration table.

Figure 4

Filtering rules can be executed from two options available in editor contextual menu: rule-based code folding and rule-based annotation addition. As the rule-based code folding option is hovered, a sub-menu showing the Code folding rules appears (see Figure 5). When one chooses a rule from there, the associated condition is evaluated and the excerpts of code holding the condition are collapsed (as indicated by the small boxes containing two points in Figure 6). To expand the code back, one selects the Not code folding sub-menu item.

Figure 5
Figure 6

Now by hovering on the rule-based annotation addition option (see Figure 7), sub-menu showing the Annotation addition rules appears. When a rule is selected, the associated condition is evaluated and the code holding the condition is annotated (Annotation editor section shows how added annotations look like).

Figure 7


Eclipse Views

A certain number of views (in the Eclipse sense of the word) are available with the reverse tool. They allow for the displaying of contextual information on the elements that make up the PACBASE programs. In general, the view context is defined by the element that is currently selected, by way of one of the editors (ch. 8) or by another view.


Segment View

Segment View

The segment view has, as its goal, the displaying of a tree view, with a segment at the root and with rubrics or group zones as sons.

The selection of a segment in the program leads to the updating of the Segment view, thereby displaying the information of the previously selected segment.

Right-clicking on a segment displayed in the view launches the entities modernization wizard (see #Vue / Wizard Transient Object Modernization).

Meaning of the view icons:

SegmentView chart organisation.png Segment
SegmentView bullet green.png Rubrique
SegmentView arrow refresh.png Zone group
SegmentView parameter.gif Redefine

Instance View

Instance View

The instances view displays the set of instances of segments declared in the working. The selection of a segment leads to the updating of the instances view.


Function View

Function View

For the function that is currently selected, this view displays its name as well as its calling and receiving functions.
The selection of a function leads to the updating of its Function view, thereby indicating the function's calling and receiving functions.

Meaning of the view icons:

FunctionView fonction.gif Function
FunctionView caller.gif Non-empty list (of accessed entities or functions)
FunctionView no caller.gif Empty list (of accessed entities or functions)
FunctionView arrow left.png Read access of entity
FunctionView arrow right.png Write access of entity
FunctionView arrow refresh.png Read and write access of entity

Dataflow View

The Dataflow view produces the same information as the corresponding HTML documentation: for a given code segment or program rubric, all the reading or writing operations connected to that rubric or segment are displayed.

The Dataflow can be sorted thanks to a simple click on the column. The sort can be produced by the transfer direction (input/output), the program name, the function name, the name of the instruction, as well as by alphabetical order within the source or the destination (Dataflow View, Fig. 1).

Selecting a segment or rubric in the editor can be done by simply clicking on the segment or by highlighting a part or the entire segment (Fig. 2).

Filtering the flow of data is possible if one uses the view handling menu. The filtering can take place on transfer directions (input/output), program names, function names, as well as instruction names (Fig. 3).

The view also takes into account the handling of events on the Dataflow list. Indeed, during the selection of an element in the Dataflow view, the editor positions itself on corresponding instruction line (Fig. 4).

Dataflow View

Fig. 1.

Fig. 2.

Fig. 3.

Fig. 4.

Meaning of the view icons:

DataflowView arrow left.png Reading of selected element
DataflowView arrow right.png Writing to selected element
DataflowView cross.png Unknown direction

Dataflow Graph View

Dataflow Graph View

The dataflow graph view is a combination of information from the Function view and the Data Flow view, and its goal is to list – ahead of a line of COBOL code – all the modifications of a given segment or rubric. This allows one to understand at which point a given value is initialized.

Once the view is active, click on a segment/rubric and launch a search for lines that are ahead that have modified it (cf. an image, as a simple example). On the latter, the modifications are done in a transitive way.


MSP View

MSP View

The MSP view (Parametrized Macrostructure) allows one to add a comment to different macros.

It is divided into three parts:

  1. a text field containing the name of the selected macro
  2. a text field containing the list of parameters of the associated macro
  3. a field of editable text that allows the user to select a comment associated with the current macro


A "Commit" button allows one to publish the local modifications. The updating of comments is therefore immediate (automatic reloading in every user's view).


Macro Call View

Macro Call View

The Macro Call view allows one to display the characteristics of a macro call.

It is divided into two parts:

  1. A tree containing the name of the macro and the values of the parameters of the macro call
  2. The text field containing the lines generated by the macro call


Documentation View

Documentation View

When a line that is produced by a macro is selected, this view displays the documentation associated with the macro.

Function Specification View

This view allows the displaying of function specification content, as a function of what is currently being selected.
It recovers the content of the "hover" which is available from the code editors (chapter 8) and is accessible through an icon of that same hover.



Metric View

The "Statistics" view allows one to obtain a certain number of reports dealing with the annotated code (Fig. 1).

The button, high and to the right, generates reports in varying formats (PDF, Excel, DOC, PPT) (Fig. 2).

The calculated metrics (so far) are:

Vue Métriques

Fig. 1.

Fig. 2.

CET View

Function

The CET (Conditional Execution Tree) view aims at facilitating batches modernization to modern execution environments such as WCG.

Since legacy code must be widely reorganized du to execution constraints on those modern environments, a transmodeling approach (see #Transmodeling) cannot be directly applied.

It is indeed needed to isolate:

This classification is performed using a family of formal annotations:

From this set of annotations, a CET tree listing all code branches is computed and displayed in the CET view.

The CET tree has the following property: each path to one of its leaf can be interpreted as a WCG "step". This step may need to be splitted if it contains impactful treatment annotations (denoting complex traetments impacting one of the conditions) or a program call. In this case, the resulting steps communicate by writing to a temporary table.

From there, it is possible to identify the constitutive elements of a WCG step (reader, processor, writer):

WCG Components

Use

The CET view reacts to PACBASE editors (files of extension .kdmcbl), for which it provides the generation of a CET tree:

Vac utilisation cet image94.png

Pressing the Refresh button (Vac utilisation cet image95.png) launch the CET generation for this program, taking into account its annotations and the elements described in the previous section.

The tree is then available in the "CET" zone. Color codes are the same as annotations colors:

Vac utilisation cet image96.png

Selecting a tree node lists all assigns preceding this node, to simplify code analysis:

Vac utilisation cet image97.png

Double-clicking on a tree node jumps to the corresponding line of the associated program.

Diagram

Once the CET tree is generated, a graphical representation can be computed by clicking on the « Refresh (Diagram) » button (Fichier:Vac_utilisation_cet_image95.png to the right). This graph is displayed in a « Diagram » tab:

Cet zest diagram.png

Miscellaneous interactions are available:

Transient Object Modernization View / Wizard

In order to perform a good quality transmodeling (see chapter #Transmodeling and especially the #Input of Missing Mappings section), legacy data types used in the transmodeled code must be modernized to UML2 classes beforehand.

The wizard available through the "Transient Object Modernization" ("TOM") PACBASE view can be used for this purpose. Entries of this view are sorted by category:

BRM tomview folded.png

Categories can be unfolded to display their content and their owning file. This view updates after two kind of actions, firstly, when a file containing a program is selected (then, program-local definitions and global scope definition will become visible), secondly, when a projet containing several programs is selected (then, all program-local definitions and global scope definition will become visible).

BRM tomview unfolded.png

Similarly to the existing behavior when selecting a data element in the editor, a selection in the PACBASE-specific TOM View will now trigger the display of the selected element structure in the Segment view. The Properties view will also be updated accordingly.

Double clicking on an entry launches the modernization wizard:

Vac utilisation cet image99.png

A default modernization is proposed. It can be modified by a set of refactorings available through a right click on the tree items:

Tracability to the legacy item is kept throughout those operations, which enables, when "Finish" is clicked:

Perspectives

Legacy Code Reverse Perspective

To open this perspective, go to Window > Open Perspective > Other... Then choose the Legacy Code Reverse perspective (Legacy Code Reverse Perspective, Fig. 1).

This perspective produces as much room as possible for the COBOL editor, by simultaneously displaying the different views that help for the understanding of the code: Outline, Segment, Instances, Functions, and DataFlow. Other views can be added according to the user's choice (Fig. 2).

Legacy Code Reverse Perspective

Fig. 1.

Fig. 2.

Retrieved from "http://wikimod.bluage.com/mediawiki/index.php/En_ba_rev_modeling"
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox