MES/MOM的未来：低代码与模型驱动（1）

以下文章来源于佰思杰 ，作者骆金松

01 低代码与模型驱动

笔者认为，“低代码”几乎是“模型驱动（Model-Driven）”的同义词，从现在绝大多数低代码平台的实现来看，低代码平台背后的实现技术正是模型驱动，带来的新东西并不多。

考虑模型在软件开发中的作用，除了广泛使用的“模型驱动”概念，还有基于模型（Model-based）、面向模型（Model-oriented）、以模型为中心（Model-centric）等等，其中“模型驱动”过去在学术界得到了更多的认同。为啥模型驱动一直不温不火，而低代码怎么突然就火了？

模型驱动一词过于学术化，其中包含的概念元数据（Meta-data）、元模型（Meta-model）、建模语言(Modeling language)、自描述（Self-descripted）等概念理解起来有一定的困难，吓跑了许多民众。而低代码就非常亲民，传达的信息非常清晰，得到业界广泛的认可，在商业上也取得了巨大成功。

图 “低代码”几乎是“模型驱动（Model-Driven）”的同义词

在软件开发过程中应用建模技术，其目的是提高抽象层次。计算机软件开发方法的每一次变革都是通过提高抽象层次实现，从机器语言到汇编语言、再到高级语言、可视化建模语言，开发效率得到了显著提升。

低代码的目标是最大限度减少手工的硬编码，意味着必须更多的使用模型，这正是模型驱动工程（MDE，Model-Driven Engineering）的目标和领域。MDE使用模型提供更高抽象层次，来降低软件的复杂性的思想已经存在了20余年：

• 更高抽象层次“领域模型（Domain Models）”➜更具体、繁琐的“代码（Source code）”

• 更易学易用的“建模工具（Modeling tools）”➜高门槛的“编程工具（Programming tools）”

• 更直观的“领域建模（Domain Modeling）”➜更偏向技术细节的“编程（Coding）”

其结果是模型驱动的应用程序开发比手工编码的效率有显著的提升，而且基于模型的系统通常更加易于维护。

02 模型驱动的架构

创建和使用领域模型是MDE的核心理念。其中最成功的MDE方法是OMG国际组织提出的MDA（Model-Driven Architecture）方法，然而MDE是一种典型的生成式技术，是一种以建模（Modeling）和模型转换（Model Transformation）为主要途径的软件开发方法。

图 模型驱动的方法MDA

如下图，MDA使用模型转换工具将平台无关的模型（PIM，Platform Independent Model）转换为平台相关模型（PSM, Platform Specific Model），最后再进一步转为代码，代码最后编译为应用系统。目前部分低代码平台正是基于模型转换实现的。

图 MDA将模型最终转换为代码

这种模式开发过程和运行过程是分离的，建模工具只是在开发期间使用，并不成为系统的一部分，任何对系统的修改都需要进入开发环境，修改模型、重新生成代码、编译。然后进入运行过程，关闭系统、部署系统、重新启动系统。

图 传统MDE开发过程和运行过程是分离的

传统的软件开发过程相关概念我建个模型总结如下：

图 传统软件开发的核心概念

“模型驱动的架构”的相关概念梳理如下，建模语言替代了编程语言，建模工具替代了编程工具，相对于开发环境直接编写代码，MDA先创建模型再自动生成代码，最后编译为应用系统。

图 模型驱动开发的几个核心概念

首先，生成式方法产生的代码有些时候不能完全满足客户需求，通常需要手工修改生成的代码，模型就与代码不一致了。其次，通过模型自动生成的代码可能不容易阅读。另外，模型只是软件开发过程中的中间产物，无法在系统运行期间动态修改并立刻生效。

03 运行时的模型驱动

运行时模型驱动（Run-time Model-Driven）架构解决了不能在系统运行期间修改模型并立刻生效的问题。建立了一体化的开发和运行环境，在运行的系统中内置建模工具，支持在系统运行时创建和修改模型，并且在运行时借助“模型解释器（Model interpreter）”或“执行引擎（Execution engine）”直接加载、解释和执行模型。

图 运行时模型驱动的开发运行一体化架构

系统运行期间定义的模型作为一种特殊的数据保存在系统中，这种数据称为元数据（Meta-data），不需要停止运行中的系统，可以在系统运行期间修改模型，系统的行为也会随之改变，这被称为运行时的适应性（Runtime Adaptability），这可以减少停机次数和维护事件。

图 运行时模型驱动开发的几个核心概念

运行时模型驱动对于降低系统开发和维护门槛、支撑快速开发和运维具有重要价值。通常不需要专业的代码工程师、业务专家或业务工程师不用关注技术细节就可以快速实现系统的定制开发和运维。

当然模型通常不能满足所有的需求，系统也支持基于插件的扩展开发，此时并不需要修改平台本身，而是基于扩展点和API进行。平台还可以提供某种脚本解释器，允许基于平台在线编写脚本，在运行时加载，进行即时编译和执行。

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

下面讨论一下建模工具、建模语言以及建模能力。如下图的电路，大家应该非常熟悉，基于对中学所学到的知识，只需要极少的符号就很容易精准表示这个电路。然而，电路图建模工具并不适合其他的建模，例如用于描述业务流程、建模大楼的结构，是否存在一种万能的通用建模语言？

图 专用的电路图建模工具建模电路图非常容易

首先介绍下什么是通用语言？汉语就是一种通用语言，汉语是一个博大精深的语言，具有强大的表达能力！如果要表达这样的电路可能会是这样的：“直流电源通过导线将一个开关和灯泡串联在一起，从电源正极出发，依次连接开关、灯泡，最后回到电源负极。”

你会说，汉语是一种自然语言，不是一种可视化的语言，如果换作图形化的建模语言，可以更好对电路进行表示。事实上，通过一种通用的建模语言并不容易，这需要强大的建模语言和建模工具，其中影响力最大的应该非统一建模语言(Unified Modeling Language，UML)莫属，UML具有广泛的建模能力。

然而，使用UML去建模一个电路图将是非常困难的，因为UML缺少灯、开关、电源、导线等领域概念，首先需要通过UML类图定义领域层的概念，然后再用领域层的概念去定义电路，如下图所示：

图 通过UML类图定义电路图的概念

然后基于领域层的概念，例如：灯、开关、电源、导线，通过UML对象图，描述各个电路器件，以及如何通过导线连接这些器件。

图 使用UML对象图描述电路

好像还漏了点什么？哈哈，电源的正负极如何表示？开关是何种开关，有多少个接线端子？当前开关当前处于闭合还是断开的状态？

图 通用建模语言虽然通用但不万能

UML建模语言作为一种通用的建模语言（GPML, General-Purpose Modeling Language），因为必须满足各种各样的通用建模需求，使得其变得更加复杂而难以使用。通用但并非万能，由于缺少领域层的概念，所以难以精确地表达语义，几乎不可能基于UML模型去直接生成一个复杂而完整的应用系统。

当然低代码平台通常提供的建模功能可能不限于UML，除了类似UML类图的数据结构建模、类似UML状态图的生命周期建模、类似UML活动图的业务流程建模，通常大部分低代码平台还提供了表单、表格、报表等一系列建模工具。

图 常见的低代码平台通用建模工具

图 面向IT的通用建模能力举例

图 基于类图定义MES/MOM的数据结构

通用的低代码平台为了满足对各种软件快速开发的需求，低代码平台不断增强其建模能力，这通常意味着你的低代码平台可能出现与UML语言、汉语类似的问题，拥有太多的概念和符号，更复杂的建模工具，其结果是这样的低代码平台使用起来不再容易。

你确定使用这样的通用建模工具进行建模真的比编写代码更加容易？答案也许是否定的，因为要具备掌握一种强大，且具备通用建模能力的建模工具，也不是一件容易的事。

虽然通用的低代码平台大幅提高了应用开发效率，但这些工具依然没提供电源、开关、灯泡等领域层的概念和表示法。所以，通用的低代码平台无法成为真正的业务人员所使用的应用开发工具。