Object process relationship modeling method and device, terminal and medium

Abstract

The invention provides an object process relation modeling method and device, a terminal and a medium, and the method comprises the steps: responding to a modeling operation for a to-be-modeled demand, determining a simulation model corresponding to the to-be-modeled demand based on a type element, a process element and a relation element, the simulation model is used for expressing a to-be-modeled demand by using a target type element and a corresponding type definition, a design view, a target process element and a corresponding process definition, a design view and a target relation element; in response to a scene definition operation for the simulation model, determining a scene corresponding to the simulation model, the scene being used for describing a process control or test case of the simulation model; and determining a deduction configuration parameter corresponding to the simulation model, and deducing the simulation model based on the deduction configuration parameter by taking the scene as an entrance to obtain a deduction result corresponding to the to-be-modeled demand. According to the method, the problem of limitation in the prior art can be effectively relieved, and richer requirements can be described.

Description

Technical Field

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

[0002] Currently, the existing modeling methods mainly model through languages such as SysML. SysML is a general graphical modeling language designed for systems engineering to support system requirements analysis, architecture definition, behavior modeling, verification, etc. However, this language has certain limitations, with complex logic or situations where it cannot describe requirements when describing requirements. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a method, apparatus, terminal and medium for modeling object-process relationships, which can effectively alleviate the problem of limitations in the existing technology and can describe more abundant requirements.

[0004] In the first aspect, the present invention provides a method for modeling object-process relationships. The method is applied to a terminal 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: Responding to a modeling operation for a to-be-modeled requirement, determining a simulation model corresponding to the to-be-modeled requirement based on the type elements, process elements, and relationship elements. The simulation model is used to express the to-be-modeled requirement 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; Responding to a scenario definition operation for the simulation model, determining a scenario corresponding to the simulation model. The scenario is used to describe the flow control or test cases of the simulation model; Determining the derivation configuration parameters corresponding to the simulation model, and taking the scenario as an entry point, deriving the simulation model based on the derivation configuration parameters to obtain a derivation result corresponding to the to-be-modeled requirement.

[0005] In the second aspect, the present invention further provides a modeling apparatus for object-process relationships. The apparatus is applied to a terminal 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 apparatus includes: A modeling module, configured to respond to a modeling operation for a to-be-modeled requirement, and determine a simulation model corresponding to the to-be-modeled requirement based on the type elements, process elements, and relationship elements. The simulation model is used to express the to-be-modeled requirement 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; A scenario definition module, configured to respond to a scenario definition operation for a simulation model, determine a scenario corresponding to the simulation model, where the scenario is used to describe the process control or test cases of the simulation model; A model deduction module, configured to 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 to-be-modeled requirement.

[0006] In a third aspect, the present invention further provides a terminal, including a processor and a memory, where 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 the first aspect.

[0007] In a fourth aspect, the present invention further provides a computer-readable storage medium, where the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are called and executed by a processor, the computer-executable instructions cause the processor to implement the method according to any one of the first aspect.

[0008] A method, apparatus, terminal, and medium for modeling an object-process relationship provided by the present invention are pre-configured with type elements, process elements, and relationship elements. First, in response to a modeling operation for a to-be-modeled requirement, a simulation model corresponding to the to-be-modeled requirement is determined based on the type elements, process elements, and relationship elements. The simulation model is used to express the to-be-modeled requirement 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. Then, in response to a scenario definition operation for the simulation model, a scenario corresponding to the simulation model is determined, where the scenario is used to describe the process control or test cases of the simulation model. Finally, deduction configuration parameters corresponding to the simulation model are determined, and the simulation model is deduced based on the deduction configuration parameters with the scenario as an entry point to obtain a deduction result corresponding to the to-be-modeled requirement. The above method abstracts the to-be-modeled requirement into types, processes, and relationships. The type is also the expression form of the object, that is, a simulation model corresponding to the to-be-modeled requirement is constructed based on the object-process relationship. On this basis, the scenario and deduction configuration parameters corresponding to the simulation model are defined, and finally, the deduction result corresponding to the to-be-modeled requirement is obtained through model deduction. The present invention has advantages such as being more concise and having fewer element quantities, and can effectively alleviate the problems of limitations in the prior art and can describe richer requirements.

[0009] Other features and advantages of the present invention will be described in the subsequent description, and, in part, will be obvious from the description, or will be understood by implementing the present invention. The objectives and other advantages of the present invention are achieved and obtained by the structures specifically pointed out in the description, claims, and drawings.

[0010] To make the above objects, features, and advantages of the present invention more apparent and understandable, the following provides preferred embodiments in conjunction with the accompanying drawings and describes them in detail as follows. Description of the Drawings

[0011] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0012] Figure 1 Flow diagram of a method for modeling the object-process relationship provided by an embodiment of the present invention; Figure 2 Schematic diagram of the objectivity, association, and development of a thing provided by an embodiment of the present invention; Figure 3 Schematic diagram of an interface of a definition type provided by an embodiment of the present invention; Figure 4 Schematic diagram of the interface after defining type elements provided by an embodiment of the present invention; Figure 5 Another schematic diagram of the interface after defining type elements provided by an embodiment of the present invention; Figure 6 Schematic diagram of an interface of a type design view provided by an embodiment of the present invention; Figure 7 Schematic diagram of a definition view of a type "column" provided by an embodiment of the present invention; Figure 8 View of the design view of a type "column" provided by an embodiment of the present invention; Figure 9 Schematic diagram of a definition view of a process "add a plate on top" provided by an embodiment of the present invention; Figure 10 Schematic diagram of a design view of a process "add a plate on top" provided by an embodiment of the present invention; Figure 11 Schematic diagram of a definition view of a process "remove a plate from the top" provided by an embodiment of the present invention; Figure 12 Schematic diagram of a design view of a process "remove a plate from the top" provided by an embodiment of the present invention; Figure 13 Schematic diagram of a definition view of a type "Tower of Hanoi" provided by an embodiment of the present invention; Figure 14Schematic diagram of a design view of a type of "Tower of Hanoi" provided by an embodiment of the present invention; Figure 15 Schematic diagram of a definition view of a process "Initialization" provided by an embodiment of the present invention; Figure 16 Schematic diagram of a design view of a process "Initialization" provided by an embodiment of the present invention; Figure 17 Schematic diagram of a definition view of a sub - process "Create a plate" provided by an embodiment of the present invention; Figure 18 Schematic diagram of a design view of a sub - process "Create a plate" provided by an embodiment of the present invention; Figure 19 Schematic diagram of a definition view of a sub - process "Temporary process 2" provided by an embodiment of the present invention; Figure 20 Schematic diagram of a definition view of a process "Move a plate" provided by an embodiment of the present invention; Figure 21 Schematic diagram of a design view of a process "Move a plate" provided by an embodiment of the present invention; Figure 22 Schematic diagram of a definition view of a process "Move" provided by an embodiment of the present invention; Figure 23 Schematic diagram of a related view of a process "Move" provided by an embodiment of the present invention; Figure 24 Schematic diagram of another related view of a process "Move" provided by an embodiment of the present invention; Figure 25 Schematic diagram of a definition view of a sub - process "Calculate the number of new plates" provided by an embodiment of the present invention; Figure 26 Schematic diagram of a design view of a sub - process "Calculate the number of new plates" provided by an embodiment of the present invention; Figure 27 Schematic diagram of a design view of a scenario provided by an embodiment of the present invention; Figure 28 Schematic diagram of a process "End" provided by an embodiment of the present invention; Figure 29 Schematic diagram of an interface of a scenario configuration provided by an embodiment of the present invention; Figure 30 Schematic diagram of an interface of a scenario production provided by an embodiment of the present invention; Figure 31 Schematic diagram of the structure of a modeling device for the relationship between object and process provided by an embodiment of the present invention; Figure 32A schematic structural diagram of a terminal provided by an embodiment of the present invention. Detailed implementation manners

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0014] Currently, based on the existing technical solutions, objectively speaking, it is found that there are the following three problems and disadvantages in the existing technologies: (1) There are many types of existing modeling methods and the modeling methods are complex; (2) For each type of graphic element in the existing modeling technologies, there are many types, making it difficult for users to use; (3) The existing modeling methods do not support logical modeling or arithmetic modeling. Based on this, the embodiments of the present invention provide a modeling method, device, terminal, and medium for object-process relationships, which have advantages such as being more concise and having fewer elements. At the same time, they can effectively alleviate the problems of limitations in the existing technologies and can describe richer requirements.

[0015] To facilitate the understanding of this embodiment, first, a modeling method for object-process relationships disclosed in the embodiments of the present invention will be introduced in detail. This method is applied to a terminal, and 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. Refer to Figure 1 the flowchart of a modeling method for object-process relationships shown in the figure. This method mainly includes the following steps S102 to S106: Step S102, in response to a modeling operation for a to-be-modeled requirement, determine a simulation model corresponding to the to-be-modeled requirement based on the type elements, process elements, and relationship elements.

[0016] Among them, the simulation model is used to express the to-be-modeled requirement 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 view of the target type element is used to express the members of the to-be-modeled requirement. The process definition view of the target process element is used to express the behaviors of the target type element. The target relationship element is 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 running control logic between sub-processes included in the target process element through process relationships.

[0017] In one example, type elements, process elements, and relationship elements can be displayed through a graphical user interface. In a modeling tool, type elements are usually used to represent objects, that is, type elements are the carriers of objects. The embodiments of the present invention perform modeling based on an object-process relationship set. Specifically: in response to the modeler's definition operations for type elements, process elements, and relationship elements, and the implementation operations for type elements and process elements, a simulation model corresponding to the modeling requirement to be modeled is constructed. The simulation model is executable. The executable simulation model can be in the form of code or in the form of primitive graphics.

[0018] Step S104: In response to the scenario definition operation for the simulation model, determine the scenario corresponding to the simulation model.

[0019] Among them, the scenario is used to describe the process control or test case of the simulation model, that is, the scenario can be regarded as a process control or regarded as a test case. In one example, in response to the modeler's definition operation for the scenario, a scenario corresponding to the simulation model can be generated for process control or test case of the simulation model.

[0020] Step S106: Determine the deduction configuration parameters corresponding to the simulation model, and taking the scenario as the entry point, deduce the simulation model based on the deduction configuration parameters to obtain the deduction result corresponding to the modeling requirement to be modeled.

[0021] Among them, the deduction configuration parameters may include scenario name, step precision, start time, stop condition, pause condition, deduction speed, initial attribute values of members of the modeling requirement to be modeled, etc. In one implementation manner, in response to the modeler's scenario configuration, scenario creation and other operations for the simulation model, the deduction configuration parameters are obtained; in response to the modeler's deduction trigger operation for the simulation model, based on the foregoing scenario and deduction configuration parameters, the simulation model is deduced. Deduction is to evolve and run step by step starting from the initial attribute values given in the scenario according to the logic defined by the scenario defined in the simulation model, the target type elements and target process elements used in the scenario, and finally terminate the deduction when the stop condition is reached. The values of each instance and the values of its member attributes after the deduction stops are regarded as the deduction result.

[0022] The modeling method for object-process relationships provided by the embodiments of the present invention abstracts the modeling requirement to be modeled into types, processes, and relationships. Types are the expression forms of objects, that is, a simulation model corresponding to the modeling requirement to be modeled is constructed based on object-process relationships. On this basis, the scenario and deduction configuration parameters corresponding to the simulation model are defined, and finally the deduction result corresponding to the modeling requirement to be modeled is obtained through model deduction. The present invention has advantages such as being more concise and having fewer elements, and at the same time can effectively alleviate the problems of limitations existing in the prior art and can describe richer requirements.

[0023] In the embodiments of the present invention, the basic concept is first explained: the world is objective, related, and developing. For example, Figure 2 as shown in the schematic diagram of the objectivity, relatedness, and development of a certain thing, objectivity: expressed by an object, and the object is used to carry observable and describable information of the thing; relatedness: expressed by a relation, and the relation is used to describe the association relationships between things, between things and processes, and between processes and processes; development: expressed by a process, and the process is used to describe the development and change, generation and extinction of things.

[0024] For easy understanding, the embodiments of the present invention provide a specific implementation manner of a modeling method for object-process relationships.

[0025] For the foregoing step S102, the embodiments of the present invention provide a modeling operation in response to the modeling requirement to be modeled, and a specific implementation manner for determining a simulation model corresponding to the modeling requirement to be modeled based on type elements, process elements, and relationship elements, as shown in the following steps 1 to 4: Step 1, in response to an abstraction operation for the modeling requirement to be modeled, abstract the modeling requirement to be modeled based on type elements, process elements, and relationship elements to determine a type definition view of the target type element, a process definition view of the target process element, and the target relationship element corresponding to the modeling requirement to be modeled. Specifically, it includes steps such as defining the target type element, defining the target process element, and defining the target relationship element.

[0026] Step 1.1, define the target type element: the target type element is used to express the members of the modeling requirement to be modeled. In the embodiments of the present invention, all descriptions of the modeling requirement to be modeled are based on types, and types are abstractions of the modeling requirement to be modeled. A type can have members and attributes to express the characteristics of the type; a type can also have processes to express the behaviors of the type.

[0027] In one implementation manner, the process of defining a type, that is, the process of clearly describing the members, attributes, and processes of the type. Refer to Figure 3 as shown in a schematic diagram of an interface for defining a type. It is possible to respond to the "add type" operation for the type control to obtain an initial type; continue to refer to Figure 4 as shown in a schematic diagram of the interface after defining the type element. The type name is defaulted to "type 1", and it can be modified by double-clicking the graphic element in the following figure or clicking the pen icon on the right side of "type 1" in the type tree on the left, so as to obtain the definition view of the type.

[0028] Step 1.2, Define target process elements: Target process elements are used to express the behaviors of target type elements. In the embodiments of the present invention, the behaviors of types are expressed through processes. A process may have no parameters or may have parameters. Parameters are one of the media for the process to interact with the model world and 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 directly used in the process, and these members and attributes are the only media and carriers for a parameterless process to interact with the model world. In one implementation, the process of defining a 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, finally obtains the definition view of the process.

[0029] Step 1.3, Define target relationship elements: 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.

[0030] In one implementation, structural relationships are needed to define the members and attributes of a type; program relationships are needed to define the parameters of a process; and program relationships are needed to define the interaction between a process and an instance. Exemplarily, refer to the relationship summary table shown in Table 1 below, which is divided into structural relationships and program relationships. Structural relationships include composition relationships, representation relationships, inheritance relationships, attribution relationships, structural control relationships, unidirectional tagged relationships, bidirectional tagged relationships, etc. Program relationships include consumption relationships, generation relationships, input influence relationships, output influence relationships, bidirectional influence relationships, state transition relationships, state transition relationship pairs, leading relationships, conditional relationships, call relationships, self-call relationships, timeout exception call relationships, time shortage exception call relationships, etc.

[0031] Table 1 Relationship Summary Table

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

[0033] In one implementation, referring to Figure 5 the interface schematic diagram after another type of definition element 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, switch to the interface of the type design view, such as Figure 6 the interface schematic diagram of a type of design view shown, Figure 6 in the toolbox pointed by the arrow in, from top to bottom are "Member m", "Property a", "Procedure", "Constant c", and "Remarks" controls respectively. In response to the editing operation on the above controls, obtain the type design view.

[0034] In specific implementation, first, in response to the creation operation of the first-level type element for the modeling requirement to be modeled, determine the members and procedures included in the first-level type element. For each member within the first-level type element, the member can be used as a second-level type element, and determine the members and procedures included in the second-level type element. Repeat this process until the composition and behavior included in the modeling requirement to be modeled are clearly described using multi-level element types.

[0035] 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 running control logic between the subprocesses included in the target process element through process relationships. In the embodiments of the present invention, a process is the definition of the behavior of a type, the implementation of a process is the detailed description of the behavior of a type, the implementation of a process corresponds to the process design view, a process can have subprocesses, and there are four sources of subprocesses: 1) It can be a temporary subprocess; 2) It can also be other processes of the class to which it belongs; 3) It can also be a system-predefined built-in process; 4) It can also use the processes belonging to these instances through the temporary variables, parameters, members, and properties of the process.

[0036] Furthermore, the running control logic between subprocesses is defined using appropriate program relationships. For details, refer to Table 1 above. The embodiments of the present invention will not elaborate on this anymore.

[0037] Furthermore, a subprocess can also have its own subprocesses, which forms a tree structure that gradually refines, abstracts, and encapsulates in a simple and reasonable manner, with both a clear global view and sufficient detailed views, and at the same time has the capabilities and characteristics of componentization and modularization.

[0038] Further, in response to the anchor connection operation for the process design view, connect the parameters of the subprocess in the process design view with the instances required by the subprocess, so that when the subprocess is used in the process design view, the anchor points of the subprocess are displayed in the process design view to prompt the user to connect instances for the subprocess. Taking the type "adder" as an example, the members include "addend 1", "addend 2" and "sum value", and the process includes "addition", then it is necessary to connect the process "addition" with the members "addend 1" and "addend 2". The manifestation form of the parameters of the process is the anchor point. In practical applications, if the subprocess 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 subprocess is used to remind the user that the subprocess needs to connect an instance. Further, in response to the additional binding operation for the process design view, connect the subprocess in the process design view with the instance. Among them, the additional binding is to establish a relationship between the instance in the parent process design view and the subprocess. The sources of the instance include the members / properties of the affiliated class, the temporary members / constants defined in the parent process design view, the parameters of the parent process, the predefined internal object instances, etc. In one implementation manner, in addition to the anchor point binding, the instance can be additionally connected to the process through a relationship. In addition to maintaining the process definition function, the ability of the process can be temporarily expanded. Taking the type "data preprocessing" as an example, the member includes "data 1", and the process includes "preprocessing", then connecting the member "data 1" and the process "preprocessing" can implement the execution of the process "preprocessing" on the member "data 1"; on this basis, if there is a new member "data 2", by additionally connecting the member "data 2" and the process "preprocessing", the execution of the process "preprocessing" on the member "data 2" can be implemented, thereby expanding the ability of the process "preprocessing".

[0039] Step 4, based on the target type element and its corresponding type design view, and the target process element and its corresponding process design view, obtain the simulation model corresponding to the modeling requirement to be modeled.

[0040] To facilitate the understanding of the foregoing Steps 1 to 4, the embodiments of the present invention provide a specific application example of building a simulation model corresponding to the Tower of Hanoi by taking the simple Tower of Hanoi as an example. The specific application example includes: (1) Type definition and implementation: Such as Figure 7 The schematic diagram of the definition view of a type "pillar" as shown, Figure 7 indicating that the members of the type include pillars. Such as Figure 8 The view of the design view of a type "pillar" as shown, Figure 8The schematic type design view includes members and procedures. m represents the member "plate list", and members are represented by rectangular primitives. The explanation of the member "plate" is as follows: in array form, with the element type being an integer. In the embodiments of the present invention, an integer represents one plate; procedures are represented by oval primitives, and the procedures include "add a plate on top" and "remove a plate on top".

[0041] (2) Procedure definition and implementation: Such as Figure 9 The schematic diagram of the definition view of a procedure "add a plate on top" as shown. Figure 9 It shows the relationship between the member "plate" and the procedure "add a plate on top" in the definition design view. Among them, the explanation of the member "plate" is as follows: P in the upper left corner represents a parameter, named plate, and the element type is an integer. Such as Figure 10 The schematic diagram of the design view of a procedure "add a plate on top" as shown, where the procedure "add an element at the end" is a predefined procedure of the array, that is, the procedure of the member "plate list". Figure 10 Its meaning is: bind the instance passed by the parameter to the anchor point of the procedure "add an element at the end".

[0042] Such as Figure 11 The schematic diagram of the definition view of a procedure "remove a plate on top" as shown. Figure 11 It shows the relationship between the member "plate" and the procedure "remove a plate on top" in the definition design view. The relationship between the parameter and the procedure is a non-empty output influence relationship. Such as Figure 12 The schematic diagram of the design view of a procedure "remove a plate on top" as shown. Use the procedure "remove an element at the end" of the member "plate list", and bind the parameter "plate" to the anchor point of the procedure "remove an element at the end". This is a non-empty influence output anchor point, which will put the removed element instance into the parameter "plate".

[0043] Further, in the embodiments of the present invention, taking the complex Tower of Hanoi as an example, a specific application example of building a simulation model corresponding to the Tower of Hanoi is provided. It includes: (1) Type definition and implementation: Such as Figure 13 The schematic diagram of the definition view of a type "Tower of Hanoi" as shown. The type "Tower of Hanoi" has no inheritance relationship.

[0044] Such as Figure 14Schematic diagram of the design view of a type of "Tower of Hanoi", including four members: member "number of disks", member "source pole", member "auxiliary pole", and member "destination pole". Among them, the member "number of disks" represents the level of the Tower of Hanoi, and its type is an integer; the members "source pole", "auxiliary pole", and "destination pole" represent the three poles in the Tower of Hanoi game, and their types are all "pole", and each has a member "disk list", procedures "add a disk on top", "remove a disk on top". It also includes three procedures: procedure "initialize", procedure "move", and procedure "move a disk". Among them, the procedure "initialize" is to initialize the Tower of Hanoi game; the procedure "move" is to move all the disks from the parameter source pole to the parameter destination pole; the procedure "move a disk" is a special move that moves a disk on top of the parameter source pole to the parameter destination pole.

[0045] (2) Procedure definition and implementation: Such as Figure 15 Schematic diagram of the definition view of a procedure "initialize", and the relationship between the parameter number of disks and the procedure "initialize" is a non-empty influencing input relationship. Such as Figure 16 Schematic diagram of the design view of a procedure "initialize", including members "number of disks", "number of disks", "index", and "source pole". Figure 16 It also shows that the embodiment of the present invention uses system global built-in procedures, assignment: b = a; comparison c = a > b; self-decrement: a--; it also uses the procedure "add a disk on top" of the member "source pole"; it also uses the sub-procedures "create a disk" and "temporary procedure 2" defined inside the procedure. It can be seen that this is a loop, the purpose is to add the parameter "number of disks" to the member "source pole", and the large disks are at the bottom and the small disks are on top, and the sizes of the disks on the source pole are arranged in descending order from bottom to top, the largest disk is equal to the number of disks, and the smallest disk is 1.

[0046] The embodiment of the present invention further explains the temporary procedures: its scope of action is inside the parent procedure and is not visible outside. The embodiment of the present invention involves two temporary procedures: sub-procedure "create a disk" and sub-procedure "temporary procedure 2".

[0047] For the sub-procedure "create a disk", such as Figure 17 Schematic diagram of the definition view of a sub-procedure "create a disk", involving two parameters: "disk size" and "disk", and will create a "disk" according to the input parameter "disk size" and put it into the output parameter "disk". Such as Figure 18Schematic diagram of the design view of a subprocess "Create a plate". The execution process starts from the subprocess "Temporary Process 1", creates an instance "plate" and places it in the parameter "plate", then calls the system-built-in process "Assign b = a" to assign the value of the parameter "plate size" to the parameter "plate". The subprocess "Temporary Process 1" in the figure has no specific definition view or design view, or rather its definition view and design view are empty because it has no specific logic and only hitchhikes to execute a "result" relationship, generating a "plate" instance, so it is an empty process.

[0048] For the subprocess "Temporary Process 2", this subprocess only has a definition view, or rather its design view is empty, such as Figure 19 Schematic diagram of the definition view of a subprocess "Temporary Process 2" as shown. The subprocess "Temporary Process 2" has no parameters, but has Java code. The meaning of this Java code is: using the addProblem in the process API to output the string "Initialization completed".

[0049] Such as Figure 20 Schematic diagram of the definition view of a process "Move a plate" as shown. It involves two parameters: "source pillar" and "target pillar", and the relationships between both parameters and the process are non-empty two-way influencing relationships. Such as Figure 21 Schematic diagram of the design view of a process "Move a plate" as shown. After the process "Remove a plate from the top" is completed, the process "Add a plate to the top" is called. Figure 21 It shows that starting from the process "Remove a plate from the top" of the parameter "source pillar", its output parameter is bound to the input parameter of the process "Add a plate to the top" of the parameter "target pillar". This is the direct transfer of parameters because no temporary variable is defined in the middle.

[0050] Such as Figure 22 Schematic diagram of the definition view of a process "Move" as shown. It involves four parameters: the parameter "number of plates", the parameter "source pillar", the parameter "auxiliary pillar", and the parameter "target pillar". Among them, the parameter "number of plates" represents the number of levels of the Tower of Hanoi (or the small Tower of Hanoi formed during the process) to be moved. Note that the process of moving the Tower of Hanoi is a recursively nested process, so the Tower of Hanoi faced by the process "Move" each time it 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.

[0051] Such as Figure 23 Schematic diagram of the involved view of a process "Move" as shown and Figure 24 Schematic diagram of another involved view of a process "Move" as shown. Figure 23and Figure 24 both illustrate the operation control logic among various subprocesses in the process of "move". Among them, Figure 23 illustrates the node where the process starts and marks that the process of "move" uses itself, indicating that the process of "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 roles will be transformed; Figure 24 illustrates that the parameter "target pillar" is bound to the anchor point "auxiliary pillar" of the process of "move".

[0052] Furthermore, the process of "move" also involves a temporary subprocess "calculate new plate number", such as Figure 25 a schematic diagram of the definition view of a subprocess "calculate new plate number" as shown in Figure 26 and a schematic diagram of the design view of a subprocess "calculate new plate number" as shown in

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

[0054] Continuing with the foregoing complex Tower of Hanoi as an example, refer to Figure 27 a schematic diagram of the design view of a scenario as shown in Figure 27 which illustrates that the scenario includes scenario members such as "Tower of Hanoi" and "number of plates". Specifically, Figure 27 indicates the process start node. At this node, the creation of the member "Tower of Hanoi" triggers the process of "initialization", and the Tower of Hanoi is initialized to level 3; after the initialization is completed, the process of "move" of the Tower of Hanoi will be called, and the members of the Tower of Hanoi, namely "number of plates", "source pillar", "auxiliary pillar", and "target pillar", will be bound to their corresponding parameters; after the move is completed, the process of "end" will be called, and this process of "end" is the process called in the scenario. Refer to Figure 28 a schematic diagram of a process of "end" as shown in

[0055] In summary, the entire process of model drawing is to define types, members of types, processes of types, definitions of processes, implementations of processes, definitions and uses of subprocesses, processes of scenarios, uses of various elements in the process, binding of anchor points (parameters) to instances when processes are used, and writing of process codes (such as JAVA, Python, etc.).

[0056] For the foregoing step S106, the embodiment of the present invention further provides an implementation manner of determining the deduction configuration parameters corresponding to the simulation model, taking the scenario as an entry, and performing deduction on the simulation model based on the deduction configuration parameters to obtain the deduction result corresponding to the modeling requirement to be modeled, including the following steps a to b: Step a, in response to a configuration operation for the simulation model, determine the deduction configuration parameters corresponding to the simulation model. The deduction configuration parameters at least include the step precision, start time, stop condition, deduction speed, and initial attribute values of the members of the modeling requirement to be modeled.

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

[0058] See Figure 29 The schematic diagram of the interface of a scenario configuration shown in the figure. The scenario configuration includes: creating a scenario configuration using the built model. It includes: configuration name, model used, scenario, scenario mode (default form scenario), scenario mode and data source of the members and attributes that appear in the scenario.

[0059] See Figure 30 The schematic diagram of the interface of a scenario production shown in the figure. The scenario production includes: configuring various data on the basis of the scenario configuration, including: scenario name, step precision, start time, stop condition, pause condition, speed, values of the member attributes that need to be initialized in the scenario configuration, etc.

[0060] Step b, in response to a deduction trigger operation for the simulation model, taking the scenario as an entry, based on the step precision, start time, deduction speed, and initial attribute values of the members of the modeling requirement to be modeled, perform deduction on the simulation model driven by events, and stop the deduction of the simulation model when the stop condition is met to obtain the deduction result corresponding to the modeling requirement to be modeled.

[0061] Among them, deduction is to evolve and run step by step starting from the initial attribute values given in the scenario according to the scenario defined in the model, the classes used in the scenario, and the logic defined by the process, and finally terminate the deduction when the stop condition is reached. The values of each instance and the values of its member attributes after the deduction stops are regarded as the deduction result. During the deduction process, the values of each instance and the values of its member attributes before the start and after the end of each step are the step snapshots of the deduction.

[0062] Among them, the events include one or more of existence trigger, value change trigger, extinction trigger, status acquisition trigger, and status loss trigger. The existence trigger is triggered when an instance of a specified target type element is generated. The value change trigger is triggered when the value of an instance of a specified target type element changes. The extinction trigger is triggered when an instance of a specified target type element goes extinct. The status acquisition trigger is triggered when an instance of a specified target type element acquires a status. The status loss trigger is triggered when an instance of a specified target type element loses a status. A summary table of the combination of a program relationship and events is shown in Table 2 below: Table 2 Summary Table of the Combination of Program Relationship and Events

[0063] Exemplarily, as described in the definition class, after the instance "Zhang San" of the type "human" is created, the process "growth" needs to be automatically started and continuously run, that is, the existence of the instance triggers the process "growth". This mechanism is called event-driven. Events are supported not only in the class design view but also in the definition view of the process. The model deduction does not run according to a predefined process but is driven by events. The definitions of types and scenarios are only the definitions of rules. Under this rule, the flow direction of the deduction depends on events. Event-driven enables the system to support both models and model deductions with clear processes and those with unclear processes. If events are not used, it is a deduction with a clear process. Using the event-driven mechanism allows for deductions with unclear processes.

[0064] Furthermore, the deduction configuration parameters further include pause conditions. In the embodiments of the present invention, the above method further includes: Step I, during the deduction of the simulation model, when the pause condition is met, pause the deduction of the simulation model; or, in response to a deduction pause operation for the simulation model, pause the deduction of the simulation model. Step II, in response to a modification operation on the simulation model and the deduction configuration parameters, obtain the modified simulation model and / or the modified deduction configuration parameters. Step III, in response to a deduction trigger operation for the simulation model, continue to deduce the simulation model based on the deduction configuration parameters within the scenario. In practical applications, during the deduction process, if the pause condition is met, the deduction will also pause. In the paused state, it is convenient to modify the values of each instance or instance member attributes, and new pause conditions can also be set. Of course, this can also be done when not in the pause / run state. In addition, during the deduction process, the user can pause / stop the deduction through the monitoring interface, the pause / stop task button. Resume the deduction through the resume button. Advance the deduction one step / multiple steps through the step once / step multiple times button.

[0065] Further, it is also possible to respond to a query operation for the simulation model, determine the query result, and display the query result through a graphical user interface. The query result includes information about the simulation model, detailed information about the deduction of the simulation model, and data generated during the deduction of the simulation model. In one example, in the deduction interface, queries for summary information on the deduction progress, events, problems, messages, etc. are provided. Queries for various information such as the definition information of classes and the definition information of class processes in the model used for deduction are provided. In one example, during the deduction process, queries for the instance information of each class and the execution details of the processes of each instance are provided, including information about the process itself, information about the instances corresponding to the parameters used in the process, information about subprocesses, etc.

[0066] Further, the deduction service provides a Restful interface for the front-end interface / other services to actively query information and control the deduction.

[0067] Further, the deduction service pushes deduction information in real time through webSocket and can accept commands to control the deduction.

[0068] In summary, the embodiments of the present invention at least have the following characteristics: 1. Concise: Use a type of view and streamlined modeling primitives to comprehensively describe the business in the field of systems engineering, with low learning and usage costs. Users who model and read models do not need to have programming experience, but having object-oriented (OO) thinking will help with modeling and using the model. 2. Hierarchical: Use a hierarchical approach to meet the user's system thinking mode from macro to micro, achieving key issue focus and step-by-step refinement of solutions. 3. Readable: It can generate a natural language model equivalent to the graphical language model, and vice versa. Business users can understand the model and it is convenient to connect and use the LLM. 4. Complete: Support logical modeling, process modeling, and arithmetic modeling, providing comprehensive support for systems engineering modeling. 5. Runnable: It can build a model that can be simulated and run without code, and natively has the elements to support simulation. 6. Code-expandable: The logic can be supplemented and described by code at any level to simplify the model. 7. Componentized: Support componentization to achieve knowledge sharing, exchange, reuse, and protection. 8. Localized: Expressed in terms familiar to users, minimizing English and translated terms as much as possible. 9. Explicit: All key information should be explicitly expressed, without implicit rules and logic.

[0069] Based on the foregoing embodiments, the embodiments of the present invention provide a modeling device for the object-process relationship. The device is applied to a terminal, and 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. Refer to Figure 31 the structural schematic diagram of a modeling device for the object-process relationship shown, and the device mainly includes the following parts: A modeling module 3102, configured to respond to a modeling operation for a to-be-modeled requirement, and determine a simulation model corresponding to the to-be-modeled requirement based on type elements, process elements, and relationship elements. The simulation model is used to represent the to-be-modeled requirement 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. A scenario definition module 3104, configured to respond to a scenario definition operation for the simulation model, and determine a scenario corresponding to the simulation model. The scenario is used to describe the process control or test cases of the simulation model. A model deduction module 3106, configured to determine deduction configuration parameters corresponding to the simulation model, and take 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 to-be-modeled requirement.

[0070] The modeling device for object process relationships provided by the embodiments of the present invention abstracts the to-be-modeled requirement into types, processes, and relationships. Types are also the expression forms of objects, that is, a simulation model corresponding to the to-be-modeled requirement is constructed based on object process relationships. On this basis, the scenario and deduction configuration parameters corresponding to the simulation model are defined, and finally, a deduction result corresponding to the to-be-modeled requirement is obtained through model deduction. The present invention has advantages such as being more concise and having fewer elements, and can effectively alleviate the problems of limitations existing in the prior art and can describe richer requirements.

[0071] For the device provided by the embodiments of the present invention, the implementation principle and the technical effects produced are the same as those of the foregoing method embodiments. For a brief description, for the parts not mentioned in the device embodiments, reference may be made to the corresponding content in the foregoing method embodiments.

[0072] The embodiments of the present invention provide a terminal. Specifically, the terminal includes a processor and a storage device; a computer program is stored on the storage device, and the computer program, when run by the processor, executes the method according to any one of the foregoing implementation manners.

[0073] Figure 32 FIG. 18 is a schematic structural diagram of a terminal provided by an embodiment of the present invention. The terminal 100 includes: a processor 320, a memory 321, a bus 322, and a communication interface 323. The processor 320, the communication interface 323, and the memory 321 are connected through the bus 322; the processor 320 is configured to execute an executable module stored in the memory 321, such as a computer program.

[0074] The computer program product of the readable storage medium provided by the embodiments 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 foregoing method embodiments. For the specific implementation, reference may be made to the foregoing method embodiments, and details are not described herein again.

[0075] Finally, it should be noted that the above-described embodiments are only specific embodiments of the present invention, used to illustrate the technical solutions of the present invention, rather than limiting it. The protection scope of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that any person skilled in the technical field of the present invention can still modify the technical solutions described in the foregoing embodiments, or can easily think of changes, or make equivalent replacements for some of the technical features; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.

Claims

1. A method for modeling object-process relationships, characterized in that: The method is applied to a terminal, the terminal is configured with type elements, process elements and relationship elements, the terminal displays the type elements, the process elements and the relationship elements through a graphical user interface, and the method includes: 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 element, the process element, and the relationship element, wherein the simulation model is used to express the requirement to be modeled by 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 the 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 demand to be modeled.

2. The object-process relationship modeling method according to claim 1, characterized in that: 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, including: 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 the member of the requirement to be modeled, the process definition view of the target process element is used to express the behavior of the target type element, and the target relationship element is used to describe the type relationship between the target type elements, the process relationship between the target process elements, and the type-process relationship between the target type element and the target process element; In response to the implementation operation for the target type element, determine a type design view corresponding to the target type element, the type design view being a view describing an internal structure of the target type element through the type relationship and the type-process relationship; In response to the implementation operation for the target process element, determining a process design view corresponding to the target process element, wherein the process design view is a view describing the 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.

3. The object-process relationship modeling method according to claim 2, characterized in that: The method further comprises: In response to an anchor point connection operation for 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 point 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.

4. The object-process relationship modeling method according to claim 1, characterized in that: Determine the 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, including: In response to a configuration operation for the simulation model, determining 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 members of the requirements to be modeled; In response to a deduction trigger operation for the simulation model, the scenario is used as an entry point, 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 demand to be modeled, and the deduction of the simulation model is stopped when the stop condition is met, so as to obtain a deduction result corresponding to the demand to be modeled.

5. The object-process relationship modeling method according to claim 4, 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 by 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.

6. The object-process relationship modeling method according to claim 4, characterized in that: The deduction configuration parameters also 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, in response to a deduction suspension operation for the simulation model, pausing the deduction of the simulation model; In response to the modification operation on the simulation model and the deduction configuration parameter, a modified simulation model and / or modified deduction configuration parameter is obtained; 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.

7. The object-process relationship modeling method according to claim 4, 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.

8. 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, the terminal displays the type elements, the process elements and the relationship elements through a graphical user interface, and the device includes: A modeling module, 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 the type element, the process element, and the relationship element, wherein the simulation model is used to express the requirement to be modeled by 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 a test case of the simulation model; The model deduction module is used to determine the 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 the deduction result corresponding to the demand to be modeled.

9. 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 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and 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 7.

Images