Was ist visuelle Programmierung?

Andere, visuelle Programmierungstools folgen den gleichen Prozessen und Paradigmen wie die textbasierte Programmierung. Stellen Sie sich vor, Sie zeichnen eine Klasse und ihre Beziehung zu den Objekten, die Sie instanziieren, anstatt alles in einen Texteditor einzugeben.

Eine kurze Geschichte visueller Programmiersoftware

 

Auch wenn es auf den ersten Blick anders aussieht, beschränkte sich die visuelle Programmierung in den 1990ern keineswegs nur auf Spielentwicklungskits, Multimedia-Tools und Datenbanken. Rational Software (2003 von IBM übernommen) hatte seit Mitte der 1980er-Jahre eine Ada-IDE ohne grafische Benutzeroberfläche entwickelt. Darüber hinaus hat sich das Unternehmen auch mit der Definition des Softwareentwicklungsprozesses befasst.

Die Arbeit am Rational Unified Process und damit verwandte Bemühungen führten schließlich zur Unified Modelling Language, die das Potenzial hatte, jeden einzelnen Teil eines Systems zu dokumentieren – ohne jemals eine Zeile Code zu schreiben. Das Ganze sah aus wie visuelle Programmierung, produzierte jedoch keine ausführbare Software.

Mit der UML wurde eine standardisierte und umfassende Sprache für die Beschreibung objektorientierter Systeme geschaffen. Daraufhin wurden einige Architekten jedoch von einer Art UML-Fieber befallen. So berichtet der Co-Autor von The Pragmatic Programmer, Andy Hunt, von einem Softwareprojekt, bei dem ein Architekt zwei Jahre lang UML-Diagramme erstellte, bevor auch nur eine Zeile Code geschrieben wurde.

Gerade als agile Methoden an Bedeutung gewannen, schien UML die problematischsten Aspekte der alten Methoden der Softwareentwicklung zu unterstützen: zu viel Planung und zu wenig Umsetzung. Ausführbare UML war ein Versuch, das fehlende Element – ausführbare Software – hinzuzufügen. Es gab mehrere Implementierungen, die jedoch keine allzu großen Auswirkungen auf eine Welt hatten, die ihren Fokus schnell auf PHP, Ruby on Rails und andere dynamische Skriptsprachen richtete.

Interessanterweise stammt eine Form ausführbarer UML, die sich durchgesetzt hat, ebenfalls von Rational Software. Rational Rose ist eine Suite von Werkzeugen zur Erstellung von Software unter Verwendung von UML und zur Generierung von ausführbarem Code in einer Zielsprache, wie C++ oder Java.

 

Fall-Ansicht in Rational Rose. Bildquelle: Assignment Help.

Der Stand der visuellen Programmierung heute

Ist die Zeit visueller Programmierung also vorbei? Anhänger der visuellen Programmierung werden das Gegenteil behaupten. Auf die Frage: „Was ist visuelle Programmierung?“ werden sie ein obskures domänenspezifisches Tool nennen. Und dann dieses Tool als Beweis dafür anführen, dass die visuelle Programmierung alles andere als tot ist.

Eine schnelle Google-Suche führt Sie nicht nur zu dem erwähnten Tool, sondern auch in eine hochspezialisierte Welt, in der dieses Tool existiert.

Zweifelsohne hat die visuelle Programmierung ihre Berechtigung – sei es bei der Programmierung von Synthesizern oder um UML-Enthusiasten ein Erfolgserlebnis zu verschaffen. Für die rein visuelle Modellierung allgemeiner Software ist die Welt jedoch einfach zu komplex.

Wenn Ihr „Code“ wie ein CPU-Schaltplan aussieht, könnte es an der Zeit sein, die Eignung der visuellen Programmierung für Ihren Zweck zu hinterfragen.

Hinzu kommt, dass visuelle Programmiersoftware in der Regel durch die Vorstellungskraft des Entwicklers begrenzt ist. Für allgemeine textuelle Programmiersprachen trifft dies nicht zu.

Und doch haben uns Tools wie Visual Basic, Delphi und ihre Nachfahren gezeigt, dass die visuelle Erstellung von Software enorm effizient sein kann. Mit einem pragmatischen Kompromiss: Dass handgeschriebener Code zuweilen die bessere Lösung ist.

Haben visuelle Programmiersprachen heute noch einen Platz?

Die Anfänge des Programmierens waren hart, keine Frage. Dennoch konnte eine Person alles verstehen und Experte für alles sein, was für die Entwicklung dieser Software notwendig war. Wenn Sie das entsprechende Alter haben, erinnern Sie sich an die Softwaretitel der 1980er-Jahre. Es war üblich, dass ein einzelner Programmierer zu einer eigenständigen Marke wurde.

Sid Meier, Mitch Kapor und Jeff Minter erlangten Berühmtheit durch die Entwicklung bekannter Applikationen oder Spiele im Alleingang oder in Zusammenarbeit mit höchstens einem weiteren Mitarbeiter. Damals dauerten die Aktualisierungszyklen für Software und Hardware Jahre. Heute gibt es Witze darüber, dass jeden Tag eine neue JavaScript-Bibliothek veröffentlicht wird. Dennoch ist an dem Gedanken etwas dran, dass die moderne Softwareentwicklung in einem Tempo voranschreitet, mit dem viele von uns nicht mithalten können.

Heute wird Software weitgehend von Spezialistenteams entwickelt. Während die frühen Entwickler alles selbst gemacht haben, gibt es in modernen Softwareentwicklungsteams vielleicht eine Person, deren einzige Aufgabe darin besteht, sich um das CI-Tool zu kümmern. Entwickler verbringen ganze Karrieren damit, sich auf ein Framework oder eine Plattform zu konzentrieren. iOS-Entwickler sind iOS-Entwickler, keine Mobile-Entwickler. Ein oder zwei Mal pro Jahrzehnt wechselt ein Webentwickler vielleicht sein bevorzugtes Framework. Und nur sehr wenige Menschen schreiben Assembler professionell von Hand.

Es ist nicht nur so, dass sich der Umfang von Software geändert hat. In gewisser Weise haben sich auch die Entwickler selbst verändert. Heute ist Software-Engineering ein Beruf wie jeder andere. In den vergangenen Jahrzehnten war dies eine Leidenschaft einiger weniger Leute, die die Hingabe hatten, ein völlig neues System zu erlernen, um z. B. den Atari ST Port ihres erfolgreichen Amiga-Spiels zu schreiben. Doch das ist verständlich, denn Informatik ist keine Nische mehr.

Heute besteht die Softwareentwicklung aus immer komplexeren Teilbereichen, und Entwickler sind gewöhnliche Menschen mit außergewöhnlichen Spezialisierungen. Diese komplexen Anforderungen und Spezialisierungen passen nicht mehr zur rein visuellen Programmierung der frühen Tools, machen es aber auch immer schwieriger, kompetente Softwareentwicklungsteams aufzubauen.

Wo rein visuelle Programmierumgebungen versagt haben, gibt es eine ganze Reihe ähnlicher Tools, die das Beste aus der visuellen Programmierung mit der textbasierten Programmierung kombinieren. Während die visuelle Programmierung auf „No-Code“ basierte, nutzen die neuen Tools „Low-Code“ als Grundlage.

Diese Tools ermöglichen es Entwicklern, Software visuell zu erstellen, indem sie Interaktionsabläufe, Benutzeroberflächen und die Beziehungen zwischen Objekten zeichnen. Zugleich aber erlauben sie auch handgeschriebenen Code, wenn dies die bessere Lösung ist.

Diese pragmatische Mischung aus visueller und textbasierter Programmierung eignet sich gut für die Anforderungen der modernen Softwareentwicklung. Low-Code-Plattformen verringern die Komplexität der Softwareentwicklung und führen uns in eine Welt zurück, in der ein einzelner Entwickler umfangreiche und komplexe Systeme erstellen kann, ohne alle zugrunde liegenden Technologien erlernen zu müssen.

Die nächste Generation visueller Programmierung: Einlösen des Versprechens

Die visuelle Programmierung war vielversprechend, und die Probleme, die sie lösen sollte, sind nicht verschwunden. Sie sind sogar relevanter als je zuvor.

Doch reale Probleme erfordern mehr Flexibilität, als die visuelle Programmierung bieten kann. Low-Code nimmt das Versprechen auf und nutzt es, um die Komplexität, die wir in der modernen Softwareentwicklung vorfinden, zu reduzieren. Die bessere Frage als „Was ist visuelle Programmierung?“ lautet deshalb heute: „Was ist Low-Code?“