ITD121代写、Java/Python程序代写

日期：2022-10-06 09:47

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.