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 .. 60 61 62 63 64 65 < 66 > 67 68 69 70 71 72 .. 123 >> Next

■ Information-formatting technologies such as XML DTD and XML Schema
■ 3GLs and 4GLs such as Java, C++, C#, and Visual Basic
■ Distributed component middleware, such as J2EE, CORBA, and .NET
■ Messaging middleware such as WebSphere MQ Integrator and MSMQ
The sample profile defined in Chapter 6 is also platform-independent in the same sense. This particular level of abstraction is a recurring theme because, as mentioned earlier, it is one level above today's typical development environments and thus is important for raising the development abstraction level.
For this reason, the MDA mappings that have been standardized so far are oriented to supporting generators that process models that are platform-independent models in this sense. Thus, this chapter's discussion of the mappings' basic principles assumes this abstraction level. You can apply some of the principles to models that are at lower levels of abstraction, but that is not the focus of these guidelines.
In this chapter, when I refer to a platform-independent model (PIM), I actually mean a PIM that is a class model.
What the Standard MDA Mappings Produce
Let's review what generators based on the standard MDA mappings produce.
The outputs standardized by MDA mappings are APIs and information formats expressed in the languages of the target technologies, including Java, XML, and CORBA IDL. The standards don't specify the exact code that implements the generated APIs and formats. As we've seen, however, they specify the semantics of the APIs and formats produced sufficiently to support interoperability between implementations of the APIs and formats.
Building Compilable Class Models 165
For example, the JCP's Java Metadata Interface (JMI) specification defines how to generate Java APIs from a class model and specifies the semantics of those interfaces, but does not specify the exact code that implements the interfaces. For interoperability purposes, standardizing the syntax and semantics of APIs is sufficient. Specifying the derivation of implementation code would tie implementers' hands too much.
The OMG's XML Metadata Interchange (XMI) standard specifies how to derive an XML-based information format—that is, an XML DTD or Schema— from a MOF class model and how to produce XML documents that conform to the DTD or Schema. It does not specify the exact code that actually produces and manages the XML documents, although it specifies the semantics of such code so that different code bases conforming to the specification can interoperate.
UML versus MOF
Although MOF is close to being a subset of UML, this chapter points out a number of cases where MOF and UML are slightly out of phase with each other. This complicates matters when trying to leverage MOF technology for constructing M1 models and processing them with generators. It forces us to have to explain the differences and modelers to have to understand them.
UML 2.0 should address these differences. As mentioned in Chapter 3, the UML 2.0 Infrastructure RFP specifically mandates that UML 2.0 correct the misalignment between MOF and UML.
There are cases where it's useful to employ a generator that implements the MOF technology mappings to transform an M1 model, since there are generators available that can perform these transformations. In such cases the M1 model must adhere to the restrictions imposed on MOF metamodelers (Chapter 6 covered these restrictions). Furthermore, there are some special issues that arise with M1 class models that are covered later in this chapter.
Purposes of the Guidelines
As I mentioned, independently of whether your PIM is a UML model or a MOF metamodel, MDA mappings will follow some basic principles. Our guidelines flow from these principles and have three general goals:
■ Ensure that the generator does not reject the model.
■ Ensure that APIs and information formats that the generator produces are of the highest possible quality.
■ For generators that produce implementations of the generated APIs and information formats, ensure that the implementations are optimal.
166 Chapter 7
description : String URL : String

ACIDTx 1 0..* Business TXUnit 1.. * 0.. * BusinessTx
" +executor +executor
Figure 7.1 Sample metamodel.
Some of this section's examples use the sample metamodel whose abstract syntax is shown in Figure 7.1. Appendix A contains informal definitions of the classes of metadata that the metamodel defines.
Don't Define Accessor and Mutator Operations for Attributes
When you define an attribute of a class, don't also define routine accessor and mutator (that is, get and set) operations for the attribute in your class definition. MDA mappings that generate APIs from a class definition expand attributes into accessor and mutator operations automatically. The generated APIs also include an operation for every operation declared in the class. Therefore, if you define accessor and mutator operations in the class, they will produce redundant operations in the generated APIs.
Previous << 1 .. 60 61 62 63 64 65 < 66 > 67 68 69 70 71 72 .. 123 >> Next