Die Inter-Aktor Shell ACSh ist eine Hypertext-gestützte Window-orientierte, interaktive low-cost Rapid-Prototyping Umgebung, die auf Prinzipien der altbewährten Unix Shell-Programmierung und Makro-Skriptsprachen basiert. Heutige Software-Technologie mit DLL und Message Run-Time Binding in der OOP ermöglicht eine flexiblere Programmierung als mit konventionellen, fest gelinkten Modulen. Mit der Inter-Aktor Shell lassen sich präcompilierte Funktionen interaktiv und interpretativ aufrufen und zu neuen Makros für lokalen Bedarf verknüpfen, und somit weite Bereiche von Anwendungen abdecken, die für eine zentrale Fertigung beim Software-Hersteller zu aufwendig oder zu speziell für einen Massenmarkt wären. Die ACSh bietet die Funktionalität und Hilfemöglichkeiten, um einem Benutzerkreis von nicht software-technologisch spezialisierten Anwendungs-Experten den leichten Zugang zur Programmierung komplexer Anwendungen zu ermöglichen. Die Inter-Aktor Shell bietet darüberhinaus einen Zugang zum Re-Engineering bestehender Systeme, deren Funktionen über das Shell-Interface entkoppelt werden können und interaktiv im Prototyping-Verfahren an neue Erfordernisse angepaßt werden können.
The Inter-Actor Shell ACSh is a hypertext based, window oriented, low-cost, rapid prototyping Environment that is based on principles of the "old faithful" Unix Shell and Macro Script languages. Modern Software Technology with DLL and message run-time binding allows a more flexible mode of programming than conventional permanently linked modules. With the ACSh it is possible to use pre-compiled functions in a standard software product interactively and interpretatively and construct new macros for local purposes. Thus it is possible to cover applications which would be too expensive to include with the standard edition. Also, the Inter-Actor allows Re-engineering of existing systems whose functions are de-coupled in the shell and can be individually re-structured for new requirements.
Moderne Software-Systeme wie Microsoft Word® sind nicht mehr
monolithisch zusammengebundene Komplexe, die in einem untrennbaren .EXE-Modul
liegen, sondern sie sind mehr als ein kooperativer Verbund einer Vielzahl von
relativ unabhängig voneinander aufrufbaren Submodulen zu sehen, der nur
umständehalber zu einer verkaufsfähigen Standard-Konfiguration
zusammengesetzt ist. Unter der Oberfläche besitzen solche Systeme aber
eine Spezialsprache, bei Word das Word Basic für die Text- Be- und
Verarbeitung. Dessen Mächtigkeit läßt sich über beliebig
einbindbare DLLs auf jede gewünschte Leistung ausbauen, die völlig
außerhalb dessen liegen kann, was die Entwickler von Word jemals geplant
hatten. Diese Möglichkeiten werden aber heute selten voll ausgenutzt.
Makrosprachen und Shell-Systeme haben eine Gemeinsamkeit: Sie sind im
Gegensatz zu den konventionellen Compiler-Systemen interaktiv, und für
die Einstellung eines Systems vor Ort gedacht, also nicht beim
Software-Hersteller, nicht zum Gebrauch von Software-Ingenieuren, sondern von
Benutzern, die zwar viel von ihrer Anwendung verstehen, aber wenig Interesse
haben, auch noch Experten für Software-Technologie zu werden. Für
einen solchen Benutzerkreis ist ein interaktives System die erste Voraussetzung
zur Akzeptanz. Weitere Voraussetzungen sind eine möglichst einfache, um
nicht zu sagen primitive Syntax, mächtige Funktionalität der
Operatoren, und ein fehlertolerantes Verhalten. Nicht umsonst wurde das bei
Word in ein interpretiertes Basic-System gefaßt. Für Systeme dieser
Art wurde in dem Leibniz Projekt der Begriff Inter-Aktor, oder
abgekürzt: Aktor geprägt. Das Wort Inter-Aktor wie hier
gebraucht hat zwar eine ähnliche Konzeption wie der Actor in dem
gleichnamigen Programmiersystem der Whitewater Group, umfaßt aber
noch andere Klassen von Anwendungen.
Das
Unix-System hat eine Programmiermöglichkeit, die besonders in den
Anfangsjahren intensiv genutzt wurde, bevor man mit dem Virtual Memory
Management beliebig große Prozesse schreiben konnte: Die
Shell-Programmierung. Da man mit der eingeschränkten Komplexität
eines einzelnen Prozesses nur ein Segment eines umfangreicheren Problems
bearbeiten konnte, wurde eine Zwischenlösung auf die Pipe ausgeschrieben,
die von dem nächsten Prozess eingelesen und weiterverarbeitet werden
konnte, sobald der erste Datensatz vom ersten Prozess ausgeschrieben war.
Die Shell ist eine ausgezeichntete Basis für das interaktive Rapid
Prototyping, wenn man erst einmal die Benutzung beherrscht. Ein ganz
wesentlicher Vorteil ist aber die Reduktion der Komplexität des
Gesamtproblems, indem genau definierte Zwischenschritte der Verarbeitung
erstellt werden, die in einem permanenten Medium gespeichert werden. Dies
bringt den zusätzlichen Vorteil, daß beim Testen einer
Problemlösung immer auf diese leicht definierten Zwischenschritte
aufgesetzt werden kann.
Das Unix-System hält eine Vielzahl von kleinen, spezialisierten Filterprogrammen bereit, die über Kommandozeilen-Steuerung auf die geforderte Leistung eingestellt werden können. Einige Grundprinzipien des Aktors sind in den Filtern zu finden: Eine mächtige verfügbare Funktionalität, die auf eine kleine Anzahl von Funktionsträgern systematisch verteilt ist, indem jeder Funktionsträger eine umrissene Klasse von Aufgaben bearbeitet; eine interaktive Benutzer-Schnittstelle und eine inkrementelle Konstruktions- und Testmethode.
Die
hier vorgestellte Interaktor Shell ACSh ist das Ergebnis von ca. 10 Jahren
Forschung und Entwicklung in dem Leibniz Projekt des Autors. In diesem Projekt
wurde das Leibniz Software-Entwicklungs-System erstellt, mit der
rapid-prototyping Sprache LPL (Leibniz Programming Language) und der
Interaktor-Shell ACSh. Diese Shell bedient sich einer modernen Philosophie des
Benutzer-Interfaces mit eigenem (Character-) Windowing, frei
benutzer-konfigurierbaren Menus, Hypertext-basiertem Editor, und
kontextsensitiver Hilfs-Funktion. Das gesamte System ist in der Shell-Sprache
LPL erstellt Es enthält ca. 100 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. Die Leistungsfähigkeit
des Aktor-Konzepts läßt sich daran ermessen, daß es
möglich war, das System in Teilzeitarbeit mit einer einzigen Person zu
erstellen, zu warten und zu pflegen.
Ein Ziel des Leibniz-Projekts war die Entwicklung einer interaktiven,
benutzer-anpaßbaren Software-Technologie, als deren Ergebnis die Metapher
des Interaktors entstand. Die Grundlage einer solchen Software-Technologie
liegt in ganz anderen Bereichen als der herkömmlichen Compiler. Sie
basiert auf der optimalen Abstimmung des Software-Gesamt-Systems auf die
Interaktion mit dem Benutzer, und seine konzeptuellen und intellektuellen
Fähigkeiten zu unterstützen und nach Möglichkeit zu erweitern.
Das
Interaktor-Prinzip ergibt 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, die Inter-Aktoren, von denen jeder eine
"Rolle" spielt, und zur Ausführung dieser Rolle ein "Skript"
erhält. Damit steht eine Metapher zur Verfügung, 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.
Der Begriff leitet sich von 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. 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. Aktor-Orientierte Programmierung (AOP)
ist eine Software-Methode, in der Software-Funktionalität durch
Inter-Aktion von Aktoren definiert und implementiert wird. In der Sprechweise
der AOP ist der Operator der menschliche Kommunikationspartner des
Aktors.
Der 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 Lehrers einarbeiten kann.
Ein
wesentlicher Faktor, der in der AOP den Hauptaspekt der Programmierung
ausmacht, ist die Kommunikation der Aktoren miteinander. Dies kann man als
das Paradigma der AOP bezeichnen. Dieses Konzept ist zwar als Messaging
in 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.
Gravierend wird dieser Faktor, wenn man den Menschen als das schwächste
Glied der Kette erkennt. 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.
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 und die Abgrenzung der Verantwortlichkeiten. Aktoren sind eine Methode, eine leicht handhabbare Komplexitäts-Abgrenzung von Software-Modulen zu erreichen. Bei der Definition von Software-Funktion in Aktoren ergibt sich auch eine natürliche Unterteilung in Arbeits-Schritte, die in einem Team auf die Programmierer verteilt werden können. Da ein 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 Aktoren implementiert werden. Die Shell-Programmierung unter Unix ist hier Vorbild.
Mit Aktoren-Skripting 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 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 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 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 Prototyp-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.
Ein wesentlicher Entwicklungsaspekt des Leibniz Projekts ist die Möglichkeit, mit den geringsten Mitteln, also mit normaler, zeichenorientierter Technologie (z.B. Alpha-Window) arbeiten zu können. Es wurde daher ein eigenes Windowing System erstellt, welches lediglich 50 KBytes Code benötigt. Weiterhin ist das System auch standalone, z.B. auf Industrie-Rechnern und embedded Systems einsetzbar. Dies ist in der heutigen Zeit der Rezession sicher ein gewichtiges Argument, wenn man dieselbe Leistung statt mit X-Window Terminals mit billigen ASCII-Geräten erreichen kann.
Im
Bereich der OOP zeichnet sich eine Dominanz von C++ ab. Dies ist aus
kurzfristigen Ökonomiegründen verständlich: Das vorhandene
Know-How Potential der C-Programmierer muß genutzt werden. Es ergibt sich
eine Verbesserung der Software-Produktivität, aber mit dem Nebeneffekt,
daß Tendenzen, die zur jetzigen Situation der Software-Krise geführt
haben, beibehalten und weiter verschärft werden. 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 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 bietet, das 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 auf der Seite der menschlichen (Ergonomie-) Aspekte gezahlt
werden
In Smalltalk sind genau genommen zwei recht verschiedene Ideen von Objekt-Orientierung realisiert worden, die des strukturellen Objekts (also Vererbung, Klassenzugehörigkeit etc.) und die Metapher des anfaßbaren Gegenstands (P:Objekt). Das Aktor-Prinzip baut auf der P:Objekt Metapher von Smalltalk auf. Dies 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 Aktors ist aber seine interaktive Handhabung durch den Benutzer, und die Unterstützung, die dem Benutzer geboten wird, den Umgang inkrementell zu lernen.
Mit der zunehmenden Verwendung von OO-Methoden verlagert sich die Vorgehensweise in der Programmierung von der individuellen Konstruktion von Modulen aus sehr einfachen Bauteilen hin zum Aufbau und Verwendung eines Teilelagers von recht komplexen Teilsystemen. OOP fängt bei der sorgfältigen Konstruktion von Objekt-Libraries an. Ihre Effizienz hängt entscheidend davon ab, wie gut diese 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.
Die konzeptuelle Transparenz für den Durchschnittsmenschen ist der wesentliche Leitfaktor für die Zusammenfassung von verwandten Funktionen in einen 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 Gegenstand mehrmals assoziiert wird, verstärkt sich auch das begriffliche Bild des Menschen von diesem Objekt. Dies ist extrem wichtig für die Eigenschaft des Self-Teaching oder autonom-Lehrens von Systemen. Es muß erreicht werden, daß sich die Konzepte über die Natur und die beste Verwendbarkeit des Aktors im Benutzer "von selbst" bilden, also ohne große Schulung und Einweisung kommen. Das Modell hierfür bieten die Gegenstände des täglichen Gebrauchs.
Die tiefsten und dauerhaftesten Lernerfahrungen des Menschen sind kinesthetisch, 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 Software-Objekt einem physikalischen 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.
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: Zum einen ist hier die Begrenzung des Kurzzeitgedächtnisses auf ca. 5-7 Elemente. Diese Limitation ist im Bereich der Programmierung kritisch, da das interaktive 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.
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.