PDFUse-Case 2.0
软件开发的中心
Ivar Jacobson、Ian Spence 和 Brian Kerr
用例作为一种需求方法已经存在了近 30 年，并且一直是用户故事等较新技术的灵感来源。现在，灵感已经转向另一个方向。“Use-Case 2.0”是新一代用例驱动的开发方法——轻量级、敏捷和精益——其灵感来自用户故事和敏捷方法 Scrum 和 Kanban。
Use-Case 2.0 具有过去所有流行的价值——不仅支持需求，还支持架构、设计、测试和用户体验——并且在业务建模和软件重用中发挥着重要作用。
Use-Case 2.0 的灵感来自用户故事，以协助 Scrum 的积压工作和 Kanban 的单件流，并引入了一个重要的新概念：用例切片。
本文论证了用例本质上包含了用户故事提供的技术，但为更大的系统、更大的团队以及更复杂和要求更高的开发提供了更多。它们与用户故事一样轻量级，但也可以平滑且结构化的方式扩展，以包含所需的尽可能多的细节。最重要的是，它们驱动并连接了软件开发的许多其他方面。
用例——为何依然成功和流行？
用例最初是在 OOPSLA 87（面向对象编程系统、语言和应用程序）6 上提出的，尽管直到 1992 年出版了《面向对象软件工程——用例驱动方法》7 一书后才被广泛采用。从那时起，许多其他作者也采用了这一想法的部分内容，特别是 Alistair Cockburn2 关于需求和 Larry Constantine4 关于设计以获得更好的用户体验。用例被采纳为标准 UML（统一建模语言1）的一部分，其图表（用例和参与者图标）是该语言中使用最广泛的部分之一。许多其他书籍和论文都撰写了关于各种系统用例的文章——不仅适用于软件，还适用于业务、系统（如嵌入式系统）和系统之系统。着眼于今天和未来，最新的宏观趋势，物联网（Internet of Things）和工业互联网，都选择了用例9。
用例实践在过去几年中不断发展，受到许多不同人士的想法的启发，更新的想法被纳入 Use-Case 2.0 中。一个新想法是将用例切片成用例切片5,8。将这些切片调整大小以使其成为合适的积压工作项，并将它们与用户故事关联起来的想法是 Use-Case 2.0 的核心。
用例可以而且应该用于驱动软件开发。它们不规定您应该如何计划或管理您的开发工作，也不规定您应该如何设计、开发或测试您的系统。但是，它们为成功采用您选择的管理和开发实践提供了结构。
用例方法成功的原因不仅仅在于它是一种从使用角度捕获需求或设计实用的用户体验的非常实用的技术，而且它还影响着整个开发生命周期。关键用例——或者更准确地说，关键用例切片（切片是用例中精心选择的部分）——系统地协助查找应用程序架构。它们驱动软件设计中组件或其他软件元素的识别。它们是必须通过测试的元素——并且真正支持测试驱动的设计。它们是计划冲刺时放入积压工作项或使用 Kanban 放在画布上的元素。业务用例是业务流程；因此，使用用例进行业务建模的优势在于，它可以直接找到要开发的系统用例以支持业务。此外，用例有助于发现共性，从而指导架构工作以实现软件重用。
应用用例还有许多类似的价值，但最重要的是用例的想法是直观易懂的。这是一种轻量级、精益和敏捷、可扩展、通用且易于使用的方法。许多第一次听到用例的人都铭记于心；许多人开始在日常生活中使用该术语，而没有考虑所有有助于软件开发许多方面的细节——这些方面是软件开发车轮的轮辐，而用例是轮毂（见图 1）。
因此，似乎很明显，用例经受住了时间的考验，并且拥有非常健康的未来。
用例采用原则
任何成功应用用例的核心都有六项基本原则
1. 通过讲述故事保持简单。
2. 理解大局。
3. 关注价值。
4. 以切片方式构建系统。
5. 以增量方式交付系统。
6. 适应团队的需求。
原则 1：通过讲述故事保持简单
讲故事是文化得以生存和进步的方式；这是将知识从一个人传递给另一个人的最简单有效的方式。这是沟通系统应该做什么以及让参与系统工作的每个人都专注于相同目标的最佳方式。
用例捕获系统的目标。为了理解用例，我们讲述故事。这些故事涵盖了如何实现目标以及如何处理途中出现的问题。用例提供了一种以简单而全面的方式识别和捕获所有不同但相关的故事的方法。这使得系统的需求能够被轻松捕获、共享和理解。
原则 2：理解大局
无论您开发的系统是大还是小，无论是软件系统、硬件系统还是业务系统，理解大局都至关重要。如果不了解系统的整体情况，您将无法就系统中应包含什么、应排除什么、成本以及将带来的好处做出正确的决策。
用例图是呈现系统需求概览的简单方法。图 2 是一个简单电话系统的用例图。这张图显示了系统的所有使用方式、谁启动交互以及涉及的任何其他方。例如，呼叫用户可以向系统的任何可呼叫用户拨打本地电话或长途电话。您还可以看到，用户不必是人，也可以是其他系统，在某些情况下，两者兼而有之（例如，被呼叫用户的角色可能是答录机而不是人）。
原则 3：关注价值
当试图理解系统将如何使用时，始终重要的是关注它将为其用户和其他利益相关者提供的价值。只有当系统实际使用时才会产生价值，因此最好关注系统将如何使用，而不是关注它将提供的功能或特性的长列表。
用例通过专注于系统将如何用于实现特定用户的特定目标来提供这种关注。它们涵盖了系统的多种使用方式：那些成功实现目标的以及那些处理可能发生的任何问题的。
图 3 显示了以这种方式为现金机的取款用例构建的用例叙述。实现目标的最简单方法是通过基本流程来描述。其他方法以备选流程的形式呈现。通过这种方式，您创建了一组流程，这些流程构建和描述故事，有助于找到完成其定义的测试用例。
这种项目符号轮廓可能足以捕获故事并驱动开发，或者当团队探索系统需要做什么的细节时，可能需要对其进行详细说明。
原则 4：以切片方式构建系统
大多数系统在可用并准备好投入运营之前都需要大量工作。它们有许多需求，其中大多数需求依赖于其他需求的实现才能实现并交付价值。尝试一次性构建这样一个系统始终是一个错误。系统应该以切片方式构建，每个切片都对用户具有明确的价值。
方法非常简单。首先，确定系统必须做的最有用的一件事，并专注于此。然后拿起这件事，并将其切成更薄的切片。确定代表这些切片验收的测试用例。选择穿过从头到尾整个概念的最中心切片，或尽可能接近它的切片。作为一个团队对其进行估算并开始构建它。
这是 Use-Case 2.0 采用的方法，其中用例被切片以提供大小合适的工作项，并且系统本身也以切片方式演进。
尽管用例传统上一直用于帮助理解和捕获需求，但它们一直不仅仅是关于这些。用例切片不仅切过需求，还切过系统及其文档的所有其他方面，包括设计、实现、测试用例和测试结果。
原则 5：以增量方式交付系统
大多数软件系统都经过许多代演进。它们不是一次性生产出来的；它们是作为一系列版本构建的，每个版本都建立在前一个版本的基础上。即使是版本本身通常也不是一次性生产出来的，而是通过一系列增量演进的。每个增量都提供了一个可演示或可用的系统版本。这是所有系统都应生产的方式。
图 4 显示了系统版本的增量开发。第一个增量仅包含一个切片——用例 1 的第一个切片。第二个增量增加了用例 1 的另一个切片和用例 2 的第一个切片。然后添加更多切片以创建第三个和第四个增量。第四个增量被认为是完整且足够有用的，可以发布。
原则 6：适应团队的需求
不幸的是，对于软件开发的挑战，没有一种万能的解决方案；不同的团队和不同的情况需要不同的风格和不同的细节级别。无论您选择哪种实践和技术，您都需要确保它们足够灵活，能够满足团队的持续需求。
Use-Case 2.0 的设计考虑到了这一点，并且可以根据需要进行简化。小型协作团队可以使用非常轻量级的用例叙述，以捕获故事的基本要素。这些可以手写在简单的索引卡上。大型分布式团队可以使用更详细的用例叙述，以文档形式呈现。团队可以自行决定是否需要超越基本要素，并在遇到基本要素无法应对的问题时以自然的方式添加细节。
Use-Case 2.0 实践
Use-Case 2.0 实践描述了要使用的关键概念、用于描述它们的工作产品以及一组活动。
要使用的概念
Use-Case 2.0 涵盖了需求、为满足需求而开发的系统以及用于证明系统满足需求的测试。Use-Case 2.0 的核心是用例、用例切片和故事。
用例捕获需求，每个用例都通过将其切片成一组可以独立工作的用例切片来管理范围。讲述故事弥合了利益相关者、用例和用例切片之间的差距。这就是利益相关者沟通他们的需求并探索用例的方式。理解故事也是找到正确的用例切片来驱动系统实现的机制。
用例
用例是
* 系统执行的一系列动作，这些动作为特定用户产生了可观察的价值结果。
* 系统的特定行为，它与用户协作以交付对该用户有价值的东西。
* 为用户提供有意义结果的最小活动单元。
* 一组相关需求的上下文。
总而言之，所有用例的集合为我们提供了系统的所有功能需求。
理解用例的方法是讲述故事。这些故事涵盖了如何实现目标以及如何处理途中出现的任何问题。它们帮助开发人员理解用例并以切片方式实现它。
用例经历几个定义的状态更改，从仅建立目标开始，到故事结构理解、最简单的故事实现、足够的故事实现，再到所有故事实现。这些状态构成了理解和实现用例的重要航点。
用例切片
用例涵盖了许多重要性和优先级各不相关的相关故事。在一个版本中交付的故事通常太多，并且通常在一个增量中要处理的故事也太多。因此，需要将用例分成更小的部分。
用例切片是从用例中选择的一个或多个故事，以形成对客户具有明确价值的工作项。它充当完成所选故事的实现所需的所有工作的占位符。用例切片演变为包括通过设计、实现和测试的相应切片。
用例切片是 Use-Case 2.0 最重要的元素，因为它不仅用于帮助满足需求，还用于驱动系统的开发以满足需求。
用例切片经历几个状态更改，从最初的识别（范围界定）开始，到准备、分析、实现，最后到验证。这些状态允许计划和跟踪用例切片的理解、实现和测试。
对于粗略观察状态的观察者来说，这可能看起来像瀑布过程。但是，有一个很大的不同，因为这涉及到一个单独的用例切片。在所有切片中，所有活动都可以并行进行。当一个用例切片正在被验证时，另一个用例切片正在被实现，第三个正在准备中，第四个正在被分析。
故事
讲述故事是开发人员与利益相关者一起探索用例的方式。每个对用户和其他利益相关者有价值的故事都是贯穿其中一个用例的线索。故事本质上可以是功能性的或非功能性的。
故事由用例叙述的一部分、一个或多个流程和特殊需求以及一个或多个测试用例来描述。找到有效故事的关键是理解用例叙述的结构。流程网络可以被认为是总结了描述用例所需的所有故事的地图。在图 3 中之前的现金机示例中，您可以识别出诸如“提取 100 美元的标准金额”、“提取 75 美元的非标准金额并获得收据”或“响应无效卡”之类的特定故事。
每个故事都遍历一个或多个流程，从基本流程开始处的用例开始，到基本流程结束处的用例结束。这确保了所有故事都与实现同一目标相关，是完整且有意义的，并且是互补的，因为它们都建立在基本流程描述的简单故事之上。
工作产品
用例和用例切片由团队用来帮助共享、理解和记录它们的一些工作产品支持。
用例模型将需求可视化为一组用例，从而提供了要构建系统的总体概览。该模型定义了用例，并为详细阐述各个用例提供了上下文。
用例通过讲述故事来探索。每个用例都通过以下方式描述：（1）用例叙述，概述了其故事作为一组流程；以及（2）一组测试用例，完成了故事。这些可以用一组适用于整个用例且通常是非功能性的特殊需求来补充。这些将影响故事，帮助将正确的故事分配给用于实现的用例切片，并且最重要的是，定义正确的测试用例。
用例模型由支持信息补充。这捕获了用例模型中使用的术语的定义，以及在用例叙述中概述故事时使用的术语的定义。它还捕获了适用于所有用例的任何系统范围的需求。
可以创建用例实现来显示系统的元素如何协作以执行用例。将用例实现视为提供“如何做”以补充用例叙述的“做什么”。表达用例实现的常用方法包括简单表格、故事板或序列图。
使用用例和用例切片
除了创建和跟踪工作产品外，开发人员还需要跟踪用例和用例切片的状态和属性。这可以通过多种方式和多种工具来完成。可以使用便利贴或电子表格非常简单地跟踪状态。如果需要更正式的方式，则可以使用许多商业上可用的需求管理、变更管理或缺陷跟踪工具之一。
图 5 显示了一个用例及其一些切片，这些切片捕获在一组便利贴上。
显示的用例是来自在线购物应用程序的“7. 浏览和购物”。用例的切片 1 和 2 基于从基本流程派生的单个故事：“选择和购买 1 件产品”和“选择和购买 100 件产品”。切片 3 基于涵盖用例中涉及的各种支持系统的可用性的多个故事。
用例的基本属性是其名称、状态和优先级。在本例中，使用了流行的 MoSCoW（必须做、应该做、可以做、想要做）优先级排序方案。还应估算用例。这里使用了一种评估相对大小和复杂性的简单方案。
用例切片的基本属性是：（1）其故事列表；（2）对用例和定义故事的流程的引用；（3）对将用于验证其完成情况的测试和测试用例的引用；以及（4）对实现和测试切片所需工作的估算。在本示例中，故事用于命名切片，并且对用例的引用隐含在切片的编号和流程列表中。估算是在与团队协商后稍后添加的。这些是每个便利贴右下角的大数字。在本例中，团队使用了计划扑克来创建使用故事点的相对估算。
还应该对用例和用例切片进行排序，以便首先处理最重要的用例和用例切片。
保持工作产品尽可能轻量级
所有工作产品都定义了多个细节级别。第一个级别定义了基本要素，即实践工作所需的最小信息量。定义了更多细节级别，以帮助团队应对他们可能遇到的任何特殊情况。这允许小型协作团队在简单的索引卡上定义非常轻量级的用例叙述，并允许大型分布式团队拥有以文档形式呈现的更详细的用例叙述。然后，团队可以根据需要扩展叙述，以帮助沟通或彻底定义重要或安全关键的需求。
好消息是，您始终以相同的方式开始，即从基本要素开始。然后，团队可以不断调整其用例叙述中的细节级别，以满足他们不断变化的需求。
要做的事情
Use-Case 2.0 将工作分解为许多必要的活动，如果用例要为团队提供真正的价值，则需要完成这些活动。
查找参与者和用例活动生成一个用例模型，该模型标识用例，随后将对其进行切片。然后，将通过在用例叙述中描述相关故事并定义测试用例来准备这些用例切片。分析切片以确定系统元素将如何交互以执行用例，然后作为切片实现和测试。Use-Case 2.0 可以被认为是测试驱动开发的一种形式，因为它预先为每个切片创建测试用例。最后，对整个系统进行测试，以确保所有切片在组合在一起时协同工作。
这些活动本身将在您的工作过程中多次执行。即使是一个简单的活动，例如查找参与者和用例，也可能需要多次执行才能找到所有用例，并且可以与其他活动并行或之后进行。例如，在继续查找参与者和用例的同时，您还可以实现早期找到的用例中的一些切片。
随着项目的进展，优先级会发生变化，经验教训会被吸取，并且会提出变更请求。这些都可能对已经实现的用例和用例切片以及仍在等待进展的用例和用例切片产生影响。这意味着将对用例进行持续的检查和调整活动。这也将调整使用 Use-Case 2.0 实践的方式，以调整切片的大小或工作产品中的细节级别，以满足项目和团队不断变化的需求。
使用 Use-Case 2.0
许多人认为用例仅适用于用户密集型系统，这些系统在人类用户和系统之间有大量交互。这很奇怪，因为用例的最初想法来自电信交换系统，该系统既有人类用户（用户、操作员），也有机器用户（以其他互连系统的形式）。用例适用于所有被使用的系统——这意味着所有系统。
它不仅适用于用户密集型应用程序
事实上，用例对于几乎没有人机交互的嵌入式系统与对于用户密集型系统一样有用。人们正在汽车、消费电子、军事、航空航天和医疗行业等不同领域的各种嵌入式软件开发中使用用例。即使是用于化工厂的实时过程控制系统也可以通过用例来描述，其中每个用例都侧重于工厂过程行为和自动化需求的特定部分。
它不仅适用于软件开发
用例的应用不仅限于软件开发。它们还可以帮助理解业务需求、分析现有业务、设计新的和更好的业务流程，以及利用 IT 的力量来改造业务。通过递归地使用用例来（1）建模业务及其与外界的交互，以及（2）建模支持和改进业务所需的系统，开发人员可以无缝地识别系统将影响业务的哪些方面以及需要哪些系统来支持业务。
处理所有类型的需求
尽管用例是描述系统功能的最流行技术之一，但它们也被用于探索非功能特性。执行此操作的最简单方法是将它们捕获为用例本身的一部分——例如，将性能需求与用例特定步骤之间所花费的时间相关联，或将用例的预期服务级别列为用例本身的一部分。
一些非功能特性比这更微妙，并且适用于许多甚至所有用例。在构建分层架构（包括安全、事务管理、消息传递服务和数据管理等基础设施组件）时，尤其如此。这些领域的需求仍然可以表示为用例——专注于系统技术用法的单独用例。这些额外的用例称为基础设施用例8，因为它们包含的需求将驱动应用程序运行的基础设施的创建。
适用于所有开发方法
Use-Case 2.0 适用于所有流行的软件开发方法，包括
* 积压工作驱动的迭代方法，如 Scrum、EssUP 和 OpenUP。
* 基于单件流的方法，如 Kanban。
* 一次性完成的方法，如传统瀑布。
Use-Case 2.0 和积压工作驱动的迭代
在采用任何积压工作驱动的方法之前，您必须了解哪些项将进入积压工作项。团队使用各种形式的积压工作项来驱动他们的工作，包括产品积压工作项、版本积压工作项和项目积压工作项。无论使用何种术语，它们都遵循相同的原则。积压工作项本身是可能需要的一切事物的有序列表，并且是任何要进行的更改的单一需求来源。
在 Use-Case 2.0 中，用例切片是主要的积压工作项。用例切片的使用确保了积压工作项的良好形成，因为它们自然是独立的、有价值的和可测试的。定义它们的用例叙述的结构确保了它们是可估算的和可协商的，并且用例切片机制使它们可以切片得尽可能小，以支持开发团队。
当采用积压工作驱动的方法时，重要的是要认识到积压工作项不是预先构建和完成的，而是不断地工作和改进的。图 6 显示了积压工作驱动的迭代方法的典型活动顺序。
Use-Case 2.0 和单件流
单件流是一种从精益制造中借鉴的技术，它可以避免迭代和瀑布方法中看到的需求批处理。每个需求项都快速流经开发过程，但为了有效工作，此技术需要小的、规则大小的项。用例的大小将太不规则且太大而无法流经系统。但是，可以适当地调整用例切片的大小并对其进行调整以满足团队的需求。
单件流并不意味着一次只处理一个需求项，或者在一个工作站和下一个工作站之间只有一件工作。系统中需要有足够的项来使团队保持忙碌。在制品限制用于平衡流程并防止任何浪费的积压工作项的积累。图 7 显示了一个简单的 Kanban 板，用于可视化用例切片的流程。
在制品限制以红色显示。从左到右读取，您可以看到切片必须在输入团队之前进行识别和范围界定。在此图中，在制品限制为 5，并且作为需求来源的客户、产品负责人或需求团队会尝试始终保持五个用例切片准备好实施。
请注意，没有明确的 Kanban 板或在制品限制集；它取决于团队结构和工作实践。看板和在制品限制应与实践相同地进行调整。用例切片的状态非常有助于这种工作设计，因为它们可以清楚地定义切片在移交给链条的下一部分时应处于什么状态。
Use-Case 2.0 和瀑布
由于各种原因，您可能需要在某种形式的瀑布治理模型的约束下开发软件。这通常意味着将尝试在将所有需求移交给第三方进行开发之前预先捕获所有需求。
在瀑布方法中，用例不会不断地工作和改进以允许最终系统出现，而是在工作开始时一次性定义。
瀑布方法的一次只做一件事的性质意味着团队的组成会随着时间的推移不断变化，因此使用面对面沟通来分享故事的能力非常有限。为了应对这种情况，您需要提高工作产品上的细节级别，超越基本要素。
Use-Case 2.0——它不仅适用于一种类型的团队
Use-Case 2.0 的另一个重要方面是它能够适应现有的团队结构和工作职能，同时鼓励团队消除浪费并提高效率。为此，Use-Case 2.0 没有预定义任何特定的角色或团队结构，但它确实为每个中心元素（用例和用例切片）定义了一组状态。
正如关于 Use-Case 2.0 和单件流的讨论所说明的那样，状态指示项何时处于静止状态，并且可以从一个人或团队移交给另一个人或团队。这使得该实践可以与各种形状和规模的团队一起使用，从几乎没有或没有移交的小型跨职能团队到大型专家团队网络，其中每个状态更改都是不同专家的责任。跟踪这些元素的状态和移交允许监控工作流经团队（或多个团队），并允许团队调整其工作方式以不断提高其绩效。
扩展以满足您的需求——向内、向外和向上
没有一种预定义的方案适合所有人，因此 Use-Case 2.0 的使用需要在多个不同的维度上进行扩展
* 用例向内扩展，为经验不足的实践者（开发人员、分析师、测试人员等）或想要或需要更多指导的实践者提供更多指导。
* 它们向外扩展以覆盖整个生命周期，不仅涵盖分析、设计、编码和测试，还涵盖运营使用和维护。
* 它们向上扩展以支持大型和超大型系统，例如系统之系统：企业系统、产品线和分层系统。此类系统很复杂，通常由在不同站点并行工作的许多团队开发，可能针对不同的公司，并重用许多遗留系统或打包解决方案。
无论正在开发的系统的复杂程度如何，开发团队始终以相同的方式开始，即识别最重要的用例并创建总结需要构建的内容的大图。然后可以调整 Use-Case 2.0 以满足团队不断变化的需求。事实上，Use-Case 2.0 实践坚持您不断检查和调整其使用情况，以消除浪费、提高吞吐量并跟上团队不断变化的需求。
用户故事和用例——有什么区别？
回答这个问题的最佳方法是查看用户故事和用例的共同属性——使两者都作为积压工作项良好工作，并使两者都能够支持流行的敏捷方法，如 Scrum、Kanban、测试驱动开发和示例规范。
用例切片和用户故事3 具有许多共同特征。例如
* 它们都定义了团队可以在冲刺中完成的功能切片。
* 如果它们太大，都可以切片，从而产生更多、更小的项。
* 它们都可以写在索引卡上。
* 它们都产生代表验收标准的测试用例。
* 它们都是对话的占位符，并受益于 Ron Jeffries 发明的三个 C：卡片、对话和确认。
* 它们都可以使用诸如计划扑克之类的技术进行估算。
因此，鉴于它们有如此多的共同之处，是什么使它们与众不同呢？用例和用例切片提供附加值
* 一张大图，帮助人们理解系统的范围及其价值。
* 更好地理解系统做什么以及如何做。
* 更好地组织、理解、应用和维护测试资产。
* 轻松的测试用例生成和分析。
* 支持持续的影响分析。
* 主动范围管理，允许轻松关注提供最小可行产品。
* 灵活、可扩展的文档，以帮助应对可追溯性或其他合同约束。
* 支持简单系统、复杂系统以及系统之系统。
* 更容易识别缺失的和冗余的功能。
问题仍然存在：你应该使用哪种技术？一旦你超越个人偏好，这实际上非常依赖于具体情况。 考虑以下因素：有多容易接触到 SME（领域专家）；以及如果需求错误泄露到线上环境，其后果将有多严重。
当容易接触到 SME 且错误严重性较低时，用户故事最适用。 当不容易接触到 SME 或错误后果较高时，用例和用例切片更适用。 然而，由于用例方法可以向下扩展到用户故事的最佳适用点，因此您可能仍然希望应用用例方法。 如果目标系统将始终处于用户故事的最佳适用点，那么用户故事就足够了，但如果您预计它会扩展到该范围之外，则应考虑用例和用例切片。
结论
Use-Case 2.0 作为一个经过验证且定义完善的实践而存在，它与许多其他软件开发实践兼容，例如持续集成、有意架构和测试驱动开发。 它也适用于所有流行的管理实践。 特别是，它具有轻量性和灵活性，可以支持以敏捷或精益方式工作的团队。 它还具有支持以更正式或瀑布式环境工作的团队所需的完整性和严谨性。
有关完全文档化的 Use-Case 2.0 实践的更多详细信息，请访问 http://www.ivarjacobson.com。
参考文献
1. Booch, G., Jacobson, I., Rumbaugh, J. 2004. 统一建模语言参考手册，第二版。 Addison-Wesley Professional。
2. Cockburn, A. 2001. 编写有效的用例。 Addison-Wesley Professional。
3. Cohn, M. 2004. 用户故事应用。 Addison-Wesley Professional。
4. Constantine, L., Lockwood, L. 1999. 软件可用性设计。 Addison-Wesley Professional。
5. Jacobson, I. 2003. 面向方面的案例，第二部分。 软件开发杂志 (十一月): 42-48。
6. Jacobson, I. 1987. 工业环境中的面向对象软件开发。 面向对象编程系统、语言和应用程序会议论文集 (OOPSLA 87)。
7. Jacobson, I., Christerson, M., Johnsson, P., Overgaards, G. 1992. 面向对象软件工程：用例驱动方法。 Addison-Wesley Professional。
8. Jacobson, I., Ng, P.W. 2005. 基于用例的面向方面软件开发。 Addison-Wesley Professional。
9. Slama, D., Puhlmann, F., Morrish, J., Bhatnagar, R. 2015. 企业物联网； http://enterprise-iot.org/book/enterprise-iot/。
Ivar Jacobson， 博士，是组件和组件架构、用例、面向方面软件开发、现代业务工程、统一建模语言和 Rational 统一过程的创始人之一。 他对软件行业的最新贡献是一个正式的实践概念，该概念将实践提升为软件开发的“一等公民”，并将方法（或过程）简单地视为实践的组合。 Jacobson 也是 SEMAT（软件工程方法和理论）社区的创始人之一，该社区的使命是重塑软件工程。 他是七本有影响力的畅销书和大量论文的主要作者。 他被授予 Gustaf Dalén 奖章（“小诺贝尔奖”）， 并且是秘鲁圣马丁德波雷斯大学的 荣誉博士。
Ian Spence 是 Ivar Jacobson International 的首席技术官，也是 SEMAT （软件工程方法和理论） 内核开发团队的负责人。 作为一位经验丰富的教练，他已将数百个项目引入迭代和敏捷实践。 他还领导了众多成功的大规模转型项目，与多达 5,000 人的开发组织合作。 他目前的兴趣领域是大型项目的敏捷、敏捷外包以及通过敏捷度量驱动可持续变革。
Brian Kerr 是一位经验丰富的敏捷教练、顾问、 和变革推动者，并且是 Ivar Jacobson International 的首席顾问。 他与团队和组织合作，帮助他们以务实和可持续的方式采用关键的软件开发实践。 他在需求领域拥有特别的专业知识，并且在过去的 20 年中，在许多行业和领域中使用、教授和咨询用例方法。 他参与了 SEMAT （软件工程方法和理论） 倡议以及 Use-Case 2.0 实践中捕捉到的最新想法背后的思考工作。
版权所有 © 2016，所有者/作者持有。 出版权已许可给 。
最初发表于 Queue vol. 14, no. 1—
在 数字图书馆 中评论本文
更多相关文章
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 - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。 低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。 本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。 在其快速前进的匆忙中，它容易受到时尚的支配，并且可能会忘记或忽略一些它面临的永恒问题的成熟解决方案。 用例于 1986 年首次引入，并在后来普及，是这些成熟的解决方案之一。
© 保留所有权利。