【模型驱动软件设计】一个典型的Web应用案例分析

         在大体上确立了MDSD的基础，特别是为以体系结构为中心的模型驱动软件开发确立基础之后，为在实践中熟悉MDSD，下面开始分析一个实用案例。

一、应用程序开发

         应用程序开发的一次迭代首先要从创建或扩展一个应用程序设计开始，在本例中使用UML工具。通过一个MDSD生成器，UML工具输出的应用程序设计的XMI表示被转变为一个实现框架。实际的业务逻辑是通过手工编程实现的并被集成到生成的基架代码内。为此，我们使用保护区（protected area）。在句子构成上，这些使用目标语言写成的注释，不过它们是由MDSD生成器解释的。在生成的代码中每个保护区都有一个被写成注释形式的全剧唯一标识符，而且被唯一地连接到一个模型元素。

1、应用程序实例

      为了形象的说明一种整体性的软件开发方法--从业务流程分析、以体系结构为中心的设计、模型驱动代码生成到业务逻辑实现，应用程序是基于一个简单却比较重要的例子创建的。

      例子描述了一个汽车共享公司信息系统的开发过程。

                                             汽车共享应用程序的用例概况

              汽车共享1.0版实现了系统用例“预约汽车”并且允许汽车预约和汽车管理。出于授权和计费目的，汽车共享团体的成员在系统中进行了注册。该系统的主要目的是通过电话中心代理电子执行汽车预约。

         汽车共享应用程序的体系结构是一个典型的三层体系结构，由一个表示层、一个处理层和一个持久层组成。它是基于J2EE架构的。 

汽车共享体系结构

           表示层按Struts方式使用基于Servlet Model2的体系结构的MVC模式。

           持久层视野一个持久业务对象模型（Business Object Model，BOM），该模型由EJB实现。委托容器管理的持久性（Container Managed Perisistence，CMP）机制和关系数据库一起处理持久型。

          一种类描述体系结构概念的设计语言（UML配置文件）帮助设计了PIM形式的汽车共享应用程序。在UML配置文件中，可以找到在概念体系结构概况中出现的简化形式的概念。（例如实体对象、值对象等）。到目标平台的变换由一组生成器模版实现，这些模版将从模型中生成需要的源代码。

  生成软件体系结构和运行环境 

2、MDSD工具

              为了实践应用MDSD需要一种UML建模工具和一个MDSD生成器。UML工具必须能够和UML配置文件一起工作。目前，还不存在能够评估建模约束的主流UML工具，即能够检查以OCL表达式为形式的元层断言。因此，检查约束需要MDSD生成器的支持。

          生成器必须读取各自UML工具提供的模型并把它们用作生成的输入。现在大部分UML工具能够用XMI格式保存模型，不过XMI的质量不同。因此，MDSD生成器应该为不同的建模工具提供预先定义的定制适配器。

3、例1:模型的简单变化

        第一个例子描述了汽车共享应用程序静态类模型的一个简单变化以及设计、生成和构建这个循环的执行过程。因为汽车共享应用程序所需的JSP完全是由带有类别模版的类的信息生成的，所以改变表示层的某些内容是不错的建议。

       一旦涉及开发中的简单变化，就只是工作在模型层。在发生这样的变化之后，模型以XMI格式输出。生成器解释XMI并生成相应的源代码。构建和配置都发生在IDE或Ant环境下。

       很显然，这里的模型起到源代码的作用-所有有关变化的信息都保存在模型中。因此，除了实际源代码外，建议将模型集成在应用程序的发布管理中。

4、例2:模型的变化和保护区

         第二个例子具体阐述了如何提供保护区内业务逻辑的个别部分。为此，考虑如何在处理层中确定预约所需的一个参数以及它如何被表示层所用。

5、例3:使用动态模型

         除了基于静态模型生成源代码的选项之外，诸如活动图和状态图的动态模型也可用于代码生成。

导航顺序的变化 

        控制流完全可以由应用程序设计生成。不需要对Struts配置进行进一步的手动操作。经验表明，这样做是特别有利的，因为活动图也极好地记录了导航，并可供域专家们讨论。 

6、开发和体系结构之间的相互作用

        应用程序开发和体系结构之间的良好协调是MDSD项目成功的关键。在生成软件体系结构交付的时候，生成体系结构开发并未结束。正如在例子中描述的应用程序开发步骤所示，在项目期间绝大多数情况下都会出现改变生成软件体系结构的需求。一方面，需要额外的代码保护区以允许各自的调整；另一方面，已经确定的是新的体系结构模式必须支持生成。只有接受从应用程序开发得到的反馈并将其并入生成软件体系结构中，团队才能得到一个满足需求的、最优的、可持续性的解决方案。在这方面，生成软件体系结构像架构一样演变和发展。类似地，它必须使用适当的版本并且可以被那些使用它的项目访问。

     为了检验自己对于改进使用中的生成软件体系结构的想法， 可以用一个“沙盒子”进行局部测试。保护区外的代码在重新生成代码之前将保持不变。如果变化能够产生期望的结果，可以通过改变生成软件体系结构来使正规项目都会收到它的影响。这种方法的优势是生成软件体系结构始终处于一种格式良好、一致的可用状态。

7、中间结果

       在充当软件开发者的角色时，有更多的时间处理基本的任务--实现特定项目的业务逻辑。一个MDSD生成器或者生成软件体系结构承担了用于开发技术基架代码的单调复制和粘贴工作，这些对业务相关的编程来说毫无意义。和非生成方法相比，纠正技术代码中的错误更加容易而且执行起来效率更高。基架代码中的缺陷只需要在一个地方修改，也就是在生成软件体系结构的变换规则中，这类似于在架构中修补缺陷。在重新生成代码之后，所有有缺陷的代码将被正确的代码取代。

       因为在生成的骨架中集成了手写的业务逻辑代码，所以也就失去了应用程序完整的平台独立性和自动的可移植性。

二、体系结构开发

          避免冗余是关键概念之一。冗余不只存在于EJB层，而且还存在于主流软件体系结构的其他所有层中：流控制、表示、控制器和传统集成等。我们的目标是将这些冗余尽可能全部分派给一个生成软件体系结构，该结构不仅仅是从单个部分或页面，而是从不同的层了解所有的构建原则和编程模型。这种方法的好处是可以极大地提高应用程序开发的产量。

        这种生成软件体系结构远远超越了简单的生成器工具，例如XSLT或XDoclet，而且不依赖于特定的应用。它可以重复使用并且支持具有相同技术属性的一整套软件系统。只要汽车共享应用程序和保险应用程序共有相同的基本技术原则，它们就属于这套系统。

1.UML配置文件

          首先，需要一个允许创建正式MDSD模型的以体系结构为中心的配置文件。为了建模，使用一种能够捕获应用程序中使用的体系结构概念的设计语言。设计语言的焦点在于体系结构的可重用性，并因此产生了一种完全从技术细节中抽象而来的以体系结构为中心的设计。通过适当的规则，模型可以被转变为适用于各种目标平台的源代码。

        理想地，UML工具内定义包括约束的配置文件，而且UML工具可以解释该定义，因此完全允许为某个类别模版定义那些标记值，并且要检查配置文件的建模规则。遗憾的是，许多通用的UML工具并不具备这些特征，因此正式的UML配置文件定义仍然有文档规范的特征。

2.变换

        在定义一个UML配置文件后，现在处理实际的代码生成，这不是一个简单的任务。幸运的是，某些局部任务具有一个更加普遍的本质，而且MDSD工具将为我们完成这项工作。这包括中和UML工具和XMI输出、模版扩展控制、输入/输出流处理以及为实现业务逻辑的保护代码区扫描和持久性。大多数MDSD生成器是架构并且使用一种模版语言以一种直白方式描述从模型到代码的变换。

1）元模型/配置文件的实现

       为了使生成器架构能够产生目标平台的实现骨架，需要一个应用UML配置文件的Java实现。

       生成器架构能够实例化这种专业的元模型--在生成器一次运行的初期，它为具有类别模版的每个模型元素创建一个元类实力。

2）模版编程

        模版产生特定平台的实现骨架。模板与生成的代码非常相似而且能有一个参考实现轻易得到。在创建模版的时候，参考实现中的固定部分作为纯文本被复制到模版定义中并与元模型中读出的性质相结合。这样，例如汽车共享应用程序EntityBean的所有类和描述符以及该应用程序EntityBean的配置、持久型和关系的特性完全由标注为Entity Object的类产生，除了业务逻辑相关查找的EQL。

3.MDSD生成器的运行模式

openArchitectureWare架构师如何工作的 

组件及其作用如下：

• 生成软件体系结构包含生成器使用的所有必要模块。
• 设计语言（design language）。UML配置文件经常使用设计语言使用：类别模版、标记值和约束都用于用特定域概念扩展标准UML。
• XMI输入（XMI input）。UML设计由建模工具输出到一个XMI表示中。生成器能够处理设计的XMI表示。必须为每个模型元素分配一个UUID。
• 元模型实现。MDSD生成器是自由配置的元模型的特征。这是Java语言实现的，这意味着对域每个标准的UML元素和用设计语言实现的每个类别模板，元模型中都正好存在一个Java类。
• 模版（template）。openArchitectureWare架构使用一种模版语言和用Java实现的元模型构成一种面向对象的生成器：元模型的构建自我翻译。
• 生成器后端（generator backend）。后端对模版进行注释，完成文件的处理，同时扫描保护区域并将现有的手写代码内容保存到最新的生成骨架中。
• 实例化规则（instantiation rule）。生成器允许以一个XML文件的形式定义XMI表示及元模型之间的映射。
• 运行系统。在逻辑上，运行系统或平台是生成软件体系结构的一部分，因为它不依赖于具体的应用程序。

      在应用程序的生命周期内，功能性需求的改变和扩展将是必要的，不过有关应用程序的体系结构方面的需求也可能变化。

6.基架代码的边界

        到目前为止，已经说明了在体系结构开发中要完成的任务以及如何定义基架代码。不过，如何用这种骨架实现手工开发的代码--一般是业务逻辑，以及如果出现重复的再生和结构性变化如何对它进行维护？各种方法可以集成生成的基架代码和手工编写的业务代码。

7.结构化元程序

        这里介绍的模板构成了一种可能散步在两种语言之间的MDSD变换的实现技术。这里有效地处理元程序，因为它们负责创建程序。不过应该牢记元程序也是程序。

三、结论和展望

         OMG_MDA方法的实用性经常会被部分人质疑，这可能已经被人们发现了。确实有一部分人认为MDA只是一种“理论家们的教条”。不过，通过多年的时间以及不同领域和不同规模的项目应用，这里介绍的实效版的以体系结构为中心的MDSD已经证明了自己的实用价值，而且早期的采纳者们已经开始卓有成效地使用这种方法了。

      有人认为，介绍生成方法会限制他们的个人自由，或者他们害怕被生成器供应者掌控。出现这种偏见的代表性原因是由于使用CASE方法或者通过丢失的或不好的信息产生的失败经验。方法本身并不需要为特定的人员分配角色，它只是描述特定角色要完成的任务，例如开发者和设计师。分配角色是团队或项目经理的主要责任。

      除了一种适当的方法论之外，支持实现所需概念的工具的可用性对成功使用MDSD也很重要。通过分布建模和配置、生成器集成以及对元级OCL约束的支持来更好地支持UML工具方法是尤其值得的。

      以体系结构为中心的MDSD并不是唯一的MDSD变型方案。