OO系统分析师之路.pdf

OO系统设计师之路--分析模型系列（1）--什么是分析模型 作者: coffeewoo() 分析模型是采用分析类，在系统架构和框架的约束下，来实现用例场 景的产物。 分析模型是高层次的系统视图，在语义上，分析类不代表最终的实现。 它是计算机系统元素的高层抽象。 笔者认为分析模型正是OO设计的核心，而设计类只是OO的实现手段。 分析模型是MVC模式的经典应用。对比分析类的名称，MVC模式，读 者应该能够发现分析类在OO和商业目标中精妙的对应关系：人，事， 物，规则--actor,boundary,engity,control。这就是为什么笔者说 分析模型是OO设计的核心。 （让关心OO之路列的朋友们久等了，今天正式开始推出之路系列的 第二部，OO系统设计师之路。在第一部OO系统分析员之路中，我们 始于什么是用例，结束于需求规格说明书。我们还记得在第一部中， 最后的结果是系统用例。系统用例规定了系统范围，通过用例场景， 规定了系统蓝图，让我们知道了系统将如何实现业务用例中规定的业 务。这些工作，是由系统分析员来完成的。到这里为止，我们还不知 道如何让计算机来执行这些业务。大家都知道，在需求过程结束后， 即将进行的是分析设计过程，这是系统设计师的职责。OO之路第二 部正是针对系统设计师的，笔者将试图在接下来的文章里，说明如何 做系统设计，要运用哪些工具，产生哪些结果，以及如何来验证我们 的设计是否正确。 这是设计师之路的第一篇，笔者要讨论的是分析模型。我们经常会听 到分析模型这个词，但真正懂得，或者用过分析模型的人却少之又少。 下面笔者将写下一段对话，这段对话是笔者在招聘设计师的过程中与 许多应聘者对话的场景模拟。90%以上的应聘者都不能很好的回答这 些问题。读者也可以试着回答，看看你对用UML进行OO系统设计有 多深的了解。 对话场景： -在需求过程结束以后，接下来你会做什么？ -分析设计 -你的设计依据是什么？ -需求结果，用例模型 -你是如何设计的？设计的结果是什么？ -设计类图，确定类的方法和属性，会用时序图来表达类之间的交互。 还有会应用设计模式来增强系统的扩展性和复用能力。 -那你是如何确定出类来的呢？比如针对一个特定的需求，为什么你 决定用三个类而不是五个类？类方法又是如何确定的呢？为什么设 计七个方法而不是十个方法？ -短暂沉默后：经验啊，从我多个项目的设计经验和实际情况来看， 用这几个类和这些方法完全可以满足业务要求，并且是经过优化的， 是最好的方案。 -那么你如何能够保证，或者，你用什么来证明，你的设计能够满足 需求呢？除了经验之外，你能用什么方法来证明呢？ -沉默之后:我有很丰富的设计经验，我的设计是经过深思熟虑的。设 计会经过评审，讨论和充分的沟通，后面还有测试，不满足需求时会 再进行修改和补充的。 -刚才你也说了，需求结束后你将进行分析设计的工作。你能说说分 析和设计的差别吗？分析做什么，设计做什么？ -更长时间的沉默：分析和设计是同一个过程，分析是想的过程，设 计是把想的内容用类表达出来。 -我们知道在UML里有分析模型和设计模型，如果分析和设计是同一 个过程，你能说说分析模型和设计模型的区别吗？ -沉默... 是的，的确是这样。很多人分不清分析和设计不同的目标，没有使用 过或根本不知道分析模型。更多的人无法回答他的设计如何能够被证 明是满足需求的，那些类在他们看来，都是凭经验，如同精灵一般从 脑子里蹦出来的。他们很自信自己的经验和设计能力，津津乐道于一 个又一个设计模式，他们认为，如此优秀的设计怎么会不满足需求 呢？证明？很奇怪的问题，我设计的目的就是为了满足需求，不满足 需求的设计我会不断改进啊，最终它一定是满足的啊。 可惜这并没有回答我的问题，我问的是如何证明，而不是是不是满足。 即使设计师拥有丰富的经验和超强的设计能力，设计结果的确满足了 需求，并且很优秀，但那只是结果而不是过程，那是个人英雄的胜利， 而不是软件过程的胜利。 事实上，这一切问题，都只是因为设计师们遗忘了很重要的一个过程， 分析模型。那么什么是分析模型呢？为什么分析模型能够解决这些问 题呢？ RUP里对分析模型和分析类的定义是：分析类用于获取系统中主要的 “职责簇”。它们代表系统的原型类，是系统必须处理的主要抽象概 念的“第一个关口”。如果期望获得系统的“高级”概念 性简述， 则可对分析类本身进行维护。分析类还可产生系统设计的主要抽象： 系统的设计类和子系统。 如果你对上面的定义感到迷惑不解（RUP的定义一向如此），下面是 笔者在实际工作中对分析模型的理解和应用经验，或许可以帮助