| ARCHITECTURE DRIVEN MODERNIZATION [ADM] |
OMG provides a roadmap based on the MDA set of methodologies for any kind of technology modernization. This set of modernization standards envisages the following steps.
The ADM Process
Step #1: KNOWLEDGE DISCOVERY META-MODEL (KDM)
Establish a meta-model that enables modernization tools to exchange application meta-data across applications, languages, platforms and environments and provides a comprehensive view of application structure and data.
Step #2: ABSTRACT SYNTAX TREE META-MODEL (ASTM)
The ASTM represents software below the procedural level. It fully represents applications and facilitates the exchange of granular meta-data across multiple languages. The ASTM establishes the foundation for subsequent analysis, visualization and transformation standards.
Step #3: ANALYSIS
This involves examination of structural meta-data with the intent of deriving behavioral meta-data about the system. This behavioral meta-data may take the form of business rules or other aspects of a system that are not part of the structure of the system, but are semantic derivations of that structure and the data.
Step #4: SOFTWARE METRICS PACKAGE (SMM)
The focus of the Software Metrics Package is to derive metrics from the KDM that can describe various system attributes. These metrics convey technical, functional and architectural issues for the data and the procedural aspects of the applications of interest. These metrics support planning and estimating, ROI analysis and the ability of analysts to maintain application and data quality.
Step #5: VISUALIZATION
Visualization focuses on ways to depict application meta-data stored within the KDM. This may include any variety of views as may be appropriate or useful for planning and managing modernization initiatives. Examples include the use of graphs or charts, metric summaries or standardized development models.
Step #6: REFACTORING
Refactoring defines ways in which the KDM can be used to refactor applications. This includes structuring, rationalizing, modularizing and in other ways improving existing applications without redesigning those systems or otherwise deriving model-driven views of those systems.
Step #7: TRANSFORMATION
Transformation defines mappings between the KDM and ASTM and target models. This standard defines the mappings and transformations that may occur between existing applications and top down, target models. Development paradigms may vary, but will include MDA as a target. This standard provides a transformational bridge between existing systems and target architectures.
|
Our Rapid Transformation Methodology
Based on the standards defined by ADM, we have devised our Rapid Transformation Methodology (RTM). RTM retains the goodness of time-tested legacy applications while migrating the application to a modern environment. RTM empowers the business people to become the protagonists in the application development and maintenance lifecycle. We teach your business people to use Business Process Management tools where they can specify all necessary business process information. We use code generators to convert your Business Model into deployable applications. In the process, you get “maintainable Business Models” instead of maintainable source code.
Overview
There are various approaches to accomplishing our goal.In our purest approach, we use OMG's Architecture Drive Modernization (ADM) methodology to extract "knowledge" from your existing application and export it to the standard MDA process, as depicted below: |
|
There are variations of this approach that we shall discuss later. Let us first explore the AUTOMATED DESIGN
Step #1: DESIGN RECOVERY
Meta-Model Driven Approach
A Meta-Model contains information about a model. For instance, a Java Meta-Model defines the grammar, syntax, rules, constraints and structure of Java. Meta-Models are complicates structures that enable us to understand and model your application.
|
|
As the first step to transforming any application, we must build a Meta-Model (or use an existing Meta-Model) of the programming languages your application is written in.
Then our parsers can analyze the source code (with reference to the meta-model) and extract all possible atomic-level software artifacts into an XML Repository. The XML Repository then enables us to fully analyze the source code and automatically generate documentation and analysis results for further engineering. See schematic below: |
|
Our parsers are at the heart of the process. These parsers use Source Language Meta Models to interpret a given source code. We already have meta-models for most languages.
The parsers extract the design artifacts that contain the “knowledge” of any application: Data Structures, Input/Output Screen/Report layouts, Business rules and data transformation procedures.
The extracted Business Model, along with all the source code reduced to the atomic level, is stored in an XML Repository. Various kinds of useful documentation and analysis can be easily produced from here. |
Step #2: RE-ENGINEERING
We analyze the existing architecture, diversity of tools used, usage of external function calls (black boxes), programming ingenuity, data models, program structure, inter-program communication, external APIs, and so on, we can truly assess the “as is" state of affairs.
Based on this assessment, we can advice you on the pros and cons of the strategic directions we can take to modernize the application.
The typical choices are:
1) Adopting Model Driven Architecture (MDA)
We shall implement the process depicted earlier (under OVERVIEW), which we reproduce below for your easy reference:
|
|
| The steps under this process are as follows: |
a) Use Automated Design Recovery to extract the "knowledge" of your existing application.
b) Use that knowledge, with supplemental assistance from business users, to build the Business Model – called Platform Independent Model (PIM) in MDA parlance -- using a BPM Tool.
c) Use MDA's model-to-model transformation procedures to automatically convert the PIM (i.e., Business Model) into Source Code.
d) Compile, link, deploy the generated software.
|
2) Adopting a "loosely-coupled" approach to MDA |
This generally means skipping the Platform Independent Model (PIM), the Business Model, but employing automated model-to-model transformation concepts to migrate an existing application from one platform to another. Below are two typical examples just to give you an idea. We shall refrain from a detailed discussion here.
|
Step-3: IMPLEMENT THE CHOSEN MIGRATION METHODOLOGY |
| Regardless of method chosen, the ultimate results are typically as follows (not intended to indicate sequence of events): |
1) A new target platform is selected . For instance, J2EE, .NET, etc.
2) A new architecture is determined for the new platform under the 'n-tier' architecture.
|
The n-tier architecture readily implements Distributed Application Design concepts. It distributes a system’s overall functionality into a number of layers or “tiers” with each tier performing some unique tasks that are not handled by other layers. It is possible to develop each of these layers separately from the others, as long as it can communicate with the other layers and adhere to the standard specifications. It is possible for each layer to treat the other layers in a “black box” fashion. That means that the layers do not care how the other layers process information, as long as the data is sent between layers in the correct format. This separation of concerns protects the other layers from any changes that might occur within the functions one particular layer handles.
|
The following is an example of 7-tier architecture: |
|
Depending on whether J2EE or .NET is selected as the target, the exact architectural components shall vary, as depicted in the schematic below: |
 |
3) If required, the new application is Web-enabled.
We have tools to automatically generate GUI screens from Mainframe/Midrange Character User Interfaces, which can then be manually touched up, as necessary.
4) If required, the application is migrated to a New Database.
Database consolidation (merging multiple databases into one database) is sometimes a requirement.
5) New source code is generated in the target languages.
More than one language may be called for. This may include DDL (Data Definition Language routines), WSDL (Web Service Definition Language), XSD (XML Schema Definition), CSS (Cascading Style Sheets), Stored Procedures and other code segments. All source code is part of our deliverable.
6) Additional code re-factoring, SOA-enablement and additional functionality may be implemented, if required.
7) Dynamic documentation of the new code base is generated, where the documentation will change in real-time to reflect the latest changes to the software.
|
| |
| |
