BN.com Gift Guide

Design by Contract, by Example / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $20.06
Usually ships in 1-2 business days
(Save 59%)
Other sellers (Paperback)
  • All (12) from $20.06   
  • New (7) from $41.50   
  • Used (5) from $20.05   

Overview

Design by contract is an underused--but powerful--aspect of the object-oriented software development environment. With roots in the Eiffel programming language, it has withstood the test of time, and found utility with other programming languages. Here, by using both the Eiffel and Java languages as guidance, Design by Contract, by Example paves the way to learning this powerful concept.

Through the following six teaching principles, the authors demonstrate how to write effective contracts and supporting guidelines. Readers will learn how to:

  1. Separate queries from commands
  2. Separate basic queries from derived queries
  3. Write a postcondition for each derived query that specifies what result can be returned
  4. Write a postcondition for each command that specifies the value of every basic query
  5. Decide on a suitable precondition for every query and command
  6. Write invariants to define unchanging properties of objects

Contracts are built of assertions, which are used to express preconditions, postconditions and invariants. Using the above principles, the authors provide a frank discussion of the benefits, as well as the potential drawbacks, of this programming concept. Insightful examples from both the Eiffel and Java programming languages are included, and the book concludes with a summary of design by contract principles and a cost-benefit analysis of their applications.

Design by Contract, by Example is the first book of its kind to offer an example-based approach to learning this important paradigm. If you are a developer seeking a way to improve your craft, this book will give you the necessary understanding of the concepts of contracts in software design.

0201634600B08142001

Read More Show Less

Product Details

  • ISBN-13: 9780201634600
  • Publisher: Addison-Wesley
  • Publication date: 10/28/2001
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 256
  • Product dimensions: 7.32 (w) x 8.97 (h) x 0.63 (d)

Meet the Author

Richard Mitchell is a senior consultant with InferData Corporation, specializing in object-oriented analysis and design. Before joining InferData full-time in 1999, he was a Professor of Computing at the University of Brighton, UK, where he was involved in teaching and researching object technology.

Jim McKim is Clinical Professor and Chair of the Department of Engineering and Science at Rensselaer Polytechnic Institute in Hartford, Connecticut. He has been teaching and consulting in the area of object oriented software development for some 10 years. Over the same period he has authored or coauthored numerous articles on Design by Contract for such publications as the Journal of Object-Oriented Programming and IEEE Computer.

0201634600AB08142001

Read More Show Less

Read an Excerpt

WHAT THE BOOK COVERS

Design by contract is all about adding assertions to object-oriented programs, at the design and coding stages. Assertions are facts about a program that must be true for the program to be bug-free. The key assertions in design by contract define preconditions, postconditions, and invariants:

  • A precondition is a condition on a method specifying what must be true for it to be valid to call the method.
  • A postcondition is a condition on a method specifying what will become true when the method successfully completes.
  • An invariant is a condition on a whole class specifying what is true about any object of the class whenever you can call a method on that object.

The assertions are written in a programming language, so that

  • They make sense to programmers, providing good, helpful documentation.
  • They can be checked at runtime, providing support for testing and debugging.

This book concentrates on showing you how to write good contracts. The book presents six principles for writing good contracts, and some supporting guidelines. Through examples, the book motivates the principles and guidelines and shows them in use.

After studying the first three chapters, you will be in a position to write high-quality contracts. The rest of the book will help you do even better.

In addition to chapters that develop contracts for individual example classes, there are chapters on contracts in relation to inheritance and on the topic of frame rules (contracts that assert what does not change). Two larger examples towards the end of the book involve developing contracts across more than one class. Chapter 9 concerns the Observer pattern from Gamma et al. 1994, and Chapter 10 presents a small application in which an object in the user interface is shown to respect part of a contract in the heart of the application. Chapter 12 discusses the use of contracts in systems analysis. Chapter 8 reviews the benefits of using contracts and compares design by contract to defensive programming. Chapter 11 explores how to attach contracts to interfaces and explores briefly how you might implement contracts in a distributed environment.

PROGRAMMING LANGUAGES

The examples are presented first in the object-oriented programming language Eiffel. We chose Eiffel for three reasons:

  1. Eiffel has built-in support for contracts, so it is excellent for showing the concepts at work.
  2. Eiffel is easy to read, so it's a good pseudo-code from which you can implement the ideas in any object-oriented programming language.
  3. Commercial-strength compilers are available for Eiffel, so our contracts can play both their intended roles, as specifications and as checks. A contract is a specification of a class, describing precisely what services the class delivers. The assertions in a contract can be evaluated at runtime to check that the implementing code is consistent with its specification.

You don't have to be an Eiffel programmer to follow the examples. We are sure you'll be able to carry the principles over to your own programming environment. The issues we raise, and the advice we give, are not specific to Eiffel.

We do rework two of our examples in Java, using a preprocessor (called iContract) that provides support for contracts. This allows us to explore some issues that do not arise so directly in Eiffel and to show you contracts in another language.

WHO THE BOOK IS FOR

The book is written for anyone who wants to find out how to write good contracts. We intend it to be useful to practitioners, students (especially the early chapters), teachers, and researchers.

We don't believe the book is one you can curl up with by the fire (in winter) or the pool (in summer) and read your way through. We believe its material has to be studied and, most importantly, tried out. We hope you have access to a programming environment that supports contracts, such as a Java compiler and the iContract tool (see the bibliography for more information) or an Eiffel compiler (again, more information in the bibliography).

We do not teach object-oriented programming. We assume you know how to program in some object-oriented programming language. We have tried to give enough explanation of the Eiffel and Java code that those familiar with other OO languages can follow the examples.

STYLE

The book is based firmly on examples. Usually, a chapter is based on a single example. This means that there is quite a lot of code to wade through at times. However, most of the code is at the level of assertions, which define what a piece of program achieves. This level of code is generally easier to understand than the code that defines how a piece of program achieves its goal. In addition, we usually dissect the code a few lines at a time to make it easier to follow the discussion.

The examples are mostly simple ones. For example, instead of writing full contracts for the customer manager component introduced in Chapter 1, we write them for a look-up table (or dictionary), which is the data structure that underpins the customer manager component. That way, you won't get lost in too many details, and you won't lose sight of the basic principles. Once you see the principles, we are confident you'll be able to apply them to your own, more complicated examples.

We have been selective in what we put into this book. Other books have useful and insightful things to say on the subject of design by contract, but we have concentrated on what makes this book different—the advice it gives on how to write good contracts.

And, of course, this book is not the end of the story of design by contract. There is more work to be done on writing contracts, on developing the underlying technology and the underlying theory, on applying the ideas in broader contexts, and on assessing the benefits in practice.

WEB SITE

There is a Web site associated with the book. It contains the source code of the examples. Our hope is that you will download the code and play with it. Change the code. Add bugs, both in the implementation and in the contracts, and see what happens. Change the examples into new ones. Experiment. Use them on real projects. That's how we learned about contracts.

Read More Show Less

Table of Contents

Foreword.

Preface.

1. A First Taste of Design by Contract.

About This Chapter.

The Customer Manager Example.

Some Questions.

A Contract for CUSTOMER_MANAGER.

The Story So Far.

Runtime Checking.

Trustworthy Documentation.

Summary.

An Aide Memoire.

Things to Do.

2. Elementary Principles of Design by Contract.

About This Chapter.

Stacks.

Separate Commands and Queries.

Naming Conventions.

Separate Basic Queries and Derived Queries.

Specify How Commands Affect Basic Queries.

Capture Unchanging Properties in Invariants.

The Class and Its Contract.

The Basic Queries Are a Conceptual Model of Stacks.

The Six Principles.

Things to Do.

3. Applying the Six Principles.

About This Chapter.

Dictionaries.

Separating and Categorizing Features.

Postconditions.

Preconditions.

Invariant.

A Complete, Contract-Level View of DICTIONARY.

Summary.

Things to Do.

4. Building Support for Contracts—Immutable Lists.

About This Chapter.

Support for Linear Structures.

Contracts Involve Expressions.

Immutable Lists.

A Contract for Immutable Lists.

The Basic Queries.

The Creation Command.

The Derived Query Count.

The Derived Query Preceded_by.

The Derived Query Item.

The Derived Query is_equal.

The Derived Query Sublist.

Summary.

Things to Do.

5. Applying the Six Principles to QUEUE.

About This Chapter.

Queues.

A Contract for the Remove Feature.

Making Count a Derived Feature.

A Contract for the Initialize Feature.

A Contract for the Head Feature.

A Contract for the put Feature.

More Derived Queries.

Summary.

Things to Do.

6. Design by Contract and Inheritance.

About This Chapter.

Superclasses and Subclasses.

Redefining Contracts.

Eiffel Syntax.

Summary.

Invariants and Inheritance.

Designing Superclasses with Guarded Postconditions.

Two Kinds of Inheritance.

Summary.

Things to Do.

7. Frame Rules.

About This Chapter.

Change Specifications and Frame Rules.

Frame Rules for put Using Immutable Lists.

Frame Rules for put Using “Forall”.

Kinds of Frame Rules.

Things to Do.

Appendix: More About the Preprocessor.

8. Benefits of Design by Contract.

About This Chapter.

Kinds of Benefits.

Better Designs.

Improved Reliability.

Better Documentation.

Easier Debugging.

Support for Reuse.

Design by Contract and Defensive Programming.

Defending a Program Against Unwanted Input.

Bulletproofing a Routine.

Defensive Programming.

Some Costs and Limitations of Contracts.

9. Contracts for an Observer Framework.

About This Chapter.

The Observer Framework.

Immutable Sets.

Attaching and Detaching Observers.

Notification (For One Observer).

Notification (For All Observers).

A Performance Issue.

Frame Rules.

Privacy.

Things to Do.

10. Fulfilling a Precondition.

About This Chapter.

The Examples.

Fulfilling and Testing a Precondition.

Testing Versus Checking.

A Simple Counter Class.

The User's View of the Program.

The Internal Structure of the Program.

The Program's Behavior.

A Minor Detail.

Summary.

Things to Do.

11. Java Examples.

About This Chapter.

Why Java?

Queues.

The Basic Query size().

The Basic Query get().

The Derived Query head().

The Derived Query isEmpty().

The Derived Query shallowCopy().

The Constructor Queue.

The Command put.

The Command remove.

Summary.

Dictionaries.

Names.

The Invariant.

The Basic Queries.

A Derived Query.

The Commands.

The Constructor.

A Possible Set of Classes.

Java Without iContract.

Precondition Testing.

Things to Do.

12. Analysis by Contract.

About This Chapter.

A Use Case.

Contracts in Analysis Models.

A Contract for the withdrawCash Use Case.

From Analysis to Design.

Problem Domain and System Models.

The Object Constraint Language.

Summary.

Bibliography.

Index. 0201634600T10102001

Read More Show Less

Preface

WHAT THE BOOK COVERS

Design by contract is all about adding assertions to object-oriented programs, at the design and coding stages. Assertions are facts about a program that must be true for the program to be bug-free. The key assertions in design by contract define preconditions, postconditions, and invariants:

  • A precondition is a condition on a method specifying what must be true for it to be valid to call the method.
  • A postcondition is a condition on a method specifying what will become true when the method successfully completes.
  • An invariant is a condition on a whole class specifying what is true about any object of the class whenever you can call a method on that object.

The assertions are written in a programming language, so that

  • They make sense to programmers, providing good, helpful documentation.
  • They can be checked at runtime, providing support for testing and debugging.

This book concentrates on showing you how to write good contracts. The book presents six principles for writing good contracts, and some supporting guidelines. Through examples, the book motivates the principles and guidelines and shows them in use.

After studying the first three chapters, you will be in a position to write high-quality contracts. The rest of the book will help you do even better.

In addition to chapters that develop contracts for individual example classes, there are chapters on contracts in relation to inheritance and on the topic of frame rules (contracts that assert what does not change). Two larger examples towards the end of the book involve developing contracts across more than one class. Chapter 9 concerns the Observer pattern from Gamma et al. 1994, and Chapter 10 presents a small application in which an object in the user interface is shown to respect part of a contract in the heart of the application. Chapter 12 discusses the use of contracts in systems analysis. Chapter 8 reviews the benefits of using contracts and compares design by contract to defensive programming. Chapter 11 explores how to attach contracts to interfaces and explores briefly how you might implement contracts in a distributed environment.

PROGRAMMING LANGUAGES

The examples are presented first in the object-oriented programming language Eiffel. We chose Eiffel for three reasons:

  1. Eiffel has built-in support for contracts, so it is excellent for showing the concepts at work.
  2. Eiffel is easy to read, so it's a good pseudo-code from which you can implement the ideas in any object-oriented programming language.
  3. Commercial-strength compilers are available for Eiffel, so our contracts can play both their intended roles, as specifications and as checks. A contract is a specification of a class, describing precisely what services the class delivers. The assertions in a contract can be evaluated at runtime to check that the implementing code is consistent with its specification.

You don't have to be an Eiffel programmer to follow the examples. We are sure you'll be able to carry the principles over to your own programming environment. The issues we raise, and the advice we give, are not specific to Eiffel.

We do rework two of our examples in Java, using a preprocessor (called iContract) that provides support for contracts. This allows us to explore some issues that do not arise so directly in Eiffel and to show you contracts in another language.

WHO THE BOOK IS FOR

The book is written for anyone who wants to find out how to write good contracts. We intend it to be useful to practitioners, students (especially the early chapters), teachers, and researchers.

We don't believe the book is one you can curl up with by the fire (in winter) or the pool (in summer) and read your way through. We believe its material has to be studied and, most importantly, tried out. We hope you have access to a programming environment that supports contracts, such as a Java compiler and the iContract tool (see the bibliography for more information) or an Eiffel compiler (again, more information in the bibliography).

We do not teach object-oriented programming. We assume you know how to program in some object-oriented programming language. We have tried to give enough explanation of the Eiffel and Java code that those familiar with other OO languages can follow the examples.

STYLE

The book is based firmly on examples. Usually, a chapter is based on a single example. This means that there is quite a lot of code to wade through at times. However, most of the code is at the level of assertions, which define what a piece of program achieves. This level of code is generally easier to understand than the code that defines how a piece of program achieves its goal. In addition, we usually dissect the code a few lines at a time to make it easier to follow the discussion.

The examples are mostly simple ones. For example, instead of writing full contracts for the customer manager component introduced in Chapter 1, we write them for a look-up table (or dictionary), which is the data structure that underpins the customer manager component. That way, you won't get lost in too many details, and you won't lose sight of the basic principles. Once you see the principles, we are confident you'll be able to apply them to your own, more complicated examples.

We have been selective in what we put into this book. Other books have useful and insightful things to say on the subject of design by contract, but we have concentrated on what makes this book different--the advice it gives on how to write good contracts.

And, of course, this book is not the end of the story of design by contract. There is more work to be done on writing contracts, on developing the underlying technology and the underlying theory, on applying the ideas in broader contexts, and on assessing the benefits in practice.

WEB SITE

There is a Web site associated with the book. It contains the source code of the examples. Our hope is that you will download the code and play with it. Change the code. Add bugs, both in the implementation and in the contracts, and see what happens. Change the examples into new ones. Experiment. Use them on real projects. That's how we learned about contracts.

0201634600P12122001

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)