Overview

This lab continues from the in-class activity of the previous
lecture. It's all about Object Oriented Design. Last class you
started on a design for a program that solves the problem
described here. Today
your group will finish that deisgn, and implement it.
To facilitate working in a group, you will use git, as you did in
Lab 2.

Gifts and Rules and Advice

I have several gifts and rules and pieces of advice for you.

Gift: I have a class for representing and
dealing with dates
— MyDate. Check out the
documentation to learn how to use it, and download the
compiled classfile with:

MyDate has enough functionality to get the job done (it's what
I used) but it
may be that you want more. It's derived from the Java API
class Calendar (actually from a subclass called
GregorianCalendar) so you can look for extra methods there.

Rules: Basic operating rules are:

The driver program's source code file should be named Lab08.java

The input file will be given as the first command-line
argument.
Make sure to test with in0.txt.

The number of days to simulate will be given as the
second command-line argument.

The simulation will start on 1 January 2016.

If the program is run with fewer than two arguments, the
following usage message will be shown:

usage: java Lab08 <infilename> <numDays>

and the program will terminate.
If it is run with proper arguments, it will print its
output as shown in the following sample run:

in3.txt

sample run

every 2 days start 1/7/2016 expense Ta
every 1 days start 1/6/2016 income Dum

You will put proper Java-style comments in front of each
class definition and public method definition, and
generate nice javadoc documentation for your project
(how to do this is explained in the lab).

Advice: the "smarts" should be builtin to the classes
themselves, not the driver program. That principle should
guide your design. I suggest that your driver program
be designed roughly like this:

set today to 1/1/2016
for(i=0; i < numDaysToSimulate; i++)
{
ask each event whether they have something going on today and, if any do, report them
set today equal to the next day
}

That way the driver is simple, and the "smarts" will be in
each event class's code when it decides whether something's
going on.

Important: whoever's doing the driver is probably going
to have to read the input file. Reading dates (e.g. 2/5/2017)
is greatly aided by the split method in String.
Checkout
the documentation!

Part 0: Setting up a git repository for the group

There will be three of you working on this project. Once you get
to a certain point, all three should have separate tasks to
accomplish, so you should be able to work in parallel and
periodically merge your three chunks of the program together.
To make this kind of work possible without going crazy, you'll use git!
Choose one of the three members of your group to be the one who
will "host" the git repository and do the following under their account.x

In a terminal window give the following commands:

cd ~ ← cd to your home directory
mkdir share08 ← create new directory "share08"
cd share08 ← cd to the new directory
~wcbrown/bin/cher m18xxxx m18xxxx← use the alpha codes of the two other partners. This makes the directory "shared"

In the same directory as the previous step, give the command:

~wcbrown/bin/git-init

This will create a git repository that you both can share.
Note the output line that looks like

if you do an ls, you should see the
directory share08
has suddenly appeared. Cd into the share08 directory. In it, you should find a README file.
This is where you will be working from now on!

Part 1: Work together to agree on a design and get the base class written

Working all three of you together, finalize version 1.0 of your design
(remember the diagram from class?),
get "the base class" actually written, and check
in and push
the base class source file and MyDate.class into your git repository, like this:

Make sure that the base class source file actually compiles!
Also make sure all three of you have a checkout of the repository
with all this new stuff.

Part 2: Many hands make light work

You should be able to start working in parallel on implementing
different parts
of your design now. Decide who is going to do what, and go off
separately and write (and thoroughly test!) your parts. You can
talk to each other and ask for help and advice as you go. If you
decide some part of the design needs to change, that's OK, but
make sure you all agree on what's going to change, and make sure
only one of you actually alters the base class if it needs
changing. That one person should commit and push the new version,
then the other two should do a "pull" to get the new version.

To be clear on the "git" stuff: suppose you create or edit a
file named Foo.java. You would give the following
commands:

git add Foo.java &lt- this says the next commit will include the new Foo.java
git commit -m "Added my wonderful new Foo.java class" &lt- commits changes to your personal version of the repo
git push &lt- pushes these changes to the master copy of the repo

Then everyone else would give the command

git pull

to pull these changes from the master copy of the repo and
incorporate them into their personal copies.

Part 3: Bring it all together

When you've all completed your separate parts and commited and
pushed them to the repository, have all three group members come
together at one computer and finish the task.

You should have all included nice Java-style comments with your
code. To generate documentation from these automatically do
the following:

javadoc -d doc -link https://docs.oracle.com/javase/8/docs/api *.java

... which will create a directory "doc" in the current directory
and put all the documentation in it.
To view the documentation you've created, press ctrl-o in your
browser, and navigate to the file doc/index.html in your share08
directory.
It's worth doing this and looking at the documentation as you try
to put together your pieces into the complete working program.
Don't add the documentation to the repo, just as you won't add any
of the .class files that come from compiling your .java files. We
only bother to add those things that we can't just generate
automatically.
Note: be sure to test your program carefully and thoroughly!

Submitting the lab

You need to submit this properly. We won't track down your
missing pieces or your otherwise properly submitted labs.
Here's all you need to do.

Make sure the README file has the names and alphas of all
three team-members in it!

Cd to the directory in which your lab
files lie, and give this command: