李妮娅《统一软件开发过程》第六章用例驱动的过程.pdfVIP

第6章用例驱动的过程 目录  6.1 定义  6.2 识别用例  6.3 用例的进化  6.4 用例的组织  6.5 在过程中使用用例  6.6 小结 概述  选择什么样的模型和选择什么样的技术来表述模 型, 对于我们考虑问题和解决问题有着重大的影响.  问题模型与解决方案的模型要保持一致性.  本章将介绍用例、参与者、情景等概念，同时还 将介绍如何在生命周期中将用例作为许多活动的 驱动来使用，并在模型之间传递信息和保持模型 的一致性。 6.1 定义  6.1.1 用例和参与者  6.1.2 事件流  6.1.3 情景  6.1.4 用例模型 6.1.1 用例和参与者  用例(use case)是一个系统执行的动作序列，对 特定参与者产生有价值的可见结果。  参与者(actor)是系统之外与系统能产生交互作用 的人或物  动作(action)是一个计算程序或算法程序，在参与 者给出系统信号或系统得到一个时间事件时被调 用。动作是原子的，一个动作要么全部执行，要 么根本不执行。  动作序列(a sequence of actions)是指贯穿于系 统的特定事件流。  有价值的可见结果(an observable result of value):动作序列一定要产生对系统的参与者有价 值的可观测到的结果。  用例的定义描述了执行用例时系统要做些什么。 一组用例就可以定义系统的功能，每一个用例代 表了一个特定事件流。  用例的作用是从用户角度获取系统的功能，在客 户和系统开发人员之间进行交流时充当了共同的 语言。 用例和参与者的示例  银行客户可以通过自动取款机(ATM)提款、转帐 或检查帐户上的余额。 6.1.2 事件流  事件流(flow of events)描述了参与者和系统之间 的动作序列。  事件流用自然用语写成，或者用含有精确术语的 短语写成。  一个关于事件流的示例： 《提款》见下一页 1. 用例开始于客户将卡插入ATM机。系统读取并验证卡上 的信息。 2. 系统提示输入个人标识号(PIN)。客户输入PIN。系统进 行验证。 3. 系统询问客户需要哪种操作。客户选择“提款”。 4. 系统询问提款数量。客户输入要提取的金额数。 5. 系统询问账户种类。客户选择账户种类。 6. 系统与ATM 网络交换信息，以验证账户ID、PIN以及剩余 金额。 7. 系统提问客户是否要收据。这一步只有在可以用纸打印 收据时才执行。 8. 系统提示用户取走卡。用户将卡取走。 9. 系统给出客户申请的现金。 10.假如客户需要，系统打出收据，用例结束。  用例事件流最终要描述所有可能的过程， 要考虑所有可相互替换的路线和不同的情 景。  选择什么样的路径依赖于以下几点： 参与者的输入(input from an actor) 系统内部状况(the internal state of the system) 超时或出错(time-outs and errors) 6.1.3 情景  情景(scenario)可以理解为是用例的实例  用例的实例是一个特定的事件流或一个特定的路 径。  情景的作用  在过程中使用情景的目的是提取并强调一个独特的贯 穿于用例的动作序列或“线程”。在定义测试用例时 尤其有用。  在项目早期寻找用例时，最容易的方法是从一个特定 的情景开始，而后将它扩展到更多的事件流，最后总 结为成熟的用例。 6.1.4 用例模型  用例模型由整个系统或系统某一部分的所有用例 及与这些用例交互的参与者组成，以此来描述整 个系统的功能。  用例模型提供了系统预期功能模型和外部环境模 型，可以将用例模型作为开发人员和客户之间的 契约。  Rational统一过程中使用用例图和活动图将用例 模型可视化，包括用例之间可能的关系。 用例建模阶段是否考虑并发性等非功 能需求  在用例建模阶段，假设所有情景都可以同 时运行而不会产生任何问题。在设计阶段 时，要确保能正确处理所有非功能性需求。 6.2 识别用例  思考方式1：研