Chapter 5: Packages

This chapter describes the means by which you can use the UML to group various model elements that are conceptually related .

Package Fundamentals

A package is a grouping of pieces of a model. Packages are very useful in managing models. They're also quite helpful in grouping related items, such as use cases, in order to make it easier to break up work among subteams.

A package can contain one or more kinds of model elements, each of which must have a unique name within the package. In a package, there can just be classes (see Chapter 1), classes and class diagrams (see Chapter 3), just use cases (see Chapter 4), or a number of different kinds of constructs and diagrams. The only rule is that each element of a model can belong directly to only one package. (In UML terms, a model is basically a package that contains other packages.) Note, though, that a package is a conceptual grouping; the system will probably not be built along package boundaries.

A UML package appears as a tabbed folder. There are the following three variations:

• The package name appears in the body of the folder, and the contents are hidden from view (see Figure 5-1).

  
  Figure 5-1: Package (no members shown)

• The name of the package appears within the tab, and the contents of the package are listed in the body of the folder (see Figure 5-2).

  
  Figure 5-2: Package (members shown internally)

• The package name appears in the body of the folder, and the contents are shown outside the folder (see Figure 5-3).

  
  Figure 5-3: Package (members shown externally)

A package name should be short and simple; it should convey the essence of the contents of the package.

You can also show the visibility of the elements within a package. The available options are public (+), which means that any other element can "see" the given element, and private (-), which means that only other elements within the same package can see the given element.