最近，我被邀請到一家信息機構交流信息技術的心得。主持人告訴我他們現在擁有一
個分布區域極為廣大的信息系統。每一個區域使用的硬件、操作系統、數據庫和開發
工具都不同。而且，目前這些系統之間并沒有專線連接在一起?，F在他們想要整合這
些系統，而且希望能夠在機構中心向不同的區域查詢貨物數據并且在機構中心整合查
詢到的信息。

這位主持人詢問我有沒有什么方法可以完成這個信息架構。在詳細地討論之后，我了
解到機構中心從各個區域查詢的信息都是屬于小量數據的查詢。由于在每一個不同的
區域都有自己的數據庫，因此可以通過每一個區域的數據庫服務器從大量的數據中擷
取查詢數據，再把查詢到的結果傳回機構中心進行簡單的整合工作。

對于這個信息架構，我想最簡單的方法就是在每一個區域的服務器上實現一個CORBA
服務器，再由CORBA服務器對外提供查詢接口。由于CORBA擁有跨平臺、數據庫和開發
語言中立的特點，因此非常適合使用來作為原有專屬系統提供對外的標準服務接口。
有了CORBA服務器作為服務接口之后，我們可以繼續把CORBA服務轉換為標準的Web 
Service，再由機構中心使用SOAP，即可輕易地使用標準機制穿透并且整合原本的異
質系統。

使用Web Service的原因是由于在這個應用中只會有少量的資料查詢，因此Web Service
絕對可以勝任，而Web Service提供的穿透力和整合力是其他技術難以相比的。對于
安全的需求，可以使用HTTPS加上CORBA的安全服務即可提供一定的安全可靠性。

原本看起來困難的事情一下子就被Web Service和CORBA聯手解決了。這正是一個非常
好的Web Service應用范例。

那么在2002年，Web Service在信息業界應用的情形到底是如何呢？到底有沒有信息
系統在使用SOAP和Web Service技術呢？其實，我們從各種開發工具都支持Web Service
的應用來看，一定是有人已經在使用Web Service了，否則沒有必要幾乎所有的開發
工具都爭先恐后地加入對于SOAP和Web Service的支持。

下圖是2002年信息界對于使用Web Service的最后調查結果，從數字中我們可以看到，
沒有使用Web Service的比率是43.2％，但是超過50％的調查顯示Web Service已經
或多或少的被應用在信息系統之中了。而這些統計數據也代表了Web Service被實際
應用的證明。

另外一份對于Web Service應用的調查結果如下頁所顯示。我們可以看到在2003年中
Web Service將有更大的使用比率，可見Web Service的應用將會快速地提升。

如果我們把兩份統計結果以趨勢圖同時呈現的話，會發現Web Service應用的成長比
率幾乎不會輸給一般的開發工具或是程序語言的成長比率。

在2003年Web Service除了將愈來愈普及之外，新的Web Service規格也將慢慢完善并
且開始被軟件廠商實現。除此之外，也開始有信息廠商對Web Service的缺點加以改
善推出變形的解決方案。不過千變萬變，不變的是在現在信息多元化的時代正顯示了
我們的確需要Web Service代表的穿透力和整合力。

許多人當初說Web Service是不實際的技術，從目前的各種跡象和統計數字來看這些
人似乎是錯了。Web Service的簡單化不代表無用，其緩慢也不代表不可用。我們只
需要在適當的地方使用適當的技術，Web Service就是一個很好的例子。畢竟當初Don 
Box在定義SOAP時最原始的想法本就是"簡單(Simple)"，不是嗎？



面向對象技術的平民化

"你們是用什么方法來開發系統的？"，"你們使用UML嗎？你們在使用面向對象方式開
發應用系統時使用所有的UML圖形嗎？"，"你們遵循RUP來發展軟件嗎？"，這些問題
是我在和一些信息界的朋友聊天時經常詢問的問題，因為我也非常想了解UML/RUP和
Modeling在業界使用的情形。

UML和Modeling的需求在三位OO大師多年的提倡并且成立Rational公司開始大賣Rose
后，照理說UML和Modeling在信息業界應該是被廣泛地使用，不是嗎？但是情形似乎
并不是如此。

在我知道的許多案例中，許多公司或是信息機構在購買了Rose之后，要么被供奉起來
成為一種先進/時髦的象征，不然就是被使用來作為畫圖的工具。即使是真地使用UML
和Modeling的公司也大都只是使用Rose畫畫Use Case、Class Diagram和Object 
Diagram，再繼續深入得幾乎沒有。為什么會如此呢？UML已經被證明是非常好的理論、
開發方式和溝通語言，Rose也推出了這么多年，為什么UML的普及率仍然非常低呢？為
什么許多購買了Rose的公司和機構也沒有完全使用Rose的功能呢？這其中一定有一些
問題存在。但是，這是什么問題呢？

就我個人的經驗來說，在許多的項目開發之中大概都只有使用到Use Case、Class 
Diagram和Object Diagram，最多畫畫Sequence Diagram，接著就是結合組件模型、
開發工具和數據庫開始進入開發的階段，比較注重CBD的開發模型，鮮少使用到其他
的UML圖形，因此可以說是偏向結合UML和Extreme Programming，以項目時程為最重
要的依歸，并不強調完全遵照UML和RUP。因此，我也非常想要和其他的朋友交流，了
解其他人使用UML/RUP的情形，或者其他人是如何使用OO技術開發項目的。

我個人也是從事信息工作的一員。雖然沒有什么顯著的貢獻，但是我對于UML和Rose
始終有一份懷疑。當然，這份懷疑并不是指UML和Rose沒有用，相反，UML的確對于軟
件工程有著卓越的貢獻。不過我認為UML和Rose之中的許多東西過于繁瑣，要實際應
用在項目發展之上，除非項目沒有時程和資源的限制，就像Rumbaugh自己在GE時從事
的實驗計劃，擁有許多的資源和寬闊的時程，否則，怎么可能有時間和資源把所有的
UML圖形都畫出來呢？至少就我個人的項目生涯來說是從來都不可能的，因為在我個
人的信念中項目開發最重要的準則是"On-Time Delivery Of A Working And Decent 
System"，不是UML，不是RUP，更不是任何其他時髦軟件技術。

另外，我一直認為Rose實在算不上好的軟件，每一次我使用Rose就有種回到Windows 
3.1時代的感覺。此外，Rose在繪制UML圖形上始終有一些小問題，從版本1開始到現
在都沒有改善。因此我也曾經開玩笑地說，"Rose是全世界一流的OO分析師配合三流
的程序員開發出采的產品"。因此我個人對于UML/RUP一直有著一份懷疑，只是人微言
輕，不敢輕易表示對于UML/RUP的質疑。

不過，在Extreme Programming對于UML/RUP開發模式提出類似的質疑和逐漸分庭抗禮
之后，我也在Internet/Intranet上看到愈來愈多對于UML/RUP的批評以及許多人公開
討論使用UML/RUP失敗的原因和檢討。此后，我總算如釋重負，因為這些都證明了不
單是我個人有疑問，許多人都有相同或是類似的問題。我認為這些批評和質疑對于
UML/RUP是一件好事，因為這可以讓軟件界再次審視UML/RUP不足之處，找出問題的所
在并且加以改善，才能夠讓UML/RUP持續地對軟件界和軟件工程做出貢獻。正由于
Extreme Programming對于UML/RUP的挑戰，反而可以讓我們更清楚地了解什么方法才
是最適合的。我個人認為，對于小/中的系統或是項目而言，簡易的UML和Extreme 
Programming是比較適當的，而對于大型的企業應用系統(Enterprise Application 
System)而言，UML和RUP被證明是有效的。

一直到2003年初聽了TogetherSoft的首席科學家(Chief Scientist)Todd Olsen的演
講后，才正式確定了我的想法沒有錯。連Todd Olsen都認為UML/RUP太過于學術化，
對于學術的研究沒有問題，但是在實際的應用中則稍顯繁雜。開發人員應該在開發工
具的輔助下進行適當的修整以找出最"適當"的方式來進行項目或是系統、工具的開發。
連Todd Olsen這種經驗豐富、軟件開發實力又驚人的大師級人物都這么說，我也就放
下心來了?？磥韺儆趯崙鹦偷拈_發人員，依照武俠書的講法，應該掌握的是"最具殺
人威力的劍法，而不是華麗的招式"。當時我在聆聽了Todd Olsen大膽的說法之后不
禁大呼過癮，隱藏在心中多年的質疑終于一揮而去。

雖然過于拘泥于UML/RUP的開發模型不算是好的方式(或許這對于學術研究是正確的)，
但是也沒有人完全否認UML/RUP對于軟件開發的貢獻。事實上UML是很重要的，因為它
可以讓開發人員使用同一種語言溝通，也可以很有效地使用Use Case讓企業人員和開
發人員溝通。但是為什么在Rational推廣Rose這么多年來普及的成效仍然有限呢？我
個人認為有如下的原因：

■  價格昂貴，難以普及
■  只鎖定金字塔頂端的開發人員
■  過于強調完整的UML/RUP開發模式
■  沒有和開發工具整合在一起，以打入一般的開發人員群體

由于Rose采取高價的策略，因此雖然為Rational賺進了大把的鈔票，但是也讓UML/RUP
和Rose的普及率難以大幅地擴展。想想10年前的Client/Server技術也是在
PowerBuilder、Gupta等采取高價措施而難以快速普及，一直要到VB和Delphi等大眾化
開發工具提供了Client/Server功能之后，才讓Client/Server快速為大多數的軟件人
員視Client/Server技術為理所當然的基本技巧。在PowerBuilder/Gupta錯失了占據
Client/Server的龐大市場之后，再也無法成為Client/Server的領導廠商。

同樣地，如果Rational一直為Rose采取高價，只鎖定高階開發人員市場的策略，那么
Rose很可能會在其他的競爭對手推出更好的UML產品之后快速流失市場，事實上這正
是Rational在2002年面臨的困境，因為Rose不但遭受許多UML小廠商的競爭，更被其
最大的競爭對手TogetherSoft打得難以招架，要不是Rational還有3位OO大師的名號
在力撐，Rose早就被TogetherJ或是TogetherSoft的Control Center打得落花流水了。
從最近4年TogetherSoft可怕的成長速度可以看出來，Rational早已被TogetherSoft
逼得寢食難安了。

在Borland并購了TogetherSoft之后，Rational將面對更為艱難的狀況。一旦Borland
成功地在其的開發工具中整合TogetherSoft的產品，那么將可能會像當初的Client/
Server技術一樣，可通過提供更平易近人的UML工具而快速讓UML為大多數的開發人員
接受而使用。再加上如果Borland以合理的價格提供UML和開發工具，那么將可以讓UML
打入金字塔中/低階的開發市場，快速鯨吞Rose的市場。到時Rose在UML/Modeling產
品本身不如TogetherSoft之下，再加上Borland開發工具的強力支援，Rational的大
勢不妙。因此這是為什么當Borland宣布并購TogetherSoft之后受傷最深的公司就是
Rational，而Rational也立刻聲明中斷和Borland的合作的原因。最后在Rational眼
看后勢欠佳，再加上IBM提出動人的并購條件之后便立刻接受了IBM的提議。

根據2002年的信息調查顯示，大多數的開發人員已經視Modeling工具為相當重要的工
具。

而且目前使用Modeling工具的開發人員也相對地滿意于Modeling工具提供的功能。因
此，如果Modeling工具能夠再和開發工具緊密地結合，那么Modeling未來的發展將更
為快速。

目前在所有和開發相關的工具中，Modeling和設計工具已經占據了相當重要的地位。
根據2002年調查的結果顯示，設計和Modeling工具已經分別占據了所有開發相關工具
的第2和第8名，而且還呈現持續上升的狀態。

由此可見，開發人員已經愈來愈重視設計和Modeling工具。在Borland并購TogetherSoft
之后，我認為Borland會以較為合理的價格提供整合Modeling和開發工具的軟件包，
快速把UML技術打入一般開發人員的市場，并且將會正式觸發使用UML和Modeling功能
成為開發人員的核心基本技巧，就像數年前Client/Server技術對于開發人員一樣。

因此，我們可以發現下面圖形呈現的還是去年以前開發人員擁有的技術狀況。開發人
員的核心技術只需要擁有程序語言、數據結構和Algorithm即可。

但是從2003年開始，一旦Borland或是IBM推出整合Modeling工具和開發工具的新一代
軟件之后，面向對象、Modeling和Design Pattern等技術將被壓縮到開發人員的核心
基本技術之中。這代表未來的開發人員必須熟知面向對象、Modeling和Design Pattern
等技術，再也無法逃避學習這些重要的軟件技巧。

因此，我們可以說信息公司的合并不但影響這些軟件公司之間的競爭，也會對開發人
員產生影響。在面向對象、Modeling和Design Pattern等技術成為開發人員的核心技
能之后，當然可以增加軟件開發的速度和可靠度，這對于整個軟件產業而言是正面的
結果。對于像Borland或是IBM等公司，由于讓UML和Modeling技巧和產品成為一般開