UML Package Diagrams Notation

Package diagram is UML structure diagram which shows packages and dependencies between the packages.

Model diagrams allow to show different views of a system, for example, as multi-layered (aka multi-tiered) application - multi-layered application model.

The following nodes and edges are typically drawn in a package diagram: package, packageable element, dependency, element import, package import, package merge.

Package

Package 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 shown as a rectangle with a small tab.

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 members shown within the package rectangle.

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

Members of package shown outside the package.

Package org.hibernate contains interfaces SessionFactory and Session.

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

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

Visibility of a package element may be public or 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:

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

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

URI attribute of a package rendered 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.

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:

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

Element Import

Element import is a directed relationship between an importing namespace and imported packageable element. It allows the element to be referenced using its name without a qualifier. An element import is used to selectively import individual elements without relying on a package import.

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 element import shown using a import keyword, private - using access keyword.

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 ] '}'

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.

Package import 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.

Public package import shown using a import keyword, private - using access keyword

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.

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.

Package merge shown as dashed line with an open arrowhead from receiving package to merged package.

UML Kernel package merges Constructs package
which imports Primitive Types.

Next  Model

Comments
blog comments powered by Disqus