Assignment InstructionsComplete the following steps for this assignment:Create a MySQL script that creates the tables in the database with the appropriate primary and foreign keys.Your script must add data into the database tables. Every table must be loaded with at least two rows of data.Create screen captures showing the creation and contents of each table.Check and implement the database connectivity using JDBC.Check and implement exception handling for the database connectivity.Implement the Log-in action in your CapestraApp project, checking for the specified username and pass-word in the database and reporting a successful or unsuccessful log-in.Run your CapestraApp program and do screen captures of both successful and unsuccessful log-in attempts.Do not capture your entire desktop—just capture the individual screens.Paste all screen shots into a single MS Word document.Your name should appear at the top of the MS Word document.Name your document, following this pattern: LastName_Week5.docx.Create a .zip file containing your MySQL script file, your MS Word document, and a .zip of your CapestraApp project.Rename your .zip file, following this pattern: LastName_Week5.zip.SQL: CREATE ALL TABLES IN DATABASE; LOAD DATA INTO DATABASEOverviewTo integrate the functionality between the database and the application, you need to create the connection using JDBC. The JDBC API allows Java to connect to MySQL 5.7 using the MySQL Driver on any platform. The JDBC API allows Java to connect to the database, create and execute queries, and view and modify resulting records. Be sure to view the videos to guide you through the database creation and connection. You will need to create a MySQL script to create the ‘orderentrysystem’ database used by the CapestraApp application. The script must not only create all appropriate tables but also must load some sample data into each table. Note that just creating the database within MySQL Workbench does not satisfy the requirements of this assignment—you must create the database using a MySQL script file.This week’s assignment also includes a small programming assignment: You will create the semantics behind your revised Log-in scene. Currently your Log-in scene only provides the employee with a field for entering a username. Checking the SRS, you will see that the Log-in scene must provide for both a username and a pass-word. A successful log-in takes place only if both are provided to the system and they match what is in the orderentrysystem Employee table. You need to modify the Log-in scene to provide for a correctly functioning pass-word field, as well as using MySQL to determine whether the username-passwor-d combination matches an employee in the database. If a match is found, an appropriate message (including the employee’s first name, last name, and employee ID) should be displayed to the user. If no match is found, an appropriate message should be displayed.In this assignment, you will create the database tables in MySQL 5.7 for the CapestraApp application. In addition, you will create and check the functionality to connect to the database from the application through a connector using JDBC. Use CapestraApp code provided to check that the database connection is correctly implemented. You need to ensure that exception handling is done correctly in case the database does not exist or if the connection fails.Check the SRS to see precisely what the Log-in action must do. Examine what is implemented in the CapestraApp template code to see what it does and how it does it. You’ll need to think about how to modify the existing code to meet the SRS requirements.Successfully Designing and Building Software
Successfully Designing and Building Software
Systems
Following are some tips on designing and building software systems:
1. Read each assignment carefully. This is a must! Each assignment tells precisely what
the deliverables are. Implement those items and nothing more. The assignments are
“staged” so that you will incrementally get a more and more functional system, though
the workload each week is approximately the same.
2. Read and “play” with the provided skeleton app. You need to understand it well in order
to make extensions and corrections. The better you understand how the app currently
works, the easier it will be for you to make modifications and additions.
3. Allow sufficient time to complete each assignment. Most assignments take longer than
you would originally guess. So, you must allow some margin for error—which leads to
the next step. Leaving the actual programming for the weekends almost never provides
adequate time.
4. Under no circumstance allow yourself to fall behind. In programming, falling behind is
lethal! You simply cannot make up everything you should have been doing throughout
the course in the last couple of weeks.
5. Do your own work. Programming cannot be learned vicariously. It is definitely okay to
ask questions of each other—you are encouraged to do so—but do not let others do
your work for you. You will become addicted to their help and then become hopelessly
lost.
6. Understand everything you do. Experiment a lot. Don’t think you are done with your work
just because your assignment is done. Study and be sure to develop a healthy
intellectual curiosity!
7. When you have a good running version of your code, be certain to make a backup of
your project so that if anything “bad” happens in the future, you always have this good
copy to return to.
8. Double-check the requirements in each assignment, just before you are ready to submit
your work. And double-check what you’ve built against the requirements given in the the
software requirements specification (SRS).
9. Don’t quit! You are learning a skill that requires time and effort. The more you practice,
the easier things become. The more efficient you become, the fewer errors you will
encounter and the more fun you will have.
It is imperative that all follow these steps. If you do, you will learn a lot in this class and have a
lot of fun. We want everyone in this class to succeed. If you have any kinds of questions at all,
please contact your instructor using Ask Your Instructor or by sending a Message.
Successfully Designing and Building Software
Successfully Designing and Building Software
Systems
Following are some tips on designing and building software systems:
1. Read each assignment carefully. This is a must! Each assignment tells precisely what
the deliverables are. Implement those items and nothing more. The assignments are
“staged” so that you will incrementally get a more and more functional system, though
the workload each week is approximately the same.
2. Read and “play” with the provided skeleton app. You need to understand it well in order
to make extensions and corrections. The better you understand how the app currently
works, the easier it will be for you to make modifications and additions.
3. Allow sufficient time to complete each assignment. Most assignments take longer than
you would originally guess. So, you must allow some margin for error—which leads to
the next step. Leaving the actual programming for the weekends almost never provides
adequate time.
4. Under no circumstance allow yourself to fall behind. In programming, falling behind is
lethal! You simply cannot make up everything you should have been doing throughout
the course in the last couple of weeks.
5. Do your own work. Programming cannot be learned vicariously. It is definitely okay to
ask questions of each other—you are encouraged to do so—but do not let others do
your work for you. You will become addicted to their help and then become hopelessly
lost.
6. Understand everything you do. Experiment a lot. Don’t think you are done with your work
just because your assignment is done. Study and be sure to develop a healthy
intellectual curiosity!
7. When you have a good running version of your code, be certain to make a backup of
your project so that if anything “bad” happens in the future, you always have this good
copy to return to.
8. Double-check the requirements in each assignment, just before you are ready to submit
your work. And double-check what you’ve built against the requirements given in the the
software requirements specification (SRS).
9. Don’t quit! You are learning a skill that requires time and effort. The more you practice,
the easier things become. The more efficient you become, the fewer errors you will
encounter and the more fun you will have.
It is imperative that all follow these steps. If you do, you will learn a lot in this class and have a
lot of fun. We want everyone in this class to succeed. If you have any kinds of questions at all,
please contact your instructor using Ask Your Instructor or by sending a Message.
Clarification Week 5 Deliverable
Clarification for Week 5 Deliverable
Most recently we have been focused on learning MySQL, and we will continue this
concentration through the end of next week. But in addition, we need to maintain our
programming skills. And most learners have not been looking at “the big picture.” By the end of
Week 9 you must have implemented 100% of the functionality specified in the SRS. This
includes a Login action that functions as specified in the SRS. But everyone has been ignoring
this requirement (rightly so!) because
implementing the correct Login action hasn’t
been a requirement in any earlier week.
Therefore, this week, in addition to working on
database normalization, you will build a fully
functional Login action.
The template app provided in our course gives
you a Login action that looks like this:
The “What”
A quick check of the SRS tells you that an
employee must log in by providing a correct
username and password—not just a username.
Moreover, no functionality other than Login
should be available to a user until after the
employee user has successfully logged in. But
working on this requirement should be postponed until the other Actions and Reports have been
implemented
You need to fully implement the Login action
specified in the SRS. Your Login screen might
look something like this:
This is a snapshot of a sample Login screen just
after Steve Hutton’s username and password
were entered and the Login button was pressed.
Of course, your Login screen does not need to
exactly match this one, but it must provide the
functionality specified in the SRS.
The “How”
Now you need to consider how this functionality
might be implemented. Note that the SRS is
silent about the “how”—as it should be. So, the design of this functionality is up to you. You
need to think about what alternatives might be available:
•
You’ll need to change the existing Login screen so that the screen requests a
UserName-Password pair of items instead of only a username.
Clarification Week 5 Deliverable
•
You’ll need to update the code “behind” the Login screen so that both the UserName
and the Password are looked up in the ‘orderentrysystem’ database. You’ll need to
determine if the UserName-Password combination is or is not present in the database
and then either display information telling the user that the login attempt was successful,
or it was unsuccessful.
•
You might accomplish this using one SELECT statement that uses an AND condition, or
you might select the UserName that matches and then use code check to see if the
Password matches. There are advantages and disadvantages for each of these
approaches. And other approaches are possible.
Deliverable
For Week 5, in addition to your MySQL work, you need to submit your entire Login-updated
NetBeans Capestra project and MySQL database creation script. Of course, you’ll need to
submit some screen captures for both successful and unsuccessful login attempts.
Software Requirements
Specification
for
Capestra Furniture Order
Entry Application
Version 1.4 approved
Prepared by Capestra
August 2, 2018
Updated: July 26, 2020
Contents
1.
Introduction …………………………………………………………………………………………………… 4
1.1
Purpose ……………………………………………………………………………………………………….. 4
1.2
Document Conventions …………………………………………………………………………………… 4
1.3
Intended Audience and Reading Suggestions…………………………………………………….. 4
1.4
Product Scope ………………………………………………………………………………………………. 4
2.
Overall Description…………………………………………………………………………………………. 5
2.1
Product Perspective ……………………………………………………………………………………….. 5
2.2
Product Functions ………………………………………………………………………………………….. 5
2.3
User Types and Characteristics ……………………………………………………………………….. 5
2.4
Operating Environment …………………………………………………………………………………… 5
2.5
Design and Implementation Constraints…………………………………………………………….. 5
2.6
User Documentation ………………………………………………………………………………………. 6
2.7
Assumptions and Dependencies ………………………………………………………………………. 6
3.
External Interface Requirements ……………………………………………………………………… 7
3.1
User Interfaces ……………………………………………………………………………………………… 7
3.2
Hardware Interfaces……………………………………………………………………………………….. 7
3.3
Software Interfaces ………………………………………………………………………………………… 7
3.4
Communication Interfaces ………………………………………………………………………………. 7
4.
System Features …………………………………………………………………………………………….. 8
4.1
Action: Login …………………………………………………………………………………………………. 8
4.2
Action: Add Customer …………………………………………………………………………………….. 9
4.3
Action: Place Order ………………………………………………………………………………………..10
4.4
Report: Employee Information …………………………………………………………………………11
4.5
Report: Customer Information ………………………………………………………………………….12
4.6
Report: Order Information ……………………………………………………………………………….13
4.7
Report: Product Information …………………………………………………………………………….14
5.
Other Nonfunctional Requirements …………………………………………………………………15
5.1
Performance Requirements …………………………………………………………………………….15
5.2
Safety Requirements ……………………………………………………………………………………..15
5.3
Security Requirements ……………………………………………………………………………………15
5.4
Business Rules ……………………………………………………………………………………………..15
6.
Other Requirements ……………………………………………………………………………………….16
Capestra Furniture SRS v1.4
2
Appendix A: Glossary …………………………………………………………………………………………….17
3
1. Introduction
1.1 Purpose
An order entry application to allow employees of Capestra Furniture to create customers and
place orders into a database. The scope of this SRS is the desktop application and its backend
support system.
1.2 Document Conventions
This document follows the following conventions:
•
Bold text signifies user actions.
•
Italic text signifies existing systems outside the scope of this document.
•
Requirement statements are prioritized individually.
1.3 Intended Audience and Reading Suggestions
This document serves as a reference for all Capestra Furniture employees who have a stake in
its implementation, testing, deployment, and ongoing support, including system architects,
developers, test engineers, support engineers, operations, and legal. This document covers
multiple facets of the software application. It is recommended that it is first read end-to-end, and
then serve as a reference source.
1.4 Product Scope
The application will run on Windows desktops but can be ported to mobile devices. It will
provide a frontend to Capestra’s backend systems for the purpose of handling order entry. It will
allow employees to create customers, place orders, view employee details, view customer
details, view order details, and view product details.
4
2. Overall Description
2.1 Product Perspective
Capestra Furniture’s order entry application is a new product that will integrate with Capestra’s
third party web site. Employees will be provided support to be migrated to the desktop
application database. No orders or customers will need to be directly synced from this
application. In future releases, data from this database will be synced to the third-party website
or directly linked to the hosting database.
2.2 Product Functions
The Capestra Furniture’s order entry application will consist of the following primary features:
•
Allow the employee to log into the application and connect to the database.
•
Allow the employee to add a customer.
•
Allow the employee to place a furniture order.
•
Allow the employee to run a report displaying a list of employee details.
•
Allow the employee to run a report displaying the details about a specific customer.
•
Allow the employee to run a report displaying the details of all past orders.
•
Allow the employee to run a report displaying the details of all furniture products.
2.3 User Types and Characteristics
•
All employees will be able to access all part of the application.
2.4 Operating Environment
The application will operate on any device using JRE 8 or higher.
The application will be designed to support future versions as well through automatic updates.
2.5 Design and Implementation Constraints
The expected implementation constraints are:
•
Use Java and JavaFX for development.
•
Use NetBeans 8.2. for the IDE.
•
Use MySQL 5.7 for the database.
5
2.6 User Documentation
The user documentation will include:
•
Commented code.
•
Presentation of the final implementation.
•
Contextual help within the application.
2.7 Assumptions and Dependencies
The employee list and content will be provided from the third party in a .csv file. Capestra
Furniture will also provide a template application to expand on with documentation to explain the
application framework.
6
3. External Interface Requirements
3.1 User Interfaces
These user interfaces will be provided by the designer/developer of the application:
1.
2.
3.
4.
5.
6.
7.
Employee login screen (Partial sample provided in the template).
Add customer screen.
Place order screen.
Report screen for employee details (Provided in the template).
Report screen for customer details.
Report screen for order details.
Report screen for product details.
3.2 Hardware Interfaces
The software will work with the any OS that supports Java JRE 8. There will be no hardware
interfaces that are out of the ordinary.
3.3 Software Interfaces
•
The application will be written in Java and JavaFX and will interface directly with the
MySQL database.
•
The application will not rely on any third-party libraries beyond the Java SDK.
•
Data will be communicated to and from Capestra Furniture’s backend system using the
JDBC protocol.
3.4 Communication Interfaces
•
The application must communicate with MySQL 5.7 (not 8.0) using JDBC drivers.
7
4. System Features
The system provides a menu bar containing two drop-down menus: Action and Report.
The 3 Actions are: Login, Add Customer, and Place Order. The 4 Reports are:
Employee Info, Customer Info, Order Info, and Product Info.
4.1 Action: Login
4.1.1
Description and Priority
All employees from Capestra Furniture have an account in the web site data. All of
the employee data will be provided through a .csv file (EmployeeList.csv) for
import into the database. This feature is of high priority.
4.1.2
Stimulus/Response Sequences
The employee opens the application for the first time.
The employee is prompted for username and password to log into the system.
The employee enters his or her existing account credentials.
The employee presses the “Login” button.
The system responds telling if the credentials are valid or not.
4.1.3
Functional Requirements
REQ-1: Render login screen.
REQ-2: Validate employee username / password against the database.
REQ-3: Check with the database to determine if an account with the entered
username already exists.
REQ-4: Log the employee into the system. Display a message telling the first
name, last name, and ID of the employee who just logged in.
REQ-5: An appropriate error message must be displayed if the database is
inaccessible.
8
4.2 Action: Add Customer
4.2.1
Description and Priority
The employee should be able to add a new customer into the application to be
inserted into the database. This feature is of a high priority.
4.2.2
Stimulus/Response Sequences
The employee opens the application.
The employee logs into the application.
The employee selects “Add Customer” from the Action menu.
The employee enters in the customer’s first name, last name, email address,
address, city, state, zip code, and phone number.
The employee presses the “Add Customer” button to add the customer.
The system responds telling if the customer was added successfully or if there
was an error.
4.2.3
Functional Requirements
REQ-1: Verify the employee has logged in.
REQ-2: Verify that the customer was successfully added.
REQ-3: Validate that all of the input fields have been entered.
REQ-4: The successful insertion confirmation message must include the name of
the customer that was added.
REQ-5: Display any errors (like missing fields) in an appropriate fashion; e.g.,
beside each input field or above all of the input fields.
REQ-6: All input fields should be cleared if and only if the insertion was
successful.
REQ-7: A customer must not be added if there already is a customer with the
same first name and last name in the database. In this case an appropriate
message must be displayed.
9
4.3 Action: Place Order
4.3.1
Description and Priority
The employee should be able to place an order for a customer who either calls in
or is done in person into the application to be inserted into the database. This
feature is of a high priority.
4.3.2
Stimulus/Response Sequences
The employee opens the application.
The employee logs into the application.
The employee selects “Place Order” from the Action menu.
The system displays a list of customers in a drop down.
The system displays a list of products in a drop down.
The employee selects a customer and product.
The employee enters the desired quantity of products to order.
The employee presses the “Place Order” button to place the order.
The system responds telling if the order was added successfully or if there was an
error.
4.3.3
Functional Requirements
REQ-1: Verify the employee has logged in.
REQ-2: Check that there is enough quantity of the product to be ordered. If not,
raise an exception, otherwise, continue.
REQ-3: Insert a record in the order table to include in the customer ID, employee
ID who is logged in, date of the order, and the order status (pending, delivered)
REQ-4: Insert a record in the order_detail table to indicate the order ID, product
ID, and quantity.
REQ-5: Update the product table to deduct the number of items ordered.
REQ-6: Display any errors either beside each input field or above all of the input
fields.
REQ-7: Validate that all of the input fields have been entered. The quantity must
be a valid integer greater than zero.
REQ-8: All of the database statements must execute in a database transaction.
REQ-9: All input fields should be cleared if the transaction was successful.
10
4.4 Report: Employee Info
4.4.1
Description and Priority
The system should display a list of current employees. This feature already has
been implemented in the template.
4.4.2
Stimulus/Response Sequences
The employee opens the application.
The employee logs into the application.
The employee selects “Employee Information” from the Report menu.
The system responds by displaying the list of employees. The information
displayed must include employee ID, first and last names, and email address.
4.4.3
Functional Requirements
REQ-1: Verify the employee has logged in.
REQ-2: Display an appropriate message if there are no employees.
REQ-3: All employee information must be displayed in tabular form.
11
4.5 Report: Customer Info
4.5.1
Description and Priority
The system should display full details about the specified customer. This feature is
of a high priority.
4.5.2
Stimulus/Response Sequences
The employee opens the application.
The employee logs into the application.
The employee selects “Customer Info” from the Report menu.
The employee selects a customer from a drop-down list showing all current
customers (sorted by first name).
As soon as the employee selects a specific customer, the system displays all
details about the specified customer including id, first name, last name, address,
city, state, zip, phone, and email address.
The employee can then select a different customer from the drop-down list and
see the details about the newly selected customer.
4.5.3
Functional Requirements
REQ-1: Verify the employee has logged in.
REQ-2: Display an appropriate message if there are no customers or if no
customer has been selected.
REQ-3: Customers are selected using a drop-down list.
REQ-4: Display full details about the specified customer.
REQ-5: The customer selection drop-down should remain available during the
display of the customer information, being shown just above the customer details.
12
4.6 Report: Order Info
4.6.1
Description and Priority
The system should display a three-part screen including: (a) List of all customers;
(b) List showing details of all orders; (c) List of all products and categories. This
feature is of a high priority.
4.6.2
Stimulus/Response Sequences
The employee opens the application.
The employee logs into the application.
The employee selects “Order Info” from the Report menu.
In the top table, the system displays all customer details including first name, last
name and all contact information for the customer, ordered by customer’s last
name.
In the middle table, the system displays the details of all orders including order ID,
date, status, customer ID, employee ID, customer first and last name, address,
city, state, zip, email, product ordered, and quantity ordered.
In the bottom table, the system displays all categories and their associated
products, as well as their full descriptions and the unit price for each product.
4.6.3
Functional Requirements
REQ-1: Verify the employee has logged in.
REQ-2: Display an appropriate message if there are no customers..
REQ 3: Display an appropriate message if there are no orders.
REQ 4: Display an appropriate message if there are no categories or products.
13
4.7 Report: Product Info
4.7.1
Description and Priority
The system should display a list containing full details about all products in
inventory. This feature is of a high priority.
4.7.2
Stimulus/Response Sequences
The employee opens the application.
The employee logs into the application.
The employee selects “Product Information” from the Report menu.
The system displays a list showing full details about all products in inventory
including their categories, names, descriptions, prices, and quantities on hand.
4.7.3
Functional Requirements
REQ-1: Verify the employee has logged in.
REQ-2: Display an appropriate message if there are no products.
14
5. Other Nonfunctional Requirements
5.1 Performance Requirements
The order entry system needs to be fast. This will require the SQL statements to be optimized
and the database design to be set up in third normal form.
5.2 Safety Requirements
The application has no special safety requirements.
5.3 Security Requirements
All communications need to be properly authenticated.
Because the application interfaces with other systems, it need to be able to handle errors and
failures gracefully, with sensible re-try logic and clear messaging for the user.
Capestra Furniture is intending to expand this application in the future. Therefore, the
application needs to be designed with componentization and reusability in mind.
5.4 Business Rules
Employees can login, add customers, place orders and view reports. This application should
simulate the business processes. An employee can add new customers. When an employee
places an order, the order should be associated with the employee. An order should have order
line items. Although in this first iteration only one product can be added in an order, future
iterations will allow multiple items per order. The database design should take this into
consideration. Users can order multiple quantities of the same product. Each product belongs to
a single category.
15
6. Other Requirements
The application needs to have locally-managed storage.
The backend system will interface with Capestra Furniture’s MySQL 5.7 (not 8.0) database
server.
The backend system will communicate with the MySQL database using a JDBC driver.
The application needs to be in English, but designed with internationalization in mind for future
versions.
The minimum tables that are required for the database include:
•
Customer (consists of customer related information including first name, last name,
email address, address, city, state, zip code and phone number).
•
Employee (consists of employee information; table data is provided in
EmployeeList.csv).
•
Order (consists of high-level order information such as the order date, the customer who
ordered it, and the employee who entered it into the system).
•
Order Details (links the order and product tables together; includes the quantity of
products ordered).
•
Product (product information including the product name, description, price, and quantity
currently available).
•
Category (list of the categories for the furniture products).
16
Appendix A: Glossary
•
API: Application Programming Interface. A definition and implementation of a layer that
exposes and provisions certain services to external systems (such as client
applications).
•
LAN: Local Area Network. A network of a group of related computers and other devices
(usually within a home or an office).
17
Purchase answer to see full
attachment
Why Choose Us
- 100% non-plagiarized Papers
- 24/7 /365 Service Available
- Affordable Prices
- Any Paper, Urgency, and Subject
- Will complete your papers in 6 hours
- On-time Delivery
- Money-back and Privacy guarantees
- Unlimited Amendments upon request
- Satisfaction guarantee
How it Works
- Click on the “Place Order” tab at the top menu or “Order Now” icon at the bottom and a new page will appear with an order form to be filled.
- Fill in your paper’s requirements in the "PAPER DETAILS" section.
- Fill in your paper’s academic level, deadline, and the required number of pages from the drop-down menus.
- Click “CREATE ACCOUNT & SIGN IN” to enter your registration details and get an account with us for record-keeping and then, click on “PROCEED TO CHECKOUT” at the bottom of the page.
- From there, the payment sections will show, follow the guided payment process and your order will be available for our writing team to work on it.