OMG‘s MDA: An Overview copyright © 2001, MATHEMA AG OMG‘s MDA: An Overview OMG‘s MDA: An Overview Markus Völter

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 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:  CORBA  Java .NET  XMI/XML  Web-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 functionality  The 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 system  must be formal in the sense that each box and line has a clearly defined semantic meaning defined in terms of the MOF.  Examples include  source 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 Computing  Real 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 tools  manual 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 adtifact  All the models at the different stages can be kept in synch, keeping their different levels of abstraction  A 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

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 profiles  Example: 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-engineering  Cannot 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

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 way  or, 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 mappings  To automate the mappings  To 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  Yes, it is important! Conclusions THE END.