KerML (Kernel Modeling Language) ist eine modellbasierte Sprache, die als Kern für SysML v2 dient. Es handelt sich um eine metamodellbasierte Sprache, die eine formale Grundlage für die Modellierung bietet und Prinzipien wie Präzision, Erweiterbarkeit und Interoperabilität befolgt. Sie ist vergleichbar mit ECORE aus dem Eclipse Modeling Framework (EMF) - einem abstrakten Kern für nachfolgende Modellierungswerkzeuge.
Lange Zeit war das Eclipse Modeling Framework (EMF) im Bereich der modellbasierten / modellgetriebenen Werkzeuge sehr einflussreich. Es ist ein umfassendes Framework, das eine Fülle von Anwendungsfällen abdeckt. Es kann leicht um neue Anwendungsfälle erweitert werden. Obwohl es etwas an Zugkraft zu verlieren scheint, da viele Parteien zu Python oder webbasierten Tech-Stacks wechseln und hier das Rad neu erfinden, spielt es immer noch eine Rolle in vielen Frameworks (Franca, Topcased, Papyrus usw.).
Das Forschungsteam des GAIA-X-Leuchtturmprojekts COOPERANTS verwendet ein internes Systems-Engineering-Tool eines der Mitglieder als kollaborative Plattform für das Systems-Engineering mit mehreren Teilnehmern. Obwohl dieses Werkzeug nicht EMF-basiert ist, verwendet es das EMF-basierte "Ecore"-Format zur Definition seines Metamodells. Dabei gibt es unterschiedliche Möglichkeiten ein Ecore-Metamodell zu erstellen:
- Direkte Bearbeitung mit Ecore-Tooling (nicht die beste Benutzererfahrung)
- Transformieren eines UML-Modells nach Ecore, basierend auf einem Profil (z.B. mit Magicdraw oder Papyrus)
- Textuelle Definition mit den Xcore-Tools, die eine textuelle DSL für die Erstellung der Artefakte bieten
- Ableitung des Modells aus einer Xtext-Grammatik
Ich persönlich mag den Xcore-Ansatz, da er eine angenehme Benutzererfahrung mit einem schlanken Tooling bietet. Da die Systems-Engineering-Gemeinschaft jedoch SysML v2 als Standard mit einer textuellen Notation einführt, warum nicht auch einen Blick darauf werfen? In den letzten Wochen von COOPERANTS haben wir daher begonnen, KerML als Modellierungssprache für Weltraum-Metamodelle einzuführen.
Grundlegende Modellierung
Die SysML-Pilotimplementierung wird mit einem Beispiel für ein Adressbuch geliefert, das zeigt, dass sie auch für die Datenmodellierung gut geeignet ist:
private import ScalarValues::*; private import Ecore::*; package AddressBookModel { class Entry { name: String; address: String; } class AddressBook { enries: Entry[*]; } }
Listing 1: SysML Pilot Adressbuch Beispiel
Ein einfacher KerML-Generator für die textuelle Notation in .ecore ist in wenigen Stunden geschrieben. Die größte Herausforderung besteht darin, das neue Metamodell zu verstehen und durch die Modellhierarchie zu navigieren (den richtigen Weg zu finden, um Multiplikationen und Merkmalswerte zu erhalten) war eine Sache.
Erweitern von KerML durch Hinzufügen von Metadaten
Bei der Codegenerierung oder Modelltransformation werden oft zusätzliche Daten benötigt, um Besonderheiten des Zielmodells zu definieren, die im Quellmodell nicht direkt als Modellkonzepte vorhanden sind. Bei der Modellierung von Ecore mit UML hätten wir Stereotypen und getaggte Werte verwenden können. Diese Konzepte fanden nicht direkt den Weg in die SysML v2. Dafür hat SysML v2 das Konzept der Metadaten. Wir können diese verwenden, um einige Aspekte zu definieren, die für die Konfiguration eines vollständigen .ecore erforderlich sind:
private import ScalarValues::*; library package Ecore { metaclass ECoreAnnotation { feature nsPrefix : String; feature nsURI : String; feature ANNOTATIONS_SOURCE : String; feature modelName : String; } }
Listing 2: Metadaten für eine Ecore-Paket-Anmerkung
Jetzt können wir unser Adressbuchmodell erweitern, um zusätzliche Informationen für das generierte Ziel-Ecore einzubeziehen.
private import ScalarValues::*; private import Ecore::*; package AddressBookModel { @ECoreAnnotation { modelName = "AddressBook"; nsURI = "https://addressbook"; } class Entry { name: String; address: String; } class AddressBook { entries: Entry[*]; } }
Listing 3: Konfiguration des generierten Ecore auf der Grundlage von Metadaten
Nun sind wir in der Lage, das Metamodell unseres Systems-Engineering-Tools auf der Grundlage von KerML zu konfigurieren und .ecore als Standardschnittstelle/Konfigurationsdatei zur Konfiguration des Modells zu verwenden. Ein schöner Vorteil der SysML v2 ist die Unterstützung der textuellen Notation. Die Pilotimplementierung der textuellen Notation basiert auf dem großartigen Xtext-Framework, das zu einem großen Teil von der itemis AG gesponsert, konzipiert und implementiert wurde.
Für diejenigen, die Textdateien in eine eigenständige Java-Anwendung laden wollen, gibt es im Internet einige Snippets, die zeigen, wie man Xtext-Modelle eigenständig laden kann. Um die Dinge weiter zu vereinfachen, finden Sie hier ein Snippet zum Laden von KerML-Dateien in eine Java-Anwendung:
Ich hoffe, das hilft denjenigen, die an KerML/SysML v2 interessiert sind, und macht es zugänglich.package com.itemis.ocean.sysml; import org.eclipse.emf.common.util.URI; import org.eclipse.emf.ecore.resource.Resource; import org.eclipse.xtext.resource.XtextResourceSet; import org.omg.kerml.xtext.KerMLStandaloneSetup; import org.omg.sysml.lang.sysml.SysMLPackage; import com.google.common.collect.Streams; import com.google.inject.Injector; public class SysMLReader { public static void main(String[] args) { SysMLReader sreader = new SysMLReader(); sreader.read(); } public void read() { Injector injector = new KerMLStandaloneSetup().createInjectorAndDoEMFRegistration(); SysMLPackage registerMe = SysMLPackage.eINSTANCE; injector.injectMembers(this); XtextResourceSet resourceSet = injector.getInstance(XtextResourceSet.class); Ressource resource = resourceSet.getResource(URI.createFileURI("./Vehicles_3.kerml"), true); Streams.stream(resource.getAllContents()).forEach(System.out::println); } }
Weitere Informationen:
Kommentare