UML 2 Package Diagramming Guidelines

Elements of UML 2.0 Style

A package diagram is a UML diagram composed only of packages and the dependencies between them. A package is a UML construct that enables you to organize model elements, such as use cases or classes, into groups. Packages are depicted as file folders and can be applied on any UML diagram. Create a package diagram to:

There are guidelines for:

  1. Class Package Diagrams
  2. Use Case Package Diagrams
  3. Packages

1. Class Package Diagrams

Figure 1. A class package diagram.


  1. Create UML Component Diagrams to Physically Organize Your Design.
  2. Place Subpackages Below Parent Packages.
  3. Vertically Layer Class Package Diagrams.
  4. Create Class Package Diagrams to Logically Organize Your Design. Figure 1 depicts a UML Class diagram organized into packages. In addition to the package guidelines presented below, apply the following heuristics to organize UML Class diagrams into package diagrams:
  • Place the classes of a framework in the same package.
  • Classes in the same inheritance hierarchy typically belong in the same package.
  • Classes related to one another via aggregation or composition often belong in the same package.
  • Classes that collaborate with each other a lot, information that is reflected by your UML Sequence diagrams and UML Collaboration diagrams, often belong in the same package.

2. Use Case Package Diagrams

Use cases are often a primary requirement artifact in object-oriented development methodologies, this is particularly true of instantiations of the Unified Process, and for larger projects package diagrams are often created to organize these usage requirements.

Figure 2. A UML Use Case diagram comprised mostly of packages.


  1. Create Use Case Package Diagrams to Organize Your Requirements
  2. Include Actors on Use Case Package Diagrams
  3. Horizontally Arrange Use Case Package Diagrams

3. Packages

The advice presented in this section is applicable to the application of packages on any UML diagram, not just package diagrams.

  1. Give Packages Simple, Descriptive Names
  2. Apply Packages to Simplify Diagrams
  3. Packages Should be Cohesive
  4. Indicate Architectural Layers With Stereotypes on Packages
  5. Avoid Cyclic Dependencies Between Packages
  6. Package Dependencies Should Reflect Internal Relationships