omg‘s mda: an overview markus völter [email protected]

OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG

OMG‘s MDA: An Overview

OMG‘s MDA:An OverviewOMG‘s MDA:An Overview

Markus Völter [email protected]



Roadmap

What is MDA? MDA core idea Models Core models and platforms The concept of traceability Application development process Types of model mappings Specifying and automating mappings The Account example The Role of packages A note on architecture and MDA MDA Ingredients Tool Support Conclusions



What is MDA?

This is what the OMG says: (copied from their website at www.omg.org/mda)

MDA provides an open, vendor-neutral approach to the challenge of interoperability, building upon and

leveraging the value of OMG's established modeling standards: Unified Modeling Language (UML); Meta-Object Facility (MOF); and Common Warehouse Meta-model (CWM). Platform-independent Application descriptions built using these modeling standards can be realized using any major open or proprietary platform, including CORBA, Java, .NET, XMI/XML, and Web-based platforms.



The Problem of Middleware Proliferation

Middlewares: CORBA, COM, DCOM, MTS/COM+, RMI, EJB, CCM, MoM, MQSeries, JMS, HTTP, XML, SOAP

Common Services: transactions, security, persistence, directory, event handling, load balancing, failover.

It‘s hard to standardize on a single middleware platform; within an organization, and over time.

MDA tries to separate business models from their technical realization.



What is MDA? (cont‘d)

They want to solve (once more ) the Interoperability problem

It is based on OMG‘s available modelling standards: Unified Modeling Language (UML)Meta-Object Facility (MOF)and Common Warehouse Meta-model (CWM).

The goal is to build platform-independent applications



What is MDA? (cont‘d)

These platform-independent applications will be able to run on several major (and upcoming) platforms:CORBAJava.NETXMI/XMLWeb-based platforms.



MDA Core Idea

Core concept of MDA is the following separation:the specification of system functionalityThe specification of the implementation of that

functionality on a specific technology platform.

The same functional model should be able to run on several different technical implementation platforms.

To achieve this, MDA defines mappings on the platforms as part of the (upcoming) standards.



Models

A model is a representation of a part of the function,

structure and/or behavior of a systemmust be formal in the sense that each box and line

has a clearly defined semantic meaning defined in terms of the MOF.

Examples includesource code (a model that can be executed by a

machine)A set of IDL interfaces (a model that can be used

with any CORBA implementation)A UML-based specification (a model whose

properties can be expressed graphically via diagrams, or textually via an XML document)



The basic modelling standards apply: UML, MOF, CWM

On top of this, a small number of core models will be defined:Enterprise ComputingReal Time Computing...

Core Models are currently known under the name of UML Profiles.

Core Models serve as a metamodel for all the applications in the particular domain.

MDA Core Models



The core (meta-)models are platform independent!

Platform specialisits define mapping to the target platforms:automatic mapping toolsmanual mapping rules, idioms or patterns

The result of the mapping is, again, a UML model, this time target platform specific.This is because specific (annotated) UML models

contains mode semantic information than XML, IDL, or Java code

Core Models and Platforms



There is one very important concept: traceability.

The artifacts that evolve through different modelling levels (analysis, design, implementation) will all be modelled and linked!

You can see the history of an adtifactAll the models at the different stages can be kept in

synch, keeping their different levels of abstractionA change in one model can be propagated to the

other models, if rules for such propagations exist.

Traceability



Note that this process can be multi-staged!

MDA Application Development process

PIM

PSM

Core Model

PSM-Metamodel

concre te leve lm eta leve l

<<instanceof>>

<<instanceof>>



Example using the EDOC core model and J2EE



PIM PIM: Mappings when there are no platform-specific information is needed.Examples: (Domain-) Specialization, Analysis to design

(to some degree)

PIM PSM: A sufficiently refined PIM is transferred to the execution-environment PSM.Mapping is based on platform characteristics ideally

modelled in UML using specific profilesExample: Logical component model mapped to EJB or

CCM

Types of Mappings



PSM PSM: Required for realization and deployment of assets. Depending on the concrete target, more refinement

of the PSM might be required.Examples: EJB 1.1 model to Weblogic 6.1

PSM PIM: Used for mining PIMs from conrete PSMs. Typically called re-engineeringCannot be fully automated (we already have these

problems today...)

Types of Mappings cont‘d



The idea is to let the user specify some aspects of the mapping, but he need to know how something is actually implemented.

The PIM is done independent of any technology projection.

Then, the PIM (or a traced copy of it!) is annotated with target-platform specific information.

A (traced) PSM is generated from the annotated PIM.

This PSM can be copied, annotated and generated again to perform a PSM to PSM mapping for the concrete execution environment.

Specifying and automating mappings



The MOF (and XMI) is used as a basis for such mappings.

Annotation will be done using profiles: metamodel information, OCL, stereotypes, and tool-specfic annotations.

The Mapping is generally based on the source and target metamodels and a generic mapping among them.

The Mapping can require the user to specify additional information not necessarily available in the source model.

Specifying and automating mappings cont‘d



We start with a PIM, basically the analysis model. We already use EDOC stereotypes.

Example: Account (from the OMG)



We select CORBA as the target environment. Based on the metamodels, the mapping automatically

produces the following PSM:

Note that this PSM can now be refined even further, exploiting the features of a specific ORB.

Example: Account (from the OMG) II



We could similarly map this to EJB, refining it further to a specific J2EE server.

Note that sometimes more that one mapping could be possible:In EJB, we could use

Entity Beans to represent entities,Or use the Type Manager pattern

Additional information to make such decisions must be specified. For example, we could tag the account as shared and low-rate (resulting in an Entity Bean) or non-shared and high-rate (using a type manager).

Example: Account (from the OMG) III



The next step is a PSM to PSM mapping, that produces an „IDL Model“.

This can now be implemented in the traditional way.

Example: Account (from the OMG) IV



MDA uses UML packages to group the different models that still belong together.

Packages can be a refinement (mapping) of each other:

Packages can contain the same information seen from different viewpoints:

The Role of Packages

P1 P2view point correspondence

<<abstract>>P1

<<refined>>P2

refi

ne

me

me

nt



The different models would be contained in different packages. Traceability would be available (in practice only, if tool support is available!)

Example: Account (from the OMG) V



The (automatic) mapping can only work if either many things are always done the same wayor, if the user specifies enough additional for a

mapping.

Thus, the more „semantic“ information an architecture (or its model) contains, and the less atomic building blocks it contains, the more efficient the mapping can be.

This is simplified by using reference architectures, architectural templates, patterns or styles.

A note on architecture and MDA



MOF is used to specify metamodels XMI can be used to exchange models among tools UML is used for modelling Profiles and stereotypes are used to specify additional

information The task forces (med, transportation, business,

manufactuting, transportation, telecon...) will become core models

CORBA and CCM will be one (OMG‘s preferred) execution environment

CORBA Services will be used to implement the technical, platform-specific aspects

... Thus, all OMG assets now ship under a new name!

Ingredients



Tool support is essential:For modelling (as already the case today)To create and manage metamodels and their

mappingsTo automate the mappingsTo track the refinement and viewpoint relationships

(traceability).

At the MDA website there are 40 or so tools listed...

Tool support



One of the really available tools is iO‘s ArcStyler:

It is based on an archtectural style convergent components

It provides support from CRC-cards over analysis, design and J2EE server specific deployment

The modelling part is integrated with Rose.

It provides refinements for all relevant J2EE application servers.

Tool support II



MDA is certainly an interesting idea. The concepts are not all new, however. Because of the OMG‘s „political“ power, MDA will

become important.

So: If a suitable architectural metamodel for a domain can be devised, an MDA-based approach can improve productivity significantly!

More info at www.omg.org/mda

Yes, it is important!

Conclusions

THE END.

omg‘s mda: an overview markus völter [email protected]

Documents