Knigge für Softwarearchitekten

Entwurf von Softwarearchitekturen (Teil 2)

Peter Hruschka und Gernot Starke

In der letzten Folge haben wir Ihnen aus dem Lehrplan des iSAQB e.V. [1] den Entwurf von Softwarearchitekturen vorgestellt. Der iSAQB-e.V.-Lehrplan räumt dieser wichtigen Aktivität großen Raum ein – weshalb wir dieses Thema in unserer Kolumne erneut aufgreifen.

Alles googeln – von wegen!

Können Sie (ohne Taschenrechner) ausrechnen, wie viel drei Eier kosten, wenn die Packung mit 12 Stück 2,49 Euro kostet? Kennen Sie die Hauptstadt von Ungarn? Und können Sie einen Knopf ordentlich annähen? Vieles kann man heute bei Google nachschlagen. Allgemeinbildung ist scheinbar nur noch selten gefragt. Trotzdem helfen einige Grundkenntnisse und Fähigkeiten im realen Leben oft weiter. Auch für Softwarearchitekten gibt es, unabhängig von einzelnen Technologien, einige Grundkenntnisse und Fähigkeiten, die sie beherrschen sollten. In anderen Worten: Das kleine Einmaleins für Softwarearchitekten. Der iSAQB-Lehrplan (Kasten) schließt einige dieser Basiskenntnisse ein, die schon seit Jahren bekannt und noch immer gültig sind. Betrachten wir einige davon: Jeder Baustein, also jedes Stück zusammenhängender Quellcode, sollte einige wünschenswerten Eigenschaften besitzen.

Blackboxen und das Geheimnisprinzip

Bausteine sollten auf ihrer jeweiligen Abstraktionsebene eine Blackbox bilden und dem EVA-Prinzip genügen: Eingabe -> Verarbeitung (oder Verantwortung) -> Ausgabe. Das Innenleben sollte gemäß dem Geheimnisprinzip verborgen bleiben. Wir sprechen den Baustein nur über seine Schnittstellen an. Sein Innenleben können wir dann bei Bedarf modifizieren oder effizienter gestalten, ohne andere Bausteine zu stören. Sollten Sie für einzelne Bausteine deren Aufbau und innere Struktur vorgeben wollen (Was Sie als Softwarearchitekt häufig tun werden!), dann müssen Sie lediglich die Blackbox „aufklappen“ und sie als Whitebox betrachten: Geben Sie die Einzelteile vor, deren Zusammenwirken die Aufgabe (Funktionalität, Verantwortung) der Blackbox erfüllt. Wichtig: Die Teilbausteine müssen wieder sauber gekapselte Blackboxen mit expliziten Schnittstellen und klar definierter Verantwortung sein.

Kopplung und Kohäsion – alt, aber immer noch wichtig

Jeder Baustein sollte mit anderen Bausteinen einerseits lose gekoppelt sein und andererseits inhaltlich einen starken Zusammenhalt aufweisen: „loose Coupling“ und “ strong Cohesion“ [2]. Klingt einfach – ist in der Realität aber schwieriger. In arc42 haben wir dafür das Blackbox-Template eingefügt. Darin fordern wir zuerst, die Verantwortung jedes Bausteins in einem einzigen prägnanten Satz zu formulieren. Das ist unser Weg, Sie an das „Single Responsibility Principle“ zu erinnern. Wenn es Ihnen leicht fällt, diesen einen Satz zu formulieren, dann stimmt meist die Kohäsion. Benötigen Sie jedoch viele „und“ und „oder“, dann mag Ihr Baustein zu viel unterschiedliche Verantwortung tragen und die Forderung nach „Separation of Concern“ verletzen. Entkopplung von Bausteinen können Sie in vielen Programmiersprachen über Schnittstellen, diverse der Gang-of-Four-Entwurfsmuster oder Dependency Injection erreichen. Sie bezahlen diese Entkopplung jedoch mit verringerter Testbarkeit. Die Clean-Code-Initiative [3] hat sich unter anderem die Einhaltung dieser zentralen Grundprinzipien zum Ziel gesetzt. Hinzu kommen noch viele weitere Vorschläge für „soliden“ Entwurf, genannt SOLID-Prinzipien. Die entstammen der (ziemlich dogmatischen) Feder von Robert C. Martin [4].

Bausteine dokumentieren

Wenn Sie sich für Blackbox-Bausteine entschieden und deren Abhängigkeiten festgelegt haben, sollten Sie Ihre Entwurfsentscheidungen auch (außerhalb vom Quellcode) dokumentieren. In der UML eignen sich dafür primär Komponenten- oder Paketdiagramme. Darin können Sie Bausteine beliebig schachteln, das Verfeinern von groben Blackboxes in Whiteboxes funktioniert damit problemlos. In jeder Whitebox beschreiben Sie durch geeignete Beziehungen (Benutzung, Komposition/Aggregation, Vererbung) die Abhängigkeiten der Bausteine voneinander.

Lehrplan und Realität

Der iSAQB-Lehrplan fordert das kleine Einmaleins des Softwareentwurfs, das finden wir gut. In der Realität müssen Sie für erfolgreiche Entwürfe allerdings viel weiter gehen – zwischen Top-down- und Bottom-up-Vorgehen wechseln, verschiedene Perspektiven/Sichten einnehmen, die Domäne und gleichzeitig die Qualitätsanforderungen im Auge behalten. Daneben gilt es, die speziellen Fähigkeiten Ihrer Teams sowie die Eigenheiten bereits vorhandener Systeme angemessen zu berücksichtigen. Zu guter Letzt haben manche Projekte ja sogar Budget- und Zeitrestriktionen, die manchmal dem „gründlichen Nachdenken“ entgegenstehen. Die Realität setzt daher manchmal dem Wunschdenken des guten Entwurfs enge Grenzen. Bleiben Sie optimistisch!

Der iSAQB-Lehrplan

Das Kapitel 3 des iSAQB-Lehrplans handelt von Entwicklung und Entwurf von Softwarearchitekturen. Bezüglich des Entwurfs von Bausteinen, Entwurfsprinzipien und -mustern gibt es folgende Lernziele vor (unter der Rubrik „Können“, siehe auch [5]):

  • Grundlegende Konzepte der Architekturentwicklung benennen, erklären und anwenden
  • Bausteine von Softwarearchitekturen und deren wünschenswerte Eigenschaften benennen und erklären (Kapselung, Information Hiding, deutsch: Geheimnisprinzip)
  • Blackbox- und Whitebox-Begriff erklären und zielgerichtet anwenden
  • Arten der Zusammensetzung von Bausteinen (Schachtelung, Benutzung/Delegation, Vererbung)
  • UML-Notation für verschiedene Bausteine und deren Zusammensetzung (Pakete als semantisch schwache Form der Aggregation von Bausteinen, Komponenten mit fest definierten Schnittstellen als semantisch präzisere Form der Aggregation)
  • Entwurfsprinzipien erläutern anwenden können: Geheimnisprinzip, Kopplung und Kohäsion, Trennung von Verantwortlichkeiten (Separation of Concern), Offen-Geschlossen-Prinzip (Open-Closed-Principle), Umkehrung von Abhängigkeiten durch Schnittstellen, Dependency Injection zur Externalisierung von Abhängigkeiten
  • Abhängigkeiten und Kopplung von Bausteinen verstehen und gezielt einsetzen
  • Schnittstellen/Interfaces entwerfen und beschreiben können
  • Zusammenhang zwischen Abhängigkeiten im Modell und im Quellcode von Programmiersprachen
Peter Hruschka (http://www.systemsguild.com) und Gernot Starke (innoQ-Fellow, http://www.gernotstarke.de) haben vor einigen Jahren www.arc42.de ins Leben gerufen, das freie Portal für Softwarearchitekten. Sie sind Gründungsmitglieder des International Software Architecture Qualification Board (http://www.iSAQB.org) sowie Autoren mehrerer Bücher rund um Softwarearchitektur, Softwareentwurf und Entwicklungsprozesse.
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.