Package Diagram

Purpose

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).

Example

Here is an example Package Diagram.

Description

Package Diagrams (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.

• Logical View , encapsulated in a package called model
• Component View , encapsulated in a package called components
• Process View , encapsulated in a package called processes
• Deployment View , encapsulated in a package called processors

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:

• A lower-level PD to define the level of detail in the corresponding part of a UML model
• A lower-level CD to define the set of classes in that package within the model view of an OO system that describes its static structure
• A lower-level CPD to define the set of implementation build components for the components view, or the set of executable units in the processes model
• A lower-level DPD to define the set of processors used to execute the OO system in the processors view

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 Model modelling domain, but only in the Cradle Implementation Model modelling domain.

Within the Essential Model, therefore, packages in any UML model can only expand into either a PD or CD, whilst in the Implementation Model, packages can be expanded into a PD, a CD, a CPD or a DPD.

Each package is defined in a Process Specification (PSpec) 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 PSpec definition are both named and numbered from the name of the global package.

Characteristics

Linkage

Symbols