DOCSLIB.ORG

Algebraic Principles for Program Correctness Tools in Isabelle/HOL

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Algebraic Principles for Program Correctness Tools in Isabelle/HOL Algebraic Principles for Program Correctness Tools in Isabelle/HOL Victor B. F. Gomes Supervisor: Georg Struth Department of Computer Science University of Sheffield A thesis submitted for the degree of Doctor of Philosophy February 2016 i Acknowledgements I gratefully acknowledge the funding received from the CNPq through the programme Science without Border (CsF) to undertake my PhD. Foremost, I would like to express my sincere gratitude to my supervi- sor Prof. Georg Struth for all the support and guidance during these three exciting years. Without his assistance and constant feedback, this thesis would not have been possible. In addition, I would like to thank the rest of my research panel: Prof. Marian Georghe and Dr. Joab Winkler for their insigthful comments and questions. I would also like to thank my collegue Alasdair Armstrong for his constant assistance while I was learning Isabelle. As well as to all the attendees of the verification reading group for all the in-depth and memorable discussions: Dr. Brijesh Dongol, Dr. James Cranch, Dr. Kirill Bogdanov and Dr. Michael Laurence. I wish to thank Prof. Jos´eNuno Oliveira, Prof. Peter Jipsen, Dr. Wal- ter Guttmann and Dr. Damien Pous for interesting and insightful conversations during RAMiCS'14. I also thank Prof. Jeremy Gib- bons, Dr. Stephan Van Staden, Prof. Roland Backhouse, Prof. Carrol Morgan and Prof. Lindsay Groves for their discussions, suggestions and guidance during MPC'15. Thanks to all my collegues in the department: Jorge, Jos´e,Raluca, Fernando and Umberto. Special thanks to the Brazilian gang: Carol, Tiago, L´ucia,T´eo,Yuri, Hegler and Gustavo. I am especially grateful for my Sheffield friends and flatmates, who I was lucky to spend time with during my PhD: Annemie, Fred, Natalie, Galyia, Jamie, Girija and Theo (thanks for the proofreading). Agrade¸coem especial minha fam´ıliapelo apoio incondicional, for¸cae incentivo. Minha amada m~ae,meu pai companheiro e meus queridos irm~aose irm~as:Camilla, Larissa, Andr´e,Samuel e Luana. Abstract This thesis puts forward a flexible and principled approach to the development of construction and verification tools for imperative pro- grams, in which the control flow and the data level are cleanly sep- arated. The approach is inspired by algebraic principles and bene- fits from an algebraic semantics layer. It is programmed in the Is- abelle/HOL interactive theorem prover and yields simple lightweight mathematical components as well as program construction and veri- fication tools that are themselves correct by construction. First, a simple tool is implemented using Kleeene algebra with tests (KAT) for the control flow of while-programs, which is the most com- pact verification formalism for imperative programs, and their stan- dard relational semantics for the data level. A reference formalisation of KAT in Isabelle/HOL is then presented, providing three different formalisations of tests. The structured comprehensive libraries for these algebras include an algebraic account of Hoare logic for par- tial correctness. Verification condition generation and program con- struction rules are based on equational reasoning and supported by powerful Isabelle tactics and automated theorem proving. Second, the tool is expanded to support different programming fea- tures and verification methods. A basic program construction tool is developed by adding an operation for the specification statement and one single axiom. To include recursive procedures, KATs are expanded further to quantales with tests, where iteration and the specification statement can be defined explicitly. Additionally, a nondeterministic extension supports the verification of simple concurrent programs. Finally, the approach is also applied to separation logic, where the control-flow is modelled by power series with convolution as sepa- rating conjunction. A generic construction lifts resource monoids to assertion and predicate transformer quantales. The data level is cap- tured by concrete store-heap models. These are linked to the algebra by soundness proofs. A number of examples shows the tools at work. I hold the opinion that the construction of computer programs is a mathematical activity like the solution of differential equations, that programs can be derived from their specifications through mathematical insight, calculation, and proof, using algebraic laws as simple and elegant as those of elementary arithmetic. C. A. R. Hoare iii Contents Contents iv List of Figures vii 1 Introduction1 1.1 Contributions . .3 1.2 Outline . .7 1.3 Publications . .9 2 Technical Background 10 2.1 The while Programming Language . 11 2.2 Hoare Logic . 14 2.3 Weakest Preconditions . 15 2.4 Separation Logic . 17 2.5 Refinement Calculus . 17 I Construction and Verification of while Programs 19 3 Algebras for Program Correctness 20 3.1 Kleene Algebras . 20 3.2 Kleene Algebras with Tests . 23 3.3 Isabelle/HOL Formalisation . 25 3.4 Propositional Hoare Logic . 30 3.5 Demonic Refinement Algebras . 32 3.6 Loop Transformation Example . 36 3.7 Conclusions . 40 4 A Basic Verification Tool 41 4.1 Principles of Tool Design . 41 4.2 Data Flow Integration . 43 4.3 Euclid's Algorithms . 47 iv CONTENTS 4.4 Arrays and for Loops . 49 4.5 Procedures, Local Variables and Function Calls . 51 4.6 Conclusions . 55 5 A Refinement Tool 56 5.1 The Specification Statement . 56 5.2 Data Flow Integration . 58 5.3 Sum of Even Fibonacci Numbers . 60 5.4 Insertion Sort . 65 5.5 Conclusions . 67 6 Recursive Programs 70 6.1 Verification of Recursive Programs . 70 6.2 Binary Search . 74 6.3 Quantales and Program Transformations . 77 6.4 Conclusions . 79 7 Predicate Transformers Semantics 80 7.1 Alternative Semantics . 80 7.2 Backward Predicate Transformers . 81 7.3 Forward Predicate Transformers . 82 7.4 Relating Semantics . 83 7.5 Modal Kleene Algebras . 85 7.6 Domain Quantale . 88 7.7 Implementation in Isabelle/HOL . 91 7.8 Conclusions . 93 8 Nondeterministic Programs 94 8.1 Guarded Command Language (GCL)................ 94 8.2 Propositional Hoare Logic for GCL ................. 96 8.3 GCL Examples . 98 8.4 Parallelism by Nondeterminism . 99 8.5 Isabelle Implementation . 102 8.6 Examples . 103 8.7 Conclusions . 104 II Verification of while programs with Pointers 108 9 Separation Logic 109 9.1 Design Approach . 109 9.2 Partial Algebras . 111 v CONTENTS 9.3 Power Series and Convolution . 112 9.4 Assertion Quantale . 114 9.5 Predicate Transformer Quantales . 118 9.6 Verification Conditions . 119 9.7 Refinement Laws . 120 9.8 Relational Fault Model . 121 9.9 Modal Separation Algebras . 124 9.10 Conclusions . 127 10 Separation Logic Assertions 128 10.1 Assertions over Heaplets . 128 10.2 Tactics for Separation Logic . 131 10.3 Conclusions . 134 11 Programs with Pointers 135 11.1 Program State Integration . 135 11.2 Linked Lists . 138 11.3 Examples . 139 11.4 Constructing a Linked List Reversal Algorithm. 140 11.5 Conclusions . 143 12 Conclusion 144 12.1 Summary . 145 12.2 Future Work . 145 A Algebraic Structures 147 B Introduction to Isabelle/HOL 151 B.1 Proving in Isabelle . 151 B.2 Isabelle Axiomatic Type Class . 153 B.3 Isabelle Main Library . 154 B.4 Eisbach . 155 C Source Code 156 C.1 Kleene Algebras . 157 C.2 Kozen's Loop Transformation Theorem . 159 C.3 Refinement Kleene Algebra . 163 C.4 Correctness Tools . 165 References 177 vi List of Figures 1.1 Algebraic approach for programm correctness tools. .7 2.1 Big-step operational semantics of the while language . 12 2.2 Relational semantics of the while language . 13 2.3 Rules of Hoare logic . 15 2.4 The weakest liberal precondition operator for a while language . 16 2.5 Morgan's refinement laws . 18 3.1 Algebraic semantics for a while language. 24 3.2 Example of proof in Isar, co-simulation law for Kleene star. 27 3.3 Back's refinement atomicity theorem. 35 4.1 Principles of tool design . 42 4.2 The hoare tactic. 47 4.3 Euclid's algorithm. 48 4.4 Integer division algorithm. 48 4.5 Power algorithm . 50 4.6 Linear search algorithm . 52 4.7 Maximum function of two natural numbers . 54 5.1 Construction of the sum of even Fibonacci numbers program . 62 5.2 Sum of even Fibonacci numbers . 63 5.3 Verification of the sum of even Fibonacci numbers program . 64 5.4 Construction of insertion sort algorithm (excerpts) . 66 5.5 Insertion sort algorithm . 67 5.6 Verification of insertion sort algorithm (proof steps) . 68 6.1 Verification of binary search (annotated algorithm) . 76 7.1 Euclid's algorithm by weakest liberal precondition . 92 8.1 Verification of Euclid's greatest common divisor algorithm in GCL 99 8.2 Verification of maximum algorithm in GCL ............. 99 vii LIST OF FIGURES 8.3 The initialisation protocol example . 105 8.4 Mutual inclusion problem example . 106 10.1 Tactics for separation logic . 132 11.1 Deallocation of the first element in a list segment . 140 11.2 Linked list deallocation algorithm . 141 11.3 In situ linked list reversal algorithm by refinement . 142 11.4 In situ linked list reversal algorithm . 143 A.1 Algebraic structures . 149 B.1 Example of proof in Isar, co-simulation law for Kleene star. ..
Load more

Recommended publications
  • An Aggregate Computing Approach to Self-Stabilizing Leader Election
    An Aggregate Computing Approach to Self-Stabilizing Leader Election Yuanqiu Mo Jacob Beal Soura Dasgupta University of Iowa Raytheon BBN Technologies University of Iowa⇤ Iowa City, Iowa 52242 Cambridge, MA, USA 02138 Iowa City, Iowa 52242 Email: [email protected] Email: [email protected] Email: [email protected] Abstract—Leader election is one of the core coordination 4" problems of distributed systems, and has been addressed in 3" 1" many different ways suitable for different classes of systems. It is unclear, however, whether existing methods will be effective 7" 1" for resilient device coordination in open, complex, networked 3" distributed systems like smart cities, tactical networks, personal 3" 0" networks and the Internet of Things (IoT). Aggregate computing 2" provides a layered approach to developing such systems, in which resilience is provided by a layer comprising a set of (a) G block (b) C block (c) T block adaptive algorithms whose compositions have been shown to cover a large class of coordination activities. In this paper, Fig. 1. Illustration of three basis block operators: (a) information-spreading (G), (b) information aggregation (C), and (c) temporary state (T) we show how a feedback interconnection of these basis set algorithms can perform distributed leader election resilient to device topology and position changes. We also characterize a key design parameter that defines some important performance a separation of concerns into multiple abstraction layers, much attributes: Too large a value impairs resilience to loss of existing like the OSI model for communication [2], factoring the leaders, while too small a value leads to multiple leaders.
    [Show full text]
  • A Theory of Fault Recovery for Component-Based Models⋆
    A Theory of Fault Recovery for Component-based Models? Borzoo Bonakdarpour1, Marius Bozga2, and Gregor G¨ossler3 1 School of Computer Science, University of Waterloo Email: [email protected] 2 VERIMAG/CNRS, Gieres, France Email: [email protected] 3 INRIA-Grenoble, Montbonnot, France Email: [email protected] Abstract. This paper introduces a theory of fault recovery for component- based models. We specify a model in terms of a set of atomic components incrementally composed and synchronized by a set of glue operators. We define what it means for such models to provide a recovery mechanism, so that the model converges to its normal behavior in the presence of faults (e.g., in self-stabilizing systems). We present a sufficient condition for in- crementally composing components to obtain models that provide fault recovery. We identify corrector components whose presence in a model is essential to guarantee recovery after the occurrence of faults. We also for- malize component-based models that effectively separate recovery from functional concerns. We also show that any model that provides fault recovery can be transformed into an equivalent model, where functional and recovery tasks are modularized in different components. Keywords: Fault-tolerance; Transformation; Separation of concerns; BIP 1 Introduction Fault-tolerance has always been an active line of research in design and imple- mentation of dependable systems. Intuitively, tolerating faults involves providing a system with the means to handle unexpected defects, so that the system meets its specification even in the presence of faults. In this context, the notion of spec- ification may vary depending upon the guarantees that the system must deliver in the presence of faults.
    [Show full text]
  • Cs8603-Distributed Systems Syllabus Unit 3 Distributed Mutex & Deadlock Distributed Mutual Exclusion Algorithms: Introducti
    CS8603-DISTRIBUTED SYSTEMS SYLLABUS UNIT 3 DISTRIBUTED MUTEX & DEADLOCK Distributed mutual exclusion algorithms: Introduction – Preliminaries – Lamport‘s algorithm –Ricart-Agrawala algorithm – Maekawa‘s algorithm – Suzuki–Kasami‘s broadcast algorithm. Deadlock detection in distributed systems: Introduction – System model – Preliminaries –Models of deadlocks – Knapp‘s classification – Algorithms for the single resource model, the AND model and the OR Model DISTRIBUTED MUTUAL EXCLUSION ALGORITHMS: INTRODUCTION INTRODUCTION MUTUAL EXCLUSION : Mutual exclusion is a fundamental problem in distributed computing systems. Mutual exclusion ensures that concurrent access of processes to a shared resource or data is serialized, that is, executed in a mutually exclusive manner. Mutual exclusion in a distributed system states that only one process is allowed to execute the critical section (CS) at any given time. In a distributed system, shared variables (semaphores) or a local kernel cannot be used to implement mutual exclusion. There are three basic approaches for implementing distributed mutual exclusion: 1. Token-based approach. 2. Non-token-based approach. 3. Quorum-based approach. In the token-based approach, a unique token (also known as the PRIVILEGE message) is shared among the sites. A site is allowed to enter its CS if it possesses the token and it continues to hold the token until the execution of the CS is over. Mutual exclusion is ensured because the token is unique. In the non-token-based approach, two or more successive rounds of messages are exchanged among the sites to determine which site will enter the CS next. Mutual exclusion is enforced because the assertion becomes true only at one site at any given time.
    [Show full text]
  • Separation of Concerns in Multi-Language Specifications
    INFORMATICA, 2002, Vol. 13, No. 3, 255–274 255 2002 Institute of Mathematics and Informatics, Vilnius Separation of Concerns in Multi-language Specifications Robertas DAMAŠEVICIUS,ˇ Vytautas ŠTUIKYS Software Engineering Department, Kaunas University of Technology Student¸u 50, 3031 Kaunas, Lithuania e-mail: [email protected], [email protected] Received: April 2002 Abstract. We present an analysis of the separation of concerns in multi-language design and multi- language specifications. The basis for our analysis is the paradigm of the multi-dimensional sepa- ration of concerns, which claims that multiple dimensions of concerns in a design should be imple- mented independently. Multi-language specifications are specifications where different concerns of a design are implemented using separate languages as follows. (1) Target language(s) implement domain functionality. (2) External (or scripting, meta-) language(s) implement generalisation of the repetitive design features, introduce variations, and integrate components into a design. We present case studies and experimental results for the application of the multi-language specifications in hardware design. Key words: multi-language design, separation of concerns, meta-programming, scripting, hardwa- re design. 1. Introduction Today the high-level design of a hardware (HW) system is usually based either on the usage of the pure HW description language (HDL) (e.g., VHDL, Verilog), or the algo- rithmic one (e.g., C++, SystemC), or both. The emerging problems are similar for both, the HW and software (SW) domains. For example, the increasing complexity of SW and HW designs urges the designers and researchers to seek for the new design methodolo- gies.
    [Show full text]
  • Multi-Dimensional Concerns in Parallel Program Design
    Multi-Dimensional Concerns in Parallel Program Design Parallel programming is difficult, thus design patterns. Despite rapid advances in parallel hardware performance, the full potential of processing power is not being exploited in the community for one clear reason: difficulty of designing parallel software. Identifying tasks, designing parallel algorithm, and managing the balanced load among the processing units has been a daunting task for novice programmers, and even the experienced programmers are often trapped with design decisions that underachieve in potential peak performance. Over the last decade there have been several approaches in identifying common patterns that are repeatedly used in parallel software design process. Documentation of these “design patterns” helps the programmers by providing definition, solution and guidelines for common parallelization problems. Such patterns can take the form of templates in software tools, written paragraphs with detailed description, or even charts, diagrams and examples. The current parallel patterns prove to be ineffective. In practice, however, the parallel design patterns identified thus far [over the last two decades!] contribute little—if none at all—to development of non-trivial parallel software. In short, the parallel design patterns are too trivial and fail to give detailed guidelines for specific parameters that can affect the performance of wide range of complex problem requirements. By experience in the community, it is coming to a consensus that there are only limited number of patterns; namely pipeline, master & slave, divide & conquer, geometric, replicable, repository, and not many more. So far the community efforts were focused on discovering more design patterns, but new patterns vary a little and fall into range that is not far from one of the patterns mentioned above.
    [Show full text]
  • Using Architectural Styles in Design ‹ the Nature of Computation ‹ the Quality Concerns
    Which Architectural Style should be used? The selection of software architectural style should take into consideration of two factors: Using Architectural Styles in Design The nature of computation The quality concerns Lecture 6 U08182 © Peter Lo 2010 1 U08182 © Peter Lo 2010 2 In this lecture you will learn: The selection of software architectural style should take into consideration of two • Use of software architectural styles in design factors: • Selection of appropriate architectural style • The nature of the computation problem to be solved. e.g. the input/output data structure and features, the required functions of the system, etc. • Combinations of styles • The quality concerns that the design of the system must take into • Case studies consideration, such as performance, reliability, security, maintenance, reuse, • Case study 1: Keyword Frequency Vector (KFV) modification, interoperability, etc. • Case study 2: Keyword in Context (KWIC) 1 2 Characteristic Features of Architectural Behavioral Features of Architectural Styles Styles Control Topology Synchronicity Data Topology Data Access Mode Control/Data Interaction Topology Data Flow Continuity Control/Data Interaction Direction Binding Time U08182 © Peter Lo 2010 3 U08182 © Peter Lo 2010 4 Control Topology: Synchronicity: • How dependent are the components' action upon each other's control state? • What geometric form does the control flow for the systems of the style take? • Lockstep – One component's state implies the other component's state. • E.g. In the main-program-and-subroutine style, components must be organized must • Synchronous – Components synchronies at certain states to make sure they are in the be organized into a hierarchical structure. synchronized states at the same time in order to cooperate, but the relationships on other states are not predictable.
    [Show full text]
  • Preserving Separation of Concerns Through Compilation
    Preserving Separation of Concerns through Compilation A Position Paper Hridesh Rajan Robert Dyer Youssef Hanna Harish Narayanappa Dept. of Computer Science Iowa State University Ames, IA 50010 {hridesh, rdyer, ywhanna, harish}@iastate.edu ABSTRACT tempt the programmer to switch to another task entirely (e.g. Today’s aspect-oriented programming (AOP) languages pro- email, Slashdot headlines). vide software engineers with new possibilities for keeping The significant increase in incremental compilation time conceptual concerns separate at the source code level. For a is because when there is a change in a crosscutting concern, number of reasons, current aspect weavers sacrifice this sep- the effect ripples to the fragmented locations in the com- aration in transforming source to object code (and thus the piled program forcing their re-compilation. Note that the very term weaving). In this paper, we argue that sacrificing system studied by Lesiecki [12] can be classified as a small modularity has significant costs, especially in terms of the to medium scale system with just 700 classes and around speed of incremental compilation and in testing. We argue 70 aspects. In a large-scale system, slowdown in the de- that design modularity can be preserved through the map- velopment process can potentially outweigh the benefits of ping to object code, and that preserving it can have signifi- separation of concerns. cant benefits in these dimensions. We present and evaluate a Besides incremental compilation, loss of separation of con- mechanism for preserving design modularity in object code, cerns also makes unit testing of AO programs difficult. The showing that doing so has potentially significant benefits.
    [Show full text]
  • Versatility and Efficiency in Self-Stabilizing Distributed Systems
    Versatility and Efficiency in Self-Stabilizing Distributed Systems Stéphane Devismes To cite this version: Stéphane Devismes. Versatility and Efficiency in Self-Stabilizing Distributed Systems. Distributed, Parallel, and Cluster Computing [cs.DC]. Université Grenoble Alpes, 2020. tel-03080444v4 HAL Id: tel-03080444 https://hal.archives-ouvertes.fr/tel-03080444v4 Submitted on 21 Sep 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. HABILITATION À DIRIGER DES RECHERCHES Spécialité : Informatique Arrêté ministériel : 23 Novembre 1988 Présentée par Stéphane Devismes Habilitation préparée au sein du laboratoire VERIMAG et de l’École Doctorale Mathématiques, Sciences et Technologies de l’Information, Informatique Versatility and Efficiency in Self-Stabilizing Distributed Systems Généralité et Efficacité dans les Systèmes Distribués Autostabilisants Habilitation soutenue publiquement le 17 décembre 2020, devant le jury composé de : Denis TRYSTRAM Professeur, Grenoble INP, Président Toshimitsu MASUZAWA Professeur, Osaka University, Rapporteur Achour MOSTÉFAOUI
    [Show full text]
  • Separation of Concerns for Dependable Software Design
    Separation of Concerns for Dependable Software Design Daniel Jackson and Eunsuk Kang MIT Computer Science and Artificial Intelligence Laboratory 32 Vassar Street, Cambridge, MA 02139 [email protected] ABSTRACT tiously includes collection of detailed statistics and explicit mechanisms for adjusting the process accordingly. For ‘mixed-criticality’ systems that have both critical and non-critical functions, the greatest leverage on dependabil- Testing is used for two very different purposes. On the one ity may be at the design level. By designing so that each hand, it is used to find bugs. Structural tests exploit knowl- critical requirement has a small trusted base, the cost of the edge of the structure of the software to identify bugs in analysis required for a dependability case might be dra- known categories. A mutation test, for example, might fo- matically reduced. An implication of this approach is that cus on the possibility that the wrong operator was selected conventional object-oriented design may be a liability, be- for an expression; a regression test is designed to detect the cause it leads to ‘entanglement’, and an approach based on reoccurrence of a particular flaw. For this kind of testing, a separating services may be preferable. successful test is one that fails, and thus identifies a bug. Categories and Subject Descriptors On the other hand, testing can be used to provide evidence D.2.2 [Software Engineering]: Design Tools and Tech- of dependability. In this case, tests focused on particular niques; D.2.4 Software/Program Verification; D.2.10 De- known bug categories are less useful (since a failure might sign.
    [Show full text]
  • Session 8: from Analysis and Design to Software Architectures (Part I Addendum)
    Software Engineering G22.2440-001 Session 8 – Sub-Topic 1 From Analysis and Design to Software Architectures (Part I Addendum) Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Agenda • Towards Agile Enterprise Architecture Models • Building an Object Model Using UML • Architectural Analysis • Design Patterns • Architectural Patterns • Architecture Design Methodology • Achieving Optimum-Quality Results • Selecting Kits and Frameworks • Using Open Source vs. Commercial Infrastructures 2 1 Part I Towards Agile Enterprise Architecture Models 3 There is an Urgent Need for More Reliable, Concept-driven, Early Requirements Processes (review) • SDLC Process model frameworks have matured and converged significantly on effective practices in system development phases, however, they are still weakest on the front-end. RUP Phases: Inception ElaborationConstruction Transition • Project Planning • Hi-level languages • QA Methods • ??? • Use Case Models • Frameworks • Test environments •… • Object Models •IDEs • Issue support tools • Data Models • n-Tier Architectures • Usability • UI prototypes • Design Patterns Engineering •… •… •… MSF Phases: Envisioning PlanningDeveloping Stabilizing / Deploying Less mature methods / support More mature methods / support 4 2 XP Practices (review) • The Planning Game – determine the scope of the next release, based on business priorities and technical estimates. • Small Releases – every release should be as small as possible, containing the most valuable business requirements. • Metaphor – guide all development with a simple, shared story of how the whole system works. • Simple Design – design for the current functionality, not future needs, and make the design as simple as possible for that functionality (YAGNI). • Refactoring – ongoing redesign of software to improve its responsiveness to change. • Testing – developers write the unit tests before the code; unit tests are run “continuously”; customers write the functional tests.
    [Show full text]
  • The Shadow Knows: Refinement and Security in Sequential Programs *
    Science of Computer Programming Volume 74, Issue 8, 1 June 2009, Pages 629-653 Special Issue on Mathematics of Program Construction (MPC 2006) The Shadow Knows: Refinement and security in sequential programs Carroll Morgan 1 Sch. Comp. Sci. & Eng., Uni. NSW, Sydney 2052 Australia Abstract Stepwise refinement is a crucial conceptual tool for system development, encour- aging program construction via a number of separate correctness-preserving stages which ideally can be understood in isolation. A crucial conceptual component of security is an adversary’s ignorance of concealed information. We suggest a novel method of combining these two ideas. Our suggestion is based on a mathematical definition of “ignorance-preserving” refinement that extends classical refinement by limiting an adversary’s access to concealed information: moving from specification to implementation should never increase that access. The novelty is the way we achieve this in the context of se- quential programs. Specifically we give an operational model (and detailed justification for it), a basic sequential programming language and its operational semantics in that model, a “logic of ignorance” interpreted over the same model, then a program-logical semantics bringing those together — and finally we use the logic to establish, via refinement, the correctness of a real (though small) protocol: Rivest’s Oblivious Transfer. A previous report treated Chaum’s Dining Cryptoraphers similarly. In passing we solve the Refinement Paradox for sequential programs. Key words: Security, privacy, Hoare logic, specification, implementation, logic of knowledge This is an extension of an earlier report [1]. Email address: [email protected] (Carroll Morgan). 1 We acknowledge the support of the Aust.
    [Show full text]
  • A Structured Programming Approach to Data Ebook
    A STRUCTURED PROGRAMMING APPROACH TO DATA PDF, EPUB, EBOOK Coleman | 222 pages | 27 Aug 2012 | Springer-Verlag New York Inc. | 9781468479874 | English | New York, NY, United States A Structured Programming Approach to Data PDF Book File globbing in Linux. It seems that you're in Germany. De Marco's approach [13] consists of the following objects see figure : [12]. Get print book. Bibliographic information. There is no reason to discard it. No Downloads. Programming is becoming a technology, a theory known as structured programming is developing. Visibility Others can see my Clipboard. From Wikipedia, the free encyclopedia. ALGOL 60 implementation Call stack Concurrency Concurrent programming Cooperating sequential processes Critical section Deadly embrace deadlock Dining philosophers problem Dutch national flag problem Fault-tolerant system Goto-less programming Guarded Command Language Layered structure in software architecture Levels of abstraction Multithreaded programming Mutual exclusion mutex Producer—consumer problem bounded buffer problem Program families Predicate transformer semantics Process synchronization Self-stabilizing distributed system Semaphore programming Separation of concerns Sleeping barber problem Software crisis Structured analysis Structured programming THE multiprogramming system Unbounded nondeterminism Weakest precondition calculus. Comments and Discussions. The code block runs at most once. Latest Articles. Show all. How any system is developed can be determined through a data flow diagram. The result of structured analysis is a set of related graphical diagrams, process descriptions, and data definitions. Therefore, when changes are made to that type of data, the corresponding change must be made at each location that acts on that type of data within the program. It means that the program uses single-entry and single-exit elements.
    [Show full text]