System sequence diagramOperation contract

End of analysis

We have

Functional requirementUse case model

Use case diagramBrief use case descriptionRanking of the use casesFully dressed for the most important

Information requirementDomain model

The classes in the system and the structure between them

Moving from analyses to design

System sequence diagramFor each fully dressed use case make a system sequence diagramFor each system operation that changes the state of the domain model write an operation contract (we will not do much about operation contracts in this course just mention their existence)

System sequence diagram

: Cashier :System

Simple cash-only Process Sale scenario:

1. Customer arrives at a POS checkoutwith goods and/or services to purchase.2. Cashier enters item identifier andquantity, if greater than one.3. System records sale line item andpresents item description, price, andrunning total.Cashier repeats steps 2-3 until indicatesdone.4. System presents total with taxescalculated.5. Cashier tells Customer the total, andasks for payment.6. Customer pays with cash.7. Cashier enters cash tendered.8. System records payment and presentschange due.7. System logs the completed sale, butdoes not interact with external systems.8. System presents receipt.9. Customer leaves with receipt and goods.

enterItem(itemID, quantity)

endSale()

makePayment(amount)

description, total

total with taxes

change due, receipt

* [more items]

In the systems sequence diagram the system is seen as a black box.

The system events(the arrows between the actor an the system) are found from the Fully dressed descriptionThe response from the system can shown as dottet linies

System events

Name the system event with a verbPut the values (parameters) on Response from the system can be shown as information on a dotted lineLoops can be shown as a box around system events. Please see the book for details on how it is written in UML

System operations and contract

A system operation is an operation the system has to offer, to handle the system events.There are different kind op system operations, the one that changes the state of the domain model is the one you should consider making a contract on.The contract describe in detail what state the domain model is in after the system operation.

System operation changing the state of the domain model

: Cashier:System

addLineItem(itemID, quantity)

endSale()

makePayment(amount)

description, total

total with taxes

change due, receipt

* [more items]

makeNewSale()

these input system eventsinvoke system operations

the system eventmakeNewSale invokes asystem operation calledmakeNewSale and so forth

this is the same as in object-oriented programming whenwe say the message fooinvokes the method (handlingoperation) foo

Example of operation contract

Saledatatime 1 1..*1 1..*

SalesLineItemquantity

0..* 10..*

ProductSpecificationdescriptionpriceitemID

Operations contractOperation: addLineItem (itemID, quantity)Use-cases: Process salePrecondition: A Sale instance (object) has been createdPost conditions:

A SalesLineItem instance (object) sli was createdsli was associated with the current Salesli.quantity became quantitysli was associated with a ProductSpecification (object), based on itemID match (association formed).

Part of the domain model

Operation contracts

Operations contractOperation: addLineItem (itemID, quantity)Use-cases: Process salePrecondition: A Sale instance (object) has been

createdPostconditions:

A SalesLineItem instance (object) sli was createdsli was associated with the current Salesli.quantity became quantitysli was associated with a ProductSpecification (object), based on itemID match (association formed).

Important notes:Reference to the use casePrecondition: what information has to be present in the system, before theoperations startsPostcondition:Which object has been createdWhich attributes has been changedWhich object structure has been created

Ready to move from what to how