Results 1 
6 of
6
Modular Verification of SRT Division
, 1996
"... . We describe a formal specification and mechanized verification in PVS of the general theory of SRT division along with a specific hardware realization of the algorithm. The specification demonstrates how attributes of the PVS language (in particular, predicate subtypes) allow the general theory to ..."
Abstract

Cited by 16 (1 self)
 Add to MetaCart
. We describe a formal specification and mechanized verification in PVS of the general theory of SRT division along with a specific hardware realization of the algorithm. The specification demonstrates how attributes of the PVS language (in particular, predicate subtypes) allow the general theory to be developed in a readable manner that is similar to textbook presentations, while the PVS table construct allows direct specification of the implementation's quotient lookup table. Verification of the derivations in the SRT theory and for the data path and lookup table of the implementation are highly automated and performed for arbitrary, but finite precision; in addition, the theory is verified for general radix, while the implementation is specialized to radix 4. The effectiveness of the automation stems from the tight integration in PVS of rewriting with decision procedures for equality, linear arithmetic over integers and rationals, and propositional logic. This example demonstrates t...
Modular Verification of SRT Division
, 1996
"... . We describe a formal specification and verification in PVS for the general theory of SRT division, and for the hardware design of a specific implementation. The specification demonstrates how attributes of the PVS language (in particular, predicate subtypes) allow the general theory to be deve ..."
Abstract

Cited by 11 (1 self)
 Add to MetaCart
. We describe a formal specification and verification in PVS for the general theory of SRT division, and for the hardware design of a specific implementation. The specification demonstrates how attributes of the PVS language (in particular, predicate subtypes) allow the general theory to be developed in a readable manner that is similar to textbook presentations, while the PVS table construct allows direct specification of the implementation's quotient lookup table. Verification of the derivations in the SRT theory and for the data path and lookup table of the implementation are highly automated and performed for arbitrary, but finite precision; in addition, the theory is verified for general radix, while the implementation is specialized to radix 4. The effectiveness of the automation derives from PVS's tight integration of rewriting with decision procedures for equality, linear arithmetic over integers and rationals, and propositional logic. This example demonstrates t...
Spill  a Logic Language for Writing Testable Requirements Specifications
, 1997
"... A requirements specification is the first formal description of a program. Formal methods of program construction can be practically useful only when the requirements specification can be shown to be adequate. This must be done by informal means: inspection and testing. Current specification languag ..."
Abstract

Cited by 6 (0 self)
 Add to MetaCart
A requirements specification is the first formal description of a program. Formal methods of program construction can be practically useful only when the requirements specification can be shown to be adequate. This must be done by informal means: inspection and testing. Current specification languages do not easily support both inspection and testing. We propose a specification language, Spill, which has been designed with the express purpose of providing such support. Our language is based on the ideas of logic programming, and can be thought of as both an extended and a restricted version of pure Prolog. A specification written in Spill can be read as a declarative, precise description of the properties of the specified object. The description can be used as a starting point in the formal derivation of a program. At the same time the specification is testable  it can be treated as a program that allows the user to test whether the object so described would indeed have the desired ...
Formal requirementsbased programming for complex systems
 In Proc. International Conference on Engineering of Complex Computer Systems
, 2005
"... Computer science as a field has not yet produced a general method to mechanically transform complex computer system requirements into a provably equivalent implementation. Such a method would be one major step towards dealing with complexity in computing, yet it remains the elusive “holy grail ” of ..."
Abstract

Cited by 3 (2 self)
 Add to MetaCart
Computer science as a field has not yet produced a general method to mechanically transform complex computer system requirements into a provably equivalent implementation. Such a method would be one major step towards dealing with complexity in computing, yet it remains the elusive “holy grail ” of system development. Currently available tools and methods that start with a formal model of a system and mechanically produce a provably equivalent implementation are valuable but not sufficient. The “gap” that such tools and methods leave unfilled is that the formal models cannot be proven to be equivalent to the system requirements as originated by the customer. For the classes of complex systems whose behavior can be described as a finite (but significant) set of scenarios, we offer a method for mechanically transforming requirements (expressed in restricted natural language, or appropriate graphical notations) into a provably equivalent formal model that can be used as the basis for code generation and other transformations. While other techniques are available, this method is unique in offering full mathematical tractability while using notations and techniques that are well known and well trusted. We illustrate the application of the method to an example procedure from the Hubble Robotic Servicing Mission currently under study and preliminary formulation at
Pitfalls of Formality in Early System Design
 In Proceedings of the 1998 ARO/NSF Monterey Workshop on Increasing the Practical Impact of Formal Methods for ComputerAided Software Development
, 1998
"... One of the advantages of using formal methods in design should be that we can be precise about where our methods fail. However, it is rare to find discussions in the literature of problems in applying formal methods  particularly in the early stages of design. One reason for this is that failures a ..."
Abstract

Cited by 3 (0 self)
 Add to MetaCart
One of the advantages of using formal methods in design should be that we can be precise about where our methods fail. However, it is rare to find discussions in the literature of problems in applying formal methods  particularly in the early stages of design. One reason for this is that failures are often caused by the context in which a method is applied, rather than by some purely technical limitation. Using examples from research in which I have been involved I shall describe some of the pitfalls I have encountered and which I have observed frequently in the research of others. 1 Introduction Berry, in these proceedings [1], advocates the use of appropriately chosen and applied formal methods in the early stages of design lifecycles  observing factors outside the technical considerations of the methods themselves which influence their success. This paper is complementary to Berry's discussion because it looks at some factors which can lead to failure. It has been unfashionable f...
On Software Certification: We Need ProductFocused Approaches ⋆
"... Abstract. In this paper we begin by examining the “certification ” of a consumer product, a baby walker, that is productfocused, i.e., the certification process requires the performance of precisely defined tests on the product with measurable outcomes. We then review current practices in software ..."
Abstract

Cited by 2 (2 self)
 Add to MetaCart
Abstract. In this paper we begin by examining the “certification ” of a consumer product, a baby walker, that is productfocused, i.e., the certification process requires the performance of precisely defined tests on the product with measurable outcomes. We then review current practices in software certification and contrast the software regime’s processoriented approach to certification with the productoriented approach typically used in other engineering disciplines. We make the case that productfocused certification is required to produce reliable software intensive systems. These techniques will have to be domain and even product specific to succeed. 1