围绕一般模型化关系的若干讨论

提要：什么话题能够把物理的、计算机的、认知的、数学与逻辑乃至哲学的问题无缝联系在一起，语言、信息？这里说的则是模型。跨越特定领域的通用模型概念定义以及一般模型化关系，是做出有效讨论的起点。

欧阳余山先生长期研究表达理论及从事企业建模与信息资源规划实践。在《作为模型而起作用的实体》一文和与笔者的讨论中，余山对模型驱动应用（MDApp）及其架构原理模型驱动机制（MDM）做了一些评论，点到了若干颇为关键的要点。一般模型化关系是不久前才发布的，它是在 MDM 基础上更一般化和严谨的表述，并且阐明了与经典模型化关系间的联系；因此，笔者将讨论转到这个基础上来。零星提到不少话题，比较散乱，这里汇总一下，叙述得更清楚、条理些——也免得辛辛苦苦码了一段评论，莫名其妙就被那些博客平台伟光正的审核机制给黑了。

从对表达的二元指称关系的突破说起

一般模型化关系是在经典三元模型化关系和模型驱动机制（MDM）基础上建立的完整表述。正如余山指出，一般模型化关系突破了符号对现实世界表达的二元指称关系，涉及到概念模型（及/或所谓数据模型、信息模型，或具体如企业模型、业务流程模型等）的“应用秘密”。实际上，提出一般模型化关系基本背景之一，是经典三元模型化关系，可表示为三元组（主体，模型，对象）：主体（Subject）建立和使用对象的模型。而符号表达具有相似的讨论背景，即（概念，符号，所指物）：这是正是经典的意义三角，而主体则隐藏在“概念”的背后，或者被默认为第四者。留意它与经典三元模型化关系之间的对应。

模型化关系是对“符号”（signs）认识层次的超越，即符号学（Semiotics）所在：在那里，一切围绕符号展开：符号的效用、行为及其作为知识等等。尽管符号学也强调符号作为系统，但其出发点和根本内容始终是符号个体及其集合、关系（序列等）、编码与解码。这个层次上的突破，已经显现在经典三元模型化关系上，但从实际情形看，许多模型研究与实践者没有真正意识到这一点或其重要性，并在此基础上进一步拓展，反而在实际的研究中退回到符号学的层次去寻求答案和理论性支撑。一般的语言/语义学研究与之密切关联，基本处于同样的层次上。

进一步，笔者认为，模型与其对象的关系从根本上是整体性的，涉及二者的拓扑性质及联系。模型表达了其对象的某些性质，这是通常的理解。从表达理论的角度，笔者记得很久前和余山提起过拓扑性质对于表达理论的重要性，拓扑不变性是可表达的基础，它可能是建立“异质”对象（余山喜欢的说法）之间的表达关系的根据。人们所熟知的数学抽象，是集合上的映射/函数关系。这是一种集体关系，但仅仅是阶梯的入口。踏上阶梯，首先要考察涉及“数学结构”的关系，而不仅仅是集合、映射及运算等；再进一步，从某种整体性立场上，集合的要素（例如符号）就沦为一些“点”而已。于是，计算数学教科书中不常见或不曾见的角色就自然登场了：从数学结构导入模型论；从点集的性质导入拓扑学。

为什么不把计算机应用看作对现实世界的建模

余山指出，这是一个关键点。一般模型化关系蕴含了这个问题的答案。这里首先把这个问题再缩小一点：为什么不把软件看作现实世界的模型或抽象？这是种颇有市场的观点。其中一个代表性的例子是在面向对象（OO）软件开发中，大家普遍习惯于（似乎也颇满足和陶醉于）将软件对象模型等同于现实世界事物模型。在业务应用开发中，面向对象建模常常就被当成是对业务对象建模；软件对象与业务对象的这种“同一关系”，至今仍颇为“主流”。这种观念有多错？有时候它可以是对的，大多数时候似乎也只是差那么一点点，尤其是，当你不以为也不期望模型与建模能带来什么实质的改变时。然而，这一点点差别，正涉及我们想要更进一步，开辟新空间的关键。

只要小心地对待模型的概念，从逻辑上就不难做出明确的回答：计算机软件不是其应用对象的模型或抽象，而是具有和处理其模型或抽象，（参见此文。更精细的说明，须在严格界定物理、概念与计算机三种空间基础上才能完成，这反而不像表面看到那么简单）。与此相关，笔者认为，一般而言，软件对象也不是现实世界事物模型（二者最接近的情形，也许在如计算机模拟应用系统设计中）；一般情形是软件对象包含（封装）现实世界对象的模型，是后者的容器。

结合计算机应用领域模型运用的现状，值得强调，从MDM到一般模型化关系，明确了应用系统模型与应用对象（目标事物）模型的区别，MDM围绕后者并称之为“应用模型”，同时还提出了模型独立性这一重要原理。这些问题同样是“看似简单”。近年活跃的模型驱动工程（MDE）明确地基于应用系统模型，但从未认真或有效地澄清过上面提到的软件对象建模与应用对象建模的混淆问题，以及建模与编程概念的区别这样的基本问题。即使在最接近MDApp概念的models@runtime这一独特分支上，仍然如此。在更早确立的概念建模领域，同样可以发现在这些方面的暧昧和不确定。概念建模由Chen 1976至今发展近四十年，始终停留在需求分析工具和“交流沟通媒介”这样的定位上。正如余山指出的，MDApp与MDM，一般模型化关系，是概念建模背后一直丢失的那个“秘密”，由此才能开启这一技术跨入计算机应用“正房”的门。概念建模本是明媒正娶的大家闺秀，却一直屈居小妾之位，不胜悲哀乎？而从这一新的立场审视，旧有的技术并不能满足新的要求，并且有不少重要的欠缺。一般模型化关系是对其重整的出发点和基本依据。如余山所述，对应用模型的识别与定位，是MDM三角关系的基本贡献之一，“从元模型[即模型化知识]出发的应用模型可以采用[更强地说是应该采用]业务语言而不是计算机语言，[……]它能更好地表达现实世界。这也正是我们引入模型的意义，这是模型语言与一般程序语言的不同之处。”

这些要点背后，就是模型驱动应用代表的新计算机应用思想，应用模型是其的核心，并成为计算机程序、现实世界事物以及应用的主体——人之间连接与相互作用的中介，它具有计算机可处理和人类可理解的双重性（见《模型驱动应用（MDApp）：以模型驱动机制跨越业务与信息技术鸿沟》叙述和其中的图解以及相关论文）。必须区别于常见的概念性或启发性理解（例如模型作为业务人员与软件开发者的沟通媒介）。由此将直接派生出对建模语言及相关支撑软件等不同以往的要求。

从形式系统到现实世界

从数学的对应到操作性的关联——模型化关系中不同角色的实际相互作用，也就是从形式系统如何连接到现实世界事物的相互作用。怎样实现？这是何其大的问题！一切的科学探索，都是在建立这种联系。回到我们的论域，往小里说，这涵盖了一个软件应用实现的全部细节。在现实世界中，没有什么意义的理解，只有操作性的连接。数学家也许告诉你模型与目标事物存在同构映射，但绝不会告诉你怎样在作为实体的模型得到或“刻上”那些“对应的点”，以及如何实质地（例如，在计算机软件中）发生作用。B.C. Smith 1985的经典论文中指出，没有关于它们如何连接的理论。如此说来，所有的计算理论都停靠在左侧；跨越右侧鸿沟的所有实践都是摸着石头过河，笔者认为这个现实没有多少改变。

一般模型化关系给出了比Smith提出问题的视图更具体而清晰的图景。明确分离了两种主体，并阐明了两个操作性的回路，这两个回路就是跨越右侧鸿沟的途径。另一方面，在操作性联系途径里，明确了模型化知识角色及其独立位置。也许不能说从前不知道这些联系，至少是忽略了它们——尤其是这些联系间的联系，及其方式。怎样在软件应用中实现？从应用（系统）架构设计开始。技术架构满足应用架构。不同于传统的编程任务，不同的应用系统及软件生命周期，不同的市场策略。

讨论背景说明

欧阳余山先生长期研究表达理论及从事企业建模与信息资源规划实践。在《作为模型而起作用的实体》一文和与笔者的讨论中，余山对模型驱动应用（MDApp）及其架构原理模型驱动机制（MDM）做了一些评论，点到了若干颇为关键的要点一般模型化关系是不久前才发布的，它是在MDM基础上更一般化和严谨的表述，并且阐明了与经典模型化关系间的联系；因此，笔者将讨论转到这个基础上来。零星提到不少话题，比较散乱，这里汇总一下，叙述得更清楚、条理些——也免得辛辛苦苦码了一段评论，莫名其妙就被那些博客平台伟光正的审核机制给黑了。

※※※

余山所用的标题展示了三个关键字：模型，实体，起作用。这三个关键字概括了这个方向的主要研究。

在模型驱动工程中，模型的基本作用是转换生成代码的桥梁，伴随着一条辅线取代代码（所谓可执行模型）。近二十年，软件产学两界围绕它发表了何止成千上万的研究，养活了不知多少教授、博士。迄今的结果，大部分人是失望的。信息系统领域对模型的主要研究是概念建模，其空间一直限于需求分析，作为人群沟通的媒介。OO开发者以对象建模代替领域建模，再来一点敏捷、极限编程，概念建模几乎没有立锥之地。

MDE路线事实上的基础，是一直被诟病没有理论基础的面向对象技术。概念建模与信息系统路线的真正起点，应当追溯到Codd的关系模型与关系数据库理论，这个领域一开始就落在坚实的数学基础之上，但随着面向对象的兴起，发展停滞，理论也失去方向或动力。

概念模型本来就是指向所谓现实世界即应用对象的，模型驱动应（MDApp）能够赋予她四十年来不敢想象的空间与新角色：成为应用系统运行的基础，程序成为支持者，被驱动者。这是一个巨大的空间，无论对实践还是理论探索。与MDE与概念建模相比，应该有多少人来探索才恰如其分？

余山的回应鼓励了我，几天拉拉杂杂码了不少字。回头看看，不禁自嘲，又干什么呢？新的旧了，懂的懂了，喜欢的喜欢了，抄的抄了，不喜欢的早忘了。砍了砍，还是很啰嗦。贴出来，算是对余山兄关注的回报吧。

原发：企业工程论坛，2013-11-06
http://www.ee-forum.org/wp/pub/ty/2013-11-p3808.html
（修改了原文中的链接）

作者印：dcb442

---