TK2023 Object-Oriented Software Engineering

1. TK2023 Object-Oriented Software Engineering CHAPTER 7 OPERATION CONTRACTS

2. INTRODUCTION • Use cases are the primary mechanism to describe system behaviour. • Sometimes, a more detailed description of system behaviour can be useful.

3. CONTRACTS • Contracts describe detailed system behaviour in terms of state changes to objects in the domain model, after a system operation has executed. • System operations are operations that are invoked in response to incoming system events.

4. enterItem(itemID, qty) enterItem(itemID, qty) : Cashier the system event enterItem is generated the system operation enterItem is invoked : System

5. System makeNewSale() enterItem(itemID, qty) endSale() makePayment(amt) … • The entire set of system operations, across all use cases, defines the public system interface; the system is viewed as a single class.

6. CONTRACT SECTIONS • A contract contains the following sections: Operation: Name of operation, and its parameters, if any. Cross References: (optional) Use cases within which this operation can occur. Preconditions: Noteworthy assumptions about the state of the system or objects in the domain model before execution of the operation. They are assumed to be true and will not be tested. Postconditions: The state of objects in the domain model after completion of the operation.

7. EXAMPLE OF A CONTRACT: enterItem Operation: enterItem(itemID:ItemID, qty:Integer) Cross References: Use Cases: Process Sale Preconditions: There is a sale currently going on Postconditions: - A SalesLineItem (sli) was created - sli was associated with the current Sale - sli.quantity was set to qty - sli was associated with a ProductSpecification, based on itemID match

8. POSTCONDITIONS • The postconditions describe changes in the state of objects in the domain model. Domain model state changes include: • instances created or deleted • associations formed or broken • attributes changed • Postconditions are not actions to be performed during the operation.

9. Remember that the postconditions are written in the context of the domain model objects. • Are postconditions necessary? • Most often, the effect of a system operation is relatively clear (from the use case, talking with the domain experts, etc). • Sometimes, the detail and precision in contracts can become useful during design. • Note that postconditions specify the changes a system operation needs to achieve without describing how they are to be achieved.

10. For example, consider the postcondition The SalesLineItem (sli) was associated with the current Sale But how will this be achieved? • linking Java objects? • inserting rows in a relational database? • … • In other words, the design can be deferred. We need to focus on the analysis of what must happen, rather how it is to be accomplished.

11. E F C D A B AN ANALOGY BEFORE OPERATION

12. DURING OPERATION

13. AFTER OPERATION A B C E D F

14. BEFORE OPERATION enterItem(1234, 3) AN EXAMPLE

15. DURING OPERATION enterItem(1234, 3)

16. AFTER OPERATION enterItem(1234, 3) 1. Instance creation 2. Associations formed 3. Attribute change

17. GUIDELINES FOR WRITING CONTRACTS • To write contracts: 1. Identify system operations from the SSDs 2. Write contracts for system operations that are complex and perhaps subtle in their results, or which are not clear in the use case. 3. Describe postconditions using the following categories: a. Instance creation or deletion b. Attribute modification c. Associations formed or broken

18. State the postconditions in a declarative, passive past tense form. This will emphasize the postconditions as declarations of state changes. • A SalesLineItem was created • Create a SalesLineItem

19. Remember to establish a memory between existing objects or those newly created by defining the forming of an association. Example (enterItem): - A SalesLineItem (sli) was created - sli was associated with the current Sale • Forgetting to include the forming of associations is the most common mistake made when writing contracts.

20. A NOTE OF CAUTION! • It may not be necessary to write complete and detailed set of postconditions for all system operations. • Treat contracts as an initial best guess; most likely, they are not complete and perfect specifications.

21. UPDATING THE DOMAIN MODEL • It's quite common to discover new conceptual classes, attributes or associations in the domain model while writing contracts. • So, do not be limited to the prior definition of the domain model; enhance it as you make new discoveries.

22. POS SYSTEM: SYSTEM OPERATIONS OF PROCESS SALE Operation: makeNewSale() Cross References: Use Cases: Process Sale Preconditions: none Postconditions: - A Sale (s) was created - s was associated with the Register - Attributes of s were initialized

23. Operation: enterItem(itemID:ItemID, qty:Integer) Cross References: Use Cases: Process Sale Preconditions: There is a sale underway Postconditions: - A SalesLineItem (sli) was created - sli was associated with the current Sale - sli.quantity was set to qty - sli was associated with a ProductSpecification, based on itemID match

24. Operation: endSale() Cross References: Use Cases: Process Sale Preconditions: There is a sale underway Postconditions: - Sale.isComplete was set to true.

25. Operation: makePayment(amt:Money) Cross References: Use Cases: Process Sale Preconditions: There is a sale underway Postconditions: - A Payment (p) was created - p.amountTendered was set to amt - p was associated with the current Sale - The current Sale was associated with the Store (to add it to the historical log of completed sales)