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

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

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

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

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

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

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

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

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

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

1. 模型標準

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

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

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

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

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

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

2. 模型分類

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

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

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

3. 模型設計

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

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

M3層設計結構如下圖：

M2層設計結構如下圖：

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

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

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

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

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

4. 模型關聯(lián)

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

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

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

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

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

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

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

5. 模型生態(tài)

應用業(yè)務模型管理（ROMA ABM）作為元模型驅動開發(fā)的載體，與周邊系統(tǒng)或者伙伴形成良好的生態(tài)循環(huán)：

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

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

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

到此，關于“如何解讀基于MOF的應用模型管理”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>