C++代写：AST21105CampingEquipmentSystem

代写一个露营用的装备租赁管理系统。

Project Description

You are requested to write up a program that handles loans of camping
equipment for a scout group. The system keeps track of loans of camping
equipment. The systems will check a user’s level and depends on a user’s level
the system will determine whether such loan is allowed. The system will also
keep track of loan history. To facilitate users, the system could enable an
administrator to insert a text file with specified format for bulk data
insertion. Data insertions are inserting a batch of users and inserting a
batch of camp equipment. The system could hold a default administrator
identity with user-id and password as admin and admin, respectively.

Roles of User

Scout Members and Scouters

Even though a scout group has multiple sections but the loan system is only
for the three sections: Scout (partially), Venture Scout, and Rover Scout.
Each section has number of scout members. Each member has the attributes 1)
ID, 2) Name, 3) Section, 4) Date of Birth, and 5) Address. For members of
Scout, they have an additional attributes Rank (Member, Patrol Leader,
Assistant Patrol Leader). Beside scout members, a scout group is run by a
group of volunteers, Scouters. Scouters have an additional attribute Rank. You
may want to add an additional attribute to record their level of rights
indicating how many items these users could borrow.
Both scout members and scouters could do the following tasks:

1. Borrow camp equipment*
2. Retrieve loan record with loan date, camp equipment item id(s), item name, date of return.
3. View of available camp equipment for loans

• Different types of scout members have various levels of rights when borrowing equipment. For member in Scout session, members could only borrow 1 item and both Patrol Leader and Assistant Patrol Leader are permitted to borrow 3 items. Each venture scout could borrow up to 3 items. Rover scout and scouters could borrow up to 5 items.

Administrator

An administrator that could do the following tasks:

1. Inserting tabulated files containing batches of users and batches of camp equipment. These two files have their own fixed format which will be discussed later.
2. Display loan records containing loan date, camp equipment item id(s), item name, name of borrower, return date, status (out for loan, returned if equipment is back).
3. Display list of camp equipment (by categories: tent, lantern, and stoves).
4. Update condition of equipment.
5. Produce a .txt file that contains all updated data such as loan records and equipment lists.

Camp Equipment

Camp equipment item are categorized into 3 major types: tent, stoves, and
lantern. Each equipment has itemID, itemName, brand, itemType (tent, stove,
lantern), dateOfPurchase (DDMMYYYY), condition (good, damaged, being repaired,
or disposed), and status (in or out - if loaned). Different types of equipment
are further detailed with attributes only to a specific type.

Tent

Tent belongs to camp equipment and can be further detailed with these
attributes: tentSize (2, 4, 6, 8, 10, and 16), tentType (lightweight, family,
wall, tunnel, or dome), numberOfDoors (1, 2, and 4), doubleLayer (true /
false) and colour.

Lantern

Lantern has the following specific attributes: lanternSize (hiking or
camping), lanternType (head lamp, table lamp, led lamp, and beam lamp), and
fuelType (AA batteries, AAA batteries, C batteries, D batteries, stove gas and
screw headed gas).

Stove

Stove has the following specific attributes: stoveType (ultralight,
lightweight, and table), and fuelType (stove gas, screw headed gas, and wax).

System

In general, the system provides the following tasks:

1. The system should provide a menu for users to login.
2. If users fail to authenticate themselves, the system will display error message and re-prompt users to attempt again.
3. Once users have logged into the system, the system will provide a menu with the following options:
   * Displaying a list of available camp equipment item by category
   • If users pick this option, the system displays list of available equipment by category.
   • Only “good” conditions and unborrowed items are displayed on list.
     • Displaying user’s loan record
   • If users have borrowed equipment, a list of loaned equipment by the user will be displayed.
     • Providing a sub-menu for equipment loan (only for users who have not borrowed any items)
   • If users have any unreturned item, this option should not be available to them.
   • If users have not borrowed any item, the system will provide a menu for users to borrow items from the scout group. Number of items allowed for loan depends on users’ rank.
   • For any loan of equipment, by default, the returning date will be 14 days after the loan date.
     • Returning camp equipment
   • Users key in item id(s) of item(s) to return the item. The system keeps prompting users to key in item ids until user has inputted -1.
     • Exit
   • Display thank you message and exit the system.

Tasks to be completed

Tasks are generally categorized into Core, Graphical User Interface (GUI), and
Documentation. The core modules, GUI, and documentation weigh 70%, 20%, and
10%, respectively. Each will be detailed in later sections.

Core Part (70%)

The core modules are mainly the system that could run independently with a
command line interface, to be implemented by you. Followings are suggested
classes that you should implement. Be reminded, those suggested classes may
not be enough and you may need to create more class and to include libraries
to complete the requirements.

Class User and its derived classes (15%)

There are multiple types of users and they may have different level of rights
and attribute sets. You may define User as a superclass and furnish the class
by various sub-classes. You may also want to implement the User class as an
abstract class with pure virtual functions for different sub-classes’ further
implementation, if necessary.

Class Admin (10%)

There is only ONE admin and the administrator could do multiple tasks
mentioned above. You may hardcode the user id and password, both as “admin”.
Be warned, this is the only thing you could do the hardcoding.

Class Equipment and its derived classes (15%)

Equipment class has a set of common attributes for 3 different types of
equipment which could be further detailed with sub-classes. You may also want
to implement the Equipment class as an abstract class with pure virtual
functions for different sub- classes’ further implementation, if necessary.

Class FileHandler (10%)

The FileHandler class is used to read and write plain text files. The class
has two major methods fileRead(…) and fileWrite(…). All text files are in
fixed format. See appendices for details.

Class LoanControl (20%)

The LoanControl class is actually the class that works between UI (the Menu
class) and other entity classes like User, Equipment, and even the FileHandler
class. This class serves as a manager that manages all activities of the
system and passing data/messages between classes and menu. The LoanControl
class will make decisions whether such loan of equipment is permitted.
The functions mentioned above in System may not include all necessary
functions. You may have to add more necessary functions.

Class Menu (ONLY IF YOU IMPLEMENT COMMAND LINE User Interface)

The Menu class serves as a command line user-interface with menu and sub-menu.
You should try your best to properly respond to user’s input errors. The Menu
class does not weigh any mark but marks will be deducted if you fail to
produce a user- friendly UI.
Beside menu for users, you are also required to implement a menu for
administrator and implement all necessary functions.

Marking Criteria of Core Part

Generally speaking, core parts are graded according to its completion of
requirements, usage of advanced programming techniques (inheritance and
polymorphism, etc.), and documentation (comments).

Graphical User Interface (GUI) (20%)

This is NOT a core part. By completing a user-friendly GUI will let you get
the rest 20% of the project mark. Clues on working C++ with GUI are little and
will not be discussed in lectures and labs. Make sure you have included all
necessary libraries and files when submitting your project to Canvas.
IMPORTANT: Please carefully consider your programmability to assess whether
adoption of GUI for this project is worth.

Marking Criteria of GUI

GUI will be graded by user-friendliness, smooth of usage with only keyboard,
flow of menu.

Documentation (10%)

Each project group should produce a user manual with NO MORE THAN 16 pages
including cover page and appendices. The document will be graded according to
readability and coverage of functions.