Systemarchitektur und Cohesion

Um was geht es hier?

In diesem Beitrag möchte ich kurz eine Entwurfsrichtlinie mit dem Namen ‚Bindung‘ (Cohesion) vorstellen.

Hintergrund hierbei ist folgende Frage?

Worauf muss ich bei der Erstellung einer System-Architektur achten, damit die angestrebte Lösung die Eigenschaften besitzt, wie:

  • Wartbarkeit
  • Änderbarkeit
  • Verständlichkeit
  • Austauschbarkeit

Die Antwort hierauf lautet:

„Achte auf den Grad der Bindung zwischen den Elementen die zu einer Komponente gehören!“

Was hierunter zu verstehen ist und auf was man in der Praxis achten muss, möchte ich nachfolgend kurz vorstellen.

Was bedeutet Bindung?

Bindung ist ein Maß, wie eng die Elemente zusammenhängen, die zu einer Komponente gehören.

Cohesion-Intro
Figure:Bindung

Somit beschreibt die Bindung den Grad der Zusammengehörigkeit der Elemente einer Komponente.

Es ist anzustreben, dass die Bindung möglichst hoch ist (im Sinne von starker Bindung). Alle Elemente sollen zu der Lösung einer Aufgabe bzw. der Verantwortlichkeit einer Komponente Beitragen.

Warum soll die Bindung stark sein?

Besitzen alle Elemente einer Komponente eine starke Bindung, dann ist die Komponente:

  • Einfacher auszutauschen
  • Einfacher wiederzuverwenden
  • Einfacher zu testen
  • Einfacher zu verstehen
  • Einfacher zu ändern

Stellt sich nun die Frage:
Wie erkenne ich den Grad der Bindung der einzelnen Elementen?

Wie erkenne ich den Grad der Bindung einer Komponente?

Um den Grad der Bindung zu erkennen stellt sich zunächst die Frage:

Frage 1: Hat die Komponente genau eine Verantwortlichkeit/Aufgabe?

Ob eine Komponente genau eine Verantwortlichkeit hat kann man an dem Namen der Komponente erkennen.

Besteht der Name einer Komponente aus einem Substantiv, welches die Verantwortlichkeit exakt beschreibt, dann ist dies ein Indiz dafür, dass der Grad der Bindung zwischen den Elementen hoch ist.
Positiv Beispiele:
* DeviceListe
* Zugangskontrolle

Negativ Beispiel:
* SearchAndVerifyUpdateBook

Frage 2: In wie weit tragen alle Elemente einer Komponente zur Erbringung der Verantwortlichkeit bei?

Die nachfolgende Abbildung visualisiert, wie man sich eine hohe Bindung vorstellen kann

Cohesion-Hohe Bindung
Figure: Hohe Bindung

Bei einer hohen Bindung gibt es einen guten Grund, warum die Elemente innerhalb dieser Komponente zu finden sind.

Im Gegensatz hierzu zeigt die nachfolgende Abbildung eine Visualisierung, wie man sich eine geringe Bindung vorstellen kann.

Cohesion-Niedrige Bindung
Figure: Geringe Bindung

Eine geringe Bindung der Elemente einer Komponente zeigt sich unter anderem an dem Namen einer Komponente. Allgemeine Namen wie „Utilities“ oder „Control“ deuten darauf hin, dass die Element wenig oder nichts miteinander zu tun haben.

Um den Grad der Bindung besser versehen zu können, schauen sind nachfolgend einige Beispiele aufgeführt.

Bindung am Namen erkennen

In der nachfolgende Abbildung sind 3 Java Klassen mit ihren Methoden aufgeführt.
An den Namen der Methoden kann man erkennen, dass der Grund, warum die Methoden in dieser Klasse angesiedelt sind, auf der Funktion READ oder WRITE basiert. Dies ist ein schwacher Grund. Änderungen in einer Methode zieht sehr wahrscheinlich Änderungen in einer anderen Klasse nach sich. Ein Kapseln nach Datenstrukturen würde hier das Design verbessern.

Cohesion-Java-Sample
Figure: Java Beispiel- geringe Bindung

Dieses einfache Beispiel zeigt, dass sich die Bindung der Methoden einer Klassen an dem Namen erkennen lassen.

Bindung an der Beziehung erkennen

Die Art der Beziehung, warum einzelne Elemente zusammen gefasst werden, liefert ein Aussage, über den Grad der Bindung.
Hierbei spielt es keine Rolle, von welcher Art die Elemente sind.
Bei den Elementen kann es sich um:

  • Anweisungen in einer Funktion oder Methode handeln
  • Methoden, die in einer Klasse angesiedelt sind
  • Klassen, die in einem Package zu finden sind
  • Funktionen, die in einer Library (.a,.so,*.dll) zu finden sind
  • Komponenten, die gemeinsam installiert werden
  • Komponenten die Zusammen einen Dienst erbringen

In der nachfolgenden Tabelle habe ich die wichtigsten Gründe aufgeführt und den Grad der Bindung klassifiziert.

Grund Grad der Bindung
Alle Elemente tragen zur Lösung einer Funktionalen Anforderung bei sehr hohe Bindung
Die Element müssen in einer vorgegebenen Reihenfolge ausgeführt werden, die sich aus der Aufgabenstellung heraus ergibt hohe Bindung
Die Element müssen immer in dieser Reihenfolgen ausgeführt werden, aufgrund des gewählten Designs schwache Bindung
Es gibt einen besonderen Grund. Die Elemente müssen irgendwo abgelegt werden sehr schwache Bindung

In der Praxis wird man aber selten eine klare Abgrenzung finden. Oft findet man ein Mischform vor und mehrere Gründe treffen zu.

Zur Vertiefung

Zur Vertiefung möchte ich das Buch

Meilir Pages Johns, Structured Design

In diesem Buch wir sehr gut und ausführlich auf Coupling und Cohesion eingegangen. Die vielen Beispielen aus der Praxis, helfen das Wissen über Kopplung (Coupling) und Bindung (Cohesion) zu vertiefen.

Katgeorie:Methodik | Kommentare deaktiviert für Systemarchitektur und Cohesion

System Architekturen erstellen (Part 2)

Um was geht es hier?

Jeder der in einer Situation war, eine Systemarchitektur definieren zu müssen, ist auf folgende Herausforderungen gestoßen.

  • Wie komme ich zu einer System Architektur.
  • Wie kann ich meine System-Architektur dokumentieren?

Auf die erste Frage, bin ich in meinem vorherigen Eintrag eingegangen. In diesem Beitrag möchte ich auf die zweite Frage eingehen.

Wie finde ich einen ersten Entwurf einer System-Architektur

Hierfür bieten sich folgende Ansätze an:

Ausgangspunkt Vorgehen
Ein ähnliches System wurde in der Vergangenheit bereits erstellt Man startet mit der bereits verwendeten System-Architektur und passt diese an das Projekt an
Referenz-Architektur Man startet mit einer Referenzarchitektu,r für die zu unterstützende Platform. Zum Beispiel JAVA2EE
Architektur Pattern Man startet mit einem Architektur-Pattern. Ggf werden mehrere Pattern angewendet, die sich ergänzen.

Wie kann ich die System-Architektur beschreiben

Fachliche Anforderungen sind im Allgemeinen stabiler als technische Anforderungen. Stabil bedeutet, dass diese weniger volatil sind bzw. sich ändern.

Oder mit anderen Worten:
„Technologien ändern sich schneller als die fachlichen Anforderungen“

Für die System-Architektur bedeutet dies, das wir uns auf das High-Level Design beschränken.

Intermediate und Low-Level Design ersparen wir uns bei der Dokumentation.

Für die Definition und Beschreibung der wichtigsten Informationen im High-Level Design haben sich in der Praxis folgende Notation/Visualisierungen bewährt.

Die Fokus-Frage Notation
Was gehört zum System? Kontext-Diagramm
Wie trenne ich fachliche und technische Dienste? DDD Hexagon Diagramm
Wie beschreibe ich, wie die Daten verarbeitet werden? Datenfluss-Diagramm
Wie beschreibe ich, aus welchen Teilen/Komponenten mein System besteht? Struktur / Blockdiagramme
Welche Daten werden gespeicherte Datenmodelle

Für die weitere Vertiefung zur Erstellung von System-Modellen empfehle ich die Seite:
Blockdiagramme

Katgeorie:Methodik | Kommentare deaktiviert für System Architekturen erstellen (Part 2)