十三年前，他开发了一门编程语言，附带完整IDE。按他自己的说法，这是全球第一门、也是目前唯一一门功能完整的模型导向编程语言。
他用这套技术（Mo+）在自己的项目和工作场所的企业项目上取得了不错的效果。但有一个问题始终没解决：没能把想法卖给更广泛的受众。
六年前，他离开了软件工程行业，跑去挪威、英国以及斯堪的纳维亚其他未来会去的地方，挥斧头造维京船和盎格鲁-撒克逊船。人离开了，脑子没停——他时不时还会想起模型导向编程，以及它的潜力。
这篇文章想干什么
他写这篇文章，不是为了讲自己开发的技术，而是想推动模型导向语言的研究、开发和使用。他明确说，希望能为大学或企业正在进行的相关研究做点贡献，也请读者告诉他，哪里有人在搞模型导向编程语言的研发。
他坚信模型导向编程语言这个家族有巨大的未来潜力，甚至可能尤其是在当下这个AI世界里。他希望这篇文章能让人更深入地看看这种潜力。
他接下来要列出的原则和特性，除非特别说明，都不是纯理论——它们在企业系统里实际用了好几年。
模型到底是什么
模型有很多种，描述模型的方式也有很多种。核心在于：模型的目的是简洁地表示另一个更大或更复杂的东西。
对于模型导向编程，需要一个电子化的模型定义。他给出的定义是：模型可以用结构和数据来描述。结构定义了模型的规则或“模式”，并且始终是层级化的。一个具体的模型由符合该结构的数据填充。
模型结构可以简单地用节点和属性来定义。
有人可能不信模型结构总能是层级化的、只有一个根节点。他拿Northwind数据库的一部分做例子。有人会说“这不层级啊”。他的回应是：我们看的不是模型结构，而是模型数据。关系数据库的表里的数据行是运行时数据，不是他说的东西。模式才是模型数据的一个例子。
在关系数据库IDE里，模式能以树状视图显示，层级结构一目了然。所以关系数据库的模型结构包含数据库、表、列、键这些节点，它们整齐地落在一个层级里。
有人会说“等等，外键引用了表，层级被打破了”。他用一条规则很简单地处理了这个问题。有了这条规则，就能有非常复杂的模型结构，同时整齐地落在层级里。他补充说，好的模型结构定义里，节点定义在它们能独立存在的最高层级上。
一个餐厅场景，三种结构
文章剩下的部分用一个简化的餐厅场景，用不同方式建模，解释怎么用模型导向编程语言针对这个场景编程。
他先给出一个实体关系模型（伪Shlaer-Mellor格式）来说明这个场景。再次强调，在这个场景里，这个模型代表的是数据，不是结构。
然后进入模型结构。他给出一个实体关系图，可以表示支持上述模型数据的结构。这个结构的根节点是Model，子节点有Entity、Relationship等。实线代表模型结构的层级，虚线代表交替的关联。填充这个结构时，Entity的实例包括Restaurant、Customer、Staff等，Restaurant Entity属性的实例包括Id、Name、Location等。
这是表示数据的唯一或最佳结构吗？当然不是，有很多可能。他又给出一个备选的实体关系模型结构，把Entity、Relationship、Property放在同一层级。如果关系和属性可以独立于实体存在，这可能说得通。
还有第三种结构：关系和属性需要依附实体才能存在，关系是源实体的子节点。
他之所以提出这些备选结构，是因为这对模型导向编程语言有影响——层级在遍历时稍微更方便一些。这一点后面会详细解释。
他强烈认为，用结构和数据来定义模型，是一个极其重要的基础原则，它打开了一个模型导向编程语言的家族。
几个定义
继续之前，他给了几个定义：
- 建模：用数据填充模型结构的过程。
- 模型导向编程（MOP）：利用模型来创建和维护一个系统（本文语境下指软件系统）的过程。
- 模型导向开发（MOD）：创建并利用模型来创建和维护一个系统的过程。换句话说，MOD包含建模和MOP。
文章到这里还没展开完，但他想推动这件事的意图已经很清楚：这套东西他用过、有效，只是没能让更多人用上。现在他把目光投向AI时代，觉得模型导向语言的价值可能比当年更大。
热门跟贴