在软件构造过程中，会用到两种模型：系统分析模型和系统设计模型。

系统分析模型

系统分析模型又称为问题空间模型，它根据实物——即准备实现的系统参照物——展开工作。系统分析首先考察实物的结构和组织，然后考察系统行为、方法，对系 统进行逐步分解并对分解出来的组成部分进行研究，理解其内容、形式、组织方式、行为规则等，在这个过程中积累知识，形成系统分析模型。

系统分析从系统的整体和高级知识入手，经过行为、方法的分析到达系统的底层，即数据层次。这个过程是一个思维发散的过程。系统分析要求建模人员尽量多的考虑系统中的各种因素，举一反三，只要合理的东西都应该在模型中体现。

一般来说，系统分析进行到数据层次，即行为、方法的分析完成之后，其模型就可以做为系统设计的输入，开始系统设计了。但这个时候系统分析做为一个建模过程 并未停止，对数据层次的建模和系统设计重合，这也就是我们平时所说的（面向对象的）系统分析和系统设计没有明显的界限。实际上在这里，在数据建模的层次， 系统分析和系统设计是重合的。

系统设计模型

系统设计模型也叫做解决方案模型，它的构造是针对并不存在的目标系统进行的。根据系统分析的馈入，系统设计和系统分析一起针对系统的数据层次进行建模。对 系统的数据建模，导致基本的实体对象模型产生。在这个基础上，系统设计针对系统的行为和方法进行建模。在系统行为建模完成后，再对系统的结构和组织进行建 模。可以看到，系统设计建模过程是从系统的较低层次走向系统的高级层次，最终形成系统设计模型。

系统设计建模过程是一个思维收敛的过程。根据系统分析的结果，系统设计人员对多个可选的方案进行取舍，选择合适的方案实现。如果说系统分析是一颗逐渐长大的树，则系统设计是对树的修正，使其成为一个最低成本的实现模型。

我们在软件构造过程中使用的模型是系统分析模型和系统设计模型的集合，称为表示模型。

在《小议模型》一文中我已经提到，现今国内软件开发过程中产生的模型是不完整、不准确的。这也体现在：表示模型并不是由完整的系统分析模型和系统设计模型组成，通常由于种种原因，系统分析模型存在比较大的问题。

一般来说，一个比较好的表示模型应该由相对平衡的系统分析模型、系统设计模型组成。系统分析模型中的某个部分，一定在系统设计模型中有一个对应的部分，它 们共同描述同一组件（集）。这两个部分是一致的，区别是一个由分析过程生成，一个由设计过程生成。对于这点，最普遍的一个误解就是：我这边已经有了，为什 么那边还要有一套？

这个问题的答案很简单。在《小议模型》中，我们已经解释了语义间隙这 个概念，现在来看系统构造过程中的语义间隙。从大的方面来讲，系统是这样产生的：实物->分析模型->设计模型->实现的系统。这中间 基本上都存在语义间隙，尤其以实物到分析模型之间的间隙为最。试想，如果没有分析模型，没有分析模型中这看上去似乎多余的东西，这中间的语义间隙会有多 大？这不是猜想，这是曾经发生的事实，这是经验教训。

那么对于规模较小的系统，又是怎么样呢？和大规模的系统是一样的。小系统就没有语义间隙吗？大小只是规模不同而已，实质是一样的。所谓麻雀虽小，五脏俱全。

模型粒度

最后来谈谈模型粒度的问题。简单的说，就是模型到底要做到多细？模型最基本的要求就是要准确、易理解。对于一个过粗的模型，其准确性可能存在问题；对于一个过细的模型，其理解上可能又存在困难。而不粗不细，折中考虑，平衡点又在哪里呢？

其实就系统分析模型来讲，主要就是要缩小其与实物之间，与设计模型之间的语义间隙。面对实物，要求模型表达准确；面对设计模型，要求表达清晰。这个基本上 靠个人水平了。我的方式是保证准确性，在这个前提下，用多几个“包”来分解，这样也基本上可以做到“清晰”。这个包，当然不是将来要设计实现的东西，仅起 到辅助表达的作用。

而对于设计模型来说，一个非常详细的设计模型可以直接生成代码，这就大大缩小了设计和实现之间的语义间隙。但毕竟设计不等于实现，一个精细的算法还是要靠 编码人员完成，这就不得不考虑设计模型的易理解性。这里我的建议是：设计模型可以做的比较细，但模型在表达上要尽量考虑易理解性。举例来说：一个EJB可 以在设计模型中对应到四个接口和一个实现类，但是在类图中，我们完全可以只画出实现类，使用stereotype标示其为EJB。这样即可以生成代码，又 不妨害理解。

后记：这篇随笔来自于我最近做的一次培训，删掉了其中关于“系统知识层次模型”的部分。原因是该模型存在问题，反而可能造成理解上的偏差。如果大家对此感 兴趣，或者有什么其他问题，可以讨论一下。如果可能（我自己也不是很确定），还会有下一篇，或许应该叫《又议模型》吧。^_^