Results 1  10
of
20
Writing Larch Interface Language Specifications
 ACM Transactions on Programming Languages and Systems
, 1987
"... Current research in specifications is emphasizing the practical use of formal specifications in program design. One way to encourage their use in practice is to provide specification languages that are accessible to both designers and programmers. With this goal in mind, the Larch family of formal s ..."
Abstract

Cited by 73 (2 self)
 Add to MetaCart
Current research in specifications is emphasizing the practical use of formal specifications in program design. One way to encourage their use in practice is to provide specification languages that are accessible to both designers and programmers. With this goal in mind, the Larch family of formal specification languages has evolved to support a twotiered approach to writing specifications. This approach separates the specification of state transformations and programming language dependencies from the specification of underlying abstractions. Thus, each member of the Larch family has a subset derived from a programming language and another subset independent of any programming languages. We call the former interface languages, and the latter the Larch Shared Language. This paper focuses on Larch interface language specifications. Through examples, we illustrate some salient features of Larch/CLU, a Larch interface language for the programming language CLU. We give an example of writing an interface specification following the twotiered approach and discuss in detail issues involved in writing interface specifications and their interaction with their Shared Language components.
Objects and Classes, Coalgebraically
 ObjectOrientation with Parallelism and Persistence
, 1995
"... The coalgebraic perspective on objects and classes in objectoriented programming is elaborated: objects consist of a (unique) identifier, a local state, and a collection of methods described as a coalgebra; classes are coalgebraic (behavioural) specifications of objects. The creation of a "new" o ..."
Abstract

Cited by 68 (17 self)
 Add to MetaCart
The coalgebraic perspective on objects and classes in objectoriented programming is elaborated: objects consist of a (unique) identifier, a local state, and a collection of methods described as a coalgebra; classes are coalgebraic (behavioural) specifications of objects. The creation of a "new" object of a class is described in terms of the terminal coalgebra satisfying the specification. We present a notion of "totally specified" class, which leads to particularly simple terminal coalgebras. We further describe local and global operational semantics for objects. Associated with the local operational semantics is a notion of bisimulation (for objects belonging to the same class), expressing observational indistinguishability. AMS Subject Classification (1991): 18C10, 03G30 CR Subject Classification (1991): D.1.5, D.2.1, E.1, F.1.1, F.3.0 Keywords & Phrases: object, class, (terminal) coalgebra, coalgebraic specification, bisimulation 1. Introduction Within the objectoriente...
On Observational Equivalence and Algebraic Specification
, 1987
"... The properties of a simple and natural notion of observational equivalence of algebras and the corresponding specificationbuilding operation are studied. We begin with a defmition of observational equivalence which is adequate to handle reachable algebras only, and show how to extend it to cope wit ..."
Abstract

Cited by 66 (17 self)
 Add to MetaCart
The properties of a simple and natural notion of observational equivalence of algebras and the corresponding specificationbuilding operation are studied. We begin with a defmition of observational equivalence which is adequate to handle reachable algebras only, and show how to extend it to cope with unreachable algebras and also how it may be generalised to make sense under an arbitrary institution. Behavioural equivalence is treated as an important special case of observational equivalence, and its central role in program development is shown by means of an example.
Mongruences and Cofree Coalgebras
 Algebraic Methods and Software Technology, number 936 in Lect. Notes Comp. Sci
, 1995
"... . A coalgebra is introduced here as a model of a certain signature consisting of a type X with various "destructor" function symbols, satisfying certain equations. These destructor function symbols are like methods and attributes in objectoriented programming: they provide access to the type (or st ..."
Abstract

Cited by 30 (10 self)
 Add to MetaCart
. A coalgebra is introduced here as a model of a certain signature consisting of a type X with various "destructor" function symbols, satisfying certain equations. These destructor function symbols are like methods and attributes in objectoriented programming: they provide access to the type (or state) X. We show that the category of such coalgebras and structure preserving functions is comonadic over sets. Therefore we introduce the notion of a `mongruence' (predicate) on a coalgebra. It plays the dual role of a congrence (relation) on an algebra. An algebra is a set together with a number of operations on this set which tell how to form (derived) elements in this set, possibly satisfying some equations. A typical example is a monoid, given by a set M with operations 1 ! M , M \Theta M ! M . Here 1 = f;g is a singleton set. In mathematics one usually considers only singletyped algebras, but in computer science one more naturally uses manytyped algebras like 1 ! list(A), A \Theta l...
Discovering documentation for java container classes
 IEEE Transactions on Software Engineering
, 2007
"... 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 in ..."
Abstract

Cited by 20 (1 self)
 Add to MetaCart
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
Observational Specifications and the Indistinguishability Assumption
 Theoretical Computer Science
, 1995
"... 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 spec ..."
Abstract

Cited by 17 (0 self)
 Add to MetaCart
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...
Invariants, Bisimulations and the Correctness of Coalgebraic Refinements
 Techn. Rep. CSIR9704, Comput. Sci. Inst., Univ. of Nijmegen
, 1997
"... . Coalgebraic specifications are used to formally describe the behaviour of classes in objectoriented languages. In this paper, a general notion of refinement between two such coalgebraic specifications is defined, capturing the idea that one "concrete" class specification realises the behaviour of ..."
Abstract

Cited by 12 (4 self)
 Add to MetaCart
. Coalgebraic specifications are used to formally describe the behaviour of classes in objectoriented languages. In this paper, a general notion of refinement between two such coalgebraic specifications is defined, capturing the idea that one "concrete" class specification realises the behaviour of the other, "abstract" class specification. Two (complete) prooftechniques are given to establish such refinements: one involving an invariant (a predicate that is closed under transitions) on the concrete class, and one involving a bisimulation (a relation that is closed under transitions) between the concrete and the abstract class. The latter can only be used if the abstract class is what we call totally specified. Parts of the underlying theory of invariants and bisimulations in a coalgebraic setting are included, involving least and greatest invariants and connections between invariants and bisimulations. Also, the proofprinciples are illustrated in examples (which are fully formalise...
An Example of Interactive Hardware Transformation
, 1993
"... This article presents an example of correct circuit design through interactive transformation. Interactive transformation differs from traditional hardware design transformation frameworks in that it focuses on the issue of finding suitable hardware architecture for the specified system and the issu ..."
Abstract

Cited by 10 (1 self)
 Add to MetaCart
This article presents an example of correct circuit design through interactive transformation. Interactive transformation differs from traditional hardware design transformation frameworks in that it focuses on the issue of finding suitable hardware architecture for the specified system and the issue of architecture correctness. The transformation framework divides every transformation in designs into two steps. The first step is to find a proper architecture implementation. Although the framework does not guarantee existence of such an implementation, nor its discovery, it does provide a characterization of architectural implementation so that the question "is this a correct implementation?" can be answered by equational rewriting. The framework allows a correct architecture implementation to be automatically incorporated with control descriptions to obtain a new system description. The significance of this transformation framework lies in the fact that it requires simpler mechanism o...