Debugging Of Specifications Research Articles

Formal Requirement Debugging for Testing and Verification of Cyber-Physical Systems

A framework for the elicitation and debugging of formal specifications for Cyber-Physical Systems is presented. The elicitation of specifications is handled through a graphical interface. Two debugging algorithms are presented. The first checks for erroneous or incomplete temporal logic specifications without considering the system. The second can be utilized for the analysis of reactive requirements with respect to system test traces. The specification debugging framework is applied on a number of formal specifications collected through a user study. The user study establishes that requirement errors are common and that the debugging framework can resolve many insidious specification errors.

Low-Effort Specification Debugging and Analysis

Reactive synthesis deals with the automated construction of implementations of reactive systems from their specifications. To make the approach feasible in practice, systems engineers need effective and efficient means of debugging these specifications. In this paper, we provide techniques for report-based specification debugging, wherein salient properties of a specification are analyzed, and the result presented to the user in the form of a report. This provides a low-effort way to debug specifications, complementing high-effort techniques including the simulation of synthesized implementations. We demonstrate the usefulness of our report-based specification debugging toolkit by providing examples in the context of generalized reactivity(1) synthesis.

Slicing communicating automata specifications: polynomial algorithms for model reduction

Abstract In the industry, communicating automata specifications are mainly used in fields where the reliability requirements are high, as this formalism allow the use of powerful validation tools. Still, on large scale industrial specifications, formal methods suffer from the combinatorial explosion phenomenon. In our contribution, we suggest to try to bypass this phenomenon, in applying slicing techniques preliminarily to the targeted complex analysis. This analysis can thus be performed a posteriori on a reduced (or sliced ) specification, which is potentially less exposed to combinatorial explosion. The slicing method is based on dependence relations, defined on the specification under analysis, and is mainly founded on the literature on compiler construction and program slicing. A theoretical framework is described, for static analyses of communicating automata specifications. This includes formal definitions for the aforementioned dependence relations, and for a slice of a specification with respect to a slicing criterion . Efficient algorithms are also described in detail, for calculating dependence relations and specification slices. Each of these algorithms has been shown to be polynomial, and sound and complete with respect to its respective definition. These algorithms have also been implemented in a slicing tool, named C arver , that has shown to be operational in specification debugging and understanding. The experimental results obtained in model reduction with this tool are promising, notably in the area of formal validation and verification methods, e.g.model checking, test case generation.

An Eclipse-based Integrated Environment for Developing Executable Structural Operational Semantics Specifications

The Structural Operational Semantics Development Tooling (SOSDT) Eclipse Plugin integrates the Relational Meta-Language (RML) compiler and debugger with the Eclipse Integrated Development Environment Framework. SOSDT, together with the RML compiler and debugger, provides an environment for developing and maintaining executable Structural Operational Semantics specifications, including the Natural Semantics big step variant of SOS specifications. The RML language is successfully used at our department for writing large specifications for a range of languages like Java, Modelica, Pascal, MiniML etc. The SOSDT environment includes support for browsing, code completion through menus or popups, code checking, automatic indentation, and debugging of specifications.

Debugging high‐performance component‐based applications

AbstractComponent frameworks for high‐performance computing (HPC) have special requirements that distinguish them from general component frameworks and other traditional/monolithic codes. HPC component‐based applications have a crucial need for correct, high‐performance execution across a variety of open‐source and proprietary component compositions, potentially incorporating several different programming languages. This paper targets the unique challenges associated with debugging HPC component‐based applications in the Common Component Architecture (CCA). We propose to take advantage of the well‐defined code separation created by component interfaces or ‘ports’ by logging port method invocations and capturing the corresponding data arguments. This approach makes it possible to find and isolate faulty components, simulate their invocation for specific debugging analyses, check data argument validity and boundaries, and create inputs for black‐box testing. Published in 2006 by John Wiley & Sons, Ltd.

Tracing Prolog programs by source instrumentation is efficient enough

Tracing by automatic program source instrumentation has major advantages over compiled code instrumentation: it is more portable from one Prolog system to another, it produces traces in terms of the original program, and it can be tailored to specific debugging needs. The main argument usually put forward in favor of compiled code instrumentation is its supposed efficiency. We have compared the performances of two operational low-level Prolog tracers with source instrumentation. We have executed classical Prolog benchmark programs, collecting trace information without displaying it. On average, collecting trace information by program instrumentation is about as fast as using a low-level tracer in one case, and only twice slower in the other. This is a minor penalty to pay, compared to the advantages of the approach. To our knowledge, this is the first time that a quantitative comparison of both approaches is made for any programming language.

A METHOD FOR REQUIREMENTS ANALYSIS AND KNOWLEDGE ELICITATION

Requirements analysis is a knowledge intensive task and it requires an expert to understand what the clients need. In this paper, we introduce a method which contains different artificial intelligence techniques to perform this task, and a prototype knowledge-based requirements analysis system, RAKES, is presented to explain our approach. In this approach, not only the ordinary functional requirements are collected, but also some non-traditional information, such as non-functional requirements like the quality of operations or the background information for constructing the requirements, is gathered through a knowledge-based support. Different kinds of information collected are stored and organized in a knowledge base and can be used as the source of the user input in the latter phases of software development. Algorithms and procedures have been developed for constructing the interface language, organizing the knowledge base, and applying the knowledge base to different tasks. RAKES is integrated to an on-going research, called the FRORL methodology, to offer a systematic way toward requirements analysis, specification production, prototype generation, specification debugging, and code transformation.

DEBUGGING LOGIC-BASED REQUIREMENTS SPECIFICATIONS FOR SAFETY-CRITICAL SYSTEMS — A FRORL APPROACH

Safety-critical systems are not only difficult to build, but also difficult to debug because they often have strict timing constraints and non-deterministic behavior. A correct and precise specification reduces the effort spent in testing and debugging the implemented system. This paper presents techniques of specification debugging and issues related to it. We introduce an approach to the debugging of a specification in FRORL (Frame and Rule Oriented Requirements Language), which supports non-determinism and non-monotonicity in a system. The approach aids the user in detecting and correcting the possible faults which can arise not only when writing the specification, but also after the verification of the specification.

Critiquing software specifications

The authors describe how the knowledge of expert-systems analysts is being input to use in an automated critic for specification debugging. They are working on a system, named Kate, that tries to acquire a problem specification that includes a description of the objects, transitions (actions), and constraints of the intended system. They have built a computer-based critic as part of the Kate environment that has its roots in a set of protocols they collected over several analysis sessions. The critic has three major components: a model of the domain, a matcher to connect parts of the model to the specification being analyzed, and a critique to supply the analysis. The model represents a set of policy issues for building systems in a particular domain and a set of relevant problem specification cases to consider for systems in the domain. The critic has been run on a library database problem. The results are presented and compared with a critique by an experienced library analyst.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>