信息倉儲支持雙向工程HTML文檔化完全UML1.3支持選擇列表數據建模版本控制模型導航打印支持圖表視圖圖表輸出腳本健壯性平臺升級未來(lái)...以下標準用于評估一種UML工具。當然，除了已被列出的以外，可以用這些標準來(lái)評估的產(chǎn)品還很多，但如果你想選擇最好的，請花時(shí)間按照清單對產(chǎn)品作測試。如果你特別重視某項標準而在清單中沒(méi)有列出，
請告訴我們。對于一個(gè)大項目，信息倉儲(Repository)對在開(kāi)發(fā)人員之間共享組件設計是必要的。兩個(gè)以上的開(kāi)發(fā)人員可以共享同一模型的的組件，甚至可以通過(guò)在適當級別上定義所有權和共享權來(lái)合作進(jìn)行單一組件的開(kāi)發(fā)。 信息倉儲通常用提供數據共享和并發(fā)控制等特性的數據庫來(lái)實(shí)現。 通過(guò)提供鎖定和只讀訪(fǎng)問(wèn)，信息倉儲允許一個(gè)開(kāi)發(fā)人員擁有整個(gè)模型而其他人對該模型及其組件只讀訪(fǎng)問(wèn)，或者將這些組件結合到自己的設計中。重要的是： 這種工具應該允許你從另一個(gè)模型只引入你所需要的組件而不必引入整個(gè)模型。
構造信息倉儲的另一個(gè)令人感興趣的方法是利用項目的源代碼，使用源碼控制系統來(lái)提供并發(fā)控制。這種方法的好處是在源碼和模型之間有更高級別的同步，另一個(gè)好處是更除去了另一個(gè)數據源--別忘了，如果你為信息倉儲使用了數據庫，你必須對各種存儲數據分別備份并完成在模型、信息倉儲和源代碼之間的三方同步，而不止是在代碼和模型之間的兩方同步。
有了建模工具對信息倉儲的支持，對任何組件的修改將被自動(dòng)傳播到所有引入該組件的設計。
對源代碼(Java, C++, CORBA IDL)的正向和逆向工程的能力是一項復雜的需求，不同廠(chǎng)商在不同程度上成功地支持這一點(diǎn)。對正向和逆向工程這兩方面的成功結合，定義為雙向工程。
正向工程在第一次從模型產(chǎn)生代碼時(shí)非常有用，這將為你節省許多用于編寫(xiě)類(lèi)、屬性、方法代碼的瑣碎工作的時(shí)間。
在以前沒(méi)有模型存在的情況下，將代碼轉換成模型；或者在迭代結束，重新同步模型和代碼時(shí)，逆向工程非常有用。
在一個(gè)迭代開(kāi)發(fā)周期中，一旦一個(gè)模型作為迭代的一部分被修改，另一輪的正向工程應允許所有加入該模型的新的類(lèi)、方法、屬性的代碼被更新。這個(gè)步驟通常不被開(kāi)發(fā)者采用，因為許多工具在這個(gè)過(guò)程中沒(méi)有辦法管理源代碼，問(wèn)題在于源代碼中不只包含與模型有關(guān)的信息。工具必須精于對在新一輪正向工程之前已有的源代碼進(jìn)行重新構造。
至少，建模工具應成功支持一開(kāi)始的正向工程和全過(guò)程的逆向工程。同樣，建模工具對純Java語(yǔ)言的逆向工程的支持應該毫無(wú)問(wèn)題。一定要針對你自己的源代碼確認這一點(diǎn)，因為我們見(jiàn)到過(guò)優(yōu)秀的工具在對Java的一些特性如內聯(lián)類(lèi)(inner classes)等進(jìn)行逆向工程時(shí)失敗了，每一次進(jìn)行逆向工程時(shí)，你不得不把討厭的代碼注釋掉----確實(shí)非常痛苦。
對象建模工具應能為對象模型及其組件無(wú)縫地產(chǎn)生HTML文檔。HTML文檔提供對象模型的靜態(tài)視圖，以便開(kāi)發(fā)者通過(guò)瀏覽器迅速查詢(xún)而不需要加載建模工具本身。另外，通過(guò)產(chǎn)生HTML文檔，所需建模工具的許可證(licenses)會(huì )因減去那些對模型只需要有只讀權限的人而減少。
HTML文檔應包括模型中每個(gè)圖形的一張位圖，并允許通過(guò)超鏈接瀏覽整個(gè)模型。產(chǎn)生HTML文檔所需的時(shí)間應是合理的?，F在許多產(chǎn)品在不同程度上成功支持這一點(diǎn)。再說(shuō)一遍，你必須親自測試這個(gè)特性，在特征表上有打勾并不能保證成功支持。
雖然許多工具聲稱(chēng)完全支持UML1.3，實(shí)際上，這是一項復雜的需求，一些工具并不能做到廣告所聲稱(chēng)的完全支持。至少應支持的圖表有：用例圖(Use Case diagrams)，類(lèi)圖(Class diagrams)，協(xié)作圖(Collaboration diagrams)，順序圖(Sequence diagrams)，包圖(Package diagrams)，狀態(tài)圖(State diagrams)。
建模工具應在一些關(guān)鍵界面上提供選擇列表:
協(xié)作圖(Collaboration Diagrams)和順序圖(Sequence Diagrams) --工具應允許從模型的類(lèi)列表中選擇一個(gè)類(lèi)，把一個(gè)對象分配給它，并允許對象間傳送的消息能夠從接收消息對象(類(lèi))的有效方法列表中選取。
類(lèi)圖(Class Diagram) --工具應允許從別的包或模型的類(lèi)列表中選擇并引入類(lèi) 。
選擇列表特性在直觀(guān)上對建模工具至關(guān)重要，可以看作是必備特性。能夠迅速從列表中選擇一個(gè)對象到另一個(gè)對象的消息，給開(kāi)發(fā)順序圖和協(xié)作圖帶來(lái)很大的方便。
對象建模工具應允許集成數據建模工具。有許多方法可以提供這種功能。一種方法是UML工具提供將對象模型轉換成DDL(數據定義語(yǔ)言，用于為類(lèi)創(chuàng )建表的SQL)。另一種方法是UML工具輸出元數據到能夠輸入這些元數據的數據建模工具，并將其作為數據模型的基礎。一套先進(jìn)、完整的工具應允許數據模型和對象模型之間在每次設計的迭代之后同步。
建模工具應允許儲存各種版本，以便后續迭代開(kāi)始時(shí)，以前的版本仍然可以得到，并用于重建或保持基于該版本的已有代碼。
建模工具應提供強的導航支持以允許開(kāi)發(fā)者全盤(pán)瀏覽模型中的所有圖表和類(lèi)。一種方法是提供一個(gè)按名字排序的類(lèi)目錄或選擇列表，以便設計人員隨意跳到圖表中想去的類(lèi)。
對于大的圖表，工具應使得在縮放和平移時(shí)，能夠輕松實(shí)現瀏覽。
工具也應允許在使用雙向工程時(shí)，對類(lèi)的源代碼輕松瀏覽。
建模工具應允許一張大圖表能夠準確地用多個(gè)頁(yè)面打印出來(lái)，并提供打印預覽和縮放功能，輕松地使圖表能夠在所需頁(yè)數內放置。允許將一張圖表放置在單頁(yè)中的能力在清單中是高要求。不幸的是，我們發(fā)現許多工具很難用無(wú)縫的方式完成這項重要的任務(wù)。
建模工具應能方便定制類(lèi)及其細節的視圖。例如，它應有可能從圖表中排除所有的get/set方法，因為它們會(huì )對闡明一個(gè)圖表造成混亂。方法的全部信息應允許容易地根據不同級別細節的需要顯示或隱藏。屬性和方法的可見(jiàn)性(private, protected, public)是用于選擇什么該顯示，什么該隱藏的另一個(gè)尺度。
一個(gè)經(jīng)常被忽略的關(guān)鍵特性是用某種格式輸出圖表，以便引入到文字處理文檔或Web頁(yè)面中。用于輸出的最流行圖像格式是GIF、PNG和JPEG。輸出時(shí)，工具應允許你定義所產(chǎn)生圖形的首選分辨率和尺寸。這個(gè)功能需求來(lái)自那些野心勃勃，需要寫(xiě)一本包括圖表的UML書(shū)籍的作者，或者希望將他們的工作展示在網(wǎng)站上的人。
用腳本編程是建模工具應該支持的另一個(gè)強大的特性。有了腳本功能，高級用戶(hù)可以創(chuàng )建能在建模工具內直接訪(fǎng)問(wèn)對象模型的腳本來(lái)添加其它功能，例如：為當前開(kāi)發(fā)的項目做的項目管理表格，定制文檔，定制代碼，報表和度量。一個(gè)定制代碼的例子是集合類(lèi)和用于訪(fǎng)問(wèn)集合類(lèi)的get/set方法。
為了方便使用腳本，建模工具應公開(kāi)訪(fǎng)問(wèn)自身對象模型的接口，以便在開(kāi)發(fā)時(shí)能提供對對象模型組件的訪(fǎng)問(wèn)。(如果這一句聽(tīng)起來(lái)有點(diǎn)繞口，請再讀一遍。)例如，腳本編寫(xiě)者應能在整個(gè)迭代周期中訪(fǎng)問(wèn)類(lèi)圖中類(lèi)的集合，從而能夠通過(guò)類(lèi)對象的accessor方法來(lái)訪(fǎng)問(wèn)類(lèi)的屬性。當然，腳本語(yǔ)言自身應該是面向對象的；一個(gè)明顯的選擇就是Java語(yǔ)言本身，另一種選擇就是Python腳本語(yǔ)言。
你的UML工具需要象巖石般堅固可靠，以防止設計期間工具崩潰而使用戶(hù)的時(shí)間和生產(chǎn)率在不知不覺(jué)中損失，或者在模型沒(méi)有備份的情況下崩潰。我們曾親眼見(jiàn)過(guò)許多領(lǐng)先的工具因為崩潰或文件損壞而引起數小時(shí)的工作成果丟失。如果你是一位開(kāi)發(fā)人員，你知道那種因“生產(chǎn)率高的軟件”反而比粗糙的代碼工具生產(chǎn)率要低而產(chǎn)生的蔑視感覺(jué)。如果你是一位經(jīng)理，你會(huì )看到被要求使用一種不可靠的工具時(shí)開(kāi)發(fā)人員的憤恨。
今天，健壯性常被發(fā)現于用Java實(shí)現的應用程序(JVM運行時(shí)保護)或開(kāi)放源碼的項目(在web范圍內并行調試)。發(fā)現某種特定的UML工具是否健壯的最快方法是在comp.object等新聞組四處詢(xún)問(wèn)，你一定會(huì )聽(tīng)到許多抱怨的！
可用于此處的另一個(gè)策略可以借鑒有效率的辦公應用程序，我們也推薦工具開(kāi)發(fā)商采用這種策略。該策略就是讓UML工具每隔一定時(shí)間間隔就在背后自動(dòng)保存模型。
為了使你在建模工具上的投資得到最大回報，請慎重地考慮工具將運行在哪種平臺上。你需要為Windows還是Unix開(kāi)發(fā)軟件？還是二者都要？將在哪種平臺上開(kāi)發(fā)？
最近的各種事件一起推翻了這個(gè)神話(huà)：一流的跨平臺圖形用戶(hù)界面還不能實(shí)現或者擁有一個(gè)"最少共同支配者"的視感。很長(cháng)時(shí)間以來(lái),這是不可能的(除了基于HTML的應用程序之外)，直到最近Java的Swing用戶(hù)界面的出現。但是，跨平臺工具需要在Linux等常用平臺得到支持，以大規模地被程序員們采用。
Sun最初幾乎沒(méi)有做什么事情來(lái)促進(jìn)Java在Linux上的應用。但最近工業(yè)界元老們，主要是IBM，IBM保證在他們所有的硬件平臺上為L(cháng)inux提供無(wú)限廣泛的支持，并支持Apache/Jakarta項目, IBM現正快速地在Linux上推廣Java。也許因為IBM已經(jīng)開(kāi)始為主要的Linux廠(chǎng)商發(fā)放它的JDK 1.1.8版本，Sun被迫支持在Linux上的
全功能JDK 1.2 （帶Swing的Java2）的發(fā)放。通過(guò)
Blackdown小組的努力，這個(gè)Linux上的Java端口大部分已被完成。
迄今為止我們已經(jīng)測試了一種Linux平臺上基于Swing的領(lǐng)先Linux工具，結果優(yōu)秀。但要告誡的是：128M內存是必需的。
你需要選擇一種將會(huì )不斷通過(guò)修正錯誤、改進(jìn)性能、添加新特性來(lái)進(jìn)行改進(jìn)的建模工具，畢竟你在時(shí)間和金錢(qián)上進(jìn)行了一項大的投資，而且改換到另一種建模工具并不容易。
小心那些已經(jīng)被大公司擁有的產(chǎn)品。在兌現所有期權之后，最初的開(kāi)發(fā)者常常會(huì )離開(kāi)公司，尋找下一次大的機會(huì )。尋找有才能的、能讀懂和維護最初并非由其編碼的軟件復雜模塊的程序員并不容易。這種場(chǎng)景也會(huì )出現在開(kāi)放源碼項目上。
如何能知道一種產(chǎn)品是否在改進(jìn)？向銷(xiāo)售代表詢(xún)問(wèn)下一版本發(fā)放的詳細時(shí)間表以及該產(chǎn)品將來(lái)的藍圖。密切觀(guān)察產(chǎn)品改進(jìn)和添加新特性的速度。產(chǎn)品計劃什么時(shí)候支持UML 1.3？圖形界面是否支持最新的流行樣式？你也可以看看該公司的網(wǎng)站：如果產(chǎn)品發(fā)布和外界評論是舊的，就是可疑的。
現在我們來(lái)看看對未來(lái)有什么希望。建模工具的當前成熟程度表明，工具廠(chǎng)商準備通過(guò)添加高級特性來(lái)使產(chǎn)品達到新的高度。我們希望在下一代產(chǎn)品中看到以下特性的出現。
在模型的迭代開(kāi)發(fā)過(guò)程中，將UML圖表和相鄰窗口的源代碼匹配，是非常有效率的。支持這種視圖協(xié)調的產(chǎn)品可以給模型設計者的工具箱添加一個(gè)額外的功能選項，以直接給建模工具添加強大的源代碼編輯特性。當建模工具不必作為設計者的首選編輯器時(shí)，能夠在代碼里直接更改方法的名字或原型，并立即反映到模型中。
最想要的特性是類(lèi)似emacs等流行編輯器的鍵盤(pán)仿真，另一個(gè)熱門(mén)特性是通過(guò)改變顏色來(lái)突出語(yǔ)言關(guān)鍵字，注釋等等，提高了代碼的易讀性。一個(gè)重要特性是在類(lèi)圖中選擇一個(gè)類(lèi)、屬性或方法時(shí)跳轉到匹配代碼行的能力。 最重要的是, 編輯器應該是快速易用的。
作為變通的方法，另一種解決方案是允許建模工具和開(kāi)發(fā)者喜愛(ài)的編輯器通信。例如，通過(guò)一個(gè)熱鍵，允許建模工具從當前活動(dòng)窗口跳轉到伴隨編輯器的匹配代碼行。
我們真正想在不久的將來(lái)看到的一個(gè)特性是，建模工具幫助產(chǎn)生交互圖和狀態(tài)圖的能力。
工作方式是：在一個(gè)已有的程序的執行過(guò)程中，建模工具應容易生成一個(gè)追蹤文件，目的是獲取對象間互相傳遞信息時(shí)的交互。產(chǎn)生追蹤文件后，建模工具將被用于分析該追蹤文件，以發(fā)現對象交互的模式。建模工具應允許用戶(hù)從一組類(lèi)中選擇一個(gè)來(lái)分析，然后展示被追蹤文件記錄的每個(gè)類(lèi)唯一的一套交互，允許用戶(hù)為模型選擇交互。最后，工具應能夠產(chǎn)生一張基于真實(shí)記錄對象交互的順序或協(xié)作圖。
很酷嗎？它并不象聽(tīng)起來(lái)的那樣太過(guò)前衛。因為追蹤技術(shù)已經(jīng)十分成功地應用在幫助開(kāi)發(fā)人員追捕他們的程序中性能瓶頸的工具中。這類(lèi)產(chǎn)品一個(gè)很好的例子就是KL Group的JProbe，用于分析Java程序的性能。
使用同樣的技術(shù)自動(dòng)產(chǎn)生狀態(tài)圖也是可能的。對以前描述過(guò)的順序的修改將允許用戶(hù)為狀態(tài)機里的狀態(tài)指定基類(lèi)的名稱(chēng)。建模工具將追蹤基類(lèi)的衍生類(lèi)之間的交互。從這種追蹤，建模工具能夠通過(guò)描繪每次被記錄的狀態(tài)遷移來(lái)創(chuàng )建狀態(tài)圖。
如果你是項目經(jīng)理中的一員，你最有可能想要能夠估量你的O-O項目進(jìn)展如何。一個(gè)應被集成到建模工具中的很好的特性是能夠輸出模型信息到允許你追蹤項目設計和實(shí)現進(jìn)程的工具中。由于它的通用性和可塑性，電子表格是實(shí)施這個(gè)解決方案的理想工具。項目管理工具也是理想的候選。
這個(gè)特性如何工作呢？在高層次，通常你想追蹤的是模型中的類(lèi)和負責在這些類(lèi)上工作的的人。 你想知道什么時(shí)候有人開(kāi)始在該類(lèi)上工作，完成任務(wù)到了哪種水平。在下一層次的細節上，你想要知道每個(gè)類(lèi)的方法。在這一層次，你可能想要知道哪種方法已經(jīng)包括在交互圖中，或在實(shí)施階段，每種方法完成了多少代碼量。
要使這個(gè)特性起作用，你需要“敏捷”地更新你的項目管理信息。不象報表工具那樣總是從頭產(chǎn)生一個(gè)新報表，你只需要在第一次輸出所有東西。產(chǎn)生初始報表后，你的建模工具應該只被要求用新信息來(lái)修改你的管理工具。根據用戶(hù)需要控制的級別，建模工具能在輸出之前展現給用戶(hù)一個(gè)修改的清單。
建立一個(gè)項目管理鏈接的一個(gè)美妙的好處是，提供把分析和設計階段的完成日期作為目標的能力。具體方法是通過(guò)計算進(jìn)展速度，并基于完成模型所需的剩余的工作，使用這個(gè)速度來(lái)計算預期的完成日期。
當你的項目開(kāi)始成熟時(shí)，你可能需要知道你的模型的度量。度量能在一個(gè)特殊的模型的生存質(zhì)量上給面向對象分析員一些即時(shí)的反饋。一些感興趣的度量包括：類(lèi)層次中的超類(lèi)數量，每個(gè)類(lèi)中方法的數量，每個(gè)類(lèi)中屬性的數量，get/set的數量，方法重載的數量，每個(gè)方法的代碼行數，public、private和protected方法的百分比，每個(gè)類(lèi)的耦合度（該類(lèi)知道另外的類(lèi)的數量），以及被注釋方法的百分數。
度量可以通過(guò)一個(gè)報表界面提供，或者，更好的是，通過(guò)一個(gè)到電子表格的鏈接，類(lèi)似于前面描述的項目管理鏈接。
為達到真正的、標準化的矢量圖形輸出/輸入功能，UML工具廠(chǎng)商即將有一種選擇。W3C的
可縮放矢量圖形(Scalable Vector Graphics, SVG)建議是可格式化圖形的一種XML語(yǔ)法，成熟的1.0版本規范已經(jīng)進(jìn)展到“最后預覽”階段(3/3/2000)。一旦被完全認可，你可以留意HTML瀏覽器廠(chǎng)商什么時(shí)候在他們的下一代瀏覽器中提供支持。
為什么是SVG？因為一套用這種矢量圖形格式輸出的UML圖表可以被鏈接到網(wǎng)頁(yè)上?！皁ver the web”的UML設計文檔的讀者將能夠使用這種圖形瀏覽技術(shù)，如在瀏覽器內縮放和平移，來(lái)更輕松地瀏覽一張大的UML圖表。還有，和GIF格式圖形相比，這種格式將戲劇性地提高通過(guò)web加載大圖形的速度。請看今天Macromedia Flash的展示在瀏覽器中加載是如何之快，就可以證明這一點(diǎn)！
為了強調GIF圖形和可縮放圖形在出版環(huán)境中的強烈差別，我們準備了一個(gè)模擬，通過(guò)創(chuàng )建包括兩個(gè)類(lèi)圖實(shí)例的Adobe PDF文件，其中一張是輸入的GIF圖形，另一張是矢量圖形。你可以下載這個(gè)PDF文檔并在A(yíng)dobe Acrobat中觀(guān)看。嘗試放大到很高的水平如800%或1600%，然后比較GIF圖形和矢量圖形的結果。這個(gè)實(shí)驗并非不切實(shí)際：你可能需要準備一張被縮放到一個(gè)可讀性提高的水平的演示圖。
下載GIF和矢量圖形對比的PDF例子文件.
為了展望UML和SVG的未來(lái)，我們也準備了一個(gè)使用SVG在瀏覽器中顯示類(lèi)圖的演示。為了觀(guān)看這個(gè)演示，你必須首先為你的瀏覽器下載一個(gè)SVG察看器。我們推薦來(lái)自?xún)?yōu)秀的
Adobe SVG站點(diǎn)的插件。這樣你就可以觀(guān)看
用SVG顯示的圖形模型演示。
對UML開(kāi)發(fā)團體來(lái)說(shuō)，對象管理組織(OMG)的XMI標準是最近最令人振奮的進(jìn)展。XMI是一種有潛力最終允許在領(lǐng)先的開(kāi)發(fā)工具之間無(wú)縫共享模型的交換格式。例如，與其在UML建模工具中書(shū)寫(xiě)腳本來(lái)創(chuàng )建報表，不如讓用戶(hù)簡(jiǎn)單地在開(kāi)發(fā)時(shí)使用XMI輸出該模型，然后引入到一種特定的報表書(shū)寫(xiě)工具中。事實(shí)上，這個(gè)范例將平等地、很好地應用到前面討論過(guò)的特性：O-O度量追蹤和項目管理。此外，自從XMI使用XML來(lái)表示模型信息，一批XML解決方案很快會(huì )出籠，例如為基于瀏覽器表示提供的XSL格式表和為搜索兼容性提供的 XQL查詢(xún)工具。
XMI標準是復雜的，在被廣泛使用之前，它將需要時(shí)間來(lái)適應許多不可避免的兼容性問(wèn)題(誰(shuí)說(shuō)標準經(jīng)不起解釋?zhuān)?。但是，既然XMI是由IBM和Unisys等領(lǐng)先的工業(yè)巨頭開(kāi)發(fā)的，可以預期產(chǎn)品很快會(huì )出現。一直到用戶(hù)團體不斷要求廠(chǎng)商來(lái)驅動(dòng)在UML工具中的XMI支持的需求。關(guān)于XMI的進(jìn)一步信息，請看優(yōu)秀的
IBM網(wǎng)頁(yè)。
作為XMI如何投入使用的例子，請看我們的項目，
轉換XMI到HTML. 這個(gè)項目展示了XSL格式表如何能被用來(lái)產(chǎn)生UML模型的HTML翻譯。
讀者建議 如果您對在清單中未列出的UML建模工具新特性有什么想法，
我們將很樂(lè )意聽(tīng)到。 謝謝曾經(jīng)把他們的UML工具評價(jià)標準Email給我們的讀者。他們的原始建議
在這兒。
