1400 - Prog - 7 - Weather Forecaste
CIST 1400, Introduction to Computer Programming
Programming Assignment
In this assignment you will be implementing a weather forecaster. It involves writing 3 different classes plus a driver program. It is recommended that
you write one class at a time and then write a driver (tester) program to ensure that it works before putting everything together. Alternately, you can
use the Interactions tab of jGRASP to test some of the early classes. This is discussed in the next few pages.
Write a multi-class program with three classes and a driver.
Based on the following UML diagrams, implement the three required classes, Temperature , Season , and Weather . You will also implement
a program that uses all of these classes in some fashion, Forecaster.java .
Name your classes as follows:
Temperature in source file Temperature.java
Season in source file Season.java
Weather in source file Weather.java
Forecaster in source file Forecaster.java
Program 7
Overview
Goals
What to Implement
Class and File Naming
Work on each class individually, and only in little bits at a time. The suggested order of development for the classes is:
1. Season
2. Temperature
3. Weathe
As you write each of these, test each method as you write it. Methods of testing are discussed in the next section, "How to Test Individual Classes".
After these three classes are developed, you can then work on the Forecaster program that will be discussed later in this document.
Plan to spend the full time available on this assignment. This is not an assignment that can be written in a night or two. If you parcel out you
development over the course of the entire time available, it should be manageable. This is especially important because you can't submit to WebCAT
until you have all four classes written and can submit them all at the same time.
As you develop individual classes ( Season.java , Temperature.java , and Weather.java ), you can test them separately in Web-CAT fo
no grade.
Web-CAT "Assignment"
Labeled FOR TESTING ONLY - NO GRADE
File(s) to Submit
Summer XXXXXXXXXXHW07 - Season Season.java
Summer XXXXXXXXXXHW07 - Temperature Temperature.java
Summer XXXXXXXXXXHW07 - Weather Season.java , Temperature.java , Weather.java
When you are ready to test the Forecaster.java file, you will submit all four files ( Season.java , Temperature.java ,
Weather.java , and Forecaster.java ) to the actual assignment that will be graded: HW 07 - Summer 2019 : Weather Forecaster -
SUBMIT ALL FOUR FILES FOR GRADING.
Since the Submission Energy feature of WebCAT is turned on, you only have 3 submissions per hour once you are at the point of testing all four files
working together. This means that a lot of testing needs to be done locally before you're ready to submit to WebCAT.
How To Not Be Overwhelmed By This Assignment
Testing Individual Classes with Web-CAT
As you write each of the classes below, you should test them as you implement various fields and methods. One way to do this is to write an
accompanying driver program. For instance, as you write the Temperature class, you might also write TemperatureDriver.java which
includes a main() method and does basic calls on each of the methods. This would give you good practice working with each of the methods in
the class to build on for future use in other classes.
Another, quicker way to test classes as you write them is to use Interactions pane/tab of jGRASP. When you have written a little bit of code (i.e.,
implemented some fields or a single method of the class), you can compile that code in jGRASP as normal and then go to the "Interactions" tag in the
ottom window of jGRASP (alongside "Compile Messages", "jGRASP Messages", and "Run I/O").
After you have compiled the class you're working on, selected the "Interactions" tab, and then clicked in that window at the bottom of jGRASP, you
can interactively create and work with objects, inspecting the object contents (fields) in the "Workbench" window on the left side of jGRASP.
Using this method of code writing can speed up the development process dramatically because you can immediately catch issues with your code and
test things immediately.
It is suggested that you write a method and then compile and test that method immediately instead of trying to write all of the methods at once and
then test them. Once you are fairly certain one method works co
ectly, move on to the next method. You may discover in later testing that something
may be
oken and have to come back and fix it, but test each method as thoroughly as possible after you write it.
As an example, when writing the Temperature class, implement the instance variables and write the default constructor and then test it to make
sure it works co
ectly.
Notice in the example on the next page that you're not required to use semicolons to end statements in the Interactions tab because you're not
necessarily writing complete Java statements, you're just testing individual methods. Additionally, a number of different methods are being tested in
the example image displayed, but only after they have each been individually tested incrementally.
How to Test Individual Classes
One possible use of the Interactions tab to test your Temperature class as you develop it:
What the Workbench panel might look like after working with a Temperature object in the Interactions pane a bit:
The first, shortest, and easiest class you should write is the Season class. This class represents a season and should be saved in the file
Season.java . Use the UML diagram below for requirements.
Season
- season : String
«constructor» Season()
+ getSeason(): String
+ setSeason(newSeason: String) : void
+ toString() : String
+ equals(other: Season) : boolean
Here are
ief descriptions of the fields:
Field Description Notes
season Stores name of cu
ent season The value can be one of spring , summer , fall , winter , autumn in lowercase
Here are
ief descriptions of all of the methods you should implement for the Season class. Make sure to name them and implement them exactly
as you see them here as this is how Web-CAT will test them.
The Season Class
PLEASE NOTE: The "Sample Interactions Tab Test Code" would be entered into the Interactions tab in jGRASP after you have added a method and
successfully compiled the code. These samples are not comprehensive and may not test every single aspect of the methods. You should use these
as jumping-off points for your own testing.
Method Description
Sample Interactions Tab Test
Code
Season() Default constructor, defaults to winte
Season x = new Season();
Season y = new Season()
getSeason() returns the cu
ent value of season
Season a = new Season()
a.getSeason()
setSeason(newSeason)
Sets season to lowercase version of parameter newSeason if valid,
egardless of capitalization (i.e., SuMMer and summer and SUMMER
should all set summer for season); nothing done if newSeason is invalid.
Season b = new Season();
.setSeason("summer")
.getSeason()
.setSeason("aUtUmN")
.getSeason()
.setSeason("potato")
.getSeason()
toString() Simply returns the season, the same as getSeason()
Season c = new Season()
c
c.toString()
equals(other)
Returns equality of two Season objects if their seasons match; autumn
and fall are considered the same.
Season d = new Season()
Season e = new Season()
d.equals(e)
e.equals(d)
e.setSeason("sumMER")
d.equals(e)
The Season Class, continued
The next class you should write is the Temperature class. This class represents a temperature and should be saved in the file
Temperature.java .
Use the UML diagram below for requirements. Exact implementation is up to you. Pay careful attention to changing the scale or setting the
temperature. For instance, if the temperature is set at 32° F and then the scale is changed to C with the setScale() method, how will you
handle the temperature?
Temperature
- degrees : double
- scale : cha
«constructor» Temperature()
«constructor» Temperature(temp : double, sc: char)
+ getTemp(): double
+ getScale() : cha
+ set(temp: double, sc: char) : void
+ setTemp(temp: double) : void
+ setScale(sc: char) : void
+ toString() : String
+ equals(other: Temperature) : boolean
Here are
ief descriptions of the fields:
Field Description Notes
degrees Stores temperature should be between -50° and +150° Fahrenheit, inclusive
scale Indicates Celsius or Fahrenheit as must be capital C or F
The Temperature Class
Here are
ief descriptions of all of the methods you should implement for the Temperature class. Make sure to name them and implement them
exactly as you see them here as this is how Web-CAT will test them:
Method Description
Sample Interactions Tab Test
Code
Temperature() Default constructor, sets temperature to 0° Celsius. Temperature a = new Temperature()
Temperature(temp,sc)
Specific constructor, sets temperature and scale; make sure
temperature falls within valid range and scale is co
ect.
Temperature b = new Temperature(10,'C')
Temperature c = new Temperature(-40,'F')
Temperature d = new Temperature(-60,'F')
Temperature e = new Temperature(151,'F')
Temperature f = new Temperature(66,'C')
Temperature f = new Temperature(-46,'C')
Temperature g = new Temperature(10,'z')
getTemp() Returns the cu
ent temperature based on the scale.
.getTemp()
c.getTemp()
c.getTemp()
d.getTemp()
e.getTemp()
f.getTemp()
g.getTemp()
getScale() Returns the value of the scale field.
.getScale()
c.getScale()
c.getScale()
d.getScale()
e.getScale()
f.getScale()
g.getScale()
set(temp,sc) Sets temperature and scale; if either is invalid nothing happens
.set(10,'C')
.set(-40,'F')
.set(-60,'F')
.set(151,'F')
.set(66,'C')
.set(-46,'C')
.set(10,'z')
setTemp(temp)
Validates the temperature for object's scale; no change to
temperature if invalid; make sure to validate for given scale.
Temperature j = new Temperature()
j.getTemp()
j.setTemp(12)
j.getTemp()
Temperature k = new Temperature(112,'F')
k.setTemp(-14.2)
The Temperature Class, continued
Method Description
Sample Interactions Tab Test
Code
setScale(sc)
Sets the scale; parameter can be either upper or lowercase,