Using Analysis Patterns to Uncover Specification Errors (original) (raw)

Automatically Detecting Inconsistencies in Program Specifications

Lecture Notes in Computer Science, 2013

A verification system relies on a programmer writing mathematically precise descriptions of code. A specification that describes the behavior of an operation and a loop invariant for iterative code are examples of such mathematical formalizations. Due to human errors, logical defects may be introduced into these mathematical constructs. Techniques to detect certain logical errors in program specifications, loop invariants, and loop variants are described. Additionally, to make program specifications more concise and to make it easier to create them, RESOLVE has parameter modes: each formal parameter is annotated with a mode that is related to the intended roles of the incoming and outgoing values of that parameter. Methods to check whether the programmer has chosen a plausibly correct mode for each parameter are also explained. The techniques described are lightweight and are applied at an early stage in the verification process.

Using Abstraction and Model Checking to Detect Safety Violations in Requirements Specifications

Software …, 1998

Exposing inconsistencies can uncover many defects in software specifications. One approach to exposing inconsistencies analyzes two redundant specifications, one operational and the other property-based, and reports discrepancies. This paper describes a "practical" formal method, based on this approach and the SCR (Software Cost Reduction) tabular notation, that can expose inconsistencies in software requirements specifications. Because users of the method do not need advanced mathematical training or theorem proving skills, most software developers should be able to apply the method without extraordinary effort. This paper also describes an application of the method which exposed a safety violation in the contractor-produced software requirements specification of a sizable, safety-critical control system. Because the enormous state space of specifications of practical software usually renders direct analysis impractical, a common approach is to apply abstraction to the specification. To reduce the state space of the control system specification, two "pushbutton" abstraction methods were applied, one which automatically removes irrelevant variables and a second which replaces the large, possibly infinite, type sets of certain variables with smaller type sets. Analyzing the reduced specification with the model checker Spin uncovered a possible safety violation. Simulation demonstrated that the safety violation was not spurious but an actual defect in the original specification.

An Automated Approach to Specification-Based Program Inspection

2005

In this paper, we describe how formal specification is adopted to improve the commonly used verification and validation technique known as program inspection, in order to establish a more rigorous, repeatable, and efficient inspection process than the conventional practice. We present a systematic approach to inspecting program code on the basis of the relation between functional scenarios defined in a specification and execution paths implemented in its program. We report a prototype tool for the approach to support both forward and backward inspection strategies, and a case study of inspecting an Automatic Teller Machine system to evaluate the performance of the approach and the tool.

Diagnosing and correcting design inconsistencies in source code with logical abduction

Science of Computer Programming, 2011

Correcting design decay in source code is not a trivial task. Diagnosing and subsequently correcting inconsistencies between a software systems's code and its design rules (e.g., database queries are only allowed in the persistence layer) and coding conventions can be complex, time-consuming and error-prone. Providing support for this process is therefore highly desirable, but of a far greater complexity than suggesting basic corrective actions for simplistic implementation problems (like the "declare a local variable for non-declared variable" suggested by Eclipse).

A Technique for Analyzing the Effects of Changes in Formal Specifications

The Computer Journal, 1992

Formal specifications are increasingly used in modeling software systems. An important aspect of a model is its value as an analytical tool to investigate the effect of changes. This paper defines the notion of predicate differences and shows how predicate differences may be used to analyze the effects of changes in formal specifications. Predicate differences have both theoretical and practical applications. As a theoretical tool, predicate differences may be used to define a meaning for the 'size' of a change to a formal specification. Practical applications include analyzing the effect of design changes on a previously verified design; defining an affinity function for reusable software components; computing slices of formal specifications, similar to program slices; investigating the conditions under which invalid assumptions will render a system non-secure; and formalizing the database inference problem.

Automated consistency checking of requirements specifications

ACM Transactions on Software Engineering and Methodology, 1996

This article describes a formal analysis technique, called consistency checking, for automatic detection of errors, such as type errors, nondeterminism, missing cases, and circular definitions, in requirements specifications. The technique is designed to analyze requirements specifications expressed in the SCR (Software Cost Reduction) tabular notation. As background, the SCR approach to specifying requirements is reviewed. To provide a formal semantics for the SCR notation and a foundation for consistency checking, a formal requirements model is introduced; the model represents a software system as a finite-state automaton, which produces externally visible outputs in response to changes in monitored environmental quantities. Results of two experiments are presented which evaluated the utility and scalability of our technique for consistency checking in a real-world avionics application. The role of consistency checking during the requirements phase of software development is discussed.

Tool-Assisted Multi-Facet Analysis of Formal Specifications (Using Alelier-B and ProB)

2009

Tool-assisted analysis of software systems and convenient guides to practise the formal methods are still motivating challenges. This paper addresses these challenges and shows using a case study that one can increase the quality of the software by analysing from multiple aspects a formal specification. The B method and the Atelier-B tool are used for formal specifications, for safety property analysis and for refinements. The ProB tool is used to supplement the study with model checking; it helps to discover errors and therefore to improve the former specifications.

Diagnosis and semi-automatic correction of detected design inconsistencies in source code

Proceedings of the International Workshop on Smalltalk Technologies - IWST '09, 2009

In order to alleviate design decay, different program design documentation techniques are used for the specification and detection of design inconsistencies in code. However, these design documentation techniques do not always provide support for the diagnosis and (semi-) automatic correction of such inconsistencies. In case they do, corrective solutions are typically targeted to a reduced set of pre-defined inconsistency problems, and they are not easily customizable to new kinds of consistency checks defined by a user. In particular, they cannot infer possible corrective actions to solve new user-defined inconsistency problems. In this paper, we present a technique for the diagnosis and (semi-) automatic correction of inconsistencies in the context of an existing tool for inconsistency management: IntensiVE. Our technique uses logic abductive reasoning to infer solutions to detected user-defined inconsistencies, starting from basic composable corrective actions. A first prototype implementing our technique on top of IntensiVE is shown.

A formal language and analysis tool for black box specifications

Journal of Computing Sciences in Colleges, 2009

The black box specification, developed by Harlan Mills, addresses the problem of software errors that result from failing to properly specify a response for an input scenario. Each black box models how an artifact responds to a particular input from its environment. This response depends on both the current input and the entire history of interactions it has had with the environment. We have observed that students find the black box concept useful and comprehensible, but tedious and error-prone as well. In order to enhance the utility and accessibility of this technique, we have developed a formal specification language and analysis tool for black box specifications. The analysis tool verifies whether a black box is a well-formed specification. To this end, it ensures that a response is specified for every possible combination of inputs from the environment, that every condition is logically disjoint with every other condition in the specification, and that every condition in the sp...

Automated Error-Detection and Repair for Compositional Software Specifications

Lecture Notes in Computer Science, 2014

The complexity of error diagnosis in requirements specifications, already high, is increased when requirements refer to various system components, on whose interaction the system's aims depend. Further, finding causes of error, and ways of overcoming them, cannot easily be achieved without a systematic methodology. This has led researchers to explore the combined use of verification and machine-learning to support automated software analysis and repair. However, existing approaches have been limited by using formalisms in which modularity and compositionality cannot be explicitly expressed. In this paper we overcome this limitation. We define a translation from a representative process algebra, Finite State Processes, into the action language C+. This enables forms of verification not supported by previous methods. We then use a logicprogramming equivalent of C+, to which we apply inductive logic programming for learning repairs to system components while ensuring no new errors are introduced and interactions with other components are maintained. These two phases are iterated until a correct specification is reached, enabling rigorous and scalable support for automated analysis and repair of component-based specifications.