Results 1 - 10
of
10
Objects and Classes, Coalgebraically
- Object-Orientation with Parallelism and Persistence
, 1995
"... The coalgebraic perspective on objects and classes in object-oriented 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 67 (17 self)
- Add to MetaCart
The coalgebraic perspective on objects and classes in object-oriented 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 object-oriente...
A Logic for the Java Modeling Language JML
- Fundamental Approaches to Software Engineering (FASE), volume 2029 of LNCS
, 2001
"... This paper describes a specialised logic for proving specifications in the Java Modeling Language (JML). JML is an interface specification language for Java. It allows assertions like invariants, constraints, pre- and post-conditions, and modi able clauses as annotations to Java classes, in a design ..."
Abstract
-
Cited by 50 (15 self)
- Add to MetaCart
This paper describes a specialised logic for proving specifications in the Java Modeling Language (JML). JML is an interface specification language for Java. It allows assertions like invariants, constraints, pre- and post-conditions, and modi able clauses as annotations to Java classes, in a design-by-contract style. Within the LOOP project at the University of Nijmegen JML is used for specification and verification of Java programs. A special compiler has been developed which translates Java classes together with their JML annotations into logical theories for a theorem prover (PVS or Isabelle). The logic for JML that will be described here consists of tailor-made proof rules in the higher order logic of the back-end theorem prover for verifying translated JML specifications. The rules efficiently combine partial and total correctness (like in Hoare logic) for all possible termination modes in Java, in a single correctness formula.
Beyond assertions: Advanced specification and verification with JML and ESC/Java2
- In Formal Methods for Components and Objects (FMCO) 2005, Revised Lectures, volume 4111 of LNCS
, 2006
"... Abstract. Many state-based specification languages, including the Java Modeling Language (JML), contain at their core specification constructs familiar to most computer science and software engineering undergraduates: e.g., assertions, pre- and postconditions, and invariants. Unfortunately, these co ..."
Abstract
-
Cited by 35 (10 self)
- Add to MetaCart
Abstract. Many state-based specification languages, including the Java Modeling Language (JML), contain at their core specification constructs familiar to most computer science and software engineering undergraduates: e.g., assertions, pre- and postconditions, and invariants. Unfortunately, these constructs are not sufficiently expressive to permit formal modular verification of programs written in modern object-oriented languages like Java. The necessary extra constructs for specifying an object-oriented module include the less familiar frame properties, datagroups, and ghost and model fields. These constructs help specifiers deal with potential problems related to, e.g., unexpected side effects, aliasing, class invariants, inheritance, and lack of information hiding. This tutorial focuses on these constructs, explaining their meaning while illustrating how they can be used to address the stated problems. 1
Inheritance of Behavior
- Journal of Logic and Algebraic Programming
, 1999
"... One of the key issues of object-oriented modeling and design is inheritance. It allows for the definition of subclasses that inherit features of some superclass. Inheritance is well defined for static properties of classes such as attributes and methods. However, there is no general agreement on the ..."
Abstract
-
Cited by 11 (1 self)
- Add to MetaCart
One of the key issues of object-oriented modeling and design is inheritance. It allows for the definition of subclasses that inherit features of some superclass. Inheritance is well defined for static properties of classes such as attributes and methods. However, there is no general agreement on the meaning of inheritance when considering the dynamic behavior of objects, captured by their life cycles. This paper studies inheritance of behavior both in a simple process-algebraic setting and in a Petri-net framework. Process algebra is chosen, because it concentrates on behavior, while abstracting from the internal states of processes. The result of the algebraic study is a clear conceptual understanding of inheritance of behavior. It can be expressed in terms of blocking and hiding method calls. The results in the algebraic framework inspire the development of the concept of inheritance of behavior in the Petri-net framework. The Petri-net formalism allows for a graphical representation...
The theory of classification, part 8: Classification and Inheritance
- in Journal of Object Technology
, 2003
"... This is the eighth article in a regular series on object-oriented type theory, aimed specifically at non-theoreticians. In earlier articles, we explored the view that a programmer's class in C++ or Java corresponds in some way to a type in the formal model, and that a compatible subclass therefore c ..."
Abstract
-
Cited by 10 (8 self)
- Add to MetaCart
This is the eighth article in a regular series on object-oriented type theory, aimed specifically at non-theoreticians. In earlier articles, we explored the view that a programmer's class in C++ or Java corresponds in some way to a type in the formal model, and that a compatible subclass therefore corresponds to a subtype [1, 2]. In the
A Coalgebraic Semantics of Subtyping
, 2000
"... Coalgebras have been proposed as formal basis for the semantics of objects in the sense of object-oriented programming. This paper shows that this semantics provides a smooth interpretation for subtyping, a central notion in object-oriented programming. We show that different characterisations of be ..."
Abstract
-
Cited by 7 (1 self)
- Add to MetaCart
Coalgebras have been proposed as formal basis for the semantics of objects in the sense of object-oriented programming. This paper shows that this semantics provides a smooth interpretation for subtyping, a central notion in object-oriented programming. We show that different characterisations of behavioural subtyping found in the literature can conveniently be expressed in coalgebraic terms. We also investigate the subtle difference between behavioural subtyping and refinement.
A Catalogue of Incremental Changes for Coloured Petri Nets
- the International Conference of Application and Theory of Petri Nets
, 1999
"... Abstract: This paper presents three forms of incremental change or refinement which are considered appropriate for Coloured Petri Nets. The intention is to recommend forms which are appropriate to Petri Nets and not primarily driven by the desire to emulate object-oriented programming languages. Nev ..."
Abstract
-
Cited by 3 (2 self)
- Add to MetaCart
Abstract: This paper presents three forms of incremental change or refinement which are considered appropriate for Coloured Petri Nets. The intention is to recommend forms which are appropriate to Petri Nets and not primarily driven by the desire to emulate object-oriented programming languages. Nevertheless, the proposals are compared with others in the literature — with objectoriented programming languages, with practical case studies of the application of formal methods, and with other object-oriented Petri Net formalisms.
Adding Axioms to Cardelli-Wegner Subtyping
, 1994
"... Cardelli and Wegner developed a simple theory of object subtyping which was later to form the basis for a second-order theory of bounded quantification [Card84, CW85, Ghel90] and the higher-order theory of F-bounded quantification explored by Cook and others [CCHO89a, CHC90]. In all of these present ..."
Abstract
-
Cited by 1 (1 self)
- Add to MetaCart
Cardelli and Wegner developed a simple theory of object subtyping which was later to form the basis for a second-order theory of bounded quantification [Card84, CW85, Ghel90] and the higher-order theory of F-bounded quantification explored by Cook and others [CCHO89a, CHC90]. In all of these presentations, the abstract type of objects is only expressed syntactically, in terms of an external interface of function signatures. Here, we re-introduce semantic descriptions for objects, in terms of sets of axioms constraining the operation of some invocations of their functions. We use the well-understood technique of definition by comprehension to motivate subtyping rules for object axioms and prove how these rules interact properly with Cardelli-Wegner style subtyping rules. For languages like Eiffel [Meye88, Meye92] and Sather [Omoh94] in which programmers can write object axioms, rules governing the addition of preconditions, postconditions and data type invariants can now be motivated fr...
A theory of class
- In Proc. 3rd Int. Conf. Object-Oriented Info. Sys
, 1996
"... ABSTRACT: We present a mathematical theory of class. The theory is general, in that it encompasses many different approaches to type abstraction, such as type constructors, generic parameters, classes, inheritance and polymorphism. The theory is elegant, in that it is based on a simple generalisatio ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
ABSTRACT: We present a mathematical theory of class. The theory is general, in that it encompasses many different approaches to type abstraction, such as type constructors, generic parameters, classes, inheritance and polymorphism. The theory is elegant, in that it is based on a simple generalisation of F-bounds. The theory has timely implications for emerging OMG standards and future language designs. KEYWORDS: object-oriented, type theory, F-bounds, class, classification, generic parameters, polymorphism, inheritance
Rationalising Eiffel's Type System
- Proc. 18th Conf. Techn. ObjectOriented
, 1995
"... forbidding the redefinition of attribute types, inverting the routine argument redefinition rule to observe contravariance (redefined arguments should have more general types), judging type compatibility between parameterised types after replacing the type parameters and introducing an explicit type ..."
Abstract
-
Cited by 1 (1 self)
- Add to MetaCart
forbidding the redefinition of attribute types, inverting the routine argument redefinition rule to observe contravariance (redefined arguments should have more general types), judging type compatibility between parameterised types after replacing the type parameters and introducing an explicit type attribute scheme to handle Eiffel's anchored types. Contravariance is a counterintuitive finding for subtyping models of inheritance because it prevents the uniform specialisation of function arguments and results. It forbids the replacement of a function f:t®t closed over a type t by a function f:s®s closed over a subtype s Í t [Cardelli 86]. While insisting that Eiffel should obey the contravariant rule, Cook ruefully admits that: Eiffel has too many polymorphic type mechanisms: conformance, generic and anchored types, some of which are flawed and others redundant. Cook's suggested 1989 corrections to Eiffel's type rules, most notably to make inheritance obey subtyping, were not accepte...

