Modular invariants for layered object structures

Müller, Péter; Poetzsch-Heffter, Arnd; Leavens, Gary T.

doi:10.1016/j.scico.2006.03.001

Cited by 106 publications

(84 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A number of methodologies have been proposed for ownership-based hiding of invariants (e.g., [28]). Drossopoulou et al [11] introduce a general framework to describe verification techniques for invariants.…”

Section: Related Workmentioning

confidence: 99%

Dynamic Boundaries: Information Hiding by Second Order Framing with First Order Assertions

Naumann

Banerjee

2010

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. The hiding of internal invariants creates a mismatch between procedure specifications in an interface and proof obligations on the implementations of those procedures. The mismatch is sound if the invariants depend only on encapsulated state, but encapsulation is problematic in contemporary software due to the many uses of shared mutable objects. The mismatch is formalized here in a proof rule that achieves flexibility via explicit restrictions on client effects, expressed using ghost state and ordinary first order assertions.

show abstract

Section: Related Workmentioning

confidence: 99%

Dynamic Boundaries: Information Hiding by Second Order Framing with First Order Assertions

Naumann

Banerjee

2010

Programming Languages and Systems

View full text Add to dashboard Cite

show abstract

“…In this paper, we use a visible state semantics [26]; that is, invariants have to hold in all visible states. The notion of a visible state is determined by the specification language.…”

Section: Object Invariantsmentioning

confidence: 99%

“…See our earlier work [18,26] for a discussion of invariants for aggregate objects. Moreover, we do not consider method calls in invariants.…”

Section: Object Invariantsmentioning

confidence: 99%

See 1 more Smart Citation

Information Hiding and Visibility in Interface Specifications

Leavens

Miiller

2007

29th International Conference on Software Engineering (ICSE'07)

Self Cite

View full text Add to dashboard Cite

Information hiding controls which parts of a class are visible to non-privileged and privileged clients (e.g., subclasses). This affects detailed design specifications in two ways. First, specifications should not expose hidden class members. As noted in previous work, this is important because such hidden members are not meaningful to all clients. But it also allows changes to hidden implementation details without invalidating correctness proofs for client code, which is important for maintaining verified programs. Second, to enable sound modular reasoning, certain specifications must be visible to clients. We present rules for information hiding in specifications for Java-like languages, and demonstrate their application to the specification language JML. These rules restrict proof obligations to only mention visible class members, but retain soundness. This allows maintenance of implementations and their specifications without affecting client reasoning. KeywordsInformation hiding, visibility, behavioral interface specification language, proof obligation, public, protected, private, client, JML language AbstractInformation hiding controls which parts of a class are visible to non-privileged and privileged clients (e.g., subclasses). This affects detailed design specifications in two ways. First, specifications should not expose hidden class members. As noted in previous work, this is important because such hidden members are not meaningful to all clients. But it also allows changes to hidden implementation details without invalidating correctness proofs for client code, which is important for maintaining verified programs. Second, to enable sound modular reasoning, certain specifications must be visible to clients. We present rules for information hiding in specifications for Java-like languages, and demonstrate their application to the specification language JML. These rules restrict proof obligations to only mention visible class members, but retain soundness. This allows maintenance of implementations and their specifications without affecting client reasoning.

show abstract

“…However, the necessity to explicitly manipulate an object's validity increases the overhead of verification; therefore, [23] defines implicitly in which execution states an object's invariants must hold, based on an ownership model which is enforced by the type system.…”

Section: Hierarchic Shapes For Program Verificationmentioning

confidence: 99%

Types for Hierarchic Shapes

Drossopoulou

Clarke

Noble

2006

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. Heap entities tend to contain complex references to each other. To manage this complexity, types which express shapes and hierarchies have been suggested. We survey type systems which describe such hierarchic shapes, how these types are used for reasoning about programs, and applications in concurrent programming.Most imperative programs create and manipulate heap entities (objects, or records) which contain references to each other forming intricate topologies. This creates complexity, and makes programs difficult to understand and manipulate. Programmers, on the other hand, tend to think in terms of shapes, categorizations and hierarchies.Thus, in the last decade, types describing shapes and hierarchies have been proposed to express programming intuitions, to support verification, and for synchronization and optimizations. We will discuss types for hierarchic shapes in terms of object oriented programming, because, even though the ideas are applicable to any imperative language, most of the related research was conducted in the context of object oriented languages.

show abstract

Modular invariants for layered object structures

Cited by 106 publications

References 29 publications

Dynamic Boundaries: Information Hiding by Second Order Framing with First Order Assertions

Dynamic Boundaries: Information Hiding by Second Order Framing with First Order Assertions

Information Hiding and Visibility in Interface Specifications

Types for Hierarchic Shapes

Contact Info

Product

Resources

About