飘
飘香剑雨
Unregistered / Unconfirmed
GUEST, unregistred user!
http://www.sina.com.cn 2002/03/11 13:03 赛迪网-中国计算机报
文/孙志永、蔡茂
我国的软件开发已经逐步从原来的手工作坊式发展到了软件工程的阶段。同时
，软件开发本身也在不断发展，已从“算法＋数据结构＝程序”逐步发展到了“设
计模式＋对象组件＋开发工具＝程序”。开发工具的选择，已经成为软件开发成功
的要素之一。
开发工具的选择主要决定于两个因素：所开发系统的最终用户和开发人员。最
终用户需求是一切软件的来源和归宿，也是影响开发工具的决定性因素；开发人员
的爱好、习惯、
经验也影响着开发工具的选择。严格的软件工程管理和开发人员的技术水平是软件
开发成功的关键。
本文介绍一些选择软件开发工具的思路，重点强调在满足客户群体的情况下，
软件工具服务于软件工程思想的重要性。
开发工具 争显锋芒
首先需要强调的是：开发工具的比较没有绝对的标准。评价一种开发工具，不
仅要看它对设计模式、对象结构以及管理的支撑情况，更重要的是要针对具体的使
用环境、开发方法、结构体系、开发群体以及使用群体来评价一种工具的适宜程度
。
现有的开发工具大概分为大而全和小而专两种类型。Microsoft的Visual
Studio系列和IBM的Visual Age系列应该属于前者；其他很多工具，像
Delphi/C++Builder/JBuilder/Kylix、PowerBuilder/PowerJ，还有大量的各种
SDK等都具有各自的特点，属于小而专的类型。
大而全的工具一般都提供从前端到后台，从设计到编码测试的完整工具，但在
一些特定的功能上，它们不如小而专的工具。
Visual Studio.NET的UML开发工具(Visual Modeler/Visio)一般只能和
Rational Suite中Rational Rose的Logical View相比，它不可能有完整的
Rational Unified Process流程；其可视化的Visual Basic没有办法和
Delphi/C++Builder在速度和功能上相比。
虽然Visual Studio.NET的各个部分都有不足，但其Visio工具能够更快、更方
便地和编程语言整合在一起。Visual Basic在和Office等工具整合时遇到的问题(
数据类型转化等)比Delphi/C++Builder要少得多。所以，工具类型和具体的情况决
定了特定条件下软件开发工具最优的选择。
欲善其事 先利其器
开发工具的选择主要决定于两个因素：所开发系统的最终用户和开发人员。最
终用户需求是一切软件的来源和归宿，也是影响开发工具的决定性因素；开发人员
的爱好、习惯、经验也影响着开发工具的选择。
最终用户的需求
程序的最终使用群体是软件开发的服务对象，也影响着开发工具的选择。从计
算机使用的程度分，最终的使用者可以分为IT人员、各行业的专业人员以及普通用
户。使用者的不同，对于软件的需求就不会相同。IT人员自然需要更多的功能、更
自由的定制/二次开发空间；行业用户往往需要一个整体的解决方案，从而提升其
整体竞争力；普通用户显然要求更方便简单地使用。用户的需求分别在自由度、涵
盖度、针对性、方便性等维度展开。
扩展软件自由度
为了扩展软件的自由度，较少的封装和充分的功能暴露是必然的。为了让用户
自由使用Windows的功能，自由访问操作系统和硬件资源的语言C++或者Assembler
应该是最好的选择。Visual C++成为Microsoft对其操作系统功能的“权威”封装
，至今在Windows系统级开发中占据主流地位；C++ Builder扩充的标准的C++语法
，提供了RAD(Rapid Application Development)的支持，但是它的VCL(Visual
Component Library)大部分是用Delphi写的，不像Visual C++的MFC/ATL类库的纯
C++源代码，对于C++程序员的深入编程不利。最近开放源代码(Open Source)运动
风靡全球，开放源代码的C++工具中，GCC受到了普遍的采用。它不仅可以在各种流
行操作系统(Windows、Linux、Solaris、HP-Unix)上运行，而且支持Object C、
C++的各种扩充语法，甚至可以编译Java代码。
涵盖度各取所求
关于涵盖度的要求，不同的系统也是不尽相同的：有的可能要求涵盖前端、中
间件、后台、数据库，也有可能要求涵盖各种操作系统和硬件平台。Visual
Studio .NET和IBM的电子商务平台都能够提供从客户端、中间件到数据库的整体开
发支持。
Visual Studio.NET甚至将可视化带到了Web客户端，通过拖放完成Web页面以
后，可以双点到后台处理程序的框架代码中。从软件工程的思想看来，Visual
Studio.NET给程序员提供了强大而且方便的功能，但是并没有明确的支持需求分析
的流程。IBM的Visual Age系列在这个方面做得不错，Visual Age UML Designer支
持从需求分析到设计、编码的相对完整过程(不过，在代码生成方面仅仅对Java和
Smalltalk的支持比较好)。
Visual Studio.NET采用COM+作为组件模型，其生成的Web客户端对于平台没有
限制。不过，虽然.NET框架应该可以移植到非Windows平台上运行，但是其中间件
和服务端还没有看到在Unix或者Mac OS上的成功案例。IBM
VisualAge+WebSphere+DB2系列大量采用JavaBEAn/J2EE作为组件模型，由于Java的
平台无关性，客户端和中间件的跨平台性就比较好。
当然，用小而专的工具组合起来也能完成这些工作，Rational Suite可以完成
从业务建模、系统建模、模块建模以及发布测试的完整过程，Delphi/C++Builder
可以利用CORBA或者COM+作为中间件，JBuilder 6更是可以采用Visibroker或者
orbix等各种CORBA产品或者WebSphere、iPlanet、BAS、WebLogic等各种J2EE产品
。但是，如果不明白Rational中UML和代码映射的方法以及C++Builder/Delphi/
JBuilder对于代码的管理方式，要让建模和编码配合起来，就需要在Rational
Rose中设置ClassPath以及在Borland工具中设置源代码目录。其中的过程和可能出
现的问题都很多，而在Visual Studio.NET中，这些工作仅仅是点几下鼠标的事情
。
也有像Ensemble这样的公司，专门集成小而专的工具，但是这些软件的成熟度
以及学习和掌握也是问题。当然，在局部涵盖性上，Delphi使用CLX的程序可以在
Kylix上编译，从而在Linux上运行；Raining Data Corporation的Omnis Studio
3.1甚至直接支持跨越Windows和Linux平台的RAD开发。
针对性各有特色
在针对性上，各个工具都具备各自的优势。在单机应用上，Visual FoxPro具
有全球最快的数据访问引擎。而PowerBuilder在开发两层数据库应用上，特别是用
数据窗口和Sybase数据库后台挂接，用PowerDesign建模，不仅开发速度快，而且
效率和稳定性也比较好。在三层应用上，使用Visual Basic/C++/C#+ADO，如果再
使用SQL Server，就在性能、开发效率、稳定性上都有保证；而使用
C++Builder/Delphi+DataSnap(MIDAS)，在挂接非微软数据库，或者需要和CORBA程
序交互时都具有优势。
对于多层分布式应用，COM+规范和CORBA产品(orbix, visibroker等)往往决定
了开发工具的选择。COM+的开发工具一般采用Visual Studio.NET或Borland的产品
，而由于CORBA的编程语言和系统平台的无关性，各种开发平台一般都可以。另外
，针对C/C++编程，DSET公司的DSG在高端应用(一般在电信领域)中，它在与网络协
议栈的无关性、同/异步消息处理、海量通信能力、嵌入式到大型机的移植性等方
面,具有独特的优势。在服务器端开发上，COM+、CORBA 3.0、J2EE都支持组件模型
，分别利用MSMQ、CORBA Messaging System、JMS完成异步通信。COM+仍然主要集
中在Windows平台上，CORBA 3.0的Java语言部分包含整个J2EE规范。但是，CORBA
作为一个跨语言跨平台的规范，现在支持3.0版本非Java语言的产品还不多，支持
其核心——CCM(CORBA Component Model)的C++编程的产品有iCMG公司K2-CCM等。
J2EE的组件(EJB)已经发展到了1.2版本。满足该规范的产品——BEA
WebLogic、Borland BAS、 IBM WebSphere、Oracle 9i甚至免费的JBOSS都得到了
广泛的应用。BEA WebLogic 7.0在前端开发工具上做了大量的工作，声称将J2EE开
发和Visual Basic放在同一个级别上(其内部名字就是Visual Basic for Java)。
微软方便性最好
在方便性上，由于有大量用户的实践，微软的开发工具应该是最好的。它在可
视化、工具间互操作性、稳定性、文档的丰富性上都具有明显的优势。Borland
Delphi/C++Builder在可视化上和Visual Basic/C#基本上类似，但是他们在稳定性
上不足(C++Builder 5.0自动生成的CORBA程序的debug版会报错(Exception))；IBM
Visual Age系列的稳定性不错，但是它们的可视化编程不是非常方便；在文档方
面，更是没有一种工具具有Visual Studio自带的MSDN那样的容量(两张光盘)。
开发者的偏爱
开发工具是给开发者用的，开发人员是这些工具的用户。不同的开发人员对工
具的偏爱也不同。Pascal程序员一般都会钟爱Delphi/Kylix；Windows的C++程序员
则会选择C++Builder或者Visual C++；在不同平台下C++编程的人员可能会更加喜
欢GCC；Smalltalk程序员恐怕就只会考虑Visual Age Smalltalk；而Turbo Lisp、
Visual Fortran、Perl Builder等开发工具在其他各种编程语言的程序员中也被大
量采用。
现在，各种编程语言的功能互相融合，像Borland Delphi和C++Builder之间的
功能差异，在语言上表现得已经非常少了。除了编程语言的偏爱以外，不同操作系
统的程序员使用的工具也不同：Solaris系统下的程序员更多地使用CC编写C++/C的
后台程序，用Perl编写框架或者测试脚本，用TCL/TK编写界面程序；虽然Windows
下也有这些工具，但是更多程序员恐怕还是会选择支持RAD的工具。现在，人们普
遍认可一种趋势：操作系统、编程语言在开发上的差异正在迅速消失。XML有效地
解决了在不同系统下统一数据表达的问题；通过虚拟机，Java程序能够在不同操作
系统下执行；微软的.NET框架能够利用C++/Basic/C#来编程。
平台和语言间的交互使得各种工具对于通用标准的支持越来越重视。Sun新推
出的Java的XML开发包，明确支持由微软和IBM提出的SOAP规范，Visual Studio.
NET也明确支持Java语言(J#)。虽然现在还仅仅是一个开端，但是，语言和平台的
融合是一种不可阻挡的趋势：必然有更多的编译器将其他语言编译成为Java字节码
，Visual Studio.NET也必然会将程序编译到其他操作系统中。
然而，伴随着技术的融合，差异性也将永远存在。微软为了互联网应用而推出
.NET框架，Windows和Visual Studio都做了巨大的改进。为了这个框架，Visual
Studio.NET甚至推出了一个新的编程语言C#，它具有Java语言的大部分特征，同时
在固定内存区允许使用指针。C#在设计上确实非常先进，但是由于缺乏大量的使用
，而且缺乏Java 2中的安全特性，是否能够吸引大量的程序员，还是一个未知数；
同时，C#中的很多特性(像对象方法的修饰词等)都是微软COM+规范在编程语言中的
映射，这会在今后的操作系统平台移植时产生麻烦。
除了开发人员的平台特性和语言偏爱以外，人员间的配合模式也决定着工具的
选择。自由软件普遍采用的跨地域开发模式，对于使用CVS版本管理系统的开发工
具非常合适。而由于Visual Studio.NET在开发调试中会改变本地Windows注册库，
跨地域开发就非常不方便。
当然，不能排除别的因素对于开发工具的影响。举例来说，行业的特点以及遗
留系统(legacy system)对于开发的影响也是不可忽略的：电信行业的软件开发，
由于有ITU-T规范的存在，Java要代替现有的C/C＋＋开发模式还不能像通用软件那
么快。但是，归结起来，软件的开发总是一个由人完成和为人服务的。无论其他因
素的影响力现在有多大，今后的发展也必然是由人来决定的。
开发利器1 PB集成 降本提效
互联网已经从前几年的“接入为王”、“内容为王”，发展到了今天的“应用
为王”的时代了。大批的应用软件开发人员也将进入Web应用开发领域。他们熟悉
应用业务领域、熟悉传统C/S的开发技巧，但不一定熟悉HTML/JavaScript, 也不一
定熟悉3-tier体系架构。这对平台和工具厂商来说是一个巨大的商机。
PB异军突起
现在究竟是什么阻碍了Web应用和3-tier的大批出现呢？仍然是工具。一个好
的开发工具应该是在日常开发中能够屏蔽烦琐的技术细节，并允许高级开发人员直
接干预这些技术细节。在3-tier开发中，我们会同时面对数据库操作(表、数据维
护、存储过程和触发器的维护等)，Component编写和调试, 网页(尤其是调用这些
Component的动态页面)的编写和调试，以及一些2-tier应用程序的维护等许多任务
。
一般说来，完成这些任务需要使用多种工具，在开发时需要在多个工具之间切
换，由此造成了开发效率的低下和开发难度的提高。而PB8/PJ4很好地解决了这些
问题。所有这些任务，都可以在同一个开发环境中完成，开发人员能非常快速地编
写基于数据库的业务逻辑Component以及调用这些Component的Web-Client或
PB-Client。尤其是Sybase把2-tier中的王牌Datawindow扩展到了HTML领域，使得
数据库驱动的动态页面实现起来非常容易。
总体来说，Sybase的优势在于具备开发企业信息系统所需的全系列的工具，包
括系统分析和系统设计工具PowerDesigner、应用开发工具PowerBuilder和PowerJ
、应用服务器EAServer(内含Jaguar和PowerDynamo)、数据库Adaptive Server
Enterprise(以及复制服务器等)。这些工具由于是同一家公司的产品，具有非常好
的互操作性。同时，这些工具对标准的支持非常好，比如EAServer对组件模型就同
时支持COM、CORBA和J2EE，可以用C/C++和JAVA来编写各种Component, 甚至以
CORBA的形式支持用PowerBuilder直接编写Component。
反面意见
许多人都提到PB的许多不足，比如与VB和Delphi相比界面较单调、对于
Windows API的调用能力较差(PB本身不直接支持指针)等等。然而，在某些特定场
合，这些问题会变成优势。企业应用的核心在于数据访问和业务逻辑。界面的花哨
倒并不重要。在企业应用中，好的用户界面设计是指符合用户业务思维方式和业务
流程的界面设计，而不是花哨的界面设计。而不支持指针，则会大大提高程序的可
靠性。这些问题，实际上都源自PB产品的定位：不是作为一个通用开发工具，而是
作为一个专用的企业信息系统开发工具。在这个领域，PB/PoerJ确实是无可匹敌的
。
在系统分析和设计工具领域，Rational Rose是一个常被人称道的工具。然而
在现实的信息系统项目和应用软件开发中，我们面对的不是纯面向对象的环境，而
是关系数据库和面向对象的混合环境。并且，用户无一例外地希望数据库的访问有
尽可能高的性能。
第三方工具
在互联网上您可以找到大量第三方的工具来帮助您提高您在开发
PowerBuilder应用时的效率和质量。下面就是两个例子：
大家一定会了解Visual C/C++与MFC的关系。在C/S环境中，PowerBuilder也有
一个PFC与之对应。当然，两者的层次是不同的。MFC提供了底层的封装，而PFC提
供了数据库应用的更高层面的封装。对PFC的深入应用可以大大提高系统的开发效
率和开发质量。进入到3-tier的世界，如果用PB来开发Component，同样也有一些
很好的类库，比较著名的就是EAF。对这些类库的深入应用并形成自己的类库，是
迅速提高产品和项目的质量和效率捷径。
确保应用软件的质量一定是许多人都很头疼的问题。那我们就先来看看最基本
的问题吧。在单元测试这个领域，大家一定了解在Java中的JUnit这个单元测试工
具。PB中也有一个对应的工具叫做PBUnit。你可以在开发过程中，在PBUnit环境中
编写测试脚本，反复对你的Object进行回归测试，并自动记录、分析测试结果。对
于常常是包含了大量数据处理的PB应用程序来说，这是非常有价值的。(祝枫)
开发利器2 WebSphere Studio 开放开发
IBM正在交付一个基于WebSphere Studio Workbench技术的电子商务应用程序
开发工具的新套件。WebSphere Studio Workbench是一个用于工具开发和集成的平
台。这是 IBM 对开放源码Eclipse Project的增值实现。WebSphere Studio
Workbench提供用于开发源代码编辑器和其它用户界面的一组API、模型和框架，以
及对资源管理的公共服务、调试和团队编程的访问。该平台实现了现有标准并提供
用于将功能部件和函数作为插件添加的扩展点。IBM 和独立软件供应商(ISV)正在
开发插入这个框架的工具。
WebSphere Studio Site Developer和WebSphere Studio Application
Developer是IBM合并和扩展WebSphere Studio Workbench而成的两个产品。这些产
品是计划中将要跨越所有电子商务开发角色的集成开发工具套件的一部分，从Web
开发者到Java开发者、到商务分析师、到设计师、到企业程序员。WebSphere
Studio开发工具系列将添加更多产品。
客户希望有开放标准、工具集成、更大的灵活性和结合到现有应用程序的能力
。这些还只是WebSphere Studio产品套件所交付的部分优点。
垂直和水平集成
传统上，软件供应商提供垂直工具，迫使客户自己做集成。WebSphere Studio
Workbench的目的是提供一个 IBM 和 ISV 都能容易地扩展的平台。供应商已经拥
有了该技术并在此基础上积极地构建工具。
在Workbench上构建的每个WebSphere Studio产品都将提供已集成的工具，使
您可以专注于构建应用程序而不必费力去集成工具。
开放标准
WebSphere Studio套件中的所有产品都是构建在开放标准上的，并且它们所生
成的代码也是与开放标准一致的。可以构建和部署满足Servlets 2.2、JavaServer
Pages(JSP)1.1和 Enterprise JavaBEAns(EJB)1.1规范的最新型的
(state-of-the-art)服务器端应用程序(在Site Developer产品中将不包含EJB开发
工具。)所有构建在WebSphere Studio Workbench上的产品，都包含
CVS(Concurrent Versions System)。
基于角色的开发
WebSphere Studio产品系列中的每个成员都是为特殊电子商务开发角色或某种
角色范围设计的。例如，Site Developer是为开发和管理整个网站的Web开发者设
计的。Application Developer包含Site Developer的所有功能并添加了对在业务
逻辑方面(包含 EJB)工作的程序员的支持。当IBM交付WebSphere Studio系列的未
来成员时，它将扩展其选项范围，将产品与用户的角色和需求相匹配。
在每个WebSphere Studio解决方案内部，面向任务的视图筛选出复杂性并只提
供与手边的任务相关的功能。用户根据此时正在开发或分析什么，或者根据他们在
项目中的角色切换视图。因为不同的开发者以不同的方法工作，所以视图可以定制
。因为他们使用WebSphere Studio Workbench技术构建，所以所有工具和视图共享
一个公共外观，这减小了学习难度并使得用户的生产力最大化。并且，因为项目的
开发资源存储在单个资源库中，所以您获得了对项目的最大共享性和一致团队支持
。
最大编程性能
除了将应用程序开发者们从工具集成任务中解放出来以外，Site Developer和
Application Developer 都以许多方法优化了程序员的生产力。(苏永)
开发利器3 微软.NET和C#
微软现在把自己的希望寄托在新的.NET应用程序框架之上。虽然在.NET中几乎
可以使用任何一种编程语言，但是开发者更热衷的还是微软的C#和C++。因为它们
改变了几乎所有从桌面软件到具有Web功能的企业解决方案的Windows开发规则,所
以这些技术的潜力非常巨大。
.NET框架和C#扩展了Windows的功能，C#和Visual Studio .NET的结合使得创
建和配置Web服务几乎可以自动进行。并且，和传统的ASP应用程序相比，ASP.NET
应用程在性能、稳定性以及可扩展性方面都有了实质性的提高。
虽然有很多优点，但是.NET价格不菲。目前的Windows开发者如果要转向.NET
框架，都必须进行再培训，并且所需费用很高。由于.NET框架中有很多重大的改变
以及复杂度的提高，因而现在的VB程序员将无法应对这些变化。C++程序员则会因
为C#继承了自己熟悉语言中的基本内容而感到高兴，但是他们也会发现在API以及
语言方面C#还是有很大的改变。
在ASP.NET中，由于不再使用VBScript，而只用JScript，并且在系统服务中也
不再提倡使用COM(Component Object Model)，因此要把现有的Web应用程序转换成
ASP.NET，重新编写程序代码要耗费大量的时间和精力。如果要把现有Java项目转
入到.NET框架中，即使你使用的是J#(微软的Java开发语言)，那么要完成一个项目
的迁移，至少也要花费几个月的时间。如果要把服务器从Unix平台迁移到
Windows,那么更是要求所有的IT职员都必须掌握一门新的技术。
考虑到以上因素，我们就很容易理解为什么.NET和C#会让人们既关注又担忧。
当然，对于已经在从事Windows平台下开发的公司和企业来说，不是接不接受.NET
的问题，而是什么时候接受的问题。目前普遍的观点认为，如果不及时实现向.
NET的迁移，那么将最终不堪忍受来自开发者、商业伙伴、应用程序提供商以及工
具提供商的压力。
当然，相对于来自Java、Unix和Linux拥护者的挑战来说，微软要把Windows下
的开发者吸引到.NET框架上来。在和Java和J2EE的竞争中，微软主要有两张牌可打
，即Visual Studio .NET和Web服务。测试版的Visual Studio .NET IDE(整合开发
环境)已经在开发人员中引起了不小的震动。相信在Web服务领域和Java竞争时，它
将成为微软的一把利器。(伊利贵)
开发利器4 钟情Delphi 6
Delphi 6 是当前 Windows 平台上全面支持最新 Web 服务的快速开发工具。
无论是企业级用户还是个人开发者，都能够利用Delphi 6 轻松、快捷地构建新一
代电子商务应用。Delphi 6优秀在何处？
高效的开发
Delphi 6是一个RAD(Rapid Application Development 快速开发工具)。它有
可视化的开发环境，当然具有类似功能的开发工具也不少(如Visual Basic)，但
Delphi 6有如下的独到之处：
Delphi 6是真正面向对象的。其构建的VCL库中的所有组件都可以被继承以创
建新的组件，包括窗体类TForm。相比之下，ActiveX组件缺乏这种灵活性。
Delphi 6的CodeInsight技术(即代码自动完成功能)是建立在编译器信息上的
，而VB使用的是类型库信息，使用编译器信息的好处是更具灵活性。不过，时常有
程序员抱怨Delphi 6的代码提示时间太长。
高效的编译
可以说，Delphi 6是Windows平台上最快的高级语言本地代码编译器了。编译
速度快有什么好处呢？快速的编译器可以让你频繁地在修改代码和编译运行的状态
间切换。至少，我自己已经非常习惯了这样的工作方式：运行程序看一下效果，退
出程序修改少量代码再运行程序。而Delphi 6的编译器从来不会让我有等待的感觉
。
高效的执行
Delphi 6与C++Builder使用的是同一个后端优化器，因此其生成代码的效率与
优秀的C++编译器生成代码效率相同。
Delphi 6生成完全本地代码，因此Delphi 6编译结果的可执行文件可以被独立
执行、分发(对于“绿色软件”的开发，这一点十分重要)。不需要其他运行库支持
。当然，你也可以选择动态链接编译，这样可以大大减小可执行文件的长度，不过
这种情况下在分发程序时，必须同时分发必要的运行库文件。
构建Windows/Linux 应用
Delphi 6 与Kylix兼容。使用Kylix，可在Linux平台上重新编译基于Windows
平台的CLX应用；而利用Delphi 6，即可在Windows上重新编译基于CLX组件的
Linux应用。Delphi 6包含BaseCLX、VisualCLX、DataCLX和NetCLX四个组件。
与AppServer集成
Delphi 6通过最新SIDL与AppServer连接。它为AppServer应用开发出高性能、
具有丰富GUI环境的客户端应用，通过Internet将AppServer的EJB功能作为遵循业
界标准的SOAP/XML Web服务发布到全球。(李争)
编后语
现在，各种开发工具的功能相互大量重复，一个大而全的工具几乎总是可以被
几个别的工具代替。工具的选择确实非常让人迷惑，但是，无论是开发人员还是管
理人员都应该意识到：工具只能起到协助的作用，严格的软件工程管理和开发人员
的技术水平才是软件开发成功的关键。成功开发加上有效的管理和市场运作，才能
构成一个完整的成功软件。
小资料
开发工具的对垒
软件开发人员没有人会不知道微软的.NET和Sun的J2EE。二者尽管所提供的方
法不同，但都具有许多非常优秀的特点。
二者的可移植性都非常好。.NET的核心只能工作在Windows环境下，但从理论
上讲可以支持多种语言开发?只要这些语言的子集已经定义好，并为他们建立了IL
编译器?。对于J2EE来说，只要遵循Java VM?规则?和一组平台需要的服务，就可以
在任何平台上工作。因为所有定义J2EE平台的规范，都已经向公众公布，所以，许
多供应商也提供兼容产品和开发环境。
.NET并不是一种精巧的标志，而是微软策略的重大转移，它将给其操作系统平
台带来更大的支持率。现在他们正努力把Java和开放资源自身所特有的语言逐步开
放，然后实现直接满足开发商的需要。Java清除了平台的障碍。但是为了用J2EE来
做开发工作，用户必须在Java环境下工作。而.Net是想让用户使用自己选择的语言
来建造.NET应用程序，这是十分美妙的。
对于微软的开发商，.NET是一个好的构架，用户可以将许多事情交给微软的体
系结构去完成。ASP.NET比ASP好，ADO.NET比ADO和DCOM出色，C＃比C和C＋＋更好
。所以，如果现在正在微软的开发构架中从事开发工作，将.NET的元件采纳到你的
体系结构中，显然是一个明智的选择。不过，虽然.NET平台描绘了美好的蓝图，但
其设想要全部成为现实，还有较长的路要走。例如IL公共语言的运行，目前还有某
些明显的障碍需要克服。想要把每一种语言和元件运行时集成起来，必须定义这种
语言的子集/超集，并清晰地影射到IL上；此外必须定义结构，以便提供IL需要的
元数据；还有必须要开发适用于两种编译语言结构的编译器，集成到IL部件字节代
码中；同时还要生成对现有IL元件的语言专用接口。
由于历史的原因，在Java语言中使用非Java语言，必须要开发非Java语言到
JavaVM的众多转换器。因此，在Java环境中写代码，就必须要承受将额外的翻译工
作加到目标构架上。如果Java环境是目标，人们通常会选择学习Java。而如果目标
环境是.NET，那么人们将会选择学习C＃。(伊利贵)
64位的软件开发
因为在内存容量、I/O处理效率等方面64位系统有着32位系统无可比拟的优势
，因此在高端应用上，Sun、IBM和HP等大腕一直热衷于64位系统。可以预见，在不
久的将来，Intel的64位处理器将成为Sparc的主要竞争对手。
不过，由于Linux和Windows环境下的主要的应用程序都是32位的，因此，软件
厂商和自由软件项目必须为64位系统重写他们的应用程序。所幸的是，由于Java的
盛行以及.NET的出现，这将使得应用程序向Itanium的移植变得非常神速。IBM已经
推出了其用于Itanium的Java SDK(软件开发工具包)，此外，微软的.NET框架在其
发行.NET Server时，也将登陆Itanium。而Borland更是已经使其Java开发工具和
服务器可以在Itanium上运行。(伊利贵)
文/孙志永、蔡茂
我国的软件开发已经逐步从原来的手工作坊式发展到了软件工程的阶段。同时
，软件开发本身也在不断发展，已从“算法＋数据结构＝程序”逐步发展到了“设
计模式＋对象组件＋开发工具＝程序”。开发工具的选择，已经成为软件开发成功
的要素之一。
开发工具的选择主要决定于两个因素：所开发系统的最终用户和开发人员。最
终用户需求是一切软件的来源和归宿，也是影响开发工具的决定性因素；开发人员
的爱好、习惯、
经验也影响着开发工具的选择。严格的软件工程管理和开发人员的技术水平是软件
开发成功的关键。
本文介绍一些选择软件开发工具的思路，重点强调在满足客户群体的情况下，
软件工具服务于软件工程思想的重要性。
开发工具 争显锋芒
首先需要强调的是：开发工具的比较没有绝对的标准。评价一种开发工具，不
仅要看它对设计模式、对象结构以及管理的支撑情况，更重要的是要针对具体的使
用环境、开发方法、结构体系、开发群体以及使用群体来评价一种工具的适宜程度
。
现有的开发工具大概分为大而全和小而专两种类型。Microsoft的Visual
Studio系列和IBM的Visual Age系列应该属于前者；其他很多工具，像
Delphi/C++Builder/JBuilder/Kylix、PowerBuilder/PowerJ，还有大量的各种
SDK等都具有各自的特点，属于小而专的类型。
大而全的工具一般都提供从前端到后台，从设计到编码测试的完整工具，但在
一些特定的功能上，它们不如小而专的工具。
Visual Studio.NET的UML开发工具(Visual Modeler/Visio)一般只能和
Rational Suite中Rational Rose的Logical View相比，它不可能有完整的
Rational Unified Process流程；其可视化的Visual Basic没有办法和
Delphi/C++Builder在速度和功能上相比。
虽然Visual Studio.NET的各个部分都有不足，但其Visio工具能够更快、更方
便地和编程语言整合在一起。Visual Basic在和Office等工具整合时遇到的问题(
数据类型转化等)比Delphi/C++Builder要少得多。所以，工具类型和具体的情况决
定了特定条件下软件开发工具最优的选择。
欲善其事 先利其器
开发工具的选择主要决定于两个因素：所开发系统的最终用户和开发人员。最
终用户需求是一切软件的来源和归宿，也是影响开发工具的决定性因素；开发人员
的爱好、习惯、经验也影响着开发工具的选择。
最终用户的需求
程序的最终使用群体是软件开发的服务对象，也影响着开发工具的选择。从计
算机使用的程度分，最终的使用者可以分为IT人员、各行业的专业人员以及普通用
户。使用者的不同，对于软件的需求就不会相同。IT人员自然需要更多的功能、更
自由的定制/二次开发空间；行业用户往往需要一个整体的解决方案，从而提升其
整体竞争力；普通用户显然要求更方便简单地使用。用户的需求分别在自由度、涵
盖度、针对性、方便性等维度展开。
扩展软件自由度
为了扩展软件的自由度，较少的封装和充分的功能暴露是必然的。为了让用户
自由使用Windows的功能，自由访问操作系统和硬件资源的语言C++或者Assembler
应该是最好的选择。Visual C++成为Microsoft对其操作系统功能的“权威”封装
，至今在Windows系统级开发中占据主流地位；C++ Builder扩充的标准的C++语法
，提供了RAD(Rapid Application Development)的支持，但是它的VCL(Visual
Component Library)大部分是用Delphi写的，不像Visual C++的MFC/ATL类库的纯
C++源代码，对于C++程序员的深入编程不利。最近开放源代码(Open Source)运动
风靡全球，开放源代码的C++工具中，GCC受到了普遍的采用。它不仅可以在各种流
行操作系统(Windows、Linux、Solaris、HP-Unix)上运行，而且支持Object C、
C++的各种扩充语法，甚至可以编译Java代码。
涵盖度各取所求
关于涵盖度的要求，不同的系统也是不尽相同的：有的可能要求涵盖前端、中
间件、后台、数据库，也有可能要求涵盖各种操作系统和硬件平台。Visual
Studio .NET和IBM的电子商务平台都能够提供从客户端、中间件到数据库的整体开
发支持。
Visual Studio.NET甚至将可视化带到了Web客户端，通过拖放完成Web页面以
后，可以双点到后台处理程序的框架代码中。从软件工程的思想看来，Visual
Studio.NET给程序员提供了强大而且方便的功能，但是并没有明确的支持需求分析
的流程。IBM的Visual Age系列在这个方面做得不错，Visual Age UML Designer支
持从需求分析到设计、编码的相对完整过程(不过，在代码生成方面仅仅对Java和
Smalltalk的支持比较好)。
Visual Studio.NET采用COM+作为组件模型，其生成的Web客户端对于平台没有
限制。不过，虽然.NET框架应该可以移植到非Windows平台上运行，但是其中间件
和服务端还没有看到在Unix或者Mac OS上的成功案例。IBM
VisualAge+WebSphere+DB2系列大量采用JavaBEAn/J2EE作为组件模型，由于Java的
平台无关性，客户端和中间件的跨平台性就比较好。
当然，用小而专的工具组合起来也能完成这些工作，Rational Suite可以完成
从业务建模、系统建模、模块建模以及发布测试的完整过程，Delphi/C++Builder
可以利用CORBA或者COM+作为中间件，JBuilder 6更是可以采用Visibroker或者
orbix等各种CORBA产品或者WebSphere、iPlanet、BAS、WebLogic等各种J2EE产品
。但是，如果不明白Rational中UML和代码映射的方法以及C++Builder/Delphi/
JBuilder对于代码的管理方式，要让建模和编码配合起来，就需要在Rational
Rose中设置ClassPath以及在Borland工具中设置源代码目录。其中的过程和可能出
现的问题都很多，而在Visual Studio.NET中，这些工作仅仅是点几下鼠标的事情
。
也有像Ensemble这样的公司，专门集成小而专的工具，但是这些软件的成熟度
以及学习和掌握也是问题。当然，在局部涵盖性上，Delphi使用CLX的程序可以在
Kylix上编译，从而在Linux上运行；Raining Data Corporation的Omnis Studio
3.1甚至直接支持跨越Windows和Linux平台的RAD开发。
针对性各有特色
在针对性上，各个工具都具备各自的优势。在单机应用上，Visual FoxPro具
有全球最快的数据访问引擎。而PowerBuilder在开发两层数据库应用上，特别是用
数据窗口和Sybase数据库后台挂接，用PowerDesign建模，不仅开发速度快，而且
效率和稳定性也比较好。在三层应用上，使用Visual Basic/C++/C#+ADO，如果再
使用SQL Server，就在性能、开发效率、稳定性上都有保证；而使用
C++Builder/Delphi+DataSnap(MIDAS)，在挂接非微软数据库，或者需要和CORBA程
序交互时都具有优势。
对于多层分布式应用，COM+规范和CORBA产品(orbix, visibroker等)往往决定
了开发工具的选择。COM+的开发工具一般采用Visual Studio.NET或Borland的产品
，而由于CORBA的编程语言和系统平台的无关性，各种开发平台一般都可以。另外
，针对C/C++编程，DSET公司的DSG在高端应用(一般在电信领域)中，它在与网络协
议栈的无关性、同/异步消息处理、海量通信能力、嵌入式到大型机的移植性等方
面,具有独特的优势。在服务器端开发上，COM+、CORBA 3.0、J2EE都支持组件模型
，分别利用MSMQ、CORBA Messaging System、JMS完成异步通信。COM+仍然主要集
中在Windows平台上，CORBA 3.0的Java语言部分包含整个J2EE规范。但是，CORBA
作为一个跨语言跨平台的规范，现在支持3.0版本非Java语言的产品还不多，支持
其核心——CCM(CORBA Component Model)的C++编程的产品有iCMG公司K2-CCM等。
J2EE的组件(EJB)已经发展到了1.2版本。满足该规范的产品——BEA
WebLogic、Borland BAS、 IBM WebSphere、Oracle 9i甚至免费的JBOSS都得到了
广泛的应用。BEA WebLogic 7.0在前端开发工具上做了大量的工作，声称将J2EE开
发和Visual Basic放在同一个级别上(其内部名字就是Visual Basic for Java)。
微软方便性最好
在方便性上，由于有大量用户的实践，微软的开发工具应该是最好的。它在可
视化、工具间互操作性、稳定性、文档的丰富性上都具有明显的优势。Borland
Delphi/C++Builder在可视化上和Visual Basic/C#基本上类似，但是他们在稳定性
上不足(C++Builder 5.0自动生成的CORBA程序的debug版会报错(Exception))；IBM
Visual Age系列的稳定性不错，但是它们的可视化编程不是非常方便；在文档方
面，更是没有一种工具具有Visual Studio自带的MSDN那样的容量(两张光盘)。
开发者的偏爱
开发工具是给开发者用的，开发人员是这些工具的用户。不同的开发人员对工
具的偏爱也不同。Pascal程序员一般都会钟爱Delphi/Kylix；Windows的C++程序员
则会选择C++Builder或者Visual C++；在不同平台下C++编程的人员可能会更加喜
欢GCC；Smalltalk程序员恐怕就只会考虑Visual Age Smalltalk；而Turbo Lisp、
Visual Fortran、Perl Builder等开发工具在其他各种编程语言的程序员中也被大
量采用。
现在，各种编程语言的功能互相融合，像Borland Delphi和C++Builder之间的
功能差异，在语言上表现得已经非常少了。除了编程语言的偏爱以外，不同操作系
统的程序员使用的工具也不同：Solaris系统下的程序员更多地使用CC编写C++/C的
后台程序，用Perl编写框架或者测试脚本，用TCL/TK编写界面程序；虽然Windows
下也有这些工具，但是更多程序员恐怕还是会选择支持RAD的工具。现在，人们普
遍认可一种趋势：操作系统、编程语言在开发上的差异正在迅速消失。XML有效地
解决了在不同系统下统一数据表达的问题；通过虚拟机，Java程序能够在不同操作
系统下执行；微软的.NET框架能够利用C++/Basic/C#来编程。
平台和语言间的交互使得各种工具对于通用标准的支持越来越重视。Sun新推
出的Java的XML开发包，明确支持由微软和IBM提出的SOAP规范，Visual Studio.
NET也明确支持Java语言(J#)。虽然现在还仅仅是一个开端，但是，语言和平台的
融合是一种不可阻挡的趋势：必然有更多的编译器将其他语言编译成为Java字节码
，Visual Studio.NET也必然会将程序编译到其他操作系统中。
然而，伴随着技术的融合，差异性也将永远存在。微软为了互联网应用而推出
.NET框架，Windows和Visual Studio都做了巨大的改进。为了这个框架，Visual
Studio.NET甚至推出了一个新的编程语言C#，它具有Java语言的大部分特征，同时
在固定内存区允许使用指针。C#在设计上确实非常先进，但是由于缺乏大量的使用
，而且缺乏Java 2中的安全特性，是否能够吸引大量的程序员，还是一个未知数；
同时，C#中的很多特性(像对象方法的修饰词等)都是微软COM+规范在编程语言中的
映射，这会在今后的操作系统平台移植时产生麻烦。
除了开发人员的平台特性和语言偏爱以外，人员间的配合模式也决定着工具的
选择。自由软件普遍采用的跨地域开发模式，对于使用CVS版本管理系统的开发工
具非常合适。而由于Visual Studio.NET在开发调试中会改变本地Windows注册库，
跨地域开发就非常不方便。
当然，不能排除别的因素对于开发工具的影响。举例来说，行业的特点以及遗
留系统(legacy system)对于开发的影响也是不可忽略的：电信行业的软件开发，
由于有ITU-T规范的存在，Java要代替现有的C/C＋＋开发模式还不能像通用软件那
么快。但是，归结起来，软件的开发总是一个由人完成和为人服务的。无论其他因
素的影响力现在有多大，今后的发展也必然是由人来决定的。
开发利器1 PB集成 降本提效
互联网已经从前几年的“接入为王”、“内容为王”，发展到了今天的“应用
为王”的时代了。大批的应用软件开发人员也将进入Web应用开发领域。他们熟悉
应用业务领域、熟悉传统C/S的开发技巧，但不一定熟悉HTML/JavaScript, 也不一
定熟悉3-tier体系架构。这对平台和工具厂商来说是一个巨大的商机。
PB异军突起
现在究竟是什么阻碍了Web应用和3-tier的大批出现呢？仍然是工具。一个好
的开发工具应该是在日常开发中能够屏蔽烦琐的技术细节，并允许高级开发人员直
接干预这些技术细节。在3-tier开发中，我们会同时面对数据库操作(表、数据维
护、存储过程和触发器的维护等)，Component编写和调试, 网页(尤其是调用这些
Component的动态页面)的编写和调试，以及一些2-tier应用程序的维护等许多任务
。
一般说来，完成这些任务需要使用多种工具，在开发时需要在多个工具之间切
换，由此造成了开发效率的低下和开发难度的提高。而PB8/PJ4很好地解决了这些
问题。所有这些任务，都可以在同一个开发环境中完成，开发人员能非常快速地编
写基于数据库的业务逻辑Component以及调用这些Component的Web-Client或
PB-Client。尤其是Sybase把2-tier中的王牌Datawindow扩展到了HTML领域，使得
数据库驱动的动态页面实现起来非常容易。
总体来说，Sybase的优势在于具备开发企业信息系统所需的全系列的工具，包
括系统分析和系统设计工具PowerDesigner、应用开发工具PowerBuilder和PowerJ
、应用服务器EAServer(内含Jaguar和PowerDynamo)、数据库Adaptive Server
Enterprise(以及复制服务器等)。这些工具由于是同一家公司的产品，具有非常好
的互操作性。同时，这些工具对标准的支持非常好，比如EAServer对组件模型就同
时支持COM、CORBA和J2EE，可以用C/C++和JAVA来编写各种Component, 甚至以
CORBA的形式支持用PowerBuilder直接编写Component。
反面意见
许多人都提到PB的许多不足，比如与VB和Delphi相比界面较单调、对于
Windows API的调用能力较差(PB本身不直接支持指针)等等。然而，在某些特定场
合，这些问题会变成优势。企业应用的核心在于数据访问和业务逻辑。界面的花哨
倒并不重要。在企业应用中，好的用户界面设计是指符合用户业务思维方式和业务
流程的界面设计，而不是花哨的界面设计。而不支持指针，则会大大提高程序的可
靠性。这些问题，实际上都源自PB产品的定位：不是作为一个通用开发工具，而是
作为一个专用的企业信息系统开发工具。在这个领域，PB/PoerJ确实是无可匹敌的
。
在系统分析和设计工具领域，Rational Rose是一个常被人称道的工具。然而
在现实的信息系统项目和应用软件开发中，我们面对的不是纯面向对象的环境，而
是关系数据库和面向对象的混合环境。并且，用户无一例外地希望数据库的访问有
尽可能高的性能。
第三方工具
在互联网上您可以找到大量第三方的工具来帮助您提高您在开发
PowerBuilder应用时的效率和质量。下面就是两个例子：
大家一定会了解Visual C/C++与MFC的关系。在C/S环境中，PowerBuilder也有
一个PFC与之对应。当然，两者的层次是不同的。MFC提供了底层的封装，而PFC提
供了数据库应用的更高层面的封装。对PFC的深入应用可以大大提高系统的开发效
率和开发质量。进入到3-tier的世界，如果用PB来开发Component，同样也有一些
很好的类库，比较著名的就是EAF。对这些类库的深入应用并形成自己的类库，是
迅速提高产品和项目的质量和效率捷径。
确保应用软件的质量一定是许多人都很头疼的问题。那我们就先来看看最基本
的问题吧。在单元测试这个领域，大家一定了解在Java中的JUnit这个单元测试工
具。PB中也有一个对应的工具叫做PBUnit。你可以在开发过程中，在PBUnit环境中
编写测试脚本，反复对你的Object进行回归测试，并自动记录、分析测试结果。对
于常常是包含了大量数据处理的PB应用程序来说，这是非常有价值的。(祝枫)
开发利器2 WebSphere Studio 开放开发
IBM正在交付一个基于WebSphere Studio Workbench技术的电子商务应用程序
开发工具的新套件。WebSphere Studio Workbench是一个用于工具开发和集成的平
台。这是 IBM 对开放源码Eclipse Project的增值实现。WebSphere Studio
Workbench提供用于开发源代码编辑器和其它用户界面的一组API、模型和框架，以
及对资源管理的公共服务、调试和团队编程的访问。该平台实现了现有标准并提供
用于将功能部件和函数作为插件添加的扩展点。IBM 和独立软件供应商(ISV)正在
开发插入这个框架的工具。
WebSphere Studio Site Developer和WebSphere Studio Application
Developer是IBM合并和扩展WebSphere Studio Workbench而成的两个产品。这些产
品是计划中将要跨越所有电子商务开发角色的集成开发工具套件的一部分，从Web
开发者到Java开发者、到商务分析师、到设计师、到企业程序员。WebSphere
Studio开发工具系列将添加更多产品。
客户希望有开放标准、工具集成、更大的灵活性和结合到现有应用程序的能力
。这些还只是WebSphere Studio产品套件所交付的部分优点。
垂直和水平集成
传统上，软件供应商提供垂直工具，迫使客户自己做集成。WebSphere Studio
Workbench的目的是提供一个 IBM 和 ISV 都能容易地扩展的平台。供应商已经拥
有了该技术并在此基础上积极地构建工具。
在Workbench上构建的每个WebSphere Studio产品都将提供已集成的工具，使
您可以专注于构建应用程序而不必费力去集成工具。
开放标准
WebSphere Studio套件中的所有产品都是构建在开放标准上的，并且它们所生
成的代码也是与开放标准一致的。可以构建和部署满足Servlets 2.2、JavaServer
Pages(JSP)1.1和 Enterprise JavaBEAns(EJB)1.1规范的最新型的
(state-of-the-art)服务器端应用程序(在Site Developer产品中将不包含EJB开发
工具。)所有构建在WebSphere Studio Workbench上的产品，都包含
CVS(Concurrent Versions System)。
基于角色的开发
WebSphere Studio产品系列中的每个成员都是为特殊电子商务开发角色或某种
角色范围设计的。例如，Site Developer是为开发和管理整个网站的Web开发者设
计的。Application Developer包含Site Developer的所有功能并添加了对在业务
逻辑方面(包含 EJB)工作的程序员的支持。当IBM交付WebSphere Studio系列的未
来成员时，它将扩展其选项范围，将产品与用户的角色和需求相匹配。
在每个WebSphere Studio解决方案内部，面向任务的视图筛选出复杂性并只提
供与手边的任务相关的功能。用户根据此时正在开发或分析什么，或者根据他们在
项目中的角色切换视图。因为不同的开发者以不同的方法工作，所以视图可以定制
。因为他们使用WebSphere Studio Workbench技术构建，所以所有工具和视图共享
一个公共外观，这减小了学习难度并使得用户的生产力最大化。并且，因为项目的
开发资源存储在单个资源库中，所以您获得了对项目的最大共享性和一致团队支持
。
最大编程性能
除了将应用程序开发者们从工具集成任务中解放出来以外，Site Developer和
Application Developer 都以许多方法优化了程序员的生产力。(苏永)
开发利器3 微软.NET和C#
微软现在把自己的希望寄托在新的.NET应用程序框架之上。虽然在.NET中几乎
可以使用任何一种编程语言，但是开发者更热衷的还是微软的C#和C++。因为它们
改变了几乎所有从桌面软件到具有Web功能的企业解决方案的Windows开发规则,所
以这些技术的潜力非常巨大。
.NET框架和C#扩展了Windows的功能，C#和Visual Studio .NET的结合使得创
建和配置Web服务几乎可以自动进行。并且，和传统的ASP应用程序相比，ASP.NET
应用程在性能、稳定性以及可扩展性方面都有了实质性的提高。
虽然有很多优点，但是.NET价格不菲。目前的Windows开发者如果要转向.NET
框架，都必须进行再培训，并且所需费用很高。由于.NET框架中有很多重大的改变
以及复杂度的提高，因而现在的VB程序员将无法应对这些变化。C++程序员则会因
为C#继承了自己熟悉语言中的基本内容而感到高兴，但是他们也会发现在API以及
语言方面C#还是有很大的改变。
在ASP.NET中，由于不再使用VBScript，而只用JScript，并且在系统服务中也
不再提倡使用COM(Component Object Model)，因此要把现有的Web应用程序转换成
ASP.NET，重新编写程序代码要耗费大量的时间和精力。如果要把现有Java项目转
入到.NET框架中，即使你使用的是J#(微软的Java开发语言)，那么要完成一个项目
的迁移，至少也要花费几个月的时间。如果要把服务器从Unix平台迁移到
Windows,那么更是要求所有的IT职员都必须掌握一门新的技术。
考虑到以上因素，我们就很容易理解为什么.NET和C#会让人们既关注又担忧。
当然，对于已经在从事Windows平台下开发的公司和企业来说，不是接不接受.NET
的问题，而是什么时候接受的问题。目前普遍的观点认为，如果不及时实现向.
NET的迁移，那么将最终不堪忍受来自开发者、商业伙伴、应用程序提供商以及工
具提供商的压力。
当然，相对于来自Java、Unix和Linux拥护者的挑战来说，微软要把Windows下
的开发者吸引到.NET框架上来。在和Java和J2EE的竞争中，微软主要有两张牌可打
，即Visual Studio .NET和Web服务。测试版的Visual Studio .NET IDE(整合开发
环境)已经在开发人员中引起了不小的震动。相信在Web服务领域和Java竞争时，它
将成为微软的一把利器。(伊利贵)
开发利器4 钟情Delphi 6
Delphi 6 是当前 Windows 平台上全面支持最新 Web 服务的快速开发工具。
无论是企业级用户还是个人开发者，都能够利用Delphi 6 轻松、快捷地构建新一
代电子商务应用。Delphi 6优秀在何处？
高效的开发
Delphi 6是一个RAD(Rapid Application Development 快速开发工具)。它有
可视化的开发环境，当然具有类似功能的开发工具也不少(如Visual Basic)，但
Delphi 6有如下的独到之处：
Delphi 6是真正面向对象的。其构建的VCL库中的所有组件都可以被继承以创
建新的组件，包括窗体类TForm。相比之下，ActiveX组件缺乏这种灵活性。
Delphi 6的CodeInsight技术(即代码自动完成功能)是建立在编译器信息上的
，而VB使用的是类型库信息，使用编译器信息的好处是更具灵活性。不过，时常有
程序员抱怨Delphi 6的代码提示时间太长。
高效的编译
可以说，Delphi 6是Windows平台上最快的高级语言本地代码编译器了。编译
速度快有什么好处呢？快速的编译器可以让你频繁地在修改代码和编译运行的状态
间切换。至少，我自己已经非常习惯了这样的工作方式：运行程序看一下效果，退
出程序修改少量代码再运行程序。而Delphi 6的编译器从来不会让我有等待的感觉
。
高效的执行
Delphi 6与C++Builder使用的是同一个后端优化器，因此其生成代码的效率与
优秀的C++编译器生成代码效率相同。
Delphi 6生成完全本地代码，因此Delphi 6编译结果的可执行文件可以被独立
执行、分发(对于“绿色软件”的开发，这一点十分重要)。不需要其他运行库支持
。当然，你也可以选择动态链接编译，这样可以大大减小可执行文件的长度，不过
这种情况下在分发程序时，必须同时分发必要的运行库文件。
构建Windows/Linux 应用
Delphi 6 与Kylix兼容。使用Kylix，可在Linux平台上重新编译基于Windows
平台的CLX应用；而利用Delphi 6，即可在Windows上重新编译基于CLX组件的
Linux应用。Delphi 6包含BaseCLX、VisualCLX、DataCLX和NetCLX四个组件。
与AppServer集成
Delphi 6通过最新SIDL与AppServer连接。它为AppServer应用开发出高性能、
具有丰富GUI环境的客户端应用，通过Internet将AppServer的EJB功能作为遵循业
界标准的SOAP/XML Web服务发布到全球。(李争)
编后语
现在，各种开发工具的功能相互大量重复，一个大而全的工具几乎总是可以被
几个别的工具代替。工具的选择确实非常让人迷惑，但是，无论是开发人员还是管
理人员都应该意识到：工具只能起到协助的作用，严格的软件工程管理和开发人员
的技术水平才是软件开发成功的关键。成功开发加上有效的管理和市场运作，才能
构成一个完整的成功软件。
小资料
开发工具的对垒
软件开发人员没有人会不知道微软的.NET和Sun的J2EE。二者尽管所提供的方
法不同，但都具有许多非常优秀的特点。
二者的可移植性都非常好。.NET的核心只能工作在Windows环境下，但从理论
上讲可以支持多种语言开发?只要这些语言的子集已经定义好，并为他们建立了IL
编译器?。对于J2EE来说，只要遵循Java VM?规则?和一组平台需要的服务，就可以
在任何平台上工作。因为所有定义J2EE平台的规范，都已经向公众公布，所以，许
多供应商也提供兼容产品和开发环境。
.NET并不是一种精巧的标志，而是微软策略的重大转移，它将给其操作系统平
台带来更大的支持率。现在他们正努力把Java和开放资源自身所特有的语言逐步开
放，然后实现直接满足开发商的需要。Java清除了平台的障碍。但是为了用J2EE来
做开发工作，用户必须在Java环境下工作。而.Net是想让用户使用自己选择的语言
来建造.NET应用程序，这是十分美妙的。
对于微软的开发商，.NET是一个好的构架，用户可以将许多事情交给微软的体
系结构去完成。ASP.NET比ASP好，ADO.NET比ADO和DCOM出色，C＃比C和C＋＋更好
。所以，如果现在正在微软的开发构架中从事开发工作，将.NET的元件采纳到你的
体系结构中，显然是一个明智的选择。不过，虽然.NET平台描绘了美好的蓝图，但
其设想要全部成为现实，还有较长的路要走。例如IL公共语言的运行，目前还有某
些明显的障碍需要克服。想要把每一种语言和元件运行时集成起来，必须定义这种
语言的子集/超集，并清晰地影射到IL上；此外必须定义结构，以便提供IL需要的
元数据；还有必须要开发适用于两种编译语言结构的编译器，集成到IL部件字节代
码中；同时还要生成对现有IL元件的语言专用接口。
由于历史的原因，在Java语言中使用非Java语言，必须要开发非Java语言到
JavaVM的众多转换器。因此，在Java环境中写代码，就必须要承受将额外的翻译工
作加到目标构架上。如果Java环境是目标，人们通常会选择学习Java。而如果目标
环境是.NET，那么人们将会选择学习C＃。(伊利贵)
64位的软件开发
因为在内存容量、I/O处理效率等方面64位系统有着32位系统无可比拟的优势
，因此在高端应用上，Sun、IBM和HP等大腕一直热衷于64位系统。可以预见，在不
久的将来，Intel的64位处理器将成为Sparc的主要竞争对手。
不过，由于Linux和Windows环境下的主要的应用程序都是32位的，因此，软件
厂商和自由软件项目必须为64位系统重写他们的应用程序。所幸的是，由于Java的
盛行以及.NET的出现，这将使得应用程序向Itanium的移植变得非常神速。IBM已经
推出了其用于Itanium的Java SDK(软件开发工具包)，此外，微软的.NET框架在其
发行.NET Server时，也将登陆Itanium。而Borland更是已经使其Java开发工具和
服务器可以在Itanium上运行。(伊利贵)
