Transcript 细化领域模型

面向对象开发模型及过程
Unified Process
Xiao ding TSEG
© 2008 BUPT TSEG
UP基本结构
1. UP是一个软件开发过程
2. 软件开发过程是一个将用
户需求转化为软件系统所
需要的活动集合。
3. UP不仅仅是一个简单的过
程，而是一个通用的过程
框架。
4. UP使用UML来制定和描述
软件系统的所有视图。
5. UP的突出特点：用例驱动、
以构架为中心、使用迭代
和增量的开发模式
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
2
UP生命周期

UP是在重复一系列组成软件系统生命周期的循环。每次循
环都以向用户提供一个产品版本作为终结。

每次循环都包括四个阶段：初始、细化、构造和移交。每
个阶段又进一步细分为多次迭代过程

每次循环都产生系统的一个新的版本(version)，每个版
本都是一个可交付的产品它包括由能够编译和运行的构件
所体现的源代码、各种手册和相关的交付品

所完成的产品包括一整套需求、非功能性需求和测试用例
等文档，还包括构架和可视化的模型
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
3
UP 的迭代增量开发模式

UP的每个阶段可以进一步分为几个迭代过程。它是生成可
执行产品版本（内部和外部）的完整开发循环，是最终产
品的一个子集，从一个迭代过程到另一个迭代过程递增式
增长形成最终的系统。

迭代和增量的三个关键点

计划一小步

说明、设计和实现一小步

集成、测试和运行每次迭代（一小步）
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
4
UP的其它重要概念

在早期迭代中解决高风险和高价值的问题

不断地让用户参与评估、反馈和需求确认

在早期迭代中确定系统的核心架构

不断地验证质量，尽早并经常性的实施测试

进行可视化建模（使用UML）

认真管理需求，实施变更管理和配置管理
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
5
UP里程碑

每个阶段都以一个里程碑作为结束标志。通过获得一组可
用的制品来定义每个里程碑。

在每个阶段结束时进行评估以确定是否实现了此阶段的目
标。良好的评估可使项目顺利进入下一阶段。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
6
迭代和增量模型的特点

将项目分解成许多袖珍项目，每一个袖珍项目都作为一次迭代

每个这样的袖珍项目都像过去的瀑布模型，因为它处理的是瀑布模型
的活动。我们可以将每次迭代标注为一个“袖珍瀑布”

迭代不是一个完全独立的实体，它是项目的一个阶段，它在很大程度
上是作为项目的一部分而得到的

规划人员设法对迭代进行排序以得到一条有序的途径，使早期的迭代
为后期的迭代提供认知基础

项目的早期迭代增进了对需求、问题、风险和方案领域的了解，而后
期迭代产生的附加增量最终构成了外部版本，即客户产品

最终的成功是一个一直前进的迭代系列；即不必因为在后期的迭代中
了解到的一些问题而回退 2 ~ 3个迭代去修补模型
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
7
使用迭代和增量的理由

为了尽早处理关键风险和重要风险

为了建立一个构架来指导软件开发

能够处理不断变化的需求，并提供灵活变化的机制

为了提供一个开发过程，使所有工作人员更高效地工作
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
8
合理规划迭代过程
 项目经理在当前迭代的目标未达到之前不应同意开
始下一次迭代。否则，就会导致必须改变计划来适
应新的情况
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
9
确定迭代次序
 用例设定了一个目标；而构架建立了一个模式。记
住这个目标和模式，管理人员可以在人力资源充分
的情况下规划出进行产品开发的顺序
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
10
迭代和增量的优点

允许变更需求：需求总是会变化，这是事实。

逐步集成元素：集成并不只是简单的“一锤定音”。在迭代式方法中
，集成可以说是连续不断的。过去在项目结束时要占到整个项目工作
量 40% 的那段较长的、不确定的且棘手的时期，现在分散到六至九个
集成部分中，每一部分要集成的元素都比过去少得多。

及早降低风险：因为风险一般只有在集成阶段才能发现或得到处理。

有助于组织学习和提高：团队成员有机会在整个生命周期中边做边学
，各显其能。测试员可以早一些开始测试，技术文档编写员可及早开
始编写，其他人也是如此。

提高复用性：早期迭代中的设计复审可使构架设计师确定毋庸置疑的
潜在复用部分，并在以后的迭代中开发和完善这些公用代码。

生成性能更强壮的产品：性能上的瓶颈可以尽早发现并处理，而不象
在交付前夕，此时已来不及处理。

迭代流程自身可在进行过程中得到改进和精炼：一次迭代结束时的评
估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织
和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
11
初始阶段 Inception

主要目的是将一个好的想法发展为最终产品的一个构想。
本质上，该阶段应回答下面三个问题：

系统向它的每个主要用户提供的基本功能是什么？

该系统的构架看起来是什么样子？

开发该产品的计划如何？开销多大？

该阶段中最关键用例的简化用例模型可以回答第一个问题
。

在这个阶段，构架是试验性的，通常只是一个包括主要子
系统的大致轮廓。

在这个阶段，要确定最主要的风险及其优先次序，要对细
化阶段进行详细规划，并对整个项目进行粗略估算。

注意，该阶段的目标不是定义所有的需求
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
12
初始阶段的目标和任务
 建立项目的软件规模和边界条件，包括运作前景、
验收标准以及希望产品中包括和不包括的内容。
 识别系统的关键用例
 对比一些主要场景，展示至少一个备选构架
 给出用户提出的非功能性要求描述
 评估整个项目的总体成本和进度
 评估潜在的风险（源于各种不可预测因素）
 准备项目的支持环境。
 在阶段后期为细化阶段制定迭代计划
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
13
初始阶段的工件集

Vision：核心项目需求、关键特性、主要约束的总体构想

Business Case：业务用例

Use-case Model：初始的关键用例模型，占10-20%的数量

Risks List

Plan

Project-specific templates

Software Development Plan

Iteration Plan

Product Acceptance Plan

Development Case

Tools

Glossary
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
14
电子收款机（POS）系统案例

POS机是一个计算机化应用的系统，用于记录销售信息和处理支
付过程，一般超市和零售商店都会用到。该系统的假设条件如下
：
系统包括终端系统、条码扫描仪等硬件，还有相应的软件系统；
 它可能还需要与其他系统存在接口，比如信用卡支付系统、库存系
统、记费系统等；
 该系统具有一定的容错性能，比如在与库存系统暂时终端连接时，
仍能够进行物品的销售，不至于使系统瘫痪；
 多样化的终端接口：瘦客户Web终端、PC、触摸屏、无线PDA
 能适应不同商店业务销售的功能要求，提供一种灵活性和定制能力
的功能（作为系统开发的复用需求）

© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
15
POS案例-Step1


初始阶段应该考虑以下问题：

项目的前景如何？

业务背景和业务流程是什么？

可行性如何？项目是否停止或继续进行？

购买还是开发？

粗略估计一下成本，估计收益。
主要目标：


只进行一定的研究，得到未来新系统的可行性以及实现系统总体目
标的合理判断，并确定是否值得继续深入研究系统即可。（深入的
研究是细化阶段的工作）
概括为：

预见项目的范围、前景和业务案例；

项目相关人员是否就项目的前景达成基本的一致，项目是否值得继
续进行认真的研究。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
16
POS机案例-Step2
 该阶段的主要工作成果集
 项目前景
 业务背景及业务流程
 关键用例模型（10-20%）
 补充性规格说明
 词汇表
 ….
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
17
POS机案例-Step3

用例建模的基本过程：

1.选择系统边界
 POS作为一个待构建的系统，包含软件、POS机、输入终端等，收银员、
支付授权、税金计算等不包括在系统之内。任何系统之外的事物都在系
统边界之外。

2.识别主要角色
 主要角色：在使用系统服务的过程中满足自己的用户目标的那些参与者
。找出用户目标
 次要角色：为系统提供服务的那些参与者。说明外部接口和协议
 后台角色：对用例的行为感兴趣。保证找到并满足所有必要的兴趣。

3.识别主要角色的目标
 一般来讲：第2和第3步是同时进行的。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
18
POS机案例-Step4 寻找ACtor






顾客：

购买商品、退货、支付费用

希望得到快速的服务、能清楚地看到购买的商品和价格信息，得到收据以便退货
收银员：

处理销售、处理退货、入款、出款

希望能快速准确地输入，切无支付错误（出现错误时，将从其薪水中扣除）
经理：

启动、关机、处理销售异常操作

希望能快速地执行相应的操作，易于更正收银员出现的错误
系统管理员：

添加用户、修改用户、删除用户、安全管理、系统表管理

希望能方便地添加使用POS机的用户，并针对不同用户赋予不同的操作权限等
销售活动分析系统：

分析销售数据和销售表现

能够定期快速地获得必需的数据，制定相应的统计报表
库存系统、记费系统等……
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
19
主要参与者的确定

主要参与者是收银员还是顾客？

答案：收银员。

问题：为什么？为什么不是顾客？

主要原因取决于系统的边界，以及有关系统设计的主要对
象。

如果将企业（超市）和销售服务视为一个整体，则主要参
与者是“顾客”，顾客的主要目标是通过商店购买商品然
后离开。

然而从POS系统建设的角度出发，认为使用系统的用户是收
银员，他（她）的目标是使用POS机并通过该机处理销售交
易
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
20
POS机案例-Step5 确定用例

顾客：购买商品

收银员：处理销售、销售前准备、结束销售

经理：开关机、处理销售异常

系统管理员：用户管理、权限安全管理

……

由系统的主要参与者确定系统的关键用例

销售

用户管理

权限安全管理
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
21
POS机案例-Step6 用例图
 绘制初始用例图
认证系统
(from Actors)
收银员
(from Actors)
销售
(from <Use Case Name>)
<<角色>>
计费系统
(from Actors)
用户管理
(from <Use Case Name>)
系统管理员
(from Actors)
安全管理
(from <Use Case Name>)
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
22
POS机案例-Step6 关键用例描述

用例：销售

主要参与者：收银员

项目相关人员及其兴趣：（参见第19页）

前置条件：收银员必须已经被识别和授权

后置条件：存储销售信息、更新账目和库存信息、生成收据等

主要成功场景：
1.顾客携带商品到达POS机收费口
2.收银员开始一次新的销售
3.收银员输入商品标识
4.系统记录单件商品，并显示该商品的描述、价格、累加值。
收银员重复3～4步，直到商品输入结束。
5.系统显示总值并计算税金。
6.收银员请顾客付款。
7.顾客支付，系统处理支付。
8.系统记录完整的销售信息，并将销售和付款信息发送到外部的帐务系统和库存系统
。
9.系统打印收据
10.顾客带着商品和收据离开。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
23
POS机案例- step7 其他文档编写
用例模型只是描述了系统的功能性需求，其他需求
放在下列工件中描述：
 前景（vision）：概述项目的远景。用简洁的语言表达
项目总体想法，包括：项目为什么被提出？有哪些问题
？有哪些项目相关人员？他们需要什么？以及提出了哪
些解决方案等。
 补充规格说明：未在用例中描述的FURPS+需求。
 术语表：术语及其定义，还可以用作数据字典。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
24
需求：FURPS+

Function（功能）：特性、能力、安全性

Usability（可用性）：人性化因素、帮助和文档；

Reliability（可靠性）：故障周期、可恢复性、可预测性；

Performance（性能）：响应时间、吞吐量、准确性、有效性；

Supportability（可支持性）：适应性、可维护性、国际化、可配置性
。

＋：一些辅助性和次要的因素。

Implementation（实现）：资源限制、语言和工具、硬件等；

Interface（接口）：与外部系统接口所加的约束；

Operations（操作）：系统操作环境中的管理

Package（包装）

Legal（授权）：许可证或其他方式。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
25
前景 Vision

修订历史

简介

定位


商业机会

问题综述

产品定位综述

替代方案和竞争对手
page1
项目相关人员描述

项目相关人员（非用户）概述

用户概述

项目相关人员主要的高级别目标和问题

用户级别目标

用户环境
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
26
前景 Vision



page2
产品纵览

产品远景

优点概述

假设和依赖

成本和定价

授权和安装
系统特性概述

系统特性是系统提供的一个外部可观测到的服务，这种服务能够直
接满足项目相关人员的需要。

特性是系统能做的事情。系统会做<某特性>，比如记录销售记录、
支付授权（信用卡、借记卡、支票）
其他需求和约束
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
27
补充性规格说明

修订历史

简介

功能性（跨越许多用例的一般功能）


日志和错误处理

可插入的业务规则

安全性
可用性


page1
人为因素，比如屏幕的分辨率要求
可靠性

可恢复性：外部服务发生错误的时候，尽量采用本地方法来解决，
以使交易能够完成。

性能：交易的处理速度
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
28
补充性规格说明
page2

可支持性

适应性

可配置性

实现约束：用户要求使用Java技术的解决方案

采购的组件

免费的开放源码的组件

接口

值得注意的硬件及其接口

软件接口

领域（业务）规则：规定一个领域或者业务如何操作，如
：退货、折扣等。

法律问题

有关感兴趣的业务规则：商品定价、信用卡支付需要签名、条形
码产品等
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
29
术语表 Glossary
 修订历史
 定义
术语
定义和相关信息
别名
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
30
细化阶段 Elaboration

详细说明系统的绝大多数用例，并根据关键用例的实现在
第1-2次迭代中设计出系统的构架

最关键用例都要在这个阶段具体化。该阶段的结果是构架
基线

在细化阶段末期，要规划完成项目的活动，估算完成项目
所需的资源。

该阶段的关键问题是：用例、构架和计划是否足够稳定可
靠，风险是否得到充分控制，以便能够按照合同的规定完
成整个开发任务。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
31
细化阶段的目标和任务

确保构架、需求和计划足够稳定，充分减少风险，从而能
够有预见性地确定完成开发所需的成本和进度。

处理在构架方面具有重要意义的所有项目风险

建立一个已确定基线的构架

制作产品质量构件的演进式原型

细化前景文档

在细化阶段后期为构造阶段制定详细的迭代计划

建立支持环境。这包括创建开发案例、创建模板和指南、
安装工具
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
32
细化阶段的工件集

Vision

Prototypes

Use-case Model ：至少80%的用例要完成，所有用例均被识别，大多数用
例描述被开发

Domain Model： 结合用例模型完成相应的领域模型构建

Analysis Model： 可选，主要用于帮助系统结构的确定

Design Model： 结合用例给出系统的静态和动态结构

Data Model：

Implementation Model：将部分用例转化为代码
结合用例模型和领域模型给出相应的数据模型

Risk List

Tools

Software Architecture Document

Software Development Plan

Iteration Plan
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
33
细化阶段：迭代1
POS机案例 确定迭代次数

进入到细化阶段的首要工作就是确定阶段的迭代次数

根据细化阶段的主要目标：构建架构基线，来确定具体的
迭代次数

一般情况下，通过实现2-3个用例来证明架构的稳定性

本案例计划使用两次迭代
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
34
细化阶段：迭代1
构建领域模型 Domain Model




领域模型是OO分析中最重要的和经典的模型，它阐述了领
域中的重要业务概念
领域模型是UP过程的可选制品，但领域模型很大程度上会
影响用例模型分析和构建，甚至是设计模型中的软件对象
。
领域模型的构建限定于当前迭代所分析的用例，它能够不
断地演进用以展示相关的重要概念。
定义：是对领域内的概念类或现实世界中对象的可视化表
示，而非软件对象。也称之为概念模型、分析对象模型、
领域对象模型。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
35
细化阶段：迭代1
领域模型 Domain Model


应用UML表示法，领域模型被描述为一组没有定义操作的类
图，提供了概念透视图，用以展示：

领域对象或概念类

概念类之间的关联

概念类的属性
概念类的定义：是思想、事物或对象，可以从其符号、内
涵和外延来考虑

符号：表示概念类的词语或图形

内涵：概念类的定义

外延：概念类所适用的一组实例
表示“销售”交易的事件、具有时间和日期
销售1、销售2…销售n
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
36
细化阶段：迭代1
领域模型不是软件组件模型
 领域模型所关注的仅仅是客观世界中的事物并将其
可视化，而非诸如Java或C#类的软件对象。
 以下元素不适用于领域模型
 软件制品，例如窗口、界面、数据库
 软件模型中具有职责或方法的对象
销售数据库
软件制品，不属于
领域模型
领域模型
© 2007 BUPT TSEG
软件类制品
北京邮电大学 通信软件工程中心
37
细化阶段：迭代1
降低与OO建模之间的表示差异
 OO的关键思想：领域层软件类的名称要源于领域模
型的信息和职责
 这样可以减小人们的思维与软件模型之间的表示差
异
启发了软件
对象及其名称
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
38
细化阶段：迭代1
创建领域模型的原则
 以当前迭代所关注的需求为界
 寻找概念类
 将其绘制为UML类图中的类
 添加关联和属性
 寻找概念类的三条策略
 重用和修改现有的概念模型
 根据经验使用分类列表
 根据用例说明确定名词短语
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
39
细化阶段：迭代1
使用分类列表寻找概念类
概念类分类
示例
概念类分类
示例
物理或具体对象
Register
抽象名词的概念
Hunger
事物的设计、
描述和规范
位置
交易
Airplane
ProductSpecification
FlightDescription
Store
Airport
Sale, Payment
Reservation
组织
SalesDepartment
事件
Sale, Payment, Meeting
过程
交易项目
SalesLineItem
规则和政策
人的角色
其他事物的容
器
Cashier
分类
Pilot
Store, Bin
Airplane
有关工作、契约、财务
和法律事物的记录
ObjectAirline
Flight, Crash, Landing
SellingAProduct
BookingASeat
RefundPolicy
CancellationPolicy
ProductCatalog
PartsCatalog
Receipt, Ledger,
EmploymentContract
Item
MaintenanceLog
LineOfCredit
Passenger
Stock
财务设施及服务
在该系统之外 CreditPaymentAuthorizationSystem 手册、文档、引用
AirTrafficControl
的系统
论文、书籍
容器包含的元素
Acrophobia
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
DailyPriceChangeList
RepairManual
40
细化阶段：迭代1
通过识别名词短语寻找概念类

用例是通过名词短语识别领域概念的丰富源泉，因此应该
详述用例。

名词可以是概念类，也可能是概念类的属性。


属性一般是可以赋值的，比如数字或者文本。

该名词可以这样赋值吗？如果不行的话，那么就有可能是一个概念
类。

如果对一个名词是概念类还是属性举棋不定的时候，最好将其作为
概念类处理。

需要注意的是：不存在名词到类的映射机制，因为自然语言具有二
义性
这种方法的弱点是自然语言的不精确性
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
41
细化阶段：迭代1
POS机案例- Step1寻找概念类

主要成功场景：
1.顾客携带商品到达POS机收费口
2.收银员开始一次新的销售
3.收银员输入商品标识
4.系统记录单件商品，并显示该商品的描述、价格、累加值。
收银员重复3～4步，直到商品输入结束。
5.系统显示总值。
6.收银员请顾客付款。
7.顾客支付，系统处理支付。
8.系统记录完整的销售信息，并将销售和付款信息发送到外部的记
帐系统和库存系统。
9.系统打印收据

10.顾客带着商品和收据离开。
……
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
42
细化阶段：迭代1
POS机案例-寻找到的初始概念类

顾客：商品销售的主体和驱动者

商品：顾客所需购买的物品

POS机：商店进行商品销售的设备

收银员：商店执行商品销售并使用销售设备的人员

销售：一次或多次商品交易事件

商品标识：是销售设备能唯一标识物品的ID

商品条目：销售设备记录每一个商品销售的具体信息，销售小票中的多
条商品信息

商品总价：一次销售所有商品的总价

付款：顾客支付该次销售交易的金额

帐务系统：销售设备将一次销售交易的金额等信息传递给记账系统

库存系统：一次销售将对库存的商品信息和数量进行修改

商品描述：每一个销售商品的具体信息
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
43
细化阶段：迭代1
添加关联
 关联通常意味着我们必须知道这个关系的存在，并
且这个关系需要保存一段时间，时间的长短取决于
关联所处的语境。
 添加关联的两种方式：
 需要将概念之间的关系信息保持一段时间的关联－需要
知道（need-to-know）型关联
 只需理解型关联反映了理解概念类所需的本质信息
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
44
细化阶段：迭代1
添加关联-使用常见的关联列表
分类
示例
分类
示例
A在物理上是B的一
部分
A在逻辑上是B的一
部分
A在物理上包含在B
中或者依赖于B
A在逻辑上包含在B
中
Drawer — Register
A是B的一个组织子
单元
Department — Store
A是对B的描述
A是交易或者报表B
中的一项
A为B所知/为B所记录/
录入B中/为B所捕获
A是B的一个成员
Wing — Airplane
SalesLineItem — Sale
FlightLeg—FlightRoute
Register — Store, Item — Shelf
Passenger — Airplane
ItemDescription — Catalog
Flight— FlightSchedule
ItemDescription — Item
FlightDescription — Flight
SalesLineItem — Sale
Maintenance Job —
Maintenance Log
Sale — Register
Reservation — FlightManifest
Cashier — Store
Pilot — Airline
© 2007 BUPT TSEG
A使用或管理B
A与B通信
A与一个交易B有关
A是一个与另一个交
易B有关的事务
A与B相邻
A为B所拥有
A是一个与B有关的
事件
北京邮电大学 通信软件工程中心
Maintenance — Airline
Cashier — Register
Pilot — Airplane
Customer — Cashier
Reservation Agent —
Passenger
Customer — Payment
Passenger — Ticket
Payment — Sale
Reservation — Cancellation
SalesLineItem —
SalesLineItem
City— City
Register — Store
Plane — Airline
Sale — Customer, Sale — Store
Departure — Flight
45
细化阶段：迭代1
关联与概念类
 识别概念类比识别关联更重要，因此领域模型创建
过程中应该更加注重概念类的识别。
 根据“需要知道型”原则获取最小集合的关联，然
后利用“只需理解型”关联增强对领域中关键概念
的理解。
 太多的关联不仅不能有效地表示领域模型，反而容
易使领域模型变得混乱。
 避免显示冗余或导出关联。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
46
细化阶段：迭代1
POS机案例- Step2 添加关联
 POS机案例中领域模型的核心概念类应该是销售
 销售与POS机之间存在“使用”或者“扫描”的关系
 一个销售“包括”多个销售条目
 一次销售必然要有顾客“支付”相应的金额
 销售条目“记录”的是销售的商品信息
 POS机“位于”库存系统中
 商店的商品“存储”于库存系统
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
47
细化阶段：迭代1
案例- Step3 构建初始领域模型类图
商店
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
48
细化阶段：迭代1
Step 4 添加属性
 领域模型中包含的属性：是需求（用例）建议或者
暗示我们需要记忆的那些信息。
 有效属性类型原则：

概念模型中的属性应当被优先定义为简单属性或数据类型。如：boolean、
date、number、string、text、time，其他常见的简单数据类型如：
address、color、zip等。

用关联而不是用属性来联系概念类，
避免用属性表达一个复杂的领域概念。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
49
细化阶段：迭代1
POS机案例- Step5 完善领域模型类图
产品描述
1
describes
0..1
1..n
1
帐务系统
1
1
records-accounts-for
1
1
付款
1
n
1
1
0..1
1
is for
1
<<Actor>>
顾客
(from Actors)
© 2007 BUPT TSEG
Used-by
n
1
Houses
1..n
POS机
Captured on
销售
1
商店
Logs-completed
Payed-by
1
产品目录
n
stocks
Contained-in
contains
n
商品
Records-sale-of
销售条目
1..n
1
1
works on
1
<<Actor>>
收银员
(from Act...
北京邮电大学 通信软件工程中心
50
细化阶段：迭代1
Step 6 领域模型是否正确
 没有所谓唯一正确的领域模型
 所有的模型都是用于理解领域的特点
 领域模型主要是在特定群体中用于理解和沟通的工
具
 领域的概念
 术语
 概念之间的关系
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
51
细化阶段：迭代1
构建用例模型 Use-Case Model
 用例模型的组成
用例图
用例说明
SSD系统顺序图
操作契约
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
52
细化阶段：迭代1
POS案例-Step1-用例模型之SSD

系统顺序图（SSD）：用于说明与系统相关的输入和输出
事件，它是操作契约和对象设计的输入。

用例图表达了角色使用系统的目标，那么角色是如何激活
系统操作满足其目标的呢？


面向对象思想中，通过事件激活。

系统事件有哪些？系统顺序图（SSD）
用例描述角色是如何与系统进行交互的。在交互中，角色
对系统发起系统事件，系统中的某些系统操作对这些事件
加以处理。

例如，当收银员使用扫描仪输入商品ID时，收银员请求POS机记录对该商
品的销售（EnterItem事件），该事件引发了系统的操作。用例说明暗示
了EnterItem事件，而SSD将其变得具体和明确。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
53
细化阶段：迭代1
系统顺序图 SSD
 系统顺序图：
 为每个用例的主要成功场景以及频繁或复杂的替代场景
进行设计；
 描述外部角色与系统（作为一个黑箱）之间交互的事件
；
 本次迭代主要考虑主要角色产生的事件；
 也可以描述次要角色接收系统产生的事件。
 描述事件的顺序。
 此时所描述的系统行为只需要确定系统“做什么
”，而无需解释如何做。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
54
细化阶段：迭代1
系统顺序图 SSD目的
 软件设计中需要明确的问题是：系统中会发生什么
事情？为什么？
 原因是我们必须为这些处理和事件（来自于鼠标、
键盘…）来设计软件
 来自于参与者（人或计算机）的外部事件
 时间事件
 错误或异常（通常源于外部）
 因此需要准确地知道什么是外部输入的事件，即系
统事件
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
55
细化阶段：迭代1
SSD与用例图之间的关系
简化的现金支付的处理销售场景
1.
2.
3.
4.
顾客携带所需商品到POS机进行付款
: 系统
: 收银员
收银员开始一次新的销售交易
1:makeNewSale
收银员输入商品项目标识
2*[more items]:enterItem(itemID,quantity)
系统逐条记录出售的商品项目，并显
示该商品的基本描述、数量、价格和
累计金额
5.
系统显示总价
6.
收银员告知顾客总价并提请付款
7.
顾客支付
8.
系统处理支付。
description,total
3:endSale
total
4:makepayment(amount)
change due, receipt
……
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
56
细化阶段：迭代1
POS案例-Step2- 整理SSD的信息

在SSD中所展示的元素：操作名称、参数、返回的数据等

需要对这些在图中很简洁的数据加以适当的解释，以便为
设计时能明确输入了什么和输出了什么。

词汇表是详细描述这些元素的最佳选择

例如，实例中的一条返回信息“change due,receipt”。就可以在词
汇表中加入票据条目，显示票据样本（数码图片）、详细内容和布
局
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
57
细化阶段：迭代1
POS案例-Step3-用例模型之操作契约

用例的操作契约可以作为用例模型中一个补充环节，它对
用例指出的系统操作的作用提供了更详细的分析。

操作契约的主要输入是SSD中确定的系统操作、领域模型或
者领域专家的见解。

操作契约也可以作为对象设计的输入

定义操作执行的结果（对象状态的改变），而非过程
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
58
细化阶段：迭代1
操作契约的组成
操作以及参数的名称
操作：
交叉引用： （可选择）可能发生此操作的用例
前置条件： 在操作执行前，领域模型中系统或对象状态的假设，它们在此
操作的逻辑内不会得到测试，而被假设为真，同时，它们并非
无关紧要而应让读者了解此假设的存在。
后置条件： 操作完成后领域模型中对象的状态。（最重要的部分）
操作：
交叉引用：
前置条件：
后置条件：
enterItem(itemID:ItemID,quantity:integer)
用例：Sale
有一个Sale正在进行
1.创建一个SalesLineItem实例sli（实例创建）
2.sli和当前的Sale形成关联（关联形成）
3.sli.quantity变成quantity（属性修改）
4.在itemID匹配的基础上，sli和ProductSpecification形成关联
（关联形成）
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
59
细化阶段：迭代1
操作契约的后置条件

后置条件描述了领域模型内对象的变化，后置条件可以分
为三种类型：

创建或删除实例

属性值的变化

形成或消除关联（UML的链接）

后置条件是声明性的，而且是面向状态变化而不是面向行
为的。正是基于此，后置条件能够在不描述系统操作如何
实现的前提下描述系统操作引起系统状态的变化，给出了
分析的细节。因此，分析阶段可以集中精力于系统发生了
什么而非是如何发生的。

在需求分析时，要为系统操作产生一个完整、详细的后置
条件集是不可能甚至是不需要的。（初始契约不完整）。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
60
细化阶段：迭代1
示例：enterItem后置条件



创建和删除实例

输入itemID和商品条目的quantity后，会创建哪些新对象？

答：创建了SalesLineItem的实例Sli。
属性修改

在收银员输入商品条目标识和对应的商品数量后，修改了哪些新对
象或现有对象的属性？

答：SalesLineItem的quantity被赋值为quantity参数，即修改属
性 Sli.quantity = quantity
关联形成和消除

在收银员输入商品的itemID和quantity后，形成或清除了哪些新的
或已有的对象之间的关联？

答：Sli与当前的Sale关联

答：基于itemID的匹配，Sli与ProductDescription关联
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
61
细化阶段：迭代1
示例：销售用例中的系统操作契约 page1
操作：
makeNewSale( )
交叉引用：
前置条件：
用例：Sale
无
后置条件：
1.创建了Sales的实例s（实例创建）
2.S被关联到Register（关联形成）
3.S的属性被初始化（属性修改）
操作：
enterItem(itemID:ItemID,quantity:integer)
交叉引用： 用例：Sale
前置条件： 有一个Sale正在进行
后置条件： 1.创建一个SalesLineItem实例sli（实例创建）
2.sli和当前的Sale形成关联（关联形成）
3.sli.quantity变成quantity（属性修改）
4.在itemID匹配的基础上，sli和ProductSpecification形成关联（关
联形成）
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
62
细化阶段：迭代1
示例：销售用例中的系统操作契约 page2
操作：
交叉引用：
前置条件：
endSale( )
后置条件：
1.Sale.iscomplete被置为真（修改属性）
操作：
makePayment(amount:Money )
用例：Sale
正在进行中的销售
交叉引用： 用例：Sale
前置条件： 正在进行中的销售
后置条件： 1.创建了Payment的实例p（实例创建）
2.p.amountTendered被赋值为amount（修改属性）
3.P被关联到当前的Sale（形成关联）
4.当前的Sale被关联到Store（形成关联），将其加入到完成销售
的历史日志中
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
63
用例模型、领域模型与设计模型的关系
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
64
总结
初始阶段、细化阶段的初次迭代
 初始阶段完成了大约10%～20%的需求调研，细化
阶段的第一次迭代在此基础上进行稍微深入的调研
工作。
 需求和面向对象的分析工作：do
the right thing（做
正确的事情）
 设计工作：do
the thing right（正确地做事情）
 开始对象设计：核心是交互图。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
65
细化阶段：迭代2
设计模型

领域模型描述了概念类、属性、关联

用例模型表达了系统功能需求、系统事件和系统操作契约
。

那么谁来完成系统的功能呢？

概念类转化到设计类（包括属性和关联）

设计类的职责是什么？

设计类如何协作处理系统事件、满足系统操作契约，并最终实现系
统功能来满足用例的需求？

其中设计对象的职责非常关键。

GRASP（General Responsibility Assignment Software Patterns）是
一种软件设计模式，称为对象职责分配模式。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
66
细化阶段：迭代2
GRASP 基于职责设计对象

职责和方法：职责是抽象，方法实现了职责

对象的职责分为两种类型：
 了解型（knowing）
 了解私有的封装数据；
 了解相关联的对象；
 了解能够派生或者计算的事物。
Sale具有了解其销售总额的职责
 行为型（doing）
 自身执行一些行为，如创建一个对象或者进行计算；
 启动其他对象中的动作；
 控制或协调其他对象中活动。
Sale具有创建SaleLineItem对象的职责

方法是对象操作的实现，是完成对象职责的手段。职责既
可以由一个方法实现，也可以与其他方法或者对象协作实
现。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
67
细化阶段：迭代2
职责与顺序图

顺序图体现了如何为对象分配职责：一个对象接收了某条
消息，表明该对象具备了处理该条消息的职责。

职责的分配来源于顺序图，也就是说当绘制顺序图的时候
就是在决定职责的分配。
: POS机
: Sale
makePayment(cashTendered)
create(cashTendered)
抽象，表示“销售”对
象具有创建“付款”的
职责
© 2007 BUPT TSEG
: 付款
“POS”机使用makePayment消息
向“销售”发出请求，“销售”
在相应的makePayment方法中进
行处理；完成这个职责还需要通
过协作创建“付款”对象，并调
用其构造器
北京邮电大学 通信软件工程中心
68
细化阶段：迭代2
GRASP 设计模式

创建者（Creator）

信息专家（Information Expert）

控制器（Controller）

低耦合（Low Coupling）

高内聚（High Cohesion）

多态（Polymorphism）

纯虚构（Pure Fabrication）

间接性（Indirection）

防止变异（Protected Variations）
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
69
细化阶段：迭代2
GRASP 创建者

问题来源：谁该负责创建某类的实例

解决方案：如果满足以下的条件之一（越多越好），则可将创建类A的
职责分配给类B。
 B聚合（aggregate）对象A；
 B包含（contain）对象A；
 B记录（record）对象A的多个实例；
 B密切使用对象A；
 B拥有创建对象A所需要的初始化数据（B是创建对象A的信息专家）
 那么，B是对象A的创建者；如果有多个选项满足的情况下，首选聚集或
包含A的类B。

创建者模式的意图是寻找在任何情况下都与被创建者对象具有连接的
创建者，且具有低耦合的特点。

案例问题：谁应当负责创建SaleLineItem实例？
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
70
细化阶段：迭代2
GRASP 创建者

在领域模型或用例说明中去寻找聚合、包含SaleLineItem实例的类。

发现概念类Sale包含多个SaleLineItem对象，为此根据创建者模式，
Sale是具有创建SaleLineItem实例职责的候选者，进而可产生以下顺序
图

这个模式的优点在于支持低耦合
: POS机
: Sale
makeLineItem(quantity)
create(quantity)
: SaleLineItem
这个职责的分配要求在Sale
中定义MakeLineItem方法。
强调：在绘制顺序图时考虑和
决定这些职责的分配。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
71
细化阶段：迭代2
GRASP 信息专家

问题来源：给对象分配职责的原则是什么？

解决方案：将职责分配给拥有履行一个职责所必需信息的类，即信息
专家。换言之，对象处理自己拥有信息的事务。

案例问题：谁应该负责获取一次销售的总额？

在具体案例中，某个类需要知道一次销售的总额。即，谁应当了解销售的
总额？

设计模型中还没有软件类，怎么办？

此时，“信息专家”就是领域模型。

查看领域模型，找出拥有相关信息的概念类，将其应用或扩展到设计模型
，形成软件类。

按照信息专家原则，我们找到了概念类Sale。

在设计模型中加入Sale软件类，为其分配获取总额的职责并以名为getTotal
的方法来表示
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
72
SaleLineItem
quantity
: POS机
1
1..n
Contained-in
Item
ItemID
Records-sale-of
0..1
Sale
date
time
1: t = getTotal( )
: Sale
getTotal()
n
describes
部分领域模型
1
Sale
date
time
添加一个新方
法getTotal()
1
ProductDescription
ItemID
description
price
按照信息专家模式找出软件类Sale的getTotal操作
SalesLineItem.quantity
销售总额＝销售量×销售价格
ProductSpecification.price
Sale
date
time
1: 1:t=getTotal()
: POS机
: Sale
getTotal()
2: 2*[more items]:st=getSubTotal()
SaleLineItem
quantity
getSubTotal()
: Product
Description
lineItems[i] :
SaleLineItem
3: 2.1:getPrice()
Product
Description
ItemID
description
price
getPrice()
© 2007 BUPT TSEG
注意：职责的实现需要分布
在不同的对象中的信息，一
个任务需要多个对象（信息
专家）协作来完成。
为了实现获知和回答销售总
额的职责，找到了三个对象
并分配了三个职责。
北京邮电大学 通信软件工程中心
73
细化阶段：迭代2
GRASP 信息专家的优点

优点：
维持了信息封装性，因为对象使用自己的信息完成任务。支持了低
耦合，提高了系统的健壮性和可维护性。
 系统行为分散在不同的类中，这些类提供处理自己信息的能力，使
得这些类易于理解和维护。


注意：
当一个类按照信息专家模式得到的职责有很多种类型的时候，就产
生了类的内聚性问题。
 需要利用隔离原则，将不同逻辑方面的职责进行隔离，分配给不同
的软件对象，以提高内聚性。


相关模式：低耦合模式、高内聚模式
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
74
细化阶段：迭代2
GRASP 低耦合

问题来源：怎样降低依赖性，减少变化带来的影响，提高重用性？

解决方案：分配一个职责给对象时，要保持对象间的低耦合度。减少
对象间的依赖性，从而减少变更带来的影响，提高对象的重用性。

耦合：测量一个元素连接、了解或者依赖其他元素的强弱尺度。

使用高耦合性的类会出现的问题
C
A
如果类A和其他的类之间
关系简单一些就好了！
修改A，会影响B,C,D？
B
D
© 2007 BUPT TSEG
想重用A，太麻烦！
北京邮电大学 通信软件工程中心
75
细化阶段：迭代2
GRASP 低耦合 案例分析

考虑创建Payment实例并使它与Sale关联。

问题：哪个类应负责这件事情呢？

方案1：现实世界中是POS机记录了Payment，根据创建者原则建议将
Pos机作为Payment的候选者。Pos机会把addPayment消息发送给Sale，
并把新的Payment作为参数传递给它。
1: MakePayment()
: Cashier
2: crate()
: POS机
: Payment
3: addPayment(p)
: Sale
这种职责分配使得Pos机与Payment之间产生了耦合，即
Pos机类必须知道Payment类
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
76
细化阶段：迭代2
GRASP 低耦合 案例分析


方案2：回顾领域模型中这三个类之间的关系，发现Sale与
Payment类之间有关联关系
考虑支持低耦合，由Sale类来创建Payment类的实例，这样
避免了Pos机类与Payment了之间的耦合。
1: MakePayment()
: Cashier
: POS机
2: MakePayment()
: Payment
: Sale
3: create()
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
77
细化阶段：迭代2
GRASP 耦合关系

在制定设计决策阶段必须考虑低耦合问题。

在C++、Java这类面向对象语言中，两个类之间的耦合常见的形式包括
：


X具有引用Y实例或者Y本身的属性；

X调用Y对象中的服务；

X的方法中有Y类型（参数或返回）；

X是Y的直接或间接子类；

Y是一个接口，X实现了这个接口。
耦合的权衡原则：

尽量降低耦合，但耦合是不可避免的，因为系统的任务是通过关联对象之
间的协作完成的；

耦合一个高稳定的系统元素不是一个问题，因为不会发生变更；

更多地考虑与系统不稳定元素之间的耦合，尽量降低这种耦合。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
78
细化阶段：迭代2
GRASP 高内聚

问题来源：怎样保持对象是有重点的、可理解的、可管理
的，并且能够支持低耦合？

解决方案：分配一个职责给对象时，要保持对象本身功能
的高内聚度。

对象内聚度：是对象职责联系的紧密程度。

一个低内聚的对象会执行许多互不相干的功能，或需要完成大量的
工作。这样的类是不合理的，会导致下列问题：
难于理解、难于重用、难于维护；
系统脆弱，常常受到变化的影响。
大粒度对象，承担了本该委托给其他对象完成的职责。

经验：一个具有高内聚的类具有数目相对较少的方法和紧密相关的
功能，但是它并不完成太多的工作。任务过大时，寻求与其他对象
协作完成。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
79
细化阶段：迭代2
GRASP 高内聚 案例分析






同样考虑创建Payment实例，并与Sale类相关联。
如果按照前述的方案1，那么Pos机将具有“支付”的职责
，并完成makePayment系统操作的部分职责。
如果Pos机负责的职责越来越多且与系统操作有关的某些
或大部分工作，它的任务负荷将不断增加，而成为非内聚
的类。
这种方案对于系统实现来说并非不可取，但是需要从系统
整体职责分配的角度出发，它可能具有低内聚的倾向。
如果采用方案2，则将创建Payment的职责分配给了Sale类
，一定程度上支持了Pos机的高内聚。
方案2既支持了Pos机类的高内聚也支持了它的低耦合性，
所以它是我们所需要的系统设计。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
80
细化阶段：迭代2
GRASP 控制器

问题来源：在系统边界之后（UI Layer之后）首先接收和协调系统操
作的第一个对象是什么？

控制器是我们寻找的第一个对象，它负责接收和处理系统操作消息。

解决方案：把接收或者处理系统事件的职责分配给这样一个类：

1.
它代表整个系统、设备或者子系统，称为外观控制器
2.
它代表一个发生系统事件的用例场景，称为用例控制器，通常命名为:

<UseCaseName>Controller/Coordinator/Session

在相同的用例场景中使用同一个控制器类处理所有的系统事件；

一次会话是与一个角色进行交谈的一个实例。

注意：“window/view”等类不参与完成与系统事件相关的任务，它们接收这
些事件后，将其委派给控制器。
通常，UI层不应当包含应用逻辑，为此UI层对象必须把外部系统事件
的请求委派给其他层。如果“其他层”为领域层时，就需要确定相应
的领域对象。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
81
细化阶段：迭代2
GRASP 控制器 示例
两种选择：外观控制器、
用例控制器
哪个对象应负责接收这个系统事件？
有时称它为控制器或协调者。它通常不
实现职责，而是将职责委托给其他对象
控制器是从界面层到领域层的外观对象
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
82
细化阶段：迭代2
GRASP 控制器使用原则

当一个系统不具有“太多”的系统事件，或者用户接口不
可能将事件消息重定向到其他控制器时，选择外观控制器
是合适的。



这时，外观控制器相当于一个应用的封面，隔离了用户接口和应用
逻辑。
如果在外观控制器中由于过多的职责而变得“臃肿”的时
候，应该选择用例控制器。

如果选择了用例控制器，那么每一个用例都有一个不同的控制类，
而且只有一个，以便维护用例的状态。

用例控制器可以实现有一定执行顺序的系统操作。
不论是外观控制器还是用例控制器，它们只是接收系统事
件消息，并没有实现系统操作的职责，系统操作应该委托
给领域对象处理。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
83
细化阶段：迭代2
GRASP 系统操作的分配
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
84
细化阶段：迭代2
GRASP UI层到领域层的耦合关系
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
85
细化阶段：迭代2
UP 分析模型

分析模型可作为从用例模型及领域模型过渡到设计模型的
一种手段。

分析模型由一些抽象地分析类构成，用以展示系统相关的
抽象用例实现过程。


边界类：位于系统边界，包括所有窗体、报表、与硬件设备以及其
他系统的接口

控制类：用于模拟一个或几个用例的特定行为，通常它控制和协调
其他的对象而不进行具体的业务逻辑实现，即它封装了用例的特定
行为

实体类：具有保存那些要持久存储的信息的方法，通常用领域模型
的术语进行命名。数据库设计时可以对每个实体类生成一张表
仅用于展示系统的软件三层结构，而不用考虑每个类的具
体实现
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
86
细化阶段：迭代2
设计模型 用例实现




UP定义：在设计模型中用协作的对象描述如何实现一个特定用例。一
个用例实现就是一个特定场景的对象协作。
在分析的过程中使用用例模型、SSD确定了系统事件；进而系统执行了
一个用例场景，这就是一个用例实现。
顺序图中的对象是由领域模型中的概念类启发命名的软件对象，也包
括为了设计而引入的纯虚构对象，顺序图描述这些对象协作完成任务
的交互过程。
在POS机案例中发现的系统事件




makeNewSale()
enterItem()
endSale()
makePayment()
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
87
细化阶段：迭代2
对象设计 makeNewSale -1
操作
makeNewSale()
交叉引用
前置条件
用例：Process Sale
后置条件
1.创建一个Sale实例s（实例创建）
无
2.s和Register建立关联（关联形成）
3.初始化s的属性（属性修改）
问题1：如何为系统操作makeNewSale选择控制器
解决方案： 根据“控制器”模式，要么使用“外观控制器”，
要么使用“用例控制器”。在本案例中，由于只
存在少量的系统操作，为此选用“外观控制器”，
以Register作为设计模型中的软件对象。
注意：此时的Register已经不再是物理终端设备
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
88
细化阶段：迭代2
对象设计 makeNewSale -2

设计用例实现过程

Register对象根据系统事件makeNewSale创建(使用创建者模式)软件
对象Sale

当创建Sale对象时，还需要为创建一个空集合来记录销售的商品条
目SaleLineItem。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
89
细化阶段：迭代2
对象设计 enterItem -1
操作
交叉引用
前置条件
后置条件
enterItem(itemID:ItemID,quantity:integer)
用例：Process Sale
有一个销售正在进行
1.创建一个SalesLineItem实例sli（实例创建）
2.sli和当前的Sale建立关联（关联形成）
3.sli.quantity变成参数quantity（属性修改）
4.实例sli在itemID匹配的基础上与
ProductSpecification建立关联（关联形成）
问题1：控制器类的选择
问题2：是否要显示商品的描述和价格？
问题3：创建新的SaleLineItem
问题4：寻找ProductDescription
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
90
细化阶段：迭代2
对象设计 enterItem -2 顺序图
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
91
细化阶段：迭代2
对象设计 endSale -1
操作
endSale()
交叉引用
前置条件
用例：Process Sale
后置条件
1.Sale.isComplete变为真（属性修改）
有一个销售正在进行
问题1：控制器类的选择
问题2：设置isComplete属性
问题3：计算销售总额
主要成功场景：
3、收银员输入商品标识
4、系统逐条记录出售的商品条目…
收银员重复3-4，直到结束
5、系统显示销售总额
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
92
细化阶段：迭代2
对象设计 endSale -2
1.
谁应该负责了解销售总额？
2.
销售总额=所有销售商品条目小计之和
3.
小计=数量*产品价格
1、ProductDescription.price -> ProductDescription
2、SaleLineItem.quantity -> SaleLineItem
3、所有当前Sale中的SaleLineItem -> Sale
问题1、谁应该负责计算销售总额呢？
解答：根据信息专家模式，应该是Sale，因为它知道计算总额所必需的
所有SaleLineItem实例。为此Sale将具有获得总额的职责，并赋予
getTotal方法
问题2、谁应该负责计算销售小计呢？
解答：根据信息专家模式，应该是SaleLineItem，因为它知道销售数量和
与之关联的ProductDescription。给其赋予getSubTotal方法。
问题3、谁负责知道销售商品的价格呢？
解答：ProductDescription，因为它封装了价格的属性，并赋予getPrice方法
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
93
细化阶段：迭代2
对象设计 endSale -3

设计Sale.getTotal

由Register发送getTotal消息给Sale对象实例

Sale给每个相关的SaleLineItem对象实例发送getSubTotal消息

SaleLineItem 又给其相关的ProductDescription对象实例发送
getPrice消息
<<method>>
Public int getTotal()
{
int tot=0;
for each SaleLineItem, sli;
tot = tot + getSubTotal();
return tot;
}
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
94
细化阶段：迭代2
对象设计 makePayment 1
操作
交叉引用
前置条件
后置条件
makePayment(amount:Money)
用例：Process Sale
有一个销售正在进行
1.创建一个Payment实例p（实例创建）
2.p.amountTendered等于amount（属性修改）
3.p和当前的Sale建立关联（关联形成）
4.当前的Sale和Store建立关联（关联形成）：目的是向已
完成销售的历史日志中添加。
主要成功场景：
……
6.收银员请顾客付款。
7.顾客支付，系统处理支付。
8.系统记录完整的销售信息，并将销售和付款信息发送到外部的记帐系统和库存系统。
9.系统打印收据
……
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
95
细化阶段：迭代2
对象设计 makePayment 2

问题1：创建Payment

问题2：记录sale日志

问题3：计算余额
处理支付
计算余额
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
96
细化阶段：迭代2
将UI层连接到领域层

一种方法：初始化例程（如Java的main方法）创建一个UI和一个领域
对象，并将领域对象传递给UI。

另一种方法：一个UI对象从一个大家熟知的源（如工厂对象）抽取领
域对象。
public class Main {
public static void main( String[] args ) {
Store store = new Store();
Register register = store.getRegister();
ProcessSaleJFrame frame = new ProcessSaleJFrame( register );
...
}
}
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
97
细化阶段：迭代2
初始化和“启动”用例



初始化的领域对象是什么？
应选择位于或接近于领域对象包含或聚合层次中的根类作
为初始领域对象。该类可能是外观控制器，比如Register，
也可能是容纳所有或大部分其他对象的某些对象，比如
Store。
应用如何启动？

建立一个初始领域对象，由它负责后续直接领域对象的创建。

应用发送create消息以创建初始领域对象

如果初始领域对象控制进程，则应用继续发送run消息给初始领域对
象，移交应用控制权。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
98
细化阶段：迭代2
POS机案例 设计 Store.create

根据以上原则和分析结果，可有如下初始化内容：

创建Store, Register, ProductCatalog, ProductDescription

建立ProductCatalog, ProductDescription关联

建立Store与ProductCatalog的关联

建立Store与Register的关联

建立Register 与ProductCatalog
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
99
细化阶段：迭代2
设计类图



顺序图（用例实现，UCR）将处理系统消息的职责分配给设
计类，DCD（Design Class Diagram）则将处理消息的职责转化
为对象的方法。
顺序图和DCD经常并行交叉进行：画一部分顺序图，然后更
新DCD，再进一步扩展顺序图，依此类推。
DCD主要定义类的接口，不定义算法。
基本的属性和关联
 类的接口：方法
 属性类型、属性可见性、对象导航等。

© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
100
细化阶段：迭代2
设计类图步骤 -1

STEP1：通过扫描所有的顺序图以及领域模型中涉及的类，识别参与软
件解决方案的类。

Register,ProductCatalog,Store,Payment

Sale,ProductSpecification,SalesLineItem
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
101
细化阶段：迭代2
设计类图步骤 -2

STEP2:根据在领域模型中已经识别出来的部分属性，绘制
适当的类图。
注意：角色类未被转换到设
计模型中。如：Cashier。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
102
细化阶段：迭代2
设计类图步骤 -3

STEP3:添加方法，
通过顺序图获得每
一个类的方法；

一般，发送给类X
的所有消息的集合
就是类X必须定义
的大多数方法。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
103
细化阶段：迭代2
设计类图步骤 -3.1

添加方法要注意的几个问题：

创建create消息一般被忽略，因为在编程语言中，每个类都有相应的构造函数来实
现对象的创建。(但要注意构造函数的参数）

为了实现封装性，每个对象一般都有简单的存取私有成员的get和set方法，这些方
法是显然的，为了不干扰类图的可读性，不列出存取方法。

发送给多对象的消息，处理消息的操作不是多对象中的每一个对象的方法，而是容
纳这些对象的容器对象。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
104
细化阶段：迭代2
设计类图步骤 -4

STEP4:添加更多的类型信息

属性类型

方法参数类型以及返回类型
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
105
细化阶段：迭代2
设计类图步骤 -5

STEP5:添加关联和导航

导航（navigability）：是关联角色的一个属性，表示从一个源对
象沿着关联导航方向可以单向地到达一个目标类。

导航意指可见性－－通常是属性可见性。
在OOPL中，从A关联导航到B，转换为类A中有一个类B的实例属性。

定义A到B带导航修饰关联的常见情况：
A发送一个消息到B
A创建一个B的实例
A需要维护到B的一个连接
– 往往：一个对象的创建者要求拥有一个与它所创建对象的不间断连接。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
106
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
107
细化阶段：迭代2
POS机案例 较为完善的DCD
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
108
细化阶段：迭代2
设计类图步骤 -6

STEP6:添加依赖关系

依赖关系：表示一个元素
（类、用例等）对另外一
个元素有所了解（用带箭
头的虚线表示）。

在类图中常用依赖关系表
示类之间的非属性可见性
（参数可见性、本地可见
性、全局可见性）。属性
可见性用关联和导航表达
。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
109
细化阶段：迭代2
设计类图步骤 -7

STEP7:类成员的细节表示（可选）

成员可见性：惯例：属性私有，方法公有。

方法体描述：注释。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
110
细化阶段：迭代2
设计类图总结
2
1
3
4
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
111
细化阶段：迭代2
设计转换为代码 -1
 由DCD创建类的定义
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
112
细化阶段：迭代2
设计转换为代码 -1.1

添加引用（reference）属性

对象的引用属性是指引用另外一个对象作为自己的属性，而不是指简单类
型的属性。

一个类的引用属性由类图中的关联和导航来建议

一般来讲：这个引用属性的名称就是导航方向的角色名称
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
113
细化阶段：迭代2
设计转换为代码 -2

从交互图创建方法

交互图显示了响应方法调用而发送的消息，这些消息的顺序将转换
为方法定义中的一系列语句。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
114
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
115
细化阶段：迭代2
设计转换为代码 -3

多对象的容器类/集合类在代码中的体现

一个对象维护一组对其他对象的可见性通常是必要的；

在类图中体现在多重性大于1的一端。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
116
细化阶段：迭代2
设计转换为代码的次序建议
类的实现要按照从低耦合到高耦合度最高的次序来完成
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
117
细化阶段深入
需求变更

需求来源：POS机案例中，要求系统能够支持信用卡和支票
支付的功能，以及在销售的过程中顾客可以随时取消销售
行为。

用例说明中需要添加扩展的场景描述
用例1:Process Sale
主要成功场景：
1.顾客携带购买的商品或服务到POS机结账
……
7.顾客付款，系统处理支付。
……
扩展：
7b.用信用卡支付：包含Handle Credit Payment用例。
7c.用支票支付：包含Handle Check Payment用例。
……
a*：在任何时间，顾客可以选择取消购物：包含Cancel Sale
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
118
细化阶段深入
绘制用例图-用例关系的引入

用例建模专家Cockburn建议：尽量使用包含关系而非扩展
和泛化

使用扩展关系的合适的时机是：不允许修改基用例文本。
<<include>>
顾客
(from Actors)
销售
取消交易
(from <Use Case Name>)
(from <Use Case Name>)
<<include>>
<<include>>
<<include>>
收银员
(from Actors)
现金支付
信用卡支付
支票支付
(from <Use Case Name>)
(from <Use Case Name>)
(from <Use Case Name>)
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
119
细化阶段深入
扩展的场景描述
扩展场景：
7b.用信用卡支付：
1.顾客输入信用卡账号信息
2.系统向外部的支付授权服务系统发出授权支付请求和批准支付的请求
2a.系统侦测到与外部系统交互失败：
1.系统通知收银员有错误发生
2.收银员要求顾客改变支付方式
3.系统收到支付批准并通知收银员
3a.系统收到支付拒绝的通知
1.系统通知收银员系统拒绝支付
2.收银员要求顾客改变支付方式
4.系统记录信用卡的支付情况，包括支付授权
5.系统显示信用卡签名的输入机制
6.收银员要求顾客为信用卡支付签名。顾客签名。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
120
细化阶段深入
领域建模：使用泛化

通过名词短语可以发现“现金支付”和“信用卡支付”以及“支票支
付”的概念非常类似，可以考虑使用面向对象中的继承特性，即泛化
Payment
关系来表示它们之间关系。
这里是概念类
，而非软件类
CashPayment


CreditPayment
CheckPayment
将一个类划分为子类的动机：

1.子类具有额外的相关属性；（扩充属性）

2.子类具有额外的相关关联；（子类继承父类的属性和关联）

3.子类在运行、处理、反应或操作等相关方式上与超类或其他子类不
同。（扩充操作）

4.子类代表一个活动的事物，他们与超类的其他子类在相关的行为方
式上相似但不同。（扩展操作：多态）
将多个子类概括为概念超类的动机：

这多个子类代表一个相似概念的变体

所有子类具有的相同属性可以提取并在超类中表示

© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
所有子类具有的相同关联都可以被提取并与超类相关。
121
细化阶段深入
领域建模：Payment概念类的层次结构
Sale
1
Payed-by
1
Payment
金额 : Currency
CashPayment
CreditPayment
n
© 2007 BUPT TSEG
这里是概念类
，而非软件类
CheckPayment
1
Identified by
paid with
1
CreditCard
1
Check
北京邮电大学 通信软件工程中心
122
细化阶段深入
领域建模：关联类的使用

POS及案例中添加了使用信用卡或者支票进行销售的支付，
那么就存在支付授权认证的必要性

通过支付场景中名词短语可发现“支付授权服务系统”、
“授权支付请求”和“批准支付的请求”等概念

为此需要对原有的领域模型进行更改，添加一个能与外部
认证系统相关联的“认证服务”概念类

授权服务为每个商店分配一个商业标识ID

商店在进行授权服务请求时需要发送带有ID的消息

商店对于每个服务都有不同的商业ID
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
123
细化阶段深入
领域建模：关联类的使用
Store
地址 : String
名称 : String
n
authorizes payment of
n
AuthorizationService
adress
name
phoneNumber
CreditAuthorizationService
1
问题：
商业ID（merchantID）该作为
商店概念类的属性呢？还是应该
作为认证服务概念类的属性呢？
CheckAuthorizationService
1
authorizes
authorizes
n
CreditPayment
n
CheckPayment
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
124
细化阶段深入
领域建模：关联类的使用原则

在领域模型中，如果一个类A可能同时拥有多个相同的属性B，则不要
将属性B置于A中。应将属性B让在另一个类中，并将其与类A进行关联
。

例如一个人可能有多个电话号码，则应将电话号码放在一个单独的类
中(PhoneNumber)，然后让其与Person类相关联。
Store
地址 : String
名称 : String
AuthorizationService
adress
name
1..nphoneNumber
authorizes payment of
n
n
n
purchase
Sells
ServiceContract
merchantID
1..n
n
Store
地址 : String
名称 : String
AuthorizationService
adress
name
1..nphoneNumber
authorizes payment of
n
ServiceContract
merchantID
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
125
细化阶段深入
细化领域模型：包图的使用

领域模型很容易扩展到足够复杂，以至于难以理解，这时
就需要将其分解成与概念相关的包

包的划分原则：

同一个主题域－由概念或目的紧密相关

在同一个类层次中

参与同一个用例

紧密相关
Domain
Core/Misc
Sales
Authorization
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
Products
Payments
126
细化阶段深入
细化领域模型：Core/Misc包
广泛共享、或者没有一个明显归属的概念可以置入
Core/Misc包中。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
127
细化阶段深入
细化领域模型：Sale包
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
128
细化阶段深入
细化领域模型：Products包
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
129
细化阶段深入
细化领域模型：Payment包
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
130
细化阶段深入
细化领域模型：Authorization包
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
131
细化阶段深入
新需求的SSD
信用卡支付SSD
makeCreditPayment
支票支付SSD
makeCheckPayment
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
132
细化阶段深入
新需求的后续工作内容
 描述系统操作makeCreditPayment的操作契约
 描述系统操作makeCheckPayment的操作契约
 发现一些可能的新的领域概念类
 利用GRASP模式将操作契约中完成状态的职责分配给不同
的概念类（用交互图表示）
 从领域类转换到设计类（DCD表达）
 从交互图中寻找设计类的方法
 测试用例、代码实现
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
133
细化阶段深入
系统构架


架构：是一组有关如下要素的重要决策：

软件系统的组织、构成系统的结构化元素、接口、它们相互协作的
行为的抉择；

结构化元素和行为元素逐步组合成粒度更大的子系统的方式的抉择
；

指导元素及其接口、协作和组合方式的架构风格的抉择。

不仅包括结构化元素，也包括行为元素，特别是系统和子系统的大
尺度的职责及其协作。

作为系统的一种描述，架构还要解释系统为什么以某种方式进行设
计的动机或理由。
UP中的架构分析

架构调研：识别对系统存在或可能存在重大影响的功能性和非功能
性需求（特别是非功能性需求）。广义上讲，这是对系统的重大设
计决策有特别影响的需求进行分析。

架构设计：对软件、硬件和网络、运营、政策等软件设计中的需求
和要素进行决策。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
134
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
135
partition
layer
一层就是
一个包。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
136
一般层间耦合观点：
1.所有较高层可依赖于技
术服务层和基础层；
2.依赖于业务基础设施层
的领域层是要首先考虑的；
3.表示层发出对应用层的
调用，应用层再对领域层
进行服务调用。表示层不
直接对领域层进行调用，
除非不存在应用层。
4.如果应用是一个单进程
的“桌面”程序，为了保
证效率，领域层对其他层
可见。
© 2007 BUPT TSEG
5.如果是分布式系统，那
么领域对象的的序列化复
制对象（值对象或者数据
容器对象）通常可以被传
北京邮电大学 通信软件工程中心 递到表示层。
137
构造阶段 Construction

在这个阶段，构架基线逐渐发展成为完善的系统。在初始
阶段形成的构想进化成为一个准备移交给用户的产品。

在这个阶段的末期，产品将包括管理层和客户对发布的版
本达成共识的所有用例。但是，产品不可能是完全没有缺
陷的。很多缺陷将在移交阶段发现和改正。

在里程碑处要回答的问题是，早期交付给某些客户的产品
是否完全满足了用户的需求？
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
138
构造阶段的目标

通过优化资源和避免不必要的报废和返工，使开发成本降
到最低。

快速达到足够好的质量

快速完成有用的版本

完成所有所需功能的分析、开发和测试。

迭代式、递增式地开发随时可以发布的完整产品。

确定软件、场地和用户是否已经为部署应用程序作好准备
。

开发团队的工作实现某种程度的并行。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
139
构造阶段的任务

Resource management, control and process optimization

Complete component development and testing against the
defined evaluation criteria

Assessment of product releases against acceptance criteria for
the vision.
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
140
构造阶段的工件集


System

Implementation Model

Data Model

Test Model
Plan

Deployment Plan

Iteration Plan

Design Plan

Training Materials

Project-Specific Templates

Tools
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
141
移交阶段 Transition

进行 Beta 测试，按用户的期望确认新系统

培训用户和维护人员

市场营销、进行分发和向销售人员进行新产品介绍

调整活动，如进行调试、性能或可用性的增强

根据产品的完整前景和验收标准，对部署基线进行的评估

实现用户的自我支持能力

在涉众之间达成部署基线与前景的评估标准一致

最终：
产品发布
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
142
移交阶段的任务

executing deployment plans

finalizing end-user support material

testing the deliverable product at the development site

creating a product release

getting user feedback

fine-tuning the product based on feedback

making the product available to end users
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
143
移交阶段的工件集

The Product Build

Release Notes

Installation Artifacts

Training Materials

End-User Support Material

Test Model
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
144
核心工作流

软件开发流程定义了“谁”、
“何时”、“如何”做“某事
”。四种主要的建模元素被用
来表达：

角色（Role）
“谁”

活动（activity）“如何”

工件（artifact）“某事”

工作流（workflow，discipline
） “何时”
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
145
1、核心工作流（业务）

业务建模的目的在于

了解目标组织（将要在其中部署系统的组织）的结构及机制。

了解目标组织中当前存在的问题并确定改进的可能性。

确保客户、最终用户和开发人员就目标组织达成共识。

导出支持目标组织所需的系统需求。

为实现这些目标，业务建模工作流程说明了如何拟定新目
标组织的前景，并基于该前景来确定该组织在业务用例模
型和业务对象模型中的流程、角色以及职责。

作为对这些模型的补充，还开发了以下工件：

补充业务规约

词汇表
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
146
2、核心工作流（需求）


需求工作流程的目的是：

与客户和其他相关人员在系统的理解方面达成并保持一致。

使系统开发人员能够更清楚地了解系统需求。

定义系统边界（限定）。

为计划迭代的技术内容提供基础。

为估算开发系统所需成本和时间提供基础。

定义系统的用户界面，重点是用户的需要和目标。
在此阶段，完成以下工作内容：
创建前景文档，说明用户需求
建立用例模型
 识别actor
 识别use case
 描述use case
其他功能和非功能性需求在补充规范中说明。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
147
3、核心工作流（分析与设计）


显示系统“如何”在实现阶段被实现的，达到下列目标：

在特定的实现环境中完成用例描述中指定的任务和功能

满足了所有的需求

健壮地被建造（如果功能需求发生变化，应该易于更改）
分析设计结果是一个设计模型和可选的分析模型：

设计模型由设计类和一些描述组成：
设计类被组织成具有良好接口的设计包和设计子系统
描述则体现了类的对象如何协同工作实现用例的功能


设计模型是源代码的抽象
设计活动以体系结构设计为中心
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
148
4、核心工作流（实现）

定义代码的组织结构：以层次化方式组织实施子系统；

实现类和对象：以构件的形式（源文件、二进制文件、可
执行文件等）；

将开发出的构件作为单元进行测试；

将由单个实现者或小组产生的结果集成为可执行的系统。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
149
5、核心工作流（测试）

核实对象之间的交互。

核实软件的所有构件是否正确集成。

核实所有需求是否已经正确实施。

确定缺陷并确保在部署软件之前将缺陷解决。

UP提出了迭代的方法，意味着在整个项目中进行测试，从
而允许尽可能早地发现缺陷，从根本上降低了修改缺陷的
成本；

测试生命周期的阶段：计划、设计、实现、执行和审核。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
150
6、核心工作流（部署或发布）
 目标是成功地生成版本，将软件分发给最终用户。
包含的活动：
 生成软件本身外的产品；
 软件打包
 安装软件
 给用户提供帮助
 许多情况下还包括如下的活动：
 计划和进行β测试版
 移植现有的软件或数据
 正式验收
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
151
7、核心工作流（配置和变更）

完成建立并管理基线的任务。

基线：已经通过正式复审和批准的某规约或产品，它因此可以作为
进一步开发的基础，并且只能通过正式的变更控制过程进行改变。

配置项：置于配置和变更管理控制之下的工件。

提供了管理系统演化中的多个变体、跟踪软件版本的准则
；

描述了如何管理并行开发、分布式开发，如何自动化创建
工程；

涵盖了需求变更管理，即：如何报告缺陷？如何管理缺陷
？及如何使用缺陷来跟踪进展和发展的倾向？
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
152
8-9、核心工作流（项目管理及环
境）

项目管理

集中在迭代开发过程的组织管理方面

目标是提供以下的事物来使该任务更简单：
 管理项目的框架；
 计划、配备、执行、监控项目的实践准则；
 管理风险的框架。

环境

目的是给软件开发组织提供软件开发环境（过程和工具），软件开
发队伍需要它们的支持；

集中在项目环境中配置过程的活动，同样着重支持项目的开发规范
的活动，提供了逐步指导手册，介绍了如何在组织中实现过程；

还包含了定制流程所必须的准则、模板、工具的开发工具箱。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
153
UP最佳实践

短时间分区式的迭代：2～6周，不鼓励时间推迟

适应性开发：小步骤、快速反馈和调整

在早期迭代中解决高风险和高价值的问题

不断地让用户参与评估、反馈和需求；

在早期迭代中建立内聚的核心架构

不断地验证质量；提早、经常和实际地测试；

使用用例：获取需求、制定计划、进行设计、测试、编写终端用户文
档的驱动力量。

可视化软件建模（使用UML）

仔细地管理需求（需求提出、记录、等级划分、追踪和生命周期跟踪
。）

实行变更请求和配置管理。
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
154
UP工件与阶段的关系
流程
工件
业务建模 领域模型
用例模型
构想
需求
补充规范
术语表
设计模型
设计
软件架构文档
数据模型
实现
实现模型
项目管理 软件开发计划
测试
测试模型
环境
开发案例
初始
细化
构造
移交
I1
E1..En
S
R
R
R
R
S
S
S
S
R
S
R
C1..Cn
T1..Tn
S
S
S
S
S
S
R
R
R
R
R
R
R
S表示开始（Start），R表示提炼（Refine）
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
155
UP总结
© 2007 BUPT TSEG
北京邮电大学 通信软件工程中心
156