13.5. Applying UML: Package Diagrams
UML package diagrams are often used to illustrate the logical architecture of a systemthe layers, subsystems, packages (in the Java sense), etc. A layer can be modeled as a UML package; for example, the UI layer modeled as a package named UI.A UML package diagram provides a way to group elements. A UML package can group anything: classes, other packages, use cases, and so on. Nesting packages is very common. A UML package is a more general concept than simply a Java package or .NET namespace, though a UML package can represent thoseand more.The package name may be placed on the tab if the package shows inner members, or on the main folder, if not.It is common to want to show dependency (a coupling) between packages so that developers can see the large-scale coupling in the system. The UML dependency line is used for this, a dashed arrowed line with the arrow pointing towards the depended-on package.A UML package represents a namespace so that, for example, a Date class may be defined in two packages. If you need to provide fully-qualified names , the UML notation is, for example, java::util::Date in the case that there was an outer package named "java" with a nested package named "util" with a Date class.The UML provides alternate notations to illustrate outer and inner nested packages. Sometimes it is awkward to draw an outer package box around inner packages. Alternatives are shown in Figure 13.3.
Figure 13.3. Alternate UML approaches to show package nesting, using embedded packages, UML fully-qualified names, and the circle-cross symbol.
[View full size image]
UML Tools: Reverse-engineer Package Diagrams from Code
During early development, we may sketch a UML package diagram and then organize our code according to these package sketches. Over time, the code base grows and we spend more time programming and less on modeling or UML diagrams. At that point, a great use for a UML CASE tool is to reverse-engineer the source code and generate a package diagram automatically.This practice is enhanced if we use the naming conventions on p. 204 suggested for code packages.