CISC 181 Introduction to Computer Science, Fall, 1998

Nov 23 Lab project -- Final programming projects

This will be the final lab assignment and will be done in teams of two people. There are three remaining lab sessions counting today, and they will be devoted to teamwork on these projects. There are a number of projects to choose from and a number of required elements to be worked into your designs. Due at the end of the lab next Monday is a written proposal stating which projects your team will complete and which of them will contain which of the specified elements and which team members will be responsible for which part, and finally it will include at least one class declaration.

The collection of problems from which you may choose is the problem set from the recently completed ACM programming contest, The assignment is to solve three of the problems. You choose which three.

Each team is encouraged to solve more than three problems. Extra credit points may be gained for doing so and these extra credit points will be applied to your homework total. There are two catches to this extra credit scheme (to be fair and to make it truly "extra" credit). First, the extra credit counts on a 2 for 1 basis. Thus it takes 2 extra credit points to make up for 1 previously docked point. Second, extra credit points cannot bring your homework total above the total points for non-extra credit homework. Thus someone who has done all previous homework perfectly (including the three problems assigned here) has nothing to gain from extra credit except extra satisfaction.

The required elements

  1. Classiness element: Each solution must include at least one class. The class may be very simple, but it must be there. Two of the contest problems involve searches somewhat similar to your 8 queens problem. For these problems the board class or one derived from it is acceptable to meet this classiness rquirement.
  2. Friendliness element: At least one solution must be a design that involves defining and using at least one friend function to a class,
  3. Overwhelming element: At least one solution must be a design that involves defining and using at least one overloaded operator.
  4. Sharing element: At least one solution must be a design that determines well defined separate parts that can be separately debugged, and that in fact are separately coded and debugged by different team members. The common interface for the parts must be put in a header file. Almost surely the structure will be an interface which is a class declaration, with separate parts being a file implementing the member functions and a file containing main and using the class to solve the problem.

    Teams may work collaboratively on all aspects of other problems or may even assign separate problems to separate individuals other than the one meeting this sharing element. However we prefer to see problems done collaboratively or in this mode that involves this use of a class header as interface.

Comments on the 8 contest problems

  1. Golf score. Possible class: score4tuple, possible friend function returns rank of a score within a score4tuple (also needs score4tuple of previous hole). Possible overloaded operator: + to add up total scores from score4tuples.
  2. Titanic. Possible class: something like the board class for 8 queens. PS: I find the moral position "save yourself before others" of the problem statement offensive.
  3. Joe-Ball. This is like the problem of how many ways there are to make change for a given amount with given coin denominations. Possible classes list of the score denominations, list of numbers of scores of each kind for a given way a game score could happen.
  4. Car Insurance. Possible class: car/driver data record. PS. I object to the ethical position we are asked to take on, "write this program so people can be fired." As a programmer consultant, I'd refuse this commission. I'd do it if CEO had the goal to free up the agents to be more productive for the company.
  5. Oldies. Possible class: stack of records, with member function to do the "playing" of a record. The records themselves could be a simple class with name and number-of-times-played fields.
  6. Greed. Some people say the lottery is a tax on the poor. Some say it is a tax on stupidity, since the expected value of a lottery ticket is usually about half it's cost. Anyway, the problem has nothing to do with gambling, really.
  7. Fire! Another search problem, probably calling for a board type class.
  8. VCR. Probable classes: one class for data about a show to be recorded and one class for the state of the VCR with fields for on/off, channel, recording/not=recording, and appropriate member functions for changing state.

The labs and submissions

  1. Lab Nov 23: Team assignments, get organized, examine and discuss problems. Tentative problem picks.
  2. Lab Nov 30: Choose problems, overall design, assignment of tasks within team.
  3. Nov 30 - end of lab - Proposal due: Hand in proposal including problems chosen, task assignment. For at least one problem, include a header file for a class, to be used as mentioned above for the sharing element. The proposal may be handwritten, and you won't be held to it exactly for the final submission (you can switch problems or strategy within a problem). However, the header file should be online at this point (and thus please print it as part of the proposal. Since team members should be able to go work from it on their respective parts, it is important that it be well thought out already.
  4. Lab Dec 7: Final team meeting. merging, debugging, tuning the code.
  5. Dec 9: Final due date. Submit each problem solution as a separate unit (fastened together within itself, but not fastened to any other solution). Each solution includes (1) the code, (2) output demonstrating correctness and/or incorrectness, and (3)a paragraph discussing how the solution went. Was this one of the harder or easier ones? How much work was it? Anything expecially good or bad about working as a team on this one? Note: If a solution does not work perfectly, it is important that the outputs submitted show both what it can do correctly and what it can't. It is also important that you write comments on imperfect output showing us that you've noticed the problem. Seeming to say, "this is the solution" when it isn't the solution is much worse than saying "this is a partial solution and here are the issues needing further attention - we just ran out of time."