Die Begriffe „Low Code“ und „NoCode“ sind in aller Munde – von DER Neuerung in der Programmierwelt spricht man. Diese beiden Ansätze gehören zur Überkategorie der sogenannten Modellgetriebenen Softwareentwicklung. Doch was ist das eigentlich?
Ein Modell ist ein Abbild der Wirklichkeit
Ein Modell ist ein Abbild der Wirklichkeit – So zumindest lautet der Merksatz, den man im Physik-Unterricht zur Definition eines „Modells“ lernen musste. Modelle gibt es überall: Wettermodelle simulieren das Wetter im Computer, um einen Wetterbericht vorherzusehen; Physikalische Modelle wie das Atommodell erklären anschaulich die Wirkungsweise unseres Kosmos; Architektur-Modelle sind Miniatur-Versionen eines Hauses oder eines ganzen Areals, um zum Beispiel Bauanträge genehmigt zu bekommen.
Von Modellierung spricht man, wenn man beim Entwurf nicht das reale Objekt direkt bearbeitet, sondern zuerst ein Abbild (z.B. ein 3D Computer-Modell oder eine Lehm-Form der Luxus-Autokarosse) mit viel weniger Aufwand gestaltet, das dann später in sein reales Counterpart übersetzt werden kann.
Und genau das tut man bei der Software-Modellierung.
Vorreiter: Struktogramme, ER-Diagramme, UML
In der Informatik haben sich schon sehr früh Modellierungswerkzeuge herausetabliert, die auch standardisiert wurden: ER-Diagramme beschreiben Diagramme, Strukturgramme beschreiben Algorithmen.
Die OMG hat anschließend angefangen, den UML-Standard zu spezifizieren. Im UML-Standard kann man alle möglichen Szenarien modellieren:
- Klassendiagramme modellieren Datenschemen, Attribute und Methoden
- Sequenzdiagramme modellieren Kommunikationsszenarien zwischen Akteuren, z.B. zwischen Client und Server
- Zustandsdiagramme beschreiben das Verhalten von zustandsgetriebenen Automaten
- Paketdiagramme modellieren den High-Level-Aufbau einer Software
- uvm
Modellieren und Programmieren
Schnell hat sich herausgestellt, dass die vorangegangene Modellierung ja eigentlich Basis für die Ausimplementierung ist. In der Anfangszeit der Informatik hat man noch modelliert und anschließend das Modell nachprogrammiert. Nach und nach kamen immer mehr Tools hinzu, die aus den Modellen schon Code und Codegerüste herstellen konnten. So kann man sich anhand eines UML-Klassendiagramms schon in der Eclipse-IDE die JAVA-Klassen mit leeren Methoden anlegen lassen.
Doch diese einfachen Code-Generatoren sind leider eine Einbahnstraße: Aus dem Modell wird Code, aber der Code kann nicht mehr in das Modell zurückgewandelt werden, sprich: Ändert man etwas am Code, das so nicht modelliert wurde, muss man danach das Modell von Hand aktualisieren.
Einen saubereren Ansatz bieten hier die No-Code und Low-Code Tools:
Modell als Single Point of Truth
Ein wesentlich vielversprechenderer Ansatz ist, bei der modellgetriebenen Softwareentwicklung einfach das Modell als Single Point of Truth zu definieren.
Bei der Low-Code-Bewegung bedeutet das: Anstatt also das UML-Klassendiagramm in Code umzuwandeln, wird das UML-Diagramm dauerhaft im grafischen Editor behalten und nur beim Doppelklick auf eine Methode öffnet sich noch ein Code-Editor. Doch Low-Code-Tools arbeiten nicht nur auf UML-Ebene, sie erlauben zum Beispiel auch das Designen von Benutzeroberflächen oder das Zusammenklicken von Ablaufdiagrammen und Workflows.
Noch spannender sind hier die No-Code-Tools, denn bei ihnen muss sich die komplette Funktionsweise der zu programmierenden Anwendung modellieren lassen. Doch was bedeutet im Fall der Softwareentwicklung „Modell“?
Modell als Daten in einem Datenschema
Um No-Code richtig zu verstehen, werde ich hier einmal den Begriff des „Modells“ entzaubern anhand der Programmiersprache Java.
Denn eine Java-Bytecodedatei ist auch nichts anderes als ein Modell, um Software zu beschreiben. Hier der Aufbau eines Java-Programms:
- Ein Java-Programm besteht aus mehreren Klassen
- Jede Klasse hat einen Klassennamen, sowie einen Classpath
- Eine Klasse kann mehrere Attribute haben. Jedes Attribut hat einen Namen, eine Sichtbarkeit (public|private|protected), sowie einen Datentyp
- Ein Datentyp muss wiederum eine Klasse sein
- Eine Klasse hat mehrere Methoden mit Methodennamen, Sichtbarkeit, sowie einem Rückgabe-Datentyp
- Eine Methode hat eine Liste von Parametern mit Parametername und Datentyp
- Eine Methode hat eine Liste von Anweisungen
- und so weiter…
Wie man sieht: Man kann den Aufbau eines Java-Programms wiederum selbst als UML-Klassendiagramm zeichnen. Damit lassen sich alle Anwendungen erstellen, die man sich so denken kann.
Doch das Java-Modell hat einen großen Nachteil: Es ist durchgängig Low-Levelig. Was heißt das? Um komplexe Programme zu erstellen, muss man viele Klassen, viele Attribute und viele Methoden anlegen. Die Methoden bestehen wiederum aus vielen Zeilen Code.
Will man beispielsweise jetzt ein komplexeres Feature, wie zum Beispiel Logging in eine Software einbauen, fängt man an, hunderte Zeilen in Zig Dateien zu ändern. Das zu Grunde liegende Software-Modell ist also mächtig, aber nicht angenehm zu programmieren.
Workflows: Ein beliebtes No-Code-Modell
Ein beliebtes No-Code-Modell ist der Workflow. Beim Workflow-Modell modelliert man die einzelnen Formulare, in denen sich der User aufhalten kann, sowie mit welchem Datensatz die Formular-Felder verknüpft werden, sowie wohin die einzelnen Buttons (z.B. Speichern oder Weiter) als nächstes führen.
Das „Datenschema“ des Workflow-Modells sieht also ungefähr so aus:
- Es gibt eine Liste von Formularen
- Jedes Formular hat Formular-Elemente mit (x, y, Beschriftung, Typ, Feld-Verknüpfung)
- Jedes Formular hat Buttons mit (x, y, Beschriftung, NextWorkflow)
Doch das Dilemma, in dem viele No-Code-Tools stecken: Um benutzerfreundlich zu sein, muss das Modell einfach sein. Ein einfaches Modell ist aber nicht mächtig genug, um alles damit umsetzen zu können.
FOP als Lösung für modellgetriebene Softwareentwicklung
FOP ist eine sogenannte featureorientierte Programmiersprache. Das bedeutet, man kann Features in Bibliotheken definieren – und geht damit eine Abstraktionsstufe weiter als andere Programmiersprachen wie PHP, Java, C++ oder Python, die nur Programmablaufpläne in Prozeduren vorhalten können.
Eine Feature ist im Gegensatz zu den low-leveligen Elementen der Java-Programmiersprache, die oben beschrieben wurden, wahlweise High- oder Low-Level. Damit lässt sich viel schneller programmieren.
Beispiel: Ein Feature für eine Software kann das „Login-Verfahren“ sein. In FOP programmiert man dieses Feature einfach mit folgender Code-Zeile:
Login<"users", "username", "password">.Features werden also nur mit ein paar Parametern aktiviert.
Dabei gibt es in der Standardbibliothek vom FOP etliche Feature-Definitionen unterschiedlichster Modelle:
Imperatives / Objektorientiertes Programmiermodell:
- Klassen
- Methoden
- Attribute
- Namespaces und Use-Klauseln
Aus dem Imperativen Programm-Modell können direkt Quellcode bzw. Executables erzeugt werden
Formular-Modell:
- Formulare
- Eingabefelder
- Buttons
Das Formular-Modell wird in FOP-Bibliotheken so implementiert, dass es auf das Objektorientierte Modell heruntergebrochen wird.
Tabellen-Modell (Datenschemabeschreibung für Datenbanken)
- Tabellen
- Deren Spalten
- Datatentypen
- Beschriftungen
Das Tabellen-Modell wird in FOP-Bibliotheken so implementiert, dass es auf das Formular-Modell heruntergebrochen wird. Man bekommt also sämtliche CRUD-Funktionen für eine Tabelle gratis ausimplementiert.
Module-Modell (komplette Software-Features)
- Rechnungsstellung
- Personal-Zeiterfassung
- Produktionsplanung
- Dokumentenmanagementsystem
Das Module-Modell wird in FOP-Bibliotheken so implementiert, dass es auf das Tabellen-Modell heruntergebrochen wird. Damit lassen sich komplette Großprojekte mit nur wenigen Zeilen Code implementieren.
All diese Modelle kann man in der FOP-Programmiersprache sowohl textuell, als auch grafisch bearbeiten. Durch die Möglichkeit der High-Level-Features wie z.B. Modulen ergibt sich ein wesentlich schnelleres Arbeiten. Der Compiler übersetzt den High-Level-Code dann wieder in „normalen“ Source-Code zurück, damit der Code z.B. von PHP ausgeführt werden kann.
Fazit
Modellgetriebene Softwareentwicklung hilft den Entwicklern, schneller zur Lösung zu kommen und weniger Programmierfehler zu machen. Gerade bei der grafischen Entwicklung erkennt man Programmierfehler auch viel schneller. Bessere Programmiermodelle ermöglichen eine bequemere Anwendungsentwicklung, da man nicht jedes mal das Rad neu erfinden muss.
Modulare Baukastensysteme machen selbst große Projekte händelbar. Mit dem richtigen Tool lassen sich selbst ERP-Großprojekte mit relativ überschaubarem Aufwand von einem kleinen Team implementieren – und kleine Teams kommunizieren bekanntermaßen effektiver.
Der Fallstrick liegt aber hier in der Mächtigkeit des verwendeten Tools. Die Programmiersprache FOP ermöglicht die freie Programmierbarkeit komplett neuer Modelle in Bibliotheken, was sie von allen anderen No-/Low-Code-Tools abhebt.
German 
English
Comments are closed