Roboter als Programmierer

02.01.2001 von Klaus Manhart
Computerprogramme zu entwickeln ist nicht nur aufwändig und teuer - die Ergebnisse stecken auch oft voller Fehler. Ein deutsches IT-Unternehmen will mit Software-Robotern die Entwicklung automatisieren und garantiert '100 Prozent fehlerfreie Software'.

"Würden Sie mit einem Flugzeug fliegen, das so gebaut ist, wie die Software von heute? - Sie glauben nicht, dass es 100 Prozent fehlerfreie Software gibt?" Martin Rösch, Geschäftsführer der rheinischen Rösch Consulting GmbH, liebt es, sein Publikum mit solchen Aussagen zu provozieren. Auf der Entwicklermesse Components 2000 Mitte Oktober in München berichtete der gelernte Informatiker dem erstaunten Publikum von der Erstellung kompletter Software-Systeme, die "garantiert und nachweisbar richtig sind". Von Rösch erstellte Software, untermauerte der Kaarster Unternehmer wiederholt in seinen Vortrag, ist zuverlässig und 100 Prozent fehlerfrei.

Röschs Ansatz ist zwar nicht neu, er will ihn aber konsequent in die Praxis umsetzen: Programmierer spielen bei seiner Methode der Software-Entwicklung nur mehr eine kleine Rolle. Von menschlichen Unzulänglichkeiten befreit erstellen Software-Roboter die Programme automatisch. Sie sollen die Gewähr bieten, dass die Computersysteme fehlerfrei arbeiten. Und sollten Kunden tatsächlich Mängel entdecken, bekommen sie ihr Geld zurück. An der herkömmlichen Methode der Software-Entwicklung lässt Rösch kein gutes Haar: "Alle uns bekannten Software-Fehler von Handys, Navigationssystemen, Abrechnungssystemen, aber auch von Systemen der Luft- und Raumfahrt wären mit den von Rösch Consulting entwickelten Verfahren und Werkzeugen vermeidbar gewesen."

Fehler in Software sind vorprogrammiert

Starke Sprüche nicht nur für Software-Experten. Denn jeder PC-Einsteiger weiß aus leidvoller Erfahrung mit Word, Windows und anderen Programmen, wie es um die Fehlerfreiheit von Software bestellt ist: Jedes Programm enthält Fehler, sie sind unvermeidbar. Dafür, dass moderne Software so anfällig für Fehler ist, gibt es mehrere Gründe. Zum einen müssen die Programme heute immer mehr Anforderungen genügen, gleichzeitig steigen die Qualitätsanforderungen der Nutzer. Zum anderen wird technisches und fachliches Wissen in der Programmentwicklung weitgehend vermengt. Heutige Software-Entwickler müssen nicht nur technisches Wissen über die Architektur der Software besitzen, sondern auch über inhaltliche, fachliche Kompetenz verfügen, etwa im Banken- und Versicherungswesen. Dabei stoßen sie naturgemäß schnell an ihre Grenzen. Ändert sich die Software-Architektur selbst, müssen zudem viele, wenn nicht alle Anwendungen geändert und erneut getestet werden.

Gestandene Informatiker sind bei Ankündigungen von fehlerfreier Software erst recht skeptisch. Denn sie wissen: Methoden, die stets zu fehlerfreier Software führen, kann es aus rein mathematischen Gründen nicht geben. Prof. Klaus Jantke vom Deutschen Forschungszentrum für Künstliche Intelligenz, der sich im Rahmen des vom Bundesministerium für Wirtschaft und Technologie geförderten Fairpay-Projektes mit zuverlässigen Zahlungssystemen beschäftigt, bemüht sich zwar, Software mit mathematisch beweisbaren Sicherheitseigenschaften zu erstellen. Er gibt aber zu Bedenken: "Zwar ist es theoretisch tatsächlich möglich, aus hinreichend präzisen Spezifikationen automatisch korrekte Programme zu generieren. Andererseits gibt es hinreichend viele sinnvolle Spezifikationen, für die gilt, dass es keine berechenbare Methode gibt, automatisch korrekte Programme zu generieren. Das geht nachweislich nicht."

Vorbild: Industrielle Fertigungsmethoden

Von Ansätzen, die Fehlerfreiheit von Programmen formal zu garantieren, distanziert sich Rösch. Rösch ist ein Praktiker und seine Motivation leitet sich historisch ab: Er will die Software-Entwicklung nach dem Vorbild traditioneller Industriezweige wie der Fertigungsindustrie organisieren - und damit Fehler ausschließen. Diese Industriezweige haben einen klaren, einheitlichen Weg hinter sich: Vom Handwerk über die Manufaktur und die Fabrik hin zu Massenfertigung und CIM (Computer Integrated Manufacturing).

Die Software-Industrie hinkt dieser Entwicklung hinterher, sie ist gegenwärtig auf dem Stand einer Manufaktur. Denn Programmierung läuft noch kaum routinisiert und automatisiert ab. Entwickler müssen ähnliche Code-Sequenzen immer wieder manuell eingeben. "Vergleicht man die Software-Entwicklung mit dem historischen Schritt vom Handwerksbetrieb zur industriellen Massenproduktion, so arbeiten Programmierer heute wie vor 50 Jahren noch als Handwerker", analysiert Rösch die derzeitige Situation.

In der Automatisierung der Software-Entwicklung sieht Rösch deshalb die Möglichkeit, die Qualität der Programme zu verbessern und Software fehlerfrei herzustellen. Denn wenn Industrieprodukte praktisch zuverlässig gefertigt werden können, meint er, dann müsse das mit Software ebenso möglich sein. Für ihn als Praktiker zählt als "Beweis", dass Software richtig funktioniert, nicht eine im wissenschaftlichen Elfenbeinturm erdachte Methode, sondern einzig und allein der Kunde.

Wann sind Programme fehlerfrei?

Auf die Frage "Wann ist ein Programm fehlerfrei?" gibt Rösch deshalb die ganz pragmatische Antwort: "Wenn Software nicht das tut, was sie tun soll." Für ihn legt der Kunde fest, was die Software tun soll und dieser definiert auch die Prüfbedingungen. Basis des - ebenfalls automatisierten - Software-Checks sind dabei die Richtlinien nach ISO 9000, Teil 3.

Die Garantie der Fehlerfreiheit bezieht sich damit ausschließlich darauf, dass das Programm sich den Wünschen des Kunden gemäß verhält. Das heißt nicht, dass das Programm tatsächlich fehlerfrei ist. Es können etwa Fehler enthalten sein, die der Kunde nicht bemerkt, weil es für diese Zwecke, in denen sich der Fehler bemerkbar machen würde, gar nicht eingesetzt wird.

Software vom Fließband

Dem Kunden zu garantieren, dass die entwickelte Software seine Belange fehlerfrei erfüllt und im Fehlerfall zumindest einen Teil der Entwicklungskosten zurück zu zahlen, traut sich deshalb bislang kein Software-Unternehmen. Mit Software-Robotern glaubt Rösch, dass dies machbar ist. Mit ihnen will er die Komplexität der Software-Erstellung in den Griff bekommen und für eine Entkopplung von fachlichen und technischen Code-Teilen sorgen. Mit Hilfe dieser Roboter soll die Software-Branche in punkto Qualitätskontrolle und Fertigungsautomation auf den Stand gebracht werden, wie er in anderen Industriezweigen üblich ist. So wie heute Autos, Möbel, Geschirr oder andere Industrieprodukte am Fliessband produziert werden, soll in Bälde Software ein Fliessband-Produkt werden. Rösch vollzieht einfach die Lernschritte nach, die in der mechanischen Fertigung etwa von Industriegütern aus den letzten 200 Jahren bekannt sind. Das Erfolgsrezept lautet hier wie dort, dass eine Gliederung einer Aufgabe in überschaubare Teile erfolgen muss:

Drei Millionen Zeilen Code pro Stunde

Der Ablauf eines Software-Projektes bei Rösch Consulting unterscheidet sich dann auch deutlich von der bisherigen Vorgehensweise. Das ausfälligste Merkmal ist das vollständige Fehlen der Projektphase, in der bisher die individuellen Programme geschrieben wurden. Diese Arbeit wird komplett von Software-Robotern erledigt (der Begriff wurde von der Firma im übrigen geschützt). Software-Roboter sind allerdings nicht reine Code-Generatoren. Die gibt es schon länger. Vielmehr greifen sie bereits in der früheren Design-Phase ein, bei der es darum geht, Regeln zu spezifizieren, nach denen die Programmierer arbeiten und die bislang per Hand eingearbeitet werden mussten.

Immerhin erzeugen die Roboter drei Millionen Zeilen Code pro Stunde und sollen 95% der Programmierarbeit erledigten. Nur fünf Prozent müssen noch von Hand programmiert werden. Noch sind die Roboter zugeschnitten auf bestimmte Projekte, wie etwa beim Versicherungsunternehmen Signal Iduna oder dem Sparkassen-Rechenzentrum bei SIS West. Bei DePFa IT Services AG in Mainz wird derzeit eine Software-Roboter-Umgebung aufgebaut und für den produktiven Einsatz vorbereitet. Langfristig sollen die Software-Roboter jedoch unabhängig von spezifischen Anwendungen zum Massenprodukt weiterentwickelt werden. Einfache Varianten sollen dann im Internet dem breiten Publikum kostenlos zur Verfügung gestellt werden.

Klassische- und Roboter-Programmierung

Kern des Ansatzes für Software Roboter ist der sogenannte RC-Generator. Er beruht auf objektorientierter Software-Technik und sorgt für die Trennung von fachlichem und inhaltlichem Wissen. Die beiden Kompetenz- und Verantwortungsbereiche "Betriebliche, das heißt fachliche Ablauflogik und Verarbeitungsregeln" und "Technische Software-Architektur" sollen so in getrennte Hände gelegt werden.

Beide Verantwortungsbereiche gewinnen hierdurch freie Hand für den Aufbau von hochspezialisiertem Wissen, das ohne Störungen konstruiert, gepflegt und zur Anwendung gebracht werden kann. Die Verbindung der Arbeitsergebnisse der beiden Gruppen - der fachlichen und der technischen Software-Entwickler - zu funktionierendem Anwendungscode erfolgt vollständig automatisiert. Hierdurch wird zum einen Zeit gewonnen und zum anderen können Fehlerquellen ausgeschaltet werden.

Eigenschaften der RC-Generatoren

Im einzelnen hat der RC-Generator folgende Merkmale:

Er generiert über 95% des gesamten Codes für ein Projekt. Dies reduziert die Laufzeit von Projekten. Dies geschieht innerhalb von wenigen Minuten oder Sekunden. Zudem soll der Code sehr effizient und schnell sein.

Der RC-Generator fügt fachlichen und technischen Code erst zum Zeitpunkt der Generierung zusammen. Deshalb können fachliche Anwendungsentwickler und technische Software-Architekten parallel zueinander arbeiten und bis zum letzten Augenblick vor einem Generierungslauf noch Änderungen vornehmen.

RC-Generatoren sind sprach- und plattformunabhängig und können so theoretisch für jede Programmiersprache und jede Plattform, von Mainframes bis zu PCs, eingesetzt werden.

Der RC-Generator erzeugt Text-Dateien. Deshalb kann er zur Erzeugung von beliebigen Texten eingesetzt werden. Seinen größten Nutzen entwickelt er aber für generierungsfähige objektorientierte Software-Architekturen. Er arbeitet architekturgetrieben, nicht OOA-getrieben. Auch wenn der RC-Generator OOA-Werkzeuge benutzt, wird er aber nicht durch sie eingeschränkt. Der RC-Generator kann so auch für die Entwicklung von Software-Komponenten, für DCOM-basierte Architekturen, und für die Enterprise Java Beans eingesetzt werden.

Futter für Software-Roboter

Bei einem Projekteinsatz benötigt der RC-Generator folgende Eingaben:

Ein OOA-Modell, ergänzt um OOD- und Implementierungsinformationen. Fachlichen Code für die individuellen Operationen der Objektklassen sowie eine generierungsfähig aufbereitete Software-Architektur.

Das OOA-Modell wird zum Beispiel in UML erstellt (weitere Informationen zum Thema UML finden Sie hier). Hierfür können gängige OOA-Werkzeuge benutzt werden. Einzige Voraussetzung: Ihr Inhalt kann, vorzugsweise in XMI exportiert werden.

Die OOD- und Implementierungsinformationen umfassen zum Beispiel:

Hieraus kann schon fast der gesamte Code für eine Anwendung generiert werden, wie etwa das Anlegen und Löschen von Objekten, das Setzen und Lesen von Attributen oder das Navigieren zwischen Objekten und Beziehungen. Zusätzlich wird der gesamte technische Code erzeugt, der zum Beispiel Objektdaten aus der Datenbank holt oder die Kommunikation zwischen Client- und Server-Maschinen erledigt.

Lediglich der Code für die individuellen Operationen der Objekte wie den Umsatz eines Kunden berechnen oder Tilgungsplan für ein Darlehen erstellen muss von den fachlichen Anwendungsentwicklern in der Programmiersprache der Implementierung geschrieben werden.

Die dritte und letzte Eingabe für den RC-Generator stammt von den technisch orientierten Entwicklern der Architekturgruppe: die generierungsfähig aufbereitete objektorientierte Software-Architektur. Sie besteht in der Regel aus zirka 30 bis 50 Stanzformen, die für die Code-Generierung und ihre Steuerung verwendet werden.

Arbeitsweise des RC-Generators

Aus den beschriebenen Eingaben erzeugt der RC-Generator in einem einzigen Generierungsschritt den kompletten Anwendungscode für ein Projekt. Der erzeugte Anwendungscode wird anschließend von den jeweils geeigneten Systemwerkzeugen, wie Compilern und Datenbank-Hilfsprogrammen, in eine ausführbare Form gebracht.

Zuerst werden die OOA-Informationen aus dem OOA-Modell ausgelesen und in den OOA-Bereich eines temporären Repositories eingestellt.

Das Repository enthält außer dem OOA-Bereich noch die Bereiche OOD und Implementierung. Der Implementierungs-Bereich ist wiederum aufgeteilt in die verschiedenen Bereiche, für die Code generiert werden soll.

Für ein großes deutsches Versicherungsunternehmen, das den RC-Generator einsetzt, wurde beispielsweise folgende Repository-Struktur gewählt:

Im weiteren Verlauf der Generierung werden die im Repository-Code hinterlegten Regeln für das objektorientierte Design und die Implementierung angewendet und die entsprechenden Bereiche des temporären Repositories werden entsprechend den hinterlegten Regeln gefüllt. Die Regeln des Repositories sind in Java codiert und legen zum Beispiel fest, wie Beziehungen zwischen Objekten implementiert werden und welche Namenskonventionen für die generierten Source-Dateien gelten sollen.

Nach Abschluss dieses Teils der Generierung enthält das Repository alle Informationen, die für den nächsten Schritt, die abschließende Code-Generierung erforderlich sind.

Im letzten Schritt der Generierung arbeitet der RC-Generator wie ein computer-gesteuerter Industrie-Roboter. Die Elemente der generierungsfähig aufbereiteten objektorientierten Software-Architektur werden - wie in einer richtigen Stanzmaschine - der Reihe nach als Stanzformen eingespannt und alle Sourcen, die mit Hilfe der gerade eingespannten Stanzform erzeugt werden können, werden generiert. Hierbei greift der RC-Generator bei jedem einzelnen Stanzvorgang auf die im Repository hinterlegten Informationen zurück und bindet den fachlichen Code für die individuellen Operationen der Objektklassen an den richtigen Stellen ein. Als Ergebnis einer Generierung liegt der gesamte Anwendungscode des Projekts vor.

Ausblick

Röschs Software-Roboter werden zur Zeit noch als Dienstleistungsangebot seiner Firma für Kunden individuell aufgebaut und angepasst. Für 2001 ist die Produktfreigabe für universell einsetzbare Versionen der Software-Roboter vorgesehen. Die Preise liegen noch nicht fest, eine "Schnupper-Version" für die Erstellung einfacher Informationssysteme soll jedoch kostenfrei im Internet bereit stehen.

Ob die Roboter die hoch gesetzten Ziele tatsächlich erfüllen, wird sich zeigen. Glaubt man den Berichten des Unternehmens, so waren die Verantwortlichen bei den bislang durchgeführten Projekten durchweg zufrieden. Dr. Bernd Neumann von der Depfa IT Services AG in Main etwa realisierte mit der Rösch-Technologie ein vollständig neues IT-System für 10.000 Unternehmen der Immobilienwirtschaft mit 250.000 Endsystemen und einer halben Million Anwendern. "Ich arbeite seit über 30 Jahren in der Datenverarbeitung. Ich habe zunächst selbst nicht geglaubt, dass so etwas möglich ist. Kosten und Zeit werden damit mindestens um die Hälfte reduziert", lobt Neumann den Roboter-Ansatz.

Akademische Computerexperten andererseits sind skeptischer und beurteilen Röschs Software-Roboter als weit weniger innovativ als diese dargestellt werden. Für Manfred Broy beispielsweise, Informatikprofessor an der TU München am Lehrstuhl Software & Systems Engineering, sind solche Ansätze nur alter Wein in neuen Schläuchen. Insbesondere, so Broy, würden solche Software-Roboter bestimmt keine Fehlerfreiheit garantieren. Broy: "Der benötigte Input für die Software-Roboter ist der springende Punkt. Aus grundlegenden Erwägungen kann ein Software-Roboter höchstens eine formalisierte problemorientierte Beschreibung in eine ablauforientierte Beschreibung (Programm) umsetzen. Ist die Spezifikation falsch, ist es auch das Resultat. Im Endeffekt wird nur auf einer höheren Ebene programmiert - das ist nichts neues."

Rösch ist dennoch von seinen Robotern überzeugt. Setzt sich die Automatisierung der Software-Produktion durch, erwartet Rösch gewaltige Auswirkungen auf die Software-Industrie: Die Softwarepreise werden auf 10 Prozent der heutigen Kosten sinken, eine Software-Komponenten-Industrie wird entstehen und ein Konzentrationsprozess einsetzen. Dass Rösch von der Initiative der Bundesregierung, mit der Green Card ausländische Programmierer anzulocken nicht viel hält, überrascht nicht. Denn die eigentlichen Programmiertätigkeiten, meint Rösch, können Roboter schneller, billiger und besser erledigen. (fkh)