Ein Mikrocomputer ist nach landläufiger Vorstellung ein für wenige hundert Mark erhältlicher Rechner, mit dem man erstaunliche Basic-Programme schreiben oder zumindest Telespiele betreiben kann. Demnach findet Softwareentwicklung hauptsächlich abends und am Küchentisch statt und enthält als wesentliches Element das Finden von Verfahren zum Knacken der Herstellerschutzcodes, um damit die Zahl der illegal kopierten Programme zu erhöhen. Ergraute Großrechnerverantwortliche drohen indes ihren Mitarbeitern mit Disziplinarmaßnahmen, wenn sie Anzeichen aufkommender Mikrosucht bei ihnen feststellen.
Aufgeklärtere DV-Gewaltige halten den Mikro für einen überteuerten Terminalersatz, mit dem man sich alberne Fragen von Endbenutzern vom Hals halten und diese mit unnützen Planungsspielen á la XY-Calc beschäftigen kann. Dann kostet der Rechenzwerg schon an die 10000 Mark und die Softwareentwicklung besteht vor allem darin, geeignete Tabellenkalkulationsprogramme aufzutreiben und eventuell ein Transferprogramm zum Übersenden von Datenbankauszügen aus dem Großrechner an den Mikro selbst zu stricken.
Von beiden Arten von Mikros soll hier nicht die Rede sein, auch nicht von jenen - vor allem in Herstelleranzeigen existierenden - Wunderwerken, die sowieso alle DV-Aufgaben besser, schneller und kostengünstiger erledigen, als irgendein Produkt des Großcomputer-Establishments.
Die heute üblichen Maßzahlen sind 64 KB virtueller Adreßraum, bis zu 1MB realer Hauptspeicher, bis zu 100 MB Externspeicher und eine Summendatenrate von etwa 1 MB/s zwischen den beiden Speicherkomponenten. Derzeitige Kaufpreise für diese Systeme liegen zwischen 10000 Mark und 100000 Mark, obwohl der Kaufpreis oder die Busarchitektur vom Softwarestandpunkt aus kein gutes Kriterium für eine Einteilung in Mikro-, Mini- und Großcomputer ist.
Organisatorisches Umfeld des MC-Software-Einsatzes
Der Einsatzzweck dieser Anlagen variiert. Um als Anwender in nennenswertem Umfang Softwareentwicklung treiben zu müssen, wird man sie in Verbindung mit Individualprogrammen einsetzen, oder als Wiederverkäufer (VAR) Mikros mit eigenen Anwendungsprogrammen vertreiben. Der Mikro ist hier Teil eines Gesamtsystems; so bei technischen Anwendungen, in denen er steuerndes oder zumindest protokollierendes Element einer Meßapparatur wird (embedded systems) oder für Großanwender, die Mikros gezielt im Rahmen einer einheitlichen Politik zur Übernahme dedizierter Anwendungen in Fachabteilungen einsetzen und hierfür selbst Software entwickeln.
In allen genannten Fällen hat es der Benutzer zunächst mit der üblichen Problematik der Softwareentwicklung zu tun, nämlich robuste, wartbare, änderbare und praktisch benutzbare Programme für andere zu schreiben. Der Unterschied zur Entwicklung an Großsystemen resultiert dabei einmal aus den oben genannten Limitierungen und zum zweiten aus dem so ganz anderen organisatorischen Umfeld des MC-Software Einsatzes.
Sehen wir von den Hardwarebegrenzungen einmal ab, so kann sich der Softwareentwickler für Mikros nicht darauf verlassen, daß - für eine Rechenzentrumsumgebung selbstverständliche - organisatorische Maßnahmen sein Produkt betrieblich abstützen.
Damit scheiden sofort eine ganze Reihe von Softwarekonzepten aus, die von einer wohlorganisierten Wechselwirkung manueller (beziehungsweise durch einen Operateur gesteuerter) und Anwender-gesteuerter Verfahren ausgehen. Im Mikrobereich ist der Anwender Rechenzentrumsleiter, Systemanalytiker, Operateur und manchmal auch Programmierer in einer Person, so daß Mikrocomputer-Software besonders robust sein muß.
Diese Robustheit läßt sich umso leichter erreichen, je einfacher die von dem betreffenden System ausgeführte Funktion und je geringer dessen Wechselwirkung mit anderen Systemen ist. Schnittstellen sind unbedingt in ihrem Umfang zu minimieren und in ihrer Wirkung durch defensiven Code zu kontrollieren, was konkret ganz klar für eine Wechselwirkung auf Prozeß-Ebene über Dateien, Nachrichten-orientierte Vermittlung (über Send-Receive-Direktiven) oder Pseudodateien (zum Beispiel Unix Pipes) und gegen die bei älteren Programmiersprachen üblichen riesigen gemeinsamen Datenbereiche (Common areas) spricht. Sicher ist dieses Prinzip des Informations- Verbergens auch im Großsystembereich bekannt. Es ist in seiner Handhabung für Mikrocomputer nur deshalb schwieriger, weil die hier verfügbare Hardware-Leistung im Vergleich zum Software-Aufwand immer noch gering ist und man sich davor hüten muß, den großen Vorteil der Mikros gegenüber Großsystemen, nämlich konstante Bildschirm Antwortzeiten und schnelles reagieren im Dialog beziehungsweise bei Unterbrechung durch einen buchhalterischen , alles abprüfen und verkapseln wollenden Programmierstil zu verspielen.
Richtige Modularisierung und Schnittstellenprüfung wird durch geeignete Werkzeuge erleichtert, die einen Teil der notwendigen Prüfungen während des Programmentwicklungsprozesses und nicht zur Laufzeit ausführen. Hierzu gehören auf jeden Fall geeignete, Schnittstellenbedingungen zur Kompilationszeit überprüfende Programmiersprachen. Vielleicht ist dies der Grund, warum sich modernere prozedurale Sprachen wie Pascal oder die Pascal-Nachfolgersprachen Modula, C und Ada im professionellen Mikrobereich eher durchgesetzt haben, als im Heimcomputer- oder Großcomputerbereich.
Softwareentwicklung ohne Steinzeitwerkzeuge
Pascal und Modula führen Prüfungen auf Typverträglichkeit zwischen Operanden beziehungsweise Parametern und Argumenten von Prozeduren und Prozeduraufrufen zur Kompilatioszeit durch; bei C läßt sich das gleiche durch einen geeigneten Programmierstil (der durch Prüfwerkzeuge gefördert wird) erreichen. Von der Pascal-Nachfolgesprache Ada ist in diesem Zusammenhang eine weitere Verbesserung zu erwarten, weil Ada das unauthorisierte Verwenden von Datentypen besonders erschwert und die Trennung von Definition und Implementierung einer Prozedur besonders fördert (ähnliches leistet auch Modula). Natürlich kann hier entgegengehalten werden, daß Ada mit seiner anspruchsvollen Programmierumgebung APSE nicht gerade ein Kandidat für ein Softwareentwicklungssystem auf einem Arbeitsplatzcomputer ist. Hierzu ist aber Folgendes zu sagen: Einige Computerhersteller (zum Beispiel Data General, Digital und in gewissem Umfang auch IBM) bieten zueinander auf Betriebssystemebene kompatible Computerfamilien, die in den Mikrobereich hineinreichen. Hier ist Programmentwicklung auf einer größeren Anlage mit Portieren der Anwendung auf die Zielmaschine besonders leicht. Ähnliches gilt auch für Computer auf der Basis des Motorola MC 68000. Fallende Hardwarepreise besonders im Peripheriebereich und das Vordringen echter 32-Bit-Mikros werden dazu führen, daß auch die Systementwicklung auf der Zielmaschine immer mehr in den Bereich des Möglichen rückt. Das Haupthindernis scheint hier nicht in dem Verfügbarmachen einer bestimmten Programmiersprache zu liegen, sondern im Vorhandensein der gesamten erforderlichen Infrastruktur inklusive Peripherie und Datenhaltung.
Programmiersprachen sind nämlich nur eines von mehreren notwendigen Entwicklungswerkzeugen. Systeme zur Textverarbeitung und Dokumentenhaltung, Bibliothekssysteme für die Quell-, Objekt- und Lademodulverwaltung, Textmanager beziehungsweise Prüfwerkzeuge zur Qualitätssicherung (zum Beispiel Testmonitore zur Prüfung der Erzielung eines bestimmten Überdeckungsgrades für Tests) sind für jede Systementwicklung sehr nützlich, die über Adhoc- und Trivialprogrammierung hinausgeht, also - praktisch gesprochen - einen Umfang von einigen Tausend Zeilen Pascal oder C überschreitet. Hier wird der typische Mikro-Softwareentwickler wohl noch einige Zeit warten müssen, bis ihm integrierte Entwicklungsumgebungen, wie sie für den Superminibereich jetzt üblich werden (zum Beispiel CMS, MMS und DTM auf Digitals VAX-Anlagen), in industrieller Qualität angeboten werden.
Dies soll jedoch nicht heißen, daß Softwareentwicklung außerhalb derartiger Rechnerarchitekturen mit Steinzeitwerkzeugen wie zeilenorientierten Editiersystemen, einstufigen und voneinander ungeschützten Dateisystemen und Basic- beziehungsweise P-Code-Interpretern zur Codegenerierung durchgeführt werden muß. Es gibt auch im 16- Bit- Bereich (und nicht nur für das Betriebssystem Unix) zahlreiche Werkzeuge, die zumindest ansatzweise ähnliches leisten wie oben gefordert und die einem Praxistest durchaus standhalten. Das Problem liegt hier in der Integration und in der Verbindung zu den Methoden der Softwareentwicklung.
Hier muß man besonders auf Beschränkungen der Systemumgebung Rücksicht nehmen, die im unteren und mittleren Mikrobereich (16-Bit-Architektur, eventuell Disketten als einziger Massenspeicher) heute noch bestehen. Sie erzwingen unter Umständen ein anderes Vorgehen bei der Systemmodularisierung, als es nach ausschließlich methodenorientierten Gesichtspunkten (zum Beispiel aufgrund der Analyse des Datenflusses) notwendig wäre. Es ist deshalb wenig sinnvoll, Mikro- Anwendungen zunächst für ein System mit großem Adreßraum (zum Beispiel für ein virtuelles 32-Bit-System) zu entwickeln und dann auf die kleinere Anlage zu portieren. Vielmehr müssen die Beschränkungen der Zielmaschine von vornherein bekannt sein und in der Auswahl der für das System grundlegenden Datenstrukturen berücksichtigt werden. Sehr günstig ist es, wenn man die Beschränkungen des Zielsystems auf dem unter Umständen konfortableren Entwicklungssystem simulieren oder zumindest überprüfen kann. Aus diesen Zwängen resultiert eine Überlegenheit gewisser Entwicklungsmethoden wie etwa jenen, die primär die Datenstrukturen des Zielsystems betrachten, gegenüber anderen (zum Beispiel reiner schrittweiser Verfeinerung oder reiner Datenflußorientierung).
Wurde bisher das Gebiet der konventionellen Systementwicklung betrachtet, so sei ein Ausblick auf die mögliche Einführung von "Künstliche Intelligenz"-Systemen (KI) in den Mikrobereich aus Usersicht gestattet. Für die oft naiven Anwender von Mikrocomputersoftware wäre der Einsatz von KI-Interface-Systemen zu den eigentlichen Anwendungsprogrammen äußerst nützlich.
Damit würde das in diesem Bereich so wichtige Gebiet der Benutzerführung endlich von der Alternative befreit, dem User entweder eine oft noch einfallslose Menüführung oder die (für ihn vielleicht zu große) Freiheit mächtiger prozeduraler Kommandosprachen bieten zu müssen. Ein auf natürlich-sprachlicher Eingabe basierender Dialog zum Finden der Lösung in einer konkreten Anwendungsumgebung könnte dem naiven Benutzer helfen, ohne den Erfahrenen durch eine Folge von Haupt- und Untermenüs oder - noch schlimmer - umständliche Abfragefolgen zu frustrieren. In näherer Zukunft scheinen vor allem diese hybriden Systeme (KI-Interface zum konventionellen Anwendungssystem) die größte Chance auf rasche Einführung in den Mikrocomputerbereich zu haben. Mit fortschreitender technischer Entwicklung könnten für andere als die heute typischen Anwendungen auch reine KI-Systeme auf entsprechender Hardware, wie zum Beispiel als geschlossene Expertensysteme für bestimmte Anwendungsklassen in den Mikromarkt eindringen.
*Bernd Gliss ist EDV-Leiter in Stuttgart.