UML einfach erklärt: Die 6 wichtigsten Diagramme für Entwickler und Architekten

Um ein Softwaresystem zu beschreiben, verwenden wir gerne Diagramme und Grafiken. Diese ermöglichen es einfach und effizient komplexe Sachverhalte zu beschreiben. Nun können wir einfach wild darauf los zeichnen und verschiedene Kästchen zeichnen und diese mit Linien verbinden, um unser System darzustellen. Was wir mit unseren Kästchen und Linien aber genau meinen, ist oftmals nicht mal uns selbst klar und oftmals werden die „Syntaxelemente“ inkonsistent zwischen den Diagrammen verwendet.

Standardisierte Modellierungssprachen wir UML, die Unified Modeling Language, lösen dieses Problem, in dem sie eine einheitliche Notation vorgeben. Die UML wurde in den 1990er-Jahren geschaffen, um verschiedene Modellierungssprachen zu vereinheitlichen. Sie wird aktuell von der Open Management Group entwickelt und als ISO/IEC 19505 genormt. Die UML-Spezifikation ist frei verfügbar, aber Vorsicht, sie ist nicht unbedingt als Abendlektüre geeignet.

Typische Herausforderungen der UML

Den meisten Softwareentwicklern ist die UML wohlbekannt, aber sie wird nur ungern verwendet. Einer dieser Gründe ist die Komplexität der Modellierungssprache. Die offizielle UML-Spezifikation (Infrastructure und Superstructure) umfasst 1000 Seiten und ist teilweise sehr abstrakt und schwer verständlich. Noch dazu richtet sich die Sprache nicht nur Softwaresysteme, sondern auch an andere technische Systeme. Das bedeutet, dass viele Bereiche der Spezifikation generisch definiert sind und somit schwerer verständlich sind, als es bei einer fokussierten Sprache der Fall sein würde. Dazu kommt, dass die UML gerne auch entsprechend akademisch an Schulen und Universitäten gelehrt wird.

Wie auch bei natürlichen Sprachen existieren in der Praxis diverse Dialekte. Das sind Abwandlungen des Standards, die innerhalb einer beschränken Gruppe angewandt wird. Häufig finden wir diese Dialekte innerhalb eines Unternehmens oder eines bestimmten Teams. Wenn Leute die Sprache mit einem gewissen Dialekt lernen und sich dann mit anderen Personen austauschen, kann es zu entsprechenden Kommunikationsproblemen und Missverständnissen kommen. Das ist also ähnlich wie bei natürlichen Sprachen. Schicken Sie mal einen Wiener nach Vorarlberg 🤷‍♂️.

Bilder sagen mehr als tausend Worte

Warum brauchen wir eigentlich Modellierung? Laut Definition versteht man in der Wissenschaft unter einem Modell eine Abbildung eines Objektes, eines Verhaltens oder eines Systems, das man verstehen möchte. In der Softwareentwicklung verwenden wir Modelle bereits, um den Entwurf des Systems zu leiten. Das Modell hilft uns, ein komplexes Softwaresystem in einer einfachen, meist grafischen Repräsentation abzubilden. Es kann uns unterstützen, ein geistige Modell unseres Systems auf Papier zu bringen und einfacher zu kommunizieren. Die grafische Repräsentation über Diagramme ist dabei nicht notwendig, aber oftmals eine effizientere Alternative zu textueller Beschreibungen.

Im Gegensatz zu reinen grafischen Diagrammen, die mit einem Zeichentool erstellt werden, bieten Modelle den Vorteil, Semantik zu beinhalten. Ein Modell-Element kann validiert und wiederverwendet werden. Validierung bedeutet, dass die Modell-Elemente nur in einen gültigen, den Regeln der Modellierungssprache entsprechenden Zusammenhang gebracht werden können. Die Wiederverwendung bedeutet, dass wir ein Element nur einmal im Modell mit all seinen Eigenschaften und Beziehungen erstellen müssen und dieses Element in verschiedenen Diagrammen verwendet werden kann.

UML ist also nicht nur eine Art, um zu zeichnen, sondern um zu modellieren. Die grafische Sicht wird zwar oft in der Praxis angewandt, aber UML beschreibt in erster Linie Regeln, um Elemente und deren Beziehungen im Modell zu definieren.

UML-Diagrammarten

Das folgende Bild zeigt alle verfügbar 14 Diagrammarte der UML. Ich verwende hier bereits eines der genannten UML-Diagramme, nämlich ein Klassendiagram, um die Beziehungen und Hierarchien zwischen den Diagrammen darzustellen.

Alle Kästchen in diesem Diagramm werden als Klassen bezeichnet, die Verbindungen werden als Assoziationen bezeichnet. Es handelt sich hierbei sogar um eine spezielle Assoziation, nämlich um die Generalisierung. Das blaue Kästchen „Diagramm“ in der Mitte ist die Wurzel aller UML-Diagrammarten. Von der wird weiter aufgeteilt in Struktur- und Verhaltensdiagramme. Von dort wird weiter spezialisiert in die konkreten Diagrammtypen. Eine Ausnahme stellen Kommunikations-, Sequenz-, Interaktionsübersichts- und Zeitverlaufsdiagramme dar, die als Verhaltensdiagramme zusammengefasst werden.

In der Softwareentwicklung verwenden wir aber meistens nur einen Teil der 14 Diagramme. Ich würde auch explizit dazu raten, nur einen Teil der Diagramme im Unternehmen bzw. dem Team zu verwenden, um die Verwendung von UML zu vereinfachen. Im folgenden erkläre ich 6 Diagramme näher, die meiner Meinung nach den größten Nutzen in der Softwareentwicklung haben. Die sind:

• Komponentendiagramm
• Klassendiagramm
• Verteilungsdiagramm
• Anwendungsfalldiagramm
• Aktivitätsdiagramm
• Sequenzdiagramm

Die ersten drei sind Strukturdiagramme und können genutzt werden, um den Aufbau des Systems, die Beziehungen zwischen den Teilen sowie Hierarchien darzustellen. Mit den anderen drei Diagrammen können Verhalten dargestellt werden. Anwendungsfalldiagramme können einen guten Überblick über die Szenarien, die ein Akteur mit dem System durchführen kann. Diese Szenarien können mit Aktivitäts- und Sequenzdiagramme weiter spezifiziert werden, um ein genaue Kommunikationsverhalten oder Abläufe zu beschreiben.

Auch die anderen Diagrammtypen können natürlich einen Nutzen für die Softwareentwicklung haben. Meine List ist definitiv „opinionated“ – Tun Sie sich keinen Zwang an die Liste für Ihre Bedürfnisse anzupassen.

Komponentendiagramm

Ein Komponentendiagramm ist gut geeignet, um die groben Strukturen einer Architektur darzustellen. In meiner Architekturarbeit verwende ich die Komponentendiagramme sehr häufig, um die verschiedenen Zerlegungsebene zu modellieren.

Im Komponentendiagramm werden Komponenten und Ihre Schnittstellen festgelegt. Eine Komponente kann jeder beliebige Baustein von der Systemebene bis runter zur Klassenebene sein. Auf Klassenebene würde man eher zu einem Klassendiagramm greifen, da dieses eine detailliertere Spezifikation erlaubt.

Die Schnittstellen einer Komponente sind entweder angebotene Schnittstelle (Provided Interface) oder benötigte Schnittstelle (Required Interface). Sie beschreiben, dass Funktionen von einer Komponente angeboten werden bzw. das die Komponenten Funktionen von einem anderen Element benötigt. Typischerweise wird die benötigte Schnittstelle einer Komponente mit einer angebotenen Schnittstelle einer anderen Komponente verbunden. Diese Verbindung nennt man eine Assembly-Assoziation, die gerne über eine Balls-and-Sockets-Notation dargestellt wird.

Die Rechtecke zwischen Schnittstelle und Komponente nennt man Port. Diese sind ein Eintrittstor der Schnittstelle in das Innere einer Komponente. Ports werden nur benötigt, wenn Schnittstellen auf die inneren Elemente der Komponente weitergeleitet werden. Ich empfehle, Ports grundsätzlich einzuzeichnen, da das Hinzufügen immer richtig ist, das Weglassen aber manchmal falsch sein kann.

Hier sehen wir, wie eine Schnittstelle per Port an eine interne Komponente weitergeleitet wird. Die Weiterleitung wird mittels Delegate-Assoziation dargestellt. In diesem Diagramm kann man auch die Verschachtelung von Komponenten gut erkennen. Das ist besonders hilfreich, um Hierarchien und interne Strukturen von Komponenten darzustellen.

Klassendiagramm

Klassendiagramme können verwendet werden, um feinere Details in der Modellierung darzustellen. Typischerweise werden sie verwendet, um Klassen, wie wir sie in objektorientierten Sprachen verwenden, zu modellieren. Es können aber auch andere, fachlich-orientierte Entitäten damit dargestellt werden. Das beinhaltet Domänen-Modelle oder Datenstrukturen.

Klassen erlauben eine detaillierte Darstellung mittels Attribute und Operationen. In einer Klasse, die innerhalb einer objektorientierten Sprache umgesetzt wird, entspricht das den Feldern und Methoden der Klasse. Wird die Klasse verwendet um ein Fachobjekt innerhalb des Domänenmodells zu modellieren, so entspricht das den Eigenschaften und Zuständigkeiten des Fachobjekts.

In diesem Beispiel sehen wir eine Klasse mit Namen Tenant. Sie besitzt die Attribute Income und Move In Date, welche beides private Attribute sind. Das bedeutet, sie können nicht außerhalb der Klasse verwendet oder verändert werden. Name, Monthly Rent und Top sind öffentliche Attribute, die auch von außerhalb der Klasse verwendet und verändert werden können. Die Unterscheidung zwischen privat und öffentlich wird über das + und – am Anfang des Attributnamens spezifiziert. Nach dem Attributnamen wird der Datentyp des Attributs getrennt mit einem Doppelpunkt angegeben.

Im nächsten Abschnitt finden wir drei öffentliche Operationen vor: Pay Rent, Move In und Move Out. Pay Rent verfügt über einen Parameter von Typ Month und gibt einen boolean zurück. Bei den Parameter wird nicht der Name, sondern der Typ des Parameters angegeben.

Klassen können nicht nur allein stehend betrachtet werden, sondern können auch Beziehungen zu anderen Klassen haben. Hier sehen wir eine Reihe von unterschiedlichen Beziehungen. Die einfachste Beziehung ist die Assoziation, die wir zwischen Landlord und Janitor sehen. Sie sagt aus, dass die beiden Klassen in einer Beziehung zueinander stehen, gibt aber keine weiteren Details zu dieser Beziehung an. Assoziationen können aber noch weiter spezialisiert werden. Zwischen Tenante und Person wird eine Aggregation verwendet. Das bedeutet, dass ein Tenant aus mehreren Persons besteht bzw. sich aus mehreren Personen zusammensetzt.

Zwischen House und Flat besteht eine Komposition. Ähnlich wie die Aggregation zeigt sie, dass ein House aus mehreren Flats besteht. Eine Komposition zeigt jedoch, dass der Zusammenhang existenzabhängig ist. D. h. wenn eine Flat kann ohne House nicht existieren. Wird ein House zerstört, werden auch alle beinhalteten Flats zerstört. In diesem Beispiel sehen wir auch noch die Verwendung einer Multiplizität, die hier mit 1..* dargestellt ist. Die Multiplizität sagt hier aus, dass es beliebig viele, aber mindestens eine Instanz von Flat geben muss. Multiplizitäten könne eine einzige Zahl sein oder ein Zahlenbereich. Der Stern steht hierbei für beliebig viele.

Das letzte Assoziationsbeispiel ist die Generalisierung, die wir im Diagramm auf der rechten Seite zwischen Employer, AMCE und Local Supermarket sehen. In der Softwareentwicklung bezeichnen wir die Generalisierung auch als Vererbung. Sie zeigt, dass ACME und Local Supermarket eine spezielle Ausprägung eines Employer sind (umgekehrt ist der Employer die Generalisierung der beiden anderen Klassen). Die Employer besitzt hier auch den Stereotypen <<abstract>>. Dies bedeutet, es können keine Instanzen von Employer erzeugt werden.

Neben den gezeigten Assoziationen gibt es noch eine Reihe von weiteren Beziehungen zwischen Klassen. Wir wollen aber unsere Syntax so einfach wie möglich halten. Ich finde es besser, nur einfache Assoziationen zu verwenden, die jeder im Team versteht, als sehr detaillierte Syntaxelemente einzusetzen, die dann nicht mehr verstanden werden.

Verteilungsdiagramm

Neben der reinen Strukturbeschreibung eines Systems ist auch die physische Abbildung auf die Hardware – also die Verteilung – wichtig. Ein UML-Verteilungsdiagramm zeigt genau das: Welche Softwarekomponenten läuft auf welcher Hardware.

In einem Verteilungsdiagramm werden Knoten verwendet, um die Hardware darzustellen. Knoten können beliebig verschachtelt sein. Innerhalb eines Hardware-Knotens kann man beispielsweise eine Laufzeitumgebung darstellen. Es können auch weitere Ebenen für Rechenzentren, Cloud-Regions oder Cloudanbieter verwendet werden.

Die Softwarekomponente ist als Artefakt dargestellt. Es zeigt das physische Artefakt, das verteilt wird. Dies können Artefakte wie JAR-Files, DLLs, EXE oder MSI sein. Es kann sich hierbei aber auch um NPM-Pakete oder Docker Images handeln, die typischerweise in einem Repository gehalten werden und nicht direkt als Datei verteilt werden.

Knoten können verbunden werden, um die Kommunikationsbeziehung zwischen den Knoten darzustellen. Auch hier können Multiplizitäten verwendet werden oder einfach nur das Kommunikationsprotokoll angegeben werden.

Zu guter Letzt kann man über <<manifest>>-Beziehungen einen Zusammenhang zwischen Artefakten und Komponenten herstellen. Somit sieht man, welche Komponenten über welcher Artefakt abgebildet ist und man stellt einen Zusammenhang zwischen der Struktur des Systems und der physischen Verteilung her.

Anwendungsfalldiagramm

Kommen wir nun zu dem ersten UML-Diagramm, das Verhalten beschrieben kann. Das Anwendungsfalldiagramm ist gut geeignet, um die grundlegenden Szenarien zu beschreiben, die Akteure mit dem System ausführen können.

Die Elemente eines Anwendungsfalldiagramms sind Anwendungsfälle (Use Cases) und Akteure. Ein Spezialfall eines Akteurs ist ein Systemakteur, also ein externes System, mit denen wir über Schnittstellen kommunizieren. Akteure sind die handelnden Personen, die Aktionen im System ausführen können. Diese Aktionen werden als Anwendungsfall bezeichnet. Anwendungsfälle sind dabei relativ grob gehalten. „Blauen OK-Button klicken“ wäre zu detailliert für einen Anwendungsfall. „Suche nach Artikel durchführen“ passt hingegen gut.

In diesem Beispiel sind die Akteure als Strichmännchen dargestellt. Systemakteure verwenden die Rechteck-Darstellung und Anwendungsfälle sind als Ovale gezeichnet.

Da Anwendungsfalldiagramme nur einen Überblick über das Verhalten geben, werden diese gerne mit ausführlicheren Beschreibungen des Verhaltens ergänzt. Dies könnte sein:

• Nummerierte Liste von Schritten
• Aktivitätsdiagramme
• Sequenzdiagramme
• Nicht-UML-Diagramme wie Fluss- oder BPMN-Diagramme

Eine nummerierte Liste sind eine sehr einfache Möglichkeit, das Verhalten zu beschreiben. Wir zählen Schritt für Schritt auf, welche Aktionen durchgeführt werden:

1. Suchfenster öffnen
2. Suchbegriff eingeben
   1. Wenn kein Ergebnis angezeigt wird: Suchbegriff korrigieren
   2. Wenn Ergebnisse angezeigt werden: Auf Ergebnis klicken, um Details zu sehen.
3. Suchfenster schließen

Wie wir sehen, können auch einfache Verzweigungen und alternative Pfade gut abgebildet werden. Ich würde hier aber zur Vorsicht raten und die Verzweigungen nicht zu komplex machen. Dafür eignen sich andere Diagramme besser wie zum Beispiel das Aktivitätsdiagramm.

Aktivitätsdiagramm

Die Aktivitätsdiagramme der UML fokussieren sich auf die Abfolge von Aktionen. Diese Aktionen werden auch als atomare oder elementare Aktionen bezeichnet, um auszudrücken, dass sie nicht mehr weiter unterteilt werden können.

Die Rechtecke in diesem Beispiel stellen eben jene atomaren Aktionen da. Der Fluss der Aktionen geht vom Start-Knoten zum End-Knoten. Typischerweise zeichnet man den Fluss von oben nach untern, bzw. von links nach rechts ein. In diesem Diagramm sehen wir auch einen Entscheidungsknoten, der als Route dargestellt wird. Die Entscheidung wird in textueller Form annotiert und weist mehrere Flussalternativen auf. Diese Alternativen müssen in einem Zusammenführungsknoten wieder zusammengeführt werden, welcher ebenfalls als Route dargestellt wird.

Aktivitätsdiagramme kennen noch zahlreiche weitere Syntaxelemente, mit denen sich Nebenläufigkeit, Datenflüsse, Exceptions, Signale und noch vieles mehr darstellen lässt.

Sequenzdiagramm

Möchte man Interaktionen mit Fokus auf das Zeitverhalten darstellen, so bietet die UML dafür Sequenzdiagramme an. In Sequenzdiagrammen wird der Austausch von Nachrichten zwischen Beteiligten dargestellt. Ein Sequenzdiagramm stellt dabei einen Pfad durch einen Entscheidungsbaum innerhalb eines Ablaufes dar. Wenn verschiedene Pfade (Happy Path, Angry Path) dargestellt werden sollen, so muss hierzu für jeden Ablauf ein eigenständiges Diagramm modelliert werden. Sequenzdiagramme können hierfür auch mit anderen Diagrammen wie einem Aktivitätsdiagramm kombiniert werden, die weitere Verzweigungen und Fehlerpfade darstellen können.

Im Beispiel sehen wir mehrere Beteiligte. In diesem Fall ist das ein Akteur und zwei Komponenten, die mit Lebenslinien (den vertikalen, gestrichelten Linien) eingezeichnet werden. Zwischen den Lebenslinien werden Nachrichten ausgetauscht, wobei der Fluss von links nach rechts und oben nach unten geht. Der Name der Nachricht wird über die Pfeile geschrieben. Über die Pfeilspitzen kann angezeigt werden, ob es sich um eine synchrone oder asynchrone Nachricht handelt. Synchrone Nachrichten werden mit einer gefüllten Pfeilspitze, asynchrone Nachrichten mit einer offenen Pfeilspitze gezeichnet. Im Gegensatz zu asynchronen Nachrichten erwarten synchrone Nachricht eine Antwort und blockieren die Lebenslinie für weitere Nachrichten, bis diese eine Antwort erhalten hat.

Auch Sequenzdiagramme enthalten noch weitere Syntaxelemente wie gefundene und verlorene Nachrichten oder Schleifen.

Die anderen 8 Diagramme

Neben diesen 6 häufig verwendete Diagramme möchte ich noch kurz die restlichen 8 UML-Diagramme beschrieben. Diese können natürlich auch einen gewissen Nutzen für die Softwareentwicklung bringen.

1. Profildiagramm: Dieser Diagrammtyp wird im Metamodell von UML für die Darstellung der Strukturen von Stereotypen verwendet. Dadurch können Erweiterungen oder Anpassungen an Metaklassen vorgenommen werden.
2. Objektdiagramm: Um Instanzen von Klassen darzustellen, kann ein Objektdiagramm verwendet werden. Die Instanzen befüllen Klassen mit konkreten Ausprägungen für Ihre Attribute und zeigen so den Zustand zu einem konkreten Zeitpunkt. Objektdiagramme sehen ähnlich wie Klassendiagramme aus. Es wird neben dem Klassenname auch die Bezeichnung des Objekts im Format „Objekt: Klasse“ angegeben. Auch die Ausprägungen der Attribute werden explizit angegeben.
3. Paketdiagramm: Pakete sind ein Möglichkeit, um eine Menge an Modellierungselemente logisch zu gruppieren. Sie werden häufig verwendet, um Namensräume und Hierarchien darzustellen und können auch verwendet werden, um beispielsweise die Zugehörigkeit mehrerer Komponenten zu einer technischen Schicht darzustellen. Pakete sind semantisch schwach und deshalb sollte man sich überlegen, ob ein Komponenten- oder Klassendiagramm nicht besser geeignet ist für die Darstellung.
4. Kompositionsstrukturdiagramm: Mit Kompositionsstrukturdiagrammen können die internen Strukturen von Klassen, Komponenten und anderen Classifier dargestellt werden. Dieses Diagramm ist ähnlich wie das Objektdiagramm eine Instanz-Darstellung und beinhaltet spezifische Ausprägungen der dargestellten Classifier. Im Kompositionsstrukturdiagramm kann auch die Verbindung zwischen dem Verhalten mit der Realisierung der internen Strukturen hergestellt werden.
5. Zustandsdiagramm: Ich habe lange überlegt, ob ich das Zustandsdiagramm noch in meine Liste der wichtigsten Diagramme aufnehmen soll, da ich es doch häufiger verwende. Es zeigt die internen Verhalten eines Systems über ihre Zustände und Zustandsübergänge an. Stellen wir uns vor, wir haben eine Rechnung in unserem System, die die Zustände „erfasst“, „genehmigt“, „bezahlt“ und „storniert“ haben kann. Nur bestimmte Zustandsübergänge sind fachlich sinnvoll. Diese kann man gut in einem Zustandsdiagramm darstellen. Natürlich eignet sich dieses Diagramm auch gut zur Modellierung von Zustandsautomaten (State Machines).
6. Kommunikationsdiagramm: Das Kommunikationsdiagramm ist mit dem Sequenzdiagramm verwandt und kann den Austauschen von Nachrichten darstellen. Nachrichten werden dabei in einer bestimmten Reihenfolge ausgetauscht. Es sieht ähnlich wie ein Klassen- bzw. Objektdiagramm aus, beinhaltet aber Nachrichten, die zu den Assoziationen zugeordnet sind. Das Diagramm erlaubt also darzustellen, welche Nachrichten über welche Assoziationen abgebildet sind.
7. Interaktionsübersichtsdiagramm: Interaktionsübersichtsdiagramme weisen Ähnlichkeiten zu Aktivitätsdiagrammen auf. Sie beinhalten jedoch keine atomaren Aktionen, sondern nur Inline-Aktionen und referenzierte Aktionen. Typischerweise werden sie zur überblicksartigen Beschreibung des Interaktionsverhaltens eines Systems verwendet.
8. Zeitverlaufsdiagramm: Wenn die Darstellung von genauem Zeitverhalten für die Übergänge von Zuständen notwendig ist, kann ein Zeitverlaufsdiagramm verwendet werden. Das Diagramm beinhaltete eine X- und eine Y-Achse. Die Y-Achse zeigt die verschiedenen Beteiligten und die X-Achse die zeitlichen Zustandsänderungen.

Das richtige Diagramm für den richtigen Zweck

Jetzt haben wir die UML-Diagramme kennengelernt. Die Frage ist nun aber, wie man diese Diagramme am besten zur Beschreibung eines Softwaresystems einsetzt? Dazu möchte ich das 4+1 Sichtenmodell für Softwarearchitektur (The 4+1 View Model of Software Architecture) als Referenz nehmen. Dieses Modell wurde Anfang der 90er-Jahre von Philippe Kruchten geschaffen, um ein Softwaresystem aus den verschiedenen Blickpunkten unterschiedlicher Stakeholder zu schaffen. Dabei erlaubt dieses Modell verschiedene visuelle Repräsentationen und ist nicht an die Unified Modeling Language gebunden.

In der Kontextsicht (Logical View) wird die Funktionalität des Systems aus Endbenutzersicht beschrieben. Die Bausteinsicht (Development View) beschreibt den strukturellen Aufbau des Systems. Dynamische Aspekte des Systems werden in der Laufzeitsicht (Process View) beschrieben. Dies beinhaltet Prozesse, Zeitverhalten und Abläufe. Die physische Verteilung (Deployment) auf Rechnerknoten beschreibt die Verteilungssicht (Physical View). Die fünfte Sicht ist die Anwendungsfallsicht (Scenarios) und wird als Zusatz gesehen, Kontext zu geben. Die Inhalte sind oftmals bereits in anderen Sichten enthalten. Deshalb ist die Anwendungsfallsicht redundant und wird als „+1“-Sicht bezeichnet.

In der nachfolgenden Tabelle sehen Sie, welche UML-Diagramme sich am besten für welche Sicht eignen.

Architektursicht	Diagramme
Anwendungsfallsicht	Anwendungsfalldiagramm
Kontextsicht	Anwendungsfall- oder Komponentendiagramm
Bausteinsicht	Komponenten- und Klassendiagramm
Laufzeitsicht	Aktivitäts- und Sequenzdiagramm
Verteilungssicht	Verteilungsdiagramm

Bei der Kontextsicht ist Vorsicht angebracht. Typischerweise möchte man in diesem Diagramm das System, Akteure und externe Systeme darstellen. Anwendungsfall- und Komponentendiagramme können zwar dafür verwendet werden, aber beide Diagrammarten haben hier nur beschränkte Syntaxelemente zur Verfügung. In der Praxis werden deshalb auch gerne eine Mischung von verschiedenen Diagrammarten verwendet.

Alternativen zu UML

Neben der Unified Modeling Language gibt es noch weitere Möglichkeiten zur Modellierung von Software Systemen. Wir wollen uns hier in Kürze einige populäre Alternativen zu UML ansehen. Streng genommen zählen diese Alternativen nicht immer als Modellierungssprachen, werden in der Praxis aber oft als solche verwendet.

C4 Model

Das C4 Model wurde von Simon Brown geschaffen, um eine schlanken grafischen Notation für Softwarearchitekturen zu schaffen. C4 basiert dabei auf Grundlage der UML und des 4+1 Sichtenmodells. Es werden vier Diagrammebenen definiert, die C4 ihren Namen geben: Context, Containers, Componentes und Code. Diese vier Ebenen stellen eine schrittweise Dekomposition der Software da. Die vier Diagrammebenen erfüllen folgende Rolle:

• Context (Ebene 1): Diese Ebene zeigt den Umfang eines Systems und die Beziehung zu seinen Benutzern sowie den Fremdsystemen.
• Container (Ebene 2): Das System wird in Container (Anwendung oder Data Store) zerlegt.
• Component (Ebene 3): Die Container werden weiter in Components unterteilt. Dies ist im einfachsten Fall eine logische Gruppe von zusammengehörigen Klassen.
• Code (Ebene 4): In der letzten Ebene können Details für die Implementierung bereitgestellt werden. C4 definiert auf dieser Ebene keine eigenen Elemente, sondern empfiehlt die Verwendung von UML-Klassendiagramme oder Entity Relationship Diagramme.

Die Notationselemente sind dabei absichtlich einfach gehalten. C4 macht auch keine Vorschriften zu den genauen grafischen Elementen wie Formen, Layout oder Farben. Jedes Team kann seinen eigenen Satz an konkreten grafischen Elementen schaffen. Man kann C4 deshalb genauso mit Elementen aus der UML entwerfen. Zur Notation werden folgende Empfehlungen gemacht.

Diagramme

• Jedes Diagramm soll einen eindeutigen Titel haben.
• Jedes Diagramm soll über eine Legende verfügen, die die verwendete Notation (Formen, Farben, Linien, etc.) beschreibt.
• Akronyme und Abkürzungen sollen den Lesern verständlich sein oder ansonsten in der Legende erklärt werden.

Elemente

• Der Elementtyp sollte explizit spezifiziert werden, z. B. Person, Softwaresystem, Container oder Komponente.
• Jedes Element sollte eine kurze Beschreibung haben, die auf einem Blick dessen Zuständigkeiten ersichtlich macht.
• Jeder Container oder Component soll explizit eine Technology spezifizieren.

Beziehungen

• Jede Linie repräsentiert eine unidirektionale Beziehung.
• Jede Linie sollte beschriftet sein. Die Beschriftung sollte dabei konsistent mit Richtung und Zweck der Beziehung sein (z.B. Abhängigkeit oder Datenfluss). Versuche so genau wie möglich zu sein und vermeide die Verwendung eines einzelnen Wortes wie „verwendet“.
• Beziehungen zwischen Container sollen mit der Technologie bzw. dem Protokoll beschriftet werden, da diese in der Regel eine prozessübergreifende Kommunikation darstellt.

SysML

Die System Modeling Language (SysML) ist eine auf UML basierende Modellierungssprache für Systems Engineering und wird ebenfalls von der OMG entwickelt und gepflegt. SysML besteht aus einer Untermenge der UML-Diagramme, die teilweise angepasst sind. Zusätzlich gibt es noch einige Diagramme, die in SysML neu definiert werden.

Originaldiagramme aus der UML

• Anwendungsfalldiagram
• Sequenzdiagram
• Zustandsdiagram
• Paketdiagramm

Modifizierte Diagramme aus der UML

• Aktivitätsdiagramm
• Blockdefinitionsdiagramm (basierend auf Klassendiagramm)
• Internes Blockdiagramm (basierend auf Kompositionsstrukturdiagramm)

Neue Diagramme in SysML

• Anforderungsdiagramm
• Zusicherungsdiagramm

Lasssim Diagramme

Die Lasssim Diagramme stammen von Simon Lasselsberger und sind seine Best Practice Architekturdiagramme zu gestalten. Er lässt dabei seine Erfahrungen als selbstständiger Softwarearchitekt und ehemaliger Lead System Architect von Runtastic einfließen. Er will mit seinen Diagrammen dabei die folgenden 5 Ziele erreichen:

• Einfach zu lesen: Das Zielpublikum soll die Diagramme innerhalb weniger Sekunden verstehen.
• Für sich stehend: Die Hauptbestandteile müssen ohne weitere Erklärung aussagekräftig sein.
• Schnell zu erstellen: Diagramme müssen schnell erstellbar sein.
• Einfach zu warten: Dinge ändern sich, deshalb muss es einfach sein, auch die Diagramme zu ändern.
• Schön: Diagramme sind Marketingmaterial für technische Ideen.

Zur Erreichung dieser Ziele definiert er einige Richtlinien, die unter anderem folgendes beinhalten:

• Zeige nur Strukturen.
• Verwende Konsistente Symbole.
• Lasse Verbindungen weg, wenn diese für das Verständnis nicht essentiell sind.
• Erkläre alle deine Verbindungen.
• Verwende Pfeilspitze nur, wenn diese eine spezielle Bedeutung haben.

Übrigens ist „Lasssim Diagramme“ keine offizielle Bezeichnung. Da Simon laut eigenen Aussagen keine offizielle Bezeichnung für seine Architekturdiagramme hat, werde ich sie bis auf Widerruf weiterhin so nennen. 😉

Flussdiagramme, Entity Relationship Diagram, etc.

Es gibt viele weitere Diagrammarten, die für sich genommen keine vollständige Modellierung eines Systems zulassen. In Kombination kann man damit aber ein System ausreichend Modellieren. Beispielsweise können Entity Relationship Diagramme verwendet werden, um Datenmodellierung zu betreiben und Blockdiagramme können verwendet werden, um die wesentliche Systemstrukturen zu zeigen. Diese können mit Flussdiagramme und Message Sequence Charts kombiniert werden, um das Verhalten des Systems zu beschreiben.

Modellierungssprachen für andere Architekturdomänen

Die UML eignet sich in erster Linie für die Beschreibung von Anwendungsarchitekturen. Für andere Architekturdomänen gibt es weitere Modellierungssprachen, die besser geeignet sind. Diese sollen hier eine kurze Erwähnung und oberflächliche Beschreibung erhalten.

Business Process Model & Notation (BPMN)

Die BPMN ist eine grafische Modellierungssprache für Business Architecture (Geschäftsarchitektur), die auch im Bereich von Prozessmanagement und Wirtschaftsinformatik verwendet wird. Mithilfe der BPMN können Geschäftsprozesse und Arbeitsabläufe erfasst werden. Das Aussehen der erstellten Diagramme ähnelt dabei den Aktivitätsdiagrammen der UML.

ArchiMate

Um Enterprise Architecture (Unternehmensarchitektur) zu modellieren, ist ArchiMate ein etablierter Standard, der auf IEEE 1471 basiert und diesen inzwischen abgelöst hat. Die Konzepte der ArchiMate-Sprache sind im sogenannten ArchiMate Framework zusammengefasst. Dort wird die Unternehmensarchitektur in die Geschäfts-, Anwendungs- und Technologieschicht unterteilt. ArchiMate bietet eine einheitliche Modellierungssprache, um die Erstellung und den Betrieb von Geschäftsprozessen, Organisationsstrukturen, Informationsflüssen, IT-Systemen und technischer Infrastruktur zu beschreiben.

Abschluss

Dieser Blogartikel soll eine Übersicht über die UML geben und die für die Softwareentwicklung relevantesten Diagramme darstellen. Zu jedem einzelnen Diagramm gibt es noch viel mehr zu sagen und ein Blogartikel alleine wird aus Ihnen noch keinen UML-Profi machen.

Um wirklich den Mehrwert von Modellierung zu erfahren, ist der Transfer dieses Wissens in die Praxis essentiell. Hierbei gibt es viele Stolpersteine und Herausforderungen, angefangen vom Tooling, über die verwendeten Technologien, organisatorische Randbedingungen und noch vieles mehr.

Bei diesen Transferprozess unterstütze ich Sie gerne, damit er effizient und wertschöpfend wird! Lesen Sie mehr über meine Leistungen im Bereich Modellierung und Dokumentation oder nehmen Sie gleich mit mir Kontakt auf.