06_usecases.ppt-暨南大学计算机科学系.pptVIP

Fig. 6.6 Fig. 6.6 Fig. 6.7 * * * * * * * * * * * * * * * * * * * 第六章 用例 　　　　　　暨南大学计算机系 黄战 目标 确定和编写用例。 使用摘要、非正式和详述等用例形式的基本式样。 将测试应用于确定适当的用例上。 将用例分析与迭代开发联系起来。 overview 简介 用例： 用例是文本形式的情节描述，广泛应用于需求的发现和记录工作中。 用例会影响项目的众多方面，包括OOA/D，用例也将作为本书案例研究中许多后继制品的输入。 虽然UML用例图易于学习，但是要将确定和编写良好的用例的众多知道原则融会贯通，还需要数周甚至更长的时间。 示例 通俗地讲，用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。以下是摘要形式用例的示例： 处理销售：顾客携带所购商品到达收银台。收银员使用POS系统记录每件商品。系统连续显示累计总额，并逐行显示细目。顾客输入支付信息，系统对支付信息进行验证和记录。系统更新库存信息。顾客从系统得到购物小票，然后离开商品离开。 定义 参与者（actor）是某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织，例如收银员。 场景(scenario)是参与者和系统之间的一系列特定的活动和交互。也称为用例实例（use case instance）。场景是使用系统的一个特定情节或用例的一条执行路径。例如，使用现金成功购买商品的场景。 用例(use case)就是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。例如处理退货－－交替场景。 用例模型 UP在需求科目中定义了用例模型（Use-Case Model）。 这是所有书面用例的集合；这是系统功能性和环境的模型。 用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。 用例 用例模型在UP中不是唯一的需求制品。 其他制品还有补充性规格说明、词汇表、设想和业务规则。 用例模型还可以包含UML用例图，以显示用例和参与者的名称及其关系。UML用例图可以为系统及其环境提供良好的语境图。 用例不是面向对象的，编写用例时也不会进行OO分析。但这并不妨碍其有效性，用例可以被广泛应用。也就是说，用例是经典OOA/D的关键需求输入。 为什么使用用例 许多目标需要计算机来帮助实现，但其中最好的方法都是简单通俗的，对户客户而言更是如此。在软件项目中，缺少用户参与是项目失败的主要原因之一。 用例： 使工作保持简单的好方法。 使领域专家或需求提供者自己编写（或参与编写）用例成为可能。 强调了用户的目标和观点。 与查询系统特性清单相比更强调以客户为中心。 用例的优越性在于能够根据需要对复杂程度和形式化程度进行增减删节。 用例是功能需求吗？ 用例是： 需求，主要是说明系统如何工作的功能性或行为性需求。 FURPS+中的F。用例强调了”F”(功能性和行为性)。 在UP中，用例被推荐作为发现和定义需求的核心机制。 用例定义了系统行为的契约。 参与者的三种类型 参与者是任何具有行为的事物，在所讨论系统（System under Discussion,SuD）调用其他系统的服务时，还包括其自身。 参与者会出现在用例文本的活动步骤中。 参与者不仅是所扮演的角色，也可以是组织、软件和计算机。 相对于SuD,有三种外部参与者： 主要参与者：具有用户目标，并通过使用SuD的服务完成。通常用来发现驱动用例的用户目标。 协助参与者：为SuD提供服务（例如，信息服务）。自动付费授权服务即是一例。协助参与者通常是计算机系统，但也可以是组织或人。协助参与者通常是为了明确外部接口和协议。 幕后参与者：在用例行为中具有影响或利益，但不是主要或协助参与者。例如，政府收税机构。通常是为了确保确定并满足所有必要的重要事物。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。 用例的常用形式 用例能够以不同形式化程度或格式进行编写： 摘要－－简洁的一段式概要，通常用于主成功场景。前例中的处理销售就是摘要形式的用例。 何时使用？在早期需求分析过程中，为快速了解主体和范围。可能只需要几分钟进行编写。 非正式－－非正式的段落格式。用几个段落覆盖不同场景。前例中处理退货就是非正式形式的用例。 何时使用？同上。 详述－－详细编写所有步骤及各种变化，同事具有补充部分，如前置条件和成功保证。 何时使用？确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量的具有重要架构和高价值的用例。 示例 6.8节学习模板和示例。 模板小节 范围 范围界定了所要设计的系统：系统用例和业务用例。 级别 用例主要分为用户目标界别或子功能级别。用户目标级别（user-goa