Modeling, Specification Languages, Array Programs

Total Page:16

File Type:pdf, Size:1020Kb

Modeling, Specification Languages, Array Programs Chapter 4 Modeling, Specification Languages, Array Programs This chapter presents some techniques for verifying programs with complex data structures. Typical examples of such data structures are arrays and lists. The main ingredient is to provide extensions to the language of expressions and formulas, under the form of an expressive specification language. Section 4.1 presents generalities about specification languages, while other sections present an overview of the constructs for modeling and specifying as they are available in the Why3 tool [7]. Finally, Section 4.6 is dedicated to the modeling and the proof of programs on the array data structure. 4.1 Generalities on Specification Languages There have been a lot of variants of specification languages proposed in the past. Various classes of such languages are characterized by the kind of logic that they are based on. Algebraic Specifications This class of languages is characterized by the use of multi-sorted first-order logic with equality, and usually the use of rewriting techniques [13], which permits to mix executable- style and declarative-style specifications. Famous languages and tools of this class are Larch [17], KIV [26], CASL (Common Algebraic Specification Language) [2], OBJ [16], Maude [10]. Set-theory based approaches Another class of languages is based on classical Set theory. These languages are not typed, the typing properties being instead encoded by formulas on sets. Reasoning on such languages is also typically done by rewriting techniques. A precursor of this class is the Z notation [27]. It is used in tools like VDM [18], Atelier B [1], etc. Higher-Order Logic Higher-Order Logic is characterized by the use of mathematical functions as objects of the language. It is based on advanced lambda-calculi (e.g. System F). Reasoning on such specifications is typically done using interactive environment where proofs are constructed manually us- ing tactics/strategies. Famous tools implementing some higher-order logics are PVS [24], Isabelle [22], HOL4 [23], Coq [5], etc. Object-Oriented languages These are based on the idea of using the object-oriented paradigm in a logic world. They are typically in use in a context of object-oriented-style development. The precursor is the language Eiffel [20], which is both a programming language and a specification language, and was designed to support the concept of design-by-contract. Other famous languages are OCL [28] (Object 41 Constraint Language) which allows to incorporate formal specifications into the UML diagrammatic design methodology, and the Java Modeling Language [9]. Satisfiability Modulo Theories In 1980, Nelson and Oppen [21] proposed a new technique for com- bining propositional reasoning and dedicated decision procedures for specific theories. This gave birth to a new class of automated theorem provers called SMT solvers. A precursor of such solvers is Sim- plify [14] which was used for program verification in the ESC/Java tool. The SMT-LIB format [25] is not really a specification language but a common language for describing verification conditions as they typically come from program verification. In this context, the intermediate languages for program verification Why [15] and Boogie [3] propose small specification languages that can be supported by SMT solvers. Nowadays, the successors of Why and Boogie, respectively Why3 [7] and Dafny [19], propose modeling languages that can be seen as a compromise between: Expressivity of the language, to be able to design specifications of complex programs ; • Support by automated provers, in particular modern SMT solvers like Alt-Ergo [6], Z3 [12], • CVC3 [4] which support quantified first-order formulas. The following sections present an overview of the constructs of the Why3 specification language. 4.2 Defined Functions and Predicates Direct definitions of new functions and predicates can be given under the form function f(x1 : τ1, . , xn : τn): τ = e predicate p(x1 : τ1, . , xn : τn) = e where τi, τ are not reference types. In such definitions, no recursion is allowed, unless we are in the case of Section 4.3.3. Since expres- sions have no side-effects, these define total functions and predicates, which are pure in the sense that they have no side-effects. Example 4.2.1 Here are a few examples of definitions of functions and predicates. function sqr(x:int) : int = x * x function min(x:real,y:real) : real = if x y then x else y ≤ function abs(x:real) : real = if x 0.0 then x else -x ≥ predicate in_0_1(x:real) = 0.0 x x 1.0 ≤ ∧ ≤ predicate prime(x:int) = x 2 forall y z:int. y 0 z 0 x = y*z y=1 z=1 ≥ ∧ ≥ ∧ ≥ ∧ → ∨ 4.3 Constructed Types New logic data types can be defined by standard construction of compound types. Being in a logic language, these types must be pure in the sense of pure functional programming, that is, the values of these types cannot be modified “in-place”. 42 4.3.1 Product Types Types can be defined as being tuples of already defined types, for example type intpair = (int, int) function sumprod (n:int,m:int) : intpair = (n+m,n*m) type vector = (real, real, real) function diag(x:real) : vector = (x,x,x) The construct let x=e1 in e2 is extended so as to allow introducing a tuple, as in function sum (p:intpair) = let (x,y) = p in x+y The other kind of product type is the record type, defined classically by a sequence of named fields. The dot notation allows to access a given field. For example, type vector = { x:real; y:real } function norm(v:vector) : real = sqrt(v.x * v.x + v.y * v.y) function rotate(v:vector,a:real) : vector = { x = cos(a) * v.x + sin(a) * v.y ; y = sin(a) * v.y - sin(a) * v.x } Again, it is important to notice that these are pure types; the components of tuples and the fields of records are immutable. In other words, there is no way to assign a field. 4.3.2 Sum Types We can define new sum types in a functional programming style, with the form of declaration type t = C (τ , . , τ ) | 1 1,1 1,n1 | · · · C (τ , . , τ ) | k k,1 k,nk where C1,...,Ck are constructors. Example 4.3.1 The type of cards in a standard 54-card game can be defined as type suit = Spade | Heart | Diamond | Club type value = Ace | King | Queen | Jack | Number(int) type card = Normal(suit,value) | Joker Associated to sum types is the definition by pattern-matching, with the form match expression with C (x , . , x ) expression | 1 1,1 1,n1 → 1 | · · · C (x , . , x ) expression | k k,1 k,nk → k end where each xi,j is a variable that is bound in expressioni. For convenience, one may use extended pattern-matching [8]: inside patterns, an argument of a constructor may itself be a pattern. One may also use the wildcard character _. As in OCaml or Why3, we distinguish between constructors and variables by enforcing a capital letter as the first character of a constructor. Example 4.3.2 Here is a function that returns the score of a given card in an imaginary game. 43 function score (c:card,trump:suit): int = match c with | Joker 100 → | Normal(Ace,s) if s=trump then 50 else 20 → | Normal(Number(n),s) if s=trump then 50 else n → | Normal(v,_) → match v with | King | Queen 40 → | Jack 30 → | _ 0 → end end 4.3.3 Recursive Sum Types Sum type definitions can be recursive. Recursive definitions of functions or predicates are allowed if recursive calls are on structurally smaller arguments, which corresponds to the notion of primitive recursion on such a sum type. Example 4.3.3 Here is a definition of binary trees holding integers at each node, and a function giving the sum of the elements of a tree. type tree = Leaf | Node(tree,int,tree) function sum (t:tree) : int = match t with | Leaf 0 → | Node(l,x,r) sum(l) + x + sum(r) → end The recursion is allowed since arguments l and r are subtrees of the input. 4.3.4 Polymorphic Types All the constructs for type definitions above can be parameterized, i.e. the type is given one or several type variables as parameters, as in type vector α = (α,α,α) type tagged α = { tag : int ; content : α } type option α = None | Some(α) type tree α β = Leaf(α) | Node(tree α β, β, tree α β) 4.3.5 Example of Lists Lists, or finite sequences, are very common data structures. The type of lists can be modeled by a polymorphic, recursive sum type as type list α = Nil | Cons α (list α) Classical functions on lists can be defined by primitive recursion, such as function append(l1:list α,l2:list α) : list α = match l1 with | Nil l2 → 44 | Cons(x,l) Cons(x,append(l,l2)) → end function length(l:list α) : int = match l with | Nil 0 → | Cons(x,r) 1 + length(r) → end function rev(l:list α) : list α = match l with | Nil Nil → | Cons(x,r) append(rev(r),Cons(x,Nil)) → end When proving programs operating on lists, and on recursive sum types in general like binary trees above, it is very common that some properties are needed, such as the properties lemma append_nil: forall l:list α. append(l,Nil) = l lemma append_assoc: forall l1 l2 l3:list α. append(append(l1,l2),l3) = append(l1,append(l2,l3)) Such lemmas can be stated as this in the Why3 tool. They must be proved by induction, meaning that they are out of reach to SMT solvers.
Recommended publications
  • A Classification and Comparison Framework for Software Architecture Description Languages
    A Classification and Comparison Framework for Software Architecture Description Languages Neno Medvidovic Technical Report UCI-ICS-97-02 Department of Information and Computer Science University of California, Irvine Irvine, California 92697-3425 neno@ics.uci.edu February 1996 Abstract Software architectures shift the focus of developers from lines-of-code to coarser- grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architecture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, the distinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation, and programming languages on the other. This paper attempts to provide an answer to these questions. It motivates and presents a definition and a classification framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations. The framework is also used to classify and compare several existing ADLs. One conclusion is that, although much research has been done in this area, no single ADL fulfills all of the identified needs. I. Introduction Software architecture research is directed at reducing costs of developing applications and increasing the potential for commonality between different members of a closely related product family [GS93, PW92]. Software development based on common architectural idioms has its focus shifted from lines-of-code to coarser-grained architectural elements (software components and connectors) and their overall interconnection structure.
    [Show full text]
  • An Architectural Description Language for Secure Multi-Agent Systems
    An Architectural Description Language for Secure Multi-Agent Systems Haralambos Mouratidis1,a, Manuel Kolpb, Paolo Giorginic, Stephane Faulknerd aInnovative Informatics Group, School of Computing, IT and Engineering, University of East London, England b Information Systems Research Unit, Catholic University of Louvain (UCL), Belgium c Department. of Information and Communication Technology, University of Trento, Italy d Information Management Research Unit, University of Namur, Belgium Abstract. Multi-Agent Systems (MAS) architectures are gaining popularity for building open, distributed, and evolving information systems. Unfortunately, despite considerable work in the fields of software architecture and MAS during the last decade, few research efforts have aimed at defining languages for designing and formalising secure agent architectures. This paper proposes a novel Architectural Description Language (ADL) for describing Belief-Desire-Intention (BDI) secure MAS. We specify each element of our ADL using the Z specification language and we employ two example case studies: one to assist us in the description of the proposed language and help readers of the article to better understand the fundamentals of the language; and one to demonstrate its applicability. Keyword: Architectural Description Language, Multi-Agent Systems, Security, BDI Agent Model, Software Architecture 1 Corresponding Author: H.Mouratidis@uel.ac.uk 1 1. Introduction However, as the expectations of business stakeholders are changing day after day; and The characteristics and expectations of as the complexity of systems, information new application areas for the enterprise, and communication technologies and such as e-business, knowledge management, organisations is continually increasing in peer-to-peer computing, and web services, today’s dynamic environments; developers are deeply modifying information systems are expected to produce architectures that engineering.
    [Show full text]
  • Should Your Specification Language Be Typed?
    Should Your Specification Language Be Typed? LESLIE LAMPORT Compaq and LAWRENCE C. PAULSON University of Cambridge Most specification languages have a type system. Type systems are hard to get right, and getting them wrong can lead to inconsistencies. Set theory can serve as the basis for a specification lan- guage without types. This possibility, which has been widely overlooked, offers many advantages. Untyped set theory is simple and is more flexible than any simple typed formalism. Polymorphism, overloading, and subtyping can make a type system more powerful, but at the cost of increased complexity, and such refinements can never attain the flexibility of having no types at all. Typed formalisms have advantages too, stemming from the power of mechanical type checking. While types serve little purpose in hand proofs, they do help with mechanized proofs. In the absence of verification, type checking can catch errors in specifications. It may be possible to have the best of both worlds by adding typing annotations to an untyped specification language. We consider only specification languages, not programming languages. Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifica- tions; D.2.4 [Software Engineering]: Software/Program Verification—formal methods; F.3.1 [Logics and Meanings of Programs]: Specifying and Verifying and Reasoning about Pro- grams—specification techniques General Terms: Verification Additional Key Words and Phrases: Set theory, specification, types Editors’ introduction. We have invited the following
    [Show full text]
  • Architecture Description Language) COMS W4115 Alan Khara Ask2206 February 11, 2014
    1 of 13 General Purpose ADL (Architecture Description Language) COMS W4115 Alan Khara Ask2206 February 11, 2014 1.0 Introduction In the design of system architecture1, a blueprint of the system typically comes second, after requirements are gathered in the process of architecture development. This is followed by design verification and, later, implementation. Initially, the domain of Architecture Description Languages (ADLs) was confined to the design phase and was highly motivated by Object Oriented paradigm [1] [2] [3]. ADLs were mainly graphical in nature, with numerous Line and Box representations that were later standardized by Object Management Group (OMG) in Unified Model Language2 (UML) [4][5]. Being quickly adopted by industry, UML was infested with ambiguous features: a given relationship between components of a system could be ambiguous and yield two different interpretations of the same drawing [2]. Research during the last decade has worked to solve this problem on two different fronts. One line of research seeks to extend UML in order to make it less ambiguous [6] [7] [8] [9]. Another kind of research is finding new ADLs (graphical and text based) that have more rigorous and well defined semantics [10] [11] [12][13]. Both of these trends are important with respect to defining the problem scope of the proposed project. Because they are mainly driven by industry, efforts to extend UML are inherently domain- specific [14]. The primary motivation behind the development of UML is to overcome ambiguity and reduced the communication gap that exists among various stakeholders. This is tackled by either introducing constraints or adding new vocabulary.
    [Show full text]
  • Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria Revision 1.0
    Comparative Studies of 10 Programming Languages within 10 Diverse Criteria Revision 1.0 Rana Naim∗ Mohammad Fahim Nizam† Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada ra_hass@cse.concordia.ca m_niza@cse.concordia.ca Sheetal Hanamasagar‡ Jalal Noureddine§ Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada s_hanama@cse.concordia.ca j_noure@cse.concordia.ca Marinela Miladinova¶ Concordia University Montreal, Quebec, Canada marin_mi@cse.concordia.ca Abstract This is a survey on the programming languages: C++, JavaScript, AspectJ, C#, Haskell, Java, PHP, Scala, Scheme, and BPEL. Our survey work involves a comparative study of these ten programming languages with respect to the following criteria: secure programming practices, web application development, web service composition, OOP-based abstractions, reflection, aspect orientation, functional programming, declarative programming, batch scripting, and UI prototyping. We study these languages in the context of the above mentioned criteria and the level of support they provide for each one of them. Keywords: programming languages, programming paradigms, language features, language design and implementation 1 Introduction Choosing the best language that would satisfy all requirements for the given problem domain can be a difficult task. Some languages are better suited for specific applications than others. In order to select the proper one for the specific problem domain, one has to know what features it provides to support the requirements. Different languages support different paradigms, provide different abstractions, and have different levels of expressive power. Some are better suited to express algorithms and others are targeting the non-technical users. The question is then what is the best tool for a particular problem.
    [Show full text]
  • A Formal Methodology for Deriving Purely Functional Programs from Z Specifications Via the Intermediate Specification Language Funz
    Louisiana State University LSU Digital Commons LSU Historical Dissertations and Theses Graduate School 1995 A Formal Methodology for Deriving Purely Functional Programs From Z Specifications via the Intermediate Specification Language FunZ. Linda Bostwick Sherrell Louisiana State University and Agricultural & Mechanical College Follow this and additional works at: https://digitalcommons.lsu.edu/gradschool_disstheses Recommended Citation Sherrell, Linda Bostwick, "A Formal Methodology for Deriving Purely Functional Programs From Z Specifications via the Intermediate Specification Language FunZ." (1995). LSU Historical Dissertations and Theses. 5981. https://digitalcommons.lsu.edu/gradschool_disstheses/5981 This Dissertation is brought to you for free and open access by the Graduate School at LSU Digital Commons. It has been accepted for inclusion in LSU Historical Dissertations and Theses by an authorized administrator of LSU Digital Commons. For more information, please contact gradetd@lsu.edu. INFORMATION TO USERS This manuscript has been reproduced from the microfilm master. UMI films the text directly from the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter face, while others may be from any type of computer printer. H ie quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandardm argins, and improper alignment can adversely affect reproduction. In the unlikely, event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps.
    [Show full text]
  • Application Software Prototyping and Fourth Generation Languages
    NATL INST OF STANDARDS & TECH R.I.C. Computer Science A1 11 02661 975 Fisher, Gary E/Application software prot and Technology QC100 .U57 NO.500-148 1987 V19 C.I NBS-P PUBLICATIONS NBS Special Publication 500-148 Application Software Prototyping and Fourth Generation Languages Gary E. Fisher 1987 Tm he National Bureau of Standards' was established by an act of Congress on March 3, 1901. The Bureau's overall goal is to strengthen and advance the nation's science and technology and facilitate their effective application for public benefit. To this end, the Bureau conducts research to assure international competitiveness and leadership of U.S. industry, science arid technology. NBS work involves development and transfer of measurements, standards and related science and technology, in support of continually improving U.S. productivity, product quality and reliability, innovation and underlying science and engineering. The Bureau's technical work is performed by the National Measurement Laboratory, the National Engineering Laboratory, the Institute for Computer Sciences and Technology, and the Institute for Materials Science and Engineering. The National Measurement Laboratory Provides the national system of physical and chemical measurement; • Basic Standards^ coordinates the system with measurement systems of other nations and • Radiation Research furnishes essential services leading to accurate and uniform physical and • Chemical Physics chemical measurement throughout the Nation's scientific community, • Analytical Chemistry industry,
    [Show full text]
  • HDL and Programming Languages ■ 6 Languages ■ 6.1 Analogue Circuit Design ■ 6.2 Digital Circuit Design ■ 6.3 Printed Circuit Board Design ■ 7 See Also
    Hardware description language - Wikipedia, the free encyclopedia 페이지 1 / 11 Hardware description language From Wikipedia, the free encyclopedia In electronics, a hardware description language or HDL is any language from a class of computer languages, specification languages, or modeling languages for formal description and design of electronic circuits, and most-commonly, digital logic. It can describe the circuit's operation, its design and organization, and tests to verify its operation by means of simulation.[citation needed] HDLs are standard text-based expressions of the spatial and temporal structure and behaviour of electronic systems. Like concurrent programming languages, HDL syntax and semantics includes explicit notations for expressing concurrency. However, in contrast to most software programming languages, HDLs also include an explicit notion of time, which is a primary attribute of hardware. Languages whose only characteristic is to express circuit connectivity between a hierarchy of blocks are properly classified as netlist languages used on electric computer-aided design (CAD). HDLs are used to write executable specifications of some piece of hardware. A simulation program, designed to implement the underlying semantics of the language statements, coupled with simulating the progress of time, provides the hardware designer with the ability to model a piece of hardware before it is created physically. It is this executability that gives HDLs the illusion of being programming languages, when they are more-precisely classed as specification languages or modeling languages. Simulators capable of supporting discrete-event (digital) and continuous-time (analog) modeling exist, and HDLs targeted for each are available. It is certainly possible to represent hardware semantics using traditional programming languages such as C++, although to function such programs must be augmented with extensive and unwieldy class libraries.
    [Show full text]
  • CSL4P: a Contract Specification Language for Platforms
    CSL4P: A Contract Specification Language for Platforms Alessandro Pinto and Alberto L. Sangiovanni Vincentelli October 19, 2016 Abstract The contract-based design formalism supports compositional design and verification, and generalizes many other languages where components are defined in terms of their assumptions and guarantees. Most languages and tools for contract-based design allow defining, instantiating and connecting contracts, but fall short in capturing families of potential architectures in a flexible way. This article presents a Contract-Based Specification Language for Platforms (CSL4P). A platform comprises a set of contract types and a set of constraints called rules. Contract types can be instantiated and connected to form platform instances. While the meaning of composition is predefined in most languages, composition rules are used in CSL4P to provide a finer control on the semantics of interconnections. The separation of contract types and rules also allows defining different platforms out of the same set of components. This article describes syntax and semantics of the language, a development environment which includes a compiler and a verification back-end, and an application example. 1 Motivation, Background and Contributions A design process defines a sequence of design, validation and verification activities, as well as guidelines, rules and best practices to help avoiding common pitfalls that may turn into serious design errors. Design processes become essential in large systems not only to manage complexity arising from the large number of components, but most importantly to manage their interactions through controlled interfaces. This is crucial because components and subsystems may span across various disciplines, groups, and organizations. For the past four decades, system engineering processes have been the subject of standardization efforts.
    [Show full text]
  • Investigating Architecture Description Languages (Adls) a Systematic Literature Review by Sajjad Hussain
    Institutionen för datavetenskap Department of Computer and Information Science Final thesis Investigating Architecture Description Languages (ADLs) A Systematic Literature Review By Sajjad Hussain LIU-IDA/LITH-EX-A--13/070--SE 2013-12-20 Linköpings universitet Linköpings universitet Linköpings universitet SE -581 83 Linköping, Sweden 581 83 Linköping This thesis is submitted to the Department of Computer and Information Science (IDA) Linköpings universitet in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering and Management. Contact Information: Author: Sajjad Hussain E-mail: sajhu213@student.liu.se University Supervisor: Prof. Kristian Sandahl Email: krisa@ida.liu.se Examiner: Johan Åberg Email: johan.aberg@liu.se Linköpings universitet SE-581 83 Linköping, Sweden ABSTRACT Context: Over the last two decades, software architecture has introduced a new trend in software development. This new trend has completely changed the normal methods and practices of software engineering. The focus has become the architectural elements rather than code and sub-routines. Architecture description languages (ADLs) have been proposed for this kind of architecture based software development. There are a number of different ADLs both in academia and industry; they are not totally adopted by the software engineering community, but they are not avoided either. In this research work, an investigation has been performed based on the ADLs evaluation in practice. Objectives: The main aim of this study is to investigate evaluation of ADLs in academia and industry. To explore the benefits and drawbacks of ADLs in practice. The study also explores the different quality factors improved by ADLs. Further different methods used to build architecture with ADLs and then how to use architecture described with an ADL in software development and maintenance have also been reported.
    [Show full text]
  • Specification and Description Language (SDL)
    Specification and Description Language (SDL) Definition Specification and description language (SDL) is an object-oriented, formal language defined by The International Telecommunications Union– Telecommunications Standardization Sector (ITU–T) (formerly Comité Consultatif International Telegraphique et Telephonique [CCITT]) as recommendation Z.100. The language is intended for the specification of complex, event-driven, real-time, and interactive applications involving many concurrent activities that communicate using discrete signals. Overview This tutorial discusses the applications and reasons for the use of specification and description language (SDL). Over the last decade, the size of produced software has increased dramatically. More and more systems are multiprocess and distributed, and they execute in a heterogeneous environment. It is increasingly accepted within a steadily growing range of industrial segments that the best way to meet the needs of these systems is through formal methods. Furthermore, as the international market grows, equipment from different manufacturers must be able to communicate with each other. Therefore, the formal methods should be internationally standardized. Telecommunications software engineers have developed such methods and tools for the development of complex real-time software. SDL is an object-oriented formal language defined by the ITU−T for specification of complex, real-time applications. The strength of SDL is its ability to describe the structure, behavior, and data of a system. Topics 1. Benefits of a Specification Language 2. History 3. SDL Characteristics 4. Theoretical Model and Structure 5. Sharing, Reuse, and Maintenance 6. Openness, Portability, Scalability, and Distributed Applications Web ProForum Tutorials Copyright © 1/20 http://www.iec.org The International Engineering Consortium 7. Graphical and Textual Notations and Applications Areas Self-Test Correct Answers Glossary 1.
    [Show full text]
  • Formal Specification and Verification Stephan Merz
    Formal specification and verification Stephan Merz To cite this version: Stephan Merz. Formal specification and verification. Dahlia Malkhi. Concurrency: the Works of Leslie Lamport, 29, Association for Computing Machinery, pp.103-129, 2019, ACM Books, 10.1145/3335772.3335780. hal-02387780 HAL Id: hal-02387780 https://hal.inria.fr/hal-02387780 Submitted on 2 Dec 2019 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. Formal specification and verification Stephan Merz University of Lorraine, CNRS, Inria, LORIA, Nancy, France 1. Introduction Beyond his seminal contributions to the theory and the design of concurrent and distributed algorithms, Leslie Lamport has throughout his career worked on methods and formalisms for rigorously establishing the correctness of algorithms. Commenting on his first article about a method for proving the correctness of multi-process programs [32] on the website providing access to his collected writings [47], Lamport recalls that this interest originated in his submitting a flawed mutual-exclusion algorithm in the early 1970s. As a trained mathematician, Lamport is perfectly familiar with mathematical set theory, the standard formal foundation of classical mathematics. His career in industrial research environments and the fact that his main interest has been in algorithms, not formalisms, has certainly contributed to his designing reasoning methods that combine pragmatism and mathematical elegance.
    [Show full text]