本书内容包括
Ivar Jacobson文集，闪烁着突破性的思想火花。
对文章进行了更新，纳入了新的进展和术语。本书符合“UML标准”。
Ivar Jacobson最新的观点，是对他以前工作的回顾及对未来的展望。
本书是计算机工作者进一步了解统一过程及其实践实现的重要读物，对面向对象的建模者、管理者和想在实践(不仅仅是理论)中使用面向对象概念的架构师来说极有价值。
本书是世界软件开发方法大师lvar Jacobson的文集，反映了他对软件开发的深刻思考。全书内容由他的同事Stefan Bylund进行了改编，反映了最新进展。涉及的基本主题包括：方法学、大规模系统架构、用例、开发工具支持，基于构件的开发。迭代开发及软件开发的主要概念。作为统一软件开发过程的核心人物，Ivar Jacobson在本书中还追溯了统一软件开发过程的创立过程。
本书的作者Ivar Jacobson是统一建模语言的三大创始人之一。本书从Objectory与Rational的合并说起，详细介绍了统一软件开发过程之路。包括统一软件开发的概念与简史，过程和工具，用例工程，架构与大规模系统。本书共分七部分，每一部分都以“Ivar语录”结束，总结了该部分的主题。本书是了解统一软件开发过程的必备书。
作者简介：
Ivar Jacobson博士是Objectory方法的创立者。是Objectory公司的创始人。曾任Rational公司副总裁。他是用例和用例驱动开发方法“之父”， 是统一建模语言(UML)和统一软件开发过程的创始人之一。
前言
在去年圣诞节期间，我做了一件很长一段时间一直想要做的事情—搜检了一遍旧纸堆，以便好好清理一下办公室。我很爱扔旧东西，其中最旧的文章是我在1985年的博士论文。我仔细审视这些文章的参考书目，发现了在1967~1970年间写的一些报告。这不由得使我想起这些文章最初是如何写成的。
在1967年我们并没有个人电脑，如今这很难叫人相信，而那时我们是在打字机上写文章的！工程师并不亲自打字：我们先用铅笔写在纸上，然后用剪刀和胶水通过剪贴来修改文章。随后，秘书会把它打出来，不过这已经是数天以后的事了。故而在我们看到打字版本的文章时，可能已经准备好要做进一步的改动了。其结果是，我们写不了多少东西。
不仅如此，由于我爱把没用的东西扔掉，所以并没有留下什么拷贝。因此，在1978年，当爱立信AXE电信系统的成功终于变为现实的时候，总裁Bj歳n Svedberg向我索要关于这一成功背后的技术的具有历史意义的记录，而在我的办公室里一份记录都没有。
由于这是5年前所进行的工作，原有部门也没有了相关的记录。我不得不四处打电话询问这些旧文档的下落，回答是它们可能被存放在地下室的旧文件柜中—如果我运气好的话。
我冲到那里，发现很长的走廊里摆放着一组巨型文件柜，抽屉从地板一直排到天花板。我花了一个小时才找到存放着我所在部门十年来所有文档的那个抽屉。为了找到想要的文档，我不得不仔细检视一个又一个的活页夹。经过数小时的寻找，终于找到了一堆有我签名的相关文档（我的签名很突出，比我现在的书法更易于辨认）。如今，有了互联网，很难叫人相信我们当初是这么查找东西的。
在那儿究竟找到了什么？
那便是基于构件的软件开发！
不过，关于我们在早期是如何工作的记录着实不多，我们那时的重点是把软件做出来。也就是说，从架构开始开发其模型—需求、设计、实现和测试—并使之成长为一个成熟的系统。而且，所有这些都是用瑞典文记录的。
当基于构件开发的最初思想在我脑海中产生的时候，我对它进行了一些提炼。这些年我基本上就在做这件事情，但这些年的确让人激动。尤其令人兴奋的是能和那些才华横溢的人们一起工作，他们教给我很多关于软件的知识。特别是G歳an Hemdal，他从头到尾参与了构件的实现工作，从设计开始直到可执行代码（包括编程语言、操作系统和计算机架构）；Dines Bjorner指导我如何将建模语言加以形式化；而Walk Royce则向我解释了在基于构件开发的前提下，如何进行迭代的和风险驱动的开发工作。还有所有造就了统一过程和统一建模语言今日地位（一个标准的开发平台）的具有传奇色彩的人们。
然而未来更令人兴奋。
现在有了这样一项技术，它可以成功地构造出我们所需要的软件，使我们的生活更加轻松。现在我们能够构建以前做梦都不敢想的系统。随着因特网的兴起，很多30年前、20年前甚至5年前的开发实践都被改变了。在这个新世界里，电子商务、以客户为中心、创新设计、业务工程、分布式、开放性、标准和全球可用性等都成了新的基本词汇。
但是，并非什么都是新的。我们还是需要构件，还是需要用例、架构和迭代。既然统一过程和统一建模语言都是可扩展的，我们就不必再去重新发明“轮子”来支撑这个新世界，可以在现有的基础上，继续对其加以精炼。
我对于统一过程和统一建模语言的未来寄予很高的期望，它们有能力在新的应用领域和新的技术平台上成长并发挥作用。
有件事情我们可以肯定回答，那就是未来在召唤，欢迎每个人和我一起加入前进的潮流中。
Ivar Jacobson
序
能有机会编辑Ivar Jacobson博士的这一系列文章，我很激动。这些文章涉及了与计算机科学领域相关的很多主题和难点，同时也表述了Ivar个人对这些问题的见解。而这些见解正以这样或那样的方式得到越来越多人的认可，这些观点已经在很多领域获得了商业的成功，同时也为作者赢得了大师的美誉。
所有这一切都可以追溯到20世纪60年代，那时候的Ivar Jacobson博士还只是一个与复杂电信系统做“斗争”的年轻技术人员，而软件正逐渐成为这些系统的核心。在1967~1969年期间，他帮助引入了构件和基于构件的开发，并因此造就了瑞典历史上最大的商业成功—爱立信的AXE交换机。正如我们看到的，即便是今天基于构件的方法，如微软公司的COM+，其底层的基本原则和30年前竟然别无二致！那个时代的贡献包括：应用于构件和子系统上的顺序图、协作图和状态图，以及隐藏在构件开发的标准方法背后的无数新颖思想。
在此基础之上，Jacobson博士把他的主要灵感都投入到规范和描述语言（SDL）1 之中，这是第一个基于对象和构件技术的标准语言的蓝本，它于1976年开始开发，如今仍然是电信领域的一项标准。
除此之外，Jacobson博士还是公认的用例和用例驱动开发方法“之父”，这些方法应用在业务建模和软件建模领域。用例已经成为获取软件系统需求的主流技术，而且为每一个客户（业务客户或者软件系统客户）提供了他们所渴望的价值链。
Jacobson博士创立了第一个工程化的业务和软件开发工程—Objectory，现在它已经发展成为业界标准的统一过程（Rational统一过程）。这种软件开发过程是建立在统一建模语言的基础之上的，而统一建模语言具有迭代、以架构为中心、用例驱动和风险驱动的特征。
另外，Jacobson博士也是统一建模语言的三大创始人之一。统一建模语言是基于构件开发的新的面向对象蓝图语言。他的很多新颖的思想随着UML的发展而载入标准之中（UML的另外两位创始人是Jim Rumbaugh和Grady Booch）。
令人心动的是，所有这些工作都反映在本书收录的一系列文章中，因此本书也是对Jacobson博士其他著作2,3,4,5的一个有益的补充。这些文章都根据新的发现、术语和UML（也就是说，本书是UML兼容的）进行了更新和精炼。而且，每一部分开始都有对收录文章的介绍以及简要的目录，每一部分的结尾都有一段与该主题相关的Jacobson博士的访谈。这些题为“Ivar语录”的访谈其实上是我和Jack Jackson、Adriano Comai、Bob Hathaway先前对Jacobson博士采访的一个汇编。
欢迎您阅读本书，让我们在通往统一软件开发过程的大路上任意驰骋吧！
Stefan Bylund
参考文献：
[美]Ivar Jacobson,Stefan Bylund：暂无简介
程宾 朱鹏 张嘉路：暂无简介
如今在软件开发界，Rational所倡导的统一软件开发过程恐怕无人不知；而在电信界，爱立信的AXE系统数十年来也是享有盛名。在这两者的背后，我们可以发现它们共同的“父亲”：Ivar Jacobson。作为大名鼎鼎的“三朋友”（Three Amigos）之一，Jacobson博士在面向对象领域做出了许多贡献，而这正源于他在爱立信公司开发AXE系统时所积累的经验。
本书其实是Ivar Jacobson博士所著的面向对象软件工程文集。这一篇篇的文章不仅铺就了一条统一软件开发过程之路，而且还勾勒出了软件对象理论的发展过程，而这些方面可能是很多读者还不太熟悉的。通过阅读本书，可以在品味其中所蕴含的哲学思想的同时，将书中所提供的工程经验运用到实际工作中，真可谓受益良多。
由于工作的关系，我们既使用过爱立信公司的AXE交换机系统，又使用过Rational公司的RUP软件开发过程，所以在翻译文集的时候，深有所感，许多平时所积累的疑惑都得到了解答。当然，由于水平有限，难免有错漏之处，欢迎广大读者批评指正。
本书是程宾、朱鹏和张嘉路三名译者共同努力的结果。在本书的翻译过程中，还得到了上海交通大学尤晋元教授的关心和指导。曾玲玲、张宏、王跃华、薛宗琪、陈俊等也参与和支持了本书的译校工作，在此一并致谢。
译 者
译者序
序
前言
致谢
第一部分 导 言
第1章 构造一个完整的解决方案 3
1.1 市场整合 3
1.2 战略协作 3
1.3 财务协作 3
1.4 软件工程过程 5
1.5 软件工程过程支持环境 5
1.6 培训、指导和咨询服务 6
1.7 以工业标准为目标 6
编者按 6
参考文献 7
Ivar语录 9
第二部分 简 史
第2章 发生在爱立信的故事：一次
巨大的商业成功 15
2.1 背景 15
2.2 产品 16
2.3 AXE方法：概览 16
2.4 成功背后的秘密 17
2.5 它是如何发生的 18
2.6 思想比产品更长久 19
2.7 结论 21
致谢 21
参考文献 21
第3章 一个雄心勃勃的目标：使用面向
对象技术的软件工业化开发 23
3.1 引言 23
3.2 软件的工业化开发 24
3.3 系统开发 26
3.3.1 系统开发—一个渐进变化
的过程 27
3.3.2 增量开发 28
3.3.3 原型 28
3.3.4 从分析到设计 29
3.4 面向对象 30
3.4.1 对象概念 30
3.4.2 类 30
3.4.3 继承 31
3.5 功能/数据架构和面向对象架构
的比较 31
3.5.1 功能/数据隔离 31
3.5.2 面向对象 32
3.5.3 面向对象可在所有的开发
工作流中使用 33
3.6 大型系统的开发 34
3.6.1 架构 35
3.6.2 方法 36
3.6.3 过程 37
3.6.4 过程更胜于方法 38
3.7 计算机辅助设计 40
3.8 ObjectOry简介 41
3.9 结论 42
致谢 43
参考文献和推荐读物 43
Ivar语录 45
第三部分 愿景的种子
第4章 方法之战到停火的时候了 51
4.1 存在着一场方法之战吗 51
4.2 需要一场方法之战吗 51
4.3 你是说标准化吗 51
4.4 能够达成何种结果 52
4.5 该怎么做 52
4.6 为什么要做 52
编者按 53
参考文献 53
第5章 是的，方法之后还存在生命：
软件开发过程 55
第6章 用对象技术进行业务流程再造 59
6.1 信息技术的角色 59
6.2 有哪些风险以及如何减少风险 60
6.3 正式的再造过程 60
6.4 面向对象的业务工程 61
6.5 小结 64
编者按 64
参考文献 64
第7章 用构件来构建：迈向成熟的
对象技术 67
7.1 面向对象的优点 68
7.2 还需要什么 68
7.3 用专门化的对象分类来管理复杂性 70
7.4 用分层结构来管理复杂性 72
7.5 小结 74
参考文献和推荐读物 74
第8章 通过对象取得成功：现实中
的重用 77
8.1 市场要求重用 77
8.2 从爱立信的成功中所获得的
重用经验 78
8.3 架构是成功的关键 78
8.4 组织起来管理架构 80
8.5 当然会有些问题 80
8.6 ……当然，我们还从别人那里
学了不少 81
8.7 将思想精炼成通用的使用框架 81
8.8 定义完善的方法 82
参考文献 83
第9章 现在该有一个对象建模
语言标准了 85
参考文献 88
第10章 只有软件和狗窝才不用
蓝图来建造 89
10.1 模型有助于思考 89
10.1.1 真实世界和模型 89
10.1.2 软件作为模型 90
10.2 什么是UML 91
10.3 一个突破 92
Ivar 语录 93
第四部分 过程和工具
第11章 超越方法和CASE：软件工程
过程及其集成支持环境 101
11.1 软件开发仍然是一门手艺 101
11.2 方法并非过程 102
11.3 方法的缺陷 103
11.4 CASE工具不能适应方法 103
11.5 第二代方法 104
11.6 我们需要什么 105
11.6.1 SEP用户组织 106
11.6.2 SEP用户 106
11.6.3 SEP开发组织 107
11.7 SEP支持环境 107
11.8 在投资和回报方面的区别 108
11.9 让SEP/SEPSE成为现实 109
11.10 结论 109
参考文献 110
第12章 再造软件工程过程 111
12.1 再造的技术框架 111
12.2 经验和结论 114
编者按 115
参考文献 115
第13章 设计软件工程过程 117
13.1 在SEP环境中工作 117
13.2 泛化及特化 120
13.3 SEP项目的动态特征 120
13.4 过程的裁剪—SEP框架的使用 121
13.5 经验之谈 121
13.6 对象的好处 122
参考文献和推荐读物 122
第14章 设计一个完整的软件工程过程
支持环境 125
14.1 SEPSE的设计始于SEP模型 125
14.2 SEPSE设计特性 128
14.3 SEPSE实现 129
14.4 SEPSE实现的一些重要方面 130
14.4.1 可用性 130
14.4.2 一致性和完备性 130
14.4.3 多角色支持 131
14.4.4 分层架构 131
14.4.5 面向对象的全局存储空间 131
14.5 SEPSE经验谈 132
参考文献 132
第15章 通过确定过程框架来建立
自己的过程 133
15.1 方法和过程的区别 133
15.2 商用软件开发组织就是软件
工程业务 134
15.3 特定的过程即是软件工程
业务的开发案例 134
15.4 是否所有的过程都能定义为
软件工程业务的开发案例 134
15.5 就面向对象系统而言，从普遍意义
上来讲，软件工程业务可以泛化成
可重用的框架 135
15.6 是否能在框架上构建具体的
软件工程业务 135
15.7 我们感受到了过程框架的威力 136
参考文献和推荐读物 136
Ivar语录 139
第五部分 用 例 工 程
第16章 用例建模基础 145
16.1 前言 145
16.2 用例的直觉认识 146
16.3 一个例子 147
16.4 用例建模 148
16.4.1 参与者的使用 149
16.4.2 用例的使用 150
16.4.3 用例类元 152
16.5 用例最适用的应用程序 153
16.6 用例交互：讨论要点 154
16.7 相关工作 155
参考文献 156
第17章 用例建模基础（续） 159
17.1 用例间的关系 159
17.1.1 泛化关系 160
17.1.2 扩展关系 162
17.1.3 泛化和扩展关系 163
17.2 小结 165
编者按 165
参考文献 166
第18章 用例和对象 167
18.1 软件开发过程中的用例模型
和对象模型 167
18.2 类图 168
18.3 交互图 170
参考文献 172
第19章 混淆的OOA和OOD领域 173
19.1 OOA是什么 174
19.1.1 如何进行OOA 174
19.1.2 OOA难道不是一种设计吗 174
19.1.3 业务应用领域是什么以及如何
了解用例 175
19.1.4 什么是仿真，分析难道不包
括仿真吗 176
19.2 OOD是什么 176
19.3 什么时候开始设计 177
19.3.1 分析模型就是设计模型吗？还是
它们应该是互相独立的 178
19.3.2 分析和设计如何保持无缝衔接 179
19.3.3 框架从何而来 179
19.3.4 模式从何而来 180
19.4 结论 180
参考文献 180
第20章 用例工程：释放它的能量 183
20.1 分析用例 184
20.2 设计和实现用例 184
20.3 测试实现的用例 185
20.4 用例工程的好处 185
编者按 187
参考文献和推荐读物 188
第21章 用例建模的形式化 189
21.1 基本用例：建模语言的设计原理 189
21.1.1 用例模型的项目相关人员 190
21.1.2 用例模型的可表达性 190
21.2 形式化层次 192
21.2.1 基本构件 192
21.2.2 类元关系 193
21.2.3 交互图 193
21.2.4 接口 194
21.2.5 状态图 195
21.3 经验 195
21.4 结论 197
参考文献和推荐读物 197
第22章 对用例正在增长的共识 199
22.1 背景 199
22.2 用例和对象 200
22.2.1 对象的观点 202
22.2.2 把用例作为预想工具 202
22.3 重新修订用例间的关系 203
22.3.1 泛化关系 203
22.3.2 扩展关系 203
22.3.3 实例关系 204
22.4 其他方法 204
22.4.1 OMT/Rumbaugh 204
22.4.2 责任驱动设计/Wirfs-Brock 205
22.4.3 对象行为分析 205
22.5 下一个是什么 206
参考文献 207
Ivar语录 209
第六部分 架构与大规模系统
第23章 大规模系统中的用例 215
23.1 用例模型介绍 215
23.2 不同级别的系统 216
23.3 不同级别的用例模型 216
23.4 电话交换系统的例子 217
23.5 顺序图与系统接口 218
23.6 下属系统是系统 219
23.7 不同级别用例模型间的映射 220
23.8 小结 221
致谢 221
参考文献 221
第24章 互连系统的系统 223
24.1 互连系统的系统 223
24.2 系统开发的工作流和模型 224
24.3 开发互连系统的系统 225
24.4 系统间的关系 227
24.5 应用领域 229
24.6 大规模系统 229
24.7 分布式系统 230
24.8 结论 230
参考文献 230
第25章 扩展—一种演进大型系统
的技术 233
25.1 演进面向对象软件 233
25.2 测试 234
25.3 扩展 234
25.4 历史注解 235
25.5 实现扩展 235
25.6 结论 237
参考文献 238
第26章 用例与架构 239
26.1 用例驱动开发 239
26.2 架构组织了开发工作 241
26.3 保持用例和架构的平衡 243
参考文献 244
第27章 架构是关于每件事情的—
但并非每件事情都是架构 245
27.1 什么是架构 245
27.1.1 架构是关于每件事情的 246
27.1.2 架构不是每件事情 246
27.2 模型是每件事情 247
27.3 架构与模型 248
第28章 架构的步骤 251
28.1 什么时候开发架构 251
28.2 哪些用例对架构是重要的 251
28.2.1 降低最严重风险的用例 252
28.2.2 对系统的用户最重要的用例 252
28.3 不要漏掉任何用例 252
28.4 架构基线是一个系统—但却是
一个“瘦小的”系统 253
28.5 架构基线和架构描述 254
28.6 架构基线是可运转的 255
28.7 架构：最重要的决定因素 255
第29章 用接口和用例构造可插拔的架构 257
29.1 子系统和接口 257
29.2 一个电信的例子 258
29.2.1 本例中的子系统 260
29.2.2 为可插拔性而构建—高层视图 261
29.2.3 为可插拔性而构建—低层视图 264
29.2.4 不同层次视图间的可跟踪性 265
29.3 可插拔子系统的一种设计方法 265
29.3.1 第1步：确定最高层子系统 265
29.3.2 第2步：把用例分配到子系统中 266
29.3.3 第3步：指定通过接口实现的操作 266
29.3.4 第4步：设计每个子系统内部 267
29.4 经验 267
29.5 相关工作 268
29.6 结论 268
感谢 268
编者按 269
参考文献 269
Ivar语录 271
第七部分 结 束 语
第30章 Objectory就是统一过程 277
30.1 什么是基于构件的开发 278
30.2 怎样找到构件 280
30.3 基于构件开发和面向对象开发
之间的区别 281
30.4 什么是Objectory 282
编者按 283
参考文献 284
第31章 统一过程是迭代的 285
31.1 一小步一小步地开发 285
31.2 迭代不是什么 286
31.3 生命周期中的迭代 287
参考文献 289
Ivar语录 291
