CN111475164A - 组件依赖关系检测方法、装置以及电子设备 - Google Patents

Abstract

本申请公开了组件依赖关系检测方法、装置以及电子设备，涉及软件处理技术领域。具体实现方案为：在对软件进行编译的过程中，获取软件中待处理的组件，以及组件对应的编译文件；对组件对应的编译文件进行扫描，确定组件的现有依赖关系列表；根据组件的现有依赖关系列表以及软件的依赖范畴文件，确定现有依赖关系列表中是否存在不允许依赖的第一组件；在现有依赖关系列表中存在第一组件时，进行编译报错提示，从而能够自动检测组件之间的依赖关系是否合理，效率高，且成本低。

Description

组件依赖关系检测方法、装置以及电子设备

技术领域

本申请涉及数据处理技术领域，具体涉及软件处理技术领域，尤其涉及组件依赖关系检测方法、装置以及电子设备。

背景技术

目前在Android工程中，组件之间的依赖关系，存在合理的依赖关系以及不合理的依赖关系，不合理的依赖关系，例如，项目X中的组件A依赖一个非合理的组件B，组件B不是项目X所需要的，甚至B组件因为代码体积庞大或者依赖关系更庞杂，进而导致X项目臃肿，安装包体积过大。因此，需要对组件之间的依赖关系进行限制。

现有技术中，并没有具体实现用于限制组件之间的依赖关系。只能由工程人员去手动检查组件之间的依赖关系是否合理，效率低，且成本高。

发明内容

本申请提出一种组件依赖关系检测方法、装置以及电子设备，通过对软件中组件对应的编译文件进行扫描，确定组件的现有依赖关系列表；根据组件的现有依赖关系列表以及软件的依赖范畴文件，确定现有依赖关系列表中是否存在不允许依赖的第一组件，在存在时，进行编译报错提示，从而能够自动检测组件之间的依赖关系是否合理，效率高，且成本低。

本申请第一方面实施例提出了一种组件依赖关系检测方法，包括：在对软件进行编译的过程中，获取软件中待处理的组件，以及所述组件对应的编译文件；

对所述组件对应的编译文件进行扫描，确定所述组件的现有依赖关系列表；所述现有依赖关系列表中包括：所述组件所依赖的各个组件；

根据所述组件的现有依赖关系列表以及所述软件的依赖范畴文件，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件；

在所述现有依赖关系列表中存在所述第一组件时，进行编译报错提示。

在本申请一个实施例中，所述软件的依赖范畴文件的获取方式为，

获取所述软件的层级信息；所述层级信息包括：业务层级、服务层级和基础层级；

根据预设的依赖规则，确定所述业务层级、所述服务层级和所述基础层级中各个组件所允许依赖的组件；

根据所述各个组件所允许依赖的组件，生成所述依赖范畴文件。

在本申请一个实施例中，所述根据所述组件的现有依赖关系列表以及所述软件的依赖范畴文件，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件，包括：

根据所述软件的依赖范畴文件，确定所述组件的允许依赖关系列表；

根据所述组件的现有依赖关系列表和允许依赖关系列表，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件。

在本申请一个实施例中，所述依赖范畴文件包括：所述软件中各个组件的权重；

所述根据所述软件的依赖范畴文件，确定所述组件的允许依赖关系列表，包括：

获取所述依赖范畴文件中所述组件的权重，以及所述依赖范畴文件中对应的权重小于等于所述组件的权重的第二组件；

将所述第二组件的集合，确定为所述组件的允许依赖关系列表。

在本申请一个实施例中，所述依赖范畴文件包括：所述软件中各个组件对应的白名单；

所述根据所述软件的依赖范畴文件，确定所述组件的允许依赖关系列表，包括：

获取所述软件中所述组件的白名单；

将所述白名单，确定为所述组件的允许依赖关系列表。

本申请实施例的组件依赖关系检测方法，通过在对软件进行编译的过程中，获取软件中待处理的组件，以及组件对应的编译文件；对组件对应的编译文件进行扫描，确定组件的现有依赖关系列表；根据组件的现有依赖关系列表以及软件的依赖范畴文件，确定现有依赖关系列表中是否存在不允许依赖的第一组件；在现有依赖关系列表中存在第一组件时，进行编译报错提示，并中断编译过程，从而能够自动检测组件之间的依赖关系是否合理，效率高，且成本低。

本申请第二方面实施例提出了一种组件依赖关系检测装置，包括：

获取模块，用于在对软件进行编译的过程中，获取软件中待处理的组件，以及所述组件对应的编译文件；

第一确定模块，用于对所述组件对应的编译文件进行扫描，确定所述组件的现有依赖关系列表；所述现有依赖关系列表中包括：所述组件依赖的各个组件；

第二确定模块，用于根据所述组件的现有依赖关系列表以及所述软件的依赖范畴文件，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件；

处理模块，用于在所述现有依赖关系列表中存在所述第一组件时，进行编译报错提示。

在本申请一个实施例中，所述软件的依赖范畴文件的获取方式为，

获取所述软件的层级信息；所述层级信息包括：业务层级、服务层级和基础层级；

根据预设的依赖规则，确定所述业务层级、所述服务层级和所述基础层级中各个组件所允许依赖的组件；

根据所述各个组件所允许依赖的组件，生成所述依赖范畴文件。

在本申请一个实施例中，所述第二确定模块具体用于，

根据所述软件的依赖范畴文件，确定所述组件的允许依赖关系列表；

根据所述组件的现有依赖关系列表和允许依赖关系列表，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件。

本申请实施例的组件依赖关系检测装置，通过在对软件进行编译的过程中，获取软件中待处理的组件，以及组件对应的编译文件；对组件对应的编译文件进行扫描，确定组件的现有依赖关系列表；根据组件的现有依赖关系列表以及软件的依赖范畴文件，确定现有依赖关系列表中是否存在不允许依赖的第一组件；在现有依赖关系列表中存在第一组件时，进行编译报错提示，并中断编译过程，从而能够自动检测组件之间的依赖关系是否合理，效率高，且成本低。

本申请第三方面实施例提出了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的组件依赖关系检测方法。

本申请第四方面实施例提出了一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行如上所述的组件依赖关系检测方法。

上述可选方式所具有的其他效果将在下文中结合具体实施例加以说明。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是根据本申请第一实施例的示意图；

图2是软件层级信息的示意图；

图3是根据本申请第二实施例的示意图；

图4是根据本申请第三实施例的示意图

图5是用来实现本申请实施例的组件依赖关系检测方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

下面参考附图描述本申请实施例的组件依赖关系检测方法、装置以及电子设备。

图1是根据本申请第一实施例的示意图。其中，需要说明的是，本实施例提供的组件依赖关系检测方法的执行主体为组件依赖关系检测装置，组件依赖关系检测装置具体可以为硬件设备，或者硬件设备中的软件等。其中，硬件设备例如终端设备、服务器等。

如图1所示，组件依赖关系检测方法具体实现过程如下：

步骤101，在对软件进行编译的过程中，获取软件中待处理的组件，以及组件对应的编译文件。

本实施例中，软件具体可以指通过工程化方法构建得到的软件，构建得到的软件由各个组件构成。对软件进行编译的过程可以为，依次调用软件中的各个组件进行编译生成对应的编译文件，对编译文件进行检查操作，在各个编译文件检查均无误的情况下，进行打包处理，得到软件对应的安装包。对编译文件进行检查，例如检查运行编译文件后的输出格式是否有误、是否输出预设的错误数据等。但目前的编译过程并未涉及检查依赖关系是否合适。其中，编译文件例如可以为二进制文件。

本实施例中，在对软件进行编译的过程中，若某个组件的编译文件已生成，则可以对该组件的编译文件进行依赖关系检测。

本实施例中，软件的依赖范畴文件的获取方式可以为，获取软件的层级信息；层级信息包括：业务层级、服务层级和基础层级；根据预设的依赖规则，确定业务层级、服务层级和基础层级中各个组件所允许依赖的组件；根据各个组件所允许依赖的组件，生成依赖范畴文件。

本实施例中，软件层级信息的示意图可以如图2所示。在图2中，业务层级包括业务组件；服务层级包括：服务组件；基础层级包括：基础组件。预设的依赖规则可以包括：业务组件可以依赖业务组件、服务组件和基础组件；服务组件可以依赖服务组件和基础组件；基础组件不允许依赖业务组件和服务组件；服务组件不允许依赖业务组件。另外，依赖规则中还可以包括：软件架构师添加的各组件之间的不允许依赖关系和允许依赖关系，例如，组件A不允许依赖组件B等。

本实施例中，依赖范畴文件可以采用白名单机制或者权重机制得到，例如在权重机制下，依赖范畴文件可以包括：软件中各个组件的权重等。其中，在权重机制下，若组件A允许依赖组件B，则组件A的权重大于等于组件B的权重。其中，组件的权重，可以参考组件所在的层级的属性文件，或者组件的定义属性进行设置。白名单机制下，依赖范畴文件可以包括：软件中各个组件对应的白名单等。

步骤102，对组件对应的编译文件进行扫描，确定组件的现有依赖关系列表；现有依赖关系列表中包括：组件所依赖的各个组件。

本实施例中，若组件调用了其他软件，则在组件对应的编译文件中会有体现。通过扫描组件对应的编译文件，可以获取到组件的现有依赖关系列表。其中，现有依赖关系列表中包括：组件所依赖的各个组件的标识等。

步骤103，根据组件的现有依赖关系列表以及软件的依赖范畴文件，确定现有依赖关系列表中是否存在不允许依赖的第一组件。

本实施例中，组件依赖关系检测装置可以针对组件的现有依赖关系列表中的每个待查询组件去查询依赖范畴文件，判断待查询组件是否为允许依赖的第一组件。其中，现有依赖关系列表中的每个待查询组件可以用对应的标识进行标示。

步骤104，在现有依赖关系列表中存在第一组件时，进行编译报错提示。

本实施例中，在现有依赖关系列表中不存在第一组件时，确定组件通过依赖关系检测处理，可以对下一个待处理的组件进行依赖关系检测处理；若软件中所有的软件均通过依赖关系检测处理，则可以对软件中各个软件对应的二进制文件进行打包处理，得到软件对应的安装包。

本申请实施例的组件依赖关系检测方法，通过在对软件进行编译的过程中，获取软件中待处理的组件，以及组件对应的编译文件；对组件对应的编译文件进行扫描，确定组件的现有依赖关系列表；根据组件的现有依赖关系列表以及软件的依赖范畴文件，确定现有依赖关系列表中是否存在不允许依赖的第一组件；在现有依赖关系列表中存在第一组件时，进行编译报错提示，从而能够自动检测组件之间的依赖关系是否合理，效率高，且成本低。

图3为是根据本申请第二实施例的示意图。如图3所示，步骤103具体可以包括以下步骤：

步骤301，根据软件的依赖范畴文件，确定组件的允许依赖关系列表。

本实施例中，在权重机制下，依赖范畴文件可以包括：软件中各个组件对应的权重。对应的，组件依赖关系检测装置执行步骤301的过程具体可以为，获取依赖范畴文件中所述组件的权重，以及依赖范畴文件中对应的权重小于等于组件的权重的第二组件；将第二组件进行组合，得到组件的允许依赖关系列表。其中，对应的权重小于等于组件的权重的第二组件，例如可以为组件的下个层级组件或者下下个层级组件，或者可以为组件的相同层级组件。

本实施例中，权重的设置方法可以为，获取软件的层级信息；层级信息包括：业务层级、服务层级和基础层级；其中业务层级高于服务层级，服务层级高于基础层级；为层级高的组件设置较高的权重，为层级低的组件设置较低的权重；以及根据软件架构师的需要将部分组件设置为特定的权重。

本实施例中，在白名单机制下，依赖范畴文件可以包括：软件中各个组件对应的白名单。对应的，组件依赖关系检测装置执行步骤301的过程具体可以为，获取软件中组件的白名单；将白名单，确定为组件的允许依赖关系列表。其中，组件的白名单中包括有：组件允许依赖的各个组件。其中，白名单中的各个组件可以采用对应的标识进行标示。

本实施例中，特定组件的白名单中所包括的组件，为层级低于特定组件的组件，或者软件架构师根据需要设置的允许特定组件依赖的组件。

步骤302，根据组件的现有依赖关系列表和允许依赖关系列表，确定现有依赖关系列表中是否存在不允许依赖的第一组件。

本实施例中，组件依赖关系检测装置执行步骤302的过程例如可以为，针对组件的现有依赖关系列表中的每个待查询组件，去查询允许依赖关系列表，判断待查询组件是否存在于允许依赖关系列表中，若存在于允许依赖关系列表中，则确定待查询组件是允许依赖的；若不存在于允许依赖关系列表中，则确定待查询组件是不允许依赖的。

本申请实施例的组件依赖关系检测方法，通过在对软件进行编译的过程中，获取软件中待处理的组件，以及组件对应的编译文件；对组件对应的编译文件进行扫描，确定组件的现有依赖关系列表；根据软件的依赖范畴文件，确定组件的允许依赖关系列表；根据组件的现有依赖关系列表和允许依赖关系列表，确定现有依赖关系列表中是否存在不允许依赖的第一组件；在现有依赖关系列表中存在第一组件时，进行编译报错提示，从而能够自动检测组件之间的依赖关系是否合理，效率高，且成本低。

为了实现图1至图3所述实施例，本申请实施例还提出一种组件依赖关系检测装置。

图4是根据本申请第三实施例的示意图。如图4所示，该组件依赖关系检测装置400包括：获取模块410、第一确定模块420、第二确定模块430、处理模块440。

其中，获取模块410，用于在对软件进行编译的过程中，获取软件中待处理的组件，以及组件对应的编译文件；

第一确定模块420，用于对所述组件对应的编译文件进行扫描，确定所述组件的现有依赖关系列表；所述现有依赖关系列表中包括：所述组件所依赖的各个组件；

第二确定模块430，用于根据所述组件的现有依赖关系列表以及所述软件的依赖范畴文件，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件；

处理模块440，用于在所述现有依赖关系列表中存在所述第一组件时，进行编译报错提示。

在本申请一个实施例中，所述软件的依赖范畴文件的获取方式为，

获取所述软件的层级信息；所述层级信息包括：业务层级、服务层级和基础层级；

根据预设的依赖规则，确定所述业务层级、所述服务层级和所述基础层级中各个组件所允许依赖的组件；

根据所述各个组件所允许依赖的组件，生成所述依赖范畴文件。

在本申请一个实施例中，所述第二确定模块430具体用于，根据所述软件的依赖范畴文件，确定所述组件的允许依赖关系列表；

根据所述组件的现有依赖关系列表和允许依赖关系列表，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件。

在本申请一个实施例中，所述依赖范畴文件包括：所述软件中各个组件的权重；对应的，所述第二确定模块430具体用于，获取所述依赖范畴文件中所述组件的权重，以及所述依赖范畴文件中对应的权重小于等于所述组件的权重的第二组件；将所述第二组件的集合，确定为所述组件的允许依赖关系列表。

在本申请一个实施例中，所述依赖范畴文件包括：所述软件中各个组件对应的白名单；对应的，所述第二确定模块430具体用于，获取所述软件中所述组件的白名单；将所述白名单，确定为所述组件的允许依赖关系列表。

本申请实施例的组件依赖关系检测装置，通过在对软件进行编译的过程中，获取软件中待处理的组件，以及组件对应的编译文件；对组件对应的编译文件进行扫描，确定组件的现有依赖关系列表；根据组件的现有依赖关系列表以及软件的依赖范畴文件，确定现有依赖关系列表中是否存在不允许依赖的第一组件；在现有依赖关系列表中存在第一组件时，进行编译报错提示，从而能够自动检测组件之间的依赖关系是否合理，效率高，且成本低。

为了实现上述实施例，本申请实施例还提出一种电子设备。

如图5所示，是根据本申请实施例的组件依赖关系检测方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图5所示，该电子设备包括：一个或多个处理器501、存储器502，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图5中以一个处理器501为例。

存储器502即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的组件依赖关系检测方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的组件依赖关系检测方法。

存储器502作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的组件依赖关系检测方法对应的程序指令/模块(例如，附图4所示的获取模块410、第一确定模块420、第二确定模块430、处理模块440)。处理器501通过运行存储在存储器502中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的组件依赖关系检测方法。

存储器502可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据组件依赖关系检测的电子设备的使用所创建的数据等。此外，存储器502可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器502可选包括相对于处理器501远程设置的存储器，这些远程存储器可以通过网络连接至组件依赖关系检测的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

组件依赖关系检测方法的电子设备还可以包括：输入装置503和输出装置504。处理器501、存储器502、输入装置503和输出装置504可以通过总线或者其他方式连接，图5中以通过总线连接为例。

输入装置503可接收输入的数字或字符信息，以及产生与组件依赖关系检测的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置504可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。

Claims (10)

1.一种组件依赖关系检测方法，其特征在于，包括：

在对软件进行编译的过程中，获取软件中待处理的组件，以及所述组件对应的编译文件；

对所述组件对应的编译文件进行扫描，确定所述组件的现有依赖关系列表；所述现有依赖关系列表中包括：所述组件所依赖的各个组件；

根据所述组件的现有依赖关系列表以及所述软件的依赖范畴文件，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件；

在所述现有依赖关系列表中存在所述第一组件时，进行编译报错提示。

2.根据权利要求1所述的方法，其特征在于，所述软件的依赖范畴文件的获取方式为，

获取所述软件的层级信息；所述层级信息包括：业务层级、服务层级和基础层级；

根据预设的依赖规则，确定所述业务层级、所述服务层级和所述基础层级中各个组件所允许依赖的组件；

根据所述各个组件所允许依赖的组件，生成所述依赖范畴文件。

3.根据权利要求1所述的方法，其特征在于，所述根据所述组件的现有依赖关系列表以及所述软件的依赖范畴文件，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件，包括：

根据所述软件的依赖范畴文件，确定所述组件的允许依赖关系列表；

根据所述组件的现有依赖关系列表和允许依赖关系列表，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件。

4.根据权利要求3所述的方法，其特征在于，所述依赖范畴文件包括：所述软件中各个组件的权重；

所述根据所述软件的依赖范畴文件，确定所述组件的允许依赖关系列表，包括：

获取所述依赖范畴文件中所述组件的权重，以及所述依赖范畴文件中对应的权重小于等于所述组件的权重的第二组件；

将所述第二组件的集合，确定为所述组件的允许依赖关系列表。

5.根据权利要求3所述的方法，其特征在于，所述依赖范畴文件包括：所述软件中各个组件对应的白名单；

所述根据所述软件的依赖范畴文件，确定所述组件的允许依赖关系列表，包括：

获取所述软件中所述组件的白名单；

将所述白名单，确定为所述组件的允许依赖关系列表。

6.一种组件依赖关系检测装置，其特征在于，包括：

获取模块，用于在对软件进行编译的过程中，获取软件中待处理的组件，以及所述组件对应的编译文件；

第一确定模块，用于对所述组件对应的编译文件进行扫描，确定所述组件的现有依赖关系列表；所述现有依赖关系列表中包括：所述组件所依赖的各个组件；

第二确定模块，用于根据所述组件的现有依赖关系列表以及所述软件的依赖范畴文件，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件；

处理模块，用于在所述现有依赖关系列表中存在所述第一组件时，进行编译报错提示。

7.根据权利要求6所述的装置，其特征在于，所述软件的依赖范畴文件的获取方式为，

获取所述软件的层级信息；所述层级信息包括：业务层级、服务层级和基础层级；

根据预设的依赖规则，确定所述业务层级、所述服务层级和所述基础层级中各个组件所允许依赖的组件；

根据所述各个组件所允许依赖的组件，生成所述依赖范畴文件。

8.根据权利要求6所述的装置，其特征在于，所述第二确定模块具体用于，

根据所述软件的依赖范畴文件，确定所述组件的允许依赖关系列表；

根据所述组件的现有依赖关系列表和允许依赖关系列表，确定所述现有依赖关系列表中是否存在不允许依赖的第一组件。

9.一种电子设备，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-5中任一项所述的方法。

10.一种存储有计算机指令的非瞬时计算机可读存储介质，其特征在于，所述计算机指令用于使所述计算机执行权利要求1-5中任一项所述的方法。

Images