Operation contracts are formal constraints defined over software operations. These are created during the domain-modeling phase. Typically, an operation contract consists of 4 components:
* Operation name: A name for the operation
* Cross-References: List of use-cases that refer this operation
* Preconditions: State of variables/system before this operation is invoked
* Postconditions: State of variables/system after successful completion of the operation Typically, the Postconditions can be of 3 kinds: Name: appropriateName Responsibilities: Perform a function Exceptions: none
| Attributes | Values |
|---|
| rdfs:label
| |
| rdfs:comment
| - Operation contracts are formal constraints defined over software operations. These are created during the domain-modeling phase. Typically, an operation contract consists of 4 components:
* Operation name: A name for the operation
* Cross-References: List of use-cases that refer this operation
* Preconditions: State of variables/system before this operation is invoked
* Postconditions: State of variables/system after successful completion of the operation Typically, the Postconditions can be of 3 kinds: Name: appropriateName Responsibilities: Perform a function Exceptions: none
|
| dcterms:subject
| |
| wikify
| |
| dbkwik:speedydelet...iPageUsesTemplate
| |
| notability
| |
| unreferenced
| |
| orphan
| |
| concern
| - Notability and sources issues tagged since 2007.
|
| Timestamp
| - 20120707014252(xsd:double)
|
| abstract
| - Operation contracts are formal constraints defined over software operations. These are created during the domain-modeling phase. Typically, an operation contract consists of 4 components:
* Operation name: A name for the operation
* Cross-References: List of use-cases that refer this operation
* Preconditions: State of variables/system before this operation is invoked
* Postconditions: State of variables/system after successful completion of the operation Typically, the Postconditions can be of 3 kinds:
* Instance creation
* Attribute modification
* Associations broken/added A UML Operation contract identifies system state changes when an operation happens. Effectively, it will define what each system operation does. An operation is taken from a system sequence diagram. It is a single event from that diagram. A domain model can be used to help generate an operation contract. The domain model can be marked as follows to help with the operation contract: Green - Pre existing concepts and associations. Blue - Created associations and concepts. Red - Destroyed concepts and associations. Operation Contract Syntax Name: appropriateName Responsibilities: Perform a function Cross References: System functions and Use Cases Exceptions: none Preconditions: Something or some relationship exists Postconditions: An association was formed When making an operation contract, think of the state of the system before the action (snapshot) and the state of the system after the action (a second snapshot). The conditions both before and after the action should be described in the operation contract. Do not describe how the action or state changes were done. The pre and post conditions describe state, not actions. Typical postcondion changes: Object attributes were changed. An instance of an object was created. An association was formed or broken. Postconditions are described in the past tense. They declare state changes to the system. Fill in the name, then responsibilities, then postconditions.
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)