Software Engineering 1 Object-oriented Analysis and Design Chap 31 More SSDs and Contracts.

Software Engineering 1

Object-oriented Analysis and Design

Chap 31More SSDs and Contracts



NextGen POS 1

New System Sequence Diagrams In the current iteration, the new payment handling requirements

involve new collaborations with external systems. To review, SSDs use sequence diagram to illustrate inter-system

collaborations, treating each system as a blackbox. To illustrate the new system events in SSDs in order to clarify:

new system operations that the NextGen POS system will need to support

calls to other systems, and the responses to expect from these calls Common Beginning of Process Sale Scenario

The SSD for the beginning portion of a basic scenario includes makeNewSale, enterItem, and endSale system events; it is common regardless of the payment method



NextGen POS 2

enterItem(itemID, quantity)

:NextGenPOSSystem: Cashier

endSale

Process Sale Scenario

Description.total

total with taxes

makeNewSale

«actor»:TaxCalculator

taxLineItems=getTaxes(sale)

[more items ]loop



NextGen POS 3

Credit payment SSD

makeCreditPayment(credNum, expiryDate)

reply = requestApproval( request )

:Customer

postReceivable( receivable )

:NextGenPOSSystem

«actor»:CreditAuthorization

Service

«actor»:Accounts

postSale( sale )



NextGen POS 4

In both cases of credit and check payments, a assumption (for this iteration) - the payment is exactly equal to the sale total, and a different amount does not have be an input parameter.

the call to the external CreditAuthorization Service is modeled as a regular synchronous message with a return value.

This is an abstraction that could be implemented with a SOAP request over secure HTTPS, or any remote communication mechanism.

The makeCreditPayment system operation and the use case assume the credit information (credit account number and expiry date) of

the customer is coming from a credit card (reader). when a credit authorization service approves a credit payment, it owes

the store for the payment; thus, a receivables entry needs to be added to the accounts receivable system.



NextGen POS 5

Check payment SSD.

makeCheckPayment( driversLicenseNumber)

reply = requestApproval( request)

:Cashier

: NextGenPOSSystem

«actor»: CheckAuthorization

Service



NextGen POS 6

In this iteration, the new system operations must handle are: makeCreditPayment makeCheckPayment

In the first iteration, the system operation for the cash payment was simply makePayment.

Now that the payments are of different types, it is renamed to makeCashPayment.

To review, system operation contracts are an optional requirements artifact (part of the Use-Case Model)

Usually, the use case text is itself sufficient, and these contracts aren't useful.

But on occasion they bring value by their precise and detailed approach to identifying what happens when a complex operation is invoked on the system, in terms of state changes to objects defined in the Domain Model.



NextGen POS 7

Contract CO5: makeCreditPayment Operation:makeCreditPayment( creditAccountNumber, expiryDate

) Cross References:Use Cases: Process Sale Preconditions: An underway sale exists and all items have been

entered Postconditions:

a CreditPayment pmt was created pmt was associated with the current Sale sale a CreditCard cc was created; cc.number = creditAccountNumber,

cc.expiryDate = expiryDate cc was associated with pmt a CreditPaymentRequest cpr was created pmt was associated with cpr a ReceivableEntry re was created re was associated with the external AccountsReceivable sale was associated with the Store as a completed sale

postcondition indicating the association of a new receivable entry in accounts receivable.



NextGen POS 8

During testing, it is clear from this post-condition that the accounts receivable system should be tested for the presence of a new receivable entry.

Contract CO6: makeCheckPayment Operation:makeCheckPayment( driversLicenceNumber ) Cross References:Use Cases: Process SalePreconditions:An

underway sale exists and all items have been entered. Postconditions:

a CheckPayment pmt was createdpmt was associated with the current Sale sale a DriversLicense dl was created; dl.number =

driversLicenseNumberdl was associated with pmt a CheckPaymentRequest cpr was created.pmt was associated with cpr sale was associated with the Store as a completed sale

Software Engineering 1 Object-oriented Analysis and Design Chap 31 More SSDs and Contracts.

Documents

Transcript of Software Engineering 1 Object-oriented Analysis and Design Chap 31 More SSDs and Contracts.