目前公司所从事的项目是采用建模方式实现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还有很长的路要走。