本文是關於使用工業標準 UML 對 XML 應用程序建模的系列文章的最後一篇。上一期（請參閱 參考資料）留下了一個問題：如果 UML 模型和 XML 詞彙表之間存在多種可能的關係怎麼辦？本文進一步昇華了貫穿本系列文章的一個主題：建模是出於特定目的而對現實的簡化。
您 已經看到，我提倡根據項目需要採用實用靈活的方法。本文將討論還沒有解決的幾個問題，以便幫助將這些技術應用於您的環境。通過目前介紹的樣式表例子，只要 再有一個建模工具（如 IBM® Rational Rose®），就可以很容易地採用與業界兼容的方式對 XML 項目進行建模。
前面幾期文章曾多次提到，模型不是憑空而來的，建立模型是爲了服務於特定的目的。模型是現實的某些方面的簡化表示，通過這種簡化分析其背後的現實就更容易了，從而最終能夠更好地理解它。
對 於本系列文章而言，現實就是 XML 詞彙表或者 Web 服務。不可否認，這些本身已經就是抽象的現實了。但如果您曾經閱讀過 XML 模式文本，很快就會明白爲何需要簡化了。（有些繞彎子的）模式語法造成的紛亂迫切需要進行簡化。UML 最明顯的好處之一是，作爲一種圖形化的語言比標記更容易閱讀。另一個好處是 UML 提供了更具綜合性的視圖，只要看一眼模型就能大致瞭解類的數量及其相互關係的複雜程度。無論如何，UML 省略了很多底層的綜合細節，如名稱空間前綴、本地元素和全局元素，以及一個概念是元素還是屬性。
理想情況下，建模可以幫助更好地理解應用程序，從而創造出更加適用的 XML 詞彙表或者設計更加強大的 Web 服務 API。
簡 化到何種程度纔算適當呢，這與應用程序的特殊性以及精化模型的方式有關。前面已經提到，建模不是一蹴而就的事（除了那些最簡單的應用程序）。 一般來說，建模從一次非正式的會話開始，期間可以收集到模型中基本的定義和最簡單的關係。然後要經過一系列的評審會議對模型進行精化。通過不斷的迭代逐漸 形成更加正式、更加完整的模型（一般要從白板上轉移到建模工具中）。最後，UML 模型轉化成 XML 模式，這是 XML 詞彙表非常正式的描述。或者模型被處理成 WSDL 文件，同樣是 Web 服務的正式描述。也可用同樣的模型生成 Java 類。
看一看最後一個階段：UML 模型被處理成更加精確的 XML 模式。您已經看到，如果按照一種非常簡單的方法，這一步令人喫驚地容易。很多 UML 建模工具（如 IBM Rational Rose）按照 UML 元模型的定義來存儲模型。
簡而言之，UML 元模型就是表示 UML 模型的一組類。從註釋到包，包括類本身，UML 中的每個概念都有一個元類。對象管理組（Object Management Group，OMG）已經標準化了 XML Metadata Interchange (XMI)元模型的 XML 表示。 XMI 允許 XML 開發人員訪問模型。事實上，我應該說“一定程度上的標準化”，因爲不同的建模工具（甚至同一工具的不同版本）可以按照不同的方式解釋 XMI。在實踐中，這種差別非常細微，可以在樣式表中解決。
不 管怎樣，要從 UML 模型生成 XML 模式，只要確定 UML 元模型中的哪個概念和哪個 XML 模式標籤對應就可以了。比如，顯然 UML 類應該轉化爲 XML 元素。因爲 UML 元模型保存在 XML 中，生成模式就只需要編寫一個 XSLT 模板，讓其匹配所有的 UML:Class 實例，並將其轉化爲 xs:element 。
實現 逆向樣 式表從 XML 模式生成 UML 模型也是可能的（並且常常是人們所期望的）。如果需要把標準詞彙表結合到您的設計中，這種技術非常方便。 這種詞彙表很少以 UML 的形式提供，通常是 XML 模式。只要有適當的樣式表，對其進行逆向工程轉化成模型用不了多少時間。
編寫與 XMI 元素相匹配並將其轉化爲 XML 模式元素的樣式表，從概念上講很簡單。我在以前的文章中給出的樣式表既不是很長也不是特別複雜。
至少理論上是這樣。在實踐中如果不夠謹慎的話，情況也可能失控。首先，XSLT 編碼可能非常棘手（雖然不會出現重大的變化）。回顧一下 上一期文章中介紹的樣式表，特別要注意 UML:Class 的模板。這個模板遠遠比不上我寫過的那些最複雜的 XSLT 模板，但也不像上面所說的那樣簡單。因此在嘗試解決這個項目之前一定要磨練您的 XSLT 技巧（或者打開我的樣式表看看）。
其 次，更爲重要的是，確定哪個 UML 概念與哪個 XML 概念相匹配也不一定很簡單。上一期文章中曾經指出，構造型和標籤可以作爲擴展 UML 模型的工具，以便支持在 UML 中沒有等價物的 XML 概念。構造型和標籤都很有用，如果您對通過構造型和標籤限制 XML 模式的每個方面感興趣，請堅持下去吧！
要記住，按照定義模型是一種簡化，因此模型（即使是精化的模型）不包括所有的實現細節是完全合理的。很多方面最好放在模型之外，留在樣式表本身中。
  |
|
W3C XML Schema Recommendation 非常複雜，可能不需要考慮它的每一個細節，因此，確定所需的一組特性子集是合算的，它將用於給定項目。不要爲推薦標準中的其他內容浪費時間。
應該包含什麼，不包含什麼？不幸的是，對於這個問題我沒有特定的答案。最好的經驗是 包含那些對於項目很重要的方面而忽略其他方面。當然，這就留下了一個問題，即確定什麼對於您的項目是重要的。
對於多數應用程序而言，都希望隱藏全局元素和本地元素以及元素和屬性之間的區別。實際上，更重要的是定義必要的數據字段，而不是決定這些字段作爲元素還是屬性。不管怎麼樣，元素和數據都是存儲數據的字段。
雖然存在例外情況，元素和屬性之間的差別通常是實現上的細節，對於設計者而言，在很大程度上是無關的細枝末節。因此，雖然使用不同的 UML 概念（可能還包括構造型）來建模元素和屬性可能很有吸引力，但我不建議這樣做。
爲何要忽略元數和屬性之間的差別呢？因爲它搞亂了模型，只增加了很少的有用信息。比較圖 1 中的三種模型：
圖 1. 三種 UML 模型
按 照逆時針的順序，第一個模型（左上角）是用構造型標記元素。第二個模型（下方）用 UML 屬性表示 XML 屬性，並把 XML 元素建模爲聯繫（不同的 UML 概念標記 XML 中的差異）。最後一個模型（右上角）沒有做這麼詳細的區分。哪個模型最清楚？要知道，這是一個非常簡單的模型。設想如果每個用例中有數十個類，哪一種模型 更容易閱讀呢？打印出來哪一個用的紙張最少呢？顯然最後一個模型可讀性最好。
將 UML 圖看作用戶界面是合理的。只要可能，就應該減少混亂，用明確可讀的方式對信息編碼。
顯然，如果要從 UML 模型中提取信息，應該能在其他某個地方使用。這就是 XSLT 樣式表所起的作用：不僅要在 UML 和 XML 之間轉換，還必須事先保證轉換有效進行的規則。前面的文章中所介紹的樣式表都遵循下面這些原則：
- 從不創建 XML 屬性。大小可能不同，但是元素可以編碼此類項目的所有信息。
- 將 UML 類映射爲全局元素，將 UML 屬性映射爲本地元素。這樣做主要是爲了避免名稱衝突：如果兩個類具有相同的屬性，映射爲全局名可能會造成衝突。
這兩條簡單的規則足以將模型中省略的所有信息加上。另外一個好處是，如果我決定改變這些規則（比方說不再使用本地元素），那麼需要改變的只有樣式表，而不必改變模型。如果這些細節寫入模型，那麼模型也需要更新。
您可能不同意我對屬性所持的觀點。雖然屬性在這個特定的應用程序中不重要，但是您的應用程序可能不同。不同的項目強調 XML 語法的不同方面：
- 電子商務項目往往強調類的結構，不太關注具體的 XML 語法。
- 工業組織往往在類層次結構方面大量投資，努力實現標記的重用（在不同的上下文中重用元素）。
- 和實際數據相比，商務人員往往更關心業務流程。
- 出版項目往往擔心硬編碼 XML 標記的易用性，因爲作者可能需要手工編寫 XML 文檔。
因此如果屬性對您的項目至關重要，則將其在模型中表示出來。同樣要把 UML 圖看作是 XML 詞彙表的界面，當然不希望 UI 隱藏重要的方面。模型只是一種工具，沒有必須顯示什麼不顯示什麼的硬性規定。要做的就是捕獲應用程序需要的所有信息，如此而已。
可以看出，我不贊成某一種標準映射適用於所有 XML 應用程序的說法。XML 應用程序千差萬別，不可想像有一種映射到處都適用。
顯然，XML 的 UML 表示中有 95% 對所有項目都是通用的，您可以使用我提供的那些樣式表作爲一個很好的起點。這種情況和 SQL 代碼生成類似，常常需要微調數據庫的代碼生成。
爲了最大限度地適應項目需要，雖然我鼓勵調整 UML 到 XML 的映射，但是最好在 UML 框架之內調整，沒有必要脫離標準的 UML。
這裏有一個例子。圖 2 是我經常看到的一個模型，但這種做法是不好的。具體而言，問題出在 make-element 和 namespace-uri 屬性。
圖 2. 糟糕的建模方法
推想起來，地址並沒有 make-element 屬性，該屬性只不過是暗示樣式表生成給定的語法。這個屬性表示的信息和地址無關，編碼的是地址的 XML 編碼信息。這樣做既危險，又毫無意義。
危險是因爲歪曲了 UML 屬性的定義。屬性應該提供它自己的類的信息，而不是 XML 語法的信息。這樣的模型無法移植，讀者難以理解，而且可能造成嚴重的維護問題。
此 外，這樣做也毫無意義，因爲 UML 提供了擴展機制（構造型和標籤）來應付這類要求。如果需要標識特定類型的類或者增加類的元數據層信息，就必須使用 UML 擴展。再說一次，爲了最大限度地適應項目需要，雖然我鼓勵對 UML 到 XML 的映射進行調整，但強烈建議以標準方式進行調整。
|
|
我 相信本系列文章使您對 XML 應用程序的 UML 建模有了更深的理解。使用 UML 建模 XML 應用程序已經越來越引起人們的興趣，僅僅因爲 UML 模型可以在 Java、C++ 和其他語言之間共享。我已經分析了支持對 XML 應用程序建模的工具（UML 元模型、XMI 和 XSLT）。使用適當的建模工具，再加上我提供的樣式表，就可以開始了。
如果您對本系列文章有什麼建議或者問題，請參與論壇中的討論（請參閱 參考資料）。
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文.
- 回顧 Benoît Marchal 撰寫的本系列文章的以前各期：
- 第 1 部分討論了 UML 和 XML 模式之間的關係（ developerWorks，2004 年 3 月）。
- 第 2 部分介紹了 UML 元模型和 XMI，後者是基於 XML 的模型交換規範。作者然後探討了如何從元模型映射到 XML Schema（ developerWorks，2004 年 5 月）。
- 第 3 部分探討了擴展 UML 語言的工具：構造型和標籤（ developerWorks，2004 年 6 月）。
- 完整的 UML 元模型，請參閱對象管理組織（OMG）站點上的 UML 規範。
- 探索 IBM Rational Rose，這是一種領先的 UML 建模產品。在 developerWorks的 Rational專區可以找到大量 Rational 和 UML 資源。
- 通過 ArgoUML和 Poseidon for UML (Community Edition)研究本系列文章中介紹的技術，這兩種免費建模工具都可導出 XMI，雖然和 IBM Rational Rose 相比侷限性較大。
- 閱讀 Mike Padilla 撰寫的“ Strike a balance: Users' expertise on interface design”（ developerWorks，2003 年 9 月），它提供了用戶界面設計方面的建議，我認爲大多數都適用於 UML 和 XML 之間的映射。在可選擇的建模工具範圍之內，您也許會希望儘量簡化手頭的任務。
- 研讀 Alan Cooper 所著的 The Inmates Are Running The Asylum 一書，這是關於用戶界面的最佳圖書之一，也是最棒的計算機科學圖書之一。
- 在 developerWorksXML 專區 可以找到數百篇 XML 資源，其中包括 Benoît Marchal 使用 XML 專欄以前各期的文章。
- 在 developerWorks Developer Bookstore可以找到各種關於 XML 的書籍，其中包括 Benoît Marchal 所著的 XML by Example 。
- 瞭解如何才能成爲一名 IBM 認證的 XML 及相關技術的開發人員。