元模型是模型驱动软件开发最重要的方面之一。处理下面的MDSD挑战需要元建模的知识。
- 构建特定域的建模语言（DSL）：元模型描述这种语言的抽象语法；
- 模型验证：模型在元模型中定义的约束下是有效的；
- 模型到模型的变换：这种变换被定义的两个元模型之间的映射原则；
- 代码生成：生成模版参考额DSL元模型；
- 工具集成：基于元模型，可以使建模工具适应各自的域；
一、元模型的定义
元模型是陈述建模的模型。更精确地说，一个元模型描述模型的可能结构--它用抽象的方式定义了一种建模语言的构件及它们之间的关系，还有约束和建模规则--不过并不是语言的具体语法。我们说一个元模型定义了一种建模语言的抽象语法和静态语法。反之亦然，每种正式语言都有一个元模型，如Java或UML；
元模型和模型之间有一种类-实例的关系：每个模型都是元模型的一个实例，因此定一个一个元模型需要一种元建模语言，而且该语言是用一个元元模型描述的。理论上，这种抽象概念的“层叠”可以被无限延伸，不过在实践中采取的是其他措施。
在MDSD的背景下，域的DSL是由一种元模型定义的。
现实、模型和元模型之间的关系
在原则上，可以用任意一种建模语言描述模型。语言的选择 应该基于语言对要描述的域的适宜性。在现实生活中，这一决定经常由问题是否有实用的工具可以供建模语言适用来决定的，这意味着现在UML可用于许多场合中的建模。因此，观察UML背景下的建模就具有极大的相关性。
元关系通常是相对于模型的。
OMG的四元层
UML元模型中的构建Class现在是元元元素MOF Classifier的一个实例。MOF类在M3层被定义。元对象工具MOF是OMG的元元模型。MOF是用来在M2层定义建模语言，例如UML。支持它的思想是UML将不会是唯一的建模语言，将基于MOF定义另外的特定域的和可能已经被标准化的建模语言。MOF也能够定义非面向对象的建模语言。
在OMG模型中，MOF之上没有元层--基本上，MOF自己定义自己。
MOF中截取的一部分
正如MOF的名字所表明的，这是一种基于面向对象范例的元元语言。为此，MOF借用了UML的类的内核，使用了相同的概念和具体语法。
二、比较元层和抽象层
模型之间可以有不同的关系。元关系，说明了元模型定义的创建模型所用的概念。
在另一方面，即使位于相同的元层上，模型还是可以位于不用的抽象层。典型地，变换被用来将较高模型层中的模型映射到较低抽象层中的模型，每个模型都是元模型的一个实例。因此这两个模型是不同的，不过可以在相同的元层上找到模型和元模型。
三、MOF和UML
UML是MOF的一个实例---一种应用。必须考虑各种细节。
首先，UML的存在先于MOF。UML最初是被正式定义的--即它知识纯粹被口头定义的。随后定义的MOF指定UML是正式基于MOF的。后来版本的UML定义客服了这种先后次序导致的问题，所以现在UML可以被真正的成为一种MOF语言。
MOF模型的表示法是UML的具体语法，这偶尔会导致混淆。正式地，可以由模型元素的命名空间/包的规范解决该问题，不过仍然存在混淆的可能。
MOF包含许多在UML中也出现的模型元素。例如，这两种语言都拥有一个名为Class的元素。即使元素有相同的名字并且经常粗略地描述相同的特征，它们却不是完全相同的---只要它们位于不同的元层。
元和抽象
四、扩展UML
在软件开发中，通常不会从基于MOF定义一个全新的M2语言开始，而是会始于UML元模型并在需要的时候对它进行扩展。
- 基于UML的正式模型扩展
- 用类别模版/配置文件（UML1.x）扩展
- 用类别模版/配置文件（UML1.2）扩展
1.基于元模型扩展
这种类型的扩展是扩展UML的元模型。为此，就像在建模中常常做的那样，应用高一层的元层语言，在这种情况下就是MOF。只有当工具拥有一个表述明确、公开的基于MOF元模型时，才能用这种工具实现这种扩展。
M2层内的继承
2.用UML1.x类别模版扩展
用类别模版扩展是UML特有的一种功能，它被定义为配置文件机制的一部分。
3.用UML2.0的配置文件扩展
使用UML2.0的定义扩展类别模版机制并将其放置在一个更加容易理解的配置文件机制背景中。这里扩展的概念很关键。扩展是一种新符号和一种新的UML语言构件。它被表示为一个填充的继承箭头。
UML2.0呵呵UML1.x之间的另一个不同是，一个模型元素现在可以同时有多个类别模版。于是它拥有所有类别模版的属性作为标记值。
五、UML配置文件
配置文件支持对UML进行调整和扩展，使它适应专业的或技术的领域。可能还有人说UML不是一种语言而是一个语言族，在这种情况下，UML配置文件就是卒中的元素--具体语言。目标是UML工具和生成器可以像插件一样处理配置文件。为此，OMG为UML定义了一种配置文件机制。
UML现在为用UML表示配置文件和用应用程序模型来注释它的用途提供了语言的选项。
一个配置文件并不是独立的。相反它总是依赖并使用一个参考元模型。这可以是UML元模型，也可以是一个现有的配置文件。
六、元建模和OCL
OC L是对象约束语言的缩写。这是一种没有负面影响的便于陈述的语言，它用于定义约束，如基于MOF建模语言的建模规则。约束用有关模型实例有效性的其他信息丰富了模型。约束适用于M1和M2层的应用程序。
七、元建模：例1
出于说明的目的，现在来建立于UML无关的自己的元模型，即不扩展UML元模型的元模型。例如，使用生成编程和FODA方法中的特征模型。
八、元建模：例2
元模型的另一个例子是可用于小型设备和嵌入式系统的极度简化的组件基础设施。基于该基础设施的应用程序的中心成分是---很明显--组件。在定义体系结构的过程中，定义一个组件的内容是合理的，这也就是一开始就要为这种基础设施的组件定义一个元模型的原因。
此外，一个组件有许多配置参数。为简化问题，这些参数必须是String类型的组件类的属性，因为它们是在系统启动时从一个配置文件中读取的。
九、工具支持的模型验证
支持元建模的工具各种各样。区分下面可供选择的办法是有可能的：
- 不支持
- 单独的工具
- 集成的建模工具
最常用的是将一个UML工具和一个单独的生成器/验证工具结合在一起。遗憾的是，集成的元建模工具仍然普遍被市场忽视。
生成器将所有的模型作为自己的输入数据。分析器对这些进行分析，随后元模型实例化器用配置好的元模型实例化得到的分析树。因为生成器中可以使用不同的分析器，所以输入的格式是可以互换的。
十、元建模和行为
元建模背景下的行为在两方面是有趣的。一方面，行为可以被隐藏在元模型的意义内，另一方面，可以用元建模使得行为建模可以被明确访问，例如，以活动图或状态图的形式。
十一、一个更加复杂的例子
关于ALMA望远镜的。采用UML定义数据结构并由它生成各种其他工件：
- XM L模式
- XML的包装类和用各种语言（C++、Java、Pyhon）实现的（解）编制器；
- 专有数据格式的转换器
- 数据模型的Html文档
1.基础
首先，必须区分实体和依赖对象。实体有自己的ID而且可以基于若干属性被搜索到。一个实体可以再分为几个部分，即依赖对象。这些依赖对象没有自己的身份特征而且不能被搜索到--只有持有它们的实体知道它们而且可以检索到它们。部分可以包含更多的部分。
2.值类型
在数据模型中存在数据间的其他区别。特定额信息，如一个星星在天空中的位置，既不是依赖对象也不是它们的基本类型。为此，引入值类型。值类型本身没有身份特征：它们的只由自己的数值组成。具有相同值的两个值类型实例被认为是完全相同的。通常，定义实体或者依赖对象的属性只能是基本类型或值类型，因为这些值在系统中会重复出现。
3.物理量
因为ALMA是一种物理测量工具，所以它处理的数据涉及很多的物理量，因此像在元模型中一样清楚地提供物理量是有意义的。物理量有一个值和一个单位。各种物理量有某种定义好的单位和取值范围。
十二、元建模中的缺陷
本节给出了一些提示和技巧并揭露了特别是与UML有关的元建模中的一些缺陷：
- 在元建模中经常会出现这个问题，即必须使用什么符号不再显而易见；
- 偶然发现自己在错误的元层纱个。
一般来说，提出如何用一种编程语言实现元模型这个重要的问题被证明是有帮助的。反之，可以提示什么符号是正确的。
1.接口
问题：希望表示某个事实，即一个元类实体的实力必须实现某个接口。
正确的解决方案：一个实体的一组实现的接口必须包含接口累。这既可以用一条OCL约束表示，也可以通过构造个字的元关联的子集表示。
2.依赖性
问题：表达组件可以依赖于接口的事实，因为它们要调用接口的操作。
正确的解决方案：定义组件和接口之间的一种关联并称之为使用。
一个组件可以使用许多接口而且一个接口可以被许多组件使用。
3.ID
问题：实体必须有且只有一个名为ID的String属性，这代表识别属性或基本键。
正确的解决方案：使用了一条OCL约束，它规定在实体的属性中必须有一个名为ID的String型属性。
4.基本键
问题：实体的所有实例在它们的属性中必须有且只有一个属性的类型为Entity PK。这里，Entity PK是一种特殊话的元类Attribute。
正确的解决方案：
正确的元模型
5.元层和Instanceof
本节以UML为例说明在使用复杂建模语言时的一个缺陷。
给出了一个UML类图和一个UML对象图。对象是在类图中定义类的实例。到目前为止，对象-类之间的关系很明显是一种instanceof关系，这近一步证明了可以存在同一个类多个对象。链接和关联之间也是这种关系。
通过观察，很容易就可以解决这个明显的矛盾：这两个instanceof并不是相同的语言构件。