Information Hiding and Visibility in Interface Specifications

Abstract

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.

Harmonic Paradigm

“…It's important because it affects design specifications. In other words, certain specifications should be visible whereas it doesn't cause hidden parts to expose [7].…”

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

“…Unlike I set , this is suitable to appear in the module interface, as a public invariant [23] or explicitly conjoined to the procedure specifications of SET . The client does not update the default value, null, of n.own.…”

A Unified Framework for Verification Techniques for Object Invariants

“…In our earlier paper [8], we discuss six verification techniques from the literature in terms of our framework, namely those by Poetzsch-Heffter [31], Huizing & Kuiper [14], Leavens & Müller [16], Müller et al [27], and Lu et al [23]. In this paper we concentrate on the techniques based on heap topologies [27,23], because those benefit most from the formalisation in our framework.…”

“…Some verification techniques exclude the pre-and post-states of so-called helper methods from the visible states [16,17]. Helper methods can easily be expressed in our framework by choosing different parameters for helper and non-helper methods.…”

“…To describe a verification technique applied to a program, we write the application of the components to class, method names, etc., D c : the property that may depend on fields declared in class c. The parameter c can be used, for instance, to prevent invariants from depending on fields declared in c's superclasses [16,27].…”