UML Weekend Crash Course™ - To Parent Directory

Session 24—Modeling the Development Environment 247
Defining the Notation for Packages and Package Diagrams
The package icon looks like a tabbed folder. Packages reference one another using the
dependency notation, a dashed arrow. Read the example in Figure 24-2 as “the Receiving
subsystem depends on, or needs help from, the Purchasing subsystem package.”
Purchasing
Receiving
Figure 24-2
Package icon and dependency notation
Package stereotypes
In Figures 24-1 and 24-2, each package icon contains a stereotype like or
. You can put almost anything you want in a package, so the package
description often requires a bit of clarification. The stereotype allows you to characterize
the contents of the package and still provide specific naming of its contents. For example,
the Receiving package is characterized as a subsystem. This prevents us from interpreting it
as the directory containing the receiving documents, or some other resources besides the
subsystem classes.
Be careful though. Stereotypes are not part of the package name, so they do not help
make it unique. Two packages at the same level called Receiving and
Receiving would be in conflict and probably would not be allowed by most
modeling tools. On the other hand, if the packages themselves are contained within other
packages, then they are qualified by their containers, making them unique. However, you
need to check how your modeling tool implements these rules.
Package dependency
Figure 24-2 also shows a dashed dependency arrow from Receiving to Purchasing. The
dependency relationship means that at least one class in a package has to communicate
with at least one class in the other package. The dependency in Figure 24-2 could mean
that the Receipt class in the Receiving package (Receiving :: Receipt) needs to be able to
get the details of the PurchaseOrder class in the Purchasing package (Purchasing ::
PurchaseOrder) in order to validate incoming products.
It is entirely valid for a dependency to run both directions, indicated by an arrowhead on
both ends of the dashed line. Figure 24-3 shows an example where Shipping might need to
update an Order in the Order Processing subsystem. But Order Processing might also need to
check the status of a Shipment containing the Products on an Order.