简介

没有其他软件工程语言结构 具有与用例一样大的影响，并且 如此广泛。我相信这是因为用例， 虽然是一个简单的想法，但在许多不同的方面都发挥着作用 软件工程。很多人问我是怎么来的 使用 tuse case 的想法，我将在这里简要描述它。我会 还要总结我们迄今为止在用例中取得的成就，然后提出建议 未来的一些改进。他马里兹

昨天：In The Beginning

用例已经存在超过 16 年了。当我第一次 在 1986 年使用了这个词，他们是自 1967.

进入用例

那是 1986 年;我对如何对电话进行建模感到困扰。现代 当时的 Switch 提供了很多类型的电话：本地 呼叫、传出呼叫、传入呼叫和中转呼叫。那里 是多种本地呼叫;以及多种呼出电话： 呼叫邻居交换机、国内交换机、国际交换机 开关。而且，最重要的是，这些电话中的每一个都可以被转载 使用不同的信号系统。

我们发现了很多多样性和多样性的问题 几年前。我们没有对每种类型的呼叫进行建模——有太多了， 它们之间有很多重叠——我们只是列出并命名 所有这些案例：我们称它们为交通案例。相反，我们对 我们需要不同的 “函数” 来执行所有调用。一个 function 是一些定义松散的软件。函数具有 无接口。他们有开始和结束，但不是 定义明确。函数可以与外部世界交互。 总体感觉是，我们并不真正了解哪些功能 是的，但我们可以举出他们的例子，有些人可以 指定它们。

但是，我们确实知道如何实现功能。我学到了 描述继电器操作序列的图表技术。 1969 年，我将这项技术转化为软件来描述组件 交互 — 与今天所谓的序列图 — 相同 引入它们时使用的术语。我们描述了函数 通过使用序列图（或协作图 进行更简单的交互），其方式与我们描述 今天的用例实现。

然后，在 1986 年春天的一天，在处理交通案件时 并尝试将它们映射到函数上，我突然明白了。A 流量 case 可以用函数来描述，方法是使用类似继承的 机制。我更改了术语并制作了交通案例和 函数和用例 — 前者成为具体或实际使用 案例，后者变成了抽象的用例。

我为 OOPSLA'86 写了一篇关于此的论文;这篇论文是我介绍的地方 使用案例。论文没有被接受（可能是因为我已经 在那次会议上有另一篇论文，或者因为大多数 程序委员会是编程语言专家）。然而 该论文被 OOPSLA'87 接受。本文介绍了许多 用例建模中的关键思想。

1987 年的用例是什么？

根据 OOPSLA'87 论文，“用例是一个特殊的序列 由用户和系统在对话中执行的交易。 这与我们目前的（非正式的）定义非常相似。我开发了 用于描述系统的外部视角的单独模型 我称之为用例模型。我所说的外面，是指一个黑匣子 系统视图 - 系统的内部结构为 对这个模型不感兴趣。有些人误解了 术语“outside”，并认为它是 User Interface 的同义词 但事实并非如此。相反，它代表了功能需求的模型 的系统。

此时，用例模型还包括实体（域） 对象，因此我们可以展示用例如何<<access>> 实体。用例和实体是类类的（带有操作） 而不是数据。用例模型中的另一个关系是 <<built-on>> 这被描述为“继承关系的扩展形式。 多重继承很常见。实际上，内置关系 是泛化关系和 <<extend） 的组合>> 关系。

不仅指定了用例，还设计和测试了用例。 “你创建的流程 [我们今天所说的活动] 与 有用例。转换用例的概念模型 无缝集成到一个新模型中，展示每个用例是如何实现的 通过识别出的块 [块今天将是子系统， 类或组件]。这听起来很像合作。 “每个用例都经过单独测试，以保护系统 满足用户的要求。请注意，用例 构成了贯穿整个开发活动的关键方面。

序列图用于显示 块/组件。这并不奇怪，因为序列图有 到那时，它们在实践中展示了近 20 年的价值。

到 1992 年，用例是什么？

1992 年，OOSE 出版了《面向对象的软件工程 — 一种用途》一书 案例驱动的方法，1 已发布。在 1987 年和 1992 年期间，Objectory 该过程已被大约 20 个客户实际使用 重要的新产品开发。这些客户参与其中 在许多不同类型的系统中：管理信息系统， 防御系统（飞行员、对抗措施、C3I）和电信系统 （POTS，移动）。在 OOPSLA′87 上展示的是理论，现在 这个想法背后我们有很多实践经验。在这些 五年的用例已经成熟。

因此，用例在很大程度上采用了它们当前的形式（语法和语义） 1992 年之前。那时我们有用例、参与者、用例模型、 关系 “继承” （现在被 “泛化” 取代） 和 <<extend>>。我不喜欢我们今天所说的 <<include>> 依赖性，因为我认为这会损害 通过邀请功能分解进行建模。

为了更加清晰，我们将区分 在用例（作为类的事物）之间，使用 case 和用例的描述。

用例模型的深度在于其用例。每个用例 description 包含以下内容：

1.简要描述

2.控制流

3.基本流和替代流

4.子流（在同一用例描述中的许多地方可重复使用）

5.前提条件和后置条件

然而，用例不仅仅是一种需求技术。

用例可追溯到分析、设计和实施 和测试。对于用例模型中的每个用例，我们创建了一个协作 （参与类的视图）在 Analysis and Design 中。每次使用 case 生成一组测试用例。用例对于 设计用户界面并构建用户手册。使用案例 也进入了商业建模领域，因为他们完美地 与业务流程的定义相匹配。

我们为我们的方法创造了用例驱动开发一词 的软件开发 — 首先确定所有使用案例并指定 他们每个人都在需求中，分析和设计每一个 分别在分析和设计中，最后进行测试 他们中的每一个都在测试中。

我们在 1992 年之前就拥有了这一切！

今天：从那时起

发生了很多事情用例的采用率让我感到惊讶：它们被接受了 几乎立即被所有方法论者采用，并基本上采用 全球。其他重要技术，例如基于组件的设计 和面向对象建模的争议要大得多，也是必要的 采用时间要长得多。这可能是因为用例 基本上是一个简单而明显的想法;它们与对象配合得很好 和对象思维。使用用例不仅仅是一种技术 管理需求，但它将所有活动捆绑在一起 在项目中 - 此项目是否像单个 迭代，或者一个导致新产品发布的主要项目。

当前用例的定义基本上可以追溯到 1994 年。 为了在定义过多或过少的用例之间取得平衡， 我添加了一个要求，即用例必须给出 “可衡量的值” 分配给“特定参与者”。根据经验，我建议 支持一个业务流程的大型系统不应再有 比 20 个用例多。我意识到，给出任何这样的数字 可能会导致人们采取不受欢迎的行动来获得“正确” 数。如果他们的用例少于 20 个，他们可能会拆分一些 他们数到 20 个;或者，如果他们有超过 20 次使用 cases，它们可能会组合单独的用例来计算 的 20 个。但这是错误的方法。我见过很好的用例 适用于商业系统的模型，最少有 5 个用例和一些 有多达 40 个用例。但是，我也看到了用例 具有多达 700 个用例的模型 — 显然这些用例并不可靠 模型。我建议的 20 个用例是具体的（真实的）用例 而不是泛化或扩展/包含片段。

用例已成为统一建模语言 （UML） 的一部分。 因为 UML 是精确定义的，所以用例的含义和 相关概念（例如用例实例 [UCI]）也可以 由于 UML 强大的分类器概念而被精确定义。 我在 1992 年所说的“类”现在可以正式解释了 通过 UML 分类器。我们不再需要只依赖旧的 定义“用例是一系列操作...”虽然 从用户的角度来看，这仍然是一个兼容的定义， 基于分类器的定义是方法论者处理的内容 工程师和工具构建者需要明确。因此，UML 工作 导致了对用例的更精确定义，但它 没有做太多事情来发展它们。粗略地说，我们只改变了 “uses” 关系到泛化，我们添加了

<<include>>。（Objectory 中的“uses”关系以前是 称为 “inheritance”，从未打算用作 <<include>> 片段。过去，我们不允许开发人员对这些 片段，而是使用另一种涉及文本对象的技术; 我们稍后会讨论这些。

我对我们的 Rational Unified Process （RUP） 的方式非常满意 团队正确实施了用例并提高了他们的实用性 用。没有做出真正重大的改变，但用例已经 根据数千人的经验进行进化，以便更好地解释 客户和我们自己的专家。特别是一本新书 Use 由 Kurt Bittner 和 Ian Spence 编写的 Case Modeling3 现已上架。 这是一本关于用例的书。我强烈推荐所有参与者 在软件工程和需求开发中，请阅读它。也 Kelli Houston 的 RUP 在用户体验设计与用例方面的工作 对我们早期在这一领域的工作有很大的改进，并且 与最初的用例概念非常一致。

因此，现在可能是采取一些步骤来发展的时候了（澄清 并扩展）用例的想法。但首先，要提醒一句 关于正式化用例。

正式确定用例时要小心

多年来，人们一直批评用例没有 在 UML 中是一个足够正式的描述。虽然我的几篇论文 讨论正式化用例的技术，例如使用 Sequence 图表来显示参与者如何与用例交互，或使用 用于描述单个用例的活动图或状态图， 我警告不要使用这些技术。毕竟，用例 model 用于与客户和用户进行通信。形式化 用例（使用数学）从来都不是问题。我已经 在 1986 年完成。事实上，任何计算机科学学生都可以做到 它。通过在 UML 中制作用例分类器，您可以使用该工具 正式描述用例，基本上是您想要的任何深度。

然而，困难在于使用 UML 中可用的 最务实的方式。我仍然不愿意建议那个系统 分析师描述用例比以某种文本形式更正式。 避免尝试使用图表指定每个用例的内部结构 例如活动图或状态图。您可以描述 使用序列图的用例和参与者之间的交互 或带有泳道的活动图。我认为有更好的方法 为了更准确地了解需求（使用的内部 case），而不是在 use-case 模型中引入更多形式主义。这 是分析的作用——但这是另一篇论文的主题。

明天：可能的下一步

在过去十年中，用例的编写方式一直保持不变 相当稳定。当然，这些年来我一直想让 改进，然而，一旦讨论了更改，一切都 受到质疑，事情变得太不稳定了。

因此，我觉得保持原样更安全，直到人们变得 更熟悉用例结构。此外，我们需要允许 在现场使用用例及其实施的时间 发展并建立起来。在本节中，我将提出 当前用例应用的几个问题，以及 表示一些建议的更改。

提案的一些背景

软件系统的用例模型基本上包含四种类型 的使用案例：

• 具体用例：可以实例化（抽象的不能）
• 泛化使用案例：支持重用使用案例
• 扩展用例：将行为添加到现有（或假定的 现有）用例，而不更改原始用例
• 包含用例：将行为添加到其他用例中，并执行 所以通过改变它们。

概括

这些用例是具体应用的抽象和概括 案例（通过泛化关系）或其他抽象 使用案例。泛化使用案例（父使用案例）和 它的子用例 （children） 应该属于相同的类型才能服从 可替换性原则 — 您应该能够使用实例 只要您需要 parent的实例。现在，这个 对于用例（或任何状态驱动的分类器）来说并不完全正确， 由于子用例可能需要与 演员。但是，基本思想是相同的：孩子应该是 与父级相同类型 （classification）。例如，Make 本地呼叫 （Local Call） 和拨打唤醒电话 （Make a Wake-Up Call） 均泛化为 抽象用例 拨打电话。

扩展

回想一下，扩展用例有一个非常特殊的用途：它们 将行为添加到现有（或假定的现有）用例中，以及 无需更改 it4。使用扩展是一种获取 易于理解的描述。首先，您描述基本 （强制性） behavior，然后添加额外的（强制或可选）行为 - behavior 这不是理解更基本行为所必需的。以这种方式 您可以从描述一些非常简单的基本行为开始，然后 然后添加越来越多的行为，而不必更改基本功能。 扩展不仅仅是一种描述可选行为的技术 （可选，即从客户的角度来看），它们是 也用于描述结构化 道路。如果没有像 extensions 这样的机制，则 use 的基本流程 case 会变得杂乱无章，而这些语句与 do 使用基本用例，即使这些语句很重要 对于其他用例。

使用扩展的一个潜在问题是创建深层次结构 的扩展依赖性。为了避免这些，我们需要指导方针：我们通常 永远不要扩展扩展 （片段），因为这会使它们 难以理解。

另一个潜在的混淆点是知道何时使用扩展 以及在描述使用案例时何时使用替代路径。再 我们需要指南：我们通常只使用 extend 关系 当扩展用例与扩展 基本用例 — 或者更准确地说，当它是单独的混凝土时 用例本身，或者当它只是一个小片段时也需要 通过另一个用例。基本用例必须单独完成 ，并且不需要扩展。否则，您必须使用 alternative paths 来描述其他行为。

扩展在管理软件开发方面有很大帮助 整个软件开发生命周期。例如，一个大的 可以在不请求回归的情况下添加扩展的类 base 的测试 - 您只需测试 extensions 和 他们与现有基地的合作。让我来限定一下。第一 扩展，因为语言结构需要通过设计传播 和 implementation：它们需要添加到设计模型中， implementation model、可执行代码等。（如需进一步 信息查找 OOSE 书中的 “extends”。二、只有扩展 不访问其他用例的对象（更准确地说，扩展 不修改与其他用例实现共享的对象） 例如，将属于此类。当这些条件 都已满足，我们可以证明某些扩展将无法 损坏现有软件。

早在 1978 年，我在爱立信就提出了扩建的想法。开发 人员 直到 1991 年才接受了这个想法。它们最初发表于 OOPSLA 8656。但这个想法有好处：爱立信甚至申请了专利 以支持扩展。对 C++ 和操作系统的扩展 - 在 事实上，计算机体系结构也是如此 - 是由我们的基础设施建议的 团队。扩建将显著降低开发成本。 进一步的讨论超出了本文的范围，但重点是 就是：不要认为扩展只对用例有用！

我希望在即将发布的面向方面的论文中讨论扩展如何 可以通过使用案例建模以外的活动传播 - 活动 例如分析、设计、实施和测试。这是 我上面说的其实已经在 OOSE 书中描述过了。

包含

当用例诞生时，人们看到了对两种重用的需求。 由于我基于面向对象的用例，因此我看到了巨大的价值 在 subclassing 中，并在 1987 年引入了我们所谓的 “继承” 用例之间的关系。在 1992 年，我们将其从 “uses” 改为 减少“技术”术语，更容易被分析师采用。在 UML 后来被称为“泛化”。另一个重用需求 只是一种分解常见事件流 （共享） 的机制 来自用例描述;对于我们当前使用 <<include>> 关系。这种共享行为就是我 这里称为 Inclusion。

我非常不愿意引入这样的关系，因为 我预见到人们会滥用用例，就像他们那样应用它们 功能分解。事实上，这是对 今天的用例。人们通过使用用例来描述 函数而不是对象，然后归咎于用例概念 为他们的问题。为了解决这个问题，我们引入了另一个想法。 在 Objectory 工具中，我们支持通过 “text objects” 进行重用7， 由一段文本组成的可重用对象。这些文本对象 只能由负责文本对象的人员更改， 而不是由其他人使用（或重复使用）对象。

文本对象可以在多个位置重复使用，例如 用例的不同文本描述。就像 Rose/XDE，它有 每个类的 model 元素可以显示（不同 如果需要），文本对象可以显示在 多个文档。美妙之处在于所有文本对象都是 保存在一个地方，以便于查找、更改和管理它们， 并且所有引用都自动保持同步。非常强大！

我认为我们的解决方案在那个时候是正确的，当时我们 担心用例会被视为另一种方式 功能。这个问题今天在系统分析师中仍然存在，尽管 在方法论者中不是。

两类扩展/包含用例

最初引入扩展用例时，我基本上 只考虑一种扩展或内含物：小的可重用 use-case 片段。我没有预见到能够扩展的必要性 或包括具体的完整用例。这是我们学到的 在实际使用的前四年。很多次 we8 讨论 需要两种扩展用例。然而，我们没有 希望使用例建模更加复杂。在 UML 1.1 期间 我们（主要是 Jim、Gunnar 和我）涉及这个主题的工作，但是 出于同样的原因，我们没有坚持下去。也许现在是时候了？

有两类扩展/包含用例：

1. 它们本身就是具体的（完整的）用例
2. 它们只是用例的片段

扩展/包含本身就是具体的用例。 这些用例与 Actor 交互，可以说提供了 值。例如9，考虑一个“监视”系统 报告入侵者。基础（具体用例）监控 监视区域，甚至可能做一些其他工作，例如 保持恒定的建筑温度。扩展用例 （也是一个具体用例）报告异常事件 - 安全漏洞 或火灾 - 向有关当局（警察、消防、建筑物 管理）。这表明基本用例具有一些重要的 行为，扩展用例也是如此 - 它们都是具体的 用例，它们都可以实例化。

扩展/包含只是用例的片段。这 是一类大得多的用例，但每个成员通常都非常 小。这些用例是抽象的，因为它们无法实例化 分别。其他一些用例（通常是混凝土）需要它们 或泛化使用案例。例如，在图 2 中，假设 基本用例是银行事务 Conduct Transaction。每 当交易失败时，银行希望将此事件注册到 使其可用于其他一些具体用例，在本例中为 管理使用案例 Inspect Transaction Failures。一个明显的 传统的解决方案是更改事务用例 因此在其描述中明确显示失败消息 已注册。但是，这需要更改 base 并使理解复杂化。更改无关 基本用例 Conduct Transaction;它只是为了注册 一些信息传递给其他用例。这样的更改可能不是 令人不安，但当你有好几个时，它就会变得相当 混乱。为了避免使基础混乱，我们改用扩展 Use cases 在基本用例之上添加更改。我们会 添加第三个使用案例 — 一个名为 Register 的非常小的使用案例片段 失败。以类似的方式，我们可能有像 在两个或多个具体之间共享的包含用例 使用案例。假设 Validate User 就是这样一个包含的用例 fragment（与其他一些实际用例共享）。

具体和抽象用例 用例的一部分 模型，其中包含两个具体的用例：Conduct Transaction 和 Inspect 引入了具体用例 Inspect 之间的依赖关系

我引入了具体用例 Inspect 之间的依赖关系 Transaction Failures 和扩展用例 Register Failures。 由于此依赖项是特殊的，并且只需要将 extension fragment 添加到需要它的用例中，它可能是一个不错的 定义唯一依赖项构造型的想法（也许是 <<need>>？ 为了它。但这是一个单独的问题。

第一类用例（本身就是具体的用例）是 好吧，我们不需要对它做任何特别的事情。混凝土用途 案例可以扩展基本用例或包含在基本用例中。

第二类用例 — 用例碎片，正如我将的那样 呼叫他们 - 将讨论扩展和包含用例 很多共同点 ing 的 “执行” 是 s 的主要区别 在扩展和包含用例之间是用例的方式 实例

- 在包含的情况下，基流本身会明确指示 用于遵守包含用例的实例。

- 在扩展的情况下，基本流不指定中断， 相反，扩展用例指定了基本用例中的位置 用例实例应进行中断。

扩展用例引用了一个扩展点，该扩展点指定了 基本用例中的唯一位置。在 OOSE 和 Objectory 中，扩展 points 属于 Extending 用例。在 UML 1.1 的工作中 Jim Rumbaugh 建议扩展点应该属于 扩展用例。论点是封装——扩展 用例不应看到基本用例的详细信息，而只看到 扩展点。如果您更改扩展用例，则仅更改 用例会知道新位置。我同意他的观点。

因此，扩展和包含用例非常相似;事实上 它们可以被认为是彼此的反面。实际上，当 在 UML 1.1 上，Jim 和我讨论过这个 shoube 反映了 在两个依赖项的命名方式中。然而，他并没有疯 关于我的提案，<<include>> 应该命名为 <<inverse extend>>，而且我认为没有人会是。

感谢 1981 年对 SDL 的工作，以及现在的 UML，我们取得了 在开发更精确的建模语言方面大有帮助。

很简单：古典语言规范 （1） 从 一个具体的句法结构 （a ch ents e ince fragments are NOT 用例，则它们不应由 use-case 语法表示。 它，我对新的符号元素有什么好的提议 应该看起来像这样。建议图 3.适当地处理片段 - 作为 Tiny Elements

表示法元素），即 （2） 映射到抽象 syntactic 结构，而 whiin 又 （3） 映射到语义 元素。语义指定语法的含义。最 有趣的句法结构具有独特的语义对应关系。 （反之亦然，因为设计的语言 通常有很多 semantic elem[dynamic semantics] 没有 句法对应。因此我认为它是标准语言 设计实践，使每个独特的语义元素都可以映射 独特的语法结构。自然语言要复杂得多， 但是由于我们自己正在创建 thUML 语言，因此我们不需要 使事情复杂化。

S

使分析人员更难区分重要元素。 碎片应该被当作它们应该被对待的方式对待——更少 比实际用例重要。

N

个东西，我选择了一个图标来表示一个微小的元素 — 一个 点。但是，指示 fragment 的图标会更直观。 图 3 是我所指的一个例子。

ConductTransactionInspect TransactionFailures<<extend>><<include>>Validate 用户

Register Failures 片段（参见图 2）已折叠为 dot 及其名称包含 tion，l he dot 表示扩展 fragment — 寄存器失败 fragment — 我们将其称为 “E”。E 是他 点将展开（通过“单击点”）到新的区间 的用例。我们这个例子中只有一个扩展 （注册 Failures） 需要 Inspect Transaction e ometimes an extension fragment 的实例。在这些 所有 N igure 3 的情况 g 也有一个包含片段 — 验证 User 片段。包含片段在这里是一个重要的 包涵片段和扩展片段之间的区别： ?包含片段将由用例实例 “执行” 那也 “执行” ？扩展片段将被 “执行” by a use case instance 消失的用例以外的使用案例。这 点的语义是，在执行 Conduct Transacwhen 到达扩展点时，点指定的东西将 happen：将执行扩展。检查事务失败 用例将使用扩展来履行其职责。

T

不是实际用例的一部分 Inspect Transaction Failures（称为 UC2） 的 Alpha Server S Package。由于 E 仅由 UC2 需要，因此我们 不需要给它起个名字。相反，我们通过将 用例符号的点。但是，必须清楚的是， 需要扩展名 E 的用例 （UC2） 不<<extend>> 另一个基本用例 Conduct Transaction （UC1） 或扩展 E.因此，从语言的角度来看，这是完全错误的 将用例 UC2 <<extend>> UC1.不带点 或类似的东西，我们就无法正确解释 所需的语义。

T

可以命名新的 compartment “Extensions”，并使用它来描述 用例所需的扩展。

在

失败中。因此，在 Inspect Transaction 的扩展隔间中 失败，我们将描述 Register Failures 用例。由于我们 只有一个扩展名，我们没有命名它，但如果有多个 扩展，我们可以命名这些点。

S

扩展片段必须在用例中唯一命名 型。扩展片段中的点 representin 必须是 “free” 来自一个特定的用例，但相关（通过依赖项 — 最好是 使用新的刻板印象<<需要>>或类似的东西）使用 需要它的情况。此类扩展片段是一种 的分类器具有 extensiocompartment。

F

不是真实的用例;它们是可重复使用的用例描述 或“文本对象”。包含片段是独立于 包含它们的用例，因此它们在语义上相似 扩展几个实际用例所需的片段。

T

实际用例（包含它的用例）。

这需要它。

对于 UML 术语，片段应该是带有符号的分类器 这让我们思考一些微小的事情——但现在我太深入了 本文的目的。我们还需要一个语法快捷方式 （syntactic sugar） 将 fragment 附加到具体用例。我们仍然需要 以务实的方式使用 fragment。

后天：使用案例的未来

多年来，有许多改进用例的想法。 有很多想法，我不知道它们都知道，但我会列出来 下面介绍其中一些，并介绍其他一些。我无法克制 讨论我最兴奋的那些：制作用例代码 模块，通过面向方面的编程和制作用例 运行时实体。以下是“未来”的可能方向 的使用案例：

• 刻板印象用例

有多种方法可以对使用案例进行分类。有 primary、secondary、 等用例;有业务用例、软件用例、 系统用例等;业务用例是支持、管理 或操作 10， ...刻板印象是一种用于分类的 UML 机制 这将有助于开发人员对用例进行建模。

• 阐明模式和用例之间的关系

许多设计模式是可重用使用的 “模板” 实现 例。这种模式通常使用 sequence diagrams 来描述 或协作图。模式是一般 问题，并且可以应用于不同的上下文。因此 模式与通用、可重用之间的有趣关系 指定问题的用例。澄清这种关系 对开发人员非常有帮助。

• 在人机交互 （HCI） 中使用用例

人机交互是一门科学。有一种方法可以设计用户体验 通过了解用户社区、其习惯和隐喻。 通过与以下公司合作，我接触到了这项技术 正在为庞大的用户社区开发大型商业网站。 用例将是集成软件开发的一个重要概念 和 HCI 方法。

• 基于使用案例的成本估算

1994 年，马格努斯·克里斯特森 （Magnus Christerson） 领导了古斯塔夫·卡纳 （Gustaf Karner） 的硕士论文11， 这导致了一篇关于基于用例的项目估算的论文 点（派生自功能点）。据我所知，这仍然是 一篇有趣的论文。凭借我们今天的所有经验 用例和项目估算，我们应该能够实现现代化 这些想法。

• 可重用的用例

这是一个巨大的话题。商业软件的重用应该从 了解其使用案例 — 业务的使用案例， 以及要使用的软件的用例。这就是深度 我与 Martin Griss 一起编写的《软件重用》一书12 以及 帕特里克·琼森 （Patrik Jonsson） 回到 1994-97 年。它在今天比以往任何时候都更加重要 当公司的 IT 支持是通过集成企业应用程序构建时， 无论这些是遗留系统、打包解决方案、新应用程序、 或 Web 服务。进一步的讨论可以在我的 RUC 2002 中找到 演讲 “缩小差距：业务驱动的企业应用程序集成”。 （我很乐意将此发送给 Rational 员工。

使用例场景成为一等公民

能够识别和列举用例会很有帮助 方案，并显示这些方案之间的依赖关系。召回 场景是我们选择建模的用例实例。 这可能更像是一个流程问题，而不是语言问题。 可能有多种依赖项。

迭代依赖关系

每个项目迭代都由许多用例场景驱动。 通常，一个用例不会在单个迭代中完成，而是 经过多次迭代进行。我希望能够 展示迭代如何由场景组成，场景如何增长 经过多次迭代，以及几种不同的场景如何 多次迭代共同构成了一个完整的用例。您应该 例如，能够表明您可能必须减少开发 重要场景 先 只是为了能够发展 更重要 实例。举个具体的例子，你可能需要先开发 允许电话系统操作员进行 在订户可以拨打任何电话之前，订户是有效用户 调用。

测试用例依赖项

方案之间的依赖关系还有其他原因。一 用于测试。集成测试是逐个测试构建的 case 的构建方式与构建迭代的方式非常相似。

我们将能够将用例场景跟踪到测试用例。一个好的 use-case scenario 是一个很好的测试用例。之间的关系 用例方法和测试优先方法将变得更加 精简。

用例和面向方面的编程

当今最令人兴奋的“新”运动之一是面向方面的 编程 （AOP）。AOP 是 OOPSLA 的年度流行语。和 理由非常充分。本文无法深入探讨 AOP 的但是，我不能不给出一些提示，为什么 AOP 会 让未来的用例变得精彩。扩展的整个想法 用例，即向现有系统添加行为，而无需 改变它，与 aspects 的整个想法非常相似。使用案例 实现作为 Aspects 实现。扩展用例将 作为方面实现。扩展点在语义上相似 以连接点。

使用 RUP 时，在每次迭代中，我们指定用例， 我们设计它们，并测试它们。在设计和测试之间，我们必须 中断用例流程，以便设计、编码和测试 共同实现用例的组件。使用 AOP 将简化 即：我们将直接从用例设计转到用例编程 然后进行用例测试。组件的工作将得到支持 通过我们的编程环境（AOPL = OOPL + 方面）。因此 AOP 允许我们无缝地实现用例。

既不是用例驱动的开发，也不是面向方面的编程 是灵丹妙药。它们仅代表两种最佳实践。然而 我相信整合它们将极大地改善方式 软件。

使用例成为运行时实体

最令人兴奋的用例未来是它们还将拥有 运行时环境中的对应项。能够识别 在操作中执行用例（实际上是用例实例） 系统可以帮助我们实现许多重要的功能，如 我 1985 年的论文13，它有一个语义结构，表示 use-case 实例。用例实例是由外部 事件，它存在于与用户的整个交互过程中（例如 在电话呼叫期间），并且它跟踪了所有 参与了 use-case 实例。有了这样的结构，我们 可以更增量地更改已安装的软件 - 一次使用 case 实例。软件系统可以重新启动 在更小的步骤中，在大多数情况下，只需重新启动用例 实例。而且，我们可以简化编程 的用例。使用 AOP，我们可以实现其中的一部分。看起来 我们至少会实现面向用例的编程。?

最后的话

使用案例现在已经存在超过 15 年。我们可以移动 通过清理一些小缺陷，他们向前迈进了一步：通过分离 用例和 fragments。这可以明天完成。

后天，有许多有趣的想法可以扩展 在用例上。我们的许多想法只是边际改进。 然而，其中两个想法是戏剧性的增强：利用 case 对模块进行编码，并使它们成为可执行的运行时实体。

在那之前，请享受今天的用例！