CS239 Advanced Programming

Software Requirements Specification

Programming Assignment 2

Change Order to PA1

How much rain V2?

Timesheet due with your submitted program as the last page of the submission. See link for notes.

Final Program Due by Feb 6 10:00pm in Linux submit. Hardcopy due on Feb 7.

Introduction

Purpose: In PA1, the application that was delivered permitted entry of data by hand. After several weeks of entering rainfall data over and over and over again, the customer asked for a change order for the program. They want the ability to choose where the data is coming from, alter that data and then save that data at the end of the session.

Deadlines

Submit: Wednesday February 6 before 10PM.
Report: Thursday February 7 at the beginning of class. A 10 points/day late penalty will apply for each of the 2 deadlines. If the submit is late, the report is due the next class or lab session day after successful submission.

Background

A number of areas of the country, including much of the Southeast, are in the middle of droughts. Rainfall is important to maintaining healthy community water supplies. In addition, farmers and others working in agriculture are concerned about their growing seasons and the amount of rainfall and the patterns of rainfall to facilitate growing crops. This application will begin to build an application that would enable us to track and report rainfall amounts and summaries for a given period of time.

Existing program components

Your application will be written from your PA1. Your application will consist of 3 Java classes, RainfallDriver, RainfallIO and Rainfall. These classes are described in the writeup for PA1. You may have additional classes as you find useful to your application.

Changes to program behavior

When the application is first launched, the initial welcome message should display as before. But now, a menu of choices should be presented to the user as follows:

Indicate your choice of activity below
	1. Load a file containing the rainfall data.
	2. Enter or update rainfall data.
	3. Print rainfall report.
	4. Save the rainfall data.
	5. Exit the application.

Options 2 and 3 should operate as the enter and print methods did before (with a couple of minor changes to the report as described below).
Option 1 should prompt the user for the name of the input file, and it should use that file data to load the Rainfall object.
Option 4 should prompt the user for the name of the output file, and it should use that file to store the data from the Rainfall object.
Option 5 should check that the user saved the rainfall data prior to exiting and then exit the application.

The Rainfall Report prints with some inconsistent labels. The new version is as follows:
- 0th line - blank
- 1st line - "Annual Rainfall Report"
- 2nd line - blank
- 3rd line - "Annual Rainfall: " followed by the total rainfall.
- 4th line - blank
- 5th line - "Monthly Rainfall"
- 6-17th lines - tab space followed by the month name followed a colon followed by a space followed by the rainfall total.18th line - blank
- 19th line "Wettest Month: " followed by the name of the month with the highest total followed by a space and the rainfall amount.
- 20th line "Driest Month: " followed by the name of the month with the lowest total followed by a space and the rainfall amount.
- 21st line "Highest Rainfall: " followed by the name of the month and the numeric day of the day with the highest rainfall amount followed by that amount. Multiple days should be separated by a comma and a space.
- 22st line blank
- 23rd line - "End of Rainfall Report" this line should be followed by a single newline character
Clarification - For manual entry (option #2, a single 0 by itself on a line signals the end of input.)

Detailed descripitions of menu behavior and options 1, 4, and 5

Option 1

When the user chooses option 1, they should receive a prompt message "Enter the name of the comma separated file for input: ". The user should enter the value on the same line with the prompt. This entry should be followed by the output of a new line character.

If the file exists and can be read by the application, each value should be read in and stored in the array. If any errors in the data are encountered, a heading should display, "Error in input data." This line will be followed on the next with each of the error messages. Error messages should go to the moniter based on the specific errors found in the data. The errors that can occur will be the same as in PA1, but instead of prompting for reentry, the application should simply display the offending line with the diagnostic message, followed by "Data ignored.". Order of errors is the same as PA1, non-numeric values, bad month, bad day, bad rainfall amount. If two or more errors occur on the same line, you should only print the first such error that you encounter in the order of bad data, bad month value, bad day value, bad rainfall amount.

NOTE: The input file should have the same format as the manual entry: mm,dd,rainfall followed by a newline character.

If the file does not exist, the application should print an error message as follows: filename + " does not exist. Try again.". Then you should reprompt the user for a filename on the next line.

If the file exists, but cannot be opened, the application should print an error message as follow: filename + " cannot be opened. Try again.". Then you should reprompt for a filename on the next line.

Option 4

When the user chooses option 4, they should receive a prompt message "Enter the name for the output file". The user should enter the value on the same line with the prompt. This entry should be followed by the output of a new line character.

If the file does not exist and can be opened by the application, each non-zero value should be printed to the file in the format of mm,dd,rainfallAmount.

If the file does exist, the application should print a warning message as follows: filename + " already exists. Do you wish to continue (Y/N)". If the user types "Y" or "y", write out the data to the file. If the user types anything else, reprompt them for the name of the output file.

If the file cannot be opened, the application should print an error message as follow: filename + " cannot be opened. Try again.". Then you should reprompt for a filename on the next line.

When the file has been saved, print a message, "Your data has been saved to " followed by the filename.

Option 5

If the user has previously saved the file, print an exit message, "Exiting rainfall tracker\n" and end.
If the user has not saved the file, print a warning message, "Do you wish to exit without saving (Y/N)?" If they respond with Y or y, print the exit message and end. If they respond with anything else, do not exit and redisplay the menu.

Menu behavior

The menu as described above should display upon entry to the application and each time a user choice has been executed. The menu should always have a blank line before the first heading line, and each of the choices are preceded by a single tab character. The cursor should rest on the line below the menu for the user's entry.

If the user types in any invalid choice (bad data or an incorrect number), you must print an error message on the next line, "Your choice " followed by the entry " is incorrect. Try again." The cursor should wait on the same line as this error message.

Additional Program Requirements

You may add additional methods, but these should be private "helper" or utility methods, unless you need to use them in both Rainfall and RainfallIO.
Rainfall amounts should always print with three decimal positions.
Month numbers and days are 1 based. In other words a user will enter January as month 1 and the first day of the month as day 1.
Your program must include an acknowledgement section acknowledging help received from TAs or reference sources. You do not need to reference receiving help from the instructor.
If you received no help your acknowledgement section should have a statement to that effect.
Your program must conform to standard Java programming standards and the additional requirements for this class. See the Style Guide for this class.
You must use a two dimensional array for this program.
Where feasible, you should use prevention to avoid having your program throw exceptions. In some cases, you must use an exception handler as required by the compiler. Since the user is entering the file names, we expect that this will be problematic and will want to prevent the exception from actually being thrown.
If you do exception handling, you must catch the exact exception that will be thrown.

Timesheet

To help give you some idea of how you are spending your project time you will fill out a timesheet .xls, timesheet.pdf, timesheet.ods recording all of the time and the category into which that time goes for every block of time that you spend on the project. (Choose whichever format you prefer. The pdf version is intended to be filled out by hand while the other two are intended to be electronic records.) While it may be scary to see how many hours you put into a programming project, this will help you to plan better for future projects in the class and others. When working on custom work, your time might also be billed back directly to the customer necessitating an accurate accounting. An explanation of the categories:

Design - Any time that you spend thinking through, charting, diagramming, or writing pseudo code is considered design time. You may have a big chunk of design at the beginning, and then small amounts as you try to work through a particular problem or issue.
Coding - Any time spent writing code that is new to the project would be coding time. Don't count the time that you are coding in direct response to an execution error from a test. Do count as coding any time that you spend coding after doing a design or redesign and before you begin testing the new solution.
Testing - Any time spent in testing the program using data. This might be unit testing (where you are simply testing a single component) or system testing (where you are testing how well the whole project works.)
Debugging - This is the time that you spend correcting and retesting problems that you find. The testing and debugging process might lead you to return to design if a particular component is not working properly.

Honor Code

This work must conform to the JMU Honor Code and the specific requirements of this class. You may have an opportunity to work with your team in class on this assignment but only in the confines of the classroom. Any other help must come from the professor or the TAs for this class. See the collaboration policy for further information.

Grading

You will receive 70% of the grade by successfully submitting the program (which includes passing all submit tests) on time.
10% will be attained by successfully creating the output files. Submit does not check for these.
The remainder will be based on your conformance to the Style and other requirements of the assignment. Review the Style Guide and the program checklist before your final submission.
All grades will be based on 100 points.
If a program does not pass the submit tests, you may submit to the non-test submit system which will provide a hardcopy report. The 70% grade will be based on the number of tests that pass my manual tests (which will be based on the submit tests.)
You may submit any number of times. The only one I will count is the one that corresponds to the hardcopy report that you turn in. (Note: I may later in the semester restrict the number of submits, but for now, consider it unlimited.)
Successfully submitted programs that are late will be graded, then a 10 point penalty assessed for each day late. Saturday will not be considered a late day. Late penalties apply to programs submitted on time but not turned in on time. It is expected that the hardcopy will be turned in on the deadline or within one class period of a successful submit run.
No programs will be accepted after one calendar week past the due date of the assignment.

Hints

While you have a largely working program as a base for this project, you may want to review your design. One change that may cause you some redesign is the requirement that error messages from a file look slightly different than the error messages provided interactively to the user.
Be sure that you understand how to test for the presence or absence of a file before you try to embed it in the code.
Worry about all of the validation checking for the file and the exit until you have the processing of the file and the saves working properly. The work on the validation problem...in many cases, you may have to check for two independent errors in the same loop.
Be sure to review your final program for conformance to the Style Guide which is available under the Resource tab.