C M S C     2 1 4
C o m p u t e r   S c i e n c e   I I
S p r i n g   2 0 0 2


Project #4

Due Saturday, April 27th, by 11pm
Sunday, April 28th, by 11pm
MONDAY, April 29th, by 11pm

Originally Posted: April 12, 2002

Corrections/Clarifications

Specifications on Text Fields/Buttons

This is to make it easier to find the buttons/text field specifications (it's also listed above in Corrections/Clarifications)

Button/Text Field Specs

Required Project

You must pass primary on this project by Friday, May 10, 2002 at 4 PM, or you will receive an `F' in the course, regardless of any other grades in the course. This primary must not be hardcoded. If so, it is NOT considered passing primary, and is furthermore, a violation of academic intergrity.

You will receive more points for the project if it is turned in within 3 days after the project is due. If you turn the project after 3 days late, you will receive 10 points for successfully passing the primary input, as long as it is turned in by May 10, 2002, at 4 PM. These criteria were stated in the syllabus.

Note: Final possible submission is due at 4 PM

Purpose

  1. To use the container classes written in Projects 1--3, to help develop classes in this project.
  2. To learn to use inheritance, including writing virtual functions, etc.
  3. To develop classes needed to solve a problem.
  4. To write documentation associate with each of the classes.
  5. To write clone() that will work with an inherited class and a driver (to be provided to you).
  6. To debug code from previous project, so that it doesn't give you problems on this one.

Academic Integrity Statement

Please note that *all* programming projects in this course (including this one) are to be done independently or with the assistance of the instructional staff of this course only.

Please review the policies outlined on the class syllabus concerning the use of class computer accounts and concerning the University's Code of Academic Integrity. The instructors of this course will review the programs submitted by students for potential violations of the Code of Academic Integrity and if it is believed that a violation has occurred it will be referred to the Office of Judicial Programs and the Student Honor Council.

Hardcoding is considered a violation of academic integrity

Checklist

Click here before submitting.

Project 4 Checklist

Design Background

In the first three projects, you've been developing and testing your classes, as well as writing documentation. While some of you may have grumbled about writing documentation, the purpose is to have you think about how you implement code before implementing code. This may seem like a tedious task, but it's important as tasks get larger, require more people, and require more planning. Writing larger code doesn't simply require more time, it requires more planning.

There are different ways to plan the design of the code. In fact, there's a whole subfield devoted to this: software engineering, with many "experts" espousing their ideas for how software should be written.

For example, some suggest describing what needs to happen in terms of "actors" and "actions" where "actors" are things that "do" actions. Actors becomes objects and classes, while their actions become methods. Diagrams can be drawn that show a scenario of how such actions are performed.

UML has been used to describe the interrelation of classes to other classes (including features such as inheritance, composition).

This course is not devoted to software engineering techniques, so you will base the design of classes based on your experience as a programmer, having taken at least two and a half semesters of programming.

Background

In this project, you will implement an online journal. There are two phases. The initial phase involves entering information about each member. The second phase involves actions that can be performed.

In particular, a user can

Background Reading

Please read the following.

Files Provided

A list of files will be provided soon!

Files Submitted

Use Project 4 Checklist (above) as final check for project submission

Documentation Files

If you wish to see a TA, you must have documentation for the classes you are writing. It's suggested that you write the documentation as you code.

Restrictions

Here are restrictions/requirements of the project.

More restrictions/requirements are coming.

Tasks

The following is a suggested way to approach the project.

Task 1: Date

Probrably the most important task is to create something that can store dates. Dates will consist of a month, day, year, hour, minute and AM/PM.

The format will look like:

April 10, 2002   3:40 AM
You should save this information in a convenient format (hint: use something that makes it easy to compare two dates).

Also, overload relational operators so you can compare dates.

Task 2: Make a base class for journal entry and MP3.

You should be able to compare objects of the base class (that is, if you dereference pointers of the base class) using comparison operators.

Call this AbstractEntry. Make this an abstract class from which the journal entry class and MP3 class.

Task 3: Spend time understanding how the posted files work.

There will also be a tutorial on this.

Task 4: Be able to "clone" a BST.

Posted: April 14, 2002

In the Projects/P4/Clone directory of the posting account, there are several classes. Shape is the base class. For some reason, cxx insists that the destructor, even if declared pure virtual, must be implemented. Not sure why. It shouldn't do that. The whole point of being pure virtual is so one doesn't implement the method. So, the destructor is now just virtual, instead of pure virtual.

For this part, rewrite your copy() method in BstSortedList so that it can handle BstSortedList<Shape *, ShapeComparator where you will need to write a ShapeComparator class to compare two Shape * objects.

This exercise is really interesting. It shows you how it's different to manage a container class which contains objects versus trying to manage a container classes with pointers to dynamically allocated objects. In Fall 2001, students discovered that it's difficult to create a container class that can manage both objects and pointers to dynamically allocated objects at the same time. It appears as if you can only store objects, or store pointers, but not have a simple way to manage both.

Your main goal is to make sure the copy constructor works on a BST that stores Rectangles, Triangles and Circles.

The following does NOT work:

void BST::copyRec( BST::Node * curr ) // curr points to node in "other" tree
{
  // copies the shape in the node of the other BST -- doesn't WORK!
  Shape * shapePtr = new Shape( curr->getData() ) ;

  // creates new node -- this is OK
  Node * nodePtr = new Node( shapePtr ) ;

  // more code
}
You can't copy the shape in the first line. Why not? Several reasons. First, Shape is abstract, so you can't create instances of it. Second, to create a new Shape you need to pass in an object, and curr->getData() returns a pointer (so you need to dereference, i.e. *curr->getData()). Third, even if Shape weren't abstract (and therefore you could create instances), you could only create Shape objects, not rectangles, triangles, etc.

The reason is simple: constructors can't be virtual! Why not? The reason is this. When you are calling a method that is virtual, you have a base class method on a derived object, and the derived object has a type. However, when you are calling a constructor, the constructor does NOT have a type yet. You are creating it.

Think about it. What type should new Shape( ... ) create? If there are more than one derived class, does it even make sense to have it virtual? It doesn't! But you may claim: why doesn't it use the parameter to determine which constructor to call?

That's a good obsevation. The problem? C++ doesn't support this kind of virtual function call. Virtual functions are determined based on the type of the object who is calling the method. It is NOT based on an object passed as parameter to a method, and what situation do we have here? We're trying to make it virtual based on the parameter of the constructor. Since C++ doesn't support this, it can't work.

So how do we solve the problem? Since constructors aren't virtual, we make a method that is virtual, and behaves like a constructor.

This is how it's done:

  // this is how you should call it!
  Shape * shapePtr = curr->getData()->clone() ;

  // creates new node -- this is OK
  Node * nodePtr = new Node( shapePtr ) ;

  // more code
clone() should be a virtual method in the base class.
  // In Shape.h
  virtual Shape * clone() const ;  // should make pure virtual

  // In Rectangle.h
  virtual Shape * clone() const ;  // overrides
The implementation should look like:
  Shape * Rectangle::clone() const {
      return new Rectangle( *this ) ; // call copy constructor  
  }
Similar for triangles and circles.

So your task is:

We will run a similar driver to test your code.

Debugging Hints

When you write the code, obviously, use a test driver. You need to submit it anyway, so use it.

Also, for ArrayList, it's a good idea to print a message indicating you've gone out-of-bounds, if the index is out-of-bounds. Notice that regular arrays won't tell you such things.

README

The README has been posted in the posting account (and README.directions). (POSTED SOON)

How to Submit Your Project

In order to successfully submit your project, it must pass the primary input and produce the primary output. The primary input will be sent to your project using input redirection.

   p4 < primary.input
Your program MUST produce the executable p4, EXACTLY, when the command "make" is run with no arguments. Thus, you must use a makefile named exactly "Makefile".

Your program must use cxx with the options -w0 -std strict_ansi. Unfortunately, while we have aliased this for you, it doesn't always work with Makefile, so use the full name in your makefiles.

We will use "diff -bwi" to test your code. This ignores case, treats N blanks as 1 blank, treats N blank lines as 1 blank line. We will also strip all blank lines from your input when matching to ours. However, diff is sensitive to punctuation, number of dashes, etc. so you should attempt to make your output match ours as closely as possible otherwise you may not be able to submit your program. If this is the case (that your program does not submit) you must fix your code until the output it produces matches that of the primary output. Note: "hardcoding" output is a violation of the University's Code of Academic Integrity.

To submit your project you must first combine the following files (and only these files) into a single tar file using the Unix tar command:

You may name your tarfile anything you want, but p4.tar is the suggested name.

NOTE! You should make a backup copy of all your files BEFORE attempting to create your tarfile!!!! You have been warned.

After creating the tar file you should submit that one file using the following command:

submit p4.tar 4
where p4.tar can be replaced by whichever tar file you have created, and 4 refers to the current project,

See the class syllabus for policies concerning email
Last Modified: Fri Apr 26 17:19:21 EDT 2002
left up down right home

Web Accessibility