Table Of ContentFORMAL SPECIFICATION
TECHNIQUES FOR ENGINEERING
MODULAR C PROGRAMS
The Kluwer International Series in
Software Engineering
Series Editor
Victor R. Basili
University of Maryland
College Park, MD 20742
The Kluwer International Series in Software Engineering will
address the following goals:
*
To coherently and consistent~y pre~ent-important research topics
and their application(s).
*
To present evolved concepts in one place as a coherent whole,
updating early versions of the ideas and notations.
*
To provide publications which will be used as the ultimate
reference on the topic by experts in the area.
With the dynamic growth evident in this field and the need to
communicate findings, this book series will provide a forum for
information targeted toward Software Engineers.
FORMAL SPECIFICATION
TECHNIQUES FOR ENGINEERING
MODULAR C PRO GRAMS
by
TAN Yang Meng
Dejence Science Organisation
Singapore
Foreword by lohn Guttag, Cambridge, Massachusetts
.
.,
~
SPRINGER SCIENCE+BUSINESS MEDIA, LLC
Library of Congress Cataloging-in-Publication Data
Tan, Yang Meng.
Formal specification techniques for engineering modular C pro grams
/ Tan Yang Meng ; forword by John Guttag.
p. cm. -- (The Kluwer international series in software engineering; 1)
Includes index.
ISBN 978-1-4613-6850-2 ISBN 978-1-4615-4125-7 (eBook)
DOI 10.1007/978-1-4615-4125-7
1. C (Computer program language) 2. Software engineering.
I. Title. 11. Series.
QA76.73.CI5T36 1996
005. 13'3--dc20 95-40529
CIP
Copyright @ 1996 by Springer Science+Business Media New York
Originally published by Kluwer Academic Publishers in 1996
Softcover reprint of the hardcover 1s t edition 1996
All rights reserved. No part of this publication may be reproduced, stored in
a retrieval system or transmitted in any form or by any means, mechanical,
photo-copying, recording, or otherwise, without the prior written permission of
the publisher, Springer Science+Business Media, LLC.
Printed on acid-free paper.
CONTENTS
FOREWORD ix
PREFACE
Xlll
1 INTRODUCTION 1
1.1 The Problems and the Approach 2
1.2 Larch/C Interface Language 6
1.3 Related Work 7
1.4 Key Lessons Learned 11
1.5 Research Contributions 14
2 OVERVIEW OF LCL 17
2.1 Larch 17
2.2 LCL Basics 18
2.3 LCL Function Specification 19
2.4 LCL Abstract Type Specification 21
2.5 Historical Note 23
3 SUPPORTING PROGRAMMING STYLES 25
3.1 Specified Interfaces and Data Abstraction 25
3.2 Specified Interfaces in C 26
3.3 Abstract Types in C 27
3.4 Tool Support: LCLint 30
3.5 Summary 33
4 SPECIFICATION TECHNIQUES 35
4.1 Requirements of the Program 36
4.2 The Design of the PM Program 39
4.3 Overview of Specification Techniques 40
4.4 The date Interface 42
4.5 The trans Traits 46
4.6 The trans Interface 48
4.7 The trans...set Interface and Trait 51
4.8 The position Traits 57
4.9 The position Interface 60
4.10 Summary 65
5 REDUNDANCY IN SPECIFICATIONS 67
5.1 Testing Specifications 68
5.2 Semantics of Claims 69
5.3 Claims Help Test Specifications 72
5.4 Claims Help Specification Regression Testing 76
5.5 Claims Highlight Specification Properties 78
5.6 Claims Promote Module Coherence 82
5.7 Claims Support Program Reasoning 84
5.8 Claims Support Test Case Generation 85
5.9 Experiences in Checking LCL Claims 85
5.10 Claims or Axioms? 90
5.11 Summary 91
6 REENGINEERING USING LCL 93
6.1 Software Reengineering Process Model 94
6.2 A Reengineering Exercise 96
6.3 Effects of Reengineering 101
6.4 Specification Tool Support 105
6.5 Summary 106
7 THE SEMANTICS OF LCL 109
7.1 Basic LCL Concepts 110
7.2 LCL Storage Model 111
7.3 LCL Type System 114
7.4 LCL Function Specification 119
7.5 LCL Module 125
vi
7.6 Type Safety of Abstract Types 141
7.7 Summary 143
8 FURTHER WORK AND SUMMARY 145
8.1 Further Work 145
8.2 Summary 149
A LCL REFERENCE GRAMMAR 151
B RELATING LCL TYPES AND LSL SORTS 155
B.1 Modeling LCL Exposed Types with LSL Sorts 155
B.2 Assigning LSL Sorts to LCL Variables 157
B.3 Assigning LSL Sorts to C Literals 158
C LCL BUILT-IN OPERATORS 159
D SPECIFICATION CASE STUDY 165
D.1 The char Trait 165
D.2 The cstring Trait 166
D.3 The string Trait 167
D.4 The mystdio Trait 168
D.5 The genlib Trait 169
D.6 The dateBasics Trait 170
D.7 The dateFormat Trait 171
D.8 The date Trait 172
D.9 The security Trait 173
D.lO The lot Trait 174
D.ll The list Trait 174
D.12 The lotJist Trait 175
D.13 The kind Trait 175
D.14 The transBasics Trait 176
D.15 The transFormat Trait 176
D.16 The transParse Trait 177
D. 17 The trans Trait 179
D.18 The tranSJlet Trait 179
D.19 The income Trait 180
vii
D.20 The positionBasics Trait 181
D.21 The positionMatches Trait 182
D.22 The position Exchange Trait 183
D.23 The positionReduce Trait 183
D.24 The positionSell Trait 184
D.25 The positionTbill Trait 186
D.26 The position Trait 186
D.27 The genlib Interface 188
D.28 The date Interface 189
D.29 The security Interface 191
D.30 The lotlist Interface 191
D.31 The trans Interface 192
D .32 The trans...set Interface 195
D.33 The position Interface 196
E GETTING LARCH TOOLS AND
INFORMATION 203
REFERENCES 205
INDEX 209
viii
FOREWORD
The essence of software construction is combining, inventing, and planning the
implementation of abstractions. The trick is to describe a set of modules that
interact with one another in simple, well-defined ways. If this is achieved, mod
ules can be worked on independently, and yet will fit together to accomplish
the larger purpose. During initial development this permits simultaneous de
velopment of modules. During program maintenance it makes it possible to
modify a module without affecting many others.
A difficulty is that abstractions are intangible. Nevertheless, they must some
how be captured and communicated. That is what specifications are for. Spec
ification gives us a way to say what an abstraction is, independent of any of its
implementations and independent of how it might be used.
This book is about formal specifications, that is to say specifications written in
a language with a well-defined syntax and semantics. We use formal languages
because we know of no other way to make specifications simultaneously as pre
cise, clear, and concise. Why not use natural language to write specifications?
For the same reason we do not use natural language to specify a musical com
position, an architectural plan, or a chip design. It is exceedingly difficult to
achieve even precision in a natural language-let alone clarity and brevity.
Another advantage of formal specifications is that they can easily be processed
by machines. Mistakes of many kinds will crop up in specifications, just as
they do in programs. Tools can be used to help write, debug, and even read
specifications.
Some programmers are intimidated by the mere idea of formal specifications,
which they fear may be too "mathematical" for them to understand and use.
Such fears are groundless. Anyone who can learn to use a programming lan
guage can learn to use a formal specification language. After all, programs
themselves are formal texts. Programmers cannot escape from formality and
mathematical precision, even if they want to.
The specifications in this book are written in LCL, a member of the Larch family
of languages. Larch's roots can be traced back to work I did as a graduate
student, under the supervision of Jim Horning at the University of Toronto.
In 1974, we proposed a combination of algebraic and operational specifications
which we referred to as "dyadic specification." By 1980 we had evolved the
essence of the two-tiered style of specification used in this book. The first rea
sonably comprehensive description of this approach to specification was pub
lished in 1985. The first complete Larch interface language was Jeannette
Wing's Larch/CLU.
While widely known in the formal methods community, our early work on Larch
had little impact in the wider software engineering community and next to no
impact on practicing programmers. This was a source of great frustration to
us, and prompted us to shift the emphasis of our work.
In the late 1980's we began to concentrate on the tight integration of the Larch
technology with standard programming languages and tools and on providing a
path for the gradual integration of formal methods into standard programming
practice. This book reports some results of that effort.
The book presents
• LCL, a language for specifying modules designed for invocation from pro
grams written in Standard c. LCL is not a C dialect. Programs spec
ified and developed with LCL are C programs, accepted by ordinary C
compilers. LCL is presented here in enough detail to permit interested
readers to start writing their own specifications. (If you are interested
in doing this, I strongly urge you to get the LCL tools before starting.
The tools are available, at no cost. For information consult http://larch
www.lcs.mit.edu:8001/larch on the World Wide Web or send e-mail to
evs@larch.lcs.mit.edu.),
• A way to introduce useful redundancy into specifications. This redundancy
is used to highlight important properties, both local and non-local, of
specifications.
• A substantial example of how formal specifications can be used in practice.
Particular attention is devoted to the reengineering of applications, and
• A style of C programming in which abstract types playa major role.
x