1、元、
"元" 英语是 Meta，meta在不同的行业领域有不同的翻译，在 IT 领域一般来说 Meta 是翻译成元，主要因为在 IT 中Meta 主要指的是一些 控制、 说明、 描述的意思。
在汉字中这个 "元" 有两个意思。 第一个意思就是 "首" 的意思， 如元旦 ，第二个意思就是描述、 说明、 控制。（个人觉得这里应该是取第一个意思“首”的这层意思，即开端、本源的意思，没有查到老师讲的第二个意思）
2、BNF
巴科斯范式(BNF: Backus-Naur Form 的缩写)
巴科斯范式是由 John Backus 和 Peter Naur 首次引入一种形式化符号来描述给定语言的语法（最早用于描述ALGOL 60 编程语言）。
巴科斯范式的内容
在双引号中的字("word")代表着这些字符本身。而double_quote用来代表双引号。
在双引号外的字（有可能有下划线）代表着语法部分。
尖括号( < > )内包含的为必选项。
方括号( [ ] )内包含的为可选项。
大括号( { } )内包含的为可重复0至无数次的项。
竖线( | )表示在其左右两边任选一项，相当于"OR"的意思。
= 是“被定义为”的意思。
现在，几乎每一位新编程语言书籍的作者都使用巴科斯范式来定义编程语言的语法规则。
UML 的元语言可以用 Backus 范式来表示，一般编程语言的这个元语言主要是用 Backus 范式，Backus Naur 范式来表示所有的高级语言，实际上 Java，C++ 它们都可以用一个 Backus 范式来表示。
3、元模型
UML元语言是用一种模型，对所有的这个建模元素和 UML 的图进行描述的一种语言,描述 UML 所有的一些建模元素 。为了体现一致性，把这个 UML元语言称之为元模型 ，元模型实际上就是描述UML的语法规则的一种语言，元模型就是模型的模型。
元模型定义了描述某一模型的规范，具体来说就是组成模型的元素和元素之间的关系。元模型是相对与模型的概念,离开了模型元模型就没有了意义。
元模型主要是用来描述这个模型的这个语法规则的。 是对模型的语法和语义进行规约的一种模型。UML 中的元模型 是对 UML 的语法规则进行描述的。
4、元模型体系
\%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E6%8A%80%E6%9C%AF%E9%AB%98%E7%BA%A7%E8%AF%BE%E7%A8%8B\%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E6%8A%80%E6%9C%AF%E9%AB%98%E7%BA%A7%E8%AF%BE%E7%A8%8B(%E7%AC%AC%E5%9B%9B%E7%AF%87)\%E5%85%83%E6%A8%A1%E5%9E%8B%E4%BD%93%E7%B3%BB.png?lastModify=1530593011)
元模型体系有三个层次。 第一层叫 M0 层，M0实际上是这个对象实例层，这个模型般来说很少在建模的时候建立，它用来表示在程序执行的过程中，在内存中的一些实例和实例之间、 对象和对象之间的关系，也可以用来表示在现实世界中一些实例和实例之间的关系。
但是一般用UML的时候是集中在M1这个层次， 叫模型层次，也就是建立的一些类，关联关系，Use case，全部都在这个范畴，这个范围内这里边每一个类实际上是 M0 层的多个类的一个抽象， 这个层次的一个类对应于 M0 层中的多个实例。 这是它们的一个规则，M1层次是可以被进一步地抽象、 规约到M2 这个层次，比如说所有的类，它们有些共性的东西， 那就是从语法角度来看，不管你是客户、 老师、 学生 订单、 事件等等，全部都是类，既然都是类的话，那么它们共性是什么？结构是什么？这个要用 M2 基于元模型来进行描述。
M2层次即元模型层次，那所谓的类必须得有一个类名，然后还得有一些属性的集合，它得有一些操作的集合，有些还得有一些元数据，比如说明这个类到底是抽象类、主动类还是被动类，所以在元模型中可以表示类，那当然也可以表示Use case，表示Use case的组成结构，甚至是可以主动的扩展一些新的一些图。
二、软件方法的未来发展
未来的软件方法学，跟3D打印机很像， 一端输入是软件的模型，另一端输出的是可执行的代码， 100% 的可执行代码，直接在环境中就可以运行的一些程序。目前所有的这些技术都已经进入了一些实质性的阶段， 这就是模型驱动的软件开发方法学的一个思想， 它实际上是以模型为中心，通过模型转换逐渐的驱动，从需求模型到分析模型到设计模型，最后由设计模型自动化地产生 100% 的源代码。
面向对象的分析设计之间，没有方法学层面上的鸿沟， 但是分析到设计的转换就需要很多的人工的一些劳动，分析模型和设计模型它们尽管都是用面向对象方法学进行构建，但是所使用的原则，针对的一些范围也是不同的。 往往会出现分析模型和设计模型的结构完全不同，模型的结构是异构的，这需要人从中做很多工作。 如果没有一个自动化的模型转换或者说是一个代码生成的工具的话，往往会出现这样一种情况，人搞了一个分析模型，建模公司建了一个分析模型， 之后又得重新人工的， 不是直接从分析模型转换到设计模型， 而是人又得手动地从头建一遍设计模型，之后没有自动的代码生成工具，然后这个设计模型又得手动地编程序实现。
那么这使得在前几年出现的一种相当于一种敏捷软件开发的思潮，就是对传统的面向对象这种分析设计的一种挑战，认为分析模型、 设计模型本身是不可转换的，又是不可执行的，然后建立了这个设计模型之后，还得重新要开发程序。 很多的一些软件开发实际上没有时间等这么长的时间，所以就不如完全推翻掉模型，直接从分析 从需求获取就开始编写程序，这样的话通过高素质的程序员，然后还有一些与用户的密切的沟通，然后实现分析和设计。 所有的分析和设计全部都在代码原型中完成，这是一种思潮。
从长远发展来看，软件生产自动化代替手工作坊似的编程方式也是一个迟早的趋势。 在其他传统领域比如说一些比较前沿的，电子领域，硬件领域，微电子领域，实际上都已经实现了这种大规模的生产。 而软件目前还没有，但是这个趋势必然会存在的，并且一直会发展下去。 在计算机领域，大概是在上个世纪 60 年代，从汇编语言时期 过渡到高级语言时期，经历一个很大的一个跳跃，实际上当时也有很多阻力，但是无法阻挡这个程序从这个低级的汇编语言向这个更贴近于人的一种高级语言的一种蜕变。这个变革会提高大量的软件生产力， 而现在模型驱动恰恰是又要往上走了一步。
模型驱动
模型驱动架构，即MDA。
模型相对于对象来说，它的抽象粒度更大，因为模型不仅是对象， 而且还可以指代除了对象之外的其它的一些实体，比如说是一些模式，其它的一些领域的一些构造物，这些都可以用模型表示。 而对象用它描述是可以的，但是不够精确，无法进行转换， 代码生产，所以这个模型的抽象机制要比对象更加大，所以对处理更加复杂的软件系统来说，是非常有必要的。
模型驱动这个思路理念产生于世纪之交，也就是 2000年的时候，当时出现的问题就是中间件比较繁盛，有些人将它称之为第二次软件危机。 由于中间件发展比较繁盛，产生了各种平台下的这个中间件， 使得应用开发人员在利用中间件进行开发的时候要涉及到同时支持不同平台的中间件，或者说要做一个技术转换。 当基于一种中间件开发的应用，转换到另外一种中间件进行应用开发，这中间需要与转换这个中间件，应用程序和中间件之间的这个接口，所有的编程工作都由人为来完成，并且这个 编程工作繁琐、 琐碎、 容易出错， 枯燥无味。 所以人们试图在开发应用程序和中间件衔接代码的时候，进行一种自动化的尝试，由此诞生了按模型驱动这种方式，后来人们发现模型驱动这种方式并不局限于中间键领域或者说应用程序中间件之间衔接代码，其实它在所有代码中都可以实现。
模型驱动产生原因：
-
软件系统越来越复杂
-
异构性问题亟待解决
-
语言与范型
-
数据处理与访问协议
-
操作系统与中间件平台
-
软件开发技术
-
UML已发展成熟，并成为事实上的标准
UML从一种面向对象的编程语言变成了一种模型驱动编程语言，为并且提供了一些非常成熟的工具，用来支持模型驱动开发。现在来看，模型驱动从2000年开始发展到现在经过十来年的发展，基本上从标准工具上已经成熟。
模型驱动的这个思想就是三个技术：一个是元建模技术，另外一个是模型转换技术 最后是代码生成技术。元建模技术是模型驱动方法的基础，模型转换是模型驱动方法 的关键，而代码生成是模型转换的最终的目的和终极目标。MDA是目前MDE的主要方法，将业务模型和不同的平台分离、从代码为中心到模型为中心。
MDA存在的问题：
建模语言的表达能力不足（缺乏用户界面、数据库、IO建模元素等）、掌握水平（元建模能力、UML/MOF体系）、UML底层结构的新需求、模型存储与交换的问题、PIM非完全平台独立、PIM到PSM转换困难、代码生成困难、转换的代码效率不高（越来越不是问题）、调试困难。但MDA仍然是一个非常有潜力的技术，有待在多领域验证。
结论：
-
MDA是新型的软件开发技术，目前理论方法不尽成熟完善，缺少成功的应用案例。
-
MDA是非常有潜力的新型技术，代表着软件开发技术的新方向，将来有可能成为主流的软件开发方法