word to latex
This commit is contained in:
parent
8af21c1333
commit
f0a138b9d4
|
|
@ -0,0 +1,160 @@
|
|||
\section{引言}
|
||||
|
||||
软件是以计算为核心手段实现应用目标和价值的解决方案。从1966年首届图灵奖至2018年的53次颁奖中，属于软件领域的有37次（69.8\%），其中以程序设计语言、编译和操作系统为主获奖的有22次获奖，还有4次数据库获奖。作为本书第一部分的开篇，本章将简要回顾软件和软件技术的发展历程，通过梳理软件发展脉络，总结软件学科的基本内涵、关键问题、研究方法和发展规律，为第二部分学科发展战略提供基础。
|
||||
|
||||
\section{软件发展简史}
|
||||
\subsection{人力/机械计算时代}
|
||||
计算是人类思维的基本形式之一。人类历史上最早的计算设备是中国算盘。到东汉年代，提花机（参见图\ref{fig:1-1}）的设计中蕴含了用编程方式编织特定图案的思想，类似的设备1805年欧洲出现了Jacquard‘s Loom（参见图\ref{fig:1-2}）。1842年人类的第一位程序员Ada Lavelace为Babagge的分析机写了第一个程序，功能是计算Bernoulli数（参见图\ref{fig:1-3}，\ref{fig:1-4}）。可见早在机械计算时代，可编程的思想已经萌芽。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\begin{minipage}[t]{0.48\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=5cm]{fig1-1/1-1.png}
|
||||
\caption{提花机}
|
||||
\label{fig:1-1}
|
||||
\end{minipage}
|
||||
\begin{minipage}[t]{0.48\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=5cm]{fig1-1/1-2.png}
|
||||
\caption{Jacquard‘s Loom}
|
||||
\label{fig:1-2}
|
||||
\end{minipage}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\begin{minipage}[t]{0.48\textwidth}
|
||||
\includegraphics[width=5cm]{fig1-1/1-3.jpg}
|
||||
\caption{Babagge分析机}
|
||||
\label{fig:1-3}
|
||||
\end{minipage}
|
||||
\begin{minipage}[t]{0.48\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=5cm]{fig1-1/1-4.jpg}
|
||||
\caption{Babagge分析机的第一个程序}
|
||||
\label{fig:1-4}
|
||||
\end{minipage}
|
||||
\end{figure}
|
||||
|
||||
|
||||
Computer一词历史上出现在1613年，用来指完成演算或计算的人员。这种说法一直到19世纪末后工业革命产生了主要目标是用来演算的机器为止\footnote{https://www.computerhope.com/issues/ch000984.htm}。著名的哈佛大学哈佛天文台在1877年至1919年期间雇佣了一批妇女作为处理天文数据的技术工人。在电子计算机出现之前的人力和机械计算时代，Mathematic Tables项目是最大最复杂的计算项目，组织这类项目的关键就是编程的基本思想。Gertrude Blanch女士作为“数学的导演”和“计算的经理”，设计了人力计算团队执行的“算法”。这些算法和错误检测的设计思想作为超越函数的计算标准延续了数十年。逐渐地，也出现了表达编程描述形式和记号，例如1921年Lillian和Frank Gilbreth的过程图（Process Charts，参见图1-5），与后来的程序流图十分类似；又如1940年IBM的W.J. Eckert提出的打孔卡（参见图1-6）。我们可以看到，计算和编程是紧密耦合的，而编程的结果事实上是给出了一种计算应用（数学计算）的解决方案，它可以有人力计算或机械计算完成。然而，在那个时代，还未形成通用计算和编程的思想。
|
||||
|
||||
|
||||
\subsection{电子计算时代}
|
||||
四十年代出现了电子计算机，计算机先驱们相继研制了Colossus（1943）、ENIAC（1946）、EDSAC（1949）和Mark I（1949）等计算机。EDSAC作为第一台存储程序结构的电子计算机打开了通用计算的时代。程序是通过一种微开关的形式加载到机器硬件上。到五十年代后，才出现了用户和计算机之间的简单交互。Grace Hopper在1951年和1952年为UNIVAC I编写了A-0系统，这是第一个电子计算机的编译器，从今天的角度看A-0更像现代编译器概念的Loader或Linker，无论怎样都是第一个系统软件。UNIVAC I的程序有一组子程序和参数序列组成。两年后，Ａ-2系统成为了第一个开源软件。早期系统是驻留管理程序，它将程序从纸带或者穿孔卡上读到计算机中加载。这种技术直接形成了历史上第一个商用操作系统，1956年IBM 704的操作系统。五十年代后，人们开始意识到1936年提出的图灵机模型的理论意义，图灵机成为计算机科学发展的理论基础。通用图灵机和通用计算使人们进一步认识到可编程是计算的基本属性，人们通过编写程序使得计算机完成指定的任务。
|
||||
|
||||
\subsection{软件和软件工程的出现}
|
||||
“软件”一词最早出现在1953年兰德公司R.R. Carhart的报告中，用来说明讨论可靠性时与硬件相对应的“人因”。而人们现在一般认为“软件”的术语来自John W. Tukey在1958年的论文。文中指出 “软件由精心编写的解释程序、编译器和自动编程等组成，它们至少象电容器、晶体管、电线和磁带等现代计算机硬件一样重要”。1968年，或许是巧合，出现两个软件发展史上的重大事件。一是，软件与硬件的解绑；二是，软件工程会议的召开。这两个事件的背景都与IBM著名的IBM S/360系统相关。
|
||||
|
||||
软件依附在硬件之上解决应用问题。早期的计算机系统中硬件和软件时捆绑的。所谓“捆绑”，指IBM在收费上采取只考虑硬件价格而软件和系统服务免费的策略。这在当时对于用户是很有吸引的，也增强了公司的竞争力。到1964 年，情况发生了变化，IBM宣布了新的IBM S/360系列，希望能够升级硬件系统而不需要替换或改变用户的应用程序。而稍后RCA也宣布了其新的Spectra 70系统与IBM 360兼容。这使得IBM难以阻止RCA在市场上“免费”使用IBM的软件。1968年，IBM宣布了其软件和硬件系统的解绑，改变了软件的商业和竞争模式。自此软件从计算机系统中与硬件的剥离，获得了可以独立发展的空间。可以看到，除了商业上的反垄断和市场竞争因素外，软件本质上“解决方案”的独立性和计算平台抽象为解绑提供了历史必然和技术可行。自此，人们逐步认识到软件是计算机系统的灵魂，它向下管理计算机系统的各类资源，向上满足用户对计算机系统的应用需求。
|
||||
第二个事件是软件工程的兴起。计算机能力的快速提高和软件复杂性困难，出现了“软件危机”现象，例如，IBM 360操作系统OS/360的进度、开销和可靠性均不尽人意。NATO在1968年举行了首次软件工程会议，人们逐渐认识到需要如同其他领域的工程方法一样，系统化地进行软件开发。正如Margaret Hamilton在开发阿波罗在轨飞行和导航系统项目中明确指出，“我努力使软件具有合法性，使得构造软件的活动要受到应有的尊重，因而我开始用‘软件工程’将其与硬件和其他类型的工程区分开来，成为整个系统工程的一部分”。软件工程的出现不仅激活了软件发展的巨大活力，也隐喻了软件发展的外在驱动力，不断增长的应用需求和不断增长的计算能力。
|
||||
|
||||
|
||||
\subsection{软件发展的主线}
|
||||
软件作为计算灵魂与计算发展紧密相连。追溯软件发展可以有多条线索，既可以考察计算机系统平台、应用和计算形态的发展，也既可以采用程序设计语言、系统软件、软件开发方法等角度。从需求应用看，从军事计算需求起步，逐步从商业计算、个人计算、网络计算、云端计算、到如今泛在计算；从计算平台看，从主机时代、微机时代、互联网时代到人机物融合时代，计算设备的多样性、能力、范围不断扩展。相应的，面向需求，满足各类质量、进度和成本约束，软件的语言从机器语言、汇编语言、高级语言、发展到领域语言，软件开发方法从结构化方法、对象化方法、构件化方法、服务化和网构化方法到智能化方法，系统软件平台从批处理、交互式、网络化、云边端融合系统软件。
|
||||
|
||||
软件作为问题解决方案，其结果是认识空间的表达。Sapir-Whorf的语言相对论假设对语汇的重要性给出了一个表述。其弱版的语言相对论是指语言影响思维与决策；而强版的语言决定论则指语言决定思维与认知边界。认识软件的切入点是认识各种软件抽象。它们构成了软件方法学的语汇，包括但不限于程序设计语言设施、软件构件、软件服务等。而系统软件的核心在于实现抽象，应用软件在于使用抽象。不同层次的抽象、抽象的计算实现和使用组成了软件发展的脉络。我们试图以软件各种抽象为主线来梳理和汇聚软件发展的基本历程。
|
||||
|
||||
从最初计算机系统上机器指令开始，人们不断地在建立抽象，例如：汇编语言中的宏指令抽象，定义了具有宏名的一段汇编语句序列；在结构化高级语言的数据结构抽象，过程抽象；面向对象方法中的类和继承；构件化方法中的构件抽象；服务化方法的服务抽象；以及网构化方法的主体抽象；智能化方法语言中的学习赋能抽象等等。语汇抽象之间的关系与软件定义栈呈现一个垂直吻合的关系。例如，在典型的大数据处理系统（Google）中，我们可以看到接口与服务、方法与设施、虚拟化与实现等不同层次组成的抽象栈，它们分别对应着Web服务、MapReduce、Dryad、Pregel、BigTable、集群调度、分布式文件、操作系统等抽象层。
|
||||
|
||||
以程序设计语言和相应程序接口为基础，形成了软件的基本抽象。与数学抽象的不同，软件抽象是可编程的单元并有计算之实现。围绕这些抽象软件学科的发展呈扇形展开，分化出以建立抽象为主要内容的软件理论和方法学；以实现抽象为主要内容的系统软件；以使用抽象为主的软件开发和工程。参见图1-X。
|
||||
|
||||
军事和科学计算是计算应用的最初需求。面向科学计算建立的抽象成为软件发展的早期里程碑。为了满足数值计算的需求John Backus1953年发展了Fortran语言，是历史上第一个正式推广的高级程序设计语言，1957年在IBM704计算机上实现。Fortran语言提供的抽象对用数学公式表达的问题求解提供了直接支持。多年的版本更替，Fortran语言至今仍在使用。Fortran的主要贡献者获得了图灵奖。1960年，面向常规商业信息处理，COBOL语言发布，成为COBOL-60。COBOL提供了面向周期性循环处理和数据变换的抽象，适合于报表、情报、计划编制等商业数据处理，如今仍有应用。同一时间段，面向通用计算的算法语言ALGOL 60诞生，成为ACM当时算法描述的标准，它提供了数据结构、块结构、递归等设施。ALGOL语言的意义重大，一是它确立了结构化高级程序设计语言设计的基础，之后的Pascal、C、Java等强制式程序设计语言的基础；二是它催生了试图严格或形式化定义语言和程序的一大批软件基础理论成果。ALGOL 60的主要贡献者Peter Naur获得了2006年图灵奖。60年代末至80年代，历经Simula 67、Smalltalk、C++等语言，面向对象程序设计范型形成，提供了类、对象、方法、消息传递、继承等设施，建立了封装、抽象和多态等机制。面向对象语言的创立者也获得了图灵奖。与强制式程序设计语言不同，50年代末人们还探索了声明式程序设计语言，其代表是基于Lambda演算的函数式语言LISP。它提供了用于问题求解的函数抽象，首次在语言中支持递归函数定义。LISP的设计思想深刻地影响了ML、Haskell等函数式程序设计语言的发展。随着人们对程序设计安全可靠、便捷有效等需求的提高，以及计算平台向并发、分布、异构发展，程序设计语言呈现了两方面走向：一是，程序设计范型的融合，例如面向对象语言和函数式语言的融合并支持并发、安全计算，出现了Scala、Rust等程序设计语言，展现了强劲的势头；另一方面是，面向特定领域的语言受到了重视，它们针对领域应用提供高效便捷的抽象，例如面向大数据处理的Map Reduce面向区块链智能合约的Solidity。
|
||||
|
||||
60年代末软件工程思想的出现，使得人们认识到如何面向应用建立软件开发方法和软件工程模式的重要性。软件开发方法中的诸多抽象大多来自于程序设计语言的思路。例如，70年代的结构化系统分析和设计方法、80年代的面向对象分析和设计、90年代基于构件的软件工程、新世纪的面向服务/网构化的软件工程等等。软件开发和程序设计在抽象上尽可能地保持了一致或相容，使得软件工程模型不同阶段、不同层次地抽象有着较好的对应。
|
||||
|
||||
程序设计语言向上要面向问题求解方法的表达，向下要在计算机系统上实现。围绕语言的语法、语义和语用等方面的程序理论和问题求解的计算理论成为了软件理论的重要部分。从ALGOL60开始，关于程序理论的研究就开始了，其基本内容是在计算理论的基础上建立程序的形式语义，并对程序及其性质进行推理，本质是基于数学的方法来建立抽象及抽象之间的联系。在60年代到70年代，人们建立了程序设计语言的操作语义学、公理语义学、指称语义学和代数语义学。程序语言与形式语义的研究紧密联系，例如，1974年Barbara Liskov提出了抽象数据类型的程序设计思想，建立了现代面向对象语言的核心特征，包括强类型检查和通用类型支持，支持了对象化方法语言中的类抽象。以形式语义学为基础，人们长时期探索程序的形式开发和形式验证等形式化方法和技术以提高软件生产率和软件质量，取得显著的进展，例如模型检验获得了2005年图灵奖。与程序相关的问题的求解判定和算法复杂性也成为程序设计语言设计和形式化方法的重要内容，例如Gradual类型的引入。
|
||||
|
||||
随着硬件能力快速提高，以编译器和操作系统为代表的系统软件成为建立抽象、使用抽象来实现更高级抽象的焦点。事实上，程序设计语言中许多重要概念来自于编译器和操作系统的设计。John Cocke在解决上下文无关语言的有效扫描中发明了动态程序设计范型，而Floyd为了构建层次化自顶向下的扫描器发明了递归协程序作为抽象结构。Floyd希望能发现语言支持的新范型（抽象）。这说明了抽象是用来支持相对应的设计方法，也就是问题求解的方法。
|
||||
|
||||
到六十年代，集成电路的兴起增强了计算机的能力，操作系统出现了不少新技术并变得强大复杂。典型的技术有多道程序设计、分时、实时、多处理器技术等等。70年代，操作系统的设计进一步发展，形成了UNIX操作系统，成为当今主机操作系统的基础。80年代，商业计算和微处理器时代到来，出现了一批微机和工作站操作系统，代表的是MS-DOS，Linux、Solaris 和Windows等。90年代，随着计算机网络和网络就是计算机的推动下，在主机和微机操作系统的基础上，中间件或网络化操作系统逐渐成为系统软件的新的增长点。进入新世纪后，以iOS和Android代表的移动操作，和主机操作系统向数据中心扩展的云操作系统形成了云端计算的软件基础设施的基本格局。
|
||||
|
||||
操作系统中的三个基本元素是抽象、机制和策略。而其抽象的基本设计原则是机制与策略的分离、共性的沉淀。典型的例子有进程和进程管理、线程和并发、调度、内存管理、进程间通信、I/O管理、虚拟化、分布文件系统、分布共享内存、安全与隐私抽象-Ownership等等。在实现这些抽象的过程中，人们发现并设计了计算的原理和法则，例如局部性原理、名字映射、分而治之、信息隐藏等等。与实现抽象密切相关，系统软件与计算平台的演进紧密相关，例如在网络化时代，操作系统的API是网络操作的API，而在云边端的时代，操作系统通过协议软件、RPC等来集成。Barbara Lis-kov讨论了系统、语言和抽象的关系，指出抽象对系统组织的作用，例如用进程和软件层次来组织复杂系统。为了应对操作系统设计中可靠性、安全性、可配置、可扩展和多处理器程序设计等挑战，微软的Singularity OS的首要任务开发新的抽象，包括平台的抽象指令集、操作系统和应用统一可扩展的体系结构和一阶的应用抽象。特别的是应用抽象递归的应用到操作系统自身，包括内核和其他OS构件。Singularity OS的后继Midori OS支持了微软西海岸和亚洲的自然语言搜索服务。Midori表明了合理的抽象和软件栈能在内存、类型和并发安全之上构建系统和应用，性能和安全并不是对立的。
|
||||
|
||||
回顾软件学科发展，在认知空间中，人们一方面不断的建立抽象，一方面不断的在计算平台上实现抽象，两者相辅相成，螺旋上升；与此同时使用抽象的方法和对高层抽象的需要促进了方法和技术的发展。例如，结构化程序设计开创了程序设计得到的程序具有良好的结构，在这个指导思想下，问题求解可以看作是一系列的分解过程，即从一个较高层的过程，初步的加入细节得到较低层的抽象，从而完成整个程序。逐步精化和层次化的程序结构是结构化程序设计的基本原理。在结构化程序设计的基础上，当程序员在某个抽象层次上使用下一层次提供的抽象时并不需要考虑底层的实现细节。然而高级程序设计语言不可能以内嵌的方式提供问题求解需要的所有抽象，需要一种方式可以从内嵌类型构造不同层次抽象的能力。这些动机促使了抽象数据类型的出现。抽象数据类型用抽象对象上一组操作的方式定义了该类抽象对象，即用类型上的操作来定义新类型。它一方面封装了底层操作抽象的细节，又构造了一组新的类型抽象。如图，结构化抽象与THE OS、C与UNIX、面向对象与CORBA和EJB、服务化与Docker虚拟机交相辉映，形成了以计算为手段的解平台提升，并与结构化、对象化、构件化、服务化等软件开发方法携手同行，成为人工科学边界物的基础。
|
||||
|
||||
软件发展的核心是管理复杂性。从平台空间到应用空间的认知与问题求解鸿沟是作为解决方案的软件来提供或弥补的，相应的软件形态也在逐步的演变丰富。在计算机诞生后五十年中，软件的表象发生数次变化。从早期的“程序=数据结构+算法”的初级抽象，到“软件=程序+文档”，结构化程序设计关注在于管理结构复杂性。进入网络化时代后，交互复杂性和规模复杂性日益突出，体系结构加设计模型抽象、服务加组合抽象为管理这些类复杂性应运而生。进入大数据时代后，知识复杂性和领域复杂性需要纳入软件，软件在程序加文档的基础上需要抽象知识、数据和能力。软件的发展从微观上看，从40年代到60年代解决基础问题，到80年代管理结构复杂性为主，到本世纪初管理交互复杂性为主，到近来以管理异构、互联的规模复杂性和社会技术复杂性。建立、实现、使用抽象的循环迭代不断往复，推进着软件技术的发展。
|
||||
|
||||
抽象是从制品的角度来认识、构造和演进软件。而软件作为人类的智力产品，与这条主线相配合，组织和管理制品在生命周期中的过程复杂性是极为重要的，也构成了一条与抽象相配合的辅线。它的演进与软件的应用、平台和认知空间的演进互联互动，从早期的作坊式生产组织方式、企业化生产组织方式发展到网络化智能化时代的社会化生产方式。企业化生产组织方式主要有软件过程（1970）、CMM（1988）、SCRUM（1995）、RUP（2000）和外包（2001）；社会化生产方式有开源（1997）、Git（2005）、StackOverflow（2007）和DevOps（2008）。
|
||||
|
||||
|
||||
|
||||
\section{软件学科的内涵、发展规律和基本架构}
|
||||
\subsection{内涵与学科特征}
|
||||
软件作为计算平台上实现应用价值的解决方案，是最存粹的人工制品，其内涵特征包括了三个方面：
|
||||
\begin{itemize}
|
||||
\item [-] 功能性：以何种结构和行为
|
||||
\item [-] 目的性：达成什么应用目的
|
||||
\item [-] 适应性：何种环境依赖之下
|
||||
|
||||
\end{itemize}
|
||||
|
||||
软件学科是以软件为研究对象，研究设计和使用软件及其规律的学科。其核心内容是以计算为工具的问题求解方法论，目标是达成效能、效率和价值的统一，知识体系包括了理论、方法、工具、环境和生态。N. Wirth在“软件工程简史”一文中指出“如果说我们能从过去学到什么，那就是计算机科学本质上是方法论学科。它开发并教育在广泛不同应用的共性受惠的知识和技术”。我们认为，在这个意义上，软件学科实质上就是Wirth所说的计算机科学。之所以我们使用了软件科学，是因为有了时代的扩展（参见第二篇引言）。
|
||||
|
||||
软件的功能性、目的性和适应性，使得软件学科呈现出了艺术、科学和工程共存的学科特征。这源自于软件本身融合了人类活动、数学物理规律约束的计算模型和装置、以及面向应用价值的工程设计。例如，软件的算法设计是艺术，而算法分析是科学；程序设计是艺术；而程序正确性是科学；进一步软件开发是工程，而软件分解与抽象及其正确性是艺术与科学。软件之目的性是其工程属性的来源，而功能性的设计及设计的柔性孕育了多样的艺术性，软件最终运行的计算平台的物理和自然属性内生了软件发展遵循的科学规律。而艺术、科学和工程在软件发展的不同阶段和侧面会相互渗透乃至相互转换。归根到底，其目的性价值、软硬平台与外部环境所形成的功能及界面适应性是其核心，也形成了软件成为万能集成器和粘合剂的基础设施地位。而这一特性，也形成了软件作为核心的不同层次栈组成计算载体，包括语言、平台、结构和框架。
|
||||
|
||||
\subsection{发展的基本规律}
|
||||
随着网络时代的到来，软件网构化和服务化，解耦和绑定的周期性出现，驱动力主次的周期性变化，使得软件变化成为常态。“变是不变”形成了软件发展的规律。我们从两个方面来认识软件学科发展的规律：第一，本学科发展的驱动力是什么？第二，本学科的研究方法论是什么。
|
||||
|
||||
\subsubsection{发展的驱动力}
|
||||
软件是刚性约束和超级柔性的产物。平台和应用目的可计算、复杂性和正确性形成了软件需要遵循的刚性约束，而内在的各种方法学引导，功能和适应性设计则形成了系统的柔性多样，也给予了软件学科无穷的发展活力。作为人工制品的界面物属性，软件学科发展的外部驱动力来自于两个方面：不断增长的应用需求和不断增强的计算平台；而其内在驱动力也来自于其核心问题的解决，即软件的效率和质量，即提高软件生产率，保障软件质量，降低软件成本，以及不断发展的人本属性，包括人的认知规律和人力资源管理的深化与提高。
|
||||
|
||||
\textbf{外在驱动力}
|
||||
|
||||
回顾软件发展的历史，可以看到软件的外在驱动力主要来自于两个方面。第一个方面是来自于计算平台的发展，简称平台驱动力；第二个方面是应用需求的增长，简称应用驱动力。平台的变迁形成了软件所依赖的平台空间；而应用的增长形成软件所解决的问题空间。在平台空间和问题空间的之间，形成了软件作为界面物所需具有的功能、目的和适应形成的认知空间。软件的发展是着三个空间变化、渗透和互动的产物。
|
||||
|
||||
应用和平台的诉求，应用拉动，平台提高，推动软件的发展。从应用驱动力的角度，软件的范围扩展，渗透力增强。不断增长的应用诉求拉动了软件技术从早期的科学计算应用，扩展到了等各类不同应用，软件学科的无可比拟的渗透力变得空前的强大，软件的形态、开发方法和运行形态等诸多方面发生了巨大的变化。从平台驱动力的角度，计算平台从Von Neumann计算机到网络就是计算机、从端网云是计算机到全球泛在计算，形成了从封闭、静态环境（单机计算平台）到开放、动态环境（网络计算平台）的态势，造就了软件发展的不竭动力，使得软件所能提供的解决方案的解空间更趋科学、高效。在应用驱动力和平台驱动力的联合作用下，软件正走向“定义一切”。
|
||||
|
||||
\textbf{内在驱动力}
|
||||
|
||||
作为计算平台上问题解决方案的方法论，软件学科需要阐明一些基本问题，这些基本问题的解决支撑了软件学科发展，即：可计算性理论，解决问题能不能在计算平台上求解的问题；算法设计与分析，解决问题能不能在计算平台上高效能行求解的问题；软件方法和技术，解决问题能不能有效控制复杂性；软件基础理论，解决软件能不能可信的问题。前两个问题解决问题的能行求解；第三个问题解决复杂性的工程控制方法；第四个问题评价获得的解是否符合价值观，达到目的。我们认为，作为问题求解的方法学，提高求解效能（单位成本的软件生产率和软件质量）是软件发展内在驱动力，而抽象和复杂性控制成为学科发展的核心要素。
|
||||
|
||||
从技术角度看，灵活、可变、适应性是软件不变的需求。软件在语言上追求更具表达能力；在方法上符合人类思维，易构造，易维护；在系统上更高效可靠。围绕抽象和复杂性控制，软件学科形成了从模式化、形式化、自动化到智能化的基本手段，由软件结构、开发结构和组织结构组成的工程模型走向开放化。
|
||||
|
||||
\subsubsection{学科方法}
|
||||
|
||||
从研究的角度，软件学科需要建立构造并在计算机上运行问题解决方案的科学和工程基础。从应用的角度，我们需要建立开发软件制品的方法和过程来高效和节约地构建软件系统。在软件学科中，基本方法可以归为三类，即理论方法、实验方法和设计方法。
|
||||
|
||||
\textbf{理论方法}
|
||||
|
||||
理论方法首先给出对象的定义描述，并假设它们之间可能的联系，通过证明来判断这些联系是否成立，并解释所得到的结果。源于以图灵机为代表的形式化计算模型的奠基性贡献，使得计算平台伊始便具有刚性的数学理论约束，使得数学天然地进入了计算机理论研究。通过建立形式理论、推理获得结果并解释结果，形成了软件作为数学对象来研究和开发的方法学。这种方法提供了开发模型和理解模型边界的分析框架，在软件正确性方面发挥了重要作用。理论方法根植于数学，将计算视作数学对象开展研究。
|
||||
|
||||
\textbf{实验方法}
|
||||
|
||||
实验方法或者建模属于实验科学方法。它首先形成基于假设构造一个模型，开发统计/量化方法，应用到案例上，度量和分析，来确认所提出的模型。这种模式是一种变革性的改进，例如提出一种新的方法和工具来完成软件开发。仅仅提出一种方法还不够，需要有度量和分析的方法来说明方法和工具较已有方法的先进性。实验方法根植于自然科学方法，源于科学假设，系统建立模型，验证并确认这些假设。与其他科学方法类似，实验手段中计算手段的引入使现代实验方法有了新的途径。对于软件科学的研究来也是这样，可以利用计算的手段开展软件的实验研究，包括用软件模拟软件的模型方法和用数据科学方法来研究软件及其环境的现象和方法。
|
||||
|
||||
\textbf{设计方法}
|
||||
|
||||
自然科学中理论方法和实验方法之外，人工科学的特有方法是设计方法，它着眼于为了解决一个问题来工程化构造一个软件。它的基本过程是表述需求、表述规约、设计和实现系统并测试系统。设计中不断对已有的软件解决方案观察，提出更好的解决方案，建立/开发、度量和分析，重复直到难以改进。这种模式是一种演进改进的方法，是一种模型改进的方法，关键在于仔细的分析和度量。设计方法根植于工程，源于面向问题，通过系统的设计过程来构造解决方案。
|
||||
|
||||
软件科学构成了人工科学的基础。其核心是模型抽象。以模型为数学对象，形成了软件学科的理论方面；从软件到软件模型，形成了软件学科的科学方面，从软件能否构造一个符合该软件系统的模型，并对软件开展预言；从问题、软件模型到软件，形成了软件科学的工程方面，面向问题获得求解模型并构造一个符合该模型的软件系统。上述三个方面在软件科学的研究中并不是正交的，往往会联合在一起共同解决学科问题。它们各自具体不可替代的作用，理论方法描述和揭示软件模型及对象之间的联系，实验方法可以运用这些联系来预言软件行为并与现实世界比较，设计方法则是通过这些联系的科学发现来设计完成解决方案。这三者的紧密联系也使得软件科学区别于数学、自然科学和传统工程科学。
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{举例}：基于大代码的软件自动生成方法就综合软件科学中的理论、实验和设计方法。程序综合是计算机科学的明珠。其理论研究是长期以来的科学问题。演绎推理的理论方法是其重要途径，形式规约开始构造一个正确的程序，自动定理证明和归纳综合是其基本思路，并逐步发展到了归纳推理。近来随着海量代码的累积，实验统计的方法逐步兴起，以实验方法从代码数据中学习，建立程序综合和推理的启发式预言有效地提高了综合效率。以归纳推理和统计推理相结合的程序综合设计方法成为了当前软件自动化研究的重要趋势，在代码自动生成、代码修复、人机协同编程等方面取得了重要进展。
|
||||
|
||||
\end{itemize}
|
||||
|
||||
\subsection{软件学科的基本架构}
|
||||
从目前的一级学科划分看，软件学科横跨了计算机科学与技术，软件工程、网络空间安全等三个一级学科。特别是，与计算机软件与理论二级学科和软件工程一级学科关系密切。
|
||||
|
||||
与本科生的计算教育学科相比，软件学科横跨了ACM/IEEE计算教程等五个学科，即计算机科学、计算机工程、软件工程、信息技术、信息系统。它们的覆盖关系如图1-X所示。
|
||||
|
||||
我们着眼于软件学科发展历程的回顾，重新梳理，就现状划分了三个子领域，程序设计语言与理论、系统软件、软件工程。其中，程序设计语言与理论的核心内容是建立抽象；系统软件的核心内容是实现抽象；软件工程的核心内容是使用抽象。它们与我国目前一级学科、ACM/IEEE计算学科的关系如图1-X所示。
|
||||
|
||||
软件强大的渗透性，使得软件和产业紧密相联，并产生了软件产业。软件的问题解决方案和人工制品特性、软件发展的外部驱动力决定了其形成产业的必然，而强大的产业需求不断地拉动软件的发展，软件学科与软件产业相互促进，共生共荣。
|
||||
|
||||
\section{本章小结}
|
||||
|
||||
本章通过梳理软件发展的脉络，指出了软件是以计算为核心手段实现应用目标和价值的解决方案。可编程是软件的基本特征，建立抽象、实现抽象和使用抽象是软件发展的主线。不断增长的应用需求和不断增强的计算平台构成了软件发展的外部驱动力，而控制复杂性、提高单位成本的软件生产率和软件质量是其发展的内在驱动力。软件作为最为复杂的人工制品，软件学科是以软件为研究对象，通过科学方法、实验方法和设计方法等途径，研究设计和使用软件及其规律的学科。
|
||||
|
||||
第一篇的后续几章分别介绍程序设计语言与理论、系统软件、软件工程、软件产业等方面进一步阐述学科领域的内涵和外延、关注解决科学问题，以及对应的发展历程，现状和存在的主要矛盾。目的是从各方面来阐述软件发展的学科特性，把握学科现状和发展规律，为展望学科的未来发展奠定理性思考的基础。
|
||||
|
||||
\section{参考文献}
|
||||
|
||||
\begin{itemize}
|
||||
\item [] [1]. Liskov \& Zilles. Programming with Abstract Data Types, ACM SIGPLAN Notices, 1974
|
||||
\item [] [2]. Floyd. The paradigms of programming, CACM 1979
|
||||
\item [] [3]. Watts S. Humphrey. Software Unbundling: A Personal Perspective. IEEE Annals of the History of Computing. 2002
|
||||
\item [] [4]. H.A. Simon. The Science of the Artificial. 1968
|
||||
\end{itemize}
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
% !TEX root = main.tex
|
||||
|
||||
\chapter{引言}
|
||||
|
||||
bla bla
|
||||
|
||||
\section{第一节标题}
|
||||
|
|
@ -0,0 +1,249 @@
|
|||
|
||||
\section{引言}
|
||||
|
||||
软件工程师在开发软件系统时，不可避免地要用到某种程序设计语言。顾名思义，程序设计语言是程序员用来描述程序行为的语言。在计算机科学领域，曾出现过数百种程序设计语言。TIOBE给出目前常用程序设计语言的流行度排序，从高到低有：Java、C、Python、C++、C\#、JavaScript、PHP等[23]。Sebesta[1]从高级语言机制的设计角度对程序设计语言进行了深入细致的介绍和比较。大多数新程序设计语言的创建都受以前语言概念的启发。较旧的语言仍然是新语言的坚实基础，而新出现的程序设计语言使程序员的工作变得更加简单。
|
||||
|
||||
程序设计语言的定义可分为语法、语义等方面。语义表示程序的含义，由静态语义和动态语义组成。静态语义指程序编译时可以确定的语法成分的含义；建立在转换/迁移系统上的动态语义则描述程序如何执行。
|
||||
|
||||
\section{程序设计语言}
|
||||
|
||||
在计算机发展的早期，人们往往是用二进制(0/1序列)给计算机发指令。这显然很不方便。后来，逐渐出现了汇编语言以及各种高级语言。一般来说，提高软件开发本身的效率与质量需要更抽象更高级的程序设计语言；而提高现实计算机硬件系统的利用率和执行效率，则需要使用较低级的程序设计语言，这样程序可以更直接地控制硬件资源。较通用的程序设计语言适用于广泛的应用领域和应用场景，可吸引大量的语言使用者，积累充足的遗产代码，便于培训与推广共享资源；但高度通用的语言设计上难以兼顾开发效率与执行效率。很多针对特定应用领域的程序设计语言更容易通过合适的语言机制同时改善软件开发与执行的效率。多样化的编程接口具有程序设计语言功能，但缺乏相应的编程框架甚至程序库等。这类接口反映了相应的编程模型的特点，实质上起到了程序设计语言的作用。
|
||||
|
||||
程序设计语言的发展既要遵循自身理论与模型的内在规律，也受到计算机系统发展的驱动和行业应用需求发展的推动。不同语言不同程度地受这些因素推动。但从程序设计语言发展历史角度看，应用需求的影响明显处于主导地位。新出现的程序设计语言通常是应对新兴应用或者新兴计算机体系结构的需要。
|
||||
|
||||
\subsection{语言的设计、实现及生命期}
|
||||
\subsubsection{设计}
|
||||
一般说来，程序语言的设计应该遵守以下原则：能够很容易的理解；能够清晰、准确地表达计算意图；确保程序不会导致意外；每种语言构造的组合都是合法的；相似的特点有相似的表示和行为；能够很容易发现错误并纠正；能够给用户提供加入新结构的机制；允许程序在不同机器和系统间的移植；能够编写对应的转换器或解释器。
|
||||
|
||||
语言设计在实践中有三个角度：从程序设计语言理论角度出发设计的语言如Pascal、Ocaml、X10等十分关注语言语义的清晰性、灵活性、简洁性，往往直接反映了理论领域的创新成果；从系统软件与体系结构角度出发设计的语言如图形处理器支持的CUDA，关注如何充分利用系统结构的特点来优化性能；从应用角度出发设计的语言如XML、PHP、Julia等关注与目标应用的契合度以及编程的便易性。
|
||||
|
||||
某些语言如数据库查询语言SQL简洁地表示数据表格间的代数关系，大幅简化了对数据库的查询；深度学习编程框架TensorFlow[5]、PyTorch等辅助编程者方便地生成神经网络结构并根据学习算法自动生成反向网络。这些语言或框架追求编程简单性，虽然简化了循环和递归这样的图灵可计算性的关键语句，但仍然反映了一定的程序设计模型。
|
||||
|
||||
\subsubsection{实现}
|
||||
|
||||
语言的传统实现方式分为从高级语言到机器代码的静态编译与直接对高级语言程序解释执行两种方式。如果存在中间语言，在不同层次分别可能采用不同方式混合实现，如避免在运行时的编译性能消耗和内存消耗的运行前编译(ahead of time，简称为AOT)与根据当前硬件情况实时编译生成机器指令的运行时编译(just-in-time，简称为JIT)。编译技术仍然是语言实现的关键技术。一方面类型检查等静态程序分析均在编译阶段实施，另一方面代码生成过程中的优化技术是对程序员屏蔽硬件复杂性的主要手段。
|
||||
|
||||
近年来，随着计算机系统结构的多样化和复杂化，程序设计语言出现了许多新的形式。例如，并行编程模型OpenMP使用预编译制导语句插在C或Fortran的代码中，描述了多线程并行。尽管OpenMP本身不具有完整的独立语法，但因为反映了与串行C语言不同的共享变量式并行编程模型，我们也可以称之为新的“语言”或者至少是新的“语言机制”。
|
||||
|
||||
通用语言的程序可以像OpenMP那样插入新的语言机制的语句，也可以反过来在新风格的程序中插入通用语言的子程序。这一方式在大数据处理编程框架MapReduce、Hadoop、Spark中得以应用，不仅简化了分布式并行数据处理编程，而且允许程序员设计灵活高效的程序用于数据处理。一些编程模型的实现甚至不引入任何新的语法扩展，仅仅以子程序库的形式出现。比如，科学计算中广泛使用的MPI由C和Fortran程序库实现，支持多种形式的消息传递通讯。
|
||||
|
||||
\subsubsection{发展}
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=0.80\textwidth]{fig1-2/2-1.png}
|
||||
\caption{常见程序语言的发展脉络
|
||||
\label{fig:2-1}}
|
||||
\end{figure}
|
||||
|
||||
自20世纪60年代以来的发展历程看，程序设计语言的抽象级别显著提高。历史上曾出现过将程序设计语言分为四代的提法：
|
||||
|
||||
\begin{enumerate}[1)]
|
||||
\item 机器语言：由二进制0、1代码指令构成，不同的处理器具有不同的指令系统。由于机器语言难编写和维护，人们已很少直接使用这种语言。
|
||||
\item 汇编语言：汇编语言指令可以直接访问系统接口。由汇编程序翻译成的机器语言程序效率高。但同样难以使用与维护。
|
||||
\item 高级语言：它是面向用户的，独立于计算机种类与结构。因此易学易用，通用性强，应用广泛。图\ref{fig:2-1}给出了常见高级程序设计语言的发展脉络，其中箭头指向的程序设计语言借鉴了前驱的设计思想。
|
||||
\item 非过程化语言：使用这种语言编码时只需说明“做什么”，不需描述算法细节。数据库查询语言是其中的一种，用户可以对数据库中的信息进行复杂的操作。
|
||||
\end{enumerate}
|
||||
|
||||
在程序设计语言发展最初阶段，程序设计语言按照主要编程范式，可以被归类为面向过程式的、面向对象式的、逻辑式的、函数式[22]的等。随着C++、C\#等语言的出现，传统分类之间的界限逐渐变得模糊。现代的编程语言往往具有若干种类编程语言的元素，这就是所谓的多范式编程语言。而多范式程序设计语言也是一个越来越明显的趋势。
|
||||
|
||||
一个成功的程序设计语言从探索到推广、接受和最终成为行业标准往往经历以下四个阶段：第一阶段，新兴应用与系统的软件开发在早期开发过程只能采用已有的程序设计语言配以一定的软件工程方法；第二阶段，为提高软件生产率，多种语言工具开始出现；第三阶段，行业标准的形成有助于积累遗产代码资源和培训与推广资源；第四阶段，随着大量遗产代码开始积累，行业商业模式成型，倾向于使用成熟的程序设计语言。分析程序设计语言所处的发展阶段有助于我们了解甚至预测其发展规律。
|
||||
|
||||
\subsection{应用驱动的程序设计语言发展}
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=0.80\textwidth]{fig1-2/2-2.png}
|
||||
\caption{程序设计语言的发展及分类}
|
||||
\label{fig:2-2}
|
||||
\end{figure}
|
||||
|
||||
这里以多个有代表性的典型语言为例，分析其应用背景、设计特点与发展规律，从而展现程序语言发展的现状、预测未来发展趋势。按照程序语言的类型与应用，图\ref{fig:2-2}给出了以时间为主线的不同类别语言的发展过程与分类关系。从不同角度来看，一种程序语言既可能属于系统编程语言，又是面向对象语言。从发展过程来看，一种语言在发展过程中会不断进行扩充，融入不同的范式，进而趋近于多范式语言。本节主要以应用驱动来组织。计算机产业的发展往往是新的产业应用从已有的应用模式中成长出来而不是取而代之。新语言的出现往往标志着信息技术在新的应用领域的扩张。
|
||||
|
||||
\begin{itemize}
|
||||
\item 科学与工程计算(1954~)
|
||||
\end{itemize}
|
||||
|
||||
早期计算机系统硬件结构简单，软件专用性强，主要用于核反应计算、密码破译这样专业性强的科学与工程计算领域，直接服务对象往往是政府与军工。1956年发布的Fortran语言标志着具有完整工具链的程序设计语言出现。Fortran语言符合典型的过程式语言的特征，由从事系统结构和系统软件的研究人员设计，采取编译的方式实现，反映了程序设计与计算机系统之间的紧密联系。尽管串行的科学计算软件开发方法已成熟，积累的大量遗产代码保证了Fortran这样的语言在其适用领域仍然具有生命力。
|
||||
|
||||
早期语言的准确语义往往依赖于编译器的实现，针对特定体系结构由编译器的开发者设计。1950年代末期出现了一些由计算机逻辑理论与程序语义研究者设计和实现的程序设计语言，如ALGOL和LISP语言。此后出现的大量函数式语言如Haskell、ML往往具有清楚而简洁的数学表示，设计出发点上更多地考虑如何优美地表示计算，但由于缺乏工业级应用的针对性以及性能上对常见体系结构的适配性，其接受范围受到限制。
|
||||
|
||||
科学与工程性质的计算，尤其是高性能计算往往与计算机体系结构密切相关，发展了多种形式的编程接口。OpenMP是共享内存的并行计算所常用的编程接口。其特点是在C或Fortran中插入指导语句，希望不改变原有串行程序语义的条件下利用共享存储器的多线程并行加速计算。MPI是跨平台的消息传递通讯程序库，完全不增加额外的语法机制。图形处理器语言CUDA在C基础上扩展了一些语法机制，用以区分在CPU、GPU上运行的程序片段，作出不同的编译。并行程序设计模型一直是程序设计理论研究的一个重点 。
|
||||
|
||||
\begin{itemize}
|
||||
\item 商用计算(1960~)
|
||||
\end{itemize}
|
||||
|
||||
信息技术的应用逐渐从专业领域扩展到广阔的商业领域信息化。COBOL语言的出现标志着商业化的事务处理如金融、财会有了强有力的语言技术支持。该时期计算系统往往是大型机或小型机服务器。COBOL拥有庞大的用户群，据称积累了超过2000亿行遗产代码\footnote{http://cobolcowboys.com/cobol-today/}。由于商业计算的多样性，一台大型机往往需要运行多种类型的软件，甚至同时并发地运行不同软件。这一时期开始，管理不同类型软件的操作系统得以发展。C语言可以直接处理系统资源，尤其适合系统软件开发。相比之下，同样是过程式语言的PASCAL语言则是由程序设计语言理论研究者设计的更加安全和规范的语言。数据库查询语言SQL是较早出现的领域专用语言。它不具有完整的程序设计语言功能，但可看成是针对关系数据库应用的编程模型。
|
||||
|
||||
随着商用计算而来的是软件大规模化。1960年代末出现了一系列旨在有效控制大规模软件开发过程复杂性的程序设计思想。面向对象的思想及其第一个语言Simula67试图对不同程序模块访问共享变量的方式进行限制，使得程序更加具有模块组装特性。Dijkstra提出避免使用GOTO语句的结构化程序设计思想[3]，对程序的控制流进行限制。
|
||||
|
||||
\begin{itemize}
|
||||
\item 人工智能(1960~)
|
||||
\end{itemize}
|
||||
|
||||
人工智能自诞生以来，广受关注。在该领域也出现了若干专用语言。人工智能有符号主义、连接主义等流派。
|
||||
|
||||
符号主义就是以符号逻辑系统为基础来表示知识。二十世纪七十年代，Robert Kowalski 等人提出了逻辑可以作为程序设计语言的基本思想，把逻辑和计算这两个截然不同的概念统一在一起。这就是逻辑程序设计(logic programming)，而Prolog语言就是典型的逻辑程序设计语言。对经典的逻辑程序设计语言，可以进行各种扩充。例如，将状态转移的控制机制引入到时序逻辑系统的XYZ/E是世界上第一个可执行的时序逻辑程序设计语言[9]。
|
||||
|
||||
连接主义的代表是试图模拟人脑的人工神经网络。近十年来，深度学习显示出了强大的学习能力和广泛的应用前景。TensorFlow、PyTorch等工具针对深度神经网络学习算法的特点，利用高级语言展开生成神经网络结构然后以高性能方式运行学习算法。这些多样的领域特定语言工具不具备完整的通用程序设计语言功能，但十分适合特定的应用场景。
|
||||
|
||||
\begin{itemize}
|
||||
\item 个人计算与系统编程(1981~)
|
||||
\end{itemize}
|
||||
|
||||
在摩尔定律背景下，计算机硬件系统的价格不断下降，个人使用计算机的情形越来越普遍。随个人计算而来的是软件的多样化，应用形式从事务处理和业务处理扩展到教育与娱乐。软件的开发与销售形式从硬件捆绑式发展到专业软件企业发行软件拷贝的销售形式。软件开发团队与人员的数目大量增加。C++是C语言的面向对象扩展，逐渐成为实施传统软件工程的主流语言。
|
||||
|
||||
作为一种新的多范式语言，Rust不仅能够提供友好的编译器和清晰的错误提示信息，而且速度快、内存利用率高，同时具有丰富的类型系统保证内存安全和线程安全。目前从初创公司到大型企业，已有很多公司都在使用 Rust，应用范围不仅包括嵌入式设备，也包括可扩展的 Web 服务。
|
||||
|
||||
\begin{itemize}
|
||||
\item Web服务与移动计算(1990~)
|
||||
\end{itemize}
|
||||
|
||||
伴随互联网的出现，Web服务软件一改拷贝销售形式，直接通过互联网向终端用户提供服务。其服务形式多样，方式多变。服务的反应速度往往受限于互联网的带宽与延迟，而不是计算的速度。因此，客户端与服务器端交互程序设计语言重点关注软件的开发效率，而不是程序的性能。典型的支持此类应用的脚本语言如JavaScript、PHP已然形成工业标准。
|
||||
|
||||
1990年代后智能手机的出现与普及将计算拓展到个人随身携带的新模式。一些为Web服务设计的语言仍然适用，但新的应用形式也带来了新的挑战。许多项目需要同时以网页、平板以及智能手机形式提供服务。由于应用需求与服务逻辑的易变性，软件的任何更新希望在不同平台上一致地更新。针对这些挑战，出现了新的语言如HTML5。它们不仅需要支持复杂的功能，还需要解决跨平台、跨设备、跨操作系统兼容可移植的难题。
|
||||
|
||||
\begin{itemize}
|
||||
\item 大数据分析与处理(2004~)
|
||||
\end{itemize}
|
||||
|
||||
平台系统的大规模数据分析与处理需求，首先来自于互联网的搜索服务。其特点是大量采集的数据需要多台服务器的集群通过并行计算高速处理。分布式并行计算带来了性能优化与可靠性的挑战。但是，在平台建设期无法预知随时可能出现的各种数据分析需求。应用开发人员需要随时针对应用需求快速、灵活地编程，而不必为系统级的性能与可靠性问题所困扰。
|
||||
|
||||
设计易用而且高效的并行程序设计语言，是数十年来计算机科学的一个难题。2004年谷歌公司发布MapReduce[1]，标志着工具化的大数据编程框架出现。其设计思想是将数据集的操作限制为并行函数式语言中最基本和常用的Map和Reduce两个命令。对个体数据项的处理由应用开发人员使用C和Java这样的通用语言来编程，而数据集层次的操作由担任分布式操作系统角色的运行时系统负责执行。Hadoop和Spark是基于MapReduce的主要开源工具。尽管此类语言工具不具有独立的语法系统，但其功能和语义直接反映了并行函数式语言与过程式语言混合的编程模型，实质上起到了程序设计语言的作用。
|
||||
|
||||
增加语言的专用性有助于在保证易编程性的前提下优化性能，但如果一个编程模型不能涵盖同一应用领域多种相互联系的计算需求，其专用性会影响行业标准的形成。基本的Map与Reduce命令还不能涵盖一般的并行计算步骤的数据依赖关系。
|
||||
|
||||
\begin{itemize}
|
||||
\item 互联网金融(2009~)
|
||||
\end{itemize}
|
||||
|
||||
以软件为核心的互联网金融指的是以互联网为载体的金融服务形式，而并非仅仅将互联网作为连接客户的信息系统。开源软件技术主导的金融服务形式始于2009年出现的第一个数字货币--比特币。数字货币以去中心化共识的区块链记账技术为基础，提供类似法定货币的金融功能，具有特殊的金融服务属性。以太坊数字货币扩展了记账技术，支持区块链中记录完整的程序并以可验证的方式执行这样的程序：合同即是程序，程序即是合同。这就是所谓的智能合约(smart contract)。Solidity是目前最流行的合约编程语言。Solidity语法类似于JavaScript，支持继承、类和复杂的用户定义类型，通过编译的方式生成以太坊虚拟机中的代码。
|
||||
|
||||
\section{程序设计语言及相关理论}
|
||||
程序设计语言都具有语法和语义。同时，程序的行为可以描述为状态的转移过程。这里将讨论程序设计语言的语法与语义基础，并给出保证程序正确性的分析方法。
|
||||
|
||||
\subsection{类型论}
|
||||
在很多程序设计语言中，变量与数据是带类型的；而类型之间有一定的关联。人们在研究程序设计语言理论时，可以借鉴类型论(type theory, 也称“类型理论”)来研究程序语言的类型系统。类型论是数理逻辑中的一个分支，其中的马丁洛夫类型理论用规则来刻画类型及行为，是程序构造的形式理论。类型理论研究的是程序语言的类型系统，用于定义如何将编程语言中的数值和表达式等短语归类为许多不同的类型，如何操作这些类型，这些类型如何互相作用。类型通过预测程序部件的某些执行行为来协调这些部件间的交互。在类型化的程序语言中，语言构造分为引入和消去两种形式。类型的引入形式确定该类型的值或范式，而消去形式则确定如何操作该类型的值以形成另一种（可能是相同的）类型的计算。例如，可以使用类型系统中的归纳类型定义如自然数、表、树等数据结构；使用多态类型处理程序的特定型与参数型这些不同的输入类型；使用记录类型定义一组记录的命名类型等；自然数类型的引入形式是自然数，消去形式是加法和乘法等。
|
||||
|
||||
\subsection{形式语言}
|
||||
程序设计语言都有自己的词法和语法，而词法和语法的定义是一系列规则的集合，这些规则的基础就是形式语言。文法是形式语言中十分重要的基本概念，是定义描述语言的语法结构的一组形式规则。文法有四种分类，其中最常用的为正则语言和上下文无关语言。正则语言可以用正规式定义，上下文无关语言可以用上下文无关文法(元素和规则的集合)定义。程序设计语言中的大多数算术表达式可用上下文无关文法生成。正则语言是最简单的语言类，是上下文无关语言类的一个真子类。正则语言已应用于计算机程序语言编译的词法分析、开关电路设计等方面。对程序设计语言编写的程序进行分析和处理(编译)时，需要判断对应的句子是否合法，可以通过对应语言的自动机进行判断。自动机是语言的另一种表示方法。其中，正则语言可以转换成有限状态自动机、上下文无关语言可转换成下推自动机表示，反之亦然。针对某种特定输入的一系列有限的规则，对不同的输入的元素，自动机依据自身的状态会做出不同的响应，最后达到某种特定的状态。
|
||||
|
||||
\subsection{形式语义学}
|
||||
给定一个程序，如何判断它是否正确？这是很早以前人们就关注的问题。简单来说，如果一个程序恰当地实现了设计者与用户的意图，它就是正确的。严格意义上，程序的正确性[6]需要数学证明，不仅需要形式描述设计者与用户的意图，而且要形式描述程序的含义，并推导程序的行为满足设计者与用户的意图。程序含义的形式化描述就是形式语义学。基于形式语义，不仅可以构建描述程序含义的基础，还可以用于验证程序的正确性。
|
||||
|
||||
程序设计语言的语法是符号化的，语义是该语言程序所描述的计算或过程。根据语义，程序设计语言的解释器或编译器可以将该语言程序编译成计算机可处理的机器语言程序。在程序设计语言的早期，人们使用自然语言解释语义。这种自然语言解释的语义不精确、有歧义，无法分析和证明程序的正确性。为了提高程序设计语言的可理解性、支持语言标准化、指导语言设计、辅助编译器开发、证明程序的性质和程序之间的等价性，需要对程序设计语言的语义进行抽象，给出严格的定义。为此，人们开始研究使用数学结构定义程序设计语言的语义，并扩展出各类形式规约(specification)语言[19]，形成了形式语义学[8]。
|
||||
|
||||
\begin{itemize}
|
||||
\item 操作语义
|
||||
\end{itemize}
|
||||
程序运行中变量赋值的变化、行为的变迁可以通过操作语义进行描述。操作语义(operational semantics)将语言中各个成分翻译成计算机系统中相应的一组操作。目前最为常见的操作语义是标号迁移系统(labeled transition system)，将程序执行描述成标号迁移系统，其中的状态是程序执行期间任意时刻观察到的变量取值。迁移规则规定如何从一个状态转换到下一个状态，每条迁移规则对应一个语句，称为标号。一条语句的语义由一组以其为标号的规则定义；标号规则具有组合性，即一个复合语句的规则可以由其成分语句的规则组合而成。例如，针对一个C程序中的循环语句while(x<y) do{x++;}的操作语义为：
|
||||
\lstset{language=C}
|
||||
\begin{lstlisting}
|
||||
loop: if (x>=y) goto out;
|
||||
if (x<y) { x=x+1; goto loop}
|
||||
out: …
|
||||
\end{lstlisting}
|
||||
其中，loop、out是标号，从loop到loop、loop到out是描述程序执行的迁移系统中的迁移规则。
|
||||
|
||||
在由操作语义描述的串行程序的语义中，状态是一些简单的数据结构，迁移规则一般都是确定的、离散的，也不需要考虑标号间的通信和同步。为了定义复杂程序的操作语义，例如面向对象程序、并发程序、实时程序、概率程序、混成系统等，人们对迁移系统进行了各种扩充，或扩充它的状态，或扩充它的迁移关系，亦或两者同时扩充。例如，为了定义面向对象程序，人们对程序状态进行扩充，引入堆和栈等复杂数据结构；为了处理并发程序，人们对标号迁移关系进行扩充，使用标号描述通信和同步；为了描述概率和随机程序，允许以给定的概率或者随机选取迁移规则等。
|
||||
|
||||
基于抽象机的操作语义可描述实现方面的执行细节，操作性比较强，适合于语言编译器的开发与编译的优化。操作语义中的状态是显式的、可操作的。因此，在基于状态搜索的模型检验方法中，操作语义比较适合描述模型的语义，即状态的变化序列。然而，抽象机上的推理系统比较弱，不易对大规模或无穷状态的系统进行基于演绎推理的形式验证。
|
||||
|
||||
\begin{itemize}
|
||||
\item 公理语义
|
||||
\end{itemize}
|
||||
程序的语义不仅可以使用操作语义描述，还可以使用形式逻辑来描述。而形式逻辑是公理语义(axiomatic semantics)的基础。公理语义直接使用形式逻辑来描述程序的语义，在已有的形式逻辑系统基础上增加所有程序必须满足的基本命题(程序公理)。动态逻辑、模态逻辑、时序逻辑等用来作为定义程序公理语义的形式系统。每个程序的基本语句都有一组公理和推理规则，它们与断言逻辑一起构成程序逻辑的证明系统。例如，若条件语句if(y==1) then x=1; else x=2的前置条件为{y==1}，则该语句执行后，后置条件为{x==1}。在该形式系统中可以直接进行程序性质的规约和验证。程序逻辑的表达能力、可靠性、完备性以及可判定性都可归结为数理逻辑上的元性质，程序逻辑的解释模型通常就是程序设计语言的指称语义或操作语义。
|
||||
|
||||
常见的形式逻辑有基于一阶逻辑扩展的Floyd-Hoare 逻辑[15]、谓词转换器(predicate transformer)等。其中，Floyd-Hoare 逻辑最初是面向串行程序的，并扩展至并发程序、实时系统、混成系统甚至量子系统等。针对指针程序和面向对象程序，产生了分离逻辑及其变种，从而把Floyd-Hoare 逻辑的应用推进到实际的程序验证。公理语义在形式验证中的应用是比较多的。
|
||||
|
||||
\begin{itemize}
|
||||
\item 代数语义
|
||||
\end{itemize}
|
||||
面向对象程序设计语言具有抽象数据类型、多态性等特点。在抽象数据类型的基础上发展起来的代数语义(algebraic semantics)，用代数方法研究计算机语言的语义。它把程序设计语言形式地定义为满足某种公理体系的抽象代数结构，然后利用这种代数结构的性质来证明用该语言编写的程序的正确性。
|
||||
|
||||
抽象数据类型将数据对象及对象上的操作封装、数据类型的特性与实现分离，具有模块化和可复用的性质。它与软件开发过程匹配比较自然，因此也可以用于程序的自动构造：首先设计较小的抽象数据类型，然后逐步扩充形成较大的抽象数据类型体系；这个过程中，抽象数据类型间可讨论层次一致和充分完备等性质。
|
||||
|
||||
\begin{itemize}
|
||||
\item 指称语义
|
||||
\end{itemize}
|
||||
指称语义(denotational semantics)关注代表程序所做所为的数学对象，用数学对象上的运算来定义语言的语义。建立指称语义首先要确定程序设计语言的解释域(论域理论)。论域理论是指称语义的数学基础，讨论各种语言成分的指称(意义)的数学结构，并在各种数学结构之上定义语言语义，推导语言成分特性。例如，将程序设计语言的基本语法实体的指称定义为程序状态空间上的函数和泛函，复合语法实体的指称由构成它的子成分的指称复合得到。基于指称语义的相关理论，可以推导不同语言形式语义间的关系，也可以分析同一语言不同语义间的转换关系。其中，基于一阶关系演算的程序统一理论(unifying theories of programming，简称UTP)，可以通过伽罗瓦连接(Galois connection)给出同一语言不同语义间的转换关系。
|
||||
|
||||
除了这几类经典的语义，近期由Grigore Rosu提出的K框架提供了基于重写的语言[21]，用于定义编程语言的正式操作语义。K语言的语义是可执行的。结合K语言语义及相应的逻辑推理过程，可以分析和验证各种程序，而无需为语言提供任何其他语言（公理或指称或动态等）语义。
|
||||
|
||||
\subsection{形式规约}
|
||||
直接使用程序设计语言及其语义，难以描述和证明软件从需求文档到程序代码的开发过程各阶段创建的不同抽象层次的制品及其正确性。针对这一问题，人们开始研究高层抽象的形式规约语言的设计。形式规约语言是指由严格的递归语法规则所定义的语言，满足语法规则的句子称为合式或良构(well-formed)规约。形式规约可以自顶向下逐步精化形成开发的规约序列，在足够的实现细节完成后，可以通过代码自动生成得到程序。以形式规约语言为基础的形式化开发方法，有VDM、Z、Event-B、RAISE、CafeOBJ、TLA、SOFL等。20世纪七十年代后，软件工程界认识到数学可以为程序正确性保证提供技术基础。相应的出现了一系列程序设计理论框架。例如，八十年代初，唐稚松提出以时序逻辑作为软件开发过程的统一基础，并着手建立XYZ系统[9]。Goguen 和Burstall提出了一种抽象模型理论，以实现不同形式逻辑基础上的各种形式化方法的理论统一、技术和工具的集成与使用[10]。Hoare和何积丰提出了统一程序设计理论框架UTP，提供了在一种程序(如串行程序)语义模型理论基础上构建扩展程序(如并发)的语义理论，从而保证原来的理论在扩展的理论中能够重用[11]。
|
||||
|
||||
基于程序逻辑系统的性质规约刻画了所期望的系统行为，这些性质是通过逻辑公式来描述的。
|
||||
|
||||
串行程序设计早期的程序逻辑是Floyd-Hoare逻辑。通过在一阶谓词系统基础上添加关于程序的公理和推理规则，构成了Floyd-Hoare 逻辑的推理系统。类似的规约语言还有Dijkstra 的卫士命令语言的最弱前置条件演算。然而，早期的基于Floyd-Hoare 逻辑的推理系统无法描述带指针和内存数据结构的程序规约，也无法描述并发程序的规约。分离逻辑是对Floyd-Hoare 逻辑的扩展，以支持带有指针和内存数据结构的程序的验证。分离逻辑最大的特点是对内存和数据结构的抽象描述，能够更方便、更模块化地支持类似C程序的指针程序的验证。它在断言语言中引入方便描述内存使用和分离特性的分离合取和分离蕴含谓词，并在规则中将Floyd-Hoare 逻辑的不变式(invariance)规则替换为框架(frame)规则。
|
||||
|
||||
并发程序的规约在Floyd-Hoare 逻辑的基础上，引入了行为轨迹的变量或不变式。与分离逻辑类似，并发分离逻辑也支持并发程序验证。后续有大量工作对并发分离逻辑进行扩充，例如将Rely-Guarantee 和并发分离逻辑结合，从而支持细粒度并发或者无锁并发程序的规约和验证。除了这些针对串行一致性内存模型上的并发程序的程序逻辑外，还有一些工作对并发分离逻辑进行扩展，以支持弱内存模型下的并发程序。例如，在C11 内存模型上的程序逻辑(如文献[13])， 来证明C11 内存模型(子集)上的程序的正确性。
|
||||
|
||||
Floyd-Hoare逻辑中，程序与断言是分离的，而且也无法表达活性。针对这些不足，相继出现了基于模态逻辑的动态逻辑、基于动态逻辑的模态$\mu$-演算[14]。作为模态$\mu$-演算的真子集，线性时序逻辑(LTL)和计算树逻辑(CTL)是并发系统规约和验证的常用语言。除了这些经典的逻辑，还有用于数理逻辑计算和并发系统正确性验证的动作时序逻辑(TLA)、用于有限序列中命题与一阶逻辑推理的区间时序逻辑(ITL)。为了处理一些非功能性质，还出现了各种扩充，如微分动态逻辑、度量时序逻辑(MTL)、时段演算(DC)等。
|
||||
|
||||
\section{程序正确性分析方法}
|
||||
程序的正确性分析存在不同的方法。如图\ref{fig:2-3}所示,程序的正确性分析过程可以通过构建程序需满足的性质到规约的映射，程序行为与形式语义的映射，再使用相应的形式化分析方法实现。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=0.50\textwidth]{fig1-2/2-3.png}
|
||||
\caption{程序的形式化分析方法
|
||||
\label{fig:2-3}}
|
||||
\end{figure}
|
||||
|
||||
\subsection{基于验证的分析方法}
|
||||
定理证明、模型检验是形式化验证的两种主要方法，并逐渐被IT产业界所接受和采纳。例如，使用形式化验证工具如Z3、SLAM等，分析软件的正确性；基于分离逻辑的验证工具Infer用于Android应用的开发过程中；使用SMT求解器去验证Web服务的正确性；使用定理证明辅助工具来验证操作系统内核的正确性和安全性。
|
||||
|
||||
\begin{itemize}
|
||||
\item 定理证明
|
||||
\end{itemize}
|
||||
|
||||
基于定理证明的验证大部分是以程序逻辑为理论基础的。除此以外，我们还可以基于程序的操作语义，直接表达程序执行的安全性、正确性等各种性质，并证明相关定理。
|
||||
|
||||
对串行程序进行验证，可以通过一组与程序设计语言语句对应的Floyd-Hoare逻辑公理和规则，将对程序的验证转化为一组数学命题的证明。基于这种逻辑，一方面的工作通过并发任务的无干扰性(non-interference) [12]、并发任务间接口的抽象[17]、程序逻辑的化简[16]等不同方面，实现并发程序的验证。另一个方面的工作使用关系型程序逻辑验证两个程序之间的关系，或者一个程序在两种输入下的行为之间的关系。前者可用于程序精化的验证，而后者则可用于信息安全性质，如信息流控制(information flow control)机制的验证。
|
||||
|
||||
基于定理证明的验证可以分为两类，即基于自动定理证明器的自动验证和基于人机交互的半自动验证。常见的程序自动证明器(program verifier)，如Dafny、Why3、VeriFast、Smallfoot等，大多都基于某种具体的程序逻辑。给定程序及其规约，证明器能够自动决定针对程序的每条语句使用程序逻辑中的何种公理或规则，并产生相应的验证条件作为证明义务。最终，由定理证明器完成对验证条件的证明。目前使用最广泛的定理证明器是Z3，其他常见的证明器还包括CVC4、Yices 2等。基于人机交互的半自动验证工具，如Coq和Isabelle/HOL等，利用类型系统和逻辑之间的Curry-Howard同构关系[1]，将构造证明的过程转化为编写程序的过程，而证明的正确性检查也变成了类型检查问题。这种方法的优点在于无需牺牲规约和代码的表达能力，程序规约可以用表达能力很强的逻辑(如在Coq 和Isabelle/HOL 中使用的高阶逻辑)来表示。而且证明自身在机器中有显式表示，其正确性可以被自动检查，因此无需依赖自动定理证明算法的正确性，验证的结论也就更加可信。seL4的ARM版本是第一个带有完整代码级的功能正确性证明的通用操作系统内核，可以应用于金融，医疗，汽车，航空电子设备和国防部门。它的验证使用了Isabelle/HOL定理证明，这意味着通过形式化方法证明了实现(用编写C语言)是满足其规约的。除了对程序的验证，还有对编译器的验证，保证程序从编写到产生的可执行程序的正确性。例如，适用于C99编程语言的大部分语法的CompCert是一个经过正式验证的优化编译器，支持PowerPC、ARM、RISC-V、x86和x86-64架构。
|
||||
|
||||
\begin{itemize}
|
||||
\item 软件模型检验
|
||||
\end{itemize}
|
||||
模型检验通过自动遍历系统模型的有穷状态空间，来检验系统的语义模型与其性质规约之间的满足关系。软件系统属于无穷状态系统，即使状态有穷，其状态空间规模通常远超当前计算机可处理的范围。在硬件系统模型检验取得巨大成功的时候，软件模型检验所面临严俊的挑战。对于无穷状态系统，符号化可达性分析可能不终止。软件模型检验的核心问题是如何建立可检验规模的软件模型(抽象)。一种方法是采用上近似(over-approximation或下近似(under-approximation)对模型进行抽象，另一种方法是使用限界模型检验，将模型空间爆炸涉及的参数(例如循环次数、并发数等)限制在一定范围内，验证系统模型在此深度内是否满足系统规约。在软件模型检验中，利用静态分析、符号执行等方法抽取程序模型，以及基于路径的模型检验等静态和动态结合的方法，也是有效提高模型检验扩展性的重要途径。近年来，将模型检验与定理证明有效地结合也是一个有前景的方向。
|
||||
|
||||
\subsection{程序的自动综合}
|
||||
按照某种形式规约表达的用户意图，程序综合能够使用指定的编程语言自动生成符合规约的程序代码。程序综成器通常在程序空间上执行某种形式的搜索，以生成与各种类型一致的程序约束(例如输入输出示例，演示，自然语言，部分程序和断言)。程序综合是编程理论中最核心的问题之一[20]。早期的想法是通过组合子问题生成带有证明的、可解释的实现。一个分支是使用定理证明器首先证明用户提供的规约，再使用这个证明提取相应的程序逻辑。而另一个较为流行的方法是从一个高层规约开始，不断的进行转换，直到实现目标程序。近期的程序综合方法中，用户提供规约的同时，还可以提供目标程序的语法。这样使得基于语法结构进行的综合过程更加高效，得到的程序的可解释性更高。
|
||||
|
||||
\subsection{程序的精化}
|
||||
程序精化是将抽象（高级）形式规范可验证地转换为具体（低级）可执行程序的过程，是通过逐步细化分阶段完成。精化（Refinement）是一种数学表示法和若干规则的集合，它对Dijksart的卫式命令语言进行扩充，通过结合规约语句、精化规则和语言本身，从程序规约推导出命令式程序。程序精化(程序规约转换成可执行代码)可分为数据精化和算法精化两种，形式化将程序逐步转换为更加便于实现的形式：数据精化把抽象的数据结构转换为可以高效实现的形式；算法精化将程序逐步转换为更加便于实现的代码形式。
|
||||
|
||||
\section{小结}
|
||||
开发软件，离不开程序设计语言。本章简要介绍了若干典型的程序设计语言。在计算机发展的不同阶段，为了应对一些典型应用，这些语言应运而生。本章还介绍了几类形式语义。它们有助于清晰地表达程序的含义，可用于验证程序的正确性。
|
||||
|
||||
\section{参考文献}
|
||||
|
||||
\begin{itemize}
|
||||
\item [] [1]. Sebesta R.W. Concepts of Programming Languages. (7th ed.) Pearson, 2006.
|
||||
\item [] [2]. Bergin T. J. A history of the history of programming languages. Comm. ACM 50(5): 69-74 (2007)
|
||||
\item [] [3]. Dijkstra E.W. Go To Statement Considered Harmful. Communications of the ACM. 11(3): 147-148, 1968.
|
||||
\item [] [4]. Lämmel R. Google's MapReduce programming model — Revisited. Science of Computer Programming. 70: 1-30, 2008.
|
||||
\item [] [5]. Abadi M. et al. TensorFlow: A System for Large-Scale Machine Learning. Proc. OSDI 2016: 265-283.
|
||||
\item [] [6]. Turing A. Checking a large routine. Report of a Conf. on High Speed Automatic Calculating Machines, Cambridge University Math. Lab., 1949. 67~69.
|
||||
\item [] [7]. Roscoe AW. Understanding Concurrent Systems. Springer-Verlag, 2010.
|
||||
\item [] [8]. 周巢尘，詹乃军. 形式语义学引论(第二版). 科学出版社, 2018.
|
||||
\item [] [9]. 唐稚松等. 时序逻辑程序设计与软件工程. 科学出版社, 2002.
|
||||
\item [] [10]. Goguen JA, Burstall RM. Institutions: Abstract model theory for specification and programming. Journal of the Association for Computing Machinery, 1992,39(1):95-146.
|
||||
\item [] [11]. Hoare CAR, He J. Unifying Theories of Programming. Prentice Hall, 1998,14:184-203.
|
||||
\item [] [12]. Owicki S, Gries D. An axiomatic proof technique for parallel programs I. Acta Informatica, 1976,6(4):319-340.
|
||||
\item [] [13]. Svendsen K, Pichon-Pharabod J, Doko M, Lahav O, Vafeiadis V. A separation logic for a promising semantics. In: Proc. of the European Symp. on Programming. Springer-Verlag, 2018. 357-384.
|
||||
\item [] [14]. Kozen D. Results on the propositional mu-calculus. Theoretical Computer Science, 1983,27(3):333-354.
|
||||
\item [] [15]. Hoare CAR. An axiomatic basis for computer programming. Communications of the ACM, 1969,12(10):576-580.
|
||||
\item [] [16]. Owicki S, Gries D. Verifying properties of parallel programs: An axiomatic approach. Communications of the ACM, 1976,19(5):279-285.
|
||||
\item [] [17]. Jones CB. Tentative steps toward a development method for interfering programs. ACM Trans. on Programming Languages and Systems, 1983,5(4):596-619.
|
||||
\item [] [18]. Howard WA. The formulae-as-types notion of construction. To HB Curry: Essays on Combinatory Logic, Lambda Calculus and Formalism, 1980,44:479-490.
|
||||
\item [] [19]. 王戟,詹乃军,冯新宇,刘志明.形式化方法概貌.软件学报,2019,30(1):33-61
|
||||
\item [] [20]. Amir Pnueli and Roni Rosner. On the synthesis of a reactive module. In POPL, 1989:179–190.
|
||||
\item [] [21]. Roșu, Grigore. From rewriting logic, to programming language semantics, to program verification. Logic, Rewriting, and Concurrency. Springer, Cham, 2015. 598-616.
|
||||
\item [] [22]. Hu Z, Hughes J, Wang M. How functional programming mattered, National Science Review, Oxford Journal, 2015, 2(3):349-270.
|
||||
\item [] [23]. https://www.tiobe.com/tiobe-index/
|
||||
|
||||
\end{itemize}
|
||||
|
|
@ -0,0 +1,253 @@
|
|||
|
||||
|
||||
\section{系统软件概述}
|
||||
系统软件是驱动下层计算资源有效运转、为上层应用提供共性支撑的软件，主要包括操作系统、编译系统、中间件和数据库管理系统。其中，操作系统负责管理计算系统软硬件资源、操纵程序运行，为应用软件提供公用支撑；编译系统（又称编译器）负责将源语言编写的源程序翻译为等价的可运行目标程序；中间件将系统软件的概念扩展到网络环境，为分布式应用软件部署、运行和管理提供支撑；数据库管理系统旨在统一管理和维护数据库中的数据，是存储、组织、联接、变换和加载数据的软件。
|
||||
|
||||
与面向特定领域、解决特定问题的应用软件不同，系统软件是运行于计算“系统”层面上的软件。此处的“系统”有两层含义：
|
||||
|
||||
\begin{itemize}
|
||||
\item 系统软件将计算系统的概念从硬件扩展到了软件层面。通过将底层硬件资源进行适当地抽象和封装，系统软件为上层应用提供了一个软件平台（也可以称为“虚拟机”），使得上层应用软件可以方便使用各类资源能力，无需关注底层细节。这一平台承担了共性的资源管理功能，屏蔽了异构性和细节，使得计算系统易于使用、易于编程。系统软件作为平台化基础设施，同时也封装了许多共性问题的解决方案，以避免应用软件去“重复发明轮子”。
|
||||
\item 系统软件是驱动计算系统有效运转的控制器/协调者。系统软件一方面与计算系统中各类硬件资源直接交互，管理、调度和使用这些资源，使得之可以高效协同；另一方面系统软件也直接操纵管控上层应用的运行，从而达到提高程序装载和调度的自动化程度、提高资源利用率等目标。例如，操作系统可以通过批处理、分时共享等方法来实现计算系统作业任务切换，因此早期也被称为“监督例程”（Supervisory Program）或“控制程序”[1]。
|
||||
\end{itemize}
|
||||
系统软件并不是与计算机一起诞生的，它的出现有内因和外因两个方面。早期的计算机（如ENIAC）编程采用接线和开关等手工操作方式，并没有系统软件的概念。即使在存储程序计算机出现之后，系统软件也并未马上出现，应用直接在裸机上运行。但是，将应用与硬件祼机直接绑定，无论是运行效率、编程难度还是场景复用能力都十分低下。系统软件通过维护一个“虚拟机”来解决这一问题，它一方面通过对资源和应用的操纵控制，承担起计算机硬件资源管理功能，另一方面也通过封装与抽象，使得应用软件更加易于编码实现和加载运行。系统软件出现的外因则是软件复杂性增长所导致的分工细化，特别是上个世纪50-60年代，面向底层硬件资源的系统程序设计（System Programming）和面向领域的应用程序设计（Application Programming）的分化，以及系统程序员和应用程序员的分工，直接推动了系统软件这一概念的广泛接受。
|
||||
|
||||
\section{操作系统}
|
||||
从功能定位的角度而言，操作系统是负责管理硬件资源、控制程序运行、改善人机界面和为应用提供支持的系统软件，是计算机软件生态链的基础核心。在一个计算系统中，操作系统向下是最靠近硬件的一层软件，它通过调用硬件驱动程序、固件等方式实现对硬件的管理；向上屏蔽硬件细节，为应用软件提供功能更为完善、灵活可编程的“虚拟机”，并通过事件循环等实现对各类应用软件的运行管理。因此，操作系统兼具“承上启下”和“管家”两类作用。由于操作系统的特殊地位，其发展与上层应用需求和底层硬件形态的演化都有着密切联系。从最初与硬件和应用场景高度绑定，到之后逐渐独立于硬件，操作系统向上提供的服务越来越多、向下针对硬件的抽象程度越来越高，其内涵和外延不断拓宽，并在积累一段时间后产生质变，表现出大约每隔20年一次的跨越式发展的周期律（“主机-个人计算-互联网和移动计算”，图\ref{fig:3-1}）。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=0.80\textwidth]{fig1-3/3-1.png}
|
||||
\caption{操作系统发展历程
|
||||
\label{fig:3-1}}
|
||||
\end{figure}
|
||||
|
||||
\subsection{操作系统的出现（20世纪50年代）}
|
||||
早期的存储程序计算机并没有操作系统，需由用户或专门操作人员（Operator）管理计算任务，包括装入打孔卡片或纸带、通过包含开关和指示灯的控制面板来了解状态、在出错时进行必要干预等。这一方式可以满足早期少量科学计算的需要。但是随着计算机应用领域从传统科学计算领域向国防、政府、商业等通用领域拓展，计算任务及相关的数据量迅速增长，手工管理成为了制约计算机利用效率的瓶颈问题。用软件来代替操作人员实现计算任务自动管理（包括载入和执行），这是操作系统最早出现的动因之一，并直接催生了第一代的批处理操作系统。由于其强调替代人进行监管，这一时期的操作系统雏形多被冠以“控制程序/例程”（Control Program/Routine）、“管程”（Monitor）、“监督例程”（Supervisory Routine）等名称。典型实例是通用汽车与北美航空于1956年基于IBM 704所开发的GM-NAA IO系统[3]，其核心的管程可以从磁带上自动顺序读入和批量执行应用程序。该系统通常被认为是第一个成熟的商用操作系统，在20世纪50年代末被移植到多个巨型机上。
|
||||
|
||||
操作系统出现的另一个背景是20世纪 50年代计算机技术的革新，特别是磁芯内存、磁带等大容量高速存储技术的应用，以及从早期打孔卡片发展而来的“文件”等抽象的出现，使得专业化的大型软件成为可能，软件开发作为一个独立行业开始从硬件设计制造中分离出来。人们针对“如何提高软件开发的效率”这一问题进行初步探索，催生了Fortran等高级语言的出现，也在这一过程中积累了大量工具、编译器、可重用例程和库等。由于软件开发与运行密切相关，因此在这一时期，许多操作系统与编程系统并未严格区分，典型实例包括MIT的CSSR（Comprehensive System of Service Routines）[4]、ERA 1103（UNIVAC 1103A）计算机所配备的“集成计算系统”[5]等。这类系统通常具备运行时批处理功能，但更强调对开发的支持，其核心是一系列可重用库和辅助工具（Utility Tool）。这也是今天操作系统“沉淀共性问题解决方案”能力的来源。
|
||||
|
||||
虽然第一代操作系统以批处理模式为主，但由于指挥控制、工业自动化等领域对计算机的迫切需求，早期人们即在实时（或者至少能够在线处理的）操作系统方面开展了实践。典型案例是上个世纪50年代美国军方半自动地面防空系统（Semi Automatic Ground Environment，SAGE）项目，这一系统通过多个主机实现了雷达数据的实时汇聚、处理和态势生成，其操作系统能够实现计算和I/O操作过程的交叠，在部份文献中被认为是首个实时操作系统。
|
||||
|
||||
\subsection{主机计算时代的操作系统（50年代-70年代）}
|
||||
在大型主机时代，操作系统的发展主要围绕提高计算资源的利用率和提高操作系统的抽象能力两条主线展开：
|
||||
|
||||
\begin{enumerate}[(1)]
|
||||
\item 提高计算资源的利用率
|
||||
|
||||
早期的操作系统采用单道批处理作业模型，此处的“单道”是指能够批量运行任务、减少了手工切换开销，但是在执行过程中只有单个程序在排他运行。由于CPU时间被大量浪费在等待I/O数据的过程中，资源利用率仍然相当低。1956年，UNIVAC 1103A计算机引入了硬件中断（Interrupt）的概念，为多个应用分时运行奠定了基础。此后，软件技术（如任务调度技术）和硬件技术（如内存保护机制）的协同发展，使得多道批处理、分时系统等支持多道程序设计（Multiprogramming）的操作系统开始出现。
|
||||
|
||||
\begin{itemize}
|
||||
\item 多道批处理是对单道批处理的扩展，允许单一计算机同时载入多个作业，使之可以以恰当的调度策略交替占用CPU，从而提高资源利用率，其典型案例是20世纪60年代由荷兰计算机科学家Dijkstra所领导研发、基于层次化架构的THE操作系统[6]。
|
||||
\item 分时系统的思想则几乎与操作系统同时出现，其目标是“通过分时共享，使得一台大的计算机能够像多台小型计算机一样使用” [7]。从1961年的首个MIT CTSS分时操作系统[8]开始，此类系统均通过CPU时间片的划分来支持多个终端用户
|
||||
\end{itemize}
|
||||
|
||||
\item 提高操作系统的抽象能力
|
||||
|
||||
在这一阶段，一系列重要的、今天所熟知的操作系统抽象（及其实现机理）被确立。其中，20世纪50年代“文件”已经被用于描述存储于外部存储器（如磁鼓）中的数据单元，60年代初文件系统已经成为许多操作系统的基本组件，并在Unix操作系统中扩展为对所有I/O设备能力的抽象；内存分页（段）和虚拟内存于1959年在英国曼彻斯特大学Atlas计算机原型系统中首先实现，并很快出现在60年代的商用计算机中，成为对内存资源的基本使用方式；多道程序、特别是分时共享理念的发展，推动了进程和线程的概念被提出，二者今天仍是CPU资源调度和使用的基本单位。上述抽象奠定了现代操作系统内核设计与实现的基础，也逐渐在软件领域形成了对“操作系统应当如何抽象计算机硬件能力”这一问题的共识。
|
||||
|
||||
与操作抽象能力提升相关的一个里程碑事件是“兼容”概念的提出。早期操作系统往往绑定到特定机型甚至特定应用场景，许多操作系统是计算机最终用户所开发或定制的。进入20世纪60年代，集成电路的发明促使计算技术迅速向工业、商业、教育等各个领域渗透，与硬件和场景高度绑定的操作系统已经无法满足日益增长的需求。在这一背景下，IBM于1961年启动OS/360研制计划[11]，旨在为System/360系列计算机开发了统一的批处理操作系统，为应用软件提供标准化、与特定机型和应用场景解耦的运行环境。其后，1968年发布的CP-67操作系统和1972年发布VM/370操作系统扩展了分时共享的思想，首次提供了成熟的虚拟化能力[12]，并率先使用了今天被广泛接受的Hypervisor（虚拟机监视器）一词。“兼容”概念自此开始深入人心：操作系统与硬件和应用场景解耦，使得上层应用在任何时候都看到是一个标准化的、具有通用图灵机能力的“虚拟机”，而不同型号的硬件也通过操作系统的抽象封装，以一致的方式向上层应用提供其能力，这一思路直接推动了整个计算机软硬件生态链的快速发展。
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{计算机普及时代的操作系统（70年代-21世纪初）}
|
||||
20世纪70年代集成电路技术的高速发展推动了微处理器的出现，使得计算技术由“旧时王谢堂前燕，飞入寻常百姓家”，具体表现为：一方面，个人计算机迅速普及，产品和技术快速发展，使得能“兼容”多种软硬件的操作系统成为主流，而且用户的非专业化使得图形用户界面成为主流操作系统的内嵌能力；另一方面，由于工业控制、航空航天、武器装备等领域微处理器的应用，嵌入和实时操作系统作为操作系统的一个分支开始登上历史舞台。此外，这一时期的开源操作系统对本领域后续发展产生了深远影响。
|
||||
|
||||
\begin{enumerate}[(1)]
|
||||
\item 个人计算机操作系统
|
||||
|
||||
70年代中期Intel发布8080 CPU以后，Digital Research发布了最早的微型计算机操作系统CP/M-80，它由基本输入输出系统（Basic Input/Output System，BIOS）、基本磁盘操作系统和控制台命令处理程序组成。其中，基本输入输出系统的引入，实现了操作系统其它模块与低层具体硬件的解耦，显著提高了操作系统的适用性和上层应用的可移植性。这种操作系统与具体硬件解耦的思想拓展了System/360大型机时代所提出的“兼容”概念，被后来的微软MS-DOS（Microsoft Disk Operating System）等操作系统所延续，直接为个人计算机软硬件生态链的快速发展奠定了基础。
|
||||
|
||||
在个人计算时代，操作系统的另一个重要进展是图形用户界面的加入。早在1973年，Xerox即推出了支持可视化操作的Alto计算机，并于1981年发布了集成完整图形化桌面的操作系统Xerox 8010 Star；1984年Apple发布了具有图形用户界面的个人计算机Lisa；1985年微软公司发布了Windows系列操作系统。图形用户界面是计算技术普及的必然结果：由于个人计算机面对的不是专业用户，易用性成为了操作系统的瓶颈问题，因此基于窗口和鼠标的直观操作取代了繁琐晦涩的命令行界面。
|
||||
|
||||
此外，90年代初Linux操作系统以开源软件形式出现，对操作系统技术、产品、产业乃至于相关法律政策、社会文化等都产生了重大影响。开源作为一种群智汇聚、群体协作的有效方式，一方面可以有效推动操作系统产品的发展，应对操作系统自身的复杂性；另一方面一个操作系统能否被广泛接受也取决于其生态链的完善程度，而开源则为生态链构建提供了一种基于众包的新模式。
|
||||
|
||||
\item 嵌入实时操作系统
|
||||
|
||||
20世纪70年代单片机出现是计算机发展史上的重要事件之一，它使得在各类设备中“嵌入”计算机成为可能，可被视为最早的“信息物理融合”（Cyber-Physical）尝试。针对嵌入式设备，80年代现代意义上强调轻量级、具有实时处理能力的嵌入实时操作系统开始出现，此类操作系统需要在资源受限环境下运行，并且由于其与物理世界直接交互，往往需要提供对实时性（时间可预测性）的保证。首个商业嵌入式实时操作系统内核VTRX32于1981年发布，后续涌现出了vxWorks、uCOS、QNX等一系列被广泛应用的嵌入实时操作系统产品。
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{互联网和移动计算时代的操作系统（21世纪初-）}
|
||||
进入21世纪，新型计算模式不断出现，计算技术表现出向两极发展的趋势：一方面以“云”为核心，强调通过资源集约化和按需服务方式，推动信息技术实现社会化和专业化；另一方面以“端”为核心，强调信息技术的普适化，使得计算服务如同水、电、空气一样随时随地可以获取而又不可见。需要指出的是，“云”和“端”二者并非割裂的，而是优势互补，正在通过“云+端”等形式共同推动着计算技术的新一轮革命。
|
||||
|
||||
\begin{enumerate}[(1)]
|
||||
\item 云计算操作系统
|
||||
|
||||
近年来，作为服务化思想的集大成者，云计算模式被广泛接受，云计算操作系统的概念开始出现。云计算操作系统是指架构于云计算数据中心各类硬件资源之上，实现“基础设施即服务”、“平台即服务”[13]等目标的系统软件，其典型代表包括Google AppEngine、Microsoft Azure等。此类操作系统具有如下一些特征：
|
||||
|
||||
\begin{itemize}
|
||||
\item 在资源的管控方面，此类操作系统的核心是大型主机时代即已出现的虚拟化技术，但将其应用场景拓展到了数据中心甚至多数据中心级别的，通过虚拟化实现海量计算、网络、存储资源的细粒度管理，进而实现资源的有效聚合和弹性扩展。例如，互联网虚拟计算环境 iVCE[14]通过资源的“自主协同、按需聚合”，将静态统一视图的资源组织模式扩展为相对稳定视图、按需可伸缩的资源组织模式，从而实现面向互联网计算的高效管控。
|
||||
\item 在应用软件的执行管控维度上，此类操作系统面向云服务这类大规模分布计算软件，提供了任务调度与执行、负载均衡、安全管控、在线监控和升级演化、分布式数据存储访问等一系列基础设施和相应能力。这些能力以的服务化方式提供，用户无需像传统系统软件那样自行安装、部署和维护。部分“平台即服务”基础设施还内建了编译系统和调测试环境，支持云端开发和编译构建。
|
||||
\item 在自身生命周期方面，此类操作系统需要 7×24小时持续提供基础服务，是支撑整个信息空间持续运行的核心基础设施。其突出表现为一旦发生故障，会产生较大的社会经济影响。例如，文献[15]指出如果一个主要的云平台宕机3－6天，美国经济会产生 30亿－150亿美元的损失。
|
||||
\end{itemize}
|
||||
|
||||
\item 智能终端操作系统
|
||||
|
||||
移动操作系统是“端”操作系统的典型代表。近年来，移动计算、特别是智能手机的出现，推动了移动操作系统的快速发展，典型实例包括Google的Android和Apple的iOS。此类操作系统在架构上与个人计算机操作系统并无本质区别，但更强调对移动和手持环境的支持，包括移动网络接入、各类传感器数据获取、电池管理、触摸屏交互等。与个人计算时代类似，操作系统在移动计算软硬件生态链中同样具有核心基础地位，特别是操作系统内置应用商店的出现，在降低用户查找、获取和安装应用程序难度的同时，也形成了较完善的商业模型。移动操作系统当前还表现出了与桌面系统一体化的发展趋势，通过统一桌面和移动操作系统及其生态，将有利于操作系统更好地发展与维护。例如，谷歌继移动操作系统Android和轻量级桌面系统ChromeOS之后，正在研制跨平台的Fuchsia操作系统。此外，随着万物互联时代的到来，以华为“鸿蒙”等为代表的轻量级、面向分布式环境、强调“联接”的物联网操作系统也正在逐步走向成熟。
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\section{编译系统}
|
||||
编译系统是将源语言（例如高级程序设计语言）编写的代码翻译为等价的、高效的、能被计算机或虚拟机执行的目标代码（例如机器语言）的系统软件。如前节所述，由于软件开发与运行的密切相关性，在计算机发展的早期，通常并不严格区分操作系统（Operating System）和编程系统（Programming System），只是后者更强调其对开发的支持，包括编译能力、开发辅助工具和可重用例程/库等。其后，编译系统逐渐被从操作系统中独立出来，并随着计算机体系结构和程序设计语言的变迁而不断扩展其内涵和外延（图\ref{fig:3-2}）。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=0.80\textwidth]{fig1-3/3-2.png}
|
||||
\caption{编译系统发展历程
|
||||
\label{fig:3-2}}
|
||||
\end{figure}
|
||||
作为机器体系结构抽象的符号化语言，汇编语言的目标是提高编程效率和质量。然而，计算机能读懂的只有机器指令，此时需要一个能够将汇编指令转换成机器指令的翻译程序。1947年伦敦大学伯贝克学院的Kathleen Booth为ARC2计算机开发了第一个汇编语言及其机器汇编器。之后不久，开始出现带有支持代码“库”的计算机，预先记录在打孔卡片和磁带上的支持代码库能够在装载器（Loader）的支持下与用户程序进行连接，从而支持输入输出等操作。这就是编译系统这种系统软件类型最早的雏形。
|
||||
|
||||
虽然汇编语言相对于机器语言提高了程序的可读性，但编写、阅读和理解汇编语言的难度依然较高。20世纪50年代初，葛丽丝·霍普在UNIVAC I上首次使用了“编译器”（Compiler）一词。在她所实现的编译器雏形中，磁带上的每段例程由一个数字代码标识，用户输入一组数字代码，来使得计算机依次加载这些例程。葛丽丝·霍普工作证明了高级语言（数字代码）向机器语言（磁带上例程中所包含机器指令序列）映射的可行性。在此基础上，更为激进的“自动编程”（Automatic Programming）的概念[16, 17]被提出，希望能够采用接近于人类自然语言的语言编写程序，依据这些程序自动生成可执行的机器代码，从而显著提高程序开发效率和质量、便于程序的理解阅读和维护。在这一思想的驱动下，上个世纪50年代出现了第一个高级程序设计语言——为IBM 704大型机设计的Fortran语言[18]。1957年发布的Fortran编译器则是第一个功能比较完备的高级程序语言编译器。它也是第一个具备优化能力的编译器，引入了循环优化、寄存器分配等技术，使编译器翻译的机器代码能够与当时人工编写的汇编程序性能相当。
|
||||
|
||||
\subsection{程序设计语言驱动的编译系统发展（60年代-90年代）}
|
||||
在高级程序设计语言出现以后，程序设计方法学和程序设计语言飞速发展，诸如结构化程序设计、面向对象程序设计、函数式程序设计、逻辑程序设计等方法和语言百花齐放，直接推动了编译技术和编译系统的发展。
|
||||
|
||||
20世纪50年代末，COBOL（Common Business-Oriented Language）语言诞生[19]。与Fortran主要面向科学计算不同，COBOL是用于商务数据处理的语言，也是第一个跨平台的高级程序设计语言。1960年，COBAL编译器编译的COBOL程序成功在UNIVAC II和RCA 501机上运行。70年代初，美国Bell实验室以开发了B语言和B语言编译器，并用B语言编写了第一个UNIX操作系统内核。在B语言基础上，Bell实验室经过进一步改进完善后发布了C语言及其编译器。
|
||||
|
||||
相对于Fortran和 C等命令式高级语言，面向对象语言也在这一时期得到发展。20世纪 60年代的SIMULA67语言[20]引入了类和对象的概念，被认为是世界上第一个面向对象语言。70年代出现的Smalltalk语言支持类的动态创建和修改。受到C和SIMULA67语言的影响，Bell实验室在八十年代开发了C++，随后开发了支持C++的Cfront编译器。20世纪90年代，随着C++等语言的流行，面向对象语言成为主流的编程语言，重要标志是GCC编译器（GNU Compiler Collection）走向成熟，以及Java面向对象语言和编译器的发布。这一时期互联网的发展也促进了编程语言及其编译/解释执行系统的发展，例如出现了互联网开发、在运行时检查类型甚至改变程序结构的动态语言（如PHP、Ruby等）。
|
||||
|
||||
60-70年代，编译系统的基础理论和相关技术也开始成熟。20世纪50年代，Noam Chomsky通过研究自然语言结构提出Chomsky文法类型，其中上下文无关文法成为现今几乎所有程序设计语言的语法[21]。60年代至80年代，用于上下文无关文法识别的有效算法逐步发展为编译原理的标准部分，同时科学家们着眼研究编译器的自动构造，典型实例包括为UNIX操作系统研制的词法分析器生成工具Lex和语法分析器生成工具Yacc。编译系统中的代码优化研究也起步于这一阶段，包括与处理器体系结构无关的优化（如循环变换、常量传播、公共表达式删除）以及与处理器体系结构相关的优化（如寄存器分配、指令调度），后者与当时精简指令集、超标量、超长指令字等体系结构技术的发展密不可分。
|
||||
|
||||
\subsection{多核/众核架构驱动的编译系统发展（21世纪-）}
|
||||
提高处理器性能是计算机领域长期追求的目标。随着处理器功耗、散热和设计复杂度等原因，在单核处理器上提高时钟频率的方法已无法继续提高处理器性能。因此，学术界和工业界开始改变策略，通过增加处理器核心数目来扩展性能。2001年，第一款商用非嵌入式多核处理器IBM POWER4发布，计算机体系结构发展进入多核时代。然而，增加处理器核数并不必然带来应用性能的提升，需要充分挖掘应用中的并行性以利用处理器的多核特性[22]。在编译系统中挖掘并行性，具有对程序员透明、有可能在机器指令层面发挥硬件潜力等特点，因此当前的主流编译器（如GNU GCC、Intel ICC、IBM XLC和Oracle compiler）均提供了对多核心的支持和优化。
|
||||
|
||||
与多核处理器通常仅集成几个处理单元不同，众核处理器在同一处理器内部集成了大量同构处理单元。例如，GPU（Graphics Processing Unit）在一个芯片上集成数百甚至数千个“小而简单”的核心，通过使用大量线程并发提高性能，特别适合用于加速大规模并行应用。近年来，众核处理器在高性能计算、人工智能等领域发展迅速，其编译优化技术也随着体系结构的不断升级而进步，包括针对GPU不同存储层次的优化、程序并行度的自动调优、通信优化、针对宽向量的自动向量化等。
|
||||
|
||||
多核和众核处理器都在不断向前发展，聚合两类处理器的异构计算平台获得了工业界和学术界的重视。2007年首个针对异构计算平台的通用编程模型OpenCL出现，各硬件厂商纷纷提供了OpenCL编译、运行时和驱动支持，使OpenCL代码能够运行在不同类型和不同厂商的硬件平台上。此外，OpenMP 4.0标准也引入了异构计算支持。目前，异构计算平台已成功运用到从超级计算机到移动设备的不同层次计算机系统中。为了提高异构计算平台的性能，研究人员在负载均衡、数据通信延迟隐藏、同步等方面展开了研究。
|
||||
|
||||
\section{中间件}
|
||||
“中间件（Middleware）”本义是指位于操作系统之上、应用软件之下的一层中间软件，提供操作系统所不具备、但上层应用又迫切需要的系统软件功能。由于在过去很长一段时间内，经典操作系统并未充分考虑分布式应用支撑问题，因此狭义的、或者说现代意义上的“中间件”往往特指网络计算中间件，也即支持分布式应用的部署、运行和管理的软件[23]。今天，随着应用软件和操作系统的发展，中间件一词含义也在不断演化（图\ref{fig:3-3}），并表现出沉淀和融入到操作系统中的趋势。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=0.80\textwidth]{fig1-3/3-3.png}
|
||||
\caption{中间件发展历程
|
||||
\label{fig:3-3}}
|
||||
\end{figure}
|
||||
|
||||
\subsection{中间件的出现（20世纪60年代中后期-80年代）}
|
||||
中间件的出现是软件系统应用场景快速拓展的结果。随着计算技术的发展，上层应用在适应新场景过程中对系统软件不断提出新的要求，而作为底层支撑的经典操作系统能力相对稳定固化，很难快速跟上这些变化，二者之间的差距决定了中间件存在的合理性。在1968年北大西洋公约组织的软件工程报告中，“中间件”一词被首次使用[24]，代指弥补底层操作系统（当时称“服务例程/控制程序”）通用能力和上层应用特化需求之间鸿沟的中间层软件（图\ref{fig:3-4}）。1972年Jenkin等撰文指出，“随着一些系统变得空前复杂，标准的操作系统需要扩展或修改，推动了‘中间件’这一名词出现”[25]。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=0.80\textwidth]{fig1-3/3-4.png}
|
||||
\caption{NATO软件工程报告中的倒金字塔软件结构[24]
|
||||
\label{fig:3-4}}
|
||||
\end{figure}
|
||||
|
||||
虽然“中间件”这一名词在60年代中后期即已出现，但早期计算机厂商通常提供从操作系统到应用软件的一揽子解决方案，使得二者之间的鸿沟并不凸显。20世纪80年代初，网络技术走向成熟，如何高效构造跨越多个计算结点的分布式应用成为焦点。在传统操作系统之上，开发人员只能通过操作系统的Socket API原生接口，以完全手工方式实现分布式应用中的网络消息传递，其过程繁琐、复杂且低效。同时，除了通信支持外，相对于单机软件，分布式系统还有很多特有的理论和技术问题（如并发支持、事务管理、访问控制等），而传统操作系统并未提供相应的支撑能力。
|
||||
|
||||
为了应对上述挑战，人们早期围绕两种思路展开了探索。一是以Amobea[26]等分布式操作系统为代表的方法，核心是将单机操作系统的概念放大到网络环境，实现对网络软硬件资源的严格管控，例如文献[27]指出“分布式操作系统对用户而言与单机操作系统无二，只是运行在多个独立处理器上。它的核心概念是透明性”。但是，网络资源具有分布自治、高度异构、持续演化等特点，其软件很难通过严格的以自顶向下的方法精确设计出来，而更多的是通过互联互通方式成长式构造出来的。后一种思路在1976年的ARPANET RFC707中即以“允许调用远程进程所实现的任意命令或函数”的“请求-响应”协议形式出现[28]。Birrel和Nelson等于1984年实现了首个远程过程调用（Remote Procedure Call，RPC）框架[29]，标志着现代意义中间件的诞生。
|
||||
|
||||
\subsection{企业计算时代的中间件（80年代-21世纪初）}
|
||||
如前所述，最早出现的中间件是面向过程的中间件。早期的Sun RPC、开源软件基金会的DCE（Distrbuted Computing Environment）等都是具有代表性的此类中间件，聚焦于尽量实现“调用远程过程像调用本地过程一样简单”。相对于过程，“对象”提供了更贴近现实世界的抽象。面向对象中间件出现于上个世纪80年代初，例如华盛顿大学1980年启动的Eden项目[30]即以在网络计算环境中应用面向对象技术为目标，提出了分布式Ejects（Eden objects）的概念、编程模型和相应支撑平台。OMG于1990年发布CORBA 1.0是具有里程碑意义的面向对象中间件标准，直接推动了面向对象中间件的成熟和高速发展，对后续SUN公司的Java/RMI、微软公司的DCOM等技术体系有着直接和深远的影响。
|
||||
|
||||
分别发布于1998年和2000年的EJB（Enterprise JavaBean）和CCM（CORBA Component Model）推动了面向构件中间件的出现。面向构件中间件又被称构件容器或构件化应用服务器，它是以构件为基本单元的分布式软件的运行平台。构件技术一方面强调通过大粒度、具有规范接口的软件单元来组装软件系统，另一方面由于构件具有规范的功能和管理接口，因此运行时可以对分布式系统进行灵活管理操纵，包括生命周期管理、交互关系管理甚至动态更新演化等。
|
||||
|
||||
除了上述支撑不同应用程序模型的通用中间件外，部份中间件关注的是分布式软件的一些特化场景，其典型代表是消息中间件和事务处理中间件：（1）在分布计算实践的初期，人们就已发现紧耦合、同步的过程调用并不能满足所有应用场合，支持异步交互和松耦合通信的分布式应用消息机制的研究和实践开始被重视，诸如Field、InformationBus等消息中间件平台开始出现。上个世纪90年代，IBM MQSeries等消息中间件产品被大量使用，消息中间件技术走向成熟。（2）在大型主机时代，IBM的CICS（Customer Information Control System）系统就已提供了跨计算结点事务支持。针对美国电话公司需要的联机事务处理能力，AT\&T贝尔实验室于上个世纪80年代初发布了跨平台的Tuxedo事务处理中间件，相关研究与实践对后续X/Open组织的分布式事务处理规范、OMG组织的对象事务服务规范等产生了较大影响[31]。
|
||||
|
||||
\subsection{互联网计算时代的中间件（90年代末-）}
|
||||
20世纪90年代中后期， 互联网进入高速发展阶段。互联网资源具有开放动态、成长自治的特点，但人们同时又希望软件能够持续在线、高度可用，二者之间的矛盾催生了“服务”的概念。从2000年左右W3C组织所制定一系列Web Service标准开始，“服务”一词即被用来抽象可通过网络按需访问、无需关心实现细节的能力[32]。以此为核心，面向服务体系结构通过服务化封装和“服务提供者-消费者”之间的动态发现，解决开放动态与持续在线之间的矛盾。
|
||||
|
||||
作为互联网时代的产物，服务化思想首先推动了中间件技术外延的拓展。Apache Tomcat、IBM WebSphere等Web服务中间件以支撑面向服务体系结构为目标，封装了服务注册、服务发现、服务访问等共性基础设施；以企业服务总线（Enterprise Service Bus，ESB）为代表的服务集成中间件通过服务封装、服务组合、服务协同等技术实现自治子系统之间的通信，进而实现复杂业务系统跨域集成；微服务则聚焦单个业务系统内部，通过系统内部组件的彻底服务化，实现开发阶段“分而治之”和运行阶段的灵活应变，这一思路催生了Spring Cloud等微服务框架。
|
||||
|
||||
互联网软件按需提供服务的特点也促使了中间件本身向持续运行的平台形式的转型，其典型代表是网格计算中间件、P2P中间件以及云计算“平台即服务”（PaaS）基础设施等。“平台即服务”在“基础设施即服务”（IaaS）的基础上提供包括中间件和数据库在内的一系列软件栈，为云端分布式应用提供服务化的、可按需使用的运行托管环境。在某种程度上，“平台即服务”可视为中间件技术在云计算环境下的集成和延续。
|
||||
|
||||
\subsection{信息物理融合时代的中间件发展（21世纪初-）}
|
||||
计算技术的网络化和普适化推动了信息与物理空间的持续融合，出现了各类可以感知/作用于物理世界的大规模网络软件，中间件技术随之在不断发展。自上个世纪末以来，随着相关硬件技术的逐渐成型，中间件领域针对嵌入式传感器和移动设备等载体，开始关注对物理空间情境（Context）数据的处理，出现了普适计算中间件、传感器网络中间件、情境感知中间件等一系列新型中间件[33]。近年来快速发展的物联网中间件（IoT Middleware）在上述中间件概念的基础上，进一步针对“万物互联”的大规模异构环境进行了拓展，其核心关注点是在资源受限、高度异构、规模庞大、网络动态变化条件下，如何实现互联互通互操作，并且不违反各种时空约束特性，满足物联网应用对海量传感器数据或事件实时处理的需求。
|
||||
|
||||
除了感知物理世界外，随着信息物理融合系统的成熟，近年来中间件领域开始关注如何联接能够直接“作用”于物理世界的计算设备，其突出代表是无人系统/机器人中间件。针对无人系统计算环境高度异构、资源受限、常态失效、实时性要求高等特点，从2000年左右的Player等中间件开始，包括Miro、CLARAty、OpenRTM-aist、Pyra、Orca、MARIE等在内的一系列实践推动了无人系统中间件技术的发展，并直接为今天广泛使用的机器人“元级操作系统”ROS（Robot Operating System）奠定了理论和技术基础[34]。
|
||||
|
||||
\section{数据库管理系统}
|
||||
数据库是长期存储在计算机内有组织、可共享的大量数据的集合，数据库管理系统旨在统一管理和维护数据库中的数据，是存储、组织、联接、变换和加载数据的软件。从本质上而言，数据库管理系统把逻辑数据转换成为计算机中具体的物理数据，从而使得用户可以访问、检索和维护数据，而不必顾及这些数据在计算机中的布局和物理位置。
|
||||
|
||||
数据库管理系统的发展历史可以按照其支撑的应用特征来划分（图\ref{fig:3-5}）[35]。第一代系统主要是支持数据的存储与访问，数据的组织以层次和网状模型为代表。第二代系统主要围绕联机事务处理（Online Transaction Processing，OLTP）应用展开，在关系模型和存储技术的基础上，重点发展了事务处理、查询优化等能力。第三代系统主要围绕联机分析处理（Online Analysis Processing，OLAP）应用展开，重点在于提出高效支持联机分析处理复杂查询的新型数据组织技术。第四代系统主要围绕大数据应用展开，重点在分布式可扩展、异地多备份高可用架构、多数据模型支持、以及多应用负载类型支持等特性。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=0.80\textwidth]{fig1-3/3-5.png}
|
||||
\caption{数据库管理系统发展历程
|
||||
\label{fig:3-5}}
|
||||
\end{figure}
|
||||
|
||||
\subsection{数据库管理系统的出现（20世纪60年代-70年代初）}
|
||||
20世纪50年代前期，计算机被主要用于科学计算，数据仅被认为是“计算”的产品或附属品，通常存储在被称为“文件”的打孔卡片（早期）或外设数据单元上。随着计算机应用领域向商业、金融、政府等通用领域扩展，文件作为数据存储的主要设施，已经无法满足对各类应用中数据项之间的复杂关系进行管理的需求，主要表现在以下几个方面：文件内部数据组织往往是面向单一应用的，不同应用共享同一个文件结构效率较低；文件之间的数据是独立的，无法表达两个文件的数据所存在内在逻辑关系；文件的组织方式单一，难以满足不同的访问模式对数据高效率访问的需求。
|
||||
|
||||
在上述背景下，为了提供系统化、高效的数据组织与访问功能，专门的数据库管理系统开始出现。60年代初通用电气在其生产信息和控制系统（MIACS）中设计了“集成数据存储”（Integrated Data Store），被认为是首个支持直接访问的数据库管理系统，并直接为CODASYL组织后续制定的网状数据库标准奠定了基础。1968年，IBM发布了运行于System/360主机的层次数据库管理系统IMS（Information Management System）。上述两个具有里程碑意义的产品分别代表了数据库管理系统的两种早期数据模型，也即数据是按照网状的“图”还是层次化的“树”来组织。其中，层次模型由于其每一个节点最多只有一个父节点，因此可以采用有效的手段（例如按照树遍历的顺序）来存储数据，而网状模型可以将图分解为一组“基本层次联系”的集合，其本质上可以用“树”结构来表达和存储数据。
|
||||
|
||||
\subsection{关系数据库的高速发展（70年代-90年代）}
|
||||
20世纪70年代是关系数据库形成并实现产品化的年代，主要的代表人物就是IBM的埃德加·科德（Edgar F. Codd）。1970年，科德发表题为“大型共享数据库的关系模型”的论文[36]，文中提出了数据库的关系模型。由于关系模型简单明了、具有坚实的数学理论基础，操作语言是描述性的，无需像层次网状模型那样，需要描述存取路径（既先访问哪个数据再访问哪个数据）这样的细节，给提高信息系统开发的生产率提供了极大的空间，所以一经提出就受到了学术界和产业界的高度重视和广泛响应。尽管一开始产业界还充斥了对关系数据库系统性能的怀疑，但科德所开发的System R系统证明其性能可以有保障。这一结论极大地推动了关系数据库技术的发展，关系数据库产品开始涌现，例如IBM公司自己在System R系统基础上推出的DB2产品和ORACLE公司的同名数据库产品。
|
||||
|
||||
20世纪80年代，关系数据库迅速取代层次和网状数据库占领市场。数据库研究工作重心也围绕关系数据库展开。在这一阶段，描述型的关系库数据语言（SQL语言）、完善数据正确性确保的机制、逐渐发展的开发工具和软件生态推动了上述挑战的解决，在实践中显著提高了生产率。由于科德杰出的贡献，1981年的图灵奖授予了这位“关系数据库之父”。
|
||||
|
||||
具体而言，这一阶段的研究和实践核心围绕查询优化和事务管理等展开：（1）查询优化。关系数据库语言是基于集合的描述性语言（如70年代初出现的SQL语言），其查询的结果也是一个集合。如何将一个SQL语句转换为可以执行的程序（类似程序自动生成器），而且要在所有可能的执行计划（程序）中选择出一个效率足够好的加以执行，是这一阶段工作重点之一。（2）事务管理。事务管理提供对并发事务的调度控制和故障恢复，确保数据库系统的正确运行。詹姆斯·尼古拉·格雷（James Gray）在相关研究方面发挥了十分关键的作用，为数据库管理系统成熟并顺利进入市场做出了重要的贡献。他的成就汇聚成一部厚厚的专著《Transaction Processing: Concepts and Techniques》[37]，他也众望所归获得了1998年度的图灵奖。
|
||||
|
||||
在这一时代，对于数据库管理系统做出重要贡献的还有迈克尔·斯通布雷克（Michael Stonebraker）。他在加州大学伯克利分校计算机科学系任教的29 年中中，领导开发了关系数据库系统Ingres、对象–关系数据库系统Postgres、联邦数据库系统Mariposa等，同时创立了多家数据库公司。他在“One size does not fit all”的思想指导下，开发了一系列的“专用”关系数据库产品，例如流数据管理系统、内存数据库管理系统、列存储关系数据库系统、科学数据库管理系统等。因“对现代数据库系统底层的概念与实践所做出的基础性贡献”，他于2015年获得了图灵奖。
|
||||
|
||||
\subsection{数据仓库系统的出现和发展（90年代-）}
|
||||
数据仓库可看作是关系数据库的一个自然延伸。随着数据库技术的普及应用，越来越多的数据被存储在数据库中，除了支持业务处理以外，如何让这些数据发挥更大的作用，就是一个亟待解决的问题。特别是对于联机分析处理类应用，如何让复杂分析能高效地执行，需要有特殊的数据组织模式，推动了数据仓库系统的出现。
|
||||
|
||||
星型模型是最常用的数据仓库的数据组织模型。所谓星型模型也称多维模型，就是选定一些属性作为分析的维度，另一些属性作为分析的对象。维属性通常根据值的包含关系会形成一个层次，例如时间属性可以根据年月周日形成一个层次，地区属性也可以形成街道-区-市这样的层次。为了实现快速分析，可以预先计算出不同层次上的统计结果，从而获得快速联机分析的性能。在实现方式上，数据仓库可以用关系数据库实现（Relational OLAP），分别用事实表和维表来存储统计结果和维度结构，也可以用特别的数据模型（CUBE）来实现，列存储的技术也在这个过程中被提出和应用。同时，支持联机分析处理的前端工具的发展，也使得普通用户可以方便地使用数据仓库
|
||||
|
||||
\subsection{大数据时代数据库管理系统的发展（21世纪初-）}
|
||||
关系数据库成熟并广泛应用后，数据库领域一度走入一段迷茫期，被关系模型的“完美”所陶醉。进入21世纪，互联网的高速发展使得数据规模越来越庞大，传统关系数据库的弊端开始凸显：在搜索引擎、流媒体等拥有海量非结构化数据的领域，传统的关系数据模型并不完全适用，而关系型数据库所承诺的原子性、一致性、隔离性、持久性等ACID特性在这些领域有可能不需要严苛保证，不必要的开销和有限的可扩展性导致数据存储和管理效率低下。在这一背景下，NoSQL数据库开始出现，其重要的里程碑事件是Google所发布的Bigtable[40]及根据其理念所开发的开源HBase数据库。与关系数据库不同，NoSQL数据库不再采用严苛的关系模型，转而使用更为灵活的键值对结构、文档模型、图模型等。同时，NoSQL数据库可能不提供严格的一致性保证，并且通常在设计时即考虑了水平可扩展能力（即通过增加计算节点来扩充处理能力），因此可以达到比关系型数据库更高容量和性能。
|
||||
|
||||
随着实践的深入，人们发现NoSQL并非解决大数据时代数据管理问题的“银弹”。一方面，无论从应用程序继承的角度还是提高生产率的角度，SQL语言都是不可或缺的工具，因此继承和汲取SQL的优点（如在上层提供SQL查询引擎）逐渐成为NoSQL数据库的共识，NoSQL一词的含义也从“非SQL”被修正为“不仅仅是SQL”（Not Only SQL）。另一方面，许多联机事务处理业务在应对海量数据同时仍需要采用关系模型，并保证原子性、一致性、隔离性、持久性等特性。因此，能够提供与NoSQL数据库类似的扩展性能、但仍具备关系数据库能力的NewSQL数据库近年来得到了快速发展，其典型代表包括Google全球级分布数据库Spanner和开源领域的CockroachDB、TiDB等。
|
||||
|
||||
\section{总结与展望}
|
||||
系统软件将计算系统的概念从硬件扩展到了软件层面上，它为上层应用提供了一个可以使用各类资源能力、但又无需关注底层细节的软件平台。历经六十余年的发展，系统软件已经形成操作系统、编译系统、中间件和数据库管理系统等典型形态，已经成为了计算机软硬件生态链的核心，对信息产业乃至人类社会产生了较大影响，在促进经济发展和文明进步中发挥了重要作用。在这一过程中，系统软件表现出了如下一些发展规律：
|
||||
|
||||
\begin{itemize}
|
||||
\item 场景驱动发展。本质而言，系统软件负责向应用提供“抽象”（或者说虚拟机），并将这一“抽象”绑定硬件祼机。因此，应用场景的变迁持续推动着系统软件的发展，典型案例是操作系统的发展所呈现的“20年周期”：在贝尔定律支持下，计算设备约每10年一次换代，设备和用户增加10倍，成为新的蓝海、催生新型应用，间次推动操作系统换代并形成新的生态，使得操作系统每隔20年左右迎来一次跨越式发展的机遇期。
|
||||
\item 技术螺旋上升。与应用软件的快速更新不同，系统软件技术具有相对稳定性，并且每一次跨越式发展都是在继承的基础上提升新场景下的能力。例如，虚拟化技术早在60年代IBM实验性操作系统CP-40和其后商用化的CP-67、VM/370中得到完整实现，而云计算时代虚拟化技术“复兴”过程中的挑战则主要来自于数据中心环境资源集约化的需求。
|
||||
\item 分支交叉融合。系统软件并非是计算机与生俱来的，其发展经历了从无到有、进而形成多个分支的过程。“分久必合”，近年来分支之间表现出相互融合趋势，系统软件整体在向平台化和体系化拓展。例如，操作系统的概念正在进一步泛化，中间件这一分支目前表现出向操作系统融合的趋势，而在许多语境下云计算操作系统已经涵盖了系统软件四个主流分支。
|
||||
\end{itemize}
|
||||
|
||||
今天，“软件定义一切”、“软件成为社会基础设施”正在成为软件学科发展的主流方向，这一趋势推动着系统软件的进一步发展，通过支撑软件系统与社会/物理系统协同演化、联接人机物多个维度、成为泛在基础设施等形式获得新的活力。
|
||||
|
||||
\section{参考文献}
|
||||
|
||||
\begin{itemize}
|
||||
\item [] [1]. M. Bullynck, "What is an operating system? A historical investigation (1954–1964)," in Reflections on Programming Systems: Springer, 2018, pp. 49-79.
|
||||
\item [] [2]. A. M. Turing, "On computable numbers, with an application to the Entscheidungsproblem," Proceeding of the London Mathematic Society, 2, pp. 230-265, (1937).
|
||||
\item [] [3]. R. L. Patrick, "General motors/North American monitor for the IBM 704 computer," in AFIPS Conference, 1987.
|
||||
\item [] [4]. H. D. Bennington and C. H. Gaudette, "Lincoln laboratory utility program system," in Joint ACM-AIEE-IRE western computer conference: ACM, 1956, p. 21-21.
|
||||
\item [] [5]. W. F. Bauer, "An integrated computation system for the ERA-1103," Journal of the ACM (JACM), 3, pp. 181-185, (1956).
|
||||
\item [] [6]. E. W. Dijkstra, "The structure of the “THE” multiprogramming system," in The origin of concurrent programming: Springer, 1968, pp. 139-152.
|
||||
\item [] [7]. W. F. Bauer, "Computer design from the programmer's viewpoint," in Eastern joint computer conference: Modern computers: objectives, designs, applications, 1958, pp. 46-51.
|
||||
\item [] [8]. J. Lee, "Time-sharing at MIT: Introduction," IEEE Annals of History of Computer, pp. 13-15, (1992).
|
||||
\item [] [9]. F. J. Corbató and V. A. Vyssotsky, "Introduction and overview of the Multics system," in Proceedings of the November 30--December 1, 1965, fall joint computer conference, part I, 1965, pp. 185-196.
|
||||
\item [] [10]. M. J. Bach, The design of the UNIX operating system vol. 5: Prentice-Hall Englewood Cliffs, NJ, 1986.
|
||||
\item [] [11]. G. H. Mealy, "The functional structure of OS/360, Part I: Introductory survey," IBM Systems Journal, 5, pp. 3-11, (1966).
|
||||
\item [] [12]. R. J. Creasy, "The origin of the VM/370 time-sharing system," IBM Journal of Research and Development, 25, pp. 483-490, (1981).
|
||||
\item [] [13]. A. D. JoSEP, R. KAtz, A. KonWinSKi, L. Gunho, D. PAttERSon, and A. RABKin, "A view of cloud computing," Communications of the ACM, 53, (2010).
|
||||
\item [] [14]. X. Lu, H. Wang and J. Wang, "Internet-based virtual computing environment (iVCE): Concepts and architecture," Science in China Series F: Information Sciences, 49, pp. 681-701, (2006).
|
||||
\item [] [15]. LLyod'S, "Cloud Down: Impacts on the US economy," Technical Report, 2018, https://www.lloyds. com/~/media/files/news-and-insight/risk-insight/2018/cloud-down/aircyberlloydspublic2018final.pdf.
|
||||
\item [] [16]. G. M. Hopper and J. W. Mauchly, "Influence of programming techniques on the design of computers," Proceedings of the IRE, 41, pp. 1250-1254, (1953).
|
||||
\item [] [17]. J. W. Backus, "Automatic programming: properties and performance of FORTRAN systems I and II," in Proceedings of the Symposium on the Mechanisation of Thought Processes, 1958, pp. 165-180.
|
||||
\item [] [18]. J. Backus, "The history of Fortran I, II, and III," ACM SIGPLAN Notices, 13, pp. 165-180, (1978).
|
||||
\item [] [19]. J. E. Sammet, "The early history of COBOL," in History of programming languages I: ACM, 1978, pp. 199-243.
|
||||
\item [] [20]. O. Dahl, B. Myhrhaug and K. Nygaard, "Some features of the SIMULA 67 language," in Conference on Applications of Simulations, 1968, pp. 29-31.
|
||||
\item [] [21]. N. Chomsky, "Three models for the description of language," IRE Transactions on information theory, 2, pp. 113-124, (1956).
|
||||
\item [] [22]. M. Mehrara, T. Jablin, D. Upton, D. August, K. Hazelwood, and S. Mahlke, "Multicore compilation strategies and challenges," IEEE Signal Processing Magazine, 26, pp. 55-63, (2009).
|
||||
\item [] [23]. 梅宏, 王怀民, "软件中间件技术现状及发展," 中国计算机学会通讯, 1, pp. 2-14, (2015).
|
||||
\item [] [24]. J. N. Buxton and B. Randell, Software Engineering Techniques: Report on a Conference Sponsored by the NATO Science Committee: NATO Science Committee; available from Scientific Affairs Division, NATO, 1970.
|
||||
\item [] [25]. B. Jenkins, "Developments in computer auditing," Accountant, (1972).
|
||||
\item [] [26]. A. S. Tanenbaum, R. Van Renesse, H. Van Staveren, G. J. Sharp, and S. J. Mullender, "Experiences with the Amoeba distributed operating system," Communications of the ACM, 33, pp. 46-63, (1990).
|
||||
\item [] [27]. A. S. Tanenbaum and R. Van Renesse, "Distributed operating systems," ACM Computing Surveys (CSUR), 17, pp. 419-470, (1985).
|
||||
\item [] [28]. IETF, "RFC 707 - High-level framework for network-based resource sharing," 1977.
|
||||
\item [] [29]. A. D. Birrell and B. J. Nelson, "Implementing remote procedure calls," ACM Transactions on Computer Systems (TOCS), 2, pp. 39-59, (1984).
|
||||
\item [] [30]. A. P. Black, "Supporting distributed applications: Experience with Eden," in ACM SIGOPS Operating Systems Review. vol. 19: Citeseer, 1985, pp. 181-193.
|
||||
\item [] [31]. W. Emmerich, M. Aoyama and J. Sventek, "The impact of research on the development of middleware technology," ACM Transactions on Software Engineering and Methodology (TOSEM), 17, p. 19, (2008).
|
||||
\item [] [32]. C. Ferris and J. Farrell, "What are web services?" COMMUNICATIONS OF THE ACM, 46, p. 31, (2003).
|
||||
\item [] [33]. 丁博, 王怀民, 史殿习, "普适计算中间件技术," 计算机科学与探索, 1, pp. 241-254, (2007).
|
||||
\item [] [34]. A. Elkady and T. Sobh, "Robotics middleware: A comprehensive literature survey and attribute-based bibliography," Journal of Robotics, 2012, (2012).
|
||||
\item [] [35]. 杜小勇, 卢卫, 张峰, "大数据管理系统的历史, 现状与未来," 软件学报, 30, pp. 127-141, (2019).
|
||||
\item [] [36]. E. F. Codd, "A relational model of data for large shared data banks," COMMUNICATIONS OF THE ACM, 13, pp. 377-387, (1970).
|
||||
\item [] [37]. J. Gray and A. Reuter, Transaction processing: concepts and techniques: Elsevier, 1992.
|
||||
\item [] [38]. S. Ghemawat, H. Gobioff and S. Leung, "The Google file system," in ACM Symposium on Operating Systems Principles, 2003.
|
||||
\item [] [39]. J. Dean and S. Ghemawat, "MapReduce: a flexible data processing tool," Communications of the ACM, 53, pp. 72-77, (2010).
|
||||
\item [] [40]. F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber, "Bigtable: A distributed storage system for structured data," ACM Transactions on Computer Systems (TOCS), 26, p. 4, (2008).
|
||||
|
||||
\end{itemize}
|
||||
|
|
@ -0,0 +1,496 @@
|
|||
|
||||
\section{软件工程的诞生}
|
||||
50年前（1968年）在德国的一个叫做Garmisch的小镇上，由NATO科学委员会主导召开了一个小型研讨会，有来自11个国家的50位代表参加。会议的议题是如何应对当时面临的所谓“软件危机”。在这个研讨会上诞生了“软件工程”这个学科领域[1]。软件危机指，在所需时间内编写出有用且高效的计算机程序存在很大困难。其原因出自，一计算机能力的迅速增长，二希望用软件来解决的现实问题的日益复杂，三当时可以采用的软件开发方法明显不能应对。导致软件的开发出现了许多问题。
|
||||
|
||||
Dijkstra在那个研讨会上就指出[2]：软件危机的主要原因是机器变得更强大，强大了好几个数量级！坦率地说：只要没有机器，编程就没有问题了; 如果只有一些比较弱的机器，编程就是简单的问题，但当有了能力巨大的计算机，编程就成为同样大的问题。总之，主要原因是机器能支持的计算能力和人对软件的预期，远远超出了程序员能够有效利用的能力和对问题的驾驭能力。当时谈到的软件危机表现为多种形式：软件开发效率低（如，项目超预算，项目时间过长，软件滞后交付），软件质量很差（如，很多方面不符合要求），项目难以管理（如，代码难以维护），等等。
|
||||
|
||||
50年前这次会议讨论的问题，涉及软件开发的方方面面，如，软件与硬件的关系、软件的设计、软件的生产、软件的分发、以及软件的服务等。这次会议成为软件工程学科的奠基性会议，所讨论的核心议题成为软件工程学科经久不衰的开放性挑战问题，比如：（1）获取正确的软件需求；（2）设计合适的系统架构；（3）正确和有效地实现软件；（4）能验证软件的质量；（5）长期维护具有目标功能和高代码质量的软件系统。
|
||||
|
||||
1986 年，布鲁克斯(Brooks) 在《人月神话》中给出了“软件开发没有银弹”的预言[3]，即由于软件本质上的复杂性，在未来10 年内，不存在任何技术或方法能够使软件生产力提升10 倍以上。1995 年，布鲁克斯在重新发行的《人月神话》纪念版中再次重申，“软件开发没有银弹”的预言在下一个10 年仍然成立[4]。布鲁克斯的观点得到了软件开发实践者和研究者的广泛关注和讨论。虽然有学者曾经宣称某项技术或方法有可能成为“银弹”，但实践表明这些技术或方法后来都没有成为“银弹”。
|
||||
|
||||
随着信息技术的发展，软件技术的应用范围不断扩大，应用领域不断深入，50年前的软件和现代软件已经不可同日而语，在最初出现软件的时候，谁都没有预计到现在人们对软件的期望，谁都没能想象出通过在互联网和物联网之上，未来人机物融合系统将会在任何地方并由任何人来操控。软件工程50年前的核心挑战仍然还是当前的核心挑战，问题表述几乎没有变化，但问题在不同年代却被赋予了不同的内涵。“软件开发没有银弹” 的预言仍是软件工程研究者和实践者不可逾越之“墙”。
|
||||
\section{软件工程的内涵和知识体系}
|
||||
什么是软件工程？如何理解软件工程？Wikipedia\footnote{https://en.wikipedia.org/wiki/Software\_engineering}引用的简短描述涵盖了其主要关注点：软件工程是将\textbf{工程化的手段}并采用\textbf{系统化的方法}进行\textbf{软件开发}[5]。
|
||||
|
||||
具体一点来说，可以罗列一些大家公认的说法，比如：
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 系统地将科学知识、方法和经验应用于软件的设计，实施，测试和记录[6]。
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 应用系统的、规范的、可量化的方法，来开发、运行和维护软件[7]。
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 关注软件生产各个方面的工程学科[8]。
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 建立和使用合理的工程原理，以便经济地获得可靠且在计算机上高效工作的软件。
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 软件工程是一个包含过程、一系列方法和工具的框架[9]。
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 软件工程是处理构建大型和复杂软件系统的计算机科学领域，这些软件系统如此之大和复杂，使得其要有一组或多组工程师来构建[10]。
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 软件工程关注大型程序的构造，协作是大型程序设计的主要机制，中心主题是控制复杂度，管理软件的进化。其中，所开发软件的有效性是至关重要的，软件必须有效地支持用户[11]。
|
||||
|
||||
Dines Bjorner认为[12]，理解软件工程，需要同时回答“how”（如何进行）和“what”（要做什么），而上述关于软件工程的表述，仅仅涉及其中一个问题的回答：
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 软件工程是艺术、规范、工艺、科学、逻辑、和实践：
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
\ \ \ \ o 基于科学的洞察，去综合（即构建、构造）软件（即技术），和
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{1.6em}
|
||||
\ \ \ \ o 分析（即学习、研究）现有的软件技术，为了探清和发现其可能的科学内容。
|
||||
基于此，他给出了关于“软件工程”概念的具体刻画[12]：
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 软件工程师需要建立和使用可靠的方法，以有效地构建令人满意的软件，该软件可以解决用户确认的问题
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 软件工程扩充了计算机科学领域，以涵盖软件系统的构造，这些软件系统常常非常大也非常复杂，需要一组或多组工程师协作完成
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 软件工程是一门学科，它把通过学习和实践获得的数学知识，加以判断优化成为应用数学的方式，以（1）理解问题领域；（2）解决现实问题；（3）为这些通常通过计算来解决的问题，开发计算系统，建立软件解决方案
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 软件工程由一下三部分组成：（1）领域工程（以理解问题领域）；（2）需求工程（以理解问题及它们的解决方案的可能框架）；（3）软件设计（以实现想要的解决方案）
|
||||
|
||||
从上述分析可知，软件工程要解决的问题是\textbf{如何高效地开发出符合要求的产品}。这中间包含三个方面的含义。第一，软件工程的产出是一类产品，其产品形态是\textbf{软件}，这决定了软件工程学科的研究对象。第二，软件工程需要高效高质地开发出这类产品，工程化是使产品开发得以高效的一种手段，工程化一般依赖于管理有序的\textbf{生产过程}，生产过程中要依据的合适的\textbf{方法}，以及可操作的\textbf{质量保证手段}。这构成了窄义的软件工程学科的研究范畴。第三，软件产品是用来解决现实世界的\textbf{领域相关问题}的，它的使用需要能为相关领域带来\textbf{价值}，更进一步地，领域价值的评判已经超出窄义的软件工程的范畴，其论域范畴扩展到了应用领域中，因此，\textbf{领域工程}进入广义的软件工程学科范畴，同时，\textbf{需求工程}需求工程成为领域工程和窄义的软件工程的之间的桥梁。
|
||||
|
||||
软件工程学科所针对的关键问题包括：（1）如何理解所面对的问题领域；（2）如何理解当前需要软件来解决的问题，以此推断可能的解决方案；（3）如何高效高质地开发出能胜任的软件。
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[scale=0.3]{fig1-4/fig1.png}
|
||||
\caption{软件工程学科组成成分}
|
||||
\label{fig:fig1}
|
||||
\end{figure}
|
||||
|
||||
概述地说，软件工程的内涵可以用图\ref{fig:fig1}展示。其中内核三部分为软件工程的核心内容，包括领域工程、需求工程和软件系统设计与实现三部分，这三个部分形成广义上的软件工程的学科内涵。其中，软件系统设计与实现是软件工程学科的主体内容，也是软件工程50年来发展最快的部分。其针对的问题是：如何高效高质地开发出能胜任的软件系统，其知识和技术体系体现在软件工程的方法、过程、质量保证及其相应的支撑工具上，这部分内容将在第3节予以描述。
|
||||
|
||||
软件工程相比与传统的工程学科，其最大的不同在于它的跨行业性，也就是涉及，领域工程和需求工程就是解决解决软件的跨行业性，其针对的问题包括：如何理解所面对的问题领域（领域工程），和如何理解需要用软件技术来解决的问题（需求工程）。这两部分的内容将在第4节中描述。
|
||||
|
||||
图1外围中的圆圈中还列举了一些与软件工程有适度交叉的领域，包括：计算机科学与技术是软件工程的技术支撑。数学提供了软件工程研究，特别是定量研究中所需的数学工具和理论支撑。管理科学和生态学为复杂软件系统的系统化和工程化管理，以及软件开发和应用生态的建立和可持续发展提供指导。在成为人类社会生活的基础设施后，软件系统需要遵循或受到各项法律法规的约束。系统科学则将成为软件工程应对复杂领域问题的系统方法学。
|
||||
|
||||
从学科知识体系的角度，IEEE SWEBOK Guide V3.0[13]给出了软件工程的15个知识领域（见图\ref{fig:fig2}），包括：软件需求、软件设计、软件构造、软件测试、软件维护、软件配置管理、软件工程管理、软件工程过程、软件工程模型和方法、软件质量、软件工程职业实践、软件工程经济学、计算基础、数学基础和工程基础。这个知识分类体系，除了基础性知识领域外，其它的大部分知识领域可以归属为上述的软件系统设计和实现的内容。软件需求知识领域可以归属为需求工程范畴，但需求分析仅仅是需求工程中的一个很小的部分。该知识分类体系没有涉及领域工程。
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[scale=1]{fig1-4/fig2.png}
|
||||
\caption{IEEE SWEBOK Guide V3.0软件工程知识体系}
|
||||
\label{fig:fig2}
|
||||
\end{figure}
|
||||
|
||||
\section{软件工程方法、过程、质量保障和工具}
|
||||
从研究布局的角度看，软件工程的研究可以分为软件工程方法、软件工程过程、软件质量保障、以及软件工程工具这四个维度。本节下面的部分分别从这几个维度进行介绍。
|
||||
\subsection{软件工程方法}
|
||||
\subsubsection{概述}
|
||||
在软件工程早期，软件开发基本上没有可遵循的方法，程序员只是依据自己的经验并根据需要解决的问题直接编写代码。根据M. H. Hamilton的回忆 [13]，在她负责的早期飞行控制软件开发项目中，当时程序员主要关心的是，理解硬件和软件的关系以及如何利用这类知识来提升软件的性能。由于没有任何辅助工具，程序员最担心的是代码出错，需要不断地花时间进行手工调试。
|
||||
|
||||
在总结早期飞行控制软件开发经验的基础上，M. H. Hamilton设计了一个通用系统语言（Universal System Language, USL）[14]，其灵感来自她对Apollo软件开发过程中出现的错误模式或错误类别的认识。当时，子系统间的接口错误占了软件错误的绝大部分，而且这些错误通常是最难找到和调试正确的。USL给出了不同接口错误的类别定义，通过这些系统定义来识别错误并在系统设计的时候预防它们。 USL定义了六个公理，形成了控制逻辑的数学构造性理论的基础。该语言还在Hamilton Technologies，Inc推出的001 Tool Suite软件上得到实现。
|
||||
|
||||
软件工程方法是用于指导软件开发和维护的结构化方法，主要为了使软件开发和维护具有结构性，使软件开发和维护成为系统化可重复的过程，从而提高软件开发的成功率。随着软件和软件应用的发展，软件工程方法一直在不断地发展，其主要关注点从系统的功能设计和实现（结构化方法）。到面向现实世界问题实体对象的设计和实现（面向对象方法），再到面向现实世界问题求解非功能属性的设计和实现等，使软件开发方法的隐含面不断向现实世界发展。
|
||||
|
||||
除了系统化的软件开发方法，软件开发效率和质量是软件工程追求的一个目标，面向构件的软件工程尝试采用大规模重用的手段，提高软件的开发效率，以及提升所开发的软件的质量。面向服务的软件工程则是另一种基于重用的方法，将其它软件提供的服务作为可重用的构件，软件系统通过重用并无缝集成来自不同提供方的服务来获得。
|
||||
|
||||
除此之外，还有其它一些软件开发和软件工程模式，比如开源软件开发、基于搜索的方法以及敏捷开发等，它们都从不同的角度应对软件开发的问题，解决软件危机，尝试找到软件开发的“银弹”。
|
||||
\subsubsection{结构化系统分析和设计方法 \protect\footnote{https://en.wikipedia.org/wiki/Structured\_systems\_analysis\_and\_design\_method}}
|
||||
结构化系统分析和设计方法（SSADM）是一种系统化的软件分析方法，它发展于20世纪70-80年代，是一种用于分析和设计信息系统的瀑布方法。SSADM是不同流派的结构化方法的综合集成，典型的包括Peter Checkland的软系统方法[15]，Larry Constantine的结构化设计[16]，Edward Yourdon的Yourdon结构化方法[17]，Michael A. Jackson的Jackson结构化编程[18]和结构化设计[19]，以及Tom DeMarco的 结构化分析[20]等。
|
||||
|
||||
SSADM倡导三种建模技术，它们目前还是软件系统数据建模和分析的重要技术：
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 逻辑数据建模：识别、建模和记录要设计的系统的数据需求的过程。建模结果为数据模型，包含实体（业务处理需要记录的信息），属性（与实体相关的事实）和关系（实体间的关联）。建模结果为实体关系模型。
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 数据流建模：识别、建模和记录数据如何在信息系统中流动的过程。展示过程（即将一种形式的数据转换为另一种形式的活动），数据存储（数据存留点），外部实体（将数据发送到当前系统或从系统接收数据的外部系统）和数据流向（数据通过什么路由流动）。建模结果为数据流模型。
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.6em}
|
||||
• 实体事件建模：是一个双向过程，包括实体行为建模，即识别、建模和记录影响每个实体的事件以及事件发生的序列（形成实体的生命历程）；和事件建模，即为每个事件设计一个协调实体生命历程的过程。建模结果为实体生命历程，和事件效果对应图。
|
||||
\subsubsection{面向对象的分析和设计 \protect\footnote{https://en.wikipedia.org/wiki/Object-oriented\_analysis\_and\_design}}
|
||||
面向对象方法起源于20世纪90年代，早期有不同的面向对象方法，它们通常与特定的计算机辅助软件工程（CASE）工具联系在一起。其中比较有代表性的包括，Grady Booch的Booch方法[21]，James Rumbaugh的OMT方法[22]，Ivar Jacobson的OOSE方法[23]。但这三种不同体系下形成的软件制品彼此间难以理解和复用，如何形成一个能够支撑从需求到实现的软件行业标准，成为当时的一个亟需解决的问题。1994年，他们一起合作开发了统一建模语言（UML）[24]，并将他们的方法与其他各种见解和经验集成到Rational Unified Process（RUP）[25]中，自此统一过程成为面向对象分析和设计最流行的方法和参考模型，形成全面的迭代和增量过程的指南和框架，成为软件开发和项目管理的最佳实践。
|
||||
|
||||
面向对象方法强调模块化和可重用性，追求“开放的封闭原则”的实现。如果模块支持扩展，或者模块提供标准化方法来添加新行为或描述新状态，则模块是开放的。这在面向对象方法中通过创建现有类的新子类来实现。如果模块具有明确定义的稳定接口，所有其他模块只能通过这个接口访问该模块，从而限制由于其它模块的改变而引入的交互和潜在错误，则该模块是封闭的。这在面向对象方法中通过定义调用对象上的方法来实现，方法可以是公共的或私有的，即，对象特有的某些行为不会暴露给其他对象。这减少了软件实现中的许多常见错误。
|
||||
|
||||
相比于结构化分析将过程和数据分开考虑，面向对象分析的特点是，关注于从问题领域中识别出来的对象，并围绕这些对象来组织系统需求，通过对象集成系统的行为（流程）和状态（数据）。在设计阶段，面向对象方法侧重于将实现约束作用于分析过程中得到的概念模型上，比如硬件和软件平台，性能要求，持久存储和事务，系统的可用性以及预算和时间所施加的限制等，分析模型中与技术无关的概念被映射到实现类和接口，进而得到解决方案域的模型，强调利用架构模式和设计模式等指导软件架构的设计[26]。
|
||||
\subsubsection{基于构件的软件工程}
|
||||
因为面向对象的软件开发并没有能够支持大规模的软件重用，而软件产业发展带来大量软件资产，特别是可重用软件资产的积累，人们希望能充分利用这些可重用的软件资产，提高软件开发效率，提升所开发软件的可靠性，因而提出基于构件的软件工程\footnote{https://en.wikipedia.org/wiki/Component-based\_software\_engineering}。
|
||||
|
||||
实际上，早在60年代，就已经出现基于构件的软件工程的萌芽，当时程序员建立了可在各种工程和科学应用中重复使用的科学子程序库，当然这些子程序库虽然以有效的方式重用了定义良好的算法，但它们的应用领域有限。基于构件的软件工程建立在软件对象，软件架构，软件框架和软件设计模式的前驱方法之上，可重用构件封装了数据结构和应用于数据结构的算法。
|
||||
|
||||
根据基于构件的软件工程的理念，单个可重用的软件构件可以是软件包，web服务，web资源或一组相关功能（或数据）的封装体。也就是，把相关的功能体/数据资源等放在一个单独的构件中，每个构件内的所有数据和函数在语义上都是相关的。因此，构件可以说是\textbf{实现层的模块化和内聚}。
|
||||
|
||||
构件通过接口相互通信，以实现系统层的协调。当构件向系统的其余部分提供服务时，它采用提供的接口，国定其他构件可以使用的服务，以及它们如何执行此操作。这个接口可看作为构件的签名 – 调用方不需要了解构件（实现）的内部工作方式即可使用它。这个原理称为\textbf{构件的封装}。
|
||||
|
||||
构件的另一个重要属性是\textbf{可替代性}，也就是说，如果一个构件满足另一个构件的接口规范，则在设计时或运行时前一个构件可以替代后一个构件，因而能支持系统版本更新和替代，而不破坏所支撑的运行系统。
|
||||
|
||||
可重用性是高质量软件构件的重要特征。构件模型是构件必须满足的属性的定义，组件组成的方法和机制，目前已经有几种具有不同特征的构件模型，比如：Enterprise JavaBeans（EJB）模型，构件对象模型（COM）模型，.NET模型和公共对象请求代理体系结构（CORBA）构件模型等。
|
||||
\subsubsection{基于搜索的软件工程}
|
||||
许多软件工程任务可以建模位计算搜索、组合优化问题，基于搜索的软件工程就是用来解决这些软件工程任务的。这类方法最早在1976年出现，当时，Webb Miller 和 David Spooner尝试把优化算法用于浮点测试数据的生成[27]。1992年，Xanthakis等将搜索算法用于解决软件测试问题[28]。2001年，Harman 和 Jones正式基于搜索的软件工程[29]。
|
||||
|
||||
SBSE从问题的解空间出发，将软件工程任务转换为可使用元启发式搜索优化算法来处理的计算搜索任务，涉及定义搜索空间或一组可能的解决方案，并使用度量函数（即适应度函数）来测量潜在解决方案的质量，从而实现软件工程任务求解的自动化和智能化。
|
||||
|
||||
SBSE适用于软件开发过程的几乎所有阶段，其中软件测试是主要的应用阶段之一，其他软件工程任务包括，需求分析，软件设计，软件开发和维护等。
|
||||
\subsubsection{敏捷软件开发}
|
||||
敏捷软件开发通过自组织和跨职能团队及其客户/最终用户的协作努力，使需求和解决方案不断演化发展的方法，它倡导适应式规划、演化式发展、尽早交付和持续改进，同时鼓励快速应变和灵活反应。
|
||||
|
||||
实际上，迭代增量开发可追溯到1957年[30]，而演化式项目管理[31]和自适应软件开发[32]也早在70年代就已经出现。90年代，有很多批评针对一些僵化的对软件工程的过度监管、计划和微观管理等重量级方法，许多轻量级方法得以发展，其中包括快速应用开发（RAD）[33]，统一过程（UP）和动态系统开发方法（DSDM），Scrum、Crystal Clear和极限编程（XP），特征驱动开发等。他们都早于敏捷宣言，但现在都被包含进敏捷软件开发方法。
|
||||
|
||||
2001年，17位软件开发人员\footnote{Kent Beck，Ward Cunningham，Dave Thomas，Jeff Sutherland，Ken Schwaber，Jim Highsmith，Alistair Cockburn，Robert C. Martin，Mike Beedle ，Arie van Bennekum，Martin Fowler，James Grenning，Andrew Hunt，Ron Jeffries，Jon Kern，Brian Marick和Steve Mellor。}在犹他州雪鸟度假村开会，讨论这些轻量级开发方法，随后他们发布了“敏捷软件开发宣言”，包含如下十二项原则：[22]（1）通过尽早和持续交付有价值的软件来实现客户满意度；（2）即使在项目后期，也需要拥抱不断变化的要求；（3）经常性地（按周而不是按月）提供可工作的软件；（4）业务人员和开发人员间密切合作；（5）项目围绕有有动机目的的人建立，他们需要得到信任；（6）面对面交谈是最好的沟通方式；（7）可工作的软件是项目进展的主要衡量标准；（8）可持续地向前推进，保持稳定的步伐；（9）不断关注技术进展和良好设计；（10）简单性 - 最大化未完成工作量的艺术 - 至关重要；（11）最好的架构，要求和设计来自自组织团队；（12）团队反思如何变得更有效，并相应地进行调整。
|
||||
\subsection{软件工程过程和过程管理}
|
||||
软件工程师要开发和维护软件，就要完成一系列的活动，比如需求、设计、构造、测试、配置管理等，软件工程过程主要就涉及这些活动。将软件的开发和维护，分解成这样一组活动，主要是为了便于管理。软件开发过程是为了实现事先定义的目标而建立起来的一组活动，这组活动之间有一定的先后顺序，并作为一个整体来实现事先定义的目标。这里所提及的目标就是软件项目管理试图要实现的目标，例如成本、工期以及质量等典型目标。软件过程管理的管理对象就是软件过程，管理的直接目的是为了让软件过程在开发效率、质量等方面有着更好性能绩效。
|
||||
\subsubsection{系统生命周期}
|
||||
系统生命周期是涉及系统存在所有阶段的一个视图，包括概念设计阶段，设计和开发阶段，生产和构建阶段，分发和运行阶段，维护和支持阶段，退役阶段，淘汰和处置阶段。
|
||||
|
||||
概念设计阶段确定需求，定义潜在解决方案，评估潜在解决方案以及开发系统规范，为系统设计提供全面的技术要求指导。设计和开发阶段进行所需系统功能的所有子系统的符合系统规范的设计，定义子系统间的接口，以及整体测试和评估要求，最后生成足以执行详细设计和开发的开发规范。详细设计和开发细化和初始系统规范，产生系统与其预计环境间的接口规范，以及对系统维护和支持要求的综合评估，负责完成产品、工艺和材料的规范。
|
||||
|
||||
在生产和施工阶段，产品将按照产品、工艺和材料规范中规定的要求制造或组装，并在目标环境中进行部署和测试，进行系统评估以纠正缺陷并使系统适应持续改进。完全部署后，系统将用于其预期的操作角色并在其操作环境中维护。最后还必须不断评估系统的有效性和效率，以确定产品何时达到其最大有效生命周期。 考虑因素包括：持续存在运营需求，运营要求与系统性能之间的匹配，系统淘汰与维护的可行性以及替代系统的可用性。
|
||||
|
||||
典型的生命周期模型包括瀑布模型、迭代式模型、增量模型、螺旋模型以及原型法等。对应系统的生命周期，有多种系统开发生命周期模型[33]，主要包括瀑布模型、迭代模型、增量模型、螺旋模型以及原型法等。
|
||||
\subsubsection{软件过程和软件过程管理}
|
||||
软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合。软件过程有广义和窄义之分，广义的软件过程涉及三个维度，技术、人员以及流程，窄义的软件过程就是一组有先后顺序的活动，即流程。其中，流程即是这三个维度中的一维，更重要的，它是连接技术和人员的粘合剂，将技术、人员及流程三者融为整体，软件过程才能在软件开发中真正起到指导作用。窄义的软件过程则只单纯涉及软件开发流程。
|
||||
|
||||
软件过程与软件生命周期紧密相关，一个软件过程既可以覆盖从需求到交付的完整的软件生命周期，也可以仅仅包括其中某些特定开发阶段。例如，一个实现过程就只包括详细设计、编码、代码评审、编译以及单元测试等更为细小的开发步骤。甚至，为了确保代码评审工作的质量，也可以进一步定义、管理和改进代码评审过程。
|
||||
|
||||
软件过程管理涉及对软件开发过程的管理，包括软件过程的建立、执行、监控、评估以及改进等活动。软件过程管理最重要的内容，就是从众多企业的软件开发活动的经验教训中，总结形成的可供参考的模型。最著名的软件过程管理参考模型是能力成熟度模型CMM以及其后续的集成模型CMMI[34]。
|
||||
\subsection{软件质量保证}
|
||||
软件是一种人工制品，需要有相应的软件质量保证（Software Quality Assurance, SQA）机制，包括监控软件工程过程以确保质量。软件质量保证涵盖整个软件开发过程，包括需求定义，软件设计，编码，源代码控制，代码审查，软件配置管理，测试，发布管理和产品集成等。
|
||||
\subsubsection{软件质量标准}
|
||||
目前，已经存在一系列标准用于监控和评估软件生产过程过程，以确保软件的质量，如，ISO / IEC 15504\footnote{https://www.iso.org/standard/38932.html}，其第一个版本专注于软件开发过程，后来扩展到涵盖软件业务中的所有相关流程，例如项目管理，配置管理，质量保证等，是成熟度模型的参考模型，评估者可以根据模型在评估期间收集证据，全面确定所开发产品（软件，系统和IT服务）的能力。其更新版本是ISO / IEC 33000\footnote{https://www.iso.org/standard/54175.html}。其它质量标准还包括ISO/IEC 25000\footnote{https://www.iso.org/standard/64764.html}、ISO/IEC/IEEE 29119\footnote{https://www.iso.org/standard/45142.html}等。
|
||||
\subsubsection{形式化规约}
|
||||
除了采用工程方法来组织、管理软件的开发过程，并根据标准检验过程的正确性外。还有一类工作就是深入探讨程序和程序开发过程的规律，建立严密的理论，以其用来指导软件开发实践，这类工作推动了形式化方法的深入研究，其目标是以严格的数学推演为基础，通过对系统的形式规约、验证和逐步精化来构造并实现软件，从而提高软件设计的可靠性和鲁棒性。通过对系统的形式规约、验证和逐步精化来构造并实现软件。其中，形式规约是使用形式语言构建所开发的软件系统的规约，对应软件生命周期不同阶段的制品，刻画系统不同抽象层次的模型和性质。形式化开发就是构造并证明形式规约之间的等价转换和精化关系，以系统的形式模型为指导，通过逐步精化，最后开发出满足需要的系统，也称为构造即正确(Correct by Construction)的开发。
|
||||
|
||||
特别值得一提的是，南京大学徐家福教授领导的科研团队，它从规约到实现，开发了多个软件自动化系统。中科院唐稚松院士领导的科研团队，提出了XYZ系统，是由一个时序逻辑语言XYZ/E，以及围绕该语言的一组软件工具组成，XYZ/E第一个可执行的时序逻辑语言[35]。中科院董韫美领导的科研团队，提出了基于复用的文法推断方法，提出一种新的递归函数理论，研究开发了支持系统MLIRF[36]。
|
||||
\subsection{软件工程工具}
|
||||
软件工程工具是辅助软件开发人员、运维人员、管理人员等不同软件开发过程参与者的各类软件产品的总称。软件开发工具软件工程工具从软件工程概念早期的编程工具、软件过程管理工具以及软件度量工具，逐步发展为服务于软件整个生命周期的整套工具链，并且在不同的软件工程环节存在多种可供选择的软件工程工具产品。丰富的软件工程工具一方面为软件开发人员提供了更加高效便捷的开发方法和能力，另一方面也给增加了软件开发人员的学习成本。同时，面向软件工程过程不同环节的软件工程工具，也促进了软件工程的领域细分，不同的软件工程工具对工具使用者的不同技能要求，使得软件工程技能培训和学习更加细化和专业化。
|
||||
|
||||
根据软件工程工具所服务的人员角色不同，可将软件工程工具分为软件开发工具、软件运维工具、软件开发管理工具等。后续将对各类软件工程工具的历史和现状进行简要回顾。
|
||||
\subsubsection{软件开发工具}
|
||||
早期的软件开发主要针对特定的硬件平台特定流程或工具，采用机器语言或汇编语言，并没有独立的软件开发工具。20世纪五六十年代，随着Fortran、Basic等高级语言的出现，计算机程序逐步脱离了面向特定硬件系统的束缚，更加接近于自然语言而易于开发人员书写。开发人员使用文本编辑工具编写代码后，使用代码解释或编译工具将源代码转换为操作系统可以识别的代码，进而完成预期的程序动作。广义上来说，文本编辑器和编译器都可以看作最原始的软件开发工具。然而，通用文本编辑工具在编写代码时无法提供语法高亮、编译、调试等功能，因此集成开发环境（IDE）逐渐发展起来。20世纪80年代，通用编程语言Ada带有自己的编程支持环境APSE提供了编辑界面、编译器、测试器、连接加载器等功能模块，将集成开发环境提升到一个新的阶段。此后，微软（Microsoft）、宝蓝（Borland）等软件公司相继开发出各自的开发环境用于支持相应编程语言的开发与调试。IDE的出现为软件开发人员在开发过程中集中完成软件开发任务提供了统一的环境，也为后续进一步扩展新软件工程工具奠定了基础。从早期的基于字符界面的开发工具到以视窗为特征的图形界面集成开发环境，从软件企业开发的商用集成开发环境到开源社区主导的开放式插件式集成开发环境，软件开发工具随着程序语言、开发技术、开发过程的变化日益复杂。例如，1987年宝蓝公司推出的Turbo C开发环境，在字符界面上提供了灵活的代码编写和调试环境，使得开发人员能够一站式完成程序编写、测试和调试。1991年为了适应微软公司的视窗（Windows）操作系统界面风格，宝蓝公司又推出Borland C++，并在90年代后期推出Borland C++ Builder提升了集成开发环境的易用性和代码编译链接的效率。在这个工具的升级过程中，不仅需要适应C/C++语言标准的变化、操作系统的变化，还考虑了开发人员的易用性需求，通过可视化的窗体设计器、对象观察器等可视化元素加入到开发环境中，推出了VCL构件库，引领了快速应用程序开发（RAD）开发方法，大大降低了开发Windows应用程序的难度。
|
||||
|
||||
随着软件日益复杂和开发过程的不断演进，仅提供代码编辑、调试能力不足以支撑丰富的软件工程活动。开放式架构的开源集成开发环境以插件的形式提供各类辅助支持，包括在开发环境中提供各类代码静态扫描功能、代码重构功能、代码自动补全和框架自动生成功能等，大大扩展了集成开发环境的能力范围，使之能服务于不同的开发过程活动。例如最初由IBM公司主导开发的Eclipse在2001年开源转入非盈利组织Eclipse基金会管理后，开源社区的大量开发者为其开发了众多实用的功能，进而衍生出了MyEclipse、IBM Rational Software Architect等多种工具软件，服务于不同层次和复杂程度的开发需求。
|
||||
|
||||
特别值得一提的是，在中国有一项重大工程就是青鸟工程[37]，由北京大学牵头，从“六五”开始一直到“十五”，经过很长时间的科技攻关，这项工程有很多单位参加， 在“七五”期间，有11个单位 100多位科技成员，“八五”期间有22个单位338位科技成员，遍布了全国各地。青鸟工程的目标是以实用的软件工程技术为依托，建立软件产业基础，推行软件工程化、工业化生产技术和模式，提供软件工业化生产手段和设备，形成规模经济所需的人才储备、技术储备、产品储备。它从基础研究，到实用化、产品化技术的研究，到工程化、工业化生产技术的研究。它的关键是创新，这个创新不仅是概念的创新，还是机制的创新和技术的创新，目的就是使得手工作坊式通过工业化生产技术和工程化开发方法，设计支撑环境与工具，构建标准规范体系，提出了青鸟软件生产线模式，实现作坊式的开发方式到工业化生产方式变革，这是中国软件产业建设的共性和基础性工作。
|
||||
\subsubsection{软件运维工具}
|
||||
软件的运行和维护是软件交付后的必要环节。在以桌面应用为主的上世纪90年代以前，软件产品要么以商业现货（commercial-off-the-shelf）形式提供给最终用户，要么以商用服务项目的形式在客户现场（on-site）提供支持。此时，软件的运维主要是软件日志的收集与分析。通常只能通过现场日志的分析获知软件的可能问题，进而在开发环境中进一步测试、验证、修改软件以修复相关问题。在这种模式下，软件运维工具往往并不受重视，并且通常是融合在软件开发工具中的，即需要通过软件开发过程中写入必要的日志信息，才能实现必要的运行维护工作。随着互联网应用和应用的服务化进程的开启，21世纪以来，服务化和云化的软件使得软件运维从客户端现场支持逐步转向后端、云端。此时的软件运行具有在线动态地特性，不仅需要运行时的日志记录与分析，还需要能快速响应特定的运行问题，并快速给出维护方案、上线修复的软件产品。软件运维从简单的运行日志分析和调错，逐步向实时监控、快速响应的反向发展，这也带来了开发运维一体化（DevOps）的兴起。由此，软件运维工具范围迅速扩大，形成了涵盖开发、构建、测试、集成及交付、容器平台等个子领域的工具集。例如自动化构建是持续集成的重要支撑，支持持续集成的工具包括开源工具Jenkins、商用工具Bamboo以及商用开源版本并存的Travis等。这些工具的特性分别适应特定的应用群体或用户，运维人员可实现多种运维工具的按需选择。
|
||||
\subsubsection{软件管理工具}
|
||||
软件管理工具特指在软件开发过程中使用的，不直接产出软件中间制品或最终制品的辅助工具。软件管理工具主要面向软件开发管理人员，同时也服务于软件开发活动所有参与者。这些辅助工具包括项目进度管理工具（如MS Project）、软件版本管理工具（如SVN、Git、ClearCase）、在线细粒度任务安排和看板工具等，对软件开发过程、制品进行。从软件工程概念提出依赖，采用工程化的管理手段使得软件的开发过程变得可见、可控、可度量、可预测是这些工具的终极目标之一。这些工具随着软件工程学科发展和研究内容的变化而不断改进，新的工具不断涌现，体现了软件工程学科的活力。例如，随着敏捷方法被软件工程实践逐步接受，以软件工具形式出现的看板软件也发展起来，开始作为传统的物理看板的补充，在异地分布式团队等场景中广泛地使用。尽管目前此类软件仍然存在诸如易用性、可配置性等缺陷，但作为新兴的软件工程工具，若能通过触摸交互式高分辨率显示等技术改进实现随时随地的交互，那么对精准高效地管理团队内部人员的开发进度、协调团队交互沟通，都会具有非常重要的价值，应用前景非常广阔。可见，软件管理工具仍然是提升软件开发工程化能力的重要工具集。
|
||||
\section{软件需求工程}
|
||||
当软件变得复杂，需要对软件的需求进行分析，以此构造综合性的问题求解方案，当软件系统变得更加复杂，则需要有一整套的过程和相应技术，指导和帮助软件开发人员系统化地进行用户的需求识别和分析，确定软件能力需求，从而构造问题场景的整体的解决方案。从而出现独立的研究方向：需求工程[38]。需求工程有三个关注点：环境（可改进点）、期望需求（关注的改进方面）、和软件系统需求（可实现性）。
|
||||
|
||||
简单说，需求工程就是：现实世界中存在需要解决的问题、可改进的地方、或者可能蕴含的机会等，然后在圈定的范围内认知并明确刻画出想要解决的问题，最后依据当前可行的信息技术手段，设计出问题求解的方案，并认证该解决方案的可行性和有效性。因此需求工程的主要任务就是观察现实世界机会、识别和定位现实需求、分析和建模软件需求、验证和管理软件需求等。
|
||||
|
||||
由于需求工程的出发点是观察现实世界并进行问题识别，根据现实世界问题识别的不同角度，出现了不同的需求工程方法，主要的需求工程方法包括：面向目标的方法[39]、面向主体和意图的方法 [40]、面向情景的方法[41]、问题框架方法[42]、环境建模方法[43]等。这些方法的特点和需求工程技术见表1所列。
|
||||
\begin{table}
|
||||
\centering
|
||||
\small
|
||||
\caption*{表1. 代表性需求工程方法}
|
||||
\begin{tabular}{|p{0.1\textwidth}<{\centering}|p{0.2\textwidth}<{\centering}|p{0.28\textwidth}<{\centering}|p{0.27\textwidth}<{\centering}|}%
|
||||
\hline
|
||||
方法& 问题视角& 软件需求获取手段& 软件需求获取手段\\
|
||||
\hline
|
||||
面向目标的方法& 现实世界中存在新的需要达成的业务目标& \makecell[l]{ • 识别高层目标\\
|
||||
• 自顶向下，按照业\\ \protect\quad 务目标实现策略进\\ \protect\quad 行目标分解，直到\\ \protect\quad 获得可操作目标}
|
||||
& \makecell[l]{• 可操作目标的可实\\ \protect\quad 现性分析\\
|
||||
• 自底向上的逐层目\\ \protect\quad 标可满足性分析\\
|
||||
• 目标冲突的检测和\\ \protect\quad 协商}
|
||||
\\
|
||||
\hline
|
||||
面向主体和意图的方法& 现实世界存在需要维系的自治个体/组织的关系& \makecell[l]{• 个体/组织间依赖关\\ \protect\quad 系识别\\
|
||||
• 个体/组织策略的目\\ \protect\quad 标建模\\
|
||||
• 个体/组织的反依赖\\ \protect\quad 关系以及反依赖关\\ \protect\quad 系应对策略
|
||||
}& \makecell[l]{• 依赖关系的可满足\\ \protect\quad 性和鲁棒性分析\\
|
||||
• 依赖路径的脆弱性\\ \protect\quad 分析\\
|
||||
• 反依赖关系的防御
|
||||
}\\
|
||||
\hline
|
||||
面向情景的方法& 现实世界中的业务流程需要自动化支撑& \makecell[l]{• 现实场景抽象和建\\ \protect\quad 模。\\
|
||||
• 现实场景模型脆弱\\ \protect\quad 点分析和改进点确\\ \protect\quad 定，如活动改进和\\ \protect\quad 流程改进。\\
|
||||
• 改进策略确定
|
||||
}& \makecell[l]{• 场景流合理性分析\\
|
||||
• 场景流可行性分析\\
|
||||
• 场景流资源/环境依\\ \protect\quad 赖性分析\\
|
||||
• 场景流最优化分析
|
||||
}\\
|
||||
\hline
|
||||
问题框架方法& 软件处于环境中，软件的能力需求由需要和环境进行的交互决定& \makecell[l]{• 识别软件上下文\\ \protect\quad （环境）\\
|
||||
• 抽象环境实体的特\\ \protect\quad 征\\
|
||||
• 在环境实体上确定\\ \protect\quad 用户需求，以此确\\ \protect\quad 定软件与环境实体\\ \protect\quad 的交互\\
|
||||
• 根据交互特征识别\\ \protect\quad 问题框架
|
||||
}& \makecell[l]{• 构建上下文图。环\\ \protect\quad 境实体识别\\
|
||||
• 构建问题图。基于\\ \protect\quad 环境实体确定用户\\ \protect\quad 需求，系统/环境交\\ \protect\quad 互识别\\
|
||||
• 进行问题投影。子\\ \protect\quad 问题识别，基本问\\ \protect\quad 题框架匹配
|
||||
}\\
|
||||
\hline
|
||||
环境建模方法& 软件处于环境中，环境的行为模型和意图确定软件的功能和非功能需求& \makecell[l]{• 识别软件的上下文\\ \protect\quad （环境）\\
|
||||
• 环境模型已存在，\\ \protect\quad 继承环境实体模型，\\ \protect\quad 否则\\ \protect\quad 构建环境实体模型\\
|
||||
• 按业务场景定义用\\ \protect\quad 户需求\\
|
||||
• 确定系统和环境的\\ \protect\quad 交互，根据需求约\\ \protect\quad 束和环境实体约束，\\ \protect\quad 确定系统能力，包\\ \protect\quad 含功能和非功能性
|
||||
}& \makecell[l]{• 特定领域的环境建\\ \protect\quad 模\\
|
||||
• 业务场景定义及其\\ \protect\quad 环境约束叠加\\
|
||||
• 基于业务场景逻辑\\ \protect\quad 的系统需求识别
|
||||
}\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\section{领域工程}
|
||||
领域工程\footnote{https://en.wikipedia.org/wiki/Domain\_engineering}，是支持软件开发中全面系统化重用领域知识的整个过程。领域工程的出发点是，大多数软件系统都不是全新的系统，领域工程可以通过使用同领域相似系统的模型和代码，提高新软件的开发效率额和质量，降低成本。因此，领域工程面向特定领域装煮鱼捕获和收集可重用的软件制品，以便在与之相对的应用工程中重用。与应用工程相对应，领域工程也分为分析、设计和实现三个阶段。
|
||||
|
||||
领域分析侧重于识别和定义领域，并生成领域模型。面向特征的领域分析方法[44]是具有代表性的领域分析方法。领域分析的来源是某领域过去产生的制品，包括现有系统及其如设计文档，需求文档和用户手册等制品。领域分析的目标是将根据已知的领域知识进行扩展，通过领域特征建模，识别领域的公共特征，以及存在的差异性，从而支持领域需求的可配置性。领域设计根据领域分析阶段生成的领域模型，产生领域中所有系统都能符合的通用系统架构模式，并确定模式的范围以及与模式相关的上下文，以适当限定架构适用的范围。最后领域实现是创建为能有效生成本领域客户化软件使用的过程和工具。
|
||||
|
||||
最早的代表性领域工程是产品线工程，以产品特征建模为基础，又称面向特征重用 [44]，FORM通过领域工程过程，支持开发可重用的体系结构和构件，并支持使用领域工程生成的领域制品开发应用程序。 FORM首先分析出领域特定领域中应用程序在服务、操作环境、领域技术和实现技术等方面共性的或者差异性的功能特征。这个分析过程构建出来的模型被称为特征模型。 该模型则可用于定义参数化参考体系结构和在实际应用程序开发时可实例化的适当的可重用构件。
|
||||
|
||||
特别一提，我国陆汝钤院士提出并建立基于领域建模的软件工程[45]，采用知识工程方法建模领域知识，并支持全过程领域模型驱动的软件开发。
|
||||
\section{结束语}
|
||||
|
||||
随着信息技术的飞速发展，软件系统无处不在，其应用形态呈现出泛在化、社会化、情境化、智能化等特征，软件正逐步成为人类社会不可或缺的基础设施。软件工程方法和技术的进步支撑了整个的软件应用的展开，体现在软件系统的规模越来越大，所解决的问题越来越复杂、交互对象越来越多样，人们寄予越来越高的可靠性要求。现在，人机物融合应用模式的不断深入，“泛在系统”和“软件定义”也成为呼之欲出的着力点。这既孕育了软件工程学科的新的增长点，也给软件工程方法和技术带来了新的挑战，需要有新的软件工程方法和技术支撑。
|
||||
|
||||
早期代表性的研究工作包括，
|
||||
|
||||
2000年开始，在互联网发展的环境下，提出了并率先开展了研究，面向互联网计算的新型软件——网构软件，这是在面对互联网的发展而提出来的一个新型的软件开发环境。网构软件被列为国家科技计划的重要方向。从2002年起，连续获得三期973计划项目支持，在国际上也产生了广泛的学术影响。
|
||||
\section{参考文献}
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[1] P. Naur and B. Randell, eds., Software Engineering: Report on a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968, NATO Scientific Affairs Div., Jan. 1969
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[2] E. W. Dijkstra, The Humble Programmer, Communication of ACM 15(10): 859-866, 1972
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[3] F. P. Brooks, The Mythical Man-Month, Addison-Wesley, 1975
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[4] F. P. Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, Computer, 20(4): 10-19, 1987
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[5] P. Laplante, What Every Engineering Should Know about Software Engineering, Boca Raton: CRC, 2007, ISBN 978-0-8493-7228-5
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[6] Systems and software engineering -Vocabulary, ISO/IEC/IEEE std 24765:2010(E), 2010.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[7] IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[8] Ian Sommerville, Software Engineering, Harlow, England: Pearson Education, 1982.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[9] R. S. Pressman, Software Engineering: A Practitioner’s Approach, Mc Grew Hill, 2005
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[10] C. Ghezzi, M. Jazayeri and D. Mandrioli, Fundamentals of Software Engineering, Prentice-Hall, 2002
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[11] H. van Vliet, Software Engineering: Principles and Practice, John Wiley \& Sons, Ltd., 2000
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[12] Dines Bjorner著（刘伯超、向剑文等译），软件工程（卷1-卷3），清华大学出版社，2010年
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[13] M. H. Hamilton, What the Errors Tell Us, Software Engineering’s 50th Anniversary, IEEE Software, September/October 2018, 32-37
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[14] M. H. Hamilton and W. R. Hackler, Universal Systems Language: Lessons Learned from Apollo, IEEE Computer, Dec. 2008, 34-43
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[15] P. Checkland and J. Scholes, Soft Systems Methodology in Action, Wiley, 1990
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[16] E. Yourdon and L. Constantine, Structured Design: Fundamentals of a Discipline of Computer Program and System Design, Prentice-Hall, 1979
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[17] E. Yourdon, Modern Structured Analysis, Yourdon Press, 1989
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[18] M. Jackson, Principle of Program Design, Academic Press, 1975
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[19] M. Jackson, System Development, Prentice-Hall International, 1983
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[20] T. DeMarco, Structured Analysis and System Specification, Prentice Hall, 1979
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[21] G. Booch, R. A. Maksimchuk, M. W. Engle, J. Conallen, B. J. Young and K. A. Houston, Object-Oriented Analysis and Design with Applications (2nd Edition), Addison-Wesley, 1993
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[22] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall International, 1991
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[23] I. Jacobson, Object Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley Professional, 1992
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[24] I. Jacobson, G. Booch and J. Rumbaugh, The Unified Software Development Process, Addison Wesley Longman, 1998
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[25] P. Kruchten, The Rational Unified Process: An Introduction, Addison-Wesley, 2004
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[26] E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns, Addison-Wesley Professional, 1994
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[27] W. Miller and D. L. Spooner, Automatic Generation of Floating-Point Test Data, IEEE Transactions on Software Engineering. SE-2 (3): 223–226, 1976
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[28] S. Xanthakis, C. Ellis, C. Skourlas, A. Le Gall, S. Katsikas and K. Karapoulios, Application of genetic algorithms to software testing, Proceedings of the 5th International Conference on Software Engineering and its Applications: 625–636, 1992
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[29] M. Harman and B. F. Jones, Search-based software engineering, Information and Software Technology. 43 (14): 833–839, 2001
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[30] C. Larman and V. R. Basili, Iterative and Incremental Developments: A Brief History, IEEE Computer, 36(3): 47-56, 2003
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[31] T. Gilb, Evolutionary development, ACM SIGSOFT Software Engineering Notes. 6 (2): 17, 1981
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[32] E. A. Edmonds, A Process for the Development of Software for Nontechnical Users as an Adaptive System, General Systems, 19: 215–18, 1974
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[33] J. Martin, Rapid Application Development, Macmillan, 1991.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[34] M. B. Chrissis, M. Konrad and S. Shrum. CMMI: Guidelines for Process Integration and Product Improvement, Addison-Wesley Professional, 2003.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[35] 徐家福，吕建，软件语言及其实现，科学出版社，2000
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[36] 陈海明，董韫美. 一个支持规约获取的形式规约语言.《计算机学报》第25卷第5期, 2002年5月, pp.459-466
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[37] 杨芙清，中国软件工程五十周年纪念院士论坛报告，2018年11月
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[38] K. Pohll, Requirements Engineering: Fundamentals, Principles and Techniques, Springer-Verlag, 2010.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[39] A. van Lamsweerde, Requirements Engineering: From System Goals to UML Models to Software Specification, John Wiley, 2009
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[40] E. Yu, Social Modeling for Requirements Engineering, MIT Press, 2010
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[41] A. G. Sutcliffe, Scenario-Based Requirements Engineering, Proceedings of IEEE International Requirements Engineering Conference (RE2003): 320-329, 2003
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[42] M. Jackson, Problem Frames: Analyzing and Structuring Software Development Problems, Addison-Wesley, 2001
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[43] Z. Jin, Environment Modelling based Requirements Engineering for Software Intensive Systems, Elsevier, Morgan Kaufmann Publisher, 2017
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[44] K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin and M. Huh, FORM: A feature-oriented reuse method with domain-specific reference architectures, Annals of Software Engineering, 5: 143-168, 1998
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[45] R. Lu and Z. Jin, Domain Modeling based Software Engineering, Kluwer Academic Publishers, 2000.
|
||||
|
||||
|
|
@ -0,0 +1,180 @@
|
|||
|
||||
\section{概述}
|
||||
软件产业是战略性新型产业的重要组成部分，在推动传统产业升级转型、促进经济结构调整和发展方式转变、拉动经济增长和扩大就业、变革人类生产生活方式等方面发挥着日益重要的作用。
|
||||
|
||||
随着软件从依附于计算机硬件的程序逐步发展为独立的产品，并且门类逐渐丰富，与软件产品、服务相关的组织和团体在协作和竞争中逐渐形成产业链、产业圈，其重要性已经国民经济中显现。2018年我国软件和信息技术服务企业数超过3.7万家，从业人数达到643万人，软件业务规模（包括软件产品、信息技术服务、嵌入式系统软件）达到6.3万亿元[3]。据预测，2019年全球信息技术产业规模将达5万亿美元，其中软件和信息技术服务业占比将达32\%，物联网软硬件、云计算、大数据等新兴领域将占17\%[4]。
|
||||
|
||||
软件学科与软件产业相互促进、共生共荣。软件产业的发展推动着软件学科的进步，软件产业的繁荣与分化对软件学科的演进与细化提出了更高的要求。同时，软件学科服务于软件产业，支撑软件产业的发展和壮大。软件学科从理论和实践上对软件产业的繁荣发挥着越来越重要的作用。
|
||||
|
||||
本章将概述软件产业概念和软件产业的生态构成，回顾软件产业的形成、发展的历程，接着从软件技术与软件产业的互动的视角阐述软件产业生态不同阶段的特点和不同的侧面，分析软件产业随着应用场景和应用领域的细分所形成的不同产业生态格局，揭示软件学科在软件产业发展中的推动作用和软件产业对软件学科演进的需求牵引。通过软件产业生态不同阶段和侧面的讨论，揭示软件产业的发展趋势，以及软件学科对支撑软件产业和国民经济发展的重要作用，力图为软件学科更好地服务于产业和经济发展需求提供有用的信息。
|
||||
|
||||
\section{软件产业和软件产业生态}
|
||||
软件产业是为有效地利用计算机资源而从事计算机程序编制、信息系统开发和集成及从事相关服务的产业[1]。软件产业通常分为软件产品业和软件服务业两大部门。因此也有学者将软件产业定义为“与软件产品和软件服务相关的一切经济活动与关系的总称”[2]。
|
||||
|
||||
软件产业这一概念的外延非常广泛。在工信部中国电子信息产业发展研究院编著的中国软件产业发展蓝皮书系列中，软件产业细分为基础软件产业、工业软件产业、信息技术服务产业、嵌入式软件产业、云计算产业、大数据产业、信息安全产业等。中国软件行业协会的软件产业研究报告中，将软件产业分为软件产品和软件服务，而软件产品进一步分为系统软件、支撑软件和应用软件，软件服务则涵盖了与软件相关的服务内容。国际数据公司（IDC）将软件产业细分为应用解决方案（Application Solutions）、应用开发及配置软件（Application Development and Deployment Software）和系统基础软件（System Infrastructure Software）。从更广泛的意义上来说，软件产品和软件服务越来越深刻地影响并渗入众多传统产业和新兴产业，并随着技术的发展和应用领域的扩展不断细化社会分工，逐步形成围绕特定应用领域的软件子产业。
|
||||
|
||||
一般而言，软件产业涵盖了软件企业、软件产品和服务、软件从业人员（特别是开发者）众多要素，他们之间相互影响、相互依存、相互竞争，形成了一种共生生态。在软件产业生态中，软件企业及其所生产的产品、所提供的服务之间的供需关系形成了软件产业链，而不同的软件产业链之间或互补、或竞争，构建起了错综复杂的产业关系网。
|
||||
|
||||
软件产业生态是软件企业、软件从业人员以及各类各层次、多种类的软件产品与服务的共生体。各类软件产品以及相应的研发企业、人员形成了上下游的产业链，并且产业链的各个局部形成了若干维度的子产业。软件产业生态，从软件产品和服务的相互依赖性来看，从上游到下游，基本可以分析为操作系统、中间件、数据库、应用软件等层次。应用软件中，又可进一步细分出工业软件（包括企业管理信息系统等软件）、个人软件（以个人使用为目的的软件）。软件产业链上不同种类的软件及其开发者、开发企业形成了相互关联的多个子产业圈。下游的软件子产业很大程度上受到上游软件子产业的制约，而另一方面又在一定程度上促进上游软件子产业的发展。例如，处于软件产业链上游的操作系统等系统软件是下游应用软件运行的基础，因此围绕操作系统等系统软件和各个业务领域的需求所研发的一系列应用软件，与所对应的操作系统形成相互依赖、相互促进、相互制约的生态圈；而随着应用软件的普及使用，基于特定操作系统的应用软件也可能由用户市场驱动发展出支持其他操作系统的版本，进一步扩展了相关软件的生态圈。由此可见，各类应用软件、操作系统等上下游软件以及相应的开发商、用户共同构成了多层次多维度的复杂生态系统。\ref{fig:fig1}
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[scale=0.7]{fig1-5/fig1.png}
|
||||
\caption{软件产业构成}
|
||||
\label{fig:fig1}
|
||||
\end{figure}
|
||||
|
||||
\section{软件产业发展历程概览}
|
||||
软件产业脱胎于计算机产业的发展和进步，与软件技术相互影响、相互促进。软件产业的形成与发展遵循产业分化和进步的一般规律。图\ref{fig:fig2}展示了软件产业发展历程的概貌。
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[scale=0.5]{fig1-5/fig2.png}
|
||||
\caption{软件产业发展历史概览}
|
||||
\label{fig:fig2}
|
||||
\end{figure}
|
||||
|
||||
早期的计算机软件往往附属于计算机硬件。直到20世纪50年代，软件还主要以项目的形式进行定制化开发。这些软件开发项目往往由政府主导，并服务于国防等关键部门，并且只有少量大型服务企业研制。当时，计算机行业的大多数高管不相信软件产品会有重要的市场[5]。
|
||||
|
||||
20世纪60年代，随着计算机硬件能力的提升，软件的规模日益庞大，开发过程日益复杂，出现了软件危机。软件的重要性和独立性也开始逐渐显现。例如，1961年开始研发的OS/360操作系统软件耗费了超过5000人年的工作量，软件成本甚至超过了IBM System/360大型机硬件。60年代中期，出现了一些具有特定用途、可以被售卖给不止一个客户的程序，具有一些产品化的特性，但销售量小，仅能看作是软件产业的萌芽。而与此同时，软件开发和管理中的大量现实问题促使业界思考软件开发的独特之处。1968年软件工程概念提出，标志着对软件及其开发方法的研究进入了一个新的阶段，也预示着软件开发向工程化发展。1969年，计算机企业巨头IBM宣布了软件可作为独立于硬件单独售卖的商品而存在[5]。在此期间，出现了强大的企业解决方案提供商，例如专业的数据库公司，研发数据库等通用型软件以弥补计算机制造商自带软件的不足，但整体规模仍然不大。这种状态几乎持续到20世纪70年代末，绝大多数软件应用程序仍是在主机或微机上按需定制的。在这一阶段，软件厂商已经开始发展起来，并且开始认识到大规模复杂软件开发中的一些问题，推动了软件工程理论的发展。
|
||||
|
||||
20世纪80年代，随着微型计算机的大规模普及，大量软件得到了广泛的使用，软件企业以此为契机得以迅速发展，开启了以软件为销售对象的商业模式[2]，也由此掀起了以数字化为特征的第一次信息化浪潮[6]。在这时期，软件真正开始形成一个独立的产业，不仅有大量的软件开发企业和开发者，还出现了更加广大的软件产品市场和用户，并且越来越独立于特定的计算机硬件，逐步形成独立的产业生态。
|
||||
|
||||
从20世纪90年代中期开始，以美国提出“信息高速公路”建设计划为重要标志，互联网逐渐实现了大规模商用，迎来了以网络化为特征的第二次信息化浪潮[6]。软件从以单机应用为主逐渐呈现出网络化交互特征。大量带有社会化特征的软件开始蓬勃发展，形成了以互联网为基础、以服务化为特征的产业生态。
|
||||
|
||||
当前，随着以智能化为特征第三次信息化浪潮[6]的到来，软件产业正在发生新的变化。新型的融合化应用场景越来越丰富，基于云计算、大数据的智能化应用软件和企业蓬勃发展，基于软件的产品和服务日益多样化精细化，逐渐向传统行业和新兴行业渗透，呈现软件定义一切的产业新生态。
|
||||
在后续的论述中，我们将以软件产业与软件技术互动为主线，从不同阶段和视角回顾软件产业生态，探讨软件产业对软件学科的需求以及软件学科对软件产业的支撑。
|
||||
|
||||
\section{不同阶段和视角的软件产业生态}
|
||||
\subsection{软件产业与软件技术的互动}
|
||||
由软件产业发展历程可以看到，软件产业的发展与软件技术的进步是相互影响、相互促进的。
|
||||
|
||||
当人们意识到软件可以是独立于硬件存在的单独产品时，针对不同目的、具有不同功能特点的软件也逐渐发展出专门化细分的软件技术领域，相应的软件产品也逐渐形成独立的门类。逐渐细化的各类软件产品，极大丰富了软件产业生态结构。
|
||||
|
||||
随着互联网软硬件技术的发展和普及，软件产品从拷贝安装的应用模式，逐渐转向通过网络按需获得的服务模式。软件的应用场景和用户群体的多样化趋势，扩大了软件市场，催生了一批以在线软件服务为主要业务的软件企业。这些企业和各类新型应用需求，反过来又促进了服务化软件技术的创新和发展，形成以服务化为特征的产业生态。
|
||||
|
||||
在软件产业生态和软件技术的发展过程中，软件的复杂性和软件开发的困难也越来越被人们所重视。在不同的产业阶段，如何高效地开发高质量软件成为永恒的话题，不断推动着软件技术的进步和软件产业的发展。从软件开发的角度而言，软件开发方法、工具和环境经历着不同的变化。软件开发者，以及以软件开发工具和环境为主要业务的软件企业，一起构建了独特的软件开发产业生态，与软件技术的共同发展。
|
||||
|
||||
可见，软件产业从早期由产品化构建起产业生态，到后期逐渐发展为以服务化为特征的产业生态，软件技术的发展和变革无所不在。由软件开发方法、环境和工具推动的软件开发产业生态是软件技术发展的重要推动要素。本节回顾以产品化为特征的软件产业生态、以服务化为特征的软件产业生态以及开发者视角的软件产业生态，分析软件产业与软件技术的互动与演变，并揭示软件产业与传统产业的融合化发展新趋势。
|
||||
\subsection{以产品化为特征的软件产业生态}
|
||||
正如传统工业部门在生产力发展过程中不断分化一样，软件也经历了产品门类不断细分的过程。软件从硬件中剥离出来之初，并没有具体的门类细分，从硬件资源管理到具体应用功能都包括在一个混沌的整体中。随着软件需求的不断增长，软件应用的数量不断增多，人们发现有一些共性功能是几乎所有软件的运行都必须具备的，因此就将这些共性分离出来，包装成早期的操作系统，而功能各异的应用功能则在操作系统之上开发运行，形成各类应用软件。后来，人们发现一些应用软件中仍然存在不少逻辑上高于操作系统、同时又存在于多种应用中的共性部分。这些共性部分又进一步被分离出来，有些被单独包装成产品，产生了数据库软件以及其他用于支撑软件运行交互的所谓中间件。而上层的应用软件也在实际应用中针对不同的业务需求不断细分，形成了各类不同的应用软件，孕育了各自的软件开发企业和应用市场。可见，随着软件技术的发展，软件产品经历了共性沉淀、结构细分的过程，而此过程中，每一个细分领域出现了专门的软件技术领域和产品，而产业结构也逐渐丰富。
|
||||
|
||||
本小节以操作系统产品、办公软件产品、中间件产品、工业软件产品为典型代表，概述以产品化为特征的软件产业生态产生与发展过程。
|
||||
|
||||
操作系统是构建现代软件产业生态的重要基石。20世纪60年代，操作系统软件开始逐渐从计算机硬件中独立出来，出现了产品化萌芽。例如，OS/360操作系统能运行在一系列用途与价位不同的IBM System/360大型机上，具有了现代操作系统的独立性和产品化的特征，但仍然依附于特定厂商，也并未形成产业。1969年，贝尔实验室开发开放源码的Unix操作系统，得到了广泛的应用。之后基于Unix的源代码，大量类Unix系统被研发出来，可用于多种计算机硬件。市场上形成了多种独立的操作系统软件产品。例如，加州大学伯克利分校研发的BSD，以及此后的FreeBSD、NetBSD、OpenBSD等衍生产品。20世纪70年代后期，IBM公司推出的个人电脑（PC）催生了面向个人的软件使用场景，为软件产业的发展提供了广阔的空间；80年代，微软通过与IBM公司的合作，成功研制了面向个人计算机的桌面操作系统MS-DOS，成为当时在IBM PC上最常用的操作系统，也带来了大量的软件应用场景，推动了第一波信息化浪潮，促进软件产业的发展和壮大。同期，MacOS在苹果公司Macintosh计算机上也得到了广泛的应用。1983年，嵌入式实时操作系统（RTOS）VxWorks由美国WindRiver公司研发，具有高性能的内核以及友好的用户开发环境，以其良好的可靠性和卓越的实时性，至今仍被广泛地应用在通信、军事、航空、航天等高精尖技术及实时性要求极高的领域中。20世纪90年代，微软公司自行研发新操作系统Windows，通过图形化界面来替换其原有的字符界面为主的DOS系列操作系统。同期，芬兰裔美国软件工程师Linus Torvalds基于Unix研发了Linux操作系统，由于其轻量级微内核的设计和良好的可移植性，目前已经发展为国际主流操作系统之一，并形成了多种变体版本。
|
||||
|
||||
当前，操作系统软件产业在不同操作系统领域呈现各自的发展特点。在服务器操作系统领域，Linux、Unix和Windows是最常见的操作系统软件产品。在桌面操作系统领域，Windows占据最大的市场份额，但是近年来Mac OS和Linux的份额在不断增加。在移动智能终端操作系统领域，Android被华为、三星等众多手机和其他终端厂商使用，而iOS则在苹果公司经营下形成了自己的产品生态。在嵌入式操作系统领域，VxWorks、Windows Embedded、嵌入式Linux等系统软件产品广泛用于工业控制、终端设备等领域，形成了稳中有增的产业份额；我国国产工控实时操作系统SylixOS也在在国内关键系统市场逐步扩展份额，形成对VxWorks等国际产品的替代。云操作系统、智能穿戴操作系统等产品的软件产业规模总体较小，仍有很大的发展空间。
|
||||
|
||||
办公软件是一种重要的服务于日常信息处理的共性应用软件产品\footnote{在我国，办公软件也被归入基础软件。}。由于办公软件产品的普及，各类信息的记录与处理有了便捷高效的平台。其中，最为知名的办公软件包括文字处理、电子表格、演示等。早期的办公软件国外有Word Prefect、Lotus123等，而国内则有WPS等，都具有广泛的部署和深刻的商业影响。随着信息处理的需求越来越大，人们对办公软件的易用性要求也日益提升，推动者各厂商对软件产品的设计不断改进。在操作系统进入图形化“视窗”时代后，相应的办公软件也开启了“所见即所得”（WYSIWYG）的新阶段，大大提升用户体验，并反过来对操作系统的效率和稳定性提出新的要求。
|
||||
|
||||
随着互联网时代的到来，办公软件再次开始出现分化。首先，是在线协作开始逐渐成为办公软件的重要功能，这方面Google Docs等软件系统或者说是在线文档服务带来了更多的便利。其次，互联网模式的兴起，使得面向个人的办公软件的盈利模式不仅仅限于许可收入，在线广告、文档模板等等都成为新的商业模式。例如，金山办公软件是一款非常老牌的办公软件，虽然在一段时间内受到微软办公套件Office产品的强烈竞争，但在互联网思维的新商业模型下，很快就以其轻便、免费的特点，重新获得了国内用户的青睐。金山办公的营收中除去软件授权许可的收入外，超过50\%的收入来自于互联网广告、办公服务订阅等收入。除了商业产品，一些开源办公软件如LibreOffice、NeoOffice等也形成了一定的市场规模。由此可见，办公软件产品也在朝着多元化、市场化、开源化的方向发展。
|
||||
|
||||
中间件是一种重要的基础软件。中间件与操作系统、数据库系统并称为三大类系统软件，但相比于操作系统和数据库，中间件产品出现得更晚。一般认为，中间件是网络环境下处于操作系统等系统软件和应用软件之间的一种起连接作用的分布式软件[mh]。1968年出现的将应用软件与系统服务分离的IBM CICS交易事务控制系统可以看作是中间件产品的萌芽。它在面向最终用户的应用功能与面向机器的系统服务之间提供了中间层的封装，使得各个层次的关注点更加集中。到20世纪90年代，互联网的出现使网络应用和分布式应用登上历史舞台，而其中涉及通信、协同等源于异构性的大量共性问题，复杂性越来越高，需要专门的软件产品来处理。一般认为ATT公司贝尔实验室于1990年推出的用于解决分布式交易事务控制的Tuxedo系统是中间件产品诞生的标志，是一种交易中间件，也是最早的中间件。此后，消息中间件、应用服务器中间件、应用集成中间件（企业服务总线ESB等）、业务架构中间件（业务流程管理BPM等）等各类中间件产品迅速发展起来。典型的中间件厂商包括国外企业IBM、Oracle、BEA等，开源产品组织Apache、JBoss、JOnAs等，以及国内企业金蝶、东方通、中创、普元等，形成了相互竞争、相互补充的繁荣的生态格局。可见，中间件产品的发展过程也是软件技术相关领域日益复杂和细分的结果。
|
||||
|
||||
工业软件是一类典型的面向领域的应用软件，是支撑传统工业企业信息化、提升传统工业企业管理水平的重要软件产品簇。工业软件按涉及的工业业务领域可分为研发设计类软件和业务运营管理类软件。早在20世纪60年代，美国的大型企业就会采购昂贵的计算机设备进行商业信息的处理。但是由于当时计算机硬件和软件之间耦合紧密，软件往往是作为计算机售后的一种服务提供，因此无法形成独立的产业。60年代末70年代初，随着系统软件的出现，通用计算机系统开始普及，由此面向工业生产及其信息化的独立软件开发商开始逐渐出现。直至80年代，随着更便宜的个人电脑和通用操作系统的普及，企业信息化的门槛得以大幅降低，软件技术开始惠及更多的行业。随着工业生产和研发复杂性提升，研发领域如计算机辅助设计（CAD）、辅助分析（CAE）、辅助制造（CAM）、辅助工艺规划（CAPP）、产品数据管理（PDM）、产品全生命周期管理（PLM）等涌现了大量的商业化的软件产品，为相关业务领域带来了显著的生产力优势，很快在各个行业得到普及。在业务运营和管理领域，早期的软件更多集中于管理信息系统（MIS），重点在于以数字化的形式来记录企业管理过程中产生的原始数据以及简单的业务流程。为了更好利用以手工为主的企业既有流程，企业资源规划（ERP）等软件产品诞生，逐渐形成了以计算机软件为中心的企业级管理系统。它不仅仅是对既有业务流程的自动化，而是包含了诸如财务预测、生产能力、资源调度等更具有价值的软件功能，同时对企业经营管理方式产生了深刻的影响。大数据和智能化时代的到来，正在将业务运营管理方面的软件产业水平提升到一个新的高度。
|
||||
|
||||
由此可见，以产品化为特征的软件产业代表着早期桌面化的市场需求，软件企业通过软件销售的形式向各类用户提供商用的软件产品。由于软件产品复制的边际成本非常低以至于可被忽略这一完全不同于传统产业的特性，知识产权保护成为软件产业中的重要企业战略决策[7]，并且持续促进着软件技术的发展。同时，大量用户的特殊需求要求软件企业提供大量的定制功能，因此咨询与实施成为软件产品部署的重要方式，同时也促进企业采用支持可变性建模的开发方法开发面向特定领域的系列软件产品，使得产品化的软件生态更加丰富。随着云计算、移动计算等技术的发展和普及，一些以销售软件产品为主的软件企业开始向云化、服务化转型。软件产业逐步开启以服务化为特征的新阶段。
|
||||
|
||||
\subsection{以服务化为特征的软件产业生态}
|
||||
服务化是互联网技术的产物。互联网软硬件的发展，使得依赖于拷贝安装的软件产品转变为通过网络、按需索取成为可能。软件功能进一步细分为前端以人机交互为主和后端以业务逻辑处理为主两大部分。随着大量的业务逻辑迁移到后端，对后端的计算、存储能力提出了更高的技术要求，逐步发展出了云计算技术与平台；而互联网的广泛可达能力，带来了巨量的普通用户，形成了丰富的互联网应用。
|
||||
|
||||
在以服务化为特征的软件产业生态中，软件的核心价值主要以网络服务的形式呈现。作为产业生态的主体，软件企业大量采用云计算技术提升用户服务能力；同时，软件的用户能够在各类终端上通过网络按需访问所需要的服务。由于软件的服务化、远程化、轻量化带来了具有良好的伸缩性和互操作性，因此，服务化的软件极大地推动了软件产业生态的繁荣。从企业而言，软件的部署和运维得到良好的控制；从用户而言，轻量化的运行提升了使用体验。受限于篇幅，本节以社交类软件和云计算服务为例介绍具有典型服务特征的新型软件产业生态。
|
||||
|
||||
社交类软件体现了人和人之间的连接。这一天然的人际链接的需求，在互联网普及之前，只能通过传统的社交方式来完成。互联网的发展使得社交活动发展到一个完全不同的高度，这也催生了一大批以社交为主营业务的软件公司。社交类软件最早以即时消息服务（IM）的形式出现，例如国外的ICQ、AIM、Skype等，国内的QQ（早期称为OICQ）。由于和社交关系深度绑定，社交软件的盈利模式非常多样，同时这类软件也具有极强的粘性，一旦占据优势地位就非常难于被其他软件所替代。
|
||||
|
||||
互联网模式的变革也为新的社交软件形态的产生带来了新的机会，例如Web2.0时代的到来，在线交流变得更加便捷，也催生了诸如Facebook、Twitter、国内的微博等社交类网站的兴起。它们不再局限于通讯录中的固定的联系人，而是使得互不相识的人际互动变得更加频繁，甚至还出现了以陌生人社交为主要业务软件产品，以及面向职业人士的LinkedIn等软件产品。移动互联网的兴起是另一次变革的浪潮，由于智能手机的用户普及率高且便于随身携带等特点，通过智能手机随时在线使用社交媒体软件成为可能。这催生了新一代的社交类产品如微信、Telegram、Line、WhatsApp等的繁荣。围绕这些应用软件，形成了大量外围软件服务，涉及电子商务、在线支付、招聘择业、娱乐游戏、社会信息服务等众多领域，几乎涉及了社会生活的方方面面。可以说，在新型软件技术的支撑下，相关软件产业生态已经影响到当今社会的主要生活方式。
|
||||
|
||||
云计算服务是新型服务化软件背后的重要技术支撑，提供了大规模并行化定制化的服务能力。其中大规模和并行化处理能力往往来自以虚拟化技术（Virtualization）为基础的云计算服务，而定制化能力则更多依赖于21世纪初发展起来的平台即服务（PaaS概念）。就虚拟化软件而言，其本身以产品化形式出现，但对外提供服务化能力，将计算机的各种实体资源（如CPU、内存、磁盘空间、网络适配器等）进行抽象、转换后，以虚拟设备的方式呈现出来并可供分割、组合为一个或多个计算机环境。自20世纪60年代以来，虚拟化能力随着桌面计算和服务器架构的日益发展不断发展完善，面向不同的底层硬件资源和上层应用需求出现了以KVM、VirtualBox、VMware ESX、Xen等多种虚拟化软件产品，进而出现了用于虚拟环境管理的OpenStack、Amazon EC2等产品。基于虚拟化技术，许多厂商如Amazon、微软、Google、百度、阿里巴巴、华为等，提供了不同层次的在线服务，包括基础设施即服务（IaaS）、平台即服务（PaaS）、软件即服务（SaaS）。基础设施即服务提供在线计算资源和基础设施，比如Amazon、华为、阿里等厂商的服务器租赁等服务。平台即服务提供在线的应用开发和发布解决方案，提升应用开发和运行的灵活性，比如Google App Engine、微软Azure、Force.com等。软件即服务是在线化的软件形态，面向最终软件用户，以在线服务的形式提供面向领域的软件功能，比如SalesForce的CRM系统、Cisco的WebEx等。不同厂商在推出相应的云计算服务同时，往往会提供IaaS、PaaS、SaaS中的一层或多层服务，这也建立了围绕不同软件厂商的产业生态。而不同软件厂商之间的软件产品间形成竞争和补充关系，进而也形成了更加复杂的层次化软件产业生态。
|
||||
|
||||
在软件服务化的趋势下，不论是传统行业还是新兴行业，软件的随处可用、随需而变、按需提供的特性，大大扩张了软件产业的范围，使得软件与人们的生产、生活更加密切接触，成为社会经济生活各个环节中不可或缺的重要组成部分。进而，随着软件能力的提升和应用范围的扩大，小到日常生活、大到城市治理，多元融合的软件开启了以融合化为特征的软件产业阶段。
|
||||
\subsection{开发者视角的软件产业生态}
|
||||
软件开发者是软件产业生态的重要参与者。围绕开发者，软件产业生态经历了从产品到服务、从单机到集群、从闭源到开源多个阶段。与产品视角和服务视角所见的软件产业不同，以开发者为中心的软件产业围绕软件开发工具、方法和服务，形成了一种推动软件产业本身发展的重要动力。软件开发工具软件既是软件产业中用于软件产品开发的工具，同时也是构成软件产业重要组成部分的一类软件产品，具有典型的两面性。因此，本节将从软件开发工具形成的软件产业生态的角度，回顾开发者视角的软件产业历史，分析不同阶段软件开发技术对软件产业发展的支撑。
|
||||
|
||||
软件开发环境经历了单机集成开发环境、支持协同的软件开发环境以及云开发环境等多个阶段，形成了单机集成开发环境和云协同开发环境融合的庞大产业。20世纪80年代以前，软件开发环境主要是针对特定的硬件平台，因此，此时开发工具相关的软件还没有形成固定的产业。随着高级编程语言的出现和普及，各类集成软件开发环境（IDE）逐渐发展起来，形成了具有领域特点的产业雏形。在高级编程语言和集成开发环境的支撑下，软件开发效率大大提升，促进了软件产品的繁荣。20世纪80-90年代，宝蓝（Borland）、微软（Microsoft）等公司推出了各自的开发工具软件，形成了多种开发工具软件竞争的产业局面。随着新的操作系统和中间件的变化，开发工具产业也在发生着适应性的变化。例如，以C和Pascal起家的宝蓝公司在20世纪90年代末到21世纪初，为了应对Java语言的广泛使用，推出了JBuilder系列开发环境；随着Linux的不断普及，推出了Kylix；随着.NET平台的广泛使用，推出了支持.NET的开发工具Delphi 8以及多个后继版本；直至2006年，由于对服务化编程模式支持不足、定价过高等多种原因，Delphi才在竞争中渐渐失去有利地位，被Embarcadero收购；继而由Embarcadero控制的Delphi开发环境工具为了满足服务化、跨平台的软件开发需求，仍然推出新的版本，通过面向移动开发和跨平台特点与微软Visual Studio .NET等工具软件竞争。可见，软件技术的进步推动着软件开发工具产业的持续发展，而开发工具产业生态的兴盛也支撑着软件技术的不断提升与改进。
|
||||
|
||||
与此同时，开源集成开发环境随着Java等语言的兴起而不断发展，形成以开源和协作为特色的软件产业生态，并派生出特有的商业模式。Eclipse是一个典型的例子。Eclipse最初由IBM公司主导开发，并于2001年开源，随后转由非盈利组织Eclipse基金会管理至今。Eclipse项目架构设计灵活，其开源引起了广泛的关注，并得到上百家大型软件企业的参与与贡献。围绕Eclipse这个开源集成开发环境，开源社区的开发者和参与开源社区贡献的软件企业纷纷为该产品开发插件，并得到集成和推广。在此基础上，Eclipse衍生出了MyEclipse等商用版本，以及IBM Rational Software Architect等多种工具软件。此类工具面向软件开发者的不同开发需求，提供不同层次的解决方案和开发环境。这类软件生态往往以开源为核心，通过良好设计的、具有可扩展性的软件架构展现了软件的良好生命力，并且在开源环境下不断发展，同时采用合适的开源许可证允许衍生出商业产品，并通过商业产品的应用与开源版本实现协同的演进。
|
||||
|
||||
随着软件产品日益复杂，开发人员的协同工作更为重要。在协同开发环境下，涉及到不同的开发团队、不同的开发资源如何协调的问题。例如，对协同开发的软件代码，需要有相应的版本控制软件。在版本控制领域，除了经典的ClearCase、Perforce等商业工具之外，还产生了CVS、SubVersion等开源免费工具。由于软件开发的社会化协作程度越来越高，分布式版本管理系统逐渐替代中央控制的版本管理系统成为主流。其中的典型代表是git和mercurial。社会化编程的兴起，又对版本控制之外的社会化协作产生了新的需求，催生了一大批诸如GitHub、Gitlab、Bitbucket、Coding等国内外的开发者社区及协作服务提供商。持续集成需要自动化构建工具的支持，其中既有Bamboo等商业的持续集成工具，也有Jenkins等开源免费的工具，同时还存在以免费为主体、但具有某些收费高级功能，或是面向开源社区免费、但面向商业应用收费的产品，如Go、Travis等。此外，在配置管理、自动化构建和测试、容器和服务平台、日志管理及监控和告警等领域，都出现了许多具有竞争力的产品。
|
||||
|
||||
开发运维一体化（DevOps）运动的兴起，则是在前述实践基础上进一步引发的更为深刻的技术和文化变革。开发和运维不再彼此独立，而是建立了更流畅、更紧密的协作关系。从工具链角度，不仅仅是发布活动，配置、监控及最终用户反馈等环节也融入其中。因为持续集成、持续交付和开发运维一体化的工具链的端到端的特点，基本上囊括了软件开发中从开发到集成交付、从基础运行环境配置到软件配置管理等各个子领域的多种工具的集合，也促进了相关子领域的各工具软件产业的繁荣以及生态的兴盛。从开发者角度而言，大量的开发工具和开发模式为开发者提供了多种提升开发效率和质量的技术途径，同时也带来了更多的技术选择成本和学习成本。如何促进相关软件产业生态良性发展，辅助开发人员更专注于需求，提升开发效率和交付能力，降低学习成本，是一个重要的研究问题。
|
||||
\subsection{以融合化为特征的软件产业生态}
|
||||
第三次信息化浪潮的推进，使得智能化、融合化逐渐成为软件产品和服务的新趋势。从无处不在的计算，到软件定义一切，以融合化为特征的软件产业生态已经开始渗透到社会生活的方方面面。在这新型的软件产业生态中，软件产业链已经不仅涵盖传统运行于计算机硬件上的软件，还进一步覆盖了智能感知设备甚至人。人、机（计算机）、物（智能感知设备）融合是新型软件产业生态中的典型场景。得益于小型微型终端设备、智能终端设备的普及，新型物联网应用促使软件开发商、硬件制造商、服务提供商、系统集成商等多种角色共享智能化、融合化的软件市场份额。例如，在智能家居场景中，各类智能家居设备通过软件定义的方式接入智能家居总控软件，用户能通过在智能手机中安装远控软件实现对家中设备的远程查看、管理和控制。与生活密切相关的空调、电视机、电饭煲、电灯等传统电器产业为软件产业提供了巨大的潜在发展空间。小米、华为等企业已经在相关领域做出了成果丰硕的探索和尝试。又如，近年来以国内饿了么、美团为代表的从线上到线下（O2O）的服务模式，以共享单车、共享汽车为代表的共享经济模式，无不体现了软件与各行业融合的全新产业生态。
|
||||
|
||||
灵活多变、快速定制、多源融合的产业生态对软件本身带来了新的挑战。快速开发灵活可伸缩的软件产品，确保提供高效稳定的软件服务，促使软件开发人员和研究人员对软件的技术架构进行不断的探索创新，也进一步丰富了软件产业生态中生产者和消费者的构成，给软件产业的持续发展带来蓬勃生机。
|
||||
|
||||
|
||||
\section{总结和展望}
|
||||
软件产业生态的建立、发展和繁荣已经经历了超过半个世纪。回顾这五十多年的软件产业发展历程，软件产业生态的建立与软件技术的发展密不可分。随着技术的进步，各类软件产品、软件企业、软件从业人员之间的竞争与合作持续发展，逐步渗透入人类生活的方方面面。“软件定义一切”和“一切皆服务（XaaS）”为软件产业创新发展扩展了新的空间。新一代技术催生新的软件产业细分，促进软件产业向其他各个产业的渗透，形成基于软件的产业融合。同时，传统软件企业在云计算技术的推动下加快自身的服务化转型，全球软件即服务落地明显加快。软件产业的服务化、融合化特征日趋显著，成为软件产业的新增长点，也成为软件技术和软件学科发展的新契机。
|
||||
|
||||
随着越来越多行业对软件和软件技术需求的增长，软件产业将继续发展和细分，并进一步与人类社会生产生活紧密融合。软件产业的细分与服务化、融合化转型，给软件学科的研究带来了新的挑战，需要有符合产业可持续发展要求的研究内容和成果，认识并补足软件产业生态化发展的短板，从而支持和促进软件产业的持续健康发展。
|
||||
|
||||
\section{参考文献}
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[1] “计算机软件产业技术创新战略研究”课题组，计算机软件产业技术创新战略研究报告[R]，1996.12
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[2] 傅荣会，中国软件产业发展的理论与实践[M]，北京理工大学出版社，2017
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[3] 工信部，2018年全国软件和信息技术服务业主要指标快报表[R/OL]，http://www.miit.gov.cn/n1146312/n1146904/n1648374/c6633874/content.html，2019.2，访问时间2019.8
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[4] 美国计算机行业协会（CompTIA）, IT Industry Outlook 2019[R/OL], https://www.comptia.org/resources/it-industry-trends-analysis，2019.1， 访问时间2019.8
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[5] Johnson L., A view from the 1960s: How the software industry began[J]. IEEE Annals of the History of Computing, 1998, 20(1): 36-42.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2em}
|
||||
[6] 梅宏，建设数字中国——把握信息化发展新阶段的机遇[N]，人民日报，2018
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[7] Steinmueller W E., The US software industry: an analysis and interpretative history[R]. University of Limburg. 1995.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[8] 杨芙清，发展我国的软件产业，电子展望与决策，1994.01, 18-19
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[9] 吕建，软件技术与软件产业[J]，科技与经济，2002(Z1):28-32
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[10] Botelho A J J, Stefanuto G, Veloso F. The Brazilian software industry[R]. Georgia Institute of Technology, 2004.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[11] 惠瑜, 罗光春, 李炯. 国内外软件产业发展战略比较研究[J]. 电子科技大学学报: 社会科学版, 2006 (6): 23-26.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[12] 李德升. 全球软件产业发展特点与趋势分析[J]. 全球科技经济瞭望, 2012, 27(4)：52-57
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[13] Takahashi M.， Development Policy of the Chinese Software Industry[J]. 大阪産業大学経営論集, 2015, 16(2): 177-189.
|
||||
|
||||
\noindent
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{2.3em}
|
||||
[14] 中国电子信息产业发展研究院、工业和信息化部赛迪智库，软件产业发展白皮书（2015版）[R]，2015.4
|
||||
|
|
@ -1,15 +1,149 @@
|
|||
% !TEX root = main.tex
|
||||
|
||||
\chapter{总论}
|
||||
|
||||
bla
|
||||
|
||||
\section{节标题}
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{center}
|
||||
\includegraphics[width=.8\textwidth]{figs/以抽象为中心.pdf}
|
||||
\caption{以抽象为中}
|
||||
\label{default}
|
||||
\end{center}
|
||||
\end{figure}
|
||||
\section*{总论}
|
||||
软件承载着文明\footnote{“Our civilization runs on software.” —C++之父Bjarne Stroustrup.}。时至今日，“人-机-物”三元融合\footnote{这里所谓人是指系统中的人类参与者及其社会关系，机是指计算平台和信息空间的数据、软件服务等各种资源，物是指数字化的设备装置和可传感的物品。或曰“信息-物理-社会”三元融合系统。}和软件定义一切的发展趋势使得软件成为信息社会的基础设施。软件科学与工程学科已进入一个新的阶段，其发展日新月异，重要性日益凸显。在本书上篇回顾软件学科发展历程，梳理发展脉络，总结发展规律的基础上，本篇各章讨论在人机物融合的时代背景下，面向软件作为基础设施的时代要求，软件科学与工程的发展趋势、关键挑战与潜在突破，给出学科发展建议。
|
||||
|
||||
软件是以计算为核心手段实现应用目标的解决方案。软件学科是研究以软件求解应用问题的理论、原则、方法和技术，以及相应的工具支持和生态环境的学科。也就是说，软件学科本质上是一门方法论学科【cite N. Wirth】。其带来的是一种人类思维的创新，以人机共融方式延伸了单纯人脑思维，形成了一种前所未有的创造力。随着软件应用范围的扩张,软件的计算平台的泛化和软件方法技术的发展，软件学科的边界不断拓展，内涵不断深化。本章总论“软件作为基础设施”这一发展趋势，进而以系统观、形态观、价值观和生态观四个视角探讨软件学科的方法论新内涵。
|
||||
|
||||
\section{软件作为基础设施}
|
||||
从人类社会信息化的角度看，软件的基础设施地位具体表现为四个方面。首先，一大批基础软件本身就是信息基础设施，支撑各种应用软件的运行。其次，一大批嵌入式软件已成为掌控并支撑物理基础设施运行的关键系统。第三，一大批应用软件及其所提供的服务已成为信息社会不可或缺的基础资源与设施。最后，从软件产业整体的角度看，随着传播和互联的渗透发展，计算成为了人类与物理世界互动的中介，软件成为了创造新文明的载体，大规模、高效率地生产高质量的软件产品和提供软件服务的能力已成为社会经济升级发展的新动能，构成国家的一种核心竞争力。
|
||||
|
||||
软件成为人类社会基础设施是社会信息化进程不断加深的必然结果，其技术基础是“计算的泛在化”和“软件定义一切”。
|
||||
|
||||
“计算的泛在化”是指计算变得无处不在而又无迹可寻。万物数字化、万物互联使得计算无处不在。网络化计算平台迅速拓展到无处不在的各类智能化设备和可传感物体，深入到人类社会生活的方方面面，形成了“人-机-物”三元融合的发展趋势。计算设备、网络设备、存储设备与各类传感器设备、判断设备、决策设备、作动设备所形成的数量众多、大大小小的平台已经互联融合，成为一体。与此同时，对于所服务的用户而言，计算自然融入人类生产、生活活动环境和过程之中，无需关注，不着痕迹。
|
||||
|
||||
“软件定义”是指软件以平台化的方式，向下管理各种资源，向上提供编程接口，其核心途径是资源虚拟化以及功能可编程。“软件定义一切”则将软件平台所管理的资源和提供的编程抽象泛化到包括计算、存储、网络、软件服务等在内的各类计算资源、包括各种数字化机电设备和可传感物体对象在内的各类物理资源、乃至可通过激励机制调配的人力资源。软件定义可递归分层，形成一种生长式、演化式的可扩展体系。这种软件定义的人机物融合平台逐渐呈现了“泛在操作系统“发展方向。
|
||||
|
||||
“软件定义一切”实质上是通用可编程思想在各个领域的应用，是一种以软件实现分层抽象的方式来驾驭复杂性的方法论。数字化使得几乎所有的设备都包含了独立或者集成的计算设备，完成“感知、判断、控制、作动”闭环的部分或者全部。这个改变是信息化发展的基础，使得现代设备或装置往往都具备编程控制的能力，推动了人们基于通用计算机的思维架构（人们总结成计算思维）来理解和求解各领域问题，而通用计算机的软件则定义了问题的求解过程。因此，软件将并正在定义一切。
|
||||
|
||||
\section{软件学科范畴的拓展}
|
||||
作为一门方法论学科，软件学科拓展的驱动力来自软件应用范围扩张、计算平台的泛化和软件方法技术本身发展三个方面。
|
||||
|
||||
从软件应用范围扩张的角度看，正如上文所述，计算日益变得无处不在，“人-机-物”三元融合不断深入。在此趋势下，从宏观上看，软件从实现计算的工具逐步转变为信息社会不可或缺的基础设施；从微观上看，软件的角色也从负责应用过程中孤立、确定的信息处理环节，转变为负责定义并协同整个应用涉及的“人-机-物”各类资源，实现应用价值。软件作为系统解决方案，涉及的范畴扩展到各类物理设备、物品和人类的主观体验与价值实现；因而软件学科无可避免地涉及到控制科学、系统科学以及心理学、管理学、社会学等范畴的问题，并以软件学科自身的方法论将其内化和拓展。
|
||||
|
||||
从软件依赖的计算平台泛化的角度看，计算平台从传统的集中式单机发展到并行与分布平台，到今天的“云-边-端”异构多态计算平台。这个网络化计算平台不仅包括传统的互联网，还融合了传感网、物联网、移动互联网、社交网等，标志着计算平台不断向物理世界和人类社会快速延伸，形成一种泛化的计算平台。软件定义技术为这个“人-机-物”融合的平台提供可编程计算抽象。同时，这个计算平台也使得海量的有关于“人-机-物”融合的应用场景数据不断被收集、处理和积累，成为平台上的重要资源。软件作为应用解决方案，在这个计算平台之上利用数据资源，协同人机物，实现应用价值；同时也通过在这个平台上提供服务，并进一步积累数据，不断拓展这个计算平台。
|
||||
|
||||
从软件方法技术发展的角度看，当前软件的基本形态、所实现的逻辑推理形式、软件开发的隐喻（metaphor）模式、软件的生态环境、元级方法论都在发生深刻的改变。软件的基本形态从计算机硬件的附属品到独立的软件产品，到云化的软件服务，转变为无处不在而又无迹可寻的泛在服务。软件所实现的逻辑推理形式在基于规则的演绎之上发展出数据驱动的归纳，统计机器学习技术就是后者的典型表现。软件开发的隐喻模式经历了从实现数学计算到模拟物理世界，再到虚实融合创造的转变。对软件作为客体对象的考察从以个体及其生产使用为主扩展到在生态的层面上考虑软件及其利益相关者群体的竞争、协作等社会性特征。在元级方法论层面，正从以还原论为主向系统论发展，软件作为解决方案越来越多地被视为开放环境中的复杂适应系统，而不是封闭规约下的确定行为系统。
|
||||
|
||||
随着软件学科的不断拓展，它也逐渐成为一门基础学科，并向其他学科渗透。所谓基础学科，是指某个拓展人类可认识改造的世界疆域之不可替代知识体系，具有独特的思维方式与方法论，为其他学科发展提供不可或缺的支撑。其一个标志是其基础内容进入国民基础教育课程体系。软件学科日益呈现出这些特征：软件是把物理世界拓展为信息-物理-社会融合世界的主要手段；与此同时，“软件定义”赋能的计算思维有可能成为继实验观察、理论推导、计算仿真、数据密集型科学之后的新的研究手段，尤其是为以信息-物理-社会融合系统为对象的科学研究提供赖以运作的理论基础和实践规范。而以软件知识为主体的计算机教育已经成为包括我国在内的多个国家的国民基础教育课程体系的主要内容之一。
|
||||
|
||||
\section{软件科学的新理解}
|
||||
一般而言，驾驭系统固有复杂性的基本途径是有效抽象和层次分解。与其他制品不同，软件是纯粹的逻辑产品，原则上只受能行可计算的限制，可以实现最纯粹的抽象，也可以支持最具扩展性的层次分解。回顾软件学科的发展，贯穿始终的主题是以软件范型（建立抽象）为轴心，系统软件（实现抽象）和软件工程（使用抽象）相互促进、螺旋上升的过程。由于软件在应对复杂性方面具有独特优势，软件成为了各类复杂应用系统的“万能集成器”，也成为了人类构造的最复杂的各类系统的核心。另一方面，正因为此，软件而使得万物互联，其所形成的系统的复杂性往往集中体现为软件的复杂性。
|
||||
|
||||
在软件作为基础设施、软件定义一切的背景下，软件进一步成为构造开放环境下复杂系统的关键。在展望软件学科在新时代所面临的挑战与机遇之前，我们首先在元级方法学，也就是研究方法学的层面上讨论观察软件学科内涵的若干新视角，包括以驾驭复杂性为目标的系统观、以泛在服务和持续演化为特征的形态观、以使用质量为核心的价值观、以及关注群体协作平衡的生态观。
|
||||
\subsection{系统观}
|
||||
所谓软件学科的系统观，有三层含义。第一层含义是系统工程。也就是说，软件学科的关注点应从为应用系统提供高质量的软件部件，上升到关注“人-机-物”整个系统的价值实现。软件定义一切的趋势使得软件不仅仅是系统中的信息处理工具，也是管理各类资源、融合人机物的“万能集成器”，是实现应用价值的整体解决方案。
|
||||
|
||||
第二层含义是复杂系统。现代软件系统的复杂性体现在其前所未有的代码规模、软件处理的数据量、软件用户量和使用的多样性、软件通过网络形成的连接量和种类、涉及承载运行的计算和物理设备量和种类等方面，也体现在其所处环境的开放性和由于“人在回路”所带来的不确定性。这使得看待软件的视角从封闭规约下的确定行为系统向开放环境中的复杂自适应系统、从单体系统向系统之系统转变。
|
||||
|
||||
第三层含义是系统论。对于上述复杂软件系统，常常难以用其组成部件的性质去解释其整体性质。此时单纯依赖还原论方法难以驾驭其复杂性，需要借鉴系统论方法。
|
||||
\subsubsection{系统观下的软件学科发展}
|
||||
软件作为人类智力产品，无论是软件制品本身，还是软件开发、使用过程和场景与万物和人类有着紧密关联，其开发和运行的网络化（网构软件的实践），以及软件基础设施化、服务化都触发了软件生产方式、计算平台和运行方式的变革。软件创新从个人、组织智慧发展到群体智慧创新。软件科学与自然科学、社会科学等各领域产生了千丝万缕的联系，信息物理融合、软件社会化、大数据时代的软件新形态使得软件必然成为技术-社会系统（Socio-Technical System）。人机物融合的软件系统，其复杂性本身就呈现在系统乃至系统之系统的层面上，综合性和系统性也愈来愈强。系统观要求软件科学体系需超越传统还原论的思维藩篱。
|
||||
|
||||
近年来，软件科学在系统观方向上进行了不少探索，包括：基于复杂网络来认识大规模软件系统的整体性质、基于多自主体的软件系统和方法、复杂自适应软件与系统、群体化软件开发方法等。网络化和大数据催发了融合软件系统与系统论研究的切入点，数据驱动的软件设计和优化初显端倪，在一些特定领域获得很大成功。人们对于数据驱动的软件的设计，不再遵循传统的自顶向下、分而治之、逐步精化的经典还原论法则，而是一种基于输入输出的黑盒的数据描述，训练出深度神经网络，充当所需要的软件。这种基于深度学习的方法从海量的样本中归纳出神经网络，其泛化能力可视为通过神经元系统的涌现而达成的功能。然而，这些研究仍处于方法层次，还未到达方法论的层次，即关于研究问题需要遵循的途径和研究路线，也可视作具体方法的元级层次。
|
||||
|
||||
新的软件方法学的关键在于如何认识因果和相关。因果观是有前提的，相对的；相关性是绝对的。软件发展在人机物融合时代，人在回路、“拟人化”计算（Human Computation）、人机共融等需要关于软件规律的元级方法论创新。
|
||||
|
||||
在软件系统的建模方面，软件将从单纯信息处理向“场景计算”发展，这里的场景包括物理环境和社会环境。软件与软件所处的环境或应用场景共同决定了软件特性和价值，包括功能、性能、安全、可靠等。软件将作用于环境，并且可以改变自身结构以适应环境变化和影响环境的需求。
|
||||
|
||||
在软件系统的机理方面，软件的语义将由传统的还原论形式语义方法，向多尺度、可演化的抽象方向发展，组合方式将从传统的静态组合方式向动态可演化的、具有涌现特性的方式发展，建立软件微观行为与宏观行为的辩证统一。面向人机物融合的认知，软件作为人工智能或者“智能+”的承载，将深化复杂自主系统的智能行为理论和方法，软件定义将成为人机物融合系统中学习赋能（型）资源的管理途径。
|
||||
|
||||
软件科学的发展也将促进系统论和系统学的发展。在软件定义一切的时代，软件成为复杂适应系统认知的载体和实验平台，而软件发展中形成的以形式化体系为基础的规则驱动软件理论，高性能计算之上建立的模拟仿真技术，与进入智能化阶段形成的大数据驱动的软件方法，为形成还原论和整体论的辩证统一奠定了良好的基础，软件走向人机物融合更是为系统论和系统学的发展提供了实践探索的大场景。
|
||||
\subsubsection{系统观下软件方法学的关键科学问题}
|
||||
软件学科的系统观形成、并与系统学的交叉融合将经历一个长期的阶段。当前软件学科所面临的一个关键科学问题是对于人机物融合系统的建模与分析，表现为两个方面：一是系统论驱动的复杂软件系统的观察和度量方法；二是兼容离散、连续、实时等不同特性的模型表示方法及其工具支持。在操作层面，系统观下软件方法学的研究有紧密联系的两个抓手：
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{4.4em}
|
||||
（1） 以复杂自适应软件系统为抓手，形成元级反射和学习赋能相结合的元级化理论，建立泛在操作系统的技术和平台；
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{4.4em}
|
||||
（2） 推进数据驱动软件开发方法的发展，打通经典软件方法与数据驱动软件方法的界限，突破大数据分析的可解释性和常识推理问题，为涌现现象规律的认识、解释、设计建立基础理论和方法。
|
||||
|
||||
展望未来，多自主体形成的协同与自组织以及自适应结构和能力、网络化产生的大数据与数据语义的复杂网络，将是软件系统在传统规则驱动基础上走向人机物融合超大规模系统的基础。软件作为复杂系统乃至复杂巨系统，在软件定义时代，软件科学将与系统学共同发展，软件方法学将吸收系统论成果，并支撑系统论和系统学的发展。
|
||||
\subsection{形态观}
|
||||
随着计算机技术的发展和计算机应用的不断深入，软件的外在形态逐步从硬件附属物、独立的软件制品发展到网络化服务。与之相对应，软件开发范型也经历了无结构、结构化、面向对象、面向构件、面向服务的发展历程。当前，软件的外在形态正在朝着泛在化和可持续成长的方向发展：在空间维度上，软件应用的范围越来越广，对于人类生活和现实世界的渗透力越来越强，呈现出泛在化的趋势；时间维度上，软件应用随着上下文环境及用户需求的变化不断适应和演化，呈现出持续成长的趋势。与此同时，软件开发范型也进一步向网构化以及数据驱动方向发展。
|
||||
\subsubsection{软件应用的泛在化}
|
||||
计算和信息处理早已通过各种移动设备、嵌入式设备以及各种传感器渗透到了我们日常生活的方方面面，并通过各种通信技术实现了广泛的设备互连和信息互通。各种软件应用以嵌入式的方式实现预定义的信息处理和通信功能。近些年来，信息技术呈现软件定义一切的发展趋势，即软件全面接管人类社会以及物理社会中的各种资源（包括物理、计算和人力资源），以各种形式的接口对外提供服务。这一发展建立在软件的云化与服务化基础上，这使得软件的核心能力脱离了固化的用户界面和使用环境，可以按需灵活获取并组合。另一方面，硬件专用化使得运行在各种面向特定用途的硬件设备上的软件应用能够获得更好的执行效率。
|
||||
|
||||
面向最终用户的软件应用将越来越多地以人机物融合应用的形态出现，即软件以平台化、定制化和集成化的方式融合人、机、物三个方面的资源和服务从而满足用户的各种需求。这种新型的人机物融合应用具有泛在化、社会化、情境化、智能化的特点，即：软件应用无处不在同时又无迹可寻；所融合的人机物资源具备社会属性，来自于不同所有者并以社会化的方式产生价值交换；软件应用面向最终用户所处的情境按需构造，以满足即时的用户需求为目标；软件应用在智能化技术基础上，以非预设的方式按需聚合人机物资源并进行定制。
|
||||
\subsubsection{软件应用的持续成长}
|
||||
越来越多的软件都已具备面向动态变化环境的适应性和面向需求变化的演化性。软件通过监控、分析、决策、执行的反馈环路对其结构和行为进行调控，并通过不断演化来保持其有用性。快速响应变更请求并实现持续的软件演化是软件产品保持竞争优势的一个必要条件。在过去的几十年中，软件开发的主流方法已经从以瀑布模型为代表的计划驱动的方法演变为以敏捷开发为代表的快速迭代开发方法。基于云的软件应用以及软件开发平台的发展进一步催生了开发运维一体化（DevOps）的技术趋势。由此反映出软件演化中的反馈和迭代周期越来越短，演化越来越频繁。另一方面，越来越多的软件应用以服务化和云化的方式运行，在提供服务的同时持续收集用户的行为及其反馈，并在云端汇聚形成软件用户大数据。这种不断积累的用户数据为软件应用的持续优化和改进提供了新的途径。数据驱动的软件演化方式反映了用户行为已经在一定程度上取代专家成为掌握软件演化方向的主导力量。软件将逐步从被动演化转变为基于内生机制的持续生长。
|
||||
\subsubsection{新形态下的软件学科内涵}
|
||||
在软件定义一切以及人机物融合的发展背景下产生的软件应用的泛在化和持续成长的新特征对于软件学科的内涵发展将产生多个方面的影响。
|
||||
|
||||
首先，“软件定义+计算思维”将成为每个人解决现实问题、满足自身需求的新范式。未来的人类社会及日常生活的方方面面都将以软件定义的人机物融合应用的方式来实现。实现用户需求的应用软件将越来越多地以最终用户编程的方式面向应用场景按需构造。因此，最终用户必须具备基于计算思维的问题解决方案规划和构造能力。同时，这也要求我们为支持人机物融合的泛在服务软件提供通用的编程抽象（包括编程模型和语言），支持这种最终用户编程。
|
||||
|
||||
其次，适应泛在化、专用化的计算设备和运行平台成为软件的普遍要求。大量的应用软件将从通用的硬件和平台迁移到专用的硬件和平台上，需要新的方法和工具支持来实现大范围的软件迁移和优化。针对通用目的开发的软件需要具备面向不同专用硬件和平台的高效定制和裁剪能力。
|
||||
|
||||
再次，内生的持续成长能力将成为软件的基本能力。除了自适应能力外，软件将越来越多地具备支持自演化的持续生长能力。这种持续生长意味着通过各种智能化算法调整软件的算法和策略从而实现优化运行，而且还意味着软件通过各种生成以及合成能力不断增强自身的能力。因此，未来软件定义中功能与数据的界限将进一步模糊，越来越多的功能将通过数据定义（代码也可以看作一种数据）的方式进行表示，并通过数据驱动的方式实现自演化和自生长。
|
||||
|
||||
最后，软件与人将在不断汇聚的群体智慧中实现融合发展。软件的覆盖面越来越广、渗透性越来越强，最终用户对于软件的依赖也越来越强。由此，软件所能获得的关于用户行为和反馈的数据越来越全面和丰富，并在此基础上形成越来越强的群体智慧。这种群体智慧注入软件后又将服务于每个最终用户，使得他们能够在各种应用场景中以更加智能化和个性化的方式满足自身的需求，从而使得软件在使用中越来越有“灵性”和“人性”。未来的软件学科及相关研究需要摈弃“人”与“软件”二元分离的思维定式，更加自觉的考虑人机共融，不仅考虑“人因”，更要考虑“群智”。
|
||||
\subsection{价值观}
|
||||
传统的软件质量观以软件制品为中心，人们主要通过客观度量软件系统来评估软件。新时代下，软件制品的内外部质量要求进一步强化和扩展。更重要的变化，软件通过服务的方式满足用户需求，软件无迹可寻的趋势强化了软件作为人类价值载体的特征，需要在传统的质量观的基础上发展到以人为中心的价值观。
|
||||
\subsubsection{从质量走向价值}
|
||||
传统的软件质量模型定义了内部质量、外部质量和使用质量，其主要关注包含内部质量和外部质量的系统质量。新时代下，软件生态和形态特征变化使得对于软件质量需要有新的认识。一方面变化是软件的服务化特征，即：软件系统通过服务满足用户需求，用户不再拥有软件制品，只享受软件提供的服务。另一方面，技术对社会的影响，使得软件体现了人类价值观。人类价值观，指的是“基于人的一定的思维感官之上而作出的认知、理解、判断或抉择，体现了人、事、物一定的价值或作用”，价值观具有稳定性、持久性、历史性和选择性等特点；软件通过一系列价值要素体现了主观的人类价值观，这些价值要素包括隐私性、安全性（safety \& security）、平等性等。传统的质量观转变为 “以软件制品为基础，以用户体验为中心”的价值观。在价值观主导下，不同用户会有不同的软件预期，也会使得同一软件系统具有不同的价值。
|
||||
\subsubsection{新时代软件系统的价值要素}
|
||||
软件会有多个不同的角度来评价其价值。未来人机物融合的软件基础设施将在可信性、安全性和持续性等价值要素上推动软件学科的发展。
|
||||
|
||||
（1）可信性
|
||||
|
||||
人机物融合导致整个社会系统遍布软件，“软件无处不在”，软件系统的可信性对于整个社会系统至关重要。软件系统的可信性，要求在软件开发、运行、维护、使用等过程采取有效的措施和方法确认其满足人们的普遍要求和期望，它体现了新时代软件的价值取向。软件系统的可信性，包括软件本身可信和行为可信两个方面。软件本身可信，指的是软件身份可信和能力可信，即：软件开发过程提供可信证据（如内部质量和外部质量）进行自证；软件行为可信，指的是软件行为可追踪记录、不可更改，即：软件运行过程提供监控以控制其对周遭的影响，使得包含该软件在内的整个系统的对外表现符合用户要求。软件形态日趋多样，加剧了软件可信面临的挑战。
|
||||
|
||||
（2）安全性
|
||||
|
||||
安全性要求为人类活动和生存环境提供必要的安全保障，包括系统安全（Safety）和信息安全（Security）。系统安全是指能及时有效地避免给人员、设施、环境、经济等造成严重损害，信息安全是指能有效防控各类的非法获取、传播和使用。软件信息安全保障失效的后果之一就是系统安全故障，因此，本书将两种安全性合二为一，统称为安全性（Safety\&Security）。传统软件质量观将安全视作系统质量的一部分，强调软件个体的安全性。随着人机物融合，软件系统已融入人类社会，并与人类无缝交互。换言之，泛在计算平台上软件与软件、软件与人的交互无处不在，软件个体可影响整个泛在网络计算平台的行为；软件个体的漏洞等故障很容易扩散（传播）。软件作为基础设施，参与并掌控了很多关键领域的资源，其安全性威胁会给整个系统带来致命的威胁。因此，安全性这一质量属性随着软件成为基础设施的现状变得愈发重要。
|
||||
|
||||
（3） 伦理观
|
||||
|
||||
作为人类价值载体，软件行为体现了人类价值观；由于软件无迹可寻，导致人类价值观又通过软件影响人类社会。因此，软件系统的行为应符合社会道德标准，不会对个人和社会产生负面结果，这种规范称为软件系统的伦理观。社会道德定义了一定时间区域内人们行为规范，可具体表现为无歧视、尊重隐私、公平公正等，并最终体现于软件系统的具体行为。因此，软件系统的伦理观，也体现于软件行为的上述方面，并需要通过软件开发和运行的诸多机制进行支持。
|
||||
|
||||
（4）持续性
|
||||
|
||||
软件系统成为支撑社会经济运行的基础设施，掌控了国民经济和社会关键基础资源，需具有持续提供服务的能力。软件系统提供服务的可持续性（sustainability），指的是在持续不间断运行、维护和发展过程中，面对各种突发异常事件，仍能提供令人满意的服务的能力。软件支撑的基础设施服务，为满足各类应用快速增长、新技术不断涌现的需求，需要具有开放扩展能力，即能集成各种异构的技术及系统，支持各类软件制品的即时加载/卸载，对内部状态及外部环境变化的感应、自主响应以及调控机制，以及个性化服务的定制等。显然，这种开放体系架构常常引入系统设计的脆弱性和质量隐患，从而给持续提供服务带来挑战。
|
||||
\subsubsection{价值观下，软件方法学的关键科学问题}
|
||||
软件价值观强化了可信性、安全性、持续性等具有新时代特色的价值要素，这些价值要素与软件开发运行维护过程的交融将经历一个长期的阶段，其带来的关键科学问题在于四个方面：
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{3.4em}
|
||||
1) 软件以何种方式承载人类价值观？具体地，如何通过需求等阶段获得项目特定的价值观，将其细化并融合于软件开发过程（包括软件的分析、设计和实现等环节）中？
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{3.4em}
|
||||
2) 如何定义复杂开放软件的可信性度量模型，并以此为基础通过开发运行环境证据的收集评估软件可信性？在开放环境下，可信性的定义也是动态多变的，如何在系统实现和运行中支持动态的可信性？
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{3.4em}
|
||||
3) 如何在泛在网络计算平台下，系统化地从硬件平台、操作系统、应用软件等多层考虑软件安全性（Safety\&Security）？
|
||||
|
||||
\hangafter=1
|
||||
\setlength{\hangindent}{3.4em}
|
||||
4) 如何在软件开发和运行过程中引入灵活性的机制，使得作为基础设施的软件系统提供的服务具有持续性？此外，这种灵活性机制，有可能会给软件质量等带来的影响，这也是支持持续性的软件系统需要在设计实现中需要解决的问题。
|
||||
\subsection{生态观}
|
||||
软件的开发、维护和应用所涉及的各种元素（包括开发者、用户、代码、项目、社区、企业及其环境等）彼此交互互相依赖，逐渐形成复杂生态系统，需要用生态化的观点去理解和研究。生态化是软件的强大渗透力的必然结果：一方面软件活动延伸到了个体、群体和社会；另一方面软件所涉及的各种元素之间存在越来越多的依赖性、相关性和相互作用。
|
||||
\subsubsection{软件生态系统}
|
||||
“人－机－物”三元融合的新型应用模式涉及到广大社会群体，涉及面广，分工精细，不仅需要术业专攻的各种企业和个体参与，也使得它们可以根据其本身特点和业务诉求参与到开发、应用及其支撑的各个环节，从而形成联合生态。
|
||||
|
||||
开源是一类典型生态系统。开源以燎原之势渗透到了软件产业各个领域,目前80\%的软件开发都是开源模式，几乎100\%的IT企业都借鉴开源代码，故而代码片段、软件包、软件以及技能、知识和上下游项目等的依赖无处不在，生态以一种自然的方式呈现于软件、开发者、开发社区和企业中。一些大规模复杂软件（尤其是基础软件）例如Linux内核，OpenStack等，因其基础性和流行度涉及到众多厂商的利益，因此也会吸引庞大的群体（企业和个体）在其开发和应用市场中扮演不同的角色，形成生态。
|
||||
|
||||
总的来说，软件生态系统指参加软件活动（开发、运行、维护、应用等）的一组实体及其环境组成的、彼此交互的社区体系（系统之系统）。生态系统可以从下述几个维度来刻画。
|
||||
|
||||
首先，多元素交互（开发者、用户、代码、项目、社区、企业等）是软件生态系统的最典型特征，而且交互的元素具有深刻的社会性（因为核心参与者——开发者和用户——都是社会体）。元素关系主要体现为协作、竞争和混合并保持生态的平衡。系统中要素关系（对立、独立或互补）之间的平衡是秩序之本，非平衡是运动变化之源。
|
||||
|
||||
其次，生态系统的关键元素是个体、代码和项目/社区，三者互相融合、依赖和影响。个体之间、代码之间、项目之间存在各种依赖，形成各种供应链，而个体、代码和项目之间因为彼此依存也存在各种影响。生态的要义在于供应链的形成和各种影响的相互作用需要抵达平衡。
|
||||
|
||||
第三，生态系统是由群体智能和计算机智能交互并融合而实现的。群体智能体现为分布在全球的开发者和用户，计算机智能体现为支撑分布式开发和使用的工具和基础设施（计算机辅助支持和人机交互）。群体智能（体现了众多的个体认知的汇聚，并涵盖商业智能和宏观调控的战略智能等）通过计算机智能凝炼为代码和产品，计算机智能支持人们更好地协作、开发和无处不在的使用，并且在开发和使用活动中不断迭代增强。
|
||||
\subsubsection{生态观下的软件学科的关键科学问题}
|
||||
软件从过去的个体作坊开发，到不同组织内或组织间参与下的组织式开发，发展到了数以万计互相依赖的软件或项目形成的供应链和庞大的生态系统。其转变给软件开发带来了前所未有的创新水平。同时，规模指数级增长的软件或项目及其之间庞杂的依赖关系使得软件供应链的复杂度激增，进而给软件开发和应用及市场带来诸多挑战。
|
||||
|
||||
第一，个体开发者学习成本进一步增大。首先因为软件之间广泛存在的依赖关系使得掌握一个新的软件需要学习别的软件。例如，对某个软件进行调试需要学习的相关软件依赖包可能会很多。其次，复杂依赖关系带来了新的问题，涉及更多的学习内容。例如，不同开源项目遵循相应许可证（License）的约束，并且不同许可证之间存在兼容问题，这就要求开发者在借鉴开源代码时需要了解对应的许可证。这其中的关键科学问题是：个体开发者如何学习并加入复杂项目和生态？
|
||||
|
||||
第二，群体协作更加复杂。首先群体元素更为多样，其次不同元素围绕生态中的各种软件活动存在错综复杂的协作关系，最后协作行为并非恒定而是不断发展和演化的。例如供应链上的软件项目互相依赖，开发者需要跨越多个项目去实现目标功能，开发者之间的协作不再拘泥于单个项目。例如具有不同商业目标的公司需要各司其职，互补有无，还需要跟竞争对手建立协作，在商业利益和群体目标之间实现平衡。已有的群体协作机制大多聚焦对单个项目的支持，互相依赖的项目之间因缺少有效的信息沟通与集成机制使得群体协调的复杂度增大。总之，这其中的关键科学问题是：复杂生态中群体如何协作，协作行为如何发展？
|
||||
|
||||
第三，生态可持续性受到的威胁持续增加。软件供应链上的节点是组成生态的关键元素，它们互相依赖互相影响。一个软件的漏洞有可能使得其他依赖该软件的项目面临同样的危机。例如，影响昭著的Heartbleed漏洞所涉及的OpenSSL项目中的两个文件至少存在于其他六千多个开源项目中。各大企业因为软件供应链的存在对软件溯源（即追踪代码问题的来源）有很大的需求，投资也是可观的。然而软件供应链上节点间的依赖关系隐藏在开发活动数据中，看不见摸不着但广泛存在，这就使得软件生态的可持续受到更多潜在威胁。而生态的形成和可持续发展影响到软件甚至信息产业的革新和发展。这方面的关键科学问题是：大规模代码和项目的供应链行为如何理解？产业生态如何形成，如何实现可持续发展？
|
||||
|
||||
总之，尽管有数千万个软件和项目及超过一千亿的源代码文件，但人们对软件生态中供应链的形成和发展，及其可能带来的风险和挑战却知之甚少。随着软件生态系统的快速延展，各类供应链关系逐步显现，如开发供应、技术供应、以及产销供应等。供应链中数以千万计的个体开发者、软件项目、公司等围绕软件形成复杂生态的各种活动数据都被软件支持工具记录下来，可以方便的获取，这为公众或者企业自己更好地理解生态的形成和发展，以降低或消除上述生态中的依赖风险、识别其他可能存在的风险提供了一种很好的方法。利用社会学理论对海量数据可视化出来的软件供应链网络进行分析，可以允许我们从个体学习、群体协作、以及生态持续的角度去识别评估风险，进而地更好保障软件生态的可持续发展。
|
||||
|
||||
综上，生态观对软件方法学带来显著的变化和跨越，软件学科跟其他学科的交叉性将更为凸显。软件和软件学科需要从以往关注个体软件的构建和运维转变到关注有广泛社会参与的软件体系的构建、运维和成长，以及软件生态的平衡和可持续发展。
|
||||
|
||||
\section{软件学科的发展趋势}
|
||||
预告本篇其余各章的主要内容】
|
||||
|
|
@ -0,0 +1,224 @@
|
|||
|
||||
学科教育基于学科的独立知识体系，宣传和普及学科知识，培养学科专业人才。学科教育是构成学科的要素之一，并受学科的发展、教育理念和方法的进步等因素的影响。软件学科虽然是一门新兴学科，但是随着软件学科的边界不断拓展，内涵持续变化，地位不断提升，以及对人类社会的影响面日益扩大，软件学科教育的重要性日益凸显。如何加强软件学科教育，让更多的社会大众从中受惠和受益，成为全社会关心的话题。
|
||||
|
||||
软件学科的研究主体是人类及其思维活动，客体是软件及其内在规律。在人-机-物高度融合的时代，“软件定义一切”、“软件无所不在”使得软件成为人类社会的基础设施，软件的环境、边界、构成、形态、交互等发生了深刻的变化，这些变化不仅推动了软件学科的发展和进步，而且使得软件学科教育的对象、内容和关注点等也随之发生变化。
|
||||
|
||||
首先，随着软件日益普及，软件对人类生活和现实世界的渗透力越来越强、影响面越来越广，受其辐射和影响的人群越来越多，并随之产生了一系列新的问题和价值取向，如可信、隐私保护、安全等。越来越多的普通人融入软件定义的世界，甚至通过编程等方式参与软件的构造。总体而言，\textbf{软件学科与人类社会间的关系变得更为密切，软件学科教育日趋普及化和全民化}。
|
||||
|
||||
其次，随着计算平台不断向物理世界和人类社会快速延伸，软件作为“集成器”在连接物理系统和社会系统中发挥着日趋重要的作用，软件泛在化和人机物融合的趋势日益明显，软件成为诸多行业和领域（如机器人、航空、航天、生物医学等）解决其特定问题的核心手段和必不可少的工具。\textbf{这些行业、领域的专业人士需要接受软件学科教育，掌握软件学科的基础知识和核心能力，软件学科教育不断向其它的专业领域延伸}。
|
||||
|
||||
再次，软件系统变得日益复杂，并体现多元价值，需要借鉴系统论方法（而非还原论方法）来驾驭软件的复杂性，并从生态系统的角度认识软件系统及其开发和演化。随着软件学科外延的拓展和内涵的发展，软件学科不断地与其他的相关学科进行交叉，其知识体系也在不断的丰富和完善，对软件专业人才的知识、能力、素质和技能等要求也随着发生变化，\textbf{软件学科教育需要与时俱进，从系统观和系统能力、软件生态观、多元价值观等方面加强专业人才的培养}。
|
||||
|
||||
最后，软件学科教育需要充分发挥软件作为一项可辅助解决特定领域问题（如教育问题）的计算工具的优势，培养社会大众基于软件来解决问题的创新意识，借助软件学科的已有资源，借鉴先进的教育理念和方法，\textbf{推动软件学科人才培养理念和教育方法的改革}。
|
||||
|
||||
概括起来，软件学科作为基础学科，其教育涉及多个方面，需要推动普及教育，加强非专业教育，深化专业教育，重视人才培养理念和教育方法的改革；软件学科教育需要解决上述方面的诸多重大挑战问题，并开展针对性的研究工作。
|
||||
|
||||
\section{重大挑战问题}
|
||||
为了适应人机物融合时代软件学科的发展以及人才培养的需求，软件学科教育需要在普及教育(§10.1.1)、专业教育(§10.1.2)、其他学科专业教育(§10.1.3)、教育理念与方法(§10.1.4)等方面解决以下一系列重大挑战问题。
|
||||
|
||||
\subsection{面向不同受众对象和认知水平的普及教育}
|
||||
软件定义一切，软件无处不在，软件的地位越来越重要。在人机物融合时代，软件不仅是人类社会的基础设施，而且正成为承载人类文明的新载体。如何做好现代软件文明的继承者、传播者和创作者，软件学科教育必须顺应这一时代要求，从单一性的专业教育向大众化的通识教育转变，即惠及普通大众，从儿童、少年、青年、中年到老年，人人能用软件，人人能评软件，人人能读软件，人人能写软件。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{如何培养以计算思维为核心，融合创新思维的系统性认知能力}
|
||||
\end{itemize}
|
||||
|
||||
软件是人类智力活动的创作结果。软件学科普及教育首先需要解决社会大众（尤其是青少年）针对软件及其开发的系统化认知问题。从系统观的视角上看，软件学科的核心认知能力是计算思维，它是信息社会中现代人的基本素养，也是人类诸多认知能力的核心要素之一。从内涵上看，计算思维能力绝不仅仅是编程技能，也不纯粹是掌握某些程序设计语言，而且还包括应用软件定义的人机物资源来创新解决问题以及由此所需的创新思维能力。现阶段软件已渗透到自然科学、工程技术、社会人文等方方面面，计算思维与其他认知能力（如批判思维、创新思维等）相互作用，相互影响，不可分离。软件学科教育要突出软件作为“集成器”在连接物理系统和社会系统中的关键作用，强化通过软件来解决各种实际问题的思维训练。为此，软件学科的普及教育需要充分揭示计算思维能力与其他认知能力之间的关系，深化以计算思维、创新思维为核心的普及教育，推动系统化认知能力的提高。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{不同教育受众认知能力的成长有何规律，如何构建适应不同受众的普及教育知识体系}
|
||||
\end{itemize}
|
||||
|
||||
软件学科普及教育受众对象的涉及面广、差异性大，其中青少年教育是核心和关键。他们是一类认知能力正逐步成长的特殊人群，其基本认知能力，如抽象思维能力、表达交流能力、逻辑分析与推理能力、计算抽象能力等正处于逐步形成的阶段。针对不同的受众对象，他们在计算思维等认知能力的成长方面有何规律性？不同认知能力的形成存在怎样的依赖性？计算思维的训练与哪些认知能力密切相关？等等基础性的问题值得去探究。与此同时，计算思维等认知能力的培养需要依托软件学科和非软件学科的诸多相关知识，这些知识需要与实际问题域相结合，以加强计算思维能力的训练和实践。因此，如何以软件学科知识为核心，建立起科学的、层次性的、可满足不同受众和认知能力培养需求的知识体系，是软件学科普及教育亟需解决的关键问题。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{如何构建与认知能力和水平相适应且贯穿终身的软件学科普及教育理念与方法}
|
||||
\end{itemize}
|
||||
|
||||
软件学科普及教育对象处在各行各业，知识背景不一样，认知能力千差万别，且需面对从儿童期、少年期、青年期、中年甚至到老年等一生各种不同时期，认知水平各不相同，因此普及教育模式不能单一化，教育方法不能统一化。对于儿童和少年，游戏编程、可视化和实物编程有利于推动以计算思维为核心的认知能力逐步形成和深化；对于青少年，创新思维与软件核心认知能力的紧密融合更有效推动其认知能力发展；对于成年人，通过软件创意创作把个人智慧进行沉淀和累积更能发挥其特长。对于老年人，编程将会成为他们除了琴棋书画广场舞之外的另一个重要兴趣方向。与此同时，随着信息技术的发展，教育的方式和方法也在不断的改变。为此，软件学科普及教育需要寻求适应不同普及对象、不同行业领域、不同认知水平的教育理念和方法。
|
||||
|
||||
\subsection{反映人机物融合时代特点的专业教育}
|
||||
在人机物融合时代，软件的环境、边界、构成、形态、交互、复杂性等发生了深刻的变化，软件学科的内涵和外延也在不断的发展，其知识体系不断的丰富，对软件学科专业人才的能力、素质和技能等要求也随之发生变化，进而对软件学科专业教育提出了新的挑战。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{如何认识人机物融合时代对软件学科专业能力提出的新要求？}
|
||||
\end{itemize}
|
||||
|
||||
在人机物融合时代，软件学科教育需要从提升可持续核心竞争力的角度着重加强专业人才的能力和素质培养。从系统观的视角，人机物融合时代的软件系统已不再是纯粹的技术系统，而是需要与物理世界、社会系统等进行高度融合。这类系统的开发需要采用系统论方法（而非还原论方法）来驾驭复杂性，要从“人机物”相互融合的角度和层次来认识软件系统，要将软件视为融合人机物的“万能集成器”。此外需要从横向（系统的层次）和纵向（系统的联盟）、高层、宏观、全局、多视角地分析系统的构成和考虑系统的设计，需要站在系统的高度来综合考虑人、机、物之间的关系，通过人、机、物三者间的协同来给出软件系统的解决方案，也即软件学科专业人才需要具备“系统能力”。人机物融合时代的软件系统也呈现出新的特点，软件规模的超大（如几亿甚至十几亿行代码）、软件需求不清晰且持续变化，软件系统表现为一类系统子系统而非单一系统、动态演化系统而非静态确定系统、社会技术系统而非纯粹技术系统等等。因此，软件形态和复杂性的变化以及软件学科范畴的拓展对软件学科专业人才的能力和素质提出了更高的要求，软件学科专业人才需要具备解决人机物融合新时代背景下的复杂工程问题的能力，这种能力需要建立多学科知识的基础之上，以应对人、机、物融合带来的各种问题。同时，需要加强以软件作为解决方案、融合人机物来解决问题的创新能力等等。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{如何构建与人机物融合时代软件学科特点相适应的专业知识体系？}
|
||||
\end{itemize}
|
||||
|
||||
在人机物融合时代，不仅软件系统的构成、形态和复杂性在变，人们对软件系统的价值观认识也在变（如更加关注软件的可信性、隐私性、安全性、平等性、持续性等价值取向），支撑软件系统开发和运维的方法和技术也在不断的变化。软件开发和运维不仅是个体和团队行为，而且延伸到社会层次，表现为一种社会化行为。开源软件的成功实践表明，大规模群体化软件创作成为一种重要的软件开发方式，软件生态变得极为重要。此外，软件学科不断地与其他相关的学科进行交叉，如大数据、人工智能、社会学、系统科学等等。这些意味着人机物融合时代的软件学科专业教育知识体系发生了深刻的变化，其知识域在不断拓展，知识点在不断增加。为了满足人机物融合时代对软件学科专业能力提出的新要求，需要建立支撑系统能力、解决复杂工程问题能力以及创新能力等能力培养所需的知识体系。因此，软件学科专业教育需要建立起与人机物融合时代软件学科发展相适应、满足软件学科专业人才培养需要的知识体系。
|
||||
|
||||
\subsection{融合软件学科知识的其他学科专业教育}
|
||||
从形态观的视角，软件对人类生活和现实世界的渗透力越来越强，呈现出泛在化的趋势，与众多的专业和学科联系紧密；从系统观的视角，软件作为“集成器”在连接物理系统和社会系统中发挥关键作用，与诸多的应用领域密切相关。无疑，非软件学科的专业人才越来越多的需要具备软件学科的相关知识和能力，以帮助他们解决特定专业和学科领域的相关问题。如何在非软件学科教育中融合软件学科教育的内容成为一项重大的挑战。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{如何在其他学科专业教育中融入软件学科的知识体系}
|
||||
\end{itemize}
|
||||
|
||||
现有的许多学科与软件学科紧密相关，但在学科教育层面，它们很少交叉和融合软件学科的知识体系。随着软件学科的日趋泛在化以及对各个领域、行业和专业的不断渗透，以及社会对复合型、创新型人才的迫切需求，如何把软件学科的相关知识体系融入到非软件学科（如航空、航天、机器人、新材料等）的知识体系中，构建跨专业、多学科交叉的新型融合性知识体系，将成为未来非软件学科教育改革面临的一项重大挑战。非软件学科教育需要借鉴和引入“软件定义+计算思维”的理念，使得相关专业人才具备利用软件学科的思维方法解决专业特定问题的能力，这种新的融合性教学模式能够充分发挥软件学科的优势和专业特长，有利于激励学生探索交叉学科的新领域，促进学生能力和素质的全面发展。实现“非软件学科 + 软件学科”相融合的教育改革，既是当前诸多专业教育面临的机遇，也是它们必须应对的挑战。针对相关学科专业（如农业、气象、生物医学、现代服务业等）的人才培养，在保障以本学科专业为主导的前提下，如何加强软件学科相关知识的学习和能力的培养，如何调整培养方案和知识体系，完成从“专业型”到“融合型”学科培养方式的转型，是当前非软件学科教育亟待解决的问题。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{如何培养具有软件学科知识和能力的复合型、创新型跨界专业人才}
|
||||
\end{itemize}
|
||||
|
||||
随着行业软件化转型需求的不断增长，诸多学科和专业与软件学科的融合日趋紧密，迫切需要具有软件学科知识的复合型、创新型跨界专业人才。然而，现有的许多专业人才培养尚无法满足这一需求，极大制约了相关行业的转型、专业和学科的发展，导致这种状况的原因是多方面的：一些非软件学科的专业人才培养直接将软件学科中的某些先进软件技术套用到相关专业领域之中，并没有系统地考虑这些技术在跨界专业领域中的实用性以及其软件应用需求的特殊性；它们更多地关注于自身专业领域的相关知识和能力，忽视和错失了软件学科的知识和技术给专业领域问题的解决带来的新机遇。因此，如何培养具有软件学科知识和能力的复合型、创新型跨界专业人才，将是诸多专业和学科教育面临的重大机遇和挑战。在现有的人才培养体系下，我们应该深入思考如何在掌握专业基础知识的同时，将软件学科的知识与相关专业学科的知识相交叉和融合，实现从单一专业人才到跨界复合型、创新型人才的转变，满足人机物融合时代对复合型、创新型人才的巨大需求。
|
||||
|
||||
\subsection{适应软件学科发展的人才培养理念及教育方法}
|
||||
在人机物高度融合的时代，软件学科教育既要根据软件学科的特点、顺应学科的发展趋势，也要充分利用好学科发展的成果，促进学科人才的培养。软件学科教育在教育理念、方法和模式等方面面临一系列的挑战。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{如何借助软件学科的成果来加强软件学科人才的教育？}
|
||||
\end{itemize}
|
||||
|
||||
在几十年的发展过程中，软件学科领域积累了大量多样的资源，包括代码、模型、文档、数据、开发知识等等。尤其是近年来，随着以开源软件为代表的群智软件工程的快速发展，在互联网的开源软件社区汇聚了各种软件资源和开发数据。这既给软件学科教育创造了条件、提供了“物质”基础，同时给软件学科教育提出了新的问题和挑战：如何借助这些软件资源来探究软件学科人才的成长轨迹和培养路径？如何利用这些软件资源来来支持软件学科教育、促进软件人才培养？
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{如何顺应当前教育理念和手段的发展，改革软件学科人才的教育方式和方法？}
|
||||
\end{itemize}
|
||||
|
||||
以互联网为基础的信息技术正改变甚至颠覆传统的教学理念和方法，以MOOC、SPOC等为代表的大规模在线教育意味着互联网大众不仅是教育的受益者，也是教育的参与者。随着软件的普及化以及软件学科逐步成为一门基础性学科，软件学科教育朝着普及化和全民化的方向发展，越来越多的大众涉足软件的使用、评价甚至开发，因而成为软件学科教育的对象。这就需要为软件学科的大众化和普及化教育投入足够的教育资源、提供有效的方式和手段。以群体化软件开发方法为代表的软件开发隐喻给软件学科教育提供了新的启示，借助于互联网大众、利用群智的力量来推进软件学科教育将是未来的一个重要趋势，它不仅有促进软件学科教育的普及化，而且还可通过大众的协同，共同分享学习的经验和资源。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{如何为软件学科教育提供软件支撑？}
|
||||
\end{itemize}
|
||||
|
||||
软件为特定领域的问题提供基于计算平台的解决方案。软件学科教育是一个特殊的应用领域，它涉及诸多问题的解决，如教育资源的组织和分享、学习者的交互和协同、教育成效的考核和评估等等。因此，如何为软件学科教育提供软件支撑成为一个开放性的问题。
|
||||
|
||||
\section{主要研究内容}
|
||||
针对上述重大挑战问题，软件学科教育需要开展以下几个方面的研究工作，包括：以“计算思维 + 创新思维”为核心的普及教育（§10.2.1）；以“多学科交叉融合知识体系＋系统能力和解决复杂工程问题能力培养”为核心的专业教育（§10.2.2）；以“专业学科知识 + 软件学科知识”为基础，实现复合型、创新型和跨界人才培养的其他学科专业教育（§10.2.3）；以及以“探究成才规律 + 寻求理念创新 + 开发支撑软件”为核心的教育方法改革（§10.2.4）。
|
||||
|
||||
\subsection{以“计算思维 + 创新思维”为核心的普及教育}
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{软件学科核心认知能力的成长模型和规律及其知识体系}
|
||||
\end{itemize}
|
||||
|
||||
软件学科的认知能力以计算思维为核心，包含抽象思维、表达交流、逻辑分析和推理、计算抽象等，这些能力有其各自的特殊性，相互间存在依赖性。为此，需要深入研究以计算思维能力为核心的认知能力成长模型，探究不同受众认知能力的成长规律。与此同时，这些能力培养所需的知识潜藏在数学、语文、物理、化学、自然科学等课程的知识体系之中。软件学科认知能力的培养和上述知识之间存在横切特征，且不以软件的形态直接表征出来，而且代表这些知识体系的课程很少与实际的软件及其开发相关联。因此，需要从横切和纵切二个方面，探究并建立起支撑软件学科核心认知能力成长的知识体系。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{以计算思维为核心，融合创新思维的系统化认知能力培养方法}
|
||||
\end{itemize}
|
||||
|
||||
人机物融合时代，软件使能的创新是软件学科辐射影响的主要目标，软件学科教育要在培养计算思维能力的同时，强化基于软件来解决问题的创新思维能力的培养。现阶段，软件学科的普及教育还是以编程技能培养为主，我们对计算思维与创新思维二者相互作用的认识还不够，无法满足软件学科普及性教育的需要。因此，我们需要研究如何将“计算思维”与“创新思维”二者相结合来深化软件学科的普及教育，探究“计算思维+创新思维”融合培养的学习路径，建立起支撑“计算思维 + 创新思维”培养的方法和手段。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{适应不同认知水平且贯穿终生的软件学科普及教育方法}
|
||||
\end{itemize}
|
||||
|
||||
软件学科普及教育受众的专业和知识背景具有多样化的特点，年龄层次和认知水平有较大的差异性。为此，需要借鉴生态化发展的思路，研究与教育对象的生理、心理和认知相适应的教育方法；研究同质生态教育方法和异质生态关联的迁移教育方法；研究如何借助于信息系统（尤其是软件系统）来支持和推广软件学科的普及教育。
|
||||
|
||||
\subsection{以“多学科交叉融合知识体系＋系统能力和解决复杂工程问题能力培养”为核心的专业教育}
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{面向多学科交叉融合的软件学科专业教育的知识体系}
|
||||
\end{itemize}
|
||||
|
||||
针对人机物融合时代的软件学科特点和人才培养要求，深入研究软件学科与哪些相关学科发生了交叉、交叉的边界和范围是什么；人们对软件的价值取向发生了什么样的变化，这些变化对学科的知识体系提出了什么样的要求；软件学科自身发展带来那些方面的变化，这些变化处于知识体系的那些层次和方面。另外，还需要从软件学科专业人才能力培养的视点，探讨系统能力、解决复杂工程问题能力的培养对知识体系提出什么要的要求。在此基础上，研究并建立起人机物融合时代面向多学科交叉融合的软件学科专业教育的知识体系，包括知识领域、知识单元、知识点等。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{软件学科专业教育核心能力的培养方法}
|
||||
\end{itemize}
|
||||
|
||||
系统能力、解决复杂工程问题能力等是人机物融合时代软件学科专业教育的核心能力和关键要素。这二类能力的关注点和侧重点有所不同，培养方式和手段也不仅相同。实践无疑是专业教育环节中支撑能力培养的主要手段。为此需要深入研究系统能力、解决复杂工程问题能力的内涵、构成和模型，分析不同能力之间的内在关联性，探究能力持续性培养和形成的特点和规律性，并针对人机物融合系统，探究如何通过设计渐进式、综合性的实践来促进系统能力和解决复杂工程问题能力的培养，并探究针对能力培养的考评方法。
|
||||
|
||||
\subsection{以“专业学科知识 + 软件学科知识”为基础，实现复合型、创新型和跨界人才培养的其他学科专业教育}
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{基于“专业学科知识 + 软件学科知识”的其他学科专业教育知识体系}
|
||||
\end{itemize}
|
||||
|
||||
作为基础学科，软件学科教育需要面向其他的专业实现外延式的发展。针对不同专业自身的特点，结合软件学科知识在该专业人才培养中所起到的作用，采取“专业学科知识 + 软件学科知识”的方式来拓展专业知识体系，开展专业教学改革，使得相关专业人才具备软件学科的知识并能运用它们来解决特定专业问题。为此需要研究如何将软件学科的知识融入到相关专业的知识体系之中，并实现与专业知识的有机融合，实现跨学科间知识体系的交叉融合和互补，为跨界人才培养奠定基础。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{具有软件学科知识和能力的复合型、创新型和跨界专业人才培养方法}
|
||||
\end{itemize}
|
||||
|
||||
随着软件学科在专业领域的不断渗透，在人才培养方案设计中，必须解决学生在学习过程中软件学科相关知识储备不足的问题。跨界软件学科人才培养需要多元化的课程体系。因为专业背景和专业思维的不同，非专业软件化教学过程中对软件学科的知识结构需求和相关课程衔接也是不同的。跨界软件学科人才培养方案需要探究如何实施“因材施教”的新型教学模式，分析不同专业对软件学科的“个性化”需求，构建专业软件化的新型课程体系结构，设计差异化的跨界软件学科人才培养方案。这种差异化的人才培养方案使得软件学科和本专业学科能够更好地交叉融合在一起，让非软件专业的学生也能形成通过软件科学思维来解决本学科专业问题的能力，有利于促进交叉学科领域研究成果的产生，满足社会对复合型、创新型的跨界软件学科人才的需求。
|
||||
|
||||
\subsection{以“探究成才规律 + 寻求理念创新 + 开发支撑软件”为核心的教育方法改革}
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{软件学科人才培养模型及规律}
|
||||
\end{itemize}
|
||||
|
||||
软件学科教育对象的涉及面广，年龄层次和知识背景差异性大，培养的目的和要求多样化。软件学科教育牵涉多方面的专业知识和非专业知识，需要强化不同层次的能力和素质培养。这些知识、能力和素质之间存在内在的关联性。为此，软件学科教育需要针对不同的培养对象和目的，深入探究人才培养模型，包括知识体系、能力体系、工程素质等，分析他们在培养过程中所发挥的作用以及相互之间的继承性和和依赖性。此外，软件学科人才的成长受多方面因素的影响，包括自身的素质和能力，外在的教育者及合作群体，学习的环境和激励机制，甚至学习过程中所依赖的软件平台（如开源社区）等。为此，需要研究探究软件学科人才的成长规模，依此来指导教育政策和机制的设计以及平台的建设。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{软件学科资源在人才培养中的应用}
|
||||
\end{itemize}
|
||||
|
||||
经过几十年的积累，尤其是近年来群智软件工程的发展，软件学科积累了大量、多样、极有价值的软件资源，如以开源社区为载体的各类开源代码、知识问答、软件开发历史数据等。软件学科专业教育需要深入挖掘和利用软件学科资源在学科专业教育中的价值，系统研究如何在课程教学、实践教学和人才培养过程中有效地应用这些软件学科资源，如何将抽象的理论知识与具体的软件学科资源相结合来促进知识的理解和掌握、推动实践教学、培养软件工程能力和素养。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{群体化学习}
|
||||
\end{itemize}
|
||||
|
||||
借助互联网平台，通过吸引、汇聚和管理大规模的学习者，使得他们以竞争和合作等多种自主协同方式来开展学习将是未来的一种重要学习方式，我们称之为群体化学习。软件学科教育需要充分借助于互联网大众的智慧和理念，施行群体化学习的思想和理念，以促进软件学科人才的大规模、高质量、普及化的培养。为此，基于群智智理论和方法的指导，借助于互联网上的大数据分析，需要研究支持群体化学习的组织结构和协同模型，分析和设计群体化学习的激励机制，探究不同组织结构、协同模型和激励机制对群体化学习成效、质量和受益面等产生的影响及涌现结果。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{大规模在线开放实践MOOP}
|
||||
\end{itemize}
|
||||
|
||||
能力和素质培养是软件学科教育的一项主要任务。针对软件学科的发展特点，需要研究软件学科人才的能力和素质模型，建立不同能力和素质之间的关系，分析普及教育、专业教育、非专业教育等分别需要达到什么样的水平和层次，探究软件学科内涵的拓展如何影响能力和素质。实践是支撑能力和素质培养的主要教学途径。依托大规模人群的在线开放实践（称为MOOP）将成为能力和素质培养的重要趋势，也是对MOOC在该方面存在欠缺的有效弥补。为此需要研究支撑能力和素质培养的实践体系建设，探究如何将诸如游戏化机制等引入到MOOP之中以支持大规模在线开放实践，分析针对MOOP的量化表示与评测方法，建立起针对能力和素质培养的评价体系与评价指标。
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\bullet$] \textbf{软件学科教育的支撑软件}
|
||||
\end{itemize}
|
||||
|
||||
需要针对软件学科教育的需求开发相应的支撑软件，研究软件学科教育软件如何同步分享和利用互联网上诸如开源社区中的学习资源（如开源软件和软件开发知识），构建软件学科教育软件与开源社区之间的互操作和交互机制，探究如何基于教育大数据的分析来构建学习者的个性化学习路径，并依次为基础为其提供最佳学习规划。
|
||||
|
||||
\section{本章小结}
|
||||
在人机物融合时代，随着软件辐射面和影响面的扩大，软件学科的不断发展和进步，软件学科教育的内涵和外延也在发生改变，它涉及普及教育、专业教育、其他学科专业教育、教育理念与方法改革等多个方面，面临着一系列重大问题的挑战，包括：如何针对具有不同认知水平的受众对象开展普及教育？如何针对人机物融合时代特点深化专业教育？如何在其他学科专业中融合软件学科的知识以加强非软件学科专业教育？以及如何开展软件学科人才培养理念和教育方法的改革等等。
|
||||
软件学科教育涉及诸多方面的研究内容，包括：以“计算思维 + 创新思维”为核心的普及教育；以“多学科交叉融合知识体系＋系统能力和解决复杂工程问题能力培养”为核心的专业教育；以“专业学科知识 + 软件学科知识”为基础、实现复合型、创新型和跨界人才培养的非软件学科专业教育；以“探究成才规律 + 寻求理念创新 + 开发支撑软件”为核心的教育方法改革等等。
|
||||
|
||||
\section{参考文献}
|
||||
[1] 梅宏. 万物皆可互联,一切均可编程[J]. 方圆, 2018, 501(12):58-59.
|
||||
|
||||
[2] 吴爱华, 侯永峰, 杨秋波, 等. 加快发展和建设新工科 主动适应和引领新经济[J]. 高等工程教育研究, 2017(1): 1-9.
|
||||
|
||||
[3] Bandyopadhyay S, Thakur S S. ICT in education: Open source software and its impact on teachers and students[J]. International Journal of Computer Applications, 2016, 151(6): 19-24.
|
||||
|
||||
[4] 计算机教育与可持续竞争力, “计算机教育20人论坛”编写组，高等教育出版社，2019.
|
||||
|
||||
[5] 李晓明, “老年编程”的畅想, 计算机学会通讯, 15(15), 2019.
|
||||
|
||||
[6] 梅宏, 周明辉. 开源对软件人才培养带来的挑战[J]. 计算机教育, 2017, (1): 2-5.
|
||||
|
||||
[7] 毛新军, 尹刚等, 新工科背景下的软件工程课程实践教学建设: 思考与探索, 计算机教育, 2018, 7: 5-8.
|
||||
|
||||
[8] Ian Sommerville, Dave Cliff, Radu, etc., Large-Scale Complex IT System, Communication of ACM, 2012, 55(7), 71-77.
|
||||
|
||||
[9] Linda Northrop, et.al., Ultra-Large-Scale Systems: The Software Challenge of the Future, Software Engineering Institute, Carnegie Mellon University, 2006.
|
||||
|
||||
[10] 中国ICT人才生态白皮书，华为、计世资讯编制，2018年7月
|
||||
|
||||
[11] Wing, Jeannette . Computational Thinking Benefits Society. 40th Anniversary Blog of Social Issues in Computing, 2014.
|
||||
|
||||
[12] EdSurge, "The 5th 'C' of 21st Century Skills? Try Computational Thinking (Not Coding) - EdSurge News", 2018.
|
||||
|
||||
[13] "Future-forward: How to incorporate the 5th 'C' of 21st Century learning". eSchool News. 2017.
|
||||
|
||||
[14] ACM中国教育委员会，教育部高等学校大学计算机课程教学委员会(译). 信息技术课程体系指南2017. 北京：高等教育出版社, 2019.
|
||||
|
||||
[15] ACM and AIS. Curriculum Guidelines for Undergraduate Degree Programs in Information Systems (IS 2010).
|
||||
|
||||
[16] ACM and IEEE Computer Society, Computer Science Curricula 2013 (CS 2013).
|
||||
|
||||
[17] ACM and IEEE Computer Society, Computer Engineering Curricula 2016 (CE 2016).
|
||||
|
||||
[18] IEEE Computer Society, SWEBOK V3.0 (Guide to the Software Engineering Body of Knowledge).
|
||||
|
||||
[19] ACM and IEEE Computer Society, Software Engineering 2014 (SE 2014)
|
||||
|
||||
[20] ACM and IEEE Computer Society, Graduate Software Engineering 2009(GSwE2009)
|
||||
|
||||
[21] 刘海涛. 高等学校跨学科专业设置:逻辑、困境与对策[J]. 江苏高教, 2018，(2):6-11.
|
||||
|
||||
[22] 焦磊.国外知名大学跨学科建制趋势探析[J].高等工程教育研究，2018，(3): 124-129.
|
||||
|
||||
[23] 李韬.“技术+管理”复合型人才培养目标下实践教学创新研究[J]. 企业科技与发展, 2019, 448(2):161-162.
|
||||
|
||||
[24] 王涛, 白羽, 余跃, 等. Trustie:面向软件工程群体化实践教学的支撑平台[J]. 计算机教育, 2018, (7):18-22.
|
||||
|
||||
[25] 高珍, 林冰轩, 袁时金, 等. 以学科交叉推动软件工程复合型硕士培养的探索及实践[J]. 计算机教育, 2018, (11):21-24.
|
||||
|
|
@ -0,0 +1,215 @@
|
|||
|
||||
任何一个学科的发展都需要基础理论作为支撑。涵盖计算理论与程序理论的软件理论为软件学科的发展奠定了理论基础。重要的理论结果和方法也有助于实际软件开发。信息技术的快速发展推动了整个社会的信息化程度不断提高。软件作为重要的基础设施之一，需要不断提高其品质。著名软件工程师Laurence Peter Deutsch [1]给学生的建议包括：“Good software requires the ability to think formally (mathematically),…Make sure you have some exposure to assertions, proofs, and analysis of algorithms, …”
|
||||
|
||||
|
||||
在满足实际需求的过程中，理论本身不断完善。随着软件应用需求和场景的持续发展和丰富、软件运行环境和硬件平台的不断变革、以及软件基础性地位的日益提升，软件理论有着更为广阔的应用前景和发展机遇，但同时也面临巨大的挑战。最近十余年，物联网、大数据、人工智能等信息领域技术浪潮不断兴起，对计算和程序理论提出了一系列新的需求和挑战。
|
||||
|
||||
|
||||
首先，新型的软件应用需求和场景为软件理论带来挑战。大数据应用需要新型算法和复杂性理论支持海量数据的高效处理；云计算的发展需要新型的分布式计算理论以及新型的编程模型；人工智能的发展使得具有不确定性的知识表示和推理成为一种常规的思维方式，从而为算法和复杂性理论、编程模型、以及软件的可靠性分析等带来众多问题；信息物理系统（CPS）和物联网应用则使得系统的建模、分析和验证成为难以回避的挑战。
|
||||
|
||||
|
||||
其次，软件运行环境和硬件平台的变革为软件理论带来机遇和挑战。一方面，处理器能力和网络带宽的大幅提升，使得以往受限于计算或通信能力的技术变得更具有实用性，包括特定的编程模型以及程序的自动化分析和验证技术，从而为软件理论的发展带来新的驱动力。另一方面，运行环境和硬件平台的变革也带来巨大挑战：人、机、物的融合使得软件运行在具有高度动态化和不确定性的环境中，为软件的规约、建模、分析和验证带来困难；多核处理器的普及促进了并发程序的使用，但对于高效并发算法的验证缺少理论和工具支持；其他挑战还包括搭载异构芯片的处理器、云平台上数据一致性的形式化规约和验证等。
|
||||
|
||||
|
||||
其三，软件基础性地位的提升为软件理论带来挑战。软件作为基础设施，日益深入到我们生产生活的方方面面，相应地，对软件可靠性的要求也变得越来越强。人们开始期望那些在以往仅仅针对特定算法和协议的验证技术能够应用于代码级的完整系统验证上，特别是底层系统软件的验证，如操作系统内核、编译器、密码算法和协议实现等。信息物理融合系统以及基于学习的人工智能技术在自动驾驶等安全攸关系统中的应用使得混成系统和概率系统的形式验证需求越发迫切。同时，软件复杂度的提高，对于可信软件的自动化开发和验证技术也提出了更高的要求。
|
||||
|
||||
|
||||
本章将针对软件理论的核心内容，包括算法及复杂性理论、程序正确性理论等，逐一探讨其面临的挑战，以及将来需要开展的研究。
|
||||
|
||||
|
||||
\section{重大挑战问题}
|
||||
在新的时代背景下，特别是在人机物融合的大环境下，软件理论遇到了新的挑战。具体包括：如何应对大规模的数据与计算(§1.1.1)；如何保证复杂软件系统的正确性、可靠性、安全性(§1.1.2)；针对新型计算机的硬件架构与新的计算平台，如何建立其理论分析基础(§1.1.3)。
|
||||
|
||||
|
||||
\subsection{算法与计算复杂性理论}
|
||||
算法复杂性度量和NP完全性理论的建立与发展，形成了计算机科学的重要研究领域：算法与计算复杂性。常见的理论结果往往是，给出某个问题的多项式时间算法，或给出某个问题的计算复杂性证明（如NP困难性）。算法分析和计算复杂性理论要考虑计算资源，即时间与空间。新时代的软件不仅催生出新的计算模型，对传统的算法分析也带来新的挑战。
|
||||
|
||||
首先，如何设计可伸缩的算法是人机物融合背景下对计算复杂性理论的一个挑战。传统的计算复杂性理论最关注的是P vs. NP问题，通常认为多项式时间能够解决的问题都可以算是能被有效求解的问题。但是在当今大数据时代，很多大图动辄都有百万量级的节点、千万量级的连接边，一个经典的$O(n^{2})$时间的图论算法将完全无法在这样的图上运行。因此设计具有可扩展性的算法，使得在小规模数据上运行较好的软件和算法能够容易的应用到大数据集上，是当前针对大数据算法研究的一个重要挑战。一般认为在大数据时代，$O(n logn)$时间或者线性时间的算法是可伸缩的，这种算法的结果通常都是近似性的，而非精确的，同时经常需要使用随机化的算法设计技术，包括采样、随机游走等设计技术，以达到$O(n logn)$乃至线性时间的复杂度。
|
||||
|
||||
其次，目前随着信息技术的发展和应用的多样化与日常化，对于软件的实时性要求越来越高，例如：导航软件、打车软件等，这为相关的算法研究带来了新的挑战。挑战之一是由于数据不断的产生和到来，与传统的离线算法不同，需要研究在线算法，算法既需要高效（算法的复杂度低），同时还要能够保证较小的竞争比（在线算法的性能与最优的离线算法性能的比值）。另外一个挑战是数据的不确定性，很多场景下输入的数据不是确定性的，而是服从某种概率分布的一个具体采样。一个典型的例子是多臂老虎机问题，动态导航问题就可以转化为一种复杂的组合多臂老虎机问题。如何在数据具有不确定性的情况下仍然能设计出具有较小的期望近似比的算法是该研究方向的一个重要挑战。
|
||||
|
||||
最后，云计算的普及和发展，为软件、算法的研究带来了新的分布式计算的挑战。分布式算法不仅仅关注时间复杂度，还更加关注节点之间的通信开销以及每个节点自身的存储开销。这里节点之间的通信开销可以建模成一个多方通信问题，但同时节点的存储开销又牵扯到空间复杂度。另外，由于可能存在某些节点临时掉线、断网、软硬件故障等，其中又涉及到传统分布式计算中的拜占庭问题等。
|
||||
|
||||
|
||||
\subsection{复杂系统的可靠性保证}
|
||||
近年来，计算机越来越深入到人们生活中的方方面面，对软件系统可靠性的要求越来越高。另一方面，随着处理器计算能力的增强和形式验证理论与技术的发展，软件验证的能力也在提高。因此，用形式化验证技术来确保复杂系统的可靠性成为一种可行的方案，得到了越来越多的关注和研究，近年来也出现了一些有代表性的优秀成果。
|
||||
|
||||
|
||||
然而，在软件日益得到广泛应用的同时，其复杂度也在不断增加。软件系统的复杂性主要体现在单点技术特性复杂、系统结构复杂、系统规模庞大等方面。复杂软件系统的验证技术也随之面临重要挑战。在形式化方法中，系统的可靠性或其他安全攸关性质可以通过规约描述，而系统是否满足规约的分析过程依赖于系统的形式化建模、分析和验证。
|
||||
|
||||
|
||||
复杂系统的可靠性挑战主要体现在以下几个方面：
|
||||
|
||||
|
||||
首先，如何准确表示复杂系统的规约。系统的规约一般通过逻辑公式、集合论等来描述对系统安全性、可靠性、正确性等各方面的需求。系统规约要解决的主要问题是，将各种非形式化表述中使用的关键概念和性质，采用简洁直观又容易被用来推理验证的数学和逻辑语言进行描述。
|
||||
|
||||
|
||||
随着系统复杂性的增加和系统应用场景的多样化，使得需要描述的性质变得更加复杂。例如，信息物理系统除了关心功能正确性，还关心非功能相关的性质，包括实时、空间位置等时空特性；机器学习算法和系统的正确性和安全性的研究目前仍处于起步阶段，即便非形式的定义和刻画这些性质仍然是开放性问题，其中一些已经被大家所接受的重要性质，如鲁棒性（Robustness），其性质刻画与经典的程序功能正确性刻画显著不同。在并发系统中，除了线性一致性（linearizability）这种经典的对并发对象的功能正确性的刻画以外，人们还提出了各种新型的量化松弛算法，它们部分放松了线性一致性的要求，但仍然能够提供一定的正确性保证。这些放松后的保证该如何进行形式化的刻画，是目前面临的关键挑战。与之类似，为了解决云计算中分布式多拷贝数据的一致性问题，并在一致性、可用性、以及系统性能方面取得平衡，人们提出了各种不同强度的数据一致性，包括最终一致性、因果一致性、顺序一致性以及各种变体，还包括多种数据一致性相结合的算法和系统，这些不同的一致性的形式化规约是当前研究的热点问题。在信息安全领域，很多安全特性不是描述程序一次运行的性质，而是要刻画程序多次运行之间的关系，如信息流安全中经典的非干扰性（Non-Interference），这一类性质往往被称为“超安全性质”（Hyper-properties），其规约也和经典的功能正确性有所不同。
|
||||
|
||||
|
||||
其次，如何形式化表示复杂软件系统。安全攸关领域的很多系统往往可看成是信息物理系统在复杂环境中的运行。由于系统的非确定性，或克服复杂性而进行的简化，很多都具有概率与随机行为。例如，由于风对飞行器运动的影响，网络控制的系统中消息的丢失及其他随机事件。因此，对既有随机、离散事件又有连续状态变化的随机混成系统的建模、分析与验证是非常困难的。为了实现随机混成系统的分析，可以通过添加概率或随机性对混成自动机进行扩展。然后对随机混成系统的验证转化成通过概率模型检验或统计模型检验进行可达性分析。但是，现有的基于随机混成系统的可达性分析方法仍存在很多不足。
|
||||
|
||||
|
||||
第三，如何保证具有复杂数据结构、算法或协议的系统的可靠性。现有软件系统中含有非常复杂的数据结构、算法和协议等，现有的验证理论难以完全支持。例如，操作系统内核中，为了提高系统效率，往往会使用非常复杂的指针数据结构，其复杂度远远超出双向链表、红黑树等教科书上的经典数据结构。操作系统内核和文件系统中，还会使用很多巧妙的无锁并发算法，其验证一直是形式化验证中的难点。加密算法和协议的验证则需要概率相关的特定验证理论。云计算平台中普遍使用地理上分布的多拷贝数据，其数据一致性算法的验证目前也缺少成熟理论的支持。
|
||||
|
||||
|
||||
第四，如何保证具有复杂体系结构的系统的可靠性。复杂系统往往由大量模块构成，模块之间的组合方式复杂，总体体现为两点：（a）从纵向看，模块之间相互调用，抽象层次不同。一方面，不同抽象层次的代码特性不同，所需要的验证理论和技术也会不尽相同；另一方面，为了实现完整系统的验证，需要将这些不同抽象层次的模块验证后，得出完整系统的可靠性结论。这需要验证技术能够有效集成不同的验证方法、理论和工具，并具有很好的纵向可组合性。（b）从横向看，模块之间有多重组合方式，例如多线程并发、事件驱动等。不同的组合方式导致模块执行的控制流的多样性，这也对系统的模块化验证以及水平方向的可组合性带来挑战。
|
||||
|
||||
|
||||
第五，如何提高软件开发的自动化程度，实现构建即正确的系统。综成(synthesis)技术可以提高软件的自动化程度。基于演绎的方法可以从高层规范的实现中派生出低层实现；基于归纳的方法可以根据实例的行为，生成满足实例的程序。但状态空间爆炸问题制约了可合成的系统规模。符号化方法、组合式方法可以提高可合成系统的规模，却难以真正投入使用。随着推理、求解技术的发展与硬件计算能力的提高，学术界出现了一系列程序自动综成工具，如Sketch、Rosette等，并用于学术界及业界的研究机构中。然而，由于可合成系统规模有限，软件的自动化仍缺乏实际应用。
|
||||
|
||||
|
||||
最后，如何验证基于学习技术的复杂系统。机器学习的准确率难以达到百分之百。有必要对使用机器学习的系统鲁棒性进行分析。这种鲁棒性分析首先根据系统使用的神经网络结构构建相应的抽象关系，再基于抽象关系分析输入在一定的扰动下，输出是否会出现分类错误。由于复杂神经网络的神经元个数是百万级别的，而且使用了大量的非线性函数，传统的方法如基于线性规划或约束求解的方法很难实现对实际系统的分析。基于神经网络中使用的非线性函数的利普希茨(lipschitz)连续特点对非线性函数进行抽象，或使用多面体(zonotope)抽象表示神经网络每层的值域可以提高可分析系统的规模，但仍缺乏对实际基于学习系统的验证[17]。
|
||||
|
||||
\subsection{新型体系结构和计算平台下的程序语义刻画和正确性保证}
|
||||
近年来，新的体系结构和计算平台大量涌现，包括多核处理器、GPU和异构芯片、分布式云计算平台等。它们对编程有各自特定的要求，也对相应的程序验证带来了重要的机遇和挑战。
|
||||
|
||||
|
||||
首先，多处理器架构对程序本身的内存模型分析与设计带来新的挑战。多核处理器的流行让并发编程由一种高级编程技巧变为一种基本的编程技能。然而，并发编程自身的困难并未随之消失，特别是经典的共享内存的多任务并发模型及其基于锁的同步机制，为并发程序设计带来了数据竞争、原子性违背、死锁、活锁等各种问题。针对这些问题，新的易用、可靠的并发编程模型一度成为研究的热点，提出的新型编程模型包括软件事务型内存（Software Transactional Memory，简称STM）、事件驱动的并发模型、基于消息传递的并发模型等。然而，从易用程度和程序效率的需求看，现有编程模型仍然无法替代经典的共享内存并发模型。并发编程的另一大挑战是内存模型问题。编译器和处理器的优化导致每个并发任务的执行并不是严格按照代码顺序逐条指令运行。虽然这些指令执行顺序的改变不会影响单个任务的串行行为，但会对多任务的程序行为产生影响。相应的，并发程序行为呈现出所谓的弱内存模型。任何一个并发编程语言需要都需要描述其内存模型，然而由于编译器优化的复杂性，为高级语言定义内存模型的工作仍然是一个开放性问题。例如Java和C++现有的内存模型仍然存在各种问题。因此，对这些模型的形式化定义和改善成为当前研究的一大热点。
|
||||
|
||||
|
||||
其次，多处理架构引发了并发程序数据一致性分析的挑战。多核平台中存在多线程并发程序对共享资源的访问冲突。多线程并发程序已经成为现代程序设计的趋势。并发软件应用中的并发数据结构提供支持多线程并发访问。但并发线程的执行存在不确定性,传统的测试方法很难发现这类错误。多核平台下的弱内存模型则使得多线程间数据访问的一致性难以保证。并发数据结构实现的可线性化（或其量化松弛）验证问题已经取得了一定进展，可线性化条件对有界多并发线程是可判定的，但对无界多并发线程是不可判定的。
|
||||
|
||||
|
||||
最后，新型计算平台引发了分布式系统数据一致性分析的挑战。云计算平台中，为了提高系统的可用性，往往采用地理上分布的多拷贝数据，这也使得系统开发需要面对数据一致性、可用性和对网络分割的容忍性这三者不可兼得的经典问题（即所谓的CAP定理），需要在三者中做出取舍，取得合理折中。考虑到强数据一致性（串行一致性）的实现对效率影响较大，实际系统中往往根据业务特点来适当放松对一致性的保证，这样带来的结果是：一方面系统中可能多种一致性并存，另一方面应用级程序员在使用弱一致性数据的时候，难以保证程序业务的正确性。如何在编程语言和模型中既支持多种一致性，又能简化编程负担，并且对程序的可靠性和正确性给出指导原则和分析验证技术，是当前研究的热点。
|
||||
|
||||
|
||||
\section{主要研究内容}
|
||||
为了应对人机物融合环境下对软件理论的诸多挑战，需要开展多方面的研究工作。首先，为了支持有效的大数据处理，需要研究针对性的算法(§1.2.1)；其次，为了保证复杂系统的可靠性，需要围绕着规约、建模、分析与验证等环节进行研究(§1.2.2)；其次，为了支持新的处理器结构与计算平台上的程序设计，需要构建相应的理论(§1.2.3)；最后，为了提高新型软件的可靠性，需要研究新型软件的特点，从而给出相应的分析方法(§1.2.4)。
|
||||
|
||||
\subsection{面向大数据的算法与计算复杂性}
|
||||
在大数据应用越来越普遍的背景下，研究面向数据科学的算法与计算复杂性理论是有效解决大数据应用问题的基础与核心。主要内容包括：新型计算模型上的算法设计与分析范式以及计算复杂性下界；数据科学所引发的非传统计算问题的高效算法与计算复杂性理论；数据依赖的算法设计与非最坏情况复杂度分析等。具体问题包括：并行、分布式、低通信、亚线性开销、动态输入、局部计算等约束下的算法设计与分析；优化、采样、推断等数据科学的计算原语在大数据环境下有理论保证的高效算法；面向隐私性、公平性等新型计算约束的算法设计与分析。
|
||||
|
||||
\subsection{形式化方法的理论研究}
|
||||
一般来说，形式化方法的理论研究内容主要涉及规约、建模、分析与验证方法。
|
||||
|
||||
\begin{itemize}
|
||||
\item 形式规约
|
||||
\end{itemize}
|
||||
|
||||
形式规约可以分为基于模型的方法与基于代数的方法。基于模型的方法有VDM、Z、B、CSP等。基于代数的方法有Lotos、Larch、LTL等。近些年来，针对串行程序的形式规约语言的进展集中在分离逻辑方面。除了针对分离逻辑的研究工作，为了验证不同的系统，研究人员对经典时序逻辑如LTL、CTL和CTL*等做了各种扩展上，包括博弈扩展、概率扩展、实时扩展、量子扩展等。时序逻辑的概率扩展主要包括PCTL、PCTL*等。对于离散马尔可夫链模型，PCTL的模型检验问题可在多项式时间内完成，而LTL和PCTL*的模型检验问题仍是PSPACE-完全的。时序逻辑的实时扩展，包括MTL和TCTL。MTL的可满足性问题和针对时间自动机的模型检验问题在连续时间上是不可判定的，在离散时间上是EXPSPACE-完全的。时序逻辑的量子扩展主要包括QCTL、QCTL*等。QCTL在量子马尔可夫链上的验证可在多项式时间内完成；同样，该逻辑的可满足性的判定问题目前仍然没有解决。另外，时序逻辑的“超性质”是基于计算机安全背景的扩展，主要包括HyperLTL、HyperCTL*等。HyperLTL的模型检验算法在最坏情况下是非初等可判定的，同时这两种逻辑的可满足性问题也是非初等可判定的，但对于其某些特定片段却存在较为高效的算法。除了基于时序逻辑形式规约的研究进展，还出现了同步语言Quartz、描述动态自适应系统的RLEAX等描述系统规约。此外，基于本体论的网络本体语言(web ontology language)也用于描述机器人、航天领域的形式规约描述系统需求。
|
||||
\begin{itemize}
|
||||
\item 形式建模方法
|
||||
\end{itemize}
|
||||
|
||||
形式建模方法用于精确地刻画计算机软硬件系统的行为。在一些安全关键领域，为了描述和验证系统的安全性，既需要描述离散的机器指令，又需要描述系统所处环境的连续特性。通常，使用混成自动机进行刻画。然而，与状态机类似，混成自动机缺乏对结构的描述。因此，出现了很多辅助复杂系统模块化表示的方法。例如，支持混成行为的层次化规范的环境SHIFT、PTOLEMY，描述并发混成行为的I/O自动机、CHARON，描述混成行为的规范HCSP(hybrid CSP)、描述基于逻辑与组合分析的混成Hoare逻辑HHL(hybrid Hoare logic)等。工业界常使用Simulink/Stateflow环境实现复杂系统的建模，但它缺乏统一的形式语义。为了对复杂系统的建模，人们还提出了组合建模方法，如HMODEST，随机混成程序。
|
||||
|
||||
|
||||
刻画无穷状态系统有随机、参数化等模型，除了使用相应的分析工具如INFANY、JKind等，还可以统一在进程重写系统(Process Rewrite System, PRS)中进行分析。
|
||||
|
||||
|
||||
最近，深度神经网络的健壮性分析是研究热点之一。神经网络的结构常被表示为一组在整数域或实数域上的线性算术方程组与激活函数对应的非线性方程组的集合。然而已有的线性优化算法或者SMT求解器不擅于直接求解非线性方程。比较普遍的方法是根据具体的非线性方程，对线性优化算法或SMT求解器进行扩展，验证神经网络的安全性，或找到对抗干扰实例。
|
||||
|
||||
\begin{itemize}
|
||||
\item 形式分析与验证方法
|
||||
\end{itemize}
|
||||
|
||||
|
||||
软件系统的分析与验证的核心问题与挑战是如何应对系统的复杂性，缓解状态空间爆炸问题，并提高分析的精度与效率。形式分析与验证方法主要包括符号执行、抽象解释、定理证明、模型检验等，从不同方法与角度提高分析验证系统的精度与规模。
|
||||
|
||||
1)基于符号执行的程序分析方法
|
||||
|
||||
符号执行提供了一种系统性遍历程序路径空间的手段。提高可伸缩性方面的研究包括设立特定的搜索策略、约束输入范围减少程序的路径空间、优化路径条件、或面向特征的高效编码提高可伸缩性。在可行性方面的研究基本都是在分析的精确性、可靠性、建模工作量以及可扩展性之间进行权衡和折中。面向新的分析需求，也有一些新的符号执行技术出现，其中比较有代表性的是概率符号执行技术。符号执行技术与其他技术之间的紧密融合，以提高分析的效果，也是目前新的发展趋势，包括与模型检验、抽象解释、模糊测试、随机测试等的一些技术结合，以提高程序的覆盖率或缺陷发现效率。
|
||||
|
||||
2)基于抽象解释的形式验证方法
|
||||
|
||||
抽象解释理论为程序分析的设计和构建提供了一个通用的框架，并从理论上保证了所构建的程序分析的终止性和可靠性。抽象解释的核心问题是提高抽象的精度。为提高抽象解释分析精度，可以结合符号化方法来提高分析精度，利用SMT求解器、插值等技术来计算程序语句迁移函数的最佳抽象；也可以提高抽象域的非线性表达能力。如何有效降低存储开销和提高计算效率，是提高抽象解释可扩展性需要考虑的主要问题。在提高抽象解释的可行性方面，研究工作包括复杂数据结构如数组内容、数值与形态混合程序自动分析的支持；不同谱系目标程序如多线程程序、中断驱动型程序、概率程序的支持；活性性质如时序性质、终止性分析的支持。
|
||||
|
||||
3)基于演绎推理的定理证明方法
|
||||
|
||||
定理证明的基本思想是将程序满足其形式规约的证明问题转化为一组数学命题的证明。为了提高证明的效率，推广定理证明的应用，定理证明方面的研究可以分成两部分：交互式定理证明（Interactive Theorem Proving）和自动推理（Automated Theorem Proving）。交互式定理证明最常用的两个证明辅助工具是Coq和Isabelle。Lean是一个最新的证明辅助工具，其中的一个设计重点是允许更有效的证明策略的实现。自动定理证明的基础包括SMT（Satisfiability Modulo Theories）和归结(Resolution)。SMT的研究对象是各种领域知识的逻辑组合，经常表达为带等词的一阶逻辑公式。惰性算法是目前主流的SMT求解方法，采用了被称为DPLL（T）的算法框架。为了DPLL求解与理论求解更为有效地结合，理论判定过程一般要设计为增量式的（Incremental）和可回溯的（Backtrackable）。主流SMT求解器还采用多种策略加速求解过程，如理论预处理，选择分支，理论推导，理论冲突分析和引理学习等。此外，基于定理证明的方法也可以支撑构造即正确的系统软件开发，如具有分层规范与公式推导特征的DeepSEA程序能够生成由CompCert编译的C程序、低层的Coq规范，以及表明该程序满足规范的证明。
|
||||
|
||||
4)基于模型检验的形式验证方法
|
||||
|
||||
反例制导的抽象精化方法（Counter-Example Guided Abstraction Refinement，CEGAR）是当前复杂系统模型检验的主要手段之一。同时，基于插值（Interpolant）来对抽象谓词进行精化、有界模型检验（Bounded Model Checking，BMC）也是主流的研究方向。目前相关方向的工作主要集中于如何对代码中各种数据结构如数组、位向量、堆等进一步提供编码机制，如何对给定深度内行为空间进行有效编码及剪枝等来提升可验证系统规模，并提高验证效率等。此外，通过多技术深度融合来进行代码验证是近年来的重要趋势之一。如将抽象解释（Abstract Interpretation）与模型检验相结合，将插值技术与SMT结合等等。其中最具有代表性的工作为CPAChecker工具。它基于若干技术的结合，通过统一接口集成多种求解器和技术来对软件系统进行验证，从而得到更好的性能和可伸缩性。
|
||||
|
||||
|
||||
简单混成系统的验证可以通过时间自动机、多速率自动机等实现。基于决策过程的Tarski代数的方法可以计算特定线性混成系统的可达集计算。HYTECH模型检验工具是第一个实现线性混成系统的精确符号化可达性分析工具，用的是基于多面体（polyhedral）计算的方法。而CHECKMATE、d/dt工具使用多面体方法计算线性混成系统可达集的上近似。除此以外，还可以通过惰性定理证明方法分析线性或非线性混成系统的限界可达性问题，混成系统的分析还可以采用基于网格或谓词抽象的连续动力学特性的离散化等技术。
|
||||
|
||||
|
||||
能够避免可达集计算的演绎推理方法，被越来越多的用于复杂混成系统的验证，其核心是用来描述与推理系统属性的规范逻辑的表达能力。例如，Platzer等人提出的Differential (algebraic) dynamic logic可用于大部分混成系统的建模与自动化推理。
|
||||
|
||||
5)面向复杂系统的统计模型检验方法
|
||||
|
||||
统计模型检验方法通过有限多次的执行对系统进行模拟，并使用假设检验来推断这些样本是否提供满足或违反规范的统计证据。虽然基于仿真的解决方案并不能保证正确的结果，但可以限制发生错误的概率。而且，基于模拟的方法比基于搜索的精确方法使用的计算资源要小得多。
|
||||
|
||||
6)面向复杂系统的运行时验证方法
|
||||
|
||||
由于可以在系统运行时检测系统是否满足规范或出现异常，运行时验证技术使用的更为广泛。它的基本思想是将形式化描述的规范转换成监测器，插桩在实际的系统中，观测系统行为是否出现异常。目前，可监测的范围既可以是形式描述的规范，也可以是抽象出来的系统行为，不仅可以对传统的软件进行监测，也可以对基于学习的软件进行监测。为了降低监测行为对系统的开销，还出现了硬件形式的监测器，实现对实时系统的监测。
|
||||
|
||||
|
||||
\subsection{新型体系结构和计算平台下的程序设计理论}
|
||||
为了应对新涌现的体系结构与计算平台，软件与程序理论主要研究运行于新体系架构程序的语义、可靠性保证等问题。
|
||||
|
||||
|
||||
新型体系结构下内存模型的形式化定义是软件理论研究的领域之一。片上多核／众核处理器已成为计算机体系结构发展的主流。传统的顺序一致性（sequential consistency）模型虽然符合程序设计的直觉，但已不能满足编译优化、处理器性能提升等多方面的需要。目前主流的多核处理器如x86、ARM和Power等所实现的内存模型都放松了对一致性的要求，允许同一线程对不同地址的读写访问可以乱序执行。在程序设计语言层面，如C11/C++11、Java等，也直接定义了内存模型，支持基于共享内存的多线程程序设计，为编译优化、虚拟机性能提升等提供必要基础。但目前，处理器及程序设计语言层面的内存模型仍缺乏严格的形式化定义，使并发程序设计及验证变得更加困难。已有的语义有x86-TSO内存模型的操作语义、Power内存模型的公理语义。但如何严格刻画不同处理器、程序设计语言的内存模型，仍有待进一步研究。
|
||||
|
||||
|
||||
多处理器架构的并发程序可线性化问题是新型体系架构下的另一个研究内容。可线性化是多处理器并发程序设计的一种正确性条件，沿袭了顺序式程序设计的惯性，但可能会由于顺序瓶颈（Sequential bottleneck）制约并发软件的性能和可扩展性。近年来提出的准可线性化（Quasi-Linearizability）及更一般的量化松弛框架允许放松可线性化标准所要求的严格顺序规约（如放松并发队列的FIFO顺序），以适应多核平台性能优化的灵活性。可线性化问题对有界多并发线程而言是可判定的，但对无界多并发线程而言已经是不可判定的。在理论方面，已证明准可线性化问题对有界多并发线程而言是不可判定的；一般而言，弱内存模型可线性化在无界多调用/返回操作的情况下是不可判定的，但在有界多调用/返回操作的情况下是可判定的，因此可以采用静态方法来验证限界条件下并发数据结构实现的弱内存模型可线性化问题。
|
||||
|
||||
|
||||
近年来，高性能计算机的峰值计算能力不断提高。但相关软件的发展还难以跟上。如何保证这类软件的可靠性，更是一个尚未解决的难题。目前，虽然有少量研究[13]，但不能用于大规模并行程序的验证。
|
||||
|
||||
|
||||
\subsection{新型软件及应用的处理与分析方法}
|
||||
对于近年来新出现的各种软件及应用，核心问题是在提高系统效率的同时，如何保证系统的可靠性。基于人工智能(学习)的系统是近期出现的主流新型软件之一。根据不同的系统需求，有不同的研究方法。
|
||||
|
||||
|
||||
一类研究围绕着如何攻击与防御人工智能系统。基于学习的模型极易受到噪音的影响，输入中的一点噪音就会改变输出结果。因此对抗样本是不可避免的。在实际系统中，对抗样本攻击的成功率非常高。如何快速地寻找对抗样本，进行攻击，是个重要的研究问题。它本质是一个优化问题，通常可以利用梯度下降优化的方法得到较好的解。目前较新的方法将模型与噪声都转变成优化目标项，而输出限制条件转换成损失函数，值域限制被转换成了平滑截断函数的变量，这样优化器可以通过直接优化目标函数，得到对抗样本。除了对抗样本的寻找，另一个方向是如何进行防御，如对抗训练、防御蒸馏等。有研究表明，即使在有防御蒸馏保护的前提下，仍可以通过转移学习生成有效的对抗样本。
|
||||
|
||||
|
||||
另一类研究以形式化分析为基础，提供该类系统的可靠性、鲁棒性等保证。基于神经网络的智能系统结构复杂，神经元结点数众多。如何验证这类系统的正确性、分析其可靠性，是一个挑战性的问题。基于抽象的方法大大提高了可处理的神经元个数。由于实际系统的输入具有不确定性，针对确定的神经网络结构判断系统对每个输入的鲁棒性难以推广，目前缺乏对实际系统可用的验证方法。一种可行的方法是对接近输出的中间层进行验证。或者，针对神经网络的可解释性问题，把语义作为训练内容，与现有的系统结合，增加网络的可解释性。另一种可行的方法是根据系统训练过程中网络结构特点，构建输出的监测器。在使用中若某个输入导致了异常的网络内部结构，则该输入可能未在训练集范围内，输出结果不一定可靠。
|
||||
|
||||
\section{本章小结}
|
||||
计算机软硬件的飞速发展以及不同领域需求的日益复杂，催生出各种实际问题，为软件的设计与开发带来巨大的机遇与挑战。作为软件学科基础的理论与方法也需要与时俱进；我们需要不断探索解决这些挑战性问题的新途径。软件理论依赖于各种数学手段；反过来，软件及理论的发展也可能给数学研究带来新的问题。
|
||||
|
||||
\section{参考文献}
|
||||
[1]. L. Peter Deutsch, Ronald B. Finkbine. ACM Fellow profile. ACM SIGSOFT Software Engineering Notes 24(1): 21 (1999).
|
||||
|
||||
|
||||
[2]. Y. Afek, G. Korland, E. Yanovsky. Quasi-linearizability: Relaxed consistency for improved concurrency. 14th International Conference On Principles of Distributed Systems (OPODIS’10), 395-410, 2010.
|
||||
|
||||
|
||||
[3]. T. Henzinger, C. Kirsch, H. Payer, A. Sezgin, A. Sokolova. Quantitative relaxation of concurrent data structures. 35th ACM Symposium on Principles of Programming Languages (POPL’10), 395-410, 2013.
|
||||
|
||||
|
||||
[4]. X. Huang, M. Kwiatkowska, S. Wang, et al. Safety Verification of Deep Neural Networks[C]. CAV 2017, LNCS 10426, pp. 3-29. Springer.
|
||||
|
||||
|
||||
[5]. L. de Moura, S. Kong, J. Avigad, F. van Doorn, and J. von Raumer. The Lean Theorem Prover[C]. CADE 2015. LNAI 9195, pp. 378-388, Springer.
|
||||
|
||||
|
||||
[6]. D. Kroening and O. Strichman, Decision Procedures—An Algorithmic Point of View[M], Springer, 2008.
|
||||
|
||||
|
||||
[7]. R. Nieuwenhuis, A. Oliveras, and C. Tinelli, Solving SAT and SAT Modulo Theories: From an abstract Davis--Putnam--Logemann--Loveland procedure to DPLL(T)[J], Journal of ACM 53(6), pp. 937-977, 2006.
|
||||
|
||||
|
||||
[8]. Y. Sun, M. Wu, W. Ruan, X. Huang, Marta Kwiatkowska, Daniel Kroening: Concolic testing for deep neural networks. ASE 2018: 109-119.
|
||||
|
||||
|
||||
[9]. T. Gehr, M. Mirman, D. Drachsler-Cohen, P. Tsankov, S. Chaudhuri, M. T. Vechev: AI2: Safety and Robustness Certification of Neural Networks with Abstract Interpretation. IEEE Symposium on Security and Privacy 2018: 3-18.
|
||||
|
||||
|
||||
[10]. D. Beyer, M. E. Keremoglu. CPAchecker: A Tool for Configurable Software Verification. CAV 2011, LNCS 6806, pp. 184-190. Springer.
|
||||
|
||||
|
||||
[11]. E. M. Clarke, O. Grumberg, S. Jha, Y. Lu, H. Veith. Counterexample-guided abstraction refinement. CAV 2000, LNCS 1855, pp. 154–169. Springer.
|
||||
|
||||
|
||||
[12]. R. Alur, K. McMillan, D. Peled. Model-checking of correctness conditions for concurrent objects. 7th IEEE Symposium on Logic in Computer Science (LICS’96), 219-228, 1996.
|
||||
|
||||
|
||||
[13]. A. Bouajjani, M. Emmi, C. Enea, J. Hamza. Verifying concurrent programs against sequential specifications. 22nd European Symposium on Programming (ESOP’13), LNCS 7792, 290-309, 2013.
|
||||
|
||||
|
||||
[14]. X. Fu, Z. Chen, Y. Zhang, C. Huang, W. Dong, J. Wang. MPISE: Symbolic Execution of MPI Programs. HASE 2015: 181-188.
|
||||
|
||||
|
||||
[15]. X. Jin, B. W. Wah, X. Cheng, Y. Wang. (2015). Significance and challenges of big data research. Big Data Research, 2(2), 59-64.
|
||||
|
||||
|
||||
[16]. E. Kazemi, M. Zadimoghaddam, A. Karbasi. Scalable deletion-robust submodular maximization: Data summarization with privacy and fairness constraints. In International conference on machine learning: 2549-2558.
|
||||
|
||||
|
||||
[17]. Xiaowei Huang, Daniel Kroening, Wenjie Ruan, James Sharp, Youcheng Sun, Emese Thamo, Min Wu, Xinping Yi. A Survey of Safety and Trustworthiness of Deep Neural Networks. arXiv:1812.08342.
|
||||
|
|
@ -0,0 +1,198 @@
|
|||
|
||||
世界离不开计算，描述计算离不开程序设计语言。不同的程序设计语言描述不同的计算模式，比如，命令式语言描述以状态的变换作为计算的模式，函数式语言描述以函数作为计算的模式，逻辑语言描述以证明作为计算的模式，而量子语言则描述量子计算的模式。
|
||||
|
||||
|
||||
“软件定义一切”本质上是可编程思想扩张到整个社会和物理世界，是一种以软件实现分层抽象的方式来驾驭复杂性的方法论。随着人机物融合的发展，计算的泛在化成为必然，程序设计语言向下需要对物理世界进行抽象并提供处理物理世界的接口，向上需要能够处理不同场景的多范式的应用编程。泛在计算中不断涌现出的新的计算模式、新的计算平台和新的应用问题给程序设计语言的定义和实现带来了新的挑战。
|
||||
|
||||
|
||||
首先，新的计算模式需要新的程序设计语言。随着不断涌现的新的计算模式，如适合于抽象描述机器学习的概率计算、神经网络计算、大数据计算、保护隐私的计算等，我们需要新的语言定义和实现技术，快速开发各种各样新的程序设计语言，支持各类新型计算模式。
|
||||
|
||||
|
||||
第二，新的硬件和计算平台需要新的语言实现技术。新的硬件（如GPU、非易失性内存等）和新的计算平台（如云、网构等）不断涌现。除了设计新的程序设计语言，我们还需要研究新的编译技术以生成适合于新的硬件和体系结构的高效代码。
|
||||
|
||||
|
||||
第三，新的应用问题需要新的程序设计语言来高效地解决。随着社会的发展，我们会遇到各种各样的新的复杂的应用问题，除了利用既有程序设计语言开发新的软件之外，我们还可以通过设计更好的程序设计语言来解决这些问题。新型语言不单单提供了描述解决该问题本身的一个方法，而且可以提供解决一类相似问题的方便而可信的一般途径。程序设计语言技术提供给我们解决类似问题的方便而可信的途径。
|
||||
|
||||
|
||||
第四，程序设计语言的发展需要健在的语言生态。程序设计语言的生态，包括支撑环境、集成开发环境、扩展功能支持库、第三方功能模块、帮助文档和知识库、技术交流社区、资源下载网站、教程和培训等。程序设计语言生态的繁荣决定了程序设计语言的繁荣。
|
||||
|
||||
|
||||
在这一章里，我们将从计算的泛在和多样性，计算平台，软件的复杂性和安全性，以及软件的生产效率等几个方面来讨论新时代软件设计语言与支撑环境方面的挑战，列出重要的研究内容，并阐述展示程序设计语言及支撑环境方面的研究趋势。
|
||||
|
||||
\section{重大挑战问题}
|
||||
程序设计语言的挑战问题集中于如何建立、描述和实现抽象。具体来说，其挑战表现在两个方面。首先，在抽象建立和描述方面，主要表现在如何通过对领域和应用问题的抽象，开发有效的领域特定语言(§1.1)、支持多范式程序设计(§1.2)，特别是加强大数据时代语言对数据处理的支持(§1.3)。其次，在抽象的实现方面，主要表现在如何开发人机物融合的泛在混合系统的编译技术(§1.4)和构建程序语言的安全性保障机制(§1.5)。
|
||||
|
||||
\subsection{面向泛在计算的语言的定制}
|
||||
随着泛在计算的普及，一方面，专用化的计算设备和运行平台需要软件具备面向不同专用硬件和平台的高效定制能力；另一方面，泛在服务软件需要提供各种特定的编程抽象，支持面向人机物融合的最终用户编程。在泛在计算的环境下，程序员的概念也不断泛化——未来越来越多的人，甚至那些缺乏足够计算机专业知识的领域专家，需要对专用化的设备或特定领域的问题进行程序设计。这就需要我们开发各式各样的领域特定语言。面向泛在的计算为领域特定语言的定义和实现带来了新的挑战。
|
||||
|
||||
\begin{itemize}
|
||||
\item 特定领域语言一般是轻量的，是通用语言的特例。在通用语言的实现已经存在的前提下，我们可以用通用语言的方式来定义和实现领域特定语言。然而，这种方式不仅增加了开发的难度，而且也不经济。我们需要一种高效的特定语言的定义和实现方法。一个想法是设计并实现一种通用语言作为特定语言定义和实现的基础，但是什么样的通用语言适合于定义和实现各类特定领域语言是一个必须解决的问题。
|
||||
\item 对于通用语言，我们已经开发了不少很有用的程序分析、优化、调试、测试方法。对于特定领域语言，我们需要利用这些方法。尽管我们可以用通用语言来实现某种特定领域语言，但是如何能够将这些一般性的方法系统化地映射到特定语言的实现上是一个挑战。比如，假设我们在通用语言上实现了一个测试方法，但是通用语言上的测试结果对于特定领域语言的用户而言是不能理解的。我们只有将通用语言上的测试例子和结果映射到特定语言程序上，特定领域语言的用户才能理解。
|
||||
\item 在设计特定领域语言时存在的一个选择是应该设计一个小而精的语言，还是设计一个大而全面的语言？Schema语言的设计者之一的Guy Steele认为，既不应该建立一种小语言，也不应该建立一种大语言，而需要设计一种可以成长的语言。语言设计应该是增长式的——语言必须从小开始，能够随着用户集的增长而增长。例如，我们可以比较APL语言和Lisp语言：APL不允许用户以“流畅”的方式向该语言添加新的原语（premitive)，这使得用户难以扩展该语言；在Lisp中，用户可以定义与语言基元保持一致的单词，它使语言用户可以轻松扩展语言并共享代码。为此，在设计语言时，我们面临的挑战是，如何保证其具有一定的韧性，支持新的语言构造和特性可以被无缝接入其中，同时，在语言演化过程中，也能保证遗留系统被无障碍地执行。
|
||||
\end{itemize}
|
||||
\subsection{多范式程序设计的语言支持}
|
||||
主流程序设计语言支持不同的程序设计范式。从程序设计语言的角度出发，一方面，需要设计与程序设计语言相适应的程序设计范式或者程序设计模型，以获取程序可读性、模块性、抽象性和性能上的平衡。另一方面，需要提供技术手段，根据程序员能力或者开发任务自动选择或者推荐程序设计范式，提升程序员程序设计效率。然而随着解决的问题越来越复杂，我们需要研究支持多范式的程序设计语言，以及对多范式语言的高效实现机制。特别是，我们面对下面一些挑战。
|
||||
|
||||
|
||||
首先，如何将描述函数计算最直接的函数式程序设计融合到其它语言中是多范式语言设计的一个挑战。函数式程序设计 (Hu, 2015)用函数来抽象计算，它的高阶函数和计算的透明性的两个重要特征，一方面使函数式语言适用于大数据处理、人工智能等领域，但是另一方面也使它不容易与其它语言共用。尽管已有不少关于研究和系统讨论如何融合逻辑语言与函数式语言，融合面向目标式语言和函数式语言，不少通用程序设计语言（C++和Java、Kotlin等）也开始支持函数式程序设计，但是，现在还没有一个公认的计算模型来系统地支持这种融合的设计和实现。如何将函数式语言的高阶函数和计算透明性有效而便捷地扩展至通用程序设计语言及支撑环境，以支持函数式程序设计或混合程序设计，成为一个值得关注的挑战问题。
|
||||
|
||||
|
||||
其次，无缝融合并发程序设计是多范式语言设计和实现的另一个挑战。目前已经存在很多并发程序设计模型，它们指定了系统中的线程/进程如何通过协作来完成分配给它们的作业——不同的并发模型采用不同的方式拆分任务，线程/进程间的协作和交互方式也不相同。为此，需要建立与特定程序设计语言相适应的一组并发模型，更好支持程序员设计与实现并发任务。此外，传统的并发思维，是在单个处理器上，使用分时方式或是时间片模型来执行多个任务。如今的并发场景则正好相反，是将一个逻辑上的任务放在多个处理器或者多核上执行。因此，程序设计语言需要提供足够的机制来分解任务。然而，基于目前并发API，比如线程、线程池、监视等，编写并发程序依然很困难，还需要更多关于程序设计语言及实现方面的努力。例如，可以由编译器甚至执行引擎识别出程序中可并发的任务，以便多核计算机可以将其安全地并发执行。
|
||||
|
||||
\subsection{大数据处理的程序语言支持}
|
||||
当今时代是大数据的时代。全球的数据在不断地增多，依赖这些数据对各行各业进行优化是当今社会的发展趋势。大数据呈现出体量巨大，数据类型多样，数据增长速度快和数据价值密度低的4V特征，这就意味着要利用好数据中的价值，我们必须依赖于程序以自动化地管理和分析数据，从而给程序设计语言带来了一系列全新挑战。
|
||||
|
||||
|
||||
首先，大数据的一个特点是数据类型多样，但不同的人和不同的场合需要的数据是不一样的，这就意味着我们常常需要对数据按不同方式进行组织。数据自主性和数据互操作性给程序语言的设计带来挑战。一方面，当我们按照某一种特定格式获取到数据的时候，需要把数据转换成其他格式保存和展示。另一方面，当我们修改了其中一份数据的时候，需要保证其它保存的数据和展示的视图都能对应修改。如果用传统程序设计语言编写这样的数据同步程序有两方面的问题：(1) 重复的编码工作量大：对于两种数据的同步一般需要编写两份转换程序，但这两份转换程序很多部分是重复的。(2) 很容易出现错误：两份转换程序容易写得不一致。因此，需要新的程序设计语言来处理此类数据管理需求。
|
||||
|
||||
|
||||
其次，大数据具有体量巨大、数据增长快的特点。这就意味着，要对海量的大数据进行分析，不但人工无法完成，小型计算机系统通常也无法完成。要完成海量的数据分析，往往需要包含多个CPU的大型机系统，或者由多个中小型计算机联网形成的集群系统。但是，用普通程序设计语言编写这类集群系统上的大数据处理程序非常复杂，因为程序员必须处理并行任务分解、多CPU/计算机调度、进程/线程同步等一系列问题。需要新的程序设计语言来降低大数据处理程序的编写难度。尽管MapReduce, Pregel等面向大数据处理的并行计算模型已经提出，但是基于这些模型的程序语言要么接近于模型、用户难以使用，要么用户容易写，但是缺少优化方法、运行效率低。需要新的程序设计语言来解决此类数据计算需求。
|
||||
|
||||
|
||||
最后，大数据具有价值密度低的特点，这就意味着如果要发挥大数据的作用，需要采用合适的方式对数据进行统计。有效的统计方法往往需要我们针对数据的特点构建统计模型，然后根据统计模型对数据进行统计。比如，现在流行的神经网络需要用户首先给出网络结构，然后根据数据确定网络中参数数值。而基于统计学的概率图方法需要先确定随机变量的分布和随机变量之间的依赖关系，然后基于数据确定随机变量的后验分布。这些统计模型的编写较为复杂，同时给定模型之后的统计算法也比较复杂，因此，需要有新的程序设计语言来支持这类模型的描述（如概率编程等）、验证和测试。
|
||||
|
||||
\subsection{面向人机物融合的混合编译}
|
||||
编译器是程序设计语言的重要支撑环境，其负责将一种语言（通常为高级语言）所书写的程序变换成另一种语言（通常为低级语言）程序。编译器的另一个主要功能是对程序进行优化，提升软件的性能。现代软件系统呈现人机物融合的泛在混合特性，对编译技术也带来新的挑战。
|
||||
|
||||
首先，编译器需要能够快速对应不断出现的专用处理器。摩尔定律的逐渐失效以及大数据处理深度学习等新应用需求的出现，正助推计算机行业从通用计算机系统，转向一个青睐专用微处理器和专用存储系统等专用硬件的时代。这种转变需要我们研究新的更有效的编译技术。当一个新的硬件出现之后，首先，应该对专用硬件进行抽象，定义一个底层使用该硬件的领域特定语言（DSL）；然后，扩充现有的语言，为之提供一个高层次的界面，以便用户描述专用硬件上的计算；最后，定义如何将高层次的程序翻译到底层的DSL。为了支持这个过程，我们需要研究自动编译技术——我们预测未来的编译器能够在SMT等求解器的帮助下自动生成能在专用处理器上运行的的目标程序，通过重写策略对目标程序自动优化，且保证编译过程的正确性和代码质量。
|
||||
|
||||
|
||||
其次，编译器需要能够高效地处理混合系统。现在的软件系统越来越复杂，形成了一个混合的系统，需要既能处理离散的又能处理连续的计算，既能处理决定性（逻辑式）的又能处理概率性的计算，既针对命令式的又针对函数式的程序设计语言，既可静态类型检查又可以动态确认程序满足的性质。为了开发这样的复杂的软件系统，混合语言以及相应编译技术变得非常重要。此外，复杂软件系统可能由不同程序设计语言书写的程序组成。对不同程序设计语言所书写的程序进行高效混合编译，也是一个值得关注的研究问题。
|
||||
\subsection{程序设计语言的安全性保障}
|
||||
程序设计语言的安全性，体现在两个方面：程序设计语言自身的安全性设计与其支撑环境（如库、编译器、解释器、运行时等）的安全性保障。程序设计语言的设计者和实现者都在不遗余力的提升程序设计语言的安全性。当前，程序设计语言的安全性方面，还存在以下的重大挑战问题。
|
||||
|
||||
|
||||
首先，需要建立语言安全性和灵活性、复杂性之间的平衡。程序设计语言的安全性主要体现为程序设计模型中一组机制，保障程序员写出安全的程序。例如，C++支持的RAII（资源获取即初始化）通过栈语义保证对象析构函数的自动调用，解决了内存泄漏问题；类型系统使代码仅能访问被授权可以访问的内存位置；脸书公司推出的智能合约语言Move语言不支持动态分配和循环递归依赖等（Blackshear，2019）等。然而，语言安全性的提升意味着程序设计灵活性的下降、支撑环境复杂性的提升。为此，在设计一门程序设计语言的同时，需要定义一组通用的或领域/环境相关的安全机制，包括是否支持指针、自动垃圾回收、异常处理，是否支持强类型检查和中间码验证等，一方面允许程序设计人员编写出既功能强大又足够安全的程序，另一方面在静态编译或者动态执行时实现程序的安全性检查。
|
||||
|
||||
|
||||
其次，需要提供充分保障支撑环境可靠性、安全性的分析、测试和验证等技术手段。编译器、虚拟机和执行引擎的代码复杂，其中潜伏着包含缺陷或者安全漏洞。如何提升编译器、虚拟机和执行引擎的安全性是一个重要的问题。当前已经出现了经过验证的编译器，例如CompCert。此外，已经出现了一批针对编译器和虚拟机的测试和安全分析工作，例如CSmith、EMI等。尽管如此，对编译器（包括优化算法）及虚拟机等安全性分析、测试、验证工作还面临很多问题，我们仍需要能够充分保障编译器、虚拟机和执行引擎的安全性的分析、测试和验证技术手段。例如，不可能枚举出一个语言的所有程序实例以对支撑环境进行穷尽测试，相反，需要提供一套策略，协助选择或者自动生成具有代表性的程序实例以高效测试支撑环境的健壮性。特别是，针对支撑环境进行广泛测试，针对各类编译技术和算法（如优化算法和垃圾回收算法）进行正确性验证，及验证应用程序接口的正确性，仍然是这个方向上的难点问题。此外，在程序设计语言动态演化过程中，需要提供足够的技术手段，保障语言新特性和支撑环境新功能可以被可靠地、安全地加入至既有语言和支撑环境中。
|
||||
|
||||
\section{主要研究内容}
|
||||
为了应对上述重大挑战，需要在多方面开展研究。首先，为了支持泛在计算(§2.1.1)、大数据处理(§2.1.3)、和人机物融合(§2.1.4)等多种新型应用场景，需要研究面向不同领域的编程语言，包括面向数据管理统计的程序设计语言(§2.2.2)、面向软件定义网络的程序设计语言(§2.2.3)、支持最终用户编程的程序设计语言(§2.2.6)。其次，为了设计面向泛在计算的语言(§2.1.1)和实现多范式程序设计支持(§2.1.2)，需要研究多范式和领域特定的程序设计语言(§2.2.1)、离散和连续混成系统的语言和工具(§2.2.4)以及支持共享内存模型的并发程序设计(§2.2.5)。最后，为了支持新语言所带来的开发环境和生态的变化，我们需要研究程序设计框架和程序设计开发环境(§2.2.7)、特定领域语言的元编程和开发环境(§2.2.8)、程序设计语言的生态及其演化规律(§2.2.9)。
|
||||
|
||||
\subsection{多范式和领域特定的程序设计语言}
|
||||
主流程序设计语言都支持多种程序设计范式。一方面需要研究如何设计程序设计语言所支持的范式乃至于库、编程框架等，以助于程序员更便捷地编写大型应用。另一方面，需要研究如何根据程序员能力或者开发任务自动选择或者推荐程序设计范式，以提升程序员程序设计效率。此外，也需要对多范式程序设计语言的支撑环境（含编译、编译时和运行时优化、内存管理、多线程处理、垃圾回收等）及其程序分析、验证技术进行研究——在一门程序设计语言中引入新的程序设计范式，往往需要很多工业界和学术界的努力，避免支撑环境的复杂性、分析及验证技术难度的急剧上升。
|
||||
|
||||
|
||||
随着专用处理器等硬件的不断出现以及各种特定应用领域软件开发的需求，领域特定语言的开发变得非常重要。领域特定语言既向下提供特定平台的编程模型，也向上提供具体应用场景的需求描述方法。尽管我们可以使用一般的程序语言的设计方法和编译技术，但是这样开发效率低。我们应该开发在通用语言的基础上实现领域特定语言的技术。主要研究内容包括：（1）如何在用户的DSL上来表示运行时和编译时的错误；（2）如何自动生成测试用例直接测试DSL程序；和（3）如何将深度嵌入和浅嵌入的领域特定语言的定义方法结合起来。
|
||||
|
||||
\subsection{面向数据管理统计的程序设计语言}
|
||||
数据在我们的生活中无处不在。在一个医疗保健系统中，医院、药房、患者都有各自的数据，为了保护隐私，这些数据没有被集中统一管理，而是以一种非中心的方式分散在不同的系统中。如何安全地共享和交换信息从而实现非中心数据的互操作成为现代社会亟需解决的一个重要问题。为了解决这个问题，需要将非中心数据的互操作问题分解为(1)局部的隐私控制问题、(2)全局的数据同步问题、(3)联系局部和全局的软件体系结构问题。每个问题的解决都需要我们设计好的程序设计语言，从而实现一个高可信且可扩展的非中心数据的互操作系统。目前，研究人员提出的双向变换语言(Czarnecki,2009)能够保证两种数据的一致性，为部分解决数据的互操作提供一个好的解决方案，值得进一步深入研究。
|
||||
|
||||
|
||||
解决数据统计问题的途径是设计程序设计语言来编写统计模型。目前的统计模型语言主要包括两类。一类是支持神经网络编写的语言，代表语言包括TensorFlow(Abadi, 2016)、PyTorch(Paszke, 2017)等。神经网络要求构造出一个网络结构，同时网络上的所有运算都要是能求导的。神经网络的程序设计语言通过限定程序中的运算必须是由可求导的操作构成来保证网络是可以求导的，并利用微积分中的求导算法自动求导来完成网络的训练。此外，神经网络语言通常包括大数据分析语言的功能，可以将运算分配到多个CPU或者多台计算机上，应对大数据程序的运算量要求。另一类是概率程序设计语言，代表语言包括Stan (Carpenter, 2017)、PyMC (Patil, 2010)等。概率程序设计语言主要用于编写一个概率模型，包括随机变量、随机变量的分布和相互关系等，允许程序员指定一些模型上的观察值，通过贝叶斯统计来对模型其他部分的随机变量计算后验分布。概率程序设计语言通常提供一系列分析算法和采样算法用于求解和近似求解模型，同时部分语言也提供并行计算能力，以支持用于在大型机/集群系统上快速求解。
|
||||
|
||||
|
||||
\subsection{面向软件定义网络的程序设计语言}
|
||||
传统网络设施的网络协议都固定在芯片中，一旦制造出来就不可能支持新的网络协议。为了解决这个问题，软件定义的网络设备把控制器制作成可以程序设计的开关电路，允许通过软件控制开关来实现不同的协议。最基础的软件定义网络程序设计语言是Openflow(McKeown, 2008)，该语言用于直接控制网络硬件中的开关。由于直接程序设计控制开关较为困难，研究人员又进一步提出了高层的程序设计语言，其代表语言为NetKat语言(Anderson, 2014)和P4语言(Bosshart, 2014)：NetKat语言主要从控制角度看待网络协议，允许程序员采用类似普通函数语言的方式来声明函数和函数的组合，然后该语言的编译器负责将这种高层声明转换成Openflow上的开关控制；P4语言主要从数据角度看待网络协议，通过数据格式和对应数据项上的操作来描述网络协议。然而，程序设计人员在编写应用的时候仍需要使用一组与新型硬件相关的库函数，这极大程度地影响了既有系统在新型硬件上的运行或者迁移。这里，值得关注的研究内容包括：（1）定义高层次的、具有更强表达能力的网络定义语言；（2）通过修改底层支撑环境（包含操作系统、编译器、执行引擎、库等），支持既有系统在编译或者执行过程中，主动支持新型硬件的使用。
|
||||
|
||||
\subsection{离散和连续混成系统的语言和工具}
|
||||
混成系统是由离散和连续的多个子系统组合而成的混合模型。尽管近年来已有很多处理混成系统的语言和系统工具，每个语言和工具对环境做出不同的假设，导致混成系统难以在不同的语言和工具之间共享信息。因此，需要解决混合系统中各个子系统的一致性问题，从而最大限度地利用现有的语言和工具。主要研究内容包括：（1）审阅和比较现有混成系统语言和工具的语义、表达能力和数学机制，发掘它们的差异；（2）设计一种语义感知的交换格式，便于描述不同语言间的语义变换（交叉语义）；（3）设计一个描述混成系统的统一的描述语言并开发相应的实现和验证技术。
|
||||
|
||||
\subsection{支持共享内存模型的并发程序设计}
|
||||
由于处理器和编译器对程序的优化，大多数处理器和程序设计语言（如C++或Java）无法提供理想化的顺序一致性（sequential consistency）内存模型。近年，来对内存一致性模型的形式化定义成为研究的热点，包括对处理器（如x86、Arm、Power等）和并发程序设计语言（如C++和Java等）的内存模型的设计与实现等。然而，现有程序设计语言的内存模型仍然存在较多问题。Java和C++的内存模型仍然过于复杂，且允许程序产生违背直观的行为，特别是跟程序逻辑完全无关的行为（即所谓的out-of-thin-air行为，简写为OOTA）。因此这些内存模型还有待改进。另一方面，经典的并发验证逻辑和既有分析、测试、验证工具无法直接应用于弱内存模型程序，我们需要新的理论和工具支持。针对以上不足，我们需要解决以下问题：（1）改良现有的程序设计语言中的内存模型，避免内存模型中的OOTA行为；（2）基于改良后的内存模型，给出新型的并发程序验证、分析、测试的技术，保证弱内存模型下的并发程序编译及执行的正确性。
|
||||
|
||||
\subsection{支持最终用户编程的程序设计语言}
|
||||
最终用户程序设计主要涉及两条研究路线。一条路线是从教育的角度出发，把现有程序设计语言中的概念用更简单直观的图形化方式表达出来，使得没有学过程序设计的人也能很快熟悉和掌握。这其中的代表语言就是Scratch(Resnick, 2009)。Scratch采用类似程序流程图的方式表达顺序、选择、循环等概念，使得没有接受过计算机教育的儿童和老人也可以通过简单拖动鼠标就能完成想要的程序。目前Scratch已经广泛用于儿童教育中，用于培养儿童的计算思维。此外，一些智能家居和智能机器人设备也引入了类似的语言来进行简单的程序设计。为此，在设计此类语言的时候，需要设计一组被最终用户所能接受和使用的语言构造，并由相关支撑环境实现将用户设计的程序“编译”为可以被具体执行的程序。另一方面，这类面向最终用户的程序设计语言一般都比较简单。且最终用户在程序设计时经常出错。如何能提升此类程序设计语言的表达及容错能力，将成为一个值得研究的问题。
|
||||
|
||||
|
||||
最终用户程序设计的另一条路线是针对特定领域让用户用最自然的方式表达需求，同时用程序综合的方式来完成程序的构造。这方面的一个典型例子是Excel。Excel从2017起引入了基于样例的程序合成方法(Polozov, 2015)，该方法允许用户对于一列或一行单元格中的几个数据提供计算结果的样例，然后Excel自动根据样例推测出用户想要撰写的程序，并自动填充其它单元格数据。然而，上述基于样例的程序合成方法并不适合很多应用场景。我们需要研究更多适用于不同应用场景和不同用户级别的需求表达方式，以及将这些需求转换成程序的方法。
|
||||
|
||||
|
||||
最终用户程序设计的一个重要应用领域是应对面向人机物融合的大趋势，为最终用户提供控制网络上设备的编程方式。目前，在这个方向上已经有一些典型的应用，包括为智能家居的物联网设备编程。比如，IFTTT采用了IF语句作为基础编程单元，主要表达不同条件满足的时候设备应该采用的动作。很多主流的智能家居企业比如小米、华为都采用了这种编程模型。但目前编程模型的能力还有较大局限性，一些需求无法完全表达；同时在程序变得比较复杂的时候，基于IFTTT的编程方式也容易带来预期之外的交互，引起较难调试的问题。
|
||||
|
||||
|
||||
\subsection{程序设计框架和程序设计开发环境}
|
||||
程序设计语言与编程环境、程序设计框架、程序设计工具需要协同发展。近几十年来程序设计的努力主要体现在框架及工具等方面。例如.NET Framework里有超过一万个类及十万个方法，现有的编译器和解释器之间的界限越来越模糊。类似的，现在的IDE包含了无数强大的功能，例如语法提示，重构，调试器等。上述程序设计框架、工具等支撑着高层语言的普及和使用。因此，需要设计与开发与程序设计语言相匹配的程序设计框架和程序设计环境，支撑多范式程序设计，并集成程序搜索、推荐、自动修复等功能，以支持程序员轻易地开发出更强大的应用。
|
||||
|
||||
\subsection{特定领域语言的元编程和开发环境}
|
||||
程序设计语言方面另一个研究内容是构建支持特定领域语言的定义和实现的开发环境。这个环境需支持高效而正确地设计和实现众多的领域特定语言，抓住不同领域的计算特征，便于领域专家使用。同时，为了高效组合不同领域的计算特征，需要构建“面向语言”的程序设计环境。面向语言的程序设计明确鼓励开发人员构建自己的领域特定语言，或者将具有特定领域概念的现有语言作为方法的一部分进行扩展。利用这个环境，程序员在软件开发时不是只使用一种语言，而是使用最适合每项任务的语言，然后把它们有机组合在一起。例如，MPS (Meta Programming System) 等语言工作台是面向语言方法的重要组成部分。使用MPS，可以为任何新语言定义编辑器，使得领域特定语言的使用更简便。即使是不熟悉传统程序设计的领域专家，也可以在MPS中使用领域特定语言。
|
||||
|
||||
\subsection{程序设计语言的生态及其演化规律}
|
||||
程序设计语言的流行与发展，离不开其生态的繁荣与发展。生态，包括支撑环境、集成开发环境、扩展功能支持库、第三方功能模块、帮助文档和知识库、技术交流社区、资源下载网站、教程和培训等，提供了对程序设计语言更广泛的支持。然而，针对程序设计语言生态的研究还不多。仍需要对程序设计语言生态进行大量研究，研究如何定义/描述一个程序设计语言及其生态系统，以及研究如何将一个既有项目从一个语言生态迁移至另一个语言生态等。此外，需要分析生态系统的利益相关者及生态中蕴含的海量知识/数据等，以更好发现程序设计语言与生态、利益相关者的伴生、共同演化与发展的规律。
|
||||
|
||||
|
||||
由于工业界、研究者的努力，程序设计语言将处于持续演化中，主要演化方向是使语言变得更简单、更完善、更强大、更安全、更易学和使用。然而，仍需要进一步探索程序设计语言的演化规律，理解、分析并利用程序设计语言演化的驱动力，探索可能的演化方向，推动程序设计语言进一步发展。首先，需要归纳、总结程序设计语言中出现的、程序设计人员更主动采纳的新特性、新机制。例如，如何设计一系列“语法糖”，帮助程序设计人员更便捷地书写程序；如何从语言角度设计模板，使得模板的编写变得更简单和容易理解；如何使程序员更容易使用容器和算法，且更容易组合算法等；如何通过语言来简化异步程序的编写等。此外，程序设计语言的演化，也会导致支撑环境性能的提升。例如，利用模块以加快编译速度，利用反射以提供强大的编译期AST元数据查询能力，利用即时编译（JIT）编译器以省下了解释器的开销等等。这里，语言的演化更需要得到编程支撑环境方面的支持。
|
||||
|
||||
|
||||
\section{本章小结}
|
||||
如果说软件是社会的基础，那么程序设计语言就是软件的核心。泛在计算促使我们设计各式各样的满足某种性质的领域特定程序设计语言，研究语言随着时间和环境的改变而变化的演化和生长机制，并开发一个全新的“基于语言”的软件设计方法和支撑环境。在这一章里，我们指出了新时代程序设计语言的几个挑战性问题，有些问题并不是新的，但是它们被赋予新的内涵。作为参考，我们也列出了一些重要的研究内容，希望能够通过这些具体研究来迎接这些挑战。
|
||||
|
||||
\section{参考文献}
|
||||
[1] Kreutz D, Ramos F M V, Esteves Verissimo P, et al. Software-Defined Networking: A Comprehensive Survey. Proceedings of the IEEE, 2014, 103(1):10-13.
|
||||
|
||||
|
||||
[2] Thereska, E., Ballani, H., O'Shea, G., Karagiannis, T., Rowstron, A., Talpey, T., ... \& Zhu, T. (2013, November). IOFlow: a software-defined storage architecture. Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles (pp. 182-196). ACM.
|
||||
|
||||
|
||||
[3] Ouyang J, Chu C W, Szmanda C R, et al. Programmable polymer thin film and non-volatile memory device[J]. Nature materials, 2004, 3(12): 918
|
||||
|
||||
|
||||
[4] Jain S, Kumar A, Mandal S, et al. B4: Experience with a globally-deployed software defined WAN. ACM SIGCOMM Computer Communication Review. ACM, 2013, 43(4): 3-14.
|
||||
|
||||
|
||||
[5] McKeown N, Anderson T, Balakrishnan H, et al. OpenFlow: enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 2008, 38(2): 69-74.
|
||||
|
||||
|
||||
[6] Czarnecki K, Foster J N, Hu Z, et al. Bidirectional transformations: A cross-discipline perspective. International Conference on Theory and Practice of Model Transformations. Springer, Berlin, Heidelberg, 2009: 260-283.
|
||||
|
||||
|
||||
[7] Shvachko K, Kuang H, Radia S, et al. The hadoop distributed file system，MSST. 2010, 10: 1-10.
|
||||
|
||||
|
||||
[8] Hu Z, Hughes J, Wang M. How functional programming mattered, National Science Review, Oxford Journal, 2015, 2(3):349-270.
|
||||
|
||||
|
||||
[9] Zaharia M, Chowdhury M, Franklin M J, et al. Spark: Cluster computing with working sets. HotCloud, 2010, 10(10-10): 95.
|
||||
|
||||
|
||||
[10] Kyrola A, Blelloch G, Guestrin C. GraphChi: Large-Scale Graph Computation on Just a PC, Presented as part of the 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI 12). 2012: 31-46.
|
||||
|
||||
|
||||
[11] Abadi M, Barham P, Chen J, et al. Tensorflow: A system for large-scale machine learning, 12th USENIX
|
||||
Symposium on Operating Systems Design and Implementation (OSDI 16). 2016: 265-283.
|
||||
|
||||
|
||||
[12] Paszke A, Gross S, Chintala S, et al. Automatic differentiation in pytorch. 2017.
|
||||
|
||||
|
||||
[13] Carpenter B, Gelman A, Hoffman M D, et al. Stan: A probabilistic programming language. Journal of statistical software, 2017, 76(1).
|
||||
|
||||
|
||||
[14] Patil A, Huard D, Fonnesbeck C J. PyMC: Bayesian stochastic modelling in Python. Journal of statistical software, 2010, 35(4): 1.
|
||||
|
||||
|
||||
[15] Anderson C J, Foster N, Guha A, et al. NetKAT: Semantic foundations for networks. Acm sigplan notices, 2014, 49(1): 113-126.
|
||||
|
||||
|
||||
[16] Bosshart P, Daly D, Gibb G, et al. P4: Programming protocol-independent packet processors. ACM SIGCOMM Computer Communication Review, 2014, 44(3): 87-95.
|
||||
|
||||
|
||||
[17] Resnick M, Maloney J, Monroy-Hernández A, et al. Scratch: Programming for all. Commun. ACM, 2009, 52(11): 60-67.
|
||||
|
||||
|
||||
[18] Polozov O, Gulwani S. FlashMeta: A framework for inductive program synthesis. ACM SIGPLAN Notices. ACM, 2015, 50(10): 107-126.
|
||||
|
||||
|
||||
[19] Yuting Chen, Ting Su, Chengnian Sun, Zhendong Su, Jianjun Zhao: Coverage-directed differential testing of JVM implementations. PLDI 2016: 85-99
|
||||
|
||||
|
||||
[20] Junjie Wang, Bihuan Chen, Lei Wei, Yang Liu: Skyfire: Data-Driven Seed Generation for Fuzzing. IEEE Symposium on Security and Privacy 2017: 579-594
|
||||
|
||||
|
||||
[21] Xuejun Yang, Yang Chen, Eric Eide, John Regehr: Finding and understanding bugs in C compilers. PLDI 2011: 283-294
|
||||
|
||||
|
||||
[22] Vu Le, Mehrdad Afshari, Zhendong Su: Compiler validation via equivalence modulo inputs. PLDI 2014: 216-226
|
||||
|
||||
|
||||
[23] Junjie Chen, Yanwei Bai, Dan Hao, Yingfei Xiong, Hongyu Zhang, Bing Xie: Learning to prioritize test programs for compiler testing. ICSE 2017: 700-711
|
||||
|
||||
|
||||
[24] Rody Kersten, Kasper Søe Luckow, Corina S. Pasareanu: POSTER: AFL-based Fuzzing for Java with Kelinci. ACM Conference on Computer and Communications Security 2017: 2511-2513
|
||||
|
||||
|
||||
[25] Zeyu Sun, Qihao Zhu, Lili Mou, Yingfei Xiong, Ge Li, Lu Zhang: A Grammar-Based Structural CNN Decoder for Code Generation. CoRR abs/1811.06837 (2018)
|
||||
|
||||
|
||||
[26] Sam Blackshear, Evan Cheng, David L. Dill, Victor Gao, Ben Maurer, Todd Nowacki, Alistair Pott, Shaz Qadeer, Rain, Dario Russi, Stephane Sezer, Tim Zakian, Runtian Zhou: Move: A Language With Programmable Resources. https://developers.libra.org/docs/assets/papers/libra-move-a-language-with-programmable-resources.pdf (2019)
|
||||
|
|
@ -0,0 +1,173 @@
|
|||
|
||||
软件开发方法与技术是软件学科的核心关注点之一，从宏观上看，其目标一方面是在计算平台上给出满足用户需求的解决方案，另一方面是达到开发效率、质量、成本的最佳平衡。在通常的软件及信息技术体系中，软件开发包括了技术、管理、工具等多个方面：技术上包括软件分析、设计、构造、维护和质量保证，关注于如何完成具体的软件开发活动并产出相应的软件制品；管理上包括软件过程模型、开发团队组织和最佳实践，关注于软件开发活动的流程和协作管理以及包括人在内的各类资源的组织和运筹等；不论是技术还是管理方面，在解决大规模复杂软件开发问题时都离不开工具的支持和帮助。高效、高质量、低成本地开发和演化软件系统是软件开发方法和技术研究追求的总体目标，在这个总体目标指引下，在不断出现的、新的应用需求的牵引下，软件开发方法和技术研究不断面临新的挑战。
|
||||
|
||||
|
||||
在“软件定义一切”的时代背景下，尽管软件开发方法与技术的目标宏观上依然不变，但是软件的需求空间被进一步大幅度扩展，人机物融合的需求场景和运行环境更进一步增大了软件系统的规模和复杂性，导致软件开发和演化的成本随之急剧上升，从而产生了对软件自动化方法与技术的迫切需求；另一方面，软件开发和演化的外在条件随着需求和技术发展不断发生变化，新的问题不断涌现，不断扩展了软件自动化方法和技术的研究空间。
|
||||
|
||||
|
||||
人是软件开发成败的决定因素，认知空间中人们长期的积累与计算平台的发展，使得软件开发的社会化和智能化成为必然方向，也为软件开发中人与计算/机器平台的新型关系的建立提出了挑战。网络化、数据化、可视化、虚拟化将改变人在软件开发中的工作方式、合作方式和组织方式，催生出软件开发的各种新方式，包括软件开发终端化和普及化、群智化开发与生态化平台等等。建立新的开发方式以有效适应人机融合的软件生态发展，将是软件开发和平台的未来机遇。
|
||||
|
||||
|
||||
软件作为智力和人工制品，软件开发属于认知空间范畴，介于应用空间（问题空间）与平台空间（解空间）之间。应用空间和平台空间的泛在化和持续变化决定了未来软件形态的泛在性、适应性、演化性。复杂多样的不确定性成为软件的固有本质特征，控制而不是消除不确定性使得软件的持续演化和成长成为必然挑战。与传统软件开发相比较，软件的不确定性控制和处理难以在设计时完成，除了面向应用空间，软件开发的设计时与运行时融合要求认知空间与平台空间的协作乃至一体化成为一个趋势。近来的开发运维一体化已经有了一个良好的开端。
|
||||
|
||||
|
||||
面向动态变化场景的人机物融合复杂系统，软件开发面临的首要挑战是融合人机物三元资源、以建模为核心的软件定义方法和技术。我们需要构建人机物三元资源及其行为的抽象、观察和度量的新模型和方法，研究基于软件定义方法的元级控制和数据赋能机理，使得软件开发方式（包括设计、构造和保证）从实体建模为主走向实体加链接，从分而治之走向群智聚合，从而有效驾驭各类软件复杂性。
|
||||
|
||||
\section{重大挑战问题}
|
||||
在人机物融合应用场景需求牵引下，软件开发方法和技术研究面临的重大挑战问题主要包括复杂场景分析与建模（§4.1.1）、群智开发（§4.1.2）、人机协作编程（§4.1.3）和开发运维一体化（§4.1.4）。
|
||||
|
||||
\subsection{复杂场景分析与建模}
|
||||
人机物融合计算场景的需求在我们的日常生活中已经存在，大到智慧国家、智慧城市，小到网络家电、汽车引擎智能网络控制系统，对这类计算场景的分析和建模存在许多挑战，其中最重要的挑战包括如下四个方面。
|
||||
|
||||
|
||||
（1）与日俱增的规模与复杂度
|
||||
|
||||
|
||||
从已经出现的支撑人机物融合计算场景的系统来看，其系统的大小和复杂性显著增加。例如，现代汽车中基于软件的功能在不断地持续增加[1]，比如，2007年经典高端轿车包含大约270个与驾驶员互动的软件实现的功能，而最新的高端轿车包含超过500个这样的功能。轿车软件的规模也在大幅增长。2007年高端轿车的二进制代码量约为66兆字节，而现在这类轿车则含超过1千兆字节的二进制代码。随着软件支持的功能的数量和规模的增加，复杂性也随之增加。这些基于软件的功能要求各个组件子系统，例如刹车系统、发动机管理系统、驾驶辅助系统等，具备更细粒度的功能，以及子系统之间密集的交互，因而整个系统的复杂性大大增加，对系统的分析和建模需要从方法和技术上得到全面提升。
|
||||
|
||||
|
||||
除了功能数量和规模的提升，对软件分析和建模方法的挑战还来自于软件与硬件、软件与人的交互的紧密性和持续性。首先，软硬件协同分析和建模成为必须，这类系统的发展大部分是由先进硬件技术的改进而驱动的，集成电路的成本、尺寸和能耗的显著降低以及基于新原理的计算元件的可用都是技术改进的例子。这种改进使得软件有可能控制设备，而且在经济上也成为可行。另一方面，软件在硬件设备中的广泛集成又为许多设备提供了更加新颖的功能，例如家用电器的网络连接，集成了数万到数千个内核的多核处理器的单个芯片的开发，意味着即使是单芯片系统也必须被视为由大量单个节点组成。这种趋势和挑战要求采用系统的方法来设计具有大量计算节点的大型网络化系统。通过网络将数亿或者数十亿个物理设备、智能设备连接起来，这些数量庞大的智能设备进行实时数据采集和彼此之间信息交互，形成了复杂的网络，产生了大量的数据，这些数据呈指数级增长。这些数据的处理促进了新软件的诞生，系统规模日益增大。这描绘了一个物理世界被广泛嵌入各种感知与控制智能设备后的场景，在这个场景下能够全面地感知环境信息，智能地为人类提供各种便捷的服务。
|
||||
|
||||
|
||||
其次，将人的行为分析和建模纳入到系统分析和建模的范畴中也成为必须。在这些人机物融合计算场景中，人的日常生活和这些大型网络化系统将紧密地联系在一起，比如，目前，全球已经大约30亿人连入互联网，每个人都在智能终端、个人电脑上使用各种各样的软件，发微博、发微信、全球每天会有2.88万小时的视频上传到Youtube，会有5000万条信息上传到Twitter，会在亚马逊产生630万笔订单，…。这些数据都是由人和系统的持续交互产生的结果，人的行为和意图将成为系统分析和建模的重要关注点。
|
||||
|
||||
|
||||
（2）开放和不确定环境
|
||||
|
||||
|
||||
在传统软件分析和建模方法中，通常假设软件的工作环境就是当前设计的环境。与其不同，在人机物融合计算场景中，软件系统将运行在开放和不确定环境中。例如，在未来的大规模无处不在的城市计算系统中，系统将能获取到大量的异构数据，这些异构数据由城市空间中的各种数据源和数据采集器（如传感器、设备、车辆、建筑物和人类等）产生，需要集成到软件系统中进行统一分析，并在收集的数据上构建许多有趣的应用。例如，通过气象传感器收集温度、湿度和风向等信息后，软件系统可以预测热岛效应并给出应对措施。软件系统还可以帮助维护旧的高速公路或道路，并通过部署在旧建筑中的传感器检测旧建筑的安全参数，预测危险。软件系统还可以通过感知人类的生命体征，帮助提供紧急医疗服务和监测慢性病。在所有这些人机物融合计算场景下，软件的交互环境都是动态的，并且可以观察到其不确定性。
|
||||
|
||||
|
||||
有很多证据表明，在人机物融合计算场景中，软件的交互环境也是开放的。例如，许多移动电话、掌上电脑、个人电脑甚至是配备RFID的商品都通过不同规模的网络联网，它们可以自主的动态加入或者移除。可用设备的不断更新，又促使服务提供商提供新服务或删除不再有校或已被取代的服务，更换不再提供类似功能的其他服务，利用网络环境提供新的服务，而这些更新后的服务是软件系统设计时不可能预见到的。因此，建立在不断变化的服务空间上的人机物融合系统的环境永远不会是封闭的，而是开放的，所以需要从方法学和技术层面支撑分析和建模能容忍环境的开放性、变化性和不确定性。
|
||||
|
||||
|
||||
（3）情境感知和适应性
|
||||
|
||||
|
||||
除了复杂度和不确定性带来的挑战之外，人机物融合计算场景中，对软件系统的分析和建模还受到来自由于新算法新技术引入的系统能力的挑战。例如，目前可以看到的，手机与全球定位系统位置设备耦合的电子导航系统，以及执行从交通冲突检测到自动间隔和车道跟踪任务的自动装置，正在被辅助驾驶软件系统采用，这些新的能力使软件系统更加深入地嵌入到可变和开放的环境中，也使系统能够了解系统周围的整体情况，从而做出更好的在线决策。新技术和新能力的引入使得软件系统常常要在与其设计时明显不同的条件下运行。
|
||||
|
||||
|
||||
在执行时，软件系统它们不仅应该能够适应各种交互和运行环境（比如，网络环境）的变化，还应该能够在遇到变化时继续可靠地执行。未来的人机物融合计算场景中，软件系统将更普遍、更分散，并且在其运行期间将需要更广泛的适应性。交互和运行情境的动态变化（事物在环境中变化的程度和速度）是一个重要特征。软件系统的分析和建模需要考虑在线决策的能力。在人机物融合复杂计算场景下进行动态决策，所要求的绝不仅仅是简单地认识环境状态，具备良好的情境意识，整合对情境的理解，它高度依赖于情境感知能力，支持对环境状态的不断演变的认识。
|
||||
|
||||
|
||||
（4）创新使能的需求模糊性
|
||||
|
||||
|
||||
人机物融合计算场景下，软件系统分析和建模的困难还来自于当前的需求相关者（即领域专家，最终用户和客户）无法提供完整和正确的能力要求。可以看到，许多创新应用，一些最受欢迎的应用程序，如微信、在线购物等，都是由技术的发展和产品设计师的创新思维驱动的，而不是最初的需求相关者所要求的。信息技术飞速发展的时代，领域专家和最终用户无法提出超出想象范围的技术发展，他们不了解现有技术的发展趋势，在软件系统分析和建模方法中支持未来创新需求的引入或提供对创新需求的包容手段是一个重要的挑战。
|
||||
|
||||
\subsection{群智开发}
|
||||
互联网技术的发展，使得人类群体打破物理时空限制开展大规模协作成为可能，新型编程技术包括新型高级编程语言、智能化编程工具和技术的出现则降低了编程开发的参与门槛，软件开发活动从一个纯粹的生产性活动转变为一个涉及到多种要素紧密关联的社会性活动，软件也从相对独立的产品转变为多种元素相互依赖持续演化的生态。在软件生态系统中，作为软件开发活动中的关键要素，人在其中的角色发生了显著变化：参与者规模的变化，软件开发活动的参与者规模由过去的公司/组织内部封闭环境下的数百数千人转变为软件生态系统中通过互联网联接的开放环境的数万数十万人；参与者类型的变化，软件开发活动的参与者由过去的主要是开发者转变为软件生态系统中开发者、用户、管理者、投资人等多种不同类型的个体深度参与，共同驱动软件生态系统的发展演化；参与者角色的变化，每个软件开发活动的参与个体的角色从单纯的软件开发者或使用者等单一角色演变为软件生态系统的参与者和推动者等多重角色，每个参与个体都成为软件生态中的组成部分同软件生态共同成长演化。
|
||||
|
||||
|
||||
群智开发是一种通过互联网联接和汇聚大规模群体智能实现高效率高质量的群体化软件开发方法，主要包括微观个体的激发、宏观群体的协作、全局群智的汇聚以及持续的成长演化等不同的维度。在生态观下，软件开发的关注点从“人在系统外”的软件系统构建发展为“人在回路”的软件生态构建。开源软件、软件众包以及应用市场等快速发展，显示出超越传统软件开发的生产力，展现了群智开发所蕴含的巨大潜力。但是，如何高效激发和稳态汇聚大规模群体智能，确保群智智能在软件开发活动中可控形成和重复出现，构建持续健康演化的软件生态，是群智开发面临的核心挑战。
|
||||
|
||||
|
||||
（1）自主个体的持续激发和大规模群体的高效协作
|
||||
|
||||
|
||||
互联网技术的快速发展，打破了传统软件开发面临的时间和空间的局限，为大规模群体的联接和协作提供了坚实基础。在开源、众包和应用市场中，采用社区声誉、物质回报等多种机制来激励群体参与，并采用合作、竞争和对抗等模式开展群体协作，取得了一定的进展。但是，在互联网环境下的群智开发中，参与的每个个体都具有高度的行为自主性和不可预测性，基于人类群体智能的软件开发不仅仅是一种技术问题，而是一个涵盖心理、社会、经济等多种属性交织作用的复杂问题，如何有效激发每一个参与个体持续高质量贡献？另一方面，大规模多样化群体的开放参与带来巨大的沟通交互开销，如何有效组织大规模参与群体开展高效协作共同完成复杂软件开发任务，是群智开发面临的一大挑战。
|
||||
|
||||
|
||||
（2） 群智任务的度量分解与群智贡献的汇聚融合
|
||||
|
||||
|
||||
软件开发本身是一项创作与生产深度融合的活动，具有很强的开放性和灵活性。在面对一个具有更强不确定性和差异性的大规模群体时，如何将一个复杂的软件开发任务分解成一组简单任务，并建立起开发任务与参与个体的最优适配，实现个体智能的最大释放？此外，开放参与下的软件开发具有群体贡献碎片化、群智结果不可预期性等特点，如何量化度量群智贡献的质量和价值、构建有效的群智贡献迭代精化闭环、实现多源碎片化群智贡献的可信传播与汇聚收敛，形成高效群智涌现？
|
||||
|
||||
|
||||
（3）群智开发生态的认知度量和成长演化
|
||||
|
||||
|
||||
在群智开发中，参与者群体、代码与社区等多样要素共同形成一个持续发展的生态，在个体激发和群智融合基础上，通过评估和反馈推动生态持续成长演化。在此环境下，软件开发关注点不再仅仅是孤立的、静止的参与者个体或者代码，更需要从“联系”的、“发展”的视角去分析和认识整个群智生态。面临以下两个方面的挑战：一是如何认知和计算软件开发中的群智。群智激发和汇聚是形成群智开发生态的关键，如何深入理解和认识群智激发汇聚和本质，并从激发和汇聚的角度建立群体智能的效能评估方法和评测指标，从而为群智开发的成长演化提供评价准则和度量体系？二是如何推动群智生态的持续成长演化。群智生态中各个要素相互依赖紧密交互，如何建立多元高效的主动反馈机制，在基于群智度量体系对群智过程开展量化度量的基础上对参与群体进行实时反馈和持续引导，驱动群智生态的正向演化？
|
||||
|
||||
\subsection{人机协作编程}
|
||||
在现有的软件开发活动中，几乎每一行程序（高级语言编写的代码）都需要人类程序员手工编写，随着对软件的需求进一步地增长，以及软件复杂度进一步地提升，这种几乎全手工的编程方式将成为制约计算机行业发展的瓶颈。只有大幅度提升机器编程的占比，并将程序员的主要工作更多地放在少数对创造性具有极高要求的活动上，才能够突破这一瓶颈。因此，需要将程序员统领开发环境完成编程任务的模式转变为程序员与机器各司其职又相互协作完成编程任务的模式。实现人机协作编程的挑战主要来自两个方面：1、如何提升机器编程的能力；2、如何实现人机无障碍协作。
|
||||
|
||||
|
||||
提升机器编程的能力是实现人机协作编程的基础，软件自动化是提升机器编程能力的主要技术手段。人们对软件自动化的探索几乎是伴随着软件的出现而开始的，由于早期的软件开发（编程）是异常繁琐易错的工作，人们很早就开始考虑将编程中机械性的工作交给机器完成。然而，软件自动化也一直没有完全达到人们的期望，导致软件开发长期属于严重依赖开发人员个人能力的活动。传统的软件自动化技术以严格的规约作为输入，通过机器将规约翻译成程序代码或者通过搜索技术找到符合规约的程序代码：前者的典型代表是编译器，也是软件自动化方面到目前为止最为成功的尝试，但随着抽象层次的提高，人们发现很难通过固定的规则完成所有可能的翻译；后者的典型代表是程序合成，但由于程序空间过于庞大，目前能够通过搜索获得程序通常仅限于规模很小的程序。近年来，随着数据的广泛积累，数据驱动的方式在很多领域取得了前所未有的成功，类似地，长期累积的海量代码数据为软件自动化带来了新的可能性，为提升机器编程能力带来了新的希望。数据驱动的软件自动化可以利用已有代码数据中总结出来的规律指导搜索，从而提升程序合成的效率，同时这种不依赖严格推理的模式又易于处理半形式化甚至非形式化的规约，从而扩大软件自动化技术的适用范围。由于程序空间是无限空间，已有程序代码在整个空间里仍然很稀疏，而程序代码又受到问题领域、技术进步、开发者习惯的影响展现出很强的异质性，如何从已有程序代码总结规律存在巨大的挑战。
|
||||
|
||||
|
||||
与人工编程相比，机器编程的优势在于机器编程可以利用计算机的强大计算能力，劣势在于机器编程主要从已有代码中学习，缺乏有效处理边角信息的能力，因此高效的人机协作将能更好地发挥两者的优势。支持高效人机互动的开发环境一直是软件工程关注的重点之一，最早的开发环境只是一系列工具的简单堆叠，真正意义上的开发环境是在上世纪八十年代以后发展起来的，这类开发环境的主要特点在于，开发者是整个开发环境的主导，开发环境是开发者的操控台和延伸，进入到新世纪开发环境有两个新的发展趋势：1、开发环境中开始出现一些智能服务（如代码推荐等），虽然能够进入主流开发环境的智能服务仍十分有限，但学术界研究的智能工具多以开发环境的插件形式展现；2、开发环境开始支持开发者间的交互，虽然这与开发者间远程协作需求的增长有关（短程协作中开发者可以进行面对面的交流），但却为探索多开发者协同提供了有益尝试。为了满足人机协作编程的需要，开发环境需要应对以下两方面的挑战：1、建立开发者对机器编程的信任关系：在开发者主导的环境中开发者更多依赖自己的主观判断，但在人机协作环境中开发者完全可控的范围缩小将更依赖机器编程，如果开发者不能确信机器编程能否完成特定任务，就会严重影响开发效率；2、实现人机多渠道交互：现有开发环境中的人机交互以及开发者间的交互方式主要以文本方式进行，而人类通常习惯同时以多种方式进行交流，这样才能更好激发开发者的创造力。
|
||||
|
||||
\subsection{开发运维一体化}
|
||||
软件开发是人类的一项高复杂度的集体智力活动，其现实问题的复杂度反映到开发中主要表现为架构、过程、技术和组织四个维度上的复杂度，它们往往紧密地交织纠缠在一起并相互转化。软件工程在这四个维度上发展趋势，即架构逐渐去中心化，技术趋于平台化、自动化和虚拟化，过程趋于增量和迭代，组织趋于小而自治，开发运维一体化（DevOps）集中体现了这些发展趋势的高阶形态。随着互联网化和服务化的高度发展和走向成熟使得未来的软件更加需要具备持续（continuous）的特征。这种持续性将覆盖从商业策划、开发到运维以及演化的所有环节，使得未来软件系统像具有生命一般：在持续稳定提供服务的同时，软件系统的边界、发展走向等不再固化，而是始终处在不断变化和适应之中。持续性与上述的架构、过程、技术与组织四个维度的复杂性交织在一起，再叠加性能、安全等质量要求和实效性要求等，使得未来的软件系统的开发和运维面临诸多的挑战，这就需要我们在原则、方法、实践以及工具层面都做要充分的应对。
|
||||
|
||||
|
||||
（1） 构建按需（On-Demand）的基础设施
|
||||
|
||||
|
||||
作为DevOps产生的技术和平台基础，基础设施(Infrastructure)可能是未来DevOps能够发挥更大作用的关键环节。然而，如何匹配软件系统运行需求（或者企业需求）来构建适用的基础设施一直是需要重点关注的话题。值得关注的几个挑战包括：1）混合云，即为了更好的适应各种业务场景，混合云是一种合理的选择，但是由此带来的异构、安全、可扩展等方面的挑战不容忽视；2）边缘计算，即为了尽可能减少数据传输代价，就近提供计算服务是一种选择，但是，这会大大增加基础设施的复杂程度，带来软件系统部署和维护方面的巨大挑战。此外，支持Serverless架构的基础设施、内建安全的基础设施、RPA（Robotic Process Automation，机器人流程自动化）等等也都是未来支撑DevOps发展的IT基础设施相关的研究和实践热点。
|
||||
|
||||
|
||||
（2） 搭建智能化流水线
|
||||
|
||||
|
||||
DevOps 持续高效高质量的交付有赖于高度自动化支持工具的支持，自动化也是获得快速反馈的关键。鉴于DevOps自动化支持工具涉及多个阶段，种类繁多，数量上已达数千种，从诸多关系复杂的工具中理解和选择合适的工具集合来搭建流水线对 DevOps 实践者来讲至关重要，但也非常具有挑战性。未来，部分重要的基础性工具将向少数较成熟的工具收敛（如在持续构建、自动化部署、服务治理等方面），但是，更多的DevOps的自动化支持工具将向更加专业化发展。即构建的流水线往往面向特定应用领域（例如金融行业对安全性和合规性有着极高要求）或包含其他专业组建（例如，人工智能、大数据等），因而，如果提供开箱即用的工具链方案，帮助企业选择并定制适合其业务的DevOps工具链是一个巨大的挑战。此外，随着软件项目的持续进展，DevOps流水线会产生大量的数据，例如，工具链自身产生的数据，在研软件系统在验证过程中产生的数据以及DevOps项目执行产生的数据等等。如何从流程与数据两个维度打通，提供以DevOps流水线为基础的开发运维一体化协作平台，进而提升其智能化水平，再次基础上提升DevOps实践的效率和质量，同样也是为了支持前文所述的持续性，从工具链和生产环境角度需要需要解决的重大挑战之一。
|
||||
|
||||
|
||||
（3） 探索可用的微服务化架构演化策略和评估手段
|
||||
|
||||
|
||||
微服务化是支持前文提及的软件系统持续性要求的必备条件。软件系统的微服务化要求软件系统的各个模块或服务间耦合进一步降低，从而在新版本发布和出现问题时不会影响到系统其它部分。企业系统架构向微服务架构演化以更好地支持DevOps已成为行业共识和趋势，然而在演化过程中却面临诸多挑战。首先，合理的服务划分，即将软件系统拆分成多个独立自治且协同合作的服务，是微服务应用实现敏捷、灵活和高可扩展的先决条件，也是微服务领域的一项严峻挑战。其次，虽然服务拆分为测试带来诸多便利，但在另一方面，服务数量的增加也带来了测试复杂度的指数增长。当采用微服务架构之后，系统对远程依赖项的依赖较多，而对进程内组件的依赖较少，因此测试策略和测试环境需要适应这种变化。微服务系统不仅需要保证组件内部的正确性，还需要通过契约测试等保证组件间通信和交互的正确性，使得众多微服务能够真正实现协同工作。相应地，微服务联调、日志分析与故障定位、自动化监控告警与治理策略等是当前以及未来较长时间内的研究中需要探索的迫切问题。此外，微服务架构并不一定适合所有的企业情况，因此，建立微服务架构行之有效的评估和决策支持方法，如在演化过程中，应该通过哪些角度去判断架构拆分的效果？这些角度与业务需求之间的对应关系？如何度量微服务拆分效果并及时给出建议（包括补充替代的架构形式）等都存在若干亟需解决的问题。
|
||||
|
||||
|
||||
（4） DevOps高频交付带来的质量和安全问题
|
||||
|
||||
|
||||
质量和安全一直都不是新问题，但是在当前以及未来，都是DevOps用以支撑未来软件系统开发和运维应当重点关注的点。在DevOps语境下，在高水平自动化支持下的快速高频交付是维系持续性的基础，但同时也使得传统的质量和安全问题都有了新的内容。例如，通过各类工具来实现自动化V\&V是DevOps实践中的不二选择。然而，现有工具在发现并且消除缺陷和隐患的效率和效能方便并不能如意。大量研究和实践表明，DevOps和Security合规往往在实践中具体天然的对立，这种对立不是通过“构造”DevSecOps一个词汇能解决的。如何协调上述的对立是一个棘手问题。其次，现代软件系统的缺陷（vulnerability）往往有多种来源和根本原因，例如来自上述基础设施的安全威胁、DevOps的快节奏所导致的各种妥协、质量缺陷、大量第三方组件的安全威胁、自动化运维中的安全隐患、企业文化（流程、人员技能和意识等）导致的安全疏漏等等。所谓百密一疏，尽管有一些工具、方法以及实践可以一定程度上缓解上述各种威胁带来的压力，但显然在效果和效率方面还有一些不足。从这个意义上述，退而求其次的方式是采取事后方式——通过监控系统运行过程尤其是通过分析系统异常来辅助发现安全风险。但是，这种方式还是有两大急需解决的难题，即如何产生可靠的高质量运行相关的数据（例如日志信息）以及如何应用先进的技术（例如大数据、AI技术等）提升对数据的利用效率和分析数据发现质量和安全性风险的能力。
|
||||
|
||||
|
||||
（5） 智能化运维
|
||||
|
||||
|
||||
作为DevOps中的Ops一端，运维的重要性越来越突显。工业界目前已经开始实践智能化运维（AIOps）技术以有效降低运维成本、提高运维效率和质量。随着各类AI技术和方法的迅速发展，智能化运维尽管已经有了较为坚实的基础，但是其有效实施却直接依赖于软件系统或者服务的运行时产生的各类信息的质量。目前智能化运维主要是提供一些相对简单的标准化日志信息的捕获、分析和决策，主要只关注在运维侧，在现阶段尚未有效形成运维-开发的反馈闭环，以支持开发高效应对运维变化。此外，智能化运维依赖的各类数据都有缺点：日志数据的产生主要依赖程序员的个人经验，实践中往往日志质量很差，难以支持对软件行为的有效捕获；指标数据则是一种隔靴搔痒的环境数据；跟踪路径数据会在瞬间产生巨量数据，导致完全无法分析。因此，如何充分使用这三类数据，在更加精细的力度上捕获软件应用或者服务的行为，进而提供更加准确的信息供分析，这是智能化运维需要解决的关键问题。
|
||||
|
||||
|
||||
（6） 支撑DevOps规模化的组织与管理
|
||||
|
||||
|
||||
DevOps整合了开发团队与运维团队，使其成为一个整体，这使得团队的组织、文化和软件过程都与单纯的开发团队和运维团队有所不同。同时，团队的规模也不可避免的有所增加，降低了团队面对面沟通的效率。DevOps是受到敏捷软件开发的影响而产生的，天然带有敏捷基因并植根于精益思想。然而，敏捷方法的很多理念和实践并不能天然应用于DevOps。例如，常规敏捷方式鼓励着眼当前问题同时通过承担一定程度的技术负债来应对未来的多种可能变化。这种寻求局部最优解的思维方式并不利于打破各个部门之间的壁垒。又如，在敏捷宣言鼓励之下的“重代码轻文档”方式在高频交付中也会面临挑战，等等。另一方面，随着开发和维护的软件系统越来越复杂，规模也越来越大，开发运维团队合并后，必然要求团队规模也相应扩大。一个DevOps团队由于包含了运维人员，安全团队等，整体人员规模会更大，工作和交流更加复杂。敏捷社区提出了SAFe（Scaled Agile Framework来支持更大规模的团队，目前已经列入DevOps相关内容。然而，也有很多人批评SAFe过于复杂，违背了敏捷的基本价值观。从这个意义上说，如何在大规模团队中实施DevOps仍将成为未来一段时间研究者和实践者需要解决的问题。
|
||||
|
||||
\section{主要研究内容}
|
||||
面向高效、高质量、低成本开发和演化软件系统的总体目标，软件开发方法和技术的研究范围涵盖新型程序设计与软件方法学、软件自动化技术、软件复用技术、软件自适应与生长技术、复杂软件分析与建模、智能软件开发方法、嵌入式软件开发方法与技术、复杂系统需求分析方法与技术、软件服务化方法与技术等各个方面。结合应对以上重大挑战问题，主要研究内容将集中在人机物融合场景建模（§4.2.1）、系统自适应需求分析（§4.2.2）、系统内生安全规约获取（§4.2.3）、群智软件生态（§4.2.4）、群智开发方法（§4.2.5）、群智协同演化（§4.2.6）、群智软件支撑环境（§4.2.7）、面向机器编程的代码生成（§4.2.8）、面向人机协同的智能开发环境（§4.2.9）、开发过程建模与优化（§4.2.10）、软件系统运行数据管理（§4.2.11）、安全可信的开发运维一体化（§4.2.12）、开发运维一体化的组织与管理（§4.2.13）、微服务软件架构（§4.2.14）等。
|
||||
|
||||
\subsection{人机物融合场景建模}
|
||||
人机物融合的新型泛在系统，以实现人类社会、信息空间和物理世界的互联互通为目标。在这种应用场景中，计算资源高度泛化，系统能力拓展到包括连接、计算、控制、认知、协同和重构等在内的网络化、协同式和适应性的认知、计算和控制一体的综合能力范畴。需要研究人机物融合的计算环境的认知和建模，特别是对各种实现感知、计算、通信、执行、服务等能力的异构资源的认知的建模；系统研究交互环境的建模理论，包括交互环境静态属性特征和动态行为特征，以及行为约束等多个方面；需要对典型人机物融合场景下泛在应用的本质特征，分别予以有效的场景抽象，研究相应的软件定义方法，以凝练人机物融合应用场景的共性，更有效地管理资源，并适应动态多变的应用场景。
|
||||
|
||||
\subsection{系统自适应需求分析}
|
||||
人机物融合应用场景下，需求以及交互环境的动态变化性和不确定性，使得系统的自适应性成为关键，软件系统的自适应性需求建模和管理成为热点研究课题，其中包括自适应需求的获取，自适应系统的建模，需求、系统模型和交互环境的在线检测和分析，系统能力在线规划和管理等。针对系统环境的开放性、动态变化性和不确定性等，需要对系统及其交互环境在建模和模型管理方面进行综合型研究，在系统环境建模方法，环境现象感知方法，环境事件推理技术，模型的追踪关系和基于追踪关系的协同演化策略，运行时目标驱动的在线优化和系统功能重配置方法，以及系统自适应性机制的度量和评估方法等方面进行深入研究。
|
||||
|
||||
\subsection{系统内生安全规约获取}
|
||||
人机物融合应用场景下，安全作为第一要务是不容置疑的，一方面需要保护人生安全，另一方面需要避免损失，避免破坏环境，安全防护，这些已成为系统强制执行的法律。系统内生安全的实现存在两个阶段，第一阶段是安全特征的构造，安全特性不同与系统的其它功能，需要研究：基于显式环境建模安全关注点分析，支持对安全隐患/环境风险/不合规问题等的识别；研究对系统运行时的时空间协同建模，支持混合的行为建模和认知建模以及人类行为模拟，支持从环境行为模型中发现隐含的风险隐患；研究离散模型和连续模型的融合方法，支持一体化系统验证，以及人在环路中/上系统，以及支持协作和共享的控制器综合。第二阶段是建立内置的安全规约，研究对系统级内置隐私保护和安全控制能力抽象，支持安全能力成为系统可管理的资源，研究面向应用场景的可定义的安全能力配置，系统功能和隐私/安全约束的协调，个性化、可动态配置的隐私/安全约束，以及可追溯可审计的隐私保护/安全控制。
|
||||
|
||||
\subsection{群智软件生态}
|
||||
在群智开发中，参与者群体、开发环境、软件任务、软件制品等多种要素相互作用，是持久驱动软件生产力发展的重要引擎。然而，由于软件的复杂性持续增长、开发过程的开放性持续加大，软件生态的形成与演变具有很强的随机性，未能形成有效的生态构建机理与方法。为此需要重点研究：1）基于博弈论和社会经济学等理论研究开源生态形成与演化的动力学模型，形成“贡献激发、群智汇聚、人才涌现”的良性循环；2）研究面向软件生态的多模态持续激励机制，突破基于区块链等新型技术的群智激励方法；3）研究软件生态的大规模混源代码溯源技术和演化分析方法，突破软件开发供应链的分析识别技术，建立全谱系的群智软件生态供应链模型。通过上述研究，为软件生态构建和演化提供理论指导。
|
||||
|
||||
\subsection{群智开发方法}
|
||||
在动态开放环境下，参与群体的高自主性、任务目标的高变化性，带来群智涌现的不确定性，严重制约了基于群智的软件开发效能。基于“人在回路中”的群智软件生态观，群智软件开发方法需重点关注：（1）研究大规模群体的高效协作机理和模型，突破面向复杂环境的群体协同增强方法；（2）研究碎片化贡献的高效共享与汇聚融合技术，建立群体贡献的高效可信传播体系；（3）突破群智贡献的多维量化评估与度量技术，形成多源群智贡献的高效汇聚与精化收敛方法
|
||||
|
||||
\subsection{群智协同演化}
|
||||
群智软件开发是一种人类智能和机器智能协同融合推动软件系统持续迭代的新方法，如何充分激发人机群智的效能实现软件系统的快速演化，需要重点关注：（1）研究群体行为量化分析与建模方法，建立群智激发汇聚行为轨迹演进模型；（2）研究涵盖代码、开发者、开发社区、软件生态的群智软件开发多维度分析评估方法，突破面向软件开发演化的大数据分析和智能释放技术；（3）研究开发者群体智能与开发大数据机器智能的互补融合、协同演进机制，构建面向软件生态演化的人-机反馈回路。通过上述研究，为群智软件生态演化提供技术支撑。
|
||||
|
||||
\subsection{群智软件支撑环境}
|
||||
以群智软件开发方法和技术为依托，以群智开发生态为理论指导，构建面向群智软件开发与演化的支撑环境，需要重点关注：（1）研究构建面向群智制品和大规模群体的管理、协作、共享与评估等群智开发支撑工具集，有效支持开放群体的高效协同和群智任务的有效管理；（2）研究动态开放环境的群体组织规则与环境协作流程，构建相应的支撑机制和工具，充分释放大规模人-机群体的效能；（3）突破面向新型软件的智能化开发运维一体化技术，构建人机混合智能软件开发与演化的支撑平台，建立针对群智软件开发生态中核心技术和关键节点的支撑和掌控机制，形成覆盖人-机-物的全新软件开发与技术创新生态网络。
|
||||
|
||||
\subsection{面向机器编程的代码生成}
|
||||
机器编程是人机协作编程的基础，而代码生成又是机器编程的核心。从软件的生命周期过程看，机器编程主要在以下场景中起作用：（1）以软件规约为出发点，自动生成满足规约的软件代码；（2）针对软件中存在的错误，自动生成修复代码。从软件规约生成代码本质上是一个搜索过程，即在在程序空间里搜索满足软件规约的程序，然而待搜索的程序空间规模巨大，搜索难以有效进行；同时，程序本身固有的复杂性使得验证代码是否满足规约也存在巨大的效率问题。与从软件规约生成代码相比，自动生成修复代码有明显的特殊性：修复时通常缺乏可以准确刻画正确程序性质的规约，但存在可运行的出错程序，此时代码生成更多地是在已有代码上的修改，而验证更多地通过对比运行修改前后的程序进行。这方面的主要研究内容包括：（1）如何利用海量代码数据加速程序合成中的代码搜索；（2）如何利用海量代码数据加速程序合成中的代码验证；（3）如何利用人类程序员的修复数据完成软件错误的自动修复。
|
||||
|
||||
\subsection{面向人机协作的智能开发环境}
|
||||
人机协作编程的另一个重要基础是高效的智能开发环境，智能开发环境是机器编程技术的集中承载者，也为开发人员提供各种智能服务，同时智能开发环境也是开发人员间交流的通道。在一个智能开发环境中，开发人员应该能够方便地获取各种所需的信息，从而减少对自身大脑信息记忆的依赖；同时，智能开发环境应该能够主动识别开发人员的需求，为开发人员推荐相关的信息或开发动作，比如推荐完成特定开发任务的代码；进一步，作为开发人员间交流的中介，智能开发环境应该保证开发人员间高效顺畅的交互，如果存在可以独立承担开发任务的机器程序员，智能开发环境也应保证人类程序员与机器程序员间的交互；传统的键盘和屏幕并不是人类最习惯的交互机制，更好的交互机制应该是一种综合运用多种感官的多通道交互，智能开发环境应该提供开发人员更习惯的交互机制。因此，这方面的主要研究内容包括：（1）如何帮助开发人员快速查找开发所需的信息；（2）如何针对具体的开发任务推荐可能的开发动作；（3）如何实现开发人员间以及与开发环境间的多通道交互。
|
||||
|
||||
\subsection{开发过程建模与优化}
|
||||
丰富的工具是软件过程实现DevOps化的助推器与基石，工具在有效的优化过程的同时，会产生海量的过程数据。挖掘这些数据并构建模型，以实现过程改进和优化是目前热门的研究领域。早在DevOps出现之前，软件过程建模和优化就是一个研究热点，但数据的缺乏一直是过去相关研究面临的主要挑战。DevOps的盛行，尤其是随着各类工具的普及，问题已经转变为了如何有效挖掘并利用资源库中蕴含的海量数据。有两大类研究值得关注：一类是使用传统过程建模技术为理解、分析以及管控过程提供支持，更进一步的可以实现过程的改进与优化。另一类研究采用机器学习技术，着眼于过程中更具体的点，例如缺陷预测，持续集成结果预测，评审人员推荐等等，能够为提高过程质量、减少资源消耗和缩短交付周期等提供支持。
|
||||
|
||||
\subsection{软件系统运行数据管理}
|
||||
从指标信息、调用链信息以及日志信息入手，通过深入整合与挖掘这三种运维数据信息，来提供更丰富以及高质量的信息，进而提升AIOps的质量与效率，这应该是需要实现的目标。为了达成这个目标，需要开展如下研究。首先，需要研究提升运维数据的质量的方法。在这三类信息中，由于日志信息是非结构化的以及主观的，因此数据的质量并不理想。在日志的生命周期中，需要将日志决策和开发的阶段提前，融入需求开发阶段，并形成日志的开发-运维反馈闭环。辅以自动化日志工具，以此来提高日志的质量以及日志记录的效率。其次，应该提升调用链信息的捕获和存储效率。最后，需要提出一种深度整合三类运维数据的方法。指标信息、调用链信息以及指标信息应该通过特定的算法关联起来，从而提供多维度的运维信息。例如，调用链信息可以与指标信息结合，将各个时间节点的指标信息以调用关系的形式组织起来，进而促进根因分析等AIOps任务。
|
||||
|
||||
\subsection{安全和可信的开发运维一体化}
|
||||
DevOps打破了软件开发与运维团队之间的隔阂，提高了软件部署的频率，但是当运维团队在维护过程中遇到安全问题时仍然需要通过求助安全团队，使用专业的安全工具检测问题来源，分析数据形成解决方案并提交给开发团队最终解决问题，这一过程通常需要较长的时间且伴随有问题扩散的风险。为实现安全且可信的运维，主要的研究内容包括：（1）通过自动化运维以及智能化运维减少运维工作中的一些人工操作，在提升效率的同时避免手工作业所可能产生的错误；（2）对运维过程的监控数据进行分析，及时检测异常的发生，并对问题进行追踪和溯源工作，快速解决问题、避免损失；（3）DevSecOps下的安全运维在持续监控和分析的同时需要建立持续的问题反馈循环，为产品安全性和可行度提供持续的保障。
|
||||
|
||||
\subsection{开发运维一体化的组织与管理}
|
||||
为了缩短软件从产品设计到呈现给最终用户的时间，DevOps整合了软件开发和运维团队，这使得DevOps团队的组织、文化和过程都与单纯开发、运维团队不同。基于DevOps的目标、基础设施变化、质量和安全的挑战、工具链发展现状，DevOps需要解决以下问题：（1）使用经验软件工程的方法，探寻适合DevOps的组织结构和过程实践，并进行验证；（2）如何既能通过团队自组织工作方式提升效率，同时又能够避免由于具体人员技能缺失或管理人员与DevOps团队缺乏信任关系造成的失败，在敏捷与规范之间取得平衡；（3）在大型项目中，使用怎样的组织方式和软件过程，能够使得DevOps项目具有敏捷应对变更的优势以及工作效率。
|
||||
|
||||
\subsection{微服务软件架构}
|
||||
围绕微服务架构有如下几类研究：第一，实现合适粒度的微服务划分方法，主要研究内容包括：（1）基于领域驱动设计方法识别限界上下文以实现高内聚、低耦合的服务；（2）利用遗留系统的现有构件信息识别候选微服务；以及（3）综合利用多种划分策略实现复杂系统的服务划分等。第二，基于微服务架构的快速故障定位和消除，主要研究内容包括：（1）构建更加完善的监控系统，除了基础指标监控功能，实现分布式服务链路追踪和日志聚合分析等高级功能来帮助故障排查和定位；（2）基于AIOps实现智能告警运维，具体来讲通过已经构建的监控系统平台对多种类型数据进行不同形式的采集（有代理和无代理）、处理、存储， 使用并改进机器学习算法对运维数据进行分析预测，实现多种场景的智能告警运维。第三，微服务架构评估，主要研究内容包括：（1）提出面向微服务系统的架构质量评价方法，为微服务系统架构质量的评估过程提供指南，总结供架构评估使用的核查表（checklist）以支持开发、运维微服务系统的实践；（2）初步实现一个微服务系统的验证平台，为软件开发、运维人员和软件组织提供有效的架构决策和实现支持。
|
||||
|
|
@ -0,0 +1,114 @@
|
|||
|
||||
操作系统负责管理软硬件资源、操纵程序运行，为应用软件提供公共支撑，是“软件作为基础设施”的集中体现。过去，操作系统是信息空间的基础设施，起到以平台化方式向下管理各类资源、向上支撑应用运行的作用；未来，在信息物理持续融合趋势的推动下，操作系统管理资源将向各类物理资源扩展，甚至向其他具有“数字孪生”特性的经济、社会和生产生活资源扩展。这一趋势是“软件定义”思想发展的必然结果：随着计算系统正在突破单机、数据中心等封闭环境的限制，操作系统的资源虚拟化、功能可编程能力进一步拓展，从控制管理单个计算机系统资源进一步延伸为连接协调多个结点组成的复杂计算系统，为信息空间、物理空间乃至整个社会提供“软件定义”手段，推动着诸如网构软件操作系统、智能家居操作系统、智慧城市操作系统等“普适操作系统”（Ubiquitous Operating System）成为现实$^{[1]}$。
|
||||
|
||||
与此同时，操作系统的外延、或者说“操作系统应该是什么形态”这一问题也在随着技术和应用的发展而不断扩展演化。例如，在人机物融合互联这一大背景下，中间件正在表现出加速融合到操作系统中的趋势：早在上个世纪的90年代初，美国华盛顿大学的MOSES（Meta Operating System and Entity Shell）项目即使用了“元级操作系统”的概念来描述分布环境下“位于本地操作系统之上、应用之下的一层软件”$^{[2]}$；早期的普适计算中间件Gaia $^{[3]}$等已在文献中混用“元级操作系统”和“中间件”概念，而今天广泛应用的ROS（Robot Operating System）$^{[4]}$更是继承了网络中间件的核心思想。换言之，操作系统正在以海纳百川的方式沉淀各类具有软件定义特征的基础设施，这也是本章标题“操作系统与运行平台”的由来。
|
||||
|
||||
基于上述内涵和外延两个方面的观察，本章将从平台架构、方法机制、安全隐私、生态链构建等方面列出操作系统与运行平台的重大挑战问题，并阐述本领域的研究趋势和内容。
|
||||
\section{重大挑战问题}
|
||||
互联网革命正在进入下半场，“万物互联”时代正在到来，人机物融合的泛在应用场景推动着操作系统和运行平台的新一轮变革，带来体系结构、资源管理、应用支撑、首先，在所管控资源高度异构、涵盖人-机-物三元空间的条件下，未来的操作系统和运行平台需要什么样的架构（§5.1.1）；其次，从向下管理泛在资源的角度，需要以及什么样的资源虚拟化和调度机制（§5.1.2）；再次，从向上支撑应用运行的角度，应当如何支撑上层应用的持续适应和演化（§5.1.3）；最后，在人与物加入到操作系统管理对象中之后，基础设施层的安全与隐私保护风险如何应对（§5.1.4）。
|
||||
\subsection{支持软件定义的新型运行平台架构}
|
||||
“软件定义”的提法最早可追溯到上个世纪90年代所提出的软件定义无线电（Software-Defined Radio）$^{[5]}$概念。在软件定义的无线电设备中，传统由晶体管、集成电路等实现的信号处理部件（如滤波器、调制/解调器等）被软件所代替，在大幅简化硬件设计同时，获得“功能可编程”的显著收益――设备能力可以按需扩增或裁剪，从而快速适应技术体制和市场需求的变化。
|
||||
|
||||
进入21世纪，随着云计算等新型计算范型的出现，人们对计算系统的灵活性、可管理性和资源利用率的追求日益提高，“软件定义”一词被引入到计算技术领域。以 “软件定义网络”$^{[6]}$为例，与传统网络互联能力由硬件/固件所决定不同，软件定义网络强调将整个网络自底向上划分为数据、控制和应用三个平面。其中，控制平面向下操纵和协调数据平面上设备（如交换机）的行为，向上提供尽可能与硬件无关的抽象（编程接口）、支撑应用平面运行。控制平面不仅具备“功能可编程”能力，也具备了“资源虚拟化”能力，也即能够对数据平面资源进行高效管理、封装与抽象。“软件定义”内涵的这一升华深受操作系统思想的影响。例如，首个开源的软件定义网络控制器NOX（Network Operating System）在其文献$^{[7]}$中指出，“现代操作系统通过提供对资源和信息高层抽象的可控访问…使得程序可以在各种计算硬件上安全和高效执行复杂任务”，NOX就是将操作系统思想拓展到了网络设备管理中。
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\subfigure[传统操作系统]{
|
||||
\centering
|
||||
\includegraphics[width=0.4\linewidth,height=2.5cm]{fig2-5/tos.png}
|
||||
}\
|
||||
\subfigure[软件定义网络$\lbrack$x$\rbrack$]{
|
||||
\centering
|
||||
\includegraphics[width=0.5\linewidth, height=2.5cm]{fig2-5/sdn.png}
|
||||
}
|
||||
\caption{操作系统与软件定义网络架构的类比}
|
||||
\end{figure}
|
||||
|
||||
将操作系统“功能可编程”、“资源虚拟化”的思想拓展到存储、安全、数据中心等具体领域，我们就得到了软件定义存储、软件定义安全、软件定义的数据中心等概念。进一步，随着操作系统由计算机软硬件之间的桥梁、人与计算机之间的桥梁拓展到云边端、人机物之间的桥梁，其定位将由单个计算机“管家”演化为支撑“软件定义一切”的运行平台。传统操作系统架构面向的是信息空间内孤立计算结点，这一沿用数十年的架构将面临如下两个方面的挑战。
|
||||
\begin{itemize}
|
||||
\item 从“精确控制”到“连接协调”的挑战。未来的人机物融合系统将是大规模、网络化的计算系统，虽然每个节点上仍将运行传统的节点操作系统，在节点内部通过对资源实施严格精确控制来达到资源虚拟化、功能可编程的目的，但这种精确控制机制很难直接应用到网络层面。事实上，这种简单放大的思路在30年前的Amobea等分布式操作系统实践中就已经证明很难奏效（参见本书历史篇§3.4“中间件”一节）。根本原因在于网络化系统具有开放和复杂系统的特征，其所涉及的实体往往跨越多个管理域，系统边界也随时间演化而不断发生变化，很难构建静态不变的控制中心，或是明确稳定的自顶向下层次化结构。在这种场景下，更为妥当的方式将是 “连接协调”，即通过按需聚合和动态协同来打破不同节点之间的壁垒，统一管理并优化利用计算、数据甚至物理世界各种资源。从“精确控制”到“连接协调”的方式的这一转变，将从根本上动摇现有操作系统的架构，并催生新一代、运行于节点操作系统之上的网络操作系统。
|
||||
\item 计算、通信、控制三元融合场景的挑战。今天广泛使用的Windows、Linux等操作系统在架构上深受首个现代意义上操作系统－－Unix的影响。它们运行于单一计算结点范围内，内部大致可划分为资源管理、系统调用、人机接口等层次。这种架构针对信息空间内部的孤立计算结点设计，很难支撑泛在化、智能化、网络化的新型应用场景。具体而言，在计算维度上，单一的本地计算将向云边端一体化计算、人机物协作计算、智能和机器学习计算等新型场景变迁；在通信维度上，5G等新型网络的出现使得网络时延和吞吐量得到极大改善，可望触发移动和嵌入式操作系统的新一轮革命；在控制维度上，物联网、机器人等与物理世界紧密融合的计算设备涌现，使得“功能可编程”将突破信息空间范畴，需要在操作系统架构设计层面上考虑物理空间约束和对物理空间的影响。
|
||||
\end{itemize}
|
||||
\subsection{泛在资源的高效虚拟化和灵活调度}
|
||||
文献$^{[1]}$给出了“普适操作系统”的概念，指出未来的操作系统不仅仅是IT操作系统，也将成为物理世界和虚拟世界的操作系统，在今天已经初露端倪的机器人操作系统、车辆操作系统、物联网操作系统等基础上，校园操作系统、城市操作系统、家庭操作系统等可望在将来成为现实。在这一背景下，操作系统的核心功能――资源虚拟化和调度的实现机制面临一系列挑战（图\ref{fig2}）。
|
||||
|
||||
首先，高性能处理器、新型存储器件、高速网络互联设备等快速发展，使得经典的计算资源虚拟化和调度机制面临挑战。例如，多核和多芯片计算机系统中非一致性内存访问架构使得传统基于页的虚存系统面临挑战；张量处理器等人工智能新型加速器的出现，亟待相应细粒度的虚拟化技术支持；非易失性内存的应用使得内存中的某些数据不再需要存储到硬盘，对传统类文件系统架构带来挑战；大规模分布式异构计算以及移动异构片上系统，对Linux等多线程共享存储的单内核结构提出挑战；100G及以上以太网链路在大规模数据中心的普及，网络带宽增长速度超越CPU处理能力增长速度，操作系统网络协议栈面临挑战；等等。
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{fig2-5/mmm.png}
|
||||
\caption{人机物融合新型资源的虚拟化和调度所面临挑战}
|
||||
\label{fig2}
|
||||
\end{figure}
|
||||
|
||||
其次，如何为人机物融合计算中的各类新型异构资源建立抽象，是未来操作系统需要解决的核心问题。本质上，操作系统和运行平台负责向应用提供“抽象”，并将这些“抽象”绑定到硬件祼机。数十年来，这一领域已经积累了诸如进程、线程、文件、内存页等一系列重要抽象机制，为现代操作系统奠定了基石。但是，未来操作系统所管理的资源将跨越人、机、物三元空间，涵盖物理资源、计算资源、数据资源等多种类型，现有抽象远远不能满足需求。因此，需要探索符合新型资源特点、切合其特性的抽象机制，并突破在单一计算结点、有一定边界的分布式系统、跨域开放式系统等不同尺度上维护这些抽象的方法机理。
|
||||
|
||||
再次，在操作系统支持下，物理资源将呈现物理与数字二像性，如何将信息空间内的抽象与物理空间内的实体绑定，并持续保持和校正二者之间的一致性，是操作系统泛在化以后产生的新问题。一方面，需要利用预建立物理模型、传感器实时数据、较大时空尺度上的运行历史等数据，集成多物理量、多尺度、多概率的仿真过程，实现物理资源到信息空间中实体的正向映射，以及“因果关联”的虚拟实体到物理资源的映射；另一方面，即使建立了相应的“数字孪生”关系，也要考虑物理域和社会域资源在管理和调度过程中的特有属性，例如动作的非精确性和动态性、固有的噪声等。
|
||||
|
||||
第四，如何使打破信息-物理世界间以及不同节点间的壁垒，按需聚合各类资源，是实现泛在资源优化利用的关键。如前节所述，未来的计算系统在微观尺度上仍将运行我们今天所熟悉的节点级操作系统，而在整个系统的宏观尺度上，资源管理模型将从“精确控制”向“连接协调”转变。虽然这一理念在中间件、网构软件等领域已经有了初步实践，但一系列实现机制层面上的开放问题仍有待解决，包括需要何种模型来协调跨域资源及其能力、如何在动态环境下维持相对稳定的“功能可编程”抽象、如何有效管理调度各种冲突及涌现现象等。
|
||||
|
||||
第五，需要深入理解未来泛在计算场景下应用模式的共性特征，为上层应用的“软件定义”提供适当的、相对稳定的编程接口。可以预见，未来泛在计算场景至少包括数据规模巨大、强调按需能力获取的“云-边”效用计算，资源需求动态变化、不确定性很强的智能计算，移动性强、承载设备多、续航要求高、迭代快的智慧城市、工业互联网等领域的协作计算，人与物相互驱动、相互协同的人机物统一计算等。这些泛在应用模式很多都处在探索阶段，需要理解和凝练应用模式的共性特征，进而通过编程接口支撑上层应用灵活实施软件定义。
|
||||
\subsection{复杂软件系统持续适应演化的共性支撑}
|
||||
近年来，以人机物融合系统为背景，有研究者提出了信息产业的“昆虫纲悖论”：一方面，未来物联网设备和应用场景将会像昆虫一样繁多，带来空前巨大的市场；另一方面，由于每种场景都存在其个性化需求和特点，针对场景所开发的软件系统将缺乏可拷贝性，导致边际成本显著提高，反过来制约产业的发展。要打破这一悖论，关键在于软件系统不能静态绑定到特定场景，而应当具备灵活适应场景的能力，在其生命周期内能够持续演化来应对环境和用户需求的变化。
|
||||
|
||||
软件适应能力将成为未来人机物融合软件系统的基本属性，而操作系统在支撑软件适应演化活动方面具有天然优势：从可计算性的角度而言，操作系统与下层硬件裸机一起组成了能够“操纵”应用软件执行的通用图灵机实现，这一“操纵”能力使得操作系统有可能驱动应用软件的适应和演化；从计算反射$^{[10]}$实现的角度而言，操作系统和运行平台是应用软件执行的“元层容器”，对于上层应用具有计算反射能力，例如获知上层应用和环境状态、维护系统化反映上层应用环境和状态的模型、对上层应用实施调整操作等。因此，操作系统和运行平台是驱动计算节点动态感知、自主学习、在线演化的理想载体，但这一地位也同时对平台设计实现提出了一系列挑战。
|
||||
\begin{itemize}
|
||||
\item 操作系统及其上应用的自主适应与学习赋能。从“网络就是计算机”到“场景就是计算机”，其蕴含的理念从计算资源聚合进一步拓展到了多样化人机物融合场景下的资源按需定制。要实现“场景就是计算机”，关键在于操作系统和其上应用需要具备主动适应新场景和场景变化的能力，包括：操作系统本身和其上应用都具有柔性体系结构，节点本身可以动态调整，节点与节点这间连接关系可以按需变化，并且携带有指导这些变化的元层数据；在操作系统和运行平台内部构建“感知－理解－调整”回路，能够捕获和理解环境及运行状态，进而据此进行应用配置生成、主动部署、参数和连接关系在线调整等操作；具有从过去的适应和演化动作及效果中持续学习的能力，从而突破预定义场景和决策规则的约束，使得操作系统及其上应用在适应场景和用户需求变化的维度上能够表现出一定的“智能”。
|
||||
\item 大规模复杂软件系统的演化规律及其支撑机制。人机物融合场景下，许多软件系统已经达到了空前的规模。例如，互联网的前身ARPANET仅连接了4个节点，而2018年移动社交应用微信的月活跃用户数达到了10.8亿。规模上的量变引起质变，此类系统表现出了“系统之系统”、信息物理融合系统和“社会-技术”系统的特点，具有与单个节点或小规模分布式系统不同的演化规律，包括：复杂软件系统规模巨大，其海量状态数据之间存在着千丝万缕的联系，如何“去粗取精、去伪存真”，提取能够作为适应演化依据的运行态势数据；复杂软件系统中的节点通过“连接”形成了一个复杂网络，如何基于复杂网络中的交互掌握软件架构和运行大势；在由大量自治软件单元所组成的复杂软件系统中，适应性演化动作往往发生在单元、子系统、系统等多个尺度上，如何在群体层面上形成恰当的适应性演化行为，以及不同层次上的适应性演化如何相互影响；等等。
|
||||
\item “人在回路中”的软件系统演化决策。软件是“由人开发，为人开发”的产品，人在软件生命周期各个阶段所发挥的作用不可替代，人是软件产品需求的提出者，也是需求落地实施的开发者，同时也是软件终端的使用者以及运行时的维护和升级者。因此，未来人机物融合软件系统适应性演化决策应当是软件和人相结合的方式，除了现有的规则、策略、机器学习等自动化方法外，“人在回路中”是其重要的特点，操作系统和运行平台如何通过集成DevOps工具和平台来有效支持人来发挥作用、同时又通过人工智能相关技术减少人主动干预的负担，是未来要解决的重要挑战。
|
||||
\item “信息-物理-社会”空间的协同持续演化。复杂软件系统是典型的“社会-技术-物理”系统，软件将与其所在的社会和物理环境紧密融合在一起，相互作用、相互影响。这与传统的、完全在信息空间运行的软件有着质的区别。具体到基础性的、“操纵计算系统执行”的操作系统和运行平台层面，需要有能力支撑上层应用与物理世界和人类社会长期性的共同进化。这将显著扩展现有操作系统的内涵，带来一组极具挑战性的开放问题，例如：物理空间变化的频率远高于信息空间变化的频率，如何高效的适应物理空间的变化；利用人工智能算法来进行演化决策，一旦决策错误可能会直接在物理空间造成严重后果，其中的技术、法律甚至伦理问题如何解决；等等。
|
||||
\end{itemize}
|
||||
\subsection{人机物融合过程中的安全与隐私保护}
|
||||
数十年来，“魔高一尺，道高一丈”，主流操作系统不断围绕系统用户认证、访问控制、数据安全、漏洞攻击缓解等方面进行安全增强。然而，安全与隐私保护是一种伴生技术，新的安全问题伴随新计算模式的涌现而不断产生。未来，随着5G通讯、移动互联、云计算与物联网的应用普及，人机物将广泛互联，在网络虚拟世界与现实世界的行为将实现虚实深度融合，导致信息系统的安全防御边界愈加模糊，面临的安全威胁在种类和数量上都将激增，用户隐私保护的难度显著增加。在未来人机物融合的过程中，作为信息空间与物理空间乃至整个社会进行统一信息处理的载体，操作系统及运行平台在安全和隐私保护方面的需求将面临一系列挑战：
|
||||
|
||||
首先，需要在大规模松耦合交互场景下建立虚实融合的信任关系。在未来人机物深度融合的时代，将会有大量物理设备与应用软件接入到运行平台，以数字身份作为运行主体在系统中发挥作用。随着越来越多的现实世界行为被迁移到网络虚拟空间进行处理，在数字世界中如何对纷繁芜杂的虚拟社会关系进行准确刻画并实施严格管理，是构筑未来安全可信数字空间的所必须要面对的挑战。在此基础上，要建立数字身份的信任关系，还需要在平台层面上对数字实体在虚拟世界的行为进行全面、如实地记录，为准确刻画数字世界实体间的信任关系提供有力依据。并且，由于现实社会中主体之间关系的大规模、松耦合特性，原有的集中式管理方式对人机物融合系统的实体管理将无法适用，需要实现管理的弱中心化，基于众包、基于区块链等新型信任关系构建方法已在操作系统领域崭露头角。例如，IBM的面向区块链的分布式操作系统Hyperledger Fabric可以利用区块链来支撑分布式应用运行，并且通过模块化的共识协议来使得系统可以灵活适应不同的应用场景和信任模型。
|
||||
|
||||
其次，需要实现人机物融合场景下的严苛安全和隐私保护需求。人机物融合场景下计算节点众多、数据传输分散，诸如边缘计算等以“计算尽可能靠近数据的源头”为基本理念的计算模式将走向前台。而这些新的计算模式由于其服务模式的复杂性、实时性，数据的多源异构性、感知性以及终端的资源受限特性，传统数据安全和隐私保护机制将很难高效应用。同时，由于移动终端的资源一般都比较有限，其所能承载的数据存储计算能力和安全算法执行能力也有一定的局限性。如何将传统的隐私保护方案与边缘计算环境中边缘数据处理特性相结合，从数据隐私、位置隐私、身份隐私等多个方面入手研究相应的保护方案，是未来操作系统安全与隐私保护领域面临的重要挑战。同时，为了支撑广泛、大规模的人机物融合和互联，需要突破现有操作系统安全和隐私保护的被动防御机制、打破“信任篱笆”，强化安全与隐私保护的主动性与支配性，在利益与风险之间权衡，既关注更强、更灵活的隐私保护，又支持网络资源共享和互联互通。
|
||||
\section{研究内容}
|
||||
如5.1.1节所述，未来操作系统分成两种类型：节点操作系统和网络操作系统。前者是今天操作系统的后续者，在有明确边界的节点范围内，实现资源虚拟化和功能可编程；后者运行于节点操作系统之上，实现网络环境下人机物异构资源聚合和优化管理，支撑各种类型、不同尺度的泛在应用。本节将以这一分类为依据，分别阐述节点操作系统（§2.1-§2.3）和网络操作系统（§2.4-§2.6）的研究内容，并在§2.7、§2.8、§2.9和§2.10中专门阐述物理和社会资源管理、操作系统和应用的适应和演化、操作系统生态链构建相关研究问题。
|
||||
\subsection{支持泛在应用和新型硬件的节点操作系统}
|
||||
节点操作系统是未来操作系统生态中的基石。过去60年中，大型主机、个人计算机、实时嵌入设备、手持移动设备、可穿戴和物联网设备等不同类型计算节点的出现，以及相应应用场景的普及，持续推动着节点操作系统技术的发展。针对未来人机物融合环境中网络资源、存储资源、数据资源、计算资源、传感资源等海量异构资源，节点操作系统将进一步探索以“软件定义”的方式实现资源的虚拟化和柔性调度的方法机制，通过编程接口支撑各类泛在化、网络化和智能化应用。另一方面，新型应用对算力和存储性能等多方面的要求导致新型异构硬件的不断出现和演化，如图形处理器、张量处理器、非易失性内存、远程直接内存访问等。操作系统自身需要适应这些新型硬件发展，进而研究异构计算、内存计算等新型运行平台架构，实现技术架构升级和软硬件之间的深度融合优化设计。
|
||||
|
||||
此外，如何依托云计算等后台支持，构建跨终端、体系化的操作系统平台，使得用户在不同平台上获得一致化的用户体验和设备自由切换能力，也是泛在计算的重要使能机制。典型案例是谷歌继移动操作系统Android和轻量级桌面系统ChromeOS之后正在研制的跨平台Fuchsia操作系统，其目标是能够覆盖嵌入式、终端、平板和桌面等所有平台。
|
||||
\subsection{面向特定应用领域的节点操作系统优化技术}
|
||||
特定领域的节点操作系统实现技术将进一步突破。一方面，针对复杂环境对智能终端的高可靠、低功耗、强交互、智能化和高安全等方面的迫切需求，突破高可靠终端操作系统体系结构、多场景自适应的电源管理优化技术、多种生物特征认证增强技术、资源受限环境下的深度学习适配优化技术，构建具备高可靠、低功耗、强交互、智能化和高安全能力的新一代智能终端操作系统。另一方面，针对嵌入式计算中安全关键、任务关键、非关键等任务混合运行及其安全隔离问题，研究混合任务确定性调度、混合系统实时响应、混合任务间高效通信机制等技术，形成具有确定性保障能力的嵌入式混合关键任务操作系统保障机制，满足嵌入式计算在复杂环境中对系统实时性、安全性、可靠性的严酷要求。
|
||||
\subsection{软硬件结合的节点操作系统安全防护技术}
|
||||
如何结合处理器和硬件平台的特点，设计新型安全高效的操作系统结构，是节点操作系统技术另一主要研究内容。当前，基于CPU的可信计算空间隔离和基于TPM芯片的可信计算技术为可信软件执行提供了硬件级的执行验证，这些技术都从操作系统底层提供了有力的可信执行支持，未来操作系统安全研究将利用这些先进技术来降低漏洞给应用带来的安全风险，发展软硬协同的操作系统安全攻防对抗模式，变被动响应为主动防护，夯实信息系统的安全基础。具体而言，需要突破软硬件高效协同的安全体系结构设计、安全防护模型和方法、跨域交互机理及优化方法和基于模糊测试的内核安全性测试等关键技术，结合硬件平台提供的多层次特权防护、资源分区隔离等安全能力，解决软硬协同的高安全操作系统设计中的核心问题。
|
||||
\subsection{面向新型应用和部署模式的资源虚拟化技术}
|
||||
随着云原生应用架构的不断发展和应用，以“函数即服务”（FaaS）为代表的无服务器计算（Serverless）等计算模式和边缘计算等应用模式给传统操作系统和虚拟化架构带来了挑战。首先，虚拟化技术需要能够在支持多租户隔离的前提下实现高密度的资源虚拟化。以在边缘计算场景为例，与集中式云数据中心不同，可能需要在边缘的十几个服务器上分别支持数千种不同的服务，当前已有的基于容器的轻量级虚拟化技术尚不能完全满足。其次，在无服务器计算和边缘计算等场景中，应用对资源的需求是高度动态变化的，这给虚拟化的性能提出了苛刻要求，需要探索新的轻量级虚拟化架构和优化机制。再次，部分云计算应用开始出现向微服务应用发展的趋势。这意味着软件架构进一步地解耦，单个镜像上运行的业务更加专一。因此，当前提出了 Unikernel等机制来大幅度精简冗余模块来提高虚拟机的启动速度，但虚拟化场景下的适用性和成熟度还需要进一步提升。最后，计算资源之外的其它资源（如GPU、存储、网络等）专用虚拟化技术需要进一步探索。
|
||||
\subsection{网络环境下跨结点的资源高效按需聚合技术}
|
||||
“计算的泛在化”意味着操作系统和运行平台的作用范围突破了传统单一计算结点范畴，需要在广域环境和广义的计算空间内调度各类资源，为上层软件提供相对稳定的抽象，这是未来操作系统和运行平台所面临的重大挑战，而资源聚合及统一管理优化是网络操作系统实现这一目标的手段。在计算系统规模持续增长的情况下，需要突破海量虚拟机资源的高效管理、虚拟机间通信优化、自适应的虚拟机在线迁移及动态部署、共生虚拟机间共享内存的弹性管理及优化、虚拟机访存效率优化等技术，实现跨结点的高效分布式资源调度。另一方面，网络操作系统中往往没有明确、固化的控制中心或层次结构，跨结点的“资源虚拟化”和“能力可编程”主要依靠“连接协调”、通过自底向上的方式来实现。如何借鉴社会系统、经济系统、生物系统等复杂系统机理，实现上述目标，也是此类操作系统面临的挑战。
|
||||
|
||||
在跨结点的资源按需聚合方面，未来的一个重要应用模式是“云-边-端”协同模式。因此，需要面向现代网络化信息支撑体系的发展趋势，探索以资源虚拟化、服务云化、前后融合为基本特征的“云-边-端”协同操作系统柔性结构设计与优化技术。研究“云-边-端”高效资源协同调度框架、基于云边端协同和多目标优化的任务调度技术等，解决复杂环境给软硬件资源管理带来的挑战。
|
||||
\subsection{虚拟化和多租户条件下的主动防御技术}
|
||||
其次，需要抵御虚拟化和多租户等新型运行支撑技术带来的安全风险。未来，更多的服务被整合在单一运行平台上，这些服务中可能包括了来自不同租户的不同安全等级的信息，必须根据用户需求对应用系统的硬件、软件、数据、网络、存储等不同层面资源实现安全隔离。同时，为了提高资源利用效率，运行平台根据资源使用情况进行动态调度，这种动态变化的环境将显著增大了安全隔离的难度。目前主要通过底层的虚拟机监控器Hypervisor来负责实现虚拟机的隔离，为用户提供自底向上的虚拟化软硬件运行环境，具备较强的隔离性。而为了提高服务运行性能，以Docker为代表的轻量级虚拟化容器技术也被广泛应用，相对于虚拟机的强隔离性，容器技术则是以弱隔离性换取性能的提高。在应用虚拟化技术的过程中，隔离性与性能之间的取舍、动态变化下虚拟计算资源的安全复用、Hypervisor层的虚拟机监管、虚拟机逃逸防护等都成为必须要面对的挑战。同时，虚拟化技术还需要对软件定义网络在数据中心内部的网络安全管理提供支持，通过虚拟网关等技术对虚拟化数据流进行安全监控，这些虚拟设备能否安全使用都将对系统安全性产生深刻的影响。
|
||||
\subsection{物理和社会空间资源的抽象和管控技术}
|
||||
操作系统的“资源虚拟化”能力来自于其对资源的抽象、封装和调度的能力。传统操作系统针对的是信息空间内部的资源 ，而如何表达和管理各类高度异构、动态变化的物理和社会空间资源，是未来泛在化操作系统需要应对的问题。在此基础上，在认知、物理和信息空间三者之间，如何刻画、检验、保持、校正多模型结构之间定性与定量一致性，进而实现具有“数字孪生”的物理和社会空间资源的调度和管理，是未来操作系统重要研究内容之一。
|
||||
|
||||
此外，未来操作系统的编程接口不仅涉及到计算资源的“软件定义”，可能包括各种可传感物体对象、智能无人系统等各类物理资源，甚至向其他具有“数字孪生”特性的经济、社会和生产生活资源，其接口形式、接口实现机理等都是开放的问题。
|
||||
\subsection{人机物融合的操作系统架构演进技术}
|
||||
面向未来“人-机-物”融合环境中网络资源、存储资源、数据资源、计算资源、传感资源等海量异构资源，以“软件定义”的方式实现资源的虚拟化和柔性调度，通过编程接口支撑中心式的云计算和分布式的分散计算模式以及各类智能应用。适应人工智能芯片、非易失性存储等硬件发展，研究异构计算、内存计算等新型系统软件架构，实现技术架构升级和软硬件之间的深度融合优化设计。
|
||||
\subsection{运行平台支持的软件在线适应与演化技术}
|
||||
操作系统和运行平台是能够支撑上层应用适应和演化的天然基础设施，但由于在线演化的需求是在“软件作为基础设施”过程中逐渐显现的，其实现机理也是目前操作系统和运行平台领域研究相对薄弱的环节，需要从运行状态把握、群体智能决策调整、宏观和微观演化效果评估等角度开展研究。相关研究内容已经在重大挑战性问题的5.1.3节中给出，本节不再赘述。
|
||||
\subsection{基于开源和众包的操作系统生态构建技术}
|
||||
随着互联网的深入发展和广泛应用，操作系统和运行平台的研发出现了新的特点，其中开源和众包对操作系统的发展产生了深远影响。它们一方面改变了操作系统产业的商业模式，服务化成为趋势，操作系统厂商如苹果、微软纷纷从销售产品获利转型为提供服务获利的模式；另一方面促进了面向行业或应用场景需求的专用操作系统的发展，降低了操作系统研发定制的门槛，使得更多的厂商可以参与到操作系统生态链构建中来。但是，开源和众包模式的引入，也为操作系统的开发带来了一系列问题。例如，在使用开源资源时，如指导思想和方法不当，可能导致在产品中包含若干“黑盒子”，引入代码不可控、产品升级被动等风险；产品如过度依赖开源，发展途径就会被开源主导，创新的空间将被大幅约束；等等。如何在操作系统生态链构建过程中最大限度发挥开源和众包的长处，是需要深入研究的问题，相关的研究方向包括操作系统代码来源链的建模和分析、开源许可证的合规性及冲突分析、多来源缺陷数据的定性与定量统计分析等。
|
||||
\section{结束语}
|
||||
无论是今天还是未来，操作系统都是“软件作为基础设施”的集中体现，也是“软件定义一切”能力的基石。在计算泛在化背景下，未来的操作系统将突破当前单机操作系统这一狭义形式，向支撑人机物融合、具有“资源虚拟化”和“功能可编程”特点的泛化运行平台过渡。受这一趋势所推动，一系列重大挑战性问题涌现，包括支持软件定义的新型运行平台架构、泛在资源的高效虚拟化和调度方法、软件系统持续适应演化的支撑机制、人机物融合过程中的安全与隐私问题等。本节对上述挑战的概念内涵、产生背景和展开后的具体问题进行了详细阐述，并在此基础上结合操作系统和运行平台领域当前研究热点，从未来的节点操作系统、网络操作系统等角度，对领域研究内容进行了梳理。
|
||||
\section{参考文献}
|
||||
[1] Mei, H., and Guo, Y.: Toward ubiquitous operating systems: A software-defined perspective, Computer, 2018, 51, (1), pp. 50-56
|
||||
|
||||
[2] Pezely, D.J., Almquist, M.D., Evenson, M.T., and Bricken, W.: Design and implementation of the meta operating system and entity shell. Technical Report, Human Interface Technology Lab, University of Washington, 1992.
|
||||
|
||||
[3] Román, M., Hess, C., Cerqueira, R., Ranganathan, A., Campbell, R.H., and Nahrstedt, K.: Gaia: a middleware platform for active spaces, ACM SIGMOBILE Mobile Computing and Communications Review, 2002, 6, (4), pp. 65-67
|
||||
|
||||
[4] Quigley, M., Conley, K., Gerkey, B., Faust, J., Foote, T., Leibs, J., Wheeler, R., and Ng, A.Y.: ROS: an open-source Robot Operating System. Proc. ICRA workshop on open source software2009 pp. 5
|
||||
|
||||
[5] Tuttlebee, W.H.: Software-defined radio: facets of a developing technology, IEEE Personal Communications, 1999, 6, (2), pp. 38-44
|
||||
|
||||
[6] Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C.E., Azodolmolky, S., and Uhlig, S.: Software-Defined Networking: A Comprehensive Survey, PROCEEDINGS OF THE IEEE, 2015, 103, (1), pp. 14-76
|
||||
|
||||
[7] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N., and Shenker, S.: NOX: towards an operating system for networks, ACM SIGCOMM Computer Communication Review, 2008, 38, (3), pp. 105-110
|
||||
|
||||
[8] Northrop, L., Feiler, P., Gabriel, R.P., Goodenough, J., Linger, R., Longstaff, T., Kazman, R., Klein, M., Schmidt, D., and Sullivan, K.: Ultra-large-scale systems: The software challenge of the future, Technical report, CMU Software Engineering Institute, 2006.
|
||||
|
||||
[9] Soules, C.A., Appavoo, J., Hui, K., Wisniewski, R.W., Da Silva, D., Ganger, G.R., Krieger, O., Stumm, M., Auslander, M.A., and Ostrowski, M.: System Support for Online Reconfiguration, USENIX Annual Technical Conference, 2003.
|
||||
|
||||
[10] Maes, P.: Concepts and experiments in computational reflection, ACM SIGPLAN Notices, 1987, 22, pp. 147-155
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
|
||||
大数据时代，我们用“以数据为中心的计算”这一说法来表达计算技术的发展趋势：数据在计算体系中的地位越来越重要，数据不再仅仅是算法处理的对象，也不再仅仅是依附于某种功能软件而存在，数据是组织的资产而独立存在，而且数据越积越多、规模越来越大，形成一种数据平台。
|
||||
|
||||
在某种程度上，数据平台隔离了上层基于机器学习的数据建模和推理应用与下层大数据的存储与计算设施。这种分离增加了上层应用系统的稳定性。虽然在目前阶段，很多组织的数据还不够大，自己保存和运维的压力和成本还不是很高，所以往往倾向于自己运营。但当数据达到一定规模后，将会消耗海量的计算、存储、网络等资源，这时就必须放在云计算平台上了。更进一步，为降低成本，组织也不需要自己维护大数据处理与分析系统，把数据拉回来到自己的系统中进行处理了。大数据分析可以依赖云计算平台上的大数据分析服务，直接在共享的公共大数据集上开展各类大数据处理与分析。
|
||||
|
||||
从数据管理的角度看，新一代大数据管理与分析系统具有如下特征：多种数据模型并存；多种计算模型融合；系统可伸缩弹性扩展能力强。首先，多种数据模型并存是指可以支持关系、文本、图、KV等多种数据模型的存储与访问，系统能够根据应用特征甚至运行负载的情况进行模型的转化，支持自适应优化。其次，多计算模型融合是指高效支持批处理、流计算等多种计算模型，计算系统要能将多种计算模型进行深度的融合，而非简单地将两套或多套系统进行集成，避免数据的反复迁移，提高效率，同时能够做到批流交互，支持复杂应用和深度分析。最后，系统要能够高效利用底层的云计算资源，面向云计算平台上的虚拟资源构建效率高、弹性扩展能力强的系统，能够实时进行可伸缩调整，提高资源利用率，在软件系统层提升从资源到性能的转换效率。
|
||||
|
||||
从应用角度看，高时效可扩展的大数据管理与分析系统，未来将支持应用从联机事务处理（OLTP）、联机分析处理（OLAP），走向联机机器学习（OLML）。机器学习等人工智能应用，能够从大数据中挖掘深度知识，将成为大数据管理与分析系统上的一类重要应用。机器学习系统将不再像现在这样，一类模型对应一个工具，而是成为一个同时支持多种机器学习模型的大规模开放平台。
|
||||
|
||||
从数据工程的角度看，降低大数据应用的门槛非常迫切，平民化数据科学成为一种趋势，实现平民化数据学科的有效途径就是提供丰富易用的工具，从数据采集，数据整理到数据分析和模型训练等，这方面的研究实践活动非常活跃，成果大量涌现。未来，期待大数据应用开发方法学的成果能够统领这个方向的研究。
|
||||
|
||||
本章列出数据管理和数据工程的若干重要挑战、主要研究内容与研究趋势\footnote{陈红、陈普川、陈跃国、卢卫、张峰、张孝参与本章内容的讨论与撰写}。
|
||||
\section{重大挑战问题}
|
||||
数据管理与数据工程的挑战问题包括两个方面。首先，在数据管理方面，主要表现在如何管理大数据(§6.1.1)、如何利用新硬件混合架构来实现大数据的管理(§6.1.2)。在数据工程方面，主要有异构数据整理(§6.1.3)、数据分析(§6.1.4)和数据安全与隐私保护(§6.1.5)等挑战。
|
||||
\subsection{大数据管理的挑战}
|
||||
大数据具有大容量、多类型、快变化、低质量的4V特征。大数据管理已不像传统数据库时代去追求使用关系数据库来解决所有数据管理的问题,而是探索从数据存储、数据组织与存取、语言处理、应用等几个维度对各个传统数据库管理系统进行解耦，解耦后的各个子系统依据大数据的4V数据特征，各自独立发展，用户可根据实际应用的需要，采用松耦合的方式对各个子系统进行组装，量身定制自己的大数据管理系统。大数据管理系统技术目前还在快速进化之中，还没有成型。管理好4V的数据，是对大数据管理系统的基本要求。从这个基本点出发，可以归纳出大数据管理系统的若干技术挑战：
|
||||
|
||||
第一，多数据模型的统一管理。i）数据模型是数据管理的核心，数据结构、数据操作、完整约束是构成数据模型的三大要素。关系模型有单一的关系数据结构、封闭的关系操作集合、灵活的关系完整性约束；而大数据管理中的其他数据模型，包括键值对、图、文档等，虽然数据结构定义清晰，但缺少数据模型中数据操作和数据约束两大要素的定义，亟待理论上的突破。ii）关系数据库有严格的关系数据理论和模式分解算法辅助数据建模，如何对大数据进行有效数据建模，尚缺少理论和技术支撑。iii) 大数据多源、异构的特点，使得大数据管理系统无法采用单一数据模型进行管理，多数据模型并存并统一管理，需要系统从语言处理、数据组织与存取、数据存储等多个层次进行重新设计与优化。
|
||||
|
||||
第二，新型系统架构。大数据的大容量和快变化特征，要求大数据管理系统具备高可扩展性。针对大容量特点，采用“分而治之”的思想，将数据进行分片，每个分片部署到指定的节点上进行管理。针对快变化的特点，当数据快速增加时，可以通过增加节点的数量，使系统仍然具备较低的响应时间。在此背景下，大数据管理系统架构面临如下挑战：i）容错。一方面，大数据管理中的存储节点、计算节点已经不局限于传统分布式数据库中的高性能服务器，可以是普通服务器，甚至是普通的PC机器，可靠性有限。更重要地是，节点数量的增加，整个系统出现节点故障的可能性增大。如何从容错的角度，设计可靠的系统架构，不影响数据存储、数据操纵、数据运维等管理的正确性和高效性。ii）去中心化。大数据管理系统是分布式的，中心节点可能会成为访问的瓶颈。一方面，中心节点的故障会造成整个系统的瘫痪；另一方面，中心节点负载过重，也会影响系统的可扩展性和高效性，如何研究去中心化的大数据管理系统架构，突破单点瓶颈，实现系统的高可扩展性和高效性。iii) 自适应优化。一方面，集群环境下，存储节点、计算节点的硬件能力可能存在较大差异，需要研究异构集群环境下的自适应优化。另一方面，负载任务的多变性和复杂性，要求研究多数据模型下的自适应优化。vi)与其他技术的融合。新硬件技术与人工智能技术的发展，研究如何使用新硬件和人工智能技术，优化大数据管理系统的各个模块，提升系统的可扩展性、可靠性、高效性。
|
||||
\subsection{新硬件与混合架构的挑战}
|
||||
数据管理系统的实现受计算机软件技术和硬件技术以及应用三方面的影响。随着新硬件及各种混合架构的出现，支持数据管理与数据工程的底层硬件正在经历巨大的变革，各类新型加速设备、混合架构出现也在逐渐改变数据管理和数据工程中的设计，并带来了巨大挑战。
|
||||
|
||||
近些年，以GPU为代表的新硬件得到了迅猛发展，越来越多的数据管理与数据工程应用采用新硬件与传统系统相混合的架构，使用GPU等新硬件进行加速。相对于传统数据管理与数据工程相关应用，GPU等新硬件的引入可提供更高的数据处理速度，以及更好的实时处理效果。然而，虽然新硬件与混合架构为数据管理和数据工程提供了新思路，但也带来了一系列亟待解决的新挑战：
|
||||
|
||||
第一，混合架构中的新硬件资源分配。不同种类的新硬件具有完全不同的体系结构特征，适合处理的应用特征也不完全相同。例如，GPU硬件依赖众核的并行提升吞吐量，隐藏访问延迟，往往适合高吞吐量、对延迟不敏感的应用。因此，在数据管理和数据工程中需要尽可能使各新硬件设备处理各自适合的负载，而如何识别出适合新硬件加速的程序进行有效地任务分配是一个不小的挑战。
|
||||
|
||||
第二，混合架构下的数据传输。混合架构中的GPU等新硬件设备往往通过PCIE与传统CPU处理器相连接，由于GPU等新硬件设备具有独立的存储结构，处理数据时需要从主存将数据传输至设备存储中，存在的挑战是如何降低数据传输所带来的性能影响等。
|
||||
|
||||
第三，新硬件下的数据结构与算法。传统的数据管理和数据工程应用所采用的数据结构和算法往往是针对x86系统架构设计的，不适用于GPU等新型硬件。例如，GPU中具有大量的计算核心，存在可以控制的局部缓存，体系结构组织方式也和传统CPU不同，需要使用GPU编程语言考虑硬件特性进行程序设计。此外，新硬件编程往往涉及编程语言的扩展，因此，新硬件下需要有针对性地设计数据结构和算法是一个重要挑战。
|
||||
|
||||
第四，新型存储结构。以非易失性存储器为代表的新介质可进一步加速数据处理的速度，但随着新型存储的引入，数据管理的过程中有可能会涉及多种存储类型，存储的层次结构也可能与以往不同，如何设计相应的数据存储也是数据管理与数据工程的挑战。
|
||||
\subsection{异构数据整理的挑战}
|
||||
数据整理是在挖掘提炼数据价值的过程中需要进行的前期的数据预处理工作。它看似不足轻重，实则非常重要。有调查研究表明，很多大数据分析任务80\%以上的工作花费在数据整理上，这给数据分析带来了巨大的人力成本。很多分析设想因为承担不起前期巨大的数据整理工作而最终被放弃。更重要的是，由于缺少系统性和理论性的支撑，数据整理的质量千差万别，这给数据分析的结果带来了很大的不确定性，大大影响了大数据价值的挖掘与提炼。
|
||||
|
||||
与数据仓库时代的ETL只关注业务系统内的数据不同，数据整理技术通常需要帮助用户将其拥有的数据与外部的一些数据源进行关联和数据融合。融合过程中面临着比较大的数据集成难题，伴随着大量的数据质量问题，如数据项缺失、不一致、重复、错位、异常值等。而很多情况下，这些数据集成和数据质量方面的问题又与具体的应用场景关系密切，很难形成通用的、一体化的数据整理解决方案。需要针对不同问题和典型场景，研究系列的数据整理工具，而这些工具的适用性就面临很多挑战性问题。
|
||||
|
||||
数据准备服务于企业内部所有的数据使用者，以对数据处理技术不熟悉的业务用户为主。这些用户缺少数据管理与数据处理知识，但对业务熟悉，对数据背后的语义更清楚，他们是企业机构大数据价值发现的主力。如何针对这类业务型数据分析人员的需求和特点，提供高效的数据整理工具，是数据整理技术面临的一大挑战。这即包括数据整理工具的易用性，有包括工具在执行数据整理任务过程中的执行性能和被整理后数据的有效性。数据整理工具适用性和易用性之间通常还存在一定的矛盾，如何利用一些自动化的手段，降低用户使用工具的难度，根据场景自动优化配置数据整理工具，会是数据整理面临的一项重要难题。
|
||||
|
||||
数据仓库中的ETL是为了建立数据仓库所采用的相对固定的数据处理流水线。数据处理过程一旦建立，整个过程比较静态，很少再变化。数据整理任务是针对企业业务系统中的问题，动态构建的数据处理过程。它针对具体问题做数据预处理，会随着不同问题采用不同的数据整理过程，虽然一些任务之间可以共享某些数据整理过程。如何优化不同数据整理任务所构成工作流，共享数据整理的知识和经验，避免重复性操作，也是数据整理所面临的较大难题。
|
||||
\subsection{交互式数据分析的挑战}
|
||||
传统数据仓库，可以预先创建好结构清晰的数据模式，分析人员往往对数据模式比较了解，因此分析任务也能围绕数据模式较为清晰的定义出来。但是，大数据的异构性给数据分析带来了复杂性。在很多大数据场景中，异构性等让数据模式变复杂、并且可能在需要经常变化，数据分析人员不太容易预先构建好清晰的数据模式和其上的数据分析模型。在这种情况下，数据分析师往往需要交互式的数据分析能力，需要通过交互认识数据，调整模型和参数，对数据分析的一些假设不断做出调整。这就与传统报表式的数据分析有了很大的差别。交互式数据分析有很多新的挑战：
|
||||
|
||||
首先，要有很好的数据可视化做为支撑。数据可视化能够帮助分析人员简洁清晰地认识数据的重要特性，为调整分析维度、数据范围、模型类型等提供基本的数据和决策支撑。好的结果可视化分析界面，能够帮助用户更好地与数据分析系统进行交互，让分析任务更快地按用户想要的视角和方向而展开。可视化不仅包含结果的可视化，还要能够引导分析人员朝更有利于开展深入分析的方向而进行分析流程的推荐，辅助分析人员更有效地探索数据空间。
|
||||
|
||||
其次，可视分析系统要想做的好，分析处理的性能至关重要。有研究曾表明，秒级以上的交互性能通常会让分析人员失去很多耐心，很难保持住流畅持续的分析工作流。因此，要求用户每次对分析任务进行调整后，新的分析任务能够尽可能在亚秒级完成。这在大数据上近乎是很难实现的，必须从技术层面解决高性能数据分析的需求。常见的技术里，利用新硬件技术（GPU, FPGA, NVM, RDMA等）提速、数据预取与预计算、近似查询等都是提升大数据分析性能的有效手段。
|
||||
|
||||
再者，交互式数据分析的效果评价也是很有挑战的事情。由于交互式分析过程中分析人员往往存在分析目的不明确的问题，分析任务要在交互过程中不断调整，这为评价交互式分析算法和系统的好坏带来很多挑战。很多研究，需要借鉴人机交互领域的一些方法去衡量交互式分析解决方案的效果。因此，交互式分析也是人机交互和数据分析的学科交叉，需要技术和设计两个方面的支撑与紧密结合。
|
||||
|
||||
最后，交互式数据分析的复杂性为分析系统的设计和架构带来了很多挑战。需要在可视化、人机交互、高性能分析处理、数据库等多层面综合考虑，很多环节还需要跨层的紧密结合。该领域的研究难度也比较大，通常只有构建出可用的系统原型，才能够有效验证交互式数据分析算法和系统的优劣。
|
||||
\subsection{数据隐私保护与数据安全的挑战}
|
||||
数据安全与隐私保护问题长期以来一直受到人们的广泛关注。尤其是近年来大数据和人工智能技术的高速发展，数据外包到云平台上的需求与日俱增，各类应用对数据共享的呼声日益强烈，人们日常生活和出行对于基于位置的服务的依赖性逐步提高，这些都使得数据安全和隐私保护问题变得愈加突出和复杂。虽然学术界和工业界在隐私保护与数据安全方面已经取得了一些可喜的进展，但面对大数据的应用需求和应用场景，还是显得力不从心。目前数据隐私和安全问题存在于大数据收集、存储、管理、使用的各个阶段，如何抵御非法用户的恶意攻击和隐私窃取；如何防止数据被非法篡改或删除，导致错误的查询和分析结果；如何避免合法用户利用数据之间的关联关系，通过反复搜索推演出数据隐私；如何防止人们在使用数据服务时暴露自身的偏好、位置、轨迹等隐私信息，都是亟需解决的关键问题，也是关系到大数据应用前景的重要现实问题。这里面的重要技术挑战包括：
|
||||
|
||||
第一，敏感数据的安全存储与检索。大数据促进了云存储和云计算的快速发展，许多公司，如亚马逊，谷歌，微软等，已经加快了开发云服务步伐，大数据系统将数据外包到云平台上已成为一种趋势，但云平台是不可信的第三方，存在隐私数据被泄露、关键数据被篡改等风险，敏感数据在云平台上的安全存储与检索是必须解决的挑战性问题，它制约了云服务的推广与应用。
|
||||
|
||||
第二，数据的安全计算与共享。“数据孤岛”已成为在智慧医疗、金融分析、商品推荐、电商服务等各个领域中存在的普遍现象。对于作为数据拥有者的服务商，在不泄露各自敏感数据的前提下，联合多个服务商进行计算使用是充分挖掘数据价值的迫切需求，也是未来发展趋势。然而各个服务商的敏感数据难以直接透明化共享，以及在使用新技术过程中造成的隐私安全漏洞，都使得数据安全计算与共享成为一个挑战性问题。
|
||||
|
||||
第三，动态数据的安全发布。数据发布是数据服务的一种重要形式，k-匿名、l-多样性等传统隐私保护技术难以解决大数据环境中动态数据发布所带来的隐私泄露问题，差分隐私技术能够对静态数据的统计类信息进行安全发布，但是对于动态持续的数据发布场景，由于数据之间具有关联关系，其隐私泄露问题更加突出和严重，目前还没有有效的解决方案，是一个尚待突破的研究挑战。
|
||||
|
||||
第四，隐私性和数据可用性的平衡。数据挖掘技术能够深入挖掘大数据中所蕴含的知识和规律，使大数据的价值能得到更充分的发挥。但与此同时，即使采用了数据加密、数据加噪等数据保护手段，隐藏在不同来源数据背后的个人隐私信息仍然有可能被分析和推断出来。简单地切断社交网络信息、医疗信息、社保信息、购物平台信息、出行轨迹信息等不同来源数据之间的关联，对大数据系统的可用性和数据价值会造成致命影响，如何在隐私性和数据可用性之间寻求平衡是一个重要挑战。
|
||||
\section{主要研究内容（每一项内容300字左右）}
|
||||
为了应对上述重大挑战，需要在多方面开展研究。这里我们列出了11项研究内容，其中5个属于数据管理范畴，包括分布数据管理(§6.2.1)、云数据管理(§6.2.2)、图数据管理(§6.2.3)、新硬件数据管理（§6.2.4）和内存数据管理（§6.2.5）。另外6项属于数据工程范畴，包括多源数据集成（§6.2.6）、数据整理（§6.2.7）、数据分析（§6.2.8）、数据可视化（§6.2.9）、数据隐私（§6.2.10）和数据安全（§6.2.11）。
|
||||
\subsection{分布式数据管理}
|
||||
由于大数据的管理需求，分布式数据库一直是工业界和学术界的研究重点。分布式数据库应该具备强一致性、高可用性、可扩展性、易运维、容错容灾以及满足ACID属性的高并发事务处理能力。由于受限于CAP理论，即在必须支持分区容错性的前提下，系统实现只能侧重一致性和可用性的一个方面而无法同时满足；另一方面，支持ACID事务属性及高并发事务处理一直是分布式关系数据库的难点。分布式数据库基本是围绕数据强一致性、系统高可用性和ACID事务支持等核心问题展开研究工作。这些性质与系统的扩展性和性能密切相关，甚至相互制约，往往需要根据具体的应用需求进行取舍。很多NoSQL数据库都是放弃支持事务ACID属性来换取性能的提升。近年来，新型数据库（NewSQL）的出现给分布式数据库的发展带来新的方向。它的目标是提供与NoSQL相同的可扩展性和性能，同时支持事务的ACID属性。这种融合一致性和可用性的NewSQL已经成为分布式数据库的研究热点。
|
||||
\subsection{云数据管理}
|
||||
云数据管理以大容量、多类型、快变化、低质量的大数据为管理对象，提供弹性、可靠的与高效的数据存储、组织与存取、查询处理、运行与维护等管理功能。针对多类型特征，研究多模型数据统一管理技术，提供统一查询语言（例如SQL）和编程接口。针对大数据的大容量、快变化特点，从系统容错、数据划分与迁移、去中心化、自适应优化等维度，研究弹性、高可靠、高性能的云数据管理系统架构。针对大数据应用的多样性特点，从分布式系统的强一致性、最终一致性、弱一致性，与分布式事务的隔离级别两个维度出发，研究去中心化的分布式事务处理技术。研究基于新硬件、基于人工智能的云数据管理技术，优化数据存取、查询处理、并发访问控制与故障恢复、系统运维等子系统。研究云计算资源的按需分配和弹性伸缩调整技术，支撑系统的弹性管理。
|
||||
\subsection{图数据管理}
|
||||
针对规模巨大的图数据，按照对图数据管理的抽象程度可以被分成两类。低层次抽象的提供编程接口的图数据管理系统，针对图数据管理中的基本操作设计并实现相应的编程接口，用户利用这些编程接口来实现相应的管理功能；高层次抽象的描述性查询语言，用户将相应的管理需求用描述性查询语言表达，系统解析这些描述性查询语句并生成相应的查询计划来进行执行处理，实现包括图搜索、基于图的社区发现、图节点的重要性和相关性分析、图匹配查询等查询和分析需求。新的研究问题还包括异构计算环境下的图数据管理、多源流式图数据管理、RDF知识图谱构建和推理等。
|
||||
\subsection{新硬件数据管理}
|
||||
新硬件技术的发展为数据管理技术带来新的挑战，也带来明显的机遇。作为系统软件，数据库底层需要针对新硬件的发展做出适应性调整，充分利用新硬件带来的便利，同时避免新硬件自身约束导致的新瓶颈。目前研究较多的新硬件包括高性能和专用处理器、高速网络、和非易失性内存等。针对高性能和专用处理器，数据库底层核心算法需要充分考虑多核并行的能力，重新设计连接、排序等基本操作。图形处理器GPU、现场可编程门阵列FPGA等专用处理器具备更大规模的数据并行操作能力，从而提升数据的向量处理效率，支持数据库内核范围内的机器学习等任务。传统分布式数据库或者并行数据库在高速网络环境中，网络传输不在是瓶颈，需要设计新的分布式连接方法和分布式并发控制策略等。而非易失存储的高速和持久化能力对数据库系统结构层面结合方式和恢复机制等带来新的研究课题。
|
||||
\subsection{内存数据管理}
|
||||
相对于以磁盘为主要存储介质的传统数据库，内存数据库带来多个量级的性能提升，内外存数据交换不再是主要性能代价，而关注CPU特性对内存操作的影响，如CPU中的缓存、指令和数据的预取、共享数据结构等，重点研究上述变化在数据组织、数据索引、事务机制、查询优化等方面的不同。在数据组织方面，内存数据库中数据可以按照其处理器核进行划分，同一个划分中数据操作串行，减少并发控制带来的各种代价；也可以采用所有处理器核都可以访问全部数据的方式。内存数据库索引设计主要考虑索引结点的大小和CPU缓存大小相关,从而在索引操作过程中提升CPU缓存的命中率；同时内存索引结构的设计需要考虑多核环境中的并发查询和更新，减少内存数据结构中并发锁的使用，减低索引维护代价。内存数据库的事务处理和并发控制机制使用多版本并发控制协议，通过保存不同版本从而支持无阻塞高效率的读取操作，或采用乐观并发机制提高效率。
|
||||
\subsection{多源数据集成}
|
||||
多源数据集成，指为多个异构的数据源提供统一的存取方法。多源数据集成需要解决两个核心问题：数据集成的精确性以及查询处理的效率。首先，须研究实体匹配的问题，即判断多个字符串或元组是否对应同一个实体。为此需要定义两个字符串或元组相似度的度量标准，如基于字符序列的度量标准、基于集合的度量标准以及混合度量标准。实体匹配方法还需要具备可扩展性，以处理大规模的数据集。其次，须解决模式匹配问题，其目标是建立不同模式到一个统一的集成模式之间的映射。模式匹配的研究方法包括基于实例的匹配，基于模式信息的匹配，以及混合匹配等。近来的一个趋势是采用机器学习或深度学习方法来提高模式匹配的准确度。最后，多源数据集成还包括查询改写和查询优化。查询改写研究形式上不一致的两个查询是否等价，以及一个查询是否可以在一组视图上执行。数据集成系统中的查询优化重点是自适应的查询处理，即查询处理器可以在运行时动态修改查询计划。
|
||||
\subsection{数据整理}
|
||||
数据整理是为了使数据能够更好地服务于数据分析而对数据进行的审查和转换的过程，它是整个数据分析流程中最占用精力的过程。从技术上讲，数据整理包含了前期数据解析与结构化处理、数据质量评估与数据清洗、数据集成和提纯等过程。由于问题的复杂性，数据整理过程通常不是完全自动化的，而是需要用户介入的反复迭代和交互的过程。数据可视化、用户反馈与交互在整个过程中都发挥了重要作用。如何开展有针对性的研究工作，并系统化地集成各方面相关研究工作，形成数据整理方面整体上的研究和应用影响力？从事相关领域的研究学者应充分利用庞大的Python开源社区PyData，投入系统化的数据准备工具研制中，将研究成果更好地应用在实际场景中，或许是一条较为可行的技术路线。
|
||||
\subsection{数据分析}
|
||||
从系统角度，交互式分析对大数据分析处理的性能要求极高，如何利用好新硬件（如GPU, FPGA, NVM, RDMA等）来加速大数据分析至关重要。在数据分析处理层面，还可以利用用户在交互分析时，需要花时间去理解数据分析的结果，利用这个时间完成数据的预取和预计算操作，把最有可能的下一步分析任务的结果提前算出来，或者采用近似计算方法，给出统计分析结果的上下界，并随着数据分析处理的进行，不断更新计算结果，让分析结果随着用时的增加更为精确。如何根据一些常见的数据分析类型，设计相关的评测基准，让不同交互式数据分析解决方案之间有更好的可比性，也是很值得研究的方向。再有就是解决具体分析任务时，如何设计有效的交互界面，结合数据模式和数据空间的特点，设计有效的数据交互方式，让数据和分析流程都能更好地通过可视化方式，引导用户以较低的代价参与到数据分析的整个流程中。
|
||||
\subsection{数据可视化}
|
||||
数据可视化利用计算机图形学、数据分析、用户交互界面等技术，通过数据建模等手段，为用户提供有效的数据呈现方式。数据可视化能够帮助用户迅速理解数据，定位问题。数据可视化技术可以从不同维度来刻画，如可视化后台的数据类型、不同类型的可视化交互技术等。数据可视化技术的进展通常针对不同的数据类型展开：图数据的海量规模（包括节点和边）以及有限的可视空间限制成为图数据可视化的主要挑战，主要研究侧重于图简化的思路，通过边聚集或者点聚集，构建不同层次的图，同时引入交互策略，支持用户对其感兴趣的部分进一步动态分析；时空数据是包含时间维度和空间维度的数据，其空间维度通常和地理系统进行结合，重点研究采用属性可视化技术展示对象随着时空维度变化，如将事件流和地理流结合的Flowmap、时间-空间-事件等信息的三维立方体方式等；数据仓库中多维数据可视化则着重更加友好呈现数据，利用散点图、平行坐标等方式提高用户对整体分布和不同维度之间关系的理解。
|
||||
\subsection{数据隐私}
|
||||
数据隐私保护技术主要利用以密码学为基础的加密、签名、协议等技术，以统计学为手段的匿名化技术、模糊化技术等，和基于概率分析的差分隐私技术等，为用户数据提供隐私保证。大数据背景下潜在隐私泄露方式更加多元，主要研究内容可以包括以下三方面，一是大数据隐私保护理论，包括隐私定义与搜索能力之间的关系、支持数据隐私的安全搜索机理、隐私保护方法评测基准等。二是数据存储、查询和发布中的隐私保护技术，包括基于隐私识别的数据加密算法、带密检索机制、动态数据的安全连续发布、具有复杂关联的敏感数据反推演策略等。三是数据服务中的个人隐私保护，包括社交网络环境下的个性化隐私度量及保护手段，数据服务中对用户偏好、地理位置、行动轨迹等信息的隐藏策略，及其与服务质量之间的关系度量等。
|
||||
\subsection{数据安全}
|
||||
数据安全的研究主要是利用现代密码学算法对数据进行主动保护，研究内容包括可搜索加密、密文计算、完整性验证、基于属性加密的访问控制和基于角色的访问控制、安全审计、身份验证等，保证数据“专人专用”，防止攻击者或黑客窃取到重要信息。数据安全的研究旨在解决海量数据规模、多样化数据类型给检索和存储带来的巨大压力，比如说通过加密技术解决云服务所带来的敏感外包数据的安全存储与查询问题，以及通过安全计算协议解决大数据环境下人工智能的高速发展所带来的数据安全共享计算的难题，包括优化同态加密、多方安全计算的高昂通信代价等。总的来说，数据安全的研究内容更侧重于在实际应用场景下对敏感数据进行主动保护，同时保证高可用性，探索并设计多种巧妙的、可扩展的轻量级机制与安全协议。
|
||||
\section{本章小结}
|
||||
在“以数据为中心的计算”计算时代，数据在计算体系中的重要性凸显。数据不再是依附软件（业务）而存在的，数据本身可以是独立存在的。这给数据管理和数据工程带来新的挑战和机遇。一方面数据不仅仅支撑业务的运行，即使在业务活动结束后还要继续保存，因此，数据会越积越多，给数据的管理带来挑战。另一方面，数据只有利用才有价值，围绕数据价值的提升，需要有方法学和工具的支撑。
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
|
||||
软件系统已经成为各行各业的重要基础设施，包括单纯的信息基础设施、软件嵌入的物理设备、以及软件提供的服务设施等。可以预计，基于这些软件基础设施，未来的应用软件系统将以面向领域的人机物融合场景计算为主要呈现形式。即应用软件系统将使计算服务嵌入各行各业以及民众生活，使计算从单纯的赛博空间进入人机物融合空间，综合利用人类社会（人）、信息空间（机）和物理世界（物）等的资源，通过协作进行领域特定的个性化计算，实现领域价值。
|
||||
|
||||
人机物融合场景下的软件应用系统，起源于2006年前后出现的信息物理融合系统（Cyber-Physical Systems，CPS），以及更早兴起的物联网（Internet of Things, IoT）。早期研究侧重于网络化嵌入式系统和控制系统等，包含物理资源层、传感网络层、计算控制层、和价值服务层，物理资源层通过传感网络层连接到计算控制层；计算控制层则根据感知获得的事件、日志等，并根据相应的数据处理和行为决策逻辑向外提供服务。这类系统明显的具有面向特定应用领域，实现场景计算的特征，譬如智能交通、工业制造、无人驾驶、健康医疗等。
|
||||
|
||||
CPS与IoT技术的结合，使因特网能感知现实世界，通过和云计算的融合使嵌入式系统与云数据中心及云服务连接起来，进而支持更高层服务和控制的实现，通过与云计算、雾计算及边缘计算深度融合，使能“人”的融入，从而形成了新的应用软件系统形态。随着人的因素在系统运行过程起越来越重要的作用，这类系统逐渐发展出泛在化、社会化和智能化的典型特征。
|
||||
|
||||
图\ref{fig1}给出了这类面向领域的应用软件系统的通用架构。其含义是，第一，应用场景及其各类物理设备、人及其互连关系等形成面向领域的应用软件系统的上下文元素（或场景元素），当出现计算需求时，与需求相关的上下文元素形成与需求对应的上下文。第二，自适应控制层提供场景元素的动态接入/撤出、场景元素的动态发现、场景元素的融合管理、以及场景元素的社会化协同等机制，形成或动态演化出能满足当前应用需求的系统。第三，所组成的应用系统通过和其上下文元素的交互，实现需求所要求的价值。因此，这类应用软件系统可成为面向需求和场景的软件系统，表现出异构多样化设备的可接入、异质构件的互操作、以及个性化需求的可满足性等，系统通过多样化感知设备使能对现实场景的感知和直接的作用。
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{fig2-7/marc.png}
|
||||
\caption{面向领域的应用软件系统元架构}
|
||||
\label{fig1}
|
||||
\end{figure}
|
||||
\section{重大挑战问题}
|
||||
从软件开发方法的角度看，支撑泛在系统开发的途径是软件定义理论与技术，即对每个面向场景子系统中的服务、任务和工作流执行所共需的资源进行抽象、虚拟化和数值化，这些资源包括人、硬件、数据、软件和服务等。在此基础上，设计新的软件系统针对相关资源进行有效管理、控制、协调和优化配置，进而支撑层次化系统之系统架构特征的人机物融合系统，支持各层、各场景中相关服务和任务的高效执行。
|
||||
|
||||
相比于传统软件系统，人机物融合应用软件系统更关注一系列新的性质，包括：
|
||||
\begin{itemize}
|
||||
\item 现实世界的可感知性和实体及资源的移动性：体现为现实世界可感知，感知的实时性和非确定性（概率）等，由于系统实体/资源的可移动性，时空一致性感知和控制成为必须的性质；
|
||||
\item 软件的异构连接性和系统性：其连接性体现为物理构件与信息构件的交互，系统之系统的连接，及其与云服务器的连接等。其系统性体现在子系统的按需分解和组合，以及服务的按需分解和组合等；
|
||||
\item 系统边界的开放性和系统成分间和系统和外界的互操作性：体现为系统构件的动态接入和自主远离；子系统间和不同服务平台间的交互，各类人机交互的共存，及其导致的不可忽略的系统、信息和网络的安全性等；
|
||||
\item 环境状态的动态变化性和系统的自适应性：由于现实世界的变化性以及变化的不可预知性，要求系统具有面向动态行为变化的自适应性，体现为系统的可调节参数、动态可适应接口和动态可配置架构等。
|
||||
\end{itemize}
|
||||
|
||||
其主要挑战性问题包括：如何确定泛在系统的作用边界以及处理边界的可伸缩性（7.1.1），如何采用统一的抽象屏蔽系统成分的异构性（7.1.2），如何解决离散的计算系统和连续的物理系统的耦合性（7.1.3），如何在系统设计和实现中体现使用者的价值观（7.1.4），如何构建系统生态以保证其可持续性（7.1.5）。下面将对其分别进行分析。
|
||||
\subsection{系统边界的可伸缩性}
|
||||
人机物融合系统的环境包罗万象，包括网络资源、存储资源、数据资源、计算资源、传感资源等海量异构资源，它们连接起来实现万物互联。通过软件定义把资源虚拟化，再通过软件系统对虚拟资源进行管理和调度。在硬件资源虚拟化的基础上，用户可编写应用程序，通过系统调用接口，访问资源所提供的服务，更重要的是能够灵活管理和调度资源，改变资源的行为，以满足应用对资源的多样需求。简而言之，就是更多地由软件来驱动并控制硬件资源。通过软件定义，实现需求可定义、硬件可重组、软件可重配、和功能可重构。
|
||||
|
||||
由于人们一直追求更高更好的设备性能，未来的标准或新算法不断地需要嵌入到系统中，系统需要更强的处理能力和更多的资源来完成功能，软件定义应当能够适应这种变化。增强系统适应性需要伸缩性作保证。伸缩性一般指在软件或硬件中增加或减少模块,以增强或降低系统性能的自适应能力。在同一个逻辑单元内增加资源来提高处理能力。或者增加更多逻辑单元的资源，并令它们像是一个单元一样工作。由此可见软件定义为软件系统划分了新的边界，同时软件定义也加剧了边界的模糊化。
|
||||
|
||||
伸缩性需要可重构性支持。伸缩性保证嵌入新功能的能力而具体的实现由可重构性保证。具有先进可重构性的系统要求伸缩性良好，伸缩性良好的系统需要完善的可重构性。重构性，即系统功能随着需求改变的能力，也可称为可编程性。外在需求的变化往往在速度、种类、方式上都有比较大的幅度，需要系统能根据需要及时做出较大的改变。这对单纯的硬件来说，各方面的难度都太大。
|
||||
|
||||
模块化对可重构是一个支撑。将定义系统的各个任务分解为相互独立的软件和硬件模块,这些模块通过接口以逻辑的方式连接起来形成所需要的系统功能。物理资源池通过专业的配置，实现灵活的调整、动态的分配与可编程化的配置，使其具有了模块化的特征。模块化系统可以通过增加或替换模块动态改变功能，而不会与系统中其它模块产生冲突。模块间定义良好的接口有助于增强模块化系统的设计。
|
||||
|
||||
为了对可重构性的适应，系统应能够被精确配置成各种不同的虚拟设备，可以支持不断涌现的新技术和新功能。在嵌入新技术和支持新功能时，如果系统不够灵活，系统结构就必然要推倒重来，系统可重构的优越性就会随之丧失，也就不能称作是软件定义。
|
||||
\subsection{系统成分的异构性}
|
||||
随着软件系统外在形态在空间上的演化，特定领域的软件系统通过“云-边-端”一体化的形式连接融合“人-机-物”，形成泛在网络计算平台。在该平台下，软件系统从单一资源按需管控变为多种类、多粒度资源的随需协同管控。软件系统将包括物理资源、计算资源和人力资源等异构资源，它们将被抽象为面向人机物三元融合的泛在资源，并进行管理。具体而言，在系统成分上，物理资源包括被计算的物理设备实体和用于信息采集的传感器设备；计算资源包括AI构件、传统软件模块和外部逻辑部件如芯片、GPU；人力资源主要指可抽象与编程的具有社会属性的用户。虽然软件系统的泛在资源管理为特定领域的标准化、模块化、平台化和智能化带来了可能，但软件系统成分的异构性却为特定领域软件系统的开发带来新的挑战。
|
||||
|
||||
在异构资源整合与调度层面，特定领域软件系统需在理解异构资源在语义层和应用层上行为差异的基础上，对广域分布的异构资源进行整合，形成异构资源监测、分析、计划和执行的闭环领域问题解决方案。由于特定领域软件系统在“人-机-物”融合方面的复杂性，以及不同硬件设备、AI构件等的内在特异性，需要面向特定领域对软件系统进行按需构造，根据特定的领域需求，对异构资源进行合理选择与智能调度，形成需求驱动的异构资源调度、部署、迁移、卸载的资源管理模式，保障软件系统在跨领域迁移方面的无感迁移和快速汇聚。
|
||||
|
||||
为了达到上述目的，需考虑面向异构资源的系统体系结构设计，以异构资源为基础对特定领域的软件系统的体系结构进行动态调整；需解决异构资源的统一建模问题，利用软件定义思想对异构资源进行虚拟化，完成异构资源的功能划分、建模与封装，实现异构资源的解构与重构；需要解决基于场景需求的系统构件选择问题，对特定领域进行场景分析，根据特定领域的性能需求、安全需求、智能算法需求对异构资源进行动态选择，形成面向需求的控制模型，建立功能（再）编排及实施机制与运行时调控机制；需设计人机协同的交互式系统构造方法，从“人-机-物”融合为出发点，根据特定领域场景需求和“人”的反馈对已整合的异构资源进行动态添加与卸载；需研究系统构件的接口适配与集成方法，能够将不同的异构资源进行无缝衔接，并根据领域特性对资源进行持续演化。
|
||||
|
||||
在异构资源编译与优化层面，特定领域的软件系统需考虑异构资源的计算能力，将整合的资源进行按需编译与优化，使软件系统支持以“人”为中心的高效“人-机-物”智能决策，形成面向高动态复杂场景的“人-机-物”融合智能编译机制。在该编译机制的基础上对领域数据、系统资源、交互对象进行动态优化，达到面向异构硬件/异构智能处理框架的全栈优化，以及智能化数据分析，和“人-机-物”融合的软硬件协同优化的目的。但由于异构资源运行时的复杂性和异构资源潜在的平台、环境依赖性，会给特定领域软件系统的生产、流通带来影响。
|
||||
|
||||
为了能够完成异构资源的编译与优化，需要建立异构资源的统一协同开发模式，对人机物融合系统所涉及的多种环境及硬件设备，建立统一的开发模型，在异构资源整合的基础上面向应用需求对异构资源进行高效开发，保障特定领域软件系统的开发效率和质量；需解决面向特定领域的全栈编译优化问题，根据领域场景建立异构资源的编译容器，建立“人-机-物”资源的协同编译模式，并通过分析领域特点，对软件系统进行面向编译序列的优化、链接时优化和反馈式编译优化；需保障构件系统的编译一致性，在领域场景快速切换和持续演化的过程中，保障编译结果的可重现、可持久化；需完成基于构件的泛在系统质量度量与提升，以运行效率、系统能耗等为目标对软件系统进行动态优化和智能编译，实现编译结果和优化策略的可测试、可验证。
|
||||
|
||||
最终形成，在异构资源虚拟化基础上的智能软件系统，完成软件系统的自治感知变化、自动需求分析、解决方案自动生成、自适应编译优化、和智能实施管控。
|
||||
\subsection{系统模型的混成性}
|
||||
人机物系统通过集成人、计算单元和物理对象的各自优势，以提高系统的计算分析、精确控制以及感知能力。例如，与飞行员存在交互的电传操纵飞行控制系统，与驾驶员存在交互的驾驶辅助系统，以及与医生存在交互的智能医疗系统等安全攸关系统。如何对人机物系统建模及其正确性证明是一个亟待解决的问题。
|
||||
|
||||
与一般的信息物理系统不同，人机物系统的正确执行很大程度上依赖于人与自主组件之间的交互接口。鉴于人机物系统中人、计算单元和物理对象高度集成交互的特性，传统的混成系统框架下的形式化建模、分析与验证方法已不再适用于复杂的人-信息物理系统。为此，需要研究新的面向人机物系统的形式化建模、分析与验证方法。
|
||||
\begin{itemize}
|
||||
\item 人机物融合软件系统的建模。分析人机物系统与经典的信息物理系统之间的特征差异，在采用混成系统刻画连续变化的物理层与离散变化的决策控制层之间交互过程的基础上，增加人的操作和人机交互的形式表示，形成完整的人机物系统的形式化模型；分析人机物系统与经典的信息物理系统之间的功能需求差异，构建人机物系统的功能需求形式描述。
|
||||
\item 人机物融合软件系统的验证。鉴于人机物系统与外部环境存在交互的特性，分析人机物系统和功能需求的不确定性，研究如何利用经验数据构建数据驱动模型，以对人机物系统模型进行迭代修正，提高验证结果的精度。
|
||||
\item 人机物融合软件系统的控制策略综合。分析人机物系统中控制器与不确定环境间的反应特性，以功能需求为制导，研究控制策略综合方法；构建反例制导的构造即正确的控制策略综合方法。
|
||||
\item 人机物融合软件系统协同机理与模型一致性。研究以人为中心的信息物理系统三元协同机理，分析基于社会科学理论建立的社会计算系统模型与基于信息科学理论建立的信息物理系统模型的一致性，建立协同一致的人机物融合模型。
|
||||
\end{itemize}
|
||||
\subsection{系统能力的价值性}
|
||||
随着软件系统外在形态在时间上的演化，软件系统需随上下文环境及用户需求不断变化、适应和演化，并持续成长、创造系统价值。软件系统的价值体现在将特定领域的真实世界与虚拟世界进行融合的能力，并形成实时感知、动态关联、智能决策、和“人-机-物”交融的交互模式。在这种模式下，特定领域的软件系统应体现人文关怀，从个体用户和群体用户的利益出发，感知用户需求，自主优化系统结构，为用户提供持续性的服务，最终创造软件价值。具体的，在获取用户对物理世界的关键结果和掌握“人-机-物”交互情况后，软件系统将用户意图转换为控制信号，以此为据制定决策，并将决策结果反馈给物理世界，最终形成以软件系统为载体，以“人”为第一负载，面向应用场景和用户实体的软件系统服务模式，达到在自主无人系统、流程工业管理、复杂控制系统、智慧城市系统等方面提供服务、创造价值的目的。由于在特定领域下，软件系统已形成了一个具有多人、多机、多物组成的动态开放网络社会，此种社会模型为软件系统的服务模式设计和系统安全保障带来了挑战。
|
||||
|
||||
在软件系统的服务模式设计方面，需要针对特定领域的软件系统互操作、互理解和互遵守的全新交互方式，建立以通信为基础，支持“机-机”互理解、“人-机”互理解，并且遵守物理规则、信息规则和社会规则的服务模式。需要解决领域场景抽象和用户画像建立问题，从整体的角度对用户进行协同过滤与分类，同时从个体的角度建立可定制化的用户需求模型，将用户的需求转换为具体的软件系统逻辑，根据用户需求分析用户的行为模型，预判能够为用户提供的软件服务；需解决面向价值的软件系统架构设计问题，针对全新的软件系统组成方式和运行模式，实现动态可扩展的、覆盖“云-边-端”一体化的软件系统架构，使软件系统架构根据特定领域场景和客户需求动态变换和持续演化，并支持基于认知主体的自主协同和动态可编程调度机制，最终达到软件系统按需提供服务、服务价值具有可持续性的目的；需实现用户需求的精准分析和实时满足，将用户数据与软件系统决策数据通过用户的反馈形成闭环，利用以己推人和以人推己的方式，精准产生满足用户需求的决策，并根据用户的反馈实时优化系统决策模型，做到感知人、测试人、和分析人，最终体现出软件系统精准的提供用户服务的能力。
|
||||
|
||||
在软件系统的安全保障方面，为了确保面向场景和用户价值的软件系统可持续提供用户服务，特定领域的软件系统需要具有可信性和安全性。具体而言，可信性要求软件系统的开发、运行、维护、使用等过程能够采取有效的措施和方法确认其满足人们的普遍要求、期望、和价值取向；而安全性要求软件系统具有持续不断的运行、发展能力，并在面向各种突发异常事件的情况下，仍能够提供令客户满意的服务能力。为了达到这个目的，需要解决面向“人-机-物”融合的不确定系统状态下的软件系统可验证问题，建立软件系统需求、设计、开发、测试、维护全流程的质量保障机制，提升软件系统持续提供服务、创造价值的可信性，特别是提升在面向AI构件和概率输出结果下的软件服务的可信性；解决面向复杂领域环境的软件系统韧性保障问题，实现终端服务的质量保障，建立状态保持的服务接替抗毁机制，同时确立面向复杂、不确定环境的资源持续保障机制，确保软件系统的可持续提供服务的能力；解决特定领域软件系统的安全性问题，提升软件系统保护用户数据和系统数据的能力，以及抗攻击的能力，能够做到对用户敏感数据实体以及数据交互过程的可跟踪、可防护、可实时安全保障。
|
||||
|
||||
另一个方面，随着软件系统复杂程度的不断增长，不同用户，在不同的场景下，对系统存在不同的需求。而系统应该着力帮助满足不同用户个性化的需求，实现客户的价值。以智慧城市中的知识库系统为例。此系统的目标是将分散在不同信息系统和专家头脑中的知识集中表达和管理，并为不同的智慧应用提供知识检索、推理的服务。然而，智慧城市中存在大量的应用，不同应用对知识的诉求存在明显的差异。例如：城市规划类应用，由于涉及城市建设的重大决策，其对知识的可信性要求很高，只有来源可信（如：从权威机构发布数据中抽取的知识）、推理可靠（基于高置信度的推理方法获得的新知识）、经过交叉验证（不同来源的数据彼此验证一致）的高可信度知识才能使用。而城市服务设施推荐类应用（如：向个人用户推荐景点、餐馆的应用）则更希望利用数量更加丰富，从社交媒体或本地论坛的用户生成内容（UGC）中萃取的知识，而对知识的可信性要求相对较低。考虑到不同应用对知识的诉求存在差异，城市的知识库系统应该建立知识可信性评估机制，并为不同场景、不同用户（或应用）提供满足其价值取向的，个性化、差异化知识检索服务。
|
||||
\subsection{系统生态的持续性}
|
||||
在人机物融合的信息技术应用场景中，大量的物理设施、信息系统和人（或组织）频繁交互，形成复杂系统。为了使此复杂系统能够良性发展演化，应该从系统、参与者、政策环境等多个维度综合考虑智慧城市生态系统的建设和培育，使不同层次、不同功能的软件和具有不同资源和诉求的参与者能够在智慧城市的统一背景下，形成各展所长、相互支撑、共同发展的共生格局。
|
||||
|
||||
在系统维度，应该针对特定领域软件系统的特点建立顶层设计。以智慧城市系统为例，从抽象层次上分为信息资源管理、领域知识服务、开发运行支撑、智慧应用等多个层次；从业务领域上，分为政府规划管理、公共服务、商业服务、民生服务等多个应用领域。不同业务领域之间建立系统化的数据开放共享和业务功能协同标准。在参与者维度，应该设计一套便捷的协作机制，使拥有不同资源、具有不同能力的系统开发、运营、应用、评估管控机构，以及系统的用户可以高效的沟通、协同，在达成各自目标的同时，也帮助其他组织或个人达成其诉求。在政策环境维度，应该围绕数据开放共享、信息资源授权、知识产权保护、安全隐私保护等方面，建立促进系统繁荣发展的政策环境。
|
||||
\section{主要研究内容}
|
||||
人机物融合系统应用场景已经开始呈现或者成为愿景，比如智慧城市系统、智能制造等，如何从理论和技术上支持这类领域特定的应用系统的设计和构造，存在大量值得研究的问题。根据上述挑战性以及典型应用场景，本章提出如下亟需研究并解决的问题。
|
||||
\subsection{环境建模及其软件定义方法}
|
||||
系统边界可伸缩（7.1.1）意味着系统和环境的无缝链接，在系统运行时系统和外部环境的边界将根据情景发生变化。因此，环境模型是系统能够对其边界进行动态调整的基础，支持环境实体的动态接入和系统边界实体的游离。如何构建即具有足够表达能力，又能支持有效推理的环境模型，并通过软件定义方法成为系统成分是一个重要研究方向。与此相关的研究问题包括：第一，系统环境本体和环境元模型的构建，模型制导的环境实体识别和表征，环境实体的动态性和不确定性建模和表示；第二，容忍不确定性的系统上下文识别和推理，需求驱动的系统上下文定位和适应机制；第三，系统上下文特征到系统行为特征的追踪关系，系统行为特征到系统结构特征的追踪关系等的构建，基于这些追踪关系的系统特征和行为的推理；第四，由于系统边界的开放性，系统自适应安全（Security\& Safety）的建模和分析非常重要，如何抵制和应对外界对系统的干扰，以及保证不对外界产生干扰也是自适应系统期望具有的能力，并协调权衡其它重要的非功能需求，也是一个十分重要的问题。
|
||||
\subsection{模型驱动场景感知和认知}
|
||||
系统边界可伸缩（7.1.1）使人机物融合应用场景展现出不可预知的动态性，为了使场景变化的情况下系统也能完成场景的实时感知，需要研究场景的建模和模型驱动的场景感知和认知。具体研究内容包括：第一，针对系统交互环境的特性（特别是环境的变化性特征）以及系统与环境的交互特性两个方面进行研究，然后研究环境特征、环境的变化性特征、以及交互特征中可能蕴含的软件自适应需求，识别和提取自适应需求的模式。拟采用的方法和技术包括：含模糊因子和具有不确定性表达能力的需求表示、可变性建模、需求模式、开放系统架构等。其中的挑战性问题包括：软件环境主要由什么样的对象实体组成？什么建模机制可以容忍开放、动态、变化的软件环境？如何表示环境的动态变化性？如何应对环境实体和交互现象的不确定性？不同类型的环境对象和环境交互及其特征可能蕴含哪些自适应需求？等等
|
||||
\subsection{异构资源的统一表示和封装}
|
||||
针对系统成分的异构性（7.1.2），需要提供异构资源的统一表示和软件定义方法，研究资源的统一封装机制，以便于系统的资源的统一管理和调度，支持实现在纵向上根据应用需求进行底层资源的弹性可伸缩调度及分配并进行性能优化，在横向上打破传统应用 “资源孤岛” ，实现灵活方便而又安全隐私的互连互通。其研究问题是，如何抽象人类社会（人）、信息空间（机）、物理世界（物）三元世界的资源；如何支持响应需求的动态资源、具备规划、决策、学习能力的、集成了软件、硬件、数据资源复合的智能体资源等。具体而言，在硬件资源管理方面，需要研究面向新型硬件资源的抽象表示和驱动、泛在网络中人、机、物间的新型消息标准；在任务管理方面，需要研究软件定义的资源重构能力抽象；在数据资源管理方面，需要研究面向新型存储设备的存储层次重划分、语义背景数据的抽象、内存计算新器件的抽象等；在软件资源管理方面，需要研究云-边-端融合环境下软件包抽象等。异构资源统一管理的关键研究问题，是资源能力的抽象，研究以知识建模为基础的异构资源抽象，以知件为载体对异构资源进行其静态和动态模型的封装，从而通过知件的管理和调度实现异构资源的管理和按需调度。
|
||||
\subsection{服务需求模式及其在线感知}
|
||||
针对系统能力的价值性（7.1.4），如何认识并建模人机物融合环境中的新型应用，这些应用呈现出泛在化、社会化、情境化、智能化等新型应用形态与模式，需求多样且多变。如何设计面向人机物融合应用系统的软件定义方法和语言，给出人机物资源的数据与控制解耦机理、资源编程接口智能化生成与运行模型技术以及场景化资源编程与执行模型技术。通过最终支持更好地凝练应用共性，更有效地管理资源，并根据频繁变化的应用需求和动态多变的应用场景对各类资源作按需、深度、灵活的定制。需要研究人机物融合应用的多种多样的领域和场景的抽象，包括数据规模巨大、突发性强、实时性高的基于云计算的泛在效用计算，对资源需求的动态性、不确定性很强的应用的智能应用场景，以及移动性强、承载设备多、续航要求高、迭代快的智慧城市、工业互联网等领域的协作计算场景等，从而实现对服务需求模式的在线感知。
|
||||
\subsection{系统学习赋能机制及性能确保}
|
||||
一方面，系统能力的价值性（7.1.4）除了表现为需求的可满足性外，还体现为系统能不断提升自身的能力以满足不断涌现的新的需求，系统学习赋能机制成为必需。另一方面，系统成分的异构性（7.1.2）方面，除了异构资源外，系统计算部件页存在异构性，其中涉及数据驱动的AI构件，等等。这些机制和计算部件的设计和性能确保是亟待解决的问题，同时需要针对学习赋能系统的安全性隐患，研究学习赋能系统的安全性设计方法，提高对学习赋能系统的安全验证能力，构建确保安全的学习赋能系统的运行环境。
|
||||
|
||||
具体而言，第一，需要研究学习赋能系统的抽象方法和软件定义方法。要设计既能形式化描述，又能尽量反映学习赋能系统行为的规约是一个具有挑战性的问题，要从不同方面对学习赋能系统进行规约。第二，需要研究学习赋能系统的组合式设计。研究集成AI构件的系统层设计方法上，在AI构件规约的基础上，通过合理安排系统架构，集成AI构件和传统逻辑构件，并确保集成系统具有整体安全性。第三，研究学习赋能系统的验证。设计既能够处理大规模AI构件又具有较高精度的验证技术，同时，除了验证技术本身，研究考虑了验证需求的AI构件设计技术等。第四，研究学习赋能系统的运行时确保。针对未能完全验证的AI构件软件，需要研究运行时确保机制，提供有良好检测机制，能及时发现AI构件异常的检测机制。
|
||||
\subsection{异构模型的融合和验证}
|
||||
人机物融合系统需要与物理世界实现无缝融合，从系统行为和行为建模的角度，这类系统涉及多种计算现象，系统模型呈现异构性，即系统模型的混成性（7.1.3），并具有高度随机性和不确定性，是复杂的异构系统，系统的行为需要根据环境的改变进行动态调整。这些全新的特征引出了如下亟待研究并解决的问题。第一，研究跨领域的人机物融合系统建模方法，研究能够描述这种复杂异构系统的规范逻辑。第二，为应对人机物融合系统通过感知环境、通讯及控制结构实现的高度并发性、实时性和高度不确定性，研究人机物融合系统的异构模型的融合，及其综合分析和测试技术。第三，人机物融合系统的形式规约常常表达为复杂的时序性质，需要研究的系统的复杂性质分解技术，以及基于性质分解的验证技术，通过将性质划分及分解到安全、活性、公平性性质，进而研究相应高效验证算法。
|
||||
\subsection{空间分布系统的的时空一致性}
|
||||
有一类人机物融合应用场景，其系统成分是空间上可移动的，移动的物理约束给系统提出了一类新的约束，即时空一致性，其强调系统在规定的时间到达或者只能到达指定位置，并能在规定的时间内完成指定的任务。时空一致性约束引入了很多新的研究问题，包括，（1）研究这类带时空一致性的人机物融合系统的时空一致性表示的规范语言，支持 对系统的时空一致进行规范性描述， 准确表达时空一致性需求；（2）研究能描述时空一致性的时空时钟， 以及基于这时钟的逻辑系统， 以支持时空一致性分析和模型验证；（3）研究不确定场景下，系统与环境的交互过程中的动态时空一致性问题，包括量化的时空一致性等， 支持带时空一致性需求的系统自动适应能力，从而增强系统的健壮性和可生存性。
|
||||
\subsection{数据驱动的流程控制}
|
||||
人机物的无缝集成应用中，一个不容忽视的问题是物理世界产生的海量信息的实时采集、处理和利用，从而体现其价值性（7.1.4），成为推动科技创新、经济增长和社会稳定的重要力量。实现流程工业管理的网络化、一体化和智能化是优化整个价值链的方法，也是提升竞争力实现业务价值的途径。典型场景是工业物联网和智能制造。
|
||||
|
||||
需要研究的主要内容包括，第一，实时准确的信息感知和数据采集。流程工业生产过程优化调控和经营管理优化决策需要准确的信息，其难点是如何实现从原料供应、生产运行到产品销售全流程与全生命周期资源属性等的快速获取与信息集成，包括原材料与产品属性的快速检测、物流流通轨迹的监测以及部分关键过程参量的在线检测等；第二，生产运行监测和动态优化决策能力。由于流程生产计划的不确定因素众多，原料采购价格和市场需求多变，其核心需要解决如何深度融合市场和装置运行特性知识，进行实现从以计划为基础到以优化决策为基础的管理模式上的变革；第三，高通量时序数据全生命周期管理、传输和利用。工业物联网的数据采集、管理和利用涉及跨越“云-网-端”三层体系架构，终端层需要支持高性能的写入、高压缩比的存储以及简单查询。场控层需要配备高效丰富的时间序列查询引擎。数据中心层需要能与大数据分析平台无缝集成，支持时许数据处理和挖掘分析；第四，以软件为中心的生产全流程自动协同控制能力。软件系统需要支持将物质转化机理与装置运行信息等的深度融合，建立过程价值链的表征关系，支持生产过程全流程的自动协同控制与优化；第五，生产过程故障诊断与环境安全监测和预报能力，研究重点在于通过软件系统并集成实现传感、检测、控制以及溯源分析等技术，实现模型与数据驱动的流程工业过程中，运行工况的故障预报、诊断与自愈控制，以及生产制造全生命周期安全环境足迹监控与风险控制。
|
||||
\subsection{跨域信息互通机制}
|
||||
人机物融合在智慧城市应用中，展现出跨地域、部门或系统的边界的特性（7.1.1），体现为城市信息空间、物理空间和社会空间的深度融合。它以向城市管理者提供城市规划管理的支持，向市民提供泛在、周到的智能服务等为目标，提供支持基于跨域信息互通的智慧服务的共性基础支撑平台，通过协作形成各展所长、相互支撑的共生生态系统。
|
||||
|
||||
主要研究内容包括：第一，城市信息资源互操作与管理系统。研究针对特定跨部门、系统的应用场景的系统集成和协同机制，建立城市信息资源互操作与管理系统，一方面打破城市各孤岛系统的壁垒，建立数据共享开放、功能协同的机制；另一方面，实现对城市各类信息资源的统一索引、授权、监控管理，促进基于语义的资源大规模共享与协同。第二，建立基于众包的城市感知与应用平台。具体包括，一是研究基于众包的城市感知，也叫做移动群体感知。建立基于人群移动性及其各类手持设备城市场景感知、计算和通信等的能力，形成基于人类智能的“综合感知终端”。二是研究智慧城市跨应用的共性知识的知识萃取与演化方法。城市知识萃取与演化包括三方面能力：(a)领域知识模型构造能力，将分散在信息系统和专家的头脑中的知识集中为一个统一、一致的知识模型与知识库；(b)领域知识模型演化能力，更新知识模型，保持模型内部的一致性，实现知识模型随城市发展的自适应演化；(c)知识可信性评估能力，从溯源、推理、传播、交叉验证等多种渠道，评估知识的可信性。三是研究基于众包的智慧应用开发方法和支撑平台。面向城市中智慧应用多样、本地化、个性化的需求，促进具有不同资源、能力的开发者密切合作，在基于互联网的众包应用开发平台的支撑下，实现大规模协同软件开发。
|
||||
\section{本章小结}
|
||||
本章涉及未来与领域应用相关的软件系统，提出了三层系统架构的参考模式，以显式表达领域应用的系统观、价值观和生态观，分析了面向领域应用的软件系统在方法学上的挑战，并指明了典型领域软件系统的主要研究方向和研究内容。
|
||||
|
|
@ -0,0 +1,169 @@
|
|||
|
||||
软件学科是一门工程技术型学科，质量自从软件诞生之日起就是被关注的重点。经典的软件质量核心价值观强调“绝对正确”，涵盖了正确性、易用性、高效性、可靠性、鲁棒性、（易）理解性、维护性、复用性、移植性、测试性等一系列属性，强调在客观证明基础之上形成对软件质量的客观认识。
|
||||
|
||||
在“软件定义一切”的时代，一方面人机物融合应用场景使得软件的使能空间被进一步大幅度扩展，导致软件系统的规模和复杂性进一步增大，软件开发和演化的成本进一步上升；另一方面动态开放的运行环境使得安全性成为十分重要的质量属性，专门针对性的保障措施成为迫切需求；进一步，由于软件日益成为实现应用价值的核心载体，各类利益相关者的价值实现被纳入软件质量属性的范围。由于受到可投入成本的限制，人们越来越清楚地认识到在客观证明基础之上形成对软件质量的客观认识是现实达不到的理想目标，因而软件质量的核心价值观转变为强调“相对可信”，即在客观证据（包括部分客观证明）的基础上形成对软件质量的主观判断。
|
||||
|
||||
在建立价值观的基础上要进一步建立各类软件质量保障措施，也即围绕各类软件质量关注点提供解决问题的方法和技术。从系统观与生态观的角度看，软件质量的考虑涉及更宽广的范畴。例如，从系统工程的角度看，如何在经济可行条件约束下通过综合集成的方法，用可担负质量的部件实现高质量的系统。又如，如何认识在软件生态系统中质量的依赖与传播规律；考虑到软件生态中各类利益相关者的价值差异和冲突，软件及其服务的质量如何取舍权衡等等。以上内容相关的质量保障措施值得进一步研究，但由于篇幅有限，本章主要关注以下更加迫切、更具挑战性的软件质量与安全保障问题。
|
||||
|
||||
随着软件质量的核心价值观从“绝对正确”转变为“相对可信”，可信软件的度量与评估成为软件质量保障的基础性挑战问题。随着人机物融合程度的加深，实时混成、云端融合、复杂异构、动态聚合、智能适应等非经典需求与应用场景层出不穷，软件系统设计、实现和运行过程中需要采用更具针对性的质量保障措施。大规模复杂系统的安全保障变得更重要但又更困难，迫切需要新的技术突破；确保物联网软件安全上升到了国家安全高度，亟需系统深入的研究工作。特别地，数据驱动的智能软件日益成为一类重要的软件形态，不同于传统软件，这类软件基于概率化的归纳推理来实现智能行为，对各类不确定性的驾驭是其内在的要求，如何有效评估和保障这类智能化软件系统与服务的质量也是亟待研究的问题。
|
||||
|
||||
\section{重大挑战问题}
|
||||
|
||||
软件质量与安全保障面临的重大挑战问题主要集中以下几个方面：一是在人工智能时代，数据驱动的智能软件系统因为依赖于外部数据、内置模型等鲜明的新特性，如何才能有效保障其质量；二是可信增强，人机物融合场景下的规模化、定义化的软件系统，如何才能将针对传统静态、封闭、开发阶段的可信度量、评估和增强技术，支持动态、开放、演化的软件；三是软件与系统安全，现阶段遇到的挑战主要在于如何针对大规模复杂软件系统和无处不在的物联网软件，有效检测安全缺陷或漏洞，并通过构建准确、高效的缺陷修复技术及漏洞防御机制保障安全。
|
||||
|
||||
\subsection{数据驱动的智能软件系统质量保障}
|
||||
|
||||
越来越多的软件系统采用人工智能技术基于大规模数据分析进行计算、推理及决策，即综合利用统计分析算法、数据处理、并行计算等技术，从海量、多态的数据中，挖掘知识、实现数据价值的最大化。随着数据驱动的智能软件系统越来越广泛地应用在工业生产、社会生活、金融经济、行政管理的方方面面，其可靠性、鲁棒性、安全性等问题如不能有效地加以防范，将造成重大损失甚至灾难性后果。与传统软件相比，数据驱动的智能软件系统在高度复杂的数据依赖、软件行为不确定性、计算结果鲁棒性方面，对质量保证研究提出了新的挑战。
|
||||
|
||||
(1) 数据和模型质量成为瓶颈。数据驱动的智能软件系统中，往往以数据为核心，围绕数据的处理、分析、挖掘、学习等各种任务设计算法，被称为“面向数据编程”的模式。因此，与传统软件侧重“逻辑正确”不同，数据和模型的质量是数据驱动的智能软件系统可信性的基础和关键。一方面，数据的质量难以保证，噪音会严重干扰模型的有效性；另一方面，鉴于认知系统和认知过程的复杂性，模型有可能不完整、不精确、模型假设存在偏差，算法应具备一定的鲁棒性，不受模型中噪音的干扰，给出可信的决策结果，在数据分布特征等方面，训练数据集与实际应用或是预期的数据集可能存在不一致性，即数据集偏差、歧视、或是样本迁移问题，直接影响模型的可靠性。数据和模型的错误和失效，将造成智能算法判断和决策错误、软件失效。
|
||||
|
||||
(2) 数据依赖严重且依赖关系复杂、多变，软件行为难以预测。数据驱动的智能软件系统数据、模型之间存在着错综复杂的依赖关系，这些依赖关系可能是隐形的、间接的、动态多变的，数据、模型依赖及其与代码之间的相互关联难以分析和维护，错误难以定位和隔离。相比于代码分析，数据、模型和代码之间依赖和追踪关系的研究还非常有限，尚缺乏有效的技术和工具。由于程序逻辑高度依赖于数据，算法对数据、模型的变化敏感，基于概率分析和动态学习的决策过程，使得软件行为具有很大的不确定性。
|
||||
|
||||
(3) 数据驱动智能软件系统的异常监控和容错。运行在安全关键场景下的数据驱动的智能软件系统一旦出现质量问题，将会导致严重后果，例如，无人驾驶汽车的识别错误时将会导致事故。如何通过有效的手段，监控系统运行时的数据和行为，及时预判系统行为异常，以便采取有效措施，保障系统能够正常运行。进而，如何通过相关容错手段，确保数据驱动的智能软件系统在运行时出现故障的情况下，保障系统的行为符合预期。
|
||||
|
||||
\subsection{人机物融合场景下的软件系统可信增强}
|
||||
与传统系统不同，人机物融合场景下的软件系统将计算部件与物理环境进行一体化整合，将大量独立的异构设备（及其数据）进行智能化的连接，并针对当前系统、场景等的实时变化根据任务需求对计算逻辑，乃至系统架构进行自动调整与配置。这样，计算设备可以更精确的获取外界信息并做出针对性、智能化的实时反映，从而提高计算的性能与质量，给出及时、精确并且安全可靠的服务，实现物理世界与信息系统的整合统一[20]。显然，列车、电网、航天等典型安全攸关系统均具有鲜明的人机物融合特质。如何对相关系统的可信性进行保障对相关系统的正确运行具有重要意义。然而，在人机物融合的场景下，相关异构、组合、动态等特性也给系统行为可信保障带来了新的挑战与需求。
|
||||
|
||||
(1) 人机物融合场景下组件间将进行频繁的通信、合作与协同，去完成复杂的任务。因此，相关系统是一个典型的组合系统。长期以来，对大规模组合系统进行分析、测试、验证一直是相关领域难点所在。此外，由于在人机物融合场景下不确定性、概率性行为、实时连续行为越来越常见。如何在建模阶段对随机、不确定、连续行为进行描述，并在分析中对相关行为进行研究，也是对相关复杂不确定系统进行可信增强的一个重要挑战。
|
||||
|
||||
(2) 相较于一般静态可预测系统，人机物融合场景下系统行为更加强调于实时捕获、采集环境或者其他协作成员的运行时参数，从而进行自身策略，乃至组件间拓扑结构的智能化调整。在开放环境下，相关外界参数取值随时间变化，难以准确离线刻画。因此，从传统的静态测试、分析、验证等角度出发，难以遍历枚举相关开放动态行为中可能出现的所有场景，无法给出完整状态空间描述与安全保障。在此情况下，如何从运行时监控角度应对开放环境带来的连续动态行为是相关领域重要关注问题。
|
||||
|
||||
(3) 从系统观来认识人机物融合系统，我们会发现在人机物融合场景下，相关系统的多组件行为呈现出典型的分布式、异构式特征。在组件内部行为难以描述，组件间相互规格和工作方式差异巨大，难以整体把控的情况下，如何从体系结构角度对系统可信增强进行考虑，设计面向容错的新型协同设计方式及异构系统体系结构[31]，为相关软件设计提出了新的挑战。
|
||||
|
||||
|
||||
\subsection{大规模复杂系统安全缺陷检测与保障}
|
||||
现代软件系统因需求的快速迭代而增量构建、经过频繁重构和演化、规模庞大、复杂度高，都是典型的大规模复杂系统，在企业应用、城市交通、航空航天、智能电网、医疗、指挥控制等重要领域已经成为了不可或缺的一部分，但其实现中存在漏洞或恶意代码等安全缺陷，是导致大规模复杂系统安全性问题的主要根源，而要想保障其安全，需要即时检测并排除安全缺陷，但随着软件的规模和复杂性的不断增大，现有软件安全保障技术与工具的有效性和可扩展性受到了严重制约，软件安全缺陷检测和排除以人为中心、侧重经验的实践现状尚未改变，尚未能形成自动化、客观化的解决方案。综上所述，软件安全保障所面临的新挑战主要包括：
|
||||
|
||||
(1) 安全缺陷统一建模。安全缺陷中，漏洞属于实现中存在遗漏，而恶意代码属于多余的实现，经过几十年的发展，已经公开了大量的安全缺陷，软件安全缺陷具有程序设计语言依赖、系统依赖等特征，有时还依赖于特定的硬件平台与体系结构，安全缺陷形态、机理各异。针对特定的安全缺陷，研究相应的检测方法进行精准制约化检测，虽在特定场景下可行，但已不能满足实际的安全需求。面临的挑战主要在于如何统一表达安全缺陷的语法、语义特征、触发规则、行为特征等问题，使得能够通过相关检测算法高效、精准识别安全缺陷；在此基础上，解决安全缺陷检测方法的平台化、引擎化、定制化，以便检测已有的重要安全缺陷，并具备扩展能力，检测新的安全缺陷。
|
||||
|
||||
(2) 大规模复杂系统安全缺陷检测方法的效率和资源有效协同。根据已公开的安全缺陷特征，通过静态分析、测试和验证等方法检测潜在安全缺陷，是目前被普遍采用的技术。但随着软件系统规模越来越大、系统功能日趋复杂，公开安全缺陷的数量也急剧上升，安全缺陷检测方法的精准性和规模化能力是难点问题。面临的挑战主要包括：1）需要平衡在处理大规模程序时在精度和可扩展性之间取舍。高精度的检测方法需要更多的资源开销，并且受到程序规模的制约，而为了适应大规模程序的安全缺陷检测，采用保守的策略，会导致大量的误报，且需要人工进一步确认，从而降低了检测方法的可用性； 2）需要平衡协同计算资源的消耗与检测效率。安全缺陷检测方法可以提升精度但增加复杂度且需要更高的计算资源，可以利用大数据处理、硬件加速、并行化等技术优化检测算法，依据特定的规则将大规模代码进行切分，将检测任务并行化处理、并将其分配到不同的计算资源上完成检测工作。
|
||||
|
||||
(3) 安全缺陷检测过程中大规模状态空间的充分探索。在安全缺陷检测过程，需要尽快探索到目标程序的状态空间，以检测潜在的安全缺陷，由于复杂软件系统的程序状态空间十分庞大，如何有效地探索程序的状态空间是需要解决的关键问题，具体包括以下几个方面：1）程序分支和循环结构的深度覆盖：通过探索程序状态空间过程中历史覆盖、缺陷检测、冗余等信息，有效地制导探索过程，尽早覆盖关键的程序状态空间；2）多元信息制导的模糊测试输入生成：利用程序结构、安全缺陷特征、执行结果反馈等信息，有效地制导模糊测试，使其能够产生覆盖多样性目标的输入空间，从而快速覆盖程序状态空间，到达能够触发安全缺陷的程序行为路径。
|
||||
|
||||
(4) 历史漏洞机理和安全专家经验难以复用。在现有安全缺陷检测的分析和测试过程中，多个环节存在不确定性，需要人工决策，而机器学习、深度学习等人工智能技术。这些专家经验以及历史漏洞的机理分析对后续分析能够起到很大作用。但遗憾的是，这些经验在现阶段难以复用。另一方面，在文本、图像、语音等信息的处理方面已经具备人的智能而实现自主决策。因此，如何在安全缺陷检测和预警的各个环节中引入智能化技术，是现阶段所面临的重要挑战，具体包括以下两个方面：1）安全缺陷检测历史信息的智能化：将安全缺陷检测历史信息及其统计特征知识化，以便在安全缺陷检测过程中使用机器学习方法进行智能化预测，如何将深度学习技术应用到安全缺陷检测样本代码相似度映射中以便实现同源安全缺陷检测和挖掘的智能化，应用到输入域、程序结构的映射中实现模糊测试中输入生成的智能化；2）安全专家经验的知识化和智能化利用：利用安全缺陷检测过程中的安全专家经验，并抽象其为安全缺陷检测的启发式规则，以便在安全缺陷检测过程中根据自动搜索经验知识空间实现安全缺陷检测的智能化。
|
||||
|
||||
(5) 面向安全保障的缺陷自动修复与验证。及时修复软件中存在的安全缺陷，是保障软件安全的主要手段，先阶段主要依靠人工修复软件安全缺陷需要花费大量的时间精力阅读理解程序代码、定位安全缺陷并修复，非常耗时耗力。面临的挑战主要在于：1）如何针对安全缺陷实现自动修复。基于遗传算法、程序搜索、程序合成等手段的软件缺陷的自动修复方法面临在实际系统中应用的可扩展性、可用性等方面的挑战。2）如何自动验证修复。目前存在一些修复方法在某些实验途径上可以证实有效性，但缺少理论基础，无法保障其完备性，需要有手段保证安全缺陷修复措施符合预期。
|
||||
|
||||
|
||||
|
||||
\subsection{物联网软件安全保障}
|
||||
|
||||
物联网是移动互联网、云计算、大数据技术和人工智能等新一代信息技术，在人类社会的具体应用领域中，通过人机物融合实现计算、信息、通讯、控制等任务的一体化的产物。物联网软件是其核心使能组成部分，也是软件产业的一个新兴领域。物联网高速发展的同时，也带来新的问题，特别是物理设备实现移动互联后，导致所有物联网终端设备直接暴露在互联网上、处于不安全状态，使得设备自身安全、其拥有和传输的数据的机密性、完整性和可获得性，都面临安全挑战。任一物联网终端软件一旦遭受攻击，将会导致软件崩溃、设备失效、威胁用户隐私、冲击关键信息基础设施等安全事故，对整个物联网系统造成严重的破坏性。但现阶段，全面保障物联网软件与系统安全，需要检测物联网软件的所有潜在安全薄弱环节，实施有针对性的保障措施。但由于物联网软件的复杂性、异构性、人机物融合等特性，仍然需要重点解决如下重大挑战问题：
|
||||
|
||||
(1) 面向复杂异构物联网终端控制软件的安全缺陷检测。在复杂物联网系统中，计算、通信和控制设备由于其各自所执行的任务不同，往往由完全不同的软硬件构成，同时不同设备间的相互协作关系也由于系统的庞大而变得十分复杂，有时还可能存在动态变化，这导致对复杂物联网系统中异构的终端设备控制软件进行安全性检测变得异常困难。如何改进现有的静态分析与动态测试技术以适应物联网软件依赖的芯片、硬件外设、操作系统、指令集、外部库、交互接口、外部输入等异构性，是面向复杂异构物联网终端软件进行安全缺陷检测亟需解决的关键问题。
|
||||
|
||||
(2) 面向完整物联网软件系统的模糊测试。物联网边界模糊、设备异构，物联网软件实现了控制、计算与通信的集成，使其在处理能力不断强大的同时，内部结构也变得愈加庞杂且与外部世界的交互变得愈加频繁，而现有的模糊测试方法主要针对物联网软件系统自身故障进行安全检测，面临的挑战在于如何针对物联网系统与环境，探索使用基于人工智能技术、深度学习方法，构建智能化模糊测试方法，将物联网状态空间中搜索安全缺陷的问题转化为目标制导模糊测试与优化问题。
|
||||
|
||||
(3) 面向动态安全检测的物联网软件仿真与虚拟化技术。现有物联网软件测试需要互联网环境支撑、动态执行设备，并依据获取的运行时反馈信息进行分析，使得运行时安全检测面临驱动设备运行困难、捕获设备反馈困难、识别安全缺陷困难等问题，具体包括：1）物联网软件仿真技术。由于物联网软件依赖的终端硬件、体系架构、指令集、部署配置的多样性，如何在支持相应固件体系结构、指令集的模拟器的基础上构建通用仿真执行支撑环境；如何针对基于特定外设，基于适配接口构建物理设备运行驱动环境，从而实现能对典型设备进行运行驱动的支撑；如何利用通用仿真环境和物理环境的支撑，捕获运行时的物理设备的状态、仿真环境下覆盖等反馈信息，便于安全缺陷检测过程。 2）物联网系统环境建模与虚拟化技术，物联网软件需要通过外设、互联网接口与外界交互，如何基于各类网络协议，对多类交互输入接口进行虚拟化和数字化的基础上统一建模，对物联网运行依赖的系统软件平台进行虚拟化建模与支撑。
|
||||
|
||||
\section{主要研究内容}
|
||||
软件系统的质量和安全保障主要在于针对软件自身的构建和维护阶段、软件运行和提供服务阶段，未来应当研究以下几个方面：一是从发现缺陷角度，需要研究现有软件质量和安全保障的技术手段的能力提升；二是从适应新时代软件新的特征角度，需要研究的新的软件质量和安全保障的方法；三是从标准、伦理和法律符合性角度，研究在软件开发构建、运行维护过程中约束、规范人的行为以保障软件的质量和安全的技术手段。
|
||||
|
||||
\subsection{大规模复杂系统建模、分析、测试与验证}
|
||||
人机物融合场景下，大规模复杂系统的行为存在多组件间交互、大量不确定、概率性行为，研究概率、组合建模机制对相关系统行为进行描述，并在此基础上研究大规模概率组合系统分析、测试、验证方法与技术以进行可信增强和质量保障具有重要意义。
|
||||
|
||||
\subsection{开放动态系统行为监控、预测与容错}
|
||||
传统静态手段难以应对开放动态系统，从监控的角度在运行时对系统行为进行可信增强具有重要意义。以监控属性和监控设计模型为基础，结合运行时验证、故障诊断与隔离等技术，研究相关系统主动监控理论，一方面能够有效监控系统当前出现的问题，另一方面可以基于运行状态对系统后续行为进行预测，在出现可能发生故障的趋势时，对系统运行进行干涉，以避免故障的发生。
|
||||
|
||||
\subsection{系统体系结构驱动的可信增强}
|
||||
针对系统异构复杂性，从体系结构角度出发进行模块化设计将问题与影响进行局部隔离，增加与预留容错机制，减小单组件失效对整体带来的影响对于整体系统可信增强具有重要意义。另外，将上述相关技术进展纳入系统设计，从协同设计角度在设计阶段整体考虑进行监控、预测、容错，对于提升系统可信、性能等也具有显著意义。人机物融合场景下各系统分处不同物理空间，跨越不同知识领域，使用不同架构。为了保证最终整体系统的安全可靠，从系统工程的角度对相关系统进行整体分析是一个重要的方向。
|
||||
|
||||
\subsection{数据质量治理}
|
||||
数据质量是大数据分析正确和决策有效的根本保证。通过数据治理，采用高效的数据管理工具，保证数据在全生命周期内正确、规范、安全，符合系统要求，有助于高质量的知识挖掘和利用。与传统关系型数据相比，大数据具有数据量大、实时分析要求高、存在多种异构数据格式、噪音高、关键数据元素持续演变等特点，质量管理更加具有挑战性和迫切性。
|
||||
|
||||
\subsection{智能模型质量保障}
|
||||
针对数据集偏差、歧视及样本迁移等问题，一方面需要提高机器学习算法设计的鲁棒性；另一方面更需要在系统层面上构建一套监测体系来时刻发现数据偏差、歧视和样本迁移问题。在构建这套检测体系时，需要考虑两个维度，一是需要保证检测的高效性和及时性；二是需要保证检测的有效性，要能很好的度量数据分布。分析智能学习算法及其开发框架设计，检测鲁棒性、安全性、稳定性等各方面问题，并评估其在智能应用中的风险。探索有效的智能软件测试和质量评估方法。当前对于智能软件的质量评估主要是机器学习算法精度的度量标准，评估并引导智能软件在人工标注的数据集上得到较好的结果，但是却无法评估智能软件在面对恶意攻击的稳定性。
|
||||
|
||||
\subsection{全生存期软件质量运维}
|
||||
在系统开发环境、集成环境、运行动态环境中，建立一体化的质量保证平台，对开发、集成、部署、运维流程中各个环节质量数据进行综合分析，支持持续迭代的故障检测和质量评价过程，构建软件质量的全景视图，以期更加准确有效地发现质量问题、追溯问题来源并评估质量风险。DevOps、持续集成（CI, Continuous Integration）、持续测试（CT, Continuous Testing）、持续交付（CD, Continuous Delivery）、智能运维（AIOps）等技术及其自动化工具支持，是DevOps提升软件质量保证的关键。在CI/CT/CD过程中，开发人员的每次代码更新提交后，都会触发构建、部署、以及测试脚本的自动执行，小规模代码、高频率测试有助于及时、快速地发现、定位和修复缺陷；在AIOps中，通过大数据分析等技术，自动、及时发现运行过程中的异常行为。开发运营一体化，还可以进一步构成质量反馈机制，将运营环节发现的异常分析报告反馈给开发环节，以加强CI/CT过程的故障检测和质量保证。
|
||||
|
||||
\subsection{软件生态中缺陷检测与修复}
|
||||
开源软件和代码托管平台的大量使用使得软件开发已经从独立的项目模式演变成社会技术性的软件生态系统模式，这也使得项目间形成错综复杂的依赖关系，促进了项目的共同发展和演化，同时也为软件的维护工作和质量保障带来了新的挑战，解决不好就破坏了软件生态系统的健康与发展。跨项目缺陷的检测和修复问题尤为突出。研究具有复杂、开放、规模大和分布式等特征软件生态系统中的跨项目缺陷的预测、定位和修复，充分利用软件生态系统中多种形态的数据（如代码、代码提交日志、程序频谱、文档、历史缺陷数据和开发者数据等），多种形态数据的关联和影响、项目间的依赖关系和数据流动，研究面向软件生态系统的多形态数据的语义模型、项目依赖网络的软件分析技术，实现跨项目缺陷检测；从缺陷产生的原因、缺陷的影响、缺陷的修复等多个角度研究软件生态系统中缺陷的特征和规律，以目前流行的开源软件生态系统作为对象，构建公共数据集，并进行大规模的实验验证分析，建立一套软件生态系统中缺陷的影响分析模型和方法、跨项目缺陷修复的方法和相应的支撑平台。
|
||||
|
||||
\subsection{大规模复杂软件的恶意代码智能检测}
|
||||
基于恶意代码的静态结构和动态行为特征及其演化，通过在静态分析中引入人工智能技术，模拟安全专家“手工”检测和识别恶意代码的流程，研究和设计智能化恶意代码检测模型。将恶意特征库作为数据集，分析并生成其适合机器学习模型的特征描述，进行大规模训练，从而快速、准确地实现对恶意特征的识别和判断，为大规模复杂软件的恶意代码检测提供技术支撑。同理，恶意代码随时间演化，检测模型也需不断变化，因此如何训练出抗恶意代码演化的自改进模型是研究重点；研究通过对目标复杂软件（系统）的恶意特征进行自动化标记，使用智能化技术设计动态分析方法。标记出需要部分动态分析的含恶意特征的目标程序，对其进行运行态行为实时跟踪，实现对恶意行为的自动化验证。
|
||||
|
||||
\subsection{漏洞智能化检测}
|
||||
通过从复杂系统内部和外部海量数据中收集、提取特征，基于深度学习等智能化方法对复杂系统内部逻辑建模，并以前期漏洞检测分析结果为数据基础，完成对复杂系统运行逻辑的预测，实现判别异常运行逻辑，从而有效提高漏洞检测的效率；研究基于深度学习技术构造软件输入域与代码结构、行为的映射模型，基于映射模型有效指导模糊测试生成过程中输入域修改位置与变异值，进而测试针对特定代码区域、触发特定行为，以有效检测漏洞；基于漏洞成因及触发机制，研究基于大数据处理的程序漏洞并行检测技术。
|
||||
|
||||
\subsection{漏洞智能化修复}
|
||||
漏洞修复作为保护系统免受攻击的重要一环，往往需要精确地把控漏洞成因及漏洞危害。人工进行漏洞修复往往由于安全人员的知识水平和思维习惯等问题造成修复失败或者又引入新的漏洞[19]。通过研究漏洞代码的自动化定位、漏洞代码上下文智能切片和基于上下文的代码逻辑修正等技术，结合智能化方法，构建智能化漏洞修复技术，保障漏洞修复的准确性和及时性。如何表示数据、选取智能化模型是研究难点，因为将数据合理表达为智能模型适合处理的形式，并选用合适的模型，可使漏洞修复过程更加可靠。
|
||||
|
||||
\subsection{物联网软件安全保障}
|
||||
研究针对物联网软件的静态分析和符号执行技术，支持典型安全缺陷的检测检测；研究物联网软件建模、模型驱动测试与验证方法；研究面向物联网的智能模糊测试技术，用物联网软件结构、行为模型有效制导模糊测试，生成能够覆盖物联网软件输入域、结构和行为场景的测试输入，利用机器学习、深度学习等人工智能技术，基于对物联网软件结构与行为、物联网软件安全缺陷、模糊测试历史等知识和经验的学习，构建并训练映射模型，预测输入域与状态空间区域的映射关系，通过使用遗传算法、人为指定漏洞关联重点区域，优化模糊测试制导算法，避免无效、冗余的测试生成，在资源有限的情况下充分有效地遍历重要的状态空间尽早发现漏洞；研究物联网软件虚拟化和仿真技术，对物联网运行依赖的系统软件平台进行虚拟化建模与支撑，针对物联网软件依赖的特定外设、体系架构、指令集等，研究仿真运行技术。
|
||||
|
||||
\subsection{软件质量与安全保障的外延扩展}
|
||||
分析国际、国家软件质量和安全相关的标准，针对软件新的特征和应用，研究新型软件质量模型、标准的扩展、标准符合性评估手段；基于ACM/IEEE软件工程职业伦理规范，研究适合我国国情的软件从业人员的职业伦理规范；基于在国家重要领域软件应用的相关法律规定，研究法律法规符合性的软件的质量和安全保障技术手段，包括GPL、APL等软件授权规定，软件代码中违规行为和证据的获取等。
|
||||
|
||||
\section{本章小节}
|
||||
在“软件成为基础设施、软件定义一切”的背景下，本章基于软件的复杂加剧化、形态服务化、质量价值化、协作生态化的视角，从可信软件度量与评估、数据驱动的智能软件系统质量保障、人机物融合场景下的软件系统可信增强、大规模复杂软件系统安全、物联网软件安全等几个角度讨论了软件质量与安全保障面临的重大挑战问题，展望了未来仍需研究的方向和内容。
|
||||
|
||||
\section{参考文献}
|
||||
[1] xLe Goues C, Nguyen T V, Forrest S, et al. Genprog: A generic method for automatic software repair[J]. Ieee transactions on software engineering, 2011, 38(1): 54-72.
|
||||
|
||||
[2] Kruger J, Schneider J, Westermann R. Clearview: An interactive context preserving hotspot visualization technique[J]. IEEE Transactions on Visualization and Computer Graphics, 2006, 12(5): 941-948.
|
||||
|
||||
[3] Kim G, Humble J, Debois P, et al. The DevOps Handbook:: How to Create World-Class Agility, Reliability, and Security in Technology Organizations[M]. IT Revolution, 2016.
|
||||
|
||||
[4] Ebert C, Gallardo G, Hernantes J, et al. DevOps[J]. Ieee Software, 2016, 33(3): 94-100.
|
||||
|
||||
[5] Dang Y, Lin Q, Huang P. AIOps: real-world challenges and research innovations[C]//Proceedings of the 41st International Conference on Software Engineering: Companion Proceedings. IEEE Press, 2019: 4-5.
|
||||
|
||||
[6] Li Z, Dang Y. AIOps: Challenges and Experiences in Azure[J]. 2019.
|
||||
|
||||
[7] D. Sculley, T. Phillips, D. Ebner, et al. Machine learning: the high-interest credit card of technical debt[J]. 2014. http://citeseerx.ist.psu.edu/
|
||||
viewdoc/summary? doi=10.1.1.675.9675.
|
||||
|
||||
[8] M. Jorge, C. Ismael, R. Bibiano, S. Manuel, P. Mario. A Data Quality in Use Model for Big Data. Future Generation Computer Systems, 63(2016): 123-130.
|
||||
|
||||
[9] S. Soares, Big Data Governance: An Emerging Imperative, MC Press, 2012.
|
||||
|
||||
[10] Li Y, Jin Z. An Android malware detection method based on feature codes[C]//2015 4th International Conference on Mechatronics, Materials, Chemistry and Computer Engineering. Atlantis Press, 2015.
|
||||
|
||||
[11] Galal H S, Mahdy Y B, Atiea M A. Behavior-based features model for malware detection[J]. Journal of Computer Virology and Hacking Techniques, 2016, 12(2): 59-67.
|
||||
|
||||
[12] Sogukpinar I. Analysis and Evaluation of Dynamic Feature-Based Malware Detection Methods[C]//Innovative Security Solutions for Information Technology and Communications: 11th International Conference, SecITC 2018, Bucharest, Romania, November 8 {u2013} 9, 2018, Revised Selected Papers. Springer, 2019, 11359: 247.
|
||||
|
||||
[13] 李华, 刘智, 覃征, 等. 基于行为分析和特征码的恶意代码检测技术[J]. 计算机应用研究, 2011, 28(3): 1127-1129.
|
||||
|
||||
[14] 宋文纳, 彭国军, 傅建明, 张焕国, 陈施旅 . 恶意代码演化与溯源技术研究. 软件学报,2019.http://www.jos.org.cn/1000-9825/5767.htm
|
||||
|
||||
[15] Gosain A, Sharma G. A survey of dynamic program analysis techniques and tools[C]//Proceedings of the 3rd International Conference on Frontiers of Intelligent Computing: Theory and Applications (FICTA) 2014. Springer, Cham, 2015: 113-122.
|
||||
|
||||
[16] Cousot P, Giacobazzi R, Ranzato F. Program analysis is harder than verification: A computability perspective. In: Proc. of the CAV.2018. 75-95.
|
||||
|
||||
[17] 张健,张超,玄跻峰,熊英飞,王千祥,梁彬,李炼,窦文生,陈振邦,陈立前,蔡彦.程序分析研究进展.软件学报,2019, 30(1):80-109. http://
|
||||
www.jos.org.cn/1000-9825/5651.htm
|
||||
|
||||
[18] 邹权臣, 张涛, 吴润浦, 马金鑫, 李美聪, 陈晨, 侯长玉. 从自动化到智能化:软件漏洞挖掘技术进展. 清华大学学报(自然科学版), 2018, 58(12): 1079-1094.
|
||||
|
||||
[19] Lin Z, Jiang X, Xu D, et al. AutoPaG: towards automated software patch generation with source code root cause identification and repair[C]//Proceedings of the 2nd ACM symposium on Information, computer and communications security. ACM, 2007: 329-340.
|
||||
|
||||
[20] Edward Lee. Cyber-physical systems - are computing foundations adequate? Position paper for NSF workshop on Cyber-Physical Systems: Research Motivation, Techniques and Roadmap.
|
||||
|
||||
[21] Wang, Xiaofeng, Naira Hovakimyan, and Lui Sha. "L1Simplex: fault-tolerant control of cyber-physical systems." In 2013 ACM/IEEE International Conference on Cyber-Physical Systems (ICCPS), pp. 41-50. IEEE, 2013.
|
||||
|
||||
[22] Ammar M, Russello G, Crispo B. Internet of Things: A survey on the security of IoT frameworks[J]. Journal of Information Security and Applications, 2018, 38: 8-27.
|
||||
|
||||
[23] David Y, Partush N, Yahav E. Firmup: Precise static detection of common vulnerabilities in firmware[C]//ACM SIGPLAN Notices. ACM, 2018, 53(2): 392-404.
|
||||
|
||||
[24] Davidson D, Moench B, Ristenpart T, et al. {FIE} on Firmware: Finding Vulnerabilities in Embedded Systems Using Symbolic
|
||||
Execution[C]
|
||||
//Presented as part of the 22nd {USENIX} Security Symposium ({USENIX} Security 13). 2013: 463-478.
|
||||
|
||||
[25] Corteggiani N, Camurati G, Francillon A. Inception: System-wide security testing of real-world embedded systems
|
||||
software[C]//27th {USENIX} Security Symposium ({USENIX} Security 18). 2018: 309-326.
|
||||
|
||||
[26] Zheng Y, Davanian A, Yin H, et al. FIRM-AFL: high-throughput greybox fuzzing of iot firmware via augmented process emulation[C]//28th {USENIX} Security Symposium ({USENIX} Security 19). 2019: 1099-1114.
|
||||
|
||||
[27] Sfar A R, Natalizio E, Challal Y, et al. A roadmap for security challenges in the Internet of Things[J]. Digital Communications and Networks, 2018, 4(2): 118-137.
|
||||
|
||||
[28] Kolias C, Kambourakis G, Stavrou A, et al. DDoS in the IoT: Mirai and other botnets[J]. Computer, 2017, 50(7): 80-84.
|
||||
|
||||
[29] Zhou W, Jia Y, Yao Y, et al. Discovering and understanding the security hazards in the interactions between IoT devices,
|
||||
mobile apps, and clouds on smart home platforms[C]//28th {USENIX} Security Symposium ({USENIX} Security 19). 2019: 1133-1150.
|
||||
|
||||
[30] Chen J, Diao W, Zhao Q, et al. IoTFuzzer: Discovering Memory Corruptions in IoT Through App-based Fuzzing[C]//NDSS. 2018.
|
||||
|
||||
[31] Seto, Danbing, Bruce Krogh, Lui Sha, and Alongkrit Chutinan. "The Simplex architecture for safe online control system upgrades." In Proceedings of the 1998 American Control Conference. ACC (IEEE Cat. No. 98CH36207), vol. 6, pp. 3504-3508. IEEE, 1998.
|
||||
|
||||
|
|
@ -0,0 +1,194 @@
|
|||
|
||||
\section{引言}
|
||||
|
||||
“人－机－物”三元融合的新型应用模式, 通过综合应用物联网、移动互联网、通信、大数据计算、人工智能等技术，使人类社会（人）、信息空间（机）、物理世界（物）之间实现互联，形成以人为中心的新社会形态[1]。其中，软件作为关键要素，围绕软件的各类元素之间也存在复杂的依赖关系，形成了软件生态。软件生态是指各类软件制品（包括开发态和运行态）及其软件涉众（包括开发者、使用者和维护者等）和软件设施（包括承载软件制品开发与运行的物理设施和其作用的物理设施），围绕软件相关的各种活动（包括开发、使用、服务、维护等），形成的相互依赖和相互作用的网络，如图\ref{fig:fig1}所示。随着互联网的发展和软件技术的发展，这些依赖关系使得软件制品越来越依赖于其所存在的软件生态，逐渐推动软件生态化，成为软件产业的未来发展趋势。
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[scale=1]{fig2-9/fig1.png}
|
||||
\caption{软件生态系统}
|
||||
\label{fig:fig1}
|
||||
\end{figure}
|
||||
|
||||
在软件作为基础设施、软件定义一切的背景下，软件学科的内涵呈现出四个新视角，包括以驾驭复杂性为目标的系统观、以泛在服务和持续演化为特征的形态观、以使用质量为核心的价值观、以及关注群体协作平衡的生态观。这四个视角对软件生态既提供了新的观察内容，又提出了新的挑战。从系统观来说，生态系统是复杂系统（各类软件及软件活动涉及到的社会角色彼此交互），适合采用系统论驱动的复杂软件系统的观察和度量方法，以及各种模型表示方法及其工具支持。从形态观来说，软件泛在化和软件应用的持续成长趋势不仅是软件生态的驱动力，也增进了其复杂性。从价值观来说，软件生态体现了从单个元素到复杂系统的价值的转变，并且因其所涉及的浓厚社会因素从传统的质量观发展到以人为中心的价值观。从生态观来说，软件开发、使用（工具观或客体观的表述）或服务（主体观的表述）的复杂性体现在参与到软件开发、维护、使用、应用及市场的各个环节的广大社会群体，还体现在软件活动所处环境的开放性及其彼此交互和依赖所带来的不确定性等。总的来说，软件制品、软件涉众以及软件设施日益复杂化，同时在经济力量不断将国家市场转变为国际市场的前提下，全球化软件活动已经发展成为一种不可逆转的趋势[2]。全球分工不断精益化，各种供应链关系形成和发展，软件生态化成为趋势，并可能形成常态。
|
||||
|
||||
在软件生态化这一背景下，催生出了许多软件学科的重要研究内容。例如，如何理解并利用大规模代码和项目的供应链行为；个体如何快速学习并加入复杂项目和生态；群体如何高效高质地协作完成各类软件活动相关的任务；涵盖公司、个体开发者及用户在内的广泛社会力量如何围绕软件构建可持续性演化的生态系统等。在本章中，我们将围绕这些问题从三个层次理解软件生态。
|
||||
|
||||
\section{重大挑战问题}
|
||||
研究软件生态的挑战问题集中在如何刻画、抽象和分析复杂的软件生态网络。具体来说，如图\ref{fig:fig1}所示，分为三个层次的依赖关系网。首先，软件制品之间存在的相互依赖关系（无论是开发态还是运行态）构成了供应链网络。软件制品特别是大型商业软件之间的依赖关系非常复杂，其挑战表现在如何理解并利用大规模代码和项目的供应链行为（§9.1.1）。其次，在这个网络上叠加软件涉众（开发者、使用者和维护者），包括软件涉众与这些软件制品形成的相互关系，以及由此带来的软件涉众之间的关系网络，从而形成相互联系软件制品生态网络与其之上的软件涉众生态网络。由此带来的挑战例如：个体如何学习并加入复杂项目和生态（§9.1.2），复杂生态中群体如何协作，协作行为如何发展（§9.1.3）等。再者，我们可以在这个网络之下叠加软件设施，包括软件设施与这些软件制品形成的相互关系，以及由此带来的软件设施之间的关系网络（也就是物联网）。在理解了三层软件生态网络的基础上，带来的核心挑战问题是生态如何形成，如何可持续发展（§9.1.4）。
|
||||
|
||||
\subsection{供应链的复杂性}
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[scale=1]{fig2-9/fig2.png}
|
||||
\caption{CRAN 运行时的依赖关系}
|
||||
\label{fig:fig2}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[scale=1]{fig2-9/fig3.png}
|
||||
\caption{软件供应链示意图}
|
||||
\label{fig:fig3}
|
||||
\end{figure}
|
||||
|
||||
随着软件技术的不断发展和软件应用领域不断深入，软件产品越来越多样化和复杂化。一些大型项目（例如Linux内核项目）的代码规模几乎呈现指数级增长，代码之间的依赖关系也不断复杂化。例如，一个软件可能同时依赖数千个其他软件项目。图\ref{fig:fig2}展示了CRAN (Comprehensive R Archive Network)运行时复杂庞大的依赖关系，节点是软件包(package)，连线是运行时依赖关系。不同于围绕同一软件形成的生态系统，这种由于软件或软件项目之间互相依赖（如软件的构建或运行时依赖；开发者同时参与多个软件项目；软件代码的复制粘贴等）形成的复杂关系网络被称为软件供应链[3]。图\ref{fig:fig3}以开源软件为例展示了软件供应链的可能组成成分（闭源软件或开源闭源软件一体的生态也是同理），涉及了底层硬件固件、系统软件、开发平台软件、以及与用户最为相关的应用软件。大型的软件供应链几乎囊括了开发、运行过程中涉及到的所有软硬件及其生态。数以万计互相依赖的软件或项目形成的供应链为软件开发和使用带来了前所未有的创新水平，同时，规模指数级增长的软件或项目及其之间庞杂的依赖关系使得供应链的复杂度激增，进而带来诸多挑战，也促进了这方面研究的繁荣。
|
||||
|
||||
|
||||
|
||||
\subsection{个体学习以及加入生态的困难性}
|
||||
个体（包括开发者、维护者等）作为软件生态中的参与者，是影响软件开发质量和效率的关键因素，是软件生态中最核心的角色之一。近年涌现的一些软件开发现象，诸如全球化、越来越多的高层次认知任务外包、针对大规模复杂项目的高效参与需求，正在改变人们思考、学习、工作以及合作的方式。尤其是许多关键系统的复杂性不断增强，使得新人进入非常困难。因此，个体如何学习和掌握复杂系统成为了一个亟待解决的问题，另外，以互联网为媒介的各种应用蓬勃发展，各种新的技术和新的应用方式层出不穷，这也给开发者如何快速学习适应变化带来了很大的挑战。这方面问题都引起了工业界和学术界的广泛关注。
|
||||
|
||||
“个体学习”包含了两层含义。第一，学习什么？一些复杂的大型软件项目，除了要求个体掌握必要的编程技能，项目所涉及的领域知识也需要开发者理解。除此之外，他们还需要学习如何与社区沟通（根据Astromskis等人的研究[4]，开发者近乎一半的工作时间都花费在沟通上），需要熟悉使用各种开发支持工具——这些工具及其积累的数据也是分布式环境下传播知识和学习项目的重要媒介[5]。第二，如何学习？一个开发者如何从初学新手成长为专业行家，如何从初进社区的新手角色变为核心团队成员，他怎么获取各种知识和信息，又是以一种什么顺序掌握等，这些都是理解个体学习的关键挑战。在开源项目中，并无层级组织、训练计划、集中式的环境给予初学者必要的熏陶和培育，更多的是“边干边学”（learning by doing）。研究那些高产的开发者的学习轨迹，看他们如何获得技能、解决关键而复杂的任务，了解是什么激励了他们，也许能够将他们获得技能的方法具体化，并进一步地用于训练其他人；同时，高手和新手解决问题的心理模型不一样，因而在其指导新手时可能会出现失配问题（zone of proximal development，认知科学的一个重要发现[6]）。如何理解项目中失配问题的本质，并建立相应技术和工具来更好适配新手的需求和高手的指导不仅能帮助个体成长，也将帮助软件项目和社区的发展；另外，对于要处理各种复杂编程任务的程序员，如何应对人类本身的认知局限性，例如工作记忆系统容量有限，认知负荷等问题，也是软件工程领域要考虑的问题。总的来说，我们需要对个体如何学习一个软件项目、如何使项目更具可读性（self-documenting[7]）、如何创造革命性的资源和工具来提高新人的学习能力和生产力有更深入的理解。
|
||||
|
||||
\subsection{群体协作的不可控性}
|
||||
在经济力量不断将国家市场转变为国际市场的前提下，全球化软件开发已经发展成为一种不可逆转的趋势[15]。分布在世界各地的软件涉众需要协同发布一个可用的高质量软件，这将面临大规模的通信、协调和合作。软件开发活动中涉及到的众多角色能否积极地参与、良好地协作这些社会性的问题同样影响到软件开发的效率以及产品的质量。
|
||||
|
||||
基于互联网的软件开发活动，以开源开发为代表，基本都在开放透明的分布式环境下合作实施，具有沟通媒介和形式多样化（例如版本控制系统、缺陷追踪系统等软件开发支撑工具和Twitter、StackOverflow等互联网新媒体）、协作内容和信息碎片化的特点，再加上软件项目上下文千差万别，使得找到通用的（可复现的）最佳实践非常困难，从而导致群体社会化开发的可知与可控难题有加剧的趋势。
|
||||
|
||||
\subsection{生态的可持续性}
|
||||
软件生态由于汇聚了众多复杂的软件系统、软件涉众，以及软件设施，它们之间呈现出非常复杂紧密的依赖关系，具有极快的发展速度和极大的创新潜力。随着支持分布式软件开发的开放现代平台的出现和不断完善，如GitHub、Bitbucket、和GitLab，软件项目正在以前所未有的速度增长。然而，鉴于各种复杂因素的存在，软件生态的持续发展面临诸多潜在的风险和挑战，特别是开源软件在目前的全球软件生态中扮演了非常重要的角色，但因为参与的开放性以及集中意志/管理的缺乏，其可持续性在可见的未来存在很大挑战，主要表现在如下三个方面。
|
||||
|
||||
首先，广泛的社会参与使得开源生态的管理控制复杂性激增。越来越多的商业组织和非营利机构参与到开源生态系统，并扮演重要的角色。例如，175个公司在OpenStack最近发布的 Rocky版本中贡献了近90%的代码[21] 。来自各个行业、出于不同目标和动机的商业公司，对开源生态的参与方式也千差万别[22]。此外，参与到同一开源生态系统的商业组织之间又会存在（或者产生）合作或竞争等关系。总的来说，不断增加的各种组织、其差别迥异的参与方式以及相互间错综复杂的关联关系，都使得开源生态系统控制和管理的难度迅速且持续增加。
|
||||
|
||||
其次，商业参与具有很大的不稳定性。开源生态系统中的商业公司始终需要在“开放”与“盈利”之间权衡，一旦确定其目标无法完成或参与战略发生转变等，将有可能直接停止（撤走）对开源软件的所有投入。特别是那些在开源社区占据主导地位的公司的离开，将可能直接导致该开源生态走向失败[23]。例如，IBM取消了对开源项目Aperi的支持后，该项目被迫关闭[24]。
|
||||
|
||||
第三，商业文化与自由开源精神存在冲突。商业公司传统的软件开发经验习惯，如组织安排、任务分工等可能伤害那些崇尚“黑客文化”、“自由软件精神”的个体开发者。因为这类开源开发者更加倾向于自发参与、按照个人意愿选择任务，例如目前世界第一大开源JavaEE应用服务器JBossAS的创始人Marc Fleury在RedHat收购JBoss之后离开[25]。
|
||||
|
||||
\section{主要研究内容}
|
||||
为了应对上述挑战，相关研究需从以下几个方面开展。首先，为了理解和度量复杂的生态网络，前提是需要建立一套数据驱动的软件度量和分析方法（§9.2.1）。其次，围绕软件生态的三个层次，还有以下三方面主要研究内容。第一，为了应对复杂软件供应链所带来的挑战，需要理解并度量大规模代码和项目的供应链模式，从中挖掘可借鉴的成功经验，同时及时识别潜在风险（§9.2.2）。第二，基于软件供应链，开发者之间也形成了相互协作的关系网，如何帮助他们顺利加入复杂项目，提高团队协作效率也是软件生态领域所关注的主要研究内容之一（§9.2.3）。第三，基于以上研究内容，我们期待能够深入理解生态系统的形成机理和可持续机理，从而帮助软件生态可持续发展（§9.2.4）。
|
||||
|
||||
\subsection{数据驱动的软件度量和分析方法}
|
||||
随着开发支撑技术的成熟，近年来软件项目广泛使用版本控制系统、缺陷追踪系统、邮件列表和论坛等工具，大型软件工程的数字轨迹被普遍地保存起来。软件生命期的数据，包括代码的每一次变更，人们的每一个缺陷报告、每一个评论和每一个邮件等，都被完整保存在软件仓库中。这种大规模的多源异构数据为研究软件生态带来重大契机，为人们认识软件开发的本质，提高开发效率和保证软件质量开启了一扇新的大门。如何更好地利用这些数据，让数据发挥最大价值是进行相关研究的基础。首先，应该关注数据的收集，以及组织与存储。其次，由于软件开发活动数据被广泛应用于科学研究和开发实践，数据质量对相关的研究和实践有重大影响,因而需要得到足够的重视。
|
||||
|
||||
\subsubsection{数据的收集}
|
||||
构建数据基础设施的第一步是数据的收集工作。研究者所面临的基本挑战是数据的可得性问题。随着开源运动的不断发展状态，网络上累积了越来越多的公共开放的软件项目的开发数据，这使得大规模的数据的收集成为可能。然而，长时间、高频率的数据访问将产生类似DoS攻击的不良影响，妨碍项目的正常运转，因此，很多开源项目的组织都对数据的访问频率做出了限制。因此，大量数据的收集通常需要消耗大量的时间才能完成。如果研究者各自地重复进行收集，这不仅会给项目带来成倍的数据访问负担，而且还造成了时间、人力、物力的浪费，这也是建立数据基础设施的必要性之一。目前，由于越来越多的研究兴趣投向一些组织所拥有的数据，这些组织也开始与学术界进行接触和合作，开放他们的数据。例如Stack Exchange公司已经若干次公开发布其问答网站的数据存档\footnote{https://archive.org/details/stackexchange}，Mozilla社区也在北京大学的软件工程研究所的数据分析小组的请求下发布了其Bugzilla的后台数据库的dump [14]。如今，数据可得性的问题已经得到了极大的缓解。
|
||||
|
||||
在数据可得的前提下，开发和采用对应于不同数据源的数据收集的技术是收集过程的核心研究问题，这其中包括数据源的定位和数据的处理及下载。在数据源的定位上，收集的范围决定其难度。对于单一项目，数据源的定位较为简单，通过项目的wiki提供的各种在线工具的URL链接人工定位即可；对于单一组织管理的项目集合，通常会有项目列表，其中包含了每个项目各类资源的URL链接；对于没有特定的目标，要进行普查式的收集，需要借助人的知识与经验，从一些经典及大型的组织入手，按照单一组织下项目的数据源的定位方式进行检索，其次利用检索工具进行更大范围的检索，例如Mockus在全面收集开源项目版本控制数据的工作中便先从SourceForge、GoogleCode、Savannah、Tigris等知名的软件项目门户，以及Linux kernel, FreeBSD, NetBSD等社区入手，之后借助文献、Google代码检索工具等进行补充[30]。对于数据的下载，不同类型的访问方式决定了不同的下载方式。对于问题追踪等来自web应用的数据，通常可以通过网络爬虫技术对页面进行检索和下载，如果该应用提供了数据访问的API，可以直接通过API来下载。这两种下载方式的缺陷包括两个方面，一方面是下载的伸缩性受到应用本身对数据访问频率的限制，对于大规模的数据，需要投入更多的IP地址及下载时间；另一方面是无论用户接口还是编程接口会发生版本的迭代，数据下载的逻辑可能需要变更，所下载的数据格式可能改变。对于版本控制等可以直接克隆或者镜像后台数据库的系统的数据，使用相应的工具或者命令进行下载。对于官方提供工具后台数据库dump的情况，研究者只要简单地进行下载即可，但数据的提供方需要做一定的处理工作，包括去除隐私、安全及其他敏感数据，才能对数据进行公开。未来研究的重点将是针对不同应用场景，如何高效高质量的定制数据集。
|
||||
|
||||
\subsubsection{数据的组织与存储}
|
||||
数据的组织与存储主要服务于后续的数据访问与分享。数据组织通常包括两个方面，数据格式的转换和数据模型的建立。一方面，某些原始数据的格式，例如web页面，版本控制库等，需要较为复杂的解析程序来进行数据的解析从而提取相应的信息。可以先将此类特殊格式的数据转换为较为通用、解析容易的格式，如CSV，JSON，XML等，然后进行存储；另一方面，为了便于数据的检索和分析，有些数据基础设施会对数据进行建模，抽象出其中的实体与实体间的关系，按照定义的模型进行存储，例如Gousios[11]将通过GitHub API所收集到的非关系型的数据，按照其定义的关系模型存储在MySQL数据库中。根据数据组织方式的不同，数据一般会采用文件系统、数据库系统或者其他工具特定的方式，如版本控制系统，来进行存储。采用何种方式进行数据的存储取决于原始数据的类型和数据收集者所设计的应用场景。此外，多源异构数据的存在使得如何建立不同数据源间的联系成为了其中的重要研究问题之一。
|
||||
|
||||
\subsubsection{数据的质量}
|
||||
高质量的数据是对软件开发实践进行分析、预测、推荐的基础。确保软件数据质量主要从两个角度出发。首先，取决于数据清洗。数据清洗的目的在于去除影响数据分析结果的“脏数据”，例如，在问题追踪系统中，某个问题报告的评论中可能含有广告等无关软件开发活动的数据，他们会影响基于评论数量、评论时间等度量的准确性从而威胁到分析得出的结论。一般而言，去除“脏数据”的过程更多地体现在具体的数据分析中，在目前大多数数据基础设施的建立过程中，由于没有针对特定的研究问题，数据清洗的工作涉及较少。其次，应该关注数据与上下文是否相匹配[33]。如果不匹配，这可能使得基于问题数据的方法、软件产生的结果存在偏差,甚至无效。例如,Kim 等人[31]在利用问题追踪数据智能化预测任务完成时间的工作中,将问题报告被标记为“已解决”的时间点视为该任务完成的时刻。然而Zheng 等人[32]发现：任务完成的时间存在问题——开发者在完成任务后可能并不会及时将问题报告标记为“已解决”,而是在之后清理问题追踪系统时,通过脚本进行批量处理,即“任务完成时间”并不能真正代表任务被解决的时刻。因此,Kim 等人的结果存在偏差。我们相信,随着人们对软件生态的认识逐渐深入,数据质量问题会得到越来越多的关注(鉴于软件生态相关研究对于数据的依赖)。同时希望有越来越多的努力构建出可靠的数据集,或者构建相应的方法来产生可靠的数据集。此外，用自动化的方法来检测和修正问题数据也应是未来研究应关注的重点内容之一。
|
||||
|
||||
\subsection{软件供应链的度量与分析}
|
||||
在大数据时代，基于多源信息融合研究如何规避供应链风险对软件质量保证至关重要。软件供应链在为开发人员提供便利的同时，也引进了新的风险和不确定性。一方面供应链上任何一个节点的问题都可能波及到链条上的其它节点，使得损失被放大，例如月下载量千万的npm包就曾被黑客篡改，大批开发者的权益可能会被侵犯或已经被侵犯\footnote{https://github.com/dominictarr/event-stream/issues/116}；另一方面任何一个节点会需要承受链条上所有其他节点的问题，仍然是损失会放大。因此，对于“软件生态供应链”风险的评估就变得愈发重要，很多企业（尤其是大企业）在这方面的需求不断增加。研究上需要对形成软件供应链的软件之间的功能性、组织性依赖关系进行大规模的深入分析。值得一提的是，随着软件活动数据越来越丰富，研究软件供应链的理论基础开始从原来的数据少、基于定性的方法向数据丰富、基于量化的方法转变。这提供了更好的方法来量化供应链中的风险及其传递，进而为降低这些风险及其影响力提供了契机。但需要指出的是，由于软件供应链几乎囊括了开发、运行过程中涉及到的所有软硬件，涉及项目众多，项目间关系极其复杂，该方面的研究目前还处于初始阶段。
|
||||
|
||||
\subsection{个体学习与群体协作的研究}
|
||||
作为软件涉众之一的开发者，他们在软件生态中扮演者非常重要的角色。如何帮助新开发者快速加入复杂生态以及提高群体协作效率是一大关键研究内容。
|
||||
|
||||
\subsubsection{个体学习}
|
||||
随着软件生态变得越来越复杂，个体如何学习并加入生态存在诸多障碍。为了向他们提供有效帮助，相关研究应重点关注两个方面：研究如何利用数据来度量个体学习能力，以及如何借鉴社会学的研究方法和洞见来研究软件开发的社会性特征及相关问题。
|
||||
|
||||
软件开发最根本问题在于开发者个体的复杂性，主要挑战在于个体（学习）能力的度量和评估—无法度量也就无法揭示问题所在，进而难以控制其复杂性。海量的软件开发历史数据和先进的分析方法和工具使得探索并解决该问题成为可能。例如，通过对软件开发中的多源数据（包括版本控制、任务追踪、人力资源等数据）进行融合来度量开发者的开发任务随时间的变化，对任务的价值和难度、所体现的开发者人际关系进行多维度的刻画，建立程序员成熟度的度量框架，以此来评估开发者经验的成长轨迹[8][9] 。这些度量方法和结果为我们更好的探究软件项目个体开发者的学习和能力成长提供了坚实的基础和依据。未来还要很多研究工作需要深入，包括更好支持评估项目中程序员的技能与效率，支持对程序员成长轨迹的精确分析，为初学者选择合适的开发任务等。
|
||||
|
||||
社会科学领域的诸多学科，例如认知学、发展心理学、组织管理学，已经对人类学习有许多研究。更确切地说，意识和脑、思考和学习的方式、解决问题过程中神经的行为和能力的提升都被集中地研究。并且，多个分支学科发现的证据存在交集[10] ，使得多学科交叉发展以追求对人类学习的更全面的认识成为一个重要趋势。因此，如何借用这些学科的视角去理解开发者的学习是主要研究内容之一。这方面已有很多研究值得借鉴。例如Curtis论证认知学就是这样一个范例[11]，它提供了很好的方式去理解影响项目表现的最重要因素。此外，我们还能基于对开发者学习的研究结果普适性地理解人类学习。在过去的几十年里，人们花费了大量的努力试图解开工作绩效的决定因素。在一开始人们普遍认为导致异常表现的特征是天生的，并且是遗传的[12]。然而，Ericsson等人[13]的研究表明，许多曾经被认为反映天赋的特征实际上是经过了长达十年的紧张练习的结果。周等的一个工作借用管理科学的一个框架来表征开源贡献者进入社区的初始行为特征[14]，并利用其在社区的初始活动数据来度量该框架的三个维度，如图\ref{fig:fig4}所示。他们发现，新加入的贡献者成为长期贡献者（long term contributor，在社区中持续贡献三年以上）的可能性与他的能力（ability）、意愿（willingness）以及环境因素（environment）有关，例如，其参与社区的意愿（量化为其所报告的问题是否会得到解决，表征了该问题的质量，即报告者为报告该问题所倾入的精力）能够使其成为长期贡献者的概率加倍[8][12]。这个工作建立了一个开发者初始行为度量体系，支持对开发者长期贡献的分析预测。
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[scale=1]{fig2-9/fig5.png}
|
||||
\caption{开发者行为特征的理论框架与相关量度}
|
||||
\label{fig:fig4}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{群体协作}
|
||||
从大规模数据挖掘细粒度的微过程[16]，是找到可复现群体协作活动的可能途径。微过程是项目在完成各项特定任务（例如解决bug，提交代码，沟通需求，指导新手等）时所采用的方式方法或活动流程，对微过程的度量是获取细粒度可复制最佳实践的关键。如图\ref{fig:fig5}所示，微过程研究可以从广度和深度两个方面来开展，分这两种选择主要是从时间和成本上来考虑。相关研究工作也是从这两方面展开的。
|
||||
|
||||
广度研究是指，从尽可能广阔的视角上（例如覆盖尽可能多的项目）去探索问题。例如，朱等以GitHub中海量软件项目为样本研究了项目中文件目录的使用模式及其对项目流行度的影响[17]，发现标准文件夹（例如文档，测试和示例）不仅是最常用的文件夹，而且其使用与项目流行度（即项目fork数量）密切相关。对文件夹使用的初步研究表明，可以借鉴频繁模式挖掘获得的文件夹使用模式，量化和改进文件的组织实践。Ohira等人[18]对拥有大量开发人员和项目的大型在线社区SourceForge.net进行分析，发现开发者群体协作关系呈现无标度网络（scale-free network）特征。即，只有少数开发者加入了许多项目并与其他开发者建立了丰富的链接，而大多数开发者加入的项目很少，并且与其他项目的社交关系非常有限。通过对开发者社交网络的构建，有助于帮助开发者定位沟通对象，识别有经验的开发者，从而提高群体协作的效率和质量。
|
||||
|
||||
深度研究是指以典型案例为研究对象进行深入探索。例如，针对软件项目缺陷追踪工作流中的一个微过程：产品定位，谢等发现了影响其质量的若干关键因子并提出了度量方法，进而设计了一个工具PAR（Product Assignment Recommender）用于预测缺陷报告是否被准确定位，然后应用到了Mozilla十年历史中的88,000 个缺陷报告[19]。结果表明，该工具的精度达到73.65%，比随机预测的精确度高3.4倍，有助于改进缺陷报告的质量。又例如，谭等研究了开源贡献者对同一代码文件进行修改的最佳合作模式。提出以集中度、复杂度和稳定性来刻画同一个文件的代码贡献组成，并以OpenStack的核心项目Nova为例归纳出3种贡献组成模式。这些模式可以用来对代码贡献提出推荐，例如，对于逻辑复杂、代码量大的文件（例如实现系统核心功能的文件等），一旦出现问题会直接导致系统不能正常工作，最好由两名以上核心开发者进行开发和维护，这样在某个开发者离开时，不会出现无监管状态[20]。以上研究都从多个维度对群体协作进行了度量，所得出的研究结果可以为复杂的群体社会化开发提供相关建议。
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[scale=0.3]{fig2-9/fig4.png}
|
||||
\caption{微过程研究模式图}
|
||||
\label{fig:fig5}
|
||||
\end{figure}
|
||||
|
||||
\subsection{软件生态机制机理的研究}
|
||||
探究生态系统构建及其持续发展的理论、方法与技术是软件数字社会学的又一大关键研究内容。软件生态在近十多年的发展中得到了学术界和产业界的广泛关注。主要研究内容包含以下两个方面。
|
||||
|
||||
\subsubsection{软件生态系统的形成和演化}
|
||||
此类研究的主要目的是通过分析生态系统的历史数据度量生态的健康状态并建立可持续发展理论等。例如，Gamalielsson等人基于邮件列表中回复者的质量，提出将响应能力作为软件生态系统健康度的评价指标[26]。Lehman等提出软件生态系统的成熟理论用来评估软件的进化，例如生存能力，增长潜力等[27]。我们有个工作是通过挖掘Linux内核的开发历史数据，从Maintainer工作量的角度来探究影响Linux kernel生态系统可持续演化的关键因素[28]。结果表明Linux kernel的任务规模和Maintainer数量都随时间持续增长，且尽管Maintainer的平均负载随时间有降低的趋势，但因为工作量分布的不均衡性，少数Maintainer仍然存在过劳现象。Linux kernel的部分模块如硬件驱动程序只有不足20%的Maintainer负责审查80%的代码提交。这种核心Maintainer负载过重的情况将直接影响软件生态的持续稳定发展。该工作还发现为一个文件指派多个Maintainer只能提高1/2的生产率。因此，寻找降低软件生态管理复杂度的解决方案将是未来工作的一个重点。
|
||||
|
||||
\subsubsection{软件生态系统中的商业参与}
|
||||
此类研究重点关注开源软件生态系统，的目的是探究商业参与模式及其对开源生态的影响并寻找可能的有效实践。例如，我们面向三个技术同构的混合项目（JBossAS，JOnAS，Geronimo，均为实现JavaEE规范的应用服务器项目）进行了实证分析[23]，通过收集分析互联网上大量文本信息以及项目开发活动数据建立了三个商业参与模型，并量化了不同模型对贡献者参与的影响。该研究发现重度商业参与会减少新来者但同时提高贡献者的持续度。我们另一个研究OpenStack（开源云计算平台）的工作也发现，个别商业公司对开源项目的高强度控制会降低其他公司以及个体开发者的参与[29]。我们还探索了商业公司广泛参与OpenStack的现状[22]，研究表明，来自不同行业的公司会通过有选择地对OpenStack生态中某些子项目做贡献来实现它们的特定目标，例如IBM和Intel会向OpenStack贡献大量的驱动和插件来实现软硬件兼容。不同公司的贡献方式也有很大差别，例如有的公司会将贡献重心放在文档编写上。总的来说，现有工作尚未很好的解决众多商业组织和非营利机构的参与给开源生态带来的诸多挑战。相反很多研究案例折射出了目前开源生态系统在商业与开源混合时的困局。未来的挑战在于从各个角度探索以深入并全面地刻画开源生态系统中的商业参与。
|
||||
|
||||
\section{本章小结}
|
||||
现如今全球化的软件开发面临复杂性不断扩张的问题：软件规模急剧增长、代码依赖错综复杂；开发者个体差异大、群体协作难以控制；广泛的社会参与形成复杂生态等。这些问题为研究软件生态带来了巨大挑战。在这一章中，我们从软件生态的三个层次出发，指出了软件生态面临的几大挑战问题。同时，我们也围绕这几大挑战问题，列出了一些重要研究内容，期待能帮助人们更好的理解和构建软件生态，也希望能为相关研究人员带来一些新观点和新视角。
|
||||
|
||||
\section{参考文献}
|
||||
[1] 赵兰香等主编. 科技发展新态势与面向2020年的战略选择[J]. 中国科学院院刊, 2013(5).
|
||||
|
||||
[2] Herbsleb J D, Moitra D. Global software development[J]. IEEE Software, 2001, 18(2): 16-20.
|
||||
|
||||
[3] Mockus A. Keynote: Measuring Open Source Software Supply Chains. NASAC, 2017.
|
||||
|
||||
[4] Astromskis S, Bavota G, Janes A, et al. Patterns of developers behaviour: A 1000-hour industrial study[J]. Journal of Systems and Software, 2017, 132: 85-97.
|
||||
|
||||
[5] Manikas K, Hansen K M. Software ecosystems–A systematic literature review[J]. Journal of Systems and Software, 2013, 86(5): 1294-1306.
|
||||
|
||||
[6] Vygotsky, L. Interaction between learning and development. Readings on the Development of Children, 1978, 23.3: 34-41.
|
||||
|
||||
[7] Schach S R. Object-oriented and classical software engineering[M]. McGraw-Hill, 2002.
|
||||
|
||||
[8] Zhou M, Mockus A. What make long term contributors: Willingness and opportunity in OSS community[C]//International Conference on Software Engineering. IEEE, 2012:518-528.
|
||||
|
||||
[9] Tan, X., Qin, H., \& Zhou, M. Understanding the variation of software development tasks: A qualitative study. //Proceedings of the 9th Asia-Pacific Symposium on Internetware. ACM, 2017.
|
||||
|
||||
[10] National Research Council. How people learn: Brain, mind, experience, and school: Expanded edition[M]. National Academies Press, 2000.
|
||||
|
||||
[11] Curtis B. Fifteen years of psychology in software engineering: Individual differences and cognitive science[C]//Proceedings of the 7th International Conference on Software Engineering. IEEE Press, 1984: 97-106.
|
||||
|
||||
[12] Neisser U, Boodoo G, Bouchard Jr T J, et al. Intelligence: knowns and unknowns[J]. American Psychologist, 1996, 51(2): 77.
|
||||
|
||||
[13] Ericsson K A, Krampe R T, Tesch-Römer C. The role of deliberate practice in the acquisition of expert performance[J]. Psychological Review, 1993, 100(3): 363.
|
||||
|
||||
[14] Zhou, M., \& Mockus, A. Who will stay in the floss community? Modeling participant’s initial behavior. IEEE Transactions on Software Engineering, 41(1), 82-99, 2015
|
||||
|
||||
[15] Herbsleb J D, Moitra D. Global software development[J]. IEEE Software, 2001, 18(2): 16-20.
|
||||
|
||||
[16] Zhou M, Mockus A. Mining micro-practices from operational data[C]
|
||||
//Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. ACM, 2014: 845-848.
|
||||
|
||||
[17] Zhu J, Zhou M, Mockus A. Patterns of folder use and project popularity: a case study of github repositories[C]// Acm/IEEE International Symposium on Empirical Software Engineering \& Measurement. ACM, 2014:1-4.
|
||||
|
||||
[18] Ohira M, Ohoka T, Kakimoto T, et al. Supporting knowledge collaboration using social networks in a large-scale online community of software development projects[C]//12th Asia-Pacific Software Engineering Conference (APSEC'05). IEEE, 2005: 6 pp.
|
||||
|
||||
[19] Xie J, Zheng Q, Zhou M, et al. Product assignment recommender[C]
|
||||
//Companion Proceedings of the 36th International Conference on Software Engineering. ACM, 2014: 556-559.
|
||||
|
||||
[20] 谭鑫,林泽燕,张宇霞,周明辉.代码文件贡献组成模式的分析[J].软件学报,2018,29(8):2283−2293.
|
||||
|
||||
[21] OpenStack Foundation, http://stackalytics.com/?
|
||||
project\_type
|
||||
=all\&metric=commits, 2018
|
||||
|
||||
[22] 张宇霞,周明辉,张伟,等. OpenStack开源社区中商业组织的参与模式[J]. 软件学报, 2017, 28(6): 1343-1356.
|
||||
|
||||
[23] Zhou M, Mockus A, Ma X, et al. Inflow and retention in oss communities with commercial involvement: A case study of three hybrid projects[J]. ACM Transactions on Software Engineering and Methodology (TOSEM), 2016, 25(2): 13.
|
||||
|
||||
[24] Chris Mellor. Aperi dies on its arse. The Register, https://
|
||||
www.theregister.co.uk/2009/01/30/aperi\_is\_dead/ (2009).
|
||||
|
||||
[25] CIO Staff, https://www.cio.com/article/2442437/open-source-tools/
|
||||
jboss-head-marc-fleury-leaves-red-hat.html , 2018
|
||||
|
||||
[26] Gamalielsson J, Lundell B, Lings B. Responsiveness as a measure for assessing the health of OSS ecosystems[C]//Proceedings of the 2nd International Workshop on Building Sustainable Open Source Communities (OSCOMM 2010). Tampere: Tampere University of Technology, 2010: 1-8.
|
||||
|
||||
[27] Lehman M M, Ramil J F, Wernick P D, et al. Metrics and laws of software evolution-the nineties view[C]//Proceedings Fourth International Software Metrics Symposium. IEEE, 1997: 20-32.
|
||||
|
||||
[28] Zhou M, Chen Q, Mockus A, et al. On the scalability of Linux kernel maintainers' work[C]//Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering. ACM, 2017: 27-37.
|
||||
|
||||
[29] Zhang Y, Tan X, Zhou M, et al. Companies' domination in FLOSS development: an empirical study of OpenStack[C]//Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings. ACM, 2018: 440-441.
|
||||
|
||||
[30] Mockus A. Amassing and indexing a large sample of version control systems: Towards the census of public source code history[C]// Mining Software Repositories, 2009. MSR '09. 6th IEEE International Working Conference on. IEEE, 2009:11-20.
|
||||
|
||||
[31] Kim S, Jr. Whitehead EJ. How long did it take to fix bugs? In: Proc. of the 2006 Int’l Workshop on Mining Software Repositories.ACM Press, 2006. 173−174.
|
||||
|
||||
[32] Zheng Q, Mockus A, Zhou M. A method to identify and correct problematic software activity data: Exploiting capacity constraints and data redundancies. In: Proc. of the 2015 9th Joint Meeting on Foundations of Software Engineering. ACM Press, 2015.637−648.
|
||||
|
||||
[33] 涂菲菲,周明辉.软件开发活动数据的数据质量问题.软件学报,
|
||||
2019,30(5):1522−1531. http://www.jos.org.cn/1000-9825/5727.htm
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 203 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 53 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 53 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 326 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 63 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 141 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 162 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 141 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 468 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 80 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
48
main.tex
48
main.tex
|
|
@ -14,17 +14,57 @@
|
|||
|
||||
\tableofcontents
|
||||
|
||||
\input{Ch0-1-Abstract.tex}
|
||||
%\input{Ch0-1-Abstract.tex}
|
||||
|
||||
\part{软件学科发展回顾}
|
||||
|
||||
\input{Ch1-1-Intro.tex}
|
||||
\chapter{软件学科历史回顾}
|
||||
\input{Ch1-1-History}
|
||||
|
||||
\chapter{程序设计语言与理论}
|
||||
\input{Ch1-2-ProgrammingLanguage}
|
||||
|
||||
\chapter{系统软件}
|
||||
\input{Ch1-3-SystemSoftware}
|
||||
|
||||
\chapter{软件工程}
|
||||
\input{Ch1-4-SoftwareEngineering}
|
||||
|
||||
\chapter{软件产业}
|
||||
\input{Ch1-5-SoftwareIndustry}
|
||||
|
||||
|
||||
\part{新时代的软件学科}
|
||||
bad
|
||||
|
||||
\chapter{引言}
|
||||
\input{Ch2-1-Overview}
|
||||
|
||||
\input{Ch2-1-Overview.tex}
|
||||
\chapter{软件理论}
|
||||
\input{Ch2-2-SoftwareTheory}
|
||||
|
||||
\chapter{软件语言}
|
||||
\input{Ch2-3-SoftwareLanguage}
|
||||
|
||||
\chapter{软件开发方法与技术}
|
||||
\input{Ch2-4-DevelopmentMethodology}
|
||||
|
||||
\chapter{操作系统与运行平台}
|
||||
\input{Ch2-5-OperatingSystem}
|
||||
|
||||
\chapter{数据管理}
|
||||
\input{Ch2-6-DataManagement}
|
||||
|
||||
\chapter{面向领域的应用软件系统}
|
||||
\input{Ch2-7-DomainApplication}
|
||||
|
||||
\chapter{软件质量与安全保障}
|
||||
\input{Ch2-8-Quality&Security}
|
||||
|
||||
\chapter{软件生态}
|
||||
\input{Ch2-9-SoftwareEcosystem}
|
||||
|
||||
\chapter{软件学科教育}
|
||||
\input{Ch2-10-Education}
|
||||
|
||||
\part{软件学科发展建议}
|
||||
and so so
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
\contentsline {part}{第一部分\hspace {1em}杞<EFBFBD>欢瀛︾<EFBFBD>鍙戝睍鍥為【}{5}
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
第一篇 第一章 软件学科历史回顾 Ch1-1-History
|
||||
第一篇 第二章 程序语言与理论 Ch1-2-ProgrammingLanguage
|
||||
第一篇 第三章 系统软件 Ch1-3-SystemSoftware
|
||||
第一篇 第四章 软件工程 Ch1-4-SoftwareEngineering
|
||||
第一篇 第五章 软件产业 Ch1-5-SoftwareIndustry
|
||||
|
||||
第二篇 第一章引言 Ch2-1-Overview
|
||||
第二篇 第二章 软件理论 Ch2-2-SoftwareTheory
|
||||
第二篇 第三章 软件语言 Ch2-3-SoftwareLanguage
|
||||
第二篇 第四章 软件开发方法与技术 Ch2-4-DevelopmentMethodology
|
||||
第二篇 第五章 操作系统与运行平台 Ch2-5-OperatingSystem
|
||||
第二篇 第六章-数据管理 Ch2-6-DataManagement
|
||||
第二篇 第七章 面向领域的应用软件系统 Ch2-7-DomainApplication
|
||||
第二篇 第八章软件质量与安全保障 Ch2-8-Quality&Security
|
||||
第二篇 第九章 软件生态 Ch2-9-SoftwareEcosystem
|
||||
第二篇 第十章 软件学科教育 Ch2-10-Education
|
||||
Binary file not shown.
Loading…
Reference in New Issue