in black and white
Main menu
Home About us Share a book
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Model driven architecture applying MDA to Enterprise computing - Frankel D.

Frankel D. Model driven architecture applying MDA to Enterprise computing - Wiley & sons , 2003. - 355 p.
ISBN: 0-471-31920-1
Download (direct link): modeldrivenarchitecture2003.pdf
Previous << 1 .. 50 51 52 53 54 55 < 56 > 57 58 59 60 61 62 .. 123 >> Next

XMI's Reverse Mapping
There are, of course, XML DTDs and Schema that are not XMI-compliant and that various standards bodies or corporations have already adopted. We cannot ignore this reality.
Thus, the new XMI specification does more than extend XMI to cover XML Schema. It also defines a reverse mapping for transforming any arbitrary non-XMI XML DTD or Schema into a MOF metamodel. It even defines a way to produce a MOF model from a non-XMI XML document for which there is no DTD or Schema, although it is preferable to reverse engineer from a DTD or Schema.
As Figure 5.30 illustrates, you can start with a DTD or Schema; produce a MOF metamodel; and then use the MOF-IDL, MOF-Java, and MOF-XML forward mappings to produce MOF-compliant APIs as well as XMI DTDs and Schemas. In other words, it's possible to directly infer MOF-based APIs and XMI DTDs and Schemas from non-XMI XML DTDs and Schemas.
16 [HUTN]
The Meta Object Facility (MOF) 137
Non-XMI XML DTD or Schema
XML-MOF Reverse Mapping
Mapping (JMI) Mapping (XMI)
MOF-Compliant MOF-Compliant XMI
CORBA APIs Java APIs DTD or Schema
Figure 5.30 Using the XML-MOF reverse mapping.
This, in turn, makes it possible to automatically generate code that transforms a non-XMI XML document into MOF-compliant CORBA objects, Java objects, and/or XMI documents. Thus, the groundwork is in place for MOF tools to manage the metadata even though the original format description is not MOF-based.
As we've pointed out, a non-XMI XML DTD or Schema cannot express all the semantics that a MOF metamodel can. This has ramifications for the reverse mapping. For example, there is not enough information in a DTD or Schema to enable a reverse mapping engine to determine whether an association in the resulting MOF metamodel should use composite aggregation, since XML does not have a concept similar to composition. Thus, the reverse mapping always defaults to ordinary associations.
However, the reverse mapping is a parameterized mapping. The parameters can be used to fill in semantic information missing from the DTD or Schema. For example, the modeler can set a parameter to determine whether a particular association produced by the reverse mapping should be ordinary or use composite aggregation.
Beyond the standardized mapping parameters, there is further opportunity to semantically enhance the metamodel produced via the reverse mapping, by writing invariant rules in OCL that may have been documented only informally for the DTD or Schema. Therefore, typically a MOF metamodel produced by a reverse mapping tool should be enhanced by a modeler before running it through a compiler that executes any of the MOF forward mappings, assuming that sufficient documentation about the semantics of the original DTD or Schema is available.
138 Chapter 5
Be aware, though, that there are certain kinds of enhancements to the reverse-engineered MOF metamodel that you can make that actually change the structure of the model. For example, since DTDs have no inheritance and Schemas only have single inheritance, there may be opportunities to use MOF multiple inheritance to streamline the metamodel produced via reverse engineering. Changes of this nature carry a price in that, once you make them, the abstract syntax of the MOF metamodel in its altered form cannot be directly inferred from the combination of the non-XMI DTD or Schema and the reverse mapping parameters. This limits the degree to which you can automatically generate code to transform non-XMI XML documents into MOF-compliant Java objects, CORBA objects, and XMI documents. Once you cross this line, you are going to need some hand coding to do that transformation.
The MOF has some limitations that are worth pointing out. Most MDA experts already recognize these shortcomings, and there are plans in place to address most of them.
Lack of Coverage of Graphical Notation
MOF does not have a language for defining graphical notation. Thus, if you require a graphical notation optimized for a particular kind of model defined by a metamodel, there is no standard way to declare that notation and to associate notational constructs with the constructs defined by the metamodel's abstract syntax.
Consequently, standards-based MDA development environments that support new graphical notations by reading standardized notation descriptions are not possible. As we have discussed previously, UML profiling supports only a limited ability to define new graphical notations, so it does not fill this gap.
An MDA development environment could support the ability to define new graphical notations elegantly, but it would have to do so in a proprietary fashion given the lack of support by standards.
Lack of Support for Versioning
Good metadata repository tools that can scale to enterprise demands must support versioning of models. It should be possible to hold multiple versions of a model in a repository. In fact, it should be possible to traverse forward and backward over a series of versions of a model.
Previous << 1 .. 50 51 52 53 54 55 < 56 > 57 58 59 60 61 62 .. 123 >> Next