大象：Thinking in UML(第2版) 下载 pdf 百度网盘 epub 免费 2025 电子书 mobi 在线

大象：Thinking in UML（第二版），ISBN：9787508492346，作者：谭云杰 著

Part Ⅰ 你需要了解 2

第1章 为什么需要UML 2

1.1 面向过程还是面向对象 2

1.1.1 面向过程方法 3

1.1.2 面向过程的困难 5

1.1.3 面向对象方法 7

1.1.4 面向对象的困难 9

1.2 UML带来了什么 11

1.2.1 什么是UML 11

1.2.2 统一语言 13

1.2.3 可视化 13

1.2.4 从现实世界到业务模型 15

1.2.5 从业务模型到概念模型 17

1.2.6 从概念模型到设计模型 18

1.2.7 面向对象的困难解决了吗 20

1.3 统一过程简介 22

1.3.1 RUP是什么 22

1.3.2 RUP与UML 24

1.3.3 RUP与软件工程 25

1.3.4 RUP与最佳实践 26

1.3.5 RUP与本书 27

第2章 建模基础 29

2.1 建模 29

2.2 用例驱动 32

2.3 抽象层次 34

2.4 视图 36

2.5 对象分析方法 37

Part Ⅱ 在学习中思考 42

第3章 UML核心元素 42

3.1 版型 42

3.2 参与者 43

3.2.1 基本概念 43

3.2.2 发现参与者 45

3.2.3 业务主角 46

3.2.4 业务工人 48

3.2.5 参与者与涉众的关系 49

3.2.6 参与者与用户的关系 49

3.2.7 参与者与角色的关系 50

3.2.8 参与者的核心地位 50

3.2.9 检查点 50

3.3 用例 51

3.3.1 基本概念 52

3.3.2 用例的特征 53

3.3.3 用例的粒度 55

3.3.4 用例的获得 57

3.3.5 用例和功能的误区 60

3.3.6 目标和步骤的误区 62

3.3.7 用例粒度的误区 64

3.3.8 业务用例 67

3.3.9 业务用例实现 67

3.3.10 概念用例 68

3.3.11 系统用例 69

3.3.12 用例实现 70

3.4 边界 71

3.4.1 边界决定视界 72

3.4.2 边界决定抽象层次 72

3.4.3 灵活使用边界 73

3.5 业务实体 74

3.5.1 业务实体的属性 74

3.5.2 业务实体的方法 75

3.5.3 获取业务实体 75

3.6 包 77

3.7 分析类 79

3.7.1 边界类 80

3.7.2 控制类 81

3.7.3 实体类 82

3.7.4 分析类的三高 82

3.8 设计类 83

3.8.1 类 84

3.8.2 属性 84

3.8.3 方法 84

3.8.4 可见性 85

3.9 关系 85

3.9.1 关联关系（association） 86

3.9.2 依赖关系（dependency） 86

3.9.3 扩展关系（extends） 87

3.9.4 包含关系（include） 87

3.9.5 实现关系（realize） 88

3.9.6 精化关系（refine） 89

3.9.7 泛化关系（generalization） 89

3.9.8 聚合关系（aggregation） 90

3.9.9 组合关系（composition） 90

3.10 组件 90

3.10.1 完备性 91

3.10.2 独立性 92

3.10.3 逻辑性 92

3.10.4 透明性 92

3.10.5 使用组件 92

3.11 节点 94

3.11.1 分布式应用环境 95

3.11.2 多设备应用环境 95

第4章 UML核心视图 97

4.1 静态视图 97

4.1.1 用例图 97

4.1.2 类图 102

4.1.3 包图 104

4.2 动态视图 105

4.2.1 活动图 105

4.2.2 状态图 112

4.2.3 时序图 114

4.2.4 协作图 118

第5章 UML核心模型 124

5.1 用例模型概述 125

5.2 业务用例模型 126

5.2.1 业务用例模型主要内容 127

5.2.2 业务用例模型工件的取舍 129

5.2.3 何时使用业务用例模型 130

5.3 概念用例模型 131

5.3.1 概念用例模型的主要内容 132

5.3.2 获得概念用例 133

5.3.3 何时使用概念用例模型 133

5.4 系统用例模型 134

5.4.1 系统用例模型的主要内容 134

5.4.2 获得系统用例 136

5.5 领域模型 137

5.5.1 读者须知 137

5.5.2 基本概念 138

5.5.3 领域模型的主要内容 139

5.6 分析模型 141

5.6.1 如何使用分析模型 142

5.6.2 分析模型的主要内容 144

5.6.3 分析模型的意义 145

5.7 软件架构和框架 146

5.7.1 软件架构 147

5.7.2 软件框架 152

5.7.3 何时使用架构和框架 153

5.8 设计模型 154

5.8.1 设计模型的应用场合 155

5.8.2 设计模型的主要内容 155

5.8.3 从分析模型映射到设计模型 157

5.9 组件模型 158

5.9.1 何时使用组件模型 160

5.9.2 广义组件的用法 161

5.10 实施模型 162

何时使用实施模型 162

第6章 统一过程核心工作流简介 164

6.1 业务建模工作流程 165

6.1.1 工作流程 165

6.1.2 活动集和工件集 167

6.1.3 业务建模的目标和场景 168

6.2 系统建模工作流程 170

6.2.1 工作流程 170

6.2.2 活动集和工件集 172

6.2.3 系统建模的目标 175

6.3 分析设计建模工作流程 176

6.3.1 工作流程 176

6.3.2 活动集和工件集 183

6.3.3 分析设计的目标 184

6.3.4 推荐的分析设计工作流程简介 184

6.4 实施建模工作流程 186

6.4.1 工作流程 186

6.4.2 活动集和工件集 187

6.4.3 推荐的实施建模工作流程 188

第7章 迭代式软件生命周期 192

Part Ⅲ 在实践中思考 195

第8章 准备工作 195

8.1 案例说明 195

8.2 了解问题领域 196

8.2.1 了解业务概况 196

8.2.2 整理业务目标 197

8.3 做好涉众分析 197

8.3.1 什么是涉众 198

8.3.2 发现和定义涉众 198

8.3.3 涉众分析报告 200

8.4 规划业务范围 207

8.4.1 规划业务目标 207

8.4.2 规划涉众期望 207

8.5 整理好你的思路 208

8.5.1 划分优先级 208

8.5.2 规划需求层次 209

8.5.3 需求调研计划 210

8.6 客户访谈技巧 212

8.6.1 沟通的困难 212

8.6.2 沟通技巧 213

8.7 提给读者的问题 215

第9章 获取需求 217

9.1 定义边界 217

9.1.1 盘古开天——从混沌走向清晰 217

9.1.2 现在行动：定义边界 219

9.1.3 进一步讨论 221

9.1.4 提给读者的问题 224

9.2 发现主角 224

9.2.1 女娲造人——谁来掌管这个世界 224

9.2.2 现在行动：发现主角 225

9.2.3 进一步讨论 229

9.2.4 提给读者的问题 232

9.3 获取业务用例 232

9.3.1 炎黄之治——从愚昧走向文明 232

9.3.2 现在行动：获取业务用例 233

9.3.3 进一步讨论 240

9.3.4 提给读者的问题 243

9.4 业务建模 243

9.4.1 商鞅变法——强盛的必由之路 243

9.4.2 现在行动：建立业务模型 244

9.4.3 进一步讨论 254

9.4.4 提给读者的问题 258

9.5 领域建模 259

9.5.1 风火水土——寻找构成世界的基本元素 259

9.5.2 现在行动：建立领域模型 259

9.5.3 进一步讨论 267

9.5.4 提给读者的问题 270

9.6 提炼业务规则 271

9.6.1 牛顿的思考——揭穿苹果的秘密 271

9.6.2 现在行动：提炼业务规则 272

9.6.3 进一步讨论 275

9.6.4 提给读者的问题 276

9.7 获取非功能性需求 277

9.7.1 非物质需求——精神文明是不可缺少的 277

9.7.2 现在行动：获取非功能性需求 278

9.7.3 进一步讨论 282

9.7.4 提给读者的问题 286

9.8 主要成果物 287

提给读者的问题 288

第10章 需求分析 290

10.1 关键概念分析 290

10.1.1 阿基米德杠杆——找到撬动地球的支点 290

10.1.2 现在行动：建立概念模型 291

10.1.3 进一步讨论 301

10.1.4 提给读者的问题 302

10.2 业务架构 302

10.2.1 拼图游戏——我们也想造个世界 302

10.2.2 现在行动：建立业务架构 304

10.2.3 进一步讨论 309

10.2.4 提给读者的问题 311

10.3 系统原型 312

第11章 系统分析 315

11.1 确定系统用例 315

11.1.1 开始规划——确定新世界的万物 315

11.1.2 现在行动：确定系统用例 318

11.1.3 现在行动：描述系统用例 320

11.1.4 进一步讨论 325

11.1.5 提给读者的问题 327

11.2 分析业务规则 327

11.2.1 设定规则——没有规矩不成方圆 327

11.2.2 现在行动：分析业务规则 328

11.2.3 提给读者的问题 335

11.3 用例实现 335

11.3.1 绘制蓝图——世界将这样运行 335

11.3.2 现在行动：实现用例 337

11.3.3 进一步讨论 344

11.3.4 提给读者的问题 346

11.4 软件架构和框架 346

11.4.1 设计架构——新世界的骨架 346

11.4.2 什么是软件架构 349

11.4.3 什么是软件框架 349

11.4.4 软件架构的基本构成 350

11.4.5 应用软件架构 354

11.4.6 提给读者的问题 354

11.5 分析模型 355

11.5.1 设计功能零件——让世界初步运转起来 355

11.5.2 现在行动：建立分析模型 355

11.5.3 进一步讨论 362

11.5.4 提给读者的问题 364

11.6 组件模型 364

11.6.1 设计功能部件——构建世界的基础设施 364

11.6.2 现在行动：建立组件模型 365

11.6.3 进一步讨论 372

11.6.4 提给读者的问题 377

11.7 部署模型 377

11.7.1 安装零部件——组装一个新世界 377

11.7.2 现在行动：建立部署模型 378

11.7.3 提给读者的问题 380

第12章 系统设计 381

12.1 系统分析与系统设计的差别 381

12.2 设计模型 382

12.2.1 按图索骥——为新世界添砖加瓦 382

12.2.2 现在行动：将分析模型映射到设计模型 383

12.2.3 进一步讨论 388

12.2.4 提给读者的问题 390

12.3 接口设计 390

12.3.1 畅通无阻——构建四通八达的神经网络 390

12.3.2 现在行动：设计接口 391

12.3.3 进一步讨论 398

12.3.4 提给读者的问题 400

12.4 包设计 401

12.4.1 分工合作——组织有序世界才能更好 401

12.4.2 现在行动：设计包 405

12.4.3 进一步讨论 410

12.5 提给读者的问题 413

第13章 数据库设计 414

13.1 关公战秦琼——面向对象与关系模型之争 414

13.2 相辅相成——面向对象的数据库设计 416

13.3 平衡的艺术——数据库设计的方法和策略 419

13.3.1 OR-Mapping策略 421

13.3.2 对象—关系平衡策略 427

13.4 进一步讨论——数据库设计到底有多重要 428

第14章 开发 430

14.1 生成代码 430

14.1.1 现在行动：生成代码 431

14.1.2 进一步讨论 434

14.2 分工策略 436

14.2.1 纵向分工策略 436

14.2.2 横向分工策略 442

14.2.3 选择适合你的开发分工策略 444

Part Ⅳ 在提炼中思考 446

第15章 测试 446

15.1 质量保证——新世界需要稳健运行 446

15.2 设计和开发测试例 447

15.3 提给读者的问题 453

第16章 理解用例的本质 454

16.1 用例是系统思维 454

16.2 用例是面向服务的 459

16.3 善用用例方法 461

第17章 理解用例驱动 463

17.1 用例与项目管理 463

17.2 用例与可扩展架构 464

第18章 用例驱动与领域驱动 468

18.1 用例驱动与领域驱动的差异 468

18.2 领域驱动的理想与现实 469

18.3 如何决定是甭采用领域驱动方法 471

第19章 理解建模的抽象层次 473

19.1 再讨论抽象层次 473

19.1.1 层次高低问题 474

19.1.2 层次不交叉问题 474

19.2 如何决定抽象层次 475

19.3 抽象层次与UML建模的关系 475

第20章 划分子系统的问题 477

20.1 面向对象的子系统问题 477

20.2 UC矩阵还适用吗 477

20.3 如何划分子系统 478

第21章 学会使用系统边界 482

21.1 边界是面向对象的保障 482

21.2 利用边界来分析需求 483

21.2.1 边界分析示例一 483

21.2.2 边界分析示例二 486

21.3 边界意识决定设计好坏 487

第22章 学会从接口认知事物 489

22.1 怎样描述一件事物 489

22.2 接口是系统的灵魂 490

第23章 学会正确选择 493

23.1 屁股决定脑袋——学会综合权衡 493

23.2 理辩则明——学会改变视角 496

第24章 学会使用设计模式 499

24.1 如何学习设计模式 499

24.2 如何使用设计模式 503

附录 UML视图常用元素参考 510

图目录 515

表目录 524

后记 525

暂无相关内容，正在全力查找中

暂无出版社相关信息，正在全力查找中！

暂无相关书籍摘录，正在全力查找中！

在线阅读地址：大象：Thinking in UML(第2版)在线阅读

在线听书地址：大象：Thinking in UML(第2版)在线收听

在线购买地址：大象：Thinking in UML(第2版)在线购买

RUP即Rational Unified Process，是Rational公司开发的软件过程产品。The Unified Software Development Process也指的是RUP，不过去掉了前面的公司名。本文分别采用“统一软件过程”和“RUP”作为其全称和简称。

　　就笔者所了解，当前国内业界普遍关心的一个问题是：RUP的剪裁原理是什么，有没有工程化的RUP剪裁过程。本文将讨论上面两个问题。本文有不少观点来自个人心得，有不妥之处，敬请斧正。

第一部分 RUP的剪裁原理

　　首先介绍“软件过程也是软件”这一著名原理，然后指明RUP的剪裁原理是：软件过程开发的再工程。

一、 软件过程也是软件

　　软件工程大师Osterweil在其论文《Software Processes are Software Too》中高屋建瓴地指出：软件过程也是软件。软件有一个开发的过程，软件过程也有一个开发的过程；软件开发产出软件产品，软件过程开发产出过程产品；软件开发可以是一个演进过程，软件过程开发也可以是一个演进过程。

1. 软件过程也有一个开发的过程

　　软件过程也是经过了需求捕获、分析、设计、实现和测试等活动才开发出来的。下面仅简单论述。软件过程开发中，需求是指采用该软件过程的目的是什么（高层需求），要用来指导哪些活动（需求）；分析和设计是指，活动之间如何衔接甚至并行执行，各活动产出什么产品；实现是指，将软件过程文档化，相当于软件开发的coding；软件过程开发也有测试，不过是在脑子里run的，而上级领导用脑子run两遍批示通过就是验收测试。

　　进一步讲，软件过程不仅有开发过程，而且有完整的软件过程生存周期。因为软件过程在开发出来之后，也有交付使用、维护升级直至废弃的过程。交付使用就是将软件过程实施，用于指导软件项目的开发。要是在使用软件过程时发现有错误之处（bug，需纠错...

建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察到对象的内部结构和工作原理的便于理解的表达。

模型要能够真实反映客观事物就需要一个论证过程，使得模型建立过程是严谨的，并且结果是可追溯和验证的。

对于一种软件建模方法来说，为现实世界建立模型也要是严谨的，可追溯和可验证的，除了描述清楚需求，还要能很容易将这个模型转化为计算机也能够理解的模型。

建立模型的过程是一个抽象的过程，要建立模型，首先要知道如何抽象现实世界。

现实世界的本质无非是由人，事，物和规则组成的。

UML中，人 - 参与者（Actor），事 - 用例（use case），规则 - 业务场景视图（bussiness scenario）和用例场景视图（use case scenario），物 - 业务对象模型视图（bussiness object model）

业务模型映射了原始需求信息，之后要经历一个概念化（Conceptual）的过程建立适合计算机理解和实现的模型，这个模型称为分析模型。（Analysis Model）

分析模型有：

1. 边界类

2. 实体类

3. 控制类

在这个阶段，还可以对这些分析类在不同的视角上进行分类和整理，得到包，组件和节点。软件架构也是在这个阶段产生。

在设计模型中，概念模型中的边界类可以被转化为操作界面或系统接口；控制类可以被转化为计算程序或控制程序，例如工作流，算法体等；实体类可以转化为数据库表，XML文档或者其他持久化类。

这个转化过程是有章可循的，可以遵循的规则有：

1. 软件架构和框架

2. 编程语言

3. 规范或中间件

统一过程归纳和集成了软件开发活动中的最佳实践，它定义了软件开发过程中最重要的阶段和工作（四个阶段和九个核心工作流），定义了参与软件开发过程中的各种角色和他们的职责，还定义了软件生产过程中产生的工件，并提供了模板。最后，采用演进式软件生命周期（迭代）将工作，角色和成果物串在一起，形成了统一过程。

UML是一种语言，用来描述软件生产过程中要产生的文档，统一过程则指导如何产生这些文档以及这些文档要讲述什么的方法。

（重量级）统一过程 vs. （轻量级）敏捷方法

要解决问题领域就要归纳出所有必要的抽象角度（用例），为这些用例描述出可能的特定场景，并找到实现这些场景的事物，规则和行为。再换个说法，如果我们找到的那些事物，规则和行为实现了所有必要的用例，那么问题领域就被解决了。这就是用例驱动方法的原理。

在统一过程中，一个用例就是一个分析单元，设计单元，开发单元，测试单元甚至部署单元。

用例可以驱动的内容包括：

1. 逻辑视图：该视图以图形方式说明关键的用例实现，子系统，包和类，即，人，事，物，规则，是如何分类组织的。

2. 进程视图：以图形方式说明了系统中进程的详细组织结构，其他包括类和子系统到进程和线程的映射，即，人，事，物，规则，是如何交互的。

3. 部署视图：以图形方式说明了处理活动在系统中各节点的分布，包括进程和线程的物理分布，即，人，事，物，规则，是如何部署在物理节点（主机，网络环境）上的。

4. 实施视图：其作用是获取为实施制定的架构决策。包括：

a. 例举实施模型中的所有子系统。

b. 描述子系统如何组织为层次和分层结构的构件图。

c. 描述子系统间的导入依赖关系的图解。

实施视图用于：

a. 为个人，团队或分包商分配实施工作。

b. 估算要开发，修改或删除的代码数量。

c. 阐明大规模复用的理由。

d. 考虑发布策略。

也即，人，事，物，规则，如何构成系统的零部件，以及我们如何组织人力生产和组装这些零部件以建成最终系统。

书籍介绍

大象：Thinking in UML（第二版），ISBN：9787508492346，作者：谭云杰 著