科学网 › 标签 › 面向资源

标签: 面向资源

相关帖子	版块	作者	回复/查看	最后发表

没有相关内容

相关日志

从架构看大数据和云计算的关系: 热度 2 Babituo 2015-1-31 12:43; 从架构看大数据和云计算的关系当说到大数据和云计算，乃至超级计算的关系时，很多专家都给出类似的科普级的观点：大数据是大菜，云计算是大锅，炒大菜当然要用大锅，有大锅当然能炒大菜。比如，当我质疑新闻稿中说“天河一号”用于了大数据处理的说法时，闵应骅前辈给出了如下科普级的解释：大数据需要高速度的计算机。这个解释当然有道理，却还是解答不了我的疑问。我的疑问实际是：巨型机“天河一号”在架构上是如何支持大数据的计算的？它有支持巨型机实施大数据计算的架构么？为什么会有此疑问？因为炒大菜的充分必要条件，不仅仅是有足够的地方存放足够多的食材，和有足够多的锅（云计算）或足够大的锅（巨型机）这两项条件，容易被忽视的是：如何才能够将这足够多的食材，怎么放到锅里去抄的问题。这，就是一个架构的问题。直接形象一点吧，假设我们要做的事是：一次性炒一份让全北京市的人一顿吃的一道大白菜，假设大约需要1000吨的白菜吧。和我们平时家里吃一餐的几颗小白菜相比，算是大数据了（不很贴切，要贴切是可以的，但太罗嗦，“砖家”不要急着拍砖）。好，这么多的菜需要一锅炒出来，得需要一口多大的锅（巨型机）啊？或需要多少口不小的锅（云主机）同时炒啊？好，假设我们要为此建一个超级大厨房（云计算中心），需要在20分钟内完成炒菜装盘送到餐桌前的过程，否则，菜就凉了，要不然，全北京市的人排队吃这“一顿午饭菜”，可能要持续进行一个月的时间。咋办呢？这厨房得建成啥样的呢？怎么运作呢让我来设计一下吧：我们不能从农民的地里把这1000吨大白菜(大数据)用大卡车运来直接倒进锅里煮吧？所以，我设计了1万个足球场大小的备料场。是这么分组的：100个操场负责卸菜，然后派发到每个卸菜场负责把卸下的菜，分发到100个操场上去进行挑拣，清洗和切细。嗯，知道吧，这就是一个负责大数据处理的集群。因为这些处理要在5分钟内完成，所以，必须是1万个备料场同时进行，分散并行处理，这就是所谓的Map。切好的菜需要在炒之前地先运到灶台上去吧？所以，100条传送带把切好的菜料汇聚到一条超宽的传送带上，再由这条超宽的传送带送往灶台。这就是Reduce了，我们的传送带（网络）有足够的带宽，把这些菜料3分钟运到灶台是没问题的。假设1口大锅（主机）一次3分钟大约可炒熟300公斤的洗好，切好的大白菜，假设有10分钟的时间来炒菜，那么，一口锅最多炒3轮，也就是900公斤，我们需要1000口这样的锅。实际上是不是这样也没关系，反正就是1000个下料口，1000个出菜口，里面到底是多少口什么锅无所谓，可能是3000口100公斤的大锅；也许是30口10吨大锅。经过“虚拟化”，从外面看上去就是1000口300公斤大锅了。每口大锅不会同步开炒，同步完成，炒的菜会给谁吃，也说不准。反正，尽量给这个炒完，可能歇会，再给下一个炒。如果吃菜的人不动，是给人炒菜的锅移动到吃菜的人跟前来炒，那么，看上去就是炒菜锅象天上的云一样在流动。流动到哪，就给那的人炒菜。所以，叫“云炒菜”，不是忽悠人的，而是为了让人好明白才这么叫的。好了，“云炒菜中心”的架构就这么设计好了。我们可以看到，里面实际有两个中心:“理菜中心”和“炒菜中心”。理菜中心解决的要炒的菜多，排队炒等不起的问题；而炒菜中心解决的是吃菜的人多，每人一个专用锅浪费的问题。大数据处理和云计算，实际上目前还只是在不同的场地上，由不同的家伙式来干的不同的事。但由于只有一个名字：“（云）计算中心”，很容易让人误以为，只要是有这个名字的地方，就可以两种事都做齐了。而实际的事实是：大多数的有这个名字的地方，要么只是理菜中心，要么只是炒菜中心。能合二为一的地方，意味着它里面，大数据和虚拟云计算这两套家伙式（基础设施）都得有，而且必须能配合得起来。比如，那个巨无霸，我是很怀疑在它的周围是否设有“理菜中心”的。巨无霸提供的只是炒菜的能力强准确地说，只是快，可能人家炒一锅，它可炒10万锅，“锅”当然也不小，能不能一轮就炒出一个大菜来，还要看有没有给它配一个自动供料的“理菜中心”。我怀疑的理由是：让我们看看现在世面上的厂家的做的厨房和各家所用的厨房吧，你会知道我的怀疑不是胡思乱想的。好，就让我们以云计算为例，来检视一下目前的云计算架构和大数据处理的架构吧，看看在架构上，我们是否已经准备好了“同时既能容纳足够多食材，又能容纳足够多的炒锅”的厨房和灶台了吧。先看IBM的“蓝云” 看吧，这框出来的部分，显然只是一个大“灶台”-虚拟云计算环境。而作为理菜场的“大数据”在哪？难道要建在虚拟网络里吗？大数据可是实打实地需要网络吞吐量的哦，好吧，就算可以建在虚拟网络里，而且我们这100个大操场确实是从一块有足够大面积的场地（存储空间）中虚拟出来的，可难保这100个大操场的100张大门，不是从一张门虚拟出来的啊（是否有足够的网络与存储设备间的带宽，值得怀疑），尽管这张门也可能比较宽，但要做到真实所需的100张门这么宽，就没有虚拟的必要了。要知道，大数据处理，是依靠真实可同时开进开出的通道，才能做到并行“捡菜、切菜”的啊！再来看惠普云计算解决方案吧。是不是也是一个大“灶台”，它告诉你，那1000个炒菜锅，或许是100个刀片服务器虚拟出来的。而且，它还直接明了的告诉我们：服务器存储网络SAN是独立架构的。不管其SAN是用超融合设备还是用纯软件解决，总之，网络内的存储资源已被统一池化。这意味着：虚拟出来的主机系统，即便可以用来当作大数据处理的某个结点（一块理菜的场地），但这块场地的门，是否独立，能否支持全部主机的并行数据进出，是个大疑问。再来看个国产的华为的吧华为没有把大数据平台和云计算平台混谈。这是其大数据平台架构：显然，这个架构和“虚拟化”，池化无关。一个Hadoop集群完成“理菜中心”的任务，是比较完整的电信级的大数据解决方案。下面这就是华为的“大灶台”虚拟云计算中心了：厂家的看到这了，看到这，我们应该明白这个道理了：所谓云计算平台和大数据平台是两个不同的平台，我们在云计算平台中看不到集群的影子，在大数据平台中，看不到虚拟池化的影子。而不是所谓的：只要是云计算，就是用大锅炒大菜了。大数据和虚拟云完全是两个可以不搭边的不同应用。当然，也可以搭边，但要搭边，就一定要同时拥有这2套系统，才能用大锅炒大菜。在这，我只是打出了IBM和HP的“炒菜中心”方案，相信，IBM，HP也有自己各自的“理菜中新”方案。下面来看玩家的。当然，先看亚马逊的。这是亚马逊的弹性云平台EC2 这是一个真正把“理菜中心”和“炒菜中心”整合在一起了的一个方案。其弹性大数据处理MapReduce部分是一个相对独立的架构，底层跨在Ec2 Instances和S3 之上，意味着，这个独立的大数据处理平台，是构建在虚拟的计算资源和虚拟存储资源基础之上的。所以，我有点怀疑这个架构的大数据处理能力和效率，应该不会比Google强。好，立马来看Google的云架构看到了吧，Google是干什么的，Google的云架构主要是由N多个Node组成，每个Node其实就是一个“理菜中心”，所以，google的“云计算”里面，其实没有云计算，只有大数据处理。基于GSF的MapReduce是Google干的最多的活。他们不出租计算主机，所以不提供虚拟云。微软的是个灶台，不用多说了，看下图就知道：没有大数据，只有虚拟资源服务。下面看国内玩家的百度在架构上显然是同时支持“炒菜”和“理菜”的，这点和亚马逊相当。和竞争对手Google比，至少在架构上设计更全面，可支持更丰富和开放的服务。当然，从实际开发的IT应用项目的数量和先进性而言，google领先于百度是毫无疑问的，但这和云计算架构无关。也就是说，作为一个平台，百度至少是不输给google的。本来不想看的，还是来看一下“阿里云”吧阿里云的架构显得很怪异，它更象一个独立的网络版应用系统，也就是一个功能级的应用支撑平台，而不是一个通用的系统级网络应用支撑平台。其架构从图示上看给人个感觉就是“混乱”。整个数据中心作为底层，之上支撑的仅仅是一个操作系统Linux，似乎是Linux装载在“数据中心”这个“裸机”上。再往上的层次也是，似乎是想将整个阿里云当作一台电脑来打造一样。这个想法比较独特，但在技术支撑上，很可能被主流的云计算平台架构技术“吞没”。尽管阿里有钱了，这么任性，风险还是有点大。从应用的角度来看，阿里云的架构似乎只能支撑自己的一盘大菜，老百姓各炒自己的小菜，便是他的大菜。总的看来，阿里云不是一个技术云，而是一个业务云。说白了，大数据系统是系统之下的系统，云计算系统则是系统之上的系统，阿里的架构师看来是不懂这个，或者太懂这个了，居然可以集成得像一台机器。如果是后者，其野心大得有点可怕，当然，也就风险很大。接着从纯技术的角度来看下大数据和云计算的通行架构吧。大数据，当然，以目前仍占主流的Hadoop为例，尽管它应该很快被Spark所替代掉。写到这，不免让我有所慨叹：我们国内的技术跟风者，简直就像我们A股市场上的散户——如果把国际云计算技术比作A股市场的话。看看人家的顶尖大学在做什么，而我们的呢？难怪，当我发出豪言要超越他们的时候，显得那么“蚁马赛跑”。好在有“蚁群算法”，而没有“马群算法”，赛就赛吧，期待蚁王驾到，蚁群出现。不用讲了，我已经讲过了，这就是个“大白菜料理场”而已。所有的技术概念都可以和大白菜料理场的概念对应上，你丝毫不必觉得它有什么神秘。如何映射概念，由于时间关系暂时也不展开了。更想说说Spark的架构说是Spark的架构，还真不如说是Spark的生态。说生态的感觉确实比架构的感觉舒服很多。多种物种的共生环境，确实比冰冷的组件、构件、模块结构相互支撑互动的系统，让人感觉温暖得多。计算机架构仿生的理念，总算逐渐被“发源”了——显然，这不仅仅是心理的温暖感的需求，而是技术质变的需求。这里只说RDD，Spark的核心创新：抽象的弹性分布式数据集。还是用比喻来说科普一点：如果说MapReduce的机制，是生产线上的“皮带传动”运输处理线的话，RDD就是叉车托盘运输处理流程线。关键差别在哪？在分散数据在处理过程中的共享。当然，这意味着RDD必须比Mapreduce支持更多的操作，这些更多的操作支持，最终可使数据处理更灵活和流畅。可见，这种生态感是从骨子里透出来的。这里不得不提一下我发现的“资源”概念。RDD是最接近资源概念的数据集概念，但还没有达到资源概念的创新高度。何以此说？资源是一种“分布式弹性对象”，走看吧，我敢打赌，未来RDD的升级版提出类似“分布式弹性对象”、再发展下去，当国外大拿们提出某种“软件组件虚拟化”的技术概念来的时候，国内的跟风卖力者必定又将趋之若鹜。殊不知，蚂蚁已经走在骏马之前了，可谁会跟蚂蚁的风？蚂蚁就算没命奔跑也带不起风啊。哦，原来，是“跟风”这种行为的错，蚁群可不是靠跟风来形成群体智慧的啊。顺便提下REST，RESTful和“资源”的关系。最早的互联网是把数据资源化，接下来是把软件服务资源化，也就是RESTful，云计算环境下的互联网把硬件资产资源化了，当然，SOA走到了云计算的前面是一种阴差阳错，差错在SOA是软件服务的行为化。走在云计算后面的软件服务，将是：将资源进行到底——软件组件直至程序逻辑和语句的资源化。 RESTful是把用代码程序语言开发的软件资源化，而我的面向资源开发，是用虚拟化的软件资源开发程序。本质相同的是资源化的方法手段，本质不同的是资源化的架构层次。资源化，就是虚拟化，云化，池化。其背后的本质，是将“分享、共享的技术机制（请决不要理解为仅仅是精神意念）”沉淀到底。RDD正是走在这条路上的“先行者”（先行马，前面还有只“先行蚁”，是资源，呵呵）之一。一般云计算架构，上刘鹏的图了：我猜这个刘鹏就是当面在北大推动网格计算的那位刘鹏。记得我和他通过一封邮件，邮件中我很赞赏他的工作和网格计算的理念，是将混沌的互联网引向有序的起点。他也给我回过邮件表示同意我的观点。最后，给出我描绘的未来云计算的通行架构最后，表达个人期望：我非常希望能加入一个类似“透明计算”团队这样的国家队，把面向资源开发的这只蚂蚁变成一匹骏马。最终让质疑我们国人技术创新能力的人闭嘴，让国外厂商来跟我们的风。除最后一幅图，图片来自网络，版权归其作者所有邱嘉文 2015年1月31日于珠海诚开智能; 个人分类: 面向资源软件开发方法|13388 次阅读|3 个评论

面向资源应用软件开发方法心法：面向资源与关系的实体化: 热度 1 Babituo 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 种关系，就是： A 是 B 的一部分，和： A 是 B 的一种。 A 是 B 的一部分，表明两个资源处于不同的事实层级。 A 是内部事实层面的资源，而 B 是更外部事实层面的资源。因为 A 所在的事实是 B 所在的事实的内部事实，所以， A 才是 B 的一部分。 A 是 B 的一种，可能有 2 种含义： 1. A 在事实领域，而 B 在概念领域。表明 A 是一个具体对象的资源， B 是对这类对象的抽象结果的概念对象。比如：这匹白马是马。当然，在面向资源的语境中，二者都是资源了。 2. A ， B 都在概念领域。表明， A 是一个外延小于 B 的概念。比如，马是动物的一种。这里所谈到的，实际是如下三种关系： 1. 事实领域内的关系； 2. 概念领域内的关系； 3. 跨事实领域和概念领域的关系，就是所谓的“虚实跨界”的关系。似乎，所有的关系，都不外乎是这三种关系中的某一种。好，接下来再分析事实领域内的关系。上面讲到的是，事实领域本身被分为不同的规模层级。比如，“北京工人体育场正在举行一场足球赛”，是一个事实，在这个事实的内部，可能存在一个更小范围的事实，就是“这场足球赛正是中国队和韩国队在比赛，中国队正由左向右攻”。还有比这个事实更小的事实 : “李铁正在盯防安再旭”。于是：我们可以说出如下的 A 是 B 的一部分的关系来：李铁是中国队的一部分；中国队是这场比赛的一部分。只要说出不同事实层级之间的相关的 2 个资源，我们就找出了一个“ A 是 B 的一部分”的关系的实例。由此受到启发：处于同一事实层级的两个资源的关系是一种新的类型的关系。比如，李铁和安在旭，中国队和韩国队，它们之间的关系，可统一称为“交互关系”：它们在同一个事实层面，交换物质、能量和信息。似乎在事实领域不再有别的关系类型了：因为，“事实是分层级的”已经是一种基本固定的模式了，这样，就只需要建立同一事实层级的关系和跨事实层级的关系就可以了。就好比世界可被分为事实领域（世界）和概念领域（世界）两个子世界是一种基本固定的模式一样。为什么要这么分模式？暂时假定认为只有这样的分法是符合“最简充分必要原则”的吧。如果以后发现还有更好的模式符合这个原则，我们可以换掉这种模式。为什么要遵守“最简充分必要原则”？暂且认为这个原则最科学吧。如果以后我们认为还有更科学的原则，我们可以换掉这个原则。回来再看概念领域，受事实领域可分层级的启发，概念领域也是可以分层级的。“ A 是 B 的一种”，已经表明概念领域的层级是被划分为不同的抽象级别的了。尽管在概念领域的不同子领域内，其划分层级的个数和方法各异，但，概念分抽象级别，已经是基本的“概念领域的事实”了。看吧，我们可以把概念领域也“事实化”来理解了，这样，至少就是试图取得“公认”的一种姿态。这和我们把“关系实体化”似乎有一种类似企图。尽管有主观性，但我们会认为这种主观是“客观的主观”，就是：主观上的事实一定会是这样子的。这样的事实，与存在“我们认为某个观点就是个人的主观观点”的事实显然是有区别的。既然概念领域也存在分层级的事实，而且我们也找到了不同层级之间的概念资源关系，就是“ A 是 B 的一种”这类关系了，那么，处于同一概念层级的概念资源之间，又会有什么关系呢？比如，对照上述足球赛的例子，我们可以按“虚实跨界”的“ A 是 B 的一种”的规则，来归纳出对应的概念领域的事实，就是：一场足球赛有 2 支足球队在一个球场上进行。 2 支足球队代表不同的立场方进行比赛； 1 支足球队有多名队员； 2 支足球队的队员之间会进行足球动作的对抗。这就是概念领域抽象的事实，经过这样的抽象，不仅是上述工体上的那场球赛的事实是这个概念事实的一种，任何其他的正常足球比赛，都会是这个概念事实的一种。没错吧？我们已经知道在客观事实领域的同一事实层级的资源之间的关系，叫“交互关系”了。那么，客观事实领域的“交互关系”投影到概念事实领域内之后，相互之间的关系，叫什么呢？比如，“足球队”这个概念和“球场”这个概念之间有什么关系呢？客观事实资源之间是使用关系，当然，客观事实资源的使用，就是一种交互行为，问题是：概念之间不能也是“使用关系”吧？如果要说概念的使用，应该是“足球赛”的概念，使用了“足球队”和“球场”的概念，才对的啊。嗯，这里意外发现一种新的“不同层级”之间的概念关系了，“不同层级”之间的概念可以有“使用关系”哦。要小心！这里的“不同层级”，并不是概念按抽象级别划分的层级，而只是概念描述了不同层级的客观事实之间的关系事实而已。同样要小心的是：这里的“使用关系”和客观事实同级别之间的资源之间的交互关系也不同。而只是我们在定义一个概念时，要使用的其他概念，这些概念之间可能用“Ａ是Ｂ的一部分”的关系表达更恰当一些。比如，说“‘足球队’的概念是‘足球赛’概念的一部分”似乎更符合理解的习惯。而作为两个概念，“足球队”和“球场”都是组成“足球赛”概念的部分，或许再加上“球队会使用球场”这个关系概念，就完整了：是“足球队”，“球队会使用球场”，“足球场”这三个概念组成了“足球赛”的概念。所以，“球队会使用球场”这个概念在概念领域和“足球队”的概念作为概念的存在并无差异，只是其描述的含义，在事实层面是一个真实的关系而已。它们在概念领域是同层次的协作关系，是它们的语义共同协作，定义了足球赛的语义。这里有一个稍微有些出乎意外的发现：在客观事实领域内的层级关系，“投影”到概念事实领域之后，这种层级关系，被压缩到概念的含义中去了，对于概念资源而言，并不会在概念领域里形成同样的层级，概念领域是按自己的抽象原则来形成层级的，和客观事实领域是按空间尺度形成层级的原则是不同的。换句话说，在概念世界并不会去按概念的实质内容去引发动作，而只会按概念的内容构成完整的更大事实的概念。只有把这些概念的实质内容，实例化到现实的事实世界，概念事实所表达的含义才会鲜活起来，这时，就已经变成是客观事实了，已经不再是概念事实了。联想到我曾经研究过的复逻辑，概念事实和客观事实的关系实际是逻辑上的虚实关系。概念是事实转过９０度的投影，转过９０度，意味着从有功变为无功，意味着从动力转变为约束力。用概念所表述的关系确实不会自己运转，但是会用来规定和约束受控客观事实的运转。如果非要把概念世界和现实世界统合起来不可，一个“复世界”便是活龙活现的了：Ｗｗ　＝　Ｗｒ　＋　ｉＷｃ关于复逻辑，这个小差开的有点大了，大得我自己都招架不住了。现在看来，复逻辑的存在，并不是蒲风捉影的了。复逻辑不仅在逻辑学上可能是新鲜的，在哲学上，世界是复世界，这个概念就像数学上用复数来统一实数和虚数一样。复变函数所描述的世界，是不是就可以是这个复世界呢？如果我是数学家，这个事也会是我感兴趣的事情呢。我是软件工程师，所以，我还是回去研究我的软件吧。这个发现至少会在为关系的实体化方面的处理提供可信赖的支撑。这对面向资源的软件开发来说，无疑是一个重大的启发。我知道的，在面向对象编程中，并不缺乏解决这类问题的技术。小结到此为止，我们发现了至少可以归纳出来的 6 种关系是： 1. 在客观事实世界中，同一事实级别内不同资源的关系，协作关系，红色线段表示。 2. 在客观事实世界中，不同事实级别内的不同资源的关系，组成关系，黄色线段表示。 3. 横跨客观事实世界和概念事实世界之间的关系，例证关系（虚实跨界），蓝色线段表示。 4. 概念事实世界中，同一概念抽象级别内的资源组成关系，白色线段表示。 5. 概念事实世界中，同一概念抽象级别内的资源协作关系，紫色线段表示。 6. 概念事实世界中，不同概念抽象级别之间的关系，概念抽象关系，绿色表示。以上 6 种关系，可能意味着在软件开发中需要用源代码的方式，编写 6 类关系的处理代码，作为平台的功能提供出来，在实际的应用开发中，只要使用这六类关系之一，如实地定义相应的资源之间的关系，就可以期待，大部分的资源关系的处理，都能得到平台的支持。当然，这是一个不完全的归纳，相信深入研究下去，还可以发现为数不多的更多的不同类型的关系，只要这些关系在抽象类型上可以被划分为确切的可操作的几种类型，我们就可以通过扩充一种新类型的关系可供定义使用。应用软件则可灵活地在系统资源间，按实际事实的需求添加新的资源关系，系统的引擎就会按照预定的模式处理这些关系。总之，关系实体化是将对象模型资源化的关键技术，这一关键技术的突破，将抹平对象模型的设计时与运行时之间的鸿沟，使得资源模型具备“动态地构建动态的模型”的能力。邱嘉文 2014 年 9 月 11 日非常感谢博友：刘钢老师在哲学方面的指点，让我有底气贴出早就写出来了，但由于对哲学的敬畏不敢贴出的，这篇哲学味较浓的文章。; 个人分类: 面向资源软件开发方法|3207 次阅读|7 个评论

面向资源应用软件开发心法：资源语言编程思想: 热度 2 Babituo 2015-1-5 16:11; 资源语言编程思想 “面向资源”的语言范式面向资源的应用软件开发方法，是以“资源”为唯一运维元素的开发方法。这意味着该方法的思想基础，是以“资源”作为最基本的原子概念，实现对软件开发活动与现实世界的社会活动的抽象统一的认识和描述的。可以说，面向资源的开发方法，是通过在“资源的抽象层次”的统一设计和调度，来实现现实世界和智能世界的协同运转的。应用软件的资源，本质上是信息资源。也就是说资源的“实体”就是“信息”，资源是由信息聚合而成的“实体”，然后在这些实体之间设计和运转着一些静态的、动态的、多层嵌套的组合关系，就构成了软件的信息世界。所以，资源是用来观察、描述、构建和运转软件的信息世界的一种思考方法和语言范式。因此，面向资源开发方法中的资源描述符号和方法，就是一门同态描述信息世界和现实世界的编程语言。这门语言，必定有其独特的使用方式和方法。动态组织的结构模式 “运动与变化”，是全人类无论是谁，从哪个方面，来认识世界的哪个部分或整体，都能共同得到的一个性质。假设能用“资源”这个名称来统称这个世界的基本组成事物，那么，这个世界就必然是一个在各个资源之间建立的动态关系的总和，这样，“资源”，看起来只是“事物”的代名词。在面向资源应用软件开发方法的语境中，“资源”还是人类创造的“信息世界”中的“事物”代名词，因为在信息世界中，如果把基本的组成要素还叫“事物”的话，总会让人感到有点不适应。不管怎样，重要的是要给这两个空洞的词汇赋予最少必须赋予的含义。“动态组织”应该会是这个含义的首选。“动态组织”的内涵，可充分地将资源概念引向结构化的运动和变化的理解。对任何一个动态的组织，似乎总是可以放到这样一个语言框架下来得到描述，这个语言框架就是：目的－目标－功能－行动－实体。当然，在认识事物时，并不是对所有类型的“动态组织”，在这个语言框架的各个层次上，都可以被分配到同样多的内容。比如，生命组织和类生命的组织，分配重心偏左，而非生命的组织则偏右。但为了寻找一个统一的架构来对所有的“资源”或“事物”一视同仁的话，可能很难有第二个框架更适合来表达其“动态组织”的内涵。如果说，这个世界的本质，本身就是一道巨大的程序的话，那么，这道大程序，至少是要在这个语言框架的五个层次上，同时得到编写的。再如果，编写这道大程序的基本指令单元，可以是“资源”的话，也就意味着要问：能满足编写这道大程序的要求的指令系统，可能会是怎样的呢？五层程序的实质要回答资源指令系统必须满足的要求的问题，先要探究动态组织的五层程序的实质。然后才能设计和验证用来实现这些程序的“资源编程语言”是否能够一致地满足这些编程的需要。实体的程序，是对实体相对处于静态的构建组成结构关系的编织；行动的程序，是对实体之间交互操作的连接关系及其在时间次序上的编排。功能的程序，是对实体行动被执行时反映在不同实体上的改变过程和效果的组合要求。目标的程序，是对实体功能实施后反映在关键状态指标上的到达预定值点的时序要求。目的的程序，是对实体在精神意识层面获得暂时的安定和满足状态的时机的安排。显然，这五层的程序是各自独立、相互关联、逐层依赖－控制、并同时运转的。实体的程序是行动的程序的基础，这意味着：只有在相互建立了广义的信息联络通道的实体之间才能通过广义的信息通信来实现交互的操作；而实体之间的交互操作，必定会改变相关实体的结构或外观，也就是会获得相应的功能效果；而功能效果的实现是以达到特定的目标次序来证明和检验的；按预想的方式达到了相应的目标，就能给有意识的主体带来目的上的满足感和安定感，当然，一个意识主体的目的的满足，可以、可能或必然（有意、无意或不可避免）同时会破坏另外一些的意识主体在目的上的满足感和安定感，就迫使另外的意识主体会做出行动，重新达到自己原来的，或新想的目的和新设的目标。于是，这道大程序就会“永不停机”地在五个层次上同时展开，不断运转下去 ...... 。有趣的是：虽然非生命形态的动态组织缺乏自我的目的性，也没有主动的目标状态，但它们并不是它们就绝对不会出现在目标层次和目的层次的程序中的。因为，除了在意识主体的这两层程序中，必不可少地会有非生命形态的动态组织参与外，当然，它们通常是被当作“客体”来对待的。事实上，是客观规律代表着它们背后的“主体意识”的。它们反而会在主体意识层的程序上表现出比那些所谓的“意识主体”更强的稳定性。这也是这个世界具有“可编程”特性的原因，否则，一切的“程序”都无从谈起。所以，这道“大程序”，是有目的地遵循自然规律的程序。当然，也可以是相反的，这样，这道大程序就可以很快坍缩到仅剩实体和行动层次的程序了——所有意识主体、包括人类都被这道程序消灭掉了。所以，在这个大程序的编写中，我们最好还是把被我们“蔑视”为非生命的动态组织，当作一个强大的意识主体来对待为好。不要以为这个大程序很空洞，太虚无缥缈，实际每个人的一生的每一刻，都是这道大程序的一部分，而且，有可能永远影响着这道大程序的未来运行——即使生命个体逝去——发挥影响的不是其人体的物质残留，而是其留给这道大程序的信息遗产。如果说，面向资源的开发方法有其目的的话，其目的就是：希望全人类的每个人都能为这道大程序留下有价值的信息遗产。资源的结构面向资源的应用软件开发中的资源结构非常简单，就是：一个成员集合。任何一个资源，都是由多个不同数量种类的信息成员组成的一个张学文广义集合。对资源的结构，形式化的表达如下： R :={n1*IM1,n2*IM2,n3*IM3,...,nN*IMN} 其中： R: 表示任意一个资源； ni: 包含的某类信息成员的个数； IMi: 表示某种类型的信息成员。资源的信息成员就是资源的属性参数成员。是具有某种参数类型的属性类型的取值，其参数类型作为系统存储和计算操作的依据，而属性类型则作为可理解的信息含义的标志。具有这样的结构的资源，如何能够满足编写那道大程序的任何一小部分的需要？为简化起见，接下来探究资源是如何在“功能 - 行动”的双层上进行编程的。这两层，也是当前应用软件编程中，软件的逻辑内容的主要分布区域。以下通过资源编程和代码语言编程的对比分析，说明资源编程继承和发展了一般代码编程语言的全部语言功能要素，因而可期待资源编程能实现通用的应用编程。功能 - 行动双层编程一个功能是一组行动得到执行的外显过程和结果。仔细理解这句话，有如下几个方面的含义： 1. 功能层和行动层的程序是不同层次的程序，需要严格区分。既不能在功能层的程序描述行动过程逻辑，也不能在行动层次描述功能的组织逻辑。需要指出的是：对两个层次的程序不分开的混合编写的做法，在目前的面向对象编程方法和语言中是允许的，而且实际是大量存在的，因为这只取决于程序员的表达习惯。这使程序表现出如下的现象：在同一段程序代码中，我们总可以看见具有应用功能含义的函数过程的调用语句，又有操作数据参数等，系统的计算资源的语句出现。其中的函数和过程调用，就是功能性的语言，操作那些系统计算资源的语句，就是行动性的语言。实现这些函数或过程的那些段程序，则对应着每项功能的行动层的程序。这种不严格分开功能层程序和行动层程序的方法，确实给程序的编写带来了很大的自由，但实际效果上却是模糊了系统的层次性的边界，让系统的层次性耦合度很难得到控制。这也是造成应用软件系统程序维护困难的主要原因之一。在目前的编程语言中，除非建立相应的编程规范，而程序员严格遵守这些规范，才可能编写出功能层和行动层分开的程序来。但事实上是不会有这样的规范出台并可以得到执行的。因为这样的规范，用在目前的编程语言环境中，对编程的行为本身造成了很大的自由度的约束。类似在允许有六个自由度运动的三维空间上，又只允许物体在分开的两组不同的自由度上作运动，这会让在空间内运动的物体“感到非常难受”。目前的应对该问题的方法是靠软件的层次型的架构设计来解决。需要架构设计师在架构设计阶段就设计不同的功能集合的架构层次，然后让不同的程序编码活动分开来实现不同层次的功能，让底层的程序提供支持上层的程序的 API 接口。这样的策略是可以将系统的层次性耦合得到控制，但在系统层次性的功能构建和行动构建之间增加了人为的工作流程的约束：必须先完成架构设计，然后才进行编码。而这些约束，并不是构建行为本身就存在逻辑约束。带来的根本问题是：原本可并行的工作不得不串行进行。当然，由此带来的系列问题影响到软件项目的方方面面。资源编程的思想和方法，通过为功能编程和行动编程提供“两个相互平行的编程空间”各自独立而又相互对应的双层编程方法来解决这个问题。由于是在两个不同的编程空间内进行编程，两个不同的空间可使用的“编程指令集”本身就代表了不同的语义：在功能层编程空间中，只有资源的功能性描述语句可用；而在行动层编程空间中，又只有资源的行动的操作指令可用。这样，在两个各自独立的空间内对编程的行为就不需要任何自由度的约束，这些约束转换成为编程环境本身的结构约束了。就好比：将“在一个花园里对不同的观赏需求设立由不同的观赏路径关口划分的禁区”的做法，改成“直接建设两个不同视角的风景的花园，比如一个地面，一个空中花园，对两个花园都不设立任何观赏禁区，但又有连接两个花园各对应景点之间的快速栈道，让观赏者可自由切换所处花园”的做法。 2. 功能层是比行动层更高级的语义层。日常说的：“你做这些事有什么用？”就表达了行动层和功能层之间的关系。“做这些事”就是行动层的描述，“有什么用”就是功能层的描述。而此处的“更高级”则有做两层的含义：首先，更高级，是对行为粒度上的集合后的粗化表达；其次是对一组关联的细粒度的行动集合的功用语义的封装表达。功能层的程序，是纯粹的“有哪些用”的组合关系，和“怎么得到这些用”处是不同层次的表达，当然，这些“用处”的表达之所以会集中在一组相关的组合逻辑中，是因为它们都是为了达到同一个目标。而“怎么得到这些用处”则是围绕这个功能的一系列的行为的逻辑组合。 “一项功能”和“一个可分解为多个动作的大动作”的表达是不同的。不同在于，功能可以是，但不一定是对应“一个大动作”的。因为，通常意义的“一个动作”，是由一个实体做出的，而功能所含的动作集合，可以是多个实体的多个相关动作的逻辑组合。除非，参与功能的多个实体，可以理解为是共同组成的“同一个大实体”。而我们通常也正是：将“形成一组相关功能所需的参与共同度较高的一组实体的集合”，认识定义为是一个更大的实体的。而包含在更大实体定义之外的实体动作关系，则成为更大粒度实体上的动作关系。即使是这样，功能的含义也只是对这个大动作所能产生的作用的描述，而不是这个大动作本身。这就是所谓的“语义的封装”。同样，在功能层的程序中，本身也存在小粒度的功能组合封装为一个大粒度的功能的嵌套表达。这种功能嵌套的表达，也和行动层的大小行动的嵌套表达没有强制性的直接对应关系。所以“嵌套结构”只是一种程序的结构特性，并不是行动层程序的专利，是多项行动形成一项功能的必要但不充分的条件。 3. 功能之对应行动，不是动作逻辑上的对应，而是行为语义的对应。这意味着“功能层的程序”，不是可直接进行操作的程序。只有行动层的程序，才是可直接进行操作的程序。执行行动层的程序本身，就同时是在“执行”对应的“功能层程序”，并没有单独的“功能层程序”的执行过程独立存在。尽管“功能层程序”不是直接执行的程序，但由于它们对应着可执行的行动程序的每个功能单位。所以，在行动程序被执行的过程中，我们又确实同时可以观察到：一个“功能的程序”正在得到执行。同样的道理，功能层程序之对应目标层程序，目标层程序之对应目的层程序，也有类似的“既封装了细粒度的行为，又转换了不同层级的语义”的作用，从而实现了最顶层的目的与最底层的实体操作的一致性和连贯性。资源的操作指令和资源编程资源作为实体的结构很简单，是一个关于信息成员的张学文广义集合。而资源进行操作的指令也很简单，只有一个，就是：“连接”。为什么会只有如此简单的一条操作指令？因为对“信息成员”所能，所需进行的唯一的操作的方法，就是连接到其他信息成员。这就是对资源行动层编程的唯一指令。资源的一个行动，意味着，也仅意味着：连接多个不同资源的不同的信息成员。也就是使不同资源的被连接的不同的信息成员的信息一致。这非常类似语言代码编程中的“赋值”语句。本质上，连接，也是实现一种赋值操作。我们不禁要问：如此简单的编程方式就能实现以往编程语言的同样功能，就能编写出同样功能的程序来吗？如果这样，其他编程语言的除赋值语句之外的，大量的功能性语句和结构性语句又有什么用处呢？答案是：不要忘记，资源语言是建立在其他编程语言基础之上的更高级的编程语言。在行动编程的空间，相当于它只保留了代码编程语言的“赋值”操作，这种最少必须保留的操作。而代码编程语言的其他功能性语言，和其他程序的组件， API 一样，全部都转换为可供使用的“资源组件”了。不仅如此，其他代码编程语言的程序组件，不仅可以作为一个整体的资源组件来使用，而且还可以按组件的功能结构，“被拆解”为相应的“成员组件”，直到拆解到原始编程语言的最小的功能单位为止，而原始编程语言的最小功能单位，就是面向资源开发中的“原子资源组件”了。所以，资源的行动层程序就是这样的：连接两个不同的资源信息成员，就代表一个原子行动，多个原子行动按一定方式组合，就构成一个小行动，多个原子行动和小行动按一定方式组合，就构成一个大行动。而资源的功能层程序则是这样的：如果需要一个连接多个信息成员的动作组，那么，这个动作组会产生什么效果或代表什么变化的过程，直接给出效果和过程的自然语言描述名称就可以了，这样，将不同的动作组按不同的方式组合起来，自然就是将不同的功能组合起来的当功能了。当然，也可以反过来：需要什么样的程序功能效果或变化过程，可以直接用自然语言来描述这些效果和变化过程。然后，在来寻找：要实现这些功能的话，需要，也只需要将哪些资源组件的哪些信息成员连接起来就可以了。资源行动组的连接方式在以往编程语言中，有几个程序结构语句，在资源编程中，被转换为几种不同的行动组合方式的动作，如： “抉择”动作 , 代表 if... Else... 语句。代表根据一个“是否型”信息成员的值做出后续行动组的不同选择的操作。 “选择”动作，代表， case X of... 语句。代表根据一组“是否型信息成员 - 行动组”中，按顺序检查信息成员值选择最先满足条件的行动组的选择操作。 “择进 / 择回”动作，代表 While...Do 和 Do...While 语句。代表根据一个“是否型”信息成员的值做出后续是否重复进行一个行动组的执行的操作。而每一个抉择、选择、择进 / 择回的操作，都有其实际的功能性含义，同样可以将其功能的描述作为功能层程序的内容。这样，上述的操作行动，同时也就是某类选择和控制型功能的实现方法，可分别编写在行动层程序和功能层程序中。在日常的行动组合中，常常会使用一种多个行动组按动态排序的结果先后执行的组合方式，不同于计算机编程中的 Case 语句，只选择多个是否条件中，按顺序最先满足条件的分支动作，这种组合需要按多组动作的排序的结果顺序，执行全部的动作。当然，这种组合方式在目前的代码编程语言中也可以实现，但作为一种通用的程序组织方式，实现起来也有一定的难度。这种组合方式在资源编程中作为一种通用行动组组织方式提供，称“序择”动作。资源语言编程中心思想资源编程语言是建立在面向对象编程语言基础之上的，以资源为唯一编程实体元素的高级编程语言。从编程实体上看资源，资源是一组信息成员的张学文广义集合。信息成员就是资源的属性参数成员。资源编程语言只有“连接”这一种对资源实体操作指令。资源编程严格分开功能层程序和行动层程序。连接资源的信息成员就是编写资源的动作程序。给出资源动作或动作组的功能描述，就是编写资源的功能层程序。使用“抉择、选择、序择、择进、择回”五种资源组组合指令，就能编写出各种复杂的资源组合程序，同时给出资源组合的功能应用组合的含义。 2015 年 1 月邱嘉文于珠海诚开智能参考文献：【1】《组成论》，张学文。; 个人分类: 面向资源软件开发方法|2932 次阅读|2 个评论

资源组件的三种上下级关系: 热度 1 Babituo 2014-12-14 15:11; 资源组件的三种上下级关系应用软件观念的变革面向资源的应用软件开发方法虽然是在面向对象的软件开发方法上拓展出来的一个新方法，但迅速理解和掌握面向资源的应用软件开发方法精要，则不必从软件内部的体系结构的变革开始来理解，而只要从我们对应用软件的外部观念进行如下拓展开始：传统的应用软件的观念，是将应用软件视作辅助业务工作的工具来对待。随着软件的运行环境不断在应用领域、应用地域、应用深度、应用功能和相互连接等各方面的迅速成长，软件的世界和人类社会的现实世界已经接近全面的融合了。也就是说，我们看待应用软件观念，已经可以从“是在外部辅助我们工作和生活的工具系统”发展到“就是我们工作和生活的世界本身内部的一部分”了。完成了这一观念的变革，就能理解为什么应用软件的开发方法是面向资源的了。资源，作为推动世界运转所需的一切实体和虚体形式的材料，是一个广为人知，耳熟能详的概念。从生产生活上的物资、材料、设备、机械、人工、智力、知识、经验、信息以及他们之间的各种连接和关联的关系，甚至所需的场地、空间、资金、能量和时间及其约束关联关系，都可以被统一理解为是“资源”。所以，资源是构成人类社会的构建和运转要素的最抽象而又最通俗的概念之一。而当今的软件世界已经和现实世界高度的融合了，我们看待现实世界的构建和运转要素的方法，自然也将适应于用来看待软件世界的构建和运转的要素。这一观念，在笔者研究和开发面向资源的应用软件开发平台“诚开智能软件平台”的实践中，一直是作为一条最基本的信条被秉承着。在此信条的指引下，寻找面向对象的软件开发中的概念和现实生活世界中的概念的对照关系，就成了一项别开生面的有趣工作。资源组件概念由来软件的“组件”，在现实世界的一个隐喻就是“积木”，就是软件构建和运转的主要的一种“资源”。可以说，现代的应用软件，就是通过建立和连接数量众多，功能各异的组件资源来实现系统的构建和运转的，所以，如何设计组件的构建、连接和运转的机制，就是研究面向资源应用软件开发方法的重点内容。面向资源的应用软件开发，必定不会是以程序代码为主的方式来构建和连接软件的组件，否则，就不应该另外取名叫“面向资源”了，因为以程序代码为主的资源方式，就是传统的面向对象的软件开发方式。虽然资源组件的构建方式是一个说来话长的问题，但对三种有趣的资源组件的上下级关系，则可长话短说。这三种资源组件关系就是：母子关系，父子关系和主从关系。这是现实世界人力资源的三种基本的人际上下级关系，可用来直接映射表达三种基本的软件资源组件关系。这里说是“映射”，不仅仅是一种“隐喻”，而且表示在语义关系上存在有趣的高度一致的对应关系。有趣到我在诚开智能软件平台开发的程序设计中，发现对其中两个关系的表达用词多次更改，最后还是发现直接就用原词反倒是最恰当的表达。程序语言组件间的三类上下级关系传统面向对象的程序代码中实现了两种最基本的组件上下级关系，是“继承关系”和“聚集关系”。其中的“继承关系”语义非常清晰。在程序设计语言中，实现这个关系的关键词是“Class”。就是“具体类自动拥有被继承的祖先类的属性和方法定义”的关系。其表达的是后代同态于祖先的基因遗传的关系。在这层关系下，具体类继承抽象类，类实例化为对象。表现为：“祖先变，后代随变”，“模子变，实例随变”的关系。另一类“聚集关系”的语义并不那么清晰，实际主要包含两类：一类是“聚合”，是“强聚集”，另一类是“弱聚集”，在程序语言中常用“Owner”和“Parent”来标识这两类聚集关系，即“所有者”和“父母”关系。其中的“所有者”关系表示：聚集在“所有者”组件名下的所有组件，是以所有者为生存依赖的，即：所有者生，聚集者随生，所有者灭，聚集者同灭； “父母”关系表示：多个“聚集者”组件是在同一个“父母”组件的承载和管理下进行活动的。对于聚集者组件而言，“父母”组件就像是容器，聚集者组件可以根据需要，更换到不同的容器之中接受管理。经验不足的程序员经常会混淆Owner和Parent的用途。多少和这两个词汇实际含义和在这里的用法表达的含义不十分吻合有关。为什么会出现用词表达不准确，多少可能和编程语言的设计者没有把应用软件的世界看成是现实世界的一部分有关。对资源组件间的Mother关系在面向资源的开发方法中，软件的设计平台和应用运行平台是同一个平台。就像餐馆为了适应顾客对食材的种类多，数量少的灵活需求，把厨房的烹饪平台和顾客的饮食桌面合并为一个平台，从而发明出“火锅”一样。软件开发相当于烹饪菜肴，而软件应用则相当于消费饮食。可见，原本分管设计和应用的两个平台的合并，是实现随需应变的前提之一。而对这一餐饮业火锅的隐喻，还可继续深入对照下去：传统面向对象编程语言的开发相当于餐馆的菜谱开发，Class就是炒菜的菜谱，Object就是炒出来的菜。按什么菜谱操作，炒出来的就是什么菜。食客只能按菜谱的目录单来点菜，厨师也只按点到的菜单的菜谱来炒菜，多菜谱混搭的饮食需求是不受欢迎的。面向资源的应用软件开发正是要克服这种“一次性设计”带来的问题，但又不能丢失“类-实例化”机制带来的“知识重用”的效果。似乎出现了矛盾：既要得到抽象描述的知识重用的效果，又不能接受必须把抽象描述转换为实例才能运行的“鸿沟”。如何解决这个矛盾？解决这个矛盾的诀窍，正好是中国古代哲学和西方哲学的差异的现世反映：形证法和例证法的差异性和等效性。在面向资源的开发平台中，设计元素不再是抽象的形式化的符号表述，而是实际的软件对象。比如，对需要一个整型变量的设计，不再是用编程语言的“Integer”这个词来告诉计算机，这里需要一个整型变量，而是直接在计算机中，创建一个实际的整数变量的实例来进行设计。这个实际的变量，就是计算机中实际运行着的软件资源，面向资源的开发，就是用本身就在运行着的软件资源来告诉计算机如何工作。为解决知识性的重用问题，只需把已构建的任何组合形式的资源组件实例，当作一个样板，照此克隆或以此为模板创建新资源组件实例即可，这两类创建关系之前被称为“例型”和“类型”两类关系。其中的类型关系，在样板组件和以样板为模板创建的新组件之间，就建立了一种具有抽象约束力的表达。这种关系不仅完全可实现面向对象编程语言中的类继承和实例化的关系，而且和例型关系的交替组合，能带来广阔的动态演进机制的设计空间。由于这类关系是决定新资源组件的产生的，因而被称为“母子关系”。在其中的资源组件的类型关系中，子总是类母的，母变子随变。在资源组件的这类母子关系中特殊的是：　即便是已经出生的子资源组件，和生其的母资源组件之间的母子关系总是存在的，只要母变化结构，子的结构也随之变化。在我的编写的诚开智能软件平台的源程序中，最后选来表达这类关系的程序用词，就是“Mother”。即：一个资源组件可以有一个Mother为母组件作为其类型，并可以同时成为其他多个资源组件的Mother。资源组件间的Father关系如果说母亲对子女的主要责任是“生”，那么，父亲对子女的主要责任就是“养”。“生”决定了子的性状随母，而“养”则决定子的存活状态随父。所以，对传统程序代码中实现的组件之间的“Owner”关系，在资源组件之间，则更准确地用“Father”来替代了。显然，一个资源组件只能有一个父资源组件，整个系统是最大的父。而一个资源组件可以作为多个子资源组件的父资源组件而存在。父必定比子先生，父死子亡，否在则父死前必托孤给新的养父，这些关系在资源组件的生命周期控制中，都是可用的机制。在软件世界中，反映现实世界的这种父子关系模型的实例比比皆是。比如，在一个智能试验工作管理系统中，所有的业务对象的数据表述集合都可认为是资源组件，而资源组件的父子关系，往往构成应用系统的主心骨，如：一个公司和公司所设的每个部门，一个部门和部门所设的每个岗位；一个购销合同的文本和该合同所订购的产品的描述；一个产品的描述和针对这个产品所做的每项试验的试验记录；一个产品的描述和针对这个产品的每个试验报告；一项试验类型的规则和根据这个规则进行的每次试验的数据记录等等。这些都可以建模为资源组件的父子关系。可见，父子关系是“子依托父的存在而存在”的一种特殊的一对多的组件关系。如，撤销了一个部门，那么，该部门的岗位就不复存在了。而正是这些具有父子关系的组件集合，构成了一个试验工作管理系统的数据骨架。资源组件间的Master关系从以上的分析可见，在传统的面向对象编程语言中（后简称OO）的组件关系Class,对应到了面向资源开发（后简称RO）的组件关系Mather;而OO中的Owner则对应到RO组件关系Father。反倒是本来该表达Master含义的时候，在OO中使用了本该表达Mother和Father含义的Parent。OO中组件关系用词的通俗语义，看来是正好搞反了。所以，资源组件剩下的一种一对多关系就是主从关系，也就是Master关系。这和现实世界的每个人的人脉关系，真的是形成了工整而有趣的对照：每个人都是“母生父养头儿罩”着的，不是吗？资源组件也是这样的呢。不像Mother和Father统管着资源组件的生命周期，Master统管着的是资源组件的活动周期。一个资源组件，参与着另一个资源组件所主控的活动，那么，在该活动中，就接受主控组件的调遣。直到该资源组件完成在改活动中的使命，退出该活动，并参与到其他的活动中，则表明资源组件更换了其Master。这和现实世界的职业人变换工作改老板的隐喻也是很贴切的。当然，每个资源组件也有机会成为其他资源组件的Master,只要我们在资源的活动逻辑中，定义了参与该活动的其他资源组件。三树错合构建资源组件的复杂动态关系网资源组件之间的三种关系，都是连续的一对多的关系，也就是说，就某类关系而言，资源组件之间都构成一个树的关系。这样，一个应用软件系统就有了至少有了三个相对独立的关系树的结构。由于这三个树结构都是叠加构建在每个资源组件之上的，因此，系统的全部的资源组件就将这三个树交织了起来，形成了一个有序而又复杂的，动静相宜的关系网。 Mother关系相对比较固定，只有Mother组件或子组件自身消亡时，其子组件的母子关系才断开，子组件的结构此时就只受自身演变的影响了。 Father关系相对比Mother关系灵活一些。在Father消亡时，可选择将子组件“托孤”给其他组件做子。如果选择不托孤，则子组件个跟随父组件消亡。 Master关系相对最灵活，通常，一个资源组件在一个时刻只有一个Master组件，也就是说，一个资源组件在一个时刻只参与一个资源活动。资源组件在资源活动之间的活动调度，则由活动规则自身来控制。因此，一个资源组件在某个时刻的Master组件是谁，实际是动态变化，不可预知的。面向资源开发方法，正是靠实现了这个内部机理，从而带来软件系统的可演进性的。这也是面向资源的应用软件开发方法，从软件的角度实现平行演进系统的技术方案的核心。邱嘉文 2014年12月于珠海诚开智能; 个人分类: 面向资源软件开发方法|3784 次阅读|2 个评论

面向资源应用软件开发方法首次公开讲座PPT: 热度 1 Babituo 2014-11-22 09:19; 时间：2014年11月26日地点：珠海城市职业技术学院活动：珠海学术活动周诚开PPT讲稿.pdf PPT格式在论坛上： http://bbs.sciencenet.cn/forum.php?mod=viewthreadtid=2270875page=1#pid3487151; 个人分类: 面向资源软件开发方法|7083 次阅读|1 个评论

对象的例型和类型概念的提出: 热度 2 Babituo 2014-10-21 14:10; 前言由本人提出的面向资源的应用软件开发方法，为了实现“可在运行时设计”的特性，就必然要突破“设计 - 运行”之间的鸿沟。一旦软件开发工具提供了这样的特性，就意味着，软件，可以在运行中，一边运行，一边进行软件自身的设计和改进，也可以说，对软件的结构的设计改进，已经成了软件运行的一部分了。这意味着真正赋予了软件类似生命的特征，正如我们教育和培养下一代，是在他们“活着”的同时所进行的一样。我们不会将一个被教育者置回某种休克的设计状态，对他进行教育和培养，然后再换醒他活过来去更好地行动和思考。而现代软件工程对一个软件的开发和升级本质上还处于这种模式之下。面向资源的应用软件开发方法，就是要实现“编写活着的程序”。于是，实现对象的可演进性成为实现真正的软件“随需应变”的必要技术，同时，也是实现“编写活着的程序”的开发应用模式的关键技术。在有能力提供这项技术之前，所有的“随需应变”都是在奢谈。本人目前正试图在诚开智能软件开发平台的开发中，尝试向这一技术实现发出挑战。由于没有先例，开发的过程伴随着理论的探索和编程的实践交叉进行。在这种全身心的投入研究开发过程中，不断有新的发现，新的否定，真的是一种美妙的研究享受。对象的例型和类型，例象和类象概念的发现，就是在可演进的对象模型探索中，获得的有趣的认识之一，特分享给网友们去体会。概念由来在当今 OO 编程语言中，实际上已经显露过这两个不同的概念的区别了。比如，在 Java 中，我们可以新建 New 一个类 Class 的实例对象 Object ，也可以以一个对象 Object 为蓝本，克隆 Clone 出另一个对象 Object 。这里，克隆的目的在于重用蓝本对象的数据值。同时，也是按蓝本的类型创建的一个新的对象实例，也就是说，对象克隆，同时重用了蓝本对象的结构 Class 。由于在现有 OO 编程语言中，不存在对象的可演进性，也就是说，不存在提供在程序运行中再来改变对象结构的特性的设计考虑。这是在当前 “ 设计 - 运行 ” 分离的软件应用模式下，不需要的特性，当然，也是该模式下应用开发的软件不可能真正实现“随需应变”的根本原因所在。在之前的博文中，我已经介绍了，实现可演进的对象模型的关键，是在运行时彻底打通“属性 - 类型 - 对象”之间的相互衍生的三角关系。也就是说，要从当前的软件开发，是“从属性定义衍生到类型定义，再衍生到对象创建”这一单向的单程过程，改变为可双向循环互通衍生的过程。也就是说，要实现对象的可演进特性，关键是要实现除了上述单程单向开发路径外，还要能首尾衔接，反向贯通。具体地说，就是实现：首位衔接：可将对象拆解为属性成员对象，可将拆解的成员对象克隆重新组合新的对象。反向贯通：可根据非类型实例化创建的对象反向归纳出类，根据已经定义的类，定义新的属性类型。例型和类型概念的提出，正是为了实现“属性 - 类型 - 对象”之间可双向循环互通衍生的理论需求之一而被发现的。概念提出例型：以 A 对象为例克隆一个 B 对象， A 对象为 B 对象的例型， B 对象为 A 对象的例象。类型：以 A 对象为类创建一个 C 对象， A 对象为 C 对象的类型， C 对象为 A 对象的类象。关键特性：改变例型结构，不改变例象结构；改变类型结构，类象结构跟随改变。主要性质： l 一个对象可以是其他一些对象的例型，同时可以是另一些对象的类型。 l 一个对象，要么是例象，要么是类象，而且只能有唯一的例型或唯一的类型。 l 一个对象，不管是作为例象、类象、例型还是类型，其值的改变只改变自身，不改变其它任何对象的值。 l 只有作为类型的对象结构改变，才改变其类象的结构。作用划分：例型的作用在于重用对象的数值。类型的作用在于可同时重用对象的数值和结构。概念的意义可演进性设计的最终目标，是解决继承和发展之间的矛盾。面向资源的可演进性对象模型为可演进性设计提供了新的设计时空。回到前言 ... 2014-10-21 邱嘉文于珠海诚开智能; 个人分类: 面向资源软件开发方法|3468 次阅读|3 个评论

一个软件开发工具是否可用于开发其自身？: 热度 3 Babituo 2014-8-25 12:27; 我产生面向资源开发方法最早期的思路来源于对这个问题的思考？那还是在1993年前后，当时国内流行的中文DOS系统有一个UCDOS。那时，Window已经出现，但如何在Windows下开发应用程序还是一门高深的技术。如何在UCDOS下开发出发仿Windows的具有图形交互特性的应用程序，是很多DOS程序员都在探索的技术。我硕士研究生论文是“电力监控图形应用模型的研究”。其实，就是做一个DOS下的SCADA平台的图形画面的编辑工具。这让我对图形学编程有了浓厚的兴趣。所以，工作后尽管从事了管理软件的开发，仍然把图形编程当作是自己的一把利器。我开始开发的第一个管理软件，是试图在UCDOS下编写一个电力工程概预算的软件。为了在UCDOS下编写出类似Windows的图形界面，我开始了有趣的尝试。当时流行的开发语言只有Turbo C和TurboBasic。在我研究生课题的交互式图形编辑引擎的基础上，开发一个绘制图形画面的程序，并不难。有趣的是：用自己的交互式图形工具画出来的图形画面，可被用来当作另一个软件的交互操作界面。比如，图形菜单，就是先画出菜单摸样的图形，然后再用程序代码载入画好的图形文件显示出来就成为了漂亮的图形弹出菜单。这样，就省去了用编程语言编写图形显示界面的大量工作。虽然，这个项目很快被和合作者一起在Windows下的编程技术取代。但却给了我一个重要的启示：用编写出来的软件工具构造的资源，可用于构造其他程序。而当软件工具本身，就是要构造的“其他程序”的内核的话，一个软件开发工具，岂不是可以用于开发其自身了？; 个人分类: 基因软件开放实验室|3354 次阅读|6 个评论

面向资源的可演进软件系统的基本原理-2: 热度 1 Babituo 2014-8-16 22:45; 实现可演进性的基本原理属性属性：用来描述某个对象或种某类型的某个特征的一个数据表述的方式，称为一个属性。比如：用来描述“属性”这种概念对象自身的属性有：名称和数据类型两个属性。例如：为描述“人的称谓”，需要一个具体的属性实例，其名称的数据是“姓名”，其数据类型的数据是“文本型”。类型类型：用多个属性进行组合来描述的一个个体种类，称为一个类型。例如：用“姓名”，“年龄”，“性别”，“身份证号码”，“相片”等这组属性进行组合，就描述了“人”这个实体种类，也就得到“人”这个类型。对象对象：由一组属性的数值来组合描述的一个个体，就称为一个对象。例如：由 { 姓名 = 王小二，年龄 =12 岁，性别 = 男，身份证号码 =XXXX ，相片 = YYY.jpg} 这组属性值组合在一起，就描述了一个人的个体，这个个体，就是一个对象。属性，类型，对象三者基本关系概述事实启示：可操作的对象的存在并不依赖于其类型的存在，而只依赖于其属性是否被标识出来，以及对象在标识出来的属性上的取值是否明确得到。比如：对于一匹马，即使我们没有建立对“马”这种动物类型的认知，这匹马本身，还是作为一匹马存在着，这并不妨碍我们骑上它去驰骋。这意味着，在事实层面操作和使用对象时，可以不必关心对应的类型是否存在，直接操作和使用对象的属性值就能反映事实的变化过程。类型只是在归纳认识理解同类的对象时，才会必须用得上。所以，可以有两种途径得到对象的定义： 1. 直接对一组属性的取值组合进行标识； 2. 取类型所包含的属性组合进行联合取值进行标识。认识到上述事实，是理解对象及其关系“可演进”的特性实现原理的突破口。基本原理传统的面相对象的软件编程所实现的软件系统，采用的是单独的上述第 2 种方法得到运行中的软件对象实例。“编程”的行为本身，就是在固化对象的描述框架，就是在限制运行时对象的属性和能力，不可能超出编程时所实现的“类”的描述。如果构建一个软件开发和运行统一的一体化平台，使平台具备直接采用上述方法 1 在运行时通过临时组合不同的属性取值，以及对这组取值的处理方法来构建运行时所需的对象的能力。这实际上就是绕过了“类”的限定，直接在运行时制造出所需的对象。这样的对象，不仅不受设计时的“类”的局限，反而可以通过对运行时运用相同属性方法所直接构造出来的对象进行归纳，得出需要的“类”来，再使用归纳出的“类”（实际是以直接构建的对象为“例”，而不是源程序所设计的“类”）来直接指导后续的系统自身的构建行为。这样，就不需要经过一个“设计”的过程来阻断对象的演化，既可以实现对象的演进和突变，又可以充分利用成熟的、自动归纳的“类”来实现对象属性和行为定义的可重用性。这就是利用“可演进的对象关系”实现系统的可演进性的基本原理。简单地说，就是在运行时打通了属性、对象和类型三者的完整关系链，就找到了实现系统的可演进性所需的内在结构。珠海横琴新区诚开智能科技有限公司邱嘉文 2014 年 8 月于珠海顺便正面回复上篇读者李红雨先生的“好奇”。他提到： ... 通常来说，演进的驱动力来自外部环境的变化，如果软件系统能够实现演进，这样的驱动力可以认为是来自需求，如何识别需求对于软件本身来说是个不容易克服的鸿沟，目前都是通过设计的流程将这种需求转化为技术的逻辑，博主的设计不知道是否在理论和实践上都有所突破，... 在上篇的回复中，我只是简单地做了一下提示：您说的没错，目前都是通过设计的流程将这种需求转化为技术的逻辑的。这里需要对“设计流程”和“设计工作”需要进行仔细的辨析，才能理解到我的突破点何在。我理解，李红雨先生的“好奇”中，可能带有这样的“以为”：作者是否自称是取得了某种突破，可以跨过软件设计环节，直接利用软件需求来将业务的需求转化为技术的逻辑了？果真如此，必定需要在理论和实践两方面都取得重大突破才行。细心的的读者，或许会注意到我在这里对“设计”措辞又做了的微妙的改变，称“设计环节”。李先生原用词是“设计流程”。我对“设计流程”一词的理解是：专门用来完成设计工作的一套工作流程。也许李先生的本意，就是用“设计流程”一词，涵盖了按流程所进行的设计工作。所以，我之前会做出提示：设计流程的概念和设计工作的概念是两个密切相关但又不同的两个概念。就好比我们进餐馆吃菜，正常流程是：点菜，洗菜，炒菜，上菜，吃菜。如果点菜代表软件需求，上菜代表软件编码，那么，洗菜，炒菜分别对应分析和设计的流程。那么，我现在声称取得的突破，是不是就是省略了炒菜的过程，直接就上菜了呢？我认为，我的突破只是发明了“火锅”的吃法而已。炒菜的流程确实是被省略了，但炒菜的工作（使生食料变为熟食料的工作）并没有被省略。只是完全可以和吃菜的过程“并形地进行”而已。那种既要吃熟食，又不必把食物弄熟的“重大突破”，类似于发明永动机，我是无论如何也取得不了的。可以说，我只是在发明“软件的火锅吃法”而已。谢谢红雨的关注。欢迎讨论。希望我的谜底没让你失望。将来有机会请您吃顿“软件火锅”体验一下。; 个人分类: 基因软件开放实验室|3142 次阅读|5 个评论

面向资源的可演进软件系统的基本原理-1: 热度 5 Babituo 2014-8-14 07:31; 可演进的软件系统需求范例 S 公司是一家近年平均年销售额数亿元规模的、中国南方著名的电力互感器产品制造商。公司之所以能在激烈竞争的市场环境下迅速成长并维持长盛不衰，恐怕和公司的一条服务信条密切相关，这条信条是：“只要客户有明确可达的技术要求的产品订购需求，哪怕只需要订购一台，公司也可为其服务。” 当然，说起来如此简单的一句信条，真正实施起来却不是那么简单的事。这意味着公司必须从一线的产品研发，物流，生产，销售到二线的人资，财务，行政等，必须全面处于规范高效，同时又开放和灵活的管理状况之下；意味着庞大的客户数量，丰富的产品线，繁杂的物流线索同时处于有效的管控之下；当然，为支撑这个业务系统的高效运转，除了公司上下领导和员工的齐心协力之外，一个切实有效的 ERP 系统，当然是不可缺少的。然而，一个无法借助 ERP 系统解决的信息处理的问题，却长期困扰了公司上下多年了。这个问题就是：“如何高效地管理品种数量众多的产品出厂试验的过程和结果数据？”。公司多次尝试建设一个专门的试验工作管理的软件系统来解决这个问题，但始终未能得到基本满意的结果。经过分析，这个软件系统建设不理想的主要原因是：该系统的需求是一个随时可能有过程性影响的变化的需求。按常规软件编程开发的软件系统，无法满足随时出现的系统灵活多样的却又彼此相似的功能需求。具体地说，就是公司有上百条产品线可接受客户最低到一台数量的个性化定制的订单，产生每年百万计数量的产品生产任务，会需要数万计的产品试验方案和报告及铭牌的输出要求要得到实现。如果每种试验方案和试验报告的自动填报工作都通过编写相应的软件代码来实现。那么系统开发的规模将是十分庞大的，系统的开发成本无法和应用效益形成匹配。并且，随着系统应用的同时，系统开发的工作也将始终伴随，因为，用户总会发现有新的订单需要新的试验方案，要产生新的报告输出的要求。更隐秘的问题是：尽管每种新的试验方案看起来是在某种现有方案基础上的“局部修改”的结果。但由于这种局部修改，并不是一个在某“工作环节”上的局部修改，而是在某“产品特性”上的局部修改，这意味着：不可能用某种局部可替换的工作方法来适应这种修改，而要在整个工作流程上按这个产品特性的修改进行相互关联的试验过程、规则和输出结果的联动变化。常识告诉我们：计算机信息处理无非就是“用处理机处理数据”，所以，对于变化着的需求，如果能用变化着的数据来满足，就不必让处理机具有可变性。比如：如果把运行软件系统得到试验结果的整个过程，比作是在计算机里写一篇文章，那么，就只需要一个类似 Word 的软件系统，能让用户根据表达的需要，可对文章的任何部分进行修改——因为只是修改被处理的数据，所以大部分情况下，不必修改 Word 软件这个“处理机”来适应不同文章的需求。不幸的是：由于试验工作本身是有逻辑过程性的，并不能简单地抽象为象文字处理一样的某种单纯的数据处理的工作，要平滑地适应这种变化的需求，不可选择地要让“处理机”自身具有某种可变性。事实上，为满足类似这样的逻辑过程可变化的软件需求，全世界的软件科学家和工程师们都在绞尽脑汁。他们把这个难关叫做随需应变，并发展了现代的软件架构技术，其中就包括通过改变处理机自身来适应这种变化着的软件需求的架构技术。可演进特性可演进的特性是指：软件系统中的程序对象的特性可以随着应用需求的变化而得到发展的特性。也就是说，软件中的程序对象的属性和功能可以随着需求的变化而动态地进行增加或减少，对象之间的关系也可以根据需要执行的功能所需，而动态地得到建立和解除。为什么传统的面向对象编程方法实现的软件系统是“不可演进”的？传统的面向对象编程方法，实际是面向“类”的编程方法。是经过面向对象的分析和设计，从现实对象的行为中，归纳总结出对象的抽象类型及其抽象的交互行为关系，程序按抽象类型及其交互关系进行编写，在实际运行时再按类型及其关系结合实际处理的数据进行对象的“实例化”。被实例化的对象只能按照程序所编制的类及其交互关系所描述的那样，做出构建和交互的行为，这是一种“ 在设计时就规定好，运行时只按设计的运转处理 ”的开发应用分离的模式。传统的面相对象编程方法实现的软件系统自身结构和功能的构建是在设计时就预先计划好的，实际运行时，只是按照预先设计好的模式进行运行，处理相应的数据而已。而不能随着要处理的数据的不同，需要的处理功能的不同，来随之在线实时变更系统的结构和功能，来适应处理需求的变化。因此，传统的面相对象编程方法所实现的软件系统是“不可演进的”。可演进和智能演进的区别系统演进的特性是指被实现的软件系统，在运行时还具备修改自身对象特性的能力。而这种能力是如何在运行时得到产生和执行的，则正是可演进和智能演进的区别所在。可演进的特性是指系统修改自身对象特性的能力，是通过允许人工交互操作的方式，手工或半自动来建立并得到执行的。而智能演进，则不需要人工的干预，系统自身就能适应外部需求自动地启用这样的自我构建和执行操作的行为。可演进性的核心价值在于突破了系统演进中的“设计时”和“运行时”的鸿沟。也可以说，是在设计时就设计了系统将来在运行时可演进修改对象结构和功能的机制，使得满足应用需求变化的对象功能升级，可在运行时通过尽量少的交互操作就能实现，使系统平滑地，实时地得到自我的完善。当然，人工智能的最终目标是实现系统的智能演进，在达到这个最终目标之前，可演进或许正是在不可演进的现实基础上所能进行的一个积极的尝试。所以，可演进的技术，不是人工智能技术。可演进和热可插拔的区别为了不中断一个运行中软件系统而给软件系统的功能进行升级，现有的方案是：设计了一个大致稳定的系统框架，而在这个框架上的某些具体应用功能实现上，定义了一些抽象的功能接口，这些功能接口有初始的程序对象的实现，系统框架负责按抽象的功能接口维持系统的整体运行，而不必关心实际实现这个功能接口的程序对象是谁。如果需要在运行时增强或改变程序对象的功能，而不需变更功能接口规范时，就可以重新按新的需求重新设计和实现出新的程序对象，在系统不必停机的情况下，可以通过配置运行参数的方式，替换原来实际执行软件功能的对象，也就是实现了程序对象的“热可插拔性”。从本质上来讲，“热可插拔性”是一种可称为“可在运行时同步设计”的方案。在逻辑上讲，系统的设计时和运行时，依然是被割裂开的，只是从串行改成了并行。这种割裂，意味着，系统的自身的构建性操作和对外信息处理的操作并没有融合在系统自身的结构上。因而，对系统的升级改进，只能是按预设范围和扩展点进行，而不能进行连续和实时的演化。软件对象的“热可插拔性”设计，是现今广泛采用的“让处理机具有可变性”的架构技术。这种技术，只适应能通过“局部过程的功能异化”来满足的需求变化。无法适应因待处理的“业务产品特性”的局部变化，导致整个软件系统系统逻辑过程必须做出适应性调整变化的需求。作者长年致力于开发软件。根据自己 20 多年的软件开发实践和对相关理论、技术的学习研究，在自主开发的一个应用软件开发和运行一体化的软件平台中，设计并实现了一种基于可演进的对象关系的软件模型。该模型以传统面向对象软件工程方法为基础，并在技术层面突破了传统面向对象编程的开发技术的限制，实现了“程序对象及其关系可在运行时融合领域模型可变”的技术。为实现可演进的软件系统创出了一条新路。待续 ...; 个人分类: 基因软件开放实验室|2041 次阅读|7 个评论

面向资源的应用软件开发将迈向信息化的本质: Babituo 2014-7-15 14:31; 最近重新启动了十多年前中断了的“面向资源应用软件开发方法”的研究。对面向资源应用软件的开发方法的本质进行了更加深入的思考。我曾概要的总结了的对信息化的本质的一个归纳的思路：如果说传统的产业是资源密集型产业的话，那么，曾经兴起的数字化浪潮，则试图将传统产业的资源密集型特征转化为“数字密集型”的特征。即，将传统的物化的自然资源和生产要素资源进行数字化描述的转换，从而在信息层面让传统的资源彻底摆脱对物化的外壳的依赖，让传统资源的信息化替身能在极低的能量消耗下，得到更为广泛，更为快捷的传播。显然，这得益并促进了互联网产业的飞速发展，而造就互联网产业的飞速发展的本质原因，无非是互联网显著降低了实现各个产业环节之间的信息对称目标的成本，这也正是互联网对整个产业结构的深远的价值影响所在。然而，数字化浪潮在带来数字化的虚拟资源的同时，也带来了“大数据”对虚拟资源信息本质的“淹没效应”：对传统资源数字化的结果是适应计算机信息化的前提，离现实资源的“信息化原态”确实更近，但又不是完整意义的现实资源的“信息化原态”。就好比纯水撒在固态的表面容易被分辨，但注入到海水中就无法分辨而被淹没了一样。信息化的虚拟资源相对物化的现实资源来说，差异显著，而相对日渐普及的更接近自身的数字化虚拟资源来说，无疑大大增加了分辨的难度。所谓“信息化原态”是相对现实资源的“物化原态”而言，不仅反映现实资源的表象特征（这正是数字化虚拟资源的功能），而且反映现实资源的内在逻辑特征的描述形态。而只有具备这样的“信息化原态”的表达能力，才能实现“对虚拟资源的操作”与“对现实资源操作”的同态意义。这正是实现虚拟世界和现实世界“并行运转，相互操控”的一大基础。所以，如果要问：什么是面向资源应用软件开发中的“资源”，那么，反映现实资源的“信息化原态”的虚拟资源，便是最准确的答案。于是，对面向资源的应用软件方法的手段和目标，就可以做如下的表述：直接面向现实世界资源的表象与逻辑特征，并在计算机中直接构建完整反映这些特征的信息化虚拟资源，从而实现可并行互通的现实世界和虚拟世界的资源操作，并借助这种可并行互通的虚拟世界的资源操作，最大限度地替代现实世界的可替代的资源操作，从而极大提高现实世界资源运转效率和能源效益。面向资源的应用软件开发方法，不仅仅是开发工具，手段和开发方式的变革，而且是对计算机应用软件的应用价值的终极目标的认知的变革。面向资源的应用软件开发将迈向信息化的本质。邱嘉文 2014年7月15日于珠海诚开智能; 个人分类: 信息探索|3217 次阅读|1 个评论

更多...

帐号		自动登录	找回密码
密码			注册

关闭 安全验证

标签: 面向资源

相关帖子

相关日志

关闭安全验证