來源

前言

「工欲善其事，必先利其器」，學習UML沒有好的工具幫忙，往往會讓開發人員半途而廢，尤有甚者，開發人員有時會因為使用了不容易使用的開發工具而 誤認為UML是一個非常困難學習的「技術」。殊不知UML只是一種「語言」，就和學習中文、美語一樣，學習UML根本不困難，只要瞭解UML的語法以及知 道UML的適用時機，UML自然手到擒來。當然，如果有一套上手的UML開發工具，UML的困難度更是大幅降低，這也是本次專欄我們會討論UML工具評比 的原因。

在這次專欄中，我們將評比三個不同的UML工具 – IBM公司的 Rational Software Architect(以下簡稱RSA)、Borland公司的 Together Architect(以下簡稱Together)以及Sparx Systems公司的 Enterprise Architect Corporation Edition(以下簡稱EA)。
評比的標準會從以下兩個面向來分別評估：

1. 對UML 2.0的支持；
2. 文件產生機制。

整篇文章中，我們會分成兩大部分，主要針對這三套軟體在上述的兩個面向中的操作進行說明，並且在每一個部分的最後一個小節，都會對三個軟件在該項目中做綜合評比。
不過在開始介紹之前，先就價錢做個評比說明，根據三家公司的產品標準售價，其價格的比較表如下表：

表1：三套軟件的價格表

對！不要懷疑，這三個產品的價格的差距大約是20倍。先有這樣的一個印象後，我們將針對這三個產品的功能再詳細介紹。

對UML 2.0的支持分析

圖1 是OMG所定義的UML十三張圖的分類(參考自Unified Modeling Language: Superstructure, Version 2, p. 660)。

圖1、UML 2.0 規範的 Diagram 分類

以下，我們將針對上述的三個軟件分別說明其對於UML 2.0規範的十三張圖的支援。

1、IBM RSA：

IBM的 RSA 與 Borland Together都是建構在 Eclipse 平台上，因此，你必須要先建立一個 UML 2.0 的專案，如此才可以繪製UML的圖形。下圖2就是 RSA 的 UML專案的操作畫面。

圖2、RSA 的 UML 2.0 專案操作畫面

和 Eclipse 的操作相類似，在 RSA 的操作畫面中，左邊是專案區，右邊則是所有可以使用的工具區。

在 RSA 中可以新增的圖形共有：Class Diagram、Composite Structure Diagram、Component Diagram、Deployment Diagram、Use Case Diagram、Activity Diagram、State Machine Diagram、Sequence Diagram以及Communication Diagram等九張圖。

比較起 UML 2.0 的規格所制訂的十三張圖，分別少了 Object Diagram、Package Diagram、Interaction Overview Diagram 以及 Timing Diagram 四張圖。
不過如果我們詳細觀看 UML 2.0 的規格，我們可以發現，其實 Object Diagram 與 Package Diagram 的基本 Diagram 其實就是 Class Diagram，只是在這兩張圖中，其分別表達了 Package 間的相依關係以及 Object 之間的關係。因此，在 RSA 中，我們可以使用 Class Diagram 來繪製這兩張圖形。

至於 Interaction Overview Diagram也是類似的狀況，在 UML 2.0 的規格中，其基本的圖形是 Activity Diagram，因此，我們同樣也可以利用 Activity Diagram 來繪製 Interaction Overview Diagram。

至於時序圖，雖然在 RSA 中的 Communication Diagram 可以表達時序圖中的LifeLine，但是其餘的相關的UML元件都缺乏，因此，RSA並無法完整表達時序圖。

就以上的說明我們可以瞭解，要在 RSA 中繪製完整的十三張 UML 2.0 規範的圖形，其實有一點困難性，開發人員必須要很清楚地知道這十三張圖各自的主要特性，如此才可以找到適當的圖形來進行繪製。

至於操作性上，開發人員如果熟悉 Eclipse 的介面的話，使用 RSA 算是還相當簡易，但如果不幸地，開發人員使用的 IDE 工具是 Eclipse 以外的開發工具的話，使用 RSA 算是有些難度在的。

接著來看細部的操作，在RSA中，開發人員可以輕易地將繪製好的 Sequence Diagram 轉成 Communication Diagram，反之亦然，這算是 RSA 延續過往 Rose 的重要特性，可以說是這套產品最讓人激賞的部分。

最後談到 MDA(Model-Driven Architecture)的機制，在 RSA 中提供三種轉換機制，分別是 UML->Java、UML->C++以及UML->EJB，由於 RSA 是建置在 Eclipse 上，因此，其轉換為 Java 或 EJB 時，能夠非常順暢地跟 Eclipse 的 Java 或是 J2EE 專案結合，在這個部分，也是 RSA 一向的強項。

2、Borland 的 Together：

跟 RSA 相同，在 Borland Together 中要新增 UML 2.0 的Diagram，也必須要在Eclipse的環境中新增一個 UML 2.0 的專案。下圖3即是 Borland Together 的操作畫面。

圖3、Borland Together 的操作畫面

跟 RSA 不同，Borland Together 儘可能地讓操作介面與先前的版本類似。針對每一張不同類型的 UML Diagram，其所可以使用的工具都不同，該工具列如上圖右方的「Pallets」繪圖模版。

另外跟 RSA 類似的，則是在 Borland Together 中，同樣地也只支持 UML 2.0中的九張圖(如上圖左方框起來的部分)，Package Diagram、Object Diagram、Interaction Overview Diagram 以及 Timing Diagram 都不能直接由 Borland Together 中選取。

如同前面所說，Package Diagram 以及 Object Diagram 都可以使用 Class Diagram 來繪製，相同地，在 Borland Together 中你也可以利用 Class Diagram 來繪製這兩張圖。

至於 Interaction Overview Diagram 以及 Timing Diagram，則在 Borland Together 中並沒有辦法繪製。

大體而言，Borland Together 在 UML 2.0 的支持上主要是缺少了上述的兩張圖；再就實際的操作來說，Borland Together 延續了過往 Together 的操作方式，因此，對於Together舊有的用戶來說，不會造成太大的困擾。

此外，Together 在 Sequence Diagram 與 Communication Diagram 的互轉上，提供一個很有趣的機制，就是你可以根據一張相同的 Interaction Diagram，指定利用「Sequence Diagram」或是「Communication Diagram」來呈現，這是一個非常有趣的想法，更體現了這兩張圖是同一個實作的不同觀點的這個看法。

至於若要根據 UML 產生 Source Code，則必須要採用不同的專案。如果要產生 Java 的程式碼，必須要選用「Java Modeling」專案，此時，當你在該專案中建立 Class 時，Together都會自動產生一個 Java Class，當該 Class 的屬性或是操作有所變動時，則會立刻反應到程式中。這一點和先前的 TogetherJ 是完全相同的。

此外，Together 仍然保有過去 TogetherJ 的重要功能，也就是可以利用 Sequence Diagram 產生 Implement 的程式碼，相同地，也可以由程式碼反轉回 Sequence Diagram。這算是 Together 的一大特點，也是其與其他兩個產品競爭的最大優勢。

3、Sparx Systems 的 EA(Enterprise Architect)

EA 是這三個軟件中最輕薄短小的。由於採用 Stand-alone 的 AP，因此安裝 EA 時不需要先安裝 JRE 及 Eclipse。

至於在 EA 中繪製 UML Diagram，則相對簡單的多，由於 EA 本身就是繪製 UML 的工具，因此，你只要在 EA 中新增一個專案，其自然就會把所有 UML Diagram 要繪製的相關環境準備好。下圖4就是 EA 的設計環境。

圖4、EA 的操作畫面

和 Eclipse 的操作相類似，在 RSA 的操作畫面中，左邊是專案區，右邊則是所有可以使用的工具區。

EA 的操作介面和前面的兩個軟件有相當大的不同。最主要的原因是前面兩個軟件都是建構在 Eclipse 的基礎下，因此，其基本的操作會受到 Eclipse 的影響；而 EA 本身則是一個獨立的程式，因此，其操作的方式自然可以自行去設計。

如果開發人員熟悉像 Delphi、Visual Studio 或是 Borland 等IDE開發工具的話，會發現EA的操作環境和這些工具非常類似。在整個開發環境中，右方是工具區，左方則是整個Project相關的各種不同的視界(View)。

在 EA 中，所有的 UML 圖形將會放置在 Project View 中。和 Togethe r類似的，當你指定到一個特定 Type 的 Diagram 時，左方的 Toolbox 會停留在該 Diagram 對應的 Pallet 上，這在操作上是非常方便的。

接著看到對 UML 2.0 的支持上。相同地，你可以看到圖4中央框起來的對話框，那就是在 EA 中可以支持的 UML 2.0的Diagram。

除了 RSA 及 Together 所支持的那九張 Diagram 外，EA 另外也支持剩餘的四張 Diagram；除此之外，EA也另外支持非標準的 Analysis Diagram(Eriksson-Penker Business Extensions，台灣俗稱魚骨圖)。因此，若單從對 UML 2.0 的支持來說，EA算是最完整支持UML 2.0的工具。

不可避免地，我們也必須要談到 EA 中對於 Sequence Diagram 與 Communication Diagram 的互轉，這方面 EA 並沒有提供任何的功能允許這兩張圖彼此互轉，這算是EA中比較弱的一環。

接著看到 EA 對於 MDA 的支持。在 EA 中，這個部分做的非常彈性，開發人員可以利用 Script 的語法自行定義自己的 Transformation Rule。在 EA 中則提供 C#、EJB、Java、DDL、XSD 以及 Web Service等標準的轉換機制，讓開發人員可以將同一個 PIM(Platform-Independent Model) 的 Model 轉換為各種不同平台的 PSM(Platform-Speficic Model)。

至於程式的雙向工程，EA 則支持了包括 C#、VB、VB .NET、Java、C++、Delphi 及 PHP 等各種不同的程式語言。就單一產品而言，在程式語言的支持度上，EA 算是這三個工具之中最多元的 (RSA只支持Java及C++；Together只支持Java)。

至於和 IDE 工具的整合上，由於 EA 是一套 Stand-alone 的應用程式，因此在對於 IDE 工具的支持上不如 RSA 與 Together。

對UML 2.0支持的綜合評比：

有關這三套軟件在 UML 2.0 的支持上，我們將以下表2 來進行分析。

文件產生機制(Document Generator) 比較

對於開發人員來說，繪製設計圖以及進行程式寫作並非最繁重的工作，因為這是身為一個軟體開發人員勢必要做的事，但是，要將軟體的設計圖以及程式碼製 作成開發的文件，往往會造成開發人員的重大困擾。這並不是因為這些文件不重要，或是開發人員不重視，而是因為要在設計工作進行的過程中，隨時去注意文件的 格式或是內容，往往會讓設計人員的思緒受到影響。正因為如此，使用一個好的UML工具，幫助開發人員能夠利用工具產生開發文件的功能，才會成為評估UML 工具是否合格的重要評斷標準。那麼，究竟要如何才能夠評估一個UML工具是否有足夠的能力產生開發文件呢？大致可以從以下幾個部分來進行評估：

• 文件所能夠支援的格式有多少？
• 是否可以客製化為開發團隊所適用的格式？
• 製作文件所需要花費的Effort有多少？

以下我們將針對這幾個部分，分別來探討。

1、IBM RSA：

RSA 基本上與 Rose 相當類似，其所能夠支持的文件類型相當有限，主要是 PDF 與 HTML，下圖5即是 RSA 產生文件的操作畫面(以產生 PDF 為例)。

圖5、RSA 產生設計文件的操作畫面

基本上，RSA 所能夠產生的相關設計文件其實也只有兩種，同時，開發人員也不能夠直接去建立該設計文件的 Template，因此，RSA 在設計文件的支持上是非常薄弱的。

在 RSA 的前一個版本中，IBM提供另外一個產生開發文件的工具 – Rational soDa，但是該產品最後發佈的版本是在 RSA Release 之前，因此，該版本是否有支持 RSA 仍在未定之天。不過單就 RSA 而言，其產生開發文件的功能實在是過於陽春，這是不爭的事實。

2、Borland Together：

延續上一個版本的特色，Borland Together 在製作開發文件上仍是相當簡便。其主要仍是利用 Template 的方式來產生文件。下圖6即是 Together 產生開發文件的操作畫面。

圖6、Together 的產生開發文件的操作畫面

而 Together 在產生文件的機制中，最讓人激賞的是其可以產生的文件格式多達五種，除此之外，其 Template 的設計也非常具備彈性，下圖7即是 Together 製作 Document Template 的製作畫面。

圖7、Together 的 Document Template 製作畫面

開發團隊除了使用 Together 所提供的 Template 之外，也可以依據團隊的需要自行製作自己的 Template，這在整個文件製作的彈性上，可說是非常完整。當然，針對之前的 Togethe r開發團隊來說，新版的 Togethe r仍然可以使用舊版所設計的 Template，在這一點上，Together 也勝過 RSA 許多。

3、Sparx Systems的EA：

EA所能夠製作的文件型態，主要是 HTML 與 RTF 格式。下圖即是 EA 的 RTF 開發文件的產生畫面。

圖8、EA 文件製作的操作畫面

EA 製作文件的方式和 Together 非常類似，也是利用 Template 的方式來產生文件，不過不同的是 Sparx Systems 發揮他們的特色，提供了多種預設的 Template，讓開發人員一方面可以直接使用這些 Template，另一方面也可以透過 Copy Template 的方式來製作自己的 Template，下圖9即是透過 EA 的預設 Template 所製作的某個開發團隊的 Template 的設計畫面。

圖9、EA 的 Template 製作畫面

相同地，EA 的最大特色就是簡單。因此，EA 的 Document Template 所採用的設計方式是「WYSWYG」(What You See is What You Get) 的方式，對於開發人員來說，利用這種方式來進行設計，會相對簡單許多。不過與 Togethe r提供多種的 Document Type 相比，EA所提供的 Document Type 就陽春的多。

文件製作的綜合評比：

相同地，我們利用前面所說的三個重點來對這三個工具做一個評比，評比的結果如表3。

表3、對於文件製作的綜合評比

結論：

本文的目的主要是希望讀者能夠透過筆者對於這三套軟件實際操作後的心得，瞭解這三套軟件各自的優缺點，並且能夠根據讀者各自的需要，透過成本-效益的分析，選擇一套最適合自己開發團隊的UML工具。

事實上，除了上述的幾個面向外，讀者在實際選擇UML工具時，仍應該考慮以下幾個不同的面向，包括：專案管理上的難易度、團隊開發平台的支持、需求蒐集的面向以及測試機制的支持….等。 不過由於篇幅的關係，我們只能夠把此次的主題放在「UML 2.0的支持」以及「文件製作的機制」上。