Date post: | 01-Jan-2016 |
Category: |
Documents |
Upload: | sylvester-curry |
View: | 21 times |
Download: | 1 times |
INTRODUCTION
Use cases are the primary mechanism to describe system behaviour.
Sometimes, a more detailed description of system behaviour can be useful.
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.
: Cashier
: System
enterItem(itemID, qty)
the system evententerItem is generated
the system operationenterItem is invoked
enterItem(itemID, qty)
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)…
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.
CONTRACT SECTIONS
A contract contains the following sections:
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
EXAMPLE OF A CONTRACT: enterItem
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.
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.
For example, consider the postconditionThe 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.
AN EXAMPLE BEFOREOPERATIONenterItem(1234, 3)
: Register : Sale
: ProductCatalog
: ProductSpecification
: SalesLineItem
linked to the corresponding ProductSpecification
AFTEROPERATIONenterItem(1234, 3)
: Register : Sale
: ProductCatalog
: ProductSpecification
: SalesLineItem
linked to the corresponding ProductSpecification
: SalesLineItem
qty = 3
linked to the ProductSpecification for itemID 1234
1. Instance creation2. Associations formed3. Attribute change
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
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
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.
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.
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.
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
POS SYSTEM: SYSTEM OPERATIONS OF PROCESS SALE
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
Operation: endSale()
Cross References: Use Cases: Process Sale
Preconditions:
There is a sale underway
Postconditions:
- Sale.isComplete was set to true.
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)