DOCSLIB.ORG

Eiffel Analysis, Design and Programming Language ECMA-367

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

ECMA-367 1st Edition / June 2005 Eiffel Analysis, Design and Programming Language Standard ECMA-367 1st Edition - June 2005 Eiffel Analysis, Design and Programming Language Ecma International Rue du Rhône 114 CH-1204 Geneva T/F: +41 22 849 6000/01 www.ecma-international.org Brief history Eiffel was originally designed, as a method of software construction and a notation to support that method, in 1985. The first implementation, from Eiffel Software (then Interactive Software Engineering Inc.), was commercially released in 1986. The principal designer of the first versions of the language was Bertrand Meyer. Other people closely involved with the original definition included Jean-Marc Nerson. The language was originally described in Eiffel Software technical documents that were expanded to yield Meyer’s book Eiffel: The Language in 1990-1991. The two editions of Object-Oriented Software Construction (1988 and 1997) also served to describe the concepts. (For bibliographical references on the documents cited see 3.6.) As usage of Eiffel grew, other Eiffel implementations appeared, including Eiffel/S and Visual Eiffel from Object Tools, Germany, EiffelStudio and Eiffel Envision from Eiffel Software, and SmartEiffel from LORIA, France. Eiffel today is used throughout the world for industrial applications in banking and finance, defense and aerospace, health care, networking and telecommunications, computer-aided design, game programming, and many other application areas. Eiffel is particularly suited for mission-critical developments in which programmer productivity and product quality are essential. In addition Eiffel is a popular medium for teaching programming and software engineering in universities. In 2002 Ecma International formed Technical Group 4 (Eiffel) of Technical Committee 39 (Programming and Scripting Languages). The Eiffel Analysis, Design and Programming Language Standard provides a precise definition of the language and ensures interoperability between implementations. The first of these benefits is of particular interest to implementors of Eiffel compilers and environments, who can rely on it as the reference on which to base their work; the second, to Eiffel users, for whom the Standard delivers a guarantee of compatibility between the products of different providers and of trust in the future of Eiffel. TG4 devised this Standard from June 2002 to April 2005, starting from material from the original and revised versions of the book Standard Eiffel (latest revision of Eiffel: The Language). During that period the Technical Group conducted fifteen face-to-face meetings and numerous phone meetings, in addition to extensive technical correspondence. The members of the committee have been: Karine Arnout (ETH, Zurich); Éric Bezault (Axa Rosenberg, Orinda); Paul Cohen (Generic, Stockholm), Dominique Colnet (LORIA, Nancy); Mark Howard (Axa Rosenberg, Orinda); Alexander Kogtenkov (Eiffel Software, Moscow); Bertrand Meyer (Eiffel Software, Santa Barbara, and ETH, Zurich); Christine Mingins (Monash University, Melbourne); Roger Osmond (EMC, Boston); Emmanuel Stapf (Eiffel Software, Santa Barbara); Kim Waldén (Generic, Stockholm). Observers having attended one or more of the meetings include Cyril Adrian (LORIA), Volkan Arslan (ETH), Paul Crismer (Groupe S, Brussels), Jocelyn Fiat (Eiffel Software, France), Randy John (Axa Rosenberg), Ian King (Eiffel Software), Philippe Ribet (LORIA), Julian Rogers (Eiffel Software), Bernd Schoeller (ETH), David Schwartz (Axa Rosenberg), Zoran Simic (Axa Rosenberg), Raphael Simon (Eiffel Software), Olivier Zendra (LORIA). The committee acknowledges the contributions of many people including David Hollenberg, Marcel Satchell, Richard O’Keefe and numerous others listed in the acknowledgments of the book Standard Eiffel. The editor of the standard is Bertrand Meyer. Emmanuel Stapf is the convener of TG4 (succeeding Christine Mingins, 2002-2003) and its secretary (succeeding Karine Arnout, 2002-2004). The final version of the document was prepared by Éric Bezault, Mark Howard, Alexander Kogtenkov, Bertrand Meyer and Emmanuel Stapf. This Ecma Standard has been adopted by the General Assembly of June 2005. Table of contents 1 Scope 1 1.1 Overview 1 1.2 “The Standard” 1 1.3 Aspects covered 1 1.4 Aspects not covered 1 2 Conformance 1 2.1 Definition 1 2.2 Compatibility and non-default options 2 2.3 Departure from the Standard 2 3 Normative references 2 3.1 Earlier Eiffel language specifications 2 3.2 Eiffel Kernel Library 2 3.3 Floating point number representation 2 3.4 Character set: Unicode 3 3.5 Character set: ASCII 3 3.6 Phonetic alphabet 3 4 Definitions 3 5 Notational conventions 3 5.1 Standard elements 3 5.2 Normative elements 3 5.3 Rules on definitions 3 5.4 Use of defined terms 4 5.5 Unfolded forms 4 5.6 Language description 4 5.7 Validity: “if and only if” rules 4 6 Acronyms and abbreviations 5 6.1 Name of the language 5 6.2 Pronunciation 5 7 General description 5 7.1 Design principles 5 7.2 Object-oriented design 6 7.3 Classes 6 7.4 Types 10 - i - 7.5 Assertions 11 7.6 Exceptions 13 7.7 Genericity 14 7.8 Inheritance 15 7.9 Polymorphism and dynamic binding 17 7.10 Combining genericity and inheritance 18 7.11 Deferred classes 20 7.12 Tuples and agents 21 7.13 Type- and void-safety 22 7.14 Putting a system together 23 8 Language specification 23 8.1 General organization23 8.2 Syntax, validity and semantics 24 8.2.1 Definition: Syntax, BNF-E 24 8.2.2 Definition: Component, construct, specimen 24 8.2.3 Construct Specimen convention 24 8.2.4 Construct Name convention 24 8.2.5 Definition: Terminal, non-terminal, token 24 8.2.6 Definition: Production 25 8.2.7 Kinds of production 25 8.2.8 Definition: Aggregate production 25 8.2.9 Definition: Choice production 25 8.2.10 Definition: Repetition production, separator 25 8.2.11 Basic syntax description rule 26 8.2.12 Definition: Non-production syntax rule 26 8.2.13 Textual conventions 26 8.2.14 Definition: Validity constraint 27 8.2.15 Definition: Valid 27 8.2.16 Validity: General Validity rule 27 8.2.17 Definition: Semantics 27 8.2.18 Definition: Execution terminology 27 8.2.19 Semantics: Case Insensitivity principle 28 8.2.20 Definition: Upper name, lower name 28 8.2.21 Syntax (non-production): Semicolon Optionality rule 28 8.3 The architecture of Eiffel software 29 8.3.1 Definition: Cluster, subcluster, contains directly 29 8.3.2 Definition: Terminal cluster, internal cluster 29 8.3.3 Definition: Universe 30 8.3.4 Validity: Class Name rule 30 8.3.5 Semantics: Class name semantics 30 8.3.6 Definition: System, root type name, root procedure name 30 8.3.7 Definition: Type dependency 30 8.3.8 Validity: Root Type rule 31 - ii - 8.3.9 Validity: Root Procedure rule 31 8.3.10 Definition: Root type, root procedure, root class 31 8.3.11 Semantics: System execution 32 8.3.12 Syntax : Class names 32 8.4 Classes 32 8.4.1 Definition: Current class 32 8.4.2 Syntax : Class declarations 32 8.4.3 Syntax : Notes 32 8.4.4 Semantics: Notes semantics 33 8.4.5 Syntax : Class headers 33 8.4.6 Validity: Class Header rule 33 8.4.7 Definition: Deferred class, effective class 33 8.4.8 Syntax : Obsolete marks 33 8.4.9 Semantics: Obsolete semantics 33 8.5 Features 34 8.5.1 Definition: Inherited, immediate; origin; redeclaration; introduce 34 8.5.2 Syntax : Feature parts 34 8.5.3 Feature categories: overview 34 8.5.4 Syntax : Feature declarations 35 8.5.5 Syntax : New feature lists 35 8.5.6 Syntax : Feature bodies 35 8.5.7 Validity: Feature Body rule 35 8.5.8 Definition: Variable attribute 36 8.5.9 Definition: Constant attribute 36 8.5.10 Definition: Routine, function, procedure 36 8.5.11 Definition: Command, query 37 8.5.12 Definition: Signature, argument signature of a feature 37 8.5.13 Feature principle 37 8.5.14 Syntax : Feature names 37 8.5.15 Syntax (non-production): Alias Syntax rule 38 8.5.16 Definition: Operator feature, bracket feature 38 8.5.17 Definition: Identifier of a feature name 38 8.5.19 Definition: Same feature name, same operator, same alias 39 8.5.20 Syntax : Operators 39 8.5.21 Validity: Assigner Command rule 40 8.5.22 Definition: Synonym 40 8.5.23 Definition: Unfolded form of a possibly multiple declaration 40 8.5.24 Validity: Feature Declaration rule 41 8.5.25 Validity: Alias Validity rule 42 8.6 The inheritance relation 43 8.6.1 Syntax : Inheritance parts 43 8.6.2 Definition: Parent part for a type, for a class 43 8.6.3 Definition: Multiple, single inheritance 43 - iii - 8.6.4 Validity: Class ANY rule 44 8.6.5 Validity: Universal Conformance principle 44 8.6.6 Definition: Unfolded Inheritance Part of a class 44 8.6.7 Definition: Inherit, heir, parent 45 8.6.8 Definition: Conforming, non-conforming parent 45 8.6.9 Definition: Ancestor types of a type, of a class 45 8.6.10 Definition: Ancestor, descendant 45 8.6.11 Definition: Proper ancestor, proper descendant 45 8.6.12 Validity: Parent rule 45 8.6.13 Syntax : Rename clauses 46 8.6.14 Validity: Rename Clause rule 46 8.6.15 Semantics: Renaming principle 47 8.6.16 Definition: Final name, extended final name, final name set 47 8.6.17 Definition: Inherited name 47 8.6.18 Definition: Declaration for a feature 47 8.7 Clients and exports 48 8.7.1 Definition: Client relation between classes and types 48 8.7.2 Definition: Client relation between classes 48 8.7.3 Definition: Indirect client 48 8.7.4 Definition: Supplier 48 8.7.5 Definition: Simple client 48 8.7.6 Definition: Expanded client 49 8.7.7 Definition: Generic client, generic supplier 49 8.7.8 Definition: Client set of a Clients part 49 8.7.9 Syntax
Recommended publications
  • LNCS 4119, Pp

    LNCS 4119, Pp

    Exceptions in Java and Eiffel: Two Extremes in Exception Design and Application Joseph R. Kiniry School of Computer Science and Informatics University College Dublin Belfield, Dublin 8, Ireland [email protected] Abstract. Exceptions are frequently a controversial language feature with both language designers and programmers. Exceptions are controversial because they complicate language semantics—and thus program design, testing, and verifica- tion—and some programmers find them annoying or difficult to use properly. By examining two programming languages that have very different, even opposing, exception mechanisms, a set of exception principles is introduced that summarize the key semantic and social issues surrounding exceptions. 1 Introduction The designers of future programming languages must decide whether to include excep- tions in their new languages. If they decide exceptions are warranted, they must then consider what exceptions represent: (1) a structure for control flow, (2) a structure for handling abnormal, unpredictable situations, or (3) something in-between. Additionally, the syntax and meaning of exceptions must be considered. The syntax of exception mechanisms is also important. Syntax impacts how program code looks and is comprehended, it influences the design and realization of algorithms, and it affects the manner in which programmers handle unusual cases and unexpected situations, and thus indirectly impacts software reliability. And, while the syntax of exception mechanisms is the aspect most programmers see, tool developers and lan- guage theoreticians must wrestle with exception semantics. In general, a small, elegant semantics is desired by all parties. One way to consider how to design a feature like exceptions in future languages is to analyze their design in today’s languages.
  • From Eiffel to the Java Virtual Machine

    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.
  • Volume 28 Number 1 March 2007

    Volume 28 Number 1 March 2007

    ADA Volume 28 USER Number 1 March 2007 JOURNAL Contents Page Editorial Policy for Ada User Journal 2 Editorial 3 News 5 Conference Calendar 38 Forthcoming Events 45 Articles C. Comar, R. Berrendonner “ERB : A Ravenscar Benchmarking Framework” 53 Ada-Europe 2006 Sponsors 64 Ada-Europe Associate Members (National Ada Organizations) Inside Back Cover Ada User Journal Volume 28, Number 1, March 2007 2 Editorial Policy for Ada User Journal Publication Original Papers Commentaries Ada User Journal – The Journal for the Manuscripts should be submitted in We publish commentaries on Ada and international Ada Community – is accordance with the submission software engineering topics. These published by Ada-Europe. It appears guidelines (below). may represent the views either of four times a year, on the last days of individuals or of organisations. Such March, June, September and All original technical contributions are articles can be of any length – December. Copy date is the first of the submitted to refereeing by at least two inclusion is at the discretion of the month of publication. people. Names of referees will be kept Editor. confidential, but their comments will Opinions expressed within the Ada Aims be relayed to the authors at the discretion of the Editor. User Journal do not necessarily Ada User Journal aims to inform represent the views of the Editor, Ada- readers of developments in the Ada The first named author will receive a Europe or its directors. programming language and its use, complimentary copy of the issue of the general Ada-related software Journal in which their paper appears. Announcements and Reports engineering issues and Ada-related We are happy to publicise and report activities in Europe and other parts of By submitting a manuscript, authors grant Ada-Europe an unlimited license on events that may be of interest to our the world.
  • Eiffel, Smarteiffel, Conception Par Objets, Programmation Par

    Eiffel, Smarteiffel, Conception Par Objets, Programmation Par

    Eiffel, SmartEiffel, conception par objets, programmation par objets, programmation par contrats, interface, g´en´ericit´e, liaison dynamique, simulation, et cætera. Dominique Colnet { [email protected] 11 juillet 2007 Avertissement Ce document en cours de r´edaction n'a pas la pr´etention d'^etre un ou- vrage complet et exhaustif sur la conception et la programmation par objets avec le langage Eiffel. Ce n'est pas un manuel de r´ef´erence du langage Eiffel ni la documentation du com- pilateur et des outils de SmartEiffel1. Il s'agit plut^ot d'un ensemble de notes de cours, d'une suite plus ou moins p´edagogique de transparents ainsi qu'une collection h´et´erog`ene d'exercices. Comme c'est souvent le cas pour les polycopi´es d'enseignement, le document actuel est constamment en cours de r´edaction. La premi`ere version de ce document doit dater des ann´ees 19902, date `a laquelle nous avons d´ecid´e d'utiliser Eiffel pour la licence d'in- formatique de l'Universit´e Henri Poincar´e (Nancy 1) ainsi qu’`a l'ESIAL (Ecole´ Sup´erieure d'Informatique et Applications de Lorraine). Toutes les suggestions seront les bienvenues (m^eme les corrections orthographiques). Ce document peut ^etre diffus´e reproduit et/ou modifi´e librement a` la seule condition d'indiquer sa provenance initiale et de laisser le pr´esent avertissement inchang´e. Si vous souhaitez disposer du texte source (LATEX) du document, il suffit de me le demander par mail ([email protected]). Table des mati`eres 1 Les premiers pas 3 1.1 Le premier programme .
  • Eiffelstudio: a Guided Tour

    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.
  • Technical Report

    Technical Report

    Proceedings of the ECOOP 2003 Workshop on Exception Handling in Object-Oriented Systems: Towards Emerging Application Areas and New Programmi Technical Report Department of Computer Science and Engineering University of Minnesota 4-192 EECS Building 200 Union Street SE Minneapolis, MN 55455-0159 USA TR 03-028 Proceedings of the ECOOP 2003 Workshop on Exception Handling in Object-Oriented Systems: Towards Emerging Application Areas and New Programmi Alexander Romanovsky, Christophe Dony, Jorgen Lindskov Knudsen, and Anand Tripathi July 01, 2003 Exception Handling in Object Oriented Systems: Towards Emerging Application Areas and New Programming Paradigms Workshop July 21, 2003 ECOOP 2003 ii Table of Contents Introduction.............................................................................................................................. v Workshop Organizers ............................................................................................................. vi Workshop Program................................................................................................................ vii Invited talk Getting Control of Exception (Abstract)......................................................................... 1 Papers Errors and Exceptions – Rights and Responsibilities..................................................... 2 Analyzing Exception Usage in Large Java Applications.............................................. 10 Bound Exceptions in Object Programming .................................................................
  • Debian Build Dependecies

    Debian Build Dependecies

    Debian build dependecies Valtteri Rahkonen valtteri.rahkonen@movial.fi Debian build dependecies by Valtteri Rahkonen Revision history Version: Author: Description: 2004-04-29 Rahkonen Changed title 2004-04-20 Rahkonen Added introduction, reorganized document 2004-04-19 Rahkonen Initial version Table of Contents 1. Introduction............................................................................................................................................1 2. Required source packages.....................................................................................................................2 2.1. Build dependencies .....................................................................................................................2 2.2. Misc packages .............................................................................................................................4 3. Optional source packages......................................................................................................................5 3.1. Build dependencies .....................................................................................................................5 3.2. Misc packages ...........................................................................................................................19 A. Required sources library dependencies ............................................................................................21 B. Optional sources library dependencies .............................................................................................22
  • Spest - a Tool for Specification-Based Testing

    Spest - a Tool for Specification-Based Testing

    SPEST - A TOOL FOR SPECIFICATION-BASED TESTING A Thesis presented to the Faculty of California Polytechnic State University, San Luis Obispo In Partial Fulfillment of the Requirements for the Degree Master of Science in Computer Science by Corrigan Johnson January 2016 !c 2016 Corrigan Johnson ALL RIGHTS RESERVED ii COMMITTEE MEMBERSHIP TITLE: SPEST - A Tool for Specification-Based Testing AUTHOR: Corrigan Johnson DATE SUBMITTED: January 2016 COMMITTEE CHAIR: Gene Fisher, Ph.D. Professor of Computer Science COMMITTEE MEMBER: David Janzen, Ph.D. Professor of Computer Science COMMITTEE MEMBER: John Clements, Ph.D. Associate Professor of Computer Science iii ABSTRACT SPEST - A Tool for Specification-Based Testing Corrigan Johnson This thesis presents a tool for SPEcification based teSTing (SPEST). SPEST is designed to use well known practices for automated black-box testing to reduce the burden of testing on developers. The tool uses a simple formal specification language to generate highly-readable unit tests that embody best practices for thorough software testing. Because the specification language used to generate the assertions about the code can be compiled, it can also be used to ensure that documentation describing the code is maintained during development and refactoring. The utility and effectiveness of SPEST were validated through several experiments conducted with students in undergraduate software engineering classes. The first experiment compared the understand- ability and efficiency of SPEST generated tests against student written tests based on the Java Modeling Language (JML)[25] specifications. JML is a widely used language for behavior program specification. A second experiment evaluated readability through a survey comparing SPEST generated tests against tests written by well established software developers.
  • Designing Efficient and Safe Weak References in Eiffel with Parametric

    Designing Efficient and Safe Weak References in Eiffel with Parametric

    Designing efficient and safe weak references in Eiffel with parametric types Frederic Merizen, Olivier Zendra, Dominique Colnet To cite this version: Frederic Merizen, Olivier Zendra, Dominique Colnet. Designing efficient and safe weak references in Eiffel with parametric types. [Intern report] A03-R-517 || merizen03a, 2003, pp.14. inria-00107752 HAL Id: inria-00107752 https://hal.inria.fr/inria-00107752 Submitted on 19 Oct 2006 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. Designing efficient and safe weak references in Eiffel with parametric types Frederic Merizen∗ Olivier Zendray Dominique Colnetz Emails: {merizen,zendra,colnet}@loria.fr LORIA 615 Rue du Jardin Botanique BP 101 54602 VILLERS-LES-NANCY Cedex FRANCE December 15, 2003 Abstract In this paper, we present our work on the design and implementation of weak references within the SmartEiffel project. We introduce the known concept of weak references, reminding how this peculiar kind of references can be used to optimize and fine-tune the memory behavior of programs, thus potentially speeding up their execution. We show that genericity (parametric types in Eiffel) is the key to implementing weak references in a statically-checked hence safer and more efficient way.
  • Object-Oriented Literate Programming

    Object-Oriented Literate Programming

    Object-Oriented Literate Programming By Ming Yu Zhao, B.Sc. A Thesis Submitted to the School of Graduate Studies in Partial Fulfilment of the Requirements for the Degree of Master of Science Department of Computing and Software McMaster University c Copyright by Ming Yu Zhao, August 2007 ii Master of Science (2007) McMaster University (Computing and Software) Hamilton, Ontario Title: Object-Oriented Literate Programming Author: Ming Yu Zhao, B.Sc. (Dalian University of Technology) Supervisor: Dr. Emil Sekerinski Number of pages: x, 179 Abstract During the past decades, programming methodology has seen an improvement by structured programming and object-oriented programming (OOP), leading to soft- ware that is more reliable and easier to develop. However, software engineers are still dealing with problems in processing associated documentation. Literate programming was introduced by Donald Knuth in the early 80's as an approach to produce pro- grams together with their documentation in a way that is aimed at consumption by humans rather than by compilers. However, dated and complex features, dependence on formatting and programming language, and a lack of methodology prevented the method from gaining in popularity. In this thesis, we propose an approach to \integrate" OOP with literate pro- gramming in order to present and document the whole design in a consistent and maintainable way. In our approach, both program code and corresponding documen- tation are generated from the same source. The resulting documentation consists of code chunks with detailed explanations, as well as automatically generated class diagrams with varying levels of detail. A tool, Spark, has been developed and applied to the design of a Transit Information System from requirement analysis to testing.
  • Diploma Thesis

    Diploma Thesis

    Eiffel SDL multimedia library (ESDL) DIPLOMA THESIS Till G. Bay 24th September 2003 Project Period: Monday, 2003-05-26 - Friday, 2003-09-26 Student: Till G. Bay ([email protected]) Student-No: 98-803-000 Supervising Assistant: Karine Arnout Supervising Professor: Bertrand Meyer 1 ETHZ D-INFK Eiffel SDL multimedia library (ESDL) - DIPLOMA THESIS Prof. Dr. Bertrand Meyer Till G. Bay Contents I Description 5 1 Project description 5 1.1 Overview ............................... 5 1.2 Scope of the work ........................... 6 1.3 Intended results ............................ 7 II Project Steps 8 2 Evaluation 8 2.1 Evaluation of SDL Wrappers .................... 8 2.1.1 Evaluation of EWG ..................... 8 2.1.2 Evaluation of jegl ....................... 8 2.1.3 Conclusion .......................... 9 2.2 Evaluation of existing multimedia libraries for Eiffel ....... 9 2.2.1 Evaluation of EiffelFURY .................. 9 2.2.2 Evaluation of Eiffel SDL .................. 10 2.2.3 Conclusion .......................... 10 3 Usability discussion 11 3.1 Demo Creation ............................ 11 3.2 Discussion of the found usability flaws ............... 12 4 Redesign 13 5 Applications 15 6 Extensions 16 III State and future of ESDL 17 IV Project Organization 22 7 Background material 22 7.1 Reading list .............................. 22 8 Project management 22 8.1 Objectives and priorities ....................... 22 8.1.1 Design objectives ....................... 22 8.1.2 Objectives for the intended results ............. 23 8.2 Criteria for success .......................... 23 8.3 Method of work ............................ 24 8.4 Quality management ......................... 24 8.4.1 Documentation ........................ 24 8.4.2 Validation steps ....................... 24 2 ETHZ D-INFK Eiffel SDL multimedia library (ESDL) - DIPLOMA THESIS Prof.
  • Automatic Verification of Eiffel Programs

    Automatic Verification of Eiffel Programs

    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by CiteSeerX Automatic Verification of Eiffel Programs Master Thesis By: Julian Tschannen Supervised by: Martin Nordio Prof. Bertrand Meyer Student Number: 02-715-498 Abstract Correctness of software systems can be proven by using static verification techniques. Static verifiers such as Spec# and ESC/Java have been developed for object-oriented languages. These verifiers have shown that static verification can be applied to object-oriented languages such as C# and Java. However, these verifiers are not easy to use, as they introduce many new concepts that programmers have to learn. To apply these verifiers to a real project, one has to modify existing code by adding contracts and annotations such as pure method marks or ownership information. Eiffel supports Design by Contract. Current libraries and programs are therefore already annotated with contracts. The goal of this thesis is to develop an automatic verifier for Eiffel which can prove existing code without the need of further annotations. The main features supported by the tool are agents and dynamic invocation. The tool, called EVE Proofs, translates Eiffel programs to Boogie and runs a fully automatic theorem prover to check correctness of the code. EVE Proofs is integrated in EVE, the Eiffel Verification Environment. This integration enables Eiffel programmers to use it directly from the programming environment. To reason about framing of routines, one needs modifies clauses. To prove existing Eiffel code, we implemented an automatic extraction of modifies clauses. Although the extraction of modifies clauses is limited, it enables us to prove examples with simple frame conditions.