软件工程 (8)

第8章 用例驱动
第8章 用例驱动
8.1 用例驱动开发概述 8.2 为什么使用用例 8.3 确定客户需要什么 8.4 需求工作流 8.5 领域模型 8.6 业务模型 8.7 补充需求 8.8 初始需求 8.9 初始需求：考勤系统实例研究 8.10 继续需求流：考勤系统实例研究 8.11 修订需求：考勤系统实例研究 8.12 测试工作流：考勤系统实例研究 8.13 需求规格说明书 8.14 小结 习题８
第8章 用例驱动
知识点 需求工作流，领域模型，业务模型，建模技术。
难点 如何将理论与实践结合。
基于工作过程的教学任务 通过本章学习，了解为什么使用用例，学习用例驱动开
发的基本概念；确定客户需要什么，掌握需求工作流的基本 过程；理解领域模型、业务模型对需求的作用，掌握相关的 建模技术；以考勤系统为例，全面展示需求工作流的工作过 程；了解考勤系统的测试工作流。
第8章 用例驱动
8.1 用例驱动开发概述
在需求工作流中，开发者必须确定什么样的软件是客户 想要的。因此，需求捕获有两个目标：发现真正的需求，并 以适合于用户、客户和开发人员的方式加以描述。“真正的 需求”是指在实现时可以给用户带来预期价值的需求，但是， 很多客户不知道他们需要什么．
第8章 用例驱动
第8章 用例驱动
需求 分析 设计 实现 测试
用例模型 分析模型 设计模型 实施模型 实现模型 测试模型
图8-1 统一过程从需求到测试的一系列工作流
第8章 用例驱动
用例常用于捕获软件系统(尤其是基于构件的系统)的需 求。用例不只是捕获需求的工具，还能够驱动整个开发过程。 在寻找和确定类、子系统和接口时，在寻找并确定测试用例 时，在规划开发迭代和系统集成时，用例都将作为主要输入。 对每次迭代，用例驱动完成一整套工作流(从需求捕获，经 过分析、设计和实现，最后到测试)，并将这些不同的工作 流集成在一起。
第8章 用例驱动
开发人员设计类和用例实现，以便更充分地应用相关的 产品和技术(如对象请求代理、图形用户界面、构造工具和 数据库管理系统等)来实现系统。根据子系统对设计类进行 分组，并定义子系统间的接口。开发人员还要进一步建立实 施模型，其中包括定义在计算节点上的系统的物理结构，以 验证用例能够实现并能在节点上运行。
第8章 用例驱动
设计模型具有下面的特点： 设计模型是有层次的，也包括跨层次的关系，这些关 系在UML中很常见：关联、泛化和依赖等； 用例实现是协作的构造型，协作表示类元在做某件事 情(如实现用例)时如何参与和扮演角色； 设计模型是实现的蓝图，设计模型的子系统和实现模 型的构件之间存在直接的映射关系。
“以适合于用户、客户和开发人员的方式”主要是指对需求 的最后描述必须能够让用户和客户理解，但是，即便客户真 正了解他们需要什么，也有可能很难精确地把其想法传达给 开发者，因为大多数客户的计算机知识不如开发团队的成员。 这也是需求工作流的难点之一。
第8章 用例驱动
系统通常有多种用户，每种用户都是一个参与者，参与 者使用系统与用例进行交互，用例是系统向参与者提供某些 有价值结果而执行的动作序列，即某种功能，参与者和用例 构成用例模型。
在分析和设计期间，用例模型经分析模型转化为设计模 型。简单地说，分析模型和设计模型都是由类元(Classifier) 和说明如何实现用例的集合组成的。类元是一种描述行为和 结构特征的模型元素，它具有属性和操作，可以用状态图描 述，有的还可以实例化、参与协作等。类元的种类包括类、 行为、构件、数据类型、接口、节点、信号、子系统以及用 例。其中，类是最常见的类元。
பைடு நூலகம்
第8章 用例驱动
统一过程(UP)的核心思想是用例驱动、以构架为中心的 迭代和增量开发。图8-1描述了统一过程中的一系列工作流 和模型。从机器解释的角度看，实现模型是最形式化的，而 用例模型的形式化成分最少。也就是说，部分实现模型可以 通过编译和连接成为可执行代码，而用例模型主要用自然语 言来描述。
第8章 用例驱动
开发人员以用例模型为输入来创建分析模型。用例模型 中的每个用例都实现为分析模型中的用例实现，用例和用例 实现的依赖性支持需求和分析之间的无缝可跟踪性。通过对 用例进行处理，开发人员可以确定参与实现用例的类，例如， “取款”用例可以通过分析“取款”类、“账户”类、“分 配”类及其他无需在此标识的类来实现。开发人员将用例中 定义的职责分配为类的职责，因此“账户”类包括诸如“从 账户上提取一定数额的现金”的职责。这样，就可以得到一 个类的集合，合在一起就能实现用户所需的用例。
第8章 用例驱动
8.2 为什么使用用例
在软件开发中，很常见的问题是许多客户不知道他们需 要什么，进一步来讲，即便客户真正了解他们需要什么，也 有可能很难精确地把这些想法传达给开发者，因为大多数客 户的计算机知识不如开发团队的成员。对开发人员来说，对 软件产品及其功能进行形象化描述已经很难了，对并不精通 软件工程的客户来说则更加困难。
第8章 用例驱动
分析模型也是一种模型，是需求的详细规格说明，可作 为设计模型的切入点。分析模型可能是暂时的，只存在于前 几次迭代中，然而，在某些情况下，尤其对于大型、复杂系 统，分析模型会存在于系统的整个生命周期。这种情况下， 分析模型的用例实现与设计模型中相应的用例实现之间存在 一种无缝的跟踪依赖关系，分析模型中每个元素都可以从实 现它的设计模型元素中跟踪到。
开发人员把设计好的类实现为实现模型中的构件(源代 码)集合，能够产生(即编译和连接)如DLL、JavaBeans和 ActiveX等可执行代码，用例有助于开发人员确定实现和集 成构件的次序。
第8章 用例驱动
在测试工作流期间，测试人员验证系统确实能够实现用 例描述的功能并满足系统需求。测试模型包含测试用例，测 试用例是测试数据集，定义了输入、运行条件和结果的集合。 许多测试用例直接从用例得到。因此，在测试用例和相应的 用例之间存在跟踪依赖关系，这意味着测试人员将验证系统 能够做用户需要的事，即能够执行用例。