信息化的本质分享 http://blog.sciencenet.cn/u/Babituo

博文

面向资源应用软件开发方法心法:面向资源与关系的实体化

已有 2325 次阅读 2015-1-7 10:36 |个人分类:面向资源软件开发方法|系统分类:科研笔记| 应用软件, 面向资源, 关系实体化

面向资源与关系的实体化


逻辑学和关系型数据库中的关系


在逻辑学上,关系被定义为是概念之间的联系,是把概念连接为命题、理论和知识的纽带。用图论来说,概念是结点,关系是连接结点的边。

这样的观点,突出了概念对事物描述的主体作用,而关系,则只是把分散的事物连接为一个系统性的整体事物的纽带而已。在这样的框架下讨论关系,关系会显得有些单薄。比如逻辑学上对关系的分类,就只会,也只需从概念的外延的交叉种类来说明概念的外延关系。这样的“关系”,实质上只是一种附属于概念的某种性质而已,而不是一种可独立存在的“另一类概念”。

逻辑学上这样的观点,应用到计算机关系型数据库的设计上是很明显的:E-R图主要是对概念及其关系建模。其E为实体,R为关系,和逻辑学上的概念和关系是很吻合的:其中的E用来表述由属性集合所刻画的事物的概念模型,与概念的内涵一致;R则只是描述概念之间的数量联系,与概念的外延关系相关。当然,在数据库设计中,也有将关系实体化的应用,可建立“关联实体”,但这只限于一种对复杂的数量关系的技术处理的手段,而不是对“关系概念”本身在概念上的突破。关系,始终只是作为一种附属于“概念实体”的性质而被对待。

关系型数据库与逻辑学的这种高度吻合,可以说是逻辑学的最成功,最有效的应用之一。为什么会有如此成功?以及如此的成功可能意味着什么?是个有趣的问题。因为二者在“逻辑拓扑”上的相似性高,所以才有如此成功的应用。这样的成功,一方面意味着关系型数据库具有的逻辑学的理论支撑,将使其,事实也证明其,具有象逻辑学一样的广泛的应用领域和影响力;而另一方面,则可能意味着:关系型数据库的应用能力上的局限性,可能也反映出逻辑学的局限性。

这种局限就在于:逻辑学可能会和关系型数据库一样,只善长应用于解决静态模型的建模和应用的问题,而不善长应用于解决需要动态模型的问题。关系型数据库主要用于解决存储和查询为主的应用需求,这类应用甚至就直接被称为“数据库应用”。这和逻辑学本身追求概念的稳定性、精确性和可靠性的基因是一致的。

但事物本身,随着我们对事物的认识越来越全面,我们也越来越知道这一点,事物的本身,原来并不是那么稳定和相对静态不变的。我们非常惧怕这种可变性和不稳定性给我们带来对事物操控上的不精确和不可靠。可以说,“事物越是稳定的,静态的,我们操控起来就会越精确,越可靠”的观念,到了受到严重冲击的时候了。我们一方面认识到事物的本来面目,并不象我们以前认识到的那么稳定和保持静态,另一方面我们也经受不住可以动态把控事物的诱惑,但我们从来没有想失去对把控事物的高精确性和高可靠性的要求,甚至要求还越来越高。在这样的状况下,我们出现对技术,甚至对技术背后的理论的焦虑心理,是可以理解的,也是必须的。

哲学和面向对象软件工程方法中的关系

哲学上讲的关系,比起逻辑学上的关系,其内涵就小很多,外延就大得多了。哲学上讲的关系,是事物的普遍联系,是一种相互关联,相互作用的事实存在,是有“实在性”的存在。如果对照逻辑学来讲,逻辑学上的概念外延关系只是一种侠义的关系,而对真正的,事实存在性的关系而言,是一种相对独立的概念,这种关系的概念应对应逻辑学上的“联系词”概念。

面向对象思想的哲学起源,被认为最初来源于维特根斯坦的《逻辑哲学论》。就是这位奥地利的哲学家和数理逻辑学家1922年出版的这部著作,被称为哲学的语言学转向的登峰造极性著作。维特根斯坦正是在这部著作中,旗帜鲜明地将哲学的问题转化为了语言学的问题,而描述其转向的两个关键词便是“事实”Case和“对象”Object。他认为:对象链接为原子事实,原子事实不断进行累积而形成的一个巨大的事实,就是这个世界。

维特根斯坦所言的事实,就是能被一组对象及其关系描述清楚的逻辑图景。我们就是通过产生和组合这样的关于事实的逻辑图景,形成一个巨大的逻辑图景,来清晰地表达我们对世界的认识的。

计算机从被发明的那时起,我们就不仅仅满足于只用其解决数学计算的问题。到现今,我们已经在朝用计算机来帮助我们来认识和理解,甚至把控这个世界的方向,迈出实质性的步伐了。所以,计算机语言从纸带穿孔语言发展到面向对象这种哲学底蕴十足的语言,是自然不过的进化方向了,也可以说,正是因为面向对象的分析设计方法及编程语言在计算机软件开发中的广泛应用,才让计算机在信息处理方面的能力大大增强,而不只是停留在计算解题方面,才让我们在信息处理方面逐步迈向这个世界的本质,才使得哲学问题现今可从语言学的问题转化为信息和信息处理的问题。

面向对象分析设计方法中的关系,有事实关系,类关联关系和对象协作关系。其中的

“事实”,不仅仅是静态的“有什么”的事实,而包含“在发生什么”的这样的动态的事实。是因为有“因为有什么才会发生什么,发生什么又会导致有什么”这样的迭代递归,事实才会被不断汇集和累积起来,构成更大的事实。面向对象分析设计方法,就是分别从事实层面、构成事实的对象层面的静态特征、动态特征,这三个方面来组合一个立体的逻辑视图,来刻画这个世界的运行机理的。

在面向对象的分析设计语言UML中,这三种逻辑视图分别是:用例视图,类-关联图和协作图(另一种表现手法是顺序图)。其中用例视图所描述的用例关系,就是事实关系,用来描述在所发生的一个事实和另事实之间,存在什么关系,比如,有依赖关系,使用关系,扩展关系,等等,这些关系,描述了事实单元之间的行为迁移,价值流转,目标依赖等高层的动态关系。

-关联图,是站到事实的内部,去分析,观察,和构造,造成事实的内部机理,所给出的一类相对静态的视图。表面看和关系型数据库的E-R图类似,实质上有本质的不同。其不同在于:类不仅仅封装了静态的实体属性特征,还封装了实体的方法行为特征,所以,不再称其为是对“实体”的封装,而是对“对象”的封装。

这意味着:类的关联关系,就是对对象之间的链接关系的抽象,是有对象交互操作的具体含义的关系,而不仅仅是实体之间的数量关系。如果说实体-关系中的关系,象是连接不同实物的连线,以便在存储它们的容器中,顺着这些连线能够从一个实物找到另一个或一些实物,那么,对象关系中的关系,则是链接不同动作机构的液压管道,使得一个对象能够顺着一条管道向另一个或一些对象发出液压传动的动作指令。而协作图或顺序图,就是描述这些动作指令是按什么逻辑顺序的步骤来进行的。

更加不同的意味是:对象不是象实体那样的,没有内部,只有表面属性特征的一个黑箱。即使其表面的,看上去是静态的属性特征,在打开对象内部的结构来看,却可以是另一番关于对象内部的事实的图景,正是这些内部的事实造就了对象的外部特征。这种同态于现实世界的多层嵌套的逻辑结构,是平面化的ER图远远不能表达的,真切的事实图景。

很多从事技术工作的人员甚至是专家,都很少思考这些哲学意义的不同,也由于技术方法的缺失,导致实际在技术上也用实现ER图的关系型数据库技术来部分实现类-关联图中的类的持久化。这样做看似实现了实体模型和对象模型的结合,但这种结合的“缝隙”很大,大到一不小心就会严重影响到对象模型的动态表达能力的运用。

造成设计时和运行时鸿沟的原因分析

由于当今面向对象的编程语言本身,存在设计时和运行时的鸿沟,导致面向对象的编程技术,并不能充分地贯彻面向对象的分析设计思想,也就是说,当今的面向对象的编程语言,哪怕像JAVA这样,很纯粹的面向对象的编程语言,要在计算机中实现真实世界的对象演变过程,就像迷信中的游魂要投胎重新做人一样,有“跨界”的艰难。

而要打破设计时和运行时的鸿沟,尤其是在需要同时贯彻面向对象的哲学思想的要求下,打破设计时和运行时的鸿沟,其技术难点,并不是简单的变编译执行为解释执行的困难。实际上JAVA已经这样做了,但依然未能突破设计时和运行时的鸿沟,真正的技术难点是:需要寻求一种统一的逻辑抽象表达模式,使得这种抽象表达模式,不仅能将计算机的资源和应用领域的资源统一到一个平台上进行处理,而且还能适应从设计、实现和运行的同步操作。现在的类-对象Class-Object封装的逻辑抽象表达模式,能够实现前者,却不能实现后者,导致只能僵化Class来实施面向对象的思想。

回到过去的ER图的实现技术关系型数据库,实际上已经突破了设计时和运行时的鸿沟。在软件运行时,可以通过执行构建型SQL语句来改变库表结构,可以通过查询型SQL语句来进行查询和计算。尽管其可执行的计算非常简单并计算过程不得不低效,但SQL至少是可在运行时直接执行的语言,不需要回到设计阶段在代码中写一句代码,再编译为Exe程序安装后才能执行。关系型数据库的这个特性,使得构建一个设计时和运行时统一的数据库应用平台成为可能,事实上,软件界也一直没有停止过类似平台的开发和应用。只是由于存在哲学基因上的不足,这类平台的应用领域和应用效果始终得不到提升,不能满足具有复杂的动态过程模型的软件开发与应用的需要。

关系型数据库可以做到设计时和运行时统一的原因在于:ER图的哲学图景把实体和关系都进行了相当的简化。“关系型数据库”名称中的“关系”概念,并不是实体关系中的“关系”概念,而是用一组参数的联合关系,就可代表一个实体的这种抽象表达的模式。这样的话,需要处理的现实对象的逻辑元素,就和计算机里的数据库处理的逻辑元素实现了简单的统一:简单排列的一组参数值,既是计算机可理解的资源对象,又是现实世界的人可理解的资源对象。剩下的,只需处理这些参数组之间的数量关系就可以了。处理方式种类也非常简单:增删改查四种操作就足够了。

归纳一下面向对象的软件开发和关系型数据库应用开发的特点,我们会发现:面向对象的开发是静态地开发出动态模型应用的方法,而关系型数据库是可动态地开发出静态模型应用的方法,而我们的目标是:可动态地开发出动态模型应用的方法。为了实现这一点,需提出一种可动态建立的动态模型的资源表达方法。这种方法既不能是实体关系法,也不能是直接的对象模型法,但必须具备实体关系法的可动态构建特征,又必须具备对象模型法具有的动态表达能力的特征。这给我们的启发是:如果实现了对象模型与实体模型的完整融合,那么,使得我们可以在类似实体模型的模型上进行动态的构建,在类似对象模型的模型上进行动态模型的运行。可设计出一种介于对象模型和实体关系模型之间的资源模型来实现这个目标,并可称这种新的抽象表达模型就叫“资源模型”。于是,计算机处理的对象,统一为既不是实体,也不是对象,而是资源了,面向资源的软件开发的方法就应运而生了。

面向资源与关系实体化

资源模型,并不是简单地用实体模型来实现对象模型,或简单地将对象模型简化为实体模型就是了。尽管现行的很多互联网应用架构就是这么处理的,他们也得到了很多架构上的灵活性,实现了某种程度的开发时和运行时的融合,但现今的大部分互联网应用可交互性依然较差,不然的话,应用的可演进性就不会仍然是要靠设计时来实现的。

要实现资源模型,显然必须按对象模型的信息模型来设计资源模型,才能让模型具有动态的表达能力;也只有资源模型具备了实体模型的实体化的特征,才可以动态地被构建。因此,必须解决对象模型的完整实体化的问题,其中,包括对象静态属性集合实体化和动态属性及方法集合的实体化的问题。解决对象模型的静态属性的实体化不难,可直接采用实体建模的方法,一组参数的集合即可实现。所以,解决资源模型的设计的难点在于对关系的处理。一个类封装了对象的属性集合和方法的集合。其中的动态属性和所有的方法,都是对对象关系的实现。对象关系不同于实体模型的实体关系,看上去是具有千差万别的处理内容和处理的过程形式的,所以,需要根据对象关系的不同,在编程语言中编程时编写不同的具体编码来实现这些关系,正是这个原因,导致了大量的对象关系必须通过“硬编码”来实现。从而导致了设计时和运行时的分离。

如何实现关系的实体化,看上去只是个技术的问题,其实不然,前面讲到,实际可能是一个语言学,甚至是哲学的问题。对象关系演化的本质,是客观事物自身结构的演化(内部关系的变化)和对外交互关系的变更。当然,在统一的事实概念基础上,内部和外部是相对的,一个事实的内部,就是造成这个事实所包含的对象的外部,反之,对象的对外交互关系的变更,本质上也就是在演变一个更大的事实的内部机理。二者的差异,仅在于嵌套的层次不同。

核心问题就归结到关系实体化的多样性问题了。把一种动态的行为当作静态的实体来对待,本质上来讲,只是一种变换的处理。所以,如何对对象关系进行实体化分类,就成了资源模型构建的难点。

假设被处理的对象,已经全部转换为实体模型中的实体形式,我们称其为资源而不是实体,是因为实际上它们只是和实体具有相同的可构建性,但和实体具有不一样的可操作性。那么,问题就被明确为:各种各样的资源之间可能拥有的,具有事实操作语义的关系对象,有多少种类型?能否穷举?这里把关系表述为关系对象,是为了避免类似逻辑学上的那种性质上的关系概念,比如类似“外延包含关系”这样的关系概念的干扰。在这里,关系是关系对象,意味着具有某种功能的传递性的抽象表达,比如:“抽象化关系”,意味着是A经过抽象化后得到B。这样的关系,抽象出来之后,又有多少种?非要换成逻辑学的语言,就是问:联系词有多少种抽象形式?

有多少种实体化关系的抽象?

在知识工程理论中提到,如果对所有的知识概念对象的关系进行抽象,最后我们只会得到2种关系,就是:AB的一部分,和:AB的一种。

AB的一部分,表明两个资源处于不同的事实层级。

A是内部事实层面的资源,而B是更外部事实层面的资源。因为A所在的事实是B所在的事实的内部事实,所以,A才是B的一部分。

AB的一种,可能有2种含义:

1.A在事实领域,而B在概念领域。表明A是一个具体对象的资源,B是对这类对象的抽象结果的概念对象。比如:这匹白马是马。当然,在面向资源的语境中,二者都是资源了。

2.AB都在概念领域。表明,A是一个外延小于B的概念。比如,马是动物的一种。

这里所谈到的,实际是如下三种关系:

1.事实领域内的关系;

2.概念领域内的关系;

3.跨事实领域和概念领域的关系,就是所谓的“虚实跨界”的关系。

似乎,所有的关系,都不外乎是这三种关系中的某一种。

 

好,接下来再分析事实领域内的关系。

上面讲到的是,事实领域本身被分为不同的规模层级。比如,“北京工人体育场正在举行一场足球赛”,是一个事实,在这个事实的内部,可能存在一个更小范围的事实,就是“这场足球赛正是中国和韩国队在比赛,中国正由左向右攻”。还有比这个事实更小的事实:“李铁正在盯防安再旭”。

于是:我们可以说出如下的AB的一部分的关系来:李铁是中国队的一部分;中国队是这场比赛的一部分。只要说出不同事实层级之间的相关的2个资源,我们就找出了一个“AB的一部分”的关系的实例。

由此受到启发:处于同一事实层级的两个资源的关系是一种新的类型的关系。比如,李铁和安在旭,中国队和韩国队,它们之间的关系,可统一称为“交互关系”:它们在同一个事实层面,交换物质、能量和信息。

似乎在事实领域不再有别的关系类型了:因为,“事实是分层级的”已经是一种基本固定的模式了,这样,就只需要建立同一事实层级的关系和跨事实层级的关系就可以了。就好比世界可被分为事实领域(世界)和概念领域(世界)两个子世界是一种基本固定的模式一样。

 

为什么要这么分模式?

暂时假定认为只有这样的分法是符合“最简充分必要原则”的吧。如果以后发现还有更好的模式符合这个原则,我们可以换掉这种模式。

为什么要遵守“最简充分必要原则”?

暂且认为这个原则最科学吧。如果以后我们认为还有更科学的原则,我们可以换掉这个原则。

 

回来再看概念领域,受事实领域可分层级的启发,概念领域也是可以分层级的。“AB的一种”,已经表明概念领域的层级是被划分为不同的抽象级别的了。尽管在概念领域的不同子领域内,其划分层级的个数和方法各异,但,概念分抽象级别,已经是基本的“概念领域的事实”了。看吧,我们可以把概念领域也“事实化”来理解了,这样,至少就是试图取得“公认”的一种姿态。这和我们把“关系实体化”似乎有一种类似企图。尽管有主观性,但我们会认为这种主观是“客观的主观”,就是:主观上的事实一定会是这样子的。这样的事实,与存在“我们认为某个观点就是个人的主观观点”的事实显然是有区别的。

 

既然概念领域也存在分层级的事实,而且我们也找到了不同层级之间的概念资源关系,就是“AB的一种”这类关系了,那么,处于同一概念层级的概念资源之间,又会有什么关系呢?

比如,对照上述足球赛的例子,我们可以按“虚实跨界”的“AB的一种”的规则,来归纳出对应的概念领域的事实,就是:

一场足球赛有2支足球队在一个球场上进行。

2支足球队代表不同的立场方进行比赛;

1支足球队有多名队员;

2支足球队的队员之间会进行足球动作的对抗。

这就是概念领域抽象的事实,经过这样的抽象,不仅是上述工体上的那场球赛的事实是这个概念事实的一种,任何其他的正常足球比赛,都会是这个概念事实的一种。没错吧?

 

我们已经知道在客观事实领域的同一事实层级的资源之间的关系,叫“交互关系”了。

那么,客观事实领域的“交互关系”投影到概念事实领域内之后,相互之间的关系,叫什么呢?比如,“足球队”这个概念和“球场”这个概念之间有什么关系呢?客观事实资源之间是使用关系,当然,客观事实资源的使用,就是一种交互行为,问题是:概念之间不能也是“使用关系”吧?如果要说概念的使用,应该是“足球赛”的概念,使用了“足球队”和“球场”的概念,才对的啊。

嗯,这里意外发现一种新的“不同层级”之间的概念关系了,“不同层级”之间的概念可以有“使用关系”哦。要小心!这里的“不同层级”,并不是概念按抽象级别划分的层级,而只是概念描述了不同层级的客观事实之间的关系事实而已。同样要小心的是:这里的“使用关系”和客观事实同级别之间的资源之间的交互关系也不同。而只是我们在定义一个概念时,要使用的其他概念,这些概念之间可能用“A是B的一部分”的关系表达更恰当一些。比如,说“‘足球队’的概念是‘足球赛’概念的一部分”似乎更符合理解的习惯。

而作为两个概念,“足球队”和“球场”都是组成“足球赛”概念的部分,或许再加上“球队会使用球场”这个关系概念,就完整了:是“足球队”,“球队会使用球场”,“足球场”这三个概念组成了“足球赛”的概念。所以,“球队会使用球场”这个概念在概念领域和“足球队”的概念作为概念的存在并无差异,只是其描述的含义,在事实层面是一个真实的关系而已。它们在概念领域是同层次的协作关系,是它们的语义共同协作,定义了足球赛的语义。

这里有一个稍微有些出乎意外的发现:在客观事实领域内的层级关系,“投影”到概念事实领域之后,这种层级关系,被压缩到概念的含义中去了,对于概念资源而言,并不会在概念领域里形成同样的层级,概念领域是按自己的抽象原则来形成层级的,和客观事实领域是按空间尺度形成层级的原则是不同的。换句话说,在概念世界并不会去按概念的实质内容去引发动作,而只会按概念的内容构成完整的更大事实的概念。只有把这些概念的实质内容,实例化到现实的事实世界,概念事实所表达的含义才会鲜活起来,这时,就已经变成是客观事实了,已经不再是概念事实了。

联想到我曾经研究过的复逻辑,概念事实和客观事实的关系实际是逻辑上的虚实关系。概念是事实转过90度的投影,转过90度,意味着从有功变为无功,意味着从动力转变为约束力。用概念所表述的关系确实不会自己运转,但是会用来规定和约束受控客观事实的运转。如果非要把概念世界和现实世界统合起来不可,一个“复世界”便是活龙活现的了:

Ww = Wr + iWc

关于复逻辑,这个小差开的有点大了,大得我自己都招架不住了。现在看来,复逻辑的存在,并不是蒲风捉影的了。复逻辑不仅在逻辑学上可能是新鲜的,在哲学上,世界是复世界,这个概念就像数学上用复数来统一实数和虚数一样。复变函数所描述的世界,是不是就可以是这个复世界呢?如果我是数学家,这个事也会是我感兴趣的事情呢。我是软件工程师,所以,我还是回去研究我的软件吧。

这个发现至少会在为关系的实体化方面的处理提供可信赖的支撑。这对面向资源的软件开发来说,无疑是一个重大的启发。我知道的,在面向对象编程中,并不缺乏解决这类问题的技术。

小结

到此为止,我们发现了至少可以归纳出来的6种关系是:

 

 

 

 

1.在客观事实世界中,同一事实级别内不同资源的关系,协作关系,红色线段表示。

2.在客观事实世界中,不同事实级别内的不同资源的关系,组成关系,黄色线段表示。

3.横跨客观事实世界和概念事实世界之间的关系,例证关系(虚实跨界),蓝色线段表示。

4.概念事实世界中,同一概念抽象级别内的资源组成关系,白色线段表示。

5.概念事实世界中,同一概念抽象级别内的资源协作关系,紫色线段表示。

6.概念事实世界中,不同概念抽象级别之间的关系,概念抽象关系,绿色表示。

以上6种关系,可能意味着在软件开发中需要用源代码的方式,编写6类关系的处理代码,作为平台的功能提供出来,在实际的应用开发中,只要使用这六类关系之一,如实地定义相应的资源之间的关系,就可以期待,大部分的资源关系的处理,都能得到平台的支持。

当然,这是一个不完全的归纳,相信深入研究下去,还可以发现为数不多的更多的不同类型的关系,只要这些关系在抽象类型上可以被划分为确切的可操作的几种类型,我们就可以通过扩充一种新类型的关系可供定义使用。应用软件则可灵活地在系统资源间,按实际事实的需求添加新的资源关系,系统的引擎就会按照预定的模式处理这些关系。

总之,关系实体化是将对象模型资源化的关键技术,这一关键技术的突破,将抹平对象模型的设计时与运行时之间的鸿沟,使得资源模型具备“动态地构建动态的模型”的能力。

 

邱嘉文

                                                                                2014911


非常感谢博友:刘钢老师在哲学方面的指点,让我有底气贴出早就写出来了,但由于对哲学的敬畏不敢贴出的,这篇哲学味较浓的文章。




http://wap.sciencenet.cn/blog-33982-857195.html

上一篇:面向资源应用软件开发心法:资源语言编程思想
下一篇:追寻信息的芳香——《穿越歧路的花园》读后感

1 icgwang

该博文允许注册用户评论 请点击登录 评论 (7 个评论)

数据加载中...
扫一扫,分享此博文

Archiver|手机版|科学网 ( 京ICP备07017567号-12 )

GMT+8, 2021-9-23 20:51

Powered by ScienceNet.cn

Copyright © 2007- 中国科学报社

返回顶部