统一软件开发过程(RUP) 简 介

王立福

2009.12

一 RUP与UML的关系 二 RUP的本质和突出特点 三 RUP的需求获取 四 RUP的需求分析 五 RUP的软件设计

一 RUP与UML的关系 1 UML的构成 UML作为一种半形式化的规约语言,提供了: 1支持建模的术语(表) --该术语表中的术语跨越了问题空间到目前“运行平台”之间,即:

运 行平 台

问题空间

Actor Use case 关联 泛化

分析类 分析包 Use case细化

　　--该术语表支持不同抽象层的建立,即:

需求获取层

需求分析层

软件设计层

软件实现层

--该术语表支持以面向对象的观点,建立系统模型,即:

给出表达“客体”、“客体关系”的术语.

为了支持抽象系统分析和设计中的事物，UML给出了8个基本术语，即：类、接口、协作、用况、主动类、构件、制品、结点，并给出了这些基本术语的一些变体。

可见,UML是将大千世界的一切客体分为八个”范畴”!用于抽象各类事物.

每个术语都体现着一定的软件设计原理，例如类体现了数据抽象、过程抽象、局部化以及信息隐蔽等原理；用况体现了问题分离、功能抽象等原理；接口体现了功能抽象等。

并且为了进一步描述这些模型元素的语义，还给出一些特定概念和表示，例如操作\属性这些概念，是为了增强类的语义.

为了表达模型元素之间的关系，UML给出了4个术语,即：关联、泛化、细化和依赖，以及它们的一些变体。 可见, UML是将大千世界客体之间的关系分为4个”范畴”! 用于抽象各种事物之间的关系。 这些术语都体现了结构抽象原理，特别是泛化概念的使用，可以有效地进行“一般/特殊”结构的抽象，支持设计的复用。 并且为了进一步描述这些模型元素的语义，还给出一些特定的概念和表示，例如聚合\组合\限定符等这些概念，是为了增强关联的语义。

当使用以上12个术语(不含它们的变体)来创建模型时，其语义就被映射到相应的模型元素上。

为了组织以上两类模型元素，UML给出了包这一术语，在实际应用中，可以把包作为控制信息复杂性的机制。 为了使创建的系统（或系统成分）模型清晰、易懂，UML给出了注解这一术语。

2支持建模的表达格式 为了表达概念模型和软件模型，UML提供了14种图形化工具,即:　　 图

行为图 结构图

类

图

对象

图

构件

图

包

图

部署

图

组合结构 图

USE CASE

图

活动

图

状态

图

交互

图

顺序

图

通信

图

交互概观 图

定时

图

其主要目的是：支持软件开发人员 从不同目的（静态、动态）、针对不同粒度（系统、子系统、类目等），从不同抽象层和从不同视角来创建模型，并

建立相应的文档。 前6个图可用于概念模型和软件模型的静态结构方面； 后8个图可用于概念模型和软件模型的动态结构方面. 其中: 类图可用于创建系统、子系统、类目等的结构模型，表达它们的一些说明性信息； use case图可用于创建有关系统、子系统、类目等功能模型，表达它们在功能需求方面的信息；

状态图可用于创建系统、子系统、类目等的行为生存周期模型，表达它们的一种动态结构，给出它们在生存期间可有哪些

阶段、每一阶段可从事的活动以及对外所呈现的特征等方面的信

息； 顺序图可用于创建系统、子系统、类目等的交互模型,表达它们的一种交互结构，给出有关参与交互的各方、交互方式以及

交互内容.

总之,UML是一种可视化的建模语言，给出了一些可用于定义软件开发各抽象层的术语（符号），给出了各层表达模型的工具。

2 UML与RUP的关系

作为一种软件开发方法学，为了支持软件开发活动，至少应涉及三方面的内容：

一是支持定义各抽象层，即给出各层的一些术语;

二是给出各层的模型表达;

三是给出如何把一个抽象层的模型映射为另一个抽象层

的模型，即过程指导。

可见, RUP 和UML 是“统一”的方法学。

Actor Use case 关联 泛化 USE CASE图模

型

分析类 分析包 Use case细化 分析模型

设计模型

部署模型

RUP

二 RUP的本质和突出特点 1 RUP的本质

本质: 是“一般的过程框架 ” . 即: --为进行软件开发中不同抽象层之间“映射”，安排开发活动的次序，指定任务和需要开发的制品，提供了指导； --为进行项目中制品和活动的监控测量，提供了相应的准则。 换言之，RUP比较完整地定义了将用户需求转换成产品所需要的活动集，并提供了活动指南以及对产生相关文档的要求。

适用于：大多数软件系统的开发，涉及

-不同应用领域 -不同类型的组织

-不同的技能水平 -不同的项目规模

2 RUP的突出特点 是一种以用况（Use Case）为驱动的、以体系结构为中心的、迭代、增量式开发。 以用况为驱动 意指在系统的生存周期中， 以用况作为基础，驱动有关 人员对所要建立系统之功能 需求进行交流，驱动系统分 析、设计、实现和测试等活 动，包括制定计划、分配任 务、监控执行和进行测试等， 并将它们有机地组合为一体， 使各个阶段中都可以回溯到 用户的实际需求。

USE CASE 分 析

输入

设 计

实 现

跟踪 输入

跟踪

输入 跟踪

输入

输入

测 试

输入

跟踪

输入

从USE CASE模型的视觉

从分析模型的视觉

从设计模型的视觉

从实现模型的视觉

从部署模型的视觉

给 出 体 系 结 构

描 述

以体系结构为中心 意指在系统的生存周期中，开发的任何阶段（RUP规定了四个阶段，即初始阶段、细化阶段、构造阶段和移交阶段）都

要给出相关模型视角下的有关体系结构的描述，作为构思、构

造、管理和改善系统的主要制品。

系统体系结构是对系统语义的概括表述，内含一些决策，主要涉及软件系统的组织（包括构成系统的结构元素、各元素的

接口、由元素间的各种协作所描述的各元素行为、由结构元素

和行为元素构成的子系统、相关的系统功能和性能、其他约束

等）以及支持这种组织的体系结构风格。 　系统体系结构对所有与项目有关人员来说都是能够理解的，

因此便于用户和其他关注者对系统达到共识，以便建立和控制

系统的开发、复用和演化。 　因此，在系统体系结构描述中，应关注子系统、构件、接口、

协作、关系和节点等重要模型元素，而忽略其他细节。

具体地说，体系结构描述应根据相关模型的视角： ① 展示对体系结构有意义上的用况、子系统(不涉及子系统的隐含成分和私有成分，及其变种)、接口、类(主要为主动类)、构件、节点和协作； ② 展示对系统体系结构有意义的非功能需求，例如性能、安全、分布和并发等； ③ 简述相关的平台、遗产、所用的商业软件、框架和模板机制等；以及 ④ 各种体系结构模式。

例如，为获得系统用况模型视角下的系统体系结构描述，应： ① 在一般性地了解系统用况之后，勾画与特定用况和平台无关的系统体系结构轮廓。 ② 关注一些关键用况。所谓关键用况，是指那些有助于降低最大风险的用况，对系统用户来说是最重要的用况，以及有助于

实现所有重要的功能而不遗留任何重大问题的用况。 ③ 给出每一关键用况的描述。其中应考虑软件需求、中间件、遗产系统和非功能性需求等，以便产生更加成熟的用况和更多

的系统体系结构成分。 ④ 对以上三步进行迭代，得到一个文档化的体系结构基线。并在此基础上，形成一个稳定的系统体系结构描述。

阶 段

核心工作流

迭代、增量式开发 意指通过开发活动的迭代，不断地产生相应的增量。在RUP中，规定了四个开发阶段：初始阶段（the inception phase）、

精化阶段（ the elaboration phase）、构造阶段（ the construction

phase）和移交阶段（ the transition phase）

每次迭代都要按照专门的计划和评估标准，通过一组明确的活动，产生一个内部的或外部的发布版本。两次相邻迭代所得到的

发布版本之差，称为一个增量，因此增量是系统中一个较小的、

可管理的部分(一个或几个构造块)。 贯穿整个生存周期的迭代，形成了项目开发的一些里程碑。 --每一阶段的结束，是项目的一个主里程碑（共四个），产生系统的一个体系结构基线，即模型集合所处的当时状态。 --主里程碑是管理者与开发者的同步点，以决定是否继续进行项目，确定项目的进度、预算和需求等。 --在四个阶段中的每一次迭代的结束，是一个次里程碑，产生一个增量。次里程碑是如何进行后续迭代的决策点。

--系统体系结构基线的建立，是精化阶段的一个目标，期间通过不断演化，到该阶段末得到这一基线，是系统的“骨架”. 该基线包括早期版本的用况模型、分析模型、设计模型、部署模型、实现模型和测试模型，但此时用况模型和分析模型较为

成熟。

--在实践中，体系结构描述和体系结构基线往往同时开发，以便指导整个软件开发的生命周期。期间，体系结构描述不断更新，

以便反映体系结构基线的变化。

注:该基线应该是坚实的，因为它是开发人员当时和将来进行开发时所要遵循的标准;并应与最终系统(对客户发布的产品) 几乎具有同样的骨架。但最后形成的体系结构基线是系统各

种模型和各模型视角下体系结构描述的一个集合。

综上可知，RUP的迭代增量式开发，是演化模型

的一个变体. 但: 规定了“大”的迭代数目-四阶段; 规定了每次迭代的目标。

需求 设计 编码 测试 集成

需求 设计 编码

测试 集成

开

发

反

馈

开

发

反

馈

...

第 一 次 迭 代 第 二 次 迭 代

初始阶段的基本目标是：

获得与特定用况和平台无关的系统体系结构轮廓，以此建立产品功能范围；

编制初始的业务实例，从业务角度指出该项目的价值，减少项目主要的错误风险。

简言之，其目标是：建立该项目的生存周期目标

（objectives）

精化阶段的基本目标是： 通过不断演化式地捕获并描述系统的大部分需求（一些关键用况），建立系统体系结构基线的第一个版本，这是精化阶段

的目标.这一基线，通常是系统的“骨架”. --该基线包括早期版本的用况模型、分析模型、设计模型、部署模型、实现模型和测试模型，但此时用况模型和分析模型

较为成熟。 --该基线主要可减少次要的错误风险. --到该阶段末，基于该基线就可估算成本、进度，并能详细地规划构造阶段。 简言之，其目标是：建立系统的体系结构基线.

构造阶段的基本目标是： 通过演化，形成最终的系统体系结构基线（包括系统的各种模型和各模型视角下体系结构描述）; 开发了完整的系统，确保产品可以开始向客户交付, 即具有初始操作能力。 简言之，其目标是：形成一个可基本交付使用的产品/系统.

交付阶段的基本目标是：确保有一个实在的产品，发布给用户群。期间，培训用户如何使用该软件。 简言之，其目标是：向用户交付一个可使用的产品/系统.

三 RUP的需求获取 1 需求获取的目标 对大的、复杂的系统的开发,一般包括需求获取和需求分析.

RUP需求获取的目标是：

客观问题（系统）

系统需求获取模型

形成--涉及：不同概念和不同处理逻辑

体系结构描述 -USE CASE模型

2 实现需求获取目标的基本途径 　 实现实际问题到软件开发需求获取层的映射，即从软件开发的角度-实现第一次抽象。

其中至少涉及以下3个问题： 1)如何定义需求获取层，即该层是由哪些术语定义的； 2)如何确定模型表示； 3)如何映射。

实际问题

需求获取层 模型表示 1) 2)

3)

1)需求获取层的术语（概念） 术语: USE CASE actor 以及 4个表达关系的概念：关联、包含、扩展、泛化 2)功能模型表达 工具:USE CASE图

实际问题

模型表示 工具

-USE CASE图

体系结构描述 -USE CASE模型

3)如何映射 总地来说，需求获取工作包括以下四步，但它们并非是严格

分离的。

要做的工作 产生的制品

-列出候选的需求 特征（Feature）列表

-理解系统语境 领域模型或业务模型

-捕获功能需求 Use case 模型

-捕获非功能需求 补充需求或针对一些特定需求

的use cases

(1)列出候选的需求

通过五种技术(自悟/交流/观察/小组会/提炼)之一,或某些技术的组合,以特征（Feature）的形式列出候选的需求,形成特征列表.其中:

特征:一个新的项（ item ）及相关的简要描述（shrinks） 。

例如：系统必须有能力支持100个以上的并发用户，每个用 户可以处理附录A中操作任务的任选组合，平均响 应时间应该小于1秒，最大响应时间应小于5秒。

特征作为需求, 被转换为其它制品:

应用系统

潜在的抽象层

（特征层）

一个抽象层

（ USE CASE 层）

USE CASE1

USE CASE

USE CASE2

USE CASE3

制品：USE CASE模型

规约

规约

形成

Actor 关联

关于特征的几点说明：

-每一特征有一个简短的名字和简要的说明或定义。

-每一特征还有一组对规划有意义的信息，可以包括：

状态（ Status），例如 ，提交，批准，确认

是否是组成的等。

估算的实现成本。( 所需的资源类型和人/时）。

优先级（Priority）(e.g.,critical, important, or

ancillary)。

实现中相联的风险等级。

(2) 理解系统语境

依据特征列表, 通过创建领域模型和业务模型来了解问题域的知识-是待建系统的语境.其中:

1领域模型

领域模型捕获了系统语境中的一些重要对象类型。其中

领域对象表示系统工作环境中存在的事物或发生的事件

领域类通常以三种形态出现：

业务对象：表示那些被业务所操纵（ manipulate）的事

物（ thing），例如定单，帐目和合同等

实在对象（Real-world objects）和概念：例如飞机，火箭等

事件（Events）：例如飞机到达，飞机起飞等

Order date of submission delivery address

Item description picture cost

Invoice amount date of submission last date of payment

Account balance owner

1..* payable

1..*

buyer

1 seller

1 领域类: Order, Invoice, Item, and Account

可见, 领域模型中的一个类图,捕获了该系统语境中

的一些重要的概念.

领域模型一般是以类图予以表达的。例如:

2业务模型 业务模型可以分为以下2个层次： •业务 use case 模型 抽象一个特定业务.一般可用USE CASE图来表达,其中以业 务use case来描述该业务的处理（business processes）, 以业 务 actors来描述与该业务交互的客户（customers ）. 例如:

取款 银行服务员

• 业务对象模型 业务对象模型是一个业务的内部（interior）模型。通 过一组workers 、business entities 、work units来细化业务 use case模型中的每一个业务use case。 其中， Business entity :表示某些事物（ something）, 例如 一张发票 它们在一个业务use case中被使用之。 work unit :是这样实体的一个集合，对最终用户而言，形成 了可认知的整体。 workers: 使用该业务use case的工作人员. 注:Business entities 和 work unit可作为领域类，用于表达 领域中的概念，例如定单，栏目，发票等。

一般地,每一个业务use case的细化可以通过交互图和活动 图来表达。

(3) 捕获系统功能需求,创建系统用况模型

1Use-Case 模型的组成

2Use-Case 模型的说明 用以表达客户认可的需求-系统必须满足的条件和能力。 是客户和开发人员之间有关系统功能的一种共识。 Use-Case 模型是一个系统的一种模型，包括 actors、 use cases 以及它们之间的关系。

Use-Case system Use-Case model

Actor Use case

* *

1

The Use-Case system denotes the top-level package of the model

3参与系统需求捕获的有关人员及其任务

System Analysis

responsible for

Use-case Specifier

responsible for

User-interface designer

responsible for

Architect

responsible for

use case model

Actor Glossary Use case User interface prototype

Architecture Description

4构造系统USE CASE模型中的活动 活动1:发现并描述Actor和USE CASE

任务1:发现 Actor

- 当存在业务模型时,可直接发现一些候选的 actors，即： • 对于业务中的每一个worker，可以建议一个候选的 actor • 对于每一个将要使用该信息系统的业务actor,即每一个业务客户， 可建议一个候选的actor。

- 当有或没有领域模型时 分析人员就要与客户一起标识 actor，并将所标识 actor进行分类， 形成 一些候选的 actors。

Note:还要标识表示外部系统的actor和系统维护和运行 所需要的actor 。

针对候选的actors ,可用以下2条准则来确定最终系统actors : 第一条准则：至少要识别出一个用户，可以扮演候选的 actor。 该准则将帮助我们仅发现那些相关的actors，避免 actor 仅是一些想象的“事物”。 第二条准则：系统中不同actors 实例之间，其角色的重叠 应是最少的。 其中,如果2个或多个actors有着几乎相同的角色，那么就 应该考虑： 是否将这些角色组合到一个actor的角色中，或 是否需要发现另外一个“一般化”的actor，使之具 有那些重叠的、公共的角色，并可以通过“泛化”， 形成那些特定actor。

任务2:Actors的命名与描述

Actors的命名：

对actors的命名,可“传达”（ convey）所期望的语义,因

此给出恰当的名字是非常重要的。

Actors的描述：

对actor的描述，应包含其角色（责任）以及为了完成其

责任所需要的条件。

例如: the Buyer, Seller

Buyer

A Buyer represents a person who is responsible for buying goods or services as described in the business use case Sales: from Order to Delivery. This person may be an individual or someone within a business organization. The Buyer of goods and services need the Billing and Payment System to send order and to pay invoices.

Seller

A Seller represents a person who sells and delivers goods or services. The Seller uses the system to look for new orders and to send order confirmations, invoices, and payment reminders.

--当已有一个业务模型时 可直接标识一些临时的用况,即为其中的一个“工作人员”或“业务参与者”的角色，对应地创建一个用况; 继之,对这些暂时的用况进行细化和调整，并确定工作人员和业务参与者 的哪些任务可由系统自动地予以实现，而后对确定的用况进行重新组织，以便更好地适应系统参与者的的要求 。 --当没有业务模型时 就要与客户和/或用户一起来标识用况。其中，需要一个一个地审阅参与者, 为每一个参与者建议一些侯选的用况。例如，研究一个参与者需要哪些用况，为什么需要这些用况，并研究参

与者的创建、改变、跟踪、迁移等工作，通常需要哪些用况来

支持之，研究业务用况中使用的业务对象，例如定单和帐目等。

任务3:发现Use Case

--不论采用什么方法，在发现候选用况中还需要进一步考虑一些问题，例如： •参与者是否还可能要通知系统一些外部事件，包括已经发生的一些事件，例如：发票已经过期。 •是否还可能存在一些其他的参与者 ，他们执行系统的启动、终止和维护。 •是否存在一些侯选的用况，不宜作为系统最终的用况 ，而应把它们作为其他用况的组成部分。 创建的用况是否可以作为一个功能单元，容易修改、测试和管理之等。 •对用户和系统之间的一个交互序列，是否在一个用况中予以规约，还是在多个用况中予以规约等。

--确定系统最终的用况 其中，会涉及一个很难处理的问题，即用况范围大小的确定。其中必须考虑：它是否是完整的 （complete），是否是另一用况的继续. 下面给出两条确定用况大小的基本准则： 第一条准则：用况应为它的参与者产生有值的结果 (result of value)，特别地，用况应向一个特定的参与者交付了可见的结果（值）. 这一准则的目的是为了避免发现的用况太小。 第二条准则：用况最好只有一个特定的参与者( particular actor)。 这条准则的目的是为了使所标识的用况都有一个真实用户，从而可以避免发现的 用况太大。

注:基于一些参与者而第一次发现的用况，常常需要予以重 新组织，重新评估，使之更加 “稳定”。例如， 假定已经有了一个体系结构描述，那么就要对新捕获的 用况进行必要的调整，以便适应已有的体系结构。

任务4:用况的描述 对用况的描述程度，取决于是在什么时候。一般或在发现时，或在需要精化时（参见4）任务3）。 在用况发现时，其描述一般应该： 首先给出该UAE CASE的名字；继之，给出该用况的概要描述。根据需要，概要描述一般可以采用两种形式，一种是简单地给

出用况的功能，例如： “Pay Invoice Use Cases “The use case Pay Invoice is used by a Buyer to schedule invoice payments. The Pay Invoice use case then effects the payment on the due date. ”

第二种形式是首先概括其动作，而后一步一步地列出系统与其参与者交互时所要做的事情。例如： “Before this use case can be initiated, the Buyer has already received an invoice (delivered by another use case called Invoice Buyer ) and has also received the goods or services ordered.: 1. The buyer studies the invoice to pay and checks that it is consistent with the original order. 2. The Buyer schedules the invoice for payment by the bank. 3. On the day payment is due, the system checks to see if there is enough money in the Buyer’s account. If enough money is available, the transaction is made.”

通过以上活动1: --形成了系统的粗略用况模型，记为用况模型[概述]。例如:

--以这一用况模型[概述]为此基础上，进而可形成系统的一些 非功能需求和相应的应用术语集。

财务结算机构（负责信用卡帐户的结算服务）

零售机构（顾客通过该机构刷卡，购买商品或服务。

活动2:确定use case的优先级（ Priority） 目标 这一活动目标是，在活动1）和2）的基础上，确定哪些用况 适宜在早期迭代中予以开发，哪些用况适宜在后期迭代中予 以开发，并形成系统用况模型[概述]视觉下的体系结构描述。

输入与输出

Architect Use Case model [outlined]

Supplementary Requirements

Glossary

Architecture Description [view of the use case model]

Prioritized Use Cases

实施

--刻画在体系结构方面具有意义的用况，包括:

对某一重要、关键功能的用况的描述;

包括对那些必须在软件生存周期早期予以开发的、某一重

要的用况的描述。

作用

--确定在规划的下一个迭代中，需要哪些开发活动和任务;

--在这一规划中,当然还需要考虑其它非技术因素，例如系

统开发的业务和经济方面的因素。

活动3: Use Case精化

目的

详细地描述事件流，包括use case是怎样开始的，是怎样结束 的，是怎样与actors 进行交互的。 输入与输出

Use case Specifier Use Case

model [outlined]

Supplementary Requirements

Glossary

Use Case [detailed]

Detail a Use Case

The result is a detailed description of a particular use case in text and diagram.

精化途径 涉及:如何描述一个 use case中所有可选的路径； 在一个 use case的描述中包括的内容； 如何在必要时形式化地给出use case的描述。

有效技术：事件流技术 对用况的精化描述，可以用事件流（Flow of Events）描述技术，规约当一个用况执行时，系统做了什么，以

及系统如何与其参与者参与者进行交互。 一个用况可以被认为有一个开始状态，一些中间状态，并从一个状态转换为另一状态，如下所示：

其中，红箭头线表示基本路径，曲线是其它可选路径。

首先，从开始状态到终止状态选择一条完整的基本路径，并对其进行描述。其中，这一基本路径的选择应该是用户

认为它是一条最通常的、并对相关参与者产生最有意义值

的路径。一般来说，这一基本条路径还应包含系统的一些

例外和异常处理。 接之，描述其余可选路径。其中，是否把其中那些很小的可选路径，作为基本路径的组成部分，还是作为一条独立

的路径，这是一个设计决策问题，取决于该描述是否精确，

是否容易阅读。

例如： “Paths of the Pay Invoice Use Case Precondition: The buyer has received the goods or services ordered and at least one invoice from the system. The buyer now plans to schedule the invoice(s) for payment.

Flow of Events Basic Path 1 The buyer invokes the use case by beginning to browse the invoices received by the system. The system checks that the content of each invoice is consistent with order confirmations received early(as part of the Confirm Order use case) and somehow indicates this to the buyer. The order confirmation describes which items will be delivered, when , where, and at what price.

2 The buyer decides to schedule an invoice for payment by the bank, and the system generates a payment request to transfer money to the seller’s account. Note that a buyer may not schedule the same invoice for payment twice. 3 later, if there is enough money in the buyer’s account, a payment transaction is made on the scheduled date. During the transaction, money is transferred from the buyer’s account to the seller’s account, as described by the abstract use case Perform Transaction(which is used by Pay Invoice). The buyer and the seller are notified of the result of the transaction. The bank collect a fee for the transaction, which is withdrawn from the buyer’s account by the system.

4 The use case instance terminates. Alternative Path In Step 2, the buyer may instead ask the system to send an invoice rejection back to the seller.In Step 3, if there is not enough money in the account, the use case will cancel the payment and notify the buyer.

Post-condition: The use case instance ends when the invoice has been paid or when the invoice payment was canceled and no money was transferred. ”

一般来说，在用况的一个精化描述中，其基本内容包括： 1 定义一个前置条件，用于表达该用况的开始状态； 2 定义第一个要执行的动作，例如上例中的 Step 1，描 述该用况是如何开始的，什么时候开始。 3 定义该用况中基本路径所要求的动作及其次序。上例中 以次序号（ Step 1-4)）定义了动作及其执行次序； 4 描述该用况是如何结束的，什么时候结束（例如 Step 4 ）； 5 定义一个后置条件，用于表达可能的结束状态； 6 描述基本路径之外的可选路径；

7 定义系统与参与者之间的交互以及它们之间的交换 (例如Step 2 和Step 3)，即描述该用况的动作是如何被相关参与者激发的，以及它们是如何响应参与者的要求。其中，如果该

系统与其它系统交互，则必须规约这一交互,例如引用一个标准的通讯协议。 8 描述系统中使用的有关对象、值和资源 (例如Step 3)，即描述在一个该用况的动作序列中，如何使用为该用况属性所

赋予的值。 总之,在用况描述中，必须明确描述系统做什么（执行的动作） ，描述参与者做什么，并从参与者做什么中分离出系统的责任。否则用况描述就不够精确。

注意:

一个事件流的描述应包括一组管理上适于修改、复审、设计、实现和测试的动作序列，并作为用户手册的一节内容。

对每一个用况的事件流，一般采用正文来描述其中的动作序列，只有当该用况的动作序列和/或该用况与其参与者的交互较为复杂时，才可使用活动图、状态图或交互图来描述之，而

且在实际工作中的很多情况下，正文描述和这些图之间往往是

相互补充的。

不管采用什么描述技术，都必须描述所有的可选路径，否则就不能说给出了该用况的规约。

规约人员应当： 紧密地与该use case的实际用户一起工作；在与其交谈 中，通常需要记录他们对该use case 的理解,并与其讨论建议 方案。

只有当满足以下条件时，才能说结束了用况描述： � 用况是很容易可理解的； � 用况是正确的（即捕获了正确的需求）； � 用况是完备的（例如，描述了所有可能的路径）; � 用况是一致的。

用况的描述可以在需求捕获结束的复审会中，由分析

员予以评估，也可以由用户和客户予以评估。但仅客

户和用户才能确认用况是否是准确的。

活动4:用户界面的原型构造

目的

建造一个用户界面的原型，使用户有效地执行use cases。

步骤

第一步，用户界面的逻辑设计

第二步，物理用户界面的设计

第三步，开发用户界面原型，演示为了执行该use

case，用户怎样使用该系统。

注：如何进行以上三步，可参见有关文献。

活动5 :Use Case 模型的结构化

前置条件:

系统分析员已经标识了actors 和 use cases, 已经以

图予以了描述，并给出了整个use case 模型的说明。

use case 规约人员已经对每一use case开发了详细的描述。

做什么：

• 抽取use case描述中一般的、共享的功能，用于特定

use case描述。

• 抽取use case描述中附加的或可选的（additional or

optional）功能，它们可能被扩展为特定use case描述。

使用泛化关系，标识并描述那些共享功能

例如：

Buyer Seller Pay Invoice

Pay Invoice 和 Perform Transaction

这2个 use case之间的泛化关系

Perform Transaction

使用扩展关系，标识并描述附加的或可选的功能

例如：

Buyer

Seller

Pay Invoice

Pay Invoice 和 Pay Overdraft Fee

这2个use cases之间的扩展关系

《extend》

Perform Transaction Pay Overdraft Fee

标识use case之间的其它关系

use cases之间还包括其它关系，例如包含关系（include ）。

例如:

在用况图的结构化中，应注意以下问题： 在建立用况的结构中，应尽可能地反映用况的实际情况。否则，不论对用户或客户，还是对开发人员本身，要理解这些用

况以及它们的意图就变得相当困难。 在用况的结构化中，不论是施加什么结构，对新引入的用况

都不应太小或太大。因为，在以后的开发中，对每一个用况都

需要对其做进一步处理，成为一个特定的制品。例如在需求获

取阶段，用况规约人员需要给出它的描述，而在后续的分析和

设计中，设计人员需要对不同的用况予以细化（realization），

这样，如果用况太小或太大，势必产生一系列管理上的问题。

在建立用况的结构中，应尽量避免对用况模型中的用况功能进

行分解。最好在分析和设计中对每一用况进行精化（refining），其中如果需要的话，以面向对象风格把用况中所定义的功能作

为概念分析层上对象之间的协作，这样可以对需求产生更深入

的理解。

通过对用况模型的结构化，最终形成系统的一个精化用况模型，记为用况模型[精化]。

RUP需求获取小结(四点)

需求获取以及相关制品

work to be done result artifacts

-List candidate requirements Feature list

-Understand system context Business or domain model

-Capture functional requirements Use case model

-Capture nonfunctional Supplementary requirements

requirements or individual use cases (for

use case specific req.)

业务模型或领域模型 建立了系统的语境，是创建系 统use case 模型的基础。  use case 模型 Use-Case Model 是软件和客户就需求的一个共识，即系统 必须具有的条件（conditions）和能力（capabilities） 。 The Use-Case 模型为系统分析、设计、实现以及测试提供 了基本的输入。 A Use-Case 模型是系统的一个模型，包含系统中 actors 、 use cases 以及它们之间的关系。即：

Use-Case system Use-Case model

Actor Use case

* *

1

The Use-Case model and its contents. The Use-Case system denotes the top-level package of the model

use-case 模型捕获了功能需求。非功能需求特定于单个的use

case，其规约具有一般性，并不针对一个特定的use case 。 use-case 模型的描述，可以通过：

- a survey description

-a detailed description of each use case. 对于use case 模型中的每一 use case ，应驱动开发的后 续工作，并实现它们的无缝连接。即在分析阶段和设计阶段， 应标识相匹配的 use-case 细化（realization），并标识测试阶段 中的一组测试用例（ test cases ）。

捕获需求阶段的活动

序号

输入 活动 执行者 输出

1 业务模型或领域模型,补充需求, 特征表

发现参与者和用况

系统分析员、客户、用户、其他分析员

用况模型

概述，术语表

2 用况模型概述，补充需求，术语表

赋予用况优先级

体系结构设计者 体系结构描述用况模型角度

3 用况模型概述，补充需求，术语表

细化用况 用况描述者 用况详述

4 用况详述，用况模型概述，补充需求，术语表

人机接口原型化

人机接口设计者 人机接口原型

5 用况详述，用况模型概述，补充需求，术语表

构造用况模型

系统分析员 用况模型详述