UML, Meta Meta Models and Profiles
If someone ever wants to get brainsick and/or feel defeated, the easiest way is to try to comprehend the UML metamodeling approach which is used by OMG to describe UML.
The metamodeling approach means that “a metamodel is used to specify the model that comprises UML”. This approach supposedly “offers the advantages of being more intuitive and pragmatic for most implementors and practitioners.” Let’s take a look at some details of the approach.
UML specification is organized into two volumes “UML 2: Infrastructure” and “UML 2: Superstructure”.
The UML Infrastructure is represented by two packages: Infrastructure Library and Primitive Types. The Infrastructure Library consists of the packages Core and Profiles.
The Core package of the UML Infrastructure was designed for high reusability, where other metamodels at the same metalevel … either import or specialize its specified metaclasses. MOF, UML, and CWM each depends on the common Core. The Infrastructure Library defines the actual metaclasses that are used to instantiate the elements of UML, MOF, CWM, and indeed the elements of the Infrastructure Library itself. In this respect, the Infrastructure Library is said to be self-describing, or reflective. One obvious problem here is that UML Infrastructure is used to define MOF which in turn is used to define UML Superstructure. If Infrastructure is so reusable and generic, it should be defined separately from UML.
OMG states that it is possible for a model to be used as a metamodel, so that for example, the Infrastructure Library is in one capacity used as a meta-metamodel (M3) and in the other aspect as a metamodel (M2), and is thus reused in both the M2 and M3 metalevels.
Meta Meta Models, UML and Profiles
OMG says that:
The meta-metamodeling layer forms the foundation of the metamodeling hierarchy. The primary responsibility of this layer is to define the language for specifying a metamodel. The layer is often referred to as M3, and MOF is an example of a meta-metamodel.
Keep reading: In the four-layer metamodel hierarchy, MOF is commonly referred to as a meta-metamodel, even though strictly speaking it is a metamodel. Simple, isn’t it? Infrastructure Library is sometimes meta-metamodel and sometimes a metamodel, at the same time MOF is commonly meta-metamodel while in fact it is metamodel!
MOF is used as the meta-metamodel not only for UML, but also for other languages, such as Common Warehouse Metamodel (CWM). The UML Superstructure metamodel is specified by the UML package on the diagram above. UML is defined as a model that is based on MOF. Every model element of UML is an instance of exactly one model element in MOF. A model is an instance of a metamodel. UML is a language specification (metamodel) from which users can define their own models.
The Profiles package of the Infrastructure Library contains mechanisms that allow metaclasses from existing metamodels to be extended to adapt them for different purposes, e.g. to adapt the UML metamodel for different platforms (such as J2EE or .NET) or domains. As such, it could be considered at the same meta-metalevel as MOF - one level higher than the UML metamodel.
The Profiles package of the UML Superstructure (from Auxiliary Constructs) merges Profiles package of the Infrastructure Library. A profile is a restricted form of a metamodel that must always extend some reference metamodel that was created from MOF, such as UML or CWM.
若有收获，就点个赞吧
0 人点赞
