面向对象分析与设计-四色原型模式

本文格式为Word版，下载可任意编辑——面向对象分析与设计—四色原型模式面向对象分析与设计—四色原型模式

1.背景介绍

至今我都明白的记得我第一次被面试官问起什么叫“建模〞技术时的情景，那是好几年前的事情了，当时是胸有成竹的去面试一个有关系统分析、设计的.NET高级软件工程师岗位。面试官几乎没问我有关.NET方面的任何技术实现，他就简单的问了问：“你如何把握你所分析出来的系统的正确性？〞，我当时有点小冲动，觉得这个问题应当很简单嘛，都是概念而已，让他直接点问，结果他来一句：“你懂建模吗？，能给我解释一下建模的作用吗？〞，接着他出了一个小例子，让我对这个例子进行建模，要考虑到各种扩展性、业务稳定性的关键点，要边建模边说出为什么要这么建模，要说出思路。他最终重点强调了一下：“创立出来的模型是不允许跟任何具体的代码、工具有关联的〞。

在我现在看来，他的意思也就是说创立出来的UML类图模型是领域无关模型（领域通用模型），可以用任何一种编程技术去实现他，作为建模者不需要考虑这些实现细节，考虑的越多越简单分散你对真实业务的等价建模，简单犯技术人员的通病（用技术的思维来考虑业务）。

我当时心想这个简单啊，不就是用UML搞点图出来做做秀嘛，表达出分析、设计的高端嘛，其他还能有啥作用；其实我当时之所以这么想是由于我对UML、建模也尝试过学习、理解和运用，结果我发现这就是一个作秀的工具罢了，对这个东西很不屑，甚至对软件工程中的“建模〞领域有一种抵触心理。

我当时随口说了一些我学习UML建模时的心得，心想这个也就是最终答案了，由于它确实就是这个作用（“作秀〞），然后我通过代码驱动建模，倒着推导出UML的类图，结果和我意料的差不多；基本上都覆盖了这个小例子的几大方面，反正面试官不知道我是如何得出这个UML类图的，只有天知道，我是通过先构建代码模型然后反方向推到出类图模型的，嘴上说的跟心理想的完全是相反的。

在我感觉十分良好的等着面试官接着问下一个问题的时候，状况出现了。面试官说我漏掉了东西，说我没有充分考虑到业务场景，没有将业务概念中的关键

概念划明显了，甚至疏忽了很重小的领域实体属性，依照我这个模型图开发出来的软件是不能够满足现在的业务要求的。我当时就蒙了，啥叫关键概念，哪个概念不是关键概念啊，又有哪里不能用了，心理有点委屈，一时不理解，觉得面试官在难为我。

其实我现在能明白当时面试官说的是什么意思，他是指我未能明了的表达出各个类的职责，看上去每个类扮演的角色都是一样的，无非就是属性、方法这些类元素，我未能捕获到核心领域概念，未能站在领域考虑建模，而是站在代码的层面上来从低往上看的，好多东西是看不明白的，说白了，开发人员拿到这个类图能否明白自己将要面对的领域，假使能明白，此时类图模型是健康的，假使不明白那就是有问题的，由于模型图不是给自己看的，而是给整个团队交流共享的。

后来我自己调整了一下心情，就算面试失败我也要有总结才行，面试本来就是一个被虐的过程。（“佛曰：此时正是修行时〞，就当是锻炼好了。）

我虚心的向面试官请教我这个模型图哪里有问题，他指出了有可能我这辈子都无法看见的分析盲点，他说这个问题是程序员用技术思维来分析建模的通病。为什么他能看见这些盲点，而我不能，我很想知道这其中的精华，我当时就要求降薪到这里来学习，面试官不降薪愿意让我过来，他也是一个对技术有追求的人吧。但是后来我有特别事情未能去贵公司就职，此后我一直惋惜，这个建模精华我有可能一辈子都搞不懂了。

现在我能明白，其实假使用代码级别的分析思维来辅助你建模就一定会有盲点，由于代码级别的“设计模式〞，“设计原则〞并非建模时的“分析模式〞，这是两个不同的问题域，也就是说彼此用在不同的业务领域的，不能够一概而论，假使交织使用就会误导你目前的重心，你会往里面添油加醋。

“建模〞这个十分抽象且神圣的词是多么的霸气，貌似是已经触及软件工程的最高境界了；崇拜，自卑；搞软件开发也有几年了，竟然连建模都不懂；那一夜我完全失眠了，从那以后我在技术上充满了无助感，为什么？由于我已经明白自己要想在软件领域有一定的成果，必需学会对真实世界建模，从那开始“建模〞一词在我脑子的已经和UML关系不大了。

之后我在软件分析、设计的海洋里苦苦寻觅这个曾经在我面前就像流星一样划过的“建模金钥匙〞，有了它我就可以去一个神圣的世界。辗转反侧几年过去了，在前不久我终究知道“建模的金钥匙〞是什么了，这类东西在网络上很少见，写的很少，下面我们来详细了解它。

2.问自己，UML对你来说有意义吗？它帮助过你对系统的分析、建模吗？我想学过软件开发的人都多多少少了解UML，简单讲它就是一个用来建模的语言，你可以纯粹的把它理解成是一个画图工具，定义了一些元素，用来表达不同的概念。这里我们关心的是UML类图，也就是用来进行面向对象结构建模用的，通过各种不同的图形来表达抽象的对象结构。

图1：简单的订单类图

上图是一个很简单的“订单〞与“产品〞相关的类图，我们都能懂这里面的意思，由于我们对这块的业务很了解；知道在什么地方应当有什么，譬如Order中的计算商品总价的算法，有相关业务背景的人都知道这里是会存在的极大规律变化的地方，所以我们需要通过接口来隔离这块规律。

我们之所以能够画出这张类图跟UML这个语言本身其实没关系，重要的是你对相关的业务十分之了解，在你脑子里可以不使用UML来建模，你可以用任何一个草图来建模，也就是说UML并不等于建模，这个要明白的认识。那我们使用UML有何用？它并没有帮助我们来分析系统；没错，UML从某个角度讲它没有直接帮助我们对系统尽心分析建模，帮助我们分析建模的是那些业务知识，懂业务的人可以不使用UML来建模，随便用一种图形表示法来说明业务概念即可。其实UML只不过是一个通用的模型表达语言而已，是用来帮助我们交流模型用的，并非是建模的思想和方法。

既然UML不能够帮助我们分析系统，那我们如何才能确凿的建模出我们不是很熟悉的领域呢？我们必需承认，领域专家假使懂技术确定是建模的最适合人选，但是现实并非这样，需要我们技术人员去熟悉领域然后创立模型，但是这中间难免会漏掉重要的业务概念，由于终究从真实的业务到最终的模型是有一个过程的，而最让我们无助的是在这个过程中没有任何可行的指导思想可以借鉴的，只有通过经验来把握最终的质量。

总是通过经验来建模不符合软件行业的发展方法，显然不行，这种建模技术莫非不可以传递吗？答案是可以传递的，说明这个可以传递的技术正是本文的目的。我们继续往下看。

3.一直以来其实我们被一个缝隙隔开了，使我们对OOAD遥不可及上节中其实已经抛出建模的核心问题域了，只不过不是很明显；我们用本节来重点突出这个长久以来一直困扰我们建模者的问题域，以引起我们对它的重视，由于它也是软件工程中的一个重要的研究领域。

如本节标题所说，其实我们被一个建模时所产生的一个缝隙隔开了，而这个缝隙很长一段时间内没有人关注过，也没有引起相关重视，所以导致我们的建模技术很难提升。

建模是一个过程，这个过程大约是这样子的，需要我们将真实的业务场景确凿的用某种建模语言表达出来，换句话说用什么建模语言表达出来很简单，重点是如何得出这个模型，而得出这个模型的过程就是我们这里所说的建模缝隙。

图2：

从“业务概念〞到“类模型〞中间夹着一个“建模过程〞，这个地方其实一直以来就是分析建模的鸿沟，这个空白的地方一直没有成熟的经验可以学习。在我们对当前分析的业务不是很了解的时候如何正确