MES/MOM的未來：低代碼與模型驅(qū)動（1）

以下文章來源于佰思杰 ，作者駱金松

01 低代碼與模型驅(qū)動

筆者認(rèn)為，“低代碼”幾乎是“模型驅(qū)動（Model-Driven）”的同義詞，從現(xiàn)在絕大多數(shù)低代碼平臺的實現(xiàn)來看，低代碼平臺背后的實現(xiàn)技術(shù)正是模型驅(qū)動，帶來的新東西并不多。

考慮模型在軟件開發(fā)中的作用，除了廣泛使用的“模型驅(qū)動”概念，還有基于模型（Model-based）、面向模型（Model-oriented）、以模型為中心（Model-centric）等等，其中“模型驅(qū)動”過去在學(xué)術(shù)界得到了更多的認(rèn)同。為啥模型驅(qū)動一直不溫不火，而低代碼怎么突然就火了？

模型驅(qū)動一詞過于學(xué)術(shù)化，其中包含的概念元數(shù)據(jù)（Meta-data）、元模型（Meta-model）、建模語言(Modeling language)、自描述（Self-descripted）等概念理解起來有一定的困難，嚇跑了許多民眾。而低代碼就非常親民，傳達(dá)的信息非常清晰，得到業(yè)界廣泛的認(rèn)可，在商業(yè)上也取得了巨大成功。

圖 “低代碼”幾乎是“模型驅(qū)動（Model-Driven）”的同義詞

在軟件開發(fā)過程中應(yīng)用建模技術(shù)，其目的是提高抽象層次。計算機軟件開發(fā)方法的每一次變革都是通過提高抽象層次實現(xiàn)，從機器語言到匯編語言、再到高級語言、可視化建模語言，開發(fā)效率得到了顯著提升。

低代碼的目標(biāo)是最大限度減少手工的硬編碼，意味著必須更多的使用模型，這正是模型驅(qū)動工程（MDE，Model-Driven Engineering）的目標(biāo)和領(lǐng)域。MDE使用模型提供更高抽象層次，來降低軟件的復(fù)雜性的思想已經(jīng)存在了20余年：

• 更高抽象層次“領(lǐng)域模型（Domain Models）”?更具體、繁瑣的“代碼（Source code）”

• 更易學(xué)易用的“建模工具（Modeling tools）”?高門檻的“編程工具（Programming tools）”

• 更直觀的“領(lǐng)域建模（Domain Modeling）”?更偏向技術(shù)細(xì)節(jié)的“編程（Coding）”

其結(jié)果是模型驅(qū)動的應(yīng)用程序開發(fā)比手工編碼的效率有顯著的提升，而且基于模型的系統(tǒng)通常更加易于維護。

02 模型驅(qū)動的架構(gòu)

創(chuàng)建和使用領(lǐng)域模型是MDE的核心理念。其中最成功的MDE方法是OMG國際組織提出的MDA（Model-Driven Architecture）方法，然而MDE是一種典型的生成式技術(shù)，是一種以建模（Modeling）和模型轉(zhuǎn)換（Model Transformation）為主要途徑的軟件開發(fā)方法。

圖 模型驅(qū)動的方法MDA

如下圖，MDA使用模型轉(zhuǎn)換工具將平臺無關(guān)的模型（PIM，Platform Independent Model）轉(zhuǎn)換為平臺相關(guān)模型（PSM, Platform Specific Model），最后再進一步轉(zhuǎn)為代碼，代碼最后編譯為應(yīng)用系統(tǒng)。目前部分低代碼平臺正是基于模型轉(zhuǎn)換實現(xiàn)的。

圖 MDA將模型最終轉(zhuǎn)換為代碼

這種模式開發(fā)過程和運行過程是分離的，建模工具只是在開發(fā)期間使用，并不成為系統(tǒng)的一部分，任何對系統(tǒng)的修改都需要進入開發(fā)環(huán)境，修改模型、重新生成代碼、編譯。然后進入運行過程，關(guān)閉系統(tǒng)、部署系統(tǒng)、重新啟動系統(tǒng)。

圖 傳統(tǒng)MDE開發(fā)過程和運行過程是分離的

傳統(tǒng)的軟件開發(fā)過程相關(guān)概念我建個模型總結(jié)如下：

圖 傳統(tǒng)軟件開發(fā)的核心概念

“模型驅(qū)動的架構(gòu)”的相關(guān)概念梳理如下，建模語言替代了編程語言，建模工具替代了編程工具，相對于開發(fā)環(huán)境直接編寫代碼，MDA先創(chuàng)建模型再自動生成代碼，最后編譯為應(yīng)用系統(tǒng)。

圖 模型驅(qū)動開發(fā)的幾個核心概念

首先，生成式方法產(chǎn)生的代碼有些時候不能完全滿足客戶需求，通常需要手工修改生成的代碼，模型就與代碼不一致了。其次，通過模型自動生成的代碼可能不容易閱讀。另外，模型只是軟件開發(fā)過程中的中間產(chǎn)物，無法在系統(tǒng)運行期間動態(tài)修改并立刻生效。

03 運行時的模型驅(qū)動

運行時模型驅(qū)動（Run-time Model-Driven）架構(gòu)解決了不能在系統(tǒng)運行期間修改模型并立刻生效的問題。建立了一體化的開發(fā)和運行環(huán)境，在運行的系統(tǒng)中內(nèi)置建模工具，支持在系統(tǒng)運行時創(chuàng)建和修改模型，并且在運行時借助“模型解釋器（Model interpreter）”或“執(zhí)行引擎（Execution engine）”直接加載、解釋和執(zhí)行模型。

圖 運行時模型驅(qū)動的開發(fā)運行一體化架構(gòu)

系統(tǒng)運行期間定義的模型作為一種特殊的數(shù)據(jù)保存在系統(tǒng)中，這種數(shù)據(jù)稱為元數(shù)據(jù)（Meta-data），不需要停止運行中的系統(tǒng)，可以在系統(tǒng)運行期間修改模型，系統(tǒng)的行為也會隨之改變，這被稱為運行時的適應(yīng)性（Runtime Adaptability），這可以減少停機次數(shù)和維護事件。

圖 運行時模型驅(qū)動開發(fā)的幾個核心概念

運行時模型驅(qū)動對于降低系統(tǒng)開發(fā)和維護門檻、支撐快速開發(fā)和運維具有重要價值。通常不需要專業(yè)的代碼工程師、業(yè)務(wù)專家或業(yè)務(wù)工程師不用關(guān)注技術(shù)細(xì)節(jié)就可以快速實現(xiàn)系統(tǒng)的定制開發(fā)和運維。

當(dāng)然模型通常不能滿足所有的需求，系統(tǒng)也支持基于插件的擴展開發(fā)，此時并不需要修改平臺本身，而是基于擴展點和API進行。平臺還可以提供某種腳本解釋器，允許基于平臺在線編寫腳本，在運行時加載，進行即時編譯和執(zhí)行。

04 通用建模能力是不足夠的

下面討論一下建模工具、建模語言以及建模能力。如下圖的電路，大家應(yīng)該非常熟悉，基于對中學(xué)所學(xué)到的知識，只需要極少的符號就很容易精準(zhǔn)表示這個電路。然而，電路圖建模工具并不適合其他的建模，例如用于描述業(yè)務(wù)流程、建模大樓的結(jié)構(gòu)，是否存在一種萬能的通用建模語言？

圖 專用的電路圖建模工具建模電路圖非常容易

首先介紹下什么是通用語言？漢語就是一種通用語言，漢語是一個博大精深的語言，具有強大的表達(dá)能力！如果要表達(dá)這樣的電路可能會是這樣的：“直流電源通過導(dǎo)線將一個開關(guān)和燈泡串聯(lián)在一起，從電源正極出發(fā)，依次連接開關(guān)、燈泡，最后回到電源負(fù)極?！?/p>

你會說，漢語是一種自然語言，不是一種可視化的語言，如果換作圖形化的建模語言，可以更好對電路進行表示。事實上，通過一種通用的建模語言并不容易，這需要強大的建模語言和建模工具，其中影響力最大的應(yīng)該非統(tǒng)一建模語言(Unified Modeling Language，UML)莫屬，UML具有廣泛的建模能力。

然而，使用UML去建模一個電路圖將是非常困難的，因為UML缺少燈、開關(guān)、電源、導(dǎo)線等領(lǐng)域概念，首先需要通過UML類圖定義領(lǐng)域?qū)拥母拍睿缓笤儆妙I(lǐng)域?qū)拥母拍钊ザx電路，如下圖所示：

圖 通過UML類圖定義電路圖的概念

然后基于領(lǐng)域?qū)拥母拍?，例如：燈、開關(guān)、電源、導(dǎo)線，通過UML對象圖，描述各個電路器件，以及如何通過導(dǎo)線連接這些器件。

圖 使用UML對象圖描述電路

好像還漏了點什么？哈哈，電源的正負(fù)極如何表示？開關(guān)是何種開關(guān)，有多少個接線端子？當(dāng)前開關(guān)當(dāng)前處于閉合還是斷開的狀態(tài)？

圖 通用建模語言雖然通用但不萬能

UML建模語言作為一種通用的建模語言（GPML, General-Purpose Modeling Language），因為必須滿足各種各樣的通用建模需求，使得其變得更加復(fù)雜而難以使用。通用但并非萬能，由于缺少領(lǐng)域?qū)拥母拍睿噪y以精確地表達(dá)語義，幾乎不可能基于UML模型去直接生成一個復(fù)雜而完整的應(yīng)用系統(tǒng)。

當(dāng)然低代碼平臺通常提供的建模功能可能不限于UML，除了類似UML類圖的數(shù)據(jù)結(jié)構(gòu)建模、類似UML狀態(tài)圖的生命周期建模、類似UML活動圖的業(yè)務(wù)流程建模，通常大部分低代碼平臺還提供了表單、表格、報表等一系列建模工具。

圖 常見的低代碼平臺通用建模工具

圖 面向IT的通用建模能力舉例

圖 基于類圖定義MES/MOM的數(shù)據(jù)結(jié)構(gòu)

通用的低代碼平臺為了滿足對各種軟件快速開發(fā)的需求，低代碼平臺不斷增強其建模能力，這通常意味著你的低代碼平臺可能出現(xiàn)與UML語言、漢語類似的問題，擁有太多的概念和符號，更復(fù)雜的建模工具，其結(jié)果是這樣的低代碼平臺使用起來不再容易。

你確定使用這樣的通用建模工具進行建模真的比編寫代碼更加容易？答案也許是否定的，因為要具備掌握一種強大，且具備通用建模能力的建模工具，也不是一件容易的事。

雖然通用的低代碼平臺大幅提高了應(yīng)用開發(fā)效率，但這些工具依然沒提供電源、開關(guān)、燈泡等領(lǐng)域?qū)拥母拍詈捅硎痉?。所以，通用的低代碼平臺無法成為真正的業(yè)務(wù)人員所使用的應(yīng)用開發(fā)工具。