UML Diagrammtypen und Softwarearchitektur im Überblick

Klassendiagramme

Das Klassendiagramm oben zeigt einen Satz von Klassen, Schnittstellen (Interfaces) und Kollaborationen sowie deren Beziehungen. Andere Grafiken wie Diagramme können auch Klassenanmerkungen und Einschränkungen enthalten, Pakete enthalten oder auch aus diesen bestehen, welche dazu dienen, Elemente zur Modellierung in Teilen eines größeren Ganzen zu gruppen. Manchmal werden in Diagrammen auch Klassen an Orten platziert, wenn man speziell den Typ (möglicherweise dynamisch) einer Instanz anzeigen möchte.

Objektdiagramme

UML-Klassendiagramme werden verwendet, um statische Aspekte der Bausteine des Systems anzuzeigen. Die Interaktionsdiagramme dienen dazu, die dynamischen Aspekte des Systems anzuzeigen und bestehen aus diesen Vorkommen und gesendeten Nachrichten zwischen blockierten Objekten. Abbildung 1 der Objekte enthält einen Satz von Elementen, die im Klassendiagramm gefunden wurden. Deshalb drückt ein Objektdiagramm den statischen Interaktionsteil einer Instanz aus, bestehend aus Objekten, die ohne Programmnachrichten zwischen den Objekten arbeiten.

Interaktionen

In jedem System interagieren Objekte, wenn Nachrichten übermittelt werden. Die Interaktion ist ein Verhalten, das einen Satz von Nachrichten enthält, die von einem Satz von Objekten innerhalb eines bestimmten Kontextes und Zwecks ausgetauscht werden.

Anwendungsfalldiagramme

Dieses zeigt einen Satz von Anwendungsfällen und Akteuren (wie spezielle Klassen) sowie Beziehungen. Sie decken den statischen Blick der Anwendungsfälle ab und sind besonders wichtig für das Modell und die Organisation des Verhaltens.

Zustandsdiagramme

Es zeigt eine Zustandsmaschine, bestehend aus Zuständen, Übergängen, Ereignissen und Aktivitäten. Diese schematischen Darstellungen decken die dynamischen Aspekte eines Systems ab und sind sehr wichtig bei der Modellierung des Verhaltens einer Schnittstelle, Klasse oder Zusammenarbeit.

Komponentendiagramme

Dieses zeigt oben die Organisation und Abhängigkeiten eines Satzes von Komponenten. Sie decken die Ansicht der statischen Implementierung ab und stehen in Beziehung zu Klassendiagrammen, wobei eine Komponente meist eine oder mehrere Klassen, Schnittstellen oder Kollaborationen beinhalten kann.

Architektur

Die Entwicklung eines Software-Systems muss aus verschiedenen Perspektiven betrachtet werden. Verschiedene Nutzer (Endverbraucher, Analysten, Entwickler, Integratoren, Projektleiter usw.) führen zu unterschiedlichen Zeitpunkten des Projektverlaufs unterschiedliche Aktivitäten aus, sodass die Ergebnisse zu verschiedenen Projektphasen unterschiedlich betrachtet werden können, abhängig von der jeweiligen Zeit. Die gesamte Architektur trifft erhebliche Entscheidungen über:

• Die Organisation des Systems
• Die Auswahl von Strukturelementen und Schnittstellen, durch die das System konstituiert wird
• Das Verhalten, wie es in den Komponenten und Kollaborationen spezifiziert wird
• Die Form der Elemente, deren Zusammensetzung und Verhalten progressiv größer werden
• Den architektonischen Stil, der diese Organisation führt: statische und dynamische Elemente, ihre Kollaborationen und ihre Zusammensetzung

Sequenzdiagramme

Ein Sequenzdiagramm betont die zeitliche Anordnung der Nachrichten. Abbildung 1 des Sequenzdiagramms zeigt zunächst die an der Interaktion beteiligten Objekte im oberen Teil des Diagramms entlang der X-Achse. Normalerweise stellt sich dar, dass das linke Objekt die Interaktion beginnt und die Objekte nach rechts hin untergeordnet sind. Unten werden die Nachrichten gebracht, welche diese Objekte senden und empfangen, beispielsweise in der Reihenfolge ihrer zeitlichen Sukzession bis nach unten. Dies bietet dem Betrachter eine klare visuelle Signale des Kontrollflusses im Laufe der Zeit.

Aktivitätsdiagramme

Ein Aktivitätsdiagramm zeigt Aktivitäten für sportliche beziehungsweise operative Abläufe. Die Ausführung ist eine atomare Aktivität innerhalb einer Zustandsmaschine. Schließlich produzieren einige Aktivitäten Maßnahmen, die als atomare Berechnungen ausführbar sind, den Systemzustand ändern oder den Wert eines Objekts entwickeln. Die Aktionen beinhalten auch andere Operationen wie Erstellung oder Zerstörung von Objekten, einfache Berechnungen wie die Auswertung eines Ausdrucks. Grafisch ist ein Diagramm eine Ansammlung von Knoten mit zahlreichen Aktivitäten und Bögen.

Übergänge

Ein Übergang findet statt, wenn eine Maßnahme oder Aktivität beendet ist und der Kontrollfluss unmittelbar zur nächsten Handlung oder Aktivität übergeht. Dieser Fluss, der mit Übergängen spezifiziert wird, zeigt den Weg von einem Zustand zum nächsten. In der UML wird ein Übergang durch eine Linie repräsentiert, die gerichtet ist.

Bifurkation

Sequenzielle Übergänge sind häufig, aber für einen Modell-Kontrollfluss nicht immer die einzige Lösung. Wie bei Flussdiagrammen kann es auch Gabelungen geben, die alternative Wege auf Basis boolescher Ausdrücke spezifizieren. Die Bifurkation wird mit einem Diamanten dargestellt. Eine Gabel kann ein oder mehrere Eingangs- und Ausgangsübergänge haben. Für jeden Ausgangsübergang gibt es einen booleschen Ausdruck, der nur beim Eintritt in die Bifurkation einmal bewertet wird. Die Wachen der Ausgangsübergänge dürfen sich nicht überschneiden (andernfalls wäre der Kontrollfluss-Modell zweideutig), müssen aber alle Möglichkeiten abdecken, da sonst die manuelle Steuerung unterbrochen würde.

Teilung und Vereinigung

Sequenzielle Übergänge und Bifurkationen sind die am häufigsten genutzten Wege in Aktivitätsdiagrammen. Es ist jedoch auch möglich, nebenläufige Verläufe zu finden, wenn man Arbeitsabläufe von Geschäftsprozessen speziell modelliert. In der UML wird hierfür ein Synchronisationsbalken eingesetzt, um die Teilung und Vereinigung dieser Kontrollflüsse zu spezifizieren. Ein Synchronisationsbalken wird als horizontale oder vertikale Linie repräsentiert.