ITD121辅导、Java/Python程序辅导

日期：2022-10-07 07:46

ITD121 Programming Principles
Semester 2, 2022
Object-Orientated Design and Implementation
Part A (10%): due 23 Sep 2022
Part B (40%): due 28 Oct 2022
Assessment Type: Individual or Pair
Task
This assignment aims to give you experience working on a simplified but realistic problem,
similar to what you will encounter in the workplace.
In this assignment you develop a prototype Auction House system which allows people to
advertise, place bids for, and sell products. The system represents a minimum viable
product which is not expected to include all aspects of the final working solution. Examples
of functionality which would be required in a full product but which are outside the scope of
the present task are: reports for administrative or promotional purposes; client sales
history; auction house commission; sales tax; recommender subsystem.
Your task is to apply object-oriented design and programming techniques to create a welldocumented and easy to maintain software solution that achieves the user stories listed
below, showcasing best-practice application of the software engineering principles and
techniques covered in Topics 6 through 10 of the unit.
Part A User Stories
1. Story: As the proprietor of the Auction House I want to the system to provide a simple
text based user interface so clients will find it easy to use the system and it will be easy
for me to test the system.
Acceptance Criteria:
When the program starts, a Main Menu dialog is displayed, with options that
allow the user to (1) Register, (2) Sign In, or (3) Exit.
The user is required to supply a validated numeric value in the range 1–3, and
the system takes subsequent action as appropriate.
All subsequent actions apart from Exit will be mediated by similarly structured
menus, or by “question/answer/validation” style dialogs.
When Exit is selected, the program terminates gracefully.
Other selections are dealt with as indicated in the following stories.
2. Story: As someone interested in buying or selling products I want to register as a client
with the online auction house so I can conduct business in the auction house.
Acceptance criteria:
A Registration dialog (available as an option on the Main Menu) allows the user
to enter their name, email address, and password.
Name, email address, and password are validated according to criteria set out in
Appendix 1, items 1–3 respectively.
Email address must not be the same as any existing email address.
Client email address and password are preserved in the system for later use.
System must allow at least 100 clients to be registered simultaneously.
After registration is complete, control returns to the Main Menu.
3. Story: As a client I want to use my existing email address and password to authenticate
myself with the system in order to access my private records and conduct transactions.
Acceptance criteria:
A Sign In dialog (available as an option on the Main Menu) allows the user to
enter email address and password to sign in to the system.
If the email address and password match those of an existing client, the program
advances to the Client Menu dialog.
If the supplied credentials do no match those of any existing client, then an
informative message to that effect is displayed.
In either event, control subsequently returns to the Main Menu.
4. Story: As a client I want to be able to log out from the system so that the next person to
use the system cannot access my private records or conduct transactions using my
account.
Acceptance criteria:
A Log Out option is available in the Client Menu.
When selected, control returns to the Main Menu.
The user must re-authenticate to access their previously entered information.
5. Story: As the proprietor of the auction house I need all registered clients to provide their
name and home address the first time they sign in so that products purchased through
the auction house can be collected and delivered.
Acceptance criteria:
The first time a client signs in, a Personal Details dialog is presented to collect
their name and home address.
Home address is validated according to the rules set out in Appendix 1, item 3.
Once the home address has been recorded, and on all subsequent sign-ins, the
client progresses to the Client Menu dialog to conduct business.
6. Story: As the proprietor of the auction house, I want the system to automatically save
the list of clients (together with their advertised products and details of any bids they
have placed on products) before the system closes, so client information will be
available for subsequent processing.
Acceptance criteria:
All client data that has been entered into the system is saved to a text file in a
suitable format, either immediately when it is accepted by the system, or when
the system shuts down.
7. Story: As the proprietor of the auction house, I want the system to automatically load
the list of clients (together with their advertised products and details of any bids they
have placed on products) when the system starts, so client information will not have to
be re-entered if the system powers down.
Acceptance criteria:
Client data (including all clients, products, and bids) from previous sessions is
available when the system starts.
Part B User Stories
8. Story: As a client I want to advertise products in the auction house so I can sell them to
make some money.
Acceptance criteria:
A Product Advertisement dialog (available as an option on the Client Menu)
allows the client to add a new product to their list of advertised products.
Product information is validated according to the rules set out in Appendix 1,
item 6.
The system must permit at least 100 products to be advertised by each client.
9. Story: As a client I want to be able to display a list of all my currently advertised products
with information about bids that have been placed on each, if available, so I can see
what stock remain to be sold.
Acceptance criteria:
A Product List dialog (available as an option on the Client Menu) displays all
products advertised by the currently logged in client.
If no products have been advertised, an informative message to this effect is
displayed is displayed to notify the user there are no matching results.
Products are displayed in a tabular form, with one product per row. Rows of the
product list are numbered consecutively, starting at 1.
In addition to the row number, each row contains the product name,
description, and price. If a bid is present, then details of the bid are displayed in
a further set of three columns. Bid details consist of the name and email address
of the highest bidder, and the amount of the highest bid. If no bid is present,
then a place-holder consisting of a single ‘-‘ (minus sign) appears in each column
reserved for bid details.
The information is displayed in a single row, with fields separated by tab
characters.
Products should be ranked in ascending order by name, then description, then
price.
After the list is displayed, control returns to the Client Menu.
10. Story: As a client I want to be able to use a search phrase to locate products that have
been advertised for sale, so I can find products I might want to buy.
Acceptance criteria:
A Product Search dialog (available as an option on the Client Menu) queries the
user to get a search phrase.
Search phrase is validated according to the rule set out in Appendix 1, item 5.
Once a valid search phrase has been obtained, all products for sale by
advertisers other than the current logged in client are queried to see if the
search phrase appears in either product name or product description. If the
search phrase is the special “ALL” keyword, then all products are listed.
If no products are found which match the search phrase, an informative
message is displayed to notify the user there are no matching results.
If at least one product is found, then the search results are displayed in the same
manner as specified in Story 8, Acceptance Criteria 3 to 6.
11. Story: As a client I want to be able to bid a dollar amount for a product, so I can try to
buy it.
Acceptance criteria:
After the Product Search dialog displays a list of products, a Bid Dialog queries
the user to find out if they want to place a bid on any items on the list, by
eliciting an answer which must be either “yes” or “no”.
If the response is affirmative, then the user is requested to supply a row number
from the Product Search result list. The number must be validated as an integer
within the range of row numbers appearing in the search result table.
The user is then requested to supply a bid amount:
a. Bid amount is entered as a currency amount validated according to the
rules set out in Appendix 1, item 7.
b. Bid amount must be must be greater than the current highest bid to be
acceptable.
c. Once a bid is initiated, the user must supply a valid currency amount
which exceeds the value of the previous best bid before they can
proceed.
The resulting highest bid, including the email address of the currently logged in
client and the new bid amount is applied to the designated product, replacing
any previous highest bid.
12. Story: As a client I want to be able to view a list containing my products for which bids
have been placed, so I can see if anything can be sold.
Acceptance Criteria:
A List Product Bids dialog (available from the Client Menu) is displayed, similar to
the list introduced in Story 8. Instead of showing all products advertised by the
current logged-in client, only those products for which another client has placed
a bid are displayed.
If no products have a bid, an informative message to this effect is displayed is
displayed to notify the user there are no matching results.
Otherwise, all products with a bid are displayed as per Story 8.
13. Story: As a client I want to be able to sell one of my products to the current highest
bidder so I can realise a cash return.
Acceptance Criteria:
After the List Product Bids dialog has displayed items, a Sell Product dialog
queries the user to find out if they want to sell a product, by eliciting an answer
which must be either “yes” or “no”.
If the response is affirmative:
a. The user is requested to supply a row number from the Bid Product
result list. The number must be validated as an integer which is equal to
or greater than 1 and less than or equal to the maximum product row
number appearing in the result table.
b. The product in the designated row is then sold to the successful bidder,
and a message is displayed to indicate how the product will be delivered.
c. After completion of the operation, the product is no longer included in
the current logged-in client’s Product List.
14. Story: As a client, when I place a bid for a product I want to be able to specify that I will
receive the product by one of two options – “click and collect”, or “home delivered” – so
I can get my new product and start using it.
Acceptance Criteria:
After the Place Bid dialog completes, a Delivery Options dialog is used to obtain
delivery information from the user.
Two kinds of Delivery Option are available:
a. “Click and Collect” allows the client to specify a Pickup Window – a time
period during which in which the product will be collected.
If “Click and Collect” is selected, then a Pickup Window dialog is used to
obtain the start- and end-time of the Pickup Window. Data requirements
Pickup Window are set out in Appendix 1, item 8.
b. “Home Delivery” allows the client to specify a delivery address (which
may be different from their registered home address)
If “Home Delivery” is selected, then a Home Delivery dialog is used to
obtain a delivery address. First, the user is asked if they would like
delivery to their home address. If the response is affirmative, then home
address is used as the delivery address for the bid. Otherwise, the
delivery address is obtained from the user according to the criteria for
home address listed in Story 5. Validation rules for delivery address are
set out in Appendix 1, item 3.
15. Story: As a client, I want to see a list showing all products I have successfully purchased
so I can make my next trading decision.
Acceptance Criteria:
A Purchased Items dialog (available from the Client Menu) is used to show
details of all successful purchases in a tabular format.
If no products have been purchased, an informative message to this effect is
displayed is displayed to notify the user there are no matching results.
Purchases are displayed in a tabular form, with one purchase per row. Rows of
the product list are numbered consecutively, starting at 1.
In addition to the row number, each row contains: email address of the seller;
product name; description; original listed price; amount paid for the product
(this is the amount of the successful bid); and a synopsis of the delivery options.
The information is displayed in a single row, with fields separated by tab
characters.
Products should be ranked in ascending order by name, then description, then
price.
User Interface
The company has plans to eventually develop a graphical user interface for this application,
however, this prototype implementation will have a simple text-based interface. A video
which demonstrates how each of the user stories should work in practice is available on
Blackboard.
The user interface of your solution must adhere strictly to the
structure, format and wording of all user interface elements as they
appear in the video.
Automated test scripts will be used to verify functionality, so any
divergence will adversely affect your score.
Database
The company has plans to eventually use a relational database to store and save all
customer data. However, for this prototype, all data will be kept in text files stored in the
present working directory when the program runs. The persistence format is left for you to
choose; any format which enables all information to be reliably stored without loss of
information between runs is acceptable.
Recommended Approach
You are encouraged to design and develop the application in an iterative and incremental
fashion – one user story at a time. You can implement the user stories in whatever order
you please, however for each new user story you should design and implement only the
classes and methods that you require to implement that user story. You are encouraged to
make changes to your class diagram using draw.io (https://app.diagrams.net/). You may
need to first refactor some of the classes and methods that you have already implemented
for earlier user stories in order to better facilitate the new user story. After each user story
you should have working code that achieves all of the user stories considered so far.
Submit Part A at the end of Week 9 for assessment and feedback. Further constructive
feedback about your work in progress will be provided in class during Weeks 11 – 13. Part A
user stories will be reassessed as part of Part B, so any improvements you make in relation
to those user stories will count towards your final score.
What to Submit
For each part of the assignment, you are required to submit a zip file – via Blackboard –
containing the following items:
? The project folder that contains all of your project files.
? Present an image (e.g. BMP, TIFF, JPG, .drawio) that presents the class diagram of
all of the user stories.
? A checklist of all the user stories and whether you have competed them or not.
We recommend that your class diagram should be made in draw.io
(https://app.diagrams.net/).
Develop your solution in a folder named “CAB201_Assignment_2021_S2_n12345678”
replacing the n12345678 with your student ID, and zip the folder. Upload the zip file to
Blackboard.
How to Submit
1. It is your responsibility to ensure that your code compiles and runs in a standard
.NET6.0 development environment. To do this, test your program in one of the
CAB201 computer laboratories prior to submission. If you are unable to access
computer labs, you can use VMWare Horizon (See the VMWare Horizon Client
tutorial on the O-Week page on Blackboard).
2. Follow the submission link on Blackboard to submit your zip file.
3. You may make as many submissions as you want, and we will mark the latest
one that came in before the deadline. Therefore, we recommend that you
submit your work in progress each time a user story is finished. This will protect
you against issues such as accidentally breaking something in your submission
ten minutes before the deadline, and other last-minute network connectivity or
server load problems.
Academic Integrity
Please read and follow the guidelines in QUT’s Academic Integrity Kit, which is available
from the Blackboard site on the Assessment page. Programs submitted for this assignment
will be analysed by the MoSS (Measure of Software Similarity) plagiarism detection system
(http://theory.stanford.edu/~aiken/moss/).
Final Comment
Though all care has been taken in the production of this specification and related
documentation, there may be a need to notify by email any alterations/clarifications to this
specification and related documentation. Remember to check your email regularly for
announcements from CAB201.
Appendix 1: Data validation Rules
1. Client name is a non-blank text string of arbitrary length
2. Email address must be a text string of arbitrary length, consisting of
A single @ symbol that must not be the first or last character of the address
The prefix (the part before the @) has the following requirements:
i. The only valid characters are letters, numbers, underscores (_),
dashes (-) and periods (.)
ii. The last character of the prefix must not be an underscore, dash or
period
The suffix (the part after the @) has the following requirements:
i. The only valid characters are letters, numbers, dashes (-) and dots (.)
ii. There must be at least one dot
iii. Dots cannot be the first or last character of the suffix
iv. Following the last dot, only letters are permitted
3. Client home and delivery addresses consist of the following fields (all fields
mandatory unless otherwise indicated):
Unit/apartment # (optional for the user to enter, but required to exist as a
property or field in the implementing system), must be positive nonzero
integer if present)
Street number (positive nonzero integer)
Street name (non-blank text string of arbitrary length)
Street suffix (e.g. Rd, St, Dr, Blvd)
City (non-blank text string of arbitrary length)
Postcode (integer between 1000 and 9999 inclusive)
State/Territory (must be one of QLD, NSW, VIC, TAS, SA, WA, NT, ACT)
4. Password must be a text string of arbitrary length, at least 8 non-white-space
characters which must contain at least one character from each of the following
categories:
Uppercase letter
Lowercase letter
Digit
Non-alphanumeric character (e.g. !@#$%^&*)
5. Search Phrase is a non-blank text string.
The special keyword “ALL” is used to list all available products.
6. Product advertisement consists of the following mandatory fields:
Product name – a non-blank text string of arbitrary length
Product description – a non-blank text string of arbitrary length which is not
the same as the product name
Price – a currency value (see item 7 for formatting specification)
7. Currency amount is input as a text string in the following format:
The first non-blank symbol is ‘$’ (dollar sign)
The leading ‘$’ is followed by a whole dollar amount, i.e. one or more decimal
digits, with no intervening spaces.
The whole dollar amount is followed by ‘.’ (period)
The period is followed by a cents amount, i.e. exactly two decimal digits
8. Click and Collect Pickup Window consists of the following mandatory fields:
Start time – a DateTime value which may be entered in any format
acceptable to the DateTime.Parse method.
End time – a DateTime value which may be entered in any format
acceptable to the DateTime.Parse method.
Start time must be at least one hour later than the current system time when
the bid is placed.
End time must be at last one hour after start time.