ECO传奇（I）

csstome

浏览: 1472819 次
性别:
来自: 北京

最近访客更多访客>>

u012363178

wangyy

ChangingWay

yadgen

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (2009)

社区版块

存档分类

Delphi 敏捷开发设计模式框架 F#

ECO传奇（I）

前一阵子为CSDN写了一篇有关ECO的文章，CSDN为它取名为“ECO传奇”。由于CSDN杂志是在大陆发行而且是简体版，因此，为了让台湾的朋友也有机会看看这篇文章，以下我贴出了繁体版：

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

最近几年来，软件工程和程序语言一样都呈现百家争鸣的现象，从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研发团队不可或缺的主要技术人员，而且直到现在这四个人仍然为当初促使他们合在一起的信念保持着高度的热忱和兴奋之心。

ECO研发团队的所在地：斯德哥尔摩。

大约在四年前，Borland决定购买Bold技术并且把Bold研发团队带入了Delphi的研发团队，这让Bold研发团队有了一个全新的开始。而在Bold研发团队加入Delphi研发团队不久之后，Borland就决定让Bold技术从Win32平台开始转入.NET平台和C#程序语言。为了这个转变，Bold研发团队因此花费了大量的时间思考他们目前所拥有的东西（也就是Bold框架），什么需要和值得保留，Bold研发团队又需要把Bold带领到什么方向而且开发人员未来应该如何使用这个新的技术。在谨慎的思考之后，Bold研发团队终于对未来的方向以及他们想研发的新一代产品有了基本的轮廓，这就是ECO框架萌芽的起点。

话说Bold虽然是一个强大的框架，但是Bold拥有非常庞大的API，因此，对于初学者而言是非常沉重的负担。此外，Bold框架中也拥有一些难以使用的部分。因此，Bold/ECO研发团队决定大幅缩减API，让ECO框架能够和.NET内建的UI组件搭配在一起，并且重新整理高阶的服务在一组易于使用的接口中，这样一来，不但可以让初学者非常方便上手，也符合目前面向对象框架改为使用接口导向（Interface Oriented）的设计架构。

在Borland购买了Bold技术之后的四年，Bold/ECO研发团队为ECO框架研发出了一个更为弹性的面向对象对映器，这可以让ECO框架非常简单就能够使用各种不同的数据存取技术来存取数据来源，例如ECO框架可以通过面向对象对映器搭配ADO.NET，Bdp.NET，dbExpress.NET等。此外，他们也研发出了OCL的分支语言Eco Action Language，以便能够处理对象的状态和对象的生命周期，研发出从数据库模式逆向工程以产生类别模型以及模型驱动的状态机等先进的技术。

当ECO研发团队在研发ECO技术时，他们需要一种浏览语言能够让开发人员使用来表达如何存取模型中的元素，例如开发人员可以使用下面的语法来取得客户发票中所有购买项目的总金额:

myInvoice.items.value->sum

一开始ECO研发团队自己研发了一种元素浏览语言，但是当他们发现OCL被公布了之后，他们就立刻了解到OCL完全符合他们的需求，因此，ECO研发团队立刻开始实OCL并且让ECO成为世界第一个商业实作的OCL，此外Anders和Jonas也参与了OCL 2.0规范的定义。

ECO I于C#Builder 1.0时出现于业界，ECO II出现于BDS 2005中，很快ECO框架和技术就成为了BDS最耀眼、最独特的技术，也是BDS最大的竞争力之一。到了BDS 2006的ECO III，ECO已经成为了一个非常成熟的框架和技术，使用ECO开发应用程序的开发人员也愈来愈多。目前ECO研发团队正在全力催生ECO IV。

ECO初始开创团队，Jan Norden，Jesper Hogstrom，Jonas Hogstrom以及Anders Ivner

模型驱动开发领导者-ECO架框

ECO是根据模型驱动架构（Model Driven Architecture ，MDA）以及设计驱动架构（Design Driven Architecture ，DDA）为核心发展出来的技术，并且结合OR Mapping，图形用户界面绑定，对象服务以及许多其他丰富的功能而形成了以模型驱动开发（Model Driven Development ，MDD）为基础的软件工程。此外，ECO也结合了RAD能力，因此，在MDD实作的产品中是偏向RAD MDD，意思是说，ECO为了快速使用MDD的开发速度，因此，加入了RAD开发能力，让开发人员能够在IDE中像使用组件开发的方式使用ECO。

ECO的开发方式是让开发人员设计完善的用户需求业务逻辑模型，然后 ECO运行时环境就可以忠实地执行这个设计的模型，所有模型中定义的规范都可以自动被ECO运行时环境自动地遵守和执行。因此，我们可以简单地说ECO能够达到“模型即程序，程序即模型”的地步。也许让我们举一个范例会让读者比较容易了解ECO的开发方式。

使用ECO开发的第一步是建立用户需求的业务逻辑模型，开发人员应该在这个模型中尽可能地设计完整的信息，因为一旦业务逻辑模型设计完毕，ECO应用程序在执行时期就会忠实地自动执行这个业务逻辑模型，因此，任何开发人员花时间在模型中设计的结果都可以自动被执行，完全避免了许多开发人员认为设计是浪费时间的工作。例如下面的业务逻辑模型简单地仿真了一个小型论坛的ECO设计模型：