Package diagram

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.

Dependencies

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.

These elements:

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