Source Code Dependency Graphing for Impact Analysis

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Software developers face challenges in identifying and predicting the impact of source code modifications due to limited knowledge and visibility of client workflows, leading to introduced errors and defects that degrade the client experience.

Innovation Solution

A system and method that utilize multi-pronged dependency graphing and intelligent predictions based on historical modifications to provide comprehensive knowledge of upstream and downstream dependencies, generating static and dynamic dependency graphs to perform impact analysis and predict affected methods.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of information

If developers use available tools to recognize and understand impacted code, then they can identify some dependencies, but they lack complete knowledge and visibility of client workflows leading to introduced errors

Engineering Contradiction:

Improvevisibility of client workflowsVSAvoidintroduced errors and defects

Core Design Contradiction:

Loss of informationVSReliability

Solution Approach 1:

The patent segments the dependency analysis into three distinct graphs: static dependency graph (compile-time dependencies), internal-domain dynamic dependency graph (runtime dependencies within the software), and client-domain dynamic dependency graph (runtime dependencies in client workflows). This segmentation allows comprehensive coverage of all dependency types without overwhelming complexity, enabling complete visibility into client workflows while maintaining reliability.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent adds temporal and contextual dimensions to dependency analysis by creating dynamic dependency graphs that capture runtime behavior across different domains (internal and client). This multi-dimensional approach transforms static code analysis into a comprehensive view that includes execution context, workflow boundaries, and actual runtime dependencies, eliminating information loss about client workflows.

Inventive Principle:

Principle #17Another dimension (Dimensionality change)

2Adaptability or versatility

If developers modify source code to correct defects or enhance functionality, then software functionality is improved, but new errors and defects are introduced due to lack of holistic impact analysis

Engineering Contradiction:

Improvesoftware functionality enhancementVSAvoidintroduced defects

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The patent performs preliminary impact analysis by comparing the modified code against all three dependency graphs before deployment. This preliminary action identifies all potentially affected code regions across static and dynamic dependencies, allowing developers to review and test impacted areas before the modification goes live, thus preventing new defects while enabling functionality enhancement.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system provides feedback about the impact of code modifications by analyzing changes against the three dependency graphs and identifying affected workflows. This feedback mechanism highlights upstream and downstream dependencies, allowing developers to understand the full scope of changes before implementation, thereby reducing introduced defects while maintaining adaptability for functionality enhancement.

Inventive Principle:

Principle #23Feedback

3Loss of information

If comprehensive dependency analysis is performed across all code bases, then complete visibility of client workflows is achieved, but system complexity increases

Engineering Contradiction:

Improvecomplete knowledge of client workflowsVSAvoidsystem complexity

Core Design Contradiction:

Loss of informationVSDevice complexity

Solution Approach 1:

The patent reduces system complexity by segmenting the comprehensive dependency analysis into three manageable graphs with distinct purposes: static dependencies, internal runtime dependencies, and client runtime dependencies. Each graph can be generated, stored, and analyzed independently, allowing complete knowledge of client workflows without overwhelming system complexity.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent introduces an intermediary impact analysis module that compares code modifications against all three dependency graphs and synthesizes the results. This intermediary component manages the complexity by providing a unified interface for comprehensive analysis, hiding the underlying complexity of maintaining three separate graphs while delivering complete visibility of client workflows.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS11544055B2System and method for identifying source code defect introduction during source code modification

Publication Date: 2023.01.03 CERNER INNOVATION INC

AI summary

Methods, systems, and computer-readable media are disclosed herein that provide a comprehensive view that reveals all or nearly all possible method dependencies that are present in client workflows. In aspects, when computer code for a particular method is going to be edited, other methods are identified that have upstream or downstream dependencies relative to the particular method. The methods that will be affected based on the computer code editing can be presented in a user-interactive graphical user interface that facilitates exploration of upstream and downstream dependencies.