英语原文共 16 页，剩余内容已隐藏，支付完成后下载完整资料
关系数据库视角下模型驱动工程的教学
东·贝特瑞1，艾瑞克·拉提墨1，梅迪·阿桑萨2
（1 德克萨斯大学奥斯丁分校，奥斯丁，美国德克萨斯州 78712，
batory@cs.utexas.edu, e@utexas.edu
2 巴斯克自治区大学（UPV/EHU），西班牙圣塞瓦斯蒂安，maider.azanza@ehu.es）
摘 要：我们从关系数据库的角度重新诠释了MDE，从而提供了一种使用本科生应该熟悉的概念和技术来教授、理解和演示MDE的替代方法。我们使用(1)关系数据库来表达模型和元模型，（2）序言来表达约束和M2M转换，（3）Java工具来实现M2T和T2M转换，（4）面对对象的 shell脚本语言来组成MDE转换。案例研究证明了我们方法的可行性。
1 概 述
模型驱动工程（MDE）是程序规范和构造的标准技术。我们认为向本科生普及MDE概念（模型，元模型，M2M，M2T，T2M转换，约束和引导）是非常重要的，这样当他们在工业中遇到它时，他们就会对MDE有所了解。我们的动机来源于经验：除非学生在学校里遇到一个想法（不管是否成熟）否则他们将来不太可能接受它。此外，教学MDE和将MDE思想具体化的工具和语言密切相关，二者是不可分割的。
我们最初试图做到这一点（2011秋季），但是失败了。我们使用Eclipse建模工具[1]并且花了相当长的时间来为学生们制作观看的视频，包括安装教程和使用工具，都失败了。不管什么原因，为学生安装就存在问题。Eclipse的最终发行版本里面安装了所有的工具，但是当学生们使用这些工具时，结果就没那么好了。我们使用Eclipse来绘制一个拥有简单的赋值的元模型的状态图（主要是在类中呈现的东西），让Eclipse生成绘制状态图的工具，并使用这个生成的工具来绘制特定的状态图。这对大多数学生来说都是非常令人沮丧的经历。25%的优秀学生得到了使用它的权利，50%的人提交了中等的意见书，剩下的就放弃了。另外一周（使用教程帮助）有89%的学生正确使用了，但仍然有太多人落后。整个经历给我们留下了苦涩的滋味，体验更糟的是我们的学生。我们不知道这是一个典型的情况还是一个反常现象，但我们不会再试一次了。
回想起来，我们发现了很多原因，但基本上使用Eclipse工具是主要问题。（1）我们使用的工具不够吸引人——即使是琐碎的应用，它们也很难被使用。（2）这些工具的使用使学生养成了那种如同中世纪学生使用咒语来解决问题的心态。点这里，点击，然后发生某些事情。从学生的角度看来，这是胡言乱语。虽然我们可以告诉他们发生了什么(我们没有），这种互动模式给我们双方留下了一个加深理解应该驻留的真空区。（3）经过多年的回顾，我们得出结论，使用，教授和理解这些工具的入门成本太高，我们对此感到非常不舒服。（学生是否同意这一点，是针对今年秋季的实证研究的主题）。我们寻求一种轻量级的方式来替代原先那种模式来理解和证明MDE，本科生应该已经知道使用的工具和概念。
在本文中，我们提出了一种改进而不是革命性改变的方法来理解和教授核心的MDE概念（模型、元模型、M2M、M2T、T2M转换、约束和引导）。在2012秋季，我们与新来的一个本科生班一起尝试了这种方法，问题更少了。（再次申明，我们谨慎的避免诸如“更好”或“更成功”等词，直到我们的实例研究的结果符合。我们使用适当的词是“有趣的”）。本文主要研究了该项技术仍在评价中的应用和案例研究。我们希望研究MDE或使用MDE的其他人能够从我们的简单方法中获益。
2 MDE模型和元模型
MDE可以理解为关系数据库的一个应用。尽管MDE通常以图（模型或元模型的可视化）来呈现，但所有的图表都有简单的编码来作为一组规范化的表。
请考虑图1a中的FSMs状态机的元模型，包括节点和边缘。图1b显示了基础关系表的结构（使用制造的标识符，用节点#和边缘#表示）。
这些表里的内容是FSM的一个实例用元组。本文第一位作者的饮食习惯的FSM和它的元祖显示在图1c和1d中。
图1 状态机及其表
制造的元祖标识符几乎消除了关系表设计的所有复杂性（c.f.[8,12]）。只需要五个简单的规则就可以对元模型映射到表进行定义，一个规则定义元祖实例化：
1.每个元类映射到一个不同的表。如果元类具有K属性，则该表将包含至少K 1列：一个用于标识符，其他的用于每个不同的属性。
2.在元模型[17]中n:m的关系是有效的，但在这里不行。每个关系必须有一个结束符是0..1或者1的基数。图2显示了如何将n:m的关系转换为一对1:n和1:m的显式关联的关系。这样转换的原因来自于下一条规则。
图2 n:m的关系图的转换
3.每个关系都有相关的“0:1”或“1”边上的单个属性表示。通常，关系会将属性添加到它所包含的两个表中。“n”方将有一个默认值属性，在规范化表中是不允许这样做的。“1”方允许拥有一元值属性（元祖标识符）。由于两个属性编码都是完全相同的信息，所以我们只需丢弃同值属性。图3是对最近三条规则的应用的一个说明：部门表有两列（#和名称），学生表有三列（#，学生学号和登记号）。包含部门#值的列通过登记与学生表相关联。图1a到图1b的映射是另一个例子。
图3 关系图与关系表的映射
4.对于和继承相关的类，超类的所有属性都将被传递到类表中。父类的标识被所有子类共享。不需要为抽象类生成表。具体见图4。
图4 继承关系图与关系表的映射
- 只有不是子类实例的类的对象才能成为表的元祖。这一规则将在第4节中更加详细的讨论。
- 元祖标识符可以自定义（如图1d中的e1和e3），也可以是可读的单列键（如nReady和nDrink）。关键值是自定义的首选；在工具中应该首先选择自定义的标识符。
请注意，关系表始终能够在数据层次结构进行编码。我们看到的规范化或者“朴实”表的简单是一个重要的概念。
3 模型约束
OCL是表达模型约束的标注语言。考虑到关系数据库的连接，我们可以做的更好。Prolog是计算机科学（CS）中用于编写声明性数据库约束的基本语言。它是图灵完成的，是所有学习计算机科学的学生都应该接触的语言。图5a显示了如何将关系表的元祖表示为Prolog的详细情况。图5a中的第一个事实定义了图1b的节点表的架构：它有三列{id、名称、类型}。
图5 序言表和目标元模型
下面是在FSM中强制执行的三个约束条件：
C1 所有状态必须有独一无二的名字；
C2 所有的转换必须在状态下开始和结束，并且
C3 一定有一个开始状态
在SWI插件中它们的表达如下；（Msg）是一个报告错误的调用库。如果没有违反每个约束的条件，那么allConstrains的值则为true。
4 模型之间的转换
MDE中基本活动是模型到模型（M2M）的转换。可以用序言的声明方式编写数据库到数据库（或M2M）的转换，而不是使用专门为MDE而发明的语言。
假设我们将图1d的数据库转换为符合图5b的元模型的数据库。（我们对抽象类着色，使它们更易于识别。表达这种转换的序言规则是：
另一个例子：图4的职员和教职员表的元祖不出现在成员表中。若要将元祖从子表中转到超类表中，可以使用以下转换：
由于序言是图灵完成的，数据库的转换的复杂性可能是随机的。
观察 在数据库设计和元模型设计之间存在着密切的联系。通过上述方式呈现MDE加强了这一联系。此外，学生不需要熟悉数据库来理解以上的想法。规范化表是计算机科学中的一个基本的、简单的概念结构。本科生可能以经在编程语言入门课程中接触到序言。（当你处理规范化元祖并且几乎没有列表时，Prolog实际上是一中简单的语言）。我们为其明显的数据库连接选择了序言，但怀疑Datalog,Haskell,Scala或其他功能语言可能同样有效。
5 模型与文本之间的转换
MDE的一个突出优势它可以实现样板代码的产生。这是通过模型到文本（M2T）转换完成，有很多工业中使用的文字模板引擎。 Apache Velocity是一个特别易于学习和强大的工具，见例4。我们对Velocity进行了两项小修改，以便将其整合Prolog数据库。我们的工具被称为Velocity Model-2-Text（VM2T）。
首先，我们为表格定义了Velocity变量。如果表的名称是“表”，那么表变量是“tableS”（将“S”附加到“表”）。这使Velocity可能遍历表中的所有元祖。
其次，Velocity模板将其输出标准化。我们引入了标记在模板执行期间将输出重定向不
同的文件。 MARKER的价值变量定义输出指向的文件的名称;重新分配其价值，将输出定向到另一个文件。使用MARKER的一个例子很快就呈现出来了。
图6a显示了一个类的元模型。这个元模型的两个例子，城市和城市账户，如图6b所示。包含两个实例的数据库如图6c所示。
图7a是一个VM2T模板。当非MARKER语句执行时，图7b是输出。每个类的定义最好应该在它自己的文件中。当所有语句都被执行时，会生成所需的两个文件（图7c）。
通过VM2T，将图1d的FSM数据库直接转换图8的类图表示的代码，从而将二者有趣的联系起来。
图6 一个类元模型，一个模型及其Prolog数据库
图7 VM2T模板和两种输出
观察 Velocity的好处似乎很明显：学生使用工业工具，而不是MDE或特殊版的Eclipse，它稳定，合理无缺陷，并且有相当好的文档。在我们看来，很容易学习使用，而且相对无痛。
图8 FSM代码输出的类图
6 文本到模型的转换
鉴于以上情况，学生不难理解图9：一个擅长使用FSM的应用程序工程师使用一种图形化工具，这种工具可以生成一个转换后的表格，并且通过VM2T产生FSM的源代码。
图9 FSM应用工程师对MDE模式的使用
缺少的是将图形工具的严格冗长的XML输出转换为干净的集合的Prolog表格，即文本到模型（T2M）转换（图9中虚线箭头所指）。编写一个简单的Java程序很容易，它可以读取XML，解析它，并输出包含Prolog数据库的单个文本文件。使用更通用的工具将XML解析为Prolog可能更可取，但会失去通过动手了解T2M内部转换的工作的优势。
寻找合适的图形编辑器GE是一个三重挑战：
- 它的XML必须容易理解，
- 它的XML必须是稳定的，意味着它的XML格式不可能很快改变，并且
- 它的调色板[2]是可定制的。
MS Visio易于使用，其调色板可以轻松定制，但其XML文件为不可理解的，MS定期修改这些文件的格式。更简单的GE，如Violet [21]，yUML [22]，UMLFactory [20]，满足（a）和（b）;为他们编写T2M工具并不困难。
我们还没有找到满足所有三个约束条件的GE。Violet是典型代表：全部调色板是硬连线 UML图只有一个。不能通过定义一组图标（具有图形属性）来绘制自定义图形。都可以做的就是翻译那些专门为给定的UML图表而设计的XML文档。这并不坏;它只是不理想。直到找到灵活的GE，否则很难引导MDELite（为目标领域建立定制的GE，这是MDE的一个关键想法）证明。
观察 MDE工具（如FSM工具）可以作为结构性编辑器。这是一个应该立即标注错误的图纸或防止用户创建不正确的图纸的工具。GE可能很愚蠢 - 它们让你画任何东西（比如连接没有节点的边缘）。需要用户提供即时反馈，需要将设计保存为XML文档，将文档翻译成Prolog表格，评估Prolog约束，并显示遇到的错误。然后才可以修改现有工具以呈现此反馈，但是不是很有优势。
<str
剩余内容已隐藏，支付完成后下载完整资料</str
资料编号：[22455]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
