1. 91.3913Feb 2003 R McFadyen1 Contracts (Ch 13) Used to help understand requirements more completely based on assertions; assertions are applicable to any element of the UML text discusses contracts for system operations; contracts are applicable to execution of any software component

2. 91.3913Feb 2003 R McFadyen2 Domain Model Use Case Model text diagram SSD System operation contracts Design Model Figure 13.3 Relationship between Contracts and other artifacts

3. 91.3913Feb 2003 R McFadyen3 Contracts A contract is a technique for describing system operations in terms of state changes to objects in a Domain Model Major proponent - Bertrand Meyer Based on concept of assertion a statement, a constraint or declaration, that must be true a false value indicates a bug may be expressed informally, or in the UML we can (optionally) use the Object Constraint Language (OCL; 1999) to specify constraints rigorously

4. 91.3913Feb 2003 R McFadyen4 Constraints Three types pre-condition: must be true before a part of the system executes post-condition: must be true after a part of the system executes invariant: must be true before and after any part of the system is executed. Constraints can be enclosed in braces and placed in a note on a diagram appear as guards on a diagram kept in a separate file managed by a CASE tool

5. 91.3913Feb 2003 R McFadyen5 Constraints e.g. Suppose each instance of a Student class has an ageFirstEntry attribute and the age must always be 16 or more. –OCL context Student inv: ageFirstEntry >=16 informal precise Student ageFirstEntry {ageFirstEntry >=16}

6. 91.3913Feb 2003 R McFadyen6 Consider the execution of a routine: The called routine provides a service - it is the supplier The caller is the client requesting the service. A contract will spells out precisely the obligations of the caller (client) and the callee (supplier). The contract serves as an interface specification for the routine. Example: consider a routine that merges two sorted sequences. The merge routine is the supplier of the service; the calling routine is the caller. A contract will spell out the responsibilities of each party. Contracts

7. 91.3913Feb 2003 R McFadyen7 Responsibilities: Client: Ensure that the both sequences to be merged are each already sorted Supplier: Efficiently merge the two sorted sequences into one sorted sequence Contracts

8. 91.3913Feb 2003 R McFadyen8 Software contract: The responsibilities of the client will be called pre- conditions The responsibilities of the supplier will be called post- conditions Pre-condition: both sequences to be merged are each already sorted Post-condition: the two sorted sequences are merged into one sorted sequence Contracts

9. 91.3913Feb 2003 R McFadyen9 During analysis developers must first understand the problem domain and identify domain objects, their relationships with other domain objects, and their constraints. If a contract is defined in terms of domain objects the constraints can be clear and explicit, easily understood Everyone understands the business contracting metaphor. Business rules (constraints) can become an integral part of the software from the very beginning. Example: consider a withdraw method for an ACCOUNT class:withdraw (amount_to_withdraw: MONEY) Contracts

10. 91.3913Feb 2003 R McFadyen10 Example: consider a withdraw method for an ACCOUNT class: withdraw (amount_to_withdraw: MONEY) Pre-conditions: positive_amount: amount_to_withdraw > 0 sufficient_balance: balance >= amount_to_withdraw Post-conditions: correct_balance: balance = initial balance - amount_to_withdraw Contracts

11. 91.3913Feb 2003 R McFadyen11 Contracts Contract Components (Larman) Operation - name and parameters Cross References - where operation used Preconditions - assumptions about the state of the system or Domain Model objects Postconditions - state of objects after the operation completes objects:any new ones? any attributes modified? associations: any new or modified associations? Larman’s version is very informal

12. 91.3913Feb 2003 R McFadyen12 SSD for a samplePOS Use Case Figure 13.1 Input Events invoke a system operation of the same name same idea as in object-oriented programming when we say a message foo invokes the method foo Referred to as the enterItem system operation

13. 91.3913Feb 2003 R McFadyen13 SalesLineItem quantity Product Specification itemID Sale 1 1..* * 1Described by Contained in The part of the Domain Model relevant to enterItem( )

14. 91.3913Feb 2003 R McFadyen14 Contracts Example Operation:enterItem (itemID : ItemID, quantity : integer) Preconditions there is a Sale underway Postconditions a SalesLineItem instance was created an association between the sale and the sales line item was created an attribute, quantity, was modified an association between the product specification and the sales line item was created

15. 91.3913Feb 2003 R McFadyen15 Design By Contract (DBC) provides the basis for documenting software interfaces Reusers of a software component need to understand what the software provides them and what they must do to obtain these benefits. This is the contract. DBC is perhaps a best non-practice. Example of a new DBC tool: iContract: Design by Contract in Java allows one to include runtime assertions for development purposes and suppress them for production http://www.javaworld.com/javaworld/jw-02-2001/jw- 0216-cooltools.html