代码生成的未来

代码生成的未来

Carol Sliwa

[2004/3/22]

模型驱动架构的先行者面临着文化的壁垒，但回报将是事件和资金的节省，以及更高的代码质量。

Wisconsin正在使用一个Web系统替换原来的基于client/server的失业保险金应用系统。但这一次，团队通过画图来描述业务过程，而不是写厚厚的规约。

他们聘请了一位讲师，教授Cobol开发人员如何使用统一建模语言（Unified Modeling Language），团队在计算机上为新的应用画出了各种UML图。

部分软件开发组织正在转向名为MDA（Model Driven Architecture）的系列标准，Wisconsin只是其中一员。MDA由总部位于Needham的国际对象管理集团OMG所制定。他们使用UML以及代码生成工具来构建应用，如果一切顺利的话，在完成业务逻辑的过程中，编程语言将会用得很少。OMG的CEO，Richard Soley，说，他已经知道有两家公司通过MDA生成100% 的代码。

但是，自动代码生成只是MDA带来的利益中的一种。他们认为，MDA还将带来开发时间和成本的降低、代码质量的提高、代码复用的提高，以及与应用需求更好的吻合。

Lee Carter，Wisconsin开发部分的项目主管，认为这是有帮助的，业务用户和IT开发人员现在可以使用相同的语言来描述需求。“这使得我们可以关注于业务需求而不是过早地考虑底层的技术细节”。

为了表示需求，开发人员和业务分析员使用图形来表示各种用例场景，诸如一个不完整的应用是如何处理，或者如何处理被拒绝的应用请求。并表示这些系统是如何联系起来的。Carter说，一旦一系列活动图、顺序图、协作图以及其他图设计之后，就可以通过工具转换这些模型，得到应用的代码。

他认为这些文档化应用的图可以在任何时间使用，就算历经多年。因为他们是由IBM Rational的软件所支持的。“图形比文字的表现能力更强，写满的一页页文字，通常没有人会再看第二遍。而且，我们可以从业务需求跟踪到代码，或者从代码回溯到业务需求。”

为了简便到MDA的转化，这个项目团队从OMG的MDA FastStart计划中购买了位于St. Paul, Minn的Adaptive Team Collaboration公司的服务。ATC公司的CTO，Chris Armstrong，担任过讲师、教练、顾问、心理专家等各种角色。Carter说，他最近的角色是过程审计人员。

另外一个重要的决定是选用了Curam公司基于J2EE的框架为政府的社会服务部分开发应用。Wisconsin 团队使用UML来描述业务需求，并通过一个PIM（platform-independent model，平台无关模型）定义，有效地集成到Curam软件中。系统集成Tier技术公司在这项工作中亦有贡献。

Carter认为，到目前位置，项目已经超出了预期的效果。团队提前60天完成了项目。第一个产品版本11月将发布，其他部分将在两年内完成。和使用传统方法开发的类似项目相比，开发时间得到了减少。

Wilmington 的PFPC公司为投资管理行业提供IT外包服务和应用，他们说，采用MDA，过去需要6个月完成的客户的项目，现在4个月就可以完成。

该公司的CIO，Michael Harte，认为，MDA已经逐渐渗透到他的团队中，带来了更大的精确性。因为这个过程强制了开发中需要做更多的前置工作，和过去相比，严重的设计缺陷可以被更早地发现。

PFPC 的高级架构师Ian Maung指出，MDA帮助位于不同地方的开发人员可以更好的交流，因为（通过UML）这个统一的接口，他们可以理解对方的意思。

Maung 认为，将来MDA 将带简化运行平台之间的切换，因为业务和应用逻辑的定义都是平台无关的，而且只需要简单地修改就可以生成新的平台相关模型。他希望UML2.0中的行为语义（action semantics）可以实现对一些像J2EE这种基于标准的平台的100%的代码生成，从而使得MDA最终可以实现自定义的代码生成。

根据几名分析人员的估计，尽管UML/MDA越来越多地被应用架构师所采用，也只有不到15%的开发人员在使用UML。批评者认为其复杂性将会拒人于门外，并且想要将已有的IT文化转变为代码生成的方式也是有困难的。

Forrester Research 公司的分析人员Analyst Carl认为，很少有开发团队有耐心深入到一个项目中很久还没有看到一行代码。“对传统的IT企业而言，尽早看见代码的愿望是普遍的，我认为，对于任何形式的建模而言，这都是唯一的最大的障碍”。

Meta Group公司的Thomas Murphy认为，许多开发人员都有过使用4GL工具产生的难以维护的代码的不愉快的经验，这使得他们很犹疑。他预测，模型驱动的开发方式将会前进，不一定是使用UML/MDA，但会面临很多挑战。

先行者对这些困难中的很多都有意识到。例如，Maung 认为宣称完全支持这些标准的工具往往都不是真的完全支持。PFPC 的首席架构师Per Gyllstrom 指出，也有一些开发人员担心自动代码生成工具将抢掉他们的饭碗。他认为，重要的是要先在一些小型项目中实施，以消除人们对MDA的怀疑。

尽管MDA的优点之一是代码复用，但开发人员往往很难信任别人的代码，或者是机器产生的代码。

位于加州Novato的Fireman's Fund Insurance公司在进行大项目时遇到了这样的阻碍。该项目2000年开始，由一个精于面向对象开发的7人团队使用在IBM的保险应用架构（Insurance Application Architecture，IAA）中开发的 UML类图的部分来生成一个基于企业JavaBean框架的代码，这个框架包含了持久性、消息、事件以及对象分布方面的支持。

Rational Rose的脚本产生了超过80%的架构代码，Fireman's Fund 后来选用了Codagen 公司的一个代码生成工具。几个星期之内，Codagen的规则引擎和可重用模板就使得使用Rose脚本来产生模型到代码转换的需求消失得无影无踪。

但是，但优先级改变时，问题出现了，核心架构团队和需要手工编写业务逻辑代码的开发人员之间出现了问题，Fireman's Fund 的一位企业架构师Bill Nadal 说。

企业架构师团队在2002年重新拾起了火炬，这一次，Peter Herzum ，面向组件软件制造的一位专家，他的目标是设计可重用的组件。团队的目标是面向开发的“软件工厂”，其中组件可以被重用和拼装，以构建各种应用。

Nadal 说，Herzum的软件LLC以及Codagen面向IBM的MQSeries的金融版本使用了IAA的类模型以及Rose脚本来生成服务以及基于XML的消息。在他们演示中，应用MDA可以自动为持久化的类、服务接口以及XML信息生成代码。这为MDA方法提供了一个论据。

Fireman's Fund 的企业架构师现在正在用他们的组件蓝图（blueprints）为安全、内容管理以及元数据管理构建核心的基础模型。将来，他们计划要关注于业务层次的组件。

“大家都认为要在一个企业全面推广是耗时且成本昂贵的”，Nadal 认为，“这通常意味着你需在要在一些单独地项目中定义一些高质量的组件，以后可以多次复用。MDA是实现这个目标的重要一步。”

（自 COMPUTERWORLD，袁峰 摘译，不得转载用于商业用途）