用例及领域模型

OO系统设计师之路--分析模型系列（1）--什么是分析模型

===========================================================

OO系统设计师之路--分析模型系列（1）--什么是分析模型

作者: coffeewoo()

发表于: 2006.10.30 00:02

分类: 系统分析、设计，UML及OO ,

出处: /post/9169/224686

---------------------------------------------------------------

分析模型是采用分析类，在系统架构和框架的约束下，来实现用例场景的产物。

分析模型是高层次的系统视图，在语义上，分析类不代表最终的实现。它是计算机系统元素的高层抽象。

笔者认为分析模型正是OO设计的核心，而设计类只是OO的实现手段。

分析模型是MVC模式的经典应用。对比分析类的名称，MVC模式，读者应该能够发现分析类在OO和商业目标中精妙的对应关系：人，事，物，规则

--actor,boundary,engity,control。这就是为什么笔者说分析模型是OO设计的核心。

（让关心OO之路列的朋友们久等了，今天正式开始推出之路系列的第二部，OO系统设计师之路。在第一部OO系统分析员之路中，我们始于什么是用例，结束于需求规格说明书。我们还记得在第一部中，最后的结果是系统用例。系统用例规定了系统范围，通过用例场景，规定了系统蓝图，让我们知道了系统将如何实现业务用例中规定的业务。这些工

作，是由系统分析员来完成的。到这里为止，我们还不知道如何让计算机来执行这些业务。大家都知道，在需求过程结束后，即将进行的是分析设计过程，这是系统设计师的职责。OO之路第二部正是针对系统设计师的，笔者将试图在接下来的文章里，说明如何做系统设计，要运用哪些工具，产生哪些结果，以及如何来验证我们的设计是否正确。

这是设计师之路的第一篇，笔者要讨论的是分析模型。我们经常会听到分析模型这个词，但真正懂得，或者用过分析模型的人却少之又少。下面笔者将写下一段对话，这段对话是笔者在招聘设计师的过程中与许多应聘者对话的场景模拟。90%以上的应聘者都不能很好的回答这些问题。读者也可以试着回答，看看你对用UML进行OO系统设计有多深的了解。

对话场景：

-在需求过程结束以后，接下来你会做什么？

-分析设计

-你的设计依据是什么？

-需求结果，用例模型

-你是如何设计的？设计的结果是什么？

-设计类图，确定类的方法和属性，会用时序图来表达类之间的交互。还有会应用设计模式来增强系统的扩展性和复用能力。

-那你是如何确定出类来的呢？比如针对一个特定的需求，为什么你决定用三个类而不是五个类？类方法又是如何确定的呢？为什么设计七个方法而不是十个方法？

-短暂沉默后：经验啊，从我多个项目的设计经验和实际情况来看，用这几个类和这些方法完全可以满足业务要求，并且是经过优化的，是最好的方案。

-那么你如何能够保证，或者，你用什么来证明，你的设计能够满足需求呢？除了经验之外，你能用什么方法来证明呢？

-沉默之后:我有很丰富的设计经验，我的设计是经过深思熟虑的。设计会经过评审，讨论和充分的沟通，后面还有测试，不满足需求时会再进行修改和补充的。

-刚才你也说了，需求结束后你将进行分析设计的工作。你能说说分析和设计的差别吗？分析做什么，设计做什么？

-更长时间的沉默：分析和设计是同一个过程，分析是想的过程，设计是把想的内容用类表达出来。

-我们知道在UML里有分析模型和设计模型，如果分析和设计是同一个过程，你能说说分析模型和设计模型的区别吗？

-沉默...

是的，的确是这样。很多人分不清分析和设计不同的目标，没有使用过或根本不知道分析模型。更多的人无法回答他的设计如何能够被证明是满足需求的，那些类在他们看来，都是凭经验，如同精灵一般从脑子里蹦出来的。他们很自信自己的经验和设计能力，津津乐道于一个又一个设计模式，他们认为，如此优秀的设计怎么会不满足需求呢？证明？很奇怪的问题，我设计的目的就是为了满足需求，不满足需求的设计我会不断改进啊，最终它一定是满足的啊。

可惜这并没有回答我的问题，我问的是如何证明，而不是是不是满足。即使设计师拥有丰富的经验和超强的设计能力，设计结果的确满足了需求，并且很优秀，但那只是结果而不是过程，那是个人英雄的胜利，而不是软件过程的胜利。

事实上，这一切问题，都只是因为设计师们遗忘了很重要的一个过程，分析模型。那么什么是分析模型呢？为什么分析模型能够解决这些问题呢？

RUP里对分析模型和分析类的定义是：分析类用于获取系统中主要的“职责簇”。它们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。如果期望获得系统的“高级”概念性简述，则可对分析类本身进行维护。分析类还可产生系统设计的主要抽象：系统的设计类和子系统。

如果你对上面的定义感到迷惑不解（RUP的定义一向如此），下面是笔者在实际工作中对分析模型的理解和应用经验，或许可以帮助读者理清头绪。

∙分析模型是采用分析类，在系统架构和框架的约束下，来实现用例场景的产物。在OO之路的第一部里，我们说用例和用例场景规定了业务范围和要求，如果分析类完全实现了这些用例和场景，我们就能肯定的说分析类已经满足了需求。

分析类是什么呢？一般来说，分析类有：

边界类(boundary)

实体类(entity)

控制类(control)

再加上实现用例场景需要的actor类，共四种。这些分析类将在后面的文章里详细讨论，读者现在只需要记住它们的样子。

∙分析模型是高层次的系统视图，在语义上，分析类不代表最终的实现。它是计算机系统元素的高层抽象。上述的四个分析类可以完全模拟计算机的执行过程。分析类具化以后产生真正的实现类，即所谓的设计类，也就是大多数设计师所说的类图。

∙笔者认为分析模型正是OO设计的核心，而设计类只是OO的实现手段。还记得上一部第一篇中笔者提到的复用的三个层次吗？组件级的复用实际上是通过分析模型表达的，而设计模型中的复用，只是利用了OO语言的特性，来实现复用的要求。

∙分析模型是MVC模式的经典应用。从分析类的名称就可以看出来。笔者在上一部第四篇中讲到的一个观点：“商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂