滞后的软件建模将去向何方？
软件产业在找到解决软件结构与交付方法的根本问题的办法的同时，它也在积极地更新软件建模以适应当前的SOA和敏捷开发实践。下面是正在解决中的一些主要问题：
- UML与典型的、瀑布交付过程的、面向对象的设计技术有很深的渊源
- UML最初是一种需求归档方式，而非用来生成软件
- 主流架构已经从面向对象转向面向服务
- 主流方法已从瀑布方法转向敏捷方法
- 有新的需求要利用建模来创建完整的软件方案
- 统一建模语言（UML）的核心思想尚未做出更新以适应这些转变
以下对UML的批评已经持续多年：
- 语言臃肿。UML常因不必要的庞大和复杂而受到批评。它包含太多多余的或者很少使用的图示和构造。其中UML2.0受到的这类指责要多于UML1.0，因为新版本的修正在“委员会式的设计”方式上做了更多妥协。
- 学习与采用上的困难。上述问题使学习与应用UML成为一个难题，特别是在管理层强迫缺乏必要技能的工程师使用UML时。
- 只有代码才能与代码同步。有不同的观点认为，只有可运行的系统才是最重要的，而不是漂亮的模型。
- 累积阻抗/阻抗失配。和任何其它符号系统一样，UML能更简洁、更有效地描述一个系统。因此，开发人员要尽力寻找能够将UML与编码语言的长处完美结合的非常好的方案。如果所用的编码语言无需遵守保守的面向对象的设计方式，这个问题会尤为突出。
- 试图成为功能较多语言。UML是一种希望能够与各种实现语言都兼容的通用建模语言。以一个具体的项目为例，设计团队必须限定UML最合适的用途以取得既定的目标。而将UML的使用范围限制到特定领域的方法本身便饱受批评，尚未成形。
敏捷方法强调可用、可验证的软件，而不是臃肿的需求过程。这暗示着可用的软件可以成为用户与技术人员之间沟通的桥梁。为达到这个目的，就要尽可能快地交付可用的软件。在软件建模能够成功地融入SOA和敏捷方法之前，必须满足如下几个关键的要求：
- 让利益相关人参与建模过程
- 迅速创建可用的原型
- 原型要可以长期使用而不能被废弃
- 自我描述与归档
- 包含面向服务的概念
- 基于XML并且技术中立
- 涵盖集成与分布的概念
- 容易被大众理解
如果软件建模能满足以上标准，那么软件产业将可直接通过新方法交付面向服务的软件。这个模型有描述软件需求和生成可用方案的双重作用，使所交付软件的质量更高、迭代周期更短。对建模中曾经面临的技术与方法上的困难进行分析还会获得更多的益处，包括：
- 同步的需求与实现
- 更快更频繁的迭代
- 利益相关人之间的关系更为紧密
- 更好的可预测性
- 需求与架构的一致性
- 提高生产效率
- 减少浪费
- 广泛的应用
