CS 6400 Spring 2022 GameSwap
web | 代写app | 代做java | project代做 | STA | sql代写 | php代写 | database – 这道题目是利用java进行的编程代写任务, 涉及了web/app/java/STA/sql/php/database等代写方面, 该题目是值得借鉴的project代写的题目
CS 6400 Spring 2022
GameSwap
project Overview
The purpose of this project is to analyze, specify, design, implement, document, and demonstrate an app your team develops. The project will proceed in three phases as outlined in the Classical Methodology for database Development: Analysis & Specification, Design, and Implementation & Testing. The system should be implemented using a fully relational, distinct (separate from your application) Database Management System (DBMS) that utilizes tables and supports standard sql queries. Under no circumstances may you use a tool that automatically generates SQL, automatically maps programming objects into the database, or a non-tabular system that utilizes SQL as a data manipulation language. We will provide further details regarding acceptable project stacks separately.
The three phases of the project cover the following work-processes from the Classical Methodology for Database Development. The due dates and details of what must be submitted for each phase will be available on Canvas.
When reading through this project description, please make the following assumptions: unless otherwise specified
as optional, all attributes are required; that you should create normalized schemas, and minimize the use of NULL
attributes whenever and wherever possible; ensure that you store non-numeric data that appear as numbers (such
as street numbers, phone numbers, postal codes, etc.) as strings and not numeric data types; the word date
means only the date is stored, while date and time means storing both date and time; any dates displayed must
include month, date, and year; if a sort order is not specified as ascending or descending, then ascending order is
implied; and avoid catch-all forms with unnecessary inputs that the user would leave empty or NULL. In addition,
your users will not utilize the system at the same time, so you do not need to be concerned about handling
concurrent operation that could conflict and introduce inconsistencies in your database. This spec contains a
functional description along with some screen mockups. The user interfaces depicted in this project description
serve as examples to guide your thinking and are not intended to capture all functionality as described. Your
projects interface may look completely different and that is fineeven encouraged! For example, you might
choose to split up some interfaces we have shown on a single screen into multiple screens. You might choose to
use popup windows instead of refreshing the page. A complete reorganization of the user interface is acceptable
providing your application supports the same functionality as described below. You may implement the project as
a traditional standalone application (e.g., java GUIs or Pythons TkInter) or as a web application (e.g., web scripting
languages like php or JSP). Your project is not graded on its aesthetic appeal, but on its functionality.
Do not create any additional functionality that is not mentioned in this specification (such as email notifications,
etc.) or attempt to enhance your final product beyond what the specification requires. Adding unwanted
functionality can and will impact your grade!
Overview
In recent years, the sales of board games, video game systems, and other home entertainment activities skyrocketed. Today, many people find themselves with a surplus of games and other items. GameSwap is a bartering website for trading these items. Initially, it will be limited to some specific types of items and is intended for making local trades, although users who are not located close to each other might figure out shipping details on their own.
Definitions
This section provides some basic details about the things and their properties that the system tracks. Note that some operational attributes may not be mentioned as they might not be an essential property of something. Pay close attention to the functionality section as it may imply operational attributes that may need to be included in your design.
At the core of GameSwap are users. Users will self-register and the following details will be collected from them:
- Password o If desired, the password may be encrypted for storage, but this is not required in this initial version of the application.
- First name
- Last name
- Nickname (for display purposes)
- City, state, and postal code o A listing of postal codes, with city, state, and their central latitude & longitude will be provided and could be used to allow users to select only their postal code or to validate their entry. o This listing of postal codes will not change, and you do not need to worry about updating it. o A short sample listing of postal codes is below to provide some basic understanding of what their data will look like.
Postal Code City State Latitude Longitude
55302 Annandale MN 45.246631 – 94.
20227 Washington DC 38.893311 – 77.
14043 Depew NY 42.904958 – 78.
15278 Pittsburgh PA 40.434436 – 80.
24062 Blacksburg VA 37.174227 – 80.
02472 Watertown MA 42.371296 – 71.
07309 Jersey City NJ 40.73276 – 74.
00623 Cabo Rojo PR 18.08643 – 67.
53031 Hingham WI 43.639395 – 87.
60651 Chicago IL 41.901485 – 87.
57440 Frankfort SD 44.857069 – 98.
72714 Bella Vi STA AR 36.458041 – 94.
99671 Stebbins AK 63.511893 – 162.
97304 Salem OR 44.970181 – 123.
81624 Collbran CO 39.220166 – 107.
82718 Gillette WY 43.939968 – 105.
89317 Lund NV 38.835421 – 115.
92232 Calexico CA 33.026203 – 115.
30334 Atlanta GA 33.702657 – 84.
36879 Waverly AL 32.733511 – 85.
- Phone number (optional) o The phone number itself (formatted as XXX-XXX-XXXX) o Phone number type: limited to the choices of home/work/mobile o Share phone number on swaps: yes/no
An email can only be registered once in the system. Nicknames do not have this requirement. A phone number can only be registered to a single user. The system will not require forgot password or password reset functionality.
The GameSwap system also tracks items that will be swapped. For all items, the following details are input:
- The title/name of the item (name and title may be used interchangeably to describe this attribute)
- The items game type (one of the following, along with the specific details listed for that type) o Board game o Card game o Video game Platform: limited to the choices of Nintendo, PlayStation, or Xbox. This list of values should be updatable in the database (it is not necessary to update this list in the UI). Media: limited to the choices of optical disc, game card, or cartridge o Computer game Platform: limited to the choices of Linux, macOS, or Windows o Jigsaw puzzle Piece count
- Condition: limited to Mint, Like New, Lightly Used, Moderately Used, Heavily Used, or Damaged/Missing parts
- User-entered description (optional)
When an item is listed, it is assigned an item number by the system, which is an ordinal based on when the item was input (for example, the first item in the system would be assigned item number 1, the second assigned 2, and so on).
Users that have listed items will be able to swap items with each other. Items associated with a pending swap (a proposed swap not yet accepted or rejected) are not available for swapping, as are items associated with completed swaps. For obvious reasons, a user cannot swap items with themself, and a user with no listed items may browse items but cannot swap. For clarity and convenience, the user proposing a swap is called the proposer and the user receiving the proposed swap is called the counterparty. A proposer will request a swap with a proposed item for one of the counterpartys items (called the desired item). The date the proposal is made will be stored. The counterparty will then accept or reject the swap, with the date of acceptance or rejection also stored. If a swap is rejected, that specific item-for-item swap cannot be proposed again. If a swap is accepted, the counterparty will see the contact information for the proposer, so that they may communicate and determine how to physically swap items. To mark the swap as completed, after swapping items, both users must rate each other, on a scale of 0-5. Items that have been swapped cannot be swapped again, however, a user can enter the item into the system as a new item listing (which may have different/new information, such as an updated condition or description) for another swap.
Functionality
When initially accessing the application, all users should be directed to the login form.
Login
Users will login with an email or phone number, and password. A register link should also be provided on the login form. If the email or phone number for the user is not registered, or the username/phone number is registered, but the password is incorrect, present an appropriate error message to the user.
User registration
Main menu
After logging in or registering, all users will be taken to the main menu. To make them feel at home, you should have a
welcome message at the top of the menu that includes the users first and last names. Several statistics will also be displayed: the number of proposed swaps the user has received, which, if greater than zero, links to the accept/reject swap form (if any swaps are more than five days old, or the user has more than five unaccepted swaps, this number should be printed in bold and in red); the number of unrated swaps the user has not yet rated, which, if greater than zero, links to the swap rating page (if greater than 2, this number should also be printed in bold and red); the users current rating average, rounded to hundredths (or None if no ratings have been made for them). In addition, appropriate links to the following functions must be provided: Listing an item; showing a list of the users items; searching for items; swap history; and updating the users information. Most importantly, a logout option should be on this screen which logs the user out and returns them to the login form. (For user convenience, you may provide a logout option on all forms, but it is not required.)
Listing an item
This page will be used to collect the information needed for listing an item. If a user has more than two unrated swaps, or more than five unaccepted swaps, they cannot list a new item and an appropriate message should be displayed. You should ensure that only the fields needed for the chosen game type are displayed, for example, a card game would not need the fields required for a video game, and so on. In this example, the form is configured for listing a jigsaw puzzle. Any errors should be indicated with an appropriate error message. Once the item is saved, the item number
should be assigned by the system and a success message showing the item number should be displayed to the user.
My items
This form will display any items listed by the user that are available for swapping. The top of the form should show the count of items for each game type, along with the total of items. The listing should include item number, game type, item name/title, the condition, and the first 100 characters of the description (if the description is greater than 100 characters, place an ellipsis […] at the end to indicate it has been truncated), sorted by item number ascending. A detail button or link should be provided which allows loading items specific details (viewing item details will be covered
further on in this spec).
Searching for items
This form will allow the user to search for items by various criteria. The following search options should be provided:
- By keyword (matching any string in either the name/title or description)
- Within the users postal code
- Within X miles of the user, where X is a user-entered whole number, utilizing the coordinates provided with the postal codes o For example, if the user enters 5, then anything with <=5 miles would be returned. o To determine the distance between postal codes, the haversine formula can be used to calculate the straight-line distance between two points. The formula is provided below (additional details can be found at http://www.movable-type.co.uk/scripts/latlong.html, along with examples for utilizing it in database queries). Note that latitude and longitude are expressed in degrees, which must be converted to radians for these calculations, the Earths radius (approx. 3958.75 mi) should be used for R.
- Within a specific postal code entered by the user o If the postal code entered is invalid, an appropriate error message should be displayed instead of no search results.
These search parameters are exclusive, that is, you are not required to support combinations of the different options. Only items available for swapping should be included in the search results. If the search yields no results, the message
Sorry, no results found! should be displayed and the user returned to the search form.
The search results forms title and header should indicate what type of search has been executed. The search detail should show the item number, game type, item name/title, the condition, the first 100 characters of the description (if the description is greater than 100 characters, place an ellipsis (…) at the end to indicate it has been truncated), and the distance from the user (rounded to tenths), sorted by distance and item number ascending. If performing a keyword search, then the field(s) that matched the keyword should be highlighted with a blue background in the search results. A detail button or link should be provided which allows loading items specific details (viewing item details will be covered further on in this spec).
View Item
This form will be accessed from many other forms and displays different elements depending on the context. All details for the item must be shown: item number, title/name, any type-specific attributes, and the description. If no description exists, then the field should not be displayed. In this example, a video game is being viewed.
If the item belongs to another user, then their nickname, city, state, postal code should be displayed along with their swapper rating, rounded to hundredths (defaulting to None if no ratings exist) and their distance from the user, rounded to tenths, unless they are in the same postal code, in which case the distance should not be displayed. If the distance is between 0.0 and 25.0 miles, it should be highlighted with a green background, if between 25 .0 and 50. miles, highlighted with a yellow background, between 50.0 and 100.0 miles, highlighted with an orange background, and if over 100.0 miles, the background should be highlighted red. If the current user does not have more than 2 unrated swaps, or more than five unaccepted swaps, and the item is available for swapping, a Propose swap option should be displayed.
Proposing a swap
This form will allow a user to select which of their own items they would like to propose to the counterparty for the desired item. If a user has more than 2 unrated swaps, they cannot propose a swap and should not be able to reach this form. If the counterparty is >= 100.0 miles from the user, a warning message containing that distance should be shown at the top of the form. The desired items title should be displayed. An appropriate mechanism for choosing the proposed item should be provided, such as a listing with a selector, a list box, a dropdown list, etc. The list for choosing the proposed item should show item number, game type, title, and condition, ordered by item number, and must only display items that are available for swapping. Once the proposed item is chosen, the user must be provided with a button or mechanism to confirm the proposal. Once confirmed, the date the proposal was made is stored in the
database. A confirmation message should also be displayed, which will allow the user to return to the main menu.
Accept/reject swaps
This form will list proposed swaps where the user is the counterparty so that they may accept or reject them. For each proposal, show the date proposed, desired items title, proposers nickname, their rating (rounded to hundredths), distance from user (rounded to tenths), and proposed item title, ordered by proposal date. Both item fields should link to the items detail page, and an accept/reject mechanism should be provided.
If the swap is accepted, display a dialog with the proposers email, first name, and phone number/type, if available and if sharing option is set. (If phone number is available, but not shareable, it can also be displayed as not available.)
The acceptance/rejection date of the swap should be recorded in the database. If rejected, a new swap for the proposed item and desired item cannot be proposed again. Accepting a swap removes it from the listing, and if no more swaps need to be accepted or rejected, the user should be returned to the main menu.
Rate swaps
This form will be used to rate the other user in the swap after the swappers have traded items. For any unrated swaps, show the swap acceptance date, the users role in the proposal (proposer or counterparty), proposed item title, desired item title, other users nickname, and rating choice (0 5), ordered by acceptance date descending. The item titles on this form do not need to link to the item detail form.
Choosing a rating will record it in the database and remove the swap from the list. If no additional swaps need rating, return the user to the main menu.
Swap history
This form will display to the user their history of all swaps. At the top of the form should be a summary, showing the logged in users total swaps proposed, total received , subtotals for accepted and rejected, and % rejected, rounded to tenths (if >= 50 .0%, highlight in red).
Next, a listing of all swaps is displayed, which will include swap proposed date, swap acceptance/rejection date, swap status (accepted or rejected), users role in proposal (proposer or counterparty), proposed item title, desired item title, other users nickname, and for accepted swaps, the rating that the user gave to the other user (if not rated, you should allow a rating to be submitted, and refresh/update the form after submission), sorted by acceptance/rejection date descending and swap proposed date ascending. A detail link or button should be provided so that the swap details form can be loaded for a listed swap.
Swap details
This form will show all the details of the selected swap (proposed date, accepted/rejected date, swap status, swap type) and the rating that the user gave to the other user (if not rated, you should allow a rating to be submitted, and refresh/update the form after submission). It will also display the other users nickname, distance, and if an accepted swap, their contact details (first name, email, and phone number/type if available and sharing option is set), and details
for both items (like the item details screen, it should include all attributes for the items).
Update user information
This is the same as the user registration form but meant for existing users to update their information. If a user has any unapproved swaps (as proposer or counterparty), or unrated swaps, they cannot make any updates and should be shown a suitable message when they attempt to access this form. The only item that a registered user cannot update is their email address. If a user attempts to change their phone number, but it is already in use by another user, an appropriate error message should be displayed.