谈谈分析模型的那些事儿之开始分析

——对分析模型的一点儿见解

当需求分析结束、需求确认完成、需求讨论告一段落的时候&＃xff0c;我们的需求分析员拿出了厚厚的一打用例分析模型、领域设计模型&＃xff0c;需求分析阶段结束&＃xff0c;开始进入开发阶段。但是&＃xff0c;这时候虽然需求分析阶段结束了&＃xff0c;却千万不要以为需求分析就结束了&＃xff0c;如果你还这样认为&＃xff0c;说明你还没有摆脱瀑布式开发的思维。瀑布式开发的思维的关键点就是认为&＃xff0c;需求分析阶段应当完成所有的需求分析和确认的工作&＃xff0c;否认需求分析阶段以后还会变更需求。拥抱变化是现代软件开发思想的核心之一&＃xff0c;什么敏捷开发、迭代开发、极限编程&＃xff0c;都是围绕这个主题展开的。拥抱变化&＃xff0c;意味着我们的软件需求总是在变化&＃xff0c;因此需求分析文档&＃xff0c;包括用例模型、领域模型&＃xff0c;总是在与之同步。总之&＃xff0c;不要期望在需求分析阶段就完成所有的事&＃xff0c;在分析设计&＃xff0c;以及之后的编程开发阶段、实施和维护阶段&＃xff0c;我们都应当随时与客户保持联系&＃xff0c;注意与他们的反馈。

在需求分析阶段结束以后&＃xff0c;许多公司&＃xff08;包括我们&＃xff09;通常的做法都是立即进入开发编程阶段。开发人员与需求人员坐在一起开了一个简短的动员会&＃xff0c;按照模块和功能的划分&＃xff0c;给所有的人进行一次任务分配&＃xff0c;紧接着开发人员就领着自己的任务开始埋头开发。诚然&＃xff0c;几乎所有的开发任务时间都是非常紧张的&＃xff0c;但是没有经过规划和设计的系统&＃xff0c;往往是无序和低效的。那些我在《谈谈软件开发的那些事儿》中提到的噩梦就是这样开始的。随意地创建对象&＃xff0c;随意地分配属性和方法&＃xff0c;随意地相互调用&＃xff0c;都会大大降低软件的可维护性。一个小小的变更&＃xff0c;就会让我们的软件大动筋骨&＃xff0c;从何谈起拥抱变化呢&＃xff1f;要提高软件的可维护性、可变更性&＃xff0c;就必须让我们的设计低耦合、高内聚&＃xff0c;也就必须做到职责驱动设计&＃xff08;RDD&＃xff09;。建立必要的分析模型和设计模型&＃xff0c;可以帮助我们做到这一点。

分析模型和设计模型就是在需求分析结束后、程序开发开始前的这段分析设计阶段使用的。按照RUP的流程&＃xff0c;应当先建立分析模型&＃xff0c;然后再建立设计模型。但是分析模型和设计模型没有明显的时间分隔&＃xff0c;通常都是经过无数次迭代&＃xff0c;从分析模型逐渐过渡到设计模型。分析模型是在不考虑任何技术实现的前提下进行的纯OO分析的模型。不论你的系统是采用J2EE实现还是C&＃43;&＃43;实现&＃xff0c;分析模型都是一样的。而设计模型则相反&＃xff0c;设计模型开始考虑具体技术的实现。因此&＃xff0c;从分析模型到设计模型是一个从抽象到逐渐细化的过程。

另一个问题是&＃xff0c;谁来完成从分析模型到设计模型的整个过程&＃xff1f;我认为&＃xff0c;应当是需求分析人员和架构分析师共同来完成。然而&＃xff0c;在实际情况是&＃xff0c;更多的工作是需求分析人员来完成的。因此&＃xff0c;那些由技术出身的&＃xff0c;拥有扎实OO分析设计基础的需求分析员在完成这些工作时会更加得心应手。下面我们看看分析模型是怎样开始分析和设计的。&＃xff08;续&＃xff09;

相关文章&＃xff1a;

《 谈谈分析模型的那些事儿 之 职责驱动设计 》