TK2023 Object-Oriented Software Engineering CHAPTER 7 OPERATION CONTRACTS
INTRODUCTION <ul><li>Use cases are the primary mechanism to describe system behaviour. </li></ul><ul><li>Sometimes, a more...
CONTRACTS <ul><li>Contracts  describe detailed system behaviour in terms of state changes to objects in the domain model, ...
: System : Cashier enterItem(itemID, qty) the system event enterItem  is generated the system operation enterItem  is invo...
<ul><li>The entire set of system operations, across all use cases, defines the public system interface; the system is view...
CONTRACT SECTIONS <ul><li>A contract contains the following sections: </li></ul><ul><ul><li>Operation : Name of operation,...
EXAMPLE OF A CONTRACT: enterItem Operation:  enterItem(itemID:ItemID, qty:Integer) Cross References: Use Cases: Process Sa...
POSTCONDITIONS <ul><li>The postconditions describe changes in the state of objects in the domain model.  Domain model stat...
<ul><li>Remember that the postconditions are written in the context of the domain model objects. </li></ul><ul><li>Are pos...
<ul><li>For example, consider the postcondition </li></ul><ul><ul><ul><li>The  SalesLineItem  ( sli ) was associated with ...
AN ANALOGY BEFORE OPERATION A B C D E F
DURING OPERATION
A B C D E F AFTER OPERATION
AN EXAMPLE BEFORE OPERATION enterItem(1234, 3)
DURING OPERATION enterItem(1234, 3)
AFTER OPERATION enterItem(1234, 3) 1. Instance creation 2. Associations formed 3. Attribute change
GUIDELINES FOR WRITING CONTRACTS <ul><li>To write contracts: </li></ul><ul><ul><li>1. Identify system operations from the ...
<ul><li>State the postconditions in a declarative, passive past tense form.  This will emphasize the postconditions as dec...
<ul><li>Remember to establish a memory between existing objects or those newly created by defining the forming of an assoc...
A NOTE OF CAUTION! <ul><li>It may not be necessary to write complete and detailed set of postconditions for  all  system o...
UPDATING THE DOMAIN MODEL <ul><li>It's quite common to discover new conceptual classes, attributes or associations in the ...
POS SYSTEM: SYSTEM OPERATIONS OF  PROCESS SALE Operation:  makeNewSale() Cross References: Use Cases: Process Sale Precond...
Operation:  enterItem(itemID:ItemID, qty:Integer) Cross References: Use Cases: Process Sale Preconditions: There is a sale...
Operation:  endSale() Cross References: Use Cases: Process Sale Preconditions: There is a sale underway Postconditions: - ...
Operation:  makePayment(amt:Money) Cross References: Use Cases: Process Sale Preconditions: There is a sale underway Postc...
Upcoming SlideShare
Loading in …5
×

07 Contracts

1,058 views
850 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,058
On SlideShare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
39
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

07 Contracts

  1. 1. TK2023 Object-Oriented Software Engineering CHAPTER 7 OPERATION CONTRACTS
  2. 2. INTRODUCTION <ul><li>Use cases are the primary mechanism to describe system behaviour. </li></ul><ul><li>Sometimes, a more detailed description of system behaviour can be useful. </li></ul>
  3. 3. CONTRACTS <ul><li>Contracts describe detailed system behaviour in terms of state changes to objects in the domain model, after a system operation has executed. </li></ul><ul><li>System operations are operations that are invoked in response to incoming system events. </li></ul>
  4. 4. : System : Cashier enterItem(itemID, qty) the system event enterItem is generated the system operation enterItem is invoked enterItem(itemID, qty)
  5. 5. <ul><li>The entire set of system operations, across all use cases, defines the public system interface; the system is viewed as a single class. </li></ul>System makeNewSale() enterItem(itemID, qty) endSale() makePayment(amt) …
  6. 6. CONTRACT SECTIONS <ul><li>A contract contains the following sections: </li></ul><ul><ul><li>Operation : Name of operation, and its parameters, if any. </li></ul></ul><ul><ul><li>Cross References : (optional) Use cases within which this operation can occur. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>Postconditions : The state of objects in the domain model after completion of the operation. </li></ul></ul>
  7. 7. EXAMPLE OF A CONTRACT: enterItem 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
  8. 8. POSTCONDITIONS <ul><li>The postconditions describe changes in the state of objects in the domain model. Domain model state changes include: </li></ul><ul><ul><li>instances created or deleted </li></ul></ul><ul><ul><li>associations formed or broken </li></ul></ul><ul><ul><li>attributes changed </li></ul></ul><ul><li>Postconditions are not actions to be performed during the operation . </li></ul>
  9. 9. <ul><li>Remember that the postconditions are written in the context of the domain model objects. </li></ul><ul><li>Are postconditions necessary? </li></ul><ul><ul><li>Most often, the effect of a system operation is relatively clear (from the use case, talking with the domain experts, etc). </li></ul></ul><ul><ul><li>Sometimes , the detail and precision in contracts can become useful during design. </li></ul></ul><ul><li>Note that postconditions specify the changes a system operation needs to achieve without describing how they are to be achieved . </li></ul>
  10. 10. <ul><li>For example, consider the postcondition </li></ul><ul><ul><ul><li>The SalesLineItem ( sli ) was associated with the current Sale </li></ul></ul></ul><ul><ul><li>But how will this be achieved? </li></ul></ul><ul><ul><ul><ul><li>linking Java objects? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>inserting rows in a relational database? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>… </li></ul></ul></ul></ul><ul><li>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. </li></ul>
  11. 11. AN ANALOGY BEFORE OPERATION A B C D E F
  12. 12. DURING OPERATION
  13. 13. A B C D E F AFTER OPERATION
  14. 14. AN EXAMPLE BEFORE OPERATION enterItem(1234, 3)
  15. 15. DURING OPERATION enterItem(1234, 3)
  16. 16. AFTER OPERATION enterItem(1234, 3) 1. Instance creation 2. Associations formed 3. Attribute change
  17. 17. GUIDELINES FOR WRITING CONTRACTS <ul><li>To write contracts: </li></ul><ul><ul><li>1. Identify system operations from the SSDs </li></ul></ul><ul><ul><li>2. Write contracts for system operations that are complex and perhaps subtle in their results, or which are not clear in the use case. </li></ul></ul><ul><ul><li>3. Describe postconditions using the following categories: </li></ul></ul><ul><ul><ul><li>a. Instance creation or deletion </li></ul></ul></ul><ul><ul><ul><li>b. Attribute modification </li></ul></ul></ul><ul><ul><ul><li>c. Associations formed or broken </li></ul></ul></ul>
  18. 18. <ul><li>State the postconditions in a declarative, passive past tense form. This will emphasize the postconditions as declarations of state changes. </li></ul><ul><ul><li>A SalesLineItem was created </li></ul></ul><ul><ul><li>Create a SalesLineItem </li></ul></ul>
  19. 19. <ul><li>Remember to establish a memory between existing objects or those newly created by defining the forming of an association. </li></ul><ul><ul><li>Example (enterItem): </li></ul></ul><ul><ul><ul><li>- A SalesLineItem ( sli ) was created </li></ul></ul></ul><ul><ul><ul><li>- sli was associated with the current Sale </li></ul></ul></ul><ul><li>Forgetting to include the forming of associations is the most common mistake made when writing contracts. </li></ul>
  20. 20. A NOTE OF CAUTION! <ul><li>It may not be necessary to write complete and detailed set of postconditions for all system operations. </li></ul><ul><li>Treat contracts as an initial best guess; most likely, they are not complete and perfect specifications. </li></ul>
  21. 21. UPDATING THE DOMAIN MODEL <ul><li>It's quite common to discover new conceptual classes, attributes or associations in the domain model while writing contracts. </li></ul><ul><li>So, do not be limited to the prior definition of the domain model; enhance it as you make new discoveries. </li></ul>
  22. 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. 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. 24. Operation: endSale() Cross References: Use Cases: Process Sale Preconditions: There is a sale underway Postconditions: - Sale.isComplete was set to true.
  25. 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)

×