Model Driven Architecture in the Enterprise
Final Report
12/15/05
CSE 333
Professor: Steven Demurjian
Amit Adur
Keyur Patel
Sabhay Kapoor
Saleh Ibrahim
Table of Contents
Model Driven Architecture in the Enterprise i
Table of Contents ii
MDA in the Enterprise 4
Abstract 4
1. Introduction 4
2. Background 5
2.1 MDA 5
2.1.1 MDA Objectives 5
2.1.2 MOF: the MDA’s Genie 5
2.1.3 Role of UML in MDA 7
2.2 EDOC: Model-Driven Enterprise Architecture 7
2.3 Alternatives to MDA/EDOC 8
3. Evaluation Criteria for MDA Tools 8
4. Evaluation of MDA compliant tools 12
4.1 Borland Together Architect 2006 for Eclipse 12
4.2 I-Logix Rhapsody 21
4.2.1 Rhapsody Overview 21
4.2.2 Rhapsody Evaluation 22
4.2.3 The MIA-Software Tool Suite 27
4.2.4 Rhapsody and MIA-Tools 28
4.3 OptimalJ Developer Edition by intelliJ 4.0.00 29
4.4 MagicDraw UML 10.0 41
5. Summary of Results 51
6. Conclusions and Future Work 52
Appendix A: UML 1.x and MDA 54
A.1 Advantages 54
a) Separation of Abstract Syntax from Concrete Syntax 54
b) Enabling Extensibility 54
c) Supports platform-independent models 54
d) Open Standard 54
A.2 Disadvantages of using UML 1.x: 55
a) Not enough support for component based modeling 55
b) UML and MOF are not in sync 55
Appendix B: 4. Other Enterprise Architectures 55
B.1 TOGAF Model 55
B.2 IDEF (for Integrated Definition) 56
B.3 The Zachman Framework 56
B.4 C4ISR 57
B.5 The Treasury Enterprise Architecture Framework (TEAF) 57
Appendix C: Other MDA Tools 58
C.1 OpenMDX: An Advanced MDA Framework 58
C.2 ExecutableUML (xUML) 58
C.3 Component-X by Data Access Technologies 59
C.4 The TAU Generation2 Approach to MDA 59
Appendix D. Project Schedule and Task Assignment 60
References 62
-ii-
MDA in the Enterprise
Abstract
Model Driven Architecture (MDA) has the potential to revolutionize software development, especially for enterprise application where integration and maintainability are challenging. In this project we will present the basics of MDA and how it can leverage enterprise application development. We will also present the relatively-new Enterprise Distributed Object Computing (EDOC) standard, which attempts to standardize MDA application to the Enterprise. The role UML plays in MDA is explained along with what has been introduced in UML 2.0 to enhance this role. Other enterprise development approaches will be briefly explain and contrasted with MDA/EDOC. Furthermore, we evaluate MDA/EDOC-support in available software modeling tools using specific derived evaluation criterion. Finally we will attempt to anticipate the future direction in MDA-based standards as well as industry support and adoption of these standards.
1. Introduction
For decades, software engineering continued to be an evolving discipline. Software developers are still after software development approaches that achieve reusability at more levels of abstraction. This is particularly true for developing applications for the enterprise; where business collaborations are a central concern. Software designers need a modeling framework that enables process engineering by assembling reusable services. Moreover, the development approach must enable parts of the enterprise to react quickly and reliably to changes in requirements and in available technologies.
Model Driven Architecture (MDA) enables the clear separation of platform-independent and platform-specific models, allowing the implementation of platform-independent models on any platform. Although UML isn't an integral part of MDA, it is still a language of choice for MDA. UML version 2.0 was specifically enhanced to empower UML's role in MDA. Before MDA was standardized by OMG, this approach has been applied for years to embedded and real-time software development. Now, the concept of MDA is applicable to almost all categories of the software industry [DF03]. While enterprise software development benefited from MDA, Enterprise Distributed Object Computing (EDOC) arrived as a standardized MDA-based modeling framework tailored for enterprise needs. EDOC also carefully covers the five viewpoints of the Open Distributed Processing Reference Model (ODP-RM), which is a widely-accepted software engineering reference model for distributed processing [IJ].
The rest of this document is organized as follows: Section 2 presents some background information on MDA, MOF, and ODP-RM, and the role of UML in MDA. EDOC is given special attention as an MDA-based standard for modeling enterprise component systems. Section 3 introduces the software modeling tools that are have been identified as MDA-compliant. Section 4 explains the current status of our project and future plan. Appendix A explains the advantages and disadvantages of UML 1.x and Appendix B presents Alternative Enterprise Development approaches
2. Background
The Enterprise Distributed Object Computing profile is a UML profile for modeling enterprise applications. In this section we will describe the rational for MDA, how it relates to existing concepts and standards such as MOF, ODP-RM, and UML.
2.1 MDA
Over the past decade, software designers’ attention shifted towards more clear separation between platform independent and platform dependent models. OMG’s Model Driven Architecture (MDA) provides an open, vendor-neutral approach to the challenge of business and technology change [OMG]. This is why MDA is often defined as an approach to modeling that separates the specification of system functionality (platform[1]-independent model) from the specification of its implementation on a specific technology platform (platform-specific model) [EC04]. But actually the benefits of MDA go even further. In this subsection we elaborate on the various objectives of MDA and how MOF and UML enable MDA to achieve these objectives.
2.1.1 MDA Objectives
Usually different aspects of the same application can be modeled separately using different modeling languages. For example, the relational data store structure can be modeled using and Entity-Relationship diagram, while the format of communicated messages carrying the same pieces of data can be modeled using an XML Document Type Definitions. One of the most difficult challenges a software architect faces is keeping these different models in sync [DF03].
MDA achieves this objective by taking one step back and starting at the model level, hence model-driven architecture. An MDA-based framework will be composed of a set of modeling languages that will be used for modeling different aspects or viewpoints of the application. By defining transformation rules between the different modeling languages consistency between the different models developed can be observed. Figure 1 illustrates the role of MDA in integrating different models describing the same application.
2.1.2 MOF: the MDA’s Genie
In order to define modeling languages, MDA uses formal models called meta-models. Metamodels are basically models that describe modeling languages [DF03]. As an example of a metamodel refer to Figure 2 for the metamodel for Java Class Contents [MU04].
The Meta Object Facility (MOF) supports the managing of different metadata in a coordinated way. The basic idea is to define a formal model of each language. These models then drive MOF-based generators that keep the consistency between models based on the rules defined on their corresponding metamodels. Figure 3 illustrates the role of MOF generators
Obviously MDA can achieve neat separation of platform-independent models from platform-specific models, by guiding the software architect to carefully define platform-independent metamodels, platform-specific metamodels and the mappings between them. MOF-Generators can then convert platform-independent models into platform dependent artifacts, such as interfaces, classes, beans, etc.
Figure 1. MDA is an overall architecture for integrating different specifications of the same software product made from different viewpoints in different languages [DF03].
Figure 2 The metamodel for Java Class Contents expressed in UML [MU04]
2.1.3 Role of UML in MDA
Although MDA as an approach is not built on UML, practically MDA took advantage of many of the UML strengths and derived enhancements to the UML standard. In 2003, UML 2.0 was created to correct some of the shortcomings of the previous versions of UML 1.x. The following sections will describe some of the advantages and disadvantages of UML 1.x from an MDA perspective [DF03]. Then we will look at UML 2.0 and discuss how some of these disadvantages are eliminated [CE03]. Refer to Appendix A for details.
UML 1.x Advantages / UML 1.x Disadvantages· Separation of Abstract Syntax from Concrete Syntax
· Enabling Extensibility
· Supports platform-independent models
· Open Standard / · Not enough support for component based modeling
· UML and MOF are not in sync
Improvements in UML 2.0:
a) Support for component based modeling
UML 2.0 has added functionality of modeling objects via composite structures. For example structured classifies such as classes and components can be decomposed hierarchically and assembled.
b) UML and MOF
The slight inconsistencies between UML and MOF have been corrected in UML 2.0
2.2 EDOC: Model-Driven Enterprise Architecture
One step from conceptual specification to technical specification of MDA was OMG’s introduction of the EDOC specification. EDOC integrates enterprise platform-independent application models called the Enterprise Collaboration Architecture, with platform-specific UML profiles, including but not limited to Web Services, .NET, CORBA, and J2EE. In this manner, both business and technical aspects of an application can grow at its own pace independent of each other. EDOC was greatly inspired by the industry standard Open Distributed Processing Reference Model described in the following section.
The Open Distributed Processing Reference Model
ISO has approved a Reference Model for Open Distributed Processing (ODP-RM) partitions system specifications into five viewpoints, namely [IJ], the enterprise viewpoint, the information viewpoint, the computational viewpoint, the engineering viewpoint, and the technology viewpoint. This clear separation of concerns is crucial to the success of enterprise modeling. What it lacks was the mechanism to seamlessly integrate multi-viewpoint models into a consistent enterprise model, and this is where MDA comes to action.
The EDOC elements can be clearly divided into three categories; Platform-Independent Profiles, Platform Dependent Profiles and Pattern Profiles. Figure 3 illustrates these categories and their location in the ODP-RM [EC04].
Figure 3: EDOC Elements from the ODP-RM viewpoints perspective
2.3 Alternatives to MDA/EDOC
There have been many approaches to enterprise software development, usually focusing on different aspects of the development process. Some of them are already obsolete, while others even integrate with MDA. TOGAF, IDEF, The Zachman Framework, C4ISR, and TEAF has been identified and briefly described in Appendix B.
3. Evaluation Criteria for MDA Tools
Up till now OMG specifies guidelines for using MDA [MG03], but has no MDA certification process. Tool vendors use the term MDA-support often to mean different things. One of the major objectives of this project is to identify and evaluate UML modeling tools that claim to support MDA, by comparing them to the MDA guidelines. We have identified the many tools that claim MDA-support. We then picked four of them based on their availability for evaluation and on their overall conformance to MDA guidelines. In this section we will present the evaluation scheme, which extends the work done in [EV03], with more specific details.
Evaluation Criteria
The work done in this project to evaluate MDA modeling tools, use the feature analysis approach. In this approach, a set of features relevant to the goal of evaluation is listed and the support of each of these features is then checked in every tool. As there might be different levels of support for each of the features, we used a 4-star rating scheme rather than a yes/no scheme.
OMG defines only a set of guidelines [MG03], based on which the authors of [EV03] devised a sixteen-feature evaluation criteria. In order for this criteria to be more useful we added specific sub-features to each of the sixteen features to make it easier to evaluate. The sixteen-feature evaluation criteria are shown in Table 1.a and 1.b.
Criteria Number / Criteria Name / Criteria ExplanationMDA 01 / Support for PIM / § Support of at least one PIM (Generic UML and domain-tagged UML profiles can be considered PIM)
§ Support Multiple Viewpoint PIM
§ PIM extensibility (custom Metamodels)
§ PIM Metamodels editing facility
MDA 02 / Support of PSM / § Support at least one PSM (platform in the sense of middleware)
§ Platform-tagged UML profiles count as PSM
§ (PIM to PSM is a critical requirement of MDA)
MDA 03 / Can Target Multiple PSM / § Target more than one PSM, e.g. J2EE and .NET
§ PSM extensibility
§ PSM Metamodels editing facility
MDA 04 / Model Integration / § Multiple diagrams of the same type
§ Multiple diagram types
§ Multiple viewpoints feed the same transformation
MDA 05 / System Evolution / § Source code management
§ Forward propagation of changes
§ Efficient-forward propagation of changes (updates only)
MDA 06 / Model Interoperability / § Import models from other legacy tools
§ Import XMI
§ Export XMI
MDA 07 / Mappings are modeled / § Legacy-customizable Model-to-Code mappings
§ Quasi-standard QVT Model-to-Code mappings
Table 1.a Evaluation Criterion
Criteria Number / Criteria Name / Criteria ExplanationMDA 08 / Support for Managing Model Complexity / § Locating modeling elements in models
§ Zooming in and out
MDA 09 / Correctness / § Modeling tool checks static models based on the corresponding metamodels
§ Allow more rules to be defined and checked
MDA 10 / Expressivity / § Language "can" express any instance of the domain it is modeling
§ support expressive higher levels of abstraction (PIM)
MDA 11 / Patterns and Genericity / § Use of ready-made patterns in code generation
§ Use of ready-made patterns in transformations
§ User-defined patterns
MDA 12 / Support for Refactoring / § Generate Model given Code
§ Propagate code changes to model (roundtrip)
MDA 13 / Intra-Model Mappings / § Built-in Model-to-Model Mappings (transformations)
§ Immediate propagation of changes between models related by transformations
§ Legacy-customizable transformations
§ QVT Model-to-Model mappings
MDA 14 / Traceability / § PSM elements reference PIM elements where they originate
§ Transformations generate a log that help tracing the execution of the different mappings
MDA 15 / Life Cycle / § Analysis,
§ Design,
§ Implementation,
§ Testing
MDA 16 / Standardization / § UML
§ MOF
§ XMI
§ QVT
Table 1.b Evaluation Criterion (continued)
Not all features are born equal, some are critical to the concept of MDA, some are useful and others are just optional. In order for our evaluation to be more meaningful, we had to assign every feature one of the following importance levels: