早上好，你们好吗？很高兴五年之后又来到中国，（五年前我来过中国）我看到在中国发生了很大的变化。我是从上海驱车赶往南京，一路上看到每隔几百米就有一个新的建筑拔地而起，我对中国发展的速度感到非常惊讶，希望在软件行业能够构建出同样辉煌的建筑。今天我要告诉大家一些有关软件构建的秘密。
今天我会告诉大家怎么样更加方便、容易地来开发软件。为什么大家都觉得软件开发非常困难呢？我觉得主要原因是业务领域跟计算机领域之间的概念有很大的差别。一般来说业务是用自然的语言来表述，但是软件有可能是用一些非常低级的计算机语言来表述的。构建一个软件需要写很多的代码，要写很多的控制逻辑，有很多复杂的东西在里面。作为软件开发者我们的任务就是要在业务跟软件之间构建起一座桥梁。我们有四种方法使得软件开发变得更加简便。
第一种方法就是尽量向业务领域描述靠拢，尽量用高级语言来直接描述业务领域的概念。大家看到右面这张图是用高级语言、抽象语言来描述的业务的概念，从业务模型到最终软件的实现有可能还要构建一些中间的层次来搭建他们之间的桥梁。为了控制细节上的复杂度，就要很好地来构建我们软件的架构，控制好构件之间的协作关系。为了减少我们书写的代码量，我们可能会使用一些自动化的工具来帮助我们自动生成代码。大家都习惯于最简单的软件开发方式就是坐下来直接写代码，这看上去好像是一种最简单的方式，但实际上最后会给我们带来更大的麻烦。如果开发人员只是写代码而没有设计的话，很有可能他所构建的这个系统的架构就不是那么完善，同时代码之间没有很好地协调。不同的开发小组写的代码可能功能上会有所重叠或者是相互冲突，不同的开发小组就会使用不同的、不一致的格式进行交互。这是一种非常不好的协作模式，因为开发团队之间会相互干扰，而破坏对方的一些工作成果。而且如果是开发人员去写代码的话，就意味着他们有更多的工作要去完成。在最糟糕的情况下大家看到这样的系统有可能是非常脆弱的，任何改变都可能会破坏整个结构。
我们向大家推荐的方法就是称之为模型驱动架构这种新的方(MDAModel Driven Architecture)。在这种方法里我们使用一个高级的模型来描述一些业务领域的概念，基于这种高级的模型再来生成基于某种特定运行平台的代码。在这个过程中我们会使用一些自动化的工具，基于一些标准来生成我们的代码。MDA方法是由对象管理组OMG (Object Management Group) 提出来的，OMG是国际化的标准化的组织。我们在开发的时候，起点是比较高级的业务领域的模型，这个模型我们称之为平台无关模型，也就是PIM (Platform Independent Platform)。在这个平台无关的模型里我们着重关注的是业务的逻辑。涉及到具体平台相关时我们会使用一种与实现相关的Profile，这种Profile描述了特定平台的实现细节。基于平台无关的模型以及特定平台的Profile就可以自动生成基于某种特定运行平台可运行的系统，称之为平台相关模型PSM (Platform Specific Model)。从同一种平台无关模型出发，你可以针对多个不同的运行平台来生成多个不同的PSM，最后基于PSM你还可以生成具体的代码。在MDA里我们需要三样东西，首先我们需要来描述问题的模型，在这里可以使用UML或者是使用新的领域描述语言DSL (Domain Specific Language) 来描述业务领域方面的模型；第二个需要利用架构框架来描述具体的实现，架构框架可以针对某种具体实现作出一些假设，从而基于这些假设来减少我们在建模阶段所涉及的细节，最后通过一些自动化的工具来生成实际可运行的模型或者是模型的特定翻译工具等等。
接下来我要介绍的是问题领域相关的模型。一种描述问题领域模型的方式就是使用UML，大家都知道UML最初是由Grady Booch、Ivar Jacobson和我共同创建的，后来OMG里的其他成员也陆续对这个语言进行了扩展。现UML已经成为对象领域被全世界开发人员广为使用的一种语言。跟编程语言相比UML是一种更加高级的描述语言，在这种语言里我们减少了很多不必要的、细节的描述。理论上讲UML可以应用于很多领域，我们可以对UML加以改造，利用一种称之为UML Profile的机制可以使UML用于某些特定的领域。UML Profile是在UML的基础上针对某些特定的领域进行一些改造，使得它能够支持这些业务领域里特定的业务概念。但即便是我们使用UML Profile这种特殊的机制，UML本身还是一种非常通用的语言，里面还是包含了很多重复性的细节。另外一种方式就是利用称之为领域描述语言的DSL语言来描述问题领域的这些概念。DSL是一种特殊的语言，有它自己的语法和语意，它是针对某一种业务领域而设计的。DSL是利用一些比较高级的概念来描述问题领域的概念，这样它可以减少业务领域跟具体实现之间的差距。DSL里也可以包括一些预先置好的数据与模式，基于DSL的模型可以减少一些重复性的控制逻辑的描述，同时生成更加底层、详细的代码。这里我们来看一些现有的DSL的例子。
首先大家想不到的是在30年以前我们就有这样一种DSL语言，就yacc，在这个yacc里用巴柯斯范式BNF来构建编译器。yacc编译器就可以利用你所描述的BNF来构建复杂的语法编译工具，从而减少手工开发这种编译工具的难度。另外一种大家想象不到的DSL是大家经常用的GUI编程工具，来帮助你搭建用户界面。在这种工具里就可以在屏幕上画上你想要的表格、图表或者是控件等等。大家看到在屏幕上画了这些控件，在内部代表着上千行的代码。但是开发人员不用去描述这些细节的控制逻辑，工具会帮你做到所有的这一切，这样大大简化了开发人员的工作量。另外一种DSL大家可能都想像不到，就是我们日常在使用的桌面编辑工具，像FrameMaker 或者是Word工具。作者可以很容易地用这个工具来写下他们所编辑的书或者是插入一些他们想要的控制逻辑，像图片等等。另外一种就是大家知道的MIDI，用于在乐器跟电脑之间的一种描述语言，它可以让电脑也能够产生音乐。音乐家利用MIDI这种语言不用编程就可以创造出音乐。另外一个例子就是数学上的一些应用工具，利用这些工具用户可以直接用数学表达式、数学公式来描述一些复杂的概念。
这里我再给大家介绍另外一种特殊的DSL，就是以前大家广为使用的SDL。SDL是国际电信联盟ITU所通过的一种标准，很多电信制造商都在利用这种标准来描述他们的电信设备，如交换机。很多知名的电信企业如摩托罗拉、爱立信等都在使用SDL来描述他们的应用。这种语言提供了复杂的描述手段，使得这些企业能够利用它来描述电信上的一些复杂协议。我跟这些企业的开发人员都有过一些合作，我发现他们在使用一些工具时都存在着一些困难。因为随着时代的进步SDL逐渐退出了主要的潮流，它并没有包括一些最新的像UML工具里的一些特性。最近对象管理组OMG刚刚完成一项项目，就是把UML升级到UML2.0。来自于摩托罗拉、爱立信的开发人员成为这个项目组的成员之一，在这个项目里我们把SDL的一些概念也加入到UML2.0里面。所以当UML2.0出来之后现在可以把SDL做成UML的一种Profile。这意味着传统的SDL的用户也可以利用UML工具来继续你的软件开发，同时也可以利用UML里其他的一些特性。这也是一个很好的DSL语言的发展历程，在这个历程中大家看到如果一种概念型的领域描述语言比较有用的话，其实还会继续延伸它的生命力，比如像SDL被加入到UML2.0里去。
有关这个领域描述语言有几种不同的类型，有一种形式称之为描述式 (Declarative) 的。在这种描述式的语言里只需要描述我们需要做什么，但是并不需要描述详细的控制逻辑。这就像我们用数学公式来描述复杂的数学问题一样，并没有说明我们应该如何来解决这个问题。这种形式的DSL被广为使用，因为简化了开发的工作量，他们并不需要描述详细的控制逻辑。如果计算机能够自动地生成这种解决方案的话，这其实是一个非常有用的方式。但是实际的情况并不是如此，所以会有另外一种形式的DSL语言称之为命令式(Imperative) 的，需要写出一行行的指令来告诉如何解决这个问题。这种形式的DSL详细描述了具体的控制逻辑，当然也给开发人员带来了难度，因为它更难以使用。所以我们想出一种折中的方式把这两种形式结合起来。在这种方式里我们就用一些高级的描述性的方式来描述这些问题领域的概念。在开发的后期我们可以使用低级的命令行的方式来描述这些细化的控制逻辑。这种方式实际上是结合了前面两种描述方式的优点。现在又有了一个非常流行的概念叫做面向Aspect的编程 (AOP – Aspect Oriented Programming) ，在这种方法里我们是把不同的需要解决的问题划分成不同功能的Aspect，一些有关Aspect的例子就包括如何控制安全性、如何永久地保存数据、如何提供一种并发的处理机制、以及如何记录一些日常信息等等。所以每一种Aspect实际上可以帮助我们来解决某一个特定领域的问题，但是这种解决方案是横跨整个系统的。在这种方式里我们需要有一个翻译软件把这些Aspect转化成具体的代码。解释软件应该知道Aspect之间的差异和相互的交互，应该能够补充一些必要的代码把他们整合起来。实际上从本质上讲AOP方法跟刚才讲的DSL语言是非常接近的，在每一种方法里都有一种高级的描述方法来描述问题领域的这些概念，同时都需要有一种翻译软件把这个模型翻译成最终的实现。现有的这些AOP语言并不是太好，有些并没有我们想像中工作得那么好。翻译工具不能很好地工作，开发人员还是需要去描述一些他们之间实现的细节。我认为在AOP这种技术真正非常流行之前，我预期到AOP的下一个版本一定要增强转换 (transform) 的功能，这样才能能使得它更加流行。我认为这种DSL语言可以帮助我们来描述这种AOP 的自动生成、自动转换功能。
接下来我们来看一下架构框架。架构包括好几样东西，首先在构建架构时要做的是将系统分解成为一些子系统，这些子系统本身应该有完整的功能，同时应该能够相互交互。子系统之间功能上不应该有重叠，在这种架构里我们需要描述子系统之间交互的拓扑逻辑，常见的拓扑逻辑包括像流水线、星形结构等等。架构的另外一个方面就是要描述子系统之间的交互规则以及他们所交换的数据格式。另外架构设计师也需要描述有关资源管理的规则，这样使得不同的开发人员能够更加有效地来使用这些资源，这里提到的资源就包括像内存、系统进程等等这些概念。所谓好的架构跟差的架构之间的差别就在于一个好的架构它能够更好地适应系统将来的变化，注意这个变化是不会自动发生的，是应该由架构设计师为将来的变化做好准备。在一些好的架构里会使用“钩子（Hook）”这种机制，它可以使得我们不用修改这个系统就可以增加一些新的功能。我们经常看到很多项目延期的情况，原因就是项目里的很多测试工作被忽略掉了。举一个类比，大家想想现在汽车里的发动机，发动机里有很多传感器，这样汽车上的电脑可以随时感知发动机里的工作状态。大家想象一下如果先把发动机造出来再把传感器放进去，这实际上是行不通的，在设计发动机时就应该考虑要把传感器放进去。在做开发时架构设计师也要把测试这个概念加入到开发过程中去，使得测试成为我们开发过程的一部分。所以我们应该在早期设计架构的时候就应该考虑到测试，这样能够有效地提高软件的质量。实际上大家都知道架构是很难去搭建的，我们想方设法使得架构这种工作对开发人员来说变得更加简单。所以我们是把其他开发人员在开发过程中得到的一些好的架构经验总结出来，称之为架构框架。所谓的架构框架实际上是一种可重用的架构模式，这种模式是从好的架构模式里总结出来，这些架构模式可以进一步地被其他人所重用。
架构框架包括好几样东西，首先我指的是执行环境的框架，这里包括很多小的元件，这些元件之间是相互继承的。这些小的控制单元对用户来讲并没有提供它的价值，它所关注的只是这些小的控制单元内部的控制逻辑。它也包括预先定义好的系统之间交互的接口、数据格式等等。所以我们可以预先构建好一个系统，逐渐地往里面增加它的功能。实际上我们很难把所有的东西都组合在一起，一下子把它构成一个可运行的系统。如果你试图把所有的东西一下子都集成起来的话，这实际上是非常困难的。一种比较简单的方法就是你从一个小系统开始，在开发的过程中逐渐往这个系统里增加功能，逐渐地把这个系统建立起来。基于这种开发理念，我们在设计架构框架的时候就会预留好一些扩展点，通过这些扩展点可以增加更多的功能，这些功能有可能体现为一些插件。在构造系统时就是把不同的插件插到不同的系统上去，好的架构框架应该也包括一些可重用的构件。开发人员应该利用现有的构件来开发系统，而不需要写代码。在构建一些复杂系统时，开发人员有可能也需要自己去开发一些构件，但是并不需要所有的构件都从头做起。一切好的架构框架实际上都应该包括一些好的例子，这样对我们可以有更大的帮助。实际上大家都有这种经验，当你采用一种新技术时很难判断怎么样把各种部件集成在一起，但是如果这时有一些很好的例子的话，我们的工作就会变得简单。这里大家看到的一些有关架构框架的例子就包括我们经常谈到的Eclipse、.NET或者是J2EE架构。
使用架构框架可以给我们带来很多好处，它可以使我们非常容易地利用DSL来描述一些现有的概念，也可以帮助我们来保证系统的一致性。如果系统是由很多小组来开发的话，这种框架可以在不同小组搭建的系统之间保持高度的一致性。另外它也可以保证基于同一种架构框架的不同开发应用也保持高度的一致性。另外它使得用户的界面所使用的数据模式、用户的体验等等在不同的应用之间也保持高度的一致性。架构框架也可以很好地帮助增量式的开发，可以从一个小的系统开始，基于这种框架来逐步增加它的功能。另外架构框架也可以减少我们开发设计的工作量，使得不同的开发人员在设计的时候减少他们的分歧。
我们有很多种方法来帮助我们描述一个架构框架，第一种方式是可以用UML模型来描述架构框架，可以描述结构模型、接口模型、描述模式等等。基于那种框架我们可以描述DSL语言的语法和语意。每一种架构框架都会包含一些具体的代码，象C++或者是Java等等。每一个框架也应该包含一些文字描述来告诉使用者如何来使用这个框架。总而言之架构框架的基本思想是要从专家手里把一些好的经验总结出来，使得所有人都能够共享这些好的经验。一个类似的例子就是模式 (Pattern) ，模式已经是十年前的一个概念了。模式可以帮助我们来构建架构和解决一些具体的技术问题。什么是模式呢？模式是针对常见问题提供的解决方案。很多模式都有不同的参数，这些参数使得模式可以应用于不同的领域。所谓的模式有很多种级别，有些是比较低级的，象通常我们讲的设计模式，也有一些是帮助我们来构建模型的，也有一些是帮助我们来搭建系统架构的。跟我们刚才提到的架构框架一样，每一个模式它都应该有这样几部分，包括架构、结构、内部的交互规则以及一些使用指南等等。另外一种共享经验的方式就是来构建可重用的构件，构件是为一种特定的架构所设计的，在这个架构下不同的构件可以很好地相互合作。
接下来我再给大家介绍的是MDA技术中有关自动化工具的部分。我们在做MDA开发时需要的是一个建模工具，这个建模工具可以帮助我们来描述模型以及各种模式。如果你开发的是一个小系统，只有两三个人的小项目，就不需要建模工具。但是即便是简单的问题也有必要来使用工具，例如你会使用计算器来把数据加在一起，这样使你的工作更加简便。对于一些大的项目、十几个人的项目当然需要一个建模工具来帮助你们团队协作、帮助你们来记录你们设计的结果。假如没有工具来协调大家工作的话，在建模过程中你们的工作有可能会相互重叠、相互冲突，有些信息可能会丢失。工具同时也可以帮助我们来找出你设计中的一些错误或者是瓶颈之所在，帮助我们避免一些问题。一个好的自动化工具也可以根据你所指定的特定架构和平台来生成可运行的代码。自动化工具在生成代码时也会生成一些追踪信息，就是从模型到代码之间的关联关系也会被记录下来。对于一些大的项目而言，有可能你们会使用很多种不同的工具，这些工具有可能带来的困难是他们之间很难进行信息的交流。在这种情况下我们需要有一个公共的存储库来存放和管理所有的这些工具所产生的数据。这种公共的存储库应该可以使开发人员自由地修改数据，而并不影响其他人的结果。用于构建这种存储库的技术就包括MOF（Meta-Object Facility元对象设施），另外一个是XML (eXtended Markup Language) 。
用于MDA开发的另外一种工具主要是翻译工具，可以帮助我们把模型自动地翻译成为代码。一个好的工具可以基于某种特定的平台帮助我们生成代码。另外一种翻译工具就是一些代码优化工具。一个例子是，大家可以把这种优化想像成为它可以把一个简单的代码映射成为复杂的代码，从而提高运行效率。另外的转化工具包括重新排版、组合这些代码等等。实际上一个好的转化工具是很难得到的，现在我们有很多种不同的变换工具，现在对象管理OMG正在进行的一个项目称之为QVT (Query-View-Transformation) 项目，就是查询、察看和变换，这个项目的主要目的是为变换工具制定一个标准。这个项目预定是在明年的第一季度结束，一旦这个标准出台的话，它就可以使得不同的变换工具之间的协作变得更加简单。
对于这种变换工具我们到底有哪些要求呢？首先这种变换工具一定要理解源和目标语言的语法，同时在这种工具在生成代码时，不要指望它生成的是最好的代码（可能是比较好的代码），因为通过这种工具已经减少了我们很大的工作量。实际上在这种变换工具上已经有很多年经验的积累，比如大家经常用到的编译器，我们希望把编译器上好的经验吸收过来。一方面需要构建自动化的变换工具来帮助我们转换代码，但是同时也要注意到我们现有的项目有很多历史代码。我们希望这种新的QVT标准能够接受插件，以插件的方式来支持现有的这些代码。对于这个变换工具的另外一个要求是要使得它能够维护代码跟模型之间的关联，因为每当你对模型作出一个小的修改时，我们是希望这个工具能够相应地生成变化的代码，而不是每当你修改一部分模型之后这个工具需要把整个模型重新生成一遍，这是非常费时的。为了满足这种要求，变换工具需要保持模型跟代码之间的关联关系。对于这种变换实际上我们有几种不同的方式。第一种就是部分的转换，在这种方式里我们是把模型转换为代码，但是在这种转换里很多实现的细节是被忽略掉的。比如说现在大家正使用的很多UML工具实现的就是这种转换，这种转换只是帮你生成数据结构或者是一些简单的代码框架。所以这种变换方式生成代码非常快，但是开发人员或者是编程人员需要做更多的工作来增加细节的描述。当然在这种变化里存在着风险：如果编程人员修改代码的话，有可能会破坏掉代码跟模型之间的关联。我们称之为双向变换的技术实际上是可能的，只要我们在这种变换工具里，在生成的代码里保持这种代码跟模型之间的关联关系就可以了。所以每当开发人员修改模型的话，我们就知道相应的哪一块代码需要做相应的修改了。但是这种逆向的变换往往是比较模糊的，从代码到模型我们往往不知道怎么样根据代码生成一个什么样的模型。主要的原因是因为代码比模型包含的信息更少，但是这种部分的变换技术其实是比较切实可行的技术，因为我们可以快速地利用它来建立我们的模型，并且生成我们的代码。但是从长远的角度来看这有可能并不是一个很好的解决方案。
另外一种取而代之的方法是完全生成，在这种技术里我们只有一种单向变换，就是从模型直接变换到代码，而且是百分之百地生成代码。在这种方法里开发人员是不会去修改生成的代码。但是这也对DSL语言提出要求，DSL应该有能力来描述足够的细节。编译器就是一种完全生成的很好例子。大家都有这种经验，只会用编译器生成代码，但是从来不会去修改编译器所生成的汇编代码或者是信息代码。当我在很多年以前开发工作时这并不是一个事实，那个年代人们对编译器还不是非常信任，开发人员经常去检查编译器所生成的代码。现在编译器已经发展得足够成熟、足够好了，所以大家都非常信任这种变换。现在大家用的另外一种完全生成的例子包括格式的转换，比方现在有些工具可以帮助我们从UML模型生成XML格式。完全生成这种技术有可能适用于那些我们能够掌控所有细节的场合下使用。尽管现在这种完全生成的技术不是非常成熟，但是我预期在将来这种技术应该是越来越可用的。
第三种方式其实是把前面两种方式都结合在一起，就是把代码嵌入到模型中去。在这种方法里开发人员会把代码的片段插入到模型中去。在这种模型里如果DSL的描述能力不够的话，开发人员就会用编程语言来描述这些细节。当变换工具生成代码时就会把开发人员插入的代码嵌入到最后生成的代码中去。所以如果开发人员想修改最终生成的代码的话会修改这个模型中插入的代码片段，重新利用这个模型来生成代码。这种方式有可能更象我们谈到的部分生成的例子，因为在这种技术里开发人员还是需要来写一些编程代码。但是他们还是有不同的，因为在这种技术里我们是把模型跟代码存放在同一个文件里。与其他的技术相比这种方式避免了我们丢失了模型跟代码之间一致性的危险。因为这个变换工具知道插入的代码在模型的什么地方，所以它可以很好地在模型跟生成的代码之间搭建这个映射。实际上这是一种非常灵活的技术，这种技术在几十年以前，在刚才提到的编译器的生成里面就已经用到这种技术了。这是一种非常灵活的工作方式，但是它要求开发人员同时在两个不同的层次进行工作，他既应该在高层次模型这个级别工作，同时也需要开发人员在低层次代码这一级别进行开发工作。但是在当前这个情况下，在我们有更好的完全生成的解决方案之前，这有可能是一种比较实际的技术。最后是一种更加先进的变换技术，在这种变换技术里我们为这种变换本身搭建起一个变换的模型。在这种技术里面，我们会针对这种变换来建立起一个模型，并且利用这个模型把原模型跟目标代码联系起来。利用这种开发技术进行开发的话，就意味着我们通常所讲的设计就是要去构建出这样一个变换。一旦我们搭建起这样一个变换模型就可以把这种变换应用到很多源模型上去。比如说我们可以应用这种技术来构建一些模式，利用这个模式应用到很多领域上去。这是一种非常强大的技术，但是我并不认为这是每一个开发人员都适用的一种技术。这种技术需要一些特定的技能以及相关的知识。但我还是认为这种技术可以给大家带来益处。谁可以用这种技术呢？是一些在开发团队里专门负责构建这个模式或者是构建架构框架的人，有一部分人可以用这种技术来构建出比较好的模式或者是架构框架，使得这种好的经验可以使更多的开发人员受益。
很多对于建模的批评就集中在模型是不可以运行的，我并不认为这是一种很好、很正确的想法。并不是说你看到一个模型就可以去执行它，实际上你可以利用一些自动化的工具来执行这个模型。早期的模型应该是不完整的，所以你不能期望它是可运行的。因为这个模型是不完整的，它里面有可能缺少一些必要的数据或者是一些未知的决策，这些都会阻碍这个模型成为可运行的模型。在某些开发模型里我们并不在意这种可运行，因为有些架构设计师他只关注于这种模式，但是并不在意具体的数据结构。这里可以采用的一种技术就是尽早地对架构进行一些测试，有可能还有很多细节不清楚，但是我们还是有办法对架构进行测试的，在IBM内部我们正在开发这种技术。也有人建议把UML变成一种可运行的语言，但是我认为这并不是一个很好的主意。基本的UML实际上是不可运行的，因为UML是一个作用非常广泛的语言。UML在设计时就被设计成用来支持很多种不同的运行平台、很多种不同的编程语言，所以如果想把UML变成可运行的跟你的想法之间就有一定的差距。另外UML本身作为一种建模语言，在其内部缺少了一些运行方面的语意，比如说你是不是需要多任务，还是外部的数据交换的格式等等。怎么样使得UML变得可运行呢？你可以针对某一个特定的运行平台来制定一个特定的UML Profile。比如说有一个现实的例子就是RealTime Profile，这个Profile使得UML可以在实时系统设计这个领域变得可运行。但是大家注意UML本身还是一个通用的描述语言，DSL可能是在很多情况下表述能力都要更强一些。我的想法是可以把UML作为DSL最终实现的过渡语言。我们可以把DSL所描述的语言模型转换成为用UML描述的一个中间产品。然后可以用工具把这种中间化的UML模型进一步转换成特定平台上可以运行的代码。这就等于是构建了从不同的DSL模型到最终可运行平台的转换跟变换。
160
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
