中国科学：信息科学2020年第50卷第11期：1595-1611 《中国科学》杂志社 SCIENTIA SINICA Informationis SCIENCE CHINA PRESS 可成长软件专题·评述 CrossMark 可成长软件理论方法和实现技术：从范型到跨越 许畅12*，秦逸12，余萍12，曹春12，吕建12 1.南京大学计算机软件新技术因家重点实验室，南京210023 2.南京大学计算机科学与技术系，南京210023 *通信作者.E-mail:changxu@nju.edu.cn 收稿日期：2020-04-01；修回日期：2020-07-07：接受日期：2020-09-30：网络出版日期：2020-11-10 因家重点研发计划（批准号：2017YFB1001801)和国家自然科学基金（批准号：61932021,61902173）资助项目 摘要在云计算和大数据的技术背景下，“人-机-物”三元融合的应用模式正不断加速社会的信息 化进程，并对软件系统的自适应和持续演化能力提出了新的需求.本文探索了面临软硬件环境及外部 资源不断变迁挑战下的可成长网构软件理论方法和实现技术，从软件可成长性问题的由来，至可成长 性概念的内涵和可成长软件的范型机理，在开放环境感知与自适应、无缝演化和过程演进，以及演化 质量评估方法和保障机制3个方面系统分析了可成长软件的技术挑战并介绍了当前的技术进展，以支 撑软件系统在不断成长视角下的长期生存. 关键词可成长软件，范型机理，自主适应，持续演化 1引言 云计算，大数据技术和“人-机-物”三元融合的应用模式正不断加速社会的信息化进程，在此 背景下，软件作为信息社会的基础设施，常面临着其软硬件环境及外部资源不断变迁的挑战.对此，以 基础软件方法学及相应关键技术的系统创新，增强开放网络环境下软件系统的自适应和持续演化能 力，使其能够长期生存并不断成长，成为了当前国际学术研究的新焦点.本文以科技部国家重点研发 计划“云计算和大数据”专项“可持续演化的智能化软件理论，方法和技术”的工作为基础，介绍我们 在以智能化为手段，以可成长为本质的可持续演化软件理论、方法和技术方面的研究进展，以抛砖引 玉，吸引专家见解和开发者实践. 本文组织如下，首先，我们介绍软件的可成长性，分析可成长性问题的由来，以及可成长性概念的 内涵和范畴：其次，我们探索以网构软件的思想来构建可成长软件的理论方法，分析实现可成长网构 软件的可能途径、其范型机理，以及技术挑战：再次，我们讨论支撑软件可成长性的关键技术，包括赋 能关键技术和外围关键支撑，其涉及软件开放环境感知与自适应、无缝演化和过程演进，以及演化质 引用格式：许畅，秦逸，余萍，等.可成长软件理论方法和实现技术：从范型到跨越.中国科学：信息科学，2020,50：1595-1611，doi 10.1360/SSL-2020-0079 Xu C,Qin Y,Yu P,et al.Theories and techniques for growing software:paradigm and beyond (in Chinese).Sci Sin Inform,2020,50:1595-1611,doi:10.1360/SsL-2020-0079 ©2020《中国科学》杂志社 www.scichina.com infocn.scichina.com https://engine.scichina.com/doi/10.1360/SSI-2020-0079
SCIENTIA SINICA Informationis 中国科学 : 信息科学 2020 年 第 50 卷 第 11 期 : 1595–1611 ⃝c 2020《中国科学》杂志社 www.scichina.com infocn.scichina.com 可成长软件专题 . 评述 可成长软件理论方法和实现技术: 从范型到跨越 许畅1,2* , 秦逸1,2 , 余萍1,2 , 曹春1,2 , 吕建1,2 1. 南京大学计算机软件新技术国家重点实验室, 南京 210023 2. 南京大学计算机科学与技术系, 南京 210023 * 通信作者. E-mail: changxu@nju.edu.cn 收稿日期: 2020–04–01 ; 修回日期: 2020–07–07 ; 接受日期: 2020–09–30; 网络出版日期: 2020–11–10 国家重点研发计划 (批准号: 2017YFB1001801) 和国家自然科学基金 (批准号: 61932021, 61902173) 资助项目 摘要 在云计算和大数据的技术背景下, “人 – 机 – 物” 三元融合的应用模式正不断加速社会的信息 化进程, 并对软件系统的自适应和持续演化能力提出了新的需求. 本文探索了面临软硬件环境及外部 资源不断变迁挑战下的可成长网构软件理论方法和实现技术, 从软件可成长性问题的由来, 至可成长 性概念的内涵和可成长软件的范型机理, 在开放环境感知与自适应、无缝演化和过程演进, 以及演化 质量评估方法和保障机制 3 个方面系统分析了可成长软件的技术挑战并介绍了当前的技术进展, 以支 撑软件系统在不断成长视角下的长期生存. 关键词 可成长软件, 范型机理, 自主适应, 持续演化 1 引言 云计算, 大数据技术和 “人 – 机 – 物” 三元融合的应用模式正不断加速社会的信息化进程, 在此 背景下, 软件作为信息社会的基础设施, 常面临着其软硬件环境及外部资源不断变迁的挑战. 对此, 以 基础软件方法学及相应关键技术的系统创新, 增强开放网络环境下软件系统的自适应和持续演化能 力, 使其能够长期生存并不断成长, 成为了当前国际学术研究的新焦点. 本文以科技部国家重点研发 计划 “云计算和大数据” 专项 “可持续演化的智能化软件理论, 方法和技术” 的工作为基础, 介绍我们 在以智能化为手段, 以可成长为本质的可持续演化软件理论、方法和技术方面的研究进展, 以抛砖引 玉, 吸引专家见解和开发者实践. 本文组织如下, 首先, 我们介绍软件的可成长性, 分析可成长性问题的由来, 以及可成长性概念的 内涵和范畴; 其次, 我们探索以网构软件的思想来构建可成长软件的理论方法, 分析实现可成长网构 软件的可能途径、其范型机理, 以及技术挑战; 再次, 我们讨论支撑软件可成长性的关键技术, 包括赋 能关键技术和外围关键支撑, 其涉及软件开放环境感知与自适应、无缝演化和过程演进, 以及演化质 引用格式: 许畅, 秦逸, 余萍, 等. 可成长软件理论方法和实现技术: 从范型到跨越. 中国科学: 信息科学, 2020, 50: 1595–1611, doi: 10.1360/SSI-2020-0079 Xu C, Qin Y, Yu P, et al. Theories and techniques for growing software: paradigm and beyond (in Chinese). Sci Sin Inform, 2020, 50: 1595–1611, doi: 10.1360/SSI-2020-0079 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
许畅等：可成长软件理论方法和实现技术：从范型到跨越 量评估方法和保障机制等重要方面：最后，我们介绍可成长软件理论方法和技术的集成应用，并展望 未来和总结全文 23 软件的可成长性 本节介绍软件的可成长性，分析可成长性问题的由来，以及可成长性概念的内涵和范畴 2.1软件可成长性问题的由来 从以机械化为代表的第一次工业革命，到以电气化为代表的第二次工业革命，一直到近代以自动 化为代表的第三次工业革命，以及当前和未来以智能化为代表的第四次工业革命.软件已逐步成为支 撑我们现代化信息社会的基础设施.其中一个重要原因就是，从第三次工业革命开始出现了电子计算 机，人类的计算能力和工作效率由此大幅提升，计算机软件也因而进入了蓬勃发展的阶段.对此，C++ 语言发明人Bjarne Stroustrup甚至高度评价：“人类文明运行在软件之上”.近年来，云计算、大数据 技术和“人-机-物”三元融合的应用模式正不断加速现代社会的信息化进程，与此相应的，软件也 变得与人类生活越来越息息相关，越来越重要。 但随之而来的，是软件的构建和维护任务日益复杂，不断挑战软件开发者管理和技术的能力界 限.比如说，根据波音和空客的实证数据，习，其软件代码可达三千万行，并且随着其业务复杂度每增 长25%，软件复杂度可相应增长100%.即使软件开发者能顶住巨大压力从事如此复杂的编码工作，也 不得不耗损自身健康作为代价.而另一方面，随着社会的信息化进程加速发展，当前许多软件基础设 施面临着环境、资源和需求的不断变迁，急需重新构建或繁重维护，这进一步加剧了问题的严重性 在这种情况下，软件的长期生存或单纯是生存都变得非常困难.据悉，有苦撑12年，具有600多 万行代码和五万多个类的烂尾开发项目，到后期软件结构已变得异常复杂，即使软件开发者付出极 大努力也无法充分理解，最终不得不在多次追加开发资金之后仍然垮掉).而因为代码难以理解和注 释不规范问题，软件开发者之间也曾发生过矛盾，甚至危及生命的事件，使得软件的构建和维护难以 持续).即使是国际著名Ora©le公司的成熟数据库产品，开发人员也对其生存和维护问题怨声载道： “·你做不到在不破坏成千上万个现有测试的情况下更改产品中的单一行代码·代码中充斥 着各种各样的垃圾内容·顺利的话，会有大约100个失败的测试，倒霉的话，会有大约1000个失 败的测试·再添加几个标志，试图解决问题.”).对这样的问题，美国国防部高级研究计划 局(Defense Advanced Research Projects Agency,DARPA)己经开始规划，期望设计和开发一套资源自 适应软件系统(BRASS),它不仅能够经受一个多世纪的考验，而且还能自行对所在生态系统中的变化 做出安全、动态式的响应，从而彻底解决软件的长期生存难题， 我们认为，软件构建和维护任务的复杂性，实质上反映了软件的可成长性问题.软件难以继续构建 和维护，本质上暗示了软件自身的可成长性比较差甚至缺失.对此，科研人员和软件开发者近几十年 来一直在与软件的可成长性问题进行抗争.并且已经付出大量管理和技术上的努力 比如说，在管理方面，教科书级经典著作《人月神话》B,4很早就提出了软件危机的两点具体表 现.一是软件开发活动不具有可扩展性，难以驾驭大规模系统，二是团队规模和协作效率（或沟通成 本)之间具有两难问题，换言之，软件的复杂性无法简单通过增加人（即人力成本）和月（即时间成本） 1)https://zhuanlan.zhihu.com/p/38973085/. 2)http://finance.sina.com.cn/stock/usstock/c/2018-09-23/doc-ifxeuwwr7514854.shtml. 3)https://www.oschina.net/news/101928/about-oracle-database-code. 4)https://tech.huangiu.com/article/9CaKrnJJO38. 1596 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
许畅等: 可成长软件理论方法和实现技术: 从范型到跨越 量评估方法和保障机制等重要方面; 最后, 我们介绍可成长软件理论方法和技术的集成应用, 并展望 未来和总结全文. 2 软件的可成长性 本节介绍软件的可成长性, 分析可成长性问题的由来, 以及可成长性概念的内涵和范畴. 2.1 软件可成长性问题的由来 从以机械化为代表的第一次工业革命, 到以电气化为代表的第二次工业革命, 一直到近代以自动 化为代表的第三次工业革命, 以及当前和未来以智能化为代表的第四次工业革命, 软件已逐步成为支 撑我们现代化信息社会的基础设施. 其中一个重要原因就是, 从第三次工业革命开始出现了电子计算 机, 人类的计算能力和工作效率由此大幅提升, 计算机软件也因而进入了蓬勃发展的阶段. 对此, C++ 语言发明人 Bjarne Stroustrup 甚至高度评价: “人类文明运行在软件之上”. 近年来, 云计算、大数据 技术和 “人 – 机 – 物” 三元融合的应用模式正不断加速现代社会的信息化进程, 与此相应的, 软件也 变得与人类生活越来越息息相关, 越来越重要. 但随之而来的, 是软件的构建和维护任务日益复杂, 不断挑战软件开发者管理和技术的能力界 限. 比如说, 根据波音和空客的实证数据 [1, 2] , 其软件代码可达三千万行, 并且随着其业务复杂度每增 长 25%, 软件复杂度可相应增长 100%. 即使软件开发者能顶住巨大压力从事如此复杂的编码工作, 也 不得不耗损自身健康作为代价. 而另一方面, 随着社会的信息化进程加速发展, 当前许多软件基础设 施面临着环境、资源和需求的不断变迁, 急需重新构建或繁重维护, 这进一步加剧了问题的严重性. 在这种情况下, 软件的长期生存或单纯是生存都变得非常困难. 据悉, 有苦撑 12 年, 具有 600 多 万行代码和五万多个类的烂尾开发项目, 到后期软件结构已变得异常复杂, 即使软件开发者付出极 大努力也无法充分理解, 最终不得不在多次追加开发资金之后仍然垮掉1) . 而因为代码难以理解和注 释不规范问题, 软件开发者之间也曾发生过矛盾, 甚至危及生命的事件, 使得软件的构建和维护难以 持续2) . 即使是国际著名 Oracle 公司的成熟数据库产品, 开发人员也对其生存和维护问题怨声载道: “· · · · · · 你做不到在不破坏成千上万个现有测试的情况下更改产品中的单一行代码 · · · · · · 代码中充斥 着各种各样的垃圾内容 · · · · · · 顺利的话, 会有大约 100 个失败的测试, 倒霉的话, 会有大约 1000 个失 败的测试 · · · · · · 再添加几个标志, 试图解决问题 · · · · · · ” 3) . 对这样的问题, 美国国防部高级研究计划 局 (Defense Advanced Research Projects Agency, DARPA) 已经开始规划, 期望设计和开发一套资源自 适应软件系统 (BRASS), 它不仅能够经受一个多世纪的考验, 而且还能自行对所在生态系统中的变化 做出安全、动态式的响应4) , 从而彻底解决软件的长期生存难题. 我们认为, 软件构建和维护任务的复杂性, 实质上反映了软件的可成长性问题. 软件难以继续构建 和维护, 本质上暗示了软件自身的可成长性比较差甚至缺失. 对此, 科研人员和软件开发者近几十年 来一直在与软件的可成长性问题进行抗争, 并且已经付出大量管理和技术上的努力. 比如说, 在管理方面, 教科书级经典著作《人月神话》[3, 4] 很早就提出了软件危机的两点具体表 现. 一是软件开发活动不具有可扩展性, 难以驾驭大规模系统, 二是团队规模和协作效率 (或沟通成 本) 之间具有两难问题, 换言之, 软件的复杂性无法简单通过增加人 (即人力成本) 和月 (即时间成本) 1) https://zhuanlan.zhihu.com/p/38973085/. 2) http://finance.sina.com.cn/stock/usstock/c/2018-09-23/doc-ifxeuwwr7514854.shtml. 3) https://www.oschina.net/news/101928/about-oracle-database-code. 4) https://tech.huanqiu.com/article/9CaKrnJJO38. 1596 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
中国科学：信息科学第50卷第11期 来解决.此外，为缓解软件危机，极限编程XP)提出了系列措施来提高软件开发的效率和增进开发 人员对彼此代码的理解，如使用用户故事把客户加入到需求分析的圈子当中，或使用结对编程实现增 进代码理解的编程分享等. 又比如说，在技术方面，DevOps同)的提出倡导了软件开发模型从经典的瀑布模型，到后来的敏捷 和精益开发，以至更具效率的持续集成、持续交付、持续部署和持续运维.此外，设计模式[可强调了 复用已有的成功软件开发设计，以提升开发效率和降低维护难度，而代码重构阁则指引了如何在不破 坏原有功能的前提下，为己有软件引入设计模式.针对设计模式和代码重构的引入，科研人员也深入 分析其实际效用，如香港科技大学张成志教授团队通过设计基于实际软件开发者的对比实验，研究了 雇佣具有更多工作经验的开发者和花费代价通过代码重构为已有软件引入设计模式这两种方法哪个 对软件的持续维护工作更具有效用回，以及软件开发者是否真能有效利用预先在软件中部署的设计模 式o等问题 如此看来，类似于软件可成长性问题的关注一直存在，为何现在再次讨论并探索其可能的解决方 案呢？有两点主要的原因，一是现代信息社会对软件的构建和维护要求更加迫切了，如物联网、软件定 义和工业4.0等概念和技术的提出，促使软件系统加速进入“人-机-物”三元融合的应用模式，并 不断承受环境、资源和需求持续变迁的压力；二是现代计算基础设施更加成熟和有能力，如云计算、大 数据和深度学习等技术的提出.使得原先因为计算能力不足而无法大规模开展的工作如今能够有效尝 试.在这样的前提下，我们希望深入理解软件的可成长性问题，并从软件自身的构架角度（内部）和对 开发者支持的角度（外部）共同探讨软件可成长性的解决方案， 需要说明的是，反映出软件可成长性问题的软件构建和维护任务的复杂性，既有来自开发角度的 原因，也有运行态的原因.从开发角度来说，在软件部署前由于初始应用需求日益复杂，而在软件部署 后则因为应用需求持续变迁，所以开发角度这方面主要是指用户的应用需求导致软件构建和维护的复 杂性.另一方面，从运行态来说，软件的环境和资源持续变迁，也可能使应用难以保持原有的服务质量 和内容，而要应对这一问题，也会产生对软件持续维护，甚至再次构建的需求，所以运行态这方面主要 是指环境和资源变迁所导致的软件构建和维护的复杂性.这两方面综合起来，我们说，软件构建和维 护的复杂性即可成长性难题，既涉及开发角度，又有运行态的原因，是环境、资源和需求多个来源的持 续变迁所导致的，这是一个深刻且影响广泛，需要认真对待的问题： 2.2软件可成长性概念的内涵和范畴 基于以上的分析，我们定义软件可成长性概念的内涵为：在其所处软硬件环境，所依赖外部资源， 以及所服务用户目标不断变化的条件下，能通过主动的感知、智能的适应和持续的重构演化，实现长 期生存并不断优化.这一概念内涵，界定了引发软件可成长性目标的由来（即环境、资源和需求的变 化)，也指明了达成软件可成长性的方法（即基于感知、适应和演化的架构）. 同时我们定义软件可成长性概念的范畴为：软件成长不是“开创天地，从无到有”的神话，即软件 无需开发者，可完全自行演化出所需功能，也可完全自行修正自身缺陷（从任意规约自动生成程序的 问题是不可判定的山，更不用提无规约情况下的程序自动生成问题)：相反，软件成长是一个“不断努 力，持续演进”的过程，即软件在自身架构上需要明确考虑其适应和演化问题，支持软件适应变化和版 本演化，使其生存时间更长，并对开发者支持使其更容易实现软件新增功能和修复缺陷。 1597 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
中国科学 : 信息科学 第 50 卷 第 11 期 来解决. 此外, 为缓解软件危机, 极限编程 XP [5] 提出了系列措施来提高软件开发的效率和增进开发 人员对彼此代码的理解, 如使用用户故事把客户加入到需求分析的圈子当中, 或使用结对编程实现增 进代码理解的编程分享等. 又比如说, 在技术方面, DevOps[6] 的提出倡导了软件开发模型从经典的瀑布模型, 到后来的敏捷 和精益开发, 以至更具效率的持续集成、持续交付、持续部署和持续运维. 此外, 设计模式 [7] 强调了 复用已有的成功软件开发设计, 以提升开发效率和降低维护难度, 而代码重构 [8] 则指引了如何在不破 坏原有功能的前提下, 为已有软件引入设计模式. 针对设计模式和代码重构的引入, 科研人员也深入 分析其实际效用, 如香港科技大学张成志教授团队通过设计基于实际软件开发者的对比实验, 研究了 雇佣具有更多工作经验的开发者和花费代价通过代码重构为已有软件引入设计模式这两种方法哪个 对软件的持续维护工作更具有效用[9] , 以及软件开发者是否真能有效利用预先在软件中部署的设计模 式 [10] 等问题. 如此看来, 类似于软件可成长性问题的关注一直存在, 为何现在再次讨论并探索其可能的解决方 案呢? 有两点主要的原因, 一是现代信息社会对软件的构建和维护要求更加迫切了, 如物联网、软件定 义和工业 4.0 等概念和技术的提出, 促使软件系统加速进入 “人 – 机 – 物” 三元融合的应用模式, 并 不断承受环境、资源和需求持续变迁的压力; 二是现代计算基础设施更加成熟和有能力, 如云计算、大 数据和深度学习等技术的提出, 使得原先因为计算能力不足而无法大规模开展的工作如今能够有效尝 试. 在这样的前提下, 我们希望深入理解软件的可成长性问题, 并从软件自身的构架角度 (内部) 和对 开发者支持的角度 (外部) 共同探讨软件可成长性的解决方案. 需要说明的是, 反映出软件可成长性问题的软件构建和维护任务的复杂性, 既有来自开发角度的 原因, 也有运行态的原因. 从开发角度来说, 在软件部署前由于初始应用需求日益复杂, 而在软件部署 后则因为应用需求持续变迁, 所以开发角度这方面主要是指用户的应用需求导致软件构建和维护的复 杂性. 另一方面, 从运行态来说, 软件的环境和资源持续变迁, 也可能使应用难以保持原有的服务质量 和内容, 而要应对这一问题, 也会产生对软件持续维护, 甚至再次构建的需求, 所以运行态这方面主要 是指环境和资源变迁所导致的软件构建和维护的复杂性. 这两方面综合起来, 我们说, 软件构建和维 护的复杂性即可成长性难题, 既涉及开发角度, 又有运行态的原因, 是环境、资源和需求多个来源的持 续变迁所导致的, 这是一个深刻且影响广泛, 需要认真对待的问题. 2.2 软件可成长性概念的内涵和范畴 基于以上的分析, 我们定义软件可成长性概念的内涵为: 在其所处软硬件环境, 所依赖外部资源, 以及所服务用户目标不断变化的条件下, 能通过主动的感知、智能的适应和持续的重构演化, 实现长 期生存并不断优化. 这一概念内涵, 界定了引发软件可成长性目标的由来 (即环境、资源和需求的变 化), 也指明了达成软件可成长性的方法 (即基于感知、适应和演化的架构). 同时我们定义软件可成长性概念的范畴为: 软件成长不是 “开创天地, 从无到有” 的神话, 即软件 无需开发者, 可完全自行演化出所需功能, 也可完全自行修正自身缺陷 (从任意规约自动生成程序的 问题是不可判定的 [11] , 更不用提无规约情况下的程序自动生成问题); 相反, 软件成长是一个 “不断努 力, 持续演进” 的过程, 即软件在自身架构上需要明确考虑其适应和演化问题, 支持软件适应变化和版 本演化, 使其生存时间更长, 并对开发者支持使其更容易实现软件新增功能和修复缺陷. 1597 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
许畅等：可成长软件理论方法和实现技术：从范型到跨越 3 可成长网构软件理论方法初探 本节探索以网构软件的思想来构建可成长软件的理论方法，分析实现可成长网构软件的可能途 径、其范型机理，以及技术挑战 3.1网构软件理论方法发展的新阶段 网构软件(Internetware)理论方法12,13到已经发展了十多年，从一开始其目标就设立为：让软件从 封闭、静态和可控的传统环境走向开放、动态和难控的互联网环境，这也暗示着软件规约从封闭走向 开放、包容环境的不确定性.由此，网构软件的目标在本质上己包括了当下复杂软件系统正不断承受 环境、资源和需求持续变迁的挑战，因而网构软件理论方法从一开始就有相当的预见性.基于这样的 预见.我们期望软件变得更智能.转变自身从“以不变应万变”的消极姿态变成具有“随机应变”的主 动能力，以应对当下环境、资源和需求不断变迁的挑战 网构软件理论方法的研究经历了前后三期科技部973项目，循序渐进，分别探索了软件协同与资 源共享、环境感知与自主适应，以及持续演进与质量保障3个方面.当前，随着软件的可成长性成为 研究的关注点，该系列的研究也开始探索可成长网构软件的理论、方法和技术，进入了新的阶段， 我们考虑可成长网构软件应该具有4个特征，将其总结为4个“明确”，即明确考虑业务逻辑和适 应逻辑、明确建模环境感知和异常处理、明确支持版本更替和无缝演化，以及明确管理感知效率和演 化质量.由此，可成长网构软件将显式关注并明确实现软件的适应变化、版本演化和开发者支持，呼应 我们先前表述的软件可成长性的内涵和范畴】 3.2实现可成长网构软件的可能途径 由以上分析可知，可成长网构软件是一种新的软件范型，它需要在设计机制上考虑适应变化、版 本演化和开发者支持.为了实现具备这样特征的可成长网构软件，我们考虑3条可能的途径，它们分 别需要回答如何为可成长软件构建提供体系支撑，如何使已有软件具备可成长能力，以及如何使上述 过程智能化和自动化这3个问题.实际上，对这3个问题的回答将解读可成长软件应该是什么样的形 态（即“为何形态”），如何让软件从不可成长变成可成长或增强其成长能力（即“如何转变”），以及实 现软件成长的自动化（即“智能支持”）.通俗地说，这3个问题大致等价于：天生的可成长软件长什么 样，如何改造传统软件变成这样，以及怎样自动做到这点 为何形态.要回答如何为可成长软件构建提供体系支撑，我们需要研究可成长软件的范型、机理 和方法学.具体而言，这条途径从架构出发，研究可成长软件之架构模型、运行机理、构造方法和质量 保障，使软件具备自主适应和持续演化能力，实现其感知、适应和学习等智能化手段， 如何转变.要回答如何使已有软件具备可成长能力，我们需要研究软件可成长性的挖掘和增强技 术.具体而言，这条途径从资源出发，研究应用资源使用和资源依赖关系的挖掘和理解，以及增强软件 生存能力的自适应配置调整. 智能支持.要回答如何使上述过程智能化和自动化，我们需要研究数据驱动的软件构造和成长技 术.具体而言，这条途径从数据出发，实现数据驱动的软件构造和演化规律及模式获取，基于软件演化 历史数据，在新的演化任务中实现自动化 以上3条途径在逻辑上是连贯的，同时又是3种实现方式，分别考虑了如何重新设计可成长软件、 如何改造成为可成长软件，以及如何革命性地直接合成新软件.它们分别由南京大学、中国人民解放 军国防科技大学和北京大学团队主要研究，而我们南京大学团队主要关注第1条途径，以阐明可成长 1598 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
许畅等: 可成长软件理论方法和实现技术: 从范型到跨越 3 可成长网构软件理论方法初探 本节探索以网构软件的思想来构建可成长软件的理论方法, 分析实现可成长网构软件的可能途 径、其范型机理, 以及技术挑战. 3.1 网构软件理论方法发展的新阶段 网构软件 (Internetware) 理论方法 [12, 13] 已经发展了十多年, 从一开始其目标就设立为: 让软件从 封闭、静态和可控的传统环境走向开放、动态和难控的互联网环境, 这也暗示着软件规约从封闭走向 开放、包容环境的不确定性. 由此, 网构软件的目标在本质上已包括了当下复杂软件系统正不断承受 环境、资源和需求持续变迁的挑战, 因而网构软件理论方法从一开始就有相当的预见性. 基于这样的 预见, 我们期望软件变得更智能, 转变自身从 “以不变应万变” 的消极姿态变成具有 “随机应变” 的主 动能力, 以应对当下环境、资源和需求不断变迁的挑战. 网构软件理论方法的研究经历了前后三期科技部 973 项目, 循序渐进, 分别探索了软件协同与资 源共享、环境感知与自主适应, 以及持续演进与质量保障 3 个方面. 当前, 随着软件的可成长性成为 研究的关注点, 该系列的研究也开始探索可成长网构软件的理论、方法和技术, 进入了新的阶段. 我们考虑可成长网构软件应该具有 4 个特征, 将其总结为 4 个 “明确”, 即明确考虑业务逻辑和适 应逻辑、明确建模环境感知和异常处理、明确支持版本更替和无缝演化, 以及明确管理感知效率和演 化质量. 由此, 可成长网构软件将显式关注并明确实现软件的适应变化、版本演化和开发者支持, 呼应 我们先前表述的软件可成长性的内涵和范畴. 3.2 实现可成长网构软件的可能途径 由以上分析可知, 可成长网构软件是一种新的软件范型, 它需要在设计机制上考虑适应变化、版 本演化和开发者支持. 为了实现具备这样特征的可成长网构软件, 我们考虑 3 条可能的途径, 它们分 别需要回答如何为可成长软件构建提供体系支撑, 如何使已有软件具备可成长能力, 以及如何使上述 过程智能化和自动化这 3 个问题. 实际上, 对这 3 个问题的回答将解读可成长软件应该是什么样的形 态 (即 “为何形态”), 如何让软件从不可成长变成可成长或增强其成长能力 (即 “如何转变”), 以及实 现软件成长的自动化 (即 “智能支持”). 通俗地说, 这 3 个问题大致等价于: 天生的可成长软件长什么 样, 如何改造传统软件变成这样, 以及怎样自动做到这点. 为何形态. 要回答如何为可成长软件构建提供体系支撑, 我们需要研究可成长软件的范型、机理 和方法学. 具体而言, 这条途径从架构出发, 研究可成长软件之架构模型、运行机理、构造方法和质量 保障, 使软件具备自主适应和持续演化能力, 实现其感知、适应和学习等智能化手段. 如何转变. 要回答如何使已有软件具备可成长能力, 我们需要研究软件可成长性的挖掘和增强技 术. 具体而言, 这条途径从资源出发, 研究应用资源使用和资源依赖关系的挖掘和理解, 以及增强软件 生存能力的自适应配置调整. 智能支持. 要回答如何使上述过程智能化和自动化, 我们需要研究数据驱动的软件构造和成长技 术. 具体而言, 这条途径从数据出发, 实现数据驱动的软件构造和演化规律及模式获取, 基于软件演化 历史数据, 在新的演化任务中实现自动化. 以上 3 条途径在逻辑上是连贯的, 同时又是 3 种实现方式, 分别考虑了如何重新设计可成长软件、 如何改造成为可成长软件, 以及如何革命性地直接合成新软件. 它们分别由南京大学、中国人民解放 军国防科技大学和北京大学团队主要研究, 而我们南京大学团队主要关注第 1 条途径, 以阐明可成长 1598 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
中国科学：信息科学第50卷第11期 价值实现 用户价值模型 可信元模型 可表 世界 规约 的 机器 系统元模型 环境元模型 户 可 协同与演化 组合服务 动态与多变 翻翻的盟一 可 感 软件协同 化的系 閻留盟國一 的 次件实 软件实体 环 描述框架 语义模型 建模方法 软件实体 软件实体 境 图1（网络版彩图）可成长网构软件架构模型图 Figure 1 (Color online)Architectural structure of growing software 软件的范型机理（即它到底如何运作），以及分析其构建思路和技术挑战.接下来我们从可成长网构软 件的角度深入分析这条实现途径，这一途径是可成长网构软件理论方法的核心，也是其他实现途径的 目标。 3.3可成长网构软件的范型机理 如前所述，可成长网构软件是新的软件范型，因此我们从历史出发，回顾和分析近年来软件范型 的演化过程.为可成长网构软件摸清脉络和总结特征 20世纪七八十年代，软件范型研究者多关注于面向软件功能结构的结构化范型，有代表性的、图灵 奖级别的大师包括荷兰的Edsger Wybe Dijkstra,美国的Donald Ervin Knuth,英国的Charles Antony Richard Hoare,以及瑞士的Niklaus Emil Wirth.21世纪初，又涌现出一批关注面向软件问题结构 的对象化范型的大师，包括挪威的Ole-Johan Dahl和Kristen Nygaard,以及美国的Alan Curtis Kay 和Barbara Liskov.我们看到，范型的发展趋势与软件的使命有关，其逐渐从以软件自身为中心转变为 以问题解决为中心.近年来，软件的复杂性进一步提升，“人月神话”的问题仍未突破，随着“人一机一 物”三元融合的应用模式加速发展，其环境、资源和需求不断变迁，软件的持续演化和长期生存逐步成 为新的需求.对此，中国学者也从十多年前，开始研究面向开放协同与适应演化的网构化范型，以支持 在可感知环境反馈下的系统演化.比如国内中国人民解放军国防科技大学王怀民教授团队14,1)特别 关注了局部自治系统融合成为整体软件系统的构建和维护问题，分析了传统“还原论”软件开发方法 的不足，在构建方面提出了以自主化软件单元进行模块更新和连接调整的成长性构造思想，在维护方 面提出了基于统计确定性和逻辑确定性的规律寻找方式，以及基于“监控一分析-决策-调整”的演 化实现机制，成为本文工作的基础之一 顺此历史发展趋势和软件使命变迁，我们总结可成长网构软件的范型机理应具备3项基本特征， 即三元融合的架构模型，自主适应的运行机理，以及持续演化的生命周期. 三元融合的可成长软件的架构模型（图1）.从架构模型上看，可成长软件需要考虑用户（人）、环 境（物）和系统（机）三者的互动，以及其三元融合下应用的抽象.因此，可成长范型在架构模型上包 括3部分：其一是“可表征的用户”，代表应用的价值体现：其二是“可感知的系统”，代表对动态、多 1599 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
中国科学 : 信息科学 第 50 卷 第 11 期 图 1 (网络版彩图) 可成长网构软件架构模型图 Figure 1 (Color online) Architectural structure of growing software 软件的范型机理 (即它到底如何运作), 以及分析其构建思路和技术挑战. 接下来我们从可成长网构软 件的角度深入分析这条实现途径, 这一途径是可成长网构软件理论方法的核心, 也是其他实现途径的 目标. 3.3 可成长网构软件的范型机理 如前所述, 可成长网构软件是新的软件范型, 因此我们从历史出发, 回顾和分析近年来软件范型 的演化过程, 为可成长网构软件摸清脉络和总结特征. 20 世纪七八十年代, 软件范型研究者多关注于面向软件功能结构的结构化范型, 有代表性的、图灵 奖级别的大师包括荷兰的 Edsger Wybe Dijkstra, 美国的 Donald Ervin Knuth, 英国的 Charles Antony Richard Hoare, 以及瑞士的 Niklaus Emil Wirth. 21 世纪初, 又涌现出一批关注面向软件问题结构 的对象化范型的大师, 包括挪威的 Ole-Johan Dahl 和 Kristen Nygaard, 以及美国的 Alan Curtis Kay 和 Barbara Liskov. 我们看到, 范型的发展趋势与软件的使命有关, 其逐渐从以软件自身为中心转变为 以问题解决为中心. 近年来, 软件的复杂性进一步提升, “人月神话” 的问题仍未突破, 随着 “人 – 机 – 物” 三元融合的应用模式加速发展, 其环境、资源和需求不断变迁, 软件的持续演化和长期生存逐步成 为新的需求. 对此, 中国学者也从十多年前, 开始研究面向开放协同与适应演化的网构化范型, 以支持 在可感知环境反馈下的系统演化. 比如国内中国人民解放军国防科技大学王怀民教授团队 [14, 15] 特别 关注了局部自治系统融合成为整体软件系统的构建和维护问题, 分析了传统 “还原论” 软件开发方法 的不足, 在构建方面提出了以自主化软件单元进行模块更新和连接调整的成长性构造思想, 在维护方 面提出了基于统计确定性和逻辑确定性的规律寻找方式, 以及基于 “监控 – 分析 – 决策 – 调整” 的演 化实现机制, 成为本文工作的基础之一. 顺此历史发展趋势和软件使命变迁, 我们总结可成长网构软件的范型机理应具备 3 项基本特征, 即三元融合的架构模型, 自主适应的运行机理, 以及持续演化的生命周期. 三元融合的可成长软件的架构模型 (图 1). 从架构模型上看, 可成长软件需要考虑用户 (人)、环 境 (物) 和系统 (机) 三者的互动, 以及其三元融合下应用的抽象. 因此, 可成长范型在架构模型上包 括 3 部分: 其一是 “可表征的用户”, 代表应用的价值体现; 其二是 “可感知的系统”, 代表对动态、多 1599 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
许畅等：可成长软件理论方法和实现技术：从范型到跨越 适应 决策 可感知 能适应 场景 在线 重构 智能化 有数据 正常 会学习 运行 图2（网络版彩图）可成长网构软件运行机理图 Figure 2 (Color online)Runtime mechanism of growing software 开发者、用户驱动 开发侧面 的持续改进 ◆用户需要 决策 件 重构 软件持续演化 应行为 运行 感知 系统运行 V V31V4 基于环境互动反馈 运行侧面 的持续优化 图3（网络版彩图）可成长网构软件生命周期图 Figure 3 (Color online)Lifecycle of growing software 变环境的建模和理解：其三是“可演化的系统”，代表软件的协同和演化能力.这3部分联合一起，在 用户方面，实现用户应用价值导向的运行时需求模型：在环境方面，实现基于先验元级模型和规约的环 境感知；在系统方面，实现具有在线适应和演化能力的系统.由此，这3部分共同形成“人-机-物 三元融合的可成长软件的架构模型 自主适应的可成长软件的运行机理（图2）.从运行机理上看，可成长软件的运行态表现为一个迭 代式的闭环适应圈，包括“感知环境-适应决策-在线重构-正常运行”这4个基本环节.在感知 方面，可成长软件主动感知环境、资源和用户需求的变化，以知晓“何时演化”；在决策方面，可成长软 件进行应用目标和场景数据导向的适应决策，以确定“演化什么”：在实施方面，可成长软件实现高效、 安全的运行时系统调整和更新，以回答“如何演化”.由此，这3方面共同形成自主适应的可成长软件 的运行机理， 持续演化的可成长软件的生命周期（图3）.从生命周期上看，可成长软件逐步推进一个双维度弹 性的持续演化过程，一方面基于环境的反馈进行自主适应优化（在弹性限度之内），另一方面基于开发 者和使用者的驱动进行过程演进优化（在弹性限度之外）.从生态方面看，可成长软件具备一个开放的 网络软件开发和运行生态环境：从动力方面看，可成长软件做到开发者、使用者反馈和主动感知并举： 从演进方面看，可成长软件无缝、透明地对软件持续改进和优化.由此，这3方面共同形成持续演化 的可成长软件的生命周期. 1600 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
许畅等: 可成长软件理论方法和实现技术: 从范型到跨越 图 2 (网络版彩图) 可成长网构软件运行机理图 Figure 2 (Color online) Runtime mechanism of growing software 图 3 (网络版彩图) 可成长网构软件生命周期图 Figure 3 (Color online) Lifecycle of growing software 变环境的建模和理解; 其三是 “可演化的系统”, 代表软件的协同和演化能力. 这 3 部分联合一起, 在 用户方面, 实现用户应用价值导向的运行时需求模型; 在环境方面, 实现基于先验元级模型和规约的环 境感知; 在系统方面, 实现具有在线适应和演化能力的系统. 由此, 这 3 部分共同形成 “人 – 机 – 物” 三元融合的可成长软件的架构模型. 自主适应的可成长软件的运行机理 (图 2). 从运行机理上看, 可成长软件的运行态表现为一个迭 代式的闭环适应圈, 包括 “感知环境 – 适应决策 – 在线重构 – 正常运行” 这 4 个基本环节. 在感知 方面, 可成长软件主动感知环境、资源和用户需求的变化, 以知晓 “何时演化”; 在决策方面, 可成长软 件进行应用目标和场景数据导向的适应决策, 以确定 “演化什么”; 在实施方面, 可成长软件实现高效、 安全的运行时系统调整和更新, 以回答 “如何演化”. 由此, 这 3 方面共同形成自主适应的可成长软件 的运行机理. 持续演化的可成长软件的生命周期 (图 3). 从生命周期上看, 可成长软件逐步推进一个双维度弹 性的持续演化过程, 一方面基于环境的反馈进行自主适应优化 (在弹性限度之内), 另一方面基于开发 者和使用者的驱动进行过程演进优化 (在弹性限度之外). 从生态方面看, 可成长软件具备一个开放的 网络软件开发和运行生态环境; 从动力方面看, 可成长软件做到开发者、使用者反馈和主动感知并举; 从演进方面看, 可成长软件无缝、透明地对软件持续改进和优化. 由此, 这 3 方面共同形成持续演化 的可成长软件的生命周期. 1600 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
中国科学：信息科学第50卷第11期 需要说明的是，在以上架构模型中，“人”一方面指模型中“可表征的用户”，因为可表征的用户代 表应用的价值体现，所以人作为应用需求的直接提出和要求变迁者，是架构模型中非常重要的一环，因 此建模为需要明确体现其相关应用价值的可表征用户.另一方面，“人”也可以隐式融入到架构模型 的“可感知的系统”和“可演化的系统”中，对于前者，比如人可提供知识、行为识别和隐私数据等，成 为环境上下文的一部分，对于后者，比如人可参与到软件动态更新安全点的选择和转换函数的合成与 审核中，成为演化环节的一部分.这两方面综合起来，“人”对于未来的软件系统，既可以是提出要求 的用户，也可以是解决问题的关键，因此他们是“人-机-物”融合应用整体系统不可或缺的一部分 此外，在以上运行机理和生命周期部分，我们介绍的适应和演化是两种重要的成长方式，前者是指基 于环境的反馈进行自主适应的优化，这是在运行态，主要指利用软件自身已实现的功能和做法应对环 境和资源的变迁，在弹性限度之内可以无需修改软件设计和代码，并依旧保持原先的服务质量和内容： 后者是指基于开发者和使用者的驱动进行过程演进的优化，这与开发态和运行态都有关，开发态包括 支持在弹性限度之外的新功能设计和故障修复等行为，运行态包括支持新版本软件进行动态更替等行 为.这两方面综合起来，我们说，适应和演化都是实现软件成长的重要途径 以上关于架构模型、运行机理和生命周期3个基本特征分别分析了可成长软件的静态结构、运 行机制和演进历程，回答“可成长软件是什么”这一问题，并给出理想的可成长软件的设计蓝图.对照 此蓝图，接下来的重要问题是，如何去构建这样的可成长软件，其中有何技术挑战.下面我们探讨并回 答“可成长软件怎么做”这一问题. 3.4可成长网构软件的构建思路和技术挑战 我们以元级化和定义化的思路来构建可成长软件，这着眼于复杂的环境开放性，其中包括应用场 景的多样性、环境和需求的多变性，以及系统内外开发者和用户的不确定性.我们以元级化提供可成 长能力，因为传统软件属于“目标级”，仅实现针对给定需求和环境的功能，而新增“元级”则使软件可 抽象可成长能力，以刻画感知、适应和演化行为.元级化有个重要的哲学问题，即认清“我是谁”.另一 方面，我们以定义化实现软件的成长，以“软件定义软件”的方式，克服“软件不软”的困难，支持软件 持续的适应和演化，以应对环境和需求变化.定义化也有个重要的哲学问题，即认清“我从哪里来，要 到哪里去” 相反.软件若直接实现应用功能.则可能表现脆弱.无论是应用需求有变迁，或是环境和资源不再 满足其功能实现的前提，都可能造成软件难以保持原先的服务质量和内容，从而不得不回归维护或重 新构建.而“元级化”概念的提出，要求软件在设计过程中明确考虑环境、资源和需求的变迁问题，以 软件定义的方式设计实现软件在运行时的自主适应和开发时的持续演进，也即要抽象软件的成长能力， 另外，以上关于“软件不软”是形象的说法，意思是软件若直接实现应用功能则表现“脆而硬”，容易被 环境、资源和需求的持续变迁所打倒，而“软件能软”的说法则是相反，是期望其能在应对环境、资源 和需求变迁方面游刃有余，表现出一定程度的韧性，这也是可成长软件的目标.根据以上元级化和定 义化的构建思路，我们提出面向自适应和持续演化的可成长软件体系结构（图4）.基于此结构，可成长 软件通过基于先验元模型的环境需求建模和规约感知环境和需求变化.通过软件定义体系结构模型支 持软件系统的自适应和持续演化行为.从图中可以看出，这一结构分“静态构成”和“运行机制”上下 两层，从功能上又分“环境和需求的感知与理解”和“软件自适应与持续演进”左右两部分.从静态构 成上，软件对物理环境进行抽象，获得“先验”的环境和需求（即模型和规约），然后在运行机制上，以 环境处理中间件对物理环境进行感知，提炼出应用上下文.以静态规约和运行时上下文共同驱动可适 应的软件系统，以适应逻辑推动业务逻辑的优化，实现系统的适应和演化行为.这样的规划在整体上体 1601 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
中国科学 : 信息科学 第 50 卷 第 11 期 需要说明的是, 在以上架构模型中, “人” 一方面指模型中 “可表征的用户”, 因为可表征的用户代 表应用的价值体现, 所以人作为应用需求的直接提出和要求变迁者, 是架构模型中非常重要的一环, 因 此建模为需要明确体现其相关应用价值的可表征用户. 另一方面, “人” 也可以隐式融入到架构模型 的 “可感知的系统” 和 “可演化的系统” 中, 对于前者, 比如人可提供知识、行为识别和隐私数据等, 成 为环境上下文的一部分, 对于后者, 比如人可参与到软件动态更新安全点的选择和转换函数的合成与 审核中, 成为演化环节的一部分. 这两方面综合起来, “人” 对于未来的软件系统, 既可以是提出要求 的用户, 也可以是解决问题的关键, 因此他们是 “人 – 机 – 物” 融合应用整体系统不可或缺的一部分. 此外, 在以上运行机理和生命周期部分, 我们介绍的适应和演化是两种重要的成长方式, 前者是指基 于环境的反馈进行自主适应的优化, 这是在运行态, 主要指利用软件自身已实现的功能和做法应对环 境和资源的变迁, 在弹性限度之内可以无需修改软件设计和代码, 并依旧保持原先的服务质量和内容; 后者是指基于开发者和使用者的驱动进行过程演进的优化, 这与开发态和运行态都有关, 开发态包括 支持在弹性限度之外的新功能设计和故障修复等行为, 运行态包括支持新版本软件进行动态更替等行 为. 这两方面综合起来, 我们说, 适应和演化都是实现软件成长的重要途径. 以上关于架构模型、运行机理和生命周期 3 个基本特征分别分析了可成长软件的静态结构、运 行机制和演进历程, 回答 “可成长软件是什么” 这一问题, 并给出理想的可成长软件的设计蓝图. 对照 此蓝图, 接下来的重要问题是, 如何去构建这样的可成长软件, 其中有何技术挑战. 下面我们探讨并回 答 “可成长软件怎么做” 这一问题. 3.4 可成长网构软件的构建思路和技术挑战 我们以元级化和定义化的思路来构建可成长软件, 这着眼于复杂的环境开放性, 其中包括应用场 景的多样性、环境和需求的多变性, 以及系统内外开发者和用户的不确定性. 我们以元级化提供可成 长能力, 因为传统软件属于 “目标级”, 仅实现针对给定需求和环境的功能, 而新增 “元级” 则使软件可 抽象可成长能力, 以刻画感知、适应和演化行为. 元级化有个重要的哲学问题, 即认清 “我是谁”. 另一 方面, 我们以定义化实现软件的成长, 以 “软件定义软件” 的方式, 克服 “软件不软” 的困难, 支持软件 持续的适应和演化, 以应对环境和需求变化. 定义化也有个重要的哲学问题, 即认清 “我从哪里来, 要 到哪里去”. 相反, 软件若直接实现应用功能, 则可能表现脆弱, 无论是应用需求有变迁, 或是环境和资源不再 满足其功能实现的前提, 都可能造成软件难以保持原先的服务质量和内容, 从而不得不回归维护或重 新构建. 而 “元级化” 概念的提出, 要求软件在设计过程中明确考虑环境、资源和需求的变迁问题, 以 软件定义的方式设计实现软件在运行时的自主适应和开发时的持续演进, 也即要抽象软件的成长能力. 另外, 以上关于 “软件不软” 是形象的说法, 意思是软件若直接实现应用功能则表现 “脆而硬”, 容易被 环境、资源和需求的持续变迁所打倒, 而 “软件能软” 的说法则是相反, 是期望其能在应对环境、资源 和需求变迁方面游刃有余, 表现出一定程度的韧性, 这也是可成长软件的目标. 根据以上元级化和定 义化的构建思路, 我们提出面向自适应和持续演化的可成长软件体系结构 (图 4). 基于此结构, 可成长 软件通过基于先验元模型的环境需求建模和规约感知环境和需求变化, 通过软件定义体系结构模型支 持软件系统的自适应和持续演化行为. 从图中可以看出, 这一结构分 “静态构成” 和 “运行机制” 上下 两层, 从功能上又分 “环境和需求的感知与理解” 和 “软件自适应与持续演进” 左右两部分. 从静态构 成上, 软件对物理环境进行抽象, 获得 “先验” 的环境和需求 (即模型和规约), 然后在运行机制上, 以 环境处理中间件对物理环境进行感知, 提炼出应用上下文. 以静态规约和运行时上下文共同驱动可适 应的软件系统, 以适应逻辑推动业务逻辑的优化, 实现系统的适应和演化行为. 这样的规划在整体上体 1601 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
许畅等：可成长软件理论方法和实现技术：从范型到跨越 环境和需求的感知与理解 软件自适应与持续演进 “先验”的环境和需求 可适应软件系统 抽象 予盈老 适应逻辑 业务逻辑 静态构成 物理 软件定义体 系结构模型 境处理中间件 系统的适 感知 情境感知应用上下驱动 )应和演化 基础设施 文处理 行为 运行机制 图4（网络版彩图）面向自适应和持续演化的可成长软件体系结构 Figure 4 (Color online)Architecture of growing software with self-adaptation and continuous-evolution support 现了软件定义的系统结构模型，其中上层（红色）是元级部分，下层（紫色）是新的目标级部分 有了前述的可成长软件设计蓝图和构建思路，我们回答“可成长软件怎么做”这一问题，还需解决 众多的技术挑战.比如说，在运行时刻，如何做到环境上下文的高效处理，在演化时刻，如何做到软件 版本的无缝更替，以及在整个过程中，如何评估和保障环境上下文处理和软件适应演化的质量等.针 对这些挑战，我们在第4节中探讨支撑软件可成长性的关键技术，并分析和总结当前的研究进展， 4 支撑软件可成长性的关键技术 本节讨论支撑软件可成长性的关键技术，包括赋能关键技术和外围关键支撑，其涉及软件开放环 境感知与自适应、无缝演化和过程演进，以及演化质量评估方法和保障机制等重要方面 4.1软件可成长性关键技术及其支撑角色 支撑软件可成长性的关键技术主要覆盖可成长网构软件的几个重要方面.包括开放环境感知与自 适应方法和技术、软件无缝演化和过程演进支撑技术，以及软件演化质量评估方法和保障机制.其中， 开放环境感知与自适应方法和技术负责准确、高效地理解环境和资源的变化，软件无缝演化和过程演 进支撑技术负责软件在线更新并挖掘用户需求的变化，软件演化质量评估方法和保障机制负责评估和 保障环境质量和软件一致性演化. 开放环境感知与自适应方法和技术.这是支撑可成长软件内化自主适应能力的核心技术，需要做 到：高效的环境上下文一致性处理.以提升检测和修复环境上下文一致性错误的处理性能：资源使用 的在线监控和优化，以从资源配置和调度角度为软件运行提供有效资源支撑和性能优化：以及多维多 粒度的资源调度优化，以为异构资源进行抽象并建立优先级资源调度.这方面的几项技术协作实现准 确、高效理解环境和资源变化的目标 软件无缝演化和过程演进支撑技术.这是支撑可成长软件内化过程演进能力的核心技术，需要做 到：高一致、低干扰的软件在线更新和版本热部署，以提供一致性保障并最小化对服务干扰：软件运行 环境的可配置定义，以实现软件在线演化中的资源保障：以及面向开发生态的运维推荐和用户需求分 析，以支撑智能化开发成员推荐和用户隐式需求分析.这方面的几项技术协作实现软件在线更新并挖 掘用户需求变化的目标. 软件演化质量评估方法和保障机制.这是支撑可成长软件持续演化服务质量评估和保障的核心技 术，需要做到：环境上下文一致性处理效率和效果的科学评估和保障，如以处理性能、漏报数量、误报 数量和修复效果评估质量，以增量式检测、并行式检测和跨越式调度保障质量等；软件在线更新安全 1602 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
许畅等: 可成长软件理论方法和实现技术: 从范型到跨越 图 4 (网络版彩图) 面向自适应和持续演化的可成长软件体系结构 Figure 4 (Color online) Architecture of growing software with self-adaptation and continuous-evolution support 现了软件定义的系统结构模型, 其中上层 (红色) 是元级部分, 下层 (紫色) 是新的目标级部分. 有了前述的可成长软件设计蓝图和构建思路, 我们回答 “可成长软件怎么做” 这一问题, 还需解决 众多的技术挑战. 比如说, 在运行时刻, 如何做到环境上下文的高效处理, 在演化时刻, 如何做到软件 版本的无缝更替, 以及在整个过程中, 如何评估和保障环境上下文处理和软件适应演化的质量等. 针 对这些挑战, 我们在第 4 节中探讨支撑软件可成长性的关键技术, 并分析和总结当前的研究进展. 4 支撑软件可成长性的关键技术 本节讨论支撑软件可成长性的关键技术, 包括赋能关键技术和外围关键支撑, 其涉及软件开放环 境感知与自适应、无缝演化和过程演进, 以及演化质量评估方法和保障机制等重要方面. 4.1 软件可成长性关键技术及其支撑角色 支撑软件可成长性的关键技术主要覆盖可成长网构软件的几个重要方面, 包括开放环境感知与自 适应方法和技术、软件无缝演化和过程演进支撑技术, 以及软件演化质量评估方法和保障机制. 其中, 开放环境感知与自适应方法和技术负责准确、高效地理解环境和资源的变化, 软件无缝演化和过程演 进支撑技术负责软件在线更新并挖掘用户需求的变化, 软件演化质量评估方法和保障机制负责评估和 保障环境质量和软件一致性演化. 开放环境感知与自适应方法和技术. 这是支撑可成长软件内化自主适应能力的核心技术, 需要做 到: 高效的环境上下文一致性处理, 以提升检测和修复环境上下文一致性错误的处理性能; 资源使用 的在线监控和优化, 以从资源配置和调度角度为软件运行提供有效资源支撑和性能优化; 以及多维多 粒度的资源调度优化, 以为异构资源进行抽象并建立优先级资源调度. 这方面的几项技术协作实现准 确、高效理解环境和资源变化的目标. 软件无缝演化和过程演进支撑技术. 这是支撑可成长软件内化过程演进能力的核心技术, 需要做 到: 高一致、低干扰的软件在线更新和版本热部署, 以提供一致性保障并最小化对服务干扰; 软件运行 环境的可配置定义, 以实现软件在线演化中的资源保障; 以及面向开发生态的运维推荐和用户需求分 析, 以支撑智能化开发成员推荐和用户隐式需求分析. 这方面的几项技术协作实现软件在线更新并挖 掘用户需求变化的目标. 软件演化质量评估方法和保障机制. 这是支撑可成长软件持续演化服务质量评估和保障的核心技 术, 需要做到: 环境上下文一致性处理效率和效果的科学评估和保障, 如以处理性能、漏报数量、误报 数量和修复效果评估质量, 以增量式检测、并行式检测和跨越式调度保障质量等; 软件在线更新安全 1602 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
中国科学：信息科学第50卷第11期 性和效率的科学评估和保障，如以服务一致性，对服务干扰程度、停顿时间和性能损失评估质量，以构 件级一致性维护、代码级更新错误恢复和系统级更新测试保障质量：以及基于模型的持续演化策略构 造及验证，如以层次化自适应和在线学习规划解决不确定性和不可预见性问题.这方面的几项技术协 作实现评估和保障环境质量和软件一致性演化的目标. 我们把支撑软件可成长性的关键技术分为赋能关键技术和外围关键支撑两部分，前者直接负责软 件开放环境感知与自适应、无缝演化和过程演进，以及演化质量评估方法和保障机制3个重要方面， 后者从静态分析、动态检测和安全分析3方面辅助支撑软件的可成长性.接下来我们分析和总结这些 关键技术的当前研究进展. 4.2赋能关键技术的研究进展 针对软件开放环境感知与自适应、无缝演化和过程演进，以及演化质量评估方法和保障机制3个 重要方面的赋能关键技术.我们先分析其解决思路，这大致可分为可成长软件内化自主适应能力与质 量保障，以及可成长软件内化过程演进能力与质量保障这两部分 可成长软件内化自主适应能力与质量保障.软件要准确、高效地理解环境和资源的变化，就必须 应对其从环境和资源处获得不精确、不完整，甚至相互冲突上下文数据的技术挑战，这要求有高效的 环境上下文一致性处理技术.“一致性处理”意味“看得透”，即要确保上下文数据的质量；“高效”意 味“做得快”，要能在软件运行时高性能地检测和修复上下文数据的错误.我们的目标是实现环境上下 文处理效率的数量级提升，解决思路是细粒度多维度优化.具体而言，对每次约束检测的调度，如果上 下文数据前后关联，我们可采用强耦合增量式约束检测，达成“单步更高效”，如果数据前后无关，我们 可采用弱耦合并行式约束检测，达成“多步能并行”，以双管齐下，实现单次调度加速的效果：对多次约 束检测的调度，我们可识别其中的无效调度（即不检测也无漏报错误），采用跨跃式检测调度，达成“跨 越批处理”，以实现多次调度加速的效果.两方面综合起来，我们在约束检测调度内和调度间分别进行 细粒度和多维度的优化.可期望实现环境上下文处理效率的数量级提升 可成长软件内化过程演进能力与质量保障.软件要支持在线更新并挖掘用户需求的变化，就必须 解决“怎么变”的技术问题和“变什么”的需求问题.对前者，要求有高一致、低干扰的软件在线更新 和版本热部署技术，对后者，要求有面向开发生态的运维推荐和用户需求分析技术.在软件在线更新 方面（即“怎么变”），我们的目标是实现更新过程的服务一致性，并降低对服务的干扰程度、停顿时间 和性能损失，解决思路是在线式多层面更新.具体而言，在架构层，我们可利用依赖分析支持过程的动 态迁移：在构件层，我们可基于动态依赖降低对服务的干扰；在代码层，我们可使用延时更新缩短服务 的中断时间.而在用户需求挖掘方面（即“变什么”），我们既可从社交活动中分析用户的需求，即通过 软件使用行为和评价信息分析用户潜在需求并辅助以用户具体评论文本构建用户显式需求，也可从日 常行为中推断用户的需求，即在感知层收集用户可观测行为、心理和生理数据，在融合层分析多源异 构数据，解决其中冗余、噪声和数据缺失等问题，在理解层建立用户行为、思维和社会关系模型.此外 既与“怎么变”又与“变什么”密切相关的一个技术问题是如何面向开发生态进行正确、合适的运维 推荐（即由谁来解决如何开发和维护问题），我们的解决思路是利用开发者能力建模和项目成员推荐， 即通过开发者的项目经历建模其个体能力和协作方式，之后在项目发生人员变动时可推荐最适合此项 目团队的成员」 以下我们结合这两部分的解决思路，分析和总结目前在开放环境感知与自适应方法和技术、软件 无缝演化和过程演进支撑技术，以及软件演化质量评估方法和保障机制这3方面赋能关键技术上的进 展.限于篇幅，我们在每个技术点上仅列举一至两项代表性工作 1603 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
中国科学 : 信息科学 第 50 卷 第 11 期 性和效率的科学评估和保障, 如以服务一致性, 对服务干扰程度、停顿时间和性能损失评估质量, 以构 件级一致性维护、代码级更新错误恢复和系统级更新测试保障质量; 以及基于模型的持续演化策略构 造及验证, 如以层次化自适应和在线学习规划解决不确定性和不可预见性问题. 这方面的几项技术协 作实现评估和保障环境质量和软件一致性演化的目标. 我们把支撑软件可成长性的关键技术分为赋能关键技术和外围关键支撑两部分, 前者直接负责软 件开放环境感知与自适应、无缝演化和过程演进, 以及演化质量评估方法和保障机制 3 个重要方面, 后者从静态分析、动态检测和安全分析 3 方面辅助支撑软件的可成长性. 接下来我们分析和总结这些 关键技术的当前研究进展. 4.2 赋能关键技术的研究进展 针对软件开放环境感知与自适应、无缝演化和过程演进, 以及演化质量评估方法和保障机制 3 个 重要方面的赋能关键技术, 我们先分析其解决思路, 这大致可分为可成长软件内化自主适应能力与质 量保障, 以及可成长软件内化过程演进能力与质量保障这两部分. 可成长软件内化自主适应能力与质量保障. 软件要准确、高效地理解环境和资源的变化, 就必须 应对其从环境和资源处获得不精确、不完整, 甚至相互冲突上下文数据的技术挑战, 这要求有高效的 环境上下文一致性处理技术. “一致性处理” 意味 “看得透”, 即要确保上下文数据的质量; “高效” 意 味 “做得快”, 要能在软件运行时高性能地检测和修复上下文数据的错误. 我们的目标是实现环境上下 文处理效率的数量级提升, 解决思路是细粒度多维度优化. 具体而言, 对每次约束检测的调度, 如果上 下文数据前后关联, 我们可采用强耦合增量式约束检测, 达成 “单步更高效”, 如果数据前后无关, 我们 可采用弱耦合并行式约束检测, 达成 “多步能并行”, 以双管齐下, 实现单次调度加速的效果; 对多次约 束检测的调度, 我们可识别其中的无效调度 (即不检测也无漏报错误), 采用跨跃式检测调度, 达成 “跨 越批处理”, 以实现多次调度加速的效果. 两方面综合起来, 我们在约束检测调度内和调度间分别进行 细粒度和多维度的优化, 可期望实现环境上下文处理效率的数量级提升. 可成长软件内化过程演进能力与质量保障. 软件要支持在线更新并挖掘用户需求的变化, 就必须 解决 “怎么变” 的技术问题和 “变什么” 的需求问题. 对前者, 要求有高一致、低干扰的软件在线更新 和版本热部署技术, 对后者, 要求有面向开发生态的运维推荐和用户需求分析技术. 在软件在线更新 方面 (即 “怎么变”), 我们的目标是实现更新过程的服务一致性, 并降低对服务的干扰程度、停顿时间 和性能损失, 解决思路是在线式多层面更新. 具体而言, 在架构层, 我们可利用依赖分析支持过程的动 态迁移; 在构件层, 我们可基于动态依赖降低对服务的干扰; 在代码层, 我们可使用延时更新缩短服务 的中断时间. 而在用户需求挖掘方面 (即 “变什么”), 我们既可从社交活动中分析用户的需求, 即通过 软件使用行为和评价信息分析用户潜在需求并辅助以用户具体评论文本构建用户显式需求, 也可从日 常行为中推断用户的需求, 即在感知层收集用户可观测行为、心理和生理数据, 在融合层分析多源异 构数据, 解决其中冗余、噪声和数据缺失等问题, 在理解层建立用户行为、思维和社会关系模型. 此外, 既与 “怎么变” 又与 “变什么” 密切相关的一个技术问题是如何面向开发生态进行正确、合适的运维 推荐 (即由谁来解决如何开发和维护问题), 我们的解决思路是利用开发者能力建模和项目成员推荐, 即通过开发者的项目经历建模其个体能力和协作方式, 之后在项目发生人员变动时可推荐最适合此项 目团队的成员. 以下我们结合这两部分的解决思路, 分析和总结目前在开放环境感知与自适应方法和技术、软件 无缝演化和过程演进支撑技术, 以及软件演化质量评估方法和保障机制这 3 方面赋能关键技术上的进 展. 限于篇幅, 我们在每个技术点上仅列举一至两项代表性工作. 1603 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
许畅等：可成长软件理论方法和实现技术：从范型到跨越 4.2.1开放环境感知与自适应方法和技术 这方面研究要解决高质高效的环境上下文一致性处理问题， 可成长软件需要能够根据所感知的环境上下文调整自身行为，以实现智能的软件服务，但环境上 下文中往往包含各种感知噪音和测量误差，容易导致错误的行为调整，甚至造成软件崩溃.当前的方 法是通过约束检测发现环境上下文一致性错误并及时修复，但已有技术采用即时调度策略，虽然能保 证正确性但是效率低下，也有尝试批量检测策略，虽然能提高效率但是丢失率居高不下.对此，我们提 出了基于自适应分组的批量检测策略GEAS1间，既保证正确性，又兼容已有约束检测技术并大幅提升 检测效率.与已有工作相比，GEAS可提升约束检测效率1.46.5倍，并保证零丢失率，而已有工作则 会导致39%~65%的丢失率.在此基础上，基于组内匹配对消优化，我们进一步提出了跨越批处理式增 强型检测策略GEAS-opt1),在零丢失率前提下，提升约束检测效率6.728.6倍.基于该技术，我们 实现了原型测试系统，使用588万城市车辆GPS数据开展一致性约束检测实验，结果表明该系统在 离线检测配置下可提升检测效率48~148倍，在在线检测配置下可提升检测效率18~42倍，并保证了 零漏报率和零误报率，有效支撑了可成长软件高质高效感知开放环境的能力. 4.2.2软件无缝演化和过程演进支撑技术 这方面研究要解决高一致低干扰的软件动态更新.非确定环境下的自适应系统验证.以及面向开 发生态的运维推荐和需求分析等问题， 可成长软件的无缝演化依赖于动态更新技术.它可以在不终止正在运行软件系统的前提下将其更 新到新版本.在动态更新的过程中，被修改系统组件的运行时状态需被合理地转换到对应的新状态 以确保被修改组件仍可正确与其他组件交互.然而实现运行时状态转换面临诸多困难.主要是由于不 同版本组件的底层实现差异所导致.对此，我们提出了AOTES技术18，针对Java程序实现动态更新 中的自动对象状态转换.为了消除不同版本实现层的差异，AOTES将旧版本中对象状态抽象成方法调 用历史，然后将该调用历史中的旧版本方法替换成对应的新版本方法，并重新执行新版本方法调用序 列创建对应的新版本对象状态.AOTE$不需要对被更新程序做任何代码插桩，因此在软件系统常态 执行过程中没引入额外负载.我们收集了若干开源软件开发库和服务器程序，包括Apache Commons Collections,Tomcat,FTP以及SSHD.在61个实验对象转换中，AOTES可成功完成51个对象转换， 而已有技术（如缺省转换和TOS转换1町）只能处理611个对象转换.在此基础上，我们分别在代码 层、构件层和应用层部署软件动态更新技术.针对重要的技术指标，在干扰减少方面，我们初步实现面 向微服务的软件无缝演化，较传统安全的Quiescence方法20，AOTES在版本更新时可减少23.9%的 千扰，在停顿控制方面，我们初步实现面向代码级更新的Javelus8,在42个真实Tomcat更新上的测 试实验中，系统中断时间不超过70.5s,有效支撑了可成长软件的跨版本无缝演化能力. 此外，可成长软件的自主适应需要应对开放环境的非确定性，因此非确定环境下的自适应系统验 证是一个重要问题.已有技术通过反例构造验证和发现自适应系统中的缺陷问题.但其所依赖的非确 定环境模型往往不够准确而需要在真实环境中对构造的反例进一步确认.困难是这样构造的反例由于 发生概率很低而导致确认的效率极低，严重影响系统验证的效果.对此，我们提出了VERSA技术21)， 以原有反例为基础，进一步构造出新的路径等价反例，这些新构造的反例能确保触发等价的原缺陷问 题，但拥有基于当前非确定环境模型的最大发生概率.实验表明，VESA比已有技术可显著提升构造 反例的发生概率（发生概率提升一个数量级，触发时间降低一个数量级），有效推进了自适应系统的缺 陷验证水平.进一步的，此类方法其所依赖的非确定环境模型由于感知误差和数据样本问题往往不够 1604 https://engine.scichina.com/doi/10.1360/SSI-2020-0079
许畅等: 可成长软件理论方法和实现技术: 从范型到跨越 4.2.1 开放环境感知与自适应方法和技术 这方面研究要解决高质高效的环境上下文一致性处理问题. 可成长软件需要能够根据所感知的环境上下文调整自身行为, 以实现智能的软件服务, 但环境上 下文中往往包含各种感知噪音和测量误差, 容易导致错误的行为调整, 甚至造成软件崩溃. 当前的方 法是通过约束检测发现环境上下文一致性错误并及时修复, 但已有技术采用即时调度策略, 虽然能保 证正确性但是效率低下, 也有尝试批量检测策略, 虽然能提高效率但是丢失率居高不下. 对此, 我们提 出了基于自适应分组的批量检测策略 GEAS [16] , 既保证正确性, 又兼容已有约束检测技术并大幅提升 检测效率. 与已有工作相比, GEAS 可提升约束检测效率 1.4∼6.5 倍, 并保证零丢失率, 而已有工作则 会导致 39%∼65% 的丢失率. 在此基础上, 基于组内匹配对消优化, 我们进一步提出了跨越批处理式增 强型检测策略 GEAS-opt [17] , 在零丢失率前提下, 提升约束检测效率 6.7∼28.6 倍. 基于该技术, 我们 实现了原型测试系统, 使用 588 万城市车辆 GPS 数据开展一致性约束检测实验, 结果表明该系统在 离线检测配置下可提升检测效率 48∼148 倍, 在在线检测配置下可提升检测效率 18∼42 倍, 并保证了 零漏报率和零误报率, 有效支撑了可成长软件高质高效感知开放环境的能力. 4.2.2 软件无缝演化和过程演进支撑技术 这方面研究要解决高一致低干扰的软件动态更新, 非确定环境下的自适应系统验证, 以及面向开 发生态的运维推荐和需求分析等问题. 可成长软件的无缝演化依赖于动态更新技术, 它可以在不终止正在运行软件系统的前提下将其更 新到新版本. 在动态更新的过程中, 被修改系统组件的运行时状态需被合理地转换到对应的新状态, 以确保被修改组件仍可正确与其他组件交互. 然而实现运行时状态转换面临诸多困难, 主要是由于不 同版本组件的底层实现差异所导致. 对此, 我们提出了 AOTES 技术 [18] , 针对 Java 程序实现动态更新 中的自动对象状态转换. 为了消除不同版本实现层的差异, AOTES 将旧版本中对象状态抽象成方法调 用历史, 然后将该调用历史中的旧版本方法替换成对应的新版本方法, 并重新执行新版本方法调用序 列创建对应的新版本对象状态. AOTES 不需要对被更新程序做任何代码插桩, 因此在软件系统常态 执行过程中没引入额外负载. 我们收集了若干开源软件开发库和服务器程序, 包括 Apache Commons Collections, Tomcat, FTP 以及 SSHD. 在 61 个实验对象转换中, AOTES 可成功完成 51 个对象转换, 而已有技术 (如缺省转换和 TOS 转换 [19] ) 只能处理 6∼11 个对象转换. 在此基础上, 我们分别在代码 层、构件层和应用层部署软件动态更新技术. 针对重要的技术指标, 在干扰减少方面, 我们初步实现面 向微服务的软件无缝演化, 较传统安全的 Quiescence 方法 [20] , AOTES 在版本更新时可减少 23.9% 的 干扰, 在停顿控制方面, 我们初步实现面向代码级更新的 Javelus 8, 在 42 个真实 Tomcat 更新上的测 试实验中, 系统中断时间不超过 70.5 ms, 有效支撑了可成长软件的跨版本无缝演化能力. 此外, 可成长软件的自主适应需要应对开放环境的非确定性, 因此非确定环境下的自适应系统验 证是一个重要问题. 已有技术通过反例构造验证和发现自适应系统中的缺陷问题, 但其所依赖的非确 定环境模型往往不够准确而需要在真实环境中对构造的反例进一步确认. 困难是这样构造的反例由于 发生概率很低而导致确认的效率极低, 严重影响系统验证的效果. 对此, 我们提出了 VERSA 技术 [21] , 以原有反例为基础, 进一步构造出新的路径等价反例, 这些新构造的反例能确保触发等价的原缺陷问 题, 但拥有基于当前非确定环境模型的最大发生概率. 实验表明, VERSA 比已有技术可显著提升构造 反例的发生概率 (发生概率提升一个数量级, 触发时间降低一个数量级), 有效推进了自适应系统的缺 陷验证水平. 进一步的, 此类方法其所依赖的非确定环境模型由于感知误差和数据样本问题往往不够 1604 https://engine.scichina.com/doi/10.1360/SSI-2020-0079