Page 815 - Introduction to Programming with Java: A Problem Solving Approach

Apago PDF Enhancer
of an interface. The arrowheads point in the direction of generalization—toward the more general entity. The more specific entities know about the more general entities and depend on them. Because of this depen- dency, changes to ancestor classes or interfaces can force changes to descendant or implementing classes. On the other hand, since an ancestral class or interface does not know about its descendants, changes in descendants or implementations never force changes in ancestors or interfaces. Inheritance is automatically a unidirectional association.
Appendix 7 UML Diagrams 781
Commission
SalariedAndCommissioned
Employee2
Salaried2 Hourly2
Payroll3
Commissioned
Figure A7.3 First-cut UML class diagram for Payroll3 program in Section 13.9
association lines by adding special symbols that describe particular types of relationships. In addition, you might add barbed arrowheads to convert associations from bi-directional to unidirectional and make depen- dencies go just one way. Unidirectional dependencies are preferable to bi-directional dependencies because they simplify software management—software changes to one class are less likely to require changes to other classes.
Figure A7.4 contains a fleshed-out and modified version of the first-cut UML class diagram in Figure A7.3. Notice that we italicize the Commission and Employee2 class names. That means they have at least one abstract method and cannot be instantiated. We also italicize all the abstract meth- ods they contain. Next, look at the hollow arrowheads, which indicate inheritance. Inheritance arrowheads on solid lines indicate extension of a class. Inheritance arrowheads on dashed lines indicate implementation
2
Nowlookatthecompositionindicators. Wechosetoshowthemas(soliddiamond)compositionsrather
than (hollow diamond) aggregations because the class that instantiates the components (Payroll3) in- serts anonymous components into its containing array. All the composition lines have multiplicities. These indicate that there is always exactly one payroll and there could be any number of employees of any of the four types. Since Hourly2, Salaried2, Commissioned, and SalariedAndCommissioned all descend from the Employee2 class, we can put instances of all four of these classes into a common Employees2 array, as we do in the Payroll3 class definition in Figure 13.17.
Finally, look at the barbed arrowheads we have added to the composition association lines. As we said, all association lines are bidirectional by default, and one design objective is to convert bidirectional associa- tions into unidirectional associations. The barbed arrowheads on the non-diamond ends of the four compo- sition lines do that. They say the composition’s components have no knowledge of their container. That’s appropriate in this case, because this container is just a driver, and many drivers are ephemeral—here today and gone tomorrow.
Figure A7.4 also includes a dashed association line with a barbed arrow that points to the abstract class, Employee2. This acknowledges that the local variable called employees “depends on” the Employee2 class because the type of its elements is Employees2. The barbed arrow at the Employees2
2 Notice how the association line between Payroll3 and Commissioned arcs over the association line between SalariedAndCommissioned and Salaried2. This UML detail helps distinguish a cross-over from a junction.