successful implementation of model driven architecture · 2014-09-30 · successful implementation...
TRANSCRIPT
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
Successful Implementation of Model Driven Architecture
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.
Successful Implementation of Model Driven Architecture
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.
Successful Implementation of Model Driven Architecture
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
Successful Implementation of Model Driven Architecture
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.
Successful Implementation of Model Driven Architecture
7
Figure 2: Platform Independent Model in UML 2.0
Successful Implementation of Model Driven Architecture
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.
Successful Implementation of Model Driven Architecture
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:
Successful Implementation of Model Driven Architecture
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.
Successful Implementation of Model Driven Architecture
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
Successful Implementation of Model Driven Architecture
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.
Successful Implementation of Model Driven Architecture
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.
Successful Implementation of Model Driven Architecture
14
Figure 6: Custom Configuration File from the Java PSM
Successful Implementation of Model Driven Architecture
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.
Successful Implementation of Model Driven Architecture
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