软件方法（上册）

作品简介

UMLChina首席专家潘加宇的第一本书。作者在为软件组织提供建模咨询和培训服务超过十年后，把他的经验和感悟写成了本书。《软件方法：上册，业务建模和需求》从“利润＝需求－设计”开始，用市场经济的思想讲解软件开发中需求和设计的道理，以及统一建模语言UML在需求和设计中的应用。本书还破解了软件开发领域流行的一些心灵鸡汤式宣传。

潘加宇，umlchina首席专家。在1999年还是一名程序员时，利用业余时间创建了umlchina，潜心研究需求和设计技能。2002年开始对外提供uml需求和设计的技术指导和训练服务，客户覆盖了各个领域的领袖企业。

作品目录

• 推荐序
• 致谢
• 前言
• 推荐阅读
• 第1章　建模和UML
• 1.1　粗放经营的时代已经远去
• 1.2　利润＝需求－设计
• 1.3　核心工作流
• 1.4　UML简史
• 1.5　各工作流中的UML
• 1.6　基本共识上的沟通
• 1.7　沟通仅限于开发团队内部
• 1.8　方法和过程
• 1.9　案例介绍
• 1.10　模型的组织
• 1.11　工具操作
• 第2章　愿景
• 2.1　最不可缺的工件
• 2.2　愿景的定义
• 2.3　老大
• 2.4　把产品当项目——定位具体的组织（人群）
• 2.5　寻找老大：要点和典型错误
• 2.6　可度量的目标
• 2.7　揣摩目标度量
• 2.8　涉众利益
• 2.9　可以积累的财富
• 2.10　案例
• 2.11　工具操作
• 第3章　业务建模之业务用例图
• 3.1　软件是组织的零件
• 3.2　业务建模步骤1-1：选定要改进的组织
• 3.3　业务建模步骤1-2：组织的业务用例图
• 3.3.1　业务执行者
• 3.3.2　业务工人和业务实体
• 3.3.3　寻找业务执行者
• 3.3.4　业务用例
• 3.4　案例
• 3.5　工具操作
• 3.6　总结
• 第4章　业务建模之业务序列图
• 4.1　描述业务流程的手段
• 4.2　业务序列图要点
• 4.2.1　消息代表责任分配而不是数据流动
• 4.2.2　聚焦于系统之间的协作
• 4.2.3　只画核心域相关的系统
• 4.2.4　把时间看作特殊的业务实体
• 4.3　业务建模步骤1-3：现状业务序列图
• 4.3.1　错误：把“现状”误解为“纯手工”
• 4.3.2　错误：把“现状”误解为“规范”
• 4.3.3　错误：以待开发系统为中心拼凑流程
• 4.4　案例
• 4.5　工具操作
• 4.6　业务建模步骤1-4：改进业务序列图
• 4.6.1　改进一：物流变成信息流
• 4.6.2　改进二：改善信息流转
• 4.6.3　改进三：封装领域逻辑
• 4.6.4　阿布思考法
• 4.7　案例
• 4.8　工具操作
• 第5章　需求之系统用例图
• 5.1　系统执行者要点
• 5.2　需求步骤2-1：识别系统执行者
• 5.3　系统用例要点
• 5.4　需求步骤2-2：识别系统用例
• 5.5　用例的进一步讲解
• 5.5.1　错误：玩弄“复用”
• 5.5.2　错误：玩弄“层次”
• 5.5.3　错误：玩弄“子系统”
• 5.5.4　错误：模糊的价值
• 5.5.5　提示：大用例无妨小用例
• 5.5.6　提示：用例的命名
• 5.6　案例
• 5.7　工具操作
• 5.8　总结
• 第6章　需求之系统用例规约
• 6.1　需求步骤2-3：书写系统用例规约
• 6.1.1　前置条件和后置条件
• 6.1.2　涉众利益
• 6.1.3　基本路径
• 6.1.4　扩展路径
• 6.1.5　补充约束
• 6.2　案例
• 6.3　工具操作
• 第7章　需求之需求启发
• 7.1　启发障碍
• 7.2　需求启发手段
• 7.2.1　研究资料
• 7.2.2　问卷调查
• 7.2.3　访谈
• 7.2.4　观察
• 7.2.5　研究竞争对手
• 7.3　需求工程师
• 7.3.1　好奇心
• 7.3.2　探索力
• 7.3.3　沟通力
• 7.3.4　表达力
• 7.3.5　热情