Abstract not found

The main ideas underlying work on the model-theoretic foundations of algebraic specification and formal program development are presented in an informal way. An attempt is made to offer an overall view, rather than new results, and to focus on the basic motivation behind the technicalities presented elsewhere.

An overview of past, present and future work on the Extended ML formal program development framework is given, with emphasis on two topics of current active research: the semantics of the Extended ML specification language, and tools to support formal program development.

One of the most novel features of Casl, the Common Algebraic Specification Language, is the provision of so-called architectural specifications for describing the modular structure of software systems. A brief discussion of refinement of Casl specifications provides the setting for a presentation of the rationale behind architectural specifications. This is followed by some details of the features provided in Casl for architectural specifications, hints concerning their semantics, and simple results justifying their usefulness in the development process.

The Curry--Howard isomorphism, a fundamental property shared by many type theories, establishes a direct correspondence between programs and proofs. This suggests that the same structuring principles that ease programming be used to simplify proving as well. To exploit object-oriented structuring mechanisms for verification, we extend the object-model of Pierce and Turner, based on the higher order typed -calculus F ! , with a proof component. By enriching the (functional) signature of objects with a specification, the methods and their correctness proofs are packed together in the objects. The uniform treatment of methods and proofs gives rise in a natural way to object-oriented proving principles --- including inheritance of proofs, late binding of proofs, and encapsulation of proofs --- as analogues to object-oriented programming principles. We have used Lego, a type-theoretic proof checker, to explore the feasibility of this approach. In particular, we have verified a small hier...

Abstract not found

this report may apply, should support following activities: 1. formulation of a requirement (e.g., total correctness statement, or algebraic specification, or process logic formula), 2. description of a construction (e.g. resp., imperative program, or algebra, or process), 3. verification that a given construction satisfies a given requirement. The verification step 3 above cannot, for any realistic classes of requirements and constructions, be fully automated. Therefore, it generates a proof obligation that may be either proven by hand, or passed over to a heuristic theorem prover, or left unproven but recorded in the construction's documentation for future reference, in case something goes wrong. But then, it is acceptable that the steps 1 and 2 generate proof obligations as well. For instance, an attempt to automatically type check a construction might break down at some point, in which case the type checker would generate a proof obligation for that point and then proceed as if everything worked well. It is important that the number and the complexity of generated proof obligations be kept within reasonable limits. In particular, no proof obligations should be generated where no dependent types and no subtypes are involved. This report presents a simple but powerful language SDDP

Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.5.4 Special Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.6 Semantics of Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6.1 Semantics of Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6.2 Action Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.7 Specification Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.7.1 Early Algebraic Specification Languages . . . . . . . . . . . . . . . . . . . . . . . . 53 4.7.2 Recent Algebraic Specification Languages . . . . . . . . . . . . . . . . . . . . . . . 55 4.7.3 The Common Framework Initiative. . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5 Methodology 57 5.1 Development Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1.1 Applica...