尽管过去十年间关于模型驱动工程（model-driven engineering，简称MDE）的优缺点争论已经相当热烈，但目前，MDE实践方面的全行业调研还很少。在一项新的研究课题里，我们调研了450名MDE实践者，并对超过22位进行了深度访谈。我们发现，尽管MDE的运用比人们普遍认为的更为广泛，但开发者很少通过它来生成整个系统；相反，他们只用MDE来开发系统中的关键部分。
对象管理组织（OMG）在2001年发布了模型驱动架构（model-driven architecture，MDA）规范第一版。MDA强调模型在软件开发中作为首要制品的作用；尤其是，模型应该足够精确，以支持生命周期各阶段的自动模型转换。当然，这不是什么新的想法，但它确实唤起了该领域的复苏，并在模型驱动方法的支持者与反对者之间引起了激烈争论。1.
许多年之后，现在关于模型驱动工程（MDE）是否是一个开发软件的好办法，仍未得到澄清（请参阅边栏《到底什么是MDE？》）。有些公司称采用MDE取得了成功，而另一些则经历了惨痛的失败。我们需要对MDE实践进行一次全行业的独立调研，找出那些导致成功或失败的因素。虽然之前有一些关于建模在业界运用的调研，但它们只关注于建模中的某一个方面，比如UML的使用2或形式化方法等。3.
在本文中，我们将介绍一项关于MDE实践的最新调查研究，并分享从中获得的广泛经验。具体地，我们关注于揭示MDE的成功与失败因素。我们调查了450位MDE实践者，并对超过22位来自9个行业17家公司的实践者进行了深度访谈（有关细节请参阅边栏《调研方法》）。
这项调研显示，不同机构运用MDE的成熟度分布很广：就参与问卷调查的人数来看，处于早期调研阶段的人、首次MDE项目参与者、和有多年MDE经验的人，三者比例相当。我们的访谈对象，通常都是对MDE富有经验的人。在业界运用MDE的方式上，我们有一些意想不到的发现；我们还了解到许多企业为增加MDE胜算而采取的措施。
许多经验教训都表明了这样的事实，即：社会组织因素在决定成败上，至少具有与技术因素同等的重要程度。关于本项调研研究方法的详细介绍，我们已另行撰文。本文旨在为那些已经或正考虑采纳MDE的人，提供一些关键的经验信息。
有些人称MDE在软件工程里的运用机会很少，他们认为MDE只在一些利基市场（niche markets）里被专家们所使用。然而，我们的数据否定了这种观点。我们发现，某种形式的MDE被广泛运用于实践，跨越包括汽车、银行、打印机和Web应用在内的各种行业。比如，450位问卷调查4,5对象在不同公司里担任不同的角色（36%是开发者，37%是项目经理），所在公司的开发者人数也具有良好的分布（52%少于100人，19%超过1000人）。我们的访谈环节也支持这一发现，并且证实MDE确实运用广泛，而且使用方式也多种多样：从“为整个应用领域定义精确模型”这一全行业都在做的事，到“针对单个公司的单个应用系列生成代码”这种很受限的、有限程度的MDE运用。
或许有些出乎意料，在我们的调研中，大部分MDE实践案例都遵循了领域特定模型（domain-specific modeling）的方法：那些成功运用MDE的公司，基本都创建或使用了为他们领域专门设计的语言，而不是采用像UML这样的通用语言。访谈数据显示，为细窄且拥有良好理解的领域开发小型的领域特定语言（domain-specific languages，DSLs）是常见现象。普遍看法认为，应该花费大量精力来开发那些覆盖着广泛领域且能捕获其中领域知识的模型。与之不同的是，在实际应用中，领域模型其实的是“快而粗糙的（quick and dirty）”；有时，最快只要两周就能开发出一个DSLs（及相应的生成器）。迷你DSL的运用也很广泛，甚至是在单个项目里。但如何整合多个DSLs是一个明显的挑战。我们的调研对象倾向于结合UML来使用DSL——在某些情况下，DSL就是一个UML概要文件（profile）。不过无论在什么环境下，建模语言都需要相当多的定制，才能被运用于实践。
我们的研究发现还让我们相信，大部分成功的MDE实践都是从基层开始的。由高级管理层强行贯彻的MDE计划一般都是艰难的；一些访谈对象称，若开发者们不愿投入的话，那么自上而下的管理肯定是要失败的。所以，我们只看到寥寥几个用MDE生成整个系统的案例。成功的MDE实践者不是遵循重量级的自上而下的方法，而是在因地制宜地将它与其他方法灵活地结合起来使用。
让我们感到意外的是，我们的数据显示，代码生成并不是采纳MDE的关键动力。尽管人们经常认为MDE（或至少模型驱动的开发）与代码生成关系紧密，而且代码生成能够带来诸如生产效率提高等好处。但事实上，生产效率的提高差异很大（差的降低27%，高的提升800%）。大部分公司的生产效率提高似乎介于20%到30%之间。6令人意想不到的是，我们的数据表明，这种程度的生产效率提高并不足以成为采纳MDE的动力：MDE带来的培训成本和大量组织上的变动，可以轻易抵消这百分之二三十的效率提升。不过，这并不意味着公司不该采纳MDE。相反，我们的访谈结果一次又一次地表明，虽然那些公司在采用代码生成的方法，其实他们觉得MDE在其他方面的收益要比效果并不明显的效率提升来说更为重要。所以，从这个意义上说，代码生成转移了我们对MDE的注意力，而我们的调研结果表明，我们有必要对MDE的愿景、宣传口号和理解进行重新认识。
调研方法
我们综合了多种不同的研究方法，从广为传用的问卷调查法，到半结构化访谈法（对象是业界专业人士），还有现场观察法（研究MDE实践者如何工作）等等。问卷调查法是通过SurveyMonkey在线进行的，内容主要是封闭性问题，采用单项选择和李克特量表（Likert scales）等形式。我们在问卷的开始处强调了，我们的目标群体是有MDE实际工作经验的业界实践者。我们在软件工程邮件列表和OMG网站上对问卷调查活动进行了宣传。我们还进行了22个半结构化的深度访谈，大部分是通过电话完成的。大多数访谈对象对MDE的态度总体上是肯定的，不过我们也遇到小部分尝试过MDE、但以失败告终的人。访谈时长为45到60分钟，提出的问题包括采用MDE的方法与动机，成功/失败的理由，以及获得的经验教训等等。访谈过程有录音和笔录；我们最后得到的关于MDE经验的文字记录超过15万字。有关研究方法的详细信息，我们已撰文另行发表。
参考文献
J. Hutchinson et al., “Empirical Assessment of MDE in Industry,” Proc. 33rd Int’l Conf. Software Eng. (ICSE 2011), 2011, pp. 471–480.
如果MDE的真正好处不是代码生成，那么是什么呢？我们发现，原来MDE的主要优势，是在记录好的软件架构方面提供了支持。大家都会同意，明确描述的软件架构是成功软件开发的关键之一。然而，软件工程师们缺少技能、技巧和时间来投身于架构定义这项工作，所以，尽管他们欣然接受架构定义的价值，但在实践中并没有去做。访谈对象们一致同意，MDE使明确的架构定义变得更容易，尤其是在基层开展MDE的时候。在精确模型被逐渐引进组织内的过程中，开发者们会发现一些似曾相识的代码片段，于是他们将其抽象为一个DSL，并为之编写生成器——这实际上是一个逐渐构建架构描述的过程。精确模型所要求的严格性，迫使开发者们进行显式的架构描述，只不过不强制他们采用重量级、冗长的架构定义过程罢了。
有一家公司，他们采用各种基于XML的DSLs来为某大型复杂系统种的许多部分生成代码。随着时间的推移，开发者们也开始意识到，他们实际上在以一种非标准的关注分离形式进行架构构建：他们发现自己不知不觉地在系统里寻找可自动生成的部分（较简单的部分）和需要有经验的开发者来编写的部分（复杂的部分）。这种关注分离的形式——把简单和复杂的部分加以区分——能够加深对系统架构的理解，而且是在MDE的实际演进方式（而不是管理指令）之下产生的。
即便是那些认识到MDE优势的公司，他们采纳MDE也需要较采纳其他方法（如敏捷）更长的时间。我们的数据表明，这种惰性之所以存在，其中一个主要因素是MDE通常被宣传为一种更快更省的技术。但这并不足已成为公司冒险采纳它的理由；相反，他们采纳MDE，是由于MDE促成了其他方案无可能实现的事。某全球知名打印机厂商就是一个例证。他们在十年前就开始有意识地采用MDE了。那时，软件是他们的瓶颈：当时普遍认为，软件是妨碍新款打印机上市的制约因素。不过，在MDE方面经过十年的努力之后，该公司称，现在软件已经不再是个问题了。换言之，MDE令他们可以专注于他们早该专注的事——即制造打印机，而不是开发软件。这说明一个问题，我们该重新考虑MDE的宣传口号了：它不是一种让你做事更快的方法，而是一种让你可以从事新事物的手段。
除了以上这些关于MDE成功与失败的有趣发现，我们的数据还让我们对MDE的心理与组织方面有了更多了解。我们在其他软件工程子领域里观察到一个现象，即不同类型的开发人员（比如新近程序员与专家程序员）之间存在显著的个体差异。我们在MDE里也发现了相似的现象。7,8
首先，似乎软件架构师普遍对MDE反映良好。MDE项目所使用的代码生成器，对架构规则、约束和模式等进行编码，而这些都是由软件架构师制定的。因此，MDE赋予架构师更多的控制权，从而令他们可以在开发团队里容易地实施自己的设计决定。
其次，某些类型的开发人员可能会对MDE非常排斥，比如编程专家和编程爱好者。前者习惯于被请教有难度的技术问题，后者乐于（甚至是在业余时间）尝试各种新的编程技术。编程专家反感MDE，还是出于控制权的因素：MDE可能会降低他们在公司里的重要性。对于编程爱好者而言，他们觉得MDE将任务自动化，限制了他们的创造性。
我们发现管理层面也存在类似的问题。具体地说，似乎中层经理可能会成为采纳MDE的瓶颈。因为他们夹在高级经理与基层员工之间，他们通常承担很少的战略职责，因此未必会预见到MDE能带来什么。相反，他们的主要职责是跟踪进度和项目里程碑，他们自然会出于规避风险考虑而抵制新技术。
MDE可能会给全球化软件开发带来根本性转变。众多公司称，他们通过MDE减少了离岸活动，因为现在他们可以把原本外包的近岸任务给自动化了。
关于是否人人都具备抽象思考能力这一问题，似乎不同公司有不同的看法。例如，有家公司觉得，采用MDE的主要瓶颈在于他们需要对数百名软件开发人员进行重新培训，其中许多人都无法转向抽象思考。与之形成对比的是另一家公司，他们称只有很少的程序员无法进行抽象思考（他们说是3%，不过这个数字并不是经由科学的方法得到的）。尽管这一问题明显与公司的MDE成熟度有关，但结果仍然表明，我们对软件开发中抽象思维的理解还很有限——其他研究人员也有同样的发现9
一些迹象表明，MDE专家既要具备软件开发（及抽象）能力，又要对相关领域有着透彻的理解。由于大部分MDE工作都和领域十分相关，因此领域知识相当重要。因此，根据技能划分，把团队成员分为领域专家和MDE专家的团队，成功几率较低；但如果团队成员同时具备这两种技能的话，成功几率就会增加——也就是说，团队成员一个个都既能为领域开发元模型，又能为领域编写代码，还有对领域进行分析的能力。这有助于减少误解和加速进度。
正如其他软件工程方法一样，组织的架构和业务也与MDE成功与否之间也存在着值得注意的联系。
我们的数据明确表明，MDE（至少目前）并不适合所有类型的机构。有趣的是，那些面向特定领域的（如汽车、打印机接口、金融应用等）公司比开发通用软件的公司（如顾问咨询公司）更容易接受MDE。前者已经雇佣了领域专家，这些领域专家可能已经创建过有关模型。尽管他们创建的模型也许只是个草图或具体一点的蓝图，或者他们可能只是用PowerPoint来非正式地描述模型，但正如几位访谈对象所说，把这些非正式模型转换为计算机可读的精确模型，比从零开始创建要轻松得多。
相比之下，写通用软件的开发者可能很难认识到模型的重要性，而且事实上，对于他们正在开发的软件来说，模型也许未必适合。一个很说服力的例子是，一家全球大型软件咨询公司意识到，尽管他们已经多次帮助来自特定领域的客户成功运用了MDE，但他们仍然觉得这种成功不太可能在自己公司内部发生。MDE似乎对机构评估个人与团队方面的一些假定存在异议。例如，有些架构师对我们说，有时，他们会人为地把模型搞复杂，因为他们的经理不明白简单模型更好的道理；相反，经理们会觉得简单的模型说明考虑得不够周全。公司雇佣新员工的方式也有悖于MDE的思路。在雇佣开发人员时，通常衡量的是他们熟悉什么技术，而不是他们对领域的理解程度。而MDE专家要有对一个或多个领域的深入理解，才能成功运用这项技术。
我们的研究结果指出一些应当注意的具体指导原则。下面，我们就根据我们掌握的实证数据，提出成功实施MDE最重要的五点建议。
正如你所看到的，在运用MDE时，这几点建议需要小心判断；对实施进展进行充分评估，似乎是成功采纳MDE的另一个重要工作。
我们的数据还显示出建模培训方式的影响。大学里的软件工程课通常是以自上而下的方式教学的：从创建需求模型开始，然后以迭代的方式逐步细化架构、设计、代码、测试等等。这种教学方式要求学生在理解具体细节之前，就对系统的抽象理解做出形式化描述，这给他们带来很大困难。
我们在研究中发现，按照这种自上而下的方式在全企业范围内引入MDE的做法充满困难。那些成功实施MDE的公司，都是从基层开始推行MDE的：小团队试用MDE的各个面面，让可重用资产在公司里得到认可，并最终实现MDE在整个企业的普及。这种工作方式表明，开发者觉得从基层对现有资产进行重构，要比从上层进行抽象，更容易掌握MDE。这让我们注意到了MDE工作方式与教学方式上的不匹配。
另外，似乎MDE开发者既需要编译器开发能力，也需要抽象能力。不幸的是，这些能力要通过不同的计算机课程来学习，而这些课程之间的联系很少。然而，根据我们的证据，我们认为抽象能力与编译/优化技术应该整合起来，放在一起教授。这一想法将彻底改变软件工程的教授方式，并提高新一代开发人员的能力，使他们既有问题空间里的抽象能力，又有自动转换到业务空间的能力。11
我们所做的是首个针对MDE实践的全行业调研。它发掘出许多已经在MDE上取得巨大成功的公司，并揭示了他们成功的部分原因。它也发掘出一些曾经尝试MDE、但最终放弃的公司。我们的许多发现是一般性的软件开发经验教训，与其他研究揭示的结果一致（例如在形式化方法的使用方面）。然而，无疑我们也有针对MDE的经验教训，比如那些与代码生成和抽象有关的。3也许，最让人大开眼界的部分是我们认识到，最新建模技术与工具在支持软件开发活动方面的不足。在建模语言或工具方面，我们没有发现一致意见——在调研中，开发者们提到了超过40种“常用”建模语言和100种“常用”工具。有一项最近研究，调查了50位软件设计师，发现他们要么根本不用UML，要么只是有选择性地、非正式地使用UML。这些研究让我们注意到了建模方面的一些基本问题——设计者们如何进行抽象，工程师们如何用抽象概念来对系统进行分析，机构如何处理抽象概念——都没有很好地反映在当前的建模方法里。事实上，绝大多数建模方法（既包括工业界，也包括学术界的）在开发过程中都没有充分理解用户和机构的工作方式。例如，UML 2.0对UML标准做了很大改动，但并没有如实反映实证软件建模或软件设计研究上的研究成果。最终，当前的建模方法，迫使开发者和机构按一种适应方法论本身（而不是让方法论适应人）的方式来工作。
最后，在结束本文之前，我们提倡采用联合的方法来开发建模方法，从而更好地反映开发者和机构处理抽象和复杂问题时的工作方式。我们相信，只有将软件建模、软件设计研究和组织研究（目前，他们已经在各自势力范围内经取得了瞩目的成绩，但尚未看到融合）三者结合起来，才能实现这一目标。工具和技术应该对开发者与机构的实践有充分的理解，而目前这方面的努力还不够——填补这一空缺或许能解决所有问题，并让建模获得比目前更广泛的接受。
Jon Whittle是英国兰卡斯特大学（Lancaster University）计算与通信学院软件工程组主任。他的研究兴趣包括软件建模、实证软件工程和社会化计算。Whittle获得爱丁堡大学人工智能博士学位。他的联系方式是：j.n.whittle@lancaster.ac.uk。
John Hurchinson是英国兰卡斯特大学（Lancaster University）计算与通信学院高级研究助理。他的研究兴趣包括软件建模、软件过程评估和计算语言学。Hutchinson获得兰卡斯特大学计算机科学博士学位。他的联系方式是：j.hutchinson@lancaster.ac.uk。
Mark Rouncefield是英国兰卡斯特大学（Lancaster University）计算与通信学院高级讲师，前微软欧洲研究院研究员。他的研究兴趣包括工作、机构和人因方面的实证研究，以及交互式计算机系统设计。Rouncefield获得兰卡斯特大学社会学博士学位。他的联系方式是：m.rouncefield@lancaster.ac.uk。
本文最早刊载于《IEEE Software》杂志。《IEEE Software》杂志旨在构建一个属于软件行业前沿工作者与未来工作者的社区，传达可靠、实用、先进的软件开发信息，从而令工程师和管理者们掌握快速变化的技术变革。