We present and evaluate an automatic tool for extracting algebraic specifications from Java classes. Our tool maps a Java class to an algebraic signature and then uses the signature to generate a large number of terms. The tool evaluates these terms and based on the results of the evaluation, it proposes equations. Finally, the tool generalizes equations to axioms and eliminates many redundant axioms. Since our tool uses dynamic information, it is not guaranteed to be sound or complete. However, we manually inspected the axioms generated in our experiments and found them all to be correct.

We study proof systems for reasoning about logical consequences and refinement of structured specifications, based on similar systems proposed earlier in the literature [ST 88, Wir 91]. Following Goguen and Burstall, the notion of an underlying logical system over which we build specifications is formalized as an institution and extended to a more general notion, called (D, T )-institution. We show that under simple assumptions (essentially: amalgamation and interpolation) the proposed proof systems are sound and complete. The completeness proofs are inspired by proofs due to M. V. Cengarle (see [Cen 94]) for specifications in first-order logic and the logical systems for reasoning about them. We then propose a methodology for reusing proof systems built over institutions rich enough to satisfy the properties required for the completeness results for specifications built over poorer institutions where these properties need not hold.

We present our work on the representation and correctness of program schemas, in the context of logic program synthesis. Whereas most researchers represent schemas purely syntactically as higher-order expressions, we shall express a schema as an open first-order theory that axiomatises a problem domain, called a specification framework, containing an open program that represents the template of the schema. We will show that using our approach we can define a meaningful notion of correctness for schemas, viz. that correct program schemas can be expressed as parametric specification frameworks containing templates that are steadfast, i.e. programs that are always correct provided their open relations are computed correctly.

It can be argued that for (semi-)automated software development, program schemas are indispensable, since they capture not only structured program design principles, but also domain knowledge, both of which are of crucial importance for hierarchical program synthesis. Most researchers represent schemas purely syntactically (as higher-order expressions) . This means that the knowledge captured by a schema is not formalised. We take a semantic approach and show that a schema can be formalised as an open (firstorder) logical theory that contains an open logic program. By using a special kind of correctness for open programs, called steadfastness, we can define and reason about the correctness of schemas. We also show how to use correct schemas to synthesise steadfast programs. 1. Introduction It can be argued that any systematic approach to software development must use some kind of schema-based strategies. In (semi-)automated software development, program schemas become indispensable, s...

. A new treatment of data refinement in typed lambda calculus is proposed, based on pre-logical relations [HS99] rather than logical relations as in [Ten94], and incorporating a constructive element. Constructive data refinement is shown to have desirable properties, and a substantial example of refinement is presented. 1 Introduction Various treatments of data refinement in the context of typed lambda calculus, beginning with Tennent's in [Ten94], have used logical relations to formalize the intuitive notion of refinement. This work has its roots in [Hoa72], which proposes that the correctness of a concrete version of an abstract program be verified using an invariant on the domain of concrete values together with a function mapping concrete values (that satisfy the invariant) to abstract values. In algebraic terms, what is required is a homomorphism from a subalgebra of the concrete algebra to the abstract algebra. A strictly more general method is to take a homomorphic relatio...

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 conditions under which a formal system for reasoning about structural specifications, built over one logical system could be reused for reasoning about structured specifications built over another logical system are formulated and studied. Following Goguen and Burstall, the notion of a logical system is formalized as an institution and extended to a D-institution. A new function between classes of specifications, inspired by a similar function from [HST 94], is defined as a natural extension of institution representations to structured specifications. 1

I propose a formalisation of knowledge sharing scenarios that aims at capturing the crucial role played by an existing duality between ontological theories one wants to merge and particular situations that need to be linked. I use diagrams in the Chu category and colimits over these diagrams to account for the reliability and optimality of knowledge sharing systems. Furthermore, I show how we may obtain a deeper understanding of a system that shares knowledge between a probabilistic logic program and Bayesian belief networks by re-analysing the scenario in terms of the present approach.

Modern programs make extensive use of reusable software libraries. For example, we found that 17 % to 30 % of the classes in a number of large Java applications use the container classes from the java.util package. Given this extensive code reuse in Java programs, it is important for the reusable interfaces to have clear and unambiguous documentation. Unfortunately, most documentation is expressed in English, and therefore does not always satisfy these requirements. Worse yet, there is no way of checking that the documentation is consistent with the associated code. Formal specifications present an alternative which does not suffer from these problems; however, formal specifications are notoriously hard to write. To alleviate this difficulty, we have implemented a tool which automatically derives documentation in the form of formal specifications. Our tool probes Java classes by invoking them on dynamically generated tests and captures the information observed during their execution as algebraic axioms. While the tool is not complete or correct from a formal perspective we demonstrate that it discovers many useful axioms when applied to container classes. These axioms then form an initial formal documentation of the class they describe. 1

In OO Design, it is widely recognised that the distribution of tasks between objects and the contracts between them are key to effective design. In composing designs from reusable parts, the parts are therefore frameworks, namely descriptions of the interactive relationships between objects which participate in the interactions. Designs are then built by composing these frameworks, and any object in the final design will play (various) roles from several frameworks. Practitioners of OO Design use pictorial notations for design. However, in order to reason formally about design, we need a sound (formal) semantics for the diagrams. In this paper, we show that frameworks can be formalised as many-sorted theories, and then present a pictorial representation of such theories, developed in the Catalysis project. 1. Introduction Formal methods for program or system development need to have a good pictorial notation if they are to be adopted by practitioners for real-world work. Such a notati...