来源：佰思杰本文约6000字，建议阅读10分钟本文将深度分析低代码、模型驱动的关系，以及如何支撑MES/MOM的未来。

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语言、汉语类似的问题，拥有太多的概念和符号，更复杂的建模工具，其结果是这样的低代码平台使用起来不再容易。

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

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

05 面向业务领域建模

我们的确需要功能强大的通用建模工具，用于去开发应用系统。同时，我们也需要面向不同领域的一系列更简洁、更易用的专用建模工具，这些工具可以提供给不同的领域工程师使用，更高效的开发和维护应用系统，而不是IT工程师。

那么什么是专用建模工具？对于MES/MOM系统来说，系统需要提供哪些领域相关的建模能力？我们举个实际的例子。如下图，对于一个高度柔性自动化的数字孪生智能工厂，我们对生产排程、仓储物流、质量监控、设备监控、设备运维等进行建模。

图 基于模型定义高度柔性自动化的数字孪生智能工厂

建模包括两个方面：静态的部分和动态的部分。

• 结构建模通常是静态的，用于映射工厂的对象和结构关系，例如组织结构、班组/工段、车间布局、工位和连接关系、工位配备的资源，如设备、人力、工具工装，仓库、存储分区、货位结构、车间缓存区、物流配送点、物流设备/容器、配送路线等。

• 行为建模通常是动态的，用于定义系统的行为，包括数据处理、分析、预测、优化和控制等，例如：用户权限规则、日历/资源产能配置、生产排程和调度策略、仓储上/下架策略、物流拉动/配送规则、物流拥塞控制规则、质量预警规则、设备预防性维护策等。

通常需要提供一系列建模工具，分别提供给不同角色的业务人员使用，当工厂的生产布局、工艺流程、组织架构、生产设备、物流路线等发生变化时，主要由这些业务工程师负责对相关的模型进行调整，调整之后不需要生成代码立刻生效，不需要交给程序员去修改代码。

图 面向业务工程师的建模能力

图 生产监控图形化布局设计

图 设备联网建模工具

通过这些建模工具，实际上MES/MOM系统面向业务工程师开放了某种业务领域的建模能力，或者提供了一种面向领域，更加图形化、简单和易于使用的用户界面，或提供了一系列面向领域的建模语言（DSMLs，Domain-Specific Modeling Languages），用来帮助业务人员更高效地创建系统可动态解析的模型。

需要说明的是：虽然提供了面向不同业务领域的建模工具，但是这些建模工具所定义的模型不是彼此独立的，而是互相关联的，大家共同创建和持续维护和优化整个工厂模型。例如，物流模型配送点通常会连接到车间布局中的工位，生产工艺、生产计划也需要与生产资源相匹配。

系统提供通用建模能力当然是必要的，因为通用，所以更复杂，有更高的门槛，这些通用建模工具通常应该面向IT工程师。业务人员并不需要学习一种强大的、且通用的建模语言，而只需要掌握与各自业务相关的建模工具，熟悉相关的概念和建模方法就可以，这极大降低了系统使用的门槛。

图 同时提供面向IT和业务的建模工具

06 分层扩展的架构

当然有好的架构还不够，有远见的MES厂商必须注重产品的标准化、实现分层扩展、打造合作伙伴生态，否则将很难做大规模。对于MES和MOM来说，下图是建议的分层的扩展方式。

图 MES/MOM更好的拆分方式是分层

• 技术平台可以解决架构和技术问题，屏蔽技术细节和复杂性，并提供低代码开发的相关能力，提高整个系统的扩展性和灵活性。

• MES/MOM产品平台解决提供覆盖制造运营全业务流程的共性模块，从而最大限度实现重用，满足共性需求，满足跨组织的协同要求，封装内部的复杂性。

• 行业扩展满足特定行业的扩展，例如提供各个行业层的扩展，实现对细分领域的深耕，从而更好为细分领域客户创造价值。

• 客户扩展是为单个客户而开发的，满足单个客户的共性需求。

其中，第1、2层应该由业界有实力的公司研发，需要很大的投入。第3、4层可以由具有领域Know How和商业资源的集成服务商、实施服务商承担，这样可以很好分工，发挥各自优势，建立合作伙伴生态。

图  MES/MOM产品线业务范围、知识产权范围

这里所说的分层扩展并不仅限于基于模型的扩展，系统可提供快速模块化选配能力，包括开发新的插件，采用层次化、模块化、可插拔的体系架构，可通过现有模块的选配、替换和扩展开发提供快速满足需求的能力，而且在需求调整后可灵活调整。

07 突破技术方面的限制

基于运行时模型驱动（Runtime Model-Driven）的MES/MOM系统架构显然具有很高的技术门槛，这种能力一旦建立，将是难以被复制和模仿的，将形成独特的竞争力，这些挑战主要包括：

首先，不但提供通用建模能力，还需要提供领域建模能力，这需要一套元建模（Metamodeling）设施，可以用来实现模型的持久化、定义建模工具、模型解释器等，对这方面感兴趣的朋友可以去了解一下MOF元建模框架的四层架构，分别是：元元模型层（M3）、元模型层（M2）、模型层（M1）、运行时（M0）。

另一个挑战是性能，系统可以在运行时修改模型，模型改变后系统的行为随之动态改变，可以显著提高MES产品应对需求变化的能力。然而，这种方法需要在运行时动态读取和解释模型，这导致系统的性能下降，使用多级缓存系统优化系统性能，减少数据库访问次数，可以优化系统的运行效率。

图 支持Web及运行时模型驱动的多级缓存系统

笔者对性能进行了测试，系统启动一段时间后，元数据加载到缓存系统后，累计命中率可超过95%。三级缓存系统将运行时间优化为没有添加任何缓存运行时间的1.08％！由此证明了运行时模型驱动的MES系统，多级缓存系统在性能优化方面的巨大威力，系统的整体运行性能接近硬编码的MES系统，但系统的灵活性和扩展性却与硬编码的系统有了巨大的提升。

其中的一个难点是，如何对程序员屏蔽多级缓存系统的复杂性，将缓存系统的复杂性必须封装在底层框架，而不需要MES产品开发人员、二次开发人员面向缓存系统编程，这就需要一套支持多级缓存机制的元数据驱动的对象关系映射框架（Metadata-Driven ORM-Mapping Framework）。这就好像你开车并不需要关注汽车的转向系统、动力系统、刹车系统等汽车的内部结构和原理。

图 对程序员屏蔽多级缓存系统的复杂性

另一个难点是如何实现模型在不同环境中的同步，通常建模在开发环境中进行，需要将模型同步到测试环境，通过测试以后，将模型同步到生产环境。考虑到系统的复杂性，通常建模是一个多人并行开发的环境，需要解决多人建模的模型合并问题。为此，可能需要定义通用模型描述语言，可以用于在不同环境中录制（类似VBA）、传递并重建模型。

这对于绝大多数MES厂商来说，存在着较高的技术壁垒，这正是工业软件的成功难以复制、没法弯道超车的原因吧。

08 运行时模型驱动代表未来

目前中国的MES市场正处于群雄并起，鱼龙混杂的竞争阶段，市场集中度并不高。笔者认为未来5年，将有90%的MES厂商退出历史舞台，主流MES厂商将集中到5到10家。随着部分MES厂商做大规模并上市，形成主流厂商品牌效应，业务会迅速集中到这些主流MES厂商，会加速其他MES厂商的退出。

未来几年国内MES软件市场的竞争将越演越烈，笔者认为，基于运行时模型驱动的架构的MES/MOM系统将更具竞争力，因为面向业务领域的建模是让业务人员低门槛参与MES/MOM系统开发和运维几乎唯一的方法。虽然这条道路上充满了荆棘，困难重重。

09 总结

低代码平台背后的实现技术正是模型驱动，使用模型可以提高抽象层次、降低软件的复杂性，大幅提升系统的开发效率。

运行时模型驱动（Run-time Model-Driven）架构可以更加有利于MES/MOM的开发和运维。

我们的确需要功能强大的通用建模工具，用于去开发应用系统。同时，我们也需要面向不同领域的一系列更简洁、更易用的专用建模工具。

当然有好的架构还不够，有远见的MES厂商必须注重产品的标准化、实现分层扩展、打造合作伙伴生态，否则将很难做大规模。

基于运行时模型驱动（Runtime Model-Driven）的MES/MOM系统架构具有很高的技术门槛，这种能力一旦建立，将是难以被复制和模仿的。

编辑：王菁

校对：汪雨晴