使用 XML：UML、XMI 和代碼生成，第 1 部分

Benoit 開始撰寫關于 UML 和 XML 模式開發的一系列新文章，這是其中的第一篇，討論了使用 UML 對 XML 建模的動機。他還介紹了 XML Metadata Interchange（XML 元數據交換，XMI），并簡要描述了從 UML 模型自動派生 XML 模式的策略。請您在本文的討論論壇上與作者及其他讀者交流您的想法。（您也可以單擊本文頂部或底部的討論來訪問論壇。）
隨著 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 模式則被認為包含大量的實現細節。這種區別有助于清晰地劃分建?；顒优c實現活動。建模通常由業務分析人員完成，而實現則是技術人員的職責。這種工作的劃分模仿了典型應用程序開發中分析人員與開發人員之間的分工。

雖然我認為這種劃分對編程而言是合理的，但不能保證也適用于 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 最適合于中型和大型的項目：

UML 應用于 Java、C++、Python、PHP、SQL、Web 服務以及差不多任何其他部屬技術。它的統一性減少了培訓的需要（一種語言適用于每個人），而且更容易在團隊中共享設計。
UML 圖可以根據需要顯示更多的或較少的信息，因此可以使用同一個工具準備多種復雜層次的模型。
UML 主要的不利之處在于在處理建模的底層方面時不很友好。比如，在樹中對一組元素排序很容易，但在 UML 中就需要很多技巧。

UML 和 XML
我計劃在以后幾篇文章中詳細討論這個話題?，F在，只要指出在 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 建?？蚣埽‥MF），原來稱為 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 樣式表。下一篇文章中將介紹這種樣式的一個例子。

參考資料

請參與本文的討論論壇。（您也可以單擊本文上部或底部的討論來訪問論壇。）

閱讀 Cameron Laird 的 XMI 入門文章，“XMI 與 UML 合力推動產品開發”（developerWorks，2001 年 10 月）。

看一看 Donald Bell 的“UML 基礎：統一建模語言簡介”（developerWorks，2003 年 6 月），這是一篇淺顯易懂的 UML 文章。

請訪問 DocBook.org，這是 DocBook 的資源站。DocBook 是一種圖書出版的常見詞匯表，讀一讀您就知道圖書實際上是多么復雜的一個系統。

進一步了解 RELAX NG，有人建議用它來代替 XML 模式。它有一些有趣的特性，在市場上得到了廣泛的認可。如果您使用它，請閱讀 Nicholas Chase 的教程“理解 RELAX NG”（developerWorks，2003 年 12 月）。

使用 WSDL 描述 Web 服務。

看一看 XML Spy 和 TurboXML，這是兩種使用專門可視化語言的 XML 模式編輯器。

研究 SmartDraw 和 Omnigraffle，這兩種繪圖工具有時候用于繪制簡單的 UML 模型。雖然適用于小型項目，但不支持 XMI 而且不夠靈活。

探索模板驅動的 Jakarta Velocity 和 Asbot 代碼生成器。

使用 Eclipse Modeling Framework 和 hyperModel 從 UML 模型生成代碼（包括 XML 模式）。

考察 Poseidon for UML 和 Codagen，具有代碼生成功能的 UML 建模工具。

探索 IBM Rational Rose，領先的 UML 建模產品。您可以在 developerWorks 的 Rational 欄目找到大量的 Rational 和 UML 資源。

在 developerWorks XML 技術專區可以找到更多的 XML 資源，包括 Benoit Marchal 使用 XML 專欄以前的所有文章。

了解如何才能成為一名 IBM 認證的 XML 及相關技術的開發人員。

關于作者
Benoit Marchal 是一位比利時籍顧問。他是 XML by Example, Second Edition 以及其他幾本 XML 書籍的作者。您可以通過 bmarchal@pineapplesoft.com 或者他的個人站點 www.marchal.com 和他聯系。