Jetzt, da die Grundlagen der Modellierung in Teil 1 behandelt wurden, können wir uns etwas anderes ansehen, das itemis regelmäßig tut, um knifflige Probleme zu lösen: Language Engineering.
Wie wir gesehen haben, impliziert die Modellierung immer das Vorhandensein eines zugrunde liegenden Metamodells. In der LEGO® Welt umfasst das Metamodell die verschiedenen Arten, Formen und Farben der Bausteine und die Prinzipien, wie sie verbunden werden können. Das Metamodell eines jeden LEGO®-Sets wird also durch die Art der Teile definiert, die in der Box enthalten sind, und durch die Prinzipien, wie die Teile verbunden werden können. Die Teile und die Verbindungsmechanismen können als die „Sprache“ eines jeden LEGO® Sets angesehen werden.
In der Softwareentwicklung werden Modelle häufig auf Basis textbasierter Programmiersprachen erstellt. In diesem Fall definiert das Metamodell oder die „Sprache“ die Syntax, die Grammatik und die Möglichkeit, Funktionen in den Prozess der Modellierung einzubeziehen.
Programmiersprachen unterscheiden sich nicht nur in ihrer Syntax und Grammatik, sie unterscheiden sich auch auf der Ebene der zugrunde liegenden Features und Konzepte.
C wird häufig auf spezialisierter Hardware wie Mikrocontrollern eingesetzt. Diese Controller verfügen über begrenzte Ressourcen und werden häufig in Fahrzeugen, Industrieanlagen oder der Heimautomatisierung eingesetzt. Die Konzepte und die Struktur von C spiegeln den Hardware-Befehlssatz wider und sind auf Ressourceneffizienz optimiert.
Java dagegen ist eine höhere, objektorientierte Programmiersprache. Es läuft normalerweise nicht auf ressourcenbeschränkten Mikrocontrollern, sondern auf Servern mit vielen Ressourcen. Da Java-Programme oft größer sind als in C geschriebene Software, enthält es Konzepte auf höherer Ebene, die helfen, Softwarefunktionen zu strukturieren und wiederzuverwenden, zB durch die Einführung von Klassen mit der Fähigkeit, Fähigkeiten zu vererben.
SQL – Structured Query Language – ist eine andere Art von Programmiersprache. SQL wurde für einen bestimmten Zweck entwickelt: den Umgang mit Informationen, die in relationalen Datenbanken gespeichert sind. Die Syntax und die bereitgestellten Funktionen sind daher auf die Domäne relationaler Datenbanken zugeschnitten.
Obwohl sie sich in Umfang und Struktur unterscheiden, fallen C und Java beide in die Kategorie der Allzwecksprachen. Sie sind nicht darauf ausgelegt, eine bestimmte Art von Problem zu lösen, sondern können in vielen Bereichen verwendet werden. Sprachen wie C++, C#, Python oder XML fallen in dieselbe Kategorie.
SQL hingegen ist auf eine Gruppe von Aufgaben in einer Domäne zugeschnitten: die Abfrage und Manipulation relationaler Datenbanken. Es fällt daher in die Kategorie der domänenspezifischen Sprachen oder DSLs. Andere DSLs sind HTML oder MATLAB.
Was ist das Äquivalent zu Allzwecksprachen in der Welt von LEGO®? Nun, als ich dort aufgewachsen bin, gab es nur 5 oder 6 LEGO®-Farben und die Formen der Blöcke waren meistens rechteckig. LEGO® Figuren sahen sehr generisch aus. Ein Raumschiff zu bauen erforderte etwas Kreativität und etwas Kompromissbereitschaft.
Heute ist eine Vielzahl von domänenspezifischen LEGO® „DSLs“ verfügbar. Piraten mit ihren Schiffen, Polizisten inklusive Schäferhunden – und sogar unser Millennium Falcon.
(Picture by Kim Do-hyun: https://www.flickr.com/photos/stickkim/6966161674)
Beachten Sie die benutzerdefinierten Teile, die im Raumschiff verwendet werden, sowie die benutzerdefinierten Figuren und ihr Zubehör. Bei einer sehr spezifischen Aufgabe – dem Bau eines Millennium Falcon – machen kundenspezifische Teile wie Antennen oder Cockpitfenster den Modellierungsprozess viel effizienter und die Ergebnisse beeindruckender.
Der Bau eines LEGO® Millennium Falcon im Jahr 1976 wäre eine viel anspruchsvollere Aufgabe gewesen. Ich frage mich, ob jemand Chewbacca mit einem roten Top und einer blauen Hose erkannt hätte …
Wer also kommt in den Genuss der Vorteile domänenspezifischer Sprachen – sei es im Bereich der Computersprachen, Systemtechnik oder LEGO®? Nun, nicht alle.
In der Vergangenheit musste es eine signifikante Anzahl potenzieller Nutzer (= Marktgröße) von Programmierern, Ingenieuren oder Spielern geben, um die Entwicklung und Wartung einer DSL zu rechtfertigen. Folglich behielten DSLs oft einen eher breiten und technischen Charakter – der gemeinsame Nenner der angesprochenen Expertengruppe.
Wenn Sie also zu den Spezialisten gehören, die Abfragen für relationale Datenbanken (SQL) schreiben müssen, oder wenn Sie ein Star Wars-Fan sind, haben Sie Glück und bekommen Ihre DSL.
Wenn Ihr Fach- oder Interessengebiet jedoch „Nische“ ist, müssen Sie sich mit Allzwecksprachen begnügen und wieder auf die Verwendung von quadratischen und rechteckigen Legosteinen zurückgreifen.
Punkte mitnehmen:
Nachdem die Vorteile von DSLs bekannt sind, stellt sich die Frage, wie man mehr Experten und Spezialisten in ihren Fachgebieten Zugang zu effizienteren Modellierungsmethoden verschaffen kann.
Zum Glück sind wir endlich im Zeitalter des 3D-Drucks angekommen!
Abgesehen von Lizenz- und Urheberrechtsproblemen würde ein 3D-Drucker in Verbindung mit der passenden Software es LEGO®-Spielern ermöglichen, beliebige LEGO®-Teile ihrer Wahl zu definieren und zu drucken. Einhörner statt Pferde: Einfach ausdrucken! Star Trek statt Star Wars Figuren: Einfach ausdrucken!
Die neuen Teile können jetzt genau nach den Bedürfnissen des Spielers konstruiert werden.
Erfreulicherweise gab es in den letzten Jahren auch in Bezug auf die Erstellung domänenspezifischer Sprachen in der Modellierung und im Software-Engineering erhebliche Fortschritte.
Martin Fowlers Konzept der Language Workbenches (LWB) ist bereits mehr als ein Jahrzehnt alt. Seine Visionen und Ideen wurden inzwischen Wirklichkeit.
Language Workbenches sind Softwarewerkzeuge, die entwickelt wurden, um neue Programmiersprachen einschließlich ihrer Syntax, Grammatik und zugrunde liegenden Konzepte (= Metamodelle) effizient zu erstellen.
Language Workbenches sind die „3D-Drucker der Softwareentwicklung“. Sie ermöglichen die effiziente Erstellung von DSLs – selbst für sehr kleine Expertengruppen mit sehr spezifischen Modellierungsanforderungen. Die Benutzergruppe für DSLs kann jetzt so klein wie ein Team in einer Abteilung sein.
Heute sind eine Reihe von Language Workbenchesn verfügbar. Eine Kategorie konzentriert sich auf einen textuellen Modellierungsansatz. Ein beliebtes Beispiel für eine textuelle Language Workbench ist Xtext.
Projectional Language Workbenches hingegen sind nicht auf eine Notationsart beschränkt. Stattdessen können sie den Inhalt von Modellen flexibel in jeder Art von Darstellung gemäß den Bedürfnissen und Vorlieben des Benutzers projizieren. Das Meta Programming System (MPS) von Jetbrain ist heute die beliebteste Projectional Language Workbench.
Projektions-LWBs speichern Modelldaten in Bäumen. Dieser spezielle Baum wird auch als Abstract Syntax Tree (AST) bezeichnet. Die Modellierungsinformationen werden in den Elementen des AST gespeichert und können dann auf jede beliebige Notation projiziert werden: einen Text, eine Tabelle, eine mathematische Formel oder jede Form von grafischer Darstellung. Als Teil des Projektionsprozesses kann das System bestimmte Aspekte des zugrunde liegenden Modells hervorheben und andere Aspekte ausblenden. Der Benutzer kann die für die jeweilige Aufgabe relevanten Abstraktionen flexibel auswählen – „Abstraktionen on Demand“.
Lassen Sie uns einen kurzen Blick auf ein reales Beispiel werfen.
Sicherheitsexperten analysieren und bewerten die Sicherheitseigenschaften technischer Systeme. Dies kann ein Fahrzeug oder ein IoT-Gerät sein. Dazu müssen sie zunächst die Grundstruktur und die Hauptfunktionen des Systems verstehen. Hier arbeiten sie eng mit dem Engineering-Team zusammen, das mit den Komponenten, Schnittstellen und Daten des Systems vertraut ist. Basierend auf dieser Struktur müssen iterativ Sicherheitsziele, Angriffsvektoren, Schadenspotenziale und Ausbreitungswege modelliert werden. Identifizierte Risiken werden dann z. B. durch das Hinzufügen von Verschlüsselung und den erforderlichen Schlüsseln gemindert. Dies wirkt sich wiederum auf die ursprüngliche Architektur und Funktionen des Systems aus.
Obwohl es nicht wichtig ist, jedes Detail des oben genannten spezifischen Arbeitsablaufs vollständig zu verstehen, werden die Modellierungsherausforderungen hoffentlich deutlich. Wir müssen ein Modell definieren, an dem Designer, Architekten und Sicherheitsingenieure gleichzeitig arbeiten können, während sie sich auf verschiedene Aspekte des Modells konzentrieren. Und verschiedene Aufgaben innerhalb des Prozesses profitieren von unterschiedlichen Notationen: Grafiken, Tabellen, Text, Diagramme usw.
Wie eine DSL in einem benutzerdefinierten Editor, der mit einer Projektionssprachen-Workbench erstellt wurde, aussehen könnte, ist unten dargestellt. Bitte beachten Sie, dass dies unterschiedliche Projektionen EINES Modells sind, die unterschiedliche Abstraktionen für unterschiedliche Schritte in der Analysephase betonen, einschließlich einer spezifischen DSL für die Sicherheitsdomäne.
Punkte mitnehmen
Language Engineer lösen herausfordernde Probleme im Bereich der System- oder Softwaremodellierung, indem sie domänenspezifische Sprachen und Modelle erstellen.
Oft sind diese Probleme das Ergebnis einer erhöhten Komplexität und der Unfähigkeit, diese Komplexität mit den etablierten Software-Tools und -Methoden zu bewältigen.
Die Gründe für die erhöhte Komplexität können unterschiedlich sein. Von einer wachsenden Anzahl von Funktionen und Produktvarianten über strengere regulatorische Dokumentationsanforderungen oder die Anforderung, die Abhängigkeiten von Querschnittsthemen wie Kosten, Leistung, Sicherheit und Schutz entlang des gesamten Produktentwicklungsprozesses zu analysieren.
Oft sind schwache Metamodelle, zB im Klartext geschriebene Anforderungen, und die fehlende Werkzeugunterstützung für die Experten, „ihre Modelle richtig hinzubekommen“, die Ursache für die Notwendigkeit, sich im Bereich Methoden und Werkzeuge weiterzuentwickeln.
Language Engineer sind in der Regel Teil eines multidisziplinären Teams, das Teammitglieder und Fachexperten von der Kundenseite umfasst. Dies bedeutet immer, dass Language Engineer tiefe Einblicke in viele verschiedene Bereiche erhalten: von Automotive über Industrieautomation, Medizin, Versicherungen oder Telekommunikation. Language Engineer müssen auch Abhängigkeiten der Arbeitsergebnisse verschiedener Benutzergruppen auf Kundenseite lernen und verstehen. Gemeinsam mit den Domänenexperten helfen Language Engineer dann, die richtigen Abstraktionen einschließlich Syntax, Grammatik und Funktionen zu finden, um alle relevanten Aspekte einer Domäne zu modellieren. Language Engineer sind normalerweise auch am Entwurf und Aufbau der Tools beteiligt, die es den Domänenexperten ermöglichen, die Modelle zu erstellen und mit ihnen zu arbeiten.
Die DSLs und das zum Zweck der obigen Sicherheitsanalyse erstellte Tool sind ein typisches Beispiel für die Arbeit von Language Engineern. Sicherheitsmethodik-Experten, potenzielle Anwender verschiedener Kunden und die Language Engineer von itemis definierten das Modell einschließlich der relevanten Abstraktionen, geeigneten Notationen und Projektionen. itemis baute dann den Editor, in diesem Fall basierend auf einem Projektions-LWB-MPS von Jetbrains, auf, um Sicherheitsanalyseprojekte zu modellieren, zu analysieren und zu dokumentieren.
Wenn DSLs und Language Engineering für Sie nach tragfähigen Geschäftsansätzen oder spannenden persönlichen Herausforderungen für 2018 klingen, zögern Sie nicht, uns zu kontaktieren und mehr zu erfahren.
Aber für das neue Jahr gilt: Den Ausgleich in unserem stressigen Alltag nicht vergessen und mehr spielen! Vielleicht mit LEGO®.
Nutzen Sie das Jahr 2023, um all Ihre Vorsätze zu erreichen und vor allem: Bleiben Sie gesund!