分析模型是采用分析类,在系统架构和框架的约束下,来实现用例场景的产物。
(让关心OO之路列的朋友们久等了,今天正式开始推出之路系列的第二部,OO系统设计师之路。在第一部OO系统分析员之路中,我们始于什么是用例,结束于需求规格说明书。我们还记得在第一部中,最后的结果是系统用例。系统用例规定了系统范围,通过用例场景,规定了系统蓝图,让我们知道了系统将如何实现业务用例中规定的业务。这些工作,是由系统分析员来完成的。到这里为止,我们还不知道如何让计算机来执行这些业务。大家都知道,在需求过程结束后,即将进行的是分析设计过程,这是系统设计师的职责。OO之路第二部正是针对系统设计师的,笔者将试图在接下来的文章里,说明如何做系统设计,要运用哪些工具,产生哪些结果,以及如何来验证我们的设计是否正确。
这是设计师之路的第一篇,笔者要讨论的是分析模型。我们经常会听到分析模型这个词,但真正懂得,或者用过分析模型的人却少之又少。下面笔者将写下一段对话,这段对话是笔者在招聘设计师的过程中与许多应聘者对话的场景模拟。90%以上的应聘者都不能很好的回答这些问题。读者也可以试着回答,看看你对用UML进行OO系统设计有多深的了解。
对话场景:
-在需求过程结束以后,接下来你会做什么?
-分析设计
-你的设计依据是什么?
-需求结果,用例模型
-你是如何设计的?设计的结果是什么?
-设计类图,确定类的方法和属性,会用时序图来表达类之间的交互。还有会应用设计模式来增强系统的扩展性和复用能力。
-那你是如何确定出类来的呢?比如针对一个特定的需求,为什么你决定用三个类而不是五个类?类方法又是如何确定的呢?为什么设计七个方法而不是十个方法?
-短暂沉默后:经验啊,从我多个项目的设计经验和实际情况来看,用这几个类和这些方法完全可以满足业务要求,并且是经过优化的,是最好的方案。
-那么你如何能够保证,或者,你用什么来证明,你的设计能够满足需求呢?除了经验之外,你能用什么方法来证明呢?
-沉默之后:我有很丰富的设计经验,我的设计是经过深思熟虑的。设计会经过评审,讨论和充分的沟通,后面还有测试,不满足需求时会再进行修改和补充的。
-刚才你也说了,需求结束后你将进行分析设计的工作。你能说说分析和设计的差别吗?分析做什么,设计做什么?
-更长时间的沉默:分析和设计是同一个过程,分析是想的过程,设计是把想的内容用类表达出来。
-我们知道在UML里有分析模型和设计模型,如果分析和设计是同一个过程,你能说说分析模型和设计模