您的位置: 首页  >  文章  >  系统分析与设计——Use Cases

系统分析与设计——Use Cases

分类: 文章 • 2023-11-30 23:32:46

L05. Use Cases

Topics

What are Use Cases?

  • 用例是使用系统来满足用户目标的某些参与者的 text stories（而不是图表！）。
  • 它们用于发现和记录系统需求
  • 如果图表澄清了文字，请使用它。

Sample UP artifact influence (UP工件之间的相互影响)

  • 高级目标和用例图被输入到用例文本的创建中。
  • 这些用例反过来会影响许多其他分析，设计，实现，项目管理和测试工件。

系统分析与设计——Use Cases

Terminologies

  • Actor（参与者）——Actor的扮演者不仅是人，而且是组织，软件和机器。
  • Scenario（Use Case实例）——Actor与系统之间的特定动作顺序和交互作用。 （也称为用例实例）
  • Use case 是相关成功和失败场景的集合，这些场景描述了使用系统支持目标的参与者
  • [RUP Use Case]一组用例实例，其中每个实例是系统执行的一系列动作，这些动作可为特定参与者提供可观察的价值结果

What are Three Kinds of Actors?

  • 与正在讨论的系统（SuD）相关的外部参与者有三种：
  • Primary actor(主参与者)可以通过使用SuD的服务来实现用户目标。 （查找驱动用例的用户目标。）
  • Supporting actor (支撑参与者)为SuD提供服务。 自动付款授权服务就是一个例子。 （以阐明外部接口和协议。）
  • Offstage actor (幕后参与者)对用例的行为感兴趣，但不是主要的或支持的； 例如，*税务机构。 （以确保识别并满足所有必要的利益。）

Use-Case Model in UP

  • UP在需求规范中定义了用例模型。
  • 首先，这是所有书面用例的集合； 它是系统功能和环境的模型。
  • 用例模型不是UP中唯一的需求工件。
    • 也有补充规范，术语表，愿景和业务规则。
  • 用例模型可以选择包括UML用例图，以显示用例和参与者的名称及其关系。
  • 用例没有面向对象的

Why Use Cases?

  • 用例是一种很好的保持简单的方法，并且使领域专家或需求提供者自己编写（或参与编写）用例成为可能。
  • 他们强调用户的目标和观点
  • 基于其精炼的技巧和格式，又很强的伸缩性

Three Formats of Use Cases

  1. Brief(简约格式)——简短的段落摘要，通常是主要的成功场景。 在早期需求阶段创建。
  2. Casual(非正式格式)——非正式段落格式。 可以在多个段落中涵盖各种场景。
  3. Fully-dressed(详述格式)——详细编写所有步骤和变体。 有支持部分，成功保证，主要方案，替代方案等。

A Brief Use Case （简约格式例）

Process Sale（流程销售）：
客户到达结帐处并购买物品。 收银员使用POS系统记录每个购买的物品。 系统显示运行总计和行项目详细信息。 客户输入付款信息，系统将对其进行验证并记录。 系统更新库存。 顾客
从系统收到收据，然后带着物品离开…

A casual format use case with alternate scenarios （一个非正式格式的用例和替代方案）

Handle Returns （处理退货）：

  • Main Success Scenario: （主情景）
    客户到达结帐处并返回物品。 收银员使用POS系统记录每个退回的物品……
  • Alternate Scenarios：（备选情景）
    • 如果客户用信用付款，并且拒绝了对其信用帐户的补偿交易，请通知客户并用现金付款。
    • 如果在系统中找不到商品标识符，请通知收银员并建议手动输入标识符代码（可能它已损坏）。
    • 如果系统检测到无法与外部计费系统进行通信，…

Fully dressed Use Case （详述例）

Use Case 用例：购买产品（用用户的语言描述用户的目标）
Actors 参与者：客户，系统（为什么定义参与者是一个好主意？）

  1. 客户浏览目录并选择要购买的物品
  2. 客户去结帐
  3. 客户填写运输信息（地址；第二天或3天交货）
  4. 系统显示完整的定价信息，包括运费
  5. 客户填写信用卡信息
  6. 系统授权购买
  7. 系统立即确认销售
  8. 系统发送确认电子邮件给客户

（我们正确地理解了主要情况吗？）

备选方案1：授权失败（这会在什么步骤发生？）

6a. 在步骤6，系统无法授权信用购买
允许客户重新输入信用卡信息并重试

备选方案2：普通客户（这会发生在什么步骤？）

3a. 系统显示当前的运送信息,价格信息,信用卡信息的最后四位数
3b. 客户可以接受或覆盖这些默认设置
在步骤6返回主要方案

Template of Fully Dressed Use Cases 详述格式的模板

详述格式的用例显示更多细节并结构化； 他们深入挖掘。
系统分析与设计——Use Cases

Scope

  • 定义用例的范围。
  • 这可以适用于整个系统（如POS示例），也可以适用于整个系统（如用于在会计系统中创建日记帐分录的用例）。

Level

  • 用户目标级别：让用户（主要角色）完成任务的方案。 对应于基本业务流程（EBP）。
  • 子功能级别：支持用户目标所需的较小步骤。
    • 通常是为了排除几个常规用例共享的重复子步骤而创建的（以避免重复的通用文本）

Primary Actor

  • 用例的主参与者，调用系统服务以实现目标的人（或有时是对象）。 （Actors什么时候可能不是一个人？）

Stakeholders and Interests List（关联者及其关注点列表）

  • 它提示并限制了系统必须执行的操作
  • stakeholders(利益相关者)是有理由想要此系统的人。
  • Interests(利益)是他们想要它的理由以及他们对它的期望。
  • 您可以将系统视为各个利益相关者之间的contract（合同）。
  • 用例作为行为合同，仅捕获与满足利益相关者利益相关的所有行为。

Preconditions and Success Guarantee 前提条件和成功保证

  • 除非您说的是不明显和值得注意的内容，否则不需要它来帮助读者获得见识。
  • 前提条件说明了在开始场景之前必须始终为真的情况。 这通常定义了另一个用例的成功。
  • 成功保证（或后置条件）陈述了用例成功完成后必须满足的条件。

Main Success Scenario and Steps (or Basic Flow) 主要成功方案和步骤（或基本流程）

  • 它描述了满足利益相关者利益的典型成功路径。
    • 您得到了杂货，商店得到了钱，库存减少了，等等。
  • 它通常不包含任何条件或分支。
    • 可以说，它非常一致并且可以将所有条件处理推迟到“扩展”部分，因此更易于理解和扩展。
  • 三种可能的步骤
    • 参与者之间的交互
    • 系统的确认
    • 系统状态的改变

Extensions or Alternate Flows 扩展（备选流程）

  • 这些通常是文本的大部分。
  • 这些包括成功和失败的所有其他可能结果（场景或分支）。
  • 扩展方案是主要成功方案的分支，因此可以针对其步骤1…N进行标记。
  • 扩展有两个部分：条件和处理。

Performing Another Use Case 执行另一个用例

  • 用例可以分支到其他用例。
    • 例如，如果POS系统拒绝条形码，则收银员可以请求备用查询
  • 通过下划线表示这一点：
    • 收银员执行“查找产品帮助”以获取商品ID和价格

Special Requirements

  • 如果非功能性需求，质量属性或约束条件与用例特别相关，则将其记录在用例中。
  • 这些包括已被强制或认为可能的质量，例如性能，可靠性和可用性，以及设计约束（通常在I / O设备中）。
  • 用用例记录这些是经典的UP建议。 最终移动并合并补充规范中的所有非功能性要求。

Technology and Data Variations 技术和数据变化

  • 关于必须how（如何）做的技术变体，但不能做什么：
    • 扫描条码
    • 关键项ID
    • 射频识别
  • 值得注意的是将其记录在用例中。
  • 但是要避免早期的设计决策，保持通用性。
  • 还需要了解数据方案的变化，
    • 例如使用UPC或EAN作为商品标识符，以条形码符号系统进行编码

相关推荐