PDF用例至关重要
用例提供了一种经过验证的方法，以简洁且易于理解的格式捕获和解释系统的需求。
Ivar Jacobson 和 Alistair Cockburn
虽然软件行业是一个快节奏且令人兴奋的世界，新的工具、技术和方法不断涌现以服务于商业和社会，但它也很健忘。在快速前进的过程中，它容易受到时尚潮流的影响，并且可能会忘记或忽略一些它面临的永恒问题的成熟解决方案。用例，最早于1986年6 引入，并在之后得到普及3,7，就是这些成熟的解决方案之一。Ivar Jacobson 和 Alistair Cockburn，该领域两位主要的参与者，正在撰写本文，向新一代人描述用例是什么以及它们如何发挥作用。
我们认为，当今世界有许多专业的开发人员、分析师和测试专家，他们正在看到他们当前工作方式的缺点，并且正在寻找一种简洁而稳健的方式来向他们的利益相关者描述和沟通需求。用例继续以简单的方式解决一系列显著的问题，因为它们实现了以下目标：
这甚至还不是完整的好处列表！由于用例定义了与参与者的操作和交互序列，它们还可以驱动用户体验设计和领域驱动设计，并支持业务建模和价值流分析。
用例的“原因”
用例用于将组织与其产品或声明的意图绑定在一起。例如，自动驾驶汽车的用例指定或描述了这些汽车应具有的额外功能。用例可以描述全新的产品或服务，或对现有事物的改进。它们易于理解，并受到用户、利益相关者、业务分析师和测试专家的喜爱。
这个概念非常流行，以至于术语用例甚至已成为词典条目，并在今天的谷歌搜索中产生1.11亿个匹配项（用户故事返回340万个结果）。如此庞大数字的原因是用例被用于所有领域：自动驾驶汽车、大数据、物联网（Internet of Things）、云计算。
即使是一个平庸的用例也将为赞助商、分析师、开发人员和测试人员带来显著的好处；没有必要将它们细化到极致才能释放这种价值。用例也具有一种美妙的精确性；当使用国际标准 UML（统一建模语言）时，您可以从需求中的用例无缝过渡到设计中的实现，再到实施，以及一直到测试。
不幸的是，有一个重要的社区已经忘记或拒绝在其工作中使用用例：新一代的软件开发人员。许多人仍然不明白将用例作为敏捷开发过程的组成部分是多么容易。结果是什么？用例很可能被创建、维护，并为组织的许多部门交付显著的价值，但开发人员却错误地认为用例与他们希望使用的用户故事之间存在阻抗不匹配。事实上，我们曾经听到一位开发人员对业务分析师说：“如果你带着用例出现在我们的房间里，我们不会读它们的！”
令人高兴的是，我们现在看到了用例的复兴。即使在敏捷项目中，业务分析师也在使用它们来将他们的业务需求整合在一起。最近（2021年）的 DevOps 现状报告也强调了用例的重要性：
“记录您的产品和服务的关键用例。您记录关于系统的内容很重要，用例允许您的读者将信息和您的系统投入使用。”1
用例是什么样的？
OMG UML 规范9 将用例定义如下：
“用例是捕获系统需求的一种手段，即系统应该做什么。指定的关键概念是参与者、用例和主题。每个用例的主题代表正在考虑的应用用例的系统。用户和任何其他可能与主题交互的系统都表示为参与者。”
每个用例都包含以下关键要素：
参与者定义了用户在与系统交互时可以扮演的角色。用户可以是个人或其他系统。主要参与者是用例流行的参与者。这是用例的原因。通常，此参与者也是引发事件的参与者。辅助参与者通常是帮助系统实现主要参与者目标所必需的。用例的魔力在于所有这些都是多么简单地完成的。
这是一个来自实际项目的示例用例，用于说明。
下订单
主要参与者： 职员
主要场景
1. 职员识别客户、商品和数量。
2. 系统接受订单并将其排队。
备选方案
1a. 信用额度低 & 客户是“首选”：系统无论如何都给予他们信用额度。
1b. 信用额度低 & 非“首选”客户：职员仅接受预付款。
2a. 库存不足：客户接受延期交货：职员将订单减少到可用库存水平。
请注意，此示例是对必须发生的事情的非常简单的文本描述，没有描述 GUI（图形用户界面）。它非常易于阅读，任何忙碌的高管都可以一目了然地看到关键条件是否得到处理。与此同时，它非常完整，业务分析师可以在开发人员发现角落案例之前对其进行调查。它为测试人员提供了测试系统功能完整性所需的结构。
这种可读性使用例具有魔力。即使是随意编写的用例也提供了刚刚概述的关键价值。用例的美妙之处在于，当以结构化文本捕获时，它们可能非常有效。
UML（建模标准语言）也可以用于传达用例静态视图的关键要素——一图胜千言。图 1 显示了一个名为仓库库存的系统，其中参与者职员与用例下订单进行交互，而用例下订单又与参与者客户进行交互。
UML 还允许我们通过应用序列图、协作图或活动图（如果需要）来描述参与者和用例之间的动态行为和交互。
用例的益处
在最高级别——我们可能称之为“10万美元级别”，用例可以概述将要交付的内容，以便组织中的每个人都可以阅读。将组织的目标意图统一起来价值数十万美元。花费几个小时进行用例头脑风暴会议可以帮助所有参与者对拟议的解决方案获得共同的理解，并产生一套易于理解的用例。
在前面的示例中，关于职员工作的进一步讨论阐明了该参与者和系统在许多用例中的作用：执行库存的定期审核、为客户下订单、在需要时补充产品库存以及帮助送货员在仓库中卸货。UML 图现在提供了影响系统状态的用例以及我们已识别的使用该系统的参与者的简单、清晰、永久的记录。图 2 显示了一个具有更多参与者和用例的仓库库存系统。
如前所述，将组织的目标意图统一起来确实价值数十万美元。
故事：在一家大型公司的一次用例培训课程结束后将近一年，其 CTO 在一次公开研讨会上表示，用例挽救了他的项目。当检查用例时，它们非常荒谬、极其简单——比此处提供的示例简单得多。
当被问及如此简单的用例如何可能挽救项目时，这位高管说：“通常发生的情况是，业务部门要求开发部门生产一些东西。然后开发人员离开很长时间，被各种有趣但无关紧要的主题分散注意力，并交付其他东西。
在这种情况下，业务部门要求这些简单的东西，开发人员保持正轨并交付了完全相同的东西。这些简单的用例使我们的项目成功了一次。”
在下一个级别，我们可能称之为“1万美元级别”，用例为业务分析师提供了一个支架，以发现困难的角落案例，并在开发人员和测试人员提出他们无法回答的尴尬问题之前调查并找到答案。
故事：本文中的下订单用例示例来自一个实际项目。备选方案 1b 不在原始用例中；只有 1a，写成：“1a. 信用额度低 & 客户是‘首选’：系统给予他们信用额度。”
奇怪的是，一开始没有人问，如果客户不是首选客户，应该怎么办。最后，有人问了这个问题。这似乎很奇怪，但遗漏经常以这种方式发生。在这个例子中，花了几天的时间调查才找到答案。
这种对角落案例缺乏探究的情况在现实世界中经常发生——并且很可能像这样的一个简单问题可能需要几天才能得到回答。但是，如果系统在没有处理该案例的情况下被开发和交付，那么业务部门的成本是多少，请想象一下。
没有其他功能需求格式——不是编号的需求，不是 shall 和 should，不是用户故事，不是故事地图——提供这种价值。
在下一个级别，我们可能称之为“1000美元级别”，用例为开发人员和测试人员都提供了出色的规范。它命名了每个场景以及每种情况下应该发生的事情。
关键在于，用例的顶级价值在于使整个组织与其目标保持一致。详细的编写具有很高的价值，但仍然比即使是非正式编写的用例提供的顶级价值低几个数量级。
为什么人们停止使用它们？
三件事使对用例的使用暂停：将用例制作为每个功能需求的百科全书条目的趋势，用例迫使人们实际思考他们想要什么，以及敏捷的替代方案：“用户故事”。
1. 第一个错误是将用例制作为功能需求的百科全书条目的趋势，并在该用例的描述下收集所有感兴趣的内容。项目经理和业务分析师开始将他们认为重要或相关的信息添加到用例中。结果，曾经紧凑的用例变成了一个臃肿的存储空间，用于存储关于该主题的每一条信息：UI 设计、复杂的业务规则、详细的验证、接口定义、数据格式等等。他们失去了用例的 10 万美元价值：对组织各个部门的忙碌人员来说是可读的。如果我们对用例有一条规则，那就是：每个用例描述都应该易于阅读。对用例中包含的内容要非常严格和有选择性。功能需求，以及仅与特定用例相关的非功能需求，应以简洁的方式包含在内。
2. 用例迫使人们实际思考他们想要什么的第二个问题通过关于找出如何处理非首选客户的故事来突出显示。它们需要思考和调查时间。随着世界变得越来越快，并以敏捷的方式工作，业务分析师被给予越来越少的时间来思考和调查。相反，他们被告知只需写一个占位符短语，让详细的条件在开发过程中出现。
3. 导致远离用例的第三种力量是用户故事。用户故事最初是为小型、共址项目提出的，在这些项目中，业务专家与开发人员的步行距离很短。用户故事实际上是“提醒进行对话”。详细的需求将在开发人员向业务人员展示不断增长的功能的一系列对话中演变。从未写下详细的规范。用户故事从来都不是需求捕获格式；它是有意非正式和不完整的。
在并行演变中，用户故事最终也变成了百科全书，就像用例曾经那样。它们从小型对话环境中的索引卡片转移到大型分布式项目中的在线需求和任务列表。它们失去了用例作为项目目的的可读持有者的优势，以及允许它们不完整的快速反馈。他们保留的是想法，即没有必要思考、提前思考、详细思考，而只需编程。开发人员喜欢这样。
繁重的前期思考、用例作为不可读的百科全书以及用户故事避免思考和计划的替代方案的结合导致了那句评论：“如果你带着用例出现，我们不会读它们的。”
用例的复兴
渐渐地，商业人士再次开始发现需要在一个地方看到他们提出的系统，并且新的受众开始理解用例的真正概念。他们需要“看到”他们面前的系统，并保证他们的请求的一致性和完整性。业务分析师已经再次开始编写用例，只是为了在开发人员以敏捷方式移动时保持业务可见。
故事：在一个最近的项目中，人们对用例一无所知，对用户故事也知之甚少，并且只是最近才听说过用户故事地图。
业务分析师接受了关于用例的速成课程，并以简单、可读的风格编写了两个用例。她还为他们标记了用户故事（如下一节所示）。被要求到办公室讨论即将到来的项目时，她向开发主管展示了她的两个用例，这位主管对用例一无所知。他很高兴，并说：“这些很好，我们可以使用这些。”她的业务赞助商也喜欢她可以阅读它们并了解新系统涵盖了哪些业务方面。
然而，第二天，开发人员表示他们想编写用户故事。她回到办公室，看到他们用一堆随机的句子贴满了墙壁，通常说他们将对数据库做什么，或一些其他内部编程任务。
那时她说：“你可以编写用户故事，但业务需求的最终存储库是用例。”
下周，开发人员表示他们想使用故事地图。她回到办公室，看到他们用成行成列的——再次——编程任务贴满了墙壁。
从那时起，她编写用例以保持她的思路清晰，并向其他商业人士展示。她继续使用这些用例来理顺故事地图，保持列与真实用户需求的对齐，并找到故事地图中的漏洞。
用例与敏捷开发相遇
许多人认为用例与敏捷开发相悖，但事实并非如此。本文的作者 Ivar 和 Alistair 在 2000 年代初期分别工作时，找到了将用例纳入增量和敏捷开发的相同方法。Ivar 和他的同事将他们的结果写成“用例 2.0”；8 Alistair 在他的讲座和课程中教授了类似的技术。4,5
敏捷开发依赖于两件事：（1）团队所有专业人员之间的密切协作；（2）增量开发。
保持用例的可读性，即使是非正式的，也有助于协作。所有角色都可以阅读所需的内容并保持一致。这是容易的部分，或者至少不是神秘的部分。
（对许多人来说）神秘的部分一直是：如何以演进的方式编写用例，以便第一个增量交付很好地展示正在交付的功能子集，同时允许用例随着时间和需求增长。
答案是将用例分成多个切片，其中每个切片都可以实现以形成对客户具有明确价值的工作项。切片不需要包含整个流程及其所有测试用例。第一个切片可能只是通过主要场景及其测试用例的“快乐日”路径。
一个实用的起点是查看我们用例中主要场景的第一句和可能最后一句话，并将此作为我们的第一个切片和用户故事来实现——一种信封，供所有其余部分从中生长。稍后的切片可以以相同的增量方式实现备选场景。切片可以根据团队的偏好制作成小或大。
这是另一个示例，展示了大学课程注册用例的增长。它来自 Steve Adolph 和 Paul Bramble 的著作有效用例模式。2
第一个切片
注册课程
主要参与者：学生
主要场景
1. 学生请求构建课程表。
2. 系统准备一个空白课程表单。
3. 学生指示课程表已完成。系统保存它。
以良好的增量风格，系统做了一些有用的事情，但尚无任何细节。在第一个切片中，第一个用户故事——可以写成“创建并保存空白课程表”——将在数据库中创建一个格式良好的空课程表。
在以下完整用例的扩展中，我们用数字（在方括号中，例如 [1]）标记每个附加切片。根据团队的偏好，它们可能会以不同的顺序完成；这只是一种可能性。请注意第一个切片 [1] 如何捕获开始和结束步骤。另请注意步骤 5 如何分成两个切片。
注册课程
主要参与者： 学生
主要场景
[1] 1. 学生请求构建课程表。
[1] 2. 系统准备一个空白课程表单。
[2] 3. 系统从课程目录系统获取可用课程。
[3] 4. 学生最多选择 4 个主要课程和 2 个备选课程。
[4,5] 5. 对于每门课程，系统验证学生是否具有必要的先修课程，并将学生添加到课程中，将学生标记为课程表中该课程的“已注册”。
[1] 6. 学生指示课程表已完成；系统保存它。
备选方案
[6] 1a. 学生已经有一个课程表
系统调出学生当前版本的课程表以进行编辑，而不是创建新的课程表。
[7] 1b. 当前学期已结束，下一个学期尚未开始
系统允许学生查看现有课程表，但不允许创建新的课程表。
[8] 3a. 课程目录系统无响应
系统通知学生，用例结束。
[9] 5a. 课程已满或学生未满足所有先修课程要求
系统禁用该课程的选择并通知学生。
通过以长篇形式编写用例，然后将其切分为切片，业务分析师可以跟踪正在交付的总上下文，同时支持开发团队以敏捷的方式工作，可能使用用户故事和故事地图。这正是业务分析师在之前的案例中所做的。
图 3a 中的图片显示了“注册课程”用例的主要场景如何在（例如）五个单独的切片中实现，开发团队优先交付主要场景。“创建并保存空白课程表”作为第一个用户故事交付。此用例的备选场景也可以在多个切片中交付（图 3b 中显示了四个切片）。
根据项目背景、固定价格投标或演进系统，用例可能在不同级别进行草绘或起草。在固定价格投标的情况下，它们必须至少以完整的级别起草，以识别必须开发的接口和必须研究的棘手的角落案例。
在演进的上下文中，最初可能只有用例名称的头脑风暴，以及选择一个或两个切片进行扩展开发。之后，将根据需要命名和起草它们，以保持业务可见并使开发步入正轨。
要点回顾
用例以简单的方式为许多利益相关者解决了一系列显著的问题。用例的一些好处是：
此外，它们可以预先编写用于固定投标项目，也可以增量编写用于演进和敏捷项目。
用例的 10 万美元价值在于以组织中的每个人都可以阅读的方式展示将要交付的内容。随意、可读的用例仍然有用，而不可读的用例将不会被阅读。
用例的 1 万美元价值在于为业务分析师提供了一个支架，以便在开发人员和测试人员发现困难的角落案例之前发现和调查它们。这是我们所知的唯一提供这种好处的技术。
1000 美元的价值是为开发人员和测试人员提供规范，提供上下文并命名每个场景以及在每个场景中应该发生的事情。
获得这些好处的关键是保持写作简单，避免将用例变成百科全书条目，尤其要避免在其中放入 UI 细节。架构师和 UX（用户体验）专家当然可以将用例作为驱动他们自己工作的关键输入，但他们的工作输出不应添加回这些用例中（除非是为了纠正原始用例）。
用例提供了一种经过验证的方法，以简洁且易于理解的格式捕获和解释系统的需求。它们可以在不同级别使用：捕获“大局”视图或描述开发人员或测试人员的更详细的需求。用例受到商业人士的喜爱，并提供了一种简单的结构，可以帮助业务分析师探究新需求的角落案例。Ivar 的用例 2.0 和 Alistair 的敏捷用例方法都包含了开发人员所需的用户故事和增量。
参考文献
1. Accelerate State of DevOps 2021. Google Cloud; https://services.google.com/fh/files/misc/state-of-devops-2021.pdf.
2. Adolph, S., Bramble, P. 2003. 有效用例模式. Addison-Wesley.
3. Cockburn, A. 2001. 编写有效的用例。 Addison-Wesley.
4. Cockburn, A. 2003. 敏捷用例; https://web.archive.org/web/20140330015706/ http://alistair.cockburn.us/get/2231.
5. Cockburn, A. 2005. 用于敏捷和传统开发的用例; https://web.archive.org/web/20140329233851/ http://alistair.cockburn.us/get/2232.
6. Jacobson, I. 1987. 工业环境中的面向对象软件开发。在面向对象编程系统、语言和应用程序会议论文集 (OOPSLA 87)； https://dl.acm.org/doi/10.1145/38765.38824.
7. Jacobson, I., Christerson, M., Johnsson, P., Overgaards, G. 1992. 面向对象的软件工程——用例驱动的方法。 Addison-Wesley Professional.
8. Jacobson, I., Spence, I., Kerr, B. 2016. 用例 2.0。 acmqueue 14(1); https://queue.org.cn/detail.cfm?id=2912151.
9. OMG. 2017. OMG 统一建模语言 (OMG UML)，版本 2.5.1； https://www.omg.org/spec/UML/2.5.1/PDF.
关于作者的说明
Ivar Jacobson 在 1980 年代发明了用例，并在 1987 年的 OOPSLA 会议的论文中首次向世界展示了它们。6
Alistair Cockburn 在为 IBM 咨询集团创建面向对象编程项目的方法论时，于 1991 年发现了该论文，并飞往斯德哥尔摩向 Ivar 及其同事学习用例。从那时起，两位作者都在单独的书籍和文章中广泛撰写了关于用例的文章。
Alistair 是 2001 年《敏捷宣言》的共同作者之一，他开始将用例应用于演进和敏捷项目。4.5
Ivar 看到类似的需求，将增量方法形式化为用例 2.0。8 要查找有关“用例 2.0”的更多详细信息，请参阅 https://www.ivarjacobson.com/use-case-resources。您可以在 https://alistaircockburn.com/Publications 阅读 Alistair 的最新著作。
版权所有 © 2023 归所有者/作者所有。出版权已授权给
最初发表于 Queue 第 21 卷，第 5 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。 密码学哈希函数存在许多由各种安全需求驱动的标准，但在非密码学方面，存在一定程度的传统认知，尽管哈希函数历史悠久，但这些认知尚未得到充分探索。 虽然针对实际数据集以实现均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。 技术领导者凭直觉接受良好的开发者体验能够实现更有效的软件交付和开发者幸福感。 然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，以研究生产力差异，从而提供有关该主题的新见解。 低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。 本文报告了程序和协议、结果、局限性以及未来研究的机会。
Jorge A. Navas, Ashish Gehani - OCCAM-v2：结合静态和动态分析以实现有效且高效的程序整体特化
OCCAM-v2 利用可扩展的指针分析、值分析和动态分析，为 LLVM bitcode 创建了一个有效且高效的特化工具。 实现的代码大小缩减程度取决于特定的部署配置。 每个要特化的应用程序都附带一个清单，其中指定了先验已知的具体参数，以及运行时将提供的剩余参数的计数。 部分求值的最佳情况发生在参数完全具体指定时。 OCCAM-v2 使用指针分析来去虚拟化调用，从而可以消除任何直接调用都无法访问的函数的整个主体。
© 保留所有权利。