CPS 108 Fall 1996: toonces

The Object-Oriented Networked Calendar Extraction System

Update

Goal

Your goal is to write toonces, " The Object-Oriented Networked(eventually) Calendar Extraction System". toonces will print calendars in a variety of formats; keep track of appointments and other calendrical events; and print weekly, monthly, daily reminders of these events. Calendars will be viewed in several ways and in several output formats.

(toonces is the name of a cat that drives a car. toonces was featured for many years on Saturday Night Live)

High-level specification

Programs

You will write both C++ and Java versions of toonces. A well-planned, object-oriented design should help facilitate development in both languages. One key is to design an integrated set of classes that can then be implemented in both languages.

Calendars

To help develop calendars you'll probably want to use classes that represent dates.

In C++ you have access to a class Date for representing and manipulating month/day/year dates.

• date.h
• date.cc

In Java you have access to the class java.util.Date that supports many of the C++ Date class functions and that also represents hours/minutes/seconds (the Java class has more functionality than the C++ class, but you probably won't use all of this functionality in implementing toonces.)

toonces will support simple calendars of the kind supported by the Unix cal command. The output of cal 10 1996 follows.

   October 1996
   S  M Tu  W Th  F  S
         1  2  3  4  5
   6  7  8  9 10 11 12
  13 14 15 16 17 18 19
  20 21 22 23 24 25 26
  27 28 29 30 31

Different views (other than the simple month view above) will also be supported (more on views below). For example, a simple continuous semester calendar produced by toonces might look like:

            September - December 1996

     Su     Mo     Tu     We     Th     Fr     Sa
+------+------+------+------+------+------+------+
|     1|     2|     3|     4|     5|     6|     7|
|  September  |      |      |      |      |      |
+------+------+------+------+------+------+------+
|     8|     9|    10|    11|    12|    13|    14|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    15|    16|    17|    18|    19|    20|    21|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    22|    23|    24|    25|    26|    27|    28|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    29|    30|     1|     2|     3|     4|     5|
|      |      |  October    |      |      |      |
+------+------+------+------+------+------+------+
|     6|     7|     8|     9|    10|    11|    12|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    13|    14|    15|    16|    17|    18|    19|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    20|    21|    22|    23|    24|    25|    26|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    27|    28|    29|    30|    31|     1|     2|
|      |      |      |      |      |  November   |
+------+------+------+------+------+------+------+
|     3|     4|     5|     6|     7|     8|     9|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    10|    11|    12|    13|    14|    15|    16|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    17|    18|    19|    20|    21|    22|    23|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    24|    25|    26|    27|    28|    29|    30|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|     1|     2|     3|     4|     5|     6|     7|
| December    |      |      |      |      |      |
+------+------+------+------+------+------+------+
|     8|     9|    10|    11|    12|    13|    14|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    15|    16|    17|    18|    19|    20|    21|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    22|    23|    24|    25|    26|    27|    28|
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+
|    29|    30|    31|      |      |      |      |
|      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+

The Calendar Language

Since toonces must keep track of events and appointments (e.g., the vernal equinox, doctor appointments, and CPS 108 meetings) it will need to read and write calendrical events using some language. The language will be developed by CLANG, the Calendar LANguage Group (described in more detail below). toonces will have the ability to read a file in the format determined by CLANG and and output calendars based on events listed in the file. In addition, toonces will be able to support other calendar languages by being able to translate from them into the language used by toonces.

For example, see man pages for the programs calendar, calentool, cm (the latter is a sun specific program) for some details on other languages.

Views

toonces should provide a number of views of a calendar. There are two factors affecting the view: scope and format.

• Scope determines what time frame the outputted calendar will cover. This can range from one day to many years.
• Format determines what the calendar looks like. toonces chooses an appropriate default format for the given scope; the user can override that default. For example, if the scope is one day, then the appropriate default would be the "Day" format; a scope of 9 months would probably be best displayed in the "Month" format.
  In any of the "graphical" formats, events are listed inside the corresponding day's cell, if there is room; if there is no room, some indication should be given that there are events on that day (perhaps a colored-in square, or a thicker border, etc.).
  In any of the following formats, the name of the format indicates the basic unit of display. For example, Day requires the output to have each day displayed separately; in the Week format, the basic unit is the week, and so each week should be displayed in its entirety, each on a separate row. The Month format, for example, does not restrict you to print only one month, only that multiple months will be displayed as separate entities.
1. Day: a "textual" calendar format where events are merely listed in some appropriate fashion. Multiple days are printed one after each other.
2. Week: a "graphical" calendar format which shows a Sunday to Saturday week (seven cells). Multiple weeks are displayed in consecutive rows, with no separation between months (however, months are labeled somewhere appropriate).
3. Month: a "graphical" calendar format where, if multiple months are shown, they are separated (just like a wall calendar).
4. more to be determined later (see, for example, the semester calendar above.)

toonces should allow more than one view at a time if displaying on a screen. For example, you could have three windows, one "Day", one "Month", and one "Week" view, all being updated when the user enters a new event into the system. The Observer design pattern (see Design Patterns) will be very useful for this.

Note that you do NOT need to support windows and different graphical views on screen with the C++ version of toonces.

Output

Your program will support several forms of output, four of which will be plain text, HTML, Postscript, and a graphical Java interface (in the Java version). Documentation on these will be given out in class and placed on the web. You have great flexibility in the "look" of the outputted calendar. Be creative yet functional.

Usage

toonces will have both an interactive interface and a command line interface. The command line interface will look something like this:

toonces [ -f format ] datestart dateend

format
One of d (day), w (week), or m (month).
datestart, dateend
A date has one of the following numeric forms:

month/year

day/month/year

All years are assumed to be AFTER 1800. A year specified by 2 digits is assumed to be between 1960 and 2059, otherwise years should be specified by four digits.

The output of the command-line version should go to standard output.

The interactive version will allow the user to specify new events, delete or modify existing events, etc., through an intuitive interface. Clicking on a day of the month may bring up an edit window, for example.

The C++ program might have a text-menu driven interface.

Design

Good design is crucial in large projects such as these. One thing already mentioned is the design of the view system; the Observer design pattern was designed specifically for this.

Java has two interfaces: observer/observable to support different views. You should read about these and others in the Design Patterns book.

CLANG, the Calendar Language Group (composed of one representative from each group) will provide a definition for the calendar language that toonces should understand. This language should be as robust and flexible as possible (at a minimum, one of the complex event types could be able to specify an event that happens daily, weekly, or monthly).

What is the internal representation of events? The design of the calendar language may tie in closely with the internal event representation. There should also be an inuitive interface for accessing this data. All the view classes and output generators should be "querying" this data structure through an interface general enough to support these different clients, but powerful enough for all of them to get what they need efficiently must be developed.

The several output formats that you should be able to provide are another point of design. All the output generators have to be able to create "Day", "Week", and "Month" versions of their output. Again, good design is critical to support the different formats easily.

Groups

This project offers great possibilities for distribution of work. The design should be modular enough to facilitate dividing tasks among the members of the group. That should not be difficult to do.

Each member of the group should be delegated for one or more group roles. Some roles that must be filled:

• leader(s) - one, preferably two, people designated to coordinate group meetings, ensure that load is properly balanced, and have a vision of where the project is going.
• CLANG representative (inter-group liaison) - one person who acts as this group's representative on the working group to design a common calendar language. This working group must agree on a clear definition of the calendar language used by all groups. (First and foremost, CLANG must decide on an appropriate name for the calendar language.) The scope of this working group may expand in the future to include other inter-group projects, such as working on designing, finding, and installing software that all groups will use; developing standards for user-interfaces that all groups might want to follow; etc.
• librarian - responsible for managing all documents, including source code,web documents, revision control expert, test plan, design doument, final documentation, coding standards
• experts - responsible for being familiar with an aspect of the project which every member does not need to know intimately. Examples: HTML expert, PostScript expert, AWT expert.
• programmer - everyone in the group is a programmer

Prototype

The prototype due on October 14 should at the least read a file (in some format, not necessarily the final calendar language) and produce either HTML output or a window with a graphical representation of a month.

Schedule

• October 11 (Friday): Design document due
• October 14 (Monday): Prototype due (either C++ or Java)

Project requirements, design, and writeup by

and