06_useCases.ppt

1、第六章，用例，黄沾，暨南大学计算机系，目标，用例的确定和编译。使用基本风格的用例形式，如抽象的、非正式的和详细的。应用测试来确定合适的用例。将用例分析与迭代开发联系起来。概述、简介、用例：用例是文本形式的情节描述，广泛用于需求的发现和记录。用例将影响项目的许多方面，包括面向对象分析/开发，并且在本书的案例研究中，用例也将作为许多后续产品的输入。虽然UML用例图很容易学习，但是整合许多已知的原则来识别和编写好的用例需要几周甚至更长的时间。通俗地说，用例是以文本形式的情节描述，表明参与者使用系统来实现某些目标。下面是一个概要形式的用例示例：处理销售：客户将他们购买的商品带到收银台。收银员使用POS

2、系统记录每个项目。系统连续显示累计总额，并逐行显示明细。客户输入支付信息，系统验证并记录支付信息。系统更新库存信息。顾客从系统中获得购物收据，然后离开商品。定义，actor是有行为的东西，它可以是一个人(由一个角色来标识)、一个计算机系统或一个组织，如出纳员。场景是参与者和系统之间的一系列特定活动和交互。它也被称为用例实例。场景是使用系统的特定场景或用例的执行路径。例如，用现金成功购买商品。用例是一组相关的成功和失败场景，用来描述参与者如何使用系统来实现他们的目标。例如，处理返回交替场景。用例模型，UP在需求账户中定义一个用例模型。这是所有书面用例的集合；这是系统功能和环境的模型。用例是文本文

3、档，而不是图形；用例建模主要是写文本的活动，而不是绘图。用例和用例模型不是UP中唯一的需求产品。其他产品包括补充规范、词汇、想法和业务规则。用例模型还可以包含UML用例图来显示用例和参与者的名字以及它们之间的关系。UML用例图可以为系统及其环境提供一个好的上下文图。用例不是面向对象的，并且在编写用例时不会进行面向对象分析。然而，这并不妨碍它的有效性，用例可以被广泛使用。换句话说，用例是经典面向对象分析/开发的关键需求输入。为什么用例许多目标需要计算机的帮助，但是最好的方法是简单和流行的，特别是对于客户。在软件项目中，缺乏用户参与是项目失败的主要原因之一。用例：保持工作简单的好方法。领域专家或需

4、求提供者有可能自己编写(或参与)用例。强调用户的目标和观点。与查询系统功能列表相比，它强调以客户为中心。用例的优势在于能够根据需要增加、减少和缩短复杂性和形式化。用例是功能需求吗？用例是：需求，主要是解释系统如何工作的功能或行为需求。f在FURPS中。用例强调“f”(功能和行为)。在UP中，用例被推荐作为发现和定义需求的核心机制。用例为系统行为定义契约。参与者有三种类型。参与者是任何有行为的事物，包括它自己(当讨论中的系统调用其他系统的服务时)。参与者出现在用例文本的活动步骤中。参与者不仅是他们扮演的角色，也是组织、软件和计算机。与SuD相比，有三种外部参与者：主要参与者：那些拥有用户目标并通

5、过使用SuD的服务来实现它们的人。通常用于发现驱动用例的用户目标。协助参与者：为SuD提供服务(如信息服务)。自动支付授权服务就是一个例子。协助参与者通常是计算机系统，但他们也可以是组织或人。帮助参与者通常是澄清外部接口和协议。幕后参与者：对日常事务有影响或兴趣，但不是主要或辅助参与者的人。例如，政府税收机构。通常是为了确保所有必要和重要的事情都得到识别和满足。如果幕后的参与者没有明确的名字，有时很容易忽视他们的影响或好处。用例的一种常见形式，可以用不同的形式化程度或格式来编写：一段简明的总结，通常用在主要的成功场景中。在前面的例子中，处理销售是一个概要形式的用例。它什么时候使用？在早期需求分

6、析过程中，为了快速了解主题和范围。写起来可能只需要几分钟。非正式的非正式段落格式。用几个段落覆盖不同的场景。在前面的例子中，处理退货是一个非正式的用例。它什么时候使用？同上。详述所有步骤和细节写作的各种变化。同事有补充的部分，如先决条件和成功的保证。它什么时候使用？在识别了大量用例并以概要形式编写之后，在第一次需求讨论中详细编写了少量具有重要架构和高价值的用例。示例，学习第6.8节中的模板和示例。模板部分，范围定义了要设计的系统：系统用例和业务用例。级别用例主要分为用户目标部门或子功能级别。用户目标层，一个常用的层，描述了实现主要参与者目标的场景，这大致相当于业务流程工程中的基本业务流程(EB

7、P)。子功能级用例描述了支持用户目标所需的子步骤。当几个通用用例共享重复的子步骤时，它们被分离并创建为子功能级用例。主要参与者调用系统服务来实现目标的主要参与者。模板部分、涉众以及他们的关注列表建议并定义了系统必须做的工作。用例应该包含什么？先决条件和成功保证(后条件)先决条件给出的条件在用例场景开始之前必须始终为真。成功保证(或后条件)给出了用例成功结束后必须为真的东西。符号、两栏或对话的格式。例如，教科书的第79页。标准，以基本风格编写用例，将用户界面排除在思考之外；关注意图。特定风格的用例文本涵盖了用户界面的决定。在早期需求工作中应该避免。写简洁的用例，写黑盒用例，黑盒推荐的最常用类型；它不描述系统的内部工作和组件设计，而是通过职责描述系统。在参与者框中采用参与者目标的观点。指导方针：如何找到用例，选择系统边界，找到主要参与者，找到每个主要参与者的目标定义，满足用例参与者的用户目标，什么样的测试有助于找到有用的用例，老板测试你今天一整天都做了什么？