image-20200707111153891

 

Ein praxisorientierter Leitfaden

Version: 1.1 / 11.12.2020

 

Autoren:

Jörg Hofstetter, Jordan Sucur, Hansjörg Diethelm, Martin Jud

Dozierende der Hochschule Luzern, Departement Informatik, Rotkreuz. https://www.hslu.ch/de-ch/informatik/

Feedback willkommen: jordan.sucur@hslu.ch

 


Hinweis:

Diese Seite darf frei verwendet und verlinkt werden, auch Teile daraus dürfen unter Quellenangabe übernommen werden.


 

Inhaltsverzeichnis

Einführung und Motivation

 

Informatik-Diagramme können uns massgeblich bei der Anforderungsanalyse oder der Entwicklung und Kommunikation von Softwarelösungen unterstützen. Immer nach dem Motto "Ein aussagekräftiges Bild sagt mehr als tausend Worte"! Mit der UML 1 kennen wir eine standardisierte Technik um Diagramme auf Ebene Programmierung zu erstellen. Für die abstraktere Systemmodellierung hat sich leider die UML als wenig effektiv herausgestellt. In aktuellen Fachbüchern über Software Architektur werden daher meist mehr oder weniger formelle Blockdiagramme eingesetzt.

Der vorliegende Leitfaden zur Verwendung von Blockdiagrammen ist im Rahmen der Zusammenarbeit von Informatik-Dozierenden an der Hochschule Luzern entstanden. Uns motivierte dabei die Fragestellung, wie einfache, verständliche, aber doch aussagekräftige Diagramme eines Software- oder IT-Systems erstellt werden können. Auslöser war die Tatsache, dass sowohl bei Studierende als Dozierenden diesbezüglich oft Unklarheiten festzustellen sind.

Blockdiagramme sind meist intuitiv erfassbar und können sehr flexibel eingesetzt werden. Um aber wesentliche Aspekte eines Software Systems unmissverständlich festzuhalten, sollten ein paar Regeln beachtet werden. Diese werden im vorliegenden Leitfaden beleuchtet und mit vielen Beispiele untermauert.

Wir möchten also:

Ergänzende Inhalte:

Bereiche des Leitfadens, die linksseitig mit einer Markierung versehen sind, beinhalten ergänzende Inhalte, welche für das grundsätzliche Verständnis nicht zwingend notwendig sind. Die Leser*innen entscheiden selber, ob Sie sich entsprechend vertiefen möchten.

 

Blockdiagramme

Blockdiagramme sind uns aus der Systemtheorie 2 bekannt sind und werden auch in anderen Fachdisziplinen (z.B. der Elektronik) zur Systembeschreibung verwendet. Dazu werden die Systeme in mehrere Teile, Funktionseinheiten oder eben Blöcke zerlegt und die Wirkungsmechanismen zwischen diesen Blöcken in einem Blockdiagramm oder einem Blockschaltbild (Elektronik) dargestellt. Blöcke werden oft als Rechtecke (oder andere grafische Symbole) dargestellt, Beziehungen und Wirkungen zwischen diesen Blöcken mittels Strichen und Pfeilen modelliert. Siehe dazu nachfolgendes Beispiel aus der Literatur.

 

 

image-20200706144024463

Fig. 1: Ein Beispiel eines typischen Software-Architekturdiagrammes, Quelle: Klaus P. Jantke et al., Refinement of Adaptivity by Reflection, International Conference on Signal-Image Technology & Internet-Based Systems, Link

Leider fehlt solchen Block-Diagramm oft die nötige Präzision insbesondere in der Beschreibung der Interaktionen. Oft wird z.B. nicht zwischen Datenfluss und Beziehungen unterschieden, oder Gruppierungen werden bloss über die gegenseitige Lage auf dem Diagramm angedeutet.

Obwohl das nachfolgende Modell, welches in einem Architektur-Workshop entstanden ist, "nur" eine Handskizze ist, hat es doch eine gewisse Präzision, was die Darstellung der Interaktionen betrifft. Mittels Farben (rot und grün) wurde klar zwischen Konzepten wie Kontrollfluss (Calls, Beziehungsrichtung) und Datenfluss unterschieden. Auf einfachste Art und Weise wurde direkt im Diagramm eine Legende integriert (siehe unten links)! Das Diagramm könnte noch verbessert werden, indem z.B. die Datenflüsse vollständig mit sprechenden Namen versehen würden.

 

 

Fig. 2: Beispiel eines Blockdiagrammes, ein Software Architekturdiagramm. Quelle: http://www.flickr.com/photos/codingthearchitecture/albums/72157634079861799 (besucht: 18.4.2019).

 

Blöcke und Datenfluss

Beim Einsatz von Blockdiagrammen zur Modellierung von Software und IT Systemen stellt sich die Frage, wofür Blöcke denn eigentlich stehen können?

Typischerweise werden wir folgende "Teile" eines Systems als Blöcke modellieren:

 

Typischerweise werden wir Blöcke grafisch als Rechtecke darstellen. Es können aber auch andere Formen definiert werden, um Block-Typen zu unterscheiden (siehe "Blöcke und ihre Darstellung").

Wie können wir das Verhalten der Blöcke, d.h. das Zusammenspiel der Blöcke untereinander, beschreiben? In Analogie zur Systemtheorie (siehe untenstehenden Exkurs) kann das Verhalten eines System z.B. dadurch beschrieben werden, indem typischer Datenfluss zwischen diesen Blöcken dargestellt wird. Wir halten damit fest, welche Daten in einen Block hinein fliessen (Input-Daten) und welche Daten in der Folge aus dem Block heraus fliessen (Output-Daten). Typischerweise tun wir dies mittels Pfeilen, welche in die Blöcke und aus den Blöcken zeigen (Beachte: die Pfeile werden bewusst nicht bis auf die Kanten der Blöcke gezogen, um diese von den nachfolgend beschriebenen Beziehungen zu unterscheiden). Wichtig ist, dass die ausgetauschten Datenelemente (Nachrichten) aussagekräftig benannt werden.

 

image-20191125090152542

Fig. 3: Software-Block mit Input- und Output-Datenfluss

 

Exkurs: Blockschaltbild eines technischen Systems in der Systemtheorie

Bei Blockdiagrammen, wie sie in der Systemtheorie 2verwendet werden, wird die Wirkungen zwischen den Blöcken dadurch beschrieben, dass die Input-Signale, welche auf die Blöcke wirken, und die resultierenden Output-Signale festgehalten werden. Siehe dazu nachfolgendes Beispiel einer Temperaturregelung.

 

image-20200515120552795

Fig. 4: Technisches Blockschaltbild einer Temperaturregelung (http://www.chemgapedia.de/vsengine/vlu/vsc/de/ch/7/tc/regelung/grundlagen/regelung_grundlagen.vlu/Page/vsc/de/ch/7/tc/regelung/grundlagen/regkreis/regkreis.vscml.html)

 

Betrachten wir nun ein konkretes, einfaches Beispiel. Wir verwenden dazu ein altbekanntes Diagramm der Software Technik, das sogenanntes Kontextdiagramm 3. Damit wird klar, wie mittels Datenfluss das Verhalten eines Software Systems auf einer sehr hohen Abstraktionseben beschrieben werden kann.

 

 

image-20200219082314578

Fig. 5: Kontext-Diagramm eines Bankomaten

Auf dem Diagramm ist ersichtlich, welche externen Akteure (Kunde, Unterhalt, Bank-Zentrale) welche Daten/Nachrichten mit dem eigentlichen System, dem Bankomaten, austauschen.

Zwischen diesen Blöcken wird der Datenfluss in Form von konkreten, benannten Nachrichten mit Pfeilen, welche die Datenflussrichtung festhalten, dargestellt.

Mit diesem Blockdiagramm wird das Verhalten eines Informatiksystems, hier ein Bankomat, auf hoher Abstraktionsebene beschrieben, ohne sich um die inneren Details des Systems zu kümmern. In der Systemtheorie spricht man daher von einer Black Box View 4 , im Gegensatz zur White Box View, bei welcher die innere Struktur beschrieben wird. Der White Box View möchten wir uns im nächsten Kapitel widmen.

 

Blöcke und Beziehungen

Wenn wir zwischen zwei Blöcken einen Datenfluss einzeichnen, ist damit noch nicht geklärt, wer die Interaktionen auslöst. Neben dem Datenfluss braucht es daher weitere wichtige Elemente um ein System und sein Verhalten zu beschreiben.

Wir möchten dazu ein Beispiel betrachten, bei welchem wir sowohl Datenfluss als auch strukturelle Beziehungen in einem einzigen Blockdiagramm festhalten.

 

image-20200219073758520

Fig. 6: Enthaltensein, gerichtete Beziehung und Datenfluss

Wir sehen in dem Beispiel drei wesentliche Aspekte:

Enthaltensein: Oft wird ein Block in seinem Inneren in mehrere Unterblöcke unterteilt ( -> White Box View; d.h. wir beschreiben die innere Struktur eines Blockes). Die beiden Blöcke Bestellvorgang und Kundenverwaltung sind Teile des Blockes Web-Shop. Sie werden dazu einfach im Inneren des umschliessenden Blockes gezeichnet.

Gerichtete Beziehung: Zwischen Bestellvorgang und Kundenverwaltung haben wir eine gerichtete Beziehung. Die Richtung der Beziehung ist durch den Pfeil zwischen den Blockkanten angezeigt. Obige Figur drückt aus, dass der Bestellvorgang die Kundenverwaltung kennt, diese nutzen, d.h. Interaktionen auslösen kann (aber nicht umgekehrt).

Datenfluss: Die zu dieser Beziehung dazugehörigen Datenflüsse/Nachrichten (wie z.B. Lieferadresse) werden als "freie" Pfeile gezeichnet, welche die Kanten der Blöcke nicht berühren, sich aber nahe und parallel zur entsprechenden Beziehung befinden. Der Pfeil zeigt die Richtung des Datenflusses an.

Damit können wir z.B. aus dem obigen Diagramm folgende Schlüsse ziehen: Über die gerichtete Beziehung Kundeninformationen werden Daten wie ID, Offene Rechnungen und Lieferadresse ausgetauscht. Angestossen wir eine entsprechende Interaktion vom Bestellvorgang, dieser kennt/nutzt die Kundenverwaltung.

Wie im obigen Kontextdiagramm gesehen, kann man Datenfluss durchaus auch ohne Beziehungen einzeichnen. In diesem Fall lässt man es (noch) offen, wer die Interaktion anstösst.

Wir halten uns im Text an folgende Konvention:

 

Nun zu einem etwas komplexeren Beispiel:

image-20200724161835654

Fig. 7: Beziehungen und mögliche Datenflüsse im Innern eines Bankomaten

 

 

Blöcke und ihre Darstellung

image-20200228082221665

Fig.8: alternative Blockdarstellungen

Typischerweise wird ein Block durch ein Rechteck mit einem sprechenden Namen dargestellt. Es sind aber durchaus auch andere symbolische Darstellungen (siehe oben) oder der Einsatz von Farben möglich. Falls diese Elemente nicht selbst sprechend sind, müssen sie mittels einer Legende erklärt werden!

Aus obigen Beispielen wird auch klar, dass ein Block unterschiedlichste Dinge umfassen kann: Ein Stück Software, eine Programmierklasse, Datenbestände, einen Server (Hardware), einen Service oder auch einen Akteur. Wir können Blöcke aber auch einsetzen um reine Funktionen, d.h. Aufgaben eines Systems, zu modellieren, die (noch) nicht einer definierten Software-Komponente zugeordnet werden können!

 

Übersicht Basis-Elemente

Im Folgenden wollen wir grundlegende Elemente von Software Systemen übersichtsmässig darstellen und beschreiben. Die meisten kennen wir bereits, es sind aber auch ein paar neue dabei.

 

Fig. 9: Beziehung:

Mit einer Beziehung, einer Verbindung zwischen den Kanten zweier Blöcke, wird ausgedrückt, dass die Blöcke Fahrplan APP und SBB Server eine Beziehung haben. Über den Beziehungsnamen "Fahrplanabfrage" wird die Beziehung genauer spezifiziert. Wir verwenden möglichst sprechende, eindeutige Beziehungsnamen. Dies verbessert das Verständnis und Beziehungen können eindeutig referenziert werden.

 

1571666101348

Fig. 10: Gerichtete Beziehung

Bei einer gerichteten Beziehung wird durch einen Pfeil am Ende einer Beziehung eine Richtung dargestellt, d.h. der Block Fahrplan APP kennt oder/und nutzt den Block SBB Server. Dies kann bedeuten, dass Fahrplan APP einen "Link" zum SBB Server hat (diesen kennt) und damit entsprechende Interaktionen (Befehle) auslösen kann. Was die gerichtete Beziehung bezweckt, sollte aus dem Kontext und dem Beziehungsnamen klar werden (im Beispiel: eine Fahrplanabfrage, also eine Interaktion).

 

Gerichtete Beziehung und Interaktionen in der Programmierwelt

Betrachten wir konkrete mögliche Umsetzungen des obigen Beispiels in der Programmierwelt. Typischerweise würde die Fahrplan APP bei SBB Server Interaktionen starten, d.h. Befehle ausführen. Wir können uns dazu insbesondere folgende Varianten vorstellen: a) Beide Blöcke sind Objekte einer Programmiersprache. Dann muss Fahrplan APP eine Objektreferenz auf SBB Server haben, um z.B. eine entsprechende Methode getFahrplan() aufrufen zu können. Entsprechender Datenfluss wird technisch via Übergabeparameter und Return-Werte realisiert. b) Beide Blöcke sind Software-Komponenten unterschiedlicher Systeme, welche z.B. via REST 5 kommunizieren. In diesem Falle würde der SBB Server eine entsprechende REST-Schnittstelle 6 bereitstellen, welche Fahrplan APP nutzen kann (alternativ könnte man dies grafisch mit einem Interface darstellen, siehe weiter unten).

Damit wird klar: Es gibt ganz unterschiedliche technische Ausprägungen obiger Modell-Situation. Bei Bedarf kann dies textuell beschrieben oder in einem Detail-Diagramm (tiefere Abstraktion) aufgezeigt werden.

Gerichtete Beziehungen zwischen Blöcken sind ein wesentlicher Aspekt einer Softwarearchitektur und sagen etwas über die Kopplung 7 zwischen den Modulen aus. So ist im obigen Diagramm Fahrplan APP abhängig vom SBB Server (enge Kopplung). D.h. eine Änderung in SBB Server kann auch eine Anpassung im Fahrplan APP implizieren, aber nicht umgekehrt. Solche Abhängigkeiten möchte man in einer guten Architektur möglichst minimieren, insbesondere will man zyklische Abhängigkeiten vermeiden!

Gerichtete Beziehung machen also indirekt auch eine Aussage über den Kontrollfluss (Befehlsablauf, siehe dazu Kapitel "Komplexe Interaktionen"): Der initiale Kontrollfluss muss in diesem Fall von Fahrplan APP ausgehen. Es kann aber auch sein, dass im Rahmen einer solchen Beziehung der Kontrollfluss dreht (Siehe dazu das Konzept der Inversion of Control 8: Die Fahrplan APP könnte sich z.B. initial beim SBB Server anmelden, einen "Absender" hinterlegen und danach von SBB Server über Neuigkeiten spontan informiert werden. Siehe dazu auch das Observer-Pattern 9.)

 

image-20191106160955100

 

Fig. 11: Datenfluss mit Bezug zu einer Beziehung

Im obigen Bild wird der Datenfluss in Bezug auf die Beziehung Fahrplanabfrage dargestellt, d.h. die Nachricht Strecke fliest zum SBB Server, die Nachricht Fahrplan zur Fahrplan APP. Die eingezeichnete Datenrichtung enthält keine Aussage darüber, wer in dieser Situation aktiv wird, wer den Datenfluss anstösst (dies ist in einer frühen Projektphase oft ein technisches "Detail" , welches erst auf Realisierungsebene interessiert). Durch Einzeichnen einer gerichteten Basis-Beziehung könnte geklärt werden, wer die Interaktionen anstösst.

 

image-20191106161330099

Fig. 12: Datenfluss ohne Bezug zu einer Beziehung (Beachte: die Pfeile werden nicht auf die Kanten gezogen).

Datenfluss kann auch ohne Bezug zu einer Beziehung eingezeichnet werden (wie dies z.B. im Rahmen des Kontext-Diagrammes erfolgte). Zu beachten ist, dass die Pfeile für Datenfluss nicht auf die Block-Kanten gezogen werden, sonst können wie sie nicht von gerichteten Beziehungen unterscheiden!

 

Praxishinweis: Diese Darstellungsart mit den "freien" Pfeilen kann bei Diagrammen mit vielen Nachrichten und der Verwendung eines Zeichnungswerkzeuges aufwändig werden, da die Nachrichten nicht an die Kanten der Blöcke "geklebt" werden können (die meisten Zeichnungsprogramme bieten solche "Klebe"-Funktionen an, damit können komplexe Diagramme einfacher angepasst werden).

Das Zeichnungsprogramm Visio von Microsoft bietet mit der Vorlage Datenflussdiagramme eine Lösung an, die auch ein Ankleben solcher "freier" Pfeile erlaubt.

Als einfache Alternative kann die im Kapitel "Komplexe Interaktionen" vorgestellte asynchrone Nachricht verwendet werden (gestrichelte Verbindungslinie zwischen den Kanten der Blöcke mit offenem Pfeil).

 

1555588692810

Fig. 13: Verwendung der "asynchronen Nachricht" für die Darstellung von Nachrichtenfluss. Durch die gestrichelte Linie haben wir eine klare Unterscheidung zur gerichteten Beziehung (zur Erinnerung: eine Beziehung wir mit einer ausgezogenen Linie gezeichnet).

Falls in einem Diagramm nur Datenfluss und keine gerichteten Beziehungen verwendet werden, und eine entsprechende Legende im Diagramm vorhanden ist, kann auch ein ausgezogener Pfeil zwischen den Kanten verwendet werden. Dies muss aber in einer Legende deklariert werden.

 

 

image-20200721105743254

 

Fig. 14: Ein Port

Ein Port, hier durch ein Quadrat auf der Kante eines Blockes dargestellt, stellt einen definierten Interaktionspunkt dar. Er stellt eine Art "Tor" dar, eine definierte Öffnung (analog einem Stecker) für die Interaktion mit der Umwelt dar. Zur eindeutigen Identifikation sollten Ports einen sprechenden, eindeutigen Namen haben (wie Fahrplan im obigen Beispiel).

Ein Port kann von anderen Blöcken benutzt werden, er kann aber auch selber aktiv werden und andere Ports oder Blöcke benutzen. Port's können allenfalls auch nur auf einer Seite einer Beziehung vorhanden sein.

Damit sind in obigem Diagramm folgende Aussagen möglich:

 

 

image-20200721105625597

Fig. 15: Interface

SBB Server bietet der Umwelt ein Interface an, über welches andere Blöcke (hier Fahrplan APP) definierte Dienste nutzen können. Das Interface sollte einen sprechenden und eindeutigen Namen haben (hier Fahrplan API / API=Application Interface), damit es in einer Schnittstellenbeschreibung referenziert werden kann.

Im Gegensatz zu einem Port (siehe oben) hat ein Interface eine klare "Richtung", d.h. ein Block bietet ein Interface an, ein oder mehrere Partner verwenden es.

 

Fazit: Mit den bisher vorgestellten Darstellungselementen können schon sehr viele Eigenschaften von Software Systemen präzise und einfach beschrieben werden. Wir werden im Kapitel Komplexe Interaktionen weitere Elemente für die Modellierung komplexerer Interaktionen kennen lernen.

Obige Beispiele sollen nun aber nicht bedeuten, dass in jedem Fall genau diese Notationen zu verwenden sind. Es handelt sich vielmehr um einen sinnvollen Vorschlag. Wichtig ist allerdings, dass allen Beteiligten immer klar ist, welche Bedeutung Symbole, Linien und Pfeile haben. Dies kann am einfachsten dadurch erreicht werden, indem zu jedem Diagramm eine entsprechende Legende anfügt wird, oder für ein bestimmtes Projekt eine gemeinsame Notation festlegt wird.

 

Diagrammtypen

Nachfolgend möchten wir den praktischen Einsatz von Blockdiagrammen anhand bekannter Diagrammtypen der Softwaretechnik beispielhaft beleuchten. Um aber eine systematische Einordnung dieser Diagrammtypen zu erleichtern, vorgängig ein paar Worte zu Software Modellen.

Ein Software Modell stellt ein vereinfachtes Abbild der Wirklichkeit dar und besteht typischerweise aus mehreren Diagrammen, welche ein System aus unterschiedlichen Sichten (Perspektiven) und auf unterschiedlichen Abstraktionsstufen (Abstraktionsebenen) beschreiben. Abstraktion ist ein in der Technik bekanntes Instrument, um komplexe Dinge vereinfacht und übersichtlich darstellen zu können.

 

image-20200707084527558

Fig. 16: Analogie Architekturskizzen (Diagramme): aus unterschiedlichen Blickwinkeln und unterschiedlichen Massstäben (Abstraktion) wird die Wirklichkeit modelliert. Quelle: https://thinkarchitect.wordpress.com/2011/05/07/how-does-an-architect-design-part-1sketching-ideas/, besucht am 7.7.2020

Um ein Diagramm wirklich einordnen zu können, muss den Betrachtenden jederzeit klar sein, zu welcher Sicht und zu welcher Abstraktionsstufe (Abstraktionsebene) es gehört! Um diese Orientierung zu vereinfachen, verwenden wir an der Hochschule Luzern im Unterricht folgende Modellierungsmatrix, eine vereinfachte Übersicht der Informatik-Modellierungslandschaft mit drei Sichten (System-, Prozess-, Informations-Sicht) und drei Abstraktionsebenen (Fachliches Konzept, Technisches Konzept, Realisierung).

 

image-20191213133930342

Fig. 17: Modellierungsmatrix mit Kurzbezeichnungen und möglichen Notationen (Quelle: Hochschule Luzern, Departement Informatik https://www.hslu.ch/de-ch/informatik/).

Wir sehen anhand der obigen Modellierungsmatrix, dass je nach Bereich neben Blockdiagrammen weitere Notationen eingesetzt werden. Blockdiagramme sind insbesondere für die Systembeschreibung der oberen Abstraktionsstufen (insb. S1 bis S2) geeignet.

Wir werden in der Folge bei den einzelnen Diagrammen angegeben, auf welcher Abstraktionsstufe (Detaillierungsgrad) das entsprechende Diagramm typischerweise eingesetzt wird:

Zu beachten: Beim Einsatz mehrerer Diagramme zur Beschreibung eines System ist darauf zu achten, dass die Diagramme über alle Sichten und Abstraktionsebenen hinweg konsistent bleiben. Kommt z.B. der gleiche Block oder die gleiche Beziehung in mehreren Diagrammen vor, müssen diese über alle Diagramme auch gleich bezeichnet werden!

 

Exkurs: Andere Notationen

In der obigen Modellierungsmatrix werden neben den Blockdiagrammen weitere Modellierungs-Notationen erwähnt. Ein paar ergänzende Worte dazu:

Die Sicht "Prozesse" wird sehr gut mit der BPMN 10 abgedeckt. Dies dürfte auch in der Praxis die meistgewählte Variante darstellen.

Für die Sicht "Information" gibt es die unterschiedlichsten, etablierten Notationen wie Chen, Krähenfuss, Martin, Bachmann und UML Klassendiagramme (siehe z.B. https://de.wikipedia.org/wiki/Entity-Relationship-Modell).

Mit der UML1 wurde im Bereich der objektorientierten Programmierung (S3) eine einheitliche Notation standardisiert. Sie ist für die Systembeschreibung höherer Abstraktion aber weniger geeignet und wird in der Praxis auch selten dafür eingesetzt. Dazu ein paar Stimmen aus der Fachwelt:

Martin Fowler, der Autor des bekannten Buches "UML Distilled: A Brief Guide to the Standard Object Modeling Language", Addison-Wesley, 2003", https://martinfowler.com/bliki/UmlMode.html (besucht: 17.4.2019) unterscheidet mehrere Arten um UML einzusetzen:

a) UmlAsSketch: communicate some aspects of a system, b) UmlAsBlueprint: build a complete software design, c) UmlAsProgrammingLanguage: UML as higher level language.

Er propagiert UML insbesondere für die Ebenen c) und allenfalls b). Zu a), der Systemsicht, sagt er: "This group isn't very impressed with UML 2".

Scott Ambler hat in seinem Buch "Agile Modeling, 2002, John Wiley & Sons" eine Methode vorgestellt, wie man in agilen Software Projekten modelliert https://www.agilemodeling.com/ (besucht: 17.4.2019). Er bezieht sich dabei teilweise auf bekannte UML Diagramme aber auch auf andere Diagramme wie "Data flow diagrams (DFD)". In der Übersicht auf http://agilemodeling.com/artifacts/ (besucht: 17.4.2019) wird ersichtlich, dass viele der referenzierten Diagramme keine UML Diagramme sind.

Mit der SysML 11sollten entsprechende Einschränkungen der UML für die Systemmodellierung aufgehoben werden. SysML konnte sich aber nicht durchsetzen, insb. da sie grundlegen Schwächen der UML in diesem Bereich nicht beheben konnte.

Mit der Methode C4 model 12 wurde ebenfalls darauf reagiert, dass UML für die abstrakte Architektur-Modelle wenig geeignet ist (z.B. auch keine Aussagen über sinnvolle Abstraktionsebenen macht) und daher in der Praxis kaum eingesetzt wird. Daher hat man mit C4 ein vollständiges Modellierungssystem für Software Systeme definiert, welches sehr ähnlich zu unseren Blockdiagrammen und der Modellierungsmatrix ist. Wir werden im nachfolgenden Kapitel «Container- und Component-Diagramme" im Detail darauf eingehen.

 

Kontextdiagramm

Abstraktionsstufe: S1

Das Kontextdiagramm haben wir bereits in einem frühen Kapitel ("Blöcke und Datenfluss") kennengelernt. Dabei geht es darum, die Systemgrenze klar zu definieren (was gehört zum betrachteten System, was nicht) und den umliegend Kontext festzulegen (mit welchen externen Aktoren interagiert unser System). Durch Festhalten möglicher Nachrichten (Datenfluss) zwischen den Akteuren und dem System wird das Systemverhalte auf einer sehr hohen Abstraktionsstufe beschrieben.

 

image-20200214155413811

Fig. 18: Kontextdiagramm eines Ausschreibungs-Systems (bei einer Ausschreibung oder Submission werden gewünschten Eigenschaften eines zu beschaffenden Objektes in einem Lastenheft schriftlich festgehalten und publiziert, worauf mögliche Lieferanten entsprechende Angebote eingeben können.)

 

Domänenmodell

Abstraktionsstufe: S1

Ein Domänenmodell

 

image-20200214133951016

Fig. 19: Domänenmodell Management von Ausschreibungen (Dieses Beispiel basiert auf folgender Quelle: https://www.heise.de/developer/artikel/Microservices-Warum-ein-Domain-Model-in-die-verkehrte-Richtung-fuehren-kann-4142695.html)

Neben den bereits eingeführten Beziehungen zwischen den Blöcken übernehmen wir im Domänenmodell von der UML 13 folgende Beziehungsarten zwischen Blöcken:

Generalisierung/Spezialisierung: Ein Lieferant aber auch ein Käufer sind je Spezialisierungen einer Firma. Firma stellt eine Generalisierung von Käufer und Lieferant dar.

Kardinalitäten: In vielen Blockdiagrammen ist die Unterscheidung zwischen konkreten Instanzen und Typen von Blöcken nicht zentral. Aber in obigem Diagramm möchten wir konkret ausdrücken, dass mehrere Instanzen des Blockes Offerte zu einer bestimmten Ausschreibung gehören.
Die Kardinalität (0..*) in der Beziehung zwischen Ausschreibung und Offerte drückt aus, dass eine Instanz von Ausschreibung eine Beziehung zu Null oder beliebig vielen Instanzen von Offerte hat.

Komposition (Aggregation): Eine Ausschreibung besteht aus mehreren, bzw. (0...n) Offerten. Der schwarz ausgefüllte Rhombus symbolisiert eine Komposition, d.h. die Offerten sind Teil einer Ausschreibung, können alleine nicht existieren. (Ein nicht-ausgefüllter Rhombus würde eine Aggregation symbolisieren, was bedeutet, dass eine Offerte zwar ein Teil (Enthaltensein) einer Ausschreibung ist, aber auch alleine existieren kann.) Bemerkung: Alternativ könnte man die Offerte auch innerhalb des Blockes Ausschreibung zeichnen. Im Falle des obigen Diagramm-Types würde dies aber schnell unübersichtlich.

Die Verwendung zusätzlicher Beziehungsarten aus der UML ist problemlos möglich, da gerichtete Beziehung in unseren Blockdiagrammen und UML-Klassendiagrammen bezüglich Bedeutung und grafischer Notation gleichartig sind.

 

Exkurs: In Domänen-Modellen wird in der Praxis oft zwischen Control-, Entity- und Boundary-Blöcken unterschieden:

  • Entity-Blöcke: repräsentieren langlebige Informationen, Entitäten, die normalerweise abgespeichert werden.
  • Control-Blöcke: Beinhalten die Business-Logik, welche für die Abarbeitung der Prozesse notwendig sind.
  • Boundary-Blöcke: repräsentieren Elemente an der Schnittstelle zur Aussenwelt.

Man könnte nun diese Blockarten z.B. durch unterschiedliche Blockfarben oder auch unterschiedliche geometrische Formen grafisch unterscheiden. Je nach Verwendungszweck wird man entscheiden, welche Blöcke man bevorzugt beschreibt. In obigem Beispiel handelt es sich eher um Entity-Blöcke, wie man sie insb. in einer "Bounded Context Map" (siehe unten) vorfindet und dazu verwendet, um Microservices (siehe Kapitel "Diagramm einer Microservice-Architektur") zu identifizieren.

 

Bounded Context Map

Abstraktionsstufe: S1

Ein "Bounded Context" ist ein zentrales Werkzeug der Methodik "Domain-Driven Design" 14. Eine Kurzbeschreibung dazu findet sich bei Martin Fowler: https://martinfowler.com/bliki/BoundedContext.html. Siehe auch das Kapitel "Domänenmodell".

Oft kann eine einzelne Entität eines Domänenmodells sinnvollerweise nicht in der ganzen Domäne genau gleich definiert werden. Ein Kunde hat z.B. in einem Verkaufs-Kontext eine andere Ausprägung als in einem Support-Kontext. Dieser Aspekt kann durch Verwendung von "Bounded Context" modelliert werden. Bounded Context kann z.B. ein wichtiges Hilfsmittel zum Erfassen von Microservices (siehe Kapitel "Diagramm einer Microservice-Architektur") sein.

 

image-20191213112800645

Fig. 20: Eine Bounded Context Map anhand eines Beispiels aus Fowler (https://martinfowler.com/bliki/BoundedContext.html).

Ein "Bounded Context" wird hier als Block mit einem speziellen Aussehen (Oval) modelliert (wie dies in der DDD Literatur üblich ist). Es lassen sich auch DDD-gemässe Up-Links (U) und Down-Links (D) modellieren. Alternativ könnte man auch eine Gruppierung (gestricheltes Oval) verwenden. Zu beachten ist hier, dass Customer innerhalb Sales Context nicht genau die gleiche Ausprägung wie Customer innerhalb Support Context hat!

 

Anwendungslandkarte / Systemlandkarte

Abstraktionsstufe: S1-S2

Anwendungslandkarten werden oft bei der Neuentwicklung einer IT Applikation und deren Integration in ein Gesamtsystem in einer frühen Projektphase erstellt, um auf technischer Ebene einen Überblick über eine IT-Landschaft zu erhalten. Dazu werden in einem Diagramm Anwendungen, Systeme, wichtige Daten, Schnittstellen und Datenaustausch (Datenfluss) und deren Bestellungen dargestellt.

 

 

image-20191126172733430

Fig. 21: Anwendungslandkarte/Systemlandkarte. Quelle: http://www.arcway.com/produkte/arcway-methode/anwendungslandkarten/ (Modifiziert und erweitert, da insb. die originale Interface-Modellierung nicht aussagekräftig war).

Wie wir in obigem Beispiel sehen, können auch Farben dazu eingesetzt werden, um verschiedene Block-Typen zu unterscheiden. Diese werden in einer Legende, welche Bestandteil des Diagrammes ist, erklärt.

 

Technisches Übersichtsdiagramm

Abstraktionsstufe: S2

Eine grobe Übersicht ("High Level View") über die Beziehungen zwischen den Grundelementen (Funktionen, Komponenten) und den eingesetzten Grundtechnologien.

image-20191122121803717

Fig. 22: technisches Übersichtsdiagramm

Im obigen Diagramm werden die wichtigsten Komponenten des Systems und deren Nutzungsbeziehungen aufgezeigt. Man sieht z.B., dass Service A und Service B eine gemeinsame Datenbank DB nutzen, und dass für den Daten- und Befehlsaustausch zwischen API-Gateway und den Services ein sog. Message Bus verwendet wird, wobei hier eine konkrete Technologie (Rabbit MQ) eingesetzt wird.

Was man auf diesem Diagramm nicht sieht: wer tauscht mit wem konkret welche Daten über den Message Bus aus! Im nächsten Diagramm wurden daher zusätzlich konkrete Nachrichten eingezeichnet:

 

image-20191122123141777

Fig. 23: technisches Übersichtsdiagramm, Erweiterte Darstellung

Man sieht in der obigen Skizze, dass Service A eine Massage A über den Message Bus zum Service B schickt. Noch etwas klarer wird diese Situation mit der Darstellung der Message B.

Im späteren Kapitel "Diagramm einer Microservice-Architektur" werden wir eine weitere, abstraktere Darstellungsform aufzeigen: Der Message Bus, als technisches Hilfsmittel, wird dort ganz weggelassen (abstrahiert), nur noch die direkten Nachrichten zwischen den Services und dem Gateway werden eingezeichnet. Durch Erhöhung der Abstraktionsstufe kann damit der Blick auf das Wesentliche fokussiert werden.

 

Datenflussdiagramm

Abstraktionsstufe: S2

Um das Zusammenspiel mehrerer Teile eines komplexen Systems darzustellen (d.h. das Verhalten des Systems zu beschreiben) reicht es oft, wenn wir mögliche Datenflüsse zwischen den beteiligten Blöcken einzeichnen. Die Beziehungsarten (Richtung der Beziehung) werde weggelassen (abstrahiert) - entweder weil sie in der Entwicklung noch gar nicht bekannt sind, oder weil das Diagramm sonst zu unübersichtlich würde.

 

image-20191129165810263

Fig. 24: Datenflussdiagramm einer Data Warehouse Applikation. Quelle: https://www.slideshare.net/vanuganti/designing-scalable-data-warehouse-using-mysql

Wir haben obige Skizze (bis auf die integrierte Legende Dataflow) unverändert der angegebenen Quelle entnommen. Sie Skizze könnte verbessert werden, indem die einzelnen Nachrichten/Datenflüsse mittels sprechendem Namen klar bezeichnet würden.

Nachfolgend ein Datenfluss-Diagramm (DFD), wie es in der Strukturierten Analyse 15 verwendet wird (deMarco-Notation). Dabei werden symbolische Blockdarstellungen für unterschiedliche Bedeutungen eingesetzt. Die Bedeutung der Symbole und Pfeile sind in einer integrierten Legende festgehalten.

image-20200724143602798

Fig. 25: Datenflussdiagramm

Bemerkung: Da wir hier nur Datenfluss und keine Beziehungen einzeichnen, und wir die Bedeutung der Pfeile in einer Legende klären, dürfen wir der Einfachheit wegen die Pfeile für den Datenfluss grafisch auf die einzelnen Blöcke "ziehen" (es kann keine Verwechslungen mit gerichteten Beziehungen geben).

 

Layer-Diagramm

Abstraktionsstufe: S2-S3

Bei einer sog. Layer-Architektur werden Softwarekomponenten mehreren logischen Layern (logische Schichten) zugeordnet und klare Regeln bezüglich der Abhängigkeit angewendet: Blöcke oberer Schichten greifen nur auf direkt darunterliegen Schichten zu, aber nicht umgekehrt. Durch Einhalten diese Regel kann eine besser wartbare Architektur erreicht werden (zyklische Abhängigkeiten zwischen Blöcken führen zu schwer wartbaren Systemen. Da eine Änderung in einem Block zu möglichen Anpassungen an den abhängigen Blöcken führt, diese neu getestet werden müssen...).

Ein Beispiel einer Layer-Architektur, basierend auf den oben gemachten Vorschlägen für Blockdiagramme:

image-20191104154505275

Fig. 26: Layer-Diagramm.

Die einzelnen Layer (wie User Interface, Application, Domain und Infrastructure) werden als Gruppierung (gestrichelte Linien) markiert, da sie keine eigentlichen Software-Komponenten darstellen. Beziehungen erfolgen gemäss obiger Regel, Datenfluss ist natürlich in beide Richtungen erlaubt.

Betrachten wir dazu auch ein Original-Diagramm aus einem Fach-Paper. Es basiert auf Überlegungen von Eric Evans, der wesentlich den Architekturansatz Domain Driven Design (DDD 14 ) prägte. Es zeigt uns eine analoge Layer-Architektur. Diese Originalskizze sieht unserem Blockdiagramm verblüffend ähnlich!

 

image-20191105081433757

Fig. 27: Layer Diagramm nach Eric Evans: Cesar de la Torre: DDD N-Layered Architecture Guidance, einem Workshop-Paper auf idoc entnommen (S. 33) welches 2019 hochgeladen wurde auf https://idoc.pub/documents/overview-ddd-n-layered-architecture-4h-workshop-19n06k2mgpnv. Letzter Besuch: 17.5.2020)

 

Warum aussagekräftige Pfeile so wichtig sind

Sowohl im Schulalltag als auch in der Fachliteratur tauchen immer wieder Blockdiagramme mit unklaren Pfeilen auf. Dazu ein durchaus typisches Beispiel aus der Fachliteratur:

 

image-20201130114915694

Fig. 28: Blockdiagramm einer Layer-Architektur von Cesar de la Torre: DDD N-Layered Architecture Guidance, Präsentation Slide, basierend auf «Guía de Arquitectura N-Capas orientada al Dominio con .NET», Cesar de la Torre Llorente et. al, Microsoft Architecture, 2010.

Beim Betrachten des obigem Diagrammes stellt sich unweigerlich die Frage, was die roten Pfeile bedeuten. Versuchen wir es mit dem «Ausschlussprinzip» (was kann es nicht sein?):

  • Es können keine gerichteten Beziehungen sein, da die Pfeile zwischen den Layern in beide Richtungen zeigen. Damit würden Layer-Vorschriften verletzt!
  • Es können keine Datenflüsse sein. Es ist kaum vorstellbar, dass aus dem Infrastruktur-Layer Daten ausschliesslich «raus» fliessen.

Entweder sind also einzelne Pfeile falsch oder man hat nicht sauber zwischen Beziehungsrichtungen und Datenfluss unterschieden. In beiden Fällen fehlt den Pfeilen eine konkrete Aussagekraft, d.h. die Pfeile verwirren!

In einem späteren Dokument der gleichen Autorengruppe taucht das gleiche Diagramm in einer modifizierten Form wieder auf. Jetzt wird die Bedeutung der Pfeile klarer (zumindest die schwarzen): es muss sich um gerichtete Beziehungen (Abhängigkeiten) handeln.

 

image-20201130114955986

Fig 29: Layer-Diagramm mit klareren Pfeilen aus: N-Layered Domain Oriented Architecture Guide with .NET 4.0, Cesar de la Torre Llorente et al., Microsoft Architecture, 2011.

Gerade im obigen Diagramm, welches eine sogenannte «Domain-Oriented Architecture» beschreibt, sind die Pfeilrichtungen ganz zentral. Ein wesentliches Charakteristikum dieser Architektur ist nämlich, dass der Domain Layer den Kern der Applikation darstellt und nicht abhängig von anderen Layern (z.B. dem Persistence-Layer) ist. Im Diagramm sehen wir dies anhand der Beziehungspfeile klar: Der Data Persistence-Layer kennt/benutzt den Domain-Layer, aber nicht umgekehrt. Siehe dazu auch unser Diagramm-Typ «Hexagonal Architekturdiagramm».

Bemerkung: Zwar wurden die Pfeile hier konsistent verwendet. Eine kurze Legende eingebettet im Diagramm selber wäre noch hilfreicher gewesen!

 

Hexagonal Architekturdiagramm

Abstraktionsstufe: S2-S3

Analog einem Layer-Diagramm werden die Schichten der Hexagonal-Architektur (https://www.informatik-aktuell.de/entwicklung/methoden/domain-driven-design-im-hexagon.htmlmittels) mit dem Element der Gruppierung (gestrichelte Elemente) erfasst:

image-20191122154353571

Fig. 30: Haxagonal Architecture. Quelle: https://www.informatik-aktuell.de/entwicklung/methoden/domain-driven-design-im-hexagon.html

Das Besondere dieser Architektur kommt im Diagramm klar zum Ausdruck: Das Domain-Model stellt den eigentlichen Kern der Applikation dar. Dieser Kern ist unabhängig von den anderen Gruppen: Er wird von umliegenden Blöcken genutzt (gerichtete Beziehung), er selber muss aber die umliegenden Gruppen nicht kennen. Dies bedeutet in der Praxis: Änderungen in den umliegenden Gruppen (z.B. ein neuer Adapater für eine Datenbankanbindung oder Anpassungen an einen Service) können nicht zu Änderungen des Domain Models führen. Dadurch kann das Domain Model einfacher stabil gehalten werden.

 

Container- und Component-Diagramme

Abstraktionsstufe: S2

Das sog. C4 model 12 beschreibt eine umfassende Methode zur graphischen Modellierung von Software Architekturen. C4 model propagiert dabei die Modellierung über vier Abstraktionsebenen: Context, Container, Components und Code, und deckt damit S1-S3 «unserer» Modellierungsmatrix ab. Da C4 model und unser Ansatz viele Gemeinsamkeiten haben, können wir die Ebenen Container- und Component-Diagramme durchaus übernehmen, um die technische Ebene S2 in zwei Teile zu unterteilen:

image-20201211150107553

Fig. 31: Beispiel eines Component-Diagrammes nach C4 model, aus https://c4model.com/, besucht am 9.12.2020.

In C4 model wird bei Beziehungen analog unseren Blockdiagrammen insb. zwischen Datenfluss (C4: data flow) und einer gerichteten Beziehung (C4: Dependency = Abhängigkeit, eine Ausprägung/Folge einer gerichteten Beziehung) unterschieden. Im Detail werden in C4-Diagrammen (siehe obiges Beispiel) Beziehungen allerdings etwas anders dargestellt als in unseren Blockdiagrammen: Sämtliche Beziehungsarten werden graphisch gleichartig mit einem gestrichelten Pfeil dargestellt. Die Unterscheidung erfolgt nicht graphisch, sondern über das angehängte Text-Label. Beispiele dazu (aus der angegeben C4 Quelle):

Es ist also darauf darauf zu achten, die Text-Labels pro Projekt sorgfältig zu wählen und zu "vereinheitlichen" (Legende).

Natürlich können die in C4 propagierten Diagramm-Typen Container und Component durchaus auch als Blockdiagramme mit den uns bekannten Beziehungssymbolen eingesetzt werden.

Software-Design mit Blockdiagrammen

Abstraktionsstufe: S2-S3

Beim Software-Design geht es ja um die Frage, wie man ein Softwaresystem sinnvoll strukturiert, so dass die Software gut verständlich, gut wartbar, performant etc. bleibt. Bekannte Design-Pattern 16 können uns dabei unterstützen.

Die Visualisierung (Modellierung) eines Softwaresystems wiederum kann uns dabei unterstützen, einerseits unsere Überlegungen/Resultate für uns und andere festzuhalten, aber auch um Schwachpunkte unseres Designs einfacher zu erkennen!

Dazu ein kleines, fiktives Beispiel: Wir betrachten in der untenstehenden Figur zwei Blöcke UI (User Interface) und BusinessModel. Wir sehen unten eine sog. White-Box Sicht, d.h. die innere Struktur dieser Blöcke wird ebenfalls dargestellt, wobei es sich in diesem Fall um Programmiersprachen-Klassen handelt (daher UML Symbole für Klassen verwendet).

Window A soll in diesem Beispiel eine Liste der Bestellsumme aller Kunden (Customer) darstellen. Dazu muss Window A über eine Referenz auf Customer die zugehörigen Order anfragen, bei jedem Order die zugehörigen Article anfragen um schlussendlich bei jedem Article den Preis (getPrice()) abzufragen und dann alle Preise zusammenzählen. Wir sehen sofort: Window A muss relativ viel über den inneren Aufbau von BusinessModel wissen, es muss mit mehreren inneren Blöcken/Klassen kommunizieren.

 

image-20200724154602354

Fig. 32: System aus 2 Blöcken mit Beziehungen ins Innere der Blöcke

In der nächsten Figur, einer Black-Box Sicht, blenden wir nun die innere Struktur der beiden Hauptblöcke aus. Wir erhalten so eine abstraktere Sicht auf unsere Software. Was uns auffällt: Die Sache wird nicht viel übersichtlicher. Wir haben immer noch viele Beziehungen und ohne Kenntnis der inneren Struktur von BusinessModel sind diese kaum verständlich. Wir haben zwar das Innere der Blöcke verborgen, aber die Komplexität der Beziehungen ist geblieben!

image-20200724160136001

 

Fig. 33: Black-Box Sicht

Betrachten wir nochmals das Gesamtsystem und erinnern wir uns an das Design-Pattern Fassade 17: "Die Fassade ist eine Klasse mit ausgewählten Methoden, die eine häufig benötigte Untermenge an Funktionalität des Subsystems umfasst. Sie delegiert die Funktionalität an andere Klassen des Subsystems und vereinfacht dadurch den Umgang mit dem Subsystem."

Dies wurde in der folgenden Skizze mit der Fassade OrderAdmin umgesetzt. Window A muss sich nun nicht mehr die Details von BusinessModel kümmern, sie kann sich direkt an OrderAdmin wenden, diese erledigt (delegiert) dann die Aufgaben an die entsprechenden Klassen des Teilsystems BusinessModel.

image-20200724155139354

Fig. 34: Erweiterung um das Fassaden-Muster

 

Wenn wir uns jetzt wieder der Black-Box View zuwenden, können wir dies wie folgt ausdrücken: UI nutzt ein Port OrderAdmin, um Informationen über die Order zu erhalten oder zu manipulieren. Alternativ könnten wir dies auch mit einem Interface darstellen.

image-20200403091649370

Fig. 35: Verständlichere, abstrakte Sicht

 

Was wir damit erreicht haben:

Wir daraus lernen : Nachdenken über einen besseren Softwareaufbau und Visualisierung der Software gehen Hand in Hand, beeinflussen sich gegenseitig.

 

Verteilungsdiagramm

Abstraktionsstufe: S2-S3

Ein Verteilungsdiagramm beschreibt, welche Software-Komponenten auf welchen Ressourcen (Hardware) verteilt sind und wie diese zusammenwirken.

image-20191122155226131

Fig. 36: Verteilungsdiagramm nach UML, Quelle: https://www.researchgate.net/publication/225548717_Migrating_Legacy_Assets_through_SOA_to_Realize_Network_Enabled_Capability/figures?lo=1

Obiges Verteilungsdiagramm nach UML kann durchaus als Blockdiagramm interpretiert werden und entspricht absolut unserem Anspruch betr. Einfachheit und Klarheit der Aussage! (Bemerkung: Die Interface-Verbindung mit der gestrichelten Linie zwischen "Stecker" und "Buchse" ist eine Option in UML. Diese ist intuitiv und damit auch in einem Blockdiagramm verwendbar).

 

Mechatronisches Modell

In einem mechatronischen System werden mechanische, elektronische und Informatik-Komponenten kombiniert. Alle diese Teile lassen sich als Blöcke modellieren. Der Datenfluss kann sowohl informationstechnische Daten, elektrische Signale als auch mechanische Kraftflüsse umfassen.

image-20191202093447582

 

Fig. 37: Modell eines mechatronischen Systems (ein autonomes Fahrzeug mit Motoren, Radantrieb und diversen Sensoren).

 

Komplexe Interaktionen

Nachdem wir grundlegende Notationsregeln für Blockdiagramme kennen gelernt und uns mit Diagramm-Typen auseinandergesetzt haben, wollen wir uns etwas komplexeren Interaktionsmustern von Software Systemen zuwenden, wie sie z.B. unter dem Begriff "Enterprise Integration Pattern" 18 in der Literatur beschrieben wurden.

Wir befinden uns damit auf der Abstraktionsstufe "Technisches Konzept/ Architektur", d.h. wir betrachten die konkrete/technische Ausprägung der Kommunikation zwischen Blöcken. Dazu müssen wir einige softwaretechnischen Begriffen wie synchrone- und asynchrone-Kommunikation und Kontrollfluss klären.

In der untenstehenden Figur, einem Ausschnitt unseres bekannten Bankomaten-Beispiels, wird z.B. eine Nachricht Kontostand zwischen den Blöcken Anbindung Bank-Server und Kontostand-Anfrage ausgetauscht (Datenfluss als Pfeil neben der Beziehung). Wer diesen Datenfluss initiiert, ist anhand dieses Diagrammes aber noch nicht definiert! Dies ist eine Frage des Kontrollflusses.

image-20200724162115007

Fig. 38: Ein Detail aus dem Bankomaten

Der Kontrollfluss (oder Sequenzfluss) stellt den eigentlichen Ablauf in einem Software-Programm dar. Nehmen wir an, es handelt sich in obiger Figur um ein Modell eines in Java geschriebenen Softwaresystems. Der Block Transfer würde z.B. eine Java-Methode setTransfersumme() beim Block Anbindung Bank-Server aufrufen, um damit die Nachricht Transfersumme als Methoden-Parameter zu übermitteln (man könnte auch sagen, Transfer führt einen "Call" aus). Damit geht der Kontrollfluss von Transfer nach Anbindung Bank-Server über. Erst mit dem Ende der Methode (Return) kehrt er zu Transfer zurück.

Dies ist in Übereinstimmung zur eingezeichneten gerichteten Beziehung zwischen den Blöcken Transfer und Anbindung Bank-Server: Transfer nutzt/kennt den anderen Block. Diese gerichtete Beziehung sagt uns, dass der initiale Kontrollfluss von Transfer ausgehen muss (was allerdings noch keine Garantie dafür ist, dass der Kontrollfluss während des gesamten Programmablaufes nicht auch mal die Richtung ändern kann (siehe dazu das Konzept von "Inversion of Control" 8 und auch den Einschub "Gerichtete Beziehung und Interaktionen in der Programmierwelt" im Kapitel "Übersicht Basis-Elemente").

Wollen wir also im untenstehende Diagramm gezielt ausdrücken, dass der Block Transfer einen sog. "Call" beim Block Anbindung Bank-Server ausführt (in einer objektorientierten Sprache: Methodenaufruf) und damit die Transfersumme aktiv überträgt, können wir dies z.B. mittels einer gestrichelten Linie mit einer ausgefüllten Pfeilspitze und einer entsprechenden Benennung der Beziehung darstellen:

image-20191127144038859

Fig. 39: Synchrone Kommunikation

In diesem Fall sprechen wir von einer synchronen Kommunikation, d.h. Transfer schickt eine "Anfrage" an Anbindung Bank-Server und wartet (blockiert) bis er eine entsprechende Antwort (ein OK oder eine andere Antwort) erhält und die Kommunikation abgeschlossen ist.

Innerhalb einer Software-Komponente kann eine synchrone Interaktion im einfachsten Fall durch einen "Call" (Methodenaufruf) implementiert werden. Befinden sich die beiden Partner auf unterschiedlichen Rechnern (oder Prozessen), können wir dies z.B. über einen REST-Aufruf 6 erreichen.

Bei einer asynchronen Kommunikation arbeiten Sender und Empfänger von Nachrichten zeitlich entkoppelt, d.h. der Sender einer Nachricht wartet nicht auf eine entsprechende Antwort, er arbeitet nach dem Senden weiter und verarbeitet eine allfällige Antwort irgendwann später. Ein solches Interaktions-Muster verlangt nach einer Technik zur Zwischenspeicherung der übertragenen Nachrichten. Technisch kann dazu eine Message-Queue Infrastruktur (eine Ressource des Betriebssystem oder ein unabhängiger Message Broker wie z.B. RabbitMQ 19) verwendet werden.

 

Wir können eine asynchrone Nachricht analog darstellen, aber mit einer offenen Pfeilspitze:

1555588692810

Fig. 40: asynchrone Nachricht

 

 

Notationsbeispiele komplexer Interaktionen

Die meisten Zeichnungswerkzeuge bieten Möglichkeiten, um Verbindungslinien zwischen Blöcken mit unterschiedlichen Pfeilspitzen und weiteren Symbolen n den Verbindungsenden zu erstellen. Dies können wir nutzen, um projektspezifische "Notationen" zur Typisierung von Interaktionen zu definieren. Wir möchten dies an einigen Beispielen , wie man sie z.B. in einer Microservice-Architektur 20 vorfindet, aufzeigen.

In Anlehnung an 21 haben wir uns in den ersten vier Beispiele auf die Nachrichten-Aspekte synchron/asynchron (Pfeilspitze) und konsumierend/nicht konsumierend (Zusatzsymbol Kreis) beschränkt. Wobei konsumierend hier bedeutet: der Empfänger konsumiert die Nachricht, diese steht anderen Empfängern nicht mehr zur Verfügung. Wo es Sinn macht, haben wir dabei (in Klammern) auf passende, bekannte "Kommunikationsmuster" verwiesen.

 

image-20191127105107084

Fig. 41: Asynchron und konsumierend (Winner take all)

 

image-20191127143855763

Fig. 42: Synchron und konsumierend (Request-Response oder Call).

 

image-20191127104853868

Fig. 43: Asynchron und nicht konsumierend (Fire&Forget).

 

image-20191127104313751

Fig. 44: Synchron und nicht konsumierend.

 

Wir können auch grafische Symbole auf den Verbindungselementen definieren, um Interaktionen zu typisieren:

 

1556119396299

Fig. 45: Publish-Subscribe: A ist der Publisher, bei welchem sich B anmeldet und danach entsprechende Nachrichten über einen (typischerweise asynchronen) Nachrichtenkanal erhält. Der Pfeil entspricht damit der Datenflussrichtung und nicht der "Anmeldungsrichtung".

 

1555589137408

Fig. 46: Shared Data: Zwei Blöcke A und B interagieren über einen gemeinsamen Speicherbereich.

 

1556119185605

Fig. 47: allgemeiner Nachrichtenaustausch zwischen A und B. Mittels unterschiedlicher Symbole und/oder Bezeichnung beim Nachrichtensymbol kann eine Typisierung vorgenommen werden. Dort kann z.B. stehen: Publish, Request, Response, ACK etc.

 

Diagramm einer Microservice-Architektur

Modellierungsmatrix: S2-S3

Die Umsetzung obiger Interaktionsmuster soll anhand eines Diagrammes einer typischen Microservice-Architektur 20 mit synchronen und asynchronen Verbindungen zwischen den Services aufgezeigt werden.

image-20200722101343170

Fig. 48: Microservice-Diagramm

In diesem Diagramm wird der Nachrichtenaustausch zwischen den Microservices und einem Gateway, der Schnittstelle zur Aussenwelt, aufgezeigt. Insbesondere wird ersichtlich, in welchen Fällen eine synchrone oder eine asynchrone Kommunikation gewählt wird.

Die gewählte Technik für die Nachrichtenverbindung, in diesem Falle das Message-System RabbitMQ, wurden in diesem Fall nicht als Komponente eingezeichnet, sondern hintern den Nachrichten in Klammern angegeben (RMQ oder REST). Dies im Unterschied zum Kapitel "Technisches-Übersichtsdiagramm", dort wird das Message System als eigener Block eingezeichnet. Mit dem Weglassen des Message Systems wird eine höhere Abstraktion erreicht und auf das Wesentliche (die Kommunikationsart) fokussiert.

Bemerkung: Bei den Nachrichten "Ausschreibungsunterlagen" und "Angebot" handelt es sich um nicht weiter spezifizierte, allgemeine Nachrichten, wie wir sie aus vorherigen Blockdiagramm kennen.

 

Zeitliche Abfolge von Interaktionen

Um eine zeitliche Abfolge von Nachrichten darzustellen, können Nahrichten nummeriert werden, oder auch wie folgend in einem Sequenzdiagramm dargestellt werden. Die Bedeutung der Nachrichtensymbole (hier Pfeilspitzen und Linie) bleibt dabei die gleiche.

 

image-20200727090320305

Fig. 49: Darstellung der zeitlichen Abfolge von (synchronen und asynchronen) Nachrichten. Die Zeitachse verläuft von oben nach unten.

 

Zeichnungswerkzeuge

 

Fig. 50: Handskizzen können sehr Ausdruck stark sein. Quelle: Was ist ein Luft-Abgas-System? | Haustechnik Verstehen

 

 

Begriffe und Quellen

 

Software System 
BlockBlöcke sind modulare Einheiten, Teile eines Systems. Dies können sowohl Software- als auch Hardware-Komponenten, Programmiersprachen-Klassen, Teilsysteme, externe Akteure oder auch fachliche Funktionen sein.
Alternative Begriffe für Software-Blöcke: Teil , Part ( UML 1),
Block (SysML 22), Einheit (IEC 62304 23), Modul, Paket, Klasse/Objekt.
BlockdiagrammEin Diagramm, d.h. eine grafische Darstellung von Blöcken und ihren Interaktionen. Zur Beschreibung eines Systems wird dieses in mehrere Blöcke zerlegt und die Wirkungen zwischen diesen Blöcken in einem Blockdiagramm (in der Elektronik: Blockschaltbild) dargestellt.
AbhängigkeitEin Block A ist von einem Block B abhängig, wenn Block A den Block B kennt und nutzt. Folge davon ist: Eine Änderung im Block B kann eine Anpassung in Block A bedingen.
InteraktionEine Interaktion bezeichnet das (einseitige oder wechselseitige) aufeinander Einwirken von Blöcken. Dies kann auf unterschiedliche Art und Weise erfolgen (Datenfluss oder Kontrollfluss).
Datenfluss(oder Informationsfluss) Nachrichten oder Ereignisse, die zwischen Blöcken ausgetauscht werden.
Nachricht(oder Message) eine konkrete Informationseinheit, die als gerichteter Datenfluss zwischen Blöcken übertragen wird.
Ereignis(oder Event) Ein Ereignis zeigt dem Empfänger an, dass sich etwas ereignet hat. Ein Ereignis ist schlussendlich eine Nachricht (d.h. eine Informationseinheit), deren Fokus auf der Ereignisanzeige liegt.
KontrollflussDer Kontroll- oder Sequenzfluss stellt den eigentlichen Ablauf eines Software-Programmes dar. Er legt fest, welcher Block in welchem anderen Block Software-Aktivitäten auslöst oder aufruft (Calls).
BefehlEin Block A befiehlt einem Block B etwas zu tun. Dies kann via Nachrichten oder direkt als Call einer Programmiersprache umgesetzt werden.
CallAufruf einer Sequenz von Programmiersprachen-Befehlen.
Typischerweise werden Übergabeparameter mitgegeben und ein Resultat zurück geliefert.
ModellEin vereinfachtes Abbild der Wirklichkeit.
Ein graphisches Modell eines Systems besteht aus mehreren Diagrammen, welche unterschiedliche Sichten und Abstraktionsstufen des Systems darstellen.
SichtEin System kann aus unterschiedlichen Perspektiven (Sichten) beschrieben werden. Ein Beispiel: die Datensicht
AbstraktionsstufeHohe Abstraktionsstufe: Ein System wird nur ganz grob beschrieben, die Details werden ausgeblendet.
Tiefe Abstraktionsstufe: Eine Detailbeschreibung.
Notationein System von graphischen Zeichen oder Symbolen und entsprechender Verarbeitungsregeln zum Erstellen von Diagrammen.

 

Quellenangaben:

 

 

 

 

 

 

 

 

 

 

 

 


1 Unifed Modeling Language, eine grafische Modellierungssprache zur Spezifikation, Konstruktion und Dokumentation von Software-Teilen und anderen Systemen. Wikipedia: https://de.wikipedia.org/wiki/Unified_Modeling_Language, Spezifikation der OMG, UML2.5 als pdf: http://www.omg.org/spec/UML/2.5
2 Systemtheorie, eine Engineering Disziplin, Wikipedia: https://de.wikipedia.org/wiki/Systemtheorie_(Ingenieurwissenschaften)
5 Representational State Trasfer, ein Programmierparadigma für verteilte Systeme mit Web-Service, Wikipedia: https://de.wikipedia.org/wiki/Representational_State_Transfer
6 Representational State Trasfer, ein Programmierparadigma für verteilte Systeme mit Web-Service, Wikipedia: https://de.wikipedia.org/wiki/Representational_State_Transfer
7 Ein Mass, wie eng Softwaremodule miteinander verknüpft sind, siehe Wikipedia: https://de.wikipedia.org/w/index.php?title=Kopplung_(Softwareentwicklung)&oldid=163233899)
10 Business Process Modeling and Notation, Wikipedia https://de.wikipedia.org/wiki/Business_Process_Model_and_Notation
11 System Modeling Language, Wikipedia: https://en.wikipedia.org/wiki/Systems_Modeling_Language
13 Unifed Modeling Language, eine grafische Modellierungssprache zur Spezifikation, Konstruktion und Dokumentation von Software-Teilen und anderen Systemen. Wikipedia: https://de.wikipedia.org/wiki/Unified_Modeling_Language, Spezifikation der OMG, UML2.5 als pdf: http://www.omg.org/spec/UML/2.5
14 Vaughn Vernon, Implementing Domain Driven Design, Addison-Wesley, 2013
15 Strukturierte Analyse / Strukturiertes Design https://de.wikipedia.org/wiki/Strukturierte_Analyse
18 Enterprise Integration Pattern, Introduction to Basic Conversations: https://www.enterpriseintegrationpatterns.com/patterns/conversation/BasicIntro.html
19 Open-Source Message Broker, Wikipedia: https://en.wikipedia.org/wiki/RabbitMQ
21 The Tao of Microservices, Richard Rodger, Manning 2018. siehe auch https://livebook.manning.com/book/the-tao-of-microservices
22 System Modeling Language, Wikipedia: https://en.wikipedia.org/wiki/Systems_Modeling_Language
23 Medical device software – software life cycle processes, Wikipedia: https://en.wikipedia.org/w/index.php?title=IEC_62304&oldid=889807267)