用例
- 一件软件的使用情况；经常在复数中用于建议软件可能有用的情况。
- 系统接收外部请求（例如用户输入）并响应它的潜在场景。
本文讨论了后一种意义。 （有关另一种意义的更多信息，请参见例如用户角色）。
用例是操作或事件步骤的列表，通常定义角色（在统一建模语言中已知（UML）作为演员）和实现目标的系统。演员可以是人类或其他外部系统。在系统工程中，使用案例的级别比软件工程中的级别更高，通常代表任务或利益相关者的目标。然后可以在系统建模语言（SYSML）或作为合同语句中捕获详细要求。
历史
1987年，伊瓦尔·雅各布森（Ivar Jacobson）在OOPSLA '87会议上介绍了有关用例的第一篇文章。他描述了如何使用文本，结构和视觉建模技术来驱动面向对象的分析和设计的文本，结构和视觉建模技术如何使用该技术来捕获和指定系统的要求。最初，他使用了用法方案和用法案例- 后者是他瑞典语användningsfall的直接翻译 - 但发现这些术语在英语中都没有自然，最终他就定居在用例中。
1992年，他合著了本书，面向对象的软件工程 - 用例驱动方法，奠定了OOSE系统工程方法的基础，并有助于普及用例捕获功能要求，尤其是在软件开发中。 1994年，他出版了一本书，讲述了应用于业务模型和业务流程重新设计的用例和面向对象的技术。
同时， Grady Booch和James Rumbaugh分别统一了面向对象的分析和设计方法， Booch方法和对象建模技术（OMT） 。 1995年，伊瓦尔·雅各布森（Ivar Jacobson）加入了他们，共同创建了统一的建模语言（UML） ，其中包括用例建模。 UML于1997年由对像管理小组（OMG）标准化。Jacobson，Booch和Rumbaugh还致力于对Objions软件开发过程的完善。由此产生的统一过程于1999年发布，并促进了用例驱动方法。
从那时起，许多作者为技术的发展做出了贡献，尤其是：拉里·康斯坦丁（Larry Constantine）于1995年在以使用方式的设计为背景下开发，所谓的“必需用例”，旨在描述用户意图而不是动作序列或可能限制或偏向用户界面设计的方案； Alistair Cockburn于2000年出版了基于文本叙述和表格规格的面向目标用例实践。 Kurt Bittner和Ian Spence于2002年开发了用于分析用例的功能要求的高级实践； Dean Leffingwell和Don Widrig提议将用例应用于改变管理和利益相关者的沟通活动； Gunnar Overgaard在2004年提议将设计模式的原理扩展到用例。
2011年，雅各布森（Jacobson）与伊恩·斯潘塞（Ian Spence）和库尔特·伯特纳（Kurt Bittner）一起出版了电子书用例2.0 ，以使技术适应敏捷的环境，并用逐步的用例“切片”丰富了技术，并在展示了重新恢复的方法之后，在整个开发生命周期内促进其用途在年度IIBA会议上。
一般原则
用例是用于捕获，建模和指定系统要求的技术。用例对应于系统可能与其参与者互动的一组行为，并产生可观察到的结果，从而有助于其目标。演员代表了人类用户或其他系统在交互中的作用。
在需求分析中，在其标识下，根据其主要演员代表的特定用户目标命名用例。通过文本描述或其他图形模型进一步详细介绍了该案例，这些模型可以解释活动和事件的一般顺序以及特殊条件，异常或错误情况等变体。
根据软件工程知识体（SWEBOK） ，用例属于基于方案的需求启发技术以及基于模型的分析技术。但是用例还支持基于叙事的需求收集，增量要求获取，系统文档和接受测试。
变化
该技术中有不同种类的用例和变化：
- 系统用例指定要开发的系统的要求。他们在详细的描述中不仅确定了与演员的互动，还标识了参与处理的实体。它们是进一步分析模型和设计活动的起点。
- 业务用例专注于业务组织而不是软件系统。它们用于在业务流程重新设计计划的背景下指定业务模型和业务流程要求。
- 基本用例，也称为抽像用例，描述了参与者的潜在意图以及系统如何解决这些情况，而无需定义任何顺序或描述场景。开发这种做法是为了支持以用户为中心的设计，并避免在系统规范的早期阶段引起对用户界面的偏见。
- 用例2.0适应敏捷开发方法的上下文。这种技术丰富了需求收集的实践，并支持用户故事叙事。它还提供了用例“切片”，以促进需求的增量启发并实现增量实现。
范围
用例的范围可以由一个主题和目标定义：
- 主题标识将提供交互的系统，子系统或组件。
- 可以考虑到对目标感兴趣的组织级别（例如公司，部门，用户）以及用户目标分解为子目标的组织级别，可以从层次结构结构。目标的分解是从用户的角度进行的，并且独立于系统，这与传统功能分解不同。
用法
已知用例在以下情况下应用：
- 面向对象的软件工程（OOSE） ，作为驱动元素；
- 统一建模语言（UML）作为行为建模工具；
- 统一的软件开发过程（UP）及其前进者IBM Rational Unified Process（RUP） ；
- 软件需求规范（SRS）的前期文档，作为功能要求的替代结构；
- 使用实体控制方法从要求中得出设计；
- 和敏捷的发展。
模板
从文本中，有很多方法可以通过用例简短，休闲，轮廓到完全穿着等，以及各种模板。在由各个供应商或专家设计的模板中编写用例是获得高质量功能系统要求的常见行业实践。
Cockburn风格
Alistair Cockburn在他的书撰写有效用例中定义的模板一直是使用最广泛的用例使用案例之一。
设计范围
Cockburn建议用符号注释每个用例以显示“设计范围”，该示波器可能是黑框（内部细节是隐藏的）或白色盒子（显示了内部细节）。有五个符号可用：
| 范围 | 图示 | |
|---|---|---|
| 组织（Black-Box） | 填满的房子 |  |
| 组织（白色框） | 毫无用处的房子 |  |
| 系统（黑色框） | 装满的盒子 |  |
| 系统（白色框） | 未装满的盒子 |  |
| 成分 | 螺钉或螺栓 |  |
其他作者有时会在组织级别调用用例“业务用例”。
目标水平
Cockburn建议用符号注释每个用例以显示“目标水平”；首选的级别是“用户目标”（或通俗的“海平面”）。
| 目标水平 | 图示 | 象征 | |
|---|---|---|---|
| 总结很高 | 云 | ++ |  |
| 概括 | 飞行风筝 | + |  |
| 用户目标 | 海上波浪 | ! |  |
| 子功能 | 鱼 | - |  |
| 太低 | 海床蛤壳 | -- |  |
有时，在文本写作中，用例名称加一个替代文本符号（！ +， - 等）是一种更简洁，更方便的方式来表示级别，例如下订单！ ,登入- .
穿好衣服
Cockburn描述了用例的更详细的结构，但在需要较少详细信息时可以简化它。他穿着穿着的用例模板列出了以下字段：
- 标题：“一个主动动力的目标短语，命名了主要演员的目标”
- 主要演员
- 上下文中的目标
- 范围
- 等级
- 利益相关者和利益
- 前提
- 最少的保证
- 成功保证
- 扳机
- 主要成功情况
- 扩展
- 技术和数据变化列表
此外，Cockburn建议使用两种设备指示每种用例的性质：用于设计范围和目标水平的图标。
科克本的方法影响了其他作者。例如，亚历山大（Alexander）和Beus-dukic将Cockburn的“穿好衣服的用例”模板从软件到各种系统的系统概括，以下字段与Cockburn不同：
- 变化方案“（也许从并可能返回主要场景）”
- 例外“ IE异常事件及其异常处理场景”
随意的
Cockburn认识到项目可能并不总是需要详细的“完全穿着”的用例。他描述了一个随意的用例：
- 标题（目标）
- 主要演员
- 范围
- 等级
- （故事）：用例的主体只是一段或两段文本，非正式地描述了会发生什么。
福勒风格
马丁·福勒（Martin Fowler）指出：“没有标准的方法来编写用例的内容，并且不同的格式在不同的情况下效果很好。”他描述了“使用的常见风格”，如下所示：
- 标题：“目标案例正在尝试满足”
- 主要成功方案：编号的步骤列表
- 步骤：“对演员与系统之间的相互作用的简单陈述”
- 扩展名：单独编号的列表，每个扩展名
- 扩展：“从..主要成功方案导致不同交互的条件”。主步骤3的扩展名为3A，等等。
Fowler样式也可以看作是Cockburn模板的简化变体。该变体称为用户故事。
阿利斯泰尔·科克本（Alistair Cockburn）说：
将用户故事视为用用例，在2位精确度。精度名称的位1个用例的目标，位2添加了主要情况。位3添加了故障条件，位4添加了故障操作。位5添加了IN/OUT数据的数据描述。我将催化放在第六位的精度上，因为它们还包括消息的收件人的模型。在Crystalmethodology家族中，以不同级别的精度为基础的项目用例不同。一种方法上的轻度项目使用用户故事，一个方法上的重重项目使用用例使用了4位精确度，而催化使用了6位精确度。
马丁·福勒（Martin Fowler）说：
这全都与人们的使用情况有关。我见过许多人以非常形式化的方式用例。肯特以更平易近人的方式来做他的股票。我确实会像肯特的用户故事一样用例。我打电话给他们使用案例，以更好地与其他开发人员进行沟通，并影响他们使用更轻巧的方法。
演员
用例定义了外部参与者与正在考虑的系统之间的相互作用以实现目标。演员必须能够做出决定，但不必是人类：“演员可能是一个人，公司或组织，计算机程序或计算机系统（智能软件，软件或两者兼而有之）。”演员始终是利益相关者，但并非所有利益相关者都是演员，因为他们可能“永远不要与系统直接互动，即使他们有权关心系统的行为方式”。例如，“系统的所有者，公司的董事会和监管机构（例如国税局和保险部）都是利益相关者，但不太可能是参与者。
同样，使用系统的人可能会因为扮演不同的角色而被代表为另一个演员。例如，用户“乔”在使用自动柜员机从自己的帐户中撤回现金或扮演银行出租人的角色时，可能会扮演客户的角色。
演员经常代表别人工作。 Cockburn写道：“如今，我为客户撰写'销售代表'或为营销部门撰写“店员”，以捕捉系统的用户为其他人行事。”这告诉项目，“用户界面和安全许可”应为销售代表和店员设计，但客户和营销部门是对结果的关注的角色。
利益相关者可能会扮演主动和不活动角色：例如，消费者既是“大众市场购买者”（不与系统互动），又是用户（演员，与购买的产品积极互动）。反过来，用户既是“普通运算符”（用于其预期目的使用系统的演员），又是“功能受益人”（从使用系统使用中受益的利益相关者）。例如，当用户“ Joe”从他的帐户中提取现金时，他正在操作自动柜员机并代表他自己获得结果。
Cockburn建议在系统的利益相关者中寻找演员，用例的主要和支持的（次要）参与者，设计的系统本身（SUD）本身，最后是“内部参与者”，即系统组件下的组件设计。
业务用例
用用例描述用户（或其他类型的演员）和系统之间的一系列事件和交互的方式，为了产生价值（目标）的结果，业务用例描述了更一般的交互在业务系统和该系统的用户/参与者之间，以产生价值的业务结果。主要区别在于，除了技术系统外，业务用例模型中考虑的系统可能还包含人员。这些“系统中的人”被称为商业工人。在餐厅的示例中，必须做出决定是否将每个人视为演员（因此在系统之外）或商业工作者（在系统内部）。如下所示，如果服务员被认为是演员，那么餐厅系统不包括服务员，并且该模型会揭露服务员和餐厅之间的互动。另一种选择是将服务员视为餐厅系统的一部分（商业工作者），同时考虑客户在系统之外（演员）。
视觉建模
用例不仅是文本，而且是图表。在统一的建模语言中，用例和参与者之间的关系在最初基于Ivar Jacobson的对象符号的用例图中表示。 SYSML在系统块级别使用相同的符号。
此外，其他行为UML图，例如活动图，序列图，通信图和状态机器图，也可以用于相应地可视化用例。具体而言，系统序列图（SSD）是一个序列图，通常用于显示外部参与者与设计下的系统之间的相互作用（SUD），通常用于可视化用例的特定方案。
用例分析通常从绘制用例图表开始。对于敏捷开发，许多UML图的需求模型描绘了用例，以及一些文本说明，注释或用例简介将非常轻巧，并且足以容纳小型或简易的项目使用。作为对用例文本的良好补充，用例的视觉图表表示也是有效的促进工具，以更好地理解复杂的系统行为要求。
例子
以下是示例用例编写，并带有略微修改的Cockburn式模板。请注意，在基本用例描述中没有按钮，控件，表单或任何其他UI元素和操作，其中仅在基本流或扩展的每个步骤中都表示用户目标，子目标或意图。这种做法使需求规范更清晰，并最大程度地提高了设计和实施的灵活性。
用例：编辑文章
主要演员：会员（注册用户）
范围： Wiki系统
等级： ！ （用户目标或海平面）
简介：（等效于用户故事或史诗）
- 成员编辑他们正在阅读的文章的任何部分（整个文章或部分）。在编辑过程中允许预览和更改比较。
利益相关者
...
后条件
- 最少的保证：
- 成功保证：
- 该文章已保存并显示了更新的视图。
- 该文章的编辑记录是由系统创建的，因此文章的观察者稍后可以告知该更新。
前提：
- 启用编辑的文章将提交给会员。
触发器：
- 成员在本文中调用编辑请求（全文或仅一部分）。
基本流程：
- 该系统提供了一个新的编辑区域/盒子，其中包含所有文章的相关内容，并提供信息的编辑摘要，以供成员编辑。如果成员只想编辑报告的一部分，则仅显示本节的原始内容，并且在编辑摘要中自动填写了部分标题。
- 成员修改文章的内容，直到满足会员为止。
- 会员填写编辑摘要，告诉系统是否要观看本文，并提交编辑。
- 系统保存文章，记录编辑事件，并完成任何必要的后处理。
- 该系统向会员提供了文章的更新视图。
扩展：
2–3.
- A。 Show Preview：
- 成员选择提交修改后内容的Show Preview 。
- 系统重新运行步骤1，添加了渲染的更新内容以进行预览，并告知会员他/她的编辑尚未保存，然后继续进行。
- b。显示更改：
- 成员选择的显示更改，该更改提交了修改后的内容。
- 该系统重新运行步骤1，并增加了比较成员当前编辑之间的差异的结果，而本文的最新保存版本则继续进行。
- C。取消编辑：
- 成员选择取消。
- 该系统会丢弃成员所做的任何更改，然后转到步骤5。
4a。暂停：
...
优点
自敏捷运动的成立以来， Extreme编程的用户故事技术一直很受欢迎，以至于许多人认为它是所有项目敏捷要求的唯一和最佳解决方案。 Alistair Cockburn列出了他仍然在敏捷开发中写用例的五个原因。
- 目标名称列表提供了系统将提供的内容的最短摘要（即使在当时的用户故事）。它还提供了一个项目规划骨架，用于建立初始优先级，估计，团队分配和时机。
- 每种用例的主要成功情况为所有与系统基本上要做什么以及它不做什么的协议相关的人。它为每个特定的订单项需求（例如细粒度的用户故事）提供了上下文，这种上下文很难获得其他任何地方。
- 每种用例的扩展条件提供了一个框架，用于调查所有小小的努力，这些东西以某种方式占用了开发时间和预算的80％。它提供了一种外观的机制，因此利益相关者可能会发现可能需要很长时间才能获得答案的问题。这些问题可以并且应该提前安排时间表，以便在开发团队开始努力时可以准备好答案。
- 用例扩展方案片段为许多详细的，通常很棘手且忽略的商业问题提供了答案：“在这种情况下，我们该怎么办？”这是一个与if ...然后...的思维/文档框架相匹配，然后...其他帮助程序员通过问题进行思考的语句。除了在调查时完成，而不是编程时间。
- 完整的用例集表明，调查人员已经考虑了每个用户的需求，对系统的每个目标以及所涉及的每个业务变体。
总而言之，与传统或其他方法相比，用例指定系统要求具有这些明显的好处：
用户专注
用例构成了用于软件需求规范过程的功能强大的，以用户为中心的工具。用例建模通常是从确定与系统相互作用的关键利益相关者角色（参与者）以及系统必须实现的目标或目标（外部视角）开始的。然后，这些用户目标成为代表系统提供的所需功能功能或服务的用例名称或标题的理想候选者。这种以用户为中心的方法可确保具有实际业务价值和用户真正想要的东西，而不是从开发人员或系统（内部）角度推测的那些琐碎的功能。
多年来，用例创作一直是以用户设计（UCD）领域的重要而有价值的分析工具。
更好的沟通
用例通常用带有结构化模板的天然语言编写。这种叙述性的文本形式（清晰的需求故事），几乎每个人都可以理解，并在所有利益相关者（包括客户，最终用户，开发人员，测试人员和经理）中提供了更好和更深入的沟通。更好的通信导致质量要求，从而交付了质量系统。
结构化探索的质量要求
关于用例的最有力的事情之一位于用例模板的格式，尤其是主要的成功方案（基本流程）和扩展方案片段（扩展，非凡和替代流动）。分析从前提到后条件到后条件，探索和调查用例流的每个动作步骤（从基本到扩展）的每个动作步骤，以识别那些棘手的，通常隐藏和忽略，看似琐碎但实际上昂贵的要求（正如Cockburn提到的那样）上面）是一种系统的结构化和有益的方法，可以系统地获得清晰，稳定和质量要求。
最小化和优化用例以实现用户目标的操作步骤，还有助于更好的交互设计和系统的用户体验。
促进测试和用户文档
借助基于动作或事件流结构的内容，编写良好的用例模型也可以作为设计案例和系统或产品的用户手册的出色基础和有价值的指南，这是一项努力的投资-正面。用例及其测试用例的流动路径之间存在明显的连接。通过其场景（用例的运行实例）从用例中得出功能性测试用例很简单。
限制
用例的局限性包括：
- 用例不适合捕获系统的非相互作用要求（例如算法或数学要求）或非功能性要求（例如平台，绩效，时机或关键性的问题）。这些是在其他地方宣告的更好指定的。
- 由于没有完全标准的用例定义，因此每个项目都必须形成自己的解释。
- 某些用例关系（例如扩展）在解释方面是模棱两可的，利益相关者可能很难理解，正如科克本指出的那样（问题＃6）
- 用例开发人员经常发现很难确定用户界面（UI）依赖性的水平以在用例中纳入。虽然用例理论表明在用例中不反映UI，但要抽象设计的这一方面可能会很尴尬，因为它使用例难以可视化。在软件工程中，通过应用需求可追溯性（例如使用可追溯性矩阵）来解决这个困难。将UI元素与用例相关联的另一种方法是将UI设计附加到用例中的每个步骤。这称为用例情节板。
- 用例可以过分强调。贝特兰·迈耶（Bertrand Meyer）讨论了诸如从字面上的用例中驾驶系统设计的问题，并使用用例排除其他潜在有价值的需求分析技术。
- 用例是测试设计的起点，但是由于每个测试都需要自己的成功标准，因此可能需要修改用例以为每条路径提供单独的后条件。
- 尽管用例包括目标和环境，但这些目标背后的目标和动机（利益相关者的关注及其评估包括非交互）冲突还是对其他系统目标进行负面影响，是面向目标的需求建模技术（例如BMM）的主题。 ， I* ， Kaos和Archimate Armor）。
误解
关于用例的常见误解是：
用户故事很敏捷；用例不是。
敏捷和混乱对需求技术是中性的。作为Scrum底漆，
产品积压项目以任何清晰可持续的方式阐明。与流行的误解相反，产品积压不包含“用户故事”。它只是包含项目。这些项目可以表示为用户故事，用例或任何其他要求的方法。但是，无论方法是什么，大多数项目都应该专注于为客户提供价值。
用例进化，用用例切片逐渐富含用例，以考虑敏捷方法。
用例主要是图表。
克雷格·拉曼（Craig Larman）强调，“用例不是图表，它们是文本”。
用例具有太多与UI相关的内容。
正如某些人所说，
用例通常包含一定程度的细节（即标签和按钮的命名），这使其不太适合从头开始捕获新系统的要求。
新手误会。写得很好的用例的每个步骤都应呈现演员的目标或意图（功能要求的本质），通常不应包含任何用户界面详细信息，例如命名标签和按钮，UI操作等，这是一个不好的实践，将不必要地使用例写作复杂化并限制其实施。
至于从头开始捕获新系统的要求，用例图和用例简介通常用作方便而有价值的工具，至少与用户故事一样轻巧。
为大型系统编写用例是繁琐的，并且浪费时间。
正如某些人所说，
用例的格式使得很难在不到数百页的情况下描述大型系统（例如CRM系统）。这很耗时，您会发现自己花时间做不必要的返工。
花很多时间编写乏味的用例，这些用例不增加价值或很少的价值，并且会导致很多返工，这表明作家的技能不佳，并且对如何有效地编写质量用例的知识很少。用例应以迭代，增量和进化（敏捷）方式撰写。应用用例模板并不意味着应使用并在特殊专用阶段（即传统瀑布开发模型中的需求阶段）全面使用用例模板的所有字段。
实际上，通过这些流行的模板样式制定的用例格式，例如RUP和Cockburn（也由OUM方法采用）等，在实践中已证明是有价值且有用的工具，用于捕获，分析和记录复杂要求大型系统。好的用例文档（模型）的质量不应在很大程度上或仅根据其大小来判断。大型系统的质量和全面用例模型也可能最终变成数百页，这主要是因为问题的固有复杂性，而不是因为其作者的写作技巧差。
工具
具有模板支持的文本编辑器和/或文字处理器通常用于编写用例。对于大型和复杂的系统要求，专用的用例工具很有帮助。
一些知名的用例工具包括：
- casecomplete
- 企业建筑师
- 魔术
- Rational Software的RequisitePro- 1990年代的早期，众所周知的用例和需求管理工具之一。
- 软件创意建模者
- Wiki软件- 团队的好工具，可协作和管理用例。
大多数UML工具都支持用例的文本写作和视觉建模。