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

2. Software Engineering 2 Object-oriented Analysis and Design NextGen POS 1  New System Sequence Diagrams m In the current iteration, the new payment handling requirements involve new collaborations with external systems. m 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: m new system operations that the NextGen POS system will need to support m calls to other systems, and the responses to expect from these calls  Common Beginning of Process Sale Scenario m 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

3. Software Engineering 3 Object-oriented Analysis and Design NextGen POS 2 enterItem(itemID, quantity) : NextGenPOS System : Cashier endSale Process Sale Scenario Description.total total with taxes makeNewSale «actor» : TaxCalculator taxLineItems= getTaxes(sale) [more items ] loop

4. Software Engineering 4 Object-oriented Analysis and Design NextGen POS 3 Credit payment SSD makeCreditPayment (credNum,expiryDate) reply=requestApproval(request) :Customer postReceivable(receivable) :NextGenPOS System «actor» :CreditAuthorization Service «actor» :Accounts postSale(sale)

5. Software Engineering 5 Object-oriented Analysis and Design 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. m 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 m 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.

6. Software Engineering 6 Object-oriented Analysis and Design NextGen POS 5  Check payment SSD. makeCheckPayment (driversLicenseNumber) reply=requestApproval(request) :Cashier :NextGenPOS System «actor» :CheckAuthorization Service

7. Software Engineering 7 Object-oriented Analysis and Design NextGen POS 6  In this iteration, the new system operations must handle are: m makeCreditPayment m makeCheckPayment  In the first iteration, the system operation for the cash payment was simply makePayment. m 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) m Usually, the use case text is itself sufficient, and these contracts aren't useful. m 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.

8. Software Engineering 8 Object-oriented Analysis and Design NextGen POS 7  Contract CO5: makeCreditPayment m Operation:makeCreditPayment( creditAccountNumber, expiryDate ) m Cross References:Use Cases: Process Sale m Preconditions: An underway sale exists and all items have been entered m 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.

9. Software Engineering 9 Object-oriented Analysis and Design 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 m Operation:makeCheckPayment( driversLicenceNumber ) m Cross References:Use Cases: Process SalePreconditions:An underway sale exists and all items have been entered. m Postconditions:  a CheckPayment pmt was created  pmt was associated with the current Sale sale  a DriversLicense dl was created; dl.number = driversLicenseNumber  dl was associated with pmt  a CheckPaymentRequest cpr was created.  pmt was associated with cpr  sale was associated with the Store as a completed sale