JP2023071664A - Format-specific data processing operation - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve format-specific data processing operations.

SOLUTION: A method includes analyzing, by a processor, a first version of a computer program, the analyzing including identifying a first process included in the first version of the computer program, the first process configured to perform an operation on data having a first format, and generating, by the processor, a second version of at least part of the computer program, including omitting the first process, and including in the second version of the at least part of the computer program one or more second processes configured to perform a second operation on data of a second format different from the first format, in which the second operation is based on the first operation.

SELECTED DRAWING: Figure 1

COPYRIGHT: (C)2023,JPO&INPIT

Description

PRIORITY CLAIM This application claims priority from U.S. Provisional Application No. 62/345,217, filed June 3, 2016, and U.S. Patent Application No. 15/433,467, filed February 15, 2017. and the entire contents of both are incorporated herein by reference.

Background Complex computations can often be represented as data flows using a directed graph (called a "dataflow graph"), the components of this computation being associated with the vertices of this graph, and the data being Flow between each component corresponding to a link (arc, edge) of the graph. Each component is a data processing component that receives data at one or more input ports, processes this data, provides data from one or more output ports, and a sender or receiver of data flows. It can contain data set components that play a supporting role.

Overview In one aspect, a method includes analyzing, by a processor, a first version of a computer program to identify a first process included in the first version of the computer program; A process configured to perform a first operation on data in a first format; and generating, by a processor, a second version of at least a portion of a computer program, comprising: one or more second processes configured to perform a second operation on data in a second format different from the first format, including omitting the process of Including in a second version of at least a portion, the second action being based on the first action.

Implementations can include one or more of the following features.

Identifying the first process includes identifying the first process whose first operation depends on the format of the data.

Identifying the first process includes identifying the first process incapable of performing the first operation on data in the second format.

The method includes determining the format of data to be processed by the first process. Identifying the first process includes identifying the first process incapable of performing the first operation on data having a format of data processed by the first process.

Identifying the first process includes identifying a first data processing element of the computer program, the first data processing element configured to execute the first process. Including one or more second processes in a second version of at least a portion of the computer program includes one or more second data processing in the second version of at least a portion of the computer program. The second data processing element is configured to execute one or more second processes.

A first format includes a data type.

The first format contains the size of the data elements.

A first process is configured to perform a first operation on data records in a first record format, and one or more second processes are configured to perform data records in a second record format. is configured to perform the second operation on the A first record format contains the names of the fields in each record.

The method includes presenting an identifier of a first set of one or more actions in a user interface.

Generating a second version of at least a portion of a computer program includes generating a copy of this portion of the computer program.

The method includes modifying the copy of this portion of the computer program to omit the first process and include one or more second processes.

The method includes executing a second version of the computer program.

One or more secondary processes are defined by overlay specifications. Generating the second version of the computer program includes generating a second version based on the first version of the computer program and the overlay specification. The overlay designation identifies one or more of a process upstream of the first process and a process downstream of the first process. The method includes identifying a first process based on analysis of executable code defining the first process.

A computer program includes a graph. A first process is an executable process represented by a first component of the graph and one or more second processes are represented by one or more second components of the graph. It is an executable process that One or more second components are configured to receive data records from upstream components of the graph. One or more second components are configured to provide data records to downstream components of the graph.

In one aspect, a system is means for analyzing a first version of a computer program by a processor, the analyzing identifying a first process included in the first version of the computer program. means configured to perform a first operation on data having a first format; and generating a second version of at least a portion of a computer program by a processor. comprising omitting the first process and configured to perform a second operation on data having a second format different from the first format; in a second version of at least a portion of the computer program, the second operation being based on the first operation.

In one aspect, a system comprises a processor coupled to a memory, the processor and memory configured to analyze a first version of a computer program, the analyzing comprising the first version of the computer program. wherein the first process is configured to perform a first operation on data having a first format, the version of at least a portion of the computer program configured to generate a second version, including omitting the first process, and configured to perform a second operation on data having a second format different from the first format One or more second processes are included in a second version of at least a portion of the computer program, the second operations being based on the first operations.

In one aspect, a persistent computer-readable medium causes a computing system to analyze a first version of a computer program, the analyzing included in the first version of the computer program. a second version of at least a portion of a computer program, the first process configured to perform a first operation on data having a first format; and omitting the first process, and configured to perform a second operation on data having a second format different from the first format. storing instructions for including the process of No. 2 in a second version of at least a portion of the computer program, the second action being based on the first action;

Other features and advantages will be apparent from the following description and claims.

Description of the drawing
It is an example of a graph. It is an example of a graph. It is an example of a graph. This is an example of overlay designation. It is a block diagram. It is a flow chart. It is a block diagram. It is a block diagram. It is a block diagram. It is a flow chart.

Description An executable application, such as a graph, may include one or more processes that are specific to one or more particular formats of data records processed by the executable application. Such processes may perform operations on data of only one or more specific formats, and attempting to perform these processes on data of different formats may lead to errors or incorrect processing. There is Techniques for identifying executable application processes specific to one or more particular formats of data are now described. In order to allow executable applications to perform operations on data of different formats, a second form of executable application in which these format-specific processes are omitted and one or more other processes are included. version can be generated. These other processes, sometimes referred to as replacement processes, are based on operations performed by the omitted format-specific processes, but are specific to one or more formats of data that differ from each other, or any An operation can be performed that can perform an operation on the data in the format. Including the replacement process in the second version of the executable application enables the executable application to process data in a format different from the format in which the original version of the executable application was constructed.

A replacement process can be defined in an overlay specification, which is a separate file from the original executable application (sometimes referred to as the first application). A replacement process defined in an overlay specification can be added to a second version of an application (sometimes called a second application) without becoming part of the original application. For example, when an application is compiled, the compiler takes into account the overlay file and produces a second application in which one or more processes are omitted and one or more corresponding replacement processes are included. If omitted, it means that the processes contained in the first application are not contained in the second application. A corresponding replacement component is inserted at the location where the second application, eg, the omitted process, was located in the first application.

The replacement process is an example of insertion. Other examples of inserts include test sources and probes, which can also be defined by overlay specifications. A test source is a replacement data source that can provide data, such as test data, for processing by an executable application. Probes are alternative destinations for executable applications to write data. Insertion may be useful, for example, for testing or debugging executable applications such as graphs. For example, a tester or developer may wish to run tests using a particular set of input data to observe the effects of changes to an application. By running the application with a consistent set of input data both before and after this change, the effect of this change on the data output by the application can be monitored. In some instances, the tester has a particular set of test data that will be used when testing the application, such as a set of test data that will exercise all of the application's functionality at least once. may have. Similarly, the tester may wish to write this data output by the application to a specific destination that is different from the standard destination to which the application writes output data.

In some examples, the insertion can be automatically defined based on automatic analysis of the application. For example, replacement components can be automatically defined based on automatic identification of format-specific processes in the application. Test sources and probes can be automatically defined based on the automatic identification of the application's data sources and output data receivers.

In some examples, the executable application is a graph-based process. A graph-based process includes one or more components, each representing an executable process, connected by flows that show the flow of data from one component to another. A replacement process is an object associated with a component in a graph-based process. A replacement process (sometimes called a replacement component) can replace an existing component in a graph such that data that would have been processed by the existing component is instead processed by the replacement component. can. Insertion of test sources and probes are objects associated with flows in graph-based processes. A test source can replace data passing through the flow (eg, upstream data) with new data so that upstream computations do not have to be re-run on each execution of the graph. For example, a test source can replace this data source such that the graph is provided with test data from the test source rather than from the data source. The probe can monitor the data passing through the flow as the graph is executed, and can save this data for later inspection or reuse. For example, the probe may receive data that would otherwise have been stored in an output data receiver such as a database.

Inserts defined by overlay specifications can be added to an application while it is running without becoming part of the original application. When the application is compiled, the compiler takes into account the overlay files and produces an executable application containing the inserts. We may refer to the original application as the first version of the application and the application containing the insert as the second version of the application. For example, in the graph-based process example, the executable graph can be visualized as a second version of the graph containing the elements of the first version of the graph combined with the insert objects defined in the overlay specification. can be represented. In some examples, the executable graph is a shell script and not stored in a file. In some examples, the executable graph and this graph are stored in separate files.

Incorporating inserts into the second version of the graph does not modify the first version of the graph. Instead, the insert definitions can remain in separate files (e.g., separate overlay specifications) and converted to regular graph constructs for inclusion in the modified graph at the start of code generation. Therefore, there is no risk of unintentionally destroying the original graph.

An example of a graph 100 is shown in FIG. Graph 100 is a visual representation of a computer program containing data processing components connected by flows. A flow connecting two components indicates that records output by the first component are passed to the second component. A first component references a second component when a flow connects the first component to the second component.

Data sources 102 such as databases (as shown), files, queues, executable statements (eg, SQL statements), or other types of data sources external to graph 100 are processed by graph 100. contains one or more data records that By external is meant that the data of data source 102 is not stored within graph 100 . Data source 102 is connected to filter component 103 by a flow. In general, a filter component screens or removes records that do not meet predetermined criteria. In this example, filter component 103 passes data records for customers in Ohio and rejects other records. Filter component 103 is connected to sort component 104, which sorts the filtered data records by zip code. Sorting component 104 is connected to replication component 106, which makes copies of data records so that they can be processed in two different ways. The replication component is connected to a format modification component 108 and a filter by expression component 110 . For example, one occurrence of data records for customers in Ohio may be sorted by zip code and sent to format modification component 108, and another occurrence of data records may be configured for sorting by expression. sent to element 110. A format change component 108 changes the format of a data record to a different data format, and a filter by expression component 110 converts the data record to a different data format based on the expression associated with the data record. delete. The format modification component 108 and the filter by expression component 110 are connected to an aggregation component 112 that combines the received data records, which is a database (as shown). , files, queues, or downstream processing components that exist outside the graph. By external is meant that the output data receiver 114 data is not stored within the graph 100 . Graph 100 includes many flows between each component, including flows 116 (sometimes referred to as source/filter flows 116) between data sources 102 and filter components 103, and aggregate component 112. and output data receiver 114 (sometimes referred to as aggregation/output flow 118) are of particular interest in this example.

One or more of each component of the graph may be format-specific components. Format-specific components are components that can only process data in one or more specific formats. A data format is a characteristic of an individual data item (eg, a characteristic of a value within a field of a record) or a characteristic of a record (sometimes called a record format). Examples of characteristics of individual data items are the size of the data item (e.g., single-byte ASCII data item, or multibyte data item), the type of data item (e.g., string type, integer type, Boolean type, or other data types), or other characteristics of individual data items. Examples of record formats include the name of a field within a record, the position of a field within a record, the number of fields within a record, a hierarchical record, an array or repeating group of fields, a nested array, a subrecord, or a record includes another characteristic of

A graph may only be able to process data of a particular format when it contains components specific to that particular data format. When graphs are used to process data having formats that differ from each other, errors may occur or data may be processed incorrectly. To enable a graph to process data in different formats, one or more of the format-specific components can be replaced with components that can process data in different formats. A replacement component can be a format-specific component that is specific to the various components, or a component that can process data in any format (sometimes called a format-independent component). ).

For example, in the example of FIG. 1, sorting component 104 sorts the records by the values in the zip code field. Sort component 104 in this example is a format-specific component that can only handle integers. An operator of graph 100 may wish to use graph 100 to process new sets of data in which the postal code field may contain alphanumeric strings.

Referring to FIG. 2, a second version 200 of graph 100 is generated in which sorting component 104 is omitted and permuted sorting component 204 is included. A permutation sort component 204 is placed in the second version 200 of the graph at the same position as the sort component 104 and is capable of sorting alphanumeric columns. Other components of the graph remain unchanged. A second version 200 of the graph can thus process the new set of data.

Some components may be able to receive and perform operations on data in any format, but may output data in a particular format. If data in different formats are desired as output (eg, to be provided as input to another application that specifies a particular format), the graph may not be able to provide this data. To enable the graph to output data in the desired format, one or more of the format-specific components can be replaced with components capable of outputting data in the desired format.

Still referring to FIG. 1, format modification component 108 is a format-specific component that outputs data in a particular format. For example, format modification component 108 may output a data record with four fields, Name, Account_num, Balance, and Trans_date. Operators of graph 100 may want graph 100 to produce output data in different formats, for example, so that the output data can be processed by another application that has specific requirements for the record format of the input data. Sometimes. In this example, the desired format of the output data includes four fields Cust_name, Balance, Account_num, and Trans_date. That is, it is necessary to rename the first field of the output data and switch the second and third fields.

Referring to FIG. 3, a second version 300 of graph 100 is generated in which format change component 108 is omitted and a replacement format change component 308 is included. The replacement format change component 308 can be placed in the second version 300 of the graph at the same position as the format change component 108 to produce the desired format of the output data. Other components of the graph remain unchanged.

In some examples, other components of the graph may be omitted, such as one or more components upstream or downstream of the format-specific component. In some cases, replacement components may be included in place of one or more of the omitted other components.

In some examples, a tester of graph 100 may wish to debug graph 100 to verify its functionality. In some cases, testers may wish to verify data as it flows from one component to another. In some cases, a tester may wish to bypass an upstream component in graph 100 and instead insert data at the location of the bypassed component. In some cases, a tester may wish to test the behavior of graph 100 using a consistent set of input data to monitor the effect of changing the graph on the data the graph outputs. be. In some cases, the tester tests the behavior of graph 100 using a set of input data that he knows will allow all of the graph's functions to be executed at least once, thus perfecting the graph. Sometimes we want to be able to test

When debugging graph 100, it may be desirable to refrain from modifying the graph. For example, testers may not want to risk compromising the functionality of the graph. In some instances, the tester may have limited or no access to the graph (eg, the tester may not have the necessary permissions to edit the graph). To debug this graph 100 without modifying it, overlays can be used to debug the graph. In some examples, this overlay can be specified automatically, for example based on automatic analysis of the graph. A second version of at least a portion of the graph 100 can be generated based on the original graph 100 (sometimes referred to as the first version of the graph) and the overlay specifications.

As data traverses the flow between each component of graph 100, e.g., along the flow from the first component to the second component, or along the flow to the output data receiver, the probe , collect or monitor this data. For example, as data passes through the flow as graph 100 is executed, this data can be monitored, saved for later inspection, or saved for reuse. Overlay specifications can define probes that refer to flows that carry data to be collected or monitored. Probes specify the flows for which data should be collected or monitored. A probe can be configured to report a particular value, or to report when a particular value is within or outside a predetermined range. Data passing through the probe may be saved for later analysis or use, for example, the data may be stored in a flat file or relational database.

In some examples, a probe can refer to a flow from some component of graph 100 to an output data receiver such as a file or database. By placing a probe along the flow to the data receiver during debugging of graph 100 , this probe receives data output from graph 100 . For example, each time graph 100 is run in debugging mode, output data may be received by a probe and written to a file so that output data from various graph runs may be compared, or otherwise can be evaluated by the method of In some examples, output data receivers are automatically identified and overlays are automatically specified to define probes for insertion in front of the identified output data receivers.

In some examples, a probe may refer to a flow from an upstream component to a downstream component of graph 100 . By placing a probe along the flow to a downstream component during debugging of graph 100, this probe receives data that would otherwise have been received by the downstream component, thus prevent it from running. For example, a tester may wish to monitor the results of graph processing before downstream components. For example, this downstream component may have functionality that affects outside of the graph, e.g. You can send a text message to During graph debugging, the tester may wish to disable components that affect the outside of the graph.

A test source inserts data into graph 100 in a particular flow between two components of graph 100 . An overlay specification can define a test source that references flows that carry data to be replaced with data from the test source. In some examples, the test source replaces data that would normally flow through with new data. In some situations, a test source can be configured to read previously saved data and pass this data to downstream components. In some examples, a test source inserts data into graph 100 in the flow from a data source, such as a database or file. A test source can insert data that has the same format as data that would otherwise have been provided by the data source. In some examples, data sources are automatically identified and overlays are automatically specified to define test sources to replace the identified data sources.

In some examples, the results of running graph 100 to a point (eg, to a component) may have been previously verified. That is, upstream process functionality may have been verified up to a point. In such cases, it may be inefficient for upstream components to reprocess each function each time graph 100 is executed. A test source can insert data (eg, data that has been verified so far) into the graph at some point thereof. In this way, the entire section of graph 100 that has been executed so far may be bypassed.

An example of an overlay specification 200 defining one or more inserts is shown in FIG. Insertions can be objects associated with the flow of a graph (eg, graph 100) and can take the form of probes, test sources, or replacement components. In the example of FIG. 4, overlay specification 200 includes one test source definition 201 and one probe definition 213 . Overlay specifications 200 may be stored in a file, such as a file separate from the file containing specifications for graph 100 .

The overlay specification 200 begins with a three-line header that specifies the graph to which the insert definition can correspond. Following the header are test source definitions 201, probe definitions 213, and replacement component definitions (not shown).

Test source definition 201 includes name 202 , upstream port 204 , downstream port 206 , insertion type 208 , prototype path 210 and layout parameters 212 .

The upstream port 204 of the test source definition 201 references the output port of the component immediately upstream in the flow where the test source is to be inserted into the graph 100 . A component upstream in a flow is the component from which data is output on the flow from its output port. In the example of FIG. 4, upstream port 204 of test source definition 201 points to the output of database 102 . Downstream port 206 of test source definition 201 references the input port of the component immediately downstream in the flow where the test source is to be inserted into graph 100 . A component downstream of a flow is a component whose input port receives data from the flow. In the example of FIG. 4, downstream port 206 of the test source definition points to the input of filter component 103 . Thus, test source definition 201 in this example results in a test source being placed in the flow between the output of database 102 and the input of filter component 103, so that this test source is Indicates that the data provided can replace input data from database 102 .

Insert type 208 defines whether the insert is a test source, probe, or replacement component. In the example of FIG. 4, a value of '0' defines a test source, a value of '1' defines a probe, and a value of '2' defines a replacement component. Other values can be used to define the type of insert. Since this insert is a test source, the value of insert type 208 is "0".

A prototype path 210 indicates the type of insertion. In this example, this insert is test source, so the prototype path 210 specifies the input file component. A prototype path 210 points to a file containing code that defines a particular type of insertion. Layout parameters 212 define the location of the source files that contain the data that the test source will contain. In some examples, this location is a file path. Data in the source file will normally replace data that would pass through the flow defined by upstream port 204 and downstream port 206 . That is, when the test source is applied to graph 100 , filter component 103 receives data in the source file rather than receiving data from database 102 .

This source file contains data that has the same format as data that would otherwise be received by components downstream of the test source. In some examples, the data in the source files may be the same as the data in the data source (eg, database) upstream of the test source. For example, data records from database 102 can be copied to the source file. In some examples, the data source represents executable statements such as SQL queries. In these examples, a SQL query can be executed and the results of this query execution can be stored in a source file. In some examples, the data in the source files can come from somewhere other than the data source. For example, the data in the source file can be generated to reliably process certain data (eg, a range of values) in order to fully debug graph 100 . In some examples, the data in the source file remains the same even though the data in the data source changes, thus allowing debugging to continue with a consistent set of input data.

In some examples, the data in the source file may be the same data that would have passed through the flow during normal execution of the graph 100, but by inserting this data using a test source, the upstream configuration Elements can refrain from processing. For example, an upstream component such as replication component 106 may require a large amount of system resources to process data, or may require a large amount of system resources compared to other components in data flow graph 100 . , the time required to process the data can be relatively long. Thus, known data (eg, the same data that would have passed through the flow during normal execution) can be inserted into the flow to save time or conserve system resources.

Probe definition 213 includes name 214 , upstream port 216 , downstream port 218 , insertion type 220 and prototype path 222 .

The upstream port 216 of the probe definition 213 references the output port of the component immediately upstream of the flow that should insert the probe into the graph 100 . In the example of FIG. 4, upstream port 216 of probe definition 213 points to the output of aggregation component 112 . The downstream port 218 of the probe definition 213 references the input port of the component immediately downstream in the flow that should insert the probe into the graph 100 . In the example of FIG. 4, downstream port 218 of probe definition 213 points to output data receiver component 114 . Thus, the probe definition 213 in this example would result in the probe being placed in the flow between the output of the aggregation component 112 and the output data receiver component 114, resulting in the output data receiver component indicates that the probe receives data that would otherwise have been written to .

Insertion type 220 of probe definition 213 defines whether the insertion is a test source, a probe, or a replacement component. Since this insert is a probe, the value of insert type 220 is "1".

Prototype path 222 indicates the type of insertion. In this example, this insertion is a probe, so prototype path 222 specifies an output file component. A prototype path 222 points to a file containing code that defines a particular type of insertion.

In some examples, data to be monitored by probes is stored in files that are automatically created by the system. This file can be stored at a location determined by the system. The probe monitors data passing through the flow defined by upstream port 216 and downstream port 218 . That is, when a probe is applied to graph 100, the data passing from the output of aggregation component 112 to the input of output data receiver component 114 is monitored and stored in a file automatically created by the system. . In some examples, this data can be monitored prior to storage. The file can receive data in the same format that would have been received by the component referenced by the probe definition (external data receiver component 114 in this example).

In some examples, the overlay specification may define the insertion of one or more probes or test sources as a result of the automatic analysis of graph 100 . For example, an automated analysis of graph 100 can be performed to identify any data source, such as a database, file, or other type of data source. One or more of the identified data sources can be automatically replaced with test sources. The replaced data source inserts the test source into the flow immediately downstream of the data source, so that downstream components are provided with data from this test source instead of data from the data source. means that Similarly, automatic analysis of graph 100 can identify any output data receiver, such as a database, file, or other type of output data receiver. One or more of the identified output data receivers can be automatically replaced with probes. Permuted output data receiver inserts a probe into the flow immediately upstream of the output data receiver, meaning that data from the upstream component is received by the probe instead of the output data receiver. . Automatic analysis of graph 100 can also be used to identify other components, such as specific types of components (eg, specific types of components whose execution affects the outside of graph 100).

Further discussion of test source and probe insertion is presented in US patent application Ser. No. 14/715,807, the entire contents of which are incorporated herein by reference.

A replacement component definition includes a name, upstream port, downstream port, insertion type, prototype path, and layout parameters. The upstream port of a replacement component definition refers to the output port of the component immediately upstream from where this replacement component is inserted into graph 100 . The downstream port of a replacement component definition refers to the input port of the component immediately downstream from where this replacement component is inserted into the graph. An existing component in graph 100 to be replaced by a replacement component can be identified based on the upstream port and downstream port. The insert type defines this insert to be a replacement component.

The prototype path indicates the type of insert. In this example, this insertion is a replacement component, so the prototype path points to the file containing the code defining the replacement component. The code defining the replacement component is based on the code defining the existing component to be replaced, but can handle data in any desired format.

In some examples, overlay specifications may define one or more replacement components for a graph as a result of automatic analysis of the graph. For example, the specifications of each component in the graph can be analyzed. A component specification includes or refers to code that defines this component, eg, code that defines the data processing operations represented by this component. Analysis of the code can reveal whether the data processing operations represented by the components depend on the format of the data.

Replacement components are defined for one or more of the identified format-specific components. In some examples, the format-specific component to replace is identified based on user input. For example, a user may use their knowledge of the format of the input data, the process represented by each format-specific component, or both, to determine whether to replace any of the components. . In some examples, an automatic analysis of the format of the input data can be performed against the format of the data previously processed by the graph to identify replacements for any of the format-specific components.

In some examples, a non-graph-based computer program identifies one or more format-specific processes within the computer program and performs one or more other processes, e.g., on data in a particular format. It can be replaced by a process that can operate on or can operate on data in any format.

Referring to FIG. 5, analysis engine 300 automatically parses graph 100 to identify data sources 302 and output data receivers 304 in order to insert test sources, probes, or both. For example, the analysis engine 300 can access the parameters and connections for each node of the graph 100 (the terms "node" and "component" are sometimes used interchangeably). If a given node has no input connections, parsing engine 300 identifies this node as a data source. Similarly, if a given node has no output connections, parsing engine 300 identifies this node as an output data receiver. In order to access and parse each node of the graph, the parsing engine "explores" all of the graph's connections (the terms "connection" and "flow" are sometimes used interchangeably). go around. In some examples, graph 100 is not instantiated or parameterized until run time (eg, when processing begins for debugging purposes). Analysis engine 300 can perform automatic analysis at runtime to identify data sources and output data receivers in graph 100 .

Analysis engine 300 sends the identifiers of data source 302 and output data receiver 304 to insertion engine 306, which replaces either data source or output data receiver with a test source and probe, respectively. determine whether or not it will be done. In some examples, the tester 308 provides a list 310 of data sources and output data receivers that should be replaced with test sources and probes. This list 310 may be provided as a file, database, or in another format. For example, tester 308 may have any data source on list 310 that is expected to change frequently. By replacing such data sources with test sources, tester 308 can ensure that consistent input data can be used to test graphs.

Insertion engine 306 compares each identified data source 302 and output data receiver 304 with the data sources and output data receivers on list 310 . The insert engine creates an overlay specification 312 for any data source 302 or output data receiver 304 that appears on list 310 . In some examples, parameters for overlay specifications 312, such as upstream ports and downstream ports, are provided by parsing engine 300 to insertion engine 306. FIG. In some examples, the insertion engine 306 accesses the graph 100 to obtain relevant parameters.

To create overlay specifications 312 for the test source, insertion engine 306 reads data into the source file. In some examples, insertion engine 306 reads data copied from data source 302 into source files for test sources that will supersede a particular data source 302 . In some examples, the data source 302 contains executable expressions, such as SQL statements, and the insert engine 306 executes the executable expressions and reads the execution results into the source files. In some examples, insertion engine 306 can request data for source files from tester 308 via user interface 314 . For example, the insertion engine 306 can provide a list of identified data sources 302 to the tester 308 so that the tester 308 can determine which of the identified data sources 302 is the test source. You can choose whether it will be replaced with The tester 308 can also specify data to be included in the source files for the test source. In some cases, the tester 308 can identify the location (eg, path) of the file containing the data for the test source. In some cases, tester 308 can direct insertion engine 308 to generate a source file that is a copy of the data in original data source 302 . In some cases, tester 308 can direct insertion engine 308 to execute executable expressions, such as SQL statements, contained in or associated with original data source 302 . In some cases, the tester 308 may allow data to be generated for the source files of the test sources. For example, tester 308 may provide a set of data, such as real data or generated data, that causes every function in the graph to be executed at least once.

To create the overlay specification 312 for the probe, the insertion engine 308 determines the location of the file in which the output data should be stored. In some examples, this location is set by default, eg, by a system engineer. In some examples, insertion engine 306 can request tester 308 to specify a location for the output data file via user interface 314 .

To insert replacement components, parsing engine 300 parses graph 100 to identify one or more format-specific components 305 within the graph. To analyze each component of the graph, the analysis engine 300 "walks" through all of the graph's connections. In some examples, the parsing engine 300 starts with the furthest upstream component of the graph and "treats" through each outgoing flow from this upstream component, thus eventually traversing all of the graph's components. may be analyzed. Conversely, the parsing engine 300 starts with the furthest downstream component of the graph and "searches" through each input flow to this downstream component, thus eventually reaching all the components of the graph. may be analyzed.

Analysis engine 300 has access to the specifications of each component in graph 100 . A component specification includes or refers to code that defines this component, eg, code that defines the data processing operations represented by this component. Based on analysis of the code, analysis engine 300 can determine whether data processing operations depend on the format of the data. The parsing engine 300 sends identifiers of the format-specific components to the insertion engine 306, which determines whether to omit any of the format-specific components for the replacement component.

In some examples, analysis engine 300 analyzes graph 100 in response to user requests. For example, a user may wish to use graph 100 to process data in a different format than the data normally processed by this graph. A user can request analysis of the graph 100 to ensure that the graph 100 can handle data in different formats.

In some examples, analysis engine 300 analyzes graph 100 once, for example, when the graph is first defined, or when the graph is first instantiated or parameterized (eg, during the first execution of the graph). to generate a list of all format-specific components in the graph. The list of format-specific components within the graph can be stored for future reference and used, for example, in response to user requests to use graph 100 to process data in different formats. can.

In some examples, analysis engine 300 automatically determines when to analyze the graph. For example, a graph's specification may include a description of the format of data so far processed by this graph. If the format of the input data is different from the format of the data processed so far, the parsing engine parses the graph to see if any components need to be replaced in order to process the differently formatted input data. may be determined.

The insertion engine 306 determines whether to omit any of the format-specific components identified by the parsing engine 300 . The insertion engine 306 creates an overlay specification that defines a replacement component for each omitted component.

In some examples, the format-specific components to omit are identified by the user. For example, the insertion engine 306 can display a list of identified format-specific components on the user interface 314, and the user selects the component to replace. The user can indicate the component to be used as the replacement component for each component to be replaced. For example, users may use their knowledge of the format of the input data, the process represented by each format-specific component, or both, to determine whether any of the components should be omitted and which components should be included as a replacement component. Based on user input identifying components to be omitted, replacement components, or both, the insertion engine 306 creates an overlay specification.

In some examples, the insertion engine 306 can automatically determine whether any format-specific components should be omitted and which components should be included as replacement components. For example, the insertion engine can parse the specifications of each of the format-specific components to determine which components can or cannot process the input data. The insertion engine 306 automatically identifies replacement components, e.g., replacement components that represent the same data processing operations represented by the corresponding components to be replaced, but that can process data in the format of the input data. be able to. The insertion engine 306 creates overlay specifications for automatically identified replacement components. In some examples, user input is incorporated into automated decisions. For example, the user may be asked to approve the replacement component identified by the insertion engine 306 .

FIG. 6 shows a general approach for defining replacement components for graphs. A set of data having a particular format is received (400) for processing by the graph. A determination is made as to whether the graph should be analyzed for its ability to process a particular format of received data (402). In some examples, a user can indicate, for example via a user interface, that the graph should be analyzed. For example, the user may know that this set of data has a different format than previous data processed by the graph. In some examples, this determination can be made automatically. For example, the format of the received data can be determined and compared, for example, with information stored in the specification of the graph indicating the format of the data from which the graph is constructed. If the format of the data from which the graph is constructed and the format of the received data do not match, the graph is parsed.

The graph is parsed 404, for example by a processor, to identify one or more components of the graph that depend on the format of the data processed by the component. Specifically, specifications for each of one or more of the graph's components are parsed to identify format-specific components within the graph. In some examples, the graph is analyzed by stepwise progression through each component of the graph. For example, each component is parsed to determine if it is format-specific and to identify its input and output flows. Each flow continues to adjacent components, each of which is parsed to determine whether this component is format-specific and to identify input and output flows. In this way, all of the components of the graph can be analyzed. In some examples, this analysis can be performed automatically at runtime, eg, after the graph has been parameterized. In some examples, this analysis can be performed automatically and dynamically, eg, while the graph is running. For example, dynamic analysis can be performed as certain parameters are resolved during graph execution. In some examples, the graph is received in short-term memory, from which the graph is parsed by a processor to identify format-specific components.

One or more of the components identified as format-specific are evaluated to determine if the component should be omitted and if a replacement component is included (406). For example, a format-specific component may be omitted if the component cannot process data having the format of the received data set. In some examples, a list of format-specific components is displayed in the user interface and the user specifies whether any of the components should be omitted. In some examples, the specification of each of the format-specific components is evaluated to automatically determine whether the component can process data having the format of the received data set. In some examples, all components identified as format-specific are omitted.

Overlay specifications are defined 408 for replacement components with each one or more of the format-specific components to be omitted. The specification of a given replacement component is based on the specification of the corresponding abbreviated format-specific component, but one or more data operations that can be performed on data having the format of the set of data received. Define behavior. In some examples, the replacement component may be format-specific to the format of the received data set. In some examples, the replacement component may be generic, eg, capable of processing data in any format.

Prior to executing the graph, a compiler may compile 410 the graph into an executable graph. As part of compilation, the compiler takes into account overlay specifications 200 that define replacement components. For example, a compiler may accept overlay specification 200 as input. A second version of the graph is generated, the format-specific components identified for replacement are removed, and one or more replacement components are added to the second version of the graph as objects in place of the removed components. inserted into the version. The replacement components may be represented in the second version of the graph along with the data processing components included in the first version of graph 100 (other than the removed components). The overlay specification 200, or the file storing this overlay specification, remains separate from the file containing the graph. That is, the replacement component may be displayed in the second version of the graph along with the data processing components included in the first version of the graph, but the file containing the first version of the graph is the replacement component does not contain a definition of

Insertion of test sources, probes, or replacement components defined in an overlay specification can be performed in at least two modes: Single-Execution Mode and Saved-State Mode. can be done using one.

FIG. 7 shows an exemplary system for executing an insert definition in single execution mode. In this example, client 602 generates or references a first version of graph 604 and an overlay file 606 (eg, overlay specification) that defines an insert. For example, overlay file 606 may be overlay specification 200 in FIG. Graph 604 is then compiled by compiler 608 . Compiler 608 takes overlay file 606 into account and creates a second version of the graph. A second version of the graph is executable and includes inserts defined by overlay file 606 . A second version of the graph can then be run. In some cases compilation and execution occur simultaneously. If the second version of the graph is to be run again, the process is repeated, including redesigning graph 604, recompiling, and rerunning the second version of the graph. No information is saved from one run of the executable graph to the next.

FIG. 8 shows an exemplary system for executing an insert definition in save state mode using save state manager 708 . In this example, a client 702 generates or references a graph 704 and an overlay file 706 (eg, overlay specification) that defines an insert. For example, overlay file 706 may be overlay specification 200 in FIG. A save state repository 710 is managed by save state manager 708 and compiler 712 . The save state manager 708 can also identify where this save state data is located within the save state repository 710 . Graph 704 is compiled by compiler 712 . Compiler 712 takes overlay file 706 into account and creates a second version of the graph that includes the insertions defined by overlay file 706 . A second version of the graph can then be run. In some cases compilation and execution occur simultaneously. The saved state mode differs from the single run mode in that the saved state mode allows the executable graph to be run multiple times while preserving information between each run.

A save state manager 708 can reside in a save state manager directory and manages save states. Examples of information that may be stored in the saved state repository 710 include information related to probe insertion, information related to test source insertion, information related to replacement component insertion, information related to overlay file 706, among other information. and parameters (eg, attributes) associated with the graph components.

In some examples, when an executable graph is executed, only certain portions of the graph are executed. That is, only certain components of the graph are executed. In some examples, less than all of the graph's components are executed. Executable graphs only need to execute the components that will affect the insertion. In some examples, the second version of the graph is a second version of the entire original graph. In some examples, the second version of the graph is a second version of only a fraction of the entire original graph, eg, only the portion of the graph associated with the defined insertion. For example, components upstream of the most upstream replacement component may be executed by the first version of the graph, and components starting with the most upstream replacement component may be executed by the second version of the graph. You may

FIG. 9 illustrates an exemplary data processing system 800 in which the replacement component techniques described herein can be used. The system 800 includes a data source 802, which may include one or more sources of data, such as connections to storage devices or online data streams, each of which may be in various formats (e.g., database tables). , spreadsheet files, flat text files, or native formats used by mainframes). Execution environment 804 and development environment 818 may be hosted on one or more general purpose computers under the control of a suitable operating system, eg, some version of the UNIX operating system. For example, execution environment 804 can include a multi-node parallel computing environment, which includes multiple central processing units (CPUs) or processor cores, local system (e.g., symmetric multiprocessing (SMP) computer ) or a local distributed system (e.g., multiple processors coupled as a cluster or massively parallel processing (MPP)), or a remote processor or remote distributed processor (e.g., a local area network (LAN) and/or multiprocessors coupled via a wide area network (WAN)), or any combination thereof.

Execution environment 804 reads data from data source 802 and generates output data. The storage device providing data source 802 may be local to execution environment 804, for example, it may be stored on a storage medium (eg, hard drive 808) coupled to the computer hosting execution environment 804, or may be executed. It may be remote to environment 804, for example, it may be a remote system (eg, mainframe 810) that communicates with the computer hosting execution environment 804 via a remote connection (eg, provided by a cloud computing infrastructure). ). Data sources 802 may include data defined in a test source definition (eg, test source definition 201 of FIG. 4). That is, layout parameter 212 of test source definition 201 may point to the location of the source file within data source 802 .

The output data may be stored back into data sources 802 or data storage system 816 accessible from execution environment 804, or may be used in other ways. Data storage system 816 is also accessible to development environment 818, which allows developers 820 to develop, debug, and test graphs. In some implementations, the development environment 818 presents the application as a graph containing nodes (representing data processing components or datasets) connected by directed flows (representing work elements or flows of data) between each contact. It is a system for development. For example, US Patent No. 2007/0011668, entitled "Managing Parameters for Graph-Based Applications," describes such an environment in more detail and is incorporated herein by reference. incorporated herein by reference. U.S. Pat. No. 5,966,072, entitled "EXECUTING COMPUTATIONS EXPRESSED AS GRAPHS," describes a system for performing such graph-based computations, This is incorporated herein by reference. Graphs created according to this system provide a way to get information to and from the individual processes represented by the graph components, to transfer information between each process, and to define the order of execution for each process. do. The system includes an algorithm that selects the method of inter-process communication from any available method (e.g., the communication path through the graph flow could use TCP/IP or UNIX domain sockets, or Data can be passed between each process using shared memory).

Development environment 818 includes code repository 822 for storing source code. In some examples, the source code and overlay specification (eg, overlay specification 220 of FIG. 4) may be developed by developer 820 accessing the development environment, eg, via a user interface. In some examples, the source code and overlay designations are automatically determined, for example, by the analysis engine 300 and insertion engine 306 described above. In some examples, graphs and overlay specifications can be stored in code repository 822 . In some examples, graphs are stored in a code repository 822 and overlay specifications are stored in another overlay repository 824 .

One or both of code repository 822 and overlay repository 824 may communicate with compiler 826 . Compiler 826 can compile the first version of the graph and the overlay specification (eg, overlay specification 200 of FIG. 4) into an executable second version 828 of the graph. For example, a compiler may accept an overlay specification as input. One or more inserts are processed and inserted into the graph in the form of objects each corresponding to an insert definition contained in the overlay specification. A second version 828 of the graph can be visually represented by a modified graph. Insert objects may be shown in a second version of graph 500 .

Development environment 818 may include execution environment 830 for executing second version 828 of graph. For example, once the graph is compiled by compiler 826, a second version 828 of the graph can be executed. Executing the second version 828 of the graph includes each component, insertion (e.g., test source, probe, replacement configuration) as data (e.g., work elements or data records) flows between each component. elements, or a combination of any two or more thereof), and performing computations associated with the directed flow of the second version 828 of the graph. In some examples, execution environment 830 executes the second version of the graph without modifying the first version of the graph source code stored in code repository 822 or the source code stored in overlay repository 824 . version 828 of Execution environment 830 may be accessible through an interface of development environment 818 or may have its own interface. This interface can be configured to display information related to the execution. The interface is configured to display information related to the insertion (e.g., data being monitored and stored by probes, data being inserted by test sources, information about replacement components, or other information). You can also The execution environment 830 may allow the developer 820 to execute the second version 828 of the graph multiple times between each run and modify aspects of the second version 828 of the graph. .

In some examples, the developer controls the insertion and compilation of graphs. For example, developer 820 selects the first version of graph 100 of FIG. 1 from code repository 822 . Developer 820 also selects overlay specification 200 of FIG. 4 from overlay repository 824 . In some examples, instead of selecting overlay specification 200 , developer 820 may select insert definitions from various overlay specifications in overlay repository 824 . Developer 820 instructs compiler 826 to compile a second version 828 of the graph based on first version of graph 100 and overlay specification 200 .

In some cases, inserts are inserted automatically. For example, as noted above, one or more data sources, output data receivers, or format-specific components in graph 100 may be identified, for example, by identifying components that have no input or output connections, or It is automatically identified by analyzing the specifications of the components in graph 100 . The identified data sources and output data receivers can be automatically compared to a list of data sources and output data receivers that will be replaced by insertions during debugging of graph 100 . For example, this list can be provided by developer 820 . A format-specific component can be parsed to determine whether this component can process data in a particular format, such as the format of an incoming set of data. A list of format-specific components that cannot process the data is generated. In some examples, this list may be provided by developer 820 . According to this list, overlay specifications for data sources, output data receivers, or format-specific components of graph 100 are automatically created. A second version of the graph is then automatically compiled.

In some examples, overlay specifications are not persistently stored as files in code repository 822 or overlay repository 824 . Rather, the information (e.g., insert definitions) that would normally be included in an overlay file is created by developer 820 (e.g., via a user interface) or automatically determined by parsing engine 300 and inserting engine 306. and temporarily stored in memory. The overlay information is then passed to a compiler (eg, 608 in FIG. 8) or a save state manager (eg, 708 in FIG. 9).

Referring to FIG. 10, in an exemplary process, a first version of a graph (eg, graph 100 of FIG. 1) is received (902). For example, a first version of the graph may be received in short-term memory accessible to the processor. A first version of graph 100 includes components and flows. The components represent the operations performed on the data records, and the flow represents the flow of data records between each component.

An overlay specification is received that defines one or more inserts (904). In some examples, overlay specifications are received from developers or testers. In some instances, overlay specifications are automatically defined, eg, as described above. The overlay specification may be the overlay specification 200 shown in FIG. An overlay specification may include one or more insertion definitions (eg, one or more test source definitions, one or more probe definitions, or one or more replacement component definitions). An insert definition can include a name, upstream port, downstream port, insert type, prototype path, and layout parameters (for test source definitions). Each of the defined test sources and probes can be associated with a flow of graph 100 . Each of the defined replacement components can be associated with a component of graph 100 .

One or more objects, each corresponding to one of the defined inserts, are created (906). An object may be a graph component, such as a test source, probe, or replacement component.

A second version of at least a portion of the graph is generated (908), including at least some of the components and flows of the portion of the graph 100 and the generated one or more objects. In some examples, the second version of the graph is a copy of the original graph 100 modified to include at least some of the components and flows of a portion of the graph 100 and one or more generated objects. is. The second version of the graph can be visually represented by a modified graph (eg, the second version of graph 200 of FIG. 2 or the third version of graph 300 of FIG. 3). Each object is inserted in the flow associated with the defined insertion corresponding to the object (for test sources or probes) or in place of the component associated with the defined replacement component corresponding to this object. be done. The generated insert object, along with the data processing components of graph 100, may be displayed in a second version of the graph, but the first version of graph 100 (or the file containing the first version of graph 100) ) are not modified.

Having described compilers (e.g., compiler 608 in FIG. 7 and compiler 712 in FIG. 8) that can compile graphs and overlay specifications to create a second version of the graph that includes the inserts defined by the overlay files; In some embodiments, graphs and overlay specifications are not compiled. For example, graph and overlay specifications can be executed directly without being compiled. The interpreter can directly execute graph and overlay specifications by converting each statement into a series of one or more subroutines already compiled into machine code.

Although insertions have been described in the form of probes, test sources, and replacement components, in some embodiments the insertions can take other forms. Insertion can be used extensively to enter data at a given point on the graph and retrieve data from a given point on the graph. For example, inserts can be designed to monitor the quality of data passing through the flow of the graph. Users can receive automatic alerts when the data quality is below a threshold. Further description of insertion can be found in US patent application Ser. No. 14/715,904, the entire contents of which are incorporated herein by reference.

Additionally, although insertion has been described in the context of graphs, in some embodiments, insertion can be used with other executable applications. For example, data sources, output data receivers, or format-specific processes for a generic executable application can be identified using automatic analysis of the application. One or more of the identified data sources, output data receivers, or format-specific processes can be replaced by appropriate test sources, probes, or replacement processes, respectively. In this way, executable applications can process data from test sources, output data to probes, or be able to process data in different formats from each other. This configuration may be useful for testing or debugging executable applications.

The techniques described above may be implemented using a computing system executing suitable software. For example, the software may be one or more computers running on one or more programmed or programmable computing systems (which may be of various architectures such as distributed architecture, client/server, or grid). may include steps in a computer program, each of the computing systems having at least one processor, at least one data storage device (including volatile and/or non-volatile memory, and/or storage elements) A system comprises at least one user interface (for receiving input using at least one input device or input port and for providing output using at least one output device or output port). Software may include, for example, one or more modules of relatively large programs that provide services related to graph design, construction, and execution. Each module of the program (eg, elements of a graph) can be implemented as a data structure or other organized data conforming to a data model stored in a data repository.

The software may be implemented on a tangible, persistent medium such as a CD-ROM or other computer-readable medium (eg, readable by a general-purpose or special-purpose computing system or device). , or over the communications medium of a network, in a tangible and persistent medium of the computing system on which the software executes (eg, encoded in a propagated signal). Some or all of the processing may be performed on a dedicated computer, or dedicated hardware such as a coprocessor or field programmable gate array (FPGA), or dedicated application specific integrated circuit (ASIC). can be run using Processing may also be implemented in a distributed fashion, with different computing elements performing different portions of the calculations specified by the software. Each such computer program is accessed by a general purpose or special purpose programmable computer to configure and operate the computer when the storage medium is read by the computer to perform the processes described herein. It is preferably stored or downloaded to a computer readable storage medium capable of storage (eg, a solid state memory device or medium, or a magnetic or optical medium). The inventive system may also be viewed as embodied in a tangible, persistent medium configured with a computer program, wherein the medium so configured enables the computer to perform a specific It operates in a predefined manner to enable one or more of the processing steps described herein.

A number of embodiments have been described. Nevertheless, the foregoing description is intended to illustrate rather than limit the scope of the invention, which is defined by the scope of the appended claims. Please understand. Accordingly, other embodiments are within the scope of the following claims. For example, various modifications may be made without departing from the scope of the invention. Additionally, some of the steps described above may be order independent and, therefore, may be performed in a different order than the order described.

Claims (26)

analyzing a first version of a computer program by a processor, including identifying a first process included in the first version of the computer program, the first process comprising: configured to perform a first operation on data in one format;
generating, by a processor, a second version of at least a portion of said computer program, comprising omitting said first process, wherein data in a second format different from said first format; including in said second version of said at least one portion of a computer program one or more second processes configured to perform the second act, wherein said second act is performed by said second A method based on the operation of 1. 2. The method of claim 1, wherein identifying a first process comprises identifying a first process for which said first operation depends on said format of said data. 3. The method of claim 1 or 2, wherein identifying a first process comprises identifying a first process incapable of performing said first operation on data in said second format. A method according to any one of claims 1 to 3, comprising determining, by said first process, the format of data to be processed. Identifying a first process includes identifying a first process incapable of performing said first operation on data having said format of said data processed by said first process. A method according to claim 4. identifying a first process comprises identifying a first data processing element of said computer program, said first data processing element configured to execute said first process; , the method according to any one of claims 1 to 5. including said one or more second processes in said computer program includes one or more second data processing elements in said second version of said at least part of said computer program 7. The method of claim 6, wherein said second data processing element is configured to execute said one or more second processes. A method according to any preceding claim, wherein said first format comprises a data type. A method according to any one of claims 1 to 8, wherein said first format comprises the size of data elements. The first process is configured to perform the first operation on data records of a first record format, and the one or more second processes are configured to perform the first operation on data records of a second record format. A method according to any preceding claim, arranged to perform said second operation on data records. 11. The method of claim 10, wherein said first record format includes names of fields in said record. A method according to any one of claims 1 to 11, comprising presenting an identifier of the first set of one or more actions in a user interface. A method according to any one of claims 1 to 12, wherein generating said second version of at least part of said computer program comprises generating a copy of said part of said computer program. 14. The method of claim 13, comprising modifying the copy of the portion of the computer program to omit the first process and include the one or more second processes. A method according to any one of claims 1 to 14, comprising executing said second version of said computer program. A method according to any preceding claim, wherein said one or more second processes are defined by overlay specifications. 17. The method of claim 16, wherein generating the second version of the computer program comprises generating the second version based on the first version of the computer program and the overlay specification. the method of. 18. The method of claim 16 or 17, wherein the overlay designation identifies one or more of a process upstream of the first process and a process downstream of the first process. A method as claimed in any one of claims 16 to 18, comprising identifying the first process based on analysis of executable code defining the first process. 2. The method of claim 1, wherein said computer program comprises a graph. wherein the first process is an executable process represented by a first component of the graph and the one or more second processes are one or more second configurations of the graph; A method according to any one of claims 1 to 20, which is an executable process represented by elements. 22. The method of claim 21, wherein the one or more second components are configured to receive data records from upstream components of the graph. 23. A method according to claim 21 or 22, wherein said one or more second components are arranged to provide data records to downstream components of said graph. means for analyzing a first version of a computer program by a processor, said analyzing comprising identifying a first process included in said first version of said computer program; means wherein the first process is configured to perform a first operation on data having a first format;
Means for generating by a processor a second version of at least a portion of said computer program comprising omitting said first process and having a second format different from said first format. including in said second version of said at least part of said computer program one or more second processes configured to perform a second operation on data; A system, wherein an action is based on said first action. a processor coupled to a memory, the processor and memory comprising:
configured to analyze a first version of a computer program, said analyzing comprising identifying a first process included in said first version of said computer program; a process configured to perform a first operation on data having a first format;
configured to generate a second version of at least a portion of said computer program, comprising omitting said first process; in said second version of said at least a portion of said computer program, said second action being configured to perform the action of based on the system. the computing system
A first version of a computer program is analyzed, said analyzing comprising identifying a first process included in said first version of said computer program, said first process comprising: , configured to perform a first operation on data having a first format;
a second operation on data having a second format different from the first format, comprising generating a second version of at least a portion of said computer program and omitting said first process; storing instructions for including in said second version of said at least a portion of said computer program one or more second processes configured to perform said second act is based on said first act.

Images