Modular Software Build with Dependency Tree Testing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current software development and deployment processes face challenges in flexibility and completeness, particularly in testing and installation, due to limitations in data-driven testing methods that struggle with unexpected responses and require extensive scripting knowledge, leading to superficial testing and difficulty in managing dependencies across different software versions.

Innovation Solution

A method involving modular software builds, where a dependency tree is created to define relations between code segments, allowing for dynamic loading and management of executable segment modules, along with a testing approach using reaction lists to monitor and compare all reactions against expected outcomes, enabling more comprehensive testing and optimal software configuration based on test results.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Extent of automation

If data-driven testing methods are used, then testing automation is improved, but testing completeness deteriorates due to inability to handle unexpected responses

Engineering Contradiction:
Improvetesting automationVSAvoidtesting completeness
Core Design Contradiction:
Extent of automationVSReliability

Solution Approach 1:

The patent segments the software application into modular components with defined interfaces. Testing is performed on individual modules and their interfaces separately, then integrated. This segmentation allows automated testing to systematically cover all possible interface interactions and unexpected responses, improving testing completeness while maintaining automation.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements feedback mechanisms where test results from automated testing are used to refine and expand the test case library. Unexpected responses captured during automated testing are automatically added as new test scenarios, creating a self-improving testing system that increases completeness over time while maintaining high automation levels.

Inventive Principle:
Principle #23Feedback

2Measurement precision

If extensive scripting knowledge is required for testing, then testing precision is improved, but ease of operation deteriorates

Engineering Contradiction:
Improvetesting precisionVSAvoidease of operation
Core Design Contradiction:
Measurement precisionVSEase of operation

Solution Approach 1:

The patent implements self-service testing capabilities where the system automatically generates, executes, and analyzes test cases based on the modular software architecture and interface definitions. The testing framework self-adapts to new modules and interfaces without requiring manual scripting, maintaining precision through structured interface contracts while eliminating the need for extensive scripting knowledge by operators.

Inventive Principle:
Principle #25Self-service

3Adaptability or versatility

If modular software build with dependency trees is implemented, then adaptability is improved, but device complexity increases

Engineering Contradiction:
Improvesoftware flexibilityVSAvoidbuild system complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the software into modular components with explicit dependency declarations. Each module is independently compilable and testable. The build system automatically generates dependency trees from these declarations, managing complexity through systematic organization while enabling high adaptability through selective module assembly and configuration for different deployment scenarios.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent creates a universal modular architecture where standardized interface definitions and dependency mechanisms can be applied across different software applications and deployment targets. The same modular build system and dependency management approach works consistently across various platforms and configurations, reducing the need for complex application-specific build logic while maintaining versatility.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Reliability

If comprehensive testing with reaction lists is performed, then reliability is improved, but time consumption increases

Engineering Contradiction:
Improvesoftware reliabilityVSAvoidtesting time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent divides comprehensive testing into segmented phases: unit testing of individual modules, integration testing of module interfaces, and system testing of the complete application. Each phase uses reaction lists focused on specific concerns, reducing the time required for each testing segment while collectively achieving comprehensive coverage and high reliability through the systematic progression through all phases.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent performs preliminary automated testing and static analysis of modular components before executing comprehensive reaction list tests. Dependency validation, interface contract verification, and basic functionality checks are performed in advance, filtering out obvious defects early and reducing the scope and time required for more time-consuming comprehensive testing while maintaining reliability.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS11775273B2Methods and systems of software testing, distribution, installation and deployment
Publication Date: 2023.10.03 VERIVERSION LABS LTD
  • US11775273B2 patent drawing
  • US11775273B2 patent drawing
  • US11775273B2 patent drawing

AI summary

A method of compiling a software application as modular software build, comprising: creating a dependency tree defining a plurality of dependency relations between a plurality of code segments of a software code of a software application, each one of the plurality of dependency relations defines at least one of a functionality dependency, a parameter dependency and a structure dependency between a pair of the plurality of code segments; separately compiling each of the a plurality of code segments into one of a plurality of executable segment modules; and creating a core module adapted to be installed on a client device having a processor for loading the plurality of executable segment modules according to the plurality of dependency relations for an execution of the software application.