L
lzhuan
Unregistered / Unconfirmed
GUEST, unregistred user!
MDA会带来什么
紫云英
MDA概述
MDA是“模型驱动构架”（Model Driven Architecture）的缩写。它是由OMG定义的一个软件开发框架。其关键之处是，模型在软件开发过程中扮演了非常重要的角色。在MDA中，软件开发过程是由对软件系统的建模行为驱动的。
MDA开发生命周期和传统的生命周期并没有很大的不同。MDA的工件是形式化模型，也就是可以被计算机理解的模型。下面列出的3种模型位于MDA的核心：
· 平台独立模型（PIM）：具有高抽象层次、独立于任何实现技术的模型。
· 平台相关模型（PSM）：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
· 代码：用源代码对系统的描述（规约）。每个PSM都将被变换成代码。
传统上，从模型到模型的变换，或者从模型到代码的变换，主要是手工完成的。与此相反，MDA变换总是由工具执行的，许多工具可以把PSM变换成代码，这并不令人惊奇。MDA的创新之处是把PIM到PSM的变换也自动化了。
软件开发是什么
Alistair Cockburn在他的Agile Software Development一书中归纳了业界对软件开发的看法：以C.A.R Hoare为代表的数学观、以Bertrand Meyer为代表的工程观、以很多程序员为代表的手工艺观，还有一些程序员则认为软件开发是神秘的创造行为。当然，近20年来，也有越来越多的人对软件开发持建模观，比如Ivar Jacobson就曾声称：软件开发就是建模。MDA Explained一书的作者也指出：代码就是模型。Cockburn则在他的书中独树一帜地提出：软件开发是一种协作游戏。
自然，持不同软件开发观的项目主导者会关注软件开发过程的不同方面。为了节省资源，我们希望软件开发领域的研究者和项目主导者（实践者）的关注焦点是真正决定项目成败的那个方面。否则，学术界投入大量时间精力去研究对项目成败无足轻重的因素，项目主导者把大量人力物力用于控制项目中无关紧要的方面（如Cockburn调侃地指出的：开发场所的环境湿度），那岂不冤枉至极？
那么，这个“至关重要”的方面究竟是什么呢？是工具？是过程？是整个方法学？还是人？或者是别的我们尚未注意到的因素？目前，没有人知道确切答案。或许，每个方面都对项目成败有些影响吧。无论如何，因为MDA将会对软件开发的各个方面都产生深远影响，所以不管您对软件开发持何观点，您都无法回避MDA。下文我将简述MDA对软件开发各方面带来的影响。
MDA改变了协作游戏的角色和规则
好吧，我们就按照Cockburn的说法，把软件开发看作协作游戏好了。不过，任何游戏总要有参与者和游戏规则吧？目前，编码员是重要的游戏参与者，但在MDA版本的协作游戏中，没有这个角色了，取而代之的是建模者。但是，MDA也引入了另一个新游戏——这个游戏不是编写软件产品，而是编写变换规则。变换规则市场会逐渐成长，就像基于组件的开发启动了组件市场那样。在新游戏中，原来的编码员中的精英人物将找到他们新的位置，而他们也将自豪地发现，他们编写的代码将获得程度空前的复用。至于游戏规则的改变，我在这里说不好也说不全，请您在玩新版本的游戏时慢慢体会吧J
MDA改变了开发过程
目前，许多项目经理都很注重开发过程。或许因为过程对项目成败真的很重要，或许仅仅因为过程是软件开发中项目经理唯一可以施加较大影响的方面。无论如何，MDA对开发过程的改变不容忽视。
比如，开发过程的需求分析阶段依然存在，不过需求分析员要编写的不再是需求分析文档，而是PIM——平台独立模型。需求分析文档和PIM有什么区别？阅读需求分析文档的是人，是设计师或者程序员，但阅读PIM的则主要是类似于编译器的自动工具。
既然需求分析阶段产生的工件改变了，那么依赖需求分析阶段结果的设计阶段自然也要改变，而“编码”这项工作则需要完全重新定义了。测试、部署等阶段也会有相应改变。此处不再详叙，请阅读本书正文。
MDA改变了开发工具
随着技术的进步，开发工具的改变一直都没有停止。当主流开发语言是汇编的时候，您可曾想象到含自动完成、重构、集成调试器的IDE？你可曾想到会有一天汇编代码不再由人手写而是由编译器自动生成并且可以高度优化？那么，当主流开发语言的抽象层次即将再次跃升，开发工具的革命也将到来。在MDA的世界中，“变换工具”扮演了传统编译器的角色，传统编译器则退居目前汇编器（就是把汇编语言翻译成机器语言的程序）的地位，其余各层工具依次后退。调试器也将逐渐进化，就如同从机器码级调试（汇编语言级调试）向源码级调试的过渡那样，慢慢过渡到模型级调试。在IDE中最重要的也不再是基于文本的代码编辑窗口，而是基于图形的建模窗口。人们将像现在谈论一个API函数那样谈论一个设计模式（design patterns），而代码模式（idioms）将完全由变换工具自动生成，不再是人们关心的内容。
MDA让你重新认识文档、代码、模型
以前，我们倾向于认为，给人看的文档或者模型不需要写得太精确，因为人总会有很强的理解力，人的大脑能够“全自动”地更正一些无关紧要的错误并补全一些省略之处。另外，文档或者模型写得太精确是浪费时间，因为文档和模型又不能变成可以运行的产品，你总是需要用代码把模型重新翻译一遍。Cockburn和一些XP推崇者的观点更极端：文档和模型不重要，人们拿着文档或者围在画着模型的白板前的讨论才重要，因为真正的沟通不是发生于阅读文档之时，而是发生于人与人的讨论中。
好吧，或许以前确实如此。但MDA将完全颠覆这一现实。模型不再主要是给人看的了，而主要是给机器看的。写的精确一点也不再是浪费时间，因为只写一遍（您不需要再把文档和模型手工翻译成代码）而且早晚要认真地写一遍。至于围在白板前的讨论——如果是在讨论如何编码实现某个模型，那么很抱歉，这样的讨论不再需要了。当然，其他方面的沟通还是需要的，但必须承认，游戏规则已经改变，游戏中的关卡已经改变，您有了不少新的“通关任务”，而很多老任务则自然取消了。
MDA带来了数学般的精确性
是的，凡是能让机器理解和自动处理的东西都必须是数学般地精确的。您在编译程序时有没有遇到过这样的编译器信息：“警告：第nnn行代码具有二义性”？那意思就是，请您把代码写得更精确些。那么，MDA要说的就是，请您把模型建得更精确性。MDA工具会严格检查您的模型以确保这一点的。
MDA为新方法学提供了土壤
如果软件开发是游戏，那么方法学就是攻略。或许高手不需要攻略也能把游戏玩通关，但大多数人在攻略的指导下能少走很多弯路。MDA制定了新的游戏规则，那么我们自然可以期待新版本的攻略如雨后春笋般出现。即便是同一个游戏，您手中有了不同的战斗工具、不同的装备，玩法也会不同。那么，既然MDA带来了很多新一代的工具，新的方法学会诞生也不足为奇了。
既然提到方法学，我就再多说几句。把软件工程中“methodology”这一术语译为“方法学”其实颇具误导性，因为这个词的内涵往往不是哲学老师常挂于嘴边的“世界观和方法学”的那个方法学，而是指一系列你需要照着做的方法，或者说一系列约束开发人员的规则。它不是“研究方法的学科”，而就是一系列方法和规则的集合。
按照规则的多少和约束的强弱，可以大致地把方法学分为重型和轻型两种。“重型方法学”比较正规和严谨，在采用重型方法学的项目中，开发人员具有较强的可替换性，因为方法学本身强制要求开发者把他所创造的所有东西都记录在案（按照该方法学规定的格式），所以参与项目的新人能借助这些文档很快上手（前提是新人也熟悉这种方法学规定的格式），从而开发人员跳槽对项目的冲击也相对较小。项目经理们可能会比较偏爱这样的方法学，因为这样一来他们掌控的因素比较多，风险就比较小。开发人员则不会喜欢这样的方法学，因为在采用重型方法学的项目中，他们只是可替换的螺丝钉，难以感觉到自己的重要性。而且做连篇累牍的文案工作纯属利他（对经理、对可能加入的新人有利），毫不利己（很无聊很费时间，而且占用的是自己本可用于开发的时间）。
轻型方法学则具有相反的特质。记录在案的东西不多，交付的就是代码以及可以跑的产品，当然还有测试用例。大多数交流是口头的、非正式的，很高效，但也只存在项目成员的脑海中。如果成员从项目中离去，那么他脑海中的这些东西也随之带走。因为开发人员往往都希望自己具有不可替代的重要性，而且一般都觉得写程序比写文档好玩，再者轻装向前可以走得比较快（因为不必把时间浪费于编写正规文档），所以开发人员一般都比较偏爱轻型方法学。
一般而言，大型项目采用重型方法学好一点，因为项目人手多，周期长，即便所有员工都很爱戴老板很忠于公司很喜欢这个项目，但这么多人在这么长时间内一个都不跳槽一个都不生病一个都不结婚生孩子也是挺难办到的。而小型项目则往往采用轻型方法学好一点。Cockburn提出的水晶方法族就充分考虑了项目规模的因素，当然，还考虑了项目紧要性等别的因素。
那么，MDA有没有对某种类型的方法学特别垂青呢？没有，MDA是“轻重咸宜”的。既然XP（极限编程）俨然已是轻型方法的招牌，那么自有好事者用模型替换代码，提出了XM（极限建模）。轻型方法的另一特征是迭代和重构，MDA极佳的同步特性也为之提供了有力支持。而重型方法也能从MDA获益匪浅。重型方法有一大特征就是书写详尽的文档，创建大量的模型，那么MDA说：让文档更详尽些吧，让模型更精确些吧……详尽精确到机器都能理解并自动编译了，这一量变到质变的转换也就完成了。
从学术界及业界，我们已经看到，一些传统的方法学正从MDA这一变革中汲取新的养分，而新的方法学也能从MDA的土壤中茁壮成长。或许未来20年中，又会有一批涉及MDA的新方法学著作出现吧。
创造性的脑力劳动是无可替代的
所有的改革都会在一定程度上重新分配社会资源，都会造成新的富人和新的穷光蛋。MDA也不例外。不过MDA所威胁到的是只会老老实实地把详尽的设计文档翻译成C++或者Java代码的人。
社会发展的历史就是一部机器逐渐替代人的劳动的历史。所以部分人失业是进步的必然代价。不要试图阻止技术进步的脚步，因为技术进步的同时也会创造新的工作机会。比如MDA很可能就会创造出新的变换定义集市场。但是，只要您从事的工作具有创造性，就无法被机器取代。
软件设计是需要创造性的，这一创造性或者体现在代码中，或者体现在文档中。在MDA出现之前，如果我们认真地编写文档，然后认真地编写代码，那么我们进行了两遍创造性劳动，这浪费了劳动力。而有些软件成熟度（CMM）级别高的企业（特别是印度和日本企业）是这样做的：认真地编写文档，代码则是文档的精确翻译。更多的中国企业则是这样做的：文档敷衍了事（敷衍CMM检查组或者敷衍上级领导和客户），创造性劳动则在编码阶段做。这些做法的优劣不去评述，但只要您做的是创造性工作，那么在MDA的世界中您会如鱼得水的，因为工具只是为您节约了做无聊琐事的时间，让您可以把精力集中到创造性过程中去。
业界和IT媒体前段时间曾有“大量需要软件蓝领”的声音，我不知道当时是否真的有此需要。但我在此大胆预言：MDA一旦普及，软件蓝领会大量失业。因此，我敬请读者您不要把“软件蓝领”作为您的职业生涯目标。如要在未来立足软件开发业，请您永远不要放弃自己创造性思维的能力。
本文为人民邮电出版社即将出版的《解析MDA》一书的译序
紫云英
MDA概述
MDA是“模型驱动构架”（Model Driven Architecture）的缩写。它是由OMG定义的一个软件开发框架。其关键之处是，模型在软件开发过程中扮演了非常重要的角色。在MDA中，软件开发过程是由对软件系统的建模行为驱动的。
MDA开发生命周期和传统的生命周期并没有很大的不同。MDA的工件是形式化模型，也就是可以被计算机理解的模型。下面列出的3种模型位于MDA的核心：
· 平台独立模型（PIM）：具有高抽象层次、独立于任何实现技术的模型。
· 平台相关模型（PSM）：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
· 代码：用源代码对系统的描述（规约）。每个PSM都将被变换成代码。
传统上，从模型到模型的变换，或者从模型到代码的变换，主要是手工完成的。与此相反，MDA变换总是由工具执行的，许多工具可以把PSM变换成代码，这并不令人惊奇。MDA的创新之处是把PIM到PSM的变换也自动化了。
软件开发是什么
Alistair Cockburn在他的Agile Software Development一书中归纳了业界对软件开发的看法：以C.A.R Hoare为代表的数学观、以Bertrand Meyer为代表的工程观、以很多程序员为代表的手工艺观，还有一些程序员则认为软件开发是神秘的创造行为。当然，近20年来，也有越来越多的人对软件开发持建模观，比如Ivar Jacobson就曾声称：软件开发就是建模。MDA Explained一书的作者也指出：代码就是模型。Cockburn则在他的书中独树一帜地提出：软件开发是一种协作游戏。
自然，持不同软件开发观的项目主导者会关注软件开发过程的不同方面。为了节省资源，我们希望软件开发领域的研究者和项目主导者（实践者）的关注焦点是真正决定项目成败的那个方面。否则，学术界投入大量时间精力去研究对项目成败无足轻重的因素，项目主导者把大量人力物力用于控制项目中无关紧要的方面（如Cockburn调侃地指出的：开发场所的环境湿度），那岂不冤枉至极？
那么，这个“至关重要”的方面究竟是什么呢？是工具？是过程？是整个方法学？还是人？或者是别的我们尚未注意到的因素？目前，没有人知道确切答案。或许，每个方面都对项目成败有些影响吧。无论如何，因为MDA将会对软件开发的各个方面都产生深远影响，所以不管您对软件开发持何观点，您都无法回避MDA。下文我将简述MDA对软件开发各方面带来的影响。
MDA改变了协作游戏的角色和规则
好吧，我们就按照Cockburn的说法，把软件开发看作协作游戏好了。不过，任何游戏总要有参与者和游戏规则吧？目前，编码员是重要的游戏参与者，但在MDA版本的协作游戏中，没有这个角色了，取而代之的是建模者。但是，MDA也引入了另一个新游戏——这个游戏不是编写软件产品，而是编写变换规则。变换规则市场会逐渐成长，就像基于组件的开发启动了组件市场那样。在新游戏中，原来的编码员中的精英人物将找到他们新的位置，而他们也将自豪地发现，他们编写的代码将获得程度空前的复用。至于游戏规则的改变，我在这里说不好也说不全，请您在玩新版本的游戏时慢慢体会吧J
MDA改变了开发过程
目前，许多项目经理都很注重开发过程。或许因为过程对项目成败真的很重要，或许仅仅因为过程是软件开发中项目经理唯一可以施加较大影响的方面。无论如何，MDA对开发过程的改变不容忽视。
比如，开发过程的需求分析阶段依然存在，不过需求分析员要编写的不再是需求分析文档，而是PIM——平台独立模型。需求分析文档和PIM有什么区别？阅读需求分析文档的是人，是设计师或者程序员，但阅读PIM的则主要是类似于编译器的自动工具。
既然需求分析阶段产生的工件改变了，那么依赖需求分析阶段结果的设计阶段自然也要改变，而“编码”这项工作则需要完全重新定义了。测试、部署等阶段也会有相应改变。此处不再详叙，请阅读本书正文。
MDA改变了开发工具
随着技术的进步，开发工具的改变一直都没有停止。当主流开发语言是汇编的时候，您可曾想象到含自动完成、重构、集成调试器的IDE？你可曾想到会有一天汇编代码不再由人手写而是由编译器自动生成并且可以高度优化？那么，当主流开发语言的抽象层次即将再次跃升，开发工具的革命也将到来。在MDA的世界中，“变换工具”扮演了传统编译器的角色，传统编译器则退居目前汇编器（就是把汇编语言翻译成机器语言的程序）的地位，其余各层工具依次后退。调试器也将逐渐进化，就如同从机器码级调试（汇编语言级调试）向源码级调试的过渡那样，慢慢过渡到模型级调试。在IDE中最重要的也不再是基于文本的代码编辑窗口，而是基于图形的建模窗口。人们将像现在谈论一个API函数那样谈论一个设计模式（design patterns），而代码模式（idioms）将完全由变换工具自动生成，不再是人们关心的内容。
MDA让你重新认识文档、代码、模型
以前，我们倾向于认为，给人看的文档或者模型不需要写得太精确，因为人总会有很强的理解力，人的大脑能够“全自动”地更正一些无关紧要的错误并补全一些省略之处。另外，文档或者模型写得太精确是浪费时间，因为文档和模型又不能变成可以运行的产品，你总是需要用代码把模型重新翻译一遍。Cockburn和一些XP推崇者的观点更极端：文档和模型不重要，人们拿着文档或者围在画着模型的白板前的讨论才重要，因为真正的沟通不是发生于阅读文档之时，而是发生于人与人的讨论中。
好吧，或许以前确实如此。但MDA将完全颠覆这一现实。模型不再主要是给人看的了，而主要是给机器看的。写的精确一点也不再是浪费时间，因为只写一遍（您不需要再把文档和模型手工翻译成代码）而且早晚要认真地写一遍。至于围在白板前的讨论——如果是在讨论如何编码实现某个模型，那么很抱歉，这样的讨论不再需要了。当然，其他方面的沟通还是需要的，但必须承认，游戏规则已经改变，游戏中的关卡已经改变，您有了不少新的“通关任务”，而很多老任务则自然取消了。
MDA带来了数学般的精确性
是的，凡是能让机器理解和自动处理的东西都必须是数学般地精确的。您在编译程序时有没有遇到过这样的编译器信息：“警告：第nnn行代码具有二义性”？那意思就是，请您把代码写得更精确些。那么，MDA要说的就是，请您把模型建得更精确性。MDA工具会严格检查您的模型以确保这一点的。
MDA为新方法学提供了土壤
如果软件开发是游戏，那么方法学就是攻略。或许高手不需要攻略也能把游戏玩通关，但大多数人在攻略的指导下能少走很多弯路。MDA制定了新的游戏规则，那么我们自然可以期待新版本的攻略如雨后春笋般出现。即便是同一个游戏，您手中有了不同的战斗工具、不同的装备，玩法也会不同。那么，既然MDA带来了很多新一代的工具，新的方法学会诞生也不足为奇了。
既然提到方法学，我就再多说几句。把软件工程中“methodology”这一术语译为“方法学”其实颇具误导性，因为这个词的内涵往往不是哲学老师常挂于嘴边的“世界观和方法学”的那个方法学，而是指一系列你需要照着做的方法，或者说一系列约束开发人员的规则。它不是“研究方法的学科”，而就是一系列方法和规则的集合。
按照规则的多少和约束的强弱，可以大致地把方法学分为重型和轻型两种。“重型方法学”比较正规和严谨，在采用重型方法学的项目中，开发人员具有较强的可替换性，因为方法学本身强制要求开发者把他所创造的所有东西都记录在案（按照该方法学规定的格式），所以参与项目的新人能借助这些文档很快上手（前提是新人也熟悉这种方法学规定的格式），从而开发人员跳槽对项目的冲击也相对较小。项目经理们可能会比较偏爱这样的方法学，因为这样一来他们掌控的因素比较多，风险就比较小。开发人员则不会喜欢这样的方法学，因为在采用重型方法学的项目中，他们只是可替换的螺丝钉，难以感觉到自己的重要性。而且做连篇累牍的文案工作纯属利他（对经理、对可能加入的新人有利），毫不利己（很无聊很费时间，而且占用的是自己本可用于开发的时间）。
轻型方法学则具有相反的特质。记录在案的东西不多，交付的就是代码以及可以跑的产品，当然还有测试用例。大多数交流是口头的、非正式的，很高效，但也只存在项目成员的脑海中。如果成员从项目中离去，那么他脑海中的这些东西也随之带走。因为开发人员往往都希望自己具有不可替代的重要性，而且一般都觉得写程序比写文档好玩，再者轻装向前可以走得比较快（因为不必把时间浪费于编写正规文档），所以开发人员一般都比较偏爱轻型方法学。
一般而言，大型项目采用重型方法学好一点，因为项目人手多，周期长，即便所有员工都很爱戴老板很忠于公司很喜欢这个项目，但这么多人在这么长时间内一个都不跳槽一个都不生病一个都不结婚生孩子也是挺难办到的。而小型项目则往往采用轻型方法学好一点。Cockburn提出的水晶方法族就充分考虑了项目规模的因素，当然，还考虑了项目紧要性等别的因素。
那么，MDA有没有对某种类型的方法学特别垂青呢？没有，MDA是“轻重咸宜”的。既然XP（极限编程）俨然已是轻型方法的招牌，那么自有好事者用模型替换代码，提出了XM（极限建模）。轻型方法的另一特征是迭代和重构，MDA极佳的同步特性也为之提供了有力支持。而重型方法也能从MDA获益匪浅。重型方法有一大特征就是书写详尽的文档，创建大量的模型，那么MDA说：让文档更详尽些吧，让模型更精确些吧……详尽精确到机器都能理解并自动编译了，这一量变到质变的转换也就完成了。
从学术界及业界，我们已经看到，一些传统的方法学正从MDA这一变革中汲取新的养分，而新的方法学也能从MDA的土壤中茁壮成长。或许未来20年中，又会有一批涉及MDA的新方法学著作出现吧。
创造性的脑力劳动是无可替代的
所有的改革都会在一定程度上重新分配社会资源，都会造成新的富人和新的穷光蛋。MDA也不例外。不过MDA所威胁到的是只会老老实实地把详尽的设计文档翻译成C++或者Java代码的人。
社会发展的历史就是一部机器逐渐替代人的劳动的历史。所以部分人失业是进步的必然代价。不要试图阻止技术进步的脚步，因为技术进步的同时也会创造新的工作机会。比如MDA很可能就会创造出新的变换定义集市场。但是，只要您从事的工作具有创造性，就无法被机器取代。
软件设计是需要创造性的，这一创造性或者体现在代码中，或者体现在文档中。在MDA出现之前，如果我们认真地编写文档，然后认真地编写代码，那么我们进行了两遍创造性劳动，这浪费了劳动力。而有些软件成熟度（CMM）级别高的企业（特别是印度和日本企业）是这样做的：认真地编写文档，代码则是文档的精确翻译。更多的中国企业则是这样做的：文档敷衍了事（敷衍CMM检查组或者敷衍上级领导和客户），创造性劳动则在编码阶段做。这些做法的优劣不去评述，但只要您做的是创造性工作，那么在MDA的世界中您会如鱼得水的，因为工具只是为您节约了做无聊琐事的时间，让您可以把精力集中到创造性过程中去。
业界和IT媒体前段时间曾有“大量需要软件蓝领”的声音，我不知道当时是否真的有此需要。但我在此大胆预言：MDA一旦普及，软件蓝领会大量失业。因此，我敬请读者您不要把“软件蓝领”作为您的职业生涯目标。如要在未来立足软件开发业，请您永远不要放弃自己创造性思维的能力。
本文为人民邮电出版社即将出版的《解析MDA》一书的译序