CN116301878A - Method, device, equipment and medium for inquiring inverse dependency relationship of software module - Google Patents

Method, device, equipment and medium for inquiring inverse dependency relationship of software module Download PDF

Info

Publication number
CN116301878A
CN116301878A CN202211525995.4A CN202211525995A CN116301878A CN 116301878 A CN116301878 A CN 116301878A CN 202211525995 A CN202211525995 A CN 202211525995A CN 116301878 A CN116301878 A CN 116301878A
Authority
CN
China
Prior art keywords
software module
software
data structure
module
dependency
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211525995.4A
Other languages
Chinese (zh)
Inventor
熊磊
陈永波
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guoke Chushi Chongqing Software Co ltd
Original Assignee
Guoke Chushi Chongqing Software Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guoke Chushi Chongqing Software Co ltd filed Critical Guoke Chushi Chongqing Software Co ltd
Priority to CN202211525995.4A priority Critical patent/CN116301878A/en
Publication of CN116301878A publication Critical patent/CN116301878A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G06F8/433—Dependency analysis; Data or control flow analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/658—Incremental updates; Differential updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

The disclosure relates to a method, a device, equipment and a medium for inquiring an inverse dependency relationship of a software module, which can be applied to automatic driving software development, wherein the method comprises the following steps: receiving a request for inquiring the inverse dependency relationship of a first software module, wherein the first software module is at least one of a plurality of software modules contained in a collaborative task; searching a pre-built data structure for a target data structure containing the first software module, the data structure being used to describe forward dependencies between the plurality of software modules in the collaborative task; and carrying out reverse lookup in the target data structure to obtain a second software module with an inverse dependency relationship with the first software module. The query efficiency is high, the query result is comprehensive, participants of the collaborative task can clearly know the affected software modules under the condition that the own software modules are changed, and update compatibility test, integration test and the like among all the software modules in the collaborative task are facilitated.

Description

Method, device, equipment and medium for inquiring inverse dependency relationship of software module
Technical Field
The disclosure relates to the technical field of software engineering, and in particular relates to a method, a device, equipment and a medium for inquiring an inverse dependency relationship of a software module.
Background
In the process of developing application software, collaborative operations need to be performed across departments, across fields and the like, one application software may involve a large number of software modules, and the relationship between each software module is complicated.
The software modules involved in the same collaborative task may be responsible for different development teams, with rights setting policies between the software module code warehouses. For example, source code information of some software modules can only be obtained by developers of the same group of software modules in a collaborative task, and other group of developers in the same collaborative task cannot obtain information of software modules outside the group. In some scenarios, it is desirable to obtain software modules that are affected by one or more software modules in a collaborative task; under the condition of authority setting, the requirement of inquiring the inverse dependency relationship of the software module cannot be met.
Disclosure of Invention
To overcome the following technical problems in the related art: because the existing package management tool only contains the declaration information of the software module on which the software module depends, namely the forward dependency relationship, the existing package management tool is dependent under the condition that the authority setting exists, and the problems of low query efficiency and incomplete query of the reverse dependency relationship exist. The embodiment of the disclosure provides a method, a device, equipment and a medium for inquiring the inverse dependency relationship of a software module.
According to a first aspect of embodiments of the present disclosure, a method of querying an inverse dependency of a software module is provided. The method comprises the following steps: receiving a request for inquiring the inverse dependency relationship of a first software module, wherein the first software module is at least one of a plurality of software modules contained in a cooperative task; searching a pre-built data structure for a target data structure comprising the first software module, the data structure describing forward dependencies between the plurality of software modules in the collaborative task; performing reverse lookup in the target data structure to obtain a second software module with an inverse dependency relationship with the first software module; the reverse dependency relationship is used for representing a downstream software module affected by the change of an upstream software module, the forward dependency relationship is used for representing an upstream software module on which the downstream software module depends, and the upstream software module and the downstream software module belong to the cooperative task.
In some embodiments, the data structure includes: a data object, an object dependency relationship and a relationship direction, wherein the data object is used for representing the software modules in the collaborative task, the object dependency relationship is used for representing the dependency relationship between the software modules, and the relationship direction is used for representing the upstream and downstream directions between two software modules involved in the object dependency relationship; wherein the object dependency relationship includes at least one of: the header file contains dependencies, link dependencies to static libraries in compiled links, link dependencies to dynamic libraries in compiled links.
In some embodiments, performing a reverse lookup in the target data structure to obtain a second software module having an inverse dependency relationship with the first software module includes: and determining a software module positioned downstream of the first software module in the target data structure as the second software module according to the relation direction.
In some embodiments, the data structure includes: a directed acyclic graph, the directed acyclic graph comprising: a vertex and a connecting edge connected between the vertices, the connecting edge having a direction, the vertex being used to represent a software module, the connecting edge being used to represent a dependency relationship between software modules, the direction being used to represent upstream and downstream directions of two software modules involved in the dependency relationship;
the target data structure is a target path including a vertex corresponding to the first software module, and the second software module includes: and the software module corresponding to the vertex set positioned at the downstream of the vertex corresponding to the first software module.
In some embodiments, the above method further comprises: acquiring forward dependency relationships of the plurality of software modules from script file declaration information of the plurality of software modules; and generating a data structure associated with the collaborative task according to the forward dependency relationship of the plurality of software modules.
In some embodiments, the above method further comprises: acquiring the software module updating information of the cooperative task; and correspondingly updating the data structure according to the software module updating information, wherein the updating comprises the following steps: new information, delete information, or change information.
In some embodiments, the software module update information includes: adding a third software module, deleting a fourth software module, or modifying a fifth software module. According to the software module update information, correspondingly updating the data structure, including: responding to the software module updating information as a newly added third software module, and acquiring the forward dependency of the third software module from script file declaration information of the third software module; adding the forward dependency of the third software module to the information of the data structure; responding to the software module update information to delete a fourth software module, and deleting information corresponding to the fourth software module from the information of the data structure; and in response to the software module updating information being a modified fifth software module, updating the information of the data structure according to the modified information of the fifth software module.
According to a second aspect of embodiments of the present disclosure, an apparatus for querying an inverse dependency of a software module is provided. The device comprises: the system comprises a request receiving module, a searching module and a dependency determining module. The request receiving module is used for receiving a request for inquiring the inverse dependency relationship of a first software module, wherein the first software module is at least one of a plurality of software modules contained in a cooperative task. The searching module is used for searching a target data structure containing the first software module in a pre-constructed data structure, and the data structure is used for describing forward dependency relations among the plurality of software modules in the cooperative task. The dependency relationship determining module is configured to perform reverse lookup in the target data structure to obtain a second software module having an inverse dependency relationship with the first software module. The reverse dependency relationship is used for representing a downstream software module affected by the change of an upstream software module, the forward dependency relationship is used for representing an upstream software module on which the downstream software module depends, and the upstream software module and the downstream software module belong to the cooperative task.
According to a third aspect of embodiments of the present disclosure, there is provided an electronic device, comprising: a processor; a memory for storing processor-executable instructions; the processor is configured to read the executable instructions from the memory and execute the executable instructions to implement the method for querying an inverse dependency relationship of a software module provided in the first aspect of the present disclosure.
According to a fourth aspect of embodiments of the present disclosure, there is provided a computer readable storage medium having stored thereon computer program instructions which, when executed by a processor, implement a method of querying an inverse dependency of a software module provided by the first aspect of the present disclosure.
The technical scheme provided by the embodiment of the disclosure can comprise the following beneficial effects:
by constructing a data structure for describing forward dependency relationships among the plurality of software modules in the collaborative task, presenting upstream and downstream dependency relationships among the software modules in the collaborative task in the data structure, and carrying out reverse search in a target data structure containing a first software module, a second software module with reverse dependency relationships with the first software module can be obtained, the query efficiency is high, the query result is comprehensive, each developer in the software modules of the collaborative task can conveniently know the global dependency relationships among the software modules, and the developer can conveniently and comprehensively query the downstream software module or the upstream software module of the software module responsible for the developer; the participants of the collaborative task can clearly know the affected software modules under the condition that the software modules of the participants are changed, so that the participants corresponding to the affected software modules are notified correspondingly, and update compatibility test, integration test and the like among the software modules in the collaborative task are facilitated. At least, the problems of low query efficiency and incomplete query of the inverse dependency relationship existing in dependence on the existing package management tool under the condition of permission setting can be solved.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure.
FIG. 1 is a schematic application scenario illustrating a method of querying inverse dependencies of software modules, according to an example embodiment.
FIG. 2 is a flowchart illustrating a method of querying an inverse dependency of a software module, according to an example embodiment.
FIG. 3 is a schematic diagram illustrating a constructed data structure according to an example embodiment.
FIG. 4A is a schematic diagram of a target data structure shown according to an example embodiment.
Fig. 4B is a schematic diagram of a target data structure shown according to another example embodiment.
FIG. 5 is a flowchart illustrating a method of querying an inverse dependency of a software module according to another exemplary embodiment.
FIG. 6A is a diagram illustrating the addition of a software module to a collaborative task according to an example embodiment.
FIG. 6B is a diagram illustrating a corresponding data structure after a new software module is added to a collaborative task according to an example embodiment.
FIG. 7 is a block diagram illustrating an apparatus for querying inverse dependencies of software modules, according to an example embodiment.
Fig. 8 is a block diagram of an electronic device, according to an example embodiment.
Detailed Description
Exemplary embodiments will be described in detail below with reference to the accompanying drawings.
It should be noted that the related embodiments and the drawings are only for the purpose of describing exemplary embodiments provided by the present disclosure, and not all embodiments of the present disclosure, nor should the present disclosure be construed to be limited by the related exemplary embodiments.
It should be noted that the terms "first," "second," and the like, as used in this disclosure, are used merely to distinguish between different steps, devices, or modules, and the like. Relational terms are used not to indicate any particular technical meaning nor sequence or interdependence between them.
It should be noted that the modifications of the terms "one", "a plurality", "at least one" as used in this disclosure are intended to be illustrative rather than limiting. Unless the context clearly indicates otherwise, it should be understood as "one or more".
It should be noted that the term "and/or" is used in this disclosure to describe an association between associated objects, and generally indicates that there are at least three associations. For example, a and/or B may at least represent: a exists independently, A and B exist simultaneously, and B exists independently.
It should be noted that the various steps recited in the method embodiments of the present disclosure may be performed in a different order and/or performed in parallel. The scope of the present disclosure is not limited by the order of description of the steps in the related embodiments unless specifically stated.
It should be noted that, all actions for acquiring signals, information or data in the present disclosure are performed under the condition of conforming to the corresponding data protection rule policy of the country of the location and obtaining the authorization given by the owner of the corresponding device.
FIG. 1 is a schematic application scenario illustrating a method of querying inverse dependencies of software modules, according to an example embodiment.
An autopilot software project (abbreviated as autopilot project) is developed cooperatively as an example of a cooperative task. It can be appreciated that the application scenario can be extended to other collaborative development task scenarios, and also to collaborative task scenarios where multiple software modules of other types have a dependency relationship. Referring to the dashed line box in fig. 1, in the collaborative task 100 corresponding to the autopilot project, 7 software modules, namely, software modules 1 to 7, need to be organized organically, wherein the software modules 1 to 3 are third party library modules 110, the software modules 4 and 5 belong to external software modules 120 provided by suppliers, the software modules 4 are external software modules provided by suppliers a, the software modules 5 are external software modules provided by suppliers B, and the software modules 6 and 7 are internal software modules 130 self-developed by development team X.
In general, the software project of the automobile has huge scale, and the software modules involved in the application scene of high-speed sensing or low-speed parking of one automatic driving can be about 100-200. With some open-source package management tools or self-grinding package management tools, the external dependencies of each software module are typically explicitly declared in a file (e.g., a Python script file), and by looking at the script file of a certain software module, it is possible to quickly learn which software module or modules the current software module depends on.
During the development, it was found that: in the whole flow of research, development, deployment and testing of an automatic driving project, a developer can only know the direct upstream software module on which a responsible software module depends according to the information of the responsible software module, cannot comprehensively know all the upstream software modules, and cannot comprehensively know which downstream software modules the self software module depends on.
In an exemplary scenario, the third party library module 110, the external software module 120 and the internal software module 130 are responsible for different development teams, and authority setting policies exist between software module code warehouses, for example, dependency information of the third party library module 110 can only be obtained by a developer of a third party and is not open to a user, and then, for the development team X, it is impossible to obtain comprehensive dependency information between each software module in a collaborative task.
For example, in some scenarios, even if a developer can determine, from information about a plurality of software modules in a responsible group, an upstream software module and a downstream software module that have a dependency relationship in the group, for example, a developer in a development team X can obtain the dependency relationship of each of the software modules 6 and 7, and because of the authority setting policy between the software module code warehouses, the development team X may not have authority to obtain the dependency relationship information of the third party library module 110 and the external software module 120, which results in that the dependency relationship link known by the developer of one software module is not comprehensive.
In some scenarios, it is desirable to obtain software modules that are affected by one or more software modules in a collaborative task. However, the existing package management tool only contains the declaration information of the software module on which the software module depends, namely the forward dependency relationship, so that the requirement of inquiring the reverse dependency relationship of the software module cannot be met under the condition of permission setting, and the existing package management tool is relied on, so that the problems of low query efficiency and incomplete query of the reverse dependency relationship exist.
For example, referring to FIG. 1, in one exemplary scenario, a developer of a software module 4 needs to perform an integration test on the software module 4, but because the software module 4 releases a dynamic link library, it needs to perform an integration test by means of executable files of other software modules, and at this time, it needs to clearly know which software modules are affected by the integration test.
However, since software module 4 belongs to an external software module provided by vendor a and software module 5 belongs to an external software module provided by vendor B, the developer of software module 4 cannot fully learn the dependencies of software modules 1-3, 5, 6 and 7 in the collaborative task. And the quick and efficient reverse relation searching can not be performed according to the declaration information in the packet management tool corresponding to each software module. Namely, the problems of low query efficiency and incomplete query of the inverse dependency relation exist.
In other exemplary scenarios, it may also be that a developer of a certain software module performs code modification on the software module, so as to cause version upgrade of the software module, and sometimes needs to be notified to a responsible person affecting the relevant software module affected by the software module in time, that is, needs to check which software module or modules the current software module depends on. This dependency is reverse, unlike a dependency explicitly declared forward in a software module script file.
It has thus been found in research and development that there is a need for efficient and comprehensive querying of inverse relationships of one or more software modules in a collaborative task, however the related art does not take this problem into account and does not give a solution.
In view of this, the embodiments of the present disclosure provide a method, an apparatus, a device, and a medium for querying an inverse dependency relationship of a software module, by constructing a data structure for describing a forward dependency relationship between a plurality of software modules in a collaborative task, where upstream and downstream dependency relationships between each software module in the collaborative task are presented in the data structure, and performing an inverse lookup in a target data structure including a first software module, a second software module having an inverse dependency relationship with the first software module can be obtained.
Exemplary method
FIG. 2 is a flowchart illustrating a method of querying an inverse dependency of a software module, according to an example embodiment.
Referring to fig. 2, a method for querying an inverse dependency relationship of a software module according to an embodiment of the disclosure includes the following steps: s210, S220, and S230. The above method may be applied to an electronic device.
In some embodiments, the electronic device is a server that provides service support for a plurality of software modules corresponding to the collaborative task. The server may be an application server or a cloud server, including a service cluster. The server has data storage functionality or is capable of accessing and operating a database. When the server executes steps S210 to S230 to obtain a query result (for example, a second software module) corresponding to the inverse dependency relationship, the query result is sent to the terminal device corresponding to the query request.
In other embodiments, the electronic device is a terminal device having a display screen, such as a desktop computer, a notebook computer, a tablet computer, a smart phone, or the like. And a developer corresponding to one or more software modules in the plurality of software modules in the collaborative task initiates a query request to the used terminal equipment, and the terminal equipment correspondingly executes steps S210 to S230.
In step S210, a request for querying an inverse dependency relationship of a first software module, where the first software module is at least one of a plurality of software modules included in a collaborative task, is received.
Referring to fig. 1, the collaborative task 100 includes a plurality of software modules, and taking an example in which an autopilot project includes 7 software modules, the number of first software modules to query for an inverse dependency relationship may be one or more.
The above-described inverse dependency relationship is used to represent downstream software modules affected by variations in upstream software modules. The upstream software module and the downstream software module both belong to the cooperative task.
In step S220, a target data structure including the first software module is searched in a pre-built data structure, where the data structure is used to describe forward dependency relationships between the plurality of software modules in the collaborative task.
The forward dependency is used to represent the upstream software module that the downstream software module depends on.
The script file declaration information of the software module carries the description of the forward dependency. In some embodiments, the resulting data structure may be constructed from script file declaration information of the software module.
A data structure refers to a collection of data elements that have one or more relationships with each other. In the embodiments of the present disclosure, the data structure is a data form stored in the background database, and the specific form may vary, and any data structure capable of describing the forward dependency of the software module is within the scope of the present disclosure.
For example, in the vehicle field, the data structure may employ a directed acyclic graph, considering that features of the vehicle that do not allow cyclic dependencies between software modules may be mapped to acyclic features of the directed acyclic graph.
In other embodiments, the data structure may also have a corresponding presentation manner at the front end (e.g., a terminal device), so that developers of each software module of the collaborative task can know global dependency relationships between the software modules, and the developers can also conveniently perform visual understanding on downstream software modules or upstream software modules of the software modules responsible for the developers.
For example, the data structure is presented at the front end in the form of a dependency graph, which may vary in the style presented at the front end. Such as presenting software modules with circles, triangles, rectangular boxes, pentagons, hexagons, etc., presenting upstream and downstream dependencies between software modules with arrowed lines, circled lines, etc., specific presentation formats may be set and adjusted, such as: pattern style of elements, presence or absence of padding, line format, color of display elements, content representation form of display text, content style (including font color, presence or absence of tilting, bold, font size, etc.), etc.
In step S230, a reverse lookup is performed in the target data structure to obtain a second software module having an inverse dependency relationship with the first software module.
One or more second software modules having an inverse dependency relationship with the first software module are obtained by performing an inverse lookup in the target data structure, i.e. from the downstream direction of the first software module.
In the related art, each terminal device has a permission limit on information access of a non-internal software module in a collaborative task, for example, a terminal device used by a developer of the software module 4 does not have access permission on information of the software modules 1 to 3. Therefore, the developer can only know the direct upstream software module depending on the responsible software module according to the information of the responsible software module, cannot comprehensively know all the upstream software modules, and cannot comprehensively know which downstream software modules the self software module depends on.
In contrast, in the embodiment of the present disclosure, for the same collaborative task, the server side has access rights to script file declaration information of multiple software modules in the collaborative task, and the terminal device can query by the server side based on the constructed data structure to obtain a corresponding result by initiating a query request to the server side.
In the embodiment including steps S210 to S230, by constructing a data structure for describing forward dependency relationships among the plurality of software modules in the collaborative task, the data structure presents upstream and downstream dependency relationships among the software modules in the collaborative task, and performing reverse lookup in a target data structure including a first software module, a second software module having an inverse dependency relationship with the first software module can be obtained, so that query efficiency is high, query results are comprehensive, and each developer in the software modules of the collaborative task can conveniently know global dependency relationships among the software modules, and can also conveniently and comprehensively query a downstream software module or an upstream software module of the software module responsible for the developer; the participants of the collaborative task can clearly know the affected software modules under the condition that the software modules of the participants are changed, so that the participants corresponding to the affected software modules are notified correspondingly, and update compatibility test, integration test and the like among the software modules in the collaborative task are facilitated. At least, the problems of low query efficiency and incomplete query of the inverse dependency relationship existing in dependence on the existing package management tool under the condition of permission setting can be solved.
In some embodiments, the received request R 1 Is a request to query for the inverse dependency of the software module 4.
In another embodiment, the received request R 2 Is a request to query for the inverse dependency of the software module 6.
The script file declaration information of the software module carries the description of the forward dependency. In some embodiments, the resulting data structure may be constructed from script file declaration information of the software module.
In some embodiments, the data structure includes: data objects, object dependencies and relationship directives, the data objects being used to represent software modules in the collaborative task, the object dependencies being used to represent dependencies between the software modules, the relationship directives being used to represent upstream and downstream directions between two software modules involved in the object dependencies. Wherein the object dependency relationship includes at least one of: the header file contains dependencies, link dependencies to static libraries in compiled links, link dependencies to dynamic libraries in compiled links.
In the application development process, a compiler compiles a plurality of source code files into a plurality of independent unconnected target files, and then links the target files through a linker to form an executable file; a software development task often includes a plurality of software modules, and on the premise of ensuring that each software module can be compiled independently, all modules are assembled, and the process of assembling the modules is a process of compiling links.
For example, script file declaration information of the software module 1 is described as follows: the software module 1 has no external dependencies. The script file declaration information of the software module 2 is described as: the software module 2 depends on the software module 1 and the software module 3. The script file declaration information of the software module 3 is described as: the software module 3 depends on the software module 4. The script file declaration information of the software module 4 is described as follows: the software module 4 depends on the software module 9. The software module 9 is not a software module in the collaborative task 100. The script file declaration information of the software module 5 is described as follows: the software module 5 depends on the software module 2 and the software module 4. The script file declaration information of the software module 6 is described as follows: the software module 6 depends on the software module 2 and the software module 5. The script file declaration information of the software module 7 is described as follows: the software module 7 depends on the software module 1.
FIG. 3 is a schematic diagram illustrating a constructed data structure according to an example embodiment.
For example, referring to fig. 3, the server side can construct a data structure 300 according to the script file declaration information of the software modules 1 to 7 in the above example, where the data structure 300 includes 8 data objects, and in fig. 3, an oval box is used to illustrate the data objects, which are a first data object 301, a second data object 302, a third data object 303, a fourth data object 304, a fifth data object 305, a sixth data object 306, a seventh data object 307, and an eighth data object 308, respectively; the first data object 301 is used to represent software module 1, the second data object 302 is used to represent software module 2, the third data object 303 is used to represent software module 3, the second data object 304 is used to represent software module 4, the fifth data object 305 is used to represent software module 5, the second data object 306 is used to represent software module 6, the seventh data object 307 is used to represent software module 7, and the second data object 308 is used to represent software module 9.
In which, since the software module 9 is not a software module within the collaborative task, it is illustrated in fig. 3 by a dashed box, in the metadata information of the data structure 300 or in the metadata information of the software module 9, it will be explained that the software module 9 does not belong to the collaborative task 100.
Referring to FIG. 3, the data structure 300 includes object dependencies and relationship directives in addition to 8 data objects, and in FIG. 3, a connection with an arrow is used to illustrate an object dependency, where the direction of the arrow is used to illustrate a relationship director. Here, in the same line, an upstream software module is illustrated with an object pointed by an arrow, and a downstream software module is illustrated with an object away from the arrow. For example, the first dependency relationship 311 represents a dependency relationship between the software module 2 and the software module 1, where the software module 2 is a downstream software module and the software module 1 is an upstream software module. Similarly, the second dependency relationship 312 is used to represent a dependency relationship between the software module 2 and the software module 3, where the software module 2 is a downstream software module and the software module 3 is an upstream software module. The third dependency 313 is used to represent the dependency of the software module 3 and the software module 4, where the software module 3 is a downstream software module and the software module 4 is an upstream software module. The fourth dependency relationship 314 is used to represent the dependency relationship between the software module 4 and the software module 9, where the software module 4 is a downstream software module and the software module 9 is an upstream software module. The fifth dependency relationship 315 is used to represent a dependency relationship between the software module 5 and the software module 2, where the software module 5 is a downstream software module and the software module 2 is an upstream software module. The sixth dependency relationship 316 is used to represent a dependency relationship between the software module 5 and the software module 4, where the software module 5 is a downstream software module and the software module 4 is an upstream software module. The seventh dependency 317 is used to represent the dependency between the software module 6 and the software module 2, where the software module 6 is a downstream software module and the software module 2 is an upstream software module. The eighth dependency relationship 318 is used to represent a dependency relationship between the software module 6 and the software module 5, where the software module 6 is a downstream software module and the software module 5 is an upstream software module. The ninth dependency 319 is used to represent a dependency of the software module 7 with the software module 1, where the software module 7 is a downstream software module and the software module 1 is an upstream software module.
FIG. 4A is a schematic diagram of a target data structure shown according to an example embodiment.
Referring to the circled portion of the large dashed oval box in FIG. 4A, for request R 1 A target data structure 410 is indicated in the data structure, and the target data structure 410 includes three dependency paths of the software module 4, and the sequence numbers (1) to (3) are used to illustrate the three dependency paths:
dependence path (1): software module 6 → software module 2 → software module 3 → software module 4 → software module 9;
dependence path (2): software module 6-software module 5-software module 2-software module 3-software module 4-software module 9;
dependence path (3): software module 6 → software module 5 → software module 4 → software module 9.
Fig. 4B is a schematic diagram of a target data structure shown according to another example embodiment.
Referring to the circled portion of the large dashed oval box in FIG. 4B, for request R 2 A target data structure 420 is indicated in the data structure, the target data structure 420 is four dependent paths including the software module 6, and serial numbers (1) to (4) are used to illustrate the four dependent paths, where the dependent paths (1) to (3) are the same as the three dependent paths (1) to (3) in the target data structure 410, and the dependent path (4) is: software module 6→software module 2→software module 1.
In some embodiments, performing a reverse lookup in the target data structure to obtain a second software module having an inverse dependency relationship with the first software module includes: and determining a software module positioned downstream of the first software module in the target data structure as the second software module according to the relation direction in the target data structure.
For example, looking up in the downstream direction of software module 4 in target data structure 410, obtaining a second software module having an inverse dependency relationship with software module 4, includes: software module 3, software module 5, software module 2 and software module 6.
Looking up in the target data structure 420 along the downstream direction of the software module 6, and after looking up, there is no software module downstream of the software module 6, so that it is explained that there is no second software module having an inverse dependency relationship with the software module 4, and the obtained query result of the inverse dependency relationship is: the inverse dependency does not exist or the corresponding second software module does not exist.
In the vehicle field, the feature of not allowing cyclic dependence among software modules of the vehicle can be mapped to the acyclic feature of the directed acyclic graph, so the data structure can employ the directed acyclic graph.
The directed acyclic graph includes: the system comprises vertexes and connecting edges connected between the vertexes, wherein the connecting edges are provided with directions, the vertexes are used for representing software modules, the connecting edges are used for representing dependency relations among the software modules, and the directions are used for representing upstream and downstream directions of two software modules related to the dependency relations. In this embodiment, the data objects in the data structure are here corresponding to the vertices of the directed acyclic graph; the object dependencies and relationship directives in the above data structure correspond here to directed conjoined edges of the directed acyclic graph.
The target data structure is a target path including a vertex corresponding to the first software module, and the second software module includes: the vertex sets (e.g., the vertex sets corresponding to the third data object 303, the fifth data object 305, the second data object 302, and the sixth data object 306 illustrated in fig. 3) downstream from the corresponding vertex set of the first software module (e.g., the software module 4) correspond to the software modules (e.g., the software module 3, the software module 5, the software module 2, and the software module 6).
FIG. 5 is a flowchart illustrating a method of querying an inverse dependency of a software module according to another exemplary embodiment.
In some embodiments, when the method is executed by the server, the method may further include a step of constructing a data structure, where the step of constructing a data structure includes: s510 and S520, referring to fig. 5, only steps S510 and S520 are illustrated in fig. 5 for simplicity of illustration.
In step S510, the forward dependency of the plurality of software modules is acquired from the script file declaration information of the plurality of software modules.
In some embodiments, the forward dependency is used to describe information of an upstream software module that each software module depends on, including but not limited to: name of upstream software module, IP address, version information, etc.
In some embodiments, the hardware platform on which the software modules in the collaborative task operate is different, and in order to adapt to the operated hardware platform, the software module dependency relationships corresponding to the same software module are also different.
For example, the script file declaration information of the software module includes information of an upstream software module on which the software module depends, and for example, the script file declaration information of the software module 6 includes the following information: the software module 6 is dependent on the software module 2, the software module 3 and the software module 4 when running on the platform X and on the software module 2 and the software module 9 when running on the platform Y. Then, in embodiments of the present disclosure, it is necessary to determine the software module dependencies on the domain controller, the target hardware platform, for the collaborative task to be an autopilot project.
In some embodiments, the script file declaration information of some software modules is generic to a general platform, and the dependency relationship of the software modules is not limited to a specific application platform.
In step S520, a data structure associated with the collaborative task is generated according to the forward dependency of the plurality of software modules.
And integrating forward dependency relations of the plurality of software modules to obtain at least one dependency relation network corresponding to the collaborative task, and generating a data structure related to the collaborative task according to the information of the at least one dependency relation network.
In some embodiments, an empty data structure is newly built in the database, and the data structure is bound with the identification of the corresponding collaborative task; each software module is added in the collaborative task, the information of the data structure is correspondingly updated, for example, the vertexes of the directed acyclic graph or vertex information is updated; and if the dependency relationship between the software modules in the collaborative task changes, updating at least one of the end points or the points of the connection lines of the directed acyclic graph.
For example, the collaborative project comprises software modules 1-7, a vertex 1 is created in an empty data structure corresponding to the directed acyclic graph aiming at the software module 1, the vertex is used for representing the software module 1, and then no connection operation is carried out on the vertex 1 according to the forward dependency of the software module 1; for software module 2, according to the forward dependency of software module 2 as dependent on software module 1, then a vertex 2 is created in the data structure containing vertex 1, and a connection line from vertex 2 to vertex 1 is added between vertex 1 and vertex 2. Similarly, for other software modules included in the collaborative task, the vertex is continuously created and the corresponding connection line is added in the existing data structure, or a new data structure is newly created to describe the software modules and the corresponding dependency relationship. One or more data structures corresponding to the collaborative project are ultimately obtained.
In some embodiments, the above method further comprises: acquiring the software module updating information of the cooperative task; and correspondingly updating the data structure according to the software module updating information, wherein the updating comprises the following steps: new information, delete information, or change information.
In some embodiments, the software module update information includes: a third software module is added. According to the software module update information, correspondingly updating the data structure, including: responding to the software module updating information as a newly added third software module, and acquiring the forward dependency of the third software module from script file declaration information of the third software module; and adding the forward dependency relationship of the third software module into the information of the data structure.
FIG. 6A is a diagram illustrating the addition of a software module to a collaborative task according to an example embodiment. FIG. 6B is a diagram illustrating a corresponding data structure after a new software module is added to a collaborative task according to an example embodiment.
For example, referring to fig. 6A, the collaborative task 100 is updated, a software module 8 is newly added in the original collaborative task 100, the newly added software module 8 belongs to an internal software module 130 which is self-developed by the research and development team X, the collaborative task after the newly added software module is illustrated as a collaborative task 100', and the forward dependency relationship of the software module 8 is described in the script file declaration information of the software module 8: depending on the software module 3 and the software module 1, as shown in fig. 6B, the forward dependency relationship of the newly added software module 8 is newly added to the information of the above data structure, and corresponds to the newly added data object 601 (corresponding to the vertex when the data structure is the directed acyclic graph) corresponding to the newly added software module 8 in the original data structure, and the corresponding first newly added dependency relationship 611 and second newly added dependency relationship 612. The first new dependency 611 represents a dependency between the software module 8 and the software module 3, the software module 8 being a downstream software module and the software module 3 being an upstream software module. The second newly added dependency relationship 612 represents a dependency relationship between software module 8 and software module 1, software module 8 being the downstream software module and software module 1 being the upstream software module.
In other embodiments, the software module update information includes: the fourth software module is deleted. According to the software module update information, correspondingly updating the data structure, including: and deleting the information corresponding to the fourth software module from the information of the data structure in response to the software module update information being the fourth software module deletion. A similar update procedure may refer to the newly added example, except that the information corresponding to the fourth software module needs to be deleted in the data structure, which is not further illustrated here.
In still other embodiments, the software module update information includes: the fifth software module is modified. According to the software module update information, correspondingly updating the data structure, including: and in response to the software module updating information being a modified fifth software module, updating the information of the data structure according to the modified information of the fifth software module.
The modifying fifth software module includes: the content of the fifth software module is updated, or the dependency of the fifth software module is updated, and the corresponding modification is, for example: modifying vertex information corresponding to a fifth software module in the directed acyclic graph; the connection (at least one of a connection endpoint and a direction) of the fifth software module in the directed acyclic graph is modified.
The data structure is dynamically updated according to the update condition of the software modules in the collaborative task, so that the problem that the dependency relationship of each software module in the collaborative task is not fully known and cannot be timely known after the dependency relationship is updated in the related technology can be effectively solved, the data structure can be timely tracked and updated under the condition that the software modules contained in the collaborative task are changed, the query result of the inverse dependency relationship obtained by the query is the updated inverse dependency relationship which is suitable for the updated collaborative task, and developers of the related software modules which are affected can be timely notified in the process of performing integrated test or upgrading compatibility test on certain software or certain software, and the downstream software modules are enabled to be suitable for compiling link update and integrated test of the software modules.
Exemplary apparatus
FIG. 7 is a block diagram illustrating an apparatus for querying inverse dependencies of software modules, according to an example embodiment.
Referring to fig. 7, an apparatus 700 for querying inverse dependencies of software modules according to an embodiment of the present disclosure includes: a request receiving module 710, a searching module 720 and a dependency determining module 730.
The request receiving module 710 is configured to receive a request for querying an inverse dependency relationship of a first software module, where the first software module is at least one of a plurality of software modules included in a collaborative task.
The searching module 720 is configured to search a pre-built data structure for a target data structure including the first software module, where the data structure is configured to describe forward dependencies among the plurality of software modules in the collaborative task.
The dependency determination module 730 is configured to perform an inverse lookup in the target data structure to obtain a second software module having an inverse dependency relationship with the first software module.
The reverse dependency relationship is used for representing a downstream software module affected by the change of an upstream software module, the forward dependency relationship is used for representing an upstream software module on which the downstream software module depends, and the upstream software module and the downstream software module belong to the cooperative task.
In some embodiments, in the apparatus 700, the data structure includes: a data object, an object dependency relationship and a relationship direction, wherein the data object is used for representing the software modules in the collaborative task, the object dependency relationship is used for representing the dependency relationship between the software modules, and the relationship direction is used for representing the upstream and downstream directions between two software modules involved in the object dependency relationship;
Wherein the object dependency relationship includes at least one of: the header file contains dependencies, link dependencies to static libraries in compiled links, link dependencies to dynamic libraries in compiled links.
In some embodiments, in the apparatus 700, performing a reverse lookup in the target data structure to obtain a second software module having an inverse dependency relationship with the first software module includes: and determining a software module positioned downstream of the first software module in the target data structure as the second software module according to the relation direction.
In some embodiments, in the apparatus 700, the data structure includes: a directed acyclic graph, the directed acyclic graph comprising: a vertex and a connecting edge connected between the vertices, the connecting edge having a direction, the vertex being used to represent a software module, the connecting edge being used to represent a dependency relationship between software modules, the direction being used to represent upstream and downstream directions of two software modules involved in the dependency relationship; the target data structure is a target path including a vertex corresponding to the first software module, and the second software module includes: and the software module corresponding to the vertex set positioned at the downstream of the vertex corresponding to the first software module.
In some embodiments, the apparatus 700 further comprises: the data structure building module includes: the system comprises a forward dependency acquisition module and a data structure generation module.
The forward dependency module is used for acquiring forward dependencies of the plurality of software modules from script file declaration information of the plurality of software modules.
The data structure generation module is used for generating a data structure associated with the collaborative task according to forward dependency relations of the plurality of software modules.
In some embodiments, the apparatus 700 further comprises: and the data structure updating module is used for:
acquiring the software module updating information of the cooperative task;
and correspondingly updating the data structure according to the software module updating information, wherein the updating comprises the following steps: new information, delete information, or change information.
In some embodiments, in the apparatus 700, the software module update information includes: adding a third software module, deleting a fourth software module, or modifying a fifth software module.
According to the software module update information, correspondingly updating the data structure, including:
Responding to the software module updating information as a newly added third software module, and acquiring the forward dependency of the third software module from script file declaration information of the third software module; adding the forward dependency of the third software module to the information of the data structure;
responding to the software module update information to delete a fourth software module, and deleting information corresponding to the fourth software module from the information of the data structure;
and in response to the software module updating information being a modified fifth software module, updating the information of the data structure according to the modified information of the fifth software module.
The details of the implementation of the respective modules in this embodiment may be referred to in the description of the method in the first embodiment, and the entire contents of the first embodiment may be incorporated into this embodiment.
Exemplary electronic device
Fig. 8 is a block diagram of an electronic device, according to an example embodiment. The electronic device may be a vehicle controller, an in-vehicle terminal, an in-vehicle computer, or other type of electronic device.
Referring to fig. 8, an electronic device 800 may include at least one processor 810 and memory 820. Processor 810 may execute instructions stored in memory 820. The processor 810 is communicatively coupled to the memory 820 via a data bus. In addition to memory 820, processor 810 may also be communicatively coupled to input device 830, output device 840, and communication device 850 via a data bus.
The processor 810 may be any conventional processor, such as a commercially available CPU. The processor may also include, for example, an image processor (Graphic Process Unit, GPU), a field programmable gate array (Field Programmable Gate Array, FPGA), a System On Chip (SOC), an application specific integrated Chip (Application Specific Integrated Circuit, ASIC), or a combination thereof.
The memory 820 may be implemented by any type or combination of volatile or nonvolatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk.
In the embodiment of the present disclosure, the memory 820 stores executable instructions, and the processor 810 may read the executable instructions from the memory 820 and execute the instructions to implement all or part of the steps of the method for querying inverse dependencies of software modules according to any of the above-described exemplary embodiments.
Exemplary computer-readable storage Medium
In addition to the methods and apparatus described above, exemplary embodiments of the present disclosure may also be a computer program product or a computer readable storage medium storing the computer program product. The computer program product comprises computer program instructions executable by a processor to perform all or part of the steps described in any of the methods of the exemplary embodiments described above.
The computer program product may write program code for performing the operations of embodiments of the present application in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages, as well as scripting languages (e.g., python). The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server.
The computer readable storage medium may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may include, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the readable storage medium include: a Static Random Access Memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic or optical disk, or any suitable combination of the foregoing having one or more electrical conductors.
Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure. This application is intended to cover any adaptations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.
It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims (10)

1. A method of querying an inverse dependency of a software module, comprising:
receiving a request for inquiring the inverse dependency relationship of a first software module, wherein the first software module is at least one of a plurality of software modules contained in a collaborative task;
searching a target data structure containing the first software module in a pre-built data structure, wherein the data structure is used for describing forward dependency relations among the plurality of software modules in the collaborative task;
Performing reverse lookup in the target data structure to obtain a second software module with an inverse dependency relationship with the first software module;
the reverse dependency relationship is used for representing a downstream software module affected by the change of an upstream software module, the forward dependency relationship is used for representing an upstream software module on which the downstream software module depends, and the upstream software module and the downstream software module both belong to the cooperative task.
2. The method of claim 1, wherein the data structure comprises: a data object, an object dependency and a relationship direction, wherein the data object is used for representing software modules in the collaborative task, the object dependency is used for representing the dependency between the software modules, and the relationship direction is used for representing the upstream and downstream directions between two software modules involved in the object dependency;
wherein the object dependency relationship includes at least one of: the header file contains dependencies, link dependencies to static libraries in compiled links, link dependencies to dynamic libraries in compiled links.
3. The method of claim 2, wherein performing a reverse lookup in the target data structure results in a second software module having an inverse dependency relationship with the first software module, comprising:
And determining a software module positioned downstream from the first software module in the target data structure as the second software module according to the relation direction.
4. A method according to any one of claims 1-3, wherein the data structure comprises: a directed acyclic graph, the directed acyclic graph comprising: the system comprises vertexes and connecting edges connected between the vertexes, wherein the connecting edges are provided with directions, the vertexes are used for representing software modules, the connecting edges are used for representing dependency relations between the software modules, and the directions are used for representing upstream and downstream directions of two software modules related to the dependency relations;
wherein the target data structure is a target path including a vertex corresponding to the first software module, and the second software module includes: and the software module corresponding to the vertex set positioned at the downstream of the vertex corresponding to the first software module.
5. The method as recited in claim 1, further comprising:
acquiring forward dependency relations of the plurality of software modules from script file declaration information of the plurality of software modules;
and generating a data structure associated with the collaborative task according to the forward dependency relationship of the plurality of software modules.
6. The method as recited in claim 5, further comprising:
acquiring software module updating information of the collaborative task;
and correspondingly updating the data structure according to the software module updating information, wherein the updating comprises the following steps: new information, delete information, or change information.
7. The method of claim 6, wherein the software module update information comprises: adding a third software module, deleting a fourth software module or changing a fifth software module;
and correspondingly updating the data structure according to the software module updating information, wherein the method comprises the following steps:
responding to the software module updating information as a newly added third software module, and acquiring the forward dependency of the third software module from script file declaration information of the third software module; adding the forward dependency of the third software module to the information of the data structure;
responding to the software module update information to delete a fourth software module, and deleting information corresponding to the fourth software module from the information of the data structure;
and in response to the software module updating information being a modified fifth software module, updating the information of the data structure according to the modified information of the fifth software module.
8. An apparatus for querying an inverse dependency of a software module, comprising:
the system comprises a request receiving module, a request processing module and a processing module, wherein the request receiving module is used for receiving a request for inquiring the inverse dependency relationship of a first software module, and the first software module is at least one of a plurality of software modules contained in a cooperative task;
the searching module is used for searching a target data structure containing the first software module in a pre-built data structure, and the data structure is used for describing forward dependency relations among the plurality of software modules in the collaborative task;
the dependency relationship determining module is used for carrying out reverse searching in the target data structure to obtain a second software module which has an inverse dependency relationship with the first software module;
the reverse dependency relationship is used for representing a downstream software module affected by the change of an upstream software module, the forward dependency relationship is used for representing an upstream software module on which the downstream software module depends, and the upstream software module and the downstream software module both belong to the cooperative task.
9. An electronic device, comprising:
a processor;
a memory for storing the processor-executable instructions;
The processor is configured to read the executable instructions from the memory and execute the executable instructions to implement the method of any one of claims 1-7.
10. A computer readable storage medium having stored thereon computer program instructions, which when executed by a processor, perform the method of any of claims 1-7.
CN202211525995.4A 2022-11-30 2022-11-30 Method, device, equipment and medium for inquiring inverse dependency relationship of software module Pending CN116301878A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211525995.4A CN116301878A (en) 2022-11-30 2022-11-30 Method, device, equipment and medium for inquiring inverse dependency relationship of software module

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211525995.4A CN116301878A (en) 2022-11-30 2022-11-30 Method, device, equipment and medium for inquiring inverse dependency relationship of software module

Publications (1)

Publication Number Publication Date
CN116301878A true CN116301878A (en) 2023-06-23

Family

ID=86836488

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211525995.4A Pending CN116301878A (en) 2022-11-30 2022-11-30 Method, device, equipment and medium for inquiring inverse dependency relationship of software module

Country Status (1)

Country Link
CN (1) CN116301878A (en)

Similar Documents

Publication Publication Date Title
US11429365B2 (en) Systems and methods for automated retrofitting of customized code objects
US8826225B2 (en) Model transformation unit
US20100313182A1 (en) Extensible user interface generation
US20080046864A1 (en) Method and system for analyzing and presenting conflicts in model transformation and automatically reconciling model transformation
US20080276221A1 (en) Method and apparatus for relations planning and validation
US20220198003A1 (en) Detecting added functionality in open source package
CN118202330A (en) Checking source code validity at code update
CN112148278A (en) Visual block chain intelligent contract framework and intelligent contract development and deployment method
CN111858959A (en) Method and device for generating component relation map, computer equipment and storage medium
CN115599386A (en) Code generation method, device, equipment and storage medium
CN116560683A (en) Software updating method, device, equipment and storage medium
US20200097260A1 (en) Software application developer tools platform
CN117112060A (en) Component library construction method and device, electronic equipment and storage medium
CN114461223A (en) Code generation method and device and terminal equipment
CN114997111B (en) Service processing method, device, computer equipment and storage medium
US11977473B2 (en) Providing a pseudo language for manipulating complex variables of an orchestration flow
US11947966B2 (en) Identifying computer instructions enclosed by macros and conflicting macros at build time
CN115794858A (en) Query statement processing method, device, equipment and storage medium
CN113805877B (en) Project engineering construction method and device based on IDEA plug-in
CN116301878A (en) Method, device, equipment and medium for inquiring inverse dependency relationship of software module
US20190042588A1 (en) Dependency Mapping in a Database Environment
CN117009397A (en) Data query method, data query device, electronic equipment and storage medium
CN114115982A (en) Code issuing method, device, equipment and storage medium
CN113867780A (en) Service integration method, device and storage medium
CN113504904A (en) User-defined function implementation method and device, computer equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination