Abstract not found

The Larch family of languages is used to specify program interfaces in a two-tiered definitional style. Each Larch specification has components written in two languages: one that is designed for a specific programming language and another that is independent of any programming language. The former are the Larch interface languages, and the latter is the Larch Shared Language (LSL). Version 2.3 of LSL is similar to previous versions, but contains a number of refinements based on experience writing specifications and developing tools to support the specification process. This report contains an informal introduction and a self-contained language definition. This report supersedes Pieces II and III of Larch in Five Easy Pieces [Guttag, Horning, and Wing 1985b] and "Report on the Larch Shared Language" [Guttag and Horning 1986]. iii Report on the Larch Shared Language, Version 2.3 Chapter 1: Overview 1.1. Introduction 1.2. Simple Algebraic Specifications 1.3. Getting Richer Theories 1.4...

To establish the correctness of some software w.r.t. its formal specification is widely recognized as a difficult task. A first simplification is obtained when the semantics of an algebraic specification is defined as the class of all algebras which correspond to the correct realizations of the specification. A software is then declared correct if it corresponds to some algebra of this class. We approach this goal by defining an observational satisfaction relation which is less restrictive than the usual satisfaction relation. Based on this notion we provide an institution for observational specifications. The idea is that the validity of an equational axiom should depend on an observational equality, instead of the usual equality. We show that it is not reasonable to expect an observational equality to be a congruence. We define an observational algebra as an algebra equipped with an observational equality which is an equivalence relation but not necessarily a congruence. We assume th...

. We investigate the impact of modularity on the semantics and on the implementation of software specifications. Based on the stratified loose semantics approach we develop a suitable specification framework which meets our basic requirements: the independent construction of implementations for the single constituent parts (modules) of a system specification and the encapsulated development of each implementation part using the principle of stepwise refinement. Our paper is not aimed at providing an elaborated specification language but rather to concentrate on the modularity issues of system development. Hence, only few but powerful constructs are provided which can be seen as a kernel for further extensions. In particular, we will show that implementation and parameterization can be handled within a uniform concept and we will prove compatibility theorems like the horizontal composition property. All constructs are defined on top of a very general logical framework thus being applica...

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.

this paper, we will describe the main techniques for the semantic definition of some of the most used structuring and modular constructs. Our main aim will be to study the generic, "institutionindependent ", version of each construct. However, in order to provide intuition, in most cases, we will first study these constructions in connection to equational logic.

A refinement relation for parameterized algebraic specifications is introduced in which the body specification is refined covariantly (i.e., specialized) while the parameter specification is refined contravariantly (i.e., generalized). This refinement is similar to the subtyping relation between function types. Assuming a few relatively weak axioms about parameterized specifications, refinement is shown to satisfy the expected properties for software development in-the-large: independent refinement of body and parameter, and closure under sequential composition, instantiation and a suitable form of `horizontal' composition. Keywords Parameterized specifications, mixed-variance refinement, compositionality 1 INTRODUCTION The primary subject of this paper is a general notion of refinement for parameterized specifications. Many notions of refinement have been previously proposed in the literature (Ehrig & Kreowski 1982, Ganzinger 1983, Goguen & Meseguer 1982, Sannella & Tarlecki 1988, S...

Abstract. An important aspect of the feature interaction problem is to formally capture the notion of feature interactions. Although this notion is quite well informally understood by the researchers of the domain, the way, they handle it, strongly depends on the field of investigation they decide to work on (formal method application, architectural conception, technological research...). In this article, we focus on how formally specifying and studying feature systems, and both integration and interaction of features. More precisely, we aim to give a logic-independent framework to deal with the notions of feature, feature-based systems and feature interactions. Then, to help the reader's intuition, we instantiate it by a dynamic algebraic formalism and we give concrete examples of interactions between two features previously described in this formalism.

. This paper presents a model inference system to control instantiation of generic modules. Generic parameters are specified by properties which represent classes of modules sharing some common features. Just as type checking consists in verifying that an expression is well typed, model checking allows to detect whether a (possibly generic) instantiation of a generic module is valid, i.e. whether the instantiation module is a model of the parameterizing property. Equality of instances can be derived from a canonical representation of modules. At last, we show how the code of generic modules can be shared for all instances of modules. 1 Introduction Genericity is a useful feature for specification languages, and for programming languages alike, because it allows to reuse already written packages by instantiating them on various ways, thus limits the risk of bugs and reduces software costs. When a generic module is instantiated and imported into another module, one has to check that the...

. This paper provides with a description of how to use a formalism called CO-OPN (Concurrent Object Oriented Petri Nets), which incorporates both concurrency and data structuring features, for open distributed program development. CO-OPN is a structured extension of Petri nets and algebraic abstract data types. A CO-OPN specification is composed of a set of objects (algebraic abstract data types and Petri nets), and of a synchronous communication mechanism. We describe in which way it is possible to specify open distributed programs with CO-OPN and under what assumption it is possible to gather open systems through the use of standardized communication components specified with CO-OPN. Moreover the refinement capabilities of CO-OPN on the Petri net part and the algebraic abstract data type part allow powerful specification refinements in order to reach implementations. Keywords : Formal approaches to modelling of distributed systems, open distributed systems, modular specification, c...