Hierarchical correctness proofs for distributed algorithms

Lynch, Nancy; Tuttle, Mark R.

doi:10.1145/41840.41852

Cited by 587 publications

(319 citation statements)

References 19 publications

(1 reference statement)

Supporting

Mentioning

315

Contrasting

Unclassified

Order By: Relevance

“…In figure 2, the input f is only accepted in state 0, but not in any other states. This is opposed to other automata-based formalisms, such as I/O automata [11], where every input must be enabled at every state. By not requiring the model to be input enabled, interface automata models are usually more concise, and do not include states that model error conditions.…”

Section: An Examplementioning

confidence: 99%

System-Level Types for Component-Based Design

Lee

Xiong

2001

Embedded Software

View full text Add to dashboard Cite

Abstract. We present a framework to extend the concept of type systems in programming languages to capture the dynamic interaction in component-based design, such as the communication protocols between components. In our system, the interaction types and the dynamic behavior of components are defined using interface automata -an automata-based formalism. Type checking, which checks the compatibility of a component with a certain interaction type, is conducted through automata composition. Our type system is polymorphic in that a component may be compatible with more than one interaction type. We show that a subtyping relation exists among various interaction types and this relation can be described using a partial order. This system-level type order can be used to facilitate the design of polymorphic components and simplify type checking. In addition to static type checking, we also propose to extend the use of interface automata to the on-line reflection of component states and to run-time type checking. We illustrate our framework using a component-based design environment, Ptolemy II, and discuss the trade-offs in the design of system-level type systems.

show abstract

Section: An Examplementioning

confidence: 99%

System-Level Types for Component-Based Design

Lee

Xiong

2001

Embedded Software

View full text Add to dashboard Cite

show abstract

“…The model is a simplified version of the I/O automata model [10,11]: it does not deal with fairness or other forms of liveness and there is no distinction between input and output actions. In this section we review some basic definitions and results concerning automata and simulation proof techniques.…”

Section: Labeled Transition Systems and Simulationsmentioning

confidence: 99%

“…In Figure 1, the algorithm is specified as an automaton SUM using the standard precondition/effect style of the I/O automata model [10,11,4]. A minor subtlety is the occurrence of the variable v in the definition of the step relation, which is neither a state variable nor a formal parameter of the actions.…”

Section: Description Of the Algorithmmentioning

confidence: 99%

Verification of a distributed summation algorithm

Vaandrager

1995

CONCUR '95: Concurrency Theory

View full text Add to dashboard Cite

“…Second, simulation implies trace containment, whose checking for nondeterministic specifications is PSPACE-complete [Meyer and Stockmeyer, 1972]. The computational advantage is so compelling as to make simulation useful also to researchers that favor the linear approach to specification: in automatic verification, simulation is widely used as a sufficient condition for trace containment [Cleaveland et al, 1993]; in manual verification, trace containment is most naturally proved by exhibiting local witnesses such as simulation relations or refinement mappings (a restricted form of simulation relations) [Lamport, 1983;Lynch and Tuttle, 1987;Lynch, 1996].…”

Section: Introductionmentioning

confidence: 99%

Coverage of Implementations by Simulating Specifications

Chockler

Kupferman

2002

Foundations of Information Technology in the Era of Network and Mobile Computing

View full text Add to dashboard Cite

In formal verification, we verify that an implementation is correct with respect to a specification. When verification succeeds and the implementation is proven to be correct, there is still a question of how complete the specification is, and whether it really covers all the behaviors of the implementation. In this paper we study coverage for simulation-based formal verification, where both the implementation and the specification are modelled by labeled state-transition graphs, and an implementation I satisfies a specificationS if S simulates I. Our measure of coverage is based on small modifications we apply to I. A part of I is covered by S if the mutant implementation in which this part is modified is no longer simulated by S. Thus, "mutation coverage" tells us which parts of the implementation were actually essential for the success of the verification. We describe two algorithms for finding the parts of the implementation that are covered by S. The first algorithm improves a naive algorithm that checks the mutant implementations one by one by exploiting the significant overlaps among the mutant implementations. The second algorithm is symbolic, and it improves a naive symbolic algorithm by reducing the number of variables in the OBDDs involved. In addition, we compare our coverage measure with other approaches for measuring coverage.

show abstract

Hierarchical correctness proofs for distributed algorithms

Cited by 587 publications

References 19 publications

System-Level Types for Component-Based Design

System-Level Types for Component-Based Design

Verification of a distributed summation algorithm

Coverage of Implementations by Simulating Specifications

Contact Info

Product

Resources

About