DOCSLIB.ORG

Data Persistence in Eiffel

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Data Persistence in Eiffel University of Kentucky UKnowledge Theses and Dissertations--Computer Science Computer Science 2016 Data Persistence in Eiffel Jimmy J. Johnson University of Kentucky, [email protected] Digital Object Identifier: https://doi.org/10.13023/ETD.2016.444 Right click to open a feedback form in a new tab to let us know how this document benefits ou.y Recommended Citation Johnson, Jimmy J., "Data Persistence in Eiffel" (2016). Theses and Dissertations--Computer Science. 51. https://uknowledge.uky.edu/cs_etds/51 This Doctoral Dissertation is brought to you for free and open access by the Computer Science at UKnowledge. It has been accepted for inclusion in Theses and Dissertations--Computer Science by an authorized administrator of UKnowledge. For more information, please contact [email protected]. STUDENT AGREEMENT: I represent that my thesis or dissertation and abstract are my original work. Proper attribution has been given to all outside sources. I understand that I am solely responsible for obtaining any needed copyright permissions. I have obtained needed written permission statement(s) from the owner(s) of each third-party copyrighted matter to be included in my work, allowing electronic distribution (if such use is not permitted by the fair use doctrine) which will be submitted to UKnowledge as Additional File. I hereby grant to The University of Kentucky and its agents the irrevocable, non-exclusive, and royalty-free license to archive and make accessible my work in whole or in part in all forms of media, now or hereafter known. I agree that the document mentioned above may be made available immediately for worldwide access unless an embargo applies. I retain all other ownership rights to the copyright of my work. I also retain the right to use in future works (such as articles or books) all or part of my work. I understand that I am free to register the copyright to my work. REVIEW, APPROVAL AND ACCEPTANCE The document mentioned above has been reviewed and accepted by the student’s advisor, on behalf of the advisory committee, and by the Director of Graduate Studies (DGS), on behalf of the program; we verify that this is the final, approved version of the student’s thesis including all changes required by the advisory committee. The undersigned agree to abide by the statements above. Jimmy J. Johnson, Student Dr. Raphael A. Finkel, Major Professor Dr. Miroslaw Truszczyński, Director of Graduate Studies Data Persistence in Eiffel DISSERTATION A dissertation submitted in partial fulfillment of the require- ments for the degree of Doctor of Philosophy in the College of Engineering at the University of Kentucky By Jimmy J. Johnson Lexington, Kentucky Director: Dr. Raphael A. Finkel Professor of Computer Science Lexington, Kentucky 2016 Copyright © Jimmy J. Johnson 2016 Abstract of Dissertation Data Persistence in Eiffel This dissertation describes an extension to the Eiffel programming language that provides automatic object persistence (the ability of programs to store objects and later recreate those ob- jects in a subsequent execution of a program). The mechanism is orthogonal to other aspects of the Eiffel language. The mechanism serves four main purposes: 1) it gives Eiffel programmers a needed service, filling a gap between serialization, which provides limited persistence functions and database-mapping, which is cumbersome to use; 2) it greatly reduces the coding burden in- curred by the programmer when objects must persist, allowing the programmer to focus instead on the business model; 3) it provides a platform for testing the benefits of orthogonal persistence in Eiffel, and 4) it furnishes a model for orthogonal persistence in other object-oriented lan- guages. During my research, I created a prototype implementation of the persistence mechanism using it effectively in several programs. Performance measurements showed acceptable perfor- mance with some increase in program memory usage. The prototype gives the programmer the ability to add automatic persistence to existing code with the addition of only a few lines of code. The size of this additional code remains constant regardless of the total number of lines of code in the project. Eiffel syntax remains unchanged and nonpersistent Eiffel code runs as is while incur- ring only a very small speed penalty. KEYWORDS: data persistence, orthogonal persistence, persistent programming language, object-oriented programming, Eiffel Jimmy J. Johnson November 9, 2016 Date Data Persistence in Eiffel By Jimmy J. Johnson Dr. Raphael A. Finkel Director of Dissertation Dr. Miroslaw Truszczyński Director of Graduate Studies November 9, 2016 Acknowledgements I would like to express my special appreciation to my advisor Dr. Raphael Finkel. His advice and encouragement have been invaluable. He put up with my zealousness for the Eiffel programming language and supported my use of it as a platform for this research. I greatly ap- preciate his dedication to my work and for the opportunity to study under him. I also want to thank Dr. Jerzy Jaromczyk, Dr. Miroslaw Truszczyński , and Dr. Victor Marek for their guidance, instruction, and encouragement during my studies and research. I want to thank Dr. Bertrand Meyer for his support as I began my graduate studies. Without him, I would not have had such a wonderful language in which to work, and this project may not have materialized. Mrs. Annie Meyer at Eiffel Software also provided much encour- agement as she liaised between Eiffel Software’s technical support team and me. Others at Eiffel Software and at ETH Zurich have been a great help as well and deserve my thanks. Emmanuel Stapf, Jocylyn Fiat, and Alexander Kogtenkov provided help with the Eiffel compiler and many other technical issues for which I am very grateful. Roman Schmock- er’s help with the Eiffel runtime was indispensable. Finally, I wish to thank my wife for tolerating my late-night research and programming and for mostly ignoring the ensuing grumpiness the next morning. She held the fort down, allow- ing me to focus on this research. iii Table of Contents Acknowledgements ......................................................................................................................... iii Table of Contents ............................................................................................................................ iv List of Tables .................................................................................................................................. vi List of Figures ................................................................................................................................ vii Chapter 1 Introduction ................................................................................................................ 1 1.1 Terminology ..................................................................................................................... 3 1.2 “Eiffel: The Language” ................................................................................................... 4 1.2.1 Eiffel terminology ................................................................................................ 4 1.2.2 A sample system .................................................................................................. 6 1.2.3 Classes.................................................................................................................. 6 1.2.4 Eiffel initialization rules....................................................................................... 8 1.2.5 Reference and value semantics ............................................................................ 8 1.2.6 Tuples ................................................................................................................. 10 1.2.7 Once features ..................................................................................................... 10 1.2.8 Design by Contract® ........................................................................................... 11 1.2.9 Void-safe Eiffel .................................................................................................. 13 1.2.10 Feature renaming ............................................................................................... 13 1.3 The persistence problem ................................................................................................. 14 1.3.1 Serialization ....................................................................................................... 15 1.3.2 Database mapping .............................................................................................. 16 1.4 Summary ........................................................................................................................ 17 1.5 Roadmap ........................................................................................................................ 18 Chapter 2 Interface and semantics ............................................................................................. 19 2.1 Interface classes.............................................................................................................. 19 2.2 Persistent and persistable ............................................................................................... 20 2.3 Example system.............................................................................................................. 21 2.3.1 Access to persistence and initialization ............................................................
Load more

Recommended publications
  • Assertions, Pre/Post- Conditions and Invariants
    9/14/12 Assertions, pre/post- conditions and invariants Section 2.1 in Walls and Mirrors Section 4.5 Rosen Programming as a contract n Specifying what each method does q Specify it in a comment before method's header n Precondition q What is assumed to be true before the method is executed q Caller obligation n Postcondition q Specifies what will happen if the preconditions are met q Method obligation 1 9/14/12 Class Invariants n A class invariant is a condition that all objects of that class must satisfy while it can be observed by clients n What about Points in Cloud? q boundaries? q center? What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } // what could you state here? 2 9/14/12 What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } //n >= limit //more? What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } //n >= limit //n is the smallest power of 2 >= limit 3 9/14/12 assert Using assert: assert n == 1; while (n < limit) { n = 2 * n; } assert n >= limit; When to use Assertions n We can use assertions to guarantee the behavior.
    [Show full text]
  • Sound Invariant Checking Using Type Modifiers and Object Capabilities
    Sound Invariant Checking Using Type Modifiers and Object Capabilities. Isaac Oscar Gariano Victoria University of Wellington [email protected] Marco Servetto Victoria University of Wellington [email protected] Alex Potanin Victoria University of Wellington [email protected] Abstract In this paper we use pre existing language support for type modifiers and object capabilities to enable a system for sound runtime verification of invariants. Our system guarantees that class invariants hold for all objects involved in execution. Invariants are specified simply as methods whose execution is statically guaranteed to be deterministic and not access any externally mutable state. We automatically call such invariant methods only when objects are created or the state they refer to may have been mutated. Our design restricts the range of expressible invariants but improves upon the usability and performance of our system compared to prior work. In addition, we soundly support mutation, dynamic dispatch, exceptions, and non determinism, while requiring only a modest amount of annotation. We present a case study showing that our system requires a lower annotation burden compared to Spec#, and performs orders of magnitude less runtime invariant checks compared to the widely used ‘visible state semantics’ protocols of D, Eiffel. We also formalise our approach and prove that such pre existing type modifier and object capability support is sufficient to ensure its soundness. 2012 ACM Subject Classification Theory of computation → Invariants, Theory of computation → Program verification, Software and its engineering → Object oriented languages Keywords and phrases type modifiers, object capabilities, runtime verification, class invariants Digital Object Identifier 10.4230/LIPIcs.CVIT.2016.23 1 Introduction Object oriented programming languages provide great flexibility through subtyping and arXiv:1902.10231v1 [cs.PL] 26 Feb 2019 dynamic dispatch: they allow code to be adapted and specialised to behave differently in different contexts.
    [Show full text]
  • The Contract Pattern Permission Granted to Copy for Plop ’97 Conference
    Copyright 1997, Michel de Champlain The Contract Pattern Permission granted to copy for PLoP ’97 Conference. All other rights reserved. Michel de Champlain Department of Computer Science University of Canterbury, Christchurch, New Zealand [email protected] http://www.cosc.canterbury.ac.nz/~michel 12 August 1997 Abstract This paper describes the Contract pattern, an idiom that lets you apply assertions to guarantee pre-conditions and post-conditions of methods and invariants on the state of objects. This pattern can be used to develop reliable classes by making the Design by Contract methodology—introduced by Meyer in the specific context of the Eiffel language—available in Java and possibly other object-oriented languages. Intent Provide an implementation of the Design by contract methodology [Meyer88] for developing reliable classes and create robust objects in Java. This programming pattern lets you apply assertions to guarantee the pre-conditions and post-conditions of methods and invariants on the state of objects. Also Known As Design by contract Motivation Sometimes it’s necessary to restrict a class interface because you don’t want to provide all the possible input combinations for all collaborators. One way to achieve this goal is to make minimal and consistent methods that impose pre-conditions on input parameters. Moreover, you might want to ensure the class behavior by imposing post-conditions before methods return. You might also need to make sure that the class is always in a stable state. Such an approach can result in reliable classes to create robust objects. Consider for example a bounded counter that has both a lower and upper bound.
    [Show full text]
  • Safely Creating Correct Subclasses Without Superclass Code Clyde Dwain Ruby Iowa State University
    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 2006 Modular subclass verification: safely creating correct subclasses without superclass code Clyde Dwain Ruby Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Ruby, Clyde Dwain, "Modular subclass verification: safely creating correct subclasses without superclass code " (2006). Retrospective Theses and Dissertations. 1877. https://lib.dr.iastate.edu/rtd/1877 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Modular subclass verification: Safely creating correct subclasses without superclass code by Clyde Dwain Ruby A dissertation submitted to the graduate faculty in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Major: Computer Science Program of Study Committee Gary T. Leavens, Major Professor Samik Basu Clifford Bergman Shashi K. Gadia Jonathan D. H. Smith Iowa State University Ames, Iowa 2006 Copyright © Clyde Dwain Ruby, 2006. All rights reserved. UMI Number: 3243833 Copyright 2006 by Ruby, Clyde Dwain All rights reserved. UMI Microform 3243833 Copyright 2007 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, MI 48106-1346 ii TABLE OF CONTENTS ACKNOWLEDGEMENTS .
    [Show full text]
  • 3. Design by Contract
    3. Design by Contract Oscar Nierstrasz Design by Contract Bertrand Meyer, Touch of Class — Learning to Program Well with Objects and Contracts, Springer, 2009. 2 Bertrand Meyer is a French computer scientist who was a Professor at ETH Zürich (successor of Niklaus Wirth) from 2001-2015. He is best known as the inventor of “Design by Contract”, and as the designer of the Eiffel programming language, which provides built-in for DbC. DbC was first described in a technical report by Meyer in 1986: https://en.wikipedia.org/wiki/Design_by_contract Who’s to blame? The components fit but the system does not work. Who’s to blame? The component developer or the system integrator? 3 DbC makes clear the “contract” between a supplier (an object or “component”) and its client. When something goes wrong, the contract states whose fault it is. This simplifies both design and debugging. Why DbC? > Design by Contract —documents assumptions (what do objects expect?) —simplifies code (no special actions for failure) —aids debugging (identifies who’s to blame) 4 As we shall see, DbC improves your OO design in several ways. First, contracts make explicit the assumptions under which an object (supplier) will work correctly. Second, they simplify your code, since no special action is required when things go wrong — the exception handling framework provides the necessary tools. Third, contracts help in debugging since errors are caught earlier, when contracts are violated, not when your program crashes because of an invalid state, and it is clear where to lay the blame for the violation (i.e., in the object or its client).
    [Show full text]
  • Lecture Notes in Computer Science
    Orthogonal Persistence Revisited Alan Dearle, Graham N.C. Kirby and Ron Morrison School of Computer Science, University of St Andrews, North Haugh, St Andrews, Fife KY16 9SX, Scotland {al, graham, ron}@cs.st-andrews.ac.uk Abstract. The social and economic importance of large bodies of programs and data that are potentially long-lived has attracted much attention in the commercial and research communities. Here we concentrate on a set of methodologies and technologies called persistent programming. In particular we review programming language support for the concept of orthogonal persistence, a technique for the uniform treatment of objects irrespective of their types or longevity. While research in persistent programming has become unfashionable, we show how the concept is beginning to appear as a major component of modern systems. We relate these attempts to the original principles of orthogonal persistence and give a few hints about how the concept may be utilised in the future. 1 Introduction The aim of persistent programming is to support the design, construction, maintenance and operation of long-lived, concurrently accessed and potentially large bodies of data and programs. When research into persistent programming began, persistent application systems were supported by disparate mechanisms, each based upon different philosophical assumptions and implementation technologies [1]. The mix of technologies typically included naming, type and binding schemes combined with different database systems, storage architectures and query languages. The incoherence in these technologies increased the cost both intellectually and mechanically of building persistent application systems. The complexity distracted the application builder from the task in hand to concentrate on mastering the multiplicity of programming systems, and the mappings amongst them, rather than the application being developed.
    [Show full text]
  • Persistent Programming and Object Oriented Databases
    l.l Persistent Programming and Object Oriented Databases Malcolm Atkinson and Ronald Morrison University of Glasgow University of St. Andrews Abstract Persistent Programming Languages are defined as those languages which allow any of their values to have lives of any duration. The first ten years of research into those languages are reviewed. The motivation for such languages has increased. There are significant technological developments pertinent to their implementation. To obtain the ir benefits requires a radical revision of the architecture of computer systems, and a major comm itment to the parad igm . Their potential as a foundation for im plementing operating systems and database systems is described, as well as their obvious use for writing long-lived and large scale applications. The paper concludes by examining some aspects of object orientation, to consider the solutions offered by the persistent paradigm. 1 Introduction It is now ten years since a group in Scotland began the implementation of a persistent programming language. This paper reviews the progress in those ten years, and then suggests the next major step in persistent programming research. The review concludes that persistent programming languages have the capability of supporting applications programs and many components currently thought of as system components. The next step will demonstrate the value of persistent languages as a foundation for system software. It will also realise the target of 'seamless' computing which that research began to explore ten years ago, and provide efficient implementation of this class of languages. Such a seamless system is expected to yield very large productivity improvements for the implementers of large app lication systems.
    [Show full text]
  • Napier88 Reference Manual Release 2.2.1
    Napier88 Reference Manual Release 2.2.1 July 1996 Ron Morrison Fred Brown* Richard Connor Quintin Cutts† Alan Dearle‡ Graham Kirby Dave Munro University of St Andrews, North Haugh, St Andrews, Fife KY16 9SS, Scotland. *Department of Computer Science, University of Adelaide, South Australia 5005, Australia. †University of Glasgow, Lilybank Gardens, Glasgow G12 8QQ, Scotland. ‡University of Stirling, Stirling FK9 4LA, Scotland. This document should be referenced as: “Napier88 Reference Manual (Release 2.2.1)”. University of St Andrews (1996). Contents 1 INTRODUCTION ............................................................................. 5 2 CONTEXT FREE SYNTAX SPECIFICATION.......................................... 8 3 TYPES AND TYPE RULES ................................................................ 9 3.1 UNIVERSE OF DISCOURSE...............................................................................................9 3.2 THE TYPE ALGEBRA..................................................................................................... 10 3.2.1 Aliasing............................................................................................................... 10 3.2.2 Recursive Definitions............................................................................................. 10 3.2.3 Type Operators...................................................................................................... 11 3.2.4 Recursive Operators ..............................................................................................
    [Show full text]
  • From Eiffel to the Java Virtual Machine
    From Eiffel to the Java Virtual Machine Adding a new language target to the EiffelStudio compiler Søren Engel, [email protected] Supervisor Dr. Joseph R. Kiniry Thesis submitted to The IT University of Copenhagen for the degree of Bachelor of Science in Software Development August 2012 Abstract Previous attemps has been made towards translating and executing programs written in Eiffel on the Java platform, as described in Baumgartner [1]. However, the generated Java code has not been easy to use in terms of interoperability between the two languages, due to the restrictions of the Java language. Due to the evolution of the Java language, the work presented in this thesis examines whether it is possible to simplify the translation model of Eiffel to Java. In doing so, this thesis describes a refined translation model that leverages on some of the new features of the Java language, such as the invokedynamic bytecode instruction. Moreover, in order to verify the correctness of the proposed translation model, a description follows on how the translation model may be integrated into the existing EiffelStudio compiler, in terms extending the back-end to target the Java platform. In regards of simplicity, it was found that by using new language features of Java, the translation model of Eiffel to Java could be simplified to the extend that it solves the known issues found in the solution presented in Baumgartner [1]. In trying to integrate the translation model into the existing EiffelStudio compiler, it was found that no public documentation exists which described the internal structure of the EiffelStudio compiler.
    [Show full text]
  • Chapter 3. the Persistent Programming Language, PS-Algol
    https://theses.gla.ac.uk/ Theses Digitisation: https://www.gla.ac.uk/myglasgow/research/enlighten/theses/digitisation/ This is a digitised version of the original print thesis. Copyright and moral rights for this work are retained by the author A copy can be downloaded for personal non-commercial research or study, without prior permission or charge This work cannot be reproduced or quoted extensively from without first obtaining permission in writing from the author The content must not be changed in any way or sold commercially in any format or medium without the formal permission of the author When referring to this work, full bibliographic details including the author, title, awarding institution and date of the thesis must be given Enlighten: Theses https://theses.gla.ac.uk/ [email protected] On The Utilisation of Persistent Programming Environments Richard Cooper A thesis submitted to the Faculty of Science, University of Glasgow For the degree of Doctor of Philosophy September, 1989 © R. L. Cooper, 1989 ProQuest Number: 10999281 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a com plete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. uest ProQuest 10999281 Published by ProQuest LLC(2018). Copyright of the Dissertation is held by the Author. All rights reserved. This work is protected against unauthorized copying under Title 17, United States C ode Microform Edition © ProQuest LLC.
    [Show full text]
  • Writing Cybersecurity Job Descriptions for the Greatest Impact
    Writing Cybersecurity Job Descriptions for the Greatest Impact Keith T. Hall U.S. Department of Homeland Security Welcome Writing Cybersecurity Job Descriptions for the Greatest Impact Disclaimers and Caveats • Content Not Officially Adopted. The content of this briefing is mine personally and does not reflect any position or policy of the United States Government (USG) or of the Department of Homeland Security. • Note on Terminology. Will use USG terminology in this brief (but generally translatable towards Private Sector equivalents) • Job Description Usage. For the purposes of this presentation only, the Job Description for the Position Description (PD) is used synonymously with the Job Opportunity Announcement (JOA). Although there are potential differences, it is not material to the concepts presented today. 3 Key Definitions and Concepts (1 of 2) • What do you want the person to do? • Major Duties and Responsibilities. “A statement of the important, regular, and recurring duties and responsibilities assigned to the position” SOURCE: https://www.opm.gov/policy-data- oversight/classification-qualifications/classifying-general-schedule-positions/classifierhandbook.pdf • Major vs. Minor Duties. “Major duties are those that represent the primary reason for the position's existence, and which govern the qualification requirements. Typically, they occupy most of the employee's time. Minor duties generally occupy a small portion of time, are not the primary purpose for which the position was established, and do not determine qualification requirements” SOURCE: https://www.opm.gov/policy-data- oversight/classification-qualifications/classifying-general-schedule-positions/positionclassificationintro.pdf • Tasks. “Activities an employee performs on a regular basis in order to carry out the functions of the job.” SOURCE: https://www.opm.gov/policy-data-oversight/assessment-and-selection/job-analysis/job_analysis_presentation.pdf 4 Key Definitions and Concepts (2 of 2) • What do you want to see on resumes that qualifies them to do this work? • Competency.
    [Show full text]
  • Eiffelstudio: a Guided Tour
    EiffelStudio: A Guided Tour Interactive Software Engineering 2 EIFFELSTUDIO: A GUIDED TOUR § Manual identification Title: EiffelStudio: A Guided Tour, ISE Technical Report TR-EI-68/GT. (Replaces TR-EI-38/EB.) Publication history First published 1993 as First Steps with EiffelBench (TR-EI-38/EB) and revised as a chapter of Eiffel: The Environment (TR-EI- 39/IE), also available as An Object-Oriented Environment (Prentice Hall, 1994, ISBN 0-13-245-507-2. Version 3.3.8, 1995. Version 4.1, 1997 This version: July 2001. Corresponds to release 5.0 of the ISE Eiffel environment. Author Bertrand Meyer. Software credits Emmanuel Stapf, Arnaud Pichery, Xavier Rousselot, Raphael Simon; Étienne Amodeo, Jérôme Bou Aziz, Vincent Brendel, Gauthier Brillaud, Paul Colin de Verdière, Jocelyn Fiat, Pascal Freund, Savrak Sar, Patrick Schönbach, Zoran Simic, Jacques Sireude, Tanit Talbi, Emmanuel Texier, Guillaume Wong-So; EiffelVision 2: Leila Ait-Kaci, Sylvain Baron, Sami Kallio, Ian King, Sam O’Connor, Julian Rogers. See also acknowledgments for earlier versions in Eiffel: The Environment (TR-EI-39/IE) Non-ISE: special thanks to Thomas Beale, Éric Bezault, Paul Cohen, Paul-Georges Crismer, Michael Gacsaly, Dave Hollenberg, Mark Howard, Randy John, Eirik Mangseth, Glenn Maughan, Jacques Silberstein. Cover design Rich Ayling. Copyright notice and proprietary information Copyright © Interactive Software Engineering Inc. (ISE), 2001. May not be reproduced in any form (including electronic storage) without the written permission of ISE. “Eiffel Power” and the Eiffel Power logo are trademarks of ISE. All uses of the product documented here are subject to the terms and conditions of the ISE Eiffel user license.
    [Show full text]