Vector-Based Software Dependency Identification

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Traditional static analysis methods for identifying software dependency relationships are limited by programming language constraints, scalability issues with large source code, and inability to handle missing code, leading to false dependencies and difficulty in capturing dynamic relationships.

Innovation Solution

A vector-based approach that calculates dependency relationship scores using a magnitude vector and historical trends, allowing for the identification of trending relationships and prioritization of code segment updates based on upward or downward trends, independent of programming languages.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If traditional static analysis is used to identify source code dependencies, then language-specific tools can provide dependency information, but the analysis becomes constrained by programming language limitations and produces numerous false dependencies

Engineering Contradiction:
Improvedependency identification accuracyVSAvoidprogramming language constraints
Core Design Contradiction:
Measurement precisionVSAdaptability or versatility

Solution Approach 1:

The patent introduces a vector-based representation as an intermediary layer between source code and dependency analysis. Instead of directly analyzing source code with language-specific tools, the system converts code elements into vectors and computes dependency relationships through vector operations, thereby eliminating programming language constraints while maintaining accurate dependency identification

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces traditional static analysis mechanisms with a vector-based computational approach. Instead of using language-specific parsing and analysis tools, the system uses vector mathematics to compute dependency relationships, substituting the mechanical analysis process with a more versatile mathematical framework that works across all programming languages

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

2Reliability

If conservative analysis is applied to identify dependencies, then false dependencies are reduced, but relevant dependencies become difficult to identify among numerous false positives

Engineering Contradiction:
Improvefalse dependency reductionVSAvoidrelevant dependency identification
Core Design Contradiction:
ReliabilityVSMeasurement precision

Solution Approach 1:

The patent applies dynamic weighting to dependency relationships by introducing magnitude vectors that capture the strength and direction of dependencies. Instead of using static conservative thresholds, the system dynamically adjusts dependency scores based on vector magnitudes and relationships, allowing relevant dependencies to stand out from false positives through their stronger vector signals

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent changes the parameter space for dependency analysis by transforming binary dependency existence into continuous vector-based dependency scores. This parameter transformation allows for nuanced differentiation between strong relevant dependencies and weak false dependencies, enabling more precise identification of actual relationships

Inventive Principle:
Principle #35Parameter changes

3Measurement precision

If static code analysis is performed, then a snapshot of code relationships is obtained, but dynamic or execution time information is not captured

Engineering Contradiction:
Improvecode relationship snapshotVSAvoiddynamic execution time information
Core Design Contradiction:
Measurement precisionVSLoss of information

Solution Approach 1:

The patent performs preliminary vectorization of source code elements before execution, creating a foundation for subsequent dynamic analysis. By pre-computing vector representations and establishing the framework for vector-based dependency tracking, the system prepares the groundwork for capturing dynamic relationships during actual code execution without losing the structural snapshot information

Inventive Principle:
Principle #10Preliminary action

4Quantity of substance

If traditional analysis tools are used for large source code, then dependency identification is attempted, but scalability issues prevent effective analysis of very large codebases

Engineering Contradiction:
Improvesource code processing capacityVSAvoidanalysis scalability
Core Design Contradiction:
Quantity of substanceVSProductivity

Solution Approach 1:

The patent segments large source code into smaller code elements that are individually vectorized. By dividing the codebase into manageable segments and computing vectors for each segment independently, the system achieves linear scalability and can efficiently analyze very large codebases without overwhelming computational requirements

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent changes the computational parameters from traditional complex static analysis to simpler vector operations. This parameter simplification transforms the complexity from O(n^2) or worse to O(n) vector computations, enabling the system to scale efficiently to large codebases while maintaining analysis quality

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS11455154B2Vector-based identification of software dependency relationships
Publication Date: 2022.09.27 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US11455154B2 patent drawing
  • US11455154B2 patent drawing
  • US11455154B2 patent drawing

AI summary

Techniques for vector-based identification of software dependency relationships are described herein. An aspect includes determining a first dependency relationship value between a first code segment and a second code segment. Another aspect includes calculating a magnitude vector based on the first dependency relationship value and a second dependency relationship value corresponding to the first code segment and the second code segment. Another aspect includes determining a relationship score for the first code segment and the second code segment based on the magnitude vector and the first dependency relationship value.