Packages

Packages provide a general mechanism for partitioning models and grouping model elements. Each package is represented graphically by a folder.

Packages divide and organize models in much the same way that directories organize file systems. Each package corresponds to a subset of a model and contains, depending on the model, classes, objects, relationships, components, or nodes, as well as their associated diagrams. (Nodes are discussed towards the end of this chapter.)

Decomposition into packages is not the basis for a functional decomposition; each package is a grouping of elements according to purely logical criteria. The general system layout (the system architecture) is expressed by the hierarchy of packages and by the network of dependency relationships between packages.

The stereotypes «category» and «subsystem» allow distinguishing between packages of the logical view and packages of the implementation view as required. (These views are described in chapter 4.)

A package defines a namespace, so that two distinct elements contained in two distinct packages may have the same name. A package may contain other packages, with no limitation on nesting levels. A given level may contain a mixture of packages and other model elements, in the same way as a directory may contain other directories and files.

Every element belongs to a package. The package located at the highest level is the root package of the whole model. A class contained within one package may also appear in another package in the form of an imported element, by means of an inter-package dependency relationship.

Imports between packages are represented within class diagrams, use case diagrams and component diagrams, using a stereotyped dependency relationship drawn from the client package to the supplier package.

A dependency relationship between two packages means that at least one class in the client package uses the services offered by at least one class in the supplier package. The classes contained within a package are not all necessarily visible outside the package.

The operator

::

allows the specification of a class defined in a context other than the current context. The expression Zoo::Kangaroo
, for example, refers to the Kangaroo
class as defined in the Zoo
package.

A package is a group of model elements, but it is also an encapsulation of these elements. Just like classes, packages have an interface and an implementation. Each element contained within a package has a parameter that indicates whether the element may be seen outside the package. The possible values of that parameter are

public

or implementation
(private).

In the case of classes, only those marked as public appear in the interface of the package that contains them; they may then be used by class members of client packages. Implementation classes are only usable within the package that contains them.

Dependencies between packages result in obsolete relationships between model elements contained within these packages. For reasons that pertain to compilation at the implementation stage, it is strongly recommended to make sure that cross-package dependencies result only in acyclic graphs. The following situation must therefore be avoided:

Similarly, circular, transitive dependencies, like the one illustrated below, should be avoided:

As a general rule, circular dependencies may be reduced by splitting one of the questionable packages into two smaller packages, or by introducing a third, intermediate package.

Some packages are used by all other packages and group, for example, basic classes like sets, lists, files, or error management classes. These packages have a property that identifies them as global packages. It is therefore not necessary to show the dependency relationships between them and their users, limiting the graphical load on the diagram.

In order to reduce graphical load, dependencies related to packages that are visible globally are not represented in diagrams.