Der heutige Gastartikel wurde von Carsten Pitz geschrieben, der seine seine Erkenntnisse über den Stand von Papyrus für die Modellierung mitteilt, was für unsere für unsere Leser interessant sein dürfte. Insbesondere als ein auf Eclipse basierendes Werkzeug, Papyrus kann integriert mit ReqIF Studio.
Dennoch hat Papyrus den Ruf, nicht industrietauglich zu sein nicht industrietauglich zu sein, schwer zu bedienen zu sein und wichtige Funktionen zu vermissen. Wie auch immer, Carstens Meinung ist jedoch eine ganz andere. Lesen Sie weiter, um herauszufinden, warum.
Papyrus - oder meine Sicht auf UML (von Carsten Pitz)
Der folgende Artikel ist eine sehr persönliche Sicht auf Papyrus. Um die richtige Grundlage zu geben, muss ich mit meinem ersten Kontakt mit mit UML im Jahr 1998 beginnen. Damals arbeitete ich bei einem großen deutschen Logistik Logistikdienstleister in einer Gruppe von vier Architekten. Unsere Aufgabe war die Erforschung und innovative Technologien zu erforschen und zu bewerten. UML wurde am 19. November 1997 als offene Spezifikation am 19. November 1997 veröffentlicht, und sie war damals neu und innovativ. Zeit.
Auch die objektorientierte Methodik (OO) war zu diesem Zeitpunkt neu. Als die Doppel-Null eine bestimmte Bedeutung hat, wurde der Begriff mit der Toilette in Verbindung gebracht - was zu einigen Belustigungen mit der der Abteilungssekretärin führte...
Also haben wir die UML 1.1-Spezifikation untersucht (UML 1.0 war Rational proprietär) und evaluierten vier UML-Tools. Diese Werkzeuge waren: Rational Rose, Together/J, Computer Associates Paradigm Plus und Sterling Software COOL:Jex.
Erforschung der UML 1.1. mit Together/J im Jahr 1998
Unsere Wahl fiel auf Together/J. Vielleicht nicht die schlechteste Wahl, denn Together/J ist das einzige Werkzeug, das von diesen Werkzeugen noch existiert. Falls Andreas W. dies liest: Hallo Andreas, ich bin mir der Tatsache bewusst, dass Sterling Software COOL:Jex zu Telelogic Tau wurde, das wiederum zu IBM Rational Rhapsody wurde. Aber die Änderungen an COOL:Jex waren viel einschneidender wie bei Together/J.
Trotz der Tatsache, dass Together/J das einzige dieser Werkzeuge ist, das mehr oder weniger so existiert wie 1998, muss ich aus der Retroperspektive Ich muss zugeben, dass die Wahl von Together/J stark von unserem gemeinsamen Entwicklungshintergrund gemeinsam hatten.
Dennoch passte Together/J perfekt zu unseren damaligen Bedürfnissen. Die Round-Trip-Engineering, das Together/J schon 1998 bot, ist auch heute noch auch heute noch mit keinem anderen Tool zu vergleichen.
Fokus auf Struktur
Da wir einen starken Entwicklungshintergrund haben, lag unser Schwerpunkt auf der Struktur, genauer gesagt genauer gesagt auf Klassendiagramme. Diese einfachen Klassendiagramme haben uns sehr geholfen sehr geholfen, Ideen zu visualisieren und zu diskutieren (Carsten Pitz)
Einfache Klassendiagramme sind sehr hilfreich, um unsere Ideen zu visualisieren und zu diskutieren.
Noch eine Information zu meiner Person. Der älteste und bei weitem erfahrenste erfahrenste Entwickler unseres Teams nahm mich eines Morgens zur Seite und sagte mir: “Deine Entwürfe sind irgendwie seltsam. Deine Entwürfe respektieren perfekt alle OO-Regeln, die mir bekannt sind. Aber irgendwie weigere ich mich, Ihre Entwürfe als objekt orientieren. Ich habe lange darüber nachgedacht und bin gestern Abend auf die Idee gekommen. Ihre Entwürfe sind komponentenbasiert.”. Nach einiger Zeit antwortete ich: “Ja, meine Entwürfe sind komponentenbasiert. Ich bin Ingenieur und als Ingenieur denke ich denke ich in wiederverwendbaren Komponenten, die über gut definierte Schnittstellen kommunizieren.”
Ich analysierte meine Entwürfe und verglich sie mit den Entwürfen der anderen Architekten aus unserer Gruppe. Ich war der Einzige, der Schnittstellen und Pakete. Ich führte spezielle Klassen ein, die ich Schnittstellenklassen nannte. Heute wird diese Art von Klassen gemeinhin als Fassaden bezeichnet. Diese Schnittstellenklassen habe ich in Schnittstellenklassenpaketen zusammengefasst. Die einzigen öffentlichen Pakete der Komponenten.
Fokus auf Verhalten
Später, im Jahr 2002, änderte sich mein Umfeld. Ich musste die Implementierungsoptionen Implementierungsoptionen mit Kunden diskutieren und nicht nur innerhalb eines Architektenteams. Sogar Programmcode ist zwar die genaueste Notation, um Verhalten auszudrücken, sind die meisten Kunden mit geschäftlichem Kontext nicht in der Lage, Programmcode zu verstehen. Code zu verstehen. Daher hat die Beschreibung von Verhalten mit der UML-Notation bald mein mein Modellierungsportfolio.
Zustandsdiagramme und Sequenzdiagramme können so entworfen und dargestellt werden, dass die Kunden sie verstehen. Das war gut.
Artefakt-Generierung
Da ich im Grunde meines Herzens Ingenieur bin, tut es mir wirklich weh, ein Stück der Arbeit wegzuwerfen. Das führt mich zur Artefakterzeugung. Mein ursprüngliches Tooling zur um dies zu erreichen, waren ArgoUML & AndroMDA. ArgoUML ist ein UML-Modellierungs Werkzeug. AndroMDA ist ein Modell zu Text, ein M2T-Konverter. Aber ArgoUML wurde nicht migriert, um UML2 zu unterstützen.
UML2 und die Meta-Objekt-Funktion
Für mich kam UML2 genau zum richtigen Zeitpunkt. UML2 bot mir einen aufgeräumten Profilmechanismus und ein aufgeräumtes UML-Metamodell, die Meta-Object Facility (MOF). Die MOF entwickelte sich zu etwas wirklich Nützlichem für mich. Aber wie ich bereits erw??hnt habe, wurde ArgoUML nicht auf UML2 migriert.
Ich habe mehrere verschiedene Werkzeugkonfigurationen ausprobiert. Eclipse Topcased entsprach meinen Bedürfnisse am besten, also blieb ich bei Topcased. Topcased verwendete Acceleo als Artefaktgenerator, so dass ich begann, MOFM2T - die Notation der OMG zur Modelle in Text zu transformieren - als Transformationssprache zu verwenden.
Anwendungsfälle
Wie ich schrieb in einem Blogbeitrag bei SE-Trends (Anwendungsfälle brachten mich dazu, Objekte als Akteure zu betrachten, Architektur als Choreographie von Akteuren. Dieses Prinzip erwies sich als äußerst wirkungsvoll.
Trotzdem habe ich die Anwendungsfälle vergessen, einfach weil ich keinen Bedarf für sie hatte. Zu dieser Zeit schien niemand, nicht einmal in der Wissenschaft, sie zu verwenden auch nicht.
Mein Interesse an Anwendungsfällen wurde geweckt, als ich mich mit einer großen Menge von Anforderungen zu tun hatte. Wenn ich mich richtig erinnere, sammelten in diesem Projekt die Anforderungsingenieure etwa 17.000 Anforderungen von fragwürdiger Qualität.
Ich habe darüber nachgedacht und nach einer Weile habe ich - mehr aus Instinkt als aus Ratio - begonnen, Anwendungsfälle zu definieren und den definierten Anwendungsfällen Anforderungen Anwendungsfällen zuzuordnen. Dieser Ansatz erwies sich als erfolgreich. Also beauftragte ich die anderen Architekten an, mir dabei zu helfen. Es funktionierte. Wir entwickelten recht schnell ein Verständnis dafür, was zu tun war.
Über Werkzeuge und ihre Grenzen
Wie Sie vielleicht schon bemerkt haben, war meine Werkzeuggeschichte vielfältig und ziemlich disruptiv. Mit meinem starken Entwicklerfokus begann ich mit Together/J, wegen seiner unübertroffenen Round-Trip-Engineering-Funktionen. Mein Bedarf an Artefaktgenerierung führte mich zur Kombination von ArgoUML und AndroMDA. Und um an den Vorteilen der UML2 gegenüber der UML1 teilzuhaben, wechselte ich zu Topcased.
Darüber hinaus habe ich viele so genannte “UML”-Tools ausprobiert. Alle diese anderen Werkzeuge empfand ich als Gefängnisse, genauer gesagt als Sammlungen von Einschränkungen. Diese Beschränkungen äußern sich als Einschränkungen in Ausdrucksstärke, Modellgröße und der Fähigkeit, die Werkzeuge an meine Bedürfnisse anzupassen Werkzeuge an meine Bedürfnisse anzupassen.
Ausdrucksstärke - UML bietet mir von Haus aus eine eher begrenzte Ausdrucksfähigkeit, aber ihr Profilmechanismus ermöglicht es mir, die Ausdrucksmöglichkeiten nach meinen Bedürfnissen zu erweitern. Durch die Verwendung des Profilmechanismus bietet mir die UML eine praktisch unbegrenzte Ausdrucks möglichkeiten. Deshalb übersetze ich das “U” in “UML” oft mit “universal”. Für mich ist ein Werkzeug darf nicht den Profilmechanismus der UML einschränken.
Ich ziehe es vor, das “U” in UML mit “universal” zu übersetzen, nicht mit “unified” (Carsten Pitz)
Modellgröße - Die Modellierung in der für die Artefaktgenerierung die für die Artefaktgenerierung erforderlich ist, führt zu ziemlich großen Modellen. Viele Tools, die ich versagten bei der Unterstützung von Modellen in der für diese Aufgabe erforderlichen Größe.
Anpassung und Erweiterung - Bisher hatte ich noch keine Notwendigkeit ein UML-Tool ernsthaft anzupassen oder zu erweitern. Das macht es für mich zwar schwer zu diesem Thema zu empfehlen, aber ich ziehe es vor, die Möglichkeit dazu zu haben.
Papyrus: Ein Modellierungsrahmen für UML und SysML
Topcased ist eingestellt worden, und nach mehreren Inkarnationen (OPEES, Polarsys) scheint Papyrus der neue Renner zu sein. Ich habe Papyrus ausprobiert, als die Version 0.8 war und die Bewertung der Vor-1.0 sah vielversprechend aus. In vielerlei Hinsicht folgte Papyrus höchst kontroversen Designentscheidungen, die schon zu Zeiten von Topcased diskutiert wurden. Topcased. Mehr noch als Topcased war Papyrus ein Satz von Werkzeugen, ein Gerüst, das vom Kunden zusammengesetzt und konfiguriert werden musste. Aber da ich einen Entwicklerhintergrund war ich es gewohnt, Module zusammenzustellen und zu konfigurieren.
Mehr noch als Topcased ist Papyrus ein Satz von Werkzeugen, ein Rahmen, der zusammengesetzt und konfiguriert werden kann (Carsten Pitz)
Streng genommen ist Papyrus nur der UML/SysML-Editor. Was ich hier hier als “Papyrus” bezeichne, ist eigentlich ein angepasstes und erweitertes Eclipse, mit dem Papyrus Plug-In als Kernstück.
Papyrus bietet die genaueste UML 2.5-Implementierung von allen UML Werkzeug, das ich bisher benutzt habe. Irgendwie scheint es mir, als wolle Papyrus heiliger sein heiliger sein als der Papst. Aber damit kann ich nicht nur gut leben, ich schätze diese Einstellung, denn Papyrus ist für die Modellierung sicherheits kritische Systeme. Während die Arbeit mit Papyrus hart ist, gibt mir ig die das Vertrauen, dass ich meine Arbeit richtig gemacht habe.
Papyrus ist die bisher getreueste UML 2.5 Implementierung (Carsten Pitz)
Ich verwende den gesamten Satz von Diagrammen, den die UML bietet, einschließlich Diagramme. Papyrus ist das einzige UML-Werkzeug, das ich kenne, das den ersten Satz von Kapitel 9.6 “Operationen” der UML 2.5 Spezifikation respektiert: “Eine Operation ist ein BehavioralFeature, das einer Schnittstelle, einem Datentyp oder einer Klasse gehören kann, DataType oder Class.”. Gerade dieser Satz ist für mich absolut entscheidend. Er ermöglicht es mir, ein Verhalten als eine Operation zu spezifizieren.
SysML 1.4
Papyrus 2.x unterstützt SysML 1.4 und optional SysML 1.1 (SysML 1.1 Unterstützung muss separat installiert werden). Hart arbeiten, um heiliger zu sein als der Papst zu sein, scheint auch die Agenda des SysML-Teams zu sein. Aber wie wie bereits erwähnt, schätze ich diese Einstellung sehr.
Von den SysML-Angeboten verwende ich eigentlich nur Blockdefinitionsdiagramme, interne Blockdiagramme und manchmal auch Anforderungen.
Bei der strikten Umsetzung der SysML-Spezifikationen sind Konnektoren nur Teile eines Blocks verbinden. Folglich sind Konnektoren nur in internen Blockdiagrammen verfügbar. Nachdem ich gelernt habe, dies zu respektieren, betrachte ich empfinde ich dies als Leitfaden und nicht als Einschränkung.
SysML-Konnektoren dürfen nur Teile eines Blocks verbinden. Dies dient als Leitfaden, nicht als Einschränkung. (Carsten Pitz)
Was noch? BPMN, Profile, OCL
BPMN - Auch wenn die Unterstützung für die Business Process Modeling Notation (BPMN) sehr vorläufig ist, evaluiere ich sie derzeit. Bislang verwende ich sie nicht produktiv. Irgendwie vermisse ich Swim Lanes und würde UML-Akteure den BPMN-Swimlanes zuordnen. Aber zumindest der zweite Aspekt ist eine Frage der BPMN-Spezifikation und keine Frage der Implementierung.
UML-Profile - Wie bereits erwähnt, ist der UML-Profil Mechanismus für mich absolut unerlässlich. Papyrus bietet mir eine in keiner Weise in keiner Weise verkrüppelte, ausgereifte Implementierung des UML-Profil-Mechanismus. Die Unterstützung umfasst neben einer vollständigen Implementierung der UML Spezifikation einen sehr umfassenden Mechanismus zur Profilversionierung.
OCL - Die Object Constraint Language der UML (OCL) ist IMHO ein wichtiger Teil der UML-Welt. Mit OCL können Sie Einschränkungen definieren. Das folgende Diagramm stellt ein einfaches Beispiel dar:
MOFM2T - Die Transformationstechnologie für MOF-Modelle (Model Object Facility) wurde bereits früher erwähnt. Ich verwende MOFM2T direkt über Acceleo zur Artefakte zu erzeugen und indirekt über GenDoc, um Dokumentation zu erzeugen. Trotz der Tatsache, dass die Versionsnummer von GenDoc v0.60 ist und noch kleinere Probleme hat, fange ich an, es in einer produktiven Umgebung zu verwenden.
Acceleo von Obeo ist ein Code-Generator, der ein sehr ausgereiftes Tool ist, auf das ich mich voll und ganz verlasse.
ReqCycle ist eine Erweiterung zur Verfolgung von Anforderungen an Papyrus. ReqCycle ist hochgradig konfigurierbar und schränkt Sie nicht ein. Bisher schätze ich ReqCycle sehr, da es die Zuweisung von Anforderungen zu Elementen nicht einschränkt. ReqCycle sehr zu schätzen. Aber ich vermisse einige wichtige Funktionen. Für Wie kann ich zum Beispiel die Anzahl der erfüllten, offenen oder veralteten Anforderungen?
Meine Probleme mit Papyrus
An dieser Stelle sollte es offensichtlich sein, dass ich nicht nur ein Fan von Papyrus bin, sondern es auch für produktionsreif halte. Abgesehen davon gibt es Raum für Verbesserungen. Hier ist die Liste der Trauben, die ich mit dem Werkzeug:
Lollipop-Notation - Die Lollipop-Notation für Schnittstellen hat einige Probleme. Genau dieses Problem wurde neunmal aufgezeichnet im Bug-Tracker und wurde bisher noch nicht gelöst.
Meldungen in Zeitdiagrammen - Ich habe bis jetzt noch nicht herausgefunden, wie man das mit Papyrus 2 oder 3 machen kann. Ich habe es erneut mit den Versionen 2.0.2 und 3.0 M4 ohne Erfolg. Es funktionierte perfekt mit Papyrus 1. Aber mit Papyrus 2 und auch 3 scheint eine Nachricht zwischen Ereignissen nur ihren Startpunkt zu akzeptieren, aber nicht ihren Endpunkt.
Das folgende Diagramm demonstriert dies anhand eines fiktiven, einfachen Zeitdiagramms, das mit Papyrus Version 1.1.4 erstellt wurde, wobei Nachrichten zwischen Ereignissen rot hervorgehoben sind:
Nachrichten zwischen Lebenslinien sind in Abbildung 17.30 “Zeitdiagramm mit mehr als einer Lebenslinie und mit Nachrichten” der UML 2.5 Spezifikation dargestellt. I eine Ausgabe eingereicht für diese. Für mich ist es kein Hindernis, aber dennoch ein Problem.
Verschachtelte Häfen - Bisher war ich nicht in der Lage, verschachtelte Ports zu modellieren. Aber wie ich verstanden habe, ist dies Funktion ist noch in Arbeit. Ich schätze verschachtelte Ports sehr, wenn es zum Beispiel darum geht, eine Satz von BDDs und IDBs, die eine Hardware darstellen, in eine Eingabedatei für ein PCB-Layout-Systems.
GenDoc wird für die Dokumentenerstellung verwendet. Wenn der Text aus einem eigenen Kommentar generiert, der dynamische Verweise auf Elementen enthält, wird der Link nicht aufgelöst.
Was ist mit den Kritikern?
Es hat einige Kritik an Papyrus gegeben, einige davon berechtigt, einige aufgrund von Missverständnissen. Ich werde mich zu einigen der vorherrschenden Probleme.
Rahmenwerk vs. Produkt von der Stange - Ich erwähnte diesen Punkt bereits erwähnt. Aber, soweit ich verstanden habe, ist Papyrus dafür gedacht Bedürfnisse zu erfüllen, die weit über den Umfang anderer so genannter High-End UML/SysML Modellierungswerkzeugen. Dies erfordert, dass Papyrus anpassbar und erweiterbar ist. erweiterbar sein. Diese beiden Anforderungen können IMHO einfach nicht von einem monolithisches Design. Sie können mich gerne eines Besseren belehren.
Einfacher Gebrauch - Papyrus ist nicht nur das, was ich bezeichne als “ein sogenanntes “UML” Werkzeug”, Papyrus ist ein echtes UML Werkzeug. Und Papyrus ist ein Werkzeug und auf keinen Fall ein Spielzeug. Meine Frau hat kürzlich eine Kettensäge gekauft. Sogar ein so einfaches Werkzeug wie eine Kettensäge erfordert, dass die Benutzer wissen, wie man es zu benutzen. Aber im Gegensatz zu einem UML-Modellierungswerkzeug ist eine Kettensäge ein gnadenloses Werkzeug. Wenn Sie nicht wissen, wie man sie benutzt, verlieren Sie höchstwahrscheinlich buchstäblich ein Bein oder einen Arm. Daher ist der Schmerz, den diese Vorstellung verursacht die meisten Benutzer dazu, die Grundlagen zu lernen, bevor sie ihre Kettensäge benutzen. Kettensägen. Das Gleiche gilt für ein Modellierungswerkzeug: Der Benutzer muss mit der Modellierungsnotation und mit der Modellierung vertraut sein.
Ein Architekt, der mit der UML-Notation vertraut ist, wird keine größeren Probleme haben bei der Beherrschung von Papyrus. Aber um mit der UML-Notation vertraut zu sein, muss man dass man die UML-Spezifikation liest und versteht, was nicht trivial ist. Nach meiner Wahrnehmung kennt höchstens einer von hundert Leuten, die behaupten die behaupten, mit der UML vertraut zu sein, überhaupt wissen, dass es eine Spezifikation gibt. Ohne Urteil ist das für mich einfach zu enttäuschend.
Meiner Einschätzung nach weiß nur einer von hundert UML-Anwendern, dass es eine UML-Spezifikation gibt.
Viele “UML”-Benutzer betrachten UML als das, was ich als “Zeichnungen” bezeichne. Schlimmer noch, “Zeichnungen” werden oft gefordert. Entschuldigung, meiner Meinung nach ist ein UML-Modell ist nicht bunt, nicht sexy in irgendeiner Weise. Ein UML-Modell ist eine eher abstrakte, (semi-)formale Beschreibung eines Plans, sonst nichts. Nur nur sehr wenige Kunden sind heute bereit, dies zu akzeptieren. Vergleichen Sie dies mit den frühen 2000er Jahren, wo die Kunden viel eher bereit waren, dies zu akzeptieren. I halte dies für ein gesellschaftliches Problem.
Papyrus entwickelt sich weiter
Papyrus entwickelt sich schnell weiter. Die aktuelle Version ist 2.0.2 (Stand: 7. Dezember, 2016). Meilenstein 4 der Version 3 wurde am 14. Dezember 2016 veröffentlicht und die finale Version 3 wird voraussichtlich am 3. Juli 2017 zusammen mit mit Eclipse Oxygen. Version 1 war dazu gedacht, es zum Laufen zu bringen, Version 2 um die GUI zu verbessern, und Version 3 für die volle Unterstützung von Model-to-Model Transformationen (M2M). Bislang habe ich nur Model-to-Text-Transformationen verwendet. M2M wird eine neue Welt für mich eröffnen.
Das Papyrus Team ist auch sehr entgegenkommend, wie die Links zu Einträgen im Papyrus Bug Tracker in diesem Artikel zeigen. Die Entwickler antworten auf diese, die Kommunikation ist keineswegs ein Monolog, sondern ein Dialog.
Ich habe gelernt: “Danke” zu sagen”
Wir Deutschen sind dafür bekannt, dass wir uns beschweren. In dieser Hinsicht bin ich Deutscher. Wir Deutschen sind auch dafür bekannt, dass wir nicht sagen: “Danke”. Aber Ich praktiziere, und werde hart daran arbeiten, meine Fähigkeiten auf diese Weise zu verbessern. Versprochen. Danke!.
