SysML oder UML: wann ein Softwaremodell nicht mehr reicht
Solange ihr Software beschreibt, ist UML die passende Sprache. Sobald Hardware, physikalische Größen und nachzuweisende Anforderungen im selben Modell stehen sollen, wird SysML zur eigentlichen Antwort.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Wahl der Notation ersetzt die Frage, wofür das Modell gebraucht wird
Die Frage nach SysML oder UML taucht meistens auf, wenn ein Vorhaben eine Größe erreicht hat, bei der Absprachen im Kopf nicht mehr reichen. Dann wird ein Werkzeug angeschafft, eine Notation ausgewählt und mit dem Zeichnen begonnen. Was in diesem Ablauf fehlt, ist die Frage davor: Wer soll das Modell lesen, welche Entscheidung soll es tragen und was passiert damit, wenn sich die Wirklichkeit ändert. Ohne diese Antworten entsteht eine Sammlung von Bildern, die zwei Monate nach der Erstellung nicht mehr stimmt.
In die UML-Richtung falsch entschieden merkt man in Vorhaben mit Hardware. Ein Klassendiagramm kann einen Sensor darstellen, aber es kann nicht ausdrücken, dass er zwölf Volt braucht, dass er eine Anforderung aus dem Lastenheft erfüllt und dass ein bestimmter Versuch diese Erfüllung nachweist. Diese Verknüpfungen wandern dann in Tabellen daneben, und ab da gibt es zwei Wahrheiten, von denen regelmäßig eine veraltet ist.
In die SysML-Richtung falsch entschieden kostet Zeit und Wohlwollen. Ein reines Softwareteam bekommt eine Notation mit zusätzlichen Konstrukten, die es nicht braucht, ein Werkzeug, das mehr verlangt als ein Zeichenprogramm, und eine Einarbeitung, die sich am Ergebnis nicht auszahlt. Danach gilt Modellierung im Haus als Überbau, und diese Einschätzung ist schwerer zu korrigieren als jedes Modell.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Unterschiede, die sich in der Arbeit bemerkbar machen
Verglichen werden nicht Diagrammarten, sondern das, was die beiden Sprachen im Alltag leisten und was sie dafür verlangen. Wichtig zum Verständnis: SysML setzt in seiner verbreiteten Fassung auf UML auf, deshalb geht es nicht um ein Entweder-oder auf der grünen Wiese.
UML
die Sprache für den Entwurf von Software, mit Struktur- und Verhaltensdiagrammen und starker Nähe zum Code
SysML
ein Profil auf UML für die Beschreibung ganzer Systeme, mit Anforderungen, physikalischen Größen und Zuordnung als eigenen Mitteln
| Entscheidungsfrage | UML | SysML |
|---|---|---|
| Was ist der Gegenstand, den ihr beschreiben könnt? | Kommt darauf an Software, und das sehr gut: Klassen, Zustände, Abläufe, Komponenten und Schnittstellen. Alles, was nicht Software ist, muss über Umwege dargestellt werden, und diese Umwege versteht nur, wer sie selbst gebaut hat. | Stärke Das System als Ganzes. Ein Baustein kann eine Baugruppe sein, eine Software, ein mechanisches Teil oder eine Rolle, und die Sprache macht dabei keinen Unterschied. Genau dafür wurde der Baustein als allgemeineres Gegenstück zur Klasse eingeführt. |
| Wie werden Anforderungen im Modell geführt? | Schwäche Gar nicht. Anforderungen sind in der Sprache nicht vorgesehen, sie leben in einem Textdokument oder einem eigenen Werkzeug daneben. Die Verbindung zwischen Anforderung und Entwurf entsteht dann von Hand und veraltet entsprechend schnell. | Stärke Als eigene Elemente mit eigenem Diagramm, verknüpft über Beziehungen, die ausdrücken, dass ein Baustein eine Anforderung erfüllt, dass ein Versuch sie nachweist oder dass sie aus einer anderen abgeleitet ist. Damit lässt sich die Frage, was womit belegt ist, aus dem Modell heraus beantworten. |
| Wie beschreibt ihr physikalische Größen und ihre Zusammenhänge? | Schwäche Es gibt keinen vorgesehenen Ort dafür. Werte mit Einheiten landen als Text in Kommentaren oder in einer Tabelle daneben, und ein Zusammenhang zwischen zwei Größen lässt sich nicht ausdrücken, sondern nur beschreiben. | Stärke Werte tragen Einheiten und Wertebereiche, und das Parametrikdiagramm hält Gleichungen zwischen ihnen fest. Damit steht eine Massen- oder Leistungsbilanz im Modell und nicht in einer Tabelle daneben, und passende Werkzeuge können sie auswerten. |
| Wie nah kommt das Modell an den Code? | Stärke Sehr nah. Klassendiagramme lassen sich in beide Richtungen mit Code abgleichen, Zustandsdiagramme in Code überführen, und für Softwareentwickler ist die Notation vertraut, weil sie dieselben Begriffe benutzt. | Kommt darauf an Der Zweck ist ein anderer. Ein Systemmodell beschreibt, was gebaut werden soll, und der Übergang in die Software geschieht üblicherweise über einen Entwurf auf UML-Ebene. Wer Codegenerierung als Hauptzweck sucht, ist hier falsch. |
| Wie hoch sind Einarbeitung und Werkzeugaufwand? | Kommt darauf an Die Grundlagen sitzen in wenigen Tagen, und für die drei bis vier Diagrammarten, die im Alltag zählen, gibt es viel Material. Werkzeuge reichen vom einfachen Zeichnen bis zum vollwertigen Modellspeicher, und man kann klein anfangen. | Schwäche Deutlich höher. Zur Notation kommen ein Werkzeug mit Modellspeicher, eine Vereinbarung darüber, wie ihr modelliert, und die Frage, wie das Modell versioniert und im Team bearbeitet wird. Ohne eine Person, die das schon einmal gemacht hat, dauert der Einstieg spürbar länger. |
| Wo ist die Sprache in der Praxis verbreitet? | Stärke In der Softwareentwicklung überall dort, wo Entwürfe festgehalten werden, und in der Ausbildung fest verankert. In vielen Teams allerdings reduziert auf wenige Diagrammarten, und das ist kein Mangel, sondern vernünftig. | Kommt darauf an Stark in Branchen, in denen Systeme aus Hardware und Software entstehen und Nachweise verlangt werden, also im Fahrzeugbau, in der Luft- und Raumfahrt, in der Medizintechnik und im Anlagenbau. Außerhalb dieser Felder ist sie selten anzutreffen. |
Was ist der Gegenstand, den ihr beschreiben könnt?
Software, und das sehr gut: Klassen, Zustände, Abläufe, Komponenten und Schnittstellen. Alles, was nicht Software ist, muss über Umwege dargestellt werden, und diese Umwege versteht nur, wer sie selbst gebaut hat.
Das System als Ganzes. Ein Baustein kann eine Baugruppe sein, eine Software, ein mechanisches Teil oder eine Rolle, und die Sprache macht dabei keinen Unterschied. Genau dafür wurde der Baustein als allgemeineres Gegenstück zur Klasse eingeführt.
Wie werden Anforderungen im Modell geführt?
Gar nicht. Anforderungen sind in der Sprache nicht vorgesehen, sie leben in einem Textdokument oder einem eigenen Werkzeug daneben. Die Verbindung zwischen Anforderung und Entwurf entsteht dann von Hand und veraltet entsprechend schnell.
Als eigene Elemente mit eigenem Diagramm, verknüpft über Beziehungen, die ausdrücken, dass ein Baustein eine Anforderung erfüllt, dass ein Versuch sie nachweist oder dass sie aus einer anderen abgeleitet ist. Damit lässt sich die Frage, was womit belegt ist, aus dem Modell heraus beantworten.
Wie beschreibt ihr physikalische Größen und ihre Zusammenhänge?
Es gibt keinen vorgesehenen Ort dafür. Werte mit Einheiten landen als Text in Kommentaren oder in einer Tabelle daneben, und ein Zusammenhang zwischen zwei Größen lässt sich nicht ausdrücken, sondern nur beschreiben.
Werte tragen Einheiten und Wertebereiche, und das Parametrikdiagramm hält Gleichungen zwischen ihnen fest. Damit steht eine Massen- oder Leistungsbilanz im Modell und nicht in einer Tabelle daneben, und passende Werkzeuge können sie auswerten.
Wie nah kommt das Modell an den Code?
Sehr nah. Klassendiagramme lassen sich in beide Richtungen mit Code abgleichen, Zustandsdiagramme in Code überführen, und für Softwareentwickler ist die Notation vertraut, weil sie dieselben Begriffe benutzt.
Der Zweck ist ein anderer. Ein Systemmodell beschreibt, was gebaut werden soll, und der Übergang in die Software geschieht üblicherweise über einen Entwurf auf UML-Ebene. Wer Codegenerierung als Hauptzweck sucht, ist hier falsch.
Wie hoch sind Einarbeitung und Werkzeugaufwand?
Die Grundlagen sitzen in wenigen Tagen, und für die drei bis vier Diagrammarten, die im Alltag zählen, gibt es viel Material. Werkzeuge reichen vom einfachen Zeichnen bis zum vollwertigen Modellspeicher, und man kann klein anfangen.
Deutlich höher. Zur Notation kommen ein Werkzeug mit Modellspeicher, eine Vereinbarung darüber, wie ihr modelliert, und die Frage, wie das Modell versioniert und im Team bearbeitet wird. Ohne eine Person, die das schon einmal gemacht hat, dauert der Einstieg spürbar länger.
Wo ist die Sprache in der Praxis verbreitet?
In der Softwareentwicklung überall dort, wo Entwürfe festgehalten werden, und in der Ausbildung fest verankert. In vielen Teams allerdings reduziert auf wenige Diagrammarten, und das ist kein Mangel, sondern vernünftig.
Stark in Branchen, in denen Systeme aus Hardware und Software entstehen und Nachweise verlangt werden, also im Fahrzeugbau, in der Luft- und Raumfahrt, in der Medizintechnik und im Anlagenbau. Außerhalb dieser Felder ist sie selten anzutreffen.
Was passt wann
- Wenn ihr Software entwerft und Anforderungen in einem eigenen Werkzeug verwaltet
- bleibt bei UML und beschränkt euch auf die Diagrammarten, die eine konkrete Frage beantworten.
- Wenn Hardware und Software gemeinsam entstehen und ihr belegen müsst, welche Anforderung wodurch erfüllt und wodurch nachgewiesen wird
- nehmt SysML und plant Werkzeug, Modellierungsvereinbarung und Einarbeitung als eigenen Posten ein.
- Wenn ihr Systemmodellierung zum ersten Mal einführt
- fangt mit einem einzelnen Vorhaben und wenigen Diagrammarten an und benennt vorher, wer das Modell pflegt und bei welchem Anlass.
Fünf Fragen führen zur passenden Notation
- 01 Besteht der Gegenstand nur aus Software oder auch aus Hardware?
- 02 Sollen Anforderungen im Modell stehen und mit Bausteinen verknüpft sein?
- 03 Kommen physikalische Größen mit Einheiten und Zusammenhängen vor?
- 04 Muss gegenüber einer Prüfstelle nachgewiesen werden, was was erfüllt?
- 05 Wer pflegt das Modell, und bei welchem Anlass wird es aktualisiert?
Was ihr klärt, bevor ihr euch für eine Notation entscheidet
Sechs Punkte, und der erste ist der, der am häufigsten übersprungen wird. Wer den Zweck des Modells nicht benennen kann, bekommt unabhängig von der Notation eine Sammlung veralteter Bilder.
Den Zweck des Modells in einem Satz benennen
Soll es eine Abnahme tragen, eine Schnittstelle zwischen Teams festlegen, eine Architekturentscheidung begründen oder einen Nachweis gegenüber einer Prüfstelle stützen? Aus dem Zweck folgt, welche Diagramme ihr braucht, und meistens sind es sehr wenige.
Prüfen, ob nur Software beschrieben wird
Wenn der Gegenstand vollständig aus Software besteht und Anforderungen anderswo verwaltet werden, reicht UML. Sobald Hardware, mechanische Teile, Energie oder Menschen als Teil des Systems auftauchen, fehlen dort die Mittel, und ihr baut sie sonst selbst nach.
Klären, wo Anforderungen leben sollen
Wenn Anforderungen ohnehin in einem eigenen Werkzeug stehen und dort verwaltet werden, braucht ihr das Anforderungsdiagramm nicht zwingend. Wenn sie im Modell selbst geführt und mit Bausteinen und Nachweisen verknüpft werden sollen, ist das der stärkste einzelne Grund für SysML.
Physikalische Größen ernst nehmen
Sobald Werte mit Einheiten, Toleranzen und Zusammenhängen im Modell stehen sollen, etwa Massen, Leistungen oder Laufzeiten, gibt es in UML dafür keinen vorgesehenen Ort. In SysML gibt es ihn, und daran hängt auch die Möglichkeit, Zusammenhänge rechnen zu lassen.
Das Werkzeug vor der Notation festlegen
Eine Notation ohne Werkzeug ist ein Zeichenstil. Was ihr braucht, ist ein Modellspeicher, in dem ein Element einmal existiert und in mehreren Diagrammen auftaucht, damit eine Änderung überall wirkt. Klärt zusätzlich, wie das Modell versioniert wird und wie zwei Leute gleichzeitig daran arbeiten.
Mit wenigen Diagrammarten anfangen
Beide Sprachen bieten mehr an, als ein Team im Alltag benutzt. Fangt mit drei bis vier Arten an, die ihr wirklich braucht, und ergänzt erst, wenn eine konkrete Frage sich damit nicht beantworten lässt. Vollständigkeit ist kein Ziel.
Die Pflege von Anfang an mitplanen
Legt fest, wer das Modell aktualisiert, bei welchem Anlass und wer prüft, ob es noch stimmt. Ein Modell ohne benannte Zuständigkeit veraltet innerhalb weniger Wochen, und ein veraltetes Modell ist schlechter als gar keines, weil ihm noch geglaubt wird.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
SysML ist ein Profil auf UML, kein Gegenentwurf
Die verbreitete Fassung von SysML ist als Profil auf UML definiert. Ein Profil erweitert eine Sprache, ohne sie zu ersetzen: Es übernimmt Teile unverändert, schränkt andere ein und ergänzt eigene Konstrukte. Praktisch heißt das, dass ein Teil der Diagramme aus UML unverändert weiterverwendet wird, ein weiterer Teil angepasst ist und zwei Arten hinzukommen, nämlich das Anforderungsdiagramm und das Parametrikdiagramm. Wer UML kennt, findet sich deshalb schnell zurecht.
Die wichtigste inhaltliche Verschiebung steckt im Baustein, der an die Stelle der Klasse tritt. Eine Klasse trägt die Vorstellung von Software in sich, ein Baustein nicht: Er kann eine Baugruppe sein, eine Software, ein Bauteil, eine Flüssigkeit oder eine Rolle. Dazu kommen Ports, über die Bausteine miteinander verbunden sind, und zwar nicht nur für Aufrufe, sondern auch für Stoff- und Energieflüsse.
Die Nachfolgeversion ist inzwischen verabschiedet: Die zuständige Standardisierungsorganisation führt SysML 2.0 seit September 2025 als formale Spezifikation. Sie geht einen anderen Weg, denn sie ist nicht mehr als Profil auf UML gebaut, sondern hat eine eigene Grundlage und eine Textnotation neben der grafischen. In Werkzeugen und laufenden Projekten dominiert weiterhin die 1.x-Reihe. Für eine Entscheidung heute ist das kein Hindernis, es ist aber ein guter Grund, ein Werkzeug zu wählen, dessen Anbieter diesen Weg mitgeht, und Modellierungsvereinbarungen so zu schreiben, dass sie nicht an einer Werkzeugeigenheit hängen.
Was von UML im Alltag tatsächlich benutzt wird
Die Norm kennt eine ganze Reihe von Diagrammarten, aufgeteilt in solche für Struktur und solche für Verhalten. In der Praxis benutzen die meisten Teams vier davon regelmäßig: das Klassendiagramm für den fachlichen Aufbau, das Sequenzdiagramm für den Ablauf zwischen Beteiligten, das Zustandsdiagramm für alles mit Lebenszyklus und das Aktivitätsdiagramm für Abläufe mit Verzweigungen. Der Rest kommt anlassbezogen dazu oder gar nicht.
Das ist kein Versäumnis, sondern eine vernünftige Beschränkung. Ein Diagramm hat den Zweck, eine Frage zu beantworten, und wenn niemand die Frage stellt, die ein Verteilungsdiagramm beantwortet, dann braucht es keines. Teams, die sich vornehmen, ein Vorhaben vollständig zu modellieren, produzieren regelmäßig viel Material, von dem wenig gelesen und noch weniger gepflegt wird.
Für die Einführung hat sich deshalb ein anderes Vorgehen bewährt: Sammelt die Fragen, die in eurem Vorhaben tatsächlich immer wieder auftauchen, und wählt je Frage ein Diagramm. Typisch sind drei bis fünf. Wenn später eine neue Frage dazukommt, kommt ein weiteres Diagramm dazu, und zwar mit einem benannten Adressaten, der es lesen soll.
Anforderungen im Modell: der eigentliche Unterschied
Der stärkste einzelne Grund für SysML ist die Möglichkeit, Anforderungen als Modellelemente zu führen und sie mit dem zu verbinden, was sie erfüllt und was ihre Erfüllung nachweist. Damit lassen sich Fragen beantworten, die sonst Handarbeit sind: Welche Anforderungen sind noch keinem Baustein zugeordnet? Für welche gibt es keinen Nachweis? Was hängt an einer Anforderung, die sich gerade geändert hat?
Diese Fragen sind in regulierten Bereichen keine Kür. Wo gegenüber einer Prüfstelle oder einem Auftraggeber belegt werden muss, dass jede Anforderung umgesetzt und geprüft wurde, entsteht die Nachweisführung sonst in Tabellen, die jemand von Hand pflegt. Ein Modell, in dem diese Verbindungen als Beziehungen stehen, erzeugt die Übersicht auf Knopfdruck und ist bei jeder Änderung sofort wieder aktuell.
Zwei Einschränkungen gehören dazu. Erstens ersetzt das Modell nicht die Arbeit an den Anforderungen selbst: Eine unklar formulierte Anforderung wird durch eine Verknüpfung nicht besser, und die Formulierung ist eine eigene Disziplin mit eigenen Regeln. Zweitens ist die Verbindung zu einem vorhandenen Anforderungswerkzeug eine Frage, die früh geklärt gehört, denn wenn Anforderungen an zwei Orten geführt werden, entstehen genau die zwei Wahrheiten, die ihr vermeiden wolltet.
Werkzeuge und was sie erzwingen
Der Unterschied zwischen einem Zeichenprogramm und einem Modellierungswerkzeug ist der Modellspeicher. Dort existiert ein Element genau einmal und erscheint in mehreren Diagrammen; eine Umbenennung wirkt überall, und eine Auswertung über das Modell ist möglich. In einem Zeichenprogramm existiert dasselbe Element so oft, wie es gezeichnet wurde, und ab der zweiten Änderung stimmen die Bilder nicht mehr überein.
Daran hängen zwei Fragen, die vor der Anschaffung geklärt gehören. Die erste ist die Zusammenarbeit: Wie arbeiten zwei Leute gleichzeitig am selben Modell, und was passiert, wenn beide dasselbe Element ändern? Die zweite ist die Versionierung: Ein Modell in einem eigenen Format lässt sich nicht sinnvoll zeilenweise vergleichen, weshalb die Werkzeuge dafür eigene Mechanismen mitbringen, die man kennen und einrichten muss.
Für den Einstieg gilt derselbe Rat wie überall: Erst das Vorhaben, dann das Werkzeug. Ein kleines, echtes Vorhaben mit wenigen Diagrammarten zeigt innerhalb weniger Wochen, ob die Zusammenarbeit funktioniert und ob das Modell tatsächlich gelesen wird. Eine unternehmensweite Einführung vor dieser Erfahrung endet häufig mit einer teuren Lizenz und einem Modell, das drei Leute pflegen und niemand benutzt.
Woran Modellierung im Alltag scheitert
Der häufigste Grund ist ein fehlender Adressat. Ein Diagramm, das niemand liest, wird nicht gepflegt, und ein ungepflegtes Modell wird nach kurzer Zeit gefährlich, weil ihm noch geglaubt wird. Deshalb ist die nützlichste Frage vor jedem neuen Diagramm die nach der Person, die es lesen soll, und nach der Entscheidung, die es tragen wird.
Der zweite Grund ist die fehlende Verbindung zum Rest der Arbeit. Wenn das Modell neben Code, Anforderungen und Tests herläuft, ohne dass eine Änderung an einer Stelle die anderen berührt, driftet es zwangsläufig. Wirksam sind hier kleine, unspektakuläre Maßnahmen: das Modell in dieselbe Versionsverwaltung wie den Code, ein Review, bei dem auch das Modell angesehen wird, und ein fester Anlass, zu dem es aktualisiert wird.
Der dritte Grund ist ein Anspruch auf Vollständigkeit. Ein Modell muss nicht alles enthalten, es muss die Fragen beantworten, für die es gebaut wurde. Teams, die das akzeptieren, kommen mit wenigen Diagrammen weit und pflegen sie tatsächlich. Teams, die alles modellieren wollen, produzieren viel und pflegen nichts, und danach gilt die Methode im Haus als gescheitert, obwohl es der Anspruch war.
Dazu passende Kurse
Wenn Hardware und Software bei euch gemeinsam entstehen, sind SysML-Kurse für die modellbasierte Systementwicklung der direkte Weg von der Notation zum ersten tragfähigen Modell.
Bleibt es bei reiner Software, decken UML-Kurse für Softwareentwurf und Datenmodellierung genau die Diagrammarten ab, die im Alltag gebraucht werden.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr umfangreicher Überblick über Zusammenhänge und Anwendungsbereiche. Sehr zu empfehlen.
Effektives, gemeinsames Erarbeiten der Aufgaben mit vielen praktischen Tipps.
Sehr guter Trainer und gute Aufbereitung der Inhalte und auch eingehen auf Fragen der Beteiligten.
Häufige Fragen
Ist SysML einfach UML mit anderem Namen?
Können wir mit UML anfangen und später auf SysML wechseln?
Brauchen wir SysML, wenn wir ohnehin ein Anforderungswerkzeug haben?
Wie viele Diagrammarten brauchen wir wirklich?
Was ist mit der nächsten Version von SysML?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Programmierung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Am eigenen System entscheiden statt an Beispielen
Bei cmt gehst du die Notation an einem System durch, das dem eigenen ähnelt, und siehst dabei, welche der zusätzlichen Mittel aus SysML ihr tatsächlich braucht und welche ihr euch sparen könnt.
Passt dazu
- Anforderungen so aufschreiben, dass Entwicklung und Test dasselbe verstehen
- AUTOSAR Classic oder Adaptive: welche Plattform euer Steuergerät braucht
- Code Reviews einführen, ohne dass sie zum Nadelöhr werden
- Lohnt sich ISTQB Foundation Level für euer Testteam?