Chapter 11 32 operation contracts amp System Sequence diagrams 1 What will we learn Operation Contracts how to define the system operations and how to create contracts for them Define SSDs and Operation Contracts for the example case studies ID: 352922
Download Presentation The PPT/PDF document "Object-Oriented Analysis and Design" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Object-Oriented Analysis and Design
Chapter 11, 32: operation contracts & System Sequence diagrams
1Slide2
What will we learn?
Operation Contracts – how to define the system operations, and how to create contracts for them
Define SSDs and Operation Contracts for the example case studies
2Slide3
Operation Contracts
Often, the use cases and SSDs are enough to describe the systemSometimes, more detail of the system behavior is required, and that is where Operation Contracts are used
The Use-Case Model and Domain Model are the main OOA artifacts, but Operation Contracts and State Models are also helpful
Remember the SSDs are part of the Use-Case Model artifact
Actually, the Operation Contracts are considered part of the Use-Case Model, since they usually expand upon the SSD
3Slide4
4Slide5
Operation Contracts
Operation Contracts describe pre- and post-condition changes to the objects in the
Domain Model
as a result of a system operation. They are text based documentation.
Before looking at them in detail, let’s consider an example (terms like (
instance creation
) are added for explanation in this example, and would not be part of the actual contract)
:Contract CO2:
enterItem
Operation:
enterItem
(
itemID: itemID, quantity: integer)Cross Reference: Use Cases: Process SalesPreconditions: There is a sale underwayPostconditions: -A SalesLineItem instance sli was created (instance creation) -sli was associated ith the current Sale (association formed) -sli.quantity became quantity (attribute modification) -sli was associated with a ProductDescription, based on itemID match (association formed)
5Slide6
Operations Contracts - Sections
The sections of an Operations Contract are:Operation: Name of the operation, and parameters
Cross References:
Use cases this operation can occur within
Preconditions:
Noteworthy assumptions about the state of the system or objects in
the Domain Model before execution of the operation. These are
non-trivial assumptions the reader should be aware of.
Postconditions
:
The most important section. The state of objects in the Domain
Model after the completion of the operation.
6Slide7
System Operations
System operations can be thought of as operations the system (as a black-box) offers to its usersThey are identified when the SSDs are created
The SSDs show
system events
which usually trigger system operations
Some of the system events are
input events
(see next slide)
The entire set of system operations, across all use cases, defines a
public interface
which views the system as one single component or class.
7Slide8
8Slide9
Operation Contracts: Postconditions
The
postcondition
describes changes in the state of objects in the
Domain Model
. Such changes include instance creation, associations formed or broken, and attributes changed.
Note that
postconditions are
not
actions to be performed during the operation!
Postconditions
describe
the changes to the object, they do not explain how the changes are doneBreaking an association is rare, but can happen (cancel sale, for example)Instance deletion is also rare; remember, we are still in the Domain Model, not the actual software classes, so freeing up memory is not an issue9Slide10
Operation Contracts: Postconditions
The instances and associations that are created by an Operation Contract appear in the Domain Model – the contract should capture the behavior expressed in the Use Case Model as it relates to the objects and associations in the Domain Model
Note that
postconditions
(and in fact Operation Contracts) are optional – not every operation needs a contract, and often the
postconditions
are obvious and do not need to be documented
This is another tool to help understand the system behavior
Again, this is an
analysis
tool – it will help define
what
changes, not
how it changesUsually postconditions are written in the past tense – A SalesLineItem was created, not is created10Slide11
Example: enterItem
Postconditions
Look at the types of changes identified in the
enterItem
postcondition
First, recall the Main Scenario of the Process Sale use case (
pg 69 of the book):
Main Success Scenario:
…
3. Cashier enters item identifier
4. System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules.
…
Also, recall the Domain Model and SSD for this example (next slides):11Slide12
12Slide13
13Slide14
14Slide15
Operation Contracts
Contract CO2: enterItem
Operation:
enterItem
(
itemID
: itemID, quantity: integer)
Cross Reference:
Use Cases: Process Sales
Preconditions:
There is a sale underway
Postconditions
: -A SalesLineItem instance sli was created (instance creation) -sli was associated ith the current Sale (association formed) -sli.quantity became quantity (attribute modification) -sli was associated with a ProductDescription, based on itemID match (association formed)15Slide16
enterItem
Postcondition: Putting it Together
Instance Creation and Deletion:
After
itemID
and
quantity have been entered by the Cashier, the
SalesLineItem
object is created
This can be determined by the use case and Domain Model (composition of
Sales
)
Hence the postcondition: “A SalesLineItem instance sli was created”Attribute Modification:From the Domain Model, we see that the quantity attribute of the SalesLineItem is derived, or calculated. This value is entered by the Cashier (not mentioned in the use case, but shown in the SSD).This gives the postcondition: “sli.quantity became quantity”16Slide17
enterItem
Postcondition: Putting it Together
Associations Formed or Broken:
After
itemID
and
quantity are entered by the Cashier, and after we create the new
SalesLineItem
object, we must form an association with the
ProductDescription
object, as noted in the Domain Model. The new
SalesLineItem
is also associated with the Sale object. This gives the following postconditions:“sli was associated with the current Sale.”“sli was associated with a ProductDescription, based upon itemID match”Note that the original Domain Model did not show the SalesLineItem to ProductDescription association as being qualified by itemID, but this does not mean we can’t include text in the postcondition that describes how sli is associated with ProductDescription.17Slide18
Review
How to analyze a system:Use cases: Identify the main actors, and create the stories of how they interact. Add in details for each scenario
Domain Model: Identify the main conceptual classes (look for
nouns
in the use cases) and how they are associated with each other (look for
verbs
in the use cases)
System Sequence Diagrams: Create diagrams that show the system events that occur between the system (as one big black box) and the users
Operations Contracts – detail any system operations that occur to impart changes to the system objects as a result of the system events – relies on Domain Model, use cases, and SSDs
The use cases (text) and possible use case diagram, SSDs, and Operations Contracts make up the Use-Case Model artifact in UP
The Domain Model is a separate artifact, sometimes included in the Business Modeling artifact
18Slide19
How to Create Operations Contracts
Identify the system operations from the SSDs
For complex system operations, or operations that may be subtle or not clearly understood, construct a contract
To describe the
postconditions
, use the following categories:
Instance creation or deletion
Attribute modification
Associations formed or broken
Tip: Always use past tense, and if an instance is created, make sure you add an association for the new instance.
19Slide20
20
Back to the Process Sale use case SSD:Slide21
NextGen POS Operation Contracts
Contract CO1: makeNewSale
Operation:
makeNewSale
()
Cross References:
Uses cases: Process Sale
Preconditions: none
Postconditions
:
- A Sale instance
s
was created
- s was associated with a Register - Attributes of s were initializedNote that for this case, the contract is obvious and probably would not actually be written. Remember, these are system description tools, and we are not trying to document every change in the system; we just need to explain any operations that may not be obvious.21Slide22
NextGen POS Operation Contracts
Contract CO2: enterItem
Operation:
enterItem
(
itemID
: itemID, quantity: integer)
Cross Reference:
Use Cases: Process Sales
Preconditions:
There is a sale underway
Postconditions
: -A SalesLineItem instance sli was created -sli was associated with the current Sale s -sli.quantity became quantity -sli was associated with a ProductDescription, based on itemID matchWe saw this example earlier; this is more detailed and not as obvious as CO1, so it is reasonable to include this.22Slide23
NextGen POS Operation Contracts
Contract CO3:
endSale
Operation:
endSale
()
Cross Reference: Use Cases: Process SalesPreconditions:
There is a sale underway
Postconditions
:
-
s.isComplete became trueNote that according to the Domain Model, the Sale object does not have an isComplete attribute, but this is a suggested addition that occurred when we created the Operation Contract for endSale. We can then go back and modify the Domain Model to include this new attribute – an example of iterative development. 23Slide24
NextGen POS Operation Contracts
Contract CO4:
makePayment
Operation:
makePayment
(amount: Money)
Cross Reference: Use Cases: Process Sales
Preconditions:
There is a sale underway
Postconditions
:
-
A Payment instance p was created - p.amountTendered became amount - p was associated with the current Sale s - The current Sale s was associated with the StoreNote the last association that was formed creates the association “logs-completed” between Sale and Store in the Domain Diagram.24Slide25
NextGen POS: Expanding the SSDs
We now want to expand the basic Process Sales SSD we created earlier to include an expanded payment option
This would occur, for example, in a further iteration in the Elaboration phase
Recall the first iteration only included cash payments; then we enhanced the Domain Model to include credit and check, and added subclasses to the Domain Model to reflect this
We will enhance the existing SSD to include these new details, and also add Operation Contracts to explain them
Note that in this next iteration, the
makePayment
operation that we previously defined
would
be renamed “
makeCashPayment
”
First, let’s recall the expanded Domain Model for these types of payments
25Slide26
26Slide27
27
The basic scenario we have been working with:Slide28
28
Adding pay by credit; note that the
Accounts
object (Accounts Receivable in the Domain Model) gets updated.Slide29
29
Adding pay by check:Slide30
NextGen POS Operation Contracts
Contract
CO5:
makeCreditPayment
Operation:
makeCreditPayment
(creditAccountNumber, expiryDate
)
Cross Reference:
Use Cases: Process Sales
Preconditions:
An underway sale exists and all items have been entered
Postconditions: - A CreditPayment pmt was created - pmt was associated with the current Sale s - a CreditCard cc was created, cc.number = creditAccountNumber, cc.expiryDate = expiryDate - cc was associated with pmt - a CreditCardPaymentRequest cpr
was created
-
pmt
was associated with
cpr
- a
ReceivableEntry
re
was created
-
re
was associated with the external Accounts Receivable
- The current sale
s
was associated with the Store as a completed sale
30Slide31
NextGen POS Operation Contracts
Contract CO6:
makeCheckPayment
Operation:
makeCheckPayment
(
driversLicenseNumber)Cross Reference:
Use Cases: Process Sales
Preconditions:
An underway sale exists and all items have been entered
Postconditions
:
- a CheckPayment pmt was created - pmt was associated with the current sale s - a DriverLicense dl was created; dl.number = driversLicenseNumber - dl was associated with pmt - a CheckPaymentRequest cpr was created - pmt was associated with cpr - current sale s was associated with the Store as a completed sale
31Slide32
Takeaways from Chapter 11, 32
Understand how to create Operations Contracts, based upon details from the use cases, SSDs, and Domain Models.
Know the three type of
postconditions
and how to write them
32