MES/MOM的未來(lái)：低代碼與模型驅(qū)動(dòng)（1）

以下文章來(lái)源于佰思杰 ，作者駱金松

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖 傳統(tǒng)MDE開(kāi)發(fā)過(guò)程和運(yùn)行過(guò)程是分離的

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

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

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

圖 模型驅(qū)動(dòng)開(kāi)發(fā)的幾個(gè)核心概念

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

03 運(yùn)行時(shí)的模型驅(qū)動(dòng)

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

圖 運(yùn)行時(shí)模型驅(qū)動(dòng)的開(kāi)發(fā)運(yùn)行一體化架構(gòu)

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

圖 運(yùn)行時(shí)模型驅(qū)動(dòng)開(kāi)發(fā)的幾個(gè)核心概念

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

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

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

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

圖 專(zhuān)用的電路圖建模工具建模電路圖非常容易

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

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

然而，使用UML去建模一個(gè)電路圖將是非常困難的，因?yàn)閁ML缺少燈、開(kāi)關(guān)、電源、導(dǎo)線等領(lǐng)域概念，首先需要通過(guò)UML類(lèi)圖定義領(lǐng)域?qū)拥母拍?，然后再用領(lǐng)域?qū)拥母拍钊ザx電路，如下圖所示：

圖 通過(guò)UML類(lèi)圖定義電路圖的概念

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

圖 使用UML對(duì)象圖描述電路

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

圖 通用建模語(yǔ)言雖然通用但不萬(wàn)能

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

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

圖 常見(jiàn)的低代碼平臺(tái)通用建模工具

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

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

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

你確定使用這樣的通用建模工具進(jìn)行建模真的比編寫(xiě)代碼更加容易？答案也許是否定的，因?yàn)橐邆湔莆找环N強(qiáng)大，且具備通用建模能力的建模工具，也不是一件容易的事。

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