UML: What is Package Diagram? How to use it?

A package is a grouping of model elements which means that a package can contain model elements of different kinds, including other packages to create hierarchies. A package defines a namespace for its contents using for various purposes.

Package Diagram at a Glance

Package diagram is used to simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements.

The diagram below is a business model in which the classes are grouped into packages:

• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.
• One package depends on another if changes in the other could possibly force changes in the first.

Basic Concepts of Package Diagram

Package diagram follows hierarchal structure of nested packages. Atomic module for nested package are usually class diagrams. There are few constraints while using package diagrams, they are as follows.

• Package name should not be the same for a system, however classes inside different packages could have the same name.
• Packages can include whole diagrams, name of components alone or no components at all.
• Fully qualified name of a package has the following syntax.

Packages can be represented by the notations with some examples shown below:

Package Diagram — Dependency Notation

There are two sub-types involved in dependency. They are <<import>> & <<access>>. Though there are two stereotypes users can use their own stereotype to represent the type of dependency between two packages.

Key Elements of Package Diagram

Packages are used to organize a large set of model elements:

• Visibility
• Import
• Access

When to Use Packages?

To create an overview of a large set of model elements

• To organize a large model
• To group related elements
• To separate namespaces

Visibility of Packages

Each contained element has a visibility relative to the containing package.

• A public element is visible to elements outside the package, denoted by ‘+’
• A protected element is visible only to elements within inheriting packages, denoted by ‘#’
• A private element is not visible at all to elements outside the package, denoted by ‘-’
• Same syntax for visibility of attributes and operations in classes

Import Relationship between Packages

The associations are owned by package X:

Import and Access

Inheritance

A package with a generalization to another package inherits public and protected elements that are owned or imported by the inherited package. Packages are shown in static diagrams two equivalent ways to show containment:

Subsystems

Subsystems are used for system decomposition that can be represented by the parts of a system: (Specification / Realization)

Subsystem Internal and External Aspects

A subsystem has a specification and a realization to represent the two views:

• An external view, showing the services provided by the subsystem
• An internal view, showing the realization of the subsystem
• There is a mapping between the two aspects

Modeling Tips of Subsystem

• Define a subsystem for each separate part of a large system
• Choose specification technique depending on factors like kind of system and kind of subsystem
• Realize each subsystem independently, using the specification as a requirements specification

Modeling Complex Grouping

A package diagram is often used to describe the hierarchical relationships (groupings) between packages and other packages or objects. A package represents a namespace.

Package Diagram Example — Layering Structure