CHC5054 网络应用开发

Web Application Development: Coursework
Allocation
This coursework is worth 100% of the marks for module CHC5054.
You will also need skills from the following modules:
● CHC4008 (Python Programming)
● CHC4007 (Design reporting)
● CHC5049 (Database design)
● CHC5226 (Secure implementation)
Specification
Your task is to develop and test the full stack for a simple web application that allows users to
buy and sell various things of different categories.
• Buyers can create accounts with a username, password, address, email, phone number
and buy one or more products, like or dislike it, post comments, and read comments
other buyers have posted.
• The vendors also have accounts with username, password, email, address and also
phone number, they add their products with the quantity and the price.
The products are divided into categories containing products from the same type has a name,
description, price, vendor name, number of likes/dislikes, user’s comments and an “add to
cart” button
The following is the basic functionality to implement:
● On visiting the first page of the site, the user must see a list of products and
categories.
● Clicking on a category should display all products related to that category, with the
most recently updated (newly posted or with new comments and likes/dislikes) at the
top.
● Clicking on a product should show the product page including all its information
(name, picture, description, price, vendor name)
● The product page should also contain number of likes/dislikes, users’ comments with
their usernames, date, time of the comment.
● An “add to cart” button for when the buyer wants to buy the product with two buttons
+ and – to specify the quantity, the buyer can after that check other products or
proceed to the cart page.
● The cart interface should display the different products added by a buyer, quantity and
price for each product and the total price, after confirming payment with WeChat Pay
or AliPay a notification will be sent to vendors on to ship these products.
● When a vendor receives a buying notification on the website, he will ship the product
desired to the buyer, a notification is then sent to the buyer in the website containing
the tracking and the date of arrival.
● A vendor can add products with their information to his account and can add a
promotion, the new price and its duration.
● A history of different purchases should be saved for each user including the time, date,
product name, and the price.
● A user (either buyer or vendor) must be able to create an account, giving a username
and password.
● A user must be able to log into an existing account with the correct combination of
username and password.
● The user interface to register an account or log in can be either a separate page or an
overlaying box in the corner of each regular view page which appears only when a
button is clicked.
● Users cannot buy or sell products unless they are logged in. (But they can view
products)
● Comments should be viewed by all users, with their date and time.
● All users can post comments on a product.
● Data must be stored in an SQL database.
● The site should not be vulnerable to SQL, JavaScript (XSS) or HTML injection.
● The user interface should be of a standard suitable for a modern web application.
● The application should meet reasonable standards for accessibility on desktop
platforms.
The marks available for each of these areas of functionality are divided based on the sections
of the coursework, as described below. Simply writing code to meet the specification by any
means will not earn full marks.
Restrictions
Your web site must run in a Python virtual environment built by running the following
commands from a Command Prompt in a suitable working directory:
pip install virtualenv
virtualenv webtest
cd webtest
scripts\activate
pip install flask mysql-connector-python
It is recommended that you also use this virtual environment for development. Regardless,
you must test your site within the virtual environment before submitting it. This is the virtual
environment in which your code will be tested by the assessor. If it does not work, marks will
not be awarded.
In addition to the libraries in the above virtual environment, you may use the jQuery library
for JavaScript, but may not use any other frameworks or libraries. This means that you
may not use libraries that are “Flask extensions” if they are not installed with Flask.
(Please do not send e-mails asking if you can use other extension libraries; the answer is no.
The purpose of the coursework is to understand how JavaScript and server interaction work at
the lowest level possible, not in terms of abstractions created by higher level code.)
Your website must be built using HTML 5 and ECMAscript 6 on the client, and Flask,
MySQL (or SqLite) and Python 3 on the server.
Plagiarism
This is individual work. You must not copy or share code with other students. Do not copy
code from online sources, answers, tutorials or existing open-source e-commerce software.
Copied code will result in the plagiarism process being invoked and you may be asked to
attend an online meeting to verify that your understanding of your code is consistent with you
having written it.
You must be very careful with the use of online tutorials on this module. Your primary
learning source should be the module notes and the lecturer and tutorial staff. There are a very
large number of online tutorials on the topic of web development, but many are incorrect, outof-date, or badly written.
Sites which present code and then explain it are often cheating sites, not tutorials.
Retroactively explaining large amounts of code is not an effective learning method, but is
often used as a trick to “justify” presenting code actually intended to be cut and pasted. Often
the explanations are extremely poor or even incorrect and will confuse your understanding
further.
Submission
Submission is in three stages:
● a preliminary report
● the actual website
● a final report
Due Date: Preliminary report: 31st march 2023 (week 6)
Website: 5th April 2023 (week 11)
Final report: 12th April 2023 (Week 12)
The preliminary report is worth 20% of each component of the marks from the Specification
section. The implementation is worth 60%, and the final report is also worth 20%.
Code implemented in the final submission but not reported on in the actual report can still
score full marks on the other two components, but you will lose out on potential feedback on
your report.
The final report may refer to sections of code that were not implemented, but it will likely not
be possible to write the report well without having implemented those sections.
Preliminary Report
The preliminary report should cover the design and structure of implementation you intend to
use to produce the selected functionality. This should include:
● the division of functionality between client and server (in this context the “client”
means the web browser and JavaScript code, not the human user);
● wireframes representing the user interface;
● an overview of the intended implementations at client and server.
Website
The website should be uploaded as a .zip file to the student website by (Date to be
announced). To prepare your .ZIP file, do the following steps:
1. Prepare a fresh virtual environment via the commands described in the “restrictions”
section.
2. Copy your website files into the virtual environment, activate it, and ensure that your
website works inside it.
3. Use the mysqldump utility to output your database specification into a file in the
virtual environment. (The mysqldump.exe file is in the bin directory of the MySQL
Server install path.)
4. Delete the directories Include, Lib, Scripts, and tcl.
5. ZIP the virtual environment directory.
The 60% of the section mark for the website is divided as follows:
● The basic functionality (working organization, buying, selling, reading, liking,
notifying and login): 30%.
● Quality of user interface design: 10%.
● Quality of back-end architecture: 20%.
Remember to break down processes in detail to allow these to be described. “The user can
click to login” is not sufficient detail - the process of logging in is a multi-stage one that will
likely involve several communications between the client and server, and use of the database.
It is not necessary to include source code in the report. The report will be your main
opportunity to gather feedback before the submission (although you may also ask for help in
practical sessions) so make sure to provide detail on any decisions you are not sure about, so
that the assessor can provide useful feedback.
The preliminary report should be submitted on the student website by (5
th April 2023). You
may have already started developing your implementation before this submission.
Final Report
The final report should be no longer than 6 sides of A4 at standard font size, and should
address the following issues:
Describe the accessibility measures added to your site and who they are intended for. The
measures must be documented in WCAG as correct ways to increase accessibility. You could
also describe any additional accessibility features that might be added with more development
time. Note that the absence of inaccessible features that could never be relevant to the site
(such as video) cannot be listed here and is not worth any marks. (2.5%)
Describe how you would adapt your site for mobile phone users. You do not have to write
actual changes to the CSS, HTML, or JavaScript, but you should describe the changes you
would make and the means by which they would adapt the site. It is not acceptable to write
that you would replace your site with an app, (5%)
Describe how you have tested your site. This should include a formal test plan and results as
covered on previous programming and software engineering, and any fixes you made. This
should include testing both the functionality and accessibility of your site. You should also
test that your site works when multiple sessions interact with it at once, by using multiple
browsers at once on your computer. (10%) Note: if you present your test plan and results in a
table, lines and extra space taken by that table do not count against the limit of 6 sides of A4.
Choose one of the major JavaScript frameworks such as ReactJS, Bootstrap or Angular,
and research it only. Describe how you would modify your site to work within this framework
and what difference it would make to implementation of your site. Note that your description
must be specific to your site - a general description of the framework will score no marks.
(2.5%)
The final report should be uploaded to Student Website by (12th April 2023).
Overall Mark Scheme
Basic
functionality
Initial Report 20%
General Implementation 30%
User Interface 10%
Back-End
Implementation 20%
Final Report 20%
Component total 100%
Tips
Using the lecture material
The lecture material and practical’s do not directly walk you through the coursework, but it
can be completed by applying the skills they teach.
● Session 7 will help you think about designing your database. The specification
includes users, categories, products, comments. Think about what needs to be stored
about each one and how they relate to each other, and what data needs to be stored
about the relationships.
● Think about database transactions - what is the list of actions that the user can take
that alter the database? How can you write each one as a query? Think back to
CHC4007 and consideration of use cases.
● What input does each transaction need, and how can you get that from the user over
the web? Sessions 1-4 will help here.
● How will you send the input to the server? First, in what form? How can you make it
easy for your program to work with but also secure? Again, see sessions 1-4. Second,
how will you actually send it over the web? See sessions 5 and 8 for your options.
● Can you now write the Python program for the transaction and assign it to be a Flask
route? See sessions 5 and 6 as well as general Python programming from CHC4007.
● How will you return the response to the user? Will you use a web template (session 6)
or maybe a JavaScript program that reads from the server using AJAX (session 9)?
● Is the transaction “stateful” - meaning that it changes the treatment of other
transactions after it, such as logging in? If so, what do you need to store in the Flask
session variable (session 6) to allow this?
Previous Common Errors
Here are some previous mistakes frequently made by students on Web Development
coursework. Please be careful not to repeat them!
Preliminary report
● Repeating what is stated in the specification as if it was your decision rather than what
you have been told to do.
● Telling the story of how a function will be implemented rather than how the
implementation will work.
● Failing to break down tasks into client and server components or attributing all of a
multi-stage task to one of these; for example “the buyer logs into the site” which
actually requires multiple steps and cannot be purely done on the client.
● Describing what is stored on the client or server, but not what functionality they have.
● Over-emphasising the choice of technologies, rather than how they are used.
● Writing many-to-one relationships with the foreign key on the wrong side.
● Trying to store foreign keys to two different tables in the same field without
distinguishing them.
● Not showing data table descriptions, only sample data that does not formally indicate
structure.
● Omitting field types from specifications.
● Stating that the “user will be logged in” without indicating what method is used to
signal this.
● Large amount of dead space on UI designs.
● Showing UI prototypes instead of wireframes.
● Where search is implemented, not providing a wireframe for the search results page.
● Saying that administration will be implemented but not indicating what functions will
be available to administrators.
● Where administration is implemented, not providing a wireframe for the
administration page.
● Where AJAX is used, not providing a structure for the JSON messages that will be
used.
Web site
● Using unauthorized libraries.
● Failing to implement all basic functionality.
● Functions on the server that require the user to be logged in don’t actually check that
the user is logged in, for example “add to cart” can not add the product unless the
seller is logged in.
● Storing passwords in cleartext in the database.
● Making the database or on-screen fields for a comment text too short for messages to
be entered.
● Duplicated data in the database, violating normal form.
● Missing or redundant foreign keys in tables.
● Search only offers first (basic) part of exercise.
● Search loads entire table and searches it in Python rather than using SQL database
search.
● Can only search exact, not partial, matches.
Final Report
● Listing the general principles of mobile friendliness, framework features, etc. but not
how they would be used on this particular site.
● Testing complete functionality paths instead of individual interactions. While testing
paths is a good idea, remember that users may not follow them; web requests can be
sent in any order as a result of shared links, the back button, etc.
● Not testing edge, exceptional or error cases.

  WX：codehelp