（四）元模型建模理论

元数据架构区别于早期的元建模架构，具有以下功能：

模型具备面向对象的特性，其元建模结构与 UML 的对象建模结构呈现出高度的一致性。基于此特性，在相关示例中会采用 UML 包图标对元模型以及 UML 模型予以表示。值得一提的是，模型能够对任何可以想象得到的模型以及建模范式予以有力支持。

在 元数据架构里，元级别并非是固定不变的。通常情况下会存在 4 个元级别，然而，依据具体部署方式，其元级别数量可能会更多或者更少。实际上，实现级别上并不强制要求存在离散的元级别。元级别仅仅是用于理解不同类型数据与元数据之间相互关系的一种约定俗成的方式。

从广义上来说，模型作为元数据的集合体，其并不一定被限定于单一的元层次之中。例如，在数据仓库的应用场景下，将元架构 “Relational Table” 以及作为关系表实例的特定架构整合起来视作一个概念模型，这在实践中可能会产生极为有益的效果。

模型还具有自描述的显著特征。换而言之，模型是借助其自身的元建模结构来进行正式定义的。也正因如此，模型同样会采用 UML 样式的 Package 图标来加以呈现。

模型的自描述性质具有以下特性：

n  它表明模型对于实际元建模具有足够的表达能力。

n  它允许通过将映射应用于模型来定义的接口和行为。这为表示模型和元模型的计算对象之间提供了语义的统一性。这也意味着，当定义新的技术映射时，用于在该上下文中管理元模型的 API 也会被隐式定义。

n  它为模型的扩展和修改提供了体系结构基础。因此，连续的 RTF 能够在模型中进行增量更改，以解决变得明显的问题。将来，可能会添加新的元元模型以支持建模符号规范和模型到模型转换等任务。

n  给定一组适当的实现生成器，它允许通过引导创建新的元模型存储库实现。

基于模型的分层架构设计，有助于满足单一职责原则，系统中的每个模块仅有一个需要改变的原因。每一层都关注自己特定的职责或者功能。从而使代码更容易理解和维护。通过分层设计还可以在不修改现有代码的基础上进行扩展。例如数据访问层和业务逻辑层之间的解耦分层，是数据访问方式的变化不会影响业务逻辑。同时也提高了功能模块的复用性。

核心在于提供了一种可扩展的元数据的管理方式。它定义了一种支持各种元数据的架构，允许按需添加新的类型的元数据。这种实现方式主要通过对元数据进行分层来实现。分层元数据结构是一种典型的四层建模结构，这些层次分别为 M0、M1、M2、M3。

这些层通常描述如下：

l  M3：定义元模型的规则，包含了建模语言所需的元素

l  M2：定义元数据的元模型，定义了一种建模语言的结构和语法

l  M1：定义数据的元数据，模型层定义了一个具体的系统的模型。

l  M0：数据，运行时包含了一个模型的对象在运行时的状态。

四层元模型架构提供了一组建模元素以及使用这些元素的规则，为精确定义一个复杂模型语义提供了基础。

这里需要注意的是，各层级别不要混淆。四层级别是累积递进的。即 M1 级物理数据模型一致性是建立在 M2 级逻辑数据模型一致性之上。如果达不到 M2 级和 M3 级，就无法达到 M1 级。

与简单的建模方法相比，经典四层元数据架构具有许多优势。

如果框架设计得当：

• 它可以支持任何可以想象的模型和建模范式

• 它可以允许关联不同类型的元数据

• 它可以允许逐步添加元模型和新类型的元数据

• 它可以支持使用相同元元模型的各方之间任意元数据 （model） 和元元数据 （metametamodel） 的交换。

核心元模型结构用于定义元模型。元模型主要是为元数据定义信息模型。对象建模架构，实质上是 UML 核心的子集。简而言之，五个主要的建模概念：

1.      Class 类 – 对元对象进行 建模

2.      Associations 关联 – 用于对元年对象之间的二进制关系进行建模

3.      DataTypes 数据类型 – 对其他数据（例如原始类型、外部类型）进行建模

4.      Packages 包 – 将模型模块化·

5.      Constraints 约束 – 将一致性规则添加到对应的元模型以保证其语义唯一

模型分类器

数据类型

约束(Constraints)

继承 / 泛化操作不适用于数据类型（DataTypes）。在面向对象编程以及相关建模体系中，继承和泛化通常是用于类（Class）等元素来构建层次化的关系，子类可以从父类那里继承属性、方法等内容以实现代码复用和扩展功能等目的。但对于数据类型来说，它们有着自身独立定义和使用方式，不遵循继承这种通过从其他类型派生以获取特征的机制，例如像基本数据类型（如整数类型、字符串类型等），不会基于继承关系去拓展自身的性质，而是有着固定的表示和功能范围，这条约束明确了数据类型在整个体系里与继承机制的隔离，确保其使用符合相应规范。

数据类型不能是抽象的。抽象的概念在面向对象里常用于类，抽象类往往包含抽象方法等，本身不能直接实例化，需要子类去实现其抽象部分后才能实例化并使用。而数据类型主要是用于表示具体的数据表现形式和取值范围等，是可以直接被用来定义变量、存储数据等实实在在的用途，不存在像抽象类那样等待进一步实现抽象部分的情况，所以规定数据类型不允许为抽象的，以此来保证数据类型在实际运用中符合其作为具体数据表示形式的定位和功能要求。

这里的约束在不同的模型层，代表的意义不同。如果在元模型层，代表元模型之间的约束关系。如果在元模型实例层，则代表业务逻辑关系等。这个理解起来虽然有点绕，但他是理解元模型驱动架构的关键。

 将前面的内容统一描述如下

上图就是所有元模型之间的包含关系。其实还缺少关系元模型（除了包含，还需要连线，参照，继承等等）

这样就全了，有了前面这些理论支持，我们就可以构建我们自己的元模型集合了。