Source Code Translation to Dataflow Graphs

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Converting source code between procedural programming languages and dataflow programming languages is challenging due to fundamental differences in execution modalities, such as control flow versus data-driven execution, and existing solutions fail to efficiently translate legacy code into modern languages, especially when dealing with complex data relationships and database compatibility.

Innovation Solution

A method that translates procedural programming languages into dataflow graph representations, enabling component parallelism, data parallelism, and pipeline parallelism, while eliminating intermediate datasets and allowing for database agnosticism, by using a translation module that converts COBOL and JCL scripts into dataflow graphs, preserving metadata for reusable data types and dataset access.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If source code is translated using conventional source-to-source compilers, then legacy code can be converted to modern programming languages, but the translation fails to capture fundamental differences in execution modalities between procedural and dataflow languages

Engineering Contradiction:
Improvetranslation accuracyVSAvoidtranslation complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediate representation (IR) as a mediator between the source procedural language and the target dataflow language. The IR captures the semantic meaning and data relationships of the source code in a language-agnostic form, enabling accurate translation while handling the fundamental differences in execution modalities. This intermediary layer allows the translator to preserve the original program's logic without being constrained by the syntactic and semantic differences between procedural and dataflow paradigms.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The translation process is segmented into distinct phases: parsing the source code into an abstract syntax tree, converting the AST to an intermediate representation that models data relationships, and then generating the target dataflow language code from the IR. This segmentation allows each phase to focus on specific aspects of the translation, improving both accuracy and manageability of the complex translation task.

Inventive Principle:
Principle #1Segmentation

2Ease of operation

If intermediate datasets are preserved in procedural programming, then data can be accessed and processed sequentially, but storage space is consumed and I/O traffic increases

Engineering Contradiction:
Improvedata access efficiencyVSAvoidstorage space
Core Design Contradiction:
Ease of operationVSQuantity of substance

Solution Approach 1:

The patent extracts the data access and processing logic from sequential procedural operations and reformulates it as a dataflow graph where data moves continuously through processing stages. By taking out the intermediate dataset concept and replacing it with direct dataflow connections between computational nodes, the system eliminates the need for persistent storage of intermediate results while maintaining efficient data access through the dataflow execution model.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The dataflow model enables continuous processing where data flows continuously through the computational graph without being written to and read from storage at each stage. This continuity of useful action eliminates the stop-start nature of sequential processing with intermediate datasets, allowing data to be transformed and passed along the pipeline without interruption or storage overhead.

Inventive Principle:
Principle #20Continuity of useful action

3Reliability

If legacy code is maintained in original procedural languages, then existing functionality is preserved, but the code becomes difficult to find engineers with necessary skills to update

Engineering Contradiction:
Improvefunctionality preservationVSAvoidmaintainability
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent changes the language parameter of the code from legacy procedural languages to modern dataflow languages while preserving the functional behavior through the intermediate representation. The IR serves as a functional specification that is language-independent, allowing the same logic to be expressed in different programming paradigms. This parameter change enables the codebase to be maintained by engineers familiar with modern languages while the underlying functionality remains intact.

Inventive Principle:
Principle #35Parameter changes

4Ease of manufacture

If source code conversion focuses on syntactic transliteration, then translation is simpler, but fundamental differences in execution modalities are not addressed

Engineering Contradiction:
Improvetranslation simplicityVSAvoidexecution correctness
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The intermediate representation acts as a mediator that forces the translation process to go beyond syntactic transliteration. The IR requires explicit modeling of data relationships and computational logic in a way that is independent of the source language's execution modality. This intermediary step ensures that the semantic meaning and data flow characteristics are properly captured and translated into the target dataflow language's execution model, rather than merely converting syntax.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3726375B1Source code translation
Publication Date: 2023.02.01 AB INITIO TECHNOLOGY LLC
  • EP3726375B1 patent drawingFigure 1
  • EP3726375B1 patent drawingFigure 2
  • EP3726375B1 patent drawingFigure 3

AI summary

A method comprises: receiving a group of software components (122, 226, 228) comprising code units specified in one or more text-based programming languages and together defining a first data processing activity that includes at least one of (a) storing data in intermediate storage on non-transitory media, and (b) performing a sequence of steps expressed in the one or more text-based programming languages, the first data processing activity representing a transformation of input data comprising a plurality of data records to output data. The method comprises processing each of the code units specified in the one or more text-based processing languages to form respective dataflow graph representations in a dataflow graph programming language; and combining the dataflow graph representations to form a composite dataflow graph (332) in the dataflow graph programming language. The composite dataflow graph (332) defines a second data processing activity representing an equivalent transformation of the input data to the output data, and including at least one type or parallelism from a group consisting of component, data, and pipeline parallelism, the at least one type of parallelism not defined in the first data processing activity.