Component Structure and Notation

Figure 30-1 shows a possible component structure for the payroll application. We will address the appropriateness of this structure later. For now, we will confine ourselves to how such a structure is documented and used.

Figure 30-1. Possible payroll component diagram

By convention, component diagrams are drawn with the dependencies pointing downward. Components at the top are dependent. Components at the bottom are depended on.

Figure 30-1 has divided the payroll application into eight components. The PayrollApplication component contains the PayrollApplication class and the transactionSource and TextParserTransactionSource classes. The transactions component contains the complete transaction-class hierarchy. The constituents of the other components should be clear by carefully examining the diagram.

The dependencies should also be clear. The PayrollApplication component depends on the TRansactions component because the PayrollApplication class calls the transaction::Execute method. The TRansactions component depends on the PayrollDatabase component because each of the many derivatives of transaction communicates directly with the PayrollDatabase class. The other dependencies are likewise justifiable.

What criteria did we use to group these classes into components? We simply stuck the classes that look like they belonged together into the same components. As we learned in Chapter 28, this is probably not a good idea, however.

Consider what happens if we make a change to the Classifications component. This change will force a recompilation and retest of the EmployeeDatabase component, and well it should. But it will also force a recompilation and retest of the TRansactions component. Certainly, the ChangeClassificationTransaction and its three derivatives from Figure 27-13 should be recompiled and retested, but why should the others be recompiled and retested?

Technically, those other transactions don't need recompilation and retest. However, if they are part of the transactions component, and if that component is going to be rereleased to deal with the changes to the Classifications component, it could be viewed as irresponsible not to recompile and retest the component as a whole. Even if all the transactions aren't recompiled and retested, the package itself must be rereleased and redeployed, and then all its clients will require revalidation at the very least and probably recompilation as well.

The classes in the transactions component do not share the same closure. Each one is sensitive to its own particular changes. The ServiceChargeTransaction is open to changes to the ServiceCharge class, whereas the TimeCardTransaction is open to changes to the TimeCard class. In fact, as Figure 30-1 implies, some portion of the TRansactions component is dependent on nearly every other part of the software. Thus, this component suffers a high rate of release. Every time something is changed anywhere below, the TRansactions component will have to be revalidated and rereleased.

The PayrollApplication package is even more sensitive: Any change to any part of the system will affect this package, so its release rate must be enormous. You might think that this is inevitablethat as one climbs higher up the package-dependency hierarchy, the release rate must increase. Fortunately, however, this is not true, and avoiding this symptom is one of the major goals of OOD.