UML Package Diagrams Overview

Package diagram is UML structure diagram which shows structure of the designed system at the
level of packages. The following elements are typically drawn in a package
diagram: package, packageable element, dependency, element import, package import, package
merge.

ackage is a namespace used to group together elements that are semantically related and might
change together. It is a general purpose mechanism to organize elements into groups to provide
better structure for system model.

Owned members of a package should all be packageable elements. If a package is removed from a
model, so are all the elements owned by the package. Package by itself is packageable element, so
any package could be also a member of other packages.

Because package is a namespace, elements of related or the same type should have unique names
within the enclosing package. Different types of elements are allowed to have the same name.

As a namespace, a package can import either individual members of other packages or all the
members of other packages. Package can also be merged with other packages.

A package is rendered as a tabbed folder - a rectangle with a small tab attached to the left side of the
top of the rectangle. If the members of the package are not shown inside the package rectangle,
then the name of the package should be placed inside.

Package org.hibernate

The members of the package may be shown within the boundaries of the package. In this case the
name of the package should be placed on the tab.

Package org.hibernate contains SessionFactory and Session

A diagram showing a package with content is allowed to show only a subset of the contained
elements according to some criterion.

Members of the package may be shown outside of the package by branching lines from the package
to the members. A plus sign (+) within a circle is drawn at the end attached to the namespace
(package). This notation for packages is semantically equivalent to composition (which is shown
using solid diamond.)
Package org.hibernate contains interfaces SessionFactory and Session.

The elements that can be referred to within a package using non-qualified names are:

 owned elements,

 imported elements, and

 elements in enclosing (outer) namespaces.

Owned and imported elements may have a visibility that determines whether they are available
outside the package.

If an element that is owned by a package has visibility, it could be only public or private visibility.
Protected or package visibility is not allowed. The visibility of a package element may be indicated by
preceding the name of the element by a visibility symbol ("+" for public and "-" for private).

All elements of Library Domain package are public except for Account

The public elements of a package are always accessible outside the package through the use
of qualified names.

Package URI Attribute

Package has optional URI attribute which serves as unique identifier of the package. This attribute
was introduced in UML 2.4 mostly to support exchange of profiles using XMI.

Note, that UML 2.4 specification requires this URI attribute to follow the rules and syntax of the IETF
URI specification RFC 2396 while the more recent version of the URI syntax RFC 3986 (released in
2005) rendered the RFC 2396 obsolete.

Both RFCs allow URIs to be uniform resource locators (URLs), uniform resource names (URNs) or
both. Though URN actually defines item's identity (unique id) and URL provides a method for finding
it, it is very common and sometimes confusing to see URLs serving as URNs.
Here's some examples of package URI attribute in the form of URL. Note, that using "http://" scheme
is often not related to HTTP protocol and no actual resource is located at that location. URL is just
used as a substitute of unique id:

 http://www.ietf.org/rfc/rfc2396.txt

 http://www.omg.org/spec/UML/20100901/PrimitiveTypes.xmi

 http://www.uml-diagrams.org/profiles/20110410/EJB-30.xmi

My personal preference is to use URNs instead, as URN was designed specifically to define identity
(unique id) and does not imply availability of the identified resource (e.g. for obsolete resources):

 urn:ietf:rfc:3986

 urn:oasis:names:specification:docbook:dtd:xml:4.1.2

 urn:schemas-microsoft-com:xml-data

 urn:uml-diagrams-org:profiles:20110410:EJB-30

The URI attribute of a package may be rendered in the form {uri=<uri>} after the package name.

EJB Profile shown as a package with URI attribute.

Package Template

Package can be used as a template for other packages. Note, that [UML 2.4.1
Specification] inconsistently calls it both package template and template package.

Packageable element can be used as a template parameter. A package template parameter may
refer to any element owned or used by the package template, or templates nested within it.

A package may be bound to one or more template packages. When several bindings are applied the
result of bindings is produced by taking the intermediate results and merging them into the
combined result using package merge.
Package template Service Provider and bound package Scheduler Service.

Packageable Element

Packageable element is a named element that may be owned directly by a package.

Some examples of packageable elements are:

 Type

 Classifier (--> Type)

 Class (--> Classifier)

 Use Case (--> Classifier)

 Component (--> Classifier)

 Package

 Constraint

 Dependency

 Event

Packageable element by itself has no notation, see specific subclasses.

Element import is a directed relationship between an importing namespace and

The name of the packageable element or its alias is to be added to the namespace of the importing
namespace. It works by reference, which means that it is not possible to add features to the element
import itself, but it is possible to modify the referenced element in the namespace from which it was
imported.

It is possible to control whether the imported element can be further imported by other namespaces
using either element or package imports. The visibility of the element import may be either the same
or more restricted than that of the imported element. The visibility of an element import is either
public or private.

The default visibility is the same as that of the imported element. If the imported element does not
have a visibility, it is possible to add visibility to the element import. Default value is public.

In case of a name clash with an outer name (an element that is defined in an enclosing namespace is
available using its unqualified name in enclosed namespaces) in the importing namespace, the outer
name is hidden by an element import, and the unqualified name refers to the imported element. The
outer name can be accessed using its qualified name.

If more than one element with the same name would be imported to a namespace as a consequence
of element imports or package imports, the elements are not added to the importing namespace
and the names of those elements must be qualified in order to be used in that namespace. If the
name of an imported element is the same as the name of an element owned by the importing
namespace, that element is not added to the importing namespace and the name of that element
must be qualified in order to be used.

Alias specifies the name that should be added to the namespace of the importing package in lieu of
the name of the imported packagable element. The aliased name must not clash with any other
member name in the importing package. By default, no alias is used.

An element import is shown using a dashed arrow with an open arrowhead from the importing
namespace to the imported element. Note, that though it looks exactly
like dependency and usage relationships, it is a completely separate directed relationship.

The keyword «import» is shown near the dashed arrow if the visibility of import is public while the
keyword «access» is used to indicate private visibility. If the imported element is not a package, the
keyword may optionally be preceded by element, i.e., «element import».
Public import of PageInfo element and private import of SortInfo element from Domain package.

Elements that become available for use in an importing package through an element import may
have a distinct color or be dimmed to indicate that they cannot be modified.

The aliased name may be shown after or below the keyword «import».

As an alternative to the dashed arrow, it is allowed to show an element import by having a text that
uniquely identifies the imported element within curly brackets either below or after the name of the
namespace. The syntax in this case could be described as (note, this is my modified version of the
syntax):

element-import ::= '{' ( 'element import' | 'element access' ) qualified-name [ 'as' alias ] '}'

UML Package Import

Package import is a directed relationship between an importing namespace and imported package,
that allows the use of unqualified names to refer to the package members from the other
namespace(s).

Importing namespace adds the names of the members of the imported package to its own
namespace. Conceptually, a package import is equivalent to having an element import to each
individual member of the imported namespace, unless there is already a separately-defined element
import.

A package import is shown using a dashed arrow with an open arrowhead from the importing
namespace to the imported package.

WebApplication imports Presentation package.

Note, that though it looks exactly like dependency and usage relationships, it is a completely
separate directed relationship.

The visibility of a package import could be either public or private. If the package import is public,
the imported elements will be added to the namespace and made visible outside the namespace,
while if it is private they will still be added to the namespace but without being visible outside.
A keyword is shown near the dashed arrow to identify which kind of package import is intended. The
predefined keywords are «import» for a public package import, and «access» for a private package
import. By default, the value of visibility is public.

Private import of Presentation package and public import of Domain package

As an alternative to the dashed arrow, it is possible to show an package import by having a text that
uniquely identifies the imported package within curly brackets either below or after the name of the
namespace. The syntax in this case could be described as (note, this is my modified version of the
syntax):

package-import ::= '{' ( 'import' | 'access' ) qualified-name '}'

Elements that become available for use in an importing package through a package import may have
a distinct color or be dimmed to indicate that they cannot be modified.

UML Package Merge

A package merge is a directed relationship between two packages that indicates that content of one
package is extended by the contents of another package.

Package merge is similar to generalization in the sense that the source element conceptually adds
the characteristics of the target element to its own characteristics resulting in an element that
combines the characteristics of both.

Package merge can be viewed as an operation that takes the contents of two packages and produces
a new package that combines the contents of the packages involved in the merge.

This mechanism should be used when elements defined in different packages have the same
name and are intended to represent the same concept. Most often it is used to provide different
definitions of a given concept for different purposes, starting from a common base definition.

A given base concept is extended in increments, with each increment defined in a separate merged
package. By selecting which increments to merge, it is possible to obtain a custom definition of a
concept for a specific end.

Package merge is particularly useful in meta-modeling and is extensively used in the definition of the
UML metamodel.

Package merge is shown using a dashed line with an open arrowhead pointing from the receiving
package to the merged package. Keyword «merge» is shown near the dashed line.
Kernel and Profile packages merge Constructs package
which imports Primitive Types.

Package Diagram

Some major elements of the package diagram are shown on the drawing below. Web Shopping,
Mobile Shopping, Phone Shopping, and Mail Shopping packages merge Shopping Cart package. The
same 4 packages use Payment package. Both Payment and Shopping Cart packages import other
packages.

UML package diagram elements - package, import, access, use, merge.