Sichten und Blickwinkel: ISO/IEC/IEEE 42010, 4+1 und Rozanski und Woods

Ein System, viele Sichten

Kein einzelnes Diagramm kann ein reales System beschreiben. Eine Zeichnung, die zeigt, wie der Code der Essenslieferplattform in Module aufgeteilt ist, sagt nichts darüber, auf welchen Servern sie laufen; eine Zeichnung von Servern und Netzwerken sagt nichts darüber, was Schritt für Schritt passiert, wenn ein Kurier einen Auftrag annimmt. Wer all das auf eine Seite bringen will, erhält das bekannte Architekturposter: Dutzende Kästen, Linien mit sechs verschiedenen Bedeutungen, und niemand kann daraus eine präzise Frage beantworten.

Der Gedanke, der das löst, ist alt und einfach. Beschreiben Sie das System durch mehrere Sichten, von denen jede eine Menge von Strukturen für eine Menge von Anliegen zeigt, so wie ein Gebäude durch einen Grundriss, eine Ansicht, einen Elektroplan und einen Sanitärplan beschrieben wird. Jede ist eine Teilbeschreibung; zusammen beschreiben sie das Ganze. Dieser Gedanke liegt der internationalen Norm zugrunde, Kruchtens 4+1-Modell, dem Blickwinkel-Katalog von Rozanski und Woods, dem Ansatz Views and Beyond des SEI und, in schlanker Form, dem C4-Modell im nächsten Abschnitt. Dieser Abschnitt erklärt das gemeinsame Vokabular und wie man die Sichten wählt, die ein bestimmtes System braucht.

Erinnern Sie sich an Abschnitt 1.5: Ein Stakeholder ist jeder, der ein Interesse am System hat, und ein Anliegen ist jede Angelegenheit, die für einen Stakeholder wichtig ist. Sichten existieren, um Anliegen zu beantworten. Eine Sicht, die niemandes Anliegen beantwortet, ist Dekoration.

Das konzeptionelle Modell von ISO/IEC/IEEE 42010:2022

ISO/IEC/IEEE 42010 ist die internationale Norm für Architekturbeschreibung. Ihre aktuelle Ausgabe erschien 2022 und ersetzte die Ausgabe von 2011. Sie sagt Ihnen nicht, wie Sie entwerfen, welche Notation Sie verwenden oder welche Sichten Sie zeichnen sollen; sie definiert die Konzepte, die eine Architekturbeschreibung enthalten sollte, und wie sie zusammenhängen, damit sich Beschreibungen, die mit verschiedenen Methoden erstellt wurden, vergleichen und prüfen lassen. Ihr konzeptionelles Modell ist das gemeinsame Gerüst fast aller Dokumentationsansätze in diesem Kapitel.

Das Modell beginnt mit dem Betrachtungsgegenstand: dem Ding, dessen Architektur beschrieben wird; das kann ein Softwaresystem, ein System von Systemen, eine Produktlinie oder ein Unternehmen sein (die Ausgabe von 2011 nannte es „system of interest“). Der Betrachtungsgegenstand hat eine Architektur, und eine Architekturbeschreibung drückt sie aus. Innerhalb der Beschreibung haben Stakeholder Anliegen. Ein Blickwinkel ist eine wiederverwendbare Spezifikation von Konventionen zur Erstellung und Nutzung einer Art von Sicht: Er benennt die Anliegen, die er erfasst, die typischen Stakeholder und die zu verwendenden Modellarten (Notationen und Modellierungskonventionen). Eine Sicht wendet einen Blickwinkel auf einen bestimmten Betrachtungsgegenstand an: Sie behandelt diese Anliegen für dieses System und besteht aus Sichtkomponenten wie Diagrammen, Tabellen und Modellen, die jeweils von einer Modellart geregelt werden (die Ausgabe von 2011 nannte Sichtkomponenten „architecture models“).

Zwei weitere Elemente zählen in der Praxis. Korrespondenzen halten Beziehungen zwischen Elementen der Beschreibung fest, am nützlichsten zwischen Sichten: Dieser Container in der Containersicht läuft auf jenem Cluster in der Deployment-Sicht; diese Anforderung wird durch jene Entscheidung adressiert. Und Architekturentscheidungen und ihre Begründung sind Teil der Beschreibung, verknüpft mit den Anliegen, die sie adressieren. Die Ausgabe von 2022 definiert außerdem zwei Konzepte genauer, die schon die Ausgabe von 2011 erwähnte, Stakeholder-Perspektiven (Arten, Anliegen zu gruppieren) und Architekturaspekte (Merkmale des Betrachtungsgegenstands, die quer zu den Sichten liegen), benennt „architecture framework“ in „architecture description framework“ (Architekturbeschreibungsrahmen) um und legt fest, was konforme Architekturbeschreibungsrahmen, etwa die eigene Dokumentationsvorlage eines Unternehmens, enthalten müssen.

Kruchtens 4+1-Sichtenmodell

Philippe Kruchten, damals bei Rational Software, veröffentlichte Architectural Blueprints: The „4+1“ View Model of Software Architecture im November 1995 in IEEE Software. Das 4+1-Sichtenmodell war der erste weit verbreitete Ansatz mit mehreren Sichten und wurde Teil des Rational Unified Process. Kruchtens Argument war, dass die Einzeldiagramme jener Zeit zu viel auf einmal erfassen wollten und dass verschiedene Stakeholder (Endnutzer, Entwickler, Systemingenieure, Projektleiter) verschiedene Sichten brauchen.

Die vier Sichten sind diese. Die logische Sicht beschreibt die Funktionalität, die das System Endnutzern bietet, typischerweise als die wichtigsten Abstraktionen und ihre Beziehungen (in UML als Klassen- und Zustandsdiagramme). Die Prozesssicht behandelt Laufzeitanliegen: Prozesse und Threads, Nebenläufigkeit, Verteilung, Performance, Skalierbarkeit und Fehlertoleranz. Die Entwicklungssicht (auch Implementierungssicht genannt) beschreibt die Organisation der Software in ihrer Entwicklungsumgebung: Module, Subsysteme, Schichten und ihre Abhängigkeiten, die für Programmierer und für die Planung der Arbeit durch das Management zählen. Die physische Sicht (oder Deployment-Sicht) bildet die Software auf Hardware und Netzwerke ab. Das „+1“ sind die Szenarien: eine kleine Menge wichtiger Anwendungsfälle, jeder durch alle vier Sichten verfolgt, die die Architektur veranschaulichen und zugleich validieren, dass die Sichten zusammenpassen.

Die Szenarien sind der am häufigsten vergessene und wohl wertvollste Teil. Eine Sicht für sich allein kann ordentlich aussehen und dabei eine Lücke verbergen; ein echtes Szenario wie „Kunde gibt eine Bestellung auf“ durch die logische, die Prozess-, die Entwicklungs- und die physische Sicht durchzugehen, deckt fehlende Elemente und widersprüchliche Annahmen auf. Derselbe Gedanke taucht in der Laufzeitsicht von arc42 wieder auf, in dynamischen C4-Diagrammen und in Abschnitt 4.8 im Rat, ein System zu erklären, indem man einer Anfrage folgt.

Rozanski und Woods: Blickwinkel und Perspektiven

Nick Rozanskis und Eóin Woods’ Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (2. Auflage, Addison-Wesley, 2012) bietet einen Katalog von sieben Blickwinkeln für große Informationssysteme, zusammen mit einem zweiten, ergänzenden Gedanken: Perspektiven.

Ihre sieben Blickwinkel sind: Kontext (die Beziehungen des Systems zu Menschen, Systemen und externen Einheiten in seinem Umfeld), funktional (die funktionalen Laufzeitelemente, ihre Verantwortlichkeiten, Schnittstellen und wichtigsten Interaktionen), Information (wie Daten gespeichert, verwaltet, verantwortet und verteilt werden), Nebenläufigkeit (welche Teile nebenläufig laufen und wie sie koordiniert werden), Entwicklung (was Entwickler, Tester und Build-Verantwortliche brauchen: Modulstruktur, gemeinsame Verarbeitung, Standards und Organisation der Codeline), Deployment (die Laufzeitumgebung und wie die Software darauf abgebildet wird) und Betrieb (wie das System in der Produktion installiert, migriert, administriert, überwacht und unterstützt wird).

Eine Perspektive ist ihre Bezeichnung für ein Qualitätsanliegen, das quer durch alle Sichten verläuft, etwa Sicherheit, Performance und Skalierbarkeit, Verfügbarkeit und Resilienz oder Evolution (ihr Katalog umfasst außerdem Barrierefreiheit, Entwicklungsressourcen, Internationalisierung, Standort, Regulierung und Benutzbarkeit). Eine Perspektive ist keine weitere Sicht zum Zeichnen. Sie ist eine Menge von Fragen, Taktiken und Prüfungen, die auf jede Sicht angewendet werden: Für Sicherheit untersuchen Sie die Kontextsicht auf externe Akteure und Vertrauensgrenzen, die Informationssicht auf sensible Daten, die Deployment-Sicht auf Netzwerkzonen und so weiter. Das erfasst etwas, was einzelne Sichten nicht können: Qualitäten entstehen aus dem ganzen System, also müssen sie überall geprüft werden (vergleichen Sie die Qualitätsmodelle aus Kapitel 2).

Der Betriebsblickwinkel verdient besondere Aufmerksamkeit, weil viele Ansätze ihn unterschätzen. Wer das System installiert, wie Daten aus dem Altsystem migriert werden, wie die Konfiguration verwaltet wird, was der Betrieb überwacht und wie er alarmiert wird: Das sind Architekturfragen, deren Antworten das System prägen, und sie bis kurz vor dem Go-live aufzuschieben, ist eine klassische Ursache für gescheiterte Starts.

Die drei Kategorien des SEI: Modul, Komponenten und Konnektoren, Zuordnung

Kapitel 1 hat die Gruppierung von Strukturen in drei Arten durch das SEI eingeführt (siehe Abschnitt 1.1). Documenting Software Architectures: Views and Beyond verwendet dieselbe Gruppierung, um Sichten zu ordnen, und sie ist der nützlichste Weg, um zu prüfen, ob eine Menge von Sichten vollständig ist.

Modulsichten zeigen Implementierungseinheiten (Pakete, Bibliotheken, Namensräume) und Beziehungen wie ist Teil von, hängt ab von und ist ein. Typische Stile sind Zerlegungs-, Nutzungs-, Generalisierungs-, Schichten- und Datenmodellsichten. Komponenten-und-Konnektoren-Sichten (C&C) zeigen die zur Laufzeit vorhandenen Elemente (Services, Clients, Datenbanken, Queues) und die Konnektoren, über die sie interagieren (HTTP-Aufrufe, Nachrichten, gemeinsame Daten); typische Stile sind Client-Server, Publish-Subscribe, Pipe-and-Filter, Shared Data und Multi-Tier. Zuordnungssichten bilden Softwareelemente auf Dinge ab, die keine Software sind: auf Hardware und Cloud-Infrastruktur (Deployment), auf das Dateisystem und Build-Artefakte (Implementierung und Installation) und auf Teams (Arbeitszuordnung).

Die drei Kategorien lassen sich natürlich auf die anderen Ansätze abbilden. Kruchtens Entwicklungssicht ist eine Modulsicht, seine Prozesssicht eine C&C-Sicht und seine physische Sicht eine Zuordnungssicht. Die funktionalen und Nebenläufigkeits-Blickwinkel von Rozanski und Woods sind überwiegend C&C, ihr Entwicklungsblickwinkel ist Modul, und ihre Deployment- und Betriebsblickwinkel sind Zuordnung. Die C4-Container- und Komponentendiagramme des nächsten Abschnitts sind C&C-Sichten mit etwas Modulcharakter, und C4-Deployment-Diagramme sind Zuordnungssichten. Wenn Sie einen Dokumentationssatz zusammenstellen, prüfen Sie, ob er mindestens eine Sicht aus jeder Kategorie enthält, denn jede beantwortet Fragen, die die anderen nicht beantworten können.

Stakeholder und Anliegen auf Sichten abbilden

Das praktischste Werkzeug aus der Norm ist eine einfache Tabelle: Listen Sie die Stakeholder und ihre wichtigsten Anliegen auf, und benennen Sie dann die Sicht oder die Sichten, die jedes Anliegen behandeln. Lücken (ein Anliegen, das keine Sicht behandelt) zeigen, wo die Beschreibung unvollständig ist; Sichten, die niemand braucht, sind Kandidaten zum Löschen. Die folgende Tabelle ist ein erster Entwurf für die Essenslieferplattform.

Die minimale Menge an Sichten wählen

Wenn man weiß, dass es viele Blickwinkel gibt, ist die Versuchung groß, alle zu erstellen. Widerstehen Sie ihr. Jede Sicht muss mit dem System und mit den anderen Sichten konsistent gehalten werden, also erhöht jede die Wartungskosten. Das Ziel ist die kleinste Menge an Sichten, die die wichtigen Anliegen der wichtigen Stakeholder beantwortet, gemäß der Regel aus Abschnitt 4.1, für den Leser zu schreiben. Views and Beyond beschreibt ein ähnliches Vorgehen: eine Tabelle aus Stakeholdern und Sichten erstellen, Sichten zusammenlegen, wo ein Diagramm mehrere Bedürfnisse bedienen kann, und dann priorisieren.