OperationContracts

OperationContracts

Objectives ·       Define system operations. ·       Create contracts for system operations.

What are the Sections of a Contract?

       A description of each section in a contract is shown in the following schema.

Operation:	Name of 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 told.
Postconditions:	This is the most important section. The state of objects in the Domain Model after completion of the operation. Discussed in detail in a following section.

What is a System Operation?

       Operation contracts may be defined for system operations that the system as a black box component offers in its public interface. System operations can be identified while sketching SSDs. To be more precise, the SSDs show system events or I/O messages relative to thesystem. Input system events imply the system has system operations to handlethe events, just as an OO message (a kind of event or signal) is handled by anOO method (a kind of operation).

Figure11.2. SSD. System operations handle input system events.

       The entire set of system operations,across all use cases, defines the public systeminterface, viewing the system as a single component or class. In theUML, the system as a whole can be represented as one object of a class named(for example) System.

Postconditions

       The postconditions describe changes in the state of objects in the domain model. Domain model state changesinclude instances created, associations formed or broken, and attributeschanged.

       Postconditions are not actions to beperformed during the operation; rather, they are observationsabout the domain model objects that are true when the operation has finished after the smoke has cleared.

To summarize, the postconditions fall into these categories:

• Instance creation and deletion.
• Attribute change of value.
• Associations (to be precise, UML links) formed and broken.

 

How are Postconditions Related to the Domain Model?

       These postconditions are expressed in the context of the Domain Model objects. What instances can be created? Those fromthe Domain Model; What associations can be formed? Those in the Domain Model;and so on.

Why Postconditions?

       First, they aren't always necessary. Mostoften, the effect of a system operation is relatively clear to the developersby virtue of reading the use case, talking with experts, or their ownknowledge. But sometimes more detail and precision is useful. Contracts offerthat.

       Notice that the postconditions supportfine-grained detail and precision in declaring what the outcome of the operation must be. It is also possible to express this level of detail in theuse cases, but undesirable they would be too verbose and low-level detailed.

       A contract is an excellent tool of requirements analysis or OOA that describes in great detail the changes required by a system operation (in terms of the domain model objects) withouthaving to describe how they are to be achieved.

       In other words, the design can be deferred, and we can focus on the analysis of what must happen, rather than how it is to be accomplished.

How to Write a Postcondition?

       Express postconditions in the past tense to emphasize they are observations about statechanges that arose from an operation, not an action to happen. That's why they are called postconditions! For example:

·        (better)A SalesLineItem wascreated.

              rather than

·        (worse)Create a SalesLineItem, or, A SalesLineItem is created.

Should We Update the Domain Model?

       It's common during the creation of the contracts to discover the need to record new conceptual classes, attributes, orassociations in the domain model. Do not be limited to the prior definition ofthe domain model; enhance it as you make new discoveries while thinking throughoperation contracts.

       In iterative and evolutionary methods(and reflecting the reality of software projects), all analysis and designartifacts are considered partial and imperfect, and evolve in response to newdiscoveries.

When Are Contracts Useful?

       In the UP, the use cases are the mainrepository of requirements for the project. They may provide most or all of the detail necessary to know what to do in the design, in which case, contracts are not helpful. However, there are situations where the details and complexity of required state changes are awkward or too detailed to capture in use cases.

       For example, consider an airline reservation system and the system operation addNewReservation.The complexity is very high regarding all the domain objects that must bechanged, created, and associated. These fine-grained details can be written up in the use case, but it will make itextremely detailed (for example, noting each attribute in all the objects thatmust change).

       Observe that the postcondition formatoffers and encourages a very precise, analytical language that supports detailed thoroughness.

       If developers can comfortably understandwhat to do without them, then avoid writing contracts.

How to Create and Write Contracts?

Apply thefollowing advice to create contracts:

1.     Identifysystem operations from the SSDs.

2.     Forsystem operations that are complex and perhaps subtle in their results, orwhich are not clear in the use case, construct a contract.

3.     Todescribe the postconditions, use the following categories:

o    instance creation anddeletion

o    attribute modification

o    associations formedand broken

What's the Most Common Mistake?

       The most common problem isforgetting to include the forming of associations. Particularly when new instances are created, it is very likely that associations to several objects need be established. Don't forget!

OperationContracts Within the UP

       Apre- and postcondition contract is a well-known style to specify an operationin the UML. In the UML, operations exists at many levels, from System down to fine-grained classes, such as Sale. Operation contracts for the System level are part of the Use-Case Model, although they were not formally highlighted in the original RUP or UP documentation;their inclusion in this model was verified with the RUP authors.

Phases

       Inception

       Contracts are not motivated duringinception they are too detailed.

       Elaboration

       If used at all, most contracts will bewritten during elaboration, when most use cases are written. Only write contracts for the most complex and subtle system operations.

 

System Operations of the Process SaleUse Case

Contract CO1:makeNewSale

Operation:	makeNewSale()
Cross References:	Use Cases: Process Sale
Preconditions:	none
Postconditions:	- A Sale instance s was created (instance creation). - s was associated with a Register (association formed). - Attributes of s were initialized.

Contract CO2:enterItem

Operation:	enterItem(itemID: ItemID, quantity: integer)
Cross References:	Use Cases: Process Sale
Preconditions:	There is a sale underway.
Postconditions:	- A SalesLineItem instance sli was created (instance creation). - sli was associated with the current Sale (association formed). - sli.quantity became quantity (attribute modification). - sli was associated with a ProductDescription, based on itemID match (association formed).

Contract CO3:endSale

Operation:	endSale()
Cross References:	Use Cases: Process Sale
Preconditions:	There is a sale underway.
Postconditions:	- Sale.isComplete became true (attribute modification).

Contract CO4:makePayment

Operation:	makePayment( amount: Money )
Cross References:	Use Cases: Process Sale
Preconditions:	There is a sale underway.
Postconditions:	- A Payment instance p was created (instance creation). - p.amountTendered became amount (attribute modification). - p was associated with the current Sale (association formed). - The current Sale was associated with the Store (association formed); (to add it to the historical log of completed sales)

 

 

NextGenPOS partial domain model