Download as pdf or txt
Download as pdf or txt
You are on page 1of 20

System Behavior:

System Operations and


Contracts
Iram Rubab
What is an (System) Operation Contracts?
• Operation contracts may be defined for system operations that the
system as a black box offers in its public interface.

• System operations can be identified while sketching SSDs.

• Use cases are primary mechanism to describe system behavior, and


are usually sufficient.

• However, sometimes a more detailed description of system behavior


has value.

• Contracts describe detailed system behavior in terms of state


changes to objects in the Domain Model, after a system operation has
executed. 2
What is a System Operation?

3
What is an (System) Operation Contracts?

• Detailed description of system behavior

• Contracts describe detailed system behavior in terms


of state changes to objects in the Domain Model, after
a system operation has executed.

4
Operations Contracts
1. SSDs identify actor events and system operations
but not system response (as behavior).

2. Contract describes what an operation commits to


achieve.

System contracts are written for


each system operation to
endSale() describe its behavior
enterItem()
makePayment()

 Contracts can be used to express high level operations (system level)


and low level method (class level).
5
Example Contract Format

Name: Name of operation and parameters


Responsibility: Description of responsibility this operation must fulfill.

Type: (Concept, Class, Interface)


Cross Reference: System Function reference number, Use cases, ..

Notes: Design notes, algorithms, …...


Exceptions: Exceptional cases
Output: Non-UI outputs: message/record sent outside
Pre-conditions: Assumptions about the state of the system before execution of operation
Post-conditions: state of the system after execution of operation

6
Example contract--enter item
7
Name: EnterItem (upc: number, quantity: integer)
Responsibility: Enter (record) sale of an item and add it to the sale.
Display the item description and price.

Type: System
Cross Reference:
System Functions R1.1, R1.3, R1.9
Use cases: Process Sale
Notes: Use superfast database access.
Exceptions: If UPC is invalid, indicate error
Output:
Pre-conditions:UPC is known to the system
Post-conditions:
• If a new sale, a Sale was created (instance creation).
• If a new sale, the new Sale was associated with the POST
(association formed).
• A salesLineItem was created (instance creation).
• SalesLineItem. was associated with the sale (association
formed).
• SalesLineItem.quantity was set to quantity (attribute
How to make a Contract
How to make a Contract
1. Identify the system operations from the system
sequence diagrams.
2. For each system operations, construct a contract.
3. Start by writing the Responsibilities section, informally
describing the purpose of the operation.
4. Then complete the Post-conditions section,
declaratively describing the state changes that occur
to objects in the domain model.

9
Pre-conditions
• Assumptions about the state of the system before
operation.
1. Things that are important to test in software at some point during
execution of the operation.

2. Things that will not be tested, but upon which the success of the
operation hinges (e.g normal salary data).

10
Postconditions
The postconditions describe changes in the state of objects in the
domain model.
Postconditions are not actions to be performed during the operation;
rather, they are observations about the domain model objects
that are true when the operation has finished after the smoke has
cleared.

Postconditions fall into these categories:


• Instance creation and deletion.
• Attribute Modification (change of value).
• Associations (to be precise, UML links) formed and broken. 11
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.

12
The Spirit of Post-conditions: the Stage and
Curtain
 Before the operation, take a picture of the stage.
 Close the curtains on the stage, and apply the system
operations
(background noise; screams, screeches…).
 Open the curtains and take a second picture.
 Compare the before and after picture, and express as post-
conditions 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)
13
Post Conditions: EXAMPLES
• Instance Creation and Deletion
• If a new sale, a Sale was created (instance creation).
• A SalesLineItem was created (instance creation).

• Attribute modification
• SalesLineItem.Quantity was set to quantity ( attribute modification).

• Association formed and broken


• If a new sale, the new sale was associated with the POST ( association formed).
• The SalesLineItem was associated with the sale (association formed).
• The SalesLineItem was associated with a product specification, based on UPC
match (association formed).
• On payment Sale was associated with Log and was de-associated from POST

14
Contracts for Process Sale Use case

(1) Contract for: enteritem


• PostCondition:(Other sections already discussed).
1. If a new sale, a sale was created (instance creation)
2. If a new sale, the new sale was associated with the POST (associated
formed)
3. A SalesLineItem was created (instance creation).
4. The SaleLineItem was associated with the Sale (associated formed).
5. SaleLineItem.Quantity was set to quantity (attribute modification).
6. The SaleLineItem was associated with a ProductSpecification, based
on UPC match (association formed).

15
(2) Contract for: endSale
• Name:endSale ()
Post-Condition:
• Sale.isComplete was set to true (attibute modification)

16
(3) Contract for: make payment
Name: makePayment (amount: Number or Quantity)
Responsibility: Record the payment, calculate balance and print receipt.
Type: System
Cross Reference: System Functions R2.1
Use cases: Process Sale
Notes:
Exceptions: If the sale is not completed, indicate an error.
If the amount is less than the sale total, indicate an error.
Output:
Pre-conditions:
Post-conditions:
1.
A payment was created (instance creation)
2. payment.amount.Tendered was set to amount (attribute
modification)
3. The payment was associated with the sale (association formed)
4. The sale was associated with the Store, to add it to the historical 17
log of completed sales (new relationship formed and old broken)
Contracts for: startup
Name: startUp ()
Responsibility: Initialize the system.
Type: System
Post-conditions: GUESS ??
1. A Store, POST, productCatalog and productSpecification have been created
(instance creation)
2. ProductCatalog was associated with ProductSpecifications (association formed).
3. Store was associated with ProductCatalog (association formed) formed).
4. Store was associated with POST (association formed)
5. POST was associated with ProductCatalog (association formed).

Sale

Change made in Domain Model isComplete: Boolean


endSale suggests isComplete attributed date
to be added in the Sale time 18
19 UP Artifacts: Relationships between Contracts and other Artifacts

Business Modeling
Domain Model Partial artifacts,
refined in each
iteration

Terms, concepts Elaboration of some


attributes, terms in the domain
associations model
State changes in
domain objects,
Use-Case Model attributes.
association
Glossary …
System
Requirements Foo(x)

Bar(y)

Text use Use case System


cases diagrams sequence
diagrams
System
Design Model operation
contracts
Design Software Architecture
Doc.
Software classes in design take
inspiration from domain model
Software Dev. Plan

Project Management
Development Case
Test Plan

Test Environment
Analysis Phase Conclusion
Domain Model

Use Case Model


System
Behavior
Object Oriented System
Sequence
Analysis Diagrams
System
Operations
Supplementary
Specifications
System
Use Case Contracts
Model

20

You might also like