Package Diagram
A package is a logical collection of model elements of any type that is used to divide the overall model into smaller, manageable units.
A package defines a namespace, i.e. the names of the elements contained within a package must be unique. Each model element can be referenced in other packages, but only belongs to a maximum of one (home) package. Packages can contain different model elements, for example classes and use cases. They can be organised hierarchically, i.e. in turn contain packages.
Fig. 52: Sample Package Diagram
A model element, for example a class, can be used in various packages, but each class has its own root package. In all other packages, it is only recognised by its qualified name
Package name::Class name
is quoted. This creates dependencies between the packages, i.e. one package uses classes from another package.
A package is displayed in the form of a file register. The name of the package is displayed within this symbol. If model elements are displayed within the symbol, the name is shown on the tab, otherwise within the large rectangle. Stereotypes can be noted above the package name.
If you want to divide the work between several groups of developers, you can use the subdivision into packages and give each group such a package to work on. An interface is agreed so that the packages can be merged later without any problems. Initially, only the name of the interface is required.
The functions contained in the package can be called via the interface. In this way, the package can be tested accordingly and subsequent co-operation with other packages can be guaranteed. Guaranteed in this context means that the functions implemented in the package return exactly the defined result values when called with possible input values.
The interaction of the system’s packages is shown in a package diagram, in which the internal structure of a package is also modelled.
| Name/Element | Usage |
|---|---|
 | The package symbol is modelled on an index card. The package name is displayed within this symbol. If you want to model the communications of the sub-packages within the package, you can move the package name to the rectangle above. |
 | The communication between the packages is represented by an arrow that runs along a broken line. The arrow starts from the package from which most of the communication originates. |
 | If a package inherits from another, the symbol is used for generalisation. An arrow is used to connect the participating packages, with the arrowhead pointing to the package from which it is inherited. |
 | You can use this symbol to model the package structure from the parent package. To do this, the ‘Contains’ symbol is drawn on the package symbol of the parent package. The subordinate packages are connected to this symbol by solid lines. |
