The Knowledge Acquisition and Representation Language (KARL) combines a description of a knowledge-based system at the conceptual level (a so-called model of expertise) with a description at a formal and executable level. Thus, KARL allows the precise and unique specification of the functionality of a knowledge-based system independent of any implementation details. A KARL model of expertise contains the description of domain knowledge, inference knowledge, and procedural control knowledge. For capturing these different types of knowledge KARL provides corresponding modeling primitives based on Frame-logic and Dynamic Logic. A declarative semantics for a complete KARL model of expertise is given by a novel combination of these two types of logic. In addition, an operational definition of this semantics, which relies on a fixpoint approach, is given. This operational semantics defines the basis for the implementation of the KARL interpreter which includes appropriate algorithms for efficiently executing KARL specifications. This enables the evaluation of KARL specifications by means of testing. 1

ion of the Specification Borrowing a saying of Einstein's, I maintain that specifications should be as abstract as possible, but not more abstract. I see three limitations to the degree of abstraction. First, a specification as an adequate formalization of the requirements cannot be more abstract than the requirements themselves. If a specific algorithm is required, this algorithm must be specified. This argument applies as well to non-functional requirements constraining possible implementations. Some constraints can appear as comments in specifications, e.g. the requirement that a specific language should be used for the implementation. Other constraints, however, must be concretely specified, e.g. the requirement that the future software system has to adhere to the data structures of a given interface. The second limitation to abstraction arises when we make formal specifications executable. Even if the degree of abstraction of the data structures and the algorithms stays the same,...

. This paper provides an overview of the OCML modelling language: it illustrates the underlying philosophy, describes the main modelling constructs provided, and compares it to other modelling languages. 1. INTRODUCTION OCML 1 was originally developed in the context of the VITAL project (Shadbolt et al., 1993) to provide operational modelling capabilities for the VITAL workbench (Domingue et al., 1993). Over the years the language has undergone a number of changes and improvements and in what follows we will provide an overview of the current version of the language (v5.1), illustrate its underlying philosophy and compare it to other knowledge modelling languages. 2. LANGUAGE TENETS A number of ideas/principles have shaped the development of the OCML language. These are discussed in the following sections. 2.1. Knowledge-level modelling support. The main goal of OCML is to support knowledge-level modelling (Newell, 1982; Fensel and Van Harmelen, 1994). In practice this role impl...

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.

Formal Specifications become more and more important in the development of software, especially, but not only in the area of high integrity systems. Testing as a method to validate the functionality of a system against the specification will keep its justification also in a development process using formal specifications. We demonstrate, where the problems lie when carrying out software integration tests using traditional testing techniques. It will then be demonstrated, how formal specifications can be used to achieve greater reliability and productivity during the software testing process by using extensive automatic tool support. This applies for the selection of test cases as well as the evaluation of test results, leading to a highly automated test process. First experiences from a case study will be given, in which we repeat the software integration test process for an application that has been developed by DST as part of the Cabin Intercommunication Data System (CIDS) for the Airbus A330/340 family.

Abstract. We formally define an abstract executable semantics for the Business Process Execution Language for Web Services in terms of a distributed ASM. The goal of this work is to support the design and standardization of the language. “There is a need for formalism. It will allow us to not only reason about the current specification and related issues, but also uncover issues that would otherwise go unnoticed. Empirical deduction is not sufficient. ” – Issue #42, OASIS WSBPEL TC. The language definition assumes an infrastructure for running Web services on some asynchronous communication architecture. A business process is built on top of a collection of Web services performing continuous interactions with the outside world by sending and receiving messages over a communication network. The underlying execution model is characterized by its concurrent and reactive behavior making it particularly difficult to predict dynamic system properties with a sufficient degree of detail and precision under all circumstances. 1

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.

We review the various arguments which have been advanced for and against the use of executable specifications. Examples are given of the problems which may arise in applying this technique and of the benefits which may accrue. A case study is reported in which execution is used to validate the published specification of a commercially available package. We conclude that there are circumstances when executable specifications can be of high value but that execution must be used together with, and as a supplement to, other methods of validating specifications such as inspection and proof. 1 Introduction Formal specifications have been accepted as having value in a number of areas, including critical systems. A specification that does not correctly capture requirements, however, is of dubious benefit. Validating a specification, whether formal or informal, is known to be difficult. With a formal specification there are a number of techniques available for validation, including r...

Formal methods are necessary in achieving correct software: that is, software that can be proven to fulfil its requirements. Formal specifications are unambiguous and analysable. Building a formal model improves understanding. The modelling of nondeterminism, and its subsequent removal in formal steps, allows design and implementation decisions to be made when most suitable. Formal models are amenable to mathematical manipulation and reasoning, and facilitate rigorous testing procedures. However, formal methods are not widely used in software development. In most cases, this is because they are not suitably supported with development tools. Further, many software developers do not recognise the need for rigour. Object oriented techniques are successful in the production of large, complex software systems. The methods are based on simple mathematical models of abstraction and classification. Further, the object oriented approach offers a conceptual consistency across all stages of soft...

In this position paper, we give a critical analysis of the deductive and inductive approaches to program synthesis, and of the current research in these fields. From the shortcomings of these approaches and works, we identify future research directions for these fields, as well as a need for cooperation and cross-fertilization between them.