Model Driven Architecture in the Enterprise by hcj

VIEWS: 138 PAGES: 62

									Model Driven Architecture in the Enterprise

               Final Report

                 CSE 333
       Professor: Steven Demurjian

                                         Amit Adur
                                        Keyur Patel
                                     Sabhay Kapoor
                                      Saleh Ibrahim

Table of Contents

Model Driven Architecture in the Enterprise ................................................................................... i
Table of Contents ............................................................................................................................ ii
MDA in the Enterprise .................................................................................................................... 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

                           MDA in the Enterprise

Model Driven Architecture (MDA) has the potential to revolutionize software
development, especially for enterprise application where integration and maintainability
are challenging. In this project we will present the basics of MDA and how it can
leverage enterprise application development. We will also present the relatively-new
Enterprise Distributed Object Computing (EDOC) standard, which attempts to
standardize MDA application to the Enterprise. The role UML plays in MDA is
explained along with what has been introduced in UML 2.0 to enhance this role. Other
enterprise development approaches will be briefly explain and contrasted with
MDA/EDOC. Furthermore, we evaluate MDA/EDOC-support in available software
modeling tools using specific derived evaluation criterion. Finally we will attempt to
anticipate the future direction in MDA-based standards as well as industry support and
adoption of these standards.

1. Introduction
For decades, software engineering continued to be an evolving discipline. Software
developers are still after software development approaches that achieve reusability at
more levels of abstraction. This is particularly true for developing applications for the
enterprise; where business collaborations are a central concern. Software designers need a
modeling framework that enables process engineering by assembling reusable services.
Moreover, the development approach must enable parts of the enterprise to react quickly
and reliably to changes in requirements and in available technologies.

Model Driven Architecture (MDA) enables the clear separation of platform-independent
and platform-specific models, allowing the implementation of platform-independent
models on any platform. Although UML isn't an integral part of MDA, it is still a
language of choice for MDA. UML version 2.0 was specifically enhanced to empower
UML's role in MDA. Before MDA was standardized by OMG, this approach has been
applied for years to embedded and real-time software development. Now, the concept of
MDA is applicable to almost all categories of the software industry [DF03]. While
enterprise software development benefited from MDA, Enterprise Distributed Object
Computing (EDOC) arrived as a standardized MDA-based modeling framework tailored
for enterprise needs. EDOC also carefully covers the five viewpoints of the Open
Distributed Processing Reference Model (ODP-RM), which is a widely-accepted
software engineering reference model for distributed processing [IJ].

The rest of this document is organized as follows: Section 2 presents some background
information on MDA, MOF, and ODP-RM, and the role of UML in MDA. EDOC is
given special attention as an MDA-based standard for modeling enterprise component
systems. Section 3 introduces the software modeling tools that are have been identified as

MDA-compliant. Section 4 explains the current status of our project and future plan.
Appendix A explains the advantages and disadvantages of UML 1.x and Appendix B
presents Alternative Enterprise Development approaches

2. Background
The Enterprise Distributed Object Computing profile is a UML profile for modeling
enterprise applications. In this section we will describe the rational for MDA, how it
relates to existing concepts and standards such as MOF, ODP-RM, and UML.

2.1 MDA
Over the past decade, software designers‟ attention shifted towards more clear separation
between platform independent and platform dependent models. OMG‟s Model Driven
Architecture (MDA) provides an open, vendor-neutral approach to the challenge of
business and technology change [OMG]. This is why MDA is often defined as an
approach to modeling that separates the specification of system functionality (platform1-
independent model) from the specification of its implementation on a specific technology
platform (platform-specific model) [EC04]. But actually the benefits of MDA go even
further. In this subsection we elaborate on the various objectives of MDA and how MOF
and UML enable MDA to achieve these objectives.

2.1.1 MDA Objectives
Usually different aspects of the same application can be modeled separately using
different modeling languages. For example, the relational data store structure can be
modeled using and Entity-Relationship diagram, while the format of communicated
messages carrying the same pieces of data can be modeled using an XML Document
Type Definitions. One of the most difficult challenges a software architect faces is
keeping these different models in sync [DF03].

MDA achieves this objective by taking one step back and starting at the model level,
hence model-driven architecture. An MDA-based framework will be composed of a set
of modeling languages that will be used for modeling different aspects or viewpoints of
the application. By defining transformation rules between the different modeling
languages consistency between the different models developed can be observed. Figure 1
illustrates the role of MDA in integrating different models describing the same

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

 It is important to note that platform here refers also to middleware as well as the conventional hardware,
programming language or operating system platform.

The Meta Object Facility (MOF) supports the managing of different metadata in a
coordinated way. The basic idea is to define a formal model of each language. These
models then drive MOF-based generators that keep the consistency between models
based on the rules defined on their corresponding metamodels. Figure 3 illustrates the
role of MOF generators

Obviously MDA can achieve neat separation of platform-independent models from
platform-specific models, by guiding the software architect to carefully define platform-
independent metamodels, platform-specific metamodels and the mappings between them.
MOF-Generators can then convert platform-independent models into platform dependent
artifacts, such as interfaces, classes, beans, etc.

  Figure 1. MDA is an overall architecture for integrating different specifications of the same
       software product made from different viewpoints in different languages [DF03].

   Figure 2 The metamodel for Java Class Contents expressed in UML [MU04]

2.1.3 Role of UML in MDA
Although MDA as an approach is not built on UML, practically MDA took advantage of
many of the UML strengths and derived enhancements to the UML standard. In 2003,
UML 2.0 was created to correct some of the shortcomings of the previous versions of
UML 1.x. The following sections will describe some of the advantages and
disadvantages of UML 1.x from an MDA perspective [DF03]. Then we will look at UML
2.0 and discuss how some of these disadvantages are eliminated [CE03]. Refer to
Appendix A for details.

          UML 1.x Advantages                          UML 1.x Disadvantages
      Separation of Abstract Syntax from          Not enough support for component
       Concrete Syntax                              based modeling
      Enabling Extensibility                      UML and MOF are not in sync
      Supports      platform-independent
      Open Standard

Improvements in UML 2.0:
a) Support for component based modeling
UML 2.0 has added functionality of modeling objects via composite structures. For
example structured classifies such as classes and components can be decomposed
hierarchically and assembled.
b) UML and MOF
The slight inconsistencies between UML and MOF have been corrected in UML 2.0

2.2 EDOC: Model-Driven Enterprise Architecture
One step from conceptual specification to technical specification of MDA was OMG‟s
introduction of the EDOC specification. EDOC integrates enterprise platform-
independent application models called the Enterprise Collaboration Architecture, with
platform-specific UML profiles, including but not limited to Web Services, .NET,
CORBA, and J2EE. In this manner, both business and technical aspects of an application
can grow at its own pace independent of each other. EDOC was greatly inspired by the
industry standard Open Distributed Processing Reference Model described in the
following section.

The Open Distributed Processing Reference Model

ISO has approved a Reference Model for Open Distributed Processing (ODP-RM)
partitions system specifications into five viewpoints, namely [IJ], the enterprise
viewpoint, the information viewpoint, the computational viewpoint, the engineering
viewpoint, and the technology viewpoint. This clear separation of concerns is crucial to

the success of enterprise modeling. What it lacks was the mechanism to seamlessly
integrate multi-viewpoint models into a consistent enterprise model, and this is where
MDA comes to action.

The EDOC elements can be clearly divided into three categories; Platform-Independent
Profiles, Platform Dependent Profiles and Pattern Profiles. Figure 3 illustrates these
categories and their location in the ODP-RM [EC04].

        Figure 3: EDOC Elements from the ODP-RM viewpoints perspective

2.3 Alternatives to MDA/EDOC
There have been many approaches to enterprise software development, usually focusing
on different aspects of the development process. Some of them are already obsolete,
while others even integrate with MDA. TOGAF, IDEF, The Zachman Framework,
C4ISR, and TEAF has been identified and briefly described in Appendix B.

3. Evaluation Criteria for MDA Tools
Up till now OMG specifies guidelines for using MDA [MG03], but has no MDA
certification process. Tool vendors use the term MDA-support often to mean different
things. One of the major objectives of this project is to identify and evaluate UML
modeling tools that claim to support MDA, by comparing them to the MDA guidelines.
We have identified the many tools that claim MDA-support. We then picked four of them
based on their availability for evaluation and on their overall conformance to MDA
guidelines. In this section we will present the evaluation scheme, which extends the work
done in [EV03], with more specific details.

Evaluation Criteria

The work done in this project to evaluate MDA modeling tools, use the feature analysis
approach. In this approach, a set of features relevant to the goal of evaluation is listed and

the support of each of these features is then checked in every tool. As there might be
different levels of support for each of the features, we used a 4-star rating scheme rather
than a yes/no scheme.

OMG defines only a set of guidelines [MG03], based on which the authors of [EV03]
devised a sixteen-feature evaluation criteria. In order for this criteria to be more useful we
added specific sub-features to each of the sixteen features to make it easier to evaluate.
The sixteen-feature evaluation criteria are shown in Table 1.a and 1.b.

Criteria    Criteria Name           Criteria Explanation
MDA 01      Support for PIM                Support of at least one PIM (Generic UML and
                                            domain-tagged UML profiles can be considered
                                           Support Multiple Viewpoint PIM
                                           PIM extensibility (custom Metamodels)
                                           PIM Metamodels editing facility

MDA 02      Support of PSM                 Support at least one PSM (platform in the sense
                                            of middleware)
                                           Platform-tagged UML profiles count as PSM
                                           (PIM to PSM is a critical requirement of MDA)

MDA 03      Can Target                     Target more than one PSM, e.g. J2EE and .NET
            Multiple PSM                   PSM extensibility
                                           PSM Metamodels editing facility

MDA 04      Model Integration              Multiple diagrams of the same type
                                           Multiple diagram types
                                           Multiple viewpoints feed the same transformation

MDA 05      System Evolution               Source code management
                                           Forward propagation of changes
                                           Efficient-forward propagation         of    changes
                                            (updates only)

MDA 06      Model                          Import models from other legacy tools
            Interoperability               Import XMI
                                           Export XMI

MDA 07      Mappings are                   Legacy-customizable Model-to-Code mappings
            modeled                        Quasi-standard QVT Model-to-Code mappings

                               Table 1.a Evaluation Criterion

Criteria   Criteria Name       Criteria Explanation
MDA 08     Support for                Locating modeling elements in models
           Managing Model             Zooming in and out

MDA 09     Correctness                Modeling tool checks static models based on the
                                       corresponding metamodels
                                      Allow more rules to be defined and checked

MDA 10     Expressivity               Language "can" express any instance of the
                                       domain it is modeling
                                      support expressive higher levels of abstraction

MDA 11     Patterns and               Use of ready-made patterns in code generation
           Genericity                 Use of ready-made patterns in transformations
                                      User-defined patterns
MDA 12     Support for                Generate Model given Code
           Refactoring                Propagate code changes to model (roundtrip)

MDA 13     Intra-Model                Built-in       Model-to-Model       Mappings
           Mappings                    (transformations)
                                      Immediate propagation of changes between
                                       models related by transformations
                                      Legacy-customizable transformations
                                      QVT Model-to-Model mappings

MDA 14     Traceability               PSM elements reference PIM elements where
                                       they originate
                                      Transformations generate a log that help tracing
                                       the execution of the different mappings
MDA 15     Life Cycle                 Analysis,
                                      Design,
                                      Implementation,
                                      Testing

MDA 16     Standardization            UML
                                      MOF
                                      XMI
                                      QVT

                    Table 1.b Evaluation Criterion (continued)

Not all features are born equal, some are critical to the concept of MDA, some are useful
and others are just optional. In order for our evaluation to be more meaningful, we had to
assign every feature one of the following importance levels:
    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     Recommended Features         Optional Features
              Weight 5               Weight 3                    Weight 1
              MDA 01
              MDA 02
              MDA 03
              MDA 04
                                       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.

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

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

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.

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                                                        Check Output Model
 Transformation Script       Create Input Model     Apply Transformation    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

                         Figure 7: Model to Model Transformation

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

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.

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                                                         Check Output File for
 Code                      Create Input Model        Apply Transformation      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.

           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

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             Description                       Evaluation                Score
 MDA01        Support for PIMs           Tool allows Business Process               3
                                         Models (BPM) to be created at a
                                         very abstract level without the
                                         details of implementation
 MDA02        Support for PSMs           Tools supports creation of J2EE,           2
                                         EJB, etc. specific projects
 MDA03        Can Target Multiple PSMs   Together Architect supports                1
                                         mainly J2EE
 MDA04        Model Integration          Able to use multiple diagrams              4
                                         such as class, use case, sequence,
                                         state, etc. to create a single
 MDA05        System Evolution           When changes in the input                  1
                                         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.
 MDA06        Model Interoperability     Together Architect 2006 is able            4
                                         to export models as a standard
                                         XMI documentation for inter-
                                         tool operability
 MDA07        Mappings are modeled       Tool provides QVT language                 4
                                         support for model to model
                                         mappings and transformation
                                         code editor and debugger for
                                         JAVA       transformation    code
                                         mapping for model to code
 MDA08        Support for Managing Model Component diagrams are used to             2
              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,

                                     etc. that will make up a system.
MDA09   Correctness                  Together provides a wide variety     4
                                     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.
MDA10   Expressivity                 Supports       high     level   of   3
                                     abstraction in PIMs
MDA11   Patterns                     Pattern instances appear as a        4
                                     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
MDA12   Support for Refactoring      The goal of refactoring support      4
                                     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.
MDA13   Intra-Model Mappings         Does not support built-in model      0
                                     to model mappings. Mapping
                                     has to be developed by
                                     programmers         using     QVT

 MDA14       Traceability                   A                Model-to-model       2
                                            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.
 MDA15       Lifecycle                      Tool plays a role in the complete     4
                                            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
 MDA16       Standardization                Together Architect 2006 uses          4
                                            standard UML notation and can
                                            import or export models as XMI

         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 model-
driven 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 MIA-
Software 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

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 platform-
independent 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

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

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

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

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

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




                                                             Code Generators


                          Figure 16: MIA-Software Tool Suite

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
          Executes the model transformation rules on input models to generate other
          Operation is illustrated in the figure below

  Figure 17.a: Mia-Generation                  Figure 17.b: MIA-Transformation

When used together with a UML modeling tool, these tools support a full-fledged MDA-
compliant 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.

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.

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
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 also includes an open-source test environment that contains a Web
        server and EJB container. The OptimalJ deployment packager automatically

       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.

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

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.

                  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

 Fig 24: Screen shot of EJB model

Fig 25: Screen shot of DBMS model

    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

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

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.

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.

Criteria          Description                     Evaluation                 Rank
MDA01      Support for PIMs              Full support for PSM. Strong         4
                                         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

MDA02      Support for PSMs              Strong support with application      4
                                         model, abstraction over J2EE
                                         implementation and explicitly
                                         divided into web sub-models,
                                         bean and database.

MDA03      Can Target Multiple PSMs      Targets only one PSM. OptimalJ       1
                                         largely targets J2EE as a
                                         Platform     specific   domain.
                                         Cannot edit metamodels.

MDA04      Model Integration             OptimalJ supports for model          2
                                         integration e.g. the class and
                                         service part of the domain model
                                         in the transformation into the
                                         application model. Integrated
                                         relationship across diagrams.

MDA05      System Evolution              Strong support as changes in the     3
                                         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.
MDA06      Model Interoperability        OptimalJ     uses UML 2.0            3
                                         notations and can import can
                                         import/export XMI models

MDA07      Mappings are modeled          There are mappings         and       2
                                         mapping are in form of models.
                                         So users have limited access to
                                         models     using      Template
                                         programming Language

MDA08   Support for Managing Model OptimalJ using a fixed point of        2
        Complexity                 abstraction can represent most
                                   parts of both the domain and
                                   application               models
                                   diagrammatically. Zooming in
                                   and out Object Structures

MDA09   Correctness                  It enforces well-formed rules on     3
                                     both the app. and domain
                                     models. Prevent errors by
                                     disallowing reserved words

MDA10   Expressivity                 Both domain and application          4
                                     models provide the expected
                                     levels of expressivity at their
                                     levels of abstractions also
                                     expressivity using UML

MDA11   Patterns                     Here        when        converting   3
                                     application model into code,
                                     OptimalJ generates a number of
                                     patterns in the resulting code.

MDA12   Support for Refactoring      The code model is divided into       4
                                     „free‟ and „guarded‟ blocks. By
                                     this method, changes inherit.
                                     Changes in upper layer only
                                     affect guarded part of code.

MDA13   Intra-Model Mappings         Support, changes in the database     3
                                     tier is automatically reflected in
                                     the EJB tier. Also domain
                                     service model is created from
                                     domain class model.

MDA14   Traceability                 Limited support for tracing. The     1
                                     execution of mappings from
                                     domain to application model
                                     creates reference from the latter
                                     to the former. Disallow tracing
                                     of code generating mappings

MDA15   Lifecycle                    OptimalJ covers virtually all the    4
                                     aspects of the system life cycle
                                     including    analysis,   design,

                                               coding,    debugging,    project
                                               organization,    testing    and

 MDA16        Standardization                  It stores all the models in a MOF        4
                                               repository. It uses standard UML
                                               2.0      notations     and     can
                                               import/export XMI

                       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.

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

       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

Figure 28 : A General View of MagicDraw10.0 showing connection of components

Figure 29: Business Profile Model diagram showing ordering of events

           Figure 30: Shows the Implementation diagram

Figure 31: Shows The visual model differencing

Figure 32: Shows the report generation wizard

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

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

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

           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.

                   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
 MDA01        Support for PIMs               Tool allows Business Process           3
                                             Models (BPM) to be created at a
                                             very abstract level without the
                                             details of implementation
 MDA02        Support for PSMs               Supports creation of various           3
                                             PSMs J2EE, EJB, etc. specific
 MDA03        Can Target Multiple PSMs       Multiple PSMs are supported by         4
                                             MagicDraw like Java, C++,C#,
                                             EJB, DDL.
 MDA04        Model Integration              Various diagrams such as the           4
                                             class, sequence, state are
                                             provided       to    model    the
 MDA05        System Evolution               Transformations have to be             2
                                             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.
 MDA06        Model Interoperability         Models can be exported using           3
                                             the standard XMI documentation
                                             for inter-tool operability
 MDA07        Mappings are modeled           Model to model mappings are            2

 MDA08        Support for Managing Model Various viewpoint diagrams are             4
              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

MDA09   Correctness                  Provides the Language Specific      2
                                     Syntax Checker which checks
                                     the UML code before code

MDA10   Expressivity                 High levels of abstraction are      4
                                     supported in PIMs

MDA11   Patterns                     Pattern are extendable and a        3
                                     patter wizard is provided for the
                                     recognition and creation of
MDA12   Support for Refactoring      Refactoring         allows     us   3
                                     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.
MDA13   Intra-Model Mappings         Supports built in model to model    3

MDA14   Traceability                 Traceability is supported in        2
                                     MagicDraw during model to
                                     model transformations with the
                                     help of trace files.
MDA15   Lifecycle                    MagicDraw plays a role in the       3
                                     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.
MDA16   Standardization              Standard UML 2.0 notations and      3
                                     meta models are used with XMI
                                     as a standard to export and
                                     import documents.

          Table 5. Evaluation Table for MagicDraw UML 10.0

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        Rhapsody           OptimalJ        MagicDraw
                            MDA01         3               2                  4               3
                            MDA02         2               3                  4               3
                            MDA03         1               3                  1               4
                            MDA04         4               4                  2               4
                            MDA05         1               4                  3               2
                            MDA06         4               4                  3               3
                            MDA07         4               3                  2               2
                            MDA08         2               3                  2               4
                            MDA09         4               4                  3               2
                            MDA10         3               4                  4               4
                            MDA11         4               0                  3               3
                            MDA12         4               4                  4               3
                            MDA13         0               1                  3               3
                            MDA14         2               4                  1               2
                            MDA15         4               4                  4               3
                            MDA16         4               3                  4               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.


   3                                                                                                              Together
   1                                                                                                              MagicDraw






























































                        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.


               Rhapsody                                     Optional


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

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.

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

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

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;

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

       Figure B.1: Explains the detailed concept of The Zachman Framework for
       Enterprise   Architecture [ZF] [DO]

 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

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

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-PSM-
mapping 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

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 drag-
and-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

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

   Stage 1: Conception and Background (Sep. 19 – Oct. 21)

      Introduction to        Role of UML in        MDA supported              Relevant
     MDA, MOF, and                MDA                 tools                  enterprise
          EDOC                   (Amit)              (Keyur)                architectures
          (Saleh)                                                             (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            Logix Rhapsody            OptimalJ              MagicDraw
      Architect 2006         6.1 Developer           Developer              UML 10.0
       for Eclipse              Edition             Edition 4.0.00           (Sabhay)
         (Amit)                  (Saleh)               (Keyur)

   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.

[BC]   "Borland: Code::Architect"
[BT]   “Borland Together Downloads”
[CD]   “Complete Documentation towards NoMagic MagicDraw”
[CE03] Cris Kobryn and Eric Samuelsson, “Driving Architectures with UML 2.0- The
       TAU Generation2 Approach to Model Driven Architecture”, Telelogic, August
[CM04]“Comparison of Model Driven Architecture (MDA) based tools”
[DF03] David Frankel. “Model Driven Architecture - Applying MDA to Enterprise
        Computing”, Wiley Publishing Inc, 2003
[DO]    “DoD and Telelogic collaboration”
[DT]    “Development tools: Everything a designer needs to get for a killer application”
[EA]    “EA Frameworks”
[ECA04] “Enterprise Collaboration Architecture (ECA), v1.0”,
[EDOC] “EDOC-Vision”, Data Access Technologies (DAT), http://www.enterprise-
[ES]    "Executable System Design with UML" by I- Logix
[EU]    "Executable UML(xUML)" by Kennedy Carter
[EV03] “An Evaluation of Compuware OptimalJ Professional Edition as an MDA Tool”,39025945,60068893p-39000688q,00.htm
[ID]    “IDEF (for Integrated Definition)”
[IJ]    Ian Joyner, “Open Distributed Processing: Unplugged!”,
[IR]    "I-Logix Rhapsody"
[MD] “MagicDraw Architecture made simple”
[MG03] "MDA Guide Version 1.0.1", OMG, 2003.
[MI]    "MIA-Software"

[MU04] “Metamodel and UML Profile for Java and EJB Specification”, OMG, February
[NM] “NoMagic‟s official website”
[OG]   “Open Group Architecture Forum”
[OMD] "OpenMDX -The leading open source MDA platform"
[OMG] “OMG Model Driven Architecture”, OMG,
[OJD] “OptimalJ Developer Edition for IntelliJ User Guide”
[OJV] “OptimalJ versus in-sync modeling tools”
[SD]   Steve Demurjian, “The Unified Modeling Language”
[OS]   "The open standards-based Java-XML solution for worldwide computing",
       DataAccessTechnologies, Component-X, http://www.enterprise-
[TS]   “Transforming Software Development: An MDA Road Map” 2005/681/readings/mda-meservy.pdf
[UM04] “UML Profile for Patterns, v1.0”, OMG,
[ZF]   “Zachman Framework”


To top