L06. Writing Use Cases
Topics
- Guidelines to Writing Use Cases
- How to Find Use Cases
- Applying UML: Use Case Diagrams
- Evolve Use Cases Across the Iterations(within UP)
Guidelines to Writing Use Cases
Essential Style Use Cases 基本样式用例
- 大多数程序取决于特定的用户界面。
- 但是，请避免过早限制程序：
- “用户在对话框中输入ID和密码，然后按OK（确定）按钮。”
- “用户向系统标识自己。”
- 后者允许生物识别ID，键入等。
-
基本样式用例
- 专注于本质或基本思想，而不是执行的细节
Write in a Essential (UI-Free) Style 以基本（无UI）样式编写
- 基本风格:
- 用基本样式编写用例
- 保持用户界面外，并专注于参与者的意图。
- 基本风格与具体风格形成鲜明对比。
- 在早期需求工作期间避免使用具体样式。
- 具体样式：用户界面决策嵌入在用例文本中。
- 编写简洁的用例。 删除“noise”字样。
Write Black-Box Use Cases 写黑匣子用例
- 黑匣子用例无法描述系统，其组件或设计的内部工作原理。
- 相反，该系统被描述为具有责任
- 黑匣子，什么
- “系统记录销售情况”
- 不是黑匣子，怎么
- “系统将销售记录写入数据库”
Take an Actor and Actor-Goal Perspective
- 什么是用例？ （RUP）
“一组用例实例，其中每个实例是系统执行的一系列动作，可为特定参与者提供可观察的价值结果。” - 关注用户，询问他们的目标
- 了解参与者认为有价值的结果
How to Find Use Cases
Finding Use Cases
- 定义用例以满足主要参与者的目标。 因此，基本过程是：
- 选择系统边界
- 确定主要参与者
- 确定每个主要参与者的目标
- 定义满足这些目标的用例
- 当然，在迭代和进化开发中，并非所有目标或用例都会在一开始就被完全或正确地识别出来。 这是一个不断发展的发现。
Step 1: Choose the System Boundary
- 如果设计中的系统边界的定义不清楚，
- 可以通过进一步定义外部因素（外部主要参与者和支持者）来阐明这一点。
- 一旦确定了外部参与者，界限就会变得更加清晰。
- 例如：
- 是否在系统范围内完全负责付款授权？
- 不，有一个外部付款授权服务人员。
Steps 2 and 3: Find Primary Actors and Goals
- 在用户目标之前严格线性化主要参与者的识别是人为的；
- 在需求研讨会上，人们集思广益并产生了两者的混合体。
- 有时，目标揭示了参与者，反之亦然。
- 指南：首先集思广益主要参与者，因为这将建立进一步调查的框架。
Questions to Help Find Actors and Goals
除了明显的主要角色和目标之外，以下问题还有助于确定其他可能遗漏的问题：
- 谁启动和停止系统？
- 用户和安全管理由谁负责？
- 谁进行系统管理？
- “时间”是否是参与者，因为系统会响应时间事件来执行某些操作？
- 如何处理软件更新？
- 谁收到问题通知？
How to Organize the Actors and Goals?
至少有两种方法：
- 发现结果时，将其绘制在用例图中，将目标命名为用例。
- 首先编写一个actor-goal列表，查看并完善它，然后绘制用例图
Actor-Goal List
UP Vision工件中的一部分。
Why Ask About Actor Goals Rather Than Use Cases?
- 参与者有目标，并使用应用程序来帮助实现目标。
- 用例建模的观点是找到这些参与者及其目标，并创建产生价值结果的解决方案。
- 对于用例建模者来说，重点的转移很小。
- 想象一下我们在一起参加了需求研讨会。 我们可以问：
- “你是做什么？” （大约是一个面向任务的问题），或者
- “您的目标具有可衡量的价值的目标是什么？”
- 优先考虑第二个问题。
Who is the Primary Actor?
- 在用例流程销售中，为什么收银员而不是客户是主要角色？
- 取决于系统边界
Other Ways to Find Actors and Goals?
事件分析
- 另一种方法是识别外部事件
- 它们是什么，从何而来，为什么？
通常，一组事件属于同一用例。 例如：
用时间分析找出更多的actors and goals.
Step 4:Define Use Cases
- 通常，为每个用户目标定义一个用例。
- 将用例命名为类似于用户目标的用例。 用动词开头用例的名称。
例如，目标：处理销售； 用例：流程销售。 - 每个目标一个用例的一个常见例外是将CRUD单独的目标（创建，检索，更新，删除）折叠成一个CRUD用例，习惯上称为Manage 。
- 例如，“管理用户”用例可以满足目标“编辑用户”，“删除用户”等等。
What Tests Can Help Find Useful Use Cases?
- 哪个是有效的用例？
- 谈判供应商合同
- 处理退货
- 登录
- 在游戏板上移动棋子
- 可以说所有这些都是不同级别的用例，具体取决于系统边界，参与者和目标。
The Boss test 老板测试
- 老板问：“你整天在做什么？”
您回复：“登录！” 你的老板高兴吗？ - 如果不是，则该用例无法通过Boss测试，这意味着它与获得可衡量的价值没有密切关系。
- 它可能是某个较低目标级别的用例，但不是需求分析所需的关注重点。
- 这并不意味着总是忽略失败的老板测试用例。
用户身份验证可能无法通过老板测试，但是可能很重要且很困难。
Other Tests
-
基本业务流程测试：
任务执行者:- 一个人
- 在一个地方
- 在一个时间
- 响应业务事件
这样可以增加价值，并使数据保持一致状态。
-
专注于反映EBP的用例。
-
尺寸测试：
- Fully dressed is 3-10 pages.
Applying the Tests
- 谈判供应商合同
- 比EBP更广泛，更长。 可以建模为业务用例，而不是系统用例。
- 处理退货
- 登录
- 在游戏板上移动棋子
合理违反测试
- 尽管大多数用例都应满足测试要求，但例外情况很常见。
- 有时，编写代表常规EBP级用例中的子任务或步骤的单独子功能级用例很有用。
- 某些子功能可能无法通过老板测试，但非常复杂且有用。
Applying UML
Applying UML: Use Cases Diagrams
- 用例图和用例关系在用例工作中是次要的。
- 用例是文本文档。 用例工作意味着编写文本。
- 不要用图表代替思维。
Use Cases Diagrams as Context Diagram 用例图作为上下文图
- 用例图很好地描绘了系统上下文。
- 它制作了一个很好的上下文图，显示了
- 系统的边界
- 外面有什么
- 以及如何使用
- 它用作总结的交流工具
- 系统及其参与者的行为。
A simple diagram can add clarity 简单的图表可以增加清晰度
UML提供了用例图符号来说明用例和参与者的名称，以及它们之间的关系。
注释建议
指南：简化图表，使其简洁明了
Applying UML: Activity Diagrams 应用UML：活动图
- 活动图：可视化工作流程和业务流程。
- 用例涉及流程和工作流分析，
- 活动图可以代替写用例文本，
- 特别是对于描述涉及许多方和并发操作的复杂工作流的业务用例。
Requirements in Context 在环境中描述需求
- 用例可以在系统的典型使用范围内组织一组需求
- 用例替换低级功能列表
- 但是，用例并不是唯一必要的需求工件。
- UP补充规范中更好地记录了非功能性要求，报告布局，域规则和其他难以放置的元素
- 高级功能列表（系统功能，添加到Vision文档中）可以有效地总结系统功能。
- 一些应用程序需要功能驱动的观点
- 不要为此创建用例
- 用例不太适合
Evolve Use Cases Across the Iterations 跨迭代演进用例
Use Cases Driven Development 用例驱动的开发
用例对于UP迭代方法至关重要。 UP鼓励用例驱动开发。 这意味着：
- 功能需求在用例中（用例模型）
- 用例是迭代计划的重要组成部分。
- 迭代的工作部分是通过选择一些用例场景或整个用例来定义的。
- 用例是估计的关键输入。
- 用例实现驱动设计
- 团队设计协作对象和子系统，以实现用例。
- 用例影响用户手册的组织
- 测试与用例场景相对应
- 可以为大多数常见场景创建UI快捷方式