分析模式：可重用对象模型（笔记版）.doc

分析模式：可重用对象模型（笔记版） 作者：Martin Fowler ADDISON-WESLEY 1997 整理：Windy J（2001/2/14） 注：本文采用意译的方法，重在表达原文的意思，而不是逐字逐句的翻译，如有错误，请指正。 前言 不久以前市面上还没有关于面向对象分析和设计的书籍，但现在这类的书非常多以至于人们无法全部一一掌握他们。大部分的这些书致力于讲解一种注记方法，介绍一个简单的建模过程，并提供一些简例来说明。但分析模式：可重用对象模型显然不同，它关注的主要是建模的结果——那些模型本身，而不是关注建模过程——怎样建模。 我是一个信息系统面向对象建模咨询/顾问人员，为客户提供建模人员培训和项目指导。我的绝大部分经验来自建模技术知识和怎样运用它们。不过，更重要的是我在实际建模中的经验，以及看到问题经常会重复出现，正是因为这样我可以重用以前建立的模型，改进它们，并用于新的要求。 最近几年越来越多的人们发现了这一现象。我们意识到典型的方法学的书，尽管很有价值，却只提出了学习过程的第一步，这样的学习过程，还必须捕捉实际的事物本身。这样的意识发展成为了“模式（Patterns）”运动，但是怎样给模式下一个唯一的定义呢？我的定义是：模式是一种思想，它已经适用于一个实践环境中，并有可能适用于其他的环境。（A pattern is an idea that has been useful in one practical context and will probably be useful in others.）模式可以有多种格式，每一种格式都增加了一些有用的特别化特征。 本书讲述分析中的模式，也就是反映商业过程的概念模式，而不是具体的软件实现。大多数的章节讨论不同的问题域中的模式，这些模式难以按传统的行业分类（例如制造、金融、医疗保健等），因为他们经常适用于多个领域。模式可以帮助我们理解人们对世界的认识，而且基于这样的认识来建立计算机系统，并试图改变这些认识（或者可以称为商业过程重组工程Business Process Reengineering——BPR）是非常有意义的。 当然，概念模式（Conceptual Patterns）并不能孤立存在，对于软件工程人员来说，只有当他们看到如何实现时概念模型才有意义。所以在这本书里我还提供了可以将概念模型实现成软件的模式，并将讨论该软件如何适合一个大型信息系统的结构，还将给出和这些模式有关的具体实现技巧。 建模人员将在这本书里找到在其他新的领域里有用的思想，这些模式包括有用的模型，设计背后的理由，还有什么时候适合和不适合应用。这些可以帮助建模人员在遇到具体的问题时更好地应用这些模式。 这本书里的模式还可以用来回顾已有的模型——来看其中哪些可以省略，哪些可以找到替代的方式来改进它们。当我回顾一个项目时，经常拿它们和从以前的项目中学到的模式相比较，就这样，我发现模式意识使我更容易应用以往的实践经验，这样的模式也远远比简单的课本更容易揭露模型的要点和本质。通过讨论我们为什么这样建模，将会使我们对如何改进这些模型有更深的理解，即使我们并没有直接运用这些模式。 本书结构 这本书分为两大部分：第一个部分讲述分析模式——来自概念商业模型的模式；他们提供来自贸易、测量、记帐（Accounting）、组织关系等多个问题域的关键抽象。这些模式之所以是概念性的因为他们关注的是人们对业务的思考和认识，而不是计算机系统的设计方法。这个部分的章节着重于可用的可选模式，和这些可选模式各自的优点和弱点。而且尽管每一个模式可用于特定的问题域，那些基础的模式还可以用于其他的领域。 第二个部分讲述支持模式，通过支持模式对这些分析模式提供使用帮助。支持模式描述分析模式怎样适合一个大型信息系统的结构，描述这些概念模型如何转换成软件接口和实现，还有那些特定的高级（advanced）模型构造怎样和更简单结构相关。 为了描述这些模型，我需要一种注记方法。附录中包括对本书所用注记方法的简要讨论，以及符号的意思，还包括哪里可以找到我所用（注记）技术的指南。 每一个部分都划分为章节，每个关于分析模式的章节包括那些在一个松散的主题空间相关的模式，这些模式也会受到产生它们的项目的影响。这样的组织方式说明任何模式都来自于实际的环境。每个模式出现在一章的各个小节，不象其他模式作者一样，我并没有为每个模式提供单独的标题，而是提供了一个类似于描述原始工程的格式，并增加了模式在原始问题域中以及在其他的环境下如何应用的例子。关于模式，其中最大的困难就是如何抽象到别的问题域；不过我认为这个问题最好留给读者自己去思考。 因此，这本书可以当作一个目录，而不是需要从头到尾读完。我努力使得每个章节独立于其他的章节，（虽然这经常是不可能的，所以每个章节如果引用