发信人: oldman (老人), 信区: Npsos
标  题: 谈软件开发工具的选择[转贴]
发信站: BBS 哈工大紫丁香站 (Mon May 31 08:27:14 2004)

　　我国的软件开发已经逐步从原来的手工作坊式发展到了软件工程的阶段。同时，软件
开发本身也在不断发展，已从“算法＋数据结构＝程序”逐步发展到了“设计模式＋对象
组件＋开发工具＝程序”。开发工具的选择，已经成为软件开发成功的要素之一。
　　开发工具的选择主要决定于两个因素：所开发系统的最终用户和开发人员。最终用户
需求是一切软件的来源和归宿，也是影响开发工具的决定性因素；开发人员的爱好、习惯
、 
经验也影响着开发工具的选择。严格的软件工程管理和开发人员的技术水平是软件开发成
功的关键。
　　本文介绍一些选择软件开发工具的思路，重点强调在满足客户群体的情况下，软件工
具服务于软件工程思想的重要性。
开发工具 争显锋芒
　　首先需要强调的是：开发工具的比较没有绝对的标准。评价一种开发工具，不仅要看
它对设计模式、对象结构以及管理的支撑情况，更重要的是要针对具体的使用环境、开发
方法、结构体系、开发群体以及使用群体来评价一种工具的适宜程度。
　　现有的开发工具大概分为大而全和小而专两种类型。Microsoft的Visual Studio系列
和IBM的Visual Age系列应该属于前者；其他很多工具，像Delphi/C++Builder/JBuilder/
Kylix、PowerBuilder/PowerJ，还有大量的各种SDK等都具有各自的特点，属于小而专的类
型。
　　大而全的工具一般都提供从前端到后台，从设计到编码测试的完整工具，但在一些特
定的功能上，它们不如小而专的工具。
　　Visual Studio.NET的UML开发工具(Visual Modeler/Visio)一般只能和Rational Sui
te中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 Applicatio
n 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系列大量采用JavaB
EAn/J2EE作为组件模型，由于Java的平台无关性，客户端和中间件的跨平台性就比较好。

　　当然，用小而专的工具组合起来也能完成这些工作，Rational Suite可以完成从业务
建模、系统建模、模块建模以及发布测试的完整过程，Delphi/C++Builder可以利用CORBA
或者COM+作为中间件，JBuilder 6更是可以采用Visibroker或者orbix等各种CORBA产品或
者WebSphere、iPlanet、BAS、WebLogic等各种J2EE产品。但是，如果不明白Rational中U
ML和代码映射的方法以及C++Builder/Delphi/ JBuilder对于代码的管理方式，要让建模和
编码配合起来，就需要在Rational Rose中设置ClassPath以及在Borland工具中设置源代码
目录。其中的过程和可能出现的问题都很多，而在Visual Studio.NET中，这些工作仅仅是
点几下鼠标的事情。
　　也有像Ensemble这样的公司，专门集成小而专的工具，但是这些软件的成熟度以及学
习和掌握也是问题。当然，在局部涵盖性上，Delphi使用CLX的程序可以在Kylix上编译，
从而在Linux上运行；Raining Data Corporation的Omnis Studio 3.1甚至直接支持跨越W
indows和Linux平台的RAD开发。
针对性各有特色
　　在针对性上，各个工具都具备各自的优势。在单机应用上，Visual FoxPro具有全球最
快的数据访问引擎。而PowerBuilder在开发两层数据库应用上，特别是用数据窗口和Syba
se数据库后台挂接，用PowerDesign建模，不仅开发速度快，而且效率和稳定性也比较好。
在三层应用上，使用Visual Basic/C++/C#+ADO，如果再使用SQL Server，就在性能、开发
效率、稳定性上都有保证；而使用C++Builder/Delphi+DataSnap(MIDAS)，在挂接非微软数
据库，或者需要和CORBA程序交互时都具有优势。
　　对于多层分布式应用，COM+规范和CORBA产品(orbix, visibroker等)往往决定了开发
工具的选择。COM+的开发工具一般采用Visual Studio.NET或Borland的产品，而由于CORB
A的编程语言和系统平台的无关性，各种开发平台一般都可以。另外，针对C/C++编程，DS
ET公司的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公司K
2-CCM等。
　　J2EE的组件(EJB)已经发展到了1.2版本。满足该规范的产品——BEA WebLogic、Borl
and BAS、 IBM WebSphere、Oracle 9i甚至免费的JBOSS都得到了广泛的应用。BEA WebLo
gic 7.0在前端开发工具上做了大量的工作，声称将J2EE开发和Visual Basic放在同一个级
别上(其内部名字就是Visual Basic for Java)。
微软方便性最好
　　在方便性上，由于有大量用户的实践，微软的开发工具应该是最好的。它在可视化、
工具间互操作性、稳定性、文档的丰富性上都具有明显的优势。Borland Delphi/C++Buil
der在可视化上和Visual Basic/C#基本上类似，但是他们在稳定性上不足(C++Builder 5.
0自动生成的CORBA程序的debug版会报错(Exception))；IBM Visual Age系列的稳定性不错
，但是它们的可视化编程不是非常方便；在文档方面，更是没有一种工具具有Visual Stu
dio自带的MSDN那样的容量(两张光盘)。
开发者的偏爱
　　开发工具是给开发者用的，开发人员是这些工具的用户。不同的开发人员对工具的偏
爱也不同。Pascal程序员一般都会钟爱Delphi/Kylix；Windows的C++程序员则会选择C++B
uilder或者Visual C++；在不同平台下C++编程的人员可能会更加喜欢GCC；Smalltalk程序
员恐怕就只会考虑Visual Age Smalltalk；而Turbo Lisp、Visual Fortran、Perl Build
er等开发工具在其他各种编程语言的程序员中也被大量采用。
　　现在，各种编程语言的功能互相融合，像Borland Delphi和C++Builder之间的功能差
异，在语言上表现得已经非常少了。除了编程语言的偏爱以外，不同操作系统的程序员使
用的工具也不同：Solaris系统下的程序员更多地使用CC编写C++/C的后台程序，用Perl编
写框架或者测试脚本，用TCL/TK编写界面程序；虽然Windows下也有这些工具，但是更多程
序员恐怕还是会选择支持RAD的工具。现在，人们普遍认可一种趋势：操作系统、编程语言
在开发上的差异正在迅速消失。XML有效地解决了在不同系统下统一数据表达的问题；通过
虚拟机，Java程序能够在不同操作系统下执行；微软的.NET框架能够利用C++/Basic/C#来
编程。
　　平台和语言间的交互使得各种工具对于通用标准的支持越来越重视。Sun新推出的Jav
a的XML开发包，明确支持由微软和IBM提出的SOAP规范，Visual Studio.NET也明确支持Ja
va语言(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、应用服务器E
AServer(内含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也有一个PF
C与之对应。当然，两者的层次是不同的。MFC提供了底层的封装，而PFC提供了数据库应用
的更高层面的封装。对PFC的深入应用可以大大提高系统的开发效率和开发质量。进入到3
-tier的世界，如果用PB来开发Component，同样也有一些很好的类库，比较著名的就是EA
F。对这些类库的深入应用并形成自己的类库，是迅速提高产品和项目的质量和效率捷径。

　　确保应用软件的质量一定是许多人都很头疼的问题。那我们就先来看看最基本的问题
吧。在单元测试这个领域，大家一定了解在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是I
BM合并和扩展WebSphere Studio Workbench而成的两个产品。这些产品是计划中将要跨越
所有电子商务开发角色的集成开发工具套件的一部分，从Web开发者到Java开发者、到商务
分析师、到设计师、到企业程序员。WebSphere Studio开发工具系列将添加更多产品。
　　客户希望有开放标准、工具集成、更大的灵活性和结合到现有应用程序的能力。这些
还只是WebSphere Studio产品套件所交付的部分优点。
垂直和水平集成
　　传统上，软件供应商提供垂直工具，迫使客户自己做集成。WebSphere Studio Workb
ench的目的是提供一个 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 Work
bench上的产品，都包含CVS(Concurrent Versions System)。
基于角色的开发
　　WebSphere Studio产品系列中的每个成员都是为特殊电子商务开发角色或某种角色范
围设计的。例如，Site Developer是为开发和管理整个网站的Web开发者设计的。Applica
tion Developer包含Site Developer的所有功能并添加了对在业务逻辑方面(包含 EJB)工
作的程序员的支持。当IBM交付WebSphere Studio系列的未来成员时，它将扩展其选项范围
，将产品与用户的角色和需求相匹配。
　　在每个WebSphere Studio解决方案内部，面向任务的视图筛选出复杂性并只提供与手
边的任务相关的功能。用户根据此时正在开发或分析什么，或者根据他们在项目中的角色
切换视图。因为不同的开发者以不同的方法工作，所以视图可以定制。因为他们使用WebS
phere Studio Workbench技术构建，所以所有工具和视图共享一个公共外观，这减小了学
习难度并使得用户的生产力最大化。并且，因为项目的开发资源存储在单个资源库中，所
以您获得了对项目的最大共享性和一致团队支持。
最大编程性能
　　除了将应用程序开发者们从工具集成任务中解放出来以外，Site Developer和Applic
ation 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和We
b服务。测试版的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使
用的是类型库信息，使用编译器信息的好处是更具灵活性。不过，时常有程序员抱怨Delp
hi 6的代码提示时间太长。
高效的编译
　　可以说，Delphi 6是Windows平台上最快的高级语言本地代码编译器了。编译速度快有
什么好处呢？快速的编译器可以让你频繁地在修改代码和编译运行的状态间切换。至少，
我自己已经非常习惯了这样的工作方式：运行程序看一下效果，退出程序修改少量代码再
运行程序。而Delphi 6的编译器从来不会让我有等待的感觉。
高效的执行
　　Delphi 6与C++Builder使用的是同一个后端优化器，因此其生成代码的效率与优秀的
C++编译器生成代码效率相同。
　　Delphi 6生成完全本地代码，因此Delphi 6编译结果的可执行文件可以被独立执行、
分发(对于“绿色软件”的开发，这一点十分重要)。不需要其他运行库支持。当然，你也
可以选择动态链接编译，这样可以大大减小可执行文件的长度，不过这种情况下在分发程
序时，必须同时分发必要的运行库文件。
构建Windows/Linux 应用
　　Delphi 6 与Kylix兼容。使用Kylix，可在Linux平台上重新编译基于Windows平台的C
LX应用；而利用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编译器?。对于J2
EE来说，只要遵循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位系统。可以预见，在不久的将来，Inte
l的64位处理器将成为Sparc的主要竞争对手。
　　不过，由于Linux和Windows环境下的主要的应用程序都是32位的，因此，软件厂商和
自由软件项目必须为64位系统重写他们的应用程序。所幸的是，由于Java的盛行以及.NET
的出现，这将使得应用程序向Itanium的移植变得非常神速。IBM已经推出了其用于Itaniu
m的Java SDK(软件开发工具包)，此外，微软的.NET框架在其发行.NET Server时，也将登
陆Itanium。而Borland更是已经使其Java开发工具和服务器可以在Itanium上运行。
--

※ 来源:·哈工大紫丁香 http://bbs.hit.edu.cn·[FROM: 202.118.232.7]