Description
CNT 4714 Assignment 1: Event-Driven Programming
Objectives: To practice event-driven programming using Java-based GUIs. To refresh your basic Java skills. Description: Develop a Java program that creates a standalone GUI application (not an applet) that simulates an e-store which allows the user to add items (books) to a shopping cart and once all items are included, total all costs (including tax), produces an invoice, and append a transaction log file. Your program development must include the following steps: 1. Create a main GUI containing the following components: a. An area that allows the user to input data into the application along with the descriptive text that describes each input area. b. A total of six buttons as shown below with functionality as described below. c. As illustrated below, the various buttons on the interface are only accessible at certain points during a user’s interaction with the e-store. 2. An input file named “inventory.txt”. This is a comma separated file which contains the data that will be read by the application when the user makes a selection. Each line in this file contains three items; a book id, a quoted string containing the book title and author’s name, and the price for one copy of the book. A sample file is provided for you on WebCourses. 3. An output file (append only) named “transactions.txt” must be created that uniquely logs each user transaction with the e-store. The unique transaction id will be generated as a permutation of the date/time string when the transaction occurred. Restrictions: Your source file shall begin with comments containing the following information: /* Name: Course: CNT 4714 – Fall 2019 Assignment title: Program 1 – Event-driven Programming Date: Sunday September 15, 2019 */ Input Specification: The file “inventory.txt” as described above (see example below as well). Output Specification: Output is to appear in the specified components of the GUI and various message boxes that appear, plus the contents of the “transactions.txt” log file that will be generated. Deliverables: CNT 4714 – Programming Assignment #1 – Fall 2019 Page 2 (1) Submit a working copy of your source code (all .java files), including your inventory.txt file, via WebCourses no later than 11:59pm Sunday September 15, 2019. (2) Include a file that contains screen shots, similar to those illustrated below, that shows your application in action as a user interacts with your e-store to purchase books. (3) Include a screen shot of your “transactions.txt” file showing at least the last few transactions (similar to the one shown on the last page of this document). Additional Information: Shown below are example screen shots of the GUI to help illustrate how your application is to operate. 1. Screen shot of the contents of an example “inventory.txt” file. Page 3 2. Initial GUI: 3. GUI after user specifies total number of items in the order and makes a selection for item #1. Note that these buttons are not initially “active”. Allows for processing an item once it is selected. Confirms that the item is correct. View the order so far. Completes an order – generates invoice and adds to the transaction file. Clears order and starts over – no write to transaction file Quit! Page 4 4. GUI after user has selected the first item and clicked the “Process Item #1” button. 5. When the user clicks on the “Confirm Item #1” button, a confirmation information message appears on the screen. Note that the “Confirm Item #1” button is now active and the “Process Item #1” button is inactive. Information on the book purchased has been extracted from the inventory file and written into the window on the line for item #1. User entered an incorrect book ID. This message would be displayed when user pressed the Process Item button. This is the only “error” you will need to catch. Page 5 6. The main GUI after the user has confirmed the first item. 7. User enters next item in the order. Information for previous item remains on display. Subtotal should reflect current total of all confirmed items. Note that the text areas for entering the second item information are cleared and ready for input. Discount is based on the quantity of a item. If: 1-4 = 0% 5-9 = 10% 10-14 = 15% >=15 = 20% Note that the buttons change number. Page 6 8. The GUI after the user has entered the information for all the items and confirmed the last item. 9. When the user clicks the “View Order” button, the following message box should appear. Page 7 10. When the user clicks the “Finish Order” button, the invoice message should be generated and displayed. The date and time are used to create the unique transaction id in the “transactions.txt” file. For the invoice the format is “DD/MM/YY HH:MM:SS TMZ” Page 8 11. The transaction file after order shown above was finished. Note the unique transaction ids based on the date and time. The last transaction occurred on 08/27/2019 at 13:37 (1:37pm). See the invoice message above. Permutation used here is: DDMMYYYYHHMM. Page 9 12. The transaction file after several orders have been completed. Note the unique transaction ids based on the date and time for every separate transaction. This file shows seven separate transactions. Page 10
CNT 4714 Project 2: An Application Employing Synchronized/Cooperating Multiple Threads In Java Using Locks – A Banking Simulator
Objectives: To practice programming cooperating, synchronized multiple threads of
execution.
Description: In this programming assignment you will simulate the deposits and
withdrawals made to a fictitious bank account (I’ll let you use my real bank account
if you promise to make only deposits! ). In this case the deposits and withdrawals
will be made by synchronized threads. Synchronization is required for two reasons –
(1) mutual exclusion (updates cannot be lost) and (2) because a withdrawal cannot
occur if the amount of the withdrawal request is greater than the current balance in
the account. This means that access to the account (the shared object) must be
synchronized. This application requires cooperation and communication amongst the
various threads (cooperating synchronized threads). (In other words, this problem is
similar to the producer/consumer problem where there is more than one producer and
more than one consumer process active simultaneously.) If a withdrawal thread
attempts to withdraw an amount greater than the current balance in the account – then
it must block itself and wait until a deposit has occurred before it can try again. As
we covered in the lecture notes, this will require that the deposit threads signal all
waiting withdrawal threads whenever a deposit is completed.
1. To keep things relatively simple, as well as to see immediate results from a
series of transactions (deposits and withdrawals), assume that deposits are
made in amounts ranging from $1 to $250 (whole dollars only) and
withdrawals are made in amounts ranging from $1 to $50 (again, whole dollars
only).
2. You should have four deposit threads and eight withdrawal threads
simultaneously executing.
3. Once a deposit thread has executed, put it to sleep for few milliseconds
(randomly generate this number – don’t use a constant sleep time) or so
(depends a little bit on the speed of your system as to how long you will want
to sleep the depositor threads – basically we want to ensure a lot more
CNT 4714 – Project 2 – Fall 2019
Page 2
withdrawals than deposits) to allow other threads to execute. This is the only
situation in which a deposit thread will block.
4. For withdrawal threads, things will be a bit different depending on whether you
are working on a single or multi-core processor.
a. For single core processors, once a withdrawal thread has executed, have
it yield to another thread. Since the thread is giving up the processor
voluntarily, it will be unlikely to run again (attempt a second withdrawal
in a row), before another thread runs. Note however, that it does not
prevent it from running again, if all other withdrawal threads are blocked
and all depositors are sleeping, it will run again.
b. For multi-core processors, once a withdrawal thread has executed, have
it sleep for some random period of time (again, a few milliseconds
should be fine). Depending on which core a thread is executing,
yielding the CPU won’t ensure that the same thread will not run again
immediately. While, sleeping the thread will also not ensure that it will
not run two or more times in succession, it is less likely to do so in the
multi-core environment.
c. What we don’t want to happen is a single withdrawal thread gaining the
CPU and then executing a long sequence of withdrawal operations.
Recall though that withdrawal threads block if they attempt to withdraw
more than the current balance in the account.
d. Similarly, we don’t want depositor threads monopolizing the CPU either
and causing the balance in the account to grow continuously. This
would most likely occur when the withdrawal threads are sleeping too
long in comparison to the average sleep time of the deposit threads. See
page 7 for an illustration of this.
5. Assume all threads have the same priority. Do not give different priority to
depositor and withdrawal threads.
6. The output from your program must look reasonably similar to the sample
output shown below.
7. Do not put the threads into a counted loop for your simulation. In other
words, the run() method should be an infinite loop. Just stop the simulation
from your IDE after a few seconds.
8. Do not use the Java synchronized statement. I want you to handle the
locking and signaling yourself. No monitors!
Page 3
9. You must utilize a reentrant lock from the java.util.concurrent.locks package
for implementing your locking protocols. We will specify no fairness policy for
this application. Do not create your own lock using a Boolean or any other type
of variable.
References:
Notes: Lecture Notes for Multithreaded Applications.
Restrictions:
Your source files shall begin with comments containing the following information:
/* Name:
Course: CNT 4714 Fall 2019
Assignment title: Project 2 – Synchronized, Cooperating Threads Under Locking
Due Date: October 6, 2019
*/
Input Specification: Internal to the program.
Output Specification: Console based. Your output should appear reasonably
similar to the output shown below.
Deliverables:
(1) Zip up all of your .java files and submit them via WebCourses no later than
11:59pm Sunday October 6, 2019.
(2) Include at least one screen shot which illustrates the execution of your
synchronized threaded application. See below for some representative
examples. You can either do a screen shot of the console window like I did
below or redirect your output to a file and take a screen shot from an editor.
Additional Information:
Shown below are three example screen shots of the output from this program to help
illustrate how your application is to operate and display the results. The last page
illustrates execution runs that you do not want to produce.
Page 4
Page 5
W4 runs three
times in a row.
This is ok
occasionally.
Page 6
All withdrawal
threads are
blocked.
Page 7
We don’t want to see this sort of scenario where the depositors are monopolizing the
account. Indication is the depositor threads aren’t sleeping long enough.
CNT 4714 Project Three: Two-Tier Client-Server Application Development With MySQL and JDBC
Objectives: To develop a two-tier Java based client-server application interacting with a MySQL
database utilizing JDBC for the connectivity. This project is designed to give you some experience
using the various features of JDBC and its interaction with a MySQL DB Server environment.
Description: In this assignment you will develop a Java-based GUI front-end (client-side)
application that will connect to your MySQL server via JDBC.
You are to develop a Java application that will allow any client (the end-user) to execute commands
against the database. You will create a Java GUI-based application front-end that will accept any
MySQL DDL or DML command, pass this through a JDBC connection to the MySQL database
server, execute the statement and return the results to the client. Note that while technically your
application must be able to handle any DDL or DML command, we won’t actually use all of the
commands available in these sublanguages. For one thing, it would be quite rare to allow a client to
create a database or a table within a database. Note too, that the only DML command that uses the
executeQuery() method of JDBC is the Select command, all other DML and DDL commands
utilize executeUpdate(). Some screen shots of what your Java GUI front-end should look
like are shown below. Basically, this GUI is an extension of the GUI that was developed in the
lecture notes and is available on WebCourses as DisplayQueryResults.java. Your Java application
must give the user the ability to execute any SQL DDL or DML command for which the user has
the correct permissions. Note also, that if the user wishes to change databases in the middle of a
session, they must reconnect to the new database. Their user information can remain in the proper
window, but you must click the reconnect button to establish a connection to the new database. You
do not need to support simultaneous connections from your application to more than one database in
this assignment. However, you will be able to start multiple instances of your Java application and
allow different clients to connect simultaneously to the MySQL server, since the default number of
connections is set at 151 (see your Workbench options file under the networking tab).
Once you’ve created your application, you will execute a sequence of DML and DDL commands
and illustrate the output from each in your GUI for two different users. For this project you will
create, in addition to the root user, a client user with limited permissions on the database (see
below). The root user is assumed to have all permissions on the database, any command they issue
will be executed. The client user will be far more restricted.
References for this assignment:
Notes: Lecture Notes for MySQL and JDBC.
Input Specification:
The first step in this assignment is to login to the MySQL Workbench as the root user and
execute/run the script to create and populate the backend database. This script is available on the
assignment page and is named “project3dbscript.sql”. This script creates a database
named project3. You can use the MySQL Workbench for this step, or the command line
whichever you prefer.
CNT 4714 – Project Three – Fall 2019
Page 2
The second step is to create authorizations for a client user (in addition to the root user) named
client. By default your root user has all permissions on the project3 database. Use either SQL
Grant statements from the command line or the MySQL Workbench (see separate document for
details on how to accomplish this task) to check and set permissions for the client as follows:
Register the new user named client (assign them the password client – ignore the MySQL warning
on weak password setting) and assign to this user only selection privileges on the project3 schema.
Output Specification: There are two parts for the output for this project. Part 1 is to provide
screen shots from your application which clearly show the complete query/command expression
and results for each of the commands that appear in the script named:
project3rootuserscript.sql available on the course website. There are eight different
commands in this script and some of the commands will have more than one output capture (see
below). Part 2 is to provide screen shots from your application which clearly show the complete
query/command expression and results for each of the commands that appear in the script named:
project3clientuserscript.sql available on the course website. There are three different
commands in this script and some of the commands will have more than one output capture (see
below). To produce your final output, first recreate the database, then run the root user
commands followed by the client commands.
Deliverables:
Zip up all of the .java files associated with your application as well as the screen shots from each of
the commands specified in both the project3rootuserscript.sql and
project3clientuserscript.sql files via WebCourses no later than 11:59pm Sunday
October 20, 2019. Be sure to clearly label each screen shot.
Details:
Shown below is a screen shot of the initial GUI. Notice that there are drop-down lists for selecting
the JDBC driver and database URL that the client must select. The client must also specify a
username and password (MySQL option) before connecting to the database.
You should provide buttons for the user to clear the command window as well as the result window.
The status of the connection should be returned to the GUI and displayed in the connection area.
The output of all SQL commands should be returned to the SQL Execution Result window. Please
note that only SQL commands can be executed via this application, we will not go to the effort of
making the application display the results of MySQL-specific commands. (When a MySQLspecific command is executed, the SQL Execution Result window does not need to display any
results, if you wanted to you could display the line “MySQL command executed” in the results
window, but this is not required.)
Note that for non-query DML and DDL commands, before and after screen shots must be taken to
illustrate the basic effect of the command. See pages 8-9 for an illustration of this.
Page 3
The GUI areas defined.
Button to establish
connection to database
Button to clear
results window
Button to clear
the command
window
Button to
execute the
command in
the window
Drop down lists for
selecting JDBC
driver and
database
SQL Execution
Window
SQL Command
Window
DB Connection
area
Page 4
Screen shot illustrating an initial client connection.
Connection established to
selected database URL
Page 5
Illustrating the drop-down list of possible drivers that could be selected.
Illustrating the drop-down list of possible database URLs available.
Drop down menu for various
drivers that could be selected. You
can just use the one for this project.
Drop down menu for various
database urls that could be selected.
You can just use the one for this
project.
Page 6
User has connected to a database and issued a select command. Results are displayed in the SQL
Execution window.
A more complicated query:
Note the
metadata.
Your
application
must print
this for the
user.
Page 7
When the user makes a mistake entering a SQL command:
Page 8
The following three screen shots illustrate that your application should be able to handle non-query
commands from the users.
Before screen shot of a subset of the riders relation:
Page 9
Insert command issued:
After screen shot of subset of riders relation after insert command was issued:
Page 10
Screen shot illustrating the client user issuing a command for which they do not have permission:
CNT 4714 Project Four: Developing A Three-Tier Distributed Web-Based Application
Objectives: To incorporate many of the techniques you’ve learned so far this semester into a
distributed three-tier web-based application which uses servlets and JSP technology running on a
Tomcat container/server to access and maintain a persistent MySQL database using JDBC.
Description: In this assignment you will utilize a suppliers/parts/jobs/shipments database
(creation/population script available on the course assignment page) as the back-end database. Frontend access to this database by the client will occur through a single page displayed in the client’s web
browser. The schema of the backend database consists of four tables with the following schemas for
each table:
suppliers (snum, sname, status, city) //information about suppliers
parts (pnum, pname, color, weight, city) //information about parts
jobs (jnum, jname, numworkers, city) //information about jobs
shipments (snum, pnum, jnum, quantity) //suppliers ship parts to jobs in specific quantities
The first-tier (client-level front-end) of your application will be a JSP page that allows the client to
enter SQL commands into a window (i.e. a form) and submit them to the server application for
processing. The front-end (and only the front-end) will utilize JSP technology. The client front-end
will provide the user a simple form in which they will enter a SQL command (any DML, DDL, or
DCL command could theoretically be entered by the user, however we will restrict to queries, insert,
update, replace, and delete commands). The front-end will provide only two buttons for the user, an
Execute button that will cause the execution of the SQL command they enter, and a Reset button that
simply clears any content in the form input area. The client front-end will run on any web-based
browser that you would like to use. You can elect to have a default query or not, it is entirely your
decision. The application will connect to the backend database as a root user client.
The second-tier servlet, in addition to handling the SQL command interface will also implement the
business/application logic. This logic will increment by 5, the status of a supplier anytime that supplier
is involved in the insertion/update of a shipment record in which the quantity is greater than or equal to
100. Note that any update of quantity >= 100 will affect any supplier involved in a shipment with a
quantity >= 100. The example screen shots illustrate this case. An insert of a shipment tuple (S5, P6,
J7, 400) will cause the status of every supplier who has a shipment with a quantity of 100 or greater to
be increased by 5. In other words, even if a supplier’s shipment is not directly affected by the update,
their status will be affected if they have any shipment with quantity >= 100. (See page 9 for a bonus
problem that implements a modified version of this business rule.) The business logic of the
second tier will reside in the servlet on the Tomcat web-application server (server-side application).
This means that the business logic is not to be implemented in the DBMS via a trigger.
The third-tier (back-end) is the persistent MySQL database described above and is under control of the
MySQL DBMS server. All you need to do with the database is run the creation/population script. See
the important note below concerning when/how to re-run this script for your final submission.
Page 2
References:
Notes: Lecture Notes for MySQL installation and use. Documentation for MySQL available at:
http://www.mysql.com. More information on JDBC can be found at:
http://www.oracle.com/technetwork/java/javase/jdbc/index.html . More information on Tomcat can be
found at http://tomcat.apache.org. Lecture Notes for Servlets. Lecture Notes for JSPs.
Restrictions:
Your source file shall begin with comments containing the following information:
/* Name:
Course: CNT 4714 – Fall 2019 – Project Four
Assignment title: A Three-Tier Distributed Web-Based Application
*/
Input Specification: The suppliers/part/jobs/shipments database that is created/populated by the
script project4dbscript.sql, is the back-end to this application. All other input comes from
the front-end client submitted to the application server based servlet entered as either queries or
updates to this database. The set of commands that you are to execute against this database are
included in the project4commands.sql file available on the course homework page. I do not
expect your front-end to execute the script. You’ll need to execute the commands in this script one at a
time in your application (copy and paste!). I’ve put them into a script file for convenience and so that
you can run the script in the MySQL Workbench if you’d like to compare/see the result sets for each
user command.
Output Specification: All output is generated by the servlet and should appear in the user’s browser
as a text/html page presented to the user. IMPORTANT: Be sure to re-run the project4 database
creation/population script before you begin creating your screen shots for submission. By doing so
you will ensure that the database is in its initial state so that all update operations will produce the
values we are expecting to see in your result outputs.
Deliverables:
(1) You should submit your entire webapps folder from Tomcat for this program. If you submit
the entire folder, then all of the files necessary to execute your web application will be included
with the directory structure intact. Submit this via WebCourses no later than 11:59pm Sunday
(2) The following 14 screen shots must be submitted along with your webapps folder. (You can
include the screenshots in the top-level of your webapps folder if you’d like, just be sure to
include a note that you’ve done so.)
a. Command 1
b. Command 2A
c. Command 2B – output may vary here
d. Command 2C
e. Command 3A – output may vary here
f. Command 3B
g. Command 3C – output may vary here
h. Command 3D
i. Command 4
j. Command 5A
k. Command 5B – output may vary here
l. Command 5C
Page 3
m. Command 5D
n. Command 6
Additional Information:
Be very careful when setting up the directory structures required for the web applications running
under your server (Tomcat 9.0.24 or later). See the course notes on servlets for the exact directory
structure that must be developed.
Important: Please name your webapp: Project4. Let the TAs know if you are doing the bonus
problem by attaching a note to your WebCourses submission.
Schematic Overview of Project Components:
Tomcat Servlet Container
Project4 webapp
index.jsp Project4
Servlet
MySQL DB
Server
project4
User (Web-browser)
Page 4
Some screen shots illustrating the application.
Main client screen (initial configuration using a default query string):
User input area.
Two form buttons
All results returned in
this area.
Page 5
Client simply clicks the “Execute Command” button and the SQL command in the form is executed:
Results from running the
query “select * from
suppliers” – to be used to
illustrate an update
operation explained on
pages 6-8. Notice that
the supplier S5’s status is
currently 4.
Page 6
Client makes a mistake entering an SQL command:
There is no column named
something in the shipments
table.
Error message is returned from
MySQL indicating the problem with
the operation.
Page 7
Inserts and updates may cause changes to the supplier status field (business logic is triggered) as
shown below:
Client issues the following insert command:
Alert message when an update to the quantity field in the shipments table has caused an update of a
supplier’s status in the supplier table. Note that in my application, I used this alert message any time
the business logic was tested even if it did not trigger any updates. This means that this message
would appear with different values even if no rows are updated.
Page 8
After executing update command (the previous insert), client runs select * from suppliers.
BONUS PROBLEM: 15 points
Instead of allowing any update/insert of a quantity >= 100 to affect any supplier with a shipment
involving a quantity >= 100, adjust the business logic portion of your application so that an
insert/update of a quantity greater than 100, causes a change to the status of only those suppliers
Notice on page 4 (in the
original suppliers table)
that supplier S5 had a
status of 4. After this
update, the business logic
has increased supplier S5’s
status by 5, so it is now 9.
Notice too, that suppliers
S1, S12, S17, S21, S22, S3,
S44, and S6) also had their
status increased by 5, since
they were involved with a
shipment in which the
quantity was >= 100 when
the insert command was
issued. See bonus problem
below for a “fix”.
Page 9
directly affected by the update. For example, using the case shown above, when inserting the row
(S5, P6, J7, 400) into the shipments table, only the status of supplier S5 should be increased by 5
(see screen shot below). However, an update such as: UPDATE shipments SET quantity =
quantity + 50 WHERE pnum = “P3”, would increase by 5 the status of every supplier who ships
part P3 in a quantity >= 100 after the update has been issued.
NOTE: If you elect to do the bonus problem, submit only this version of your application. Do not
also submit the non-bonus problem version. Let the TAs know if you’ve elected to do the bonus
problem or not.
Immediately after issuing the update (insert above), the user reruns the select * from suppliers query:
Page 10
No changes to
S1, S1, S12, S17,
S21, S22, S3, S44,
or S6 this time.
Only supplier S5 had a
change of status due to the
insertion of the row (S5,
P6, J7, 400) as they were
the only supplier affected
by this update.
Notice that this time,
with the improved
business logic that only
the supplier directly
affected by the insert
has had their status
updated, all other
supplier status values
remain unchanged.
