Determining the Cause of a Design Model Inconsistency

Abstract

When a software engineer finds an inconsistency in a model, then the first question is why? What caused it? Obviously, there must be an error. But where could it be? Or is the design rule erroneous and if yes then which part? The cause of an inconsistency identifies the part of the model or design rule where the error must be. We believe that the visualization of an inconsistency ought to visualize the cause. Understanding the cause is of vital importance before a repair can even be formulated. Indeed, any automation (e.g., code generation, refactoring) has to be considered with caution if it involves model elements that cause inconsistencies. This paper analyzes the basic structure of inconsistent design rules as well as their behavior during validation and presents an algorithm for computing its cause. The approach is fully automated, tool supported, and was evaluated on 14,111 inconsistencies across 29 design models. We found that our approach computes correct causes for inconsistencies, these causes are nearly always a subset of the model elements investigated by the design rules' validation (a naive cause computation approximation), and the computation is very fast (99.8 percent of the causes are computable in <100 ms).

Towards Validation of UML Design Model

“…This section provides validation of some design rules given in [4]. For validation, the rules are first converted into predicate logic form following the approach of [2].…”

“…In [4], focus is on the finding the cause for a design model inconsistency. It is determined by validation of a design rule and design model both.…”

Cyber-physical specification mismatch identification with dynamic analysis

“…Cyberphysical specification mismatch is closely related to model inconsistency [32], architectural mismatch [33], and requirements consistency [34]. There are many benefits of dynamic analysis such as using implementations instead of models [3,4,31] to find dynamic program specifications [31], such as providing documentation over program evolution, checking if specifications change drastically over program evolution, etc.…”

Tracking down root causes of defects in simulink models

“…Otherwise, long paths would dominate the calculation. Consider the example model in Figure 2 and (6).…”

“…The difference between the failing and the passing test cases shall be minimal since this difference is declared to be the root cause for the failure. Another approach to determine root causes is presented in [6]. The authors describe the cause of an UNSAT part as the union of all minimal unsatisfiable subsets (MUS).…”