The package diagram is a structural (static) UML diagram that represents the packages (or namespaces) that make up a system, as well as the relationships between these different packages.
When we are dealing with a large system, it can be interesting to break it down into several parts (called packages).
A package is therefore a grouping of different elements of a system (grouping of classes, diagrams, functions, interfaces, etc.). This helps to clarify 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, encapsulated within the package and invisible 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, the items in a package are public.
"Import" type dependency:
It corresponds to the import by a package B of all the public elements of a package A.
- will have "public" visibility in package B (and would therefore also be passed to a package C which would import package B).
- will be accessible to package B without having to explicitly use the name of package A.
The "import" type dependency is represented by a dotted arrow with the <> stereotype.
Package B imports Class1 and Class2 (not Class3 which has private type visibility). Class1 and Class2 have public type visibility in package B. Package C imports Class1, Class2, and Class4.
"Access" type dependency:
It corresponds to the access by a package B of all the public elements of a package A. These elements will have the private visibility in the package B, so they cannot be transmitted to a package C which would make an import or an access to package B (no transitivity).
The "access" type dependency is represented by a dotted arrow with the <> stereotype.
Package B has access to Class1 and Class2 (not to Class3 which has private type visibility). Class1 and Class2 have private type visibility in package B. Package C has access to Class4 (not Class1 and Class2 which have private type visibility in package B).
"Merge" type dependencies:
It corresponds to the merger of 2 packages into one. The “merge” type dependency is represented by a dotted arrow with the stereotype <>.
Package A is merged into package B (package A is not modified while package B is overwritten to accommodate the merging of the 2 packages).