Cross-Format Software Analysis for Early Compliance Checking

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing software testing methods face challenges in compliance checking due to the use of different formats and languages for software architecture, source code, and configuration, making it difficult to detect errors early in the development cycle, especially when some components are proprietary or unavailable.

Innovation Solution

The implementation of cross-format analysis systems and methods that analyze software requirements in one format, extract and represent them in an intermediate format, and compare them with source-code implementations in another format, allowing for compliance checking at the source-code level regardless of the format or language used, even if some components are partially developed or unavailable.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If compliance checking is performed after software is compiled into executable code, then the software can be tested with complete functionalities, but the testing process becomes time-consuming and costly

Engineering Contradiction:

Improvesoftware qualityVSAvoidtesting time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The patent performs compliance checking at the source code level before compilation, using static analysis to detect errors early in the development cycle. This preliminary action identifies issues in requirements, architecture, and code without waiting for executable compilation, significantly reducing testing time while maintaining quality assurance.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediate representation layer that translates source code into a format suitable for compliance checking. This intermediary enables analysis of software components without requiring full compilation to executable code, bridging the gap between source code verification and executable testing.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If all software components are required to be implemented and available for testing, then complete system testing can be performed, but development delays occur when components are proprietary or unavailable

Engineering Contradiction:

Improvetesting completenessVSAvoiddevelopment speed

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The patent performs compliance checking on partially implemented software components using static analysis. Instead of requiring complete implementation of all components, the system analyzes available source code, requirements, and architecture descriptions to detect compliance issues, enabling testing without full system availability.

Inventive Principle:

Principle #16Partial or excessive action

Solution Approach 2:

The patent creates intermediate representations and models of software components that can be analyzed without requiring the actual executable components. These representations serve as substitutes that enable compliance verification even when original components are proprietary or unavailable.

Inventive Principle:

Principle #26Copying

3Loss of time

If static analysis is performed on source code in different programming languages, then early error detection is possible, but language-specific tools cannot analyze multi-language projects

Engineering Contradiction:

Improveerror detection timeVSAvoidlanguage compatibility

Core Design Contradiction:

Loss of timeVSAdaptability or versatility

Solution Approach 1:

The patent employs a universal compliance checking framework that can analyze source code written in different programming languages. The system uses language-agnostic intermediate representations and configurable analyzers that adapt to various programming languages, enabling multi-language project analysis with a single toolchain.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent changes the parameters of analysis by translating source code from different programming languages into a unified intermediate representation. This parameter transformation enables consistent compliance checking across multiple languages by converting diverse syntax and semantics into a common analysis format.

Inventive Principle:

Principle #35Parameter changes

4Reliability

If compliance checking requires all software components to be available in executable form, then thorough testing can be performed, but the process becomes costly and delays development

Engineering Contradiction:

Improvecompliance accuracyVSAvoidtesting accessibility

Core Design Contradiction:

ReliabilityVSEase of manufacture

Solution Approach 1:

The patent replaces the mechanical requirement of compiling and executing software with a static analysis approach. Instead of requiring executable code for testing, the system uses automated source code analysis tools to perform compliance checking, eliminating the need for compilation and execution while maintaining verification accuracy.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS9134976B1Cross-format analysis of software systems

Publication Date: 2015.09.15 QUALCOMM INC

AI summary

In various implementations of a software analysis system, compliance checking is facilitated by analyzing different characteristics of a software system to be developed, and by comparing the information extracted from these analysis. Two or more characteristics may be expressed in different formats or languages, and the descriptions of one or more of these characteristic may be incomplete.