具体描述
UMLChina 首席专家潘加宇的第一本书。作者在为软件组织提供建模咨询和培训服务超过十年后，把他的经验和感悟写成了本书。《软件方法：上册，业务建模和需求》从“利润＝需求－设计”开始，用市场经济的思想讲解软件开发中需求和设计的道理，以及统一建模语言UML 在需求和设计中的应用。本书还破解了软件开发领域流行的一些心灵鸡汤式宣传。
作者简介
潘加宇，umlchina首席专家。在1999年还是一名程序员时，利用业余时间创建了umlchina，潜心研究需求和设计技能。2002年开始对外提供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
· · · · · · (收起)
读后感
读完潘老师的这本大作，我的总体印象是： 概念不清，用词不当，东拉西扯，逻辑错乱。 全书中那些令人啼笑皆非的荒唐错误结论和缺陷主要有： - 设计约束是需求，但既不是功能需求，也不是非功能需求（潘老师不懂最简单的二元逻辑？）； - 全书对于“涉众”（Stakeholder）这...
评分读完潘老师的这本大作，我的总体印象是： 概念不清，用词不当，东拉西扯，逻辑错乱。 全书中那些令人啼笑皆非的荒唐错误结论和缺陷主要有： - 设计约束是需求，但既不是功能需求，也不是非功能需求（潘老师不懂最简单的二元逻辑？）； - 全书对于“涉众”（Stakeholder）这...
评分也许是因为我已经有多年的经验，我认为此书超过我过去看过的任何一本讲具体软件过程方法的书。 无论如何，我认为做过二、三年软件开发的程序员，应该人手一册此书。更不用说，从事产品设计、业务/需求分析，软件项目经理，将软件“愿景”落实到可编码开发阶段的人。 特别推荐...
评分读完潘老师的这本大作，我的总体印象是： 概念不清，用词不当，东拉西扯，逻辑错乱。 全书中那些令人啼笑皆非的荒唐错误结论和缺陷主要有： - 设计约束是需求，但既不是功能需求，也不是非功能需求（潘老师不懂最简单的二元逻辑？）； - 全书对于“涉众”（Stakeholder）这...
评分患者确实是医院的执行者 p.60 储户来存钱，企业来贷款，人民银行要对它作监管，这些就是该商业银行的执行者 p.54 ... 请问这些是中国人的语文吗？ 如此荒唐造句的原因在于作者固执地一定要把 Actor 译作“执行者”。而 UML 中的 Actor 其实代表了业务/系统的直接用户、外部...
用户评价
主要是用例图和序列图的画法，举例略啰嗦。
评分很有启发，值得反复阅读和思考，如果能加上习题解析就更好了！
评分业界领域专家的书籍一般比理论界的专家的书籍更加具体可操作，也更加贴近业界当前的实践。I hear and I forget. I see and I remember. I do and I understand。先见全局，再摸细节，力荐！
评分很有启发，值得反复阅读和思考，如果能加上习题解析就更好了！
评分算是不错的需求和用例的入门书，优点是案例翔实，其中有些图的画法值得借鉴，案例也具有参考性；缺点是偏口语化的文风，方法论不成体系，有些术语的翻译前后不一致。总体还是值得一看
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 qciss.net All Rights Reserved. 小哈图书下载中心 版权所有