【eNet硅谷动力消息】传统的企业应用软件两种典型的交付模式中，套装软件+二次开发能够大规模复用，避免重复劳动，且拥有强大功能，但弊端是没法满足企业个性化需求。而代码级的定制化虽然能够实现“量体裁衣”，却往往难以体现企业的变化和成长，无法做到“随需应变”。一直以来，如何趋利避害，取两者之长弃两者之短成为软件工程和开发技术领域的重要课题。
在此大背景下，以BEA为代表的一批技术创新型公司率先提出并开始倡导面向构件的开发技术，该技术一改过去40年以计算机语言和代码为主导的传统开发模式，转而采用构件库这一全新思路。但这种被业界形象地称为“搭积木”式的软件开发方式能够成为今后信息化的主流方向吗？
软件开发：从“打桩”到“搭积木”
2003年，国家对土地转让中出现的“黑洞”开始严格控制，“土地交易系统”一时之间成为解决问题的利器之一。在此形势下，上海市土地局开始把建立“上海市土地交易子系统”当作当时最紧急的任务。
谈及该系统，曾经参与系统项目实施和咨询工作的上海普元信息技术有限责任公司技术支持总监王克强记忆犹新：“这个系统的投资应该说并不算很大—1290万元人民币，但当时项目任务的紧迫性给人的印象很深，尤其是在开始的一个多月，几乎陷入困境。”
“这个系统基于B/S架构和三层系统机构，包括从编制招标文件到签订合同的整个流程管理”，王介绍说：“整个项目是由普元和另外两家软件公司共同实施完成，最终采用了面向构件开发技术（EOS平台），普元主要提供了开发平台和项目咨询服务。”
王克强介绍，当时“任务紧急，功能设置不明确”，这也是开发过程中遇到的主要困难。“粗线条地概括，该项目的主要困难是由于业务需求从头到尾一直在变动，导致初期需求分析需要不断修改，开发工作迟迟不能展开，从而陷入僵局。”
由于上海市土地管理局规划的操作流程和具体的业务操作存在一定差别，特别是根据各个区的要求还要进行相应的改进和调整，这样的调整从开始的需求分析到最终的试运行和调试都一直存在。并且刚开始时的开发采取的是传统的“从代码级开始编写”的定制方式，虽然一开始进展尚算顺利，但之后不久，项目的需求分析人员就发现由于用户需求随时变动，不得不经常修改厚厚的需求分析文档，项目进展很快陷入了僵局。
采用了普元EOS开发平台之后，从接到客户需求到提出应用基本成型的应用框架仅仅用了5个人5天时间，而接下来的设计开发阶段只用了2个月，仅占整个开发周期时间的一半。
“传统的代码式开发方式就像打桩，一行行代码写出来，桩子就慢慢砸深，一旦有问题，就需要把桩子拔出重来，然后开发一个新的应用系统又要重复打另一根桩—事实上很多功能模块都是可以复用的，根本不用作无用功。而面向构件技术及相应的开发平台主要解决的就是这个问题，打个比喻，面向构件就像‘搭积木’，能够方便拆卸和重新组装，对应到开发就是可以同时做到随需应变、随时修改、高比率复用，而上海市土地局的这个系统最需要的就是这样的开发方式。事实上，这个系统相当典型，很多项目在开发过程中都有着类似的特点。”
据了解，所谓面向构件技术，就是将代码组成的可实现特定功能的模块固化为一个个“构件”并使之对开发人员可视化，最终使开发人员告别“写代码”这种枯燥繁琐、近乎手工业的工作方式，转而像“搭积木”一样利用构件库中每个构件的映射实现编程。用王克强的说法，“搭积木是一种艺术，而打桩则是折磨。”
面向构件：为何叫好不叫座？
事实上，采用“搭积木”方式生产软件一直是软件开发人员的共识，但由于技术积累及开发传统等多方面原因，直到本世纪初才逐步得到实现，也涌现出了BEA Weblogic Workshop、IBM Websphere等一批有代表性的面向构件开发平台。
在此大背景下，以BEA为代表的一批技术创新型公司率先提出并开始倡导面向构件的开发技术，该技术一改过去40年以计算机语言和代码为主导的传统开发模式，转而采用构件库这一全新思路。但这种被业界形象地称为“搭积木”式的软件开发方式能够成为今后信息化的主流方向吗？
软件开发：从“打桩”到“搭积木”
2003年，国家对土地转让中出现的“黑洞”开始严格控制，“土地交易系统”一时之间成为解决问题的利器之一。在此形势下，上海市土地局开始把建立“上海市土地交易子系统”当作当时最紧急的任务。
谈及该系统，曾经参与系统项目实施和咨询工作的上海普元信息技术有限责任公司技术支持总监王克强记忆犹新：“这个系统的投资应该说并不算很大—1290万元人民币，但当时项目任务的紧迫性给人的印象很深，尤其是在开始的一个多月，几乎陷入困境。”
“这个系统基于B/S架构和三层系统机构，包括从编制招标文件到签订合同的整个流程管理”，王介绍说：“整个项目是由普元和另外两家软件公司共同实施完成，最终采用了面向构件开发技术（EOS平台），普元主要提供了开发平台和项目咨询服务。”
王克强介绍，当时“任务紧急，功能设置不明确”，这也是开发过程中遇到的主要困难。“粗线条地概括，该项目的主要困难是由于业务需求从头到尾一直在变动，导致初期需求分析需要不断修改，开发工作迟迟不能展开，从而陷入僵局。”
由于上海市土地管理局规划的操作流程和具体的业务操作存在一定差别，特别是根据各个区的要求还要进行相应的改进和调整，这样的调整从开始的需求分析到最终的试运行和调试都一直存在。并且刚开始时的开发采取的是传统的“从代码级开始编写”的定制方式，虽然一开始进展尚算顺利，但之后不久，项目的需求分析人员就发现由于用户需求随时变动，不得不经常修改厚厚的需求分析文档，项目进展很快陷入了僵局。
采用了普元EOS开发平台之后，从接到客户需求到提出应用基本成型的应用框架仅仅用了5个人5天时间，而接下来的设计开发阶段只用了2个月，仅占整个开发周期时间的一半。
“传统的代码式开发方式就像打桩，一行行代码写出来，桩子就慢慢砸深，一旦有问题，就需要把桩子拔出重来，然后开发一个新的应用系统又要重复打另一根桩—事实上很多功能模块都是可以复用的，根本不用作无用功。而面向构件技术及相应的开发平台主要解决的就是这个问题，打个比喻，面向构件就像‘搭积木’，能够方便拆卸和重新组装，对应到开发就是可以同时做到随需应变、随时修改、高比率复用，而上海市土地局的这个系统最需要的就是这样的开发方式。事实上，这个系统相当典型，很多项目在开发过程中都有着类似的特点。”
据了解，所谓面向构件技术，就是将代码组成的可实现特定功能的模块固化为一个个“构件”并使之对开发人员可视化，最终使开发人员告别“写代码”这种枯燥繁琐、近乎手工业的工作方式，转而像“搭积木”一样利用构件库中每个构件的映射实现编程。用王克强的说法，“搭积木是一种艺术，而打桩则是折磨。”
面向构件：为何叫好不叫座？
事实上，采用“搭积木”方式生产软件一直是软件开发人员的共识，但由于技术积累及开发传统等多方面原因，直到本世纪初才逐步得到实现，也涌现出了BEA Weblogic Workshop、IBM Websphere等一批有代表性的面向构件开发平台。
| 第 [1] [2] 页 下一页 |
