successful implementation of model driven architecture · 2014-09-30 · successful implementation...

Successful Implementation of

Model Driven Architecture

A case study of how Borland® Together®

MDA technologies were successfully

implemented in a large commercial bank

A Borland White Paper

By Choong Koon Fong, Together Product Champion – APAC Support Center

June 2007

Successful Implementation of Model Driven Architecture

2

Contents

Introduction ............................................................................ 3

The Business Case for MDA ..................................................... 4

The MDA Development Process ................................................ 5

A Highly Reusable, P latform Independent Model ..................... 6

Targeting P latform-Specif ic Models ......................................... 8

Automating Code and Arti fact Generation ...............................11

Summary ................................................................................15

References .............................................................................16


3

Introduction

One of the challenges faced by enterprise-scale software development is the effective design

of systems to support ever-changing business capabilities in a timely manner. Enterprise-

system design has evolved from merely writing high-level documentation and diagrams, to

architecting complex frameworks. The Model Driven Architecture (MDA) paradigm,

managed by the Object Management Group™ (OMG™), is an approach that seeks to address

the increasing complexity in enterprise-system design. It is not a radical departure from

performing system design, but an evolutionary step that combines various technologies for a

more effective software development process.

The MDA approach shifts the focus of software development from writing code to building

models. By adopting a model-centric approach, the MDA approach hopes to automate the

generation of system implementation artifacts directly from the model. MDA is essentially a

collection of related technologies such as the Query/View/Transformation (QVT), Object

Constraint Language (OCL), Unified Modeling Language (UML™) and the Meta Object

Facility (MOF). These technologies enable various forms of artifact and model

transformation. The MDA theory espouses the following layers of models:

• Computation Independent Model (CIM) • Platform Independent Model (PIM) • Platform Specific Model (PSM)

Transformations would be applied to assist in the realization of the actual system. As we

move down the model layers, each transformation would add more detail to a model. Cross-

domain transformation is possible via Model to Model Transformation.

This white paper is based on a success of a Borland customer in the financial industry that

prefers to remain anonymous. For the purpose of this paper we will refer to them as

Prosperous Bank. The paper details the success and benefits gained from the implementation

of a project using Borland® Together® MDA technologies.


4

The Business Case for MDA

Prosperous Bank is a large commercial bank, providing a wide range of consumer and

corporate banking services. In order to support its wide range of services and transactions,

Prosperous Bank undertook an ambitious Enterprise Application Integration (EAI) project,

with the goal of streamlining and integrating its transactional messaging system with other

systems such as legacy applications, database storage, back office and messaging systems.

The EAI project had to achieve the following business requirements, on top of the functional

requirements:

• Transaction Integrity • Performance • High Availability • Flexibility • Consistent design

The project was complex because understanding the behavior and technical complexities of

other systems were required in order to achieve successful system integration. Generating and

maintaining system-design models using a traditional approach did not seem feasible because

there were too many systems on different platforms. The project was considered high risk due

to the intricacy and broad scope.

After considering the requirements for the project, the MDA approach to software

development and design was chosen. Using Together MDA Technologies, Prosperous Bank

would successfully improve and optimize its software design and modeling activities. Using

the Together MDA approach, Prosperous Bank would improve the understanding of various

systems and ensure such understandings are externalized to software design models for future

system redesign and development. The MDA technologies in Together would be leveraged to

automate model and artifact generation through out the EAI development lifecycle.


5

The MDA Development Process

From the initial Proof of Concept prototype, Prosperous Bank found that the MDA approach

was feasible. Together provides a practical and pragmatic approach to MDA which enables

Prosperous Bank to easily map the MDA specific models with the EAI project specific

deliverables. The project specific deliverables of Domain Model, Detailed Design Model, and

Implementation Artifacts are generated using Together.

Figure 1: The MDA Process Used by Prosperous Bank


6

A Highly Reusable, Platform Independent Model

Together supports the concepts of PIM and PSM via Modeling Projects. A PIM is created by

modeling the business domain objects using a UML 2.0 Project. The structural relationships

of domain objects are captured in UML 2.0 Class Diagrams. This enables requirements to be

captured as independent models without worrying about platform specific technicalities. This

higher level of abstraction allows the EAI architects to focus on the critical task of analyzing

and understanding the requirements of the system. The MDA approach allows system

development to be handled in terms of abstractions, starting from higher-level abstractions in

the beginning and moving to lower -level details towards the end.

The PIM would be transformed into various PSM at the next stage of the project. In Together,

examples of PSM would be Java™ Modeling Projects, C++ Modeling Projects, Data

Modeling Projects and J2EE™ IDL Modeling Projects. A Together PIM is easily transformed

into any of the PSM by using the built-in Project Export Wizard which automates Model to

Model Transformation. Advanced transformation is handled by writing custom Model to

Model Transformation code in QVT.

A part of the PIM, a UML 2.0 Class Diagram is shown in Figure 2. As the EAI architecture is

transactional and message based, type information is important. The type information is

captured as UML 2.0 primitive types.


7

Figure 2: Platform Independent Model in UML 2.0


8

The PIM objects have been labeled with the Software Development Process stereotypes.

Using the Software Development Process UML Profile, Prosperous Bank is able to identify

the roles played by the objects and attach meaningful stereotype labels to the objects. The use

of the profile helps the architect to adopt a sound software development process from an early

stage.

Targeting Platform-Specific Models

A PSM is a computational model, specific to some information formatting technology,

programming-language middleware, messaging middleware or technological framework.

From the PIM, the next step was to develop the PSM which targets the Java programming

language and also the Database Model (ER Diagrams). The PIM to PSM transformation

process was simplified with the use of the Project Export Wizard.

For the Java PSM, the EAI project had the requirement to use new JDK® 1.5 language

constructs, such as generics collections support. This was possible by selecting the JDK 1.5

Java Source compatibility from the Project Export Wizard. The exported Java PSM is shown.


9

Figure 3: Java Platform Specific Model

From the PIM to PSM transformation, several issues had to be addressed:

• In the PIM, collections used in an object were modeled as aggregation links. After the transformation to the Java PSM, the architect has to consider the correct Java collections to be used. Platform specific decisions had to be made in selecting the appropriate Java collections, such as a List, a HashMap or a SortedSet.

• During the PIM modeling stage, the currency information was modeled as amount and currency attributes, each having the type of Double and String respectively. For the PSM, the architect has to consider the use of the java.util.Currency class instead.

• The original PIM Timestamp object could be replaced by a Java Date object from the java.util.Date class.

A practical approach was adopted to address these issues. They were resolved by making

changes manually to the automatically generated Java PSM. Besides the Java PSM, a Data

Model PSM was produced from the PIM. The Data Model PSM contains Database Entity

Relationship (ER) diagrams. For the PSM, several conventions were made:


10

• Only objects marked as entity objects (SwDev_entity) would be considered during the transformation. Control (SwDev_control) and boundary (SwDev_boundary) objects would not be considered.

• The package name would be used as the schema name. • Each class in the package would be mapped to a table name in the schema. • In order to indicate primary keys, the attribute chosen as the primary key would have

the stereotype of “PrimaryKey”. • An attribute of primitive type (e.g. Integer and Long) would be transformed

into a column in the table. • An attribute of an object type (e.g. Message) would be transformed into a foreign

key in the client table. • Generalization relationship maps to a foreign key in the client table. The child class

would refer to the super class.

A QVT transformation was written to handle the PIM to Data Model PSM transformation.

The QVT learning curve was reduced by reusing and modifying provided sample projects and

examples. This gave the EAI team a good starting point in understanding Together QVT

technologies.


11

Figure 4: Data Model ER Diagram PSM

Automating Code and Artifact Generation

From the PSM, the next step was to generate platform specific code and Data Definition

Language (DDL) scripts. Custom artifacts such as configuration files for middleware server


12

and XSL (Extended Style Sheet) transformation files had to be generated as well. The

diagram below shows the detailed code and artifacts transformation from the PSM.

Figure 5: Generation of Artifacts from PSM

The Java code is generated by building and refining the Java models. Using Borland

LiveSource™ technology, the PSM models would automatically generate Java code that

would be kept in sync with the models. DDL scripts were automatically created using the

DDL and SQL Script Export from the Data Modeling Project.


13

For the custom artifacts, a Model to Text transformation was written. Customized business

logic was required to generate these text artifacts. The architect was able to come up to speed

in writing the transformation by using the Model to Text Transformation Wizard and existing

examples.

Fragments of the auto-generated custom configuration and XSL file are shown.


14

Figure 6: Custom Configuration File from the Java PSM


15

Figure 7: XSL Transformation File from the Java PSM

Summary

The ultimate goal in Prosperous Bank’s EAI project was to integrate various islands of

applications that existed in the bank. Prosperous Bank needed a proof of concept that MDA

would allow the development of application adapters that would wrap around existing

applications such as legacy applications and packaged applications.

By using Together MDA technologies, Prosperous Bank was able to adopt a practical

approach to MDA. The technologies were able to fit within the overall project development

strategy. Additionally, Prosperous Bank was able to realize the following benefits:

• Future proofing of the overall EAI architecture by decoupling the business domain from the platform-specific details.

• Reduction in development expenses due to the automation of core artifact generation from models.


16

• Formal documentation and capture of the requirements in a standard modeling language.

• Quicker understanding of existing applications that are candidates for enterprise integration.

References

Anneke Kleppe, Jos Warmer, Wim Bast, “MDA Explained: The Model Driven Architecture:

Practice and Promise”. Addison-Wesley Professional, 2003, ISBN 0-321-19442-X

David S. Frankel, “Model Driven Architecture: Applying MDA to Enterprise Computing”.

John Wiley & Sons, 2003, ISBN 0-471-31920-1.

Copyright © 2007 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. All other marks are the property of their respective owners. • 25571

successful implementation of model driven architecture · 2014-09-30 · successful implementation...

Documents