Debatte: Wie industrietauglich ist Eclipse Papyrus?

UML-Plattform Eclipse Papyrus: Reif für die große Bühne? [Update: Charles Rivet kommentiert]

Redaktion JAXenter

Das Eclipse-Projekt Papyrus hat durch die Gründung des Papyrus Industry Consortium Anfang dieses Jahres Fahrt aufgenommen. Die Plattform für die UML-basierte Softwaremodellierung wird mittlerweile von Unternehmen wie Airbus, Atos, Ericsson, Fraunhofer Fokus und Zeligsoft gestützt. Wir diskutieren mit Papyrus-Nutzer Michael Jastram und Papyrus-Leiter Charles Rivet über den aktuellen Stand und die Zukunft von Papyrus.

Anlass für diesen Beitrag ist Michael Jastrams ursprüngliche Einstufung von Papyrus als eines der Projekte, die ihn 2015 enttäuscht haben. Der Beitrag vom Dezember 2015 hat Papyrus-Leiter Charles Rivet zu einem Blogpost angeregt, in dem er zu einem konstruktiven Dialog aufruft. Eine Anregung, die wird gerne aufnehmen!

Nachdem Michael Jastram Papyrus unter dem Gesichtspunkt der letzten Entwicklungen neu bewertet hat, gibt Charles Rivet uns ein Update zum Projekt und kommentiert einige der Kritikpunkte.  

 

Charles Rivet antwortet, 19. Mai 2016:

„Papyrus ist mehr Plattform als Tool“

Das Eclipse Papyrus-Projekt existiert jetzt schon seit einer ganzen Weile – was hat sich geändert, jetzt wo ein eigenes Industry Consortium um Papyrus gegründet wurde?

240e537342cf00f4c1063df2c8951be7Charles Rivet: Zunächst möchte ich klarstellen, dass die von mir gegebenen Antworten nur meine persönliche Meinung widerspiegeln. Sie repräsentieren nicht die Ansichten von Zeligsoft oder Eclipse noch die Meinungen des Papyrus IC oder des Papyrus-Entwicklerteams.

Das Papyrus Industry Consortium (Papyrus IC) wurde ins Leben gerufen, um die Entwicklung eines quelloffenen, Modell-basierten Engineering-(MBE)-Tools für die Industrie zu ermöglichen. Im Einklang damit wurde eine Satzung verfasst, um das Konsortium sowie seine Ziele zu definieren. Dazu gehört etwa die „Planung und Koordination der Entwicklung einer industriegerechten Papyrus-Tool-Suite, um die Verfügbarkeit von Schlüsselfunktionalitäten sowie die Evolution und langfristige Verfügbarkeit einer vollständigen MBE-Lösung sicherzustellen.“ Darin inbegriffen ist ein Überblick über den kompletten Papyrus-Entwicklungszyklus.

Im Papyrus IC sitzen vier Typen von Vertretern: Anwender (also Mitglieder, die industrielles MBE nutzen und den Entwicklungsprozess von Papyrus beeinflussen wollen), Zulieferer (Tool-Entwickler, die ihre Wissen nutzen, um Papyrus zu beeinflussen und zu entwickeln), Teilnehmer (die sich an der Entwicklung eines Papyrus-Ökosystems beteiligen wollen) sowie Forscher und Akademiker. Das Papyrus IC stellt außerdem ein Governance-Framework für die Definition, Entwicklung und Evolution einer Papyrus-Tool-Suite (oder Produktlinie) zur Verfügung.

Ein Vorteil des Papyrus IC ist, dass Firmen ihre Ressourcen (Geld und Mitarbeiter) zusammenführen können, um strategisch wichtige Bereiche von Papyrus, die noch optimiert werden müssen, in Angriff zu nehmen. Diese Bereiche werden durch die Erfahrungen der User festgelegt, was wiederum sicherstellt, dass der Fokus auf den Aspekten liegt, die die Nutzer als wichtig erachten.

Das Papyrus IC hat bereits erste Treffen abgehalten, um die Zukunft von Papyrus zu planen. Wir sind sicher, dass das Neon-Release den Erfolg unserer Herangehensweise untermauern wird.

Angemerkt werden sollte noch, dass die CEA, die Urheber von PolarSys, das führende Zulieferermitglied des Papyrus IC ist und daher ein vollständiger Partner in dieser Unternehmung.

PapyrusWas ist Eclipse Papyrus?
Papyrus ist eine erweiterbare Plattform bzw. Tool-Suite, die sowohl bestehende Modellierungssprachen à la UML 2.5 und SysML 1.4 unterstützt, als auch die Erstellung eigener domänenspezifischer Modellierungssprachen erlaubt. Durch diese Anpassbarkeit deckt Papyrus potentiell verschiedenste Entwicklungsaspekte ab, darunter z. B. modellbasierte Simulationen, modellbasierte Tests und Sicherheitsanalysen.
Im Februar 2016 hatten sich die 12 Unternehmen Adocus, Airbus Helicopters, Airbus Defence & Space, Atos, CEA List, Combitech/Saab, EclipseSource, Ericsson, Flanders Make, Fraunhofer Fokus, OneFact und Zeligsoft zum Papyrus Industry Consortium zusammengeschlossen, mit dem Ziel, eine auf Papyrus aufbauende, modellbasierte Engineering-Plattform bzw. Workbench zu schaffen.
Die quelloffene MBE(Model-Based Engineering)-Lösung soll insbesondere den Anforderungen von Unternehmensanwendern, im Speziellen den Entwicklern softwareintensiver Systeme (z. B. Unternehmensanwendungen, Embedded-Software, Internet of Things) gerecht werden.

 

Michael Jastram hat in seinen Antworten (siehe unten) angemerkt, Papyrus funktioniere nicht besonders gut Out-of-the-Box. Ist das aus deiner Sicht ein stichhaltiges Argument?

Charles Rivet: Das ist leider teilweise wahr. Das Problem hat mehrere Ebenen: Die erste Ebene besteht in der Art, wie Erwartungen gesetzt (oder vielmehr: nicht gesetzt) wurden. Papyrus wurde ursprünglich als allumfassendes, UML-basiertes Modeling-Tool vorgestellt, wohingegen viele von uns jetzt glauben, dass es eher als Framework oder als Plattform hätte präsentiert werden sollen. Viele Leute haben deswegen einen bestimmten Grad an Userfreundlichkeit erwartet. Das Produkt ist aber eher für Experten gedacht gewesen. Zum Beispiel überfordert die Fülle von Menüs und Toolbars viele Standardnutzer.

Die zweite Ebene betrifft das Installationserlebnis. User mussten zuerst die richtige Basis-Eclipse-Plattform installieren und dann die richtigen Komponenten auswählen. Das ist zwar für Eclipse eine Standardprozedur, aber nicht die beste Vorgehensweise – insbesondere im Vergleich mit kommerziellen Angeboten – für einfache Modellierer und User, die nicht mit Eclipse vertraut sind. Dieses Problem soll mit dem Projekt Papyrus RCP beseitigt werden, das auf der Webseite von Eclipse Papyrus direkt erhältlich ist.

Bei der dritten Ebene geht es um die User Experience nach dem Start des Tools. Aufgrund der vielen Menüs und Toolbars ist die Handhabung des Werkzeugs eher komplex und „expertenfreundlich“. Davon abgesehen wurde im Papyrus IC der User Experience Priorität eingeräumt und die Arbeit daran aufgenommen.

Michael hat Papyrus außerdem mit kommerziellen Lösungen verglichen. Glaubst du, der Vergleich ist fair?

Charles Rivet: Jedes MBE-Tool muss sich mit der Konkurrenz messen; in dieser Hinsicht ist der Vergleich also fair. Allerdings hat Michael Papyrus als Open Source Modeling-Tool betrachtet und nicht als Plattform (darauf komme ich noch zurück). Nun stammt Papyrus aus einer Forschungseinrichtung mit vielen verschiedenen Interessensgruppen, sodass sich die Entwicklung nicht ausschließlich auf die Fertigung eines MDE-Tools konzentrierte. Michael vergleicht Papyrus aber mit etablierten und kommerziellen Tools von Organisationen, die sich auf dieses Gebiet spezialisiert haben. Denkt man einmal so darüber nach, ist das Ergebnis nicht sonderlich überraschend.

Also, ich frage mich, wie Papyrus im Vergleich mit diesen kommerziellen Tools abschneiden würde, wenn es nicht als Tool, sondern als Tooling-Plattform gewertet würde, mit deren Hilfe Anwender die Tools auf ihre eigenen Ansprüche anpassen können. Das dürfte auch für die Papyrus-IC-Mitglieder interessant sein.

Was sind deiner Meinung nach die Stärken von Papyrus?

Die größte Stärke von Papyrus liegt in seiner Anpassbarkeit.

Charles Rivet: Die größte Stärke von Papyrus liegt in seiner Anpassbarkeit. Die Papyrus-Plattform räumt fortgeschrittenen Usern große Spielräume bei der Modifizierung ein, um die Voraussetzungen einer bestimmten Domäne, Industrie oder Sprache zu erfüllen. Das macht Papyrus zu einer hervorragenden Plattform, um UML-basierte, Domänen- spezifische Modellierungssprachen (DSML) zu entwickeln. Diese Eigenschaft war sehr nützlich, um andere DSMLs, die Teil von Papyrus sind, wie SysML, RobotML und UML-RT, das in Papyrus-RT zum Einsatz kommt, zu definieren. Übrigens wird Papyrus-RT die Inkubationsphase kurz nach dem Release von Neon verlassen. Ferner hat die Anpassbarkeit von Papyrus die Implementierung bestimmter optionaler Komponenten wie Moka und Compass erleichtert.

Eine weitere Stärke ist die Leistung des Ökosystems im Verbund mit dem Papyrus IC. Wir sprechen hier nicht nur von Kunden, sondern von Menschen und Unternehmen, die so sehr an Papyrus glauben, dass sie Geld und Zeit in das Projekt investieren und so zu integralen Bestandteilen des Gemeinschaftsprodukts geworden sind. Daneben ist es von Vorteil, dass Papyrus in einer Forschungseinrichtung entwickelt wird. Statt Shortcuts zu implementieren, werden Standards strikt eingehalten.

Welche Schwachpunkte müssen noch verbessert werden?

Charles Rivet: Der größte Schwachpunkt ist die User Experience. Von der Installation bis hin zur aktiven Benutzung müssen Verbesserungen vorgenommen werden – ein Problem, das bei allen Tools nicht einfach zu lösen ist. Wir haben bereits mit den Arbeiten begonnen und setzen hierbei auf das Feedback von Usern sowie Entwicklern innerhalb und außerhalb des Papyrus IC. Das Papyrus IC hat in Kollaboration mit PolarSys eine formale Überprüfung sowie eine Analyse der Papyrus User Experience in Auftrag gegeben. Ein Experte wird uns helfen, die Probleme in den Griff zu bekommen. Die Fortschritte, die wir in diesem Bereich machen, werden in den nächsten Releases sichtbar sein.

Die Governance des Papyrus-Tool-Suites war ebenfalls ein Thema, das mithilfe des Papyrus ICs adressiert wurde. So wurden Produktmanagement-Leader für die Hauptkomponenten und Produktvarianten ernannt. Zudem haben wir Werkzeuge und Preise zur Verfügung gestellt, um diese Initiative zu unterstützen.

Was sind die aktuellen Pläne?

Wir wollen Papyrus als Produktlinie etablieren.

Charles Rivet: In meinen Antworten habe ich bereits einige Initiativen angesprochen. Einige von ihnen repräsentieren kontinuierliche Verbesserungen, die mehrere Releases umfassen werden. Kurzfristig ist der Neon-Release im Juni geplant, der zum ersten Mal den Einfluss des Papyrus IC verdeutlichen wird.

Ein weiterer Ansatz, den wir zurzeit verfolgen, liegt darin, Papyrus als Produktlinie zu etablieren. Zum Beispiel werden wir kurz nach der Veröffentlichung von Neon einige Papyrus-basierte Modeling-Tools ankündigen und bereitstellen: beispielsweise Papyrus for Real Time, das dann die Inkubationsphase verlassen wird, und Papyrus for Information Modeling, ein Projekt, das diese Woche auf dem TM Forum Live vorgestellt wurde. Eine formale Ankündigung folgt in Kürze. Des Weiteren werden wir die Papyrus-Produktlinie mit Papyrus für xtUML ausbauen, das bereits jetzt ein separates Projekt in Eclipse ist. Darüber hinaus sind noch weitere Veröffentlichungen geplant, die sich derzeit noch in der Entwicklung befinden. Und natürlich werden wir all diese Verbesserungen auf der EclipseCon vorstellen!

Ansonsten versuchen wir, die Anzahl an Unternehmen, die kommerzielle Dienstleistungen rund um das Thema Papyrus wie Support und Trainings bereitstellen, kontinuierlich zu steigern. Wir sind überzeugt, dass wir uns auf dem richtigen Weg befinden, damit Papyrus ein Erfolg wird.

240e537342cf00f4c1063df2c8951be7Charles Rivet ist als Senior Product Manager bei Zeligsoft verantwortlich für die Entwicklung neuer Geschäftsbereiche und Produkte im Bereich Open-Source-Modeling, insbesondere Papyrus for Real Time. Als Teil dieser Arbeit ist er ein aktives Mitglied der Eclipse PalarSys Working Group.

 



Originalbeitrag vom 13. Mai 2016: Michael Jastram kommentiert seine Einschätzung von Papyrus vom Dezember 2015

„Papyrus ist ein beeindruckendes Projekt“

JAXenter: Du hattest im Dezember Papyrus als Enttäuschung bezeichnet. Was genau hat dich zu der Einschätzung gebracht?

michael1-107x130Michael Jastram: Als erstes möchte ich klarstellen, dass Papyrus ein beeindruckendes Projekt ist. Open Source hat sich seit den ersten Tagen von Eclipse ganz schön gemausert. Unter diesem Gesichtspunkt zeigt mein Kommentar eher, was für hohe Erwartungen wir inzwischen an Open Source stellen.

Zum zweiten bezog sich mein Kommentar auf die Vergangenheit. Gefragt wurde nach Enttäuschungen in 2015. Konkret basierte mein Kommentar auf den Einsatz von Papyrus im Forschungsprojekt „openETCS“, welches in 2012 begann und 2015 endete.

Bei openETCS ging es um sicherheitskritische, eingebettete Software für Triebköpfe von Zügen. Das war ein Anwendungsbereich, der perfekt zu Papyrus zu passen schien, insbesondere, da der Einsatz von Open Source zu den Forschungszielen zählte. Wir hatten die Werkzeugkette ursprünglich auf Kepler aufgesetzt. Leider hatten wir viele Probleme hinsichtlich Performanz und Bedienbarkeit. Daher fassten wir den Entschluss, zu Luna zu migrieren, was in 2015 geschah und vieles verbesserte. Aber es war zu spät, um Papyrus in der Breite einzusetzen, wie wir es ursprünglich geplant hatten.

In 2015 wurde zwar auch Papyrus Mars veröffentlicht. Allerdings waren wir zu sehr damit beschäftigt, das Projekt zum Abschluss zu bringen, sodass wir Mars nicht mehr evaluieren konnten, und eine Migration schon gar nicht in Frage kam.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

JAXenter: Nun hat sich bei Papyrus ja einiges getan in den letzten Monaten – u.a. die Gründung des Papyrus Consortiums. Wie schätzt du diese Entwicklungen ein?

Michael Jastram: Ich finde diese Entwicklungen sehr spannend. Das Führen und Steuern von Open-Source-Projekten ist eine Herausforderung, da die Entwickler ungern an wichtigen, aber langweiligen Features arbeiten. Das Konsortium hat die richtigen Leute und auch die entsprechenden finanziellen Ressourcen sowie Personal, um sich auf die wichtigen Dinge zu konzentrieren – und nicht nur auf das, was Spaß macht.

Ich finde es auch faszinierend, wie sich Eclipse diesbezüglich weiterentwickelt hat, und auch das ist ein Hinweis darauf, das Open Source erwachsen wird: Es ist nun ein großes Geschäft mit einem soliden Geschäftsmodell dahinter. Die Eclipse Foundation hat darauf reagiert, indem sie der Industrie eine entsprechende Plattform zur Verfügung gestellt hat, die Industry Groups (IG). Das ist ein gutes Konzept, welches Industrieprojekte schnell voranbringt.

Papyrus funktioniert noch nicht sonderlich gut „out of the box“.

JAXenter: Welche Verbesserungen/Erweiterungen wünscht du dir nun bei Papyrus, damit das Projekt industrietauglich wird?

Michael Jastram: Das hängt ein bisschen davon ab, was mit „industrietauglich“ gemeint ist. Papyrus wird schon eine ganze Weile in der Industrie eingesetzt, aber primär von großen Konzernen, die sich leisten können, es für deren Einsatz anzupassen. Papyrus funktioniert noch nicht sonderlich gut „out of the box“. Um nur ein Beispiel zu nennen: Wie kann aus einem Modell ein Dokument generiert werden? Das geht nur durch Basteleien, in diesem Fall mit GenDoc. Im Gegensatz dazu können kommerzielle Werkzeuge wie Enterprise Architect oder MagicDraw auf Knopfdruck Standarddokumente generieren. Und selbst ein unerfahrener Nutzer kann innerhalb weniger Stunden Anpassungen durchführen und eigene Templates erstellen. Bei einem Preis von weniger als €200 für eine Einstiegslizenz fällt einer kleinen Firma die Entscheidung für die kommerzielle Lösung leicht.

JAXenter: Vielen Dank für diese ersten Einschätzungen. In Kürze wird Papyrus-Leiter Charles Rivet die Diskussion fortsetzen!

michael1-107x130Dr. Michael Jastram ist Project Lead und Committer vom Eclipse Requirements Modeling Frameworks. Er ist Geschäftsführer der Formal Mind GmbH, die Forschungsergebnisse im Bereich Systems Engineering kommerzialisiert. Er ist regelmäßiger Fachautor und Sprecher auf Konferenzen. Er ist regelmäßiger Fachautor und Sprecher auf Konferenzen und schreibt wöchentlich über Systems Engineering unter http://se-trends.de.

Verwandte Themen:

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: