前言

1995年，Eric Gamma等人出版了他们在软件领域极富创造力的书籍Design Patterns （Addison-Wesley出版社出版），该书引入了当今软件行业一个最重要的概念：设计模式。在那时，面向对象设计已使用了几十年，并且有了组织出色的面向对象设计的知识，在书中将有正式的描述。今天，其他的书籍又增加了好的（和差的）设计模式。

我所从事的关于用例方面的工作最初是在1986年。起初他们的目的是双重的：为了能够与业务人员讨论系统用法，同时为了向设计者解释类和组件如何协作提供所需的系统功能。今天，用例已经成为了软件开发的基础之一。它们是至关重要的，不仅是为了捕获需求，而且还为了定义系统结构并对其进行测试。与面向方面结合，它们甚至可以用于程序设计。

到如今，用例已经存在并使用了足够长的时间，可以制订成熟软件开发规则，并且到了在下一级别采用用例建模的时候了。这包括建立标准建模问题的标准解决方案以及建立公共的模式词汇表。本书由两位最富有经验的用例建模者编写，为该目标做出了非常有价值的贡献。没有人像Gunnar和Karin在本书中那样对用例模式进行如此深刻的分析，他们将所有潜在的东西都变成了标准的参考。

本书囊括了每个人都会在其模型中使用的几个基本模式，以及一些用于比较特殊的模型和领域的较高级的模式。用例建模新手和专家都可以找到他们模型中要应用的模式和模型实例。

为了使本书更加有用，Gunnar和Karin不仅定义了大量的用例模式和在用例模型中如何建模的特殊用法实例，他们还提供了在用例建模中使用的精确、完整，并且是易于理解的描述。

我为Gunnar和Karin自从用例研究开始以来就在我的组里而感到骄傲。本书给我留下了深刻印象。

——Ivar Jacobson, Jaczone AB （咨询部成员）

Ivar Jacobson 咨询公司（创建者）

ivar@jacobson.com

序言

收集模型和设计

本书的目标是与大家分享我们在三十多年用例工作经验中所获得的一些经验。多年来，我们作为用例建模者和用例评论者、导师参与过上百个用例模型的开发。这些当然给我们提供了许多关于用例如何建模以及如何组织和描述好的用例模型的知识。

我们所发现的明显情形是，因为许多函数在多重系统中的重复出现，导致或多或少的相同建模问题会一次又一次出现。研究这些函数如何在多重系统用例模型中表示将导致许多有趣的结果。我们发现，比如说，这些模型中有些模型比另一些模型更容易被理解和维护，就开始分析其原因。我们还注意到有些模型，尽管它们似乎易于理解，由于其过于单纯化，我们并不能完全捕获预期意义。

在过去这段时间，我们经常和其他一些参与者进行大量的讨论，分析系统的某些使用方式应该或不应该以特殊的方式建模的原因。我们再三讨论过，在用例模型中以各种方式对特定用法的不同方面进行建模，以使得其是正确的、可理解的和可维护的。什么是重要的参数，以及什么没有重大的影响？随着时间过去，我们目睹了很多公有用例建模问题的一般解决方案，此类问题是根据许多这种重复产生的系统使用功能或方式中的好模型建模的。我们决定以组成这些一般方案的用例模型片断为用例蓝图。

很快，我们同时认识到某些方案可以被更深地归纳。所建模的特定用法是一些通用的、应该独立实现的底层设计规则。根据用例建模的基本定义应用这些设计规则或用例模式使得模型更加易于理解、更加易于维护，并且实际上通常还会更正确。

多年来，许多人曾建议我们将所获得的经验写出来。本书就是我们努力这样做的结果，本书介绍和描述了我们所掌握的几个模式和蓝图。目录绝对不是完整的，因此可能没有包括你喜欢的模式或蓝图。然而，我们相信组合列表对多数用例建模者是有用的，包括初学者和有经验的建模者。

一个在用例模型领域工作如此长时间的人不可能不注意到重复出现的好方案，也不可能不注意到用例模型中反复出现的错误。因此，我们在书中包括了一个普通用例建模错误的集合，希望对建模者和用例模型评论家有用。

我们希望本书可以成为用例建模团体内部日趋增长的共享知识和词汇量的一个起始点。因此，如果你发现某些特殊的模式和蓝图是有用的，但是本书中没有讲述，或者如果你有愿意和建模领域其他人分享的建模问题，请告诉我们。我们同时将感激你为本书目录及其内容提供的任何反馈意见。

没有Christopher Alexander及其在设计结构时（Alexander、Ishikawa、Silverstein 1977）确定和描述模式方面的极富创造力的工作，要编写一本关于模式的书是不可能的。他是一名建筑物的建筑师，在工作同时，他和他的同事研究和记录那些用于通常被认为是高质量的建筑物的模式。

20年后，模式成为了软件开发领域确定和重要的概念。在他们的初创书籍Design Patterns（Gamma等人1995年著），E. Gamma等人介绍了软件系统面向对象设计的模式集合。今天，模式在软件开发中使用相当广泛，你可以找到很多关于该主题的书籍。Pattern-Oriented Software Architecture, Volume 1:A System of Patterns（Busch mann等人1996年著）描述了软件体系结构的不同模式。M. Fowler 著了一本书名为Patterns of Enterprise Application Architecture（Fowler 2002），书中讨论了用于开发企业体系结构的模式。S. Adolph和P. Bramble所著的Patterns for Effective Use Cases（Adolph和Bramble 2002）讨论了开发用例模型过程中出现的模式。有些书籍是关于特定语言和标准的模式，例如M. Grand的Java：A Catalog of Reusable Design Patterns Illustrated with UML（Grand 2002）；F. Marinescu 的EJB Design Patterns:Advanced Patterns, Processes, and Idioms（Marinescu 2002）；以及D. Alur等人的         Core J2EE Patterns:Best Practices and Design Strategies（Alur、Malks和Crupi 2003）。模式也定义于特定的领域，例如安全领域。Open Group有一本书Security Design Patterns（Open Group 2004），书中定义了软件安全方面的不同模式。事实上，模式不仅用于定义好的设计，还用于定义应该避免的差的设计，可参考W. Brown等人的AntiPatterns:Refactoring Software, Architectures, and Projects in Crisis（Brown等人 1998）。

关于本书

本书提供从我们总共三十多年来在用例方面工作所碰到的大量用例模型中提取的用例模式和蓝图集合。虽然我们并不认为每个模式和蓝图都与所有的系统有关，但是本书没有集中于特定的领域或技术。本书针对用例建模者，例如软件工程师、开发者、系统分析师和需求规定者。其他人，包括管理人员、消费者和学生，所有想要开发、评论、批准和学习关于用例和高质量用例模型的人都可以从本书获益。

通过使用本书提到的模式和蓝图，工程可以节省用于找到如何以用例表达系统用法的时间，也可以节省决定如何构造和描述这些用例的时间。会节省用于开发用例模型的时间是因为不用再次创造模型，并且由于模型已经用于证明过的方案中，其质量也会得到提高。另外，如果用例模型是基于众所周知的技术和方案的，它将会更加易于阅读和理解。而且，由于每个模型和蓝图有给定的描述名字，我们希望用例建模者能获得一个公共的词汇表。

因此，这并不仅是一本描述用例的书。本书也不是一般的关于捕获需求的书。本书的主要目的是提供一个有用的用例模型和蓝图的集合。然而，为了完备，本书还包括了一些详细的描述、关于什么是用例，还有哪些结构可用于用例模型以及其含义是什么。本书使用的结构和图是与UML 2.0（对象管理小组 2003）中的定义一致的。我们还将描述一些文档记录用例的方法。不过，因为提供另一本关于用例的教材并不是我们的目的，我们在本书中并没有包括用例建模的特定方面。例如，我们没有提供描述用例的几种技术。此外，我们没有集中于通常的如何确定用例、如何在包中组织用例或者如何构造提供用例模型的图。关于这些内容，我们建议参考其他相关主题的书籍。在K. Bittner和I. Spence的Use Case Modeling（Bittner和Spence 2002）中，给出了用例概念以及如何使用的详细介绍。Schneider和Winters的Applying Use Cases:A Practical Guide（Schneider和Winters 2001）是另一本介绍用例的好书。A. Cockburn的Writing Effective Use Cases（Cockburn 2000年）提供了关于如何描述用例和如何确保用例都是在同一提取级别的详细讨论。

本书中，我们以实际方法讲述用例建模。毕竟，项目的主要目标是产生系统的新版本。不过，由于用例模型用于作为许多不同方案的基础，例如签署一份协议或开发一个系统的设计，用例模型的含义必须是清晰的。因此，有些模式和蓝图将导致比其他书籍或例子中所见到的更详细和复杂的模型。显然，我们首选的是正确性而不是简单化，但是尽管如此，本书中所有的例子都是我们希望找到的现实生活用例模型。

本书的模式与Design Patterns（Gamma等 1995年）中描述的模式有一些相同之处，因为它们都描述公共情形的建模。不过，Design Patterns是关于面向对象的设计，而本书集中于用例。但是，两本书中复用方面的内容是相同的。因而，本书解释许多系统中发现的用法如何由用例建模。

就其本质而言，用例建模和随之产生的用例模型不如设计建模和设计模型正式。这个差别对用例模式和设计模式的比较来说是明显的。尽管有必要达成某一级别的正式手续来完成对模式共同理解的目标，但同时也有必要确保用例建模在系统开发初期为没有经过技术训练的人保留一个有用的工具。因此，已经熟悉设计模式的读者可能会发现本书中模式的定义是很松散的，同时一个有经验的用例建模者可能发现它们被描述得很正式。

本书的组织

本书由5个部分组成。

在第一部分“导言”中，我们给读者介绍用例模式和蓝图的思想。还将提供一个小的模型实例来说明在开发系统的用例模型时如何应用，以及说明通过使用模式和蓝图的目录可以获得什么。

本书的第二部分“用例”，提供了用例结构和特定于某个用例模型的其他结构的全面描述。该部分最后一章讲述了用例在类的方面如何实现，因为如果读者要理解模式和蓝图描述的相应部分，关于这个的基本知识是必要的。本书包括第二部分是为了使其更加完备，让读者不用去寻找另一本书来理解用于模式的结构，同时还提供了我们所使用的不同结构的精确定义。

本书的主要部分是第三部分“用例模式”和第四部分“用例蓝图”，也是我们编写本书的真正目的。这里你将找到适用于不同种类应用领域用例模型的27种不同的用例模式和30种用例蓝图。

我们将相关的模式或蓝图按章节分组以使得它们可以被一起讨论，同时让读者易于查找相关的模式或蓝图。每章有一个名字和简短的说明来描述该章要讲述的模式或蓝图的目的或建模问题。接着列举该章的模式或蓝图及其在用例模型中如何表示和何时应用的描述。然后是模式或蓝图的详细讨论，以及为什么它们可以构成好的用例模型，并举例说明，还包括所涉及的用例的用例描述。最后部分将讲述如何在逻辑类模型中实现模式或蓝图中的用例。

我们还在第五部分“常见错误”列举几个常见用例建模错误，也就是不应该出现在用例模型中的方案。每个这样的常见错误有一个名字和不正确模型的简短描述，以及为什么该模型不是好的用例模型的解释。接着是关于如何改善模型的建议的讨论。

关于模式和蓝图

不管你在用例方面有什么知识和经验，尽管有些似乎是没意思的，甚至与你完全无关，我们还是希望你能找到一些有价值的模式和蓝图。不过，不同的读者很可能找到不同的有用子集，这依赖于他们不同的经验、问题领域以及应用和建模知识。

此外，由于我们不知道一个特定项目或系统的所有特定需求，你可能会遇到一些建模情形能以与这些模式和蓝图不同的更好的方式表示。当然，这是一个关于模式和蓝图的普通问题，对用例建模也不例外。尽管如此，它仍是要紧记的内容。

本书所介绍的模式和蓝图集合不是彻底的，还存在其他一些有用的和有价值的。我们再次鼓励你对本书所介绍的内容提供反馈意见，对我们所选择的实例提出批评，告诉我们关于模式和蓝图的新的应用，并对你认为其他应该包括的内容提出建议。

关于示例

本书所介绍用例描述的目的是，通过给出模式和蓝图的具体示例来实现对它们的理解。尽管在对理解模式和蓝图不必要的细节和功能方面做了一些简化，这些用例描述都是我们将在工业项目中发现的。另外，因为我们不希望例子由于异常和错误处理而有分歧，二中择一的方案总是比正常的方案较少和较简短。

因为我们认为没有一个领域包括所有必需的例子，所以我们将从几个不同的领域抽取这些例子。但是，这并不意味着这些模式和蓝图例子仅仅适用于所属领域的系统。事实上，我们在几个不同领域中见到了本书的所有模式和蓝图。

此外，我们认识到相似的系统其细节也是不同的，并且我们认为同一类型和有着相同目的功能的系统在不同的组织和世界上不同的地方也是有差别的。 

我们希望读者会看到例子是用于什么的--即模式和蓝图的例子，而不是具有代表性的系统的一部分。

如何使用本书

首先，我们坚持建议你对本书不要只读一遍。相反，我们希望你会反复阅读本书并将其作为目录册反复使用，从中受到启示，将其作为你工作的参考和催化剂。

我们关于如何使用本书的建议依赖于你以前在用例方面的经验。

如果你是一名有经验的用例建模者

作为一名有经验的用例建模者，你应该从第一部分开始。该部分包含两章，介绍我们所谓的用例模式和用例蓝图的概念，并给出如何应用的例子。

作为一名有经验的用例建模者，你或许可以跳过覆盖用例模型中不同结构的本书第二部分，而直接阅读第三到第五部分，这些部分包括用例模式、蓝图和常见错误。

我们推荐你在钻研不同的模式、蓝图和常见错误之前阅读每个目录的导言部分来得到该部分结构的概况。

我们不希望你在第1次就阅读目录中每个模式、蓝图和常见错误的所有细节。相反，你应该集中于那些与你的经验和手边项目相关的内容。不过，我们推荐你阅读第三到第五部分所有章节的导言部分来获得你可以从本书找到内容的总览。这意味着对每个模式章节，你应该阅读它的“目的”和“模式”部分；对蓝图，则阅读“问题”和“蓝图”部分；而对常见错误，则是“错误”和“不正确的模型”部分。

如果你是一名初学者或者没有用例实践方面经验的人

如果你是用例建模方面的新手，你需要在学习模式和蓝图之前了解什么是用例以及用例是干什么用的。这意味着要以与有经验的读者不同的途径来阅读本书。

作为介绍，你可以从阅读第2章开始，该节清晰地描述了一个小型Internet银行系统，并介绍了该系统的完整模型。目前，你可以跳过第2章其余部分，这些部分是分析该系统用例模型的一些用例模式和用例蓝图的应用的。

接着你应该集中于本书的第二部分，该部分描述了用例的基本原理。第3～5章给出你将需要的用例和参与者方面的所有信息。同时你应该熟悉用例建模中不同类型的关联，以及如何描述用例；因此，你应该阅读第6～14章。不过，此时你不需要详细研究这些内容。如果你要应用（模式和蓝图中使用的）关联，你可以返回这些章节以参考它们。

当你理解什么是用例建模以后，你可以阅读本书的第三到第五部分来理解不同的用例模式、蓝图和常见错误。不过，在阅读这几部分之前，返回到第一部分并阅读第1章和整个第2章来理解什么是用例模式和蓝图，以及如何区别模式和蓝图，可能会在开发用例模型时有用。

如果你不是一名设计者

通常，如果你不是设计者、软件设计师或其他对系统内部结构感兴趣的人，你可以跳过第二部分的第15章以及第三到第四部分中每章的“分析模型”节。

本书的将来用途

阅读完本书之后，在你将来开发用例模型的任务中可将其作为字典和知识库来使用--查找你在用例建模中使用的感觉不确定的不同结构，以及查找你的模型中可能应用的不同模式和蓝图。

用例的历史

use-case（瑞典语：anv?ndningsfall [anvзndni?s'fal]）概念由Ivar Jacobson发明，由于需要描述复杂的电信系统中完整的动作序列，而不仅是组成系统的组件。该术语创造于1986年，但是其概念在此之前被提出过（例如，在他的博士论文（Jacobson 1985）中，研究了大型实时系统建模的概念）。在Ivar Jacobson的论文中，定义了一个被称为course的概念，和今天的用例实例（use-case instance）概念非常相似。1987年，当Jacobson在OOPSLA '87会议（Jacobson 1987）提出关于用例概念论文的时候，该概念受到了广泛的关注。该论文中所介绍的用例定义与今天该概念的定义是基本相同的。

1987年，Ivar Jacobson创立了一个开发Objectory软件开发过程的公司。（本书作者之一当年加入了该公司，其他的作者于1989年加入。）用例概念在Objectory中有非常详细的描述，现在做了稍微的修改和增强。例如，用例模型中不再包括类建模域对象（domain objects）。extend关联已经存在，但是那时候将被称为builtOn。

在接下来的两年中，引入了一般化（generalization）关联（第1次被称为继承（inherita- nce），接着改为uses，因为它包括传统的继承更多的内容），还定义了3种不同的分析类及其不同种类的关联。1992年，书Object-Oriented Software Engineering:A Use-Case Driven Approach（Acobson等 1992）出版，该书为广大读者介绍了用例驱动的方法。另一本书The Object Advantage（Jacobson、Ericsson和Jacobson 1994），说明了用例如何用于模拟业务。

在Rational公司收购Ivar Jacobson的公司之后，Objectory过程第1次变成ROP（Rational Objectory过程），接着变成RUP（Rational Unified过程）（Kroll和Kruchten 2003；Rational软件公司 2003）。在这一时期，发起了统一建模语言（Unified Modeling Language, UML）的开发。它包含用例定义的很小改变。用例之间以前被称为uses的关联被分成了两个关联：一般化（generalization）和包含（include）。然而，用于用例建模的所有其他概念都保持相同（Object Management Group 1997；Rumbaugh、Jacobson和Booch 1999）。UML的最新版本称为UML2.0，其中的用例概念还是相同的（Object Management Group 2003）。

因此，正如Ivar Jacobson所指出的那样，用例概念的多数定义在1992年建立（Jacobson 2003）。实际情况是，用例是UML中的主要概念，是多数软件开发项目的基础，由数千建模者在成百个建模成果中使用，用例建模成为了建模系统如何使用的可靠技术。

致谢

在本书编写过程中得到了很多人的启发和鼓励。首先，我们要感谢Ivar Jacobson在20世纪80年代给我们介绍用例。我们与他有很多启发性的和鼓舞的讨论，都是关于用例为什么应该或不应该以特殊方式定义、建模和描述。没有他的极富创造力的工作，现代软件不会发展到今天这个程度。

我们特别要感谢Steve Berczuk、Katarina J?nsson、Neil Harrison和 Bengt ?vergaard，他们提出了关于如何改善本书及其内容的许多有价值的注释和建议。

我们还要感谢Christian Averskog、Karl Dickson、Erik Lindahl和Dan St?hlberg，他们为本书的草稿提出了建设性的评论；以及感谢Christina Skaskiw，是他促使我们编写了本书。

我们对Gerd ?vergaard帮助我们使得原文更出色和更正确所做的无价的努力，以及 Westin为本书的艺术工作所做贡献表示感激。没有他们两个，本书将会更枯燥和无趣。

我们还对Addison-Wesley的小组成员的所有帮助和忍耐表示感激，尤其是John Neidhart、Lori Lyons和Keith Cline。

不必说，我们还要深深感谢这些年来所有提供反馈和共享他们用例建模方面经验        的人。

最后，没有我们家庭成员Maria、Vidar、Johan、Viktor和Hanna的忍耐和支持，就没有这本关于用例模式和蓝图的书籍。

Gunnar ?vergaard和 Karin Palmkvist

斯德哥尔摩，瑞典

2004年7月

IV    序言

序言    V