Results of Tuesday Project 5 review session: Overview: You can think of the project as conducting a discrete event simulation - in other words, there is a "clock", and as with all clocks, this one runs in only 1 direction. You can't (well, you shouldn't) peek ahead in the input stream. When you process an input line, it sets the simulation clock to the indicated time on the line. Your simulation deals completely with a line before it moves on to process the next input. We will discuss what your simulation might do (as a reasonable way of dealing with all of the different kinds of input) General: 1) Points in time on events is reported using a 24-hour format. (Howver, in this writeup, I will use 12 hour time for descriptive purposes) 2) I do not know when the executable will arrive. Events: 1: The "invite" event: An invite event occurs at some POINT IN TIME - e.g. today at 4:00 PM, your friend invites you to attend a 341 cram session. The cram session is scheduled for the time INTERVAL next Monday, between 6:00 and 8:00 PM. You think this event is pretty important (because you are committed to going to grad school, and you want to get an A on the final). You need to distinguish between when (point in time) the event gets put on the schedule (today at 4) and the interval of time on the calendar the event occupies (next Monday). There are no particular problems associated with events UNLESS the intervals of time they represent happen to overlap with other events. For example, you might get a call inviting you to a basketball game that starts at 7:30 PM next Monday and lasts for 2 1/2 hours, to 10:00 PM. When an event overlaps with another event, then the calendar should a) contain ALL of the more important event b) Schedule the non-overlapped portion of the less important event. If a cancel event or an adjust event arrives, then entries on the calendar are subject to revision. Cancel means the affected event is purged - the event is no longer in the system. You just produce a message announcing that the referenced event has been dropped. EXAMPLE: you have a todo item named "GET_PLAYOFF_TICKET_FOR_REDSKINS" to be completed by next Sunday. on Monday, a cancel event would remove this from the todo list and also from any schedules past the point in time when the cancel arrived in the system. Clearly, you would not remove time "already spent" i.e. that appeared on calendars before the cancellation time. c) invite events may span calendar dates: e.g. an event called "BUSINESS_TRIP_TO_OSHKOSH" might start at 6:00 PM Wednesday, and last for 36 hours. 2: Clarifications regarding the "time" event. when a time event occurs, it a) sets the simulator's time clock to that time b) causes you to print the calendar for that day (and as suggested in the project session, it might be a good idea for debugging purposes to print all days subsequent to the one on the time event). EXAMPLE: the simulator gets a time event for Tuesday; print Tuesday's calendar, and Wednesday - ending date - Yes, those days might get changed by other events, but that is not our problem yet. c) Those ToDO events (which we haven't yet discussed) need to wind up on the calendar, too. When your program see a time event as input, it should do something with the todo list. When time event occurs, it closes out that day's invites. You should not expect to see any more invites for the day. 3: Clarifications regarding TODO events. a) Todo's have importance, and they represent activities that you have some flexibility to schedule. For instance, if you had a todo called "Study_for_CS341_Final", you might allot 12 hours, to be completed 1 minute before the start of the (invited) event "Take_CS341_FINAL". You have some flexibility about when you study. What your program needs to do with a todo event is to find time around those immobile invites. Unlike invites, todo's don't overlap invited events (or other todo's) b) Your program has to find some method for dealing with todo's. It may schedule up to 8 hours of todo each day, that time to be between 9:00 AM and 9:00 PM (NOTE: Events are not constrained by this rule; the calendar doesn't care if an event occurs between 4:00 and 4:20 in the morning. Calendars (like MacBeth) have slain sleep). c) That method for dealing w/ todo's should not cause the removal of an invited event - unless the invited event is of lower importance than the todo AND scheduling the invited event will make it impossible to complete the todo. One method for daling with the todo is that when a time event occurs, add todo activities to the calendar (and make sure to keep track of remaining time on the todo!!), then display it. NOTE: If you schedule todo's more than 1 day in advance, you may find it more complex to deal with invited events that might enter the system for those days. EXAMPLE: on Tuesday, you book 6 hours of "STUDY" for Friday, between noon and 6:00 PM. Then, on Wednesday, your simulation sees an invited event for Friday 3:00 - 4:00 PM. Processing: a) Time events occur each day - you can assume that only 1 time event will occur for each date, and if the simulator advances more than 1 day (e.g. an event occurs at a point in time Wednesday, and the next event occurs at a point in time for Friday), then your simulator should generate a time event for Thursday. If there are events on the calendar after all input is read, you should produce calendar output for them - and indicate that they were not completed - see below. b) You should produce messages (on cout) to indicate what is occurring on your calendar - these will assist in debugging (and you will not lose points for these messages, as long as the messages are reasonably user-friendly). These messages should include reporting event cancellations, changes in importance, truncations, incomplete events (todo's that never got completed, invited events that were unscheduled or partially scheduled because of preemption by more important events, events that were scheduled for times after the end of the simulation, and anything else I may have forgotten to include on this list). Error messages for ill-formed events should produce error messages - on cerr, of course. c) the quit event essentially acts as an end of input sentinel, and it may be omitted from input. You might wish to generate a quit event to occur after the last input event, should there not be one. Any other questions - email one of the faculty!