1. 91.3913September 2002 R McFadyen1 Domain Model Use Case Model text diagram SSD System operation contracts Design Model Figure 13.3

2. 91.3913September 2002 R McFadyen2 Contracts 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 declaration, that must be true a false value indicates a bug UML has OCL - very formal syntax which we will ignore

3. 91.3913September 2002 R McFadyen3 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

4. 91.3913September 2002 R McFadyen4 Responsibilities: Client: Ensure that the both of the sequences to be merged are each already sorted Supplier Efficiently merge the two sorted sequences into one sorted sequence Software contract: The responsibilities of the client will be called pre- conditions The responsibilities of the supplier will be called post-conditions

5. 91.3913September 2002 R McFadyen5 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)

6. 91.3913September 2002 R McFadyen6 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 = old balance - amount_to_withdraw end

7. 91.3913September 2002 R McFadyen7 Contracts Contract Components (Ch 13) 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

8. 91.3913September 2002 R McFadyen8 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

9. 91.3913September 2002 R McFadyen9 SalesLineItem quantity Product Specification itemID Sale 1 1..* * 1Described by Contained in The part of the Domain Model relevant to enterItem( )

10. 91.3913September 2002 R McFadyen10 Contracts Example Operation enterItem (itemID : ItemID, quantity : integer) Cross References Use Case Process Sale PreconditionsThere 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

11. 91.3913September 2002 R McFadyen11 OCL Object Constraint Language UML has a formal language for specifying constraints on object-oriented models context Salesperson:: sell ( item: Thing ) : Real pre: self.sellableItems -> includes (item) post: not self.sellableItems -> includes (item) and result=item.price

12. 91.3913September 2002 R McFadyen12 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 contracting tool: iContract: Design by Contract in Java http://www.javaworld.com/javaworld/jw-02-2001/jw- 0216-cooltools.html