CMSC 106 |
Project #2 - Car Configurator |
Spring 2003 |
Due date: Friday, March 7, 2003 at 11:00 pm
``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.
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.
- Seat type:
- Sound system:
- 1 is AM/FM radio
- 2 is CD player
- Number of speakers: total number of speakers requested
- Navigation system: 1 if requested, 0 if not
- Side air bags: 1 if requested, 0 if not
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.
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.
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:
- If a feature is standard for a trim level,
it MUST be included on any order for a car with that trim level.
However, some standard features may be upgraded with a higher option.
For example, cloth seats are standard,
but they may be upgraded to leather on the EX.
Standard options may not be downgraded.
For example, if a CD player is standard, it may not be downgraded to AM/FM radio.
- If a feature is an option for a trim level, it may or may not
be included on an order for a car with that trim level.
There are two kinds of options:
Some options, such as side air bags, may be added on to one or more trim levels.
Other options may be included as upgrades to standard features, such as leather seats.
Note that there are certain restrictions for some options,
such as the maximum number of speakers.
Some options may also require other features as prerequisites.
- If a feature is not available for a trim level,
it may NOT be included on an order for a car with that trim level.
These are the rules for specific features:
- The DX has power windows standard, but power door locks are not available.
Power windows and door locks are standard on the LX and EX.
- Cloth seats are standard on all models. Leather is available as
an upgrade option, but only on the EX.
- The DX has an AM/FM radio with 2 speakers standard;
a CD player is available as an upgrade option,
but it also requires a total of at least 4 speakers.
The LX and EX both have CD players standard, but the LX has 6 speakers, and
the EX has 8 speakers, included in the standard configuration.
Additional speakers are available as an upgrade option.
The maximum total number of speakers is
6 for the DX, 8 for the LX, and 10 for the EX.
- A computer navigation system is an option available only on
the EX with leather seats.
- Side air bags are not available on the DX. They are an option on the LX and
are standard on the EX.
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.
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:
- DX: 10 days
- LX: 12 days
- EX: 16 days
A sedan for any trim type requires 1 extra day beyond the base time.
Each other option requires 1/2 extra day, except:
- Leather seats require 3/4 day
- Each extra (non-standard) speaker requires 0.15 day
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 |
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:
- adequate descriptive comments throughout (in addition to the
comment mentioned above), to describe what your program is doing
and how
- neat and proper indentation and formatting, including consistently
and correctly aligning braces using any of the bracing styles
illustrated in your textbook
- writing clear and readable code
- use of meaningful descriptive variable names
- use of symbolic constants for all ``special'' values which don't
change and which are used in more than one place in your code
- avoiding disallowed C language features as discussed above
- you must avoid writing duplicative code; you will be penalized
for poor program design
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:
- Compile your program - let's suppose the executable is called
a.out
- 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
- 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.
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.
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.
- 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.
- 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.
- 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.
- 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.
- 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!
- Make sure your output matches the format specified, and
thoroughly test your program using a variety of input combinations.
- 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.
- 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 else
s than
if
s. 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.
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 printf
s as you need to
determine what is true about the data currently stored.
Make sure the debug printf
s 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
printf
s. Also, make sure the debug printf
s 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 printf
s will make your output look incorrect,
they will help you develop your program correctly.
Make sure that all debug printf
s 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.
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;
}
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.
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:
- failing to do all or any of the work on a project by yourself,
other than assistance from the instructional staff.
- using any ideas or any part of another student's project, or
copying any other individual's work in any way.
- giving any parts or ideas from your project, including test data,
to another student.
- having programs on an open account or on a PC that other students
can access.
- 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.
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