Download presentation
Presentation is loading. Please wait.
Published byGeoffrey Lloyd Modified over 8 years ago
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
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.