DOCSLIB.ORG

Ten Commandments Revisited a Ten-Year Perspective on the Industrial Application of Formal Methods

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ten Commandments Revisited a Ten-Year Perspective on the Industrial Application of Formal Methods Ten Commandments Revisited A Ten-Year Perspective on the Industrial Application of Formal Methods Jonathan P. Bowen Michael G. Hinchey London South Bank University NASA Software Engineering Laboratory Institute for Computing Research, Faculty of BClM Goddard Space Flight Center Borough Road, London SEI OAA, UK Greenbelt, MD, USA www.jpbowen.com sel.gsfc.nasa.gov [email protected] [email protected] ABSTRACT We, as the formal methods community, are (presumably) Ten years ago, our 1995 paper Ten Commandments of Formal convinced of the validity of formal approaches to software Methods [5] suggested some guidelines to help ensure the success of specification, design, implementation, and subsequent maintenance. a formal methods project. It proposed ten important requirements In fact, it seems a logical argument to “Formal Methodists”, for (or “commandments”) for formal developers to consider and follow, whom formal methods are a “religion,” that the introduction of based on our knowledge of several industrial application success greater rigor into software development will result in improvements stories, most of which have been reported in more detail in two both in the software itself and in the development process. books [17],[18]. The paper was surprisingly popular, is still widely Unfortunately, the rest of the world (and the software referenced, and used as required reading in a number of formal engineering community, in particular) has not been convinced on a methods courses. However, not all have agreed with some of our wide scale, despite a significant number of success stories [17],[ IS]. commandments, feeling that they may not be valid in the long-term. At least their existence is now acknowledged by most [8], and their We re-examine the original commandments ten years on, and usehlness is accepted by some [41]. Certain aspects of formal consider their validity in the light of a fiuther decade of industrial methods, such as assertions in programs [20], are widely used, best practice and experiences. although not as much as originally anticipated. However, many myths regarding formal methods, first identified as far back as 15 Categories and Subject Descriptors years ago [6],[ 161 still abound. D.3.3 [Sofhvarek’rogram Verification]: Formal methods. Holloway [22] points out that the typical argument in favor of formal methods (that software is bad, unique, and discontinuous; General Terms that testing is inadequate; and that formal methods are essential to Design, Economics, Experimentation, Human Factors, avoid design flaws) is logically flawed, and unnecessarily complex Standardization, Languages, Theory, Verification. (in logical terms). He proposes a simpler argument, which is both simple and logically valid: software engineers want to be “real” engineers; such engineers apply mathematics; and since formal Keywords methods is the mathematics of software engineering, software Formal methods, correctness, industrial application, software engineers should use formal methods. engineering. Nevertheless, formal methods are still not widely used outside the specialized formal methods community. Our original Ten 1. INTRODUCTION Commandments of Formal Methods [5] were aimed at encouraging the practical use of formal methods among the software engineering It is clear to the best minds in the field that a more community as a whole, and, more importantly, to provide some ma~heniaticalapproach is needed for sofiare to advance practical guidance to formal methods practitioners based on insights much. received fiom a number of real-life projects, many of which were - Bertrand Meyer reported in [17],[18]. The hture of foimal methods was also considered by others at around the same time [lo]. Given the lack of acceptance of the use of formal methods outside our own specialized group of people, the former was at best a vely limited success (or perhaps even a failure!). But we were considerably more successful in achieving the latter goal. Copyright 2005 Association for Computing Machinery. ACM acknowledges that this contribution was authored or co-authored by a Over the intervening ten years, we have received many contractor or affiliate of the U.S. Government. As such, the Government comments and much feedback on our “commandments”. They have retains a nonexclusive, royalty-free right to publish or reproduce this been widely cited, and included in several textbooks (e.g., see [36]) article, or to allow others to do so, for Government purposes only. and are recommended (or even required) reading for a number of FMCS’O5,September 54,2005,Lisbon, Portugal. academic courses. Naturally, not everyone agrees with all of them. Copyright 2005 ACM 1 -59593-148-1/05/0009...$5.00. They did not do so when we first published them in 1995, pointing However, the original intent of our commandment (“thou shalt out that many of them would not necessarily hold in the long term, choose an appropriate notation”) concerned a notation that was not so it is not surprising that not everyone agrees with them now. “appropriate” in the sense that it was easily understood by non- this paper, we the T~~ Commandmentsof Formal specialists, but “appropriate” in that it was useful in describing the Methods in the light of a further ten years of industrial best practice. at hand in a manner *at fits with that system. While several of the more ..popular notations (ex...- B. Z. CCS. CSP) have emerged and have widespread applicability to a broad range of Any intelligeni fool can make ihings bigger and more classes of system, it has been found in many cases that a complex ... It takes a touch of genius and a lot of courage io combination of languages is needed to adequately address all move in the opposite direction. aspects of a larger system. It has been argued that no single notation - Albert Einstein (1879-1955) will ever be suitable to address all aspects of a complex system, with the implication that future systems will require combinations of model-based methods, process algebras, and temporal (and other) logics, in particular as we build more sophisticated, advanced, and 2. REVISITING THE COMMANDMENTS ambitious systems. Table 1 illustrates just some of the wide range of “hybrid” formal He proclaimed to you his covenant, which he commanded methods that have emerged over the last decade, indicating a need to you to keep: the Ten Commandments, which he wrote on augment existing notations with concepts that address specific two tablets of sione. aspects of a system. These vary in the means by which they are - Deut.4:13, 10:4, Ex.34:28 combined, which we categorize as:’ Viewpoints (loosely coupled): different notations are used to present different “views” of a system with each notation I. Thou shalt choose an appropriate making emphasis of, or understand of, a particular aspect of notation. the system (e.g., representing timing constraints) [9]. Method Integration (close coupling): several different Notations are a 3equent complaint ... but ihe real problem notations (both formal and informal or semi-formal) are is to understand the meaning andproperties of the symbols used with (manual or automatic) translation between and how they may and may not be manipulated, and to gain notations being used both to provide a semantics for the less fluency in using ihem io express new problems, solutions formal notations and to enable graphical (or other) and prooji. Final&* you will cultivate an appreciation of presentations that are well-understood, while simultaneously mathematical elegance and style. By that time, the symbols affording the benefits of formal verification [40]. will be invisible; you will see straight through them to what Integrated Methods (tight couplingJ: multiple notations are they mean. The great advantage of mathematics is that the used along with a single notation (e.g., propositional logic) rules are simpler than those of natural language, and the used to give a uniform semantics to each notation [46]. vocabulary is much smaller. Consequent&, when presented with someihing unfamiliar it is possible to work out a At the time we published [5], method integration was very solution for yourself; by logical deduction and invention popular and it seemed that there would be a greater move towards rather than by consulting boob or experts. Integrated Methods. While certainly there has been more progress in these fields, it seems that a Viewpoints approach has been winning - C.A.R. Hoare out, perhaps due to reluctance by industry to take up full formal proof (that the more coupled approaches would support) and The use of mathematical notation is often cited as a reason for reluctance to get involved in semantic details. The Integrated the slow uptake of formal methods and an inhibitor to their Formal Methoak conference [2] continues to provide a forum for successful use in industrial applications. However, as we pointed out this research topic. in [6], the mathematics of formal methods are actually relatively Choosing thc right notation can great aid in abstraction, in simple, and exploits notations and concepts that should be well- hiding unnecessar); detail and unnecrssar?; complexity, where is understood by computing professionals (set theory, propositional where (many argue) the leal benefit offonnal melhods ci most be and predicate logic, etc.). While we concede that non-professionals felt. may not be so au fait with such notations - which makes communication more difficult, in particular with system procurers, ul could say it in usords there would he no reason iopaort who in many cases are the people with whom the formal specifier -Edward Hopper (1882-1967) most needs to communicate - in general, the notations are not beyond the understanding of well-educated software engineers. The formal methods community must also take some of the blame for this: all too often we find authors of technical papers introducing new symbols, Greek hieroglyphics, which are just alternative ways of representing existing operators and concepts.
Load more

Recommended publications
  • The Essence Initiative
    The Essence Initiative Ivar Jacobson Agenda Specific Problems A Case for Action - Defining a solid theoretical base - Finding a kernel of widely agreed elements Using the Kernel Final Words Being in the software development business Everyone of us knows how to develop our software, but as a community we have no widely accepted common ground A CASE FOR ACTION STATEMENT • Software engineering is gravely hampered today by immature practices. Specific problems include: – The prevalence of fads more typical of fashion industry than of an engineering discipline. – The lack of a sound, widely accepted theoretical basis. – The huge number of methods and method variants, with differences little understood and artificially magnified. – The lack of credible experimental evaluation and validation. – The split between industry practice and academic research. Agenda Specific Problems A Case for Action - Defining a solid theoretical base - Finding a kernel of widely agreed elements Using the Kernel Final Words The SEMAT initiative Software Engineering Method and Theory www.semat.org Founded by the Troika in September 2009: Ivar Jacobson – Bertrand Meyer – Richard Soley What are we going to do about it? The Grand Vision We support a process to refound software engineering based on a solid theory, proven principles and best practices The Next Steps Defining A Kernel of a solid widely agreed theoretical basis elements There are probably more than 100,000 methods Desired solution: Method Architectureincl. for instance SADT, Booch, OMT, RUP, CMMI, XP, Scrum, Lean, Kanban There are around 250 The Kernel includes identified practices incl such elements as for instance use cases, Requirement, use stories, features, Software system, components, Work, Team, Way-of- working, etc.
    [Show full text]
  • Formal Specification Methods What Are Formal Methods? Objectives Of
    ICS 221 Winter 2001 Formal Specification Methods What Are Formal Methods? ! Use of formal notations … Formal Specification Methods ! first-order logic, state machines, etc. ! … in software system descriptions … ! system models, constraints, specifications, designs, etc. David S. Rosenblum ! … for a broad range of effects … ICS 221 ! correctness, reliability, safety, security, etc. Winter 2001 ! … and varying levels of use ! guidance, documentation, rigor, mechanisms Formal method = specification language + formal reasoning Objectives of Formal Methods Why Use Formal Methods? ! Verification ! Formal methods have the potential to ! “Are we building the system right?” improve both software quality and development productivity ! Formal consistency between specificand (the thing being specified) and specification ! Circumvent problems in traditional practices ! Promote insight and understanding ! Validation ! Enhance early error detection ! “Are we building the right system?” ! Develop safe, reliable, secure software-intensive ! Testing for satisfaction of ultimate customer intent systems ! Documentation ! Facilitate verifiability of implementation ! Enable powerful analyses ! Communication among stakeholders ! simulation, animation, proof, execution, transformation ! Gain competitive advantage Why Choose Not to Use Desirable Properties of Formal Formal Methods? Specifications ! Emerging technology with unclear payoff ! Unambiguous ! Lack of experience and evidence of success ! Exactly one specificand (set) satisfies it ! Lack of automated
    [Show full text]
  • August 2018 FACS a C T S
    Issue 2018-1 August 2018 FACS A C T S The Newsletter of the Formal Aspects of Computing Science (FACS) Specialist Group ISSN 0950-1231 FACS FACTS Issue 2018-1 August 2018 About FACS FACTS FACS FACTS (ISSN: 0950-1231) is the newsletter of the BCS Specialist Group on Formal Aspects of Computing Science (FACS). FACS FACTS is distributed in electronic form to all FACS members. Submissions to FACS FACTS are always welcome. Please visit the newsletter area of the BCS FACS website for further details at: http://www.bcs.org/category/12461 Back issues of FACS FACTS are available for download from: http://www.bcs.org/content/conWebDoc/33135 The FACS FACTS Team Newsletter Editors Tim Denvir [email protected] Brian Monahan [email protected] Editorial Team Jonathan Bowen, John Cooke, Tim Denvir, Brian Monahan, Margaret West. Contributors to this issue Jonathan Bowen, John Cooke, Tim Denvir, Sofia Meacham. Brian Monahan, Bill Stoddart, Botond Virginas, Margaret West BCS-FACS websites BCS: http://www.bcs-facs.org LinkedIn: http://www.linkedin.com/groups?gid=2427579 Facebook: http://www.facebook.com/pages/BCS-FACS/120243984688255 Wikipedia: http://en.wikipedia.org/wiki/BCS-FACS If you have any questions about BCS-FACS, please send these to Paul Boca [email protected] 2 FACS FACTS Issue 2018-1 August 2018 Editorial Dear readers, welcome to our first issue of FACS FACTS for 2018. This year, 2018, marks the 40th anniversary of FACS. At least one editor recalls an article by Dan Simpson, member of the editorial team at the time, FACS at 10 in 1988.
    [Show full text]
  • Design by Contract: the Lessons of Ariane
    . Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] several hours (at least in earlier versions of Ariane), it was better to let the computa- tion proceed than to stop it and then have Design by to restart it if liftoff was delayed. So the SRI computation continues for 50 seconds after the start of flight mode—well into the flight period. After takeoff, of course, this com- Contract: putation is useless. In the Ariane 5 flight, Object Technology however, it caused an exception, which was not caught and—boom. The exception was due to a floating- point error during a conversion from a 64- The Lessons bit floating-point value, representing the flight’s “horizontal bias,” to a 16-bit signed integer: In other words, the value that was converted was greater than what of Ariane can be represented as a 16-bit signed inte- ger. There was no explicit exception han- dler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the onboard computers, hence the mission. This is the kind of trivial error that we Jean-Marc Jézéquel, IRISA/CNRS are all familiar with (raise your hand if you Bertrand Meyer, EiffelSoft have never done anything of this sort), although fortunately the consequences are usually less expensive. How in the world everal contributions to this made up of respected experts from major department have emphasized the European countries, which produced a How in the world could importance of design by contract report in hardly more than a month.
    [Show full text]
  • Making Sense of Agile Methods Bertrand Meyer Politecnico Di
    Making sense of agile methods Bertrand Meyer Politecnico di Milano and Innopolis University Some ten years ago, I realized that I had been missing something big in software engineering. I had heard about Extreme Programming early thanks to a talk by Pete McBreen at a summer school in 1999 and another by Kent Beck himself at TOOLS USA in 2000. But I had not paid much attention to Scrum and, when I took a look, noticed two striking discrepancies in the state of agile methods. The first discrepancy was between university software engineering courses, which back then (things have changed) often did not cover agility, and the buzz in industry, which was only about agility. As I started going through the agile literature, the second discrepancy emerged: an amazing combination of the best and the worst ideas, plus much in-between. In many cases, faced with a new methodological approach, one can quickly deploy what in avionics is called Identification Friend or Foe: will it help or hurt? With agile, IFF fails. It did not help that the tone of most published discussions on agile methods (with a few exceptions, notably [1]) was adulatory. Sharing your passion for a novel approach is commendable, but not a reason to throw away your analytical skills. A precedent comes to mind: people including me who championed object-oriented programming a decade or so earlier may at times have let their enthusiasm show, but we did not fail to discuss cons along with pros. The natural reaction was to apply a rule that often helps: when curious, teach a class; when bewildered, write a book.
    [Show full text]
  • Online Communities: Visualization and Formalization
    Online Communities: Visualization and Formalization Jonathan P. Bowen Museophile Limited, Oxford, UK [email protected] www.jpbowen.com Abstract. Online communities have increased in size and importance dramat- ically over the last decade. The fact that many communities are online means that it is possible to extract information about these communities and the con- nections between their members much more easily using software tools, despite their potentially very large size. The links between members of the community can be presented visually and often this can make patterns in the structure of sub-communities immediately obvious. The links and structures of layered com- munities can also be formalized to gain a better understanding of their modelling. This paper explores these links with some specific examples, including visualiza- tion of these relationships and a formalized model of communities using the Z notation. It also considers the development of such communities within the Com- munity of Practice social science framework. Such approaches may be applicable for communities associated with cybersecurity and could be combined for a better understanding of their development. 1 Introduction The development of collective human knowledge has always depended on communities. As communities have become more computer-based, it has become easier to monitor the activity of such interactions [7]. Recently the increasing use of online communities by the wider population (e.g., for social networking) has augmented the ways that com- munities can form and interact since geographical co-location is now much less critical than before the development of the Internet and the web [1,2].
    [Show full text]
  • Facing the Challenge of Automated Negotiation with Humans
    Facing the Challenge of Automated Negotiation with Humans A dissertation submitted by Angela Fabregues Vinent at Universitat Aut`onomade Barcelona to fulfill the degree of PhD in Computer Science. Bellaterra, September 18th, 2012 Director: Prof. Carles Sierra Tutor: Dr. Josep Puyol Elaborated at: Institut d’ Investigaci´o en Intel·lig`encia Artificial Consejo Superior de Investigaciones Cient´ıficas (IIIA-CSIC) Acknowledgements Voldria agrair a molta gent el temps que ha compartit amb mi aquests darrers anys corresponents a la realitzaciod'aquesta tesi doctoral. Especialment, voldria donar les graciesa en Juan Carlos. Sempre m'has acompanyat. Sempre m'has ajudat. Sempre has estat allaquan t'he necessitat, ja fossis al meu costat o a milles enfora. Ara que nos veim cada dia, esper no te cansis de jo. T'estim! Molts coneixements previs he hagut de menester. Molts altres els he adquirit pel cam.L'escola, l'institut, la carrera i el mastera l'IIIA m'han aportat molts d'ells. Tambeel meu pas per l'empresa privada, per tot arreu s'apren. Els valors, en canvi, s'aprenen a casa. Els vaig aprendre a Menorca graciesals meus pares i tambeals meus germans. Papa! Mama! Me vau donar una infanciaimpressionant, envoltada d'un entorn ple de coses per experimentar sentint-me segura i protegida. Me vau deixar creixer,que formessa meva propia personalitat, que anesagafant responsabilitats, i que fos lliure de decidir per jo mateixa lo que ningumespodia decidir. Vau conar en jo i me vau nancar els estudis a Barcelona. Casi res! Moltes graciesper tot. Bep, amb tu vaig aprendre a enraonar, a donar mil voltes a ses coses i a poder veure-les des de diferents punts de vista.
    [Show full text]
  • Engineering Trustcom/Bigdatase 2018
    2018 17th IEEE International Conference on Trust, Security and Privacy in Computing and Communications/ 12th IEEE International Conference on Big Data Science and Engineering (TrustCom/BigDataSE 2018) New York, New York, USA 31 July - 3 August 2018 Pages 1-650 IEEE Catalog Number: CFP18TRU-POD ISBN: 978-1-5386-4389-1 1/3 Copyright © 2018 by the Institute of Electrical and Electronics Engineers, Inc. All Rights Reserved Copyright and Reprint Permissions: Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond the limit of U.S. copyright law for private use of patrons those articles in this volume that carry a code at the bottom of the first page, provided the per-copy fee indicated in the code is paid through Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923. For other copying, reprint or republication permission, write to IEEE Copyrights Manager, IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08854. All rights reserved. *** This is a print representation of what appears in the IEEE Digital Library. Some format issues inherent in the e-media version may also appear in this print version. IEEE Catalog Number: CFP18TRU-POD ISBN (Print-On-Demand): 978-1-5386-4389-1 ISBN (Online): 978-1-5386-4388-4 ISSN: 2324-898X Additional Copies of This Publication Are Available From: Curran Associates, Inc 57 Morehouse Lane Red Hook, NY 12571 USA Phone: (845) 758-0400 Fax: (845) 758-2633 E-mail: [email protected] Web: www.proceedings.com 2018 17th IEEE International Conference On Trust, Security
    [Show full text]
  • Towards Verified Systems
    TOWARDS VERIFIED SYSTEMS edited by Jonathan Bowen TOWARDS VERIFIED SYSTEMS edited by Jonathan Bow en safemos i This page delib erately left blank for publisher's use ii This page delib erately left blank for publisher's use iii This page delib erately left blank for publisher's use iv This page delib erately left blank for publisher's use Contents Foreword xvii Preface xix Contact Addresses xxiii I Intro duction 1 1 Safety-Critical Systems and Formal Metho ds 3 1.1 A Brief Historical Persp ective ::::::::::::::::::::::::: 3 1.2 Safety-critical Computer Systems ::::::::::::::::::::::: 5 1.2.1 Dep endable computer systems :: :: :: :: :: ::: :: :: :: :: 6 1.2.2 Formal metho ds ::::::::::::::::::::::::::::: 7 1.2.3 The cost of software safety ::::::::::::::::::::::: 9 1.3 Industrial-scale Examples of Use :: ::: :: :: :: :: ::: :: :: :: :: 11 1.3.1 Aviation ::::::::::::::::::::::::::::::::: 12 1.3.2 Railway systems :: :: :: ::: :: :: :: :: ::: :: :: :: :: 13 1.3.3 Nuclear p ower plants :: :: ::: :: :: :: :: ::: :: :: :: :: 13 1.3.4 Medical systems ::::::::::::::::::::::::::::: 14 1.3.5 Ammunition control :: :: ::: :: :: :: :: ::: :: :: :: :: 16 1.3.6 Emb edded micropro cessors ::::::::::::::::::::::: 17 1.4 Areas of Application of Formal Metho ds :: :: :: :: ::: :: :: :: :: 18 1.4.1 Requirements capture ::::::::::::::::::::::::: 19 1.4.2 Design : ::: :: :: :: :: ::: :: :: :: :: ::: :: :: :: :: 19 1.4.3 Compilation ::::::::::::::::::::::::::::::: 20 1.4.4 Programmable hardware :: ::: :: :: :: :: ::: :: :: :: :: 21 1.4.5 Do cumentation :::::::::::::::::::::::::::::
    [Show full text]
  • Current Issue of FACS FACTS
    Issue 2021-2 July 2021 FACS A C T S The Newsletter of the Formal Aspects of Computing Science (FACS) Specialist Group ISSN 0950-1231 FACS FACTS Issue 2021-2 July 2021 About FACS FACTS FACS FACTS (ISSN: 0950-1231) is the newsletter of the BCS Specialist Group on Formal Aspects of Computing Science (FACS). FACS FACTS is distributed in electronic form to all FACS members. Submissions to FACS FACTS are always welcome. Please visit the newsletter area of the BCS FACS website for further details at: https://www.bcs.org/membership/member-communities/facs-formal-aspects- of-computing-science-group/newsletters/ Back issues of FACS FACTS are available for download from: https://www.bcs.org/membership/member-communities/facs-formal-aspects- of-computing-science-group/newsletters/back-issues-of-facs-facts/ The FACS FACTS Team Newsletter Editors Tim Denvir [email protected] Brian Monahan [email protected] Editorial Team: Jonathan Bowen, John Cooke, Tim Denvir, Brian Monahan, Margaret West. Contributors to this issue: Jonathan Bowen, Andrew Johnstone, Keith Lines, Brian Monahan, John Tucker, Glynn Winskel BCS-FACS websites BCS: http://www.bcs-facs.org LinkedIn: https://www.linkedin.com/groups/2427579/ Facebook: http://www.facebook.com/pages/BCS-FACS/120243984688255 Wikipedia: http://en.wikipedia.org/wiki/BCS-FACS If you have any questions about BCS-FACS, please send these to Jonathan Bowen at [email protected]. 2 FACS FACTS Issue 2021-2 July 2021 Editorial Dear readers, Welcome to the 2021-2 issue of the FACS FACTS Newsletter. A theme for this issue is suggested by the thought that it is just over 50 years since the birth of Domain Theory1.
    [Show full text]
  • 1 Publications
    1 Publications Chronological list [1] Martin Fränzle. Verification of compilers for recursive occam-like languages. ProCoS Technical Report Kiel MF 8/1, Christian-Albrechts-Universität Kiel, Germany, 1990. [2] Martin Fränzle. Operational failure approximation. In Dines Bjørner, Hans Langmaack, and C. A. R. Hoare, editors, Monograph of the ESPRIT BRA 3104 ProCoS (Provably Correct Systems), pages 165–206. Technical Report, Dept. of Computer Science, Technical University of Denmark, 1992. [3] B. Buth, K.-H. Buth, M. Fränzle, B. von Karger, Y. Lakhneche, H. Langmaack, and M. Müller- Olm. Provably correct compiler development and implementation. In U. Kastens and P. Pfahler, editors, Compiler Construction, volume 641 of Lecture Notes in Computer Science, pages 141–155. Springer-Verlag, 1992. [4] Jonathan P. Bowen, Martin Fränzle, Ernst-Rüdiger Olderog, and Anders P. Ravn. Developing correct systems. In Proc. 5th Euromicro Workshop on Real-Time Systems, Oulu, Finland, pages 176–189. IEEE Computer Society Press, June 1993. [5] Martin Fränzle and Markus Müller-Olm. Drift and granularity of time in real-time system implementation. ProCoS Technical Report Kiel MF 10/2, Christian-Albrechts-Universität Kiel, Germany, August 1993. [6] Martin Fränzle and Burghard von Karger. Proposal for a programming language core for ProCoS II. ProCoS Technical Report Kiel MF 11/3, Christian-Albrechts-Universität Kiel, Ger- many, August 1993. [7] M. R. Hansen, E.-R. Olderog, M. Schenke, M. Fränzle, B. von Karger, M. Müller-Olm, and H. Rischel. A Duration Calculus semantics for real-time reactive systems. ProCoS II document [OLD MRH 1/1], Oldenburg Universität, Germany, September 1993. [8] Martin Fränzle and Markus Müller-Olm.
    [Show full text]
  • Object-Oriented Software Construction
    Quotes from∗ Object-Oriented Software Construction Bertrand Meyer Prentice-Hall, 1988 Preface, p. xiv We study the object-oriented approach as a set of principles, methods and tools which can be instrumental in building \production" software of higher quality than is the norm today. Object-oriented design is, in its simplest form, based on a seemingly elementary idea. Computing systems perform certain actions on certain objects; to obtain flexible and reusable systems, it is better to base the structure of software on the objects than on the actions. Once you have said this, you have not really provided a definition, but rather posed a set of problems: What precisely is an object? How do you find and describe the objects? How should programs manipulate objects? What are the possible relations between objects? How does one explore the commonalities that may exist between various kinds of objects? How do these ideas relate to classical software engineering concerns such as correct- ness, ease of use, efficiency? Answers to these issues rely on an impressive array of techniques for efficiently producing reusable, extendible and reliable software: inheritance, both in its linear (single) and multiple forms; dynamic binding and poly- morphism; a new view of types and type checking; genericity; information hiding; use of assertions; programming by contract; safe exception handling. Efficient implementation techniques have been developed to allow practical application of these ideas. [T]he book relies on the object-oriented language Eiffel. 4.1 Process and Data (p. 41) A software system is a set of mechanisms for performing certain actions on certain data.
    [Show full text]