《分析模式：可重用对象模型（笔记版）.doc》由会员分享，可在线阅读，更多相关《分析模式：可重用对象模型（笔记版）.doc（114页珍藏版）》请在金锄头文库上搜索。
1、分析模式：可重用对象模型（笔记版）作者：Martin FowlerADDISON-WESLEY 1997整理：Windy J（2001/2/14）注：本文采用意译的方法，重在表达原文的意思，而不是逐字逐句的翻译，如有错误，请指正。前言不久以前市面上还没有关于面向对象分析和设计的书籍，但现在这类的书非常多以至于人们无法全部一一掌握他们。大部分的这些书致力于讲解一种注记方法，介绍一个简单的建模过程，并提供一些简例来说明。但分析模式：可重用对象模型显然不同，它关注的主要是建模的结果那些模型本身，而不是关注建模过程怎样建模。我是一个信息系统面向对象建模咨询/顾问人员，为客户提供建模人员培训和项目指导。
2、我的绝大部分经验来自建模技术知识和怎样运用它们。不过，更重要的是我在实际建模中的经验，以及看到问题经常会重复出现，正是因为这样我可以重用以前建立的模型，改进它们，并用于新的要求。最近几年越来越多的人们发现了这一现象。我们意识到典型的方法学的书，尽管很有价值，却只提出了学习过程的第一步，这样的学习过程，还必须捕捉实际的事物本身。这样的意识发展成为了“模式（Patterns）”运动，但是怎样给模式下一个唯一的定义呢？我的定义是：模式是一种思想，它已经适用于一个实践环境中，并有可能适用于其他的环境。（A pattern is an idea that has been useful in one p
3、ractical context and will probably be useful in others.）模式可以有多种格式，每一种格式都增加了一些有用的特别化特征。本书讲述分析中的模式，也就是反映商业过程的概念模式，而不是具体的软件实现。大多数的章节讨论不同的问题域中的模式，这些模式难以按传统的行业分类（例如制造、金融、医疗保健等），因为他们经常适用于多个领域。模式可以帮助我们理解人们对世界的认识，而且基于这样的认识来建立计算机系统，并试图改变这些认识（或者可以称为商业过程重组工程Business Process ReengineeringBPR）是非常有意义的。当然，概念模式（Con
4、ceptual Patterns）并不能孤立存在，对于软件工程人员来说，只有当他们看到如何实现时概念模型才有意义。所以在这本书里我还提供了可以将概念模型实现成软件的模式，并将讨论该软件如何适合一个大型信息系统的结构，还将给出和这些模式有关的具体实现技巧。建模人员将在这本书里找到在其他新的领域里有用的思想，这些模式包括有用的模型，设计背后的理由，还有什么时候适合和不适合应用。这些可以帮助建模人员在遇到具体的问题时更好地应用这些模式。这本书里的模式还可以用来回顾已有的模型来看其中哪些可以省略，哪些可以找到替代的方式来改进它们。当我回顾一个项目时，经常拿它们和从以前的项目中学到的模式相比较，就这样，
5、我发现模式意识使我更容易应用以往的实践经验，这样的模式也远远比简单的课本更容易揭露模型的要点和本质。通过讨论我们为什么这样建模，将会使我们对如何改进这些模型有更深的理解，即使我们并没有直接运用这些模式。本书结构这本书分为两大部分：第一个部分讲述分析模式来自概念商业模型的模式；他们提供来自贸易、测量、记帐（Accounting）、组织关系等多个问题域的关键抽象。这些模式之所以是概念性的因为他们关注的是人们对业务的思考和认识，而不是计算机系统的设计方法。这个部分的章节着重于可用的可选模式，和这些可选模式各自的优点和弱点。而且尽管每一个模式可用于特定的问题域，那些基础的模式还可以用于其他的领域。第二
6、个部分讲述支持模式，通过支持模式对这些分析模式提供使用帮助。支持模式描述分析模式怎样适合一个大型信息系统的结构，描述这些概念模型如何转换成软件接口和实现，还有那些特定的高级（advanced）模型构造怎样和更简单结构相关。为了描述这些模型，我需要一种注记方法。附录中包括对本书所用注记方法的简要讨论，以及符号的意思，还包括哪里可以找到我所用（注记）技术的指南。每一个部分都划分为章节，每个关于分析模式的章节包括那些在一个松散的主题空间相关的模式，这些模式也会受到产生它们的项目的影响。这样的组织方式说明任何模式都来自于实际的环境。每个模式出现在一章的各个小节，不象其他模式作者一样，我并没有为每个模式
7、提供单独的标题，而是提供了一个类似于描述原始工程的格式，并增加了模式在原始问题域中以及在其他的环境下如何应用的例子。关于模式，其中最大的困难就是如何抽象到别的问题域；不过我认为这个问题最好留给读者自己去思考。因此，这本书可以当作一个目录，而不是需要从头到尾读完。我努力使得每个章节独立于其他的章节，（虽然这经常是不可能的，所以每个章节如果引用了其他的章节，我会在介绍里声明。）每个章节的介绍部分包括该章节的通用主题空间，总结这个章节中的模式，以及模式产生的项目资料。怎样阅读本书我建议先详细阅读第一章，再看每章的介绍部分，然后就可以按照你的兴趣选择阅读各章，不管你用什么顺序。如果你不熟悉我建模的方法
8、，或我采用的注记和概念，可以阅读附录。在模式表格中给出了每个模式的简要总结，以后回顾本书的时候可以查阅它们。非常重要的是这些模式在它们产生的问题域之外也非常有用，所以我建议你阅读那些也许不在你兴趣之内的章节，例如，我发现医疗保健行业中关于观测和测量的模式在公司金融分析中证明非常有用。谁将阅读这本书最大的读者群应该是面向对象计算机系统的分析和设计人员；一个小规模但非常重要的读者群应该是那些建模项目的问题域专家；希望程序员们可以钻研这本书，尽管本书缺乏代码和有着概念倾向，我建议你们着重注意第十四章，这一章讲述了概念模型和结果软件之间的关系；数据建模人员；经理们将发现这本书是开发活动的一个起点。从模
9、式开始有助于简化目标，项目计划也可以获益于广大的模式设计背景；学生并不是我定位的读者，但他们同样可以阅读这本书。一本动态的书书出版之后作者将难以改变书的内容，但是我一直在努力学习，而且这样的学习一定会改变我的原有的看法，所以我希望这些改变也能让读者们知道。幸运的是Addison-Wesley公司为这本书提供了一个网址，将用来提供更多的资料。使得这本书可以保持动态改变，我希望该网址会包括以下内容：l 我学到的关于这本书的模式的新的东西；l 对于这本书的问题解答；l 其他人关于模式的有用解说；l UML注记出现的时候我会重画书中的图表并上载它们；这个网址将是本书的补充部分，所以别忘了关注它，并可用
10、来告诉我怎样改进和发展本书的思想。答谢（略）参考1Martin, J., and J. Odell. Object-Oriented Methods: A Foundation. Englewood Cliffs, NJ: Prentice-Hall, 1995第一章 介绍1.1 概念模型大部分面向对象建模的书都提到分析和设计，但对于分析和设计的分界点却一直没有达成统一的意见。在对象开发过程中一个重要的原则是需要设计软件，并使得软件的结构反映问题的结构，这项原则的一个结果是从分析和设计产生的模型结束时都有意变得十分类似，从而导致许多人认为这两者之间没有区别。我相信分析和设计之间的分别仍然存在，
11、但它正日益成为一个重点。进行分析时你需要努力理解面临的问题，对于我来说这不仅仅是用用例列出所有的需求。在系统开发中虽然用例即使不是必需的，也是很有价值的一个部分，但捕捉完它们并不意味着分析的结束。分析还包括深入到表面需求的背后，来得到一个关于问题本质的精神模型（或理论模型：Mental Model）。例如有人需要开发一套软件来模仿桌球游戏，问题可能用用例来表述表面的特征：“游戏者击中白球，它以一定的速度前进，并以特定的角度碰到红球，于是红球在某个特定的方向上前进一段距离”。你可以拍下几百个这样的事件，测量不同的球速，角度和距离，但靠这些样例要写出好的仿真程序远远不够，因为除了这些表面现象，你还
12、必须了解背后的本质，那就是和质量有关的运动定律，速度，动量，等等。了解这些规律将更容易看到软件可以怎样建立。桌球问题非常例外，因为那些定律早已成为公理。在许多企业中，规律并没有得到很好的理解，而需要我们努力去发现它们。因此我们建立一个概念模型来理解和简化问题。某种概念模型是软件开发过程中必要的一部分，就连最不受控制的黑客们都这样做，差别只是：建立模型到底是它本身的一个过程还是整个软件设计过程的一部分。别忘了概念模型是一个人工产物，它们代表了现实世界的模型，但它们是人类创建的。在工程方面，模型让我们更好地理解现实世界，而且，建模人员也可以使用一个或更多的模型。例如，桌球问题中，人们可以采用牛顿模
13、型或爱因斯坦模型，只是它们的精确程度和复杂程度不一样。建模原则 模型没有对错之分，只有适用性不同。（ Models are not right or wrong; they are more or less useful.）模型的选择影响着结果（系统）的灵活性和可重用性。在系统中考虑太多的灵活性将使系统复杂度提高，这是不好的设计。设计需要在建造和维护代价上进行折衷。要得到满足某种目的的软件，你需要建立一个和需求相应的概念模型。你需要你能得到的最简单的模型，不要为你的模型增加不可能用到的灵活性。最简单的模型不一定是你首先需要考虑的，因为简单的方案需要不少的时间和精力。但这些时间和精力往往是值得付
14、出的，它们不但使得系统易于建立，更重要的是易于维护和将来易于进行扩展。所以值得用可以运行的更简单的软件代替原来运行的软件。你将怎样表达概念模型？很多人把概念模型建立在他们的开发语言中。好处是你可以执行一个模型来验证它的正确性，和进行后续的研究。另一个好处是你最终将把模型转到开发语言，所以可以省区翻译转换工作。坏处是，很容易陷入语言细节而忘记原本要面对的问题；还有很容易为特定的语言建模，使得模型向别的语言移植变得困难。为了避免这些问题，许多人开始采用分析和设计技术，这些技术可以帮助人们关注概念上的而不是软件设计上的问题，问题域专家们也容易学会这些技术，由于它们使用图形，因而显得更有表现力。它们可
15、以是精确/严格的，但并非必要如此。我采用分析和设计技术的一个主要原因是为了和问题域专家一起工作，因为在概念建模时必须有问题域专家参与。我相信有效的模型只有那些真正在问题域中工作的人才能建造出来，而不是软件开发人员，不管他们曾经在这个问题域工作了多久。不过，当问题域专家开始建模时，他们需要指导。我曾经为客户服务监督、医生、护士、金融商货和公司财务分析员教授面向对象的分析和设计技术，同时，我发现，对于他们来说，有没有IT背景其实是无关紧要的，例如，我知道的最好的建模人员是伦敦一家医院的外科医生。作为一名专业的分析家和建模人员，我给这个过程提供有价值的技巧：我提供严格（的标准），我知道怎样使用这些技
16、术，而且我“局外人”的眼光可以质疑模型中看似正确的地方。但是，这些是不够的，在建立分析模型时最重要的是专业知识。分析技术倾向独立于软件技术，理想情况下，一种概念模型技术最好完全独立于软件技术，就象运动定律一样。这种独立性可以防止技术阻碍对问题的理解，而且产生的模型对各种不同的软件技术一样有用。但是实际上这种纯度不可能达到，例如，（实现）语言的变化也会影响到我们建模的方法。在这里希望大家注意的一点是，概念模型更接近软件的接口（Interfaces）而不是软件实现（Implementations）。面向对象软件的一个特点就是接口从实现中分离，但在实际中很容易忘记这一点，因为通常的语言在这两者中没有显式的区别。软件组件的接口（它的类型：type）和它的实现（用以实现的类）之间的区别非
