UML-Paketdiagramme

Ein Paketdiagramm ist das Inhaltsverzeichnis eines Modells plus eine Regel darüber, wer wen referenzieren darf. Die Form des Reiterordners ist ein Namensraum: eine Gruppe von Klassen, Anwendungsfällen, Komponenten oder weiteren Paketen.

Die Gruppierung allein ist mäßig nützlich. Der Wert steckt in den Pfeilen. Eine Abhängigkeit von ui nach domain sagt, dass die UI-Schicht Domänentypen referenzieren darf. Das Fehlen eines Pfeils in die andere Richtung sagt, dass die Domäne nicht wissen darf, dass die UI existiert - und das ist eine Architekturregel, die Sie testen, linten und einen Build daran scheitern lassen können.

In der Praxis trägt der schlichte Abhängigkeitspfeil die meisten Paketdiagramme, und die Unterscheidung zwischen «import» und «access» verdient ihren Platz erst, wenn Sie eine Sprache oder ein Framework modellieren, dessen Modulsystem den Unterschied real macht.

Alles Interessante an einem Paketdiagramm steckt in der Richtung der Pfeile, und man sucht nach zwei Dingen.

Zyklen. Können Sie bei einem Paket beginnen, Pfeilen folgen und wieder dort landen, wo Sie angefangen haben, lassen sich diese Pakete nicht unabhängig bauen, testen, verstehen oder deployen. Sie sind ein Paket, das vorgibt, mehrere zu sein. Ein Paketdiagramm macht einen Zyklus in etwa zwei Sekunden sichtbar, was ohne Werkzeug der schnellste Weg ist, einen zu finden.

Stabilität. Abhängigkeiten sollten auf Dinge zeigen, die sich seltener ändern. Im Diagramm oben zeigen ui und infrastructure beide auf domain, und alle drei auf shared. Das ist die Form einer Schichtenarchitektur: Flüchtiges hängt von Stabilem ab, nie umgekehrt. Ein Pfeil von domain nach ui wäre das Wichtigste auf der Seite.

So erkennt man auch ein shared- oder common-Paket, das aus dem Ruder läuft. Eines, auf das alles zeigt, ist in Ordnung, solange es selbst auf nichts zeigt. In dem Moment, in dem es einen ausgehenden Pfeil bekommt, hängt jedes Paket im System transitiv von diesem Ziel ab.

Paketdiagramme funktionieren auf zwei Höhen gut und dazwischen schlecht: das ganze System bei fünf bis neun Paketen, oder ein Teilsystem in ähnlicher Körnung. Ein Diagramm mit vierzig Paketen ist ein Abhängigkeitsgraph, und einen Abhängigkeitsgraphen liest ein Werkzeug besser als ein Mensch.