软件方法
出版社:清华大学出版社
出版日期:2013-9
ISBN:9787302330806
作者:潘加宇
页数:264页
作者简介
UMLChina 首席专家潘加宇的第一本书。作者在为软件组织提供建模咨询和培训服务超过十年后，把他的经验和感悟写成了本书。《软件方法：上册，业务建模和需求》从“利润＝需求－设计”开始，用市场经济的思想讲解软件开发中需求和设计的道理，以及统一建模语言UML 在需求和设计中的应用。本书还破解了软件开发领域流行的一些心灵鸡汤式宣传。
书籍目录
《软件方法：上册，业务建模和需求》
第1章.建模和uml 1
1.1 粗放经营的时代已经远去 1
1.2 利润＝需求－设计 2
1.3 核心工作流 4
1.4 uml 简史 9
1.5 各工作流中的uml 12
1.6 基本共识上的沟通 14
1.7 沟通仅限于开发团队内部 16
1.8 方法和过程 18
1.9 案例介绍 20
1.10 模型的组织 21
1.11 工具操作 25
第2章 愿景27
2.1 最不可缺的工件 27
2.2 愿景的定义 28
2.3 老大 29
2.4 把产品当项目——定位具体的组织（人群） 31
2.5 寻找老大：要点和典型错误 34
2.6 可度量的目标 36
.2.7 揣摩目标度量 38
2.8 涉众利益 40
2.9 可以积累的财富 42
2.10 案例 45
2.11 工具操作 46
第3章.业务建模之业务用例图 47
3.1 软件是组织的零件 47
3.2 业务建模步骤1-1 ：选定要改进的组织 49
3.3 业务建模步骤1-2 ：组织的业务用例图 54
3.3.1 业务执行者 54
3.3.2 业务工人和业务实体 55
3.3.3 寻找业务执行者 57
3.3.4 业务用例 58
3.4 案例 65
3.5 工具操作67
3.6 总结 75
第4章.业务建模之业务序列图77
4.1 描述业务流程的手段 77
4.2 业务序列图要点 87
4.2.1 消息代表责任分配而不是数据流动 87
4.2.2 聚焦于系统之间的协作 88
4.2.3 只画核心域相关的系统 91
4.2.4 把时间看作特殊的业务实体 92
4.3 业务建模步骤1-3 ：现状业务序列图 92
4.3.1 错误：把“现状”误解为“纯手工”93
4.3.2 错误：把“现状”误解为“规范” 93
4.3.3 错误：以待开发系统为中心拼凑流程 94
4.4 案例 96
4.5 工具操作 100
4.6 业务建模步骤1-4 ：改进业务序列图117
4.6.1 改进一：物流变成信息流 118
4.6.2 改进二：改善信息流转 120
4.6.3 改进三：封装领域逻辑 121
4.6.4 阿布思考法123
4.7 案例 129
4.8 工具操作 131
第5章.需求之系统用例图139
5.1 系统执行者要点 139
5.2 需求步骤2-1 ：识别系统执行者 143
5.3 系统用例要点 146
5.4 需求步骤2-2 ：识别系统用例 154
5.5 用例的进一步讲解 157
5.5.1 错误：玩弄“复用” 157
5.5.2 错误：玩弄“层次”163
5.5.3 错误：玩弄“子系统” 163
5.5.4 错误：模糊的价值164
5.5.5 提示：大用例无妨小用例 167
5.5.6 提示：用例的命名167
5.6 案例 169
5.7 工具操作 170
5.8 总结 176
第6章.需求之系统用例规约177
6.1 需求步骤2-3 ：书写系统用例规约 177
6.1.1 前置条件和后置条件178
6.1.2 涉众利益183
6.1.3 基本路径 189
6.1.4 扩展路径196
6.1.5 补充约束 199
6.2 案例 206
6.3 工具操作 209
第7章.需求之需求启发 227
7.1 启发障碍 227
7.2 需求启发手段 229
7.2.1 研究资料229
7.2.2 问卷调查 230
7.2.3 访谈 230
7.2.4 观察 233
7.2.5 研究竞争对手234
7.3 需求工程师236
7.3.1 好奇心 236
7.3.2 探索力 237
7.3.3 沟通力 238
7.3.4 表达力 239
7.3.5 热情 240
内容概要
潘加宇，umlchina首席专家。在1999年还是一名程序员时，利用业余时间创建了umlchina，潜心研究需求和设计技能。2002年开始对外提供uml需求和设计的技术指导和训练服务，客户覆盖了各个领域的领袖企业。
发布书评
精彩书评 (总计5条)
-
读完潘老师的这本大作，我的总体印象是：概念不清，用词不当，东拉西扯，逻辑错乱。全书中那些令人啼笑皆非的荒唐错误结论和缺陷主要有：- 设计约束是需求，但既不是功能需求，也不是非功能需求（潘老师不懂最简单的二元逻辑？）；- 全书对于“涉众”（Stakeholder）这个基本术语的理解几乎通篇是错误的，而且前后矛盾；- UML 模型不是用来和涉众沟通的！（很难相信这是一位 UML 首席专家的言论）；- 涉众没有资格、也没有责任提供需求；- 把 Actor 译成“执行者”，导致许多违反中文常识的语病，如：人民银行是商业银行的执行者，患者是医院的执行者；- 系统 Actor 和重要无关，和重要有关的概念是涉众；- 观众（涉众）在台下看，Actor 在台上表演（其实呢，台上的演员也是涉众）；- 需求或用例的“粒度”、“层次”这些概念其实并不存在，对开发人员的误导相当严重；- 设计就是代码，所以设计工作流不推荐画 UML 图；- 界面组件不是需求。人有眼睛不是需求；- 只用两三章介绍了 UML 的用例图和业务序列图，未强调业务活动图，也未详细介绍 UML 需求分析中常用到的其他图形，如系统序列图、活动图、状态图等（内容单薄、片面）；- 第 2 章所谓的“愿景”，只是区区几个“老大”或涉众的目标，名曰“度量指标”，却连一个数量也没有说明，实质内容与愿景文档差距甚远；- 作为需求分析的名著，从第 3 章到第 6 章的重点章节只介绍了以用例为主的动态建模，未详细介绍需求分析的另一半——静态建模（如领域建模、概念建模）；...基于以上这些错误和缺陷，我给全书的评价是将将及格，只达到了业余研究 UML、需求分析的中等水平，潘老师作为 UML 中国业余的首席专家名至实归，恭喜恭喜！UMLGreatChina 首席专家、创始人 张恂 ;-) -
于 p.205 潘老师说：“设计约束既不是功能需求，也不是非功能需求...设计约束是需求的一种，也一样要从涉众的视角描述。”我凌乱了，这么简单的二元逻辑（功能与非功能）也被扯成这样，新的第三种需求类型因为潘老师而诞生，真可谓中国UML江湖的又一大创举啊！我猜这与潘老师是搞化学的出身，大概没学过离散数学集合论有关吧。正确的说法是：既然设计约束不是功能需求，那么它必然也是一种非功能需求。 -
患者确实是医院的执行者 p.60储户来存钱，企业来贷款，人民银行要对它作监管，这些就是该商业银行的执行者 p.54...请问这些是中国人的语文吗？如此荒唐造句的原因在于作者固执地一定要把 Actor 译作“执行者”。而 UML 中的 Actor 其实代表了业务/系统的直接用户、外部参与者在参与 Use Case 活动中所承担的一种角色，根本不是系统的执行者！请分清系统的客户、请求者、被服务对象，与执行者、被请求者、服务者的方向好么？
精彩短评 (总计15条)
-
重塑思考产品的过程 -
讲的不是方法，是工具，快餐书，谁都可以写书？ -
产品的意义是提高效率 -
很有启发，值得反复阅读和思考，如果能加上习题解析就更好了！ -
国内不错的关于uml的书，例子也很实用。 -
从“利润＝需求－设计”开始，用市场经济的思想讲解软件开发中需求和设计的道理，以及统一建模语言UML 在需求和设计中的应用。本书还破解了软件开发领域流行的一些心灵鸡汤式宣传。 -
提供了一套可供uml建模执行的方式, 但就内容而言没评分那么高 -
书里废话太多，可能是为了增加数的趣味性吧。
觉得像这种工程类的书就不应该搞精装。 -
这才是软件工程正宗 逻辑推理严密 以前看的各种经典软工书籍都是点 这本书帮我打通任督二脉 墙裂推荐啊 -
从需求到项目设计，再到代码设计 -
UMLGreatChina首席专家张恂老师：读完潘老师的这本大作，总体感觉概念不清，用词不当，东拉西扯，逻辑错乱。全书有许多令人啼笑皆非的荒唐错误结论堪称中华名菜虾扯蛋（抑或重大理论创新？），如“涉众没资格、没责任提供需求”、“不要拿UML模型与涉众沟通”、“设计约束既不是功能需求，也不是非功能需求”、“患者是医院的执行者”、“用例的粒度并不存在，对开发人员的误导相当严重”、“人有眼睛不是需求”。。。我给全书的评价是将将及格，只达到了业余研究UML、需求分析的中等水平，潘老师作为UML中国业余的首席专家名至实归，恭喜恭喜！ -
里头有些系统用例的错误使用值得参考 -
主要是用例图和序列图的画法，举例略啰嗦。 -
说实话，这本书的废话比较多，但是确实讲了很多平时我们不会注意的痛点，总结问题的时候往往会忽略的点。。。 -
业界领域专家的书籍一般比理论界的专家的书籍更加具体可操作，也更加贴近业界当前的实践。I hear and I forget. I see and I remember. I do and I understand。先见全局，再摸细节，力荐！