Package Diagram is a structured diagram from UML that illustrates dependencies between packages. A package is the primary representation of many different model elements (classes, SW components, SW Units, ect). Due to its abstract and high level interpretation, packages can be used to partition use cases or define groups of SW Components deliveries.

Package-Diag-1

A package is notated by a rectangle with a tab on the top left as the following image shows:

The notation of the package is as follows:

(+) means that the package is public.

(-) means that the package is private.

The dotted arrow with an open arrowhead means “dependency”. The tail is located to the element having the dependency, and the head is located to the element that supports that dependency.

The arrows in Figure 1 can be labeled “<<>>” to highlight the type of dependency between the packages. <<import>>, <<access>> and <<merge>> are dependency types used in package diagrams.

The dependency types disclosure as follow:

  1. Import: Permission of a package to access the content of the other package and add aliases to their names based on the importer. It can be defined as “public” import, since nothing else refers to public items in the package to be imported.
  2. Access: Permission of one package to access the content of the other package. It is better defined as “private” import because it accesses private elements of the package to be accessed. 
  3. Merge: Permission of one package to mix the content of the other package into itself.

Package partitions can organize systems by architecture layers. This is useful for further diagramas of use cases and subsystem specifications. When you pass from package diagrams to  use case diagrams, do not break the dependency relationships.

Good package designs are identified when there are more interactions within the package than between external packages.