Lab #1 Assignment

CSE 1320-001

Summer 2011

Due Date:       See class website for due date

(see instructions on website for how to turn this in - Ōlab submission infoĶ)

Grade value:    6% out of 100% for all grades

                        Lab #1 has three parts, I, II, and III – each part is worth 2% of the total 6%

 

Objective: The goal for this lab is to provide an opportunity for practice of C program development and the C programming topics covered in Chapters 1–4 and parts of later chapters in Foster and Foster as covered in class. It is assumed that the student is familiar with the programming concepts but not the C syntax. This assignment is designed to help student practice the skills they will need for all the labs in this class. The three parts of the assignment are:

 

Part I: Practice in accessing and using the omega Unix operating system including creating a secure shell, transferring files to omega, creating directories and navigating in them, compiling a C file that was transferred to omega, running the compiled program, and recording it all in a script file.

 

Part II: Practice in editing a C program file that I give you using a line based editor on the Unix system, compiling the C file, running the program and then debugging it. This program will have intentional errors that you must fix.

 

Part III: Adding to the program from Part II by writing additional functions that will allow the program to do more actions.

 

Every lab assignment allows students to practice program development, debugging, and testing. All of these skills are crucial to success in Dr. TÕs class. The format of this assignment is not similar to the assignments that will be required for the rest of the semester but labs from previous semesters may be reviewed to get an idea. A student who is unsure of their skills should start early and should plan to ask the instructor or TA about any concepts they are unsure of.

 

Topics:

            Program design

            Modular programming structure

            Error checking

            Programming style

            Compiling code,

Executing code,

Debugging and testing.

 

Plan: Dr. T gives an overall problem that students work on all semester. Each lab assignment implements specific concepts. Succeeding assignments will modify and extend previous assignments.

 

Part I Assignment:

 

Already posted

 

Part II Assignment:

 

Already posted

 

Part III Assignment:

 

Now, IÕm going to stop giving steps and just give the requirements for this third part. You are going to take the program CL1P2err.c that now works and you are going to expand it. First, you should make a copy of the file so that the original file that you have fixed doesnÕt get messed up. To copy on Unix you give the copy command cp, then the name of the original file and then the name of the file you want to copy it into. So weÕll use: cp CL1P2err.c CL1P3.c Now you will use CL1P3.c to do the remainder of Part III.

 

For Part III you will be changing your program into one that is more meaningful and useful than just an add and multiply. We are going to enhance the program to manage information for a theater company. To start with we will just get some information about ticket prices, who is attending, and which kind of show date. With this info, you will calculate the cost for the attendees to come see the show at the performance time they want and then print this information. You must let the user do multiple sets of calculations if they want, i.e. keep asking for new costs and attendees until they are done. You must also check that all the input they give is valid, i.e. -4 people wonÕt be coming.

 

Given your starting program, you will need to make the following changes:

 

1. Give the user a welcome message when the program starts.

2. Change the variable names so that one variable is for the cost of a show, and another variable is the number of people attending. Add variables if needed. Use meaningful names.

3. Ask the user the enter the number of adults attending and the number of children under 15 attending.

4. Verify that the value that was entered was a positive number. If the number of attendees is not positive, use 3.

5. Call a function to calculate the cost of one ticket for the desired show. The function should ask the user the cost for a weekend evening show ticket. The function should then ask the user if they plan to attend A) a weekend evening show, B) a weekend matinee show, or C) a weekday evening show. Based on this result, the function should return a ticket cost calculated as follows: If A is selected, return the full cost. If C is selected, return 80% of the weekend evening cost. If B is selected, return 55% of the weekend evening cost. This value should be saved in the calling routine.

6. In the function verify that all of the number values that were entered were positive numbers. If the cost is not positive, use $40. Verify that only one of the allowed letters is chosen and make the user choose again if letter is incorrect.

7. Using the input number of adults and children and the calculated ticket price for the show, find the total cost for that group to attend their desired show. Ticket cost for children under age 15 are ¾ of the cost of regular adult tickets.

8. Print out the resulting values in a meaningful message.

9. Ask the user if they would like to calculate another show cost and read in a response from them. If yes, loop back to the top and repeat. If no, end the program with a thank you message. You will need a variable to use for this loop so donÕt forget to declare it.

 

Once your program is modified, compile it, run it and test it. Your program must compile and run without warnings or errors when you turn it in.

 

You should design your program in advance before you begin writing code. In all other labs you will document your design and turn in the design document at least a week before the lab assignment is due. The goal of the design document is to assist you in developing the actual program.

 

Read ALL of the assignment before you start trying to develop the program.

 

Be sure to check the DEDUCTIONS section at the end of this assignment to avoid penalties. You may NOT use global variables, the exit command, goto, break (except in a switch), continue, structs, strings, passing by reference (except arrays), or linked lists.

 

 

Implementation Requirements:

 

For Part III WRITE A DESIGN DOCUMENT FIRST. The design must include

 

      a) all the functions you expect to write,

 

      b) brief (one line) descriptions of each function, and

 

      c) some indication of which function calls what other functions.

 

The design document may be written as lines of text or as diagrams (such as a diagram that start with the main function at the top and all others below it) or as some combination of those, but it must include the information listed for a), b), and c) above. Each function should accomplish one main purpose and each function at a lower level should have a more specific purpose than the function that calls it. Be sure to include all the functions that are described in this lab assignment. This design documentation will normally be turned in for the lab and a design will be required to be turned in for all labs after Lab 1. See the website for the DESIGN DOCUMENT due date. It is usually ONE WEEK PRIOR to the lab due date.

 

 

 

The program should use the following data structures:

            Single variables

 

The program should use the following control structures:

            Function calls to perform tasks

            A while or for loop to allow user to give multiple inputs

            If, if-else, nested ifs, or switches to error check and implement the menu options

 

The program should NOT use:

            structs

            global variables

            exit

            break (except in a switch)

            continue

            pointers

any topic not covered in class before the lab DUE date unless approved by the instructor

 

Programming practices:

Comment your code! Use headers as described below, use line comments and use block comments. Line and block comments should explain the meaning of the code. As an example compare the following examples of code with comments:

 

Example 1:

/* Find A by multiplying L times W */

A = L * W;      // A is the product

 

Example 2:

/* Find the area of the rectangle by multiplying length times width of the sides */

A = L * W; // A is area, L is length of one side, W is length of perpendicular side attached to L

 

While Example 1 has comments, the comments do not tell us anything extra about the code. The code itself tell us that A is the product of L*W. In Example 2, the comments are meaningful and explain the goal of the code and the meaning of the variables. Make your comments like Example 2 not Example 1.

 

The program should have a program header which gives, at least, your name, the number of the lab assignment, your class and section, the assignment date, the due date, and a description of the program. If multiple files are used, each file should contain a similar header. See your instructor's website for SPECIFIC instructions about the program header.

 

Each programmer-defined function, i.e. each function you write, should have a function header similar to those used in the examples in the textbook. This header should include at least the function name, the purpose of the function, and its inputs and outputs.

 

The program should be implemented as a set of functions with a main routine and at least one function for finding the half cost. The purpose of functions is to divide the problem into small tasks, each one assigned to its own function and then to call the functions from main() or from another function when appropriate. Do not code the entire program in main!

 

The program should perform the following actions in the given order:

            Declare and initialize the variables

            Print a welcome screen for the user that introduces the system

            Get the needed input values from the keyboard or file

            Print the appropriate outputs

            Let the user make additional choices until the user indicates that they are finished.

 

Output requirements:

The program must be run and the output recorded in a script file from OMEGA using the gcc compiler. No Exceptions! If you do not know how to create a script file, it is your responsibility to ask the TA, look for help on the class website, or OIT how to use this function.

 

Testing:

This program must be run with two different sets of test data for the input data. You must create two different data sets and run your program with both of them. I will give you a small amount of sample data at the end of this lab for you to use as a model. You may run your program two times within a single execution or you may execute the program two different times so that you have a total of two different data sets. The sample data sets that you create must meet the guidelines given in the problem definition. Your test runs should demonstrate all the choices that are available in your program.

 

NOTE ABOUT ERRORS:

 

Programs turned in for credit MUST compile and run WITHOUT any compilation errors or runtime errors using the gcc compiler on omega. No other compiler may be used for the compilation for credit. No other operating system may be used for the compilation and/or execution for credit.

 

Compilation errors occur while the program is being developed and they prevent the program from compiling correctly. Programs compile correctly when running

 

>gcc myprogram.c

 

gives no error messages.

 

Programs may be turned in for credit when they are partially complete but all completed functions must run without any errors. A program completes without runtime errors if it ends only when the user selects for the program to end and it correctly prints the exit message. Partially complete programs that run correctly for all implemented menu choices will receive partial credit.

 

Any other type of ending is a runtime error or a "crash". A program has a runtime error if it compiles and runs but then crashes in any situation, i.e. if there is any set of choices the user can make that will make the program crash. It is your responsibility to test all possible choices in your program to make sure that none of them cause a runtime error. The goal of creating input test data and running your program with it should be to test all of the various choices in your program to make sure all of them terminate correctly.

 

Labs which have errors in them and do not terminate normally will receive an overall grade of 0 (zero)

 

 

Grading Scale:

 

Part I: (20%)

1 point          Script file initially shows ls -l without file output.c in directory

1 point          Script file then shows ls with file output.c in directory

2 points        mkdir C1320

1 point          ls //should show C1320 now

2 points        mv output.c C1320/ (including the ls command after to show that output.c is gone)

2 points        cd C1320 (including the ls command after to show output.c)

2 points        cat output.c // print the program to the screen

3 points        gcc output.c ( including the ls command after to show a.out )

2 points        a.out

2 points        //program output should be shown

2 points        Everything for Part I done in one continuous script file

 

Part II: (30%)

1 point          Script file initially shows ls to show the CL1P2err.c file

2 points        gcc CL1P2err.c // with two warnings and four errors

12 points      gcc CL1P2err.c // with fewer warnings and errors (repeat until no more warnings or errors)

5 points        a.out (first run with test data)

3 points        a.out // try to "break" the program with numbers (second run or iteration)

3 points        a.out // or third iteration

2 points        // discovered that very large inputs will cause "inf" output which "breaks" the program

2 points        Everything for Part II done in one continuous script file

 

Part III –

 

Code:   (34%)

Headers: program (2 pts ) + for all functions(1)

Comments (line comments and block comments) (3)

Modularity (division of the problem into small tasks, each one assigned to its own function and called from main() or from another function when appropriate) (5)

Style(indentation,meaningful identifiers,lateral separation) (4)

Correct declaration and manipulation of the variables (5)

Correct use of required control structures - menu for ticket type, loop to let user run program again (4)

Correct function structure as required- ticket cost (4)

Proper implementation of data input(2) and input error checking (4)

 

Output:            (16 %)

User clearly understands what is being requested for input (3)

Calculate tasks perform correctly (4)

Input verification shows valid values(1) and list of inputs correctly saved and printed(1)

Output gives clear information to explain the values to the user(4)

Output contains all the given test data and one additional data set (3)

 

Grading Deductions:  

Use of global variables                                                                  Overall grade: 0 (-100)

Use of exit, break (outside a switch), or continue                         Overall grade: 0 (-100)

Lab has execution errors or warnings and does not terminate normally         Overall grade: 0 (-100)

Lab has compilation errors and does not compile properly           Overall grade: 0 (-100)

Lab has a compiler warning when compiled                                 Overall grade: 0 (-100)

No submission of script file or C program file                              Overall grade: 0 (-100)

Late submission without permission from instructor                    Overall grade: 0 (-100)

            or defined late penalty if student has permission to turn in late lab

No submission of design document                                              Overall grade: 0 (-100)

Use of structs, arrays, strings, or linked lists                                Grade: -50 per use

Use of what we haven't learned and discussed in the class yet      Dr. T will assign case by case

 

 

Miscellaneous:

Be sure to test with incorrect values like negative numbers.

Your program does not have to deal with wrong data TYPES in input as long as your program informed the user of the requirements.

Your program does need to verify that input values are valid, e.g. cost should be positive.