A Package Diagram (PD) shows a grouping of elements in the OO model, and is a Cradle extension to UML. PDs can be used to show groups of classes in Class Diagrams (CDs), groups of components or processes in Component Diagrams (CPDs), or groups of processors in Deployment Diagrams (DPDs).
PDs are the only diagram type that can contain packages. While UML contains packages, and refers to diagrams that contain only packages as PDs, they are not identified as an explicit diagram type in UML. PDs have been introduced to prevent the ambiguity that could otherwise occur if users mixed packages and classes, or packages and components, or packages and processors in the same CD, CPD, or DPD respectively.
PDs exist to create an overall structure to a UML model. Specifically they exist to implement the 4+1 view. An example of this is shown below.
The top-level diagram in an OO model is a UCD that begins with the Use Case View. It identifies the system, its actors, and the use cases by which actors interact with the system. A hierarchy of these UCDs may be created, to allow full exposition of detailed or complex use cases. Use cases may also be shared between UCDs and between UML models. Lower level UCDs are also used to define the set of scenarios in a use case. Each of the scenarios may be described in a Sequence Diagram (SQD) or a Collaboration Diagram (COD) or both.
The set of SQDs and CODs identify classes, or objects within classes. Each class appears on one or more CDs and may be reached directly from the SQDs and CODs.
The system in the top-level UCD is decomposed into a top-level PD containing four packages: one for each of the views in the UML 4+1 view of a system.
All these packages are automatically generated when the top-level PD is first accessed. Any package may be decomposed into one or more other packages shown on a lower-level PD. The model will consequently contain a hierarchy of PDs, in four subtrees, all rooted under the top-level PD. This PD is for navigation purposes only.
In the model PD subtree, a level is reached where packages expand to CDs that contain the definitions of one or more classes. This subtree essentially defines the static structure of the UML model. The classes on this CD may appear on other CDs, but such appearances will identify the class as being part of another package.
Each class may be augmented by an SCD that shows the internal, dynamic, behaviour of the class. Each of a class’s operations may be detailed in its own ACD. The SCD and/or ACDs for a class will be reachable from any instance of the class on any CD.
In the components PD subtree, a level is reached where packages expand to CPDs that describe the dependencies between compilation units and the mapping between classes and compilation units.
In the processes PD subtree, a level is reached where packages expand to CPDs that describe dependencies between processes (individual executable units that can be scheduled for execution by a processor) and components in the Component View.
In the processors PD subtree, a level is reached where packages expand to DPDs that detail the processor(s) within the system, the links between them, and the mapping between processes and these processors. It is not expected that there will, in practice, be any PDs in the Deployment View, and that this view will simply contain a single DPD. More complex model structures are, nonetheless, supported.
A package may therefore be decomposed into any of:
However, as the components, processes and processors views are concerned with system model, they are not available within UML models developed in the Cradle Essential Domain, only in the Cradle Implementation Domain.
Within the Essential Domain, therefore, packages in any UML model can only expand into either a PD or CD, whilst in the Implementation Domain, packages can be expanded into a PD, a CD, a CPD or a DPD.
Each package is defined in a package specification that should be used to describe design goals or implementation-specific details for the associated package, especially its testability and acceptance criteria.
To allow packages to be shared within a UML model, and between multiple UML models in a modelling domain, global packages can be used. These share the same characteristics as shared use cases in that their PD expansion and package specification definition are both named and numbered from the name of the global package.
PDs are hierarchical. Their connectivity is:
PDs are available in models in both the Essential and Implementation Domains.
Numbering of PDsThe overall PD hierarchy is a dotted-decimal numbered set of diagrams and package specifications with the same numbers, where the root (start) of all such numbers is the name of the system in the topmost UCD from which all PDs are ultimately descended.
SymbolsAn example PD is:
The symbols available in PDs are:
| Symbol | Name | Description | Definition | Expansion |
|---|---|---|---|---|
 | Comment | Makes a note anywhere in the diagram. Are always surrounded by * characters. Note: If you do not want Cradle to automatically add an * go to the Graphics Settings section of Project Setup and turn off the Automatically add asterisks to diagram's comment symbols option. | None | None |
 | System Package | A connection of elements in a UML model, part of one of the four alternate views of a system shown in a UML model. | Package specification | PD CD CPD DPD |
 | Global Package | A collection of elements that is outside the strict scope of the system but contains functionality or behaviour that is used in the system, normally specifically in its implementation (such as windowing system or I/O driver packages). | Package specification | PD |
 | Picture | Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol. | None | None |
 | Package Dependency | Relationships between packages that indicate which packages a particular package is dependent upon for it to be able to exhibit its specified behaviour. | None | None |
 | Item | Represents a requirement or system note in the diagram. | None | None |
 | Context Item | Represents a requirement or system note in a diagram and is a container within which other object symbols can be drawn or attached. | None | None |
 | Cross Reference Link | Represents a cross reference that exists between a pair of system notes/requirements. It can also represent a cross reference between a system note/requirement and a specification or data definition or system that describes the objects symbols that it connects. | None | None |