如何解讀基于MOF的應用模型管理

這篇文章主要介紹“如何解讀基于MOF的應用模型管理”，在日常操作中，相信很多人在如何解讀基于MOF的應用模型管理問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何解讀基于MOF的應用模型管理”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

摘要：為了打破技術與業務的壁壘，搭建技術與業務的橋梁，因此基于如下流程實現應用業務模型管理 ROMA ABM。

在數字經濟時代，數據正在成為企業極其重要的戰略性資產。在政府方面，數據第一次作為新型生產要素，列為比肩土地、勞動力、資本、技術的“第五要素”。隨著數據增多，越來越難弄清楚這些數據背后的具體含義，從而引發一些下列問題：

• 查找信息難 大數據時代，政企數據量呈爆發式增長，在海量信息中快速、精確查找數據顯得不盡如人意。

• 理解不一致 業務理解存在差異，讓IT與業務脫節成為“兩張皮”，從而造成大量重復工作，甚至影響業務決策。

• 學習成本高 員工具有一定的流動性，如缺乏業務的管理辦法，對于新員工需要花費大量時間和成本做培訓，造成嚴重的知識流失和金錢消耗。

對于上述的問題，構建以業務模型突破語義屏障、運營管理驅動高質量發展的思路，構建一套完善的資產管理方法。

為了打破技術與業務的壁壘，搭建技術與業務的橋梁，因此基于如下流程實現應用業務模型管理 ROMA ABM（Application Business Model），

如下對關鍵的流程做了說明和解讀，方便大家更好的理解：

1. 模型標準

先解釋下什么模型，模型是描述數據的數據，也統稱為元數據，比如書的目錄（作者、ISBN、價格等），簡單對應對物理表的表字段，API的輸入輸出等。

業界OMG規范組織對模型有專門的定義，在MOF 2.5規范中模型術語M1層。

• M3是元元模型用于定義元模型，提供基礎模型快速組裝一個元模型包，例如定義元模型需要的領域、類、屬性、關系等等；

• M2是元模型，是M3的實例，是一種模型的規范，具體來說就是描述組成模型的元素和元素之間的關系，如關系數據庫元模型，從庫到表、實例、表、字段、索引之間的關系；

• M1是模型，是用于描述數據的數據，比如一本書的目錄信息（作者、ISBN、價格等），一般對應到物理表的表字段、API響應的字段等；

• M0是基于此模型的對象，也就是物理世界中的數據，一般對應到物理表中的數據。

2. 模型分類

ROMA ABM定義了業界比較認可分類方式，主要分為：技術模型，業務模型兩種。

• 技術模型包括：字段名稱、字段長度、數據庫表結構、API描述、消息描述、文件描述等。技術模型通常通過自動化的任務完成對模型的采集，也可以通過文件導入等其他方式完成模型的獲取，如下是關系型數據庫、微服務模型包的樣例供參考；

• 業務模型包括：業務名稱、業務定義、業務描述、安全策略等給其他使用者能夠看懂的業務屬性，使用者可根據自己的業務線或者領域快速定位到自己想要獲取的數據模型，通如下是業務模型的樣例包供參考；

3. 模型設計

通過ROMA ABM的元模型可視化配置能力能夠快速的完成元模型的設計，元模型的設計體現了設計者對整個業務系統的理解程度，從業務視角整理出的數據分類，這里我們可以稱之為業務模型，它使得整個組織統一數據語言，是業務流打通、消除信息孤島和提升業務流集成效率的關鍵要素。在設計業務模型之前，需要對組織的業務做端到端的梳理，例如有哪些業務范圍、業務過程、業務發生主體、業務事件等等，然后將以上整理內容做歸納總結，設計出符合自己組織特有的業務模型（元模型），這里以智慧城市的場景為例，整理設計歸納出數字政府的業務模型：

通過ROMA ABM可視化元模型配置能力完成數字政府業務模型的M2元模型配置、屬性配置，為了幫助大家更好的理解元模型的設計，通過數字政府業務模型對M2、M3層做詳細說明， M3層為M2層建模提供通用的元模型設計元素，具體參考如下：

M3層設計結構如下圖：

M2層設計結構如下圖：

M2層除了對業務條線做了抽象以外，還定義了業務屬性，幫助使用者獲取庫表、API等底層結構依賴的業務附加屬性，這些類內容通過底層的系統是無法獲取的，具體需要附加哪些屬性，需要數據管理者結合業務場景做梳理，如下是數字政府業務模型包中提供的通用屬性，供參考；

通過上面的數字政府業務模型我們其實不難發現，模型管理的核心能力就是從抽象逐步分解到實現，M0、M1、M2、M3對象在真實系統中的關系可以總結如下：

• M1是M0層抽象，M0代表實際存儲的數據，M1代表存儲這組數據需要的結構，通常對應到業務系統中就是一組表結構、一組API、一組文件等等；

• M2是M1層的抽象，M2代表對M1這些表結構、API、文件等的存儲模型，M2層雖然是元模型，但同時M2也是數據，因此元模型也需要統一的存儲結構并且具備擴展性；

• M3是M2層的抽象，M3代表對M2的抽象，具有通用型，就和設計工具類似，可以設計各式各樣的元模型；

4. 模型關聯

通過以上設計完成了業務模型與技術模型的設計以及配置，但是這個時候兩類模型之間并沒有發生任何關系，因此我們需要將業務模型與技術模型關聯起來，讓技術語言走向業務語言，通過工具提供快速、穩定、多樣的關聯顯得非常的重要。

在整個MOF框架中，M3-元模型是整個模型管理的核心， 那么如何構建“可配+多樣+穩定”模型采集框架就很關鍵，我們可以參考如下原則：

• M3元模型能力圖形組件化，通過拖拽方式完成對元模型包的構建；

• 同類型元模型下的多套采集適配器共用“一套程序”，實現各種介質中的模型與關系進行采集與解析，重點用于對技術模的多樣化采集，如下是關系型數據庫的適配樣例圖：

• 元模型包設計過程中支持跨包關聯，即當前元模型可以和其他元模型發生依賴關系，模型采集完成后自動實現跨包關聯；

基于上述原則從而形成下列模型采集過程：

經過以上步驟處理以后，將本身不可讀的表、字段、API等信息全部轉化為帶有業務語義的模型，讓各個部門、各個系統、各個開發者在用數的查找上更簡單、效率更高，徹底實現技術模型到業務模型的扭轉。

5. 模型生態

應用業務模型管理（ROMA ABM）作為元模型驅動開發的載體，與周邊系統或者伙伴形成良好的生態循環：

• 將存量系統中的庫表、API、文件等技術模型自動化抽取，通過可視化的元模型設計器，讓所有的技術模型能夠按照業務領域統一存儲，讓開發者或者用戶不需要關心實際的細節，屏蔽底層系統的差異；

• 通過模型扭轉把技術模型與業務模型自動關聯，讓底層庫表、API等這些無法理解的數據模型具有業務上的語義，同時讓所有的底層數據模型回歸到屬于它自己的業務范圍，讓懂業務的開發者或用戶可以在自己擅長的業務范圍內，使用自己熟悉的業務語言完成數據模型的查找；

• 第三方應用或者系統可以通過統一的接口獲取技術模型、業務模型，更進一步完成模型的消費，第三方應用或者系統基于已有的存量模型通過組合、編排等方式生成新的模型后，在回饋給應用業務模型管理服務，讓所有模型像血液一樣不停在整個系統中流動，最終形成完整的模型生態。

到此，關于“如何解讀基于MOF的應用模型管理”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！