6 Architektur-Mittel (WOMIT)

Transkript

1 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte und Techniken aufzeigt, die heutzutage in den Werkzeugkasten eines Software- Architekten gehören. Nach dem Lesen dieses Kapitels haben Sie eine Vorstellung davon erhalten, welche Mittel Sie einsetzen können, um Architekturen zu bewerten, zu beschreiben, zu erstellen und weiterzuentwickeln. Übersicht 6.1 Architektur-Prinzipien Grundlegende architektonische Konzepte Architektur-Taktiken, -Stile und -Muster Basisarchitekturen Referenzarchitekturen Architektur-Modellierungsmittel Architekturrelevante Technologien

2 spielsweise kann eine Referenzarchitektur je nach Umfang die fachliche als auch die technische Architektur umfassen. Die Verwendung der technischen Aspekte einer Referenzarchitektur setzt jedoch voraus, dass die Rahmenbedingungen auch die Verwendung der durch die Referenzarchitektur festgelegten Technologien erlauben. Sollte dies nicht zutreffen, kann bereits ein Teil der Referenzarchitektur nicht mehr verwendet werden. Ein Architekt muss daher eine Balance zwischen den durch Architektur-Mittel gemachten Vorgaben und der konkreten Problemstellung finden. Es empfiehlt sich, bei der Identifikation der Architektur-Mittel zunächst solche zu begutachten, die einen hohen Wiederverwendungsgrad besitzen. Erst wenn keine höherwertigen Mittel (z. B. Basis- und Referenzarchitekturen) zur Verfügung stehen, sollte auf grundlegendere Mittel (Architektur-Prinzipien) zurückgegriffen werden. 6.1 Architektur-Prinzipien Einflussfaktoren auf eine Architektur Wie in den vorhergehenden Kapiteln erläutert, beschäftigt sich die Software-Architektur in erster Linie mit den Bausteinen eines Software- Systems und deren Interaktion. Diese übernehmen die Umsetzung der funktionalen Anforderungen an ein Software-System. Zusätzlich dazu spielen eine große Anzahl von nicht-funktionalen Anforderungen, wie beispielsweise Performanz, Produkteinführungszeit, Kosten, Wartbarkeit, Wiederverwendbarkeit, Änderbarkeit, Verfügbarkeit und Einfachheit, eine zentrale Rolle (siehe auch Kapitel 5). Diese Einflussfaktoren bestimmen wesentlich den Aufbau einer Software-Architektur. Dies heißt aber, dass zwei Software-Systeme mit gleichen technischen Anforderungen, die von zwei unterschiedlichen Architekten in unterschiedlichen Organisationen erstellt werden, unweigerlich voneinander abweichende Software-Architekturen haben. Es stellt sich die Frage: Wie erkennt man eine gute Software-Architektur? Gute und schlechte Architekturen In der Tat kann man schwerlich sagen, dass eine Architektur an sich gut oder schlecht ist sie erfüllt nur die gesetzten funktionalen und nicht-funktionalen Anforderungen, die an das Software-System gestellt werden, mehr oder weniger gut. Das heißt in anderen Worten: Die Architekturen haben unterschiedliche Ausprägungen der Qualitätsattribute. Beispielsweise mag eine hochflexible und konfigurierbare Server- Architektur für einen Anwendungsserver sehr geeignet sein. Hingegen ist dieselbe Architektur im Vergleich zu einer weit inflexibleren Architektur für einen Server im Bereich von eingebetteten Systemen Architektur-Mittel (WOMIT)

3 Den Begriff der Kopplung kann man sich an einigen Beispielen klarmachen. Eine Klasse ist ein zentraler Baustein eines objektorientierten Systems. Daher macht es Sinn, die Kopplung der Klassen zu betrachten. Allgemein kann die Kopplung eines Bausteins der Architektur durch einfaches Zählen der Beziehungen zu einem anderen betrachteten Baustein gemessen werden. Also, auf Klassen bezogen, kann man z. B. messen, wie stark Klassen mit anderen Klassen gekoppelt sind. Dies geschieht, indem man die Anzahl der anderen Klassen ermittelt, die mit einer gegebenen Klasse in Beziehung stehen. Eine solche einfache Metrik der Kopplung liefert einen ersten Eindruck über die Kopplung in einer Architektur. Es ist aber auch wichtig, zu betrachten, auf welche Weise die Bausteine einer Architektur gekoppelt sind. Verschiedene Realisierungen einer Beziehung zwischen den Bausteinen bedeuten als Resultat oft verschieden starke Abhängigkeiten. Angenommen zwei Klassen benötigen gemeinsame Daten. Als Beispiele sollen die folgenden drei Arten der Kopplung betrachtet werden (es gibt noch viele andere Arten der Kopplung): > Die Klassen können gegenseitig auf ihre (privaten) Daten zugreifen, was eine sehr starke Form der Kopplung darstellt, denn man kann keine der beiden Klassen mehr ändern, ohne die andere zu betrachten. > Eine weniger starke Kopplung liegt vor, wenn die Klassen über eine globale Datenstruktur kommunizieren, denn die direkten Abhängigkeiten der Klassen werden aufgelöst und in die globale Datenstruktur ausgelagert. Trotzdem ist die Kopplung noch recht stark, denn alle Änderungen, die die globalen Daten betreffen, betreffen auch alle Klassen, die mit den Daten arbeiten. > Wenn die Klassen nur über Methodenparameter kommunizieren, ist die Kopplung deutlich geringer: Die beteiligten Methoden enthalten nur die wirklich notwendigen Daten. Somit ziehen Änderungen an dieser Datenkopplung meist auch nur lokale Änderungen an den beteiligten Methoden der beteiligten Klassen nach sich. Kopplungsmetriken können auch für andere Architektur-Sichten und Arten von Bausteinen betrachtet werden. Eine andere sinnvolle Sicht ist die Betrachtung der Objekt- und Aufrufstrukturen zur Laufzeit. Hier kann man sagen, ein Objekt x hat dann eine hohe Kopplung zu einem anderen Objekt y, wenn es y oft aufruft. Das Prinzip der losen Kopplung besagt, dass die Kopplung zwischen Systembausteinen möglichst niedrig gehalten werden soll. Das Prinzip Prinzip der losen Kopplung 6.1 Architektur-Prinzipien 131

4 beschäftigt sich mit dem Problem, dass es für das Verstehen und Ändern eines Bausteins oft auch notwendig ist, weitere Bausteine zu verstehen oder zu ändern [Yourdon und Constantine 1978]. Es wird angenommen, dass diese Qualitätsattribute positiv durch lose Kopplung beeinflusst werden. Ein Zweck der losen Kopplung ist also, die Komplexität von Strukturen gering zu halten: Je weniger stark ein Baustein mit anderen Bausteinen gekoppelt ist, umso einfacher ist es, den Baustein zu verstehen, ohne viele andere Bausteine gleichzeitig verstehen zu müssen. Ein zweiter Zweck ist, die Änderbarkeit der Architektur zu erhöhen: Je weniger Bausteine durch starke Kopplung von einer Änderung in einem anderen Baustein betroffen sind und je loser die existierenden Beziehungen sind, umso einfacher ist es, Änderungen lokal an einzelnen Bausteinen ohne Betrachtung ihrer Umwelt durchzuführen. Zusammenhang zu anderen Prinzipien Wie man sieht: Lose Kopplung ermöglicht den Entwurf für Veränderung, ein weiteres wichtiges Prinzip der Software-Architektur. Überdies führt lose Kopplung zum Prinzip der hohen Kohäsion, denn wenn man die externen Beziehungen lose hält, ist häufig eine direkt Konsequenz, dass die Bausteine intern stärker zusammenhängend entworfen werden. Erreicht werden kann lose Kopplung insbesondere durch Umsetzung der Prinzipien Abstraktion, Separation of Concerns und Information Hiding. Die Einführung von Schnittstellenabstraktionen ist hier ein wichtiger Aspekt. Das heißt, die Belange Schnittstelle und Implementierung werden separiert und die Implementierungsinformationen werden hinter den Schnittstellen verborgen. Um dann lose Kopplung zu erreichen, sollte man versuchen, die Anzahl der Schnittstellenelemente gering zu halten und auch die Häufigkeit des Austausches von Informationen über Schnittstellen zu begrenzen. Grundsätzlich sollten Bausteine einer Architektur nur über wohl definierte Schnittstellen kommunizieren. Dies dient der Abstraktion und zusätzlich macht es auch die Kopplung von Systembausteinen kontrollierbar. Gesetz von Demeter Ein verwandtes Prinzip zu loser Kopplung ist das Gesetz von Demeter (Law of Demeter) [Lieberherr und Holland 1989], das besagt: Ein Systembaustein sollte nur eng verwandte Bausteine benutzen ( Sprich nicht mit Fremden ). Dies ist insbesondere wichtig, da Menschen nur eine begrenzte Anzahl an Informationen im Kurzzeitgedächtnis halten können. Somit macht es Sinn, Systembausteine nicht mit zu viel externer Information zu überladen, um ihre Verstehbarkeit zu erhöhen Architektur-Mittel (WOMIT)

5 Ein wichtiges Teilprinzip der losen Kopplung ist die Vermeidung zirkulärer Abhängigkeiten zwischen den Bausteinen eines Systems, weil zirkuläre Abhängigkeiten eine besonders hohe Kopplung der Bausteine nach sich ziehen. Zirkuläre Abhängigkeiten sind die Ursache für viele Probleme in der Software-Entwicklung, wie z. B. Deadlocks und erschwerte Änderbarkeit. Ein wichtiges architektonisches Problem ist hier, dass keiner der zirkulär abhängigen Bausteine verstanden oder getestet werden kann, ohne den gesamten Zyklus zu verstehen oder zu testen. Das heißt, die arbeitsteilige Entwicklung solcher Bausteine gestaltet sich schwierig. Vermeidung zirkulärer Abhängigkeiten Statt zirkulärer Abhängigkeiten sollten die Beziehungen der Bausteine dem sogenannten Hollywood-Prinzip Don t call us, we call you! folgen also lose gekoppelt sein. Dies bezeichnet man auch als Inversion of Control. Hollywood-Prinzip und Inversion of Control Dependency Inversion ist eine Anwendung des Hollywood-Prinzips bzw. der losen Kopplung: Ein Baustein definiert eine Schnittstelle, mit der er arbeitet und andere Bausteine realisieren die Schnittstelle. Dependency Inversion Dependency Injection ist eine weitere Anwendung des Hollywood- Prinzips. Sie überträgt die Verantwortung für das Erzeugen und Verknüpfen von Bausteinen an ein extern konfigurierbares Rahmenwerk (englisch: framework), um die Kopplung zu der Umgebung des Bausteins zu reduzieren. Dadurch werden auch Abhängigkeiten leichter verwaltbar. Dependency Injection Prinzip der hohen Kohäsion Kopplung beschäftigt sich mit den Abhängigkeiten von verschiedenen Bausteinen einer Architektur. Ein Baustein besteht aber häufig selbst aus vielen Teilen. Beispielsweise besteht eine Klasse aus Variablen und Methoden. Die Abhängigkeiten innerhalb eines Systembausteins werden als Kohäsion bezeichnet. Kohäsion Auch die Kohäsion kann man sich an Beispielen klarmachen. Bezogen auf die Methoden einer Klasse kann man die Kohäsion sinnvoll durch die Aufrufbeziehungen der Methoden dieser Klasse untereinander messen. In der Laufzeitsicht hat ein Objekt x dann eine hohe Kohäsion, wenn es sich oft selbst aufruft. 6.1 Architektur-Prinzipien 133

6 Prinzip der hohen Kohäsion Die Kohäsion innerhalb eines Systembausteins soll möglichst hoch sein. Wie bei der losen Kopplung geht es auch hier um die lokale Änderbarkeit und Verstehbarkeit von Systembausteinen [Yourdon und Constantine 1978]: Wenn ein Systembaustein alle die zum Verstehen und Ändern relevanten Eigenschaften in seiner Beschreibung vereint, kann man ihn folglich ändern, ohne andere Systembausteine verstehen oder ändern zu müssen. Zusammenhang zur losen Kopplung Kopplung und Kohäsion stehen normalerweise miteinander in einer Wechselbeziehung. Zumeist gilt: Je höher die Kohäsion individueller Bausteine einer Architektur ist, desto geringer ist die Kopplung zwischen den Bausteinen. Dieser Zusammenhang wird schematisch in Abbildung dargestellt. Abb : Links sieht man ein Beispiel mit starker Kopplung und geringer Kohäsion; rechts sind lose Kopplung und hohe Kohäsion umgesetzt. Eine Architektur mit loser Kopplung und hoher Kohäsion ist gut geeignet, will man die Gesamtstruktur des Software-Systems schnell verstehen. Zusammenhang zu anderen Prinzipien Eine hohe Kohäsion führt oft zu einer losen Kopplung und umgekehrt also haben diese beiden Prinzipien in vielen Fällen eine Wechselwirkung untereinander. Erreicht werden kann hohe Kohäsion wiederum insbesondere durch Umsetzung der Prinzipien Abstraktion, Separation of Concerns und Information Hiding. Eine hohe Kohäsion lässt sich durch Kapselung verwandter Anforderungen in einem Systembaustein erreichen. Das heißt insbesondere, man wendet Separation of Concerns und Information Hiding beim Entwurf an: Verwandte Anforderungen tendieren zu hohem Kommunikationsbedarf, daher sollten sie Teil desselben Systembausteins sein, um die Kohäsion des Bausteins zu erhöhen. Ein solcher Baustein sollte alle Interna vor der Außenwelt verbergen, um die Kopplung lose zu halten. Architekturen mit hoher Kohäsion ermöglichen es, die einzelnen Systembausteine als Black Boxes zu betrachten, die unabhängig voneinander geändert und ausgetauscht werden können Architektur-Mittel (WOMIT)