CMSC 106 Project #2 - Car Configurator Spring 2003


Due date: Friday, March 7, 2003 at 11:00 pm

1 Purpose

``IF the car industry made the same kind of progress as the computer industry, THEN cars would cost $25 and get 1000 miles to the gallon.'' (Attributed to Bill Gates)

``Yes, but IF the computer industry made cars, THEN your car would crash for no apparent reason several times a day.'' (Anonymous)

In this project you will write a program using various conditional statements. Since we have not yet discovered how to make cars as cheap as computers, you will be writing a program to configure the features of a Monolithic Motors MegaMobile and compute the ship date from the order date and the time needed to build the car. The input will consist of the body type, requested features, and order date. The program will determine if the configuration is valid, and if so, provide the ship date.

2 Project description

2.1 Input

The program begins by reading in the data to describe the requested car. This data could be typed from the keyboard, or read from a file using UNIX redirection. A typical set of data may look like the following:
1 2
1 0 
1 1 4 0 0
6 23
The first line represents, in order: The second line represents, in order, power windows and door locks. The values are either 1 if the item is requested or 0 if not. The third line represents, in order: type of seats, sound system, number of speakers, navigation system, and side air bags. The fourth line contains the order date. The first value is the month (from 1 to 12) and the second value is the day of the month. (Year is not included.) For this project, you may assume that the user will enter data in the proper format and within the proper range of values for each individual data item.

2.2 Output

Your program will check the requested features and determine if they are correct. How this is determined will be described later. Below is an example of the output your program would produce if it were given the data set from the section above. Your outputs must follow the format below:
Requested configuration on 06/23:
DX Sedan
Power: windows
Seats: cloth
Sound: AM/FM radio with 4 speakers
Other: none
The car will ship on 07/05
The requested features must be listed in the same order as the input values and grouped as shown in the sample above. Possible values for ``Power'' are ``windows'' and ``door locks''. Possible values for ``Other'' are ``navigation'' and ``side air bags''. If more than one option is listed on the same line, the options must be separated by commas.

2.3 Features

The 2003 MegaMobile comes in a choice of 2 body styles: 2-door (coupe) and 4-door (sedan). There are also 3 possible ``trim'' levels, which refer to certain combinations of features. The sedan is available in DX, LX, or EX trim. The coupe is only available in LX or EX trim. For each trim level, there are some features which are STANDARD and some features which are OPTIONS. For some trim levels, certain features may be NOT AVAILABLE. The general rules for choosing features are: These are the rules for specific features:

2.4 Checking Features

After the program has printed out the requested configuration, it must check each requested feature to make sure that it is correct. The features must be checked in the exact order they are listed in the input data: body, power windows, door locks, seats, etc. NOTE: After the program finds the first configuration error, it must print the message for that error and not process any other features. If there is a configuration error, then the program also will not calculate the ship date.

2.5 Ship Date

If a car configuration is valid, the program must calculate the ship date based on the order date and the amount of time required to build the car. Each trim level requires a certain base amount of time to build. The base time INCLUDES the time required for any STANDARD features for a trim level. (Note that the LX and EX require more time to build, because they include more standard features.) The total build time also includes additional time for any options. The base build times for each trim type are: A sedan for any trim type requires 1 extra day beyond the base time. Each other option requires 1/2 extra day, except: To calculate the ship date, we assume that the factory normally starts to build the car at the beginning of the day after the order date. The car is shipped at the end of the day on which it is finished being built. This means that the ship date is calculated by adding the number of build days to the order date. Note that a car cannot be shipped until it is completely finished, so total build times must be rounded UP to the next whole day if they contain a fractional part. Also, the factory closes for 2 weeks, July 15-28, for summer vacation and re-tooling for the next model year, so any build times which would include those days must be adjusted forward, and the program must then print a message on a separate line:
 Order adjusted to new model year
After the ship date has been calculated, the program must print a message of the form:
 The car will ship on mm/dd
where mm is the ship month and dd is the ship day of the month. The values mm and dd must each be 2 digits. You will need to know how many days are in each month in order to calculate the ship date. For example, if a car is ordered on March 28th and takes 12 days to build, then it will ship on April 9. (To figure this out, we needed to know that March has 31 days.) You may ignore leap years in the date calculations. The following chart may assist you:

Days in each Month
January 31
February 28
March 31
April 30
May 31
June 30
July 31
August 31
September 30
October 31
November 30
December 31

3 Project requirements

All your C programs in this course should be written in ANSI C with trapping of unintialized variables, which means they must compile and run correctly with cc -std1 -trapuv on the OIT UNIX Class Cluster. Even if you already know what they are, you may not use any C language features other than those introduced in Chapters 1 through 5 of your textbook. Note that loops, arrays, and user-defined functions may not be used. In addition, your program must contain only one single return statement at its end. Using C features not in these chapters will result in losing credit. Your program must have a comment near the top which contains your name, login ID, student ID, your section number, your TA's name, and an original description of the action and operation of the program. Your program should be written using good programming style and formatting, as discussed in class and throughout your textbook. For this project, style is considered to consist of:

4 Primary Input/Output

We have provided two files (primary_input and primary_output) to help you test your program. If your program is run using the file primary_input as the data source, then the output should look exactly like the file primary_output. You can use UNIX redirection and the diff command to check your program with this sample data. Here's how:
  1. Compile your program - let's suppose the executable is called a.out
  2. Run your program using primary_input as the data source, and another file for the output. We'll suppose the other file is called myoutput: % a.out < primary_input > myoutput
  3. Check to see if your output file matches the primary_output file: % diff -bwi myoutput primary_output
If your output is correct, the diff command should generate no output of any kind. If your output is different from the primary_output file, the diff command will show you what lines are different. Important: We will be testing your program with many different data sets, not just the primary_input mentioned above. You will lose substantial credit for each test case that your program does not handle correctly. For this reason, it is very important that you test your program with a wide variety of input data.

5 Developing your program

You may want to skip this section at first, read the rest of the project, and come back to study it carefully when you are about to begin writing your program.

5.1 Possible development steps

It is very important to continue to type in only a part of your program at a time and verify that it's correct, before going on. Any mistake is much easier to locate this way. The idea is that at all times you have a correct program, which may be incomplete and solve only part of the problem but at least the part you've written so far works. In other words, do not attempt to write your program to perform all the necessary tests or produce completely correct output at first. Add code to perform only one processing step at a time and produce its output, and then add another until your program is complete. For example, here is one way to begin developing the program one part at a time. Write the code for each of the following steps, and compile and test at each stage to make sure the correct results are printed for different inputs before going on to the next step listed.
  1. First you could write code which reads the input data. To be sure they are being read correctly, add statements which echo each item immediately after reading.
  2. When you are sure you are reading the input correctly, you might decide to write code that determines whether or not various features are correct. Start with a small number of features, perhaps for just one trim type, and then gradually add more.
  3. When you are sure that everything else is working so far, try writing the code necessary for determining the number of days required to build a car. (Print out the number of days computed.) Test this part thoroughly before moving on.
  4. When you are sure that you are calculating the number of days correctly, write the code which will calculate the ship date. Display the date in the format specified. Test this part with as many different dates as you can before moving on.
  5. Once you are certain that the dates are being calculated correctly for times not including the model year vacation break, write the code that handles that adjustment. Test with lots of different data!
  6. Make sure your output matches the format specified, and thoroughly test your program using a variety of input combinations.

5.2 Finding compilation errors

  1. As before, if you get the error ``Invalid statement'' and the compiler identifies the very last line in your program, it usually means you have mismatched braces. Carefully match up all of your braces, and make sure that there is a closing brace to match every opening brace. This is much easier to do using a printout, and is far easier when your program is formatted neatly using proper indentation and placement of braces. Draw a line pairing up each set of matching braces until you can tell where one is missing.
  2. If you get the error ``Invalid statement'' and the compiler points right to an else, the else is not placed so it's inside an if statement. Only one statement can appear as the subsidiary statement after an if, and only one statement can appear after an else. If you want more than one statement to appear in a place where one statement belongs, you can use braces to group them into a compound statement. You may have forgotten braces around the statements which were supposed to be executed if the condition in the if/else was true (the first group of subsidiary statements). Alternatively, it's possible you made a mistake and have more elses than ifs. You are much less likely to make this mistake when your code is properly formatted and indented, with each else lined up to clearly indicate which if statement it belongs to.

5.3 Program debugging

If your program doesn't produce the results you think it should, the debug printf statement is the best tool you can use. If, for instance, you're not sure why one branch of an if/else statement is being executed when you think the other should be, put a debug printf statement right before the whole if statement which prints the values of all the variables used in the condition. Maybe one of them doesn't have the value which you think it should have at that point. On the other hand, if you run your program and see that the variables all have correct values, then the condition itself is probably not expressed correctly. Or perhaps nothing prints in some case where you think something should. Try adding an else to every if statement which doesn't already have one, which prints a message indicating what must be true for that statement to be printed. Also in other cases, add as many printfs as you need to determine what is true about the data currently stored. Make sure the debug printfs you add are descriptive in nature to tell you any information you may need to determine what your program is doing, such as what line in in the program is producing this output or what the values of all relevant variables are at that point. This is much more useful than printing something like ``I am here'' in your debug printfs. Also, make sure the debug printfs do not change what statements are controlled by the if or the else. Also for technical reasons not worth explaining, it is very important that every debug printf ends with the newline character '\n'. Although these debug printfs will make your output look incorrect, they will help you develop your program correctly. Make sure that all debug printfs are removed before you submit your source code file for grading. After removing them, before submitting your source file, make sure that you have compiled, run and tested your project again to be sure you did not accidentally change it when you were removing those lines. If you can't find the problem after trying to debug your program using these techniques, bring printouts of your program and any compiler errors or execution results to office hours. To help us find the mistake as quickly as possible, be prepared to demonstrate and explain how you have tested your program, and what results you got.

5.4 Program testing

It is very important to test your program against all different possibilities of input data, not just those provided by us. Doing this correctly involves thinking of what other input values are possible based on the project description, and what results the program should produce in those cases. As an example, say you had to write a program which reads three integers into variables a, b, and c, and prints the name of the variable which had the largest value. Imagine that you wrote the following program:
#include <stdio.h>

main() {
  int a, b, c;
  scanf("%d%d%d", &a, &b, &c);

  if (a <= b) {

    printf("b");

    if (b <= c)
      printf("c");

  } else printf("a");

  printf("\n");
  return 0;
}

Try typing, compiling, and executing this program. If you run the program and enter 2 6 4 it prints ``b'', which is correct. If you run it and enter 6 4 2 it prints ``a'', which is correct. You might assume the program works since you ran it twice with different input values, but it is not correct. Try entering 4 2 6 and it prints ``a'', which is wrong. Try entering 2 4 6 and it prints ``bc'', which is also wrong. There are other possibilities of input values which cause incorrect results as well. The conclusion is that it is always necessary to think of all the different possible combinations and possibilities of input values which might appear in a program's input, and test it so you are certain it works correctly in all cases, not just for one or two different inputs. If you are curious, one correct program to perform this task is as follows. The program could also be written using the logical operators.
#include <stdio.h>

main() {
  int a, b, c;
  scanf("%d%d%d", &a, &b, &c);

  if (a <= b)

    if (b <= c)
      printf("c");
    else printf("b");

  else

    if (a <= c)
      printf("c");
    else printf("a");

  printf("\n");
  return 0;
}

5.5 Helpful hints

One development policy which is extremely important is to use proper indentation from the beginning. Many students type in their programs any way at all, with poor or no indentation, figuring once their project works correctly they will clean it up before submitting it. This is a very bad idea, because it is much harder to find certain errors in a program with poor indentation, and it's much easier to make these types of mistakes. You are much more likely to have problems such as mismatched braces, or misplacing an else, or misunderstanding which statements are subsidiary to which if statements if your code is improperly formatted or indented, or the braces are incorrectly placed. In the Q+A sections your textbook shows several popular styles of indentation. It doesn't matter which you use, as long as your code is clear and your indentation is consistent, subsidiary statements are all indented, and statements at the same level are all indented the same way. If you come to office hours for help with a program which has missing or very poor indentation, you will be asked to correct and reformat your program before we are able to help you further with it.

6 Academic integrity statement

Any evidence of unauthorized use of computer accounts or cooperation on projects will be submitted to the Student Honor Council, which could result in an XF for the course, suspension, or expulsion from the University. Projects are to be written INDIVIDUALLY. For academic honesty purposes, projects are to be considered comparable to a take-home exam. Any cooperation or exchange of ideas which would be prohibited on an exam is also prohibited on a project assignment, and WILL BE REPORTED to the Honor Council.


VIOLATIONS OF ACADEMIC HONESTY INCLUDE:


  1. failing to do all or any of the work on a project by yourself, other than assistance from the instructional staff.

  2. using any ideas or any part of another student's project, or copying any other individual's work in any way.

  3. giving any parts or ideas from your project, including test data, to another student.

  4. having programs on an open account or on a PC that other students can access.

  5. transferring any part of a project to or from another student or individual by any means, electronic or otherwise.


IT IS THE RESPONSIBILITY, UNDER THE UNIVERSITY HONOR POLICY, OF ANY STUDENT WHO LEARNS OF AN INCIDENT OF ACADEMIC DISHONESTY TO REPORT IT TO THEIR INSTRUCTOR.

7 Submitting your project

Your project must be electronically submitted by the date above, before 11:00pm, to avoid losing credit as indicated on the syllabus. No projects more than two days late will be accepted for credit without prior permission or a valid medical excuse, as described on your syllabus. Only the project which you electronically submit, according to the procedures provided, can be graded; it is your responsibility to test your program and verify that it works properly before submitting. Lost passwords or other system problems do not constitute valid justifications for late projects, so do not put off working on your program or wait to submit it at the last minute! Turn in your assignment using the ``submit'' program as before, except using ``2'' for the project number. You are to submit only the .c file containing your source code, not the executable version of your program! If your program is in a file named ``p2.c'', submit would be run as shown.

% submit  2  p2.c

Before you submit your project, you must exactly follow the specific submission checklist in the ``Testing projects before submitting'' handout separately posted by your instructor!

Steve Scolnik 2003-02-24