【IT168 技术文档】
长期以来，面向对象模型一直不移余力地鼓吹可以使开发团队更快速地获得更高质量的软件，以及更好的代码复用。但不幸的是，传统的面向对象解决方案，如统一建模语言（UML），在实际应用中却没有履行自己的承诺，这是因为这些技术并没有在现今的环境中表现得更另人信服，而那些经常宣传的激动人心的结果也并不时常发生，发生这种情况的原因也许是计划不如变化快吧。
本文将揭示关于传统面向模型技术的一些缺陷，并向读者展示如何使用模型驱动构架(MDA)来提供更完美的解决方案，并向面向对象模型发起挑战。
一、当前的软件建模所面临的挑战
开发可定制的软件和应用程序对于企业来说总是非常必要的。对于小型或中型企业在没有使用这些繁琐的开发模式就可以非常快速地建立可定制的应用程序，但对于大型企业却不能做到这一点。为一个跨国企业开发复杂的应用，就象是建立一个几百层的大厦，如果没有设计蓝图、经过严格训练的建筑工人、高效的工具，以及其他非常重要的条件，这个建筑物的地基将很快坍塌。
在20世纪90年代，面向对象分析和设计（OOA&D）的概念为了向复杂的企业应用程序发起挑战，形成了一个银弹解决方案。在实践中，OOA&D是一项为了设计解决方案而分析系统需求的对象模型技术的使用。OOA&D方法学使用了多种UML图表来描述需求、设计、实现、测试和发布。很朋企业在这段时间内成功地应用了OOA&D技术。
但不幸的是，对象模型的最初所具有的效用已经由于很多原因而褪色，这主要是因为技术以一个非常危险的步调在变化。使用传统的对象模型技术所制定的方案很快就会被废弃。这此动态的需求主要由以下因素形成，尤其是对于企业层的的开发团队更是如此：
1. 商业模型的变化更频繁和快速 — 这些变化通常由企业合并、获得、投资以及其他的商业模型所导致。变化在现今的企业中将是永恒不变的，但是复杂、多层的应用程序构架并不象商业模型那样容易变化 — 这就意味着整个开发团队要从头做志。并没有一个完美的构架设计来支持长期的维护，而重新对原有的系统进行翻新可能要比开发它更费时间。
2. 遭遇生产力瓶颈 — 一但软件需求和开发周期被确定，构架师一般就会按着传统的方式进行工作。他们会开很多应用开发会议（JAD），来讨论高层的设计和概念分析，并对开发处理和开发周期上进行决策。在这时，设计开始失去了它们的价值。取而代之的是开发人员直接去实现它们，开发团队因此失去了时间上的概念，并且冒着用户需求随时变化的危险仍然沿用构架师在白板上建立的用例图、序列图以及类图进行设计和实现。
二、模型驱动将成为救命稻草
今天的企业需要一个新的方法来模型化对象，其中一个原因是需要更短的开发周期以及最小化开发风险。对象管理组织(OMG)只在2001年介绍了一个：模型驱动构架。这个MDA范例进化了模型，并可以应付复杂度不断增加的企业系统设计。MDA是一组通过继承XML实现的相关技术，这些技术可以将模型转化为文本，以及模型和模型之间的转换，这么做可以确保模型能以更高的效率和更灵活的应变能力来开发系统。
今天的企业需要一个新的方法来模型化对象，其中一个原因是需要更短的开发周期以及最小化开发风险。对象管理组织(OMG)只在2001年介绍了一个：模型驱动构架。这个MDA范例进化了模型，并可以应付复杂度不断增加的企业系统设计。MDA是一组通过继承XML实现的相关技术，这些技术可以将模型转化为文本，以及模型和模型之间的转换，这么做可以确保模型能以更高的效率和更灵活的应变能力来开发系统。
MDA使用的理念是构架师可以画出所有企业商业领域的内核对象的草图模型。这些对象仅仅是商业对象，并没有将来打算建立它们所使用的技术。一但这些构架师对自己画的模型草图可以准确的描述真实世界的商业模型时，构架师将使用一个基于MDA的模型工具来进行模式转换。
一但开始转换，这些工具将扫描每一个由构架师画的草图来发现商业模型。使用被封装在转换模式中的条件逻辑，可以获得基于所扫描到的对象的确定的动作。转换的输出结果就是可执行的代码，这些代码可以被编译，发布和运行。在适当的地方或功能使用这项技术，可以使企业应用开发人员更轻松地编写满足用户需求的商业特性。
三、MDA是否会真的被广泛应用
今天，MDA阵营里分为了两派，也就是它的支持者和反对者，但这两派都承认MDA的发展和被采用的速度非常缓慢。Forrester在2007年4月的调研报告“模型驱动开始的现状”中提到MDA将由于更广泛的原因而影响它的推广和普及，有很多客户和开发人员经常抱怨MDA有以下缺陷：
1. MDA非常复杂和学术化
2. MDA很严格
3. MDA仅仅是代码生成器
但我认为MDA的使用并不需要流于形式。它非常具有可实践性和弹性。事实上，支持MDA的工具已经得到了非常大的发展。我建议这些对MDA有敌意的人看看以下几点意见：
1. MDA不仅仅是支持UML的特定领域语言（DSLs）的翻版，这种语言能以可视化的方式来为我们画UML图，这个工具也可以自动写代码。然而，UML通常被认为是非常复杂和局限性，然而，作为另一种选择，自由的流模型经常不支持本质的上下文和生成UML的技术。和UML相比较，多种目的的模型语言，DSL允许我们建立描述应用程序构架和通过自己的商业模型来进行商业处理的符号，它们改善了横跨整个商业模型的可用性和应用能力。
但我认为MDA的使用并不需要流于形式。它非常具有可实践性和弹性。事实上，支持MDA的工具已经得到了非常大的发展。我建议这些对MDA有敌意的人看看以下几点意见：
1. MDA不仅仅是支持UML的特定领域语言（DSLs）的翻版，这种语言能以可视化的方式来为我们画UML图，这个工具也可以自动写代码。然而，UML通常被认为是非常复杂和局限性，然而，作为另一种选择，自由的流模型经常不支持本质的上下文和生成UML的技术。和UML相比较，多种目的的模型语言，DSL允许我们建立描述应用程序构架和通过自己的商业模型来进行商业处理的符号，它们改善了横跨整个商业模型的可用性和应用能力。
2. 所有权模式和转换内部锁已以是过去的东西了。在现在的MDA内核中已经是转换模式了，这是一种可以使代码独立于商业模型之外的指令集合。然而MDA用户一但由于客户的需求变化而陷入危机时，就可以使用一种叫查询、察看和转换（QVT）的标准语言来灵活地使MDA转换为UML、商业处理模型符号（BPMN）,数据模型以及可定制的模型类型。
3. 模型到文本的转换可以使我们节省很多时间。我们使用MDA是因为我们不用想着如何来产生代码吗？还是我们需要开发其他什么东西（如文档、发布描述文件、测试等）？事实上MDA的模型到文本的转换可以自动的产生从已存在的设计模型中能找到的所有的东西。这可以使开发人员减轻压力，转而从事更为重要的工作。
四、MDA价值的另类看法
当应用程序和商业处理的复杂度继续升级时，高效的模型解决方案的重要性更加显得突出。模型解决方案可以确保一个足以影响整个构架设计的方案以一种可视化的方式解决。模型提供的功能不仅仅是商业处理、应用程序以及企业构架，还有很多数据结构。他们可以使多个项目团队之间互相沟通，以及可以确保更完美的构架设计和长期的可维护性。更在进化的支持MDA的工具的下一步发展将是成为一种高效的模型系统。因此，所有的企业应用团队应该重新审视这种蓬勃发展的模型技术。
