1 / 28

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

OMG‘s MDA: An Overview Markus Völter markus.voelter@mathema.de. 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

kynton
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related