October 6, 2003
Due: Sunday October 12 at 9:00 pm
Purpose: Our goal in this exercise it to provide you an
introductory experience of program implementation and design. This
assignment has two parts. The first is to implement a pretty well
specified class of an object we'll call a TemperatureAdvisor. The
second part is to design (but not implement) a software module, which
we'll call a RemoteInterface,
which has to satisfy some external requirements. So our specific
objectives are to practice implementing a simple class encapsulating
properties and responsibilities, performing simple arithmetic
calculations with numeric values in Java, and using a first Java
library class (TemperatureAdvisor),
and to practice modeling, and turning a model into a particular
software design (RemoteInterface).
Time: The programming and design tasks in this homework
are intended to be extremely simple, and so really shouldn't take much
time in themselves, maybe an hour each at most. The real emphasis
in the first part is that you take your first steps in constructing the
framework of an application in a programming environment. These
comprise a class declaration including data and methods as well as
(possibly) a constructor. In the second part the emphasis is to
practice being specific in structuring a design, making explicit
decisions about how to structure the required functionality. Once
over such humps in the learning curve, rest assured we will be better
prepared to undertake greater programming challenges in the weeks to
come.
Turn-in, grading and due date: The due date is Sunday October 12 at
9:00 pm. The turn-in consists of the TemperatureAdvisor.java
file, transcript of an Interaction session (i.e. copy the text in the
Interaction Pane into something like NotePad, save it off as a .txt
document and submit that document in the turn-in page), and a design
document for
the RemoteInterface. Both turn-in and grading will be as before with
Homework #0, i.e. web submission and printed receipt. Yes!
We do want a printed receipt; it gives us something concrete to write
on, and something for you to save. Note that the ELECTRONIC turn
in cut-off is Sunday and the paper turn in is lecture Monday.
Syntax, semantics and style:
We discuss the concepts of syntax, semantics and style in this course.
They form the metrics by which anyone will judge your code, in
particular your TA in grading your assignments, so you will want to
understand them well. A good suggestion would be to closely imitate the
style and formatting that you observe and study in the code examples in
your text. Further grading guidelines for the TAs have been posted on
the homework page of the course web page, so you can read them if you
like.
Do you have to use the IPL? We recommend using the IPL for the implementation work if you had any problems with homework 0. The lab assistants are also a great source of help.
Anything else? Yes - these
instructions are much less detailed than the
instructions for homework 0. Be ready to engage in a little problem
solving.
Design Specification: A
TemperatureAdvisor is conceived of as being a simple device for
converting temperature values from Fahrenheit to Centigrade or back,
which also stores the value of the last temperture it was given
(regardless of the scale) as the "current temperature", and is capable
of making wild predictions of tomorrow's temperature. The current
temperature and tomorrow's prediction should support queries to be
expressed in any of the three possible formats: Fahrenheit, Centigrade,
or Kelvin degrees. Notice that we have specified the following
odd behavior: the current temperature state is changed by (and only by)
requests to perform a conversion; this kind of behavior is known as a side effect. That is, the
current temperture is changed as a side effect of performing a
conversion calculation. Odd as that may seem, that's the current
spec.
In order to make your wild weather
predictions for tomorrow's temperature you will want to use a Java
library class called Random,
about which I will say more below.
Output from the conversion or querie
routines should be written to the console window via the System.out.println(...)
command we saw in the Homework #0. However note that if you want
DrJava to print "The current temperature is 50 degrees F", you will
want to use the String concatenation operator ('+') (see your text p.
111) within the parameter String passed to println, so that you can
concatenate the value of the temperature into these other
strings.
Notice that there are some choices to be made in the implementation
details. First you need to identify and name the object's
properties and resposibilities, that is what will be the data and
command identifiers. Then you must choose, and clearly identify the
data types you will use to in declaring the properties and
responsibilities of this object, that is to say the types of the stored
value, parameters, and return values. Beyond the types however,
you need to choose and document the "domain specific data
representation" of the stored value, that is, not only is it an int or
float or double, but is it expressed in Fahrenheit or Centigrade or
Kelvin degrees? This implementation detail, which is undetermined
in the design
and not visible outside the object, crucially effects how you implement
the methods to fulfil the object's responsibilities, and should be
documented in the code.
Another design choice you might consider, if you have read ahead to learn about or already know about Conditional Statements,which we will be addressing in class next Monday, is rather than have separate querie and command messages for returning Centigrade or Fahrenheit values, have only one of each which "switches" on the value of a second parameter in its calling signature, a character value which might be 'c' or 'f' or 'k' (but what if it is some other value?). Yet another design choice is what the initial value of the stored temperature should be. If you don't write a constructor, what does it default to? You may wish to write your own constructor to set it to some other value you might like.
Using the Java libraries:
The standard Sun Java libraries are thoroughly documented at http://java.sun.com/j2se/1.4.2/docs/api/index.html.
Open this page and scroll down the lower left hand list of classes and
select Random,
and read about it. Notice that the first thing the documentation
tells you is that the class Random belongs
in the package java.util.
What this means is that, in order for you to be able to use this class
in your program you need to import it from the package into your
program. This is simple enough conceptually and it is also simple
in practice. All you need to do is put an import statement as the
first line in your .java file, and it should read:
import
java.util.Random;
You could also write "import java.util.*;"
which would make all the classes in that package available to your
program. The way to think about a random number generator is that
it is an object which return you a new "pseudo-random" number when you
ask for one, as if it were a guy with some dice, and you ask him to
roll. The point is that you need to instatiate and hold on to a
reference to this object . Something like this would do the trick:
Random rand =
new Random();
....then later on in your methods invoke something like:
newTemp =
currentTemp + rand.nextInt(20) - 10;
Now which form of random number to generate, and what you do with it is
up to you as an implementation detail. Notice for example that nextInt(20)
returns a random integer between 0 and 20, so that by subtracting
10, I ensure that tomorrow's temperature will be predicted to be within
10 degrees (in whatever scale) from today's. On the other hand
you could also just pick a completely random number out of the blue
(but make sure it is reasonably scaled!).
Operational testing: When
you are done coding you can try things like the following in the
Interactions Pane:
TemperatureAdvisor ta = new
TemperatureAdvisor();
//Call constructor to get named
instance 'ta' for Interactions in Pane.
ta.getCurrentTempC()
ta.convertFtoC(32.0)
ta.getCurrentTempK()
ta.getTomorrowsTempF()
...and so on.
You should omit the usual semicolons at the end of the statements when using the Interactions Pane, because that way Dr. Java prints out a response to your command. However, omitting semicolons in your Java source files will result in syntax error notifications when you compile. Also your initial call to a constructor requires a semicolon in the Interactions Pane.Something to try by way of testing in the interaction pane is this: Create two converter objects with different names. Ask one to convert a value from one scale to another, and then pass the value returned by that call as the parameter to the other converter, asking it to change the value back to the original scale. Needless to say, you should expect to get the same number back. Do you? In all cases? Try some. What if your data types were inconsistent?
Turn-in: You will use the course web site to turn in the files TemperatureAdvisor.java and a copy of the text from a successful testing session that you have performed in the Interaction Pane. (Note that interpretive comments can be entered into the interaction pane also, to explain what you're testing for, and why you are happy or not with the results.)
Grading: You will be graded
on whether your code compiles and executes, and whether the transcript
of your testing session is a reasonable demonstration of the correct
functionality of your software. Your TA will also read your code to
check that it is cleanly written and well formatted - in other words,
written in good style.
High-level Description: The second part of this assignment is
to design the software for a very simple TV remote control, and to
document your design. The important design aspects are what
functionality to include, and the choice of classes, properties and
responsibilities to map the desired functionality to. By "simple"
we mean the TV remote control only has a power button, an up & down
pair of buttons for volume, and another such pair for channel
selection. The external requirements on your software module are
the nature of the signals of the physical external devices, namely the
buttons on the remote the TV's actual controls. Your module
must communicate with these externals in their own terms, and
effectively perform a translation between their different ways of
expressing the same information.Assume that the actual physical buttons
of the remote cause messages to be sent to your control module such as "tvrc.on-off();" (which should
toggle the power), "tvrc.incrementVolume();",
etc. Also assume that the TV itself only understands signals such as "tv.turnOn();" and "tv.turnOff();", and "tv.setChannel(channelNumber);",
taking absolute power, volume and channel values, rather than
incremental ones or toggling signals. This may seem artificial,
and indeed it is. The point of the exercise is to think about how
your software module can translate or restructure information from one
representation (the "relative state" info of the buttons) to another
(the "absolute state" of the tv inputs). Your design should also
address the issue of what happens when decrementing below 0 or
incrementing beyond max values [Hint: Think about modular arithmetic,
or the remainder operator.].
Goals: Our goal is to practice modeling and mapping a model to a software design in terms of classes with properties and responsibilities. As before there are a number of possible ways to structure this problem. For example, one might ask suggestively, is there a way that your design can take advantage of the similarities in the natures of the volume and channel controls? How would you account for their particular differences, if they were both instances of the same thing? The important thing is to clearly identify what classes you want, and what their properties and responsibilities should be, what their relationships to and communication with eachother will be once instantiated, and how this will provide the required functionality. You may wish to express this as "pseudo-code", that is something that looks like an implementation in code, but in which the functions themselves are only "stubbed in" (i.e. only sketchy code or comments between the curly braces), or instead you could express your design in descriptive (yet precise) prose.
Turn-in: You will use the
course web site to turn in a design document. Make sure your TA can
read your design! The easiest way to do that is by using plain text
format such as is created in Notepad (Start -> Programs ->
Accessories -> Notepad). Please do not use Word or Wordpad as these
generate all kinds of formatting data that get messy in
translation. Also makes sure
your TA can read your design in the sense that it be
intelligible. Imagine it as a design spec you could hand to
another programmer to implement.
Grading: Grading will be based on the elegance of your design.
The completeness of your selection of functionality to include is much
less important than the completeness of your mapping of functionality
to a design. It is also important to justify your design decisions.
Overall Turn-in: To turn in
your solutions, go to the
turn-in page for homework 1 by following this link. Fill out the
form and use the browse buttons to find your TemperatureAdvisor.java
file, your transcript.txt file and your RemoteInterface.txt file
(Please note: they must have
precisely these names). When you are sure you have filled in the
form correctly, click the turn-in button. You must use the Web form
to turn in file. You won’t get credit for it
otherwise. Be sure to read carefully any further
instructions it contains, or any instructions contained on the
"receipt" page that comes back. Be sure to print or save of the html
file of the receipt page for physically handing in.