Object-process relationship modeling method, device, terminal and medium

Abstract

The present invention provides a modeling method, device, terminal and medium for object-process relationships, including: responding to a modeling operation for a requirement to be modeled, determining a simulation model corresponding to the requirement to be modeled based on type elements, process elements and relationship elements, the simulation model being used to express the requirement to be modeled using target type elements and their corresponding type definitions, design views, target process elements and their corresponding process definitions, design views and target relationship elements; responding to a scenario definition operation for the simulation model, determining a scenario corresponding to the simulation model, the scenario being used to describe the process control or test case of the simulation model; determining deduction configuration parameters corresponding to the simulation model, and using the scenario as an entry point, deducing the simulation model based on the deduction configuration parameters to obtain a deduction result corresponding to the requirement to be modeled. The present invention can effectively alleviate the limitations of the existing technology and can describe a richer range of requirements.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a method, device, terminal and medium for modeling object-process relationships. Background Art

[0002] Currently, existing modeling methods primarily utilize languages ​​such as SysML. SysML is a general-purpose graphical modeling language designed for use in systems engineering to support requirements analysis, architecture definition, behavioral modeling, and verification. However, this language has limitations, such as complex logic or inability to describe requirements. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a method, device, terminal and medium for modeling object-process relationships, which can effectively alleviate the limitations of the existing technology and can describe richer needs.

[0004] In a first aspect, the present invention provides a method for modeling object-process relationships. The method is applied to a terminal, wherein the terminal is configured with type elements, process elements, and relationship elements. The terminal displays the type elements, process elements, and relationship elements through a graphical user interface. The method includes:

[0005] In response to a modeling operation for the requirement to be modeled, a simulation model corresponding to the requirement to be modeled is determined based on the type elements, process elements, and relationship elements, the simulation model being used to express the requirement to be modeled using the target type elements and their corresponding type definition views and type design views, the target process elements and their corresponding process definition views and process design views, and the target relationship elements;

[0006] In response to a scenario definition operation for a simulation model, a scenario corresponding to the simulation model is determined, where the scenario is used to describe a process control or test case of the simulation model;

[0007] Determine the deduction configuration parameters corresponding to the simulation model, and use the scenario as the entry point to deduce the simulation model based on the deduction configuration parameters to obtain the deduction results corresponding to the requirements to be modeled.

[0008] In a second aspect, the present invention further provides an object-process relationship modeling device, which is applied to a terminal, the terminal being configured with type elements, process elements, and relationship elements, and the terminal displaying the type elements, process elements, and relationship elements via a graphical user interface, the device comprising:

[0009] A modeling module is used to respond to modeling operations for the requirements to be modeled, determine a simulation model corresponding to the requirements to be modeled based on type elements, process elements, and relationship elements, and the simulation model is used to express the requirements to be modeled using target type elements and their corresponding type definition views and type design views, target process elements and their corresponding process definition views and process design views, and target relationship elements;

[0010] A scenario definition module is used to respond to a scenario definition operation for a simulation model and determine a scenario corresponding to the simulation model. The scenario is used to describe the process control or test case of the simulation model.

[0011] The model deduction module is used to determine the deduction configuration parameters corresponding to the simulation model, and use the scenario as the entry to deduce the simulation model based on the deduction configuration parameters to obtain the deduction results corresponding to the modeling requirements.

[0012] In a third aspect, the present invention further provides a terminal comprising a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement any one of the methods provided in the first aspect.

[0013] In a fourth aspect, the present invention further provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to implement any one of the methods provided in the first aspect.

[0014] The present invention provides a modeling method, device, terminal and medium for object-process relationships, which are pre-configured with type elements, process elements and relationship elements. First, in response to a modeling operation for a requirement to be modeled, a simulation model corresponding to the requirement to be modeled is determined based on the type elements, process elements and relationship elements. The simulation model is used to express the requirement to be modeled using target type elements and their corresponding type definition views and type design views, target process elements and their corresponding process definition views and process design views, and target relationship elements. Then, in response to a scenario definition operation for the simulation model, a scenario corresponding to the simulation model is determined. The scenario is used to describe the process control or test case of the simulation model. Finally, the deduction configuration parameters corresponding to the simulation model are determined, and the scenario is used as an entry to deduce the simulation model based on the deduction configuration parameters to obtain a deduction result corresponding to the requirement to be modeled. The above method abstracts the requirements to be modeled into types, processes and relationships. The type is the expression of the object, that is, the simulation model corresponding to the requirements to be modeled is constructed based on the object-process relationship. On this basis, the scenarios and deduction configuration parameters corresponding to the simulation model are defined, and finally the deduction results corresponding to the requirements to be modeled are obtained through model deduction. The present invention has the advantages of being more concise and having fewer elements. At the same time, it can effectively alleviate the limitations of the existing technology and can describe richer requirements.

[0015] Other features and advantages of the present invention will be described in the following description, and in part will become apparent from the description, or understood by practicing the present invention. The purposes and other advantages of the present invention are realized and obtained by the structures particularly pointed out in the description, claims and drawings.

[0016] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1 A flowchart of a method for modeling object-process relationships provided by an embodiment of the present invention;

[0019] Figure 2 A schematic diagram of the objectivity, relevance, and development of a thing provided by an embodiment of the present invention;

[0020] Figure 3 A schematic diagram of an interface of a defined type provided by an embodiment of the present invention;

[0021] Figure 4 A schematic diagram of an interface after defining a type element according to an embodiment of the present invention;

[0022] Figure 5 A schematic diagram of another interface after defining a type element according to an embodiment of the present invention;

[0023] Figure 6 A schematic diagram of an interface of a type of design view provided by an embodiment of the present invention;

[0024] Figure 7 A schematic diagram of a definition view of a type of "pillar" provided in an embodiment of the present invention;

[0025] Figure 8 A view of a design view of a type of "pillar" provided for an embodiment of the present invention;

[0026] Figure 9 A schematic diagram of a definition view of a process "adding a plate on top" provided in an embodiment of the present invention;

[0027] Figure 10 A schematic diagram of a design view of a process of "adding a plate on top" provided in an embodiment of the present invention;

[0028] Figure 11 A schematic diagram of a definition view of a process "removing a plate from the top" provided in an embodiment of the present invention;

[0029] Figure 12 A schematic diagram of a design view of a process of "removing a plate from the top" provided in an embodiment of the present invention;

[0030] Figure 13 A schematic diagram of a definition view of a type of "Tower of Hanoi" provided by an embodiment of the present invention;

[0031] Figure 14 A schematic diagram of a design view of a type of "Tower of Hanoi" provided in an embodiment of the present invention;

[0032] Figure 15 A schematic diagram of a definition view of an "initialization" process provided in an embodiment of the present invention;

[0033] Figure 16 A schematic diagram of a design view of an "initialization" process provided by an embodiment of the present invention;

[0034] Figure 17 A schematic diagram of a definition view of a sub-process "create a plate" provided in an embodiment of the present invention;

[0035] Figure 18 A schematic diagram of a design view of a sub-process "creating a plate" provided in an embodiment of the present invention;

[0036] Figure 19 A schematic diagram of a definition view of a sub-process "temporary process 2" provided in an embodiment of the present invention;

[0037] Figure 20 A schematic diagram of a definition view of a process "moving a plate" provided in an embodiment of the present invention;

[0038] Figure 21 A schematic diagram of a design view of a process "moving a plate" provided in an embodiment of the present invention;

[0039] Figure 22 A schematic diagram of a definition view of a process "move" provided in an embodiment of the present invention;

[0040] Figure 23 A schematic diagram of a view involved in a process "moving" provided by an embodiment of the present invention;

[0041] Figure 24A schematic diagram of another process "movement" involving views provided by an embodiment of the present invention;

[0042] Figure 25 A schematic diagram of a definition view of a sub-process "calculate the number of new plates" provided in an embodiment of the present invention;

[0043] Figure 26 A schematic diagram of a design view of a sub-process "calculating the number of new plates" provided in an embodiment of the present invention;

[0044] Figure 27 A design view of a scenario provided by an embodiment of the present invention;

[0045] Figure 28 A schematic diagram of an "end" process provided by an embodiment of the present invention;

[0046] Figure 29 A schematic diagram of an interface for a hypothetical configuration provided by an embodiment of the present invention;

[0047] Figure 30 A schematic diagram of an interface for a scenario production provided by an embodiment of the present invention;

[0048] Figure 31 A schematic structural diagram of an object-process relationship modeling device provided by an embodiment of the present invention;

[0049] Figure 32 A schematic diagram of the structure of a terminal provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0050] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0051] At present, based on the existing technical solutions, from an objective perspective, it is found that the existing technology has the following three problems and shortcomings: (1) There are many types of existing modeling methods, and the modeling methods are complex; (2) There are many types of graphic elements of each type in the existing modeling technology, which is difficult for users to use; (3) The existing modeling methods do not support logical modeling or arithmetic modeling. Based on this, the present invention provides a modeling method, device, terminal and medium for object-process relationships, which has the advantages of being more concise and having a small number of elements. At the same time, it can effectively alleviate the limitations of the existing technology and can describe more diverse needs.

[0052] To facilitate understanding of this embodiment, a method for modeling an object-process relationship disclosed in an embodiment of the present invention is first described in detail. The method is applied to a terminal, which is configured with type elements, process elements, and relationship elements. The terminal displays the type elements, process elements, and relationship elements through a graphical user interface. Figure 1 The flowchart of a method for modeling an object-process relationship is shown, and the method mainly includes the following steps S102 to S106:

[0053] Step S102 : In response to a modeling operation for the requirement to be modeled, a simulation model corresponding to the requirement to be modeled is determined based on type elements, process elements, and relationship elements.

[0054] Among them, the simulation model is used to express the requirements to be modeled by using target type elements and their corresponding type definition views and type design views, target process elements and their corresponding process definition views and process design views, and target relationship elements. The type definition views of target type elements are used to express the members of the requirements to be modeled, the process definition views of target process elements are used to express the behaviors of target type elements, and target relationship elements are used to describe the type relationships between target type elements, the process relationships between target process elements, and the type-process relationships between target type elements and target process elements. The type design view is a view that describes the internal structure of the target type element through type relationships and type-process relationships. The process design view is a view that describes the operation control logic between sub-processes contained in the target process element through process relationships.

[0055] In one example, type elements, process elements, and relationship elements can be displayed through a graphical user interface. Type elements are usually used to express objects in modeling tools, that is, type elements are the carriers of objects. The embodiment of the present invention performs modeling based on the object-process relationship set, specifically: responding to the modeler's definition operations for type elements, definition operations for process elements, definition operations for relationship elements, implementation operations for type elements, and implementation operations for process elements to construct a simulation model corresponding to the requirements to be modeled. The simulation model is executable, and the executable simulation model can be in code form or in graphic form.

[0056] Step S104 : In response to the scenario definition operation for the simulation model, a scenario corresponding to the simulation model is determined.

[0057] Scenarios are used to describe the process control or test cases of a simulation model. In other words, a scenario can be viewed as a process control or a test case. In one example, a scenario can be generated in response to a modeler's scenario definition operations to perform process control or test cases on the simulation model.

[0058] Step S106: determine the deduction configuration parameters corresponding to the simulation model, and use the scenario as an entry point to deduce the simulation model based on the deduction configuration parameters to obtain a deduction result corresponding to the requirement to be modeled.

[0059] Among them, the deduction configuration parameters may include the name of the scenario, step accuracy, start time, stop condition, pause condition, deduction speed, initial attribute values ​​of the members to be modeled, etc. In one embodiment, the response modeler performs operations such as scenario configuration and scenario creation on the simulation model to obtain the deduction configuration parameters; the response modeler performs deduction on the simulation model based on the aforementioned scenarios and deduction configuration parameters in response to the deduction trigger operation of the simulation model. The deduction is based on the scenarios defined in the simulation model, the logic defined by the target type elements and target process elements used in the scenarios, starting from the initial attribute values ​​given by the scenario, and evolving and running step by step. Finally, the deduction is terminated when the stop condition is reached. The values ​​of each instance after the deduction is terminated, as well as the values ​​of its member attributes, are regarded as the deduction results.

[0060] The object-process relationship modeling method provided by the embodiment of the present invention abstracts the requirements to be modeled into types, processes and relationships. The type is the expression of the object, that is, a simulation model corresponding to the requirements to be modeled is constructed based on the object-process relationship. On this basis, the scenarios and deduction configuration parameters corresponding to the simulation model are defined, and finally the deduction results corresponding to the requirements to be modeled are obtained through model deduction. The present invention has the advantages of being more concise and having a small number of elements. At the same time, it can effectively alleviate the limitations of the existing technology and can describe richer requirements.

[0061] The embodiment of the present invention first explains the basic concept: the world is objective, interrelated and developing. Figure 2 The diagram shows the objectivity, association, and development of a thing. Objectivity is expressed by objects, which are used to carry observable and describable information about things. Association is expressed by relations, which are used to describe the associations between things, between things and processes, and between processes. Development is expressed by processes, which are used to describe the development and change, generation and extinction of things.

[0062] To facilitate understanding, an embodiment of the present invention provides a specific implementation of a method for modeling an object-process relationship.

[0063] Regarding the aforementioned step S102, an embodiment of the present invention provides a specific implementation method for responding to a modeling operation for a requirement to be modeled and determining a simulation model corresponding to the requirement to be modeled based on type elements, process elements, and relationship elements, as shown in steps 1 to 4 below:

[0064] Step 1: In response to an abstract operation for the requirement to be modeled, the requirement to be modeled is abstracted based on type elements, process elements, and relationship elements to determine the type definition view of the target type element, the process definition view of the target process element, and the target relationship element corresponding to the requirement to be modeled. This specifically includes the steps of defining the target type element, defining the target process element, and defining the target relationship element.

[0065] Step 1.1, define the target type element: The target type element is used to express the members of the requirement to be modeled. In this embodiment of the present invention, all descriptions of the requirement to be modeled are based on types, which are abstractions of the requirement to be modeled. Types can have members and attributes to express the characteristics of the type; types can also have procedures to express the behavior of the type.

[0066] In one embodiment, the process of defining a type is the process of clearly describing the members, attributes, and processes of the type. Figure 3 The diagram of a type definition interface shown in FIG can respond to the "add type" operation for the type control to obtain the initial type; continue to see Figure 4 The following is a diagram of the interface after defining a type element. The default type name is "Type 1". You can double-click the element in the figure below or click the pen icon to the right of "Type 1" in the type tree on the left to modify it to get the type definition view.

[0067] Step 1.2, define the target process elements: The target process elements are used to express the behavior of the target type elements. In an embodiment of the present invention, the behavior of the type is expressed through a process. The process can have parameters or not. Parameters are one of the media for the process to interact with the model world, and are one of the carriers for the process to affect or change object instances. The members and attributes of the type to which the process belongs can be used directly in the process, and these members and attributes are the only media and carriers for the process without parameters to interact with the model world. In one embodiment, the process of defining the process, that is, the process of clearly describing the relationship between the parameters of the process and the members and attributes of the type to which it belongs, ultimately obtains the definition view of the process.

[0068] Step 1.3, define target relationship elements: Target relationship elements are used to describe the type relationship between target type elements, the process relationship between target process elements, and the type-process relationship between target type elements and target process elements.

[0069] In one embodiment, structural relationships are required to define the members and attributes of a type; procedural relationships are required to define the parameters of a process; and procedural relationships are required to define the interaction between a process and an instance. For example, referring to the relationship summary table shown in Table 1 below, it is divided into structural relationships and procedural relationships. Structural relationships include composition relationships, representation relationships, inheritance relationships, attribution relationships, structural control relationships, one-way labeled relationships, two-way labeled relationships, etc. Procedural relationships include consumption relationships, generation relationships, input influence relationships, output influence relationships, two-way influence relationships, state transition relationships, state transition relationship pairs, dominant relationships, conditional relationships, call relationships, self-call relationships, timeout exception call relationships, insufficient time exception call relationships, etc.

[0070] Table 1 Relationship summary table

[0071]

[0072] Step 2, in response to the implementation operation for the target type element, determine the type design view corresponding to the target type element. The type design view is a view that describes the internal structure of the target type element through type relationships and type-process relationships. Among them, the definition view of the type details the relationship between the type and other types, including the source of the type, that is, the inheritance relationship. In an embodiment of the present invention, the implementation of the type corresponds to the design view of the type. The design view of the type details the relationship and mutual influence between the components (members, attributes and processes) of the type, including events, calls, parameter binding, etc. For example, after the instance "Zhang San" of the class "Human" is created, it needs to automatically start and continuously run its process "Growth", that is, the existence of the instance triggers the process "Growth", which is defined in the implementation view of the type.

[0073] In one embodiment, see Figure 5 Another interface diagram after defining the type element is shown. A "design view" control is displayed at the "type 1" control on the left. In response to a click operation on the "design view" control, the interface switches to the type design view, such as Figure 6 The interface diagram of a type of design view is shown in the figure. Figure 6 In the toolbox pointed by the arrow, from top to bottom are the "Member m", "Property a", "Procedure", "Constant c" and "Remarks" controls. Respond to the editing operations on the above controls to obtain the type design view.

[0074] In the specific implementation, first respond to the creation operation of the first-level type element for the requirement to be modeled, determine the members and processes contained in the first-level type element, for each member in the first-level type element, the member can be used as a second-level type element, determine the members and processes contained in the second-level type element, and repeat this process until the composition and behavior of the requirement to be modeled are clearly described using multi-level element types.

[0075] Step 3: In response to the implementation operation for the target process element, determine the process design view corresponding to the target process element. The process design view is a view that describes the operation control logic between the sub-processes contained in the target process element through process relationships. In this embodiment of the present invention, a process is the definition of the behavior of a type, and the implementation of the process is a detailed description of the behavior of the type. The implementation of the process corresponds to the process design view. A process can have sub-processes, and sub-processes can come from four sources: 1) temporary sub-processes; 2) other processes of the same class; 3) pre-defined built-in processes of the system; and 4) processes belonging to these instances can be used through the temporary variables, parameters, members, and attributes of the process's class.

[0076] Furthermore, the operation control logic between the sub-processes is defined using appropriate program relationships, which can be specifically referred to in Table 1 above, and will not be further described in the embodiment of the present invention.

[0077] Furthermore, a sub-process can also have its own sub-process, which forms a tree structure that is gradually refined layer by layer, with simple and reasonable abstraction and encapsulation. It has both a clear global view and sufficient detailed views, and has the capabilities and characteristics of componentization and modularization.

[0078] Furthermore, in response to the anchor connection operation for the process design view, the parameters of the sub-process in the process design view are connected to the instance required by the sub-process, so that when the sub-process is used in the process design view, the anchor of the sub-process is displayed in the process design view, prompting the user to connect the instance for the sub-process. Taking the type "adder" as an example, the members include "addend 1", "addend 2" and "sum value", and the process includes "addition", then the process "addition" needs to be connected to the members "addend 1" and "addend 2". The parameters of the process are expressed as anchor points. In actual applications, if the sub-process has no parameters, the anchor point will not be displayed, but it is still used. The anchor point is used to be displayed in the scenario where the sub-process is used to remind the user that the sub-process needs to be connected to an instance.

[0079] Furthermore, in response to the additional binding operation for the process design view, the sub-process in the process design view is connected to the instance. The additional binding is to establish a relationship between the instance in the parent process design view and the sub-process. The source of the instance includes the class members / attributes, temporary members / constants defined in the parent process design view, parameters of the parent process, predefined internal object instances, etc. In one embodiment, in addition to the anchor binding, the instance can be additionally connected to the process through a relationship. In addition to maintaining the process definition function, the capability of the process is temporarily expanded. For example, for the type "data preprocessing", the member includes "data 1" and the process includes "preprocessing". Then, by connecting the member "data 1" and the process "preprocessing", the process "preprocessing" can be executed on the member "data 1". On this basis, if there is a new member "data 2", the process "preprocessing" can be executed on the member "data 2" by additionally connecting the member "data 2" and the process "preprocessing", thereby expanding the capability of the process "preprocessing".

[0080] Step 4: Based on the target type elements and their corresponding type design views, the target process elements and their corresponding process design views, a simulation model corresponding to the requirements to be modeled is obtained.

[0081] To facilitate understanding of steps 1 to 4, the present invention provides a specific application example of building a simulation model corresponding to the Tower of Hanoi, taking the simple Tower of Hanoi as an example. The example includes:

[0082] (1) Type definition and implementation: such as Figure 7 A schematic diagram of a definition view of one type of "column" is shown. Figure 7 The members of the schematic type include columns. Figure 8 A view of a design view of one type of "column" is shown, Figure 8 The diagram shows that the type design view includes members and procedures. m represents the member "plate list". The members are expressed as rectangular primitives. The member "plate" is explained as follows: in array form, the element type is an integer. In the embodiment of the present invention, one integer is used to represent one plate; the procedures are expressed as elliptical primitives. The procedures include "adding a plate on the top" and "removing a plate on the top".

[0083] (2) Process definition and implementation:

[0084] Such as Figure 9 A schematic diagram of a definition view of a process "adding a plate on top" is shown. Figure 9 The diagram shows the relationship between the member "Plate" and the procedure "Add a Plate on Top" in the definition design view. The member "Plate" is explained as follows: the P in the upper left corner represents the parameter, the name is "Plate", and the element type is an integer. Figure 10The diagram shows a design view of a process "adding a plate on top", wherein the process "adding an element at the end" is a predefined process of the array, that is, the process of the member "plate list". Figure 10 The meaning is: bind the instance passed as a parameter to the anchor point of the process "add elements to the tail".

[0085] Such as Figure 11 A schematic diagram of the definition view of a process "removing a plate from the top" is shown. Figure 11 The diagram shows the relationship between the member "plate" and the process "remove a plate from the top" in the definition design view. The relationship between the parameter and the process is a non-empty output influence relationship. Figure 12 The diagram shown is a design view of a procedure "remove a plate from the top", which uses the procedure "remove elements from the tail" of the member "plate list" and binds the parameter "plate" to the anchor point of the procedure "remove elements from the tail". This is a non-empty output-affecting anchor point, and the removed element instance will be placed in the parameter "plate".

[0086] Furthermore, the embodiment of the present invention takes the complex Tower of Hanoi as an example and provides a specific application example of building a simulation model corresponding to the Tower of Hanoi. This includes:

[0087] (1) Type definition and implementation:

[0088] Such as Figure 13 The diagram shows a definition view of a type "Tower of Hanoi". The type "Tower of Hanoi" has no inheritance relationship.

[0089] Such as Figure 14 The diagram shows a design view of a "Tower of Hanoi" game type, comprising four members: a "number of plates," a "source pillar," an "auxiliary pillar," and a "target pillar." The "number of plates" member represents the number of stages in the Tower of Hanoi and is of type integer. The "source pillar," "auxiliary pillar," and "target pillar" members represent the three pillars in the Tower of Hanoi game, all of type "pillar." Each member has a "plate list" member and procedures for "adding a plate to the top" and "removing a plate from the top." The diagram also includes three procedures: "initialize," "move," and "move a plate." The "initialize" procedure initializes the Tower of Hanoi game; the "move" procedure moves all the plates from the source pillar to the target pillar; and the "move a plate" procedure is a special move that moves a plate from the top of the source pillar to the target pillar.

[0090] (2) Process definition and implementation:

[0091] Such as Figure 15The diagram of the definition view of a process "initialization" is shown in FIG. The relationship between the parameter number of disks and the process "initialization" is a non-empty influence input relationship. Figure 16 The schematic diagram of the design view of a process "Initialization" includes a member "Number of Plates", a member "Quantity of Plates", a member "Index", and a member "Source Column". Figure 16 This example also illustrates the use of a system-wide built-in procedure, assigning b = a; comparing c = a > b; and decrementing a -. It also uses the "Add a Plate on Top" procedure of the "Source Column" member; and the "Create a Plate" and "Temporary Procedure 2" subprocedures defined within this procedure. This loop is clearly intended to add the parameter "Number of Plates" to the "Source Column" member, with large plates at the bottom and small plates at the top. The plates on the source column are arranged in descending order, with the largest plate equal to the number of plates, and the smallest plate being 1.

[0092] The embodiment of the present invention further explains the temporary process: its scope of action is within the parent process and is invisible to the outside. The embodiment of the present invention involves two temporary processes: the sub-process "Create a Plate" and the sub-process "Temporary Process 2".

[0093] For a sub-procedure "create a plate", such as Figure 17 The diagram of the definition view of a sub-process "Create a Plate" is shown, involving two parameters: "Plate Size" and "Plate", which will create a "Plate" based on the input parameter "Plate Size" and put it into the output parameter "Plate". Figure 18 The following diagram shows a design view for a sub-procedure called "Create a Plate." The execution flow begins with sub-procedure "Temporary Procedure 1," creates an instance of "Plate," inserts the parameter "Plate," and then calls the built-in system procedure "Assign b = a" to assign the value of the parameter "Plate Size." Sub-procedure "Temporary Procedure 1" in the diagram lacks a specific definition view or design view, or rather, its definition view and design view are empty. This is because it lacks specific logic and simply executes a "result" relationship, generating a "Plate" instance. Therefore, it is an empty procedure.

[0094] For the sub-process "temporary process 2", the sub-process only has a definition view, or the design view is empty, such as Figure 19 The diagram shows a definition view of a sub-process "temporary process 2". The sub-process "temporary process 2" does not have any parameters, but has Java code. The meaning of the Java code is: using addProblem in the process API to output the string "initialization completed".

[0095] Such as Figure 20The diagram of the definition view of a process "Move a Plate" is shown, which involves two parameters: "Source Pillar" and "Target Pillar", and the relationship between the two parameters and the process is a non-empty bidirectional influence relationship. Figure 21 The diagram shows a design view of a process "moving a plate". After the process "moving a plate from the top" is completed, the process "adding a plate to the top" is called. Figure 21 It shows that starting from the process "remove a plate on the top" with the parameter "source column", its output parameter is bound to the input parameter of the process "add a plate on the top" with the parameter "target column". This is the direct transfer of parameters because no temporary variables are defined in the middle.

[0096] Such as Figure 22 The diagram shows a definition view of a process called "Move", which involves four parameters: parameter "number of plates", parameter "source pillar", parameter "auxiliary pillar", and parameter "target pillar". The parameter "number of plates" represents the number of Towers of Hanoi (or small Towers of Hanoi formed in the process) to be moved. Note that the process of moving Towers of Hanoi is a recursive nested process, so the Tower of Hanoi faced each time the process "Move" is executed may be different; the parameters "source pillar", "auxiliary pillar", and "target pillar" represent the source pillar, auxiliary pillar, and target pillar of this move, respectively.

[0097] Such as Figure 23 A process of "moving" is shown in the diagram of the diagram and Figure 24 Another process "moving" involves a schematic diagram of the view, Figure 23 and Figure 24 The diagrams show the operation control logic between each sub-process in the process of "moving". Figure 23 The node where the process starts is indicated, and it is noted that the process "Move" uses itself, indicating that the process "Move" is a recursive nested process. It should be noted that the meanings of the parameters "Source Pillar", "Auxiliary Pillar", and "Target Pillar" will change when bound to different processes. For example, when bound to the nested self, the role will be switched. Figure 24 It shows that the parameter "target column" is bound to the anchor point "auxiliary column" of the process "move".

[0098] Furthermore, the process "Move" also involves a temporary sub-process "Calculate new number of plates", such as Figure 25 A schematic diagram of a definition view of a sub-process "calculate the number of new plates" is shown and Figure 26 A schematic diagram of a design view of the sub-process "Calculate the number of new plates" is shown.

[0099] Regarding the aforementioned step S104, an embodiment of the present invention provides an implementation method for determining a scenario corresponding to the simulation model in response to a scenario definition operation for the simulation model. In one example, a scenario can be understood as a type, and the scenario uses target type elements defined in the simulation model to express the modeler's intention.

[0100] Continuing with the aforementioned complex Tower of Hanoi example, see Figure 27 A design view of a scenario is shown, Figure 27 It indicates that the scene contains scene members "Tower of Hanoi" and "Number of Plates". Specifically, Figure 27 Indicates the starting node of the process. At this node, the creation of the member "Tower of Hanoi" triggers the process "Initialize", and the Tower of Hanoi is initialized to level 3. After the initialization is completed, the process "Move" of the Tower of Hanoi is called to bind the members of the Tower of Hanoi, "Number of Plates", "Source Pillar", "Auxiliary Pillar", and "Target Pillar" to their corresponding parameters. After the move is completed, the process "End" is called, which is the process called in the scene. Figure 28 The diagram shows a process "end". The definition view and design view of the process "end" are both empty, but there is Java code. The meaning of the code is to use addProblem in the process API to output a problem string: move end.

[0101] To sum up, the entire process of model drawing is to define the type, the members of the type, the process of the type, the definition of the process, the implementation of the process, the definition and use of the sub-process, the process of the scenario, the use of various elements in the process, the binding of anchor points (parameters) and instances when the process is used, and the writing of process code (such as JAVA, Python, etc.).

[0102] Regarding the aforementioned step S106, an embodiment of the present invention further provides an implementation method for determining deduction configuration parameters corresponding to the simulation model, and using the scenario as an entry point, deducing the simulation model based on the deduction configuration parameters to obtain a deduction result corresponding to the demand to be modeled, including the following steps a to b:

[0103] Step a, in response to the configuration operation for the simulation model, determines the deduction configuration parameters corresponding to the simulation model, the deduction configuration parameters at least including step accuracy, start time, stop condition, deduction speed, and initial attribute values ​​of the members to be modeled.

[0104] In the specific implementation, it is divided into two steps: scenario configuration and scenario production.

[0105] See also Figure 29The following diagram shows a scenario configuration interface. Scenario configuration involves creating a scenario configuration using a pre-built model. This includes the configuration name, the model to be used, the scenario scenario, the scenario method (default form scenario), the scenario method, and the data source for the members and attributes that appear in the scenario.

[0106] See also Figure 30 The diagram shows an interface diagram for scenario creation. Scenario creation includes configuring various data based on scenario configuration, including scenario name, step accuracy, start time, stop condition, pause condition, speed, and values ​​of member attributes that need to be initialized in the scenario configuration.

[0107] Step b, responding to the deduction trigger operation for the simulation model, taking the scene as the entry, based on the step accuracy, start time, deduction speed and the initial attribute values ​​of the members of the modeling requirements, the simulation model is deduced by the event-driven method, and the deduction of the simulation model is stopped when the stop condition is met, and the deduction result corresponding to the modeling requirements is obtained.

[0108] The deduction process is based on the scenarios defined in the model, the classes used in the scenarios, and the logic defined by the processes. Starting from a given initial attribute value, the deduction process evolves and runs step by step, terminating when the stopping condition is reached. The values ​​of each instance and its member attributes after the deduction stops are considered the deduction results. During the deduction process, the values ​​of each instance and its member attributes before and after each step are the step-by-step snapshots of the deduction.

[0109] Among them, events include one or more of existence trigger, value change trigger, extinction trigger, state acquisition trigger and state loss trigger. Existence trigger is triggered when an instance of a specified target type element is generated. Value change trigger is triggered when the value of an instance generated by a specified target type element changes. Extinction trigger is triggered when an instance generated by a specified target type element disappears. State acquisition trigger is triggered when an instance generated by a specified target type element obtains a state. State loss trigger is triggered when an instance generated by a specified target type element loses a state. A summary table of program relationships and events, such as the one shown in Table 2, is provided below:

[0110] Table 2 Summary of program relationships and event combinations

[0111]

[0112] For example, the class definition describes that after an instance "Zhang San" of the type "Human" is created, its "growth" process needs to be automatically started and continuously executed. In other words, the existence of the instance triggers the "growth" process. This mechanism is called event-driven. Events are supported not only in the class design view but also in the process definition view. Model deduction does not run according to a predefined process, but is driven by events. The definition of types and scenarios is merely the definition of rules. Within these rules, the direction of the deduction process is determined by events. Event-driven systems enable the system to support both models and model deductions with clear processes and models and model deductions with ambiguous processes. Without using events, deductions are based on a clear process. Using an event-driven mechanism allows deductions with ambiguous processes.

[0113] Furthermore, the deduction configuration parameters also include a pause condition. In an embodiment of the present invention, the above method further includes:

[0114] Step I: During the deduction of the simulation model, the deduction of the simulation model is suspended when the pause condition is met; or, in response to the deduction pause operation for the simulation model, the deduction of the simulation model is suspended. Step II: In response to the modification operation of the simulation model and the deduction configuration parameters, the modified simulation model and / or the modified deduction configuration parameters are obtained. Step III: In response to the deduction trigger operation for the simulation model, the simulation model is continued to be deduced based on the deduction configuration parameters within the scenario. In actual applications, if the pause condition is met during the deduction process, the deduction will also be suspended. In the pause state, it is convenient to modify the values ​​of each instance or instance member attribute, and a new pause condition can also be set. Of course, this can also be done when not paused / running. In addition, during the deduction process, the user can pause / stop the deduction through the monitoring interface by using the Pause / Stop Task button. Continue the deduction by using the Continue Run button. Push the Step Once / Step Multiple Times button to advance the deduction one / multiple steps forward.

[0115] Furthermore, the system can also respond to query operations on the simulation model, determine query results, and display the query results through a graphical user interface. The query results include information about the simulation model, detailed information about the simulation model deduction, and data generated during the simulation model deduction process. In one example, the deduction interface provides query access to deduction progress summary information, events, issues, messages, and other information. It also provides query access to various information such as class definition information and class process definition information in the deduction model. In another example, it provides query access to instance information of each class during the deduction process, as well as execution details of each instance process, including information about the process itself, information about the corresponding instances of process parameters, and information about sub-processes.

[0116] Furthermore, the deduction service provides a RESTful interface for the front-end interface / other services to actively query information and control the deduction.

[0117] Furthermore, the simulation service pushes simulation information in real time through webSocket and can accept commands to control the simulation.

[0118] In summary, the embodiments of the present invention have at least the following features:

[0119] 1. Simplicity: A single view and streamlined modeling primitives are used to comprehensively describe business operations in the systems engineering domain, reducing the learning curve. Modelers and readers do not require programming experience, but familiarity with object-oriented (OO) thinking will be helpful. 2. Layered: A layered approach supports users' systems thinking from a macro to micro perspective, focusing on key issues and refining solutions. 3. Readability: Natural language models can be generated that are equivalent to graphical language models, and vice versa, making the models understandable to business users and facilitating integration and use with LLM. 4. Completeness: Supports logical modeling, process modeling, and arithmetic modeling, providing comprehensive support for systems engineering modeling. 5. Runnability: Models can be built that can be simulated without requiring code, and natively include elements that support simulation. 6. Code-Extensibility: Code can be used to supplement description logic at any level, simplifying the model. 7. Componentization: Supports componentization to enable knowledge sharing, exchange, reuse, and protection. 8. Localization: Uses familiar terminology, minimizing the use of English and translated terminology. 9. Explicitness: All key information should be expressed explicitly, without implicit rules and logic.

[0120] Based on the above embodiment, the embodiment of the present invention provides a modeling device for object-process relationship, which is applied to a terminal. The terminal is configured with type elements, process elements and relationship elements. The terminal displays type elements, process elements and relationship elements through a graphical user interface. Figure 31 The structure diagram of a modeling device for object-process relationship shown in FIG. 1 mainly includes the following parts:

[0121] A modeling module 3102 is configured to respond to a modeling operation for a requirement to be modeled and determine a simulation model corresponding to the requirement to be modeled based on type elements, process elements, and relationship elements. The simulation model is configured to express the requirement to be modeled using target type elements and their corresponding type definition views and type design views, target process elements and their corresponding process definition views and process design views, and target relationship elements.

[0122] A scenario definition module 3104 is configured to respond to a scenario definition operation for a simulation model and determine a scenario corresponding to the simulation model, wherein the scenario is used to describe a process control or test case of the simulation model;

[0123] The model deduction module 3106 is used to determine the deduction configuration parameters corresponding to the simulation model, and use the scenario as the entry to deduce the simulation model based on the deduction configuration parameters to obtain the deduction results corresponding to the requirements to be modeled.

[0124] The object-process relationship modeling device provided by the embodiment of the present invention abstracts the requirements to be modeled into types, processes and relationships. The type is the expression of the object, that is, a simulation model corresponding to the requirements to be modeled is constructed based on the object-process relationship. On this basis, the scenarios and deduction configuration parameters corresponding to the simulation model are defined, and finally the deduction results corresponding to the requirements to be modeled are obtained through model deduction. The present invention has the advantages of being more concise and having a small number of elements. At the same time, it can effectively alleviate the limitations of the existing technology and can describe richer requirements.

[0125] The device provided in the embodiment of the present invention has the same implementation principle and technical effects as those in the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference can be made to the corresponding content in the aforementioned method embodiment.

[0126] An embodiment of the present invention provides a terminal. Specifically, the terminal includes a processor and a storage device. The storage device stores a computer program, and when the computer program is executed by the processor, it executes the method described in any one of the above embodiments.

[0127] Figure 32 A structural diagram of a terminal provided in an embodiment of the present invention is provided, wherein the terminal 100 includes: a processor 320, a memory 321, a bus 322 and a communication interface 323, wherein the processor 320, the communication interface 323 and the memory 321 are connected via the bus 322; the processor 320 is used to execute an executable module stored in the memory 321, such as a computer program.

[0128] The computer program product of the readable storage medium provided in the embodiment of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the method described in the previous method embodiment. The specific implementation can be referred to the previous method embodiment and will not be repeated here.

[0129] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the above-described embodiments within the technical scope disclosed by the present invention, or replace some of the technical features therein with equivalents. Such modifications, changes, or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A method for modeling object-process relationships, characterized in that: The method is applied to a terminal, the terminal being configured with type elements, process elements, and relationship elements, and the terminal displaying the type elements, the process elements, and the relationship elements through a graphical user interface, the method comprising: In response to a modeling operation for the requirement to be modeled, determining a simulation model corresponding to the requirement to be modeled based on the type element, the process element, and the relationship element, the simulation model being used to express the requirement to be modeled using a target type element and its corresponding type definition view and type design view, a target process element and its corresponding process definition view and process design view, and a target relationship element; In response to a scenario definition operation for the simulation model, determining a scenario corresponding to the simulation model, wherein the scenario is used to describe a process control or a test case of the simulation model; Determine deduction configuration parameters corresponding to the simulation model, and use the scenario as an entry point to deduce the simulation model based on the deduction configuration parameters to obtain a deduction result corresponding to the requirement to be modeled; In response to a modeling operation for a requirement to be modeled, determining a simulation model corresponding to the requirement to be modeled based on the type element, the process element, and the relationship element includes: In response to an abstract operation on the requirement to be modeled, the requirement to be modeled is abstracted based on the type element, the process element, and the relationship element to determine a type definition view of a target type element, a process definition view of a target process element, and a target relationship element corresponding to the requirement to be modeled; wherein the type definition view of the target type element is used to express members of the requirement to be modeled, the process definition view of the target process element is used to express behaviors of the target type element, and the target relationship element is used to describe type relationships between the target type elements, process relationships between the target process elements, and type-process relationships between the target type element and the target process element; In response to an implementation operation for the target type element, determining a type design view corresponding to the target type element, the type design view being a view that describes an internal structure of the target type element through the type relationship and the type-procedure relationship; In response to an implementation operation for the target process element, determining a process design view corresponding to the target process element, the process design view being a view that describes an operation control logic between sub-processes included in the target process element through the process relationship; Based on the target type element and its corresponding type definition view and type design view, the target process element and its corresponding process definition view and process design view, a simulation model corresponding to the requirement to be modeled is obtained.

2. The object-process relationship modeling method according to claim 1, characterized in that: The method further comprises: In response to an anchor connection operation on the process design view, connecting a parameter of a sub-process in the process design view with an instance required by the sub-process, so as to display an anchor of the sub-process in the process design view when the process design view uses the sub-process; And / or, in response to an additional binding operation on the process design view, connecting the sub-process and the instance in the process design view.

3. The object-process relationship modeling method according to claim 1, characterized in that: Determining the deduction configuration parameters corresponding to the simulation model, and using the scenario as an entry, deducing the simulation model based on the deduction configuration parameters to obtain a deduction result corresponding to the requirement to be modeled, including: In response to a configuration operation for the simulation model, determining deduction configuration parameters corresponding to the simulation model, the deduction configuration parameters including at least step accuracy, start time, stop condition, deduction speed, and initial attribute values ​​of the member of the requirement to be modeled; In response to a deduction trigger operation for the simulation model, with the scenario as the entry, the simulation model is deduced by an event-driven method based on the step accuracy, the start time, the deduction speed and the initial attribute values ​​of the members of the requirements to be modeled, and the deduction of the simulation model is stopped when the stop condition is met, thereby obtaining a deduction result corresponding to the requirements to be modeled.

4. The object-process relationship modeling method according to claim 3, characterized in that: The event includes one or more of an existence trigger, a value change trigger, an extinction trigger, a state acquisition trigger, and a state loss trigger; The existence trigger is triggered when an instance of the specified target type element is generated; The value change trigger is triggered when the value of the instance generated for the specified target type element changes; The extinction trigger is triggered when the instance generated by the specified target type element dies; The state acquisition trigger is triggered when the instance generated by the specified target type element obtains the state; The state loss trigger is triggered when the instance generated by the specified target type element loses its state.

5. The object-process relationship modeling method according to claim 3, characterized in that: The deduction configuration parameters further include a pause condition, and the method further includes: During the deduction of the simulation model, pausing the deduction of the simulation model when the suspension condition is met; or pausing the deduction of the simulation model in response to a deduction suspension operation for the simulation model; In response to a modification operation on the simulation model or the deduction configuration parameter, obtaining a modified simulation model and / or the modified deduction configuration parameter; In response to the deduction trigger operation for the simulation model, continue to deduce the simulation model within the scenario based on the deduction configuration parameters.

6. The object-process relationship modeling method according to claim 3, characterized in that: The method further comprises: In response to a query operation on the simulation model, a query result is determined and displayed through the graphical user interface. The query result includes information about the simulation model, detailed information on the deduction of the simulation model, and data generated during the deduction of the simulation model.

7. A modeling device for object-process relationship, characterized in that: The device is applied to a terminal, the terminal is configured with type elements, process elements, and relationship elements, and the terminal displays the type elements, the process elements, and the relationship elements through a graphical user interface. The device includes: a modeling module, configured to respond to a modeling operation for a requirement to be modeled, and determine a simulation model corresponding to the requirement to be modeled based on the type element, the process element, and the relationship element, wherein the simulation model is configured to express the requirement to be modeled using a target type element and its corresponding type definition view and type design view, a target process element and its corresponding process definition view and process design view, and a target relationship element; A scenario definition module, configured to respond to a scenario definition operation for the simulation model and determine a scenario corresponding to the simulation model, wherein the scenario is used to describe a process control or test case of the simulation model; A model deduction module is used to determine deduction configuration parameters corresponding to the simulation model, and use the scenario as an entry to deduce the simulation model based on the deduction configuration parameters to obtain a deduction result corresponding to the requirement to be modeled; The modeling module is specifically used for: In response to an abstract operation on the requirement to be modeled, the requirement to be modeled is abstracted based on the type element, the process element, and the relationship element to determine a type definition view of a target type element, a process definition view of a target process element, and a target relationship element corresponding to the requirement to be modeled; wherein the type definition view of the target type element is used to express members of the requirement to be modeled, the process definition view of the target process element is used to express behaviors of the target type element, and the target relationship element is used to describe type relationships between the target type elements, process relationships between the target process elements, and type-process relationships between the target type element and the target process element; In response to an implementation operation for the target type element, determining a type design view corresponding to the target type element, the type design view being a view that describes an internal structure of the target type element through the type relationship and the type-procedure relationship; In response to an implementation operation for the target process element, determining a process design view corresponding to the target process element, the process design view being a view that describes an operation control logic between sub-processes included in the target process element through the process relationship; Based on the target type element and its corresponding type definition view and type design view, the target process element and its corresponding process definition view and process design view, a simulation model corresponding to the requirement to be modeled is obtained.

8. A terminal, characterized in that: The method comprises a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to implement the method according to any one of claims 1 to 6.

Images