我國(guó)的軟件開發(fā)已經(jīng)逐步從原來的手工作坊式發(fā)展到了軟件工程的階段。同時(shí)，軟件開發(fā)本身也在不斷發(fā)展，已從“算法＋數(shù)據(jù)結(jié)構(gòu)＝程序”逐步發(fā)展到了“設(shè)計(jì)模式＋對(duì)象組件＋開發(fā)工具＝程序”。開發(fā)工具的選擇，已經(jīng)成為軟件開發(fā)成功的要素之一。

開發(fā)工具的選擇主要決定于兩個(gè)因素：所開發(fā)系統(tǒng)的最終用戶和開發(fā)人員。最終用戶需求是一切軟件的來源和歸宿，也是影響開發(fā)工具的決定性因素；開發(fā)人員的愛好、習(xí)慣、經(jīng)驗(yàn)也影響著開發(fā)工具的選擇。嚴(yán)格的軟件工程管理和開發(fā)人員的技術(shù)水平是軟件開發(fā)成功的關(guān)鍵。

本文介紹一些選擇軟件開發(fā)工具的思路，重點(diǎn)強(qiáng)調(diào)在滿足客戶群體的情況下，軟件工具服務(wù)于軟件工程思想的重要性。

開發(fā)工具 爭(zhēng)顯鋒芒
　　
首先需要強(qiáng)調(diào)的是：開發(fā)工具的比較沒有絕對(duì)的標(biāo)準(zhǔn)。評(píng)價(jià)一種開發(fā)工具，不僅要看它對(duì)設(shè)計(jì)模式、對(duì)象結(jié)構(gòu)以及管理的支撐情況，更重要的是要針對(duì)具體的使用環(huán)境、開發(fā)方法、結(jié)構(gòu)體系、開發(fā)群體以及使用群體來評(píng)價(jià)一種工具的適宜程度。
　　
現(xiàn)有的開發(fā)工具大概分為大而全和小而專兩種類型。Microsoft的Visual Studio系列和IBM的Visual Age系列應(yīng)該屬于前者；其他很多工具，像Delphi/C++Builder/JBuilder/Kylix、PowerBuilder/PowerJ，還有大量的各種SDK等都具有各自的特點(diǎn)，屬于小而專的類型。
　　
大而全的工具一般都提供從前端到后臺(tái)，從設(shè)計(jì)到編碼測(cè)試的完整工具，但在一些特定的功能上，它們不如小而專的工具。
　　
Visual Studio.NET的UML開發(fā)工具(Visual Modeler/Visio)一般只能和Rational Suite中Rational Rose的Logical View相比，它不可能有完整的Rational Unified Process流程；其可視化的Visual Basic沒有辦法和Delphi/C++Builder在速度和功能上相比。
　　
雖然Visual Studio.NET的各個(gè)部分都有不足，但其Visio工具能夠更快、更方便地和編程語(yǔ)言整合在一起。Visual Basic在和Office等工具整合時(shí)遇到的問題(數(shù)據(jù)類型轉(zhuǎn)化等)比Delphi/C++Builder要少得多。所以，工具類型和具體的情況決定了特定條件下軟件開發(fā)工具最優(yōu)的選擇。

欲善其事 先利其器
　　
開發(fā)工具的選擇主要決定于兩個(gè)因素：所開發(fā)系統(tǒng)的最終用戶和開發(fā)人員。最終用戶需求是一切軟件的來源和歸宿，也是影響開發(fā)工具的決定性因素；開發(fā)人員的愛好、習(xí)慣、經(jīng)驗(yàn)也影響著開發(fā)工具的選擇。

最終用戶的需求
　　
程序的最終使用群體是軟件開發(fā)的服務(wù)對(duì)象，也影響著開發(fā)工具的選擇。從計(jì)算機(jī)使用的程度分，最終的使用者可以分為IT人員、各行業(yè)的專業(yè)人員以及普通用戶。使用者的不同，對(duì)于軟件的需求就不會(huì)相同。IT人員自然需要更多的功能、更自由的定制/二次開發(fā)空間；行業(yè)用戶往往需要一個(gè)整體的解決方案，從而提升其整體競(jìng)爭(zhēng)力；普通用戶顯然要求更方便簡(jiǎn)單地使用。用戶的需求分別在自由度、涵蓋度、針對(duì)性、方便性等維度展開。

擴(kuò)展軟件自由度
　　
為了擴(kuò)展軟件的自由度，較少的封裝和充分的功能暴露是必然的。為了讓用戶自由使用Windows的功能，自由訪問操作系統(tǒng)和硬件資源的語(yǔ)言C++或者Assembler應(yīng)該是最好的選擇。Visual C++成為Microsoft對(duì)其操作系統(tǒng)功能的“權(quán)威”封裝，至今在Windows系統(tǒng)級(jí)開發(fā)中占據(jù)主流地位；C++ Builder擴(kuò)充的標(biāo)準(zhǔn)的C++語(yǔ)法，提供了RAD(Rapid Application Development)的支持，但是它的VCL(Visual Component Library)大部分是用Delphi寫的，不像Visual C++的MFC/ATL類庫(kù)的純C++源代碼，對(duì)于C++程序員的深入編程不利。最近開放源代碼(Open Source)運(yùn)動(dòng)風(fēng)靡全球，開放源代碼的C++工具中，GCC受到了普遍的采用。它不僅可以在各種流行操作系統(tǒng)(Windows、Linux、Solaris、HP-Unix)上運(yùn)行，而且支持Object C、C++的各種擴(kuò)充語(yǔ)法，甚至可以編譯Java代碼。

涵蓋度各取所求
　　
關(guān)于涵蓋度的要求，不同的系統(tǒng)也是不盡相同的：有的可能要求涵蓋前端、中間件、后臺(tái)、數(shù)據(jù)庫(kù)，也有可能要求涵蓋各種操作系統(tǒng)和硬件平臺(tái)。Visual Studio .NET和IBM的電子商務(wù)平臺(tái)都能夠提供從客戶端、中間件到數(shù)據(jù)庫(kù)的整體開發(fā)支持。
　　
Visual Studio.NET甚至將可視化帶到了Web客戶端，通過拖放完成Web頁(yè)面以后，可以雙點(diǎn)到后臺(tái)處理程序的框架代碼中。從軟件工程的思想看來，Visual Studio.NET給程序員提供了強(qiáng)大而且方便的功能，但是并沒有明確的支持需求分析的流程。IBM的Visual Age系列在這個(gè)方面做得不錯(cuò)，Visual Age UML Designer支持從需求分析到設(shè)計(jì)、編碼的相對(duì)完整過程(不過，在代碼生成方面僅僅對(duì)Java和Smalltalk的支持比較好)。
　　
Visual Studio.NET采用COM+作為組件模型，其生成的Web客戶端對(duì)于平臺(tái)沒有限制。不過，雖然.NET框架應(yīng)該可以移植到非Windows平臺(tái)上運(yùn)行，但是其中間件和服務(wù)端還沒有看到在Unix或者M(jìn)ac OS上的成功案例。IBM VisualAge+WebSphere+DB2系列大量采用JavaBEAn/J2EE作為組件模型，由于Java的平臺(tái)無(wú)關(guān)性，客戶端和中間件的跨平臺(tái)性就比較好。
　　
當(dāng)然，用小而專的工具組合起來也能完成這些工作，Rational Suite可以完成從業(yè)務(wù)建模、系統(tǒng)建模、模塊建模以及發(fā)布測(cè)試的完整過程，Delphi/C++Builder可以利用CORBA或者COM+作為中間件，JBuilder 6更是可以采用Visibroker或者orbix等各種CORBA產(chǎn)品或者WebSphere、iPlanet、BAS、WebLogic等各種J2EE產(chǎn)品。但是，如果不明白R(shí)ational中UML和代碼映射的方法以及C++Builder/Delphi/ JBuilder對(duì)于代碼的管理方式，要讓建模和編碼配合起來，就需要在Rational Rose中設(shè)置ClassPath以及在Borland工具中設(shè)置源代碼目錄。其中的過程和可能出現(xiàn)的問題都很多，而在Visual Studio.NET中，這些工作僅僅是點(diǎn)幾下鼠標(biāo)的事情。
　　
也有像Ensemble這樣的公司，專門集成小而專的工具，但是這些軟件的成熟度以及學(xué)習(xí)和掌握也是問題。當(dāng)然，在局部涵蓋性上，Delphi使用CLX的程序可以在Kylix上編譯，從而在Linux上運(yùn)行；Raining Data Corporation的Omnis Studio 3.1甚至直接支持跨越Windows和Linux平臺(tái)的RAD開發(fā)。

針對(duì)性各有特色
　　
在針對(duì)性上，各個(gè)工具都具備各自的優(yōu)勢(shì)。在單機(jī)應(yīng)用上，Visual FoxPro具有全球最快的數(shù)據(jù)訪問引擎。而PowerBuilder在開發(fā)兩層數(shù)據(jù)庫(kù)應(yīng)用上，特別是用數(shù)據(jù)窗口和Sybase數(shù)據(jù)庫(kù)后臺(tái)掛接，用PowerDesign建模，不僅開發(fā)速度快，而且效率和穩(wěn)定性也比較好。在三層應(yīng)用上，使用Visual Basic/C++/C#+ADO，如果再使用SQL Server，就在性能、開發(fā)效率、穩(wěn)定性上都有保證；而使用C++Builder/Delphi+DataSnap(MIDAS)，在掛接非微軟數(shù)據(jù)庫(kù)，或者需要和CORBA程序交互時(shí)都具有優(yōu)勢(shì)。
　　
對(duì)于多層分布式應(yīng)用，COM+規(guī)范和CORBA產(chǎn)品(orbix, visibroker等)往往決定了開發(fā)工具的選擇。COM+的開發(fā)工具一般采用Visual Studio.NET或Borland的產(chǎn)品，而由于CORBA的編程語(yǔ)言和系統(tǒng)平臺(tái)的無(wú)關(guān)性，各種開發(fā)平臺(tái)一般都可以。另外，針對(duì)C/C++編程，DSET公司的DSG在高端應(yīng)用(一般在電信領(lǐng)域)中，它在與網(wǎng)絡(luò)協(xié)議棧的無(wú)關(guān)性、同/異步消息處理、海量通信能力、嵌入式到大型機(jī)的移植性等方面,具有獨(dú)特的優(yōu)勢(shì)。在服務(wù)器端開發(fā)上，COM+、CORBA 3.0、J2EE都支持組件模型，分別利用MSMQ、CORBA Messaging System、JMS完成異步通信。COM+仍然主要集中在Windows平臺(tái)上，CORBA 3.0的Java語(yǔ)言部分包含整個(gè)J2EE規(guī)范。但是，CORBA作為一個(gè)跨語(yǔ)言跨平臺(tái)的規(guī)范，現(xiàn)在支持3.0版本非Java語(yǔ)言的產(chǎn)品還不多，支持其核心——CCM(CORBA Component Model)的C++編程的產(chǎn)品有iCMG公司K2-CCM等。
　　
J2EE的組件(EJB)已經(jīng)發(fā)展到了1.2版本。滿足該規(guī)范的產(chǎn)品——BEA WebLogic、Borland BAS、 IBM WebSphere、Oracle 9i甚至免費(fèi)的JBOSS都得到了廣泛的應(yīng)用。BEA WebLogic 7.0在前端開發(fā)工具上做了大量的工作，聲稱將J2EE開發(fā)和Visual Basic放在同一個(gè)級(jí)別上(其內(nèi)部名字就是Visual Basic for Java)。

微軟方便性最好
　　
在方便性上，由于有大量用戶的實(shí)踐，微軟的開發(fā)工具應(yīng)該是最好的。它在可視化、工具間互操作性、穩(wěn)定性、文檔的豐富性上都具有明顯的優(yōu)勢(shì)。Borland Delphi/C++Builder在可視化上和Visual Basic/C#基本上類似，但是他們?cè)诜€(wěn)定性上不足(C++Builder 5.0自動(dòng)生成的CORBA程序的debug版會(huì)報(bào)錯(cuò)(Exception))；IBM Visual Age系列的穩(wěn)定性不錯(cuò)，但是它們的可視化編程不是非常方便；在文檔方面，更是沒有一種工具具有Visual Studio自帶的MSDN那樣的容量(兩張光盤)。

開發(fā)者的偏愛
　　
開發(fā)工具是給開發(fā)者用的，開發(fā)人員是這些工具的用戶。不同的開發(fā)人員對(duì)工具的偏愛也不同。Pascal程序員一般都會(huì)鐘愛Delphi/Kylix；Windows的C++程序員則會(huì)選擇C++Builder或者Visual C++；在不同平臺(tái)下C++編程的人員可能會(huì)更加喜歡GCC；Smalltalk程序員恐怕就只會(huì)考慮Visual Age Smalltalk；而Turbo Lisp、Visual Fortran、Perl Builder等開發(fā)工具在其他各種編程語(yǔ)言的程序員中也被大量采用。
　　
現(xiàn)在，各種編程語(yǔ)言的功能互相融合，像Borland Delphi和C++Builder之間的功能差異，在語(yǔ)言上表現(xiàn)得已經(jīng)非常少了。除了編程語(yǔ)言的偏愛以外，不同操作系統(tǒng)的程序員使用的工具也不同：Solaris系統(tǒng)下的程序員更多地使用CC編寫C++/C的后臺(tái)程序，用Perl編寫框架或者測(cè)試腳本，用TCL/TK編寫界面程序；雖然Windows下也有這些工具，但是更多程序員恐怕還是會(huì)選擇支持RAD的工具?，F(xiàn)在，人們普遍認(rèn)可一種趨勢(shì)：操作系統(tǒng)、編程語(yǔ)言在開發(fā)上的差異正在迅速消失。XML有效地解決了在不同系統(tǒng)下統(tǒng)一數(shù)據(jù)表達(dá)的問題；通過虛擬機(jī)，Java程序能夠在不同操作系統(tǒng)下執(zhí)行；微軟的.NET框架能夠利用C++/Basic/C#來編程。
　　
平臺(tái)和語(yǔ)言間的交互使得各種工具對(duì)于通用標(biāo)準(zhǔn)的支持越來越重視。Sun新推出的Java的XML開發(fā)包，明確支持由微軟和IBM提出的SOAP規(guī)范，Visual Studio.NET也明確支持Java語(yǔ)言(J#)。雖然現(xiàn)在還僅僅是一個(gè)開端，但是，語(yǔ)言和平臺(tái)的融合是一種不可阻擋的趨勢(shì)：必然有更多的編譯器將其他語(yǔ)言編譯成為Java字節(jié)碼，Visual Studio.NET也必然會(huì)將程序編譯到其他操作系統(tǒng)中。
　　
然而，伴隨著技術(shù)的融合，差異性也將永遠(yuǎn)存在。微軟為了互聯(lián)網(wǎng)應(yīng)用而推出.NET框架，Windows和Visual Studio都做了巨大的改進(jìn)。為了這個(gè)框架，Visual Studio.NET甚至推出了一個(gè)新的編程語(yǔ)言C#，它具有Java語(yǔ)言的大部分特征，同時(shí)在固定內(nèi)存區(qū)允許使用指針。C#在設(shè)計(jì)上確實(shí)非常先進(jìn)，但是由于缺乏大量的使用，而且缺乏Java 2中的安全特性，是否能夠吸引大量的程序員，還是一個(gè)未知數(shù)；同時(shí)，C#中的很多特性(像對(duì)象方法的修飾詞等)都是微軟COM+規(guī)范在編程語(yǔ)言中的映射，這會(huì)在今后的操作系統(tǒng)平臺(tái)移植時(shí)產(chǎn)生麻煩。
　　
除了開發(fā)人員的平臺(tái)特性和語(yǔ)言偏愛以外，人員間的配合模式也決定著工具的選擇。自由軟件普遍采用的跨地域開發(fā)模式，對(duì)于使用CVS版本管理系統(tǒng)的開發(fā)工具非常合適。而由于Visual Studio.NET在開發(fā)調(diào)試中會(huì)改變本地Windows注冊(cè)庫(kù)，跨地域開發(fā)就非常不方便。
　　
當(dāng)然，不能排除別的因素對(duì)于開發(fā)工具的影響。舉例來說，行業(yè)的特點(diǎn)以及遺留系統(tǒng)(legacy system)對(duì)于開發(fā)的影響也是不可忽略的：電信行業(yè)的軟件開發(fā)，由于有ITU-T規(guī)范的存在，Java要代替現(xiàn)有的C/C＋＋開發(fā)模式還不能像通用軟件那么快。但是，歸結(jié)起來，軟件的開發(fā)總是一個(gè)由人完成和為人服務(wù)的。無(wú)論其他因素的影響力現(xiàn)在有多大，今后的發(fā)展也必然是由人來決定的。

開發(fā)利器1 PB集成 降本提效
　　
互聯(lián)網(wǎng)已經(jīng)從前幾年的“接入為王”、“內(nèi)容為王”，發(fā)展到了今天的“應(yīng)用為王”的時(shí)代了。大批的應(yīng)用軟件開發(fā)人員也將進(jìn)入Web應(yīng)用開發(fā)領(lǐng)域。他們熟悉應(yīng)用業(yè)務(wù)領(lǐng)域、熟悉傳統(tǒng)C/S的開發(fā)技巧，但不一定熟悉HTML/javascript, 也不一定熟悉3-tier體系架構(gòu)。這對(duì)平臺(tái)和工具廠商來說是一個(gè)巨大的商機(jī)。

PB異軍突起
　　
現(xiàn)在究竟是什么阻礙了Web應(yīng)用和3-tier的大批出現(xiàn)呢？仍然是工具。一個(gè)好的開發(fā)工具應(yīng)該是在日常開發(fā)中能夠屏蔽煩瑣的技術(shù)細(xì)節(jié)，并允許高級(jí)開發(fā)人員直接干預(yù)這些技術(shù)細(xì)節(jié)。在3-tier開發(fā)中，我們會(huì)同時(shí)面對(duì)數(shù)據(jù)庫(kù)操作(表、數(shù)據(jù)維護(hù)、存儲(chǔ)過程和觸發(fā)器的維護(hù)等)，Component編寫和調(diào)試, 網(wǎng)頁(yè)(尤其是調(diào)用這些Component的動(dòng)態(tài)頁(yè)面)的編寫和調(diào)試，以及一些2-tier應(yīng)用程序的維護(hù)等許多任務(wù)。
　　
一般說來，完成這些任務(wù)需要使用多種工具，在開發(fā)時(shí)需要在多個(gè)工具之間切換，由此造成了開發(fā)效率的低下和開發(fā)難度的提高。而PB8/PJ4很好地解決了這些問題。所有這些任務(wù)，都可以在同一個(gè)開發(fā)環(huán)境中完成，開發(fā)人員能非常快速地編寫基于數(shù)據(jù)庫(kù)的業(yè)務(wù)邏輯Component以及調(diào)用這些Component的Web-Client或PB-Client。尤其是Sybase把2-tier中的王牌Datawindow擴(kuò)展到了HTML領(lǐng)域，使得數(shù)據(jù)庫(kù)驅(qū)動(dòng)的動(dòng)態(tài)頁(yè)面實(shí)現(xiàn)起來非常容易。
　　
總體來說，Sybase的優(yōu)勢(shì)在于具備開發(fā)企業(yè)信息系統(tǒng)所需的全系列的工具，包括系統(tǒng)分析和系統(tǒng)設(shè)計(jì)工具PowerDesigner、應(yīng)用開發(fā)工具PowerBuilder和PowerJ、應(yīng)用服務(wù)器EAServer(內(nèi)含Jaguar和PowerDynamo)、數(shù)據(jù)庫(kù)Adaptive Server Enterprise(以及復(fù)制服務(wù)器等)。這些工具由于是同一家公司的產(chǎn)品，具有非常好的互操作性。同時(shí)，這些工具對(duì)標(biāo)準(zhǔn)的支持非常好，比如EAServer對(duì)組件模型就同時(shí)支持COM、CORBA和J2EE，可以用C/C++和JAVA來編寫各種Component, 甚至以CORBA的形式支持用PowerBuilder直接編寫Component。

反面意見
　　
許多人都提到PB的許多不足，比如與VB和Delphi相比界面較單調(diào)、對(duì)于Windows API的調(diào)用能力較差(PB本身不直接支持指針)等等。然而，在某些特定場(chǎng)合，這些問題會(huì)變成優(yōu)勢(shì)。企業(yè)應(yīng)用的核心在于數(shù)據(jù)訪問和業(yè)務(wù)邏輯。界面的花哨倒并不重要。在企業(yè)應(yīng)用中，好的用戶界面設(shè)計(jì)是指符合用戶業(yè)務(wù)思維方式和業(yè)務(wù)流程的界面設(shè)計(jì)，而不是花哨的界面設(shè)計(jì)。而不支持指針，則會(huì)大大提高程序的可靠性。這些問題，實(shí)際上都源自PB產(chǎn)品的定位：不是作為一個(gè)通用開發(fā)工具，而是作為一個(gè)專用的企業(yè)信息系統(tǒng)開發(fā)工具。在這個(gè)領(lǐng)域，PB/PoerJ確實(shí)是無(wú)可匹敵的。
　　
在系統(tǒng)分析和設(shè)計(jì)工具領(lǐng)域，Rational Rose是一個(gè)常被人稱道的工具。然而在現(xiàn)實(shí)的信息系統(tǒng)項(xiàng)目和應(yīng)用軟件開發(fā)中，我們面對(duì)的不是純面向?qū)ο蟮沫h(huán)境，而是關(guān)系數(shù)據(jù)庫(kù)和面向?qū)ο蟮幕旌檄h(huán)境。并且，用戶無(wú)一例外地希望數(shù)據(jù)庫(kù)的訪問有盡可能高的性能。 　　

第三方工具
　　
在互聯(lián)網(wǎng)上您可以找到大量第三方的工具來幫助您提高您在開發(fā)PowerBuilder應(yīng)用時(shí)的效率和質(zhì)量。下面就是兩個(gè)例子：
　　
大家一定會(huì)了解Visual C/C++與MFC的關(guān)系。在C/S環(huán)境中，PowerBuilder也有一個(gè)PFC與之對(duì)應(yīng)。當(dāng)然，兩者的層次是不同的。MFC提供了底層的封裝，而PFC提供了數(shù)據(jù)庫(kù)應(yīng)用的更高層面的封裝。對(duì)PFC的深入應(yīng)用可以大大提高系統(tǒng)的開發(fā)效率和開發(fā)質(zhì)量。進(jìn)入到3-tier的世界，如果用PB來開發(fā)Component，同樣也有一些很好的類庫(kù)，比較著名的就是EAF。對(duì)這些類庫(kù)的深入應(yīng)用并形成自己的類庫(kù)，是迅速提高產(chǎn)品和項(xiàng)目的質(zhì)量和效率捷徑。
　　
確保應(yīng)用軟件的質(zhì)量一定是許多人都很頭疼的問題。那我們就先來看看最基本的問題吧。在單元測(cè)試這個(gè)領(lǐng)域，大家一定了解在Java中的JUnit這個(gè)單元測(cè)試工具。PB中也有一個(gè)對(duì)應(yīng)的工具叫做PBUnit。你可以在開發(fā)過程中，在PBUnit環(huán)境中編寫測(cè)試腳本，反復(fù)對(duì)你的Object進(jìn)行回歸測(cè)試，并自動(dòng)記錄、分析測(cè)試結(jié)果。對(duì)于常常是包含了大量數(shù)據(jù)處理的PB應(yīng)用程序來說，這是非常有價(jià)值的。(祝楓)

開發(fā)利器2 WebSphere Studio 開放開發(fā)
　　
IBM正在交付一個(gè)基于WebSphere Studio Workbench技術(shù)的電子商務(wù)應(yīng)用程序開發(fā)工具的新套件。WebSphere Studio Workbench是一個(gè)用于工具開發(fā)和集成的平臺(tái)。這是 IBM 對(duì)開放源碼Eclipse Project的增值實(shí)現(xiàn)。WebSphere Studio Workbench提供用于開發(fā)源代碼編輯器和其它用戶界面的一組API、模型和框架，以及對(duì)資源管理的公共服務(wù)、調(diào)試和團(tuán)隊(duì)編程的訪問。該平臺(tái)實(shí)現(xiàn)了現(xiàn)有標(biāo)準(zhǔn)并提供用于將功能部件和函數(shù)作為插件添加的擴(kuò)展點(diǎn)。IBM 和獨(dú)立軟件供應(yīng)商(ISV)正在開發(fā)插入這個(gè)框架的工具。
　　
WebSphere Studio Site Developer和WebSphere Studio Application Developer是IBM合并和擴(kuò)展WebSphere Studio Workbench而成的兩個(gè)產(chǎn)品。這些產(chǎn)品是計(jì)劃中將要跨越所有電子商務(wù)開發(fā)角色的集成開發(fā)工具套件的一部分，從Web開發(fā)者到Java開發(fā)者、到商務(wù)分析師、到設(shè)計(jì)師、到企業(yè)程序員。WebSphere Studio開發(fā)工具系列將添加更多產(chǎn)品。
　　
客戶希望有開放標(biāo)準(zhǔn)、工具集成、更大的靈活性和結(jié)合到現(xiàn)有應(yīng)用程序的能力。這些還只是WebSphere Studio產(chǎn)品套件所交付的部分優(yōu)點(diǎn)。

垂直和水平集成
　　
傳統(tǒng)上，軟件供應(yīng)商提供垂直工具，迫使客戶自己做集成。WebSphere Studio Workbench的目的是提供一個(gè) IBM 和 ISV 都能容易地?cái)U(kuò)展的平臺(tái)。供應(yīng)商已經(jīng)擁有了該技術(shù)并在此基礎(chǔ)上積極地構(gòu)建工具。
　　
在Workbench上構(gòu)建的每個(gè)WebSphere Studio產(chǎn)品都將提供已集成的工具，使您可以專注于構(gòu)建應(yīng)用程序而不必費(fèi)力去集成工具。
開放標(biāo)準(zhǔn)
　　
WebSphere Studio套件中的所有產(chǎn)品都是構(gòu)建在開放標(biāo)準(zhǔn)上的，并且它們所生成的代碼也是與開放標(biāo)準(zhǔn)一致的?？梢詷?gòu)建和部署滿足Servlets 2.2、JavaServer Pages(JSP)1.1和 Enterprise JavaBEAns(EJB)1.1規(guī)范的最新型的(state-of-the-art)服務(wù)器端應(yīng)用程序(在Site Developer產(chǎn)品中將不包含EJB開發(fā)工具。)所有構(gòu)建在WebSphere Studio Workbench上的產(chǎn)品，都包含CVS(Concurrent Versions System)。

基于角色的開發(fā)
　　
WebSphere Studio產(chǎn)品系列中的每個(gè)成員都是為特殊電子商務(wù)開發(fā)角色或某種角色范圍設(shè)計(jì)的。例如，Site Developer是為開發(fā)和管理整個(gè)網(wǎng)站的Web開發(fā)者設(shè)計(jì)的。Application Developer包含Site Developer的所有功能并添加了對(duì)在業(yè)務(wù)邏輯方面(包含 EJB)工作的程序員的支持。當(dāng)IBM交付WebSphere Studio系列的未來成員時(shí)，它將擴(kuò)展其選項(xiàng)范圍，將產(chǎn)品與用戶的角色和需求相匹配。
　　
在每個(gè)WebSphere Studio解決方案內(nèi)部，面向任務(wù)的視圖篩選出復(fù)雜性并只提供與手邊的任務(wù)相關(guān)的功能。用戶根據(jù)此時(shí)正在開發(fā)或分析什么，或者根據(jù)他們?cè)陧?xiàng)目中的角色切換視圖。因?yàn)椴煌拈_發(fā)者以不同的方法工作，所以視圖可以定制。因?yàn)樗麄兪褂肳ebSphere Studio Workbench技術(shù)構(gòu)建，所以所有工具和視圖共享一個(gè)公共外觀，這減小了學(xué)習(xí)難度并使得用戶的生產(chǎn)力最大化。并且，因?yàn)轫?xiàng)目的開發(fā)資源存儲(chǔ)在單個(gè)資源庫(kù)中，所以您獲得了對(duì)項(xiàng)目的最大共享性和一致團(tuán)隊(duì)支持。

最大編程性能
　　
除了將應(yīng)用程序開發(fā)者們從工具集成任務(wù)中解放出來以外，Site Developer和Application Developer 都以許多方法優(yōu)化了程序員的生產(chǎn)力。(蘇永)

開發(fā)利器3 微軟.NET和C#
　　
微軟現(xiàn)在把自己的希望寄托在新的.NET應(yīng)用程序框架之上。雖然在.NET中幾乎可以使用任何一種編程語(yǔ)言，但是開發(fā)者更熱衷的還是微軟的C#和C++。因?yàn)樗鼈兏淖兞藥缀跛袕淖烂孳浖骄哂蠾eb功能的企業(yè)解決方案的Windows開發(fā)規(guī)則,所以這些技術(shù)的潛力非常巨大。
　　
.NET框架和C#擴(kuò)展了Windows的功能，C#和Visual Studio .NET的結(jié)合使得創(chuàng)建和配置Web服務(wù)幾乎可以自動(dòng)進(jìn)行。并且，和傳統(tǒng)的ASP應(yīng)用程序相比，ASP.NET應(yīng)用程在性能、穩(wěn)定性以及可擴(kuò)展性方面都有了實(shí)質(zhì)性的提高。
　　
雖然有很多優(yōu)點(diǎn)，但是.NET價(jià)格不菲。目前的Windows開發(fā)者如果要轉(zhuǎn)向.NET框架，都必須進(jìn)行再培訓(xùn)，并且所需費(fèi)用很高。由于.NET框架中有很多重大的改變以及復(fù)雜度的提高，因而現(xiàn)在的VB程序員將無(wú)法應(yīng)對(duì)這些變化。C++程序員則會(huì)因?yàn)镃#繼承了自己熟悉語(yǔ)言中的基本內(nèi)容而感到高興，但是他們也會(huì)發(fā)現(xiàn)在API以及語(yǔ)言方面C#還是有很大的改變。
　　
在ASP.NET中，由于不再使用VBScript，而只用JScript，并且在系統(tǒng)服務(wù)中也不再提倡使用COM(Component Object Model)，因此要把現(xiàn)有的Web應(yīng)用程序轉(zhuǎn)換成ASP.NET，重新編寫程序代碼要耗費(fèi)大量的時(shí)間和精力。如果要把現(xiàn)有Java項(xiàng)目轉(zhuǎn)入到.NET框架中，即使你使用的是J#(微軟的Java開發(fā)語(yǔ)言)，那么要完成一個(gè)項(xiàng)目的遷移，至少也要花費(fèi)幾個(gè)月的時(shí)間。如果要把服務(wù)器從Unix平臺(tái)遷移到Windows,那么更是要求所有的

IT職員都必須掌握一門新的技術(shù)。
　　
考慮到以上因素，我們就很容易理解為什么.NET和C#會(huì)讓人們既關(guān)注又擔(dān)憂。當(dāng)然，對(duì)于已經(jīng)在從事Windows平臺(tái)下開發(fā)的公司和企業(yè)來說，不是接不接受.NET的問題，而是什么時(shí)候接受的問題。目前普遍的觀點(diǎn)認(rèn)為，如果不及時(shí)實(shí)現(xiàn)向.NET的遷移，那么將最終不堪忍受來自開發(fā)者、商業(yè)伙伴、應(yīng)用程序提供商以及工具提供商的壓力。 　　

當(dāng)然，相對(duì)于來自Java、Unix和Linux擁護(hù)者的挑戰(zhàn)來說，微軟要把Windows下的開發(fā)者吸引到.NET框架上來。在和Java和J2EE的競(jìng)爭(zhēng)中，微軟主要有兩張牌可打，即Visual Studio .NET和Web服務(wù)。測(cè)試版的Visual Studio .NET IDE(整合開發(fā)環(huán)境)已經(jīng)在開發(fā)人員中引起了不小的震動(dòng)。相信在Web服務(wù)領(lǐng)域和Java競(jìng)爭(zhēng)時(shí)，它將成為微軟的一把利器。(伊利貴)

開發(fā)利器4 鐘情Delphi 6
　　
Delphi 6 是當(dāng)前 Windows 平臺(tái)上全面支持最新 Web 服務(wù)的快速開發(fā)工具。無(wú)論是企業(yè)級(jí)用戶還是個(gè)人開發(fā)者，都能夠利用Delphi 6 輕松、快捷地構(gòu)建新一代電子商務(wù)應(yīng)用。Delphi 6優(yōu)秀在何處？

高效的開發(fā)
　　
Delphi 6是一個(gè)RAD(Rapid Application Development 快速開發(fā)工具)。它有可視化的開發(fā)環(huán)境，當(dāng)然具有類似功能的開發(fā)工具也不少(如Visual Basic)，但Delphi 6有如下的獨(dú)到之處：
　　
Delphi 6是真正面向?qū)ο蟮?。其?gòu)建的VCL庫(kù)中的所有組件都可以被繼承以創(chuàng)建新的組件，包括窗體類TForm。相比之下，ActiveX組件缺乏這種靈活性。
　　
Delphi 6的CodeInsight技術(shù)(即代碼自動(dòng)完成功能)是建立在編譯器信息上的，而VB使用的是類型庫(kù)信息，使用編譯器信息的好處是更具靈活性。不過，時(shí)常有程序員抱怨Delphi 6的代碼提示時(shí)間太長(zhǎng)。

高效的編譯
　　
可以說，Delphi 6是Windows平臺(tái)上最快的高級(jí)語(yǔ)言本地代碼編譯器了。編譯速度快有什么好處呢？快速的編譯器可以讓你頻繁地在修改代碼和編譯運(yùn)行的狀態(tài)間切換。至少，我自己已經(jīng)非常習(xí)慣了這樣的工作方式：運(yùn)行程序看一下效果，退出程序修改少量代碼再運(yùn)行程序。而Delphi 6的編譯器從來不會(huì)讓我有等待的感覺。

高效的執(zhí)行
　　
Delphi 6與C++Builder使用的是同一個(gè)后端優(yōu)化器，因此其生成代碼的效率與優(yōu)秀的C++編譯器生成代碼效率相同。
　　
Delphi 6生成完全本地代碼，因此Delphi 6編譯結(jié)果的可執(zhí)行文件可以被獨(dú)立執(zhí)行、分發(fā)(對(duì)于“綠色軟件”的開發(fā)，這一點(diǎn)十分重要)。不需要其他運(yùn)行庫(kù)支持。當(dāng)然，你也可以選擇動(dòng)態(tài)鏈接編譯，這樣可以大大減小可執(zhí)行文件的長(zhǎng)度，不過這種情況下在分發(fā)程序時(shí)，必須同時(shí)分發(fā)必要的運(yùn)行庫(kù)文件。

構(gòu)建Windows/Linux 應(yīng)用
　　
Delphi 6 與Kylix兼容。使用Kylix，可在Linux平臺(tái)上重新編譯基于Windows平臺(tái)的CLX應(yīng)用；而利用Delphi 6，即可在Windows上重新編譯基于CLX組件的Linux應(yīng)用。Delphi 6包含BaseCLX、VisualCLX、DataCLX和NetCLX四個(gè)組件。

與AppServer集成
　　
Delphi 6通過最新SIDL與AppServer連接。它為AppServer應(yīng)用開發(fā)出高性能、具有豐富GUI環(huán)境的客戶端應(yīng)用，通過Internet將AppServer的EJB功能作為遵循業(yè)界標(biāo)準(zhǔn)的SOAP/XML Web服務(wù)發(fā)布到全球。(李爭(zhēng))

編后語(yǔ)
　　
現(xiàn)在，各種開發(fā)工具的功能相互大量重復(fù)，一個(gè)大而全的工具幾乎總是可以被幾個(gè)別的工具代替。工具的選擇確實(shí)非常讓人迷惑，但是，無(wú)論是開發(fā)人員還是管理人員都應(yīng)該意識(shí)到：工具只能起到協(xié)助的作用，嚴(yán)格的軟件工程管理和開發(fā)人員的技術(shù)水平才是軟件開發(fā)成功的關(guān)鍵。成功開發(fā)加上有效的管理和市場(chǎng)運(yùn)作，才能構(gòu)成一個(gè)完整的成功軟件。 　　

開發(fā)工具的對(duì)壘
　　
軟件開發(fā)人員沒有人會(huì)不知道微軟的.NET和Sun的J2EE。二者盡管所提供的方法不同，但都具有許多非常優(yōu)秀的特點(diǎn)。
　　
二者的可移植性都非常好。.NET的核心只能工作在Windows環(huán)境下，但從理論上講可以支持多種語(yǔ)言開發(fā)?只要這些語(yǔ)言的子集已經(jīng)定義好，并為他們建立了IL編譯器?。對(duì)于J2EE來說，只要遵循Java VM?規(guī)則?和一組平臺(tái)需要的服務(wù)，就可以在任何平臺(tái)上工作。因?yàn)樗卸xJ2EE平臺(tái)的規(guī)范，都已經(jīng)向公眾公布，所以，許多供應(yīng)商也提供兼容產(chǎn)品和開發(fā)環(huán)境。
　　
.NET并不是一種精巧的標(biāo)志，而是微軟策略的重大轉(zhuǎn)移，它將給其操作系統(tǒng)平臺(tái)帶來更大的支持率?，F(xiàn)在他們正努力把Java和開放資源自身所特有的語(yǔ)言逐步開放，然后實(shí)現(xiàn)直接滿足開發(fā)商的需要。Java清除了平臺(tái)的障礙。但是為了用J2EE來做開發(fā)工作，用戶必須在Java環(huán)境下工作。而.Net是想讓用戶使用自己選擇的語(yǔ)言來建造.NET應(yīng)用程序，這是十分美妙的。
　　
對(duì)于微軟的開發(fā)商，.NET是一個(gè)好的構(gòu)架，用戶可以將許多事情交給微軟的體系結(jié)構(gòu)去完成。ASP.NET比ASP好，ADO.NET比ADO和DCOM出色，C＃比C和C＋＋更好。所以，如果現(xiàn)在正在微軟的開發(fā)構(gòu)架中從事開發(fā)工作，將.NET的元件采納到你的體系結(jié)構(gòu)中，顯然是一個(gè)明智的選擇。不過，雖然.NET平臺(tái)描繪了美好的藍(lán)圖，但其設(shè)想要全部成為現(xiàn)實(shí)，還有較長(zhǎng)的路要走。例如IL公共語(yǔ)言的運(yùn)行，目前還有某些明顯的障礙需要克服。想要把每一種語(yǔ)言和元件運(yùn)行時(shí)集成起來，必須定義這種語(yǔ)言的子集/超集，并清晰地影射到IL上；此外必須定義結(jié)構(gòu)，以便提供IL需要的元數(shù)據(jù)；還有必須要開發(fā)適用于兩種編譯語(yǔ)言結(jié)構(gòu)的編譯器，集成到IL部件字節(jié)代碼中；同時(shí)還要生成對(duì)現(xiàn)有IL元件的語(yǔ)言專用接口。
　　
由于歷史的原因，在Java語(yǔ)言中使用非Java語(yǔ)言，必須要開發(fā)非Java語(yǔ)言到JavaVM的眾多轉(zhuǎn)換器。因此，在Java環(huán)境中寫代碼，就必須要承受將額外的翻譯工作加到目標(biāo)構(gòu)架上。如果Java環(huán)境是目標(biāo)，人們通常會(huì)選擇學(xué)習(xí)Java。而如果目標(biāo)環(huán)境是.NET，那么人們將會(huì)選擇學(xué)習(xí)C＃。(伊利貴)

64位的軟件開發(fā)
　　
因?yàn)樵趦?nèi)存容量、I/O處理效率等方面64位系統(tǒng)有著32位系統(tǒng)無(wú)可比擬的優(yōu)勢(shì)，因此在高端應(yīng)用上，Sun、IBM和HP等大腕一直熱衷于64位系統(tǒng)?？梢灶A(yù)見，在不久的將來，Intel的64位處理器將成為Sparc的主要競(jìng)爭(zhēng)對(duì)手。
　　
不過，由于Linux和Windows環(huán)境下的主要的應(yīng)用程序都是32位的，因此，軟件廠商和自由軟件項(xiàng)目必須為64位系統(tǒng)重寫他們的應(yīng)用程序。所幸的是，由于Java的盛行以及.NET的出現(xiàn)，這將使得應(yīng)用程序向Itanium的移植變得非常神速。IBM已經(jīng)推出了其用于Itanium的Java SDK(軟件開發(fā)工具包)，此外，微軟的.NET框架在其發(fā)行.NET Server時(shí)，也將登陸Itanium。而Borland更是已經(jīng)使其Java開發(fā)工具和服務(wù)器可以在Itanium上運(yùn)行。

注:本文轉(zhuǎn)自http://sd.csdn.net/n/20060529/91048.html