Package Diagram

Package Diagram
“Package diagram is a UML structure diagram which shows packages and
dependencies between the packages.”

Contents of a Package Diagram

1. Package Groups common elements based on data, behavior, or user

interaction
2. Dependency Depicts the relationship between one element (package, named
element, etc) and another

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.
 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.
Package Diagram
 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 Diagram
Packageable Element:

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.
Class, Interface, Use case and Component are some of the examples of packageable
elements.
Package by itself is packageable element, so any package could be also a member of
other packages.

Visibility:

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

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).
Package Diagram
Import and Access: 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.
Package Diagram
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.
Essentially, the contents of two packages are combined to produce a new package.
Package Diagram
Common Uses:
Modeling Groups of Elements
The most common purpose for which you'll use packages is to organize modeling
elements into groups that you can name and manipulate as a set.
If you are developing a trivial application, you won't need packages at all. All your
abstractions will fit nicely into one package. For every other system, however, you'll
find that many of your system's classes, interfaces, components, and nodes tend to
naturally fall into groups. You model these groups as packages.
Package Diagram
Common Uses:
Modeling Architectural Views
Packages can be used to model the different views of software systems architecture
where view is a projection into the organization and structure of a system, focused
on a particular aspect of that system. We can decompose a system into almost
orthogonal packages, each of which addresses a set of architecturally significant
decisions.