CMSC 202 Spring 2004
Project 5

Aircraft Template

Assigned Monday April 26, 2004
Design Due Sunday May 2, 2004 at 11:59pm
Program Due Sunday May 9, 2004 at 11:59pm
Updates 30 April
The first statement under the summary of restrictions was missing the word "NO". The original statement was
In particular, there are weight or volume restrictions when loading "things" and "things" do not automatically unload when the transport lands.
This statement has been edit to be In particular, there are NO weight or volume restrictions when loading "things" and "things" do not automatically unload when the transport lands.

29 April
The Exception Classes section including this statement which is misleading for some students: Implement an exception class named BadCmdLine that prints a different message for each potential problem with the command line..
No function of the BadCmdLine class actually prints a message. The BadCmdLine class contains a message which is printed in the catch block in main( ).
The statement has been reworded. A similar statament about the Transport exception class was removed.

28 April
The original .log files found in Mr. Frey's directory did not print the maximum number of items for the Transport as specified in the project description. New .log files have been provided.

Objectives

To gain experience with

Project Description

In this project you will be developing a C++ class template that models a generic Transport aircraft. A Transport aircraft carries "things" like Cargo, people, and water from one destination to another. We will use the Transport template for both a cargo plane and a commuter plane. In order to do so, the cargo plane and the commuter plane must have the same behavior. In particular this means that the cargo plane and commuter behave just a bit differently than in previous projects. The cargo Transport will carry Cargo objects as in previous projects. The commuter Transport will carry Person objects. In preparation for future enhancements or last minutes changes to this project specification, and rather than require another class to be implemented, "Person" is a typedef for a string.

As in project 4, you will be reading commands from a file and directing your Transport plane. Output will once again be written to a logfile.

You will also be designing and using your own exception classes. The conditions under which an exception is thrown are listed in the details below.

Project 5 is invoked with the following command line arguments in the order listed

  1. which type of Transport will be flown -- "cargo" or "commuter" (without the quotes)
  2. the name of the transport's city of origin
  3. the transport's minimum altitude
  4. the transport's maximum altitude
  5. the maximum number of items the transport can hold
  6. the name of the command file
  7. the name of the logfile

Your Tasks

  1. Copy Proj5.cpp and Proj5.h from Mr. Frey's public directory.
  2. Modify Proj5.cpp so that exceptions thrown from GetCmdLine( ) are caught and handled in main( ). As these are catastrophic, unrecoverable errors, your program should print an appropriate message and exit.
  3. Modify Proj5.h by adding the proper prototypes for GetCmdLine( ) and ProcessCommands().
  4. Implement GetCmdLine( ) and ProcessCommands( ) in Proj5Aux.cpp. See the functions section below.
  5. Implement the Transport class template as described below. The Transport class should be defined in Transport.h and be implemented in Transport.cpp.
  6. Implement exception classes to be thrown and caught by your code. Exception classes should be defined in P5Exceptions.h and be implemented in P5Exceptions.cpp.
  7. Modify the Cargo class as described below.

Classes

The Transport class template

The Transport class template supports the following functions which are very similar to those of the AirCraft class from project 4. In this description, assume that "T" is the template parameter.
  1. Transport( ) -- the default constructor
  2. Transport( const string& city, int minAltitude, int maxAltitude, int maxItems) where
    • city is the city of origin
    • minAltitude is the minimum flying altitude allowed
    • maxAltitude is the maximum flying altitude allowed
    • maxItems is the maximum number of "things" a Transport can carry, regardless of size, shape or weight
  3. void TakeOff (const string& whereTo) -- begins flying to the destination at the minimum altitude
  4. void Climb( int nrFeet ) -- increases the transport's current altitude by the number of feet specified. The transport may not fly above its maximum altitude. If attempting to climb too high an exception is thrown and the Transport levels off at the maximum altitude.
  5. void Descend( int nrFeet ) -- decreases the transport's current altitude by the number of feet specified. The transport may not fly below its minimum altitude. If attempting to descend too low an exception is thrown and the Transport levels off at the minimum altitude.
  6. void Land ( ) -- the transport arrives at the destination and sets the current altitude to zero
  7. void Load(const T& item ) -- loads the specified item onto the plane. If the plane is already full, an exception is thrown.
  8. void UnLoad( const T& item) -- unloads the specified item from the plane. If the plane is empty an exception is thrown. If the item is not on the plane, an exception is thrown.
  9. void Print(ostream& out = cout ) const -- Prints the status of the transport (min/max altitude, current altitude, max number of items, city of origin and destination if flying, current city if not flying). Prints the contents of the Transport.
  10. ~Transport( ) -- the Transport destructor
In addition, operator<< must be overloaded for the Transport class as a non-member, non-friend function.

The Cargo Class

This class models a single cargo container. The basic Cargo class is unchanged from project 4 except for the addition of operator==( ) which is used by code in the Transport class. As in project 4, Cargo containers are uniquely identified by their label and you may assume that no two containers have the same label.

The Cargo class interface is defined by these public functions:

operator<< must be overloaded as a friend of the Cargo class. operator<< prints all attributes of the cargo container in a format consistent with the sample output.

Exception Classes

There are two basic kinds of exceptions in project 5 -- those thrown by GetCmdLine( ) and those thrown by methods of the Transport class. You should design exception classes for the situations described below.

Implement an exception class named BadCmdLine that contains a different message for each potential problem with the command line. Each message must inform the user of the proper command line format. These exceptions are thrown by GetCmdLine() and caught in main( ). Each of these errors is fatal, so your program should terminate. Potential problems are

  1. Too few/many arguments
  2. Type of transport not "cargo" or "commuter"
  3. Unable to open command file or log file
  4. Min/Max altitude negative or inconsistent
  5. Max number of items not positive

Implement an exception class for Transport errors. The following exceptions will be thrown by some Transport member function and caught by ProcessCommands( ). None of these are fatal errors, so your program should continue processing the command file after handling each exception.

  1. An attempt is made to load an item onto a full Transport
  2. The transport is asked to climb too high
  3. The transport is asked to descend too low
  4. An attempt is made to unload an item from an empty Transport
  5. An item to be unloaded does not exist

The functions

GetCmdLine( )

This function is called once from main( ) to validate and interpret the command line arguments and to open the command and log files. You may assume that the command line arguments are of the appropriate type. An invalid command line should be handled in the manner described above under Exception classes.

ProcessCommands( )

ProcessCommands( ) reads the command file, invokes the appropriate Transport functions and writes to the logfile when appropriate. All commands must be logged to the logfile. This function is analogous to FlyMission( ) in project 4.

Note that this function is overloaded and is NOT a function template. One version of ProcessCommands( ) reads and interprets the commands for a cargo transport, the other reads and interprets commands for a commuter transport. For each command read, the appropriate Transport function is called. This function catches any exceptions thrown by the Transport.

The Command File

For this project, the orders for each aircraft will be read from a file as in project 4. Orders are processed by the ProcessCommands( ) function. As in project 4, each command and each data item will be on a separate line in the file. The format of the PRINT, LAND, TAKEOFF, CLIMB, DESCEND and QUIT commands are identical for all aircraft. Sample command files are available in Mr. Frey's public directory.
  1. PRINT
  2. LAND
  3. QUIT
  4. TAKEOFF <city>
  5. CLIMB <nr of feet>
  6. DESCEND <nr of feet>

    The format for LOAD and UNLOAD is different for each type of Transport, but is the same as project 4.

  7. LOAD
    • Cargo Transport : LOAD <label> <weight> <height> <width> <length>
    • Commuter Transport : LOAD <Person name>
  8. UNLOAD
    • Cargo Transport : UNLOAD <Cargo label>
    • Commuter Transport : UNLOAD <Person name>

Summary of Miscellaneous Project Requirements, Restrictions and Assumptions

Most of these are the same as project 4. New or substantially modified items are indicated with
  1. In order to use a template for both the CargoPlane and Commuter, their behavior must be the same. In particular, there are NO weight or volume restrictions when loading "things" and "things" do not automatically unload when the transport lands.
  2. You must create exception classes. You may NOT use ints, strings or any other built-in type as exceptions.
  3. You may assume that all Person names are unique.
  4. Sample command files, logfiles and scripts may be copied from Mr. Frey's public directory. See the sample output section below.
  5. You may assume that orders found in the command file make sense. For example, the Commuter will not be told to LOAD passengers when it is in flight and the CargoPlane will not be ordered to UNLOAD cargo while in flight.
  6. You may NOT assume that the command file or logfile exist.
  7. You may assume that all command file data is valid. In particular this means
    1. The format of the command files will be valid
    2. The values of all data in the command file will be valid (eg positive)
    3. The command files will contain no invalid commands
  8. All commands must be logged as they are being executed. Some (or all) of the command parameters must also be displayed. See the sample output.
  9. No public methods other than those specified are permitted.
  10. The cargo container label may be a multi-word label (eg. Tom's Books).
  11. All weight data must be output with 2 decimal points.
  12. You may assume that the destination city names are one word (i.e. no spaces).
  13. You may assume that commands do not contain spaces
  14. Your executable MUST be named Proj5 as that name is used in the testing/grading scripts.

Sample Output

The sample output is found in the logfiles in Mr. Frey's public directory. The command files and scripts which produced the sample output are also available. For example, the script p5Cargo1 reads commands from p5Cargo1.cmds and logs output to p5Cargo1.log. After copying the files to your local directory, type the name of the script.

It is not necessary that you follow their format exactly, but whatever format you choose must provide all required information, including tabular form for the cargo data.

  1. All numeric columns for Cargo items must be aligned and right justified.
    You may assume the Cargo dimensions are no more than 3 digits each
    You may assume the volume is no more than 12 digits
    You may assume the weight is no more than 12 digits (including 2 decimals)
    You may assume that the city names are no more than 20 characters
  2. You may assume that a Person's name is no more than 12 characters.
  3. The Transport's items should be printed one per line. You may assume that an item's details will fit on a single line.

Free Advice and Information

  1. Mr. Frey's public directory for this project is /afs/umbc.edu/users/d/e/dennis/pub/CMSC202/p5.
  2. When you copy the scripts from Mr. Frey's directory to yours, it may be necessary to give yourself permission to execute them. This is accomplished using the chmod command.
  3. Try to reuse as much code as possible from project 4 and/or project 3.
  4. DO NOT list Transport.o as dependency of Proj5 in your makefile. As a class template, Transport.cpp will be included and compiled as part of any .cpp file that includes Transport.h
  5. As a class template, Transport's code must be generic. Transport's code can have no "knowledge" of the type of "things" it will carry. For this project that means that Transport's code has no mention of Cargo or Person.
  6. Work with just one kind of Transport at a time. Get it working with all valid data, then add the Transport exceptions. Completing the second Transport will be much easier Transport will be complete.
  7. Complete the required project implementation before attempting the extra credit.

Project Design Assignment

Your project design document for project 5 must be named p5design.txt. Be sure to read the design specification carefully. Submit your design in the usual way: submit cs202 Proj5 p5design.txt

Extra Credit - 10 points

Only one exception class is thrown by the Transport functions, since only simple messages are output; there are no details. More detailed messages are more helpful to the user. For 10 points of extra credit, create a family of Transport exceptions that provide the details listed below. This will require the use of an inheritance hierarchy of Transport exceptions, polymorphism, templated exception classes and the use of ostringstream. The catch block(s) in ProcessCommands( ) may only catch the base class exception by reference and call a polymorphic function to print the appropriate message.

As this is a significant number of extra credit points, you are required to implement this feature with little or no help from the TAs, help center, instructors or Blackboard.

As part of your descriptive message, the following details are to be provided

  1. When an attempt is made to load an item onto a full Transport, print the number of items on the Tranpsort and print the item that was to be loaded.
  2. When the transport is asked to climb too high, print the current altitude, the requested altitude, and the maximum altitude.
  3. Whe transport is asked to descend too low, print the current altitude, the requested altitude, and the minmum altitude.
  4. When an attempt is made to unload an item from an empty Transport, print the item that was to be unloaded.
  5. When an item to be unloaded does not exist, print the item that was to be unloaded.
If you choose to implement the extra credit, submit a file named p5ExtraCredit.txt with your code to alert the grader.

Project Makefile

The "make" utility is used to help control projects with large numbers of files. It consists of targets, rules, and dependencies. You will be learning about make files in discussion. For this project, examine and understand the makefile for project 4, then modify it for project 5.

When you want to compile and link your program, simply type the command make or make Proj5 at the Linux prompt. This should compile all relevent source files and create your executable. executable named Proj5. Your executable MUST be named Proj5 as that name is used in the testing/grading scripts.

The make utility can also be used for compiling a single program without linking. For example, to compile Cargo.cpp, type make Cargo.o.

In addition to compiling and linking your files, make can be used for maintaining your directory. Typing make clean will remove any extraneous files in your directory, such as .o files and core files. Typing make cleanest will remove all .o files, core, Proj1, and backup files created by the editor. More information about these commands can be found at the bottom of the makefile.

Grading

The grade for this project will be broken down as follows. A more detailed breakdown will be provided in the grade form you receive with your project grade.

85% - Correctness

This list may not be comprehensive, but everything on this list will be verified by the graders.

15% - Coding Standards

Your code adheres to the CMSC 202 coding standards as discussed and reviewed in class.

Project Submission

Your executable must be named Proj5. Submit all files necessary to build the executable.

The order in which the files are submitted doesn't matter. However, you must make sure that all files necessary to compile your project (using the makefile) are listed. You need not submit all files at the same time. You may resubmit your files as often as you like, but only the last submittal will be graded and will be used to determine if your project is late. For more information, see the projects page on the course website.

You can check to see what files you have submitted by typing

submitls cs202 Proj5

More complete documentation for submit and related commands can be found here.

Remember -- if you make any change to your program, no matter how insignificant it may seem, you should recompile and retest your program before submitting it. Even the smallest typo can cause compiler errors and a reduction in your grade.

Avoid unpleasant surprises!
Be sure to use the submitmake and submitrun utilities provided for you to compile, link and run your program after you've submitted it.