Steigern Sie Ihre Produktivität mit modellgetriebener Entwicklung (Teil 1)

Einführung

Wenn wir nach unserem Beruf gefragt werden, sind wir als Entwickler nicht gerade wählerisch. Wir können uns auf verschiedene Weise beschreiben: "Softwareentwickler", "Computerprogrammierer", "Informatiker", "Programmierer", "Softwareingenieur" oder andere, speziellere Rollen wie "Softwarearchitekt", "DevOps-Ingenieur", "Entwicklerberater" usw. Manchmal verwenden wir diese Begriffe austauschbar oder wählen den Begriff, der uns am meisten zusagt. Aber wenn man darüber nachdenkt, ist "Computerprogrammierer" wirklich dasselbe wie ein "Softwareingenieur"? In vielen Fällen kann das der Fall sein. Wie viele, wenn nicht sogar die meisten Entwickler, habe ich großen Spaß am Programmieren. Es ist zweifellos der Eckpfeiler unseres Berufs und das, was viele von uns zu diesem Beruf hingezogen hat.

Es ist jedoch wichtig zu erkennen, dass dieser Bereich auf Abstraktionen beruht. Oberflächlich betrachtet hat sich die Arbeit eines Computerprogrammierers seit den Anfängen mit Lochkarten drastisch verändert. Die meisten von uns beherrschen weder die Assembler- noch die C-Sprache, die damals (und auch heute noch) als "höhere" Programmiersprache gilt. Die Aufgabe eines Programmierers (oder "Coders") besteht letztendlich darin, Anweisungen an die zugrunde liegende Hardware weiterzugeben, um bestimmte Operationen durchzuführen. Die meisten von uns denken jedoch nicht auf diese Weise über ihre tägliche Arbeit nach. Stattdessen denken wir auf einer höheren Abstraktionsebene - in Form von Lösungen. Das Programmieren, so unterhaltsam und anspruchsvoll es auch sein mag, ist also ein Mittel zum Zweck. Daher ist der Begriff "Software-Ingenieur" ein umfassenderer Sammelbegriff für den gesamten Entwicklungsprozess. Wenn Software-Engineering wie der Bau eines Hauses ist, dann ist das Programmieren der Teil, der die Steine legt.

Leider macht das Programmieren nicht immer Spaß oder fördert die Problemlösung. Vor allem bei wortreichen Sprachen wie Java ist es oft eine lästige Pflicht. Dies ist das Ergebnis von "Boilerplate": Code, der sich wiederholt und mühsam von Hand geschrieben werden muss, aber dennoch notwendig und nützlich ist. Dies ist oft der am wenigsten produktive Aspekt der Programmierung und zufälligerweise auch der am besten automatisierbare. Obwohl IDEs gut darin sind, gängige Boilerplates wie Getter und Setter zu erzeugen, toString(), equals und hashCode()zu generieren, können sie nur die allgemeinen Bedürfnisse der Sprache, nicht aber des Bereichs abdecken. Wenn es doch nur einen Weg gäbe, den mühsamen Prozess des handschriftlichen Verfassens von domänenspezifischem Boilerplate zu umgehen...

Was ist modellgetriebenes Engineering?

Model-Driven Engineering (MDE) ist eine Disziplin, die Modelle zu Artefakten erster Klasse im Entwicklungsprozess machen und dabei die Abstraktionsebene erhöhen. Auf die Softwareentwicklung angewandt bedeutet dies, dass anstelle von Quellcode das primäre Artefakt von Interesse ist, sondern das Domänenmodell im Vordergrund steht.

Obwohl MDE oft ein akademischer Begriff und eine akademische Disziplin ist, hat sie durch den Begriff "Low-Code" mehr Aufmerksamkeit erlangt - etwas, das auch Akademikern bekannt ist. Man könnte argumentieren, dass MDE breiter angelegt ist als die Low-Code-Bewegung, aber in der Praxis sind diese Unterschiede in der Semantik oft von akademischem Interesse - entschuldigen Sie das Wortspiel!

Sie fragen sich jetzt vielleicht: Was ist ein Modell? Nun, es ist alles, was den Bereich deklarativ beschreibt. Sie können sich ein Modell als domänenspezifische Daten vorstellen. Das Entscheidende ist, dass diese Daten auf vorhersehbare Weise strukturiert sind. In der MDE-Sprache nennen wir diese Struktur das Metamodell. Das Metamodell ist selbst ein Modell, das den "Bauplan" für die Domäne beschreibt - ähnlich wie der Bauplan eines Architekten eine Anleitung für den Bau eines Gebäudes darstellt. Um dies zu verdeutlichen, lassen Sie uns einige Beispiele betrachten.

Metamodelle

Die Idee eines Metamodells besteht darin, das einzuschränken, was bei der Verwendung von Allzweckwerkzeugen und -sprachen ausgedrückt werden kann. Beispiele für Metamodellierungstechnologien sind XML-Schema (XSD), JSON-Schema oder jedes Datenbankschema. Das stimmt: Wenn Sie schon einmal mit einer relationalen Datenbank, einem XML-Dokument oder einer Konfigurationsdatei gearbeitet haben, ist Ihnen dieses Konzept bereits vertraut, auch wenn Sie es vielleicht nicht in diesem Sinne verstanden haben.

Es gibt eine Fülle von Beispielen, die ich aus Gründen der Kürze und zur Veranschaulichung hier nicht direkt anführen werde. Aber wenn Sie anfangen, über Schemata als Metamodelle und strukturierte Daten, die mit diesen Schemata konform sind, als Modellemacht das intuitiv Sinn. Betrachten Sie die "CustomersOrders.xsd"-Datei aus diesem Lernprogramm. Diese Datei modelliert effektiv die Domänenkonzepte und ihre Beziehungen zueinander. Die Datei "Datei "CustomersOrder.xml ist eine Instanz dieser Datei - ein Modell das mit dem Metamodell "CustomersOrders.xsd" übereinstimmt Metamodell. Wenn Sie mit der objektorientierten Programmierung vertraut sind, können Sie sich Metamodelle als Klassen und Modelle als Objekte (d.h. Instanzen dieser Klassen) vorstellen. In der objektorientierten Programmierung definiert eine Klasse das Schema für konkrete Instanzen (Objekte). Ein weiteres Beispiel ist dieses minimale JSON-Schema. Es definiert eine Person, die drei Eigenschaften hat: firstName, lastName und age.

Ist Ihnen in beiden Fällen aufgefallen, dass das Metamodell selbst in der gleichen Sprache wie das Modell geschrieben ist? Das heißt, eine XSD-Datei verwendet die gleiche Syntax wie XML, und ein JSON-Schema ist selbst in JSON geschrieben! Daraus ergibt sich, dass Metamodelle selbst Modelle sind, die mit einem Meta-Metamodell. Verblüffend, nicht wahr? Mit anderen Worten, es gibt ein Schema für das Metamodell. Zum Glück ist in den meisten Fällen mit diesem Meta-Metamodell auf oberster Ebene Schluss. Meta-Metamodelle sind normalerweise mit sich selbst konform. Kein Scherz - es gibt buchstäblich eine XSD-Datei, die das Metamodell für XSDs definiert!

Eclipse Modellierungsrahmen

Nach der Definition des Hauptkonzepts des modellgesteuerten Engineerings wollen wir uns nun einigen Werkzeugen zuwenden. Obwohl Schemata und Modelle mit konventionellen Werkzeugen und Serialisierungsformaten wie JSON und XML definiert werden können (und oft auch werden), wäre es für eine wirkliche Nutzung von MDE von Vorteil, mit den speziellen Werkzeugen vertraut zu sein, die von MDE-Experten verwendet werden. Aufgrund der Geschichte von MDE mit ihren stark akademischen und unternehmerischen Wurzeln hat die Eclipse-Stiftung weithin als die Heimatplattform für die etabliertesten MDE-Tools angesehen. Von zentraler Bedeutung ist dabei das Eclipse-Modellierungsrahmen (EMF). Im Kern definiert das Projekt einen Rahmen für die Definition von Metamodellen und Werkzeugen für die programmatische Arbeit mit ihnen in Java. Wie Sie vielleicht schon erraten haben, beinhaltet es das Meta-Metamodell - namens Ecore. Hier ist ein vereinfachtes Diagramm der wichtigsten Konzepte und der Hierarchie von Ecore:

Es gibt natürlich noch viel mehr zu tun - hier ist ein ausführlicheres UML-Digramm. Aber keine Sorge - das ist nichts, was Sie unbedingt wissen müssen. Es handelt sich um Concepts, die bei der Verwendung von Ecore zur Definition Ihres Metamodells intuitiv werden. Natürlich gibt es auch Tutorials für EMF online verfügbar, obwohl einige ziemlich veraltet sein können. Sie sind immer noch relevant, da EMF seit langem stabil ist.

Sie können Ecore-Metamodelle mit dem eingebauten Baumeditor, mit visuellen Sprachen wie UML oder mit textuellen Sprachen wie Emfaticdie viel einfacher zu handhaben sind als das XML, das allen Ecore-Metamodellen zugrunde liegt. Unternehmenstaugliche Werkzeuge wie Papyrus und Sirius bauen auf EMF auf und bieten noch leistungsfähigere Funktionen für die Arbeit mit Modellen. Sie können Ihr Metamodell sogar als Grammatik für eine domänenspezifische Sprache definieren, indem Sie Xtext.

Das ist eine Menge, die Sie verarbeiten müssen! Die Idee ist, Ihnen einen Überblick über die verfügbaren Werkzeuge und Technologien zu geben. Wie Sie sehen können, sind die MDE-Werkzeuge und ihre Prinzipien ziemlich reichhaltig, gut etabliert und relativ ausgereift. Sie können Ihre Modelle und Metamodelle grafisch oder textuell definieren, und da ein Großteil der Werkzeuge auf EMF aufbaut, können Sie, sobald Sie Ihr Metamodell definiert haben, Java-Code daraus generieren und programmatisch damit arbeiten, wenn Sie möchten.

Modell-Management

Nun, da Sie mit der Metamodellierung und den Werkzeugen zur Definition von (Meta-)Modellen vertraut sind, fragen Sie sich vielleicht zu Recht: Was nun? Was kann ich tun mit diesen Modellen machen? Warum sollte ich so viel Zeit und Mühe in die Definition eines Schemas investieren, das letztlich die Möglichkeiten einschränkt, die ich mit einer allgemeinen Sprache ausdrücken kann? Nun, genau hier liegt der wahre Wert von MDE. Das Metamodell ist notwendig, damit Sie mit Modellen auf einer abstrakten Ebene arbeiten können. Modell-Management ist der Prozess des Handelns mit Modellen. Zu diesen Aufgaben gehören die folgenden:

• Visualisierung: Präsentation verschiedener Ansichten und grafischer Darstellungen eines Modells für unterschiedliche Zwecke und Zielgruppen.

• Abfrage von: Abrufen von Daten aus dem Modell, was oft rechenintensive Ausdrücke erfordert.

• Validierung: Metamodelle sind oft nicht leistungsfähig genug, um alle Einschränkungen eines Domänenmodells auszudrücken, so dass zusätzliche programmatische Logik erforderlich ist, um sicherzustellen, dass die Modelle wohlgeformt sind.

• Vergleich: Vergleich von Modellen und programmatisches Vorgehen bei Unterschieden.

• Zusammenführung: Aus mehreren Eingabemodellen wird ein einziges Ausgabemodell erstellt.

• Migration: Abbildung eines Modells auf eine weiterentwickelte Version des Metamodells.

• Umwandlung: Modifizierung eines Modells oder Erstellung eines anderen Ausgabemodells (das einem anderen Metamodell entsprechen kann).

• Text-Erzeugung: Verwendung von Modellen zur Generierung von Textausgaben, z. B. Quellcode und Dokumentation.

Wie Sie vielleicht schon vermutet haben, gibt es auch Werkzeuge für all diese Aufgaben. Die de-facto Sprache für die Validierung von Modellen, die über die Fähigkeiten von Ecore hinausgehen, ist die Objektbeschränkungssprache (OCL). Sie können Sie können mehr darüber in einem einführenden Tutorium erfahrenerfahren, so dass ich mich hier nicht mit den Einzelheiten befassen werde. Es ist jedoch nützlich, sich bewusst zu machen, dass viele andere Modellverwaltungssprachen auf den Ausdrücken, der Syntax und der Semantik von OCL aufbauen oder von ihnen inspiriert sind. Die Literatur über Modell-zu-Modell-Transformationen ist sehr umfangreich und oft recht komplex, da dies der zentrale Forschungsbereich in der Wissenschaft für MDE ist. Es gibt natürlich Sprachen für Modelltransformationen, wie z.B. ATL und QVTaber auf diese wollen wir nicht näher eingehen.

Was müssen wir als Entwickler also wirklich wirklich wichtig? Produktivität, richtig? Das ist die Prämisse der gesamten Diskussion. Da ein Großteil unseres Tagesablaufs mit dem Schreiben von Dokumentation und Standardcode verbracht wird, möchten wir so viel wie möglich davon automatisch generieren lassen, damit wir uns auf die Dinge konzentrieren können, die Spaß machen und die mehr Aufmerksamkeit bzw. technisches Fachwissen erfordern. Hier kann die Modell-zu-Text-Transformation helfen. Es gibt Standards, wie z.B. MOF M2T und Werkzeuge, die ihnen entsprechen, wie zum Beispiel Acceleoaber vielleicht sind Sie auch mit konventionelleren Werkzeugen vertraut, wie z. B. Jakarta Server Pages (JSP). Java im Web klingt zwar wie ein Relikt aus den frühen 2000er Jahren, aber das Prinzip dahinter ist immer noch gültig. Schließlich ist die PHP-Sprache steht wörtlich für "Hypertext Preprocessor" und ist immer noch weit verbreitet. Aber was haben JSP und PHP mit Codegenerierung und modellgesteuertem Engineering zu tun? Damit werden wir uns in Teil 2 dieses Blogbeitrags befassen. Zuvor wollen wir einen Blick auf ein Tool werfen, mit dem wir dies demonstrieren wollen.

Epsilon

Wir haben uns kurz mit den wichtigsten Concepts in MDE und einigen Werkzeugen beschäftigt, aber wie passt das alles zusammen? Wir haben verschiedene Metamodellierungstechnologien, so dass Modelle in verschiedenen Formaten vorliegen können, doch die meisten der bisher erwähnten Werkzeuge basieren auf EMF. Da außerdem für jede Modellverwaltungsaufgabe ein eigenes Tool mit unterschiedlicher Syntax und Semantik für die Definition der Abfrage-/Transformationslogik zur Verfügung steht, könnte man meinen, dass MDE angesichts der steilen Lernkurve zu komplex und schwerfällig ist. Es gibt jedoch ein Projekt (natürlich auf Eclipse-Basis), das darauf abzielt, die verschiedenen Modellierungstechnologien und Modellverwaltungsaufgaben zu vereinheitlichen: Epsilon. Um es ganz offen zu sagen: Ich habe während meiner Promotion intensiv an Epsilon mitgearbeitet, daher bin ich natürlich etwas voreingenommen!

Ich werde mich nicht lange damit aufhalten, Epsilon und seine Architektur zu erklären, sondern überlasse dies der die Dokumentationüberlassen, aber ich werde eine kurze Einführung geben. Im Grunde bietet Epsilon eine Familie von aufgabenspezifischen Modellverwaltungssprachen, die auf einer gemeinsamen Kernabfragesprache namens EOL. Diese ist von der OCL-Syntax inspiriert, verhält sich aber viel mehr wie Java, da sie in Java implementiert ist und die Reflection-Fähigkeiten von Java intensiv nutzt. Sie können sogar nativen Java-Code von EOL aus aufrufen, so dass EOL im Wesentlichen eine vollständige Programmiersprache mit allen üblichen imperativen Programmierkonstrukten sowie deklarativen Operationen für die Arbeit mit Sammlungen ist.

Entscheidend ist, dass Epsilon auch mehrere Modellierungstechnologien unterstützt und nicht an EMF gebunden ist. Obwohl Epsilon EMF-Modelle sehr gut unterstützt und sich mit anderen EMF-Werkzeugen integrieren lässt, ist der Modell-Verbindungsschicht bedeutet, dass die Sprachen vom zugrundeliegenden Modellpersistenzformat entkoppelt sind, so dass Sie es mit verschiedenen Modelltypen wie XML, CSV und anderen Tabellenkalkulationsformaten, JDBC-kompatiblen Datenbanken, Simulink und anderen verwenden können. Simulink und mehr. Somit bietet Epsilon eine All-in-One-Lösung für die Modellverwaltung, ohne dass Sie mit verschiedenen Tools auf der Grundlage der Modellierungstechnologie arbeiten müssen. Sie können sogar mehrere Modelle unterschiedlichen Typs innerhalb desselben Programms kombinieren und auf einheitliche Weise mit ihnen arbeiten.

Das ist alles für den Moment...

Puh, das ist eine Menge, die man verarbeiten muss! Aber ich verspreche, dass im nächsten Teil alles anhand eines praktischen Beispiels zusammenkommen wird. Insbesondere werde ich demonstrieren, wie ich Epsilon verwendet habe, um das Schreiben eines großen Teils des Boilerplate-Codes für das Java-SDK von Vonage effektiv zu automatisieren.

Wenn Sie Kommentare oder Vorschläge haben, können Sie sich gerne an uns wenden auf X, früher bekannt als Twitter oder besuchen Sie unseren Gemeinschaft Slack. Ich hoffe, dass dieser Artikel nützlich war und freue mich über alle Gedanken und Meinungen. Wenn er Ihnen gefallen hat, lesen Sie bitte auch meine anderen Java-Artikel.