The package diagram is a structural (static) diagram of UML that represents the packages (or namespaces) that make up a system, as well as the relationships that bind these different packages.
When we are in the presence of a large system, it can be interesting to break it down into several parts (called package).
A package is a set of different elements of a system (classes, diagrams, functions, interfaces …). This clarifies the model by organizing it. He is represented by a folder with his name inside.
Packages can nest (hierarchical decomposition) but not overlap. A system element can only belong to one and only one package. Each package must have a different name.
It is possible to represent the elements of the system belonging to the package: inside it or outside connected by a cross arrow.
Each element of a package is either:
- private, that is to say encapsulated in the package and invisible on the outside of it. A private element is designated by a sign – in front of it.
- public, that is visible and accessible from outside the package. A public element is designated by a sign + in front of it. By default.
It corresponds to the import by a package B of all the public elements of an A package.
- will have « public » visibility in package B (and thus also be passed to a C package that would import package B).
- will be accessible to package B without explicitly using the name of package A.
The « import » dependency is represented by a dotted arrow with the <> stereotype.
Package B imports Class1 and Class2 (not Class3 which has private visibility). Class1 and Class2 have public-type visibility in package B. Package C imports Class1, Class2, and Class4.
It corresponds to the access by a package B of all the public elements of an A package. These elements will have the private visibility in the B package, so they can not be transmitted to a C package that would import or access to package B (no transitivity).
The « access » dependency is represented by a dotted arrow with the <> stereotype.
Package B has access to Class1 and Class2 (not to Class3 which has private visibility). Class1 and Class2 have private visibility in package B. Package C has access to Class4 (not Class1 and Class2 that have private type visibility in Package B).
It is the fusion of 2 packages into one. The « merge » dependency is represented by a dashed arrow with the <> stereotype.
The package A is merged into the package B (the package A is not changed while the package B is crushed to accommodate the fusion of two packages).