软件开发工具选择

我国的软件开发已经逐步从原来的手工作坊式发展到了软件工程的阶段。同时，软件开发本身也在不断发展，已从“算法＋数据结构＝程序”逐步发展到了“设计模式＋对象组件＋开发工具＝程序”。开发工具的选择，已经成为软件开发成功的要素之一。
开发工具的选择主要决定于两个因素：所开发系统的最终用户和开发人员。最终用
户需求是一切软件的来源和归宿，也是影响开发工具的决定性因素；开发人员的爱好、习惯、经验也影响着开发工具的选择。严格的软件工程管理和开发人员的技术水平是软件开发成功的关键。
本文介绍一些选择软件开发工具的思路，重点强调在满足客户群体的情况下，软件
工具服务于软件工程思想的重要性。
开发工具争显锋芒
首先需要强调的是：开发工具的比较没有绝对的标准。评价一种开发工具，不仅要
看它对设计模式、对象结构以及管理的支撑情况，更重要的是要针对具体的使用环境、开发方法、结构体系、开发群体以及使用群体来评价一种工具的适宜程度。
现有的开发工具大概分为大而全和小而专两种类型。Microsoft的VisualStudio系
列和IBM的VisualAge系列应该属于前者；其他很多工具，像
Delphi/C++Builder/JBuilder大而全的工具一般都提供从前端到后台，从设计到编码测试的完整工具，但在一些
特定的功能上，它们不如小而专的工具。
VisualStudio.NET的UML开发工具(VisualModeler/Visio)一般只能和Rational
Suite中RationalRose的LogicalView相比，它不可能有完整的RationalUnifiedProcess流程；其可视化的VisualBasic没有办法和Delphi/C++Builder在速度和功能上相比。
虽然VisualStudio.NET的各个部分都有不足，但其Visio工具能够更快、更方便
地和编程语言整合在一起。VisualBasic在和Office等工具整合时遇到的问题(数据类型转化等)比Delphi/C++Builder要少得多。所以，工具类型和具体的情况决定了特定条件下软件开发工具最优的选择。
欲善其事先利其器
开发工具的选择主要决定于两个因素：所开发系统的最终用户和开发人员。最终用
户需求是一切软件的来源和归宿，也是影响开发工具的决定性因素；开发人员的爱好、习惯、经验也影响着开发工具的选择。
最终用户的需求
程序的最终使用群体是软件开发的服务对象，也影响着开发工具的选择。从计算机
使用的程度分，最终的使用者可以分为IT人员、各行业的专业人员以及普通用户。使用者的不同，对于软件的需求就不会相同。IT人员自然需要更多的功能、更自由的定制/二次开发空间；行业用户往往需要一个整体的解决方案，从而提升其整体竞争力；普通用户显然要求更方便简单地使用。用户的需求分别在自由度、涵盖度、针对性、方便性等维度展开。
扩展软件自由度
为了扩展软件的自由度，较少的封装和充分的功能暴露是必然的。为了让用户自由
使用Windows的功能，自由访问操作系统和硬件资源的语言C++或者Assembler应该是最好的选择。VisualC++成为Microsoft对其操作系统功能的“权威”封装，至今在Windows系统级开发中占据主流地位；C++Builder扩充的标准的C++语法，提供了RAD(RapidApplicationDevelopment)的支持，但是它的VCL(VisualComponentLibrary)大部分是用Delphi写的，不像VisualC++的MFC/ATL类库的纯C++源代码，对于C++程序员的深入编程不利。最近开放源代码(OpenSource)运动风靡全球，开放源代码的C++工具中，GCC受到了普遍的采用。它不仅可以在各种流行操作系统(Windows、Linux、Solaris、HP-Unix)上运行，而且支持ObjectC、C++的各种扩充语法，甚至可以编译Java代码。
涵盖度各取所求
关于涵盖度的要求，不同的系统也是不尽相同的：有的可能要求涵盖前端、中间件、
后台、数据库，也有可能要求涵盖各种操作系统和硬件平台。VisualStudio.NET和IBM的电子商务平台都能够提供从客户端、中间件到数据库的整体开发支持。
VisualStudio.NET甚至将可视化带到了Web客户端，通过拖放完成Web页面以
后，可以双点到后台处理程序的框架代码中。从软件工程的思想看来，VisualStudio.NET给程序员提供了强大而且方便的功能，但是并没有明确的支持需求分析的流程。IBM的VisualAge系列在这个方面做得不错，VisualAgeUMLDesigner支持从需求分析到设计、编码的相对完整过程(不过，在代码生成方面仅仅对Java和Smalltalk的支持比较好)。
VisualStudio.NET采用COM+作为组件模型，其生成的Web客户端对于平台没
有限制。不过，虽然.NET框架应该可以移植到非Windows平台上运行，但是其中间件和服务端还没有看到在Unix或者MacOS上的成功案例。IBMVisualAge+WebSphere+DB2系列大量采用JavaBEAn/J2EE作为组件模型，由于Java的平台无关性，客户端和中间件的跨平台性就比较好。/Kylix、PowerBuilder/PowerJ，还有大量的各种SDK等都具有各自的特点，属于小而专的类型。当然，用小而专的工具组合起来也能完成这些工作，RationalSuite可以完成从业
务建模、系统建模、模块建模以及发布测试的完整过程，Delphi/C++Builder可以利用CORBA或者COM+作为中间件，JBuilder6更是可以采用Visibroker或者orbix等各种CORBA产品或者WebSphere、iPlanet、BAS、WebLogic等各种J2EE产品。但是，如果不明白Rational中UML和代码映射的方法以及C++Builder/Delphi/JBuilder对于代码的管理方式，要让建模和编码配合起来，就需要在RationalRose中设置ClassPath以及在Borland工具中设置源代码目录。其中的过程和可能出现的问题都很多，而在VisualStudio.NET中，这些工作仅仅是点几下鼠标的事情。
也有像Ensemble这样的公司，专门集成小而专的工具，但是这些软件的成熟度以
及学习和掌握也是问题。当然，在局部涵盖性上，Delphi使用CLX的程序可以在Kylix上编译，从而在Linux上运行；RainingDataCorporation的OmnisStudio3.1甚至直接支持跨越Windows和Linux平台的RAD开发。
针对性各有特色
在针对性上，各个工具都具备各自的优势。在单机应用上，VisualFoxPro具有全
球最快的数据访问引擎。而PowerBuilder在开发两层数据库应用上，特别是用数据窗口和Sybase数据库后台挂接，用PowerDesign建模，不仅开发速度快，而且效率和稳定性也比较好。在三层应用上，使用VisualBasic/C++/C#+ADO，如果再使用SQLServer，就在性能、开发效率、稳定性上都有保证；而使用C++Builder/Delphi+DataSnap(MIDAS)，在挂接非微软数据库，或者需要和CORBA程序交互时都具有优势。
对于多层分布式应用，COM+规范和CORBA产品(orbix,visibroker等)往往决定了
开发工具的选择。COM+的开发工具一般采用VisualStudio.NET或Borland的产品，而由于CORBA的编程语言和系统平台的无关性，各种开发平台一般都可以。另外，针对C/C++编程，DSET公司的DSG在高端应用(一般在电信领域)中，它在与网络协议栈的无关性、同/异步消息处理、海量通信能力、嵌入式到大型机的移植性等方面,具有独特的优势。在服务器端开发上，COM+、CORBA3.0、J2EE都支持组件模型，分别利用MSMQ、CORBAMessagingSystem、JMS完成异步通信。COM+仍然主要集中在Windows平台上，CORBA3.0的Java语言部分包含整个J2EE规范。但是，CORBA作为一个跨语言跨平台的规范，现在支持3.0版本非Java语言的产品还不多，支持其核心——CCM(CORBAComponentModel)的C++编程的产品有iCMG公司K2-CCM等。
J2EE的组件(EJB)已经发展到了1.2版本。满足该规范的产品——BEAWebLogic、
BorlandBAS、IBMWebSphere、Oracle9i甚至免费的JBOSS都得到了广泛的应用。BEAWebLogic7.0在前端开发工具上做了大量的工作，声称将J2EE开发和VisualBasic放在同一个级别上(其内部名字就是VisualBasicforJava)。
微软方便性最好
在方便性上，由于有大量用户的实践，微软的开发工具应该是最好的。它在可视化、
工具间互操作性、稳定性、文档的丰富性上都具有明显的优势。BorlandDelphi/C++Builder在可视化上和VisualBasic/C#基本上类似，但是他们在稳定性上不足(C++Builder5.0自动生成的CORBA程序的debug版会报错(Exception))；IBMVisualAge系列的稳定性不错，但是它们的可视化编程不是非常方便；在文档方面，更是没有一种工具具有VisualStudio自带的MSDN那样的容量(两张光盘)。
开发者的偏爱
开发工具是给开发者用的，开发人员是这些工具的用户。不同的开发人员对工具的
偏爱也不同。Pascal程序员一般都会钟爱Delphi/Kylix；Windows的C++程序员则会选择C++Builder或者VisualC++；在不同平台下C++编程的人员可能会更加喜欢GCC；Smalltalk