前言
不久前，还没有关于面向对象分析和设计的书籍。现在，这类书籍多到任何从业者都无法全部跟上。大多数这些书籍专注于教授一种表示法，提出一种简单的建模过程，并用几个简单的例子来说明。《分析模式：可复用的对象模型》是一本不同类型的书。它不聚焦于过程------如何做建模，而是专注于过程的结果------模型本身。
我是一名信息系统的对象建模顾问。客户请我培训员工建模并在项目上提供指导。我的许多技艺来自我对建模技术及其用法的了解。然而，更重要的是我的经验：我实际创建了许多模型，并定期看到问题重复出现。我经常发现，我在一个项目的许多方面又遇到了以前曾经面对的问题。这种经验让我能够复用之前构建的模型，改进它们，让它们适应新的需要。
在过去的几年里，越来越多的人也意识到了这个现象。我们认识到，典型的方法学书籍虽然有价值，但仅仅是学习过程的第一步。学习过程还必须要有实际构建的东西。这个认识催生了模式运动。参与模式运动的人多种多样，代表许多不同的兴趣和观点，但有一个目标是一样的：传播有用的软件系统模式。
由于这个模式社群的多样性，我们在定义术语"模式"时遇到了困难。我们都认为我们可以在看到模式时识别它，我们认为大多数情况下我们的意见会一致，但我们无法提出一个单一的定义。以下是我的定义：模式是一种思路，它已经在一个实际上下文中发挥作用，并且可能在其他上下文中也会发挥作用。
我喜欢把这个定义留得十分宽松，因为我希望尽可能接近模式的根本动机，而不添加过多的限制性修正。模式可以有多种形式，每种形式都增加了对该种模式有用的特化（specialization）。（1.2节讨论了模式界的现状以及本书在其中的位置。）
本书讲述分析中的模式，这些模式反映了业务流程概念结构，而不是实际的软件实现。大多数章节讨论的是各种业务领域的模式。这些模式很难分类到传统的垂直领域（制造、金融、医疗保健等）中，因为它们通常在几个领域中都有用。这些模式很重要，因为它们帮助我们理解人们如何看待世界。基于这种认知来设计计算机系统------其实就是为了改变这种认知------是有价值的，这也是业务流程再造（BPR）所要做的。
然而，概念模式不能孤立存在。只有当软件工程师能看到如何实现它们时，概念模型才有用。在本书中，我介绍了可用于将概念模型转化为软件的模式，并讨论了该软件如何融入大型信息系统的架构中。我还讨论了与这些模式相关的具体实现小技巧。
我写这本书的原因是，我在刚入行时就想读这样的书。建模人员会在本书中发现一些想法，帮助他们在新领域开始工作。本书的模式包含有用的模型、其设计背后的理由，以及它们什么时候适用，什么时候不适用。有了这些信息，建模人员可以调整模型以适应具体问题。
本书中的模式也可以用于评审模型------看看可能遗漏了什么，并建议一些可能带来改进的替代方案。当我评审一个项目时，通常会将我所见到的与与我从以前工作中学到的模式相比较。我发现，意识到工作中的模式有助于我更容易地应用过去的经验。像这样的模式还揭示了超出简单教科书所能涵盖的建模问题。通过讨论我们为何以这样的方式建模，我们可以更好地理解如何改进我们的建模，即使我们不直接使用这些模式。