敏捷建模（AM）是一种基于实践的过程，它描述了怎样才能够成为一个高效的建模人员。本书研究了AM的价值观、原则和实践，描述了用来提高建模人员工作效率的技术，而且书中还重新思考了与软件开发有关的几个重要问题，例如，怎样编写文档、怎样组织建模会议和建模团队以及UML适用于什么地方等。此外，还详细研究了怎样在XP项目中有效地建模，并解释了怎样在采用Rational统一过程（RUP）或者企业统一过程（EUP）的项目中简化建模工作。本书既适用于想知道在XP项目中怎样建模以及在RUP项目中怎样简化建模工作的开发人员和建模人员，也适用于想了解"敏捷开发"的项目经理和过程专家。
在这本具有创新思想的书中，Scott w. Ambler谈到如何做到以下几点：
◆坚定不移地采用快速移动和敏捷软件开发方法来为XP项日建模
◆将建模规程简单化，将UP的工作流程简单化，而同时又不会失去这些规程所带来的真正益处
◆利用建模来探索问题的解决方案或使交流更容易
◆有效地应用UML，并将其延伸到其他方法学中，更好地满足你的开发需要
◆通过编写敏捷文档来减轻在项目中建立文档的负担
◆使用简单建模工具，如索引卡片和白板，并且知道何时
◆使用复杂的CASE工具
◆重新考虑有关工作区域、建模团队和建模会议等问题
本书配套网站：http://www.wiley.com/compbooks/ambler
作者简介
Scott w. Ambler 是Ronin International公司(www．ronin—intl．com)的总裁和高级咨询师，该公
司是软件服务咨询公司，专门研究软件过程指导和基于对象／组件的软件体系结构与开发。Scott
是很多书的作者和合作者，他与Larry Constantine同是CMP出版社统一过程丛书的主编，同时他
也是《Software Development》杂志的特约编辑和《IBM developerWorks》的专栏作家。他的研
究领城涉及UML、软件开发、OOPSLA、Object Expo、Java Expo和应用程序开发。
如果你正在读这个前言，那你很可能是想确定是不是应该买这本书，我喜欢你的态度！为了帮助你做出这个决定，我将很快地回答几个你最可能会问的重要问题。
什么是敏捷建模
敏捷建模（Agile Modeling, AM）是一种基于实践的过程，它描述了怎样才能够成为一个高效的建模人员。当前的建模方法经常被证明有“功能障碍”，一个极端是根本就没有建模存在，当软件被证明是没有经过很好思考的时候，这经常会导致大量的返工；另一个极端是生成过多的模型和文档，这让开发工作慢得像蜗牛一样。AM帮你找到建模的最佳点，在这一点上你既进行了足够的建模，以保证有效地研究和记录系统，但又没有过多地建模以致变成减慢项目进度的负担。
想要在软件开发上采用敏捷方法的项目团队能够并且也应该使用AM的技术，特别是那些遵循极限编程（XP）、DSDM、SCRUM或FDD等敏捷过程的团队。即使在没有采用纯敏捷方法的项目中，也能用AM来改进而且能够经常简化建模工作。
这本书讲了什么
这本书一开始研究了AM的价值观、原则和实践，描述了用来提高建模人员工作效率的技术。尽管可能害怕向别人承认，但你很可能会发现，自己实际上已经在遵循其中的一部分实践，你也很可能会发现新的有效建模的方法。这本书也重新思考了与软件开发有关的几个重要问题，例如，怎样写文档、怎样组织建模会议和建模团队，以及UML适用于什么地方等。正如这本书的标题所表达的，它详细研究了怎样在XP项目中有效地建模，与你可能听到过的恰好相反，建模是XP的一个重要组成部分。这本书还解释了怎样在采用Rational统一过程（RUP）或者企业统一过程（RUP）的项目中简化建模工作。
这本书没讲什么
这本书没有告诉你怎样创建模型。例如，它没有描述写用户故事、用例以及业务规则的步骤。这本书也没有打算成为对UML、数据建模或者以用法为中心的设计（usage-centered design）的介绍。这本书着眼于更大的图景，着眼于建模的过程，而不是微小的细节。这非常与XP描述了开发软件的过程，但没有描述怎样实际去写程序非常类似。
而且，这本书与你以前读过的任何关于软件建模的书都不同。以前讲建模方法学的书一般是先描述几个建模制品，例如，用例、顺序图、类图等，然后描述一个使用这些制品建模软件的方法。AM采取了一种完全不同的方式，它描述了建模的技术，但对于创建模型的类型并不坚持要求。AM只是建议你学习怎样使用种类广泛的建模制品，并努力随着时间不断往你的知识工具箱里加入更多的东西。在其他建模技术随着其下层技术的变化而消失的同时，我相信你会发现AM的原则和实践能够经受住时间的考验，因为它们是真正基础的东西。
我是谁
虽然住在加拿大多伦多北面，但我却是位于丹佛市的Ronin International公司的高级顾问和总裁。我从20世纪80年代中期开始就一直在开发软件，从20世纪90年代初开始就一直在建造面向对象软件。我积极地与客户合作创建用于关键任务的软件，并且利用业余时间在书、杂志和在线白皮书中写一些与自己经验有关的内容。最近几年我一直致力于软件过程问题，包括统一过程（UP）等指令性过程以及极限编程（XP）等敏捷过程，帮助各种组织机构，使他们在软件开发方法上变得更加有效。我也喜欢在软件项目中扮演积极的角色，身为高级开发人员或团队负责人，只要可能我就会卷起袖子干活。
你是谁
你很可能是一个开发人员或建模人员，很想要提高自己作为一个软件专业人员的效率。你想知道在XP项目中怎样建模，或者在RUP项目中怎样简化建模工作。你甚至有可能是一个项目经理或者过程专家，想要了解“敏捷开发这东西”到底是怎么回事。
在Scott请我为这本书写序时，我感到既高兴又惊讶。我感到高兴有几个原因：能够被别人重视总是一件好事情，能够与一本写得这样好的书联系起来当然更好，并且敏捷方法（特别是极限编程）目前也是我自己关心的重点。我感到惊讶，原因在于我是最早和最大声地向Scott“建议”不要把精力放在这个问题上的人之一。“我会进行解释，可说来话长，还是让我概括一下吧。”
对我来说，软件开发最好是在专业化程度尽可能低的情况下完成。我提倡并且相信，最好的结果来自于这样的人组成的团队：他们尽自己所能在任何地方以任何方式做出贡献，而不考虑谁是架构师、建模人员、设计人员、程序人员、测试人员。这不是说我们都必须成为某种像神一样多才多艺的软件人才，而是说我们应该一起同心协力尽自己所能在任何方面做出贡献。
而且，软件开发（和前面一样，对我来说）最好在尽可能少建模的情况下完成。软件开发的意义在于开发软件，在准备工作上花的时间过长，留给重要部分—实际创建坚实的、设计良好的、高质量的软件的时间就会过少。软件的质量与在开始建造系统之前用最新建模工具画的模型并非总是相关的。
由于上面的原因，在Scott提议并启动他的敏捷建模论坛和网站的时候，我是反对这个主意的。我担心注意力过于集中在建模上会减少对整合团队和构建优秀软件所需技能的关注。我在Scott的论坛和私人电子邮件中就是这么说的，一点都不含糊。
事情的结果是，Scott认识到了一些我没有认识到的东西。如果人们要一起合作用敏捷的方式开发软件，大家仅仅有爱、理解和激情是不够的，还必须有技能。团队必须要有分析、建模、设计、编程、测试等所有作为优秀软件基础的各个方面的技能，他们在使用这些技能的时候必须始终与敏捷软件开发的价值观保持一致，这些价值观中的一条就是我们在敏捷宣言中所写的：“个人和交互高于过程和工具。”
这就是Scott在他的论坛、网站和这本书中开始做的事情。他向我们解释如何在敏捷项目的环境中进行有效、轻量级的建模；向我们解释如何在非敏捷的项目中进行建模，着眼于使非敏捷的项目变得更加敏捷。最重要的是，他做这些事情是基于一整套价值观、原则和实践的，而这些价值观、原则和实践能够贯穿到个人或团队的建模方法之中。在关注你所需要的详细的建模技能和实践的同时，他始终注视着软件开发竞争的全局。
Scott讨论了简单工具的使用、所需工作空间的类型、团队所需的组成方式，以及它们怎样结合成一个整体。我特别喜欢引用电影《Starship Troopers》（星舰战队）中Rasczak中士的那句话：“我只有一条纪律：每个人都战斗，不许有人退出，否则我会亲自毙了他。”Scott把建模与从极限编程到统一过程的各种事情都联系了起来，并且做得非常好。
写序的职责之一就是指出谁应该读这本书，我的建议是：如果你是一个需要将建模技能作为开发工作一部分的软件开发人员，也就是说，如果你是软件开发人员，那么就应该读这本书；如果你是一个需要让自己的工作成果适用于当前迅速变化的软件开发的建模人员，也就是说，如果你是建模人员，那么就应该读这本书；如果你是一个需要了解敏捷软件开发对你的项目意味着什么的软件开发经理，也就是说，如果你是软件开发经理，那么也应该读这本书。无论你在以何种形式参与当今的软件开发，这本书都能够对你有所帮助。
Scott的这本书讲述了在需要迅速地向项目关系人交付高质量软件的软件项目中，进行有效地建模所需的技能。干得不错，Scott!
Ron Jeffries
XP运动先驱
Scott W.Ambler：Scott W.Ambler: Scott W. Ambler是软件开发方法年轻一代的领军人物之一，在理论和实践上的造诣都很深厚。作为一位高级咨询师，他一直积极参与全球各种大型软件开发和过程改进项目。同时，他还是一位视野广阔的方法学者，是《Software Development》杂志的专栏作家，撰写了多部颇受推崇的著作，其中包括《The Object Primer》、《Agile Modeling》、《The Elements of UML Style》、《More Process Patterns》等。
张嘉路 等：暂无简介
随着对软件的需求越来越大，要求越来越高，各软件开发机构也越来越迫切地需要能够更有效地开发更高质量软件的方法。在国内因为开发大型软件的经验相对较少，这一点尤其显得突出。
在这种情况下，有助于提高软件开发有效性和质量的工具引起了普遍的关注，特别是软件开发过程、模型和文档。有的观点认为，只要有了好的过程，开发软件就可以像传统的工厂制造产品那样简单。但并非每个人都同意这个观点。特别是如何建立和贯彻适合于自己组织和项目的软件开发过程，更是仁者见仁智者见智。由于工作的关系，我们接触了不少产品/项目经理、投资人以及一些开发和测试人员。以下是我们常常听到的议论：“这个开发过程看起来不错，但我们企业太小，没有人手来实行它”，“我也不知道为什么要写这些文档，反正经理要求写，写就是了”，“客户总是变来变去，项目简直没法进行”或者“我们的项目一天到晚开会讨论，我都没时间写代码了”，问题究竟出在哪里呢？
相信您在读完本书的第1章之后，一定会找到答案或者说有所共鸣，并且迫不及待地想继续寻找解决之道。在本书中，作者Scott Ambler基于自己丰富的经验和敏锐的洞察力，就如何在软件开发过程中激发人的创造力和主观能动性并加以管理给出了一些原则和实践。不仅如此，他还结合当今软件开发界最常用的Rational统一过程（RUP）和极限编程（XP）举出了大量生动有趣的实例。那么，您真能够在其中找到制胜法宝吗？其实，我们翻译本书的目的就是希望能够帮助读者对软件开发中的过程、建模、文档等问题有一个更全面、更客观的理解。至于您是否找到了一颗适合您的“银弹”，那就全在于您对敏捷建模的体会了。
本书由张嘉路、朱鹏、程宾共同翻译，在翻译过程中得到了尤晋元教授的大力支持和悉心指导，张宏、曾玲玲、王跃华等也参与了本书的译校工作，在此深表感谢！
由于时间和水平有限，难免会有一些错误，希望广大读者予以指正。
译 者
2002年12月
第一部分 敏捷建模简介
第1章 绪论 3
1.1 进入敏捷软件开发 5
1.1.1 敏捷软件开发宣言 5
1.1.2 敏捷软件开发的原则 6
1.2 敏捷建模 7
1.2.1 谁是敏捷建模人员 9
1.2.2 敏捷建模概述 9
1.2.3 什么是敏捷模型 10
1.2.4 什么是（或不是）敏捷建模 12
1.3 SWA在线案例研究 14
1.4 本书概览 14
第2章 敏捷建模的价值观 17
2.1 交流 17
2.2 简单 18
2.3 反馈 19
2.4 勇气 20
2.5 谦虚 22
2.6 老生常谈之后 22
第3章 核心原则 25
3.1 软件是你的首要目标 25
3.2 支持后续工作是你的第二目标 26
3.3 轻装前进 26
3.4 主张简单 27
3.5 包容变化 27
3.6 递增的变化 28
3.7 有目的地建模 28
3.8 多种模型 29
3.9 高质量的工作 31
3.10 快速反馈 31
3.11 最大化项目关系人的投资 33
3.12 为什么需要核心原则 33
第4章 补充原则 35
4.1 内容比形式更重要 35
4.2 每个人都可以向别人学习 37
4.3 了解你的模型 37
4.4 适应本地情况 38
4.5 开放和诚实的交流 38
4.6 相信直觉 38
4.7 从这些原则中获益 39
第5章 核心实践 41
5.1 迭代和增量建模的实践 42
5.1.1 使用合适的制品 42
5.1.2 并行创建多个模型 43
5.1.3 迭代到其他的制品中 45
5.1.4 小增量建模 47
5.2 有效团队协作的实践 47
5.2.1 与他人一起建模 47
5.2.2 项目关系人的积极参与 48
5.2.3 集体所有 49
5.2.4 公开展示模型 50
5.3 简单性的实践 50
5.3.1 创建简单的内容 50
5.3.2 简单地描述模型 51
5.3.3 使用最简单的工具 52
5.4 验证工作的实践 52
5.4.1 考虑可测试性 53
5.4.2 用代码验证 53
第6章 补充实践 55
6.1 提高生产率的实践 55
6.1.1 应用建模标准 55
6.1.2 渐进地应用模式 57
6.1.3 复用已有的制品 58
6.2 敏捷文档的实践 58
6.2.1 丢弃临时模型 58
6.2.2 契约模型正式化 59
6.2.3 在有危害时才更新模型 60
6.3 有关动机的实践 62
6.3.1 通过建模来理解 62
6.3.2 通过建模来交流 63
6.4 真正的好主意 64
6.4.1 了解工具 64
6.4.2 重构 64
6.4.3 测试优先设计 64
6.5 如何在项目中安排敏捷建模的
实践 64
第7章 从混乱到有序：AM的实践如何
结合到一起 67
7.1 核心实践 67
7.1.1 与高效团队协作相关的实践 68
7.1.2 与迭代和增量开发相关的实践 68
7.1.3 促进简单性的实践 69
7.1.4 验证工作的实践 69
7.2 补充实践 69
7.2.1 与文档相关的实践 69
7.2.2 与动机相关的实践 70
7.2.3 提高生产率的实践 70
7.3 各类实践如何关联 70
7.4 混乱而有序：Chaordic 71
7.5 展望 72
第二部分 实践中的敏捷建模
第8章 交流 75
8.1 怎样交流 75
8.2 影响交流的因素 76
8.3 交流与敏捷建模 78
8.4 有效的交流 78
第9章 培养敏捷文化 81
9.1 消除有关建模的误解 81
9.1.1 误解1：模型＝文档 81
9.1.2 误解2：可以在一开头就把什么
都想清楚 82
9.1.3 误解3：建模意味着重量级软件
过程 82
9.1.4 误解4：必须“冻结”需求 82
9.1.5 误解5：设计是“刻在石头里”的 82
9.1.6 误解6：必须使用CASE工具 83
9.1.7 误解7：建模是浪费时间 84
9.1.8 误解8：世界绕着数据建模转 84
9.1.9 误解9：开发人员都知道怎样
建模 85
9.2 从小处着眼 85
9.3 放松一点要求 86
9.4 坚决支持项目关系人的权利和义务 87
9.5 重新考虑给项目关系人的报告 88
第10章 使用可能的最简单的工具 91
10.1 用简单工具敏捷建模 92
10.1.1 简单工具的优点 92
10.1.2 简单工具的缺点 93
10.1.3 何时应该使用简单工具 93
10.1.4 用技术支持简单工具 93
10.2 模型的演化 95
10.3 用CASE工具敏捷建模 99
10.3.1 选择CASE工具 99
10.3.2 克服关于CASE工具的误解 100
10.3.3 生成源代码 101
10.3.4 生成文档 102
10.4 使用媒体 102
10.5 在模型上使用工具的影响 103
10.6 在实践中使用最简单的工具 103
第11章 敏捷工作区域 105
11.1 敏捷建模室 105
11.2 有效的工作区域 107
11.3 在实践中应用 108
第12章 敏捷建模团队 111
12.1 招募少量优秀的开发人员 111
12.2 认识到在敏捷中没有“我” 114
12.3 要求每个人积极参与 115
12.4 团队一起建模 116
12.5 在实践中应用 117
第13章 敏捷建模会议 119
13.1 建模会议持续时间 119
13.2 建模会议的类型 120
13.3 建模会议的参加者 122
13.4 建模会议的正式程度 124
13.5 在实践中应用 125
第14章 敏捷资料 127
14.1 人们为什么写文档 128
14.2 模型什么时候成为永久文档 130
14.2.1 与资料相关的考虑因素有哪些 132
14.2.2 “轻装前进”是什么意思 134
14.2.3 一份文档什么时候是敏捷的 136
14.2.4 应该创建什么类型的文档 137
14.2.5 何时应该更新文档 140
14.2.6 有效的资料传递 141
14.2.7 增加资料敏捷性的策略 141
14.2.8 在实践中应用 144
第15章 UML及其延伸 145
15.1 UML并不充分 145
15.2 UML过于复杂 147
15.3 UML并非方法学也不是过程 147
15.4 别再想着可执行UML
（至少现在） 148
15.5 在实践中应用UML 149
第三部分 敏捷建模和极限编程（XP）
第16章 澄清事实 153
16.1 建模是XP的一部分 154
16.2 文档是必需的 154
16.3 XP和UML 156
16.4 结论 157
第17章 敏捷建模与极限编程 159
17.1 AM和XP之间潜在的契合 159
17.2 重构和AM 161
17.3 测试优先开发和AM 161
17.4 应该采取哪些AM实践 162
第18章 贯穿XP生命周期的敏捷建模 163
18.1 探索阶段 164
18.2 计划阶段 164
18.3 迭代到发布阶段 166
18.4 产品化阶段 168
18.5 维护阶段 169
18.6 如何应用 169
第19章 XP探索阶段的建模 171
19.1 优先定义初始需求 171
19.2 比喻、架构和骨架 174
19.3 为项目设定一个基础 176
第20章 XP迭代中的建模：条目搜索 177
20.1 任务 177
20.2 物理数据库模式建模 178
20.3 观察到的事实 181
第21章 XP迭代中的建模：订单求和 183
21.1 任务 183
21.2 用需求建模来补救 184
21.3 从外界专家那里寻求帮助 185
21.4 简短的设计会议 186
21.5 契约模型正式化 187
21.6 将来有变化怎么办 188
21.7 观察到的事实 189
21.8 如何在实际工作中应用 189
第四部分 敏捷建模和统一过程
第22章 敏捷建模和统一过程 193
22.1 在统一过程中如何建模 193
22.2 AM与UP的契合到底有多好 194
22.3 选择变得敏捷些 197
第23章 贯穿统一过程生命周期的
敏捷建模 199
23.1 建模规程 199
23.1.1 业务建模规程 200
23.1.2 需求规程 201
23.1.3 分析和设计规程 202
23.1.4 基础设施管理规程 203
23.2 非建模规程 204
23.2.1 实现规程 204
23.2.2 测试规程 205
23.2.3 项目管理规程 205
23.2.4 配置和变更管理规程 205
23.2.5 环境规程 206
23.2.6 部署规程 206
23.2.7 运行和支持规程 206
23.3 如何应用 207
第24章 敏捷业务建模 209
24.1 一个业务/基本用例模型 209
24.2 一个简单的业务对象模型 211
24.3 一份敏捷的补充业务规格说明书 212
24.4 一个业务愿景 214
24.5 如何在实践中应用 215
第25章 敏捷需求 217
25.1 上下文模型 217
25.2 用例模型 220
25.3 用例故事板 223
25.4 补充规格说明书 226
25.5 如何在实践中应用 227
第26章 敏捷分析和设计 229
26.1 在统一过程中重新考虑分析和设计
模型 230
26.2 架构建模 231
26.3 创建用例实现 235
26.4 是更新用例的时候了吗 238
26.5 是使用CASE工具的时候了吗 241
26.6 设计类建模 242
26.7 数据建模 244
26.8 包容变化 246
26.9 如何在实践中应用 247
第27章 敏捷基础设施管理 249
27.1 基础设施模型 249
27.2 基础设施建模 251
27.2.1 自顶向下建模 252
27.2.2 自底向上建模 252
27.2.3 比较这两种方式 252
27.3 设定建模标准和指导原则 253
27.4 核心基础设施团队 254
27.5 采用敏捷建模的核心架构团队 255
27.6 如何在实践中应用 256
第28章 在统一过程项目中采用敏捷
建模 259
第五部分 展望
第29章 采用敏捷建模或者克服逆境 265
29.1 估算契合程度 265
29.1.1 认识到敏捷建模什么时候管用 266
29.1.2 认识到敏捷建模什么时候
不管用 267
29.2 保持简单 268
29.3 克服组织结构上的和文化上的挑战 268
29.3.1 持怀疑态度的开发人员 269
29.3.2 过分热心的过程警察 269
29.3.3 有权力的催着要纸的人 270
29.3.4 菜谱哲学 270
29.3.5 不能接受批评 271
29.3.6 由于害怕失去所有的人而导致
过度的文档 271
29.4 克服与项目有关的挑战 272
29.4.1 分布式的开发 272
29.4.2 移交给其他团队 273
29.4.3 固定价格契约 274
29.5 考虑完全采用AM之外的其他途径 274
29.6 如何在实践中应用 275
第30章 结论：决心成功 277
30.1 对敏捷建模常见的误解 277
30.2 什么时候是（或不是）在敏捷建模 278
30.3 敏捷建模资源 279
30.4 几个临别的想法 279
附录A 建模技术 281
词汇表 291
参考文献 301
