Queueing System

Introduction

This looks at one of the current software development processes. You are required to write a report on extreme programming (XP) and in particular part of XP called “Pair Programming”. In order to do this you will need to actually try out the technique on the problem described in Appendix 1. Solving the problem will require writing a program in C# using pair programming.

The Task

A plush new restaurant has opened and wants you to write a system that will pass orders (taken by a waiter) to the chef. The system will be a queuing system so that the head chef gets the next order to be made. Unfortunately, the next orders are not presented to the chef in the order they are taken. Secretly, the waiter decides whether the customer is a priority customer (media person or other celeb, friend of management, restaurant inspector etc) or just a normal customer. Priority customers (celebs) are processed in the order they are taken and normally processed before normal customer (pleb) orders. However, to prevent people being stuck all night, if a pleb has been overlooked five times due to there being celebs present then they will be promoted and become the next available celeb.

To solve this you will need a class to hold an order for a table which will need to have a List of strings in it (where each string describes an item ordered e.g. “Roast Chicken” or “glass of house red wine” etc.). The order class should also store the table number and the waiter’s initials. Write and test this class (I’ll call it Order), then create a queue of orders using the Queue class. Test this queue of orders before progressing.

Next, create an order manager class which will have fields/attributes something like:

Queue highPriority;
Queue lowPriority;
int passCount;

And methods including the following:

void addHighOrder(Order);
void addLowOrder(Order);
Order getNextOrder();

(The constructors, display methods etc. have been omitted).

The program itself will be networked program with each waiter having their own hand held terminal. We do not have the terminals yet, so we will simulate them during the development by using a multi-form program. We will have a menu based main window which will also act as the kitchen terminal. When an order appears it is displayed in the main window. The chef goes away and prepares the order. When that order is complete, the chef will click a button and the next order will be displayed.

The waiter’s terminals will be modelled by other forms in the same project. These will allow an order to be entered then transmitted by pressing a button (labelled ‘Send’ or some such).

You will need to have one priority queue object which can be shared between all the forms this should reside in the main/kitchen form. The other forms should access this via delegates.

Initially, you should get the program working with one kitchen form and one waiter’s form. When it is working fully, you can have a list of waiter’s forms and have new ones added by the menu in the main/kitchen form.

Initial Report

This should be written before you start the pair programming exercise. Extreme programming (XP) is a modern software development process which is gaining favour in some sectors. One of the features of XP is something called pair programming (where one person writes the code and the other checks it for errors as it is being written). You need to find out about XP, including how it works (so you can adapt it for the program) and what its claimed benefits (and disadvantages) are (so that you can evaluate your experiences against these in the final part of the assignment). You should reference source material that you have used throughout, but particularly in this part of the report (be aware of the university’s policy on plagiarism).

As a final part of this preliminary report, you should include a brief plan explaining how you are going to use what you have found out about XP in solving the programming part of the assignment.

Program

During pair programming, one person writes the program (who we’ll call the coder), and the other ‘looks over their shoulder’ and checks the code for errors by reading it (we’ll call this person the code reader). Periodically, the coder and the code reader swap roles (i.e. the coder becomes the code reader and the code reader becomes the coder). On real projects this swapping of roles occurs either every day or every half day, however, since this is a small problem, this exchanging of roles should be more frequent e.g. every hour. You need to record who is in which role at any given time in a diary (see below).

Diary and Final Evaluation

You are required to keep a diary of the development process. In particular, it should note who is coding and who is code reading, and every time you change roles. You should also not what the coder is coding (i.e. what part of the problem) when you change roles, and all errors that the code reader spots. You should also reflect on any problems or successes as they arise After the program is written (and tested!!!!), you should write an evaluation on how you found pair programming. In particular, you should compare your experiences with the benefits claimed (which you should have found in your initial report) and see if you found them to be the case. You can then evaluate your experiences and decide whether pair programming helped, and if so whether the benefit was as great as claimed (and why).