Project 4 is worth 9% of your grade. Note that the due date for this project is just before the Thanksgiving break so you should use your time wisely on this project to avoid being rushed just before the break.

NOTE: failure to follow ANY of the general guidelines outlined in this and prior project descriptions in this course may result in the loss of points on this project.

As with all projects it is extremely important to begin early. There are generally a number of details contained in a project description such as this one. Please note that failure to follow the details outlined in the project description could result in a substantial loss of points so it is very important to pay close attention to the project description.

THE FOLLOWING IS TAKEN DIRECTLY FROM THE COURSE SYLLABUS (but changed to state that credit may be as high as 25% for projects submitted after the 2 day late period and the final deadline to submit this project is Friday, December 10th by 11pm):

Each student is required to successfully submit project #4 to pass the course. If a student is unable to complete project #4 (up to the MRC), the student receives an F for the final course grade, regardless of any other grades. Passing project #4 does not guarantee you will pass the course. However, failing to complete project #4 (up to the MRC) does guarantee that a student will receive an F.

Due to the importance of completing this assignment a student will be allowed to submit it up until Friday, December 10th at 11pm. Any project #4 submission made after the end of the 2 day late period and up until 11pm on 12/10/2004, that meets the MRC, will receive a score no greater than 25 (out of 100).

Note that email regarding project questions will go unanswered and the means for obtaining assistance on a project is through office hours. See the course syllabus for additional information regarding these policies. In particular the course syllabus states that email is for "emergency purposes only" and if you do send email you must include the appropriate information (including your full name, login ID and class section number) - as specified on the class syllabus.

To enhance and extend project 3 using inheritance to permit heterogenous data structures.

So far our binary search tree and the doubly-linked list data structures have stored the same kind of elements at a time (e.g., a binary search tree of Events or a doubly-linked list of AMember objects). In this project we want to change this. We want to store in a single binary search tree and in a single doubly-linked list different kinds of objects. In this project, the binary search tree will be able to store, simultaneously, not only Event objects, but also two new kinds of objects: TimedEvent and TeamEvent objects. Similarly, the doubly-linked list will be able to store two kinds of objects at the same time: Athlete and Coach objects.

The mechanism making possible the new data organization is inheritance and polymorphism. In order to give you a complete exposure to these topics, we will modify project #3 Event class into a non-abstract base class supporting the derivation of the classes TimedEvent and TeamEvent from it. Also, we will modify project #3 AMember class into an abstract base class supporting the derivation of the classes Athlete and Coach. Notice that because AMember is now an abstract class, we no longer will instantiate objects of this kind. By following the above approach you will be expose to inheritance/polymorphism issues in the context of both abstract/non-abstract base classes.

This project could be considered to be one not as long as the previous ones but it may require more thought. You will need to provide .h and .cpp files for the derived classes of this project (you will be graded on how you design these classes). Some modifications will be required to the binary search tree and the doubly-linked list implementations from project #3 so that your implementation handles correctly the new kind of data. The DataManager class will require some modifications as well.

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 and below concerning the use of class computer accounts (Acceptable Use Guidelines) and concerning the University's Code of Academic Integrity. The instructors of this course will review all of 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.

Note that "hardcoding" is also considered a violation of academic integrity.

If you are unclear about any of the policies of this course you should ask either of the instructors for further clarification. NOTE: unless explicitly specified otherwise these policies apply to all assignments in this course:

Code of Academic Integrity
Guidelines for Acceptable Use of Computing Resources

All your programs in this course should be written in ANSI C++, which means they must compile and run correctly with "cxx -w0 -std strict_ansi" on the OIT UNIX Class Cluster (dc.umd.edu).

Your program must have a comment near the top which contains your name, login ID, your section number, your TA's name, an estimated time it took to complete the project (in hours) and an original description of the action and operation of the program (thus at least 6 items neatly organized and easy to read).

Your program should be written using good programming style and formatting, as discussed in class and throughout your textbook. For this project, style is considered to consist of:

• neat and proper indentation and formatting (including both "horizontal" and "vertical" whitespace - blank lines)
• keeping all lines less than 81 characters long
• writing clear and readable code
• commenting code as necessary - each method/function you define in a .cpp (source) file must have a "header" comment at the top of the method/function including the name of the method/function, a brief description of what it does (including any data members it modifies).
• generally (but not necessarily always) any "stretch of code" longer than 6-10 lines should have one or more comments (sometimes certain sections of code will have more comments than others but in general there should be comments interspersed with your code).
• using meaningful and descriptive names for functions and variables

Answers to "frequently asked questions" will be posted via the main projects page. Prior to asking a question or submitting a project you should check the FAQ to see if any important information has been covered there. In addition to answers to FAQ's, any important information pertaining to a project will be posted on it's FAQ.

Note that the FAQ is considered part of the project description and thus just as important to read and review - even after you have submitted a project you should periodically check AND READ any new FAQ's posted. Once the project deadline has passed no new FAQs will be entered for that project and thus you can then stop checking it.

Overview of the classes

The Name and NameList classes from Project #3 will be used for this project. If those classes work correctly, there should be no need to modify them for this project. You should be able to copy the .h and .cpp files from Project #3 into your Project #4 directory. However, if those classes have errors, you must fix the problems prior to starting this project.

The Event.h class will be modified to be a non-abstract base class from which two new classes (TimedEvent and TeamEvent) will be derived. The TimedEvent class represents events which are timed (like running and swimming events) and the TeamEvent class represents events which are team events (like water polo or soccer).

The AMember.h class will be modified to be an abstract base class from which two new classes (Athlete and Coach) will be derived. The Athlete class represents association members that are athletes, and the Coach class represents association members that are coaches.

You must fix any problems (if any) associated with the binary search tree and doubly-linked list implementations. In this project you will need to modify the prototype of some of the methods of your BST, BSTIter, DLL, and DLLIter classes. Make sure your tree and linked-list implementation are properly working before modifying them for this project. More details about this matter can be found later on in the description.

A new version of the DataManager.h file has been provided for you. You will need to make modifications to the DataManager.cpp file so that it correctly implements the functionality expected for this project.

Classes to implement or modify:

Below, we provide a description of each of the classes you are to implement. For SOME of these classes there is a .h file that can be found in the posting account. The name for the methods to be described are as specified in the .h files (when in doubt follow the name presented in the .h file). You can modify copies of the files posted only if the project specification below requires or permits you to do so. There are at least two files you are NOT expected to modify: the DataManager.h and main.cpp files (and possibly others).

There may be some references to BNF entries defined in the descriptions of project #1, #2 and #3 (we will not provide the description for those entries in the current project description)

Class Name	Brief description of the class
Name and NameList	Same as in project #3.
Event and AMember	Modified to be base classes (one abstract the other not).
DLL and DLLIter	Modified slightly.
BST and BSTIter	Modified slightly.
TimedEvent and TeamEvent	Two new classes derived from the Event class.
Athlete and Coach	Two new classes derived from the AMember class.
DataManager	The execution of commands (e.g., adding/removing Events) will be possible via this class. In the main() function of the application an object of this class will be created, and any processing requests will be sent to the DataManager object for processing. This class (as well as main.cpp) has been modified for project #4 to incorporate the new additions/modifications.

Details of the classes to implement

In this project the C++ string class is being used to represent strings. Make sure you include the <string> and not the <string.h> library header file in order to use the C++ string class library.

a. Changes required to the prototype of public methods:
-------------------------------------------------------
   i. find - NEW PROTOTYPE:  bool find(BSTDataKey Key, BSTData *&entry)

             Initializes the data object pointer reference parameter 
             with a dynamically-allocated copy of the data object of 
             the entry of the tree, associated with a particular key 
             value; true is returned in this case.  A value of false 
             must be returned if an entry with a particular key value 
             is not found; the pointer reference argument must be 
             left unmodified in this case.  

             The caller of this method is responsible for 
             deallocating the copy of the object generated by find 
             (if the entry looked for is found).  The pointer 
             variable argument provided to the find method is not 
             associated with any dynamically allocated memory area at 
             the time of calling find (there is no need in find to 
             deallocate the memory area associated with the pointer 
             parameter as there is none).  If an entry with the
             specified key value is not found, the pointer reference
             argument must be left unmodified.

b. Additional info 
------------------
   i. You cannot add any public methods to the BST class.  You cannot
      change the parameters, return types or constness of any public
      methods either.

  ii. You can add any private methods you want to the BST class as
      long as the methods specified above are implemented.  You cannot
      add any public items to the BST class.

 iii. You cannot modify the BST structure (meaning the tree's shape per
      the "basic" insert/delete used in project #3).

  iv. As you are aware, polymorphism only works with pointers and
      references to objects.  Thus, you must check your implementation 
      making sure that polymorphism is possible when required.
  
   v. You must check your object assignment operations or any
      initialization operation involving two objects.  Because
      we are dealing now in an environment with heterogenous objects,
      initializations of objects that used to work in Project #3 may no
      longer work for this project.  Initialization of one object out 
      of another happens in different scenarios; check all such 
      scenarios in your implementation, making sure your code will 
      behave as expected.  For example if your code attempts to assign
      an Athlete object into a Coach object this may cause problems if
      not handled properly (for example, should it happen?  YOU must
      answer that question when developing your code).

  NOTE: The declaration for this class is in the BST.h file.  The
        methods must be implemented in the BST.cpp file.

ADDITIONAL NOTE: This class is not required (since it was extra credit
                 in project #3).

a. Changes required to the prototype of public methods:
-------------------------------------------------------
   i. getCurrent - NEW PROTOTYPE:  const BSTData &getCurrent() const

                   Return type has been changed from a value parameter
                   to a constant reference parameter.

b. Additional info
------------------
   i. Issues mentioned above in 1.b.iv and 1.b.v apply here as well.

a. Changes required to the prototype of public methods:
-------------------------------------------------------
   i. find - NEW PROTOTYPE:  bool find(DLLDataKey Key, DLLData *&entry)

             Initializes the data object pointer reference parameter 
             with a dynamically-allocated copy of the data object of 
             the entry of the dll, associated with a particular key 
             value; true is returned in this case.  A value of false 
             must be returned if an entry with a particular key value 
             is not found; the pointer reference argument must be 
             left unmodified in this case.  

             The caller of this method is responsible for 
             deallocating the copy of the object generated by find 
             (if the entry looked for is found).  The pointer 
             variable argument provided to the find method is not 
             associated with any dynamically allocated memory area at 
             the time of calling find (there is no need in find to 
             deallocate the memory area associated with the pointer 
             parameter).  If an entry with the specified key value is 
             not found, the pointer reference argument must be left 
             unmodified.

b. Additional info 
------------------
   i. You cannot add any public methods to the DLL class.  You cannot
      change the parameters, return types or constness of any public
      methods either.

  ii. You can add any private methods you want to the DLL class as
      long as the methods specified above are implemented.  You cannot
      add any public items to the DLL class.

 iii. You cannot modify the DLL structure.

  iv. As you are aware, polymorphism only works with pointers and
      references to objects.  Thus, you must check your implementation 
      making sure that polymorphism is possible when required.
  
   v. You must check your object assignment operations or any
      initialization operation involving two objects.  Because
      we are dealing now in an environment with heterogenous objects,
      initializations of objects that used to work in Project #3 may no
      longer work for this project.  Initialization of one object out 
      of another happens in different scenarios; check all such 
      scenarios in your implementation, making sure your code will 
      behave as expected.  For example if your code attempts to assign
      an Athlete object into a Coach object this may cause problems if
      not handled properly (for example, should it happen?  YOU must
      answer that question when developing your code).

  NOTE: The declaration for this class is in the DLL.h file.  The
        methods must be implemented in the DLL.cpp file.

a. Changes required to the prototype of public methods:
-------------------------------------------------------
   i. getCurrent - NEW PROTOTYPE:  const DLLData &getCurrent() const

                   Return type has been changed from a value parameter
                   to a constant reference parameter.

b. Additional info
------------------
   i. Issues mentioned above in 3.b.iv and 3.b.v apply here as well.

  NOTE: THIS CLASS HAS CHANGED SOME - the provided file Event.h provides
        the new class declaration to be associated with the Event class.

a. Changes
----------
   i. The readin and writeout methods are now virtual.  Their
      implementation should be the same as in project #3 (meaning
      they don't change - they are just virtual now).

b. New methods (public)
--------------
   i. virtual ~Event() - The class now has a virtual destructor.

  ii. virtual string classType() const - This method returns a string
                identifying the type of object.  The string value
                to return will be "Event".

 iii. virtual Event * duplicate() const - Dynamically allocates a
                copy of the current object.  Returns an Event pointer
                pointing to the dynamically allocated object.

c. New data member (protected)
------------------
   i. type - string used to store the type of object - for example
             an Event object must put "Event" in this string.  Any
             derived objects MUST put their "name" in this string -
             for example a TimedEvent object MUST put "TimedEvent"
             in this string (and NOT "Event").

d. Additional info
------------------
   i. You cannot modify the Event.h file except when explicitly
      permitted - in particular you can add protected and private
      "helping" functions, you can NOT add data members at all and
      you can not change/remove any of the parts already in Event.h

  ii. The implementation for methods not mentioned above will
      be the same as those used in project #3.

 iii. There are no new data members.

  iv. Remember, this class will be a non-abstract base class.

a. Overview
-----------
  You must define this class using the Event class as a base class
  (otherwise you will receive a 0 grade in the project).  The file
  TimedEvent_interface presents the interface to be associated with
  the TimedEvent class.  NOTICE THAT THIS FILE JUST ILLUSTRATES THE
  METHODS THAT MUST BE AVAILABLE VIA AN INSTANCE OF THE CLASS.  You
  must use the Event class and inheritance/polymorphism in order to
  write a TimedEvent class that implements the same functionality and
  interface specified by the TimedEvent_interface file.

  You will be penalized for a TimedEvent class implementation that
  doesn't make appropriate use of inheritance/polymorphism in order
  to implement the TimedEvent class.  For example, implementing
  a string getTitle() const method in the TimedEvent class is wrong;
  that's a method already available in the Event base class.

b. Methods
----------
   i. data members -

      In addition to the title, year, venue, start_day, duration and
      participants data members (that you are already familiar with)
      the TimedEvent class has the following data members:

      wr => float representing the World Record (wr) time for this
            event (in seconds - so 30.5 would be 30 and 1/2 seconds).

      wrHolder => Name object representing the name of the individual
                  who set the World Record.

      or => float representing the Olympic Record (or) time for this
            event (note this could be the same as the wr time).

      orHolder => Name object representing the name of the individual
                  who set the Olympic Record.

  ii. methods -

      constructor - The constructor must take the parameters
      specified in the TimedEvent_interface file.  The default values
      required for each parameter are as specified in that file.

      dtor - You must determine whether or not to write the dtor.

      copy constructor/assignment operators - You must determine
      whether copy constructor and assignment operators are required
      for this class.

      comparison operators - typical comparison operators (e.g.,
      ==, !=, etc.) are associated with a TimedEvent object.  Comparison
      of two TimedEvent objects is based only on the title data member
      (like we did for Event class).  That means that two TimedEvent
      objects having the same title are considered equal no matter
      the value each one may have for any of the other data members.

      duplicate - You must add a public const method called
      duplicate() that returns a pointer to a dynamically
      allocated copy of the current object.  The type of
      the pointer value returned should be Event *.

      get methods - For each of the data members, there is a public
      method that allows us to retrieve the data member value.

c. Additional info
------------------
   i. IMPORTANT: In the TimedEvent class you can NOT declare operator>>
                 and operator<< as friend functions but you must be
                 able to do input and output for objects of the class
                 using operator>> and operator<< .  The expected inputs
                 and outputs are defined by the BNFs <TimedEvent_in> and
                 <TimedEvent_out> respectively.

  ii. It is your responsibility to determine which methods to
      declare in the class.  Remember that you will be penalized for
      unnecessary methods declared in the class, and for methods you
      fail to declare.

 iii. Feel free to add any private or protected functions you feel are
      necessary.

  iv. You cannot add any public data members to the class and can only
      add those data members specified above.

   v. This class should be designed so that other classes can inherit
      from it (use it as it's base class).

  vi. You should use "good style" when writing your class and this
      includes making items const when possible or passing by reference
      or making functions virtual (and using the keyword virtual when
      appropriate even if it is not needed) (same goes for the rest of
      the classes you write below).

d. BNFs
-------

   <TimedEvent_in> ::= <event_in><ws><wr><ws><name_in><ws><or><ws><name_in>
              <wr> ::= <float>
              <or> ::= <float>

  <TimedEvent_out> ::= <event_out>"WR: "<wr_out>" held by: "<name_out><endl>
                       "OR: "<or_out>" held by: "<name_out><endl>
          <wr_out> ::= <mins>:<secs>.<huns>
          <or_out> ::= <mins>:<secs>.<huns>
            <mins> ::= (integer value 0 or greater)
            <secs> ::= 00 | 01 | 02 | 03 | 04 | ... | 57 | 58 | 59
            <huns> ::= (integer printed to 2 decimal places)

NOTE: the mins:secs:huns output must be accurate to 1/100th of a second
      (so for example if 65.3561 is the input the output must be 1:05.35
       or 1:05.36)

a. Overview
-----------
  You must define this class using the Event class as a base class
  (otherwise you will receive a 0 grade in the project).  The file
  TeamEvent_interface presents the interface to be associated with
  the TeamEvent class.  NOTICE THAT THIS FILE JUST ILLUSTRATES THE
  METHODS THAT MUST BE AVAILABLE VIA AN INSTANCE OF THE CLASS.  You
  must use the Event class and inheritance/polymorphism in order to
  write a TeamEvent class that implements the same functionality
  and interface specified by the TeamEvent_interface file.

  You will be penalized for a TeamEvent class implementation that
  doesn't make appropriate use of inheritance/polymorphism in order
  to implement the TeamEvent class.  For example, implementing a
  string getTitle() const method in the TeamEvent class is wrong;
  that is a method already available in the Event base class.

b. Methods
----------
   i. data members -

      In addition to the title, year, venue, start_day, duration,
      and participants data members, which you are already familiar
      with, the TeamEvent class has the following data members:

      exhibition => boolean indicating whether or not this is an
                    exhibition event (most are not).

      numTeams => integer representing the number of teams
                  associated with the event.

      teams => dynamically-allocated array of strings representing
               the team names associated with the event.

  ii. methods -

      constructor - The constructor must take the parameters
      specified in the TeamEvent_interface file.  The default
      values required for each parameter are as specified in
      that file.

      dtor - You must determine whether or not to write the dtor.

      copy constructor/assignment operators - You must determine
      whether copy constructor and assignment operators are required
      for this class.

      comparison operators - typical comparison operators (e.g.,
      ==, !=, etc.) are associated with a TeamEvent object.
      Comparison of two TeamEvent objects is based only on the
      title data member (like we did for Event class).  That means
      that two TeamEvent objects having the same title are
      considered equal no matter the value each one may have for
      any of the other data members.

      duplicate - You must add a public const method called
      duplicate() that returns a pointer to a dynamically
      allocated copy of the current object.  The type of
      the pointer value returned should be Event *.

      get methods - For each of the data members, there is a public
      method that allows us to retrieve the data member value.

      isExhibition - returns true is the event is an exhibition
      event; false otherwise.

c. Additional info
------------------
   i. IMPORTANT: In the TeamEvent class you can NOT declare
      operator>> and operator<< as friend functions but you must be
      able to do input and output for objects of the class using
      operator>> and operator<< .  The expected inputs and outputs
      are defined by the BNFs <TeamEvent_in> and <TeamEvent_out>
      respectively (see BNFs below).

  ii. It is your responsibility to determine which methods to
      declare in the class.  Remember that you will be penalized for
      unnecessary methods declared in the class and for methods you
      fail to declare.

 iii. You cannot add any public data members to the class and you can
      only add those data members explicitly specified above.

  iv. If there are no teams associated with an event, 0 will show up
      as the number of teams.

   v. The getTeams() must dynamically allocate an array, copy the array
      of the current object into the newly allocated array, and then
      return a pointer to this array.  The caller of the function will
      take care of deallocating the memory associated with the array.
      If the number of teams is 0, then NULL should be returned by the
      function, and no dynamic memory allocation should take place.

d. BNFs
-------

   <TeamEvent_in> ::= <event_in><ws><exhibit><ws><num_teams><ws><teams_in>
        <exhibit> ::= EXHIBIT | OFFICIAL
                      (if it is EXHIBIT then this is an exhibition event)
      <num_teams> ::= (integer >= 0)
       <teams_in> ::= <teams_in><team_in><ws> | <empty>
        <team_in> ::= <projstring>

  <TeamEvent_out> ::= <event_out><exhibit_out><endl><teams_out>
    <exhibit_out> ::= "Exhibition: No" | "Exhibition: Yes"
      <teams_out> ::= "Teams:"<endl><teamlist_out> | "Teams:"<endl>"none"<endl>
   <teamlist_out> ::= <team_out><endl> | <teamlist_out><team_out><endl>
       <team_out> ::= <projstring>

NOTE: the list of teams should be printed out in ascending sorted order
      (based on the C++ string < (less than) operator) ALSO NOTE that the
      getTeams() function should return a copy of the teams array and the
      teams must be in ascending sorted order in that copy.

  The file AMember.h provides the new class declaration to be associated
  with the AMember class.

a. Changes
----------
   i. The readin and writeout methods are now "abstract" methods (pure
      virtual).

  ii. The type data member has been REMOVED.

 iii. The getType member function has been REMOVED.

b. New methods
--------------
   i. virtual ~AMember() - The class now has a virtual destructor (it
                           is possible/better for this dtor to be
                           "pure" virtual, but it is NOT on purpose -
                           do not change this fact).

  ii. virtual string classType() const = 0 - Abstract (pure virtual)
                method which will be used to return a string
                identifying the type of object.

 iii. virtual AMember * duplicate() const = 0 - Abstract method
      returning a dynamically-allocated copy of the current object.
      An AMember pointer pointing to the allocated object is
      returned by this method.

  iv. Remember, this class is an abstract class.

c. Additional info
------------------
   i. You cannot modify the AMember.h file - except you are permitted
      to write any protected or private helping functions you want.
      You can NOT add any data members at all and you can NOT make any
      changes to or remove anything already found in AMember.h

  ii. The implementation for methods not mentioned above will
      be the same as those used in project #3.

 iii. There are no new data members (and the data member type has
      been removed).

a. Overview
-----------
  You must define this class using the AMember class as a base class
  (otherwise you will receive a 0 grade in the project).  The file
  Athlete_interface presents the interface to be associated with the
  Athlete class.  NOTICE THAT THIS FILE JUST ILLUSTRATES THE METHODS
  THAT MUST BE AVAILABLE VIA AN INSTANCE OF THE CLASS.  You must use
  the AMember class and inheritance/polymorphism in order to write an
  Athlete class that implements the same functionality and interface
  specified by the Athelete_interface file.

  You will be penalized for an Athlete class implementation that does
  not make appropriate use of inheritance/polymorphism in order to
  implement the Athlete class.  For example, implementing a string
  getName() const method in the Athlete class is wrong; that is a
  method already available in the AMember abstract base class.

b. Methods
----------
   i. data members -

      In addition to the name, year, and email data members
      which you are already familiar with, the Athlete class
      has the following data members:

      professional => boolean indicating whether the athlete is
                      a professional athlete or not (if not, they
                      are considered an amateur athlete).

      testResults => string representing the drug test results
                     for this athlete (it may be empty or contain
                     a string per the BNF below).

  ii. methods -

      constructor - The constructor must take the parameters
      specified in the Athlete_interface file.  The default values
      required for each parameter are as specified in that file.

      dtor - You must determine whether or not to write the dtor.

      copy constructor/assignment operators - You must determine
      whether copy constructor and assignment operators are required
      for this class.

      classType - this method must return the string "Athlete" (NOTE
                  that there is no data member which stores the type -
                  the function just returns it - you could say that
                  it is "hardcoded").

      duplicate - You must add a public const method called
                  duplicate() that returns a pointer to a dynamically-
                  allocated copy of the current object.  The type of
                  the pointer value returned should be AMember *.

      get methods - For each of the data members, there is a public
      method that allows us to retrieve the data member value.

c. Additional info
------------------
   i. IMPORTANT: In the Athlete class you can NOT declare
      operator<< and operator>> as friend functions but you must be
      able to do input and output for objects of the class using
      operator<< and operator>> .   The expected inputs and outputs
      are defined by the BNFs <Athlete_in> and <Athlete_out>
      respectively.

  ii. It is your responsibility to determine which methods to
      declare in the class.  Remember that you will be penalized
      for unnecessary methods declared in the class and for methods
      you fail to declare.

 iii. You cannot add any public data members to the class.

  iv. If there are no events associated with this Athlete, 0 will show up
      as the number of events.

   v. The getEvents() must dynamically allocate an array, copy the array
      of the current objects into the newly allocated array, and then
      return a pointer to this array.  The caller of the function will
      take care of deallocating the memory associated with the array.
      If the number of events is 0, then NULL should be returned by the
      function, and no dynamic memory allocation should take place.

d. BNFs
-------

      <athlete_in> ::= <NEW_amember_in><ws><professional><ws><test>
  <NEW_amember_in> ::= <maybews><name_in><ws><year_in><ws><email_in>
    <professional> ::= PROFESSIONAL | AMATEUR
            <test> ::= <projstring>

     <athlete_out> ::= <NEW_amember_out><endl><prof_out><endl><test_out>
 <NEW_amember_out> ::= <name_out>" "<year_out><email_out>
        <prof_out> ::= "Professional: No" | "Professional: Yes"
        <test_out> ::= "Test results: "<test><endl>

a. Overview
-----------
  You must define this class using the AMember class as a base class
  (otherwise you will receive a 0 grade in the project).  The file
  Coach_interface presents the interface to be associated with the
  Coach class.  NOTICE THAT THIS FILE JUST ILLUSTRATES THE METHODS
  THAT MUST BE AVAILABLE VIA AN INSTANCE OF THE CLASS.  You must use
  the AMember class and inheritance/polymorphism in order to write a
  Coach class that implements the same functionality and interface
  specified by the Coach_interface file.

  You will be penalized for a Coach class implementation that does
  not make appropriate use of inheritance/polymorphism in order to
  implement the Coach class.  For example, implementing a string
  getName() const method in the Coach class is wrong; that is a
  method already available in the AMember abstract base class.

b. Methods
----------
   i. data members -

      In addition to the name, year, and email data members,
      which you are already familiar with, the Coach class has the
      following data members:

      medalists => a NameList object used to store the names of all
                   the athletes this coach has represented who have
                   won at least one olympic medal.

      yearsCoaching => integer representing the number of years
                       this individual has been coaching.

      formerAthlete => boolean indicating if the coach was a former
                       athlete - if so it is true; otherwise false.

  ii. methods -

      constructor - The constructor must take the parameters
      specified in the Coach_interface file.  The default values
      required for each parameter are as specified in that file.

      dtor - You must determine whether or not to write the dtor.

      copy constructor/assignment operators - You must determine
      whether copy constructor and assignment operators are required
      for this class.

      classType - this method must return the string "Coach".

      duplicate - You must add a public const method called
      duplicate() that returns a pointer to a dynamically-
      allocated copy of the current object.  The type of
      the pointer value returned should be AMember *.

      get methods - For each of the data members, there is a public
      method that allows us to retrieve the data member value.

c. Additional info
------------------
   i. IMPORTANT: In the Coach class you can NOT declare
      operator>> and operator<< as friend functions but you must be
      able to do input and output for objects of the class using
      operator>> and operator<< .   The expected inputs and outputs
      are defined by the BNFs <Coach_in> and <Coach_out>
      respectively.

  ii. It is your responsibility to determine which methods to
      declare in the class.  Remember that you will be penalized for
      unnecessary methods declared in the class and for methods you
      miss to declare.

 iii. You cannot add any public data members to the class.

  vi. The getMedalists() must return a copy of the NameList object by
      value.

d. BNFs
-------

        <coach_in> ::= <NEW_amember_in><years_coaching><former><medalists>
  <years_coaching> ::= <ws>(integer >= 0)
          <former> ::= <ws>"ATHLETE" | <ws>"NON-ATHLETE"
       <medalists> ::= <ws><namelist_in>

  <coach_out> ::=
        <NEW_amember_out><endl><years_c_out><former_out><endl><medal_out>

     <years_c_out> ::= "Years coaching: "<integer>
      <former_out> ::= " (former athlete)" | <empty>
       <medal_out> ::= "Medalists:"<endl><namelist_out> |
                       "Medalists:"<endl>"none"<endl>

a. Changes in the interface
---------------------------
  The interface for the DataManager class stays basically the same as
  in project #3.  The only exception is that printEventListForward,
  printEventListBackward, printAMemberListForward and
  printAMemberListBackward all now take a string parameter,
  representing what kind of objects to print.

  The options for functions printing events are:

  All => print all the objects in the collection.
  TimedEvent => print only TimedEvent objects.
  TeamEvent => print only TeamEvent objects.

  The options for functions printing association members are:

  All => print all the objects in the collection.
  Athlete => print only Athlete objects.
  Coach => print only Coach objects.

b. Changes in the implementation
--------------------------------
  You must modify the DataManager implementation so that it can now
  work with all the different kinds of objects available (more
  information about this matter in the Inputs/Outputs section)

a. Your project will read commands that will be processed by the
   main() function in the main.cpp file.

b. All the commands specified in Project #3 (ADDTOPART, FINEVENTSOF,
   etc.) will be available in this project.  Some of them have been
   modified so now they take a parameter.  Those commands that have
   not been modified in this project should behave as specified in
   Project #3 except that they must evaluate any possible kind of
   objects that could be associated with the data structure (event
   list or association member list) when required.  For example,
   FINEVENTSOF must now check for any kind of Event objects (i.e.,
   Event, TimedEvent, TeamEvent) when determining the events
   associated with a particular individual.

c. The following commands have been modified for this project.

   i. ADDEVENT - Now we will ALWAYS have an option specifying the
                 kind of Event being added.  The options are:

      Def => represents a default Event (an instance of the base class
             Event).  These are the kinds of Event we dealt with in
             Project #3.

      TimedEvent => represents a TimedEvent

      TeamEvent => represents a TeamEvent

  ii. PRIEVENTSFORW/PRIEVENTSBACK - Now we will ALWAYS have an option
      specifying the kind of Event objects to print for both of
      these commands.  The options are:

      All => print all the events.

      Event => Although all our objects are Event (they are derived
               from this base class) in this scenario we refer to
               Event objects that are neither TimedEvent nor
               TeamEvent objects.

      TimedEvent => print only objects that are TimedEvent objects.

      TeamEvent => print only objects that are TeamEvent objects.

 iii. PRIAMESFORW/PRIAMESBACK - Now we will ALWAYS have an option
      specifying the kind of AMember objects to print for both of
      these commands.  The options are:

      All => print all the association member objects.

      Athlete => print only objects that are Athlete objects.

      Coach => print only objects that are Coach objects.

      We don't have an AMember option in this case because the AMember
      class is an abstract class.

  iv. ADDAME - Now we will always have an option specifying what
      kind of association member we are adding.  The options are:

      Coach => adding a Coach.
      Athlete => adding an Athlete.

d. BNFs (These BNF entries are extensions/modifications to the ones
         provided in Projects #1, #2 and #3).


    <actual_command> ::= <new_add_com> | <new_print_com> |
                         <new_print_ame_com> | <new_add_ame_com>
       <new_add_com> ::=
             "ADDEVENT"<ws>"Def"<ws><event_in> |
             "ADDEVENT"<ws>"TimedEvent"<ws><TimedEvent_in><ws> |
             "ADDEVENT"<ws>"TeamEvent"<ws><TeamEvent_in>

     <new_print_com> ::= <print_choice><ws><print_option><ws>
      <print_choice> ::= "PRIEVENTSFORW" | "PRIEVENTSBACK"
      <print_option> ::= All | Event | TimedEvent | TeamEvent

 <new_print_ame_com> ::= <print_ame_choice><ws><print_ame_option><ws>
  <print_ame_choice> ::= "PRIAMESFORW" | "PRIAMESBACK"
  <print_ame_option> ::= All | Athlete | Coach

   <new_add_ame_com> ::= "ADDAME"<ws>"Athlete"<ws><athlete_in> |
                         "ADDAME"<ws>"Coach"<ws><coach_in>


e. The files primary_input and primary_output in the posting account
   show examples of some of the commands and the expected outputs.

a. We will use a main function (provided in a file called main.cpp
   available in the posting account) that will read commands from the
   user and then call the appropriate DataManager method in charge of
   handling the command.  YOU CANNOT MODIFY THIS main.cpp FILE IN ANY
   WAY.  It is considered the driver of the whole application and we
   will use it to compile your system during grading.

b. The main.cpp main() function has for each one of the possible
   operations in the DataManager class an entry that allows us to
   execute that operation with a set of values provided in the input.

1. Many requirements for the implementation of this project have been specified throughout the methods description provided above; double check those requirements are satisfied by your project.
2. JUST AS IN PROJECT #3 - You must use the BST<Event,string> eventlist data member in order to keep track of Events (keeping in mind the inheritance and other matters discussed above).
3. JUST AS IN PROJECT #3 - You must use the DLL<AMember,Name> amemberlist data member in order to keep track of association members (again keeping in mind the stuff above and below).
4. Any iterations required over the association list or the event list in the DataManager class should be done using the required template class iterators (when possible and if the extra credit is done).
5. There must be a file called BST.cpp that will contain the class template(s) corresponding to the binary search tree.
6. You must have an instantiation file named Instantiations.cpp   Every template class used by your program must be instantiated in this file. Your program must link in this instantiation file when compiling the executable.
7. The DLL class MUST IMPLEMENT A TEMPLATIZED DOUBLY-LINKED LIST OTHERWISE YOU WILL RECEIVE A GRADE OF 0 FOR THIS PROJECT EVEN IF YOUR PROJECT GENERATES THE PRIMARY OUTPUT.
8. The BST class MUST IMPLEMENT A TEMPLATIZED BINARY SEARCH TREE OTHERWISE YOU WILL RECEIVE A GRADE OF 0 FOR THIS PROJECT EVEN IF YOUR PROJECT GENERATES THE PRIMARY OUTPUT.
9. Primary Output Requirements - Your project must generate results that match the primary output when run with the primary input and the main.cpp file provided. The results generated by your program will be considered correct if and only if this command reports no differences. The expected primary input and output are available in the posting account. ANY PROJECT NOT GENERATING THE CORRECT PRIMARY OUTPUT WILL RECEIVE A GRADE OF 0.
10. YOU CANNOT ADD FRIEND CLASSES AND/OR FRIEND FUNCTIONS to any of the classes in this project. We have already specified in the .h files which functions and/or classes are friends.
11. YOU CANNOT MODIFY THE HEADER FILES IN ANY WAY except when explicitly stated otherwise (and only as explicitly stated). You may write "helping" code inside the source (.cpp) files as you see fit/necessary however you can NOT have any global variables (with the exception that global constants would be allowed).
12. YOU MUST USE THE main.cpp FILE WE HAVE PROVIDED.
13. YOU CANNOT USE THE STL (Standard Template Library) IN ORDER TO IMPLEMENT THIS PROJECT.
14. You can NOT use files or any type of fstreams in this project.
15. YOU MUST USE INHERITANCE/POLYMORPHISM IN ORDER TO IMPLEMENT THE TimedEvent, TeamEvent, Athlete and Coach classes. Students not using inheritance/polymorphism to implement ALL these classes will receive 0 credit in the project (EVEN IF THEIR PROJECT GENERATES THE EXPECTED PRIMARY OUTPUT).
16. During the grading of your project, we may test your code with a main.cpp that is different from the one we provided. That means that those functions not necessarily tested by the main.cpp posted may be tested. Make sure that copy constructors, destructor and assignment operators have been implemented in such a way they work correctly no matter what main.cpp we provide.
17. Your code must not produce memory leaks. As long as it does not have leaks nor does it "wastefully" use dynamic memory, you may assume that memory allocations will always be successful.

1. This project has a number of details in it and thus it is recommended taht you start working on it immediately. DO NOT WAIT UNTIL FEW DAYS BEFORE THE DEADLINE. Office hours are usually crowded the days before the deadline; if you wait until the last minute you might not be able to get the help you need and it will be very difficult to complete all the required tasks in time.
2. Start by fixing (if necessary) the "supporting" classes (Name, NameList, Event) before you move on to the harder parts.
3. For each class you implement, you should (must) have a test driver that verifies the methods have been implemented correctly. Save those test drivers for future reference.
4. Keep backups of your projects (in a special directory separate from the one you do your main working in).
5. Remove any unnecessary files from your account. The compilation process can be interrupted if not enough disk space is available (familiarize yourself with the UNIX quota command).
6. See the FAQ online throughout the project for other possible hints.

For this project (and the rest of them) you must make a UNIX Makefile to manage the compiling of your project. The makefile must be named makefile and should be written so that the first target is p4 and that typing make p4 or just make will result in the necessary files being compiled to create the executable p4 which can then be run as specified below in the Sample I/O section. Note that your makefile should create (and leave) the necessary .o (object) files and should not recompile unnecessarily (meaning it should not have redundant/incorrect dependency lists for the targets). Your makefile does not have to have any "extra" targets such as make clean or make tar however it is ok if it does.

The makefile must use the cxx compiler with the -w0 and the -std strict_ansi options when compiling.

NOTE THAT YOUR PROJECT WILL NOT SUBMIT UNLESS IT HAS A WORKING MAKEFILE and thus you are strongly encouraged to test this well in advance of the due date to make certain your makefile is working properly. If you have difficulty using the makefile reread the makefile tutorial in the posting account:

~fjm14001/Tutorials/Miscellaneous/makefile+tar.g++

When compiling your program should not generate any compiler warning messages.

For this project you will be provided with a primary.input and primary.output file. Both of these files can be found in the posting account in the appropriate directory. YOU SHOULD COPY THE primary.input FILE FROM THE POSTING ACCOUNT - DO NOT ATTEMPT TO TYPE THIS FILE IN OR CUT AND PASTE IT FROM THE WEBPAGE - INSTEAD, COPY IT (using the UNIX cp command) DIRECTLY FROM THE POSTING ACCOUNT.

In order to pass the MRC (minimum running criteria) for this project your program must generate the primary.output when tested with the primary.input as follows:

%  make  p4
%  p4  < primary.input  > my.output
%  diff  -bwi  primary.output  my.output
%

The first line (make p4) is the step to compile the project - note that you should strive to have NO COMPILER WARNINGS (points may be deducted for having compiler warnings). Note once again: you must use the cxx compiler in your makefile and that the -w0 and -std strict_ansi options must be used (points may be deducted for failing to use the compiler and options specified).

The second line (p4 < prima...) is a way to run the p4 program and redirect input (<) to come from the primary.input file (instead of the keyboard) and have the output redirected (>) to the file my.output (instead of the screen).

The third and final line (diff -bwi ...) is how we will test to make sure that your output (my.output) matches the expected output (primary.output). The diff command will print to the screen any lines in your file that do NOT match with the corresponding lines in the other file - if nothing gets displayed that is good news - it means that your output matches the expected output. The -bwi options tell the diff command to ignore case (be case-insensitive) and to ignore extra blank spaces. You should strive to have your output diff with the primary.output without the -bwi options, as that forces you to have a "more perfect" match - however when grading we will always use the -bwi option.

In the posting account, in the ~fjm14001/Projects/P4/ directory, there are the following files (and possibly others):

     main.cpp        AMember.h       Event.cpp       DataManager.h   

When we test your project we will compile it as follows:

%  make  p4

%  make

NOTE: SUBMIT TAKES TIME TO RUN - you should always attempt to submit BEFORE 11pm and should do so long before 11pm - in particular if you run the submit command at 10:59pm it will not finish testing your program in time and it will end up being late.

IT IS VERY STRONGLY RECOMMENDED THAT YOU ATTEMPT TO SUBMIT THIS (and every) PROJECT AT LEAST ONE FULL DAY (24-hours) IN ADVANCE. In particular no extensions will be granted for problems encountered in trying to get your program to submit unless there is an error that the majority of students encounter with the submit program we provide and/or the corresponding instructions. Additionally you should make a safe backup copy of all your work PRIOR to beginning the process to submit your project (as described below).

For this project you must "tar" and submit the following files (primarily consisting of the source (.cpp) and header (.h) files used by your implementation including your makefile):

     DataManager.h    DLL.h           NameList.h      Name.h
     DataManager.cpp  DLL.cpp         NameList.cpp    Name.cpp
     Event.h          AMember.h       Athlete.h       makefile
     Event.cpp        AMember.cpp     Athlete.cpp     Instantiations.cpp
     BST.h            TeamEvent.h     Coach.h         main.cpp
     BST.cpp          TeamEvent.cpp   Coach.cpp
     TimedEvent.h
     TimedEvent.cpp

You must do this using the tar command similar to how it was used in project #2 - double check your tar file to make sure it has all of the required files and no other extra files. Points may be deducted if your tar file contains extra files. IN PARTICULAR: your tarfile should NOT contain any extra files other than those needed to create the executable p4 and it must contain all those text files (.cpp, .h and makefile) necessary to create p4.

NOTE THAT YOUR source files (.cpp) must be named the same as the corresponding header files (.h) - so for example the source file corresponding to Event.h must be named Event.cpp (which is just Event.h with the .h replaced by the .cpp).

WARNING - BE VERY CAREFUL USING THE UNIX TAR COMMAND - if you use the command incorrectly it may automatically DELETE (permanently) one or more of your files. Make a backup copy of your files before running the tar command. In particular the filename IMMEDIATELY after the -cvf in the tar command, must be the name of the file that you want to CREATE and put the other files into. If that file already exists it (the tar command) will automatically DELETE it and create a new one and if the file doesn't exist tar will just create a new one. To find out more about the tar command there is a "tutorial" in the posting account in the ~fjm14001/Tutorials/ directory also you can type "man tar" at the UNIX prompt to read the man page.

DO NOT EDIT YOUR TARFILE - it turns out that a tar file is a plain text file that you can read, but it may look "weird" inside - that is the way the tar file works and if you modify the tar file IT WILL NOT WORK ANYMORE and we will not be able to test your program.

After you have created the tar file you must then turn in (or submit) that file to us. The way that you do this is that you can type:

%  submit  proj4.tar  4

The submit command will generally display information to the screen and you should read that information to make sure your project submits successfully - if you do not see a message stating that your project was submitted then you should assume that it did not get submitted.

We will not accept projects submitted in any other way.

You may submit a project more than once - note however that only the last file you submit will be used for grading purposes - meaning that if you submit twice ontime and then once two days late only the last submission will be graded (the two day late version in this case). See the course syllabus for other details regarding late submissions.

NOTE: you should make a backup copy of all of your work on a regular basis. We will not grant extensions due to mistakenly deleted files or individual computer troubles. It is also recommended that if you do work and store your files on a personal computer you regularly backup those files by copying them into your class account (at least once a day during any of the days you work on your files).

DOUBLE CHECK WHAT YOU SUBMITTED to make sure that it is correct - in particular create a subdirectory and copy the file you submitted into that subdirectory and then untar it (tar -xvf) and check the contents to make sure they are correct - in particular compile and test the files that were extracted from the tar file. If there is a problem with the tar file you should fix it and try again.