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

There is also a case for generators that take XMI documents as input. There are generators on the market that take UML models as input and produce various artifacts such as code and relational data models. Some of these products require a proprietary representation of a UML model, such as a Rational Rose UML model file, as input.
However, increasingly such generators expect as input an XMI document that represents a UML model. This decouples the generators from dependency on a proprietary representation of a model. You can use such generators along with any UML tool capable of exporting UML models as XMI documents. Some products accept a Rose file as input to a preprocessor that transforms the Rose file into an XMI document, which, in turn, is handed to the main generator (see Figure 5.22).
Figure 5.22 oversimplifies in an important way. Figure 5.23 provides an expanded view that highlights the fact that, in a generator that properly separates concerns, the main generation logic uses an abstract syntax tree as the source for the transformation that it performs. The formal specification of the mapping that the generator executes is independent of any particular concrete representation of the model on the source side of the transformation. Thus, the main generator is independent of XMI, with XMI-specific knowledge isolated in an XMI parser that produces an abstract syntax tree representing the model.
Proprietary Representation of a UML Model
XMI Representation of the UML Model
Main Generator
Figure 5.22 Preprocessing a proprietary representation of a UML model.
The Meta Object Facility (MOF) 127
Proprietary Representation of a UML Model Preprocessor
XMI Representation of the UML Model XMI Parser
T ^
Abstract Syntax Tree
Main Generator
Figure 5.23 More complete separation of concerns in a generator.
XMI and UML Diagram Interchange
As discussed in Chapter 3, the UML metamodel does not cover the UML graphical notation. The metamodel does not contain elements such as box, line, coordinate, and so on. Thus, the XMI DTD for UML does not specify a format for encoding the graphical information contained in UML diagrams.
Let's look at this issue again from a slightly different angle. For example, suppose you define the class Customer in a model and use it in several class diagrams, each of which provides a different view of Customer. Perhaps one diagram shows all of Customer's superclasses while another shows all of the associations in which it participates. Despite the fact that Customer appears in more than one diagram, there really is only one definition of its properties. That single definition includes the specification of all of its properties, including its superclasses and associations, and that definition is what is encoded in an XMI document representing the model.
It is important to understand that a generator that produces code and other artifacts from a UML model does not need the diagram information. In our example, the generator needs only the single definition of Customer.
128 Chapter 5
Although not required by code generators, the ability to exchange diagrams in addition to definitions is useful. If there were a metamodel for UML diagrams, then XMI would provide a means to encode UML diagrams in XMI documents as well, so that they could be exchanged among tools. As we discussed, the OMG is in the process of enhancing UML to include a diagram metamodel as part of UML 2.0. Thus, when the UML 2.0 metamodel is run through an XMI generator, the resulting XML DTD and Schema for UML will support the exchange of diagrams.
A Closer Look at JMI
In some industries, such as telecommunications, CORBA is a very popular programming model. However, in many respects J2EE has eclipsed CORBA as a programming model for distributed applications. CORBA plays a crucial role in J2EE, but primarily as plumbing not visible to the application programmer. This is yet another example of technology volatility, and it makes the MOF-CORBA mapping less interesting than we thought it would be a few years ago.
Here again MOF's platform independence is paying off. Sun's Java Community Process (JCP) recently finished its MOF-Java mapping. As I mentioned earlier, this mapping is known as the Java Metadata Interface (JMI).14 Products that implement JMI are starting to appear.
A MOF-Java Mapping
JMI defines rules for representing metadata as Java objects. The mapping specifies how to transform a metamodel's abstract syntax into Java APIs. The APIs provide a way to represent models as Java objects, for the domain of models that conform to the metamodel.
Thus, JMI is analogous to the MOF-CORBA mapping. The basic difference is that, instead of specifying the production of CORBA IDL-based APIs, it specifies production of Java APIs. The APIs are typically exposed to Java clients of a metadata repository. Like the MOF-CORBA mapping, JMI not only specifies the syntax of the generated APIs but also specifies their semantics, making it possible for different vendors' MOF generators to produce interoperable implementations of the generated APIs.
Previous << 1 .. 46 47 48 49 50 51 < 52 > 53 54 55 56 57 58 .. 123 >> Next