選擇UML工具
以下標準用于評估一種UML工具。當然,除了已被列出的以外,可以用這些標準來評估的產品還很多,但如果你想選擇最好的,請花時間按照清單對產品作測試。如果你特別重視某項標準而在清單中沒有列出, 請告訴我們。

信息倉儲支持

對于一個大項目,信息倉儲(Repository)對在開發人員之間共享組件設計是必要的。兩個以上的開發人員可以共享同一模型的的組件,甚至可以通過在適當級別上定義所有權和共享權來合作進行單一組件的開發。

信息倉儲通常用提供數據共享和并發控制等特性的數據庫來實現。 通過提供鎖定和只讀訪問,信息倉儲允許一個開發人員擁有整個模型而其他人對該模型及其組件只讀訪問,或者將這些組件結合到自己的設計中。重要的是: 這種工具應該允許你從另一個模型只引入你所需要的組件而不必引入整個模型。

構造信息倉儲的另一個令人感興趣的方法是利用項目的源代碼,使用源碼控制系統來提供并發控制。這種方法的好處是在源碼和模型之間有更高級別的同步,另一個好處是更除去了另一個數據源--別忘了,如果你為信息倉儲使用了數據庫,你必須對各種存儲數據分別備份并完成在模型、信息倉儲和源代碼之間的三方同步,而不止是在代碼和模型之間的兩方同步。

有了建模工具對信息倉儲的支持,對任何組件的修改將被自動傳播到所有引入該組件的設計。

雙向工程

對源代碼(Java, C++, CORBA IDL)的正向和逆向工程的能力是一項復雜的需求,不同廠商在不同程度上成功地支持這一點。對正向和逆向工程這兩方面的成功結合,定義為雙向工程。

正向工程在第一次從模型產生代碼時非常有用,這將為你節省許多用于編寫類、屬性、方法代碼的瑣碎工作的時間。

在以前沒有模型存在的情況下,將代碼轉換成模型;或者在迭代結束,重新同步模型和代碼時,逆向工程非常有用。

在一個迭代開發周期中,一旦一個模型作為迭代的一部分被修改,另一輪的正向工程應允許所有加入該模型的新的類、方法、屬性的代碼被更新。這個步驟通常不被開發者采用,因為許多工具在這個過程中沒有辦法管理源代碼,問題在于源代碼中不只包含與模型有關的信息。工具必須精于對在新一輪正向工程之前已有的源代碼進行重新構造。

至少,建模工具應成功支持一開始的正向工程和全過程的逆向工程。同樣,建模工具對純Java語言的逆向工程的支持應該毫無問題。一定要針對你自己的源代碼確認這一點,因為我們見到過優秀的工具在對Java的一些特性如內聯類(inner classes)等進行逆向工程時失敗了,每一次進行逆向工程時,你不得不把討厭的代碼注釋掉----確實非常痛苦。

HTML文檔化

對象建模工具應能為對象模型及其組件無縫地產生HTML文檔。HTML文檔提供對象模型的靜態視圖,以便開發者通過瀏覽器迅速查詢而不需要加載建模工具本身。另外,通過產生HTML文檔,所需建模工具的許可證(licenses)會因減去那些對模型只需要有只讀權限的人而減少。

HTML文檔應包括模型中每個圖形的一張位圖,并允許通過超鏈接瀏覽整個模型。產生HTML文檔所需的時間應是合理的。現在許多產品在不同程度上成功支持這一點。再說一遍,你必須親自測試這個特性,在特征表上有打勾并不能保證成功支持。

完全UML1.3支持

雖然許多工具聲稱完全支持UML1.3,實際上,這是一項復雜的需求,一些工具并不能做到廣告所聲稱的完全支持。至少應支持的圖表有:用例圖(Use Case diagrams),類圖(Class diagrams),協作圖(Collaboration diagrams),順序圖(Sequence diagrams),包圖(Package diagrams),狀態圖(State diagrams)。

類和方法的選擇列表

建模工具應在一些關鍵界面上提供選擇列表:

協作圖(Collaboration Diagrams)和順序圖(Sequence Diagrams) --工具應允許從模型的類列表中選擇一個類,把一個對象分配給它,并允許對象間傳送的消息能夠從接收消息對象(類)的有效方法列表中選取。

類圖(Class Diagram) --工具應允許從別的包或模型的類列表中選擇并引入類 。

選擇列表特性在直觀上對建模工具至關重要,可以看作是必備特性。能夠迅速從列表中選擇一個對象到另一個對象的消息,給開發順序圖和協作圖帶來很大的方便。

數據建模集成

對象建模工具應允許集成數據建模工具。有許多方法可以提供這種功能。一種方法是UML工具提供將對象模型轉換成DDL(數據定義語言,用于為類創建表的SQL)。另一種方法是UML工具輸出元數據到能夠輸入這些元數據的數據建模工具,并將其作為數據模型的基礎。一套先進、完整的工具應允許數據模型和對象模型之間在每次設計的迭代之后同步。

版本控制

建模工具應允許儲存各種版本,以便后續迭代開始時,以前的版本仍然可以得到,并用于重建或保持基于該版本的已有代碼。

模型導航

建模工具應提供強的導航支持以允許開發者全盤瀏覽模型中的所有圖表和類。一種方法是提供一個按名字排序的類目錄或選擇列表,以便設計人員隨意跳到圖表中想去的類。

對于大的圖表,工具應使得在縮放和平移時,能夠輕松實現瀏覽。

工具也應允許在使用雙向工程時,對類的源代碼輕松瀏覽。

打印支持

建模工具應允許一張大圖表能夠準確地用多個頁面打印出來,并提供打印預覽和縮放功能,輕松地使圖表能夠在所需頁數內放置。允許將一張圖表放置在單頁中的能力在清單中是高要求。不幸的是,我們發現許多工具很難用無縫的方式完成這項重要的任務。

圖表視圖

建模工具應能方便定制類及其細節的視圖。例如,它應有可能從圖表中排除所有的get/set方法,因為它們會對闡明一個圖表造成混亂。方法的全部信息應允許容易地根據不同級別細節的需要顯示或隱藏。屬性和方法的可見性(private, protected, public)是用于選擇什么該顯示,什么該隱藏的另一個尺度。

輸出圖表

一個經常被忽略的關鍵特性是用某種格式輸出圖表,以便引入到文字處理文檔或Web頁面中。用于輸出的最流行圖像格式是GIF、PNG和JPEG。輸出時,工具應允許你定義所產生圖形的首選分辨率和尺寸。這個功能需求來自那些野心勃勃,需要寫一本包括圖表的UML書籍的作者,或者希望將他們的工作展示在網站上的人。

腳本

用腳本編程是建模工具應該支持的另一個強大的特性。有了腳本功能,高級用戶可以創建能在建模工具內直接訪問對象模型的腳本來添加其它功能,例如:為當前開發的項目做的項目管理表格,定制文檔,定制代碼,報表和度量。一個定制代碼的例子是集合類和用于訪問集合類的get/set方法。

為了方便使用腳本,建模工具應公開訪問自身對象模型的接口,以便在開發時能提供對對象模型組件的訪問。(如果這一句聽起來有點繞口,請再讀一遍。)例如,腳本編寫者應能在整個迭代周期中訪問類圖中類的集合,從而能夠通過類對象的accessor方法來訪問類的屬性。當然,腳本語言自身應該是面向對象的;一個明顯的選擇就是Java語言本身,另一種選擇就是Python腳本語言。

健壯性(Robustness)

你的UML工具需要象巖石般堅固可靠,以防止設計期間工具崩潰而使用戶的時間和生產率在不知不覺中損失,或者在模型沒有備份的情況下崩潰。我們曾親眼見過許多領先的工具因為崩潰或文件損壞而引起數小時的工作成果丟失。如果你是一位開發人員,你知道那種因“生產率高的軟件”反而比粗糙的代碼工具生產率要低而產生的蔑視感覺。如果你是一位經理,你會看到被要求使用一種不可靠的工具時開發人員的憤恨。

今天,健壯性常被發現于用Java實現的應用程序(JVM運行時保護)或開放源碼的項目(在web范圍內并行調試)。發現某種特定的UML工具是否健壯的最快方法是在comp.object等新聞組四處詢問,你一定會聽到許多抱怨的!

可用于此處的另一個策略可以借鑒有效率的辦公應用程序,我們也推薦工具開發商采用這種策略。該策略就是讓UML工具每隔一定時間間隔就在背后自動保存模型。

平臺

為了使你在建模工具上的投資得到最大回報,請慎重地考慮工具將運行在哪種平臺上。你需要為Windows還是Unix開發軟件?還是二者都要?將在哪種平臺上開發?

最近的各種事件一起推翻了這個神話:一流的跨平臺圖形用戶界面還不能實現或者擁有一個"最少共同支配者"的視感。很長時間以來,這是不可能的(除了基于HTML的應用程序之外),直到最近Java的Swing用戶界面的出現。但是,跨平臺工具需要在Linux等常用平臺得到支持,以大規模地被程序員們采用。

Sun最初幾乎沒有做什么事情來促進Java在Linux上的應用。但最近工業界元老們,主要是IBM,IBM保證在他們所有的硬件平臺上為Linux提供無限廣泛的支持,并支持Apache/Jakarta項目, IBM現正快速地在Linux上推廣Java。也許因為IBM已經開始為主要的Linux廠商發放它的JDK 1.1.8版本,Sun被迫支持在Linux上的
全功能JDK 1.2 (帶Swing的Java2)的發放。通過Blackdown小組的努力,這個Linux上的Java端口大部分已被完成。

迄今為止我們已經測試了一種Linux平臺上基于Swing的領先Linux工具,結果優秀。但要告誡的是:128M內存是必需的。

版本更新

你需要選擇一種將會不斷通過修正錯誤、改進性能、添加新特性來進行改進的建模工具,畢竟你在時間和金錢上進行了一項大的投資,而且改換到另一種建模工具并不容易。

小心那些已經被大公司擁有的產品。在兌現所有期權之后,最初的開發者常常會離開公司,尋找下一次大的機會。尋找有才能的、能讀懂和維護最初并非由其編碼的軟件復雜模塊的程序員并不容易。這種場景也會出現在開放源碼項目上。

如何能知道一種產品是否在改進?向銷售代表詢問下一版本發放的詳細時間表以及該產品將來的藍圖。密切觀察產品改進和添加新特性的速度。產品計劃什么時候支持UML 1.3?圖形界面是否支持最新的流行樣式?你也可以看看該公司的網站:如果產品發布和外界評論是舊的,就是可疑的。

未來...

現在我們來看看對未來有什么希望。建模工具的當前成熟程度表明,工具廠商準備通過添加高級特性來使產品達到新的高度。我們希望在下一代產品中看到以下特性的出