C++代写:SEHH2042GiftRedemptionSystem


设计并实现一个Gift Redemption System.
Gift Redemption

Expected Learning Outcomes

  • develop computer programs in one or more high level language programming environment;
  • design and develop structured and documented computer programs;
  • explain the fundamentals of object-oriented programming and apply it in computer program development;
  • integrate the computer programming techniques to solve practical problems.

Introduction

In this assignment, you are going to develop a “Gift Redemption System” that
runs in the command line environment. The system maintains the records of
customers and gifts which are available for redemption by customers using the
shopping points called CC points. The system allows customers to make queries
on the available gifts for redemption and check the CC points balance after
using CC points on gift redemption.

Tasks

  • Each group is required to write a Win32 Console Application program called GRS.cpp.
  • Each student is required to submit a video recording (at most 2-minute long) to demonstrate his/her individual contribution in the group project.
  • Each student is required to submit a Peer-to-Peer evaluation form (through the given Word file) via Blackboard.

Program Requirements

R0

When the program starts, the console should display a welcome message,
followed by the Main Menu of the program. Users can enter the options of the
corresponding actions (see R1 to R6 below).
Welcome Message designed by your group
*** Main Menu ***
[1] Load Starting Data
[2] Show Records
[3] Edit Customers
[4] Enter Customer View
[5] Show Transaction History
[6] Credits and Exit
*****************
Option (1 - 6):

R1 Load Starting Data

When the user inputs 1 in the Main Menu, the system is loaded with starting
data. The starting data includes records of (1) gifts, and (2) customers as
shown in R1.1 below. After the starting data is loaded, the system returns to
the Main Menu.

R1.1

The starting data to be loaded, together with the required data format of the
data fields, are described below.

Gift ID Gift Description Price (HKD) Points Required
A01 LG Internet TV 3900 19000
A02 Pioneer Hifi Set 2400 11500
A03 Sony DVD Player 400 2000
B01 Healthy Air Fryer 1500 7300
B02 Tefal Microwave Oven 480 2400
B03 Famous Coffee Maker 1800 8800
B04 Smart Rice Cooker 600 2900
B05 TechCook Toaster Oven 450 2250
C01 Wellcome $50 Coupon 50 250
C02 Mannings $50 Coupon 50 250
C03 Carol Restaurant $100 Coupon 100 500
C04 Shell $200 Coupon 200 960
D01 Clever Headset 350 1750
D02 HP Optic Mouse 250 1250
D03 Stylish Bluetooth Speaker 800 3900
Data format of each field:
  • Gift ID: A string starting with a letter and then two digits. The starting letter represents the gift category
  • Gift Description: A string that may contain white space (assume at most 100 characters long)
  • Price: An integer, the price of the gift
  • Points Required: An integer, the CC points required to redeem the gift
    Customer records
    Customer ID Rank Points Balance
    Tommy2015 B 8500
    DavidChan B 22800
    Luna123 B 650
    TigerMan B 14000
    Max5678 S 2580
    Neo2000 S 8000
    CCTang S 33554
    EchoWong G 8650
    Rubychow G 28000
    Ivy2023 G 12340
    Data format of each field:
  • Customer ID: A string that uniquely identifies a customer in the system (assume at most 50 characters long); it is case-sensitive. You can assume it does not contain white space.
  • Rank: A character (G, S or B) to represent the rank of the customer; there are different redemption discount policies for customers under different ranks, see requirement R7. Customers are ranked according to the length of time they become the member:
    Rank (character) Rank (description) Become member for
    G Gold More than or equal to 1 year
    S Silver Less than 1 year but more than or equal to 6 months
    B Bronze Less than 6 months
  • Points Balance: The CC points balance owned by the customer

R1.2

Options 2 to 5 in the Main Menu are enabled only after the system is loaded
with the starting data. If the user enters options 2 to 5 before starting data
is loaded, an error message should be shown, and then the system returns to
the Main Menu.

R1.3

After the system is loaded with the starting data, the gift records data
CANNOT be updated by any operations. However, the customer records data can be
edited under options 3 or 4 in the Main Menu. See the requirements that
follow.

R2 Show Records

[After the starting data is loaded] When the user inputs 2 in the Main Menu,
the system displays all the fields of all gift records, and then all the
fields of all customer records. Tabular format should be displayed, and the
records are sorted in alphabetical order based on the ID values. Data shown
should be the latest set of data since the starting data is loaded (updates on
the customer records resulted by the operations under options 3 or 4 in the
Main Menu should be included). After showing the records, the system returns
to the Main Menu.

R3 Edit Customers

[After the starting data is loaded] When the user inputs 3 in the Main Menu,
the system prompts for the next user input of a customer ID. If such customer
ID does not exist in the system, it is an add customer operation. Otherwise,
it is a delete customer operation.

Add customer

The system further asks the user to input two pieces of information: (1) the
date that the customer became a member (in the format DD/MM/YYYY), followed by
(2) the points balance value for the newly added customer. The system
determines which rank (G/S/B) the customer belongs to by comparing the current
date (i.e., the date that the program is run) and the date entered by the
user. After getting all user inputs, the new customer should be added into the
system. For any invalid inputs (e.g., wrong date format/ values, a future date
is entered, incorrect range of points values, etc.), the system allows TWO
more retries. With more than THREE times of invalid inputs, the system prints
an appropriate error message and returns to the Main Menu.

Delete customer

The system displays the information of the customer (including all the
fields), and prompts for user’s “Yes/No” confirmation on the delete operation.
The customer record is deleted from the system if it is confirmed.
A message showing the summary of the above operation is then displayed, and
the system returns to the Main Menu.

R4 Enter Customer View

[After the starting data is loaded] When the user inputs 4 in the Main Menu,
the system prompts for the next user input of a customer ID. If such customer
ID does not exist in the system, the system displays an error message and
returns to the Main Menu. Otherwise, it displays the Customer View Menu as
shown below, and allows further processing on the particular customer (e.g.,
DavidChan) as follows (see R4.1 to R4.3 below).
Action for Customer ID: DavidChan
***** Customer View Menu *****
[1] Earn CC Points
[2] Redeem Gifts
[3] Modify CC Points Balance
[4] Return to Main Menu
**************************
Option (1 - 4):

R4.1 Earn CC Points

When such option is chosen, the system prompts for user input of a floating
point value, which is the amount of money spent for converting to CC points.
The system then calculates and adds the CC points into the Points Balance for
the customer according to the “Points Conversion Rule” (see R7).

R4.2 Redeem Gifts

When such option is chosen, the system displays all the gifts under one of the
Gift Categories according to the user input choice of gift category. Fields
about the gift records should be displayed, including the Gift ID, Gift
Description, Price, Required Pointsthe actual required points for the
customer, which could be a discounted value according to the customer rank,
see R7. Gift records are sorted by the Required Points, from the smallest to
the largest. The display should also identify those gifts that the customer
can redeem by only using his available CC points without paying extra money.
The system then allows the user to enter the Gift ID of the gift that he wants
to redeem, followed by the amount of CC points used for redemption. For any
invalid inputs (e.g., wrong Gift ID, out-of-range CC points for the
redemption, etc.), the system allows TWO more retries. With more than THREE
times of invalid inputs, the system prints an appropriate error message and
returns to the Customer View Menu.
The user can redeem a gift with “less-than-required” CC points through paying
extra money in the redemption transaction (see R7 about the “Points Conversion
Rule”). As a result, the user can still redeem a gift if his available CC
points is less than the required one for the gift.
After getting all user inputs, the system displays the extra money needed in
the redemption transaction and asks for the user’s confirmation. Upon user’s
confirmation, the system subtracts the correct amount of CC points from the
Points Balance for the customer.

R4.3 Modify CC Points Balance

When such option is chosen, the system displays the current CC Points Balance
of the customer, and asks for user input of a new CC Points Balance value. The
system then updates the CC Point Balance for the customer.

R4.4 Return to Main Menu

When such option is chosen, the system returns to the Main Menu.

R4.5 Stay at the Customer View Menu

Following R4.1, R4.2 and R4.3, after an operation on the CC Points Balance of
the customer, the system should display the change in the CC Points Balance of
the customer by that operation, and then stays at the Customer View Menu.

R5 Show Transaction History

[After the starting data is loaded] When the user inputs 5 in the Main Menu,
the system prompts for the next user input of a customer ID. If such customer
ID does not exist in the system, the system displays an error message and
returns to the Main Menu. Otherwise, it displays all the CC Points transaction
records history for that customer since the program starts running:

  • All kinds of CC Points transactions (under R4) should be considered and displayed.
  • The transaction records should be displayed in the order that they were carried out.
  • For an “Add CC Points” transaction, the amount of money spent for earning CC points, and the change in the CC Points Balance, should be displayed.
  • For a “Redeem Gifts” transaction, the gift that is redeemed (its gift ID and gift description), the change in the CC Points Balance, and the extra money needed to pay (if any) in the redemption transaction, should be displayed.
  • For a “Modify CC Points Balance” transaction, the type (increase or decrease) and change in the CC Points Balance, should be displayed.
  • At the end, a summary showing the original CC Points Balance, the final CC Points Balance, the change in CC Points Balance, and the TOTAL amount of extra money the customer needs to pay as a result of all redemption transactions should be displayed.
  • A meaningful message should be shown if there have been no transactions made so far for the customer.
    After displaying the transaction history, the system returns to the Main Menu,

R6 Credits and Exit

When the user inputs this option, the system prompts for user’s confirmation.
If the user inputs ‘n’ or ‘N’, the system returns to the Main Menu. If the
user inputs ‘y’ or ‘Y’, the system displays the personal particulars (student
name, student ID, tutorial group) of the group members and terminates. Other
input is not acceptable and the system should ask the user to confirm again.

R7 Points Conversion Rule

The CC points of a customer could be modified by user operations under R4. The
change should be made according to the “Points Conversion Rule” below, which
also takes the rank of the customer into consideration:

  • A spending of $250 can earn 1 CC point. No CC point can be earned by the remaining spending less than $250.
  • Conversion rate during gift redemption: 1 CC point is worth $0.2.
  • According to the rank of the customer, there is a discount on the CC points required for a gift in the gift redemption. The final points required is rounded to nearest integer:
    Rank Discount

Gold | 10% off
Silver | 5% off
Bronze | No discount

  • The rank of the customer does not affect the price of a gift.
  • During the redemption process, if the user redeems a gift using “less-than-required” CC points, the extra money needed is calculated by subtracting the money value of the CC points used in the redemption (calculated using the above conversation rate) from the price of the gift.

R8

Suitable checking on user’s input is expected, except in situations with
assumptions stated in the requirements above. Appropriate error messages
should be printed whenever unexpected situation happens, e.g., input value out
of range, incorrect date format, etc.

R9

The use of functions (in addition to main function) and classes (i.e., OOP
design) are expected in your program. Appropriate comments should be added in
your source code file.

R10

Creativity and Critical Thinking: Use suitable format to present all required
information of gifts and customers clearly and neatly. Additional features can
be added.

Tips

To handle unexpected input error (e.g. input a character to an integer
variable), you may use the following code appropriately in your program:
cin.ignore(); // Discard the content in the input sequence.
cin.clear(); // Reset the input error status to no error.
—|—

Video Requirements

This is an individual task under this group project. Each student needs to
create a video recording which records either (1) your explanation on the
working algorithms of the codes that you designed and wrote, or (2) the
testing of project codes (those you wrote or the whole group’s work) using
test case scenarios. See points below for the specific requirements of the
video recording:

  • Duration of video is at maximum 2 minutes long. Use MS Teams to record.
  • The video recording is used to demonstrate your contribution in the group project. If your work done is too much to be all included in the 2-minute video, choose the most important/ representative work to record and explain.
  • At the beginning, clearly mention the objective of your video: whether you are going to (1) explain the working algorithms of your codes, or (2) run and test your project codes.
  • The video should include your voice recording (in English) as you give the presentation (either code explanation or the code testing). Your voice should be clear and loud enough.
  • The video should show the computer screen as you give the presentation. Suitable cursor movement or text highlighting by mouse action should be present.
  • In addition to your name shown by MS Teams, you should show your English name, Student ID and lecture group on the screen (e.g., put down the information using Notepad and display it). The video should keep showing it for identity verification. It is optional to show your face in the recording.
  • Show the whole screen, not just part of the screen. While showing the source codes or codetesting results, make sure the text is clearly shown, large enough and visible.

Submission

Source File: Each group submits one source code file (i.e., GRS.cpp).
Video Recording: Each student submits the shared video link via Blackboard,
through which your video recording can be viewed by your subject lecturer
successfully. [IMPORTANT: Remember to set up the access right correctly for
the shared link. You can refer to the guidelines available in Blackboard on
how to prepare the recording and set up the shared link.]
Peer-to-peer Evaluation: Each student fills in the peer-to-peer evaluation
form (MS Word) and submits via Blackboard.


文章作者: SafePoker
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 SafePoker !
  目录