本文讨论了建模对软件和系统开发的积极影响。本文的阅读对象为与开发过程相关的技术人员和非技术人员。请点击文章顶部或底部的讨论，参与论坛讨论，与其他读者分享您对本文的看法。

摘要
本文讨论了建模对软件和系统开发的积极影响。本文的阅读对象为与开发过程相关的技术人员和非技术人员。

建模是管理软件开发复杂性的有效手段。它能促进需求、构架、软件及系统的交流、设计与评估。尽管有这么多的优点，但是主流的软件开发并未能在日常工作中充分利用建模这项技术。

本白皮书探讨了建模时如何同时提供可视化内容和文本内容，以及这二者结合的重要性。它还解释了如何将建模贯穿于软件开发生命周期中的各个阶段，并且在每一阶段使用哪些建模类型最为合适。尽管统一建模语言（UML）的中心是将建模本身作为一个学科，但是它还是用来表示模型的公共方法。

引言
本白皮书将讨论建模在软件开发过程中的价值。建模的概念并非新鲜出炉，——资深软件专业人士已经有过多年的建模实践。但是在主流软件开发社区中，只有一部分软件开发人员对他们的软件开发进行了建模。本白皮书将考查什么是促进软件建模实践的基础。本白皮书旨在为精通软件建模的人员、一无所知的人员，以及听说过但从未实践过的人员，阐述建模实践所能带来的利益和价值。

什么是建模?
多年以来，业务分析人员、工程师、科学家，以及其他构建复杂结构或系统的专业人员已经为他们所构建的系统创建了模型。有时是物理模型，例如，飞机、房子或者汽车的按一定比例制作的实物大模型，有时候模型并不是那么明确，如商业金融模型、市场贸易模拟以及电子电路图。在所有情况下，模型作为一种抽象——即被构建的真实事物的近似代表。

为什么建模?
为什么在构建某些事物之前首先要建模？或许不需要。简单的事物不需要在创建之前进行建模――例如，一个简单的支票簿签发记录、简单的货币换算工具、一间犬舍或者用于打开一组常规文件的字处理程序中的宏。

这样的项目具有下列全部或大部分特点：

• 问题域很清楚。
• 相对来说易于构建解决方案。
• 需要很少的人进行协作来构建或使用该解决方案（通常只有一个人）。
• 该解决方案需要最少量的持续维护。
• 未来需要的范围不会有实质性的扩大。

但是如果假设这些特点都不具备呢？为什么一些专业人员要费心去创建模型呢？为什么他们不直接构建具体事物呢？答案在于复杂性和风险，并且最初的专业人员并不是一直适合开发任务，甚至根本不能完成任务。

　

建模使架构师及其他人员能够可视化整个系统，评估不同选择，并且更清晰地交流设计，从而避免了技术风险、财务风险或实际的构建风险。

如果不先创建一项设计、一个蓝图或者另一个抽象表示，就直接构建某种复杂系统，在技术上是不明智的、在经济上也是行不通的。尽管专业建筑师无需设计图就可以建造一间犬舍，但是如果他们不首先开发一批计划、图和某种可视化实物模型，那么就不能建造一幢15层的办公大楼。

为什么对软件进行建模?
多年以来，软件开发实践置于建模话题之外。由于其本质属性，软件易于创建和变更。几乎不需要固定设备，并且实际上没有制造成本。这些属性孕育了一种DIY（do-it-yourself）文化――每当需要时才进行构思、构建及变更。总之没有“最终”系统，那么为什么在编写代码之前还要进行构思呢？

今天，软件系统已经变得非常复杂。它们必须与其他系统进行集成，来运行日常生活中用到的对象。例如，汽车现在大规模装备了计算机及相关软件，用来控制从引擎和定速控制到所有新的车载导航和通讯系统的各个方面。软件还经常用于自动处理各种业务流程――诸如客户看见并经历过的那些业务流程，和后台办公的业务流程。

一些软件支持健康有关或财产有关的重要功能，这就使得开发、测试以及维护必定很复杂。甚至那些对健康或者财产不是特别关键的系统对于业务来说却非常关键。在许多组织中，软件开发已经不再是居于成本中心的孤立事物——而成为公司战略性业务流程的一个整体部分。对这些公司来说，软件已经成为市场竞争中一个关键的鉴别标志。

　

在许多组织中，软件开发已经不再是居于成本中心的孤立事物－―而成为公司战略性业务流程的一个整体部分。

由于很多方面的原因，开发者需要更好的理解他们正在构建什么，建模为此提供了有效的方法。同时，建模一定不要影响开发速度。客户和业务用户始终希望软件能够按时交付以及能够像所期望的那样具有随需应变的功效。为了达到这种“速度与质量并重”的目标，IBM 提出了软件开发的四项必要措施：迭代开发、重视构架、持续的质量保证以及管理变更和资产。

其他复杂的高风险系统建模的相同理由同样适用于软件－－管理复杂性并理解设计和相关的风险。尤其是通过软件建模，开发人员能够：

• 在提交额外的资源之前创建并交流软件设计。
• 从设计追溯到需求阶段，有助于确保构建正确的系统。
• 进行迭代开发，在开发中，模型和其他的更高层次的抽象推动了快速而频繁的变更。

为什么一些开发人员不选择软件建模？
尽管建模有许多原因和优点，但是仍然有很大一部分软件开发人员不在源代码更高的层次上进行任何形式的抽象。这是为什么呢？正如前面描述的那样，有时候问题或者解决方案的实际复杂度无需建模。再一次重申，如果您准备建造一间犬舍，您根本就不需要雇佣一个建筑师或者聘请一位建造者来做一系列的设计规格说明。但是在软件世界中，系统经常是开始时简单并且易于理解，在通过一系列成功实施的自然演进，就变得越来越复杂。在其他情况中，开发人员不采用建模的简单理由是没有认识到建模的需要，直到很迟的时候才察觉到建模的必要。

许多人争论，软件建模的阻力更多的是来自文化上的因素而不是其他的。传统的程序员对于通常的编写代码的技术非常擅长。甚至遭遇到不希望的复杂情况的时候，大多数开发人员仍然坚持使用他们的集成开发环境（IDE）和调试工具，以及在问题上花费更多的时间。因为建模需要额外的培训和工具，并且相应地需要额外的时间、财力和工作量上的投资―－不是正式开发工作的时间，而是在项目开发生命周期早期的时间。传统开发人员在这方面不超前的原因在于，他们认为建模将减慢他们的速度。在下一节中将帮助人们消除这种观念。

何时建模?
为复杂的应用程序建模有几项一般获益。在某些特定情况下，建模工作是值得的，这包括：

• 为了更好理解手头上的业务情况或工程情况（“as-is”模型）并且为了设计更好的系统（(“to-be”模型）
• 为了构建和设计系统的构架
• 为了创建可视化代码和其他实施形式

建模不主张全有或全无（all-or-nothing）。模型可以在软件开发过程的很多方面发挥作用。图 1 描述了实践模型驱动开发的方法的使用范围

集成的开发环境
在建模的最自由的概念中，集成开发环境（IDE）可以看作是模型驱动开发实践的入口点。现在的集成开发环境在创建和维护代码方面提供了许多提高抽象层次方面的机制。有许多工具，例如，诸如语言敏感的编辑器、导航器、表单生成器和其他GUI控制，在更严格的术语上讲都不算是模型。但是，它们能够提高源代码之上的抽象层次，提高开发人员的生产率，帮助创建更可靠的代码，以及提供更高效的维护过程。所有的这些属性都是模型驱动开发的本质。

图 1 时间、地点及建模方法的范围图

代码可视化和可视化编辑
基本IDE功能之上的一个功能是以图形的方式对源代码进行可视化处理。在这里，从某个意义上说，一幅图片的功效相当于一千行代码，开发人员已经有过使用代码之上的图形形式抽象的多年经验。传统的流图就是描述代码算法控制流的常见方法。结构图或者甚至简单的带箭头的方块图经常在白板上使用――方框代表函数和子程序，箭头用来表明调用的依赖关系等等。对于面向对象的软件，方框典型的用来描述类，而方框之间的直线描述了这些类之间的关系。

与代码可视化处理联系最密切的是可视化编辑，其中开发人员可以通过图形的方式替代惯用的 IDE 文本窗口来编辑代码。可视化编辑很适合那些对其他代码有系统性影响的变更。例如，在一个面向对象的系统中，该系统有与继承体系有关的一组类，类的某些特性（域成员、方法或者函数）或许随着应用程序的进行需要重新组织到不同的类中（该过程称为重构）。使用通常的代码编辑器制定这样的变更可能很乏味并且很容易出错。但是一个有效的可视化编辑器就会允许开发人员将成员函数从一个类中拖放到它的基类中，并且自动调整这种变更所影响的所有代码。

从某种意义上说，代码可视化和可视化编辑是简单的查看和编辑代码的替代方法。代码所做的变更会立即反映到与其相关联的图中，反之亦然。尽管一些人可能争论说这些描述不能构成“模型”，建模的本质是抽象，并且任何代码的可视化确实也是一种抽象－－有选择的揭示一些信息同时隐藏一些不必要的和不需要的细节。许多从业人员更愿意使用诸如代码模型，实施模型或特定平台模型（platform-specific model，PSM）来限定这些抽象，而不使用与代码无直接关系的其他建模的更高层次的抽象形式。

建模和双向工程
建模范围的下一步代表了传统模型驱动开发的状态。此处，可视化的模型从方法过程中创建，该方法以需求开始并且延伸到高层构架的设计模型中。然后开发人员创建详细的设计模型，从该模型中骨架生成 IDE。ID E完成详细的编码。任何影响设计模型的对代码所做的变更都会同步的返回给模型；任何模型所作的变更也同步地进入已存在的代码中。

遗留系统集成
当开发人员准备集成系统时，无论是遗留系统还是新系统，他们必须首先正确的理解这些系统，知道业务如何与这些系统协同工作，并且为这些集成划分优先级。对遗留系统进行建模并不意味着要将整个系统或者它的所有的组件都包括进去；但是，开发人员应该理解遗留系统的构架，它们如何工作以及它们如何同其他系统进行交互。理解系统行为及其他的软件对该系统的依赖情况将有助于确定下一个步骤。

为遗留系统建模有很多方法。开发人员可以使用反向工程将代码放到模型中来理解它们，还可以手工建模或者两者结合起来使用。

快速应用程序开发（RAD）
快速应用程序开发（RAD）早在 80 年代就问世了。其宗旨是简单地提供生成代码和维护代码的高生产率的方法。RAD 是通过易于使用的、高级 IDE 的图形性能来实现的。RAD 和以代码为中心的开发已及模型驱动开发不同，它提高了代码之上抽象的层次，但是它本身并没有使用“模型”。

业务建模与模型执行
在了解开发软件的需要之前，业务和工程分析员经常发现创建系统如何工作的“as-is”模型大有作用。从该模型中，他们能够分析哪些发挥了作用，哪些还有待于改进。特殊用途的工具能够通过几种关键变量（如时间，成本以及资源）来模拟这些模型。从分析中，可以创建“to-be”模型来描述新的、经过改善的过程是如何工作的。一般说来，实现新的过程需要新的软件开发，并且“to-be”模型是保证开发的关键动力。

对某些应用领域来说，“to-be”模型经过严格限定，以至于可以从模型生成完整的应用程序。 在这种抽象层次上建模的能力提供了两方面的最大潜力，一方面是生产率，另一方面是业务或工程问题域和技术或实现域之间的集成。

如何建模?

　

采用标准的表示法（例如 UML），是将模型驱动方法引入软件开发中的一个重要步骤

软件行业采用统一建模语言（Unified Modeling Language）作为表示模型和相关产品的标准方法。软件构架师，设计人员以及开发人员在指定、可视化、构建和文档化软件系统的各个方面使用 UML。来自 IBM Rational 的主要领导者引领了最初 UML 的发展。今天，UML 由对象管理组织（Object Management Group ，OMG)管理，该组织由来自全世界的代表组成，确保它的规格说明能够不断满足软件社区的动态需要。采用标准的表示法，例如 UML，是将模型驱动方法引入软件开发中的一个重要步骤。

UML不仅仅是一个图形化的表示法标准――它是一种建模语言。同所有语言一样，UML定义了语法（包括图形和文本）和语义（符号和文本的根本含意）。将UML作为一种真正的建模语言而不仅仅是标准的表示法，对于两个方面来说都很重要，一方面是标准化UML的使用，另一方面是确保自动化工具能够正确实施符号背后的规则。UML是一种真正的建模语言――已经成为软件行业最公认的及最广泛使用的建模标准。

人们如何评价建模的价值
与其他技术一样，UML 有早期的使用者，他们领导并发现了它的价值。这里只是一些 IBM Rational® 客户的一些评论，关于建模在他们业务中所起的作用：

“我们一直试图减少我们成员的保险的总体成本。方法之一就是重用贯穿我们业务建模过程中创建的信息和资产。从业务建模的前景来说，模型驱动的构架实际上处在我们工作的核心。当我们从软件开发规划开始项目的时候，我们将发现，如果没有明确的业务模型，没有一系列清晰的业务目标，就无法满足用户需要。”
— Sue Nelson, Blue Cross and Blue Shield of Florida 的业务建模负责人

“我认为可视化建模是任何开发人员工具箱中一个关键要素。它能为我们带来专门的专业知识，例如产品的安全分析。通过使用任何人都能读懂的、通用的建模技术，可以充当我们企业的安全专家，相关人员能够非常容易地检查产品并且指出任何潜在漏洞。”
— Nanette Brown, Pitney Bowes 的应用构架及质量保障负责人

“企业的构架带给我们与众不同的建模挑战。您在不同层次上进行建模。和大量的人以及不同的团队一起建模。并且不同层次上的模型需要为每个单独的涉众定制。【使用 UML 进行建模】为我们提供了灵活性【来满足】企业构架不同层次上的、独特的需要和要求”
— Frank Armour, ArmourIT, LLC 主席

以上这些观点表明，其他刚开始建模的人们能够降低风险，并且最终使建模更靠近软件开发的主流。

趋势和未来
如果您问一下软件开发专家，“软件行业向何处发展？”您可能得到大量不同的回答。但是有一个趋势是相当一致的：

软件开发的复杂性继续增长，并且开发人员必须工作在一个更高的层次上来处理这种复杂性。

无论是现在还是将来，为软件建模都是开发人员在更高的层次上工作的主要方法。当前下面的这些特定趋势值得关注。

超越可视化建模
UML 传统上是与描述软件工件的图形化方法联系在一起的。尽管现在仍维持这一特点，但是，建模“under the hood”方面变得越来越重要。元建模（Meta-modeling）是对“模型的模型”的描述。元建模技术最明显、最实际的应用可以参考 UML 版本 2，它形成了关于自动化工具如何共享数据以及相互之间互相操作的基础。这不仅可以应用在建模工具上，还可以应用在需求管理工具、编译器、测试、配置管理以及软件开发生命周期的其他方面。所有这些方面由于元模型（meta-model）的公共含义而变得更加完整，例如 UML 2 提供的与其相关的建模标准。

　

随着业务建模变得更加标准化并且同数据、软件的集成度越来越高，一种模型驱动的业务集成学科可能将要崭露头脚

统一软件、数据和业务建模
本白皮书重点主要集中在建模软件的价值。但是在实践中数据建模和业务建模以某种形式使用的时间更长一些。问题是这些类型的建模传统上在建模语言和开发人员文化上属于完全不同的世界。现在统一这三个世界的可能变得明显了－－没有必要成为一种简单的建模语言或者工具，但是可以使用一种多样的、集中的开放行业标准的组合。

贯穿生命周期的建模
随者标准的不断演进，建模将应用到贯穿整个软件开发生命周期的活动的更广阔的范围。建模的应用程序已经在项目生命周期中更早地驱动测试和其他的质量保证方面。并且由于业务建模变得更加标准化并且同数据、软件的集成度越来越高，一种模型驱动的业务集成学科可能将要崭露头脚。

特定领域的建模语言
UML 和其他的建模语言令开发人员能够将注意力集中到实施细节之上的抽象层次上。正如早在图 1 中描述的那样，建模包含的层次范围很广，甚至当我们离开实际的代码也是一样。对于抽象的最高层次，业务模型或域模型并不集中于软件，而是正在考虑的问题的本质。在这里，模型应该使用特定的业务和应用领域中人们和系统所熟悉的术语和图标。

软件行业正朝向领域特定、语言目的特定的建模语言方向发展，这样的建模语言专用于它们使用的各自领域。然而更通常的情况是，一般目的建模语言，特别是 UML，以标准的方法进行了扩展，通过诸如 profile 方面的革新来满足特定领域建模的需要。这两种方法和一般的建模价值一致：以更有效及高效的方式为特定问题和解决方案提供抽象。

软件开发业务
许多人将软件开发称为“团队运动”。伴随的一个陈述是“国际团队运动”。借助于当今的技术，软件开发已经摆脱了地理上的束缚。软件开发业务将变得越来越分布化和全球化。建模和其他更高形式的抽象对帮助开发人员处理相关的复杂性来说具有决定作用。

模型驱动的构架（Model-Driven Architecture ，MDA)
下一步的计划是由对象管理组织（Object Management Group）领导的 MDA。当还处在早期的试用阶段时，MDA 就被认为是建模和模型驱动开发技术演进的下一个逻辑步骤。MDA 基于 UML 和其他相关的标准，主要关注的是在抽象的不同层次上定义模型，和在不同层次之间的定义转换。自动工具支持对于 MDA 的发展及成功应用来说具有决定意义。