Model Driven Architecture in the Enterprise
Final Report
12/15/05
CSE 333
Professor: Steven Demurjian
Amit Adur
Keyur Patel
Sabhay Kapoor
Saleh Ibrahim
-i-
Table of Contents
Model Driven Architecture in the Enterprise ................................................................................... i
Table of Contents ............................................................................................................................ ii
MDA in the Enterprise .................................................................................................................... 3
Abstract ........................................................................................................................................... 3
1. Introduction ................................................................................................................................. 3
2. Background ................................................................................................................................. 4
2.1 MDA ..................................................................................................................................... 4
2.1.1 MDA Objectives ............................................................................................................ 4
2.1.2 MOF: the MDA’s Genie ................................................................................................ 4
2.1.3 Role of UML in MDA ................................................................................................... 6
2.2 EDOC: Model-Driven Enterprise Architecture..................................................................... 6
2.3 Alternatives to MDA/EDOC ................................................................................................. 7
3. Evaluation Criteria for MDA Tools ............................................................................................ 7
4. Evaluation of MDA compliant tools ......................................................................................... 11
4.1 Borland Together Architect 2006 for Eclipse ..................................................................... 11
4.2 I-Logix Rhapsody ............................................................................................................... 20
4.2.1 Rhapsody Overview..................................................................................................... 20
4.2.2 Rhapsody Evaluation ................................................................................................... 21
4.2.3 The MIA-Software Tool Suite ..................................................................................... 26
4.2.4 Rhapsody and MIA-Tools ........................................................................................... 27
4.3 OptimalJ Developer Edition by intelliJ 4.0.00 .................................................................... 28
4.4 MagicDraw UML 10.0 ....................................................................................................... 40
5. Summary of Results .................................................................................................................. 50
6. Conclusions and Future Work ................................................................................................... 51
Appendix A: UML 1.x and MDA ................................................................................................. 53
A.1 Advantages ......................................................................................................................... 53
a) Separation of Abstract Syntax from Concrete Syntax ...................................................... 53
b) Enabling Extensibility ...................................................................................................... 53
c) Supports platform-independent models ............................................................................ 53
d) Open Standard .................................................................................................................. 53
A.2 Disadvantages of using UML 1.x:...................................................................................... 54
a) Not enough support for component based modeling ........................................................ 54
b) UML and MOF are not in sync ........................................................................................ 54
Appendix B: 4. Other Enterprise Architectures............................................................................. 54
B.1 TOGAF Model ................................................................................................................... 54
B.2 IDEF (for Integrated Definition) ........................................................................................ 55
B.3 The Zachman Framework................................................................................................... 55
B.4 C4ISR ................................................................................................................................. 56
B.5 The Treasury Enterprise Architecture Framework (TEAF) ............................................... 56
Appendix C: Other MDA Tools .................................................................................................... 57
C.1 OpenMDX: An Advanced MDA Framework .................................................................... 57
C.2 ExecutableUML (xUML) ................................................................................................... 57
C.3 Component-X by Data Access Technologies ..................................................................... 58
C.4 The TAU Generation2 Approach to MDA ......................................................................... 58
Appendix D. Project Schedule and Task Assignment ................................................................... 59
References ..................................................................................................................................... 61
-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
-3-
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 (platform1independent 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].
1
It is important to note that platform here refers also to middleware as well as the conventional hardware,
programming language or operating system platform.
-4-
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 platformindependent 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]
-5-
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 platformindependent 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
-6-
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
-7-
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
MDA 01
Criteria Name
Criteria Explanation
Support for PIM




MDA 02
Support of PSM

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


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
(updates only)
of
changes
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
-8-
Criteria
Number
MDA 08
Criteria Name
Criteria Explanation
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
MDA 11
Patterns and
Genericity
MDA 12
Support for
Refactoring
MDA 13
Intra-Model
Mappings


Language "can" express any instance of the
domain it is modeling
support expressive higher levels of abstraction
(PIM)





Use of ready-made patterns in code generation
Use of ready-made patterns in transformations
User-defined patterns
Generate Model given Code
Propagate code changes to model (roundtrip)

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

MDA 15
Life Cycle




PSM elements reference PIM elements where
they originate
Transformations generate a log that help tracing
the execution of the different mappings
Analysis,
Design,
Implementation,
Testing
MDA 16
Standardization




UML
MOF
XMI
QVT

Table 1.b Evaluation Criterion (continued)
-9-
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:
1. Critical features: are features that are considered an integral part of the MDA
concept. It is critical that an MDA tool supports such a feature.
2. Recommended features: features that are highly recommended, the absence of
which causes serious inconvenience to the user. It is recommended that an MDA
tool supports such a feature.
3. Optional features: features that can enhance MDA tool usability, but the absence
of which can be tolerated at minimal inconvenience. It is optional that an MDA
tool supports such a feature.
Through our investigation we came to a consensus about the importance level of each
feature. Table 2 shows how every feature was classified according to this rating.
Critical Features
Weight 5
MDA 01
MDA 02
MDA 03
MDA 04
Recommended Features
Weight 3
Optional Features
Weight 1
MDA 05
MDA 06
MDA 07
MDA 08
MDA 09
MDA 10
MDA 11
MDA 12
MDA 13
MDA 14
MDA 15
MDA 16
Table 2. Level of Importance
We also designed a weighting system for these three categories where we placed a weight
of 5 for critical features, a weight of 3 for recommended features and a 1 for optional
features, so that we can calculate a rough estimate on how evaluated tools compare to
each other from the MDA support perspective.
The next section lists and evaluates some of the tools that claim MDA support.
-10-
4. Evaluation of MDA compliant tools
A long list of UML modeling tools claim to support MDA. In this project, eight different
tools have been considered, four of which have been later disregarded for reasons that
relate mainly to feasibility of the evaluation process. This section describes in detail the
evaluation process of the four tools that were evaluated, namely Together, Rhapsody,
OptimalJ and MagicDraw. For a description of the other four tools that were not
evaluated along with the reason why each of them was disregarded, refer to Appendix C.
4.1 Borland Together Architect 2006 for Eclipse
Borland Together Architect 2006 for Eclipse is a comprehensive modeling solution tool
for software architects with which they can design, develop, and communicate enterprise
application architectures. It enables designers to create UML and business process
models. It is built upon an Eclipse environment with built-in Together support for UML
and Model Driven Architecture (MDA by including OMG’s Query View Transformation
(QVT) used in model-to model transformations [OG]. Figure 4 is a snapshot of Together
Architect 2006 for Eclipse’s user interface.
Figure 4: Together Architect 2006 for Eclipse
-11-
Some of the features the tool offers are highlighted below:

Together Architect 2006 provides a complete set of MDA capabilities based on its
transformation framework. Transformation framework includes QVT
implementation as well as support for other transformation techniques.

Business Process Modeling Notation (BPMN) is designed to cover many types of
business process modeling with any level of detail and allows the creation of endto-end business processes. A diagram created in the Business Process Modeling
project can be exported to BPEL/WSDL files with the help of Export command
on the File menu.

Provides data modeling solution with the help of logical and physical entity
relationship diagrams and import/export capabilities.

Together provides support for the following diagrams and notations defined by
the UML 2.0: Activity, Class, Component, Composite structure, Deployment,
State Machine, Use case, Communication, Sequence.

Create or modify elements using patterns and templates. In addition you can
create your own patterns and distribute them as plug-ins in your organization.
Pattern definition project is a profiled UML 2.0 modeling project.

Profiles can be used to adapt the UML semantics without changing the UML
metamodel. You can also use a profiled UML 2.0 modeling project that allows
creation of profile definitions for creating your own profiles.
Support for Model Driven Architecture (MDA):
In this aspect, we will cover the main building blocks of the MDA-support tool, its main
approaches, solution to address MDA concepts and transformations.
Together for Eclipse provides a complete set of Model Driven Architecture (MDA)
capabilities based on the Together model transformation framework. The framework
implements some of the MOF 2.0 Queries/Views/Transformations (QVT) concepts and is
based on the EMF (Eclipse Modeling Framework).
Together Architect 2006 for Eclipse’s built-in documentation is complete enough to
understand how the transformation is done. Documentation and help topics are very
thorough with “cheat sheets” for MDA transformation tutorials and a searchable index
with a large collection of help topics.
-12-
Meta-models:
Tool has a vast library of meta-model definitions for technology mapping. These
technology dependent metamodels range from metamodels for UML to JAVA to EJB to
name a few. These meta-models and their properties can be viewed in the metamodel
browser window as shown below.
Figure 5: Metamodel Browser
The advantage is that the tool has built-in support for metamodel for various
technologies. However, the disadvantage of the metamodel library within the tool is that
there is no support for editing existing meta-model or creating own custom meta-model
for extensibility purposes.
-13-
Meta-models are used for transforming models into models and models into code. They
are imported into the transformation code necessary to define transformation mappings.
We will talk about this in detail in the following sections.
Model Driven Transformations:
Model to Model Support
Model to model transformation is supported in Together Architect 2006 for Eclipse. A
diagram of the steps required for the transformation is shown in figure 6.
Create
QVT
Transformation Script
Create Input Model
Apply Transformation
Check Output Model
for Correctness
Figure 6: Steps for Model to Model Transformation
To create a model to model transformation, users will first have to open a new MDA
transformation project. When a model to model transformation project is selected,
Together prompts the user to choose the metamodels for the input model and the output
model which will then be imported in the transformation script. A screenshot is shown
below.
Figure 7: Model to Model Transformation
-14-
Together gives the user a Query View Transformation (QVT) language editor for
defining the guidelines for transforming an instance of one Together or Eclipse Modeling
Framework (EMF) model to an instance of another Together or EMF model. This is the
engine which is responsible for enabling this transformation using OMG’s QVT
language.
A screenshot of a sample QVT transformation file follows.
Figure 8: Example of the QVT Transformation Script File
On the tope of the QVT file, the input and output metamodels are imported for using the
semantics for the transformation. Then it uses the semantics to create package and
classes within the packages for the output diagram.
The framework provides a declarative QVT language for defining mappings between
models and a transformation engine for interpreting the mapping definitions and queries.
The QVT language implements the latest (ad/05-03-02) MOF 2.0 QVT specification
which is still under revision. The language currently supports metamodel and
transformation import and OCL expressions. Relations are not supported yet.
-15-
The framework comes with a set of tools that helps you write, run, and debug
transformations. The QVT Editor provides basic QVT editing features (such as code
sensitive editing, syntax checking and highlighting). The Eclipse Debugger for QVT
allows you to trace the execution of the rules step-by-step. The debugger supports
breakpoints (including StepOver, StepIn and StepOut features), watches and Variable
view. The QVT Traces view enables you to inspect the result of a transformation when it
is completed.
Model to Code Support
Model to code transformation is also supported in Together Architect 2006 for Eclipse
and the technique is very similar to model to model transformation. The steps are
illustrated below.
Define Transformation
Code
Create Input Model
Apply Transformation
Check Output File for
Correctness
Figure 9: Steps for Model to Code Transformation
Model to code transformations can be performed by opening a new MDA transformation
project for model to text. For this, the user has to choose the metamodel for the input
model which will be imported in the transformation code. This is similar to the model to
model transformation. Model to text transformations are responsible for transforming an
instance of on Together or EMF model into an arbitrary text output.
A transformation is developed within the MDA Transformation project as a custom Java
Eclipse plug-in. You can create, run and debug transformations within the project
environment. When your transformation is ready, you can apply it to models and model
elements. The compiled transformations can be distributed among other Together users in
your organization since they can be deployed within the Eclipse environment as standard
Java plug-ins.
The transformation code is written in JAVA by programmers and they can specify the
output file format in this code. For example, below is a snippet of a transformation code
which converts a UML class diagram into a text file which lists all the classes that are
included in the package.
-16-
Figure 10 . Example of Transformation code written in JAVA.
After defining the transformation code, the transformation can be applied using the
“Apply Transformation” tool from the Model menu. This is will the UML diagram as
input and convert it into the appropriate code or text file.
Patterns Support
Together allows you to design your own profiles with the help of Profile Definition
Project. You can use profiles to manage a collection of tagged values and stereotypes for
your projects. After you create custom profiles, you can create profile plug-ins to share
them with your team members.
The “Profile Definition” group on the Tools Palette and “Profile Definition” group on the
context menu contain elements for creating your profiles.
Working with profiles consists of the following major stages:



creating profile definition
deploying profile
applying profile
Once the custom profile is created and deployed, it is added to the list of supported
profiles in the Modeling Preferences. You can enable it for your projects and define it as
a default profile
-17-
Evaluation of Borland Architect 2006 for Eclipse
This section will use the previously described guidelines to show how the tool ranks with
each guideline for supporting MDA. The evaluation is shown in a tabular format.
Criteria
MDA01
MDA02
MDA03
MDA04
MDA05
MDA06
MDA07
MDA08
Description
Evaluation
Support for PIMs
Tool allows Business Process
Models (BPM) to be created at a
very abstract level without the
details of implementation
Support for PSMs
Tools supports creation of J2EE,
EJB, etc. specific projects
Can Target Multiple PSMs
Together Architect supports
mainly J2EE
Model Integration
Able to use multiple diagrams
such as class, use case, sequence,
state, etc. to create a single
application
System Evolution
When changes in the input
model are made, the transformed
model or code is not update in
real time. The transformation has
to be redone in order for the
changes to be reflected in the
output model or code.
Model Interoperability
Together Architect 2006 is able
to export models as a standard
XMI documentation for intertool operability
Mappings are modeled
Tool provides QVT language
support for model to model
mappings and transformation
code editor and debugger for
JAVA
transformation
code
mapping for model to code
transformations.
Support for Managing Model Component diagrams are used to
Complexity
model higher level or more
complex structures, usually
consisting of one or more
classes, and providing a well
defined interface. Component
Diagrams illustrate the pieces of
software, embedded controllers,
-18-
Score
3
2
1
4
1
4
4
2
MDA09
Correctness
MDA10
Expressivity
MDA11
Patterns
MDA12
Support for Refactoring
MDA13
Intra-Model Mappings
etc. that will make up a system.
Together provides a wide variety
of audits, ranging from design
issues to naming conventions.
The process of running audits
begins with your selecting the
specific rules to which your
source code should conform.
Together generates an audit
report that displays only the
violations of those rules. You
can examine each violation and
decide whether to correct the
source code.
Supports
high
level
of
abstraction in PIMs
Pattern instances appear as a
result of recognition of the
existing model or creating new
instances (along with model
elements playing pattern roles)
in the model. Pattern instances
contain information about the
pattern name and the role of each
participant.
The goal of refactoring support
is to allow for improving your
code without changing its
behavior. When you refactor
your code, your goal is to make a
system-wide coding change
without affecting the semantic
behavior of the system. The JDT
automatically
manages
refactorings for you. The
workbench optionally allows
you to preview all the impending
results of a refactoring action
before you finally choose to
carry it out.
Does not support built-in model
to model mappings. Mapping
has to be developed by
programmers
using
QVT
language
-19-
4
3
4
4
0
MDA14
Traceability
MDA15
Lifecycle
MDA16
Standardization
A
Model-to-model
transformation produces an
instance of an auxiliary trace file
with detailed information about
every
transformation
step
performed. The trace file can be
opened using the designated
Traces view.
Tool plays a role in the complete
life cycle of a system, which
includes design, implementation,
debugging and testing, and
finally deployment. QVT and
Model to Text transformations
are deployed as standard Java
Eclipse plug-ins using Export
Plug-ins and Fragments Wizard
Together Architect 2006 uses
standard UML notation and can
import or export models as XMI
documents.
2
4
4
Table 3. Evaluation Table for Together Architect 2006 for Eclipse
4.2 I-Logix Rhapsody
I-Logix is one of the founding companies of the UML and a member of the OMG.
Although MDA standard is relatively new, I-Logix managed to incorporate the modeldriven approach into Rhapsody, with the help of MIA-Software MDA tool suite (MIA
stands for Model-In-Action). This section is organized as follows: an overview of
Rhapsody, results of MDA-support feature analysis of Rhapsody, description of the MIASoftware tool suite, and how Rhapsody makes use of it. The conclusion section, at the
end of the report, summarizes the evaluation results and concludes with recommendations
for software developers who may consider Rhapsody as their tool of choice.
4.2.1 Rhapsody Overview
Rhapsody developed by I-Logix is one of the market leading UML 2.0 Model-Driven
Development solutions because it is built around a series of enabling technologies
provides users the most effective means of producing systems and software intensive
designs. Rhapsody support of UML 2.0 is unparalleled and uniquely enables bridging the
functional and object oriented gap in one environment allowing a very flexible design
approach. Rhapsody has always focused on the needs of the embedded developer and
fully supported the concepts of MDA. For true effective Model-Driven Development,
Rhapsody creates a design environment that keeps you in constant communication with
-20-
the system's behavior through execution and graphical design. It also allows collaborative
and fully scalable infrastructure for a very cohesive team environment.
Embedded developers and their tools must focus on their specific needs in order to
maximize the benefits of MDA while meeting their special needs of real-time
performance, reliability and the specialized hardware control that often exists in their
environment. Rhapsody’s key enabling technologies are focused on the needs of the
embedded developer. It follows the concept of separating functionality and behavior from
implementation detail which enable embedded developers to get the most out of their
MDA process. Rhapsody claims to supports all of these important UML 2.0 concepts that
aid in creating a robust, complete and efficient PIM.
4.2.2 Rhapsody Evaluation
For the purpose of evaluation, Rhapsody 6.1 Developer Edition has undergone an
extensive MDA-compliance feature analysis. The results of that analysis are detailed here
and summarized in Table 7 in section 5.
MDA01 -Support for PIM
Rhapsody Score=2
Rhapsody has a set of predefined modeling frameworks with corresponding metamodels.
UML metamodel can serve as the basis for some of the PIM metamodels. Use Case,
Sequence, and State Chart diagrams, which are originally platform-independent, are
annotated to guide the transformation into platform specific models and/or generate code.
Rhapsody supports the definition of profiles, which extend modeling concepts with new
tags and properties. Using UML profiles, platform independent modeling can be
extended to model domain specific concepts. Profiles are graphically editable within
Rhapsody itself.
Rhapsody loses points here because it lacks clear separation between the platformindependent and the platform-specific models.
MDA02 -Support of PSM
Rhapsody Score=3
An advantage of Rhapsody is that it supports CORBA. Automatic IDL generation is the
most obvious aspect of CORBA support. CORBA IDL interfaces can then be
implemented by C, C++, or Java components.
Platform-specific information and code-generation directives are added to the PIM using
CG (code generation) properties, in order to direct the code generation engine.
A point against Rhapsody, however, is that, except for a few cases, PIM entities have
generally one-to-one to correspondence to code entities. There is no clear (graphical)
representation of the platform specific model. PSM is encoded directly in the generated
code.
-21-
MDA03 -Can Target Multiple PSM
Rhapsody Score=3
CORBA is the only commonly used PSM that is supported in Rhapsody. In addition to
CORBA, Rhapsody supports a number of legacy frameworks, such as Object eXecutable
Framework (OXF), and Interrupt Driven Framework (IDF).
Rhapsody also supports customizations of code generation rules. The Rule Composer tool
(which is actually the MIA-Generation rules editor), allows the association code
generation rules with built-in and user-defined profiles.
MDA04 -Model Integration
Rhapsody Score = 4
Rhapsody integrates different UML diagrams into a single model repository. For
example, classes defined in class diagrams are detailed in state-chart diagrams. Code
generators use this cohesive model to generate a single application spanning all
information available on different views of the model.
Figure 11.a: Method implementation is managed by the Rhapsody GUI
Figure 11.b: Round-tripping in Rhapsody
-22-
MDA05 -System Evolution
Rhapsody Score=4
As shown in Figure 11, method implementation can be developed within the model itself,
which provides for better management of code generation and system evolution. All
changes to the application can be performed within the Rhapsody GUI itself. Moreover,
Rhapsody supports round-tripping, which allows changes done to the generated code to
be reflected in the model in a consistent way. See Figure 11.b for an illustration.
MDA06 - Model Interoperability
Rhapsody Score=4
Thanks to the XMI toolkit, which is joint effort between I-Logix Inc. and SODIUS
Corporation, Rhapsody can import and export UML models in XMI. However, the
documentation states that only XMI 1.2 (UML 1.3) and prior versions are supported.
Rhapsody also allows importing Rose models, which is specifically useful because Rose
has been the most-widely used UML tool for the last few years.
MDA07 -Mappings are modeled
Rhapsody Score = 3
Rhapsody has C, C++, Ada and Java code-generation mappings defined. These mappings
are customizable using the Rule Composer editor, Figure 12. Nevertheless, we haven’t
been successful in defining a mapping from scratch
Figure 12: Rule Composer Editor (Mia-Generation)
MDA08 -Support for Managing Model Complexity
Rhapsody Score = 3
Rhapsody supports Zooming in and out object structures (Figure 13). It also supports
linking state diagrams to the classes they describe. This clears higher level diagrams from
many details, yet keeping details a click-away. We couldn't find an easy way in
-23-
Rhapsody 6.1 to allow zooming in and out relationships, such as associating dependency
links with a collaboration diagram.
Zoom out
Zoom in
Figure 13: Zooming in and out object structures
MDA09 –Correctness
Rhapsody Score=4
In addition to enforcement of metamodel static typing rules, Rhapsody defines a set of
built-in checks both for correctness and for completeness of model, Figure 14. Built-in
rules include platform-specific checks such as file name constraints, single-inheritance,
CORBA and COM-related constraints. It also includes platform independent checks such
as the constraint that a singleton-stereotyped class must have a multiplicity of one. A
model is automatically checked before code generation, but can also be selectively
checked upon user request.
Figure 14: Rhapsody built-in model checks
-24-
MDA10 –Expressivity
Rhapsody Score = 4
UML expresses PIM concepts and profiles add PSM information. While some profiles
are already built-in, user can define custom profiles to cope with the ever-changing
platform technologies.
M.DA11 -Patterns and Genericity
Rhapsody Score = 2
Rhapsody allows the definition of code generation patterns (usually called generics). The
Rule Composer can be used to define the templates or scripts used for generating code
corresponding to a specific profile tag or property.
Rhapsody GUI, however, doesn't help the designer employ existing patterns in a
graphical easy way. The user has to edit the tags and properties of each model element
manually to connect parts of the pattern.
MDA12 -Support for Refactoring
Rhapsody Score = 4
Rhapsody provides a reverse engineering tool. It has been successfully able to import a
given C++ source code into the corresponding UML model. Figure 15 illustrates how
classes, methods, attributes, and method implementations were recovered from code.
Figure 15: Result of Reverse Engineering
-25-
MDA13 -Intra-Model Mappings
Rhapsody Score=0
Rhapsody per se doesn't support model-to-model mappings. However, the underlying
engine suite has a devoted tool, Mia-Transformation, which fully supports model-tomodel mappings, including QVT language support. If this tool were added to Rhapsody,
it would have scored 4 on this metric.
MDA14 -Traceability
Rhapsody Score=1
Although the MIA-Generation engine generates a transformation log that allows the user
to trace the execution of different mapping scripts, Rhapsody doesn't expose this report.
MDA15 -Life Cycle
Rhapsody Score = 4
Rhapsody is a visual design tool for performing structural and systems modeling and
developing object-oriented embedded software. It enables you to perform analysis to
define and validate system requirements, design and specify the system architecture,
validate and simulate the model to perform detailed system testing, document the system
model by producing system specifications and generating application code.
MDA16 -Standardization
Rhapsody Score = 3
Supports UML 2.0, but only XMI 1.2 (i.e. can exchange only UML 1.3 models). Also the
emerging QVT standard is supported by the underlying MDA engine used by Rhapsody.
4.2.3 The MIA-Software Tool Suite
Although MIA-Software tool suite is described here as part of describing the Rhapsody
UML tool, Model-In-Action tools suite is a very powerful MDA engine worthy of
consideration. It is important to note that MIA-Software suite is not a modeling tool, but
rather an engine that performs mappings.
MIA-Metamodel
Generation
MIA-Generation
Metamodel
Repository
(Java)
MIA-Transformation
Code Generators
Model
Transformers
Figure 16: MIA-Software Tool Suite
-26-
The MIA-Software suite, illustrated below, is composed of three tools:
1. MIA-Metamodel Generation
 Compiles MOF-compliant metamodels into Java packages to subsequently
serve as metamodel definitions
 Metamodels are edited using MOF-compatible UML-design tool.
 Operation illustrated below
2. MIA-Generation
 Lets the user edit code generation rules for an input metamodel
 Executes code generation rules on input models to generate code
 Operation illustrated below
3. MIA-Transformation
 Lets the user edit model transformation rules from one metamodel to
another
 Executes the model transformation rules on input models to generate other
models
 Operation is illustrated in the figure below
Figure 17.b: MIA-Transformation
Figure 17.a: Mia-Generation
When used together with a UML modeling tool, these tools support a full-fledged MDAcompliant process.
4.2.4 Rhapsody and MIA-Tools
Rhapsody uses only the MIA-Generation engine, packaged by SODIUS into the
MDWorkbench. The Rules Composer and the Rules Compiler automate the processes of
defining and applying code generation mappings.
-27-
4.3 OptimalJ Developer Edition by intelliJ 4.0.00
OptimalJ is a MDA-support tool by Compuware that supports both model-to-model and
model-to-code transformations. Source model is modeled in UML and the target model is
generated as J2EE platform. OptimalJ is a model-driven, pattern based enterprise
application development environment, which accelerates the development, integration
and maintenance of J2EE applications. It specifically focuses on J2EE platform. The
patterns in OptimalJ facilitate reuse, leveraging pre-defined designs, structure and code,
and capture specific knowledge about the architectures, platforms and technologies to
help create reusable code.
Fig 18: Screen shot of Optimal J
An application in OptimalJ is developed in three sessions at the highest level. These
sessions are concurrent and described as below
 A Platform Independent model (PIM) also known as Domain model in OptimalJ.
 A Platform Dependent model (PSM) also known as Application model
 And finally the actual source code.
Here the transformations from PIM to PSM i.e. from domain to application model and
from PSM to program code have to be invoked by user explicitly.
Any change to PIM model can be percolated down to the PSM model and also the
modifications made to PSM model are reflected into the source code.
But the visa versa is not possible, architectural changes on the lower levels are not
reflected back to the top levels. This unique development is OptimalJ’s key and a
different approach as compared to standard IDE.
-28-
Features of OptimalJ
Rapid Enterprise Java Development
 In OptimalJ developers use to interact with a visual model of the application that
can either be imported from other modeling tools using the XMI or built from
scratch with the visual modeler.
 In addition to its model-based interfaces, the integrated development environment
based on the open-source IDE, Net Beans, provides a source editor, class browser,
form editor, and debugger to enable developers to view, modify, and customize
the generated application.
 Using this visual paradigm, developers are shielded from the complexity of
coding to the distributed J2EE development.
Dynamic Business Rules Implementation
 Once the basic application structure has been defined in the model, application
differentiation can be built-in using a flexible business rule editor.
 The business rules editor can define referential data constraints, which ensure data
integrity and consistency, and event condition rules that provide support for
conditional processing.
 Static rules are generated as Java code in the application, and dynamic rules are
stored in a rules database on the application server to allow for modification at
runtime
Pattern-Driven Application Generation
 OptimalJ can generate all the application code required for running an application.
To do this it first generates models for the Web (JSP), business logic (EJB), and
data tiers, which are then used to generate the actual Java code, business rules,
and data implementation scripts.
 The generated models and code are based on implementation templates called
patterns, which encapsulate knowledge and best practices for coding to the J2EE
specification and follow OMG standards
Active Synchronization of Models and Code
 OptimalJ provides live synchronization between the application models and the
Java code. Developers can make changes to applications during or after release
using the visual model, and the affected code will be regenerated automatically.
 The OptimalJ Source Editor identifies managed source code, business rule code,
and custom source code to accelerate understanding and enable you to make
modifications during development or after release of the software. This feature
really underlines one of the core benefits of OptimalJ, one that will become more
apparent as Java business applications reach their second and third iterations.
Integrated Deployment Environment
 OptimalJ automatically deploys to many of the leading J2EE production servers
including the fully integrated Compuware Optimal Server, offered as an option to
OptimalJ.
 OptimalJ also includes an open-source test environment that contains a Web
server and EJB container. The OptimalJ deployment packager automatically
-29-

deploys to this local environment, allowing developers to directly test as they
develop without worrying about the complexities of deployment.
In the time it would normally take to create the basic business design of an
application using a visual modeling tool, OptimalJ can finish coding the entire
application and deploy it
OptimalJ and MDA (Model Driven Architecture)
In this aspect, we will cover the main building blocks of the MDA-support tool, its main
approaches, solution to address MDA concepts and transformations. OptimalJ is an
exclusively MDA concept, and something that makes application development easy to a
great extend.
Pattern Support
In OptimalJ there are two levels of patterns for transformation
 One pattern is Technology Pattern
 Second one is Implementation pattern.
 Technology patterns are used to define the transformation from Domain model to
Application model (PIM to PSM)
 Implementation pattern corresponds to transformation between Application
Model and code (PSM to Code).
Fig 19: OptimalJ’s Pattern Support[UM04]
Patterns in OptimalJ are based on the proprietary Template Pattern Language (TPL).
Using this language one write own patterns for model transformation and code
transformation. OptimalJ provides very good support of predefined definition of
transformation for J2EE. From a simple Class model, that represents PIM, one could have
a running web-based J2EE application with basic functionality of add, update and delete
of entities defined in the Class model.
-30-
Model Driven Transformations:
Fig 20: OptimalJ MDA driven transformations [UM04]
OptimalJ supports 3 basic levels of models as Domain Model, Application Model and
Code Model.
The Domain model (PIM support)
Here in OptimalJ the domain model is divided into 2 sections:
 Class model – which describes the static structure of the application data.
 Service model – which states the behaviors .aspects.
One aspects of domain class model is every class must have primary key which is
unusual which is used for development of application database.
The domain class model displays UML 2.0 diagrams which is carried out via a graphical
editor. Most work is displayed out using explorer which is familiar tree style
representation.
 Class model covers the static structure of the system and application data whereas
service model is used to describe behavioral aspects.
 Class model consist of classes in the system and relationships between them, this
model is graphically displayed and is basis of other models. The structure of each
class is defined by its attributes, operations symbolizing behavior of class and
relationships are expressed as associations. One could define the associations
between classes in terms of multiplicity, generalization and composition.
 Every class in Class model must have a primary key defined for itself as this is
used in later used in creation of application’s database or schema. Service Model
is used to specify the system behavior in an implementation independent way
using concepts like Domain Views, Domain Service Attributes and Domain
Service Operations.
The domain model does not have any explicit references to end platform technology and
works at a high level of abstractions. But there are some implicit dependencies on the end
-31-
platform. For example we cannot use ‘Order’ as it is reserved word in SQL and same is
the case with Java keywords.
Fig 21: Screen shot of Domain model (PIM) diagrams
The application model (PSM support):
OptimalJ automatically transforms the Domain Model to the Application Model.
OptimalJ’s Application Model maps to Platform Specific Model (PSM) and focuses on
the targeted J2EE platform. The mapping and transformation from the Domain to
Application Model is conducted by the Technology Patterns.
PSM in OptimalJ is represented as the Application Model and it lies between domain
model and code model.
-32-
Fig 22: Screen shot of Application model
1. Presentation (Web) model - contains the information required to generate a web
front-end for the application. Presentation model contains the presentation logic
and interface of the system, as OptimalJ only supports the J2EE platform this
presentation model could be of JSP, Struts, J2SE applet or Swing.
Fig 23: Screen shot of Web model
-33-
Fig 24: Screen shot of EJB model
Fig 25: Screen shot of DBMS model
-34-
2. Business Logic (EJB) model – The Enterprise Java Bean partial reflection of the
complexity of eventual code. a middleware layer that deals with, for example,
transactions, security, persistency and scalability. . Business model contains the
business logic of the application and it is represented in EJB or Data Access
Objects (DOA).
3. Database (DBMS) model – used to model and map all the relevant database
definitions. The Database model supports DBMS elements like schemas, tables
and keys. DBMS model is third model in the Application Model and its represent
the database schema of the application
The application model provides access to an abstract view of the end technology platform
to the user and the various setting at this level.
The code model
Using the implementation pattern the user explicitly invokes the ‘generate code’ code
option, which generates all the relevant Java, JSP, XML files and other necessary for a
J2EE application. The construction of code from simple domain class model within
matters of minutes is really amazing. Also the ability to alter and make changes to model
is handled will by OptimalJ.
OptimalJ uses Jakarta Struts Framework which is open source in its J2EE server. The
code is easy to understand and modify. User can also implements feature which are not
available in the application model later on. In order to edit the code by user and keep the
integrity of changes made in both the domain and applications models are reflected in the
code, OptimalJ divides the files into free and guarded blocks. Guarded blocks are
displayed with a blue background while the free blocks are in white background. User is
unable to make any modification to guarded blocks.
Fig 26: Screen shot of Code generated
-35-
Of course the user can make changes to the guarded blocks but such changes will be
destroyed when the code is updated from the application model.
OptimalJ provides set of tools for testing and debugging of generated code and
application. One could test the functionality of the application with in the OptimalJ
environment. For easy deployment OptimalJ provides the facility of configuration of
application servers, it supports these application servers JBoss, Weblogic, IBM
Websphere, Oracle AS and Sun JSAS.
Working application
The result of generating code that follows the pre-defined code and architectural
guidelines is a working application that you can run within minutes. This includes
adhering to the business rules as specified in the domain class model and the coding
“standards” as specified in the transformations.
Fig 27: Screen shot of Application
-36-
MDA Assessment of OptimalJ
OptimalJ support for MDA is very positive, based on what we've seen of the MOF
Repository and TPL.
Summarizing what we've seen of the product so far, OptimalJ provides:

Very Good Explorer and Diagrams - the Explorer provides powerful navigation
for the Meta-Model classes and the UML diagrams give good visual feedback on
the relationships between these classes.

Good Product Integration - integrates very well with Netbeans, Tomcat, JBoss,
and Axis.

Sufficient Template Support - TPL provides a fully functional, easy-to-use and
intuitive template and scripting environment. However, the TPL development
environment would benefit from better integration with the Repository API. This
feature is forthcoming in the next release of OJ.

Rich Repository API - provides an excellent implementation of the MOF using the
Netbeans MDR and adds a substantial number of MOF classes of its own to
facilitate the creation of MDA transformations.

Strong Performance - makes very good use of memory and performs difficult
tasks, such as the creation of large diagrams, with very good performance.
Availability
The last version of OptimalJ is version 4.0 and it has released three editions. The
information about the availability and prices of OptimalJ is taken from the web-site of
Compuware, as follows:
 OptimalJ 4.0 Developer Edition: Licenses support the development, integration
and deployment of J2EE applications. The price for this edition is $1,900.
 OptimalJ 4.0 Professional Edition: Licenses support the modeling, development,
integration and deployment of J2EE applications. The actual price of this edition
is $5,000.
 OptimalJ 4.0 Architecture Edition: Licenses includes all features of Professional
Edition plus support for creating, extending, applying and exchanging software
design patterns using the OptimalJ pattern editor. The current price for this edition
is $10,000.00
Evaluation of OptimalJ
This section will use the previously described guidelines to show how the tool ranks with
each guideline for supporting MDA. The evaluation is shown in a tabular format.
-37-
Criteria
Description
Evaluation
Rank
MDA01
Support for PIMs
Full support for PSM. Strong
support with domain model
which contains class models
(static structure & service
models). It restricts reserved
names and if used lead to invalid
PSM. Has ready to use
metamodels.
4
MDA02
Support for PSMs
Strong support with application
model, abstraction over J2EE
implementation and explicitly
divided into web sub-models,
bean and database.
4
MDA03
Can Target Multiple PSMs
Targets only one PSM. OptimalJ
largely targets J2EE as a
Platform
specific
domain.
Cannot edit metamodels.
1
MDA04
Model Integration
OptimalJ supports for model
integration e.g. the class and
service part of the domain model
in the transformation into the
application model. Integrated
relationship across diagrams.
2
MDA05
System Evolution
3
MDA06
Model Interoperability
Strong support as changes in the
domain or app. models can be
filtered down to lower levels.
The transformation has to be
redone in order for the changes
to be reflected in the PSM or
code model.
OptimalJ
uses
UML 2.0
notations and can import can
import/export XMI models
MDA07
Mappings are modeled
There are mappings
and
mapping are in form of models.
So users have limited access to
models
using
Template
programming Language
2
-38-
3
MDA08
Support for Managing Model OptimalJ using a fixed point of
Complexity
abstraction can represent most
parts of both the domain and
application
models
diagrammatically. Zooming in
and out Object Structures
.
It enforces well-formed rules on
both the app. and domain
models. Prevent errors by
disallowing reserved words
2
MDA09
Correctness
MDA10
Expressivity
Both domain and application
models provide the expected
levels of expressivity at their
levels of abstractions also
expressivity using UML
4
MDA11
Patterns
Here
when
converting
application model into code,
OptimalJ generates a number of
patterns in the resulting code.
3
MDA12
Support for Refactoring
The code model is divided into
‘free’ and ‘guarded’ blocks. By
this method, changes inherit.
Changes in upper layer only
affect guarded part of code.
4
MDA13
Intra-Model Mappings
Support, changes in the database
tier is automatically reflected in
the EJB tier. Also domain
service model is created from
domain class model.
3
MDA14
Traceability
Limited support for tracing. The
execution of mappings from
domain to application model
creates reference from the latter
to the former. Disallow tracing
of code generating mappings
1
MDA15
Lifecycle
OptimalJ covers virtually all the
aspects of the system life cycle
including
analysis,
design,
4
-39-
3
coding,
debugging,
project
organization,
testing
and
deployment.
MDA16
Standardization
It stores all the models in a MOF
repository. It uses standard UML
2.0
notations
and
can
import/export XMI
4
Table 4: Evaluation Table for OptimalJ
4.4 MagicDraw UML 10.0
MagicDraw [CD] is a visual UML modeling and CASE tool with teamwork support.
designed for Business Analysts, Software Analysts, Programmers, QA Engineers, and
Documentation Writers. MagicDraw provides full UML support for the 2.0 metamodel
and notation and import of the UML 1.4 meta-model. It manages a true model
representation which it stores as one large XML flat file. This is a dynamic and versatile
development tool that facilitates analysis and design of Object Oriented (OO) systems
and databases. It supports a custom OO model generator and provides the industry's best
code engineering mechanism (with full round-trip support for J2EE, C#, C++, CORBA
IDL programming languages, .NET, XML Schema, WSDL), as well as database schema
modeling, DDL generation and reverse engineering facilities. Model elements can be
drawn on multiple diagrams carrying their content into these new contexts. Some model
elements can be displayed with varying degree of detail depending on context. For
example, class can be shown in different class diagrams with some, none, or all attributes
or operations showing, depending on what each class diagram is attempting to convey.
MagicDraw also has a reporting capability which appears to externalize the report
creation as an XML file containing the options and an XSL file specifying the report
construction. This tool is suited for a wide variety of systems including real-time,
client/server and distributed n-tier application design. MagicDraw runs on a wide variety
of operating systems, everywhere where Java 1.4 or 1.5 is supported.
We will now look into the features of MagicDraw that make it a powerful UML
modeling tool and the support is provides towards MDA ( Model Driven Architecture).
The features [NM] of MagicDraw have been described below:

Full support for UML 2.0: MagicDraw provides full support for UML 2.0 which
include the class, use case communication, sequence, state, activity,
implementation, package, component, composite structure, deployment diagrams.
MagicDraw makes it easy to model all aspects of your system: requirements,
static structure, deployment structure, activities, states, detailed action sequences,
and much more.
-40-

Support of Extendable UML 2.0. : Allows the analyst or the designer to add
some new model elements, (for instance specific class type for GUI components)
he or she may extend UML by adding its own stereotypes, constraints, tagged
values and even new appearance of the model element in the diagram (gif images
can be attached to the specific stereotypes for a different display). Different fill
colors and fonts may be used for this purpose as well. Custom appearance for
diagram elements can be defined using SVG or bitmap images.

Language Specific UML Syntax Checker: Before the Code Generation,
MagicDraw will check the correctness of the UML model and prompt you for
changes, before any code gets generated.
Pattern Generator. MagicDraw allows Design patterns to be extendable. From
version 6.0 all patterns are extendable. We can write your own patters with Java
or JPython also.
Code Generation. Once model is created, it's time to begin coding. With
MagicDraw's support of Java, C#, C++, and CORBA IDL, generating code
frameworks becomes an efficient, streamlined process. And since MagicDraw
also enables script creation for all major databases, database structure design has
never been so easy.
Code Engineering Sets. Classes might be grouped together with their
components into collections called "code engineering sets". The code engineering
set helps keep classes and source code synchronized. We may reverse engineer or
generate the code for a whole set at once. Also we may specify different
properties for each code engineering set: location of the source code files and
code generation properties.
Round-trip Engineering. Besides the source code generation and reverse
engineering, MagicDraw allows parallel changes to the both source code and
UML model. With the help of round-trip engineering technique, MagicDraw
synchronizes those changes - new methods and attributes in the source code are
added to the UML model and new items in the UML to the source code.
Integration with leading Java IDEs. MagicDraw can be integrated with various
development environments like Eclipse, IBM WSAD and RAD, Borland
JBuilder, IntelliJ IDEA, NetBeans, Sun Java Studio in a totally synchronized
manner.
Source Code Reverse Engineering. If we have lots of unknown source code and
want to get an idea what's in there, the source code can be reverse engineered. We
may get an UML model and then generate class diagram from Java, EJB, Java
bytecode, C#, CIL (MSIL), C++ or CORBA IDL source code.
Model Analysis Facilities. Consider a huge OO model with lots of dependencies,
large class hierarchies and a change in a method B in a class A, other elements in
the model will be influenced by this change, With MagicDraw we may select any
model element and find out all other elements (classes, packages, etc.) that
depends on it, or we may go in the opposite direction, select an element and ask
for a list of model elements on which your selected element is dependent on. The







-41-



dependency criteria also can be customized, it may be any combination of the
following: association, inheritance, or realization relationship, class used as
attribute type or operation parameter. It can find out all subclasses of the selected
class and generate a new class diagram that shows the whole class hierarchy of
derived classes. MagicDraw generates a package dependency diagram. A list of
packages is analyzed upon dependencies between contained classes.
Test Case Modeling. Quality assurance engineer usually uses automated testing
tools. Nevertheless he or she needs to define a strategy for structural and
functional tests. Use case diagram is a tool for the test modeling. JUnit pattern
will create a framework for test classes.
Eliminates tedious document preparation with automatic report generation.
Use MagicDraw's automatic report generation engine to quickly produce
comprehensive, professional requirements, software design documentation, and
other types of reports in HTML, PDF, and RTF formats. MagicDraw UML
generates standard artifacts that match your software development process. With
Jython they can easily customized to fit the internal standards.
Portability. Independent of the hardware and the OS the developers have, it is
very likely that MagicDraw can run on it. Windows 98/ME/NT/2000/XP, Solaris,
Linux, and Mac OS X - to name a few.
Below are a series of snapshots of MagicDraw 10.0 for UML
-42-
Figure 28 : A General View of MagicDraw10.0 showing connection of components
-43-
Figure 29: Business Profile Model diagram showing ordering of events
Figure 30: Shows the Implementation diagram
-44-
Figure 31: Shows The visual model differencing
Figure 32: Shows the report generation wizard
-45-
MagicDraw and MDA (Model Driven Architecture)
In this section we now will examine the various building blocks and the MDA solutions
provided by MagicDraw and the various model driven transformations and other
concepts. MagicDraw provides a set of Model Driven Architecture solutions [MD] [DT]
with the various frameworks, model to model transformations, PIM to PSM mappings,
code engineering and the Business profiles. We will discuss these approaches in this
report.
MagicDraw is one of the most comprehensive UML modeling tools in the industry today,
One of the things that takes it to that level is the comprehensive documentation that is
provided regarding its tools, transformations, patterns and the roundtrip engineering.
Each one of the above has been explained in the documentation is a very comprehensive
manner.
Data Modeling
There are various ways in which data modeling can be achieved in MagicDraw UML. It
allows us to integrate data models with the business and the object oriented models. UML
profile for Data Definition Language (DDL) enables mapping of relational concepts to
UML elements. MagicDraw provides us a tool for generating and reversing DDL Scripts,
retrieving
Database
Structure
(Schema)
via
JDBC.
Another data modeling powerful tool are the modeling transformations in both Platform
Independent Model (PIM) to Platform Specific Model (PSM) and PSM to PIM:





UML to Generic DDL
DDL to UML
UML to Oracle DDL
UML to XML Schema
XML Schema to UML
-46-
Figure 33: Shows the concept of data modeling used in MagicDraw
Software Modeling
MagicDraw provides full support for UML 2.0 metamodel, including class, use case,
communication, sequence, state, activity, implementation, package, component,
composite structure, and deployment diagrams. In addition, support is also provided for
explicit
UML
profiles
and
custom
diagrams.
It provides a means for architectural view modeling: to define system and software
architecture in all 4+1 views, and at different abstraction levels.
Figure 34: Shows the various abstraction levels
Code Engineering




Java, C# and C++ round-trip engineering.
Java bytecode (including zip and jar files), CIL (MSIL) reverse engineering.
EJB, CORBA IDL, XML Schema, WSDL, JDBC, DB schema reverse
engineering and code generation.
MagicDraw automatically generates the model parts in accordance with
established design patterns: GoF, Java, EJB, JUnit, XML Schema, WSDL,
CORBA IDL, and any of the other customizable patterns.
-47-
Figure 35: Shows the Code Engineering Wizard
Evaluation of MagicDraw 10.0 for UML 2.0
This section will use the previously described guidelines to show how the tool ranks with
each guideline for supporting MDA. The evaluation is shown in a tabular format.
Criteria
Description
Evaluation
Rank
Tool allows Business Process
Models (BPM) to be created at a
very abstract level without the
details of implementation
Supports creation of various
PSMs J2EE, EJB, etc. specific
projects
Multiple PSMs are supported by
MagicDraw like Java, C++,C#,
EJB, DDL.
Various diagrams such as the
class, sequence, state are
provided
to
model
the
application.
Transformations have to be
performed again in real time so
as to the changes made in the
code or model can be reflected in
the output code or model.
Models can be exported using
the standard XMI documentation
for inter-tool operability
Model to model mappings are
supported.
3
4
MDA01
Support for PIMs
MDA02
Support for PSMs
MDA03
Can Target Multiple PSMs
MDA04
Model Integration
MDA05
System Evolution
MDA06
Model Interoperability
MDA07
Mappings are modeled
MDA08
Support for Managing Model Various viewpoint diagrams are
Complexity
provided to model the various
levels of abstractions and more
complex applications in an
orderly manner. However the
component diagrams are used to
show the various methods and
classes.
-48-
3
4
4
2
3
2
MDA09
Correctness
Provides the Language Specific
Syntax Checker which checks
the UML code before code
generation.
2
MDA10
Expressivity
High levels of abstraction are
supported in PIMs
4
MDA11
Patterns
3
MDA12
Support for Refactoring
MDA13
Intra-Model Mappings
Pattern are extendable and a
patter wizard is provided for the
recognition and creation of
patterns..
Refactoring
allows
us
improving the code without
changing the semantics of the
model. MagicDraw provides
support for refactoring and thus
helps us improve the code
without changing the behavior of
the model.
Supports built in model to model
mappings.
MDA14
Traceability
2
MDA15
Lifecycle
MDA16
Standardization
Traceability is supported in
MagicDraw during model to
model transformations with the
help of trace files.
MagicDraw plays a role in the
complete life cycle of a system,
which
includes
design,
implementation, debugging and
testing, and finally deployment.
However the final deployment
phase has to undergo some
improvement for it to become a
complete tool.
Standard UML 2.0 notations and
meta models are used with XMI
as a standard to export and
import documents.
Table 5. Evaluation Table for MagicDraw UML 10.0
-49-
3
3
3
3
5. Summary of Results
In this section we summarize the results of MDA tool evaluation by comparing the scores
received by each tools. Table 6 shows the scores each tool received for each of the
features without taking into consideration the weight of each criterion.
Together
3
2
1
4
1
4
4
2
4
3
4
4
0
2
4
4
MDA01
MDA02
MDA03
MDA04
MDA05
MDA06
MDA07
MDA08
MDA09
MDA10
MDA11
MDA12
MDA13
MDA14
MDA15
MDA16
Rhapsody
2
3
3
4
4
4
3
3
4
4
0
4
1
4
4
3
OptimalJ
4
4
1
2
3
3
2
2
3
4
3
4
3
1
4
4
MagicDraw
3
3
4
4
2
3
2
4
2
4
3
3
3
2
3
3
Table 6: Scores without Weights
Figure 36 is a graphical representation of the scores without weights for each feature.
Features have been grouped by level of importance. The first five, MDA 01, MDA 02,
MDA 03, MDA 04 and MDA 07 are critical. Followed by 6 recommended features,
namely, MDA 05, MDA 06, MDA 10, MDA 12, MDA 13, and MDA 16. And finally 5
optional features, MDA 08, MDA 09, MDA 11, MDA 14, and MDA 15.
4
3
Together
Rhapsody
2
OptimalJ
MagicDraw
1
A1
5
A1
4
M
D
A1
1
M
D
M
D
A0
9
A0
8
M
D
M
D
A1
6
A1
3
M
D
M
D
A1
2
M
D
A1
0
A0
6
M
D
M
D
A0
5
A0
7
M
D
M
D
A0
4
A0
3
M
D
M
D
A0
2
M
D
M
D
A0
1
0
Figure 36: Tool Comparison Chart without Weights
Table 6 and Figure 36 are useful in comparing how each tool support each of the features
regardless of the relative importance of each feature. In order to make better calculations
we used weighted feature scores, based on the weighting scheme described in Table 2.
The graph in Figure 37 shows the result of weighted comparison of tools.
-50-
MagicDraw
OptimalJ
Critical
Recommended
Rhapsody
Optional
Together
0
50
100
150
Figure 37: Tool Comparison Chart with Weights
6. Conclusions and Future Work
MDA promises to revolutionize the software engineering discipline. It unifies the
developer's activity of building models and writing code in a single integrated process.
MDA increases productivity and allows platform independent modeling without
worrying about the implementation platform. With an MDA tool, it is possible that the
same PIM be transformed into more than one PSM for different platforms, and changes
to platform technology effects the automated mappings, thus keeping the manuallydeveloped PIM models valid.
The tool evaluation conducted in this project showed varying levels of MDA support in
today's market. Some tools which claim to support MDA miss critical MDA features.
Together and Optimal J excel in PIM modeling, but miss supporting different PSM and
PIM-to-PSM mappings. Rhapsody mixes PIM with PSM, missing one main benefit of
MDA, but is saved by its wide support of multiple embedded platforms. MagicDraw
documentation emphasizes PIM modeling without enough documentation of PSM.
The comparison of tool evaluation results shows that the total weighted scores are quite
similar. That's basically because we already excluded tools which were below a certain
standard. MagicDraw 10.0 scores best, closely followed by Rhapsody. OptimalJ and
Together support of critical features is considerably less that MagicDraw and Rhapsody.
OptimalJ’s excellent support of recommended features, however, gives it an overall score
better than Together.
-51-
We can go a step further and suggest one tool over the rest based on their individual
scores for a specific functionality. For example, Together scored higher than any other
tool for transformation support (MDA07) and pattern support (MDA11). Therefore, a
developer looking to meet these specific requirements in a tool should choose Together
Architect 2006 for Eclipse. OptimalJ received the highest score for PIM (MDA01) and
PSM (MDA02) support, thus we would suggest OptimalJ for complete platform
independent and dependent model support. Similarly, when a tool has to conform fully to
system evolution (MDA05) and model interoperability (MDA06) requirements,
Rhapsody would be the ideal choice and MagicDraw should be first choice when support
for multiple PSMs (MDA03) and model complexity (MDA08) is a high priority.
MDA support is a growing practice in the UML modeling tool world. MDA engines like
MIA-Software tool suite save tool vendors time and effort by providing standards-based
MOF implementation. It is expected that most UML tools will sooner or later support
MDA because of the various benefits mentioned before.
An important step following this project is to develop an MDA certification program,
where evaluation criteria similar to the one used here should be thoroughly detailed. We
would recommend that the certification program define more than one aspect of
certification such as the clear separation of PIM and PSM modeling activities, the
automated mappings, and the customizable/extensible metamodels.
An extension to our project could be a comparison of Query View Transformation (QVT)
with legacy transformation languages and templates of current existing MDA tools in the
market. A research could be initiated on OMG’s QVT language which would be
complemented with a comparison with current transformation languages supported by
various MDA compliant tools.
Another possible future idea for a research project could be designing and implementing
a standard UML Profile and the corresponding mapping for a specific platform like .NET
or J2EE. UML Profiles could also be investigated and implemented for some specific
domain like Healthcare, Aviation etc.
A further step in our research line is to focus on EDOC as a set of MDA profiles
specifically designed to help enterprise application development. Although too few tools,
like Component-X, support EDOC so far, but we can evaluate readiness of tools for
incorporating the EDOC standard.
-52-
Appendix A: UML 1.x and MDA
A.1 Advantages
a) Separation of Abstract Syntax from Concrete Syntax
From a modeling viewpoint, such as UML, concrete syntax implies the class diagrams,
sequence diagrams, use cases which can be used to graphically represent a particular
application. Meanwhile, abstract syntax is the formal model of UML that defines the
concepts that modelers use to graphically represent a software product. Therefore,
abstract syntax is the metamodel or model of the model. This is a big advantage because
from an MDA standpoint the semantics or properties of a model matter more than the
layout of the graphical representation.
b) Enabling Extensibility
Another requirement of MDA is the need for specialized languages for various systems
which supports the specifications of the particular system. This is achieved in UML by
the highly extensive and specialized languages known as UML profiles. When we talk
about profiles, we also have to have mappings which indicate how to translate the
specialized profiles into something that is relevant to the system that the profile defines.
For instance, the UML profile for object computing will require mapping for translation
for EJB, J2EE, .NET, CORBA, etc.
UML profiling can also create profiles or specialized languages for platform independent
models which is also a big requirement for MDA
c) Supports platform-independent models
By platform-independent, we imply that the model is independent of data formatting
technologies such as XML DTD and XML Schema, independent of languages such as
JAVA, C++, and Visual Basic, independent of distributed component technologies such
as J2EE, CORBA, and .NET.
UML raises the level of abstraction by separating the semantics from implementation.
For example it can specify the relationships between classes without going into the detail
of implementation.
d) Open Standard
The benefit of having UML governed by OMG which is a standards organization is that it
is not a proprietary technology making it available for developers for personal use.
Developers can create custom plug-ins for UML to be used in their own custom
environment and also use their custom plug-ins or modeling framework which could be
-53-
used to represent the security aspect, together with modeling framework designed by
other developers, which could represent several other aspects of the application.
A.2 Disadvantages of using UML 1.x:
a) Not enough support for component based modeling
In UML 1.x, the notion of components is very clear. It is possible to create very basic
UML profiles for components in UML although the results of doing so are not very
satisfactory.
b) UML and MOF are not in sync
UML 1.x and MOF are slightly out of sync which causes problems for developers who
are trying to building tools that support MDA based on these two standards.
Appendix B: 4. Other Enterprise Architectures
The world seemed to have been divided on the basis of frameworks and architectures,
with each of the companies modeling each one of them and trying to implement them in
the various applications. The major issue that came up from all these things was that the
mapping from one application to another was a very difficult task and thus the software
industry became a world full of various kinds of architectures and frameworks
functioning independently all together with hardly any interaction with each other.
OMG’s Model Driven Architecture (MDA) is a standards-based approach to system
development, which increases the power of models in that work. It is model-driven
because it provides a means for using models to direct the course of understanding,
design, construction, deployment, operation, maintenance and modification. An MDA
approach starts with the well-known and long established idea of separating the
specification of the business functionality of a system from the details of the way that
system uses the capabilities of its underlying platform technology to achieve that
functionality. An MDA approach is independent of development methodologies as well
as technology. This separation of business functionality from computing technology and
methodology preserves a company’s core software assets in the constantly changing
world of information technology.
B.1 TOGAF Model
One of the most important architecture model that works in tandem with MDA for
enterprise applications is the TOGAF Model.
TOGAF is a “detailed method and a set of supporting tools - for developing an enterprise
architecture.” The TOGAF Architecture Development Method (ADM) explains how to
derive an organization-specific enterprise architecture that addresses business
requirements. The ADM provides a reliable, proven way of developing the architecture;
-54-
architecture views which enable the architect to ensure that a complex set of requirements
are adequately addressed; linkages to practical case studies; and guidelines on tools for
architecture development [OG].
Some other frameworks that have been used to model various Enterprise applications are
given below:
B.2 IDEF (for Integrated Definition)
This is a framework that started in the 1970’s and consists of a group of modeling
methods that can be used to describe operations in an enterprise. IDEF was a creation of
the United States Air Force and is now being developed by Knowledge Based Systems.
Originally developed for the manufacturing environment, IDEF methods have been
adapted for wider use and for software development in general.
IDEF consists of sixteen methods, from IDEF0 to IDEF14 (and including IDEF1X), are
each designed to capture a particular type of information through modeling processes.
IDEF methods are used to create graphical representations of various systems, analyze
the model, create a model of a desired version of the system, and to aid in the transition
from one to the other [ID] [DO].
B.3 The Zachman Framework
It is a matrix of 36 cells covering the Who, What, Where, When, Why, and How
questions of an enterprise. The enterprise is then split that into six perspectives, starting at
the highest level of business abstraction going all the way down to implementation. Such
objects or descriptions of architectural representations are usually referred to as Artifacts.
The framework can contain global plans as well as technical details, lists and charts. Any
appropriate approach, standard, role, method or technique may be placed in it.
It has been looked at as a framework for building computer systems; The Zachman
Framework is actually a classification scheme for descriptive representations of the
enterprise as a whole, irrespective of its use of computers. Zachman works with many
users and vendors to promote the use of enterprise architecture [DO] [ZF].
-55-
Figure B.1: Explains the detailed concept of The Zachman Framework for
Enterprise
Architecture [ZF] [DO]
B.4 C4ISR
Command, Control, Communications, Computers, Intelligence, Surveillance, and
Reconnaissance was started in 1995 by the Assistant Secretary of Defense for Command,
Control, Communications, and Intelligence (ASD, C31) formed the C4I Integration
Support Activity (CISA) to develop a unified approach for development and evaluation
of information and architectures. CISA is developing and coordinating a common set of
Architecture terms and Definitions, and supporting the working group that is developing
the Standard Data Element-Based Automated Architecture Support Environment and the
Automated Architecture Tool Suite [DO] [EA].
B.5 The Treasury Enterprise Architecture Framework (TEAF)
It was an architectural framework that was developed by the Department of the Treasury
in response to a number of government directives, including The Information Technology
Management Reform Act (ITMRA) of 1996 ("Clinger-Cohen Act") .The Government
Performance and Results Act (GPRA) of 1993. The Federal Enterprise Architecture
Framework (FEAF) of 1999.The purpose of the TEAF is to provide a framework for the
-56-
Treasury and its bureaus to produce their enterprise architectures .An enterprise
architecture offers important benefits to an agency, capturing information needed for
planning and decision making and providing high-level views to help communicate the
complexity of large systems [DO] [EA].
Appendix C: Other MDA Tools
This appendix describes other tools that we came across during the course of our project.
The reason why each of them was excluded from the evaluation process is briefly
explained.
C.1 OpenMDX: An Advanced MDA Framework
According to their website [OMD], "OpenMDX is an advanced implementation of the
OMG Model Driven Architecture (MDA) initiative. OpenMDX is an industrial-strength,
model-driven runtime engine, open, and framework for PIMs." OpenMDX claims that
unlike most commercial tools, it does not implement the generative PIM-to-PSMmapping approach. Instead, OpenMDX provides a generic, distributed object engine
which serves as a PIM platform. Business logic here is added as plug-ins.
OpenMDX claims to follows the model-driven architecture (MDA) approach which they
summarize as "The model is the implementation.” OpenMDX supports the J2EE
platform. Also it makes no use of features which are not absolutely necessary and makes
the framework open and pluggable wherever possible.
The key benefits of OpenMDX are Open, extremely flexible framework for the
integration existing and new applications and support of the MDA standards. It offers a
wide-range of patterns, prefabricated add-ons and plug-ins offering a wide range of
deployment scenarios. OpenMDX supports component-oriented, multi-tier application
architectures which is open for multi-party software development process.
The first and foremost reason for not selecting OpenMDX is that it is an MDA engine
rather than a UML modeling tool. It is a plug-in and needs a specific environment i.e.
apache tomcat, or net ants to be configured in a specific manner which is a complicated
procedure. The setup of such a modeling environment was infeasible given the project
time constraint.
C.2 ExecutableUML (xUML)
The xUML [EU] process developed by Kennedy Carter involves the creation of platform
independent. Executable UML model with the UML diagrams being supported by the
action semantics-compliant Action Specification Language (ASL). The resulting model
can be independently debugged, executed, viewed and tested. Multiple Executable UML
models can be assembled together to form complex systems with the mappings between
models.
-57-
Both the individual executable models and multi-model assemblies can then be translated
into target implementations. The execution rules of the xUML formalism mean that the
same models can be translated into a wide variety of target architectures without changes
to the models. A cornerstone of the translation approach is that the mappings to target
implementations are themselves expressed using executable Models. These translation
models are then used to code generate a code generator for the target system architecture.
The xUML process embodies these distinctive characteristics of being precise, complete
Models that can be subjected to rigorous testing by simulation having simple notations,
using the Unified Modeling Language organized into a coherent set of layers. In xUML,
usable models which can be utilized by system designers and coders without the need for
unreliable "interpretation" of the meaning of the models and also Large-Scale Reuse, in
which entire sets of classes are reused as a single component.
xUML was not included in the evaluation because the available free version is very
limited, only includes the simulator iUML, and does not fully support the MDA concepts
as compared to other leading tools.
C.3 Component-X by Data Access Technologies
Component-X seems to be the official EDOC tool. No other tool has been found so far to
support the relatively new EDOC standard out of the box.
Component X is based upon open standards to become the component model for XML
web services. Component-X provides with CCA, a triple standards alignment with
ebXML, EDOC and EAI. EDOC provides the basis for global enterprise computing,
integrating the information system with events and information which has been
implemented in Component-X. Component-X and the EDOC Component Collaboration
Architecture are part of the UML family of languages. Component X solves the problem
of developing integrating applications across platforms, across technologies, across
Internet, across technology generation and across the enterprise. Component-X is based
on the OMG EDOC standard for enterprise modeling and implements the Component
Collaboration Architecture defined in EDOC. Components from all sources like
computation, networking, including native Java covering database access, networking,
computation, and logic - together with XML definitions, web services, and other
composite components can be assembled into business domain components using a dragand-drop assembly and configuration using Component-X.
Although Component-X was recommended by professionals as an EDOC-compliant tool,
our attempts to obtain an evaluation copy were unsuccessful.
C.4 The TAU Generation2 Approach to MDA
The TAU Generation2 is model driven approach to software development which is based
on architectural blueprint languages such as UML 2.0 to substantially improve software
-58-
productivity and quality. The approach is compatible with MDA initiative, and takes
advantage of its second-generation MDA standards, such as UML 2.0 and the UML 2.0
Profile for Testing. TAU Generation2 is a family of model-centric and role-based tools
using UML 2.0 standards. TAU Generation2 can automate the transformation of a
Platform Independent Model of requirements into a Platform Specific Models that can
generate production quality code and test scripts.
Our attempts to contact Telelogic to obtain an evaluation copy of TAU G2 were not
returned and thus TAU G2 was also excluded from the evaluation.
Appendix D. Project Schedule and Task Assignment
In the early stages of the semester, our goal for the project was to do a survey on EDOC
and its various components such as Enterprise Collaboration Architecture (ECA),
patterns profile, and platform dependent profiles. During the first few weeks, we
familiarized ourselves with the concepts of MDA, EDOC and ODP-RM. We inspected
the EDOC specifications with the objective of evaluating its effectiveness as an enterprise
development framework. Our plan then was to get a sound understanding of EDOC
concepts and apply them to modeling an enterprise application.
After the proposal and first presentation, our group realized that in order to understand
EDOC, we have to step back and first look first at the larger MDA concept in depth. We
still had the same objective but now with more focus on the MDA background of EDOC.
At the same time, we started looking for tools that support EDOC, and as soon as we
realized that too few tools already implemented this relatively new standard, we decided
to switch our focus to MDA compliant tools, and to evaluate their usefulness for
enterprise application development.
Figure 19 displays the timeline we have developed for this project as well as the
component-wise breakdown of the project into individual tasks. Our team has focused on
the theory and background of MDA. The scope of the project changed significantly after
our initial presentation, and was settled by the midterm report on evaluating MDAcompliance of the UML modeling tools available in the market.
The tasks were divided among team members as shown in Figure D.1. During the first
stage, Sep. 19 – Oct. 21, Saleh was responsible for surveying and summarizing basic
concepts and background information about MDA, MOF and EDOC, Amit was gathering
information on the role of UML, the part it plays in the concepts of MDA and what is
new in UML 2.0, Keyur was assigned the task of identifying a list of UML modeling
tools that support MDA to be later evaluated, and finally Sabhay was assigned the task of
surveying alternative enterprise modeling architectures other than EDOC/MDA.
-59-
Stage 1: Conception and Background (Sep. 19 – Oct. 21)
Introduction to
MDA, MOF, and
EDOC
(Saleh)
Role of UML in
MDA
(Amit)
MDA supported
tools
(Keyur)
Relevant
enterprise
architectures
(Sabhay)
Stage 2: Criteria/Guidelines for evaluation of tools: (Oct 22 – Nov 4)
Develop and finalize the criteria on how the different tools will be evaluated
(Team work)
Stage 3: Analysis and Evaluation of tools (Nov 4 – Nov 27)
Together
Architect 2006
for Eclipse
(Amit)
Logix Rhapsody
6.1 Developer
Edition
(Saleh)
OptimalJ
Developer
Edition 4.0.00
(Keyur)
MagicDraw
UML 10.0
(Sabhay)
Stage 4: Future Outlook and Delivery: Final Report (Nov. 28 – Dec. 4)
(Merge reports generated in step 3 into a final report)
Figure D.1: Timeline and Task Distribution
The main task during the second stage of the project, as shown in Figure D.1, was to
agree upon a tool evaluation approach, criteria and scheme, to be later used to evaluate
each MDA tools. The next two weeks were utilized for researching existing work on that
point and detailing the guidelines for the evaluation of MDA support tools. This stage
was totally a team collaborative effort.
Stage 3 describes the delegation of one tool, which passes our initial inspection, to each
team member for further evaluation. These tools and the assigned team member are as
listed. Stage 3 took a little bit longer than a month to finish.
Finally, this report is the result of stage 4, where we brought together our individual
reports and merged them into a final report which contains but is not limited to the future
of MDA, EDOC, UML, the MDA supported tools and their evaluation, and the end with
conclusions and recommendations.
-60-
References
[BC]
"Borland: Code::Architect"
http://www.borland.com/us/products/core_architect/index.html
[BT]
“Borland Together Downloads”
http://www.borland.com/downloads/download_together.html
[CD]
“Complete Documentation towards NoMagic MagicDraw”
http://www.magicdraw.com/main.php?ts=navig&NMSESSID=5784cd12588a5
83600884337924fa8d1&cmd_show=1&menu=download_manual
[CE03] Cris Kobryn and Eric Samuelsson, “Driving Architectures with UML 2.0- The
TAU Generation2 Approach to Model Driven Architecture”, Telelogic, August
2003.
http://www.umlforum.com/docs/papers/White_Paper_Driving_Architectures_UML2.pdf
[CM04]“Comparison of Model Driven Architecture (MDA) based tools”
http://dis.dsv.su.se/~emisnat/CMDA/MDATools_KTH_KUH_MasterThesis2004_Telemed5.pdf
[DF03] David Frankel. “Model Driven Architecture - Applying MDA to Enterprise
Computing”, Wiley Publishing Inc, 2003
[DO]
“DoD and Telelogic collaboration” http://www.government.popkins.com
[DT]
“Development tools: Everything a designer needs to get for a killer application”
http://www.apple.com/downloads/macosx/development_tools/magicdrawuml.ht
ml
[EA]
“EA Frameworks” http://www.eaframeworks.com/architectures/
[ECA04] “Enterprise Collaboration Architecture (ECA), v1.0”, http://www.omg.org/cgibin/doc?formal/2004-02-01
[EDOC] “EDOC-Vision”, Data Access Technologies (DAT), http://www.enterprisecomponent.com/docs/EDOC%20Vision.pdf
[ES]
"Executable System Design with UML" by I- Logix
[EU]
"Executable UML(xUML)" by Kennedy Carter http://kc.com/xuml.php
[EV03] “An Evaluation of Compuware OptimalJ Professional Edition as an MDA Tool”
http://whitepapers.zdnet.co.uk/0,39025945,60068893p-39000688q,00.htm
[ID]
“IDEF (for Integrated Definition)” http://www.IDEF.com
[IJ]
Ian Joyner, “Open Distributed Processing: Unplugged!”,
http://homepages.tig.com.au/~ijoyner/ODPUnplugged.html
[IR]
"I-Logix Rhapsody"
http://www.ilogix.com/sublevel.aspx?id=692
[MD] “MagicDraw Architecture made simple”
http://www.magicdraw.com/main.php?ts=navig&NMSESSID=5784cd12588a5
83600884337924fa8d1&cmd_show=1&menu=product_info
[MG03] "MDA Guide Version 1.0.1", OMG, 2003.
http://www.omg.org/docs/omg/03-06-01.pdf
[MI]
"MIA-Software"
http://www.mia-software.com
-61-
[MU04] “Metamodel and UML Profile for Java and EJB Specification”, OMG, February
2004
[NM] “NoMagic’s official website” http://www.nomagic.com
[OG]
“Open Group Architecture Forum” http://www.Opengroup.org/architecture/
[OMD] "OpenMDX -The leading open source MDA platform"
http://www.openmdx.org/
[OMG] “OMG Model Driven Architecture”, OMG, http://www.omg.org/mda/
[OJD] “OptimalJ Developer Edition for IntelliJ User Guide”
http://www.compuware.com/products/optimalj/4480_ENG_HTML.htm
[OJV] “OptimalJ versus in-sync modeling tools” http://whitepapers.zdnet.co.uk/
0,39025945,60092384p-39000527q,00.htm
[SD]
Steve Demurjian, “The Unified Modeling Language”
http://www.engr.uconn.edu/%7Esteve/Cse298300/finaluml.ppt
[OS]
"The open standards-based Java-XML solution for worldwide computing",
DataAccessTechnologies, Component-X, http://www.enterprisecomponent.com/edocsubmissiondanvers.htm
[TS]
“Transforming Software Development: An MDA Road Map”
http://www.cs.umb.edu/~jxs/courses/ 2005/681/readings/mda-meservy.pdf
[UM04] “UML Profile for Patterns, v1.0”, OMG, http://www.omg.org/cgibin/doc?formal/2004-02-04
[ZF]
“Zachman Framework” http://www.zifa.com
-62-