An Improved Algorithm for Generating Database Transactions from Relational Algebra Specifications

I. Mackie and A. Martins Moreira (Eds.): Tenth International Workshop on Rule-Based Programming (RULE 2009) EPTCS 21, 2010, pp. 77–89, doi:10.4204/EPTCS.21.7 An Improved Algorithm for Generating Database Transactions from Relational Algebra Specifications Daniel J. Dougherty Worcester Polytechnic Institute Worcester, MA, USA, 01609 dd@wpi.edu 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. 1 Introduction Alloy [5] is a popular modeling language that implements the lightweight formal methods philosophy [6]. Its expressive power is that of first-order logic extended with transitive closure, and its syntax, based on relational algebra, is strongly influenced by object modeling notations. The language is accompanied by the Alloy Analyzer: the analyzer builds models (or “instances”) for a specification using SAT-solving techniques. Users can employ a graphical browser to explore instances and counter-examples to claims. Having written an Alloy specification, the user must then write the corresponding code by hand; consequently there are no formal guarantees that the resulting code has any relationship to the specification. The Alchemy project addresses this issue. Alchemy is a tool under active development [7, 4] at Worcester Polytechnic Institute and Brown University, by Kathi Fisler, Shriram Krishnamurthi, and the author, with our students Theo Giannakopoulos and Daniel Yoo, that compiles Alloy specifications into libraries of database operations. This is not a straightforward enterprise since, in contrast to Z [8] and B [1], where a notion of state machine is built into the language, Alloy does not have a native machine model. Alchemy opens up a new way of working with Alloy specifications: as declarative notations for imperative programs. In this way Alloy models support a novel kind of rule-based programming, in which underspecification is a central aspect of program design. In this note we report on recent progress in improving the process of generating imperative code for declarative specifications in a language like Alloy. This paper is a companion to [4], which developed a better semantic foundation for interpreting Alloy predicates as operations. With this better foundation we are able to generate code for a wider class of predicates than that treated in [7] and also prove a more robust correctness theorem relating the imperative code to the original specification. 2 Alloy and Alchemy Some of the material in this expository section is taken from [7]. 78 An Improved Algorithm for Generating Database Transactions 2.1 An overview of Alloy An excellent introduction to Alloy is Daniel Jackson’s book [5]. Here we start with an informal introduction to Alloy syntax and semantics via an example. The example is a homework submission and grading system, shown in Figure 1. In this system, students may submit work in pairs. The gradebook stores the grade for each student on each submission. Students may be added to or deleted from the system at any time, as they enroll in or drop the course. The system’s data model centers around a course, which has three fields: a roster (set of students), submitted work (relation from enrolled students to submissions), and a gradebook. Alloy uses signatures to capture the sets and relations that comprise a data model. Each sig (Submission, etc.) defines a unary relation. The elements of these relations are called atoms; the type of each atom is its containing relation. Fields of signatures define additional relations. The sig for Course, for example, declares roster to be a relation on Course×Student. Similarly, the relation work is of type Course×Student×Submission, but with the projection on Course and Student restricted to pairs in the roster relation. The lone annotation on gradebook allows at most one grade per submission. The predicates (Enroll, etc.) capture the actions supported in the system. The predicates follow a standard Alloy idiom for stateful operations: each has parameters for the pre- and post-states of the operation (c and c’, respectively), with the intended interpretation that latter reflects a change applied to the former. Alloy facts (such as SameGradeForPair) capture invariants on the models. This particular fact states that students who submit joint work get the same grade. An important aspect of Alloy is that everything is a relation. In particular sets are viewed as unary relations, and individual atoms are viewed as singleton unary relations. As a consequence the in operator does double-duty: it is interpreted formally as

…(Full text truncated)…

This content is AI-processed based on ArXiv data.