三年前在思考动态程序结构时，想到了三旋程序架构：

三旋动态架构的程序就是动态的对象架构的程序

http://blog.sciencenet.cn/blog-33982-427240.html

那是对一种对实现三类功能的程序进行混合的灵感。

今天再思考，发现面向资源的开发方法中，已经把三旋的组织方式，从程序结构层次上升到了开发方法论的架构的层次，实现了三旋开发的架构模式。

对三旋架构模式表述如下：

问题:

当遇到应用软件所处理的业务对象的特征进行了局部的调整时，需要对软件的多个部件的功能及其组织的方式进行相应的适应性的调整，才能满足应用的要求。

在当前主流的“需求-分析-设计-开发-部署-运行”的软件开发过程模式下，完成“对软件的多个部件的功能及其组织的方式进行相应的适应性的调整”的过程，需要在软件开发工具环境和软件运行两个相对独立的环境下，由不同专业分工的人员异步工作才能完成。这使得：尽管有时需要调整的功能并不多，但可能导致要对已经开发出来的运行程序频繁进行结构性的调整而使得实际需要的开发工作量比预期的要大得多，在开发成本和效益关系上，造成不可调和的矛盾，这一矛盾往往表现为甲乙双方对软件需求变更认识差异的矛盾。

对问题的分析：

对上述问题的基本事实的分析表达如下：

1.应用软件用于对某类业务对象的生产过程进行信息化辅助管理。

2.应用软件的开发需要专业的软件开发人员在专业的软件开发工具环境下进行开发。

3.软件需求需要从业务人员的头脑中转移到软件开发人员的头脑中，这一过程需要跨界，比较艰难。

4.应用软件开发人员按照确定的软件需求进行软件开发，交付运行程序。

5.软件用户按交付的运行程序操作，辅助进行某类业务对象的生产。

造成问题的关键原因是：

1.要将业务过程知识从业务人员的头脑中，部分转移到电脑中。

2.业务人员对电脑的可用资源陌生，无法独自完成这些转移。

3.专业软件开发人员熟悉电脑可用资源，但对软件需求的变化难以把握，能按确定的软件需求完成转移，已属不易。

所以，如果要用一句话来概括问题的实质原因，这句话可以是：电脑资源和业务资源的异质化太严重。

对问题的解决方案  

从计算机编程语言到软件工程的方法论，几乎全部都是解决这个问题的方案。

从计算机语言来说：从纸带穿孔编程语言到汇编语言再到高级编程语言，目前已经发展到可视化编程语言阶段。编程语言的发展，完成了从最基本的硬件资源的封装到软件处理逻辑单元的封装，再到专业化的业务知识处理的基本功能的封装，一直都在沿着“让人脑知识转移到电脑中的过程实施者越来越脱离对电脑基础资源必须掌握的依赖”的方向前进，换句话说，就是越来越让电脑看上去像其他可供人类操控的资源一样，当然，极致程度就是像人类自身了，即实现所谓“人性化的人机接口”。 值得注意的是：这里所说的“电脑”，已经不仅仅是电脑的硬件资源，而包括电脑的各类基础软件的资源。在让些资源看起来像“人力资源”之前，让它们看起来像工业品资源，都已经是极其困难的了。

我以前编程时经常这样幻想：这个功能曾经编写过啊，或者，在某某程序上别人已经编写过的啊，要是能够象拆自行车零件一样，从这辆“拆”下来，装到哪辆上去，多好啊。当然，剪贴拷贝源代码，编写可重用的对象类，组件，构件，看上去都是在把这样的幻想变为事实。但这离真实用户的“幻想”（也许这些用户并不知道目前这依然是幻想）的实现还差得太远。他们的幻想是：把这些独立的小程序给我连接来，就构成了我要的系统了啊。他们并不知道，这每个小应用程序，都是象市场上的每种工业品一样，经过“开模”的过程，然后才利用模具铸造、注造或冲压出来的。 只不过这个“开模”的过程，就是软件开发人员分析，设计和编码的过程。要想随意拼装，得在“开模”的时候，就要设计好配合关系才行的哦。当然，工业品生产是用标准件设计库来解决拼装生产的问题的。 即便如此，我们想换个自行车上的某个螺丝，大部分人可能还是要找专业人士-自行车修理师傅。现在，用户幻想的是：能否把这几辆摩托连接起来，就成了他可用的动车组？

从软件工程方法论而言，其进化的速度还远远没有跟上编程语言的进化速度。就好比盖房子，以前是盖土房，用夯土的方法建墙的，后来改砌红砖建墙，再后来改浇注混凝土板柱梁后再砌空心灰砖建墙，到现在，有很多墙都已经用钢架搭起架子，然后拧螺丝固定玻璃板或预制墙板来建墙了，但盖楼的方法论可能还停留在砌红砖的年代。这，就是软件工程的现状。因为，大部分的软件建筑师们都只懂红砖的架构技术。

但现实的迫切的对软件架构的需求是什么呢？

是变形金刚。

你想要上天，它就变成飞行器，你想要下海，它就变成航行器，你想在陆地奔驰，它就能变成SUV。

把这个需求转换到盖房子的行业至少就是：今天是工厂的房子，明天是酒店，后天是教室，再后天是商场，电影院，住宅，写字楼，体育场 。实际，这也不是神话，现实中确实有重新装修就改头换面的。但至少也需要请工程队来重新装修，甚至也需要局部改造，有时，还不如拆了重建。但软件行业的需求是：今天提出的新需求，工程队最好明天就完工，后天就用上，否则，大后天需求又必须改变了。不是需求变更不合理，是应用规模和深度已经发展到必须满足这样的需求的时代了。

如何来解决这个问题？

我们已经知道传统的软件工程方法论和计算机编程语言，在新的需要软架构的形势下，是无法满足应用需求的了。这些传统的方法，属于一个可称为“模具时代”的方法，这是初级的工业化时代的共同特征。现在，工业化产品领域已经开启了一个新的时代，就是“3D打印时代”。这是一个去模具化的精确制造时代。3D打印机的意义，不仅在于摆脱了模具的束缚，可用来大规模打印供消费个性化产品，还可用于打印更高级的供制造产品的个性化的新工具，人类可能将迎来工具爆炸的时代。当一个工具可用于方便地制造更高级的工具时，人类的工具系统将进入一个正反馈增长的时代。

软件产业，是否有机会进入自己的“3D打印时代”呢？这启发我们，只要研究开发出“生产软件产品的3D打印机”就可以了。所以，出路一定在新时代背景所呼唤的新的工具上。必须要在新的时代背景下提出并实现新架构需求下的软件开发工具。

在“3D打印”模式的启发下，我们可以，设想新的软件开发将在一个类似的，“可自繁衍”的工具环境下开发和应用。一个软件工具系统，不仅可用来生产供使用的软件产品，还可用来生产可强化自身功能的新软件工具组件。这样的软件工具系统不仅统一了软件产品的生产和软件工具制造的过程，还将软件开发和应用的环境统一到了同一个环境下来了。这并不意味着软件开发者和软件使用者的分工必须要被消灭，反而意味着软件开发者和使用者从此可在同一个工作平台上并行地工作，更好地协同面对需求变化的挑战。

在这样的集软件开发和应用于一体的新的软件系统，必然需要新的软件架构的技术。运行维护这样的软件系统，在其目标维度上至少从软件应用维，扩展了软件开发维度，也就是说，运行这样的软件系统，至少同时会在“构建和完善软件自身的应用功能”和“使用软件系统的应用功能进行业务工作”的两个方向上取得成效。两个方向的成效不再是直线串行的，而是平面并行的。可以说，应用软件的开发应用的空间，可从此由直线（折线）空间拓展到平面空间。软件开发和使用人员，从此由“直线虫”，升级为“平面虫”了。

软件的运行，对业务信息的输入和输出，不断地进行变换处理，是软件系统和外界之间不断进行信息的“新陈代谢”的循环过程。这在三旋理论中被抽象化为一种物体的自旋运动，就是圆环体绕圆环内轴的自旋运动，我在三旋自组织理论中，将这种运动抽象地归结为系统新陈代谢功能的成因。而软件系统的自我完善和构建的功能，抽象归结到以环体的面旋运动为成因。（具体见我的三旋自组织理论博文）。所以，新的软件软件开发和应用的过程，至少同时具备了面旋和线旋的特征。

在三旋自组织原理中，还提到了另一种自组织的基本功能，就是抽象归结为体旋运动所产生的搜索和定位的功能。对照软件开发和应用的平台系统，其搜索和定位的功能，可以理解为是软件平台对不同的行业和专业方向的应用软件的开发和应用的跨度和适应性。能应用于某专业方向，则意味着工具平台可以通过“体旋”运动搜索和定位到这个专业领域方向，这取决于平台接纳专业领域知识转移能力的宽度，决定的是工具平台的通用性。 面向资源的应用软件平台，不应该是某些领域的专用的平台，而应该能覆盖各行各业的各类软件的开发和应用。

小结一下：面向资源的应用软件平台系统，应集如下三大功能体系于一体：

1.业务应用功能的开发和应用，这是平台系统的线旋能力；

2.平台系统自开发的自繁衍能力，这是平台系统的面旋能力；

3.对各行各业的各类软件的开发和应用支持能力，这是平台系统的体旋能力。

开发和应用一个面向资源的软件平台，必须着眼于这三项整体的特性。一旦开发出这样的平台系统，就能向随需应变的软件系统跨出一大步。

为了检验这种三旋架构的观点是否有效，接下来可用这种观点考察一些现行的软件平台。可从考察结果来了解三旋架构观点与被考察平台的应用特点的适应性，来评估三旋架构的意义。也可以更深入地探求如下问题的答案：为什么现有的工具平台系统不能集三大功能体系于一体，为什么必须是“面向资源”？