Section III. The Payroll Case Study
© Jennifer M. Kohnke
The time has come for our first major case study. We have studied practices and principles. We have discussed the essence of design. We have talked about testing and planning. Now we need to do some real work.
In the next several chapters, we explore the design and implementation of a batch payroll system, a rudimentary specification of which follows. As part of that design and implementation, we will make use of several design patterns: COMMAND, TEMPLATE METHOD, STRATEGY, SINGLETON, NULL OBJECT, FACTORY, and FACADE. These patterns are the topic of the next several chapters. In Chapter 26, we work through the design and implementation of the payroll problem.
There are several ways to read through this case study.
• Read straight through, first learning the design patterns and then seeing how they are applied to the payroll problem.
• If you know the patterns and are not interested in a review, go right to Chapter 26.
• Read Chapter 26 first and then go back and read through the chapters that describe the patterns that were used.
• Read Chapter 26 in bits. When it talks about a pattern you are unfamiliar with, read through the chapter that describes that pattern, and then return to Chapter 26.
Indeed, there are no rules. Pick, or invent, the strategy that works best for you.
Rudimentary Specification of the Payroll System
Following are some of the notes we took while conversing with our customer. (These notes are also given in Chapter 26.)
This system consists of a database of the company’s employees, and their associated data, such as time cards. The system must pay all employees the correct amount, on time, by the method that they specify. Also, various deductions must be taken from their pay.
• Some employees work by the hour. They are paid an hourly rate that is one of the fields in their employee record. They submit daily time cards that record the date and the number of hours worked. If they work more than 8 hours per day, they are paid 1.5 times their normal rate for those extra hours. They are paid every Friday.
• Some employees are paid a flat salary. They are paid on the last working day of the month. Their monthly salary is one of the fields in their employee record.
• Some of the salaried employees are also paid a commission based on their sales. They submit sales receipts that record the date and the amount of the sale. Their commission rate is a field in their employee record. They are paid every other Friday.
• Employees can select their method of payment. They may have their paychecks mailed to the postal address of their choice, have their paychecks held by the paymaster for pickup, or request that their paychecks be directly deposited into the bank account of their choice.
• Some employees belong to the union. Their employee record has a field for the weekly dues rate. Their dues must be deducted from their pay. Also, the union may assess service charges against individual union members from time to time. These service charges are submitted by the union on a weekly basis and must be deducted from the appropriate employee’s next pay amount.
• The payroll application will run once each working day and pay the appropriate employees on that day. The system will be told what date the employees are to be paid to, so it will generate payments for records from the last time the employee was paid up to the specified date.
Exercise
Before continuing, you might find it instructive to design the payroll system on your own, now. You might want to sketch some initial UML diagrams. Better yet, you might want to write the first few test-first use cases. Apply the principles and practices we’ve learned so far, and try to create a balanced and healthy design. Remember the coffee maker!
If you are going to do this, take a look at the use cases that follow. Otherwise, skip them; they’ll be presented again in Chapter 26.
Use Case 1: Add New Employee
A new employee is added by the receipt of an AddEmp transaction. This transaction contains the employee’s name, address, and assigned employee number. The transaction has three forms:
AddEmp <EmpID> "<name>" "<address>" H <hrly-rate>AddEmp <EmpID> "<name>" "<address>" S <mtly-slry>AddEmp <EmpID> "<name>" "<address>" C <mtly-slry> <comm-rate>
The employee record is created with its fields assigned appropriately.
Alternatives: An error in the transaction structure
If the transaction structure is inappropriate, it is printed out in an error message, and no action is taken.
Use Case 2: Deleting an Employee
Employees are deleted when a DelEmp transaction is received. The form of this transaction is as follows:
DelEmp <EmpID>
When this transaction is received, the appropriate employee record is deleted.
Alternative: Invalid or unknown
EmpID If the <EmpID> field is not structured correctly or does not refer to a valid employee record, the transaction is printed with an error message, and no other action is taken.
Use Case 3: Post a Time Card
On receipt of a TimeCard transaction, the system will create a time card record and associate it with the appropriate employee record:
TimeCard <empid> <date> <hours>
Alternative 1: The selected employee is not hourly
The system will print an appropriate error message and take no further action.
Alternative 2: An error in the transaction structure
The system will print an appropriate error message and take no further action.
Use Case 4: Posting a Sales Receipt
On receipt of the SalesReceipt transaction, the system will create a new sales-receipt record and associate it with the appropriate commissioned employee.
SalesReceipt <EmpID> <date> <amount>
Alternative 1: The selected employee is not commissioned
The system will print an appropriate error message and take no further action.
Alternative 2: An error in the transaction structure
The system will print an appropriate error message and take no further action.
Use Case 5: Posting a Union Service Charge
On receipt of this transaction, the system will create a service-charge record and associate it with the appropriate union member:
ServiceCharge <memberID> <amount>
Alternative: Poorly formed transaction
If the transaction is not well formed or if the <memberID> does not refer to an existing union member, the transaction is printed with an appropriate error message.
Use Case 6: Changing Employee Details
On receipt of this transaction, the system will alter one of the details of the appropriate employee record. This transaction has several possible variations:
Alternative: Transaction Errors
If the structure of the transaction is improper, <EmpID> does not refer to a real employee, <memberID> already refers to a member, print a suitable error, and take no further action.
Use Case 7: Run the Payroll for Today
On receipt of the payday transaction, the system finds all those employees who should be paid on the specified date. The system then determines how much they are owed and pays them according to their selected payment method. An audit-trail report is printed showing the action taken for each employee:
Payday <date>