Exercise 1
Write a program to solve the problem below, following the initial PSP and filling in the
Project Plan Summary and Defect Recording Log as you go. Read through all the
instructions and the PSP notes below before you start.
Write a Java class Year, intended to be part of a date and time library. This class must
have the following features:
1. A private field called value of type int in which the number of the year will be
stored.
2. An accessor method called getValue() that returns the value of value.
3. A function called isLeapYear() returning a boolean which returns true if the
year is a leap year and false otherwise.
4. A constructor that takes a single argument of type int, and sets value equal to
the value of that argument.
5. A main() method, used for testing the class, that takes an integer value given as a
command line argument, creates an instance of Year with the value it has read,
and then uses the result of a call to isLeapYear() to print a message.
Here is a sample interaction with the program. What the user typed is in blue, system
output is in black.
[comp2100@partch]$ java Year 2004
Yes, 2004 is a leap year
[comp2100@partch]$ java Year 2005
No, 2005 is not a leap year
A year is a leap year if it is divisible by 4, unless it is divisible by 100, in which case it is
only a leap year if it is also divisible by 400.
PSP Notes
Follow the PSP Process Script and the PSP Project Plan Summary Instructions for this
development, but with the following variations.
Planning
Because this is your first PSP program, you have no past data to use, so I will give you
some estimates to use in the “Plan” column. For later programs you will use the numbers
in the “To Date” and “To Date %” columns of the previous form.
First fill in the “Program Size” part of the “Plan” column. For “Total New & Changed”
put 40. For “Maximum” put 60 and for “Minimum” put 20.
For “Minutes/LOC” put 2.0. It's a guess. My old values were for Eiffel, and Eiffel code is
quite different to Java code.
For the planned time in the different phases, use the following values as if they were the
“To Date %” values for the previous development:
Phase
Plan
To Date %
20
Design
10
Code
20
Compile
10
Test
20
Postmortem
20
There is no particular science behind these, but they're something to start with.
The Process Script says to record the time taken for each phase in the Time Recording
Log. I think this is unnecessary: I suggest that you just record the times directly in the
“Actual” column of the Project Plan Summary form.
I guess the reason he wants you to use the Time Recording Log is so that you can keep
track of time lost to interruptions. So if you want to be extra-precise, get a spare Time
Recording Log and use it, with categories the same as the development phases. Keep it
separate from your main Time Recording Log that you use for all your COMP2100 work:
on that, all of this should appear as a single entry, in the Activity Category “Labs”.
Design
I haven't given you very much time for this, but it is important to take a little bit of time
to think about how you will write this program before you start typing it into the
computer. Read through the requirements given above and make sure you understand
them. Do you understand how to write a class that has a constructor and can have
instances, but that also has a (static) main() routine? Are you sure you understand the
logic in the decision as to whether a year is a leap year?
I am not specifying a design format, but I want you to take the time to write — in your
notebook — about how you intend to implement this program. At the very least, write a
short description of how you will implement each feature of every class.
Remember to record the actual time you spend in this phase.
Code
Not much to say here. Write the program, carefully. Record the time it takes.
If, while you're coding, you discover any mistakes you made in your design, record these
in the Defect Recording Log. Such defects would have “Design” in the Inject box and
“Code” in the Remove box.
Code Review
If you have a version of the Process Script which has a Code Review step, ignore that bit.
Skip straight to Compile.
Compile
This phase starts the first time you try to compile your program, and ends the first time
that compilation succeeds.
Unless you have been very careful, the first few times you try to compile, you will get all
kinds of error messages from the compiler, about things like syntax errors. Find and fix
each of these recording them in your Defect Log. Most of them were probably injected in
the Code phase, although some of them you may be able to identify as design errors.
Compile the program from the command line by typing:
javac Year.java
rather than using the Emacs menus.
Record the time spent in compilation.
Test
Once your program compiles, it is time to test it. Does it run correctly? Does it behave
the way it is supposed to? We won't go as far as writing a test script and data files for a
program this small, but you do need to be systematic. Test until you feel confident that
your program is 100% correct.
Here is some sample data just to make sure that you have understood the requirements.
Year Result
2000
Yes
2001
No
2002
No
2003
No
2004
Yes
1900
No
1800
No
1700
No
1600
Yes
Every time your program does something it isn't supposed to do, or gives a wrong
answer, you need to record that in your Defect Log. Also note the time that you located
the defect. Fix the problem, then look at the time again and enter the time taken on
repairs into the Fix Time box.
Remember to record the time spent in testing in the “Test” row of the “Actual” column of
the “Time in Phase” section of the Project Plan Summary.
Postmortem
Now it's time to fill in the rest of the form. Follow the PSP Project Plan Summary
Instructions. Since this is your first program, the numbers in the “To Date” column will
be the same as those in the “Actual” column. (This will be different next time.)
To get the actual program size, count the lines by hand. Later in the semester we'll get
into counting logical lines of code in a little more detail. For the moment, count all lines
except:



those that are entirely blank,
those that only have a brace (“{” or “}”) on them,
those that have only a comment on them.
To make this repeatable, put only one Java statement on each line.
One funny thing you will encounter while doing the postmortem is that you need the
Actual time for the Postmortem phase in order to complete the form, but you won't know
that time until you have completed it. Do as much of the postmortem activity as you can
without filling in this number, then make a rough estimate of how much longer you think
it will take, and use that. There's no way around this. (After a while you'll be able to make
better estimates for this also.)
When you have finished, store the completed forms securely in your lab notebook. Take a
few minutes to write down any reflections you have on the process you have just been
through. How did you feel? Did you learn anything?