CN115016832B - 一种深度分析软件组件依赖关系的方法及相关装置、平台 - Google Patents

Abstract

本申请公开的实施例提供了一种深度分析软件组件依赖关系的方法及相关装置、平台。其中，上述方法通过获取和识别目标软件包中的依赖配置文件分别发起、执行相应的组件依赖关系深度分析流程生成相应的组件依赖树分支，并根据所述组件依赖树分支最终生成目标软件包的完整组件依赖树，以解决现有技术无法全面掌握目标软件组件依赖关系、目标软件组件依赖关系获取难等问题。

Description

一种深度分析软件组件依赖关系的方法及相关装置、平台

技术领域

本申请公开的实施例主要涉及软件成分分析/开源软件安全测试技术领域，且更具体地，涉及一种深度分析软件组件依赖关系的方法及相关装置、平台。

背景技术

软件构（组）件化开发从根本上解决如何解决高效、可靠地构建和维护大规模软件的问题。随着各种软件组件在软件开发中的广泛使用，特别是开源组件的广泛应用，在理论上有助于提高软件开发效率，但是如何落实对组件（尤其是对开源组件在内的第三方组件）的合理有效利用，进而促进软件开发过程的降本增效，仍是本领域重要的研究和实践方向。

然而，随着各种组件在不同软件项目中的广泛应用，组件（包括但不限于自研组件、开源组件在内的第三方组件等）已经成为软件供应链中重要组成部分。但是，组件间错综复杂的依赖和引用关系使得软件供应链变得愈加复杂（这里主要是指开源组件）。开源软件在安全性上又往往缺少有效地审查和管理，进而给软件供应链安全带来安全风险和知识产权风险。开源组件引入导致的软件供应链复杂化趋势则更进一步加剧了上述问题的严重性。

要根除软件中的组件安全隐患和知识产权合规问题，首先就需要全面掌握其组件依赖关系（这里的软件组件依赖关系，除直接依赖外，还应当包含间接依赖；软件组件依赖关系一般以树形结构呈现）。在软件开发过程中，软件项目引入的组件通常是通过包管理器根据依赖配置文件进行配置，进而实现依赖的。当一个软件项目可能存在多层依赖关系，即在那些软件项目的依赖配置文件中的依赖组件（即直接依赖组件）中，有些又向下依赖了其他组件（即间接依赖组件），且一些间接依赖组件又可能向下依赖其他组件（同样仍为间接依赖组件）的情形，以此类推，直至再无更向下的依赖为止。而这些间接依赖的具体情况是无法直接在软件项目的配置中直接获取的。

在软件开发实践中，分析软件项目的组件依赖关系的一般做法是借助包管理器的查询依赖树命令实现的。然而，不同语言开发的程序通常由不同的包管理器管理、打包（甚至同一种语言开发的程序，因其功能定位的不同都可能采用不同的包管理器管理、打包）；也正因为此，对于一个跨语言开发的多语言软件项目，在对其进行组件依赖关系分析时，只有将该项目软件包分别导入不同的包管理器分别进行解析、查询，并汇总该软件项目所涉各编程语言下的依赖树，才能得到该软件项目的组件依赖关系的全貌。而考虑到一些包管理器对树形结构的自动去重功能，这样得到的依赖树还未必准确。

此外，在业界，一类新兴技术——SCA/OSS（Software Composition Analysis/Open Source Security，软件成分分析/开源软件安全测试技术）越来越多地应用于开源治理领域。其中，SCA/OSS作为一种主要针对开源软件（Open Source Software）的软件成分分析技术，其也提供基于组件依赖知识库的软件组件依赖分析/查询功能。然而，大多数的SCA/OSS产品的组件依赖知识库通常都是基于开源组件相关信息生成的；如此就导致这些SCA/OSS产品对自研组件、非官方渠道开源组件等覆盖不足，这不仅使得软件组件依赖关系分析的结果中缺少相关组件依赖的信息，而且还使得这些自研组件、非官方渠道开源组件等直接依赖或间接依赖的高危开源组件无法被暴露出来，对匆忙上线运营的软件系统埋下安全隐患以及许可证兼容等知识产权合规风险。

发明内容

根据本申请公开的实施例，提供了一种深度分析软件组件依赖关系的方法及相关装置、平台，通过获取和识别目标软件包中的依赖配置文件和根据其分别进行相应的组件依赖关系深度分析，进而生成若干相应的组件依赖树分支，以及结合上述组件依赖树分支最终生成目标软件包的完整组件依赖树，以解决现有技术无法全面掌握目标软件组件依赖关系、目标软件组件依赖关系获取难等问题。

在本公开的第一方面中，提供了一种深度分析软件组件依赖关系的方法。该方法包括：获取目标软件包；解析目标软件包，从中获取依赖配置文件，即第一依赖配置文件；对于大多数的要进行组件分析的软件包来说，其中通常有着若干个（不少于一个）的第一依赖配置文件（注：至少是推测其中会有若干第一依赖配置文件；当然若未能在目标软件包中获得第一依赖配置文件，通常就会认定目标软件包没有依赖任何组件，进而不再也无法进行后续的相关分析）；根据上述的第一依赖配置文件分别发起若干条（与第一依赖配置文件一一对应的）组件依赖关系深度分析流程，并通过执行这些组件依赖关系深度分析流程生成相应的组件依赖树分支；根据取得的所述组件依赖树分支最终生成目标软件包的完整组件依赖树。

在本公开的第二方面中，提供了一种深度分析软件组件依赖关系的装置。该装置包括：解析模块、调度模块和若干（不少于一个的）深度分析模块，以及生成模块；其中，解析模块用于解析目标软件包，从中获取依赖配置文件，即第一依赖配置文件；调度模块用于将第一依赖配置文件调度给相应的深度分析模块；深度分析模块用于落实组件依赖关系深度分析，进而获得相应的组件依赖树分支；生成模块用于最终的完整组件依赖树的生成；具体来说，大多数的要进行组件分析的软件包中通常都是有着若干个（不少于一个）的第一依赖配置文件的（注：至少是推测其中会有若干第一依赖配置文件；当然对于解析模块未能从目标软件包中获取到任何第一依赖配置文件的情形，通常认为其是目标软件包中没有第一依赖配置文件的例外情形，由于该情形下既不能通过直接分析取得任何任何组件依赖关系，也不会被调度模块调度到相关深度分析模块进行深度分析等，故而一般会直接认定目标软件包没有依赖其他组件，也即其组件依赖关系为空）；调度模块根据第一依赖配置文件将其调度给相应的深度分析模块进行深度分析，以获取所述第一依赖配置文件对应的组件依赖树分支；不同的深度分析模块分别用于发起和执行与之相应的组件依赖关系深度分析流程，为被调度给其的第一依赖配置文件生成对应的组件依赖树分支；生成模块根据目标软件包中所有的第一依赖配置文件对应的组件依赖树分支生成目标软件包的完整组件依赖树。

在本公开的第三方面中，提供了一种深度分析软件组件依赖关系的装置。该装置包括：至少一个处理器，和至少一个处理器耦合的存储器，以及存储在存储器中的计算机程序；其中的处理器执行所述计算机程序，能够实现第一方面述及的深度分析软件组件依赖关系的方法。

在本公开的第四方面中，提供了一种深度分析软件组件依赖关系的平台。该平台包括：输入单元、分析单元和输出单元；输入单元提供目标软件的输入；分析单元用于目标软件的组件依赖关系深度分析；输出单元用于输出分析单元针对目标软件组件依赖关系深度分析的结果。其中，输入单元用于目标软件以软件包形式提交，和/或用于目标软件的提交、转化以获取目标软件包；分析单元在针对目标软件开展组件依赖关系深度分析时，执行第一方面述及的深度分析软件组件依赖关系的方法落实相关分析；输出单元输出的目标软件组件依赖关系深度分析结果通常展示为可视化的树形图组件依赖树。

在本公开的第五方面中，提供了一种计算机可读存储介质。该介质上存储有软件成分分析相关的计算机指令；该计算机指令在被计算机处理器执行时能够实现第一方面述及的深度分析软件组件依赖关系的方法。

在本公开的第六方面中，提供了一种计算机程序产品。该程序产品包括计算机程序，该计算机程序在被计算机处理器执行时能够实现第一方面述及的深度分析软件组件依赖关系的方法。

应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。

附图说明

结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标注表示相同或相似的元素，其中：

图1示出了本公开的一些实施例中的深度分析软件组件依赖关系的过程的示意图；

图2示出了根据本公开的实施例的获取第二依赖配置文件过程中官方公共仓库（maven）的所述第二依赖配置文件及其对应组件存放示意图；

图3示出了本公开的一些实施例中的用于深度分析软件组件依赖关系的装置的框图；

图4示出了本公开的一些实施例中的用于深度分析软件组件依赖关系的平台的框图；

图5示出了能够实施本公开的多个实施例的计算设备的框图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

在本公开的实施例的描述中术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

在本公开的实施例的描述中技术术语“目标软件”是指任一的作为待检测分析对象的软件；这里的“目标软件”，包括但不限于软件项目源码包、源码文件等。其中，“目标软件包”，通常是指源码包，是“目标软件”的一种存在形式；对于非软件包形式提交的“目标软件”，具体可以通过IDE环境插件转化（例如压缩）输出可作为检测对象的“目标软件包”。

软件组件技术，特别是开源组件的发展，切实有效地提高软件开发效率，但也为软件开发管理引入了组件依赖问题。以开源软件为代表的组件安全、合规问题，以及软件开发过程中引入组件的管理缺失等，无疑都在严重威胁着软件供应链安全。组件间的层层引用不仅仅是会使软件供应链变得更加复杂，还很可能导致一些开源组件几乎不可控、不可知地出现在应用软件或软件制品中，进一步加剧软件供应链安全问题复杂化。面对上述问题，全面掌握软件组件依赖关系，包括其中的直接依赖关系和间接依赖关系，无疑是解决上述问题的重中之重。

然而，前面已经详细阐述了现有技术中通过包管理器的查询依赖树命令实现对软件组件依赖关系查询的弊端（即面对跨语言开发的多语言软件项目等分析对象时，只能获得不完整的组件依赖关系），即便基于此仍可通过分别导入不同包管理器分别获得各自的组件依赖关系并最终汇总得到完整组件依赖关系，相关方案在可操作性上也差强人意。而作为新兴技术的SCA/OSS虽然也提供软件成分分析功能，但是现有的SCA/OSS组件依赖分析同样不足以支撑相关人员获取目标软件完整组件依赖树。

具体来说，SCA软件成分分析是由IT研究咨询机构Gartner在关于DevSecOps的研究报告中提到的一种新型软件安全测试技术，其主要针对开源软件（Open SourceSoftware）以及第三方商业软件涉及的各种源码、模块、框架和库，识别和清点其中的组件，掌握其构成和依赖关系，并识别已知安全漏洞、许可证知识产权风险，尽可能排查这些隐患在应用上线运营前；OSS开源软件安全测试，顾名思义，主要是指一种基于多源SCA的、聚焦于开（混）源应用安全缺陷的检测技术。考虑到SCA通常也是主要用于揭示开源安全风险（这里泛指开/混源应用相关的），为开源安全治理提供指导，故在开源治理和供应链安全领域，SCA/OSS通常被视为一类技术。大多数公开的SCA/OSS组件依赖分析技术都是通过匹配组件依赖知识库中存储的组件依赖关系开展相关分析的；而组件依赖知识库中的这些组件依赖关系有都是通过访问开源软件项目，采集开源组件相关信息和经整理后获得的。如此，构建相关组件依赖知识库，不仅对于大多数开发者的自研组件的依赖关系获取显然是无法取得的，而且对于一些不甚规范的、自非官方渠道获取的开源组件的依赖关系也是力不能逮的。

于是，根据本公开的实施例，提出了一种深度分析软件组件依赖关系的方案。在该方案中，并不依托大多数现有SCA/OSS组件依赖分析技术中所依托的匹配组件依赖知识库（考虑到现实情况，其也很难覆盖全部组件），而是通过获取和识别目标软件包中的依赖配置文件和根据其分别进行相应的组件依赖关系深度分析、生成组件依赖树分支，并通过这些组件依赖树分支较为快速高效和相对便捷地获得完整组件依赖树，进而全面掌握目标软件组件依赖关系。相较于现有技术，上述方案无需借助包管理器、将目标软件包分别导入不同的包管理器，更加容易地获取目标软件组件依赖关系，还避免了因组件依赖知识库更新不及时和缺失等可能造成的结果不完整、不准确等。

以下将参照附图来具体描述本公开的实施例。图1示出了本公开的一些实施例中的深度分析软件组件依赖关系的过程的示意图。如图1所示，其中的深度分析软件组件依赖关系的过程100，主要包括：获取目标软件包并解析，从中获取依赖配置文件，即第一依赖配置文件；根据第一依赖配置文件分别发起若干条与之相应的组件依赖关系深度分析流程，并通过执行这些组件依赖关系深度分析流程生成相应的组件依赖树分支，以及根据上述组件依赖树分支生成目标软件包的完整组件依赖树。过程100中，获取目标软件包，以及解析目标软件包，从中获取依赖配置文件，即第一依赖配置文件（参考框101）。在框101，所述目标软件包，可以是以软件包形式提交的目标软件，例如源码包等；对于非软件包形式提交的“目标软件”，例如源码文件等，则可以通过IDE插件方式将其转化为可作为检测对象的“目标软件包”（即源码包），更具体地可以将其直接压缩成“目标软件包”，进而提交后续检测分析。在获取目标软件包后，解析目标软件包，以及可以通过遍历方式从中获取依赖配置文件，即第一依赖配置文件（参考框101）。当然若未能在目标软件包中发现任何第一依赖配置文件，则可以直接认定目标软件包没有依赖任何组件（换而言之，还可被描述为其组件依赖关系为空），直接汇报结果而不再进行相关分析。根据前面获得的第一依赖配置文件分别发与之一一对应的组件依赖关系深度分析流程，并通过执行这些组件依赖关系深度分析流程生成相应的组件依赖树分支（参考框102）。在框102，对于混编项目的目标软件包来说，通常有着多个第一依赖配置文件，故对应地一般也要发起等量的组件依赖关系深度分析流程，并通过执行这些组件依赖关系深度分析流程生成等量的组件依赖树分支。根据前面生成的组件依赖树分支生成目标软件包的完整组件依赖树（参考框103）。在框103，可以但不限于根据第一依赖配置文件间的关系生成所述完整组件依赖树。

在一些实施例中，在框102，根据第一依赖配置文件发起组件依赖关系深度分析流程的实现过程，可以是根据第一依赖配置文件的文件名确定其所对应的包管理器及模拟所述包管理器下载组件依赖获取相关组件依赖关系的过程。不同的编程语言各有优势，比如Java有着良好的交互性、跨平台性强，通常被用来开发与商业相关的网络应用。由于不同的编程语言出现的时间、面向的场景等都不同，后续发展差异明显，根据各自特点发展出了不同的包管理器。不同的编程语言通常都有去常用的包管理器，一些典型的编程语言及常用包管理器，例如，Java（maven）、Python（pip）、C/C++（conan）、Javascript（后端（npm））、前端（bower）、Ruby（bundle）等；且每一种包管理器一般有采取自己能够识别和利用的依赖管理文件（也即依赖配置文件），例如，maven的依赖配置文件的命名方式（即文件名（这里的文件名是指完整的文件名））是pom.xml、js的是package.json等。

这里以上述示例包管理器和依赖配置文件为例，详细说明上述过程。在该示例中，假定获取的第一依赖配置文件中包括名称为pom.xml和package.json的文件，那么，上述的根据第一依赖配置文件发起组件依赖关系深度分析流程的实现过程，具体包括：根据第一依赖配置文件pom.xml和第一依赖配置文件package.json确定相应的包管理器：maven和npm，使maven、npm分别根据第一依赖配置文件pom.xml、第一依赖配置文件package.json模拟maven、npm下载组件依赖过程但在该过程中只获取第一依赖配置文件pom.xml、第一依赖配置文件package.json中直接依赖组件的第二依赖配置文件pom.xml、第二依赖配置文件package.json以及进而获取其直接依赖组件/间接依赖组件向下依赖的依赖组件的第二依赖配置文件，而在该过程中不下载任何相关组件，以及进而根据所述第一依赖配置文件pom.xml/package.json和第二依赖配置文件pom.xml/package.json以及它们间的依赖关系生成分别对应第一依赖配置文件pom.xml/package.json的组件依赖树分支。

在一些实施例中，在框102，其中的组件依赖关系深度分析的实现过程，具体包括：解析每一个第一依赖配置文件，获取其中的组件依赖关系，以及根据其中的依赖组件（即直接依赖组件）的信息（例如maven的坐标等）取得访问本地仓库/私服仓库/官方公共仓库（均为存储组件及其依赖配置文件的仓库）的相关链接/途径，进而直接从中获取直接依赖组件的依赖配置文件（即第二依赖配置文件）；继续解析取得的第二依赖配置文件获取其中的组件依赖关系，以及重复上述访问组件仓库的方式根据其从本地仓库/私服仓库/官方公共仓库直接获取其中配置的依赖组件的依赖配置文件（也即第二依赖配置文件）；以此类推，直至再无更向下依赖的组件为止（或者说不能在发现新的第二依赖配置文件为止）。为了更加清晰地描述上述实现过程和阐明上述过程简单便利和低开销的特点，下面结合maven官方仓库及maven组件管理的特点进一步作详细介绍。

Maven是一种主要的针对Java 项目进行自动化的构建和依赖管理的项目管理工具。Maven通过坐标实现对组件的管理。一般的坐标要素包括厂商名称（Groupid）、组件名称（Artifactid）和版本号（Version），而仓库网址加坐标三要素往往构成访问该组件及其相关信息的url。图2示出了maven官方公共仓库组件及其依赖配置文件的存放示意图。如图2所示，“https://repo1.maven.org/maven2/”为maven官方公共仓库的网址；这里的官方公共仓库，包括官网仓库、官方镜像仓库等一系列被认可的、能够下载到官方组件的仓库。“org/springframework”为厂商名称、“spring-beans”为组件名称、“5.3.18”为组件版本号，而列表中的“spring-beans-5.3.18.jar”为spring-beans-5.3.18组件包，在正常的包管理打包下载组件过程中，只下载spring-beans-5.3.18.jar，“spring-beans-5.3.18.pom”则为组件spring-beans-5.3.18.jar的依赖配置文件（即第二依赖配置文件），其作为直接依赖组件/间接依赖组件的依赖配置文件，在包管理器打包时仅根据其下载spring-beans-5.3.18组件向下依赖的其他组件包，而不被打包在软件包中。在前面的组件依赖关系深度分析过程中，若其中的第一依赖配置文件配置中包括spring-beans-5.3.18组件，则根据其坐标获得访问链接“https://repo1.maven.org/maven2/org/springframework/spring-beans/5.3.18/”，并根据其访问官方公共仓库中spring-beans-5.3.18组件信息，并直接获取spring-beans-5.3.18.pom而不下载spring-beans-5.3.18.jar，并根据spring-beans-5.3.18.pom向下获取其他第二依赖配置文件以及根据其与上下层组件依赖关系生成相应的依赖树分支。

对应地，根据本公开的一些实施例，还提出了一种深度分析软件组件依赖关系的装置。图3示出了上述实施例中的用于深度分析软件组件依赖关系的装置的框图。如图3所示，其中的装置300包括：解析模块310、调度模块320和若干深度分析模块330，以及生成模块340。其中，解析模块310用于解析目标软件包，从中获取依赖配置文件，即第一依赖配置文件；调度模块320用于将第一依赖配置文件调度给相应的深度分析模块330；深度分析模块330用于落实组件依赖关系深度分析，获取相应的组件依赖树分支；生成模块340用于最终的完整组件依赖树的生成。上述实施例中的一些，具体地，解析模块310可以通过遍历方式从解析目标软件包中获取全部第一依赖配置文件，且大多数的软件包通常都有着若干个（不少于一个）的第一依赖配置文件；当然，对于未能从目标软件包中获取到任何第一依赖配置文件的情形，在一些实施例中，解析模块310可以直接认定目标软件包没有依赖其他组件，也可以说是认定其组件依赖关系为空。调度模块320则根据第一依赖配置文件将其调度给相应的深度分析模块330，进行发起等量的相关组件依赖关系深度分析流程，并通过执行这些组件依赖关系深度分析流程生成等量的相关组件依赖树分支。生成模块340则根据前面所有的组件依赖树分支生成目标软件包的完整组件依赖树。根据前面生成的组件依赖树分支生成目标软件包的完整组件依赖树（参考框103）。在生成完整组件依赖树的过程中，生成模块340可以但不限于根据第一依赖配置文件间的关系生成所述完整组件依赖树。

在一些实施例中，深度分析模块330分别通过模拟相应的包管理器下载组件依赖的过程为被调度给其的第一依赖配置文件生成对应的组件依赖树分支；而调度模块320则根据被调度给其的第一依赖配置文件的文件名确定其所对应的包管理器，进而将所述第一依赖配置文件调度到相应的深度分析模块；例如根据第一依赖配置文件pom.xml将其调度给对应模拟maven包管理器的深度分析模块330，根据第一依赖配置文件package.json将其调度给对应模拟npm包管理器的深度分析模块330，以获取相应的组件依赖树分支。具体地，深度分析模块330通过模拟包管理器下载组件依赖过程生成组件依赖树分支的过程，还包括只获取相关模拟下载过程中的第二依赖配置文件而不下载任何相关组件，并根据第一依赖配置文件和所取得的第二依赖配置文件（例如对应的一系列pom.xml、package.json）以及它们间的依赖关系生成第一依赖配置文件对应的组件依赖树分支。

在一些实施例中，深度分析模块330实现组件依赖关系深度分析的具体过程，可以是：对于被调度其上的第一依赖配置文件，获取其中的组件依赖关系，以及根据其从本地仓库/私服仓库/官方公共仓库直接获取所述第一依赖配置文件中配置的直接依赖组件的第二依赖配置文件；解析已获取的第二依赖配置文件，获取其中的组件依赖关系，以及根据其从本地仓库/私服仓库/官方公共仓库直接获取其中配置的依赖组件的第二依赖配置文件；以此类推，直至再无更向下依赖的组件为止（也即无法获得新的第二依赖配置文件为止）；进而根据前面获得的第一依赖配置文件和第二依赖配置文件以及它们间的依赖关系生成所述第一依赖配置文件对应的组件依赖树分支。这里的第二依赖配置文件，是指相应的第一依赖配置文件中配置的直接依赖组件的依赖配置文件或直接依赖组件又向下依赖/间接依赖的间接依赖组件的依赖配置文件。

根据本公开的一些实施例，基于上述关于软件组件依赖关系深度分析的方案，还进一步提出了一种深度分析软件组件依赖关系的平台。图4示出了上述实施例中的用于深度分析软件组件依赖关系的平台。如图4所示，其中的平台400包括：输入单元401、分析单元402和输出单元403；输入单元401提供目标软件的输入；分析单元402用于目标软件的组件依赖关系深度分析；输出单元403用于输出分析单元针对目标软件组件依赖关系深度分析的结果。为了提高平台检测分析的兼容性，为了进一步扩大平台支持的检测对象范围，输入单元还可以被配置地既支持软件包形式的目标软件提交，以及还可选择地提供目标软件提交、转化功能以获取目标软件包，支持包括但不限于源码文件等形式的目标软件通过IDE插件方式提交和转化压缩成源码包，进而提交后续检测分析；分析单元则在针对目标软件开展组件依赖关系深度分析时，执行上述任一实施例中提出的深度分析软件组件依赖关系的方法以落实相关分析。

在一些实施例中，为了便于开发人员理解和快速发现相关问题，输出单元403还可以可视化的树形图组件依赖树展示相关组件依赖关系深度分析结果。

根据本公开的一些实施例，还提出了一种深度分析软件组件依赖关系的装置；所述装置，具体地，可以是一种计算设备。图5示出了上述实施例的可以用来实施本公开的一些实施例的计算设备500的框图。如图5所示，计算设备500，包括中央处理器（CPU）501，其能够根据存储在只读存储器（ROM）502的计算机程序指令或从存储单元508加载到随机访问存储器（RAM）503中的计算机程序指令，来执行各种适当的操作和处理，在（RAM）503中，还可以存储计算设备500操作所需的各种程序代码、数据。CPU501、ROM502、RAM503通过总线504彼此相连，且输入/输出（I/O）接口505也与总线504相连。计算设备500的一些部件通过I/O接口505接入，包括：输入单元506，如键鼠等；输出单元507，如显示器等；存储单元508，如磁盘、光盘、固态硬盘（SSD）等，以及通信单元509，如网卡、调制解调器等。通信单元509能够使计算设备500通过计算机网络与其他设备交换信息/数据。CPU501能够执行上述实施例中描述的各种方法和处理过程，例如过程100。在一些实施例中，过程100，可以被实现为计算机软件程序，其被例如存储单元508等的计算机可读介质。在一些实施例中，计算机程序的部分或全部被载入或安装到计算设备500。当计算机程序被加载到RAM503被CPU501执行时，能够执行过程100的部分或者全部操作。

本文中以上描述的功能都可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：场可编程门阵列（FPGA）、专用集成电路（ASIC）、专用标准产品（ASSP）、芯片上系统的系统（SOC）、负载可编程逻辑设备（CPLD）等等。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦除可编程只读存储器（EPROM或快闪存储器）、光纤、便捷式紧凑盘只读存储器（CD-ROM）、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以独立地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

Claims (10)

1.一种深度分析软件组件依赖关系的方法，应用于跨语言开发的多语言软件项目组件依赖关系深度分析，其特征在于，该方法包括：

获取目标软件包；

解析目标软件包，获取第一依赖配置文件；所述第一依赖配置文件是指目标软件包中的依赖配置文件；

对于目标软件包，若从中获得不少于一个的第一依赖配置文件，则根据所述第一依赖配置文件分别发起相应的组件依赖关系深度分析流程，并通过执行所述组件依赖关系深度分析流程生成相应的组件依赖树分支；其中包括：根据所述第一依赖配置文件确定其所对应的包管理器机制，进而分别发起相应的组件依赖关系深度分析流程，以及根据所述第一依赖配置文件中的依赖组件配置直接获取对应的第二依赖配置文件，和根据已经获取的第二依赖配置文件中的依赖组件配置直接获取对应的第二依赖配置文件，及如此逐层向下直接获取相应的第二依赖配置文件，并根据所述第一依赖配置文件以及获取的全部第二依赖配置文件获取以及它们间的依赖关系生成所述第一依赖配置文件对应的组件依赖树分支；所述的直接获取第二依赖配置文件，是指只直接下载所述第二依赖配置文件而不下载相关组件；

根据所述组件依赖树分支生成目标软件包的完整组件依赖树；

而若从中未获得任何第一依赖配置文件，则认定目标软件包没有依赖任何组件/组件依赖关系为空。

2.根据权利要求1所述的方法，其特征在于，

所述的根据第一依赖配置文件发起组件依赖关系深度分析流程的实现过程，包括：

根据当前的第一依赖配置文件的文件名确定其所对应的包管理器；所述的包管理器是指能够识别和利用当前第一依赖配置文件的包管理器；通过模拟所述包管理器下载组件依赖的过程，根据当前第一依赖配置文件中的依赖组件配置只获取该过程的第二依赖配置文件而不下载任何相关组件，并根据当前第一依赖配置文件和所取得的第二依赖配置文件以及它们间的依赖关系生成当前第一依赖配置文件对应的组件依赖树分支；

其中，所述的第二依赖配置文件，是指当前第一依赖配置文件中配置的直接依赖组件的依赖配置文件或所述直接依赖组件又向下依赖/间接依赖的间接依赖组件的依赖配置文件。

3.根据权利要求1或2任一所述的方法，其特征在于，

所述的组件依赖关系深度分析的实现过程，具体包括：解析当前的第一依赖配置文件，获取其中的组件依赖关系，以及根据其从本地仓库/私服仓库/官方公共仓库直接获取当前第一依赖配置文件中配置的直接依赖组件的第二依赖配置文件；所述的第二依赖配置文件，是指当前第一依赖配置文件中配置的直接依赖组件的依赖配置文件或所述直接依赖组件又向下依赖/间接依赖的间接依赖组件的依赖配置文件；解析所述的已获取的第二依赖配置文件，获取其中的组件依赖关系，以及根据其从本地仓库/私服仓库/官方公共仓库直接获取其中配置的依赖组件的第二依赖配置文件；以此类推，直至再无更向下依赖的组件为止；

进而根据当前第一依赖配置文件和所有已获取的第二依赖配置文件以及它们间的依赖关系生成当前第一依赖配置文件对应的组件依赖树分支。

4.一种深度分析软件组件依赖关系的装置，应用于跨语言开发的多语言软件项目组件依赖关系深度分析，其特征在于，该装置包括：

解析模块、调度模块和深度分析模块，以及生成模块；

其中，解析模块用于解析目标软件包，获取第一依赖配置文件；

调度模块用于根据第一依赖配置文件确定对应包管理器，进而调度所述第一依赖配置文件给相应的深度分析模块进行深度分析；

深度分析模块用于进行组件依赖关系深度分析，生成相应的组件依赖树分支；

生成模块用于最终的完整组件依赖树的生成；

在所述装置中，包括有不少于一个的深度分析模块；

调度模块根据第一依赖配置文件将其调度给相应的深度分析模块进行深度分析；

各个深度分析模块分别用于发起和执行与之相应的组件依赖关系深度分析流程，为被调度给其的第一依赖配置文件生成对应的组件依赖树分支；所述深度分析模块根据被调度给其的第一依赖配置文件中的依赖组件配置直接获取对应的第二依赖配置文件，和根据已经获取的第二依赖配置文件中的依赖组件配置直接获取对应的第二依赖配置文件，及如此逐层向下直接获取相应的第二依赖配置文件，并根据所述第一依赖配置文件以及获取的全部第二依赖配置文件获取以及它们间的依赖关系生成所述第一依赖配置文件对应的组件依赖树分支；所述的直接获取第二依赖配置文件，是指只直接下载所述第二依赖配置文件而不下载相关组件；

生成模块则根据目标软件包下所有所述组件依赖树分支生成目标软件包的完整组件依赖树。

5.根据权利要求4所述的装置，其特征在于，

所述的深度分析模块分别通过模拟相应的包管理器下载组件依赖的过程为被调度给其的第一依赖配置文件生成对应的组件依赖树分支；

而所述的调度模块则根据被调度给其的第一依赖配置文件的文件名确定其所对应的包管理器，进而将所述第一依赖配置文件调度到相应的深度分析模块；

其中，所述第一依赖配置文件对应的包管理器是指能够识别和利用所述第一依赖配置文件的包管理器；

所述的通过模拟包管理器下载组件依赖过程生成组件依赖树分支的过程，具体包括根据所述第一依赖配置文件中的依赖组件配置只获取该过程的第二依赖配置文件而不下载任何相关组件，并根据所述第一依赖配置文件和所取得的第二依赖配置文件以及它们间的依赖关系生成所述第一依赖配置文件对应的组件依赖树分支；

其中，所述的第二依赖配置文件，是指所述第一依赖配置文件中配置的直接依赖组件的依赖配置文件或所述直接依赖组件又向下依赖/间接依赖的间接依赖组件的依赖配置文件。

6.根据权利要求4或5任一所述的装置，其特征在于，

所述的深度分析模块实现组件依赖关系深度分析的具体过程包括：对于被调度其上的第一依赖配置文件，获取其中的组件依赖关系，以及根据其从本地仓库/私服仓库/官方公共仓库直接获取所述第一依赖配置文件中配置的直接依赖组件的第二依赖配置文件；所述的第二依赖配置文件，是指所述第一依赖配置文件中配置的直接依赖组件的依赖配置文件或所述直接依赖组件又向下依赖/间接依赖的间接依赖组件的依赖配置文件；解析所述的已获取的第二依赖配置文件，获取其中的组件依赖关系，以及根据其从本地仓库/私服仓库/官方公共仓库直接获取其中配置的依赖组件的第二依赖配置文件；以此类推，直至再无更向下依赖的组件为止；进而根据所述第一依赖配置文件和所有已获取的第二依赖配置文件以及它们间的依赖关系生成所述第一依赖配置文件对应的组件依赖树分支；

和/或，

当所述的解析模块未从目标软件包中获取到任何第一依赖配置文件时，则直接判定目标软件包没有依赖其他组件/组件依赖关系为空。

7.一种深度分析软件组件依赖关系的装置，其特征在于，该装置包括：

至少一个处理器，和至少一个处理器耦合的存储器，以及存储在存储器中的计算机程序；

其中的处理器执行所述计算机程序，能够实现权利要求1-3任一所述的深度分析软件组件依赖关系的方法。

8.一种深度分析软件组件依赖关系的平台，其特征在于，该平台包括：

输入单元、分析单元和输出单元；

输入单元提供目标软件的输入；

分析单元用于目标软件的组件依赖关系深度分析；

输出单元用于输出分析单元针对目标软件组件依赖关系深度分析的结果；

其中，输入单元用于目标软件以软件包形式提交，和/或用于目标软件的提交、转化以获取目标软件包；

分析单元在针对目标软件开展组件依赖关系深度分析时，执行权利要求1-3任一所述的深度分析软件组件依赖关系的方法。

9.根据权利要求8所述的平台，其特征在于，

所述的输出单元输出的目标软件组件依赖关系深度分析结果展示为可视化的树形图组件依赖树。

10.一种计算机可读存储介质，其特征在于，

该介质上存储有软件成分分析相关的计算机指令；

在被计算机处理器执行时能够实现权利要求1-3任一所述的深度分析软件组件依赖关系的方法。

Images