前言2015版
每当变幻时，便知时光去。
《每当变幻时》；词：卢国沾，曲：古贺政男，唱：薰妮；1985
《软件方法（上）》出版至今的两年里，学员和读者不断给我提供反馈，我在给软件组织服务的过程中也有一些进步。这一次的改动较多，
所有为本书纠错的读者：Cliff Peng、Tiger Gm、绿豆稀饭、Casper张、吴俊峰、Bright Zhang、商雪飞、李云、杨建媛、李勇、Leo Huang、张攀、张艳梅、gs0987、Timothy Yeh、深蓝二号、毛灵、陈小青、钟正权、吴刚、许跚、半导体、穆明明、王涛、赵卫、孙晓晔、黄明哲、辛恩平、杜宁军、徐波、徐天保、张云贵、Lyla、汤晓冬、魏光裕、贾顶忠、叶青、涂文军、石碧川、李秀涛、黄保光、周进刚、吴佰钊。
推荐阅读
张生带上仆人阿梁，挑着圣贤书两大箱
《张生记》；词：高晓松，曲：高晓松，唱：曹颖；2006
本书的内容是根据我为开发团队提供服务的训练资料扩展而成的。在为开发团队提供服务时，我一直采取拿来主义的做法，不拘泥于流派或风格，着力于细节和应用。如果硬要说出本书的几个主要思想来源，我认为应该是Ivar Jacobson、Alistair Cockburn、Peter Coad和高焕堂。
下面给出我印象深刻的、推荐阅读的需求和设计书籍。需求和设计书籍只要有中文译本或者英文版能有渠道找到电子版，绝大多数我都阅读过。我没有阅读过的书，就没有资格在此处推荐了，但不意味着我认为这些书不值得阅读。您可能会发现，一些经典著作如Brooks的《人月神话》、GoF的《设计模式》等不在其中，那并不是因为我没有读过，只是我认为，对于需求和设计技能的提升，阅读以下推荐的资料帮助更大。
另外要说的是，要用发展的眼光看问题，不能搞“原教旨主义”。某种思想或方法起源于某人，不意味着某人最初对该思想或方法的认识永远是最正确的，也不意味着某人在以后的岁月中针对该思想或方法发表的各种观点都是正确的。Ivar Jacobson的“Object-Oriented SoftwareEngineering”出版于1992年，Peter Coad的“Java Modeling In Color With UML”出版于1999年，Alistair Cockburn的“Writing Effective UseCases”出版于2001年。不否认这些书中思想的光芒，但毕竟世界在进步，在实践的大浪淘沙之下，有些细节值得商议。小教派式的“教主崇拜”，由一些编辑捧出来的圈子文化以及廉价“大牛”、“大仙”、“大神”式的称呼，不值得提倡。鉴于此，本书不会称呼先行者们为“大师”、“大牛”、“大仙”、“大神”，我想他们的贡献不会因此埋没。
《软件复用：结构、过程和组织》，Ivar Jacobson 著，韩柯 译，机械工业出版社，2003。
《用例：通过背景环境获取需求》，Daryl Kulak 著，韩柯、杨柳青译，机械工业出版社，2004。
《编写有效用例》，Alistair Cockburn 著，王雷、张莉 译，机械工业出版社，2002。
《有效用例模式》，Steve Adolph, Paul Bramble 著，车立红译，清华大学出版社，2003。
《探索需求——设计前的质量》，Donald C. Gause, Gerald M.Weinberg 著，章柏幸、王媛媛、谢攀 译，清华大学出版社，2004。
《掌握需求过程(第3版)》，Suzanne Robertson, James Robertson 著，王海鹏译，人民邮电出版社，2014。
《定位》，Al Ries, Jack Trout著，李正栓、贾纪芳 译，中国财政经济出版社，2002。
《严肃的创造力》，Edward De Bono 著，杨新兰 译，新华出版社，2003。
《历史深处的忧虑》，林达 著，三联书店，1997。
《为什么是市场》，秋风 著，中信出版社，2004。
《实用面向对象软件工程教程》，Edward Yourdon, Carl Argila 著，殷人昆、田金兰、马晓勤译，电子工业出版社，1998。
《对象模型：策略、模式与应用（第2版）》，Peter Coad 著，唐毅宏 译，科学出版社，2005。
《彩色UML建模》，PeterCoad, Eric Lefebvre, Jeff De Luca 著， 王海鹏 译，机械工业出版社，2008。
《分析模式：可复用的对象模型》，Martin Fowler 著，樊东平、张路译，机械工业出版社，2004。
《Oracle 8 UML对象建模设计》，Paul Dorsey，Joseph R.Hudicka著，孟小峰 等 译，机械工业出版社，2000。
《数据模型资源手册（修订版）卷1》，LenSilverston 著，林友芳 等 译，机械工业出版社，2004。
《数据模型资源手册（修订版）卷2》，LenSilverston 著，林友芳 等 译，机械工业出版社，2004。
《MDA与可执行UML》，Chris Raistrick,Paul Francis,John Wright 著，赵建华、张天 等译，机械工业出版社，2006。
《领域驱动设计》新译本，Eric Evans 著，赵俐、盛海艳、刘霞 译，人民邮电出版社，2010。
《对象设计》，Rebecca Wirfs-Brock, Alan McKean 著，倪硕、陈师译，人民邮电出版社，2006。
《企业应用架构模式》，Martin Fowler 著，王怀民、周斌 译，机械工业出版社，2010。
《面向模式的软件架构》1-5卷，FrankBuschmann 等 著，袁国忠 等 译，人民邮电出版社，2013。
《程序设计的模式语言》1-5卷，JamesO.Coplien 等 著，谢文亮 等 译，人民邮电出版社，2006。
《设计模式初学者指南》，Allen Holub 著，徐迎晓 译，机械工业出版社，2006。
《UML状态图的实用C/C++设计》，Miro Samek 著，anymcu 译，http://sourceforge.net/projects/qpc/files/doc/PSiCC2-CN.pdf/download，2010。
《UML参考手册 （第2版）》，James Rumbaugh, Ivar Jacobson, Grady Booch 著，UMLChina 译，机械工业出版社，2005。
《OMG Unified Modeling Language Version 2.5》, Object Management Group 制订，http://www.omg.org/spec/UML/2.5/PDF，2015 。
《UML对象、组件和框架——Catalysis方法》，Desmond Francis D’Souza, Alan Cameron Wills 著，王慧、施平安、徐海译，清华大学出版社，2004。
《Object-Oriented Software Construction (2ndEdition)》，Bertrand Meyer 著，PrenticeHall，1997
《Working With Objects:The OOram SoftwareEngineering Method》，Wold Reenskaug、Trygve Reenskaug、O. A. Lehne著，Prentice Hall，1996
《UML精粹（第3版）》，Martin Fowler 著，UMLChina 译，电子工业出版社，2012。
第1章 建模和UML
牵着你走进傍晚的风里，看见万家灯火下面平凡的秘密
《情歌唱晚》；词：黄群，曲：黄群，唱：曹崴；1994
1.1 粗放经营的时代已经远去
中国刚改革开放时，出现了许多农民企业家，他们不用讲管理，也不用讲方法，只要胆子大一点，就能获得成功，因为当时的市场几乎空白，竞争非常少。农民企业家思路很简单：人人都要吃饭，所以开饭馆能够赚钱。现在这样的思路已经行不通了，市场竞争已经足够激烈，十家新开张的饭馆恐怕只有一家能撑下来，所以农民企业家已经很少见（连农民都越来越少了）。软件开发行业也一样，最开始的时候，会编程就了不得，思路也很简单：每个公司都要做财务，所以开发财务软件能赚钱。现在呢？我们每想到一个“点子”，可能有上千人同时想到了；我们要做一个东西，可能发现市场上已经有许多类似的系统。你卖高价，他就卖低价，你卖低价，他就干脆免费。机会驱动、粗放经营的时代已经远去，为了在激烈的竞争中获得优势，软件开发组织需要从细节上提升技能。
本书聚焦于两方面的技能：需求和设计。关于需求和设计，开发人员可能每天都在做，但是否理解背后的道理呢？我们来做一些题目：
访问http://www.umlchina.com/book/quiz1_1.htm完成在线测试，做到全对以获得答案。
1. 软件开发中需求工作的目的是 A)让系统更加好卖 B) 更好地指导设计 C) 对系统做概要的描述 D) 满足软件工程需求规范 |
2. 软件开发做设计工作的目的是 A) 对系统做详细的描述 B) 更好地指导编码 C) 降低开发维护成本 D) 满足软件工程设计规范 |
3. 开发人员说“根据客户的需求，我们的系统分为销售子系统、库存子系统、财务子系统...”，这句话反映了开发人员可能有什么样的认识错误？ A) 开发人员没有认识到面向对象设计的重要性 B) 开发人员直接从设计映射需求 C) 开发人员直接从需求映射设计 D) 开发人员没有用UML模型来描述子系统 |
4. 打开开发人员写的需求文档，发现用例的名字都是“学生管理”、“题库管理”、“课程管理”...，这背后可能隐藏的最大问题是什么？ A) 用例的名字不是动宾结构，应改为“管理学生”... B) 用例粒度太粗，每一个应该拆解成四个用例，“新增学生”、“修改学生”... C) 开发人员直接从需求映射设计 D) 开发人员直接从设计映射需求 |
1.2 利润＝需求－设计
利润＝收入－成本。不管出售什么，要获得利润，需要两个条件：（1）要卖出好价钱；（2）制造的成本要低。妙就妙在，价格和成本之间没有固定的计算公式，这就是创新的动力之源。放到软件业上，我也炮制了一个公式：
利润＝需求－设计
在软件开发中，需求工作致力于解决“增加销售”的问题，设计工作致力于解决“降低成本”的问题。二者不能相互取代。您能低成本生产某个系统，但不一定能保证它好卖。您的系统好卖，但如果生产成本太高，最终还是赚不了多少钱。
★高焕堂在[高 2008]中讲到：用例是收益面，对象是成本面。本书发展了他的思想。
如果需求和设计不分，利润就会缩水。从需求直接映射设计，会导致功能分解得到重复代码。如果从设计出发来定义需求，会得到一大堆假的“需求”。
拿自古以来就有的一个系统“人体”来举例。人体能提供的功能是会走路，会跑步，会跳跃，会举重，会投掷，会游泳……但是设计人体的内部结构时，不能从需求直接映射到设计，得到“走路子系统”、“跑步子系统”、“跳跃子系统”……。人体的“子系统”是“呼吸子系统”、“消化子系统”、“血液循环子系统”、“神经子系统”、“内分泌子系统”……。人体的“子系统”中很多是不能从需求直接映射出来的，需要设计人员的想象力。同样，也不能从设计推导出需求——因为人有心肝脾肺肾，所以人的用例是“心管理”、“肝管理”。
图1-1 人体的需求和设计
水店老板要雇一个民工送水（即租用一个人肉系统），他只要求这个民工能跑能扛就行，管他体内构造是心肝脾肺肾还是一块电路板；民工找工作也要从市场的要求来找，不能从自己的内部器官出发来找——“老板，我有心脏管理功能，你请我吧！”
很多时候我们说“本系统分为八大子系统……”，其实说的是“本系统的功能需求分为八大需求包……”需求包是从外部对系统功能所做的简单分包，子系统应根据部件的耦合和内聚切割得到。
我把需求和设计的区别简要列举如图1-2，后面的章节我再慢慢阐述这些观点。
需求 | 设计 |
卖的视角 | 做的视角 |
具体 | 抽象 |
产品当项目做 | 项目当产品做 |
设计源于需求，高于需求 | |
图1-2 需求和设计的区别
1.3 建模工作流
要迈向“低成本制造好卖的系统”的境界，并非喊喊口号就能达到，需要静下心来，学习和实践以下各个建模工作流中的技能：
1. 业务建模——描述组织内部各系统（人肉系统、机械系统、电脑系统……）如何协作，使得组织可以为其他组织提供有价值的服务。新系统只不过是组织为了对外提供更好的服务，对自己的内部重新设计而购买的一个零件。组织引进一个软件系统，和招聘一名新员工没有本质区别。如果能学会通过业务建模去推导新系统的需求，而不是拍脑袋得出需求，假的“需求变更”会大大减少。
2. 需求——描述为了解决组织的问题，系统必须具有的表现——功能和性能。这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众（Stakeholder）在意的、不能改变的契约，哪些不是，严防“做”污染“卖”。需求工作流的结果——需求规约是“卖”和“做”的衔接点。
3. 分析——提炼为了满足功能需求，系统需要封装的核心领域机制。可运行的系统需要封装各个领域的知识，其中只有一个领域（核心域）的知识是系统能在市场上生存的理由。对核心域作研究，可以帮助我们获得基于核心域的复用。
4. 设计——为了满足非功能需求和设计约束，核心领域机制如何映射到选定平台上实现。
到目前为止，我没有谈到UML。只要您思考过过上面这些问题，就是在建模，用口头、文本、UML、其他表示法或自造符号来表达都可以。而且我相信，每一个项目，我们都会思考和表达上面这些问题，只不过可能是无意识地、不严肃地做。现在，我们要学习有意识地做，把它做出利润来。使用UML来做是目前一个不坏的选择。
开发团队如果缺乏软件工程方面的训练，对这些工作流没有概念，就会把编码以外的工作通通称为“设计”或者“文档”。例如问开发人员在做什么，回答“我在做设计”、“我在写文档”，其实他的大脑可能正在思考组织的业务流程（业务建模），或者在思考系统有什么功能性能（需求），或者在思考系统要包含的领域概念之间的关系（分析），但他通通回答成“在做设计”、“在写文档”。后来又有牛人说了：代码就是设计。本来“设计”在他脑子里就是“代码以外的东西”，这么一推导，不就变成了：代码就是一切？
不少大谈“编码的艺术”的书籍、文章和博客也属于概念不清，文中探讨的根本不是编码的技能，而是分析技能甚至是业务建模技能。编码确实有编码的技能，就像医院里护士给患者输液也是技术活，但如果患者输液后死亡，更应该反思的是护士的输液手法不过关，还是医生的检查诊断技能不过关？
把工件简单分割为代码和文档（或设计），背后还隐含着这样的误解：认为模型（文档）只不过是源代码的另一种比较概要或比较形象的表现形式。这种误解不只“普通”的开发人员会有，一些著名的UML书籍作者也有。Martin Fowler所著的UML畅销书《UML精粹》，认为UML有三种用法：草稿、蓝图和编程语言，也是仅从编码的角度来说的。从Fowler写作的其他书籍《重构》、《企业应用架构模式》、《分析模式》等可以知道，他的研究工作集中在分析设计工作流，特别是设计工作流，不了解他在业务建模和需求方面有多少研究。鉴于Fowler在某些社群的心目中如大神一般存在，此处专门提到了他。
不同工作流产生的工件之间的区别不在于形式，而在于内容，也就是思考的边界，见图1-3。如果清楚了解这一点，即使用C#也照样可以表达需求，用Word也可以“编码”。
有的开发人员在这里思维刚好是颠倒的，先拍脑袋写出代码，然后再从结果反推前面的内容，例如下面的对话。 顾问：这个不应该是系统的用例。 开发人员：是的，我都写好了，运行一下给你看，这个系统确实提供了这个用例。 顾问：这两个类关系不应该是泛化，而是关联。 开发人员：是泛化，我打开代码给你看，或者逆向转出类图给你看。 （是否系统用例应该以“好卖”来判断，是否泛化关系应该以“是否符合领域内涵”来判断，而不是先写好代码，再用代码来证明） |
图1-3 建模工作流思考边界
一些不了解以上概念的开发团队干脆以“敏捷”、“迭代”为名，放弃了这些技能的修炼。就像一名从护士成长起来的医生，只掌握了打针的技能，却缺少检查、诊断、拟治疗方案等技能，索性说：“唉，反正再高明的大夫，也不能一个疗程把病人治好，干脆我也别花那么多心思了，先随便给病人打一针看看吧，不好再来！“迭代”只是一个底线，确实，再高明的大夫也没有把握一个疗程就治好病人，但是检查、诊断等技能越精湛，所需要的疗程就越少。不能把“敏捷”、“迭代”作为偷懒的庇护所。
唱曲的名家，唱到极快之处，吐字依然干净利落；快节奏的现代足球，职业球员的一招一式依然清清楚楚；即时战略游戏高手要在极短时间内完成多次操作，动作依然井然有序。在激烈竞争的年代需要快速应变，掌握技能才能真敏捷。世上无易事，偷懒要不得。
刚入行的开发人员体会不到建模的重要性，是正常的。就像下象棋，初学者面对单车对马双士、单马对单士等已经有共识的局面还需要思考良久，最终还拿不下来甚至输掉。这时中局和布局的书在他看来多半是枯燥无味的，还不如把一本实用残局汇编看熟了，学到一些雕虫小技，也能在菜市场赢几盘棋。不过，要迈向职业棋手的境界，参加更残酷的竞争，就体会到中局和布局的重要了。
访问http://www.umlchina.com/book/quiz1_2.htm完成在线测试，做到全对以获得答案。
1. 以下描述最可能对应于软件开发中的哪个工作流 每个项目由若干活动组成，每项活动又由许多任务组成。一项任务消耗若干资源，并产生若干工件。工件有代码、模型、文档等。 A) 业务建模 B) 需求 C) 分析 D) 设计 |
2. 以下描述最可能对应于软件开发中的哪个工作流 A) 业务建模 B) 分析 C) 需求 D) 设计 |
3. 以下描述最可能对应于软件开发中的哪个工作流 系统向会员反馈已购买商品的信息 A) 业务建模 B) 分析 C) 需求 D) 设计 |
4. 以下描述最可能对应于软件开发中的哪个工作流 某集团向优马神州经理提出举办讲座的请求后，经理根据请求决定请哪一位专家，并拟定讲座计划，交给组织工作人员执行。组织工作人员根据经理提供的专家资料通过Email、电话等各种方式联系专家，和专家商议讲座的时间和主题。 A) 业务建模 B) 分析 C) 需求 D) 设计 |
5. 如果问开发人员“你在做什么”，他说“我在写文档”，那么他有可能（本题可多选） A) 不了解软件开发各工作流的区别 B) 把自己的工作简单分为“代码”和“文档” C) 认为文档就是代码的叙述性文件 D) 知道“文档”和“代码”的真正区别是什么 |
5. 和本节评述“迭代”时所举医生治病的错误说法最不类似的是 A) 如果允许一次走两步，新手也能击败象棋大师 B) 百米短跑比赛才10秒钟，不可能为每一秒做周密计划，凭感觉跑就是 C) 即使拜仁巴萨也不能保证每次进攻都能进球，所以练习传球配合是没用的，不如直接大脚开到对方门前。 D) 虽然大家都考不及格，但考58分和考42分是不一样的。 |
