Electronic commerce is emerging as one of the major Websupported applications requiring database support. We introduce and study high-level declarative specifications of business models, using an approach in the spirit of active databases. More precisely, business models are specified as relational transducers that map sequences of input relations into sequences of output relations. The semantically meaningful trace of an input-output exchange is kept as a sequence of log relations. We consider problems motivated by electronic commerce applications, such as log validation, verifying temporal properties of transducers, and comparing two relational transducers. Positive results are obtained for a restricted class of relational transducers called Spocus transducers (for semi-positive outputs and cumulative state). We argue that despite the restrictions, these capture a wide range of practically significant business models. 1 Introduction Electronic commerce is emerging as a major Web-s...

Transputer compilation In this section we define the compilation to Transputer instructions which still uses abstract auxiliary OCCAM daemon functions. We proceed stepwise, defining for each Occam statement S the value of compile together with the TRANSPUTER ground rules for the execution of the code. Each time we show that this implements correctly the semantics of S as compiled to and executed in OCCAM daemon . Declarations The compilation of variable declarations remains the same as in OCCAM daemon . For the channel declarations (see subsection 4.3.) we have to compile the pseudo instruction init chan for the initialization of channels to nil. This is realized by first loading nil into the register Areg (using the MINT instruction) and then storing it from there to the channel (using the local storing instruction STL) with appropriate address: compile(CHAN id 1 ; : : : ; id r : S; e; m;x) = compile(init chan( ~ id); e 0 ; m;x); compile(S; e 0 ; m+ r; x) where ~ i...

We give an evolving algebra solution for the well-known railroad crossing problem and use the occasion to experiment with agents that perform instantaneous actions in continuous time and in particular with agents that fire at the moment they are enabled. 1 Introduction The well-known railroad crossing problem has been used as an example for comparing various specification and validation methodologies; see for example [6, 7] and the relevant references there. The evolving algebras (EA) methodology has been used extensively for specification and validation for real-world software and hardware systems; see the EA guide [3] and the EA bibliography [1]. The merits of using "toy" problems as benchmarks are debatable; not every methodology scales well to real-world problems. Still, toy problems are appropriate for experimentation. Here we present an evolving algebra solution for the railway crossing problem and use the opportunity for experimentation with instantaneous actions and reactions ...

The Abstract State Machine Language, AsmL, is a novel executable specification language based on the theory of Abstract State Machines. AsmL is object-oriented, provides high-level mathematical data-structures, and is built around the notion of synchronous updates and finite choice. AsmL is fully integrated into the .NET framework and Microsoft development tools. In this paper, we explain the design rationale of AsmL and provide static and dynamic semantics for a kernel of the language.

We describe a method for rigorously specifying and verifying the control of pipelined microprocessors which can be used by the hardware designer for a precise documentation and justification of the correctness of his design techniques. We proceed by successively refining a one-instruction-at-a-time-view of a RISC processor to a description of its pipelined implementation; the structure of the refinement hierarchy is determined by standard instruction pipelining principles (grouped following the kind of conflict they are designed to avoid: structural hazards, data hazards and control hazards). We illustrate our approach through a formal specification with correctness proof of Hennessy and Patterson's RISC processor DLX but the method can be extended to complex commercial microprocessor design where traditional or purely automatic methods do not scale up. The specification method supports incremental design techniques; the modular proof method offers reusing proofs and supports the designer's intuitive reasoning.

We present a design approach which allows us to formally specify a real--life processor as composed out of its basic architectural (formally specified) components. The methodology provides means to rely upon hierarchical refinements and modular structuring of the specifications as a discipline to control the behaviour of complex units in terms of the behaviour of their components. In particular this enables us to prove interesting dynamic properties about the processor in terms of properties of its basic architectural components. We have developed the method to accomplish a reverse engineering project for the VLSI implemented microprocessor zCPU, the controller of the successful APE100 massively parallel machine. 1

Abstract. Church’s Thesis asserts that the only numeric functions that can be calculated by effective means are the recursive ones, which are the same, extensionally, as the Turingcomputable numeric functions. The Abstract State Machine Theorem states that every classical algorithm is behaviorally equivalent to an abstract state machine. This theorem presupposes three natural postulates about algorithmic computation. Here, we show that augmenting those postulates with an additional requirement regarding basic operations gives a natural axiomatization of computability and a proof of Church’s Thesis, as Gödel and others suggested may be possible. In a similar way, but with a different set of basic operations, one can prove Turing’s Thesis, characterizing the effective string functions, and—in particular—the effectively-computable functions on string representations of numbers.

Abstract not found

Abstract—In some distributed and mobile communication models, a message disappears in one place and miraculously appears in another. In reality, of course, there are no miracles. A message goes from one network to another; it can be lost or corrupted in the process. Here, we present a realistic but high-level communication model where abstract communicators represent various nets and subnets. The model was originally developed in the process of specifying a particular network architecture, namely, the Universal Plug and Play architecture. But, it is general. Our contention is that every message-based distributed system, properly abstracted, gives rise to a specialization of our abstract communication model. The purpose of the abstract communication model is not to design a new kind of network; rather, it is to discover the common part of all message-based communication networks. The generality of the model has been confirmed by its successful reuse for very different distributed architectures. The model is based on distributed abstract state machines. It is implemented in the specification language AsmL and is used for testing distributed systems. Index Terms—Abstract state machines, communication protocols, computer networks, distributed systems, requirement specification, system modeling, testing of distributed systems. æ

We describe a technique for specifying and verifying the control of pipelined microprocessors which can be used where traditional or purely automatic methods do not scale up to complex commercial microprocessor design. We illustrate our approach through a formal specification of Hennessy's and Patterson's RISC processor DLX [HP90] for which we prove the correctness of its pipelined model with respect to the sequential model. First we concentrate our attention on the provably correct refinement of the sequential ground model DLX to the pipelined parallel version DLX p in which structural hazards (resource conflicts) are eliminated. Then we extend the result to the model DLX data in which also data hazards for not jump instructions are treated. The next step consists of building the model DLX ctrl in which control hazards are eliminated. In the last step we define DLX pipe and prove that it refines DLX ctrl correctly and takes care also of data hazards relative to jump instruct...