Architecture drawing method and device, equipment and storage medium

Abstract

The disclosure provides an architecture diagram generation method, device, equipment and storage medium, which can be applied to the technical field of data processing. The method comprises the following steps: defining a basic element of an architecture diagram, wherein the basic element comprises a plurality of business sub-nodes; generating business path information, wherein the business path information records at least one business sub-node required to complete a business; generating business node subordinate information according to the subordinate relationship between all business sub-nodes; defining a constraint rule of the architecture diagram based on a preset architecture specification, the business path information and the business node subordinate information; and finding a plurality of business sub-nodes associated with to-be-generated business data from all business sub-nodes as a diagram element.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a method, apparatus, device, medium, and program product for creating an architecture diagram. Background Technology

[0002] Application architecture diagrams are a crucial means of expression in the process of formulating, communicating, exchanging, reviewing, and deciding on enterprise-level architecture solutions. For the IT system construction of medium to large enterprises, appropriate application architecture specifications and principles are typically formulated based on their own strategic goals, external regulatory compliance constraints, and industry standards. However, currently, architects often use PowerPoint to create wireframes or employ industry-standard UML modeling tools, all of which are manual and unstructured processes. The lack of a unified format for the diagrams increases the cost of communication and understanding. Furthermore, the architectural specifications and principles formulated by enterprises cannot be effectively implemented into the application architecture diagram creation process through standardized rules and conditions. Summary of the Invention

[0003] In view of the above problems, this disclosure provides methods, apparatus, devices, media and program products for creating architecture diagrams.

[0004] According to the first aspect of this disclosure, a method for generating an architecture diagram is provided, comprising: defining basic elements of the architecture diagram, the basic elements including multiple business sub-nodes; generating business path information, the business path information recording at least one business sub-node traversed to complete the business; generating business node dependency information based on the dependency relationships between all business sub-nodes; defining constraint rules for the architecture diagram based on preset architecture specifications, business path information, and business node dependency information; identifying multiple business sub-nodes associated with the business data to be generated from all business sub-nodes as generating elements; and constructing an architecture diagram conforming to the constraint rules based on the generating elements.

[0005] According to embodiments of this disclosure, the types of business sub-nodes include application architecture layered nodes, physical subsystem nodes, and business initiation nodes; business node dependency information includes a first dependency relationship and a second dependency relationship, the first dependency relationship recording the dependency information between at least one business initiation node and at least one physical subsystem node, and the second dependency relationship recording the dependency information between at least one physical subsystem node and a single application architecture layered node; business path information includes call relationship information between multiple business nodes and data exchange information between multiple business nodes, the business call relationship information recording at least one physical subsystem node called from the business initiation node to the physical subsystem node that completes the business and the order of traversal, and the data exchange information recording at least one business sub-node traversed and the order of traversal required for data exchange between one physical subsystem node and another physical subsystem node.

[0006] According to embodiments of this disclosure, the constraint rules include a first constraint rule, a second constraint rule, and a third constraint rule. Based on preset architecture specifications, business path information, and business node dependency information, the constraint rules defining the architecture diagram include: defining a first constraint rule based on preset architecture specifications and a first dependency relationship, the first constraint rule being used to constrain the association range between the business initiation node and the physical subsystem node; defining a second constraint rule based on preset architecture specifications and call relationship information, the second constraint rule being used to constrain the association range between multiple physical subsystems; and defining a third constraint rule based on preset architecture specifications, the second dependency relationship definition, and data exchange information, the third constraint rule being used to constrain the association range between physical subsystem nodes and application architecture layer nodes.

[0007] According to embodiments of this disclosure, the mapping element includes a first mapping element, a second mapping element, and a third mapping element. Finding multiple business sub-nodes associated with the business data to be mapped from all business sub-nodes as mapping elements includes: parsing the business data to be mapped to obtain business source information and business requirement information; finding at least one business starting node associated with the business source information as the first mapping element; finding at least one physical subsystem node used to complete the business function as the second mapping element based on the business requirement information; and finding at least one business sub-node called from the first mapping element to the second mapping element, and at least one business sub-node traversed for data exchange from the first mapping element to the second mapping element, based on call relationship information and data exchange information, as the third mapping element.

[0008] According to embodiments of this disclosure, the mapping element further includes a fourth mapping element. Finding multiple business sub-nodes associated with the business data to be mapped as mapping elements further includes: finding at least one physical subsystem node that satisfies a first subordinate relationship with the first mapping element as the fourth mapping element.

[0009] According to embodiments of this disclosure, the mapping element further includes a fifth mapping element, and the mapping element that obtains business data further includes: finding at least one business sub-node that satisfies a second subordinate relationship with the second mapping element and the third mapping element as the fifth mapping element.

[0010] According to embodiments of this disclosure, constructing an architecture diagram that conforms to constraint rules based on graph elements includes: removing business sub-nodes in the graph elements that do not meet the constraint rules, and using the remaining business sub-nodes as graph nodes; and constructing an architecture diagram based on the graph nodes according to business path information and business node subordinate information.

[0011] According to embodiments of this disclosure, constructing an architecture diagram from graph nodes based on business path information and hierarchical relationships includes: defining a standard description language that meets the architecture specification, wherein the type of standard description language includes JSON, YAML, and XML; and constructing an architecture diagram from graph nodes based on business path information and business node hierarchical information using the standard description language.

[0012] A second aspect of this disclosure provides an architecture diagram generation apparatus, comprising: a first definition module for defining basic elements of the architecture diagram, the basic elements including multiple business sub-nodes; a first generation module for generating business path information, the business path information recording at least one business sub-node traversed to complete the business; a second generation module for generating business node dependency information based on the dependency relationships between all business sub-nodes; a second definition module for defining constraint rules of the architecture diagram based on preset architecture specifications, business path information, and business node dependency information; a search module for searching out multiple business sub-nodes associated with the business data to be generated from all business sub-nodes as generation elements; and a construction module for constructing an architecture diagram conforming to the constraint rules based on the generation elements.

[0013] A third aspect of this disclosure provides an electronic device comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the methods described above.

[0014] A fourth aspect of this disclosure also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the methods described above.

[0015] The fifth aspect of this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0016] Based on the architecture diagram generation method, apparatus, device, medium, and program products provided in this disclosure, the basic elements of the architecture diagram are defined. These basic elements include multiple business sub-nodes. Standard constraint rules are defined according to the calling relationships and subordinate relationships between these business sub-nodes. Because detailed and accurate constraint rules are defined, the diagram elements and displayed content of the architecture diagram are restricted. Therefore, this at least partially solves the technical problem of the lack of a unified format for diagram generation and the inability to implement enterprise architecture specifications and principles into the application architecture diagram generation process through standard rules. This provides a unified basis for architecture diagram generation and reduces the cost of communication and understanding. Attached Figure Description

[0017] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 A flowchart illustrating an architecture diagram drawing method according to an embodiment of the present disclosure is shown schematically;

[0019] Figure 2 A schematic diagram illustrating the types of service sub-nodes according to embodiments of this disclosure is shown.

[0020] Figure 3 A flowchart illustrating the constraint rules of a defined architecture diagram according to an embodiment of this disclosure is shown schematically.

[0021] Figure 4 A constraint association range diagram according to an embodiment of the present disclosure is illustrated schematically;

[0022] Figure 5 A flowchart illustrating the process of finding a mapping element according to an embodiment of the present disclosure is shown schematically;

[0023] Figure 6 This schematically illustrates a flowchart of constructing an architecture diagram conforming to constraint rules based on graph elements according to an embodiment of the present disclosure;

[0024] Figure 7 An architecture diagram formed by an architecture diagram drawing method according to an embodiment of the present disclosure is illustrated schematically.

[0025] Figure 8 The schematic diagram illustrates an architecture diagram formed by an architecture diagram drawing method according to an embodiment of the present disclosure, wherein the drawing elements in the drawing method include a fourth drawing element;

[0026] Figure 9 The schematic diagram illustrates an architecture diagram formed by an architecture diagram drawing method according to an embodiment of the present disclosure, wherein the drawing elements in the drawing method include a fifth drawing element;

[0027] Figure 10 A schematic diagram illustrating a structural block diagram of an architecture drawing apparatus according to an embodiment of the present disclosure is shown; and

[0028] Figure 11 A block diagram schematically illustrates an electronic device suitable for implementing an architecture diagramming method according to an embodiment of the present disclosure. Detailed Implementation

[0029] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0030] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0031] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0032] When using expressions such as "at least one of A, B, and C", they should generally be interpreted in accordance with the meaning that is commonly understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B, and C, etc.).

[0033] In the technical solutions disclosed herein, the collection, storage, use, processing, transmission, provision, disclosure, and application of data (including but not limited to user personal information) comply with the provisions of relevant laws and regulations, necessary confidentiality measures have been taken, and they do not violate public order and good morals.

[0034] The embodiments of this disclosure provide an architecture diagram generation method, which can be set in a generation program in a smart device or server. The generation program is connected to the file system through a program interface and realizes data linkage with the file system.

[0035] Figure 1 A flowchart illustrating an architecture diagram drawing method according to an embodiment of the present disclosure is shown schematically. Figure 2 A schematic diagram of service sub-node types according to an embodiment of this disclosure is shown.

[0036] like Figure 1 As shown, the architecture diagram drawing method of this embodiment includes operations S110 to S160.

[0037] When operating S110, define the basic elements of the architecture diagram, which include multiple business sub-nodes.

[0038] like Figure 2 As shown, the types of business sub-nodes include business start node 1, physical subsystem node 2, and application architecture layer node 3.

[0039] Enterprise-level application architectures are typically quite complex and are usually deconstructed using a layered approach. Layering an application architecture involves dividing different components of an application into different layers based on their functions and responsibilities, thereby maintaining the flexibility, stability, and scalability of the application architecture.

[0040] Application architecture layer 3 may include a data layer, an application service layer, and a user interface layer. The user interface layer is the interface layer through which the application interacts with the user, including web pages, mobile applications, and desktop applications. This layer is responsible for handling user input and output and passing it to the next layer. The application service layer is the application's business logic and data access layer, responsible for handling business logic and interacting with data storage. This layer typically includes service interfaces and business logic components. The data layer is the application's data storage and management layer, responsible for managing and storing the data required by the application. This layer typically includes a database and data access components. It is understood that the layering method of the application architecture in this embodiment is only illustrative; different layering methods may be used in other embodiments.

[0041] After dividing the different components of the application into different layers according to their functions and responsibilities, the same layer is integrated into a node, which is represented in the architecture diagram as different application architecture layer nodes 3, such as application architecture layer node 31 corresponding to the data layer, application architecture layer node 32 corresponding to the application service layer, application architecture layer node 33 corresponding to the user interface layer, etc.

[0042] A physical subsystem is the smallest management unit from an enterprise application architecture management perspective; it is a software unit that can be deployed and run independently. A physical subsystem is typically composed of a set of related components and services, and can be independently deployed, scaled, and maintained. A physical subsystem can be a standalone application, or a module or subsystem of an application.

[0043] The physical subsystems can be, for example, user management subsystems, product management subsystems, order management subsystems, and payment management subsystems. The user management subsystem is responsible for user registration, login, and personal information management, and can be deployed and run independently. The product management subsystem is responsible for managing and displaying product information and can be deployed and run independently. The order management subsystem is responsible for order generation, payment, and delivery, and can be deployed and run independently. The payment management subsystem is responsible for implementing payment functions and can be deployed and run independently. It is understood that the physical subsystems in this embodiment are merely illustrative; other physical subsystems may be used in other embodiments.

[0044] Different physical subsystems are represented in the architecture diagram as different physical subsystem nodes 2, such as user management subsystem node 21, product management subsystem node 22, payment management subsystem node 23, order management subsystem node 24, etc.

[0045] A channel refers to the initiator of a service provided by a company, typically including various applications and devices. Channels can be broadly categorized into customer channels and employee channels. Customer channels refer to the ways a company provides services to its customers, while employee channels refer to the ways a company provides services to its employees. These channels interact and exchange data through physical subsystems in the enterprise application architecture diagram, thereby enabling the functionality of the entire banking system.

[0046] Channels can include, for example, mobile banking: customers can transfer funds, check balances, and perform other operations through mobile banking, which is a customer channel; internet banking: customers can conduct online banking services through internet banking, which is also a customer channel; ATMs: customers can withdraw cash, deposit money, and perform other operations through ATMs, which is also a customer channel; internal employee systems: employees can check salaries, apply for expense reimbursements, and perform other operations through internal employee systems, which is an employee channel; customer service systems: employees can provide services to customers through customer service systems, which is also an employee channel. Channels can also be divided according to function, such as, understandably, product category adjustment channels, product price adjustment channels, etc.; channels can also be divided in multiple composite ways. The channels in this embodiment are only illustrative; in other embodiments, there may also be channel types.

[0047] Different channels are represented in the architecture diagram as different business starting nodes 1, such as business starting node 11 for internet banking channels, business starting node 12 for product category adjustment channels, business starting node 13 for product price adjustment channels, etc.

[0048] Each business sub-node has its own node attributes. The attributes of the business starting node may include, for example, ID, name, type, etc.; the attributes of the application architecture layer node may include, for example, ID, type, name, type, description, etc.; the attributes of the physical subsystem node may include, ID, application architecture layer ID (REF), name, etc.

[0049] This embodiment defines in detail the specific meaning and attributes of each business sub-node as a diagramming element in the architecture diagram, so that the architecture diagram has a unified diagramming basis and reduces the cost of communication and understanding.

[0050] Continue to refer to Figure 1 In operation S120, business path information is generated, which records at least one business sub-node that needs to be traversed to complete the business.

[0051] According to embodiments of this disclosure, the business path information includes call relationship information between multiple business nodes and data exchange information between multiple business nodes. The business call relationship information records at least one physical subsystem node called from the business initiation node to the physical subsystem node that completes the business, and the order in which they pass through. For example, if the business content is that a user places an order for a wealth management product through an internet bank, the user needs to initiate a transaction request to the system through the internet bank channel (business initiation node 1), undergo user authentication through the user management subsystem (physical subsystem node 21), then undergo payment-related business through the payment management subsystem (physical subsystem node 23), and finally undergo order delivery through the order management subsystem (physical subsystem node 24). That is, for the transaction business from business initiation node 1 to physical subsystem node 24, the transaction line must pass through physical subsystem nodes 21 and 23, and the path order is: business initiation node 1 → physical subsystem node 21 → physical subsystem node 23 → physical subsystem node 24. The node path in this embodiment is only an example, and different node paths may exist in other embodiments.

[0052] According to embodiments of this disclosure, the data exchange information record records at least one business sub-node and its order of passage required for data exchange between one physical subsystem node and another. For example, the user management subsystem (physical subsystem node 21) belongs to the data layer (application architecture layer node 31) of the application architecture layer, while the payment management subsystem (physical subsystem node 23) and the order management subsystem (physical subsystem node 24) belong to the application service layer (application architecture layer node 32) of the application architecture layer. When the payment management subsystem and the order management subsystem need to synchronize user data, they must pass through the user management subsystem. The order of nodes and paths in this case is: physical subsystem node 23 → application architecture layer node 32 → application architecture layer node 31 → physical subsystem node 21 → application architecture layer node 31 → application architecture layer node 32 → physical subsystem node 24.

[0053] In operation S130, business node dependency information is generated based on the dependency relationships between all business sub-nodes.

[0054] The business node dependency information includes a first dependency relationship and a second dependency relationship. The first dependency relationship records the dependency information between at least one business starting node and at least one physical subsystem node. The second dependency relationship records the dependency information between at least one physical subsystem node and a single application architecture layer node.

[0055] For example, the product category adjustment channel (business start node 12) and the product price adjustment channel (business start node 13) belong to the product management subsystem (physical subsystem node 22), and this subordinate relationship is recorded in the first subordinate relationship. The product management subsystem (physical subsystem node 22) and the user management subsystem (physical subsystem node 21) belong to the data layer of the application architecture layer (application architecture layer node 31).

[0056] In operation S140, based on the preset architecture specifications, business path information, and business node dependency information, the constraint rules of the architecture diagram are defined.

[0057] In operation S150, multiple business sub-nodes associated with the business data to be mapped are identified from all business sub-nodes and used as mapping elements.

[0058] In operation S160, an architecture diagram conforming to the constraint rules is constructed based on the graph elements.

[0059] According to embodiments of this disclosure, standard constraint rules are defined based on the business path information of business sub-nodes and the hierarchical relationships between them. Because detailed and accurate constraint rules are defined, the elements and content displayed in the architecture diagram are restricted, resulting in a unified standard for architecture diagram creation. Furthermore, enterprise-customized architecture specifications can be changed and implemented in the diagram creation process at any time.

[0060] Figure 3 A flowchart illustrating the constraint rules of a defined architecture diagram according to an embodiment of this disclosure is shown schematically. Figure 4 A constraint association range diagram according to an embodiment of the present disclosure is illustrated schematically;

[0061] like Figure 3 As shown, operation S340 may include operations S310 to S330.

[0062] When operating S310, a first constraint rule is defined based on the preset architecture specifications and the first subordinate relationship. The first constraint rule is used to constrain the association range between the business starting node and the physical subsystem node.

[0063] According to embodiments of this disclosure, such as Figure 4 As shown on the left, business starting nodes 14, 15, and 16 are subordinate to physical subsystem node 21, and business starting nodes 14, 15, and 16 are subordinate to physical subsystem node 22. For example, if business starting node 14 is the administrator channel, and the preset architecture specification stipulates that the generated architecture diagram is geared towards ordinary users and ordinary employees, business starting node 14 is not within the selection range for the generated diagram. When a certain business, such as the user registration business, is initiated, although business starting node 15 is associated with the user registration business, if the generated architecture diagram is geared towards ordinary users and ordinary employees, such as... Figure 4 As shown on the right, the business initiation node 15 is not within the association range of physical subsystem node 21 and physical subsystem node 22.

[0064] Continue to refer to Figure 3 In operation S220, a second constraint rule is defined based on the preset architecture specifications and call relationship information. The second constraint rule is used to constrain the association range between multiple physical subsystems.

[0065] According to embodiments of this disclosure, such as Figure 4 As shown on the left, when a user makes a payment, the associated business sub-nodes are: physical subsystem node 21, physical subsystem node 22, and physical subsystem node 25. However, physical subsystem node 25 is a data filtering subsystem. When the default architecture specification stipulates that data filtering content does not need to be displayed in certain situations, such as... Figure 4As shown on the right, physical subsystem node 25 is not within the scope of the associated physical subsystem.

[0066] Continue to refer to Figure 3 In operation S230, a third constraint rule is defined based on the preset architecture specifications, the second subordinate relationship definition, and the data exchange information definition. The third constraint rule is used to constrain the association range between physical subsystem nodes and application architecture layer nodes.

[0067] According to embodiments of this disclosure, such as Figure 4 As shown on the left, physical subsystem nodes 21, 22, and 26 are all subordinate to application architecture layer node 31. However, physical subsystem 26 is a data monitoring and alarm subsystem. When the preset architecture specification stipulates that the architecture diagram does not need to display data monitoring-related content in certain situations, such as... Figure 4 As shown on the right, physical subsystem node 26 is not within the scope of association with application architecture layer node 31.

[0068] It is understandable that the above-mentioned "in certain circumstances" are conditions that can be pre-set by those skilled in the art based on the actual situation.

[0069] Figure 5 A flowchart illustrating the process of finding drawing elements according to an embodiment of the present disclosure is shown.

[0070] like Figure 5 As shown, operation S150 may include operations S510 to S540.

[0071] The mapping elements can include a first mapping element, a second mapping element, and a third mapping element.

[0072] When operating S510, the business data to be generated is parsed to obtain business source information and business requirement information.

[0073] The business data to be mapped can be manually filled in by personnel using the mapping method, or it can be automatically obtained from the system through a preset program. This disclosure does not impose any restrictions on this.

[0074] Using parsing tools or scripts, business source information and business requirement information are extracted from the business data to be mapped. If the business data is completed business data, the business source information records which channels initiated the business request. If the business data is predictive data for business content, the business source information records which channels the business can initiate the request from; for example, a user name change request can be initiated through the user's mobile app or employee channels. The business requirement information records what requirements the business needs to fulfill.

[0075] In operation S520, at least one business originating node associated with the business source information is identified as the first graph element. According to an embodiment of this disclosure, for example, when a user places an order for a certain financial product, they can do so themselves through an internet banking channel or entrust a bank employee to do so. Correspondingly, the system administrator also has the authority to do so. Therefore, the business originating nodes associated with "placing an order for a certain financial product" are business originating node 1 (corresponding to the internet banking user channel), business originating node 5 (corresponding to the system administrator channel), and business originating node 7 (corresponding to the employee operation channel). These three business originating nodes serve as the first graph element.

[0076] In operation S530, at least one physical subsystem node used to complete the business function is found as the second graph element based on the business requirement information. According to the embodiment of this disclosure, for example, when a user places an order for a certain financial product, the process involves payment, order placement, and product distribution. The physical subsystem nodes that complete the business function are physical subsystem node 23 (corresponding to the payment management subsystem), physical subsystem node 24 (corresponding to the order management subsystem), and physical subsystem node 22 (corresponding to the product management subsystem). These three physical subsystem nodes are used as the second graph element.

[0077] In operation S540, based on the call relationship information and data exchange information, at least one business sub-node called from the first mapping element to the second mapping element, and at least one business sub-node that needs to be passed through for data exchange from the first mapping element to the second mapping element are identified as the third mapping element.

[0078] According to an embodiment of this disclosure, for example, when a user places an order for a certain financial product, the process from business initiation node 1 to physical subsystem node 23 requires calling physical subsystem node 21 (corresponding to the user management subsystem), and from business initiation node 5 to physical subsystem node 23 requires calling physical subsystem node 27 (corresponding to the administrator subsystem). Data from physical subsystem node 21 to physical subsystem node 23 also needs to pass through physical subsystem node 28 (corresponding to the user authentication subsystem) of application architecture layer node 32 (corresponding to the security management layer). At this point, physical subsystem node 27, physical subsystem node 28, and application architecture layer node 32 form the third graph element.

[0079] Figure 6 The flowchart illustrating the construction of an architecture diagram conforming to constraint rules based on graph elements according to an embodiment of the present disclosure is shown in the schematic diagram.

[0080] like Figure 6 As shown, operation S160 may include operations S610 to S630.

[0081] In operation S610, business sub-nodes that do not meet the constraint rules are removed from the map elements, and the remaining business sub-nodes are used as map nodes.

[0082] When operating S620, a standard description language that conforms to the architecture specification is defined. The types of standard description languages ​​include JSON, YAML, and XML. It is understood that the above language types are merely examples, and those skilled in the art can choose an appropriate language as the standard description language based on the actual situation.

[0083] When operating S630, the nodes in the graph are constructed into an architecture graph using a standard description language based on business path information and business node dependency information.

[0084] According to the embodiments of this disclosure, the architecture diagram is constructed using a defined standard description language. The diagram can be generated using only a description language parsing tool, eliminating the need for manual creation. This improves the efficiency of diagram generation and facilitates the unification of diagram generation rules, enabling different personnel to construct enterprise-level architecture diagrams with a unified basic format and architecture.

[0085] The following is a detailed diagram illustrating the process of a user placing an order for a financial product, combined with the steps described above. It should be understood that this process is merely an example and does not limit the scope of this disclosure.

[0086] Figure 7 An architecture diagram formed by an architecture diagram drawing method according to an embodiment of the present disclosure is illustrated schematically.

[0087] According to embodiments of this disclosure, the preset architecture specifications include content related to data filtering, system administrators, and data monitoring and alarms not included in the architecture diagram. The user's business is placing an order for a certain financial product.

[0088] The business data is parsed to obtain the business source information. The business starting nodes that are related to the business source information are: business starting node 1 (corresponding to the Internet bank user channel), business starting node 5 (corresponding to the system administrator channel), and business starting node 7 (corresponding to the employee operation channel). Business starting nodes 1, 5, and 7 are used as the first graph elements.

[0089] The business sub-nodes that need to complete the relevant business functions to enable a user to place an order for a certain financial product are: physical subsystem node 23 (corresponding to the payment management subsystem), physical subsystem node 24 (corresponding to the order management subsystem), and physical subsystem node 22 (corresponding to the product management subsystem). Physical subsystem nodes 22, 23, and 24 are used as the second graph elements.

[0090] From the business initiation node 1 to the physical subsystem node 23, it is also necessary to call physical subsystem nodes 21 (corresponding to the user management subsystem), 25 (corresponding to the data filtering subsystem), and 26 (corresponding to the data monitoring and alarm subsystem). Data from physical subsystem node 21 to physical subsystem node 23 also needs to pass through physical subsystem node 28 (corresponding to the user authentication subsystem) of application architecture layer node 32 (corresponding to the security management layer). At this point, physical subsystem nodes 21, 25, 26, and 28, along with application architecture layer node 32, form the third graph element.

[0091] According to the pre-defined architecture specifications, the architecture diagram generated by this type of business does not display data filtering-related content, system administrator-related content, or data monitoring and alarm-related content. Therefore, business start node 5, physical subsystem node 25, and physical subsystem node 26 are excluded, and business start node 1, business start node 7, physical subsystem node 21, physical subsystem node 22, physical subsystem node 23, physical subsystem node 24, physical subsystem node 28, and application architecture layer node 32 are used as the diagram nodes.

[0092] The architecture diagram is defined using XML, and the diagramming tools use the XML parsing language to construct the above-mentioned diagram nodes as follows: Figure 7 The architecture diagram shown is understandable. Figure 7 The architecture diagrams in this document are for illustrative purposes only. Those skilled in the art can choose the specific style of the architecture diagram according to the actual situation, and this disclosure does not impose any restrictions on this.

[0093] Figure 8 The schematic diagram illustrates an architecture diagram formed by an architecture diagram drawing method according to an embodiment of the present disclosure, wherein the drawing elements in the drawing method include a fourth drawing element;

[0094] Following the operations S420 to S440 described above, operation S450 may also be included. The mapping element may also include a fourth mapping element.

[0095] In operation S450, at least one physical subsystem node that satisfies the first subordinate relationship with the first mapping element is identified as the fourth mapping element.

[0096] exist Figure 7 Based on the implementation example, since the business initiation node 1 and the physical subsystem 29 (corresponding to the application page operation subsystem) have a subordinate relationship, the physical subsystem 29 serves as the fourth mapping element. At this time, the fourth mapping element should also be constructed as one of the mapping elements according to the operation process of steps S510 to S530, as shown in the example. Figure 8 The architecture diagram shown.

[0097] Figure 9The schematic diagram illustrates an architecture diagram formed by an architecture diagram drawing method according to an embodiment of the present disclosure, wherein the drawing elements in the drawing method include a fifth drawing element;

[0098] Following the operations S420 to S440 described above, operation S460 may also be included. The mapping element may also include a fifth mapping element.

[0099] In operation S460, at least one business sub-node that satisfies the second subordinate relationship with the second and third mapping elements is identified as the fifth mapping element.

[0100] exist Figure 8 Based on the implementation example, physical subsystem nodes 21 and 22 are subordinate to application architecture layer node 31, and physical subsystem nodes 23 and 24 are subordinate to application architecture layer node 32 (corresponding to the application service layer in the application architecture layer). Therefore, application architecture layer node 31 and application architecture layer node 32 serve as the fifth graph element. At this time, the fifth graph element should also be constructed as one of the graph elements according to the operation process of steps S510 to S530, as shown in the example. Figure 9 The architecture diagram shown.

[0101] The architecture diagram generation method provided in this disclosure defines basic elements of the architecture diagram, including multiple business sub-nodes. Based on the calling relationships and dependency relationships between these business sub-nodes, standard constraint rules are defined. Because detailed and accurate constraint rules are defined, the diagram elements and displayed content of the architecture diagram are restricted. Therefore, this method at least partially solves the technical problem that the format for generating diagrams is not standardized, and that enterprise architecture specifications cannot be implemented in the application architecture diagram generation process through standard rules. This provides a unified basis for architecture diagram generation and reduces communication and understanding costs.

[0102] Based on the above-described architecture diagram generation method, this disclosure also provides an architecture diagram generation apparatus. The following will be combined with... Figure 10 The device is described in detail.

[0103] Figure 10 A schematic diagram of a schematic diagram plotting apparatus according to an embodiment of the present disclosure is shown.

[0104] As shown in the figure, the architecture diagram generating device 1000 of this embodiment includes a first definition module 1010, a first generation module 1020, a second generation module 1030, a second definition module 1040, a search module 1050, and a construction module 1060.

[0105] The first definition module 1010 is used to define the basic elements of the architecture diagram, which include multiple business sub-nodes. In one embodiment, the first definition module 1010 can be used to perform the operation S110 described above, which will not be repeated here.

[0106] The first generation module 1020 is used to generate business path information, which records at least one business sub-node that needs to be traversed to complete the business. In one embodiment, the first generation module 1020 can be used to perform the operation S120 described above, which will not be repeated here.

[0107] The second generation module 1030 is used to generate business node dependency information based on the dependency relationships between all business sub-nodes. In one embodiment, the second generation module 1030 can be used to perform the operation S130 described above, which will not be repeated here.

[0108] The second definition module 1040 is used to define the constraint rules of the architecture diagram based on preset architecture specifications, business path information, and business node dependency information. In one embodiment, the second definition module 1040 can be used to perform the operation S140 described above, which will not be repeated here.

[0109] The lookup module 1050 is used to find multiple business sub-nodes associated with the business data to be mapped from all business sub-nodes as mapping elements. In one embodiment, the lookup module 1050 can be used to perform the operation S150 described above, which will not be repeated here.

[0110] The construction module 1060 is used to construct an architecture diagram that conforms to the constraint rules based on the graph elements. In one embodiment, the construction module 1060 can be used to perform the operation S160 described above, which will not be repeated here.

[0111] According to embodiments of this disclosure, the second definition module 1040 may further include a first rule definition module, a second rule definition module, and a third rule definition module.

[0112] The first rule definition module is used to define first constraint rules based on preset architectural specifications and first subordinate relationships. The first constraint rules are used to constrain the association range between the business initiation node and the physical subsystem node. In one embodiment, the first rule definition module can be used to execute the operation S210 described above, which will not be repeated here.

[0113] The second rule definition module is used to define second constraint rules based on preset architecture specifications and call relationship information. These second constraint rules constrain the scope of association between multiple physical subsystems. In one embodiment, the second rule definition module can be used to execute the operation S220 described above, which will not be repeated here.

[0114] The third rule definition module is used to define third constraint rules based on preset architecture specifications, second dependency relationship definitions, and data exchange information. These third constraint rules constrain the association range between physical subsystem nodes and application architecture layer nodes. In one embodiment, the third rule definition module can be used to execute the operation S230 described above, which will not be repeated here.

[0115] According to embodiments of this disclosure, the search module 1050 may further include a parsing module, a first sub-search module, a second sub-search module, and a third sub-search module.

[0116] The parsing module is used to parse the business data to be generated into a graph to obtain business source information and business requirement information. In one embodiment, the parsing module can be used to perform the operation S410 described above, which will not be repeated here.

[0117] The first sub-search module is used to find at least one business starting node that is related to the business source information as the first graph element; in one embodiment, the first sub-search module can be used to perform the operation S420 described above, which will not be repeated here.

[0118] The second sub-search module is used to find at least one physical subsystem node used to complete the business function as the second graph element based on the business requirement information; in one embodiment, the second sub-search module can be used to perform the operation S430 described above, which will not be repeated here.

[0119] The third sub-search module is used to find at least one business sub-node called from the first mapping element to the second mapping element based on the call relationship information and data exchange information, and at least one business sub-node that needs to be passed through for data exchange from the first mapping element to the second mapping element as the third mapping element; in one embodiment, the third sub-search module can be used to perform the operation S440 described above, which will not be repeated here.

[0120] According to embodiments of this disclosure, any plurality of modules among the first definition module 1010, the first generation module 1020, the second generation module 1030, the second definition module 1040, the lookup module 1050, and the construction module 1060 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules can be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the first definition module 1010, the first generation module 1020, the second generation module 1030, the second definition module 1040, the lookup module 1050, and the construction module 1060 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of software, hardware, and firmware methods, or in a suitable combination of any of these methods. Alternatively, at least one of the first definition module 1010, the first generation module 1020, the second generation module 1030, the second definition module 1040, the search module 1050, and the construction module 1060 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0121] Figure 11 A block diagram schematically illustrates an electronic device suitable for implementing an architecture diagramming method according to an embodiment of the present disclosure.

[0122] like Figure 11 As shown, an electronic device 1100 according to an embodiment of the present disclosure includes a processor 1101, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1102 or a program loaded from a storage portion 1108 into a random access memory (RAM) 1103. The processor 1101 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1101 may also include onboard memory for caching purposes. The processor 1101 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0123] RAM 1103 stores various programs and data required for the operation of electronic device 1100. Processor 1101, ROM 1102, and RAM 1103 are interconnected via bus 1104. Processor 1101 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 1102 and / or RAM 1103. It should be noted that programs may also be stored in one or more memories other than ROM 1102 and RAM 1103. Processor 1101 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in one or more memories.

[0124] According to embodiments of this disclosure, the electronic device 1100 may further include an input / output (I / O) interface 1105, which is also connected to a bus 1104. The electronic device 1100 may also include one or more of the following components connected to the I / O interface 1105: an input section 1106 including a keyboard, mouse, etc.; an output section 1107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN card, modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the I / O interface 1105 as needed. A removable medium 1111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1110 as needed so that computer programs read from it can be installed into the storage section 1108 as needed.

[0125] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0126] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 1102 and / or RAM 1103 and / or one or more memories other than ROM 1102 and RAM 1103 described above.

[0127] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the item recommendation method provided in the embodiments of this disclosure.

[0128] When the computer program is executed by the processor 1101, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0129] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 1109, and / or installed from the removable medium 1111. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0130] In such an embodiment, the computer program can be downloaded and installed from a network via communication section 1109, and / or installed from removable medium 1111. When the computer program is executed by processor 1101, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0131] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0132] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0133] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0134] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A method for generating an architecture diagram, comprising: Define the basic elements of the architecture diagram, which include multiple business sub-nodes; Generate business path information, wherein the business path information records at least one of the business sub-nodes that need to be traversed to complete the business; Based on the hierarchical relationships between all the aforementioned business sub-nodes, generate business node hierarchical information; Based on the preset architecture specifications, the business path information, and the business node dependency information, define the constraint rules of the architecture diagram; From all the aforementioned business sub-nodes, identify multiple business sub-nodes that are associated with the business data to be mapped and use them as mapping elements; Construct an architecture diagram that conforms to the constraint rules based on the graph elements; The types of business sub-nodes include application architecture layered nodes, physical subsystem nodes, and business initiation nodes; The mapping elements include a first mapping element and a second mapping element. The step of finding multiple business sub-nodes associated with the business data to be mapped from all the business sub-nodes as mapping elements includes: The business data to be mapped is parsed to obtain business source information and business requirement information. If the business data to be mapped is completed business data, the business source information records which channels the business initiated the business request from. If the business data to be mapped is prediction data of business content, the business source information records which channels the business can initiate the business request from. The business requirement information records what requirements the business needs to fulfill. Find at least one of the business origin nodes that is associated with the business source information as the first graph element; Based on the business requirement information, at least one of the physical subsystem nodes used to complete the business function is selected as the second graph element.

2. The architecture diagram generation method according to claim 1, wherein, The business node dependency information includes a first dependency relationship and a second dependency relationship. The first dependency relationship records the dependency information of at least one business initiation node and at least one physical subsystem node. The second dependency relationship records the dependency information of at least one physical subsystem node and a single application architecture layer node. The business path information includes call relationship information between multiple business nodes and data exchange information between multiple business nodes. The business call relationship information records at least one physical subsystem node called from the business initiation node to the physical subsystem node that completes the business and the order in which they are passed. The data exchange information records at least one business sub-node that needs to be passed from one physical subsystem node to another and the order in which they are passed.

3. The architecture diagram generation method according to claim 2, wherein, The constraint rules include a first constraint rule, a second constraint rule, and a third constraint rule. The constraint rules defining the architecture diagram based on the preset architecture specifications, the business path information, and the business node dependency information include: The first constraint rule is defined based on the preset architecture specifications and the first subordinate relationship. The first constraint rule is used to constrain the association range between the business starting node and the physical subsystem node. The second constraint rule is defined based on the preset architecture specifications and the call relationship information. The second constraint rule is used to constrain the association range between the multiple physical subsystems. The third constraint rule is defined based on the preset architecture specifications, the second subordinate relationship definition, and the data exchange information. The third constraint rule is used to constrain the association range between the physical subsystem node and the application architecture layer node.

4. The architecture diagram generation method according to claim 2, wherein, The mapping element includes a third mapping element, and the step of finding multiple business sub-nodes associated with the business data to be mapped from all the business sub-nodes as mapping elements includes: Based on the call relationship information and the data exchange information, at least one of the business sub-nodes called from the first mapping element to the second mapping element, and at least one of the business sub-nodes that need to be passed through for data exchange from the first mapping element to the second mapping element are identified as the third mapping element.

5. The architecture diagram generation method according to claim 4, wherein, The mapping element also includes a fourth mapping element, and the step of finding multiple business sub-nodes associated with the business data to be mapped as mapping elements further includes: Find at least one of the physical subsystem nodes that satisfies the first dependency relationship with the first mapping element as the fourth mapping element.

6. The architecture diagram generation method according to claim 4, wherein, The mapping element further includes a fifth mapping element, and the mapping element for obtaining the business data further includes: Find at least one of the business sub-nodes that satisfies the second dependency relationship with the second and third mapping elements as the fifth mapping element.

7. The architecture diagram generation method according to claim 1, wherein, Constructing an architecture diagram that conforms to the constraint rules based on the graph elements includes: Remove the business sub-nodes in the generated map elements that do not meet the constraint rules, and use the remaining business sub-nodes as the generated map nodes; The architecture diagram is constructed by using the graph nodes according to the business path information and the business node affiliation information.

8. The method for generating an architecture diagram according to claim 7, wherein, Constructing the architecture diagram from the graph nodes according to the business path information and the business node dependency information includes: Define a standard description language that conforms to the architecture specification, wherein the type of the standard description language includes JSON, YAML, and XML. The graph is constructed from the nodes in the graph using the standard description language, based on the business path information and the business node dependency information.

9. An architecture diagram generating apparatus, comprising: The first definition module is used to define the basic elements of the architecture diagram, which include multiple business sub-nodes; The first generation module is used to generate business path information, wherein the business path information records at least one of the business sub-nodes that need to be traversed to complete the business. The second generation module is used to generate business node dependency information based on the dependency relationship between all the business sub-nodes; The second definition module defines the constraint rules of the architecture diagram based on the preset architecture specifications, the business path information, and the business node dependency information. The search module identifies multiple business sub-nodes that are associated with the business data to be mapped from all the business sub-nodes and uses them as mapping elements. as well as A construction module is used to construct an architecture diagram that conforms to the constraint rules based on the graph elements; The types of business sub-nodes include application architecture layered nodes, physical subsystem nodes, and business initiation nodes; The mapping elements include a first mapping element and a second mapping element. The step of finding multiple business sub-nodes associated with the business data to be mapped from all the business sub-nodes as mapping elements includes: The business data to be mapped is parsed to obtain business source information and business requirement information. If the business data to be mapped is completed business data, the business source information records which channels the business initiated the business request from. If the business data to be mapped is prediction data of business content, the business source information records which channels the business can initiate the business request from. The business requirement information records what requirements the business needs to fulfill. Find at least one of the business origin nodes that is associated with the business source information as the first graph element; Based on the business requirement information, at least one of the physical subsystem nodes used to complete the business function is selected as the second graph element.

10. An electronic device, comprising: One or more processors; Storage device for storing one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors perform the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 8.

12. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 8.

Images