{"id":962,"date":"2017-02-07T08:00:54","date_gmt":"2017-02-07T07:00:54","guid":{"rendered":"https:\/\/formalmind.com\/?p=962\/"},"modified":"2022-04-11T18:58:54","modified_gmt":"2022-04-11T16:58:54","slug":"eclipse-papyrus","status":"publish","type":"post","link":"https:\/\/www.formalmind.com\/de\/blog\/eclipse-papyrus\/","title":{"rendered":"Ist Eclipse Papyrus bereit f\u00fcr die Industrie?"},"content":{"rendered":"

Der heutige Gastartikel wurde von Carsten Pitz geschrieben, der seine\nseine Erkenntnisse \u00fcber den Stand von Papyrus f\u00fcr die Modellierung mitteilt, was f\u00fcr unsere\n f\u00fcr unsere Leser interessant sein d\u00fcrfte. Insbesondere als ein auf Eclipse basierendes Werkzeug,\nPapyrus kann integriert mit ReqIF Studio<\/a>.<\/p>\n\n\n\n

Dennoch hat Papyrus den Ruf, nicht industrietauglich zu sein\nnicht industrietauglich zu sein, schwer zu bedienen zu sein und wichtige Funktionen zu vermissen. Wie auch immer,\nCarstens Meinung ist jedoch eine ganz andere. Lesen Sie weiter, um herauszufinden, warum.<\/p>\n\n\n\n

Papyrus - oder meine Sicht auf UML (von Carsten Pitz)<\/h2>\n\n\n\n

Der folgende Artikel ist eine sehr pers\u00f6nliche Sicht auf Papyrus. Um\n die richtige Grundlage zu geben, muss ich mit meinem ersten Kontakt mit\nmit UML im Jahr 1998 beginnen. Damals arbeitete ich bei einem gro\u00dfen deutschen Logistik\nLogistikdienstleister in einer Gruppe von vier Architekten. Unsere Aufgabe war die Erforschung und\ninnovative Technologien zu erforschen und zu bewerten. UML wurde am 19. November 1997 als offene\nSpezifikation am 19. November 1997 ver\u00f6ffentlicht, und sie war damals neu und innovativ.\nZeit.<\/p>\n\n\n\n

Auch die objektorientierte Methodik (OO) war zu diesem Zeitpunkt neu. Als\ndie Doppel-Null eine bestimmte Bedeutung hat, wurde der Begriff\nmit der Toilette in Verbindung gebracht - was zu einigen Belustigungen mit der\nder Abteilungssekret\u00e4rin f\u00fchrte...<\/p>\n\n\n\n

Also haben wir die UML 1.1-Spezifikation untersucht (UML 1.0 war Rational\npropriet\u00e4r) und evaluierten vier UML-Tools. Diese Werkzeuge waren: Rational\nRose, Together\/J, Computer Associates Paradigm Plus und\nSterling Software COOL:Jex.<\/p>\n\n\n\n

Erforschung der UML 1.1. mit Together\/J im Jahr 1998<\/h3>\n\n\n\n

Unsere Wahl fiel auf Together\/J. Vielleicht nicht die schlechteste Wahl, denn\nTogether\/J ist das einzige Werkzeug, das von diesen Werkzeugen noch existiert. Falls Andreas W.\n dies liest: Hallo Andreas, ich bin mir der Tatsache bewusst, dass Sterling\nSoftware COOL:Jex zu Telelogic Tau wurde, das wiederum zu IBM Rational\n Rhapsody wurde. Aber die \u00c4nderungen an COOL:Jex waren viel einschneidender\nwie bei Together\/J.<\/p>\n\n\n\n

Trotz der Tatsache, dass Together\/J das einzige dieser Werkzeuge ist, das\nmehr oder weniger so existiert wie 1998, muss ich aus der Retroperspektive\n Ich muss zugeben, dass die Wahl von Together\/J stark von unserem gemeinsamen Entwicklungshintergrund\ngemeinsam hatten.<\/p>\n\n\n\n

Dennoch passte Together\/J perfekt zu unseren damaligen Bed\u00fcrfnissen. Die\nRound-Trip-Engineering, das Together\/J schon 1998 bot, ist auch heute noch\nauch heute noch mit keinem anderen Tool zu vergleichen.<\/p>\n\n\n\n

Fokus auf Struktur<\/h3>\n\n\n\n

Da wir einen starken Entwicklungshintergrund haben, lag unser Schwerpunkt auf der Struktur, genauer gesagt\n genauer gesagt auf Klassendiagramme. Diese einfachen Klassendiagramme haben uns sehr geholfen\nsehr geholfen, Ideen zu visualisieren und zu diskutieren (Carsten Pitz)<\/p>\n\n\n\n

Einfache Klassendiagramme sind sehr hilfreich, um unsere Ideen zu visualisieren und zu diskutieren.<\/p><\/blockquote>\n\n\n\n

Noch eine Information zu meiner Person. Der \u00e4lteste und bei weitem erfahrenste\nerfahrenste Entwickler unseres Teams nahm mich eines Morgens zur Seite und sagte\nmir: \u201cDeine Entw\u00fcrfe sind irgendwie seltsam. Deine Entw\u00fcrfe respektieren perfekt alle\nOO-Regeln, die mir bekannt sind. Aber irgendwie weigere ich mich, Ihre Entw\u00fcrfe als objekt\norientieren. Ich habe lange dar\u00fcber nachgedacht und bin gestern Abend auf die Idee gekommen.\nIhre Entw\u00fcrfe sind komponentenbasiert.\u201d. Nach einiger Zeit antwortete ich: \u201cJa,\nmeine Entw\u00fcrfe sind komponentenbasiert. Ich bin Ingenieur und als Ingenieur denke ich\ndenke ich in wiederverwendbaren Komponenten, die \u00fcber gut definierte\nSchnittstellen kommunizieren.\u201d<\/p>\n\n\n\n

Ich analysierte meine Entw\u00fcrfe und verglich sie mit den Entw\u00fcrfen der anderen\nArchitekten aus unserer Gruppe. Ich war der Einzige, der Schnittstellen und\nPakete. Ich f\u00fchrte spezielle Klassen ein, die ich Schnittstellenklassen nannte.\nHeute wird diese Art von Klassen gemeinhin als Fassaden bezeichnet. Diese\nSchnittstellenklassen habe ich in Schnittstellenklassenpaketen zusammengefasst. Die einzigen\n\u00f6ffentlichen Pakete der Komponenten.<\/p>\n\n\n\n

Fokus auf Verhalten<\/h3>\n\n\n\n

Sp\u00e4ter, im Jahr 2002, \u00e4nderte sich mein Umfeld. Ich musste die Implementierungsoptionen\nImplementierungsoptionen mit Kunden diskutieren und nicht nur innerhalb eines Architektenteams. Sogar\nProgrammcode ist zwar die genaueste Notation, um Verhalten auszudr\u00fccken,\nsind die meisten Kunden mit gesch\u00e4ftlichem Kontext nicht in der Lage, Programmcode zu verstehen.\nCode zu verstehen. Daher hat die Beschreibung von Verhalten mit der UML-Notation bald mein\nmein Modellierungsportfolio.<\/p>\n\n\n\n

Zustandsdiagramme und Sequenzdiagramme k\u00f6nnen so entworfen und dargestellt werden, dass die Kunden sie verstehen. Das war gut.<\/p>\n\n\n\n

Artefakt-Generierung<\/h3>\n\n\n\n

Da ich im Grunde meines Herzens Ingenieur bin, tut es mir wirklich weh, ein St\u00fcck\nder Arbeit wegzuwerfen. Das f\u00fchrt mich zur Artefakterzeugung. Mein urspr\u00fcngliches Tooling zur\num dies zu erreichen, waren ArgoUML & AndroMDA. ArgoUML ist ein UML-Modellierungs\nWerkzeug. AndroMDA ist ein Modell zu Text, ein M2T-Konverter. Aber ArgoUML wurde nicht\nmigriert, um UML2 zu unterst\u00fctzen.<\/p>\n\n\n\n

UML2 und die Meta-Objekt-Funktion<\/h3>\n\n\n\n

F\u00fcr mich kam UML2 genau zum richtigen Zeitpunkt. UML2 bot mir einen\naufger\u00e4umten Profilmechanismus und ein aufger\u00e4umtes UML-Metamodell, die\nMeta-Object Facility (MOF). Die MOF entwickelte sich zu etwas wirklich N\u00fctzlichem\nf\u00fcr mich. Aber wie ich bereits erw??hnt habe, wurde ArgoUML nicht auf UML2 migriert.<\/p>\n\n\n\n

Ich habe mehrere verschiedene Werkzeugkonfigurationen ausprobiert. Eclipse Topcased entsprach meinen\nBed\u00fcrfnisse am besten, also blieb ich bei Topcased. Topcased verwendete Acceleo als\nArtefaktgenerator, so dass ich begann, MOFM2T - die Notation der OMG zur\nModelle in Text zu transformieren - als Transformationssprache zu verwenden.<\/p>\n\n\n\n

Anwendungsf\u00e4lle<\/h3>\n\n\n\n

Wie ich schrieb in einem Blogbeitrag bei SE-Trends<\/a>\n (Anwendungsf\u00e4lle brachten mich dazu, Objekte als Akteure zu betrachten, Architektur als\nChoreographie von Akteuren. Dieses Prinzip erwies sich als \u00e4u\u00dferst wirkungsvoll.<\/p>\n\n\n\n

Trotzdem habe ich die Anwendungsf\u00e4lle vergessen, einfach weil ich keinen Bedarf\nf\u00fcr sie hatte. Zu dieser Zeit schien niemand, nicht einmal in der Wissenschaft, sie zu verwenden\nauch nicht.<\/p>\n\n\n\n

Mein Interesse an Anwendungsf\u00e4llen wurde geweckt, als ich mich mit einer gro\u00dfen\nMenge von Anforderungen zu tun hatte. Wenn ich mich richtig erinnere, sammelten in diesem Projekt die\nAnforderungsingenieure etwa 17.000 Anforderungen von fragw\u00fcrdiger\n Qualit\u00e4t.<\/p>\n\n\n\n

Ich habe dar\u00fcber nachgedacht und nach einer Weile habe ich - mehr aus Instinkt als aus Ratio -\nbegonnen, Anwendungsf\u00e4lle zu definieren und den definierten Anwendungsf\u00e4llen Anforderungen\nAnwendungsf\u00e4llen zuzuordnen. Dieser Ansatz erwies sich als erfolgreich. Also beauftragte ich die anderen\nArchitekten an, mir dabei zu helfen. Es funktionierte. Wir entwickelten recht schnell ein\nVerst\u00e4ndnis daf\u00fcr, was zu tun war.<\/p>\n\n\n\n

\u00dcber Werkzeuge und ihre Grenzen<\/h3>\n\n\n\n

Wie Sie vielleicht schon bemerkt haben, war meine Werkzeuggeschichte vielf\u00e4ltig und ziemlich\ndisruptiv. Mit meinem starken Entwicklerfokus begann ich mit Together\/J,\nwegen seiner un\u00fcbertroffenen Round-Trip-Engineering-Funktionen. Mein Bedarf an\nArtefaktgenerierung f\u00fchrte mich zur Kombination von ArgoUML und AndroMDA.\nUnd um an den Vorteilen der UML2 gegen\u00fcber der UML1 teilzuhaben, wechselte ich zu\nTopcased.<\/p>\n\n\n\n

Dar\u00fcber hinaus habe ich viele so genannte \u201cUML\u201d-Tools ausprobiert. Alle diese\nanderen Werkzeuge empfand ich als Gef\u00e4ngnisse, genauer gesagt als Sammlungen von\nEinschr\u00e4nkungen. Diese Beschr\u00e4nkungen \u00e4u\u00dfern sich als Einschr\u00e4nkungen in\nAusdrucksst\u00e4rke, Modellgr\u00f6\u00dfe und der F\u00e4higkeit, die Werkzeuge an meine Bed\u00fcrfnisse anzupassen\nWerkzeuge an meine Bed\u00fcrfnisse anzupassen.<\/p>\n\n\n\n

Ausdrucksst\u00e4rke<\/strong> - UML bietet mir von Haus aus\neine eher begrenzte Ausdrucksf\u00e4higkeit, aber ihr Profilmechanismus\nerm\u00f6glicht es mir, die Ausdrucksm\u00f6glichkeiten nach meinen Bed\u00fcrfnissen zu erweitern. Durch die Verwendung des\n Profilmechanismus bietet mir die UML eine praktisch unbegrenzte Ausdrucks\n m\u00f6glichkeiten. Deshalb \u00fcbersetze ich das \u201cU\u201d in \u201cUML\u201d oft mit \u201cuniversal\u201d.\nF\u00fcr mich ist ein Werkzeug darf nicht<\/strong> den Profilmechanismus der UML einschr\u00e4nken.<\/p>\n\n\n\n

Ich ziehe es vor, das \u201cU\u201d in UML mit \u201cuniversal\u201d zu \u00fcbersetzen, nicht mit \u201cunified\u201d (Carsten Pitz)<\/p><\/blockquote>\n\n\n\n

Modellgr\u00f6\u00dfe<\/strong> - Die Modellierung in der f\u00fcr die Artefaktgenerierung\ndie f\u00fcr die Artefaktgenerierung erforderlich ist, f\u00fchrt zu ziemlich gro\u00dfen Modellen. Viele Tools, die ich\n versagten bei der Unterst\u00fctzung von Modellen in der f\u00fcr diese Aufgabe erforderlichen Gr\u00f6\u00dfe.<\/p>\n\n\n\n

Anpassung und Erweiterung<\/strong> - Bisher hatte ich noch keine Notwendigkeit\nein UML-Tool ernsthaft anzupassen oder zu erweitern. Das macht es f\u00fcr mich zwar schwer\nzu diesem Thema zu empfehlen, aber ich ziehe es vor, die M\u00f6glichkeit dazu zu haben.<\/p>\n\n\n\n

Papyrus: Ein Modellierungsrahmen f\u00fcr UML und SysML<\/h3>\n\n\n\n

Topcased ist eingestellt worden, und nach mehreren Inkarnationen\n(OPEES, Polarsys) scheint Papyrus der neue Renner zu sein. Ich habe\nPapyrus ausprobiert, als die Version 0.8 war und die Bewertung der Vor-1.0\n sah vielversprechend aus. In vielerlei Hinsicht folgte Papyrus h\u00f6chst kontroversen\nDesignentscheidungen, die schon zu Zeiten von Topcased diskutiert wurden.\nTopcased. Mehr noch als Topcased war Papyrus ein Satz von Werkzeugen, ein\nGer\u00fcst, das vom Kunden zusammengesetzt und konfiguriert werden musste. Aber da ich einen\nEntwicklerhintergrund war ich es gewohnt, Module zusammenzustellen und zu konfigurieren.<\/p>\n\n\n\n

Mehr noch als Topcased ist Papyrus ein Satz von Werkzeugen, ein Rahmen, der zusammengesetzt und konfiguriert werden kann (Carsten Pitz)<\/p><\/blockquote>\n\n\n\n

Streng genommen ist Papyrus nur der UML\/SysML-Editor. Was ich hier\nhier als \u201cPapyrus\u201d bezeichne, ist eigentlich ein angepasstes und erweitertes\nEclipse, mit dem Papyrus Plug-In als Kernst\u00fcck.<\/p>\n\n\n\n

Papyrus bietet die genaueste UML 2.5-Implementierung von allen UML\nWerkzeug, das ich bisher benutzt habe. Irgendwie scheint es mir, als wolle Papyrus heiliger sein\nheiliger sein als der Papst. Aber damit kann ich nicht nur gut leben, ich\nsch\u00e4tze diese Einstellung, denn Papyrus ist f\u00fcr die Modellierung sicherheits\nkritische Systeme. W\u00e4hrend die Arbeit mit Papyrus hart ist, gibt mir ig die\ndas Vertrauen, dass ich meine Arbeit richtig gemacht habe.<\/p>\n\n\n\n

Papyrus ist die bisher getreueste UML 2.5 Implementierung (Carsten Pitz)<\/p><\/blockquote>\n\n\n\n

Ich verwende den gesamten Satz von Diagrammen, den die UML bietet, einschlie\u00dflich\nDiagramme. Papyrus ist das einzige UML-Werkzeug, das ich kenne, das den\nersten Satz von Kapitel 9.6 \u201cOperationen\u201d der UML 2.5 Spezifikation respektiert:\n \u201cEine Operation ist ein BehavioralFeature, das einer Schnittstelle, einem Datentyp oder einer Klasse geh\u00f6ren kann,\n DataType oder Class.\u201d. Gerade dieser Satz ist f\u00fcr mich absolut entscheidend. Er\nerm\u00f6glicht es mir, ein Verhalten als eine Operation zu spezifizieren.<\/p>\n\n\n\n

SysML 1.4<\/h3>\n\n\n\n

Papyrus 2.x unterst\u00fctzt SysML 1.4 und optional SysML 1.1 (SysML 1.1\nUnterst\u00fctzung muss separat installiert werden). Hart arbeiten, um heiliger zu sein\nals der Papst zu sein, scheint auch die Agenda des SysML-Teams zu sein. Aber wie\nwie bereits erw\u00e4hnt, sch\u00e4tze ich diese Einstellung sehr.<\/p>\n\n\n\n

Von den SysML-Angeboten verwende ich eigentlich nur Blockdefinitionsdiagramme, interne Blockdiagramme und manchmal auch Anforderungen.<\/p>\n\n\n\n

Bei der strikten Umsetzung der SysML-Spezifikationen sind Konnektoren nur\nTeile eines Blocks verbinden. Folglich sind Konnektoren nur\nin internen Blockdiagrammen verf\u00fcgbar. Nachdem ich gelernt habe, dies zu respektieren, betrachte ich\nempfinde ich dies als Leitfaden und nicht als Einschr\u00e4nkung.<\/p>\n\n\n\n

SysML-Konnektoren d\u00fcrfen nur Teile eines Blocks verbinden. Dies dient als Leitfaden, nicht als Einschr\u00e4nkung. (Carsten Pitz)<\/p><\/blockquote>\n\n\n\n

Was noch? BPMN, Profile, OCL<\/h3>\n\n\n\n

BPMN<\/strong> - Auch wenn die Unterst\u00fctzung f\u00fcr die Business Process\nModeling Notation (BPMN) sehr vorl\u00e4ufig ist, evaluiere ich sie derzeit.\nBislang verwende ich sie nicht produktiv. Irgendwie vermisse ich Swim Lanes und w\u00fcrde\nUML-Akteure den BPMN-Swimlanes zuordnen. Aber zumindest der zweite\nAspekt ist eine Frage der BPMN-Spezifikation und keine Frage der Implementierung.<\/p>\n\n\n\n

UML-Profile<\/strong> - Wie bereits erw\u00e4hnt, ist der UML-Profil\nMechanismus f\u00fcr mich absolut unerl\u00e4sslich. Papyrus bietet mir eine in keiner Weise\nin keiner Weise verkr\u00fcppelte, ausgereifte Implementierung des UML-Profil-Mechanismus. Die\nUnterst\u00fctzung umfasst neben einer vollst\u00e4ndigen Implementierung der UML\nSpezifikation einen sehr umfassenden Mechanismus zur Profilversionierung.<\/p>\n\n\n\n

OCL<\/strong> - Die Object Constraint Language der UML (OCL) ist IMHO ein wichtiger Teil der UML-Welt. Mit OCL k\u00f6nnen Sie Einschr\u00e4nkungen definieren. Das folgende Diagramm stellt ein einfaches Beispiel dar:<\/p>\n\n\n\n

\"\"