Ist SysML zu kompliziert? Und wenn ja, was ist die Alternative?
Wenn es um Modellierungssprachen geht, ist die Reaktion der Menschen oft extrem: Es gibt Menschen, denen Modelle viel zu kompliziert sind; dann welche, die gerne mit Diagrammen arbeiten und diese als das Modell wahrnehmen; und solche, die die Modellierungssprachen in der Tiefe verstehen, und entsprechend komplexe Modelle bauen, die zwar beeindruckend, sind, jedoch von kaum jemanden verstanden und deswegen ignoriert werden.
Diese Situation macht es schwer, mit Modellen zu arbeiten und gleichzeitig alle Stakeholder mit ins Boot zu holen. Das ist schade, denn man kann mit Modellen unglaublich viel machen. Und Modelle ermöglichen auch agileres Arbeiten und besseres Reagieren auf Veränderungen. Doch was nützt das, wenn die Modelle von einem Großteil der Stakeholder abgelehnt wird? Selbst dann, wenn in gute Dokumentengenerierung und Schulungen investiert wird?
Bereits in der Vergangenheit wies ich darauf hin, dass selbst ein modernes Anforderungswerkzeug modelliert. Wenn wir verschiedene Entitäten haben (unterschiedliche Anforderungs-Typen) mit Beziehungen, dann haben wir ein Entity-Relationship-Modell (ER). Und mit einer modernen Entwicklungsplattform wie Jama oder gitHub können die Mitarbeiter in kurzer Zeit umgehen.
Die Sprache für Entity-Relationship-Modelle hat nur drei Sprachelemente: Entitäten, Beziehungen und Attribute
In der Praxis sind sich viele Nutzer gar nicht dessen bewusst. Sie wissen lediglich, dass es in ihrer Arbeitsumgebung ein Daten- oder Informationsmodell gibt.
Doch der Unterschied zwischen der Sprache für ein ER-Modell und einer Sprache wie UML oder SysML is gewaltig: Im ER-Modell gibt es eigentlich nur drei Sprachelemente: Entitäten, Beziehungen und Attribute, die in einem Diagrammtypen visualisiert werden können. Im Gegensatz dazu gibt es in der UML 13 Diagrammtypen und hunderte von Elementtypen, bei SysML sieht es ähnlich aus.
Gibt es einen Mittelweg?
ER-Modellierung ist weit verbreitet (auch wenn sich viele Nutzer dessen nicht bewusst sind) . Und auch wenn sich UML und SysML als standardisierte Sprachen etabliert haben, so ist die Nutzergruppe doch deutlich kleiner. Und ganz besonders, es sind oft nur die Spezialisten, die Modellieren, nicht alle Stakeholder.
Daher die Frage: Würde Modellierung erfolgreicher sein, wenn die Modellierungssprache nicht so kompliziert wäre? Mit großer Wahrscheinlichkeit ist die Antwort: Ja. Es gibt auch verschiedene Ansätze in die Richtung, zum Beispiel:
- Eingeschränkten Sprachumfang nutzen – Gerade bei UML und SysML ist es üblich, nur einen kleinen Teil der Sprachelemente zu nutzen.
- Profiling – Dies wird von UML und SysML unterstützt, um sie an spezifische Einsatzgebiete anzupassen
- Domänenspezifische Sprache – Ein Schritt weiter ist es, eine eigene Modellierungssprache zu entwickeln, welche die Sprache der Stakeholder aufgreift.
- Weitere Sprachen – Neben UML und SysML gibt es noch viele andere algemeine und spezialisierte Sprachen, wie FMC, ROOM oder BPMN.
UML und SysML haben zwei enorme Vorteile: Erstens werden sie von mehreren (!) kommerziellen Werkzeugen unterstützt, und zweitens werden sie an Hochschulen gelehrt.
Auch andere Sprachen werden natürlich gelehrt, und für fast jede Sprache gibt es zumindest einen Editor – oft kostenlos oder Open Source. Doch an die kritische Masse, die UML und SysML inzwischen haben, kommt zumindest zur Zeit keine andere Sprache dran.
Wie erreichen wir mehr Modellierung?
Meine Antwort auf diese Frage ist: Wir müssen den Mehrwert der Modellierung offensichtlicher machen und das Kosten-Nutzen-Verhältnis der Modellierung verbessern. Am Ende des Tages zählt das Ergebnis. Doch um heute zu einem positiven Ergebnis zu kommen, muss zuerst viel investiert werden, in Wissen, Erfahrung, Werkzeuge und Prozesse.
Weiterhin ist es eine Sache eine Sprache zu haben, eine andere diese auch benutzen zu können. Das richtige Vorgehen auszuwählen ist gar nicht so einfach. Hier vorgestellt hatte ich bereits das (nicht sonderlich weit verbreitete) ICONIX, das mit einer Untermenge von UML arbeitet. Dassault (ehem. No Magic/MagicDraw) hat eine eigene Methode für das Arbeiten mit SysML, MagicGrid. Einen Ähnlichen Ansatz verfolgt Thales, die nicht nur ein quelloffenes Werkzeug entwickelt haben (Capella), sondern auch eine Methode (Arcadia).
Doch von den oben aufgeführten Ansätzen, welches ist der Zielführende? Andere Sprachen, wie FMC, werden auch industriell eingesetzt. Profiling und die Einschränkung des Vokabulars von UML und SysML wird heute schon praktiziert. Und auch wenn das Erstellen von Domänenspezifischen Sprachen aufwendig ist, so ist es heute ein gutes Stück leichter, als es noch vor fünf Jahren der Fall war.
Was ist Ihre Meinung? In welche Richtung geht die Entwicklung? Gerne in den Kommentaren diskutieren!
Bildquelle: Capella
