Your SlideShare is downloading. ×
  • Like
07 Contracts
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

07 Contracts

  • 671 views
Published

 

Published in Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
671
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
35
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. : System : Cashier enterItem(itemID, qty) the system event enterItem is generated the system operation enterItem is invoked enterItem(itemID, qty)
  • 5.
    • The entire set of system operations, across all use cases, defines the public system interface; the system is viewed as a single class.
    System makeNewSale() enterItem(itemID, qty) endSale() makePayment(amt) …
  • 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 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. 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. AN ANALOGY BEFORE OPERATION A B C D E F
  • 12. DURING OPERATION
  • 13. A B C D E F AFTER OPERATION
  • 14. AN EXAMPLE BEFORE OPERATION enterItem(1234, 3)
  • 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)