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.
  1. 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:
    curl -O http://www.usna.edu/Users/cs/wcbrown/courses/S16IC211/lab/l08/MyDate.class
    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.
  2. 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.txtsample run
      every 2 days start 1/7/2016 expense Ta
      every 1 days start 1/6/2016 income Dum
      ~/$ java Lab08 in3.txt 10
      1/6/2016: Dum
      1/7/2016: Ta, Dum
      1/8/2016: Dum
      1/9/2016: Ta, Dum
      1/10/2016: 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).
  3. 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
  1. 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"
  2. 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
    checkout the repo with: git clone ssh://mich302csd17u.academy.usna.edu/home/mids/m18xxxx/share08
    Save that! That's what you need to do to "checkout" or "clone" a copy of the repository.
  3. Each partner should go to whatever directory they've created for this lab (e.g. "lab08") give your group's version of the command:
    git clone ssh://mich302csd17u.academy.usna.edu/home/mids/m18xxxx/share08
    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:
git add MyDate.class BaseClass.java
git commit -m "This is an informative message."
git push
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 <- this says the next commit will include the new Foo.java
git commit -m "Added my wonderful new Foo.java class" <- commits changes to your personal version of the repo
git push <- 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.
  1. Make sure the README file has the names and alphas of all three team-members in it!
  2. Cd to the directory in which your lab files lie, and give this command:
    from a lab machine : ~wcbrown/submit.ic211  lab08 README *.java MyDate.class
    from your laptop vm: ~/bin/submit.ic211  lab08 README *.java MyDate.class
Don't worry about submitting the javadoc output. Like the class files, I'll just generate it from your source code as I grade.