Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers / Edition 1 available in Paperback
Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers / Edition 1
- ISBN-10:
- 032114306X
- ISBN-13:
- 9780321143068
- Pub. Date:
- 07/19/2002
- Publisher:
- Pearson Education
- ISBN-10:
- 032114306X
- ISBN-13:
- 9780321143068
- Pub. Date:
- 07/19/2002
- Publisher:
- Pearson Education
Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers / Edition 1
Paperback
Buy New
$44.99Buy Used
$31.65-
-
SHIP THIS ITEM
Temporarily Out of Stock Online
Please check back later for updated availability.
-
Overview
Product Details
| ISBN-13: | 9780321143068 |
|---|---|
| Publisher: | Pearson Education |
| Publication date: | 07/19/2002 |
| Edition description: | New Edition |
| Pages: | 384 |
| Product dimensions: | 7.30(w) x 9.10(h) x 0.90(d) |
About the Author
032114306XAB06262002
Read an Excerpt
This book will teach you how to write specifications of computer systems, using the language TLA+. It's rather long, but most people will read only Part I, which comprises the first 83 pages. That part contains all that most engineers need to know about writing specifications; it assumes only the basic background in computing and knowledge of mathematics expected of an undergraduate studying engineering or computer science. Part II contains more advanced material for more sophisticated readers. The remainder of the book is a reference manual—Part III for the TLA+ tools and Part IV for the language itself.
The TLA World Wide Web page contains material to accompany the book, including the TLA+ tools, exercises, references to the literature, and a list of corrections.
What Is a Specification?
Writing is nature's way of letting you know how sloppy your thinking is.
-Guindon
A specification is a written description of what a system is supposed to do. Specifying a system helps us understand it. It's a good idea to understand a system before building it, so it's a good idea to write a specification of a system before implementing it.
This book is about specifying the behavioral properties of a system—also called its functional or logical properties. These are the properties that specify what the system is supposed to do. There are other important kinds of properties that we don't consider, including performance properties. Worst-case performance can often be expressed as a behavioral property—for example, Chapter 9 explains how to specify that a system must reactwithin a certain length of time. However, specifying average performance is beyond the scope of the methods described here.
Our basic tool for writing specifications is mathematics. Mathematics is nature's way of letting you know how sloppy your writing is. It's hard to be precise in an imprecise language like English or Chinese. In engineering, imprecision can lead to errors. To avoid errors, science and engineering have adopted mathematics as their language.
The mathematics we use is more formal than the math you've grown up with. Formal mathematics is nature's way of letting you know how sloppy your mathematics is. The mathematics written by most mathematicians and scientists is not really precise. It's precise in the small, but imprecise in the large. Each equation is a precise assertion, but you have to read the accompanying words to understand how the equations relate to one another and exactly what the theorems mean. Logicians have developed ways of eliminating those words and making the mathematics completely formal, and hence completely precise.
Most mathematicians and scientists think that formal mathematics, without words, is long and tiresome. They're wrong. Ordinary mathematics can be expressed compactly in a precise, completely formal language. It takes only about two dozen lines to define the solution to an arbitrary differential equation in the Differential Equations module of Chapter 11. But few specifications need such sophisticated mathematics. Most require only simple application of a few standard mathematical concepts.
Why TLA+?
We specify a system by describing its allowed behaviors—what it may do in the course of an execution. In 1977, Amir Pnueli introduced the use of temporal logic for describing system behaviors. In principle, a system could be described by a single temporal logic formula. In practice, it couldn't. Pnueli's temporal logic was ideal for describing some properties of systems, but awkward for others. So, it was usually combined with a more traditional way of describing systems.
In the late 1980s, I invented TLA, the Temporal Logic of Actions—a simple variant of Pnueli's original logic. TLA makes it practical to describe a system by a single formula. Most of a TLA specification consists of ordinary, nontemporal mathematics. Temporal logic plays a significant role only in describing those properties that it's good at describing. TLA also provides a nice way to formalize the style of reasoning about systems that has proved to be most effective in practice—a style known as assertional reasoning. However, this book is about specification; it says almost nothing about proofs.
Temporal logic assumes an underlying logic for expressing ordinary mathematics. There are many ways to formalize ordinary math. Most computer scientists prefer one that resembles their favorite programming language. I chose instead the one that most mathematicians prefer—the one logicians call first-order logic and set theory.
TLA provides a mathematical foundation for describing systems. To write specifications, we need a complete language built atop that foundation. I initially thought that this language should be some sort of abstract programming language whose semantics would be based on TLA. I didn't know what kind of programming language constructs would be best, so I decided to start writing specifications directly in TLA. I intended to introduce programming constructs as I needed them. To my surprise, I discovered that I didn't need them. What I needed was a robust language for writing mathematics.
Although mathematicians have developed the science of writing formulas, they haven't turned that science into an engineering discipline. They have developed notations for mathematics in the small, but not for mathematics in the large. The specification of a real system can be dozens or even hundreds of pages long. Mathematicians know how to write 20-line formulas, not 20-page formulas. So, I had to introduce notations for writing long formulas. What I took from programming languages were ideas for modularizing large specifications.
The language I came up with is called TLA+. I refined TLA+ in the course of writing specifications of disparate systems. But it has changed little in the last few years. I have found TLA+ to be quite good for specifying a wide class of systems—from program interfaces (APIs) to distributed systems. It can be used to write a precise, formal description of almost any sort of discrete system. It's especially well suited to describing asynchronous systems—that is, systems with components that do not operate in strict lock-step.
About This Book
Part I, consisting of Chapters 1 through 7, is the core of the book and is meant to be read from beginning to end. It explains how to specify the class of properties known as safety properties. These properties, which can be specified with almost no temporal logic, are all that most engineers need to know about. After reading Part I, you can read as much of Part II as you like. Each of its chapters is independent of the others. Temporal logic comes to the fore in Chapter 8, where it is used to specify the additional class of properties known as liveness properties. Chapter 9 describes how to specify real-time properties, and Chapter 10 describes how to write specifications as compositions. Chapter 11 contains more advanced examples.
The three chapters in Part III serve as the reference manual for three TLA+ tools: the Syntactic Analyzer, the TLATEX typesetting program, and the TLC model checker. If you want to use TLA+, then you probably want to use these tools. They are available from the TLA Web page. TLC is the most sophisticated of them. The examples on the Web can get you started using it, but you'll have to read Chapter 14 to learn to use TLC effectively.
Part IV is a reference manual for the TLA+ language. Part I provides a good enough working knowledge of the language for most purposes. You need look at Part IV only if you have questions about the fine points of the syntax and semantics. Chapter 15 gives the syntax of TLA+. Chapter 16 describes the precise meanings and the general forms of all the built-in operators of TLA+; Chapter 17 describes the precise meaning of all the higher-level TLA+ constructs such as definitions. Together, these two chapters specify the semantics of the language. Chapter 18 describes the standard modules—except for module RealTime, described in Chapter 9, and module TLC, described in Chapter 14. You might want to look at this chapter if you're curious about how standard elementary mathematics can be formalized in TLA+.
Part IV does have something you may want to refer to often: a mini-manual that compactly presents lots of useful information. Pages 268-273 list all TLA+ operators, all user-definable symbols, the precedence of all operators, all operators defined in the standard modules, and the ASCII representation of symbols.
Table of Contents
List of Figures and Tables.Acknowledgments.
Introduction.
I. Getting Started.
1. A Little Simple Math.
Propositional Logic.
Sets.
Predicate Logic.
Formulas and Language.
2. Specifying a Simple Clock.
Behaviors.
An Hour Clock.
A Closer Look at the Specification.
The Specification in TLA+.
An Alternative Specification.
3. An Asynchronous Interface.
The First Specification.
Another Specification.
Types: A Reminder.
Definitions.
Comments.
4. A FIFO.
The Inner Specification.
Instantiation Examined.
Instantiation Is Substitution.
Parametrized Instantiation.
Implicit Substitutions.
Instantiation Without Renaming.
Hiding the Queue.
A Bounded FIFO.
What We're Specifying.
5. A Caching Memory.
The Memory Interface.
Functions.
A Linearizable Memory.
Tuples as Functions.
Recursive Function Definitions.
A Write-Through Cache.
Invariance.
Proving Implementation.
6. Some More Math.
Sets.
Silly Expressions.
Recursion Revisited.
Functions versus Operators.
Using Functions.
Choose.
7. Writing a Specification: Some Advice.
Why Specify.
What to Specify.
The Grain of Atomicity.
The Data Structures.
Writing the Specification.
Some Further Hints.
When and How to Specify.
II: More Advanced Topics.
8. Liveness and Fairness.
Temporal Formulas.
Temporal Tautologies.
Temporal Proof Rules.
Weak Fairness.
The Memory Specification.
The Liveness Requirement.
Another Way to Write It.
A Generalization.
Strong Fairness.
The Write-Through Cache.
Quantification.
Temporal Logic Examined.
A Review.
Machine Closure.
Machine Closure and Possibility.
Refinement Mappings and Fairness.
The Unimportance of Liveness.
Temporal Logic Considered Confusing.
9. Real Time.
The Hour Clock Revisited.
Real-Time Specifications in General.
A Real-Time Caching Memory.
Zeno Specifications.
Hybrid System Specifications.
Remarks on Real Time.
10. Composing Specifications.
Composing Two Specifications.
Composing Many Specifications.
The FIFO.
Composition with Shared State.
Explicit State Changes.
Composition with Joint Actions.
A Brief Review.
A Taxonomy of Composition.
Interleaving Reconsidered.
Joint Actions Reconsidered.
Liveness and Hiding.
Liveness and Machine Closure.
Hiding.
Open-System Specifications.
Interface Refinement.
A Binary Hour Clock.
Refining a Channel.
Interface Refinement in General.
Open-System Specifications.
Should You Compose?.
11. Advanced Examples.
Specifying Data Structures.
Local Definitions.
Graphs.
Solving Differential Equations.
BNF Grammars.
Other Memory Specifications.
The Interface.
The Correctness Condition.
A Serial Memory.
A Sequentially Consistent Memory.
The Memory Specifications Considered.
III: The Tools.
12. The Syntactic Analyzer.
13. The TLATEX Typesetter.
Introduction.
Comment Shading.
How It Typesets the Specification.
How It Typesets Comments.
Adjusting the Output Format.
Output Files.
Trouble-Shooting.
Using LATEX Commands.
14. The TLC Model Checker.
Introduction to TLC.
What TLC Can Cope With.
TLC Values.
How TLC Evaluates Expressions.
Assignment and Replacement.
Evaluating Temporal Formulas.
Overriding Modules.
How TLC Computes States.
How TLC Checks Properties.
Model-Checking Mode.
Simulation Mode.
Views and Fingerprints.
Taking Advantage of Symmetry.
Limitations of Liveness Checking.
The TLC Module.
How to Use TLC.
Running TLC.
Debugging a Specification.
Hints on Using TLC Effectively.
What TLC Doesn't Do.
The Fine Print.
The Grammar of the Configuration File.
Comparable TLC Values.
IV: The TLA+ Language.
Mini-Manual 268-273.
15. The Syntax of TLA+.
The Simple Grammar.
The Complete Grammar.
Precedence and Associativity.
Alignment.
Comments.
Temporal Formulas.
Two Anomalies.
The Lexemes of TLA+.
16. The Operators of TLA+.
Constant Operators.
Boolean Operators.
The Choose Operator.
Interpretations of Boolean Operators.
Conditional Constructs.
The Let/In Construct.
The Operators of Set Theory.
Functions.
Records.
Tuples.
Strings.
Numbers.
. Nonconstant Operators.
Basic Constant Expressions.
The Meaning of a State Function.
Action Operators.
Temporal Operators.
17. The Meaning of a Module.
Operators and Expressions.
The Order and Arity of an Operator.
Expressions.
Simplifying Operator Application.
Expressions.
Levels.
Contexts.
The Meaning of a Expression.
The Meaning of a Module.
Extends.
Declarations.
Operator Definitions.
Function Definitions.
Instantiation.
Theorems and Assumptions.
Submodules.
Correctness of a Module.
Finding Modules.
The Semantics of Instantiation.
18. The Standard Modules.
Module Sequences.
Module FiniteSets.
Module Bags.
The Numbers Modules.
Index. 032114306XT07022002
Preface
This book will teach you how to write specifications of computer systems, using the language TLA+. It's rather long, but most people will read only Part I, which comprises the first 83 pages. That part contains all that most engineers need to know about writing specifications; it assumes only the basic background in computing and knowledge of mathematics expected of an undergraduate studying engineering or computer science. Part II contains more advanced material for more sophisticated readers. The remainder of the book is a reference manual—Part III for the TLA+ tools and Part IV for the language itself.
The TLA World Wide Web page contains material to accompany the book, including the TLA+ tools, exercises, references to the literature, and a list of corrections. There is a link to the TLA Web page on http://lamport.org. You can also find the page by searching the Web for the 21-letter string. Do not put this string in any document that might appear on the Web.
What Is a Specification? Writing is nature's way of letting you know how sloppy your thinking is.
—Guindon
A specification is a written description of what a system is supposed to do. Specifying a system helps us understand it. It's a good idea to understand a system before building it, so it's a good idea to write a specification of a system before implementing it.
This book is about specifying the behavioral properties of a system—also called its functional or logical properties. These are the properties that specify what the system is supposed to do. There are other important kinds of properties that we don't consider, including performance properties. Worst case performance can often be expressed as a behavioral property—for example, Chapter 9 explains how to specify that a system must react within a certain length of time. However, specifying average performance is beyond the scope of the methods described here.
Our basic tool for writing specifications is mathematics. Mathematics is nature's way of letting you know how sloppy your writing is. It's hard to be precise in an imprecise language like English or Chinese. In engineering, imprecision can lead to errors. To avoid errors, science and engineering have adopted mathematics as their language.
The mathematics we use is more formal than the math you've grown up with. Formal mathematics is nature's way of letting you know how sloppy your mathematics is. The mathematics written by most mathematicians and scientists is not really precise. It's precise in the small, but imprecise in the large. Each equation is a precise assertion, but you have to read the accompanying words to understand how the equations relate to one another and exactly what the theorems mean. Logicians have developed ways of eliminating those words and making the mathematics completely formal and, hence, completely precise.
Most mathematicians and scientists think that formal mathematics, without words, is long and tiresome. They're wrong. Ordinary mathematics can be expressed compactly in a precise, completely formal language. It takes only about two dozen lines to define the solution to an arbitrary differential equation in the DifferentialEquations module of Chapter 11. But few specifications need such sophisticated mathematics. Most require only simple application of a few standard mathematical concepts.
Why TLA+?We specify a system by describing its allowed behaviors—what it may do in the course of an execution. In 1977, Amir Pnueli introduced the use of temporal logic for describing system behaviors. In principle, a system could be described by a single temporal logic formula. In practice, it couldn't. Pnueli's temporal logic was ideal for describing some properties of systems, but awkward for others. So, it was usually combined with a more traditional way of describing systems.
In the late 1980's, I invented TLA, the Temporal Logic of Actions—a simple variant of Pnueli's original logic. TLA makes it practical to describe a system by a single formula. Most of a TLA specification consists of ordinary, nontemporal mathematics. Temporal logic plays a significant role only in describing those properties that it's good at describing. TLA also provides a nice way to formalize the style of reasoning about systems that has proved to be most effective in practice—a style known as assertional reasoning. However, this book is about specification; it says almost nothing about proofs.
Temporal logic assumes an underlying logic for expressing ordinary mathematics. There are many ways to formalize ordinary math. Most computer scientists prefer one that resembles their favorite programming language. I chose instead the one that most mathematicians prefer—the one logicians call first order logic and set theory.
TLA provides a mathematical foundation for describing systems. To write specifications, we need a complete language built atop that foundation. I initially thought that this language should be some sort of abstract programming language whose semantics would be based on TLA. I didn't know what kind of programming language constructs would be best, so I decided to start writing specifications directly in TLA. I intended to introduce programming constructs as I needed them. To my surprise, I discovered that I didn't need them. What I needed was a robust language for writing mathematics.
Although mathematicians have developed the science of writing formulas, they haven't turned that science into an engineering discipline. They have developed notations for mathematics in the small, but not for mathematics in the large. The specification of a real system can be dozens or even hundreds of pages long. Mathematicians know how to write 20-line formulas, not 20-page formulas. So, I had to introduce notations for writing long formulas. What I took from programming languages were ideas for modularizing large specifications.
The language I came up with is called TLA+. I refined TLA+ in the course of writing specifications of disparate systems. But it has changed little in the last few years. I have found TLA+ to be quite good for specifying a wide class of systems—from program interfaces (APIs) to distributed systems. It can be used to write a precise, formal description of almost any sort of discrete system. It's especially well suited to describing asynchronous systems—that is, systems with components that do not operate in strict lock-step.
About this BookPart I, consisting of Chapters 1 through 7, is the core of the book and is meant to be read from beginning to end. It explains how to specify the class of properties known as safety properties. These properties, which can be specified with almost no temporal logic, are all that most engineers need to know about.
After reading Part I, you can read as much of Part II as you like. Each of its chapters is independent of the others. Temporal logic comes to the fore in Chapter 8, where it is used to specify the additional class of properties known as liveness properties. Chapter 9 describes how to specify real-time properties, and Chapter 10 describes how to write specifications as compositions. Chapter 11 contains more advanced examples.
Part III serves as the reference manual for three TLA+ tools: the Syntactic Analyzer, the TLATEX typesetting program, and the TLC model checker. If you want to use TLA+, then you probably want to use these tools. They are available from the TLA Web page. TLC is the most sophisticated of them. The examples on the Web can get you started using it, but you'll have to read Chapter 14 to learn to use TLC effectively.
Part IV is a reference manual for the TLA+ language. Part I provides a good enough working knowledge of the language for most purposes. You need look at Part IV only if you have questions about the fine points of the syntax and semantics. Chapter 15 gives the syntax of TLA+. Chapter 16 describes the precise meanings and the general forms of all the built-in operators of TLA+; Chapter 17 describes the precise meaning of all the higher-level TLA+ constructs such as definitions. Together, these two chapters specify the semantics of the language. Chapter 18 describes the standard modules—except for module RealTime, described in Chapter 9, and module TLC, described in Chapter 14. You might want to look at this chapter if you're curious about how standard elementary mathematics can be formalized in TLA+.
Part IV does have something you may want to refer to often: a mini-manual that compactly presents lots of useful information. Pages 268-273 list all TLA+ operators, all user-definable symbols, the precedence of all operators, all operators defined in the standard modules, and the ASCII representation of symbols.