第1章 建模和UML #

← 返回《软件方法》

1.1 粗放经营的时代已经远去 #

改革开放初期，中国出现了许多农民企业家，他们不用讲管理，也不用 讲方法，只要胆子大一点，就能获得成功，因为当时的市场几乎空白， 竞争非常少。农民企业家的思路很简单：人人都要吃饭，所以开饭馆能 够赚钱。现在这样的思路已经行不通了。市场竞争已经足够激烈，十家 新开张的饭馆恐怕只有一家能撑下来，所以农民企业家已经很少见（连 农民都越来越少了）。软件业也一样，最开始的时候，会编程就了不 得，思路也很简单：每个公司都要做财务，所以开发财务软件能赚钱。 现在呢？我们想到一个“点子”，可能有上千人同时想到了；我们要做一 个系统，可能发现市场上已经有许多类似的系统。你卖高价，他就卖低 价，你卖低价，他就干脆免费。机会驱动、粗放经营的时代已经远去， 为了在激烈的竞争中获得优势，软件开发组织需要从细节上提升技能。

本书聚焦于两方面的技能：需求和设计。关于需求和设计，开发人员可 能每天都在做，但是否理解背后的道理呢？

1.2 利润＝需求－设计 #

利润＝收入－成本。不管出售什么，要获得利润，需要两个条件：

（1）要卖出好价钱；

（2）成本要低。 妙就妙在，价格和成本之间没有固定的计算公式，这正是创新的动力之 源。放到软件业上，我也炮制了一个公式：

         利润＝需求－设计

在软件开发中，需求工作致力于解决“提升销售”的问题，设计工作致力 于解决“降低成本”的问题，二者不能相互取代。能低成本生产某个系 统，不一定能保证它好卖。系统好卖，如果生产成本太高，最终还是赚 不了多少钱。

如果需求和设计不分，利润就会缩水。从需求直接映射设计，会得到大 量重复代码；如果从设计出发来定义需求，会得到一堆假的“需求”。

拿自古以来就有的一个系统“人体”来举例。人体的功能（能做什么）是 走路、跑步、跳跃、举重、投掷、游泳……但是设计人体的结构时，不 能从需求直接映射到设计，得到“走路子系统”“跑步子系统”“跳跃子系 统”……人体的“子系统”是“呼吸子系统”“消化子系统”“循环子系统”“神经 子系统”……“子系统”不是从需求直接映射出来的，需要设计人员的想象 力——本例子的设计人员就是造物主了。同样，也不能从设计推导出需 求：因为人有心肝脾肺肾，所以人的用例是“心管理”“肝管理”。

水店老板要雇一个民工送水（即租用一个人脑系统），他只要求这个民 工能跑能扛就行，管他体内构造是心肝脾肺肾还是一块电路板；民工找 工作也要从市场的需要来找，而不是从自己的内部器官出发来找——“老 板，我有心脏管理功能，你请我吧！”

很多时候我们说“本系统分为八大子系统……”，其实说的是“本系统的功 能需求分为八大需求包……”需求包是基于涉众视角对系统功能分包而得 到的，子系统是基于内部视角根据系统部件的耦合和内聚情况切割而得 到的。

高焕堂在他的书《Use Case入门与实例》中说过：用例是收益面，对象是 成本面。本书基于他的思想做了扩展。

1.3 建模工作流 #

要达到“低成本制造好卖的系统”的目标，并非喊喊口号就可以，需要静 下心来学习和实践以下各个建模工作流中的技能。

• 1．业务建模 描述组织内部各系统（人脑系统、电脑系统……）如 何协作，使得组织可以为其他组织提供有价值的服务。新系统只不过是 组织为了对外提供更好的服务，对自己的内部重新设计而购买的一个零 件。组织引进一个软件系统，和招聘一名新员工没有本质区别。如果通 过业务建模推导新系统的需求，而不是拍脑袋得出，假的“需求变更”会 大大减少。

• 2．需求 描述为了解决组织的问题，系统必须具有的表现——功能 和性能。这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众 （ Stakeholder ） 在 意 的 、 不 能 改 变 的 契 约 ， 哪 些 不 是 ， 严 防 “ 做 ” 污 染“卖”。需求工作流的结果——需求规约是“卖”和“做”的衔接点。

• 3．分析 提炼为了满足功能需求，系统需要封装的核心域机制。可 运行的系统需要封装各个领域的知识，其中只有一个领域（核心域）的 知识是系统能在市场上生存的理由。对核心域作研究，可以帮助我们达 到基于核心域的复用。

• 4．设计 为了满足质量需求和设计约束，核心域机制如何映射到选 定平台上实现。

软件开发人员如果缺乏软件工程方面的训练，对以上工作流没有概念， 就会把这些工作产生的工件通通称为“设计”或者“文档”。例如问开发人员 在做什么，回答“我在做设计”“我在写文档”，其实他的大脑可能正在思考 组织的流程（业务建模），或者在思考系统有什么功能性能（需求）， 或者在思考系统要包含的领域概念之间的关系（分析），但他通通回答 成“在做设计”“在写文档”。后来又有牛人说了：代码就是设计。本来“设 计”在他脑子里就是“代码以外的东西”，这么一推导，不就变成了：代码 就是一切？

很多大谈“编码的艺术”的书籍和文章，其实探讨的根本不是编码的技 能，而是分析技能甚至是业务建模技能，只是作者的大脑里没有建立起 这些概念而已。编码确实有编码的技能，就像医院里护士给患者输液也 需要经过训练，但如果患者输液后死亡，更应该反思的是护士的输液手 法不过关，还是医生的检查诊断技能不过关？

把工件简单分割为代码和文档（或设计），背后还隐含着这样的误解： 认为模型（文档）只不过是源代码的另一种比较概要或比较形象的表现 形式。这种误解不只“普通”的开发人员会有，一些著名的UML书籍作者 也有。Martin Fowler (1) 所著的UML畅销书《UML精粹》，认为UML有三种 用法：草稿、蓝图和编程语言，也是仅从编码的角度来说的。从Fowler 写作的其他书籍《重构》《企业应用架构模式》《分析模式》等可以知 道，他的研究工作集中在分析设计工作流，特别是设计工作流，在业务 建模和需求方面研究不多。

不同工作流产出的工件之间的区别不在于形式，而在于内容，也就是思 考的边界，如图1-3所示。如果清楚了解这一点，即使用C#，照样可以表 达需求，用Word也可以“编码”。

有的开发人员思维刚好是颠倒的，先拍脑袋实现，然后再从实现反 推前面的内容，例如下面的对话。

顾问：这个不应该是系统的用例。

开发人员：是的！我都写好了，运行一下给你看，这个系统确实提 供了这个用例。

顾问：这两个类关系不应该是泛化，而是关联。

开发人员：是泛化，不信我打开代码给你看，或者逆向工程转出类 图给你看。

是否系统用例应该以“好卖”来判断，是否泛化关系应该以“符合领域 内涵”来判断，而不是先写好代码，再用代码来证明。

一些不了解以上概念的软件开发人员干脆以“敏捷”“迭代”为名，放弃了这 些技能的修炼。就像一名从护士成长起来的医生，只掌握了打针的技 能，却缺少检查、诊断、拟治疗方案等技能，索性说：“唉，反正再高明 的大夫，也不能一个疗程把患者治好，干脆我也别花那么多心思了，先 随便给患者打一针看看吧，不好再来！”“迭代”只是一个底线，确实，再 高明的大夫也没有把握一个疗程就治好患者，所以要按疗程试试看，但 是在每一个疗程中，依然要尽力检查、诊断、拟治疗方案。检查、诊断 等技能越精湛，所需要的疗程就越少。 唱曲的名家，唱到极快之处，吐字依然干净利落；快节奏的现代足球， 职业球员的一招一式依然清清楚楚；即时战略游戏高手要在极短时间内 完成多次操作，动作依然井然有序。

有的开发团队用“项目时间太紧”作为放弃建模的理由，这个理由是不成 立的。以高考做类比，如果一年之后要高考，学霸会认真做一年的计 划，再做一周的计划，再做每天的计划，找出分值最大而自己又最薄弱 的地方先复习，并且随进度调整计划，不断提高，最终考了700分。学渣 则浑浑噩噩，零敲碎打，最终考400分。假设教育部门突然下令，一周之 后就要高考！学渣可能心里暗喜，以为自己翻身的机会来了。学霸依然 会认真做一周的计划，再做每天的计划，找出分值最大而自己又最薄弱 的地方先复习，并且随进度调整计划，不断提高，最终考得550分。学渣 虚度了一周时间，考了350分。有一个著名的学渣，每隔四年失败一次。 每次失败后总结教训“备战时间仓促”，其实再给学渣四年，它也是混四 年，最终还是那个样子——你猜这个学渣是谁？

在激烈竞争的年代需要快速应变，掌握技能才能真敏捷。世上无易事， 偷懒要不得。不能把“敏捷”“迭代”作为偷懒的庇护所。

有些互联网开发人员鼓吹“试错大法”，主张拍脑袋拿出去让市场试错， 这同样是很荒谬的。客户确实不管你是怎么开发的，他只需要挑好用的 就行，但对于开发系统的组织来说，有没有被挑中则是致命的。就像奴 隶主看角斗士厮杀，奴隶主无所谓谁胜谁负，反正过程精彩，最终嘉奖 冠军就行，而每一个角斗士却要如履薄冰，想方设法让自己坚持到最 后。可悲的是，互联网公司是角斗士，却偏偏有“我是奴隶主”的错觉。

刚入行的开发人员体会不到建模的重要性，是正常的。就像下象棋，初 学者面对单车对马双士、单马对单士等已经有共识的局面还需要思考良 久，最终还拿不下来，甚至输掉。这时中局和布局的书在他看来多半是 枯燥无味的，还不如把一本实用残局汇编看熟了，学到一些雕虫小技， 也能在菜市场赢几盘棋。不过，要迈向职业棋手的境界，参与更残酷的 竞争，就体现出中局和布局的重要了。

从我的观察所得，以上四项技能，大多数软件组织做得较好的是设计 （也就是实现），前面三项都相当差，特别是业务建模和分析，没有得 到足够的重视。很多软件组织拍脑袋编造需求，然后直扑代码，却不 知“功夫在诗外”。 本书中的“需求”和“设计”两个术语有两种用途。一种用于表达建模得到的 结果，例如“需求和设计不是一一对应的”；另一种用于表达建模的工作 流，即需求工作流和设计工作流，例如“我正在做需求”。希望下面的话 能帮助理解：为了得到需求，需要做的建模工作流有业务建模和需求， 为了得到设计，需要做的建模工作流有分析和设计。

到目前为止，我没有谈到UML。只要您思考过上面四个工作流的问题， 就是在建模。可以用口头表达，也可以用文本、UML、其他表示法或自 造符号来表达。在每一个项目中，开发团队肯定会思考和表达上面这些 问题，只不过可能是无意识地、不严肃地做。现在，我们要学习有意识 地做，而且把它做出利润来。使用UML来思考和表达是目前一个不坏的 选择。

1.4 UML简史 #

随着市场所要求软件的复杂度不断增大，软件开发的方法学也在不断进 化。从没有方法到简单的功能分解法，再到数据流/实体关系法。进入20 世纪90年代，面向对象分析设计（OOAD）方法学开始受到青睐，许多方 法学家纷纷提出了自己的OOAD方法学。流行度比较高的方法学主要有 Booch 、 Shlaer/Mellor 、 Wirfs-Brock 责 任 驱 动 设 计 、 Coad/Yourdon 、 Rumbaugh OMT和Jacobson OOSE。

这种百花齐放的局面带来了一个问题：各方法学有自己的一套概念、定 义和标记符号。例如现在UML中的操作（Operation），在不同方法学中 的叫法有责任（Responsibility）、服务（Service）、方法（Method）、成 员函数（Member Function）……同一个类图，不同方法学也有各自的符 号表达，这些细微的差异造成了混乱，使开发人员无从选 择，也妨碍了面向对象分析设计方法学的推广。

1994年，Rational 公司的James Rumbaugh和Grady Booch开始合并OMT和 Booch方法。随后，Ivar Jacobson带着他的OOSE方法学加入了Rational公 司，一同参与合并工作。这项工作造成了很大的冲击，因为在此之前， 各种方法学的拥护者觉得没有必要放弃自己已经采用的表示法来接受统 一的表示法。

Rational公司的这三位方法学家被大家称为“三友”（three amigo）。1996 年，三友开始与James Odell、Peter Coad、David Harel等来自其他公司的 方法学家合作，吸纳他们的成果精华。1997年9月，所有建议被合并成一 套建议书提交给OMG。1997年11月，OMG全体成员一致通过UML，并接 纳为标准。

从 2005 年 起 ， UML被 ISO接 纳 为 标 准 。 相 当 于 UML 1.4.2 的 ISO标 准 是 ISO/IEC 19501，相当于UML 2.1.2的ISO标准是ISO/IEC 19505。2012年， ISO继续接纳UML 2.4.1为ISO/IEC 19505-1:2012和ISO/IEC 19505-2:2012， 接纳OCL 2.3.1为ISO/IEC 19507:2012。

2011年，中华人民共和国也发布了统一建模语言国家标准GB/T28174。 不同方法学图形比较（同样一个三角形符号，在Coad/Yourdon方法学中用于表示关联，而 在OMT方法学中用于表示泛化）

UML的最新版本是OMG于2015年6月通过的UML 2.5，相关网址如 下。

OMG UML 2.5规范：http://www.omg.org/spec/UML/2.5/PDF

ISO UML规范： http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm? csnumber=52854

中华人民共和国国家标准： http://www.chinagb.org/ChineseStandardShow-197675.html 时间过去二十年了，UML不断发展，在表示法上已经获得了胜利。随便 打开一本现在出版的软件开发书，里面如果提到建模，使用的符号基本 都是UML，即便在纸上随便画个草图，样子也是UML的样子。各种主流 的开发平台也相继添加了UML建模的功能。OMG还和各种行业标准组织 如DMTF、HL7等结盟，用UML表达行业标准。

另外，以UML为契机，掀起了一股普及软件工程的热潮，在UML出现后 的几年，不但有关建模的新书数量暴增，包括CMM/CMMI、敏捷过程等 软 件 过 程 改 进 书 籍 数 量 也 出 现 了 大 幅 度 增 长 。 制 定 UML标 准 的 角 色 （OMG）、根据标准制作建模工具的角色（UML工具厂商）、使用UML 工具开发软件的角色（开发人员）这三种角色的剥离，也导致建模工具 的数量和种类出现了爆炸性的增长。而之前的数据流等方法从来没有像 面向对象分析设计方法一样，出现UML这样的统一表示法，从而带动大 量书籍和工具的产生。

最 开 始 一 批 UML 书 籍 ， 基 本 上 由 方 法 学 家 所 写 的 。 最 近 几 年 ， 以“UML”为题的新书大多为高校教材或普及性教材。这并不是说UML已 经不重要，而是没有必要再去强调，焦点不再是“要不要UML”，而是要 不要建模、如何建模。

根据UMLChina的统计，UML相关工具最多时达168种，经过市场的洗 礼，现在还在更新的还有近百种。有钱买贵的，没钱就买便宜的或者用 免 费 或 开 源 的 ， 可 参 见 UMLChina 整 理 的 UML 工 具 大 全 ： http://www.umlchina.com/Tools/Newindex1.htm。

1.5 UML应用于建模工作流 #

可能您看了会说，哇，这么多图，学起来用起来多复杂啊。其实，UML 像一个工具箱，里面有各种工具。建模人员只需要根据当前所开发系统 的特点，从这个工具箱中选择合适的工具就可以，并不需要“完整地”使 用UML。这和编程语言类似。很多人说“我用Java”，其实只是用Java的一 小部分，而且很长时间内也只会用这一小部分。

经常有学员问：潘老师，能不能给一个案例，完完整整地实施整套 UML？这是一种误解，这样的案例不应该有。这相当于问：有没有一本 经典的小说，把字典里所有的单词都用上？有一些建模工具自带的案例 模型会造成误解，一个模型里把所有的UML图都给用上了，但这是工具 厂商出于展示其工具建模能力的目的而提供的，不可当真。

各建模工作流可以选用的建模图形以及推荐用法，如图1-6所示。

观察图的地方可以知道，掌握用例图、类图、序列图这三种 图基本上够用了，可以先重点学习这三种图，其他图形暂时不管。针对 特定类型的项目，如果有必要，可以按需添加图形。例如，开发复杂组 织的运营系统，如果在业务建模时不喜欢用序列图，可以用活动图取 代；对于系统中的核心类，可以着重画出状态机图来建模类内部的逻 辑；针对质量要求很高的系统，每一个类可能都需要画状态机图，甚至 还要画时间图。

另外，设计工作流目前推荐的做法是不需要画UML图，而是用文本来表 达实现模型，即所谓“代码就是设计”——编码就是一种建模工作。计算 机运行的是二进制指令，源代码实际上也是“模型”。之所以被称为“源代 码”，是因为它是人脑需要编辑的最低形式模型。这个最低形式模型随着 时代的发展不断变化。

最初的源代码是机器语言。程序员在纸带或卡片上打孔来 表达0和1。后来发现这样太累了，于是发明了一些助记符，这就是汇编 语言。今天会有开发人员故作谦虚，“这些我不太懂唉，我是做底层的， 用C编码”，可是C语言却被归类为“高级语言”，因为类似C这样的语言出 现的时候，大多数程序员编辑的是汇编语言，C相对于汇编来说，当然很 高级。今天的一名企业应用程序员，需要编辑的可能有Java代码、配置脚 本、SQL语句等，这些就是现在的“源代码”的形式。

如果人脑只需要编辑UML模型就可以实现系统，那么“模型就是源代 码”。例如用带有设计级调试和强大代码生成能力的工具IBM Rational Rhapsody开发实时嵌入系统，人脑只需要编辑和调试UML模型（类图和 状态机图）。

1.6 基本共识上的沟通 #

不少开发人员并不喜欢用UML，更喜欢在白板上画个自造的草图，似流 程图非流程图，似类图非类图，然后说“来，我给大家讲讲！”这样的做 法有巨大的“优点”：怎么画都是对的，关于这个草图的解释权归“我”所 有。同事不好批评“我”，项目要依赖于“我”头脑中的隐式知识——要 是“我”不“给大家讲讲”，大家就玩不转了。这样，“我”在团队里的地位就 提高了。上面这种现象，在有一定资历、但又不对项目的成败承担首要 责任的“高手”身上表现得更明显。

开发人员让我看他的模型时，如果开口说“我先来给你讲讲”，我都会拦 住，“如果还需要你先讲讲，说明你所想的没有体现在模型中”。

这种做法的本质是想通过形式上的丑陋来遮掩内容上的丑陋。动乱年 代，数学家在牛棚中用马粪纸做数学推导，不代表就可以因为演算工具 简陋而允许自己胡乱使用符号和概念；过去的作家没有电脑，不意味着 可以随意写错别字和犯语法错误。开发人员故意选择简陋的形式为简陋 的内容开脱，就如同作家故意选择不好的纸来掩盖自己文字功力不足的 事实，并不是好现象。UML没有强调一定要用多么昂贵的工具来建模， 即使开发人员在海边用手指在沙滩上建模，模型所体现的概念依然要清 晰。

数学里的积分符号、五线谱的小豆芽，幼儿园小朋友也会 画，但背后的道理需要经过艰苦的训练才能理解。就像数学符号背后隐 含着数学的基本共识，五线谱背后隐含着基本乐理一样，UML背后隐含 着软件建模的一些基本共识，这些共识需要一定的训练才能掌握。

掌握统一的建模语言之后，开发团队在基本共识上沟通，会大大提高沟 通的效率和深度，有意无意遮掩的脓包也会强制露出。开发人员如果习 惯于画“草图”，用“模块”“特性”等词汇含糊不清地表达思想，在严谨建模 思维的追问之下，往往会千疮百孔，暴露许多之前没有想到的问题。这 是一些“高手”潜意识里不愿意直面UML的深层原因——如果有“高手”不同 意，欢迎把所画的草图发过来，我告诉您背后隐藏的“脓包”。

面对一个棋局，下一步怎么走？在业余棋手看来到处都是正确答案，在 职业棋手眼里，值得讨论的选项只有两三种，因为职业棋手针对一些基 本的技能达成了共识，大大减少了思考中的浪费。 有些“敏捷”软件组织，抛弃了所有“文档”（前文已说过，如果使用“文 档”这个词，说明概念不清楚），更喜欢口头交流，动不动就开会，你一 嘴我一嘴，场面看起来热热闹闹，其实沟通的效果不好，更谈不上思考 的深度和知识的沉淀。对比一下街坊老大爷下象棋的热闹和职业棋手比 赛时的沉静就知道了。“敏捷”的理由也不成立，街坊老大爷判断局势的 速度快还是职业棋手判断局势的速度快？野路子棋手不看棋书不打谱， 摆个路边摊也许够用，如果参加职业比赛，会被打得落花流水。

有的开发人员的“十年工作经验”实际上是“一年工作经验用了十年”，一直 在热热闹闹的民工层次徘徊，没有积累和成长。

不过要注意一点：使用UML沟通仅限于软件组织内部，UML模型不是用 来和涉众沟通的！这个道理以及和涉众沟通的技能将在第7章详细叙述。

1.7 建模和敏捷（Agile） #

敏 捷 运 动 在 20 世 纪 90 年 代 中 期 兴 起 ， 当 时 敏 捷 过 程 被 称 为 轻 量 （lightweight）过程。2001年，Kent Beck、Martin Fowler等人聚集在犹他 州的Snowbird，决定把“敏捷”作为新的过程家族的名称，并提出宣 言. 敏捷运动可以看作是“政治正确”的左翼思想在软件开发领域的一次演 练。这次演练和在人类社会其他领域已发生的左翼演练一样，迅速取得 了成功，带来了一批“有信仰”的软件从业者。此处不再细谈，只谈谈口 号和方法的区别。

有口号有方法，有口号无方法，无口号无方法，这三种情况哪一种最 坏？可能有的人认为无口号无方法最坏，其实不然，无口号无方法地呆 在原地，可能会慢慢衰落，但不是最坏的。历史上各种最坏的大悲剧往 往和“有口号无方法”有关。 最坏的事是“有口号无方法”的“好人”做的。偷盗抢劫的坏人知道自己做的 是坏事，会暗自收敛，事后会内疚，甚至做一些善事来弥补以求心安； 而“好人”认为自己是做好事，所以会做得很极端，如果有口号无方法， 大悲剧就发生了。例如，有人谈论社会上存在的（□□此处作者删去三十 二字□□）问题，列举的大都是事实，结果给出的解决方案却是（□□此处 作者删去二十八字□□）。有一句名言“通往地狱的道路通常是由善意铺就 的”，就是这个意思。

软件开发领域也有不少有口号无方法的场景。

【口号】我们只做最重要的需求，尽快把系统推向市场。 【问题来了】怎么知道哪个需求最重要？拍脑袋？ 【口号】设计要分离变和不变，这样可以减少变更的成本。 【问题来了】怎么知道哪些变哪些不变？抓阄？

建模，为口号提供了方法；愿景、业务建模方法，帮助迅速定位最重要 的需求；领域分析方法，帮助厘清各种概念的变和不变。

开发团队要警惕有口号无方法的成员。这些害群之马擅长喊口号打鸡 血，上班时间端着茶杯大谈老子、庄子、孙子、禅、道……吐槽软件项 目中的各种痛苦。这些痛苦确实是事实，结果给出的解决方案却是荒谬 的。

有两幢大楼，地震中一幢倒塌了，另一幢没倒塌。倒塌的直接因素可能 是大楼的结构、所用的材料、所在位置的地质环境等，但这些都涉及比 较艰深的工程力学、材料学和地质学知识。有人懒得思考，干脆就直接 嚷“有人吃回扣了”，就算经过调查没人吃回扣，他也会从工作服的颜 色，工人是否结队洗澡，施工队开会时是否站立等方面来找原因，因为 这相对容易。

本书内容针对的是影响软件质量的直接原因——缺少各种建模技能。许 多团队实施过程改进容易流于形式，根源往往就在于建模技能的不足。 如果把改进的焦点先放在建模技能上，开发人员技能提升了，适用什么 样的过程自然就浮出水面，没有必要去生搬硬套某过程。或者说，技能 增强了，更能适应不同的过程。UML建模没有绑定到特定过程。当前主 流的软件过程都是强调增量和迭代开发，应该把前面所讲的业务建模、 需求、分析、设计看作是一个迭代周期里的工作流，做一点业务建模， 做一点需求，做一点分析，做一点设计……不可误解成“做完了所有的业 务建模才能做需求”……

很多时候方法和过程经常被混淆，有人会把“敏捷”说成“敏捷方法”，其 实“敏捷”是一个过程家族。之所以造成这个误解，也许和Martin Fowler把 他介绍敏 捷过 程 家族的 文章起名 为“ 新方 法学（The New Methodology ）”有关。另一个常见的误解来自Robert C. Martin的书《敏捷软件开发 ——原则、方法与实践》，书中主要讲的是面向对象设计的一些方法 （原理、原则和模式），这些方法并非Robert C. Martin首先提出的，而且 和敏捷过程没有必然关系，但是，经常会有开发人员误解面向对象设计 的这些思想是敏捷人士提出来的。更有一些敏捷人士在没有学习和掌握 软件工程知识的情况下，先高喊“砸烂一切”，吸引热血青年，然后发现 砸烂一切是不行的，又偷偷拾起过去被自己砸烂的东西，加上自己的“敏 捷”包装，有意无意地给不了解历史的新入行开发人员造成“这是敏捷发 明的，那是敏捷发明的，所以把敏捷挂在嘴边的人最懂”的印象。

我刚开始为软件组织提供服务时，有一次和一个软件组织的经理交流， 经理说“我们用的是面向过程方法”。我一开始信以为真，认为如果能做 到用面向过程方法，从组织级、系统级到模块级层层分解也不错的。后 来发现，经理所说的“面向过程方法”其实是随意的功能分解，也就是没 有方法。

类似的场景还有：软件组织负责人说“我们现在采用的是敏捷过程”，稍 微深入了解，多半会发现其实他所说的“敏捷过程”就是没有过程。不要 让“面向过程”和“敏捷”成为偷懒的庇护所。

1.8 什么样的系统不需要建模 #

这是经常被问到的一个问题。前文已经说过，编码就是建模，所以什么 样的系统都需要建模。这个问题真正要问的是“什么样的系统可以不用业 务建模、需求、分析，而直接设计（编码）？”

1.8.1 市场没有小系统 #

过去的软件工程书籍中，谈到建模的重要性时，常会说：“自己搭个狗屋 不需要建模，盖摩天大楼需要建模，因为后者更复杂。”这样的说法并不 正确。在市场经济的环境下，如果要挣到钱，搭狗屋和盖摩天大楼的复 杂度是一样的。狗屋有狗屋的品牌，摩天大楼有摩天大楼的品牌，盖摩 天大楼的公司要抢搭狗屋公司的市场可没那么容易——世上无易事，市 场没有小系统（见图1-9）。 要是我问您，跑百米容易还是跑马拉松容易？这还用问！当然是跑百米 容易了，是吧？其实我想问的是：亚洲运动员要拿奥运冠军，是跑百米 容易还是跑马拉松容易？答案似乎就颠倒过来了。近邻韩国和日本都已 经出过奥运马拉松冠军，比起拿百米冠军，概率要大多了。 不同形态的系统各自有各自的复杂性，看起来做一个电厂管理信息系统 好像很牛，但做一块电表的学问也不小。到现在为止，我服务的组织覆 盖了国内各个领域的领袖企业，包括通信、企业管理、电子商务、房地 产、网络游戏、地理信息、物流、数码设备、医疗设备、工业控制等领 域。业务建模、需求、分析等建模技能都适用于这些企业的项目。无论 是上千万人同时使用的社交系统，还是行政人员使用的内部办公系统， 还是埋藏在人体内的小设备，建模是否值得，和系统的运行形态无关， 而是看软件组织有没有一颗冠军的心。

1.8.2 你的系统不特别 #

还有一种以为不需要建模的情况是，开发团队经常认为自己做的系统“比 较特别”，以此作为懒得深入思考的理由。如果学习了本书的建模技能， 就会发现之前认为特别的项目其实没有什么特别，包括所谓的“遗留系 统”、二次开发系统、内部系统、移动互联网系统、政绩工程……一些互 联网开发人员动不动就鼓吹“互联网思维”，拼命强调自己所开发的系统 有多特别，无非是偷懒和为失败寻找借口而已。 见识少的病人总以为自己得了怪病，其实到医院让医生一看，太普通 了。 还有一个常听到的偷懒庇护所是“软件开发是艺术”。软件开发是不是艺 术，我不知道，不过就算软件开发到了极高境界真的是艺术，恐怕也不 是大多数人目前有资格谈的。下棋到很高境界，也有各种流派风格，但 那是在通晓了基本棋理的基础上演变出来的，连基本棋理都没有掌握的 初学者，把自己的胡思乱下也当成“流派”就不合适了。 我在指点建模人员改正他所画的模型的时候，偶尔会有建模人员不服 气，“老师，难道一定要按照你这个规范吗？我自己有一套规范不行 吗？”这不是规范的问题，是背后的基本道理。 师父纠正少林弟子武功招数的细节，弟子懒得去了解为什么按师父教的 会好一点，反而说：“不要纠结于细节，天下的武功又不是只有少林这一 派，”以为这样一说，自己就可以摇身一变成为武当派高手了。其实，少 林派武功学精了，如果对武当派武功感兴趣，转起来容易很多。如果某 人学少林派武功时面对细节总是以“不纠结”为由拒绝进一步思考，很难 相信他学习武当派武功时会好到哪里去。 本书到现在为止，已经说了很多回“偷懒”，就是强调世上无易事，好的 方法应该能强迫您思考，强迫您付出心血和汗水来获得竞争优势，反之 就是忽悠，就像前些年一些甜得发腻的敏捷宣传。

1.9 案例介绍 #

本书的案例讲述UMLChina如何改进其内部业务系统的故事。我在序言说 到，UMLChina秉持“内外有别”的原则。在外面看来，UMLChina的网站其 貌不扬，十几年如一日，UMLChina组织的信息化其实藏在背后。 UMLChina一开始把领域放在软件工程，后来发现，这个领域已经太大 了，没有能力在这么大的范围内做到最好，于是缩小范围，专注于和 UML相关的建模技能。2002—2004年我们和出版社合作翻译了《人月神 话》《人件》等软件工程书籍，这方面的书籍后来不再做了，只做建模 相关的书籍。 我为UMLChina所做的定位是：做世界上最小和最好的建模咨询公司。 咨询工作适合做精，不适合做大。UMLChina没有招揽或培养满屋子的“年 轻资深咨询师”，通过扩大规模来提高收入，有的机构这样做了，也获得 了更多的收益，但那不是我们的路。 一旦从深度上定位，就会发现要做的事情非常多，2005年，我决定着手 开发UMLChina的业务系统。经过这些年持续改进和升级（也仍将继续改 进和升级），虽然现在离我希望的“武装到牙齿”的境界还有很大的距 离，但这个和UMLChina业务结合在一起的系统确实能够让UMLChina不必 请更多的人就可以保持正常运作。因为很多业务逻辑已经封装在系统 中，所以也比较容易分权给助理。 后面给出的素材绝大部分是真实的，如果有一些地方做了模糊处理，那 是出于商业上的考虑。UMLChina在商业方面的事宜有公司负责运作，本 书隐去公司真实名字，仍把这个公司叫做UMLChina。

1.10 模型的组织 #

从前面的图1-6可以知道，建模工作流和所用的UML元素不是一一对应 的。模型可以按照UML元素的种类组织，也可以按照工作流来组织。

本书推荐的模型组织方式是按工作流组织，如图1-10所示。本书提供了一 个初始Enterprise Architect（以下简称EA）模型，该模型已经按照图1-10 的组织方式建好了包，并且添加了一些业务建模和分析的构造型 （Stereotype）。我建议读者直接从本书提供的初始模型开始做，按部就 班 填 空 即 可 。 初 始 模 型 的 下 载 地 址 是 http://www.umlchina.com/training/myproject.rar。 初始模型使用EA13编辑保 存，使用其他EA版本打开编辑也应该没有问题。您在熟练掌握本书的建 模技能以后，如果体会出对您的项目更合理的组织方式，可以抛弃本书 所推荐的方式。如果您平时使用的工具不是EA，而是RSA、StarUML、 VP-UML等，也可以自行按照图1-10的方式组织模型。UML工具（包括 EA）一般都会预置一些模板，建议先无视它们。

另外一种常见的模型组织方式是按视图来组织，如图1-11所示。以前 Rational Rose默认的组织方式就是这样，最开始我也是这么做的，但是后 来发现开发人员容易出问题的地方不是用什么图，而是目前在做什么。 开发人员的思维经常跳来跳去，无意识地改变思考的焦点——正在讨论 系统之间的协作流程，突然就跳入某个系统的内部讨论类的关系，甚至 类的某个操作内部的实现。所以，本书不推荐按视图组织模型。