previous next Title Contents Index

7. Die Software-Technologie des Inter-Aktors


@:INTERACTOR

7.1. Einführung

Im folgenden Artikel wird eine Software-Technologie beschrieben, die von Grund auf in einer interaktiven Metapher, dem Inter-Aktor realisiert worden ist. Diese Technologie basiert auf einer Strategie der optimalen Abstimmung des Software-Gesamt-Systems auf die Inter-Aktion mit dem Benutzer. Das System ist in erster Linie dafür gedacht, die konzeptuellen und intellektuellen Fähigkeiten des Benutzers zu unterstützen und nach Möglichkeit zu erweitern. Wesentlich hierbei ist die Möglichkeit der optimalen Einstellbarkeit des Inter-Aktors auf den Benutzer, und auf unterschiedliche Ebenen von Erfahrung.
Ein Hauptmerkmal des Inter-Aktor-Prinzips ist eine neue Sichtweise der Software: Die Gegebenheiten in einem Computer, die wir konventionell als Programme, Module, Prozeduren, und Daten bezeichnen, werden als eine Versammlung von Quasi-Wesenheiten betrachtet, nämlich Inter-Aktoren, von denen jeder eine "Rolle" spielt, und zur Ausführung dieser Rolle ein "Skript" erhält. Diese Betrachtungsweise hat den Vorteil, daß nun eine Metapher zur Verfügung steht, die der Mehrheit der Menschen unserer Zivilisation einen greifbaren Einstieg in die Welt des Computers bietet, die nicht nur die Benutzung der Funktionen umfaßt sondern auch ihre Programmierung. Der Ansatz weist Ähnlichkeiten mit neueren Ansätzen der visuellen Programmierung auf, setzt aber auf eine eigene Methodik. Die Absicht ist dieselbe: Es soll dem nicht-versierten Benutzer des Computers ermöglicht werden, nicht-triviale Anwendungen selbstständig zu erstellen.

7.1.1. GUI-Systeme sind nicht automatisch optimal interaktiv

Window- und Maus-orientierte (GUI-) Software-Systeme haben wesentliche Verbesserungen der ergonomischen Eigenschaften der Software gebracht. Wie bei jeder neuen Entwicklung muß sich erst im Einsatz über mehrere Release-Generationen hinweg im fortlaufenden Gebrauch herauskristallisieren, welche Eigenschaften der heutigen GUI-Software sich als optimal für die Benutzerproduktivität erweisen, und welche noch weiterer Überarbeitung bedürfen.
So stellt man leider fest, daß mit dem Wechsel des Benutzer-Paradigmas von der Kommandozeilen-Schnittstelle zur GUI in vielen Fällen sehr praktische Eigenschaften der alten Systeme verlorengegangen sind: Die GUI-Technologie in der Nachfolge des Macintosh-Interfaces ist im Wesentlichen eine Verbesserung für Ad-Hoc Arbeiten und für unbedarfte Benutzer vorteilhafter als für Experten. Ihre Nachteile zeigen sich bei oft vorkommender Wiederholung von gleichen Arbeitsabläufen: Wenn hier keine leistungsfähige Makro-Methode vorhanden ist, wird die Maus-orientierte Arbeitsweise schnell zur Beschäftigungstherapie. Kommandozeilen-Systeme boten oft die Möglichkeit, über Skript-Dateien das System im batch-Modus zu steuern, was man heute in vielen GUI-Systemen vermißt, oder nur noch wesentlich umständlicher durchführen kann. Weiterhin machen GUI's oft den Eindruck, daß sie auf eine alte, nicht-interaktive Denkweise "aufgepfropft" sind, und nicht komplett durchdacht worden sind.

7.1.2. Der Begriff des Inter-Aktors

Der Begriff leitet sich von Inter-Aktor (lat. agere) ab: Der Handelnde, der (Be-) Wirkende. Actor (engl.) Ein Schauspieler. Einer, der eine bestimmte Charakteristik verkörpert, der eine begrenzte Möglichkeit zum autonomen Auftreten hat, dessen Verhalten im Kontext seines Stücks von einem Skript (seiner Rolle) definiert wird. Der Inter-Aktor ist optimal darauf abgestimmt, mit dem Operator zu interagieren. Im folgenden Text wird zur Abkürzung das Wort Inter-Aktor verwendet. In seiner software-technischen Bedeutung ist ein Inter-Aktor ein autonomes Programm-Modul mit objektartigen Eigenschaften wie Methoden, eigener Datenverwaltung, und einer eigenen interaktiven Benutzerschnittstelle. Inter-Aktor-Orientierte Programmierung (IAOP) ist eine Software-Methode, in der Software-Funktionalität durch Inter-Aktion von Inter-Aktoren definiert und implementiert wird.
Der Operator: In der Sprechweise der IAOP ist der Operator die Person, die den menschlichen Kommunikationspartner des Inter-Aktors darstellt.

7.1.3. Der Inter-Aktor als Selbst-Expertensystem

Der Inter-Aktor muß dem Benutzer optimale Auskunft über sich, seine Möglichkeiten, und seinen inneren Zustand geben können. Er kann daher als ein Experten-System über sich selbst angesehen werden. Er enthält dafür Mechanismen zur leicht zugänglichen Darstellung seiner Fähigkeiten, die bis zu einer eingebauten Teaching Funktion oder Courseware reichen können, mit der ein neuer Benutzer sich vom Kenntnisstand Null aus ohne Anleitung eines menschlichen Instruktors einarbeiten kann.

7.1.4. Programmierung als Kommunikation

Ein wesentlicher Faktor, der in der IAOP den Hauptaspekt der Programmierung ausmacht, ist die Kommunikation der Inter-Aktoren miteinander. Dies kann man als das Paradigma der IAOP bezeichnen. Dieses Konzept ist zwar mit der Objektorientierten Programmierung schon bekannt, aber wie die augenblickliche Entwicklung hin zu compilierenden Sprachen wie C++ zeigt, wird der Mensch aus dieser Kommunikation wieder ausgeschlossen. Vom Standpunkt einer Methodik, wie sie in Smalltalk initiiert wurde, ist das ein entscheidender Rückschritt. (Siehe auch: Inter-Aktoren und Objekt-Orientierte Programmierung)
Gravierend wird dieser Faktor, wenn man den Menschen als das schwächste Glied der Kette erkennt. Es wird hier wieder eine Barriere errichtet, die die Effizienz und Allgemein-Verständlichkeit der planmäßigen Interaktion mit dem Computer stark verringert. Es ist der Computerindustrie nicht damit gedient, daß Programmierung auf die exklusiven Zirkel der Software-Ingenieure beschränkt bleibt. Der wirkliche Nutzen der Computer wird erst dann voll ausgeschöpft, wenn jeder normal intelligente Mensch die Maschine auch für seine speziellen Wünsche anpassen und einrichten kann. Intuitive Software hängt auch nicht von komplexen und technisch aufwendigen graphischen Systemen ab. Die Grundfunktion der Software ist heute und wird noch so lange zeichenorientiert bleiben, wie Computer besser mit Zeichenketten als mit Pixelmustern arbeiten. Man muß hier Marketingüberlegungen und grundsätzlichere Fragen auseinanderhalten. Software ist vielleicht besser als "Dialog", oder "Skript", oder "Dramaturgie" allgemein verständlich und handlich zu machen.

7.1.5. Team-Arbeit: Inter-Aktoren und Programmierer

Das Hauptproblem heutiger Software ist ihre Komplexität. Die Aufgabe des modernen Software-Managements ist die optimale Verteilung der Komplexität auf die Mitglieder eines Software-Teams. Inter-Aktoren stellen eine ideale Methode dar, eine leicht handhabbare Komplexitäts-Abgrenzung von Software-Modulen zu erreichen. Bei der Definition von Software-Funktion in Inter-Aktoren ergibt sich auch eine natürliche Unterteilung in Arbeits-Schritte, die in einem Programmierteam leicht auf die Programmierer verteilt werden können. Da ein Inter-Aktor immer eine genormte interaktive Benutzer-Schnittstelle enthält, ist der Inspektions- und Verifikationsprozess eines solchen handlichen Moduls sehr einfach. Jede weitere Funktionalität sollte durch die Kommunikationsschnittstelle zwischen den Inter-Aktoren implementiert werden. Die alten Methoden der Shell-Programmierung unter Unix zeigen den Wert des Konzepts der Vereinfachung von Prozessen.

7.1.6. Die Metapher des Marionettentheaters

Es geht bei der Team-Arbeit im Inter-Aktor-Konzept darum, die Intentionen der Menschen, die das Team bilden, in der virtuellen Umgebung, in der sie zusammenarbeiten, programmtechnisch auszudrücken. Hier ist also ein Inter-Aktor eine tiefgreifende Einheit zwischen einem Menschen, der am Computer sitzt und einer programmierten Instanz, die ihn im Rahmen des virtuellen Teams vertritt. Eine gute Metapher scheint das Marionettentheater zu sein, bei dem ja auch für den Zuschauer nicht nur die Bewegung von Puppen zu sehen ist, sondern wo eine sehr tiefe emotionale Kommunikation zwischen dem - verborgen bleibenden - Puppenspieler, und seinem Publikum entsteht. Diese wird durch das Medium der Puppen nicht etwa vermindert, sondern hier stellt sich ein bemerkenswerter Effekt ein: Durch die Vermittlung (die mittelbare statt der unmittelbaren Kommunikation) kann sich das Spiel der menschlichen Emotionen sogar noch feiner und deutlicher auszeichnen. Dies ist unbedingt zu bedenken, wenn ein Kommunikationskanal mit eigenen Gesetzmäßigkeiten eingesetzt wird, wie es beim Computer der Fall ist.

7.1.7. Projekt Leibniz: Umfeld und Entstehung des Inter-Aktor-Konzepts

Das Inter-Aktor-Konzept ist ein Ergebnis der Arbeit im Projekt Leibniz. Die Zielsetzung dieses Projekts definiert sich wie folgt:
Erforschung von Software-Methoden zur Intelligenz-Verstärkung
Entwicklung von ergonomischer Software
Entwicklung von Human-Computer Interface-Sprachen, die auch zur Kommunikation zwischen Menschen dienen
Entwicklung von inkrementell erlernbaren Programmierschnittstellen für Anwendungsprogramme, die ohne externe Compilertools spezielle Anpassungen der Anwendungen vor Ort erlauben und von den Fach-Bearbeitern erzeugt werden können
Reduktion der Einarbeitungs-Schwelle bei Software-Systemen
Bereitstellung eines intuitiven Software-Kommunikationsmediums für Gruppenarbeit
Erstellung von Low-Cost Lösungen für benutzerfreundliche Software (Lauffähig auf Rechnern der PC-AT Klasse)
Multilingual über dynamisch austauschbare Sprachmodule
In diesem Projekt wurde das Inter-Aktor-orientierte LPL System (Leibniz Programming Language) entwickelt, das über eine eigene rapid-prototyping Programmiersprache LPL verfügt, und eine Benutzer-Shell besitzt, die LPL-Shell. Innerhalb dieser Shell sind die Inter-Aktoren vom Operator interaktiv aufrufbar und benutzbar. Diese Shell führt bestimmte Ideen, die in den alten Unix-Shells wie C-Shell und Bourne-Shell und der damit verbundenen Shell-Programmierung entwickelt wurden, weiter und bedient sich einer moderneren Philosophie des Benutzer-Interfaces mit Windowing, Hypertext[1], und kontextsensitiver Help-Funktion. Das LPL-System enthält ca. 100 Inter-Aktoren mit insgesamt ca. 10.000 Funktionen oder Methoden in 100.000 Zeilen Source Code und noch einmal soviel Kommentar und Dokumentation, insgesamt ca. 6 MByte Daten. Die Leistungsfähigkeit des Inter-Aktor-Konzepts läßt sich vielleicht daran ermessen, daß eine einzige Person diese große Datenmenge warten und bearbeiten kann.

7.2. Das Inter-Aktor-Prinzip und die Software-Industrie

7.2.1. Aktoren und die Low-Cost Lösung

Ein wesentlicher Entwicklungs-Aspekt des Leibniz Projekts ist die breite Verfügbarkeit des Systems. Es wurde darauf geachtet, daß es auf einem Standard-PC AT Modell lauffähig ist, dessen Anforderungen an die Hardware die heute am weitesten verbreitete Leistung von Maschinen im Büro-Textverarbeitungsbereich ist: 16 MHz 286, ASCII-Bildschirm 80*25, 1-2 MB RAM, 20 MB Platte. Eine Konfiguration also, wie sie in ca. 100 Millionen PC-Computern auf der ganzen Welt zur Verfügung steht. Das LPL-System arbeitet mit einem eigenen Windowing-System, welches lediglich 50 KBytes Code benötigt. Weiterhin ist es auf Rechnern ohne Betriebssystem einsetzbar (Standalone-System), z.B. auf Industrie-Rechnern und embedded Systems.
Der Aspekt der Low-Cost Lösung wird bei den heutigen window-orientierten Benutzeroberflächen meist an sehr untergeordneter Stelle behandelt. Pixel-Windowing-Systeme benötigen einen erheblich höheren technischen Aufwand bei Display und Prozessor als character-orientierte Systeme. Zwar sind 1000*1000 Pixel Bildschirme heute viel billiger als vor zehn Jahren, aber sie sind immer teurer als ASCII-Bildschirme, die z.B. mit einem Alpha-Window System arbeiten. Ein wesentlicher und oft übersehener Kostenfaktor bei Systemen mit Mega-Pixel Displays ist aber die Prozessor-und Busbelastung der Graphik, die bei AT-Bus Systemen recht merklich zu einer Verlangsamung des Systems führt.

7.2.2. Aktoren und die Rezession

Ein altes Sprichwort sagt: "Spare in der Not, da hast Du Zeit dazu." Die Rezession bietet eine ideale Gelegenheit, sich in Ruhe zu überlegen, wo bisher Ressourcen zu freigiebig eingesetzt worden sind, und wo man mit ein wenig Überlegung und etwas mehr Einsatz von Intelligenz erhebliche Gewinne an Effizienz und Kosteneinsparungen bekommen kann. Die Computerindustrie ist ein Lehrstück für freigiebige Ver(sch)wendung von Ressourcen. In der Gewöhnung an eine Verdoppelung der Leistungsfähigkeit der Hardware alle zwei Jahre sind so kleinliche Fragen wie die Effizienz von Programmen eher nebensächlich. Aber auch die Computerindustrie ist nicht abgekoppelt vom Rest der Weltwirtschaft. Das Leibniz-Projekt setzt auf eine eigene Software-Technologie: Den Tokenlisten-Interpreter [2]. Dieses Prinzip fördert die Wiederverwendung von Routinen und die sparsame Ausnutzung von Speicherplatz erheblich. Im Zuge einer Rezession kann eine solche Sparsamkeit, die zu normalen Zeiten vielleicht nicht so wichtig erscheint, einen erheblichen Unterschied machen.

7.2.3. Heutige Konzentrationstendenzen in der SW-Industrie

Eines der größten Probleme der heutigen mittelständischen Software-Industrie ist die ungeheure Komplexität und der damit verbundene finanzielle Aufwand zur Entwicklung einer auf moderner GUI-Technologie basierenden Software. Dies führt zu den heute sichtbaren Konzentrationserscheinungen auf wenige Großunternehmen, die die enormen Investitionen noch finanzieren können. Solche Unternehmen können dann allerdings nur noch Standard-Produkte erstellen, um in einem möglichst großen Abnehmermarkt ihre Kosten wieder zu amortisieren. Dies bedeutet aber, daß eine Kunden-Unterstützung vor Ort nicht mehr stattfindet. Das Ergebnis ist unbefriedigend: Zwar kann man mit Standard-Programmen 80 % der Aufgaben erledigen, aber die Anpassung an die restlichen 20 % gestaltet sich, wenn überhaupt möglich, sehr aufwendig und ineffizient.

7.2.4. Der Ansatz einer mittelständischen Software-Industrie


Das Inter-Aktor-Prinzip bietet den Lösungsansatz für die weitere Verbreitung einer heute in bestimmten Bereichen schon vorhandenen und erfolgreichen Methode der Software-Produktion. Heutige Datenbank-Systeme wie Oracle® oder DBase® besitzen Skript-Sprachen für eine interpretative Programmierung, und es hat sich eine ganze Zuliefer-Industrie für Spezial-Lösungen gebildet, die mit diesen Skript-Sprachen erstellt werden. Der Inter-Aktor ist eine Verallgemeinerung dieses Ansatzes. IAOP bietet die Möglichkeit, für jedes beliebige Anwendungsgebiet allgemeine Inter-Aktoren zu konstruieren, die eine hohe Flexibilität der Anpassung an spezielle Problemstellungen bieten. So kann man die Skriptsprachen und Hilfe-Systeme der obigen Datenbanksysteme auch als Ansätze für Datenbank-Aktoren bezeichnen. Genauso kann man Inter-Aktoren für Maschinensteuerung, für Chemische Analyse, für Materialprüfung, für Textverarbeitung, usw. erstellen. Da Inter-Aktorenskripte keine externen Compilertools benötigen, ist die Programmierung tendentiell eher für Fachleute des Anwendungsgebiets zugänglich. Die Software-Industrie wäre auf diese Weise wesentlich flexibler und in der Lage, besser auf die Belange des Endkunden (oder der Fachabteilung in Firmen) einzugehen, wenn anstelle der "Alleskönner"-Standardsoftware nun Standard-Aktoren hergestellt würden, die von einer mittelständischen Software-Industrie, also Software-OEMs (oder VARs, Value Added Resellers) an die Wünsche des Endkunden angepaßt würden.

7.2.5. Aktoren und SW-Wartung

IAOP hat keine Anforderungen an eine spezielle Implementationstechnik. So ist das riesige Feld des Re-Engineering und Retro-Fitting von bestehender Software für die Standards neuerer Software-Umgebungen angreifbar. Prinzipiell ist jede Software, die in Form von isolierbaren Modulen in .lib oder .obj -Format vorliegt, oder sich dahin umformen läßt, für den Einsatz in Inter-Aktoren geeignet. Auf diese Weise läßt sich ein Software-System auch schrittweise auf Inter-Aktoren-Technologie umstellen.

7.2.6. Zweistufige Programmierung durch Inter-Aktoren-Skripting

Die Aufgaben der konventionellen Programmierung werden durch das Inter-Aktoren-Skripting nicht hinfällig. Stattdessen wird eine strikte zwei-Stufen Trennung der Software-Produktion erreicht: Die System-Stufe, die wie bisher den Software-Ingenieuren vorbehalten ist, in der die geeigneten Inter-Aktoren für jede Anwendung konstruiert werden, und die Anwendungs-Stufe, die nun den software-technisch weniger engagierten Fachleuten der Applikation vorbehalten ist. Dies bringt einige sehr gravierende ökonomische Vorteile: Erstens ist die semantische Lücke zwischen Anwendern eines Systems und den Software-Experten wesentlich verringert, da die wesentliche Implementations-Arbeit der Anwendung nun von Experten ihres Fachgebiets gemacht werden kann. Zweitens ist die Komplexität eines speziellen Applikations-Aktors, der in ein existierendes Inter-Aktoren-System mit all seinen vorhandenen Dienstleistungen eingebunden werden kann, eine leicht zu kalkulierende Aufgabe. Hier ist auch die Möglichkeit gegeben, in erster Näherung einen Protoyp-Aktor zu erstellen, der in der Geschwindigkeit noch nicht optimiert ist, der aber eine weitgehende Parallelisierung der Entwicklungsarbeiten im Systembereich und im Anwendungsbereich erlaubt. Dadurch lassen sich entscheidende Verbesserungen im "time-to-market" Bereich erzielen. Durch breiten Einsatz von Inter-Aktoren läßt sich ein besseres produktives Gleichgewicht zwischen den verschiedenen Software-Techniken von Compiler-generierten monolithischen Programmen, Shell-Programmierung und Skript-Konfigurierung von Anwendungs-Programmen erreichen.

7.3. Aktoren und Software-Engineering

7.3.1. Bottom-Up versus Top-Down

Eine wichtige Frage ist der methodische Bezug von IAOP zu bekannten Methoden, die die Verbesserung der Software-Produktiviät zum Ziel haben. Neben der weiter unten behandelten Objekt-orientierten Programmierung ist hier vor allem das Software-Engineering (SWE) zu nennen. Man kann einen sehr einfachen Vergleich führen: SWE ist eine Top-Down Methode während IAOP bottom-up orientiert ist. Auf diese Weise läßt sich in einem Projekt mit beiden Herangehensweisen arbeiten. SWE erlaubt es sehr gut, die Strukturen eines Systems mit einer hierarchischen (aristotelischen) Methode abzubilden. Die Schwäche des SWE zeigt sich, wenn eine einmal erstellte Struktur modifiziert werden soll. Die semantischen Abhängigkeiten von Funktionen, die in verschiedenen Zweigen der Struktur-Hierarchie abgebildet sind, lassen es nicht zu, durch einfaches graphisches Editieren eines Strukturbaums neue Kombinationen zu erstellen. Der Strukturbaum muß per Hand aufgelöst werden und neu wieder aufgebaut werden.

7.3.2. Die Problematik von tiefgreifenden Struktur-Änderungen

Eine wesentliche Eigenschaft von wiederverwendbaren Software-Modulen ist, daß ihr Gebrauch in vielen verschiedenen, neuen und nicht vorher geplanten Kontexten über die Zeit tiefgreifende Modifikationen der Module erfordert. Die Entwicklung eines solchen Systems über mehrere Jahre hat, wie im LPL-System beobachtet, alle Erscheinungen einer Evolution, wie man sie sich in der Natur vorstellt. Code-Teile "wandern" in der Struktur des Systems von einem Ort zum anderen, verändern völlig ihr Aussehen, oder werden durch gänzlich andere Strukturen erstetzt. SWE-Ansätze sind bisher auf eine solche kontinuierliche Evolution des Systems nicht eingerichtet. Im SWE ist es der optimale Anwendungsfall, wenn die Struktur eines Systems schon bekannt ist (so. z.B. die hundertundzweiunddreißigste Version einer Finanzbuchhaltung), und keine gravierenden Änderungen dieser Struktur zu erwarten sind. Solche Änderungen sind dann zwar möglich, aber ungeheuer aufwendig. Die IAOP-Methode ist gerade auf solche strukturellen Modifikationen spezialisiert. In der Entwicklung des LPL-Systems wurde jede Codezeile mehrere Male umgeschrieben und die Struktur des Gesamtsystems ca. fünfmal total umgestellt.

7.3.3. Die Problematik der Code-Generierung

Eine weitere, noch nicht besonders befriedigende Seite des SWE ist die automatische Code-Generierung. Wenn überhaupt vorhanden, dann ist sie nicht sehr effizient. Das Hauptproblem ist die Faktorisierung, also das Auffinden von gemeinsamen Code-Teilen (Modulen), die in den verschiedensten Teilen des erstellten Systems vorkommen können, und deren optimale Bearbeitung ein nach dem hierarchischen Schema Top-Down vorgehendes SWE-System überfordert. IAOP ist ebenfalls genau auf diesen Aspekt optimiert. Ein Inter-Aktor stellt ein Medium dar, in dem die optimale Faktorisierung von Code ermittelt werden kann. Dies ist im wesentlichen eine Frage der Flexibilität und der Erfahrung des Inter-Aktoren-Designers, da sich hier kaum formale Methoden einsetzen lassen.

7.4. Aktoren und Objekt-Orientierte Programmierung

Die Entwicklung der Objekt-Orientierten Programmiersysteme (OOP) nimmt mit der sich abzeichnenden Marktdominanz von C++ eine Richtung, die zwar eine Verbesserung der Software-Produktivität mit sich bringen wird, aber in anderen Bereichen Tendenzen, die zur jetzigen Situation der Software-Krise geführt haben, beibehalten und weiter verschärfen. Mit C++ wird eine Sprache zum dominierenden Faktor, die an ihrer Erblast schwer zu tragen hat. Dadurch, daß C++ die Sprache C enthält, ist es jederzeit möglich, auf die alte prozedurale Weise zu programmieren, und den objektorientierten Rahmen zu sprengen. Damit wird C++ zu einem sehr problematischen und schwierig zu beherrschenden OO-System. Es wird weitere und höhere Anforderungen an die Qualität und die Ausbildung der Software-Ingenieure stellen, und verkleinert damit potentiell die Personalbasis der Fachkräfte, die effizient und schnell ihre Problemlösungen umsetzen können.
C++ ist eine Compilersprache. Es gehen mithin die Aspekte verloren, die von einem interaktiven System wie Smalltalk geboten werden: Es verliert die konzeptuelle Mächtigkeit eines Systems, das eine flexible Prototyp-Erstellung und Experimentation mit Implementations-Alternativen bietet. Weiterhin wird die Möglichkeit eines interaktiven Prototyping-Systems aufgegeben, welches auch als Kommunikationsmedium zwischen Menschen, z.B. in einer Arbeitsgruppe dienen kann. Mit OO-Systemen der C++-Klasse wird zwar ein Faktor höherer Ordnung der Software erreicht, aber es muß ein Preis in Form von Tradeoff-Faktoren [3] auf der Seite der menschlichen (Ergonomie-) Aspekte gezahlt werden

7.4.1. Unterschiedliche Formen von Objekten

Ein wesentliches Problem der OOP ist die Begriffsverwirrung, die durch den leichtfertigen Gebrauch des Wortes Objekt in dieser Technologie entstanden ist. Dies ist mit ein Grund für die Unsicherheit gegenüber der Technologie. Ein Objekt der OOP hat nur sehr wenig mit Objekten der physikalischen Realität zu tun. Innerhalb der OOP haben sich ebenfalls verschiedene Begriffsformen herausgebildet, so daß der Begriff des Objekts als solcher kaum noch eine faßbare Bedeutung hat. Hier soll daher eine etwas präzisere Fassung unternommen werden. Die verschiedenen Typen von Objekten sollen im folgenden Text durch Präfix gekennzeichnt werden. Eine (nicht vollständige) Listung ergibt folgende Typen von Objekten: P:Objekt, D:Objekt, C:Objekt und O:Objekt.


P:Objekt Ein physikalisches Objekt der dinglichen Welt, das sich anfassen und manipulieren (mit der Hand beeinflussen) läßt. Dieses Objekt ist der kinesthetischen Wahrnehmung des Menschen zugänglich. (Näheres dazu im Abschnitt: "Das kinesthetische Lernen des Menschen")

D:Objekt Ein gedachtes Objekt des Denkens, ein Begriff, ein Konzept. Etwas, das z.B. Klasse von Gegenständen der dinglichen Welt bezeichnet.


C:Objekt Ein Computer-Objekt allgemeiner Art. Dies kann ein auf einem Bildschirm dargestelltes Ikon sein, ein Cursor, ein Window, ein Menu -- Also irgendetwas, das ein Benutzer als von seinem Hintergrund verschiedenes Ding ausmachen kann, das eine bestimmte Bedeutung hat. Die Art der Programmiertechnik, mit der dieses C:Objekt erstellt wurde, braucht keinerlei Bezug zu O:Objekten haben.
O:Objekt Ein Objekt in der Begriffsweise der Objekt-Orientierten Programmierung. Dies ist ein Software-Modul, das sich durch einen privaten Datenbereich und Methoden auszeichnet, die durch Messages (Nachrichten) aktiviert werden, die von anderen Objekten an dasselbe geschickt werden. Im weiteren Sinne ist hiermit auch die Zugehörigkeit zu einer Klassenhierarchie von Objekten mit ähnlichen Eigenschaften bestimmt, sowie eine formale Vorschrift, wie die Zuordnung von O:Objekten zu dieser Klassenhierarchie erzeugt wird Die Systematisierung der O:Objekte in der OOP ist an die Linnesche Klassifizierungshierarchie in der Biologie angelehnt. Aus dieser Anlehnung stammt der Begriff der Vererbung.

7.4.2. Objektorientierung für den Benutzer

Mit dem Inter-Aktor-Konzept werden bestimmte Akzente der Objekt-Orientierten Programmierung, wie sie besonders von Smalltalk initiiert wurden, weiterentwickelt. In Smalltalk sind genau genommen zwei recht verschiedene Ideen von Objekt-Orientierung realisiert worden, die O:Objekt und die P:Objekt Metapher. Das O:Objekt ist ein Konstrukt zur logischen Ordnung im Software-Konstruktionsprozess, während das P:Objekt für den Benutzer gedacht ist. Das Inter-Aktor-Prinzip baut auf der P:Objekt Metapher von Smalltalk auf. Das Grundkonzept des Inter-Aktors ist eine lokal autonome Software-Einheit, die wie in der OOP über einen privaten Datenbereich und private Prozeduren verfügt, die über Messages (Nachrichten) aktiviert werden. Der Hauptaspekt des Inter-Aktors ist aber seine interaktive Handhabung durch den Benutzer, und die Unterstützung, die dem Benutzer geboten wird, seine Benutzung inkrementell zu lernen. Dies bedeutet: In kleinen Schritten von einer standardisierten und vordefinierten Arbeitsweise über Menus und Masken den Weg hin zu einer spezifischen und freien Programmierung der Funktionen des Inter-Aktors zu gehen. Zu diesem Zweck stehen leistungsfähige Hilfsmittel wie Hypertext und kontextsensitive Help-Fenster zur Verfügung.

7.4.3. Objektbibliotheken und die Verlagerung des Schwerpunkts der Software-Produktion

Mit der zunehmenden Verwendung von OO-Methoden verlagert sich die Vorgehensweise in der Programmierung entscheidend von der individuellen Konstruktion von Modulen aus einfachen Bauteilen (den Anweisungen der Programmiersprache) hin zu einer mehr bibliothekarischen Tätigkeit. OOP fängt bei der sorgfältigen Konstruktion von Objekt-Libraries an. Die Effizienz von OOP hängt entscheidend davon ab, wie gut diese Libraries konstruiert sind, wie schnell man etwas findet, und wie flexibel die Module sind. Hier steht die Entwicklung erst am Anfang. Es gibt noch verhältnismäßig wenig Erfahrung mit Libraries von 10.000 und mehr Objekten. Das LPL-System ist darauf ausgelegt, solche großen Informationsbestände zu verwalten - egal in welcher Programmiersprache. So existiert eine Version für Ada, für Eiffel, für C++. Die effizienteste Verwaltung muß von Mitteln wie Hypertext Gebrauch machen, sie muß die Möglichkeit bieten, Menu-Browser mit vielen verschiedenen Zugriffswegen auf die Information zu konstruieren. Funktionalitäten, die im LPL-System schon seit mehreren Jahren entwickelt und optimiert werden.

7.5. Die Ergonomie-Aspekte des Inter-Aktors

7.5.1. Kategorien des Software-Universums

Das Prinzip des Inter-Aktors stammt aus der Erkenntnis, daß sich Software-Aufgaben in Kategorien (nicht identisch mit Klassen der OOP) aufteilen lassen. Die Begriffe "Kategorie" und "Klasse" werden oft synonym verwendet. Der Klassenbegriff hat in der Informatik schon eine feste Bedeutung im Bereich der OOP. Kategorisierung ist die Bezeichnung einer systematischen Aufstellung von Betrachtungskriterien oder Einordnungskriterien, unter denen man einen Gegenstand unter Betrachtung einordnen kann. Kategorien sind ein wesentliches Thema der Philosophie. Die erste systematische Behandlung von Kategorien stammt von Aristoteles.
Ein Inter-Aktor ist ein Software-Modul, das speziell für die Bearbeitung von Aufgaben einer solchen Kategorie entworfen wurde. Im Unterschied zur OOP, in denen einfachere Objekte über Vererbung zu Objekten höherer Mächtigkeit und größerer Spezialisierung führen, sind Inter-Aktoren von Beginn an sehr mächtige Konstrukte, die in ihrer Funktionalität etwa eine ganze OO-Klasse mit ihren Unter-Objekten und Methoden abdecken.

7.5.2. Die Metapher des Gebrauchsgegenstands

Eine Charakteristik des Inter-Aktors ist seine konzeptuelle Ähnlichkeit mit einem Gerät des täglichen Gebrauchs, so zum Beispiel einer Küchenmaschine oder einer Multifunktions-Bohrmaschine. Die Design-Prinzipien solcher Geräte stehen Pate bei der Konzeption des Inter-Aktors. Im Gegensatz zur OO-Programmierung, wo eine Vielzahl von Objekten in vielen Klassen vorliegt, existieren in der IAOP einige wenige, sehr mächtige Inter-Aktoren, mit denen man eine große Anzahl von Aufgaben bearbeiten kann. Die Anpassung eines Inter-Aktors an spezielle Aufgaben erfolgt durch Anbringen einer Spezialfunktion an das Grundgerüst der Funktion. Die Mächtigkeit dieses Vorgehens zeigt sich vor allem nach einiger Zeit des Arbeitens mit Inter-Aktoren, da hier bald bestimmte Grundtypen oder Funktionsmuster, (die oben als Kategorien bezeichnet wurden) hervortreten, und die in prinzipiell sehr einfachen Software-Konstrukten verkörpert werden können. Hier ist also Mächtigkeit mit Einfachheit gekoppelt, was sicher eines der höchsten Design-Kriterien sein sollte.

7.5.3. Die Mechanik des menschlichen Gedächtnisses

Die konzeptuelle Transparenz für den Durchschnittsmenschen ist der wesentliche Grund für die Zusammenfassung der verwandten Funktionen in einen Inter-Aktor. Das menschliche Gedächtnis ist assoziativ, und Gedankenverbindungen werden verstärkt, wenn Assoziationen mehrfach wiederholt werden. Weiterhin ist das Gedächtnis topisch, also ortsbezogen. Wenn eine Funktion mit einem bestimmten D:Objekt oder P:Objekt mehrmals assoziiert wird, verstärkt sich auch die Definition, also das begriffliche Bild des Menschen von diesem D:Objekt oder P:Objekt. Dies ist extrem wichtig für die Eigenschaft des Self-Teaching oder autonom-Lehrens von Systemen. Es muß unter allen Umständen erreicht werden, daß sich die Konzepte über die Natur und die beste Verwendbarkeit des Inter-Aktors im Benutzer "von selbst" bilden, also ohne große Schulung und Einweisung kommen. Das Modell hierfür bieten wiederum die Gegenstände des täglichen Gebrauchs.

7.5.4. Das kinesthetische Lernen des Menschen

Die tiefsten und dauerhaftesten Lernerfahrungen des Menschen sind kinesthetisch[4], also mit dem Erfahren des ganzen Körpers, und nicht nur konzeptuell, verbunden. Die Idee der Virtual Reality ist der heute am weitesten fortgeschrittene Versuch, das kinesthetische Erleben des Menschen mit Computer-Hilfe zu stimulieren. Je ähnlicher ein C:Objekt einem P:Objekt ist, desto eher ist die Chance zu einem kinesthetischen Erlebnis gegeben. Dies ist einer der Gründe für die Wirksamkeit der Window-Mouse Metapher der heutigen Benutzer-Umgebungen.
Wichtiger als eine mechanische Manipulationsfähigkeit eines C:Objekts ist aber eine kinesthetische Überleitung zu höheren Formen der Manipulation. Dies ist bei heutigen Window-Maus-Systemen noch recht wenig erforscht. Generell ist aber eine interaktive Bearbeitung die Voraussetzung hierfür. Inter-Aktoren bieten diese Möglichkeit.

7.5.5. Die Anpassung des Computersystems an das menschliche Nervensystem

Es gibt einige Faustregeln des interaktiven Arbeitens mit dem Computer, deren Beachtung nötig erscheint, um eine optimale Anpassung des Systems an den Benutzer und eine maximale Produktivität zu erreichen: Diese Faktoren wurden in der Auswertung der Erfahrungen mehrerer Jahre der Arbeit mit dem Leibniz-System bestimmt. Sie werden gleichfalls durch Ergebnisse der kognitiven Psychologie bestätigt. Zum einen ist hier die Begrenzung des Kurzzeitgedächtnisses auf ca. 5-7 Elemente. Diese Limitation ist im Bereich der Probrammierung kritisch, da das Erstellen von neuen Funktionen aus vorhandenen einen geistigen Balance-Akt darstellt, auf der einen Seite die Erfordernisse der neuen Funktion im Gedächtnis zu behalten, und auf der anderen Seite die Informationen der vorhandenen Funktionen in optimaler Weise zu verknüpfen. Dies ist, wie schon oben im Abschnitt "Objektorientierte Programmierung" bemerkt, ein Faktor, der in der OOP wesentlicher ist als in der alten prozeduralen Programmierung, da man sich hier wesentlich mehr auf vorhandene Funktionen stützt, als in der alten Arbeitsweise, wo die Zahl der vorhandenen Funktionen relativ klein und überschaubar ist.

7.5.6. Die kritische Zehntel-Sekunde

In dieser Arbeitsweise ist es eminent wichtig, daß das System dem Benutzer alle relevante Information so darstellt, daß er innerhalb seiner Aufmerksamkeitsspanne darauf zugreifen kann. Wenn das System in seinen wesentlichen Funktionen eine Arbeitsweise innerhalb dieser Spanne ermöglicht, entsteht ein Effekt, der als eine Erweiterung des menschlichen Nervensystems bezeichnet werden kann. Die Arbeitsabläufe am Computer gewinnen die Eigenschaften von Reflexen, fließen also ebenfalls in das kinesthetische Vermögen des Organismus ein. In diesem Sinne kann man davon sprechen, daß das System zu einer Erweiterung des menschlichen Denkvermögens geworden ist.

7.6. Die Syntax des Inter-Aktors

7.6.1. Default-Aktoren und typisierte Messages

Ein funktionales IAOP-System benötigt nur einige wenige Standard-Aktoren, da jeder Inter-Aktor für sich sehr mächtig ist. Der besondere Vorteil einer geringen Zahl von Inter-Aktoren ist, daß man nicht, wie bei OOP-Systemen, explizit das angesprochene Objekt nennen muß, um ihm eine Message zu schicken, sondern hier gilt, frei nach MacLuhan: "The Medium is the Message".
Wie weiter unten (Instanzen) ausgeführt, existiert zu jeder Inter-Aktoren-Kategorie ein Default-Aktor, der immer aktiv ist, und wenn ein anderer Inter-Aktor derselben Kategorie angesprochen werden soll, wird dieser zum Default-Aktor gesetzt. Damit erübrigt es sich, den Namen eines Inter-Aktors mit der Message zu nennen, statt dessen wird nur die Inter-Aktor-Kategorie angesprochen. Wegen der geringen Zahl der Kategorien genügen hierfür meist ein bis drei Zeichen, die vor allem die begriffliche Assoziation des Benutzers erleichtern.

7.6.2. Aktor-Message-Syntax

Die Syntax des Inter-Aktoren-Skripting wird so einfach wie möglich gehalten. Die Message-Syntax Inter-Aktor.message ist an die Eiffel-Konvention angelehnt. Der Inter-Aktor-Typ steht links von dem Punkt und die Message rechts davon. Der Typ-Teil wird auch als Message-Typ Prefix bezeichnet. Das Message-Typ Prefix des String-Aktors ist ein "$"-Zeichen. Jede Message, die mit einem "$" anfängt, ist damit automatisch als eine Message für den Default-String-Aktor kenntlich. Siehe dazu das Beispiel der String-Aktor Messages am Ende des Artikels (Anhang I).

Beispiele:


$.invert ist die Message, den String-Buffer des Inter-Aktors zu invertieren, also das letzte Element zum ersten zu machen.
$.print ist die Message, den aktiven String des Inter-Aktors an das Terminal auszugeben.

7.6.3. Aktor-Skript-Syntax

Aktoren-Skripte sind in ihrer Syntax an wesentliche Prinzipien der Schriftsprachen angelehnt. Auch dadurch wird eine Annäherung an die konzeptuellen Gewohnheiten des Menschen erreicht. Messages an Inter-Aktoren sind "Verben" und werden in Kleinbuchstaben gehalten. Ihr Gebrauch hält sich an die Konventionen von Verben der natürlichen Sprache. Inter-Aktoren sind "Subjekte" und werden groß geschrieben. Die Notation ist eine Folge von Kommandos. Subjekte kommen im Unterschied zur natürlichen Sprache nicht in jedem Satz vor, und wenn, dann ist die Reihenfolge generell: Subjekt Prädikat

7.6.4. Instanzen von Inter-Aktoren

Aktoren lassen sich, wie Objekte der OOP instanziieren, d.h. es lassen sich neue Kopien eines Inter-Aktors erzeugen. Dies ist bei der Mächtigkeit der Inter-Aktoren nicht immer nötig, und man kommt oft mit einem einzigen Inter-Aktor einer Kategorie aus. Die Instanziierung eines Inter-Aktors geschieht mit einer speziellen Message, z.B. :VDV für Window-Aktoren. Die Anweisung:
:VDV W-MAIN
erzeugt eine neue Instanz des Window-Aktors unter dem Namen W-MAIN und setzt ihn gleichzeitig zum Default-Window-Aktor. Mit der Message:
W-MAIN v.default
wird der Window-Aktor W-MAIN zum Default-Aktor gemacht. W-MAIN bleibt damit für alle Messages an die Kategorie VDV ( = Window-Aktor ) der Default-Adressat, und reagiert auf diese Messages. Soll ein anderes Window angesprochen werden, schaltet man um:
W-SYS v.default
W-SYS bleibt dann bis zum nächsten Umschalten der Default-Aktor.

7.7. Unix, Inter-Aktoren, Shells und Pipes

7.7.1. Neufassung der Pipe: Prozess-Entkoppelung über Daten-Aktoren

Aktoren lassen sich in zwei Grund-Typen unterteilen: In Daten-Aktoren und Prozess-Aktoren. Dies scheint den Grundsätzen der OOP zu widersprechen, da ja jedes Objekt seinen eigenen Datenbereich haben soll, auf dem es arbeitet. Der Grund für diese Unterteilung liegt in den Möglichkeiten der Prozess-Entkoppelung, die mit einer solchen Systematisierung geboten werden. Dies ist ein wesentlicher Faktor, um Vereinfachung in Software-Systemen zu erreichen. Die Existenz von Daten-Aktoren ist hierin eine Weiterentwicklung solcher bekannter Konzepte wie Pipes, Shared Memory, und Shell-Programmierung.
(Weitere Information zu diesem Thema sind auch in dem Artikel
"Die Inter-Aktoren-Shell ACsh" ART-ACSH.TXT enthalten.)
(Abb.: Kommunikations-Schma von Daten-Aktoren und Prozess-Aktoren)

7.7.2. Die Prinzipien der Shellprogrammierung und Inter-Aktoren

Das Unix-System hat eine Programmiermöglichkeit, die besonders in den Anfangsjahren intensiv genutzt wurde, bevor es mit dem Virtual Memory Management die Möglichkeit gab, beliebig große Prozesse zu schreiben: Die Shell-Programmierung. Da man mit der eingeschränkten Komplexität eines einzelnen Prozesses (ein C-Programm) nur ein Segment eines umfangreicheren Problems bearbeiten konnte, wurde eine Zwischenlösung auf die Pipe (eine unbenannte Datei) ausgeschrieben, die von dem nächsten Prozess eingelesen und weiterverarbeitet werden konnte, sobald der erste Datensatz vom ersten Prozess ausgeschrieben war.

7.7.3. Shell-Programmierung reduziert Software-Komplexität

Diese Art der Programmierung hatte damals technische Gründe, und ist heute ein wenig aus der Mode gekommen, da die Shells nicht mehr dem heutigen Stand der Benutzer-Interaktions-Technik entsprechen. (Sie sind noch auf das Command-Line Interface der Teletype Terminals ausgelegt.) Nichtsdestotrotz ist diese Programmiermöglichkeit eine ausgezeichntete Basis für das interaktive Rapid Prototyping, wenn man erst einmal die Benutzung dieser Shells beherrscht. Ein ganz wesentlicher Vorteil dieser Programmierung ist aber die Reduktion der Komplexität des Gesamtproblems, indem genau definierte Zwischenschritte der Verarbeitung erstellt wurden, die in einem anderen Medium zwischengespeichert wurden. Dies bringt den zusätzlichen Vorteil, daß beim Testen einer Problemlösung immer auf diese leicht definierten Zwischenschritte aufgesetzt werden kann.

7.7.4. Block-Programmtechnik macht lokale Daten unzugänglich

Als Kontrast hierzu sei die heute gängige Praxis der Block-orientierten Programmiersprachen und der strukturierten Programmierung genannt. Hier werden sämtliche Arbeits-Datenbereiche des Programms lokal unter der Kontrolle der main() oder einer untergeordneten Routine auf dem Prozess-Stack oder dem System-Heap angelegt. Damit sind sie viel schwerer nach Unterbrechung des Prozesses z.B. für einen Post-Mortem Debug zugänglich.
(Abb.: Die Main() Hierarchie)

7.7.5. Unix-Filtertools als Inter-Aktoren

Der Vorteil der Shellprogrammierung beruht darauf, daß das Unix-System eine Vielzahl von kleinen, spezialisierten Programmen (Filter) bereithält, die über Kommandozeilen-Steuerung mehr oder weniger einfach und intuitiv auf genau die erwünschte Leistung eingestellt werden können. Die Betonung liegt dabei auf WENIGER intuitiv. Das Problem der Benutzer-Ergonomie von Unix ist unverkennbar. Erstens ist es recht intransparent, welche Filter das System für welche Aufgaben bereithält, und wie sie heißen. Dann ist es genauso un-intuitiv, welche Schalterstellungen nun was in welcher Situation bewirken. Daher ist die Nutzung dieser Vorteile nie über einen relativ kleinen Kreis von Unix-Eingeweihten hinausgedrungen.
Die Filter-Tools haben sich seit den Anfangstagen von Unix kaum verändert und es sind in den Jahren auch nicht mehr viele hinzugekommen. Einige Grundprinzipien des Inter-Aktors sind aber vorhanden: Eine große Menge von mächtiger verfügbarer Funktionalität, die auf eine wesentlich kleinere Anzahl von Funktionsträgern systematisch verteilt ist, indem jeder Funktionsträger eine umrissene Klasse von Aufgaben bearbeitet; eine interaktive Benutzer-Schnittstelle und eine inkrementelle, interaktive Möglichkeit, Programme zu erstellen, und zu testen.
(Abb.: Prozess-Kommunikation über Pipes in Unix)
(Abb.: Prozess-Kommunikation über Daten-Aktoren)

7.7.6. Unix-Shell hat keinen Zugriff auf Libraries

Im Gegensatz zu den Anfangszeiten hat sich das Gewicht der verfügbaren frei kombinierbaren Prozesskapazität von den Filtern auf die Libraries verschoben, so daß heute nur noch ein minimaler Prozentsatz (der aber in Bytes Code sehr groß ist) der Gesamt-Kapazität eines Standard-Unix-Systems in Form von Filter-Tools vorliegt. Diese sind nur auf das zeichenorientierte Datei-Interface eingerichtet, das heute weniger und weniger der Gesamtarbeit in einem Software-System einnimmt. So wird die Window-Programmierung davon nicht berührt, deren Funktionen durch Libraries für Anwenderprogramme bereitgestellt werden. Der Nachteil daran ist, daß diese Libraries nur über den (C-) Compiler eingebunden werden können. Zwar existieren viele Ansätze von speziellen Construction Kits vor allem für die (X-) Windows Programmierung, aber es existiert keine gemeinsame Konzeption für diese Tools, wie es das alte Shell-Konzept war. Und die Shell selber kann nur fertig compilierte Programme aufrufen, aber nicht auf die Libraries direkt zugreifen.

7.7.7. Die Eigenschaften der LPL-Shell

Die vorliegende Konzeption der LPL-Shell, in der die Inter-Aktoren liegen und aufrufbar sind, beruht auf einem Shell-System, das Zugriff und Einbaumöglichkeit aller Libraries bietet, die damit auch in einem interaktiven Rapid-Prototyping System mit einer durchgängigen Systemphilosophie zugänglich sind. Um die erforderliche Funktionalität der heute üblichen Ergonomie-Hilfsmittel von Windows und Multi-Media mit einer Pipe-ähnlichen Methode nutzbar zu machen, braucht man eine neue Konzeption dessen, was vor 20 Jahren mit den relativ unstrukturierten Konzepten von stream-i/o verwirklicht wurde. Hier sind in der LPL-Shell einige Prototyp-Implementationen gemacht worden, wenn auch die Entwicklung noch am Anfang steht.

7.7.8. Andere Ansätze zum Konzept der erweiterten Shell

Die Software-Industrie hat in dem Bemühen, eine möglichst gute lokale Anpassbarkeit der Produkte zu bieten, eine Familie von Skript-Sprachen hervorgebracht, mit denen Anwender vor Ort ihre Programme ohne Einsatz eines Compiler-Entwicklungssystems einstellen können. Die LISP-Programmiersprache von EMACS hat bei fast allen professionellen Programmier-Editoren ähnliche Programmierschnittstellen nach sich gezogen. Weiterhin sind die Kommandosprachen von Tabellenkalkulations-programmen in diese Klasse zu zählen. Ebenfalls die Interpreter-Sprachen von Datenbank-Systemen. Die Ansätze sind vorhanden, aber es fehlt eine einheitliche und durchgängige Implementation auf Systemebene, wie sie seit der Anfangszeit von Unix mit der Shell gegeben ist. (Deren Funktionalität hat aber nicht mit der technischen Entwicklung Schritt gehalten.) Insofern ist die LPL-Shell ein Konzept, das sich an verbreitete Vorgänger anlehnt. Um eine breite Akzeptanz in Benutzerkreisen zu finden, müssen diese Skriptsprachen aber vereinheitlicht werden und vor allem mit einer mächtigen Benutzerunterstützung verbunden werden. Diese Aufgabe hat sich das LPL-System gesetzt.
(Abb.: Die Inter-Aktoren-Shell als dritte Programmier-Ebene)
(Abb.: Alternative Kontrollflüsse: Lokale Steuerung der Inter-Aktoren über die
Shell)

7.7.9. Komplexitätsreduktion der Software durch Inter-Aktoren

Das Prinzip der Prozesskoppelung durch Pipes läßt sich mit spezialisierten Inter-Aktoren auf zeitgemäße Weise verwirklichen, und hat den Vorteil, daß wie bei diesem alten Unix-Konzept die Prozesse sich klein halten lasssen, da sie nur bestimmte Aspekte einer Aufgabe lösen müssen. Da nicht der Umweg über ein Datei-Konstrukt gegangen werden braucht, sondern im RAM Bereich gearbeitet werden kann, ist hier nur minimaler Zeitverzug als Preis zu entrichten. In der heutigen Welt der Software-Krise ist es eine unbedingte Notwendigkeit, die Komplexität der Prozesse zu reduzieren. Der Mensch ist schon seit mindestens zehn Jahren der "limiting factor" der Software-System-Entwicklung, d.h.: Software-Komplexitäten, die von der Maschine ohne weiteres verarbeitet werden können, überlasten die personellen Ressourcen. (Nicht die Erstellung der Software, sondern ihre Wartung und Weiterentwicklung ist das große Problem, wenn die Original-Teams sich aufgelöst haben).
(Abb.: Software heute im main() Paradigma)
(Abb.: Software im Inter-Aktoren Paradigma)

7.8. Der interne Aufbau des Inter-Aktoren-Systems

Aktoren können, müssen aber nicht, in OOP-Technik programmiert sein. Inter-Aktoren sind, wie weiter oben spezifiziert, "Objekte für den Benutzer". Wenn sie programmiertechnisch auch O:Objekte sind, dann ist das eine Sache der lokalen Implementation. Inter-Aktoren bieten eine Schnittstelle, um auf einer bestimmten Programmier-Ebene objektartig arbeiten zu können.

7.8.1. Die Tokenlisten-Maschine TLSI

Die technische Grundlage des Leibniz Inter-Aktoren-Systems ist der Token-Listen-Subroutinen-Interpreter, kurz TLSI genannt. Diese Klasse von logischen Maschinen gehört zu der größeren Gruppe der Metacode-Maschinen. Metacode-Maschinen sind Rechnermodelle, deren Programmcode von dem Compiler nicht in den Objekt-Code (Maschinencode oder Assemblercode) des verwendeten physikalischen Rechners übersetzt wird, sondern von einem residenten Kontrollprogramm interpretierend abgearbeitet wird. Beispiele dafür sind z.B. der Pascal P-Code (Pseudocode), APL, LISP und Postscript. Der TLSI ist ein sehr einfaches Rechnermodell, das sich auf jedem beliebigen Von-Neumann Rechner mit ca. 10 bis 30 KByte -Code installieren läßt. Wesentliche Eigenschaften des TLSI sind: Erweiterbarkeit, Portierbarkeit, Interaktivität und Umwandlungsmöglichkeit in C-Code.
(Abb.: Die Struktur der Tokenlisten-Maschine)
Erweiterbarkeit: Der wichtigste Aspekt des TLSI ist seine Erweiterbarkeit. Dadurch ist es möglich, mit einem primitiven Kernel-System in einer Minimalkonfiguration (10 bis 30 KBytes), als auch auf einer Workstation-Umgebung mit Megabyte-Größen zu arbeiten. Die Erweiterbarkeit erlaubt Anpassung an jede denkbare (und nicht denkbare) Konfiguration. Der TLSI ist eines der flexibelsten Software-Systeme überhaupt.
Portierbarkeit: Dieses genormte Rechnermodell läßt sich auf einer Vielzahl von Ziel-Prozessoren mit relativ geringem Anpassungs-Aufwand installieren. Der Arbeitsaufwand liegt bei ca. 3 Mann-Monaten. Verwendet man die C-Installation, dann ist der Portierungsaufwand nahe Null. Damit ist es möglich, standalone-Installationen auf jedem Zielrechner zu machen, und auch auf Rechner ohne Betriebssystem zu portieren.
Interaktivität: Auch in der Minimalversione ist eine User-Shell (UINT) integriert, daher ist immer interaktives Arbeiten möglich. Das System verhält sich in seiner Minimal-Konfiguration wie ein sehr leistungsfähiger Debugging-Monitor.
Umwandlungsmöglichkeit in compilierbaren Code: Weil hier ein Zwischencode interpretiert wird, ist die Ausführungsgeschwindigkeit nicht so hoch wie compilierter Assembler-Code. Es ist aber in dem C-implementierten System möglich, mit einem einfachen Filter eine Konversion von Tokencode zu compilierbarem C-Source Code zu machen, indem man jeden Token-Call durch einen C-Function Call ersetzt. Dies ist ein wesentlicher Vorteil gegenüber einer konventionellen Shell. Die Entwicklungsgeschwindigkeit ist durch die interaktive Arbeitsweise wesentlich höher als mit einem konventionellen Compiler-System.
Ideal für Source-Code-Debugger: Ein ganz entscheidender Vorteil ergibt sich durch die extrem einfache Verbindung des Run-Time Token Codes mit der Source-Information, das die Erstellung eines Source Code Debuggers zu einem vergleichsweise einfachen Projekt macht. Statt der Größenordnung von 1 bis 5 Mannjahren, läßt sich ein ausgefeilter Source-Code Debugger in ca. 3-6 Mannmonaten erstellen.
Abstrakter Rechner: Für theoretische Betrachtungen interessant ist der Faktor, daß der TLSI wahrscheinlich das einfachste praktisch nutzbare Rechnermodell ist. Es ist vergleichbar mit einer LISP-Maschine, wird aber wesentlich effektiver implementiert, so daß kein aufwendiger Rechner zur schnellen Abarbeitung erforderlich ist. Wie eingangs schon festgestellt, ist das System auf Minimalanforderungen ausgelegt. Kernelversionen des Systems laufen auch auf Single-Chip Prozessoren.

7.8.2. Aufbau und Abarbeitung einer Tokenliste

Die Tokenliste (TL) besteht aus einer Folge von Toke ns, die in einer geeigneten Datenstruktur abgelegt sind. Diese Datenstruktur besteht aus einer Folge von CELLs (Zellen) Jede CELL kann ein Token oder ein Datenelement enthalten, bei der vorliegenden Implementation werden CELL-Größen von 4 Byte verwendet. Die konzeptuelle Einfachheit dieses Schemas gegenüber den Assembler-Instruktionsformaten normaler (CISC-) Prozessoren besteht darin, daß die Befehlsbreite immer gleich ist.
Ein Token ist ein Stellvertreter für eine Routine. Eine Routin e wird ausgeführt, indem die zugeordnete Tokenliste von der STEP-Maschine abgearbeitet wird. Dies bedeutet, daß die einzelnen Tokens der Liste (oder vielmehr die damit repräsentierten Routinen) ausgeführt werden. Der jeweils aktuelle Stand der Abarbeitung innerhalb der Tokenliste wird im Befehlszeiger (Instruction-Pointer: IP) gehalten.
(Abb.: Schema der STEP-Maschine)

7.8.3. Subroutinen-Abarbeitung

Die STEP-Maschine arbeitet somit eine Tokenliste vom Start bis zum Ende ab. Da in der meisten Fällen die Tokens in den CELLs auf weitere Tokenlisten verweisen, wird in der bekannten Art des Subroutine-Nest die augenblickliche Position des IP in der augenblicklichen TL auf dem Control- oder Return-Stack gerettet, und die entsprechende neue Tokenliste abgearbeitet. Trifft die STEP-Maschine auf eine Routine, die Assemblercode des Host-Prozessors enthält, wird der Instruktions-Satz des Host-Prozessors ausgeführt.


[1]Der Begriff Hypertext wurde von Ted Nelson geprägt. Hypertext ist eine Methode, Texte und Dokumente verschiedenster Herkunft mit einer einfachen Anwähl- und Klick-Methode sofort auf den Bildschirm (oder zur Ausführung) zu bringen. Wenn Ton und Video enthalten sind, wird es auch Hypermedia genannt. Diese Methode ist ideal für die Verwaltung von weit verzweigter Information geeignet, wie sie in der Software-Produktion vorkommt. Source Code, Dokumentation, Schnittstellenbeschreibungen, Anforderungen, Testberichte, etc. können auf diese Weise sehr einfach verwaltet werden.
[2]Siehe auch: Die Tokenlisten-Maschine TLSI
Ein TLSI ist ein Interpreter, der Listen von Tokens abarbeitet, die jeweils für einen Subroutinen-Sprung stehen. Da ein Token weniger Speicherplatz benötigt als eine expandierte Subroutine, ist dieses Modell besonders speichereffizient. Ein ähnliches Verfahren wird auch bei der P-Code Option des Microsoft-C ® Compilers verwendet.
[3]Tradeoff: Für einen Vorteil einer bestimmten Größenordnung handelt man sich anderswo Nachteile derselben Größenordnung ein. Der Nettogewinn ist dadurch wesentlich geringer als erwartet. Auf Deutsch müßte man das etwas umständlicher als "invers proportionales Austauschverhältnis" bezeichnen.
[4]Kinesthesie: Die Wahrnehmung des Menschen von seinem eigenen Körper, des Muskelapparats, und der Schwerkraft-Organe in der physikalischen Umwelt von Masse, Bewegung und Beschleunigung. Im weiteren Sinne auch die Sinnesempfindungen von Wärme und Kälte. Diese Sinnesempfindungen sind nur sehr selten mit Gedanken und Assoziationen verbunden, sondern werden mehr als "Gefühl" erlebt. Die kinesthetischen Leistungen des menschlichen Nervensystems werden vom Rückenmark und vom Stammhirn, dem sog. Reptiliengehirn, also dem entwicklungsgeschichtlich ältesten Gehirnteil erbracht. Kinesthesie wird in diesem Kontext abgegrenzt von Sinnen wie Auge und Ohr, die fast immer mit Gedanken und Assoziationen verbunden sind, so daß diese Wahrnehmungen viel mehr eine symbolische Überlagerung erfahren. Diese Funktionen sind mehr mit der Hirnrinde assoziiert.


previous next Title Contents Index