本节书摘来自异步社区《UML用户指南（第2版.修订版）》一书中的第1章1.1节建模的重要性，作者【美】Grady Booch , James Rumbaugh , Ivar Jacobson，更多章节内容可以访问云栖社区“异步社区”公众号查看。

第一部分 入门
UML用户指南（第2版.修订版）

第1章　为什么要建模
UML用户指南（第2版.修订版）
本章内容

建模的重要性
建模的4项原理
软件系统的基本蓝图
面向对象建模
成功的软件组织应该总是能够交付满足其用户需要的软件。如果一个软件组织能够及时并可预测地开发出这样的软件，并能够有效地利用人力和物力资源，那么这个软件组织就是可持续发展的。

在上段话里有一个重要的含义：一个开发队伍的主要产品不应该是一堆漂亮的文档、世界级的会议、伟大的口号或者几行获得普利策奖金的源代码，而应该是满足不断发展的用户及其业务需要的优秀软件。其他的一切事情都是次要的。

不幸的是，很多软件组织把“次要的”和“不重要的”的含义搞混了。为了得到满足预期功能的软件，必须到用户中去，以一种训练有素的方式访问用户，去揭示系统的真实需求。为了开发出具有持久质量的软件，必须打好能适应变化的、坚实的体系结构基础。为了能快速、有效地开发软件，尽量减少软件废品和重复工作，必须有合适的人员和合适的工具以及合适的工作重点。为了能一贯地、可预测地做到这些，并使得在整个系统的生命期内花费合理，必须有一个能适应业务和技术变化的合理的开发过程。

建模是开发优秀软件的所有活动中的核心部分，其目的是为了把想要得到的系统结构和行为沟通起来，为了对系统的体系结构进行可视化和控制，为了更好地理解正在构造的系统，并经常揭示简化和复用的机会，同时也是为了管理风险。

1.1　建模的重要性
UML用户指南（第2版.修订版）
如果想搭一个狗窝，备好木料、钉子和一些基本工具（如锤子、锯和卷尺）之后，就可以开始工作了。从制订一点初步计划到完成一个满足适当功能的狗窝，可能不用别人帮助，在几个小时内就能够实现。只要狗窝够大且不太漏水，狗就可以安居。如果未能达到希望的效果，返工总是可以的，无非是让狗受点委屈。

如果想为家庭建造一所房子，备好木料、钉子和一些基本工具之后，也能开始工作，但这将需要较长的时间，并且家庭对于房子的需求肯定比狗对于狗窝的需求要多。在这种情况下，除非曾经多次建造过房子，否则就需要事先制定出一些详细的计划，再开始动工，才能够成功。至少应该绘制一些表明房子是什么样子的简图。如果想建造一所能满足家庭的需要并符合当地建筑规范的合格房屋，就需要画一些建筑图，以便能想清楚房间的使用目的以及照明、取暖和水管装置的实际细节问题。做出这些计划后，就能对这项工作所需的时间和物料做出合理的估计。尽管自己也可能建造出这样的房屋，但若有其他人协作，并将工程中的许多关键部分转包出去或购买预制的材料，效率就会高得多。只要按计划行事，不超出时间和财务的预算，家庭多半会对这新房感到满意。如果不制定计划，新房就不会完全令人满意。因此，最好在早期就制定计划，并谨慎地处理好所发生的变化。

如果你要建造一座高层办公大厦，若还是先备好木料、钉子和一些基本工具就开始工作，那将是非常愚蠢的。因为你所使用的资金可能是别人的，他们会对建筑物的规模、形状和风格做出要求。同时，他们经常会改变想法，甚至是在工程已经开工之后。由于失败的代价太高了，因此必须要做详尽的计划。负责建筑物设计和施工的是一个庞大的组织机构，你只是其中的一部分。这个组织将需要各种各样的设计图和模型，以供各方相互沟通。只要得到了合适的人员和工具，并对把建筑概念转换为实际建筑的过程进行积极的管理，将会建成这座满足使用要求的大厦。如果想继续从事建筑工作，那么一定要在使用要求和实际的建筑技术之间做好平衡，并且处理好建筑团队成员们的休息问题，既不能把他们置于风险之中，也不能驱使他们过分辛苦地工作以至于精疲力尽。

奇怪的是，很多软件开发组织开始想建造一座大厦式的软件，而在动手处理时却好像他们正在仓促地造一个狗窝。

有时你是幸运的。如果在恰当的时间有足够的合适人员，并且其他一切事情都很如意，你的团队有可能（仅是可能）推出一个令用户眼花缭乱的软件产品。然而，一般的情况下，不可能所有人员都合适（合适的人员经常供不应求），时间并不总是恰当的（昨天总是更好），其他的事情也并不尽如人意（常常由不得自己）。现在对软件开发的要求正在日益增加，而开发团队却还是经常单纯地依靠他们唯一真正知道如何做好的一件事——编写程序代码。英雄式的编程工作成为这一行业的传奇，人们似乎经常认为更努力地工作是面对开发中出现的各种危机的正常反应。然而，这未必能产生正确的程序代码，而且一些项目是非常巨大的，无论怎样延长工作时间，也不足以完成所需的工作。

如果真正想建造一个相当于房子或大厦类的软件系统，问题可不是仅仅编写许多软件。事实上，关键是要编出正确的软件，并考虑如何少写软件。要生产合格的软件就要有一套关于体系结构、过程和工具的规范。即使如此，很多项目开始看起来像狗窝，但随后发展得像大厦，原因很简单，它们是自己成就的牺牲品。如果对体系结构、过程或工具的规范没有作任何考虑，总有一天狗窝会膨胀成大厦，并会由于其自身的重量而倒塌。狗窝的倒塌可能使你的狗恼怒；同理，不成功的大厦则将对大厦的租户造成严重的影响。

不成功的软件项目失败的原因各不相同，而所有成功的项目在很多方面都是相似的。成功的软件组织有很多成功的因素，其中共同的一点就是对建模的采用。

建模是一项经过检验并被广为接受的工程技术。建立房屋和大厦的建筑模型，能帮助用户得到实际建筑物的印象，甚至可以建立数学模型来分析大风或地震对建筑物造成的影响。

建模不只适用于建筑业。如果不首先构造模型（从计算机模型到物理风洞模型，再到与实物大小一样的原型），就装配新型的飞机或汽车，那简直是难以想象的。新型的电气设备（从微处理器到电话交换系统）需要一定程度的建模，以便更好地理解系统并与他人交流思想。在电影业，情节串联板是产品的核心，这也是建模的一种形式。在社会学、经济学和商业管理领域也需要建模，以证实人们的理论或用最小限度的风险和代价试验新的理论。

那么，模型是什么？简单地说：

模型是对现实的简化。

模型提供了系统的蓝图。模型既可以包括详细的计划，也可以包括从很高的层次考虑系统的总体计划。一个好的模型包括那些有广泛影响的主要元素，而忽略那些与给定的抽象水平不相关的次要元素。每个系统都可以从不同的方面用不同的模型来描述，因而每个模型都是一个在语义上闭合的系统抽象。模型可以是结构性的，强调系统的组织。它也可以是行为性的，强调系统的动态方面。

为什么要建模？一个基本理由是：

建模是为了能够更好地理解正在开发的系统。

通过建模，要达到以下4个目的。

（1）模型有助于按照实际情况或按照所需要的样式对系统进行可视化。

（2）模型能够规约系统的结构或行为。

（3）模型给出了指导构造系统的模板。

（4）模型对做出的决策进行文档化。

【第2章讨论UML如何完成这4件事情。】

建模并不只是针对大的系统。甚至像狗窝那样的软件也能从一些建模中受益。然而，可以明确地讲，系统越大、越复杂，建模的重要性就越大，一个很简单的原因是：

因为不能完整地理解一个复杂的系统，所以要对它建模。

人对复杂问题的理解能力是有限的。通过建模，缩小所研究问题的范围，一次只着重研究它的一个方面，这就是Edsger Dijkstra几年前讲的“分而治之”的基本方法，即把一个困难问题划分成一系列能够解决的小问题；解决了这些小问题也就解决了这个难题。此外，通过建模可以增强人的智力。一个适当选择的模型可以使建模人员在较高的抽象层次上工作。

任何情况下都应该建模的说法并没有落到实处。事实上，一些研究指出，大多数软件组织没有做正规的建模，即使做了也很少。按项目的复杂性划分一下建模的使用情况，将会发现：项目越简单，采用正规建模的就越少。

这里强调的是“正规”这个词。实际上，开发者甚至对非常简单的项目也要做一些建模工作，虽然很不正规。开发者可能在一块黑板上或一小片纸上勾画出他的想法，以对部分系统进行可视化表示，或者开发组可能使用CRC卡片描述一个场景或某种机制的设计。使用任何一种这样的模型都没有什么错。如果它能行得通，就可以使用。然而，这些非正规的模型经常是太随意了，它没有提供一种容易让他人理解的共同语言。建筑业、电机工程业和数学建模都有通用的建模语言，在软件开发中使用一种共同的建模语言进行软件建模同样能使开发组织获益匪浅。

每个项目都能从一些建模中受益。即使在一次性的软件开发中——由于可视化编程语言的支持，可以轻而易举地扔掉不适合的软件。建模也能帮助开发组更好地对系统计划进行可视化，并帮助他们正确地进行构造，使开发工作进展得更快。如果根本不去建模，项目越复杂，就越有可能失败或者构造出错误的东西。所有实用系统都有一个自然趋势：随着时间的推移变得越来越复杂。虽然今天可能认为不需要建模，但随着系统的演化，终将会对这个决定感到后悔，但那时为时已晚。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。