[1.1]XMI 與UML結合開發公司專屬應用程式中業務模型

隨著 XML 成為主流，人們越來越關心 XML 應用程式的設計。更具體地說，許多組織希望把 XML 應用程式的設計與他們的其他應用程式設計結合起來。採用一種通用的方法——或者至少一組通用的工具——是值得考慮的方向。

就 XML 而言，設計活動主要圍繞著資料建模。事實上，因為 XML 是一種標記語言，僅僅涉及到資訊的組織——這一點和其他語言是不同的，比如 Java 同時處理資料建模（類繼承）和資料操作（方法）。

使用 XML 專欄新的系列文章將探討使用 UML 建模工具設計 XML 應用程式，如 IBM Rational Rose 和 XSLT，這是其中的第一篇。在這篇介紹性的文章，我將討論資料建模的基本原理，並介紹在後面三篇文章中將用到的技術。

資料建模

簡明牛津詞典（牛津大學出版社，2001）關於名詞“model”至少有 7 種以上的定義。對於本專欄系列文章而言，下面的定義最合適：“系統及其他的簡化（通常是數學化的）描述，以便協助計算和預測。”這個定義中有三個關鍵詞：簡化、描述和協助。

按照這個定義，模型是關於系統的描述。這一論斷很重要，模型不是系統本身，而是系統的形式化表示。具體到 XML 而言，系統由按照特定詞彙表編碼的文檔組成。

這一定義的第二方面說模型是一種簡化的表示。它不像所建模的系統那麼複雜或者豐富。許多系統都設計用於解決複雜的問題，因此天生就是複雜的。比如，看一看 DocBook 這類複雜的詞彙表：它設計用於出版技術資料和文檔（其中 Linux 文檔就是用 DocNook 出版的）。因為技術書籍和文檔很複雜， DOcBook 也很複雜

此外，人們能夠同時處理的資訊量是有限的。多數人在解決一個複雜的問題時，都喜歡（或者需要）把它分解成更小的、更容易管理的問題。建立模型就是為了滿足這種需要。模型通過只公開系統的某些特定方面來簡化複雜的系統。

定義中最後一個關鍵詞是協助。模型不是憑空建立的，而是服務於非常具體的目標，它只是更有效地實現特定目標的一種工具。目標從來不是建立模型，而是處理一個系統。

目標的操作特性與前面所述的簡化密切相關。簡化意味著要選擇系統中需要包括的那些成分，和應該拋開的那些成分。選擇受模型的目標所控制，比如試圖協助的計算和預測。

簡化和建模

無論如何強調模型是實際系統的簡化都不過分。同樣，除非將其分解成更小的、更簡單的成分，要解決一個複雜的系統是不可能的。在實踐中，一個模型常常是不夠的，複雜的系統可以用從簡單到複雜的多個模型表示。

建模的過程可以從傳奇般的餐巾紙（一塊白板或者裁好的一遝紙是很好的替代品）上的系統草圖開始。第一個模型通常很粗略，忽略了系統的多數方面，只有設計者認為重要的少數方面，可能因為這些方面特別複雜或者是系統的關鍵特徵。

這個粗略的模型將被細化成更加精細、更加複雜的一個或多個模型。每次迭代都從實際系統中引入更多的成分，直到所有相關的方面都引入到模型中。最終，您將達到資料模型的實現階段，並定義系統可以管理的所有方面。

對於 XML 而言實現將一個 XML 模式，其他的選擇包括 DTD、 RELAX NG 或者 WSDL儘管這些實現之間存在技術上的差異，但在本系列文章中我將把它們看作是 XML 模式的變體。

業內對模型與 XML 模式之間的關係有兩種不同的觀點。一些作者在設計模型和 XML 模式之間划了一條清晰的界線，設計模型通常是 UML 模型或實體-關聯式模式，被認為是抽象的，而 XML 模式則被認為包含大量的實現細節。這種區別有助於清晰地劃分建模活動與實現活動。建模通常由業務分析人員完成，而實現則是技術人員的職責。這種工作的劃分模仿了典型應用程式開發中分析人員與開發人員之間的分工。

雖然我認為這種劃分對編程而言是合理的，但不能保證也適用於 XML 建模——這使我傾向於對這種關係的第二種觀點。XML 模式是文檔的模型，您將在下一篇文章中看到，它和良好的 UML 模型在複雜程度上並沒有顯著的區別。毫無疑問，XML 模式包含大量的技術資訊，但是描述同樣多的技術資訊的 UML 模型也並不少見。因此，我傾向於把 XML 模式看作是從高層模型到底層模型的模型連續統一體中的一部分。

如果安裝了輔助建模工具——我將在本系列的其他文章中介紹——把模式僅僅看作是另一種模型尤其合適。

簡化和圖形

建模中使用的最有效簡化方式是圖形。與一長串複雜指令相比，人們發現大腦更容易處理圖形。多數建模方法都建立在可視化語言的基礎上，如 UML、實體-關係圖或者流程圖。

具體到 XML 模式，用什麼組成最佳的可視化語言存在兩種不同的觀點。一種方法是採用 XML 專用的語言，另一種則是用更一般的建模語言。XML Spy 或 TurboXML（請參閱參考資料）這類產品使用自訂的圖形樹表示處理 XML 模式。一種可視化呈現可能類似於圖 1：

圖 1. 可視化 XML 結構

為此也可以採用標準的建模語言，如 UML。圖 2 是類似於圖 1 的 UML 模型：

圖 2. 建模 XML 的 UML

每種方法各有自己的優缺點。XML 專用的符號完全與 XML 的結構匹配，很容易標誌 XML 順序、XML 選擇、元素和屬性等等。也可以用簡單的、自然的方式規定所有的技術資訊。直到最近，許多 XML 應用程式設計者還推薦使用這種方法，因為它簡單而有效。

付出的代價是建模以及工具常常不能與其他的開發工作很好地結合。雖然這種方法仍然適用於小型的 XML 項目，但是沒有很好的伸縮性。這種方法也很難用於結合了 XML、Java、Web 服務和 SQL 的大型項目，因為團隊中的其他人可能使用的是 UML。

有兩個因素使得 UML 最適合於中型和大型的項目：

1. UML 應用於 Java、C++、Python、PHP、SQL、Web 服務以及差不多任何其他部屬技術。它的統一性減少了培訓的需要（一種語言適用於每個人），而且更容易在團隊中共用設計。
2. UML 圖可以根據需要顯示更多的或較少的資訊，因此可以使用同一個工具準備多種複雜層次的模型。

UML 主要的不利之處在於在處理建模的底層方面時不很友好。比如，在樹中對一組元素排序很容易，但在 UML 中就需要很多技巧。

UML 和 XML

我計劃在以後幾篇文章中詳細討論這個話題。現在，只要指出在 XML 模式和 UML 模型之間可以建立多種映射就足夠了。UML 支援多種圖，包括使用案例圖、包圖、順序圖和活動圖表。

這裡最適合的是類圖，類圖表示物件導向的資料模型。

圖 3 是表示 person 的非常簡單的 UML 模型。它包括兩個類，一個代表 person 的基本資料（“person”），另一個代表 person 的“address（地址）”。矩形是表示類的符號，被分成三個部分：類名、屬性以及方法。因為我們要建模的是資料而不是行為，可以忽略方法部分。

圖 3. person 的 UML 模型

類之間的關係用聯絡表示。在模型中，聯絡用一條直線表示。直線可以使用串連符修飾以進行區分。比如，圖 3 中的實心菱形表示這裡是組合關係——換句話說，address 類的執行個體只能存在於 person 類的上下文中。

注意，把 UML 結構映射到 XML 可以有多種不同的選擇，其中 UML 屬性就是一個很好的例子。在 UML 中，屬性是附加到類中的欄位。在 Java 語言中只有一種合理的映射方式：屬性變成一個類變數。相反，在 XML 中屬性可以映射成子項目或者真正的 XML 屬性。我將在以後的文章中繼續討論這個話題。

模式派生

可以嘗試不同的方法繪製 UML 模型：

• 可以將其畫在紙上或白板上。
• 可以使用 SmartDraw 或 Omnigraffle 這樣的向量繪圖工具。
• 可以使用建模工具，如 IBM Rational Rose .

除了最簡單的模型之外，您可能更願意使用建模工具。初看起來，建模工具只不過是美化的繪圖工具，但實際上提供了更多的功能。建模工具能夠理解模型，因而可以為設計人員提供大量協助。比如，在向圖中增加類時，它可以自動地畫出這些關係。

自動派生

如前所述，我認為 XML 模式只不過是一種詳細模型的特殊呈現。因此，從 UML 模型自動派生 XML 模式是很重要的。

看著 UML 模型，將其編碼成 XML 模式非常耗時而且容易出錯。您可能忽略一些元素或屬性，也很容易把關係搞錯。所幸的是，只要在 UML 結構和 XML 模式語句間建立一對一的映射，這個過程很容易自動化。

您可以找到用於從模型自動派生模式的許多工具，其中包括：

• Eclipse 建模架構（EMF），原來稱為 IBM XMI Toolkit
• EMF 包括一個代碼產生器從 UML 模型派生 XML 模式。
• IBM Rational Rose，它所含的指令碼語言 RoseScript 可以處理 UML 模型，因而能將其儲存為 XML 模式。
• Velocity，來自 Apache Jakarta 的一個項目，是用於從 UML 模型產生代碼的模板引擎。
• hyperModel 是專門用於從 UML 產生 XML 的圖形化工具。
• Poseidon for UML 具有內建的代碼產生功能，很容易定製為產生 XML 模式。
• Codagen 是一個 UML 工具，提供了完善的代碼產生功能。

本系列文章中推薦一種基於 XSLT 和 XML 中繼資料交換（XMI）的解決方案。XMI 是一種標準格式，可用於把 UML 模型派生 XML。它最初是為了在不同的工具之間匯出/匯入模型而設計的，因為這裡要處理 XML，因此可以使用 XSLT 處理。

根據我的研究，由於以下原因使用 XMI 與 XSLT 非常有利：

• XMI 是一種工業標準，得到所有主要建模工具的支援。任何建立在 XMI 之上的模型都可以使用這些建模工具。
• XSLT 是有效表達轉換的一種語言。它有很多結構使其非常適合這項任務。
• 所有主流平台上都可以使用 XSLT，因此選擇的餘地很大。
• 同樣的技術很容易擴充到 WSDL 和其他 XML 語言。

我還有另一個標準，可能對您無關緊要。我主要從事電子商務，因此處理的模型是多家公司的協作項目。不同的公司可能採用不同的工具，因此在協作項目中不能要求在整個團隊中使用一種私人產品。因為 XMI 是一種工業標準，建立在 XMI 上的解決方案可以在整個團隊中很好地工作。

圖 4 說明了這個過程。我編寫一兩個樣式表從 XMI 文檔（如 UML 模型）派生 XML 模式。

圖 4. 派生模式

從 XML 模式到 XMI。這種樣式表在處理沒有使用 UML 建模的已有模式時很有用。

結束語

本文是新的系列文章的第一篇，我回顧了文檔建模背後的原理，並探討了如何在 UML 中建模 XML 模式。更重要的是，我介紹了從 UML 模型自動產生 XML 模式的工具。自動產生可以使用 XMI 與 XSLT 樣式表。下一篇文章中將介紹這種樣式的一個例子。

參考資料