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

Figure 5.27 portrays the fact that, because "the" MOF Model is itself MOF-compliant, the MOF technology mappings can be applied to it just as they can be applied to any MOF-compliant metamodel.
M2 elements
^7 Mapping Mapping (JMI) Mapping (XMI)
MOF-Compliant CORBA APIs
MOF-Compliant Java APIs
DTD or Schema
For M1 elements
"The" MOF Model (MOF-Compliant)
MOF-CORBA ^ Mapping
M3 elements
MOF-Java Mapping (JMI)
MOF-XML Mapping (XMI)
MOF-Compliant CORBA APIs
MOF-Compliant Java APIs
DTD or Schema
For M2 elements
Figure 5.27 Applying standard MOF mappings to “the" MOF model.
134 Chapter 5
The ability to represent M2 metamodels in a manner that is consistent with the representation of Ml models helps to streamline MOF metadata management. Generators and generic MOF code need to be able to read metamodels dynamically, so the representation of metamodels is a significant issue. Figure 5.28 illustrates that a MOF metadata tool manages M2 metamodels and "the" MOF Model (M3) similarly to the way it manages Ml models. This is a case where it is useful to ignore the difference between metalevels and view the absolute metalevels as arbitrary.
If you feel squeamish about the details of self-description, don't be concerned. It takes a little getting used to. You may have to read this section over a few times. The most important thing to grasp is that, just as it is important to be able to represent models as XML documents, CORBA objects, Java objects, and so on, it is also important to be able to represent metamodels as XML documents, CORBA objects, Java objects, and so on. MOF's self-describing nature makes it possible to use the same mechanisms to generate metamodel representations that are used to generate model representations.
O = MOF CORBA Interfaces О = MOF Java Interfaces (JMI)
Figure 5.28 A MOF repository manages M2 and M3 similarly to Ml.
The Meta Object Facility (MOF) 135
Additional Applications
This section takes a look at some of the newer MOF-based technologies coming on line.
Human Usable Textual Notations
Consider a UML model created with a UML tool. You can't see all the properties of the model by looking at the model diagrams. Some of the properties aren't visible unless you drill down into property dialogs. Furthermore, on any given model diagram the modeler is likely to have suppressed some of the detail for the particular viewpoint that diagram is intended to present. A person who wants to ascertain all of the model's properties has to assemble the bits and pieces from an assortment of diagrams and dialogs.
Thus, it is often convenient to render all the properties of a model linearly into human-usable text. This provides a sure way to examine all the detailed properties of the model. A human-usable textual notation (HUTN) for a UML model might look something like Figure 5.29. This example is not the best that one could do in designing a HUTN for UML, but it should convey the general idea. Of course a UML model can be rendered textually via XMI, but XML is not really friendly to humans, especially for complex models.
Class ApartmentBuilding extends Building {
attribute address String;
Class Apartment {
Association Building_Apartment {
Association End aptBuilding type ApartmentBuilding [aggregation_composite] 1..1
Association End apt type Apartment
[isOrdered,isNavigable] 1.. *
Figure 5.29 Human-usable textual notation.
136 Chapter 5
It can also be convenient in some cases for a human being to write a model textually via a HUTN rather than create it graphically. To some extent, this is a matter of personal taste. Some people feel more comfortable defining models linearly in text, and some feel better anchored with a GUI approach. For the majority there are good uses for both, and it is ideal to be able to switch back and forth easily between the two ways of modeling.
The OMG issued an RFP for a HUTN for UML. Work on it was delayed for a while, but when work resumed, consciousness in the OMG about the principles of the MOF had risen considerably.
Thus, as we go to press, the OMG is finalizing a MOF-based approach to the HUTN problem.16 Instead of designing a HUTN just for UML, the MOF-based approach defines a parameterized MOF-HUTN mapping so that, given a metamodel and some mapping parameters, a generator can produce a HUTN suitable for modeling in accordance with that metamodel. The UML HUTN will mostly likely be generated from the UML metamodel via the parameterized mapping, rather than being handcrafted. Textual notations for varied metamodels will therefore have consistency. MOF tools will be able to generate code for exporting models from repositories in HUTN form and for importing models expressed in HUTN form.
A vendor demonstrated a prototype of a MOF-based HUTN engine at an OMG meeting. For any given metamodel, it automates the production of XSL stylesheets that convert back and forth between the HUTN and XMI formats for that metamodel, and the HUTN and XMI formats are determined by the MOF-HUTN and MOF-XML mappings, respectively.
Previous << 1 .. 49 50 51 52 53 54 < 55 > 56 57 58 59 60 61 .. 123 >> Next