OMG‘s MDA: An Overview Markus Völter markus.voelter@mathema.de

1. OMG‘s MDA:An Overview Markus Völter markus.voelter@mathema.de OMG‘s MDA:An Overview

2. 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

3. 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. 

4. 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.

5. 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

6. 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. 

7. 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.

8. 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)

9. MDA Core Models • 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.

10. Core Models and Platforms • 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

11. Traceability • 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.

12. MDA Application Development process • Note that this process can be multi-staged!

13. Example using the EDOC core model and J2EE

14. Types of Mappings • 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

15. Types of Mappings cont‘d • 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...)

16. Specifying and automating mappings • 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.

17. Specifying and automating mappings cont‘d • 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.

18. Example: Account (from the OMG) • We start with a PIM, basically the analysis model. • We already use EDOC stereotypes.

19. Example: Account (from the OMG) II • 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.

20. Example: Account (from the OMG) III • 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).

21. Example: Account (from the OMG) IV • The next step is a PSM to PSM mapping, that produces an „IDL Model“. • This can now be implemented in the traditional way.

22. The Role of Packages • 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:

23. Example: Account (from the OMG) V • The different models would be contained in different packages. Traceability would be available (in practice only, if tool support is available!)

24. A note on architecture and MDA • 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.

25. Ingredients • 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!

26. Tool support • 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...

27. Tool support II • 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.

28. Conclusions • 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! THE END.