INFO

摘抄了《软件方法》方法中觉得很经典的话语

[TOC]

软件开发的四个步骤 ​

• 业务建模
• 需求
• 分析
• 设计

各个种类的图和思考的焦点 ​

工作流	思考焦点	用例	类	组件	对象	部署	组合结构	包	扩展机制	序列	通信	状态机	活动	时间	交互概述	文本
业务建模	组织内系统之间	✅	✅							✅			√		√
需求	系统边界	✅								√		√	√			✅
分析	系统内核心领域		✅		√		√			✅	√	✅	√	√
设计	系统内各领域之间		√	√	√	√	√			√	√	√	√	√

备注：✅表示优先使用，√ 表示可以使用。

掌握用例图、类图、序列图这三种图就基本够用了。

基本共识上的沟通 ​

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

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

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

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

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

总结：不要用形式上的丑陋来遮掩内容上的丑陋

走上竞争牌桌的前提是专业性 ​

面对一个棋局，下一步怎么走?在业余棋手看来到处都是正确答案，在职业棋手眼里，值得讨论的选项只有两三种，因为职业棋手针对一些基本的技能达成了共识，大大减少了思考中的浪费。

有些“敏捷”软件组织，抛弃了所有“文档”(前文已说过，如果使用“文档”这个词，说明概念不清楚)，更喜欢口头交流，动不动就开会，你一嘴我一嘴，场面看起来热热闹闹，其实沟通的效果不好，更谈不上思考的深度和知识的沉淀。对比一下街坊老大爷下象棋的热闹和职业棋手比赛时的沉静就知道了。“敏捷”的理由也不成立，街坊老大爷判断局势的速度快还是职业棋手判断局势的速度快?野路子棋手不看棋书不打谱，摆个路边摊也许够用，如果参加职业比赛，会被打得落花流水。

十年工作经验是一年工作经验用了 十年 ​

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

总结：野路子棋手在职业赛场估计会被打的落花流水

建模与敏捷 ​

敏捷运动在20世纪90年代中期兴起，当时敏捷过程被称为轻量(lightweight)过程。2001年，Kent Beck、Martin Fowler等人聚集在犹他州的Snowbird，决定把“敏捷”作为新的过程家族的名称，并提出以下宣言"

• 个体和交互 胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作 胜过 合同谈判
• 响应变化 胜过 遵循计划"

敏捷运动可以看作是“政治正确”的左翼思想在软件开发领域的一次演练。这次演练和在人类社会其他领域已发生的左翼演练一样，迅速取得了成功，带来了一批“有信仰”的软件从业者。此处不再细谈，只谈谈口号和方法的区别。

有口号有方法，有口号无方法，无口号无方法，这三种情况哪一种最坏?可能有的人认为无口号无方法最坏，其实不然，无口号无方法地呆在原地，可能会慢慢衰落，但不是最坏的。历史上各种最坏的大悲剧往往和“有口号无方法”有关。

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

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

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

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

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

总结：最坏的事情就是有口号无方法的人去做的

什么系统不需要建模 ​

市场没有小系统 ​

换句话讲,从一个小的系统锻炼建模的能力,也是可以开始的.

过去的软件工程书籍中，谈到建模的重要性时，常会说:“自己搭个狗屋不需要建模，盖摩天大楼需要建模，因为后者更复杂。”这样的说法并不正确。在市场经济的环境下，如果要挣到钱，搭狗屋和盖摩天大楼的复杂度是一样的。狗屋有狗屋的品牌，摩天大楼有摩天大楼的品牌，盖摩天大楼的公司要抢搭狗屋公司的市场可没那么容易一世上无易事，市场没有小系统

要是我问您，跑百米容易还是跑马拉松容易?这还用问!当然是跑百米容易了，是吧?其实我想问的是:亚洲运动员要拿奥运冠军，是跑百米容易还是跑马拉松容易?答案似乎就颠倒过来了。近邻韩国和日本都已经出过奥运马拉松冠军，比起拿百米冠军，概率要大多了。

不同形态的系统各自有各自的复杂性，看起来做一个电厂管理信息系统好像很牛，但做一块电表的学问也不小。到现在为止，我服务的组织覆盖了国内各个领域的领袖企业，包括通信、企业管理、电子商务、房地产、网络游戏、地理信息、物流、数码设备、医疗设备、工业控制等领域。业务建模、需求、分析等建模技能都适用于这些企业的项目。无论是上千万人同时使用的社交系统，还是行政人员使用的内部办公系统，还是埋藏在人体内的小设备，建模是否值得，和系统的运行形态无关，而是看软件组织有没有一颗冠军的心。

你的系统并不特别 ​

还有一种以为不需要建模的情况是，开发团队经常认为自己做的系统“比较特别”，以此作为懒得深入思考的理由。如果学习了本书的建模技能，就会发现之前认为特别的项目其实没有什么特别，包括所谓的“遗留系统”、二次开发系统、内部系统、移动互联网系统、政绩工程……一些互联网开发人员动不动就鼓吹“互联网思维”，拼命强调自己所开发的系统有多特别，无非是偷懒和为失败寻找借口而已。

见识少的病人总以为自己得了怪病，其实到医院让医生一看，太普通了。

还有一个常听到的偷懒庇护所是“软件开发是艺术”。软件开发是不是艺术，我不知道，不过就算软件开发到了极高境界真的是艺术，恐怕也不是大多数人目前有资格谈的。下棋到很高境界，也有各种流派风格，但那是在通晓了基本棋理的基础上演变出来的，连基本棋理都没有掌握的初学者，把自己的胡思乱下也当成“流派”就不合适了。

我在指点建模人员改正他所画的模型的时候，偶尔会有建模人员不服气，“老师，难道一定要按照你这个规范吗?我自己有一套规范不行吗?”这不是规范的问题，是背后的基本道理。

师父纠正少林弟子武功招数的细节，弟子懒得去了解为什么按师父教的会好一点，反而说:“不要纠结于细节，天下的武功又不是只有少林这一派，”以为这样一说，自己就可以摇身一变成为武当派高手了。其实，少林派武功学精了，如果对武当派武功感兴趣，转起来容易很多。如果某人学少林派武功时面对细节总是以“不纠结”为由拒绝进一步思考，很难相信他学习武当派武功时会好到哪里去。

本书到现在为止，已经说了很多回“偷懒”，就是强调世上无易事，好的方法应该能强迫您思考，强迫您付出心血和汗水来获得竞争优势，反之就是忽悠，就像前些年一些甜得发腻的敏捷宣传。

什么是愿景以及愿景的重要性 ​

爆炸法 ​

如果投资人在你身上绑了炸弹，命令你在几分钟之内把当前研究的系统推销出去，而且只能找一个人推销。假设这个炸弹还能感应脑电波，推销完毕后，如果炸弹感应到被推销的人对这个系统不感兴趣，就会爆炸。这种情况下，为了最大可能地保住自己的性命，你会选择向谁推销，推销时选择说什么话?这个问题的答案就是老大和愿景。

(很多人可能会第一时间想到向自己的父亲或母亲推销，但是，父母会买单是对你的性命感兴趣，未必对你推销的系统感兴趣，炸弹依然会爆炸!)

如果上面的场景还不足以刺激你思考，可以用加强版:如果投资人在你和你的情敌身上绑了炸弹，命令你们几分钟时间内把当前研究的系统推销出去，谁得到的感兴趣的脑电波强，谁就活下来。

愿景属于业务建模工作流的一部分。为了突出愿景的重要性，本它单独列为一章。

如果缺乏清晰、共享的愿景，开发人员就会兴高采烈地在错误的方上狂奔，做得越多，浪费越多。很多年前一位技术总监的话让我印象深刻: “知道这两个(和愿景相关度最大的)功能实现难度太大做不下去, 在我看来这个项目已经没有价值，但是开发人员还乐在其中，觉得还有其他功能可以做。”

没有愿景的支持，互联网时代流行的口号“我们只做最重要的需求”“砍掉80%的功能，专注于剩下的20%”将沦为空话，怎么判断哪条需求最重要?砍掉哪80%?愿景就是需求排序的主要依据。

愿景如此重要，开发团队却经常不写，或者把它写成一堆空话套话。我们现在来学习如何从空话套话中把干货提炼出来，写成愿景。

以一个待引入系统为研究对象，其愿景的定义是:在目标组织代表(老大)看来，引进该系统应该给组织带来的改进。

一个愿景的系统的例子:

---

系统: 生产执行管理系统老大:

龙翔公司制造部王部长目标(度量): “缩短从接到市场部订单到交付产品的时间周期。

度量:(交付时间-接单时间)/件数

---

通俗一点说，一个东西的愿景就是:东西最应该卖给谁，对他有什么好处?这么简单的问题，回答起来未必容易。开发人员介绍自己的系统时，洋洋洒洒说一大堆系统有哪些功能，采用什么技术平台、架构等，但被问到“为什么要做这个系统”时，可能就会瞠目结舌。如果开发人员的思维停留在“可以工作的软件”(来自“敏捷宣言”)而不是追求“可以卖的软件",他甚至会纳闷为什么要思考愿景这个东西!

业务流程在老大的头脑中厮杀 ​

老大的头脑是一块一块的战场。所研究的系统是军队，开发团队的领导是指挥官，他负责找到自己的军队最值得投入的战场，指挥军队和敌人厮杀，占领战场，或者防守住敌人的进攻。

开发人员到底在做什么项目？ ​

做这些深刻的思考并不容易。很多需求人员是从程序员转型而来，习惯于从实现的角度看问题，而不是从老大的视角。

有时候，我问程序员：你最近做什么项目？有的程序员回答：我在做一个“Java 项目”，因为他不关心项目的核心域是医院、物流、保险还是城市规划，他只关心这个项目能否提升他的Java 技能，从而对升职加薪有帮助，所以把这个项目叫做 "Java项目" 是十分正确的。并不只是刚入职的程序员会这样回答，有一次，我问一位有将近十年开发工作经验的架构师最近在做什么项目，架构师说：在做一个数据仓库项目。继续聊下去，了解到其实他做的是某通信公司的客户关系管理系统，里边用到了数据仓库，而数据仓库的知识恰好是他比较缺乏而且感兴趣的，所以他干脆把这个项目成为“数据仓库项目”了！

定位目标组织和老大所需要的步骤 ​

编号	情况	系统改进范围	定位老大的步骤
1	针对人群的非定制系统	某个人员	* 定位目标人员 * 定位老大
2	针对某特定机构的定制系统	某特定机构	* 定位机构范围 * 定位老大
3	针对某类机构的非定制系统	某类机构	* 定位机构范围 * 定位目标机构 * 定位老大

不要加上如果 ​

"如果"二字害人补签。建模人员嘴皮子一动，就把很难的前提条件当成已经存在的了——“如果时光可以倒流”、如果我是皇帝。

在给某单位做一个内部项目是，建模人员 A 自作主张加进去一个用例。我认为这些用例和客户的愿景关系不大，可以去掉。A 反问道：如果做一个通用的产品在市场上卖呢？“如果”！是否做通用产品，这可是一个重大的商业决策，建模人员却认为将这个系统编程通用产品拿到市场上卖（目标组织变了）是一件轻而易举的事情。事实上，这涉及整个愿景的转变，甚至公司战略的转变，而且需求受影响的可能不只是当前这个系统。市场是残酷的，谁吃肉谁喝西北风，可不能随便“如果”。

老大可以变化吗？ ​

当然可以。一个战场搞定以后，军队奔向第二个战场。或者说，根本不存在变化的问题。老大、愿景、需求都是基于现状寻求最值得的改进。改进过后，又是新的现状了，还是基于现状寻找最值得的改进。进一步也可以说，需求只有真假对错，没有变化。说需求有变化，那是从一个静止的时间点来看的。

如何提炼改进目标 ​

改进目标不是系统功能需求 ​

像目标的表述	不像目标的表述
提高回访订单转化率	建立一个 CRM 系统
减少每张处理订单需要的人力	提供自助下单功能
缩短评估贷款风险的周期	能够对贷款申请作风险评估

改进组织行为的指标，不是做某事

揣摩上意，也是某些体制下官场的基本生存技能 ​

这些揣摩技能，我们每个人都有。我们每天都在揣摩上司、同事、配偶的意思，只不过现在要把这项技能用在软件开发上。设想一下，如果不是开发软件，而是给目前单身的老大介绍个相亲对象。老大说:“帮我找个条件不错的”，您不也得从老大的角度揣摩“不错”的度量指标吗？老大更看重的是脸、身材、皮肤、性格、学历、家底？切不可因为自己喜欢凤姐，就给老大带个凤姐回来。

有时建模人员说:“哪有什么度量指标啊，我们做的那个系统就是个政绩工程，客户领导去×X省考察回来，说××省有一套×X系统，我们也要有！”其实，“政绩”二字本身就隐含着数字的概念，政绩工程也一样有度量指标。需求人员仍然需要好好去揣摩:老大关心什么样的政绩指标？“揣摩上意”本来就是某些体制下官场的基本生存技能。

思考度量指标，可以用以下方法。 针对形容词来思考符合这个形容词和不符合这个形容词的情况。例如，目标里有个形容词“规范”，我们可以问:目前怎么个不规范，请举一个最头痛的例子。如果改进之后，老大觉得规范多了，那是什么样的情况？通过这样追问，得到“规范”的度量是“格式不合格的报表所占的比例”。类似的度量还有:

方便--完成一张订单的平均操作次数

高效--从受理到发证的时间周期

从初步设想的解决方案倒推。

借鉴机构的KPI（关键绩效指标） ​

所研究系统可能就是改进其中的一部分，借鉴过来就可以(见图2-15)。

序号	KPI指标	考核周期	指标定义/公式
1	新产品工艺设计 任务完成准时率	季/年度	指标定义/公式实际设计周期X100%
2	工艺试验 及时完成率	月/季/年度	按时完成工艺试验次数/工艺试验总次数 X100%

改进目标应来自老大的视角 ​

改进目标描述的是系统给目标组织带来的改进，应该从老大和目标组织的视角来定义。不过在实践中，需求人员会觉得要揣摩老大的目标太 难，不知不觉就把它改成开发团队的目标。这种“目标”通常如下:

一年以内，网站的会员达到一千万；

系统的市场占有率达到40%。

这种不费吹灰之力得到的“目标”没有意义--你想会员达到一千万就能一千万吗？需求人员要动脑筋思考，系统必须在哪些地方给目标组织带来竞争对手所无法达到的改进，例如:

“YP网”的目标是剩女发起相亲的平均成功率达到60%以上。

这样，目标组织(上面这句话就是剩女人群)才会乐意引进这个系统。

其实很多系统就是马桶 ​

开发人员有时会有意无意把自己的系统想得太重要，还喜欢起xx云平台等很牛的名字，以为没有他们开发的系统，组织就玩不转了。有一次我到北京某公司讲课，开发人员在写某信贷风险系统的愿景时写道:本系统的目标是，银行风险部能够对贷款做风险评估。我问道:难道银行以前不能做风险评估吗？他认真地回答:不能啊，有我们的系统才行！其实想想就知道，银行都成立多少年了，该公司才成立几年？所以为了抵消开发人员这种“致命的自负”，有时我会故意将“系统”称为“马桶”，意思是这个零件和组织厕所里的马桶没有本质区别。

组织内外的边界以责任划分，而不是物理位置 ​

经常有人会提到在家上班、在客户处上班、某些岗位人员的工资和保险由外包公司负责等“特殊情况”，其实这些情况没有什么特别，因为组织内外的边界是以责任划分，而不是物理位置。关于以责任划分边界，第五章会再详细讨论。

识别业务工人，将业务逻辑从业务工人转移到系统中去 ​

业务工人是可以被替换的人脑零件，它可能会被其他业务工人替换， 但更有可能被业务实体(Business Entity)替换。业务实体是组织中的非人智能系统，例如银行的ATM、点钞机、营业系统。

在没有点钞机的时代，储户拿着一摞钞票到银行存钱，营业员需要凭着手感(界面层)一张张数，触摸信号传到大脑(核心域层)，大脑要很快判断钞票的真伪和计数。验钞、计数的逻辑封装在营业员的大脑里，营业员非常累，而且营业员要有经验，小白是干不了的。这样，人力成本高了很多。

有了点钞机，营业员只需要把整叠钞票放进点钞机过一下，点钞机会负责验钞和计数。也就是说，验钞和计数的逻辑从人脑转移到了点钞机的“大脑”，如图3-3所示。营业员轻松了，或者说，银行也就不需要那么多有经验的营业员了。许多信息化程度很高的领域，绝大多数领域逻辑目前已经运行在业务实体中，业务工人主要负责输入信息。银行所属的金融领域就是如此。

业务用例指的是希望通过和所研究组织交互获得的价值 ​

业务用例指业务执行者希望通过和所研究组织交互获得的价值。以上面提到的某商业银行为例，储户和银行打交道的目的可能有存款、取款、 转账，所以银行针对储户的用例如图3-9所示。

价值是期望和承诺的平衡点、买卖的平衡点 ​

用好用例，关键在于理解“价值”。价值是期望和承诺的平衡点、买卖的平衡点。

例如，以医院为研究对象，“患者挂号”不是用例，因为挂号不是患者对医院的期望和医院对患者的承诺的平衡点。如果挂到了号后医院的服务到此为止，患者到医院来时心中的期望将无法得到满足，或者说医院这个研究对象能承诺向患者提供的价值不是挂号，而是看病。

或者可以这样思考:医院能这样叫卖自己吗？“来呀来呀，我这家医院能挂号呀！”患者一听，“哇，真棒耶，这医院能挂号耶，我赶紧去！” 其实患者巴不得不挂号也能看病，只不过人太多了，需要拿号排队。

如果把研究对象改为医院挂号室，“患者→挂号”就是合适的用例。 患者对挂号室的期望是能挂到号，不会因为挂号室没帮他看病就破口大骂。挂号室对他的承诺也就是能给他号。

UML用的好的团队不多并不代表没有价值 ​

这里展开说一个问题:多，不代表有价值。经常有建模人员问我， “潘老师，UML用得好的团队多不多？”我只能回答“不多”(参见第1章关于“冠军的心”的阐述)。于是提问者就释然了，哦，用得好的不多，看起来这个东西用处不大，我不学也没关系的。

围棋下得好的、足球踢得好的、脑外科手术做得好的、身材长得好的......都不多，但是一旦突破门槛进入这个圈子，就会有很大的竞争优势。就拿编码来说，可能读者觉得会编码的人挺多的，周围的人大多都会。其实会编码的人数和会吃喝拉撒的人数相比少得可怜，编码编得好的就更少了，但不能由此推导出“编码没用”的结论，相反，正是因为编码有门槛，所以大多数程序员尽管买房不容易，衣食无忧是做得到的。

会用活动图(或者再退一步，会用流程图)来建模业务流程的人已经算是少的了，更多的是随意画的“草图”，更普遍的应该是什么都不会画或者懒得画，把“脓包”一遮了之。

工作人员“用Word写标书”是不对的 ​

分配给业务对象的责任必须是该对象有能力承担的。在这一点上，我们平时的说话是含糊的，很容易造成误导。例如，“工作人员用Word写标 书”这样的说法好像可以接受，但是如果按照说话的文字不假思索画出图4-20,就看出责任分配好像不对。

Word无法承担写标书的责任，这个软件系统里应该没有任何一句代 码提到“标书”的概念，只有“文档”“段落”“字体”等概念。当前编辑的文档到底是标书还是黄色小说，工作人员的大脑才知道，应该改为：

要描述清楚现状，才能找到需要的改进方案，以及系统需求 ​

黑格尔有一句经常被误解为“存在即合理”的名言--“凡是合乎理性的东西都是现实的；凡是现实的东西都是合乎理性的。”现状之所以存在，必定有其存在的原因，毕竟大家都不傻！一定要在尊重现实背后的理性的前提下再去改变，贸然改变很可能得不到好结果。

鲁迅曾经长叹“即使搬动一张桌子，改装一个火炉，几乎也要血”。但是从另一个角度想一想，桌子为什么摆在那里？火炉为什么是这个样子？

尽力描绘出真实的现状，说起来非常简单，做到却极其困难。为了克 服困难，建模人员甚至应当在心里暗暗发誓:如果不尽力去靠近真相，天打雷劈！

我是创新，没有现状，不需要现状需求用例 ​

互联网创业公司的建模人员很容易犯这个错误，动不动就说“我做的是互联网创新，没有现状！”

第2章已经说过，老大的大脑就是战场，敌人已经挤得满满当当。老大的时间和金钱是有限的，要让老大赏脸接纳某个系统，必定要动现状某个地方的蛋糕。老大不会因为“好新鲜，没见过这样的东西”就欣然接纳，这个“新”东西必须表现出比现状的某个方面好才行。

创新没什么了不起和神秘的，所有需求工作都是创新。有的时候，创业者号称“创新”的东西，只是创业者自己没做过，觉得“新”而己，客户早就见过了。如果是这样，创业者找块豆腐撞死算了。

改进业务序列图，找到系统竞争力 ​

改进模式一：物流变成信息流 ​

改进模式二：改善信息流转 ​

改进模式三：封装领域逻辑 ​

改进模式一：物流变成信息流

和信息的光电运输比起来，用其他手段运输的物的流转速度就显得太慢了，而且运输成本会随着距离的增加而明显增加。如果同类物的不同实例之间可以相互取代，那么可以提炼物中包含的部分或全部有价值的信息，在需要发生物流的地方，改为通过软件系统交换信息，需要物的时候再将信息变成物，这样可以大大增加流转速度和降低流转成本，

例如，市民要了解新闻，可以去报摊买报纸看，但这会产生各种物流，如果把报纸中包含的有价值信息提炼出来，通过软件系统传送，各种物流就消失了，如图4-40所示。

过去二三十年的信息化改进主要着力点就是物流变成信息流。这方面改进对人类社会已经产生了明显的影响。现钞用得越来越少，信件被电子邮件、短信、QQ和微信取代，照相胶卷已经绝迹，人们口中的“文件” 默认的不再是纸质文件。

了解了改进一，我们在观察业务流程时，要注意观察各种物的流动，并提炼物背后承载的信息。注意，不要忘了还有人的流动，人可是一个几十千克的物。例如，从图4-40的左侧，可以发现这么几个物流: 市民从家里挪到报摊再挪回家里，钞票从家里挪到报摊，报纸从报摊挪到家里。

除了信息化起步较晚的领域之外，目前各领域在“物流变成信息流” 方面留下的改进空间已经不多。随之而来要面对的是信息流转不通畅的问题。

改进模式二：改善信息流转

软件系统越来越多，而各个软件系统之间沟通不畅，导致一个人为了达到某个目的可能需要和多个软件系统打交道，如果把各软件系统之间的协调工作改为由一个软件系统来完成，人只需要和单个软件系统打交道， 信息的流转就改进了，如图4-41所示。

如图4-42所示，调度科为了出一份报表，不得不在多个业务实体之间疲于奔命(虽然可能只是鼠标在奔)，在中间插入新系统之后，工作量减 OK 126软件方法(上):业务建模和需求(第2版) 少了很多，如图4-43所示。

了解了改进二，我们在观察业务流程时，要注意观察信息流转不通畅的地方，特别是一些隐蔽的地方。很多人和人的协作中，可能隐藏了信息流转不畅的情况。如图4-44所示，专员请求经理审核活动计划，计划是一份电子文件，不离开座位就可以传递，不存在改进一，但是如果更仔细地观察，会得到图4-45,就可以知道存在改进二。如果不影响最终的改进方案，可以不用画出下一个级别的细节，画出图4-44即可。

改进模式三：封装领域逻辑

在业务流程中，有很多步骤是由人脑来判断和计算的，领域逻辑封装在人脑中。相对于计算机，人脑存在成本高、状态不稳定、会徇私舞弊等问题。如果能够提炼人脑中封装的领域逻辑，改为封装到软件系统中，用软件系统代替人脑，业务流程就得到了改进。

封装领域逻辑的改进如图4-46所示。

如图4-47左侧，思考和计算由销售员负责，组织需要雇用许多有一定经验的销售员，成本相当高。如果能够把销售员大脑中的经验提炼出来， 封装到软件系统中，如图4-47右侧所示，组织的成本就降下来了。

了解了改进三，我们在观察业务流程时，要注意观察和揣摩人脑中的逻辑，特别是有经验的“老司机”大脑里的逻辑。不过这有一定的难度， 我看过许多人画的业务流程像白开水一样，科长审批，处长审批，局长审批，没有内心活动，好像这些人只是个审批机器。

目前面向大众的互联网(及移动互联网)系统如微信、Facebook、 第4章业务建模之业务序列图129 >C Twitter，完成的大多是改进一和改进二，系统内部封装的逻辑不复杂。经常可以看到这样的场面:稍有新意的互联网系统刚面世，很快就出现几十上百个功能几乎一模一样的模仿者，这些模仿者中有的甚至是几个大学生凑一凑就开发出来的。谁成谁败，决胜点根本不是系统本身的功能，而是谁能早点多点拿到投资来购买内容和大做宣传，风险投资人也声称“投资是投人不是投产品本身”。

说到这里，我要啰唆几句。近年来，互联网公司的开发人员霸占了各种技术大会的讲台。他们在台上大谈互联网思维和敏捷，在台下听讲的是在电力、税务等行业钻研了十几二十年的研发负责人。乍听，这不就是瞎搞，不就是二三十年前的作坊式开发嘛！不过别不服气，人家公司在美国上市圈了好多钱，而且自身也在盈利！这样的成功事实让台下的研发总监开始反思:人家“瞎搞”，赚这么多，我们一年辛辛苦苦，赚这么点，好，回去马上引进互联网思维，把我们的研发流程互联网化、敏捷化！

这样的反思犯了一个逻辑错误:把并存当作因果。“瞎搞”是事实， “成功”也是事实，但不能得出结论“因为瞎搞，所以成功”“只要瞎搞，就能成功”或者“只有瞎搞，才能成功”。很可能该互联网公司的背景、人脉以及烧的钱才是公司成功的原因，至于公司里的软件开发团队采用什么开发方法，是站着、坐着还是倒立着开发，都不是主要影响因素。

有一天，张三喝醉酒后去买彩票，结果中奖两个亿。大家请张三上台介绍致富经验，张三介绍“我那天喝醉了酒去买彩票就中奖了”，台下听讲的彩民纷纷去喝醉买彩票，以为这样就能中大奖，这就犯了同样的逻辑错误。张三之所以能中大奖，背后肯定有原因，只不过这个原因很复杂， 属于“上帝算法”，人类目前还算不清楚(否则借来算一下明天双色球多好)，偶尔会归因为“祖上积德”之类，但应该不是喝醉了酒。

可惜，不少演讲人为了往自己脸上贴金，把并存混淆成了因果-“我们网站很成功，我们网站用PHP开发，所以PHP是最好的语言。”

中央纪委监察部网站、12306网站，访问量非常大，而且访问者忠诚度极高。到底用了什么方法和开发平台，能做出这么棒的网站？可惜，这些网站的研发负责人似乎比较低调，没有出来揽功，因为他们知道自己的贡献是多少。

可能有人要说“某某网站要应付这么多用户，背后技术门槛也不低”。我们再拿张三中奖的故事类比。张三中两亿大奖，必须纳4000万所得税。李四看到了张三中奖和纳税4000万的过程，于是预交了4000万给税务局再去买彩票，那么，李四的中奖概率会大大提高吗？

纳税是中奖带来的“快乐的痛苦”，不是中奖的原因。互联网公司的很多开发人员属于“纳税型”，是公司的成功带来了他，他却误以为自己带来了公司的成功。所以不要再拿“没有我们，就没法应付双11”来说事了，有几个网站因为用户太多倒闭的？倒是不少网站准备好了应付上亿用户，偏偏大家就是不用你。

专注于一个领域的行业软件，凝结了该行业的丰富领域知识，达到了改进三。这样的系统就能够靠软件本身的功能挣钱，它的开发团队介绍的经验值得借鉴。不过，开发这种系统的公司往往是“隐形冠军”，在它所处的领域大名鼎鼎，在大众媒体却无声无息。

不过，随着互联网跑马圈地的技术，互联网公司逐渐变成了行业巨头，领域逻辑需要越挖越深，改进三所占的比重越来越大。这方面的讨论会在第8章继续。

用阿布思考法得到一个当前最好的方案 ​

在软件开发团队中，当有人提出新的想法时，经常会被马上否定“这太难了，这做不了”，最终得到一个平庸的、毫无竞争力的系统。学会像阿布一样思考，有助于克服普通人因资源受限而不敢展开想象的思维障碍。阿布思考法分两步:

(1)假设有充足的资源去解决问题，得到一个完美的方案；

(2)用手上现有的资源去山寨这个完美方案。

如果有一个方案，花费完美方案1%的资源，能达到完美方案20%的效果。这个方案已经是目前最好的方案了，因为它是在突破思维限制以后一步步往后退得来的。

系统是能独立对外提供服务的整体 ​

系统执行者的定义：在所研究系统外，与该系统发生功能性交互的其他系统。

系统是能独立对外提供服务的整体

封装了自身的数据和行为，能独立对外提供服务的东西才能称为系统。不了解这一点，建模人员很容易把“添加一些功能”当作“研发新系统”。如图5-1所示，系统对外提供了某些服务，这些服务被分为A和B两组，但不能说有A和B两个系统。这个错误其实就是“从需求直接映射设计”的错误，如果没有很好理解第1章所阐述的“需求和设计的区别”， 建模人员很容易犯这样的错误。

系统的业务流程图 交互是功能性的交互。 ​

上面说的交互还引出一个问题:假设售票员使用鼠标和售票系统交互，按道理，比起售票员来，鼠标离售票系统更近，为什么不把鼠标作为售票系统的执行者呢？还有，假设售票系统运行在Windows操作系统之上，那么Windows是不是售票系统的执行者？

辨别的要点就是:执行者和系统发生的交互是系统的功能需求。如图， 5-9上部的序列图所示，售票员能自如地辨认并控制鼠标，是因为她的大脑里安装了如何使用鼠标的专家系统(可能是老师，也可能是父母安装的)。 猴子的大脑里没有这个系统，所以它很可能看到鼠标就一把抓起来往嘴里送。鼠标的移动和点击如何变成有效的输入事件，则由操作系统(包含了鼠 第5章需求之系统用例图151-吴 标驱动程序)负责。以上这些交互都不是售票系统的核心域概念，售票员和售票系统之间的交互才是，所以售票员才是售票系统的执行者。

系统用例的定义：系统能够为执行者提供的、涉众可以接受的价值。 ​

价值是买卖的平衡点 ​

系统用例的定义:系统能够为执行者提供的、涉众可以接受的价值。 和第3章的业务用例相比较，研究对象从组织变成了系统。要理解好系统用例，重点依然是之前所强调的买卖平衡点、期望和承诺平衡点。

以ATM为例，“储户→登录”不是它的用例，因为储户对ATM的期望以及ATM能做的承诺不只是登录。或者这样思考，ATM不能这么叫卖: “来啊来啊！我这里能登录啊”，然后储户就说“哇，真棒，这正是我想要ATM提供的服务，好，我去用一用”。

或者可以设想可能观察到的场景:

张三要出差，发现身上没现金，到ATM那里取现金，然后离开ATM忙别的去了。

客户给张三卡里转了5000元，电话请张三查收，张三到ATM那里看看自己的卡当前余额多少，脑子里想想是不是比之前多了5000元，然后离开ATM忙别的去了。

以上两个场景在典型的业务流程中可以观察到，而下面的场景就比较离谱了:

************,张三到ATM那里登录，然后离开ATM忙别的去了。

所以，ATM正确和错误的用例如图5-13所示。

用例之前的许多需求方法学，把需求定义为思考系统“做什么”， 用例把需求提升到思考系统“卖什么”的高度。这种思考是非常艰难的， 因为它没有标准答案，只有最佳答案。要得到这个最佳答案，不能靠拍脑袋，必须揣摩涉众。要得到合适的用例，需要有一颗善于体察他人的心。 如果建模人员总是习惯于从自己的角度想问题，那么让他思考“什么是系统应该提供的价值”有时甚至会让他痛苦到想要逃避，或者干脆用功能、 特性等模糊不清的词语代替。

但是逃是逃不开的，生活中处处都需要这样的思考。人们求职、求偶不就是要搞清楚“我”这个人脑系统应该卖给谁，卖什么服务的最佳答案吗？ 我会吃喝拉撒，你不愿意为此给我报酬；你想要长生不老，我又提供不了这么大的价值。要找到一个我能干好而且你又乐意买单的平衡点，确实很难。

程序员的用例是编代码，不是赚钱 ​

例如，“程序员”这个人脑系统为它的老板提供的用例是什么？安装开发工具？编码？为公司赚钱？答案是编码，这是老板对程序员的期望以及程序员可以提供的承诺的平衡点，或者说，这是程序员能卖、老板愿意买的价值。程序员不能因为装了个Visual Studio就理直气壮地向老板要报酬，老板不给就生气；程序员按要求编出了代码，老板就不能因为销售部门不给力或经济崩溃导致赚不到钱而责怪程序员。正确和错误的用例如图5-14所示。

程序员如果摆错了自己的位置，没有好好完成编码的本职工作，反倒是动不动向老板上“万言书”，对公司的发展方向大放厥词，老板是不会喜欢的，因为他不期望从程序员身上“购买”这个服务(用某知名企业领导人的话说就是:有精神病就送医院，没精神病就辞退)。

可见，搞清楚自己的“用例”，认清自己的定位，对人生多么重要。 如果您不断通过用例思维来思考系统的价值，就能训练出越来越强大的发现价值的能力。无论打工还是创业，这种发现价值的能力都可以让您受益。

用例的命名是动宾结构 ​

用例的命名是动宾结构，例如“取现金”。动词前面可以加状语，宾语前面可以加定语，把一句话的主语砍掉，剩下的可以作为用例的名字。

给用例起名时不要使用弱动词。用例之前的需求技术，可能是以“名字+-动词”的形式命名系统的功能，例如“发票作废”，后来要改成用例的动宾结构了，有的建模人员就在前面加一个弱动词“进行”，就变成了“进行发票作废”，这个也是不合适的。

如果“名词+动词”已经成为行业中的一个术语，也未必要严格的动宾结构。例如“成果分析”在某行业是一个术语，也就不必硬要倒过来变成“分析成果”了。

需求之系统用例规约，用例规约怎么划分 ​

用例图表达了用例的目标，但是对于完整的需求来说，这是远远不够的。用例的背后封装了不同级别的相关需求，我们需要通过书写用例规约把这些需求表达出来。用例规约就是以用例为核心来组织需求内容的需求规约。有了用例规约，可以不需要另外写其他格式的需求规约。用例规约的各项内容用类图展示如图6-1所示。

图6-1的各项内容中，执行者和用例在用例图中已经存在，照搬到用例规约中就可以。剩下的内容用例图上没有，需要另行添加。目前UML 并未包含用例规约的表示法。过去常见的做法是用Word等文字处理器来书写用例规约，不过扁平文本形式难以高效建立和维护用例各项内容之间的关系。现在已经有专门用于编写用例规约的工具，例如Case Complete, Visual Use Case等，而且越来越多的UML建模工具也开始提供编写用例规约的功能，使得需求人员能够以“立体”的方式来书写和保存用例规约， 并以文本、图形、表格等各种视图查看或输出，

需求之系统用例规约中常见的错误 ​

举例一些常见的“胡说八道”的例子：

错误示例	评价
会员打开系统	用手撕开？
会员进入系统	像黑客帝国一样脑门插插头进去？
系统自动计算订单总价	系统当然是自动的
会员手动输入订单信息	会员当然是手动的
会员提交订单信息给系统	“给系统”冗余

系统用例规约，一个很牛逼的正经的系统用例规约的例子 ​

结合愿景，我们可以推测“助理→创建公开课”这个用例优先级应该最高。

它的用例规约如下:

用例编号:UC1

用例名:

创建公开课

执行者: 助理(主)、官网服务器(辅)、微信公众号系统(辅)

前置条件: 无

后置条件:

已请求官网服务器接收公开课网页文件

已请求微信公众号系统发布公开课消息

公开课信息以及发布情况已保存

涉众利益:

专家--担心公开课通知中涉及自己的信息不准确，损害自己的声誉

学员--担心收到太多和自己不相关的信息；担心同样的信息收到多次

助理--担心工作量大；担心网页文件放到服务器错误的位置；担心公众号当日发送指标已经用完

官网服务器管理员--担心自己维护的系统受影响发生故障

微信公众号系统管理员--担心自己维护的系统受影响发生故障

基本路径:

1.助理请求开始创建公开课

2.系统反馈可以开课的课程主题

3.助理选择课程

4.系统反馈课程详细信息并要求补充其他公开课信息 第6章需求之系统用例规约227

5.助理提交公开课信息

6.系统验证公开课信息充分、合法

7.系统保存公开课信息，生成并保存公开课网页

8.系统请求官网服务器接收文件

9.系统请求微信公众号系统发布消息

10.系统保存公开课发布情况

11.系统反馈公开课发布情况

扩展路径:

2a.没有可以开课的课程:

• 2al.【创建课程】
• 2a2.返回4

6a.公开课信息不充分或不合法:

• 6al.系统反馈公开课信息不充分或不合法内容
• 6a2.返回5

字段列表:

4.课程详细信息一课程主题+学员对象+专家介绍+课程大纲+费用+(报名联系方法}+{交费方法

5.提交公开课信息-4+开始时间+结束日期+城市

7.保存的公开课信息=5+期号+创建时间+创建人

8.网页信息同5

10.公开课发布情况=发布时间+网页文件位置+官网发布是否成功+微信公众号系统发布是否成功

业务规则:

6.充分规则:5中所有信息都需要；

6.合法规则:结束日期必须在开始日期之后；尚不存在课程相同且举办日期和输入日期重叠的公开课；各项信息内容无敏感词；

7.期号规则:该课程最近成功举办的那一期的期号+1

质量需求:

无

设计约束：

无

和涉众交流的形式应该采用视图，而不是模型 ​

涉众没有资格提出需求的 ​

理解以下两个要点，有助于克服需求启发中的障碍。

(1)和涉众交流的形式应该采用视图，而不是模型

经常有人问:客户看不懂UML怎么办？这个问题本身就存在问题。 提问者潜意识里可能认为“客户”是一个人。所谓“客户”其实是一大堆“涉众”，他们从事的工种不同，学历职位有高有低，年龄有大有小，健康有好有坏，关注的利益更是各自不同，怎么能寄望用一种介质和所有的涉众沟通？ 第1章说过UML的优点是提高沟通的效率，还拿五线谱做了类比。五线谱是音乐专业人士交流的工具，作曲要懂、编曲要懂、乐手要懂、指挥 一246软件方法(上):业务建模和需求(第2版) 要懂、歌手要懂(注意:是懂五线谱，不是人人都要用五线谱作曲)，但听音乐的不需要懂五线谱。同样地，UML只是在“软件开发人员”圈子里面的统一表示法，基于UML的沟通主要是发生在开发团队内部，不能强行拿着UML模型和涉众沟通。

那么，和涉众交流的介质是什么呢？不是需求模型本身，而是需求模型的各种视图。面对大领导，我们可以给他放幻灯片交流愿景；中层干部喜欢看文档，我们可以按照他喜欢的格式给他炮制文档；一线操作工只关心他那一小块工作，我们可以制作界面原型和他交流；有时候甚至有的涉众根本不喜欢看任何东西，我们还可以通过“谈话”这种视图和他交流。 涉众连谈话都不乐意，我们也可以通过观察来获取素材。需求启发的技能有许多种，不仅仅是浅薄的“画个界面草图给用户看”，“问用户想要什么功能”。许多伟大的创新正是有心人在涉众不作声的情况下，观察涉众的行为得到的。

如果不了解这个区分，直接拿UML模型去和涉众交流，很容易导致“四不像”。为了迁就不同涉众的知识水平，开发团队只好损害模型的严谨性，即使是这样，涉众也不一定接受，交流效果还是不好，而且还会因为涉众的交流形式多变而影响开发团队开发过程的稳定-双方都受害。 客户的领导说，我不习惯看UML模型，就知道以前看的是××标准格式的文档，我只在这个格式的文档上签字，难道我们就不用UML建模了？下一个项目的客户领导喜欢另一种格式怎么办？下下个项目根本不需要签字怎么办？大众产品没有“客户领导”签字确认需求怎么办？不少开发团队十年如一日没有进步和积累，“交流影响开发”是原因之一。

开发人员有意无意把建模的目的理解成和涉众交流，有时背后的思想还是“懒”字，因为这样想，就有了推卸责任的机会:不是我不想建模， 就算我建模了，客户不想看啊。

需求视图和需求模型分离，交流和建模分离。在面对不同涉众时，需求人员可以灵活使用各种启发方式，见人说人话，见鬼说鬼话；回到开发团队内部时，则改用专业手段交流，这样团队才能慢慢形成稳定、严谨的开发过程(见图7-1)。

(2)和涉众交流的内容应该聚焦涉众利益，而不是需求

软件的需求规约相当于电影剧本。电影剧本不是由观众直接提供，而是由编剧根据不同观众的口味编出来的。同样，软件需求不是由涉众直接提供的，而是由需求人员综合不同涉众的利益来决定的。涉众没有资格， 也没有责任提供需求。

**首先，涉众没有资格提供需求。**系统的需求是平衡各种涉众利益得到的，不由单一涉众决定。以ATM机为例，如果需求人员询问ATM机的执行者储户“取款机应该怎么做你觉得最好”，储户回答大实话“最好像我家抽屉一样拉开就拿，喏，把我家里的抽屉拿去做原型”，需求人员显然不能把这个“抽屉”当真，只需要把“抽屉”背后的涉众利益提炼出来储户希望操作次数尽可能少一些。最终系统的需求是否尊重这个利益，就要看储户在涉众排行榜上的排位了。

**其次，涉众没有责任提供需求。**涉众可能很忙，可能没有能力。说得极端一点，婴儿只会哭会笑，婴儿产品的需求就不用做了？需求人员还是要把责任揽过来，涉众只需表达高兴不高兴就行了。

不了解“交流的内容聚焦于涉众利益”，需求人员很容易把涉众提出 的解决方案当成需求，或者抱怨涉众没有“说清楚需求”。

拿患者和医生类比可以帮助理解上面说的这两点。患者喜欢和医生交流自己的磁共振成像，医生就给他多做磁共振检查？患者懒得看甚至昏迷不醒，医生就干脆不做？患者说“我腿疼，可能得了腿癌，我要做放疗”，医生就给他做放疗？

显然不是这样，医生应该按照成熟的治疗套路，该做什么检查就做什么检查，该如何治疗就如何治。医生哄不肯吃药的小患者“来，叔叔给你吃颗糖糖”，但回到办公室和护士却要说“我刚给某某患者用了多少量的某某药，你记一下”。

需求启发的要点的一个障碍是知识的诅咒 ​

需求启发要点

许多时候，需求人员把需求启发想得太容易。经常可以听到“采集需求”这样的表述，好像需求是蘑菇，乖乖地躺在森林里，开发人员需要时，就像采蘑菇小姑娘一样，一个，两个，三个，四个....把它们都采 回来。哪有这么容易！需求不是蘑菇。需求人员要能够像猎人一样，用锐利的眼睛发现隐藏在丛林中的猎物；像侦探一样，用缜密的思维判断出伪装成好人的凶手。

需求的一个启发障碍是知识的诅咒(Curse of Knowledge),意思是: 一旦知道某个东西，就很难想像不知道它会是什么样子。1990年，斯坦福大学研究生Elizabeth Newton做了一个著名的心理学实验:让敲击者在桌子上敲击最常见的歌曲，听众根据听到的节奏回答是什么歌曲，然后让敲击者估计听众答对了多少。120次的实验中，敲击者预测听众猜对的比率会大于50%,真实的结果是听众猜对的比率只有2.5%。因为听众听的是敲出来的声音，敲击者听的是大脑里已有的歌曲。

知识的诅咒在需启发中体现为沟通的困难。需求人员懂得许多软件实现的知识，这些知识会有意无意地引导开发人员从实现的角度看需求； 涉众在领域里面工作多年，许多事情在他看来一目了然，很难用开发人员能理解的言语表达出来。

需求启发的另一个障碍是做和定义的不同。涉众会做一件事情，不代表他能够把这件事定义出来教给其他人。在足球领域，贝利和马拉多纳号称球王，但他们的执教经历并不成功，最近十年的世界最佳主教练穆里尼奥踢球水平却很一般。

需求启发 ​

• 需求启发的手段
  • 研究资料
  • 问卷调查
  • 访谈
  • 观察
  • 研究竞争对手
• 需求人员的素质培养
  • 好奇心
  • 探索力
  • 沟通力
  • 表达力
  • 热情