Chapter 30. The Payroll Case Study: Package Analysis

© Jennifer M. Kohnke

Rule of thumb: if you think something is clever and sophisticated, bewareit is probably self-indulgence.

Donald A. Norman, The Design of Everyday Things, 1990

We have done a great deal of analysis, design, and implementation of the payroll problem. However, we still have many decisions to make. For one thing, only two programmersBob and Micahhave been working on the problem. The current structure of the development environment is consistent with this. All the program files are located in a single directory. There is no higher-order structure. There are no packages, no subsystems, no releasable components other than the entire application. This will not do going forward.

We must assume that as this program grows, the number of people working on it will grow, too. In order to make it convenient for multiple developers, we are going to have to partition the source code into componentsassemblies, DLLsthat can be conveniently checked out, modified, and tested.

The payroll application currently consists of 4,382 lines of code divided into about 63 classes and 80 source files. Although this is not a huge number, it does represent an organizational burden. How should we manage these source files and divide them into independently deployable components?

Similarly, how should we divide the work of implementation so that the development can proceed smoothly without the programmers' getting in one another's way? We would like to divide the classes into groups that are convenient for individuals or teams to checkout and support.