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

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 .. 48 49 50 51 52 53 < 54 > 55 56 57 58 59 60 .. 123 >> Next

Thus, the implementations of the Java APIs that a DOM tool provides permit a client to delete a table without deleting its columns. They permit a client using the Java DOM APIs to add a column to a table that has the same name as the table. Programmers have to write extra Java code on top of DOM to enforce these rules. Furthermore, programmers may well have to write the enforcement code again when technology volatility forces them to port to environments other than Java and XML.
It may appear that the DOM tool has an advantage in that it parses the XML dynamically, rather than reading the DTD and then generating the parsing code, which has to be compiled and deployed. However, some MOF tools can read metamodels dynamically at runtime to drive their management of metadata. So far, we have talked mostly about scenarios in which MOF tools read metamodels at design time and statically generate code; however, dynamic interpretation of metamodels at runtime is also possible, as we mentioned earlier.
A side benefit of the MOF approach is that the programming model presented by the generated Java APIs reflects the structure of the metadata. Operations such as getColumn make metadata manipulation rather intuitive for the client programmer. By contrast, the DOM APIs are totally generic and their semantics are all about DOM parse trees.
What we have said about DOM can be said about the other popular XML parsing API, SAX. SAX is also driven by XML DTDs that are semantically thin in comparison to the metamodels that drive MOF tools. This limits the intelligence of SAX tools. SAX is also no different from DOM when it comes to managing technology volatility.
Another Look at MOF Self-Description
MOF self-description—that is, the fact that MOF is defined via MOF—has some interesting practical consequences. As we've discussed, when we apply XMI's MOF-XML mapping to a MOF-compliant metamodel, we get an XMI DTD for representing models that conform to that metamodel. But when we apply XMI's
132 Chapter 5
MOF-XML mapping to "the" MOF Model—that is, to the MOF model of MOF itself—we get an XMI DTD for representing MOF-compliant metamodels. This DTD is often called "the" MOF DTD, and it is an official OMG standard DTD. For each of the OMG's standard metamodels, the OMG has a standard XMI document that represents the metamodel and that validates against "the" MOF DTD.
Figure 5.26 shows the fragment of "the" MOF DTD that defines the format for representing an instance of MOF Class. Note the isSingleton property, which is visible in Figure 5.12's fragment of "the" MOF Model's abstract syntax. The other properties are inherited from superclasses of Class.
Thus, when a MOF generator transforms a metamodel, it can produce two kinds of XMI artifacts:
■ An XMI document that contains all the properties of all of the elements of the metamodel, which are M2 elements. This document validates against "the" MOF DTD.
■ A DTD for representing Ml instances of the metamodel's M2 elements.
It is important to understand the difference between these two artifacts. Unlike the XMI document, which validates against "the" MOF Model, the DTD does not contain all of the properties of the metamodel. There is some loss of information because the intent of the DTD is merely to describe a format for representing M1 instances of the metamodel's M2 elements. That format does not contain all of the metamodel's properties.
<!ELEMENT Model:Class (Model:ModelElement.name|
Model:ModelElement.annotation|
Model:ModelElement.container|
Model:ModelElement.constraints|
Model:Namespace.contents|
Model:GeneralizableElement.supertypes|
XMI.extension)*>
<!ATTLIST Model:Class name CDATA #IMPLIED annotation CDATA #IMPLIED isRoot (true|false) #REQUIRED isLeaf (true|false) #REQUIRED isAbstract (true|false) #REQUIRED
visibility (public_vis|protected_vis|private_vis) #REQUIRED
isSingleton (true|false) #REQUIRED
container IDREFS #IMPLIED
constraints IDREFS #IMPLIED
contents IDREFS #IMPLIED
supertypes IDREFS #IMPLIED
%XMI.element.att; %XMI.link.att;>
Figure 5.26 A fragment of “the" MOF DTD (for MOF 1.4).
The Meta Object Facility (MOF) 133
For example, consider our simple table-column data metamodel that contains an OCL invariant forbidding the name of a column to be the same as the name of its owning table (see Figures 5.6 and 5.7). The DTD for representing tables and columns does not contain this invariant; it merely defines the format for representing a table and column. An intelligent MOF tool reads the metamodel to ascertain the fact that this invariant exists. An important consequence is that the DTD cannot be reverse engineered to yield the original metamodel in all its detail.
The other MOF mappings we have mentioned can also be applied to "the" MOF model. Soon XMI for XML Schema will be applied to "the" MOF Model to produce "the" MOF XMI Schema. The OMG has also run "the" MOF Model through the MOF-CORBA mapping. The result is IDL for CORBA objects that represent M2 elements, that is, that represent the elements of metamodels. The OMG has standardized this IDL, which I refer to as "the" MOF Model IDL. The JMI specification applies its MOF-Java mapping to "the" MOF Model, and the resulting APIs are for Java objects that represent M2 elements. JMI standardizes these Java APIs and I call them "the" MOF Model Java APIs.
Previous << 1 .. 48 49 50 51 52 53 < 54 > 55 56 57 58 59 60 .. 123 >> Next