CS 351: Design of Large Programs

Assignment # 5, Due Date 05/05/02

In class, we studied in detail the analysis, design and software implementation of a Point of Sale terminal at a typical store as described by Larman. In particular, we considered the first iteration of the use case "Process Sale". This included a study of the System Sequence Diagram for this use case, the collaboration diagrams corresponding to each system operation (in response to a system event), the design class diagram and the Java implementation (see handout of code for the seven classes -- Store, Register, Catalog, ProductSpecification, Sale, SalesLineItem and Payment.)

The goals of this assignment include:

Your system should be capable of handling cash payments in multiple international currencies (for Extra Credit) while CC payments will involve connecting to a remote Credit Authorization Server (CAS).

GUI Design, Modification of existing classes and addition of some classes

The GUI should include the following components:

  1. A top panel containing at least the following three buttons: A push button labeled "NEW SALE", another labeled "END SALE" and a third (nominally disabled) labeled "PROCESS RETURNS".
  2. Below this panel should appear a TextArea (at the appropriate time). The contents/format of the text area should be very similar to that of the sale receipt. The first line includes the date, time and possibly a serial number. This is followed by a table of items with the following columns - ItemID, Qty, Item Desc., Unit Price and SubTotal.
  3. Below the TextArea is a panel, the contents of which are dependent on the state of the purchase. This is explained below.

System Operation makeNewSale()

Initially, the "END SALE" button is disabled. To begin a sale, the cashier clicks the "NEW SALE" button. This triggers the first system operation and causes the GUI to send the message "makeNewSale()" to the controller (which for this use case is the register.) This will trigger a sequence of message transfers captured in the collaboration diagram discussed in class. The effect on the GUI is that the buttons - "NEW SALE" and "PROCESS RETURNS" are disabled. The text area appears with the sale date/time and serial number on the first row and the table headings on the next row. The cursor is positioned under the column "ItemID" awaiting input from the cashier.

System Operation enterNewItem(..., ...)

Upon typing the item id, (s)he enters a tab and then item quantity followed by another tab. This triggers the next system operation "enterItem(..., ...)". Our client requires that the item description and sub-total fields of the table be completed. Note that this necessitates a modification of the "enterNewItem(..., ...)" method within the Sale class. The GUI will receive this information from the controller, display it and then position the cursor on the next row under column ItemID. The process of entering new items will continue until all items have been processed at which point the cashier clicks the "END SALE" button in the top panel.

System Operation endSale()

This system operation will involve computing the total for the sale and communicating it to the GUI which is displayed in the TextArea. Then the second panel below the TextArea becomes visible. This should contain a pair of radio buttons enabling the cashier to specify whether the customer wishes to pay in cash or by CC. A click of one of these buttons triggers the next system operation "makePayment(...)".

System Operation makePayment(...)

The parameter in makePayment() is an array of strings. The first element indicates Cash or CC. In the case of the former, the second element will contain the amount tendered and the third will contain the currency (ignore the third element if you are not implementing the EC part.) For CC payment, the second element of the array contains the CC number of the customer. The third element is the customer's name.

Why do we need to pass an array of strings to the controller? Should'nt the GUI be passing a Money or CC object instead? The reason for this is that, in general, the GUI does not know/understand these higher level abstractions (and we should not expect it to).

You now need to figure out what happens next. Does the controller pass the array of strings to the Sale object expecting it to create a Payment object and a Money or CC object? (if so, the Sale object will have to interpret the array of strings. Is that a reasonable expectation for the Sale object?) Or should the controller create one of these objects and pass it to sale which then creates the Payment object? Or should the controller create both the Money or CC object and the Payment object as well? Also, does it make sense to subclass Payment into say CashPayment and CCPayment and declare polymorphic operations in Payment? Is Sale visible to Payment, is Payment visible to Sale, both or neither?

What exactly are Payment's responsibilities? In the code included with this assignment, Payment is doing hardly anything at all. However, we have enhanced the scope of this assignment to include CC payments. It is now payment's responsibility to connect to a remote CAS server to seek authorization to proceed with this transaction. Use the Java Socket and ServerSocket classes for this. Assume that the CC number is 9 digits. Then the CAS should authorize the transaction only if the sum of the digits of the CC number is a multiple of 5.

If you are also attempting the EC part of this assignment, then Payment will be saddled with another responsibility - to handle multiple currencies. In particular, the sale total is in the local currency (the default of which is US$), however we wish to provide customers the convenience of paying in a basket of international currencies, confined to the euro, yen and sterling (but open to new entrants in future.) Now Payment must first convert the cash tendered by the customer to the local currency, subtract from it the sale amount and express the balance in the local currency.

To recap, clicking the Cash or CC Button on the Payment panel causes the system operation makePayment(...) to be triggered. This involves computing the change due OR obtaining authorization from the CAS. On the GUI, you could now replace the panel bearing the Cash/CC radio buttons with either a Cash Payment panel or a CC Payment panel. The former will elicit information on the amount tendered and payment currency (you may wish to use a List or ComboBox here) and return the amount of change (in US$) on a TextField. The latter would request the CC number and cardholder name and return a Yes/No response indicating whether authorization has been granted.

One final issue in connection with Payment (and this is relevant only if you are attempting the CC part) is that computing balance due will involve currency conversion. For this purpose, a remote web server will have to be accessed to get the latest currency rates. Our client requires that this be done at the start of each working day. You may wish to create a separate class to encapsulate this information which could be initialized by the SystemStartup class.

What needs to be turned in?

Turn in your new collaboration diagrams for the different system operations that you have changed, a new UML design class diagram showing (and naming) all associations, multiplicities, attributes and non-trivial methods (do not show methods such as create(), getx() or setx() but indicate parameter and return types.)

E-mail all your classes including the SystemStartup class. We will compile that class and run it. Make sure that every other class (except for Server1.java) is referenced by SystemStartup or by a class referenced by SystemStartup, etc.