11.9. Example: NextGen POS Contracts
System Operations of the Process Sale Use Case
Operation: | makeNewSale() |
Cross References: | Use Cases: Process Sale |
Preconditions: | none |
Postconditions: |
|
Operation: | enterItem(itemID: ItemID, quantity: integer) |
Cross References: | Use Cases: Process Sale |
Preconditions: | There is a sale underway. |
Postconditions: |
|
Operation: | endSale() |
Cross References: | Use Cases: Process Sale |
Preconditions: | There is a sale underway. |
Postconditions: |
|
Operation: | makePayment( amount: Money ) |
Cross References: | Use Cases: Process Sale |
Preconditions: | There is a sale underway. |
Postconditions: |
|
Changes to the POS Domain Model
There is at least one point suggested by these contracts that is not yet represented in the domain model: completion of item entry to the sale. The endSale specification modifies it, and it is probably a good idea later during design work for the makePayment operation to test it, to disallow payments until a sale is complete (meaning, no more items to add).One way to represent this information is with an isComplete attribute in the Sale :There are alternatives, especially considered during design work. One technique is called the State pattern . Another is the use of "session" objects that track the state of a session and disallow out-of-order operations; this will be explored later.