【模型驱动软件设计】「过程和工程」MDSD过程构件和最佳实践

一、简介

          本章介绍重要的、经过证明的过程构件，这些过程构件允许并支持项目中模型驱动构件开发的成功使用。

       大多数过程和实践可以非常容易地转移到一般性的--也就是说，非体系结构中心的--- MDSD。只在体系结构中心案例中有意义的技术，或者需要特定解释的技术，同样进行了显式的标记。

      推荐将这些最佳实践嵌套在迭代增加的、灵活的开发过程中。MDSD与后者没有冲突，实际上是很好地适合以增强它的优点。从理论上来说，MDSD甚至可以与瀑布开发过程相结合。然后，瀑布方法中众所周知的风险仍然存在，这就是我们--与MDSD完全无关--不推荐使用它们的原因。

二、应用程序和域体系结构开发的分离

1.基本原理

      域相关分析和作为正式模型基础的域体系结构 

     支持MDSD的一种最重要的思想是，正式的建模步骤暗示了两个先决条件，这两个先决条件没有相互关系，但可以在很大程度上并行开发：

• 必须知道具体应用程序的迭代或正价的功能/专业需求；
• 必须定义用于建模的正式语言（DSL）。此外，对于自动的进一步处理，必须以转换规则的形式将语言绑定到具体的MDSD平台。这就是术语“域体系结构”所概述的内容。

        如同其名称所指，域体系结构是结构化的并支持域。在原理上，这种域与单个的应用程序无关，或者换句话说，它覆盖了软件系统家族。

     上图所示的活动图不应该被误解为瀑布过程。它主要显示一种基本原理，每种迭代都基于该原理。

     正式的建模用于连接具体应用程序的概念与由域体系结构提供的概念--更为精确地说，使用由域体系结构提供的语言（DSL）表达功能。借助生成器的支持来转换正式的模型，并且将其映射到平台。

2.域体系结构开发线程

     为了帮助创建域体系结构，需要一些工件和活动。MDSD体系结构开发线程的目标是可重用行以及质量和效率增强。从过程的观点来看，它是MDSD的中心方面。因此，下图首先放大了现实了域体系结构创建活动。

域体系结构的创建 

    显示在图中的分区将活动划分为域、转换和平台3种类别。在每种类别中，都产生了域体系结构的工件（以深绿色显示）。这里只显示了具有最重要相关性的普通案例情况，因为--根据我们的经验--包括其他所有内容将使本质的问题无法清除显示。特别地，没有显示任何迭代循环。

 1）原型化

     在项目开发时，期望使用的平台通常已经存在，例如J2EE或特定的框架。MDSD体系结构开发线程的一种目标时将这些工件与具有丰富语义的和域特有的MDSD平台合并。因此，首先收集作为概念证据的原型相关经验总是非常有意义的。除此之外，这种原型也可以被认为是面向MDSD平台的第一步。

2）开发平台

    平台构成了生成代码和非生成代码的基础，并且用于保持转换的简单性。域体系结构的生成部分与使用的运行时系统组件具有相关性，但相反的情况则不正确。

     平台的开发也应该迭代地前进。在这种环境中应用成狗技术可以从中获益。

     另外，平台和生成代码之间的边界可以在域体系结构的进展过程中在任何方向上改变。

3）创建引用实现

      引用实现仅仅是MDSD体系结构开发线程的中间结果，但在开始创建域体系结构时，引用实现就非常重要。

      不应该将引用实现错误地理解为简单的、隔离的示例，在必要时可以从该示例中派生关于实现的建议。可以通过原型创建引用实现，但该引用实现将服务于更为重要的目标：结合引用模型/设计，它将掩饰术语域的DSL的应用和实现。这种氛围两个部分的引用举例说明了每个平台上从模型到实现的迁移。对于新的软件系统家族，首先手工创建引用实现。之后，从该引用实现中派生转换。引用模型的生成实现，或许还加上手工编程的域逻辑，必须产生完整的、可执行的引用实现。

      引用实现全部的附加价值只有通过引用实现和引用模型之间的相互作用才能获得。引用实现的具体功能性内容在本质上是无关的---只是域问题。

4）域分析/设计

       这种活动主要服务于查找域的元模型和适合的、具体的DSL。这里只列出构造DSL的最佳实践。

     体系结构中心的DSL也称为设计语言。对于这种设计语言，经常使用作为其基础的UML。然而，在一些方面UML完全不可使用，例如GUO布局的建模，从而可能不得不使用另一种符号。最终，具体的语法总是假设存在没有抽象语法重要的橘色。

    根据DSL的概念，体系结构设计者必然也会在生成代码和域逻辑之间绘制分界线---并且由此得到开发者的自由度。

     适当的建模语言的定义无疑是MDSD中最重要的挑战。

5）创建引用模型/设计

     引用模型是DSL的实例，因为它通过DSL的方法表达域示例。

    引用实现的相互作用非常重要：引用模型和引用实现共同举例说明了DSL的语法和语义，并且因此具体描述了域体系结构的概念。

6）归档编程模型

    编程模型的定义只有在域体系结构包含“语义间隙”时才相关，“语义间隙”表示通过模型转换显现的代码框架，应用程序开发者必须在编程语言中补充该代码框架，从而允许创建可运行的应用程序。

   在MDSD环境中，编程模型描述了应用程序开发者对于域体系结构的观点。

    编程模型非常易于以表的形式归档。表包含--除了DSL各自的构造--对引用模型和引用实现的适当摘录的引用。

    结果表明，走查形式的指南时最合适的方法，这种形式可向开发者解释如何使用DSL开发具体的应用程序。这种指南应该覆盖DSL和编程模型的其他方面，包括需要手工编写的代码，或者如何操作/集成生成器工具。

7）派生转换

    这种活动将DSL的映射形式化为平台和编程模型，并达到如下程度：自动转换可以将给定的应用程序模型转换为实现或程序模型。

   如果应用程序的域逻辑不能通过DS L完全表达，则需要集成生成代码和非生成代码的技术。

8）创建DSL编辑器

   并不是所有的DSL都是UML配置文件，因为可以应用标准的工具，它具有不同程度的有效性。在非常特殊化的域中，为定义符合DSL的域模型创建特定的工具是非常实际和可取的方法，从而可进一步增加人机工程学和MDSD方法的有效性。这可以桂南为成本--价值比率的问题，只能针对每种单独的情况回答这个问题。

3.应用程序开发线程

应用程序开发线程的活动 

      这里显示了非常简单的、没有迭代循环的普通情况。一个循环可以获得从几天到几分钟的任何内容，这取决于一个步骤的强度。

1）正式的建模/设计

    在这个步骤中会涉及到分析和体系结构线程：现在以域体系结构的语言（DSL）表达功能需求。参考模型充当这种环境中的方向指南。这个步骤需要信息反馈和认为的判断，因此不能自动化。

2）生成

     可以完全机械化地执行这个步骤。相比较于正式的模型，不会产生任何信息收益：通过域体系结构的转换，将其自动转换为适合MDSD平台的形式。

3）手工实现

    不能在DSL中表达的域逻辑必须在生成发生后手工添加。在我们的案例研究中，这些完全是实现程序框架中受保护区域的内容。

    域体系结构的相互作用甚至可以在实现期间发生。项目的组织必须允许必要的反馈循环。

4）组织的方面

   在理想的情况下，应用程序开发和域体系结构开发之间的分离不仅由合适的开发结构支持，还要通过改变团队、项目或公司的组织结构来支持。

三、双轨的迭代开发

      现在讨论应用程序和域体系结构开发之间角色和工件的分离。这一节介绍两种线程的同步化。明显存在从应用程序开发到域体系结构开发的相关性--以和所有使用的框架开发相同的方式。从需求管理的观点来看，这意味着应用程序开发团队假设了顾客在域体系结构开发中的角色。

双轨的迭代开发 

      注意，基于同步时间盒的增加的、迭代的过程不排除在进入迭代循环之前的域分析。相反，实际上需要对域基本概念的良好理解。只要应用程序开发进行中，进一步的域分析就会迭代地发生--作为体系结构分析的一部分，该体系结构分析现在委托给它自己的项目。

四、目标体系结构开发过程

     域体系结构开发过程的最佳实践只是一方面，要考虑的其他重要方面如下：

• 如何提出合理的目标体系结构？
• 如何使其“为MDSD做好准备”？
• 如何在重要的项目中实现它？

1.3个阶段

    软件体系结构的开发，特别是可用性在MDSD环境中的开发，应该分为3个阶段进行。在每个阶段中创建一种核心的工件--下面将简要介绍这些内容：

• 详细描述
• 迭代。
• 自动化。

2.阶段1:详细描述

         这个阶段的最佳实践与如下活动有关：域体系结构开发线程的原型化、文档编程模型和平台开发。

1）技术无关的体系结构

2）编程模型

     一旦定义了技术无关的体系结构，并且转出了该体系结构，开发者必须根据该体系结构实现功能。

3）技术映射

    软件必须提供某种服务质量级别。将QOS最为项目的一部分来实现代码非常高。甚至可能在团队中没有适当的技术。

4）模仿平台

    基于编程模型，开发者现在知道如何构建应用程序。除此之外，开发者需要能够在本地运行系统，至少运行单元测试。

5）垂直原型

    体系结构需要实现的许多肺功能需求取决于技术平台，最近只在技术映射中选择了该技术平台。映射机制甚至可能是无效的。

3.阶段2:迭代

     现在具有适当的基本机制，应该确保它们可以实际地为项目工作。因此，重复上面给出的步骤，直到它们保持合理的稳定性和可用性。

   然后，如果有较大的项目团队，转出体系结构到整个团队。如果需要开始模型驱动的开发过程，则继续阶段3。

4.阶段3:自动化

      这个阶段的最佳实践与如下活动相关：域体系结构挨罚线程的派生引用实现/模型、派生转换和域分析/设计。

    具有技术无关体系结构。需要自动化软件开发过程的各种任务。为了能够自动化，需要编码技术映射的规则，并且定义基于DSL的编程模型。

   因此，定义正式的体系结构元模型。体系结构元模型正式定义了技术无关体系结构的概念。在理想情况下，这种元模型也可以用于转换程序/生成器中，使用该转换程序/生成器自动化开发。

     形式化是一把双刃剑。

1）粘贴代码生成

    在实现方面，技术映射---如果足够稳定--一般是重复的，并且因此是冗长的和内容易出错的。同样，已经在编程模型的工件中定义的信息通常需要在技术映射代码中冲。重复的、标准化的技术映射是优秀的，因为它反应了经过很好的深思熟虑的体系结构。重复的实现总是倾向于导致产生错误和失败。

2）基于DSL的编程模型

    已经定义了编程模型。然而，该编程模型仍然过于复杂带有许多反复实现的域特有的算法。域专家很难在它们每天的工作中使用编程模型。

3）基于模型的体系结构确认

    现在具有所有适当的工件，并且已转出体系结构给大量开发者。需要确保按计划使用编程模型。不同的人可能有不同的资格。正确使用编程模型对于体系结构满足它的QOS许诺也是至关重要的。

五、产品线工程

    产品线工程（PLE）将处理域的系统分析，并且软件产品线的设计。它的目标是充分平衡软件系统开发期间自动化和重用的潜在性。产品线工程因此作为分析方法无缝地集成在MDSD环境中。

     换句话说，它为域体系结构开发线程的域部分中的所有活动提供了可靠的后台。

1.软件系统家族和产品线

      软件系统家族的初始定义如下：

      首先研究程序集的常见属性，然后确定单个家族成员的特殊属性，值得以这种方法通过某个程序集研究程序时，就认为该程序集构成家族。

     另一方面，产品线由一组功能相关的产品组成，这些产品具有共同的目标市场；它的组织时顾客组特有的。在理想情况下，要在软件系统家族的帮助下实现产品线。

2.与MDSD过程的集成

     MDSD可以被认为是产品线工程的实现技术。类似地，产品线可以被视为MDSD的分析方法。产品线实践可以并且应该迭代地和增加地使用：PLE不应该被视为单独的MDSD先前阶段，而更应该被视为附带的方法，即使它确实是MDSD项目的早起阶段的优秀方法。

3.方法学

   产品线工程的过程由3个阶段组成。

产品线工程的阶段 

1）域分析

     域分析中的第一步是域作用域划分。在这要确定域的边界。

2）域设计与实现

       软件结构的定义是域设计的一个方面。首先以平台的形式实现域产品的常见特性。因为对于所有产品，这些常见特性是相同的，没有必要以任何方式重复实现它们：它们形成了常见目标体系结构的基础。

4.域建模

      域由域特有的抽象、概念和规则组成。如何确保定义的DSL以及由此而来的模型化应用程序构成该域的正确子集？

     DSL的元模型必须受到限制，并且必须尽可能接近于域。特性模型可以在这个方面起到帮助作用。如果适当的话，元模型必须忽略不需要的或不必要的基本元模型属性--例如，UML的属性。在这种环境中约束提供了功能强大的机制。

     域的术语表或本体论可以是实现适合的元模型的有用的第一步，然后在迭代开发期间对其进行改造。

5.更多的读物