text: Seifenblase oder Problemlöser?
  12. Februar 2008 Chris Rupp und Carsten Pflug
  Dieser Artikel hinterfragt die Sinnhaftigkeit und vor allem auch die Umsetzbarkeit der SysML in der Praxis und versucht eine Antwort zu geben auf die Frage, ob die SysML wirklich ein Problemlöser ist oder doch eher nur ein netter Versuch ohne brauchbares Ergebnis. Dabei heben wir in diesem Artikel vor allem auf das Anforderungsdiagramm ab, das die Durchgängigkeit der Systementwicklung in den frühen Projektphasen gewährleisten soll.
  Die Probleme der Modellierungssprachen
  Die Unified Modeling Language (UML) ist als Modellierungssprache in der Softwareentwicklung weit verbreitet. Bildet sie doch meist einen Teil der Informatikerausbildung und gilt nun mal als internationaler Standard. Trotz aller Vorteile hat man durch den Einsatz einer Modellierungssprache nicht gleich eine Eier legende Wollmilchsau, die alles kann und alle bisherigen Probleme im Nichts verschwinden lässt. Denn auch die Modellierung hat ihre Grenzen. So ist zum Beispiel die Darstellung vieler nichtfunktionaler Anforderungen in einem Modell weiterhin ein Problem. Gelegentlich lassen sich Sachverhalte auf andere Weise als durch eine Modellierung viel schneller und mit weniger Aufwand dokumentieren, sodass es an manchen Stellen ratsam ist, nicht nur zu modellieren, sondern auch mit Prototypen zu arbeiten oder in Prosa zu spezifizieren.
  Ein weiteres Problem der Modellierungssprache ist die Traceability, die innerhalb des Modells an sich kein Problem ist. Interessanter wird das Thema, wenn wir über den Tellerrand der Modellierung hinausblicken. Sicherlich ist dies kein Problem, das durch die Modellierung entsteht. Vielmehr wird die Traceability immer etwas problematisch, wenn in einem Projekt mehrere Dokumentationsformen und dadurch verschiedene Tools zum Einsatz kommen.
  Die SysML
  Bereits seit einigen Jahren wird versucht, die oben genannten Probleme in den Griff zu bekommen. Da klar ist, dass mit der UML als bekanntester Vertreter der Modellierungssprachen keine Abhilfe geschaffen werden kann, muss nun etwas anderes her. Allerdings sollte es nicht vollkommen anders sein, sondern auf den bewährten Elementen der existierenden Modellierungssprachen aufsetzen. Das Ergebnis dieser Entwicklung ist die System Modeling Language (kurz SysML). Die SysML zählt zu den Profilen der UML. Demnach werden in der SysML Notationselemente und Mechanismen der UML verwendet und zusätzlich neue definiert die allerdings den Regeln des UML Metamodells nicht widersprechen dürfen, sonst wäre die SysML kein Profil der UML mehr.
  Abb. 1: Aus der UML entstand die SysML
  Dies bringt einige Vorteile für die SysML mit sich: Für die Anwender, welche die UML bereits kennen, bedeutet die Einarbeitung in die SysML nur einen sehr geringen Aufwand, für die SysML müssen keine vollständig neuen Tools entwickelt werden, meist reicht ein kleines Addon für ein bestehendes UML-Tool. Und Erfahrungen mit der UML können in die Anwendung der SysML mit einfließen und umgekehrt.
  Die SysML ist nicht eine von Grund auf neu erstellte Modellierungssprache, daher kann sie aus dem reichhaltigen Angebot der UML schöpfen. So verwendet die SysML das Use Case Diagram, Zustandsdiagramm, Aktivitätsdiagramm, Sequenzdiagramm und Paketdiagramm. Auch das Klassendiagramm und das Kompositionsstrukturdiagramm tauchen in der SysML wieder auf, allerdings unter anderen Namen. Hier heißen sie Blockdefinitionsdiagramm bzw. internes Blockdiagramm.
  Abb. 2: Diagramme der SysML im Überblick
  Neben den alten Bekannten kann die SysML auch mit wirklichen Neuheiten aufwarten, so das Anforderungsdiagramm und das Parameterdiagramm. Von diesen beiden ist das Anforderungsdiagramm für den Gedanken, die gesamte Systementwicklung zu unterstützen und eine Durchgängigkeit zu erzeugen, wohl das interessantere.
  Das Anforderungsdiagramm ermöglicht eine neue Art der Dokumentation von Anforderungen. Im Gegensatz zur bisherigen Methode, die Anforderungen in einem Textverarbeitungs- bzw. Requirements Management Tool zu dokumentieren, können die Anforderungen nun in Diagrammen modelliert werden. Diese Diagramme stellen nicht nur die Anforderungen an sich, sondern auch deren Beziehungen zu anderen Anforderungen oder Elementen aus anderen Disziplinen dar, wie Architektur oder Test.