从上学期期末进入模型驱动开发项目小组到现在已经有四个月了，对MDA的开发思想慢慢有了了解，以前总觉得用UML建模什么的都很浮云，而且根本没什么技术含量，在嵌入式领域更是少有用武之地，但是回望一下前段时间所做的工作，发现自己原来的想法还是太幼稚，而且把UML这套技术体系看得也太简单了。虽然现在仍不能说对UML已经有了深入的了解，但是认识的层面比起以前还是有了很大的提高。
OMG定义的四层模型体系架构，从上到下依次是元元模型（M3）、元模型（M2）、模型（M1）、实例（M0）层，每一层模型都是其上层模型的实例，如MOF（Meta Object Facility）处于元元模型这一层，UML处于元模型这一层，那么UML实际上是MOF的一个实例，即UML是根据MOF而定义出来的。我们也可以根据需求用MOF来定义一套自己的元模型而舍弃UML，但是显然这需要很强的技术后盾做支持，毕竟目前有着数量庞大的商业和开源工具很好地支持UML的最新规范，其中有的工具甚至能够很好将模型生成对应的框架代码，使用起来非常方便。而定义自己的元模型则意味着需要自己来实现相应的配套工具，其难度可想而知。有人可能会问，既然每层都是上一层模型的一个实例，那么处于最顶层的MOF又是谁的实例？这个问题我到现在弄得也不是很清楚，但是根据MOF的标准可以知道，它是自定义的，但是具体怎么自定义，则需要进一步的了解。
根据上面所述，UML是处于元模型层的，而我们实际所要建立的软件的模型则是处于模型层，即对UML提供的模型元素进行实例化，形成模型层中需要的各模型元素，来表述软件中的静态模块和动态动作，当然，仅仅依靠UML提供的状态图和交互图是没法精确表述模型动作语义的，因此而引发了项目组对xUML（可执行UML）的探索。Kenndy Carter公司与OMG合作，产生了一套具体的可执行UML建模方案，在模型中加入表示动作语义的ASL代码（Action Specification Language），从而精确地表达模型中每个操作、每个信号的具体实现。就像高级语言对于汇编语言来说更容易让人理解一样，ASL对模型中行为的表述则可以看成是高级语言在模型层次上的抽象。我们可以对C语言这样的高级语言开发编译器，生成汇编语言，那么同样的道理，对ASL这种模型层次的语言，我们也可以对它进行词法、语法、语义分析，将其映射到高级语言，这就是代码生成的基本思想。
当然，具体的实现远比上面的概念要复杂，也是我们接下来要好好研究的对象。首先，模型中的静态元素（比如类、类的属性、类之间的关联）存储在XML文件中，我们要对静态元素生成高级语言（如C语言）的框架代码，如何将模型中的规则完整而准确地映射到C语言上就需要仔细考虑，确定映射规则后，再考虑如何解析XML文件并提取其中存放的信息进行映射。其次，模型中的动态元素（比如操作、类的状态转换），由于这些是用ASL这种抽象语言表达出来的，对这种语言进行词法和语法分析，生成其抽象语法树，这就相当于要开发一个ASL的编译器，充分解析出ASL代码中的语法元素后，再考虑如何将ASL中的语法元素映射到C语言上，映射的过程可以手工的，也可以选用模版（如StringTemplate）来完成。最后，就是如何对生成的C代码文件进行管理，组织各函数之间的调用关系，利用用GCC之类的编译器，对其生成可执行文件。生成的代码可用并且完全符合模型中表达出来的需求，这才是最终的目标。至于做出的工具是否要做成Eclipse的插件，是否要有友善的界面，则需要根据小组前期工作完成的好坏而定。
由于前期的验证工作已经完成并写出了相关文档，下一步将进入较为困难的实现工作，在这里梳理一下思想，以方便以后返回来重新体会，目前的理解肯定还是有很多局限性，在后面还需要慢慢的深入体会和纠正。
posted @ 2012-05-15 00:02 cchugh 阅读(21) 评论(0) 编辑
Model to Text工具Acceleo使用教程——背景知识
Acceleo是OMG的MOF Model to Text Language (MTL)标准的实现，由法国Obeo公司研发，专用于MDA过程中的代码生成，能够有效提高开发效率。接下来的几天，我将对Acceleo进行全面的介绍，希望对大家有所帮助，并欢迎交流。
一、背景知识
1、元模型
大家都知道，模型是用具有精确语法和语义的语言对系统的抽象表示。那么，什么是元模型（meta model）呢？元模型，即模型的模型，是模型的定义，定义了模型中的内容，是模型的抽象表示。知道了元模型的定义，相信大家对元元模型（即元模型的定义）的概念也都可以举一反三了吧？
可以用地图举例，地图是真实路线的精确表示，因此地图可以认为是模型。而对地图的图例（legend）定义了地图模型由哪几部分组成、以及各部分的语义，如果没有这些图例，我们就看不懂这个地图，所以图例可以认为是地图模型的元模型（当然，我们平时不需要看图例也能看懂地图，因为所有地图的图例都是一样的）。不仅如此，所有图例元模型还都基于同一个元元模型，即每种颜色代表一种特征，所以有了相同的元元模型，在不同的地图之间保持一致就方便多了。计算机科学中也用到了类似的思想设计软件，一般用MOF表示元元模型。
2、MOF
元建模领域是非常广阔的，因为对于同一个概念，可以有数不清的方法来抽象表示。例如，同样的地方的城市、路线、地貌等可以用多种多样的地图来表示。因此OMG提出了元建模技术的标准，并在今天得到了广泛认可，这就是MOF（Meta Object Facility）。MOF可以用非常有限的词汇，表示所有的元模型类型。MOF是一种元元模型。
3、XMI
XML Metadata Interchange是OMG定义的一种模型转换标准。XMI可以将模型或元模型序列化xmi格式，从名字上可以看出，XMI格式XML的扩展。XMI实现了模型转换过程中的模型互操作性。注意一点，相同的元模型可以被序列化成不同的XMI格式。
4、EMF
Eclipse Modeling Framework是为简化Eclipse环境中模型的加载、编辑及存储等操作而提出的。它并不只适用于元模型，而是可以处理所有的模型。EMF基于一种元模型的描述标准Ecore。Ecore是EMOF（(Essential MOF）的子集（EMOF同时也是MOF2的子集）。
5、UML
相信大家对UML比较熟悉了，这里就不多介绍了。UML有自己的元模型，分别定义了类、类中的属性、方法、类的关联等。UML在大多数情况下，尤其是非正式场合能表示非常多的概念，但有时我们仍然需要定义更加形式化的建模语言，来满足不同需求，例如AADL。
6、其它元模型
UML并不能表示所有的场合，当然我们可以使用UML profiles或原型的概念扩展UML，但这样很容易达到极限，即需求与UML元素的原始语义偏离甚远的时候。因此，我们需要专用的元模型来满足不同场合的需求，通常把这种元模型称为DSL（Domain Specific Language）。目前，DSL技术已经得到广泛使用，下面是建立新DSL的基本步骤：
- 定义建模概念及相关语义
- 用MOF或EMF图的概念表示这些概念
当然，定义自己的DSL也有非常多的困难，举几个例子：
- 怎样用最好的方式表示概念。这需要有相当多的领域经验；
- 每定义新的元语言，用户就需要重新学习，如果DSL很多，掌握起来有难度；
二、总结
此文讲解了元模型的相关背景知识，下文将介绍Acceleo在这些概念基础上的应用——模型到代码的生成。
从广义上讲，元数据不仅可以描述内容本身，也可以描述整个内容体系。这就产生了内容元数据体系结构的问题。
内容元数据可以分为以下几种：
内容元数据
直接关于内容的数据。
这个层次的元数据和内容相关，不同的内容类型会有不同的元数据。
比如，对于视频内容和文本内容，其元数据的结构会有差别。
内容元数据根据内容的分类关系，会有对应的继承关系。
关系元数据
由于内容元数据之间具有关系，所以需要有数据记录这项元数据之间的关系。这里数据不妨称之为关系元数据。
聚合元数据
除了元数据之间有关系外，内容之间也有相关性。描述内容之间相关性的数据表达了内容之间的聚合，称为聚合元数据。聚合元数据按照相关关系的不同会有不同的体系。比如按作者聚合，按来源聚合，按主题聚合等等。
知识元数据
对于上述三种元数据，可以进行一定程度的抽象和总结。比如对于聚合类型的事先定义等等。如果把上面的元数据看作“操作层面”，则这些数据可以看作“知识层面”，所以暂且命名为“知识元数据”。
元元数据
这里元元数据定义为“元数据的元数据”，元元数据也是元数据，所以能够描述自身。可以参照元元模型的概念来理解元元数据。
综合考虑上述几种元数据，我们就可以建立一个相对完整的内容元数据体系结构（或者叫内容元数据架构）。
内容元数据参考模型：
元元数据参考模型：
