模型驱动开发(MDD)的未来

目前公司所从事的项目是采用建模方式实现WiMAX的呼叫处理的,应当说是一个典型的MDD(Model-Driven Development)项目。MDD或是MDA(Model-Driven Architecture)是目前软件行业的一个热门,也是一项处在发展和完善阶段的技术。我所在的公司采用MDD开发方法,所有的业务代码都是从UML模型生成,就目前公司对于MDD开发实践的经验来看,MDD还有很长的路要走。MDD在未来要被大型项目广泛采用,我想以下几点是必需要得到解决。
 
1)模型的合并(Merge)问题。我们知道对于小型的软件项目,开发人员相对少,而且项目也不复杂,那么对于并行开发所出现的合并问题,应当说所花的代价可能相对的少。但对于大型项目,我们不得不考虑多个开发子团队同时并行开发时,模型的合并所花费的代价。更有可能,合并的花费造成并行开发成为不可能。根据我们的经验,在我们开发人员大约在50人左右时,合并问题就已经是一个令人相当头痛的问题了。当前,公司采用MDD的几个产品都不想继续采用MDD,但是要完全抛弃MDD,需要很大的工作量,所以现在大家都处于煎熬当中。以图型表达为开发方式的MDD,应当说如果只是将其运用于需求分析,或是概要设计还是可以的,但如果将其运用于详细设计以及最终由其生成代码,那么MDD必须要找到一种如的方法(算法)来解决图型的合并问题。与代码合并所不同的是,图形的合并更为复杂。
 
2)模型的测试问题。代码单元测试(Unit Test)是目前软件行业广泛采用的软件开发测试方法,采用MDD开发方法,我想也必然要面对与代码单元测试相似的问题,或说需要模型的单元测试方法,而模型的单元测试我想更为复杂。这一点不得到解决,我们是很难相信其质量的。
 
3)可读性和可维护性问题。对于代码我们往往可以找到一个入口(类似于C中的main函数),通过从入口入手,我们可以慢慢的摸清软件是如何实现其功能(或是行为)的,但对于建模工具来说,这一点有可能不是这么直观。目前我们所采用的建模工具就存在类似的问题,往往要知其所以然,还得花不少的功夫。此外,模型所采生的代码往往其可读性很差,就目前我的经验来看可以说是“非人能读的”,而建模工具往往自身也是有问题的,有时,不得不从其生成的代码中通过调试来找到问题,这可以说是另一种煎熬。
 
综上所述,个人认为MDD的思想是好的,而且运用在一定的场合会带来很大的好处,毕竟图形有一个先天的好特性“一幅(好)图胜过千言万语”,但要将MDD运用到代码生成级,那,MDD还有很长的路要走。

你可能感兴趣的:(职场,模型,休闲,MDd)