Ein auf dem Stack Overflow Blog veröffentlichter Artikel plädiert dafür, das Konzept der modellorientierten Programmierung (Model Oriented Programming) neu zu betrachten. Sie könne eine Richtung darstellen, die zwischen den Anforderungen eines Systems und seinem Softwaredesign trennt und anschließend das Modell selbst zur Unterstützung bei der Erstellung und Wartung des Systems nutzt. Der Autor stützt sich auf eine frühere Erfahrung, bei der er vor 13 Jahren eine Sprache und Entwicklungsumgebung namens Mo+ entwickelte. Nach eigenen Angaben setzte er sie in Unternehmensprojekten ein, ohne dass sich die Idee in größerem Umfang durchsetzte.
Der Beitrag ist weder eine Ankündigung einer verfügbaren Sprache noch ein neues Forschungsprojekt, sondern eine These, die zu weiterer Forschung und Entwicklung in diesem Bereich aufruft – insbesondere in einer Welt, in der die Bedeutung künstlicher Intelligenz und die Komplexität von Softwaresystemen zunehmen.
Das Modell als Struktur und Daten
Der Autor schlägt vor, ein Modell durch zwei Elemente zu definieren: eine Struktur, die die Regeln oder das Schema festlegt, und Daten, die dieser Struktur entsprechen. Die Struktur ist hierarchisch aufgebaut, beginnt mit einem Wurzelknoten und verzweigt sich in Knoten und Eigenschaften. Bei Bedarf kann eine Eigenschaft auf einen anderen Knoten verweisen. Aus dieser Perspektive lässt sich das Schema einer relationalen Datenbank in hierarchischer Form darstellen, mit Knoten wie Datenbank, Tabelle, Spalte und Schlüssel, selbst wenn die Daten selbst auf Zeilen und Beziehungen verteilt sind.
Der Artikel verwendet zur Veranschaulichung ein vereinfachtes Restaurantszenario, das Restaurants, Kunden, Angestellte, Menüelemente und die Beziehungen zwischen ihnen umfasst. Er zeigt mehr als eine mögliche Struktur zur Darstellung desselben Szenarios und macht deutlich, dass die Wahl der Struktur beeinflusst, wie einfach sich das Modell durchlaufen lässt und wie Programme geschrieben werden, die darauf aufbauen.
Vier Formen der modellorientierten Entwicklung
- Informelle Modellierung: Modelle im Kopf, auf Papier oder in Diagrammen, die von Softwarewerkzeugen nicht direkt verwendet werden.
- Integrierte Modellierung: Ein Modell innerhalb des Codes, etwa in ORM-Frameworks wie Entity Framework und NHibernate oder in Benutzeroberflächen-Frameworks wie Angular und React.
- Gekoppelte Modellierung: Ein externes Modell, häufig mit UML erstellt, das eng mit Codeelementen und den Werkzeugen zu ihrer Verwaltung verbunden ist.
- Getrennte Modellierung: Ein Modell, das sich auf Anforderungen, Daten und Arbeitsabläufe konzentriert, während das detaillierte Design dem Code überlassen wird. Dabei ist nicht jedes Modellelement an eine bestimmte Softwarekomponente gebunden.
Der Autor sieht die größten Möglichkeiten in der gekoppelten und der getrennten Modellierung, insbesondere in letzterer, weil sie die Anforderungen im Modell und das Design im Code platziert. Seiner persönlichen Erfahrung zufolge macht diese Trennung den Modellierungs- und Programmierprozess flüssiger.
Vom Modell zum System
Der Artikel unterteilt die Verwendung modellorientierter Programmierung in drei Bereiche. Im Übergangsmuster interpretiert das Programm das Modell und erzeugt Quellcode, Konfigurationsdateien oder Dokumentation, die anschließend weiterentwickelt werden können. Beim Muster der Modellmodellierung unterstützt die Sprache die Erstellung und Wartung der Modellstruktur und ihrer Daten. Das Zielmuster verwendet die Sprache dagegen direkt zum Aufbau und zur Verwaltung der Systemumgebung, wofür eine vollständigere Sprache erforderlich ist.
Vorgeschlagene Sprachmerkmale
Zu den wichtigsten Vorschlägen gehört, die Modellstruktur zu einem Bestandteil der Sprachregeln zu machen, sodass direkt mit Knoten wie Entity, Property und Relationship gearbeitet werden kann, anstatt spezielle Klassen und Objekte zu ihrer Darstellung zu erstellen. Der Autor schlägt außerdem einen Modellkontext vor, der auf der Position des Programms innerhalb des Datenbaums basiert, sowie einen Stapel, der das Aufsteigen zu übergeordneten Knoten oder das Absteigen zu untergeordneten Elementen und deren Durchsuchen ermöglicht.
Eine weitere Idee sind „modellorientierte Eigenschaften“. Dabei handelt es sich um unabhängige Codeabschnitte, die mit einem bestimmten Knotentyp verbunden sind und auf mehreren Instanzen ausgewertet werden können. Diese Eigenschaften lassen sich kombinieren, um Code zu erzeugen, etwa zur Erstellung einer Klassendefinition oder ihrer Eigenschaften, oder sie können für Such- und Filtervorgänge verwendet werden. Im Übergangsmuster könnte die Eigenschaft eine put-Operation umfassen, um das Ergebnis in einer Datei oder einer Zielumgebung zu speichern.
Der Autor schlägt außerdem dynamische Regeln vor, bei denen der Interpreter beim Start einer Programmiersitzung die Modellknoten und ihre Eigenschaften zu den Sprachregeln hinzufügt. Dies ist nützlich, wenn das Standardmodell nicht genügend Informationen enthält oder wenn das Modell für eine bestimmte Organisation oder Domäne spezifisch ist. Außerdem führt er kontextabhängige Regeln ein, die die innerhalb verschiedener Programmteile zulässigen Operationen beschränken, um Nebenwirkungen zu reduzieren und Lese- und Schreibverantwortlichkeiten zu trennen.
Warum ist dieser Ansatz relevant?
Der praktische Wert der Idee liegt in dem Versuch, das Modell ausführbar zu machen, statt es lediglich als vom Entwicklungszyklus getrenntes Designdokument zu behandeln. Wenn sich Anforderungen, Daten und Arbeitsabläufe mit wiederverwendbaren Mechanismen zur Erzeugung und Wartung verbinden ließen, könnte sich die Wiederholung zwischen Modell und Code verringern. Der Artikel stellt jedoch weder eine Standardsprache noch verfügbare Werkzeuge oder Vergleichsergebnisse vor, die eine Überlegenheit dieses Ansatzes gegenüber den aktuellen Modellierungs- und Codegenerierungs-Frameworks belegen.
Wichtige Fragen bleiben daher offen: Wie werden große und sich verändernde Modelle verwaltet? Wie wird der generierte Code getestet? Und wo liegen die Grenzen dynamischer Regeln hinsichtlich Lesbarkeit, Sicherheit und Integration in Entwicklungswerkzeuge? Daher wirkt der Beitrag eher wie ein wertvoller Forschungsaufruf an Sprachentwickler und Forschende als wie eine sofort einsatzbereite Lösung.