模型驅動的軟件開發通常從應用程序建模或數據建模開始。然而，應用程序建模和數據建模是緊密相關，互為補充的。IBM 認識到在模型驅動的軟件開發中將應用程序建模與數據建模相集成的重要性，並開發了 UnifIEd Modeling Language（UML）到 Logical Data Model（LDM）轉換和 LDM 到 UML 轉換。這些轉換將使用 Rational Software Architect（RSA）集成應用程序建模並使用 Rational Data Architect（RDA）集成數據建模。本文對 RSA 和 RDA 作一個簡要的概述，並列出三種 RSA-RDA 集成場景中的高級步驟，最後討論 UML 到 LDM 和 LDM 到 UML 的轉換以及 UML Logical Data Model Profile。
模型驅動的方法正被廣泛用於軟件開發。在模型驅動的軟件開發中，要麼是從應用程序建模開始，要麼是從數據建模開始。然而，應用程序建模和數據建模互相之間是非常相似的。應用程序建模捕捉關鍵業務信息，使用統一建模語言（UML）中的類模型的形式將它們表示為類和關聯。然後，可以以類模型為基礎，派生出用於數據建模的邏輯數據模型。另一方面，數據建模使用邏輯數據模型（LDM）捕捉業務實體、它們的關系及約束，然後，可以用它們派生出用於應用程序建模的類模型。
格式良好的 LDM 可以提供企業中關鍵業務信息的正確表示。它可以包含很多應用程序和物理數據源，並且具有更長的存在期限。當企業執行應用程序建模任務時，LDM 中的清晰、准確和完整的語義為類模型提供了極好的基礎。
無論是從應用程序建模開始，還是從數據建模開始，當這些不同形式的建模被組合成一個整體時，模型驅動的軟件開發的威力將被釋放出來，因為我們具備以下優勢：
實現跨企業及其各層架構的模型互操作性， 可用於多個應用程序的可重用的信息模型， 解耦的數據語義和物理實現，以及分離應用程序建模師和數據建模師的工作。
IBM 在提供應用程序建模工具方面走在前列，最近還增加了數據建模工具。用戶可以在 Rational Software Architecture （RSA）中進行應用程序建模，在 Rational Data Architect（RDA）中進行數據建模。IBM 認識到在模型驅動的軟件開發中集成應用程序建模和數據建模的重要性，並開發了 UML 到 LDM 轉換和 LDM 到 UML 轉換，以便將這些工具鏈接在一起。UML 到 LDM 轉換是 RSA V7 的一項可選特性，LDM 到 UML 轉換是 RDA V7 的一項可選特性。這兩個產品的在線文檔詳細描述了安裝和使用這些轉換的過程，並包括了對象映射信息。
本文首先對 RSA 和 RDA 作一個簡要的概述，然後列出三種 RSA-RDA 集成場景中的高級步驟。對於 UML 到 LDM （自上而下）和 LDM 到 UML（自下而上）場景，本文進一步就企業應該何時使用它們給出了一些建議。接著，本文討論 RSA 中的應用程序建模、RDA 中的數據建模以及 UML 到 LDM （自上而下）轉換和 LDM 到 UML（自下而上）轉換。本文還討論 UML Logical Data Model Profile，它支持 RSA 中的數據建模，並增強了 UML 到 LDM 和 LDM 到 UML 轉換。
請注意，雖然 UML 到 LDM 轉換和 LDM 到 UML 轉換是 RSA 與 RDA 集成的核心，但是 RSA 與 RDA 集成中也有其他一些值得一提的重要方面：
便於部署和提高易用性的普通安裝和 shell 共享
使用 Clearcase 的公共模型庫
公共的模型驅動的開發工具集（EMF 模型、轉換框架、可擴展性等等）
對這些話題的討論超出了本文的范圍。
Rational Software Architect
Rational Software Architect（RSA） 是一種應用程序建模工具，它使企業可以建模、分析、設計和生成應用程序。它利用模型驅動的開發和 UML 創建設計良好的應用程序和服務。RSA：
擴展開放的、可擴展的軟件開發環境 Eclipse 。
利用最新的建模語言技術，支持跨各種不同領域靈活建模，包括 UML 2、用於 Java 的類 UML 標注等等。
支持用於並行開發和架構重構的靈活的模型管理；例如，可以拆分、組合、比較和合並模型和模型片段。
通過模型到模型、模型到代碼轉換，包括反向的轉換，簡化架構與代碼之間的轉換。
簡化 Java™/J2EE™、Web 服務、SOA 和 C/C++ 應用程序的設計到代碼的體驗。
包括 IBM Rational Application Developer 的所有特性，提供集成的設計和開發體驗。
RSA 中的類（Class）是應用程序中可以被創建、組裝、檢查、測試、修改或處理的任何內容。下面的圖 1 顯示了一些示例類以及它們之間的關聯 – 一個名為 Invoice 的示例 RSA 項目中的 Invoice、InvoiceItem、ProductInvoice 和 ServiceInvoice。注意，圖中顯示了三種不同類型的關聯：組合（invoice – item）、聚合（main – associate）和簡單的關聯（product - service）。本文後面將討論這些關聯。
圖 1. RSA Invoice 項目中的示例類模型
查看原圖（大圖）
Rational Data Architect
Rational Data Architect（RDA）是一種企業數據建模和集成設計工具。它簡化了數據建模和集成設計，使架構師可以發現、建模、可視化和關聯不同的、分布式的數據資產。通過使用 RDA，可以：
創建邏輯和物理數據模型。
比較和同步兩個數據模型的結構和元素。
分析數據模型的正確性以及與企業標准的一致性。
發現、探索和可視化數據源的結構。
使用映射發現潛在的關系，並識別不同數據源之間的關系。
下面的圖 2 顯示了一個示例 LDM，該 LDM 來自示例 RDA 項目 Invoice。注意，這裡有三種類型的關系：標識（item – invoice）、非標識（associate - main）和多對多（service - product）。還應注意，key inheritance 用於泛化，key migration 用於標識和非標識關系。本文後面將對此加以討論。
圖 2. RDA “Invoice” 項目中的示例邏輯數據模型
查看原圖（大圖）
在軟件開發周期中，邏輯數據模型過去常常被忽視，但是由於很多原因，現在已經變得越來越重要。LDM 提供企業中數據實體的一個視圖，而不暴露實現細節。它將數據語義與實現分開，在處理如今日益復雜的異構 IT 環境時尤其有用。其他邏輯或物理模型，例如服務模型、消息模型、類模型和數據倉庫模型，都可以追溯到一個共同的 LDM。借助成熟的模型驅動開發工具，例如 Rational Data Architect 和 Rational Software Architect，用戶甚至可以根據 LDM 生成下游模型和物理實現。毫不誇張地說，LDM 是企業的信息中心。LDM 可提供數據的企業視圖，從而幫助減少數據冗余、提高數據質量和加快集成。
集成場景
應用程序建模和數據建模的集成主要有三種場景：自上而下、自下而上和中間會合。接下來的小節詳細描述每種場景。這裡假設有兩個主要的 IT 角色 – 應用程序建模師執行應用程序建模，數據建模師執行數據建模。
自上而下：應用程序建模到數據建模
在自上而下場景中，RSA 中的類建模元素（類、屬性和關聯）被轉換為 LDM 建模元素（實體、屬性和關系），以便在 RDA 中使用。
這個場景中的步驟是：
應用程序建模師在 RSA 中進行應用程序建模。業務或應用程序數據被捕捉為類模型。
應用程序建模師使用 UML 到 LDM 轉換將全部或部分類模型轉換為一個 LDM。
數據建模師 在 RDA 中訪問和導入 LDM。
數據建模師將 LDM 轉換為物理數據模型（PDM），並使用 RDA 進一步生成數據庫模式。
下面的圖顯示在自上而下場景中應用程序建模師與數據建模師之間的交互：
圖 3. 自上而下集成場景：應用程序建模到數據建模
查看原圖（大圖）
當同時符合以下條件時，建議考慮使用自上而下場景：
應用程序建模驅動項目計劃。
應用程序跨越業務單元筒倉（silo）。
應用程序以對象為中心，除了持久性以外，對於數據管理的需求很少。
LDM 不可用。
不存在物理數據庫模式。
然而，人們有時會因為一些錯誤的原因而選擇采用自上而下場景。下面列出了這些決定采用自上而下場景的錯誤理由（使用引號括起），從而起到了反作用：
“我們以前從未實現過 LDM”。凡事總有第一次。如果您的企業過去曾經在 LDM 方面走捷徑，那麼 LDM 發揮的效用越快，企業獲得的長期收益越好。
“我們沒有 LDM 技術”。優秀的數據建模師值得企業為其投資，因此，您應該雇用擁有 LDM 技術的人員或在內部進行培訓。
“我們只需要持久數據，以供這個應用程序使用。”大多數企業應用程序都將需要與其他企業應用程序共享持久數據。LDM 有利於減少總體擁有成本。
最後，有必要提到使用自上而下方法的缺點：
數據模型可能與特定應用程序緊密耦合。
由於應用程序建模中的不規范和以對象為中心的建模，可能無法在 LDM 中立即重用類模型。
自下而上：數據建模到應用程序建模
在自下而上場景中，LDM 建模元素（實體、屬性和關系）被轉換為類建模元素（類、屬性和關聯），以便在 RSA 中使用。從企業角度長遠來看，使用自下而上方法比使用自上而下方法更好，正如前面小節所說的那樣，自上而下方法有一些局限性，而 LDM 則有很多優點。此外，自下而上方法便於分離工作 – 數據建模師只需專心開發企業級詞匯表和數據模型；應用程序建模師只需進行應用程序建模。
這個場景中的步驟是：
數據建模師使用 RDA 在一個 LDM 中建模數據。如果已經有一個數據庫模式，但是沒有物理或邏輯模型，那麼 數據建模師根據已有的模式生成一個 PDM，並將 PDM 轉換成 LDM。
數據建模師使用 LDM 到 UML 轉換將 LDM 的全部或一部分轉換成一個類模型。
應用程序建模師在 RSA 中訪問和導入類模型。
下面的圖顯示在自下而上場景中應用程序建模師與數據建模師之間的交互：
圖 4. 自下而上集成場景：數據建模到應用程序建模
查看原圖（大圖）
當同時滿足以下條件時，建議考慮使用自下而上場景：
域內的 LDM 可用。
具有一些現有數據源（關系數據庫或其他數據源）。
企業希望從應用程序中解耦數據並實現企業級數據管理。
企業希望創建可跨整個企業重用的信息。
涉及多個計劃。例如，業務應用程序重寫並需要綁定到數據倉庫。
應用程序過於復雜，並經常變化。
應用程序以數據為中心。
項目需要考慮已有的數據模型（至少需要考慮一部分）。如果有遺留的應用程序、第三方應用程序或需要實現基於標准的界面，就需要考慮這一點。
最後，實現自下而上方法也需付出一定代價：
在從 LDM 轉換到類模型時，有些語義可能會丟失，因為 LDM 的數據語義比類模型更加豐富（例如主鍵）。
由於 LDM 往往比類模型更完整，如果未經恰當交流就將 LDM 推入類模型，那麼應用程序建模師就會面對大量的信息。如果應用程序建模師不理解 LDM，那麼他們最後可能不得不從頭開始重新定義 LDM 中已有的實體或屬性。因此，因此，數據建模師和應用程序建模師之間需要進行恰當的培訓和交流。理想情況下，應用程序建模師經過培訓後應該能理解和利用邏輯數據模型。
中間會合
前面的小節描述了自上而下和自下而上場景，它們主要側重於全新的開發。然而，軟件開發的永恆主題就是變化。應用程序建模和數據建模並不是件一勞永逸的事。為了避免過時，應用程序建模和數據建模需要反復進行，並迅速轉化為業務價值。因此，應用程序建模和數據建模工具應該支持模型更新功能。例如，可以對類模型中的修改進行更新，並自動（適用於簡單修改）或手動（涉及復雜過程）反映到 LDM 中，反之，從 LDM 到類模型這個過程也一樣。
實際上，對於類模型和 LDM 的同步和變更管理並不容易，因為它們處在不同的工具中，並且常常由不同的角色 – 應用程序建模師和數據建模師 – 來處理。但是，通過認真的計劃、積極的交流和嚴格的變更管理，可以有效地利用工具特性，並實現端到端的數據治理。
取決於要更新類模型還是 LDM，中間會合場景中有兩種用例：
當類模型被轉換到 LDM 並在 RDA 中使用之後，應用程序建模師在類模型中作了一些修改，例如增加了新的屬性。我們需要在 RDA 中更新 LDM，以反映更新後的類模型。這個用例是自上而下場景的一個擴展，只是另外還需要在 RDA 中用新的或被修改的信息同步已有的 LDM。
第一個用例中的步驟是：
數據建模師在 RDA 中使用 LDM 版本 1，它是之前在 RSA 中從類模型版本 1 轉換而來的。
應用程序建模師在 RSA 中修改類模型版本 1，然後將更新後的類模型（版本 2）轉換為 LDM 版本 1+。
數據建模師在 RDA 中訪問並導入 LDM 版本 1+。
數據建模師進行比較，並在 RDA 中將 LDM 版本 1+ 和版本 1 合並為 LDM 版本 2。
下面的圖顯示在第一個用例中應用程序建模師與數據建模師之間的交互：
圖 5. 中間會合場景 – 應用程序建模到數據建模
查看原圖（大圖）
當類模型被轉換到 LDM 並在 RDA 中使用之後，數據建模師對 LDM 作了一些修改，例如增加新的列。這種情況下應該更新 RSA 中的類模型，以反映更新後的 LDM。這個用例非常類似於自下而上場景，只是另外還需在 RSA 中用新的或被修改的信息同步已有的類模型。
第二個用例中的步驟是：
應用程序建模師在 RSA 中使用類模型版本 1，它是之前從 RDA 中的 LDM 版本 1 轉換而來的。
數據建模師在 RDA 中修改 LDM 版本 1，然後將更新後的 LDM（版本 2）轉換為類模型版本 1+。
應用程序建模師在 RSA 中訪問並導入類模型版本 1+。
應用程序建模師進行比較，並在 RSA 中將類模型版本 1+ 和版本 1 合並為類模型版本 2。
下面的圖顯示在第二個用例中應用程序建模師與數據建模師之間的交互：
圖 6. 中間會合場景 – 數據建模到應用程序建模
查看原圖（大圖）
模型轉換
模型轉換是集成應用程序建模與數據建模的核心。在前面討論的自上而下場景中，需要使用 UML 到 LDM 轉換將類模型轉換為邏輯數據模型；在自下而上場景中，需要使用 LDM 到 UML 轉換將邏輯數據模型轉換為類模型。
UML 類模型
一個類模型定義了以下內容：
模型和包：作為結構組件和其他模型元素的名稱空間。一個包可以包含包、圖、類、關聯、關聯類和數據類型。
類：表示被建模系統中的概念。同一個類的不同實例具有相同的特征。類具有：
屬性：對類的特征的描述。屬性具有類型，用來定義屬性值的類型。
泛化（Generalization）：按照分類學，一個類與更泛化的類之間存在泛化關系。類與更泛化的類完全一致，但是包含額外的屬性。
關聯：表示實例之間存在聯系的兩個類之間的語義關系。除了簡單形式的關聯外，另外還有兩種形式的關聯：
聚合（Aggregation）：這種關聯指定一個聚合體（一個整體）與一個組成部分之間的整體-部分關系。
組合（Composition）：聚合的一種形式，組成部分嚴格隸屬於組合體（整體），並且部分與整體的生命周期一致。一個部分一次只能屬於一個組合體。
關聯類：關聯類是一個關聯，同時也是一個類。關聯類連接兩個類，並且有自己的屬性。
數據類型：數據類型是一組值的描述符。數據類型包括：
預定義的基本類型：Boolean、Number、String、UnlimitedNatural
用戶定義數據類型：基本類型或枚舉類型
請回到 圖 1，看看示例類模型。
RDA 邏輯數據模型
邏輯數據模型定義：
包：作為其他模型元素的結構組成。包可以包含包、圖、實體和域。
實體：表示概念、事件、人、位置或關於保存什麼信息的內容。同一種實體的實例具有相同的特征。實體可以是獨立的，也可以是非獨立的。對於一個實體，如果沒有確定它與其他實體的關系就不能惟一地標識它的實例，那麼它就是非獨立實體。否則，它就是獨立實體。實體有：
屬性：對實體特征的描述。屬性具有類型，可定義其值的類型。
主鍵：惟一地標識實體的一個實例的一個或多個屬性。
泛化：按照分類學，一個實例在它與更泛化的實例之間存在泛化關系。實體與更泛化的實體完全一致，但是包含更多的屬性。
關系：標識兩個實體之間的連接、鏈接或關聯。有三種類型的關系：
標識關系：子實體的實例通過它與父實體的關聯來標識。父實體的主鍵屬性成為子實體的主鍵屬性。