UMBC CMSC 202
UMBC CMSC 202 CSEE | 202 | current 202

CMSC 202 Spring 2004
Project 4

Aircraft with
Inheritance and Polymorphism

Assigned Monday April 12, 2004
Design Due Sunday April 18, 2004 at 11:59pm
Program Due Sunday April 25, 2004 at 11:59pm
Updates 18 April
The project description states that you may alter the order of parameters for your functions. This IS NOT TRUE for constructors since Proj4.cpp will assume you have followed the parameter order specified in the project description

16 April
Your makefile should be submitted. It was inadvertently left off the list of files to submit.


Objectives

To gain experience with

Project Description

Our previous projects have asked you to model a CargoPlane in different ways. There are of course many types of aircraft other than CargoPlanes. In this project, we will model three types of aircraft -- CargoPlane, Commuter and Tanker. Just as a CargoPlane transports Cargo, a Commuter plane transports people and a Tanker transports water to assist in fighting fires.

Since all planes have common attributes and perform common functions, it's natural to design these planes in an inheritance hierarchy with a generic AirCraft class at the top.

For our small project, we have identified these attributes which are common to all aircraft

  1. The minimum altitude at which the aircraft flies.
  2. The maximum altitude at which the aircraft can fly.
  3. The current altitude at which the aircraft is flying.
  4. The city to which the aircraft is flying
  5. The city from which the aircraft took off for its destination
The actions common to all aircraft are
  1. Take off from the current city to the destination
  2. Land at the destination
  3. Climb to a higher altitude
  4. Descend to a lower altitude
  5. Report its current status
  6. Fly the missions assigned to it
In addition to these common actions, each of our planes will also Load and Unload something (cargo, water, people).

Classes

It is NOT necessary to dynamically allocate data members of any class for this project. If you have a working version of project 3 that does not use dynamic memory allocation, that would be a good place to start.

The AirCraft class

The AirCraft class is the base class for our hierarchy. The class provides the interface for all common aircraft actions listed above. All actions are implemented in the AirCraft class as virtual functions to provide the default aircraft behavior. For some actions, the derived classes will override or extend the default behavior and for some actions, the default behavior defined in the AirCraft class is sufficient.

FlyMission() is a pure virtual function which MUST be implemented in each derived class. Because AirCraft contains at least one pure virtual function, it is an "abstract" base class (aka "ABC") and it is therefore not possible to instantiate AirCraft objects.

The AirCraft class supports the following interface. No other public functions are permitted. The "const"ness of these functions is not specified and is left to you.

  1. AirCraft( ) - the AirCraft default constructor
  2. AirCraft( const string& startCity, int minAltitude, int maxAltitude) - an alternative AirCraft constructor
  3. virtual void TakeOff (const string& whereTo) - begins flying to the destination at the minimum aircraft altitude
  4. virtual void Climb( int nrFeet ) -- increases the aircraft's current altitude by the number of feet specified. The aircraft may not fly above its maximum altitude. If attempting to climb too high, the aircraft levels off at its maximum altitude and continues to the destination.
  5. virtual void Descend ( int nrFeet ) -- decreases the aircraft's current altitude by the number of feet specified. The aircraft may not fly below its minimum altitude. If attempting to descend too low, the aircraft levels off at its minimum altitude and continues to the destination.
  6. virtual void Land ( ) - the aircraft arrives at the destination and sets the current altitude to zero.
  7. virtual void Print(ostream& out = cout ) -- Prints the status of the aircraft (min/max altitude, current altitude, city of origin and destination if flying, current city if not flying).
  8. virtual ~AirCraft( ) - the AirCraft destructor.
  9. virtual void FlyMission ( const string& cmdFile, const string& logFile) = 0; This pure virtual function MUST be implemented in each derived class. This function reads orders from the cmdFile and documents its missions by recording all information in the logFile. Each plane supports the following orders, although the data required and the manner in which the order is carried out may be different for each aircraft type.
    "LOAD", "UNLOAD", "PRINT", "QUIT", "CLIMB", "DESCEND", "LAND", "TAKEOFF"

    A complete description of the command files is given below.

The CargoPlane class

The CargoPlane class models a single plane which contains zero or more Cargo containers and many additional attributes. The CargoPlane in this project does not use a FlightTable, nor calculate fuel usage, hours, or mileage. Unused code may be deleted or kept at your discretion. Changes/additions to the CargoPlane interface are highlighted with .

In addition to the public functions defined for the AirCraft class, the CargoPlane class interface is defined by these public functions. It may also be necessary to override and/or use one or more functions from the AirCraft class as part of the CargoPlane interface.

The Cargo Class

This class models a single cargo container. The Cargo class is unchanged from project 3, although dynamic memory allocation of data members is not required. As in project 3, 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.

The Commuter Class

A commuter plane carries people from their home city to the city in which they work. For simplicity in this project, a person will be modeled with a string that is the person's name. The name will not contain spaces. The necessary private data members are left to your discretion.

The Commuter class interface is defined by these public functions. No other public functions are permitted. It may also be necessary to override and/or use one or more functions from the AirCraft class as part of the Commuter interface.

The Tanker Class

A Tanker plane is a special plane used to fight fires. It is a plane that is capable of holding large amounts of water. A Tanker plane will leave its base city, then fill its water tanke by skimming the surface of a lake. The plane will proceed to its destination and drop its water on the fire. It then returns to the lake, refills and drops more water on the fire. When the Tanker lands, it lands at its original base city, not at the destination. The necessary private data members are left to your discretion.

The Tanker class interface is defined by these public functions. No other public functions are permitted. It may also be necessary to override and/or use one or more functions from the AirCraft class as part of the Tanker interface.

The Command File

For this project, the orders for each aircraft will be read from a file as in project 3. Orders are processed by the FlyMission( ) function in each derived class.

As in project 3, 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 aircraft

  7. LOAD
    • CargoPlane: LOAD <label> <weight> <height> <width> <length> (same as project 3)
    • Commuter : LOAD <person's name>
    • Tanker : LOAD
  8. UNLOAD
    • CargoPlane: UNLOAD <Cargo label> (same as project 3)
    • Commuter : Not Applicable
    • Tanker : UNLOAD

Summary of Miscellaneous Project Requirements, Restrictions and Assumptions

Most of these are the same as project 3. New or substantially modified items are indicated with
  1. Proj4.cpp will be provided for you. A sample Proj4.cpp is provided in Mr. Frey's public directory. You should copy this file to your directory and use it during your project development and testing. You should submit this file to use submitmake and submitrun.

    This file WILL BE DELETED and REPLACED with a new Proj4.cpp for grading. DO NOT make any changes to this file that might cause compiler/linker errors when it's replaced with the new Proj4.cpp. E.g. do not change the names of functions or add/remove #includes.

  2. Sample command files and logfiles may be copied from Mr. Frey's public directory.
  3. Limit all input/output to Print() and to FlyMission().
  4. Only operator<< for Cargo may be a friend of any class. operator<< may be overloaded for other classes, but not as a friend (there's no need).
  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 assume that the command files exist.
  7. You may assume that all input data is valid. In particular this means
    1. The format of the command files will be valid
    2. The values of all data 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. You may reorder the parameters in any function, but no new parameters may be added, and no parameter may be removed.
  11. The return types of the functions may not be changed.
  12. The cargo container label may be a multi-word label (eg. Tom's Books).
  13. The maximum weight of the plane may not be exceeded. Any cargo container that would cause the weight limit of the plane to be exceeded must not be loaded.
  14. The maximum volume of the plane may not be exceeded. Any cargo container that would cause the volume limit of the plane to be exceeded must not be loaded.
  15. If a person is not allowed to board the Commuter because the plane is full, a message should be logged.
  16. All weight data must be output with 2 decimal points.
  17. If a Cargo container cannot be loaded, an appropriate message indicating why it cannot be loaded should be displayed.
  18. You may assume that the destination city names are one word (i.e. no spaces).
  19. You may assume that commands do not contain spaces
  20. Your executable MUST be named Proj4 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 which produced the sample output are also available.

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.

Required formatting is the same as project 3.

  1. All numeric columns for Cargo 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. If the plane's weight and volume data form columns (as in the sample output below) they must be aligned and right justified.
    You may assume that the weight and volume are no more than 12 digits
  3. You may assume the Tanker's water capacity is 6 digits
  4. The Commuter's passenger list must be printed 5 persons per line, in right-justified columns. You may assume that each name is no more than 12 characters.

Free Advice and Information

  1. Mr. Frey's public directory for this project is /afs/umbc.edu/users/d/e/dennis/pub/CMSC202/p4.
  2. Work with the AirCraft and the CargoPlane first and ignore the Tanker and Commuter. Once the AirCraft and CargoPlane are working together, the Tanker and Commuter will be easier to do.
  3. Recall that the AirCraft class contains everything common to all the derived classes. This can apply to const ints and protected "helper" functions as well as public functions.
  4. "static" data members are permitted and may be helpful if defined in the AirCraft class
  5. "protected" data members are permitted in the AirCraft class, but private data members with protected accessors may be better.
  6. Review the class notes on the different methods of passing parameters. Each is best for a different situation and data type.

Project Design Assignment

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

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 2, then modify it for project 3.

When you want to compile and link your program, simply type the command make or make Proj4 at the Linux prompt. This will compile Proj4.cpp, CargoPlane.cpp, Cargo.cpp, AirCraft.cpp, Tanker.cpp, and Commuter.cpp create the executable named Proj4. Your executable MUST be named Proj4 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

Submit the following files for your project. You MUST use these filenames
  1. Proj4.cpp - contains main(). Remember that this file will be replaced for grading
  2. Cargo.cpp - implementation of the Cargo class
  3. Cargo.h - interface for the Cargo class
  4. CargoPlane.cpp - implementation of the CargoPlane class
  5. CargoPlane.h - interface of the CargoPlane class
  6. AirCraft.cpp - implementation of the AirCraft class
  7. AirCraft.h - interface of the AirCraft class
  8. Tanker.cpp - implementation of the Tanker class
  9. Tanker.h - interface of the Tanker class
  10. Commuter.cpp - implementation of the Commuter class
  11. Commuter.h - interface of the Commuter class
  12. Your makefile
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 Proj4

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.


Last Modified: Sunday, 18-Apr-2004 20:41:02 EDT