隨着 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：
爲此也可以採用標準的建模語言，如 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 中就需要很多技巧。
  |
|
我計劃在以後幾篇文章中詳細討論這個話題。現在，只要指出在 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 樣式表。下一篇文章中將介紹這種樣式的一個例子。
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文.
- 請參與本文的 討論論壇。（您也可以單擊本文上部或底部的 討論來訪問論壇。）
- 閱讀 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 服務。
- 研究 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 資源。
- 在 developerWorksXML 技術專區 可以找到更多的 XML 資源，包括 Benoit Marchal 使用 XML 專欄以前的所有文章。
- 瞭解如何才能成爲一名 IBM 認證的 XML 及相關技術的開發人員。