14.4 PACKAGE DIAGRAM

14.4 PACKAGE DIAGRAM

When the number of classes becomes large, it is best to organize the classes into packages on the basis of some useful criterion. The word "package" in UML means the same thing as it does in Java.

If you have organized your classes into packages, you may want to draw a package diagram to show the dependencies between packages. One package depends on another package if any class in the former depends on any class in the latter. Such interpackage dependencies come into existence any time a class in one package has either an IsA or a HasA relationship with a class in another package.

A package is denoted by a rectangular box with a "tab" at the left end of its top. The name of a package appears in the middle of the box. But sometimes it is desirable to list the names of the more prominent classes in the package or some other package-specific information inside the box. In that event, the name of the package is placed inside the tab. Both the tab and the main box are allowed to also list inside pairs of braces any additional information that characterizes a package. For example, if a package consists solely of interfaces in Java, it could be called an abstract package and the word "abstract" placed inside braces beside the name of the package.

If a package A is dependent on package B, in the package diagram that is shown by an arrow going from A to B. For example, if you extend one of Java' Swing classes to create a user interface in a package named UI, you'd show the resulting dependency by the package diagram of Figure 14.14. Package dependencies are shown by dashed lines with solid arrowheads. If all other packages in a system are dependent on one common package-because it contains some of the more basic types used by the other packages-instead of drawing arrows, you can simply place the characterization {global} beside the package name in a package diagram.

Figure 14.14

Continuing with the above example, let' say that there is another more application-oriented package, ProcessOrder, that depends on the UI package as shown in Figure 14.15. The important thing to bear in mind here is that the chained dependencies in a package diagram are not transitive. Meaning that while the UI package depends on the Swing package, and the ProcessOrder package depends on the UI package, the ProcessOrder packagedoes not automatically become dependent on the Swing package. This corresponds to the property of the import command in Java programs. But it does not correspond to the #include compiler directive in C++. In C++ if A includes B and B includes C, thenA will include C. So we can say that the interpackage dependencies in Java, as given rise to by the import command, correspond exactly tothe semantics of the the arrow in the package diagrams of UML. On the other hand, the interpackage dependencies given rise to by #include in C++ do not correspond strictly to the meaning of the arrow in a UML package diagram.

Figure 14.15

The nontransitivity of interpackage dependency makes software maintenance easier. In the above example, this means that any changes to the Swing package would have no direct influence on the ProcessOrder package. So if the Swing package is changed, we would need to look at only the UI package to see if anything there would need to be changed. (Of course, if we make any changes to the UI package, we would then need to also look at the ProcessOrder package for possible changes.) On the other hand, with a transitive dependency, especially after our memory of how the program was implemented had faded, we would be less sure that a data type of Swing was not used directly in the ProcessOrder package.