软件工程 第二部分
第五章 面向对象方法——RUP
统一软件开发过程（Rational Unified Process：RUP）是对象管理组织（OMG）所推荐的一个有关过程的标准。 RUP是基于UML的一种过程框架。比较完整地定义了将用户需求转换成产品所需要的活动集，并提供了活动指南以及对产生相关文档的要求。 RUP适应于大多数软件系统的开发，基于构件。
知识结构 过程模型：
- 需求获取模型
- 需求分析模型
- 软件设计模型
- 软件实现模型
- 软件测试模型
第一节 RUP的特点
以用况驱动的、以体系结构为中心的迭代、增量式开发
用况驱动 在系统的生存周期中，以用况作为基础，驱动系统有关人员对所要建立系统的功能需求进行交流，驱动系统分析、设计、实现和测试等活动，包括制定计划、分配任务、监控执行和进行测试等，并将它们有机地组织在一起，使各个阶段中都可以回溯到用户的实际需求。
以体系结构为中心
- 系统体系结构：是对系统语义的概况描述，对所有项目有关人员都是可以理解的。
- 关注子系统、构件、接口、协作、关系和节点等重要模型元素，而忽略其它细节。
- 迭代与增量
- 迭代是重复的部分
- 增量是增加的部分
初始阶段的基本目标
- 获得与特定用况和平台无关的系统体系结构轮廓
- 为系统建立商业案例
- 确定项目的边界
- 从业务角度指出该项目的价值
- 第一个重要的里程碑：生命周期目标（Lifecycle Objective）里程碑
细化阶段
- 细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素
- 第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑
构造阶段
- 形成最终的系统体系结构基线
- 开发完整的系统
- 确保产品可以开始向客户交付
- 第三个重要的里程碑：初始功能（Initial Operation）里程碑
交付阶段
- 确保软件对最终用户是可用
- 基于用户反馈的少量的调整
- 第四个里程碑：产品发布（Produce Release）里程碑
第二节 核心工作流
RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Wordflows）。
需求获取
RUP运用用况（Use Case）技术来获取需求 需求获取的基本步骤： 1. 列出后续的需求：特征列表 2. 理解系统语境：领域模型或业务模型 3. 捕获功能需求：用况模型 4. 捕获非功能需求：补充需求或针对一些特定的用况
1. 列出候选的需求
- 搜取特征：是一个新的项（Item）及其简要描述
2. 理解系统语境
- 创建领域模型或业务模型
- 业务用况模型：业务参与者和业务用况
- 业务对象模型：三个术语，工作人员、业务实体、工作单元；用交互图和活动图来表达
3. 捕获功能需求：建立系统的用况模型
- 发现和描述参与者
- 发现并描述用况
- 确定用况的优先级
- 精化用况
- 构造用户界面模型
- 用况模型的结构化
需求分析
需求分析的目标：在系统用况模型的基础上，创建系统分析模型以及在该分析模型视角下的体系架构描述。
1. 术语
（1）分析类：是类的一种衍型，很少有操作和特征标记，而用责任来定义其行为，并且其属性和关系也是概念性的。 存在三种不同类型的类：实体类、边界类和控制类 （2）用况细化 - 用况细化是一个协作； - 针对一个用况，其行为可以用多个分析类之间的相互作用细化，并记为用况细化； （3）分析包 - 分析包体现了“局部化”、“问题分离”等软件设计原理 - 分析包把一些变化限制到一个业务过程、一个参与者的行为或一组紧密相关的用况，形成一些不同的分析包。 - 提现“高内聚、低耦合”
2. 分析模型的表达
- 分析模型是由“分析系统”来定义的
- 分析系统包含一组具有层次结构的包
- 一个包可以包含一些分析类和用况细化
3.分析的主要活动
活动1：体系结构分析
- 标识分析包
- 处理分析包之间的共性
- 标识服务包
- 定义分析包的依赖
- 标识重要的实体类
- 标识分析包和重要实体类的公共特性需求
活动2：用况分析
- 标识分析类
- 描述分析类之间的交互
活动3：类的分析
- 标识责任
- 标识属性
- 标识关联和聚合
- 包的分析
活动4：包的分析
- 确保分析包尽可能与其它包相对独立
- 确保分析包实现了它的目标，即细化了某些领域类或用况
- 描述依赖
4. 需求分析总结
- 三个术语：分析包、分析类、用况细化
- 四个步骤
- 体系结构分析
- 细化用况
- 对类分析
- 对包进行分析
- 一个成功：分析模型
| 用况模型 | 分析模型 |
|---|---|
| 使用客户语言来描述 | 使用开发者语言来描述 |
| 系统对外的视图 | 系统对内的视图 |
| 外部视角下的系统结构 | 内部视角下的系统结构 |
| 作为客户与开发者之间“系统应做什么”的契约 | 作为开发者理解系统如何够花、设计和实现的基础 |
| 在需求之间可能存在冗余、不一致和冲突等问题 | 在需求之间不可能存在冗余、不一致和冲突等问题 |
| 捕获的是系统功能 | 给出的是细化的系统功能 |
| 定义了需要进一步分析的用况 | 定义了用况模型中每一个用况的细化 |
软件设计
- 软件设计：定义满足需求规约所需要的软件结构
- RUP的设计目标：定义满足系统/产品分析模型所规约需求的软件结构
1. 相关术语
- 设计类
- 用况细化
- 设计子系统
- 接口
2. 设计模型、部署模型及相关视角下的体系结构描述
（1）设计模型 - 设计子系统 - 设计类 - 用况细化 - 接口
（2）部署模型 是一个对象模型，描述了系统的物理分布，即如何把功能分布于各个节点上。
3. 设计的主要活动
活动1：体系结构设计
- 标识节点和他们的网络配置
- 标识子系统和他们的接口
- 标识在体系结构方面有意义的设计类和他们的接口
- 标识一般性的设计机制
活动2：用况的设计
- 标识参与用况细化的设计类
- 标识参与用况细化的子系统和接口
活动3：类的设计
- 概况描述设计类
- 标识操作
- 标识属性
- 标识关联和聚合
- 标识泛化
- 描述方法
- 描述状态
活动4：子系统的设计
- 维护子系统依赖
- 维护子系统所提供的接口
- 维护子系统内容
RUP设计小结
RUP设计的特点 （1）使用了一种公共的思想来思考设计、并使设计可视化 （2）给出了有关子系统、设计类和接口的需求 （3）支持对底线工作的分解，使之成为一些可以由不同开发组尽可能同时处理的、可管理的部分
RUP的设计方法 （1）给出表达设计模型的基本成分的术语 （2）规约了设计模型的语法，指导模型的表达 （3）给出了创建设计模型的过程以及相应的指导
RUP的设计模型 （1）设计子系统和服务子系统，以及它们的依赖、接口和内容 （2）设计类，以及它们具有的操作、属性、关系及其实现需求 （3）用况细化 （4）设计模型视角下的体系结构描述
RUP的部署模型 （1）节点，它们的特征以及连接 （2）主动类到节点的初始映射
分析模型和设计模型的区别
| 分析模型 | 设计模型 |
|---|---|
| 概念模型 | 软件模型 |
| 可应用于不同的设计 | 特定于一个实现 |
| 使用了三个衍生类：边界、实体、控制 | 使用了多个衍生类，依赖实现的语言 |
| 几乎不是形式化的 | 是比较形式化的 |
| 开发费用少 | 开发费用多 |
| 结构层次少 | 结构层次多 |
| 动态的，但很少关注定序方面 | 动态的，但更多关注定序方面 |
| 概况给出了系统设计 | 表明了系统设计 |
| 整个生命周期内不能修改、增加等 | 整个生命周期内容应该予以维护 |
| 为构建系统定义一个结构，是基本输入 | 构建系统时，尽可能保留分析模型所定义的结构 |
设计阶段的活动 （1）体系结构设计 （2）设计用况 （3）设计类 （4）设计子系统
RUP设计对实现的影响 （1）设计子系统和服务子系统由实现子系统予以实现 （2）设计类由文件化构件予以实现 （3）在规划实现工作时，将要使用用况细化以产生一些“构造” （4）在节点上部署构件、形成分布系统时，将使用部署模型和网络配置
RUP的实现与测试
RUP的实现目标 （1）基于设计类和子系统生成构件 （2）对构成进行单元测试 （3）进行集成和连接 （4）把可执行的构件映射到部署模型
RUP实现的主要活动 （1）实现体系结构 （2）集成系统 （3）实现子系统 （4）实现类 （5）完成单元测试
RUP的测试 包括：内部测试、中间测试和最终测试
RUP测试包括的主要活动 （1）计划测试 （2）设计测试 （3）实现测试 （4）执行集成测试 （5）执行系统测试 （6）评价测试
第六章 软件测试
第一节 软件测试目标与软件测试过程模型
软件测试的对象
软件 = 程序 + 文档 测试对象：各个阶段产生的源程序和文档
软件测试的目的
测试的目的应该是通过软件测试尽可能多地发现并改正软件中存在的错误。
软件测试的定义
- 软件测试（Software Testing）是按照特定规程发现软件错误的过程。
- 使用人工或自动手段，运行或测定某个系统的过程，其目的是检验它是否满足规定的需求，或清楚地了解预期结果和实际结果之间的差异。
测试和调试的区别
- 测试证明失败，调试证明正确
- 测试以已知条件开始
- 测试是由计划的
- 测试是一个发现错误、改正错误、重新测试的过程（回归测试）
- 测试的执行是有规程的
- 测试由独立的测试小组完成
- 测试的执行和设计可由工具支持
测试过程模型
- 测试设计
- 环境模型
- 对象模型
- 错误模型
- 测试执行
- 测试结果比较
第二节 软件测试技术
软件测试 人工测试 个人复查、走查、会审 机器测试 黑盒测试、白盒测试
路径测试技术
- 是一种白盒测试技术
- 依据的是程序的逻辑结构
- 采用控制流程图来表达被测程序模型
- 通过合理地选择一组穿过程序的路径，以达到某种测量度量
- 控制流程图
是一种表示程序控制结构的图形化工具，其基本元素是过程块、节点、判定
- 过程块 是没有被判定和/或被节点分开的一组程序语句，基本特征是：若过程块中的某个语句被执行，则块中所有语句都被执行
- 判定 是一个程序点，此处控制流出现分叉
- 节点 也是程序点，此处控制流进行结合
- 链 是过程块、判定、节点之间一种具有特定语义的关系
- 路径 是由链组成的，包含一串指令或语句，其长度有链的数目决定。对软件测试而言，限定路径为：从程序的入口开始，在出口结束。
测试策略（★）
路径覆盖（PX）：执行所有可能穿过程序控制流程的路径。最强的测试度量。 语句覆盖（C1）：至少执行程序中所有语句一次。最低的测试度量。 分支覆盖（P2）：至少将程序中的每个分支执行一次。 条件覆盖与条件组合覆盖 集中测试覆盖存在以下基本关系： 语句覆盖<=分支覆盖<=条件组合覆盖<=路径覆盖路径选取与用例设计 最小的强制性测试需求是语句覆盖率。 路径选取的一般原则：
- 选择最简单的，具有一定功能含义的入口/出口路径；
- 在已选取的基础上，选择无循环的路径，选取短路径、简单路径；
- 选取没有明显功能含义的路径，要研究该路径为什么存在；
基于事务流的测试技术
- 是一种功能测试技术
- 属于黑盒测试技术
- 事务：是指从系统用户的角度出发所见到的一个工作单元，有其“生”，有其“亡”
- 短信提醒
- 节日问候
- 数据更新
事务由一系列操作组成，用“事务流”表达。 事务流：是系统行为的一种表示方法，为功能测试建立了程序的动作模式。 事务流程图：表达系统的行为，多个事务流的执行。
事务流程图中的相关概念 1. 并生：事务处理产生一个新事务，由此这两个事务继续执行 2. 丝分裂：事务处理产生两个新事务。 3. 汇集：事务的不同活动可以汇集一处。 4. 吸收：一个事务可以被另一个事务吸食。 5. 结合：两个事务结合后产生一个新的事务。
如何根据事务流程图设计测试用例 步骤1：获得事务流程图 步骤2：浏览、复审 步骤3：用例设计 步骤4：测试执行
等价类法
是根据程序的I/O特性，将程序的输入划分为有限个等价区段，使得从每个区段内抽取的代表性数据进行的测试等价于该区段内任何数据的测试。 对于每个输入条件存在着程序有效输入的有效等价类和对程序错误输入的无效等价类。
1、如果有个输入条件规定了输入数据的取值范围，则可以确立一个有效等价类和两个无效等价类。 2、如果某个输入条件规定了输入数据的个数，则可以确立一个有效等价类和两个无效等价类。 3、如果某个输入条件规定了输入数据的一组可能值，每一个输入值就是一个有效等价类，一个无效等价类。 4、如果某个输入条件是一个布尔值，则可以划分为一个有效等价类和一个无效等价类。 5、如果某个输入条件规定了必须符合的条件，则可以划分为一个有效等价类和一个无效等价类。 6、若在已划分的某个等价类中个元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类。
边值分析法
是一种根据I/O边界等价类上或紧靠边界的条件，选择测试用例的更有效方法。
因果图法
因——输入条件和果——输出结果，通过因果图将功能说明转换成一张判定表，然后为每种输入条件的组合设计测试用例。 着重检查输入条件的组合。 C：原因 E：结果 原因和原因之间的约束关系
- E（互斥）：只能有一个成立
- I（包含）：至少有一个条件成立
- O（唯一）：有且仅有一个成立
- R（要求）：当a出现时，b必须出现
- M（屏蔽）：当a=1时，b必须是0，当a=0时，b的值不确定
用因果图生成测试用例的步骤 步骤1：找出模块的原因（输入条件或输入条件的等价类）和结果 步骤2：分析原因和结果之间的对应关系，画出因果图 步骤3：在因果图上标识出一些特定的约束和限制条件 步骤4：把因果图转化为判定表 步骤5：把判定表的每一列作为依据，设计测试用例
第三节 软件测试步骤
软件测试是按照与系统开发相反的方向进行的。 依次为：单元测试、集成测试、有效性测试、系统测试
单元测试
单元测试（Unit Testing）又称为模块测试（Module Testing），或模块分调，用于测试单个程序模块，确定模块的逻辑和功能是否正确。 单元测试采用白盒测试技术。 单元测试要考虑模块的4各特征： （1）模块接口 （2）局部数据结构 （3）重要的执行路径 （4）错误执行路径 单元测试还需要开发驱动模块和承接模块： （1）驱动模块：调用被测试模块的模块 （2）承接模块：被测试模块调用的模块 驱动模块->测试->承接模块
集成测试
集成测试（Intergration Testing）用来测试模块之间接口的正确性，也即模块之间的数据和控制传递。 集成测试是与单元测试平行进行的。 两种策略： - 自顶向下的集成测试：需要设计承接模块 - 自底向上的集成测试：需要设计驱动模块，每加入新的模块，还要进行回归测试
有效性测试
目标是发现软件实现的功能与需求规格说明书不一致的错误，采用黑盒测试技术
总结
| 测试步骤 | 测试对象 | 测试方法 | 测试内容 | 特点 |
|---|---|---|---|---|
| 单元测试 | 模块 | 白盒测试 | 模块接口、局部数据结构、重要的执行路径、错误执行路径 | 驱动模块、承接模块 |
| 集成测试 | 模块的组装、模块的接口 | 黑盒测试 | 模块的接口 | |
| 有效性测试 | 是否符合用户可见的文档 | 黑盒测试 | 软件实现的内容与需求说明书的一致性 | |
| 系统测试 | 软硬件的协作、系统的性能 | 黑盒测试 |