![分析模式：可复用的对象模型[图书]](http://images.china-pub.com/ebook195001-200000/196704/zcover.jpg)
（已有30条评价）基本信息
- 原书名：Analysis Patterns: Reusable Object Models
- 原出版社： Addison-Wesley Professional
- 作者： (英) Martin Fowler
- 译者： 樊东平 张路
- 丛书名： 经典重读
- 出版社：机械工业出版社
- ISBN：9787111305309
- 上架时间：2010-6-17
- 出版日期：2010 年5月
- 开本：16开
- 页码：319
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 设计模式
【插图】
编辑推荐
Martin Fowler认识到面向对象研究团体需要一本**传统方法学*作所包含的工具和技术的书，因此撰写了《分析模式可复用的对象模型》，重点介绍面向对象分析和设计的*终结果——模型本身。他将自己丰富的对象建模专业经验与读者分享，着眼于找出重复问题并把这些问题转换为可复用的模型。《分析模式可复用的对象模型》提供一个模式目录，涉及交易.测量、财务和组织内部关系等广泛领域。
鉴于概念模式不能孤立存在，Martin Fowler还提出一系列“支持模式”，这些支持模式讨论如何将概念模式转变为适合大型信息系统构架的软件。在介绍每种模式时，都讲述设计背后的缘由以及使用这种模式的规则。书中的示例包含有用模型的使用细节并进一步探讨了将会改进分析、建模和实现的复用技巧。
内容简介
书籍
计算机书籍
本书的作者Martin Fowler是国际著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首席科学家，本书是作者的代表作之一，深受业界专业人士和广大读者的好评，经久不衰。
本书讲述各种分析模式（即来自概念性业务模型的模式）和支持模式（即讲述如何使用分析模式的辅助性模式），把论述重点放在介绍面向对象分析和设计的最终结果—即模型本身。作者透过平实朴素的语言，将自己丰富的对象建模经验与读者分享，使读者可以马上采纳这些经验性模式。
本书适合的读者范围非常广：面向对象的计算机分析人员和设计人员（尤其是那些参与系统分析的人员）、数据建模人员、编程人员以及专业的软件工程师都可以从本书中获得宝贵的知识和经验。
计算机书籍
本书的作者Martin Fowler是国际著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首席科学家，本书是作者的代表作之一，深受业界专业人士和广大读者的好评，经久不衰。
本书讲述各种分析模式（即来自概念性业务模型的模式）和支持模式（即讲述如何使用分析模式的辅助性模式），把论述重点放在介绍面向对象分析和设计的最终结果—即模型本身。作者透过平实朴素的语言，将自己丰富的对象建模经验与读者分享，使读者可以马上采纳这些经验性模式。
本书适合的读者范围非常广：面向对象的计算机分析人员和设计人员（尤其是那些参与系统分析的人员）、数据建模人员、编程人员以及专业的软件工程师都可以从本书中获得宝贵的知识和经验。
作译者
福勒（Martin Fowler），在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都是世界顶级的专家，现为Thought Works公司的首席科学家。Thougtlt Works是一家从事企业应用开发和集成的公司。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者
目录
Ralph Johnson序
Ward Cunningham序
前言
第1章 绪论 1
1.1 概念模型 1
1.2 模式世界 4
1.2.1 Christopher Alexander 5
1.2.2 描述格式 5
1.2.3 关于模式的抽象程度 6
1.3 本书中的模式 7
1.3.1 建模实例 8
1.3.2 模式的来源 8
1.3.3 跨领域的模式 9
1.4 概念模型与业务过程重组 9
1.5 模式与框架 10
1.6 本书的使用 11
第一部分 分析模式
第2章 责任模式 17
2.1 团体 18
2.2 组织层次 19
Ward Cunningham序
前言
第1章 绪论 1
1.1 概念模型 1
1.2 模式世界 4
1.2.1 Christopher Alexander 5
1.2.2 描述格式 5
1.2.3 关于模式的抽象程度 6
1.3 本书中的模式 7
1.3.1 建模实例 8
1.3.2 模式的来源 8
1.3.3 跨领域的模式 9
1.4 概念模型与业务过程重组 9
1.5 模式与框架 10
1.6 本书的使用 11
第一部分 分析模式
第2章 责任模式 17
2.1 团体 18
2.2 组织层次 19
前言
不久前，还没有任何有关面向对象分析和设计的书籍。而现在，却有如此之多的书籍，以致于任何一个专业人员都无法全部涉猎。其中大部分书籍都专注于：传授一种图符表示法，提出一个简单的建模过程，并用几个简单的示例来加以说明。本书是一本与它们完全不同的书。它并不把重点放在过程—即如何建模，而是把重点放在过程的结果—即模型本身。
我是一个信息系统对象建模方面的顾问。客户常常聘请我训练他们的员工如何建模和为他们的项目提供指导。我的大部分技能来自对建模技术以及如何运用这些技术的了解。然而，更重要的是我的实际经验，这些经验是在建造许多模型和经常分析重复出现问题的过程中积累起来的。我经常发现项目在很多方面会遇到以前我曾面对的同样问题。这些经验使得我可以重用以前所建造的模型，我只需要对这些模型加以改进，使之适应新的需求。
在过去的几年里，越来越多的人已经意识到这一现象，并且认识到那些通常介绍方法论的书籍虽然很有价值，但都只提出了学习过程的第一步，而这个学习过程还必须捕获要被建模的实际事物本身。这种认识逐渐发展成为“模式”运动，在这一运动中汇集了各种各样的人，他们有着不同的兴趣和观点，却抱着共同的目标，即传播有用的软件系统模式。
由于这个模式群体构成的多样性，我们很难给“模式”一个准确的定义。我们中的所有人都相信，一旦我们看到一个模式，就能辨别出它；我们认为我们在大多数情况下是一致的，但我们无法给出一个简单的定义。我对模式的定义是：模式是一种问题解决思路，它已经适用于一个实践环境，并且也可能适用于其它环境。
我喜欢给出一个宽松的定义，因为我希望能尽可能地接近模式研究的初衷，而不需要增加太多限制性的内容。模式可以有多种形式，而每一种形式增加了对于该模式有用的特性（1.2节讨论有关模式研究的现状以及本书所处的地位）。
本书讨论的是分析方面的模式，这些模式反映的是业务过程的概念架构，而不是实际的软件实现。绝大部分章节讨论不同业务领域的模式。这些模式很难按照传统的行业（如制造、金融、医疗保健等）进行分类，因为它们通常可用在多个领域。这些模式非常重要，因为它们可以帮助我们了解人们对世界的认识。基于这样的认识去设计计算机系统并确实去改变这种认识是非常有价值的，而认识中需要改变的地方正是需要进行业务过程重组（BPR）的地方。
然而，概念模式不可能孤立存在。对于软件工程师来讲，只有在他们明白如何实现概念模型时，这些概念模型才有用。本书介绍了一些可用于将概念模型转化成软件实现的模式，并且讨论了在一个大型信息系统中这些软件实现是如何适应系统构架的，另外还讨论了使用这些模式的具体实现技巧。
我写本书是因为它也正是我在开始时想要阅读的书。建模人员会从本书中找到可以帮助他们如何在新领域中大展拳脚的基本思路。这些模式包括：有用的模型、设计背后的论证以及适用范围。拥有这些信息，建模人员就可以为特定的问题改造现有的模型。
本书中的模式也可用于评审已有的模型—看看其中哪些可以省略，并给出一些有助于模型改进的可选方案。当我在评审一个项目时，通常会将所看到的东西同我在以前工作中所总结出的模式加以比较。我发现了解我的书中包含的模式有助于我更容易地应用自己过去的经验。像这样的一些模式还揭示了在简单的教科书中没有谈及的建模问题。通过探讨为什么要按照我们的方法去进行建模，我们在即使没有直接使用这些模式的情况下也可以更深刻地认识到如何改进我们的建模方法。
本书结构
本书分为两个部分。第一部分介绍各种分析模式，即来自概念业务模型的模式。它们提供来自贸易、测量、财务以及组织关系等多个问题域的关键抽象。这些模式都是概念性的，因为它们表征了人们考虑业务的方式，而不是设计计算机系统的方式。该部分的各章重点阐述了可用的可选模式以及这些模式的优缺点。对于同一领域的建模人员来说，每种模式都是明显有用的，但是其中的基本模式通常在别的领域也能够发挥作用。
第二部分重点介绍支持模式，这类模式帮助我们使用分析模式。支持模式展示：分析模式如何适合一个信息系统构架，概念模型的构造如何演变成为软件接口和实现，以及那些特定的高级建模构造如何与更简单的结构关联。
为了描述这些模式，需要借助于一种新的图符表示法。附录简要地讨论了这种图符表示法，并提供了其中各种符号表示的含义。我没有采用单一的方法，而喜欢综合采用来自不同方法的多种技术。附录并不是一个技术指南，但它可以提供一个大纲，使你能回想起技术内容。此外，附录还告诉你应该到何处去查找我所采用技术的指南。
书中每个部分都划分成若干章节，有关分析模式的各个章节阐述了相关的模式，这些相关模式同属一个概念较为松散的主题空间，并受到产生它们的项目的影响。这种组织形式反映了这样一个事实：任何一种模式都必须来自于一个实际的环境。每个模式都由一章中的单独小节加以阐述。我没有采用其他一些模式作者所用的任何正式标题（参见1.2.2节），而是采取尽可能具体而又尽量合理地接近原始项目形式的方式去描述模式。我还增加了一些例子来说明如何将模式应用于其原有领域以及如何将模式应用于其它领域。有关模式研究的最困难的一件事是如何对它们加以抽象，并用于其它领域；我所采取的策略是把这一问题留给读者自己去思考和解决（参见1.2.3节）。
本书更像是一本目录册，而不是一本从头读到尾的书。我尽量按照可单独阅读的方式撰写书中的每一章。（但是，这一点并非总是能做到的。在阅读一章时如果需要先了解其他章的内容，我将在引言中加以说明。）每一章都有引言，引言部分概要地说明该章所针对的问题域，并概要地描述该章所包含的相关模式，此外还会谈到这些模式来自什么项目。
如何阅读本书
建议先通读第1章，然后阅读每一章的引言部分，接下来就可以自由地按照自己喜欢的顺序去钻研各章。如果你还不熟悉我所采用的建模方法、表示法或者概念，请参见附录A。附录B“模式表”简要地总结各模式的概况，因此你可以在再次阅读本书时利用它来协助钻研本书的内容或查找所需的模式。需要特别强调的是本书中的模式也可用于其它领域，不局限于模式所产生的领域，因此我鼓励你浏览一下你可能认为不属于自己兴趣范围之内的章节。比如，我发现为医疗保健行业而设计的观察和测量模型在企业金融分析中就被证明是非常有用的。
本书的读者
虽然不同的读者会从本书学到不同的东西并且可能需要一些不同的准备知识，但本书适合的读者范围非常广。
我认为最大的读者群是面向对象（OO）计算机系统的分析人员和设计人员，尤其是那些主要从事系统分析的人员。这一类读者应该或多或少地使用过某种OO分析和设计方法。本书并不提供任何有关面向对象分析与设计的内容，因此如果你对这一领域还很陌生，建议你先阅读有关的书籍。必须强调的是，本书中的模式本质上是一种概念，而我是使用一种完全概念化的方法建模，这使得本书在表述风格上与使用更趋向基于实现的方法建模的书籍有某些区别。
我是一个信息系统对象建模方面的顾问。客户常常聘请我训练他们的员工如何建模和为他们的项目提供指导。我的大部分技能来自对建模技术以及如何运用这些技术的了解。然而，更重要的是我的实际经验，这些经验是在建造许多模型和经常分析重复出现问题的过程中积累起来的。我经常发现项目在很多方面会遇到以前我曾面对的同样问题。这些经验使得我可以重用以前所建造的模型，我只需要对这些模型加以改进，使之适应新的需求。
在过去的几年里，越来越多的人已经意识到这一现象，并且认识到那些通常介绍方法论的书籍虽然很有价值，但都只提出了学习过程的第一步，而这个学习过程还必须捕获要被建模的实际事物本身。这种认识逐渐发展成为“模式”运动，在这一运动中汇集了各种各样的人，他们有着不同的兴趣和观点，却抱着共同的目标，即传播有用的软件系统模式。
由于这个模式群体构成的多样性，我们很难给“模式”一个准确的定义。我们中的所有人都相信，一旦我们看到一个模式，就能辨别出它；我们认为我们在大多数情况下是一致的，但我们无法给出一个简单的定义。我对模式的定义是：模式是一种问题解决思路，它已经适用于一个实践环境，并且也可能适用于其它环境。
我喜欢给出一个宽松的定义，因为我希望能尽可能地接近模式研究的初衷，而不需要增加太多限制性的内容。模式可以有多种形式，而每一种形式增加了对于该模式有用的特性（1.2节讨论有关模式研究的现状以及本书所处的地位）。
本书讨论的是分析方面的模式，这些模式反映的是业务过程的概念架构，而不是实际的软件实现。绝大部分章节讨论不同业务领域的模式。这些模式很难按照传统的行业（如制造、金融、医疗保健等）进行分类，因为它们通常可用在多个领域。这些模式非常重要，因为它们可以帮助我们了解人们对世界的认识。基于这样的认识去设计计算机系统并确实去改变这种认识是非常有价值的，而认识中需要改变的地方正是需要进行业务过程重组（BPR）的地方。
然而，概念模式不可能孤立存在。对于软件工程师来讲，只有在他们明白如何实现概念模型时，这些概念模型才有用。本书介绍了一些可用于将概念模型转化成软件实现的模式，并且讨论了在一个大型信息系统中这些软件实现是如何适应系统构架的，另外还讨论了使用这些模式的具体实现技巧。
我写本书是因为它也正是我在开始时想要阅读的书。建模人员会从本书中找到可以帮助他们如何在新领域中大展拳脚的基本思路。这些模式包括：有用的模型、设计背后的论证以及适用范围。拥有这些信息，建模人员就可以为特定的问题改造现有的模型。
本书中的模式也可用于评审已有的模型—看看其中哪些可以省略，并给出一些有助于模型改进的可选方案。当我在评审一个项目时，通常会将所看到的东西同我在以前工作中所总结出的模式加以比较。我发现了解我的书中包含的模式有助于我更容易地应用自己过去的经验。像这样的一些模式还揭示了在简单的教科书中没有谈及的建模问题。通过探讨为什么要按照我们的方法去进行建模，我们在即使没有直接使用这些模式的情况下也可以更深刻地认识到如何改进我们的建模方法。
本书结构
本书分为两个部分。第一部分介绍各种分析模式，即来自概念业务模型的模式。它们提供来自贸易、测量、财务以及组织关系等多个问题域的关键抽象。这些模式都是概念性的，因为它们表征了人们考虑业务的方式，而不是设计计算机系统的方式。该部分的各章重点阐述了可用的可选模式以及这些模式的优缺点。对于同一领域的建模人员来说，每种模式都是明显有用的，但是其中的基本模式通常在别的领域也能够发挥作用。
第二部分重点介绍支持模式，这类模式帮助我们使用分析模式。支持模式展示：分析模式如何适合一个信息系统构架，概念模型的构造如何演变成为软件接口和实现，以及那些特定的高级建模构造如何与更简单的结构关联。
为了描述这些模式，需要借助于一种新的图符表示法。附录简要地讨论了这种图符表示法，并提供了其中各种符号表示的含义。我没有采用单一的方法，而喜欢综合采用来自不同方法的多种技术。附录并不是一个技术指南，但它可以提供一个大纲，使你能回想起技术内容。此外，附录还告诉你应该到何处去查找我所采用技术的指南。
书中每个部分都划分成若干章节，有关分析模式的各个章节阐述了相关的模式，这些相关模式同属一个概念较为松散的主题空间，并受到产生它们的项目的影响。这种组织形式反映了这样一个事实：任何一种模式都必须来自于一个实际的环境。每个模式都由一章中的单独小节加以阐述。我没有采用其他一些模式作者所用的任何正式标题（参见1.2.2节），而是采取尽可能具体而又尽量合理地接近原始项目形式的方式去描述模式。我还增加了一些例子来说明如何将模式应用于其原有领域以及如何将模式应用于其它领域。有关模式研究的最困难的一件事是如何对它们加以抽象，并用于其它领域；我所采取的策略是把这一问题留给读者自己去思考和解决（参见1.2.3节）。
本书更像是一本目录册，而不是一本从头读到尾的书。我尽量按照可单独阅读的方式撰写书中的每一章。（但是，这一点并非总是能做到的。在阅读一章时如果需要先了解其他章的内容，我将在引言中加以说明。）每一章都有引言，引言部分概要地说明该章所针对的问题域，并概要地描述该章所包含的相关模式，此外还会谈到这些模式来自什么项目。
如何阅读本书
建议先通读第1章，然后阅读每一章的引言部分，接下来就可以自由地按照自己喜欢的顺序去钻研各章。如果你还不熟悉我所采用的建模方法、表示法或者概念，请参见附录A。附录B“模式表”简要地总结各模式的概况，因此你可以在再次阅读本书时利用它来协助钻研本书的内容或查找所需的模式。需要特别强调的是本书中的模式也可用于其它领域，不局限于模式所产生的领域，因此我鼓励你浏览一下你可能认为不属于自己兴趣范围之内的章节。比如，我发现为医疗保健行业而设计的观察和测量模型在企业金融分析中就被证明是非常有用的。
本书的读者
虽然不同的读者会从本书学到不同的东西并且可能需要一些不同的准备知识，但本书适合的读者范围非常广。
我认为最大的读者群是面向对象（OO）计算机系统的分析人员和设计人员，尤其是那些主要从事系统分析的人员。这一类读者应该或多或少地使用过某种OO分析和设计方法。本书并不提供任何有关面向对象分析与设计的内容，因此如果你对这一领域还很陌生，建议你先阅读有关的书籍。必须强调的是，本书中的模式本质上是一种概念，而我是使用一种完全概念化的方法建模，这使得本书在表述风格上与使用更趋向基于实现的方法建模的书籍有某些区别。
序言
当我面对一个软件开发项目时，首先看重的是经验。软件开发小组成员是否拥有相关的工作经验?他们能否将自身的经验有效地应用到他们所创建的对象中?不幸的是，答案往往是否定的。
越来越多的像我们这样从事面向对象开发的人员都感觉到：已经有一段时间我们把集体的注意力放错了地方。事实上，我们已不再需要把注意力放在诸如工具、技术、图符甚至是代码上，我们已经掌握了建造复杂程序的机制。如果我们失败了，那仅仅是因为缺乏经验。
Martin Fowler发现了一种给予我们所需东西的途径：那就是以书本的形式总结并介绍经验。
他研究了领域对象，就像Eric Gamma等人在他们的代表作《设计模式》中研究了实现对象一样。Martin Fowler使用了与其相似的术语，但是方法却不一样。比如，他使用“模式”一词，并不是在抄袭或者扩充Eric Gamma的著作(或当前市面上突然出现的那些新书)。他把经验的书面形式称为“模式”，只不过是因为那就是它们本来的名称。作为一个信息系统对象建模方面的顾问，他在工作中再三地发现反复出现的问题的解决方案，并发现在该过程中的模式的组成形式。
Martin Fowler本来可以很容易地写一本有关面向对象分析的书。但是，他并没有那样去做。其结果是我们拥有了一本对分析结果进行分类的书。书中每一章都汇集了他(以及他的同事)对通常性业务问题的分析工作的结论。涉及的领域很广，从医疗记录的保存到金融衍生交易，中间还经历了几个阶段。哪一章适于你呢?令人惊讶的是，所有章节都很有用。Martin Fowler将每个问题置于特定的上下文环境中，然后给出相应的解决方案。你会在每种上下文环境中看出相似的地方，你也将识别出问题之所在。更重要的是，你将获得意外的收获，那就是：经验!
最后，Martin Fowler采用一种较为个性化的书写方式，来表达他的想法和见解。我们可以感受到他对客户和同事的尊重，他承认绝大部分灵感都是受他们(客户和同事)启发的结果。我们察觉他保持了与实现的反复无常的行为的距离，同时兼顾了可实现性，而且拿捏得恰到好处。其实， 当我们考察一个分析专家的想法时，我们主要向专家学习的是如何进行分析的思路和方法，以便进一步丰富我们自己的经验。
——Ward Cunningham
Cunningham&Cunningham，InC．
越来越多的像我们这样从事面向对象开发的人员都感觉到：已经有一段时间我们把集体的注意力放错了地方。事实上，我们已不再需要把注意力放在诸如工具、技术、图符甚至是代码上，我们已经掌握了建造复杂程序的机制。如果我们失败了，那仅仅是因为缺乏经验。
Martin Fowler发现了一种给予我们所需东西的途径：那就是以书本的形式总结并介绍经验。
他研究了领域对象，就像Eric Gamma等人在他们的代表作《设计模式》中研究了实现对象一样。Martin Fowler使用了与其相似的术语，但是方法却不一样。比如，他使用“模式”一词，并不是在抄袭或者扩充Eric Gamma的著作(或当前市面上突然出现的那些新书)。他把经验的书面形式称为“模式”，只不过是因为那就是它们本来的名称。作为一个信息系统对象建模方面的顾问，他在工作中再三地发现反复出现的问题的解决方案，并发现在该过程中的模式的组成形式。
Martin Fowler本来可以很容易地写一本有关面向对象分析的书。但是，他并没有那样去做。其结果是我们拥有了一本对分析结果进行分类的书。书中每一章都汇集了他(以及他的同事)对通常性业务问题的分析工作的结论。涉及的领域很广，从医疗记录的保存到金融衍生交易，中间还经历了几个阶段。哪一章适于你呢?令人惊讶的是，所有章节都很有用。Martin Fowler将每个问题置于特定的上下文环境中，然后给出相应的解决方案。你会在每种上下文环境中看出相似的地方，你也将识别出问题之所在。更重要的是，你将获得意外的收获，那就是：经验!
最后，Martin Fowler采用一种较为个性化的书写方式，来表达他的想法和见解。我们可以感受到他对客户和同事的尊重，他承认绝大部分灵感都是受他们(客户和同事)启发的结果。我们察觉他保持了与实现的反复无常的行为的距离，同时兼顾了可实现性，而且拿捏得恰到好处。其实， 当我们考察一个分析专家的想法时，我们主要向专家学习的是如何进行分析的思路和方法，以便进一步丰富我们自己的经验。
——Ward Cunningham
Cunningham&Cunningham，InC．
媒体评论
“本书是对不断发展的模式文献的一个重要贡献。它捕捉来自不同领域的深奥的对象建模专业知识，形成一个模式目录。这些领域模式将有助于你解决不同领域中具有挑战性的建模问题。”
———Erich Gamma
“Martin Fowler为我们给出答案，而不仅仅是一个可以找到这些答案的过程。在本书中，透过作者平实朴素的语言，你将找到自己下一个业务对象模型的重要内容。”
———Ward Cunningham
“就像‘四人帮’在他们的经典著作《设计模式》中总结出了通用的设计模式，Martin Fowler在这本让人期待已久的书中为我们总结出应用领域的诸多模式。本书是从事面向对象业务建模和业务过程重组工作的所有分析人员和设计人员的必备之书。”
——Donald G. Firesmith
———Erich Gamma
“Martin Fowler为我们给出答案，而不仅仅是一个可以找到这些答案的过程。在本书中，透过作者平实朴素的语言，你将找到自己下一个业务对象模型的重要内容。”
———Ward Cunningham
“就像‘四人帮’在他们的经典著作《设计模式》中总结出了通用的设计模式，Martin Fowler在这本让人期待已久的书中为我们总结出应用领域的诸多模式。本书是从事面向对象业务建模和业务过程重组工作的所有分析人员和设计人员的必备之书。”
——Donald G. Firesmith
书摘
如果一个模型有多个隶属层次关系，我们可以用一种类型化的关系（如图2.6 所示）来表示。我们把层次关联关系转化成一种类型，通过使用组织结构类型的不同实例来区分不同的层次关系。这样就能用组织结构的两个实例（销售组织和服务组织）来处理上一节的场景（双层次关系）。新产生的层次关系可以通过简单地增加新的组织结构类型的方式加以处理。显然，这种抽象方式使我们能够在复杂性适度增加的情况下的增加更多的系统柔性。对于双层次关系，这样去做并不值得，但对于多层次关系，就很有必要。另外请注意，组织结构有时间周期；这使我们可以有效地记录组织结构的周期性变化。进而要注意的是，我并没有把组织结构类型看成是一种属性——类型属性是一个很重要的概念，我们将在后面具体谈到。
例：为波士顿的2176大容量卡布奇诺咖啡机而设立的服务小组向波士顿的销售办事处负责。我们可以将其刻画成这样一个组织结构模型：父节点是波士顿的销售办事处，子节点是波士顿的2176服务小组，组织结构类型叫做产品线管理。
例：为波士顿的2176大容量卡布奇诺咖啡机而设立的服务小组向产品支持结构中的2170产品系列服务中心负责。我们可以把它看成是一个单独的组织结构，它的父节点是2170产品系列服务中心，而子节点是波士顿的2176服务小组。组织结构类型叫做产品支持。
要简化对象结构，应把重点放在约束规则上。这些规则的具体形式可以是：“对于一个组织结构，如果其类型是销售组织并且其子节点是一个部门的话，那么其父节点必须是一个区域子公司”。请注意，约束规则被表示成指向组织结构的属性，其暗含着约束规则针对该组织结构。然而，这也意味着当通过增加新的组织结构类型的方式来扩展系统时，会改变该组织结构中的约束规则。而且，随着组织结构类型数量的增加，这些规则将变得难以处理。
可以把约束规则放到组织结构类型中（如图2-7所示）。针对特定的组织结构类型的所有规则被集中到一个地方，这样便于增加新的组织结构类型。
然而，如果我们很少改变组织结构类型而是经常增加新的组织子类型，图2-7就难以处理了。在这种情况下，组织子类型的每次增加都会导致约束规则的改变。更好的方法是让约束规则跟随组织子类型。概括起来，我们的目标是尽量减小模型的变化。我们应该按照这种方式，在不影响模型的其它部分的前提下，把约束规则放在最容易发生变化的地方。
例：为波士顿的2176大容量卡布奇诺咖啡机而设立的服务小组向波士顿的销售办事处负责。我们可以将其刻画成这样一个组织结构模型：父节点是波士顿的销售办事处，子节点是波士顿的2176服务小组，组织结构类型叫做产品线管理。
例：为波士顿的2176大容量卡布奇诺咖啡机而设立的服务小组向产品支持结构中的2170产品系列服务中心负责。我们可以把它看成是一个单独的组织结构，它的父节点是2170产品系列服务中心，而子节点是波士顿的2176服务小组。组织结构类型叫做产品支持。
要简化对象结构，应把重点放在约束规则上。这些规则的具体形式可以是：“对于一个组织结构，如果其类型是销售组织并且其子节点是一个部门的话，那么其父节点必须是一个区域子公司”。请注意，约束规则被表示成指向组织结构的属性，其暗含着约束规则针对该组织结构。然而，这也意味着当通过增加新的组织结构类型的方式来扩展系统时，会改变该组织结构中的约束规则。而且，随着组织结构类型数量的增加，这些规则将变得难以处理。
可以把约束规则放到组织结构类型中（如图2-7所示）。针对特定的组织结构类型的所有规则被集中到一个地方，这样便于增加新的组织结构类型。
然而，如果我们很少改变组织结构类型而是经常增加新的组织子类型，图2-7就难以处理了。在这种情况下，组织子类型的每次增加都会导致约束规则的改变。更好的方法是让约束规则跟随组织子类型。概括起来，我们的目标是尽量减小模型的变化。我们应该按照这种方式，在不影响模型的其它部分的前提下，把约束规则放在最容易发生变化的地方。
