System Operation Contracts

Lecture 09
Course Instructor: Idrees Ahmad
Course Code: SE321
Fall 2020
System Operations
System Operations are the operations that handle
incoming system events.
Operations are invoked by System events.
message invokes the method (handling operation)
Operations are the the public interface of the system
Operations are named similar to System Events
System event makeNewSale operation:
makeNewSale( ).
Operations can be identified by discovering
system events from a Use-case or System
Sequence Diagram
System Operation Contracts
System Operation contracts or Operation
contracts or Contracts are written description of
what an operation commits to achieve.
Detailed system behavior in terms of state changes to
objects (Instances, Attributes and Associations) in the
Domain Model, after the system operation has
executed.
Contract are defined for each system operations.
Contracts can be used to express
High level operations (System level)
Low level method (Class level)
Contract: Format
Name Name of operation and parameters
Responsibility Description of responsibility this operation must
: fulfill.
Type: System/Class
Cross (Concept, Class, Interface)
Reference: System Function reference number, Use cases, ..
Notes: Design notes, algorithms, ……
Exceptions: Exceptional cases
Output: Non-UI outputs: message/record sent outside
Pre- Assumptions about the state of the system before
conditions: execution of operation
Post- State of the system after execution of operation
conditions:
Regardless of the format the essentials items in
an Operation Contract are
Name
Responsibility
Type
Pre-conditions
Post-conditions
 Records-sale-of

Described-by
1

Product
Focus here!!!! Product
Catalog Contains
Specification

1 description
1.. * price
1 UPC
0..1
* Used-by Describes
Sales * *
LineItem Store
Item
Stocks
quantity address 1
1
name
1
*
1.. *
Logs- 1
Contained-in Houses
completed
1  1.. *
Sale * POST
Manager
date Started-by
1 1
Captured-on
time 1 1
1
1 Initiated-by 1
Paid-by  Records-sales-on
1 1 1

Payment Customer Cashier

amount
Example:
Name: startUp ()
Responsibility: Initialize the system.
Type: System
Pre-conditions: None
Post-conditions:
Instances of Store, POST, ProductCatalog and
ProductSpecification were created (instance creation)
ProductCatalog was associated with ProductSpecification
(association formed).
Store was associated with ProductCatalog (association
formed).
Store was associated with POST (association formed)
Writing Contracts
How to write Sys Operation Contract
Identify the system operations from the system
sequence diagrams.
For each system operation, construct a contract.
Start by writing the Responsibilities section,
informally describing the purpose of the
operation.
Then complete the Post-conditions section,
declaratively describing the state changes that
occur to objects in the domain model.
Pre-conditions
Assumptions about the state of the system
before operation.
Things that are important to test in software at some
point during execution of the operation.

Things that will not be tested, the success of the

operation depends on them (e.g normal salary data).
Post-conditions
The post-conditions describe changes in the state of
objects in the domain model.
Post-conditions are the observations about the domain
model objects and must be true when the operation has
finished.
Post-conditions are not actions to be performed during the
operation
Post-conditions fall into three categories:
Instance creation and deletion.
Attribute modification.
Associations formed and broken.
Instance creation and deletion.
If a new sale, a Sale instance s was created
(instance creation).
A SalesLineItem sli was created (instance creation).

Attribute modification
SalesLineItem.Quantity was set to quantity
( attribute modification).
Associations formed and broken (to be precise,
UML links)
The SalesLineItem sli was associated with Sale
(association formed).
The SalesLineItem was associated with a Product
Specification, based on UPC match (association
formed).
On payment Sale s was de-associated from POST
(association broken)
Motivation: Why Postconditions?
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) without
having to describe how they are to be achieved.
The Spirit of Post-conditions
The Stage and Curtain
Take a picture of the stage.
Close the curtains on the stage
Open the curtains and take a second picture.
Compare the before and after picture
Compare the before and after picture
Express the post-conditions as the changes in the
state of the stage
A SalesLineItem was created …

NOTE:
A SalesLineItem was created (better: No actions
and past tense)
Create a SalesLineItem (worse)
Contracts: Use-case Process Sale
 Contracts: Use-case Process Sale

Operation:
makeNewSale()
makeNewSale
...
enterItem makeNewSale() Operation:
Use Case: (itemID, quantity) enterItem(itemID, quantity) enterItem
Process Sale endSale() endSale() ...
makePayment()
Operation:
makePayment() endSale
...
Operation:
makePayment
...
System
Sequence System
Use Case Diagram Operations Contracts
Partial Domain Model
Records-sale-of

Described-by
1

Product
Product Specification
Catalog Contains
Focus here!!!! 1 1.. * description
price
1 UPC
0..1
* Used-by Describes
Sales * *
LineItem Store
Item
Stocks
quantity address 1
1
name
1
*
1.. *
Logs- 1
Contained-in Houses
completed
1  1.. *
Sale * POST
Manager
date Started-by
1 1
Captured-on
time 1 1
1
1 Initiated-by 1
Paid-by  Records-sales-on
1 1 1

Payment Customer Cashier

amount
Contract 01: makeNewSale()
Pre-condition: None
PostCondition:
A Sale instance s was created (instance creation)
s was associated with POST (associated formed)
s.date and s.time were initialized (attribute
modification).
Contract 02: enterItem(itemId,quantity)
Pre-Conditions: There is a sale underway.
Post-Conditions:
A SalesLineItem sli was created (instance creation).
sli was associated with current Sale (associated
formed).
sli.quantity became quantity (attribute modification).
sli was associated with a ProductSpecification, based
on itemId match (association formed).
Contract 03: endSale
Pre-Condition: There is a sale underway
Post-Condition:
Sale.isComplete was set to true (attribute
modification)
Contracts 04: makePayement
Name: makePayment (amount: Number)
Responsibility: Record the payment, calculate balance
and print receipt.
Type: System
Pre-conditions: Sale s. isComplete is true
Post-conditions:
A Payment instance p was created (instance creation)
p.amount was set to amount (attribute modification)
p was associated with the current Sale s (association formed).
s was associated with the Store to be added to log of
completed sales (new relationship formed and old broken)
Updating Domain Model
Changes to be made in the Domain Model
endSale suggests isComplete attribute to be added
in the Sale

Sale

isComplete: Boolean
date
time
Thank you!!
Chapter 13 :)
Chapter 14-15 for next coming weeks