Cooperation-based Invariants for OO Languages

Middelkoop, Ronald; Huizing, Cornelis; Kuiper, Ruurd; Luit, E.J.

doi:10.1016/j.entcs.2006.05.025

Cited by 5 publications

(8 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This section presents the specification construct coop, first introduced in [9]. This construct specifies which invariants might be invalidated when a field is assigned to.…”

Section: The Specification Construct Coopmentioning

confidence: 99%

“…We do not consider this good OO design, but it is possible in Java. Rather than (slightly) changing Theorem 3.1 and introducing restrictions on programs to prevent such implementations, we use a different (more logical) semantics for constructors [9]. The body of a constructor of class C is of the shape {P 0 }mc(this, M D ); {P 1 }dtc; S, where mc(this, M D ) is a call to the constructor of C's superclass.…”

Section: Constructorsmentioning

confidence: 99%

“…By default, the coop-set is empty. We generalize the approach in [9]. A coop-set associated with a field f is a set of elements (C, I, P ), with C a classname, I the name of an invariant specified in class C and P a predicate in which all references consist of one of the keyword logical variables this or dep, followed by zero or more field accesses.…”

Section: The Specification Construct Coopmentioning

confidence: 99%

“…The specification construct inc (for inconsistent), first introduced in [9], offers flexibility at little cost. In this particular example, the specification of method loanTo includes inc: MI(m).…”

Section: The Specification Construct Incmentioning

confidence: 99%

“…We extend results from [9]: instead of the previously used fixed set of object references, predicates are introduced to describe a set of objects involved. We argue that the additional flexibility offered by inc is essential in the use of invariants over non-hierarchical object structures.…”

Section: Introductionmentioning

confidence: 98%

See 4 more Smart Citations

Invariants for Non-Hierarchical Object Structures

Middelkoop

Huizing

Kuiper

et al. 2008

Electronic Notes in Theoretical Computer Science

Self Cite

View full text Add to dashboard Cite

We present a Hoare-style specification and verification approach for invariants in sequential OO programs. It allows invariants over non-hierarchical object structures, in which update patterns that span several objects and methods occur frequently. This gives rise to invalidating and subsequent re-establishing of invariants in a way that compromises standard data induction, which assumes invariants hold when a method is called. We provide specification constructs (inc and coop) that identify objects and methods involved in such patterns, allowing a refined form of data induction. The approach now handles practical designs, as illustrated by a specification of the Observer Pattern.

show abstract

“…This section presents the specification construct coop, first introduced in [9]. This construct specifies which invariants might be invalidated when a field is assigned to.…”

Section: The Specification Construct Coopmentioning

confidence: 99%

Section: Constructorsmentioning

confidence: 99%

Section: The Specification Construct Coopmentioning

confidence: 99%

Section: The Specification Construct Incmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 98%

See 3 more Smart Citations

Invariants for Non-Hierarchical Object Structures

Middelkoop

Huizing

Kuiper

et al. 2008

Electronic Notes in Theoretical Computer Science

Self Cite

View full text Add to dashboard Cite

show abstract

Beyond Assertions: Advanced Specification and Verification with JML and ESC/Java2

Chalin

Kiniry

Leavens

et al. 2006

Lecture Notes in Computer Science

157

120

View full text Add to dashboard Cite

Many state-based specification languages, including the Java Modeling Language (JML), contain at their core specification constructs familiar to most 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 (perhaps the less familiar) frame properties, datagroups, and ghost and model fields. These constructs help specifiers deal with potential problems related to, for example, unexpected side effects, aliasing, class invariants, inheritance, and lack of information hiding. This tutorial paper focuses on JML's realization of these constructs, explaining their meaning while illustrating how they can be used to address the stated problems. public class DigitalDisplayClock { 2 //@ public model long _time; 3 //@ private represents _time = getSecond()+getMinute()*60+getHour()*60*60; 4 5 //@ protected invariant time.length == 6; 6 //@ protected invariant 0 <= time[0] && time[0] <= 9; // sec 7 //@ protected invariant 0 <= time[1] && time[1] <= 5; // sec 8 //@ protected invariant 0 <= time[2] && time[2] <= 9; // min 9 //@ protected invariant 0 <= time[3] && time[3] <= 5; // min 10 //@ protected invariant 0 <= time[4] && time[4] <= 9; // hr 11 //@ protected invariant 0 <= time[5] && time[5] <= 2; // hr 12 //@ protected invariant time[5] == 2 ==> time[4] <= 3; // hr 13 protected /*@ non_null rep @*/ int[] time; // NB rep modifier 14 /*@ pure @*/ public DigitalDisplayClock() { 15 { time = new rep int [6]; } // NB rep modifier 16 17 //@ ensures 0 <= \result && \result <= 23; 18 public /*@ pure @*/ int getHour() { return time[5]*10 + time[4]; } 19 20 //@ ensures 0 <= \result && \result <= 59; 21 public /*@ pure @*/ int getMinute() { return time[3]*10 + time[2]; } 22

show abstract

Flexible Invariants through Semantic Collaboration

Polikarpova

Tschannen

Furia

et al. 2014

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Modular reasoning about class invariants is challenging in the presence of collaborating objects that need to maintain global consistency. This paper presents semantic collaboration: a novel methodology to specify and reason about class invariants of sequential object-oriented programs, which models dependencies between collaborating objects by semantic means. Combined with a simple ownership mechanism and useful default schemes, semantic collaboration achieves the flexibility necessary to reason about complicated inter-object dependencies but requires limited annotation burden when applied to standard specification patterns. The methodology is implemented in AutoProof, our program verifier for the Eiffel programming language (but it is applicable to any language supporting some form of representation invariants). An evaluation on several challenge problems proposed in the literature demonstrates that it can handle a variety of idiomatic collaboration patterns, and is more widely applicable than the existing invariant methodologies. The Perks and Pitfalls of InvariantsClass invariants 1 are here to stay [23]-even with their tricky semantics in the presence of callbacks and inter-object dependencies, which make reasoning so challenging [17]. The main reason behind their widespread adoption is that they formalize the notion of consistent class instance, which is inherent in object-orientated programming, and thus naturally present when reasoning, even informally, about program behavior.The distinguishing characteristic of invariant-based reasoning is stability: it should be impossible for an operation m to violate the invariant of an object o without modifying o itself. Stability promotes information hiding and simplifies client reasoning about preservation of consistency: without invariants a client would need to know which other objects o's consistency depends on, while with invariants it is sufficient that it checks whether m modifies o-a piece of information normally available as part of m's specification. The goal of an invariant methodology (also called protocol) is thus to achieve stability even in the presence of inter-object dependencies-where the consistency of o depends on the state of other objects, possibly recursively or in a circular fashion (see Sect. 2 for concrete examples).The numerous methodologies introduced over the last decade, which we review in Sect. 3, successfully relieve several difficulties involved in reasoning with invariants; but ⋆ Outline and contributions. The presentation is based on examples of non-hierarchical object structures, customarily used in the literature. Sect. 2 presents the examples and the challenges they embody; and Sect. 3 discusses the approaches taken by main existing invariant methodologies. Sect. 4 introduces SC, demonstrates its application to the running examples, and outlines a soundness proof. Sect. 5 evaluates both SC and existing protocols on an extended set of examples, including challenge problems from the SAVCBS workshop series [19]. The evaluation dem...

show abstract

Cooperation-based Invariants for OO Languages

Cited by 5 publications

References 6 publications

Invariants for Non-Hierarchical Object Structures

Invariants for Non-Hierarchical Object Structures

Beyond Assertions: Advanced Specification and Verification with JML and ESC/Java2

Flexible Invariants through Semantic Collaboration

Contact Info

Product

Resources

About