杰茂源低代码与模型驱动在开发中的应用
作者：互联网
01低代码与模型驱动
考虑模型在软件开发中的作用，除了广泛使用的“模型驱动”概念，还有基于模型（Model-based）、面向模型（Model-oriented）、以模型为中心（Model-centric）等等，其中“模型驱动”过去在学术界得到了更多的认同。为啥模型驱动一直不温不火，而低代码怎么突然就火了？
模型驱动一词过于学术化，其中包含的概念元数据（Meta-data）、元模型（Meta-model）、建模语言(Modeling language)、自描述（Self-descripted）等概念理解起来有一定的困难，吓跑了许多民众。而低代码就非常亲民，传达的信息非常清晰，得到业界广泛的认可，在商业上也取得了巨大成功。
在软件开发过程中应用建模技术，其目的是提高抽象层次。计算机软件开发方法的每一次变革都是通过提高抽象层次实现，从机器语言到汇编语言、再到高级语言、可视化建模语言，开发效率得到了显著提升。
低代码的目标是最大限度减少手工的硬编码，意味着必须更多的使用模型，这正是模型驱动工程（MDE，Model-Driven Engineering）的目标和领域。MDE使用模型提供更高抽象层次，来降低软件的复杂性的思想已经存在了20余年：
1)更高抽象层次“领域模型（DomainModels）”➜更具体、繁琐的“代码（Sourcecode）”
2)更易学易用的“建模工具（Modelingtools）”➜高门槛的“编程工具（Programming tools）”
3)更直观的“领域建模（DomainModeling）”➜更偏向技术细节的“编程（Coding）”
其结果是模型驱动的应用程序开发比手工编码的效率有显著的提升，而且基于模型的系统通常更加易于维护。
02模型驱动的架构
创建和使用领域模型是MDE的核心理念。其中最成功的MDE方法是OMG国际组织提出的MDA（Model-Driven Architecture）方法，然而MDE是一种典型的生成式技术，是一种以建模（Modeling）和模型转换（Model Transformation）为主要途径的软件开发方法。
MDA使用模型转换工具将平台无关的模型（PIM，Platform Independent Model）转换为平台相关模型（PSM,Platform Specific Model），最后再进一步转为代码，代码最后编译为应用系统。目前部分低代码平台正是基于模型转换实现的。
这种模式开发过程和运行过程是分离的，建模工具只是在开发期间使用，并不成为系统的一部分，任何对系统的修改都需要进入开发环境，修改模型、重新生成代码、编译。然后进入运行过程，关闭系统、部署系统、重新启动系统。
传统的软件开发过程相关概念我建个模型总结如下：
“模型驱动的架构”的相关概念梳理如下，建模语言替代了编程语言，建模工具替代了编程工具，相对于开发环境直接编写代码，MDA先创建模型再自动生成代码，最后编译为应用系统。
首先，生成式方法产生的代码有些时候不能完全满足客户需求，通常需要手工修改生成的代码，模型就与代码不一致了。其次，通过模型自动生成的代码可能不容易阅读。另外，模型只是软件开发过程中的中间产物，无法在系统运行期间动态修改并立刻生效。
03运行时的模型驱动
运行时模型驱动（Run-time Model-Driven）架构解决了不能在系统运行期间修改模型并立刻生效的问题。建立了一体化的开发和运行环境，在运行的系统中内置建模工具，支持在系统运行时创建和修改模型，并且在运行时借助“模型解释器（Model interpreter）”或“执行引擎（Executionengine）”直接加载、解释和执行模型。
系统运行期间定义的模型作为一种特殊的数据保存在系统中，这种数据称为元数据（Meta-data），不需要停止运行中的系统，可以在系统运行期间修改模型，系统的行为也会随之改变，这被称为运行时的适应性（RuntimeAdaptability），这可以减少停机次数和维护事件。
运行时模型驱动对于降低系统开发和维护门槛、支撑快速开发和运维具有重要价值。通常不需要专业的代码工程师、业务专家或业务工程师不用关注技术细节就可以快速实现系统的定制开发和运维。
当然模型通常不能满足所有的需求，系统也支持基于插件的扩展开发，此时并不需要修改平台本身，而是基于扩展点和API进行。平台还可以提供某种脚本解释器，允许基于平台在线编写脚本，在运行时加载，进行即时编译和执行。
下面讨论一下建模工具、建模语言以及建模能力。如下图的电路，大家应该非常熟悉，基于对中学所学到的知识，只需要极少的符号就很容易精准表示这个电路。然而，电路图建模工具并不适合其他的建模，例如用于描述业务流程、建模大楼的结构，是否存在一种万能的通用建模语言？
首先介绍下什么是通用语言？汉语就是一种通用语言，汉语是一个博大精深的语言，具有强大的表达能力！如果要表达这样的电路可能会是这样的：“直流电源通过导线将一个开关和灯泡串联在一起，从电源正极出发，依次连接开关、灯泡，最后回到电源负极。”
你会说，汉语是一种自然语言，不是一种可视化的语言，如果换作图形化的建模语言，可以更好对电路进行表示。事实上，通过一种通用的建模语言并不容易，这需要强大的建模语言和建模工具，其中影响力最大的应该非统一建模语言(Unified Modeling Language，UML)莫属，UML具有广泛的建模能力。
然而，使用UML去建模一个电路图将是非常困难的，因为UML缺少灯、开关、电源、导线等领域概念，首先需要通过UML类图定义领域层的概念，然后再用领域层的概念去定义电路
然后基于领域层的概念，例如：灯、开关、电源、导线，通过UML对象图，描述各个电路器件，以及如何通过导线连接这些器件。
好像还漏了点什么？哈哈，电源的正负极如何表示？开关是何种开关，有多少个接线端子？当前开关当前处于闭合还是断开的状态？
UML建模语言作为一种通用的建模语言（GPML, General-Purpose Modeling Language），因为必须满足各种各样的通用建模需求，使得其变得更加复杂而难以使用。通用但并非万能，由于缺少领域层的概念，所以难以精确地表达语义，几乎不可能基于UML模型去直接生成一个复杂而完整的应用系统。
当然低代码平台通常提供的建模功能可能不限于UML，除了类似UML类图的数据结构建模、类似UML状态图的生命周期建模、类似UML活动图的业务流程建模，通常大部分低代码平台还提供了表单、表格、报表等一系列建模工具。
通用的低代码平台为了满足对各种软件快速开发的需求，低代码平台不断增强其建模能力，这通常意味着你的低代码平台可能出现与UML语言、汉语类似的问题，拥有太多的概念和符号，更复杂的建模工具，其结果是这样的低代码平台使用起来不再容易。
你确定使用这样的通用建模工具进行建模真的比编写代码更加容易？答案也许是否定的，因为要具备掌握一种强大，且具备通用建模能力的建模工具，也不是一件容易的事。
虽通用的低代码平台大幅提高了应用开发效率，但这些工具依然没提供电源、开关、灯泡等领域层的概念和表示法。所以，通用的低代码平台无法成为真正的业务人员所使用的应用开发工具。
05面向业务领域建模
我们的确需要功能强大的通用建模工具，用于去开发应用系统。同时，我们也需要面向不同领域的一系列更简洁、更易用的专用建模工具，这些工具可以提供给不同的领域工程师使用，更高效的开发和维护应用系统，而不是IT工程师。
那么什么是专用建模工具？对于MES/MOM系统来说，系统需要提供哪些领域相关的建模能力？我们举个实际的例子。如下图，对于一个高度柔性自动化的数字孪生智能工厂，我们对生产排程、仓储物流、质量监控、设备监控、设备运维等进行建模。
建模包括两个方面：静态的部分和动态的部分。
（1）结构建模通常是静态的，用于映射工厂的对象和结构关系，例如组织结构、班组/工段、车间布局、工位和连接关系、工位配备的资源，如设备、人力、工具工装，仓库、存储分区、货位结构、车间缓存区、物流配送点、物流设备/容器、配送路线等。
（2）行为建模通常是动态的，用于定义系统的行为，包括数据处理、分析、预测、优化和控制等，例如：用户权限规则、日历/资源产能配置、生产排程和调度策略、仓储上/下架策略、物流拉动/配送规则、物流拥塞控制规则、质量预警规则、设备预防性维护策等。
通常需要提供一系列建模工具，分别提供给不同角色的业务人员使用，当工厂的生产布局、工艺流程、组织架构、生产设备、物流路线等发生变化时，主要由这些业务工程师负责对相关的模型进行调整，调整之后不需要生成代码立刻生效，不需要交给程序员去修改代码。
通过这些建模工具，实际上MES/MOM系统面向业务工程师开放了某种业务领域的建模能力，或者提供了一种面向领域，更加图形化、简单和易于使用的用户界面，或提供了一系列面向领域的建模语言（DSMLs，Domain-Specific Modeling Languages），用来帮助业务人员更高效地创建系统可动态解析的模型。
需要说明的是：虽然提供了面向不同业务领域的建模工具，但是这些建模工具所定义的模型不是彼此独立的，而是互相关联的，大家共同创建和持续维护和优化整个工厂模型。例如，物流模型配送点通常会连接到车间布局中的工位，生产工艺、生产计划也需要与生产资源相匹配。
系统提供通用建模能力当然是必要的，因为通用，所以更复杂，有更高的门槛，这些通用建模工具通常应该面向IT工程师。业务人员并不需要学习一种强大的、且通用的建模语言，而只需要掌握与各自业务相关的建模工具，熟悉相关的概念和建模方法就可以，这极大降低了系统使用的门槛。
06分层扩展的架构
当然有好的架构还不够，有远见的MES厂商必须注重产品的标准化、实现分层扩展、打造合作伙伴生态，否则将很难做大规模。对于MES和MOM来说，下图是建议的分层的扩展方式。
1)技术平台可以解决架构和技术问题，屏蔽技术细节和复杂性，并提供低代码开发的相关能力，提高整个系统的扩展性和灵活性。
2)MES/MOM产品平台解决提供覆盖制造运营全业务流程的共性模块，从而最大限度实现重用，满足共性需求，满足跨组织的协同要求，封装内部的复杂性。
3)行业扩展满足特定行业的扩展，例如提供各个行业层的扩展，实现对细分领域的深耕，从而更好为细分领域客户创造价值。
4)客户扩展是为单个客户而开发的，满足单个客户的共性需求。
其中，第1、2层应该由业界有实力的公司研发，需要很大的投入。第3、4层可以由具有领域KnowHow和商业资源的集成服务商、实施服务商承担，这样可以很好分工，发挥各自优势，建立合作伙伴生态。
标签：建模语言,杰茂源,代码,建模,UML,驱动,工具,模型 来源： https://blog.csdn.net/JMYcloud/article/details/116990307