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 Kopplung 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

Systemarchitektur und Coupling

Um was geht es hier?

In diesem Beitrag möchte ich kurz eine Entwurfsrichtlinie mit dem Namen Kopplung(engl.Coupling) 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

System-Design und Wartung

Die Antwort hierauf lautet:

„Achte auf den Grad der Kopplung zwischen den Komponenten!“

Was hierunter zu verstehen ist und was in der Praxis beachten ist, möchte ich in diesem Beitrag kurz vorstellen.

Zunächst stellt sich aber die Frage: Was bedeutet Kopplung?

Was bedeutet Kopplung?

Kopplung ist ein Maß, wie eng oder lose zwei Komponenten miteinander gekoppelt sind.

Coupling-Intro
Figure: Kopplung zweier Komponenten

Somit beschreibt die Kopplung den Grad der Abhängigkeit einer Komponente nach außen hin.

Es ist anzustreben, dass die Kopplung zwischen allen Komponenten eines Systems lose ist (im Sinne von gering).

Warum soll die Kopplung lose sein?

Ist eine Komponente mit einer losen / geringen Kopplung zu anderen Elementen, dann ist diese Komponente:

  • Einfacher auszutauschen
  • Einfacher wiederzuverwenden
  • Einfacher zu testen
  • Einfacher zu verstehen
  • Einfacher zu ändern
Coupling und Maintenace
Figure: Kopplung und Eigenschaften

Stellt sich nun die Frage:
Wie erkenne ich den Grad der Kopplung einer Komponente?

Wie erkenne ich den Grad der Kopplung einer Komponente?

Kopplung ist ein Maß für die Unabhängigkeit von Softwarekomponenten. Der Grad der Kopplung ist somit eine skalare Größe.
Hierbei unterscheiden man zwischen direkten oder indirekten Abhängigkeiten.

Direkte Abhängigkeiten sind:

  • Alle Kenntnisse darüber, wie ich eine andere Komponente ansteuern muss um sie zu verwenden
  • Alle Annahmen darüber, die ich über die andere Komponente mache

Indirekt Abhängigkeiten sind:

  • alle Elemente, die die andere Komponente benötigt um ihre Funktion zu erbringen.

Schauen wir uns als nächstes ein paar Beispiele an, um den Grad der Kopplung besser zu verstehen.

Beispiel bei der Verwendung einer JAVA Klasse / Apis

Nachfolgend ein Beispiel aus der Java-Welt.

Coupling und Java API
Figure: Beispiel Java

Beispiel bei der Verwendung eines RESTful APis

RESTFUL API siehe Restfulapi.net

Coupling und Restful API
Figure: Beispiel RESTFul API

Mögliche weitere Coupling-Aspekte können sein:

  • Annahmen über Zeitzone des Kommunikationspartners
  • Annahmen über Zeichenkodierungen (nicht UNICODE Standards)
  • Annahmen über Datenformate wie Datumsangaben, Nummernformate uns.
  • Annahmen über das Format von Textnachrichten (i.e. Sprache)

Beispiel bei der Verwendung von MQTT

MQTT siehe mqtt.org

Wie nachfolgender Abbildung zu entnehmen ist, besteht bei der Verwendung von MQTT zusätzlich zu dem verwendeten API die Abhängigkeit zu dem Topic Schema und dem Paylod einer Nachricht.

Couplimg und MQTT
Figure: Beispiel MQTT

Tip für die Praxis

Indikator Grad der Kopplung
Ich kenne von der anderen Komponente nur die Schnittstelle und die Daten geringe Kopplung
Die Methoden der anderen Komponente muss man in einer vordefinierten Reihenfolge aufrufen mittlere bis hohe Kopplung
Ich weiß, wie die andere Komponente funktioniert und welche Zustände sie annehmen kann hohe Kopplung
Coupling in der Praxis
Figure: Kopplung in der Praxis
Katgeorie:Methodik | Kommentare deaktiviert für Systemarchitektur und Coupling

System-Architekturen erstellen (Part 1)

Um was geht es hier?

Jeder, der schon einmal 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 möchte ich in diesem Beitrag eingehen und einen Leitfaden vorstellen, der den Einstieg in die Welt der System-Architekturen erleichtern soll. Auf die zweite Fragen werde ich in einem nachfolgenden Beitrag eingehen.

Big Architecture – Front up

Dies ist der  klassische Ansatz.

  • Sammeln aller Anforderungen
  • Definiere anschliessend eine System Architektur, die alle Anforderungen erfüllt.
Big-Bag Vorgehen
Abb.: Big Architecture Front – Up

In der Praxis stellen sich hierbei folgende Nachteile heraus:

  • Das Sammeln der Anforderungen erfordert zum Teil viel Zeitaufwand
  • Feedback und Beurteilung der gewählten System-Architektur erst möglich, nachdem alles umgesetzt ist.

Bessere und schnellere Erfolge erziehlt man daher mit einem agilen Ansatz.

Der agile Ansatz

Beim agilen Ansatz lautet das Prinzip:

YAGNI -> You aren’t gonna need it

Vergleiche: Dzone yagni-a-quick-introduction

Dies bedeutet, dass in der Architektur nur dann Komponenten und Subsystem eingeführt werden, wenn diese auch wirklich benötigt werden.

System-Modell schrittweise entwerfen

Abb.: Agiler Ansatz

Das Vorgehen ist hierbei wie folgt:

Schritt Tätigkeit
1 Bestimme die minimalste Menge von Features, die im ersten Schritt umgesetzt werden müssen
2 Definiere eine dazugehörige System-Architektur
3 Implementiere die System-Architektur
4 Prüfen, ob die System-Architektur die gewünschten Funktionen und Eigenschaften besitzt (Erfahrung sammeln)
5 ggf. Re-Factoring der System-Architektur
6 Definiere und bestimme die Menge der Features, die im nächsten Schritt unterstützt werden sollen/müssen.
7 Wiederhole Schritt 2 bis Schritt 6 so lange, bis alle Anforderungen/Features umgesetzt sind.

In der Praxis bedeutet dies, dass in Schritt 2 die System-Architektur ggf. erweitert oder geändert werden muss (Re-Factoring) um die jeweiligen Features zu implementieren.

Aus dem Vorgehen wird ersichtlich, dass

  • man sehr schnell zu einem lauffähigen System kommt
  • frühzeitig Erfahrung machen kann um das System-Model  zu verifizieren
  • Das System-Modell wächst mit der Zeit  und deckt genau die Anforderungen ab,  die benötigt werden.
  • Ein Over-Engineering  wird vermieden

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