内容


Rational Edge

模型驱动开发:MDD 模型是资产还是债务?

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: Rational Edge

敬请期待该系列的后续内容。

此内容是该系列的一部分:Rational Edge

敬请期待该系列的后续内容。

插图模型驱动开发(Model Driven Development,MDD),以及与其相关的基于 UML 的工具,已经出现十多年了。许多成熟的,技术强大的先进组织 —— 例如,那些进行 Ericsson 的 3G 项目的组织 —— 已经成功地使用 MDD,通过提高的生产力、质量,及投入市场的时间,显著地增加了它们的竞争力和市场占有率。研究表明,与传统的文档驱动及以代码为中心的开发相比,利用全面的 2 MDD 实践,可以提高生产力两到四倍 1

对于当前 MDD 技术的新的开发和扩展承诺要利用全面的 MDD 进一步提升组织的竞争力。这些开发包括基于模型的系统工程(Model-Based Systems Engineering)和“可重定目标的 UML”,这允许生成代码的完全自定义,包括定义如何将 UML 操作语句转化为高级语言,例如 C++,的能力。(设想一个逻辑操作表达式,例如 port.signal().send()。如今,可以直接将该语句“剪切并粘贴”到所生成的代码中 —— “重定目标”意思是模型之外的映射机制将告诉代码生成器,该语句要成为的实际的生成代码将是什么。)一些已经利用可重定目标的 UML 实现全面的航路的组织表明,有实质的附加 3 好处,包括开发生产力和运行时执行特性的提高。

尽管有强大的证据证明 MDD 的价值,但行业仍旧没有将其作为系统和软件开发的首选方法。事实上,许多大型组织似乎离开 MDD,而又回到较传统的文档驱动和以代码为中心的方法上去了。经验较少的实践者可能将最近对敏捷方法的积极呼声误认为是抛弃 MDD 的理由,因为关于这些方法的普遍的误解是它们“只与编码相关”。

本文目的在于鼓励广泛采用 MDD。文中分析了行业中目前使用的建模方法,以及为什么它没有得到较广泛的接受。文中还指导如何实现这个现代的可能非常强大的开发方法的真正潜能。此外,本文还试图展示敏捷方法和真正的 MDD 之间不存在冲突。事实上,将这两种方法结合起来会是释放 MDD 全部潜能的非常有效的方法。

解决系统复杂性

现今的系统常常是大型的,不论我们通过类的数量、用例的数量、代码行数、开发人数、变量数、功能点数,或其他什么进行度量。虽然大小本身没必要转化为复杂性中的大幅度增长,但是现今的系统确实倾向于比较早的系统复杂得多。此外,开发这些系统的成本非常高。当发生变更时,用崭新的系统代替原来的常常在经济上是不合算的 —— 举例来说,如果使用具有改进功能的新的平台,那么会出现额外的功能需求。取而代之,现今的系统必须以准许未来的扩展、修改,和移植的方式进行构建。这需要一个健壮且有弹性的模块系统架构,并且对于所有的开发人员都是容易接受且容易理解的。该架构还必须在系统的生命周期中保持最新,从而有助于未来的工作。

处理复杂性

几千年来,人类一直在寻找解决复杂性的有效方法。凯撒的格言“Divede et impera4也适用于今天的系统和软件开发,因为它是两千年以前用来管理罗马帝国的。解决系统复杂性的一种方式是以分层的方式分解结构和行为。这培养了在不同的抽象层次上同时工作的能力,根据手边的情况和任务或多或少地着重于细节。Visualization(可视化)对于规范以及设计和实现来说,也是一种有用的技术。它能令开发人员更好地了解系统架构和设计,并且还有助于系统验证和测试。

总之,开发人员可以利用支持下面三种技术的过程、语言和工具成功地解决复杂性:

  • Hierarchical decomposition(层次分解)
  • Abstraction(抽象)
  • Visualization(可视化)

Hierarchical decomposition(层次分解)。不同的分层虑及沿不同的维度分解系统。UML 中有许多不同的可用分层:

  • Structural(结构的)
  • Behavioral(行为的)
  • Package (artifact)(包(工件))
  • Inheritance(继承)

虽然大多数实践者不知道它,但是也许设计大规模系统的最重要且最有用的分层是在 UML2 中由结构化的类实现的结构分层。它令设计可以用非常有效且可视的方式表示“局部”,或包含,关系。在较传统的工程规程中,这种表示结构关系的方式已经作为标准的操作实践很长时间了。不幸的是,在软件工程中,在分析和设计过程中对结构包含的支持直到最近才出现,5 而它仍旧没有普遍使用。

Abstraction(抽象)。抽象概念专门着重于实体或东西的基本特性,省略那些对于正在讨论的实体的存在的整体目的或理由不重要的细节。当我们表示提升抽象层次时,这意味着我们正着重于实体的更基础,更高层次的方面,过滤了目前不重要的较低层次的细节。本质上,抽象允许我们着重于“做什么”与“怎样做”。

Visualization(可视化)。“一张图胜过一千个字。”像大多数古语一样,这句话蕴涵了许多真理。人类通过可视的表示可以更容易地理解一些类型的信息。举例来说,通过阅读代码来了解大型软件系统的依赖关系几乎是不可能的,观看那些依赖关系的可视化显示会令理解更容易。然而,可视化不总是必要或有帮助。举例来说,纯顺序的代码的可视化显示可能不会比文本表示更容易理解。

普遍的误解是可视化会自动地提高抽象层次。这未必如此 —— 尽管可视化的显示常常用于在较高抽象层此上进行的工作。在不提高抽象层次的情况下,工具可能自动地生成表示实体的可视化显示,也许甚至是在您同时在较高层次上工作的时候。

文档驱动开发的缺点

传统的软件开发实践从根本上是文档驱动且以代码为中心的:编制规范的工作主要包括书写(并绘制)许多不同类型的文档,其中许多包含冗余的信息。实现是通过手工书写代码来进行的。

即使将所有的文档和代码都置于配置管理之下,此方法也可能导致重大且基本的问题:

  • 与一个参数相关的信息存储在许多地方,文档与文档之间的信息是不一致的。
  • 代码与规范产生差异,最终使规范过时。
  • 查找信息是艰难的,特别是如果工具支持是受限的。
  • 将抽象的信息转换为更详细的数据的过程是手工的,并且因此是不可靠且效率低的。
  • 信息要素之间的可追溯性是受限的,或不存在的。
  • 跨团队交流的能力受到自然语言的多义性的限制。

第一个问题特别麻烦。举例来说,对于协议或数据类型定义(举例来说,接口)来说,在早期的规范阶段定义,并存储在许多不同类型的规范文档中不是稀有的事情。后来,该协议或数据类型还将存储在代码中。如果协议或数据类型发生变更 —— 举例来说,如果添加了元素 —— 那么您必须找到记录了该数据类型的所有不同的文档,并进行变更。在大多数情况下,在所有的规范文档中确定所有这些实例的唯一方法是进行本文搜索,并在所有相关文档中进行替换。这很少像听起来那样平常。

另一个问题是自然语言常常非常不明确。对文本存储的信息的解释人人不同,误解是普遍存在的。许多组织通过许多连续的步骤手工地将文本的规范转换为设计、实现,和测试案例 —— 从系统级规范到子系统规范,到设计规范,最终到实现。这个过程需要大量的人力,并且是冗长、困难,且非常容易出错的。此外,在不同文档中的各个阶段处理的信息元素之间存在逻辑连接或链接,但导航这些链接的工具支持充其量不过是有限的。因此,不一致性的风险,特别是当开发后来的版本或进行维护时,是非常高的。

模型驱动开发的好处

MDD 通过许多方法解决了文档驱动开发中固有的问题。首先,MDD 工具提供了信息数据库,它令信息元素之间的导航更加容易,因为数据库中存储了所有的或大部分信息。此外,该数据库对于每个信息只存储一次,但从不同的上下文中进行引用。如果有一个事实发生了变更 —— 举例来说,当上面讨论的协议或数据类型发生了变更 —— 那么就只在一个地方实现变更。然后,MDD 工具负责将每个文档中该事实的所有实例进行变更。

MDD 包括建模语言的使用。IBM® Rational® 建模工具使用 UML,它是独立、一致的,形式化定义的语言,在开发的所有阶段中都要用到。UML 比自然语言要明确得多,它增强了沟通,并减少了解释错误。

今天,UML 6 还支持上面提到的四个分层类型:结构的、行为的、包,和继承。所有的都是复杂系统开发所必要的。

而且,由于 UML 是可视化的,并且如果适当地运用,在比文本或代码更高的抽象层次上运作7,开发人员就可以更大程度地关注逻辑设计而不是实现问题。这将允许开发人员更着重于生成可靠的架构,它是许多理想的系统能力的关键:可扩展性、可测试性、可维护性,和可理解性。

提高抽象层次

如果软件开发组织想要通过在减少投放市场的时间的同时提高生产力和质量来帮助它们的公司有更大的竞争力,并且满足商业目标,那么最终它们必须在开发中提高抽象层次。这不是新的概念。早期的程序设计利用机器代码指令在裸机层次上完成。然而,即使是进行像两个整数相加,并存储结果这样简单的事情还需要相当多的机器指令,因此在机器层次上进行这种类型的编码就开发人员的生产力而言不是非常有效的。汇编程序大体上是一样的,低层次的抽象,即使记住像 MOV 的助记符号而取代其相应的二进制表示要稍微容易。

为了获得更好的开发人员生产力、更高层次 —— 更抽象的 —— 就发明了程序设计语言。就程序设计人员的生产力而言,语言,例如 FORTRAN、C、Pascal、Ada、 C++,和 Java 比机器码或汇编程序设计高效得多。它们通过提高抽象层次,令程序设计人员比起“如何”更多地关注“做什么”,也就是说,抽象掉了机器层的细节。

然而,它们令开发人员工作于更高的抽象层次上,并用更短的时间指定更多的机器指令的事实不足以解释出高级语言的巨大成功。实际上,它们的成功源于一些因素的组合:它们都提高了抽象层次,并且将从较高到较低层次的信息表示的转换自动化。编译器和汇编程序自动地将表示一直向下翻译为有效的机器代码。没有此能力,就没办法使高级程序设计语言如此成功。设想,用您喜欢的高级语言指定一些像冒泡排序算法那样简单的东西,然后在没有编译器的帮助下,手工地用机器码实现是多么的不可能。

缺少了这个自动的翻译能力,MDD 就不能交付其全部的潜能了。即使您可以提高抽象层次并改进信息一致性和团队交流,您也仍旧需要自动的翻译能力来完成革命的改进。

图 1 例举了这一点。右边是硬件 —— 执行代码的计算机。它不关心您如何生成这些零一指令,您是否书写了机器码、汇编程序,或 Java,您是否手工或自动地进行翻译。它只关心这些零一指令是否与其指令集和地址空间一致。

然而,对于我们人类,该信息是要紧的,特别是如果考虑到我们的生产力 —— 单位时间内我们能处理这些零一指令的数量。基本上在汇编和机器指令之间存在一对一的映射。移动到更高的抽象层次和语言上时,该映射成为一对多,由设计层构造所生成的机器指令的数量快速的增加。缺少了自动的转换,将我们的高级语言翻译成机器关心的零一编码的能力,我们的生产力将不会提高。

自动的翻译还需要关于领域和平台的外部的,或预定义的知识,它保存在模型之外。该知识不应该由程序设计人员定义 8 而是由翻译工具基础结构提供。然后,程序设计人员可以暗地里引用或使用该知识 —— 或有时候甚至是明确地。

回到 MDD,我们可以明确地看到它提高了抽象层次,但自动的翻译怎么样?如我们所看到的,很少有组织实际地以包含此重大要素的方式实践 MDD。

图 1

图 1

图 1:更大的生产力需要更高的抽象层次和自动的翻译。Graphic courtesy of Anders Hallberg。

当前实践中的建模方法

现今大多数组织使用的建模方法属于下面三种非正式定义的类别之一:

  • 白板草图
  • 用 PowerPoint 的 UML
  • 可任意处理的 UML

这三种方法都没有发挥 MDD 范型的完全的力量。虽然它们提供了一些增加的好处,例如增强的项目交流,但是它们不能提供生产力、质量,或投放市场时间方面的巨大突破。

白板草图

此方法非常不正式地,且以特别的方式使用 UML,主要在早期的分析和设计中。它应用于探究问题领域,并开发最初的高层架构和设计。这些建模活动的输出一般不永久存储在任何意识到语法或语义的工具,相反,典型的存储介质是纸、数字照片,或者甚至只是参与者脑中的记忆记录。

一些敏捷方法的支持者为了快速地获得高层次问题的公共的理解而喜欢这种类型的建模。有了该理解,它们可以快速地转移到以代码为中心的开发上。此“捷径”的目的是去除所有非必要的工件 —— 换句话说,不立即为生成代码或测试案例的最终目标做出贡献的工件。意图是最小化必须维护的工件的数量。

用 PowerPoint 的 UML

此方法表现出建模中的下一个精确级别。利用 PowerPoint 或绘图工具获取并存储建模活动输出。然后团队从幻灯片上剪切并粘贴图形,创建正式的项目文档,包括需求规范。

可任意处理的 UML

沿着建模精确等级更进一步,此方法更严格地定义,并且需要组织中对 UML 更大程度的了解。它要求能够理解 UML 语法和语义的工具用于建模工作流中,并且模型在工具中永久保存。此方法的典型工作流围绕着分析和设计,将代码留待手工编写。一些组织还利用某些正向工程的技术 —— 换句话说,该工具能够根据模型及其元素进行部分的代码生成 9 —— 进行高层次的实现。

不幸的是,现今大多数自称进行真正的 MDD 的组织实际上追求的是上面介绍的局部方法之一。许多组织在成为 MDD 学者方面进行了实质的投资。它们修改它们的开发过程 —— 特别是它们的分析、设计,和 CM 工作流 —— 以更好地支持 MDD。它们引入了工具支持,并且将它们所有的开发人员送到 OOA/OOD,UML 和建模培训及工作间。然而,不管它们在现代技术和方法上进行的什么投资,相当多的组织仍旧挣扎于它们的生产力、质量,和投放市场的时间的数字。大多数组织不能展示出任何由在 MDD 中的投资所引起的重大改进,而它们整个的性能仍旧像它们在使用较传统的方法时一样。

这导致许多人质疑模型驱动开发的价值,并且询问模型是否真的是令组织更好地执行的资产。虽然当转向 MDD 时它们有很高的期望,但是现在许多组织怀疑,MDD 是否只是具有有限的,并且逐渐减少的价值的昂贵试验。

但真正的问题是,为什么这些组织满足于如此低层次地采用 MDD?为什么不全面采用 MDD,这将真正影响生产力、质量,和投放市场的时间?

对于 MDD 的行业阻力

以下介绍了一些为什么 MDD 没有比实际应该占的那么多优势的原因:

  • 从历史上,模型用于次要的工件,生成了维护负担。
  • 除了对特殊领域,能够完成代码生成的工具还不可用。因此,许多组织只是部分地将由模型的代码生成自动化。
  • 普遍的误解是所生成的代码必定是效率低的。
  • 与将组织从传统的,以建立的工作方式转移到新的上面相关的预先成本常常被视为禁止的。
  • 对变更的惰性、恐惧,和阻抗在开发团体中猖獗。10
  • 较上层的管理缺乏关于现代方法的知识和经验,并因此不支持向 MDD 的转移。
  • 在团队环境中很少有真正强大,但容易使用的,支持 MDD 的工具。

我们将在下面更详细地探讨每个原因。

将模型作为次要的工件

上面介绍的用 PowerPoint 的 UML 和可任意处理的 UML 的方法遭遇类似的问题:没人将模型及其工件作为主要的部分。这些包括没有直接 参与或连接到代码或测试案例的生成的开发工件 —— 一些最后在某个硬件上编译并执行的东西。这样的工件被视为次要的,因此成为未来维护的负担。

团队的当前过程可能规定必须将初始的分析模型小心地细化(更详细的)成设计模型,随后必须将它细化为包含用于实现的更多细节。此细化可以用手工完成,或利用部分的(或全面构建的)正向工程技术完成。然而,除非维护一个非常严格的规程,否则不久将出现模型和代码之间的缺口,或断路。而当缺口出现时,除了必要的代码更新之外,很少组织有时间,或动机进行模型维护。由于代码是最终将要交付的具体功能,所以这是焦点所在。最终,随着代码和模型的越来越多的分歧,模型将过时,并且代码将成为规范和实现。

在不通过自动的工具将结果的工件直接连接到代码上的情况下,利用 UML 分析和实际规范是否在用于沟通和文档的稍微更严格的且高级的语言之上添加任意内容也是可疑的。团队可能将基于 UML 的工件看作另一种形式的传统且自由浮动的规范文档。

MDD 的这个方法类似于 80 年代的伪码设计实践。虽然设计是在较高的抽象层次上完成的,并且比“怎样做”指定了更多“做什么”,但是真正的实现仍不得不手工地由伪码进行翻译。

为了让 MDD 成为真正的生产力增加器,组织需要将它们的 UML 模型作为源和应用。换句话说,模型应该包含自动生成完整的可执行程序所需的所有东西。11 这暗示,用于真正的 MDD 的工具必须能够完成代码生成。我们可以利用代码生成机制自动地由模型 —— 没有人工干预的情况下 —— 生成完整的、可执行的二进制程序,我们可以希望通过这些模型来获得更大的收益。

许多建模工具只支持部分的代码生成(非可执行的模型)

虽然许多使用建模方法的组织进行自动化的代码生成,但是在大多数情况下,它只是部分的代码生成,一般使用正向的工程技术。部分的代码生成大大地帮助了代码和模型之间分歧增加的风险。很少组织拥有规程来确保修正模型以反应所有的编码变更。只要将模型翻译为实现代码的过程仍然主要是手工的,那么 MDD 将不能按照其诺言实现。

开发人员将所生成的代码视为效率低的

许多实践者,特别是在嵌入式实时系统领域中,相信由建模工具自动生成的代码没有可接受的运行时执行特性,包括相当好的性能和内存覆盖区。虽然这在过去可能是真的,但现代的代码生成器 —— 特别是那些全面可定制的 —— 可以生成执行得像手写的 C++ 或 Java 那样好的代码。

这些异议类似于三十年前实践者提出的那些,那时由于对性能的关心,抵制使用高级程序设计语言。从那以后,编译器在生成高效机器码时非常有效,如今,除了用于控制硬件的较小的低级代码,几乎没有项目团队会认真地考虑使用汇编程序或机器码。

是时候让开发人员采用关于 MDD 代码生成的类似姿态了。当今有效的模型到代码的生成器可以完全地实现甚至是困难的实时系统,对此来说,错过的最终期限是不可接受的。举例来说,一些使用全面的 MDD,以及完全的代码生成的组织已经成功地开发了具有非常严格的实时需求的导弹控制系统。

变更方法的预先成本似乎是禁止的

任何对已建立的实践的主要变更将拥有预先成本。从传统的、基于文档的规范和以代码为中心的开发转移到 MDD 上将需要在工具、培训,和外部顾问方面的巨大投资。此外,进行这种转换的组织必须习惯崭新的工作方式,因此,最初生产力可能减少。很少有组织愿意接受这种下降,除非它们可以确信这只是临时的 —— 并且整体效率中的重大改进只是开小差。

许多开发人员抵制变更

对于开发人员来说,目前的主流工作方式基本上由文档驱动的规范组成,12 结合用高级语言,例如 C/C++ 或 Java 进行手工编码,以及可能的部分代码生成。此方法需要高级的设计和程序设计语言专家经验。许多技术人员(举例来说,设计人员,程序设计人员)根据此方法,通过成为实现专家来构建其职业生涯。MDD 似乎威胁到它们的崇高地位,因为它需要不同的技能。

MDD 可能还扰乱了负责系统分析和设计的技术人员的舒适区。对于此作用,引入 MDD 的主要新奇与挑战源于在分析和设计中,它对更大程度的一致性和形式主义的要求,MDD 比传统的文档方法的规范更早且更清晰地揭露出不一致性。它还要求对规范语言的更严格的使用。

上层管理层不了解或支持现代方法

向 MDD(或任何其他根本上不同的开发范型)转移需要大量的初始投资,并且不是没有风险的。如我们提到的,这种转移将很可能导致临时的生产力下降,并且事先证明 MDD 将真的赢利是非常困难的 —— 确实,“证据在布丁中(the proof is in the pudding)”。很少有项目经理愿意通过从事于危险的活动而危及他们的职业生涯,除非他们完全相信可以减少风险并且赢利将是丰富的。

不幸的是,现今大部分上层管理人员都拥有有限的,或不符合实际的 MDD 经验。13 如果他们有相关的技术经验,那么最可能的是关于使用传统的文档驱动及以代码为中心的工作方式的项目。对于大多数管理人员来说,MDD 是一个巨大的未知数,并且有许多潜在的风险和不确定的利益。

缺少“武器级的”并行团队开发工具

即使用于 MDD 的工具已经出现了许多年了,但是大多数都缺乏对细粒度团队开发的足够支持,令高度并行的开发非常笨重。对于那些具有相对少的各种模型工件的活动版本项目来说,目前的工具可能为团队开发提供了充足的支持。然而,十分之一 —— 或也许是百分之一 —— 的并行工作的项目版本必须采用非最佳的过程,因为工具的缺乏。特别的是,图形的差异/合并工具中需要改进。

将 MDD 带到下一个层次

我们如何克服上面详细介绍的问题,并且实现 MDD 更广泛的行业应用?这里有一些建议。

对于更多领域的完全可执行的模型

如上面所讨论的,传统的、高级程序设计语言,例如 C、C++,和 Java 的成功源于两个因素。首先,它们提高了抽象层次,因而比起“怎样做”,它们令开发人员更着重于“做什么”。它们忽视与程序设计无关的硬件架构和其他低层次的关注。其次,这些语言不用手工地翻译成机器码。相反,翻译过程由例如汇编程序、编译器,和连接器的工具完全的自动化了。为了让 MDD 在开发生产力方面达到相应的提高,它必须结合相同级别的自动化,模型必须是可自动地翻译为可执行代码的。

对于一些领域 —— 例如事件驱动的实时系统,和某种程度上的 GUI 构建器和 J2EE —— 这种真正的 MDD 已经存在。我们早先提到的令人印象深刻的生产力提高源于其模型可以自动地生成全面的可执行的应用程序的系统。在这种情况下,基本上,模型是应用程序。为了让 MDD 像传统的高级程序设计语言那样的流行和成功,这种全面可执行的 14 模型必须要在更多领域中可用。

具有定制的代码生成能力的摆脱实现的模型

不幸的是,在现今可用的大多数建模工具中,代码生成模式一般是硬连接到工具中的,并且提供对要生成的目标代码的定制的非常有限的支持。这特别应用于模型中的操作语句 —— 也就是说,开发人员写入特定模型元素中,用于指定具体行为的代码段。

这种对定制的受限支持导致了许多问题:首先,所生成代码的执行时间特性 15 可能不总是最优的。其次,模型可能比必要更早地成为具体到平台的。很明显,在一些点,模型必须包含关于底层平台的所有必要的细节。然而,为了实现可移植性和可扩展性,理论上我们想要推迟到开发的非常晚的阶段在加入那些细节。此外,我们想要完全地从逻辑模型分析出那些实现细节,并且在代码生成过程中将它们这些细节作为参数“粘贴进来”。将逻辑模型尽可能地摆脱低层细节 —— 本质上是“摆脱实现” —— 是令人想要的。这是处理开发大规模系统中固有的典型压力和问题的有效且高效的方法,那些系统的应用程序常常比它们的执行平台存在的长得多。

由逻辑模型分析出实现细节可以通过“标记及映射”机制来实现,该机制允许设计人员将个别的模型元素标记并映射为负责生成目标代码的具体的模型转换。为了实现对于各种不同的目标平台的最优的目标执行特性,这些转换将是完全可定制的。这也会是操作代码的需求 —— 手工书写成用于指定行为的模型的片段 —— 为了满足可扩展性、可移植性,和目标执行效率需求。

培训实践者关于敏捷开发和 MDD 的内容

Agile Manifesto(参见 http://www.agilemanifesto.org/)说,根据参数选择,以下原则:

过程和工具上的 Individuals and interactions(个体和交互)
复杂文档上的 Working software(工作软件)
合同协商上的 Customer collaboration(客户协作)
在依据计划上的 Responding to change(对变更的响应)

一些实践者相信,敏捷的方法与 MDD 不相容,因为它们认为敏捷性翻译为“尽可能快地跳跃编码”。事实上,敏捷性和 MDD —— 如果恰当使用 —— 是非常兼容的。敏捷的方法提倡去除所有对于为了在某个目标上执行而快速地生成质量代码不是绝对必要的工件。全面的 MDD,包括正式的,基于模型的代码生成,结合了这个“less is more” 范型。在那些“模型是代码”所在的实例中,所有实践者不得不做的是确保他们拥有精确给定的模型。然而,他们可以依赖 MDD 工具来生成可靠的代码,并且在不关注综合的文档的情况下,快速地从事软件的工作。

对于系统工程的 MDD 支持

如果 MDD 要获得广泛的使用,那么系统工程领域 16 会得到一些最大的好处。由于大多数当今的系统工程都是基于文档的,所以它遭受着前面提到的不一致性和误解。利用 MDD 可以在使您能够进行系统的逻辑高层次功能的更精确的规范和测试的同时,大大地减少这些问题。有了适当的工具支持,设计人员可以在高层的系统模型上进行执行或模拟,并调试,从而在早期确认并验证系统逻辑。它们还可以模拟通信负载,从而发现在负载平衡、错误处理,等等过程中会发生什么。

此外,适当的 MDD 工具支持提供了来自不同层次的模型的工件和模型元素之间的纵向集成和可溯性。在目前的工具中,这些链接必须手工地定义,但 IBM Research 正在开发能够通过各种信息槽“爬行和蠕动”来确定并分类不同类型信息元素之间关系的智能链接。希望未来的工具能够(半)自动地确定关系,并定义它们之间的可导航的链接。

结束语

虽然当今许多系统的数量级比十年前的那些要复杂,但是大多数组织仍旧使用适合那些较老系统的开发实践。许多已经不能够实现生产力、质量,和投放市场时间方面的提高,尽管它们利用了结合其他现代技术,例如迭代开发和面向对象设计,的建模。这种失败大部分源于它们对这些现代开发技术的非最佳的应用。特别是,大多数仍旧工作于效率低且容易出错的文档驱动的开发范型中。

在本文中,我试图展示出许多声称“MDD 无效”的组织在以次优的方式使用模型和建模。这些组织已经不能实现它们在这些现代的最佳实践中进行的重大投资的良好回报,因为它们没有将完全结构的、可执行的模型作为主要工件。这样的模型结合了敏捷的思想。在整个生命周期的工件中,它们是完全连接且可追溯的,包括需求、测试案例,和代码。

为每个领域提供完全结构的建模能力对于像 IBM Rational 这样的公司来说是一个机会。但 MDD 的有效采用还需要变化许多软件开发组织中的范型,在这些组织中,文档驱动的开发仍旧占优势,并且不赞许敏捷的原则和方法。最终,这些组织中的管理人员的职责是更好地了解 MDD 实际上是什么,它可以为他们做什么,以及如何正确地进行。

致谢

本文中表达的思想、观点,和意见完全是我的,并且没必要反映或赞同任何其他个人或组织的观点。我根据我在作为不同技术市场(从航天和国防到电信)中的许多不同组织 —— 包括市场领导者 —— 的顾问、培训师,和技术附属(attaché) 17 的几乎二十年的工作经验得来的这些观点。所有这些组织都开发系统,大部分是涉及成百个开发人员的大型系统,以及复杂的产品(它们的主要成分是软件)。

尽管上面提到了否认说明,我还想要提到一些个人,没有特别的顺序,他们帮助形成了我的观点:

  • Branislav Selic,杰出的工程师,IBM Rational
  • Anders Hallberg,技术主管,RAH Systems Design
  • Per-Arne Gussander,技术经理,ECAT,IBM Rational
  • Fredrik Ferm,策略团队领导,ECAT,IBM Rational
  • Nils Kronqvist,高级软件工程师,ECAT,IBM Rational
  • Mikael Vester,技术销售经理,ECAT,IBM Rational

注释

1 这些数字是非常保守的。

2“全面的(Full-scale)” MDD 指的是(尤其)来自“可执行模型”的完整的代码生成。它的意思是,不仅应用程序的结构部分,还有应用程序的行为方面都是由模型自动生成的。

3 这些可执行的 UML 航路的基准点是已经利用全面的 MDD 及完全可执行的模型的系统 —— 也就是,MDD 的非常先进的形式。

4 依照 Wikipedia,它实际上是创造此表达的马其顿王国菲利普二世(382-336 BC)。

5 IBM Rational Rose® RealTime 从它的第一个版本开始就已经支持明确的结构分层。

6 UML2(以及 UML-RT)支持结构化的类和结构分层,此支持是处理大型系统时的基础。

7 我曾表明过,UML 设计或实现类 —— 与分析或领域类相反 —— 在比相应的 C++ 或 Java 代码更高的抽象层次上不是必要的。具有实现类的类图不是必定提高抽象层次。达到更高的抽象层次要求您能够在不牺牲一致性的情况下推迟较低层次的细节的规范。完全的自动化,“完全结构的”代码生成确实提高抽象层次,因为代码生成器及其框架能够填充细节。

8 然而,对于用户来说,全面地定制提出的信息一定是可能的 —— 举例来说,修改转换和代码生成模式。

9 典型的正向工程生成“框架”或“结构桩”,留下部分结构和大部分行为代码,随后手工编写。

10 声名狼藉的 FUD 因素:恐惧、不确定性、怀疑。

11 包括允许在模型中引用遗留代码的机制。

12 注意,我将上面介绍的三种最普遍的建模方法 —— 白板草图、用 PowerPoint 的 UML,和可任意处理的 UML —— 看作文档驱动的开发方法。它们不是真正形式的 MDD。

13 我足够幸运,可以亲自了解此原则的一些异常 —— 它们确实是罕见的创造物。

14“全面可执行的”意味着许多东西 —— 其中有进行高级逻辑模型(举例来说,系统设计模型)的模拟和调试的能力,以及从设计模型生成有效的目标代码的能力。

15 内存覆盖区,执行效率。

16 在此,我使用的术语,基于模型的系统开发是非常广义的,基本上覆盖了系统分析和设计工作流。

17 我真的不知道描述我在 ECAT 中当前角色的确定名称。技术附属é 涵盖了我目前相对于客户所做的工作的大多方面:理解、转化,并计划他们的领域、环境、情况,商业和技术需要,以及需求,形成我的老板可以理解且可消化的形式。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=255730
ArticleTitle=Rational Edge: 模型驱动开发:MDD 模型是资产还是债务?
publish-date=09172007