Entwicklung einer RAD-Plattform im Kontext verteilter Systeme - Chemnitzer Informatik-Berichte - CSR-19-02 - TU Chemnitz
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Fakultät für Informatik
CSR-19-02
Entwicklung einer RAD-Plattform im
Kontext verteilter Systeme
Martin Springwald · Wolfram Hardt
März 2019
Chemnitzer Informatik-BerichteEntwicklung einer RAD-Plattform im
Kontext verteilter Systeme
Martin Springwald
TU Chemnitz
Fakultät für Informatik
martin.springwald@informatik.tu-chemnitz.de
Häu g wird für kommerzielle oder wissenschaftliche Zwecke Individualsoft-
ware benötigt. Obwohl Anwendungen häu g denselben Mustern folgen, müs-
sen oft auch triviale Bestandteile immer wieder neu entwickelt werden, zudem
erfordert die Entwicklung allgemein entsprechende Fachkenntnisse. Daher be-
steht die Idee Plattformen zu entwickeln, die keine oder wenig Programmie-
rung erfordern und somit die einfache und schnelle Entwicklung von Anwen-
dungen unterstützen, um Zeit und Kosten zu sparen. Das W3C hat für ver-
teilte Dienste Standards für die Beschreibung von Diensten, Prozessen und
auch die Präsentation etabliert. Es ist Ziel dieser Arbeit diese Standards zu
kombinieren und ein kompatibles, jedoch vereinfachtes Beschreibungsformat
zu entwickeln, einschlieÿlich einem Werkzeugkasten für die Codegenerierung
und Bereitstellung einer Laufzeitumgebung. Durch Modularisierung soll die
Plattform einfach erweiterbar bleiben.
Keywords: low code, meta language, rapid application development, tem-
plate engine, web engineering
1 Einleitung
Die Nutzung von Informationstechnologie (IT) ist oft integraler Bestandteil der meisten
Projekte kommerzieller oder wissenschaftlicher Natur. Dies liegt darin begründet, dass
Abläufe automatisiert und dadurch auch beschleunigt werden können. Dadurch entsteht
eine Ersparnis an Zeit und Kosten. Allerdings erfordert die Entwicklung von individuellen
Systemen eine bestimmte Menge an Ressourcen.Zeit und Kosten für Abläufe zusätzliche Zeit und Kosten für Abläufe ohne
mit zugeschnittener IT zugeschnittene IT
Ziel: senken
Zeit und Kosten für individuelle Entwicklung IT
Abbildung 1: Trade-O zwischen Ersparnis an Zeit und Kosten und Entwicklungsauf-
wand beim Einsatz von IT für Projekte
Die benötigte Menge kann dadurch begrenzt werden, dass der Entwicklungsprozess eben-
falls optimal gestaltet wird. Zielstellung ist es daher den Entwicklungsprozess an wissen-
schaftlich herausgearbeiteten oder als Best Practice anerkannten Prinzipien auszurichten.
Eine Orientierung für die Softwareentwicklung bietet dazu das Buch The Pragmatic Pro-
grammer von Andrew Hunt und David Thomas. Den wichtigsten Fokus verdienen nach
Hunt und Thomas die Wiederverwendbarkeit und Verständlichkeit einzelner Komponen-
ten. Dazu dienen unter anderem die Prinzipien Don't repeat yourself (DRY), Ortho-
gonalität und Reversibilität. Das erste Prinzip sagt aus, dass Tätigkeiten nicht ständig
redundant wiederholt werden sollen. Orthogonalität bezeichnet die Ent echtung von Ab-
hängigkeiten und Reversibilität die Wahrung von Austauschbarkeit. Ebenfalls nennen
die Autoren auch nur auf spezielle Problembereiche ausgerichtete Domänensprachen als
Maÿnahme um unnötige Redundanzen zu vermeiden. Die weiteren Prinzipien betreen
agile Methoden, wie prototypengetriebene Entwicklung.[1, S. 25]
Aufgrund der etablierten Standards des World Wide Web Consortiums (W3C) und der ge-
ringen Einstiegshürde werden immer mehr Anwendungen mit Webtechnologien realisiert.
Dabei ist es unabhängig davon, ob diese auf einem Server oder lokal auf einem Rechner
laufen sollen. Um die vorgenannten Prinzipien auch im Web Engineering anwenden zu
können, hat sich die Nutzung von Frameworks etabliert. Eines der ersten Frameworks in
diesem Zusammenhang war ColdFusion, welches bereits eine Tag-basierte Auszeichnungs-
sprache mitbrachte und damit Webseiten vorlagenbasiert ausgeben konnte.[2] Verbreitet
hat sich später auch Ruby on Rails.[3] Aus Ruby ist auch der Befehl scaold bekannt,
der das Erzeugen von Gerüsten für die Datenbank ermöglicht.[4] Daraus hat sich das
Prinzip des scaolding für derartige Frameworks etabliert. Neben dem Gerüstbau sind
Datenbankabstraktion, Templating und Mailversand wiederkehrende Bestandteile von
Web-Frameworks.
2Datenbankabstraktion Templating Mailversand
Scaffolding
Abbildung 2: Kernfunktionen von Webframeworks
Trotz des Einsatzes von Rahmenwerken ist immer noch einiges an Entwicklungsaufwand
und entsprechende Fachkenntnis erforderlich. Auch Forrester stellte 2014 in einem Report
fest: Hand-coding is too slow to develop und spricht dann als Lösung erstmals von low
code application platforms.[5] Seit dieser Zeit verbreiten sich diese sogenannten Low-
Code-Plattformen, die gemäÿ ihrer Eigenbezeichnung den Programmieraufwand soweit
wie möglich, teilweise bis auf Null, reduzieren wollen und die Entwicklung von Anwen-
dungen auf Grundlage von Beschreibungen und Zusammenstellungen unterstützen. Das
Marktvolumen dieser Plattformen wird nach Marktvorhersagen von Forrester bis 2020
auf voraussichtlich 15,5 Milliarden US-Dollar anwachsen.[6, S. 16]
Es kann vorweggenommen werden, dass verbreitete Low-Code-Plattformen durch man-
gelnde Anpassbarkeit oder Proprietarismus die Prinzipien einer ezienten Softwareent-
wicklung derzeit nicht optimal verwirklichen lassen. Daher wurde eine neue Plattform
konzipiert und prototypisch umgesetzt, um diese Lücke zu füllen.
2 Methoden
Die Arbeit ist dreigeteilt. Zuerst wurden bestehende Produkte evaluiert. Danach wur-
de ein Konzept und die prototypische Umsetzung vorgenommen. Schlieÿlich wurde das
Arbeitsergebnis mit einem Fallbeispiel evaluiert.
2.1 Bestehende Produkte
Für die Evaluation bestehender Produkte wurde eine Marktstudie von Markets and Mar-
kets herangezogen, die aktuelle Schlüsselhersteller und -produkte identi ziert.[7] Damit
wurde eine Vorauswahl der zu evaluierenden Produkte auf die wichtigsten Produkte ge-
troen. Um eine Bewertung vornehmen zu können wurden sechs Kriterien herausgearbei-
tet, die eng mit den Prinzipien e zienter Softwareentwicklung zusammenhängen und aus
diesen ableitbar sind. Das ist Versionskontrolle, Initialisierungsaufwand, Einfachheit der
Designtools, Anpassbarkeit des Aussehens oder Verhaltens bereitgestellter Widgets, Be-
reitstellung externer Schnittstellen für Plugins und die Verwendung von Standards. Für
die hier identi zierten Produkte wurden aus Kommentaren auf der Bewertungsplattform
TrustRadius[8] und den jeweiligen Produktdokumentationen mit den eben genannten
Kriterien qualitative Bewertungen vorgenommen.
32.2 Konzeptentwicklung und prototypische Umsetzung
Ausgangspunkt der Konzeptentwicklung ist die Entscheidung für die De nition einer Me-
tasprache. Denn diese muss nicht notwendigerweise Turing-vollständig sein, um nützlich
zu sein.[9, S. 49] Eine Metasprache erlaubt auch eine bessere Abstraktion und damit Re-
duzierung von weiteren Abhängigkeiten. Da das Model-View-Controller-Muster (MVC)
nach wie vor das wichtigste Paradigma für Anwendungen innerhalb verteilter Systeme
ist, soll sich das zu beschreibende System auch an diesem Modell orientieren. Auch Pop
und Altar sind im Kontext von Web Engineering der Ansicht: The MVC design pattern
is such a good t for web application development because they combine several tech-
nologies usually split into a set of layers..[10, S. 1174] Das Muster ist geeignet um die
natürlichen Belange von verteilten Systemen zu berücksichtigen.
Anfrage
Controller
Antwort
Datenmodelle Präsentation
Abbildung 3: MVC Flow im Web Engineering
Es werden drei Schichten gebildet: einerseits die Datenmodelle, andererseits die Control-
ler und zuletzt die Präsentationsschicht. Dabei interagieren die Schichten miteinander.
In der Regel sorgt der Controller für den Austausch zwischen Datenschicht und Präsen-
tationsschicht. Anfragen gehen zuerst an den Controller, die Präsentationsschicht liefert
schlieÿlich die Antwort aus.
Die prototypische Umsetzung kann auf Basis eines bestehenden Frameworks geschehen,
dass grundlegende Komponenten für den vorgenannten Aufbau bereits vorsieht. Infrage
kommen Ruby on Rails, Django, Symfony oder Flask.[11] Allerdings el die Entscheidung
hier auf ein selbst betreutes Framework, da damit eine höhere Kontrolle einhergeht, die
es ermöglicht während der forschenden Entwicklung die Auswirkungen von Änderungen
an Framework oder Generator-Toolkit zu untersuchen und zu Entscheiden, an welcher
Stelle beziehungsweise welchem Bereich die Änderungen vorgenommen werden sollten.
Es wurde daher das PHP-basierte Blob sh-Framework ausgewählt, welches sich auch
an DRY und anderen Kriterien orientiert und die Komponenten Datenbankabstraktion,
Templating und Mailversand bündelt.[12]
Auÿerdem war es notwendig ein Ökosystem in Form einer Tool-Infrastruktur zu entwer-
fen und prototypisch umzusetzen, um verschiedene Aufgaben, wie gra sches Editieren,
Generieren, Exportieren, Bereitstellen oder Dokumentieren abzubilden.
42.3 Evaluation anhand eines Fallbeispiels
Für die Evaluation von E-Learning-Angeboten wurde das Structure Oriented Evaluati-
on Model for E-Learning (SURE) an der Technischen Universität Chemnitz entwickelt.
Das Ziel dieses Modells ist es ein instrument or tool for improvement of E-Learning
bereitzustellen.[13, S. 5] Es besteht aus einem Vorgehensmodell zur Auswahl von Evalua-
tionskriterien und Datenerhebung sowie Methoden zur Berechnung und Aufbereitung der
Ergebnisse. Um dieses Modell unterstützen und anwenden zu können, sollen ohne Me-
dienbruch Online-Tools für die Schritte des Vorgehensmodells eingesetzt werden. Zwar
existiert eine Betaversion eines solchen Tools, jedoch könnte zur Bereitstellung einer um-
fassenderen und exibel erweiterbaren Lösung eine neue Umsetzung mit der in dieser
Arbeit konzipierten Low-Code-Plattform erfolgen.
Im Folgenden werden die wichtigen Punkte herausgestellt, die Anforderungen des Tools
sind. Das Tool für das SURE-Modell soll Fragebögen und Nutzer verwalten sowie die Fra-
gebögen den Nutzern präsentieren können und auf Basis der Antworten statistische Aus-
wertungen nach den vorgegebenen Formeln erstellen und gra sch präsentieren können.[13,
S. 39 - 42] Daraus folgt die Anforderung Benutzer im System authenti zieren und verwal-
ten zu können. Zudem muss es möglich sein die Benutzerkreise für Frontend und Backend
zu trennen und entsprechende Seiten für jeden Kreis bereitzustellen. Es sollte möglichst
einfach sein, die Zielstruktur für die Auswertung in der generierten Ober äche zu erstel-
len, also Ziele und Unterziele zu erstellen und miteinander zu verknüpfen sowie Fragen
aus Fragebögen mit den Zielen zu verknüpfen. Es muss auch Schnittstellen geben um
die nötigen Berechnungen für die Auswertungen zu implementieren. Als gra sche Kom-
ponenten müssen Listen und Formulare mit entsprechenden Feldern sowie Möglichkeiten
zur Darstellung der Auswertungen bereitgestellt werden.
Dabei wurde auch evaluiert, wie gut bestehende Plattformen dies leisten könnten.
3 Ergebnisse
3.1 Bestehende Produkte
Die Vergleichstabelle bewertet die Eigenschaften der Schlüsselprodukte. Als relevante Ei-
genschaften wurden Versionskontrolle (1), Initialisierungsaufwand (2), Einfachheit der
Designtools (3), Anpassbarkeit des Aussehens oder Verhaltens bereitgestellter Widgets
(4), Bereitstellung externer Schnittstellen für Plugins (5) und die Verwendung von Stan-
dards (6) herausgearbeitet. Die Werte reichen entweder von Ja bis Nein oder aber von
Gering über Mittel bis Hoch.
Nicht alle Eigenschaften konnten objektiv bewertet werden.
5Produkt 1 2 3 4 5 6
Appian Nein Hoch Gering Nein Gering Gering
Salesforce Nein Gering Ja Ja Ja Mittel
ServiceNow Ja Gering Gering Ja Ja Mittel
AgilePoint Ja Gering Ja Ja Ja Mittel
Bizagi Ja Gering Ja Ja Mittel Mittel
Caspio Nein Gering Ja Mittel Mittel Gering
K2 Nein Gering Mittel Gering Mittel Mittel
MatsSoft Limited Ja Gering Mittel Nein Gering Gering
Mendix Ja Mittel Ja Ja Ja Mittel
OutSystems Ja Mittel Ja Ja Ja Mittel
Tabelle 1: Vergleich existierender Plattformen
Kein Produkt erfüllt alle Kriterien optimal. Die höchste Bewertung erhält AgilePoint. Al-
lerdings orientiert sich auch dieses nicht an Formularbeschreibungsstandards (etwa XFDL
oder XForms). Zudem ist keines der aufgeführten Produkte freie Software.
3.2 Konzeptentwicklung und prototypische Umsetzung
Mit der Kombination aus Structured Query Language (SQL)[14], Web Services Descrip-
tion Language (WSDL)[15] (bzw. das kommende JSON Schema mit Erweiterungen[16]),
Business Process Model and Notation (BPMN)[17]/Business Process Execution Langua-
ge (BPEL)[18], XForms[19]/Extensible Forms Description Language (XFDL)[20] und den
Hypertext[21] und Cascading[22] Standards besteht ein mächtiges Set an Beschreibungs-
sprachen, mit denen alle wesentlichen Aspekte von verteilten Diensten beschrieben werden
können. Nachteilig ist, dass WSDL, BPMN/BPEL und XForms/XFDL auf Extensible
Markup Language (XML)[23] und Simple Object Access Protocol (SOAP)[24] setzen,
was zu Overhead führt, einerseits aufgrund zusätzlicher nicht immer benötigter Elemente
im sogenannten SOAP-Envelop, andererseits bereits durch die XML-Eigenheit Tags ö-
nen und schlieÿen zu müssen. Das JavaScript Object Notation-Format (JSON) spart dies
ein.[25] Ein Ersatz durch e zientere und weniger komplexe Formate wäre auch besonders
für kleinere Projekte empfehlenswert.
JSON und handlichere Dienste auf Basis von Representational State Transfer (REST)
werden dadurch vermehrt bevorzugt. Tatsächlich nden XML-basierte Dienste fast nur
noch in Intranets ihre Verbreitung.[26] In Hinblick auf Zukunftssicherheit und Einfach-
heit sollte daher weniger auf XML gesetzt werden. Allerdings sollte zu den etablierten
Standards aufgrund vorhandener Tools und der beschriebenen Vorteile eine gewisse Kom-
patibilität gewahrt werden und beim Design neuer Formate daran orientiert werden.
Die neu zu entwickelnde Beschreibungssprache wird daher JSON als Grundlage verwen-
den. Gemäÿ dem MVC-Modell wird die Beschreibungssprache zunächst in drei zu be-
schreibende Teile geteilt: Datenmodelle, Darstellung sowie Dienste und Prozesse. Ins-
gesamt entstehen elf Sektionen: pre x, vendor, domains, datalists, relations, views, lists,
forms, pages, services, processes. Dabei gehören domains, datalists, relations und views zu
6den Datenmodellen, während lists, forms und pages zur Darstellung gehören und services
sowie processes entsprechend zu Diensten und Prozessen.
Es ist stets das Ziel kompatibel zu bestehenden Standards zu sein oder sich an diesen
zu orientieren. Für den Bereich Datenmodelle wurde daher SQL als Domänensprache ge-
wählt. Es können Domänen mit Feldern und Feldtypen, Relationen und Views de niert
werden. Eine einfache Domäne mit einem Textfeld wird wie folgt de niert: example:
{ text_ elds: [ value ], methods: crud }. Es stehen verschiedene Feldtypen zur
Verfügung. Daraus werden SQL-Templates generiert, die alle Methoden für CREATE,
READ, UPDATE und DELETE (CRUD) sowie Datende nitions-Anweisungen (DDL)
zur Verfügung stellen. Später kann im Darstellungsmodul das value-Feld über den Namen
referenziert werden ohne den Typ angeben zu müssen, es wird automatisch ein passendes
Widget verwendet, auÿer es wird etwas anderes explizit angegeben. Es sind auch virtuelle
Datenmodelle über ein virtual-Flag möglich, die keine Entität in der Datenbank erzeu-
gen und nur für das Präsentationsmodul relevant sind oder die Verwendung von nicht zu
generierenden und bestehenden Entitäten über ein alias-Attribut ermöglichen. Verknüp-
fungen zwischen Domänen sind unter Angabe von Kardinalitäten (1:1, 1:n, n:m) über ein
type-Feld möglich, wobei automatisch die passenden Constraints erzeugt werden. Wich-
tig sind auch Views, die vornehmlich JOINs und UNIONs ermöglichen. Bei ihnen wird
eine Liste von Domänen über das domains-Feld angegeben und mit einer Auswahl im
Feld join_type gekreuzt. Weitere Feldfunktionen sind der Dokumentation zu entnehmen.
Insgesamt ist die Menge an den bereitgestellten Operationen Dierenz, Kreuzprodukt,
Projektion, Selektion, Vereinigung und Umbenennung relational vollständig. Somit kön-
nen alle relationalen Abfragen und Manipulationen dargestellt werden.
Listen sind Widgets, die Datensätze als Ergebnis des Aufrufs von Diensten au isten
und Aktionen sowie Anwahl und Abwahl anbieten. Bei Anwahl eines Datensatzes können
durch Verlinkungen mit weiteren Listen Abfrageketten erzeugt werden, so dass Hierarchi-
en abgebildet werden können. Formulare sind Widgets, die einen bestimmten Datensatz
als Ergebnis des Aufrufs eines Dienstes darstellen und Aktionen unter anderem für Er-
stellen, Speichern oder Löschen anbieten. Listen können auch auf Formulare verlinken, so
dass damit Editoren realisiert werden können. Seiten werden als aufrufbare URL bereit-
gestellt. Ihr Template kann im HTML-Format vorgegeben werden, sowie Gestaltungen
mit CSS durchgeführt werden. In den Seiten werden die Widgets über Platzhalter an-
gegeben und beim Aufruf automatisch geladen. Bei Bedarf kann weiterer Client-Code
eingebunden werden. Der Aufbau der Beschreibung orientiert sich an der Struktur von
XFDL- und XForms-Beschreibungen. Die Struktur kann der Dokumentation entnommen
werden.
Dienste und Prozesse werden in den zwei entsprechenden Sektionen de niert. Alle De ni-
tionen werden als Aktion über die REST-API erreichbar gemacht. Bei Diensten werden
die gewünschte Datenbankmethode und die gewünschten Domänen oder Relationen mit-
samt den Objektpfaden für die Parameter angegeben. Als Parameter stehen auch System-
variablen wie die eingeloggte User-ID zur Verfügung. Unter der Sektion Prozesse können
Ketten von Diensten angegeben werden, die nacheinander oder nach bestimmten Regeln
abgearbeitet werden und das vorherige Ergebnis als mögliche Eingabe erhalten. Damit
kann ein Work ow funktional abgebildet werden. Als Datenaustauschformat ist JSON
vorgesehen. Im Vergleich zu XML können damit redundante Daten eingespart werden.
7XML und JSON sind gleichmächtig. Dieser Teil der Beschreibung zielt auf die Kompa- tibilität mit den Standards für WSDL beziehungsweise das im Standardisierungsverfah- ren be ndliche JSON Hyper Schema sowie BPMN/BPEL ab. Die Beschreibung eines Dienstes erfolgt dabei in einem sogenannten return-Objekt. Dieses enthält die Attribute domain, optional relation sowie method und parameters. Damit werden Datenbankinter- aktionen auf vorher de nierten Entitäten oder Views beschrieben mit den vorde nierten Methoden delete, enumerate, enumerate_cached, lter, lter_cached, ltergroup, lter- group_cached, rst, insert, read, update oder upsert. Das weitere Verhalten und die richtige Reihenfolge bei der Angabe von Parametern ist der Dokumentation zu entneh- men. Für die Tool-Infrastruktur ist ein modulares Konzept vorgesehen. Jedes Tool soll sich mög- lichst auf eine bestimmte Aufgabe beschränken. Neben einem unterstützten Framework als Laufzeitumgebung ist das Herzstück der Generator, welcher aus der Beschreibung die Anwendungsdistribution erzeugt. Ein gra scher Beschreibungseditor dient der benutzer- freundlichen Erstellung der Beschreibung. Weitere Tools dienen dem Import und Export bestimmter Teile der Beschreibung und der Assets. Auch für Migrationsaufgaben wer- den Tools bereitgestellt. Der Toolkanon besteht prototypisch aus dem Generator, dem Beschreibungseditor, den Importern und Exportern, Migrationstools und einem Doku- mentationstool. Der Generator liest die Beschreibung, welche in der oben konzipierten Beschreibungsspra- che gefasst ist, ein und generiert daraus die erforderlichen Artefakte: Abfragen für Daten- modelle (queries/%name%/*.sql), Templates für Listen, Formulare und Seiten (templa- tes/list_*.html.tpl, templates/form_*.html.tpl, templates/page_*.html.tpl) sowie Con- troller (%pre x%/*.controller.php). Dabei greift der Generator auf Prototypen zurück. Es existieren Prototypen für HTML-Komponenten, Datenbank-Abfragen, Seiten-Controller, API-Controller und den clientseitigen Code. Es handelt sich insgesamt um einen Codege- nerator. Jeder generierte Code ist automatisiert prüfbar hinsichtlich Syntax und weiterer Auälligkeiten. Der verantwortlichen Person steht es frei den Code unverändert zu belas- sen oder eigene Modi kationen vorzunehmen. Empfehlenswerter ist jedoch die Verwen- dung der de nierten Schnittstellen zur Erweiterung. Solche Schnittstellen sind innerhalb der Controller und des clientseitigen Codes vorgesehen. Ein gra scher Beschreibungseditor unterstützt die Erstellung der Beschreibung und er- leichtert deutlich ihre Handhabung. Die Erstellungszeit kann damit beschleunigt werden. Laut Forrester ist die visuelle Modellierung von Datenmodellen, Geschäftslogik und Be- nutzerober ächen ein wesentlicher Bestandteil von Low-Code-Plattformen und trägt zu einer signi kanten Produktivitätssteigerung bei.[6, S. 5] Ein Screenshot aus der prototypisch entwickelten Anwendung wird hier dargestellt: 8
Abbildung 4: Screenshot Beschreibungseditor mit Fallbeispiel
Jeder Bestandteil der ersten Ebene in der Beschreibung ist als Reiter dargestellt. Un-
terhalb eines Reiters be nden sich die weiteren Optionen. Dies sind Listen weiterer zu
dem Bestandteil gehörender Einträge. Jeder Eintrag kann weitere Einträge oder eigene
Optionen besitzen. Dadurch ist eine listengesteuerte Bedienung realisiert worden. Sinn
der Anwendung ist auch dem Benutzer Hinweise zu geben, welche Optionen möglich
oder sinnvoll sind, welche Einschränkungen zu beachten sind und welche Auswirkungen
bestimmte Änderungen haben können.
Durch die Einhaltung von Standards können Datenmodelle, Benutzerober ächen und
Geschäftslogik grundsätzlich importiert und exportiert werden. Dies erleichtert die Por-
tabilität bestehender Anwendungen und reduziert den Aufwand für Neuentwicklungen
auf Basis bestehender Realisierungen. Auch erleichtert es die Portierung für andere Fra-
meworks und Laufzeitumgebungen.
Die Änderung von Datenmodellen erfordert die Anpassung der Schemata in der Daten-
bank. Damit bestehende Daten nicht verloren gehen, müssen Migrationsschritte durch-
geführt werden, die erstens die geänderten Attribute in die Schemata einp egen und
zweitens Regeln für bestehende oder nicht bestehende Daten für geänderte Attribute de-
niert werden. Eine automatische Generierung der Änderungsschritte für die Struktur und
De nition der Regeln für die Übernahme von Daten erleichtert eine Aktualisierung der
Anwendung erheblich und soll durch entsprechende Tools realisiert werden. Migrationen
fallen bei Änderungen in generierten Anwendungen genauso häu g an, wie in nicht ge-
nerierten Anwendungen. Jedoch wird bei generierten Anwendungen sinnvollerweise auch
eine automatische Migration erwartet. Bei Änderungen können im Wesentlichen zwei Be-
reiche betroen sein: das sind zum einen die aus der Beschreibung generierten Assets
und zum anderen die aus der Beschreibung abgeleiteten Entitäten in der Datenbank. Die
Migration von Assets ist in der Regel durch Überscheiben möglich. Dies ist jedoch nur
möglich, wenn die generierten Assets nicht nachträglich modi ziert worden sind. Denn in
diesem Fall müssten die Modi kationen erneut durchgeführt werden. Aber sofern keine
Modi kationen notwendig waren oder keine Modi kationen vorgenommen worden sind,
ist ein Überschreiben möglich. Sofern Entitäten in der Datenbank geändert werden müs-
sen, muss ein Migrationsskript ausgeführt werden. Dabei ist zu unterscheiden, ob bereits
produktive Daten vorhanden sind und somit Ersetzungen ohne Datenverlust möglich sind
oder inkrementelle Änderungen durchgeführt werden müssen.
Eine Erstellung der Dokumentation ist teilweise automatisierbar. Unterstützt wird die Er-
9stellung der Dokumentation durch die maschinenlesbare Beschreibung, aus der Abschnitte
generiert werden können. Tiefer gehende semantische Erklärungen können durch benut-
zerde nierte Beschreibungen ergänzt werden. Diese benutzerde nierten Beschreibungen
können an de nierten Stellen eingep egt werden. Damit ist die Dokumentation teilau-
tomatisiert und vergleichbar mit der codebasierten Generierung von Dokumentation aus
Kommentaren. Angestoÿen wird die Generierung mithilfe eines Dokumentationsgenera-
tors. Viele Softwareprojekte setzen auf automatisierte Generierung von Dokumentationen
aus Kommentaren im Code. Teilweise genügen auch automatisch generierte Kommentare,
die lediglich Namen und Parameter nennen. Häu g werden die semantischen Erklärungen
noch durch den Entwickler ergänzt, sofern die Bedeutung sich nicht selbsterklärend aus
dem Kontext ableitet. In Low-Code-Plattformen fällt wenig selbstgeschriebener Code an
und damit auch weniger Kommentare die für Dokumentationen relevant sind. Jedoch liegt
der Fokus auf Beschreibungen und diese sind durchaus kommentierbar und nicht immer
selbsterklärend. Die Dienste und Prozesse werden aus der Beschreibung automatisiert
extrahiert und grundlegend dokumentiert. Hier sind Namen, Parameter und semantische
Erklärungen relevant. Externe Entwickler sollen wissen, welche Dienste sie aufrufen kön-
nen, welche Parameter sie angeben können und was der Dienst oder Prozess bewirkt.
Als Zielformat wurde Markdown[27] gewählt. Dieses bietet ausreichend viele Formatie-
rungsoptionen, hält aber die Kompatibilität zu weiteren Zielformaten oen. Hinsichtlich
einer Abdeckung der gewöhnlichen Bestandteile einer Softwaredokumentation kann die
automatisierte Dokumentation den Quellcode und die Daten abdecken, Methoden und
Entwicklung erfordern eine Beisteuerung durch die Entwickler. Aufgrund der standardi-
sierten Laufzeitumgebung ist eine teilweise automatisierte Beschreibung der Installation
aber ebenfalls möglich. Nur die Dokumentation für Endbenutzer und von Tests muss
gesondert erfolgen. Allerdings könnten automatisiert erstellte Tests ebenfalls automa-
tisch dokumentiert werden. Insgesamt können damit perspektivisch die überwiegenden
Bestandteile einer Softwaredokumentation abgebildet werden.
Import
Beschreibungseditor Generator Migration Dokumentation
Export
Abbildung 5: Zusammenspiel der Komponenten im zeitlichen Ablauf
Das Ablaufdiagramm zeigt das Zusammenspiel aller eben beschriebenen Komponenten.
Der Beschreibungseditor ermöglicht die Änderungen an der Beschreibung, wobei wieder-
um Beschreibungen durch einen Import eingebunden werden können sowie auch bestehen-
de Beschreibungen exportiert werden können. Die Beschreibung wird schlieÿlich an den
Generator übergeben, der die Artefakte erstellt und als weitere Schritte gegebenenfalls
10zu einer Datenbankmigration führt sowie bei Bedarf automatisch eine Dokumentation er-
zeugt wird. Exportierfähige Elemente entstehen auch während der Aktivität des Genera-
tors oder der Erstellung der Dokumentation. Damit ist der Software-Entwicklungszyklus
von Codeproduktion bis Dokumentation und Inbetriebnahme vollständig abgedeckt.
3.3 Evaluation anhand eines Fallbeispiels
Um das Fallbeispiel zu realisieren, kann ein neues Projekt wie folgt initialisiert werden:
Mit `composer init` wird ein Composer-Projekt unter Abfrage wesentlicher Parameter wie
Bezeichnung, Beschreibung und Autoren des Projekts angelegt und mit `composer require
lsdl/protogen` die prototypische Umsetzung des Generators eingebunden. Als nächster
Schritt ist die contract.json im oben beschriebenen Format vorzubereiten.
Dort werden zunächst benötigte Domänen angelegt für Nutzer (einschlieÿlich Rolle), Fra-
gebögen, Fragen, Antworten sowie Ziele. Fragebögen und Fragen sind über eine Relation
zu verbinden, ebenso Nutzer (Verwalter) mit Fragebögen. Eine benötigte View ist ein
JOIN zwischen der Fragebögen-Fragen-Relation und der Fragen-Domäne sowie eine wei-
tere View die ebendiese noch zusätzlich mit der Antwort-Domäne kreuzt, um gegebene
Antworten zu erhalten. Als Seiten werden unter anderem Nutzer-, Fragebogen- und Ziel-
verwaltung sowie Fragebogenauslieferung de niert. Dabei enthält die Nutzerverwaltung
eine Nutzerliste und ein Nutzerformular, welches einen Nutzereditor abbildet. Ebenso die
Fragebogenverwaltung einen Fragebogeneditor sowie einen davon abhängigen Fragenedi-
tor. Schlieÿlich enthält die Zielverwaltung einen Zieleditor. Die Fragebogenauslieferung
wird ebenfalls mithilfe eines Editors realisiert, der Fragen au istet und zu jeder Frage ei-
ne Eingabe mittels eines önenden Formulars ermöglicht. Zur Auswertung kann ebenfalls
eine Seite hinzugefügt werden, die eine Auswahl des gewünschten Fragebogens ermöglicht
und durch Plugins entsprechende aufbereitete Statistiken präsentiert.
Die Anforderungen des Lastenheftes konnten durch Umsetzung der Vorschläge im P ich-
tenheft erfüllt werden. Das umfasst die Schwerpunkte Authenti zierung, Nutzerverwal-
tung, Fragebogenverwaltung, Fragebogendarstellung, Zielverwaltung und Auswertungs-
logik. Für die Authenti zierung wird ein vorbereitetes Plugin verwendet, welches die
an der Universität verwendeten Shibboleth-Informationen ausliest. Vollständig beschrie-
ben werden können Nutzerverwaltung, Fragebogenverwaltung und Zielverwaltung. Die
Schwerpunkte Fragebogendarstellung und Auswertungslogik, die beide den Bereich der
Kernlogik und der Präsentation umfassen, lassen sich durch benutzerde nierte Plugins
umsetzen. Damit lässt sich ein umfassender Teil beschreiben, so dass nur noch die tat-
sächlich anwendungsspezi schen Punkte programmiert werden müssen. Das führt zu einer
erheblichen Zeitersparnis bei der Entwicklung einer solchen Anwendung.
Obwohl eine Realisierung des SURE-Tools hinsichtlich der Anforderungen auch mit ei-
nem Produkt der Schlüsselhersteller im Markt der Low-Code-Plattformen möglich wäre,
konnte dies so kostengünstiger mit einer schlankeren Umgebung und mehr Kompatibilität
zu Standards erreicht werden.
11Abbildung 6: Screenshot der generierten Fragebogenverwaltung aus dem Fallbeispiel 4 Fazit Es konnten mit dieser Arbeit zwei Meilensteine erreicht werden. Der erste Meilen- stein ist die Realisierung eines Konzepts für eine Beschreibungssprache und einer Tool- Infrastruktur einer Low-Code-Plattform, welche handlich und standardkompatibel ist sowie die in der Einleitung formulierten Zielstellungen erfüllt. Auÿerdem wurde das Kon- zept in einem ersten Prototypen umgesetzt. Als zweiter Meilenstein kann die Anwendung an dem Fallbeispiel zur Entwicklung des Tools für das E-Learning Evaluationsmodell SURE angesehen werden. Mithilfe der entwickelten Low-Code-Plattformen konnten die Anforderungen umgesetzt werden und die Anwendung realisiert werden. In Bezug auf die entwickelte Low-Code-Plattformen sind die Zielstellungen erfüllt. Durch die Struktur und die automatische Generierung wird die Menge an zu schreibendem Code deutlich reduziert und vermindert Redundanzen. Die Komponenten der einzelnen Berei- che (Datenmodelle, Listen, Formulare, Seiten, Dienste, Prozesse) sind ent echtet und wiederverwendbar und erfüllen damit das Prinzip der Orthogonalität. Die Beschreibun- gen können mit geringem Aufwand geändert werden und einzelne Bestandteile ausge- tauscht werden, auch bestehen Schnittstellen die es ermöglichen andere Endprodukte zu 12
verwenden, das kann etwa ein anderes Datenbanksystem sein oder ein anderer What-
You-See-Is-What-You-Get-Editor (WYSIWYG) für Ansichten, so dass auch das Prinzip
der Reversibilität erfüllt ist. Auch von Domänensprachen wird Gebrauch gemacht (SQL,
Orientierung an Formularbeschreibungsstandards oder Prozessmodellierungsstandards,
HTML, CSS). Es ist möglich mit der Plattform eine prototypengetriebene Entwicklung
zu betreiben, indem Auswirkungen in der Beschreibung verhältnismäÿig schnell geprüft
werden können.
Verschiedene Schnittstellen ermöglichen Eingrie ohne das generierte Gerüst direkt ver-
ändern zu müssen. Solche Schnittstellen be nden sich serverseitig durch die Möglichkeit
Plugin-Skripte einbinden zu können und dort global de nierte Funktionen aufrufen zu
können oder an Pluginschnittstellen bei Authenti zierung oder dem Seitenladen zu bin-
den. Des Weiteren können clientseitig Funktionen de niert werden, die entweder beim
Laden von Widgets oder Interaktionen mit diesen oder aber bei Serverinteraktionen get-
riggert werden. Es ist zukünftig möglich diese Schnittstellen im Sinne einer Modularität
noch weiter auszubauen.
Zentrale Aufgabe für die Zukunft ist die Weiterentwicklung der einzelnen Tools der
Plattform. Der Beschreibungseditor sollte um intuitive Elemente, Vorschläge, Drag-and-
Drop/Copy-and-Paste-Unterstützung und Plausibilitätsprüfungen erweitert werden. Ins-
gesamt können On-Top unterstützende Tools bereitgestellt werden, dazu ist nicht not-
wendigerweise eine Änderung der Beschreibungsspezi kation oder der Kernkomponenten
erforderlich. Zukünftige Forschungsfelder könnten neuartige Arten zum Design und zur
Beschreibung sein. Das schlieÿt eine Bedienung mit Sprachkommandos aber auch die Ab-
leitung von Beschreibungen aus anderen intuitiven Eingaben ein. Denkbar ist auÿerdem
die Nutzung von künstlicher Intelligenz oder Maschinenlernen um Vorschläge für Design
oder Beschreibung auf der Grundlage von Vorhersagen zu machen, was den Aufwand zur
Umsetzung von Anwendungen noch weiter reduziert.
Eine besondere Stärke der Plattform liegt oenkundig in formularbasierten Anwendun-
gen, die einen erheblichen Teil unternehmensinterner oder wissenschaftlicher Software
ausmachen. Für die Zukunft könnte die Plattform auch für die Erstellung und P ege
öentlich zugänglicher Webseiten sowie deren Belange und Nebenbedingungen, die leicht
von unternehmensinternen oder wissenschaftlichen Anwendungen abweichen können, wie
etwa Suchmaschinenoptimierung oder Performance, optimiert werden.
Hinweis
Der Autor weist darauf hin, dass diese Veröentlichung auf seiner zuvor angefertigten
Masterarbeit basiert.
Literatur
[1] A. Hunt and D. Thomas, Pragmatic Programmer, The: From Journeyman to Master,
ch. A Pragmatic Approach, pp. 2569. Reading, Massachusetts: Addison Wesley,
1999.
13[2] Foundeo, Inc., ColdFusion Versions. https://cfdocs.org/coldfusion-versions,
2018. [Online, Stand: Januar 2019].
[3] D. H. Hansson, Creator of Ruby on Rails. https://dhh.dk/#rails, 2018. [Online,
Stand: Januar 2019].
[4] D. H. Hansson, The Rails Command Line. https://guides.rubyonrails.org/
command_line.html, 2018. [Online, Stand: Januar 2019].
[5] C. Richardson, J. R. Rymer, C. Mines, A. Cullen, and D. Whittaker, New Deve-
lopment Platforms Emerge For Customer-Facing Applications, 2014.
[6] C. Richardson and J. R. Rymer, Vendor Landscape: The Fractured, Fertile Terrain
of Low-code Application Platforms, 2016.
[7] Markets and Markets, Low-Code Development Platform Market, 2018.
[8] TrustRadius, Low-Code Development Platforms. https://www.trustradius.
com/low-code-development, 2018. [Online, Stand: Januar 2019].
[9] J. Arnoldus, M. Brand, A. Serebrenik, and J. J. Brunekreef, Code generation with
templates, Rheologica Acta - RHEOL ACTA, 01 2012.
[10] D.-P. Pop and A. Altar, Designing an MVC Model for Rapid Web Application
Development, Procedia Engineering, vol. 69, pp. 1172 1179, 2014. 24th DAAAM
International Symposium on Intelligent Manufacturing and Automation, 2013.
[11] HotFrameworks, Web framework rankings. https://hotframeworks.com/, 2018.
[Online, Stand: Januar 2019].
[12] M. Springwald, Blob sh is a generic web framework written in php. https:
//packagist.org/packages/greenscale/blobfish, 2018. [Online, Stand: Januar
2019].
[13] U. Tudevdagva, Structure Oriented Evaluation Model for E-Learning. Habilitations-
schrift, Universitätsverlag Chemnitz, 2014.
[14] ISO Central Secretary, Information technology Database languages SQL, Tech.
Rep. ISO/IEC 9075, International Organization for Standardization, 2016.
[15] R. Chinnici, R. A. Moreau, J.-J., and S. Weerawarana, Web Services Description
Language (WSDL) Version 2.0 Part 1: Core Language. https://www.w3.org/TR/
wsdl/, 2007. [Online, Stand: Januar 2019].
[16] H. Andrews et al., JSON Schema. https://json-schema.org/, 2018. [Online,
Stand: Januar 2019].
[17] O. M. Group, Business Process Model and Notation. https://www.omg.org/spec/
BPMN/2.0.1/, 2013. [Online, Stand: Januar 2019].
[18] D. Jordan and J. Evdemon, Web Services Business Process Execution Langua-
ge Version 2.0. http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.
html, 2007. [Online, Stand: Januar 2019].
14[19] J. M. Boyer, L. L. Klotz Jr., S. Pemberton, and N. Van den Bleeken, XForms 2.0.
https://www.w3.org/TR/xforms20/, 2012. [Online, Stand: Januar 2019].
https://www.ibm.com/support/knowledgecenter/
[20] IBM, XFDL Speci cation.
en/SSS28S_8.2.1/XFDL_Specification/xfdl_overview.html, 2015. [Online,
Stand: Januar 2019].
[21] S. Faulkner, A. Eicholz, T. Leithead, A. Danilo, and S. Moon, HTML 5.2. https:
//www.w3.org/TR/html52/, 2017. [Online, Stand: Januar 2019].
[22] T. Atkins Jr., E. J. Etemad, and F. Rivoal, CSS Snapshot 2018. https://www.w3.
org/TR/css-2018/, 2018. [Online, Stand: Januar 2019].
[23] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau, Extensible
Markup Language (XML) 1.0 (Fifth Edition). https://www.w3.org/TR/xml/, 2008.
[Online, Stand: Januar 2019].
[24] M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. F. Nielsen, A. Karmarkar,
and Y. Lafon, SOAP Version 1.2 Part 1: Messaging Framework (Second Edition).
https://www.w3.org/TR/soap12-part1/, 2007. [Online, Stand: Januar 2019].
[25] T. W. Bray, The JavaScript Object Notation (JSON) Data Interchange Format.
https://tools.ietf.org/html/rfc7159, 2014. [Online, Stand: Januar 2019].
https://www.heise.de/ix/
[26] C. Kirsch, Webservices-Konsortium löst sich auf.
meldung/Webservices-Konsortium-loest-sich-auf-1134920.html, 2010. [Onli-
ne, Stand: Januar 2019].
[27] J. Gruber and A. Swartz, Markdown. https://daringfireball.net/projects/
markdown/, 2018. [Online, Stand: Januar 2019].
15Chemnitzer Informatik-Berichte
In der Reihe der Chemnitzer Informatik-Berichte sind folgende Berichte erschienen:
CSR-10-01 Maximilian Eibl, Jens Kürsten, Robert Knauf, Marc Ritter , Workshop Au-
diovisuelle Medien, Mai 2010, Chemnitz
CSR-10-02 Thomas Reichel, Gudula Rünger, Daniel Steger, Haibin Xu, IT-
Unterstützung zur energiesensitiven Produktentwicklung,
Juli 2010, Chemnitz
CSR-10-03 Björn Kre llner, Thomas Reichel, Gudula Rünger, Marvin Ferber, Sascha
Hunold, Thomas Rauber, Jürgen Berndt, Ingo Nobbers, Transformation mo-
nolithischer Business-Softwaresysteme in verteilte, workflowbasierte Client-
Server-Architekturen, Juli 2010, Chemnitz
CSR-10-04 Björn Krellner, Gudula Rünger, Daniel Steger, Anforderungen an ein Da-
tenmodell für energiesensitive Prozessketten von Powertrain-Komponenten,
Juli 2010, Chemnitz
CSR-11-01 David Brunner, Guido Brunnett, Closing feature regions, März 2011, Chem-
nitz
CSR-11-02 Tom Kühnert, David Brunner, Guido Brunnett, Betrachtungen zur Skelet-
textraktion umformtechnischer Bauteile, März 2011, Chemnitz
CSR-11-03 Uranchimeg Tudevdagva, Wolfram Hardt, A new evaluation model for
eLearning programs, Dezember 2011, Chemnitz
CSR-12-01 Studentensymposium Informatik Chemnitz 2012, Tagungsband zum 1. Stu-
dentensymposium Chemnitz vom 4. Juli 2012, Juni 2012, Chemnitz
CSR-12-02 Tom Kühnert, Stephan Rusdorf, Guido Brunnett, Technischer Bericht zum
virtuellen 3D-Stiefeldesign, Juli 2012, Chemnitz
CSR-12-03 René Bergelt, Matthias Vodel, Wolfram Hardt, Generische Datenerfassung
und Aufbereitung im Kontext verteilter, heterogener Sensor-Aktor-Systeme,
August 2012, Chemnitz
CSR-12-04 Arne Berger, Maximilian Eibl, Stephan Heinich, Robert Knauf, Jens
Kürsten, Albrecht Kurze, Markus Rickert, Marc Ritter , Schlussbericht zum
InnoProfile Forschungsvorhaben sachsMedia - Cooperative Producing, Sto-
rag, Retrieval and Distribution of Audiovisual Media (FKZ: 03IP608), Sep-
tember 2012, Chemnitz
CSR-12-05 Anke Tallig, Grenzgänger - Roboter als Mittler zwischen der virtuellen und
realen sozialen Welt, Oktober 2012, ChemnitzChemnitzer Informatik-Berichte
CSR-13-01 Navchaa Tserendorj, Uranchimeg Tudevdagva, Ariane Heller, Grenzgänger -
Integration of Learning Management System into University-level Teaching
and Learning, Januar 2013, Chemnitz
CSR-13-02 Thomas Reichel, Gudula Rünger, Multi-Criteria Decision Support for Ma-
nufacturing Process Chains, März 2013, Chemnitz
CSR-13-03 Haibin Xu,Thomas Reichel, Gudula Rünger, Michael Schwind, Softwaretech-
nische Verknüpfung der interaktiven Softwareplattform Energy Navigator
und der Virtual Reality Control Platform, Juli 2013, Chemnitz
CSR-13-04 International Summerworkshop Computer Science 2013, Proceedings of In-
ternational Summerworkshop 17.7. - 19.7.2013, Juli 2013, Chemnitz
CSR-13-05 Jens Lang, Gudula Rünger, Paul Stöcker, Dynamische Simulationskopplung
von Simulink-Modellen durch einen Functional-Mock-up-Interface- Export-
filter, August 2013, Chemnitz
CSR-14-01 International Summerschool Computer Science 2014, Proceedings of Sum-
merschool 7.7.-13.7.2014, Juni 2014, Chemnitz
CSR-15-01 Arne Berger, Maximilian Eibl, Stephan Heinich, Robert Herms, Stefan Kahl,
Jens Kürsten, Albrecht Kurze, Robert Manthey, Markus Rickert, Marc Rit-
ter, ValidAX - Validierung der Frameworks AMOPA und XTRIEVAL, Ja-
nuar 2015, Chemnitz
CSR-15-02 Maximilian Speicher, What is Usability? A Characterization based on ISO
9241-11 and ISO/IEC 25010, Januar 2015, Chemnitz
CSR-16-01 Maxim Bakaev, Martin Gaedke, Sebastian Heil, Kansei Engineering Expe-
rimental Research with University Websites, April 2016, Chemnitz
CSR-18-01 Jan-Philipp Heinrich, Carsten Neise, Andreas Müller, Ähnlichkeitsmessung
von ausgewählten Datentypen in Datenbanksystemen zur Berechnung des
Grades der Anonymisierung, Februar 2018, Chemnitz
CSR-18-02 Liang Zhang, Guido Brunnett, Efficient Dynamic Alignment of Motions,
Februar 2018, Chemnitz
CSR-18-03 Guido Brunnett, Maximilian Eibl, Fred Hamker, Peter Ohler, Peter Prot-
zel, StayCentered - Methodenbasis eines Assistenzsystems für Centerlotsen
(MACeLot) Schlussbericht, November 2018, Chemnitz
CSR-19-01 Johannes Dörfelt, Wolfram Hardt, Christian Rosjat, Intelligente Gebäude-
klimatisierung auf Basis eines Sensornetzwerks und künstlicher Intelligenz,
Februar 2019, Chemnitz
CSR-19-02 Martin Springwald, Wolfram Hardt, Entwicklung einer RAD-Plattform im
Kontext verteilter Systeme, März 2019, ChemnitzChemnitzer Informatik-Berichte
ISSN 0947-5125
Herausgeber: Fakultät für Informatik, TU Chemnitz
Straße der Nationen 62, D-09111 ChemnitzSie können auch lesen
