Successful Implementation of Model Driven Architecture

A case study of how Borland® Together® MDA technologies were successfully implemented in a large commercial bank

A B or la nd Wh it e Pap er

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

June 2007

Successful Implementation of Model Driven Architecture

Contents

In troduc tion ...... 3

The Business Case fo r MD A ...... 4

The MDA D eve lop men t Process ...... 5

A H igh ly Reu sab le, P la tfo rm Indepen den t Mo del ...... 6

Targ eting P la tfo rm -Sp ecific Mo dels ...... 8

Auto ma ting Cod e a nd A rtifac t Gen eration ...... 11

Sum ma ry ...... 15

Refe re nces ...... 16

2 Successful Implementation of Model Driven Architecture

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 ™ (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 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.

3 Successful Implementation of Model Driven Architecture

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, 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.

4 Successful Implementation of Model Driven Architecture

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

5 Successful Implementation of Model Driven Architecture

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 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.

6 Successful Implementation of Model Driven Architecture

Figure 2: Platform Independent Model in UML 2.0

7 Successful Implementation of Model Driven Architecture

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 labels to the objects. The use of the 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.

8 Successful Implementation of Model Driven Architecture

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:

9 Successful Implementation of Model Driven Architecture

• 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 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.

1 0 Successful Implementation of Model Driven Architecture

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

1 1 Successful Implementation of Model Driven Architecture

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.

1 2 Successful Implementation of Model Driven Architecture

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.

1 3 Successful Implementation of Model Driven Architecture

Figure 6: Custom Configuration File from the Java PSM

1 4 Successful Implementation of Model Driven Architecture

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.

1 5 Successful Implementation of Model Driven Architecture

• 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

1 6