MES/MOM的未來:低代碼與模型驅(qū)動(1)
以下文章來源于佰思杰 ,作者駱金松
01 低代碼與模型驅(qū)動
筆者認為,“低代碼”幾乎是“模型驅(qū)動(Model-Driven)”的同義詞,從現(xiàn)在絕大多數(shù)低代碼平臺的實現(xiàn)來看,低代碼平臺背后的實現(xiàn)技術(shù)正是模型驅(qū)動,帶來的新東西并不多。
考慮模型在軟件開發(fā)中的作用,除了廣泛使用的“模型驅(qū)動”概念,還有基于模型(Model-based)、面向模型(Model-oriented)、以模型為中心(Model-centric)等等,其中“模型驅(qū)動”過去在學術(shù)界得到了更多的認同。為啥模型驅(qū)動一直不溫不火,而低代碼怎么突然就火了?
模型驅(qū)動一詞過于學術(shù)化,其中包含的概念元數(shù)據(jù)(Meta-data)、元模型(Meta-model)、建模語言(Modeling language)、自描述(Self-descripted)等概念理解起來有一定的困難,嚇跑了許多民眾。而低代碼就非常親民,傳達的信息非常清晰,得到業(yè)界廣泛的認可,在商業(yè)上也取得了巨大成功。
圖 “低代碼”幾乎是“模型驅(qū)動(Model-Driven)”的同義詞
在軟件開發(fā)過程中應(yīng)用建模技術(shù),其目的是提高抽象層次。計算機軟件開發(fā)方法的每一次變革都是通過提高抽象層次實現(xiàn),從機器語言到匯編語言、再到高級語言、可視化建模語言,開發(fā)效率得到了顯著提升。
低代碼的目標是最大限度減少手工的硬編碼,意味著必須更多的使用模型,這正是模型驅(qū)動工程(MDE,Model-Driven Engineering)的目標和領(lǐng)域。MDE使用模型提供更高抽象層次,來降低軟件的復雜性的思想已經(jīng)存在了20余年:
更高抽象層次“領(lǐng)域模型(Domain Models)”?更具體、繁瑣的“代碼(Source code)”
更易學易用的“建模工具(Modeling tools)”?高門檻的“編程工具(Programming tools)”
更直觀的“領(lǐng)域建模(Domain Modeling)”?更偏向技術(shù)細節(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ù)細節(jié)就可以快速實現(xiàn)系統(tǒng)的定制開發(fā)和運維。
當然模型通常不能滿足所有的需求,系統(tǒng)也支持基于插件的擴展開發(fā),此時并不需要修改平臺本身,而是基于擴展點和API進行。平臺還可以提供某種腳本解釋器,允許基于平臺在線編寫腳本,在運行時加載,進行即時編譯和執(zhí)行。
04 通用建模能力是不足夠的
下面討論一下建模工具、建模語言以及建模能力。如下圖的電路,大家應(yīng)該非常熟悉,基于對中學所學到的知識,只需要極少的符號就很容易精準表示這個電路。然而,電路圖建模工具并不適合其他的建模,例如用于描述業(yè)務(wù)流程、建模大樓的結(jié)構(gòu),是否存在一種萬能的通用建模語言?
圖 專用的電路圖建模工具建模電路圖非常容易
首先介紹下什么是通用語言?漢語就是一種通用語言,漢語是一個博大精深的語言,具有強大的表達能力!如果要表達這樣的電路可能會是這樣的:“直流電源通過導線將一個開關(guān)和燈泡串聯(lián)在一起,從電源正極出發(fā),依次連接開關(guān)、燈泡,最后回到電源負極?!?/p>
你會說,漢語是一種自然語言,不是一種可視化的語言,如果換作圖形化的建模語言,可以更好對電路進行表示。事實上,通過一種通用的建模語言并不容易,這需要強大的建模語言和建模工具,其中影響力最大的應(yīng)該非統(tǒng)一建模語言(Unified Modeling Language,UML)莫屬,UML具有廣泛的建模能力。
然而,使用UML去建模一個電路圖將是非常困難的,因為UML缺少燈、開關(guān)、電源、導線等領(lǐng)域概念,首先需要通過UML類圖定義領(lǐng)域?qū)拥母拍睿缓笤儆妙I(lǐng)域?qū)拥母拍钊ザx電路,如下圖所示:
圖 通過UML類圖定義電路圖的概念
然后基于領(lǐng)域?qū)拥母拍?,例如:燈、開關(guān)、電源、導線,通過UML對象圖,描述各個電路器件,以及如何通過導線連接這些器件。
圖 使用UML對象圖描述電路
好像還漏了點什么?哈哈,電源的正負極如何表示?開關(guān)是何種開關(guān),有多少個接線端子?當前開關(guān)當前處于閉合還是斷開的狀態(tài)?
圖 通用建模語言雖然通用但不萬能
UML建模語言作為一種通用的建模語言(GPML, General-Purpose Modeling Language),因為必須滿足各種各樣的通用建模需求,使得其變得更加復雜而難以使用。通用但并非萬能,由于缺少領(lǐng)域?qū)拥母拍?,所以難以精確地表達語義,幾乎不可能基于UML模型去直接生成一個復雜而完整的應(yīng)用系統(tǒ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語言、漢語類似的問題,擁有太多的概念和符號,更復雜的建模工具,其結(jié)果是這樣的低代碼平臺使用起來不再容易。
你確定使用這樣的通用建模工具進行建模真的比編寫代碼更加容易?答案也許是否定的,因為要具備掌握一種強大,且具備通用建模能力的建模工具,也不是一件容易的事。
雖然通用的低代碼平臺大幅提高了應(yīng)用開發(fā)效率,但這些工具依然沒提供電源、開關(guān)、燈泡等領(lǐng)域?qū)拥母拍詈捅硎痉āK?,通用的低代碼平臺無法成為真正的業(yè)務(wù)人員所使用的應(yīng)用開發(fā)工具。
*博客內(nèi)容為網(wǎng)友個人發(fā)布,僅代表博主個人觀點,如有侵權(quán)請聯(lián)系工作人員刪除。