COMP2100/2500 Software Construction

Lab 1: PSP and SVN

Summary

An introduction to using SVN Subversion Version Control System to share development of a program in a group, and then an exercise in using PSP the personal software process to record development time and defects.

Aims

In order of importance:

• Give you a first experience of using Subversion for version control.

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

• Refresh your Java programming skills.

Preparation

Read through the course notes for Subversion Version Control System particularly about the repeated working cycle of

1. svn update;
2. edit, develop and test; and
3. svn commit

Materials

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

• One copy of the Initial Project Plan summary [pdf]] [odt]] form as an Open Office document or on paper.

• One copy of the Defect Recording Log form. [pdf] [odt]

• The original Process Script or with notes.

• The Defect Recording Log Instructions and the extended list of defect types

• The Initial Project Plan Summary Instructions.

The forms and instructions are available online as PDF through the PSP Page and (directly) in the PSP Directory.

Exercise 1

Using Subversion in group work. For this lab you must use the command line window (terminal). Access on the student labs desktop: Applications »Accessories»Terminal

1. Open a terminal window. (This lab is a lightweight is an introduction to using the command line, you'll learn more about the command line and the shell later this semester.)

2. Find the other members of your team for lab1.

   The team is listed in the file /dept/dcs/comp2100/public/lab1groups.txt.
   Use the command

   % grep $USER /dept/dcs/comp2100/public/lab1groups.txt

   to find the user ids of the other people in your group. (The "%" is not part of what you type for the command, it just indicates the command line prompt, whatever it is.) The $USER here is a shell variable that is automatically replaced by your own UID, which is why this command finds the line of the file that contains your UID.
   Write down your group name and find the rest of your group—change workstations to sit together.

3. When you are sitting near each other:

4. You must clean out your Ubuntu/KDE keyring so that svn security passwords work.

   The cleaning up instructions are in a separate file cleanKeyring.html

5. Each person create a project for this lab in your own directory. Here's what to do.
   If you have a comp2100 directory, change directory into it using the command

     % cd comp2100

   otherwise create that directory:

     % mkdir comp2100

   first, then change directory into it.
   Create a directory for your labs

     % mkdir labs

   and under that, a directory for this lab:

     % mkdir labs/lab1

   Change to this directory for your work:

     % cd labs/lab1

   The cd command changes the working directory as the environment where any following commands are executed.

   If you want a more graphical view of what you have done, look at these directories with the file and directory explorer viewer application.

6. In this directory (your ~/comp2100/lab1check out a working copy of your group's shared program from the repository that I have provided as an initial template. It is called Intro2Group.java

       % svn checkout https://svn.anu.edu.au/SWConstr/lab1/branches/gDayN
   

   where gDayN is actually your group number.

   VERY IMPORTANT: note https://svn... is used here. If you work frm off-campus this is essential. (http://... may work on campus, no guarantees.
   This is a change in 2012 compared to 2011).

   This creates a directory named gDayN in your current working directory. This directory is an SVN project that is tied back to the SVN respository. Change your shell into it

     % cd gDayN

   and look at the files

     % ls 

   and look at its SVN relationship and status

     % svn info
     % svn status -v
     % svn log
   

7. Now start using the file in cooperation with the rest of your team. The aim is for you to change the file so that it prints out the long and short names of all of the team members, in alphabetical order of family names. Use a text editor like emacs or kate (later you will use eclipse but for now, it does not interact easily with subversion - please stick with the simple text editors for this exercise).
   Use the svn commands svn update, svn log and svn commit repeatedly while you edit and test the program. Work simultaneously, don't talk more than you have to to fix misunderstandings.
   To compile the program use

     % javac Intro2Group.java

   To run the program use

     % java Intro2Group

8. When all members of the team have a working copy that is finished and prints out the names of all the team members, that's completed part 1. Have a short break from the computer. Reflection and discussion time: talk with your team members, share experience on how you saw conflicts and how you resolved them without losing any work, and what happened when you forgot to update. The purpose is for each of you to understand what to do for the course assignments when you do more program development in a small team under version control.

Pause to reflect

In future you will probably want to add directories of your own to the repository for homework exercises and perhaps for the other labs. You can do this with

  % svn mkdir  newdirectoryname

and then you will use

  % svn add 

to add files that you have created, or connect projects from eclipse usoing the eclipse pull own menus.
Your assignment work will use a different repository with a trunk that can be read by the whole class, with a branch for each team. That way you can share your work with your partner securely. This is one of the biggest strengths of using version control.

You can also set up space in your personal repository for any computer-based work you do that is important enough to want to keep track of changes and have good backups. Just add more directories to the repository as you need them.

The other good thing about this way of working is that you can work from home, from a friend's computer in Sydney, from the machines in the labs, easily keeping your work synchronised. Just make sure that when you finish working in one location you “svn commit” all your changes, and that when you start working in the next location you “svn update” to get the latest version.

Exercise 2: Program development with PSP, personal SVN repository

This time you work alone not in the team, but consult team members for help in this work.

A directory and program template have been setup in the SVN repository for each student. In your labs/lab1 directory (cd ~/labs/lab1) checkout a working copy

  % svn checkout https://svn.anu.edu.au/SWConstr/lab1/branches/uNNNNN    mylab1

This directory already contained an existing source program called Year.java of which you now have a working copy. Make a small change to the program: add your name as an author. Compile and test. Check status! what files are under vrersion control? changed (modified)? not under version control? Commit your changes to the source file.

Exercise 3: add some PSP

Modify a given program to solve the problem below, following the initial PSP project planning process 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.

Read through the task instructions before you start programming.

The objective is to extend the 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 any number of integer values given on the command line as arguments. For each one it 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.

The rule for leap years in the modern Western (Gregorian) calendar: a year is a leap year if it is evenly divisible by 4, but not divisible by 100; unless it is also divisible by 400. For example: 2000 is a leap year (divides by 400); 1900 is not; 2008 is a leap year.

The Gregorian calendar was adopted in 1752 in England, so print a warning instead, for years before 1752.

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 2005 1751
Yes, 2004 is a leap year
No, 2005 is not a leap year
1751 is out of range (before 1752) for the Gregorian calendar in the English-speaking world.

Additional task

If you have completed the task and done the PSP work, here's a more realistic task as an extender.
Add a pop-up dialog to ask the user for the years, instead of using the console for input and output. This time you should include estimated "research" time in the Design phase (research: looking up details or examples in the Java library, or finding a reference example that you can use as a base).

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. I actually did this in under 30 minutes, which for my actual 38 lines is a speed of 30/38=0.8, but I knew the specification already and didn't have any thinking time.

For the planned time in the different phases, use the following values as if they were the “To Date %” values for the previous development:

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 Watts Humphrey 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 estimated 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 journal (whether this is on paper or in a blog or a textfile — 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. (this can become the comment when you start typing the class in the editor).

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.

If you are working in a tool like eclipse the "compile" phase is really merged with the "code" phase. But it's still important to record the syntax and type errors you make that you have to fix while coding, even if you lump the times together and skip the "compile" phase —so you track the kinds of errors you make, and might improve on.

While you are working, commit changes frequently. Check the status of what you are doing with

  %  svn status -v

As you commit new versions, make sure to include comments that are meaningful in terms of your development process (don't repeat what you have changed in the code, because that's obvious in the code itself: describe the step in your solving the problem, getting your program to work, and suchlike). For example:

  % svn commit -m"first attempt Year.java functions "
... working working working ...
  % svn commit -m"fixed logic error in combining 100 and 400 year tests "
... working working working ...
  % svn commit -m"passed all tests"

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.

After you finish fixing each defect, commit a new version of Year.java to your repository.

In the commit comment, link this version to your Defect Log, by putting something in the comment like: “Fixes defect #17”. You might want to add a short description of what that defect was and how it was fixed. Or not.

svn commit -m"Fixes defect #17 - using the right integer division operator" Year.java

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.

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.

As in the Compile phase, commit a new version of Year.java to the repository after each defect fix.

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

You can review your work progress using the svn log command:

  % svn log

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 left brace (“{”) on them,

• those that have only comment delimiters (“/*” or “*/”) 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 files or on paper in a ring binder or filing cabinet. 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?