omg‘s mda: an overview copyright © 2001, mathema ag omg‘s mda: an overview omg‘s mda: an...
Post on 19-Dec-2015
226 views
TRANSCRIPT
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]
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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.
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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.
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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.
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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.
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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)
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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>>
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
Example using the EDOC core model and J2EE
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
We start with a PIM, basically the analysis model. We already use EDOC stereotypes.
Example: Account (from the OMG)
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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
OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG
OMG‘s MDA: An Overview
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.