Bug Fix - Programming with Data Structures - Lab | CS 220, Lab Reports of Computer Science

Material Type: Lab; Professor: Carver; Class: Programming w/Data Structures; Subject: Computer Science; University: Southern Illinois University Carbondale; Term: Fall 2009;

Typology: Lab Reports

Pre 2010

Uploaded on 02/24/2010

koofers-user-wn6
koofers-user-wn6 🇺🇸

5

(1)

10 documents

1 / 2

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CS 220 Programming with Data Structures Fall 2009
Lab #1 (bug fix)
(Due: 9/14/09 by 1:00pm)
Your first lab will be a straightforward lab focusing on reviewing Java. You will write classes
for a (very) simplistic calendar application, along with a method for testing your classes.
The calendar application will involve three classes: Date,Event, and Calendar. You will also
write a class TestCalendar that contains a (main) test method.
Specification for the Date class:
Fields/Members:
int year The year, 2000 to 2100.
int month The month, 1 to 12.
int day The day, 1 to 31.
Constructors:
Date(int year, int month, int day) Make certain that each field value is within
the specified range, else this is an error.
Methods:
Accessors for all three fields: getYear,getMonth,getDay.
String toString() Default method for producing string version of a date, which
should be of the form: "month/day/year".
Specification for the Event class:
Fields/Members:
Date date The date of the event.
int hour The time/hour of the event, 0 to 23.
String activity A description of the event.
Constructors:
Event(int year, int month, int day, int hour) Make certain that each field
value is valid, else this is an error.
Event(int year, int month, int day, int hour, String activity) Same as above.
Methods:
Accessors for all three fields: getDate,getHour,getActivity.
void setActivity(String newActivity) Mutator for activity field.
String toString() Default method for producing string version of an Event, which
should be of the form: "month/day/year @hour: activity".
Specification for the Calendar class:
Fields/Members:
Event[] events An array holding the scheduled events. Make it size 100.
int numEvents The number of events currently scheduled.
Constructors:
Calendar() This constructor must initialize the fields of the Calendar object: creating
a 100-element Event[] and setting numEvents to 0 (zero).
pf2

Partial preview of the text

Download Bug Fix - Programming with Data Structures - Lab | CS 220 and more Lab Reports Computer Science in PDF only on Docsity!

CS 220 – Programming with Data Structures – Fall 2009

Lab #1 (bug fix)

(Due: 9/14/09 by 1:00pm)

Your first lab will be a straightforward lab focusing on reviewing Java. You will write classes for a (very) simplistic calendar application, along with a method for testing your classes. The calendar application will involve three classes: Date, Event, and Calendar. You will also write a class TestCalendar that contains a (main) test method.

Specification for the Date class:

  • Fields/Members:
    • int year – The year, 2000 to 2100.
    • int month – The month, 1 to 12.
    • int day – The day, 1 to 31.
  • Constructors:
    • Date(int year, int month, int day) – Make certain that each field value is within the specified range, else this is an error.
  • Methods:
    • Accessors for all three fields: getYear, getMonth, getDay.
    • String toString() – Default method for producing string version of a date, which should be of the form: "month/day/year".

Specification for the Event class:

  • Fields/Members:
    • Date date – The date of the event.
    • int hour – The time/hour of the event, 0 to 23.
    • String activity – A description of the event.
  • Constructors:
    • Event(int year, int month, int day, int hour) – Make certain that each field value is valid, else this is an error.
    • Event(int year, int month, int day, int hour, String activity) – Same as above.
  • Methods:
    • Accessors for all three fields: getDate, getHour, getActivity.
    • void setActivity(String newActivity) – Mutator for activity field.
    • String toString() – Default method for producing string version of an Event, which should be of the form: "month/day/year @hour: activity".

Specification for the Calendar class:

  • Fields/Members:
    • Event[] events – An array holding the scheduled events. Make it size 100.
    • int numEvents – The number of events currently scheduled.
  • Constructors:
    • Calendar() – This constructor must initialize the fields of the Calendar object: creating a 100-element Event[] and setting numEvents to 0 (zero).
  • Methods:
    • void addEvent(int year, int month, int day, int hour, String activity) – Cre- ate and add an Event instance to the Calendar.
    • void addEvent(Date date, int hour, String activity) – Same as above.
    • void addEvent(Event event) – Just add the Event to the Calendar.
    • void printEvents(int year, int month, int day) – Print each Event in the Calendar that matches the date info. Print each on a separate line, using the toString method for an Event.
    • void printEvents(Date date) – Same as above.
    • Event findEvent(String activity) – Return the first Event in the Calendar that has a matching (identical) activity string. If no match is found, return null.
    • void dump() – Print every Event in the Calendar, as with printEvents.

The TestCalendar class must have a main method that performs reasonable testing of your other three classes. You are free to add additional helper methods if you want.

You must define each class in a separate Java source file (.java file), with the name of the class (e.g., Date.java, etc.). You are free to use any development platform that you wish, but if you use an IDE, you must be able to locate the .java sources files. We will do code submissions via email (unfortunately). You should email just your Java source files (.java files) to [email protected], using the subject “CS220 lab1 submission.” Files should be sent as attachments only, so their formatting is not destroyed. It is also allowed for you to send a .zip (or .tar) file archive containing all of the needed files (not .rar files!). You will receive an email acknowledgement that the files were received and readable. Improperly submitted files will be rejected. While late submissions will generally not be accepted, some allowance for email will be made. However, if you want to claim that your email submission failed, be prepared to display the returned email message or similar. Do not leave extra/unwanted code in your submissions. This particularly means main (testing) methods, as well as printing statements for debugging. You should provide reasonable documenta- tion for each method, but we will not be requiring javaDoc style documentation with this lab. Some aspects of the implementation are not fully specified above. One is access control. The basic rule you should follow is to limit access to fields and methods as much as is possible—i.e., only those classes that definitely need field/method access should be able to get it. This is the basic idea behind encapsulation in OOP. However, since we have not yet looked at packages, I do not want you using them to control access. This effectively leaves you with either public or private access options. Use what is most appropriate. The other major element that is unspecified, is what to do in case of errors. Since we have not yet covered Java’s exception mechanism, you are to use a standard type of approach that is used in languages like C that do not have an exception mechanism. The approach is to: (1) print an informative error message; and (2) then terminate the program with an error return. Error messages should be printed with the println method of the java.io.PrintStream class. The standard stream for printing error messages is known as standard error. To print to this stream, you would use a call like: System.err.println(). You can terminate a running program by calling the exit method in the java.lang.System class. The syntax is: public static void exit(int status). By convention, a status of 0 (zero) means success, while a non-zero status such as 1 (one) means failure. Obviously, if you are exiting due to an error, you want to return a failure exit code such as 1 (one). So such a call would look like: System.exit(1).