UML & Systemmodellierung

Vom Problem zum Modell

UML steht für Unified Modeling Language. Ein Modell beschreibt einen ausgewählten Blick auf ein System. Entscheide zuerst, für wen du zeichnest und welche Frage das Diagramm beantwortet. UML ist keine Programmiersprache und kein Ersatz für Anforderungen oder Tests.

Nutzerziel → Anwendungsfall; Ablauf → Aktivität; Nachrichten → Sequenz; Typen → Klassen; Bereitstellung → Verteilung.

Klassen, Attribute und Operationen

Eine Klasse wird als Rechteck mit Name, Attributen und Operationen dargestellt. + bedeutet public, - private, # protected und ~ package. Ein Attribut kann name: Typ heißen, eine Operation name(parameter: Typ): Rückgabetyp. Eine Klasse ist ein Typ; ein Objekt ist eine konkrete Instanz.

Ticket
--
- status: String
--
+ schließen(): void

Assoziationen und Multiplizitäten

Eine Assoziation beschreibt eine fachliche Beziehung zwischen Instanzen. Die Multiplizität an einem Ende sagt, wie viele Instanzen dort zu einer Instanz am anderen Ende gehören können. 1 heißt genau eine, 0..1 höchstens eine, * beziehungsweise 0..* null bis beliebig viele und 1..* mindestens eine.

Benutzer 1 —— 0..* Ticket: Ein Benutzer kann viele Tickets erstellen; jedes Ticket gehört genau einem Benutzer.

Generalisierung, Aggregation und Komposition

Bei einer Generalisierung zeigt das hohle Dreieck vom spezialisierten Typ zum allgemeineren Typ. Eine leere Raute markiert eine gemeinsame Aggregation; die Raute liegt beim Ganzen, nicht beim Teil. Ihre genaue Semantik ist schwächer als die der Komposition und muss fachlich erläutert werden. Eine gefüllte Raute bezeichnet Komposition: Ein Teil gehört gleichzeitig höchstens einem Kompositum; seine Lebensdauer wird durch das Ganze verwaltet. Löschen des Ganzen löscht die noch zugehörigen Teile.

Admin —▷ Benutzer: Admin spezialisiert Benutzer. Auftrag ◆— Position: Auftrag ist das Ganze.

Anwendungsfälle und Systemgrenze

Akteure sind Rollen außerhalb des betrachteten Systems, auch andere Systeme können Akteure sein. Ein Anwendungsfall wird als Ellipse gezeigt und beschreibt ein fachliches Ziel aus Akteurssicht. Zeichne die Anwendungsfälle innerhalb einer benannten Systemgrenze und die Akteure außerhalb. Eine Anmeldung ist nur dann als eigener Anwendungsfall sinnvoll, wenn sie im betrachteten Modell ein relevantes Ziel oder eingebundenes Verhalten ist.

include und extend

include bindet Verhalten eines anderen Anwendungsfalls ein: Der gestrichelte Pfeil zeigt vom einbindenden zum eingebundenen Anwendungsfall. extend ergänzt unter bestimmten Bedingungen einen Basisanwendungsfall: Der Pfeil zeigt vom erweiternden zum Basisanwendungsfall. Beschreibe bei extend die Bedingung und gegebenenfalls den Erweiterungspunkt. include und extend sind keine zeitliche Ablaufreihenfolge.

Ticket erstellen --«include»--> Anmeldung prüfen
Zusatzinformation anzeigen --«extend»--> Ticket ansehen

Aktivitäten und Entscheidungen

Eine Aktivität modelliert Kontroll- und gegebenenfalls Objektflüsse. Aktionen sind abgerundete Rechtecke, der Start ist ein gefüllter Kreis und ein Aktivitätsende ein Kreis mit gefülltem Innenkreis. Eine Raute dient unter anderem als Entscheidung: Ausgehende Bedingungen wie [ja] und [nein] sollten eindeutige Alternativen bilden. Ein Merge führt alternative Pfade zusammen. Parallele Pfade erfordern Fork-/Join-Balken, nicht eine Entscheidung.

Start → Ticket prüfen → Vollständig? → [ja] bearbeiten / [nein] Angaben nachfordern

Sequenzen und Nachrichten

Eine Lebenslinie beschreibt einen Beteiligten, etwa objekt: Klasse. Zeit verläuft im Sequenzdiagramm von oben nach unten. Durchgezogene Nachrichten und gestrichelte Antworten verbinden Lebenslinien. Eine synchrone Aufrufnachricht wird üblicherweise mit gefüllter Pfeilspitze dargestellt, eine asynchrone mit offener Spitze. Der Editor nutzt offene Nachrichtenspitzen für einfache Kommunikationsskizzen; Aktivierungen, Fragmente und Selbstaufrufe müssen in einem vollständigen Sequenzmodell zusätzlich berücksichtigt werden.

benutzer → portal: Ticket senden
portal → db: Ticket speichern
db --> portal: Ticket-ID

Knoten, Artefakte und Bereitstellung

Ein Verteilungsdiagramm zeigt, auf welchen Knoten ein System läuft. Knoten können Geräte oder Ausführungsumgebungen sein, zum Beispiel «device» Client oder «executionEnvironment» JVM. Ein Artefakt ist ein konkretes auszulieferndes Ergebnis wie eine JAR-Datei. Kommunikationspfade verbinden Knoten. Eine «deploy»-Abhängigkeit zeigt vom Artefakt zum Zielknoten.

Client — HTTPS — Webserver — SQL/TLS — Datenbank
supportportal.jar --«deploy»--> Webserver

Ein Diagramm fachlich prüfen

Prüfe zuerst das Ziel des Modells. Sind alle geforderten Rollen, Elemente und Beziehungen enthalten? Stimmen Pfeilrichtung, Bedingungen und Multiplizitäten? Sind Begriffe konsistent und Annahmen erklärt? Ein hübsches Diagramm ist nicht automatisch fachlich korrekt. Die Werkstatt prüft ausgewählte Regeln und fünf konkrete Zeichenaufgaben; sie ist kein vollständiger UML-Validator.

Für FISI und FIAE einsetzen

Für Systemintegration sind Aktivitäten, Anwendungsfälle und Verteilung hilfreich, etwa für Supportprozesse, Anforderungen und die geplante Bereitstellung. In der Anwendungsentwicklung kommen Klassen und Sequenzen für Typen und Zusammenarbeit hinzu. Wähle nur Diagramme, die den konkreten Sachverhalt verständlicher machen; jede Ansicht braucht eine klare Aussage.

Mit der UML-Werkstatt arbeiten

Wähle eine Diagrammart und starte mit einer leeren Fläche oder einem Beispiel. Füge Elemente hinzu, bearbeite ihre Beschriftung und verbinde Start und Ziel. Elemente lassen sich ziehen oder über Positionsfelder und Pfeiltasten verschieben. Das aktuelle Diagramm bleibt in diesem Browser gespeichert. Lade FISIBase-UML-JSON herunter, um es wieder zu bearbeiten; SVG und PNG sind für die Dokumentation gedacht. Vorlagenwechsel und Löschungen können innerhalb der Sitzung rückgängig gemacht werden.