CSCI2014 Software Construction with JavaProject Holiday Tracking

Project Holiday Tracking System

Introduction

Employees in a company have a given number of days holiday allowance, which is specified in the employment contract. To book some days off, an employee makes a request, which the manager responsible will either grant or decline. If the request is granted then the details are recorded. In a small company with a few employees, the holidays may be tracked using a planner. However, as the number of employees grows keeping track becomes more difficult. Sometimes there are further considerations to take into account such as having sufficient cover in critical departments.

This project is to develop a computerized booking system. Initially, the user of the system will be the manager in charge of holidays. Later versions may provide a web interface for employees to view their holiday status and to submit their requests.

The functional requirements of the system are as follows:

  • To store employees' annual holiday allowances
  • Provide a suitable user-interface to allow a manger to enter a holiday request for an employee
  • To carry out validation checks (e.g. sufficient days allowance remain to meet the request)
  • Cancel a holiday request
  • Report the holiday status of an employee
  • Generate a report of employees on holiday for a specified period
  • Reset the system at the start of the year.

To develop the holiday tracking system we shall use a spiral development methodology (see [Horstmann] page 618). This involves starting with a simple prototype, followed by a series of reviews and incremental stages to create more sophisticated prototypes. Some parallel directed exercises (see other exercise sheets) will help to develop the programming techniques needed to build the prototypes.

Programming requirements
Prototype 1 – Basic model classes.
Employee Holiday Record class.
Collection of Holiday Records. / Simple class design and implementation
Testing
java.util.Collection and java.util.Map classes
Prototype 2 – GUI
A form to input holiday request data. / Java GUI Components
Layout managers
Prototype 3 – Integration of 1 and 2.
Using a form to manage holiday requests. / Event handling
Data validation
Exceptions
Model-View-Controller architecture
Prototype 4 – Persistence.
Saving and loading data. / Serialization
java.io.ObjectStreams
Prototype 5 – Enhancements
Reports
Canceling holiday requestsUsing dates / java.util.Iterator
java.util.Calendar

Take hard copies of the program listings, tests and outcomes at each stage. File them in your portfolio as you go along. Each stage does not have to be 'perfect'. What matters is that the main programming objective has been achieved.

Prototype 1 – Basic model classes.

1Design and implement a Employee Holiday Record class. Each record should have an employee ID, maximum number of days holiday allowance, and a field to record the number of days holiday taken (or remaining). In addition to set and get methods, there should be methods to deal with the holiday count. In this prototype ignore actual dates, just deal with the number of days of holiday.

Create some instances of the Employee Holiday Record class, and test all the methods thoroughly. Create a test plan and record the outcomes. Print out hard copies of the holiday class, test programs and results.

Holiday Record / HolidayPlanner
- employee id
- allowance
- count / * / - company id
- year
- collection of holiday records
...methods... / ..methods...
Initial UML Class Diagram

Create a HolidayPlanner class to hold a collection holiday records for a company. The class should include methods to add, remove, and find an employee's holiday record. Populate this class with a set of holiday records, and test all its methods. Print out hard copies of the HolidayPlanner class, test programs and results.

Write a short summary (300 words) about this prototype: what it has achieved and its limitations.

Prototype 2 – GUI to collect holiday request data

2Design and implement user interface to display a employee's record and to enter the data for a holiday request. The GUI should be a 'Form' with fields to enter an employee ID and the number of days holiday requested. A buttons panel may hold buttons to action events such as 'Find', 'Submit', 'Clear'. You may also consider creating a menu bar with some potential menu items, e.g. open, save, print data files.

Correctness and validation of the data is not a primary concern in this prototype. The requirement is that a form can be displayed, data can be entered, and eventually used to update an employees holiday record.

Obtain print out(s) of your GUI and label the containers and components used to construct it.

Prototype 3 – Integration of GUI and Model classes

3This stage links the classes in prototype 1 and the Form in prototype 2. Implement the actions corresponding to the events generated by the user. For example, when a holiday request is submitted, the data from the Form should be used to update the holiday record for the employee. A message should be displayed to confirm that the holiday request has been granted or not.

The purpose of the prototype is to ensure that actions will take place corresponding to the user's inputs. Validation of the data should take place. e.g. that the data has been entered correctly, and that the employee has sufficient days allowance to satisfy the holiday request. Below is the dialogue for a successful request.

Use Case: Successful Holiday Request
User / System Response
1. Enter Employee Id
2. Look up employee and display details
3. Submit holiday request details
4. Validate request
5. Update Employee record
6. Display confirmation message

Produce other use case dialogues showing the cases when the request fails.

Draw up a test plan and test your system thoroughly, including all validation possibilities and error paths. Show a printout of the employee records before and after to show that updates have occurred as expected (or not as the case may be).

Prototype 4 – Persistence

4In prototype 3, all the data that is created within the program is lost when the program ends.

a)Modify prototype 1 so that the HolidayPlanner is saved in a file. Then test that it can be loaded in again.

b)Modify the prototype 3 so that the collection of employees can be loaded from the file when the the program starts, and to save updated data. Consider whether saving should be done when the user quits the program, or after each successful request is processed, or by the user making a 'Save' request.

Prototype 5 – Enhancements

5Implement one or more of these enhancements:

  • Reset all holiday allowances (start of year operation).
  • Cancel a holiday request.
  • Provide a way to generate a printed reports.
  • Store additional information about the holiday request, e.g. date it was made.
  • Deal with real dates (or day numbers), to show which days are being taken as holiday.
  • Your own idea:- as discussed and agreed with your lecturer.

Hand-in : End of Week 6 ( 7th November 2003 )

For the assessment hand in the following documentation:

  1. Listings of your classes for prototype 3, including test programs and results from prototypes 1, 2 and 3.
  2. Screen dumps of the GUI Form. Clearly label and identify the various components that you have used.
  3. Final program listing (prototypes 4 and 5 combined).
  4. Use-Cases and test plans.
  5. Test programs for the classes, together with their output. Annotate the tests with handwritten comments to highlight any interesting facets.
  6. At least one side of typed A4 (font size 12), discussing aspects of your project. You should
  • discuss the design of the classes, and how they work together;
  • identify successful and unsuccessful outcomes of your code;
  • describe difficulties that you are unable to resolve satisfactorily;
  • suggest extensions and enhancements to the application.

Assessment Criteria

  1. Organisation of listings, test plans, documentation, discussion.
  2. Quality of test plans, test programs, and observations.
  3. Design and implementation of GUI.
  4. Validation code and error handling
  5. Completeness and quality of the programs.
  6. Structure of the program, e.g. Model-View-Controller architecture.
  7. Quality of discussion.
  8. Evidence of ownership, i.e. attendance record and observation of participation in lab classes.
  9. Viva (as necessary).

lz/csci2014/ProjectHoliday.doc/oct03Page 1 of 3