Download presentation
Presentation is loading. Please wait.
Published byCleopatra Leonard Modified over 9 years ago
1
1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington simmondsd@uncw.edu
2
2 Devon 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
3
3 Devon 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
4
4 Devon 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
5
5 Devon 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!!!
6
6 Devon M. Simmonds, Computer Science Department What is a Contract? As an example let’s think about the contract between a tenant and a landlord PartyObligationsBenefits TenantPay the rent at the beginning of the month. Stay at the apartment. LandlordKeep the apartment in a habitable state. Get the rent payment every month.
7
7 Devon 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
8
8 Devon 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
9
9 Devon 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
10
10 Devon 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.
11
11 Devon 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
12
12 Devon 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
13
13 Devon 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)
14
14 Devon 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 )
15
15 Devon 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
16
16 Devon 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
17
17 Devon M. Simmonds, Computer Science Department 17
18
18 Devon 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.
19
19 Devon M. Simmonds, Computer Science Department UML Notation for Interfaces Realization Dependency Provided 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.
20
20 Devon 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..
21
21 Devon 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.
22
22 Devon M. Simmonds, Computer Science Department 22
23
23 Devon 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
24
24 Devon M. Simmonds, Computer Science Department What was thus class about? 24
25
25 Devon M. Simmonds, Computer Science Department TheEnd CSC550, Devon M. Simmonds, Computer Science Department, University of North Carolina Wilmington ??????????????? …CSC550 … Q u e s t i o n s ?
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.