Producer Graph Runtime for Undo Redo Execution

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software applications lack efficient mechanisms for undoing, redoing, and aborting execution without losing data, especially when dealing with complex object-oriented programming frameworks, leading to resource-intensive recalculations and data re-loading.

Innovation Solution

A system and method that provide native undo, redo, and abort execution capabilities by using a producer graph-oriented programming framework, which tracks client code commands and runtime processes, allowing for reverse execution and synchronization of producer dependencies.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If traditional software applications execute commands in object-oriented programming frameworks, then application functionality is achieved, but efficient undo, redo, and abort operations cannot be performed without re-loading data or recalculating entire applications

Engineering Contradiction:
Improveundo, redo, and abort execution capabilitiesVSAvoidtime for data re-loading and recalculation
Core Design Contradiction:
Ease of operationVSLoss of time

Solution Approach 1:

The system performs preliminary actions by tracking all client code commands and runtime processes in advance, building a complete execution history before undo operations are needed. This allows the system to have all necessary state information ready beforehand, eliminating the need for time-consuming data re-loading when undo operations are performed.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system creates copies of application states through tracking runtime processes and command histories. Instead of re-loading original data, the system maintains replicated state information in the execution history, allowing rapid restoration to previous states without accessing original data sources.

Inventive Principle:
Principle #26Copying

2Device complexity

If traditional software applications lack execution tracking mechanisms, then simpler system structure is maintained, but computational resources are wasted on recalculating entire applications during undo operations

Engineering Contradiction:
Improvesystem structure complexityVSAvoidcomputational resources for recalculation
Core Design Contradiction:
Device complexityVSUse of energy by moving object

Solution Approach 1:

The system implements self-service by having the runtime automatically track its own execution processes and command histories. This self-tracking mechanism provides the necessary state information for undo operations without requiring external monitoring systems, thus avoiding the need for complex additional infrastructure while preventing wasteful recalculations.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system uses feedback mechanisms where the runtime continuously monitors and records execution commands and processes, creating a feedback loop that captures state changes. This feedback information is then used to enable efficient undo operations, allowing the system to restore previous states without re-computation.

Inventive Principle:
Principle #23Feedback

3Reliability

If comprehensive command tracking is implemented, then precise state management for undo/redo is achieved, but increased system complexity and overhead occur

Engineering Contradiction:
Improvestate management accuracyVSAvoidtracking system complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system merges command tracking and state management functions into the existing runtime environment. By integrating these tracking capabilities with the already-present object-oriented programming framework, the system achieves comprehensive state management without adding separate complex tracking infrastructure, thus improving reliability while minimizing additional complexity.

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentEP1952216B1Producer graph oriented programming framework with undo, redo, and abort execution support
Publication Date: 2014.09.24 MUREX
  • EP1952216B1 patent drawingFigure 1A
  • EP1952216B1 patent drawingFigure 1B
  • EP1952216B1 patent drawingFigure 1C

AI summary

A method and apparatus for providing native undo, redo, and abort execution abilities of a runtime is disclosed. In one embodiment, a system includes a runtime to run object-oriented source code with producer dependency declarations for methods, wherein a producer is an instance and a method of that instance, wherein each producer dependency declaration for a given method identifies a set of zero or more producers with outputs that are an input to the given method. According to one embodiment of the invention, the runtime includes a client code tracking module to track the client code commands being run by the runtime. Furthermore, in one embodiment, the runtime also includes a runtime tracking module to track processes of the runtime performed in response to the client code commands being tracked and run by the runtime.