A Survey of Languages for Specifying Dynamics: A Knowledge Engineering Perspective

A number of formal specification languages for knowledge-based systems has been developed. Characteristics for knowledge-based systems are a complex knowledge base and an inference engine which uses this knowledge to solve a given problem. Specification languages for knowledge-based systems have to cover both aspects. They have to provide the means to specify a complex and large amount of knowledge and they have to provide the means to specify the dynamic reasoning behavior of a knowledge-based system. We focus on the second aspect. For this purpose, we survey existing approaches for specifying dynamic behavior in related areas of research. In fact, we have taken approaches for the specification of information systems (Language for Conceptual Modeling and TROLL), approaches for the specification of database updates and logic programming (Transaction Logic and Dynamic Database Logic) and the generic specification framework of abstract state machine

Automatic Verification of Transactions on an Object-Oriented Database

In the context of the object-oriented data model, a compiletime approach is given that provides for a significant reduction of the amount of run-time transaction overhead due to integrity constraint checking. The higher-order logic Isabelle theorem prover is used to automatically prove which constraints might, or might not be violated by a given transaction in a manner analogous to the one used by Sheard and Stemple (1989) for the relational data model. A prototype transaction verification tool has been implemented, which automates the semantic mappings and generates proof goals for Isabelle. Test results are discussed to illustrate the effectiveness of our approach

Constraint Diagrams: Visualizing Assertions in OO Modelling

Describes a notation, constraint diagrams, which allows pre/post conditions and invariants to be expressed visually, rather than in the notation of mathematical logic. The notation is explored through a small case study (a library system). Some conclusions are drawn about the use of the notation in modelling, and its possible impact on tools and semantics. This report has been split into two and considerable revised and updated: Kent (1997b), Kent (1997c)

Semantics Through Pictures: towards a diagrammatic semantics for object-oriented modelling notations

An object-oriented (OO) model has a static component, the set of allowable snapshots or system states, and a dynamic component, the set of filmstrips or sequences of snapshots. Diagrammatic notations, such as those in UML, each places constraints on the static and/or dynamic models. A formal semantics of OO modeling notations can be constructed by providing a formal description of (i) sets of snapshots and filmstrips, (ii) constraints on those sets, and (iii) the derivation of those constraints from diagrammatic notations. In addition, since constraints are contributed by many diagrams for the same model, a way of doing this compositionally is desirable. One approach to the semantics is to use first-order logic for (i) and (ii), and theory inclusion with renaming, as in Larch, to characterize composition. A common approach to (iii) is to bootstrap: provide a semantics for a kernel of the notation and then use the kernel to give a semantics to the other notations. This only works if a kernel which is sufficiently expressive can be identified, and this is not the case for UML. However, we have developed a diagrammatic notation, dubbed constraint diagrams, which seems capable of expressing most if not all static and dynamic constraints, and it is proposed that this be used to give a diagrammatic semantics to OO models

A design model for Open Distributed Processing systems

This paper proposes design concepts that allow the conception, understanding and development of complex technical structures for open distributed systems. The proposed concepts are related to, and partially motivated by, the present work on Open Distributed Processing (ODP). As opposed to the current ODP approach, the concepts are aimed at supporting a design trajectory with several, related abstraction levels. Simple examples are used to illustrate the proposed concepts

Unifying Requirements and Code: an Example

Requirements and code, in conventional software engineering wisdom, belong to entirely different worlds. Is it possible to unify these two worlds? A unified framework could help make software easier to change and reuse. To explore the feasibility of such an approach, the case study reported here takes a classic example from the requirements engineering literature and describes it using a programming language framework to express both domain and machine properties. The paper describes the solution, discusses its benefits and limitations, and assesses its scalability.Comment: 13 pages; 7 figures; to appear in Ershov Informatics Conference, PSI, Kazan, Russia (LNCS), 201

What makes industries believe in formal methods

The introduction of formal methods in the design and development departments of an industrial company has far reaching and long lasting consequences. In fact it changes the whole environment of methods, tools and skills that determine the design culture of that company. A decision to replace current design practice by formal methods, therefore, appears a vital one and is not lightly taken. The past has shown that efforts to introduce formal methods in industry has faced a lot of controversy and opposition at various hierarchical levels in companies, resulting in a marginal spread of such methods. This paper revisits the requirements for formal description techniques and identifies some critical success and inhibiting factors associated with the introduction of formal methods in the industrial practice. One of the inhibiting factors is the often encountered lack of appropriateness of the formal model to express and manipulate the design concerns that determine the world of the engineer. This factor motivated our research in the area of architectural and implementation design concepts. The last two sections of this paper report on some results of this research