06191 Abstracts Collection -- Rigorous Methods for Software Construction and Analysis

From 07.05.06 to 12.05.06, the Dagstuhl Seminar 06191 ``Rigorous Methods for Software Construction and Analysis\u27\u27 was held in the International Conference and Research Center (IBFI), Schloss Dagstuhl. During the seminar, several participants presented their current research, and ongoing work and open problems were discussed. Abstracts of the presentations given during the seminar as well as abstracts of seminar results and ideas are put together in this paper. The first section describes the seminar topics and goals in general. Links to extended abstracts or full papers are provided, if available

Event-B patterns and their tool support

Event-B has given developers the opportunity to construct models of complex systems that are correct-by-construction. However, there is no systematic approach, especially in terms of reuse, which could help with the construction of these models. We introduce the notion of design patterns within the framework of Event-B to shorten this gap. Our approach preserves the correctness of the models, which is critical in formal methods and also reduces the proving effort. Within our approach, an Event-B design pattern is just another model devoted to the formalisation of a typical sub-problem. As a result, we can use patterns to construct a model which can subsequently be used as a pattern to construct a larger model. We also present the interaction between developers and the tool support within the associated RODIN Platform of Event-B. The approach has been applied successfully to some medium-size industrial case studie

Rodin: an open toolset for modelling and reasoning in Event-B

Event-B is a formal method for system-level modelling and analysis. Key features of Event-B are the use of set theory as a modelling notation, the use of refinement to represent systems at different abstraction levels and the use of mathematical proof to verify consistency between refinement levels. In this article we present the Rodin modelling tool that seamlessly integrates modelling and proving. We outline how the Event-B language was designed to facilitate proof and how the tool has been designed to support changes to models while minimising the impact of changes on existing proofs. We outline the important features of the prover architecture and explain how well-definedness is treated. The tool is extensible and configurable so that it can be adapted more easily to different application domains and development methods

An Improved Algorithm for Generating Database Transactions from Relational Algebra Specifications

Alloy is a lightweight modeling formalism based on relational algebra. In prior work with Fisler, Giannakopoulos, Krishnamurthi, and Yoo, we have presented a tool, Alchemy, that compiles Alloy specifications into implementations that execute against persistent databases. The foundation of Alchemy is an algorithm for rewriting relational algebra formulas into code for database transactions. In this paper we report on recent progress in improving the robustness and efficiency of this transformation

Towards Symbolic Model-Based Mutation Testing: Combining Reachability and Refinement Checking

Model-based mutation testing uses altered test models to derive test cases that are able to reveal whether a modelled fault has been implemented. This requires conformance checking between the original and the mutated model. This paper presents an approach for symbolic conformance checking of action systems, which are well-suited to specify reactive systems. We also consider nondeterminism in our models. Hence, we do not check for equivalence, but for refinement. We encode the transition relation as well as the conformance relation as a constraint satisfaction problem and use a constraint solver in our reachability and refinement checking algorithms. Explicit conformance checking techniques often face state space explosion. First experimental evaluations show that our approach has potential to outperform explicit conformance checkers.Comment: In Proceedings MBT 2012, arXiv:1202.582

Automatically Comparing Memory Consistency Models

A memory consistency model (MCM) is the part of a programming language or computer architecture specification that defines which values can legally be read from shared memory locations. Because MCMs take into account various optimisations employed by archi- tectures and compilers, they are often complex and counterintu- itive, which makes them challenging to design and to understand. We identify four tasks involved in designing and understanding MCMs: generating conformance tests, distinguishing two MCMs, checking compiler optimisations, and checking compiler mappings. We show that all four tasks are instances of a general constraint-satisfaction problem to which the solution is either a program or a pair of programs. Although this problem is intractable for automatic solvers when phrased over programs directly, we show how to solve analogous constraints over program executions, and then construct programs that satisfy the original constraints. Our technique, which is implemented in the Alloy modelling framework, is illustrated on several software- and architecture-level MCMs, both axiomatically and operationally defined. We automatically recreate several known results, often in a simpler form, including: distinctions between variants of the C11 MCM; a failure of the ‘SC-DRF guarantee’ in an early C11 draft; that x86 is ‘multi-copy atomic’ and Power is not; bugs in common C11 compiler optimisations; and bugs in a compiler mapping from OpenCL to AMD-style GPUs. We also use our technique to develop and validate a new MCM for NVIDIA GPUs that supports a natural mapping from OpenCL

Refinement, Decomposition and Instantiation of Discrete Models

MODEL ABSTRACT CONTEXT CONCRETE MODEL CONCRETE CONTEXT M C D N Fig. 3. Model and Context Refinements Variables Invariants Events Sets Constants Properties sees refines ABSTRACT MODEL ABSTRACT CONTEXT CONCRETE MODEL M C N Variables Invariants Events sees Fig. 4. Special Case of Model and Context Refinements 25 The situation is not the same when refining models. The concrete model N (which supposedly "sees" concrete context D) has a collection of state variables w, which must be completely distinct (in first approximation) from the collection v of variables in the abstraction M. Model N also has an invariant dealing with these variables w. But contrarily to the case of abstract model M where the invariant exclusively depended on the local variables of this model, this time it is possible to have the invariant of N also depending on the variables v of its abstraction M. This is the reason why we collectively name this invariant of N the gluing invariant J(s, t, c, d, v, w): it "glues" the state of the concrete model N to that of its abstraction M. 4.2 Refinement of Existing Events The new model N has a number of events. For the moment, each event in the concrete model N is supposed to refine a certain event in its abstraction M. Suppose we have an abstract event with guard G(s, c, v) and before-after predicate R(s, c, v, v # ) and a corresponding concrete event with guard H(s, t, c, d, w) and before-after predicate S(s, t, c, d, w, w # ). The latter is said to refine the former if the following holds: v # ( R(s, c, v, v # ) J(s, t, c, d, v # , w # ) ) 4.3 Introducing New Events in a Refinement New events can be introduced in a refinement. In this case, the refinement mechanism is slightly different from the previous o..