阅读文件夹：

• 1.背景介绍
• 2.问自己，UML对你来说有意义吗？它帮助过你对系统进行分析、建模吗？
• 3.一直以来事实上我们被一个缝隙隔开了，使我们对OOAD遥不可及
• 4.四色原型模式填补这个历史缝隙，让我们真的看见OOAD的希望
• 5.在四色原型上运用彩色建模增强视觉冲击力
• 6.通过四色原型模式建模出领域无关模型
• 7.结束语：建模时你能够不考虑详细实现，可是建模者要懂技术实现

1.背景介绍

至今我都清楚的记得我第一次被面试官问起什么叫”建模“技术时的情景，那是好几年前的事情了。当时是胸有成竹的去面试一个有关系统分析、设计的.NET高级软件project师岗位。面试官差点儿没问我有关.NET方面的不论什么技术实现。他就简单的问了问：“你怎样把握你所分析出来的系统的正确性？”，我当时有点小激动，认为这个问题应该非常easy嘛。都是概念而已，让他直接点问。结果他来一句：“你懂建模吗？，能给我解释一下建模的作用吗？“。接着他出了一个小样例，让我对这个样例进行建模，要考虑到各种扩展性、业务稳定性的关键点，要边建模边说出为什么要这么建模，要说出思路。他最后重点强调了一下：“创建出来的模型是不同意跟不论什么详细的代码、工具有关联的”。

在我如今看来，他的意思也就是说创建出来的UML类图模型是领域无关模型（领域通用模型），能够用不论什么一种编程技术去实现他。作为建模者不须要考虑这些实现细节，考虑的越多越easy分散你对真实业务的等价建模。easy犯技术人员的通病（用技术的思维来考虑业务）。

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

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

在我感觉非常良好的等着面试官接着问下一个问题的时候，情况出现了。面试官说我漏掉了东西，说我没有充分考虑到业务场景。没有将业务概念中的关键概念划分清楚，甚至疏忽了非常重小的领域实体属性，依照我这个模型图开发出来的软件是不可以满足如今的业务要求的。我当时就蒙了，啥叫关键概念，哪个概念不是关键概念啊，又有哪里不能用了。心理有点委屈。一时不理解。认为面试官在为难我。

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

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

我虚心的向面试官请教我这个模型图哪里有问题，他指出了有可能我这辈子都无法看见的分析盲点，他说这个问题是程序猿用技术思维来分析建模的通病。

为什么他能看见这些盲点，而我不能，我非常想知道这当中的精髓。我当时就要求降薪到这里来学习，面试官不降薪愿意让我过来，他也是一个对技术有追求的人吧。

可是后来我有特殊事情未能去贵公司就职。此后我一直遗憾，这个建模精髓我有可能一辈子都搞不懂了。

如今我能明确，事实上假设用代码级别的分析思维来辅助你建模就一定会有盲点，由于代码级别的“设计模式”，“设计原则”并不是建模时的“分析模式”，这是两个不同的问题域。也就是说彼此用在不同的业务领域的。不可以一概而论。假设交叉使用就会误导你眼下的重心，你会往里面添油加醋。

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

之后我在软件分析、设计的海洋里苦苦寻找这个以前在我面前就像流星一样划过的”建模金钥匙“。有了它我就能够去一个神圣的世界。辗转反側几年过去了。在前不久我最终知道“建模的金钥匙”是什么了，这类东西在网络上非常少见。写的非常少，以下我们来具体了解它。

2.问自己。UML对你来说有意义吗？它帮助过你对系统的分析、建模吗？

我想学过软件开发的人都多多少少了解UML。简单讲它就是一个用来建模的语言，你能够纯粹的把它理解成是一个绘图工具，定义了一些元素。用来表达不同的概念。这里我们关心的是UML类图。也就是用来进行面向对象结构建模用的，通过各种不同的图形来表达抽象的对象结构。

图1：简单的订单类图

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

我们之所以能够画出这张类图跟UML这个语言本身事实上没关系，重要的是你对相关的业务很之了解，在你脑子里能够不使用UML来建模。你能够用不论什么一个草图来建模，也就是说UML并不等于建模。这个要清楚的认识。

那我们使用UML有何用？它并没有帮助我们来分析系统。没错，UML从某个角度讲它没有直接帮助我们对系统尽心分析建模。帮助我们分析建模的是那些业务知识。懂业务的人能够不使用UML来建模，随便用一种图形表示法来说明业务概念就可以。

事实上UML仅仅只是是一个通用的模型表达语言而已，是用来帮助我们交流模型用的，并不是是建模的思想和方法。

既然UML不可以帮助我们分析系统，那我们怎样才干准确的建模出我们不是非常熟悉的领域呢？我们必须承认。领域专家假设懂技术肯定是建模的最适合人选。可是现实并不是这样。须要我们技术人员去熟悉领域然后创建模型，可是这中间难免会漏掉重要的业务概念。由于毕竟从真实的业务到终于的模型是有一个过程的，而最让我们无助的是在这个过程中没有不论什么可行的指导思想可以借鉴的，仅仅有通过经验来把握终于的质量。

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

3.一直以来事实上我们被一个缝隙隔开了，使我们对OOAD遥不可及

上节中事实上已经抛出建模的核心问题域了，仅仅只是不是非常明显；我们用本节来重点突出这个长久以来一直困扰我们建模者的问题域，以引起我们对它的重视，由于它也是软件project中的一个重要的研究领域。

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

建模是一个过程。这个过程大概是这样子的，须要我们将真实的业务场景准确的用某种建模语言表达出来。换句话说用什么建模语言表达出来非常easy，重点是怎样得出这个模型，而得出这个模型的过程就是我们这里所说的建模缝隙。

图2：

从“业务概念”到“类模型”中间夹着一个“建模过程”。这个地方事实上一直以来就是分析建模的鸿沟。这个空白的地方一直没有成熟的经验能够学习。在我们对当前分析的业务不是非常了解的时候怎样正确的建出相应的类模型，表层的领域概念我们能够依据自己的经验去够发现它，可是这毕竟是无法传递的知识。非常多OOAD的书籍甚至包含非常多软件project中的经典书籍都未给出这里的答案，假设用一句准确的技术术语来形容这个过程的话，事实上就是缺少一套建模分析模式。缺少一个能够让我们无论针对什么样的业务进行分析时都是一套不变的指导模式。我想这个问题对我们建模者来说肯定是共同的问题，我们须要解决它。仅仅有这样我们才不会遇见自己所不熟悉的业务领域时而束手无策，当然你能够说你也一样能够进行OOA，可是你一定会漏掉什么的。这是分析盲点，是没有正确指导思想的必定结果。正如上图中的”下订单“和”退货“两个核心的领域模型未能在右边的”类模型“中建模出来，大部分开发者的通病就是无法识别出潜在的领域概念，觉得”表层“ 的领域概念就是类模型中的”实体“，事实上这样我们到最后就回到了表驱动的开发过程其中去。由于你仅仅有通过E-R模型来思考时才干发现这样的平面的结构，可是这又和正确的软件开发訪问论背道而驰了。

4.四色原型模式填补这个历史缝隙，让我们真的看见OOAD的希望

本节我们将讨论一个分析模式，它存在有一段时间了。值得我们高兴的是它就是专门用来解决上述小节中阐述的“分析”鸿沟的，通过这套模式我们差点儿能够分析不论什么一个业务领域，再也不用怕因为自己对该领域不熟悉而漏掉了重要的领域模型，而导致代码混乱、难以重构的最大问题就是丢失重要的领域概念。让各个对象的职责未能正确的在自己的空间中。

这个分析模式就是”四色原型“模式，依据名字我们就能够大概猜出它是基于四个概念来分析我们的业务概念。以下我们来了解一下哪四个概念：

1.实体：也能够叫做物品，表示一个參与者，比方：客户、商品。

2.角色：实体、时刻时段的角色，如：订单的配送类型，用户的等级角色。

3.描写叙述：用来对实体、时刻时段的公共属性进行描写叙述。比方：客户实体的地址描写叙述，这部分信息是能够通用的。

4.时刻时段：实体在某个时间段内的參与事件。如：订单。某个客户在某个时间段内购买了某个商品。

此概念就是用来跟踪实体发生的全部须要跟踪的事件。

当我们使用四色原型模式去分析业务概念时就非常难丢失领域概念。以下我们依旧以上面的业务领域为例使用四色原型模式进行分析。

图3：

基本上我们能够使用四色原型模式去直接套某个业务领域，我们能够依据模式的思想来判断领域模型是否须要四色中的一种。

这样我们基本上不会漏掉重要的业务概念。通过将“四色原型”模式与“RUP"制品中的“业务词汇表”、"补充性规格说明“集合能够完毕美妙的OOAD敏捷过程。

使用四色原型模式来验收RUP过程制品中的业务词汇表，能够判断出自己是否遗漏了重要的业务分支。

能够说四色原型模式是通往OOAD之门的金钥匙，有了它我才相信我们如今分析的系统是OO的。

模型是让人去阅读理解的，上图中我们非常难看出哪个是”实体“哪个是”角色“哪个是”时刻时段“和”描写叙述“。所以大师们借鉴了其它领域的彩色思想来创建软件模型，这样我们就够能一眼的看出模型的具体意思，带来强大的视觉冲击力。下节我们具体的来看看彩色建模。

5.在四色原型上运用彩色建模增强视觉冲击力

为了可以突出模型的视觉效果，在四色原型上运用不同的颜色来添加模型的视觉冲击力。

使用彩色模型可以激发人类天生的视觉敏感性，让人一目了然的知道总体的模型是个什么结构。

图4：

使用绿色来表示实体（參与者），使用黄色表示角色，使用灰色表示描写叙述，使用桃红色表示时刻时段。

当然这里的颜色不是非常准确。因为我对颜色分的不是非常清楚，所以未能调出最合适的颜色，可是差点儿相同也即可了。

这样当我们面对一个大型的UML类图模型时就能够一眼识别出每一个模型所代表的概念它的职责也就清晰明了了。

6.通过四色原型模式建模出领域无关模型

建模时我们是不须要考虑该模型将要被什么技术落地，也就是说该模型是领域（技术、工具、平台）无关的。能够使用不论什么技术来实现它。

通过四色原型模式构建出来的模型图更具有可塑性。概念非常的清晰，全部的模型都是概念明白的，不存在人为的设计在里面，对于不论什么一个建模者来说这是非常宝贵的建模技术。

如果没有四色原型模式的背景，每一个建模者都依据自己的经验来如果出非常多主观的模型出来，事实上这部分模型是非常难让别人理解的。由于每一个人的理解角度不同，得出的模型自然也就区别非常大，所以建模时使用四色原型模式是一个比較通用的模式。得出的最后模型也是一个通用的且团队交流也是通用的。

技术无关是领域无关模型的一个面，领域无关也有另外一层含义，当我们有了四色原型模式时你是否发现你具有了征服全部业务领域的秘诀，就好比E-R模型一样，一个能够用无边际的抽象的模式，这个模式由四色主要的原型组成，而这个四个原型也是领域无关模型。

7.结束语：建模时你能够不考虑详细实现，可是建模者要懂技术实现

虽然建模高手会告诉我们建模时不要去考虑最后详细用什么技术去实现它。事实上跟你说这个话的人要么就是精通某个技术的高手，要么就是一个理论主义者。仅仅知道绘图而不知道怎样详细落地领域模型的分析员，前者事实上他已经做到心中有数了，为什么这么说，由于不懂技术实现的人来建模时是无法创建出能用的模型的。由于概念毕竟是概念。一旦落地到代码上、架构上一切都变了。并非那么的简单直接落地的。须要考虑到读写、业务流、职责等等问题。这里面是有非常强的技术问题在里面的。

好了文章到此结束。希望本文能对那些对OOAD、UML、建模有兴趣的朋友起到一个抛砖引玉的作用。对本文的内容想进一步学习的能够參考《彩色建模》一书，这本书是OOAD大师[Peter coad]所著。谢谢大家。

作者：王清培

出处：http://blog.csdn.net/wangqingpei557

本文版权归作者和CSDN共同拥有，欢迎转载，但未经作者允许必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法权利义务的法律。