Modular verification of higher-order methods with mandatory calls specified by model programs

Shaner, Steve M.

doi:10.31274/etd-180810-2447

Cited by 9 publications

(23 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our technique for checking whether a program refines a specification in Tisa is similar to the work of Shaner, Leavens and Naumann [15]. An implementation refines a specification if it meets two criteria: first, that the code and specification are structurally similar and second, that the body of every refining expression obeys the specification it is refining.…”

Section: Verifying Refinementmentioning

confidence: 94%

“…The most general form of specification expression is requires sp 1 ensures sp 2 , where sp 1 is a precondition expression and sp 2 is a postcondition. Such a specification expression hides program details by specifying that a correct implementation contains a refining expression whose body expression, when started in a state that satisfies sp 1 , will terminate in a state that satisfies sp 2 [15].…”

Section: Specification Constructsmentioning

confidence: 99%

“…Wasserman and Blum [31] also use a restricted form of greybox specifications for verification. Tyler and Soundarajan [32] and most recently Shaner, Leavens, and Naumann [15] have used greybox specifications for verification of methods that make mandatory calls to other dynamically-dispatched methods. Compared to these related ideas, to the best of our knowledge our work is the first to consider greybox specifications as a mechanism to decouple verification of web services without exposing all of their implementation details.…”

Section: Related Workmentioning

confidence: 99%

“…We show how to resolve this conflict using greybox specifications. Our language, Tisa, supports specification of policies specified in a variant of linear temporal logic [14], greybox specification [11] and a simple notion of refinement [12,13,15] for modular reasoning about correctness of implementations with respect to such policies. As usual, implementations are hidden, but policies and greybox specifications are public.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Tisa: A Language Design and Modular Verification Technique for Temporal Policies in Web Services

Rajan

Tao

Shaner

et al. 2009

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. Web services are distributed software components, that are decoupled from each other using interfaces with specified functional behaviors. However, such behavioral specifications are insufficient to demonstrate compliance with certain temporal non-functional policies. An example is demonstrating that a patient's health-related query sent to a health care service is answered only by a doctor (and not by a secretary). Demonstrating compliance with such policies is important for satisfying governmental privacy regulations. It is often necessary to expose the internals of the web service implementation for demonstrating such compliance, which may compromise modularity. In this work, we provide a language design that enables such demonstrations, while hiding majority of the service's source code. The key idea is to use greybox specifications to allow service providers to selectively hide and expose parts of their implementation. The overall problem of showing compliance is then reduced to two subproblems: whether the desired properties are satisfied by the service's greybox specification, and whether this greybox specification is satisfied by the service's implementation. We specify policies using LTL and solve the first problem by model checking. We solve the second problem by refinement techniques.

show abstract

Section: Verifying Refinementmentioning

confidence: 94%

Section: Specification Constructsmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Tisa: A Language Design and Modular Verification Technique for Temporal Policies in Web Services

Rajan

Tao

Shaner

et al. 2009

Programming Languages and Systems

View full text Add to dashboard Cite

show abstract

“…al. have extended JML for higher-order methods (HOM) [37]. They define a higher-order method as any method whose behaviour critically depends on one or more mandatory calls.…”

Section: Grey Box Verification Techniquesmentioning

confidence: 99%

Computational contracts

Scholliers

Tanter

Meuter

2015

Science of Computer Programming

View full text Add to dashboard Cite

Pre/post contracts for higher-order functions, as proposed by Findler and Felleisen and provided in Racket, allow run-time verification and blame assignment of higher-order functions. However these contracts treat contracted functions as black boxes, allowing verification of only input and output. It turns out that many interesting concerns about the behaviour of a function require going beyond that black-box approach, in order to control the actual computation that follows from a function. Examples are prohibiting or verifying that certain functions are called, checking access permissions, time or memory constraints, interaction protocols, etc. To address this need for grey-box verification, while preserving support for higher-order programming and blame assignment, we introduce the notion of computational contracts. A computational contract is a contract over the execution of a contracted entity.We show various applications of computational contracts, and explain how to assign blame in case of a violation. Computational contracts have been integrated with the existing contract system of Racket. Computational contracts is the first contract model with blame assignment in a higher-order setting that provides a systematic way to perform grey box verification.

show abstract

Separating Obligations of Subjects and Handlers for More Flexible Event Type Verification

Sánchez

Leavens

2013

Software Composition

View full text Add to dashboard Cite

Abstract. Implicit invocation languages, like aspect-oriented languages, automate the Observer pattern, which decouples subjects (base code) from handlers (advice), and then compound them together in the final system. For such languages, event types have been proposed as a way of further decoupling subjects from handlers. In Ptolemy, subjects explicitly announce events at certain program points, and pass the announced piece of code to the handlers for its eventual execution. This implies a mutual dependency between subjects and handlers that should be considered in verification; i.e., verification of subject code should consider the handlers and vice versa. However, in Ptolemy the event type defines only one obligation that both the handlers and the announced piece of code must satisfy. This limits the flexibility and completeness of verification in Ptolemy. That is, some correct programs cannot be verified due to specification mismatches between the announced code and the handlers' code. For example, when the announced code does not satisfy the specification of the entire event and handlers must make up the difference, or when the announced code has no effect, imposing a monotonic behavior on the handlers. In this paper we propose an extension to the specification features of Ptolemy that explicitly separates the specification of the handlers from the specification of the announced code. This makes verification in our new language PtolemyRely more flexible and more complete, while preserving modularity.

show abstract

Modular verification of higher-order methods with mandatory calls specified by model programs

Cited by 9 publications

References 10 publications

Tisa: A Language Design and Modular Verification Technique for Temporal Policies in Web Services

Tisa: A Language Design and Modular Verification Technique for Temporal Policies in Web Services

Computational contracts

Separating Obligations of Subjects and Handlers for More Flexible Event Type Verification

Contact Info

Product

Resources

About