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

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

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

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

上节中其实已经抛出建模的核心问题域了，只不过不是很明显；我们用本节来重点突出这个长久以来一直困扰我们建模者的问题域，以引起我们对它的重视，因为它也是软件工程中的一个重要的研究领域。

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

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

图2：

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