面向对象分析与设计—四色原型模式.docx

面向对象分析与设计—四色原型模式1.背景介绍至今我都清楚的记得我第一次被面试官问起什么叫“建模”技术时的情景，那是好几年前的事情了，当时是胸有成竹的去面试一个有关系统分析、设计的.NET高级软件工程师岗位。面试官几乎没问我有关.NET方面的任何技术实现，他就简单的问了问：“你如何把握你所分析出来的系统的正确性？”，我当时有点小激动，觉得这个问题应该很简单嘛，都是概念而已，让他直接点问，结果他来一句：“你懂建模吗？，能给我解释一下建模的作用吗？”，接着他出了一个小例子，让我对这个例子进行建模，要考虑到各种扩展性、业务稳定性的关键点，要边建模边说出为什么要这么建模，要说出思路。他最后重点强调了一下：“创建出来的模型是不允许跟任何具体的代码、工具有关联的”。在我现在看来，他的意思也就是说创建出来的UML类图模型是领域无关模型（领域通用模型），可以用任何一种编程技术去实现他，作为建模者不需要考虑这些实现细节，考虑的越多越容易分散你对真实业务的等价建模，容易犯技术人员的通病（用技术的思维来考虑业务）。我当时心想这个容易啊，不就是用UML搞点图出来做做秀嘛，体现出分析、设计的高端嘛，其他还能有啥作用；其实我当时之所以这么想是因为我对UML、建模也尝试过学习、理解和运用，结果我发现这就是一个作秀的工具罢了，对这个东西很不屑，甚至对软件工程中的“建模”领域有一种抵触心理。我当时随口说了一些我学习UML建模时的心得，心想这个也就是最终答案了，因为它确实就是这个作用（“作秀”），然后我通过代码驱动建模，倒着推导出UML的类图，结果和我意料的差不多；基本上都覆盖了这个小例子的几大方面，反正面试官不知道我是如何得出这个UML类图的，只有天知道，我是通过先构建代码模型然后反方向推到出类图模型的，嘴上说的跟心理想的完全是相反的。在我感觉非常良好的等着面试官接着问下一个问题的时候，情况出现了。面试官说我漏掉了东西，说我没有充分考虑到业务场景，没有将业务概念中的关键概念划分清楚，甚至疏忽了很重小的领域实体属性，按照我这个模型图开发出来的软件是不能够满足现在的业务要求的。我当时就蒙了，啥叫关键概念，哪个概念不是关键概念啊，又有哪里不能用了，心理有点委屈，一时不理解，觉得面试官在为难我。其实我现在能明白当时面试官说的是什么意思，他是指我未能清晰的表达出各个类的职责，看上去每个类扮演的角色都是一样的，无非就是属性、方法这些类元素，我未能捕获到核心领域概念，未能站在领域考虑建模，而是站在代码的层面上来从低往上看的，很多东西是看不清楚的，说白了，开发人员拿到这个类图能否明白自己将要面对的领域，如果能明白，此时类图模型是健康的，如果不明白那就是有问题的，因为模型图不是给自己看的，而是给整个团队交流共享的。后来我自己调整了一下心情，就算面试失败我也要有总结才行，面试本来就是一个被虐的过程。（“佛曰：此时正是修行时”，就当是锻炼好了。）我虚心的向面试官请教我这个模型图哪里有问题，他指出了有可能我这辈子都无法看见的分析盲点，他说这个问题是程序员用技术思维来分析建模的通病。为什么他能看见这些盲点，而我不能，我很想知道这其中的精髓，我当时就要求降薪到这里来学习，面试官不降薪愿意让我过来，他也是一个对技术有追求的人吧。但是后来我有特殊事情未能去贵公司就职，此后我一直遗憾，这个建模精髓我有可能一辈子都搞不懂了。现在我能明白，其实如果用代码级别的分析思维来辅助你建模就一定会有盲点，因为代码级别的“设计模式”，“设计原则”并非建模时的“分析模式”，这是两个不同的问题域，也就是说彼此用在不同的业务领域的，不能够一概而论，如果交叉使用就会误导你目前的重心，你会往里面添油加醋。“建模”这个非常抽象且神圣的词是多么的霸气，貌似是已经触及软件工程的最高境界了；崇拜，自卑；搞软件开发也有几年了，居然连建模都不懂；那一夜我彻底失眠了，从那以后我在技术上充满了无助感，为什么？因为我已经清楚自己要想在软件领域有一定的成果，必须学会对真实世界建模，从那开始“建模”一词在我脑子的已经和UML关系不大了。之后我在软件分析、设计的海洋里苦苦寻找这个曾经在我面前就像流星一样划过的“建模金钥匙”，有了它我就可以去一个神圣的世界。辗转反侧几年过去了，在前不久我终于知道“建模的金钥匙”是什么了，这类东西在网络上很少见，写的很少，下面我们来详细了解它。2.问自己，UML对你来说有意义吗？它帮助过你对系统的分析、建模吗？我想学过软件开发的人都多多少少了解UML，简单讲它就是一个用来建模的语言，你可以纯粹的把它理解成是一个画图工具，定义了一些元素，用来表达不同的概念。这里我们关心的是UML类图，也就是用来进行面向对象结构建模用的，通过各种不同的图形来表达抽象的对象结构。?图1：简单的订单类图上图是一个很简单的“订单”与“产品”