1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer...

25
1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington [email protected]

Transcript of 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer...

Page 1: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

1Devon M. Simmonds, Computer Science Department

Design by Contract

Devon M. SimmondsComputer Science Department

University of North Carolina, [email protected]

Page 2: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

2Devon M. Simmonds, Computer Science Department

Lecture Outline

• Design by Contract (DBC) Fundamentals– Contracts– Preconditions, postconditions and class invariants

• Interfaces as Contracts• Benefits of DBC• Summary

Page 3: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

3Devon M. Simmonds, Computer Science Department

Dependability and Object-Orientation

• An important aspect of object oriented design is reuse– For reusable components correctness is crucial since an error in a

module can affect every other module that uses it

• Main goal of object oriented design and programming is to improve the quality of software– The most important quality of software is its dependability

• Design by contract presents a set of principles to produce dependable and robust object oriented software– Basic design by contract principles can be used in any object oriented

programming language

Page 4: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

4Devon M. Simmonds, Computer Science Department

DBC Fundamentals

• A Client-Server Design• Server Objects

– Provides services for client objects to use– The object whose methods are being invoked

• Client Object– Consumes the services offered by the supplier

object– The object that invokes the methods of the

supplier object

Page 5: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

5Devon M. Simmonds, Computer Science Department

DBC Fundamentals

• Contract– A set of benefits and obligations that are mutually

agreed upon by the client and supplier– In practice, specified by the supplier object– Clients implicitly accept the contract by using

objects of the supplier class• Good contracts are always in writing!!!

Page 6: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

6Devon M. Simmonds, Computer Science Department

What is a Contract?

• As an example let’s think about the contract between a tenant and a landlord

Party Obligations Benefits

Tenant Pay the rent at the beginning of the month.

Stay at the apartment.

Landlord Keep the apartment in a habitable state.

Get the rent payment every month.

Page 7: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

7Devon M. Simmonds, Computer Science Department

What is a Contract?

• A contract document between a client and a supplier protects both sides– It protects the client by specifying how much should be done to get

the benefit. The client is entitled to receive a certain result.– It protects the supplier by specifying how little is acceptable. The

supplier must not be liable for failing to carry out tasks outside of the specified scope.

• If a party fulfills its obligations it is entitled to its benefits– No Hidden Clauses Rule: no requirement other than the obligations

written in the contract can be imposed on a party to obtain the benefits

Page 8: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

8Devon M. Simmonds, Computer Science Department

How Do Contracts Relate to Software Design?

• You are not in law school, so what are we talking about?• Here is the basic idea

– One can think of pre and post conditions of a procedure as obligations and benefits of a contract between the client (the caller) and the supplier (the called procedure)

• Design by contract promotes using pre and post-conditions (written as assertions) as a part of module design

• Eiffel is an object oriented programming language that supports design by contract– In Eiffel the pre and post-conditions are written using require and

ensure constructs, respectively

Page 9: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

9Devon M. Simmonds, Computer Science Department

Defensive Programming vs. Design by Contract

• Defensive programming is an approach that promotes putting checks in every module to detect unexpected situations

• This results in redundant checks (for example, both caller and callee may check the same condition) – A lot of checks makes the software more complex and harder to

maintain

• In Design by Contract the responsibility assignment is clear and it is part of the module interface– prevents redundant checks– easier to maintain– provides a (partial) specification of functionality

Page 10: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

10Devon M. Simmonds, Computer Science Department

DBC - A Little History• Design by Contract and the language that implements the Design by

Contract principles (called Eiffel) was developed in Santa Barbara by Bertrand Meyer (he was a UCSB professor at the time, now he is at ETH- The Swiss Federal Institute of Technology, Zurich)

• Bertrand Meyer won the 2006 ACM Software System Award for the Eiffel! – Award citation: “For designing and developing the Eiffel programming

language, method and environment, embodying the Design by Contract approach to software development and other features that facilitate the construction of reliable, extendible and efficient software.”

• The company which supports the Eiffel language is located in Santa Barbara:– Eiffel Software (http://www.eiffel.com)

• The material in some slides is from the seminal paper: – “Applying Design by Contract,” B. Meyer, IEEE Computer, pp. 40-51,

October 1992.

Page 11: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

11Devon M. Simmonds, Computer Science Department

Preconditions

• Each supplier method must specify the preconditions that must be true before the method is executed

• Client object must ensure that preconditions are met

• In practice, testing of the preconditions is performed within the suppliers’ methods

• Coupled to individual methods

Page 12: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

12Devon M. Simmonds, Computer Science Department

Postconditions

• Each supplier method must specify the postconditions that must be true after the method is executed

• Supplier object must ensure that postconditions are met

• Guarantee to client object that supplier object is living up to its end of the bargain

• Coupled to individual methods

Page 13: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

13Devon M. Simmonds, Computer Science Department

Pre/Post Conditions

• The pre and postconditions are assertions, i.e., they are expressions which evaluate to true or false– The precondition expresses the requirements that any call must satisfy– The postcondition expresses the properties that are ensured at the

end of the procedure execution

• If there is no precondition or postcondition, then the precondition or postcondition is assumed to be true (which is equivalent to saying there is no pre or postcondition)

Page 14: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

14Devon M. Simmonds, Computer Science Department

Class Invariants• A class invariant is an assertion that holds for all instances

(objects) of the class– A class invariant must be satisfied after creation of every instance of

the class– The invariant must be preserved by every method of the class, i.e., if

we assume that the invariant holds at the method entry it should hold at the method exit

– We can think of the class invariant as conjunction added to the precondition and postcondition of each method in the class

• For example, a class invariant for a binary tree could be (in Eiffel notation)

invariant left /= Void implies (left.parent = Current) right /=Void implies (right.parent = Current)

Page 15: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

15Devon M. Simmonds, Computer Science Department

Class Invariants

• Those conditions that must exist for all visible methods of a class

• Coupled to objects, not methods• Adding an invariant is similar to adding the

same constraint as a precondition and postcondition for all methods in a class

Page 16: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

16Devon M. Simmonds, Computer Science Department

Class Invariants

• In practice,– Invariants do not have to be met by private

routines– Supplier methods must ensure that all class

invariants are met before returning control to the client object

Page 17: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

17Devon M. Simmonds, Computer Science Department

Interfaces as

Contracts

1717

Page 18: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

18Devon M. Simmonds, Computer Science Department

What is a Component?

• Szyperski:– A software component is a unit of

composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third-parties.

Page 19: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

19Devon M. Simmonds, Computer Science Department

UML Notation for Interfaces

Realization DependencyProvided Interfaces

Usage Dependency/Required Interface

19

• Interface realization means ProximitySensor implements the operations defined by ISensor. – ISensor is called a provided interface for

ProximitySensor.• Interface usage means TheAlarm uses the operations

defined by ISensor. – ISensor is called a required interface for TheAlarm.

Page 20: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

20Devon M. Simmonds, Computer Science Department

If an Interface is a contract what should the contract

include?• Operations

– Preconditions– Postconditions– Component-level invariants? How?– What effects do implementation changes have on

contracts?• A math library used by an animation package.• What happens if the math library is improved to deliver more

accurate results but at a lower speed?– animation package fails because library package rate is too small..

Page 21: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

21Devon M. Simmonds, Computer Science Department

Contracts and NON-functional Requirements

• So-called Service-Level– Mean time between failures– Mean time to repair– Throughput– Latency– Data safety– Capacity– Time– Etc.

Page 22: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

22Devon M. Simmonds, Computer Science Department

Benefits of DBC

2222

Page 23: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

23Devon M. Simmonds, Computer Science Department

Benefits of DBC Techniques

• Better understood behavior (on both sides)• Clear demarcation between client and supplier• Documentation reflects code reality• Easier to write test drivers• More reliable software

Page 24: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

24Devon M. Simmonds, Computer Science Department

• What was thus class about?

Summary

2424

Page 25: 1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.

25Devon M. Simmonds, Computer Science Department

The End

CSC550, Devon M. Simmonds, Computer Science Department, University of North Carolina Wilmington

???????????????

…CSC550 …

Q u e s t i o n s ?