《软件方法》第1章 建模和UML

发帖时发现：您的文章当中包含了敏感关键词'动***％乱'，属于有关部门规定的有害信息，为了保护您和ITeye网站的安全，我们建议您不要发表这篇文章
所以下文将'动***％乱'改成“乱搞”

第1章 建模和UML

脚下没有路，我们走出来，狂风暴雨过天边
《新空气的声音》；词曲：张全复、毕晓世、解承强，唱：新空气；1988
粗放经营的时代已经远去
中国刚迈入改革开放时，出现了许多农民企业家，他们不用讲管理，也不用讲方法，只要胆子大一点，就能获得成功。为什么？当时的市场几乎空白，竞争非常少。农民企业家思路很简单：人人都要吃饭，所以开饭馆能够赚钱。现在这样的思路已经行不通了，市场竞争已经足够激烈，十家新开张的饭馆恐怕只有一家能撑下来，所以农民企业家已经很少见（连农民都越来越少了）。软件开发行业也是一样，最开始的时候，会编程就了不得，思路也很简单：每个公司都要做财务，所以开发财务软件就能赚钱。现在呢？我们每想到一个“点子”，可能有上千人同时在这样想；我们要做一个东西，可能发现市场上已经有许多类似的产品，你卖高价，他就卖低价，你卖低价，他干脆就开源。机会驱动、粗放经营的时代已经远去，为了在激烈的竞争中获得优势，软件开发组织需要从细节上提升技能。
许多开发团队里面往往会有一些高手，他们是项目的顶梁柱。这些“高手”在职业道路的初期做项目也是失败的，但经过在失败中不断积累经验，慢慢开始能够成功完成项目。不过，“高手”靠的是头脑里面的隐式知识，这些知识没有经过整理，也不一定都正确，而且“高手”潜意识里出于利益的考虑，并不愿意积极和大家分享，本书希望能够讲述一些能够被整个团队共享的显式知识，使团队有可能在不同的项目中复制成功。
本书聚焦于两方面的技能：需求和设计。关于需求和设计，开发人员可能每一天都在做，但是否理解背后的道理呢？我们来做一些测试：







利润＝需求－设计
利润＝收入－成本。不管出售什么，要获得利润，需要两个条件：（1）要卖出好价钱；（2）制造的成本要低。妙就妙在，价格和成本之间没有固定的计算公式，这就是创新的动力之源。放到软件业上，我也炮制了一个公式：
利润＝需求－设计
在软件开发中，需求工作致力于解决“产品好卖”的问题，设计工作致力于解决“降低成本”的问题。二者不能相互取代。您能低成本生产某种软件产品，但不一定能保证它好卖。您的某种产品好卖，但如果生产成本太高，或者在市场需要新型号时，无法复用之前的组件，又要投入大量人力物力去重新制造，最终还是赚不了多少钱。
需求设计不分，利润缩水。例如从需求直接映射设计，会导致功能分解得到重复代码。如果从设计直接找需求，会导致得到一大堆假的“需求”。
拿自古以来就有的一个系统“人体”来举例。人体对外的功能是会走路，会跑步，会跳跃，会举重，会投掷，会游泳…。但是设计人体的内部结构时，不能从需求直接映射到设计，得到“走路子系统”、“跑步子系统”、“跳跃子系统”…。人体的“子系统”是“呼吸子系统”、“消化子系统”、“血液循环子系统”、“神经子系统”“内分泌子系统”…..。这些“子系统”中很多是不能从需求直接找出来的，需要设计人员的想象力。水店老板要雇一个送水工（即租用一个人肉系统），他只要求这个工人能跑能扛就行，管他体内构造如何。同样，也不能从设计推导出需求――因为人有心肝脾肺肾，所以人的用例是“心管理”、“肝管理”。送水工能这样找工作吗：老板，我有心脏管理功能，你请我吧！

图1-1 人体的需求和设计
需求要具体，设计要抽象。或者说，需求，要把产品当项目做；设计，要把项目当产品做。后面的章节我再慢慢阐述这些观点。
核心工作流
要迈向“低成本制造好卖的各款产品”的境界，并非喊喊口号就能达到，需要静下心来，学习和实践以下各个核心工作流中的技能：
1. 业务建模――描述组织内部各系统（人肉系统、机械系统、电脑系统...）如何协作来为组织的“客户”提供服务。新系统只不过是组织为更好地满足客户，对自己的内部重新设计而购买的一个零件（和招聘一个新员工没有本质区别）。如果能学会通过业务建模去推导新系统的需求，而不是拍脑袋得出需求，假的“需求变更”会大大减少。
2. 需求――聚焦于待开发系统的边界，详细描述系统要卖得出去必须具有的外部表现――功能和性能。这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众在意的、不能改变的契约，哪些不是，严防“做”污染“卖”。需求工作流的结果――需求规格说明书是“卖”和“做”的衔接点。
3. 分析――提炼系统内需要封装的核心领域机制。可运行的系统需要封装各个领域的知识，其中只有一个领域（核心域）的知识是系统能在市场上生存的理由。对核心领域作研究，可以帮助我们获得基于核心域的复用。
4. 设计――将核心域知识和非核心域知识结合，最终实现系统。说“代码就是设计”指的就是这狭义的“设计”。代码确实是设计，但代码不是分析，不是需求，不是业务建模。很多时候开发人员乱用“设计”这个词，把“编码以外的所有工作”统统称为“设计”。后来又有牛人说了：代码就是设计。这么一推导，不就变成了：代码就是一切？

图1-2 核心工作流

图1-3 核心工作流思考边界
从我的观察所得，以上四项技能，开发团队做得较好的是设计（也就是实现），前面三项都相当差，特别是业务建模和分析，没有得到足够的重视。很多开发团队拍脑袋编造需求，然后直扑代码，却不知“功夫在诗外”。更糟糕的是，一些开发团队以“敏捷”为名，干脆就放弃了这些技能的修炼。就像一名从护士成长起来的医生，只掌握了打针的技能，却缺少检查、诊断、拟治疗方案...等技能，索性说：唉，反正再高明的大夫，也不能一个疗程把病人治好，干脆我也别花那么多心思了，先随便给病人打一针看看吧，不好再来！
唱曲的名家，唱到极快之处，吐字依然干净利落；快节奏的现代足球，职业球员的一招一式依然清清楚楚；星际争霸高手要在极短时间内完成多次操作，动作依然井然有序。在激烈竞争的年代需要快速应变，掌握技能才能真敏捷。
上面的文字我没有提到UML。也就是说，只要您思考过、表达过上面这些问题，就是在建模，用文本，用自造的符号来表达都可以。而且我相信，每一个项目，我们都会思考和表达上面这些问题，只不过可能是无意识地、不严肃地在做，现在我们要学习有意识地做，把它做出利润来。当然，使用UML是目前一个不坏的选择。
 













UML简史
随着市场所要求的软件规模不断增大，软件的分析设计方法一直在进化。从最开始没有方法，到简单的功能分解法，再到数据流/实体关系法。进入1990年代，面向对象分析设计（OOAD）方法学开始受到青睐，许多方法学家纷纷提出了自己的OOAD方法学，流行度比较高的方法学主要有：Booch、Shlaer/Mellor、Wirfs-Brock责任驱动设计、Coad/Yourdon、Rumbaugh OMT和Jacobson OOSE。
这种百花齐放的局面带来了一个问题：各方法学有自己的一套概念、定义和标记符号。例如现在UML中的“操作”，在不同方法学中的叫法有：责任（Responsibility）、服务（Service）、方法（Method）、成员函数（Member Function）...这些细微的差异通常会造成混乱，使开发人员无从选择，也妨碍了面向对象分析设计方法学的推广。
Booch

Coad/Yourdon

Rumbaugh OMT

UML

图1-4不同方法学图形比较
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/IEC 19501，UML2.1.2即ISO/IEC 19505。
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新闻：http://www.umlchina.com/News/News.htm
UML工具大全：http://www.umlchina.com/Tools/Newindex1.htm
 
各工作流中的UML
UML现在的版本是2.4，包含的图形如图1-6所示，一共14种（泛化树上的叶结点）。

图1-5 UML2.4图形，根据UML2.4规范重新绘制
可能您看了会说，哇，这么多图，学起来用起来多复杂啊。其实，UML像一个工具箱，里面各种工具都有。您只需要从这个工具箱中选择对您的项目类型合适的工具用上就可以，并不需要“完整地”使用UML。不只是UML，对编程语言也一样的。很多人说“我用Java”，其实只是用Java的一小部分，而且很长时间内只用这一小部分就够了。
经常有学员问：潘老师，能不能给一个案例，完完整整地实施了整套UML？这是一种误解，这样的案例不应该有。有一些建模工具自带的案例模型会造成误解，一个模型里把所有的UML图都给用上了，但这是工具厂商出于展示其工具建模能力的目的而提供的，不可当真。
各工作流可以选用的UML元素以及推荐用法如图1-7所示。
工作流 思考焦点 可选UML元素 推荐UML元素
业务建模 组织内系统之间 用例图、类图、序列图、活动图 用例图、类图、序列图
需求 系统边界 用例图、序列图、状态图、活动图、文档 用例图、文档
分析 系统内核心域 类图、序列图、状态图、活动图、通信图、包图 类图、序列图、状态图
设计 系统内各域之间 类图、序列图、状态图、活动图、通信图、组件图、部署图、时间图、组合结构图、包图 不画，代码即设计
图1-6 可选和推荐的UML用法
特定类型的项目，可以按需要添加图形，这一点后文再描述。
基本共识上的沟通
不少开发人员并不喜欢用UML，更喜欢在白板上画个自造的草图，似流程图非流程图，似类图非类图，然后说“来，我给大家讲讲！”。这样的做法有一个巨大的“优点”――因为怎么画都是对的，关于这个草图的解释权归“我”所有，同事也不好批评我，项目要依赖于“我”头脑中的隐式知识――要是“我”不“给大家讲讲”，大家就玩不转了。这一点，在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现更明显。
但是，这样的做法更像是想通过形式上的丑陋来遮掩内容上的丑陋。乱&搞年代，数学家在牛棚中用马粪纸做数学推导，不代表就可以因为演算工具简陋就可以允许自己胡乱使用符号和概念；过去的作家没有电脑，不意味着作家可以随意写错别字犯语法错误。开发人员故意选择简陋的形式为简陋的内容开脱，就如同作家故意选择不好的纸来掩盖自己文字功力不足的事实，并不是好现象。
就像数学符号背后隐含着数学的基本共识，五线谱背后隐含着基本乐理一样，UML背后隐含的是对于软件建模的一些基本共识。这些符号幼儿园的小朋友都会画，但背后的共识需要一定的训练和学习才能掌握。在基本共识上沟通，效率会高得多，无效的低水平争论也会少得多，背后的脓包也会强制性露出来。开发人员如果习惯于画“草图”，用“模块”、“特性”等词汇含糊不清地表达思想，在严谨建模思维的追问之下，往往会千疮百孔，暴露许多之前没有想到的问题。

图1-7 符号背后的基本共识
面对一个棋局，下一步怎么走？在业余棋手看来到处都是正确答案，在职业棋手眼里，答案只有两三种，因为职业棋手针对一些基本的技能形成了共识，大大减少了思考中的浪费。
但…仅限于开发团队内部
但是，这里要注意一点：这种沟通仅限于开发团队内部，UML模型不是用来和涉众沟通的！
经常有人问：客户看不懂UML怎么办？这个问题本身就有问题，提问者潜意识里可能认为“客户”是一个人，其实“客户”是一大堆“涉众”，他们学历职位有高有低，年龄有大有小，健康有好有坏，关注的利益更是各自不同，怎么能寄望用一个模型和所有的涉众沟通？
拿五线谱类比，五线谱是音乐专业人士交流的工具，作曲要懂、编曲要懂、乐手要懂、指挥要懂、歌手要懂。但没有说下载彩铃“爱情不是你想卖，想买就能卖”的打工仔还要懂五线谱的。UML只是在“软件开发人员”圈子里面的统一表示法，强迫开发人员思考，改善开发人员的交流，表达软件开发的模型。
那么，和涉众交流的介质是什么呢？不是模型本身，而是模型的各种视图。面对大领导，我们可以给他放幻灯片交流愿景；中层干部喜欢看文档，我们可以按照他喜欢的格式给他炮制文档；一线操作工只关心他那一小块工作，我们可以制作界面原型和他交流；有时候甚至有的涉众根本不喜欢看任何东西，我们还可以通过“谈话”这种视图和他交流。极端一点说，如果客户的领导喜欢“潜规则”，不排除派一名美貌女（男）员工去通过“潜规则”这种视图来和领导交流的可能。
另外，和涉众交流的内容应该聚焦于需求的素材――涉众利益（涉众希望什么担心什么），而不是需求。软件的需求规约相当于电影剧本。电影剧本并不是由观众直接提供的，而是由编剧根据不同观众的口味编出来的。同样，软件需求不是由涉众直接提供的，而是由需求工程师综合不同涉众的利益编造出来的。涉众没有资格、也没有责任提供需求，这一点后面在“需求启发”一章中再详述。
和涉众交流的形式应该采用视图，而不是模型
和涉众交流的内容应该聚焦涉众利益，而不是需求。
也就是说，不管涉众向我们索取什么材料，都把它看作视图，不管涉众向我们提供什么信息，都把它看作素材（涉众利益）。视图和模型的分离、交流和建模的分离，带来了灵活多变的交流方式和严谨稳定的开发内核。

图1-8 交流和开发分离
如果不了解这个区分，直接拿UML模型去和涉众交流需求，会因为涉众不接受而导致交流效果不好，还会因为涉众的交流形式多变而影响开发的核心工作流。客户的领导说，我不习惯看UML模型，就知道以前看的是××标准格式的文档，我只在这个格式的文档上签字，难道我们就不用UML建模了？下一个项目的客户领导喜欢另一种格式怎么办？下下个项目根本不需要签字怎么办？互联网网站没有“客户领导”签字确认需求怎么办？建模的目的是帮开发团队思考，它可以指引开发团队发现到底需要向涉众了解什么，但不是直接拿着模型和涉众交流。
方法和过程
本书讲的是方法（技能），不强调具体某一种过程。拿足球打比方，本书讨论的是射门、运球、传接、抢截、定位球、配合的技能，不讨论战术，更不讨论更衣室团结、俱乐部运营和俱乐部文化。
团队实施过程改进容易流于形式，根源往往就在于技能的不足。如果把改进的焦点先放在技能上，开发人员技能提升了，适用什么样的过程自然就浮出水面，没有必要去生搬硬套某过程。或者说，技能增强了，更能适应不同的过程。
很多时候方法和过程经常被混淆，现在经常说“敏捷方法”，其实“敏捷”是过程（家族）。之所以造成这个误解，也许和Martin Fowler把他介绍敏捷过程家族的文章起名为“新方法学（The New Methodology）”有关。另一个常见的误解来自Robert C. Martin的书《敏捷软件开发-原则、方法与实践》，书中主要讲的是面向对象设计的一些方法（原理、原则和模式），这些方法并非Robert C. Martin首先提出，而且和敏捷过程没有必然关系，但是，经常会有开发人员误解面向对象设计的这些思想是敏捷人士提出来的。
我刚开始为开发团队提供服务时，有一次和一个开发团队的经理交流，经理说“我们用的是面向过程方法”。我一开始信以为真，认为如果能做到用面向过程方法，从组织级、系统级到模块级层层分解也不错的。后来发现，经理所说的“面向过程方法”其实是随意的功能分解，也就是没有方法。
类似的场景还有：开发团队负责人说“我们现在采用的是敏捷过程”，稍为深入了解一下，多半会发现其实他所说的“敏捷过程”就是没有过程。
没有方法不等于面向过程方法，没有过程不等于敏捷过程。面向过程是成熟的方法学，真正的敏捷过程也是很严肃的过程。不要让“面向过程”、“敏捷”成为偷懒的庇护所。
还有一个常听到的偷懒庇护所是“软件开发是艺术”。软件开发是不是艺术，我不知道，不过我的观点是，就算软件开发到了极高境界真的是艺术，恐怕也不是我等目前有资格谈的。围棋下到很高境界，也有宇宙流、暴力流、地铁流…，但连基本棋理都没有掌握的初学者也胡思乱下妄谈“流派”就不合适了。艺术家一张画卖到上千万美金，某人一看，哟，怎么歪歪扭扭的和我儿子画的差不多呀，儿子，咱也别辛苦学这些绘画技法了，胡乱画吧，没准哪一天你的画也能卖一千万美金呢！
案例介绍
在开始进入方法的探讨之前，照例需要先说一下案例项目是什么，本书给出两个：
案例一：某国软件开发工具厂商AoiSora System为了在中国推广其出品的开发工具，委托中国的一家软件咨询公司――优马神州公司不定期举办与开发工具相关的免费技术讲座。技术讲座的目标听众为软件开发人员，每期讲座会邀请一名业界知名技术专家主讲。讲座已经举办了二十多期，优马神州公司的老总对现状不满意了，他希望有一些改变……
案例二：徐运光是一家软件公司的技术经理，儿子明年上初中，儿子“小升初”的大业使得徐运光对初中学校，初中老师的各种信息非常关心。在不断上网收集资料的过程中，他注意到了一个情况：初中老师的日常工作负担非常重，而且看起来没有好的电脑系统帮忙。徐运光想：能不能为初中老师的日常工作做一些软件？如果有戏的话，干脆自己开个公司来做？自己也四十了，该做一些自己的事情了……
第一个案例是个“项目”，起源于客户的要求；第二个案例是个“产品”，起源于开发人员萌生的想法。
模型的组织
建模的过程中，我们在不同的工作流使用了一些UML元素，如何来组织它们？从前面的图1-6可以知道，工作流和所用的UML元素不是一一对应的。模型可以按照UML元素的种类组织，也可以按照工作流来组织。本书推荐的模型组织方式是按工作流组织，如下图：

图1-9 推荐做法――按工作流组织模型
本书提供了一个空白的EA模型（http://www.umlchina.com/training/myproject.rar），模型中已经按照图1-9的方式建好了包，并且添加了一些构造型（Stereotype）。我建议直接从本书提供的空白模型开始做，按部就班填空即可。您在熟练掌握本书的建模技能以后，如果体会出对您的项目更合理的组织方式，可以抛弃本书所推荐的方式。如果您平时使用的工具不是EA，而是MagicDraw、StarUML、VP-UML等，也可以自行按照图1-9的方式组织模型。UML工具（包括EA）一般都会预置一些模板，建议先无视它们。
另外一种常见的模型组织方式是按视图来组织，如图1-10。以前Rational Rose缺省的组织方式就是这样，最开始我也是这么做的，但是后来发现开发人员容易出问题的地方不是用什么图，而是目前在做什么。开发人员的思维经常跳来跳去，无意识地改变研究范围，思考的边界一会在系统之间，一会在待开发系统的边界，一会跳到系统里面类的关系，一会又细到某个操作内部的代码。

图1-10 不推荐――按视图组织模型

＝＝＝＝＝＝＝＝＝＝
带有图和测试题的PDF版本《软件方法》下载地址为：
http://www.umlchina.com/book/panjiayu.htm
＝＝＝＝＝＝＝＝＝＝＝

送水工能这样找工作吗：老板，我有心脏管理功能，你请我吧！

这个生动的说出了大家思考用例方法的误区

动@乱??
  YYY

<p class="flash_error">您的文章当中包含了敏感关键词'动@乱'，属于有关部门规定的有害信息，为了保护您和ITeye网站的安全，我们建议您不要发表这篇文章，有关部门一旦认为你的文章是有害信息，会要求我们提供你的IP地址</p>

是一套建模的工具书，适合初学者。我更喜欢"大象uml"

不图文并茂,感觉很难看下去!

好书，拜读了