CS636 Programming Assignment 1:  Client-Server Programming with JDBC

We will implement the core of the Music Store app of Murach as a client-server program, following the structure of the provided pizza1 project.

User app (simplified from Murach) and supplied in stub form.

See Murach pg. 645 for the home page of the web-app version of the user app.  It shows:

   Browsing through a catalog of CDs (the Catalog page)
   We're skipping the email items (join list, contact cust. support)

Thus the effective top level of the user app for us is the Catalog page. See MusicProjectUI (but of course we are not yet using pages, just line-oriented output)

The Catalog page, also shown on pg. 645, displays the catalog, i.e., the list of CDs. The user can choose a particular CD (for example product code 8601) and get more info on it, or display the current cart (Cart page, see below) or go back to the Home page.
     The resulting Product page for chosen product code 8601 is shown on pg. 675. From here, the user can:

1.      Browse the catalog (return to the top level Catalog page)
2.      Show cart: displays cart contents (Cart page).
3.      Add to cart: displays new cart contents (Cart page, see below)
4.      Listen to sample (more just below)

Listen to Sample:  if user is not registered, they must register now (Register page, pg. 675). Then a Sound page (pg. 676) is displayed, where the user chooses which song to play, with additional options for actions 1-3 above. If a song is chosen, its mp3 is fake-played (print out its URL), the download is recorded in the DB, and the Sound page is redisplayed.

Cart page (pg. 677): displays cart contents. The user can:

•  Change or remove order, redisplay cart contents
•  Continue Shopping: return to Catalog page   
•  Checkout: If needed, get info of Register page (pg. 675). With this done, just display the complete order (Invoice page, pg. 678, simplified: no “edit” or “Continue”) and save it in the DB, then display the Complete page (pg. 679).

  After the display of the Complete page,  the user is returned to the Catalog page. In the web app, the user will have a choice of returning to the Catalog page or the Home page.

Admin app (also simplified from Murach), supplied, but needs some fixes in service layer to work properly.
Note that admin users are defined in the userpass table, and should not to be confused with ordinary site users.
The admin app’s top-level page is the Login page, p. 681. Ignore the home and “Browse Catalog”, and other links here. The entered username and password must match userpass data. (BTW, the password should be encrypted in userpass, but that would complicate things.) Then on to the Admin Menu page, pg. 683, 2 choices: Process Invoices and Display Reports
     Process Invoices: list unprocessed invoices (Invoices page, pg. 685, but add invoice dollar total column), and instead of “Click to view”, just suppose the link says “Process Invoice”. Additionally, the user can go back to the admin Menu page. When the “Process Invoice” action is done for a particular invoice, the invoice is processed, that is, the "is_processed" field is set to ‘y’ in the invoice row in the DB, and the remaining unprocessed invoices are listed again. This is fake order processing of course.
    Display Reports: Just support lists of invoices (as in Process Invoices, but all invoices, processed or not) and lists of downloads (download id, product code, filename, user, download date, in download time order).

Note that the Cart is held in memory only, not saved in the database. The apps change the database only by adding users, downloads, lineitems, and invoices, and updating the isProcessed column of invoices. This is typical of a simple web app. The DBA can insert a new row for a new CD when necessary, for example, or a new row of userpass for a new admin.

Design Tasks (not necessarily in order, and to be revisited as you go)

•    Design the UI details, using simple text input and output. Largely done for you.
•    Design the service layer API.  Here you are free to design and name methods your own way, using pizza1 as a guide
•    Design the domain objects to go with the database tables. This is done for you, and shown in Murach: see pg. 649, but we’re dropping credit card info and anything else we're not using.
•    Design the DAO (data access object) layer.  Here you are free to design and name methods your own way. Murach has such classes: see pg. 667, but use "find" rather than "select" in names, use List or Set instead of ArrayList in method argument and return types, drop unused actions.

How to proceed?  Here are some ideas.

1.  Install and run the supplied music1-setup project and copy it to music1, for your first delivery. Set up an eclipse project, and compare it to pizza1.
2.  Create the tables in Oracle first and write a program Register (in cs636.music.presentation) to insert a new user, directly, no User object, no "DAO" yet.  This brute force starter program follows the idea of using all the pieces of the needed technology as soon as possible.  Elegance can wait a bit.
3.   Make the simple program work for MySQL as well (the server on pe07 or both that and your own).
When you finish these 3 steps, put this version in your cs636/pa1a directory at cs.umb. 
4.   Refactor Register to use the supplied User domain object and a DAO for it (one way: Murach UserDB, pg. 667, but don't use static methods!).
5.  Write the User-related service methods and make the ureg command work in SystemTest, then the gui command.
6.  Write the ProductDAO, first without Tracks and then with Tracks. The provided InvoiceDAO may help, since an Invoice has LineItems.
7.  Write the Product-related service methods and make the gp and gpi commands work in SystemTest.
8.  Now that Users and Products are supported, uncomment parts of the provided Invoice and Download DAOs and get them working.
9.   Incrementally, fill out the service API to go with your DAOs and get more of SystemTest to work.
10   Fill out UserApp.java and make AdminApp work.

Here is the test.dat for SystemTest, read in the same way pizza1's SystemTest reads its file.

i             reinitialize system to bring it back to starting state
gp            get a list of CDs (products)
gpi pf01      get info for product pf01
ureg  joe smith joe@cs.umb.edu     register user
ureg  sue cohen sue@cs.umb.edu     register user
gui sue@cs.umb.edu      get info on user
gti pf01                get track info for CD pf01
dl joe@cs.umb.edu jr01 1    record download by user joe of product jr01, track 1
cc            create cart (for current user)         
addli pf01    add lineitem for prod pf01 to cart 
sc            show cart            
co sue@cs.umb.edu       checkout cart for user (creating invoice 1 for it)
setproc 1     set invoice 1 as processed
gi            get list of invoices
gd            get list of downloads

Note: this is not a complete test, but will have to do for now. We may change it, so check again before using it.

Cart Handling: We don't need unique id's for carts, because they are memory-only constructs. As shown in the stub version of UserApp, the presentation layer needs a cart variable to remember its Cart object across multiple user actions. The "new Cart()" is code in the service layer, executed at the request of the presentation to create a cart.  That's the cc command above. The presentation layer passes the cart back to the service layer in any subsequent cart action. So the service layer does not have to remember the "current cart" itself.

Although the pizza1 project has some unit tests, in files *DAOTest.java, you can ignore these for pa1a and pa1b, since we have not yet covered the JUnit testing package in class.

Implementation Notes.

• There is no need to use inheritance among your Java classes.  If you feel the need, let me know your reasoning. Program as simply as possible.
• Use the powerful Collection classes at will: using generic classes is easy.
• Be sure to make local methods and of course all fields (instance variables) private.
• You can borrow anything you want from pizza1 (without attribution), but don't leave any unused code in your program.
• You can get some useful bits of code and SQL from Murach's implementation if you want, but this must be pared down to do just what we want here.  Attribute code from other external sources.
• To start, just print out "playing whiskey.mp3" or whatever. For final delivery, print out the URL (http://www.cs.umb.edu/cs636/music1setup/sound/pf01/whiskey.mp3 for example) so the user could copy-and-paste it to a browser.

First delivery for music1 (pa1a). Due Wed., March 10 at noon. If you have trouble with the delivery, see me during office hours on that day (2:00-3:00)

Write a program Register.java (in package cs636.music.presentation, and thus in directory src/main/java/cs636/music/presentation of your music1 project) to insert a new user, directly, no User object, no "DAO" yet.  This brute force starter program follows the idea of using all the pieces of the needed technology as soon as possible. Feel free to copy code from JdbcCheckup.java and Java files in the music1-setup project.

Register.java should accept database information the way SystemTest does, but it has no input file. Don’t take any user input for the information about the new user but rather just invent values in the program. Note that you can run Register using the already existent scripts runOnH2, runOnOracle, and runOnMysql.

By midnight of the due date, deliver your project to your cs636/pa1a directory at pe07.cs.umb.edu. Make sure that your directory structure looks like this:

cs636/pa1a/pom.xml -- as provided
cs636/pa1a/*.cmd, *.sh, test.dat -- as provided
cs636/pa1a/src/main/java/cs636/music/presentation/Register.java  -- your Register program
cs636/pa1a/src/… -- other files as provided in music1-setup
cs636/pa1a/database—as provided in music1-setup 
cs636/pa1a/sound -- as provided in music1-setup

Be sure to run your project on pe07 after delivering it, to be sure you have all the needed files there.

Final delivery: this may be edited, so check back

Due Sat., March 27, midnight, in your cs636/pa1b directory, full project with java files, database support, tested 6 ways (home, pe07) x (Oracle, mysql, H2).  (The previous week is spring vacation.) No late days here, this is handled like a homework, 10 points.

cs636/pa1b/pom.xml (directory corrected)
cs636/pa1b/src: top of source tree
cs636/pa1b/src/main/java/cs636/music/presentation/SystemTest.java, UserApp.java—filled in with working calls to your service layer, and Register.java from pa1a
cs636/pa1b/src/main/java/cs636/music/service/*.java: provide a complete service API even if you don't have time to implement all of it. cs636/pa1b/database—as provided in music1-setup 
cs636/pa1b/sound -- as provided in music1-setup

Leave unimplemented service methods as "stubs", i.e. just { return null; } or whatever is needed to avoid compiler warnings.

--other source files can be named anything reasonable, all java files in the expected packages will be collected.

Grading: we will read your sources and run your programs.

grading run (at least part what we will do to test your project):
reload all three databases
mvn clean package
runOnOracle Register  (run Register.java in cs636.music.presentation)
runOnOracle SystemTest
ant show-oradb (using database/build.xml)
runOnMysql SystemTest
ant show-mysqldb (using database/build.xml)
runOnH2 SystemTest
ant show-h2 (using database/build.xml)

runOnOracle UserApp
runOnOracle AdminApp

Late Days
Each student has 3 late days to apply to the 2 final project deliveries, to cover ordinary problems like business trips, other deadlines, etc. You can use them in any pattern, but not all 3 for one project--I will record the number of late days used on each project along with the score. To use late days, simply put a README in your project directory (pa1b this time) saying how many days you are using.