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

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

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

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

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