Wie ausgereift ist Papyrus für UML wirklich?

Auch wenn ich Open Source und Eclipse sehr schätze, so war meine Erfahrung mit Papyrus bisher eher durchwachsen. Es ist allerdings auch schon mehrere Jahre her, dass ich das Werkzeug in einem Projekt nutzen durfte. Insofern finde ich die Diskussionen mit Carsten Pitz zu Papyrus sehr spannend, da er Papyrus aktiv in Projekten einsetzt. Carsten hatte sich bereits in seinem Gastartikel zu Objektorientierung bereits vorgestellt.

Da Carsten mit diesem Artikel auch insbesondere die Papyrus-Community direkt ansprechen möchte, hat er ihn auf Englisch im Formal Mind Blog veröffentlicht. Hier ist eine gekürzte Zusammenfassung für unsere deutschen Leser.

Gastbeitrag von Carsten Pitz: Papyrus – oder meine Sicht auf UML

Streng genommen ist Eclipse Papyrus nur der UML/SysML Editor. Ich verwende diesen Begriff hier jedoch für mein Setup bestehend aus Papyrus, Acceleo, GenDoc und weiteren Erweiterungen.

Der UML Editor

Von allen UML Werkzeugen, die ich bisher verwendet habe hat Papyrus die zur Spezifikation konformste Umsetzung von UML 2.5. In dieser Hinsicht ist Papyrus päpstlicher als der Papst. Aber ich schätze dies. Weshalb? Ich arbeite unter Anderem im Entwurf sicherheitskritischer Systeme, und Papyrus gibt mir das Gefühl, die Entwickler arbeiten hart, um ein gutes Produkt zu erschaffen.

Papyrus ist päpstlicher als der Papst bezüglich der Umsetzung von UML 2.5 (Carsten Pitz) Twittern

Ich nutze den vollen Satz an UML Diagrammen inklusive Timing Diagramme. Papyrus ist das bislang einzige UML Werkzeug, mit dem ich bereits gearbeitet habe, das den ersten Satz des Kapitel 9.6 „Operations“ der UML 2.5 Spezification beachtet. Dieser Satz lautet: “An Operation is a Behavioral Feature that may be owned by an Interface, DataType or Class.” Dieser Satz ermöglicht mir ein Verhalten als Operation einer Klasse zu spezifizieren.

SysML

Papyrus 2.x unterstützt SysML 1.4 und optional SysML 1.1. Päpstlicher zu sein als der Papst ist auch die Agenda der SysML Editor Entwickler. Aber wie ich bereits erwähnt habe, schätze ich dies. Von dem SysML Angebot nutze ich nur BDDs und IBDs, eher selten auch Requirement Diagramme.

Die SysML Spezifikation im Wortlaut umsetzend, erlaubt Papyrus connectors ausschließlich zum Verbinden von parts von blocks. Entsprechend sind connectors nur für IDBs angezeigt. Als ich gelernt habe dies zu respektieren, war dies eine Hilfe und keine Einschränkung für mich.

Business Process Modeling Notation

Den Support für BPMN (Business Process Modeling Notation) sehe ich in Hinblick auf die Version 0.7 als Vorversion an. Ich evaluiere diese Version, nutze diese jedoch aktuell noch nicht in Projekten.

Der BPMN Support von Papyrus unterstützt die Verbindindung zu UML- und SysML-Modellen Twittern

Neben diesem BPMN Editor existiert für Eclipse ein BPMN2 Modeler in Version 1.3.1 mit deutlich größerem Funktionsumfang. Der BPMN2 Modeler realisiert jedoch BPMN auf Basis der OMG BPMN Spezifikation formal/2013-12-09 und nicht auf dem OMG UML Profil für BPMN formal/2014-07-01 wie der BPMN Support von Papyrus. Entsprechend unterstützt der BPMN2 Modeler keine Verbindung zwischen UML/SysML und BPMN Teilmodellen mit durchgängiger automatischer Refakturierbarkeit, der BPMN Support von Papyrus mit der Realisierung von BPMN als DSML unterstützt dies jedoch vollumfänglich. Daher mein intensives Interesse am BPMN Support von Papyrus.

UML Profile

UML bietet mir von Haus aus nur äußerst eingeschränkte Ausdrucksmöglichkeiten. Entsprechend ist der UML Profil Mechanismus für mich extrem wichtig. Papyrus bietet mir eine vollständige Umsetzung des UML Profil Mechanismus ohne irgendwelche Einschränkungen. Und darüber hinaus noch einen sehr leistungsfähigen Mechanismus, UML Profile zu versionieren.

Neben vorgefertigten UML Profilen wie BPMN oder auch aber eher MARTE, nutze ich den Profilmechanismus von UML auch um selbst Profile oder auch Systeme von Profilen zu erstellen.

Object Constraint Language

Auch OCL, die Object Constraint Language von UML ist ein meiner Ansicht nach wichtiger Teil der UML Welt. OCL ermöglicht Einschränkungen zu spezifizieren. Das folgende Diagramm zeigt hierzu ein einfaches Beispiel:

OCL mit Papyrus

Der OCL Support funktioniert für mich wie vorgesehen.

Modelle zu Text

Die „Model to Text Transformation Language“ (MOFM2T) kann vielseitig eingesetzt werden. Den MOFM2T Prozessor Acceleo nutze ich sowohl direkt um Artefakte zu generieren als auch indirekt via GenDoc um Dokumente zu erzeugen. Obwohl GenDoc erst bei Versionsnummer 0.6.0 ist und noch einige Mängel hat, fange ich an dies in realen Projekten zu nutzen. Obeo Acceleo selbst ist ein bewährtes Werkzeug, dem ich voll und ganz vertraue.

ReqCycle

ReqCycle ist eine Papyrus Erweiterung um Anforderungen an Architekturelemente zu binden. ReqCycle ist hochgradig konfigurierbar und schränkt den Anwender in keiner Weise ein Anforderungen mit Architekturelementen zu verknüpfen.

So weit, schätze ich ReqCycle sehr. Aber bislang habe ich noch nicht heraus gefunden, wie ich an die Anzahl der obsoleten Anforderungen, die Anzahl der offenen Anforderungen und die Anzahl der umgesetzten Anforderungen gelange.

Danke

Haben Sie Erfahrungen mit Papyrus gemacht und möchten diese Teilen? Dann tun sie das hier im Kommentarbereich auf Deutsch, oder im englischsprachigen Artikel auf Englisch.

Ich bedanke mich beim Papyrus-Team, und bis zum nächsten Artikel.

Photo: Michael Baird / Unsplash

Dieser Artikel erschien zuerst bei se-trends.de.

One Pingback/Trackback