RU2681408C2 - Method and system of graphical oriented creation of scalable and supported software realizations of complex computational methods - Google Patents

Abstract

FIELD: computer equipment.SUBSTANCE: invention relates to computer engineering. Method of graph-oriented creation of software implementations of complex computational methods includes the construction and subsequent automatic interpretation of the graphical representation of the algorithm in the form of a directed graph that implements the complex computational method under consideration, and consists in performing a sequence of actions: a) creating an input file format for the software implementation of a complex computational method being created; b) creating a graph model of an algorithm that implements a complex computational method in the form of a directed graph, for which each node has a unique name and defines a fixed state of common data, and each edge is associated with a function, called the transition function, which defines the transformation of common data from one state to another; c) development of software implementations of transition functions defined by a graph model, with each transition function being determined by a pair of functions with unified signatures: a predicate function and a handler function; d) debugging and testing of the developed software implementation of a complex computational method, including automatic interpretation of the graph model, which consists in loading the input data into the computer’s RAM into the common data object, and then traversing the model graph with the launch of all transition functions and passing them to the input modifiable common data object.EFFECT: simplification of the design, development, testing and maintenance of software implementations of complex computational methods.12 cl, 20 dwg

Description

Cross reference to related inventions

The invention is being presented for the first time. The closest are the inventions: US 2016/0261466 A1 - SIEMENS AKTIENGESELLSCHAFT (München, DE), RU 2 435 201 C2 - MUREX S.A.S. (FR).

Technical area

The invention is a method and a software system, and relates to the field of software engineering of specialized computing systems and engineering analysis systems. The invention includes software technology for the automation of the development of supported and scalable software oriented for solving demanding applied problems of engineering analysis in complex technical systems and processes.

State of the art

In the field of software systems used to develop software implementations of computational methods, there are patented analogues [US 2016/0261466 A1 - SIEMENS AKTIENGESELLSCHAFT (München, DE), METHOD AND DIGITAL TOOL FOR ENGINEERING SOFTWARE ARCHITECTURES OF COMPLEX CYBER-PHYSICAL SYSTEMS OF DIFFERIAL OF DIFFERICENT OF DIFFERICENT OF DIFFER ), RU 2 435 201 C2 - MUREX S.A.S. (FR) - PARALLELIZATION AND TOOLS IN THE INFRASTRUCTURE OF CRAFT-ORIENTED PROGRAMMING BASED ON MANUFACTURERS (2011)], as well as a number of well-known software systems are presented in the literature [MatLab [Patent 8], LabView [Patents 4, 5], LUSTRE [8]].

It should be noted that most of the presented developments are highly specialized and the main purpose of their creation was to automate the development of specialized software in certain areas.

For example, the well-known LabView system [Patents 4, 5] offers users a platform for executing programs created using the graphic programming language “G” from National Instruments (USA). The first version of LabVIEW was released in 1986 for the Apple Macintosh, currently there are versions for Microsoft Windows, UNIX, Linux, Mac OS, etc.

LabView is used in data collection and processing systems, as well as for managing technical objects and technological processes similar to SCADA class systems, but in addition to solving problems in the field of industrial control systems, it is more focused on solving problems in the field of scientific research automation. The main purpose of LabView is to build models of technical systems and devices, for this purpose LabView includes many specialized libraries of implemented components, on the basis of which it is possible to build new systems from specific technical areas.

LabView is a closed source product. Newer versions for Windows require activation, while versions for Linux and MAC have limited support.

Another well-known system is the Simulink package, which is included with the MatLab software system. Simulink is a graphical simulation environment that allows using block diagrams in the form of directed graphs to build dynamic models, including discrete, continuous and hybrid, nonlinear and discontinuous systems. Simulink is also focused on solving the problems of modeling complex technical systems and is a model-oriented design system. First of all, Simulink allows you to create a graphical model of the system by assembling it on the basis of standard basic elements (integrator, delay link, adder, product, look-up table, multiplexer, switch, bus selector, etc.), which will correspond to a specific mathematical model of the system based on systems of ordinary differential equations or partial differential equations.

Another system close to the development being presented, focused on graphical modeling of systems, is the FEniCS system. First of all, the system is focused on tasks that can be solved using the finite element method.

FEniCS allows users to quickly transform mathematical models of modeling processes into convenient and easy-to-follow finite element code. FEniCS is an open-source cross-platform system and provides convenient interfaces for accessing functions using the Python and C ++ programming languages. A number of implemented FEniCS algorithms can use high-performance multiprocessor computing resources.

One of the most important features of FEniCS is the implementation of a flexible mechanism for entering mathematical models literally in its original integro-differential form. The FEniCS framework implements convenient mechanisms for working with finite element computational grids, functions for solving systems of linear algebraic equations, etc. [8].

Also worth noting is the TensorFlow system (https://www.tensorflow.org). TensorFlow is an open source library for building software implementations of numerical methods. TensorFlow is also based on the concepts of graph theory, as well as the concept of graph data streams. The fundamental difference between TensorFlow and the presented method is various definitions of nodes and edges. For TensorFlow, nodes represent mathematical operations, and edges represent multidimensional data arrays (tensors), while for the presented method, nodes define fixed states of common data (which, among other things, can include data arrays), and edges determine data transformation functions.

Including sources are presented that describe other systems created earlier, but which did not find such wide distribution: GRIDS, FUNSOFT.

Other highly specialized systems and programming languages should also be noted:

PTOLEMY II (http://ptolemy.eecs.berkeley.edu/ptolemyII/),

ProGraph (http://www.andescotia.com),

Apache Storm (http://storm.apache.org),

IBM InfoSphere Streams (https://www.ibm.com/software/products/en/ibm-streams),

Erlang (https://www.erlang.org/),

PROGRES (https://en.wikipedia.org/wiki/OpenEdge_Advanced_Business_Language),

Cantata, LUSTRE, KLIEG, DOME, GME, Atom3, Moses, DRACO, GenVoca, Datadvance (pSeven)

The current world level of research in this direction is determined by the presented publications, patents and software developments.

SUMMARY OF THE INVENTION

The invention includes a software framework and a system for executing special programs (G06F 9/44), the construction of which is formalized and automated. The invention is intended to simplify the processes of creating software implementations of complex computational methods (SVM). The method is called graph-oriented software engineering (GUI) or graph-oriented approach.

The invention provides the possibility of formalizing the procedure for developing engineering analysis software in complex technical systems and processes due to the formalization of the concept of an algorithm for implementing CBM in the form of a directed graph - graph model (GM).

The invention includes a system (software framework) for interpreting graph models (GM), storing the processed GM in the memory of a computer (G06F 9/06, G06F 9/445) with the subsequent automatic construction of a scalable (single-threaded or multi-threaded) program and its execution (G06F 9 / 445). Graph models describe algorithms for solving specific mathematical problems of engineering analysis (MIA) in complex technical systems and processes, which after interpretation provides numerical calculations and data processing (G06F 17/10).

The invention will automate the processes of engineering calculations in the design (G06F 17/50) of specific technical products.

Using the proposed method, the constructed graph model of a particular algorithm can be easily integrated into a previously created graph model of another algorithm and so on. This makes it possible to create programs at various levels of abstraction, which contributes to minimal duplication of source code during development and provides the ability to create easily modifiable and simultaneously automatically generated software implementations of CBM.

Programming capabilities at various levels of abstraction provide the ability to create universal software systems for testing, validating, emulating and simulating existing software built on the basis of the same principles (G06F 9/455).

Brief Description of the Illustrations

Fig. 1 * - General detailed scheme for processing a graph model of an algorithm that implements a specific computational method.

Fig. 1 - Conceptual diagram of creating a software implementation of a complex computational method using a graph-oriented approach.

Fig. 2 - A conceptual diagram of the processing of a graph model of an algorithm that implements a specific computational method.

Fig. 3 - An example of a graph model of an algorithm that implements a specific computational method. Includes one cycle.

Fig. 4 - An example of a graph model of an algorithm that depends on another graph model (subgraph). The basic execution scheme is presented: (1) - GM of the upper (1st) level of abstraction, (2) - GM of the lower (2nd) level of abstraction. For visual representation of embedded graph models, a special designation of nodes is used.

Fig. 5 - An extended example of a graph model of an algorithm of some computational method. A GM depends on another GM (subgraph), which in turn may depend on another GM. Handler functions and predicate functions are given as attributes of edges of a graph model. 2 graphs of control flows from two levels of abstraction are presented.

Fig. 6 - A relational model of a data structure to create a centralized repository of graph models of algorithms and their attributes in a remote database.

Fig. 7 - The set of possible different and equivalent queues of calls to processing functions in a single-threaded execution mode, for each of which a different, but equivalent, execution program can be built. All queues correspond to one fixed graph model. The number of possible queues is determined by the cyclomatic number of the graph.

Fig. 8 - Call queues in multi-threaded graph model execution mode.

Fig. 9 - UML sequence diagram of actions. Creating a local tool for solving a computational problem based on a graph-oriented approach.

Fig. 10 - A detailed UML diagram of the sequence of actions when working within the framework of the graph-oriented approach.

Fig. 11 - Features of the application of handler functions and predicate functions in the framework of the graph-oriented approach in order to implement automation of parallelization and branching processes.

Fig. 12 - The place of graphite-oriented development software tools within the framework of the logical and hardware architectural decomposition of the entire software computing system.

Fig. 13 - An example of a test file in the DOT format, which represents the GM and its attributes.

Fig. 14 - Placement and registration of a computational task solution tool in a remote computer program system.

Fig. 15 - Example of a source data file in aINI format.

Fig. 16 - Performing a specific software implementation of a complex computational method, built on the basis of the graph-oriented approach, based on a remote computing resource (including multiprocessor).

Fig. 17 - An example of a simple graph model that implements the PR of some CBM.

Fig. 18 - An example of a DOT file representing a simple graph model, shown in Figure 17.

Fig. 19 - An example of the source data file in aINI format, which can be fed to the input of the SVM PR implemented by the graph model shown in Fig. 17.

Fig. 20 - Examples of possible consecutive states of general CBM D data, when using the graph model shown in Figure 17 and feeding it the input data file in aINI format shown in Figure 19.

Detailed description

An original method of developing software implementations of complex computational methods (SVM) is presented. A schematic diagram of the use of the proposed method is presented in Figure 1 and defines the standard recommended sequence of actions for creating software implementations within the framework of the proposed approach.

The main purpose of the method is the development of software implementations of complex computational methods for solving problems of engineering analysis in technical systems, as well as for solving problems of scientific research.

The method is called "Graph-oriented technology for developing software implementations of complex computational methods" or graph-oriented software engineering (GPI).

Using GUI (Figure 1), first of all (Figure 1, position P1) create the input data file format. To develop the input data file format, you should use the aINI format, which allows you to create source data formats for a wide class of computational tasks.

The next operation (Figure 1, position P2) directly creates a graph model (GM) of the algorithm for solving the problem. A GM can be developed using various approaches: a) based on the use of a specialized language for describing DOT graphs, a) based on the use of a specialized software interface of the GPK by directly creating a GM, b) based on the direct creation of a GM and its attributes in relational data models in remote database (Figure 6).

After the construction of the GM, processor functions and predicate functions are developed (Figure 1, position P3) defined by the graph model. Handler functions and predicate functions can be developed using various programming languages: a) the C ++ programming language, b) the Python programming language and others, depending on the corresponding support for software tools that implement GUI (hereinafter, graph-oriented software framework (GPC) )).

To conduct debugging and testing (Figure 1, position P4) of the created software implementation (PR) of the complex computational method, use the standard testing program included in the GPC or develop a new test program in one of the GPC supported programming languages: C ++ or Python.

GUI Basics

The basis of the method:

1) concepts of graph theory;

2) information storage technologies in relational databases;

3) technologies for using dynamic link libraries;

4) technologies for using specialized data structures (associative arrays, trees, graphs).

Application area

The applied field of testing the method is the creation of software implementations of numerical methods in the following applied areas of engineering analysis: applied problems of mathematical physics in general, problems of continuum mechanics, construction of finite element methods, homogenization methods, methods for solving direct and inverse problems in the field of micromechanics of composite materials and others.

The proposed method provides the possibility of introducing software implementations of complex computational methods created with its help into applied software packages of engineering analysis and, more generally, into CAE systems.

Applications and systems within which the application of GUI is relevant:

1) systems of engineering analysis (CAE);

2) optimization systems;

3) software requiring a definition of the concept of a business process (ERP, CRM, web applications with integrated business logic).

Prerequisites for the creation of GUI. Problem situation.

Special conditions that distinguish the development of software implementation of CBM (CR CBM), oriented to solve applied problems of engineering analysis of complex technical systems and processes from software implementation of a computational algorithm for solving a specific highly specialized problem:

T1) a significant amount of work on writing the source code of the SVM PR, limiting the possibilities for creating a high-quality SVM PR to one researcher;

T2) a significant amount of source data (scalar and / or vector) specified exactly and / or inaccurately;

T3) a significant number of special conditions for the functioning and consistency of selected numerical methods to selected algorithms;

T4) the requirement to ensure the scalability of the created PR: taking into account the ability to use available computing resources (using multiprocessor technology) with high computational complexity of the task, which is especially true for applied engineering calculations and for commercial industrial engineering analysis software;

T5) the requirement of the ability to run created PR on various platforms;

T7) the need to ensure the universality of formats for presenting problem statements and sending them for calculation;

T8) when solving applied problems including it is required to provide the possibility of flexible support, the labor costs of which should not depend on the volume of the source code created by the CBM PR.

The main goal of creating the GUI method is to ensure the manufacturability (standardization, unification, continuity of each of the newly created software modules of the SVM) of the design and development of PR SVM during the stages of the software life cycle in the field of engineering analysis systems and scientific research.

The main tasks of using the GUI method.

1) Provide the ability to create software implementations of CBM by a team of research engineers and programmers at the same time.

2) Provide the ability to quickly rebuild the CBM PR when changing requirements both at the development and debugging stage and at the maintenance stage.

3) Ensure that the scalability requirements of the created CBM PRs are satisfied: this refers to the possibility of partial automation of the process of utilizing the available resources of multiprocessor technology.

4) Ensure that the requirements of T1-T8 described above are met.

GUI Formal Basic Concepts

Definition 1 (computational operation): A computational operation will be a separate function F of an algorithm that provides the implementation of a numerical method.

Definition 2 (a complex computational method): A complex computational method will be a complex of interrelated computational operations based on the use of numerical methods (possibly various) for transforming input data specified numerically in order to obtain a numerical result.

Definition 3 (data of a complex computational method): We will call CBM data the set of D parameter-value pairs, where D is an associative multidimensional container, each element of D contains a unique identifier of the element and its corresponding value of an arbitrary type.

Within the framework of the graph-oriented software framework used, a specialized class was developed that implements the indicated functionality. The class is called AnyMap.

Definition 4 (CBM state): A CBM state is a named subset S of the set of element names D.

For a fixed algorithm that implements CBM, CBM states can be modified over time.

Definition 5 (CBM data in state S): CBM data D in state S will be called the subset G of the set D induced by S. Such subsets will be denoted by DS.

Definition 6 (handler function): A handler function is a mapping f: D → D.

The signature of the handler function (in the C ++ programming language): int f (AnyMap &D);

Definition 7 (predicate function): A predicate function is one of the possible mappings: a) p: D → {1,0}; b) p: D → N *, where N * is a countable finite subset of the set N (natural numbers); c) p: D → R *, where R * is a finite set of real numbers.

Possible signatures of a predicate function (in the C ++ programming language):

bool f (const AnyMap &D);

double f (const AnyMap &D);

int f (const AnyMap &D);

Definition 8 (conversion or transition function): The transformation or transition function of the CBM F, defined on the CBM D data set, from state S1 to state S2 is the map F: D → D for which: F (DS1) = <f (DS1 ), p (DS1)>, where <f (DS), p (DS)> = ((p (DS))? f (DS1): Error (DS1)), is the C / C ++ ternary operator, f - data processor function DS1 and converting them to DS2, p - predicate function, determines whether data D can transition from state S1 using the processor function f to state S2 (for example, Figures 5, 11), Error (DS1) - some standard action handler function yuchitelnoy situation.

Definition 9 (graph model): A network model (GM) (graph model) M of the SVM PR algorithm will be called a directed graph, bypassing which an algorithm for solving a specific computational problem is implemented. A predicate function can be associated with each node of the graph, and a predicate function and a handler function, both together defining the concept of a transition function, must be associated with each edge of the graph.

The concept of GM expands the concept of flow control graph [Myers G. The Art of Testing Programs. M .: Finance and statistics, 1982. 176 s]. The network model of the algorithm determines the model of control transfer in the process of solving a computational problem, has a hierarchical construction principle, and describes the algorithm at various levels of abstraction (claim 3 of the claims).

The number of states used for a particular SVM PR is determined by the number of nodes of the corresponding graph model M.

Definition 10 (software implementation (PR) of SVM): A software implementation (PR) of SVM based on GUI (or simply PR SVM) or a “solver” of SVM will be called a triple: graph model M, data of SVM D and many transformation functions F providing transitions data D from one state to another.

Development of PR SVM using the GUI method (claim 2)

1. Determining the features of computing resources (OVR)

First of all, they determine the OVR to which the SVM PR should be oriented: architecture (multiprocessor system with shared or distributed memory), the number of available computers (processors), available RAM for each computer (processor), and available shared RAM.

2. Development of the input data format (Figure 1, position P1)

A source data file format (FF ID) is being developed for the designed SVM PR. The format should be compatible with the GPK software framework that implements GUI.

FF ID should provide the possibility of forming on its basis input data files for specific computational tasks, the solution of which will be based on the use of the created SVM PR.

FF ID should eliminate the need to develop graphical user interfaces for the created CBM PR for convenient data entry. FF ID should provide a flexible opportunity for making changes after the development of the PR SVM based on the GUI. The aINI or JSON format is used as the basic format for constructing the FF ID for the designed SVM PR (an example in the aINI format is shown in Figure 15).

3. Development of a graph model (Figure 1, position P2)

The development of the graph model includes the definition of the topology of the GM (Figure 3), the set of data states (nodes of the GM) and the set of data transitions (edges of the GM).

GM CBMs are developed using the DOT graph description language (Figure 13) or they use the GPC software interface or GM CBMs are stored directly in the database (the relational data model is shown in Figure 6) of the general software computing system (PVS) (Figure 12).

The created SHM GM can be registered manually (Figure 14) and automatically in the background when directly executed (Figure 2, position P4) in the database (DB) included in the general PVA (Figure 12). The database includes records about the specific SVMs implemented by the GM, their topologies and the corresponding FP and FD, including their classification and typification. Registration of GMs in a single database allows a preliminary search for ready-made standard GMs, their refinement, allows you to implement mechanisms for combining GMs, include one GM in another and reduce the negative consequences of duplication. When registering the GM CBM, the access rights to this GM of other PVS users are determined.

4. Development of libraries that implement processing functions and function-derivatives (Figure 1, position P3)

A handler function (FD) is a function for converting general CBM data as a whole (Definition 6).

A predicate function (FP) is a function for checking the correctness of data in a particular state of CBM data (Definition 7).

Handler functions (FOs) can only be bound to edges. If the FD is not tied to the edge, then the standard FD will be launched, which does not implement any special actions: this strategy is useful for creating stub functions, the actual implementation of which can be postponed indefinitely.

Predicate functions (FPs) can be bound to nodes and / or edges. In the case of FP binding to a node, a branching is implemented for the GM (Figure 11). The AF tied to the edge determines the possibility of starting the corresponding FD (Figures 5, 11), and so on. a mechanism for parallelizing the control flow of the algorithm is implemented (Figure 11). If the FP is not tied to a node, then no standard FPs are specially launched using the GPU used, however, if the FP is not attached to the edge, then the standard FP will be called within the GPU used, which will check the correctness of the data for the possibility of a subsequent call DOF. T.O. FPs may not be attached both to nodes and to the ribs of a GM developed by an SVM PR. Such a strategy makes it possible to reduce the requirements for specialists involved in the development of PR SVM using GUI as a whole.

The development of FD and FI is carried out in two stages. The first step is that all FDs and FPs are given names during the development of the GM created by the SVM PR. The second stage is the direct development of FD and FP using selected programming languages.

When developing the source code of each FD and FP, the input and output data of the functions are placed in the object D (CBM data) in the format defined by the AnyMap class (associative multidimensional array). According to the defined and recorded headings of the FI and FI (definitions 6.7), object D is transferred to the FI by reference (with the possibility of making changes), and to the FI by constant link (without the possibility of making changes).

To store the values of specific parameters (input and output) for each FD and FP within the framework of the AnyMap structure used for general CBM D data, a special naming principle was defined. The proposed naming principle is that each CBM D data parameter should receive a name that is clear to the developer of the corresponding function on the one hand and an obvious way to search for this parameter among the accumulated D parameters on the other. As part of the GUI, a naming principle would be defined that would include the following items (example in Figure 20).

1. A parameter whose name, and only it, is defined in the FD, should receive a unique full name in the format (for the current GM):

[<Destination Host Name>] [<Parameter Name>].

For the case of an embedded GM, the format presented above should be supplemented with information about the node that is being replaced and information about the embedded solver, i.e. format will take the form:

[<Name of the replaced node>] [<Name of the nested solver>] [<Name of the destination node>] [<Parameter name>]

2. [<Destination node name>], obviously, must be unique among all nodes of this GM. At the same time, the node names do not have to be unique for all GMs that implement the developed CBM PR, including all nested GMs.

3. The first part of the name [<Name of the destination node>] and / or [<Name of the replaced node>] [<Name of the nested solver>] [<Name of the node of destination>] cannot be determined at the level of the developer of the FS of the CBM, since in this case, the possibility of using this DF in another part of the GM or in another GM is limited at all.

4. Since the launch of a specific FD is initiated in the CCP, both [<Name of the destination node>] and / or [<Name of the replaced node>] [<Name of the embedded solver>] [<Name of the destination node>] at the time of launch for the constructed model The SVM PR algorithm (Figures 7, 8) will be known.

5. The process of reading data from the general data of the CBM D and the process of writing data to the data of the CBM D should be carried out differently (Figure 20).

6. To directly write the parameter value to the CBM D data object, you should use the push_data function of the GPC software framework, which receives an AnyMap object, the name of the parameter to be written [<Parameter Name>] and its value.

7. Reading should be done using the [] operator recursively, which should be overloaded for the AnyMap class.

This format provides the developer of the next FD with the possibility of an obvious mechanism for identifying any parameter in a GM of any complexity. An example is presented for the graph model (Figure 17), then it is presented with the corresponding DOT file (Figure 18), then an example of the input data file in the aINI format is presented (Figure 19), and finally, Figure 20 shows examples of possible sequential states of common CBM data .

Using the presented format, the mechanism of using existing SVM PRs as a whole is simplified, including maintenance and refinement: to determine the full name of the required parameter, information is needed on the GM of a particular CBM, its attributes, the name of the node that determines the initial state of the CBM D data from which the developed FD and the name of the desired parameter to read.

Such a naming strategy leads to simplification of the code for reading the necessary parameters in the corresponding FD, systematizing this process.

Regarding the FP, writing to the CBM D data in the FP is not possible, therefore, the push method cannot be called relative to the FP, while the parameters are read in the FP in the same way as for the FS.

After developing the source code of the sets of FDs and FPs for the developed VHF PR within the framework of the GUI, depending on the chosen programming language, it may be necessary to compile and assemble the created FDs and FPs into dynamic link libraries (for the case when the compiled programming language FD and / or FP was chosen )

After assembling the FD and FP into dynamic link libraries, the created libraries are placed in specialized directories of file systems (it is recommended to immediately assemble the libraries into the correct directories for their subsequent use). The specified directories must be accessible to the operating system for using these libraries when running local debugging and testing procedures for the created CBM PR. In the case of developing separate FDs and FIs using interpreted programming languages during debugging and testing, the created libraries of FDs and FIs provide access to the corresponding software interpreters (for example, Python) (Figure 10).

Created and debugged FD and FP can be registered in the database (DB), which is part of the general PVA (Figure 10). The database includes records about the implemented specific GMM GM and their corresponding FP and FD, including their classification and typification. Registration of ФО, ФП and ГМ in a single database allows a preliminary search for ready-made ФО, ФП and ГМ, their revision, and also reduces the negative consequences of code duplication. It is possible to take advantage of the existing FD and FP in the system based on the use of available source code or in binary form in the form of an accessible dynamic library. Access is granted if the author of these source codes and the corresponding binary modules of the FD and / or FP provided such opportunities during registration. The provision of possible access to the function and the type of access is determined when registering the FI and FI in the framework of the PVA (Figures 10, 14).

Direct loading of the source code or assembled binary modules of the FD and / or FP, as well as the GM in the DOT format and other formats, is possible through WEB-oriented applications provided by the PVA (Figure 14).

The development of the whole GM, FD and FP, the source data file format, as well as including debugging and testing processes, can be carried out locally without access to any external systems through the use of the GPK distributed in the form of an archive (Figure 9).

Total determined the composition of the CCP.

1. Formalized concepts: network model, data state, transformation function, predicate function, processor function.

2. Universal interpreter GM. The program implements a bypass of an arbitrary GM, taking into account the embedded GM (Figure 5).

3. A specialized data structure for storing common data (Definition 3).

4. A fixed method for determining the signatures of arbitrary predicate functions and handler functions (definitions 6, 7).

5. Fixed universal methods for storing GM and their attributes, including the names of each FD and FP. In turn, the GPK provides the ability to convert the GM and its attributes from one format to another.

5. Development / use of a testing program (Figure 1, position P4)

A schematic diagram of the process of developing and testing the created software implementation based on GUI is shown in Figure 9 (GM file format - DOT). The direct process of executing the SVM PR is presented in Figure 2.

The process of debugging and testing the created CBM PR is carried out by dynamically constructing a call queue taking into account the currently used computing hardware system (Figure 12). The GPC analyzes the available computing resources and automatically generates a single-threaded (Figure 7) or multi-threaded (Figure 8) execution plan for the created GM that implements a specific CBM. The execution plan is presented in the form of one or more call queues. After the execution plan is formed, the task is carried out directly, thereby dynamic assembly of the algorithm that implements the CBM of interest at run time is performed (Figure 2).

GUI Features

The hierarchical principle of constructing GM PR SVM (claim 3 of the claims)

By analogy with data flow diagrams (DPD or Data Flow Diagram (DFD)), graph models can provide abstraction of implementation details by embedding one GM in another (Figures 4,5). It should be noted that the interpreter program (Figure 2), traversing such a graph, remains the same!

Storage of GM and its attributes

GM storage can be implemented in a single file in the standard DOT text format (an example is shown in Figure 13), which allows you to save the GM topology, as well as determine the types of nodes, their names and bind the names of the FD and FP.

GM storage can be implemented in a database. The relational data model for storage is shown in Figure 6. A fragment of the relational data model for storing attributes of the CBM PR implemented using GUI is presented.

Placement and registration of a new computational task solution tool

Placement and registration of a computational problem solving tool in a remote computer program system is carried out according to the algorithm shown in Figure 14 by sequentially uploading the GM elements of a specific CBM PR to the corresponding remote data stores: separate source data (example in Figure 15), graphical CBM models and them corresponding binary modules ФО and ФП. Unloading is carried out through the use of a specialized PVA WEB application (Figure 12) according to the algorithm presented in Figure 14.

Scaling within the framework of GUI (p. 4 and p. 5 of the claims)

In the process of bypassing the GM, many different equivalent queues of calls to data conversion functions can be generated (Figure 7). With the classical approach to software development, the researcher develops a program that corresponds to only one of the presented call queues (single-threaded program), i.e. the researcher initially "does not see" its fundamental structure (topology), which makes it difficult to create a parallel version in the future. In the case of a significant amount of source codes, the possibility of creating a parallel version of the SVM PR is completely reduced to zero.

The created GM makes it possible to ensure multi-threaded execution of the CBM PR automatically (claim 5 of the claims) due to the availability of data on the initial topology of the algorithm that implements the CBM (Figures 3,4,5). Obviously, the use of GM and the launch in multi-threaded mode, all other things being equal, provide an increase in the performance of the SVM PR (Figure 8). T.O. the use of GUI provides automatic scaling of the performed PR SVM.

Independence from commercial software packages (claim 6)

The graph-oriented approach allows you to create software implementations of complex computational methods, regardless of commercial third-party software. Locally created SVM PRs can work locally and simultaneously, with the consent of the authors, can be integrated into third-party software, into a commercial CAE system, as well as into the framework of a common software computing system. Such integration will enable the use of multiprocessor computing resources available to the respective software systems.

The collective development of one PR SVM (paragraph 7 of the claims)

The time expenditures T (N, Ms) for the creation of the CBM PR should not grow more than linearly (preferably) with an increase in the number of program functions N required for development, with a fixed development team determined by the number of developers Ms.

With the increase in the number of functions N of a particular RMS CBM, an increase in the developers of Ms should effectively compensate for the growing workload without complicating the development process.

By standardizing the format for representing graphical models of algorithms implemented by CBM (Definition 9), headers of handler functions and predicate functions (Definitions 6, 7), using the universal AnyMap data structure to store CBM data during the calculation process (Definition 3), and also through the use of the adopted agreement on the standard principle of naming () the parameters stored in the CBM D data, the source code of the handler functions and predicate functions can be developed independently.

The independence of the implemented computational method from the presentation format of the source data (paragraph 8 of the claims)

The specified GUI property is based on the application of: a) aINI universal representation format for the source data (Figure 14), which allows you to save an arbitrary amount of source data of various types in one file and unlimitedly add an arbitrary number of new parameters to this file in the future with changing PR requirements CBM b) the universal AnyMap data structure that implements general CBM D data (Definition 3), which ensures the preservation of arbitrary source data of various types and their quantities. The use of these technologies made it possible to create a universal algorithm for reading the source data, implemented as part of the GPC.

The independence of the procedures for the formation of the statement of the problem, sending statement for calculation and calculation (paragraph 9 of the claims)

The specified GUI property is realized through the implementation of automatic software mechanisms: a) conversion of text data in aINI format into an object of type AnyMap (implementation of shared data of CBM D), b) serialization and deserialization of objects of type AnyMap.

The implementation of these software mechanisms ensures the independence of the task setting procedures from the calculation procedure, and thereby ensures the implementation of sending the task setting to a remote computing node for the purpose of calculation (Figure 16).

Formalization of the procedure for local adjustment of the created PR SVM with an independent change in the types and amount of source data (claim 10 of the claims)

The procedure for local adjustment of the created SVM PR with an independent change in the types and quantity of the source data is ensured by the use of: a) standardized fixed headers used to determine the FI and FI (definitions 6, 7); b) the universal format for representing the initial data aINI (Figure 14), which allows you to save an arbitrary amount of source data of different types in one file and unlimitedly add an arbitrary number of new parameters to this file in the future with changing requirements for the CBM PR; c) a universal AnyMap data structure that implements general CBM D data (Definition 3).

Realization of the possibilities of taking into account the changing operating conditions and the consistency of the work of the selected numerical methods for the selected algorithms during the life cycle of the created PRM SR (claim 11 of the claims)

When the operating conditions and the consistency of the work of the selected numerical methods change, the GPI allows you to flexibly replace the currently used FD and FP: a) either directly in the file describing the GM PR SVM (Figure 13), b) or using special relational data structures during storage GM in a remote database (Figure 6) that implement mechanisms for overloading functions.

Also, using GUI, it is possible to take into account the changing operating conditions and the consistency of the selected numerical methods for the selected algorithms due to the direct use of predicate functions defined in nodes that implement branching.

Independence from the hardware and software functioning platforms (claim 12 of the claims)

Independence is ensured due to the initial distributed architecture of the software computing system and cross-platform implementation of the graph-oriented software framework (Figure 12).

Nearest analogues (in the order of the greatest correspondence)

References

1.US 2016/0261466 A1 - SIEMENS AKTIENGESELLSCHAFT (Munich, DE) METHOD AND DIGITAL TOOL FOR ENGINEERING SOFTWARE ARCHITECTURES OF COMPLEX CYBER-PHYSICAL SYSTEMS OF DIFFERENT TECHNICAL DOMAINS (2016).

2. RU 2 435 201 C2 - MUREX S.A.S. (FR) - PARALLELIZATION AND TOOLS IN THE INFRASTRUCTURE OF GRAPHER-ORIENTED PROGRAMMING BASED ON MANUFACTURERS (2011).

3. KR 20060134087 (A) - BEPTECH INC. (US) METHOD OF PROGRAMMING A PROCESSING SYSTEM (2006).

4. US 4,901,221 - National Instruments Corporation (Austin, Texas, US) - GRAPHICAL SYSTEM FOR MODELING A PROCESS AND ASSOCIATED METHOD (1990) - LabView.

5. US 5,610,828 - National Instruments Corporation (Austin, Texas, US) - GRAPHICAL SYSTEM FOR MODELING A PROCESS AND ASSOCIATED METHOD (1997) - LabView.

6. US 8,949,772 Bl - Amazon Technologies, Inc., (Reno, NV, US) - DYNAMIC MODEL BASED SOFTWARE APPLICATION DEVELOPMENT (2015) - standardization of the process of building applications based on diagrams without reference to the subject area.

7. US 2004/0056908 Al - Turbo Worx, Inc. (New Haven, CT, US) - METHOD AND SYSTEM FOR DATAFLOW CREATION AND EXECUTION (2004) - building applications based on diagrams.

8. EP 3,098,736 A1 - The MathWorks, Inc. (Natick, MA 01760, US) - GRAPHICAL MODELING FOR ACCESSING DYNAMIC SYSTEM STATES ACROSS DIFFERENT COMPONENTS (2016) - MatLab.

9. US 2012/0030646 A1 - Ravindran et al. - DEVELOPING PROGRAMS IN A GRAPHICAL SPECIFICATION AND CONSTRAINT LANGUAGE (2012).

Other publications (sorted by year):

1. Markov A.V. Automation of software design and analysis using UML and Petri nets. The dissertation for the competition. step. Candidate of Technical Science, Nobosibirsk, 2015.

2. Samuel M. Smith. Flow-based programming: Why you should care even if you never plan to use it. In Proceedings of OpenWest (report), page 42 p., 2015.

3. Marakhovsky VB, Rosenblum L.Ya., Yakovlev A.V. Simulation of parallel processes. Petri nets. A course for system architects, programmers, system analysts, designers of complex control systems. Professional literature, IT Preparation, St. Petersburg, 2014.

4. Carkci M. Dataflow and Reactive Programming Systems. Create Space Independent Publishing Platform, 2014.

5. Torsten Meyer, Michael Goedicke, and Gabriele Taentzer. Viewpoint-oriented software development by distributed graph. 2013.21-st IEEE International Requirements Engineering Conference (RE), 00 (1): 92.

6. Patrick K. Notz, Roger P. Pawlowski, and James C. Sutherland. Graph-based software design for managing complexity and enabling concurrency in multiphysics PDE software. ACM Trans. Math. Softw., 39 (1): 1–21, November 2012.

7. Pamela Bhattacharya, Marios Iliofotou, Iulian Neamtiu and Michalis Faloutsos. Graph-based analysis and prediction for software evolution. In Proceedings of the 34th International Conference on Software Engineering, pages 419–429, Piscataway, NJ, USA, 2012. IEEE Press.

8. Mikael Mortensen, Hans Petter Langtangen, Garth N. Wells. A FEniCS-based programming framework for modeling turbulent flow by the Reynolds-averaged Navier-Stokes equations. Computational Engineering, Finance, and Science, 2011.

9. Tiago Boldt Sousa. Dataflow programming concept, languages and applications. Page 12, 2010.

10. Ishchenko M.A. Development of models and methods for the synthesis of the modular structure of automated information systems using Petri nets. The dissertation of the candidate of technical sciences: 05.25.05, Russian State University for the Humanities (RGGU), Moscow, 2009.

11. Morrison J. Paul. Flow-based programming. Unpublished, 2009.

12. Nam H. Pham, Hoan Anh Nguyen, Tung Thanh Nguyen, Jafar M. Al-Kofahi and Tien N. Nguyen. Complete and accurate clone detection in graph-based models. In Proceedings of the 31st International Conference on Software Engineering, pages 276–286, Washington, DC, USA, 2009. IEEE Computer Society.

13. Roberto Bruni, Antonio Bucchiarone, Stefania Gnesi, Dan Hirsch, and Alberto Lluch Lafuente Graph-Based Design and Analysis of Dynamic Software Architectures, pages 37–56. 2008.

14. Wilke Havinga, Istvan Nagy, Lodewijk Bergmans and Mehmet Aksit. A graph-based approach to modeling and detecting composition conflicts related to introductions. In Proceedings of the 6th International Conference on Aspect-oriented Software Development, pages 85–95, New York, NY, USA, 2007. ACM.

15. Christian S. Collberg, Clark Thomborson, Gregg M. Townsend. Dynamic graph-based software fingerprinting. ACM Transactions on Programming Languages and Systems, 29 (6): 35: 1–53: 67, 2007.

16. Ji Zhang and Betty H. C. Cheng. Model-based development of dynamically adaptive software. In Proceedings of the 28th International Conference on Software Engineering, pages 371–380, New York, NY, USA, 2006. ACM.

17. S. Kounev. Performance modeling and evaluation of distributed component-based systems using queuing Petri-nets. IEEE Transactions on Software Engineering, 32 (7): 486-502, July 2006.

18. Andy Schurr. Specification of graph translators with triple graph grammars, pages 151–163. June 2005.

19. Manfred Nagl. A software development environment based on graph technology. Pages 458–478, June 2005.

20. Aditya Agrawal. Model based software engineering, graph grammars and graph transformations. Area Paper, page p. 48, 2004.

21. Gurov V.S., Mazin M.A., Narvsky A.S., Shalyto A.A. UML Switch Technology Eclipse Management Information Systems, 1 (6), 2004.

22. Bernd Bruegge. Graph-based programming (presentation). Lecture course, Technische Universitaet, Muenchen, 2004.

23. Wesley M. Johnston, J.R. Paul Hanna, Richard J. Millar. Advances in dataflow programming languages. ACM Computing Surveys, 36 (1): 1–34, 2004.

24. Christian Collberg, Stephen Kobourov, Jasvir Nagra, Jacob Pitts, and Kevin Wampler. A system for graph-based visualization of the evolution of software. In Proceedings of the 2003 ACM Symposium on Software Visualization, pages 77–99, New York, NY, USA, 2003. ACM.

25. Jack Greenfield and Keith Short. Software factories: Assembling applications with patterns, models, frameworks and tools. In Companion of the 18th Annual ACM SIGPLAN Conference on Object-oriented Programming, Systems, Languages, and Applications, pages 16–27, New York, NY, USA, 2003. ACM.

26. Mary Jean, Harrold Gregg, Rothermel Alex Orso. Representation and analysis of software. CiteSeerX, page 19, 2002.

27. Dorina C. Petriu and Hui Shen. Applying the UML Performance Profile: Graph Grammar-Based Derivation of LQN Models from UML Specifications, pages 159–177. April 2002.

28. Tom Mensa and Michele Lanzab. A graph-based metamodel for object-oriented software metrics. Electronic Notes in Theoretical Computer Science, 72 (2): 57–68, November 2002.

29. B. Bohlen, D. Jager, A. Schleicher and B. Westfechtel. Upgrade: A framework for building graph-based interactive tools. Electronic Notes in Theoretical Computer Science, 72 (2): 91-101, November 2002.

30. Stephen J. Garland, Nancy Lynch. Using I / O automata for developing distributed systems. Pages 277–303, 2000.

31. Walter J. Gutjahr. A graph-based ant system and its convergence. Future Generation Computer Systems, 16 (8): 873–888, June 2000.

32. Peter Heimann, Carl-Arndt Krapp, Bernhard Westfechtel. Graph-based software process management. International Journal of Software Engineering and Knowledge Engineering, 7 (1), 1997.

33. Jeff Magee and Jeff Kramer. Dynamic structure in software architectures. SIGSOFT Software Engineering Notes, 21 (6): 3-14, October 1996.

34. G. Heidenreich, M. Minas, and D. Kips. A new approach to consistency control in software engineering. In Proceedings of the 18th International Conference on Software Engineering, pages 289-297, Berlin, Mar. 1996. IEEE Computer Society Press.

35. Zamperoni. GRIDS-graph-based, integrated development of software: integrating different perspectives of software engineering. In Proceedings of IEEE 18th International Conference on Software Engineering, pages 48–59, Mar 1996.

36. W. Deiters and V. Gruhn. The FUNSOFT net approach to software process management. International Journal of Software Engineering and Know ledge Engineering, 4 (2): 229-256, 1994.

37. Guido Wirtz. Graph-based software construction for parallel message-passing programs. Information and Software Technology, 36 (7): 405-411, July 1994.

38. Allen S Parrishand, Richard B. Borie and David W. Cordes. Automated flow graph-based testing of object-oriented software modules. Journal of Systems and Software, 23 (2): 95–109, November 1993.

39. Chris Jones. An integrated modeling environment based on attributed graphs and graph grammars. Decision Support Systems, 10 (3): 255–275, October 1993.

40. Isa S. Qamber. Flow graph development method. Microelectron Reliab., 33 (9): 1387-1395, 1992.

41. Nicholas Halbwachs, Paul Caspi, Pascal Raymond, Daniel Pilaud. The synchronous data flow programming language LUSTRE. Proceedings of the, 79 (9), 1991.

42. B. Korel and J. Laski. Dynamic program slicing. Information Processing Letters, 29 (3): 155–63, October 1988.

43. Karl J. Ottenstein and Linda M. Ottenstein. The program dependence graph in a software development environment. SIGSOFT Software Engineering Notes, 9 (3): 177–184, April 1984.

44. Peterson J. The theory of Petri nets and modeling systems. World, Moscow, 1984.

Claims (19)

1. The method of graph-oriented creation of software implementations of complex computational methods, including the construction and subsequent automatic interpretation of the graphical representation of the algorithm in the form of a directed graph that implements the considered complex computational method, and consisting in the following sequence of actions: a) creating an input data file format for the software implementation of a complex computational method based on which formats should be used that differ in the ability to define lists of initial parameters and their values; b) creating a graph model of an algorithm that implements a complex computational method in the form of an oriented graph for which each node has a unique name and defines a fixed state of common data, and with each edge there is a function called a transition function that defines the transformation of general data from one state to another; c) the development of software implementations of transition functions defined by the graph model described in clause 1b, and characterized in that each transition function is determined by a pair of functions with unified signatures: a predicate function and a processor function; d) debugging and testing of the developed software implementation of the complex computational method, including automatic interpretation of the graph model, which consists in loading the input data having the format defined in clause 1a into the RAM of the computer in the shared data object, and then traversing the model graph with the launch of all the transition functions with the transfer to them of the input of the modified object common data. 2. The method according to p. 1, characterized by the use of a generalized format of structured text data (for example, aINI, JSON, XML), which should provide the definition of text formats for the source data for a wide class of computational tasks. 3. The method according to p. 2, characterized by the possibility of creating a universal software implementation of the function of loading the source data, described in this way, into the RAM of a computer using the software implementation of the proposed method (hereinafter, graph-oriented software framework) in the form of an object of a multidimensional associative container with arbitrary change in the number, types and values of the loaded source parameters. 4. The method according to p. 1, characterized in that each transition function associated with a particular edge of the graph model receives data in the format of an object of a multidimensional associative container in a state defined by the first node, and converts this data into a new state defined by the second node. 5. The method according to p. 1, characterized in that the graph model of the algorithm that implements the complex computational method can be represented in various ways: a) in the form of descriptions in the well-known language of graphs (for example, DOT); b) in the form of a program in a compiled programming language (for example, C ++) that creates a model at runtime using the capabilities of a graph-oriented software framework. c) in the form of a script that includes an array of queries that ensures the creation, storage, and registration of the model in the repository, which is determined by the graph-oriented software framework used (for example, as a set of records in a database with a predetermined structure). 6. The method according to p. 1, characterized in that the processor functions and predicate functions can be developed using arbitrary programming languages, which is determined and provided by the support of the applied graph-oriented software framework. 7. The method according to p. 1, characterized in that the processor functions and predicate functions are interchangeable up to taking into account the internal structure of the processed data in the form of an object of a multidimensional associative container. 8. The method according to p. 1, characterized in using a standard executable testing program included in the applied graph-oriented software framework, providing interpretation of any graph model and local launch of the created software implementation of a complex computational method. 9. The method according to p. 1, characterized in the possibility of hierarchical embedding in graph models of some computational methods of graph models that implement other computational methods. 10. The method according to p. 1, characterized by the independence of the implemented computational method from the presentation format of the source data. 11. The method according to p. 1, characterized by ensuring the independence of the procedures: the formation of the statement of the problem; loading the statement and sending it for calculation; carrying out the calculation. 12. The method according to p. 1, characterized in providing automatic parallelization of the execution of the created software implementation of the complex computational method due to the previously known topology of the graph model.

Images