Model Driven Architecture in the Enterprise

1
Model Driven Architecture in the Enterprise

• Project Goal
• Brief MDA Overview and Refresher
• Evaluation Criteria
• Evaluation of MDA Supported Tools
• Borland Together Architect 2006 for Eclipse
• Logix Rhapsody Developer Edition
• OptimalJ Developer Edition by IntelliJ 4.0.00
• MagicDraw UML 10.0
• Modeling Tools Supporting MDA
• Project Current Status

2
Model Driven Architecture in the Enterprise

• Amit, Keyur, Sabhay and Saleh

3
Project Goals

• MDA Conception and Background
• Develop Criteria for MDA-Tools Evaluation
• Evaluation of Tools and Techniques
• Try selected MDA-tools
• Final Report with conclusions and future outlook

4
MDA Benefits

• Productivity
• Work is done mainly at the PIM level
• PIM-to-code transformation is automated
• Caveat need to define transformations, but they
  can be reused (hopefully)
• Portability
• PIMs are implementation-independent
• Incorporate new technologies by defining new
  (reusable) transformations
• Interoperability
• MDA tools should generate bridges
• Maintenance/Documentation
• Changes to the PIM can be filtered down to
  PSM/code by re-applying transformations

5
MDA Development Lifecycle

• MDA lifecycle similar to traditional lifecycle,
  but
• Emphasis on creation of formal models (i.e.,
  models that can be understood by computer)
• 2 types of models
• Platform-independent model
• Platform-specific model
• 3 types of transformations
• PIM-to-PIM
• PIM-to-PSM
• PSM-to-code
• Importance of transformation automation

requirements
Mostly text
MDA Process
analysis
PIM
design
PSM
coding
Code
testing
Code
deployment
6
Criteria Explanation

• MDA01 -Support for PIM
• a. Support of at least one PIM (Generic UML and
  domain-tagged UML profiles can be considered PIM)
• b. Support Multiple Viewpoint PIM
• c. PIM extensibility (custom Metamodels)
• d. PIM Metamodel editing facility

7
Criteria Explanation Contd

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

8
Criteria Explanation Contd

• MDA03 -Can Target Multiple PSM
• a. Target more than one PSM, e.g. J2EE and .NET
• b. PSM extensibility
• c. PSM Metamodel editing facility

9
Criteria Explanation Contd

• MDA04 -Model Integration
• a. Multiple diagrams of the same type
• b. Multiple diagram types
• c. Multiple viewpoints feed the same
  transformation

10
Criteria Explanation Contd

• MDA05 -System Evolution
• a. Source code management
• b. Forward propagation of changes
• c. Efficient-forward propagation of changes
  (updates only)

11
Criteria Explanation Contd

• MDA06 -Model Interoperability
• a. Import models from other legacy tools
• b. Import XMI
• c. Export XMI

12
Criteria Explanation Contd

• MDA07 -Mappings are modeled
• a. Legacy-customizable Model-to-Code mappings
• b. Quasi-standard QVT Model-to-Code mappings

13
Criteria Explanation Contd

• MDA08 -Support for Managing Model Complexity
• a. Locating modeling elements in models
• b. Zooming in and out

14
Criteria Explanation Contd

• MDA09 Correctness
• a. Modeling tool checks static models based on
  the corresponding metamodels
• b. Allow more rules to be defined and checked

15
Criteria Explanation Contd

• MDA10 Expressivity
• a. language "can" express any instance of the
  domain it is modeling
• b. support expressive higher levels of
  abstraction (PIM)

16
Criteria Explanation Contd

• MDA11 -Patterns and Genericity
• a. Use of ready-made patterns in code generation
• b. Use of ready-made patterns in transformations
• c. User-defined patterns

17
Criteria Explanation Contd

• MDA12 -Support for Refactoring
• a. Generate Model given Code
• b. Propagate code changes to model (roundtrip)

18
Criteria Explanation Contd

• MDA13 -Intra-Model Mappings
• a. Built-in Model-to-Model Mappings
  (transformations)
• b. Immediate propagation of changes between
  models related by transformations
• c. Legacy-customizable transformations
• d. QVT Model-to-Model mappings

19
Criteria Explanation Contd

• MDA14 -Traceability
• a. PSM elements reference PIM elements where they
  originate
• b. Reverse propagation of changes in PSM

20
Criteria Explanation Contd

• MDA15 -Life Cycle
• a. Analysis,
• b. Design,
• c. Implementation,
• d. Testing

21
Criteria Explanation Contd

• MDA16 -Standardization
• a. UML
• b. MOF
• c. XMI
• d. QVT

22
Together Architect 2006 for Eclipse

• Borland Together Architect 2006 for Eclipse is a
  comprehensive modeling solution for software
  architects.
• Uses an Eclipse environment with built modeling
  support by Together Architect.
• Enables architects to design, develop, and
  communicate enterprise application architectures.
  
• Designers can create UML and business process
  models.

23
Together Architect 2006 for Eclipse

• Support for Model Driven Architecture (MDA)
• Meta-models
• Tool has a large library of meta-model
  definitions for technology mapping
• These meta-models can be viewed in meta-model
  browser view.
• There is no support for editing existing
  meta-model or creating own meta-model
• Meta-models are used for transforming models into
  models and code.

• Metamodel browser screenshot

24
Together Architect 2006 for Eclipse

• Support for Model Driven Architecture (MDA)
• Model to Model Transformations
• Open new MDA transformation project
• Uses OMGs Query View Transformation (QVT) in
  model-to model transformations
• Specify input and output meta-models to import in
  QVT script
• Transforms and instance of one Together or EMF
  model to an instance of another Together or EMF
  model
• QVT Editor and Eclipse QVT Debugger enable code
  sensitive editing and step by step trace of the
  execution.

• Example of the QVT transformation script file

25
Together Architect 2006 for Eclipse

• Support for Model Driven Architecture (MDA)
• Model to Text (Code) Transformations
• Open new MDA transformation project
• Uses Eclipse Modeling Framework
• Specify input meta-model to be imported in the
  transformation code
• The model to text transformation code is written
  in JAVA
• Transforms an instance of one Together or EMF
  model into an arbitrary text output

• Example of transformation code in JAVA

26
Together Architect 2006 for Eclipse

• Support for Model Driven Architecture (MDA)
• Profiles
• Profiles are used to manage a collection of
  tagged values and stereotypes.
• Together allows you to design your own profiles
  with the help of Profile Definition Project.
• Create profile plug-ins and share them with your
  team members.
• Steps
• Create Profile
• Deploy Profile
• Apply Profile

27
Together Architect 2006 for Eclipse

• Tool Evaluation

Support for PIMs (3) Tool allows Business Process Models (BPM) to be created at a very abstract level without the details of implementation
Support for PSMs (2) Tools support creation of J2EE specific projects
Can Target Multiple PSMs (1) Together Architect supports mainly J2EE
Model Integration (3) Able to use multiple diagrams such as class, use case, sequence, state, etc. to create a single application
28
Together Architect 2006 for Eclipse

• Tool Evaluation

System Evolution (1) When changes in the input model are made, the transformed model or code is not update in real time. The transformation has to be redone in order for the changes to be reflected in the output model or code.
Model Interoperability (4) Together Architect 2006 is able to export models as a standard XMI 2.0 documentation for inter-tool operability
Mappings are modeled (4) Tool provides QVT language support for model to model mappings and transformation code editor and debugger for JAVA transformation code mapping for model to code transformations.
Support for Managing Model Complexity (2) 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.
29
Together Architect 2006 for Eclipse

• Tool Evaluation

Correctness (4) Together provides a wide variety of audits, ranging from design issues to naming conventions. You can select the specific rules to which your source code should conform to.
Expressivity (3) Supports high level of abstraction in PIMs
Patterns and Genericity (4) 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.
Support for Re-factoring (4) 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 Eclipse Java Development Tooling 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.
30
Together Architect 2006 for Eclipse

• Tool Evaluation

Intra-Model Mappings (0) Does not support built in model to model mappings. Mapping has to be developed by programmers using QVT language
Traceability (2) 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.
Lifecycle (4) 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
Standardization (4) Together Architect 2006 uses standard UML notation and can import or export models as XMI documents
31
I-Logix Rhapsody
32
I-Logix Rhapsody

• Ignores PSM from PIM directly to Code
• Uses Mia-Software Generation Tool
• Customizable code generation rules
• Code generation
• Other Mia-Software Tools (not used!)
• Mia-Metamodel Generation
• Metamodel definition
• Mia-Software Transformation
• Model-to-Model transformation
• Customizable transformation rules

33
Criteria Explanation 1

• MDA01 -Support for PIM
• a. Support of at least one PIM (Generic UML and
  domain-tagged UML profiles can be considered PIM)
• b. Support Multiple Viewpoint PIM
• c. PIM extensibility (custom Metamodels)
• d. PIM Metamodel editing facility

• Rhapsody Score3
• Full support of PIM
• Has a set of ready-to-use metamodels
• Extensible to other metamodels (using
  Mia-Metamodel Generation)

34
Criteria Explanation Contd

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

• Rhapsody Score1
• No support of middleware
• PIM-to-Code direct generation

35
Criteria Explanation Contd

• MDA03 -Can Target Multiple PSM
• a. Target more than one PSM,e.g. J2EE and .NET
• b. PSM extensibility
• c. PSM Metamodel editing facility

• Rhapsody Score (2)
• Generates C, C, Java and Ada code
• It allows definition of Code Generation Rules

36
Criteria Explanation Contd

• MDA04 -Model Integration
• a. Multiple diagrams of the same type
• b. Multiple diagram types
• c. Multiple viewpoints feed the same
  transformation

• Rhapsody Score 2
• Integrated relationships across diagrams
• UML Diagrams integration

37
Criteria Explanation Contd

• MDA05 -System Evolution
• a. Source code management
• b. Forward propagation of changes
• c. Efficient-forward propagation of changes
  (updates only)

• Rhapsody Score4
• Method code is managed by tool
• Generate updates only

38
Criteria Explanation Contd

• MDA06 -Model Interoperability
• a. Import models from other legacy tools
• b. Import XMI
• c. Export XMI

• Rhapsody Score4
• Rose Import
• XMI import/export

39
Criteria Explanation Contd

• MDA07 -Mappings are modeled
• a. Legacy-customizable Model-to-Code mappings
• b. Quasi-standard QVT Model-to-Code mappings

• Rhapsody Score 3
• Code generation mappings.
• Extensible by user
• QVT-specified
• Limited to the supported languages (C, C, Ada,
  Java)

40
Criteria Explanation Contd

• MDA08 -Support for Managing Model Complexity
• a. Locating modeling elements in models
• b. Zooming in and out

• Rhapsody Score 3
• Zooming in and out Object Sturctures

41
Criteria Explanation Contd

• MDA09 Correctness
• a. Modeling tool checks static models based on
  the corresponding metamodels
• b. Allow more rules to be defined and checked

• Rhapsody Score(2)
• Checks UML static rules

42
Criteria Explanation Contd

• MDA10 Expressivity
• a. language "can" express any instance of the
  domain it is modeling
• b. support expressive higher levels of
  abstraction (PIM)

• Rhapsody Score (4)
• UML expressivity
• User-defined profiles increase expressivity

43
Criteria Explanation Contd

• MDA11 -Patterns and Genericity
• a. Use of ready-made patterns in code generation
• b. Use of ready-made patterns in transformations
• c. User-defined patterns

• Rhapsody Score (0)
• Apparently no support

44
Criteria Explanation Contd

• MDA12 -Support for Refactoring
• a. Generate Model given Code
• b. Propagate code changes to model (roundtrip)

• Rhapsody Score (4)
• Supports roundtrip engineering

45
Criteria Explanation Contd

• MDA13 -Intra-Model Mappings
• a. Built-in Model-to-Model Mappings
  (transformations)
• b. Immediate propagation of changes between
  models related by transformations
• c. Legacy-customizable transformations
• d. QVT Model-to-Model mappings

• Rhapsody Score1
• Apparently no intra-model mappings
• The underlying MDA tool (Mia-Transformation)
  fully supports this feature with QVT Model to (4)

46
Criteria Explanation Contd

• MDA14 -Traceability
• a. PSM elements reference PIM elements where they
  originate
• b. Reverse propagation of changes in PSM

• Rhapsody Score4
• Allows tracing of code generation mappings

47
Criteria Explanation Contd

• MDA15 -Life Cycle
• a. Analysis,
• b. Design,
• c. Implementation,
• d. Testing

• Rhapsody Score (4)
• Entire Cycle,
• Includes simulation of complex state machines

48
Criteria Explanation Contd

• MDA16 -Standardization
• a. UML
• b. MOF
• c. XMI
• d. QVT

• Rhapsody Score (3)
• All supported
• QVT is supported by the underlying tool, but not
  used in Rhapsody

49
OptimalJ by Compuware

• Used OptimalJ Developer Edition by IntelliJ
  4.0.00 for evaluation
• Developers can perform system design, coding,
  debugging, project organization, testing and
  deployment.
• OptimalJ is a MDA-support tool by Compuware that
  supports both model-to-model and model-to-code
  transformation.

50
OptimalJ
The OptimalJ Framework

• Patterns in OptimalJ are based on the
  proprietary Template Pattern Language (TPL)

51
Domain Model (PIM)

• -Displayed in form of UML Diagrams and XMI
  models
• Domain model is subdivided into
• Class Model Graphical rep. of classes in the
  system and relationships between them
• Service Model used to specify the system
  behavior in an implementation independent way
  using concepts like Domain Views, Domain Service
  Attributes and Domain Service Operations

52
Application Model (PSM)
1 Presentation (Web) model - contains the
information required to generate a web front-end
for the application. 2 Business Logic (EJB)
model The Enterprise Java Bean partial is a
middleware layer that deals with, for example,
transactions, security, persistency and
scalability. 3 Database (DBMS) model The
Database model supports DBMS elements like
schemas, tables and keys.
53
Database Model (DBMS) Screenshot
54
Code Model

• Generates all the relevant Java, XML files and
  other necessary for a J2EE application.
• OptimalJ divides the files into free and guarded
  blocks.
• Can be customized and automated Changes

55
OptimalJs Cycle
56
Application Server Example

• Applications can be deployed from OptimalJ
  itself

57
OptimalJ evaluation
Support for PIMs Strong support with domain model which contains class models (static structure service models). It restricts reserved names.
Support for PSMs Strong support with application model, abstraction over J2EE implementation and explicitly divided into web sub-models, bean and database
Can target Multiple PSMs OptimalJ largely targets J2EE as a Platform specific domain
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.
58
OptimalJ evaluation contd
System Evolution Strong support as changes in the domain or app. models can be filtered down to lower levels.
Interoperability OptimalJ uses UML 2.0 notations and can import can import and export XMI models
Mapping are modeled There are mappings and mapping are in form of models. So users have limited access to models
Support for managing model complexity OptimalJ using a fixed point of abstraction can represent most parts of both the domain and application models diagrammatically.
59
OptimalJ evaluation contd
Correctness It enforces well-formed rules on both the app. and domain models. Prevent errors by disallowing reserved words.
Expressivity Both domain and application models provide the expected levels of expressivity at their levels of abstractions
Patterns and Genericity Here when converting application model into code, OptimalJ generates a number of patterns in the resulting code.
Support for Re-factoring The code model is divided into free and guarded blocks. By this method, changes inherit.
60
OptimalJ evaluation contd
Intra-model Mapping Full support, changes in the database tier are automatically reflected in the EJB tier. Also domain service model is created from domain class model.
Traceability Limited support for tracing. The execution of mappings from domain to application model creates reference from the latter to the former
Life-Cycle OptimalJ covers virtually all the aspects of the system life cycle including design, coding, debugging, project organization, testing and deployment.
Standardization It uses standard UML 2.0 notations and can import/export XMI. It stores all the models in a MOF repository.
61
MagicDraw UML 10.0

• A handy UML editor. A customizable GUI which
  helps us model ideas in UML as quickly and
  straightforwardly as possible. The entire UML 2.0
  notation and semantics and meta-model are
  supported.
• Object Oriented model analysis tool. MagicDraw
  can generate package dependency diagram, recover
  and display inheritance tree, or track any other
  kind of relation such as dependency, association,
  realization.

62
Features of MagicDraw
Support for MDA

• Accelerates your 'travel time' between modeling
  domains Model transformations can be quickly
  transformed back and forth from one modeling
  domain to another. MagicDraw UML allows model
  transformations both ways from Platform
  Independent Model (PIM) to Platform Specific
  Model (PSM) and from PSM to PIM. We can produce
  many specific models, such as XML Schema, DDL, or
  our customized specific model from a generic one.
• UML to Generic DDL
• DDL to UML
• UML to Oracle DDL
• UML to XML

63
MagicDraw UML 10.0
Support for MDA

• A powerful code engineering tool. Construct UML
  model, generate source code from it, write more
  code by hand, then reverse the code, make some
  changes , and merge your model with the code
  again. No details are lost, no matter which way
  (backward or forward) you go. Support for Java,
  C, C, CORBA IDL, DDL.
• Supports Business Process Modeling Business
  Model can be taken as a basis and further
  elaborated, thus enabling the to the point
  development and implementation of business
  process.

64
MagicDraw UML 10.0

• MagicDraw provides a means for architectural view
  modeling to define system and software
  architecture in all 41 views, and at different
  abstraction levels.
• 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.

65
MagicDraw UML 10.0

• Integrated with the following MDA Engines
• ArcStyler
• AndroMDA
• JeeWitz
• Bm Generator
• E2E Bridge
• Supports integrated development environment by
  meshing MagicDraw with Eclipse, IBM's WebSphere
  Application Developer and Rational Application
  Developer, Borlands JBuilder, IntelliJ IDEA,
  NetBeans, Suns Java Studio, BEA WebLogic
  Workshop.

66
MagicDraw UML 10.0

• How well does it conform to the guidelines?

Support for PIMs(3) a. Supports one PIM (Generic UML)
Support for PSMs(3) a. Supports at least one PSM (platform in the sense of middleware) b. Platform-tagged UML profiles count as PSM (PIM to PSM is a critical requirement of MDA)
Can target multiple PSMs(4) a. Target more than one PSM, e.g. J2EE and .NET b. PSM extensibility c. PSM Metamodel editing facility
Model Integration(4) b. Multiple diagram types c. Multiple viewpoints feed the same transformation
67
MagicDraw UML 10.0

• How well does it conform to the guidelines?

System Evolution(2) b. Forward propagation of changes
Interoperability(3) b. Import XMI c. Export XMI
Mappings are modeled(2) a. Legacy-customizable Model-to-Code mappings
Support managing model complexity(4) a. Locating modeling elements in models b. Zooming in and out c. Organizing generated code and document
68
MagicDraw UML 10.0

• How well does it conform to the guidelines?

Correctness(2) a. Modeling tool checks static models based on the corresponding metamodels
Expressivity(4) b. support expressive higher levels of abstraction (PIM)
Patterns and Genericity(3) b. Use of ready-made patterns in transformations c. User-defined patterns
Support for Refactoring(3) b. Propagate code changes to model (roundtrip)
69
MagicDraw UML 10.0

• How well does it conform to the guidelines?

Intra-model mappings(3) a. Built-in Model-to-Model Mappings (transformations)
Traceability(2) a. PSM elements reference PIM elements where they originate
Lifecycle (3) a. Analysis, b. Design, c. Implementation
Standardization(3) a. UML b. MOF
70
Comparison Chart

• Chart comparing all the tools

71
Results

• Results based on comparison chart
• MagicDraw 48
• Rhapsody 47
• OptimalJ 47
• Together 45

72
Future Outlook

• Through our research, we discovered that all of
  the MDA tools investigated are not full compliant
  to MDA specification. Each of them is missing one
  or more of the MDA features and need
  improvements
• Comparison of Query View Transformation (QVT)
  with transformation languages and templates of
  current existing MDA tools in the market.
• Evaluation or comparison of MDA tools based on
  some specific domain telemedicine, healthcare,
  aviation etc

73
Questions?