Assignment 1 (Worth 8%)

Due 11:55pm Friday 19th  August 2022. (End of Week Four)

Overview

This assignment is to be implemented using procedural programming. The overall objective is to create a program that implements the processing of customer orders for robots from a robot construction company  :  ITR  (Illawarra Toy Robotics).   The company builds robots based on orders placed by customers.  As one would expect, each robot has a degree of complexity and will be assembled, using only parts available in the inventory of the company.  Technicians, also called Builders, that work for ITR have different abilities. For each builder, the ability is variable around some given value and affects the success or otherwise of a robot build. Details about, customers, builders and parts will be given in the next sections.

General code notes

These are some general rules about what you should and should not do.

1. Your assignment should be organised into:

(a) A driver file containing your main() function.

(b) A header file containing the prototypes for the functions you write.

(c) An implementation file containing the implementations of your functions.

2. Provide a text file Readme .txt with instructions for compiling your code on capa .its .uow .edu .au into the executable ITR. The Readme .txt should actually be a text file, not a doc or docx or pdf or rtf or something other than text, and the instruction should be a copy and pastable command. For example: g++  file1 .cpp  file2 .cpp  -o  itr  -std=c++17  -Wall

3. Ensuring that your code compiles on capa is your first step in verifying your work.

4. You are not allowed to use classes because this assignment is testing your understanding of procedural programming.

5. You can use struct, but they cannot have member functions in them.  This means a struct is being used to group data together in the context of this assignment.

6. Within your code, be consistent in your tabbing style. We want readable code.

7. Include sensible volumes of commenting.

8. Use appropriate variable names and be consistent in your chosen style.

9. Don’t leak memory.

10. Your main() function should make it clear what is going on, and should not be too large.

11.  Other than the initial command line input, the program should run without user output.   In particular this means there should not be pauses waiting for the user to press a key.

Parts

The company maintains an inventory (or catalogue) of parts used to build robots. Data file describing the available parts is named Parts .txt.   The structure of the file is as follows  (colons are used to separate fields and the full stop to end the line):

Part  code:Part name:Minimum:Maximum:Complexity .

A:Head:1:2:15 .

B:Torso:0:6:5 .

C:Leg:0:4:6 .

D:Arm:0:4:8 .

E:Tail:0:6:2 .

As shown above, each part has a code indicated by single capital letter. The Minimum and Maximum are limits on the number of the corresponding part type allowed in a proposed build. For example, the minimum number of Head is 1 and maximum is 2; Torso,  Leg,  Arm and Tail have minimum of 0. The complexity is used to determine how difficult a build will be depending on the parts added.

Customers

The Customer data is contained in a file that could be named Customers .txt and has no more than 10 entries. It provides information about the customer’s name, project name and the parts required to build the order.  The structure of the file is as follows (colons are used to separate fields and the full stop to end the line):

Customer name:Project name:List  of parts .

Example:

Carly:Cat:ABCCCCE .

Dodgy  Dan:Dog:BCACECC .

Ernie:Ettin:AABCCDD .

Sally:Snake:AEEEEEE .

The Customer name is the name of the customer that submitted the order. It is a non-empty string of printable characters that may include spaces.

The Project name is chosen by the customer and is supposed to represent the type of robot to be built. Similarly to the Customer name it is a non-empty string of printable characters that may include spaces.

The List  of parts contains a list of letters with each letter corresponding to a part in the parts file.  They do not need to be in alphabetical order.  There should not be more than 10 parts for any order.

Builders

Information about the possible builders the company can assign to build an order is contained in a file that could be named Builders .txt and could have a minimum of one entry.  The structure of the file is as follows (colons are used to separate fields and the full stop to end the line):

Name:Ability:Variability .

Example:

Reliable  Rover:70:1 .

Sloppy  Simon:20:4 .

Technical  Tom:90:3 .

The name cannot be empty. The ability is an integer in the range 1 to 99 inclusive. The variability is an integer in the range 1 to 10 inclusive and this is indicative of the fact that a builder’s ability could vary around the value provided in the entry.

Processing an order

Given a customer’s order, the management at ITR has instructed the factory supervisor to use the following procedure to fill the order.

• For the given customer randomly allocate a builder who will be responsible for constructing the robot.

• Determine the overall robot complexity as 22 plus the sum of the part complexities. For example, given a customer Sally the robot complexity is computed as:

Sally:Snake:AEEEEEE .

Overall  robot  complexity  =  22+15  +  6  *  2  =  49

If the complexity is greater than 100, it should be changed to exactly 100.

• Determine the overall robot variability as 4 plus the number of parts plus the variability of the builder. For example if a builder named Reliable  Rover has been selected and has variability of 1, overall robot variability is calculated as:

Sally:Snake:AEEEEEE .

Reliable  Rover:70:1 .

Overall  robot  variability  =  4  +  7  +  1  =  12 .

Report the customer name, project name, builder name, the distribution parameters (i.e.  mean = builder’s ability. standard dev. = overall robot variability) and overall robot complexity to the Output-file.

• The builder attempts to build the robot. Generate a random value from a normal distribution with mean equal to the builder’s ability and standard deviation equal to the overall robot variability just calculated.

If the random value is greater than or equal to the overall robot complexity, the build is successful.

If the random value is less than the overall robot complexity, the build fails.

• If the build succeeds you can move on to the next customer.

• If the build fails, the builder can re-attempt the build twice.   For each re-attempt generate a random value from the same distribution as before, but for the first re-attempt add 5 and for the second re-attempt add 10 respectively to the value.

• After three fails in total you should move to the next customer regardless of the result.

• The random value and success status for each attempt should be reported to the Output-file.

Run structure

Once your program is compiled into the executable ITR, it must run as follows:

$  ./ITR  Customers .txt  Parts .txt  Builders .txt  Output-file

The order in which the files are provided on the command line serves particular purposes and should not be changed. This means that you will expect respectively, files of customer details, followed by parts details and then builders details as command line arguments.  The content of the files may differ from the samples provided, except for Parts .txt. So, you must not hard code the content of the sample files into your program. Do not hard code the names of the files in your program because these may be different when your code is run.

The expected structure of the input data files is as given above. Note that Parts .txt will definitely follow the given structure.  However, you should expect that the other data files may contain errors in structure.  For example an erroneous file may contain more than the limit given for the number of parts a robot may contain.  This could happen when the customer fill the online order form or when the receptionist took the order from the customer. Such error must be detected and dealt with in your code.  Your code could be run against several configuration of input file that may contain error.  So, you must catch any error detected.

When you read from the data files you should report on the data read by your program.  On the standard  out you should provide a list of customers, a list of parts and their total numbers required for all projects, and a list of builders and their abilities; all appropriately formatted so it is evident that you have correctly partitioned the input data. This will demonstrate that you have correctly linked the files. Note that this report should go to standard  out, and not to Output-file. Output-file is used to report on results.

The customer orders in the customers file are to be processed in the order they are given.

The file Output-file should be ordered by customer and contain a clear report on the build plan, success or otherwise in the multiple attempts, as necessary.