Architektur-Modellierung/-Visualisierung mit dem ADF

Es ist sinnvoll, ein komplexes System nicht in einem einzelnen Diagramm zu beschreiben, sondern mehrere Diagramme fĂŒr verschiedene Aspekte anzulegen. Das ADF-Framework definiert verschiedene Sichtentypen samt zugehöriger Elemente und Relationen. So erkennt man bei einem Diagramm vom Sichtentyp “Funktionen zur Laufzeit” direkt die funktionalen Teilbereiche, ihre Aufteilung und ihr Zusammenspiel. Im Gegensatz zur GebĂ€ude-Architektur (Stichwort “Flurplan” oder “Grundriss”) hat sich im Software-Engineering keine einheitliche Notation durchgesetzt, und oft werden viele unterschiedliche Aspekte in einem Diagramm vermischt.

Verwendung der ADF-Sichten

ZunÀchst sollte man verstehen, anhand welcher Dimensionen man ein System zerlegen kann (decomposition) und welche Sichtentypen es gibt.

ErklÀrung der Dimensionen

FĂŒr eine Architektursicht eines bestimmten Typs gibt es passende Elemente und Relationen.

Übersicht ĂŒber die Elemente

Am besten sieht man sich ein paar Beispiele fĂŒr Sichten verschiedener Sichtentypen an.

Beispiele

Tooling

Architektur-Modellierung/-Visualisierung mit dem ADF ist eine Methode, die unabhĂ€ngig von Tools und Technologien verwendet werden kann. ADF-Sichten kann man mit beliebigen Diagramm-Tools oder auch direkt auf dem Whiteboard zeichnen. FĂŒr die Tools Diagrams.net und PlantUML haben wir vorgefertigte Elemente und Relationen erstellt, die man direkt verwenden kann.

Zum Tooling

Weitere Themen in diesem Dokument:

Wozu verschiedene Sichten?

Wir zerlegen komplexe Materie stĂ€ndig in handhabbare Teile. Um zu verstehen, wie der menschliche Körper funktioniert, verwendet ein Medizinstudent viele verschiedene Abbildungen, die das Skelett, das Muskelsystem, das GefĂ€ĂŸsystem usw. darstellen - und auch unterschiedliche Bilder fĂŒr verschiedene Körperteile. Der GebĂ€ude-Architekt erstellt einen Flurplan als Übersicht, Grundrisse fĂŒr jede Etage, verschiedene Ansichten der AußenwĂ€nde und der Dachkonstruktion sowie spezielle Diagramme, die Stromleitungen und Steckdosen zeigen. Und wie sieht es bei Software aus?

„Es ist nicht möglich, die funktionalen Merkmale und QualitĂ€tsmerkmale eines komplexen Systems in einem einzigen verstĂ€ndlichen Modell zu erfassen, das fĂŒr alle Beteiligten verstĂ€ndlich und wertvoll ist.“ [Rozanski, Woods, 2005]

WĂ€hrend es verlockend ist, ein Softwaresystem in all seinen Details in einem großen Diagramm zu beschreiben (viele Leute versuchen das und scheitern regelmĂ€ĂŸig daran), ist ein viel praktikablerer Ansatz, ein System aus verschiedenen Blickwinkeln zu beschreiben.

Kein Standard fĂŒr Architektursichten

UML-Klassen-, Package- und Sequenz-Diagramme, welche die Code-Struktur darstellen, sind weit bekannt und verbreitet, haben aber zwei Nachteile:

  1. Sie beschreiben viele Implementierungsdetails, die fĂŒr eine GesamtĂŒbersicht vielleicht gar nicht so relevant sind und auch schnell veralten. (Manche Leute empfehlen daher, diese wenig zu benutzen und sie am besten automatisiert aus dem Code zu generieren.)
  2. Man kann sie erst dann erstellen, wenn bereits Quellcode existiert oder man zumindest weiß, an welcher Stelle Code geschrieben werden muss (Frontend versus Backend, Modul im Monolith versus eigener Microservice, 
). Bei Neuentwicklungen ist es sinnvoller, erst vom laufenden System auszugehen, dieses in Einzelteile zu zerlegen und dann zu ĂŒberlegen, wie diese Teile als Code umgesetzt werden.

FĂŒr Architekturarbeit braucht man also Sichten,

  • die grĂ¶ĂŸere ZusammenhĂ€nge visualisieren, wie z.B. das Zusammenspiel mehrerer Systeme,
  • die Systeme und Komponenten zur Laufzeit beschreiben,
  • das Deployment des Systems in der Infrastruktur zeigen,
  • Entwicklungs- und Deployment-Prozesse abbilden,
  • u.v.m.

Obwohl es verschiedene Architektursichten-Frameworks gibt, wie z.B. das 4+1 Modell von Philippe Kruchten oder das C4-Modell von Simon Brown, hat sich keines davon als allgemeiner Standard durchgesetzt. Ersteres hat aufgrund der Vielzahl unterschiedlicher Diagrammtypen und Elemente eine steile Lernkurve, letzteres engt mit den vier fest vorgegebenen “Zoomstufen” stark ein. Vor allem unterscheiden die meisten Modelle nicht zwischen Sichten auf ein System zur Laufzeit und Sichten auf ein System zur Entwicklungszeit.

Mit dem ADF-Sichtenframework stellen wir ein Modell zur Visualisierung und Modellierung von Software-Systemen zur VerfĂŒgung, welches

  • frei verwendbar ist,
  • fĂŒr alle System-Arten geeignet ist,
  • durch ein explizites Typsystem entlang der Dimensionen Laufzeit/Entwicklungszeit und Daten/Funktionen/Deployment/AktivitĂ€ten ganz deutlich macht, welchen Aspekt des Systems man beschreibt und damit hilft, nicht zu viele verschiedene Aspekte eines Systems zu vermischen.
  • ohne Software-Installation mit einem Klick sofort einsetzbar ist,
  • Tool-Support durch diagrams.net (draw.io) und PlantUML hat und damit voll kompatibel zu dem Ansatz Documentation-as-code ist,
  • auf dieser Seite hier ausfĂŒhrlich und mit Beispielen dokumentiert ist.

Die ADF-Dokumentationsvorlage komplimentiert das ADF-Sichtenframework, indem sie eine Struktur schafft, in der die Sichten eingebettet werden können.

Der ADF-Design-Guide zeigt, in welchen Iterationen man sich an eine System-Zerlegung annÀhert und welche Sichten welchen Typs dabei entstehen.

Inhaltsverzeichnis