Software platform collaborative design method and device, equipment and storage medium

Abstract

The invention discloses a software platform collaborative design method and device, equipment and a storage medium. Comprising the steps that a software design task is obtained, the design task is distributed to multiple software developers based on different functions, original design achievements of the software developers are received, and the original design achievements comprise a topological graph which is constructed based on the distributed design task and takes software element entities as nodes and the relation between the software element entities as edges; and merging the software element entities in the original design results of the software developers and the relationship between the software element entities to obtain a software collaborative design result. According to the method, the function service is taken as a software delivery boundary, collaborative design of multiple suppliers is supported, the function modules of the software platform are taken as nodes, calling relations among different function modules are taken as edges to construct the network topology of the software platform, and function decoupling of a complex software system is realized; and a single software element entity can be independently called, upgraded and replaced, so that the expandability and the flexibility of the system are improved.

Description

Technical Field

[0001] This application relates to the field of software development technology, and more specifically, to a collaborative design method, apparatus, device, and storage medium for a software platform. Background Technology

[0002] As digital transformation deepens across industries, the complexity of software platforms continues to increase, posing significant challenges to their design, development, and maintenance. Take the software platform for smart highways as an example: it encompasses multiple business segments, including highway construction, management, maintenance, operation, and services. Each segment further comprises several business systems, carrying numerous business processes, functions, and internal / external user interfaces. To improve overall service and management efficiency, these business systems require large-scale data exchange and function calls.

[0003] However, as software platforms expand in scale, multi-vendor collaborative delivery is becoming increasingly common. Multiple vendors typically divide software portions and deliver systems based on business systems, further exacerbating the ecosystem problems of complex software systems. First, each business system focuses on implementing its own functions, making it difficult to form a holistic perspective. Second, data and functional barriers easily form between different business systems, leading to problems such as redundant construction, inconsistent standards, low reusability of functional modules, low operational efficiency, and difficulties in upgrading complex software systems. Third, the division based on business systems can easily lead to fragmented business processes; users may need to switch between different business systems to complete a task, severely impacting user experience. Summary of the Invention

[0004] This application provides a software platform collaborative design method, apparatus, device, and storage medium to at least solve the technical problems in related technologies, such as redundant construction, inconsistent standards, low functional module reuse rate, low operating efficiency, and difficulty in upgrading software systems.

[0005] According to one aspect of the embodiments of this application, a software platform collaborative design method is provided, comprising:

[0006] Obtain software design tasks and assign them to multiple software developers based on different functions. The software design tasks include a list of software functions and intelligent hardware resources that support the implementation of the software functions.

[0007] Receive the original design results from the software developer. The original design results include a topology graph constructed based on the assigned design tasks, with software element entities as nodes and the relationships between software element entities as edges. The software element entities include user entities, business scenario entities, functional service entities, data element entities, and smart hardware entities.

[0008] The software element entities and relationships between them in the original design results of each software developer are merged to obtain the software collaborative design results.

[0009] According to another aspect of the embodiments of this application, a software platform collaborative design apparatus is also provided, comprising:

[0010] The task generation module is used to obtain software design tasks and assign the design tasks to multiple software developers based on different functions. The software design tasks include a list of software functions and intelligent hardware resources that support the implementation of software functions.

[0011] The original design results receiving module is used to receive the original design results of the software developer. The original design results include a topology graph constructed based on the assigned design tasks, with software element entities as nodes and the relationships between software element entities as edges. The software element entities include user entities, business scenario entities, functional service entities, data element entities, and smart hardware entities.

[0012] The external design merging module is used to merge the software element entities and the relationships between them in the original design results of various software developers, and obtain the software collaborative design results.

[0013] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described software platform co-design method through the computer program.

[0014] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is configured to execute the above-described software platform co-design method at runtime.

[0015] The technical solutions provided in this application embodiment may include the following beneficial effects:

[0016] The software platform collaborative design method provided in this application supports collaborative design among multiple software developers by allocating design tasks to multiple software developers based on functional services. It treats the functional modules of the software platform as nodes and the calling relationships between different functional modules as edges to construct the network topology of the software platform. This achieves functional decoupling of complex software systems, allowing individual software element entities to be independently invoked, upgraded, and replaced, improving the scalability and flexibility of the software platform and contributing to the asset accumulation of complex software systems. Simultaneously, it highlights the core role of data elements as key variables in business process refactoring, avoiding frequent switching between different business systems and improving software usability and user experience. Through merging processing, it identifies and merges functionally similar software element entities, reducing redundant design and functional redundancy, and improving design consistency and standardization. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 This is a flowchart of a software platform collaborative design method according to an embodiment of this application;

[0019] Figure 2 This is a software element entity relationship diagram of a software platform according to an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of the external and internal design of a software element entity according to an embodiment of this application.

[0021] Figure 4 This is a schematic diagram of an integrated design interface of a software platform according to an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of a software platform collaborative design device according to an embodiment of this application;

[0023] Figure 6 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] To address the challenges of designing complex software platforms involving multiple systems and developers, fully highlight the core role of data elements as key variables in business process reengineering, and simultaneously consider the differentiated value of different functional modules, new collaborative design methods for software platforms are needed.

[0027] This application provides an integrated collaborative design method and tool for complex software platforms that implements the concept of data element-driven and business collaboration to realize process reengineering and supports multi-vendor collaborative software design.

[0028] This application highlights the driving role of data elements in complex software platforms. By allowing data elements to flow between various business systems and functional modules, it provides insights into the operating environment of each functional module and improves the operational efficiency of the functional modules.

[0029] It emphasizes breaking down the functional boundaries between various business systems, using functional modules as the software delivery boundary, supporting collaborative design among multiple vendors, and promoting the standardized development of software functional modules.

[0030] With the goal of making it easier for users to participate in business, we have reorganized and streamlined business scenarios and processes to provide users with a "one-stop" and "personalized" service experience.

[0031] By treating the functional modules of a complex software platform as nodes and the calling relationships between different functional modules as edges, a network topology of the complex software platform is constructed, forming a software topology network. Within this network, the differentiated value of different software modules is identified, and tasks such as resource estimation and development schedule coordination are performed.

[0032] This achieves functional decoupling of complex software systems, allowing individual software elements to be independently invoked, upgraded, and replaced. This helps to accumulate assets in complex software systems and extend their lifespan.

[0033] The following is in conjunction with the appendix Figure 1-4The software platform collaborative design method of this application embodiment will be described in detail. For example... Figure 1 As shown, the method mainly includes the following steps:

[0034] S101 acquires software design tasks and assigns these tasks to multiple software developers based on different functionalities.

[0035] The software design task includes a list of software functions and intelligent hardware resources that support the implementation of the software functions.

[0036] In one implementation, the administrator first configures a design task to launch the software platform, including generating... Figure 4 The blank canvas shown does not include software element entities and relationships between entities.

[0037] Furthermore, accounts and permissions are assigned to the software developers participating in the software design. There are K developers participating in the software platform design, denoted by {dev1, dev2, ..., dev...}. K The identifier}.

[0038] The administrator discussed and refined the software platform's feature list and development task allocation with the various software developers, clarifying the division of tasks among them. Design tasks were assigned to multiple software developers based on different functionalities.

[0039] In the embodiments of this application, a vertical canvas with swimlanes is generated in the software platform interactive interface. The swimlanes correspond to software element entities in the dimensions of smart hardware, data elements, functional services, business scenarios, and users.

[0040] like Figure 4 As shown, the interactive interface of this application is defined as a vertical canvas with swimlanes. The five swimlanes defined in this application correspond to the software element entities in five dimensions: smart hardware, data elements, functional services, business scenarios, and users.

[0041] This application categorizes software element entities into five dimensions: smart hardware, data elements, functional services, business scenarios, and users. The relationships between these five dimensions are as follows: Figure 2 As shown.

[0042] Among these, smart hardware collects raw data, providing input for the generation of data elements; smart hardware also receives calls to functional services, providing automated services to users. For example, video equipment on highways can collect video images, which, after AI processing, can generate data elements such as traffic events and traffic flow; smart information boards can receive calls to information board publishing services, projecting the content to be published onto the information board to reach users.

[0043] Data elements receive data collected by smart hardware, generate data elements, and provide input for the operating environment of functional services, thereby driving the operation of functional services. For example, traffic flow and traffic congestion are data elements; data elements are called by functional services as input for those services. This application lists data elements as a separate dimension and imposes mandatory constraints in the design: the implementation of functional services must depend on data elements and use data elements as input. This is to highlight the driving role of data elements; the implementation of any function and business must be based on data elements as the basis for environmental insight, and as the driving factor and triggering condition for function and business execution. It is emphasized here that traditional software often uses manual input as the input method for data elements, making manual input a hotspot for software system functions, and manual input has great uncertainty. The data elements in this application include manual input, but rely more on the automatic data collection capabilities of smart hardware. This will greatly improve the efficiency and accuracy of data collection, enhance the perception and insight into the supply and demand and environment of business operations, and enhance the empowering ability of data elements for subsequent business.

[0044] Functional services provide integrated and standardized software functions. The division and setting of functional services follow the principle of "high cohesion and low coupling," and are generally implemented using a "microservice" approach. Standardization and integration aim to improve the reusability of software modules, prevent redundant development, reduce the overall workload of software development, and thus improve the quality of software development with the same investment.

[0045] A business scenario corresponds to an independent business process that a user needs to implement through a software system. A business scenario combines users and functional services through a specific process. Taking users and functional services as input, a business scenario optimizes the defined business process and user interface (including traditional software interfaces and large-scale model interfaces) to enable interaction between users and functional services, thereby completing the independent business process.

[0046] This application emphasizes business scenarios rather than business systems, because the atomic unit of user interaction is the business scenario. The completion of a business scenario may be cross-system. By reconstructing the business system in a scenario-based manner, we can avoid users frequently switching between business systems and improve the user's software interaction experience.

[0047] Users interact with functional modules through the interactive interface provided by the business scenario and follow the business processes defined by the business scenario. These users include both internal management users and external service users. They all indirectly interact with smart hardware by participating in the business scenario and interacting with functional services.

[0048] In this application, the application system does not play a role in business analysis and design. Instead, it is defined as an optimized combination of users and business scenarios. Based on the relevance of users and business scenarios, users and business scenarios are divided into different business systems to minimize the number of systems that the same type of user logs into, or even to log into only one system.

[0049] In summary, this application highlights the design principle of data-driven scenario-based process refactoring by defining five dimensions of software element entities, and ensures the implementation of these principles in a multi-developer context through an integrated collaborative design approach. Furthermore, this application achieves decoupling of software element entities, which facilitates their independent invocation, upgrading, and replacement during subsequent development and maintenance. This contributes to the asset accumulation of complex software systems and extends their lifespan.

[0050] In one implementation, the canvas is gridded, with each software element entity positioned at the center of a single grid, and the position of the software element entity in the software design view is defined based on the grid subscript.

[0051] Specifically, the canvas is divided horizontally into several rows, thus creating a grid. Each software element entity is positioned, and can only be positioned, at the center of a single grid cell. The position coordinates of the software element entity in the software design view can be defined using the grid indices (x, y), where x is the vertical grid index and y is the horizontal grid index. Figure 4 The coordinates of the software element entity X are (x3, y2).

[0052] In one implementation, the system further includes: an interactive interface providing add, delete, modify, and query operations for software element entities, and a flowchart drawing function for the internal design of software element entities. Modification operations include moving the position of the software element entity, generally supporting only vertical movement, and ensuring the target position is not occupied. The system also provides functions such as querying and editing data items of software element entities, and drawing flowcharts for the internal design of software element entities.

[0053] It provides operations for establishing and deleting connections between different software element entities. When a connection is established between two software element entities, a connection line is drawn between the two elements on the interface, and both software element entities will be added to each other's external design related element sets (e.g., ...). Figure 3 Elements A, C, and D are related to element X, and vice versa. Furthermore, in addition to straight lines, the connections between elements can also be curved for aesthetic purposes, thus creating a visual effect similar to a Sankey diagram.

[0054] Provides optimized display functions for the interactive interface. Given that complex software systems involve numerous software entities and multiple software developers, optimized display functions are provided, including distinguishing the entities and relationships between different developers by color or shape; and filtering or highlighting the displayed content based on the developer or entity relationship.

[0055] The design task of this application includes generating a graph with software element entities as nodes and the relationships between software element entities as edges.

[0056] Specifically, the outcome of complex software design is defined as a graph with software element entities as nodes and the relationships between them as edges. The process of complex software design is then a controlled graph generation process. Note that in the following description, especially in the graph context, software element entities will also be referred to as nodes. Graphs are generated efficiently under the constraints of software design principles through the interaction between different software developers and the integrated design system.

[0057] From a graph perspective, each business scenario is defined by a subgraph of the graph. Different subgraphs may share nodes and edges, representing that different business scenarios may share software modules. The graph defines all business scenarios of the software platform.

[0058] Secondly, define the attribute information of software element entities. The attribute information of a software element entity includes its ID, type, location, status, function list, identifiers of related software element entities, software flowchart, software developer identifier, and full lifecycle information. Among these, the identifiers of related software element entities include the interfaces corresponding to the related software element entities and the relationship between the related software element entity and this software element entity.

[0059] Specifically, the software element entities across five dimensions—smart hardware, data elements, functional services, business scenarios, and users—are defined in a normalized manner. Each software element entity (see) is defined as an 8-tuple:

[0060] see = <id,yype,(x,y),state,T func E rela ,FD func ,dev,Info life >

[0061] Among them, id uniquely identifies a software element entity; type defines the type of software element entity, mainly referring to five types: smart hardware, data elements, functional services, business scenarios, and users; (x,y) defines the position of the software element entity in the software design architecture view; state defines the state of the software element entity, including information such as the design maturity, development progress, and operation permissions of the software element entity.

[0062] T func This describes the functional list of the software element entity within the software design architecture; E rela It stores other software element entities that are related to this software element entity in terms of data or business interaction, mainly representing the results of external design, and also stores information such as interface definitions for interaction with other software element entities; FD func The software flowchart for implementing this software element entity is stored, mainly representing the results of the internal design; dev defines the developer of this software element entity; Info life It stores information about the entire lifecycle of the software element entity, including creation information, status information, modification logs, etc.

[0063] Finally, before starting the software design task, it is first necessary to... Figure 4 The types of smart hardware and users are defined. Generally speaking, these two elements are constrained by project funding and boundaries, which are certain and cannot be exceeded. All software developers' designs cannot exceed the established scope of smart hardware and users, otherwise, the software functions will not be realized or the functional scenarios will not be implemented.

[0064] S102 receives the original design results from the software developer. The original design results include a topology graph constructed based on the assigned design tasks, with software element entities as nodes and the relationships between software element entities as edges.

[0065] Among them, software element entities include user entities, business scenario entities, functional service entities, data element entities, and smart hardware entities.

[0066] In one implementation, constructing software element entities and the relationships between software element entities based on assigned design tasks includes:

[0067] Obtain the function list corresponding to the assigned design task; determine the user entity associated with each function based on the function list; implement the business scenario entity corresponding to the function; associate the user entity with the functional service entity and data element entity corresponding to the business scenario entity based on the business scenario entity; associate the smart hardware entity used to provide data elements with the determined data element entity; use the determined smart hardware entity, data element entity, functional service entity, business scenario entity, and user entity as the software element entity set corresponding to the assigned design task; use the relationships between each software element entity as the software element entity relationship set corresponding to the assigned design task; draw a topology graph with software element entities as nodes and relationships between software element entities as edges based on the software element entity set and the software element entity relationship set to obtain the original design result.

[0068] Based on the assigned software development tasks, new software element entities are added to the canvas, and relationships between these entities are established. At this stage, the software developer's design work is conducted independently; they cannot view or manipulate software element entities or relationships added by other software developers.

[0069] In this step, full permissions for adding, deleting, modifying, and querying software element entities are granted, allowing each software developer to construct the software element entities and relationships corresponding to their own development tasks with full authority.

[0070] The software developer successfully submitted the original design, which included a topological graph constructed based on the assigned design tasks, with software element entities as nodes and the relationships between software element entities as edges.

[0071] Let's assume that for developer dev k In this regard, the result of its preliminary design is defined as G0(dev) k )={node0(dev k ),edge0(dev k )}, 1≤k≤K. Where, node0(dev k ) stores the developer dev k The software element entity defined by completing the development task it has assigned, edge0(dev) k It stores the relationships between software element entities.

[0072] In the initial design phase, for any software element entity see k (x,y)∈node0(dev k ), representing the developer dev k In G0(dev) k Software element entities placed in the (x,y) grid. k(x, y), the developer needs to fill in the details. k (x,y).T func This field represents the software developer's description of the functional list of the software element node, and is also the software developer's response to the software development functional list.

[0073] S103 merges the software element entities and the relationships between them in the original design results of each software developer to obtain the software collaborative design results.

[0074] In one implementation, the original design deliverables from each software developer are merged to obtain preliminary design results. This includes: collecting the original design deliverables from each software developer and determining whether the functional definition descriptions of the software element entities corresponding to the original design deliverables cover the software function list corresponding to the software design task; if all are covered, the next merging process is carried out; if not all are covered, the software developers are notified to supplement the design.

[0075] Specifically, the merging process includes calling the analysis model to perform semantic similarity analysis on the functional definition description information of the summarized software element entities of the same type, and obtaining the analysis results. The analysis results include substitutable relationships, inclusion relationships, no relationship, and relationships to be confirmed. Nodes with substitutable and inclusion relationships are designated as nodes to be merged, and the merging process is performed on these nodes. After merging the nodes to be merged in the original design results, the preliminary design results are obtained.

[0076] In one implementation, first, the nodes to be merged are identified:

[0077] See any two software element entities of the same type in node0 k (x1, y1) and see k’ (x2,y2), where k and k' may be the same or different, representing designs from the same or different software developers.

[0078] see k (x1,y1).T func and see k’ (x2, y2).T func Semantic similarity analysis is performed. This application utilizes a large model for semantic similarity analysis, and preliminary results are provided for the analysis of see. k (x1,y1).T func and see k’ (x2, y2).T func Four similarity conclusions:

[0079] 1) Substitutable relationship (see) k (x1,y1).T func =seek’ (x2, y2).T func That is, only one of them can be retained in subsequent designs;

[0080] 2) Inclusion relationship (see) k (x1,y1).T func ∈see k’ (x2, y2).T func The function of one can be overridden by another;

[0081] 3) No relation see k (x1,y1).T func ≠see k’ (x2, y2).T func There is no similarity;

[0082] 4) Relationships that cannot be categorized into the above situations and require manual intervention for judgment.

[0083] Furthermore, the merging process for the nodes to be merged includes: sending the nodes to be merged to the corresponding software developers and providing an online chat function so that the software developers can negotiate the merging process.

[0084] The merging process includes: for nodes with substitutable relationships, retaining one of the nodes and transferring the relationships between the non-retained nodes and other nodes to the retained node; for nodes with inclusive relationships, retaining the node with the larger functional scope and transferring the relationships between the node with the smaller functional scope and other nodes to the retained node; or, splitting the node with the larger functional scope.

[0085] Specifically, the merging process is handled through negotiation among the vendors involved in the nodes with merging relationships. For the four scenarios mentioned above, the following four processing methods can be adopted respectively:

[0086] 1) Keep one of the nodes (see) k (x1, y1), another node see k’ The relationship between (x2, y2) and other software element entities is transferred to the retained node see. k (x1,y1).

[0087] 2) One type is where nodes with a small functional scope are deleted, i.e., only the see node is retained. k’ (x2, y2), see k The relationship between (x1, y1) and other software element entities is transferred to See. k’ (x2, y2); another way is to see k’ The node (x2, y2) is split into two independent functional nodes, each satisfying the condition "see". k (x1,y1).T func and seek’ (x2, y2).T func -see k (x1,y1).T func Define the functions and further readjust the relationships with other software element entities.

[0088] 3) No adjustments will be made;

[0089] 4) The manufacturer will negotiate a flexible solution.

[0090] The results of the above merging process are incorporated into the node's lifecycle management, i.e., stored in the Info of the software data elements. life In the field.

[0091] Optionally, the functional similarity of software element entities can also be judged from the perspective of the network, by referring to the similarity of their upstream and downstream software element entities, thereby increasing the accuracy of similarity identification.

[0092] By merging similar software elements, redundant design and functional redundancy are reduced, thereby improving design consistency and standardization.

[0093] Furthermore, after the merging process, the process also includes: receiving software flowcharts of the software element entities that the software developers are responsible for, edited based on the relationships between the merged software element entities; verifying the software flowcharts corresponding to each software element entity using internal and external constraint mechanisms, and using the software flowcharts that simultaneously satisfy both internal and external constraint mechanisms as the standard software flowcharts for that software element entity; and using the standard software flowcharts as attributes of the software element entities in the software collaborative design results.

[0094] The preliminary design result generated in the third step of merging is defined as G1 = {G1(dev1), G1(dev2), ..., G1(dev...}} K )}.

[0095] By each developer dev k Regarding the merged software functional scope G1 (dev) that it is responsible for k According to G1(dev) k The upstream and downstream relationships of each node in the (see) are defined for the corresponding software element entities. k See the software flowchart for (x,y). k (x,y).FD func Edit.

[0096] For each software element entity, this application proposes a design principle that combines internal and external design constraints. When editing the software flowchart, the upstream and downstream relationships of the nodes need to be considered.

[0097] Specifically, the software flowcharts edited by the software developers based on the relationships between the software element entities they are responsible for after the merging process include:

[0098] Obtain the merged information of the software element entities it is responsible for, as well as the external connection points of each software element entity. The external connection points include input nodes, output nodes, and calling nodes. Determine the internal calculation process of the software element entity based on its functional definition. Connect the input nodes, calling nodes, and output nodes as flowchart elements according to the flow nodes corresponding to the internal calculation process to obtain the software flowchart of the software element entity.

[0099] Understandably, the design process of software element entities is divided into two processes: external design and internal design, such as... Figure 3 As shown, the external design defines the relationship between software element entities and other software element entities; the internal design, based on the relationship with other software element entities, defines the implementation logic of the software entity, which is generally represented by a software flowchart.

[0100] exist Figure 3 In this design, software entity X has input relationships with C and D, and an output relationship with A. Therefore, the external design defines X's function as reading data from C and D, processing it, and outputting the result to A. The internal design is based on the external design, so X's software flowchart also follows the principle of C and D as inputs and A as output. Simultaneously, X's internal calculation process cannot contain calculation modules (such as B) that can be replaced by other software entities. If such modules exist, a relationship with B must be introduced. This aims to improve software reusability and prevent redundant development. On the other hand, if X cannot achieve its intended function based on C and D associated with the external design during the internal design (i.e., flowchart drawing process), it can force the external design to be modified, redefining its relationships with other software entities (e.g., introducing relationships with other software entities), or modifying X's functional definition (e.g., many functional definitions lack data element foundations due to hardware acquisition limitations, resulting in the inability to implement the functional definition). The internal and external constraint mechanism proposed in this application helps improve the design efficiency of complex software systems.

[0101] Furthermore, the internal and external constraint mechanisms for validating the software flowchart corresponding to each software element entity include:

[0102] Obtain the functional description, internal calculation process, and external connection nodes corresponding to the software element entity. The external connection nodes include input nodes, output nodes, and calling nodes. Determine whether the external connection nodes required by the internal calculation process of the obtained software element entity are consistent with the external connection points corresponding to the software element entity in the collaborative design results. If they are consistent, verify them through the external constraint mechanism. Determine whether the software element entity can realize the functional description based on the external connection points and internal calculation process. If it can, verify it through the internal constraint mechanism.

[0103] In one implementation, the method further includes: recording user operations during flowchart drawing, including adding new elements, element attributes, connection relationships between elements, and connection relationships between elements and related software element entities; calling the model to generate functional descriptions for the new elements and performing similarity analysis with the functional descriptions of other software element entities; and based on the analysis results, prompting the administrator whether it is necessary to integrate other software element entities into the flowchart of the current software element entity.

[0104] Specifically, this application records user operations, added flowchart elements and attributes, connections between elements, and connections between elements and other related software element entities during the flowchart drawing process. It then uses a large model to refine and generate functional descriptions for the added flowchart elements. These functional descriptions are then compared with the functional descriptions of other software element entities in the large model to perform similarity analysis, prompting the administrator whether other software element entities need to be further integrated into the implementation logic of the current software element entity.

[0105] When drawing flowcharts for software element entities, the process also includes: when a software element entity has a connection relationship with software element entities of other software developers, negotiating and drawing the flowchart with other software developers based on online conversation functionality.

[0106] After merging, each node may have relationships with nodes from other vendors. If this occurs, the node's internal design must be negotiated with other vendors. For example, this involves designing software-supported online sessions and confirmation functions to ensure the final delivered design meets the reuse requirements of other vendors. Furthermore, the interaction interfaces with other nodes must be negotiated and stored in the `see` file. k (x,y).E rela middle.

[0107] Furthermore, check whether the software flowchart that automatically identifies software element entities contradicts the preliminary design results; if so, submit it to all software developers for discussion and correction.

[0108] In the detailed design of individual software element entities, situations that contradict or conflict with the preliminary design in step three may be identified. For example, some software element entities may not be used as elements in the flowchart, or situations involving other software element entities may be omitted. These situations need to be submitted to all software developers for discussion and correction. The final design result, reviewed by all software developers, is: G2 = {G2(dev1), G2(dev2), ..., G2(dev...} K )}.

[0109] In one implementation, the system further includes: automatically generating and exporting standardized design documents for the collaborative design results of the software platform; functions for collecting, statistically analyzing, and reporting design results; and auditing outcomes. It also includes evaluating the collaborative design results.

[0110] In one implementation, evaluating the collaborative design results includes: calculating the total number of edges directly connected to a node to obtain the node's degree; and calculating the number of paths in the network that pass through the node to obtain the node's betweenness number.

[0111] In G2, each node is placed within a network structure, and the value of a node can be evaluated from the network dimension, such as by assessing its degree, betweenness, and other metrics, thereby identifying key nodes and ensuring the rationality of resource investment and node development.

[0112] A node's degree is the total number of edges directly connected to it. A higher degree indicates a more closely connected node. A node's betweenness number is the number of paths in the network that pass through that node. A higher betweenness number indicates a critical node in ensuring the proper functioning of the overall network.

[0113] Furthermore, the value of software element entities is evaluated based on the degree and betweenness of nodes. Nodes with higher degree and betweenness are called by more modules, thus their functional importance and value are greater; on the other hand, it is necessary to ensure resource investment to guarantee the quality and reliability of their development.

[0114] Furthermore, the throughput and development schedule of software elements are evaluated for their rationality. Based on the network structure, the throughput of upstream nodes can be quantitatively evaluated by working backward from the designed throughput of downstream nodes, thus providing a basis for hardware allocation and testing.

[0115] Based on the network structure, the development progress of different nodes is constrained by their upstream and downstream nodes. Based on the above constraints, the rationality of the submitted software development progress can be evaluated, or when there are differences in the development progress, the impact on the overall software progress can be evaluated from the perspective of the network, providing a basis for decision-making to adjust the progress.

[0116] The proposed solution divides the design of complex software platforms into three stages: preliminary design, detailed design, and evaluation and tracking.

[0117] The preliminary design phase involves defining entities and performing correlation analysis (defining relationships between entities) across five dimensions: smart hardware, data elements, functional services, business scenarios, and users. It also includes entity deduplication and merging. The output consists of a set of entities and a set of relationships between entities. During the preliminary design process, the technical implementation logic of the entities can be disregarded, allowing the design focus to be placed on the relationships between entities. This approach allows for a holistic view of the driving role of data elements, simplifying interaction paths between different functional services, and minimizing redundant development.

[0118] The detailed design phase uses the results of the preliminary design as input to define the technical implementation logic of each entity (expressed as a software flowchart), especially the technical implementation logic of the three types of entities: data elements, functional services, and business scenarios. The deliverable of the technical implementation logic is the software flowchart. Note that the preliminary design defines the entities and the relationships between them (relationships include input, output, and call relationships, etc.). Therefore, the implementation logic of a single entity must be limited by the relationships between entities. Furthermore, the implementation logic of a single entity cannot override the logic implementation of other defined entities. The advantage of this is that it ensures that a single entity can be logically implemented while maximizing the reuse of the functionality of other entities, thereby reducing the overall workload of software development. In addition, the preliminary design can be iteratively revised during the detailed design process.

[0119] The evaluation and tracking phase constructs the software topology network of the complex software platform based on the relationships between entities defined in the detailed design and the technical logic within each entity. Utilizing theories of complex networks and software reliability, it quantitatively evaluates the value and resource requirements of each software module within the complex software platform, as well as the dependencies between different software modules in their development sequence. For example, it infers the I / O throughput of a specific module through the call relationships between different modules. Furthermore, based on the above analysis, software development and operation support resources can be configured, and development and integration progress can be tracked.

[0120] The solution proposed in this application is a collaborative interaction design method for complex software platforms from multiple vendors. This method can implement the data-driven optimization function design concept, as well as user-centered scenario optimization and reconstruction, to ensure the delivery quality of the final complex software platform.

[0121] The software element entities are defined in five dimensions: smart hardware, data elements, functional services, business scenarios and users. The software element entities in each dimension are defined in two stages, as are the relationships between entities and the technical processes within entities. The division of labor for software design work in each stage is clear, which reduces the overall design workload and improves the design quality of the software.

[0122] After interaction with complex software platforms, standardized and serialized data elements and functional service components can be formed. These components can be independently upgraded and supplemented to support further functional optimization, reduce the maintenance workload throughout the platform's lifecycle, and also have the conditions to be integrated with large models, laying a solid foundation for intelligent business integration.

[0123] The resulting integrated design interface implements and constrains the collaborative software design process proposed in this application, while also possessing capabilities such as automated collection of software assets and reporting of results.

[0124] This forms a software topology network for complex software platforms, which can be used to identify key software modules and software development sequence relationships, thereby enabling more efficient resource allocation and tracking support, and ensuring work efficiency throughout the entire software development lifecycle.

[0125] According to another aspect of the embodiments of this application, a software platform collaborative design apparatus for implementing the above-described software platform collaborative design method is also provided. For example... Figure 5 As shown, the device includes:

[0126] The task generation module 501 is used to obtain software design tasks and assign the design tasks to multiple software developers based on different functions. The software design tasks include a list of software functions and intelligent hardware resources that support the implementation of software functions.

[0127] The original design result receiving module 502 is used to receive the original design results of the software developer. The original design results include a topology graph constructed based on the assigned design tasks, with software element entities as nodes and the relationships between software element entities as edges. The software element entities include user entities, business scenario entities, functional service entities, data element entities, and smart hardware entities.

[0128] The external design merging module 503 is used to merge the software element entities and the relationships between software element entities in the original design results of various software developers to obtain the software collaborative design results.

[0129] It should be noted that the software platform collaborative design device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the software platform collaborative design method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the software platform collaborative design device and the software platform collaborative design method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0130] According to another aspect of the embodiments of this application, an electronic device corresponding to the software platform co-design method provided in the foregoing embodiments is also provided, so as to execute the software platform co-design method described above.

[0131] Please refer to Figure 6 This illustrates a schematic diagram of an electronic device provided by some embodiments of this application. For example... Figure 6 As shown, the electronic device includes: a processor 600, a memory 601, a bus 602, and a communication interface 603. The processor 600, the communication interface 603, and the memory 601 are connected via the bus 602. The memory 601 stores a computer program that can run on the processor 600. When the processor 600 runs the computer program, it executes the software platform co-design method provided in any of the foregoing embodiments of this application.

[0132] The memory 601 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 603 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network.

[0133] Bus 602 can be an ISA bus, PCI bus, or EISA bus, etc. Buses can be divided into address buses, data buses, control buses, etc. Memory 601 is used to store programs. After receiving execution instructions, processor 600 executes the program. The software platform co-design method disclosed in any of the aforementioned embodiments of this application can be applied to processor 600, or implemented by processor 600.

[0134] The processor 600 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 600 or by instructions in software form. The processor 600 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 601. Processor 600 reads the information in memory 601 and, in conjunction with its hardware, completes the steps of the above method.

[0135] The electronic device provided in this application embodiment and the software platform co-design method provided in this application embodiment are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0136] According to another aspect of the embodiments of this application, a computer-readable storage medium corresponding to the software platform co-design method provided in the foregoing embodiments is also provided, wherein a computer program (i.e., a program product) is stored thereon, and the computer program executes the software platform co-design method provided in any of the foregoing embodiments when it is run by a processor.

[0137] It should be noted that examples of computer-readable storage media may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0138] The computer-readable storage medium provided in the above embodiments of this application and the software platform co-design method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0139] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0140] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this patent should be determined by the appended claims.

Claims

1. A collaborative design method for a software platform, used in a software design platform, characterized in that, include: Obtain software design tasks and assign them to multiple software developers based on different functions. The software design tasks include a list of software functions and intelligent hardware resources that support the implementation of the software functions. Receive the original design results from the software developer. The original design results include a topology graph constructed based on the assigned design tasks, with software element entities as nodes and the relationships between software element entities as edges. The software element entities include user entities, business scenario entities, functional service entities, data element entities, and smart hardware entities. The software element entities and relationships between them in the original design results of each software developer are merged to obtain the software collaborative design results.

2. The method according to claim 1, characterized in that, The software element entities constructed based on the assigned design tasks and the relationships between these software element entities include: Obtain the list of functions corresponding to the assigned design tasks, determine the user entities associated with each function based on the list of functions, and implement the business scenario entities corresponding to the function. Based on the business scenario entity, associate user entities with the corresponding functional service entities and data element entities that implement the business scenario entity; The identified data element entities are associated with the intelligent hardware entities used to provide the data elements; The identified intelligent hardware entities, data element entities, functional service entities, business scenario entities, and user entities are used as the set of software element entities corresponding to the assigned design tasks, and the relationships between each software element entity are used as the set of software element entity relationships corresponding to the assigned design tasks. Based on the set of software element entities and the set of software element entity relationships, a topology graph is drawn with software element entities as nodes and the relationships between software element entities as edges, thus obtaining the original design result.

3. The method according to claim 1, characterized in that, The software element entities and relationships between them in the original design deliverables of various software developers are merged, including: Collect the original design results from various software developers and determine whether the functional definition descriptions of the software element entities corresponding to the original design results cover the software function list corresponding to the software design task. If all are covered, the analysis model is invoked to perform semantic similarity analysis on the functional definition description information of the summarized software element entities of the same type, and the analysis results are obtained; the analysis results include substitutable relationships, inclusion relationships, no relationship, and pending confirmation; The nodes with the substitutable and inclusive relationships are taken as nodes to be merged, and the nodes to be merged are merged. After merging the nodes to be merged in the original design results, the preliminary design results are obtained.

4. The method according to claim 3, characterized in that, The merging process includes: For nodes with substitutable relationships, retain one of the nodes and transfer the relationships between the non-retained nodes and other nodes to the retained node; For nodes containing relationships, retain the node with the larger functional scope and transfer the relationships between the node with the smaller functional scope and other nodes to the retained node; or, split the node with the larger functional scope.

5. The method according to claim 1, characterized in that, After the merging process, the method further includes: Receive the software flowchart of the software element entities under the responsibility of the software developer, which is edited based on the relationships between the merged software element entities under the developer's responsibility. For each software element entity, the software flowchart corresponding to the software constraint mechanism is verified by internal and external constraint mechanisms. The software flowchart that simultaneously satisfies the internal and external constraint mechanisms is taken as the standard software flowchart of the software element entity. The standard software flowchart is used as an attribute of the software element entity in the software collaborative design result.

6. The method according to claim 5, characterized in that, Based on the merged relationships between the software element entities under their responsibility, the software developer edits the software flowcharts for those entities, including: Obtain the merged information of the software element entities it is responsible for, as well as the external connection points of each software element entity. The external connection points include input nodes, output nodes, and calling nodes. Determine the internal calculation process of the software element entity based on its functional definition. The input node, calling node, and output node are used as flowchart elements and connected in a directed manner according to the flowchart nodes corresponding to the internal calculation process to obtain a software flowchart of software element entities.

7. The method according to claim 5, characterized in that, The internal and external constraint mechanisms for validating the software flowchart corresponding to each software element entity include: Obtain the functional description, internal calculation process, and external connection nodes corresponding to the software element entities. The external connection nodes include input nodes, output nodes, and calling nodes. Determine whether the external connection nodes required for the internal calculation process of the obtained software element entity are consistent with the external connection nodes corresponding to the software element entity in the collaborative design result. If they are consistent, verify them through the external constraint mechanism. Determine whether the software element entity can realize the described function based on external connection points and internal calculation process. If it can, verify it through internal constraint mechanism.

8. The method according to claim 1 or 3, characterized in that, The software design platform's interactive interface includes a gridded canvas with vertical swimlanes. The swimlanes correspond to software element entities in the dimensions of smart hardware, data elements, functional services, business scenarios, and users, respectively. Each software element entity is placed at the center of a single grid. The method further includes: On the canvas, select the software element entity corresponding to the original design result, and draw the relationship between the software element entities through preset directed connection lines to obtain a topology graph with the software element entities as nodes and the relationship between the software element entities as edges.

9. The method according to claim 1, characterized in that, The software element entities in the collaborative design results include number identifiers, type identifiers, software developer identifiers, function definitions, related software element entity identifiers, software flowchart information, and full lifecycle information; The associated software element entity identifier includes the interface corresponding to the associated software element entity and the relationship between the associated software element entity and this software element entity.

10. The method according to claim 5, characterized in that, The method further includes: Record user actions when drawing the flowchart, including adding elements, element attributes, connection relationships between elements, and connection relationships between elements and related software element entities; The model is invoked to generate functional descriptions for newly added elements, and a similarity analysis is performed on the functional descriptions of other software element entities. Based on the analysis results, the administrator is prompted whether other software element entities need to be integrated into the flowchart of the current software element entity.

11. The method according to claim 1, characterized in that, The method also includes evaluating the collaborative design results. The evaluation of the collaborative design results includes: Calculate the total number of edges directly connected to a node to obtain the degree of the node; The betweenness number of the shortest path in the network that passes through this node is calculated. Evaluate the value of software element entities based on the degree and betweenness of nodes; Assess the reasonableness of the throughput and development schedule of software element entities.

12. A software platform collaborative design device, characterized in that, include: The task generation module is used to obtain software design tasks and assign the design tasks to multiple software developers based on different functions. The software design tasks include a list of software functions and intelligent hardware resources that support the implementation of software functions. The original design result receiving module is used to receive the original design results from the software developer. The original design results include a topology graph constructed based on the assigned design tasks, with software element entities as nodes and the relationships between software element entities as edges. The software element entities include user entities, business scenario entities, functional service entities, data element entities, and smart hardware entities. The external design merging module is used to merge the software element entities and the relationships between them in the original design results of various software developers, and obtain the software collaborative design results.

13. An electronic device, characterized in that, It includes a processor and a memory storing program instructions, the processor being configured to execute the software platform co-design method as described in any one of claims 1 to 11 when executing the program instructions.

14. A computer-readable medium, characterized in that, It stores computer-readable instructions that are executed by a processor to implement a software platform co-design method as described in any one of claims 1 to 11.

Images