Press "Enter" to skip to content

Goal For this assignment, you will write a program in C, in the Ubuntu Linux environment, that implements a simple

Goal For this assignment, you will write a program in C, in the Ubuntu Linux environment, that implements a simple inventory management system. Your program will keep track of different products, their price, and the current number of units in stock. It will also allow the end user to print the entire inventory, add stock to the inventory, and buy products. 2. Learning Outcomes With this assignment, you will: • write a small program in C that is modular, and correctly designed and documented • practice writing code that is separated into different header and source files • implement a collection structure 3. Instructions Your program will begin by initializing a store inventory with multiple products, each with different prices and quantities. It will then present the end user with a menu, where the user can view the current inventory, or they can add stock to the inventory by adding units to a specific product, or they can buy a product and have the program keep a running total of the prices of items bought. Your program must follow the programming conventions that we saw in the course lectures, including but not restricted to the correct separation of code into modular functions, basic error checking, and the documentation of each function. A more comprehensive list of constraints can be found in the Constraints section below. You will also be separating your code into header and source files, as described in the instructions below. 3.1. Define your compound data types You will create a file called defs.h, which is the header file that will contain your data type definitions. Once you start implementing your functions, you must also place all your function prototypes in this file, so that the compiler has all the forward references necessary (forward references are covered in section 1.2, programs #4 and #5). In your header file, you will define the following compound data types: 3.1.1. the ProductType data type, which defines a structure type containing the following fields: (a) a unique identifier for that product, stored as an integer (b) the name of the product, stored as a string (c) the number of units of that product that are currently in stock (d) the price of each unit of this product, stored as a float

3.1.2. the ProductArrType data type, which defines a structure type containing the following fields:

(a) an array of ProductType structure pointers; you can define a constant for the maximum number of products

(b) the current number of products in the array

(c) the unique identifier to be assigned to the next product to be created

3.1.3. the Inventory Type data type, which defines a structure type containing the following fields:

(a) the name of the store that owns this inventory (for example, The SCS Store)

(b) a product array, as a ProductArrType structure pointer

3.2. Design your program You will begin by designing the modular functions of your program. Your functions must be single-purpose and reusable, and they must have a clear interface with parameters that are identified as either input, output, or input-output parameters. It’s possible for the functionality of this program to be separated logically into somewhere between 8 and 12 different functions. For your design, you should aim to have a minimum of eight (8) functions (other than main()). For example, you could have functions responsible for initialization, functions for interacting with the end user, functions to process each of the different options presented to the user, etc. Your functions will also be split across multiple source files (.c files). You can start planning what those files will be, and which functions will be placed in which file.

You must have a minimum of three (3) source files for this program. For example, it’s common to have the main() function in its own main.c file. No other function will have its own file. Other groupings of functions into files will be based on functionality. Each source file will be using the compound data types defined in the data types section above. We must make each source file aware of these type definitions by placing the directive #include “defs.h” at the top of each source file. Since we have not covered all the details of compiling and linking yet, we will have to use a somewhat unsavoury way of compiling these multiple source files together. If your program has source files file1.c, file2.c, and file3.c, you will use the command: gcc -o a2 file1.c file2.c file3.c to create the executable a2. NOTE: The file names above are for example ONLY. The file names you choose must reflect the functionality contained in each source file.

3.3. Initialize the inventory and products Your program will begin by declaring a store as an instance of an InventoryType structure, and it will initialize the store’s fields. This includes the following:

3.3.1. initialize the store name

3.3.2. initialize the product array by dynamically allocating an instance of ProductArrType

3.3.3. initialize the fields of the product array, including: (a) the current number of products in the array (b) the next identifier field (i) this will be used to assign a unique id value for every product that is created in the next step (ii) for example, your product ids can begin at 1001 Once the store is initialized, you will create products and add them to the store’s product array, as follows:

3.3.4. dynamically allocate a minimum of ten (10) different products, each with a different name, number of units, and price

3.3.5. add each new product to the store’s product array NOTE: adding a product to a product array must automatically assign the array’s next identifier to that new product, and increment the next id value

3.4. Implement the user interface (UI) Your program will present the end user with a menu. Every time the user selects an option, your program will perform the corresponding action. Then the menu will be displayed again for the user to make their next selection, until they choose to exit. The menu will contain the following options: 3.4.1. print the current inventory 3.4.2. add stock to an existing product in the inventory 3.4.3. buy a product from the inventory 3.4.4. exit the program 3.5. Implement the features Your program will implement the features presented to the user, as follows: 3.5.1. print the current inventory (a) all the information about each product in the store is printed to the screen 3.5.2. add stock to the inventory (a) the user is prompted for a product id and a number of units (b) the corresponding product is found in the store’s product array (i) do not use shortcuts for this, you must traverse the product array (c) the specified number of units is added to that product 3.5.3. buy a product (a) the user is prompted for a product id (b) the corresponding product is found in the store’s product array (i) do not use shortcuts for this, you must traverse the product array (c) the product’s current number of units is decremented by 1 (d) the cost of the product is added to the user’s running total (e) the running total is printed to the screen 3.5.4. exit the program (a) the user’s accumulated total is printed to the screen (b) the program terminates NOTE: All basic error checking must be performed, and all error conditions must be handled. 3.6. Test the program You must provide sufficient datafill to test your program thoroughly. Failure to provide sufficient datafill will result in deductions, and in some cases, it will earn a zero on the assignment. 4. Constraints Your program must comply with all the rules of correct software engineering that we have learned during the lectures, including but not restricted to: 4.1. The code must be written using the default C standard that is supported by the course VM, and it must compile and execute in that environment. It must not require the installation of libraries or packages or any software not already provided in the VM provided. 4.2. Your program must be correctly designed, and it must be separated into modular, reusable functions. 4.3. Do not use any global variables. 4.4. Your program must reuse the functions that you implemented, everywhere possible. 4.5. Your program must perform all basic error checking. 4.6. Compound data types must always be passed by reference, never by value. 4.7. Return values will be used only to indicate function status (success or failure). Except where otherwise noted, data must always be returned using parameters, and never using the return value. 4.8. All dynamically allocated memory must be explicitly deallocated. 4.9. All functions must be documented, as indicated in the course material, section 1.2. 5. Submission 5.1. You will submit in cuLearn, before the due date and time, the following: 5.1.1. One tar or zip file that includes: (a) all source and header files (b) a README file that includes: (i) a preamble (program author, purpose, list of source and header files) (ii) compilation and launching instructions NOTE: Do not include object files, executables, hidden files, or duplicate files or directories in your submission. 5.2. Late submissions will be subject to the late penalty described in the course outline. No exceptions will be made, including for technical and/or connectivity issues. Do not wait until the last day to submit. 5.3. Only files uploaded into cuLearn will be graded. Submissions that contain incorrect, corrupt, or missing files will receive a grade of zero. Corrections to submissions will not be accepted after the due date and time, for any reason. 6. Grading 6.1. Marking components: • 13 marks: correct definition and usage of data types • 26 marks: correct initialization of inventory and products • 9 marks: correct overall control structure • 52 marks: correct implementation of features 6.2. Execution requirements: 6.2.1. all marking components must be called and execute successfully in order to earn marks 6.2.2. all data handled must be printed to the screen for marking components to earn marks 6.3. Deductions: 6.3.1. Packaging errors: (a) 5 marks for missing README (b) up to 10 marks for bad style or missing documentation 6.3.2. Major design and programming errors: (a) 50% of a marking component that uses global variables (b) 50% of a marking component that consistently fails to use correct design principles (c) 100% of a marking component that uses prohibited library classes or functions (d) up to 100% of a marking component where Constraints listed are not followed (e) up to 10 marks for bad style (f) up to 10 marks for memory leaks 6.3.3. Execution errors: (a) 100% of any marking component that cannot be tested because: (i) it doesn’t compile or execute in the course VM, or (ii) the feature is not used in the code, or (iii) data cannot be printed to the screen


Inciteprofessor is a Master Holder in Actuarial Science from the World's Best Universities. He also possesses a Bachelor degree in Computer Science and Cyber Security. He has worked with many freelance companies including Freelancers, Fiverr , Studybay, Essayshark, Essaywriters, Writerbay, Edusson, and Chegg Tutor. He offers help in research paper writing & tutoring in Mathematics, Finance, and Computer Science field.

View all posts

Leave a Reply

Your email address will not be published. Required fields are marked *