COSC 072: Computer Science II

Project 1
Spring 2008

Due: Feb 7 @ 5 PM
6 points

In this project, you will use classes, inheritance, and polymorphism to implement software that stores information about different varieties (or shapes) of pasta. For simplicity, we will assume that all pasta is one of two shapes, flat or round. Apologies to pasta lovers! Furthermore, we will not worry about storing so-called specialty shapes, such as orzo or fusilli. If your pasta knowledge is a little rusty, you may find helpful the information in Kyle Phillips' article The Pasta Shapes Glossary. Generally, in this project, we are concerned with sheet and strip (i.e., flat) pastas, and then extruded (i.e., round) pastas. I encourage you to think of better models for the pasta hierarchy.

I have drawn a class diagram for pastas using the Unified Modeling Language (UML), which appears in the image below. Computer scientists and software engineers commonly use UML to design software. We will discuss the diagram in class, but its interpretation should be relatively straightforward. Briefly, a rectangle represents a class and is divided into three sections for the class's name, its data members (or attributes), and its methods (or operators). Characters precede attributes and methods. The hyphen (-) denotes private, the pound sign (#) denotes protected, and the plus sign (+) denotes public.

As the diagram indicates, you should implement the Pasta class and derive two subclasses, Flat and Round. All pastas have a name and length, both of which must be protected. Flat pastas have a width, whereas round pastas have a diameter. Each class should have virtual methods that read and print the pasta's information from and to a stream. Naturally, the set methods should perform range checks and can fail silently when values are out of range. (We will learn proper methods of error handling for p2.)

Storing a single type of pasta is not very interesting, so also implement a Pastas (plural) class that stores Pasta objects in a C++ vector. As the composition link in the diagram indicates, there is a one-to-many relationship between the Pastas class and the Pasta class. The UML diagram depicts the vector as a private attribute of the Pastas class, but you can also derive Pastas from the vector class, as we did with the Numbers class in Homework 1. Implement methods to read pastas from a file, print the pastas stored in the vector, and compute the total volume of those pastas.

Design a file format for storing information about pastas, their type, name, width, and diameter. Fabricate data for a number of pastas named in Phillips' article, noting that pastas such as penne rigate consist of two strings. Store the information in the file pastas.dta.

In the main function, write a simple driver program that reads pastas from your data file, prints them to the console, and prints the total volume of the pasta. If the data file does not exist, then main should issue an appropriate message and exit.

Use stepwise refinement and incremental development. For example, implement the Pasta class and test it thoroughly before implementing, say, the Flat class.

All class definitions and class methods must be documented with Doc comments. Doc comments for class definitions must include @author and @version tags. Doc comments for methods must include @param and @return tags, where appropriate.

Getting Started

Although you may use any development environment for your project, it must compile and execute on seva. Make sure it compiles and runs without error before submitting.

Place all of your code in a subdirectory named p1. To create this subdirectory, type

seva% mkdir p1
To descend into the directory, type
seva% cd p1
All of the files for your project should be in this directory.

You must provide a working Unix Makefile with your submission. Start with this Makefile, which compiles a project consisting of main and pasta. You can copy it from my directory into your p1 directory on seva using the commands:

seva% cp ~maloofm/cosc072/Makefile ./
If you're coding on a Windows machine, you may need to edit the Makefile and change the .cc extension to .cpp.

If you want to copy files from the hw1 directory to the p1 directory, assuming you're in the p1 directory, to copy main.cc, type:

seva% cp ../hw1/main.cc ./
You can do the same for other files and edit them, rather than typing them from scratch.

At the top of the file main.cc (or the file containing the main function), place the following header comment, with the appropriate substitutions:

/*
 * COSC 072 Project 1
 * Name: <your name>
 * ID: <GoCard ID>
 * E-mail: <e-mail address>
 * Instructor: Maloof
 * TA: <TA's name>
 *
 * In accordance with the class policies and Georgetown's Honor Code,
 * I certify that, with the exceptions of the class resources and those
 * items noted below, I have neither given nor received any assistance
 * on this project.
 */

Instructions for Electronic Submission

If you need to include a message to your TA about your submission, then place the message in a file named README. Place the README file in the project's directory.

Assuming all of your code is in the subdirectory p1, directory, this directory and the submit program should be in the same directory:

seva% ls
p1/ submit.jar

To reduce the size of the zip file, before submitting, remove all object and executable files:

seva% cd p1
seva% make clean

If you need to include a message to your TA or me about your submission, then place the message in a file named README. Place the README file in the project's directory.

To move from the p1 directory to the parent directory, type

seva% cd ..
At this point, you should be above the p1 directory:
seva% ls
p1/ submit.jar

(Additional useful Unix commands)

When you are ready to submit, change the name of the directory to your netid. For example, if your netid is maloofm, then rename the directory p1 by typing

seva% mv p1 maloofm
Create a zip file of the directory and its contents by typing
seva% zip -r p1.zip maloofm/*
This command creates a zip file named p1.zip by recursively (-r) copying all of the files (*) from the directory maloofm/.

To submit the zip file type

seva% java -jar submit.jar -a p1 -f p1.zip
p1 is the name of the assignment (-a) and p1.zip is the file (-f) to be submitted for that assignment.

If the program submits the file successfully, you will receive a receipt by e-mail at the address <netid>@georgetown.edu.

Submit your project only once.

Once you've submitted your project, it is important to keep an electronic copy on a university machine (e.g., seva) that preserves the modification date and time. If we lose your project or the submission system breaks, then we will need to look at the modification date and time of your project to ensure that you submitted it before it was due.

You can also change the directory's name back to the original name. For example,

seva% mv maloofm p1
Note that changing the name of the directory does not change the dates of the files in the directory. You can also remove the zip file from your directory:
seva% rm p1.zip

The TA who will be grading your projects this semester is listed on the main page. You must submit your project before 5 PM on the due date.

Plan B

Note that you should execute Plan B only if Plan A fails for some reason. Submit is pretty reliable, but it is software. If you're running submit correctly and you see an error message labeled as SEVERE, then it's time to execute Plan B by using mail to submit your project.

To accomplish this, assuming the file you want to submit p1.zip, type at the seva prompt

seva% uuencode p1.zip p1.zip | mail cosc072@cush.georgetown.edu
Briefly, uuencode encodes the binary file p1.zip as an ASCII file that can be transmitted as mail. This form of the uuencode command pipes the ASCII-encoded file through standard input and into (|) the mail command.

When we receive you mail, we will save it to a file and use uudecode to translate the ASCII-encoded file back to the original binary file. Virtually all mail clients automatically encode binary files in this way.

Please don't use this account for communication. We don't check it regularly.

Copyright © 2019 Mark Maloof. All Rights Reserved. This material may not be published, broadcast, rewritten, or redistributed.