Prozessblog

Nachdem wir uns die Anforderungen an ein SysML-Tool grob notiert hatten (siehe Artikel Anforderungen an ein SysML-Tool), haben wir diese gruppiert und gewichtet. Dazu haben wir uns der Paarvergleichsanalyse bedient (siehe Artikel Kriterien gewichten mit der Paarvergleichsanaylse) mit folgendem Ergebnis:

Paarvergleichsanalyse der Kriterien für die Tool-Auswahl

Die Bewertung dürfte bei jedem Unternehmen etwas unterschiedlich ausfallen. Man sieht hier deutlich, dass die Zusammenarbeit mehrerer Mitarbeiter an einem Modell einen hohen Stellenwert hat und die Bedienung des Tools für ebenso wichtig erachtet wird.

Wir haben unsere Auswahl nicht zuletzt aus Kostengründen auf drei Tools beschränkt.

• Enterprise Architect von SparxSystems
• MagicDraw von Nomagic
• objectiF von microTOOL

objectiF wurde schon eingesetzt, unterstützt aber kein SysML. Die Entscheidungsmatrix (siehe Artikel Entscheidungsfindung mit Entscheidungsmatrix) sah nach Bewertung der einzelnen Optionen wie folgt aus:

Entscheidungsmatrix zur Auswahl eines SysML-Tools

MagicDraw hat das Rennen gemacht. Mit dem Teamworks-Server lässt sich komfortabel zusammen an einem Modell arbeiten. Letztlich ist die Implementierung des SysML-Standards wesentlich besser, da die komplette Semantik hinterlegt ist, so dass das Tool an vielen Stellen sinnvoll unterstützt. Wir arbeiten jetzt seit einigen Monaten mit MagicDraw und sind bisher recht zufrieden.

Wenn man sich entschließt, modellbasierte System-Entwicklung (MBSE) mit SysML einzuführen, kommt man um ein Software-Tool nicht herum. SysML-Diagramme auf Papier zu entwerfen, macht nicht wirklich viel Laune.

Insbesondere erzeugt man mit einem Diagramm eigentlich nur eine bestimmte Sicht auf das Systemmodell. Die Menge der Modellelemente mit ihren Beziehungen untereinander beinhalten die Informationen, die man in den Diagrammen nur ausschnittsweise wiedergibt.

Insofern reicht auch ein Tool wie Microsoft Visio nicht aus, denn man erhält damit nur ein “Malprogramm” und in keinster Weise ein Werkzeug, dem die Semantik der Sprache hinterlegt ist.

Wie für jede strukturierte Entscheidung sollte auch bei einer Tool-Auswahl folgendes Vorgehen verfolgt werden:

1. Kriterien festlegen für die Bewertung der möglichen Optionen
2. Mögliche Lösungen identifzieren
3. Verfahren zur Bewertung der Lösungen auswählen
4. Identifizierte Lösungen mit dem gewählten Verfahren anhand der festgelegten Kriterien bewerten
5. Auf Grundlage der Bewertung die beste Lösung auswählen

Um eine Handvoll geeigneter Kriterien zu festzulegen, macht es Sinn, sich zunächst einmal über die Anforderungen an ein solches Modellierungs-Tool Gedanken zu machen. Im folgenden finden Sie daher einige Anforderungen, die auch bei Ihnen passen könnten. In der Regel wird dasselbe Tool sowohl von den System-Ingenieuren (für SysML-Modelle) als auch von Software-Entwicklern (für UML-Modelle) verwendet. Daher finden sich Anforderungen beider Welten wieder.

Eine erste Priorisierung kann mittels Unterscheidung in soll, sollte, kann vorgenommen werden. Die Anforderungen sind wie folgt formuliert, je nachdem ob es eine Benutzer-unabhängige Tool-Aktivität ist (1), das Tool dem Benutzer eine bestimmte Funktionalität zur Verfügung stellt (2) oder die Anforderung eine bestimmte Eigenschaft des Tools beschreibt (3):

1. Das Tool soll…
2. Das Tool soll die Möglichkeit bieten, …
3. Das Tool soll fähig sein, …

Dabei wird auf das Präfix “Das Tool…” verzichtet. Hier nun also eine Auswahl von Anforderungen an ein SysML/UML-Tool:

Modellierung

1. soll die Möglichkeit bieten, entsprechend UML 2.3 zu modellieren.
2. soll die Möglichkeit bieten, entsprechend SysML 1.2 zu modellieren.
3. sollte die Möglichkeit bieten, Tabellen  zu erstellen, mit denen sich Beziehungen zwischen Modellelementen darstellen lassen.

 Benutzerfreundlichkeit

4. soll ansprechend und intuitiv zu bedienen sein.
5. sollte dem Benutzer die Möglichkeit bieten, zwischen deutscher und englischer Bedienoberfläche umzuschalten.

Konfigurationsmanagement und Zusammenarbeit

6. soll die Möglichkeit bieten, mit mehreren Benutzern parallel an einem Modell zu arbeiten. Ein Modell bezieht sich dabei auf das System eines Projektes; die Aufteilung eines Modells in Pakete ist denkbar.
7. soll die Möglichkeit bieten, auf alte Versionen eines Modells zugreifen zu können.
8. sollte die Möglichkeit bieten, die Unterschiede zwischen zwei Modellversionen darzustellen (diff).
9. sollte die Möglichkeit bieten, die Unterschiede zwischen zwei Versionen eines Elements darzustellen.
10. soll die Möglichkeit bieten, andere Modelle (Module) in ein Projekt einzubinden

Code Engineering

11. soll die Möglichkeit bieten, C++ Source Code (.c und .h) aus Klassendiagrammen zu erzeugen.
12. sollte die Möglichkeit bieten, zuvor generierten, veränderten Source Code wieder mit dem Modell zu synchronisieren.

Systemanforderungen

13. soll fähig sein, unter Windows XP und Windows 7 zu laufen.
14. kann fähig sein, unter Linux zu laufen.
15. sollte fähig sein, sich in Microsoft Visual Studio zu integrieren.
16. sollte fähig sein, sich in Eclipse zu integrieren.

Schnittstellen

17. soll die Möglichkeit bieten, aus Diagrammen Dokumente zu generieren.
18. sollte die Möglichkeit bieten, die Generierung von Dokumenten zu beeinflussen, bspw. durch die Erstellung von Templates, durch die Einbeziehung von Tagges Values und anderer Modellvariablen.
19. soll die Möglichkeit bieten, Diagramme als Bilddatei (PNG, JPG) zu exportieren.
20. soll die Möglichkeit bieten, Modellelemente mit Anforderungen aus DOORS zu verknüpfen.
21. soll die Möglichkeit bieten, Modelldaten mit XText auszutauschen.
22. soll die Möglichkeit bieten, sich über Skripte automatisieren zu lassen.
23. soll die Möglichkeit bieten, von außen (per API) auf Modelle zugreifen zu können.

Weitere Anforderungen

24. kann die Möglichkeit bieten, Metriken bzgl. des Modells zu erzeugen

Sind das in etwa die Anforderungen, die Sie an ein solches Tool stellen? Welche wichtigen Punkte fehlen?

Ich würde sagen, zu den Hauptaufgaben der System-Entwicklung zählt es,

• die Anforderungen des Systems zu spezifizieren
• eine stabile System-Architektur zu entwerfen, auf der die anderen Disziplinen aufsetzen können
• das System gegen die Kundenanforderungen zu verifizieren
• das System in seiner Zielumgebung zu validieren

Im Vergleich zum Software Engineering scheint es im Systems Engineering wenig einheitliche Methodiken zu geben, die diese Aufgaben unterstützen. Viele System-Ingenieure entwerfen ihr System in ellenlangen Prosa-Spezifikationen, die keiner liest, oder anhand von wilden Blockdiagrammen, die keiner versteht.

Das International Council on Systems Engineering (INCOSE) ist weltweit anerkannt als die bedeutendste Organisation, die sich mit System-Entwicklung beschäftigt. INCOSE erwartet in den nächsten Jahren einen Übergang von dokumententen-zentrierter System-Entwicklung zu dem, was wir Modellbasierte System-Entwicklung nennen und betont dies in ihrer Vision für das Jahr 2020.

Modellbasierte System-Entwicklung (MBSE) unterstützt den Systemingenieur bei seinen Aufgaben durch die Erstellung eines Systemmodells, das während des gesamten Entwicklungsprozesses bei Spezifikation, Entwurf, Verifikation und Validierung komplexer Systeme als Basis verschiedenster Entscheidungen und Arbeitsergebnisse dient.

So ein Modell ist eine in sich konsistente Abbildung des zu entwickelnden Systems und erlaubt unterschiedliche Sichten auf die Informationen, die es beinhaltet. Solche Sichten sind grafische Visualisierungen in der speziell für die System-Entwicklung entwickelten Modellierungssprache Systems Modelling Language (SysML).

Als internationaler Standard dient die SysML somit bei der Modellierung als hilfreiches Werkzeug und erlaubt es, dass jeder Betrachter eines SysML-Diagramms dasselbe daraus liest. In diesem Sinne erleichtert die SysML die Kommunikation im Team erheblich und gestattet es, für jeden Mitarbeiter die Sichten auf das Modell zu erzeugen, die er benötigt.

Zum Einstieg in das Thema SysML kann ich das Buch von Tim Weilkiens empfehlen, der selbst an dem Standard mitarbeitet.