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 .. 93 94 95 96 97 98 < 99 > 100 101 102 103 104 105 .. 123 >> Next

Figures 9.7 and 9.8 show how the record structure and XML metamodels also leverage the common supertypes Classifier and Feature. This means that records and XML DTDs can also be sources and targets for a CWM transformation map.
256 Chapter 9
Figure 9.5 CWM relational DB metamodel—use of common superclasses.
Adapted, with permission, from [CWM]
Thus, by defining the primary elements of data metamodels as classifiers and features, and by defining transformations as classifier and feature maps, CWM can support a wide variety of mappings.
Team-Fly®
Modeling Transformations with CWM 257
= CWM Common M2 Superclasses = CWM Relational Metamodel M2 Classes
0..*
Figure 9.6 CWM multidimensional DB metamodel—use of common superclasses.
Adapted, with permission, from [CWM]
Mapping Expressions
CWM transformation maps would lack sufficient fidelity were it not for the ProcedureExpression that each contains (refer to Figure 9.4 again). These expressions bridge the fidelity gap. CWM does not mandate the language of the expression. Thus, we should look upon CWM transformations as an extensibility framework. Users extend the framework by defining procedural expression languages or reusing ones already defined.
258 Chapter 9
Figure 9.7 CWM record structure metamodel—use of common superclasses.
Adapted, with permission, from [CWM]
To understand the importance of these expressions, consider Figure 9.9, which is the abstract syntax tree for a transformation map named B2BSalesRDBxXML. A company uses this map for exchanging purchase order data with a collaboration partner as part of a B2B sales process. The map defines how to convert relational data in the company's database into an agreed-upon XML format.
Modeling Transformations with CWM 259
= CWM Common M2 Superclasses = CWM XML Metamodel M2 Classes
0..*
Figure 9.8 CWM XML metamodel—use of common superclasses.
Adapted, with permission, from [CWM]
The figure shows how one of the classifier maps that B2BSalesRDBxXML owns, named PurchaseOrderMap, maps a relational table POItem to an XML DTD element POLineItem. The figure expands the Purchase OrderMap to show how one of the feature maps it owns, named extended PriceMap, maps the pricePerUnit and quantity columns in POItem to the extendedPrice attribute in the XML DTD. Simply associating the two source columns with the target XML attribute, however, is not sufficient to define the transformation. Adding the expression extendedPrice = pricePerUnit * quantity to the feature map makes it computationally complete.
260 Chapter 9
Figure 9.9 Abstract syntax tree for a transformation map.
UML Models as Sources and Targets
At first glance, it might appear that the CWM's Classifier and Feature are in fact the classes from the UML metamodel that bear the same names. If that were the case, then any UML Classifier (such as a Class or DataType) could be the source or target of a ClassifierMap, and any UML Feature, such as an Attribute, could be the source or target of a FeatureMap.
This, however, is not the case. CWM's Classifier and Feature and UML 1.X's Classifier and Feature are not the same. Thus, UML classifiers and features are not CWM classifiers and features and cannot be sources or targets of classifier and feature maps. The CWM architects started out simply reusing Classifier, Feature, and other elements of the UML metamodel, so that the common CWM superclasses actually were UML's Classifier, Feature, and so on. Doing so created problems for imple-menters, though. For example, if the CWM multidimensional database metamodel's Dimension element descends from UML's Classifier, then it inherits properties that support subclassing, so that one dimension can subclass another. However, dimensions can't be subclassed, so these properties are excess baggage.
Modeling Transformations with CWM 261
Thus, CWM defines its own Classifier and Feature elements and a number of other elements that are reminiscent of UML counterparts with the same name. The result is a CWM core model of common superclasses that resembles the core of the UML metamodel, but is actually subtly different.
One of the goals of UML 2.0 is to redefine its core so that it separates the concerns of classification and inheritance and a number of other concerns as well. This will make it easier for metamodels to reuse what they need from the UML core without dragging in unneeded baggage. As I've pointed out, one of the weaknesses of the UML 1.X metamodel is that it does not adequately separate concerns.
The plan is for CWM 2.0 and UML 2.0 to share this common core, as illustrated by Figure 9.10. When this alignment of CWM and UML is complete, CWM's relational Table, XML ElementType, and so on will descend from the common Classifier element, and the classifiers that are the sources and targets of a classifier map will all descend from this same element. Then, there will be no problem using a UML classifier, such as a class definition, as the source or target of a classifier map. Similarly, CWM's relational Column, XML Attribute, and so on will descend from a commonly defined Feature element, so there will be no problem using a UML feature, such as an attribute, as the source or target of a feature map.
Previous << 1 .. 93 94 95 96 97 98 < 99 > 100 101 102 103 104 105 .. 123 >> Next