[Lab 1] [Lab 2] [Lab 3] [Lab 4] [Lab 5] [Lab 6] [Lab 7] [Lab 8] [Lab 9] [Lab 10] [Lab 11]

COMP2100
Lab 2: Eiffel Revision and PSP

Summary

You will write a small Eiffel program, following the PSP and filling in the Defect Log and the Project Plan Summary.

Aims

• Refresh your Eiffel programming skills.

• Give you some practice following the PSP and filling in the forms.

Preparation

Read through your notes for Lecture 2, Lecture 3 and Lecture 6. Read the Project Plan Summary Instructions, the Defect Recording Log Instructions and the Process Script.

Materials

You will need the following PSP forms, scripts and instructions:

• One copy of the Project Plan Summary form. (Use the one for the initial process. That's the one headed "Table 12.6" which has some sections greyed out.)

• One copy of the Defect Recording Log form.

• The Process Script.

• The Defect Recording Log Instructions.

• The Project Plan Summary Instructions. (Again use the instructions for the initial process, headed "Table 12.7".)

The instructions are at the back of your brick. The forms are in the pad you should have received with your brick. The forms and instructions are also available online as PDF through the PSP Page.

---

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 an Eiffel class YEAR, intended to be part of a date and time library. This class must have the following features:

1. An INTEGER attribute value in which the number of the year will be stored.

2. A BOOLEAN query is_leap_year which returns True if the year is a leap year and False otherwise.

3. A creation routine make which takes a single INTEGER argument, and sets value equal to the value of that argument.

4. A command self_test, also a creation routine, which prompts the user for a year, reads an integer value, calls make with the value it has read, and then uses the result of a call to is_leap_year to print a message.

Compile the program with self_test as the starting point for the system.

Here is a sample interaction with the program. What the user typed is in blue, system output is in black.

[comp2100@karajan]$ test_year
Year = 2000
Yes, 2000 is a leap year
[comp2100@karajan]$ test_year
Year = 1999
No, 1999 is not a leap year

Note that 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 60. For `Maximum' put 75 and for `Minimum' put 45.

For `Minutes/LOC' put 2.0. This value is much lower than the values you will see in the textbook. It's my first guess. It's low because I think it generally takes quite a few lines of Eiffel to do simple things, compared with languages like C, also because this is a very simple program.

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	To Date %
Plan	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 with more than one creation 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:

compile -clean -o test_year year self_test

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, you can either count the (non-empty) lines by hand, or use the following shell command:

grep -vc '^[ \t]*$' *.e

(Explanation: The `-v' option reverses the sense of the selection, so it selects lines that don't match the pattern. The `-c' option just counts the matching lines, rather than printing them all. The pattern matches all lines that are either empty or contain only spaces and Tabs. The `^' character matches the start of the line. Putting a list of characters in square brackets matches any one of them. The `\t' is a special code to match a Tab character. The asterisk says match the previous bit any number (zero or more) times. The dollar sign matches the end of a line.)

The only funny thing here 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?

[Lab 1] [Lab 2] [Lab 3] [Lab 4] [Lab 5] [Lab 6] [Lab 7] [Lab 8] [Lab 9] [Lab 10] [Lab 11]