作者：潘加宇
出版社：清华大学出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
软件方法(上册)：业务建模和需求试读：
前言
1999年还是一名程序员时，我创建了UMLChina，从那时开始关注软件工程各方面的进展。2001年12月，阿里巴巴的吴泳铭来E-mail询问是否有UML方面的训练，我开始准备训练材料。2002年3月，我去杭州给阿里巴巴做了这个训练。虽然与后来我给阿里集团各公司做的许多次训练相比，这第一次讲课从内容到形式都算是糟透了，但是我现在还记得当时的心情——迈出自己事业第一步的心情。
截至目前（2013年7月），我已经上门为超过190家软件组织提供需求和设计技能的训练和咨询服务。训练结束后，学员们常会问：“潘老师，上完课后我们应该看什么书？”我总是回答：“先不用看杂七杂八的书，还是要复习我们留下的资料，那些幻灯片、练习题、模型就已经是最好的书了，按照改进指南先用一点点在具体项目上，带着出现的具体困惑和我讨论。”虽然一再这样强调了，有的学员还是经常情不自禁地拿着一本《××UML××》之类的书来问我问题，不管书上说得对不对。看来写在正式出版物上的效果就是不一样。
其实现在出书也不难，UMLChina一直在和出版社合作推介国外优秀的软件工程书籍，目前UMLChina的标记已经出现在三十多本软件工程书籍上。不过我一直没有自己写一本书，主要原因还是觉得积累不够，思考的深度也不够，对软件开发的认识还在不断变化。如果没有自己成型的东西，不能站在别人的肩膀上看得更远，只是摘抄别人的观点，这样的书有什么意义呢？
另外一个原因是，UMLChina后来采取了“隐形、关门”的策略，秉持“内外有别”的原则。我关闭了已经有4万多人的Smiling电子小组（也是为了降低某些风险），网站不再有公开的社区，在网站上也找不到“客户名单”，所有更细致的服务以非公开的方式对会员提供。在这种情况下，出一本书也不是那么迫切。
现在距离第一次提供服务已经超过十年，也有了一些积累，所以硬着头皮也要开始写书了。在这些年的服务过程中，和开发团队谈到改进时，我发现一个有趣的现象：很多开发团队（不是每个团队）或多或少都会有人（不是每个人）或明或暗地表达出这样的观点——自己团队的难处与众不同，奇特的困难降临在他们身上，偏偏别人得以幸免。
尽管UMLChina一直强调自己的服务是“聚焦最后一公里”，坚信每一个开发团队都会在细节上和其他团队有所不同，而且也应该有所不同，但很多时候，我还是感觉到，开发团队高估了自己的“个性”，低估了“共性”。本书就是归纳这样一些“共性”，作为我的一家之言，供大家参考。感谢曾经选择我的服务的伙伴们。他们一次次地给我机会来实践、发展和锤炼技艺，才有了这本书。
本书中所讲述的技能集合也是我本人身体力行的。例如，您可能已经注意到，为本书写推荐序的正是本书的“老大”，他不是什么大师专家名人，而是一名经历了入职、升职和创业，不断成长的软件开发人员。
在每个知识点，我会提供一些针对该知识点的自测题，除了文字版本，还有可以自行测试的Flash版本，请在出版社网站http://www.tupwk.com/downpage或http://www.umlchina.com下载。
一些书籍作者喜欢在书中每一章的开头放上和该章内容相关的一幅画或一句名人名言，我也效仿一下，不过没那么“高雅”——每章的开头放上和该章内容相关的一句歌词。
书中的模型图，如果是我为了讲解知识而画的，用的建模工具是Enterprise Architect 9.2；如果是截取真实模型的图片，可能会涉及各种工具。我不像Robert C.Martin那样，女儿已经长大到可以帮画插图，所以书中的手绘插图，我都自己用Wacom笔来画，可能丑了一些，请见谅。
欢迎您提供关于本书的任何反馈，我的邮箱是umlchina@gmail.com，QQ是2403816963，新浪微博是“UMLChina潘加宇”，也欢迎您经常访问www.umlchina.com。潘加宇2013.07
试试下面的测试题，看看您对UMLChina了解多少。
自测题
1.UMLChina网站成立于：
A）1997年 B）1999年
C）2001年 D）2003年
2.UMLChina网站一开始中文名字叫做：
A）软件工程之窗 B）系统分析员之窗C）中国UML播种机 D）UML中国
3.UMLChina曾经发行过一份电子杂志，名字叫做：
A）架构师 B）软件研发
C）非程序员 D）软件工程
4.《非程序员》一共发行了51期，总计为杂志翻译稿件最多的译者是：
A）透明 B）甄镭
C）刘庆 D）杨德仁
5.UMLChina现在的宣传口号是：
A）软件以用为本
B）建模带来竞争优势
C）软件以人为本
D）敏捷！敏捷！我要敏捷！
6.以下哪一本书上没有“UMLChina”几个字？
7.以下哪位专家没有在UMLChina做过网络讲座/网络交流？
A）Kent Beck
B）Martin Fowler
C）Grady Booch
D）Scott W.Ambler
E）Eric Evans
F）John Vlissides推荐阅读
本书的内容是根据我为开发团队提供服务的训练资料扩展而成的。在为开发团队提供服务时，我一直采取拿来主义的做法，不拘泥于流派或风格，着力于细节和应用。如果硬要说出本书的几个主要思想来源，我认为应该是Ivar Jacobson、Alistair Cockburn、Peter Coad和高焕堂。
下面给出我印象深刻的、推荐阅读的国内已出版中译本的书籍。需求和设计书籍只要有中文译本或者英文版能有渠道找到电子版，绝大多数我都阅读过。我没有阅读过的书，就没有资格在此处推荐了，但不意味着我认为这些书不值得阅读。您可能会发现，一些“经典”著作如Brooks的《人月神话》、GoF的《设计模式》等不在其中，那并不是因为我没有读过，只是我认为，对于需求和设计技能的提升，阅读以下推荐的资料帮助更大。
另外要说的是，要用发展的眼光看问题，不能搞“原教旨主义”。某种思想或方法起源于某人，不意味着某人最初对该思想或方法的认识永远是最正确的，也不意味着某人在以后的岁月中针对该思想或方法发表的各种观点都是正确的。Ivar Jacobson的Object-Oriented Software Engineering出版于1992年，Peter Coad的Java Modeling In Color With UML出版于1999年，Alistair Cockburn的Writing Effective Use Cases出版于2001年。不否认这些书中思想的光芒，但毕竟世界在进步，在实践的大浪淘沙之下，有些细节值得商议。小教派式的“教主崇拜”，由一些编辑捧出来的圈子文化以及廉价“大牛”、“大仙”、“大神”式的称呼，不值得提倡。鉴于此，本书不会称呼先行者们为“大师”、“大牛”、“大仙”、“大神”，我想他们的贡献不会因此埋没。《软件复用：结构、过程和组织》，Ivar Jacobson 著，韩柯 译，机械工业出版社，2003。《探索需求——设计前的质量》，Donald C.Gause，Gerald M.Weinberg著，章柏幸、王媛媛、谢攀 译，清华大学出版社，2004。《掌握需求过程（第2版）》，Suzanne Robertson，James Robertson著，王海鹏 译，人民邮电出版社，2007。《用例：通过背景环境获取需求》，Daryl Kulak 著，韩柯、杨柳青译，机械工业出版社，2004。《编写有效用例》，Alistair Cockburn 著，王雷、张莉 译，机械工业出版社，2002。《有效用例模式》，Steve Adolph，Paul Bramble 著，车立红 译，清华大学出版社，2003。《严肃的创造力》，Edward De Bono 著，杨新兰 译，新华出版社，2003。《定位》，Al Ries，Jack Trout 著，李正栓、贾纪芳 译，中国财政经济出版社，2002。《历史深处的忧虑》，林达 著，三联书店，1997。《为什么是市场》，秋风 著，中信出版社，2004。《实用面向对象软件工程教程》，Edward Yourdon，Carl Argila 著，殷人昆、田金兰、马晓勤 译，电子工业出版社，1998。《对象模型：策略、模式与应用（第2版）》，Peter Coad 著，唐毅宏译，科学出版社，2005。《彩色UML建模》，Peter Coad，Eric Lefebvre，Jeff De Luca 著， 王海鹏 译，机械工业出版社，2008。《UML面向对象设计基础》，Meilir Page-Jones 著，包晓露 等译，人民邮电出版社，2001。《分析模式：可复用的对象模型》，Martin Fowler 著，樊东平、张路译，机械工业出版社，2004。《Oracle 8 UML对象建模设计》，Paul Dorsey，Joseph R.Hudicka 著，孟小峰 等译，机械工业出版社，2000。《数据模型资源手册（修订版）卷1》，Len Silverston 著，林友芳 等译，机械工业出版社，2004。《数据模型资源手册（修订版）卷2》，Len Silverston 著，林友芳 等译，机械工业出版社，2004。《MDA与可执行UML》，Chris Raistrick，Paul Francis，John Wright著，赵建华、张天 等译，机械工业出版社，2006。《领域驱动设计》新译本，Eric Evans 著，赵俐、盛海艳、刘霞 译，人民邮电出版社，2010。《对象设计》，Rebecca Wirfs-Brock，Alan McKean 著，倪硕、陈师译，人民邮电出版社，2006。《企业应用架构模式》，Martin Fowler 著，王怀民、周斌 译，机械工业出版社，2010。《设计模式初学者指南》，Allen Holub 著，徐迎晓 译，机械工业出版社，2006。《嵌入式系统的微模块化程序设计——实用状态图C/C++实现》，Miro Samek 著，敬万钧、陈丽蓉 译，北京航空航天大学出版社，2004。《敏捷软件开发：原则、模式与实践（C#版）》，Robert C.Martin，Micah Martin 著，邓辉、孙鸣 译，人民邮电出版社，2008。《UML参考手册（第2版）》，James Rumbaugh，Ivar Jacobson，Grady Booch 著，UMLChina 译，机械工业出版社，2005。《UML对象、组件和框架——Catalysis方法》，Desmond Francis D’Souza，Alan Cameron Wills 著，王慧、施平安、徐海 译，清华大学出版社，2004。《UML基础、案例和应用（第3版）》，Joseph Schmuller 著，李虎译，人民邮电出版社，2004。《UML精粹（第3版）》，Martin Fowler 著，UMLChina 译，电子工业出版社，2012。第1章 建模和UML1.1 粗放经营的时代已经远去
中国刚改革开放时，出现了许多农民企业家，他们不用讲管理，也不用讲方法，只要胆子大一点，就能获得成功。当时的市场几乎空白，竞争非常少。农民企业家思路很简单：人人都要吃饭，所以开饭馆能够赚钱。现在这样的思路已经行不通了，市场竞争已经足够激烈，十家新开张的饭馆恐怕只有一家能撑下来，所以农民企业家已经很少见（连农民都越来越少了）。软件开发行业也一样，最开始的时候，会编程就了不得，思路也很简单：每个公司都要做财务，所以开发财务软件就能赚钱。现在呢？我们每想到一个“点子”，可能有上千人同时在这样想；我们要做一个东西，可能发现市场上已经有许多类似的产品，你卖高价，他就卖低价，你卖低价，他就干脆开源。机会驱动、粗放经营的时代已经远去，为了在激烈的竞争中获得优势，软件开发组织需要从细节上提升技能。
本书聚焦于两方面的技能：需求和设计。关于需求和设计，开发人员可能每天都在做，但是否理解背后的道理呢？我们来做一些题目。
自测题
1.软件开发中做需求的目的是为了：
A）对系统做概要的描述 B）更好地指导设计
C）让产品更加好卖 D）满足软件工程需求规范
2.软件开发中做设计的目的是为了：
A）对系统做详细的描述 B）更好地指导编码
C）降低开发、维护成本 D）满足软件工程设计规范
3.开发人员说“根据客户的需求，我们的系统分为销售子系统、库存子系统、财务子系统……”，这句话反映了开发人员可能有什么样的认识错误？
A）开发人员没有认识到面向对象设计的重要性
B）开发人员直接从设计映射需求
C）开发人员直接从需求映射设计
D）开发人员没有用UML模型来描述子系统
4.打开开发人员写的需求文档，发现用例的名字都是“学生管理”、“题库管理”、“课程管理”……这背后可能隐藏的最大问题是什么？
A）用例的名字不是动宾结构，应改为“管理学生”……
B）开发人员直接从需求映射设计
C）开发人员直接从设计映射需求
D）用例粒度太粗，每一个应该拆解成四个用例，“新增学生”、“修改学生”……1.2 利润＝需求－设计
利润＝收入－成本。不管出售什么，要获得利润，需要两个条件：①要卖出好价钱；②制造的成本要低。妙就妙在，价格和成本之间没有固定的计算公式，这就是创新的动力之源。放到软件业上，我也炮制了一个公式：
在软件开发中，需求工作致力于解决“产品好卖”的问题，设计工作致力于解决“降低成本”的问题。二者不能相互取代。您能低成本生产某种软件产品，但不一定能保证它好卖。您的某种产品好卖，但如果生产成本太高，或者在市场需要新型号时，无法复用之前的组件，又要投入大量人力物力去重新制造，最终还是赚不了多少钱。高焕堂在其著作《Use Case入门与实例》（清华大学出版社）第1章的“Use Case的经济意义”中讲到：用例是收益面，对象是成本面。本书发展了他的思想。
如果需求和设计不分，利润就会缩水。从需求直接映射设计，会导致功能分解，得到重复代码。如果从设计出发来定义需求，会得到一大堆假的“需求”。
拿自古以来就有的一个系统“人体”来举例。人体对外的功能是会走路，会跑步，会跳跃，会举重，会投掷，会游泳……但是设计人体的内部结构时，不能从需求直接映射到设计，得到“走路子系统”、“跑步子系统”、“跳跃子系统”……人体的“子系统”是“呼吸子系统”、“消化子系统”、“血液循环子系统”、“神经子系统”、“内分泌子系统”……图1-1 人体的需求和设计
人体的“子系统”中很多是不能从需求直接映射出来的，需要设计人员的想象力。水店老板要雇一个送水工（即租用一个人肉系统），他只要求这个工人能跑能扛工资低就行，管他体内构造是心肝脾肺肾还是一块电路板。同样，也不能从设计推导出需求——因为人有心肝脾肺肾，所以人的用例是“心管理”、“肝管理”。送水工能这样找工作吗：“老板，我有心脏管理功能，你请我吧！”
很多时候我们说“本系统分为八大子系统……”，其实说的是“本系统的功能需求分为八大需求包……”。需求包是从外部对系统功能所做的简单分包，子系统应根据部件的耦合和内聚切割得到。
我把需求和设计的区别简要列举如图1-2所示，后面的章节我再慢慢阐述这些观点。图1-2 需求和设计的区别1.3 核心工作流
要迈向“低成本制造好卖的产品”的境界，并非喊喊口号就能达到，需要静下心来，学习和实践以下各个核心工作流中的技能。
1.业务建模：描述组织内部各系统（人肉系统、机械系统、电脑系统……）如何协作，使得组织可以为其他组织提供有价值的服务。新系统只不过是组织为了对外提供更好的服务，对自己的内部重新设计而购买的一个零件。组织引进一个软件系统，和招聘一名新员工没有本质区别。如果能学会通过业务建模去推导新系统的需求，而不是拍脑袋得出需求，假的“需求变更”会大大减少。
2.需求：聚焦于待开发系统的边界，详细描述系统要卖得出去必须具有的表现——功能和性能。这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众（Stakeholder）在意的、不能改变的契约，哪些不是，严防“做”污染“卖”。需求工作流的结果——需求规约是“卖”和“做”的衔接点。
3.分析：提炼系统内需要封装的核心领域机制。可运行的系统需要封装各个领域的知识，其中只有一个领域（核心域）的知识是系统能在市场上生存的理由。对核心域作研究，可以帮助我们获得基于核心域的复用。
4.设计：将核心域知识和非核心域知识结合，最终实现系统。说“代码就是设计”指的是这里说的“设计”。代码确实是设计，但代码不是分析，不是需求，不是业务建模。
只要您思考过、表达过图1-3所提到的问题，就是在建模，用文本、UML、其他表示法或自造符号来表达都可以。而且我相信，每一个项目，我们都会思考和表达上面这些问题，只不过可能是无意识地、不严肃地做，现在我们要学习有意识地做，把它做出利润来。当然，使用UML来做是目前一个不坏的选择。图1-3 核心工作流
从我的观察所得，以上四项技能，大多数开发团队做得较好的是设计（也就是实现），前面三项都相当差，特别是业务建模和分析，没有得到足够的重视。很多开发团队拍脑袋编造需求，然后直扑代码，却不知“功夫在诗外”。
开发团队如果缺乏软件工程方面的训练，对这些工作流没有概念，就会把编码以外的工作通通称为“设计”或者“文档”。例如问开发人员在做什么，回答“我在做设计”、“我在写文档”，其实他的大脑可能正在思考组织的业务流程（业务建模），或者在思考系统有什么功能性能（需求），或者在思考系统要包含的领域概念之间的关系（分析），但他通通回答成“在做设计”、“在写文档”。后来又有牛人说了：代码就是设计。本来“设计”在他脑子里就是“代码以外的东西”，这么一推导，不就变成了：代码就是一切？
一些书籍、文章、博客大谈“编码的艺术”，很多也属于概念不清，其实文中探讨的根本不是编码的技能，而是分析技能，甚至是业务建模技能。编码确实有编码的技能，就像医院里“胸腔穿刺”也是技术活，但如果患者经过胸腔穿刺后死亡，更应该反思的是护士的胸腔穿刺手法不过关，还是医生的检查诊断技能不过关？
把工件简单分割为代码和文档（或设计），背后还隐含着这样的误解：认为模型（文档）只不过是源代码的另一种比较概要或比较形象的表现形式。其实，不同工作流产生的工件之间的区别不在于形式，而在于内容，也就是思考的边界，见图1-4。如果清楚了解这一点，即使只用C#，也照样可以“建模”。后面我们可以看到，如果不能做到UML模型就是代码，那么设计工作流就不需要UML模型，代码就是设计。
这种误解不止“普通”的开发人员会有，一些著名的UML书籍作者也有。Martin Fowler所著的UML畅销书《UML精粹》，认为UML有三种用法：草稿、蓝图和编程语言，也是仅从编码的角度来说的。从Fowler写作的其他书籍《重构》、《企业应用架构模式》、《分析模式》等可以知道，他的研究工作集中在分析设计工作流，特别是设计工作流，不了解他在业务建模和需求方面有多少研究。鉴于Fowler在某些社群的心目中如大神一般存在，此处专门提到了他。图1-4 核心工作流思考边界
一些不了解以上概念的开发团队干脆以“敏捷”为名，放弃了这些技能的修炼。就像一名从护士成长起来的医生，只掌握了打针的技能，却缺少检查、诊断、拟治疗方案等技能，索性说：“唉，反正再高明的大夫，也不能一个疗程把病人治好，干脆我也别花那么多心思了，先随便给病人打一针看看吧，不好再来！”“迭代”只是一个底线，确实，再高明的大夫也没有把握一个疗程就治好病人，但是检查、诊断等技能越精湛，所需要的疗程就越少。不能把“迭代”作为偷懒的庇护所。
唱曲的名家，唱到极快之处，吐字依然干净利落；快节奏的现代足球，职业球员的一招一式依然清清楚楚；即时战略游戏高手要在极短时间内完成多次操作，动作依然井然有序。在激烈竞争的年代需要快速应变，掌握技能才能真敏捷。世上无易事，偷懒要不得。
刚入行的开发人员体会不到建模的重要性，是正常的。就像下象棋，初学者面对单车对马双士、单马对单士等已经有共识的局面还需要思考良久，最终还拿不下来甚至输掉。这时中局和布局的书在他看来多半是枯燥无味的，还不如把一本实用残局汇编看熟了，学到一些奇技淫巧，也能在菜市场赢几盘棋。不过，要迈向职业棋手的境界，参加更残酷的竞争，就体会到中局和布局的重要了。
自测题
1.以下描述最可能对应于软件开发中的哪个工作流？
每个项目由若干活动组成，每项活动又由许多任务组成。一项任务消耗若干资源，并产生若干工件。工件有代码、模型、文档等。
A）业务建模 B）需求 C）分析 D）设计
2.以下描述最可能对应于软件开发中的哪个工作流？
A）业务建模 B）分析 C）需求 D）设计
3.以下描述最可能对应于软件开发中的哪个工作流？
系统向会员反馈已购买商品的信息。
A）业务建模 B）分析 C）需求 D）设计
4.以下描述最可能对应于软件开发中的哪个工作流？
某集团向优马神州经理提出举办讲座的请求后，经理根据请求决定请哪一位专家，并拟定讲座计划，交给组织工作人员执行。组织工作人员根据经理提供的专家资料通过E-mail、电话等各种方式联系专家，和专家商议讲座的时间和主题。
A）业务建模 B）分析
C）需求 D）设计
5.如果问开发人员“你在做什么”，他说“我在写文档”，那么他有可能（本题可多选）：
A）不了解软件开发各工作流的区别
B）把自己的工作简单分为“代码”和“文档”
C）认为文档就是代码的叙述性文件
D）知道“文档”和“代码”的真正区别是什么1.4 UML简史
随着市场所要求软件的复杂度不断增大，软件开发的方法学一直在进化。从最开始没有方法，到简单的功能分解法，再到数据流/实体关系法。进入20世纪90年代，面向对象分析设计（OOAD）方法学开始受到青睐，许多方法学家纷纷提出了自己的OOAD方法学，流行度比较高的方法学主要有Booch、Shlaer/Mellor、Wirfs-Brock责任驱动设计、Coad/Yourdon、Rumbaugh OMT和Jacobson OOSE，不同方法学图形比较如图1-5所示。
这种百花齐放的局面带来了一个问题：各方法学有自己的一套概念、定义和标记符号。例如现在UML中的操作（Operation），在不同方法学中的叫法有：责任（Responsibility）、服务（Service）、方法（Method）、成员函数（Member Function）……这些细微的差异通常会造成混乱，使开发人员无从选择，也妨碍了面向对象分析设计方法学的推广。图1-5 不同方法学图形比较
1994年，Rational公司的James Rumbaugh和Grady Booch开始合并OMT和Booch方法。随后，Ivar Jacobson带着他的OOSE方法学加入了Rational公司，一同参与这项工作。他们三个人被称为“三友”（Three Amigo）。这项工作造成了很大的冲击，因为在此之前，各种方法学的拥护者觉得没有必要放弃自己已经采用的表示法来接受统一的表示法。
1996年，“三友”开始与James Odell、Peter Coad、David Harel等来自其他公司的方法学家合作，吸纳他们的成果精华。1997年9月，所有建议被合并成一套建议书提交给OMG。1997年11月，OMG全体成员一致通过UML，并接纳为标准。从2005年起，UML被ISO接纳为标准。相当于UML1.4.2的ISO标准是ISO/IEC 19501，相当于UML2.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。 UML诞生时，Martin Fowler就作了如下预测：你应该使用UML吗？一个字：是！旧的面向对象符号正在快速地消逝。它们还会残留在UML稳固前出版的书上面，但新的书、文章等将会全部以UML作为符号。如果你正在使用旧的符号，你就应该在1998年间转换到UML。如果你正要开始使用建模符号，你就该直接学习UML。——Martin Fowler著，easehawking译，面向对象分析和设计技术，电子杂志《非程序员》第5期，2001。英文原文在网络上已搜索不到。
时间过去十多年了，UML不断发展，在表示法上已经获得了胜利。随便打开一本现在出版的软件开发书，里面如果提到建模，使用的符号基本都是UML，即便在纸上随便画个草图，样子也是UML的样子。各种主流的开发平台也相继添加了UML建模的功能。OMG还和各种行业标准组织如DMTF、HL7等结盟，用UML表达行业标准。
另外，以UML为契机，掀起了一股普及软件工程的热潮，在UML出现后的几年，不但有关建模的新书数量暴增，包括CMM/CMMI、敏捷过程等软件过程改进书籍数量也出现了大幅度增长。制定UML标准的角色（OMG）、根据标准制作建模工具的角色（UML工具厂商）、使用UML工具开发软件的角色（开发人员）这三种角色的剥离，也导致建模工具的数量和种类出现了爆炸性的增长。而之前的数据流等方法从来没有像面向对象分析设计方法一样，出现UML这样的统一表示法，从而带动大量书籍和工具的产生。
最早的一批UML书籍，基本上是方法学家所写。最近几年，以“UML”为题的新书大多为高校教材或普及性教材。这并不是说UML已经不重要，而是没有必要再去强调，焦点不再是“要不要UML”，而是要不要建模、如何建模。
根据UMLChina的统计，UML相关工具最多时达168种，经过市场的洗礼，现在还在更新的还有近百种。有钱买贵的，没钱就买便宜的或者用免费、开源的。从以下网址可以了解UML标准和工具。
OMG UML规范：http://www.omg.org/spec/
ISO UML规范：http://www.iso.org/iso/home/store/catalogue_tc/ catalogue_detail.htmcsnumber=52854
中华人民共和国国家标准：http://www.chinagb.org/ChineseStandardShow-197675.html
UML新闻：http://www.umlchina.com/News/News.htm
UML工具大全：http://www.umlchina.com/Tools/Newindex1.htm
电子杂志《非程序员》下载地址：http://www.umlchina.com/xprogrammer/ Index1.htm1.5 各工作流中的UML
UML现在的版本是2.4，包含的图形如图1-6所示，一共14种（泛化树上的叶结点）。图1-6 UML2.4图形（根据UML2.4规范重新绘制）
可能您看了会说，哇，这么多图，学起来、用起来多复杂啊！其实，UML像一个工具箱，里面各种工具都有。您只需要从这个工具箱中选择适合您的项目类型的工具用上就可以，并不需要“完整地”使用UML。不只是UML，对编程语言也一样的。很多人说“我用Java”，其实只是用Java的一小部分，而且很长时间内只用这一小部分就够了。
经常有学员问：潘老师，能不能给一个案例，完完整整地实施了整套UML？这是一种误解，这样的案例不应该有。有一些建模工具自带的案例模型会造成误解，一个模型里把所有的UML图都给用上了，但这是工具厂商出于展示其工具建模能力的目的而提供的，不可当真。
各工作流可以选用的UML元素以及推荐用法如图1-7所示。图1-7 可选和推荐的UML用法
从“推荐UML元素”一栏中可以看到，常用的UML图形有用例图、类图、序列图三种就够了。针对特定类型的项目，可以按需要添加图形，例如，开发复杂组织的运营系统，如果在业务建模时不喜欢用序列图，可以用活动图取代；对于系统中的核心类，可以着重画出状态机图来建模类内部的逻辑，针对质量要求很高的系统，每一个类可能都需要画状态机图，甚至还要画时间图。
另外，设计工作流推荐的做法是不需要画UML图，“代码就是设计”。要注意这里的“设计”的含义，代码是设计，但不是分析，不是需求，不是业务建模。反过来，“设计就是代码”也是成立的，例如用带有设计级调试和强大代码生成能力的Rational Rhapsody开发实时嵌入系统。
对UML不了解的人经常问我的一个问题是：UML能代替编码吗？其实源代码（也就是人脑需要编辑的介质）的形式一直在变化，从最初的机器语言到汇编语言、过程式高级语言到现在流行的面向对象语言。“模型就是源代码”不是可不可能的问题，而是合不合算的问题。真实世界中，涉众对许多系统的质量要求并不高，电商网站、银行系统出个故障，人们习以为常，能够接受，反正出了故障再恢复呗。这样的系统，充分的建模没有必要性。同时，也没有可能性，因为类太多，工期不允许为每个类画状态机。这些系统只需要对关键的类充分建模。如果做一个心脏起搏器，对质量要求非常高，通过充分的建模尽可能减少人工编码导致的偶发错误是必要的，而且也是可能的，因为类的个数少。1.6 基本共识上的沟通
不少开发人员并不喜欢用UML，更喜欢在白板上画个自造的草图，似流程图非流程图，似类图非类图，然后说“来，我给大家讲讲”。这样的做法有一个巨大的“优点”——怎么画都是对的，关于这个草图的解释权归“我”所有，同事不好批评我，项目要依赖于“我”头脑中的隐式知识——要是“我”不“给大家讲讲”，大家就玩不转了。上面这种现象，在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现更明显。
但是，这样的做法更像是想通过形式上的丑陋来遮掩内容上的丑陋。动乱年代，数学家在牛棚中用马粪纸做数学推导，不代表就可以因为演算工具简陋而允许自己胡乱使用符号和概念；过去的作家没有电脑，不意味着作家可以随意写错别字和犯语法错误。开发人员故意选择简陋的形式为简陋的内容开脱，就如同作家故意选择不好的纸来掩盖自己文字功力不足的事实，并不是好现象。UML没有强调一定要用多么昂贵的工具来建模，但是，即使您在海边用手指在沙滩上建模，模型依然要概念清晰，而不是以此为理由遮掩脓包。
如图1-8所示，就像数学符号背后隐含着数学的基本共识，五线谱背后隐含着基本乐理一样，UML背后隐含的是对于软件建模的一些基本共识。这些符号幼儿园的小朋友都会画，但背后的共识需要一定的训练和学习才能掌握。掌握之后，团队在基本共识上沟通，效率会高得多，无效的低水平争论会少得多，背后的脓包也会强制露出。开发人员如果习惯于画“草图”，用“模块”、“特性”等词汇含糊不清地表达思想，在严谨建模思维的追问之下，往往会千疮百孔，暴露许多之前没有想到的问题。这是一些“高手”潜意识里不愿意直面UML的深层原因。图1-8 符号背后的基本共识
面对一个棋局，下一步怎么走？在业余棋手看来到处都是正确答案，在职业棋手眼里，值得讨论的选项只有两三种，因为职业棋手针对一些基本的技能形成了共识，大大减少了思考中的浪费。
有些伪敏捷开发团队，抛弃了所有“文档”（前文已说过，如果使用“文档”这个词，说明概念不清楚），更喜欢口头交流，你一嘴我一嘴，场面看起来热热闹闹，其实沟通的效果不好，更谈不上思考的深度和知识的沉淀。对比一下菜市场下象棋的热闹和职业棋手比赛时的沉静就知道了。“敏捷”的理由也不成立，菜市场的民工判断局势的速度快还是职业棋手判断局势的速度快？江湖棋手不看棋书不打谱，摆个路边摊够用了，如果参加职业比赛，非被打得落花流水不可。有的开发人员的“十年工作经验”实际上是“一年工作经验用了十年”，一直在热热闹闹的民工层次徘徊，没有积累和成长。1.7 沟通仅限于开发团队内部
但是，这里要注意一点：这种沟通仅限于开发团队内部，UML模型不是用来和涉众沟通的！
经常有人问：客户看不懂UML怎么办？这个问题本身就有问题，提问者潜意识里可能认为“客户”是一个人，其实“客户”是一大堆“涉众”，他们所在领域不同，学历职位有高有低，年龄有大有小，健康有好有坏，关注的利益更是各自不同，怎么能寄望用一个模型和所有的涉众沟通？
拿五线谱类比，五线谱是音乐专业人士交流的工具，作曲要懂、编曲要懂、乐手要懂、指挥要懂、歌手要懂（注意：是懂五线谱，不是人人都要用五线谱作曲）。但哼着“什么样的节奏是最呀最摇摆”的打工仔不需要懂五线谱。UML只是在“软件开发人员”圈子里面的统一表示法，强迫开发人员思考，改善开发人员的交流，表达软件开发的模型。
那么，和涉众交流的介质是什么呢？不是模型本身，而是模型的各种视图。面对大领导，我们可以给他放幻灯片交流愿景；中层干部喜欢看文档，我们可以按照他喜欢的格式给他炮制文档；一线操作工只关心他那一小块工作，我们可以制作界面原型和他交流；有时候甚至有的涉众根本不喜欢看任何东西，我们还可以通过“谈话”这种视图和他交流。涉众连谈话都不乐意，我们也可以通过观察来获取素材。
需求调研的技能有许多种，不仅仅是浅薄的“画个界面草图给用户看”，“问用户想要什么功能”。许多伟大的创新正是有心人在涉众不作声的情况下，观察涉众的行为得到的。另外，和涉众交流的内容应该聚焦于需求的素材——涉众利益（涉众希望什么、担心什么），而不是需求。软件的需求规约相当于电影剧本。电影剧本并不是由观众直接提供的，而是由编剧根据不同观众的口味编出来的。同样，软件需求不是由涉众直接提供的，而是由需求工程师综合不同涉众的利益编造出来的。涉众没有资格、也没有责任提供需求。
和涉众交流的形式应该采用视图，而不是模型。
和涉众交流的内容应该聚焦涉众利益，而不是需求。
不管涉众向我们索取什么材料，都把它看作视图，不管涉众向我们提供什么信息，都把它看作素材（涉众利益）。视图和模型的分离、交流和建模的分离，带来了灵活多变的交流方式和严谨稳定的开发内核。图1-9 交流和开发分离
如果不了解这个区分，直接拿UML模型去和涉众交流需求，很容易导致“四不像”。不少开发团队十年如一日没有进步和积累，“交流影响开发”是原因之一。为了迁就不同涉众的知识水平，开发团队只好损害模型的严谨性，即使是这样，涉众也不一定接受，交流效果还是不好，而且会因为涉众的交流形式多变而影响开发团队核心工作流的稳定——双方都受害。客户的领导说，我不习惯看UML模型，就知道以前看的是××标准格式的文档，我只在这个格式的文档上签字，难道我们就不用UML建模了？下一个项目的客户领导喜欢另一种格式怎么办？下下个项目根本不需要签字怎么办？互联网网站没有“客户领导”签字确认需求怎么办？建模的目的是帮开发团队思考，它可以指引开发团队发现到底需要向涉众了解什么，但不是直接拿着模型和涉众交流。
开发人员有意无意把建模的目的理解成和涉众交流，有时背后的思想还是“懒”字，因为这样想，就有了推卸责任的机会：不是我不想建模，就算我建模了，客户不想看啊。
拿患者和医生类比，您想想下面的情况合理吗？患者说“我腿疼，得了腿癌，我要做放疗”，医生就给他做放疗？患者想看核磁共振成像，医生就给他做；患者不想看甚至昏迷不醒，医生就干脆不做？显然不是这样，医生应该按照成熟的治疗套路，该做什么检查就做什么检查，该如何治疗就如何治疗。1.8 方法和过程
本书讲的是方法（技能），不强调具体某一种过程。拿足球打比方，本书讨论的是射门、运球、传接、抢截、定位球、配合的技能，不讨论战术，更不讨论更衣室团结、俱乐部运营和俱乐部文化。
团队实施过程改进容易流于形式，根源往往就在于技能的不足。如果把改进的焦点先放在技能上，开发人员技能提升了，适用什么样的过程自然就浮出水面，没有必要去生搬硬套某过程。或者说，技能增强了，更能适应不同的过程。UML建模没有绑定到特定过程，不过当前主流的软件过程都是强调增量和迭代开发，所以应该把前面所讲的业务建模、需求、分析、设计看作是一个迭代周期里的工作流，做一点业务建模，做一点需求，做一点分析，做一点设计……，不可误解成“做完了所有的业务建模才能做需求”……
很多时候方法和过程经常被混淆，现在经常说“敏捷方法”，其实“敏捷”是过程家族。之所以造成这个误解，也许和Martin Fowler把他介绍敏捷过程家族的文章起名为“新方法学（The New Methodology）”有关。另一个常见的误解来自Robert C.Martin的书《敏捷软件开发——原则、方法与实践》，书中主要讲的是面向对象设计的一些方法（原理、原则和模式），这些方法并非Robert C.Martin首先提出，而且和敏捷过程没有必然关系，但是，经常会有开发人员误解面向对象设计的这些思想是敏捷人士提出来的。更有一些敏捷人士在没有学习和掌握软件工程知识的情况下，先高喊“砸烂一切”吸引热血青年，然后发现砸烂一切是不行的，又偷偷拾起过去被自己砸烂的东西，加上自己的“敏捷”包装，有意无意地给不了解历史的新入行开发人员造成“这是敏捷发明的，那是敏捷发明的，所以把敏捷挂在嘴边的人最懂”的印象。此类现象，非独软件领域，各个领域、国内国外都屡见不鲜。
我刚开始为开发团队提供服务时，有一次和一个开发团队的经理交流，经理说“我们用的是面向过程方法”。我一开始信以为真，认为如果能做到用面向过程方法，从组织级、系统级到模块级层层分解也不错的。后来发现，经理所说的“面向过程方法”其实是随意的功能分解，也就是没有方法。
类似的场景还有：开发团队负责人说“我们现在采用的是敏捷过程”，稍为深入了解，多半会发现其实他所说的“敏捷过程”就是没有过程。
没有方法不等于面向过程方法，没有过程不等于敏捷过程。面向过程是成熟的方法学，真正的敏捷过程应该是很严肃的过程。不要让“面向过程”、“敏捷”成为偷懒的庇护所。
还有一个常听到的偷懒庇护所是“软件开发是艺术”。软件开发是不是艺术，我不知道，不过我的观点是，就算软件开发到了极高境界，真的是艺术，恐怕也不是我等目前有资格谈的。下棋到很高境界，也有各种流派风格，但那是在通晓了基本棋理的基础上演变出来的，连基本棋理都没有掌握的初学者，把自己的胡思乱想也当成“流派”就不合适了。
师父纠正少林弟子武功招数的细节，弟子懒得去了解为什么按师父教的会好一点，反而说“不要纠结于细节，天下的武功又不仅仅只有少林这一派”，以为这样一说，自己就可以摇身一变成为武当派高手了。其实，少林派武功学精了，如果对武当派武艺感兴趣，转起来容易很多。如果某人学少林派武功时面对细节总是以“不纠结”为由拒绝进一步思考，很难相信他学习武当派武功时会好到哪里去。
高考时要拿到高考状元，很多时候要靠运气，顶尖的学生的知识掌握和学习方法不相上下。但不可以此作为偷懒的借口，绝大多数学生并不处于这个级别，他们要做的是将排名从1000名提升到200名，这样就有好学校可读。这个级别的爬升，还是要靠勤奋和方法。
本书到现在为止，已经说了很多回“偷懒”，就是强调世上无易事，好的方法应该能强迫您思考，强迫您付出心血和汗水来获得竞争优势，反之就是忽悠，就像现在一些甜得发腻的伪敏捷宣传。1.9 案例介绍
本书的案例讲述UMLChina自己的故事。我在序言说到，UMLChina秉持“内外有别”的原则。在外面看来，UMLChina的网站其貌不扬，十几年如一日，UMLChina组织的信息化其实藏在背后。
UMLChina一开始把领域放在软件工程，后来发现，这个领域已经太大了，没有能力在这么大的范围内做到最好，于是缩小范围，专注于和UML相关的建模技能。例如，2002—2004年间我们和出版社合作翻译了《人月神话》、《人件》等软件工程书籍，后来这方面的书籍就不做了。
我为UMLChina所做的定位是：做世界上最小和最好的建模咨询公司。咨询工作适合做精，不适合做大。UMLChina没有招揽或培养满屋子的“年轻资深咨询师”，通过扩大规模来提高收入，有的机构这样做了，也获得了更多的收益，但那不是我们的路。
一旦从深度上定位，就会发现要做的事情非常多，2005年，我决定着手开发UMLChina的业务系统。经过这些年持续改进和升级（也仍将继续改进），虽然现在离我希望的“武装到牙齿”的境界还有很大的距离，但这个和UMLChina业务结合在一起的系统确实能够让UMLChina不必请更多的人就可以保持运作。因为很多业务逻辑已经封装在系统中，所以也比较容易分权给助理。
后面给出的素材绝大部分是真实的，如果有一些地方做了模糊处理，那是出于商业上的考虑。UMLChina在商业方面的事宜有公司负责运作，本书隐去公司真实名字，仍把这个公司叫做UMLChina。1.10 模型的组织
建模的过程中，我们在不同的工作流使用了一些UML元素，如何来组织它们？从前面的图1-7可以知道，工作流和所用的UML元素不是一一对应的。模型可以按照UML元素的种类组织，也可以按照工作流来组织。
本书推荐的模型组织方式是按工作流组织，如图1-10。本书提供了一个初始Enterprise Architect模型，该模型已经按照图1-10的组织方式建好了包，并且添加了一些业务建模和分析的构造型（Stereotype）。我建议读者直接从本书提供的初始模型开始做，按部就班填空即可。初始模型的下载地址是http://www.umlchina.com/training/myproject.rar。初始模型使用EA9.2编辑保存，不过使用其他EA版本打开编辑应该没有问题。您在熟练掌握本书的建模技能以后，如果体会出对您的项目更合理的组织方式，可以抛弃本书所推荐的方式。如果您平时使用的工具不是Enterprise Architect（以下简称EA），而是MagicDraw、StarUML、VP-UML等，也可以自行按照图1-10的方式组织模型。UML工具（包括EA）一般都会预置一些模板，建议先无视它们。图1-10 按工作流组织模型（推荐做法）
另外一种常见的模型组织方式是按视图来组织，如图1-11。以前Rational Rose缺省的组织方式就是这样，最开始我也是这么做的，但是后来发现开发人员容易出问题的地方不是用什么图，而是目前在做什么。开发人员的思维经常跳来跳去，无意识地改变研究范围，思考的边界一会在系统之间，一会在待开发系统的边界，一会跳到系统里面类的关系，一会又细到某个操作内部的代码。所以，不推荐按视图组织模型。图1-11 按视图组织模型（不推荐）
自测题
1.请从大到小依次对以下软件开发名人的年龄排序：
A）Martin Fowler B）Kent Beck C）Ivar Jacobson
D）Peter Coad E）James Rumbaugh F）Grady Booch
2.以下不属于OOAD方法学的是：
A）Booch方法 B）Demarco方法
C）Rumbaugh OMT D）Coad/Yourdon
3.以下不属于UML图形的是：
A）流程图 B）状态机图
C）序列图 D）通信图
4.以下不属于本书推荐常用的UML元素的是：
A）用例图 B）组件图
C）序列图 D）类图
5.以下不是UML工具的是：
A）Enterprise Architect B）DOORS
C）Poseidon D）MagicDraw
E）Plato F）Rhapsody
6.一些开发人员更喜欢画“草图”，然后说“来！我给大家讲讲”，深层原因是：
试读结束[说明：试读内容隐藏了图片]