|
|
|
|
| LEADER |
04541nmm a2200313 u 4500 |
| 001 |
EB000619185 |
| 003 |
EBX01000000000000000472267 |
| 005 |
00000000000000.0 |
| 007 |
cr||||||||||||||||||||| |
| 008 |
140122 ||| eng |
| 020 |
|
|
|a 9781461227045
|
| 100 |
1 |
|
|a Guttag, John V.
|
| 245 |
0 |
0 |
|a Larch: Languages and Tools for Formal Specification
|h Elektronische Ressource
|c by John V. Guttag, James J. Horning
|
| 250 |
|
|
|a 1st ed. 1993
|
| 260 |
|
|
|a New York, NY
|b Springer New York
|c 1993, 1993
|
| 300 |
|
|
|a XIII, 250 p
|b online resource
|
| 505 |
0 |
|
|a 1 Specifications in Program Development -- 1.1 Programming with abstractions -- 1.2 Finding abstractions -- 1.3 The many roles of specification -- 1.4 Styles of specification -- 1.5 Formal specifications -- 2 A Little Bit of Logic -- 2.1 Basic logical concepts -- 2.2 Proof and consequences -- 3 An Introduction to Larch -- 3.1 Two-tiered specifications -- 3.2 LSL, the Larch Shared Language -- 3.3 Interface specifications -- 3.4 Relating implementations to specifications -- 3.5 LP, the Larch proof assistant -- 3.6 Lexical and typographic conventions -- 4 LSL: The Larch Shared Language -- 4.1 Equational specifications -- 4.2 Stronger theories -- 4.3 Combining traits -- 4.4 Renaming -- 4.5 Stating intended consequences -- 4.6 Recording assumptions -- 4.7 Built-in operators and overloading -- 4.8 Shorthands -- 4.9 Further examples -- 5 LCL: A Larch Interface Language for C -- 5.1 The relation between LCL and C -- 5.2 Function specifications --
|
| 505 |
0 |
|
|a 5.3 A guided tour through an LCL specification -- 6 LM3: A Larch Interface Language for Modula-3 -- 6.1 The relation between LM3 and Modula-3 -- 6.2 The LM3 semantic model -- 6.3 A guided tour through an LM3 specification -- 7 Using LP to Debug LSL Specifications -- 7.1 Semantic checks in LSL -- 7.2 Proof obligations for LSL specifications -- 7.3 Translating LSL traits into LP -- 7.4 Proof mechanisms in LP -- 7.5 Checking theory containment -- 7.6 Checking consistency -- 7.7 Extended example -- 7.8 Perspective -- 8 Conclusion -- A An LSL Handbook -- A.1 Introduction -- A.2 Foundations -- A.3 Integers -- A.4 Enumerations -- A.5 Containers -- A.6 Branching structures -- A.7 Maps -- A.8 Relations -- A.9 Graph theory -- A.10 Properties of single operators -- A.11 Properties of relational operators -- A.12 Orderings -- A.13 Lattice theory -- A.14 Group theory -- A.15 Number theory -- A.16 Floating point arithmetic -- B Implementations of Example LCL Interfaces --
|
| 505 |
0 |
|
|a C Lexical Forms and Initialization Files -- D Further Information and Tools -- E Classified Bibliography -- References
|
| 653 |
|
|
|a Formal Languages and Automata Theory
|
| 653 |
|
|
|a Machine theory
|
| 700 |
1 |
|
|a Horning, James J.
|e [author]
|
| 041 |
0 |
7 |
|a eng
|2 ISO 639-2
|
| 989 |
|
|
|b SBA
|a Springer Book Archives -2004
|
| 490 |
0 |
|
|a Monographs in Computer Science
|
| 028 |
5 |
0 |
|a 10.1007/978-1-4612-2704-5
|
| 856 |
4 |
0 |
|u https://doi.org/10.1007/978-1-4612-2704-5?nosfx=y
|x Verlag
|3 Volltext
|
| 082 |
0 |
|
|a 005.131
|
| 520 |
|
|
|a Building software often seems harder than it ought to be. It takes longer than expected, the software's functionality and performance are not as wonderful as hoped, and the software is not particularly malleable or easy to maintain. It does not have to be that way. This book is about programming, and the role that formal specifications can play in making programming easier and programs better. The intended audience is practicing programmers and students in undergraduate or basic graduate courses in software engineering or formal methods. To make the book accessible to such an audience, we have not presumed that the reader has formal training in mathematics or computer science. We have, however, presumed some programming experience. The roles of fonnal specifications Designing software is largely a matter of combining, inventing, and planning the implementation of abstractions. The goal of design is to describe a set of modules that interact with one another in simple, well defined ways. If this is achieved, people will be able to work independently on different modules, and yet the modules will fit together to accomplish the larger purpose. In addition, during program maintenance it will be possible to modify a module without affecting many others. Abstractions are intangible. But they must somehow be captured and communicated. That is what specifications are for. Specification gives us a way to say what an abstraction is, independent of any of its implementations
|