Package diagram

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.

Dependancies

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.

Import dependency:

It corresponds to the import by a package B of all the public elements of an A package.

Those elements:

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

Access dependancy:

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

Merge dependency:

It is the fusion of 2 packages into one. The « merge » dependency is represented by a dashed arrow with the <> stereotype.

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

 

Publicités