1. Used to help understand requirements more completely
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
Jan Ron McFadyen

2. Domain Model Use Case Model Design Model Figure 13.3 text diagram SSD
System operation contracts
Design Model
Figure 13.3
Relationship between Contracts and other artifacts
Jan Ron McFadyen

3. Based on concept of assertion
Contracts
A contract is a technique for describing system operations in terms of state changes to objects in a Domain Model
Contracts in Chapter 13, are based on work by Bertrand Meyer … Eiffel programming language
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
Jan Ron McFadyen

4. pre-condition: must be true before a part of the system executes
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
Jan Ron McFadyen

5. {ageFirstEntry >=16}
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
Jan Ron McFadyen

6. Consider the execution of a routine:
Contracts
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.
Jan Ron McFadyen

7. Contracts 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
Jan Ron McFadyen

8. The responsibilities of the client will be called pre-conditions
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 each already sorted
Post-condition: the two sorted sequences are merged into one sorted sequence
Jan Ron McFadyen

9. Everyone understands the business contracting metaphor.
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)
Jan Ron McFadyen

10. Example: consider a withdraw method for an ACCOUNT class:
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
Jan Ron McFadyen

11. Contract Components (Larman) Operation - name and parameters
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
Jan Ron 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
Jan Ron McFadyen

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

14. Operation: enterItem (itemID : ItemID, quantity : integer)
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
Jan Ron McFadyen

15. DBC is perhaps a best non-practice. Example of a new DBC tool:
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
Jan Ron McFadyen