《潘加宇-软件方法资料》由会员分享，可在线阅读，更多相关《潘加宇-软件方法资料（55页珍藏版）》请在金锄头文库上搜索。
1、 软件方法（草稿） 更新日期：2011.8.9 请用 9.0 版以上 Arcobat Reader 阅读，否则可能无法使用书中的测试题。 UMLChina 新浪微博 UMLChina 腾讯微博 潘加宇 1 自序 自序 光阴匆匆似流水，它一去不再回。 浪子归 ；词：黄小茂，曲：崔健，唱：崔健；1986 1999 年还是一名程序员时，我创建了 UMLChina，从那时开始关注软件工程各方面的进展。2001 年 12 月，阿里 巴巴的吴泳铭来 email 询问是否有 UML 方面的训练，我开始准备训练材料。2002 年 3 月，我去杭州给阿里巴巴做了这 个训练。虽然与后来我给阿里集团各公司做的许多次
2、训练相比，这第一次讲课从内容和形式都算是糟透了，但是我现 在还记得当时的心情迈出自己事业第一步的心情。 目前（2011 年 6 月）为止，我已经上门为已经超过 150 家的软件组织提供需求和设计技能的训练和咨询服务。训 练结束后，学员们常会问： “潘老师，上完课后我们应该看什么书？”我总是回答： “先不用看杂七杂八的书，还是要 复习我们留下的资料，那些幻灯片、练习题、模型就已经是最好的书了，按照改进指南先用一点点在具体项目上，带 着出现的具体困惑来和我讨论。 ”虽然一再这样强调了，有的学员还是经常情不自禁地拿着一本*UML*之类的 书来问我问题，不管书上说得对不对。看来写在正式出版物上的效果就
3、是不一样啊。 其实现在出书也不难，UMLChina 一直在和出版社合作推介国外优秀的软件工程书籍，目前已经有三十多本软件工 程书籍上有 UMLChina 的标记了。不过我一直没有自己写一本书，主要原因还是觉得自己的积累不够，思考的深度也不 够，对软件开发的认识还在不断变化。如果没有自己成型的东西，不能站在别人的肩膀上看得更远，只是摘抄别人的 观点，这样的书有什么意义呢？ 另外一个原因是，UMLChina 后来开始采取了“隐形、关门”的策略，秉持“内外有别”的原则。我关闭了已经有 4 万多人的 Smiling 电子小组（也是为了降低某些风险） ，网站不再有公开的社区，在网站上也找不到“客户名单”
4、 ，所 有更细致的服务以非公开的方式对会员提供。在这种情况下，出一本书也不是那么迫切。 现在距离第一次提供服务已经将近十年，也有了一些积累，所以硬着头皮也要开始写书了。在这些年的服务过程 中，和开发团队谈到改进时，我发现一个有趣的现象：很多开发团队（不是每个团队）或多或少都会有人（不是每个 人）或明或暗地表达出这样的观点自己团队的难处与众不同，奇特的困难降临在他们身上，偏偏别人得以幸免自己团队的难处与众不同，奇特的困难降临在他们身上，偏偏别人得以幸免。 尽管 UMLChina 一直强调自己的服务是“聚焦最后一公里” ，坚信每一个开发团队都会在细节上和其他团队有所不 同，而且也应该有所不同。但很
5、多时候，我还是感觉到，开发团队还是高估了自己的“个性” ，低估了“共性” 。本书 就是归纳这样一些“共性” ，作为我的一家之言，供大家参考。感谢曾经选择过我的服务的伙伴们。他们一次次地给我 机会来实践、发展和锤炼技艺，才有了这本书。 目前还没有和任何出版社商议出纸书事宜。本书先以电子版方式公布，不定期更新版本，您可以到 2 查看新的版本。因为我经常为程序员杂志写文章，所以本书中的一 些文字您可能在程序员上看到过。 每一章的后面，我会提供一些针对该章内容的自测题，读者感兴趣可以测试一下。这些测试题以嵌入 Flash 的方 式提供，请留心一下您正在使用的 PDF 阅读器是否支持 Flash，最好下
6、载最新版本的 Arcobat Reader。 一些作者喜欢在每一章的开头放上和该章内容相关的一幅画或一句名人名言， 所以我也效仿一下， 不过没那么 “高 雅”每章的开头放上和该章内容相关的一句歌词。 书中的模型图，如果是我为了讲解知识而画的，用的建模工具是 Enterprise Architect；如果是截取真实模型的 图片，可能会涉及到各种工具。我不像 Robert C. Martin 那样，女儿已经长大到可以帮画插图，所以非 UML 模型的插 图，我都自己用 Wacom 笔来画，可能丑了一些，请见谅。 关于本书的任何反馈，请发邮件到 umlchina 。 UML 全程实作公开课 8 月 1
7、3-14 日 北京 3 目录 目录 第 1 章 建模和 UML 第 2 章 愿景 第 3 章 业务建模 之 业务用例图 第 4 章 业务建模 之 业务序列图 第 5 章 需求 之 系统用例图 第 6 章 需求 之 系统用例文档 第 7 章 需求 之 需求启发和验证 第 8 章 分析 之 类图 第 9 章 分析 之 序列图 第 10 章 分析 之 状态机图 第 11 章 设计 之 映射数据层 第 12 章 设计 之 映射业务层 第 13 章 设计 之 映射表示层 第 14 章 设计 之 领域驱动设计思想 第 15 章 改进指南 1 第 1 章 建模和 UML 第 1 章 建模和 UML 脚下没有
8、路，我们走出来，狂风暴雨过天边 新空气的声音 ；词曲：张全复、毕晓世、解承强，唱：新空气；1988 粗放经营的时代已经远去粗放经营的时代已经远去 中国刚迈入改革开放时，出现了许多农民企业家，他们不用讲管理，也不用讲方法，只要胆子大一点，就能获得 成功。为什么？当时的市场几乎空白，竞争非常少。农民企业家思路很简单：人人都要吃饭，所以开饭馆能够赚钱。 现在这样的思路已经行不通了，市场竞争已经足够激烈，十家新开张的饭馆恐怕只有一家能撑下来，所以农民企业家 已经很少见（连农民都越来越少了） 。软件开发行业也是一样，最开始的时候，会编程就了不得，思路也很简单：每个 公司都要做财务，所以开发财务软件就能赚
9、钱。现在呢？我们每想到一个“点子” ，可能有上千人同时在这样想；我们 要做一个东西，可能发现市场上已经有许多类似的产品，你卖高价，他就卖低价，你卖低价，他干脆就开源。机会驱 动、粗放经营的时代已经远去，为了在激烈的竞争中获得优势，软件开发组织需要从细节上提升技能。 许多开发团队里面往往会有一些高手，他们是项目的顶梁柱。这些“高手”在职业道路的初期做项目也是失败的， 但经过在失败中不断积累经验，慢慢开始能够成功完成项目。不过， “高手”靠的是头脑里面的隐式知识，这些知识没 有经过整理，也不一定都正确，而且“高手”潜意识潜意识里出于利益的考虑，并不愿意积极和大家分享，本书希望能够讲 述一些能够被整
10、个团队共享的显式知识，使团队有可能在不同的项目中复制成功。 本书聚焦于两方面的技能：需求和设计。关于需求和设计，开发人员可能每一天都在做，但是否理解背后的道理 呢？我们来做一些测试： 2 利润需求设计利润需求设计 利润收入成本。不管出售什么，要获得利润，需要两个条件： （1）要卖出好价钱； （2）制造的成本要低。妙 就妙在，价格和成本之间没有固定的计算公式，这就是创新的动力之源。放到软件业上，我也炮制了一个公式： 利润需求设计 在软件开发中，需求工作致力于解决“产品好卖”的问题，设计工作致力于解决“降低成本”的问题。二者不能 相互取代。您能低成本生产某种软件产品，但不一定能保证它好卖。您的某种
11、产品好卖，但如果生产成本太高，或者 在市场需要新型号时，无法复用之前的组件，又要投入大量人力物力去重新制造，最终还是赚不了多少钱。 需求设计不分，利润缩水。例如从需求直接映射设计，会导致功能分解得到重复代码。如果从设计直接找需求， 会导致得到一大堆假的“需求” 。 拿自古以来就有的一个系统“人体”来举例。人体对外的功能是会走路，会跑步，会跳跃，会举重，会投掷，会 游泳。但是设计人体的内部结构时，不能从需求直接映射到设计，得到“走路子系统” 、 “跑步子系统” 、 “跳跃子系 统”。人体的“子系统”是“呼吸子系统” 、 “消化子系统” 、 “血液循环子系统” 、 “神经子系统” “内分泌子系统”
12、。 这些“子系统”中很多是不能从需求直接找出来的，需要设计人员的想象力。水店老板要雇一个送水工（即租用一个 人肉系统） ，他只要求这个工人能跑能扛就行，管他体内构造如何。同样，也不能从设计推导出需求因为人有心肝 脾肺肾，所以人的用例是“心管理” 、 “肝管理” 。送水工能这样找工作吗：老板，我有心脏管理功能，你请我吧！ 图 1-1 人体的需求和设计 需求要具体，设计要抽象。或者说，需求，要把产品当项目做；设计，要把项目当产品做。后面的章节我再慢慢 3 阐述这些观点。 核心工作流核心工作流 要迈向“低成本制造好卖的各款产品”的境界，并非喊喊口号就能达到，需要静下心来，学习和实践以下各个核 心工作
13、流中的技能： 1. 业务建模业务建模描述组织内部各系统（人肉系统、机械系统、电脑系统.）如何协作来为组织的“客户”提供服 务。新系统只不过是组织为更好地满足客户，对自己的内部重新设计而购买的一个零件（和招聘一个新员工没有本质 区别） 。如果能学会通过业务建模去推导新系统的需求，而不是拍脑袋得出需求，假的“需求变更”会大大减少。 2. 需求需求聚焦于待开发系统的边界，详细描述系统要卖得出去必须具有的外部表现功能和性能。这项技能 的意义在于强迫我们从“卖”的角度思考哪些是涉众在意的、不能改变的契约，哪些不是，严防“做”污染“卖” 。需 求工作流的结果需求规格说明书是“卖”和“做”的衔接点。 3.
14、分析分析提炼系统内需要封装的核心领域机制。 可运行的系统需要封装各个领域的知识， 其中只有一个领域 （核 心域）的知识是系统能在市场上生存的理由。对核心领域作研究，可以帮助我们获得基于核心域的复用。 4. 设计设计将核心域知识和非核心域知识结合，最终实现系统。说“代码就是设计”指的就是这狭义的“设计” 。 代码确实是设计，但代码不是分析，不是需求，不是业务建模。很多时候开发人员乱用“设计”这个词，把“编码以 外的所有工作”统统称为“设计” 。后来又有牛人说了：代码就是设计。这么一推导，不就变成了：代码就是一切？ 图 1-2 核心工作流 4 图 1-3 核心工作流思考边界 从我的观察所得，以上四
15、项技能，开发团队做得较好的是设计（也就是实现） ，前面三项都相当差，特别是业务建 模和分析，没有得到足够的重视。很多开发团队拍脑袋编造需求，然后直扑代码，却不知“功夫在诗外” 。更糟糕的是， 一些开发团队以“敏捷”为名，干脆就放弃了这些技能的修炼。就像一名从护士成长起来的医生，只掌握了打针的技 能，却缺少检查、诊断、拟治疗方案.等技能，索性说：唉，反正再高明的大夫，也不能一个疗程把病人治好，干脆我 也别花那么多心思了，先随便给病人打一针看看吧，不好再来！ 唱曲的名家，唱到极快之处，吐字依然干净利落；快节奏的现代足球，职业球员的一招一式依然清清楚楚；星际 争霸高手要在极短时间内完成多次操作， 动
16、作依然井然有序。 在激烈竞争的年代需要快速应变， 掌握技能才能真敏捷。 上面的文字我没有提到 UML。也就是说，只要您思考过、表达过上面这些问题，就是在建模，用文本，用自造的 符号来表达都可以。而且我相信，每一个项目，我们都会思考和表达上面这些问题，只不过可能是无意识地、不严肃 地在做，现在我们要学习有意识地做，把它做出利润来。当然，使用 UML 是目前一个不坏的选择。 5 UML 简史简史 随着市场所要求的软件规模不断增大，软件的分析设计方法一直在进化。从最开始没有方法，到简单的功能分解 法，再到数据流/实体关系法。进入 1990 年代，面向对象分析设计（OOAD）方法学开始受到青睐，许多方法学家纷纷 提出了自己的 OOAD 方法学，流行度比较高的方法学主要有：Booch、Shlaer/Mellor、Wirfs-Brock 责任驱动设计、 Coad/Yourdon、Rumbaugh OMT 和 Jacobson OOSE。 这种百花齐放的局面带来了一个问题
