低代码型与模型驱动型：它们是一样的吗？

由于低代码化成为新的流行语，我想知道与我们过去所说的模型驱动工程/开发相比，低代码化运动是否真的有什么不同。第一次低代码研讨会(2020模型大会的一部分)是花一些时间来反思和记录我对这个主题的想法的完美借口。

接下来你能读到的，是我思考的结果。我还嵌入了我准备展示论文的演讲幻灯片(见底部)。两者都包含了我在发布这篇文章的第一个版本时得到的一些反馈(感谢所有人给我的很好的反馈！)。我相信这(低代码在模型驱动的世界中的定位)是我们作为一个社区需要继续进行的讨论。即使我们没有达成任何共识。

免责声明：1-这是一份简短的立场文件，应以此方式阅读和解释。2-这可能是有争议的。如果你读它的时候觉得被冒犯了，我做得很好。我认为立场文件的重点是做出有力而大胆的声明，帮助开始一场讨论。3-如果两个术语中的一个(“低代码”)没有科学地定义，而需要通过研究一组自称为“低代码”的工具来推断，则很难“科学地”比较这两个术语。

话虽如此，请继续阅读我对低代码运动在模型驱动工程领域中的定位的看法。特别是，我试着对这些问题给出一些部分的答案。

低代码应用程序平台通过大幅减少所需的手工编码量来加速应用程序交付(定义取自Forrester报告[5]，该报告被归因于术语低代码的起源)。这显然不是软件工程社区第一次试图通过组合可视化开发技术(我们称之为“模型”)和代码生成来减少手动编码。事实上，正如Grady Booch所说，软件工程的整个历史都是关于提高抽象水平的。

低代码是减少开发软件应用程序所需的手动编码量的最新尝试。这也是我们从软件工程开始就一直追求的目标，点击推特(Click To Tweet)的低代码可以追溯到模型驱动的工程。但是模型驱动工程本身可以追溯到CASE(计算机辅助软件工程)工具。早在1991年，在著名的CAISE会议的第一届会议上，我们就可以找到这样的论文，阐述这样的概念：“给定最终模型，可以自动生成完整的计算机化信息系统”[2]或“我们得出了一种可以自动生成可执行代码的规范”[4]。

与此同时，低代码在当今商业世界中的影响也很明显，包括一些大胆的预测，但也包括关于最近对低代码工具的投资的实际数字，其中一些工具的商业成功，或者所有最大的软件公司都在确保他们在这个领域提供某种类型的产品。

我们没有针对所有MD*概念的通用定义。我自己的(非正式)定义如下：

模型驱动的工程(MDE)：任何软件工程过程，其中模型具有基础作用并驱动工程任务。

MDA是OMG对MDD的特定愿景，因此依赖于OMG标准的使用。

基于模型的工程/开发：前面各自概念的更软版本。在MBE过程中，软件模型扮演着重要的角色，尽管它们不一定是工程/开发的关键工件(即，它们不“驱动”过程)。

MBE与MDE区别的一个例子是开发过程，在该过程中，在分析阶段，设计人员指定系统的独立于平台的模型，但随后这些模型被直接分发给程序员手动编写代码(不涉及自动代码生成，也不明确定义任何特定于平台的模型)。在这个过程中，模型仍然扮演着重要的角色，但不是开发过程的基础。

基于上述定义，我认为低代码是模型驱动开发的同义词。如果说有什么不同的话，那就是我们可以将低代码视为MDD的一种更严格的观点，我们只针对一种具体类型的软件应用程序：数据密集型Web/移动应用程序。

请注意，术语“无代码”有时用作低代码的细微变体。事实上，我们经常可以看到工具将自己定义为无代码/低代码工具。然而，对我来说，无代码方法的关键特点是应用程序设计人员应该编写零代码来创建和部署应用程序。这很大程度上限制了您使用无代码工具实际可以做的事情。我们基本上是在考虑基于模板的框架或创建将预定义连接器混合到外部应用程序的工作流，在这些应用程序中，设计人员至多决定何时以及如何触发某些操作。

比较这些不同范例的另一种方法是查看您需要编写多少手动代码。在MBE中，您可能必须编写所有代码。相反，在MDD和低代码中，应该生成大部分代码，但是您可能仍然需要定制和完成生成的代码(大多数MDD工具包括某种类型的黑盒建模原语，您可以在其中编写应该在生成过程中添加的任何自定义代码)。在无代码中，您应该编写零代码。

显然，需要更多的研究来评估市场上的低代码工具，并更好地描述它们在不像这里介绍的那些粗粒度类别中的特征。事实上，目前基本上没有关于低码运动的研究(快速搜索只会发现一些关于将自己归类为低码的工具的论文，但没有将低码本身作为研究对象)，我相信本研讨会将开始改变这一点。

如图1所示，即使如图2所示，这个峰值比模型驱动的注意力达到顶峰要小得多，对低级代码的兴趣也是如此。

但是，如果从技术上讲，低代码并没有真正带来什么新东西，为什么会如此受欢迎呢？

首先，我认为低代码比模型驱动/基于模型传达了更清晰的信息。模型是一个模棱两可的词，因此模型驱动的概念比低级代码更难解释(每个人都清楚什么是代码，低级代码变得不言自明)。

其次，我们知道建模会吓跑开发人员。相反，低码听起来更熟悉。这与他们已经在做的(编码)是一样的，但更少了。

而且，低码的应用场景也更加清晰。与其推销您可以使用MDD做任何事情(这最终会产生不信任)，而是针对特定类型的应用程序，即那些行业中最需要的应用程序，低代码看起来更可信。

低代码通常也是一种一次性建模方法，这意味着您拥有模型和生成的代码，没有复杂的精炼链，没有模型转换，什么都没有。

平均而言，低代码的工具比我们传统的繁重的建模工具更好。例如，大多数是基于Web的，不依赖于EMF。

总而言之，我没有在低代码工具中看到任何符号、概念、模型类型或生成技术，这是我在模型驱动的世界中找不到的。但可以肯定的是，这些相同的技术是以不同的方式呈现、配置、调整和“销售”的，这最终会在人们对低代码新颖性和有用性的认知上产生很大的不同。MDE项目的成功往往更多地取决于社会和管理方面，而不是纯粹的技术方面[3]。这不是免费的(缺乏互操作性、供应商锁定、昂贵的商业模式……)。但目前看来，这似乎并没有阻止社会各界。

正如前面指出的，我不认为MDD和低代码化趋势在技术上有什么根本区别。事实上，我们几乎可以接受模型驱动工程中的任何开放挑战[1]，只需改变由“低码”驱动的“模型驱动”，就可以免费获得低码开发的研究路线图(例如，我们需要更好的方法来将人工智能集成到低码工具中，或者我们应该作为一个社区努力为将来的研究建立一个低码范例的共享库)。

但我不认为这是负面的。更多的是相反的。显然，低码吸引了很多人的注意，包括从未参加过模型界的人。从这个意义上说，低代码降低了进入建模技术空间的门槛。因此，对我来说，低代码是将建模(以及我们的建模专业知识)带到新领域和社区的巨大机会。如果我们可以通过将自己重塑为低代码专家来获得更多的资金/曝光率/用户/反馈，我完全支持。这正是许多知名的所谓低码公司所采取的方法(可以随意使用Internet Wayback Machine，看看他们的网站在过去几年里是如何从视觉建模、敏捷开发、CASE工具和类似的关键字转变为低码的)。让我们也借此机会更好地理解使类似建模的技术在广泛的软件社区中引起共鸣的因素，并从中学习。

低代码是将建模(和我们的建模专业知识)带到新的领域和社区的巨大机会，单击Tweet，在我们这样做的同时，让我们关注未来的市场趋势。一些低代码商正在(再次)转移他们的营销努力。也许用不了多久，我们就会开始高呼：低码已死，多经验开发万岁。

安东尼奥·布基亚罗内、乔迪·卡伯特、理查德·F·佩奇和阿方索·皮埃兰托尼奥。模型驱动工程中的重大挑战：研究现状分析。软件和系统建模19，1(2020年)，5-13.https://doi.org/10.1007/s10270-019-00773-6。

乔恩·阿特尔·古拉、奇数·伊瓦尔·林德兰和盖尔·维尔伦森。一九九一年。PPP：一个集成的CASE环境。“高级信息系统工程”，CAISE‘91，挪威特隆赫姆，1991年5月13-15日，学报(计算机科学讲稿，第498卷)。斯普林格，电话194-221。Https://doi.org/10.1007/3-540-54059-8_86。

约翰·爱德华·哈钦森、乔恩·惠特尔和马克·朗斯菲尔德。2014年。工业中的模型驱动工程实践：决定成败的社会、组织和管理因素。SCI。电脑。程序。89(2014)，144-161。Https：//doi.org/10.1016/j.scico.2013.03.017。

约翰·克罗斯蒂、彼得·麦克布莱恩、理查德·欧文斯和安妮·赫尔加·塞尔维特。一九九一年。使用基于过程和基于规则的方法的组合进行信息系统开发。“高级信息系统工程”，CAISE‘91，挪威特隆赫姆，1991年5月13-15日，学报(计算机科学讲稿，第498卷)。斯普林格，319-335。Https://doi.org/10.1007/3-540-54059-8_92。

克莱·理查森和约翰·R·莱默。2014年。面向客户的应用程序出现了新的开发平台。弗雷斯特：美国马萨诸塞州剑桥(2014年)。

互联网跨学科研究所(UOC)ICREA研究教授。SOM研究实验室的领导，专注于广泛的系统工程和软件工程领域。主页。