Description

​

Educational Objectives: After completing this assignment the = student=20 should have the following knowledge, ability, and skills:

• Define a class hierarchy using inheritance=20

• Define a class hierarchy using multiple inheritance=20

• Define virtual member functions in a class hierarchy=20

• Implement a class hierarchy using inheritance=20

• Implement a class hierarchy using multiple inheritance=20

• Implement virtual member functions in a class hierarchy=20

• Use initialization lists to call parent class constructors for = derived=20 class constructors=20

• State the call sequence for constructors in an inheritance chain=20

• State the call sequence for destructors in an inheritance chain=20

• Define static (compile time) polymorphism=20

• Define dynamic (run time) polymorphism=20

• Use a class hierarchy to implement dynamic polymorphism

Operational Objectives: Create (define and = implement)=20 classes Box, Cylinder, Plane, = Vehicle,=20 Car, Truck, Van, Tanker, and=20 Flatbed and an object-oriented vehicle counter for use by the=20 Department of Transportation (DOT).

Deliverables: Seven (7) files: vehicles.h,=20 vehicles.cpp, shapes.h, shapes.cpp,=20 verbose.cpp, tracker.cpp, and makefile.

​The DOT Tracker Project

This project simulates an application called tracker for the = Department of Transportation (DOT) in which highway traffic data is = accumulated=20 in real time using various sensing equipment. The sensors can passively = detect a=20 vehicle and actively inquire further data when that vehicle is a truck. = For all=20 vehicles a serial number is collected. The serial number can be decoded = to=20 determine the vehicle type (car, truck/van, truck/tanker, = truck/flatbed),=20 passenger capacity, and, for trucks, the dimensions of its carrier. = Trucks=20 actively respond with their DOT license number as well.

Tracker is set up at a specific point on a roadway, for example at a = toll=20 booth or a specific segment of interstate highway. Once activated, it = keeps a=20 running account of the passing vehicles. It can report summary data and = also can=20 keep full reports of all vehicles passing the checkpoint within a = certain time=20 block.=20

​Procedural Requirements

1. Create and work within a separate subdirectory = cop3330/proj1.=20 Review the COP 3330 rules found in Introduction/Work Rules.

2. Begin by copying the following files from the course directory: = into your=20 proj1 directory:

proj1/tester.cpp
proj1/segment0.data
proj1/segment1.data
proj1/segment2.data
proj1/proj1submit.sh
area51/tester_s.x
area51/tester_i.x
area51/tester-bad_i.x
area51/tracker_s.x
area51/tracker_i.x

The naming of these files uses the convention that _s and=20 _i are compiled from the same cource code on program = (Sun/Solaris) and linprog (Intel/Linux), respectively. The=20 executables are distributed only for your information and = experimentation. You=20 will not use these files in your own project.

3. You are to define and implement the following classes: = Box,=20 Cylinder, Plane, Vehicle, Car,=20 Truck, Van, Tanker, and Flatbed. =

4. File shapes.h should contain the definitions of the = classes=20 Box, Cylinder, and Plane. File = shapes.cpp=20 should contain the member function implementations for these classes. =

5. File vehicles.h should contain the definitions of the = classes=20 Vehicle, Car, Truck, Van, = Tanker,=20 and Flatbed. File vehicles.cpp should contain the=20 implementations for these classes.

6. File verbose.cpp should contain the verbose versions of = the=20 various class implementations (both shapes and vehicles).

7. Create a client program for all of these classes in the file=20 tracker.cpp.

8. Create a makefile for all of the project in the file = makefile.=20

9. Turn in all seven (7) files vehicles.h, = vehicles.cpp,=20 shapes.h, shapes.cpp, verbose.cpp,=20 tracker.cpp, and makefile using the = proj1submit.sh=20 submit script.

Warning: Submit scripts do not work on the = program and=20 linprog servers. Use shell.cs.fsu.edu to submit = projects. If=20 you do not receive the second confirmation with the contents of your = project,=20 there has been a malfunction.

​Code Requirements and Specifications – Server Side

1. You are to define and implement the following classes:

Services (added or changed): =20

Class Name:	Box
float Volume() const // returns volume of box object =20
Private variables:	float length_, width_, = height_

Services (added or changed): =20

Class Name:	Cylinder
float Volume() const // returns volume of cylinder = object =20
Private variables:	float length_, = radius_

Services (added or changed): =20

Class Name:	Plane
float Area() const // returns area of plane object =20
Private variables:	float length_, = width_

Services (added or changed): =20

Class Name:	Vehicle
const char* SerialNumber () const // = returns serial number=20 unsigned int PassengerCapacity () const // returns passenger = capacity=20 float LoadCapacity () const // returns 0 const char* ShortName () const // returns "UNK" static VehicleType SnDecode (const char* sn)
Private variables:	char* serialNumber_; unsigned int passengerCapacity_;

Services (added or changed): =20

Class name:	Car
Inherits from:	Vehicle
const char* ShortName() const // returns "CAR" =20

Services (added or changed): =20

Class name:	Truck
Inherits from:	Vehicle =20
const char* ShortName () const // returns = "TRK" const char* DOTLicense () const // returns the license no =20
Private variables:	char* DOTLicense_;=20

Services (added or changed): =20

Class name:	Van
Inherits from:	Truck , Box =20
float LoadCapacity () const // returns = volume of box =20 const char* ShortName () const // returns "VAN"

Services (added or changed): =20

Class name:	Tanker
Inherits from:	Truck , Cylinder =20
float LoadCapacity () const // returns = volume of cylinder =20 const char* ShortName () const // returns "TNK"

Services (added or changed): =20

Class name:	Flatbed
Inherits from:	Truck , Plane =20
float LoadCapacity () const // returns = area of plane =20 const char* ShortName () const // returns "FLT" =20

2. Each class should have the following:=20

   1. Default constructor=20

   2. Parametrized constructor that initializes the class variables=20

   3. Destructor=20

   4. Private copy constructor prototype=20

   5. Private assignment operator prototype=20

   6. Follow the notation conventions:=20

      1. Compound names use uppercase letters to separate words=20 likeThis or LikeThis=20

      2. Class, method, and function names begin with upper case = letters=20 LikeThis=20

      3. Object and variable names names begin with lower case letters=20 likeThis=20

      4. Class member variables end with underscore likeThis_ =

3. Be sure to make exactly the methods virtual that are needed – that = is,=20 those that are overridden in derived classes. Do not make a method = virtual=20 unless it is needed virtual.

4. During development and testing of the classes, each constructor and = destructor should include a line of code that sends an identifying = message to=20 standard output. (This requirement serves as a code testing device. = These=20 identifying output statements will be removed after development. But = leave=20 them in verbose.cpp when you submit!) For example, the = Van=20 destructor should output the message “~Van()“.

5. The user-defined type VehicleType is an enumerated type: =

   Type name:	VehicleType
   Enumerated values:	badSn, vehicle, car, truck, van, tanker, flatbed =20

6. The static method VehicleType Vehicle::SnDecode(const char* = sn)=20 returns the vehicle type based on the first (index 0) character of the = serial=20 number sn according to this table:=20

      sn[0]: 0        1        2        3        4    =
    5        6
VehicleType: badSn    vehicle  car      truck    van      tanker   =
flatbed =20

7. After your classes have been fully developed and debugged, so they = compile=20 without warnings using the commands g++ -c -I. -Wall -Wextra=20 shapes.cpp and g++ -c -I. -Wall -Wextra vehicles.cpp, it = is time=20 to test with tester.cpp:=20

   1. Concatenate the files shapes.cpp and = vehicles.cpp into=20 the file verbose.cpp [command: cat shapes.cpp = vehicles.cpp >=20 verbose.cpp]. Add file documentation to verbose.cpp as = usual.=20

   2. #include shapes.h and vehicles.h into = verbose.cpp, between your file documentation and the = beginning of=20 the code.=20

   3. Make sure that verbose.cpp compiles to object code with = our=20 usual compile command g++ -c -Wall -Wextra -I. verbose.cpp. =

   4. Now compile the executable program tester.x with this = command:=20 g++ -otester.x -I. tester.cpp=20

   5. Thoroughly test your vehicle objects with this program. Note = that this=20 program prompts you for a serial number. The serial number is = decoded to get=20 a vehicle type, and an object of that type is created dynamically. = You=20 should see the constructor calls displayed, in correct order, = because tester=20 uses the verbose versions of your classes. Then the methods of this = object=20 are called. You should see correct serial number (and, for trucks, = dot=20 license) displayed. An “OOPS” message will be displayed if a problem = is=20 detected with your constructors. Finally the object is deleted, and = you=20 should see the destructors called in correct order. Read the source = code in=20 tester.cpp both to understand how it works and also for = hints on=20 how to do certain things in tracker.cpp.

8. After you have developed and thoroughly tested your Vehicles = classes as=20 above, it is time to prepare your classes for Tracker:=20

   1. Comment out the verbose output statements in the constructors = and=20 destructors in shapes.cpp and vehicles.cpp, but = leave them=20 in verbose.cpp=20

   2. We are now ready to proceed to client side development. =

​Code Requirements and Specifications – Client Side

1. You are to implement a client program tracker of the = vehicle=20 system described above.

2. Tracker processes data from a file that is input through = redirection and=20 sends results to standard output. (Thus tracker does not deal directly = with=20 files but reads from and writes to standard I/O.)

3. Tracker goes through the following processing loop:=20

   1. Read the number of vehicles in the next segment=20

   2. If the number is zero, exit=20

   3. For each vehicle in the segment,=20

      1. Decode the vehicle serial number=20

      2. If other data is needed, read that data=20

      3. Create a vehicle of the appropriate type using the data read = in the=20 previous steps=20

      4. Update various summary information for this segment

   4. After all the vehicles in the segment have been read and their=20 corresponding objects created, report a summary of the various = vehicles by=20 type, along with the total tonnage of the segment.=20

   5. After the summary, report the details: for each vehicle in the = segment:=20

      1. Report the vehicle data to screen=20

      2. Release the memory used to store the vehicle =

When in=20 doubt, use the distributed executables as a guide to output data and=20 formatting.=20

4. Note that the tracker processing loop continues until zero is read = for a=20 segment size. It may be assumed that the file of data is correctly = structured=20 so that whenever an appropriate item is expected, it is next in the = file. For=20 all vehicles, the data will begin with the serial number sn = and then=20 give the passenger capacity pc. For all specific truck types, = the=20 next entry will be the DOTlicense DOTL followed by the = dimension data=20 d1 d2 d3(optional). For example, a car, truck, van, tanker, = and=20 flatbed would have these lines of data:

sn pc
sn pc DOTL
sn pc DOTL d1 d2 d3
sn pc DOTL d1 d2
sn pc DOTL d1 d2

The dimensional data should be interpreted in the order d1 =3D = length,=20 d2 =3D width or radius, d3 =3D height. Note that = this is more=20 or less self-documenting in the data file segment0.data. = Note=20 also that we will assume that each vehicle and its data are in a = separate line=20 of the input file.

5. Tracker should instantiate the objects of a segment using an array = whose=20 elements are of type Vehicle *, that is, pointer to type=20 Vehicle. At the end of reading the segment data, this array = should=20 have pointers to vehicle objects representing the entire segment. = These=20 objects should exist until the line in the report representing the = object is=20 generated.

6. Use declared constants (not hardcoded literal values) for the = following:=20

   1. The maximum number of vehicles in a traffic segment (100)=20

   2. The maximum number of characters in a vehicle serial number (20) =

   3. The maximum number of characters in a truck DOT license (20) =

7. Check for a segment size greater than tracker can handle, and exit = if that=20 happens. Thus tracker would exit if either size 0 is read or some size = greater=20 than the declared constant 6.i above.

8. Your tracker.cpp source file should #include=20 <vehicles.h>, but not any of the other project = files. Your=20 makefile should create separate object files = vehicles.o,=20 shapes.o , and tracker.o and then create the = executable=20 tracker.x.

9. Do not submit “verbose” classes for tracker.

​Hints

• Model executables tester.x and tracker.x are for = your=20 information only – they are not needed for your project. However,=20 tester.cpp is indispensable: This is one of the test programs = that=20 will be used to assess your project. Moreover, it will help you debug = your=20 classes and gives some example code that can serve as a model for your = client=20 tracker program.

• To execute tester, enter a serial number at the prompt. The first = digit=20 determines the vehicle type. Tester uses the verbose implementations, = so you=20 should see all of the constructor and destructor calls for the = selected type.=20

• To execute tracker on a data file use redirection. For example,=20 enter
  prompt> tracker.x = <=20 segment2.data
  to run tracker.x with the data = file=20 segment2.data as input.

• All destructors should be declared virtual. Be sure = you=20 understand why. There will likely be an exam question related to = this.=20

• It is wise to develop and test all of the classes prior to working = on any=20 code for tracker.cpp. This way you can concentrate on class=20 development – some call this “wearing your server hat”. After = you are=20 satisfied that your classes are correct and ready for submission, = including=20 all documentation etc, only then do you switch to your “client” hat = and start=20 working on tracker.

If you were starting from “scratch”, you would first write a test = harness=20 like tester.cpp that exercises your classes and allows you to = debug=20 them as a system.

• The program tester.cpp is central to your effort in = several ways:=20

  • It allows you to debug your classes, prior to even thinking = about=20 tracker. This way, you are wearing your “server” hat while = classes=20 are being created. (One exception: memory management issues may not = be=20 exposed by tester.)=20

  • After the classes are debugged and working correctly, you change = to your=20 “client” hat and start working on the tracker program. The = file=20 tester.cpp has model code that you should understand in = every=20 detail and use as a model for your tracker code.=20

  • Note: you will likely see code similar to tester on = an=20 exam.

• To compile tester, a command line compile is all that is required, = because=20 the source code for the dependent files is included into the client=20 program:
  prompt> g++ -I. = -Wall=20 -Wextra -otester.x tester.cpp
  Note, this is different = from the=20 way you should compile tracker, which requires a makefile to manage = separate=20 compilation of all the code files.

• Your classes will be independently tested with client programs = written to=20 the interfaces defined above.

• Run the distributed executables for tester and tracker in=20 LIB/area51/ to see how your programs are expected to behave.=20