【模型驱动软件设计】分类

            前面已经为MDSD确定了一个统一的术语，所以现在开始研究相关课题的分类。

一、比较MDSD与CASE、4GL和向导

        模型驱动软件开发的一个显著特征是使用的开发环境绝对不是静态的，不过实际上可以支持任何的目标体系结构、建模和目标语言、接口和运行组件。

       相反，一个标准的CASE或4GL工具一般至少会预先确定一个域体系结构的一个组件--而且在大多数情况下，会预先确定所有的组件：

•     DSL建模语言
•    转变
•    平台和目标体系结构

        这种关注一个域的工具不是特定的：它们试图遵守“通用型”的教条--一种适合所有场合的预先考虑的组合。这种假设在现实中完全是不切实际的而且引发了重大的问题。典型地，用这种方式可以快速创建应用程序的80%，而剩下的20%最终将耗费全部精力的80%。这是因为这些工具的不灵活性迫使工作区域它们对立。这里不能应用独立的体系结构需求和接口，更不用说是域的知识了。

        MDSD意味着明显地放弃所有“通用型”的方法。它明确地强调开发的方法论，而不是开发的环境。

       通常，人们希望生成的所有方面都是由手工实现的而且至少被验证一次。只有在第二步中才从它们中提取出域体系结构，然后基于一个输入模型自动生成特定的特征。可以先不考虑在传统的生成方法背景下出现的问题：

•       生成系统的运行性能如何？
•       生成的源代码的质量/可读性如何？

    所有的这些因素都和推导出变换的参考实现一样好或一样坏。

     当然，不必从打草稿开始：只要软件系统族是生成可用的，它的有效性就会乘以它的技术为基础的每个应用程序--即，作为族“成员”的任何应用程序。

     MDSD不能与代码生成向导或模式扩充器相比。通用开发环境的“有用的辅助”部分，或者某些UML工具的模式扩充允许自动生成类骨架，例如，允许EJB或允许生成类结构。不用于MDSD，这一步通常只执行一次。它丢弃了用MDSD实现的可重复的变换，同时保持了用户化，甚至失去了由MDSD引入的额外的抽象层。

二、比较MDSD与双向工程

         双向工程是一个能够对模型和由该模型生成的代码做任何改变的概念。这些变化通常是双向传播的而且所有的工件总是一致的。在这种情况下，从代码到模型的转变（逆向工程）就显得特别有趣。

前向/逆向/双向工程与MDSD 

           在这种方法的背景下，模型和代码拥有下相同的抽象层。这实际上是程序结构的一种可视化。在这种场景下，自动跟踪模型中代码的变化既是可行的又是有帮助的。

          MDSD用一种不同的方法：模型绝对比由它生成的代码更加抽象。因此手动改变生成代码之后，一般不可能自动保持模型的一致性。为此，应该避免用手工改变生成的代码，因此有必要精确地定义要生成哪些部分以及用手工实现哪些部分。不使用双向工程，可以求助于各种其他方法来获得期望得到的代码。

• 抽象。决策的抽象层被提升到了模型层。只有能够识别模型层上相应的抽象概念，这才是合理的。
• 标记模型。这涉及在不提升抽象层的情况下将代码层决策移动到模型中，这个过程被称作用实现决策“标记”模型。
• 代码类分离。这涉及目标体系结构的调整，用这样一种方式，手工创建的代码就必须写入为该目的特别创建的类中。
• 标记代码。它是由将代码引入保护组组成的，而且是通过使用特殊标记防止放置在它们之间的代码在重新生成时被覆盖实现的。

三、MDSD和模式

     模式（体系结构模式、设计模式、术语）与MDSD没有明确的关系。模式是记录下来的解决特定重现问题的最好惯例。不过，这两个领域之间具有某些有趣的关系。

1.模式和变换

        模式和MDSD的关系源自一个事实：变换是“将”最好的示例标准化“的一种形式，通常通过变换来创建与模式解决方案的结构相一致的目标模型（和相应的生成代码）中的结构。

      在这种背景下，理解一种模式并不仅仅是由解的UML图组成的是很重要的。一种模式的关键部分会解释什么力量会影响模式的解，什么时候可以应用一种模式和什么时候不可以，以及使用该模式的结果。一种模式也常常会记录自己的许多变体，它们可能有着不同的长处和不足。在一种变换背景下实现的一种模式并不会说吗这些方面---这些变换的开发者必须对它们进行考虑和评价并做出相应的决定。

      另一个重要的问题是使用MDSD允许选择其他的办法解决特定的问题。模式并不是用代码生成来描述的，因此MDSD可能会使得用某个模式描述的问题的其他解是可行的，而在生成环境中，人们可能并不会认真思考这些解。

     一种MDSD变换也可以用来生成模型或代码的一种解结构（包括它的行为）。但是，开发者--变换的开发者，即并不是在应用程序开发中使用这些变换的开发者--必须或确定是否以及如何应用一种模式。

2.模式和配置文件

       某些UML工具和MDA（或精确的说，EDOC模式配置文件）在UML层上定义用于将模型包装为”模式“的工具支持的宏。这是一种误解，因为正如已经解释过的，一个真正的模式并不只是一个UML宏。此外，在许多工具中，这些”模式“只能被扩展一次，因此后来这种压缩的状态便丢失了。

3.作为一种DSL源的模式语言

       模式语言用一组模式来描述一种潜在复杂的设计或系统结构：EAI应用、远程基础设施和组件容器就是例子。模型通常和它们描述或阐明系统最重要行为的系统主要结构工件结合在一起，因此，其中模式语言是它们描述的一类系统的概念化。

      作为结果，这种模式语言是能够描述系统相关类的DSL所需的元模型挖掘元素的好起点。

     对每一种概念，为了能够生成这样的一个系统，模式语言中的模式描述这样一个系统时可能需要配置的”热点“。可以轻易地将概念、它们之间的关系以及它们可供选择的配置方案重新构造成一个元模型，该元模型成为描述和配置远程基础设施的DSL基础。

四、MDSD和域驱动设计

      专有名词”域驱动设计“DDD现在是家喻户晓。在开发一个特定域平台时，这种方法与MDSD有某些共同之处：DDD不使用DSL，他也不推荐生成代码。作为替代，DDD描述了技术、模式和过程元素，它们旨在创建”良好“的，通常基于UML的某个域的模型，而且旨在创建尽可能如实地保留或表达一种应用程序设计的代码。

      尽管MDSD和DDD之间不存在很强的互相关性，但是多学习一些DDD的知识对于提高建模过程、生成的代码和编程模型的质量是很有帮助的。

五、MDSD、数据驱动开发和解释程序

         在数据驱动开发中，应用程序功能的基础性部分是用由架构读取和解释的数据结构定义的。在传统上，这些数据结构是在一个也存储了应用程序数据的关系数据库中被定义的。用这种数据结构描述的方面常常在应用程序安装和安装之间变化，它们从客户的角度出发允许轻松定制应用程序，甚至常常在变化后不需要重新启动应用程序。

        正如在MDSD中，必须定义一个元模型来定义用来配置该应用程序的数据结构。不过，架构被用来在运行时动态客户化系统，而不是在运行之前使用那些数据生成应用程序的工件。

      模型的解释是数据驱动开发的本质方面。事实上，处理上面企业应用程序例子中的数据的架构可能被看作是一种解释程序。

六、MDSD和敏捷软件开发

    一个迭代式的增量过程是MDSD的坚强合作者，而且严格的时间定量能够帮助平滑地实现体系结构开发和应用程序开发之间的反馈环。

      MDSD的目标并不是支持一种特殊的（敏捷）方法。在观察用于迭代软件开发的少数但严格的MDSD规则的时候，任何敏捷方法论都可以控制开发过程的宏活动。在实践中，敏捷小组中的角色分配是基于个体的实力和能力的，而不是呆板的工作描述的。

      MDSD强调模型的重要性。这些和源代码，而不是可供选择的文档，具有相同的重要性。由域体系结构“生产”或生成一个系统的自动化程度与3GL语言编译的自动化程度相同。敏捷问题关注创建域体系结构和一个应用程序的建模及实现。

1.敏捷宣言和MDSD

敏捷宣言

1）个体和相互作用与过程和工具

      这一声明首先表达了对人的一种高度尊重。毕竟，它意味着不应该确立任何不考虑人的过于正式的过程。一个团队应该定义适合自己的特定条件的开发过程，并且要持续地完善它。团队成员之间的相互作用优先级要高于正式的以文档为中心的过程。

      这里很明显的批评了使用诸如版本控制系统或编译器工具，在MDSD中的一部分编程是有DSL完成的前提下，生成器取代编译器而且不存在与敏捷开发的矛盾。

2）可用的软件与完整的文档

     在项目经验中，传递可运行的软件比传递好看的文档更加重要，如需求、概念、体系结构或设计。在MDSD中，模型就是源代码。图表并不仅仅是装饰，而是一个中心工件。图表和软件是不会疏远的并且总是实时更新的，因为应用程序是直接由模型生成的。

     因为能够自动完成枯燥、重复的实现工作，所以MDSD极大地加速了可运行软件创建，我们并不是要宣传一个瀑布型过程，其中首先实现域体系结构，随后在项目的第二个阶段，用它创建一个应用程序。这两方面更紧密地结合允许更加及时地创建可运行的，不过却不必是完整的应用程序。

3）客户协作与合同磋商

        这方面表达了允许客户尽可能多地参与应用程序开发的愿望。特别是在项目运行期间应该能够及时响应变化的客户需求，而不是从一开始就采取一种固定的合同权利。

       这里MDSD具有优势贲传统的迭代增长的开发更加明显，尤其适合于应用了可以被（重复）用来于客户交流的非技术DSL并因此缩短了反馈环的时候：此外，DSL与是否应用MDSD无关。

4）响应变化与计划

      该评价是关于项目过程中灵活并入客户需求的，而不是坚持在开始时已经写好而且可能不再适合客户正式定义的需求。MDSD简化了这一过程。

• 当域相关的需求变化时，生成方法允许比传统的软件开发更快、更连贯地实现这些变化。
• 可以在一个地方改写变换实现的技术侧重面，而且变化会自动传遍整个应用程序。

2.敏捷技术

         MDSD与敏捷技术之间的相互作用。

        结对编程是极限编程领域很有名的技术，其中两个开发者共享一个工作平台并一起实现应用程序。优点是错误很快就可以被检测到，因为一个开发者实现细节的同时另一个开发者在脑海里有整体的概念并识别错误。当然这对MDSD同样有效。在建模（依靠DSL）过程中，开发者和域专家甚至可以一坐在一个工作平台前。

          另一种重要的技术是测试驱动开发，也就是ices有限。这里的思想是首先实现测试，然后开发面向它们的应用程序，直到通过所有的测试。在MDSD背景下，这种方法当然在原则上可能也是可行的。但是，由于模型的附加规范层，甚至存在更大范围的可能性。

        将应用程序设计转变一种标准化实现经常被看作是限制了开发者的自由和他们响应的体系结构，尤其是在敏捷项目中。在这方面，将变换中的体系结构编码化只是这一连串想法的逻辑下一步。作为一种敏捷技术，重新分解主要应用于模型、平台、变换和手工实现代码。

      总的来说，我们认为通过体系结构的显示编码化和域知识，以及通过分离域体系结构和应用程序开发，MDSD能够帮助衡量敏捷技术。