Service warehouse storage and reference method and system based on componentization mode

Abstract

The application relates to the technical field of data processing, and discloses a service warehouse storage and reference method and system based on a componentization mode, a double-track view warehouse containing a template view warehouse and a standard view warehouse is constructed, a development requirement set is generated by extracting a time period and content requirement of a development task, a benchmark data set is established based on component deployment information of a previous period, an optimal storage and reference strategy is solved by combining storage, dependency and scheduling quantity constraints and taking the minimum service component deployment times as the target, and finally, the double warehouse is controlled to execute storage and reference, so that efficient management of the componentized service warehouse is realized. Therefore, through the setting of the double-track view warehouse, the application can effectively solve the component scheduling confusion problem caused by limited warehouse storage, dynamic component requirement change and complex dependency relationship in the MBSE development, realize fine planning and efficient reuse of component storage, reduce resource consumption of component update scheduling, and improve cross-team development efficiency.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a service repository storage and referencing method and system based on a component-based model. Background Technology

[0002] With the widespread application of Model-Based Systems Engineering (MBSE) in the development of complex systems such as automotive electronics, industrial software, and smart hardware, component-based development has become a core means to improve MBSE development efficiency. By decomposing system functions into reusable service components (such as signal parsing components, security encryption components, data storage components, etc.), it enables one-time development and multiple reuses, reducing the cost of repetitive development across projects and teams.

[0003] In collaborative development scenarios involving multiple development teams (such as multiple ECU development teams or equipment R&D teams within the same enterprise jointly advancing complex system projects), component management faces two core requirements: first, the need for reuse of general components (such as basic components that all teams need to use, such as data encryption and log collection, which need to ensure consistency and reliability); and second, the need for personalized component management for each team (such as customized components developed by each team for specific business scenarios, which need to retain flexibility and autonomous management permissions).

[0004] Meanwhile, there are two major objective constraints in actual development: First, the storage resources of the repository are limited (physical or cloud storage capacity has an upper limit, and it is impossible to store all component versions without restriction); second, the component requirements change dynamically (different development periods and different tasks have different requirements for component types, versions and functions, and the component storage and referencing strategies need to be dynamically adjusted). Summary of the Invention

[0005] This invention provides a service repository storage and referencing method and system based on a component-based model, aiming to solve at least one of the above-mentioned technical problems.

[0006] To achieve the above objectives, this invention provides a service repository storage and referencing method based on a component-based model, the method comprising the following steps:

[0007] S1: Build a view repository for the development team; wherein, the view repository includes a template view repository unique to each development team and a standard view repository shared by several development teams;

[0008] S2: When receiving several development tasks from each development team for the current repository service period, extract the development period requirements and development content from the development tasks, and generate a development requirement set based on the component call requirements corresponding to the development period requirements and development content;

[0009] S3: Establish a component call benchmark dataset according to the component deployment information of the last scheduling period of the previous warehouse service period of the standard view warehouse;

[0010] S4: Based on the development requirement set and the component call benchmark dataset, a constraint condition set considering the component occupation space limit of the standard view warehouse, the dependency relationship between components and the cycle scheduling quantity limit is constructed, and the optimal storage and reference strategy of each service component in the template view warehouse and the standard view warehouse is solved by using an optimization algorithm, with the optimization objective of minimizing the service component deployment times;

[0011] S5: According to the optimal storage and reference strategy, control the template view warehouse and the standard view warehouse to execute the service component storage and reference of the current warehouse service period.

[0012] Optionally, step S1: constructing the view warehouse of the development team, specifically comprising:

[0013] S11: Constructing a standard view warehouse and establishing a first communication link between the standard view warehouse and a standard library administrator; wherein the first communication link is configured to drive the standard view warehouse to deploy the service component in the component warehouse-in request when the component warehouse-in request uploaded by the standard library administrator is transmitted;

[0014] S12: Constructing a plurality of template view warehouses and establishing a second communication link between the template view warehouses and the standard library administrator; wherein the second communication link is configured to upload the service component in the template view warehouse to the standard library administrator, and drive the standard library administrator to generate a component warehouse-in request based on the service component passed the detection after the deployment detection and the component detection.

[0015] Optionally, in S12, the deployment detection and the component detection specifically comprise:

[0016] S121: The standard library administrator judges whether the category and period of the uploaded component conform to the corresponding deployment category and deployment period in the optimal storage and reference strategy of the current warehouse service period;

[0017] S122: The standard library administrator performs component detection on the uploaded component, including at least one or more combined detection items such as component security scanning, code quality analysis and interface function verification.

[0018] Optionally, step S1: constructing the view warehouse of the development team, further comprising:

[0019] S13: Establishing a third communication link between each development team and the template view warehouse allocated to it; wherein the third communication link is configured to transmit the service component encapsulated in the view form created by the development team to the template view warehouse for storage;

[0020] S14: Establish a fourth communication link between each development team and the standard view repository; wherein the fourth communication link is configured to enable each development team to call the service components deployed in the standard view repository when performing development tasks.

[0021] Optionally, step S2: when receiving a plurality of development tasks of each development team for the current repository service period, extracting the development period demand and development content in the development task, generating a development demand set based on the component call demand corresponding to the development period demand and the development content, specifically including:

[0022] S21: When receiving a plurality of development tasks of each development team for the current repository service period, extracting the development period demand and development content in the development task;

[0023] S22: Based on the development content, determine the component call demand of each development task, and generate a development demand set using the development period demand and the component call demand.

[0024] Optionally, S22: Based on the development content, determine the component call demand of each development task, and generate a development demand set using the development period demand and the component call demand, specifically including:

[0025] S221: Use natural language processing tools to extract a plurality of technical keywords and a plurality of functional requirement words in the development content;

[0026] S222: Perform word group matching using the preset technical association word group of each service component and the technical keywords of each development task, calculate the matching rate of the technical association word of each service component in the plurality of technical keywords, extract a plurality of service components whose matching rate exceeds a preset threshold, and implement a first screening action for the service components of each development task;

[0027] S223: Use the preset functional association word group of each service component under different component versions to determine the inclusion relationship between the preset functional association word group and the plurality of functional requirement words of the development task, extract the service component version in which the preset functional association word group is completely included in the plurality of functional requirement words, and implement a second screening action for the service components of each development task;

[0028] S224: Use the development period demand and the service component candidate set after the two screening actions to generate a development demand set for each development task.

[0029] Optionally, step S3: Establish a component call benchmark data set according to the component deployment information of the last scheduling period of the standard view repository in the previous repository service period, specifically including:

[0030] S31: query the component deployment database of the standard view warehouse, and extract the optimal storage and reference strategy of the standard view warehouse in the previous warehouse service period recorded in the component deployment database;

[0031] S32: determine the component type and component version of each service component deployed in the standard view warehouse according to the optimal storage and reference strategy of the standard view warehouse in the previous warehouse service period, and generate component deployment benchmark data;

[0032] S33: query attribute information of a plurality of service components of each template view warehouse; wherein the attribute information includes component type, component version, component occupied space, component storage location, component dependency relationship and version dependency relationship;

[0033] S34: based on the component deployment benchmark data and the attribute information of a plurality of service components, establish a component call benchmark data set.

[0034] Optionally, step S4: based on the development requirement set and the component call benchmark data set, considering the constraint condition set constructed by the component occupied space limit of the standard view warehouse, the dependency relationship between components and the cycle scheduling quantity limit, taking the minimum service component deployment times as the optimization objective, using an optimization algorithm to solve the optimal storage and reference strategy of each service component in the template view warehouse and the standard view warehouse, specifically including:

[0035] S41: extract the development period requirement of each development task in the development requirement set and the service component candidate set with different component types and component versions, extract the component deployment benchmark data in the component call benchmark data set and the attribute information of a plurality of service components;

[0036] S42: taking the component type and component version of the service component deployed in each scheduling period of the standard view warehouse in the current warehouse service period as the planning decision variable, taking the sum of the component occupied space of all service components deployed in each scheduling period of the standard view warehouse in the current warehouse service period does not exceed the component occupied space limit allocated to the standard view warehouse as the first constraint condition, taking the service component deployed in each scheduling period of the standard view warehouse in the current warehouse service period contains: at least one version of each component type in the service component candidate set of each development task running in the development period corresponding to the scheduling period and the dependent component corresponding to the service component as the second constraint condition, taking the deployment times of the service component in each scheduling period of the standard view warehouse in the current warehouse service period does not exceed the maximum detection number of the standard library administrator in a single scheduling period as the third constraint condition;

[0037] S43: taking the minimum number of service component deployment times of the standard view repository in the service component deployment of the current repository service period as an optimization target, and solving the optimal storage and reference strategy of the component type and component version of the service component deployed by the standard view repository in each scheduling period of the current repository service period by using an optimization algorithm.

[0038] Optionally, step S5: according to the optimal storage and reference strategy, controlling the template view repository and the standard view repository to perform service component storage and reference in the current repository service period, specifically comprising:

[0039] S51: extracting the component type and component version of the service component deployed by the standard view repository in each scheduling period of the current repository service period planned in the optimal storage and reference strategy;

[0040] S52: according to the component type and component version of the service component deployed in each scheduling period planned, controlling the template view repository to upload and deploy the corresponding service component to the standard view repository through the standard library administrator in each scheduling period, and controlling the standard view repository to clean up the corresponding service component in each scheduling period, so as to realize the service component storage and reference of the template view repository and the standard view repository.

[0041] In addition, in order to achieve the above-mentioned purpose, the application further provides a service repository storage and reference system based on a componentization mode, comprising:

[0042] A construction module is configured to construct a view repository of a development team; wherein the view repository comprises a template view repository dedicated to each development team and a standard view repository shared by a plurality of development teams;

[0043] An extraction module is configured to extract development period requirements and development contents in a plurality of development tasks of each development team for a current repository service period when the development tasks are received, and generate a development requirement set based on component call requirements corresponding to the development period requirements and the development contents;

[0044] An establishment module is configured to establish a component call benchmark data set according to component deployment information of the last scheduling period of the standard view repository in a previous repository service period;

[0045] A solving module is configured to, based on the development requirement set and the component call benchmark data set, consider a constraint condition set constructed by taking into account a component occupation space limit of the standard view repository, a dependency relationship between components, and a cycle scheduling quantity limit, take the minimum number of service component deployment times as an optimization target, and solve an optimal storage and reference strategy of each service component in the template view repository and the standard view repository by using an optimization algorithm.

[0046] An execution module is configured to control the template view repository and the standard view repository to execute the service component storage and reference of the current repository service period according to the optimal storage and reference strategy.

[0047] The application has the advantages that: a service repository storage and reference method and system based on a componentization mode are provided, a double-track view repository including a template view repository (used by a team) and a standard view repository (used by multiple teams) is constructed, a development task period and content requirement are extracted to generate a development requirement set, a benchmark data set is established based on component deployment information of a previous period, an optimal storage and reference strategy is solved by combining storage, dependency and scheduling quantity constraints and taking the minimum service component deployment times as the target, and finally the double repository is controlled to execute storage and reference, so that efficient management of the componentized service repository is realized. Therefore, the application can effectively solve the component scheduling confusion problem caused by limited repository storage, dynamic component requirement changes and complex dependency relationships in MBSE development, realize fine planning and efficient reuse of component storage, reduce resource consumption of component update scheduling, and improve cross-team development efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0048] Figure 1 FIG. 1 is a flowchart of a service repository storage and reference method based on a componentization mode according to an embodiment of the application.

[0049] Figure 2 FIG. 2 is a structural diagram of a service repository storage and reference system based on a componentization mode according to an embodiment of the application. DETAILED DESCRIPTION

[0050] In order to make the objectives, technical solutions and advantages of the application clearer, further detailed descriptions will be given below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the application and do not limit the application.

[0051] The embodiment of the application provides a service repository storage and reference method based on a componentization mode, which refers to Figure 1 , Figure 1 FIG. 1 is a flowchart of a service repository storage and reference method based on a componentization mode according to an embodiment of the application.

[0052] In the embodiment, a service repository storage and reference method based on a componentization mode includes the following steps:

[0053] S1: Construct a view repository of a development team; wherein the view repository includes a template view repository used by each development team and a standard view repository used by several development teams;

[0054] S2: when receiving a plurality of development tasks of each development team for the current warehouse service period, extracting the development period requirement and the development content in the development task, and generating a development requirement set based on the component call requirement corresponding to the development period requirement and the development content;

[0055] S3: establishing a component call benchmark data set according to the component deployment information of the last scheduling cycle of the previous warehouse service period of the standard view warehouse;

[0056] S4: based on the development requirement set and the component call benchmark data set, considering a constraint condition set constructed based on the component occupation space limitation of the standard view warehouse, the dependency relationship between components and the cycle scheduling quantity limitation, taking the minimum service component deployment times as the optimization objective, and using an optimization algorithm to solve the optimal storage and reference strategy of each service component in the template view warehouse and the standard view warehouse;

[0057] S5: according to the optimal storage and reference strategy, controlling the template view warehouse and the standard view warehouse to execute the service component storage and reference of the current warehouse service period.

[0058] It should be noted that in the multi-development team collaborative development scenario (such as multiple ECU development teams and device development teams in the same enterprise jointly promoting a complex system project), component management faces two core requirements: one is the general component reuse requirement (such as basic components such as data encryption and log collection that all teams need to use, which need to ensure consistency and reliability); the other is the team individualized component management requirement (such as customized components developed by each team for specific business scenarios, which need to retain flexibility and self-management authority).

[0059] At the same time, there are two objective constraints in actual development: one is the limited warehouse storage resource (the physical or cloud storage capacity has an upper limit and cannot store all component versions unlimitedly); the other is the dynamic change of component requirement (the requirement for component type, version and function is different in different development periods and different tasks, and the component storage and reference strategy needs to be adjusted dynamically). The traditional component storage and reference method has been difficult to adapt to the efficient development requirement of MBSE multi-team collaboration.

[0060] To solve the above problems, the embodiment is constructed by building a double-track view warehouse containing a template view warehouse (team exclusive) and a standard view warehouse (multi-team shared), extracting the time period and content requirements of the development task to generate a development requirement set, establishing a baseline data set based on the component deployment information of the previous period, combining storage, dependency, and scheduling quantity constraints to minimize the service component deployment times to solve the optimal storage and reference strategy, and finally controlling the storage and reference of the double-warehouse to realize efficient management of the componentized service warehouse, which can effectively solve the component scheduling confusion problem caused by limited warehouse storage, dynamic component demand changes, and complex dependency relationships in MBSE development, realize fine planning and efficient reuse of component storage, reduce resource consumption of component update scheduling, and improve cross-team development efficiency.

[0061] In the preferred embodiment, step S1: building a view warehouse of the development team, specifically includes:

[0062] S11: building a standard view warehouse, establishing a first communication link between the standard view warehouse and the standard library administrator; wherein the first communication link is configured to transmit the component storage request uploaded by the standard library administrator, and drive the standard view warehouse to deploy the service component in the component storage request;

[0063] S12: building a plurality of template view warehouses, establishing a second communication link between the template view warehouses and the standard library administrator; wherein the second communication link is configured to upload the service components in the template view warehouse to the standard library administrator, and drive the standard library administrator to generate a component storage request based on the service components that pass the detection after detection and component detection.

[0064] On this basis, step S1: building a view warehouse of the development team, further includes:

[0065] S13: establishing a third communication link between each development team and the template view warehouse allocated to it; wherein the third communication link is configured to transmit the service components encapsulated in the view form created by the development team to the template view warehouse for storage;

[0066] S14: establishing a fourth communication link between each development team and the standard view warehouse; wherein the fourth communication link is configured to enable each development team to call the service components stored in the standard view warehouse when performing development tasks.

[0067] In this embodiment, a four-level communication link management system is designed: by constructing a standard view warehouse and establishing a first communication link between it and a standard library administrator, and by constructing a plurality of template view warehouses and establishing a second communication link between them and the standard library administrator, the component deployment of the standard warehouse and the warehouse entry audit transmission of the template warehouse component are realized; by establishing a third communication link between the development team and the assigned template view warehouse and a fourth communication link between the development team and the standard view warehouse, the storage transmission of the team-defined component and the calling transmission of the standard component are realized.

[0068] Therefore, through the design of the first communication link and the second communication link, the communication rights and responsibilities of the standard library administrator and the dual warehouse are clear, the transmission process of the component from the template warehouse creation to the standard warehouse deployment is standardized, the disordered warehouse entry of the component is avoided, and the authority and compliance of the standard warehouse component are ensured; through the design of the third communication link and the fourth communication link, the component storage channel between the team and the template warehouse and the component calling channel between the team and the standard warehouse are opened, so that the team can not only independently manage personalized components, but also conveniently reuse enterprise-level general components, and the flexibility of the team and the standardization of the enterprise are balanced.

[0069] Further, in S12, deployment detection and component detection are performed, specifically including:

[0070] S121: The standard library administrator judges whether the category and time period of the uploaded component match the corresponding deployment category and deployment time period in the optimal storage and reference strategy of the current warehouse service time period.

[0071] S122: The standard library administrator performs component detection on the uploaded component, including at least one or more combined detection items such as component security scanning, code quality analysis, and interface function verification.

[0072] In this embodiment, the standard library administrator first obtains the optimal storage and reference strategy of each warehouse service time period, which clearly specifies the component category to be deployed and the deployment time period in the current time period. The administrator compares the category (such as the device temperature warning component) and the planned deployment time period of the template warehouse uploaded component with the corresponding requirements in the optimal strategy to determine whether they match. Then, the administrator performs multi-dimensional quality detection on the uploaded component, including at least one or more of the following combinations: component security scanning (detecting whether there is malicious code or vulnerabilities), code quality analysis (detecting code redundancy rate, readability, and standardization), and interface function verification (detecting whether the component interface can normally receive / output data and whether it meets the general interface standard); only when all detection items pass, the component can enter the subsequent warehouse entry process.

[0073] Therefore, for the components uploaded by the template warehouse to the standard library administrator, the present application performs compliance verification on the warehouse entry components by judging whether the component category and time period match the optimal strategy and performing component security scanning and other detection items.

[0074] In a preferred embodiment, step S2: when receiving a plurality of development tasks of each development team for the current warehouse service period, extracting the development period demand and development content in the development task, generating a development demand set based on the component call demand corresponding to the development period demand and the development content, specifically comprising:

[0075] S21: when receiving a plurality of development tasks of each development team for the current warehouse service period, extracting the development period demand and development content in the development task;

[0076] S22: based on the development content, determining the component call demand of each development task, and generating a development demand set using the development period demand and the component call demand.

[0077] On this basis, S22: based on the development content, determining the component call demand of each development task, and generating a development demand set using the development period demand and the component call demand, specifically comprising:

[0078] S221: using a natural language processing tool to extract a plurality of technical keywords and a plurality of functional demand words in the development content;

[0079] S222: performing word group matching using the preset technical association word group of each service component and the technical keywords of each development task, calculating the matching rate of the technical association word of each service component in the plurality of technical keywords, extracting a plurality of service components with a matching rate exceeding a preset threshold, and realizing a first screening action of the service component for each development task;

[0080] S223: using the preset functional association word group of each service component under different component versions, judging the inclusion relationship between the preset functional association word group and the plurality of functional demand words of the development task, extracting the service component version in which the preset functional association word group is completely included in the plurality of functional demand words, and realizing a second screening action of the service component for each development task;

[0081] S224: using the development period demand and the service component candidate set after the two screening actions to generate a development demand set for each development task.

[0082] In this embodiment, for the development task of each development team in the current service period, the development period demand and the development content of the task are extracted, the component call demand is determined based on the development content, and the development demand set is integrated and generated. When generating the development demand set, the keywords are extracted by natural language processing, the technical component similarity is calculated, the functional demand word inclusion relationship is judged, the service component is screened twice, and the development demand set is generated in combination with the development period demand.

[0083] Specifically, first, a natural language processing (NLP) tool is used to process the text description of the development content (such as "real-time position acquisition and obstacle detection of industrial robots") to extract technical keywords (such as "industrial robot", "position acquisition", "obstacle detection") and functional requirement words (such as "centimeter-level precision", "automatic error correction"); in the initial screening, each service component is pre-configured with a "technical association word group" (such as the technical association word group of the "robot position acquisition component" is "industrial robot, position acquisition, real-time data"), the matching rate of the technical association words of each service component in several technical keywords is calculated, and the components with a matching rate exceeding a preset threshold are extracted to form a preliminary component candidate set (excluding components that do not match the technical field); in the re-screening, different versions of each component are pre-configured with a "functional association word group" (such as the functional association word group of the "robot position acquisition component V2.0" is "centimeter-level precision"), the inclusion relationship between the preset functional association word group and several functional requirement words of the development task is judged, and the service component version in which the preset functional association word group is entirely contained in the several functional requirement words is extracted to form a final component candidate set; finally, in generating the requirement set, the development period requirement of each task (such as "week 3") is associated with the final component candidate set (such as "robot position acquisition component V2.0 or later version", "robot obstacle detection component V1.5 or later version") to generate the requirement record of each task, which is aggregated into the development requirement set.

[0084] In the preferred embodiment, step S3: establishing a component call reference data set according to the component deployment information of the last scheduling period of the previous warehouse service period of the standard view warehouse, specifically includes:

[0085] S31: querying the component deployment database of the standard view warehouse, and extracting the optimal storage and reference strategy of the standard view warehouse in the previous warehouse service period recorded in the component deployment database;

[0086] S32: determining the component type and component version of each service component deployed in the standard view warehouse according to the optimal storage and reference strategy of the previous warehouse service period, and generating component deployment reference data;

[0087] S33: querying the attribute information of several service components of each template view warehouse; wherein the attribute information includes component type, component version, component occupied space, component storage location, component dependency relationship and version dependency relationship;

[0088] S34: establishing a component call reference data set based on the component deployment reference data and the attribute information of several service components.

[0089] In this embodiment, first, the component deployment database (storing historical scheduling strategies and deployment records) of the standard view warehouse is accessed to extract the optimal storage and reference strategy of the last scheduling period of the previous warehouse service period, which records all the component information of the previous period standard warehouse deployment. Then, based on the optimal strategy of the previous period, the core information of each deployed component is disassembled: component type, component version, forming the component deployment benchmark data (reflecting the historical deployment state of the standard warehouse), and then accessing the component attribute database of each template view warehouse to extract the attribute information of all service components, including component type, component version, component space, component storage location, component dependency relationship (such as "dependent on data encryption component"), version dependency relationship (such as "only compatible with V1.4 and above versions"), and finally integrating the component deployment benchmark data (standard warehouse historical deployment) and the attribute information of all template components to form the component call benchmark data set.

[0090] In the preferred embodiment, step S4: based on the development requirement set and the component call benchmark data set, considering the constraint condition set constructed based on the component space limit of the standard view warehouse, the dependency relationship between components, and the cycle scheduling number limit, taking the minimum service component deployment times as the optimization objective, using an optimization algorithm to solve the optimal storage and reference strategy of each service component in the template view warehouse and the standard view warehouse, specifically including:

[0091] S41: Extract the development period requirement of each development task in the development requirement set and the service component candidate set with different component types and component versions, and extract the component deployment benchmark data and the attribute information of several service components in the component call benchmark data set;

[0092] S42: taking the component type and component version of the service component deployed by the standard view warehouse in each scheduling period of the current warehouse service period as the planning decision variable, taking the sum of the component space of all service components deployed by the standard view warehouse in each scheduling period of the current warehouse service period as the first constraint condition, taking the service component deployed by the standard view warehouse in each scheduling period of the current warehouse service period containing: at least one version of each component type in the service component candidate set of each development task in the development period corresponding to the scheduling period and the dependent component corresponding to the service component as the second constraint condition, taking the deployment times of the service component executed by the standard view warehouse in each scheduling period of the current warehouse service period as the third constraint condition;

[0093] S43: Taking the minimum number of service component deployment times of the standard view warehouse in the current warehouse service period as an optimization target, an optimization algorithm is used to solve the optimal storage and reference strategy of the component type and component version of the service component deployed by the standard view warehouse in each scheduling period of the current warehouse service period.

[0094] In the embodiment, the development period requirement and the component candidate set of each task are extracted from the development requirement set, and the component deployment benchmark data and the template component attribute are extracted from the component call benchmark data set to provide input data for modeling. After that, the component type and version deployed by the standard warehouse in each scheduling period of the current service period are defined as core decision variables, and the first constraint (storage constraint) that the sum of the occupied spaces of all deployed components of the standard warehouse in each period is less than or equal to the storage limit allocated to the warehouse, the second constraint (dependency constraint) that the component deployed in each period needs to include at least one version of the service component in each component type in the task component candidate set in the period and the dependent component corresponding to the service component, and the third constraint (scheduling quantity constraint) that the component deployment times in each period are less than or equal to the maximum detection quantity of the standard library administrator in a single period are constructed, and an optimization algorithm is used to solve the optimal storage and reference strategy.

[0095] Therefore, based on the development requirement set and the component call benchmark data set, the component type and version of each scheduling period of the standard view warehouse are taken as decision variables, the storage, dependency, and scheduling quantity constraints are combined, the minimum component deployment times are taken as the target, the optimization algorithm is used to solve the optimal storage and reference strategy, the optimal strategy with the least deployment times can be found under multiple constraints, the component requirements of each team are met, the warehouse storage occupation, dependency integrity, and scheduling workload are controlled, and the balance between resource consumption and requirement satisfaction is realized.

[0096] In the preferred embodiment, step S5: according to the optimal storage and reference strategy, the template view warehouse and the standard view warehouse perform service component storage and reference in the current warehouse service period, specifically including:

[0097] S51: extracting the component type and component version of the service component deployed by the standard view warehouse in each scheduling period of the current warehouse service period planned in the optimal storage and reference strategy;

[0098] S52: according to the component type and component version of the service component deployed in each scheduling period, the template view warehouse is controlled to deploy the corresponding service component to the standard view warehouse through the standard library administrator in each scheduling period, and the standard view warehouse is controlled to clean the corresponding service component in each scheduling period, so as to realize the service component storage and reference of the template view warehouse and the standard view warehouse.

[0099] In this embodiment, according to the component type and version of each scheduling period of the standard view warehouse planned in the optimal storage and reference strategy, the corresponding components are uploaded from the template view warehouse to the standard warehouse, and the standard warehouse is cleared of unnecessary components, so that the component storage and reference of the double warehouse are realized. The optimal strategy is converted into executable warehouse operations to ensure that the component storage state of the double warehouse matches the demand, and the team can timely call the required components.

[0100] Referring to Figure 2 , Figure 2 FIG. 1 is a structural schematic diagram of a service warehouse storage and reference system based on a componentization mode according to an embodiment of the present application.

[0101] As Figure 2 shown, the service warehouse storage and reference system based on the componentization mode according to an embodiment of the present application comprises:

[0102] A construction module 10 is configured to construct a view warehouse of a development team, wherein the view warehouse comprises a template view warehouse dedicated to each development team and a standard view warehouse shared by several development teams;

[0103] An extraction module 20 is configured to extract development period demand and development content in a plurality of development tasks of each development team for a current warehouse service period when the development tasks are received, and generate a development demand set based on component call demand corresponding to the development period demand and the development content;

[0104] An establishment module 30 is configured to establish a component call benchmark data set according to component deployment information of the last scheduling period of the standard view warehouse in a previous warehouse service period;

[0105] A solving module 40 is configured to solve an optimal storage and reference strategy of each service component in the template view warehouse and the standard view warehouse by using an optimization algorithm, with a constraint condition set constructed by considering a component occupation space limit of the standard view warehouse, a dependency relationship between components and a periodic scheduling quantity limit, and with a minimum service component deployment times as an optimization objective, based on the development demand set and the component call benchmark data set.

[0106] An execution module 50 is configured to control the template view warehouse and the standard view warehouse to perform service component storage and reference of the current warehouse service period according to the optimal storage and reference strategy.

[0107] Other embodiments or specific implementation manners of the service warehouse storage and reference system based on the componentization mode according to the present application can refer to the above-mentioned method embodiments, which will not be described here again.

[0108] It is to be understood that the terms "one embodiment", "another embodiment", "other embodiments", "first embodiment", "second embodiment", etc. as may be found in the specification and / or in the claims, indicate that the alternative is included in at least one embodiment. These terms only specify the scope of claimable subject matter; and do not necessarily affect the scope of the application. Further, these terms only indicate particular embodiments of the applications. Other embodiments of the present application can be derived from the description, experimental results and / or the claims, without departing from the scope of the present application.

[0109] It is to be understood that the terms "including", "comprising", "consisting" and "consisting essentially of" or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0110] The above only describes the preferred embodiments of the present application, and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation, or direct or indirect application in other related technical fields, which is made according to the content of the specification and drawings of the present application, is also included in the patent protection scope of the present application.

Claims

1. A service repository storage and referencing method based on componentization pattern, characterized in that, The method comprises the following steps: S1: constructing a view warehouse of a development team; wherein the view warehouse comprises a template view warehouse dedicated to each development team and a standard view warehouse shared by several development teams; S2: when receiving several development tasks of each development team for a current warehouse service period, extracting development period requirements and development contents in the development tasks, and generating a development requirement set based on component call requirements corresponding to the development period requirements and the development contents; S3: establishing a component call benchmark data set according to component deployment information of the standard view warehouse in a last scheduling cycle of a previous warehouse service period; S4: based on the development requirement set and the component call benchmark data set, considering a constraint condition set constructed by taking into account component space limitations of the standard view warehouse, dependency relationships between components and cycle scheduling quantity limitations, taking the minimum service component deployment times as an optimization objective, and solving an optimal storage and reference strategy of each service component in the template view warehouse and the standard view warehouse by using an optimization algorithm; S5: controlling the template view warehouse and the standard view warehouse to perform service component storage and reference in the current warehouse service period according to the optimal storage and reference strategy.

2. The component-based pattern based service repository storage and referencing method of claim 1, wherein, Step S1: constructing a view warehouse of a development team, specifically comprising: S11: constructing a standard view warehouse and establishing a first communication link between the standard view warehouse and a standard library administrator; wherein the first communication link is configured to drive the standard view warehouse to deploy a service component in a component warehouse-in request when the standard library administrator uploads the component warehouse-in request; S12: constructing several template view warehouses and establishing a second communication link between the template view warehouses and the standard library administrator; wherein the second communication link is configured to upload a service component in the template view warehouse to the standard library administrator, and drive the standard library administrator to generate a component warehouse-in request based on the service component passing the detection after performing deployment detection and component detection.

3. The component-based pattern based service repository storage and referencing method of claim 2, wherein, In S12, the deployment detection and the component detection specifically comprise: S121: the standard library administrator judges whether the category and the period of the uploaded component conform to the corresponding deployment category and deployment period in the optimal storage and reference strategy in the current warehouse service period; S122: the standard library administrator performs component detection on the uploaded component by at least one or more combined detection items including component security scanning, code quality analysis and interface function verification.

4. The component-based pattern based service repository storage and reference method of claim 2, wherein, Step S1: constructing a view warehouse of a development team, further comprising: S13: establishing a third communication link between each development team and the template view warehouse allocated to the development team; wherein the third communication link is configured to transmit a service component in a view form created by the development team to the template view warehouse for storage; S14: establishing a fourth communication link between each development team and the standard view warehouse; wherein the fourth communication link is configured to realize that each development team calls a service component deployed in the standard view warehouse when performing a development task.

5. The component-based pattern based service repository storage and referencing method of claim 1, wherein, Step S2: when receiving a plurality of development tasks of each development team for the current warehouse service period, extracting the development period requirement and the development content in the development task, generating a development requirement set based on the component call requirement corresponding to the development period requirement and the development content, specifically including: S21: when receiving a plurality of development tasks of each development team for the current warehouse service period, extracting the development period requirement and the development content in the development task; S22: determining the component call requirement of each development task based on the development content, and generating a development requirement set using the development period requirement and the component call requirement.

6. The component-based pattern based service repository storage and referencing method of claim 5, wherein, S22: based on the development content, determine the component call requirement of each development task, and generate a development requirement set using the development period requirement and the component call requirement, specifically including: S221: use natural language processing tools to extract a plurality of technical keywords and a plurality of functional requirement words in the development content; S222: perform word group matching using the preset technical association word group of each service component and the technical keywords of each development task, calculate the matching rate of the technical association word of each service component in the plurality of technical keywords, extract a plurality of service components with a matching rate exceeding a preset threshold, and realize the first screening action of the service component for each development task; S223: use the preset functional association word group of each service component under different component versions to judge the inclusion relationship between the preset functional association word group and the plurality of functional requirement words of the development task, extract the service component version in which the preset functional association word group is completely included in the plurality of functional requirement words, and realize the second screening action of the service component for each development task; S224: use the development period requirement and the service component candidate set after the two screening actions to generate a development requirement set for each development task.

7. The component-based pattern based service repository storage and referencing method of claim 1, wherein, Step S3: according to the component deployment information of the standard view warehouse in the last scheduling period of the previous warehouse service period, establish a component call benchmark data set, specifically including: S31: query the component deployment database of the standard view warehouse, and extract the optimal storage and reference strategy of the standard view warehouse in the previous warehouse service period recorded in the component deployment database; S32: according to the optimal storage and reference strategy of the previous warehouse service period, determine the component type and component version of each service component deployed in the standard view warehouse, and generate component deployment benchmark data; S33: query the attribute information of a plurality of service components of each template view warehouse; wherein the attribute information includes component type, component version, component occupied space, component storage location, component dependency relationship and version dependency relationship; S34: based on the component deployment benchmark data and the attribute information of a plurality of service components, establish a component call benchmark data set.

8. The component-based pattern based service repository storage and referencing method of claim 7, wherein, Step S4: based on the development requirement set and the component call benchmark data set, considering the constraint condition set constructed by the component occupation space limit of the standard view warehouse, the dependency relationship between components and the cycle scheduling quantity limit, taking the minimum service component deployment times as the optimization objective, using an optimization algorithm to solve the optimal storage and reference strategy of each service component in the template view warehouse and the standard view warehouse, specifically including: S41: extracting the development period requirement of each development task in the development requirement set and the service component candidate set with different component types and component versions, extracting the component deployment benchmark data in the component call benchmark data set and the attribute information of several service components; S42: taking the component type and component version of the service component deployed by the standard view warehouse in each scheduling period of the current warehouse service period as the planning decision variable, taking the sum of the component occupation space of all service components deployed by the standard view warehouse in each scheduling period of the current warehouse service period does not exceed the component occupation space limit allocated to the standard view warehouse as the first constraint condition, taking the service component deployed by the standard view warehouse in each scheduling period of the current warehouse service period contains: at least one version of each component type in the service component candidate set of each development task running in the development period corresponding to the scheduling period and the dependent component corresponding to the service component as the second constraint condition, taking the deployment times of the service component by the standard view warehouse in each scheduling period of the current warehouse service period does not exceed the maximum detection quantity of the standard library administrator in a single scheduling period as the third constraint condition; S43: taking the minimum service component deployment times of the standard view warehouse in the current warehouse service period as the optimization objective, using an optimization algorithm to solve the optimal storage and reference strategy of the component type and component version of the service component deployed by the standard view warehouse in each scheduling period of the current warehouse service period.

9. The component-based pattern based service repository storage and referencing method of claim 8, wherein, Step S5: according to the optimal storage and reference strategy, controlling the template view warehouse and the standard view warehouse to execute the service component storage and reference in the current warehouse service period, specifically including: S51: extracting the component type and component version of the service component deployed by the standard view warehouse in each scheduling period of the current warehouse service period in the optimal storage and reference strategy; S52: according to the component type and component version of the service component deployed in each scheduling period, controlling the template view warehouse to upload the corresponding service component to the standard view warehouse in each scheduling period, and controlling the standard view warehouse to clear the corresponding service component in each scheduling period, realizing the service component storage and reference of the template view warehouse and the standard view warehouse.

10. A component-based service repository storage and reference system, comprising: The system comprises: a construction module configured to construct a view warehouse of a development team; wherein the view warehouse comprises a template view warehouse dedicated to each development team and a standard view warehouse shared by several development teams; The extraction module is configured to extract development period requirements and development contents in a plurality of development tasks of each development team for a current warehouse service period when the development tasks are received, and generate a development requirement set based on component call requirements corresponding to the development period requirements and the development contents; The establishment module is configured to establish a component call benchmark data set according to component deployment information of the standard view warehouse in a last scheduling cycle of a previous warehouse service period; The solving module is configured to solve, based on the development requirement set and the component call benchmark data set, a constraint condition set constructed by considering a component occupation space limit of the standard view warehouse, a dependency relationship between components, and a cycle scheduling quantity limit, to minimize a service component deployment quantity as an optimization target, and to solve, by using an optimization algorithm, an optimal storage and reference strategy of each service component in the template view warehouse and the standard view warehouse; The execution module is configured to control the template view warehouse and the standard view warehouse to execute service component storage and reference of the current warehouse service period according to the optimal storage and reference strategy.

Images