model driven architecture in the enterprise

Model Driven Architecture in the Enterprise

Final Report12/15/05

CSE 333Professor: Steven Demurjian

Amit AdurKeyur Patel

Sabhay KapoorSaleh Ibrahim

-i-

Table of Contents

Model Driven Architecture in the Enterprise....................................................................................iTable of Contents..............................................................................................................................iiMDA in the Enterprise......................................................................................................................4Abstract.............................................................................................................................................41. Introduction...................................................................................................................................42. Background...................................................................................................................................5

2.1 MDA.......................................................................................................................................52.1.1 MDA Objectives.............................................................................................................52.1.2 MOF: the MDA’s Genie.................................................................................................52.1.3 Role of UML in MDA....................................................................................................7

2.2 EDOC: Model-Driven Enterprise Architecture......................................................................72.3 Alternatives to MDA/EDOC..................................................................................................8

3. Evaluation Criteria for MDA Tools..............................................................................................84. Evaluation of MDA compliant tools...........................................................................................12

4.1 Borland Together Architect 2006 for Eclipse......................................................................124.2 I-Logix Rhapsody.................................................................................................................21

4.2.1 Rhapsody Overview......................................................................................................214.2.2 Rhapsody Evaluation....................................................................................................224.2.3 The MIA-Software Tool Suite......................................................................................274.2.4 Rhapsody and MIA-Tools.............................................................................................28

4.3 OptimalJ Developer Edition by intelliJ 4.0.00.....................................................................294.4 MagicDraw UML 10.0........................................................................................................41

5. Summary of Results....................................................................................................................516. Conclusions and Future Work....................................................................................................52Appendix A: UML 1.x and MDA...................................................................................................54

A.1 Advantages..........................................................................................................................54a) Separation of Abstract Syntax from Concrete Syntax.......................................................54b) Enabling Extensibility.......................................................................................................54c) Supports platform-independent models.............................................................................54d) Open Standard...................................................................................................................54

A.2 Disadvantages of using UML 1.x:.......................................................................................55a) Not enough support for component based modeling.........................................................55b) UML and MOF are not in sync..........................................................................................55

Appendix B: 4. Other Enterprise Architectures..............................................................................55B.1 TOGAF Model.....................................................................................................................55B.2 IDEF (for Integrated Definition)..........................................................................................56B.3 The Zachman Framework....................................................................................................56B.4 C4ISR..................................................................................................................................57B.5 The Treasury Enterprise Architecture Framework (TEAF)................................................57

Appendix C: Other MDA Tools.....................................................................................................58C.1 OpenMDX: An Advanced MDA Framework.....................................................................58C.2 ExecutableUML (xUML)....................................................................................................58C.3 Component-X by Data Access Technologies......................................................................59C.4 The TAU Generation2 Approach to MDA..........................................................................59

Appendix D. Project Schedule and Task Assignment....................................................................60References.......................................................................................................................................62

-ii-

MDA in the Enterprise

Abstract

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

1. Introduction

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

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

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

-4-

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

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

2.1.2 MOF: the MDA’s GenieIn order to define modeling languages, MDA uses formal models called meta-models. Metamodels are basically models that describe modeling languages [DF03]. As an example of a metamodel refer to Figure 2 for the metamodel for Java Class Contents [MU04].

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

-5-

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

-6-

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

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

UML 1.x Advantages UML 1.x Disadvantages

Separation of Abstract Syntax from Concrete Syntax

Enabling Extensibility Supports platform-independent

models Open Standard

Not enough support for component based modeling

UML and MOF are not in sync

Improvements in UML 2.0:a) Support for component based modelingUML 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

-7-

The slight inconsistencies between UML and MOF have been corrected in UML 2.0

2.2 EDOC: Model-Driven Enterprise ArchitectureOne 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/EDOCThere have been many approaches to enterprise software development, usually focusing on different aspects of the development process. Some of them are already obsolete,

-8-

while others even integrate with MDA. TOGAF, IDEF, The Zachman Framework, C4ISR, and TEAF has been identified and briefly described in Appendix B.

3. Evaluation Criteria for MDA Tools

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

Evaluation Criteria

The work done in this project to evaluate MDA modeling tools, use the feature analysis approach. In this approach, a set of features relevant to the goal of evaluation is listed and the support of each of these features is then checked in every tool. As there might be different levels of support for each of the features, we used a 4-star rating scheme rather than a yes/no scheme.

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

Criteria Number

Criteria Name Criteria Explanation

MDA 01 Support for PIM Support of at least one PIM (Generic UML and domain-tagged UML profiles can be considered PIM)

Support Multiple Viewpoint PIM PIM extensibility (custom Metamodels) PIM Metamodels editing facility

MDA 02 Support of PSM Support at least one PSM (platform in the sense of middleware)

Platform-tagged UML profiles count as PSM (PIM to PSM is a critical requirement of MDA)

MDA 03 Can Target Multiple PSM

Target more than one PSM, e.g. J2EE and .NET PSM extensibility PSM Metamodels editing facility

-9-

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

MDA 05 System Evolution Source code management Forward propagation of changes Efficient-forward propagation of changes

(updates only)

MDA 06 Model Interoperability

Import models from other legacy tools Import XMI Export XMI

MDA 07 Mappings are modeled

Legacy-customizable Model-to-Code mappings Quasi-standard QVT Model-to-Code mappings

Table 1.a Evaluation CriterionCriteria Number

Criteria Name Criteria Explanation

MDA 08 Support for Managing Model Complexity

Locating modeling elements in models Zooming in and out

MDA 09 Correctness Modeling tool checks static models based on the corresponding metamodels

Allow more rules to be defined and checked

MDA 10 Expressivity Language "can" express any instance of the domain it is modeling

support expressive higher levels of abstraction (PIM)

MDA 11 Patterns and Genericity

Use of ready-made patterns in code generation Use of ready-made patterns in transformations User-defined patterns

MDA 12 Support for Refactoring

Generate Model given Code Propagate code changes to model (roundtrip)

MDA 13 Intra-Model Mappings

Built-in Model-to-Model Mappings (transformations)

Immediate propagation of changes between models related by transformations

Legacy-customizable transformations QVT Model-to-Model mappings

-10-

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 FeaturesWeight 5

Recommended FeaturesWeight 3

Optional FeaturesWeight 1

MDA 01MDA 02MDA 03MDA 04

MDA 05MDA 06

MDA 07MDA 08MDA 09

MDA 10

-11-

MDA 11MDA 12MDA 13

MDA 14MDA 15

MDA 16Table 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.

-12-

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.

-13-

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.

Meta-models:

Tool has a vast library of meta-model definitions for technology mapping. These technology dependent metamodels range from metamodels for UML to JAVA to EJB to name a few. These meta-models and their properties can be viewed in the metamodel browser window as shown below.

-14-

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.

-15-

Figure 6: Steps for Model to Model Transformation

To create a model to model transformation, users will first have to open a new MDA transformation project. When a model to model transformation project is selected, Together prompts the user to choose the metamodels for the input model and the output model which will then be imported in the transformation script. A screenshot is shown below.

Figure 7: Model to Model Transformation

Together gives the user a Query View Transformation (QVT) language editor for defining the guidelines for transforming an instance of one Together or Eclipse Modeling Framework (EMF) model to an instance of another Together or EMF model. This is the engine which is responsible for enabling this transformation using OMG’s QVT language.

A screenshot of a sample QVT transformation file follows.

-16-

Create QVT Transformation Script Create Input Model Apply Transformation

Check Output Model for Correctness

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

-17-

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.

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.

-18-

Define Transformation Code Create Input Model Apply Transformation

Check Output File for Correctness

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

-19-

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 ScoreMDA01 Support for PIMs Tool allows Business Process

Models (BPM) to be created at a very abstract level without the details of implementation

3

MDA02 Support for PSMs Tools supports creation of J2EE, EJB, etc. specific projects

2

MDA03 Can Target Multiple PSMs Together Architect supports mainly J2EE

1

MDA04 Model Integration Able to use multiple diagrams such as class, use case, sequence, state, etc. to create a single application

4

MDA05 System Evolution When changes in the input model are made, the transformed model or code is not update in real time. The transformation has to be redone in order for the changes to be reflected in the output model or code.

1

MDA06 Model Interoperability Together Architect 2006 is able to export models as a standard XMI documentation for inter-tool operability

4

MDA07 Mappings are modeled Tool provides QVT language support for model to model mappings and transformation code editor and debugger for JAVA transformation code mapping for model to code transformations.

4

MDA08 Support for Managing Model Complexity

Component diagrams are used to 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,

2

-20-

etc. that will make up a system.MDA09 Correctness Together provides a wide variety

of audits, ranging from design issues to naming conventions. The process of running audits begins with your selecting the specific rules to which your source code should conform. Together generates an audit report that displays only the violations of those rules. You can examine each violation and decide whether to correct the source code.

4

MDA10 Expressivity Supports high level of abstraction in PIMs

3

MDA11 Patterns Pattern instances appear as a result of recognition of the existing model or creating new instances (along with model elements playing pattern roles) in the model. Pattern instances contain information about the pattern name and the role of each participant.

4

MDA12 Support for Refactoring The goal of refactoring support is to allow for improving your code without changing its behavior. When you refactor your code, your goal is to make a system-wide coding change without affecting the semantic behavior of the system. The JDT automatically manages refactorings for you. The workbench optionally allows you to preview all the impending results of a refactoring action before you finally choose to carry it out.

4

MDA13 Intra-Model Mappings Does not support built-in model to model mappings. Mapping has to be developed by programmers using QVT language

0

-21-

MDA14 Traceability A Model-to-model transformation produces an instance of an auxiliary trace file with detailed information about every transformation step performed. The trace file can be opened using the designated Traces view.

2

MDA15 Lifecycle Tool plays a role in the complete life cycle of a system, which includes design, implementation, debugging and testing, and finally deployment. QVT and Model to Text transformations are deployed as standard Java Eclipse plug-ins using Export Plug-ins and Fragments Wizard

4

MDA16 Standardization Together Architect 2006 uses standard UML notation and can import or export models as XMI documents.

4

Table 3. Evaluation Table for Together Architect 2006 for Eclipse

4.2 I-Logix Rhapsody

I-Logix is one of the founding companies of the UML and a member of the OMG. Although MDA standard is relatively new, I-Logix managed to incorporate the 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

-22-

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 EvaluationFor 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=2Rhapsody 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=3An advantage of Rhapsody is that it supports CORBA. Automatic IDL generation is the most obvious aspect of CORBA support. CORBA IDL interfaces can then be implemented by C, C++, or Java components.

Platform-specific information and code-generation directives are added to the PIM using CG (code generation) properties, in order to direct the code generation engine.

A point against Rhapsody, however, is that, except for a few cases, PIM entities have generally one-to-one to correspondence to code entities. There is no clear (graphical) representation of the platform specific model. PSM is encoded directly in the generated code.

-23-

MDA03 -Can Target Multiple PSM Rhapsody Score=3CORBA 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 = 4Rhapsody 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

-24-

MDA05 -System EvolutionRhapsody Score=4As 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 InteroperabilityRhapsody Score=4Thanks 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 modeledRhapsody Score = 3Rhapsody 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 ComplexityRhapsody Score = 3Rhapsody 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

-25-

6.1 to allow zooming in and out relationships, such as associating dependency links with a collaboration diagram.

Figure 13: Zooming in and out object structures

MDA09 –CorrectnessRhapsody Score=4In 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

-26-

Zoom out

Zoom in

MDA10 –ExpressivityRhapsody Score = 4UML 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 GenericityRhapsody Score = 2Rhapsody 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 RefactoringRhapsody Score = 4Rhapsody 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

-27-

MDA13 -Intra-Model MappingsRhapsody Score=0Rhapsody 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 -TraceabilityRhapsody Score=1Although 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 CycleRhapsody Score = 4Rhapsody 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 -StandardizationRhapsody Score = 3Supports 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 SuiteAlthough 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.

Figure 16: MIA-Software Tool Suite

-28-

The MIA-Software suite, illustrated below, is composed of three tools:1. MIA-Metamodel Generation

Compiles MOF-compliant metamodels into Java packages to subsequently serve as metamodel definitions

Metamodels are edited using MOF-compatible UML-design tool. Operation illustrated below

2. MIA-Generation Lets the user edit code generation rules for an input metamodel Executes code generation rules on input models to generate code Operation illustrated below

3. MIA-Transformation Lets the user edit model transformation rules from one metamodel to

another Executes the model transformation rules on input models to generate other

models Operation is illustrated in the figure below

Figure 17.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.

-29-

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.

-30-

Features of OptimalJ

Rapid Enterprise Java Development In OptimalJ developers use to interact with a visual model of the application that

can either be imported from other modeling tools using the XMI or built from scratch with the visual modeler.

In addition to its model-based interfaces, the integrated development environment based on the open-source IDE, Net Beans, provides a source editor, class browser, form editor, and debugger to enable developers to view, modify, and customize the generated application.

Using this visual paradigm, developers are shielded from the complexity of coding to the distributed J2EE development.

Dynamic Business Rules Implementation Once the basic application structure has been defined in the model, application

differentiation can be built-in using a flexible business rule editor. The business rules editor can define referential data constraints, which ensure data

integrity and consistency, and event condition rules that provide support for conditional processing.

Static rules are generated as Java code in the application, and dynamic rules are stored in a rules database on the application server to allow for modification at runtime

Pattern-Driven Application Generation OptimalJ can generate all the application code required for running an application.

To do this it first generates models for the Web (JSP), business logic (EJB), and data tiers, which are then used to generate the actual Java code, business rules, and data implementation scripts.

The generated models and code are based on implementation templates called patterns, which encapsulate knowledge and best practices for coding to the J2EE specification and follow OMG standards

Active Synchronization of Models and Code OptimalJ provides live synchronization between the application models and the

Java code. Developers can make changes to applications during or after release using the visual model, and the affected code will be regenerated automatically.

The OptimalJ Source Editor identifies managed source code, business rule code, and custom source code to accelerate understanding and enable you to make modifications during development or after release of the software. This feature really underlines one of the core benefits of OptimalJ, one that will become more apparent as Java business applications reach their second and third iterations.

Integrated Deployment Environment OptimalJ automatically deploys to many of the leading J2EE production servers

including the fully integrated Compuware Optimal Server, offered as an option to OptimalJ.

OptimalJ also includes an open-source test environment that contains a Web server and EJB container. The OptimalJ deployment packager automatically

-31-

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.

-32-

Model Driven Transformations:

Fig 20: OptimalJ MDA driven transformations [UM04]

OptimalJ supports 3 basic levels of models as Domain Model, Application Model and Code Model.

The Domain model (PIM support)Here in OptimalJ the domain model is divided into 2 sections:

Class model – which describes the static structure of the application data. Service model – which states the behaviors .aspects.

One aspects of domain class model is every class must have primary key which is unusual which is used for development of application database.The domain class model displays UML 2.0 diagrams which is carried out via a graphical editor. Most work is displayed out using explorer which is familiar tree style representation.

Class model covers the static structure of the system and application data whereas service model is used to describe behavioral aspects.

Class model consist of classes in the system and relationships between them, this model is graphically displayed and is basis of other models. The structure of each class is defined by its attributes, operations symbolizing behavior of class and relationships are expressed as associations. One could define the associations between classes in terms of multiplicity, generalization and composition.

Every class in Class model must have a primary key defined for itself as this is used in later used in creation of application’s database or schema. Service Model is used to specify the system behavior in an implementation independent way using concepts like Domain Views, Domain Service Attributes and Domain Service Operations.

The domain model does not have any explicit references to end platform technology and works at a high level of abstractions. But there are some implicit dependencies on the end platform. For example we cannot use ‘Order’ as it is reserved word in SQL and same is the case with Java keywords.

-33-

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.

-34-

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

-35-

Fig 24: Screen shot of EJB model

Fig 25: Screen shot of DBMS model

-36-

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

-37-

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

-38-

MDA Assessment of OptimalJ

OptimalJ support for MDA is very positive, based on what we've seen of the MOF Repository and TPL.

Summarizing what we've seen of the product so far, OptimalJ provides:

Very Good Explorer and Diagrams - the Explorer provides powerful navigation for the Meta-Model classes and the UML diagrams give good visual feedback on the relationships between these classes.

Good Product Integration - integrates very well with Netbeans, Tomcat, JBoss, and Axis.

Sufficient Template Support - TPL provides a fully functional, easy-to-use and intuitive template and scripting environment. However, the TPL development environment would benefit from better integration with the Repository API. This feature is forthcoming in the next release of OJ.

Rich Repository API - provides an excellent implementation of the MOF using the Netbeans MDR and adds a substantial number of MOF classes of its own to facilitate the creation of MDA transformations.

Strong Performance - makes very good use of memory and performs difficult tasks, such as the creation of large diagrams, with very good performance.

Availability

The last version of OptimalJ is version 4.0 and it has released three editions. The information about the availability and prices of OptimalJ is taken from the web-site of Compuware, as follows:

OptimalJ 4.0 Developer Edition: Licenses support the development, integration and deployment of J2EE applications. The price for this edition is $1,900.

OptimalJ 4.0 Professional Edition: Licenses support the modeling, development, integration and deployment of J2EE applications. The actual price of this edition is $5,000.

OptimalJ 4.0 Architecture Edition: Licenses includes all features of Professional Edition plus support for creating, extending, applying and exchanging software design patterns using the OptimalJ pattern editor. The current price for this edition is $10,000.00

Evaluation of OptimalJ


Criteria Description Evaluation Rank

-39-

MDA01 Support for PIMs Full support for PSM. Strong support with domain model which contains class models (static structure & service models). It restricts reserved names and if used lead to invalid PSM. Has ready to use metamodels.

4

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

4

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

1

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

2

MDA05 System Evolution Strong support as changes in the domain or app. models can be filtered down to lower levels.The transformation has to be redone in order for the changes to be reflected in the PSM or code model.

3

MDA06 Model Interoperability OptimalJ uses UML 2.0 notations and can import can import/export XMI models

3

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

2


OptimalJ using a fixed point of abstraction can represent most

2

-40-

parts of both the domain and application models diagrammatically. Zooming in and out Object Structures

.MDA09 Correctness It enforces well-formed rules on

both the app. and domain models. Prevent errors by disallowing reserved words

3

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

4

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

3

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

4

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

3

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

1

MDA15 Lifecycle OptimalJ covers virtually all the aspects of the system life cycle including analysis, design, coding, debugging, project organization, testing and

4

-41-

deployment.

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

4

Table 4: Evaluation Table for OptimalJ

4.4 MagicDraw UML 10.0

MagicDraw [CD] is a visual UML modeling and CASE tool with teamwork support. designed for Business Analysts, Software Analysts, Programmers, QA Engineers, and Documentation Writers. MagicDraw provides full UML support for the 2.0 metamodel and notation and import of the UML 1.4 meta-model. It manages a true model representation which it stores as one large XML flat file. This is a dynamic and versatile development tool that facilitates analysis and design of Object Oriented (OO) systems and databases. It supports a custom OO model generator and provides the industry's best code engineering mechanism (with full round-trip support for J2EE, C#, C++, CORBA IDL programming languages, .NET, XML Schema, WSDL), as well as database schema modeling, DDL generation and reverse engineering facilities. Model elements can be drawn on multiple diagrams carrying their content into these new contexts. Some model elements can be displayed with varying degree of detail depending on context. For example, class can be shown in different class diagrams with some, none, or all attributes or operations showing, depending on what each class diagram is attempting to convey. MagicDraw also has a reporting capability which appears to externalize the report creation as an XML file containing the options and an XSL file specifying the report construction. This tool is suited for a wide variety of systems including real-time, client/server and distributed n-tier application design. MagicDraw runs on a wide variety of operating systems, everywhere where Java 1.4 or 1.5 is supported.

We will now look into the features of MagicDraw that make it a powerful UML modeling tool and the support is provides towards MDA ( Model Driven Architecture). The features [NM] of MagicDraw have been described below:

Full support for UML 2.0: MagicDraw provides full support for UML 2.0 which include the class, use case communication, sequence, state, activity, implementation, package, component, composite structure, deployment diagrams.MagicDraw makes it easy to model all aspects of your system: requirements, static structure, deployment structure, activities, states, detailed action sequences, and much more.

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

-42-

colors and fonts may be used for this purpose as well. Custom appearance for diagram elements can be defined using SVG or bitmap images.

Language Specific UML Syntax Checker: Before the Code Generation, MagicDraw will check the correctness of the UML model and prompt you for changes, before any code gets generated.

Pattern Generator. MagicDraw allows Design patterns to be extendable. From version 6.0 all patterns are extendable. We can write your own patters with Java or JPython also.

Code Generation. Once model is created, it's time to begin coding. With MagicDraw's support of Java, C#, C++, and CORBA IDL, generating code frameworks becomes an efficient, streamlined process. And since MagicDraw also enables script creation for all major databases, database structure design has never been so easy.

Code Engineering Sets. Classes might be grouped together with their components into collections called "code engineering sets". The code engineering set helps keep classes and source code synchronized. We may reverse engineer or generate the code for a whole set at once. Also we may specify different properties for each code engineering set: location of the source code files and code generation properties.

Round-trip Engineering. Besides the source code generation and reverse engineering, MagicDraw allows parallel changes to the both source code and UML model. With the help of round-trip engineering technique, MagicDraw synchronizes those changes - new methods and attributes in the source code are added to the UML model and new items in the UML to the source code.

Integration with leading Java IDEs. MagicDraw can be integrated with various development environments like Eclipse, IBM WSAD and RAD, Borland JBuilder, IntelliJ IDEA, NetBeans, Sun Java Studio in a totally synchronized manner.

Source Code Reverse Engineering. If we have lots of unknown source code and want to get an idea what's in there, the source code can be reverse engineered. We may get an UML model and then generate class diagram from Java, EJB, Java bytecode, C#, CIL (MSIL), C++ or CORBA IDL source code.

Model Analysis Facilities. Consider a huge OO model with lots of dependencies, large class hierarchies and a change in a method B in a class A, other elements in the model will be influenced by this change, With MagicDraw we may select any model element and find out all other elements (classes, packages, etc.) that depends on it, or we may go in the opposite direction, select an element and ask for a list of model elements on which your selected element is dependent on. The 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

-43-

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

-44-

Figure 29: Business Profile Model diagram showing ordering of events

Figure 30: Shows the Implementation diagram

-45-

Figure 31: Shows The visual model differencing

Figure 32: Shows the report generation wizard

-46-

MagicDraw and MDA (Model Driven Architecture)

In this section we now will examine the various building blocks and the MDA solutions provided by MagicDraw and the various model driven transformations and other concepts. MagicDraw provides a set of Model Driven Architecture solutions [MD] [DT] with the various frameworks, model to model transformations, PIM to PSM mappings, code engineering and the Business profiles. We will discuss these approaches in this report. MagicDraw is one of the most comprehensive UML modeling tools in the industry today, One of the things that takes it to that level is the comprehensive documentation that is provided regarding its tools, transformations, patterns and the roundtrip engineering. Each one of the above has been explained in the documentation is a very comprehensive manner.

Data Modeling

There are various ways in which data modeling can be achieved in MagicDraw UML. It allows us to integrate data models with the business and the object oriented models. UML profile for Data Definition Language (DDL) enables mapping of relational concepts to UML elements. MagicDraw provides us a tool for generating and reversing DDL Scripts, retrieving Database Structure (Schema) via JDBC.

Another data modeling powerful tool are the modeling transformations in both Platform Independent Model (PIM) to Platform Specific Model (PSM) and PSM to PIM:

UML to Generic DDL DDL to UML UML to Oracle DDL UML to XML Schema XML Schema to UML

-47-

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

-48-

Evaluation of MagicDraw 10.0 for UML 2.0


Criteria Description Evaluation RankMDA01 Support for PIMs Tool allows Business Process

Models (BPM) to be created at a very abstract level without the details of implementation

3

MDA02 Support for PSMs Supports creation of various PSMs J2EE, EJB, etc. specific projects

3

MDA03 Can Target Multiple PSMs Multiple PSMs are supported by MagicDraw like Java, C++,C#, EJB, DDL.

4

MDA04 Model Integration Various diagrams such as the class, sequence, state are provided to model the application.

4

MDA05 System Evolution Transformations have to be performed again in real time so as to the changes made in the code or model can be reflected in the output code or model.

2

MDA06 Model Interoperability Models can be exported using the standard XMI documentation for inter-tool operability

3

MDA07 Mappings are modeled Model to model mappings are supported.

2


Various viewpoint diagrams are provided to model the various levels of abstractions and more complex applications in an orderly manner. However the component diagrams are used to show the various methods and classes.

4

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

2

-49-

MDA10 Expressivity High levels of abstraction are supported in PIMs

4

MDA11 Patterns Pattern are extendable and a patter wizard is provided for the recognition and creation of patterns..

3

MDA12 Support for Refactoring Refactoring allows us improving the code without changing the semantics of the model. MagicDraw provides support for refactoring and thus helps us improve the code without changing the behavior of the model.

3

MDA13 Intra-Model Mappings Supports built in model to model mappings.

3

MDA14 Traceability Traceability is supported in MagicDraw during model to model transformations with the help of trace files.

2

MDA15 Lifecycle MagicDraw plays a role in the complete life cycle of a system, which includes design, implementation, debugging and testing, and finally deployment. However the final deployment phase has to undergo some improvement for it to become a complete tool.

3

MDA16 Standardization Standard UML 2.0 notations and meta models are used with XMI as a standard to export and import documents.

3

Table 5. Evaluation Table for MagicDraw UML 10.0

5. Summary of Results

-50-

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

0

1

2

3

4

MDA01

MDA02

MDA03

MDA04

MDA07

MDA05

MDA06

MDA10

MDA12

MDA13

MDA16

MDA08

MDA09

MDA11

MDA14

MDA15

Together

Rhapsody

OptimalJ

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.

-51-

0 50 100 150

Together

Rhapsody

OptimalJ

MagicDraw

Critical

Recommended

Optional

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.

-52-

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.

-53-

Appendix A: UML 1.x and MDA

A.1 Advantages

a) Separation of Abstract Syntax from Concrete SyntaxFrom 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 ExtensibilityAnother 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 modelsBy 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 StandardThe 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

-54-

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 modelingIn UML 1.x, the notion of components is very clear. It is possible to create very basic UML profiles for components in UML although the results of doing so are not very satisfactory.

b) UML and MOF are not in syncUML 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;

-55-

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

-56-

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

B.4 C4ISR Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance was started in 1995 by the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD, C31) formed the C4I Integration Support Activity (CISA) to develop a unified approach for development and evaluation of information and architectures. CISA is developing and coordinating a common set of Architecture terms and Definitions, and supporting the working group that is developing the Standard Data Element-Based Automated Architecture Support Environment and the Automated Architecture Tool Suite [DO] [EA].

B.5 The Treasury Enterprise Architecture Framework (TEAF) It was an architectural framework that was developed by the Department of the Treasury in response to a number of government directives, including The Information Technology Management Reform Act (ITMRA) of 1996 ("Clinger-Cohen Act") .The Government Performance and Results Act (GPRA) of 1993. The Federal Enterprise Architecture Framework (FEAF) of 1999.The purpose of the TEAF is to provide a framework for the Treasury and its bureaus to produce their enterprise architectures .An enterprise

-57-

architecture offers important benefits to an agency, capturing information needed for planning and decision making and providing high-level views to help communicate the complexity of large systems [DO] [EA].

Appendix C: Other MDA Tools

This appendix describes other tools that we came across during the course of our project. The reason why each of them was excluded from the evaluation process is briefly explained.

C.1 OpenMDX: An Advanced MDA Framework

According to their website [OMD], "OpenMDX is an advanced implementation of the OMG Model Driven Architecture (MDA) initiative. OpenMDX is an industrial-strength, model-driven runtime engine, open, and framework for PIMs." OpenMDX claims that unlike most commercial tools, it does not implement the generative PIM-to-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 models.

-58-

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

-59-

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.

-60-

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.

-61-

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

Introduction to MDA, MOF, and

EDOC(Saleh)

Stage 2: Criteria/Guidelines for evaluation of tools: (Oct 22 – Nov 4)

MDA supported tools

(Keyur)

Develop and finalize the criteria on how the different tools will be evaluated(Team work)

Role of UML in MDA(Amit)

Relevant enterprise

architectures(Sabhay)

Stage 3: Analysis and Evaluation of tools (Nov 4 – Nov 27)

Stage 4: Future Outlook and Delivery: Final Report (Nov. 28 – Dec. 4)(Merge reports generated in step 3 into a final report)

Together Architect 2006

for Eclipse(Amit)

OptimalJ Developer

Edition 4.0.00(Keyur)

Logix Rhapsody 6.1 Developer

Edition(Saleh)

MagicDraw UML 10.0(Sabhay)

References

[BC] "Borland: Code::Architect" http://www.borland.com/us/products/core_architect/index.html

[BT] “Borland Together Downloads” http://www.borland.com/downloads/download_together.html

[CD] “Complete Documentation towards NoMagic MagicDraw” http://www.magicdraw.com/main.php?ts=navig&NMSESSID=5784cd12588a583600884337924fa8d1&cmd_show=1&menu=download_manual

[CE03] Cris Kobryn and Eric Samuelsson, “Driving Architectures with UML 2.0- The TAU Generation2 Approach to Model Driven Architecture”, Telelogic, August 2003. http://www.uml-forum.com/docs/papers/White_Paper_Driving_Architectures_UML2.pdf

[CM04]“Comparison of Model Driven Architecture (MDA) based tools” http://dis.dsv.su.se/~emis-nat/CMDA/MDATools_KTH_KUH_MasterThesis2004_Telemed5.pdf

[DF03] David Frankel. “Model Driven Architecture - Applying MDA to Enterprise Computing”, Wiley Publishing Inc, 2003

[DO] “DoD and Telelogic collaboration” http://www.government.popkins.com[DT] “Development tools: Everything a designer needs to get for a killer application”

http://www.apple.com/downloads/macosx/development_tools/magicdrawuml.html

[EA] “EA Frameworks” http://www.eaframeworks.com/architectures/[ECA04]“Enterprise Collaboration Architecture (ECA), v1.0”, http://www.omg.org/cgi-

bin/doc?formal/2004-02-01 [EDOC] “EDOC-Vision”, Data Access Technologies (DAT), http://www.enterprise-

component.com/docs/EDOC%20Vision.pdf[ES] "Executable System Design with UML" by I- Logix[EU] "Executable UML(xUML)" by Kennedy Carter http://kc.com/xuml.php[EV03] “An Evaluation of Compuware OptimalJ Professional Edition as an MDA Tool”

http://whitepapers.zdnet.co.uk/0,39025945,60068893p-39000688q,00.htm[ID] “IDEF (for Integrated Definition)” http://www.IDEF.com[IJ] Ian Joyner, “Open Distributed Processing: Unplugged!”,

http://homepages.tig.com.au/~ijoyner/ODPUnplugged.html [IR] "I-Logix Rhapsody"

http://www.ilogix.com/sublevel.aspx?id=692[MD] “MagicDraw Architecture made simple” http://www.magicdraw.com/main.php?

ts=navig&NMSESSID=5784cd12588a583600884337924fa8d1&cmd_show=1&menu=product_info

[MG03] "MDA Guide Version 1.0.1", OMG, 2003. http://www.omg.org/docs/omg/03-06-01.pdf

-62-

http://www.omg.org/docs/omg/03-06-01.pdf

http://www.magicdraw.com/main.php?ts=navig&NMSESSID=5784cd12588a583600884337924fa8d1&cmd_show=1&menu=product_info



http://www.ilogix.com/sublevel.aspx?id=692

http://homepages.tig.com.au/~ijoyner/ODPUnplugged.html

http://www.IDEF.com/

http://edtn.bitpipe.com/detail/RES/1095961328_934.html

http://kc.com/xuml.php

http://www.enterprise-component.com/docs/EDOC%20Vision.pdf

http://www.enterprise-component.com/docs/EDOC%20Vision.pdf

http://www.omg.org/cgi-bin/doc?formal/2004-02-01


http://www.eaframeworks.com/architectures/



http://www.government.popkins.com/

http://dis.dsv.su.se/~emis-nat/CMDA/MDATools_KTH_KUH_MasterThesis2004_Telemed5.pdf

http://dis.dsv.su.se/~emis-nat/CMDA/MDATools_KTH_KUH_MasterThesis2004_Telemed5.pdf

http://www.uml-forum.com/docs/papers/White_Paper_Driving_Architectures_UML2.pdf

http://www.uml-forum.com/docs/papers/White_Paper_Driving_Architectures_UML2.pdf

http://www.magicdraw.com/main.php?ts=navig&NMSESSID=5784cd12588a583600884337924fa8d1&cmd_show=1&menu=download_manual



http://www.borland.com/downloads/download_together.html

http://www.borland.com/us/products/core_architect/index.html

[MI] "MIA-Software"http://www.mia-software.com

[MU04] “Metamodel and UML Profile for Java and EJB Specification”, OMG, February 2004

[NM] “NoMagic’s official website” http://www.nomagic.com[OG] “Open Group Architecture Forum” http://www.Opengroup.org/architecture/[OMD] "OpenMDX -The leading open source MDA platform"

http://www.openmdx.org/[OMG] “OMG Model Driven Architecture”, OMG, http://www.omg.org/mda/[OJD] “OptimalJ Developer Edition for IntelliJ User Guide”

http://www.compuware.com/products/ optimalj /4480_ENG_HTML.htm [OJV] “OptimalJ versus in-sync modeling tools” http://whitepapers.zdnet.co.uk/

0,39025945,60092384p-39000527q,00.htm[SD] Steve Demurjian, “The Unified Modeling Language”

http://www.engr.uconn.edu/%7Esteve/Cse298300/finaluml.ppt [OS] "The open standards-based Java-XML solution for worldwide computing",

DataAccessTechnologies, Component-X, http://www.enterprise-component.com/edocsubmissiondanvers.htm

[TS] “Transforming Software Development: An MDA Road Map” http://www.cs.umb.edu/~jxs/courses/ 2005/681/readings/ mda -meservy.pdf

[UM04] “UML Profile for Patterns, v1.0”, OMG, http://www.omg.org/cgi-bin/doc?formal/2004-02-04

[ZF] “Zachman Framework” http://www.zifa.com

-63-

http://www.zifa.com/



http://www.cs.umb.edu/~jxs/courses/%202005/681/readings/mda-meservy.pdf

http://www.enterprise-component.com/edocsubmissiondanvers.htm

http://www.enterprise-component.com/edocsubmissiondanvers.htm

http://www.engr.uconn.edu/~steve/Cse298300/finaluml.ppt

http://whitepapers.zdnet.co.uk/%200,39025945,60092384p-39000527q,00.htm

http://whitepapers.zdnet.co.uk/%200,39025945,60092384p-39000527q,00.htm

http://www.compuware.com/products/optimalj/4480_ENG_HTML.htm

http://www.omg.org/mda/

http://www.openmdx.org/

http://www.Opengroup.org/architecture/

http://www.nomagic.com/

http://www.mia-software.com/

model driven architecture in the enterprise

Technology

mda tools

mda objectives

advanced mda framework

rhapsody evaluation

enterprise architectures

role of uml

magicdraw uml

appendix b