第二部分初始阶段第六章用例

简介

　　用例是以文本形式的情节描述，广泛应用于需求的发现和记录工作中。用例会影响项目的众多方面(包括OOA/D)。

示例：通俗地将，用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。以下是摘要形式用例的示例：

　　处理销售：顾客携带所购买商品到达收银台，收营员使用POS系统记录每件商品。系统连续显示累计总额，并逐行显示细目。顾客输入支付信息，系统对支付信息进行校验和记录。系统更新库存信息。顾客从系统得到购物小票，然后携带商品离开。

定义：参与者，场景和用例

　　参与者(actor)是某些具有行为的事物，可以是人(由角色标识)，计算机系统或组织，例如收银员。

　　场景是参与者和系统之间的一系列特定的活动和交互，也称为用例实例(use case instance).场景是使用系统的一个特定情节或用例的一条执行路径。例如，使用现金成功购买商品的场景，或者由于信用卡付款被拒绝造成的购买失败场景。

通俗地讲，用例(use case)就是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。

用例和用例模型

　 UP在需求科目中定义了用例模型(Use-Case Model)。首先，这是所有书面用例的集合；同时，它是系统功能性和环境的模型

　　用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。用例模型还可以包含UML用例图，以显示用例和参与者的名称及其关系。UML用例图可以为系统及其环境提供良好的语境图(context diagram),也为按名称列出用例提供了快捷方式。

　　用例不是面向对象，编写用例也不会进行OO分析。但这并不妨碍其有效性，用例可以被广泛应用。也就是说，用例是经典OOA/D的关键需求输入。

　　用例是真正的需求(尽管不是所有的需求)。有些人认为需求只是"系统应该完成......"这样的功能或特性列表。实际并非如此，用例的主要思想(通常是)：为功能性需求编写用例，从而降低详细的老式特性列表的重要性或减少这种列表的使用。

定义：参与者的三种类型

　　参与者(actor)是任何具有行为的事物，在所讨论系统(System under Discussion,SuD)调用其他系统的服务时，还包括其自身。主要参与者和协助者会出现在用例文本的活动步骤中。

相对于SuD,有三种外部参与者：
　　主要参与者(primary actor):具有用户目标，并通过使用SuD的服务完成。例如，收银员。为何确定主要参与者？发现驱动用例的用户目标。

　　协助参与者(support actor):为SuD提供服务(例如，信息服务)。自动付费授权服务即是一例。协助参与者通常是计算机系统，但也可以是组织或人。为何确定协助参与者？为了明确外部接口和协议。

　　幕后参与者：在用例行为中具有影响和利益，但不是或协助参与者。例如，政府税收机构。

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。