This chapter is from the book
This chapter is from the book
This chapter is from the book
Sample Metamodels
Metamodels can be purchased, downloaded, copied, or custom developed. Sometimes, metamodels are an inherent part of a metadata solution, and implementers simply adopt them. It is always valuable to look at what is out there as a means of justifying your specific metadata approach or to help you decide whether to buy or build (more on that topic in Chapter 20).
Metamodel Types
Perspectives are represented via distinct metamodels. The types of perspective include the following:
Tool-specific—The metamodel reflects the way a tool uses its own metadata. In many cases, this metamodel is a logical or physical data model of the tool's underlying database.
Methodology-specific—The metamodel's representation is based on a particular modeling methodology, most typically object-oriented versus entity-relationship modeling. Current efforts are trying to adopt the Unified Modeling Language (UML) as a standard means of structure (content) as well as syntax. Models that appear later in this chapter are illustrated with UML.
Function-supporting—Metamodel constructs represent those used to support a particular task, set of tasks, or function. For example, there are configuration management metamodels, application testing metamodels, and data management metamodels.
Generic—Usually used for integration, these metamodels represent the components that are common to all renditions of the metadata-described information. Generic metamodels are intended to be compatible with this information irrespective of where it exists.
The sample metamodel in Figure 11-6 depicts the entities and relationships aspect of the Object Management Group's Open Information Model, part of their efforts to set standards.7 This model, diagrammed in UML, reflects the metadata relationships to be used by all compliant tools, thus guaranteeing metadata interaction and shareability. Compare this model to your data modeling thinking. If connections or entities seem to be missing, it is easy to assume that the standard will not address your needs. In addition, it may be too easy for vendor tools to comply with a model that is not detailed enough to address the full usage of entities and relationships. Finally, it is safe to assume that parts of compliant tools will be shareable, while the nonaddressed items will remain in the vendor's control.
){kind=link}
Figure 11-6 The OMG Open Information Model, entities and relationships
Source: Used with permission from the Object Management Group,
Needham, Mass. Copyright © OMG, 1993–2001.
The Attributes and Model Packaging submodels of the Open Information Model (Figure 11-7 and 11-8) show us more of the OMG's metamodel perspectives. Notice some differences with our requirements. In Figure 11-7, Domain, for example, although directly tied to an Attribute, can consist of parent and child domains, all of which are named and tied to a specific Classifier. This approach encourages the reusability of domains in a model, across many, if not all, attributes. However, when this model is compared with Figure 11-8, which represents Model Packaging, it is clear that Domain is intended to be reusable across models; there is a relationship between Domain and Model, irrespective of Attribute.
){kind=link}
){kind=link}
Figure 11-7 The OMG Open Information Model, attributes
Source: Used with permission from the Object Management Group,
Needham, Mass. Copyright © OMG, 1993–2001.
Figure 11-8 The OMG Open Information Model, model packaging
Source: Used with permission from the Object Management Group,
Needham, Mass. Copyright © OMG, 1993–2001.
As we evaluate existing metamodels and compare them to our requirements, we need to consider whether their way is better than our way, or whether our way is an absolute requirement. If the latter is the case, we must consider extending a purchased or noncustomized metamodel.
Extensions are any changes made to a marketplace model. They are easy to make, but not always so easy to maintain. The benefits and disadvantages should be weighed.
As we conclude Part II, you should have a firm feeling for the characteristics and power of metadata. Part III takes us into the heart of metadata solutions by describing how metadata comes together across the metamodels within an implemented metadata solution.