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 .. 53 54 55 56 57 58 < 59 > 60 61 62 63 64 65 .. 123 >> Next

As MOF mappings to new technologies, such as WSDL, are defined, apply these same principles to using such technologies to represent and manage metadata.
MOF takes an approach to metadata integration that is distinctly different from earlier attempts to build integrated metadata repositories. The key difference is that, rather than trying to unify all modeling under one modeling language, MOF assumes that there must be different languages for different system aspects and different levels of abstraction. MOF is a key underpinning of MDA in that it gives architects a high degree of freedom to define diverse modeling languages, while still making it possible to manage diverse metadata in an integrated fashion.
MOF applies MDA principles to the production of metadata management software by focusing on metamodels. A MOF metamodel consists of a definition of the abstract syntax for a language along with some informal, textual elaboration of the language's semantics. An abstract syntax definition is a class model that uses UML-like class-modeling constructs. Hence, you can use UML tools to define an abstract syntax. Class models that define abstract syntax drive MOF-based metadata management tools.
A MOF technology mapping specifies how to translate any MOF-compliant abstract syntax into some concrete form that can be used to represent models that conform to the abstract syntax. There are three standardized mappings:
MOF-CORBA. Defines how to represent models as CORBA objects.
MOF-XML (XMI). Defines how to represent models as XML documents.
MOF-Java (JMI). Defines how to represent models as Java objects.
A mapping to WSDL is also in the pipeline.
Extending and Creating Modeling Languages
This chapter begins by explaining UML's profiling mechanisms. It analyzes the trade-offs between extending UML via profiling and extending it via MOF. It also considers the advantages and disadvantages of leveraging UML when defining new modeling languages. It makes some observations on the differences between UML tools and MDA tools. Finally, it explains some of the differences between UML models and MOF models.
Extending UML via Profiles
In Chapter 2 we discussed the use of UML profiles. Here we take a closer look at UML profiles.
A Family of Languages1
UML's architects made a fundamental decision not to try to make UML all things to all people. Instead they equipped it with built-in extension mechanisms. The extension mechanisms make it possible, by means of a general-purpose UML tool, to define and use additional modeling constructs beyond those that the base UML defines.
1 This phrase is reused with permission from Cook 2000.
146 Chapter 6
A set of extensions essentially constitutes a dialect of UML, which, as explained earlier, is officially called a profile. Thus, UML is not one language but, instead, is a foundation for a family of UML-based languages. MDA makes heavy use of the extension mechanisms because of the need to support different system aspects and abstraction levels.
The extension mechanisms that UML provides are stereotypes and tagged values. A UML profile is a definition of a set of stereotypes and tagged values that extend elements of the UML metamodel.
Figure 6.1 is a class model that is an expanded version of Figure 4.1. It uses a simple UML profile that I defined for the examples. The profile is for creating platform-independent models of distributed components.
The profile defines three stereotypes that appear in the model. These stereotypes are named DCEntityContract, DCControllerContract, and Uniqueld.
UML notation denotes the assignment of a stereotype to a model element via what UML calls a keyword. Keywords are surrounded by guillemets, the French equivalent of English quotation marks. The name of the stereotype is the keyword. Thus, in our example stereotypes are denoted by <<DCEntity Contract┬╗, <<DCControllerContract>>, and <<UniqueId>>.2
Figure 6.1 Stereotypes and tagged values.
2 Although in UML notation the most common usage of keywords is to denote the stereotyping of a model element, keywords have other uses as well. For example, UML denotes an interface via the keyword interface, that is, with a class box that has the keyword <<interface>> at the top of the box. Interface is not a stereotype, but rather an element of the base UML.
Extending and Creating Modeling Languages 147
The DCEntityContract stereotype is an extension of the UML metamodel's element Class. Thus, a DCEntityContract is a class that defines the contract of a distributed entity component. A DCControllerContract defines the contract of a distributed controller component. The base UML does not support making such distinctions.
The fact that the ReceivablesAccount, Customer, and Invoice classes are DCEntityContracts is expressed by placing <<DCEntityContract>> at the top of their respective class boxes, following UML notation rules. The stereotypes <<DCEntityContract>> and <<DCControllerContract>> make significant distinctions and are important input to generators, which are unlikely to treat the two identically.
Previous << 1 .. 53 54 55 56 57 58 < 59 > 60 61 62 63 64 65 .. 123 >> Next