欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

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

程序员文章站 2022-03-02 19:32:37
...

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

 

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

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

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

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

 

相关文章:

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