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:
- Borrow camp equipment*
- Retrieve loan record with loan date, camp equipment item id(s), item name, date of return.
- 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:
- 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.
- 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).
- Display list of camp equipment (by categories: tent, lantern, and stoves).
- Update condition of equipment.
- 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:
- The system should provide a menu for users to login.
- If users fail to authenticate themselves, the system will display error message and re-prompt users to attempt again.
- 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.
- Displaying a list of available camp equipment item by category
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.