Showing papers on "Specification language published in 1989"

A simple approach to specifying concurrent systems

Abstract: Over the past few years, I have developed an approach to the formal specification of concurrent systems that I now call the transition axiom method. The basic formalism has already been described in [12] and [1], but the formal details tend to obscure the important concepts. Here, I attempt to explain these concepts without discussing the details of the underlying formalism.Concurrent systems are not easy to specify. Even a simple system can be subtle, and it is often hard to find the appropriate abstractions that make it understandable. Specifying a complex system is a formidable engineering task. We can understand complex structures only if they are composed of simple parts, so a method for specifying complex systems must have a simple conceptual basis. I will try to demonstrate that the transition axiom method provides such a basis. However, I will not address the engineering problems associated with specifying real systems. Instead, the concepts will be illustrated with a series of toy examples that are not meant to be taken seriously as real specifications.Are you proposing a specification language? No. The transition axiom method provides a conceptual and logical foundation for writing formal specifications; it is not a specification language. The method determines what a specification must say; a language determines in detail how it is said.What do you mean by a formal specification? I find it helpful to view a specification as a contract between the user of a system and its implementer. The contract should tell the user everything he must know to use the system, and it should tell the implementer everything he must know about the system to implement it. In principle, once this contract has been agreed upon, the user and the implementer have no need for further communication. (This view describes the function of the specification; it is not meant as a paradigm for how systems should be built.)For a specification to be formal, the question of whether an implementation satisfies the specification must be reducible to the question of whether an assertion is provable in some mathematical system. To demonstrate that he has met the terms of the contract, the implementer should resort to logic rather than contract law. This does not mean that an implementation must be accompanied by a mathematical proof. It does mean that it should be possible, in principle though not necessarily in practice, to provide such a proof for a correct implementation. The existence of a formal basis for the specification method is the only way I know to guarantee that specifications are unambiguous.Ultimately, the systems we specify are physical objects, and mathematics cannot prove physical properties. We can prove properties only of a mathematical model of the system; whether or not the system correctly implements the model must remain a question of law and not of mathematics.Just what is a system? By "system," I mean anything that interacts with its environment in a discrete (digital) fashion across a well-defined boundary. An airline reservation system is such a system, where the boundary might be drawn between the agents using the system, who are part of the environment, and the terminals, which are part of the system. A Pascal procedure is a system whose environment is the rest of the program, with which it interacts by responding to procedure calls and accessing global variables. Thus, the system being specified may be just one component of a larger system.A real system has many properties, ranging from its response time to the color of the cabinet. No formal method can specify all of these properties. Which ones can be specified with the transition axiom method? The transition axiom method specifies the behavior of a System—that is, the sequence of observable actions it performs when interacting with the environment. More precisely, it specifies two classes of behavioral properties: safety and liveness properties. Safety properties assert what the system is allowed to do, or equivalently, what it may not do. Partial correctness is an example of a safety property, asserting that a program may not generate an incorrect answer. Liveness properties assert what the system must do. Termination is an example of a liveness property, asserting that a program must eventually generate an answer. (Alpern and Schneider [2] have formally defined these two classes of properties.) In the transition axiom method, safety and liveness properties are specified separately.There are important behavioral properties that cannot be specified by the transition axiom method; these include average response time and probability of failure. A transition axiom specification can provide a formal model with which to analyze such properties,1 but it cannot formally specify them.There are also important nonbehavioral properties of systems that one might want to specify, such as storage requirements and the color of the cabinet. These lie completely outside the realm of the method.Why specify safety and liveness properties separately? There is a single formalism that underlies a transition axiom specification, so there is no formal separation between the specification of safety and liveness properties. However, experience indicates that different methods are used to reason about the two kinds of properties and it is convenient in practice to separate them. I consider the ability to decompose a specification into liveness and safety properties to be one of the advantages of the method. (One must prove safety properties in order to verify liveness properties, but this is a process of decomposing the proof into smaller lemmas.)Can the method specify real-time behavior? Worst-case behavior can be specified, since the requirement that the system must respond within a certain length of time can be expressed as a safety property—namely, that the clock is not allowed to reach a certain value without the system having responded. Average response time cannot be expressed as a safety or liveness property.The transition axiom method can assert that some action either must occur (liveness) or must not occur (safety). Can it also assert that it is possible for the action to occur? No. A specification serves as a contractual constraint on the behavior of the system. An assertion that the system may or may not do something provides no constraint and therefore serves no function as part of the formal specification. Specification methods that include such assertions generally use them as poor substitutes for liveness properties. Some methods cannot specify that a certain input must result in a certain response, specifying instead that it is possible for the input to be followed by the response. Every specification I have encountered that used such assertions was improved by replacing the possibility assertions with liveness properties that more accurately expressed the system's informal requirements.Imprecise wording can make it appear that a specification contains a possibility assertion when it really doesn't. For example, one sometimes states that it must be possible for a transmission line to lose messages. However, the specification does not require that the loss of messages be possible, since this would prohibit an implementation that guaranteed no messages were lost. The specification might require that something happens (a liveness property) or doesn't happen (a safety property) despite the loss of messages. Or, the statement that messages may be lost might simply be a comment about the specification, observing that it does not require that all messages be delivered, and not part of the actual specification.If a safety property asserts that some action cannot happen, doesn't its negation assert that the action is possible? In a formal system, one must distinguish the logical formula A from the assertion ⊢ A, which means that A is provable in the logic; ⊢ A is not a formula of the logic itself. In the logic underlying the transition axiom method, if A represents a safety property asserting that some action is impossible, then the negation of A, which is the formula ┐A, asserts that the action must occur. The action's possibility is expressed by the negation of ⊢ A, which is a metaformula and not a formula within the logic. See [10] for more details.

The Inscape Environment

Abstract: The lnscape Environment is an integrated software development enviroment for building large software systems by large groups of developers. It provides tools that are knowledgeable about the process of system construction and evolution and that work in symbiosis with the system builders and evolvers. These tools are integrated around the constructive use of formal module interface specifications. We first discuss the problems that Inscapo addresses, outline our research strategies and approaches to solving these problems, and summarize the contributions of the Inscape Environment. We then discuss the major aspects of the Inscape Environment: the specification language, system construction, system evolution, use and reuse, and validation, We illustrate these various components with examples and discussions.

Formal program construction by transformations-computer-aided, intuition-guided programming

Abstract: Formal program construction by transformations is a method of software development in which a program is derived from a formal problem specification by manageable, controlled transformation steps which guarantee that the final product meets the initial specification. This methodology has been investigated in the Munich project CIP (computer-aided intuition-guided programming). The research includes the design of a wide-spectrum language specifically tailored to the needs of transformational programming, the construction of a transformation system to support the methodology, and the study of transformation rules and other methodological issues. Particular emphasis has been laid on developing a sound theoretical basis for the overall approach. >

A really temporal logic

Abstract: A real-time temporal logic for the specification of reactive systems is introduced The novel feature of the logic, TPTL, is the adoption of temporal operators as quantifiers over time variables; every modality binds a variable to the time(s) it refers to TPTL is demonstrated to be both a natural specification language and a suitable formalism for verification and synthesis A tableau-based decision procedure and model-checking algorithm for TPTL are presented Several generalizations of TPTL are shown to be highly undecidable >

Issues in the design of a parallel object-oriented language

Abstract: This paper discusses the considerations that have played a role in the design of the language POOL2. This language integrates the structuring techniques of object-oriented programming with mechanisms for expressing parallelism. We introduce the basic principles of object-oriented programming and its significance for program development methodologies. Several approaches for integrating objects and parallelism are compared and arguments for the choices made in POOL2 are presented. We also explain why inheritance is not yet included in POOL2. A brief overview of the research in formal aspects of POOL is given. Finally we indicate some directions for future developments.

Formal Description Technique Estelle: Results of the Esprit Sedos Project

Abstract: Introduction and Overview. SEDOS Software Environment for the Design of Open Distributed Systems (M. Diaz, C.A. Vissers, J.-P. Ansart). LOTOS Backgrounds (C.A. Vissers). Introduction to the ISO Specification Language LOTOS (T. Bolognesi, E. Brinksma). Specification. LOTOS Language Development and Promotion in the SEDOS Project (J. Quemada). A Constraint Oriented Specification of Al's Node (J. Quemada, A. Azcorra). Formal Description of the OSI Session Layer: Introduction (I. Ajubi, G. Scollo, M. van Sinderen). Formal Description of the OSI Session Layer: Transport Service (G. Scollo). Formal Description of the OSI Session Layer: Session Service (M. van Sinderen). Formal Description of the OSI Session Layer: Session Protocol (I. Ajubi). The OSI Transaction Processing Service: A Formal Framework (M. van Sinderen). Connectionless Data Link Service (J. Quemada, F. Fournon). Verification. LOTOS Verification Aspects: Report of the SEDOS C2 Task (E. Brinksma). A Theory for the Derivation of Tests (E. Brinksma). Towards Algebraic Semantics of the ISO-Specification Language LOTOS (H. Ehrig et al.). A Verification Oriented Specification in LOTOS of the Transport Protocol (E. Najm). PERLON Persistency Checker for Data Type Definitions (P. Bohm, J. de Meer, P. Schoo). Equivalence Verification: Theory, Algorithms, and a Tool (T. Bolognesi, M. Caneve). TILT: From LOTOS to Labelled Transition Systems (H. Garavel, E. Najm). Tools. Introduction to LOTOS Tools (A.K. Marshall). The Design of a Simulator Tool (P.H.J. van Eijk). HIPPO: A LOTOS Simulator (J. Tretmans). Functionality of an ADT Interpreter (R.B. Alderden). The Implementation of a Specification Language for OSI Systems (J.A. Ma#as, T. de Miguel, H. van Thienen). On the Correctness of Implementations of LOTOS Behaviour Specifications (H. van Thienen, J.A. Ma#as, T. de Miguel). Dining Philosophers: A Constraint Oriented Specification (J.A. Ma#as).

A general way to put time in Petri nets

Abstract: Petri nets have been widely used in the past to model vari&s types of concurrent systems, including real-time systems. To do so, a variety of ad-hoc solutions have been proposed in order to allow time to be taken into account in specifications. In this paper, we initially survey these proposals and then we illustrate a new proposal (TEI nets), that unifies and generalizes all pre,vious ones. Next, we discuss how these and possibly other enrichments of the original model can be formally defined. This will be do,ne in terms of a high-level net model, called ER nets. The ability of ER nets to express a variety of behaviors justifies our choice to use them as a kernel formalism of a specification support environment that we are currently developing. In this environment, it will be possible to define new graphical notations for formal specifications and give them formal semantics in terms of the underlying ER model. This allows the specifier to tune the notation used in formal specifications to the particular expressive needs arising while modelling an application and yet base the notation on firm and rigorous grounds.

Laws of data refinement

Abstract: A specification language typically contains sophisticated data types that are expensive or even impossible to implement Their replacement with simpler or more efficiently implementable types during the programming process is called data refinement We give a new formal definiton of data refinement and use it to derive some basic laws The derived laws are constructive in that used in conjunction with the known laws of procedural refinement they allow us to calculate a new specification from a given one in which variables are to be replaced by other variables of a different type

Specifying and implementing theorem provers in a higher-order logic programming language

Abstract: We argue that a logic programming language with a higher-order intuitionistic logic as its foundation can be used both to naturally specify and implement theorem provers. The language extends traditional logic programming languages by replacing first-order terms with simply-typed $\lambda$-terms, replacing first-order unification with higher-order unification, and allowing implication and universal quantification in queries and the bodies of clauses. Inference rules for a variety of proof systems can be naturally specified in this language. The higher-order features of the language contribute to a concise specification of provisos concerning variable occurrences in formulas and the discharge of assumptions present in many proof systems. In addition, abstraction in meta-terms allows the construction of terms representing object level proofs which capture the notions of abstractions found in many proof systems. The operational interpretations of the connectives of the language provide a set of basic search operations which describe goal-directed search for proofs. To emphasize the generality of the meta-language, we compare it to another general specification language: the Logical Framework (LF). We describe a translation which compiles a specification of a logic in LF to a set of formulas of our meta-language, and prove this translation correct. A direct specification of inference rules provides a declarative account of a proof system and a specification of the process of searching for proofs, but generally does not implement a theorem prover that can be executed directly. We show that it is sometimes possible to obtain a theorem prover that is complete under depth-first control by making only slight modifications to a specification. For the purpose of general theorem proving, we show how tactics and tacticals, which provide a framework for high-level control over search, can be directly implemented in our extended language. This framework serves as a starting point for implementing theorem provers and proof systems that can integrate many diversified operations on formulas and proofs for various logics. We present an extensive set of examples that have been implemented in the higher-order logic programming language $\lambda$Prolog.

Logical forms in the core language engine

Abstract: This paper describes a 'Logical Form' target language for representing the literal meaning of English sentences, and an intermediate level of representation ('Quasi Logical Form') which engenders a natural separation between the compositional semantics and the processes of scoping and reference resolution. The approach has been implemented in the SRI Core Language Engine which handles the English constructions discussed in the paper.

The RAISE language, methods and tools

Abstract: This paper presents the RAISE1 software development method, its associated specification language, and the tools supporting it. The RAISE method enables the stepwise development of both sequential and concurrent software from abstract specification through design to implementation. All stages of RAISE software development are expressed in the wide-spectrum RAISE specification language. The RAISE tools form an integrated tool environment supporting both language and method. The paper surveys RAISE and furthermore, more detailed presentations of major RAISE results are provided. The subjects of these are (a) an example of the use of the RAISE method and language, and (b) a presentation of the mathematical semantics of the RAISE specification language.

Inductive Completion by Ground Proof Transformation

Abstract: Publisher Summary This chapter presents the example of Prolog that has shown the possible success of high-level programming with some powerful mathematical notation as language and an automated theorem-prover as an interpreter for its execution. One of the few serious challenges to this combination of first-order predicate logic and resolution theorem proving is provided to date by the language of term-equations together with rewrite-rule machines and the Knuth–Bendix completion procedure. The latter approach has important applications in the area of data-type specification, where term equations provide a natural specification language, whose expressive power and usefulness is well known from modern Algebra and the theory of recursive functions. Software specification through term-equations has the advantage that, by interpreting the equations as directed rewrite-rules, an easy to implement rewrite-rule machine allows their efficient application and, therefore, some means of rapid prototyping. The category of all models forms an equational variety, for which the usual equational reasoning is a complete proof procedure. In the variety, there are also certain initial or standard models that are important in practice because they capture some standard intuition; all data items in these models are denoted by terms without variables formed from the operators in the equations and, hence, they are finitely constructible.

A Temporal-Logic Based Compositional Proof System for Real-Time Message Passing

Abstract: We consider a model of real-time network computation in which synchronous communication events occur during (possibly overlapping) intervals along a dense time scale. A specification language for processes and networks based on real-time temporal logic is defined. We give a simple proof system for network specifications when specifications for component processes are given. The proof system is then extended for a version of real-time CSP, under the assumption that all communications take some fixed length of time. Finally, it is shown that this proof system can be modified to allow varying communication lengths. All versions of the proof system are compositional, sound, and relatively complete.

Structuring specifications in Z

Abstract: In the specification notation known as Z, schemas are used to structure mathematical descriptions. This paper describes the language of schemas and the conventions that are employed in their use. It also describes how proof obligations are generated during specification, and how these obligations may be discharged. The paper contains many examples, mostly taken from the specification of the user interface to a small, but realistic, software component.

Formal specification of fault-tolerance and its relation to computer security

Abstract: International Workshop on Software Specification and Design 1989 (ACM SIGSOFT Engineering Notes, Volume 14, Number 3) The techniques of formal verification are one means for gaining greater assurance of the correctness of software. These techniques require precise specification of the properties to be assured. This paper formulates precise specifications corresponding to the intuitive notions of “fault tolerance” and of “graceful degradation”. An analogy is constructed between these fault-tolerance specifications and a particular class of specifications for computer security. On the basis of this analogy, it is argued that formal verification of fault tolerance will face some of the same problems, and benefit from some of the same solutions, as verification

An introduction to discrete mathematics and formal system specification

Abstract: Commercial software development customer requirements, system specification, and natural language propositional calculus predicate calculus set theory relations and relational operators functions and sequences induction and recursive specification the specification language Z operators and objects in Z the Z schema calculus Z specifications in action - the University of Lincoln library system. Appendix: definition of Z operators. References. Index

On Recent Trends in Algebraic Specification

Abstract: In this paper we focus on three different aspects which can be considered to be recent trends within theory and applications of algebraic specification.

Locking performance in a shared nothing parallel database machine

Abstract: A quantitative performance study of two-phase locking in a parallel database machine using a simulation-based methodology is described. The DBSIM simulation methodology uses models at two levels: a Petri net model at the higher level and a queuing network model at the lower level. The Petri net model captures the characteristics of parallelism and synchronization at the workload level, while the queuing network model captures queuing aspects of the system at the physical resource level. Transactions in a workload are specified using a performance-oriented specification language based on the transaction component graph, a data flow graph with database operators. The transaction specifications are translated into Petri net representations to derive the simulation experiments. The workload is a transaction taken from an order-entry application. A shared-nothing parallel machine architecture is assumed. Results of analysis of a two-phase locking strategy with machine sizes ranging from 4 to 256 processors are presented. >

A CSR-NL interface specification version 1.5

Abstract: Spoken Language Systems will require integration of continuous speech recognition and natural language processing. This is a proposed specification for an interface between a continuous speech recognizer (CSR) and a natural language processor (NLP) to form a spoken language system. Both components are integrated with a stack controller and contribute to the search control. The specification also defines a "Top-N" mode in which a "first part" outputs a list of top N scored sentences for postprocessing by a "second part". An additional use for this specification might be NLP evaluation testing: a common simulated CSR could be interfaced to each site's NLP to provide identical testing environments.

Unified algebras and modules

Abstract: This paper concerns the algebraic specification of abstract data types. It introduces and motivates the recently-developed framework of unified algebras, and provides a practical notation for their modular specification. It also compares unified algebras with the well-known framework of order-sorted algebras, which underlies the OBJ specification language.

VVSL: a language for structured VDM specifications

Abstract: VVSL is a VDM specification language of the “British School” with modularisation constructs allowing sharing of hidden state variables and parameterisation constructs for structuring specifications, and with constructs for expressing temporal aspects of the concurrent execution of operations which interfere via state variables. The modularisation and parameterisation constructs have been inspired by the “kernel” design language COLD-K from the ESPRIT project 432: METEOR, and the constructs for expressing temporal aspects by various temporal logics based on linear and discrete time. VVSL is provided with a well-defined semantics by defining a translation to COLD-K extended with constructs which are required for translation of the VVSL constructs for expressing temporal aspects. In this paper, the syntax for the modularisation and parameterisation constructs of VVSL is outlined. Their meaning is informally described by giving an intuitive explanation and by outlining the translation to COLD-K. It is explained in some detail how sharing of hidden state variables is modelled. Examples of the use of the modularisation and parameterisation constructs are also given. These examples are based on a formal definition of the relational data model. With respect to the constructs for expressing temporal aspects, the ideas underlying the use of temporal formulae in VVSL are briefly outlined and a simple example is given.

A hybrid approach to representation in the janus natural language processor

Abstract: In BBN's natural language understanding and generation system (Janus), we have used a hybrid approach to representation, employing an intensional logic for the representation of the semantics of utterances and a taxonomic language with formal semantics for specification of descriptive constants and axioms relating them. Remarkably, 99.9% of 7,000 vocabulary items in our natural language applications could be adequately axiomatized in the taxonomic language.

Action system approach to the specification and design of distributed systems

Abstract: in temporal logic [24, 25] or in the logic developed for Unity [10]. External interactions are also modeled as joint actions, without committing to specific communication events between the system and its environment. This means that a joint action system is a closed system containing also a model of its environment. This has an effect on modularity, as will be seen below. For the design process joint action systems provide a framework for stepwise derivation. The initial action system with which this process starts should be simple. Fortunately, the natural ways of structuring action systems support a layered introduction of properties. Bias towards machine architecture or communication primitives does not belong to the initial system, even if the eventual answers to such questions were known from the beginning. No harm is caused at this level by wasteful computations allowed by nondeterminism. Furthermore, the granularity of atomic actions can be coarser than would be feasible in a distributed implementation. Together with independence of communication mechanisms this helps in the avoidance of subtle timing errors. The initial action system is the first baseline for the design process. Being amenable to both formal analysis and experimentation (by simulation and animation), it can be subjected to extensive verification and validation. From this stage the design proceeds by transformations that • refine the atomicity of actions,

Algebraic methods: theory, tools and applications

Abstract: Formalizing informal requirements some aspects.- ViewPoint oriented software development: Methods and viewpoints in requirements engineering.- Using transformations to verify parallel programs.- Experiences with combining formalisms in VVSL.- A meta-environment for generating programming environments.- Introducing formal requirements into industry.- Where can I get gas round here? - an application of a design methodology for distributed systems.- Transformations of designs.- Norman's database modularised in COLD-K.- POLAR a picture-oriented language for abstract representations.- Inheritance in COLD.- A process specification formalism based on static COLD.- Specification of the transit node in PSFd.- Design of a specification language by abstract syntax engineering.- From an ERAE requirements specification to a PLUSS algebraic specification: A case study.

RT-ASLAN: A specification language for real-time systems

Abstract: RT-ASLAN, a formal language for specifying real-time systems, is an extension of the ASLAN specification language for sequential systems. Some of the features of the ASLAN language, such as constructs for writing procedural semantics in a nonprocedural logical language, are highlighted. The RT-ASLAN language supports specification of parallel real-time processes through arbitrary levels of abstraction; processes do not have to be specified to the same level of detail. Communicating processes use an interface process as an abstract data type representing shared information. From RT-ASLAN specifications, performance correctness conjectures are generated. These conjectures are logic statements whose proof guarantees that the specification meets critical time bounds. A detailed example as well as a discussion of the advantages and disadvantages of formal specification and verification are included.

Formally specifying electronic instruments

Abstract: This paper shows how formal specification techniques can be beneficially applied in the develop ment of electronic instrumentation. As an example of our approach we present a specification of a simple electronic instrument, written in the Z specification language. We argue that such specifications can be used to gain insight into software/hardware systems and to clarify the resulting design. A consequence is that formal specifications can assume a pivotal role in system design as non-executable prototypes and lead to a cost-effect application of formal techniq,ues in industrial settings.

Automatic runtime consistency checking and debugging of formally specified programs

Abstract: This thesis studies an approach to automate the process of deciding whether a program is performing correctly, and if not, to discover the probable cause of the problem. It assumes that the intended behavior of the program is specified in some formal, high-level specification language. It studies how one can check automatically at runtime whether the program is running consistently with its specification, and if not, how inconsistencies can be automatically detected and diagnosed. A methodology of using this checking methodology for debugging formally specified programs is then presented. The consistency checking methodology depends on the particular specification language constructs used. In this thesis, two categories of constructs are studied: (1) generalized assertions and (2) algebraic specifications. Generalized assertions contain boolean expressions that must be satisfied within a specified region in the underlying program. Checking functions are generated which test for the truth of these boolean expressions. Diagnostic messages are given and a debugger is invoked if there is a violation. Checking functions are called from locations in the program where the specification may have changed value. For the purpose of this thesis, algebraic specifications are considered to be equations whose terms comprise abstract data type operations. Algebraic specification checking involves monitoring the execution of the abstract data type operations. Based on this monitoring and the algebraic specifications, a theorem prover generates invariants that the program must satisfy. If the program does not satisfy these invariants, diagnostic messages are given and a debugger is invoked. The theorem prover has to be specialized so that it operates efficiently in the context of algebraic specification checking. Methodologies to achieve this using incremental techniques are presented in this thesis. Based on these ideas, a working system has been built for automatic runtime consistency checking of Ada programs with specifications written in Anna. Experiments with this system has led to the development of a methodology of debugging programs based on formal specifications.