标签：

简介

　　用例是以文本形式的情节描述，广泛应用于需求的发现和记录工作中。用例会影响项目的众多方面(包括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提供服务(例如，信息服务)。自动付费授权服务即是一例。协助参与者通常是计算机系统，但也可以是组织或人。为何确定协助参与者？为了明确外部接口和协议。

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

标签：
来源： https://www.cnblogs.com/shadow-shine/p/9720528.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。