大会的重头戏之一便是UML之父James Rumbaugh的演讲，他演讲的题目是《提升软件开发层次：模型驱动开发展望》，IBM的一位高级技术人员为演讲做了现场翻译。虽然如此，我还是没能完整地记录他的演讲，只是记下只言片语，现在再通过我自己的理解拼起来。
James Rumbaugh首先跟大家打了招呼，然后说：他五年前曾经到过中国，今天再来，发现中国的变化很大。在从南京到上海的路上，他发现一座座新的建筑拔地而起，他希望同样的变化可以发生在软件领域，他希望中国的软件工程师们可以创造出伟大的软件。
接着，他进入了演讲的正题：从多年的软件开发实践经验来看业务领域和计算机领域有着很大的差别，业务通常用自软语言表述，而计算机领域则使用相对于自然语言低级的多的计算机语言，在构建一个软件的过程中，开发人员要编写很多的代码，很多的逻辑。
那 么如何才能搭建业务和软件之间的桥梁呢？软件需要想业务靠拢，用高级语言描述业务概念，要在中间层次搭建业务和软件之间的桥梁，软件要有很好地架构，要通 过构建部件的方式构造软件。要用自动化工具生成代码而不是直接编写代码，直接编写代码看上去很简单，但会带来更大的麻烦。如果只写代码而没有设计，则不同 的开发小组很可能会重复开发、开发出来的部件也可能是有冲突的；如果不同的开发小组使用不同的交互方式，则会破坏其他人的工作。写代码还会使开发人员的工 作很多，这样的系统也非常脆弱，任何地改变都会使得系统变得无法使用。
MDA————模型驱动的架构：用高级模型描述业务概念，用这种模型构建基于某个业务平台的代码。
MDA 方法由OMG提出，在MDA中的两个重要概念是PIM和PSM。PIM是Platfoorm Independent Model，这是平台无关的起点，在这个模型中关注业务逻辑。通过Implemention Profile来描述实现的细节。PSM似乎Platform Specific Model，是平台特定的模型。通过PIM，可生成多个PSM，给予PSM则可生成具体代码。
在MDA中，需要问题领域模型，可以用 DSL/UML来描述。DSL是领域特定语言，用架构框架描述具体的实现，通过假设，减少细节，通过翻译工具生成模型。通过UML，也可以减少不必要的细 节描述，UML可应用于很多领域，通过新的UML Profile，使其可应用于特定的领域。UML Profile通过对UML的改造，可使其支持业务领域中的概念。但UML还是通用的，包含了很多重复的细节。
用DSL描述特定的概念： DSL是一种特殊的语言，有语言发和语义，针对特定领域设计，用高级概念描述业务，从而减少IT和业务之间的差距。DSL中可包含数据模式、基于DSL的 模型减少了对控制逻辑的描述。现实的开发中，DSL的例子是很多的，譬如yacc、GUI Builder、Desktop Publishing Editor、MIDI、Mathematica等等，都是DSL的体现。
还有一个例子是SDL，它是国际电信联盟的标准，描述了很多的 电信设备如交换机。Motorola、Ericsson等公司都在使用。SDL提供了复杂的手段描述复杂的电信协议。James自己也曾经和使用SDL的 公司有过很作，然而他发现他们在工具时还是有很多的困难，因为它没有包含UML工具的很多特性。并且随着时代的进步，SDL已经逐渐退出。
OMG 升级了UML，现在有了UML 2.0版本，在这个升级的过程中，把SDL的很多概念加入到UML之中，因此，我们可以把SDL做成UML Profile，这样SDL用户也可以使用UML进行软件开发，也可以使用UML工具的特性。通过这种手段，传统语言的生命力得到了延续。
DSL 有集中类型：描述式，着重于做什么，不需要详细的逻辑，就像用复杂的数学等式描述数学问题。这种DSL被很多用户使用，因为他们不需要细节。如果计算机可 以直接使用这种DSL就好了，但实际上是不行的。因此就需要命令式的DSL，把控制逻辑一行一行地详细描述出来，这种方式是非常难于使用的。
于 是人们又想出了上述两种方式的折衷，这种方式的DSL将上述两种方式结合起来，用高级方式描述问题领域，在开发的后期使用命令式的描述控制逻辑。现在非常 流行面向Aspect编程，在这种方法中，把不同的问题划分成不同的Aspect，例如如何控制安全、并发、日志等等。每一种Aspect可解决某个方面 的问题，在这种方式中，需要翻译软件把Aspect翻译成代码，翻译软件知道其中的差异和交互，可以补充需要的代码。Aspect和DSL很象，用高级语 言描述问题，用翻译搞定实现，但现有的AOP还并不好用，譬如AspectJ。在AspectJ中，翻译工具工作地并不好，开发人员依然需要描述细节，因 此James认为AOP的下一个版本需要加入转换工具才能什他的使用更加流畅。而DSL便可用于描述AOP的自动转换。
Architecture Framework
在架构设计时，首先要将大的系统分解成有完整功能、互相交互、且功能不重叠的子系统，需要描述子系统的拓扑逻辑，譬如是流水线的、星型的还是总线型的。架构的另一方面是需要描述子系统交互规则和数据格式，架构设计师还需要描述资源的使用，着些资源包括内存、进程等等。
好 的架构能更好地使用系统变化，因为变化不会自动发生，架构设计师需要为将来的变化在架构方面做好准备。好的架构有很多，譬如hooks机制。在架构设计 时，在架构中设计好测试环节也是非常重要的。举个例子，汽车发动机内部有很多的传感器，使汽车的状态可以被车上的电脑感知。在设计的过程中，先造好发动 机，再把传感器放进去是不行的，必须要在设计的时候就把传感器如何放置设计好。对于测试，也是这个道理。测试应该成为设计的一部分，在早期设计架构的时候 就应当考虑。
架构的搭建是很困难的，人们想法设法让架构更加简单，因此总结好的经验就非常重要。所谓架构框架，就是好的架构设计模式，它们可以被重用。
在执行环境框架中，小元件是相互集成的。小的控制单元对于用户而言是没有特定价值的。关注的只是小控制单元内部，包括预先定义好的接口等，这样就可以慢慢地加入功能。
实际上很难把所有的东西一下子搞定，一种比较简单的方法是从一个小系统开始，并逐渐增加功能。基于这种开发理念，可以使用attache point。用插件构造系统的过程实际上是向attache point加入代码。
框 架应当包括很多好的构件公开发人员使用，不需要开发人员自己从头开发。复杂系统中，开发人员也需要自己的构件。好的框架应有例子可以供开发人员参考，例子 使工作更加简单。目前好的框架有很多，譬如Eclipse、J2EE、.NET等等，他们可以成为实际系统的开发框架。
使用框架有很多好 处，可使我们很容易用DSL描述现有概念，保持系统的一致性。框架可使团队间的工作保持一致，也可以是不同架构的系统保持一致，可以是界面、数据格式体验 等等都保持一直。好的架构还可以减少设计工作量，减少不同设计人员设计时的分歧。有很多中方法可以描述结构框架：UML、结构、接口、模式等等。基于结构 框架，可描述DSL的语法合语义。每一种结构框架都包括具体的代码(C++、Java)，包括描述告诉用户如何使用。
这种从专家手中总结 好的经验并共享给所有人的一个类似的例子就是模式(Pattern)，尽管它已经是十年前的东西了。模式可以帮助我们解决具体的问题，它是针对常见的问题 的解决方案。参数使Pattern可用于不同的领域，有不同级别的Pattern，譬如Design、Model、Arch等等。跟构架架构一样， Pattern也有架构、结构、规则、使用指南等等。
另一种和Architecture Framework类似的东西是Component，它为另一种特定的Architecture设计，在此Architecture下，Component可以互相协作。
MDA
Model Tools是用来描述Model、Patten等的工具。当只有两三个人时，可能就不需要Model Tools了，但即便是简单的问题，也是需要一个工具的。对于一个大的项目，也需要工具帮助团队协作、记录结果。没有工具会造成重复、冲突、丢失等等。工 具可帮助我们找出错误和问题。好的自动化工具可以为的Architecture和Runtime Platform生成代码，而从模型到代码的关联则可以被记录。
大的项目中，如果使用不同的工具，会使交流变得困难。这就需要一个公共的存储库(repositiory)。开发人员可以自由修改自己的数据而不影响他人。这种公共存储库的基础是MOF、XML等技术。
用 于MDA的翻译工具帮助我们变模型为代码，好的工具可基于特定平台生成代码。另一种是代码优化工具，可以把简单代码映射为复杂代码，还有工具可以重新排版 组合代码。好的变换工具是很难制作的。现在有很多这种变换工具，OMG正在进行的QVT项目就是在位转换工具指定标准，此项目在明年一季度结束。
对于变换工具的要求包括：理解源和目标语法，不要期望最好的代码，它已经减少了工作量。在这方面，值得参考的好的例子就是编译器。
一方面需自动化的变换工具，同时也主义现有项目的现有代码，希望QVT可以以插件的方式接受现有代码。对工具的另一个要求是需要维护关联，希望小的改变不需要重新生成所有的代码。保持模型于代码的关联关系有集中不同方式：
1. 部分地转换：把模型转换为代码，细节被忽略了。比如现在的UML工具，生成数据结构和代码框架，开发人员需要增加细节。在这种变换中是有风险的，修改代码 可能破坏关联，反向变换是可能的。但这种逆向变换是模糊的，主要是因为代码包含的信息实际比模型更少。这种部分地变换是可行的，但从长期角度看可能并不是 很好。
2. 完全生成：另一种方法称为完全生成，即生成100%的代码。开发人员不修改生成的代码，对DSL的要求是描述足够的细节，编译器就是一个很好的例子。但在 编译器刚刚出现的时候，人们并不是非常地信任，开发人员经常检查现在编译器已经足够成熟。另一个例子是格式转换UML->XML，完全生成这种技术 用于我们能掌握所有细节的情况。尽管完全生成这种方法目前还不成熟，但将来会是一种可用的技术。
3. 结合前两种，代码嵌入模型。开发人员把片段加入模型，DSL描述能力不足时，开发人员些代码，生成工具会将插入在模型中的代码加入到生成的代码中。这种么 模式更像地一种方式，但有羽模兴和代码在一起，但没有丢失关联一值得危险。这是一种很灵活的技术，在yacc中就已经开始使用了。这是一种非常灵活的方 式，它需要开发人员同时工作在高层次的模型级别，也在代码级别。这是一种很实际的技术。
4. 更先进，针对变换建立模型，把变换和原有代码联系起来，一旦搭建变换的变换，便可用于很多领域。这是一种强大的技术，但并不适用于每一个开发人员，这需要 特定技能和相关知识。James认为这种技术会带来益处。那么谁会使用这种技术呢，通常是构建架构和模式的人。有部分人可用此技术构造框架，并让更多的人 受益。
很多对缄默的品评在于模型不能运行，这并不是一个好的想法。实际上，可用自动化工具执行模型，早期的模型是不完整的，其中缺少一些 必要的数据和决策，因此不能运行。在某些模型中，这些问题并不受到关注，他们之关心模式而不是数据结构。对架构进行测试的工作目前正在IBM开发。
有人建议把UML变成可运行的，基本的UML是不可能运行的，因其作用领域广泛。UML设计师就是为了跨平台多语言，因此若你希望改变实际上是和UML的设计初衷有很大的差距的。
在UML中有不确定的点，他们是无法运行的，UML本是是缄默语言，没有运行的予以，譬如多线程等等。那么怎么把UML变成可运行的呢？UML Profile是个不错的选择，譬如RealTime Profile是UML在实时系统可运行。
相对于UML，DSL表述能力更强，可把UML作为DSL与实现之间的过渡语言，把DSL模型转换为UML中间产品，用工具把中间模型通过UML Profile转换为可运行的。这样，就构建了DSL到平台的转换。
MDA总结
MDA目前还处于早期的阶段，四到五年之后可能会被广泛地采用。现在MDA用于小项目试点，现在有很多片段，但这些片段还无法写作。James建议大家尽早地尝试一下。
DSL现在很少用到，但将来会有更多的DSL在出现。M$现在也开始支持DSL，这说明个和IBM有同样想法的企业已经越来越多了。
现在也有很多框架存在，夜间的标准组织也在开发特定领域的模型。
OMG正在开发针对意料领域模型，是各种意料设备可以很好地协作。在金融、运输等领域都有类似的情况
要推广MDA，还需要好的变换工具，明年QVT成为现实将是一个很好的开端。在MDA被广泛接受之前，还需要去很多工作，可以从编译器方面西区很多的经验。
现在看起来MDA还很新，但将来会对软件开发产生影响。