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:
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:
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)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.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.