Contracts (Ch 13)

1. 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 Feb 2003 R McFadyen

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

3. 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 Feb 2003 R McFadyen

4. 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 Feb 2003 R McFadyen

5. 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 >=16} ageFirstEntry Feb 2003 R McFadyen

6. Contracts • Consider the execution of a routine: • The called routine provides a service - it is thesupplier • 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. Feb 2003 R McFadyen

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

8. Contracts • 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 eachalready sorted Post-condition: the two sorted sequences are merged into one sorted sequence Feb 2003 R McFadyen

9. Contracts • 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) Feb 2003 R McFadyen

10. Contracts • 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 Feb 2003 R McFadyen

11. 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 Feb 2003 R McFadyen

12. 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 Feb 2003 R McFadyen

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

14. 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 Feb 2003 R McFadyen

15. 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 perhapsa 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 Feb 2003 R McFadyen