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