我国的软件开发已经逐步从原来的手工作坊式发展到了软件工程的阶段。同时，软件开发本身也在不断发展，已从“算法＋数据结构＝程序”逐步发展到了“设计模式＋对象组件＋开发工具＝程序”。开发工具的选择，已经成为软件开发成功的要素之一。
开发工具的选择主要决定于两个因素：所开发系统的最终用户和开发人员。最终用户需求是一切软件的来源和归宿，也是影响开发工具的决定性因素；开发人员的爱好、习惯、
经验也影响着开发工具的选择。严格的软件工程管理和开发人员的技术水平是软件开发成功的关键。
本文介绍一些选择软件开发工具的思路，重点强调在满足客户群体的情况下，软件工具服务于软件工程思想的重要性。
开发工具 争显锋芒
首先需要强调的是：开发工具的比较没有绝对的标准。评价一种开发工具，不仅要看它对设计模式、对象结构以及管理的支撑情况，更重要的是要针对具体的使用环境、开发方法、结构体系、开发群体以及使用群体来评价一种工具的适宜程度。
现有的开发工具大概分为大而全和小而专两种类型。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。对这些类库的深入应用并形成自己的类库，是迅速提高产品和项目的质量和效率捷径。[本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
