统一软件开发过程【可开电子发票】 电子书 下载 txt pdf mobi

本书是由UML的三位创始人Ivar Jacobson，Grady Booch，James Rumbaugh亲自撰写的。全书给出了一种以UML作为建模语言进行软件开发的过程指导。书中的内容不是UML固有的组成部分，因为UML只是一种建模语言，并不包括过程指导。实际上，UML独立于过程的特点可以使之用于不同的软件开发过程。但是本书介绍的软件开发过程是三位作者在开发UML时一直在头脑中思考的内容，因此很切合UML的特点。本书对于如何运用UML的概念进行软件开发提供了详细指导，适合参与软件开发的各类人员使用，尤其适合软件项目开发组成员阅读。

前言

部分 统一软件开发过程

章 统一过程的特点：用况驱动、以构架为中心、迭代和增量的

1.1 统一过程概述

1.2 统一过程是用况驱动的

1.3 统一过程是以构架为中心的

1.4 统一过程是迭代和增量的过程

1.5 统一过程的生命周期

1.6 一个综合的过程

第2章 软件开发的四个要素：人员、项目、产品和过程

2.1 人员至关重要

2.2 项目创造产品

2.3 产品不仅仅是代码

2.4 过程指导项目

2.5 工具对于过程不可或缺

2.6 参考资料

第3章 用况驱动过程

3.1 用况驱动开发概述

3.2 为什么使用用况？

3.3 捕获用况

3.4 实现用况的分析、设计和实现

3.5 用况的

3.6 小结

3.7 参考资料

第4章 以构架为中心的过程

4.1 构架概述

4.2 为什么需要构架？

4.3 用况和构架

4.4 建立构架的步骤

4.5 是构架描述！

4.6 三个应关注的概念

4.7 参考资料

第5章 迭代和增量过程

5.1 迭代和增量概述

5.2 为什么采用迭代和增量的开发方法？

5.3 迭代方法是驱动的

5.4 通用迭代过程

5.5 一次迭代产生一个增量结果

5.6 在整个生命周期上的迭代

5.7 由迭代过程来进化模型

5.8 迭代对开发组织具有挑战性

5.9 参考资料

第二部分 核心工作流

第6章 捕获需求：从构想到需求

6.1 为什么捕获需求很困难

6.2 需求工作流的目的

6.3 需求捕获概述

6.4 需求在软件生命周期中的作用

6.5 运用领域模型来理解的语境

6.6 使用业务模型来理解的语境

6.7 补充需求

6.8 小结

6.9 参考资料

第7章 捕获需求作为用况

7.1 引言

7.2 制品

7.3 工作人员

7.4 工作流

7.5 需求工作流小结

7.6 参考资料

第8章 分析

8.1 引言

8.2 分析概述

8.3 分析在软件生命周期中的作用

8.4 制品

8.5 工作人员

8.6 工作流

8.7 分析小结

8.8 参考资料

第9章 设计

9.1 引言

9.2 设计在软件生命周期中的作用

9.3 制品

9.4 工作人员

9.5 工作流

9.6 设计小结

9.7 参考资料

0章 实现

10.1 引言

10.2 实现在软件生命周期中的作用

10.3 制品

10.4 工作人员

10.5 工作流

10.6 实现小结

10.7 参考资料

1章

11.1 引言

11.2 在软件生命周期中的作用

11.3 制品

11.4 工作人员

11.5 工作流

11.6 小结

11.7 参考资料

第三部分 迭代和增量的开发过程

2章 一般的迭代工作流

3章 初始阶段启动项目

4章 细化阶段构造构架基线

5章 构造阶段形成初步可运行能力

6章 移交阶段完成产品发布

7章 统一过程的运用

附录A UML综述

附录B 针对统一过程的UML扩展

附录C 常用术语

本书的三位作者是统一建模语言的创始人。世界公认，这三人对开发对象技术做出了许多重大的贡献，包括对象工厂（OOSE）过程。Booch方法和对象建模技术（OMT）等，他们三人目前都在Rational软件公司任职。

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

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

在线阅读地址：统一软件开发过程【可开电子发票】在线阅读

在线听书地址：统一软件开发过程【可开电子发票】在线收听

在线购买地址：统一软件开发过程【可开电子发票】在线购买

暂无原文赏析，正在全力查找中！

暂无其它内容！

• 作者： m33 发布时间：2010-04-09 21:44:31

  一篇学术论文式的介绍RUP的书，你从其中根本就不可能得到如何实施RUP的各种实际操作的建议。

  乏味

• 作者： Joard Spike 发布时间：2010-02-22 18:09:27

  同样强调迭代和快速反馈，每个迭代都是袖珍瀑布开发

• 作者： MDifferent 发布时间：2009-03-27 18:45:37

  翻译的很烂，还不如看英文版

• 作者： Neo 发布时间：2014-01-02 23:27:55

  怎么那么多工作流的东东..

• 作者： watercloud 发布时间：2007-03-03 11:45:22

  UML号称万能，能解决N多问题，实际上使用了它后也会带来N多问题，设计方面能把问题描述清楚就行了，管它uml不uml。

• 当我们嘲笑UML的时候，我们应该嘲笑什么

  作者：霏昀 发布时间：2011-08-01 10:40:41

  按：上周偶尔谈起UML，想到自己UML、UP（统一过程）的知识有5-6年没更新了，干脆趁没忘光都吐出来。吐槽文，达意第一，术语使用不严谨。

  -------------------------------------------------------

  为了嘲笑UML，我们必须追溯UML的初衷，于是我们必须了解现实世界和软件世界之间天然的隔阂。虽然人们对软件已经习以为常，但是软件的构造并不像其他物理工具的制造那样透明。对软件一无所知的人来说，“编程”一词或多或少包含了“魔法”的成分。

  如果对软件的内在机制有所了解，就可以更容易地表达软件与现实之间的鸿沟——即，描述现实世界的自然语言和描述软件世界的机器语言之间的失配（mismatch）。现实世界的需求不能轻易地被机器语言表达，这是鸿沟所在，或者更专业地说，是软件构造复杂度的来源。

  一直以来，计算机行业用两种方法降低这种复杂度。第一种方法是对机器语言进行封装——通过引入高级语言、面向对象等概念，使编程语言可以更直接地描述现实世界。

  （题外话，这是为什么从数（美）学上看编程语言越来越dirty。因为虽然Lisp很美——美到某本书某页最下方巴掌大的Lisp代码包含了计算的本质，但这种美却不能帮助Lisp更好地描述dirty的现实世界。）

  但因为任何编程语言本质上都和图灵机等价，所以编程语言与现实世界的接近程度是有极限的。现存的编程语言依然难以直接描述复杂的现实。

  于是计算机行业用第二个办法来弥合现实与软件的隔阂，这就是建模（modelling）——通过建模将现实世界抽象为模型，使现实世界更加清晰精确；编程语言不再直接描述现实世界，而是描述现实世界的模型。

  “建模”包含两部分内容：首先是行为（“建”），即如何构造模型的方法；其次是结果（“模”），即作为方法制品的模型。

  UML模型是一种用于构造软件的模型，是现实世界和软件世界的有效中介物。UML模型被用来描述现实世界的结构，并保证描述结果和软件结构天然近似。

  但UML不是一种建模方法，UML没有定义将现实世界转化为UML模型的建模方法。实际上，使用UML模型的建模方法被称为“Unified Software Development Process（统一软件开发过程，缩写为UP）”。

  UP的官方定义语是“用例驱动，以架构为中心，迭代增量的开发过程”。UP以模型为中介，降低软件开发的复杂度，帮助人们更容易地将现实世界的需求转化为软件。UML模型仅仅是UP的制品，而且仅仅是制品中的重要部分。一个未必恰当的比喻：UP是催动UML招式的内功心法。

  遗憾的是现实中UP被丢弃、被遗忘、被不为人知。于是产生了各式各样对UML的误用：

  - 比如，以为UML用例图就是用例；以为画小人圈圈就描述了需求。实际上，UP中首先要用文档附以领域模型和业务模型描述需求。每个用例都是从需求中抽取，并且是包含参与者、前置条件、后置保证、主要事件流、扩展事件流的完整文字描述。用例图仅仅用来追溯索引用例的图示。

  - 比如，以为UML只包含类图；以为类图是银弹；以为使用UML就是画一张事无巨细的类图。其实UP中包含构造系统类图的完整流程方法，这包括：首先抽象现实世界的概念关系构造领域模型类图。而后以用例为中介精化领域类图，从用例中抽取包含新辨识概念关系的分析类图。而分析类图又会在后面的过程中被精化为设计类图，直到被用来指导具体实现。

  - 比如，因为各种误用，以为软件开发的复杂性是UML造成的，以为摆脱UML就摆脱了软件开发的复杂性。实际上，软件开发天然复杂。摆脱UML不意味着人们可以用编程语言直接描述（具备一定复杂度的）最终系统。相反人们还是会以“土法炼钢”的方式构造自己的中介物。

  此处我也无意为UP布道。不过我想说当我们像上面那样使用UML并造成混乱的时候，我们不应该嘲笑UML，UML应该嘲笑我们，因为我们才是混乱的根源。

  当我们嘲笑UML的时候，我们到底应该嘲笑什么？

  UML或曰UP的最大问题在于：它们认为模型是解决一切问题的银弹。

  实际上以建模来弥平现实与软件的鸿沟，需要经历两个步骤：首先是对现实进行抽象，将现实转化为一种更精确更易理解的模型；第二步则是将模型“具象”到软件世界，即用编程语言实现获得的模型。其中的第一个步骤中，模型作为最终制品很重要；但第二个步骤必须落实到编程语言对软件实现上。

  UP没有认清这一点，所以UP没有定义出模型使用的边界，没有给出在抽象过程结束后抛弃模型的时机，也因此没有将注意力集中到编程语言对软件的实现上。相反UP要求对模型不断精化，要求模型不断接近最终的软件。

  这导致UML或者更广义建模研究的终极理想成为：通过精化的模型直接生成运行软件，或者更直白地说企图用模型替代编程语言。

  然而无论直观感觉，还是多年的研究结果都表明：在企图精确描述软件世界时，模型并不比编程语言更优越——即，在深入到一定细节后，表达等量的内容，模型和编程语言同样复杂（如果前者不是更复杂的话）。

  所以以模型替代编程语言的所有努力看上去是注定会失败的。UML是所有这些徒劳无功的形象代言人。

  因此，我想，只有当我们看到那些事无巨细的类图、极端精确的时序图，看到那些双向转换模型的纷繁规则，看到那些神似编程语言的“建模语言”时，我们才可以去嘲笑UML。

  因为这些多少代表了UML/UP以为自负可以达到，但其实不可能达到的境地。

  blog源链：

  http://sakinijino.com/archives/3936

• 初读

  作者：豆壳 发布时间：2007-01-19 17:41:13

  这本书一看就不是为开发人员写的，所以读起来也不轻松，时间有限，只能泛读了一遍。

  其实UP还是挺好的，要敏捷也能很敏捷的，用UML也是没错的，现在敏捷社区不愿意接纳都是RUP惹的祸。IBM集中火力把用例、架构、迭代弄得只剩下用例了，用例只能是UML图，画UML非R莫属了，造成少了R就不是UP，离了R就不能UP的假象，然后兜售自己昂贵的工具，没钱的开发者傻了，敏捷火了。“赚有钱人的钱”是IBM的一贯做法，谁让咱没钱呢。不过UP自身还是值得学习借鉴的。