ECO传奇（I）

最近几年来，软件工程和程序语言一样都呈现百家争鸣的现象，从UML/RUP、敏捷开发（AD）、测试驱动开发（TDD）到功能驱动开发（FDD）以及目前快速兴起，也即本文讨论重点的模型驱动开发（MDD），让整个开发社群热闹不已。正如不同的开发人员会根据应用程序的需求以及个人的喜好选择使用不同的程序语言，而且同时使用数种程序语言开发应用程序已经成为常态现象，愈来愈多的开发团队也开始导入不同的软件工程，甚至会在不同的项目中使用不同的软件工程。这种种的现象都代表着多样化（精致化），质量和生产力决定了使用的程序语言和软件工程，而不再像以前一样由特定的信息技术主导。

那么什么是模型驱动开发呢? 在稍后本文介绍ECO的发展史段落中，读者就可以看到ECO之父Jan Norden先生对于开发应用程序的观察，相信读者必然也会心有戚戚焉。但是在叙述ECO发展史之前，在此先让笔者和各位读者交流一下数个开发的问题。

如果读者是拥有数年经验的开发人员，那么您是否记得到现在为止您撰写了多少支程序吗? 也许这个问题的答案您只有非常模糊的感觉。没关系，如果笔者继续问在您撰写的程序中您写过多少次使用相同的数据存取技术，例如JDBC，ADO，ADO.NET，BDE，dbExpress等，从相同数据库中取得数据的程序代码? 又有多少次您是把取得的数据显示在类似的图形用户界面中? 您是不是有过这样一种经验，那就是您的脑袋中已经知道如何完成应用程序的功能，但是仍然需要一步一步地撰写存取数据库的程序代码，一步一步地设计图形用户界面，虽然您已经撰写过无数类似的应用程序?

笔者本身就拥有许多上述开发的经验，那么请您想想为什么会有这种不断重复的开发工作发生? 很简单，是因为我们平时的开发工作就是把客户的需要不断地对映到我们使用的技术中，利用各种技术记录、分析和设计客户的需求，再使用人工的方式对映到数据库，对映到图形用户界面，对映到集成工作，对映到一堆不断重复的工作上。也正是因为这些需要重复进行的开发工作太多，因此，许多开发人员就开始简化客户需求设计的过程，因为许多开发人员相信许多的细节部分可以在撰写程序代码阶段完成，而无须花费时间在“无用”的设计阶段，毕竟“计划（设计）赶不上变化”，不是吗?

虽然设计不能穷尽所有开发细节，但却能够掌握大部分的业务逻辑，而就是这关键部分的业务逻辑占据了上述重复开发工作的主要部分，通过工具我们可以自动地对映业务逻辑完成上述重复的开发工作，而让开发人员专注在设计更好的客户需求模型，避免不断地重复相同或是类似的开发工作。

现在我们就可以简单地说明一下什么是模型驱动开发了。MDD的基本构想是开发人员应该专注于设计良好的业务逻辑模型，并且把业务逻辑撰写在模型中。一旦模型设计完成之后，MDD即可提供工具自动地把业务逻辑模型对映到开发人员使用的技术中。例如开发人员可以选择使用特定的平台、数据库、程序语言或是组件架构，这样一来，就避免了开发人员需要不断重复相同的开发工作，也可以大幅缩减开发过程，当然，MDD也支持了一个关键技术，那就是由此任何的设计不可能一次完成，因此MDD也支持迭代式的开发，一旦开发人员修改了设计模型，支持MDD的工具就可以再次进行迭代式转换。这整个概念如下图所示：

Borland/CodeGear研发团队的成员早在数年前便看到了这种现象，因此，也在数年前开始研发支持MDD的技术。几年前许多人都认为MDD不切实际，这主要是因为MDD牵涉到许多先进的规范和技术，在那个时候是难以实现的。但是在这几年来MDD的支持技术不断的被突破，在OMG也正式规范了MDD的标准之后，MDD的产品开始出现于市场上，也让许多开发社群了解到MDD带来的生产力和开发质量。在目前市场上的MDD产品中实现最齐全，最符合MDD规范，最有生产力的产品就是Borland/CodeGear的ECO（Enterprise Core Objects）了。ECO和它的前身Bold已经在全世界被许多开发人员使用并且开发出了众多的应用系统，它的生产力也获得了证实。尤其在软件工程盛行而且MDD被愈来愈多的人接受之后，ECO也被愈来愈多的开发人员所认识、了解和使用，当然，本文的目的也是为各位读者介绍MDD和ECO技术。

但是为什么ECO研发团队会早在七八年前就能够预见模型驱动开发的重要性而从Win32下的Bold架框开始发展? ECO研发团队有哪些厉害的角色? 在Bold/ECO的发展过程中又发生过什么样的故事? 这些都要从Bold/ECO之父Jan Norden先生开始说起。

ECO的发展史

早在数年前Jan Norden先生就发觉了大多数的应用程序都有极为类似的程序代码，这些程序代码大都不断重复出现在应用程序的各部分，例如在图形用户界面呈现对象样例中的数据以及储存对象样例到数据来源中。此外，在维护数据的完整性方面的技术问题也不断地出现在应用程序的开发流程中。然而，在这些程序代码中，最重要的是执行应用程序应该完成的工作，至少应用程序应该交付客户付钱购买的功能。

Jan Norden先生开始了解到如果能够通过提供一个充满了模型信息的架框，那么就有可能从其中抽取出系统主要组成部分的程序代码，进而允许开发人员集中在撰写可以真正交付客户价值的程序代码部分。有了这个信念之后，Jan Norden先生便开始开发数个不同的架框来试着解决软件开发过程中各种不同的基本问题。而当UML标准公布于世而且Delphi也出现在开发工具界之后（大约在1990年的中期左右），Jan Norden先生也发现到此时是把他所有在过去几年撰写的框架结合UML和Delphi并且形成一个单一产品的好时机了，不久之后Jan Norden先生终于发展出了这样的产品，那就是后来闻名的Bold。

当Jan Norden先生决定结合他的架框，UML和Delphi开发出新的产品后，Jan Norden先生很快就开始在瑞典首都斯德哥尔摩（Stockholm）建立他的核心研发团队，不久之后Bold的核心研发团队终于形成了，这些成员包含了Jan Norden，Jesper Hogstrom，Jonas Hogstrom以及Anders Ivner，笔者在撰写《Delphi MDA/DDA程序设计——使用ECO》一书的过程中即经常和Anders Ivner讨论ECO技术细节上的问题。

虽然后来Bold研发团队陆续加入其他的成员，但是Jan，Jesper，Jonas和Anders直到现在仍然是Bold/ECO研发团队不可或缺的主要技术人员，而且直到现在这四个人仍然为当初促使他们合在一起的信念保持着高度的热忱和兴奋之心。