AI时代的软件开发-重回MDA模型驱动架构思想(模型架构映射业务开发)

01-MDA模型驱动架构概述

为了解决软件开发中出现的种种问题，全球最大的软件工业标准化组织国际对象管理组织(OMG，Object Management Group)，在2001年7月提出了模型驱动架构(MDA，Model Driven Architecture)。
MDA是一种基于诸如统一建模语言(UML)、可扩展标记语言(XML)，和公共对象请求代理体系结构(CORBA)等一系列业界开放标准的框架，因此，它具备软件设计和模型的可视化、存储和交换的功能。

MDA能够创建出机器可读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存。
MDA把建模语言用作一种编程语言而不仅仅是设计语言。
MDA是为应对业务和技术的快速变化提出的一种开放、中立的系统开发方法和一组建模语言标准的集合，其最终目的是构建可执行模型，实现软件的工厂化生产。
MDA是软件开发模式从以代码为中心向以模型为中心转变的里程碑，被面向对象技术界预言为未来最重要的方法学。

模型驱动架构是以模型为核心并由模型映射驱动开发的过程。
MDA环境下的系统开发方式就是在开发活动中通过创建各种模型精确描述不同的问题域，并利用模型转换来驱动包括分析、设计和实现等在内的整个软件开发过程。

在MDA开发过程，可从三个不同的层次建立系统模型。

MDA（Model-Driven Architecture，模型驱动架构）是一种软件架构设计方法论，其基本概念是将系统开发过程中的不同层次和部分用各种形式的建模语言描述为不同的模型。
这些模型可以被进一步转换或者细化成为具体实现。

软件开发正在变得更加简单,这要归功于计算机语言发明者、工具开发者和过程专家们的不懈努力,但是从一系列需求到正确抽象解决方案的过程仍然困难重重。
即使是相对简单的系统也可能包含大量的复杂性,这就导致人们需要开发模型。
模型是对某事物的简化,以便我们可以查看、操作和推理它,从而帮助我们理解研究对象中固有的复杂性。

各种各样的模型在不同工程学科中已经使用了很长时间。
航空工程师严重依赖描述飞机所受力的模型;电气工程师使用大型模型来设计电话交换系统;没有蓝图,土木工程师就会迷失方向。
其他形式的模型,例如高级金融中使用的模拟和好莱坞导演使用的剧本分镜头,也发挥着重要作用。

抽象、分类和聚合

不论哪个学科,模型化者都会忽略某些无关的信息,并根据共同的属性将重要的信息分组,即使研究的实体之间肯定有所不同。
这就涉及到抽象和分类。

抽象是IT领域很重要的概念，可以理解为从泛化的实例到类的一个抽象过程，类是一个虚拟概念，更多的是描述了具备相同属性的一类事物的共同特性。
而分类则是进一步对共同属性进行分组。

假设我们面对一个宠物店老板,他需要一些软件来帮助生意。

抽象涉及从左列向右列移动,而分类涉及从上行向下行移动。

左上角显示了一个包含各种真实的、抽象的或假设的事物的论域,在本例中,是一只猫Munchkin,一条狗Fido和一只无名的蛞蝓(它不是宠物,所以为什么要给它起名字?)。
我们根据它们的共同特性对这些生物进行分类:所有狗在一定程度上都会流口水,所有猫或多或少都有疏远或亲昵的性格。

这些分组 Dogs、Cats 和 Distracting Animals 如左下角所示。
注意,分类事物并不改变细节量;相反,它更像是一种根据共性进行分组或建立集合的操作。

第二个重要维度是抽象。
宠物的某些属性不是相关的,比如皮毛的确切颜色或睡眠习惯。
我们发现的某些生物本身也不相关——它们存在,但它们的主要属性是我们不太关心。
我们从每个实体的原始属性中抽象出只留下感兴趣的属性。
注意,抽象并不意味着真实世界中宠物主人所喜爱的独特之处消失了;相反,抽象只约束感兴趣的属性。

狗和猫的共同特征(在本例中为名字和体重)也概括成一个独立的类Pet。
所有宠物共同特征的这种分组称为概括。
这是“双重”分类,因为单个动物,比如Fido,既被分类为Dog又被分类为Pet。
模型化者通常会组合分类、抽象和概括这三个步骤,因此可以同时完成它们。

02-AI和ChatGPT下的自然语言编程

对于采用ChatGPT，通过自然语言编程进行功能开发是我一直在摸索和尝试的一个事情。
在前面也专门验证了包括办公自动化，运维自动化，网页爬虫，视频字幕抓取等各种场景。

而自己最想做的还是传统的Web应用的开发能否完全通过自然语言编程来实现。
在前面个人尝试了采用Springboot+VUE框架来开发一个web应用功能。
但是仍然是感觉整体框架偏重，涉及到的各种分层和各类配置文件太多，通过自然语言编程去开发相对来说比较繁琐。

也正是这个原因，个人给出了自然语言开发框架和平台选择上最好能够满足如下要求和约束，具体为：

基于以上思考，我在前面画了一个简图进行说明：

在AI和ChatGPT时代，我们编写的Prompt提示语就是关键的模型。
但是我原来的思路下存在的问题是将业务语义和平台语义实现语义混合在了一起。

比如我实现一个基本的用户CRUD功能。

如果是Python语言实现，可能的语义描述是：

我希望实现一个用户表(user_id,user_name,type,Address)的CRUD功能，需要通过python语言来实现，前端采用Flask框架。
后端采用Mysql数据库。

如果是Java语言实现，可能的语义描述是：

我希望实现一个用户表(user_id,user_name,type,Address)的CRUD功能，需要通过java语言实现，采用springboot来开发后端微服务，前端采用VUE框架，后端数据库采用Oracle数据库。

而在MDA模型驱动架构思想下，我们真正需要做的是将promt提示语模型化，将业务模型和平台实现模型分离。
我们对自然语言编程的实践本质将变化为对模型的训练和抽象。

模型本身应该更好衔接现实世界和IT抽象世界。
传统的MDA架构思想出来了20多年但是并没有大范围得到使用，一个本质的原因还是MDA建模工作量巨大，而且模型设计复杂度相当大。

但是在AI时代，借助AI能力可以更加高效去构建语义模型。

03-数字模型而非数据模型

前两天在和朋友沟通数字原生和数字模型的时候，我发表了如下看法：

在AI时代到来后，技术加速使每个人都变成了“超级个体”，能做的远比想象的要多这时候最关键的就是你想要解决什么问题如何让你聚焦在这个问题上，成为解决者和发现者

数字环境本身就应该是现实物理世界和抽象虚拟世界的融合环境，我们为了理解和解构的方便将其人为的拆分为了两个独立的环境，然后又去解决两个环境的匹配问题。

真实的数字环境应该回归到融合的本源状态，所有的组织，人，业务，流程，应用，技术都应该为数字环境服务。
数字原生的思路不应该再按传统的拆分后再匹配的思路去研究，而是应该到更高层面的系统工程学思路去思考。

人，机，环境，资源，设备都仅仅是大系统里面的一个组件或节点。

数字模型不是简单的静态数据模型，而是融入了事物内在运行机制的静态+动态模型，组件+组件之间关系是静态的，但是组件协同反映出来的行为是动态的。

基于数字模型的孪生实现双向映射能力，一个是数字模型能够映射应用，一个是应用运行中能够自我纠偏模型。
这种双向映射和联动才是关键。

模型驱动，MBSE，MDA各种思想和实践早就有。
按MDA思想真正要做的是PIM平台和实现无关模型，这个模型连接现实需求和最终应用实现。
这个模型要能够具备双向映射能力。

04-模型是现实世界和抽象世界的关键纽带

在MDA架构思想下有CIM，PIM和PSM三类模型。
对于CIM可以理解为对现实世界的业务抽象和建模。
对于PSM则是结合了平台，语言，分层架构，实现技术的建模。
而真正处于元模型核心位置的是PIM平台无关模型。

PIM模型正是连接现实世界和抽象世界的关键纽带。

在自然语言编程实践中，核心将变成了三类模型的分离。
同时基于数字孪生的思想，对于CIM模型和PSM模型的任何变动都能够双向映射到最核心的PIM模型上面。

正向映射思路：

我对CIM业务建模进行了修改，那么可以快速的反映到PIM模型上，同时结合我的PSM模型生成特定平台特定语言下的源代码文件和执行程序。

反向映射思路：

我对PSM模型或者我的应用运行时提出了新的需求，发现原有模型并不能很好的支撑该需求。
那么在需求最终实现后能够自我复盘，将新的需求作为改进点，自动去调整我的PIM模型设计。

而当前的问题恰好就是只有正向驱动思路，没有反向映射和自我优化思路。
虽然正向驱动也可以多次修改后重复生成新的模型和应用，但是并没有解决模型的自我进化问题。

真正的数字模型和数字孪生一定是双向映射的。
我对最终IT应用的优化需求也能够反向调整到模型上面。

自然语义描述的业务模型化

自然语义不是模型，要基于模型驱动思路进行设计和实现，首先要解决的第一个点就是自然语义的需求内容的业务模型化问题。

这个对应的CIM模型实现。
而且借助AI和GPT可以极大加速我们实现业务需求模型化的过程。
业务模型的本质仍然是组织，流程，业务活动，业务对象，业务规则和逻辑。

也就是说对AI的训练第一步是将我们对业务架构，业务建模的理解抽象为一个模型输入给AI进行训练，让AI真正理解我们需要的业务建模内容抽象。

比如我们对业务建模和业务建模的抽象完全可以参考EA企业架构的思路，从流程，组织，业务对象，活动，规则多个维度进行建模和抽象。

那么我们最终只需要输入原始的业务需求，由AI来完成系统需求（CIM模型）的梳理和完善。

从CIM模型到PIM模型

对于PIM模型的本质可以理解为IT架构设计里面的高层领域建模，这个建模和语言无关，和实现技术和平台无关，和数据库无关，和具体架构如何分层无关。

PIM模型的本质是抽象，分离，聚合，关联。

但是PIM模型不应该是静态模型，而是包括了架构内置运行机制逻辑的静态+动态结合模型。
PIM模型本身由大量的构件组成，这些构件相互关联依赖，通过组合和协同运作来完成最终的业务场景需求的实现。

PIM模型的本质仍然是编程思想逻辑的抽象，最终体现在类，接口，方法逻辑的实现上面。
将现实世界CIM模型中的业务对象转化为类或接口，将业务对象的行为转变为方法，将业务对象的公有特点转变为类的属性。

要解决这个转化一个是需要构建一套PIM模型的模板，比如参考UML模型的思路能够形式化表达出现关键的模型。
其次是需要构建从CIM模型到PIM模型的映射规则。

PIM模型底层应该是一个稳定的元模型。

映射规则+底层元模型-》生成满足业务的PIM模型。

我们对AI的第二阶段训练就是希望对构建一个PIM的元模型逻辑，同时抽象出从CIM到PIM的映射规则，将映射规则条目化。

从PIM到PSM模型的实现逻辑

最后一步即从PIM到PSM，PSM已经是完全可以结合语言，架构，数据库，分层的实现模型。
可以生成完整的源代码。

那么一套PIM模型既可以生成python+flask语言的应用实现，也可以生成Java微服务架构，前后端分离的应用实现。
这里的关键点仍然是PSM的语言平台相关元模型的构建，从PIM到PSM映射规则的条目化描述。

所有对AI和ChatGPT的训练本质将变成对PSM元模型的学习和理解，对模型映射规则的理解。

我们可以将我们已有的软件开发项目实践内容转化和抽象为PSM元模型描述，让AI理解这个PSM元模型的架构特点。
其次可以基于已有实践项目给出从PIM模型到PSM模型的映射参考。

从PSM模型到最终的代码生成和实现

在MDA架构思想下需要模型编译器来完成模型的代码生成和实现操作。

模型编译器会根据一致的规则集,将一组标记的可执行UML模型编织在一起,因此将所有模型规范化到单一的通用基础架构。
这个任务包括在各种源模型和目标模型之间执行映射函数,以产生一个包括系统中所有的结构、行为和逻辑(所有的东西)的单一全面的模型库。

模型编译器为整个系统施加了单一的体系结构结构。
因为每个可执行模型都是PIM,而模型编译器编译模型以生成代码,你可能会问PSM怎么了。
PSM就在那里 - 它就是代码。
代码是PIM元素和所需平台的纽带，而且它也执行了。
使用可执行模型,就不需要操作PSM或将其可视化为模型。
我们可以直接生成代码,这是所有PSM之母。

而在借助GPT后可以看到，这个编译器和代码生成能力将完全被GPT的能力所替代。
我们需要做的就是让GPT学习我们定义的PSM模型，理解这个PSM，同时给出参考映射规则让GPT能够实现基于模型的代码生成。

作者:何明璐

来源:微信公众号:人月聊IT

出处:https://mp.weixin.qq.com/s/AiroaWEOu48gcs-CSRBhrg

标签：模型实现