Overall problem: determine if any interesting anniversaries will occur during this Autumn quarter
Specifically, this time: Given a file of historical events and their dates, determine whether any of them have interesting anniversaries during this quarter.
|
Project 2 Part a (not a draft!) Part a solution version of TextFileDumper.java (all added code is in main) |
Project 1 sample solution | Info on submitting a file of real history information |
| updated IDateInvestigator.java (no changes over the description on this page). Don't change this file -- you won't be able to hand it in. | HistoryFactsFile.java including comments pointing out changes compared to the description on this page. Don't change this file -- you won't be able to hand it in. | Test files directory Find all
test files here.
|
Deadlines:
Part a -- you know about!
Part b -- the remaining analytical parts: Due at beginning of quiz section, Tuesday, October 29.
Part c -- the complete code: Due electronically Wednesday evening, October 30, 9:00.
Part x, the optional pPoint opportunity: Due electronically Sunday evening, October 27, 9:00.
Electronic deadline: First Part will be due Wednesday, October 23, 2002, 9:00 p.m. However, the exact contents of that first part is still a bit fuzzy. It will certainly involved reading and processing a date file, and creating such a file yourself. Sample file: the vision science dates file.
Once again, our focus is almost entirely on programming. We also begin using files and streams. Analysis focuses on class relationships and on style.
Functional summary description of the finished program: A user starts the program, and has an opportunity to specify a file of historical facts. Assuming the file is in the proper format, the program then shows a report of the interesting anniversaries.
Dates
Dates are assumed to be C.E. (AD) in the usual (Gregorian) calendar. Dates are to be accepted from the use in either of the following formats; only the third one is new:
String which don't conform to these models can be considered errors, and should be handled appropriately (read the code for more ideas about this). Your program is free to accept other common date formats, too.
Note that a date consisting only of a year must be handled a bit differently. 1776 is not the same as January 1, 1776. For year-only dates, compute only year-interestingness, not day-interestingness.
"Interestingness"
A date is "interesting" (some changes from previous project)...
Report Record all the interesting facts that your investigation discovers.
For each date, report the full original date (in decimal); the number base
used for this fact; whether the fact is about years or days; and the number
of years or days (both in decimal and in the other number base, if not decimal).
Note that the exact format and wording of this report is not specified. (More
about this can be deduced from the code. Basically, a "report" will
be a single string containing all the needed information). The information
coming from the file will contain a date and a historical fact about that date.
Record the date (in the same format as it comes in) and the fact. Then determine
whether the date is "interesting". Record all of the "interesting"
information about the date (for example, in one long string). If the date is
uninteresting, record that, too.
"Record" simply means that the information is kept in the object in some fashion, so that it can be given to a client who requests it via the interface.
Internal Requirements
There are some requirements that your programming must meet, or the program may not even be gradable.
An interface called IDateInvestigator
is supplied. You must create a class which implements that interface. Comments
in the code will help clarify what the required behavior is. You may not modify
IDateInvestigator (you won't be able to turn in a modified version). This
interface is the same as the old IDateInvestigator, with some changes. Make
a class which implements this interface. A client (or another part of your program)
can set the date, set some historical fact in it, and then get information back
out via the interface. Turn in your IDateInvestigator. It must be implemented
according to the specifications, or it won't compile with our test programs
(even if it works perfectly with yours!).
Add the following methods to the original interface (still a draft. A .java file with the final interface specification will be provided).
public String getDate( ); //return the date in its original format as supplied to the object (any padding can be removed, and any linefeeds should be removed). It is an error for this method to be called if no date has been stored.
public void setHistoricalFact(String hFact); //record a historical fact about the date. Any old facts are not lost.
public String getHistoricalFacts( ); //return all known historical facts about the date, as a single string. Individual facts should be separated with a '\n' character (there could be additional \n characters within the string). If there are no known facts, return a string stating so.
public void setInterestingnessFact(String iFact); //record an "interesting" fact about the date. Any old facts are not lost.
public String getInterestingnessFacts( ); //return all known interestingness facts about the date, as a single string. Individual facts should be separated with a '\n' character (there could be additional \n characters within the string). If there are no known facts, return a string stating so.
Note: as before, a DateInvestigator holds information only about a single date. There is no requirement to remember information about more than one date at a time. If the same date occurs more than once in a file (presumably each occurrence with its own historical facts), you can treat them as unrelated items.
In addition, modify the IDateInvestigator interface definition so that is implements the Comparable interface. The intention is to be able to compare one date/fact set against another, based on interestingness. More details to come.
File Input and File Format
Take the data from a text file (format described below). You should use the java.io library to do this. You can use the uwcse Input class, but won't get full credit if you do (plus you lose the opportunity to practice material needed for the midterm!). Appendix A.2 shows some examples of creating a text input stream object. It's fine to copy this code, or similar code from another source, if you understand fully how the code works, and you acknowledge the source in a comment. Please don't use any Java.io facts beyond what is covered in class and in the book, unless you really understand them (otherwise, you won't be learning the basics you need to know).
File Format
The file has lines of three types:
In a valid file, the data and fact lines alternate strictly: date-fact, date-fact, etc. All comment lines must come at the beginning of the file.
If an invalid file is detected, that should be communicated somehow (so that the file owner or programmer at least knows of the problem); the program is not obligated to continue any processing after that.
HistoryFile Interface Please see updated version (link at top of page) and ignore the rest of this section.
Object of type HistoryFile are meant to encapsulate the actual file and stream from which the data comes. Methods are provided for clients to change or select a file, and to get information from it.
/** This spec should be considered provisional; a .java will be provided.
Concrete implementations should provide a constructor which opens a file containing history information. Since such a constructor is likely to be similar in many possible subclasses, a concrete implementation is supplied of a partial such constructor. */
public abstract class HistoryFactsFile {
private String fileName = "no file yet";
private FileInputStream fileStream = null;
public boolean hasNext( ); //returns false if at end of file; true otherwise
public String nextDate( ); //returns the next date on the file
public String nextFact( ); //returns the next fact on the file
}
Test Files Requirements (and Opportunities!)
Prepare a short test file that includes comments (including your name, date, and section), and at least four facts. Here's an example file; the comments will tell you where it came from. Your test file doesn't need to be this long or have genuine information. However, see the "Service Opportunity" below.
Service Opportunity
Prepare a sizable test file of real historical information and share it with the class. More information.
Analytical Exercise 1
Interfaces and Inheritance implement "is-a" relationships, and a hierarchy chart shows the relationships graphically. There are often "has-a" relationships in a class design.
Start with a concrete class of yours that extends HistoryFactsFile. Draw its interface and inheritance family tree (as we did last time). Also include classes used by HistoryFactsFile in your implementation. Show the relationship with the diamond symbol (used in the textbook). For classes used by HistoryFactsFile, also place their family tree in the diagram. "Has-a" relationships do not have to be drawn for any class other than your HistoryFactsFile implementation.
You can make these pictures freehand. It is not necessary to use a drawing program or even to worry too much about exact rectangles -- as long as the picture communicates the structure clearly.
Put your name and section on each piece of paper, and staple them together.
Hand them in at the beginning of lecture, Friday, October 18. with
Part b (see the deadlines at the top of the page).
Analytical Exercise 2
What constitutes "good" style and programming practice is sometimes hard to define, or varies from place to place. A more objective approach to judging style is to compare it against a specific style guide. Sun's Code Conventions for Java Programmers is one such guide. Many programming organizations have their own guidelines which are often even more detailed and specific.
A sample solution for Project 1 is (or will be) posted. Review the solution; read through Sun's Code Conventions. Then write a critique of the solution, based on that standard. You may have your own opinions on style, but this exercise is about applying an external standard. If you wish to include comments based on your own opinions, be sure to keep them separate and make it clear to the reader they are not part of the Sun-based critique. Hand this in with Part b.
A Few More Notes
Partner policies to be announced later. It is probably best to assume
that the first part of the project, at least, should be done by individuals
rather than team. Detailed instructions for how
to turn in your work will be available eventually.
You may work with a partner on Parts b and c. Part x
must be done individually (as Part a was).
You are free to use any standard Java library class or method. You shouldn't use code from outside the course, but if you do, recognize that with a comment in the code.
Click here to submit electronically (when the form is available. Do NOT use the Project 0 or 1 form!)