第三章 EAI 機制研究架構
從第二章的文獻探討中，可以大略清楚的知道 EAI 是一種機 制方法，和傳統的 Middleware 相似，主要的不同點在於 EAI 機 制重視在企業營運流程和資料交換兩者的整合。由圖 3.1 知道 EAI 機制是整合企業內部的老舊系統、網際網路應用、物件模式等應 用程式，使彼此的資料跟流程能相互共享利用。
圖3.1 EAI 整合應用系統示意圖
在這一章節中， 本研究針對企業應用整式整合中的 Message Brokers 中的兩個模組概念-Data Transformation 和 Business Rule 進行研究的設計架構。本研究以 XML 為整合資訊應用程式系統 的基礎，利用 XML 擁有標準化格式和方便傳遞資料交換等特性 來 做 企 業 內 部 本 身 資 料 交 換 和 營 運 流 程 作 業 溝 通 流 程 的 交 換 標 準。並將在第四章中提出客戶關係管理實例作進一步地探討。
老舊應
用系統 套裝應
用程式
Client/Server
應用系統 電子商務應用
Internet,www,Jav a
物件導 向程式
EAI
3.1 以 XML 為資料格式標準的考量
本研究將利用 XML 為資料交換格式的標準， 也就是將 XML 當成資料格式的標準，以方便 EAI 機制 系統 的整合跟應用。選擇 XML 為資料轉換格式標準，有以下幾點考量：
1. 跨平台功能： XML 具有可以整合多種異質的應用平台資 料功能 。目前 XML 可支援的語言有 Java Script、VB Script 和 Active script 等。基於可以整合多個應用平 台，我們可以 將其利用為整合文件維護的標準格式。
2. 內容彈 性且具 擴充 性：XML 的內容撰寫分別有 DTD、XML 和 XSL 等三份主要文件，主文為 XML 文件 可依不同的 DTD 文件的驗證而撰寫不同的 XML 文件內容，也因為 不同 XSL 文件的宣告而產生不同行事的呈現。對於資料的維護是有彈 性的，不因為某一資料的改變而改變內容資料的維護。
3. 嚴謹性且正確性的驗證：XML 文件透過 DTD 文件格式的 驗證具有正確地 XML 文件呈現 其具有嚴謹性且正確性也不 容懷疑。
XML 不是一個資料轉換標準的 API 介面，它只是一個種元語 言。我們要透過程式的開發來利用 XML 所建立的資料內容。XML 可以提供一些新的成效給企業在 IT 資訊應用系統的整合上。隨 著網際網路的成長 ，可見企業越來越重視 企業在 Internet 上面的 發展 ，紛紛希望從 網路上獲去利機和商機 。XML 可以讓企業在
利用網際網路時不必時時需要從後端或取所有的資訊，它將後端 資料寫入 XML 文件中， 當使用者需求資料時只需透過 XML 文 件即可得到需要的資訊和一班 html 格式要從後端資料庫 撈去資 料不同 ，這也是我們選擇 XML 在 EAI 機 制整 合上應用的原因之 一，且 經由 XML 可以適用於網路的功能我們也可以利用網路來 達到整合的目的。 相同的也因為 XML 可以支援多種應用系統平 台，而使得異質間的應用系統 整合可以透過 XML 達到整合資料 的目的。
3.2 EAI 機制概念
EAI 機制的概念並不像傳統的 Middleware 的解決方法是針對 單一應用程式之間作 API 的溝通介面；EAI 單純地將其一的應用 程式資料傳入，並透過 EAI Engine 的處理，再將處理過後的資料 傳入另一個適用應用系統之中。處理資料的功能就只單純地交給 EAI 機制去做，彼此相連的應用程式系統只要負責傳輸資料和接 收資料的工作就可以了。EAI 除了轉換資料格式以外，也將企業 營運流程的概念包含其中，並適當地將資料跟訊息傳遞到適用的 應用系統中。
EAI Engine 也就是一個 Message Brokers 模組的概念。Message Brokers 照字面上的翻譯也就是訊息的經紀人或是訊息當鋪的意 思，這樣翻譯或許不怎麼恰當，但是照字面解釋應是訊息整理的 暫存區域，也就是將原本的 raw data 整理處理之後在將其傳出給
其他應用系統應用使用。這樣的概念表示 EAI 不是個儲存訊息或 是資料的地方，而是利用傳入的資料轉變成另一個應用程式可用 的訊息。
Message Brokers 大 略 地 說 分 成 分 為 四 個 概 念 訊 息 路 線 制 定 (Message routing)、資料轉換(Data transformation)、企業營運規則 執 行 (Business rules implementation) 和 企 業 營 運 流 程 程 序 支 援 (Business process support)，如圖 3.2 所列【11】：
圖3.2 EAI-Message Brokers 四個概念
1. 訊息路線制定(Message routing)
傳遞在各個資訊系統和 Message brokers 之間的所有訊息。
這一個功能在 Message Brokers 裡扮演在不同資訊系統中制 定出傳遞訊息路線的功能。
2. 資料轉換(Data transformation)
資訊系統中所需要的資料本身的格式並不一定相同且其資
Message Brokers Business Process Business Rules DataTransformation Message Routing
Input Output
Message Message
料格式並不是資訊系統本身所能掌握處理的資訊。 所以，
Message Brokers 提供資料轉換的功能，期望各個不同的應 用程式能夠透過共同的資料格式介面而達到溝通的目的。
3. 企業營運規則執行(Business rules implementation)
企業營運規則是企業營運定義中重要的部分。企業營運規 則影響企業營運流程。Message brokers 通常會提供有 GUI 基礎的工具去設計簡單的營運流程。利用 GUI 容易地製作 規則，且也使得資訊系統更容易管理和維護。
4. 企業營運程序支援(Business process support)
Message Brokers 有責任去支援企業營運程序， 有 GUI 介面 基礎的應用程式就比較容易去建構這樣的營運程序。
本研究著重在探討 Data Transformation 和 Business Rules 這兩 個 EAI 機制的模組概念， 並利用 XML 作為企業內部營運流程作 業系統資料交換的標準。 本研究將分成兩個部分的研究架構，一 是利用 XML 的特性作為資料交換格式的標準，如圖 3.3 所示；
二 是 針 對 企 業 間 的 營 運 作 業 的 溝 通 流 程 作 業 做 適 當 的 改 善 設 計 並進一步地利用 XML 特性做交換標準的格式，圖 3.4 為詳細步 驟說明。
圖3.3 Data transformation 之研究方法
圖3.4 Business Rules 之研究方法 3.3 資料轉換概念
企業內部的資訊系統種類眾多，要使得資料在不同系統之間 的流通應用，就必須發展一套共通的資料格式，以方便資料在應 用系統之間的溝通運用。 但是，一但有了系統之間的溝通介面程 式之後，往往無法實際的運用於企業內部的應用系統作業，甚至 遇到系統或是套裝應用程式升級等問題，就又得重新開發新的溝
將資料 庫的 Tablea 名稱轉 成 DTD 的元素 名稱
欄位的 資料型 態長度 轉成 DTD 元 素宣告
欄位的資 料屬性轉 成 DTD 屬性宣告
利用屬 性內建 值表達 table、欄 位之間 的關連
利用 UML 語 言 分析企業間相 關的營運流程 作業並進一步 繪 製 成 UML 圖 形
利用 UXF 方法 將 UML 語 言 繪 製的圖形轉換 成 XML 文件
通程式介面，浪費成本也增加不必要的人力支出。
3.3.1 文件格式定義
XML 的 出 現 正 好 解 決 了 應 用 系 統 升 級 或 是 系 統 改 版 所 造 成 應用系統轉換資料介面程式重新撰寫的問題， XML 具有可擴充 性的結構化表示方法，可以針對不同資料型態製作發展各自的標 籤(tag)， 且 XML 的設計是根據 SGML 的制定簡化而來的，並且 XML 可以使用在網際網路上， 且廣泛地支援各種不同的應用程 式；在加上容易撰寫和編譯程式嚴謹等優點，因此本研究將使用 XML 來做企業應用程式之間資料交換的標準格式。
DTD 文件主要是用來驗證 XML 文 件 的 結 構 和 屬 性 是 否 正 確，所以，在複雜的企業內部資訊系統下利用 XML 作為溝通的 標準，最先要做的是在企業內部間採用相同的自製 DTD 格式，
確 保 不 同 的 資 訊 系 統 在 交 換 資 料 時 能 夠 擁 有 資 料 的 正 確 性 ， 圖 3.5 表示 DTD 和企業間應用程式的交流【9】。
網際網路的快速發展，和 XML 為 W3C 所制定之標準後，許 多系統供應商、企業體及標準組織等團體爭相推出以 XML 為資 料交換標準的電子商務架構。 但是，這些組織提出的 DTD 格式 可能只適用於特定的行業或是特定的工作內容，且有些架構對於 同樣的作業內容有較詳細的描述，但是某些架構則針對本身企業 的作業內容則不需要詳細的實體描述。所以單一架構的 DTD 格 式並無法滿足龐大的企業體內部交換資料的需求。企業和上下游
廠商採用不同的 DTD 標準，對於資料交換來說便要發展更多的 轉換程式，不僅浪費時間也浪費成本並增加維護上的困難。
Resume DTD Company DTD Person DTD Work DTD
圖3.5 DTD 的電子交換方式【9】
發展適合企業內部資料交換的 DTD 以不是件難事，企業發展 適用的 DTD，才能善用 XML 的方便性與正確性在交換資料上。
企業內部有很多的應用程式與複雜的文件資料格式，但是很難找 到一套共通的物件模型或是標準來做溝通。企業內部通常都是利 用資料庫儲存電子文件資料，因此，本研究將利用關連式資料庫 中各個 Table 之間的關連性，經由轉換的程序將其轉換成 XML DTD 文件。
3.3.2 關連資料庫轉換成 XML DTD
本 研 究 將 運 用 Buck Lee 所 提 出 的 方 法 論 ， 將 資 料 庫 中 的 Table 的關連轉換成 XML DTD。 在 Buck 的理論中有幾個特點
組織 企業
XML 資料來源
不同的使用 者
【21】：
1.將資料庫中的 table 名稱轉換成 XML 的 element(元素)。
2.將資料庫中的 columns 轉成 table element 的子元素並將資料 型態、長度和屬性表示成 DTD 的屬性類別。
3.找出資料庫中的關連並利用屬性內建表的屬性製作 DTD 之 間 element 的關連。
以上是基本的轉換方式，再加上一些變化則可以針對 Element Type 和 Attribute Type 延伸變化而去清楚地轉換關連資料庫的資 料。
Table Filed Data type Attribute NUM LongInt Primary Key FNAME String 32
LNAME String 32
HIRE_DATE Date Not NULL EMPLOYEE
TERM_DATE Date May be NULL EMP_NUM LONGINT Foreign key REVIEW_DAT
E
Date Primary Key PERF_REVIEW
REVIEW Text Not Null EMP_NUM LONGINT Foreign Key REVIEW_DAT
E
DATE May be NULL EFF_DATE DATE Not NULL COMP_CHANG
E
SALARY INT Not NULL 表3.1 關連資料庫說明範例
3.3.3 Buck 方法論的二個轉換模組概念 1. 資料類型模組(Modeling Datatypes)
傳統資料來源傾向有固定的資料型態。 XML 文件根本定義是 要擷取資訊從原本資料庫既有的格式中，並將原有基礎的知識保 留而不變化。 這一個’dtype’ 種元屬性被用來擷取資料型態的資 訊。而這種資料型態也被定義於 W3C 中，所以我們也遵循 W3C 制定的格式。這些資料型態包含 String、number、date、datetime、
float、boolean、int、time 等值。
另一相關的問題產生就是儲存資料格 式的大小問題。要如何 表示這一個資料欄位格式擁有多少 bytes 的資料空間，為了這一 個問題我們定義’dsize’這一個種元屬性去擷取這一方面的資訊。
2. 資料關連模組(Modeling Relationships)
Primary key 是一個 table 中唯一的索引對應值，在 XML 中有 一個屬性值為’ID’可以解決這方面的問題。 且執行 DOM 也提供 索引擷取這一個 element 所以這一方面是可行的。為了達到這一 個目的我們利用 pkey_id 屬性去達到這一個目的。
Foreign Key 則是提供和其他不同的 table 產 生 關 係 的對應 值。在 XML 中的屬性值”IDREF”屬性值可以定義這樣的對應關 係，所以我們將屬性在 column 名稱之後加上’_idref’。
3.3.4 Buck 方法論的三個轉換步驟
1. 將資料庫中的 table、columns 轉換成 DTD elements
Table 本身可以轉變為 Element type。在文件中每一行的資料 都會產生一個 element ， 假如這個模組的內容是 EMPTY 就將 columns 轉變成 attributes；反之，模組的內容和一連串的 elements 有關聯，就將 columns 轉變成 elements。每一個 table 會有一個對 應相通名稱的 XML elements，而對應的欄位則為其的子元素。在 建立 DTD 的過程中，都是以 XML elements 去表達 table 和 columns 的 property，或是 XML attributes 表達並沒有一定的標準，利用 屬性表達可具有預設值且佔的空間小等優點，但是，屬性無法表 達順序，且也無法定義子結構。為了怕在不同 table 間具有相同 的 element 名稱，所以在轉換的過程中，必須在欄位的轉換上加 入 table 的名稱，以示區別。 依照表 3.1， 將 EMPLOYEE 這一個 table 轉變成下列這一個 XML DTD 格式。將 employee 的 table 名 稱轉變成 elment(元 素)， 而 fields 則轉變成 employee 的子元素，
如圖 3.6 所示。(下面的範例皆依照表 3.1 所呈現)
圖3.6 轉換 TABLE 成 element Type
2. 轉換資料型態、欄位長度和屬性成 DTD 屬性類別
將資料庫欄位(Columns)轉換成 XML DTD 文件之前，必須先 知道資料庫欄位的資料型態和資料長度，才能正確詳盡地將這些 資料內入 XML DTD 文件中。以便企業未來在傳遞文件資料上，
可以利用 DTD 來驗證資料正確性的工具。 但是 我們發現 DTD 所 能表達的資料格式並不多，所以我們就自定了二個針對資料型態 和資料大小的種元屬性，’dtype’表示資料型態；’dsize 表示欄位 長度’。這個階段完成了資料類型模組化(Modeling Datatype)。
接下來我們要針對欄位的屬性來做轉換，我們知道 DTD 利 用’?’、’+’和’*’表達元素(elements)出現的次數，轉換資料庫我們 將’?’表示可以為 null ‘+’表示不可為 null。 但是在 Attributesm Types 的表達上’#REQUIRED’表示不可以為 null，而’#IMPLIED’
表示可以為 null 的表示法。
利用’dtype’來做延伸的 DTD 格式，這樣的表示方法可以更清 楚的表示是否有 null 的資料型態且規定這一個資料格式也可以 是字母、數字、虛線、冒號或底線。而不單純是上面的表示祇是 字元資料而已，且這樣的表示方法可以清楚地知道是否允許 null 的存在。規定這一欄位可能會有 null 的情況發生。
3. 表達各個 table 之間的關連
執行完以上的二個步驟後，基本的 DTD 也就建構完成，現在 再加上表達關連資料庫中的各種關連的表達就完成完整的 DTD
文件。基本上 primary key 是確保在資料庫 table 中的唯一性，在 XML DTD 的屬性類型中有一個’ID’符合這樣的精神定義。資料 庫 table 之間的關連，全靠 foreign key 的關連而產生，但是需要 唯一值對應才能有效地完成關連，所以我們針對 foreign key 做屬 性的轉換。foreign key 和 prmary key 轉換方式相同。利用屬性內 建值’IDREF’而自定型態為’fkey’，這邊要強調的是一定要有對應 的’ID’ 此 觀 念 和 關 連 資 料 庫 相 同 ， 下 列 表 示 為 PERF_REVIEW Table 中定義 EMP_NUM 為 Foreign key 且對應到 EMPLOYEE Table 中 的 primary key NUM 欄 位 ， 並 利 用 XML 屬 性 內 建 值’IDREF’創造和 primary key 之間的關連。
完成以上的步驟，就完成了 XML DTD 完整轉換關連式資料 庫 的 資 料 。 我 們 將 利 用 這 樣 的 轉 換 模 組 作 為 轉 換 關 連 資 料 庫 和 XML DTD 的轉換方法，並進一步製作成轉換程式。
3.3.5 利用 DOM 製作轉換程式
完成 DTD 文件的構建後，這一節本研究就要針對企業內部應 用程式讀取 XML 文件的介面做發展規劃。依照 W3C 所制定的標 準，文件物件模型(Document Object Model，DOM)，是一種跨平 台的應用程式介面(Application Programming Interface，API)用來 描述文件的重要結構，我們根據它，可以標準的方法存取及操作 物件【9】。
圖3.7 DOM 文件結構【9】
DOM 文件都是唯一一個樹狀結構如圖 3.7 所示。本研究將採 用微軟 MSXML 的 DOM 版本為主，MSXML 的 DOM 版本幾乎 完全遵循 W3C 在 1998 年所推出的 DOM 標準規則(DOM Level 1)。對 DOM 而言，每個項目都有特定型態的節點，都繼承自節 點介面，常見的節點有 Document、Text 、Element 以及 Attribute 等，這些節點可以擁有子節點， XML 文件可以構成一顆完整的 DOM Tree【9】。
本研究利用文件物件模型擷取 XML 中物件對應的 element(元 素)， 並取的詳細的資料進行程式的撰寫等工作 ， 並進一步完成 資訊應用系統和 XML 程式溝通的介面， 到此本研究才可以說完 成 EAI 的 Message Brokers 概念中 Data Transformation 的概念。
Document
Document Element/root
Node
ChildNodes(Nodelbt)
3.4 企業營運作業規則概念
企業內部資訊應用系統之間交換資料，除了要將資料格式轉 換成應用程式之間彼此共通的資料格式外，還必須要知道 彼此應 用程式間的企業營運作業流程為何，才知道要如何去執行運用資 料，才清楚地了解彼此共用的資料，達到共享正確資料的目的。
為了正確地了解資訊應用程式之間的企業營運流程規則，我 們要將應用程式的營運流程重新做分析再造，以確保應用程式之 間的溝通無礙，因此需要一套有效的流程表達方式，來完成資訊 應 用 系 統 間 的 溝 通 。 本研究將利用 UML 對 流 程 的 分 析 設 計 功 能 ， 重 新 針 對 應 用 程 式 的 營 運 作 業 做 詳 細 的 分 析 研 究 ， 在 利 用 UXF 的方法將 UML 的圖形表達成 XML 文件，以方便不同資訊 應用系統間的溝通與資料交換。
3.4.1 以 UML 圖形分析企業營運流程
在目前的三階架構中，無論前端的 GUI(VB、Power Builder、
Delphi 或 是 API)，中段的應用程式伺服器(OLE、CORBA)，甚至 後端的資料庫(Oracle，Informix 等 的 Unversal Server)都是採用物 件導向的設計方法。因此在應用程式企業營運流程分析上，本研 究將採用物件導向方法論—UML 來執行流程的分析。
根據 2.4 章節所提的 UML 圖形設計方法，可以依照企業營運 流程的方向和範圍決定採用哪一種圖形來表示【22】。
1.當營運流程可以由操作物件完成時，可以利用 UML 圖形中
的 狀 態 圖 (statechart diagram) 或 是 活 動 圖 (Activity diagram)，描述物件的狀態或是其行為變化，以表達企業營 運作業流程。
2.營運流程屬於物件之間的行為互動，可以利用 UML 圖形中 的循序圖和合作圖，表達物件之間的互動。
3.營運流程屬於跨系統間的物件互動，利用 UML 圖形中的使 用案例圖加以描述，使用案例圖(Use Case Diagram)可以用 來描述物件與外部資訊應用系統的互動關係，且也適合用 來描述整個企業本身的資訊應用系統。
藉由 UML 的圖形化描述可以讓應用程式系統間的溝通更一 致，且可以清楚地溝通共同共用的流程關係，而有一定的標準可 循。本研究希望透過 UML 的圖形化溝通可以更進一步地將應用 系統間的營運作業流程整合且透過重新分析，可以找出更好的作 業 流 程 並 進 一 步 確 保 資 料 交 換 的 正 確 性 和 達 到 作 業 流 程 運 作 的 目的。
3.4.2 以 UXF 方法轉換 UML 成 XML 文件
上一節中提到，我們利用 UML 的統一模式語言來做作業流程 溝 通 的 標 準 ， 而 將 企 業 營 運 作 業 流 程 跟 資 訊 系 統 作 一 緊 密 的 結 合，但是在現今的資訊環境中，還是會有資料格式不同和標準不 一的情況產生，而造成應用系統之間溝通不易、正確資料無法取 得等問題。
網際網路上傳遞資料並分享資訊，所以我們決定利用 XML 有嚴 格的文件格式、結構化且資料可以在 Internet 中交換並共享彼此 應用程式資訊等特性來轉換 UML 的模組。在資訊爆炸的 Internet 環境中，Web 是一個持續改變的地方，Web 在資料交換和應用程 式整合連接上扮演重要的角色。發 展 Internet 是目前共享資訊的 重 要 公 共 建 設 ， 所 以 在 網 際 網 路 上 發 展 是 為 了 讓 未 來 更 有 發 展 性，並讓資料格式可以得到標準化，並達到資訊共享的目的。 因 為，以上這個因素，我們希望能夠讓 UML 的模組轉換成 網際網 路上可以共享和讀 取的文件。 在轉換 UML 模組和軟體程式間最 重 要 的 因 素 在 於 模 組 的 語 意 要 詳 細 的 描 述 清 楚 並 保 持 原 本 的 語 意，基於這樣的因素，XML 將是合理且可用的選擇。
本 研 究 因 為 以 上 這 些 因 素， 選 擇 了 由 日 本 學 者 Suzuki 及 Yamamoto 所提出的 UML eXchange Format(UXF)方法 ，以 XML 來表達 UML 圖形。
3.4.2.1 UML eXchange Format(UXF)
在這一章節中將說明日本學者 Suzuki 及 Yamamoto 所提出的 UML eXchange Format(UXF)方法。 UXF 方法具有以下幾個特性
【19】：
1.軟體程式開發人員溝通容易
對軟體開發者而言， UXF 是一個有用的轉換 UML 圖形 的轉換方式。UXF 讓 UML 在每一個 model 的轉換簡單化，
且讓人容易解讀並且可以直接轉譯，而使的軟體開發撰寫 者在溝通上面更加的方便跟容易，而不再透過多種格式的 轉換來求一致化的標準。在網際網路的環境中，web 的環境 是我們可以快速地了解獲取資訊的主要來源之一，且由於 XML 文件格式的容易撰寫且標準化的規格使得 web 程式的 開發者更容易溝通跟撰寫。
2.讓程式開發工具聯絡更為方便
軟體模組快速變動在分析設計、修改維護階段和用來製 作各自發展格式的套裝軟體工具上。一個中立的應用程式 轉換介面允許 UML 模組和軟體開發工具可以共同操作開發 在軟體的生命週期期間。一但介面程式完成，模組資訊可 以重複被利用在不同領域不同效益的應用程式工具上，如 圖 3.8 所示。
圖3.8 軟體開發工具之間的互動【20】
3.4.2.2 UXF DTDs
實際上 UXF 詳細描述一連串的 XML DTDs 的組合。UXF 提 供 一 個 UML Model 的 圖 形 架 構 資 訊 轉 換 成 DTDs 文 件 標 籤
(document tag)，UML Model 的圖形架構屬性將會被轉成為相當 的 UXF 標籤(tags)。
轉換 XML 文件之前，我們要將 UML 中的各種關係及物件模 組的元素轉換成 XML DTDs。首先，要將用來建構 UML 圖形的 各種元素轉換成 DTD 中的元素；再將各個元素所具有的屬性轉 換成 DTD 的屬性類型宣告，最後，再將連接的關係利用屬性內 建值的’IDREF’為屬性資料型態表示。
UML Package UML Model Element UXF Representation Association <Association>
AssociationEnd <AssocRole>
Attribute <Attribute>
Class <Class>
Dependency <Dependency>
Generalization <Generalization>
Interface <Interface>
Operation <Operation>
Core
Parameter <Parameter>
Auxiliary Elements Refinement <Refinement>
Extension TaggedValue <TaggedValue>
Exception <Exception>
Action <Action>
ActionSequence <ActionSequence>
Common Behavior
Instance <Instance>
Model <Model>
Model Management Package <Package>
Collaboration <collaboration>
Interaction <Interaction>
Collaborations
Message <Message>
CompositeState <CompositeState>
Event <Event>
Guard <Guard>
State <State>
Transition <Transition>
StateMachines
PseudoState <PseudoState>
表3.2 UML Model elements 轉換 UXF tags 之對照【9】
圖3.9 UML Model Elments 轉換的 UXF DTD
照關係。UXF 支援很多 UML 的基本模組，如 Core Package、
Collaboration Package、Auxiliary Package、Extension Package、
Model Management 和其他的 package 等 。圖 3.9 則呈現完整的 DTD 文件展示。
有了 UXF DTD 的文件之後，就可以依照 DTD 的格式，將 UML 的圖形化資訊轉換成 XML 的文件，圖 3.10 是一個 UML 的類別 圖 ； 此 類 別 圖 包 含 四 個 類 別 ： Polygon、 Point、 GraphicsBundle 和 Triangle；Polygon 類別分別和 Point 類別、GraphicsBundle 類 別有聚合的關係；Polygon 類別和 Triangle 類別有繼承的關係。
這些模組的資訊將可以直接轉譯成 UXF 文件，如圖 3.11 為這個 範例的 UXF 文件。
圖3.10 UML 類別圖範例
圖3.11 轉換圖 UML 類別圖的 UXF 文件
根據圖 3.10 的類別圖跟圖 3.11 的 UXF 轉換文件，可以清楚 地之知道，依照 UXF DTD 的轉換方式，都可以將 UML 類別圖 中的重要資訊詳細正確地利用 XML 文件來做表達，包含類別的 屬性、類別間的關係跟類別的操作方法等，而使得 UML 的資訊 可以更方便地在不同的應用程式系統中被傳遞並加以運用。
