Model Driven Architecture in the Enterprise


               Final Report
                 12/15/05




                 C...
Table of Contents

Model Driven Architecture in the Enterprise...............................................................
C.4 The TAU Generation2 Approach to MDA.............................................................58
Appendix D. Project...
MDA in the Enterprise


Abstract
Model Driven Architecture (MDA) has the potential to revolutionize software
development, ...
systems. Section 3 introduces the software modeling tools that are have been identified as
MDA-compliant. Section 4 explai...
The Meta Object Facility (MOF) supports the managing of different metadata in a
coordinated way. The basic idea is to defi...
Figure 2 The metamodel for Java Class Contents expressed in UML [MU04]


2.1.3 Role of UML in MDA
Although MDA as an appro...
viewpoint, and the technology viewpoint. This clear separation of concerns is crucial to
the success of enterprise modelin...
The work done in this project to evaluate MDA modeling tools, use the feature analysis
approach. In this approach, a set o...
Table 1.a Evaluation Criterion
Criteria   Criteria Name      Criteria Explanation
Number
MDA 08     Support for           ...
Not all features are born equal, some are critical to the concept of MDA, some are useful
and others are just optional. In...
A long list of UML modeling tools claim to support MDA. In this project, eight different
tools have been considered, four ...
•   Together Architect 2006 provides a complete set of MDA capabilities based on its
       transformation framework. Tran...
Meta-models:

Tool has a vast library of meta-model definitions for technology mapping. These
technology dependent metamod...
Model Driven Transformations:

Model to Model Support

Model to model transformation is supported in Together Architect 20...
engine which is responsible for enabling this transformation using OMG’s QVT
language.

A screenshot of a sample QVT trans...
breakpoints (including StepOver, StepIn and StepOut features), watches and Variable
view. The QVT Traces view enables you ...
Figure 10 . Example of Transformation code written in JAVA.

After defining the transformation code, the transformation ca...
Evaluation of Borland Architect 2006 for Eclipse

This section will use the previously described guidelines to show how th...
etc. that will make up a system.
MDA09   Correctness                  Together provides a wide variety    4
              ...
MDA14       Traceability                   A Model-to-model                      2
                                       ...
the system's behavior through execution and graphical design. It also allows collaborative
and fully scalable infrastructu...
MDA03 -Can Target Multiple PSM
Rhapsody Score=3
CORBA is the only commonly used PSM that is supported in Rhapsody. In addi...
MDA05 -System Evolution
Rhapsody Score=4
As shown in Figure 11, method implementation can be developed within the model it...
6.1 to allow zooming in and out relationships, such as associating dependency links with
a collaboration diagram.


      ...
MDA10 –Expressivity
Rhapsody Score = 4
UML expresses PIM concepts and profiles add PSM information. While some profiles
ar...
MDA13 -Intra-Model Mappings
Rhapsody Score=0
Rhapsody per se doesn't support model-to-model mappings. However, the underly...
The MIA-Software suite, illustrated below, is composed of three tools:
   1. MIA-Metamodel Generation
         • Compiles ...
4.3 OptimalJ Developer Edition by intelliJ 4.0.00

OptimalJ is a MDA-support tool by Compuware that supports both model-to...
Features of OptimalJ

Rapid Enterprise Java Development
    • In OptimalJ developers use to interact with a visual model o...
deploys to this local environment, allowing developers to directly test as they
       develop without worrying about the ...
Model Driven Transformations:




               Fig 20: OptimalJ MDA driven transformations [UM04]

OptimalJ supports 3 b...
platform. For example we cannot use ‘Order’ as it is reserved word in SQL and same is
the case with Java keywords.




   ...
Fig 22: Screen shot of Application model

1. Presentation (Web) model - contains the information required to generate a we...
Fig 24: Screen shot of EJB model




Fig 25: Screen shot of DBMS model



              -35-
2. Business Logic (EJB) model – The Enterprise Java Bean partial reflection of the
       complexity of eventual code. a m...
Of course the user can make changes to the guarded blocks but such changes will be
destroyed when the code is updated from...
MDA Assessment of OptimalJ

OptimalJ support for MDA is very positive, based on what we've seen of the MOF
Repository and ...
Criteria          Description                     Evaluation                 Rank
MDA01      Support for PIMs             ...
MDA08   Support for Managing Model   OptimalJ using a fixed point of      2
        Complexity                   abstracti...
coding, debugging, project
                                               organization, testing and
                      ...
he or she may extend UML by adding its own stereotypes, constraints, tagged
    values and even new appearance of the mode...
attribute type or operation parameter. It can find out all subclasses of the selected
       class and generate a new clas...
Figure 29: Business Profile Model diagram showing ordering of events




           Figure 30: Shows the Implementation di...
Figure 31: Shows The visual model differencing




Figure 32: Shows the report generation wizard


                    -45-
MagicDraw and MDA (Model Driven Architecture)

In this section we now will examine the various building blocks and the MDA...
Figure 33: Shows the concept of data modeling used in MagicDraw

Software Modeling

MagicDraw provides full support for UM...
Figure 35: Shows the Code Engineering Wizard

Evaluation of MagicDraw 10.0 for UML 2.0

This section will use the previous...
MDA09   Correctness                  Provides the Language Specific      2
                                     Syntax Che...
5. Summary of Results
In this section we summarize the results of MDA tool evaluation by comparing the scores
received by ...
MagicDraw


                 OptimalJ
                                                              Critical
             ...
We can go a step further and suggest one tool over the rest based on their individual
scores for a specific functionality....
Model Driven Architecture in the Enterprise
Model Driven Architecture in the Enterprise
Model Driven Architecture in the Enterprise
Model Driven Architecture in the Enterprise
Model Driven Architecture in the Enterprise
Model Driven Architecture in the Enterprise
Model Driven Architecture in the Enterprise
Model Driven Architecture in the Enterprise
Model Driven Architecture in the Enterprise
Model Driven Architecture in the Enterprise
Upcoming SlideShare
Loading in...5
×

Model Driven Architecture in the Enterprise

2,554

Published on

Published in: Technology, News & Politics
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,554
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
90
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Model Driven Architecture in the Enterprise

  1. 1. Model Driven Architecture in the Enterprise Final Report 12/15/05 CSE 333 Professor: Steven Demurjian Amit Adur Keyur Patel Sabhay Kapoor Saleh Ibrahim -i-
  2. 2. Table of Contents Model Driven Architecture in the Enterprise.......................................................................i Table of Contents.................................................................................................................ii MDA in the Enterprise.........................................................................................................4 Abstract................................................................................................................................4 1. Introduction......................................................................................................................4 2. Background......................................................................................................................5 2.1 MDA..........................................................................................................................5 2.1.1 MDA Objectives.................................................................................................5 2.1.2 MOF: the MDA’s Genie.....................................................................................5 2.1.3 Role of UML in MDA........................................................................................7 2.2 EDOC: Model-Driven Enterprise Architecture.........................................................7 2.3 Alternatives to MDA/EDOC......................................................................................8 3. Evaluation Criteria for MDA Tools.................................................................................8 4. Evaluation of MDA compliant tools..............................................................................11 4.1 Borland Together Architect 2006 for Eclipse..........................................................12 4.2 I-Logix Rhapsody....................................................................................................21 4.2.1 Rhapsody Overview .........................................................................................21 4.2.2 Rhapsody Evaluation........................................................................................22 4.2.3 The MIA-Software Tool Suite..........................................................................27 4.2.4 Rhapsody and MIA-Tools.................................................................................28 4.3 OptimalJ Developer Edition by intelliJ 4.0.00.........................................................29 4.4 MagicDraw UML 10.0............................................................................................41 5. Summary of Results.......................................................................................................50 6. Conclusions and Future Work.......................................................................................51 Appendix A: UML 1.x and MDA......................................................................................53 A.1 Advantages..............................................................................................................53 a) Separation of Abstract Syntax from Concrete Syntax...........................................53 b) Enabling Extensibility...........................................................................................53 c) Supports platform-independent models.................................................................53 d) Open Standard.......................................................................................................53 A.2 Disadvantages of using UML 1.x:..........................................................................54 a) Not enough support for component based modeling.............................................54 b) UML and MOF are not in sync.............................................................................54 Appendix B: 4. Other Enterprise Architectures.................................................................54 B.1 TOGAF Model........................................................................................................54 B.2 IDEF (for Integrated Definition).............................................................................55 B.3 The Zachman Framework.......................................................................................55 B.4 C4ISR......................................................................................................................56 B.5 The Treasury Enterprise Architecture Framework (TEAF)....................................56 Appendix C: Other MDA Tools........................................................................................57 C.1 OpenMDX: An Advanced MDA Framework.........................................................57 C.2 ExecutableUML (xUML)........................................................................................57 C.3 Component-X by Data Access Technologies..........................................................58 -ii-
  3. 3. C.4 The TAU Generation2 Approach to MDA.............................................................58 Appendix D. Project Schedule and Task Assignment.......................................................59 References..........................................................................................................................61 -iii-
  4. 4. 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-
  5. 5. systems. Section 3 introduces the software modeling tools that are have been identified as MDA-compliant. Section 4 explains the current status of our project and future plan. Appendix A explains the advantages and disadvantages of UML 1.x and Appendix B presents Alternative Enterprise Development approaches 2. Background The Enterprise Distributed Object Computing profile is a UML profile for modeling enterprise applications. In this section we will describe the rational for MDA, how it relates to existing concepts and standards such as MOF, ODP-RM, and UML. 2.1 MDA Over the past decade, software designers’ attention shifted towards more clear separation between platform independent and platform dependent models. OMG’s Model Driven Architecture (MDA) provides an open, vendor-neutral approach to the challenge of business and technology change [OMG]. This is why MDA is often defined as an approach to modeling that separates the specification of system functionality (platform1- independent model) from the specification of its implementation on a specific technology platform (platform-specific model) [EC04]. But actually the benefits of MDA go even further. In this subsection we elaborate on the various objectives of MDA and how MOF and UML enable MDA to achieve these objectives. 2.1.1 MDA Objectives Usually different aspects of the same application can be modeled separately using different modeling languages. For example, the relational data store structure can be modeled using and Entity-Relationship diagram, while the format of communicated messages carrying the same pieces of data can be modeled using an XML Document Type Definitions. One of the most difficult challenges a software architect faces is keeping these different models in sync [DF03]. MDA achieves this objective by taking one step back and starting at the model level, hence model-driven architecture. An MDA-based framework will be composed of a set of modeling languages that will be used for modeling different aspects or viewpoints of the application. By defining transformation rules between the different modeling languages consistency between the different models developed can be observed. Figure 1 illustrates the role of MDA in integrating different models describing the same application. 2.1.2 MOF: the MDA’s Genie In order to define modeling languages, MDA uses formal models called meta-models. Metamodels are basically models that describe modeling languages [DF03]. As an example of a metamodel refer to Figure 2 for the metamodel for Java Class Contents [MU04]. 1 It is important to note that platform here refers also to middleware as well as the conventional hardware, programming language or operating system platform. -5-
  6. 6. 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-
  7. 7. Figure 2 The metamodel for Java Class Contents expressed in UML [MU04] 2.1.3 Role of UML in MDA Although MDA as an approach is not built on UML, practically MDA took advantage of many of the UML strengths and derived enhancements to the UML standard. In 2003, UML 2.0 was created to correct some of the shortcomings of the previous versions of UML 1.x. The following sections will describe some of the advantages and disadvantages of UML 1.x from an MDA perspective [DF03]. Then we will look at UML 2.0 and discuss how some of these disadvantages are eliminated [CE03]. Refer to Appendix A for details. UML 1.x Advantages UML 1.x Disadvantages • Separation of Abstract Syntax from • Not enough support for component Concrete Syntax based modeling • Enabling Extensibility • UML and MOF are not in sync • Supports platform-independent models • Open Standard Improvements in UML 2.0: a) Support for component based modeling UML 2.0 has added functionality of modeling objects via composite structures. For example structured classifies such as classes and components can be decomposed hierarchically and assembled. b) UML and MOF The slight inconsistencies between UML and MOF have been corrected in UML 2.0 2.2 EDOC: Model-Driven Enterprise Architecture One step from conceptual specification to technical specification of MDA was OMG’s introduction of the EDOC specification. EDOC integrates enterprise platform- independent application models called the Enterprise Collaboration Architecture, with platform-specific UML profiles, including but not limited to Web Services, .NET, CORBA, and J2EE. In this manner, both business and technical aspects of an application can grow at its own pace independent of each other. EDOC was greatly inspired by the industry standard Open Distributed Processing Reference Model described in the following section. The Open Distributed Processing Reference Model ISO has approved a Reference Model for Open Distributed Processing (ODP-RM) partitions system specifications into five viewpoints, namely [IJ], the enterprise viewpoint, the information viewpoint, the computational viewpoint, the engineering -7-
  8. 8. viewpoint, and the technology viewpoint. This clear separation of concerns is crucial to the success of enterprise modeling. What it lacks was the mechanism to seamlessly integrate multi-viewpoint models into a consistent enterprise model, and this is where MDA comes to action. The EDOC elements can be clearly divided into three categories; Platform-Independent Profiles, Platform Dependent Profiles and Pattern Profiles. Figure 3 illustrates these categories and their location in the ODP-RM [EC04]. Figure 3: EDOC Elements from the ODP-RM viewpoints perspective 2.3 Alternatives to MDA/EDOC There have been many approaches to enterprise software development, usually focusing on different aspects of the development process. Some of them are already obsolete, while others even integrate with MDA. TOGAF, IDEF, The Zachman Framework, C4ISR, and TEAF has been identified and briefly described in Appendix B. 3. Evaluation Criteria for MDA Tools Up till now OMG specifies guidelines for using MDA [MG03], but has no MDA certification process. Tool vendors use the term MDA-support often to mean different things. One of the major objectives of this project is to identify and evaluate UML modeling tools that claim to support MDA, by comparing them to the MDA guidelines. We have identified the many tools that claim MDA-support. We then picked four of them based on their availability for evaluation and on their overall conformance to MDA guidelines. In this section we will present the evaluation scheme, which extends the work done in [EV03], with more specific details. Evaluation Criteria -8-
  9. 9. The work done in this project to evaluate MDA modeling tools, use the feature analysis approach. In this approach, a set of features relevant to the goal of evaluation is listed and the support of each of these features is then checked in every tool. As there might be different levels of support for each of the features, we used a 4-star rating scheme rather than a yes/no scheme. OMG defines only a set of guidelines [MG03], based on which the authors of [EV03] devised a sixteen-feature evaluation criteria. In order for this criteria to be more useful we added specific sub-features to each of the sixteen features to make it easier to evaluate. The sixteen-feature evaluation criteria are shown in Table 1.a and 1.b. Criteria Criteria Name Criteria Explanation Number 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  Target more than one PSM, e.g. J2EE and .NET Multiple PSM  PSM extensibility  PSM Metamodels editing facility MDA 04 Model Integration  Multiple diagrams of the same type  Multiple diagram types  Multiple viewpoints feed the same transformation MDA 05 System Evolution  Source code management  Forward propagation of changes  Efficient-forward propagation of changes (updates only) MDA 06 Model  Import models from other legacy tools Interoperability  Import XMI  Export XMI MDA 07 Mappings are  Legacy-customizable Model-to-Code mappings modeled  Quasi-standard QVT Model-to-Code mappings -9-
  10. 10. Table 1.a Evaluation Criterion Criteria Criteria Name Criteria Explanation Number MDA 08 Support for  Locating modeling elements in models Managing Model  Zooming in and out Complexity 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  Use of ready-made patterns in code generation Genericity  Use of ready-made patterns in transformations  User-defined patterns MDA 12 Support for  Generate Model given Code Refactoring  Propagate code changes to model (roundtrip) MDA 13 Intra-Model  Built-in Model-to-Model Mappings Mappings (transformations)  Immediate propagation of changes between models related by transformations  Legacy-customizable transformations  QVT Model-to-Model mappings MDA 14 Traceability  PSM elements reference PIM elements where they originate  Transformations generate a log that help tracing the execution of the different mappings MDA 15 Life Cycle  Analysis,  Design,  Implementation,  Testing MDA 16 Standardization  UML  MOF  XMI  QVT Table 1.b Evaluation Criterion (continued) -10-
  11. 11. Not all features are born equal, some are critical to the concept of MDA, some are useful and others are just optional. In order for our evaluation to be more meaningful, we had to assign every feature one of the following importance levels: 1. Critical features: are features that are considered an integral part of the MDA concept. It is critical that an MDA tool supports such a feature. 2. Recommended features: features that are highly recommended, the absence of which causes serious inconvenience to the user. It is recommended that an MDA tool supports such a feature. 3. Optional features: features that can enhance MDA tool usability, but the absence of which can be tolerated at minimal inconvenience. It is optional that an MDA tool supports such a feature. Through our investigation we came to a consensus about the importance level of each feature. Table 2 shows how every feature was classified according to this rating. Critical Features Recommended Features Optional Features Weight 5 Weight 3 Weight 1 MDA 01 MDA 02 MDA 03 MDA 04 MDA 05 MDA 06 MDA 07 MDA 08 MDA 09 MDA 10 MDA 11 MDA 12 MDA 13 MDA 14 MDA 15 MDA 16 Table 2. Level of Importance We also designed a weighting system for these three categories where we placed a weight of 5 for critical features, a weight of 3 for recommended features and a 1 for optional features, so that we can calculate a rough estimate on how evaluated tools compare to each other from the MDA support perspective. The next section lists and evaluates some of the tools that claim MDA support. 4. Evaluation of MDA compliant tools -11-
  12. 12. A long list of UML modeling tools claim to support MDA. In this project, eight different tools have been considered, four of which have been later disregarded for reasons that relate mainly to feasibility of the evaluation process. This section describes in detail the evaluation process of the four tools that were evaluated, namely Together, Rhapsody, OptimalJ and MagicDraw. For a description of the other four tools that were not evaluated along with the reason why each of them was disregarded, refer to Appendix C. 4.1 Borland Together Architect 2006 for Eclipse Borland Together Architect 2006 for Eclipse is a comprehensive modeling solution tool for software architects with which they can design, develop, and communicate enterprise application architectures. It enables designers to create UML and business process models. It is built upon an Eclipse environment with built-in Together support for UML and Model Driven Architecture (MDA by including OMG’s Query View Transformation (QVT) used in model-to model transformations [OG]. Figure 4 is a snapshot of Together Architect 2006 for Eclipse’s user interface. Figure 4: Together Architect 2006 for Eclipse Some of the features the tool offers are highlighted below: -12-
  13. 13. • Together Architect 2006 provides a complete set of MDA capabilities based on its transformation framework. Transformation framework includes QVT implementation as well as support for other transformation techniques. • Business Process Modeling Notation (BPMN) is designed to cover many types of business process modeling with any level of detail and allows the creation of end- to-end business processes. A diagram created in the Business Process Modeling project can be exported to BPEL/WSDL files with the help of Export command on the File menu. • Provides data modeling solution with the help of logical and physical entity relationship diagrams and import/export capabilities. • Together provides support for the following diagrams and notations defined by the UML 2.0: Activity, Class, Component, Composite structure, Deployment, State Machine, Use case, Communication, Sequence. • Create or modify elements using patterns and templates. In addition you can create your own patterns and distribute them as plug-ins in your organization. Pattern definition project is a profiled UML 2.0 modeling project. • Profiles can be used to adapt the UML semantics without changing the UML metamodel. You can also use a profiled UML 2.0 modeling project that allows creation of profile definitions for creating your own profiles. Support for Model Driven Architecture (MDA): In this aspect, we will cover the main building blocks of the MDA-support tool, its main approaches, solution to address MDA concepts and transformations. Together for Eclipse provides a complete set of Model Driven Architecture (MDA) capabilities based on the Together model transformation framework. The framework implements some of the MOF 2.0 Queries/Views/Transformations (QVT) concepts and is based on the EMF (Eclipse Modeling Framework). Together Architect 2006 for Eclipse’s built-in documentation is complete enough to understand how the transformation is done. Documentation and help topics are very thorough with “cheat sheets” for MDA transformation tutorials and a searchable index with a large collection of help topics. -13-
  14. 14. Meta-models: Tool has a vast library of meta-model definitions for technology mapping. These technology dependent metamodels range from metamodels for UML to JAVA to EJB to name a few. These meta-models and their properties can be viewed in the metamodel browser window as shown below. Figure 5: Metamodel Browser The advantage is that the tool has built-in support for metamodel for various technologies. However, the disadvantage of the metamodel library within the tool is that there is no support for editing existing meta-model or creating own custom meta-model for extensibility purposes. 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. -14-
  15. 15. Model Driven Transformations: Model to Model Support Model to model transformation is supported in Together Architect 2006 for Eclipse. A diagram of the steps required for the transformation is shown in figure 6. Create QVT Check Output Model Transformation Script Create Input Model Apply Transformation for Correctness Figure 6: Steps for Model to Model Transformation To create a model to model transformation, users will first have to open a new MDA transformation project. When a model to model transformation project is selected, Together prompts the user to choose the metamodels for the input model and the output model which will then be imported in the transformation script. A screenshot is shown 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 -15-
  16. 16. engine which is responsible for enabling this transformation using OMG’s QVT language. A screenshot of a sample QVT transformation file follows. Figure 8: Example of the QVT Transformation Script File On the tope of the QVT file, the input and output metamodels are imported for using the semantics for the transformation. Then it uses the semantics to create package and classes within the packages for the output diagram. The framework provides a declarative QVT language for defining mappings between models and a transformation engine for interpreting the mapping definitions and queries. The QVT language implements the latest (ad/05-03-02) MOF 2.0 QVT specification which is still under revision. The language currently supports metamodel and transformation import and OCL expressions. Relations are not supported yet. 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 -16-
  17. 17. breakpoints (including StepOver, StepIn and StepOut features), watches and Variable view. The QVT Traces view enables you to inspect the result of a transformation when it is completed. Model to Code Support Model to code transformation is also supported in Together Architect 2006 for Eclipse and the technique is very similar to model to model transformation. The steps are illustrated below. Define Transformation Check Output File for Code Create Input Model Apply Transformation Correctness Figure 9: Steps for Model to Code Transformation Model to code transformations can be performed by opening a new MDA transformation project for model to text. For this, the user has to choose the metamodel for the input model which will be imported in the transformation code. This is similar to the model to model transformation. Model to text transformations are responsible for transforming an instance of on Together or EMF model into an arbitrary text output. A transformation is developed within the MDA Transformation project as a custom Java Eclipse plug-in. You can create, run and debug transformations within the project environment. When your transformation is ready, you can apply it to models and model elements. The compiled transformations can be distributed among other Together users in your organization since they can be deployed within the Eclipse environment as standard Java plug-ins. The transformation code is written in JAVA by programmers and they can specify the output file format in this code. For example, below is a snippet of a transformation code which converts a UML class diagram into a text file which lists all the classes that are included in the package. -17-
  18. 18. 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 -18-
  19. 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 Score MDA01 Support for PIMs Tool allows Business Process 3 Models (BPM) to be created at a very abstract level without the details of implementation MDA02 Support for PSMs Tools supports creation of J2EE, 2 EJB, etc. specific projects MDA03 Can Target Multiple PSMs Together Architect supports 1 mainly J2EE MDA04 Model Integration Able to use multiple diagrams 4 such as class, use case, sequence, state, etc. to create a single application MDA05 System Evolution When changes in the input 1 model are made, the transformed model or code is not update in real time. The transformation has to be redone in order for the changes to be reflected in the output model or code. MDA06 Model Interoperability Together Architect 2006 is able 4 to export models as a standard XMI documentation for inter- tool operability MDA07 Mappings are modeled Tool provides QVT language 4 support for model to model mappings and transformation code editor and debugger for JAVA transformation code mapping for model to code transformations. MDA08 Support for Managing Model Component diagrams are used to 2 Complexity model higher level or more complex structures, usually consisting of one or more classes, and providing a well defined interface. Component Diagrams illustrate the pieces of software, embedded controllers, -19-
  20. 20. etc. that will make up a system. MDA09 Correctness Together provides a wide variety 4 of audits, ranging from design issues to naming conventions. The process of running audits begins with your selecting the specific rules to which your source code should conform. Together generates an audit report that displays only the violations of those rules. You can examine each violation and decide whether to correct the source code. MDA10 Expressivity Supports high level of 3 abstraction in PIMs MDA11 Patterns Pattern instances appear as a 4 result of recognition of the existing model or creating new instances (along with model elements playing pattern roles) in the model. Pattern instances contain information about the pattern name and the role of each participant. MDA12 Support for Refactoring The goal of refactoring support 4 is to allow for improving your code without changing its behavior. When you refactor your code, your goal is to make a system-wide coding change without affecting the semantic behavior of the system. The JDT automatically manages refactorings for you. The workbench optionally allows you to preview all the impending results of a refactoring action before you finally choose to carry it out. MDA13 Intra-Model Mappings Does not support built-in model 0 to model mappings. Mapping has to be developed by programmers using QVT language -20-
  21. 21. MDA14 Traceability A Model-to-model 2 transformation produces an instance of an auxiliary trace file with detailed information about every transformation step performed. The trace file can be opened using the designated Traces view. MDA15 Lifecycle Tool plays a role in the complete 4 life cycle of a system, which includes design, implementation, debugging and testing, and finally deployment. QVT and Model to Text transformations are deployed as standard Java Eclipse plug-ins using Export Plug-ins and Fragments Wizard MDA16 Standardization Together Architect 2006 uses 4 standard UML notation and can import or export models as XMI documents. 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 -21-
  22. 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 Evaluation For the purpose of evaluation, Rhapsody 6.1 Developer Edition has undergone an extensive MDA-compliance feature analysis. The results of that analysis are detailed here and summarized in Table 7 in section 5. MDA01 -Support for PIM Rhapsody Score=2 Rhapsody has a set of predefined modeling frameworks with corresponding metamodels. UML metamodel can serve as the basis for some of the PIM metamodels. Use Case, Sequence, and State Chart diagrams, which are originally platform-independent, are annotated to guide the transformation into platform specific models and/or generate code. Rhapsody supports the definition of profiles, which extend modeling concepts with new tags and properties. Using UML profiles, platform independent modeling can be extended to model domain specific concepts. Profiles are graphically editable within Rhapsody itself. Rhapsody loses points here because it lacks clear separation between the platform- independent and the platform-specific models. MDA02 -Support of PSM Rhapsody Score=3 An advantage of Rhapsody is that it supports CORBA. Automatic IDL generation is the most obvious aspect of CORBA support. CORBA IDL interfaces can then be implemented by C, C++, or Java components. Platform-specific information and code-generation directives are added to the PIM using CG (code generation) properties, in order to direct the code generation engine. A point against Rhapsody, however, is that, except for a few cases, PIM entities have generally one-to-one to correspondence to code entities. There is no clear (graphical) representation of the platform specific model. PSM is encoded directly in the generated code. -22-
  23. 23. MDA03 -Can Target Multiple PSM Rhapsody Score=3 CORBA is the only commonly used PSM that is supported in Rhapsody. In addition to CORBA, Rhapsody supports a number of legacy frameworks, such as Object eXecutable Framework (OXF), and Interrupt Driven Framework (IDF). Rhapsody also supports customizations of code generation rules. The Rule Composer tool (which is actually the MIA-Generation rules editor), allows the association code generation rules with built-in and user-defined profiles. MDA04 -Model Integration Rhapsody Score = 4 Rhapsody integrates different UML diagrams into a single model repository. For example, classes defined in class diagrams are detailed in state-chart diagrams. Code generators use this cohesive model to generate a single application spanning all information available on different views of the model. Figure 11.a: Method implementation is managed by the Rhapsody GUI Figure 11.b: Round-tripping in Rhapsody -23-
  24. 24. MDA05 -System Evolution Rhapsody Score=4 As shown in Figure 11, method implementation can be developed within the model itself, which provides for better management of code generation and system evolution. All changes to the application can be performed within the Rhapsody GUI itself. Moreover, Rhapsody supports round-tripping, which allows changes done to the generated code to be reflected in the model in a consistent way. See Figure 11.b for an illustration. MDA06 - Model Interoperability Rhapsody Score=4 Thanks to the XMI toolkit, which is joint effort between I-Logix Inc. and SODIUS Corporation, Rhapsody can import and export UML models in XMI. However, the documentation states that only XMI 1.2 (UML 1.3) and prior versions are supported. Rhapsody also allows importing Rose models, which is specifically useful because Rose has been the most-widely used UML tool for the last few years. MDA07 -Mappings are modeled Rhapsody Score = 3 Rhapsody has C, C++, Ada and Java code-generation mappings defined. These mappings are customizable using the Rule Composer editor, Figure 12. Nevertheless, we haven’t been successful in defining a mapping from scratch Figure 12: Rule Composer Editor (Mia-Generation) MDA08 -Support for Managing Model Complexity Rhapsody Score = 3 Rhapsody supports Zooming in and out object structures (Figure 13). It also supports linking state diagrams to the classes they describe. This clears higher level diagrams from many details, yet keeping details a click-away. We couldn't find an easy way in Rhapsody -24-
  25. 25. 6.1 to allow zooming in and out relationships, such as associating dependency links with a collaboration diagram. Zoom out Zoom in Figure 13: Zooming in and out object structures MDA09 –Correctness Rhapsody Score=4 In addition to enforcement of metamodel static typing rules, Rhapsody defines a set of built-in checks both for correctness and for completeness of model, Figure 14. Built-in rules include platform-specific checks such as file name constraints, single-inheritance, CORBA and COM-related constraints. It also includes platform independent checks such as the constraint that a singleton-stereotyped class must have a multiplicity of one. A model is automatically checked before code generation, but can also be selectively checked upon user request. Figure 14: Rhapsody built-in model checks -25-
  26. 26. MDA10 –Expressivity Rhapsody Score = 4 UML expresses PIM concepts and profiles add PSM information. While some profiles are already built-in, user can define custom profiles to cope with the ever-changing platform technologies. M.DA11 -Patterns and Genericity Rhapsody Score = 2 Rhapsody allows the definition of code generation patterns (usually called generics). The Rule Composer can be used to define the templates or scripts used for generating code corresponding to a specific profile tag or property. Rhapsody GUI, however, doesn't help the designer employ existing patterns in a graphical easy way. The user has to edit the tags and properties of each model element manually to connect parts of the pattern. MDA12 -Support for Refactoring Rhapsody Score = 4 Rhapsody provides a reverse engineering tool. It has been successfully able to import a given C++ source code into the corresponding UML model. Figure 15 illustrates how classes, methods, attributes, and method implementations were recovered from code. Figure 15: Result of Reverse Engineering -26-
  27. 27. MDA13 -Intra-Model Mappings Rhapsody Score=0 Rhapsody per se doesn't support model-to-model mappings. However, the underlying engine suite has a devoted tool, Mia-Transformation, which fully supports model-to- model mappings, including QVT language support. If this tool were added to Rhapsody, it would have scored 4 on this metric. MDA14 -Traceability Rhapsody Score=1 Although the MIA-Generation engine generates a transformation log that allows the user to trace the execution of different mapping scripts, Rhapsody doesn't expose this report. MDA15 -Life Cycle Rhapsody Score = 4 Rhapsody is a visual design tool for performing structural and systems modeling and developing object-oriented embedded software. It enables you to perform analysis to define and validate system requirements, design and specify the system architecture, validate and simulate the model to perform detailed system testing, document the system model by producing system specifications and generating application code. MDA16 -Standardization Rhapsody Score = 3 Supports UML 2.0, but only XMI 1.2 (i.e. can exchange only UML 1.3 models). Also the emerging QVT standard is supported by the underlying MDA engine used by Rhapsody. 4.2.3 The MIA-Software Tool Suite Although MIA-Software tool suite is described here as part of describing the Rhapsody UML tool, Model-In-Action tools suite is a very powerful MDA engine worthy of consideration. It is important to note that MIA-Software suite is not a modeling tool, but rather an engine that performs mappings. MIA-Metamodel Generation MIA-Generation Metamodel Repository (Java) Code Generators MIA-Transformation Model Transformers Figure 16: MIA-Software Tool Suite -27-
  28. 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. -28-
  29. 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. -29-
  30. 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 -30-
  31. 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. -31-
  32. 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 -32-
  33. 33. platform. For example we cannot use ‘Order’ as it is reserved word in SQL and same is the case with Java keywords. Fig 21: Screen shot of Domain model (PIM) diagrams The application model (PSM support): OptimalJ automatically transforms the Domain Model to the Application Model. OptimalJ’s Application Model maps to Platform Specific Model (PSM) and focuses on the targeted J2EE platform. The mapping and transformation from the Domain to Application Model is conducted by the Technology Patterns. PSM in OptimalJ is represented as the Application Model and it lies between domain model and code model. -33-
  34. 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 -34-
  35. 35. Fig 24: Screen shot of EJB model Fig 25: Screen shot of DBMS model -35-
  36. 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 model Using the implementation pattern the user explicitly invokes the ‘generate code’ code option, which generates all the relevant Java, JSP, XML files and other necessary for a J2EE application. The construction of code from simple domain class model within matters of minutes is really amazing. Also the ability to alter and make changes to model is handled will by OptimalJ. OptimalJ uses Jakarta Struts Framework which is open source in its J2EE server. The code is easy to understand and modify. User can also implements feature which are not available in the application model later on. In order to edit the code by user and keep the integrity of changes made in both the domain and applications models are reflected in the code, OptimalJ divides the files into free and guarded blocks. Guarded blocks are displayed with a blue background while the free blocks are in white background. User is unable to make any modification to guarded blocks. Fig 26: Screen shot of Code generated -36-
  37. 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 -37-
  38. 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 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. -38-
  39. 39. Criteria Description Evaluation Rank MDA01 Support for PIMs Full support for PSM. Strong 4 support with domain model which contains class models (static structure & service models). It restricts reserved names and if used lead to invalid PSM. Has ready to use metamodels. MDA02 Support for PSMs Strong support with application 4 model, abstraction over J2EE implementation and explicitly divided into web sub-models, bean and database. MDA03 Can Target Multiple PSMs Targets only one PSM. OptimalJ 1 largely targets J2EE as a Platform specific domain. Cannot edit metamodels. MDA04 Model Integration OptimalJ supports for model 2 integration e.g. the class and service part of the domain model in the transformation into the application model. Integrated relationship across diagrams. MDA05 System Evolution Strong support as changes in the 3 domain or app. models can be filtered down to lower levels. The transformation has to be redone in order for the changes to be reflected in the PSM or code model. MDA06 Model Interoperability OptimalJ uses UML 2.0 3 notations and can import can import/export XMI models MDA07 Mappings are modeled There are mappings and 2 mapping are in form of models. So users have limited access to models using Template programming Language -39-
  40. 40. MDA08 Support for Managing Model OptimalJ using a fixed point of 2 Complexity abstraction can represent most parts of both the domain and application models diagrammatically. Zooming in and out Object Structures . MDA09 Correctness It enforces well-formed rules on 3 both the app. and domain models. Prevent errors by disallowing reserved words MDA10 Expressivity Both domain and application 4 models provide the expected levels of expressivity at their levels of abstractions also expressivity using UML MDA11 Patterns Here when converting 3 application model into code, OptimalJ generates a number of patterns in the resulting code. MDA12 Support for Refactoring The code model is divided into 4 ‘free’ and ‘guarded’ blocks. By this method, changes inherit. Changes in upper layer only affect guarded part of code. MDA13 Intra-Model Mappings Support, changes in the database 3 tier is automatically reflected in the EJB tier. Also domain service model is created from domain class model. MDA14 Traceability Limited support for tracing. The 1 execution of mappings from domain to application model creates reference from the latter to the former. Disallow tracing of code generating mappings MDA15 Lifecycle OptimalJ covers virtually all the 4 aspects of the system life cycle including analysis, design, -40-
  41. 41. coding, debugging, project organization, testing and deployment. MDA16 Standardization It stores all the models in a MOF 4 repository. It uses standard UML 2.0 notations and can import/export XMI Table 4: Evaluation Table for OptimalJ 4.4 MagicDraw UML 10.0 MagicDraw [CD] is a visual UML modeling and CASE tool with teamwork support. designed for Business Analysts, Software Analysts, Programmers, QA Engineers, and Documentation Writers. MagicDraw provides full UML support for the 2.0 metamodel and notation and import of the UML 1.4 meta-model. It manages a true model representation which it stores as one large XML flat file. This is a dynamic and versatile development tool that facilitates analysis and design of Object Oriented (OO) systems and databases. It supports a custom OO model generator and provides the industry's best code engineering mechanism (with full round-trip support for J2EE, C#, C++, CORBA IDL programming languages, .NET, XML Schema, WSDL), as well as database schema modeling, DDL generation and reverse engineering facilities. Model elements can be drawn on multiple diagrams carrying their content into these new contexts. Some model elements can be displayed with varying degree of detail depending on context. For example, class can be shown in different class diagrams with some, none, or all attributes or operations showing, depending on what each class diagram is attempting to convey. MagicDraw also has a reporting capability which appears to externalize the report creation as an XML file containing the options and an XSL file specifying the report construction. This tool is suited for a wide variety of systems including real-time, client/server and distributed n-tier application design. MagicDraw runs on a wide variety of operating systems, everywhere where Java 1.4 or 1.5 is supported. We will now look into the features of MagicDraw that make it a powerful UML modeling tool and the support is provides towards MDA ( Model Driven Architecture). The features [NM] of MagicDraw have been described below: • Full support for UML 2.0: MagicDraw provides full support for UML 2.0 which include the class, use case communication, sequence, state, activity, implementation, package, component, composite structure, deployment diagrams. MagicDraw makes it easy to model all aspects of your system: requirements, static structure, deployment structure, activities, states, detailed action sequences, and much more. • Support of Extendable UML 2.0. : Allows the analyst or the designer to add some new model elements, (for instance specific class type for GUI components) -41-
  42. 42. he or she may extend UML by adding its own stereotypes, constraints, tagged values and even new appearance of the model element in the diagram (gif images can be attached to the specific stereotypes for a different display). Different fill colors and fonts may be used for this purpose as well. Custom appearance for diagram elements can be defined using SVG or bitmap images. • Language Specific UML Syntax Checker: Before the Code Generation, MagicDraw will check the correctness of the UML model and prompt you for changes, before any code gets generated. • Pattern Generator. MagicDraw allows Design patterns to be extendable. From version 6.0 all patterns are extendable. We can write your own patters with Java or JPython also. • Code Generation. Once model is created, it's time to begin coding. With MagicDraw's support of Java, C#, C++, and CORBA IDL, generating code frameworks becomes an efficient, streamlined process. And since MagicDraw also enables script creation for all major databases, database structure design has never been so easy. • Code Engineering Sets. Classes might be grouped together with their components into collections called "code engineering sets". The code engineering set helps keep classes and source code synchronized. We may reverse engineer or generate the code for a whole set at once. Also we may specify different properties for each code engineering set: location of the source code files and code generation properties. • Round-trip Engineering. Besides the source code generation and reverse engineering, MagicDraw allows parallel changes to the both source code and UML model. With the help of round-trip engineering technique, MagicDraw synchronizes those changes - new methods and attributes in the source code are added to the UML model and new items in the UML to the source code. • Integration with leading Java IDEs. MagicDraw can be integrated with various development environments like Eclipse, IBM WSAD and RAD, Borland JBuilder, IntelliJ IDEA, NetBeans, Sun Java Studio in a totally synchronized manner. • Source Code Reverse Engineering. If we have lots of unknown source code and want to get an idea what's in there, the source code can be reverse engineered. We may get an UML model and then generate class diagram from Java, EJB, Java bytecode, C#, CIL (MSIL), C++ or CORBA IDL source code. • Model Analysis Facilities. Consider a huge OO model with lots of dependencies, large class hierarchies and a change in a method B in a class A, other elements in the model will be influenced by this change, With MagicDraw we may select any model element and find out all other elements (classes, packages, etc.) that depends on it, or we may go in the opposite direction, select an element and ask for a list of model elements on which your selected element is dependent on. The dependency criteria also can be customized, it may be any combination of the following: association, inheritance, or realization relationship, class used as -42-
  43. 43. attribute type or operation parameter. It can find out all subclasses of the selected class and generate a new class diagram that shows the whole class hierarchy of derived classes. MagicDraw generates a package dependency diagram. A list of packages is analyzed upon dependencies between contained classes. • Test Case Modeling. Quality assurance engineer usually uses automated testing tools. Nevertheless he or she needs to define a strategy for structural and functional tests. Use case diagram is a tool for the test modeling. JUnit pattern will create a framework for test classes. • Eliminates tedious document preparation with automatic report generation. Use MagicDraw's automatic report generation engine to quickly produce comprehensive, professional requirements, software design documentation, and other types of reports in HTML, PDF, and RTF formats. MagicDraw UML generates standard artifacts that match your software development process. With Jython they can easily customized to fit the internal standards. • Portability. Independent of the hardware and the OS the developers have, it is very likely that MagicDraw can run on it. Windows 98/ME/NT/2000/XP, Solaris, Linux, and Mac OS X - to name a few. Below are a series of snapshots of MagicDraw 10.0 for UML Figure 28 : A General View of MagicDraw10.0 showing connection of components -43-
  44. 44. Figure 29: Business Profile Model diagram showing ordering of events Figure 30: Shows the Implementation diagram -44-
  45. 45. Figure 31: Shows The visual model differencing Figure 32: Shows the report generation wizard -45-
  46. 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 -46-
  47. 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. -47-
  48. 48. Figure 35: Shows the Code Engineering Wizard Evaluation of MagicDraw 10.0 for UML 2.0 This section will use the previously described guidelines to show how the tool ranks with each guideline for supporting MDA. The evaluation is shown in a tabular format. Criteria Description Evaluation Rank MDA01 Support for PIMs Tool allows Business Process 3 Models (BPM) to be created at a very abstract level without the details of implementation MDA02 Support for PSMs Supports creation of various 3 PSMs J2EE, EJB, etc. specific projects MDA03 Can Target Multiple PSMs Multiple PSMs are supported by 4 MagicDraw like Java, C++,C#, EJB, DDL. MDA04 Model Integration Various diagrams such as the 4 class, sequence, state are provided to model the application. MDA05 System Evolution Transformations have to be 2 performed again in real time so as to the changes made in the code or model can be reflected in the output code or model. MDA06 Model Interoperability Models can be exported using 3 the standard XMI documentation for inter-tool operability MDA07 Mappings are modeled Model to model mappings are 2 supported. MDA08 Support for Managing Model Various viewpoint diagrams are 4 Complexity provided to model the various levels of abstractions and more complex applications in an orderly manner. However the component diagrams are used to show the various methods and classes. -48-
  49. 49. MDA09 Correctness Provides the Language Specific 2 Syntax Checker which checks the UML code before code generation. MDA10 Expressivity High levels of abstraction are 4 supported in PIMs MDA11 Patterns Pattern are extendable and a 3 patter wizard is provided for the recognition and creation of patterns.. MDA12 Support for Refactoring Refactoring allows us 3 improving the code without changing the semantics of the model. MagicDraw provides support for refactoring and thus helps us improve the code without changing the behavior of the model. MDA13 Intra-Model Mappings Supports built in model to model 3 mappings. MDA14 Traceability Traceability is supported in 2 MagicDraw during model to model transformations with the help of trace files. MDA15 Lifecycle MagicDraw plays a role in the 3 complete life cycle of a system, which includes design, implementation, debugging and testing, and finally deployment. However the final deployment phase has to undergo some improvement for it to become a complete tool. MDA16 Standardization Standard UML 2.0 notations and 3 meta models are used with XMI as a standard to export and import documents. Table 5. Evaluation Table for MagicDraw UML 10.0 -49-
  50. 50. 5. Summary of Results In this section we summarize the results of MDA tool evaluation by comparing the scores received by each tools. Table 6 shows the scores each tool received for each of the features without taking into consideration the weight of each criterion. Together Rhapsody OptimalJ MagicDraw MDA01 3 2 4 3 MDA02 2 3 4 3 MDA03 1 3 1 4 MDA04 4 4 2 4 MDA05 1 4 3 2 MDA06 4 4 3 3 MDA07 4 3 2 2 MDA08 2 3 2 4 MDA09 4 4 3 2 MDA10 3 4 4 4 MDA11 4 0 3 3 MDA12 4 4 4 3 MDA13 0 1 3 3 MDA14 2 4 1 2 MDA15 4 4 4 3 MDA16 4 3 4 3 Table 6: Scores without Weights Figure 36 is a graphical representation of the scores without weights for each feature. Features have been grouped by level of importance. The first five, MDA 01, MDA 02, MDA 03, MDA 04 and MDA 07 are critical. Followed by 6 recommended features, namely, MDA 05, MDA 06, MDA 10, MDA 12, MDA 13, and MDA 16. And finally 5 optional features, MDA 08, MDA 09, MDA 11, MDA 14, and MDA 15. 4 3 Together Rhapsody 2 OptimalJ 1 MagicDraw 0 1 2 3 4 7 5 6 0 2 3 6 8 9 1 4 5 A0 A0 A0 A0 A0 A0 A0 A1 A1 A1 A1 A0 A0 A1 A1 A1 D D D D D D D D D D D D D D D D M M M M M M M M M M M M M M M M Figure 36: Tool Comparison Chart without Weights Table 6 and Figure 36 are useful in comparing how each tool support each of the features regardless of the relative importance of each feature. In order to make better calculations we used weighted feature scores, based on the weighting scheme described in Table 2. The graph in Figure 37 shows the result of weighted comparison of tools. -50-
  51. 51. MagicDraw OptimalJ Critical Recommended Rhapsody Optional Together 0 50 100 150 Figure 37: Tool Comparison Chart with Weights 6. Conclusions and Future Work MDA promises to revolutionize the software engineering discipline. It unifies the developer's activity of building models and writing code in a single integrated process. MDA increases productivity and allows platform independent modeling without worrying about the implementation platform. With an MDA tool, it is possible that the same PIM be transformed into more than one PSM for different platforms, and changes to platform technology effects the automated mappings, thus keeping the 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. -51-
  52. 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. -52-

×