Prototypen benutzergerechter Computersysteme [Reprint 2019 ed.] 9783110861907, 9783110115307

Citation preview

Mensch Computer Kommunikation 4 Herausgegeben von Helmut Balzert und Gerhard Fischer

Prototypen benutzergerechter Computersysteme Herausgegeben von Rul Gunzenhäuser und Heinz-Dieter Böcker

w DE

G

Walter de Gruyter • Berlin • New York 1988

Prof. Dr. Rul Gunzenhäuser Dr. Heinz Dieter Böcker beide am Institut für Informatik der Universität Stuttgart

CIP-Titelaufnahme

der Deutschen

Bibliothek

Prototypen benutzergerechter Computersysteme / hrsg. von Rul Gunzenhäuser u. Heinz-Dieter Böcker. — Berlin ; New York : de Gruyter, 1988 (Mensch - Computer - Kommunikation ; 4) ISBN 3-11-011530-1 NE: Gunzenhäuser, Rul [Hrsg.]; G T

© Copyright 1988 by Walter de Gruyter & Co., Berlin 30. Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Übersetzung, vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (durch Photokopie, Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des Verlages reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. — Printed in Germany. Dieses Buch wurde mit dem Textsystem Scribe™ erstellt. Formatierung: Harald von der Herberg. Druck: Gerike GmbH, Berlin. — Bindearbeiten: Dieter Mikolai, Berlin. — Umschlagentwurf: Hansbernd Lindemann, Berlin.

Vorwort Der vorliegende Band berichtet an Hand von 13 Einzelbeiträgen über unterschiedliche Prototypen benutzergerechter Computersysteme. Sie entstanden seit 1985 in der Forschungs- und Arbeitsumgebung des Forschungsvorhabens INFORM am Institut für Informatik der Universität Stuttgart und am Department of Computer Science der University of Colorado in Boulder, USA, in denen ihre Autoren als Projektleiter und Mitarbeiter zusammenwirken. Seit 1981 wird die Stuttgarter Forschungsgruppe vom Bundesminister für Forschung und Technologie (BMFT) gefördert; seit 1985 arbeitet sie im Rahmen des Verbundvorhabens WlSDOM mit der Forschung von Triumph Adler, der Gesellschaft für Mathematik und Datenverarbeitung und anderen wissenschaftlichen Instituten erfolgreich zusammen. Die Arbeit von INFORM konzentriert sich auf die wissensbasierte MenschComputer-Kommunikation (MCK). Dieses Fachgebiet wurde von ihr mitgeprägt und konnte in den letzten Jahren wichtige Konzepte aus der anwendungsorientierten Informatik, der Software-Ergonomie und der kognitiven Psychologie weiterentwickeln und in interdisziplinärer Forschung und Entwicklung erfolgreich anwenden. Die Forschungsgruppe in Boulder entstand 1985 durch die Berufung von Prof. Dr. Gerhard Fischer, dem wissenschaftlichen Initiator von INFORM, an die dortige Universität. Neben eigenen Vorhaben im Bereich der Kognitionswissenschaften wird dort erfolgreich Forschung und Entwicklung im Bereich der wissensbasierten MCK in enger Kooperation mit Stuttgart weitergeführt. Dieser Band steht auch in engem Zusammenhang mit der Monographie „Methoden und Werkzeuge zur Gestaltung benutzergerechter Computersysteme" [Fischer, Gunzenhäuser 86], in der 1986 grundlegende Konzepte, Methoden und Forschungsergebnisse der wissensbasierten MCK wie • • • • •

objektorientierte Wissensrepräsentation, anwendungsneutrale Benutzerschnittstellen, Fenster- und Menüsysteme, Visualisierungstechniken der MCK, Software-Dokumentationssysteme,

VI

Vorwort • Systemkomponenten zum Wissenserwerb und • computerunterstützte Planungsprozesse

publiziert wurden.

Dieser Band spiegelt die inhaltliche Arbeit der Projekt-

gruppe INFORM bis Ende 1984 wider. Die vorliegende Monographie konkretisiert diese Inhalte durch die Darstellung prototypischer Anwendungen benutzergerechter Computersysteme. Ihre Herausgeber und ihre Autoren wollen damit unterstreichen, daß es nicht allein ausreicht, geeignete Konzepte und Methoden für benutzergerechte Anwendungen zu entwickeln. In einem stark experimentell voranschreitenden Forschungsbereich wie der MCK müssen vielmehr aussagekräftige prototypische Anwendungssysteme gebaut werden, damit fundierte Einblicke in die notwendigen und die realisierbaren Eigenschaften zukünftiger benutzergerechter Computeranwendungen gewonnen werden können. Der Band wendet sich an Informatiker und Software-Ingenieure, an Wissenschaftler und Studenten sowie an alle interessierten Anwender, die sich einen Uberblick über den gegenwärtigen Stand der Forschung und Entwicklung im Bereich der wissensbasierten MCK erarbeiten wollen. Die dargestellten Prototypen sollen ihnen Anregungen für die Konstruktion von Benutzerschnittstellen vermitteln und gleichzeitig Maßstäbe für die kritische Bewertung solcher Dialogsysteme liefern. Die Herausgeber und Autoren des vorliegenden Bandes danken dem Verlag für seine Bereitschaft, ihn als zweiten Band der Forschungsgruppe INFORM in die Reihe „Mensch-Computer-Kommunikation" aufzunehmen. Sie danken Thomas Fehrle, Dietmar Freiburg, Ulrich Hoppe, Thomas Knopik, Bettina Oeding, Ina Rubbert, Norbert Streitz, Thomas Strothotte und Gerhard Weber für ihre fundierte Kritik am Manuskript. Ihr Dank gilt auch dem BMFT, der Gesellschaft für Mathematik und Datenverarbeitung, dem Institut für Informatik der Universität Stuttgart, der Fa. Triumph Adler sowie einer Vielzahl von Kollegen und Freunden für deren langjährige Unterstützung und Förderung. Besonders Gerhard Fischer hat Uber viele Gespräche und gemeinsame Diskussionen einen nicht unerheblichen Anteil zu den hier dargestellten Arbeiten und Ideen beigetragen. Nicht unerwähnt sollen auch die Studenten bleiben, die die Arbeitsumgebung der Forschungsgruppe INFORM wesentlich mitgeprägt haben und deren Ideen sich an vielen Stellen dieses Buches wiederfinden. Besonderen Dank verdient auch Dieter Holz, der die Piktogramme zu den einzelnen Kapiteln erstellt hat.

Inhaltsverzeichnis

I Einführung Heinz-Dieter Systeme

zur

1 Böcker, Rul

Gunzenhäuser

Entwurfsunterstützung

II EL AB Direkt manipulative Simulation elektrischer Schaltungen Michael Herczeg III TRANSPLAN

19

35

Computerunterstützte Planung von Warentransporten Dieter Maier TV FINANZ

55

Anpassung von Finanzplänen durch den Endbenutzer Christian Rathke

S y s t e m e zur

Dialogunterstützung

V OTELLO

75

Einsatz eines Textformatierers als Grundlage eines passiven Hilfesystems Joachim Bauer VI PASSIVIST

89

Ein natürlichsprachliches Hilfesystem für einen Texteditor Andreas Lemke VII AKTIVIST

105

Eine aktive Hilfekomponente für einen Texteditor Thomas Schwab VIII WLSYBIB Einsatz von Undo/Redo-Mechanismen bei der Verwaltung einer Literaturdatenbank Martin Rathke

127

Inhaltsverzeichnis

VIII

S y s t e m e zur

Programmierunterstützung

IX OPTIMIST Ein System zur Beurteilung und Verbesserung von Lisp-Code Heinz-Dieter Böcker

151

X INSPECTOR Ein Navigationswerkzeug zur Untersuchung von Objektstrukturen Harald von der Herberg

169

XI ZOO Ein Werkzeug zur Gestaltung von Anwendungssystemen durch den Endbenutzer Wolf-Fritz Riekert

187

XII OBJBASE Ein System zur Strukturierung und Verwaltung von Wissen Dorothea Bauer Baukästen

für

201

Benutzerschnittstellen

X3II VISIVAL Ein Baukasten für Bildschirm-Instrumente Michael Herczeg

229

XIV TRISTAN Ein generischer Editor für gerichtete Graphen Helga Nieper-Lemke

243

Verzeichnisse Literaturverzeichnis

261

Autorenverzeichnis

273

Glossar

277

Index

283

I Einführung Heinz-Dieter Böcker, Rul Gunzenhäuser

1. B e n u t z e r s c h n i t t s t e l l e n

heute

Dies ist ein Buch über benutzergerechte Systeme. Ob ein Computersystem benutzergerecht ist, hängt wesentlich davon ab, wie es sich seinen Benutzern präsentiert; daher ist dies vor allem ein Buch über Benutzerschnittstellen. Die Architektur wissensbasierter Mensch-Computer-Kommunikation (siehe Abbildung 1) umfaßt das Anwendungssystem, seine Benutzerschnittstelle und verschiedene Typen unterstützender Systeme. Die Kommunikation des Benutzers mit der Anwendung findet über eine Benutzerschnittstelle statt. In neueren Systemen ist diese in der Regel als fenster- und menüorientierte Schnittstelle [Fabian 86] ausgebildet, wie sie auch alle in diesem Band vorgestellten Systeme verwenden. Während der Bau von Anwendungen in den klassischen Bereich der Informatik fällt, stellen die unterstützenden Systeme eine natürliche Weiterentwicklung der im Bereich Mensch-Computer-Kommunikation gelegten Grundlagen zum Bau von Benutzerschnittstellen dar. Moderne Softwaresysteme wie Programmierumgebungen, Editoren, Textformatier- und Datenbanksysteme stellen ihren Benutzern eine sehr große Funktionalität zur Verfügung. Probleme bei der optimalen Nutzung dieser Software-Werk zeuge können durch verschiedene Faktoren verursacht sein (vgl. auch [Fischer 87a]): • Umfang der Funktionalität. Der Benutzer kennt nur einen Teil der vom Systemdesigner bereitgestellten Werkzeuge. • Zugriff auf die Funktionalität. Der Benutzer weiß nicht, wie er benötigte Werkzeuge oder Informationen darüber findet. •

Anwendungsbedingungen. Der Benutzer kennt nicht alle Bedingungen, unter denen die Werkzeuge (oder Kombinationen davon) angewendet werden können.

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter & Co. • Berlin • N e w York

2

Abbildung 1.

Prototypen benutzergerechter Computersysteme

Architektur wissensbasierter MCK.

3

Einführung •

Anpassungen. Der Benutzer weiß nicht, wie er die Werkzeuge seinen Bedürfnissen und Aufgaben anpassen kann.

• Verstehen der Ergebnisse. Der Benutzer hat Schwierigkeiten Werkzeug gelieferten Ergebnisse.

bei

der

Interpretation

der

vom

Zwischen der Funktionalität der Anwendung, der Qualität der Benutzerschnittstelle und den unterstützenden Systemen bestehen enge Verbindungen und Wechselwirkungen: • Eine erweiterte Funktionalität der Anwendung stellt erhöhte Anforderungen an die Benutzerschnittstelle und die (die Nutzung der Anwendung) unterstützenden Systeme. • Bei gutem Design der Benutzerschnittstelle können unterstützende Systeme überflüssig werden. • In realen Systemen lösen oftmals unterstützende Systeme die Probleme, die nicht mit den Mitteln der Benutzerschnittstelle gelöst werden konnten. Die bestehenden Wechselwirkungen zwischen der Benutzerschnittstelle und den unterstützenden Systemen kommen auch durch die gemeinsam benutzten Techniken und Verfahren zum Ausdruck. Erklärungskomponenten, Visualisierungstechniken sowie Techniken zum Verstehen und zur Generierung natürlicher Sprache sind z.B. in allen unterstützenden Systemen in gleicher Weise verwendbar.

1.1 E i g e n s c h a f t e n v o n

Benutzerschnittstellen

Die Aufgabe von Benutzerschnittstellen ist es, die Benutzung eines Werkzeugs problemlos zu gestalten. Im Idealfall sollte ein Benutzer mit intuitivem Vorverständnis des Anwendungsbereiches in der Lage sein, ein Anwendungssystem zu bedienen. Ein wichtiges Mittel zur Verringerung der auftretenden Bedienkomplexität stellt dabei die Technik der „direkten Manipulation" dar, die in zwei verwandten Formen auftritt: 1. Direkte Manipulation in Form unmittelbarer Auswirkung von Benutzeraktionen. Das Drücken einer Taste auf der Tastatur führt direkt zur Einfügung eines Buchstabens in einen Text, eine Bewegung der Maus auf der Schreibunterlage ist direkt mit der Bewegung der Maus auf dem Bildschirm gekoppelt.

4

Prototypen benutzergerechter Computersysteme 2. Direkte Manipulation als Mensch-Problem-Kommunikation. Der Benutzer ist nicht an der Kommunikation als solcher, sondern an der Lösung eines inhaltlichen Problems interessiert; die Kommunikation mit dem Computer ist nur Mittel zum Zweck. In dieser Sichtweise sind die auf dem Bildschirm dargestellten Objekte des Bildschirms die Objekte der Anwendung und nicht nur ihre Repräsentanten.

Voraussetzung für die Technik der direkten Manipulation sind Techniken zur Visualisierung von Objekten oder Prozessen; sie unterstützen die Mensch-Problem-Kommunikation auf realistische Weise. Daher sind Visualisierungstechniken ebenso wie die direkte Manipulation wichtige Merkmale der Benutzerschnittstellen der in diesem Band vorgestellten Systeme.

1.2 U n t e r s t ü t z e n d e

Systeme

Benutzerschnittstellen verfügen über unterschiedlich ausgeprägte zungskomponenten, die man wie folgt unterscheiden kann:

Unterstüt-

• Tutorielle Komponenten. Sie dienen dazu, Benutzer erstmals mit neuen Konzepten und neuer Funktionalität vertraut zu machen. Wertvolle Grundlagen hierfür hat die Arbeitsgruppe um J.S. Brown geschaffen (siehe etwa [Burton 82; Burton, Brown 82]), wobei dem Paradigma der increasingly complex microworlds [Burton, Brown, Fischer 84] große Bedeutung zukommt. • Kritisierende Systeme. Sie zeichnen sich dadurch aus, daß in der Interaktion zwischen Mensch und Computer die primäre ,,Hörerrolle" vom Computer ausgefüllt wird. Der Benutzer arbeitet an dem von ihm selbst gewählten inhaltlichen Problem, die Kritik des Computers bezieht sich auf die Art der Lösung dieses Problems. Es ist offensichtlich, daß hier das Erkennen der vom Benutzer verfolgten Ziele und die Modellierung des Wissensstandes des Benutzers unabdingbare Voraussetzung sind. Im System OPTIMIST (Kapitel IX) werden Ideen dieser Art für den Bereich der Lisp-Programmierung untersucht. • Aktive und passive Hilfesysteme. Sie bilden die älteste Form unterstützender Systeme und sind auch bei relativ einfachen Werkzeugen sinnvoll. Bei passiven Hilfesystemen muß der Benutzer explizit Hilfe anfordern; die Initiative liegt beim Benutzer. Sie gehören heute - wenn auch oft nur in relativ einfacher Form - zu den Standardtechniken der Mensch-Computer-Kommunikation. Aktive Hilfesysteme sind Systeme, die das Verhalten des Benutzers beobachten und von sich aus tätig werden. Ihrem praktischen Einsatz stehen noch fehlende konzeptionelle Grundlagen im Bereich der Wissensrepräsentation und hohe Anforderungen an die Rechengeschwindigkeit entgegen. Die Kapitel VI und VII beschreiben die Sy-

5

Einführung steme PASSIVIST und AKTIVIST, zwei prototypische beiden Arten von Hilfesystemen. •

Vertreter

dieser

Navigationswerkzeuge. Sie unterstützen die Exploration der in einem komplexen System enthaltenen Funktionalität durch den Benutzer und stehen damit den passiven Hilfesystemen sehr nahe; meist handelt es sich bei solchen Werkzeugen um spezialisierte, durch Grafik unterstützte Systeme zum Navigieren durch Netze, deren Knoten abgeschlossene Informationseinheiten darstellen. Der in Kapitel X dargestellte INSPECTOR und das in Kapitel XI beschriebene System ZOO beinhalten derartige Navigationsmöglichkeiten.

• Intelligente Baukästen. Intelligente Baukästen vereinfachen den Umgang mit einem Werkzeug dadurch, daß sie einen Teil seiner Funktionalität vor dem Benutzer verstecken, indem sie Standardlösungen anbieten, die vom Benutzer modifiziert werden können. G. Fischer und A. Lemke [Fischer, Lemke 88a] diskutieren Beispiele derartiger Systeme; der P r o t o t y p TRISTAN ist in Kapitel XIV dargestellt. In der Praxis bestehen zwischen solchen Unterstützungskomponenten fließende Übergänge; manche Unterscheidung ist nur historisch gerechtfertigt.

Die

Herausforderung liegt in der Integration der verschiedenen Komponenten.

1.3 V o n i n t e r a k t i v e n zu i n t e l l i g e n t e n

Systemen

Der Idee, unterstützende Systeme als integrale Bestandteile eines Softwaresystems aufzufassen, liegt die Vorstellung zugrunde, daß Mensch und Computer gemeinsam ein Problem aus einem Anwendungsbereich lösen. Computernutzung wird unter dieser Zielsetzung mit dem Schlagwort „Kooperatives Problemlösen" beschrieben. Es betont den Aspekt des gemeinsamen Verfolgens eines (vom Menschen vorgegebenen) Zieles. Weder ist der Computer die große Maschine, die alle Probleme automatisch löst, noch ist einzig der Mensch derjenige, der ein Problem intelligent bearbeiten kann. Viele der in diesem Buch vorgestellten Systeme vertrauen zur Lösung eines Problems auf diese kooperative Vorgehensweise, in die Mensch und Computer jeweils ihre Stärken einbringen. Computer als „intelligente Assistenten" zu verstehen, ist ein Gedanke, der für die Gestaltung der Kommunikation genutzt werden kann:

Die K o m m u -

nikation zwischen Mensch und Computer sollte qualitativ einer (nicht

notwendigerweise

Menschen entsprechen.

natürlichsprachlichen)

Kommunikation

natürlichen zwischen

Sie ist u.a. durch ein Verstehen der kommunizier-

ten Inhalte, durch Fragen, Unterbrechungen, Stellungnahmen und Kritik so-

6

Prototypen benutzergerechter Computersysteme

wie durch wechselnde Initiative der Kommunikationspartner gekennzeichnet. Daraus leiten sich konkrete Kriterien zur Gestaltung von Softwaresystemen ab. Wir haben einige dieser Aspekte in den hier vorgestellten Systemen in Ansätzen realisiert.

2. Die Forschungsgruppe INFORM 2.1 INFORM 1981 - 1984 Das Forschungsvorhaben geht zurück auf einen Antrag von H.-D. Böcker, G. Fischer und R. Gunzenhäuser am Institut f ü r Informatik der Universität Stuttgart an den Bundesminister für Forschung und Technologie. Sein Inhalt war, integrierte Informationsmanipulationssysteme zur Unterstützung der Mensch-Computer-Kommunikation zu untersuchen, sowie einzelne Komponenten für solche Dialogsysteme zu entwerfen und prototypisch zu implementieren. Das P r o j e k t verdankt seinen Namen dem Begriff / n / o r m ationsmanipulationssystem. Darunter verstanden die Antragsteller ein Dialogsystem, das eine einheitliche und kooperative Benutzerschnittstelle für so unterschiedliche Aufgaben wie Textverarbeitung, elektronische Post, Formular- und Graphikverarbeitung, Programmieren, Erstellen von Programmdokumentationen und rechnerunterstütztes Lernen mit Hilfesystemen bietet. Die Ergebnisse des ersten Projektabschnittes (1981 und 1982) bestehen u.a. aus prototypischen

Implementierungen Formularsystems

eines bildschirmorientierten

und

einer

Editors,

eines

interaktiven

Lisp.

Kennzeichnend für diese Prototypen ist die konsequente Verwendung

Programmierumgebung

für

eines selbstentwickelten Fenstersystems zur Gestaltung von Benutzerschnittstellen. Das Forschungsvorhaben wurde ab 1983 unter dem Titel „Entwicklung von Methoden und Werkzeugen zur Verbesserung der Mensch-Maschine-Kommunikation" mit Förderung durch das B M F T fortgeführt. Über seine Ergebnisse, die von 1983 bis Anfang 1985 unter wissenschaftlicher Leitung von G. Fischer entstanden sind, wird in G. Fischer, R. Gunzenhäuser (Herausgeber): „ M e t h o d e n und Werzeuge zur Gestaltung benutzergerechter Computersysteme", dem ersten Band der vorliegenden Buchreihe, berichtet.

Einführung

7

2.2 INFORM in WlSDOM Das Forschungsprojekt INFORM bildet derzeit gemeinsam mit Vorhaben der Firma TA Triumph Adler AG (Nürnberg), des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation (Stuttgart), der Gesellschaft für Mathematik und Datenverarbeitung (St. Augustin), dem Institut für Informatik der Technischen Universität München und der Firma Systemtechnik Berner & Mattner (München) das vom BMFT bis Ende 1988 geförderte Verbundvorhaben WlSDOM.

Gemeinsames Ziel ist die Entwicklung von prototypischen wissensbasierten Systemen, die den Benutzern von Arbeitsplatzrechnern umfangreiche Systemunterstützung im Bürobereich bieten. Die Forschungsgruppe INFORM erarbeitet im Rahmen des Projektes Grundlagen für die zu entwickelnden Prototypen, auf denen sich dann die experimentellen Systementwicklungen der Projektpartner abstützen können. Diese Grundlagenforschung umfaßt im wesentlichen • die anwendungsneutrale Mensch-Computer-Kommunikation auf der Basis eines Fenstersystems mit Konzepten zur Verwaltung und Visualisierung des Dialoggeschehens, • den Einsatz prototypischer Hilfesysteme, • die Weiterentwicklung der Sprache ObjTalk, die durch G. Fischer, J. Laubsch und C. Rathke in Stuttgart zur Wissensrepräsentationssprache entwickelt wurde [Fischer, Laubsch 79; Laubsch, Rathke C. 83; Rathke C. 86a] sowie • die objektorientierte Modellierung und Akquisition von Wissen. Schließlich werden Grundlagen für prototypische Systeme zur Planungsunterstützung erarbeitet.

2.3 D i e A r b e i t s u m g e b u n g Die Arbeitsumgebung der Forschungsgruppe INFORM stellt eine Experimentalumgebung zur Umsetzung von neuen Ideen über interaktive Systeme in konkrete lauffähige Programme dar. Bei allen in diesem Labor entwickelten Systemen steht die Suche nach neuen, alternativen Lösungen für konkrete Probleme - nicht für im Elfenbeinturm erfundene Aufgabenstellungen im Vordergrund.

8

P r o t o t y p e n benutzergerechter

Der sofortigen Umsetzung der entstandenen

Computersysteme

Systeme in ein

kommerzielles

P r o d u k t steht entgegen, daß sie in einer äußerst aufwendigen, wenig verbreiteten S o f t w a r e u m g e b u n g entstanden sind.

Allerdings n i m m t die Distanz

zur industriellen Praxis mit der zunehmenden Verbreitung von Mikrorechnern u n d den erkennbaren Standardisierungstendenzen im Bereich der Fenstersysteme deutlich ab.

Die Ideen, die im Z u s a m m e n h a n g einzelner Syste-

me erprobt worden sind, tragen Merkmale guter Ubertragbarkeit.

Hardware Sämtliche beschriebenen Rechnerumgebung 1

prototypischen

entstanden,

Systeme sind in einer

bestehend

aus

einer

VAX

Teilnehmer11/780

und

„intelligenten" DIN-A4-formatigen Rasterbildschirmen, die j e d e m Mitarbeiter als normaler Bestandteil seines Arbeitsplatzes zur Verfügung stehen.

Die

Geräte sind jeweils mit 512 kB Speicher, T a s t a t u r u n d einer dreiknöpfigen Maus als E i n g a b e i n s t r u m e n t ausgestattet.

Software Die Abbildung 2 zeigt schematisch den A u f b a u der verwendeten Software. Die WLISP-Programmierumgebung

[Böcker,

Fabian,

Lemke

85]

stellt

G r u n d s o f t w a r e der in diesem Band beschriebenen Systeme bereit. eine erweiterte FranzLisp-Umgebung

[Foderaro, Sklower 8 2 ] .

die

Sie ist

Die Grundla-

gen hierzu sind von C. R a t h k e mit der objektorientierten Sprache O b j T a l k [ R a t h k e C. 86b; R a t h k e C. 86a] und von F . F a b i a n mit einem Fenstersystem [ F a b i a n 86] gelegt worden.

Darauf b a u t ein Software-Baukasten zur

Erstellung von Benutzerschnittstellen auf, der eine Vielzahl von miteinander integrierten

Komponenten

zur Mensch-Computer-Interaktion

enthält:

Me-

nüs, Sheets, Buttons, Icons, Browser, Cluster, Lifts, F o r m u l a r e , Netz- u n d Zeicheneditoren.

In WLISP laufen die unterschiedlichen Werkzeuge der Pro-

grammierumgebung

(z.B. Ein-/Ausgabeschleife, schrittweise A u s f ü h r u n g von

P r o g r a m m e n , Fehlersuche) in separaten Fenstern ab. Zwischen

ObjTalk

Abhängigkeiten. tionssprache

des

und

dem

Fenstersystem

bestehen

starke

Einerseits ist O b j T a l k neben FranzLisp die für

WLISP

grundlegenden

macht die P r o g r a m m i e r u m g e b u n g

wechselseitige Implementa-

Fenstersystems,

von O b j T a l k selbst intensiven

andererseits Gebrauch

Inzwischen haben sich viele der in diesem Buch beschriebenen Komponenten und Systeme nach ihrer Übertragung auf Symbolics Lisp-Maschinen unter Ausnutzung der dort vorhandenen Möglichkeiten weiterentwickelt.

Einführung

9

Anwendungen Interaktionsobjekte ObjTalk

WLisp

FranzLisp

Abbildung 2.

Die INFORM-Softwarearchitektur.

von eben diesem Fenstersystem. Erweiterungen

von FranzLisp sind, deren F u n k t i o n a l i t ä t ausschließlich

Lisp-Funktionen

bereitgestellt

samtarchitektur

hat

die

d u k t möglich gemacht. ter

anwenden,

Ermöglicht wird dies d a d u r c h , d a ß beides

wird.

über

Die einheitliche o b j e k t o r i e n t i e r t e

INFORM-Softwareumgebung

als

Ge-

Gemeinschaftspro-

Jeder k a n n die S o f t w a r e p r o d u k t e anderer Mitarbei-

vorläufige,

einfache

Lösungen

von

Teilproblemen

können

d u r c h bessere ersetzt werden, sobald solche v e r f ü g b a r werden.

Umfeld - Auswirkungen Die internationalen K o n t a k t e der Forschungsgruppe INFORM h a b e n insbesondere

zu

einer

intensiven

Zusammenarbeit

mit

der

Arbeitsgruppe

von

G. Fischer an der University of Colorado in Boulder, USA, g e f ü h r t , m i t der seit 1985 ein reger Austausch von Ideen, M a n u s k r i p t e n , Software u n d Wissenschaftlern besteht.

C. R a t h k e , einer der A u t o r e n dieses Bandes, a r b e i t e t

seit 1985 in Boulder, ebenso die A u t o r e n A. Lemke u n d H. Nieper-Lemke, beide Absolventen der S t u t t g a r t e r I n f o r m a t i k . Unsere S t u t t g a r t e r

„Vision", d u r c h F o r s c h u n g u n d experimentelle

Entwick-

lungen im Bereich der wissensbasierten M e n s c h - C o m p u t e r - K o m m u n i k a t i o n benutzergerechten

Computersystemen

J a h r e n ein Stück näher g e k o m m e n :

zu k o m m e n ,

sind wir in den

zu

letzten

In S t u t t g a r t - wie auch in Boulder -

ist eine „kritische Masse" an engagierten j u n g e n Wissenschaftlern, eine Arbeitsumgebung, finanzielle U n t e r s t ü t z u n g d u r c h das B M F T und einschlägige I n d u s t r i e p a r t n e r sowie zunehmendes Interesse von Industrie, richtungen u n d kritischer Öffentlichkeit v o r h a n d e n .

Forschungsein-

10

Prototypen benutzergerechter Computersysteme

3. Überblick und Einordnung der Beiträge Im vorliegenden Band

werden

insgesamt

13 Prototypen

benutzergerechter

Anwendungssysteme von Wissenschaftlern des Forschungsvorhabens INFORM vorgestellt. 1.

Alle Beiträge sind etwa wie folgt aufgebaut:

Einleitung. Hier erfolgt eine Einführung in die Aufgabenstellung innerhalb der das prototypische System unterstützend angewandt werden kann.

2. Sicht des Benutzers. Durch die Benutzerschnittstelle und den Ablauf einer wird das System exemplarisch dargestellt.

Beispielsitzung

3.

Funktionalität. Hier wird die Architektur und die Arbeitsweise des Prototyps dargestellt sowie seine Schnittstellen zu anderen Systemen und innerhalb eines „Benutzerschnittstellen-Baukastens" beschrieben.

4.

Konzeption. Konzeptionelle Besonderheiten beim Systementwurf und bei der Implementierung werden festgehalten und Verallgemeinerungen der benutzten Methoden dargestellt.

5. Erfahrungen und Ausblick. Zusammenfassend werden Vergleiche mit bisherigen Anwendersystemen gezogen.

und

zukünftigen

Die dargestellten Prototypen konzentrieren sich auf vier Anwendungsbereiche interaktiver Computersysteme: • • • •

die Entwurfsunterstützung, die Dialogunterstützung, die Programmierunterstützung und Baukästen für Benutzerschnittstellen.

Im ersten Beitrag berichtet M. Herczeg über ELAB, ein System zum Konfigurieren und zur direkten Manipulation elektrischer Schaltungen.

Mit ELAB

kann demonstriert werden, wie Laboraufgaben auf dem Bildschirm in nahezu gleicher Weise gelöst werden. Der Benutzer - z.B. ein Elektrotechniker - sieht auf dem Bildschirm ein Experimentierfeld mit ihm vertrauten elektronischen Bauteilen und ten.

Durch direktes Manipulieren dieser Objekte baut er eine

auf und testet sie unmittelbar in der Simulationsumgebung.

MeßgeräSchaltung

Die aus dem

Bürobereich bekannt gewordene Desktop-Metapher wird hier in eine LaborMetapher übertragen.

Einführung

11

Der Beitrag von D. Maier beschreibt TRANSPLAN, ein System zur P l a n u n g von W a r e n t r a n s p o r t e n .

Er geht dabei auf so grundlegende Aspekte ein wie

interaktives P l a n e n , paralleles Verfolgen alternativer Vorgehensweisen, Überw a c h u n g von R a n d b e d i n g u n g e n sowie den Einsatz von Verfahren zur automatischen Plangenerierung und ihrer Simulation. Die Vorteile der objektorientierten Implementierung von werden in diesem Beitrag deutlich. pische Arbeitsteilung

zwischen

Planungsprozessen

F ü r die bei P l a n u n g e n herrschende ty-

Mensch

(als Disponent)

und

Maschine

(als

P l a n u n g s i n s t r u m e n t ) k o m m t , wie der Beitrag zeigt, der Gestaltung der Benutzerschnittstelle besondere B e d e u t u n g zu. Der von C. R a t h k e im folgenden geschilderte P r o t o t y p FINANZ e r l a u b t das interaktive

Erstellen

und

Modifizieren

formularorientierter

Anwendungen.

(Bildschirm-)Formulare sind eine grundlegende F o r m f ü r die Interaktion zwischen Benutzern u n d zahlreichen A n w e n d u n g e n , wie auch die populären T a bellenkalkulationsverfahren zeigen. FINANZ geht wesentlich Uber die F u n k t i o n a l i t ä t solcher Systeme hinaus, z.B. durch eine o b j e k t o r i e n t i e r t implementierte deklarative Festlegung von

mul-

tiplen Abhängigkeiten zwischen F o r m u l a r f e l d e r n u n d die automatische, wissensbasierte B e h a n d l u n g von Konflikten. Die meisten B e n u t z e r h a n d b ü c h e r werden schon heute r e c h n e r u n t e r s t ü t z t stellt. cherten

er-

Wie der Beitrag von J. Bauer zeigt, können die d a f ü r on-line gespeiInformationen

genutzt werden,

um dem

Benutzer

auch

interaktiv

Hilfe anzubieten. Aus einem f ü r einen T e x t f o r m a t i e r e r erstellten M a n u s k r i p t erzeugt das System OTELLO Beschreibungsdateien f ü r ein passives, interaktives Hilfesystem. Es bietet

in seiner

Benutzung

alle F u n k t i o n e n ,

die

auch

ein

gedrucktes

Buch aufweist wie B l ä t t e r n , Nachgehen von Verweisen sowie die B e n u t z u n g unterschiedlicher Verzeichnisse u n d d a r ü b e r hinaus das effiziente E r m i t t e l n und A u f f i n d e n von Suchbegriffen im Text. ser A r t

werden

sich

umso

rascher

Elektronische H a n d b ü c h e r

durchsetzen,

kurzlebiger die f ü r R e c h n e r a n w e n d u n g e n

je

umfangreicher

die-

und

benötigten D o k u m e n t a t i o n e n

je

wer-

den. A. Lemke beschreibt im Anschluß d a r a n den P r o t o t y p eines passiven, n a t ü r lichsprachlichen Hilfesystems für einen Texteditor.

Solche Hilfesysteme be-

nötigen Wissen sowohl über das Anwendungsgebiet wie auch über das Anwendungssystem, bei dessen G e b r a u c h der Benutzer u n t e r s t ü t z t werden soll.

12

Prototypen benutzergerechter

Das von

A. L e m k e

implementierte

b e s t e h t aus vier P h a s e n : ihrer

syntatischen

Antwort.

und

Computersysteme

geschilderte Hilfesystem

PASSIVIST

der morphologischen Analyse der B e n u t z e r e i n g a b e ,

Analyse,

der

Problemlösung

Der Beitrag d i s k u t i e r t d a r ü b e r

Präsentation

der

hinaus allgemeine K o n z e p t e

und

der

und

A u f g a b e n f ü r passive Hilfesysteme d e r Z u k u n f t . E b e n f a l l s m i t einem Hilfesystem f ü r T e x t e d i t o r e n von T . Schwab.

Beitrag

W ä h r e n d einer Dialogsitzung gibt sein P r o t o t y p AKTIVIST

von sich aus den B e n u t z e r n a k t i v e Hilfe. selten

b e f a ß t sich d e r

durchgeführten Aktionen

den

E r weist beispielsweise bei relativ

Benutzer

auf

noch

unbekannte

Kom-

m a n d o s hin, die seine A r b e i t v e r e i n f a c h e n . T. Schwab schreibt

geht

auf

die P r o b l e m a t i k

solcher

aktiven

Hilfen ein

die Arbeitsweise von AKTIVIST beim E r k e n n e n

u n d B e w e r t e n von B e n u t z e r k o m m a n d o s .

von

und

be-

Editierplänen

E r schildert detailliert die A n w e n -

d u n g eines Benutzermodells u n d die i m p l e m e n i e r t e Hilfestrategie. Bei der

interaktiven

Bearbeitung

von

Aufgaben

mit

einem

Rechnersystem

k o m m t es h ä u f i g zu S i t u a t i o n e n , in d e n e n der R e c h n e r ein E r g e b n i s p r ä s e n tiert, d a s nicht den E r w a r t u n g e n des B e n u t z e r s e n t s p r i c h t . solchen S i t u a t i o n h e r a u s z u k o m m e n , stand

U m a u s einer

ist es w ü n s c h e n s w e r t , in den

vor A u s f ü h r u n g des zuletzt b e a r b e i t e t e n

Systemzu-

Interaktionsschrittes

zurück-

z u k e h r e n u n d von d o r t a u s neu zu b e g i n n e n . Der B e i t r a g von M. R a t h k e b e s c h r e i b t a u s g e h e n d von Alltagsbeispielen Einsatz von Undo ( d e m S t o r n i e r e n a u s g e f ü h r t e r A k t i o n e n ) u n d R e d o

den (dem

W i e d e r h o l e n a u s g e f ü h r t e r A k t i o n e n ) u n d w e n d e t diese M e c h a n i s m e n bei d e r V e r w a l t u n g der L i t e r a t u r d a t e n b a n k

WlSYBIB an.

Eine größere Klasse

von

A n w e n d u n g e n solcher M e c h a n i s m e n sieht er in Hilfesystemen sowie in Lehrund Lernsystemen. M e h r e r e p r o t o t y p i s c h e S y s t e m e zur P r o g r a m m i e r u n t e r s t ü t z u n g schließen sich an.

Der Beitrag von H.-D. Böcker b e s c h r e i b t den P r o z e ß des P r o g r a m m i e -

rens u n d des P r o g r a m m i e r e n l e r n e n s als k o o p e r a t i v e n P r o b l e m l ö s e p r o z e ß schen M e n s c h u n d Maschine.

zwi-

D e m R e c h n e r k o m m t dabei neben e i n f a c h e r e n

R o u t i n e a u f g a b e n a u c h die Rolle des die A k t i o n e n des B e n u t z e r s

kritisieren-

den P a r t n e r s zu. Im P r o t o t y p e n OPTIMIST wird ein L i s p - P r o g r a m m i e r e r d u r c h kritische K o m m e n t i e r u n g der von i h m erstellten P r o g r a m m e u n t e r s t ü t z t ; er ist Teil einer L i s p - U m g e b u n g , wie sie von S t u d e n t e n w e n d e t wird.

z.B. a m I n s t i t u t f ü r I n f o r m a t i k ver-

Die Regeln von OPTIMIST verfolgen dabei das Ziel, die Q u a -

Einführung

13

lität, d.h. die Verständlichkeit und den „Stil" eines Lisp-Programms zu verbessern.

Durch ein (fiktives) Szenario schildert der Autor sein in Planung

befindliches erweitertes System zur Kritik von CommonLisp-Programmen. Sämtliche im Buch dargestellten Prototypen sind objektorientiert implementiert. Eine der wichtigsten Tätigkeiten beim (objektorientierten) Programmieren ist das Untersuchen bestehender Objektstrukturen. Zu diesem Zweck hat sich in objektorientierten Programmierumgebungen eine spezielle Art von Werkzeug herausgebildet, die als Navigations- oder Browsingwerkzeuge bezeichnet werden. INSPECTOR ist ein von H. von der Herberg entwickeltes Navigationswerkzeug zur Untersuchung von Objektstrukturen der Sprache ObjTalk. Sein Beitrag enthält Uber die Darstellungen der prototypischen Entwicklungen hinaus allgemeine Aspekte der Funktionalität solcher Programmierwerkzeuge, wie z.B. die Rolle von Filtern für solche Browser. W.-F. Riekert beschreibt in seinem Beitrag den von ihm entwickelten und implementierten Wissenseditor ZOO. In einer Wissensbasis sind Fakten und Konzepte eines Anwendungsgebietes repräsentiert. Diese Wissensbasis erscheint f ü r den Benutzer als eine Netzstruktur: die Knoten stellen die Objekte des Anwendungsgebietes dar, die K a n t e n die Beziehungen zwischen den Objekten. Zur Anpassung der Wissensbasis an neue Bedürfnisse muß lediglich diese Netzstruktur modifiziert werden; dies bewerkstelligt der graphische Wissenseditor ZOO. Er erweist sich dabei als geeignete Benutzerschnittstelle zum Faktenwissen und zum konzeptuellen Wissen der Anwendung (dargestellt am Beispiel des elektronischen Postverkehrs). Das im System repräsentierte Wissen wird dabei genutzt, um die Visualisierung und die Modellierung von Wissensstrukturen zu unterstützen. Integrierte wissensbasierte Systeme sind eine Vorstellung der Zukunft. Das in ihnen enthaltene Wissen wird mit Hilfe von Wissensrepräsentationssprachen dargestellt. Mit dem Anwachsen des Wissens eines solchen Systems entstehen große Wissensbasen, die von mehreren Benutzern zu unterschiedlichsten Zwecken verwendet werden können. D. Bauer präsentiert in ihrem Beitrag das System OBJBASE, das zur Verwaltung dieser Wissensbasen und der darin enthaltenen Objekte entwickelt wurde. Es koordiniert den Zugriff auf Wissensbasen und unterstützt deren Veränderung. Damit erleichtert es die Anpassung existierender Wissensba-

14

P r o t o t y p e n benutzergerechter Computersysteme

sen an neue Anforderungen ebenso wie die Individualisierung von Wissensbasen entsprechend spezieller Benutzerwünsche.

D. Bauer stellt dar, wie ein

Benutzer beim Einbringen von neuem Wissen in ein objektorientiertes System

unterstützt

werden

kann,

indem

Veränderungen

unter

Einsatz

von

Heuristiken auf geeignete Wissensbasen verteilt u n d abgespeichert werden. M. Herczeg schildert in einem weiteren Beitrag einen von ihm entwickelten P r o t o t y p e n eines Baukastens zur Erstellung von Benutzerschnittstellen vorwiegend graphischer Ein- u n d Ausgabe numerischer Daten.

mit

Sein System

VlSIVAL stellt f ü r die P r o g r a m m i e r u n g solcher interaktiver Anwendungssysteme eine Vielzahl leistungsfähiger und individualisierbarer Bausteine zur Verfügung, die die F o r m von Instrumenten haben. Als Anwendungsbeispiel solcher (Bildschirm-)Instrumente dient ein

Monitor

zur Überwachung wichtiger Z u s t a n d s p a r a m e t e r des Betriebssytem UNIX auf einem VAX-Rechnersystem.

Dieses Beispiel ist repräsentativ f ü r eine große

Klasse von Anwendungen.

„Überall dort, wo heute Menschen vor Instru-

menten sitzen, u m den Ablauf eines Prozesses zu kontrollieren, können sich in Z u k u n f t Bildschirme mit Darstellungen von Instrumenten genauer,

flexibler,

leichter

modifizierbar,

abnutzungsfrei

und

befinden, die unzerstörbar

die wichtigsten K e n n d a t e n der Prozesse darstellen", schreibt der A u t o r . Im abschließenden Beitrag beschreibt H. Nieper-Lemke mit TRISTAN einen generischen Editor f ü r gerichtete G r a p h e n .

O h n e geeignete U n t e r s ü t z u n g ist

es f ü r P r o g r a m m i e r e r auch heute noch mühevoll, ein Werkzeug zur Darstellung u n d Manipulation von G r a p h e n in einer A n w e n d u n g zu implementieren.

TRISTAN stellt wiederverwendbare anwendungsneutrale Bausteine f ü r

Grapheditoren zur Verfügung. Es ist geeignet, u m z.B. ObjTalk-Klassenhierarchien oder Hierarchien UNIX-Dateiverzeichnissen Funktionalität;

darzustellen.

Beide

Beispiele

beide benutzen den gleichen Algorithmus

haben

die

von

gleiche

zur P l a n u n g

des

„ L a y o u t s " , u n d es existieren auch die gleichen Operationen für die K n o t e n der G r a p h e n .

Der Beitrag schließt mit einer B e t r a c h t u n g von TRIKIT, ei-

nem B a u k a s t e n zum Erstellen einer TRISTAN-Anwendung von A. Lemke.

4. Zur D a r s t e l l u n g Bei der Arbeit an diesem Buch h a t sich herausgestellt, daß es schwierig ist, hochgradig interaktive Systeme in einem linearen, statischen Medium, wie es ein Buch nun einmal ist, a d ä q u a t darzustellen.

Da gerade das äußere Er-

Einführung

15

scheinungsbild und das externe Verhalten von Programmen zentraler Gegenstand der hier beschriebenen Forschungsarbeiten ist, wiegt dieses Problem schwer. Die Interaktion mit den meisten der hier vorgestellten Systeme geschieht vorwiegend durch Zeigeaktionen auf dem Bildschirm; die T a s t a t u r wird meist nur zur Eingabe von Texten benutzt. Die Einfachheit der Bedienung dieser Systeme kontrastiert mit den oft umständlichen Beschreibungen dieser Bedienformen; sie sind k a u m in der Lage, ein lebendiges Bild von der Qualität der Interaktionen zu liefern. Auch Bildschirmabzüge stellen immer nur Momentaufnahmen von sich in ihrem Äußeren schnell wandelnden Systemoberflächen dar. Das Problem hängt eng mit dem Stand der Wissenschaft im Bereich der Mensch-Computer-Kommunikation zusammen. Da dieser noch immer durch eine relative Theoriearmut gekennzeichnet ist, lassen sich auf theoretischer Ebene nur wenige Aspekte der Qualität eines interaktiven Systems abhandeln - der entscheidende Test eines Systems geschieht durch den direkten Umgang mit ihm.

Systeme zur Entwurfsunterstützung

Elab

O o

o o »X Q

•

Finanz 0

b . r l

—1 1

D«*» O I H |

1

II E L A B Direkt manipulative Simulation elektrischer S c h a l t u n g e n Michael Herczeg

Das Konstruieren einer Brücke, das Modellieren einer Autokarosserie das Planen einer Reise haben eines gemeinsam: aus nicht genau spezifizierbar. men

oder schlecht

definierten

Man spricht auch von offenen Aufgaben

oder

die Resultate sind im VorProblemräu-

(„ill defined tasks"

[Simon 81]).

Durch die Vielzahl von Freiheitsgraden gibt es im allgemeinen nicht eine, sondern beliebig viele Lösungen, so wie es auch nicht die beste, sondern allenfalls

verschiedene

[Simon 81]).

befriedigende

Lösungen

gibt

(„satificing

situations"

Eine befriedigende Lösung wird üblicherweise durch folgen-

den Zyklus erarbeitet: 1. Auswählen von Freiheitsgraden 2. Festlegen neuer Werte 3. Beurteilen des Resultats Der zeitkritische Abschnitt in diesem Entwicklungszyklus liegt insbesondere zwischen dem Festlegen

neuer

Werte

und

dem Beurteilen

der

Wirkung.

Die größte Expertise erfordern die Auswahl der zu ändernden Freiheitsgrade sowie die Beurteilung und Bewertung der Änderung. Interaktive

computergestützte

Schwierigkeiten zu verringern.

Simulationssysteme

sind

in

der

Lage,

diese

Sie verkürzen den Zeitraum zwischen dem

Festlegen neuer Werte und der Präsentation des Resultats.

Darüber hinaus

können sie durch eine problemangemessene Präsentation des Systemzustandes die Beurteilung der Güte der erreichten Lösung wesentlich vereinfachen.

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter & Co. • Berlin • N e w York

20

Systeme zur Entwurfsunterstützung

1. E i n l e i t u n g Welche

Eigenschaften

Computersysteme

haben

sollten,

um

die

Lösung

schlecht definierter Aufgaben zu unterstützen, soll am Beispiel des Systems ELAB1 zur Konfiguration elektrischer Schaltungen dargestellt werden. Viele traditionelle Systeme zur Lösung solcher Aufgaben erlauben Schaltungen stapelorientiert zu simulieren (z.B. SPICE [Vladimirescu, Newton, Pederson 80]). Der Benutzer beschreibt die Schaltung mittels einer formalen Sprache. Anschließend wird sie simuliert und das Ergebnis in F o r m von Zahlentabellen ausgegeben. Diese Daten müssen vom Benutzer m ü h s a m interpretiert oder in einem zusätzlichen Systemlauf mittels eines Graphikprogramms auf einem Bildschirm oder Plotter dargestellt werden. Sind die Ergebnisse unbefriedigend, wiederholt sich dieser zeitaufwendige Zyklus.

2. ELAB aus B e n u t z e r s i c h t Mit dem System ELAB wird demonstriert, wie die Untersuchung einer elektrischen Schaltung am Bildschirm in nahezu derselben Art und Weise gelöst werden k a n n wie in einem Labor. Der Benutzer, z.B. ein Elektrotechniker, sieht ein „Experimentierbrett" mit den ihm vertrauten Bauelementen und Werkzeugen (Abbildung 1): • elektrische Bauteile (Widerstände, Kondensatoren, Spulen) • Spannungsquelle (Funktionsgenerator) • Meßgeräte (Oszilloskop, Frequenzanalysator, Zeiger-/Digitalinstrumente) Durch direktes Manipulieren dieser Objekte, d.h. durch Auswählen und Positionieren auf dem Bildschirm mit Hilfe einer Maus als

Zeigeinstrument,

baut er eine Schaltung auf dem Bildschirm auf und testet sie mit Hilfe einer Simulationsumgebung.

Die Resultate der Simulation beobachtet er auf

den verschiedenen, ihm zur Verfügung stehenden Meßinstrumenten.

Er ge-

staltet die Schaltung so lange um, bis das gewünschte Verhalten

erreicht

ist.

Der Benutzer

CAD-System,

erlernt

dazu

formale Sprache,

von Zahlenkolonnen

kein

komplexes

und kein

Graphik-

Er lernt nur, vertraute Objekte auszuwählen, zu

bewegen,

miteinander zu verbinden und deren Eigenschaften zu verändern.

Die aus

ausgabepaket.

keine Interpretation

keine

^ Die M o d e l l i e r u n g der W i s s e n s b a s i s über d a s V e r h a l t e n der e l e k t r i s c h e n S c h a l t u n g e n sowie die P r o g r a m m i e r u n g des S y s t e m s w u r d e n in großen Teilen von J . H e r c i e g d u r c h g e f ü h r t [Herczeg J . 8 7 ] .

21

Elab ELAB-I Notes

ÖX

- o

_

TIMER JUUUL

RUN CONTINUE NEU-CIRCUIT

Experimentation F i e l d

Abbildung 1.

Die E x p e r i m e n t i e r u m g e b u n g von ELAB.

dem Bürobereich inzwischen b e k a n n t gewordene Desktop-Metapher 81] wird in eine Labor-Metapher

[Seybold

ü b e r t r a g e n , d.h. auf das Abbild eines La-

bors auf d e m Bildschirm. ELAB besitzt zwar einen sehr eingeschränkten Anwendungsbereich:

Es las-

sen sich nur Elementarvierpole aus W i d e r s t ä n d e n , K o n d e n s a t o r e n und len miteinander

kombinieren.

Spu-

Die d a m i t erstellbaren Schaltungen sind je-

doch bereits so komplex in ihrem Verhalten, d a ß selbst ein Experte nicht in

Systeme zur Entwurfsunterstützung

22

der Lage ist, das Verhalten einer Schaltung quantitativ, oft selbst nicht einmal qualitativ abzuschätzen.

Durch die Vielfalt möglicher

(Spannungsverläufe) sowie unterschiedlicher

Eingangssignale

Anfangsbedingungen

(Spannun-

gen in Kondensatoren, Ströme in Spulen) erhöht sich die Komplexität noch einmal erheblich. Die einzelnen Bauteile von ELAB sind als Vierpole ausgebildet, d.h. sie besitzen jeweils einen zweipoligen Ein- und Ausgang, wobei ein Pol des Eingangs mit einem Pol des Ausgangs fest verbunden ist. Dieser gemeinsame Pol ist der gemeinsame Bezugspunkt für alle Schaltungsteile. Mit drei elektrischen Elementen (Widerstand, Kondensator und Spule) erhält man auf diese Weise sechs Bauteile (Abbildung 2). Daraus lassen sich durch Hintereinanderschalten eine Vielfalt interessanter und in der Praxis nützlicher Schaltungen zusammenbauen, wie beispielsweise Spannungsteiler, Hochpaß, Tiefpaß, Bandpaß, Siebkette, Serienschwingkreis und Parallelschwingkreis.

Abbildung 2.

Die sechs Elementarvierpole in ELAB.

Ein Funktionsgenerator versorgt die aufgebaute Schaltung mit periodischen Spannungssignalen oder Spannungsimpulsen. men Sinus, Rechteck,

Sägezahn,

Rampe

Vorgesehen sind die Signalfor-

und Konstante.

Die

Amplitude

und ggf. die Periodendauer dieser Signale können variiert werden. Mehrere Meßgeräte dienen zur Analyse des Verhaltens der ten und dimensionierten Schaltung.

zusammengebau-

Sie messen die Spannung an den Bau-

teilen und den Strom durch die Bauteile.

Prinzipiell sind sie mit im realen

Labor verwendeten Meßinstrumenten vergleichbar, wobei sie gegenüber diesen einige Vorteile aufweisen.

So ist das Bildschirm-Oszilloskop

in

der

Lage, beliebig viele Signale gleichzeitig darzustellen, wobei die Kurven in einem in seiner Bemaßung veränderlichen Koordinatensystem gezeichnet beschriftet werden. sichtbar

gemacht

schwingvorgänge. strumenten

und

Es können darüber hinaus nicht nur periodische Signale werden,

sondern

auch

beliebig

kurze

Ein-

Die entsprechenden Vorteile von Zeiger- und

auf dem Bildschirm

werden in Kapitel XIII diskutiert.

gegenüber Instrumenten

und

Aus-

Digitalin-

im realen

Labor

23

ELAB Mit

der

Maus

als

Zeigeinstrument

kann

„Experimentierbrett"

zusammensetzen

in ihren

verändern.

Parametern

tion

das

auf

dem

können

die Meßinstrumente

an

-

die

Ein einstellbarer Zeitgeber steuert den Si-

Der Benutzer kann während und nach Ablauf der Simula-

Verhalten

Die Tastatur

Bauteile

Zum Steuern der Simulation dienen Funk-

tionstasten auf dem Kontrollfeld. mulationsablauf.

Benutzer

und sie - wie die Spannungsquelle

Nun

Bauteile „ a n g e k l e m m t " werden.

der

dient

der

Schaltung

ausschließlich

auf

den

Meßinstrumenten

zur Eingabe

von

beobachten.

Zahlenwerten,

z.B.

für

das Dimensionieren von Bauteilen. In den Abbildungen

7 bis 10 im Abschnitt

5 wird

dies an einem

Beispiel

erläutert.

3. Die Systemstruktur von E L A B Nachdem ELAB aus der Sicht der Benutzer beschrieben wurde, wird in den folgenden Abschnitten darstellt, auf welche implementierungstechnischen

Lö-

sungen das Verhalten an der Oberfläche zurückgeführt werden kann.

3.1 O b j e k t e als Grundelemente der

Implementierung

W i e es die Bedienoberfläche von ELAB mit ihren verschiedenartigen

Arbeits-

objekten schon nahelegt, besitzt ELAB auch programmtechnisch eine objektorientierte

Konzeption.

Jedes Bildschirmobjekt,

also

z.B. jedes

elektrische

Bauteil, die Instrumente, aber auch Steuerelemente wie Zeitgeber und Starttasten, wird

durch ein O b j e k t

präsentiert.

Die A t t r i b u t e dieser O b j e k t e werden durch Slots, ihre Funktio-

nalität pol

zu

durch Methoden irgendeinem

der

Sprache

beschrieben.

Zeitpunkt

die

ObjTalk

So könnte ein

folgenden

[Rathke

C. 86b]

re-

Serienwiderstandsvier-

Attribut-/Wertekombinationen

enthalten: R = 1000 U = 10 I = 0.01 Icon = Sheet = Circuit = Position = 3 U-to-be-Checlced? = t I-to-be-Checked? = nil

Widerstandswert In Ohm Spannung am Widerstand In Volt Strom durch den Widerstand in Ampere Iconobjekt zur Visualisierung des Vierpols Formularobjekt zur Änderung der Objektattribute Schaltungsobjekt, zu dem der Vierpol gehört der Vierpol ist der dritte Vierpol der Schaltung die Spannung des Vierpols wird überwacht der Strom im Vierpol wird nicht überwacht

Die A t t r i b u t e sowie das Verhalten solcher O b j e k t e (z.B. der funktionale Zusammenhang

zwischen

Widerstand,

Spannung

und

Stromstärke:

Ohm'sches

24

Systeme zur Entwurfsunterstützung

Gesetz) sind in Klassen definiert, die Uber eine Vererbungsstruktur allgemeine Eigenschaften zu speziellen verfeinern (Abbildung 3).

Abbildung 3.

Die Vererbungsstruktur der Elementar-Vierpole von ELAB.

In der Serienwiderstandsvierpol-Klasse werden die speziellen Eigenschaften von Serienwiderstandsvierpolen, wie z.B. ihre spezielle Darstellung, durch ein bestimmtes Icon-Objekt definiert. In der allgemeineren WiderstandsvierpolKlasse wird der Slot R als A t t r i b u t für den Widerstandswert definiert. Dieses A t t r i b u t ererbt sowohl die Serien- als auch die Parallelwiderstandsvierpol-Klasse. In der allgemeinsten Vierpol-Klasse werden die Slots U und I als Attribute für Spannung und Strom beschrieben, die jeder Vierpol besitzt. Durch solche Klassenhierarchien erhält man redundanzarme Beschreibungen von komplexen Konzepten, die nicht zwangsläufig, wie in diesem Fall, hierarchischer Natur sind, sondern beliebige V e r b a n d s t r u k t u r e n bilden können. Die Objekte von ELAB wirken durch den Austausch von Nachrichten und die dadurch initiierte Ausführung von Methoden. Die Objekte bilden so ein Netz „kommunizierender Experten" [Minsky 75] mit jeweils besonderen Aufgaben im Gesamtsystem (kollektives Problemlösen). Ein solcher System-

ELAB

25

a u f b a u vereint Eigenschaften wie geringe R e d u n d a n z , Modularität u n d

da-

mit leichte Ä n d e r b a r k e i t von Eigenschaften u n d F u n k t i o n a l i t ä t sowie

pro-

blemorientierte Modellierung.

Die wichtigsten K o m p o n e n t e n von ELAB sind

• die Benutzerschnittstelle, • die zu u n t e r s u c h e n d e Schaltung, • der Simulationsmechanismus u n d • die Meßgeräte. Abbildung

4 stellt die vereinfachte S t r u k t u r

Komponenten grenzt.

sind

als Teilstrukturen

im

des Systems dar.

Gesamtnetz

Die

gegeneinander

vier abge-

D a ELAB d u r c h ein Netz von O b j e k t e n repräsentiert wird, ist die

Aufteilung in K o m p o n e n t e n

nicht als scharfe T r e n n u n g

anzusehen; sie ist

ein Hilfsmittel zum E n t w u r f , zur Implementierung u n d zur Beschreibung des Systems.

3.2 D a s

Simulationsmodell

Die vom Benutzer a u f g e b a u t e Schaltung aus verketteten Vierpolen wird mittels

Mustererkennung

in

einen

elektrischen

Zweipol

transformiert.

Zweipole e n t h ä l t die ELAB-Wissensbasis analytische Beschreibungen

Für

(Funktio-

nen) des Verhaltens in Abhängigkeit von Zeit, E i n g a n g s s p a n n u n g

und

ak-

tuellem Zustand. Zur Simulation t a k t e t ein Zeitgeber Spannungsquelle und Zweipol, die darauf mit der V e r ä n d e r u n g ihres inneren Zustandes gemäß der schreibungen reagieren.

Funktionsbe-

Auf diese Weise entstehen Abläufe von S p a n n u n g s -

bzw. S t r o m w e r t e n an den Bauteilen, die wiederum von den Meßgeräten abgegriffen, visualisiert

und

gegebenenfalls

gespeichert

werden.

Durch

die

steuerbare zeitliche R a s t e r u n g , die im Zeitgeber definiert wird, k a n n die Simulation beliebig genau und beliebig lange d u r c h g e f ü h r t werden. Eine R ü c k s e t z f u n k t i o n erlaubt das Reinitialisieren von Schaltung und

Meß-

geräten zur D u r c h f ü h r u n g eines neuen Simulationslaufs. Es ist d e n k b a r , ein leistungsfähiges Elektroniksimulationssystem für ELAB ZU verwenden, u m die benötigten Simulationsdaten Ein solches S i m u l a t i o n s p r o g r a m m aufgerufen werden.

könnte

wie SPICE

zu

erzeugen.

über eine Methode der

Zweipole

So ließen sich auch eine Reihe anderer

Schaltungsty-

pen, wie z.B. T r a n s i s t o r s t u f e n , simulieren - unter Beibehaltung der sehr expliziten und natürlichen Beschreibung der Schaltungen d u r c h O b j e k t e .

26

Abbildung 4.

Systeme zur Entwurfsunterstützung

Die Gesamtstruktur von ELAB.

27

ELAB

3.3 Die

Meßinstrumente

Ein Simulationslauf eignet aufzubereiten ten Meßinstrumente stattung stehen die dung 5):

führt zu umfangreichen Daten, die für den Benutzer gesind. Die Datenaufbereitung leisten die bereits erwähnvon ELAB. In Anlehnung an die gewohnte Laborauswichtigsten Instrumenttypen zur Verfügung (siehe Abbil-

• Oszilloskop • Frequenzanalysator • Zeigermeßinstrumente • Digitalmeßinstrumente Jedes dieser Instrumente hat bestimmte Einsatzbereiche. So verschafft ein Oszilloskop einen Uberblick über den zeitlichen Spannungs- und Stromverlauf. Mehrere Signale können dabei durch Übereinanderlegen leicht verglichen oder abgestimmt werden. Der Frequenzanalysator gibt Aufschluß über das Verhältnis von Ein- und Ausgangspegel in Abhängigkeit von der angelegten Frequenz. Ein Zeigerinstrument zeigt hingegen Momentanwerte der elektrischen Größen an. Das Einhalten bzw. Überschreiten von Toleranzen kann dabei sehr gut überblickt werden. Die Meßwerte können durch eine vom Benutzer initiierte Anpassung der Skala beliebig genau abgelesen werden. Durch automatische Anpassung der Anzeigegenauigkeit erlauben digitale Instrumente eine im Normalfall stets ausreichend genaue Wertdarstellung. Die Zeiger- und Digitalinstrumente von ELAB wurden mit dem in Kapitel XIII beschriebenen Baukasten VisrVAL generiert und konnten mit geringem Aufwand in ELAB integriert werden. Hier zeigt sich der Nutzen und die Realisierbarkeit anwendungsneutraler Benutzerschnittstellen-Bausteine recht deutlich [Herczeg 86a].

3.4 A p p l i k a t i o n s - u n d

Interaktionsobjekte

In ELAB lassen sich zwei Grundtypen von Objekten hinsichtlich ihrer Aufgaben im System unterscheiden. Applikationsobjekte, wie z.B. Vierpole und Zeitgeber, beschreiben die Anwendungswelt, im Fall von ELAB die Welt der elektrischen Bauteile und die Welt der Simulation. Zur Visualisierung und Manipulation dieser Applikationsobjekte existieren Interaktionsobjekte, das sind Beschreibungen graphischer und textueller Bildschirmdarstellungen sowie Dateneingabeverfahren für Tastatur und Zeigeinstrument (Maus bei ELAB).

28

Systeme zur Entwurfsunterstützung

T Abbildung 5.

1

Die Meßinstrumente von ELAB.

Jedes Applikationsobjekt besitzt ihm zugeordnete Interaktionsobjekte. So besitzt die Spannungsquelle beispielsweise drei fest zugeordnete Interaktionsobjekte: • das Spannungsquellen-Icon zur Visualisierung der Spannungsquelle innerhalb der Schaltung • das Signal-Menü zur Visualisierung und Änderung des Attributs Signalform • das Spannungsquellen-Formular Spannungsverlaufs

zur

Spezifikation

des

quantitativen

Alle drei Interaktionsobjekte sind als sichtbare Aspekte des Applikationsobjekts Spannungsquelle anzusehen (Abbildung 6). Dieses Prinzip der Trennung von Anwendungs- und Dialogwelt entstammt der Konzeption anwendungsneutraler Benutzerschnittstellen und dient dabei sowohl einer konzeptionellen als auch einer programmiertechnischen Entkopplung von Anwendungssystem und Benutzerschnittstelle. Das die An-

29

ELAB

Abbildung 6.

Applikationsquelle.

und

Interaktionsobjekte

für

die

Spannungs-

wendung betreffende Wissen wird in Applikationsobjekten repräsentiert, während sich das den Dialog zwischen Benutzer und System betreffende Wissen in den Interaktionsobjekten wiederfindet.

4. Z u s a m m e n f a s s u n g und A u s b l i c k Mit ELAB wird demonstriert, wie sich die bereits für Büroumgebungen bekannte Desktop-Metapher in eine Labor-Metapher (kurz Lab-Metapher) übertragen läßt. Der Techniker arbeitet damit, wie er es in seinem normalen Labor gewohnt ist. Änderungen und Erweiterungen bieten sich vor allem dort an, wo die „materielle" Arbeitswelt Beschränkungen auferlegt, die durch das Werkzeug Computer bzw. durch das Medium Bildschirm leicht und aufgabenangemessen beseitigt werden können. Ein Beispiel d a f ü r ist die Erweiterung des traditionellen Oszilloskops zu einem Instrument, das es erlaubt, mehr Informationen gleichzeitig zu präsentieren und diese in praktisch beliebiger Präzision darzustellen.

30

Systeme zur E n t w u r f s u n t e r s t ü t z u n g

Die Benutzeroberfläche von ELAB konnte mit einem vorhandenen

Benutzer-

schnittstellen-Baukasten

Derartige

verhältnismäßig

schnell erstellt werden.

Bausteine waren die genannten VlSIVAL-Instrumente, Formulare, Menüs sowie verschiedenartige ikonische Darstellungen wie Schaltungselemente, F u n k tionstasten u n d graphische Menüs. Fenstersystem

und

eine

Als Basis f ü r diese Bausteine dient ein

Verwaltungskomponente

für

Bitmaps

und

Fonts

(Zeichensätze). Als

programmiertechnische

Grundlage

der

Simulationskomponente

und

Sprache O b j T a l k .

der

der

Benutzerschnittstellen-Bausteine,

Bauteile

diente

die

objektorientierte

Durch die Verwendung von Wissensrepräsentationsmetho-

den wie objektorientierter P r o g r a m m i e r u n g , F r a m e s und Constraints ist es gegenüber traditioneller P r o g r a m m i e r u n g sehr viel leichter möglich, d e m Benutzer E r k l ä r u n g e n

zu a u f g e b a u t e n

Schaltungen

zu präsentieren

zum Beispiel auf Fehler oder Grenzen des Systems hinzuweisen.

und

ihn

Auch die

dynamische Umgestaltbarkeit des Systems basiert letztlich auf diesen Mechanismen. So wie ELAB den Arbeitsplatz eines Elektrotechnikers

auf den

Computer

abbildet, ist es auch d e n k b a r , andere Laborumgebungen, wie zum Beispiel chemische oder physikalische Labors, in ähnlicher A r t und Weise abzubilden.

Solche Umgebungen

sind auch

als Ausbildungsmedium

verwendbar.

Durch die Selbsterklärungsfähigkeit von Bildschirmdarstellungen u n d zusätzliche tutorielle K o m p o n e n t e n kann auf diese Weise auch ein wirkungsvoller Lehr- und Lernbetrieb d u r c h g e f ü h r t werden. Die inzwischen fortgeschrittene Weiterentwicklung von ELAB lotet vor allem diese tutoriellen Wissensbasis

Aspekte weiter aus.

vor

selbst besitzt.

allem

in Bezug auf

Dies erfordert die A u s d e h n u n g Wissen,

das das

System

über

der sich

Nur so wird es in die Lage versetzt, Hilfen zu seiner eigenen

Benutzung sowie kontextabhängige Erklärungen zum Anwendungsbereich abzugeben.

5. Beispieldialog Durch die folgenden Abbildungen soll ein E i n d r u c k von der Arbeit mit dem System vermittelt werden.

Die ausgeprägte Interaktivität derartiger

me läßt sich natürlich n u r sehr unzureichend durch statische nachvollziehen.

Syste-

Abbildungen

31

ELAB

©X

ELAB-l Notes

RUN

UDER

CONTINUE NEU-CIRCUIT

Experimentation Field

- O

X Ï-L

I a

Frequency Analyser

rasa

• o o

t.S

;

Abbildung 7.

I M I

••

Das Experimentierbrett mit einer aufgebauten Schaltung.

Die Schaltung stellt einen Serienschwingkreis dar, dessen Verhalten in Abhängigkeit von Eingangssignal und Dimensionierung von Bauteilen untersucht werden soll. Der Frequenzanalysator zeigt die Übertragungsfunktion der Schaltung.

32

Systeme zur Entwurfsunterstützung IELAB-1 {Notes

©X

-cn-

RUN TI H E R

CONTINUE

JUUUL

NEW-CIRCUIT

Experimentation Field

-CDAnalog Gauge 1

vO

'/,

rinrngri

im Digital Gauge 3 © >

m I fr-* [i

Abbildung 8.

Die Schaltung wird simuliert und mittels Digital- und Zeigerinstrumenten untersucht.

Die angeklemmten Instrumente zeigen während des Simulationslaufs dynamisch die Veränderung der elektrischen Größen an den Bauteilen an. Die Skalierung der Zeigerinstrumente kann bei Bedarf geändert werden, um sie an den zu messenden Wertebereich anzupassen.

33

ELAB

©X

ELAB-l Notes

•A

V

T

Experimentation Field

mi m

1 I

1

1

RUN TI H E R

CONTINUE

JUUUL

NEW-CIRCUIT

Osci Uoscope

m

Abbildung 9.

Der Signalverlauf wird im Oszilloskop dargestellt.

Im Gegensatz zum Zeiger- und Digitalinstrument zeigt das Oszilloskop den zeitlichen Verlauf der elektrischen Größen in einem Koordinatensystem an. Mehrere Größen können dabei zum Vergleich überlagert dargestellt werden. Im vorliegenden Beispiel sind dies die Spannung am Kondensator und der Strom durch die Spule. Das An- und Abklemmen sowie die Anordung von Instrumenten auf dem Experimentierbrett kann vom Experimentator problemabhängig gewählt werden. Die Interaktion erfolgt dabei ausschließlich mit der Maus.

Systeme zur Entwurfsunterstützung

34 ELAB-l Notes

o>:

H l

"t

—. 1 *

IIII

L

TIHER

1

=

JUUUL

RUN CONTINUE NEU-CIRCUIT

Experimentation Field

-O-

—i—

: ® L_ Oscilloscope

5t ml

fr ft— Frequency Analyser

/v !

Abbildung 10.

1

Ein neues Eingangssignal wird an die Schaltung angelegt.

Durch Auswahl eines Rechtecksignals als neues Eingangssignal ändert sich auch das Ausgangsverhalten, das wieder im Oszilloskop beobachtet werden kann. Der Frequenzanalysator zeigt die aktuelle Übertragungsfunktion, die sich nach Änderung der Bauteile ebenfalls verändert hat. Die Analog- und Digitalmeßinstrumente wurden deaktiviert.

III

TRANSPLAN

Computerunterstiitzte Planung von Warentransporten Dieter Maier

Dieser

Beitrag

TRANSPLAN1.

beschreibt

das

nung von Warentransporten. für

prototypische

Planungsunterstützungssystem

Es unterstützt den Disponenten einer Spedition bei der PlaAnhand

Planungsunterstützungssysteme

dieses Beispiels werden

wesentliche

Eigenschaften

allgemeine, dargestellt:

Nach einem kurzen Beispieldialog wird auf Aspekte wie interaktives Planen, Uberwachen von Randbedingungen, paralleles Verfolgen alternativer

Lösun-

gen, Verfahren zur automatischen Plangenerierung und Simulation von erstellten Plänen

eingegangen.

Im weiteren

wird

die Verwendung

anwen-

dungsneutraler Werkzeuge zur Gestaltung der Benutzerschnittstelle beschrieben.

Die durch objektorientierte Implementierung erreichbaren Eigenschaf-

ten wie Modularität und Änderbarkeit werden aufgezeigt.

1. A u f g a b e n s t e l l u n g Warentransporte optimal durchzuführen bedeutet, Güter von ihren Standorten zu ihren Betimmungsorten so zu transportieren, daß für die Gesamtheit aller Transporte möglichst wenig Ressourcen verbraucht und außerdem bestimmte Randbedingungen eingehalten werden.

Die allgemeine

Zielsetzung,

den Nutzen zu maximieren und die Kosten zu minimieren, läßt sich dabei zu

Zielen

wie

z.B.

möglichst

viele

erledigte

Aufträge,

möglichst

kurze

Strecke und Fahrzeit, gute Einhaltung von Terminen und bevorzugter Einsatz von kostengünstigen Lkws konkretisieren.

1

T R A N S P L A N w u r d e von V . K e n n e r , S. R e i c h e r t e r u n d D. R e i n h o l d i m p l e m e n t i e r t . Eine d e t a i l l i e r t e B e s c h r e i b u n g der I m p l e m e n t i e r u n g f i n d e t sich in [ R e i c h e r t e r , R e i n h o l d 86] und [Kenner 86].

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter Sc Co. • Berlin • N e w York

36

Systeme zur Entwurfsunterstützung

1.1 Die , , W e l t " der

Transportplanung

Ein Disponent einer Spedition hat eine Menge von Transportaufträgen vorliegen. Solche Transportaufträge haben Eigenschaften wie Standort, Bestimmungsort, Gewicht, Raumbedarf, frühestmögliche Abholzeit, spätestmögliche Abholzeit, frühestmögliche Ankunftszeit, spätestmögliche Ankunftszeit, voraussichtliche Dauer der Be- und Entladung, Verpackungsart und Preis für die Transportleistung. Besonderheiten der zu transportierenden Waren können z.B. Eigenschaften wie giftig, explosiv oder zerbrechlich sein. Für das Transportmittel werden zur Erledigung der Transportaufträge Routen festgelegt. biets.

Grundlage der Routenbildung ist eine Straßenkarte des Ge-

Damit können die Lage von Orten, Verbindungen zwischen Orten,

Entfernungen und die durchschnittlichen Fahrzeiten bestimmt werden. Für gewisse Strecken können Einschränkungen der Befahrbarkeit existieren, wie beispielsweise ein maximal zulässiges Gesamtgewicht oder eine maximal zulässige Höhe des Fahrzeugs, zeitliche Sperrungen wegen Bauarbeiten oder ein Verbot des Befahrens mit wassergefährdenden Stoffen in Wasserschutzgebieten. Die Fahrzeuge des Fuhrparks haben neben Eigenschaften wie zulässigem Gesamtgewicht, maximaler Zuladung und Ladevolumen, Länge, Breite und Höhe des Laderaums weitere Merkmale wie durchschnittlicher Verbrauch, verursachte Kosten und andere mehr. Fahrzeuge stehen an bestimmten Standorten, Umladeplätze erlauben einen Wechsel von Gütern von einem Fahrzeug auf ein anderes. Den Fahrzeugen müssen Fahrer zugeordnet werden; dabei sind die maximal zulässigen Fahrzeiten, Urlaub, Krankheit etc. der Fahrer zu berücksichtigen.

1.2 T e i l p r o b l e m

Routenplanung

In ihrer allgemeinen Formulierung umfaßt die Aufgabe der Transportplanung neben Routenfestlegungen auch Umschlagabläufe und Zuordnungen von Ressourcen. Um die Aufgabe handhabbar zu machen, wurde die Aufgabenstellung für TRANSPLAN eingeschränkt. Dabei wird von folgendem Szenario ausgegangen: Fahrzeuge fahren in der Regel Tagestouren, d.h. sie starten morgens leer von ihrem Standort und kehren abends nach Erledigung ihrer Transportaufträge wieder leer zu ihrem Standort zurück. Der Aktionsradius der Fahrzeuge liegt bei etwa 100 bis 150 Kilometern. Dabei wird von einem Auftragsspektrum ausgegangen, das ein Zusammenfassen mehrerer Aufträge zu einer Tour erlaubt.

37

TRANSPLAN TRANSPLAN vernachlässigt städtischen

Bereich.

dabei

Die

die detaillierte R o u t e n p l a n u n g

automatische

im

Planungskomponente

inner-

unterstützt

auch keine a u t o m a t i s c h e Z u o r d n u n g von A u f t r ä g e n zu verschiedenen

Lkws,

d.h. sie b e t r a c h t e t zu j e d e m Z e i t p u n k t nur einen Lkw 2 .

1.3 Zielsetzung: ein u n t e r s t ü t z e n d e s

System

Bei der T r a n s p o r t p l a n u n g h a n d e l t es sich u m einen offenen Problembereich, d.h.

zu

jedem

Zeitpunkt

der

Planung

können

neue

Informationen

R a n d b e d i n g u n g e n wichtig werden, die nicht vorhersehbar sind. tomatischer

Planer

kann

unerwartete

nicht e n t s p r e c h e n d berücksichtigen. sen:

Informationen

und

D a d u r c h entstehen

Einschränkungen zwei

Problemklas-

v o m System u n t e r s t ü t z t e S t a n d a r d f ä l l e und mit d e m System nicht be-

a r b e i t b a r e Ausnahmefälle.

Die Möglichkeit zur Formalisierung neuer Infor-

mationen, Einschränkungen

und

Ziele f ü r eine a u t o m a t i s c h e P l a n u n g

Z e i t p u n k t ihres A u f t r e t e n s löst dieses P r o b l e m nur teilweise. könnten werden.

zwar der Bearbeitung

d u r c h den automatischen

zum

Ausnahmefälle

Planer

zugeführt

F ü r exotische, u n t e r U m s t ä n d e n nur einmal a u f t r e t e n d e Fälle ist

dies jedoch setzt

und

Ein vollau-

vom A u f w a n d her wenig sinnvoll.

vollständig

Ziele voraus.

Vollautomatische

Ein-

Planungssysteme

dar,

da w ä h r e n d eines Planungsvorganges oft neue Ziele angestrebt werden

und

f ü r die E r s e t z b a r k e i t

Dies stellt

Planung

eine s t a r k e

schränkung

vorgegebene

vollautomatischer

auf die Verfolgung ursprüglicher Ziele verzichtet wird. Aus diesen G r ü n d e n ist TRANSPLAN nicht als autonomes, sondern als unterstützendes

C o m p u t e r s y s t e m konzipiert.

vollautomatisches, Ein E x t r e m f a l l da-

bei ist die F u n k t i o n des Systems als Ersatz f ü r „ P a p i e r u n d Bleistift". P l a n e r ist dabei in seiner Arbeitsweise völlig frei.

Auf der anderen

Der Seite

soll TRANSPLAN nicht n u r Papier u n d Bleistift ersetzen, sondern Teile der Arbeit ü b e r n e h m e n .

Der E x t r e m f a l l hier ist die a u t o m a t i s c h e Erstellung ei-

nes Planes. Zwischen

diesen

beiden

Extremen

liegen

viele

mögliche

Arbeitsteilungen.

Das beste Ergebnis der Arbeit ist zu erwarten, wenn jeder P a r t n e r , Mensch u n d C o m p u t e r , seine besonderen Fähigkeiten einbringen k a n n u n d den Teil der A r b e i t verrichtet, den er a m besten verrichten k a n n .

Uber die Auftei-

lung der Arbeit sollte der Benutzer die Kontrolle haben; er sollte über das Maß an U n t e r s t ü t z u n g , das er jeweils vom System will, entscheiden können.

2

.

.

.

.

Eine Möglichkeit, in einer „Miniwelt" eigene Erfahrungen mit der Planung von Routen zur Erledigung von T r a n s p o r t a u f t r ä g e n zu sammeln, bietet das Spiel „Auf Achse" (Spieleverlag Schmid).

38

Systeme zur Entwurfsunterstützung

Ein unterstützendes Computersystem muß deshalb so ausgelegt sein, daß es flexibel ist und die Handlungsspielräume des Benutzers möglichst wenig einschränkt. Es muß robust gegenüber Inkonsistenzen sein, da es nicht von vollständigen und korrekten Informationen ausgehen kann, z.B. falls der Benutzer auf automatische Konsistenzüberprüfungen des Systems verzichten will, da es ihm leichter fällt, zuerst einen fehlerhaften Plan aufzuschreiben, den er später korrigiert.

2. TRANSPLAN aus der S i c h t des B e n u t z e r s Als Benutzer von TRANSPLAN ist der Disponent in einer Spedition Anwendungsexperte, aber EDV-Laie3. Er hat durch. seine bisherige Arbeitsweise einen individuellen Arbeitsstil, den er beibehalten und durch das System unterstützt haben möchte.

2.1 M a n i p u l i e r b a r e O b j e k t e in TRANSPLAN Um das Arbeiten mit TRANSPLAN einfach zu gestalten, werden Konzepte der realen Welt möglichst natürlich modelliert. Objekte wie Waren, Aufträge, Städte und Transportmittel werden durch Anwendungsobjekte repräsentiert. Ein Auftrag hat z.B. Eigenschaften wie Start- und Zielort sowie eine Beschreibung der zu befördernden Ware. Ein Tagesplan für ein bestimmtes Fahrzeug enthält Informationen über die Menge der zu erledigenden Aufträge, die Fahrroute, Auf- und Abladevorgänge sowie voraussichtliche Fahrzeit und Fahrstrecke. Anwendungsobjekte können vom Benutzer mit den entsprechenden Operationen, die er aus der realen Welt kennt, manipuliert werden. TRANSPLAN stellt Anwendungsobjekte, wie z.B. Landkarte, Aufträge und Pläne, auf dem Bildschirm graphisch dar. Diese können direkt durch Anklicken mit dem Zeigeinstrument manipuliert werden. Die Auswahl von Aktionen geschieht durch Menüauswahl, die Eingabe und Darstellung von Daten, z.B. Aufträgen, durch das Ausfüllen von Formularen. Zur Visualisierung von numerischen Größen verwendet TRANSPLAN Software-Anzeigeinstrumente (siehe Kapitel XIII).

3

Den Benutzer eines Computersystems gibt es im allgemeinen nicht. Die Beschreibung stellt deshalb ein grobe Charakterisierung der beim Systementwurf vorhergesehenen Benutzergruppe dar.

39

TRANSPLAN

2.2 B e i s p i e l d i a l o g Nachfolgend soll das Arbeiten mit TRANSPLAN d u r c h einen kurzen Dialog mit Bildschirmabzügen veranschaulicht werden. Der Benutzer beginnt mit der Eingabe von A u f t r ä g e n d u r c h das Ausfüllen von F o r m u l a r e n .

Einige A u f t r ä g e sind bereits eingegeben.

P l a n ist noch leer, d.h. es sind keine A u f t r ä g e eingeplant.

Der

aktuelle

Der Lkw steht

ohne L a d u n g an seinem S t a n d o r t , im Beispiel ist dies S t u t t g a r t . Der Benutzer erweitert den P l a n sukzessiv d u r c h H i n z u n a h m e noch eingeplanter A u f t r ä g e .

Nach der Auswahl eines A u f t r a g s zur

nicht

interaktiven

E i n p l a n u n g m u ß der Benutzer die Position der Be- u n d Entladestelle angeben, sofern die Position nicht eindeutig ist. seine

Zulässigkeit

bezüglich

der

formulierten

Der erweiterte P l a n wird auf Randbedingungen

überprüft.

Verletzte R a n d b e d i n g u n g e n werden d e m Benutzer angezeigt. Abbildung 1 zeigt einen Bildschirmabzug, der aus den bisherigen

Aktionen

des Benutzers resultiert: • Im linken oberen Fenster wird der gerade bearbeitete P l a n dargestellt. Die F a h r r o u t e im Überblick sowie eine Auflistung der geplanten Aktionen werden gezeigt. Fahrzeit, Fahrstrecke u n d noch einzuplanende H e i m f a h r t zum S t a n d o r t S t u t t g a r t werden visualisiert. Das Kontrollfeld „Vorschlag G e n e r i e r u n g " erlaubt die Aktivierung verschiedener Verfahren zur a u t o m a t i s c h e n Erzeugung von P l ä n e n . • Oben rechts befindet sich ein Kontrollfeld, u m die von TRANSPLAN zu aktivieren.

Grundfunktionen

• Im Fenster „ A u f t r a g s b e s t a n d " werden die vorliegenden A u f t r ä g e dargestellt. Durch ihre Darstellung ist ihr B e a r b e i t u n g s z u s t a n d e r k e n n b a r . Das rechts davon gerade sichtbare Menü „ E i n p l a n u n g s s t r a t e g i e n " erlaubt die Auswahl einer Strategie zur E i n p l a n u n g des zuletzt selektierten Auftrages. • Im u n t e r e n Teil des Bildschirms ist ein Ausschnitt aus einer schematisierten S t r a ß e n k a r t e zu sehen. Ist der Benutzer mit einem Teilplan unzufrieden, k a n n er ihn, z.B. d u r c h Ausplanen eines A u f t r a g s , modifizieren.

Ist er unsicher, ob die E i n p l a n u n g

eines A u f t r a g s zu einem akzeptablen Ergebnis f ü h r t , k a n n er eine alternative Lösung parallel entwickeln.

Er kann ebenso Teilergebnisse ablegen, u m

gegebenfalls später darauf zurückzugreifen.

Systeme zur Entwurfsunterstützung

40 Plan!

öSTransPlan

Fahrzeit

V o r s c h l a g Generierung

-»s

^

©&

L

m e n ->

UN - >

ES - >

GP - >

•

UL

Auftrag-1 Auf t r a g - 3

E:5

h

GP |*b UL |at'

D

Ende

einzelne Stationen ät :TWt S UN a b

iTir.d

P läne S i m u l a t ion

r?h :tr»nm i S

Aufträge

All ft r a g - 3 Auf t r a g - 1

1

Ikuf Uu *

r

Auftragsbestand

iT_.

_.

7

Einplanungsstrategien optimal einplanen an gegebene Route anhangen Angabe der E i n p l a m i n a s s i e l le Angabe der Be- und E n t l a d e s t e l l e Infos

Strassenkarte

Abbildung 1.

Interaktives Einplanen von Aufträgen.

Der Benutzer läßt sich ausgehend von seinem bisher erstellten Teilplan einen Lösungsvorschlag vom System generieren. Das System stellt seinen Vorschlag als alternativen Plan dar (Abbildung 2).

41

TRANSPLAN Plani

OlTransPlan

ü E3 ES3 c

Fahrzelt

^

Vorschlag Generierung

. n.iA : 8h 8n i r»

)

O

&

Auftrage

]

Pläne S imulation

""•th ?'jn i ri I S s

->

WN ->

tb ->

UP ->

UL -> WÜL ->

einzelne Stationen s •t5,rt WM r •ach ~

ES »t-

NI -> WDL ->

Auftrag-1 Auftrag-3

Auf trag-3 Auftrag-1 Auftrag-4 Auftrag-4 Planverwaltung

Plan2: Vorschlag fuer Plani

w

Fahrzelt

1 FhTTTT

5® 2 55888:

h.

iwEsrino«

1 HHHM

1I8888 ill.HHHH 'ig:

8 8

8

8 4/HUUH

Abbildung 1.

Finanzierungspläne für ein Projekt.

Ein mit FINANZ erstelltes System zum Ausfüllen von Finanzierungsplänen für einen Projektantrag beim Bundesministerium für Forschung und Technologie.

eher Formulare können durch Verwendung des elektronischen Mediums ausgeglichen oder in Vorteile umgekehrt werden. wirrend

und schwer verständlich.

wichtige Informationen.

Papierformulare sind oft ver-

Zum richtigen Ausfüllen fehlen häufig

Demgegenüber enthalten Formulare oft Felder und

Texte, die für den Ausfüllenden nicht relevant sind.

Ein

Computersystem

kann in diesen Beziehungen viel flexibler als Papier und Bleistift sein. Bildschirm

formulare

können

der jeweiligen

Aufgabe

angepaßt

werden.

Die

Flexibilität eines Computersystems macht es unnötig, Informationen für verschiedene Zwecke im selben Formular darzustellen.

In den

verschiedenen

Bearbeitungsstufen - vom Ausfüllen bis zur Verwendung des Formulars werden unterschiedliche Anforderungen an Aufbau und Inhalt gestellt. Bildschirm

formulare

Formularen

findet

können

dynamisch

erzeugt

werden.

In herkömmlichen

man häufig Abschnitte, die nur ausgefüllt werden müs-

sen, wenn bestimmte Voraussetzungen gegeben sind (z.B. „verheiratet/ledig/ geschieden").

In solchen Fällen können Bildschirmformulare dynamisch an-

gepaßt werden, d.h. der Benutzer sieht nur die für ihn zutreffenden Teile.

58

Systeme zur Entwurfsunterstützung

Berechnungen

werden

ren Formularfeldern Formularen

gibt

vom

System

abhängen,

es

üblicherweise

prozentuale Abhängigkeiten

Feldinhalte, die von

ausgeführt.

können

automatisch

Teilsummen,

zwischen Feldern.

berechnet

Produkte,

ande-

werden.

In

Uberträge

In wissensbasierten

und

Systemen

kann die „ B e r e c h n u n g " komplexe Entscheidungsprozesse beinhalten.

Abhän-

gigkeiten der Felder bleiben dann nicht auf arithmetische Beziehungen schränkt. kation

In einem Forschungsprojekt stehen z.B. die Anzahl

von

Mitarbeitern,

die

Aufgabenstruktur,

der

und

effektive

Qualifi-

Einsatz

Mitteln und die Gesamtlaufzeit des Projekts in einer komplexen

bevon

Beziehung

zueinander. Lokale

Uberprüfungen

während können

der Feldinhalte

der Eingabe auf

werden

unmittelbar

nach

oder

Mehrdeutige oder ungenaue

vorgenommen.

Grund des Wissens Uber die Funktion des Systems

werden (Abbildung 2).

schon

Eingaben verstanden

Darüber hinaus können unvollständige A n g a b e n

er-

gänzt und kleinere Fehler korrigiert werden.

Zeitraum

Zeitraum flnf a n g SiSEnde

A b b i l d u n g 2.

1 .3.1986 g

nlir?

III)

sä!

Rnfang 1 mir

..'.'.J

©X 1 3

l«JHf,

i:-;:. 1 . 3 . '

l'ton

Interpretation und Ergänzung von

Benutzereingaben.

Beim Ausfüllen eines Datumfeldes wird die Eingabe als Datum analysiert und mit plausiblen Werten ergänzt. A u f Grund des Wissens über die Funktion eines Feldes kann entschieden werden, welche Eingaben möglich und sinnvoll sind. Erwartungen über Benutzereingaben erleichtern die A n a lyse.

Systeme

können

von

ihren Benutzern o f t nicht beeinflußt und an ihre Bedürfnisse angepaßt

wer-

den.

mit

Diese

einer

ähnlich

großen

Modifizierbarkeit

ist aber von grundlegender

Funktionalität

wie

des Anwendungssystems

FINANZ durch

den

Benutzer

Bedeutung:

• Verschiedene, formularorientierte Anwendungen unterscheiden sich in wesentlichen Punkten, so daß Standardisierungen nur selten möglich sind. Systeme müssen daher den WUnschen der Anwender angepaßt werden. Ist die Anpassung nur auf der Ebene der Programmierung möglich, dann ist dazu ein Programmierexperte erforderlich.

59

FINANZ

• Aufgaben und damit Anforderungen an das System sind einem ständigem Wechsel unterworfen. In relativ kurzen Abständen müssen Änderungen aufgenommen und durch das System reflektiert werden. Die wechselnden Anforderungen können nicht vom Systemdesigner vorausgedacht werden. Deshalb ist die Modifizierbarkeit des Systems durch den Anwender selbst notwendig. • Die Expertise zur Anpassung des Systems liegt auf der Seite des Anwenders. Die Möglichkeit, eigenständig Veränderungen vornehmen zu können, vermeidet auch Kommunikationsprobleme mit Systemherstellern. Die Möglichkeit, Systeme zu gestalten und sie an veränderte Bedingungen anzupassen, macht sie zu Werkzeugen in den Händen der Anwender. Sie sind keine festgefügten Blöcke, die, so wie sie sind, akzeptiert werden müssen. Ihre Funktion und ihre Einsatzweise werden vom Anwender bestimmt. Dazu sind keine speziellen Kenntnisse Uber die Implementationssprache erforderlich. Die Kontrolle liegt damit beim Anwender des Systems. In den folgenden Abschnitten soll dies an Hand eines Beispiels verdeutlicht werden.

2.1 B e n u t z e r m o d i f i k a t i o n e n in FINANZ Im

Finanzierungsplan

für ein

Forschungsprojekt

werden

die

beantragten

Personalkosten in einem vorgegebenen Formular dargestellt (Abbildung 3). In der ersten Spalte werden die Anzahl der Personen einer bestimmten Gehaltsklasse aufgeführt.

Zusammen mit der Jahrespauschale ergeben sich die

Gesamtausgaben bezogen auf Gehaltsklassen. samten beantragten Personalmittel aus.

Die E n d s u m m e weist die ge-

Die Jahrespauschalen der einzelnen

Gehaltsstufen befinden sich auf einem zweiten Formular. Mit Hilfe dieser beiden Formulare kann ein weiteres Formular erzeugt werden, das einen einzelnen Personalposten aus einer anderen Sicht darstellt. Im Vergleich zum Papierformular stellt das Bildschirmformular von Abbildung 3 nur einen Ausschnitt dar. Dieser Ausschnitt zeigt die für das augenblickliche Bearbeitungsstadium relevanten Informationen. Es konzentriert sich auf die Personalkosten der Projektfinanzierung. In einem anderen Bearbeitungsstadium können weitere Informationen relevant werden. Mit FINANZ ist es möglich, neue Formulare zu erzeugen, die Daten unter einer anderen Perspektive zeigen. Allgemein beschreiben die Formulare in FINANZ Sichten auf Datenstrukturen.

Diese Datenstrukturen bilden die interne Repräsentation des Systems.

Sie enthalten Daten über Projekte, Laufzeiten, Zeitpunkte, Personen, Quali-

60

Systeme zur Entwurfsunterstützung

1.I.1986 I 1 1988

von

bis H V ') 0 H H H

Abbildung 3.

(»HHHH 55000: •IHHHH SSÖH0 30000: 2S0ÖÖ; ¿BSäfl

jBat i ;Öät ïa Bat I l a / I b Bat Ub líd Bat « -Uc •Jal I ohnenpf . i 'i

von 1 . 1 986 ifbfs^ij 1 . 1. l'Hill

? § Jahre :•:•:•: i nsge San t. : : : : 1 1 ;>HHHH

1 1 Hat I 90000 1 2 . Bat Id Ä^VjVOTBfS ? Uat f l â ' î b j H Hat Uh -IIa H ll.lt -ye 8 ./fi': 0 1 nilrienpf. o H 1 ritgel t e

©V

90000 •J8HHH fleld-menu

2000H0 :ii,HHHH H H ¡160000 i,fi: :

Abbildung 11.

Das Festlegen eines Feldes.

Mit der Festlegung des Monatsfeldes hat der Benutzer Kontrolle an das System abgegeben. geschränkt.

Dadurch wird seine Entscheidungsfreiheit jedoch nicht ein-

Diese Form der Aufgabendelegation kann jederzeit wieder zu-

rückgenommen werden.

In den erklärenden Texten Uber das Zustandekom-

men von Feldinhalten wird die zusätzliche Systemleistung reflektiert.

68

Systeme zur E n t w u r f s u n t e r s t ü t z u n g

3. D i e S y s t e m s t r u k t u r v o n FINANZ Die Systemstruktur von FINANZ ist in Abbildung 12 dargestellt. in die Benutzerumgebung des INFORM-Fenstersystems tet.

FINANZ ist

[Fabian 86]

eingebet-

F o r m u l a r e und Formularfelder sind Objekte von spezialisierten Klassen

des Benutzerschnittstellen-Baukastens

[Fischer, Lemke, R a t h k e 8 7 ] .

den die oberste,

sichtbare Ebene.

für den Benutzer

werden D a t e n s t r u k t u r e n der A n w e n d u n g dargestellt. ten Ebene als ein Netz von F r a m e s

In den

Sie bil-

Formularen

Diese ist auf der zwei-

[Minsky 75] realisiert, die Wissen aus

dem Bereich der P r o j e k t f i n a n z i e r u n g repräsentieren.

Sie beschreiben

zepte wie Qualifikationen, P r o j e k t e , die P r o j e k t d a u e r , Daten,

Kon-

Grenzwerte,«

Kosten, jährliche Steigerungsraten sowie Abhängigkeiten zwischen den Attributen dieser Konzepte.

F r a m e s sind auf der untersten Ebene mit Hilfe von

O b j T a l k - O b j e k t e n implementiert

Abbildung 12.

[ R a t h k e C. 8 7 ] ,

Die S y s t e m s t r u k t u r von FINANZ.

Die Benutzeroberfläche besteht aus erweiterten K o m p o n e n t e n des Benutzerschnittstellen-Baukastens. Diese erlauben die zugrundeliegenden S t r u k t u r e n des anwendungsspezifischen Wissen unter verschiedenen Perspektiven zu betrachten. Die framebasierten K o m p o n e n t e n der Wissensbasis sind mit Hilfe von O b j T a l k - O b j e k t e n realisiert.

69

FINANZ

In den vorangegangenen Abschnitten wurde FINANZ aus der Sicht der Benutzer dargestellt.

Die F u n k t i o n a l i t ä t von F o r m u l a r e n und F o r m u l a r f e l d e r n

ist d u r c h die Framebeschreibungen der zweiten Ebenen definiert. d u n g 13 ist die D a u e r eines P r o j e k t s mit zwei F r a m e s beschrieben. riod-Frame

werden

die A t t r i b u t e

und l e n g t h

definiert.

(englisch: slots)

Das A t t r i b u t

start-date,

f u n d i n g - p e r i o d spezialisiert

In AbbilIm p e end-date period,

indem es zusätzlich das A t t r i b u t p r o j e c t e i n f ü h r t .

period slots start-date end-date length

a date range(1,1) a date range(1,1) a time-span

constraints date-difference (length = end-date - start-date) later (end-date start-date) funding-period ako period slots project start-date

a project with funding-period range (l.nil) default a date with day 1 month 1 year

Abbildung 13.

F r a m e s f ü r die Zeitdauer eines P r o j e k t s .

Diese F r a m e s beschreiben die Konzepte f ü r die Zeitdauer eines P r o j e k t s . Sie e n t h a l t e n A t t r i b u t e , Restriktionen, A n n a h m e n und Relationen zwischen Attributen. Diese Eigenschaften werden von allgemeinen auf spezielle F r a mes vererbt. Mit den A t t r i b u t e n sind Restriktionen v e r b u n d e n . F r a m e t y p d a t e sein. belegt werden.

So müssen Daten

vom

Das p r o j e c t - A t t r i b u t k a n n nur mit p r o j e c t - F r a m e s

Zusätzlich genügen die A t t r i b u t e Restriktionen bezüglich der

Anzahl ihrer W e r t e .

Im f u n d i n g - p e r i o d - F r a m e wird als A n f a n g s d a t u m ei-

nes P r o j e k t s der erste J a n u a r des nächsten J a h r e s a n g e n o m m e n , falls dieses A t t r i b u t nicht a n d e r s l a u t e n d spezifiziert wird. Zusätzlich

zu den Restriktionen,

die sich auf

einzelne A t t r i b u t e

beziehen,

e n t h a l t e n F r a m e s Beschreibungen, die sich auf das Verhältnis zwischen den

70

Systeme zur Entwurfsunterstützung

Attributen beziehen. Im Beispiel von Abbildung 13 beschreiben sog. Constraints die Tatsache, daß das Ende eines Zeitraums nach dessen Anfang erfolgt und daß die Projektdauer die zeitliche Differenz zwischen Ende und Anfang ist. Die in diesem Beispiel dargestellten Frame-Eigenschaften werden in Systemverhalten umgesetzt [Rathke C. 87]. Restriktionen wie die Einschränkung der D a t u m s a t t r i b u t e auf d a t e - F r a m e s resultieren in der Interpretation von Benutzereingaben als Datumsangaben (vgl. Abbildung 2). Constraints bewirken deren Überwachung bei Veränderung der beteiligten A t t r i b u t e . Sie bewirken auch die Ergänzung fehlender Werte, soweit diese eindeutig bestimmbar sind. Die Frames aus dem Bereich der Projektfinanzierung werden konkretisiert, d.h. auf die gegebene Situation angewandt, wenn der Benutzer neue Objekte der Systemoberfläche erzeugt. Die Erzeugung eines Formularfeldes und dessen Charakterisierung als Dauer, d.h. als zeitliche Differenz zweier Daten, bewirkt die Etablierung des f u n d i n g - p e r i o d - F r a m e s . Die dort definierten Restriktionen werden überprüft und bei Verletzung dem Benutzer zur Entscheidung vorgelegt (vgl. Abbildung 9). Fehlende, aber durch die Framebeschreibung eindeutig bestimmbare Feldinhalte werden ergänzt.

4.

Schlußbemerkungen

Das Erstellen eines Formulars, die Definition einer neuen Sicht auf interne Strukturen und die Definition neuer Beziehungen zwischen Feldern machen die Prinzipien von FINANZ deutlich: • Durch Trennung von interner und externer Repräsentation können mehrere Sichten auf dieselben internen Strukturen erzeugt werden. • Interne und Beziehungen kann an der derungen an auf dieselben

externe Repräsentation sind über deklarativ beschriebene verbunden. Änderungen der internen Repräsentation Systemoberfläche unterschiedlich dargestellt werden. Änverschiedenen Teilen der Benutzerschnittstelle können sich internen Strukturen auswirken.

• Formulare und Formularfelder werden durch Kopieren und Editieren [Lenat, Prakash, Shepherd 86] erzeugt. Dies hat eine Reihe von Vorteilen: o Komplexe Eigenschaften der internen und externen Repräsentation werden übernommen, ohne daß sie explizit vom Benutzer spezifiziert werden müßten.

71

FINANZ

o Für das Erstellen von Feldern und Formularen ist die Kenntnis einer Spezifikationssprache nicht erforderlich. Die Definition erfolgt interaktiv durch direkte Manipulation [Hutchins et al. 86] von Bildschirmobjekten. o Die Konsistenz der Interaktionsform und der Objekteigenschaften wird aufrechterhalten. o Der Prozeß des Kopierens und Editierens wird durch Strukturen unterstützt.

ObjTalk-

• Durch Einrichten von Beziehungen zwischen Formularfeldern reichhaltige interne Strukturen aufgebaut: o Frames mit einer großen Zahl anwendungsbezogener nen werden instantiiert.

werden

Informatio-

o Inferenzprozesse werden zwischen Formularfeldern etabliert. o Informationsstrukturen zur Repräsentation von Begründungen für Feldinhalte werden eingerichtet. Dadurch können Werte auf ihre Ursachen zurückgeführt und Erklärungen für den Benutzer dynamisch erzeugt werden. o Der Benutzer beschreibt nicht mehr das „ W i e " der vom System zur Verfügung gestellten Funktionalität, sondern nur noch das ,,Was". Dies vollzieht sich auf einer höheren Abstraktionsebene und ist näher an den Problemen des Benutzers. • Die Aufteilung der Aufgaben und der' Kontrolle liegt beim Benutzer. Er entscheidet, welche Arbeit vom System übernommen werden soll. Mit FINANZ kann also eine formularbasierte Benutzerschnittstelle an Aufgabe und Benutzer angepaßt werden. Sowohl Aussehen wie S t r u k t u r der Formulare werden interaktiv gestaltet. Die so gestaltete Benutzerschnittstelle vermag den Benutzer bei seiner Aufgabe wirkungsvoll zu unterstützen. FINANZ erlaubt die prototypische Entwicklung von Formularen, die z.B. einen Fachmann im Bereich der Projektfinanzierung oder der Steuergesetzgebung bei der Konzeption und der Bearbeitung von Formularen unterstützen. FINANZ dient dabei als Bindeglied zwischen den Konzepten der Repräsentationssprache, also ObjTalk-Frames, und den Konzepten des Anwendungsgebiets. Die Beschränkung auf formularorientierte Anwendungen erlaubt eine zielgerichtete Unterstützung des Benutzers während der Entwurfsphase, so daß FINANZ auch von Personen benutzt werden kann, die keine Experten im Bezug auf die ObjTalk-Programmierung sind.

S y s t e m e zur Dialoguntersttitzung

PassiviBt

Wisybib

V

OTELLO

Einsatz eines T e x t f o r m a t i e r e r s als G r u n d l a g e eines passiven H i l f e s y s t e m s Joachim Bauer

In diesem Kapitel wird das „elektronische H a n d b u c h " OTELL0 1 vorgestellt, das Texte interaktiv präsentiert. Mit OTELLO k a n n der Benutzer einen Text nicht nur seitenweise lesen, sondern auch auf einzelne Kapitel, Abschnitte, Abbildungen, usw. direkt zugreifen. OTELLO wurde für die Präsentation von Benutzeranleitungen gebaut und kann somit als passives Hilfesystem betrachtet werden. Anhand von Bildschirmabzügen wird die Benutzerschnittstelle und die Funktionalität von OTELLO beschrieben. Die OTELLO zugrunde liegenden Strukturen und die Arbeitsweise von OTELLO werden erklärt. Wichtige beim Entwurf von OTELLO angewendete allgemeine Techniken werden diskutiert.

1. E i n l e i t u n g Heute werden sehr viele Benutzerhandbücher auf dem Rechner erstellt. Die dafür gespeicherten Informationen können zusätzlich genutzt werden, um dem Benutzer interaktiv Hilfe anzubieten. Das System OTELLO dient diesem Zweck. Aus einem für den Textformatierer SCRIBE erstellten Manuskript erzeugt OTELLO Beschreibungsdateien, die die Grundlage für ein „elektronisches H a n d b u c h " bilden. Die Verwendung eines solchen elektronischen Handbuchs hat verschiedene Vorteile. Der Zugriff auf bestimmte Referenzen oder Abbildungen kann beim elektronischen Handbuch sehr schnell erfolgen. Die textuelle Suche nach bestimmten Stichwörtern im Text ist bei gedruckten Büchern sehr aufwendig, bei elektronischen Handbüchern dagegen k a u m ein Problem. Dazu kommt die stete Verfügbarkeit des elektronischen Handbuchs für denjenigen, der am Terminal sitzt und somit auch das elektronische Handbuch zur Verfügung hat.

OTELLO steht für „an object-oriented implementation of an electronic book". Das System OTELLO wurde in großen Teilen von D. Holz implementiert und ist in [Holz 87] ausführlich beschrieben.

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter Sc C o . • Berlin • N e w York

76

Systeme zur Dialogunterstützung

2. D i e B e n u t z e r s i c h t v o n OTELLO Das Ziel von OTELLO ist, dem Benutzer sämtliche Möglichkeiten zu bieten, die ihm auch ein gedrucktes Buch bietet.

Solche Fähigkeiten sind beispiels-

weise das Blättern im Buch und das Aufsuchen von bestimmten Stellen aus dem Inhaltsverzeichnis oder dem Index.

Darüber hinaus sollen die besonde-

ren Fähigkeiten des Rechners genutzt werden.

Das ist in diesem

Zusam-

menhang vor allem die Fähigkeit, Textstellen zu finden, f ü r die es prinzipiell nötig wäre, ein Buch von vorne bis hinten durchzulesen. OTELLO stellt dem Benutzer folgende F u n k t i o n e n Leser auch auf ein gedrucktes Buch anwenden Springen

auf eine Seite, Nachgehen

zur Verfügung, die ein im

Text,

eines Verweises und Aufsuchen

kann:

Blättern

einer

Textstelle aus einem der Verzeichnisse. Eine Aufgabe, die bei Benutzung eines gedruckten Buches schwierig zu erledigen ist, ist die Suche nach einem bestimmten Begriff.

Es ist nicht mög-

lich, in vertretbarer Zeit alle relevanten Stellen zu finden.

OTELLO bietet

diese A r t der Suche an, und der Benutzer h a t die Gewähr, daß kein Vorkommen übersehen wird. Ein Vorteil gedruckter Bücher ist die Möglichkeit, mit dem Buch zu „arbeit e n " , d.h. beispielsweise Zettel hineinzulegen oder sich darin Notizen zu machen.

OTELLO bietet auf elektronischem Weg die Möglichkeit,

Lesezeichen

zu setzen, kurze A n m e r k u n g e n zu machen und etwas anzustreichen.

2.1 D a s

OTELLO-Fenster

Abbildung 1 zeigt, wie OTELLO sich d e m Benutzer präsentiert. LO-Fenster links oben ist in vier Bereiche unterteilt. links ist der Textbereich. mente.

Das OTEL-

Das große

Fenster

Rechts davon befinden sich die Bedienungsele-

Die beiden unteren Fenster bilden den Statusbereich.

Die Seitengröße der für OTELLO aufbereiteten D o k u m e n t e ist an die Größe des Textbereichs angepaßt. Seite gezeigt werden.

Es kann also zu einem Zeitpunkt genau eine

Der Statusbereich ist nochmals unterteilt:

ken Hälfte wird der D o k u m e n t e n s t a t u s angezeigt. Namen

des

gerade

inspizierten

Dokuments

und

Rechts davon ist der Systemstatus visualisiert.

In der lin-

Dieser besteht aus dem der

aktuellen

Seitenzahl.

Im Beispiel wird

f o r l n p u t angezeigt, d.h. es wird eine Eingabe erwartet.

waitlng

77

OTELLO

Content 8

2.3.3. Inserting

Tables

Text

Index 1

«.. >11 1 X — n b. n ui C»> u 1 2n» . n

Figures I

The simplest and most often used action while editing is inserting some text. Thus in BISY this is the most simple thing to d a It is done by typing in your text as with a typewriter.

The text typed in

appears to the right of the current position Text to the right of the current position is shifted right.

Xerox If you press the RETURN

key the current line is finished and a new

line created. Text to the right of the current position is taken down

Post It

Remind

to the new line.

2.3.4. Deleting

Mark

Text

You can delete text forward or backward, i.e. text right of the cursor or text left of the cursor. Deleting forward is done by pressing deleting backward by pressing the DEL key.

J,

Deleting characters can-

not be done beyond the end or beginning of a line. Lines can be deleted by pressing the line key on the numeric keypad

Turn

Document

: bisy

Abbildung 1.

actual

page

Turn

: 11

Das OTELLO-Fenster.

Die Bedienungselemente von OTELLO sind sogenannte Buttons. Selektiert der Benutzer einen Button mit der Maus, wird eine an den Button gebundene Aktion ausgelöst. Während des Ablaufs dieser Aktion färbt sich der Button dunkel und zeigt so den aktiven Zustand an. Die mit Turn und einem Vorwärts- bzw. Rückwärtspfeil beschrifteten Bedienungselemente dienen zum Vorwärts- und Rückwärtsblättern um eine Seite. Möchte der Benutzer auf eine bestimmte Seite springen, hat er eine direkte und mehrere indirekte Möglichkeiten. Nach Selektieren des Buttons Jump t o wird er zur Eingabe einer Seitenzahl aufgefordert (siehe Abbildung 2). Durch Auswahl des Buttons ok wird die Eingabe abgeschlossen und die entsprechende Seite im Textbereich angezeigt. Nach einer falschen Eingabe wird der Benutzer auf die möglichen Werte hingewiesen (siehe Abbildung 3). Eine Eingabe kann durch Selektieren des Buttons Abort abgebrochen werden, wodurch OTELLO wieder in den Eingabezustand übergeht.

78

S y s t e m e zur

DialogunterstUtzung

'Contents ¡dialog-window 2.3.3.

Inserting

T h e simplest and

Type the number of the desired page

most

some text. Thus in BIS1

page number : 75|

«lone by typing in your

Abort

appears to the right of current position is shift«*

Xerox If you press the RETURN

key the current line is finished and a new

line created. Text t o the right of the current position is taken down

Post It T Remind

to the new line.

2.3.4. Deleting

Mark

Text

You can delete text forward or backward, i.e. text right of the cursor or text left of the cursor. Deleting forward is dose by pressing deleting backward by pressing the DEL key.

d,

Deleting characters can

not be done beyond the end or beginning of a line. Lines can be deleted by pressing the fine key on the numeric keypad

Turn

Turn

actual page : 14

Document

A b b i l d u n g 2.

type a page-number

S e i t e n e i n g a b e bei OTELLO.

help-window The pagenumber is out of range . It must be a positive integer or zero

OK

A b b i l d u n g 3.

OTELLO weist a u f eine f a l s c h e E i n g a b e h i n .

2.2 D a s A r b e i t e n mit

OTELLO

I n d i r e k t e M ö g l i c h k e i t e n , auf eine Seite zu p o s i t i o n i e r e n , b i e t e n d i e V e r z e i c h nisse (die vier

Buttons

rechts

Contents, Index, Figures den

Index,

das

oben)

und

und

Tables

Abbildungsverzeichnis

und

der

Button

stehen das

Find.

für das

Die

Buttons

Inhaltsverzeichnis,

Tabellenverzeichnis.

Nach

79

OTELLO

Auswahl eines Verzeichnis-Buttons erscheint ein Menü, das die Einträge des Verzeichnisses enthält. Nach Auswahl eines Eintrags erscheint im Textbereich die Seite, auf der das zugeordnete Objekt zu finden ist. Wenn der Benutzer keinen Eintrag auswählt, bleibt der Textbereich unverändert. Die Menüs für das Inhaltsverzeichnis und den Index haben noch zwei Besonderheiten. Da bei langen Dokumenten das gesamte Inhaltsverzeichnis nicht auf eine Bildschirmseite paßt, wird am Anfang nur die höchste Ebene der Dokumentenstruktur angezeigt, d.h. man sieht nur die Kapitelüberschriften. Durch Auswahl eines Kapitels mit dem rechten Mausknopf wird das Kapitel expandiert, d.h. die nächste Ebene der Überschriftenhierarchie wird angezeigt. Die Abbildungen 4 und 5 illustrieren diesen Vorgang.

Table of Contents I 1. Introduct Ion 2. Editing With BISY 3. BISY tor Programmers I. Command Summary II . BISY Variables

Abbildung 4.

11 5 50 79 117

Inhaltsverzeichnis eines Dokuments.

Table of Contents 1. Introduction 2. Editing With BISV 2.. 1. Invoking BISY 2,.2. Finishing and Interrupting BISY 2 3. Simple Editing 2..4. Advanced Editing 2..5. Using the Mouse and the Menus 2..6. Getting Out of Trouble 2..7. Differences to EMftCS 3. BISY for Programmers I. Command Summary II. BISY Variables

Abbildung 5.

1 5 5 7 8 20 38 40 47 50 79 117

Inhaltsverzeichnis nach Expansion einer Uberschrift.

Das Indexmenü zeigt immer einen Ausschnitt aus dem Index, der durch Scrollen verändert werden kann. Da dies, wenn man beim Buchstaben ,,A" steht und einen mit ,,Z" beginnenden Eintrag sucht, sehr langwierig sein kann, kann der Benutzer den Button im Titel des Menüs auswählen, wodurch er zur Eingabe einer zu suchenden Zeichenfolge aufgefordert wird. Nach Eingabe der Zeichenfolge wird der Auswahlbalken über dem ersten Eintrag positioniert, der diese Zeichenfolge enthält, und der Benutzer kann

80

S y s t e m e zur D i a l o g u n t e r s t ü t z u n g dialog-window I lype the s e a r c h - s t r i n g . I f the s t r i n g [ is not found, nothing happens

67 16 28 28 28 59 60 62 8 50 79 79 24 53 79 28 79 79 43 12 80

string : loadf Abart

M?. A t t r i b u t e s - appearance on f i l e s BISY process - s t o p p i n g and resuming BISY user f u n c t i o n s Back-tab Bel 1 B i n d i n g a command t o a key B i n d i n g a f u n c t i o n t o a key Bobp Bold o v e r p r i n t Bold-overprint-p Bolp Bottom l i n e Break l e v e l Buff e r - 1 i s t Buffers - multiple Buffers Buttons o f the mouse CTRL Change t i t l e Change f i l e Change-f i l e Change-font Change-read-table Change-t i t l e Classes Clear-attribute CI ear-bo I d - o v e r p r i n t Clear-shadow-pr i n t CI ear-under 1ine

A b b i l d u n g 6.

1

32 38 11 23 23 80 80 81 81

72

81

82 82 82

Suche im Index eines D o k u m e n t s .

mit der n o r m a l e n M e n ü a u s w a h l f o r t f a h r e n .

A b b i l d u n g 6 zeigt den V o r g a n g

der S u c h e im Index. O f t finden sich im T e x t Verweise a u f a n d e r e T e x t s t e l l e n , beispielsweise pitelüberschriften

oder

sichtbar

indem

machen,

Abbildungen. er den

scheinen d a n n unterstrichen.

Diese

Textbereich

Verweise

kann

selektiert.

der

Ka-

Benutzer

Alle Verweise

er-

N a c h Selektieren eines unterstrichenen Verwei-

ses wird die Seite dargestellt, auf der sich d a s referenzierte O b j e k t

befindet.

Eine Möglichkeit, eine beliebige Stelle zu finden, bietet die Suche von chenfolgen mit d e m B u t t o n F i n d .

N a c h Selektieren des B u t t o n s F i n d

der B e n u t z e r zur E i n g a b e einer Zeichenfolge a u f g e f o r d e r t .

F a l l s schon

Zeiwird eine

OTELLO

81

f ind-keyword-window

Abbildung 7.

Eingabe einer zu suchenden Zeichenfolge bei OTELLO.

Zeichenfolge eingegeben wurde, k a n n auch durch Auswahl von Find

last

oder Find next das letzte bzw. nächste V o r k o m m e n der Zeichenfolge gesucht werden (siehe Abbildung 7). Falls der Benutzer den dargebotenen Text oder Teile davon lieber auf P a pier lesen möchte, kann er mit d e m B u t t o n Xerox das gesamte

Dokument

Mit d e m B u t t o n Pick k a n n

oder einzelne Seiten ausdrucken

lassen.

neues Buch „gegriffen" werden.

Die erste Seite dieses D o k u m e n t s erscheint

dann

neue

im

Textbereich,

und

das

Dokument

kann

inspiziert

werden.

Durch die Verwendung mehrerer OTELLO-Fenster können verschiedene k u m e n t e gleichzeitig angesehen werden. kument

entstehen,

wenn

ein

Do-

Mehrere Sichten auf dasselbe Do-

dieses gleichzeitig

in

mehreren

OTELLO-Fenstern

dargestellt wird. Die V e r w e n d u n g von Lesezeichen soll es ermöglichen, mit d e m Buch zu arbeiten:

Beliebige Stellen eines D o k u m e n t s können mit beschrifteten Zetteln

versehen werden (Post It) und so zu einem späteren Z e i t p u n k t wieder aufgefunden werden (Remind).

Mit dem T e x t m a r k e r (Mark) k a n n ein Benutzer

f ü r ihn wichtige Textstellen auf den einzelnen Seiten eines D o k u m e n t s anstreichen.

3. A r c h i t e k t u r und A r b e i t s w e i s e v o n OTELLO Die prinzipielle Arbeitsweise von OTELLO wird von der F o r d e r u n g b e s t i m m t , vorhandene Dokumente als

„Manuskriptdateien"

Walker 80] vor.

zu benutzen. für

das

Die vorhandenen

Dokumente

Textformatierungssystem

SCRIBE

liegen [Reid,

In den M a n u s k r i p t d a t e i e n sind die Texte so beschrieben,

daß aus ihnen (im Idealfall) Texte f ü r verschiedene Ausgabegeräte wie La-

82

Systeme zur Dialogunterstützung

serdrucker, Typenraddrucker usw. erzeugt werden können, ohne das Manuskript ändern zu müssen. Abbildung 8 zeigt oben ein Beispiel für eine Manuskriptdatei und unten das Resultat des Textes, nachdem dieser für einen Laserdrucker formatiert wurde.

8SubHeading(Verzelchnlsse

bei

OTELLO)

Das System OTELLO hat folgende Verzeichnisse: 8Begln 8I:§\das Inhaltsverzeichnis des Dokuments 0I:§\das §I:e\das

Abblldungsverzelchnls

des

Dokuments

Tabellenverzeichnis

des

Dokuments

SI:0\das Stichwortverzeichnis SEnd

des

Dokuments

V e r z e i c h n i s s e bei

OTELLO

Das System OTELLO hat folgende Verzeichnisse: Contents:

das Inhaltsverzeichnis des Dokuments

Figures:

das Abbildungsverzeichnis des Dokuments

Tables:

das Tabellenverzeichnis des Dokuments

Index:

das Stichwortverzeichnis des Dokuments

Abbildung 8.

Eine Manuskriptdatei für den Textformatierer das Resultat der Formatierung.

SCRIBE und

Mit Hilfe des P r o g r a m m s SCBG2 können für den Laserdrucker formatierte Dateien auf Bitgraph-Terminals visualisiert werden. Dieses P r o g r a m m wird benutzt, um die Texte darzubieten. Neben dieser textuellen Information benötigt OTELLO für die Verzeichnisse, den Index und das Verfolgen von Verweisen noch zusätzliche Information. Die Formatieranweisungen von SCRIBE wurden zu diesem Zweck um Anweisungen erweitert, die Informationen über die T e x t s t r u k t u r in eine Datei schreiben. Diese Datei wird während der Laufzeit von OTELLO geladen, um die für eine objektorientierte Repräsentation der Dokumentenstruktur nötigen Objekte zu erzeugen: das

2

SCBG s t e h t für „Scribe to B i t G r a p h " . Es wurde im R a h m e n P . K a h l h ö f e r [ K a h l h ö f e r 85] i m p l e m e n t i e r t .

einer S t u d i e n a r b e i t

von

83

OTELLO

Dokument

an sich, seine Kapitel und Abschnitte, seine Abbildungen

Tabellen, kurz alle Bestandteile des Dokuments.

und

Die Eigenschaften eines

Dokumentbestandteils sind im Objekt, das diesen Bestandteile repräsentiert, beschrieben.

So kann beispielsweise ein Abschnitt nach der Seite gefragt

werden, an der er beginnt, oder nach dem Kapitel, in dem er sich befindet. Die Benutzerschnittstelle von OTELLO wurde mit Bausteinen des in 86]

beschriebenen INFORM-Fenstersystems erstellt.

nutzereingaben

verarbeitet und

[Fabian

In ihr werden die Be-

mit Hilfe der Objekte, die das

repräsentieren, in für SCBG geeignete Eingaben umgesetzt.

Dokument

SCBG gibt d a n n

die Texte seitenweise im Textbereich aus. Zusammengefaßt besteht OTELLO aus SCRIBE-Erweiterungen, matierer

SCRIBE selbst,

dem P r o g r a m m

aus

objektorientierten

SCBG und einer Benutzerschnittstelle.

das Zusammenwirken dieser Bestandteile.

dem

Textfor-

Programmkonstrukten,

aus

Abbildung 9 zeigt

84

S y s t e m e zur D i a l o g u n t e r s t ü t z u n g

4. Angewendete Methoden Hier sollen noch e i n m a l wichtige in OTELLO a n g e w e n d e t e M e t h o d e n tert werden.

Als erstes wird hierzu OTELLO in einen größeren

hang gestellt: es w u r d e als Hilfesystem implementiert. allgemein

interessanten

Abschnitten

über

zwei bisher

nur

eingegangen.

die

Techniken

werden

„Buch-Metapher"

am

Rande

erwähnte

erläu-

Zusammen-

Die für Hilfesysteme in

den

und die B e n u t z e r f r e u n d l i c h k e i t

diskutiert.

auf

wichtige

Dann

Eigenschaften

wird von

OTELLO

Zuletzt wird die Wichtigkeit der o b j e k t o r i e n t i e r t e n

Program-

mierung für die I m p l e m e n t i e r u n g von S y s t e m e n wie OTELLO e r l ä u t e r t .

4.1 OTELLO als H i l f e s y s t e m Mit OTELLO k a n n

man

Absicht

Anleitungen

entworfen,

Bildschirm zu bringen.

zwar

beliebige T e x t e zur

lesen, es wurde aber

Benutzung

von

Programmen

in auf

der den

Wenn m a n diesen Sonderfall b e t r a c h t e t , ist OTELLO

ein H i l f e s y s t e m 3 u n d zwar ein passives, statisches Hilfesystem. Ein

wichtiger

Punkt

bei

passiven

ken, A n f r a g e n an sie zu stellen. zielte I n f o r m a t i o n

kommen.

Hilfesystemen

sind

angemessene

Techni-

Der F r a g e n d e soll möglichst schnell an ge-

Durch

die Verzeichnisse,

die S u c h e

von

Zei-

chenfolgen und d a s N a c h g e h e n von Verweisen bieten sich d e m B e n u t z e r von OTELLO mehrere Möglichkeiten, Hilfe zu erfragen.

Diese sind die A u s w a h l

aus M e n ü s

mit

bei

den

Verzeichnissen,

Stichwortsuche

dem

Button

Find

und N a v i g a t i o n d u r c h d a s N a c h g e h e n von Verweisen (siehe hierzu auch K a pitel X ) . Ein weiterer wichtiger P u n k t bei Hilfesystemen ist die P r ä s e n t a t i o n der Hilfeinformation. information

so

Wenn d a s Hilfesystem von Nutzen sein soll, muß die Hilfedargestellt

werden,

daß

sie

leicht

verständlich

ist.

OTELLO besteht diese D a r s t e l l u n g aus T e x t , der mit A b b i l d u n g e n sein k a n n .

Bei P r o g r a m m b e s c h r e i b u n g e n sind hier insbesondere

a b z ü g e nützlich.

Ein P u n k t ,

Q u a l i t ä t der Hilfetexte. ner Hilfesysteme botenen Ein

3

Bildschirm-

auf den OTELLO keinen Einfluß hat, ist die

Wie N . Borenstein in seiner E v a l u a t i o n

[Borenstein 8 5 ]

T e x t e s ein wichtiger

wesentliches

Kriterium

ist

Bei

gemischt

verschiede-

festgestellt hat, ist die Q u a l i t ä t des darge-

Maßstab dabei

. . . . . V e r g l e i c h e die D e f i n i t i o n v o n H i i f e s y s t e m e n P r o g r a m m b e z e i c h n e t w e r d e n , d a s bei der explizite E r k l ä r u n g e n h i l f t . "

für die Effizienz eines die G l i e d e r u n g

in [ B a u e r Benutzung

88]: eines

Hilfesystems.

des T e x t e s .

Weitere

, , A l s H i l f e s y s t e m soll j e d e s interaktiven Systems durch

OTELLO

85

Kriterien für eine gute T e x t g e s t a l t u n g gibt R . Houghton

[Houghton 84]

an:

Nach Hougthon sollten keine zu großen gleichförmigen Textblöcke verwendet werden.

Der T e x t sollte so angeordnet sein, daß das F o r m a t schon Hinwei-

se auf wichtige

und weniger wichtige P u n k t e

gibt.

Wenn

zu einem

s t i m m t e n P u n k t sehr viel Information vorhanden ist, sollten nicht Seiten

Hilfe gegeben

weitere U n t e r p u n k t e

werden, sondern

eine kurze Beschreibung,

zur richtigen Information führt.

be-

mehrere

die

durch

Die Hilfe sollte

auf

konsistente Weise dargeboten werden, d.h. T e x t e , die Sachverhalte desselben T y p s beschreiben, sollten immer dasselbe F o r m a t haben und in e t w a gleich detailliert sein. Bei OTELLO wird die Hilfeinformation als T e x t repräsentiert, dessen einzelne Teile d u r c h Anweisungen für den T e x t f o r m a t i e r e r k n ü p f t sind.

SCRIBE miteinander

möglich ist, Informationen aus dem K o n t e x t eines P r o g r a m m s den.

ver-

Diese A r t der R e p r ä s e n a t i o n hat den Nachteil, daß es nicht mitzuverwen-

Ihr Vorteil ist dagegen die A n w e n d u n g s u n a b h ä n g i g k e i t und die relativ

einfache Erstellung von Texten.

4.2 Die

Buch-Metapher

Ein wichtiges Ziel bei der Implementierung rung von OTELLO nach einem realen B u c h . die d e m

Benutzer

schon

von

wand erfordert: Modell,

sondern

Büchern

her

bekannt

Zu lernen ist nicht d a s der Interaktion nur

sind,

des elektronischen B u c h s weniger

die spezielle A r t

Dadurch wird die Desktop-Metapher deren Bereich:

Die Verwendung der K o n z e p t e ,

„normalen"

den Vorteil, daß die Benutzung

von OTELLO war die Modellie-

der

Interaktion

[ S e y b o l d 81]

es entsteht die , , B u c h - M e t a p h e r "

hat

Lernauf-

zugrundeliegende

mit

dem

Rechner.

übertragen auf einen an(vgl. hierzu die

„Labor-

M e t a p h e r " in K a p i t e l II). D. Holz hat in

[Holz 87]

die Verwendung des traditionellen B u c h s ,

sondere des Lehrbuchs, untersucht.

insbe-

Dabei sind neben dem eigentlichen se-

quentiellen Lesen eines Buchs oder von Teilen eines B u c h s die Informationssuche u n d begleitende Arbeiten wichtig.

Abbildung

10 zeigt, wie sich die

Bedürfnisse eines Lesers auf die verschiedenen S u c h f u n k t i o n e n von

OTELLO

abbilden. Die im wesentlichen durchgeführten begleitenden Arbeiten sind d a s Einlegen von Lesezeichen, von

Notizen.

Remind

d a s Markieren Diese

werden

von wichtigen

bei

OTELLO

und Mark d u r c h g e f ü h r t , wobei sich

den Lesezeichen notierten Stichworte

Stellen

mit

den

Notizen

beschränken.

und

das

Funktionen

Anfertigen Post

It,

bisher auf kurze,

auf

86

Systeme zur D i a l o g u n t e r s t ü t z u n g Wunsch des Benutzers

Vorgehensweise

Button

b e k a n n t e Seite lesen

Aufschlagen der Seite

Jump t o

Information über einen b e s t i m m t e n Begriff finden

Suche im Index

Index

grob umschriebene Information finden

Suche im Inhaltsverzeichnis

Contents

Seite mit u n g e f ä h r b e k a n n t e m Layout finden

Blättern

Turn

Schmökern

Ansehen der Verzeichnisse u n d Aufschlagen von interessanten Stellen

Contents, Figures, Tables

das ganze Buch lesen

Blättern

Turn

Abbildung 10.

A r t e n der Informationssuche in Büchern.

4.3 B e n u t z e r f r e u n d l i c h k e i t Neben der einfachen Bedienung auf der Ebene des zugrundeliegenden

Mo-

dells der Buch-Metapher war eine leicht zu erlernende I n t e r a k t i o n s f o r m ein Ziel beim E n t w u r f von OTELLO.

Alle F u n k t i o n e n können durch die Betäti-

gung eines B u t t o n s ausgelöst werden.

Kommandonamen,

an die sich

Benutzer erinnern muß und die er eintippen müßte, gibt es nicht.

der

Jede In-

teraktion k a n n d u r c h den Benutzer abgebrochen werden, ohne d a ß dies zu einem Fehler f ü h r t (siehe hierzu beispielsweise A b b i l d u n g 7). der Interaktion wird im Statusbereich ständig angezeigt. gen mit OTELLO haben gezeigt, daß es nach sehr kurzer

Der

Zustand

Unsere E r f a h r u n Einarbeitungszeit

möglich ist, mit diesem System zu arbeiten.

4.4 O b j e k t o r i e n t i e r t e

Programmierung

Die von SCRIBE definierten K o n z e p t e wie Kapitel, Abschnitte,

Abbildungen

etc. k a n n m a n im o b j e k t o r i e n t i e r t e n Sinne als Klassen, die d a r a u s zierten Texte als Instanzen dieser Klassen, b e t r a c h t e n . te es nahe, OTELLO o b j e k t o r i e n t i e r t zu implementieren.

produ-

Diese Sichtweise legZu j e d e m SCRIBE-

K o n z e p t gibt es eine O b j T a l k - K l a s s e , von der beim F o r m a t i e r e n eines Dokuments

Instanzen

erzeugt

werden.

Diese Instanzen

sind s t a r k

vernetzt.

Ein A b s c h n i t t h a t beispielsweise Wissen über das Kapitel, in d e m er vork o m m t , und die Seite, auf der er beginnt.

Diese A r t der V e r n e t z u n g

ist

eine charakteristische Eigenschaft objektorientierter Systeme (vgl. Kapitel X, Abschnitt 1).

87

OTELLO Die objektorientierte

Repräsentation

der

Dokumentenstruktur

hat die folgenden Vorteile:

Durch die direkte Abbildung der

zepte

während

auf

ObjTalk-Klassen

des

Formatierlaufs

bei

OTELLO

SCRIBE-Kon-

entfällt

ein

Pro-

grammlauf, bei dem die Dokumentenstruktur analysiert und in eine interne Struktur

umgesetzt werden muß.

Die explizite Repräsentation

ments als Objekt erlaubt einen natürlichen und erleichtert die Programmierung

des

Zugriff auf seine

wesentlich.

Die gleichzeitige

dung mehrerer Dokumente wird durch die Verwendung

von

Doku-

Bestandteile Verwen-

Objektnetzen

wesentlich vereinfacht, weil bei Wechsel des Dokuments nicht wie bei der prozeduralen werden

Programmierung

muß,

sondern

eine ganze Menge von Variablen

lediglich

das

Objektnetz

ausgetauscht

umgesetzt zu

werden

braucht.

5. Schlußfolgerungen und Ausblick OTELLO ist ein nützliches Werkzeug, um sich einen Überblick über ein Prog r a m m oder Information über das allgemeine Verhalten von Programmteilen zu verschaffen.

Uber das Verhalten eines P r o g r a m m e s in einer bestimmten

Situation

OTELLO

kann

keine A u s k u n f t geben,

zum laufenden P r o g r a m m hat. dungsunabhängigkeit:

weil es keine

Verbindung

D a f ü r hat es aber den Vorteil der Anwen-

Dokumentationen für jedes P r o g r a m m können so ge-

schrieben werden, daß sie mit OTELLO präsentiert werden können.

Darüber

hinaus ist es auch relativ einfach, schon bestehende T e x t e so aufzubereiten, daß OTELLO als Hilfesystem verwendet werden kann.

Die Verwendung des

gleichen Texts für eine gedruckte Dokumentation und d a s Hilfesystem bietet den Vorteil, daß die im Handbuch stehende Information und die Hilfetexte konsistent sind. OTELLO ist ein gutes Beispiel

für ein mit Methoden

Mensch-Computer-Kommunikation

der

implementiertes System.

wissensbasierten E s ist hat eine

ins sich konsistente, einfach zu bedienende Benutzerschnittstelle und auf

einer

vollständig

objektorientierten

Implementierung.

basiert

Daneben

ist

OTELLO auch ein Baustein für andere Systeme, in denen es eingesetzt werden kann, um dem Benutzer

Informationen über die Bedienung oder

den

inhaltlichen Hintergrund eines Anwendungssystemes zu präsentieren. Eine Weiterentwicklung bar.

Eine

davon

von OTELLO ist in verschiedene Richtungen

ist eine weitergehende

Charakters eines Dokuments. beitet

und

dieses

durch

Unterstützung

des

denk-

individuellen

Wenn ein Benutzer mit einem Dokument ar-

Lesezeichen

und

Anmerkungen

für seine

Zwecke

88

Systeme zur Dialogunterstützung

modifiziert, erhält es einen individuellen Charakter. Dieser individuelle Charakter sollte nicht nur für eine bestimmte Sitzung gelten, sondern aufbewahrt werden, so daß ein Benutzer bei der nächsten Sitzung denselben Zustand des Dokuments wieder vorfindet. Eine andere mögliche Weiterentwicklung ist die Integration von OTELLO in andere Systeme. Man k a n n sich beispielsweise vorstellen, daß eine aktive Hilfekomponente wie AKTIVIST (siehe Kapitel VII) aufspürt, welche Konzepte einem Benutzer nicht b e k a n n t sind, und die Beschreibung dieser Konzepte an OTELLO delegiert.

VI

PASSIVIST

Ein natürlichsprachliches für einen T e x t e d i t o r

Hilfesystem

Andreas Lemke

In diesem Kapitel wird ein passives natürlichsprachliches Hilfesystem für einen Texteditor vorgestellt. Besonderer Wert soll auf Erfahrungen gelegt werden, die für die Entwicklung ähnlicher Systeme wichtig sein können. Hilfesysteme basieren auf Wissen sowohl über das Anwendungsgebiet wie auch über das Anwendungssystem, bei dessen Gebrauch der Benutzer unterstützt werden soll. Inhalt und Bedeutung dieser Wissensgebiete für Hilfesysteme werden anhand des Anwendungsgebietes Texteditieren diskutiert. PASSIVIST ist implementiert als ein System, das im wesentlichen aus vier Komponenten mit den folgenden Aufgaben besteht: morphologische Analyse der Benutzereingabe, syntaktische Analyse, Problemlösen und Präsentation der Lösung. Die Eigenschaften und die Implementationsweise dieser Komponenten werden beschrieben. Die natürlichsprachliche Mensch-Computer-Kommunikation beruht auf dem Vorhandensein einer gemeinsamen begrifflichen und sprachlichen Basis. Da diese nicht immer im Idealzustand existiert (der Benutzer möchte j a von einem Hilfesystem lernen), müssen Methoden gefunden werden, um diese Probleme zu überwinden. In einem abschließenden Systems gegeben.

Abschnitt

wird eine Bewertung

des

vorgestellten

Es werden Anforderungen eines Hilfesystems an das An-

wendungssystem, zu dem es gehört, diskutiert, und es wird die Rolle von passiven Hilfesystemen für interaktive Systeme der Zukunft angesprochen.

1. E i n l e i t u n g Die Funktionalität moderner Computersysteme ist in ständigem Anstieg begriffen.

Fortschritte in der Softwaretechnologie und die Verfügbarkeit von

persönlichen Rechnern mit großer Speicherkapazität

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter & C o . • Berlin • New York

und einer Leistungsfä-

90

Systeme zur Dialogunterstützung

higkeit, die früher nur Großrechner boten, haben diese Entwicklung möglich gemacht. Diese zunehmende Funktionalität bringt allerdings auch Probleme mit sich. Kein Benutzer kann ein modernes Computersystem völlig beherrschen. Durchschnittsbenutzer kennen sich in den Teilbereichen des Systems relativ gut aus, die f ü r die tägliche Arbeit genutzt werden. Sobald aber eine Aufgabe gelöst werden muß, die etwas aus der Reihe fällt, entstehen Schwierigkeiten. Mag das System auch eine Eigenschaft haben, die gerade auf diese Aufgabe zugeschnitten ist, so ist es doch häufig der Fall, daß der Benutzer diese Eigenschaft nicht kennt oder nicht weiß, wie sie erfolgreich eingesetzt werden kann. Dieser Effekt wird sich verstärken, je weiter die Funktionalität von Computersystemen zunimmt. Eine Schlußfolgerung aus dieser Hypothese ist, daß moderne Computersysteme unter der Annahme entwickelt werden sollten, daß Lernen bei Bedarf die häufigste Lernstrategie sein wird. Es kann nicht mehr angenommen werden, daß Benutzer das meiste über ein System im voraus erlernen. Hilfesysteme sind eine Antwort auf dieses Problem. Außer den Systemkomponenten, die den Benutzer direkt bei der Bearbeitung seiner Aufgaben unterstützen (z.B. Ergebnisse berechnen), müssen auch Systemkomponenten vorhanden sein, deren Aufgabe es ist, bei der Benutzung des Systems selbst zu helfen (Metasysteme). Selbstverständlich muß die Benutzung der Unterstützungskomponenten so einfach sein, daß ein Teufelskreis vermieden wird, d.h. daß die Verwendung der Unterstützungskomponenten nicht neue Unterstützungskomponenten erfordert. Eines der Probleme passiver Hilfesysteme ist die Formulierung der Anfrage. Wie kann der Benutzer sein Problem dem Hilfesystem beschreiben? Natürliche Sprache in gesprochener oder geschriebener Form bietet sich dazu an; das hier beschriebene System PASSIVIST verwendet dieses Verfahren. Eine stark abgeschwächte Form natürlicher Sprache sind Stichwörter. Ein Problem kann durch ein oder mehrere Stichwörter beschrieben werden. Eine weitere Art von Hilfesystemen sind navigatorische Hilfesysteme. Hier bewegt sich der Benutzer schrittweise suchend immer näher an die gewünschte Information heran, kann aber auch explorativ die Eigenschaften des Systems kennenlernen. Der Informationsraum navigatorischer Hilfesysteme hat meist hierarchische oder netzartige Struktur. Hilfesysteme einfachster Art sollen funktionale Hilfesysteme genannt werden. Bei dieser Art von Hilfesystemen spezifiziert der Benutzer eine Operation und fordert die zugehörige Beschreibung an. Diese Hilfesysteme können heute in vielen Computersystemen gefunden werden.

91

PASSIVIST Das hier

beschriebene

System

PASSIVIST ist ein

sprachliches Hilfesystem f ü r den Texteditor BISY

prototypisches 1

[Bauer 8 4 ] .

natürlichU m einen

Eindruck von der Arbeitsweise des Systems zu vermitteln, folgen im nächsten A b s c h n i t t einige Beispieldialoge.

In Abschnitt 3 wird die Arbeitsweise

von PASSIVIST genauer dargestellt, Abschnitt 4 ist den P r o b l e m e n natürlichsprachlicher Hilfesysteme gewidmet.

Im letzten A b s c h n i t t folgt eine Kritik

des besprochenen Systems.

2. Beispieldialog Das naturlichsprachliche Hilfesystem PASSIVIST ist in der Lage, beim Editieren von T e x t , in den Problembereichen und ,,Löschen"

Hilfe zu geben.

„ P o s i t i o n i e r e n der

Schreibmarke"

Es k a n n F r a g e n b e a n t w o r t e n über das Po-

sitionieren der S c h r e i b m a r k e an b e s t i m m t e Stellen, wie zum Beispiel an den Anfang des Textes oder an das E n d e der aktuellen Zeile.

Löschungen kön-

nen sich auf W ö r t e r , Zeilen oder größere Textregionen beziehen. PASSIVIST t r i t t in A k t i o n , wenn der Benutzer einen Hilfewunsch äußert, indem er eine Hilfetaste b e t ä t i g t und seine F r a g e in ein auf d e m Bildschirm erscheinendes Hilfefenster eingibt.

Das System u n t e r s u c h t

zeigt an, welcher Teil der F r a g e verstanden wurde.

die Frage

und

D a r a u f h i n wird die Lö-

sung des P r o b l e m s d e m Benutzer in einer K o m b i n a t i o n aus V o r f ü h r - u n d E r k l ä r u n g s m o d u s vorgestellt.

U m eine bessere Verständlichkeit zu erreichen,

wird nach j e d e m Lösungsschritt der d a n n erreichte Zustand des Editors angezeigt.

Der Benutzer f ü h r t unter Kontrolle des Systems einen Schritt aus,

d.h. er b e t ä t i g t die angegebenen Tasten, und das System zeigt den nächsten Lösungsschritt usw.

Beispiel

1:

Der Benutzer m ö c h t e die Schreibmarke an das E n d e der editierten setzen.

Datei

E r betätigt die Hilfetaste, worauf ein Hilfefenster erscheint, in d e m

er a u f g e f o r d e r t wird, eine F r a g e zu stellen. Frage:

Wie Komme ich zum Ende der Datei?

Erkannte Wörter: zum Ende der Datei Ignorierte Wörter: Wie komme ich ?

^ PASSIVIST ist im R a h m e n einer Diplomarbeit in der Gruppe INFORM an der Universität Stuttgart entstanden [Lemke 84].

92

Systeme zur Dialogunterstiitzung

Das System zeigt an, was es v e r s t a n d e n hat. man

auch

in zwischenmenschlichen

Gesprächen

Dies ist ein V e r h a l t e n , finden

kann.

Es

das

erlaubt

d e m K o m m u n i k a t i o n s p a r t n e r , sich ein Modell über das Verstehen seines Gegenübers zu bilden (Dialogmodell) u n d , falls nötig, Mißverständnisse

aufzu-

klären. Das System u n t e r s u c h t

den Satz, kristallisiert das P r o b l e m des

heraus u n d berechnet eine Lösung, die aus den d e m Benutzer Editoroperationen

zusammengesetzt

ist.

Das W o r t

Benutzers

zugänglichen

„ D a t e i " wird

hier

als

der in den Editor geladene T e x t gedeutet, der nicht identisch m i t der entsprechenden auf Sekundärspeicher

liegenden Datei ist.

PASSIVIST versucht,

eine möglichst sinnvolle I n t e r p r e t a t i o n der Benutzeräußerung zu

finden.

Die Lösung des Benutzerproblems besteht hier aus einer einzigen Operation.

primitiven

Das Hilfesystem a n t w o r t e t :

Gib den Befehl: set-cursor-to-end-of-buffer Tippe dazu die Tastenfolge: ESC->

In Tastenfolgen sind die einzelnen Tasten durch Bindestriche getrennt. Beispiel: ESC-> bedeutet: drücke zuerst ESC und dann >. Getippte Taste: ESC Getippte Taste: > Zu diesem Zeitpunkt n i m m t das System an, daß der Benutzer A n f ä n g e r ist und noch keine E r f a h r u n g mit

Computertastaturen

hat.

Daher

Schreibweise von Tastenfolgen bei den ersten zwei Fragen e r k l ä r t .

Beispiel 2: Der Benutzer möchte eine Zeile löschen. Frage:

Wie kann ich die nächste Zeile löschen?

Erkannte Wörter: nächste Zeile löschen Ignorierte Wörter: Wie kann ich die ? Setze die Schreibmarke auf die gewünschte Zeile!

wird

die

PASSIVIST

93

Gib den Befehl: cursor-down Tippe die Taste: DOWN

Getippte Taste: ? Der Benutzer hat eine falsche T a s t e g e d r ü c k t .

D a s S y s t e m erklärt nun, wo

die richtige T a s t e zu finden ist, und fordert den Benutzer nochmals auf, die fehlende E i n g a b e zu machen. M i t UP, DOWN, LEFT und RIGHT sind die Pfeiltasten rechts oben gemeint. Tippe noch die Taste: DOWN

Getippte Taste: DOWN Der B e n u t z e r b e t ä t i g t nun die richtige T a s t e und sieht, wie die S c h r e i b m a r ke sich eine Zeile nach unten bewegt, dabei aber in derselben S p a l t e bleibt. Der

nächste

Schritt

v o m S y s t e m erklärt.

der

Lösung

ist

ziemlich

kompliziert

und

wird

D a s Hilfesystem kennt gewisse stereotypische

me, die einer E r k l ä r u n g bedürfen. Es g i b t keinen besonderen Befehl, um eine Zelle als Ganzes zu löschen. Man mup zuerst den Zeileninhalt und dann eine der beiden Zellengrenzen löschen. Zum Leeren einer Zelle geht man am besten an den A n fang der Zelle und löscht dann den Rest der Zelle. Gib den Befehl: set-cursor-to-beglnnlng-of-llne Tippe die Taste: ~A

~A wird eingegeben, indem man die CTRL-Taste herunterhält, die A-Taste drückt und dann die CTRL-Taste wieder losläpt. (Die CTRL-Taste b e f i n d e t sich ganz links auf der Tastatur) Getippte Taste: ~A

daher Proble-

94

Systeme zur D i a l o g u n t e r s t ü t z u n g

Auch die Eingabe von

CTRL-Tasten

wird d e m Benutzer a n f a n g s e r k l ä r t .

Der Benutzer t i p p t ~A, u n d das System erklärt den nächsten Schritt, n ä m lich den Rest der Zeile zu löschen. Gib den Befehl: rubout-line-right Tippe die Taste: ~K

~K wird eingegeben, indem man die CTRL-Taste herunterhält, die K-Taste drückt und dann die CTRL-Taste wieder losläßt. (Die CTRL-Taste befindet sich ganz links auf der Tastatur) Getippte Taste: ~K Der Benutzer t i p p t ~K und die Zeile wird leer.

Der letzte Schritt ist, eine

der Zeilengrenzen zu e n t f e r n e n . Gib den Befehl: rubout-line-left Tippe dazu die Tastenfolge: PF2-DEL

Das Kommando rubout-line-left verbindet, wenn die Schreibmarke am Zellenanfang steht, die aktuelle Zelle mit der vorhergehenden und löscht damit die aktuelle Zeile. Getippte Taste: PF2 Getippte Taste: DEL Nach dreimaliger E r k l ä r u n g , wie die C T R L - T a s t e b e n u t z t wird, n i m m t das System an, daß der Benutzer weiß, wie sie zu betätigen sind.

3. A r b e i t s w e i s e v o n

PASSIVIST

Hilfesysteme spielen eine Vermittlerrolle zwischen Benutzer, stem und Anwendungsgebiet. system Text.

der Texteditor

Anwendungssy-

Im Falle von PASSIVIST ist das Anwendungs-

BlSY, das Anwendungsgebiet

ist das Editieren

von

95

PASSIVIST

3.1 W i s s e n s b e r e i c h e v o n PASSIVIST PASSIVIST benötigt f ü r seine A u f g a b e Wissen sowohl über das A n w e n d u n g s gebiet als auch Uber das Anwendungssystem. Wissen Uber das Anwendungsgebiet Texteditieren beinhaltet z.B. die K e n n t nis von Konzepten

wie Buchstabe, W o r t , Zeile und Seite, Beziehungen

z.B. die, daß ein W o r t sich aus einer Folge von Buchstaben

wie

zusammensetzt

u n d d u r c h Leerzeichen von anderen W ö r t e r n g e t r e n n t ist, u n d

Vorgängen

wie z.B. das Erzeugen, Löschen, Kopieren u n d Suchen von Textteilen. K o n z e p t e aus d e m Anwendungsgebiet sind im Anwendungssystem auf Softwarekonzepte abgebildet.

In den meisten Fällen ist das keine eineindeutige

Abbildung, sondern eine Konkretisierung

und Spezialisierung.

„ W o r t " beispielsweise ist in d e m E d i t o r BlSY genauer definiert.

Der Begriff Es ist fest-

gelegt, welche Zeichen W ö r t e r bilden u n d welche nicht in einem W o r t e n t halten sein können. eines Wortes

O b z.B. ein Bindestrich oder ein A p o s t r o p h als Teil

betrachtet

werden

soll,

ist außerhalb

des T e x t e d i t o r s

nicht

festgelegt. Zusätzlich benötigt

das Hilfesystem weitere Begriffe, die spezifische Eigen-

schaften des Anwendungssystems

bezeichnen.

Ein ASCII-Zeichen

ist

zum

Beispiel ein wichtiger Begriff f ü r das Verständnis der T e x t d a r s t e l l u n g in einem Editor. Sonderzeichen

Ein ASCII-Zeichen ist entweder ein Buchstabe, eine Ziffer, ein oder

ein

Zwischenraum

M a n beachte, daß hier Zwischenräume

von

der

Größe

als diskrete

eines

Buchstaben.

Zeichen definiert

sind;

das widerspricht der intuitiven Vorstellung von Zwischenräumen als kontinuierliche geometrische A b s t ä n d e .

Dieses Verständnis h a t d a n n zur Folge,

daß zum Erzeugen u n d V e r ä n d e r n von Zwischenräumen dieselben

Operato-

ren angewendet werden können wie f ü r Buchstaben. Weiterhin

ist

Wissen

über

den

Benutzer

nützlich.

Informationen

über

Kenntnisse sowie über irrige Vorstellungen des Benutzers sind f ü r das Hilfesystem Voraussetzung, u m den Benutzer zu verstehen und ihm verständliche E r k l ä r u n g e n zu geben.

In PASSIVIST ist Wissen dieser A r t in einem einfa-

chen Modell des Benutzers repräsentiert

[Rieh 7 9 ] .

Eine der wichtigsten A u f g a b e n bei der Erstellung eines Hilfesystems ist die E r f a s s u n g der Hilfebedürfnisse der Benutzer. viele Benutzer

Schwierigkeiten?

Mit welchen P r o b l e m e n

Es m u ß vermieden

werden, einen

A u f w a n d in Teile des Hilfesystems zu stecken, die d a n n von den chen Benutzern nie in A n s p r u c h g e n o m m e n werden.

haben großen

tatsächli-

U m diese Bedürfnisse

96

Systeme zur Dialogunterstützung

zu ermitteln, k o m m t man nicht umhin, empirische Untersuchungen zu machen, Benutzer zu beobachten oder ein simuliertes Hilfesystem zu verwenden. Zu allgemeinem Hilfewissen gehört auch Wissen über Kommunikation und didaktisches Wissen. Was soll geschehen, wenn die Frage des Benutzers (teilweise) unverständlich ist? Wie detailliert sollen Fragen beantwortet werden? W a n n sollen zusätzliche Informationen gegeben werden, die nicht ausdrücklich erfragt wurden, die aber sehr wahrscheinlich vom Benutzer benötigt werden? Wie kann ein einfaches Modell des Anwendungssystems vermittelt werden, so daß geringfügige Details nicht erklärt werden müssen? PASSIVIST verfügt in diesem Gebiet über fest eingebaute Strategien, die nur eine Teilantwort auf diese Fragen darstellen.

3.2 S t r u k t u r v o n PASSIVIST PASSIVIST besteht aus vier wesentlichen Komponenten: morphologische Analyse der Benutzereingabe, syntaktische Analyse, Problemlösen und graphische Ausgabe der Problemlösung.

3.3 M o r p h o l o g i s c h e

Analyse

Die morphologische Analyse der Benutzeranfrage ist die erste Phase.

Hier

werden die in der Eingabe enthaltenen Wörter mit Hilfe eines Wörterbuchs in Wortstamm, Vorsilben und Endungen zerlegt.

Zusammengesetzte Wörter

werden erkannt und ihre Bestandteile identifiziert. Das Wörterbuch enthält die folgenden Klassen von Einträgen: • Verben: hat ein Verb einen zweiten S t a m m (geh - gib), so sind beide angegeben. Ebenso kann eine besondere Konjugation angegeben sein. • Vorsilben: in der morphologischen Wortstämmen getrennt. • Nomina • Adjektive

Analyse

werden

Vorsilben

können auch einen zweiten S t a m m besitzen (Wort -

von

Wörter).

werden wie Nomina behandelt.

• Abkürzungen

werden für verschiedene Sonderbehandlungen verwendet:

o Zahlwörter werden in Ziffern umgesetzt, o Synonyme werden vereinheitlicht. o Unregelmäßige Verben werden als Abkürzungen behandelt.

97

PASSIVIST

Die folgenden Beispiele zeigen, wie Wörter durch die morphologische Analyse in Komponenten zerlegt werden: des

Zeile-n-ende-s

Nominalstamm - n - Nominalstamm - Nominalsuffix Lös-ung-s-möglichkeit V e r b s t a m m - ung - s - Nominalstamm - Nominalsuffix (leer)

3.4 Syntaktische

Analyse

Die syntaktische Analyse in PASSIVIST wird von einem ausgeführt, das in OPS5

[Forgy 81]

det für seinen Anwendungsbereich die in Abbildung sche G r a m m a t i k .

Produktionensystem

implementiert ist.

In einer semantischen

Grammatik

PASSIVIST verwen-

1 dargestellte

semanti-

werden solche

Gram-

matikregeln formuliert, die direkt Konzepten aus einem bestimmten Anwendungsbereich entsprechen.

::= Buchstabe

I Zeichen

I Character



::= I Spalte I W o r t : := aktuelles

:nächst



::=

I vorherig

I Buffer

I vorvorherig

I

. I erst

I

I letzt

I vorletzt

I

I

der

::= Anfang

I Ende

::= der



::=

::=



I übernächst

I Zeile

: a n

I auf

I in

::= der

Abbildung 1.

I zu

::= löschen + G r a m m a t i k von PASSIVIST.

Nichtterminale Symbole erscheinen in spitzen K l a m m e r n . Der Operator + bedeutet, daß beide Operanden in der Eingabe an unspezifizierter Stelle vorkommen sollen.

Systeme zur Dialogunterstützung

98

Da auch die folgenden Phasen von PASSIVIST in OPS5 implementiert sind, können sie gut integriert werden. Das hat unter anderem den Vorteil, daß Mehrdeutigkeiten schon während der syntaktischen Analyse beseitigt werden können. Die Syntaxanalyse wird in einem bottom-up Verfahren durchgeführt. Immer wenn eine Folge von Wörtern gefunden wird, die einen Satzteil bilden können, wird diese Tatsache notiert. Wenn daraufhin passende Satzteile gefunden werden, die einen Satz bilden, dann wird dieser Satz gespeichert. Dieses Verfahren ermöglicht, eine Benutzereingabe in beliebiger Reihenfolge und nicht nur von links nach rechts abzuarbeiten. Dadurch ist das System in der Lage, auch unvollständige, teilweise inkorrekte oder dem System teilweise unverständliche Äußerungen zu bearbeiten. PASSIVIST e r k e n n t in S ä t z e n

wie

• Wie lösche ich die nächste Zeile? • Wie erreiche ich, daß die nächste Zeile gelöscht wird? • Ich möchte die nächste Zeile löschen. nur die entscheidenden Komponenten „löschen" und „nächste Zeile". Da die anderen Wörter ignoriert werden, erkennt PASSIVIST diese und viele ähnliche Formulierungen desselben Problems. Dabei besteht selbstverständlich die Gefahr der Mißinterpretation, die in der Praxis aber bislang keine entscheidende Rolle gespielt hat. Bei Positions- und Bereichsangaben wird allerdings eine genauere Analyse durchgeführt. PASSfVIST versteht Angaben wie • • • • deren

die drittletzte Zeile, das zweite Wort am Bufferanfang, an den Anfang der letzten Zeile, auf das zweite Zeichen des vorigen Wortes, Bedeutung

mit

einer

reinen

Stichwortanalyse

nicht

zu

bestimmen

wäre.

3.5 S e m a n t i s c h e

Analyse

Der nächste Schritt der Analyse ist, das Problem des Benutzers zu erkennen. Für die beiden Arten von Zielen Positionieren und Löschen werden folgende Heuristiken verwendet:

99

PASSIVIST

• E n t h ä l t der Satz eine der Präpositionen ,,auf", „ a n " , „ z u " oder „ i n " gefolgt von einer Ortsangabe, handelt es sich u m ein Positionierungsproblem. • E n t h ä l t der Satz an einer beliebigen Position das W o r t „löschen", so h a n d e l t es sich u m ein Löschproblem. Nach dieser P h a s e gibt PASSIVIST d e m Benutzer eine R ü c k m e l d u n g ,

welche

W ö r t e r e r k a n n t und welche ignoriert wurden (siehe Abschnitt 2).

3.6 L ö s u n g der

Benutzerprobleme

F ü r die von PASSIVIST behandelte A r t von P r o b l e m e n besteht eine Lösung aus einer Folge von Editorbefehlen, die den Editor in den gewünschten s t a n d bringen.

Zu-

F ü r die meisten einfachen P r o b l e m e existiert ein BISY-Be-

fehl, der das Ziel in einem Schritt erreicht.

F ü r diese Fälle e n t h ä l t PAS-

SIVIST eine große Zahl spezieller Regeln, die gleichzeitig die G r u n d l a g e f ü r die Lösung komplexerer, in Teilprobleme zerlegter P r o b l e m e bilden. Voraussetzung f ü r die Erzeugung von P l ä n e n f ü r die Lösung von Benutzerproblemen ist Wissen über den aktuellen Zustand des Editors (Modell über das Anwendungssystem).

Dieses Modell e n t h ä l t bei PASSIVIST verschiedene

A n g a b e n über die Position der Schreibmarke, z.B. ob sie sich a m A n f a n g oder a m E n d e des Textes, einer Zeile oder eines Wortes befindet.

Indirekt

sagt das Modell d a m i t auch einiges über den Inhalt des T e x t p u f f e r s aus: so ist z.B. die aktuelle Zeile leer, wenn die Schreibmarke

gleichzeitig

am

A n f a n g u n d a m Ende der Zeile steht. Viele P r o b l e m e können erst gelöst werden, n a c h d e m sie in Teilprobleme zerlegt w u r d e n .

U m zum Beispiel ein W o r t zu löschen, auf dem die Schreib-

m a r k e steht, müssen die folgenden Teilprobleme gelöst werden: 2 1. Bringe Schreibmarke an den A n f a n g des Wortes! 2. Lösche W o r t a b Position der Schreibmarke! W ä h r e n d der Lösungsphase werden auch die E r l ä u t e r u n g e n f ü r den zer generiert.

Benut-

Jedesmal wenn ein Schritt der Lösung gefunden wurde, wird

dieser d e m Benutzer zur A u s f ü h r u n g präsentiert.

2

In BISY existiert kein Befehl, der ein W o r t unabhängig von der Schreibmarkenposition löschen würde. Dafür gibt es Befehle, um den Teil des Wortes links bzw. rechts von der Schreibmarke zu löschen.

100

Systeme zur Dialogunterstützung

Lösungen der Benutzerprobleme werden zunächst auf der Ebene von BlSYBefehlen bestimmt. Die zugehörigen Funktionstastenfolgen, die der Benutzer zur Ausführung dieser Befehle eintippen muß, werden erst zur Laufzeit bestimmt. Da der Benutzer in BlSY Funktionstasten beliebigen Befehlen zuordnen und insbesondere auch die vordefinierten Bindungen verändern kann, ist so sichergestellt, daß immer die gerade gültigen verwendet werden. Sind mehrere Tastenfolgen definiert, so wählt PASSIVIST eine kürzeste aus. Erfahrungen mit Anfängern haben gezeigt, daß die Beherrschung der Tastatur und der Umgang mit Tastenfolgen für diese Benutzergruppe ein erhebliches Problem darstellt. Für diesen Zweck existiert ein einfaches Benutzermodell, das widerspiegelt, ob der Benutzer die Schreibweise von Tastenfolgen und die Eingabe von Kontrolltasten beherrscht. Das System geht davon aus, daß ein Benutzer, der das System zum erstenmal benutzt, diese Kenntnisse nicht besitzt und ein Anfänger ist. Nachdem die entsprechenden Erklärungen dreimal gegeben wurden, nimmt das System an, daß der Benutzer nun über die T a s t a t u r Bescheid weiß und gibt keine weiteren Erklärungen.

4. P r o b l e m e bei n a t ü r l i c h s p r a c h l i c h e n Hilfesystemen Ein grundlegendes Problem natürlichsprachlicher Hilfesysteme ist, daß eine gemeinsame Kommunikationsbasis zwischen Benutzer und Hilfesystem notwendig ist. Dies ist um so schwieriger, als ein Anwendungssystem, wie z.B. ein Texteditor, viele dem Benutzer unbekannte Konzepte enthält, die er folglich in seinen Anfragen auch nicht verwenden und erst nach und nach erlernen wird. Genauso muß das Hilfesystem sehr sorgfältig seinen Wortschatz auf den Benutzer abstimmen, um verständliche Antworten zu generieren. In zwischenmenschlichen Beratungsdialogen können solche Anpassungsvorgänge oft beobachtet werden. Das wichtigste Hilfsmittel des Hilfesystems ist hier das Benutzermodell. Für den A u f b a u eines Benutzermodells stehen im allgemeinen die folgenden Informationsquellen zur Verfügung: • Benutzeraktionen, • Hilfeanforderungen des Benutzers, • Fragen des Hilfesystems an den Benutzer. Aktionen des Benutzers können z.B. auf die Teilmenge der K o m m a n d o s hin untersucht werden, die der Benutzer verwendet.

Diese K o m m a n d o s stellen

101

PASSIVIST

das aktive Repertoire des Benutzers dar und ergeben einen ersten Uberblick über die Kenntnisse des Benutzers. Wenn später Hilfe erteilt wird, brauchen diese Kommandos nicht mehr erläutert zu werden. Im System AKTIVIST (siehe Kapitel VII) werden endliche Automaten verwendet, um zu erkennen, wie der Benutzer bestimmte Probleme aus dem Bereich Editieren löst. Problemlösungen des Hilfesystems können d a n n auf diese Lösungen abgestimmt werden, um den Benutzer nicht mit zuviel Neuem zu überlasten. Für ein natürlichsprachliches Hilfesystem bilden die Äußerungen des Benutzers eine wichtige Informationsquelle. Die Frage etwa ,,Wie kann ich dieses Wort weiter nach rechts schieben?" deutet an, daß der Benutzer vom Raummodell der Textdarstellung ausgeht (siehe unten). Spontane Mitteilungen des Benutzers und explizite Fragen des Systems (z.B. durch einen Fragebogen) können ebenfalls Informationen für ein Benutzermodell liefern. Anfänger haben oft unvollständige und irreführende Modellvorstellungen von Anwendungsgebiet oder Anwendungssystem. In zunehmendem Maße verwenden Benutzer Computersysteme für Aufgaben, für die sie nicht speziell ausgebildet sind. Ein aktuelles Beispiel ist der Schriftsatz. Mit modernen Computersystemen ist heute jeder in der Lage, druckreife Dokumente zu erstellen. Die technische Machbarkeit garantiert aber keineswegs, daß die vorhandene Funktionalität auch sachgerecht angewandt wird [Bentley 8 6 ] . Im die soll der und

Bereich des Texteditierens existieren verschiedene Modellvorstellungen, zu Verwechslungen und Mißverständnissen führen können. Als Beispiel hier die Wirkungsweise von Pfeiltasten betrachtet werden. Gegeben sei folgende Text aus drei Zeilen mit einer Leerzeile zwischen der zweiten dritten Zeile. e i ns zue i | v i er

Die Schreibposition befindet sich am Ende der zweiten Zeile. Wenn der Benutzer die Taste mit dem Pfeil nach unten betätigt, wohin wird sich die Schreibmarke bewegen? Es gibt mindestens drei vernünftige Zielpositionen, die von einer jeweils anderen Modellvorstellung nahegelegt werden.

102

Systeme zur Dialogunterstützung e i ns zue i Q g v i erßj

1. Die Schreibmarke bewegt sich zum linken Rand der Leerzeile. Dieses Verhalten folgt aus dem Sequenzkonzept der Textdarstellung. Hier wird der Text als eine Folge von durch spezielle Zeilentrenner getrennte Zeichen aufgefaßt. Eine Leerzeile entsteht folglich durch zwei direkt aufeinanderfolgende Zeilentrenner. Dieses Verfahren wird im Texteditor BISY angewendet. 2. Die Schreibmarke geht in die Leerzeile, behält aber ihre horizontale Position bei. Dieses Verhalten erwartet man bei einem Editor, der nach dem Raumkonzept arbeitet (Schreibmaschinenmodell). Die Annahme hier ist, daß die Pfeiltaste die Schreibmarke einfach um eine bestimmte geometrische Entfernung (eine Zeilenhöhe) nach unten bewegt. 3. Die Schreibmarke kommt hinter dem Wort ,,vier" zu stehen. Wenn man annimmt, daß die Leerzeile einfach „Zwischenraum" darstellt und die Schreibmarke sich nur vor oder hinter Buchstaben befinden kann, so ist auch diese Reaktion vernünftig. Um wirkungsvolle Hilfe zu geben, muß ein Hilfesystem über solche Modellvorstellungen Bescheid wissen. Wenn ein Benutzer ständig ein anderes Systemverhalten erfährt, als er erwartet, sollte ein Hilfesystem in der Lage sein, dies zu erkennen, und dem Benutzer ein besseres Modell nahebringen. Ein grundlegendes Problem natürlichsprachlicher Systeme ist die große Zahl gleichwertiger Formulierungen, die ein Benutzer zum Ausdrücken seines Problems verwenden kann. Die beiden Formulierungen „Wie setzt man die Schreibmarke „Wie komme

ich ans

an das Ende der

Zeile?"

Zeilenende?"

sind oberflächlich sehr verschieden. Beidesmal sucht der Benutzer aber nach derselben Information. Wenn ein Hilfesystem nicht in der Lage ist, die überwältigende Mehrheit dieser Formulierungen zu verstehen, ist es von geringem Nutzen und wird von Benutzern schnell abgelehnt. Für denjenigen, der ein natürlichsprachliches Hilfesystem erstellt, ist es nicht einfach, solche äquivalenten Formulierungen vorherzusehen.

103

PASSIVIST

5. S c h l u ß b e m e r k u n g e n PASSIVIST ist ein prototypisches System, das nicht den Anspruch alle Voraussetzungen für einen kommerziellen Einsatz zu erfüllen.

erhebt, Um die-

sen Schritt zu machen, müßte vor allem die Menge der Probleme, die PASSIVIST f ü r den Benutzer lösen kann, wesentlich erweitert werden. Ein Ziel dieser Arbeit war, die Hypothese zu überprüfen, daß eine natürlichsprachliche Schnittstelle für passive Hilfesysteme besonders geeignet ist. Für den beschränkten Anwendungsbereich personen diese Annahme bestätigt.

von PASSIVIST haben

Versuchs-

Informationen konnten mit Hilfe von

PASSIVIST mindestens so schnell oder schneller gefunden werden als mit herkömmlichen gedruckten oder on-line verfügbaren Beschreibungen. Unsere Beobachtungen mit einem simulierten System haben gezeigt, daß neben geradlinigen Fragen von der Art, wie sie PASSIVIST behandelt, gelegentlich sehr unklare Äußerungen vorkommen, die zu verstehen noch mit einem erheblichen Aufwand verbunden sein dürfte. Eine andere Frage ist, wie sich natürlichsprachliche Hilfesysteme, selbst wenn alle obengenannten Probleme gelöst wären, gegenüber anderen Arten von elektronischen Hilfesystemen (z.B. aktive, navigatorische oder stichwortorientierte Hilfesysteme) stellen würden. Würden Benutzer wirklich natürlichsprachliche Systeme vorziehen? Welchen Einfluß hat die Tatsache, daß Anfragen in geschriebener Sprache gestellt werden müssen anstatt in gesprochener Sprache? Unsere eigenen Erfahrungen mit Kommunikationssystemen haben gezeigt, daß Systeme, die geschriebene Sprache verwenden (electronic mail, Briefe), oft für andere Zwecke als Systeme mit gesprochener Sprache verwendet werden (Telephon). Hilfesysteme können nicht isoliert betrachtet werden. Bestimmte Eigenschaften eines Systems verursachen entsprechende Hilfebedürfnisse und typische Fehler [Norman 83]. Da ein Hilfesystem stark von der Konzeption des Anwendungssystems geprägt wird, sollte man erwägen, ob eine Verbesserung des Anwendungssystems nicht viele Hilfebedürfnisse eliminieren würde, anstatt Schwächen des Anwendungssystems mit einem raffinierten Hilfesystem gutzumachen. Direkte Manipulation mit einem Zeigegerät kann z.B. die Cursorpositionierung sehr vereinfachen. Das Streben, mit anderen Systemen kompatibel zu bleiben, steht der Modifizierung des Anwendungssystems jedoch oft entgegen.

104

Systeme zur Dialogunterstützung

Ein wirkungsvolles natürlichsprachliches Hilfesystem zu erstellen ist sicherlich heutzutage ein großer Aufwand. Man kann erwarten, daß ein solches System mindestens nocheinmal soviel Programmcode erfordert wie das Anwendungssystem selbst. Solche Systeme werden daher zuerst für relativ einfache Anwendungen mit sehr großer Verbreitung erscheinen. Das heutzutage meistverwendete passive Hilfesystem ist der Mensch.

Die

einfachste Möglichkeit, ein Problem zu lösen, ist, einen Expertenkollegen zu fragen, ob er nicht schon einmal auf ein ähnliches Problem gestoßen

ist.

Diese Möglichkeit kann aber nicht befriedigen, weil mit zunehmender Vielseitigkeit der Systeme die Wahrscheinlichkeit dafür sinkt und Experten oft einfach nicht verfügbar sind.

VII

AKTIVIST

Eine aktive Hilfekomponente für einen T e x t e d i t o r Thomas Schwab

Dieses Kapitel beschreibt die aktive Hilfekomponente AKTIVIST1, die dem Benutzer eines Texteditors Hinweise auf ihm unbekannte Kommandos gibt. Anhand eines Beispieldialogs wird ein typisches Szenario für A K T I V I S T gezeigt; anschließend wird die Arbeitsweise näher vorgestellt. Davon ausgehend wird die Problematik aktive Hilfe allgemein behandelt.

1. M o t i v a t i o n Mit der zunehmenden Funktionalität von Computersystemen steigt zwangsläufig auch deren Komplexität. Bedingt durch die Menge der Aufgaben, die ein Benutzer mit dem Anwendungssystem lösen kann, stellt ein solches System eine große Menge an Konzepten und Befehlen zur Verfügung 2 . Ein einzelner Benutzer verliert darüber oft den Uberblick und nutzt das System nicht optimal aus. So braucht auch ein geübter, j a sogar ein sehr gut mit dem System vertrauter Benutzer Hilfe bei bisher noch nicht oder nur selten durchgeführten Aktionen. In Abbildung 1 sind die Vorstellungen des Benutzers über ein System durch Ellipsen dargestellt, wobei ein Rechteck die Menge der tatsächlich im System realisierten Konzepte symbolisiert. Die Menge der vom Benutzer vermuteten Konzepte (große Ellipse) und die tatsächlich

im

System

realisierten

(Rechteck)

stehen

nicht in einer echten Ober- oder Untermengenrelation.

im allgemeinen

Fall

Der Benutzer ver-

mutet Konzepte und damit assoziierte Befehle im System, die in Wirklich-

1

A K T I V I S T e n t s t a n d als W e i t e r e n t w i c k l u n g des in

2

Konzept s t e h t f ü r einen Begriff aus d e m jeweiligen A n w e n d u n g s g e b i e t . Im A n w e n d u n g s s y s t e m r e a l i s i e r t e K o n z e p t e spiegeln sich in F o r m von Befehlen wieder (Beispiel: das K o n z e p t d e r Z e i l e n l ö s c h u n g k a n n in e i n e m E d i t o r d u r c h den Befehl r u b o u t - l i n e realisiert sein).

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter Sc Co. • Berlin . New York

[ S c h w a b 84] vorgestellten

Hilfesystems.

106

Systeme zur Dialogunterstützung vermutete Konzepte

Abbildung 1.

Nutzung komplexer Systeme.

keit nicht darin enthalten sind.

Andererseits existieren Befehle im System,

deren Existenz der Benutzer nicht vermutet. Für die kritischen Bereiche (in Abbildung 1 durch unterschiedliche Schraffur dargestellt) soll im folgenden kurz aufgezeigt werden, wie der Benutzer sinnvoll unterstützt werden kann. • Eine verbesserte Benutzerschnittstelle kann viel dazu beitragen, daß der Benutzer auch Befehle, die er nur gelegentlich benutzt (| |), zu einem späteren Zeitpunkt wieder richtig verwendet (z.B. Menüs, Propertysheets etc.). Hilfesysteme können den Benutzer insofern unterstützen, als er bei Unklarheiten dort nachfragen kann. • Realisierte Konzepte, die der Benutzer im System vermutet {Y///// >[), können gut durch ein Hilfesystem behandelt werden: da der Benutzer die Konzepte im System vermutet, ihm aber die zugehörigen Befehle und deren Verwendung nicht bekai.nt sind, wird er von sich aus nachfragen. • Ein Hilfesystem kann erkennen, wenn der Benutzer nach Operationen fragt, die das Anwendungssystem nicht bieten kann (jff||l|]), und entsprechend darauf antworten. Dazu benötigt das Hilfesystem Wissen über die Funktionalität des Anwendungssystems. • Bei den Konzepten, die im System realisiert der Benutzer aber nichts ahnt (|||||||||¡ij||), muß system zwangsläufig versagen. Der Benutzer te keine Fragen an das Hilfesystem richten.

sind, von deren Existenz ein konventionelles Hilfewird über solche KonzepHier ergibt sich die Not-

107

AKTIVIST

wendigkeit f ü r ein aktives Hilfesystem, das d e m Benutzer von sich aus Befehle aus diesem Bereich vorschlägt. Als Vorbild f ü r ein derartiges aktives Hilfesystem k a n n m a n sich folgende Situation vorstellen: Ein menschlicher Systemexperte zu. Der ihm beim Arbeiten über den Problembereich und Ausnutzung der Funktionalität

sitzt neben dem Benutzer und schaut Experte gibt aufgrund seines Wissens den Benutzer Ratschläge zur besseren des Systems.

Das hier beschriebene System AKTIVIST ist eine prototypische, aktive Hilfekomponente Bauer

für

86].

den

bildschirmorientierten

Sie soll dem E d i t o r b e n u t z e r

Texteditor Ratschläge

BlSY

[Bauer

84;

zu Positionier-

und

Löschaktionen geben.

2. E i n e B e i s p i e l s i t z u n g m i t AKTIVIST A b b i l d u n g 2 zeigt den Bildschirmaufbau zu Beginn der Editorsitzung. t e r h a l b des Editorfensters, in dem der zu editierende Text steht, sich das Dialogfenster f ü r den Editor.

Grundsätzlich können

Kommandos

in BlSY d u r c h Betätigen einer speziellen T a s t e und anschließender des K o m m a n d o n a m e n s

im Dialogfenster ausgelöst werden.

direkt ausgelöst werden.

Eingabe

Hierbei erfolgt

eine a u t o m a t i s c h e Vervollständigung des K o m m a n d o n a m e n s . m a n d o s sind d a r ü b e r hinaus an F u n k t i o n s t a s t e n

Un-

befindet

Einige

Kom-

gebunden und k ö n n e n

Diese T a s t e n b i n d u n g e n können auch v o m

so

Editor-

benutzer w ä h r e n d der Sitzung selbst u m d e f i n i e r t werden. Rechts

oben

AKTIVIST.

auf

dem

Bildschirm

befindet

sich

das

Kontrollfeld

Der Benutzer k a n n d a m i t die aktive Hilfe ein- und

(Auswahl von Glve

Hints

bzw. Be Q u i e t ) .

für

ausschalten

Ebenso k a n n er d u r c h

An-

klicken des Hilfekoffers mit der M a u s die Hilfestrategie von AKTIVIST beeinflussen (Abschnitt 3.5).

Durch Anklicken von Look At, U s e r Model

kann

das von AKTIVIST erstellte Benutzermodell inspiziert werden (Abschnitt 3.3). Für

die

Beispielsitzung

hat

der

Benutzer

die

aktive

Hilfe

eingeschaltet.

Uber d e m Editorfenster befindet sich nun das Ausgabefenster f ü r AKTIVIST (Abbildung 2).

Sämtliche Hinweise, die AKTIVIST w ä h r e n d

zung gibt, werden in diesem Ausgabefenster ausgegeben.

der

Editorsit-

Der Benutzer

hat

d o r t die Möglichkeit vor- u n d zuriickzublättern, so daß er auch weiter

zu-

rückliegende Hinweise nochmals inspizieren k a n n .

108

Systeme zur Dialogunterstützung

T r a n s i t i o n s n e t z , (Ins t i e s c h r e i b t , a u f w e l c n e v e r s c h i e d e n e n A r t e n } m i t h i l f e der e x i s t i e r e n d e n E d i t i e r k o m m a n d o s d u r c h g e f ü h r t w e r d e n [ M i t j e d e m J E d i t i e r k o m m a n d o , d a s der B e n u t z e r a u s l ö s t , f ü h r e n d i e I r a n s i t i o n s n e t z e s ä m t l i c h e r P l a n e , d i e g e r a d e ü b e r w a c h t werden, e i n e n ZustandsUbergang durch. Zu B e g i n n der E d i t o r s i t z u n g werden a l l e P l ä n e ü b e r w a c h t ; e r s t nach und n a c h werden e i n i g e a u s der Überwachung herausgenommen ( s i e h e A b s c h n i t t 0 r e f < S t e u e r u n g - d e r - B e o b a c h t u n g > ) . Die Eingabe für d i e T r a n s i t i o n s n e t z e @Beg i n < E n u m e r a t e > a u s g e f ü h r t e m E d i t i e r k o m m a n d o und

ist

rF®

eine Seguenz von Paaren aus

Z u s t a n d des E d i t o r s n a c h A u s f ü h r u n g d e s Komma l o s . Der E d i t o r z u s t a n d i s t hier durch die C u r s o r p o s i t i o n b e z ü g l i c h s mantisciier E i n h e i t e n d e f i n i e r t ( z . B . "am A n f a n g e i n e s W o r t e s " , "am nde e i n e r Z e i l e " e t c . ) .

m

font-name:

Abbildung 2.

::

: : :

german

Einschalten von AKTIVIST.

Nachfolgend soll die Wirkungsweise von AKTIVIST anhand zweier typischer Situationen im Umgang mit dem Editor erläutert werden.

2.1 H i n w e i s auf ein

Kommando

Im Beispiel kennt der Benutzer keine komplexen Löschkommandos. Er hat während des Editiervorgangs für Löschungen nur die primitiven K o m m a n d o s r u b o u t - c h - l e f t und r u b o u t - c h - r i g h t benutzt, die das Zeichen links bzw. rechts von der Schreibmarke löschen. Nachdem er auf diese Weise mehrmals längere Wortanfänge zeichenweise gelöscht hat, ertönt ein akustisches Signal und im Ausgabefenster von AKTIVIST erscheint der Hinweis auf das Kommando r u b o u t - w o r d - l e f t (Abbildung 3).

109

AKTIVIST

You may use rubout-word-left (Key binding: to delete the left part of the current word

PF1 DEL)

1 Trans 11 lonsnet z, [las beschreibt, auf welche verschiedenen Arten tlieser ^ Mithilfe der existierenden Editierkommandos durchgeführt werden kann. Mit jedem Editierkommando, das der Benutzer auslöst, fuhren alle Transitionsnetze der Plane, die gerade überwacht werden sollen, einen Zustandsüberyany durch Zu Beyinn der Editorsitzung werden alle Pläne überwacht und erst nach und nach einige aus der überwachuny genommen [ (siehe Abschnitt G>ref). nie Eingabe für die Transit ionsnetze ist eine Sequenz von Paaren atrs @Beg in ausgeführtem Fd itorkommando und Zustand des Editors nach Ausführung des Kommandos Der ¿zustand ist hier durch die Cursorposition bezüglich semantischer Einheiten definiert (z.ß "an Anfang eines Wortes", "am Ende einer Zeile" etc ). fr

—

T m ~ ~

Abbildung 3.

Hinweis auf

t. -r

rubout-word-left.

2 . 2 Hinweis a u f T a s t e n b i n d u n g Im Beispiel weiß der Benutzer nicht, daß das K o m m a n d o beginnlng-of-llne Funktionstaste

zum Positionieren

gebunden

ist.

Er

löst

durch Eingabe

des Kommandonamens

dies mehrmals

getan

hat,

an den

set-cursor-to-

Zeilenanfang

deshalb

dieses

im Dialogfenster

erhält er im Ausgabefenster

auch

Kommando aus.

an

eine

immer

Nachdem

von AKTIVIST

er den

Hinweis auf die Tastenbindung des Kommandos (Abbildung 4).

3. Die Arbeitsweise von AKTIVIST AKTIVIST ist Teil des integrierten Hilfesystems zum Editor BlSY 3 .

Der Be-

nutzer des Editors kann in folgenden Situationen Hinweise erhalten: 1. Der Benutzer kennt ein bestimmtes komplexes Editierkommando nicht und benutzt suboptimale Kommandos, um seine Editieraufgaben durchzuführen. Der Benutzer löscht z.B. eine Zeile zeichenweise, ans t a t t das entsprechende Kommando delete-line zu verwenden.

3

Eine B e s c h r e i b u n g des gesamten Hilfesystems

findet

sich in

[Bauer, Schwab

87].

Systeme zur Dialogunterstützung

110

r

Hints For Using The Editor You may use ruboot-word-left (Key binding: to delete the left part of the current word

PF1 DFL)

[

set-cursor-to-beg inning-of- 1 ine is also bound to '"'A 1

1•

¡Editor Window a b e K

P

l

a

n

b

e

w

e

r

t

u

n

g

>

©X? i

T

Nach erfolgter Erkennung eines Plans wird die Art und Weise bewertet, wie der Benutzer ihn ausgeführt hat. Dazu existiert zu jedem Editierplan ein Kommandovorschlag, der die optimale Kommandofolge für den Plan definiert Die Metrik für die Bewertung der Lösung des Benutzers der benötigten lastendrücke.

ist die Anzahl

|

PN(Aktivist) vergleicht die für die Planausführung benutzten Kommandos mit d e n abgespeicherten Vorschlägen zu dem jeweiligen Plan. Die bestmögliche Lösung wird also nicht für jeden konkreten fall berechnet, statische Kommandovorschlag für d e n Plan wird als Optimum angesehen. Bei der Bewertung können zwei Fälle unterschieden werden: Editor Dialog Window give COMMAND: set-cursor-to-beginning-of- 1ine

Abbildung 4.

Hinweis für

set-cursor-to-beginning-of-line.

2. Der Benutzer kennt zwar das Kommando, weiß aber nicht, daß es an eine Funktionstaste gebunden ist. Er löst deshalb das Kommando durch Eintippen des Kommandonamens aus. Derzeit können 20 verschiedene Editieraufgaben (sogenannte Pläne) aus den Bereichen Positionieren der Schreibmarke und Löschung von Textteilen von AKTIVIST behandelt werden. Wie das Beispiel gezeigt hat, greift AKTIVIST nicht direkt in die Arbeit des Benutzers mit dem Editor ein. Es werden nur Hinweise ausgegeben. Um sich näher über die vorgeschlagenen Kommandos zu informieren, genügt ein Anklicken des Kommandonamens mit der Maus. Das angeklickte Kommando wird dann mit Hilfe einer anderen Hilfekomponente des Hilfesystems weiter erklärt. Im folgenden sollen die einzelnen Phasen der Arbeitsweise von AKTIVIST näher erläutert werden.

111

AKTIVIST

3.1 E r k e n n e n v o n

Editierplänen

Mit Hilfe von Transitionsnetzen wird erkannt, welchen Plan der Benutzer gerade ausfuhrt. Zu jedem Editierplan existiert ein Transitionsnetz, das beschreibt, auf welche verschiedenen Arten dieser Plan mit den vorhandenen Editierkommandos durchgeführt werden kann. Abbildung 5 zeigt das Transitionsnetz zum Plan Löschen des Wortanfangs. Die Transitionsnetze werden durch Erkennungsautomaten abgearbeitet. Mit jedem Editierkommando, das der Benutzer auslöst, führen die Erkennungsautomaten sämtlicher Pläne, die gerade überwacht werden, einen Zustandsübergang durch. Zu Beginn der Editorsitzung werden alle Pläne überwacht; erst nach und nach werden einige aus der Überwachung herausgenommen (siehe Abschnitt 3.4). Die Eingabe für die Erkennungsautomaten ist eine Sequenz von Paaren aus ausgeführtem Editierkommando und Zustand des Editors nach Ausführung des Kommandos. Der Editorzustand ist hier durch die Position der Schreibmarke bezüglich semantischer Einheiten definiert (z.B. „ a m Anfang eines Wortes", „ a m Ende einer Zeile" etc.). Jedes Paar (Kommando - Position) stellt somit ein Eingabezeichen für die Erkennungsautomaten dar. Abhängig vom zugehörigen Transitionsnetz gehen sie in andere Zustände über und können dabei Aktionen ausführen. Drei Aktionen sind bei Zustandsübergängen möglich: • init: dies geschieht, wenn die Anfangsbedingungen für die Planausführung erfüllt sind. Das nächste vom Benutzer ausgelöste Editierkommando ist also potentiell Bestandteil des Planes. • match-all: diese Aktion wird ausgelöst, wenn die Planerkennung erfolgreich war. Alle Kommandos, die seit der irai-Aktion ausgelöst wurden, sind Bestandteil der Planausführung. • match-without-last: hat dieselbe Auswirkung wie match-all, nur wird das zuletzt ausgeführte Kommando nicht mit zur P l a n a u s f ü h r u n g gezählt. Diese Aktion wird bei Plänen nötig, zu deren Erkennung ein Look-Ahead-Mechanismus nötig ist; als Look-Ahead-Distanz gilt ein Eingabeschritt. Jedes

Transitionnetz

hat

mindestens

die

zwei

ausgezeichneten

Zustände

START und WAIT mit folgender Bedeutung: WAIT: die Anfangsbedingungen für den Plan sind nicht erfüllt. Das nächste ausgelöste K o m m a n d o kann sicher nicht zum Plan gehören.

Systeme zur D i a l o g u n t e r s t ü t z u n g (rubout-ch-left / onw)

Transition:

onw bow

( Command

/ Cursorposition )

= "on word" = "beginning of word"

Abbildung 5.

Transitionsnetz f ü r Löschen

des

Wortanfangs.

START: die A n f a n g s b e d i n g u n g e n f ü r den P l a n sind erfüllt. ste ausgelöste K o m m a n d o gehört möglicherweise zum P l a n . Löschen

des Wortanfangs

Schreibmarke

innerhalb

Das näch-

k a n n z.B. nur a u s g e f ü h r t werden, wenn sich die eines

Wortes

befindet.

Der

Erkennungsautomat

zum Transitionsnetz aus A b b i l d u n g 5 befindet sich d a n n im Z u s t a n d START. Steht die S c h r e i b m a r k e nicht innerhalb eines Wortes, befindet sich der Aut o m a t im Zustand WATT. Die A u s f ü h r u n g eines nicht zum P l a n

gehörenden

K o m m a n d o s f ü h r t ihn wieder in einen der beiden Zustände zurück.

In Ab-

bildung 5 sind das die Übergänge mit * an der K o m m a n d o p o s i t i o n . Zustände STATE 1 u n d STATE 2 werden v o m E r k e n n u n g s a u t o m a t e n laufen, wenn der Benutzer den P l a n d u r c h Markieren

eines

u n d anschließendes Löschen

ausführt.

des markierten

Textbereiches

Die durch-

Textbereiches

AKTIVIST

113

Als Ergebnis einer erfolgreichen

Planerkennung

liegen die b e n u t z t e

mandofolge u n d die T a s t e n , mit denen die einzelnen K o m m a n d o s wurden,

vor.

Dieses Ergebnis wird

anschließend

in der

Kom-

ausgelöst

Bewertungsphase

weiterverwendet.

3.2 B e w e r t e n der v e r w e n d e t e n AKTIVIST kennt

zu j e d e m

Editierplan

einen Vorschlag,

K o m m a n d o f o l g e f ü r den Plan definiert. bestmögliche Lösung wird also nicht Der

Vorschlag

für

Löschen

des

Kommandos der

die

optimale

Dieser Vorschlag ist statisch; die

f ü r jeden

Wortanfangs

konkreten ist

z.B.

Fall das

berechnet. Kommando

rubout-word-left. Die Metrik f ü r die Bewertung der Lösung des Benutzers ist die Anzahl der benötigten Tastenanschläge.

Dazu vergleicht AKTIVIST die f ü r die P l a n a u s -

f ü h r u n g benutzten K o m m a n d o s mit d e m abgespeicherten Vorschlag zu d e m jeweiligen P l a n .

Bei der Bewertung können d a n n zwei Fälle unterschieden

werden: 1. Der Benutzer h a t den optimalen K o m m a n d o v o r s c h l a g

benutzt.

2. Der Benutzer h a t andere K o m m a n d o s zur P l a n a u s f ü h r u n g b e n u t z t .

V e r w e n d u n g des V o r s c h l a g s AKTIVIST b e t r a c h t e t nun mit welchen Tasten der Benutzer das K o m m a n d o , bzw. die K o m m a n d o f o l g e , ausgelöst hat.

Die verwendete Tastenfolge wird

m i t der minimal möglichen Tastenfolge gemäß der gerade aktuellen

Tasten-

bindungen verglichen: • H a t der Benutzer nicht mehr Tastenanschläge benötigt, gilt der als optimal a u s g e f ü h r t .

Plan

• H a t der Benutzer mehr T a s t e n benötigt, so k e n n t er offensichtlich nicht die kürzeste Tastenfolge, u m das K o m m a n d o (bzw. die Kommandofolge) auszulösen.

Verwendung anderer

Kommandos

G e m ä ß der Metrik soll dies nur d a n n als „ u m s t ä n d l i c h " bewertet wenn er d a d u r c h zu viele Tastenanschläge benötigt h a t .

Auch hier werden

die benötigten Tastenanschläge mit der Minimallösung f ü r den vorschlag verglichen:

werden,

Kommando-

114

Systeme zur Dialogunterstützung • Hat der Benutzer mehr Tasten benötigt, so wird seine Lösung als „umständlich" bewertet. Er hätte durch die Benutzung des K o m m a n dovorschlags Tastenanschläge einsparen können. • Hat der Benutzer weniger (siehe Beispiel) oder gleich viel Tastenanschläge benötigt, so wird die Lösung nicht als „umständlich" bewertet. Die Benutzung des Kommandovorschlags hätte keine Ersparnis gebracht. Beispiel: Die Schreibmarke steht zwischen dem ersten und zweiten Buchstaben eines Wortes. Wenn der Benutzer nun den Wortanfang (in diesem Fall nur ein einziger Buchstabe) mit r u b o u t - c h - l e f t (Taste: DEL,) löscht, wird der Plan Löschen des Wortanfangs vom entsprechenden Erkennungsautomaten erkannt. Der Vorschlag für diesen Plan ist r u b o u t - w o r d - l e f t (Tastenfolge: PF1 DEL/ Der Benutzer hat also weniger Tastenanschläge benötigt, als mit dem Kommandovorschlag. Nach der Metrik kann dies nicht als negativ bewertet werden. Der Kommandovorschlag erweist sich nur bei längeren Löschungen als besser. Es kann aus diesem Beispiel allerdings nicht geschlossen werden, daß der Benutzer den Kommandovorschlag für den Plan beherrscht. Die Bewertung wird deshalb den Plan auch nicht als optimal ausgeführt betrachten.

3.3 D a s M o d e l l über den B e n u t z e r AKTIVIST besitzt ein Benutzermodell, in dem Information Uber die Arbeitsweise, den Wissensstand und die bisher an den Benutzer gegebenen Hilfeleistungen enthalten ist. Die Informationen zur Modellierung des Benutzers werden im wesentlichen aus der Erkennungs- und Bewertungsphase gewonnen. Zu jedem Editierplan werden für jeden Benutzer folgende Daten festgehalten: • wie oft der Editierplan während der Editorsitzung wurde,

schon

ausgeführt

• wie oft die P l a n a u s f ü h r u n g als optimal bewertet wurde, d.h., wie oft der Editierplan mit dem Kommandovorschlag und der dafür minimalen Tastenfolge ausgelöst wurde, • wie oft der Editierplan seit dem letzten Hinweis dazu auf umständliche Weise ausgeführt wurde und die Anzahl der dadurch unnötigen Tastenanschläge,

115

AKTIVIST

• wie o f t der Editierplan seit d e m letzten Hinweis dazu zwar m i t d e m Kommandovorschlag, aber nicht m i t der kürzesten T a s t e n b i n d u n g ausg e f ü h r t wurde. Hierzu wird ebenfalls die Anzahl der unnötigen T a stenanschläge abgespeichert. • Die Anzahl der Hilfemeldungen, die der Benutzer schon von AKTIVIST erhalten h a t .

zu diesem

Plan

Abbildung 6 zeigt beispielhaft d e n Teil des erstellten Benutzermodells z u m P l a n Löschen

des Wortanfangs.

Der Plan wurde insgesamt dreimal

f ü h r t , allerdings nie mit d e m optimalen K o m m a n d o . einen Hinweis dazu gegeben.

ausge-

AKTIVIST h a t schon

Seit diesem Hinweis h a t der Benutzer den

P l a n einmal m i t suboptimalen K o m m a n d o s ausgelöst u n d d a d u r c h sechs zusätzliche

Tastenanschläge

benötigt.

Der K o m m a n d o v o r s c h l a g

f ü r diesen

P l a n ist r u b o u t - w o r d - l e f t u n d kann als kürzeste Tastenfolge m i t P F l DEL ausgelöst werden.

DELETE l e f t p a r t o f word

USER

MODEL

iplan executed: ::900d d o n e : ¡wrong corinand u s e d : :;with u n n e c e s s a r y k e y s : connand with wrong keys th u n n e c e s s a r y keys: messages sent to user:

used:

3 A 1 6 A A 1

INTERNAL

I N F O R M A T I O N

proposed commands: tima I keys:

rubout-gord P F l DEL

left

A c t i v e Help

Be Qu let Give Hints +

G

tde

Abbildung 6.

User

Hödel

Benutzermodell zu Löschen

des

Wortanfangs.

Der Inhalt des Benutzermodells steuert d a s Verhalten von AKTIVIST.

Auf-

grund dieser Informationen wird entschieden, welche Pläne in Z u k u n f t wei-

Systeme zur D i a l o g u n t e r s t ü t z u n g

116

ter ü b e r w a c h t werden sollen (Abschnitt 3.4) u n d zu welchen P l ä n e n der Benutzer Hinweise erhalten soll (Abschnitt 3.5). Das Modell über den Benutzer ist lokal zu den einzelnen P l ä n e n tiert.

repräsen-

Es existiert keine globale I n f o r m a t i o n s s t r u k t u r , die die Beziehungen

der P l ä n e u n t e r e i n a n d e r berücksichtigt.

Das Benutzermodell wird bei j e d e r

Editorsitzung neu a u f g e b a u t .

3.4 S t e u e r u n g der w e i t e r e n A m A n f a n g einer Editorsitzung Ihre zugehörigen

Beobachtung

werden

Erkennungsautomaten

alle P l ä n e

gleichzeitig

überwacht.

sind eingeschaltet; sie a r b e i t e n

Erkennungsprozeß die Transitionsnetze parallel ab.

im

Dies ist bei einer gerin-

gen Zahl von zu überwachenden Editierplänen noch möglich. Im Verlauf der Editorsitzung schließt AKTIVIST a u f g r u n d des erstellten Modells über den Benutzer gewisse P l ä n e von der weiteren B e o b a c h t u n g Die zugehörigen E r k e n n u n g s a u t o m a t e n werden abgeschaltet.

aus.

Das Benutzer-

modell wird zu diesen Plänen nicht weiter aktualisiert; AKTIVIST gibt deshalb auch keine Hilfemeldungen m e h r zu den Plänen.

Die Kriterien

für

den Ausschluß von Plänen k a n n der Benutzer d u r c h V e r ä n d e r n der Hilfestrategie selbst einstellen (siehe Abbildung 7). Ein P l a n , der einmal aus der B e o b a c h t u n g genommen wurde, wird w ä h r e n d der weiteren Editorsitzung

bei

einer

neuen Editorsitzung zu Beginn wieder alle P l ä n e beobachtet werden,

nicht wieder eingeschaltet.

Da aber

kann

d a d u r c h d e m U m s t a n d Rechnung getragen werden, daß der Benutzer

viel-

leicht gewisse Systemeigenschaften

kann

wieder

vergessen

hat.

AKTIVIST

sich so bei jeder Sitzung auf den aktuellen Wissenstand des Benutzers neu einpendeln.

3.5 H i l f e s t r a t e g i e v o n AKTIVIST Die Hilfestrategie von AKTIVIST k a n n

individuell eingestellt werden.

Alle

P a r a m e t e r , die bestimmen, w a n n die Hilfekomponente Hinweise geben soll, können über ein P r o p e r t y s h e e t (vgl. A b b i l d u n g 7) v e r ä n d e r t werden. Zwei P a r a m e t e r

bestimmen die globale Strategie, nach der eine Hilfeinfor-

mation ausgegeben werden soll: • Die Zeit zwischen zwei Hinweisen soll mindestens q u i e t t i m e b e t w e e n two h l n t s Sekunden betragen, u m eine I n f o r m a t i o n s ü b e r f l u t u n g zu verhindern. Besonders f ü r einen A n f ä n g e r k a n n es sonst b e d e u t e n ,

AKTIVIST

117

Be

On i et

Give Hints

c Abbildung 7.

Look fit I Mode I

q u i e t t i n e b e t w e e n two h i n t s i g n o r e good u s a g e = 2 n.mlnat h i n t s per plan = 2

= 38

Propertysheet zum V e r ä n d e r n der Hilfestrategie.

d a ß er pausenlos von der aktiven Hilfekomponente Ratschläge bek o m m t . Ein Hinweis, der sich auf eine b e s t i m m t e Aktion bezieht, soll nur unmittelbar nach deren A u s f ü h r u n g durch den Benutzer erfolgen. N u r so ist der zeitliche u n d sachliche Z u s a m m e n h a n g zwischen Hinweis u n d Arbeiten im Editor gegeben. Falls nach diesem K r i t e r i u m ein Hinweis gegeben werden sollte, der letzte aber noch keine q u l e t t i m e b e t w e e n two h l n t s Sekunden zurückliegt, erfolgt keine Ausgabe. • Hinweise zur gleichen E d i t i e r a u f g a b e oder zum gleichen K o m m a n d o werden nur m a x i m a l h l n t s p e r p l a n mal gegeben. Dies gewährleistet, d a ß der Benutzer die Hinweise nicht akzeptieren m u ß u n d die Hilfekomponente nicht aufdringlich wird, wenn er auf seine eigene A r t u n d Weise weiterarbeitet. Dabei ist es sinnvoll, den W e r t von m a x i mal h l n t s p e r p l a n größer als 1 zu wählen. Es ist nicht anzunehmen, daß der Benutzer nach einmaliger Meldung den Hilfevorschlag schon gelernt h a t . U m die Hilfeaktivität auf die f ü r den Benutzer wesentlichen Teile zu richten und sporadische Umständlichkeiten nicht überzubewerten, wird die Ausgabe von Hinweisen d u r c h vier P a r a m e t e r gesteuert.

Ein Hinweis zu einer

speziellen E d i t i e r a u f g a b e erfolgt, • wenn sie mehr als t o l e r a t e u s a g e of bad commands mal mit suboptimalen K o m m a n d o s d u r c h g e f ü h r t wurde u n d der Benutzer d a d u r c h mehr als k e y s t r o k e l i m l t f o r bad commands u s a g e unnötige T a stenanschläge gegenüber d e m K o m m a n d o v o r s c h l a g des Hilfesystems benötigt h a t oder

Systeme zur D i a l o g u n t e r s t ü t z u n g

118

• wenn der K o m m a n d o v o r s c h l a g des Hilfesystems mehr als tolerate usage of bad keys mal auf nichtoptimale Weise ausgelöst wurde u n d d a d u r c h keystroke limit for bad keys usage mehr T a s t e n a n s c h l ä ge benötigt wurden. Die aktive Hilfekomponente soll nur Hinweise zu Systemeigenschaften geben, die f ü r den Benutzer neu sind.

Aus diesem G r u n d existiert ein

weiterer

Parameter: • Wird ein Editierplan mehr als i g n o r e good usage mal auf o p t i m a l e A r t u n d Weise v o m Benutzer ausgeführt, gibt AKTIVIST die Beobacht u n g d a f ü r auf. In Z u k u n f t erfolgen dazu keine Hinweise m e h r . Hier ist zu empfehlen, den Grenzwert i g n o r e good usage größer als 1 zu wählen; d a m i t wird ausgeschlossen, daß schon ein einmaliges versehentliches Auslösen des Kommandovorschlags als Beherrschung des P l a n s interpretiert wird.

4. A k t i v e Hilfe Allgemein lassen sich Hilfesysteme a u f g r u n d der Initiative zur Hilfeleistung in passive Aktive

und aktive

Hilfesysteme unterteilen (siehe Kapitel V u n d VI).

Hilfesysteme w a r t e n

sondern

werden

sich aus aktiv.

aufgrund

nicht eine Hilfeanforderung des Benutzers einer Analyse der

bisherigen

Dialoghistorie

ab, von

Es werden Hinweise gegeben, die d a n n allerdings w i e d e r u m

ein Einstieg zu einer w e i t e r f ü h r e n d e n A n f r a g e des Benutzers sein

können.

Dies wird vor allem d a n n wichtig, wenn der Benutzer zusätzliche I n f o r m a tionen zum gegebenen Hinweis will. passives Hilfesystem voraus.

Ein aktives Hilfesystem setzt ein gutes

Die internen Wissensstrukturen über den Pro-

b l e m r a u m , die S y s t e m f u n k t i o n a l i t ä t und den konkreten Benutzer müssen in beiden A r t e n

von Hilfesystemen vorhanden sein.

Ebenso benötigen

entsprechende Mechanismen, u m Informationen geeignet auf dem

beide

Bildschirm

darzubieten, m o m e n t a n irrelevante Informationsteile auszufiltern und

weite-

res Nachfragen des Benutzers zu ermöglichen. Man spricht deshalb besser von passiven und aktiven H i l f e k o m p o n e n t e n , die Teile eines integrierten Hilfesystems sind.

Beide K o m p o n e n t e n können

auf

dieselben Wissensstrukturen zugreifen und es können Synergie-Effekte ausgen ü t z t werden, indem eine K o m p o n e n t e Ergebnisse der anderen det.

mitverwen-

So kann beispielsweise ein umfassenderes Benutzermodell erstellt

wer-

den, wenn nicht nur die verwendeten K o m m a n d o s , sondern auch die A n f r a gen des Benutzers an die passive Hilfekomponente Berücksichtigung finden.

119

AKTIVIST

Ein solches Hilfesystem schafft eine Situation, die dem eingangs erwähnten Modell mit einem menschlichen Experten als Beobachter noch näher k o m m t : Ein menschlicher Beobachter kann nicht nur von sich aus dem Benutzer Hilfe anbieten, sondern dient auch als Ansprechpartner für Fragen. Ein Dialog zwischen Benutzer und Hilfesystem wird also ermöglicht, der zum Teil vom Benutzer (passive Komponente) und zum Teil vom Hilfesystem (aktive Komponente) initiiert wird.

4.1 S p e k t r u m a k t i v e r Hilfe Definiert man jede Art von Hinweisen, die der Benutzer eines Systems ohne explizite Anfrage erhält, als aktive Hilfe, dann lassen sich folgende Techniken im weitesten Sinne als aktive Hilfeleistungen betrachten. • Statuszeile: Sie zeigt den Zustand der Maschine oder eines bestimmten Systems (z.B. in EMACS [Gosling 82]: die Datei, die editiert wird - ob sie abgespeichert wurde - die relative Position innerhalb des Textes - den eingestellten Modus des Editors). • kontext-sensitive Menüs: Es werden nur die im jeweiligen des Anwendungssystems ausführbaren Kommandos angezeigt.

Zustand

• automatische Tippfehlerkorrektur: Schreibfehler bei der Eingabe von Kommandos oder Parametern können zum Teil vom System berichtigt werden. • Fehlermeldungen: Der Benutzer erhält einen Hinweis, wenn er eine unzulässige Aktion ausgelöst hat. Der Fehler wird näher erklärt. • Verzögerte automatische Menüs: Ein Menü mit momentan möglichen Kommandos erscheint, wenn der Benutzer eine gewisse Zeit keine Eingabe gemacht hat. • Hinweis auf folgenschwere Aktionen: Der Benutzer wird vor folgenschweren Schritten gewarnt oder bekommt nach Ausführung eines solchen Schritts die Möglichkeit, diese Aktion wieder rückgängig zu machen. • Uberbeantwortung von Fragen: Bei einer Anfrage an die passive Hilfekomponente werden dem Benutzer zusätzliche Dinge erklärt, die zum Verständnis wichtig sind. • Hinweis auf ihm mit dem z.B. von

auf unbekannte nützliche Kommandos: Der Benutzer wird unbekannte Kommandos hingewiesen, die ihm seine Arbeit System erleichtern können. Diese Art der aktiven Hilfe wird AKTIVIST und WIZARD [Finin 83] angeboten.

Systeme zur Dialogunterstützung

120

• Verbesserungsvorschläge zum Arbeitsstil: gehensweisen aus dem Anwendungsgebiet fensichtlich umständlich arbeitet (mehr Hilfe). Das aufgezeigte Spektrum

Dem Benutzer werden Vornähergebracht, wenn er ofanwendungsbezogene aktive

reicht von relativ leicht

zu

implementierenden

Techniken, die in vielen Computersystemen auch ohne eigene aktive Hilfekomponente realisiert sind, bis zu Techniken, die nur mit einer aufwendigen aktiven Hilfekomponente möglich sind.

Solche Komponenten sind zur Zeit

noch nicht Teil kommerzieller Computersysteme.

4.2 A u f g a b e n einer a k t i v e n

Hilfekomponente

Die Teilaspekte von aktiven Hilfekomponenten, die in Abschnitt 3 am Beispiel von AKTIVIST aufgezeigt wurden,

sollen hier allgemeiner

betrachtet

werden.

4.2.1 P l a n e r k e n n u n g Eine der Hauptschwierigkeiten für eine aktive Hilfekomponente ist die Notwendigkeit, zu erkennen, was der Benutzer gerade tut, das heißt, in welchem Kontext er sich gerade befindet. Der Benutzer arbeitet frei, ohne Steuerung des Hilfesystems, mit dem Anwendungssystem. Das Hilfesystem muß also von selbst erkennen können, in welchem Bereich der Benutzer gerade arbeitet und welche Probleme er zu lösen versucht. Dies ist umso komplexer, je vielfältiger die Aufgaben sind, die mit dem Anwendungssystem gelöst werden können. Während des Erkennungsprozesses soll nun festgestellt werden, was der Benutzer tut und welche Mittel er dafür verwendet. Dabei soll das Verständnis über die rein syntaktische Ebene der Kommandos des Anwendungssystems hinausgehen zu einem mehr semantischen Verständnis in Begriffen des jeweiligen Anwendungsgebietes. Der Benutzer führt während dem Arbeiten mit dem Anwendungssystem Pläne aus. Robertson und Black [Robertson, Black 83] weisen dies bei Editoren nach. Allgemeine Beschreibungsmechanismen für Pläne und darauf aufbauende Planerkennungsverfahren werden in [Carver, Lesser, McCue 84; Genesereth 82; Schwab 88; Wilensky et al. 84] vorgestellt. Das Erkennen von komplexeren Plänen kann außer für den anschließenden Bewertungsvorgang auch direkt für Hilfeleistungen benutzt werden: das Ergebnis des Erkennungsprozesses nicht nur intern verwendet,

Wenn sondern

AKTIVIST

121

auch für den Benutzer offengelegt wird, ermöglicht dies eine zusätzliche Art von Hilfe. In Situationen, in denen der Benutzer unsicher ist, kann er auf die Frage „Was habe ich gerade getan?" eine eher dem Anwendungsgebiet angepaßte Antwort bekommen, als nur die Folge der von ihm benutzten Kommandos. Wenn ein Undo-Mechanismus (siehe Kapitel VIII) nicht nur auf der Ebene der Kommandos aufsetzt, sondern zusätzlich auf den erkannten Plänen, wird es möglich, auch komplexere Aktionen als Ganzes zurückzunehmen anstatt nur Einzelkommandos. In Zweifelsfällen ist es denkbar, daß sich das Hilfesystem beim Benutzer nochmals versichert, ob er einen bestimmten Plan ausgeführt hat. So kann sich ein Dialog entwickeln, der dazu dient, den Erkennungsvorgang sicherer und gleichzeitig einsichtig für den Benutzer zu gestalten. Das Hilfesystem kann ihm offenlegen, weshalb es der Ansicht ist, daß ein bestimmter Plan ausgeführt wurde. Allerdings kann durch zu häufiges Nachfragen des Hilfesystems der Benutzer beim Arbeiten erheblich gestört werden.

4.2.2

Bewertungsprozeß

Wenn eine P l a n a u s f ü h r u n g erkannt worden ist, kann die Beurteilung erfolgen, auf welche Art und Weise der Benutzer die Aufgabe bearbeitet hat. Dazu wird seine Lösung mit der eines Experten des Anwendungssystems verglichen. Das bedeutet, daß das Hilfesystem einen Expertenteil enthalten sollte, der zu einem vorgegebenen Problem aus dem Anwendungsgebiet die beste Lösung findet. So kann für den konkreten Zustand des Anwendungsprogramms die Vorgehensweise gefunden werden, die eine Aufgabe am besten ausführt. Das zu lösende Problem ist hierbei in Konzepten aus dem Problembereich beschrieben. Dabei soll die Lösung mit der des Benutzers verglichen werden, d.h. der Experte soll optimale Lösungen bezüglich gewisser Kriterien finden. Um überhaupt eine Bewertung angeben zu können, muß ein Maßstab oder eine Metrik vorhanden sein. In einfachen Bereichen ist eine Metrik meist relativ gut definierbar. So ist z.B. die Metrik für die Bewertung eines Spielerzuges bei [Burton, Brown 76] durch die Spielumgebung von „How The West Was W o n " noch leicht zu finden. In komplexen Bereichen lassen sich die Kriterien, die ein optimales Verhalten ausmachen, meist nicht in meßbaren Formen definieren.

Systeme zur Dialogunterstützung

122

Beispiel: Ein guter Skifahrer zeichnet sich durch Merkmale wie Schnelligkeit, Sicherheit und Eleganz aus. Hierbei sind Sicherheit und Eleganz schwer meßbare Kriterien. Gleichzeitig zeigt dieses Beispiel, wie sich Kriterien für eine Metrik selbst zum Teil widersprechen. So kann Schnelligkeit zum Teil nur auf Kosten von Eleganz erreicht werden. Welcher ist nun der bessere Skiläufer, der Schnellere oder der Elegantere? Ein Hilfesystem muß versuchen, eine meßbare und für den Computer leicht repräsentierbare Metrik zu verwenden. Bei AKTIVIST wurde die Anzahl der benötigten Tastenanschläge gewählt, was in einigen Fällen nicht unproblematisch sein kann. Besser wäre es, physische und kognitive Belastungen gleichermaßen zu berücksichtigen. Eine aktive Hilfekomponente kann vom Benutzer als aufdringlich empfunden werden, wenn sie immer wieder gleiches Benutzerverhalten kritisiert. Dies liegt oft an der bestehenden Diskrepanz zwischen der Metrik, die das Hilfesystem zur Bewertung der Benutzeraktionen heranzieht und dem Maßstab, den der Benutzer selbst zugrunde legt. Dieser Konflikt tritt auch bei einem hartnäckigen menschlichen Beobachter auf, wenn dieser gänzlich andere Vorstellungen davon hat, wie man etwas „ g u t " macht. Beispiel: Bevor der Fosbury Flop bekannt war, wurde im Hochsprung der Straddle als einzige richtige Technik angesehen. Ein Anfänger im Hochsprung wurde also von vorneherein auf diese Technik hin trainiert. Es wäre ihm nicht möglich gewesen, eine eigene Technik zu entwickeln. Inzwischen hat sich jedoch gezeigt, daß erst das Mißachten der traditionellen Lehrmeinung zu einer Leistungsverbesserung im Hochsprung geführt hat. Um dies etwas abzuschwächen, sollte die aktive Komponente ihre Kriterien zur Bewertung offenlegen, so daß der Benutzer weiß, weshalb er wird.

kritisiert

Es ist auch denkbar, daß der Benutzer aus einer Menge von fest

vorgegebenen Kriterien selbst auswählen kann.

4.2.3

Benutzermodellierung

Die meisten konventionellen Hilfesysteme ziehen Besonderheiten des individuellen Benutzers nicht in Betracht.

Vom Systemdesigner wird häufig ein

bestimmtes Benutzerbild in die Konstruktion eingebracht, welches dann bewirkt, daß das Hilfesystem auf verschiedene Benutzer immer gleich reagiert.

AKTIVIST

123

Ähnlich einem guten menschlichen Ratgeber sollte ein Hilfesystem sich den Eigenheiten des konkreten Benutzers anpassen. Um ein solches Verhalten erreichen zu können, muß sich das Hilfesystem nach und nach ein Modell über den Benutzer aufbauen. Dann wird es möglich individuelle Hilfe [Bauer, Schwab 87] anzubieten, die zum Beispiel das Vorwissen des Benutzers berücksichtigt. Für eine aktive Hilfekomponente können in einem Modell über den Benutzer folgende Wissensstrukturen enthalten sein: • Das konzeptionelle Verständnis des Benutzers vom System. • Die Aufgaben, die der Benutzer mit Hilfe des Anwendungssystems löst (ein Texteditor kann beispielsweise für so verschiedene Tätigkeiten wie Briefeschreiben oder Erstellung eines Programms in einer Programmiersprache benutzt werden). • Die dem Benutzer geläufigen Kommandos (die er ohne Probleme beherrscht). • Die Art und Weise, wie der Benutzer die problembereichspezifischen Aufgaben löst (z.B. ob er die Funktionalität des Anwendungssystems zu seinem Vorteil nutzt). • Die Fehler, die der Benutzer am häufigsten macht. • Die Hinweise, die das Hilfesystem dem Benutzer bisher gegeben hat. • Die Akzeptanz, auf die die vom Hilfesystem gegebenen Verbesserungsvorschläge beim Benutzer gestoßen sind. • Die Situationen, in denen der Benutzer von sich aus das Hilfesystem um Rat gefragt hat. Die Ergebnisse aus dem Erkennungs- und Bewertungsprozeß liefern wichtige Informationen, um das Benutzermodell aufzubauen. Ebenso können die fehlerhaften Aktionen des Benutzers zum Wissenserwerb herangezogen werden: ,,A user does not make arbitrary errors; all Operations are iterations towards a goal." [Norman 82]. Die Fragen, die der Benutzer an eine passive Hilfekomponente stellt, können dazu dienen, die Bereiche aufzuzeigen, in denen noch Unsicherheiten seitens des Benutzers vorhanden sind. Eine falsch gestellte Frage läßt unter Umständen auch Rückschlüsse auf ein falsches konzeptionelles Verständnis zu.

124

Systeme zur Dialogunterstützung

Nicht alle Merkmale, die im Modell über den Benutzer enthalten sind, müssen auch aus seinem Verhalten beobachtet worden sein. Durch Klassifizierung kann mit Hilfe von Stereotypen von einigen typischen Merkmalen auf andere geschlossen werden [Rieh 79; Reicherter 88].

4.2.4

Beobachtungssteuerung

In realistischen Anwendungen wird die Anzahl der potentiell zu erkennenden und bewertenden Pläne und Aktionen des Benutzers schnell die Grenze der verfügbaren Rechenleistung übersteigen. Es wird dann unmöglich, alle dem System bekannten Pläne gleichzeitig zu überwachen. Aus diesem Grund muß eine Vorauswahl der für die spezielle Situation und den speziellen Benutzer relevanten Pläne getroffen werden. Folgende Kriterien können hierzu herangezogen werden: • Pläne, die der Benutzer auf optimale Art und Weise ausführt, brauchen in Zukunft nicht mehr überwacht zu werden. • Sehr komplexe Pläne werden von Anfängern meist noch nicht ausgef ü h r t . Aufgrund der Klassifizierung des Benutzers [Rieh 79] können einige Pläne aus der Überwachung ausscheiden. • Durch Wissen über die Benutzerklasse, der der Benutzer angehört, kann auf typisches Fehlverhalten besonders geachtet werden. Dazu muß das Hilfesystem eine Sammlung von typischen Fehlern enthalten, die aufgrund von empirischen Untersuchungen festgestellt werden können. PROUST [Johnson, Soloway 84] zeigt einen Ansatz in diese Richtung, indem Pascal-Programme auf die für Anfänger typischen Fehler hin untersucht werden. • Der Benutzer kann seine Unsicherheit in einem bestimmten Bereich signalisieren, indem er von sich aus Fragen an eine passive Hilfekomponente richtet. Die Pläne, die diesen Bereich betreffen, können d a n n gezielt überwacht werden. Hier zeigt sich wiederum die Notwendigkeit, daß eine aktive und eine passive Komponente in ein Hilfesystem integriert sein sollten. • Dem Benutzer kann selbst die Auswahl überlassen werden, bei welchen Plänen er gezielt beobachtet werden soll. Er wäre dann in der Situation, mehr Kontrolle über die Hilfeaktivitäten zu haben, was zu einer erhöhten Akzeptanz des Systems führen kann. Es ist auch denkbar, daß er im voraus angibt, welchen der vorgegebenen Pläne er ausführen will, und das System seine Aktionen dann nur noch bewertet. Die Erkennungsphase wird dadurch stark vereinfacht.

125

AKTIVIST

4.2.5

Hilfestrategie

Da die aktive Hilfekomponente nicht auf direkte Anforderung durch den Benutzer tätig wird, muß die Hilfestrategie Kriterien enthalten, wann eingegriffen werden soll und was dann zu sagen ist. Diese Strategie wird sich neben globalen pädagogischen Gesichtspunkten hauptsächlich auf das erstellte Benutzermodell stützen. Dabei sind folgende Gesichtspunkte zu berücksichtigen: • Das System soll die Initiative dann Ubernehmen, wenn Schwächen des Benutzers offensichtlich werden. • Nicht jede suboptimale Aktion, die der Benutzer ausführt, soll zu einer Meldung des Systems führen. Nur häufig auftretendes suboptimales Verhalten soll eine Meldung des Hilfesystems auslösen. • Das Eingreifen des Systems soll für den Benutzer einsichtig sein. Es soll ein zeitlicher und sachlicher Bezug zu dem bemängelten Verhalten erkennbar sein. Die Offenlegung desjenigen Teils des Benutzermodells, der die Reaktion des Systems ausgelöst hat, kann als Begründung dienen. • Die Informationen sollen in einer dem Benutzer angemessenen dargeboten werden. • Informationen, die für die spezielle sind, sollen ausgefiltert werden.

Situation

nicht

von

Form

Bedeutung

• Das Hilfesystem soll den Benutzer bei einem schrittweisen Wachsen seiner Systemkenntnisse unterstützen. Einem Anfänger werden die komplexen Kommandos erst erklärt, wenn er die Grundlagen einigermaßen beherrscht. Grundsätzlich sollte der Benutzer die Möglichkeit haben, bei Meldungen der aktiven Hilfekomponente weiter nachfragen zu können.

Es sollte ein einfa-

cher Ubergang zur passiven Hilfekomponente vorhanden sein.

5. A b s c h l i e ß e n d e

Bemerkungen

Gerade bei aktiver Hilfe durch Rechnersysteme spielt die Frage der Akzeptanz eine große Rolle.

Der Benutzer kann sich z.B. durch die Hinweise in

seinem normalen Arbeitsfluß gestört fühlen. zuviel dazwischen.

Der „Beobachter" redet

ihm

Um dies zu verhindern, sollten die Hinweise der aktiven

Hilfekomponente auf eine Weise erfolgen, daß man sie auch ignorieren kann und erst später anschaut.

Bei AKTIVIST wurde dies dadurch erreicht, daß

126

Systeme zur Dialogunterstützung

die Hinweise in einem separaten Fenster ausgegeben werden, das der Benutzer auch später durch Zurückblättern inspizieren kann. Außerdem wurden die Hinweise so kurz wie möglich gehalten, um eine längere Unterbrechung zu vermeiden. Will der Benutzer mehr Information zu den vorgeschlagenen Kommandos, so kann er dies durch Anklicken mit der Maus erreichen. Er beginnt damit einen Dialog mit der passiven Hilfekomponente. Ebenso sollte das Verhalten der aktiven Hilfekomponente voll in der Kontrolle des Benutzers liegen. Dies reicht vom Einstellen, wie häufig m a n überhaupt Hinweise erhalten will, bis zum Grad, wie „kritisch" sich der Beobachter verhalten soll. Ein Experte legt an sich selbst oft strengere Maßstäbe an als ein Anfänger. Bei AKTIVIST hat der Benutzer mittels des Propertysheets (siehe Abbildung 7) die Möglichkeit, derartige Einstellungen vorzunehmen. Um einen Anfänger mit solchen Stellschrauben allerdings nicht zu überfordern, ist es sinnvoll, mit Voreinstellungen zu arbeiten, die durch empirische Untersuchungen zu ermitteln sind. Die Kontrolle des Benutzers soll natürlich auch soweit gehen, daß er die aktive Hilfeleistung zu jeder Zeit während des Dialogs an- und

abschalten

kann. Grundsätzlich sollte sich die aktive Hilfekomponente nicht aufdringlich verhalten. Es darf nie zu einer Situation kommen, in der die aktive Hilfekomponente den Benutzer zu einem bestimmten Verhalten zwingt. Ihre Aufgabe ist, den Benutzer auf gewisse Dinge aufmerksam zu machen. Ob der Benutzer dies in Zukunft auch befolgen will, muß in seiner alleinigen Entscheidung liegen. Ein Nichtbefolgen der Ratschläge darf nicht zu einem immer hartnäcker werdenden, besserwisserischen Verhalten des Hilfesystems führen. Sonst wäre der Name Hilfe-system nicht mehr angebracht.

VIII

WISYBIB

Einsatz von Undo/RedoM e c h a n i s m e n bei der V e r w a l t u n g einer L i t e r a t u r d a t e n b a n k Martin Rathke

Die Bearbeitung einer komplexen Aufgabe erfolgt im allgemeinen durch deren Zerlegung in mehrere Teilaufgaben, die - sukzessive angewandt - die Gesamtaufgabe lösen. Wenn Aufgaben in dieser Weise interaktiv mit einem Computersystem bearbeitet werden, kommt es gelegentlich zu Situationen, in denen der Rechner dem Benutzer ein Ergebnis präsentiert, das nicht dessen Erwartungen entspricht. Um einen solchen „Fehler" zu beheben, kann es notwendig sein, in den Zustand vor Ausführung der zuletzt bearbeiteten Teilaufgabe zurückzukehren oder bereits ausgeführte Teilaufgaben mit evtl. geänderten Parametern zu wiederholen. Diese Situation ist Ausgangspunkt für den Einsatz von Undo, dem Stornieren ausgeführter Aktionen, und Redo, dem Wiederholen ausgeführter Aktionen. Dieser Beitrag beschreibt ausgehend von zwei Beispielen für den Einsatz von Undo und Redo deren Verwendung im Rahmen des Literaturverwaltungssystems WISYBIB1. Von der speziellen Anwendung losgelöst werden Prinzipien zur Realisierung von Undo und Redo dargestellt.

Diese geben einen Einblick in Probleme

und technische Realisierungen im Zusammenhang mit der Stornierung und Wiederholung von Aktionen.

1. Spieler sind auch nur M e n s c h e n Welchem Schachspieler ist folgendes nicht schon passiert? Stundenlang spielt man mit einem ebenbürtigen Gegner. Irgendwann im Verlauf des Spieles glaubt man, einen entscheidenden Vorteil erzielt zu haben, den man aber gleich im nächsten Zug mit einem „ d u m m e n " Fehler wieder verspielt.

^ Window based System for maintaining BibUographies.

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter & Co. • Berlin • N e w York

128

Systeme zur Dialogunterstützung

Der Gegner gewinnt die Partie, obwohl er sie - wie er anschließend feststellt - eigentlich vor zehn oder zwölf Zügen hätte verlieren müssen. Man versucht dann, die Stellung vor zehn oder zwölf Zügen zu rekonstruieren, d.h. die letzten zehn oder zwölf Züge rückgängig zu machen. Wenn sich die Spieler nicht mehr genau an die damalige Stellung erinnern können, können sie die Stellung nur dann rekonstruieren, wenn sie ein Protokoll ihres Spiels geführt haben. Je nachdem, wie ausführlich dieses Protokoll ist, muß die Partie entweder von Anfang an nachgespielt werden, oder Zug für Zug läßt sich zurücknehmen. Ein derartiges Protokoll wird üblicherweise in der Zugnotation der Abbildung 1 geführt; es wäre zu aufwendig, nach jedem Zug die erreichte Spielstellung zu notieren.

1 4 Iii • 4 1 1 1 ! H i i n • l i lIIIi l í IIQIIl i l i l í A 83 IA II A tu IBI IBI A II IIA ¡II II 1 IIIIIIIIIIII III IDI I i i

Rossetto

-

Cardoso

40. Ld5 e:d5. Beim letzten Zug vor der Zeitkontrolle ist eine solche automatische Reaktion leicht verständlich, zumal 40. ... Sf8 nutzlos wäre: 41. T:e6 S8:e6 42. T:e6 und gewinnt. 41. D:g7tü Eines der schönsten schichte! Es folgte: 41. 42. 43. 44. 45. 46. 47.

Opfer der modernen

Schachge-

... K:g7 Sf5t Kg6 T e 6 t Sf6 T : f 6 t K:g5 Tle6 Tg2t K:g2 Dd8 Se7 aufgegeben.

Abbildung 1.

Schachnotationen.

Entnommen aus A. Koblenz „Schach lebenslänglich: Erinnerungen eines Erfolgstrainers", DeGruyter 1987

129

WlSYBIB

Ganz

anders sieht

ein Protokoll

bei der Lösung von

dem b e k a n n t e n Eisenbahnproblem

Spielproblemen

(vgl. Abbildung 2) aus.

wie

An einer engen

Ausweichstelle einer einspurigen Eisenbahnstrecke begegnen sich zwei Züge, die aus je einer Lokomotive u n d zwei Wagen bestehen. können

nicht

direkt

aneinander

vorbeifahren, da

auf

Die beiden dem

Züge

Ausweichstück

nur Platz f ü r eine Lokomotive u n d einen W a g e n oder f ü r zwei W a g e n ist. Die Lösung dieses Problems wird durch Angabe aller Zwischenzustände dargestellt.

/

rm rm rrfl

/

rm rm

\

itn rm rm

\

f^rmrm

fmm\

Itnrmrm

rrn rrn Fhi

/

\

rm rm

Hfl W! FFT!

/

\

imrmnil

Abbildung 2.

Die Lösung des Eisenbahnproblems.

Das P r o b l e m selbst wird in der Weise gelöst, daß m a n von einem gegebenen

Zustand

ausgehend wird,

Spielzüge die

dem

generiert, gewünschten

nach

deren

Zielzustand

Ausführung

eine

möglichst

nahe

Stellung

erreicht

kommt.

Wenn m a n deswegen in Sackgassen gerät, ist es erforderlich, einen

a u s g e f ü h r t e n Spielzug wieder z u r ü c k z u n e h m e n - eine F o r m eines U n d o wie sie auch bei der Analyse von Schachspielen Abstrahiert

vorkommt.

man von den Beispielen in bezug auf U n d o / R e d o ,

lassen sich

zwei Ergebnisse ableiten: 1. U m - mit Undo - zu einem früheren S y s t e m z u s t a n d ist es erforderlich, ein Protokoll zu führen.

zurückzukommen,

130

Systeme zur Dialogunterstützung

2. Ein solches Protokoll besteht aus einer Folge ausgeführter Aktionen (wie beim Schachspiel) oder einer Folge erreichter Systemzustände (wie bei der Lösung des Eisenbahnproblems). Angenommen, ein Rechner sollte solche Protokolle führen. Was müßte ihm mitgeteilt werden? Und in welcher F o r m müßte dies mitgeteilt werden? Im weiteren soll ein Rahmen für Protokolle entwickelt werden, der das Rückgängigmachen und Wiederholen von Aktionen erlaubt. Abschnitt 2 stellt mit WISYBIB ein Literaturverwaltungssystem vor, an dem exemplarisch Aktionsprotokolle und darauf aufbauend Undo/Redo-Möglichkeiten implementiert wurden. Abschnitt 3 erläutert den strukturellen A u f b a u und Besonderheiten der Implementierung für die Undo/Redo-Komponente. Abschnitt 4 ordnet die Lösung in einen allgemeinen Rahmen für U n d o / R e d o ein. Abschnitt 5 gibt eine Zusammenfassung. Die Protokollierung von Aktionen mit dem Ziel, Aktionen rückgängig machen zu können und Aktionen wiederholen zu können, wird eine wichtige Rolle spielen, wenn zukünftig Planungen und Analysen von Vorgängen fast ausschließlich über den Computer abgewickelt werden. Der vorliegende Beitrag gibt einen Einblick in dabei zu lösende Probleme und skizziert eine anwendungsneutrale technische Realisierung.

2. E i n e D a t e n b a n k für L i t e r a t u r wird

bearbeitet

Verschiedene Textverarbeitungssysteme im wissenschaftlichen Bereich ermöglichen es, bei der Zitierung von Literatur auf eine Literaturdatenbank rückzugreifen

und

vereinfachen

dadurch

das

Erstellen

eines

zu-

Literaturver-

zeichnisses zu einem Text erheblich. Bis ein Benutzer

auf

eine solche Literaturdatenbank

„einfache" Weise

zugreifen

kann,

hat

er

jedoch

auf

für

ihn

Einarbeitungsschwierigkeiten

zu

überwinden, weil die Literaturdatenbank in einer für das System geeigneten, jedoch

für den

Benutzer

Weise aufgebaut ist.

zunächst

nur

schwer

durchschaubar

gehaltenen

Die Folge ist, daß der Benutzer neben Editor

und

Textformatierer ein drittes System erlernen muß, das ihn bei der Erstellung von Texten mit Literatur unterstützt.

Das nachfolgend vorgestellte System

WISYBIB zur Verwaltung einer Literaturdatenbank bei dieser Arbeit entlastet werden kann.

zeigt, wie der

Benutzer

Es bietet ihm neben einem menü-

gesteuerten Zugang beim Eintragen neuer bzw. Löschen nicht mehr benötigter

Literaturzitate

die

Möglichkeit,

inkrementell

unter

Verwendung

Undo und Redo nach interessierenden Literaturstellen zu suchen.

von

131

WlSYBIB

Die Visualisierung erreichter Systemzustände bei der M a n i p u l a t i o n der Dat e n b a n k gestattet eine R ü c k k e h r in f r ü h e r erreichte S y s t e m z u s t ä n d e

durch

direkte Manipulation.

2.1 D i e

Eingabeschnittstelle

U m eine Ü b e r e i n s t i m m u n g

zwischen L i t e r a t u r z i t a t e n

im T e x t

u n d der

im

zugehörigen Literaturverzeichnis gesammelten L i t e r a t u r zu gewährleisten, sehen

Textverarbeitungssysteme

NROFF/TROFF

in V e r b i n d u n g

wie etwa mit

SCRIBE

REFER

[Reid,

[Tuthill

Walker

83]

eine

80]

oder

Möglichkeit

vor, T e x t und Literaturverzeichnis in einem Formatierlauf gemeinsam zu erstellen. gibt

Der Benutzer h a t getrennte Dateien f ü r Text u n d

innerhalb

seines

Textes

lediglich

mnemotechnische

Literatur

und

Kürzel

(z.B.

, , R a t h k e l 9 8 7 " ) an, mit deren Hilfe er auf E i n t r ä g e innerhalb der Literaturdatei Bezug n i m m t .

Die L i t e r a t u r d a t e i selbst e n t h ä l t die vollständigen Lite-

r a t u r z i t a t e in V e r b i n d u n g

mit

d e m Kürzel.

Besonders ökonomisch

kann

diese Technik verwendet werden, wenn an zentraler Stelle ein Literaturverzeichnis über die gesamte f ü r eine A r b e i t s u m g e b u n g

wesentliche

Literatur

g e f ü h r t wird u n d m e h t e r e Benutzer sich d a r a u s „ b e d i e n e n " . Systemspezifische Besonderheiten ergeben sich bei der E r f a s s u n g neuer Literatur.

So m u ß z.B. im F o r m a t i e r s y s t e m SCRIBE der Benutzer bei der Über-

t r a g u n g eines Zitats in die L i t e r a t u r d a t e n b a n k D o k u m e n t k l a s s e n

berücksich-

tigen wie „InProceedings",

usw.

jede Dokumentklasse füllt werden.

„TechReport",

„Article",

„Manual"

dürfen dabei jeweils nur b e s t i m m t e A t t r i b u t e

Abbildung 3 zeigt ein ausgefülltes F o r m u l a r der

klasse „InProceedings".

Für ausge-

Dokument-

D o k u m e n t e anderer Klassen können a n d e r e Attri-

b u t e e n t h a l t e n (z.B. „ J o u r n a l " bei „Article"). D a m i t ein Benutzer bei der Eingabe von neuer L i t e r a t u r nicht f ü r jede Dokumentklasse die auszufüllenden A t t r i b u t e im H a n d b u c h nachschlagen

bzw.

auswendig lernen muß, bietet ihm das System WlSYBIB die auszufüllenden A t t r i b u t e einer D o k u m e n t k l a s s e in F o r m eines F o r m u l a r s an, in d e m

der

Benutzer die notwendigen A t t r i b u t e in beliebiger Reihenfolge editieren k a n n . Gegenüber einer E r f a s s u n g von L i t e r a t u r ohne S y s t e m u n t e r s t ü t z u n g

ergeben

2

sich folgende Vorteile :

o

WlSYBIB löst nicht das Problem, daß der Benutzer sich bei der Erfassung von Literatur für eine Dokumentklasse entscheiden muß. Insofern lassen sich noch weitere ,Verbesserungen" am SCRIBE-Literatursystem denken.

132

Systeme zur D i a l o g u n t e r s t ü t z u n g

Dokument RathkeM1987c ••

.

©cfll:ia>-+?E Slots vvvvv

methods

rules

corefs constraints )) class-slots subclasses instances

4 1 J Iii fc €>X

v Abbildung 5.

Die Subklassen von menu.

Mit d e m Wechsel in die Klasse a c t l v e - m e n u erhält der Benutzer wieder ein leeres Textfenster - die Ausgaben werden also objektweise g e t r e n n t . zuvor u n t e r s u c h t er die A t t r i b u t e i n s t a n c e s 5, oberer Teil).

und s u b c l a s s e s

Wie

(Abbildung

Da a c t l v e - m e n u weder Instanzen noch Subklassen

besitzt,

Systeme zur P r o g r a m m i e r u n t e r s t ü t z u n g

176 kehrt

der Benutzer

zur

Klasse menu

zurück.

klicken des Backstep-Buttons erreichen.

Dies läßt sich d u r c h

An-

INSPECTOR reproduziert d a r a u f h i n

die Situation, die beim Verlassen der Klasse menu vorlag (vgl. A b b i l d u n g 4). Die zweite Subklasse ist p o p - u p - m e n u .

Hier findet der Benutzer u n t e r den

Instanzen ein O b j e k t n a m e n s i n s p e c t o r - t o p - m e n u Teil), das er im nächsten Schritt untersucht. Instanz

handelt,

fehlen im

Filtermenü

(Abbildung 5,

unterer

Da es sich hierbei u m eine

die E i n t r ä g e

Descr

und

Methods

(Abbildung 6).

Inspector f o r inspector-top-aenu ¡Filter Text

< El J Iii fr) ® X

Slots

(title = "inspector-menu") 1

islots

vvvvv Center-items? contents items last-sel pnaac-selector pointer-char redraw-pointer shadow-shift

Abbildung 6.

(contents * (move reshape newshape kill hury tobottoin totop nil input objects backstep path restep refresh shrink)) (last-sel = refresh) (pname-selector » (lambda (element) (or element " ")))

Die Instanz

inspector-top-menu.

Durch Ausgabe verschiedener um

das

gesuchte

"inspector-menu"

Objekt

Slots stellt der Benutzer sicher, d a ß es sich

handelt.

SPECTOR-Menüs wieder.

title

legt

den

String

gibt den Inhalt des IN-

Man sieht, daß die im Fenster erscheinende Leer-

zeile intern d u r c h das Symbol n i l enthält das zuletzt

Das A t t r i b u t

als Fenstertitel fest, C o n t e n t s

repräsentiert wird.

ausgewählte Menüelement,

Der Slot

pname-selector

last-sel spezifiziert

eine F u n k t i o n , die das Symbol n i l in einen leeren String umsetzt. Der anfängliche Mißerfolg bei der Suche läßt sich also darauf z u r ü c k f ü h r e n , daß das INSPECTOR-Menü nicht, wie e r w a r t e t , u n t e r d e m N a m e n tor-menu,

sondern

unter

inspector-top-menu

abgelegt

ist.

Ein

Sachverhalt stellt keine konstruierte Situation dar, sondern ist im mit C o m p u t e r n eher alltäglich.

inspecsolcher Umgang

Viele I n f o r m a t i o n e n , die auf einem Rechner

gespeichert sind, befinden sich nicht an der Stelle, an der man sie vermutet.

zuerst

Mit Hilfe von INSPECTOR war es im vorliegenden Fall möglich,

das gesuchte O b j e k t ohne allzu großen A u f w a n d ausfindig zu m a c h e n .

177

INSPECTOR

2.2 INSPECTOR als Teil e i n e r

Programmierumgebung

Im gerade gezeigten Beispieldialog w u r d e die Verwendung des INSPECTOR u n a b h ä n g i g von anderen Werkzeugen beschrieben.

Bei der Erstellung

S o f t w a r e k o m m t es jedoch nicht n u r auf die F u n k t i o n a l i t ä t einzelner

von Pro-

grammierwerkzeuge, sondern auch auf deren Zusammenspiel an. Abbildung

7 zeigt eine M o m e n t a u f n a h m e der objektorientierten

m i e r u m g e b u n g OBJENV [Schneider-Hufschmid 8 6 ] . „Desktop"

des O b j T a l k - P r o g r a m m i e r e r s

Program-

Dieses System k a n n als

angesehen werden.

Es

beinhaltet

ein Fenster n a m e n s „toplevel-pane", in dem der Lisp-Interpreter läuft, ein Fenster

namens

„break-pane",

das

der

Lisp-Interpreter

im

Fehlerfall

be-

n u t z t , sowie eine G r u p p e von Icons, aus der Werkzeuge zur Definition und Analyse von O b j e k t e n abgerufen werden können.

In der abgebildeten

Si-

t u a t i o n ist neben einem INSPECTOR-Fenster ein CLASSNET-Window aktiv. CLASSNET-Windows tionswerkzeugen. interne

[ R a t h k e C. 86a] bilden eine zweite F o r m von Naviga-

Im Gegensatz zu INSPECTOR, der den Zugriff auf o b j e k t -

Informationen

Struktur

des

ermöglicht,

Objektnetzes,

stellen

speziell

die

CLASSNET-Windows Klassenhierarchie,

die

äußere

graphisch

dar.

Jede Klasse wird d u r c h ein Icon repräsentiert, die Pfeile geben die Relation „ist Subklasse v o n " wieder.

Ausgehend von einer b e s t i m m t e n Klasse k a n n

der

Super-

Benutzer

sukzessive

die

bzw.

Subklassen

auf

den

Bildschirm

bringen 2 . F ü r das Z u s a m m e n w i r k e n der Werkzeuge gibt es in OBJENV eine einheitliche

Schnittstelle,

über

die

Objekte

ausgetauscht

werden

können.

Der

G r u n d g e d a n k e besteht darin, daß jedes Werkzeug ein „aktuelles O b j e k t " im F o k u s h a t , das entweder über die T a s t a t u r eingegeben oder mit der Maus selektiert werden k a n n - vorausgesetzt, daß es in irgendeiner F o r m auf d e m Bildschirm

repräsentiert

ist.

Für

die Auswahl mit der Maus werden

die

A n w e n d u n g s m e n ü s der einzelnen Werkzeuge u m folgende O p e r a t i o n e n erweitert: • select-window-with-mouse liefert zeigt (Fenster sind O b j e k t e ) . • select-window-class-with-mouse auf das der Benutzer zeigt.

das gibt

Fenster, die

Klasse

auf des

2 Zur Visualisierung hierarchischer S t r u k t u r e n siehe auch Kapitel XIV.

das

der

Fensters

Benutzer zurück,

178

Systeme zur Programmierunterstützung

toplevel-pane

© Commands 1 history redo last redo any

t 12:(ask simple-menu subclasses) TIME NI E DIO: 16 (setoli-menu menu) 13: 13:(ask popup-menu-mixin blerarchie) no object: popup-menu-mixin

opurnLfsrtprep

pause

Et'I rot

CJÊP

FX1T

Inspector for pop-up-menu-mix in Filter Slots Descr Methods

PP-U1HP0U

re» e nnUHijFE

i

B e a

Iii

Q>©::

«Text (refresh: =>=> , ¡(refresh: ) ,!(bury:)>

ref resh: select-with-«« save-be low: restore-below :

(select-with-mouse: ,*pos »>=> (prog2 , !(save-below: ) , ! ( se 1 ect-wi til-mouse :. pos) ,!(restore-below:))> Class-Net-W i ndow

( nEMi.t ) S

/ iCri'JE-nEHuj

(sirm-nEKu-i fiJiiaiUidBIg I ni xi h ) ^pßjjyp^

V

\

|VûF"-UF'-HENU*J i firrivE-l'OF-'l ( UP-HEMU J

>> break-pane

nil : Break return an object : pop-up-menu-mixin|

Abbildung 7.

« © Commands 1 message return return t retbrk abort f ancy

INSPECTOR in der Programmierumgebung OBJENV.

179

INSPECTOR

• select-object-with-mouse liefert das von einem Fenster repräsentierte Objekt. Bei Icons ist dies ein Verweis auf das dargestellte O b j e k t , bei Werkzeugen das aktuelle O b j e k t , bei Fenstern mit sensitiven Elem e n t e n k a n n eines dieser Elemente angeklickt werden. • select-object-class-with-mouse f u n k t i o n i e r t analog, nur d a ß anstelle des O b j e k t s die übergeordnete Klasse zurückgegeben wird. Hierzu ein Beispiel.

In Abbildung 7 hat der Benutzer mit Hilfe des CLASS-

NET-Windows die Hierarchie der Menüfenster u n t e r s u c h t .

Sein nächstes Ziel

war, die Klasse p o p - u p - m e n u - m i x i n im INSPECTOR genauer zu b e t r a c h t e n . Dazu h a t er aus d e m erweiterten

INSPECTOR-Menü

object-with-mouse

im

ausgewählt

und

die O p e r a t i o n

CLASSNET-Window

klickt, das p o p - u p - m e n u - m i x l n repräsentiert.

das

select-

Icon

ange-

Da sich diese Klasse im Fo-

kus des CLASSNET-Windows befindet, h ä t t e der Benutzer auch auf das Ges a m t f e n s t e r zeigen können.

3. F u n k t i o n a l i t ä t v o n INSPECTOR Bis j e t z t wurden die Eigenschaften des INSPECTOR a n h a n d von

Beispielen

demonstriert.

Die folgenden Abschnitte geben einen tieferen Einblick in die

Funktionalität

des Werkzeugs u n d

auf.

In diesem Z u s a m m e n h a n g

zeigen die zugrundeliegenden

Konzepte

wird beschrieben, wie das Verhalten

von

INSPECTOR erweitert werden k a n n .

3.1 A n f r a g e s p r a c h e n v e r s u s Betrachtet

man

INSPECTOR

von

der

Navigationswerkzeuge Implementierungsseite,

so stellt

man

fest, d a ß alle Informationen, die das Werkzeug nach außen gibt, über die reguläre

ObjTalk-Sprachschnittstelle

gewonnen

werden.

Damit

steht

IN-

SPECTOR im Gegensatz zu Stepping- und Tracewerkzeugen, die in das interne V e r h a l t e n von O b j T a l k eingreifen.

W ä h r e n d ein Stepper beispielswei-

se nach jeder Anweisung oder Nachricht die P r o g r a m m a u s f ü h r u n g

anhält,

sendet INSPECTOR in konventioneller Weise Nachrichten an O b j e k t e , so wie es der Benutzer im Lisp-Toplevel auch t u n k a n n .

Unter diesem Gesichts-

p u n k t stellt sich die Frage „ B r a u c h t m a n ein solches Werkzeug ü b e r h a u p t ? " Zur B e a n t w o r t u n g

dieser Frage

betrachten

wir

zunächst

die

Nachrichten,

die der Benutzer im vorher gezeigten Beispieldialog h ä t t e eingeben müssen: (ask inspector-menu a l l - s l o t s : )

==>

no o b ] e c t :

inspector-menu

(ask menu i n s t a n c e s ) ==> n i l (ask menu s u b c l a s s e s ) ==> (active-menu pop-up-raenu . . . )

180

Systeme zur P r o g r a m m i e r u n t e r s t ü t z u n g (ask active-menu instances) ==> nil (ask active-menu subclasses) ==> nil (ask pop-up-menu Instances)

==>

(inspector-top-menu

(ask inspector-top-menu all-slots:) (ask inspector-top-menu title) ==>

... )

==> (pname ... title "inspector-menu"

. . . )

Diese Schnittstelle h a t s t a r k e Ähnlichkeiten mit Anfragesprachen, wie sie bei D a t e n b a n k s y s t e m e n eingesetzt werden.

Anfragesprachen sind jedoch f ü r die

interaktive Informationssuche n u r bedingt geeignet: • Bei V e r w e n d u n g einer Anfragesprache m u ß der Benutzer in j e d e m Zugriffsschritt die gewünschten Informationen vollständig beschreiben. Das heißt, er f ü h r t mit jeder A n f r a g e einen Direktzugriff aus und k e h r t anschließend zu seiner Ausgangsposition zurück (Abbildung 8). Auf diese Weise ist es unmöglich, lokale S u c h u m g e b u n g e n zu bilden. • A n f r a g e s p r a c h e n sind an t a s t a t u r o r i e n t i e r t e Schnittstellen gebunden u n d erfordern deshalb einen hohen A u f w a n d bei der Spezifikation der Anfrage. E n t s p r e c h e n d häufig k o m m t es zu Eingabefehlern (z.B. d u r c h Vertippen). • A n f r a g e s p r a c h e n bieten von sich aus wenig U n t e r s t ü t z u n g . Der Benutzer m u ß sich auf die F o r m u l i e r u n g von A n f r a g e n konzentrieren und befindet sich d e m C o m p u t e r gegenüber stets in der Rolle des Sprechers. D a r ü b e r hinaus m u ß er sich frühere A n f r a g e n selbst merken, sofern sie nicht zufällig noch auf dem Bildschirm stehen. Dies bedeutet eine zusätzliche Belastung des Gedächtnisses.

Informationsmenge

Abbildung 8.

Informationszugriff mit einer Anfragesprache.

Im Vergleich

dazu

werden:

können

Navigationswerkzeuge

wie folgt

J

charakterisiert

181

INSPECTOR

• Der Benutzer bleibt nicht vor der Informationsmenge stehen, sondern er bewegt sich auf inkrementelle Weise d u r c h die I n f o r m a t i o n s m e n g e h i n d u r c h (Abbildung 9). Bei j e d e m Navigationsschritt gibt er lediglich die Spezifikationen an, die die augenblickliche Position von der Zielposition unterscheiden. Im Dialog mit INSPECTOR lauten diese Spezifikationen „gehe zur ersten Subklasse", „zeige davon die I n s t a n z e n " , „gehe zurück zum letzten O b j e k t " usw. • D u r c h den Einsatz eines Zeigeinstruments läßt sich der E i n g a b e a u f w a n d wesentlich herabsetzen. Bei INSPECTOR benötigt m a n n u r im ersten Schritt, d.h. beim Einstieg in das O b j e k t n e t z die T a s t a t u r . • Das Formulieren von A n f r a g e n wird d u r c h Menüauswahl ersetzt. Damit zeigt das Werkzeug dem Benutzer mögliche Suchrichtungen auf u n d versetzt ihn gleichzeitig von der schwierigen Rolle des Sprechers in die des Hörers [Fischer 8 3 b ] . Daneben können Dialogprotokolle g e f ü h r t u n d graphische Ausgaben erzeugt werden, u m die Orientierung bei der Informationssuche zu erleichtern (siehe Abschnitt 3.2).

! Abbildung 9.

Informationszugriff mit einem Navigationswerkzeug.

Anfragesprachen und

Navigationswerkzeuge unterscheiden sich also

weniger

darin, welche I n f o r m a t i o n e n sie liefern, sondern wie m a n zu den I n f o r m a t i o nen gelangt.

A n f r a g e s p r a c h e n sind immer

Suchziel von

vornherein

genau

beschreiben

dann läßt.

geeignet, wenn Diese Situation

sich

das

ist

bei-

spielsweise beim Formulieren von Algorithmen, d.h. beim Erstellen von P r o g r a m m e n gegeben. Bei der i n t e r a k t i v e n Fällen a n d e r s aus. sung

er

irgendwo

3

.

.

.

.

.

Informationssuche sieht die Situation

in den

meisten

Der Benutzer h a t ein b e s t i m m t e s Problem, dessen Löin

den

vorhandenen

.

Informationsstrukturen

vermutet3.

Siehe v o r i g e r Beispieldialog: die A u s g a n g s f r a g e h ä t t e a u c h l a u t e n k ö n n e n „ W i e t i e r t m a n Leerzeilen in einem M e n ü ? "

repräsen-

182

Systeme zur Programmierunterstützung

Dabei läßt sich zu Beginn der Suche weder sagen, auf welchem Weg man zur Lösung kommt, noch, ob m a n überhaupt eine Lösung findet. In einem solchen Kontext sind Navigationswerkzeuge besser geeignet. Sie machen es dem Benutzer einfacher, zuerst diesen, dann jenen Ausschnitt der vorhandener! Informationsmenge zu untersuchen. Der im englische Sprachraum gebräuchliche Ausdruck Browser beschreibt die angewandte Vorgehensweise in einer bildlichen Form: das Verb ,,to browse" bedeutet wörtlich übersetzt soviel wie „in einem Buch schmökern" oder „eine Wiese abgrasen".

3.2 O r i e n t i e r u n g i m

Objektnetz

Bei Navigationswerkzeugen, die zu jedem Zeitpunkt nur ein Element aus der vorhandenen Informationsmenge darstellen, besteht die Gefahr, daß der Benutzer nach einigen Positionsveränderungen die Orientierung verliert. Um dem entgegenzuwirken, protokolliert INSPECTOR den Weg, auf dem sich der Benutzer durch das Objektnetz bewegt. Dieses Protokoll liefert die Grundlage für folgende Funktionen: • Backstep bringt das zuvor eingestellte Objekt in den Fokus von INSPECTOR. Mit dieser Operation kann der Benutzer in Einzelschritten bis zum Ausgangsobjekt zurückgehen. Die Backstep-Operation stellt eine spezielle Ausprägung der allgemeinen Undo-Funktionalität dar 4 . • Path bringt ein Menü auf den Bildschirm, das den bisher zurückgelegten Weg aufzeigt. Eine Auswahl aus diesem Menü entspricht einer mehrstufigen Backstep- bzw. Restep-Operation. • Restep macht eine Backstep-Operation rückgängig, d.h. der Benutzer bewegt sich wieder in Richtung seines ursprünglichen Suchziels. Restep kann nur nach einem vorausgegangenen Backstep ausgeführt werden. Die Einschränkung hinsichtlich der Restep-Operation beruht darauf, daß der aufgezeichnete P f a d keine hierarchische Struktur darstellt, sondern nur den direkten Weg vom Ausgangsobjekt zum aktuellen Objekt angibt.

Schlägt

der Benutzer nach einem Backstep eine neue Richtung ein, so wird der bisherige Ast abgeschnitten 5 .

Das Abschneiden geschieht unter zwei Aspekten:

Zum einen soll der P f a d als solches übersichtlich gehalten werden (die Darbietung durch ein Menü erlaubt nur eine lineare Form), zum anderen ist

4

Z u m T h e m a U n d o / R e d o siehe K a p i t e l VIII.

5

Diese V o r g e h e n s w e i s e ist eine M i s c h f o r m aus sog. T r a v e l - u n d R e t r a c t - U n d o (Seite 140.)

183

INSPECTOR

die Backstep-Operation in erster Linie dazu gedacht, u m aus Sackgassen zurückzukehren (wie im vorigen Beispieldialog bei der Klasse a c t l v e - m e n u ) . Da t r o t z d e m der Fall eintreten k a n n , daß der Benutzer zu einem

Objekt

zurückkehren will, das nicht mehr im P f a d e n t h a l t e n ist, f ü h r t INSPECTOR eine zweite Liste, in der alle untersuchten O b j e k t e e n t h a l t e n sind - in der Reihenfolge, in der sie erstmals angesprochen w u r d e n .

Hierzu existiert ein

zweites Menü, das der Benutzer über den O b j e c t s - B u t t o n aktivieren

kann.

Abbildung 10 zeigt dieses Fenster zusammen mit d e m P a t h - M e n ü - die Einträge entsprechen der Situation, die a m E n d e des Beispieldialogs von Abschnitt 2.1 vorlag.

In beiden Menüs erscheint das gerade b e t r a c h t e t e

Ob-

jekt in p u n k t i e r t e r Schrift (um anzudeuten, daß eine Selektion keinen Sinn macht).

obj ects

menu active-menu pop-up-menu

menu pop-up-menu

ìnspector-top-aonu

ins pect or-to|i-»enu

Abbildung 10.

Protokollierung der u n t e r s u c h t e n O b j e k t e u n d des Pfades.

Eine andere Möglichkeit, sich im O b j e k t n e t z zurechtzufinden, besteht d a r i n , parallel zu INSPECTOR einen sog. „ N e t z b r o w s e r " einzusetzen, der eine graphische Darstellung der N e t z s t r u k t u r erzeugt.

In A b s c h n i t t 2.2 w u r d e m i t

CLASSNET-Windows ein derartiges Werkzeug bereits vorgestellt.

D a CLASS-

NET-Windows auf Klassen spezialisiert sind, k a n n der Benutzer mit diesem Werkzeug einen ersten Überblick Uber den A u f b a u u n d die Bestandteile eines objektorientierten P r o g r a m m s y s t e m s gewinnen.

Interessiert er sich f ü r

Details, so benötigt er einen Netzbrowser, der passend zu INSPECTOR u n t e r schiedliche nen kann.

Objektarten

und

verschiedenartige

Objektbeziehungen

aufzeich-

Ein entsprechendes Werkzeug wird in K a p i t e l XI mit d e m Sy-

stem ZOO beschrieben.

3.3 Die Rolle der

Filter

Im zurückliegenden Beispieldialog k o n n t e m a n sehen, d a ß die E i n t r ä g e

im

Filtermenü des INSPECTOR nicht von statischer A r t sind, sondern mit d e m betrachteten O b j e k t wechseln. u n d Methods

So werden z.B. bei Klassen die Filter

angeboten, die bei gewöhnlichen Instanzen fehlen.

Descr

Hinter die-

184

Systeme zur P r o g r a m m i e r u n t e r s t ü t z u n g

ser Tatsache, die zunächst nur beiläufig e r w ä h n t wurde, s t e h t ein grundlegendes Prinzip:

Das Verhalten von INSPECTOR soll nicht bei allen O b j e k -

ten dasselbe sein, sondern vom T y p des O b j e k t s abhängen.

D a m i t wird es

möglich, spezielle Eigenschaften der O b j e k t e zu berücksichtigen. Zur Realisierung des objektspezifischen Verhaltens k a n n jede O b j T a l k - K l a s s e mit einer Anzahl von Filtern versehen werden. stanzen dieser Klasse a n w e n d b a r O b j e k t e in den V o r d e r g r u n d .

Jeder Filter ist auf die In-

u n d stellt einen b e s t i m m t e n

Aspekt

Gleichzeitig findet eine V e r e r b u n g

der

entlang

der Klassenhierarchie s t a t t , d.h. der Filter s t e h t auch f ü r die Instanzen der Subklassen zur Verfügung.

So wird beispielsweise der Filter Slots

se o b j e c t zugeordnet, die sich an der Spitze der befindet.

Slots

der Klas-

ObjTalk-Klassenhierarchie

ist d a m i t als elementarer Filter f ü r alle O b j e k t e v e r f ü g b a r .

Die Darstellung der einzelnen Filter geschieht wiederum in F o r m von jekten.

Ob-

F i l t e r o b j e k t e sind d u r c h folgende A t t r i b u t e gekennzeichnet:

pname

Filter mit gibt den im F i l t e r m e n ü erscheinenden N a m e n a n . gleichem N a m e n werden bei der Vererbung ersetzt, wobei der mit der Subklasse assoziierte Filter Vorrang h a t .

owner

b e s t i m m t die Klasse, f ü r die der Filter definiert wird.

items

spezifiziert eine Funktion, mit der die Einträge für das zweite INSPECTOR-Menü berechnet werden (in Abhängigkeit vom aktuellen Objekt).

entry

spezifiziert eine F u n k t i o n , mit der das Ergebnis f ü r das T e x t fenster erstellt wird (in Abhängigkeit vom aktuellen O b j e k t und d e m ausgewählten Menüeintrag).

printer

legt die F o r m a t i e r u n g des Ergebnisses fest. Als Voreinstellung dient eine dem L i s p - P r e t t y - P r i n t e r ähnliche F u n k t i o n .

Mit der Realisierung der Filter d u r c h weitere interessante Gesichtspunkte.

O b j T a l k - O b j e k t e ergeben sich

Zum einen können diejenigen

zwei

Mecha-

nismen, die das Verhalten des Werkzeugs steuern, mit d e m W e r k z e u g selbst inspiziert werden. Filterobjekte

an

Zum a n d e r n k a n n INSPECTOR durch Definition weiterer neue A n f o r d e r u n g e n

angepaßt

werden.

Damit

wird

das

Verhalten des Werkzeugs nicht v o m Systementwickler allein b e s t i m m t , sondern k a n n von jedem O b j T a l k - P r o g r a m m i e r e r erweitert und v e r ä n d e r t werden. Hierzu ein Beispiel.

Mit Hilfe der Klasse a r r a y wurde eine o b j e k t o r i e n t i e r -

te R e p r ä s e n t a t i o n von Vektoren erstellt.

Instanzen von a r r a y besitzen die

Slots s i z e u n d c o n t e n t s , in denen die Größe bzw. die Elemente des Vek-

185

INSPECTOR

tors gespeichert werden.

Mit der Methode g e t - e l e m e n t :

Elemente abgefragt werden.

können einzelne

Um den Inhalt eines Vektors mit INSPECTOR

zu untersuchen, wird der Filter Elements

definiert:

(ask inspector-filter Instantiate: (pname = "Elements") (owner = array) (items = (lambda (object) (list-of-array-indices (ask .object size)))) (entry = (lambda (object n) (list 'element n '= (ask .object get-element:

Inspector for test-array Filter Slots

Eleaents

,n)))))

4 ED «0 III lb ©M

IText (size = 8) (contents = ARRAYC81)

Elements

(element 0 = "Element Nummer null") (element 1 - "Element Nummer eins") (element 2 = "Element Nummer zwei") (element 3 = nil) (element 4 = nil)

Abbildung 11.

Definition und Anwendung des Filters

Elements.

4. Z u s a m m e n f a s s u n g und Ausblick Mit der Implementierung von INSPECTOR wurde das Ziel verfolgt, ein Werkzeug bereitzustellen, das den ObjTalk-Programmierer bei der Untersuchung von Objektstrukturen unterstützt. Während Netzbrowser die Verbindungen zwischen Objekten sichtbar machen, ermöglicht INSPECTOR den Zugriff auf objektinterne Informationen. Zusätzlich bietet das Werkzeug dem Benutzer die Möglichkeit, durch das Objektnetz zu navigieren. INSPECTOR kann daher in Kombination mit einem Netzbrowser, aber auch unabhängig eingesetzt werden. Durch die Verwendung von Filtern wird ein flexibles Verhalten des Werkzeugs erreicht.

Zum einen können Objekte unter verschiedenen

Aspekten

betrachtet werden, zum andern läßt sich die Funktionalität des Werkzeugs durch Definition neuer Filter erweitern.

Das Filterkonzept ist gleichzeitig

186

S y s t e m e zur

Programmierunterstützung

der P u n k t , an d e m sich INSPECTOR von anderen W e r k z e u g e n dieser gorie - wie e t w a d e m S m a l l t a l k - I n s p e c t o r der S y m b o l i c s L i s p - M a s c h i n e

Kate-

[ G o l d b e r g 84] oder d e m I n s p e c t o r

[ S y m b o l i c s 8 6 ] - unterscheidet.

Hinsichtlich des F i l t e r k o n z e p t s sind verschiedene Weiterentwicklungen bar.

denk-

Im A u g e n b l i c k werden F i l t e r o b j e k t e unter V e r w e n d u n g eines gewöhnli-

chen E d i t o r s erstellt.

Hier wäre es sinnvoll,

dem Programmierer

ein

sog.

, , F i l t e r - C o n s t r u c t i o n - K i t " zur V e r f ü g u n g zu stellen, mit dessen Hilfe er neue Filter über eine f o r m u l a r o r i e n t i e r t e Schnittstelle definieren könnte (vgl. d a z u die S y s t e m e vorstellbar,

TRISTAN u n d

TRIKIT

in G r u p p e n

in K a p i t e l

XIV).

Des weiteren

ist

es

einzuteilen, so daß INSPECTOR j e n a c h

Be-

nutzer oder j e nach A n w e n d u n g m i t einem speziellen S a t z von F i l t e r n

ar-

beitet.

Filter

XI

ZOO

E i n W e r k z e u g zur G e s t a l t u n g von Anwendungssystemen durch den E n d b e n u t z e r Wolf-Fritz Riekert

Jeder arbeitende Mensch besitzt einen ganz persönlichen Stil, der sich darin zeigt, nach welchen Abläufen er seine Aufgaben erledigt und wie er dabei Arbeitsgeräte und Arbeitsgegenstände einsetzt. Damit sich ein solcher Stil auch entfalten kann, braucht der Mensch Handlungsspielräume, innerhalb deren er seine Arbeit frei gestalten kann. An Rechnerarbeitsplätzen ist dieser Spielraum weitgehend durch die verwendete Software bestimmt. Damit auch hier ein individueller Arbeitsstil möglich ist, muß der Computerbenutzer in die Lage versetzt werden, die von ihm benutzten Software-Systeme selbständig umgestalten zu können. Software-Systeme sind jedoch im Normalfall durch Programme definiert, deren Code der durchschnittliche Benutzer nicht durchschaut. Nur Programmierer sind imstande, den A u f b a u eines solchen Systems zu verstehen und gegebenenfalls zu verändern. In diesem Kapitel wird eine alternative Software-Architektur vorgestellt, in der die F a k t e n und Konzepte des Anwendungsgebiets nicht in Programmen kodiert, sondern in einer Wissensbasis repräsentiert sind. Diese Wissensbasis erscheint für den Benutzer als eine Netzstruktur; dabei repräsentieren die Knoten dieses Netzes die O b j e k t e des Anwendungsgebiets, die Kanten des Netzes stehen für die Beziehungen zwischen den Objekten. Zur Anpassung des Software-Systems an neue Bedürfnisse muß nicht mehr programmiert werden, es muß lediglich die Netzstruktur modifiziert werden. Hierfür sind neue, benutzerorientierte Software-Werkzeuge erforderlich. Ein derartiges Werkzeug ist der Wissenseditor ZOO1, der im folgenden vorgestellt werden soll. ZOO ist ein Software-System, mit dessen Hilfe Wissensnetze graphisch dargestellt und durch direkte Manipulation verändert werden können.

1

Der Name ZOO steht für „ZOO ordnet O b j e k t e " .

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter & Co. • Berlin • N e w York

188

Systeme zur Programmierunterstützung

Dies soll am Beispiel eines elektronischen Kommunikationssystems verdeutlicht werden, das den Vorgang des Schreibens, Versendens, Empfangens und Lesens von Briefen unterstützt. Wir gehen auf die genaue Ausgestaltung der Benutzerschnittstelle des Kommunikationssystems hier nicht ein; für die folgenden Betrachtungen ist es nicht von Bedeutung, ob die Benutzung des Postsystems auf direkter Manipulation von Bildschirmobjekten wie im Büroinformationssystem STAR der Firma Xerox [Smith et al. 82] oder auf einer Kommandosprache wie im Betriebssystem UNIX [UNIX 83] beruht. Der entscheidende Unterschied zu den herkömmlichen Systemen liegt im Inneren des Kommunikationssystems. Dort ist alles Wissen über Briefe, Postfächer usw. in einem Netz von Objekten repräsentiert. Dies gilt sowohl für die Fakten, mit denen das Postsystem umgeht, wie auch für die Konzepte, die dem Postsystem zugrundeliegen. Diese netzartige Repräsentation von Wissen ist Voraussetzung für die Anwendbarkeit des Wissenseditors ZOO. Mit Hilfe von ZOO ist es möglich, das Wissensnetz, das dem Postsystem zugrundeliegt, in einer graphischen Form zu bearbeiten.

1. ZOO als Benutzerschnittstelle zum Faktenwissen Unter Faktenwissen verstehen wir das Wissen um konkrete Objekte der Anwendungswelt und um ihre Beziehungen zueinander. In herkömmlichen Software-Systemen ist dieses Wissen durch Daten repräsentiert, die in einer Datenbank verwaltet werden. Was die Repräsentation von Fakten anbetrifft, ist der in unseren Systemen gewählte, auf Wissensnetzen basierende Formalismus den klassischen Datenbankmodellen gleichwertig. Er hat darüber hinaus den Vorteil, daß er besonders anschaulich ist, weil er eine graphische Interpretation nahelegt. In Abbildung 1 ist demonstriert, wie das Faktenwissen unseres Postsystems durch das System ZOO in einem Bildschirmfenster graphisch angezeigt wird. Konkrete Objekte, wie der Posteingangskorb m a i l - i n , der Brief L-26 und der Postteilnehmer John, sind durch Icons mit quadratischem Umriß dargestellt. Objekten desselben Typs sind dabei die gleichen graphischen Symbole zugeordnet. Der Name des Objekts erscheint als Inschrift im zugeordneten Icon. Relationen zwischen Objekten, wie z.B. die Absenderbeziehung der Person Michael zum Brief L-25 oder das Enthaltensein des Briefes L-25 im Posteingang m a l l - l n , werden durch Pfeile dargestellt. Diese Pfeile verbinden

189

ZOO

mail »«« v i s i t i n g

letter

1-25

@ CEj

^RECEIVER" —SENDER— ^—DATE— 3

Abbildung 1.

Die Fakten aus dem Anwendungsgebiet des elektronischen Postverkehrs werden durch Objektnetze dargestellt.

die entsprechenden Objekte miteinander und sind mit dem Namen der betreffenden Relation (hier s e n d e r bzw. c o n t e n t s ) beschriftet. Die Funktionen des Systems ZOO können durch Anklicken der Funktionssymbole am rechten Rand des Bildschirmfensters ausgelöst werden. Die meisten dieser Funktionen beziehen sich auf den momentan „besuchten" Ort im Wissensnetz. Dieser Ort erscheint auf dem Bildschirm durch Inversdarstellung deutlich herausgehoben. Man kann einen Ort im Wissensnetz besuchen, indem man mit der Maus auf ihn zeigt. In Abbildung 1 wird gerade der Brief L-25 besucht. Mit Hilfe der Funktion EDIT kann der Brief L-25 inspiziert werden. Die Eigenschaften des Objekts erscheinen in einem Property-Sheet (siehe Abbildung 2). Außer den Namen der Objekte, die mit dem Brief in einer Relation stehen, werden zwei elementare Attribute des Briefes sichtbar, nämlich der Betreff ( s u b j e c t ) und der textuelle Inhalt ( t e x t ) des Briefes. Eigenschaften, die nicht in einer Zeile des Property-Sheets Platz haben, werden abgekürzt dargestellt und können in voller Länge nur mit Hilfe eines Texteditors betrachtet werden. Durch die Selektion des Funktionssymbols STEP kann eine Navigation durch die Wissensbasis begonnen werden. Unter Navigation verstehen wir das Durchwandern des Wissensnetzes längs von Kanten. Dabei werden schrittweise Nachbarpositionen im Netz besucht. Wenn der Benutzer Teile

190

Systeme zur P r o g r a m m i e r u n t e r s t ü t z u n g

mall *** v i s i t i n g

Abbildung 2.

letter

1-Z5

Die Eigenschaften des Briefs £,-26 werden in einem P r o p e r t y Sheet angezeigt.

des Netzes a n s t e u e r t , die noch nicht auf d e m Bildschirm sichtbar sind, so erscheint das betreffende O b j e k t bzw. die b e t r e f f e n d e Relation an einer v o m System

bestimmten

Bildschirmposition

und

kann

von

dort

mit

F u n k t i o n MOVE v o m Benutzer nach Belieben wegbewegt werden.

Hilfe

der

Abbildung

3 zeigt das Ergebnis einer Navigation ausgehend v o m Brief L-24 in Richtung des Absenders des Briefes. Thomas erschienen.

Als neues O b j e k t war dabei die P e r s o n

Eine weitere Navigationsaktion

in R i c h t u n g

des

Em-

nur

gra-

pfängers des Briefes wird gerade begonnen. Mit

ZOO können

wir

das

Netz

von

Wissensbasisobjekten

nicht

phisch darstellen, wir können es auch modifizieren: • Wir können die Eigenschaften eines O b j e k t s v e r ä n d e r n , indem wir die E i n t r ä g e im betreffenden P r o p e r t y - S h e e t überschreiben. • Wir können die Relationen zwischen O b j e k t e n v e r ä n d e r n , indem wir K a n t e n zwischen den O b j e k t e n löschen oder neue K a n t e n h i n z u f ü g e n . Das Herstellen u n d das Lösen von Relationen geschieht mit Hilfe der Maus und des F u n k t i o n s s y m b o l s LINK. • Durch Kopieren von existierenden O b j e k t e n können wir mit Hilfe der F u n k t i o n COPY neue O b j e k t e erzeugen. • Mit Hilfe der F u n k t i o n DEL können wir ganze O b j e k t e aus der Wissensbasis löschen.

Zoo

191 Step t o . . .

Abbildung 3.

Durch Navigation im Wissensnetz u n d Relationen e r k u n d e t werden.

können

Alle diese Operationen haben sofortige Auswirkungen gende Wissensnetz.

weitere

auf das

Auf diesem Wissensnetz operiert auch das

Objekte

zugrundeliebetrachtete

Postsystem, deshalb werden bei dessen Benutzung die v o r g e n o m m e n e n

Än-

derungen u n m i t t e l b a r sichtbar.

2. ZOO als B e n u t z e r s c h n i t t s t e l l e z u m k o n z e p tuellen W i s s e n Das Faktenwissen, das einem Anwendungssystem

zugrundeliegt, ist Wissen,

das sich bei der Benutzung des Systems f o r t w ä h r e n d ä n d e r t und an schiedlichen Einsatzorten gen besitzt.

des Systems gänzlich unterschiedliche

unter-

Ausprägun-

So sind unserem Postsystem abhängig von der Zeit oder

dem

O r t der Installation jeweils a n d e r e Postfächer, Briefe und P o s t t e i l n e h m e r bekannt.

Es gibt jedoch auch invariantes Wissen, also solches, das sich bei

der normalen B e n u t z u n g des Systems nicht ä n d e r t . seres Postsystems ist beispielsweise d a d u r c h

Die F u n k t i o n a l i t ä t

un-

festgeschrieben, daß es P o s t f ä -

cher, Briefe und Postteilnehmer repräsentieren kann, wobei jeder Brief einen Absender, einen Adressaten u n d einen Inhalt besitzt, und d a ß m a n versenden k a n n .

Hingegen ist es unmöglich, mit dem P o s t s y s t e m

Briefe Meßda-

tenerfassung zu betreiben oder Tabellenkalkulationen v o r z u n e h m e n .

Mit ei-

nem W o r t : das f ü r das System invariante Wissen b e t r i f f t Konzepte.

Dabei

192

Systeme zur Programmierunterstützung

verstehen wir unter Konzepten ganz allgemein die verschiedenen darstellbaren Typen von Objekten sowie die Prädikate und Funktionen, die auf diese Objekte anwendbar sind. Das Wissen um diese Konzepte bezeichnen wir als konzeptuelles Wissen. Es stellt eine Abstraktion des potentiell vorhandenen Faktenwissens dar, es ist Wissen über Faktenwissen.

Abbildung 4.

Auch konzeptuelles Wissen wird in F o r m von Netzen dargestellt.

In den meisten Anwendungssystemen ist das konzeptuelle Wissen im Programmcode verschlüsselt. In seiner ursprünglichen F o r m existiert es lediglich im Kopf des Entwicklers oder bestenfalls in der P r o g r a m m d o k u m e n t a tion. In der Wissensbasis unseres Postsystems ist das konzeptuelle Wissen jedoch explizit repräsentiert, und zwar ebenso wie das Faktenwissen in Form eines Netzes. Mit dem Wissenseditor ZOO können wir auch diese Art von Wissen inspizieren. Zu diesem Zweck vergrößern wir das Bildschirm-

Zoo

193

fenster.

Dabei wird die graphische R e p r ä s e n t a t i o n des konzeptuellen

Wis-

2

sens sichtbar (Abbildung 4) . Die K o n z e p t e des Postsystems sind als O b j e k t e repräsentiert, sie erscheinen ähnlich wie die konkreten

O b j e k t e des Anwendungsgebiets

lassen sich drei A r t e n von Konzepten

unterscheiden:

als Icons.

Klassen,

Es

Methoden

u n d Slots. Klassen

sind a b s t r a k t e

Objekte, die die gemeinsamen

Menge gleichartiger konkreter O b j e k t e repräsentieren. sentiert die Klasse l e t t e r

Eigenschaften einer Beispielsweise

reprä-

die gemeinsamen strukturellen und f u n k t i o n a l e n

Eigenschaften von Briefen.

O h n e die Existenz dieser Klasse wäre es

möglich, in d e m Postsystem Briefe zu speichern u n d zu bearbeiten. stellt Klassen

als quadratische Icons dar, die zur Unterscheidung

wöhnlichen O b j e k t e n mit einem kräftigen R a n d versehen sind. sche Symbol

im

Icon wird

von einer Klasse auf

unZOO

von

ge-

Das graphi-

alle k o n k r e t e n

Objekte

So erhalten die Briefe L - 2 3 , L - 2 4

ü b e r t r a g e n , die der Klasse angehören.

u n d L - 2 5 dasselbe graphische Symbol wie die Klasse l e t t e r , der sie angehören. Die gemeinsamen f u n k t i o n a l e n Eigenschaften einer Klasse von O b j e k t e n werden mit Hilfe von Methoden

dargestellt.

M e t h o d e n sind O b j e k t e , die Ope-

rationen repräsentieren, die auf eine ganze Klasse von O b j e k t e n werden k ö n n e n .

angewandt

In unserem Beispiel sind Versenden, Löschen u n d Editieren

( s e n d , d e l e t e u n d e d i t ) Methoden, die der Klasse Brief ( l e t t e r ) net sind. knüpft. Slots jekten oder

zugeord-

M e t h o d e n sind über die Relation m e t h o d s mit ihrer Klasse verM e t h o d e n erscheinen im System ZOO als pfeilförmige Icons.

sind O b j e k t e , die die strukturellen Eigenschaften einer Klasse von Obbeschreiben. Attributen.

Jeder

Slot

Slots werden

repräsentiert im

System

eine Klasse ZOO als

dick

von

Relationen

ausgezeichnete

Rechtecke dargestellt, die den N a m e n eines A t t r i b u t e s oder einer umschließen. den.

Slots sind über die Relation s l o t s

In der A b b i l d u n g 4 e r k e n n t m a n die Slots t e x t

d a f ü r sorgen,

daß jeder Brief die gleichnamigen

Die Slots r e c e i v e r ,

sender

und d a t e

Relation

mit ihrer Klasse v e r b u n und s u b j e c t ,

Attribute

erhalten

die

kann.

definieren mögliche Relationen,

in

Daß das konzeptuelle Wissen im Gegensatz zum Faktenwissen bereits in graphischer Aufbereitung vorliegt, ist keine Zauberei. Da sich das konzeptuelle Wissen bei der normalen Benutzung des Anwendungssystems nicht verändert, zeigt es sich in derselben Darstellung wie zum Zeitpunkt seiner letzten Bearbeitung mit dem System ZOO. Zum Faktenwissensnetz hingegen kommen bei jeder Benutzung des Postsystems neue Objekte hinzu, die noch nicht mit dem Wissenseditor visualisiert wurden.

194

Systeme zur P r o g r a m m i e r u n t e r s t ü t z u n g An der type-Beziehung

denen O b j e k t e zu Briefen stehen können.

dieser

Slots zu den Klassen person bzw. date erkennt man, daß diese Slots keine einfachen

Attribute,

sondern

Relationen

zu anderen

Objekten

definieren,

wobei nur bestimmte Arten von O b j e k t e n zugelassen sind, nämlich Personen bzw. Kalenderdaten. Obwohl konzeptuelles Wissen a b s t r a k t e r e r N a t u r ist als Faktenwissen,

läßt

es sich mit den gleichen Mitteln, nämlich Objektnetzen, darstellen.

Deshalb

ist es möglich,

wir

das

Postsystem

wesentlich

umzugestalten,

indem

das

konzeptuelle Wissen, das ihm zugrundeliegt, mit Hilfe direkter Manipulation verändern.

U m dies zu demonstrieren,

werden wir im folgenden

mittels

graphischer Methoden ein neues Konzept definieren und auf diese Weise die F u n k t i o n a l i t ä t des Postsystems erweitern.

3. M o d i f i k a t i o n v o n K o n z e p t e n des A n w e n d u n g s systems Wir wollen in unserem Postsystem die Möglichkeit vorsehen, Briefe in (elektronischen) Ordnern definieren,

und

aufzubewahren.

zwar

im

wesentlichen

Deshalb die

müssen

wir neue

Objektklasse

Konzepte

folder,

die

das

Konzept eines Ordners repräsentiert, sowie den Slot i n - f o l d e r , der die Relation zwischen einem Brief und seinem Ordner beschreibt. Ein Ordner h a t Ähnlichkeiten

mit einem Postfach:

Er h a t einen

der aus einer Menge von Briefen besteht, und es sind ähnliche mit einem Ordner möglich wie mit einem Postfach.

Inhalt,

Operationen

Deshalb wollen wir ei-

nen Ordner als eine Spezialisierung des Konzepts P o s t f a c h definieren: heißt, die Klasse f o l d e r soll eine Subklasse der Klasse mailbox sein.

Das Dazu

besuchen wir die Klasse m a l l b o x und rufen über das Symbol MAKE und ein Menü, das d a r a u f h i n erscheint, die F u n k t i o n MakeSubclass auf. stehende Klasse hat zunächst noch keinen Namen. men f o l d e r .

Die ent-

Wir geben ihr den Na-

Die Klasse f o l d e r besitzt zunächst noch dasselbe graphische

Symbol wie ihre Superklasse.

Mit Hilfe der F u n k t i o n ICON können wir der

Klasse ein anderes Symbol zuordnen.

Das Ergebnis all dieser Aktionen ist

im oberen Teil der Abbildung 5 zu sehen.

Die Relation superc zeigt die

Superklassenbeziehung zwischen den Klassen m a l l b o x und f o l d e r . Bei diesen Aktionen operiert das System ZOO wie auch sonst „ a m Objekt".

setzungs- oder Generiervorgang sofort verfügbar. der

lebenden

Das neu definierte Konzept eines Ordners ist ohne weiteren Uber-

definiert ist, k a n n

N a c h d e m die Klasse

über das Funktionssymbol MAKE und eine

fol-

weitere

Zoo

195

mail *** visiting class folder

BErHODS-"^; » DELETE ) < S >•> EDIT )

LEITER IXI

/

I PEtEKE 't HI

^H

-rvpE-type-"

SENDEE SUBJECT I

9

nniL-iN dtüü^

K

Abbildung 5.

Die Wissensbasis nach Definition des Klasse f o l d e r und des Objekts p r i v a t e .

Menüselektion ein Exemplar dieser Klasse erzeugt werden. neuerzeugten

Ordner den Namen

private.

Wir geben dem

Sein Icon hat ohne

weiteres

Zutun das graphische Symbol der Klasse f o l d e r erhalten; es wird so die Klassenzugehörigkeit des Objekts bildlich dargestellt (Abbildung 5 unten). Um einen Brief einem Ordner zuordnen zu können, müssen wir eine entsprechende Relation vorsehen. Wir kopieren einen beliebigen Slot, geben ihm den Namen i n - f o l d e r und verbinden ihn über die Relation s l o t s mit der Klasse l e t t e r . Durch die Relation t y p e verbinden wir den Slot mit der Klasse f o l d e r . Ab diesem Moment ist für jeden Brief die Relation i n - f o l d e r definiert, die eine Beziehung zu dem Ordner herstellt, der den Brief enthält. Die i n - f o l d e r - B e z i e h u n g ist die Inversrelation zur c o n t e n t s - B e z i e h u n g , die für jedes Postfach und speziell für jeden Ordner

196 definiert ist.

Systeme zur Programmierunterstützung Diese Inversbeziehung der beiden Relationen deklarieren wir

durch Erzeugen eines weiteren Slots mit dem Namen C o n t e n t s , der als invers zu i n - f o l d e r gekennzeichnet ist (Abbildung 6 oben).

m a i l * * * visiting letter 1-25

OELEfS EDIT ) \ RECEV I ER H rVPE-I E INDER ~1—rypE^ —SLOTS^'—-—>1 TEXT I '^"-•'-'Z'~I suehei:r "1 1 DfT ìE ~ 1 rVPE^-TVPE N

SL0rs

1 IN-FOLOERH CONTENTA K INVERSE

a

step to.. . in-folder

text subject sender receiver date

o H

^-S .ENDER -RECEIVER—

?0HN —>

-.RECEIVERS SENDER— OftTE--^.

m Abbildung 6.

Die Wissensbasis nach Definition der Relation i n - f o l d e r .

Wenn wir den Brief L-25 besuchen und mit Hilfe der Funktion STEP das Menü der Relationen abrufen, die von dem Brief ausgehen, so erscheint jetzt auch der Name der Relation l n - f o l d e r . Wir können nun unseren Brief L-25 im Ordner private ablegen, indem wir im Bildschirmfenster die entsprechende Verbindung ziehen. Da der Slot l n - f o l d e r als invers zum Slot contents von f o l d e r definiert wurde, ist das System zur Bildung einer Inferenz fähig: Automatisch wurde vom System die Relation contents zwischen dem Ordner private und dem Brief L-25 hergestellt. Das Ergebnis ist in der Abbildung 7 zu betrachten.

Zoo

Abbildung 7.

197

Die Relation Contents zwischen dem Ordner p r i v a t e dem Brief L-25 wird automatisch inferiert.

und

Wissensnetze haben also eine Syntax. Es können nur solche Relationen zwischen Objekten hergestellt werden, die durch entsprechende Slotobjekte definiert sind. Die Syntax des Faktenwissensnetzes ist durch das übergeordnete konzeptuelle Wissensnetz gegeben. Durch Modifikation des konzeptuellen Wissensnetzes läßt sich die Syntax des Faktenwissensnetzes unmittelbar verändern. Der dazu erforderliche Editiervorgang ist von der Interaktionsform her derselbe wie bei der Bearbeitung des Faktenwissensnetzes. Die Manipulation des konzeptuellen Wissens hat somit die Wirkung einer Datendefinition in herkömmlichen Datenbankmodellen. Da das konzeptuelle Wissen in unserem System in gleicher Art wie das Faktenwissen (in herkömmlicher Sicht: die Daten) dargestellt ist, besteht im System ZOO kein wesentlicher Unterschied zwischen der Datenmanipulation und der Datendefinition. Datenmanipulationssprache und Datendefinitionssprache sind identisch. Das konzeptuelle Modell, das die Struktur der Daten definiert, ist selbst Teil der Datenbasis (sprich: Wissensbasis). Unsere Beispielsitzung am System ZOO zeigte, daß es möglich ist, sowohl die Fakten als auch die Konzepte des Postsystems zu bearbeiten und dadurch Inhalt, Struktur und Funktion des Systems zu verändern. Insbesondere die Änderungen im konzeptuellen Bereich wären bei einem nicht wissensbasierten System nur durch Programmänderungen möglich gewesen. Was noch fehlt, ist die Anpassung der Benutzerschnittstelle des Systems. Wenn die Relationen und Attribute eines Briefes in unserem Postsystem beispielsweise durch Formularfelder dargestellt sind, muß jetzt ein weiteres Formularfeld definiert werden, in das der Name eines Ordners eingetragen werden kann. Die Liste aller vorhandenen Ordner sowie die in einem Ordner enthaltenen Briefe könnten jeweils durch ein Menü dargestellt werden.

198

Systeme zur Programmierunterstützung

Diese Anpassungsarbeiten können mit Hilfe eines Benutzerschnittstellen-Baukastens (vgl.

[Fischer, Lemke, R a t h k e 87]) oder wiederum mit Hilfe des

Systems ZOO vorgenommen werden.

4. D i e I n t e r a k t i o n m i t d e m S y s t e m ZOO Die Interaktion mit dem Wissenseditor erfolgt in den meisten Fällen durch Zeigehandlungen, muß.

wobei

nur

der

linke Knopf

der

Maus betätigt

werden

Dies macht den Umgang mit dem System sehr einfach.

Dabei er-

folgt die Interaktion mit dem System nach der Noun-Verb-Syntax:

Es muß

zuerst ein Objekt bezeichnet („besucht") werden und dann erst die Operation, die auf das Objekt angewandt werden soll.

Dies hat den Vorteil, daß

die Interaktion weitgehend ohne besondere Systemmodi

[Tesler 81] erfolgt.

Nach der Selektion eines Objektes gerät man nicht in einen besonderen Systemzustand, der die Angabe einer Operation zwingend erfordert; auf eine irrtümliche Selektion eines Objektes kann jederzeit eine weitere folgen.

Selektion

Umgekehrt kann nach dem Auslösen einer Anwenderfunktion sofort

eine zweite betätigt werden, wenn sie sich auf das bereits selektierte O b j e k t bezieht. Die angebotenen Natur.

Funktionen

des Wissenseditors sind alle von

elementarer

Komplexe Operationen, die die Spezifikation einer Vielzahl von Pa-

rametern erfordern und dadurch den Benutzer in eine systemgesteuerte Dialogsequenz zwingen, sind nicht vorgesehen.

Stattdessen legt das System bei

der Ausführung der Kommandos Voreinstellungen zugrunde und konfrontiert den Benutzer sofort mit dem ermittelten Ergebnis.

Wenn der Benutzer mit

dem Ergebnis nicht gleich zufrieden ist, kann er es durch Auslösen weiterer Funktionen korrigieren.

Dadurch ist die Interaktion für den Benutzer

beliebiger Stelle unterbrechbar.

an

Die Interaktion mit dem System ist den-

noch nicht umständlich, da die angebotenen Defaults dem Benutzer häufig ausreichen.

Nur in seltenen Fällen entsteht ein Mehraufwand, der sich aber

meistens auf einen

zusätzlichen

Mehraufwand wird

aber dadurch

Mausklick mehr

beschränkt.

als ausgeglichen,

steuerung unter der Kontrolle des Benutzers bleibt.

Dieser

potentielle

daß die

Dialog-

Zoo

199

5. Zusammenfassung Objektnetze als Formalismus der Wissensrepräsentation ermöglichen die einfache Konstruktion von Wissenseditoren, mit denen F a k t e n und Konzepte eines Anwendungssystems visualisiert und vom Benutzer modifiziert werden können. Modifikationen des Anwendungssystems erfolgen durch direkte Manipulation von Graphiken. F ü r die Anpassung von Software-Systemen an neue Anforderungen und individuelle Arbeitsstile sind keine besonderen Programmierkenntnisse erforderlich. Der graphische Wissenseditor ZOO erlaubt die direkte Manipulation von Wissensbasen und operiert „ a m lebenden O b j e k t " . Es wird keine Textrepräsentation editiert, sondern die aktiven Wissensbasisobjekte eines Anwendungssystems in geladenem Zustand. Dadurch kann die Interaktion mit dem System wissensgesteuert erfolgen: Das bereits im System repräsentierte Wissen wird genutzt, um die Vorgänge der Visualisierung und Modellierung von Wissensstrukturen zu unterstützen. Das Untersuchen von Wissensbasen wird erleichtert durch Hilfen, die sich aus den vorhandenen Wissensstrukturen ableiten, so etwa durch automatisch erzeugte Menüs zur Navigation und defaultmäßig vorgegebene Icons für die darzustellenden Objekte. Der Vorgang der Modellierung von neuem Wissen geschieht ebenfalls wissensgestützt: Vom System wird die Konstruktion von genau den Objekten und Relationen angeboten, die sich im aktuellen Kontext aus den im System repräsentierten Konzepten ableiten lassen. Der objektorientierte wissensbasierte Ansatz, verbunden mit fortgeschrittenen Techniken der Mensch-Computer-Kommunikation ermöglicht so die Konstruktion besser durchschaubarer und in weiten Teilen vom Benutzer gestaltbarer Anwendungssysteme und gewährt dem am Computer arbeitenden Menschen dadurch einen größeren Handlungsspielraum als in herkömmlichen Lösungen.

XII

OBJBASE

Ein S y s t e m zur S t r u k t u r i e r u n g und Verwaltung von Wissen Dorothea Bauer

Integrierte wissensbasierte Systeme sind eine Vorstellung der Zukunft. In ihnen sollen sämtliche Komponenten wissensbasiert programmiert sein, d.h. das enthaltene Wissen soll mit Hilfe von Wissensrepräsentationssprachen dargestellt werden. Das vom Benutzer verwendete Fakten- und Regelwissen wird mit den gleichen Mitteln repräsentiert wie die von ihm verwendete Benutzerschnittstelle, wie die Entwicklungswerkzeuge, mit denen Benutzerschnittstellen und Anwendungssysteme erstellt werden, wie die Konzepte der Wissensrepräsentationssprache selbst. Dadurch kann das gesamte im System enthaltene Wissen auf uniforme Weise vom Benutzer bzw. Programmierer verändert und so an die eigenen Bedürfnisse angepaßt werden. Eine Anstrengung in Richtung auf ein integriertes wissensbasiertes System stellt die Softwareumgebung der Forschungsgruppe INFORM dar. Im Laufe mehrerer Projekte wurden wissensbasierte Benutzerschnittstellen und wissensbasierte Anwendungsysteme mit Hilfe der objektorientierten Wissensrepräsentationssprache O b j T a l k [Rathke C. 86a] entwickelt. Mittlerweile umfaßt die Softwareumgebung mehr als tausend Objekte und an die hundert Wissensbasen. Zur Verwaltung von ObjTalk-Wissensbasen und der darin enthaltenen Objekte wurde das Wissensbanksystem OBJBASE entwickelt. Es koordiniert den Zugriff auf Wissensbasen und unterstützt das Verändern von Wissensbasen. Damit erleichtert es die Fehlerkorrektur sowie die Adaption von Wissensbasen an neue Anforderungen ebenso wie die Individualisierung von Wissensbasen entsprechend spezieller Benutzerwünsche. In diesem Beitrag wird dargestellt, wie ein Benutzer beim Einbringen von neuem Wissen in ein objektorientiertes System unterstützt werden kann, indem Veränderungen unter Einsatz von Heuristiken auf geeignete Wissensbasen verteilt und abgespeichert werden.

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter & C o . • Berlin • New York

Systeme zur Programmierunterstützung

202

1. Einleitung Objektorientierte Sprachen fördern das modulare Programmieren, indem sie erlauben, Information in F o r m von wiederverwendbaren Bausteinen - den Objekten - zu repräsentieren. Objekte sind Datenstrukturen in denen Informationen gespeichert werden können. In diesem deklarativen Charakter entsprechen sie den Datensätzen einer Datenbasis. Darüber hinaus können sie jedoch auch prozedurales Wissen enthalten. Die Aufgabe von Objekten ist es also nicht nur, Informationen zu speichern und damit a b r u f b a r zu machen, sondern mit ihrer Hilfe können auch „Berechnungen" durchgeführt werden. Wissensbasen fassen einzelne ihrer Funktion nach zusammengehörende Objekte zu einer Einheit zusammen. Die in einer Wissensbasis enthaltenen Objekte modellieren ein gemeinsames Anwendungsgebiet. Bei Datenbanken legt das Datenbankschema die S t r u k t u r der in den einzelnen Datenbasen enthaltenen Datensätze fest. Die Objekte einer Wissensbasis haben demgegenüber keine einheitliche S t r u k t u r . Es existiert kein Schema, das abhängig vom Typ eines Objektes festlegt, welcher Wissensbasis es zuzuordnen ist, sondern der Ersteller des Objekts entscheidet dies entsprechend der beabsichtigten Funktion des Objekts. Wissensbasen sind ebenso wie Objekte wiederverwendbare Bausteine.

Wie

Klassen zu Subklassen verfeinert werden können, um ein spezielleres Verhalten

zu

erzielen,

können

auch

gesamte

Wissensbasen

verfeinert

werden.

Durch das Verändern oder Hinzufügen von Objekten können sie neuen Bedürfnissen angepaßt werden.

O f t wird jedoch nicht eine einzelne Wissens-

basis verändert, sondern der Benutzer manipuliert die in einem System geladenen Objekte, ohne zu beachten, von welcher Wissensbasis sie s t a m m e n . Die veränderten Objekte müssen dann am Ende der Sitzung auf einer geeigneten Wissensbasis abgespeichert werden.

Manchmal ist es auch

nötig,

die Änderungen auf mehrere Wissensbasen zu verteilen. Wissensbasen werden nicht nur verwendet, um die in ihnen enthaltene Information abzurufen, sondern sie werden auch zum Ausführen von Aktionen eingesetzt, wobei ebenso wie bei der Manipulation durch den Benutzer Objekte verändert werden. Es entstehen dabei auch Änderungen, die nicht abgespeichert werden müssen, sondern „vergessen" werden können. Dann müssen beim Abspeichern von Änderungen diejenigen selektiert werden, die später wiederverwendet werden sollen.

203

OBJBASE

2. Eine Beispielsitzung mit O B J B A S E Ein W e r k z e u g zur direkten Manipulation von O b j e k t e n stellt der Wissenseditor ZOO dar.

Im Kapitel XI w u r d e a n h a n d der Wissensbasis M a i l

ge-

zeigt, wie mit seiner U n t e r s t ü t z u n g O b j e k t e erzeugt, v e r ä n d e r t und gelöscht werden k ö n n e n . wird.

E s w u r d e e r l ä u t e r t wie „ a m

lebenden

Objekt"

operiert

A m E n d e der Sitzung liegt eine Vielzahl v e r ä n d e r t e r O b j e k t e vor,

die abgespeichert werden müssen, sollen sie in der nächsten Sitzung wieder zur V e r f ü g u n g stehen.

Diesen Zweck erfüllt zwar auch ein Hauptspeicher-

abzug, er speichert jedoch nicht nur die v e r ä n d e r t e n Objekte, sondern alle O b j e k t e a b u n d dies in einer f ü r den Menschen unlesbaren F o r m .

OBJ-

BASE hingegen bietet die Möglichkeit, nur die V e r ä n d e r u n g e n , die an einer einzelnen Wissensbasis vorgenommen wurden, abzuspeichern. Im folgenden wird gezeigt, wie der Benutzer wie bei herkömmlichen

Syste-

men selbst die O b j e k t e angibt, die er abspeichern möchte.

OBJBASE Uber-

nimmt

durchzuführen.

hierbei zunächst

nur die Aufgabe, das Abspeichern

A n h a n d dieses Beispiels wird veranschaulicht, welche P r o b l e m e dabei a u f t r e ten k ö n n e n .

Nachfolgend wird eine Wissenserwerbskomponente

vorgestellt,

die diese P r o b l e m e in Kooperation mit d e m Benutzer löst.

2.1 D a r s t e l l u n g v o n

Wissensbasen

A b b i l d u n g 1 zeigt die Benutzerschnittstelle von OBJBASE. Fenster

mit

d e m Titel KB:Mail

gibt den

Zustand

Das abgebildete

der Wissensbasis

Mail

wieder, n a c h d e m der Benutzer d o r t die O b j e k t e notiert hat, die er abspeichern m ö c h t e .

Ein solches Wissensbasisfenster setzt sich aus einer

von U n t e r f e n s t e r n z u s a m m e n :

die Beziehung der Wissensbasis zu anderen Wissensbasen an.

Die Wissens-

basis M a l l b a u t auf die Wissensbasis Zoo auf, d.h. die in M a i l O b j e k t e setzen

die Existenz

der

O b j e k t e aus Zoo voraus.

enthaltenen

Des

weiteren

setzt sich die Wissensbasis M a i l aus den Teilwissensbasen M a l l O b J e c t s M a i l P i c t u r e s zusammen.

Reihe

Die Fenster P a r t s u n d Required KBs geben

und

Die in ihnen e n t h a l t e n e n O b j e k t e gehören d a m i t

auch z u m Inhalt von M a l l .

Zusammen mit den im Fenster contents ent-

haltenen lokalen O b j e k t e n bilden sie den aktuellen Inhalt der Wissensbasis. Die

drei

nebeneinander

liegenden

Fenster

contents,

modified-objects

deleted-objects stellen den Vergleich der Wissensbasis, wie sie zuletzt speichert Fenster

wurde, contents

mit

dem

enthält

aktuellen die

Zustand

Objekte,

die

der

lokal

Wissensbasis in M a i l

und abge-

dar.

Das

enthalten

sind.

S y s t e m e zur

204

Programmierunterstützung

KB-Properties of Mail

OBJECT iUPEP'JI SION

v e r s i o n = (9 . Fri Feb 26 10:21:09 1988) owner = d o r l e status = private v a l i d i t y = global

A b b i l d u n g 1.

Aus

dem

OFF

Die B e n u t z e r s c h n i t t s t e l l e v o n OBJBASE.

Fenster

m o d i f i e d - o b j e c t s ist

Abspeichern vorgemerkt wurden.

zu e n t n e h m e n ,

welche

Objekte

zum

I m Beispiel w u r d e n alle O b j e k t e a u s Con-

t e n t s n e u z u m I n h a l t v o n Mail h i n z u g e f ü g t , sie e r s c h e i n e n d e s h a l b a u c h modified-objects. enthalten. den

Zusätzlich

Obwohl

veränderten

es a u c h

Objekten.

ist in m o d i f i e d - o b j e c t s n o c h unter Dies

deleted-objects zeigt

an,

daß

notiert das

ist,

Objekt

zählt

es

und

nicht

ist).

D a s F e n s t e r I n f o s d i e n t zur A u s g a b e v o n S y s t e m m e l d u n g e n . Fehler-

zu

abgespeichert

w e r d e n m u ß , falls es w i e d e r z u m I n h a l t h i n z u g e f ü g t w i r d ( d a es n o c h in d e r W i s s e n s b a s i s e n t h a l t e n

in

anna

das O b j e k t

Informationsmeldungen

daß Ob-

wie d e r dar.

werden.

Parts und Required KBs enthaltenen

Wissensbasisname

Durch

Anklicken weitere

in

der

Titelzeile

stellen

Wissensbasen

maussensitive

eines s o l c h e n

Bereichs e r s c h e i n t

das Formular

der

Wissensbasis

das

Man

aus ihm entnehmen,

ausgewählten

zu w e l c h e m

Zeitpunkt

die g e r a d e

so-

Bereiche

Eigenschaften

Properties, kann

z.B.

werden

eine b e s t i m m t e W i s s e n s b a s i s n i c h t g e s c h r i e b e n w e r d e n d a r f o d e r w e l c h e

Die in d e n F e n s t e r n

so

In i h m

die Meldung,

jekte gerade abgespeichert

ausgegeben,

KBzeigt.

geladene

205

OBJBASE

Version der Wissensbasis abgespeichert wurde und wer der Ersteller der Wissensbasis ist. Ebenso wird angegeben, ob es sich um eine private, öffentliche oder fremde Wissensbasis handelt und ob die Veränderungen, die an der Wissensbasis vorgenommen werden, auf einer separaten Wissensbasis oder auf der ursprünglichen Wissensbasis festgehalten werden sollen.

2.2 B e n u t z e r g e s t e u e r t e s V e r ä n d e r n v o n

Wissensbasen

Will der Benutzer neues Wissen zur Wissensbasis Mail hinzufügen, so muß er sie aktivieren. Hierfür wählt er im KB-menu den Eintrag activate aus (siehe Abbildung 1). Die weiteren Einträge des KB-menu erlauben das Abspeichern der Änderungen, das Deaktivieren der Wissensbasis sowie das Abschließen der Bearbeitung. Ist eine Wissensbasis aktiv, so kann der Benutzer ihren Inhalt sowie ihre Eigenschaften und Beziehungen zu anderen Wissensbasen modifizieren, indem er die beschriebenen Fenster und Formulare editiert. Die Eigenschaften

einer Wissensbasis können verändert werden, indem die

entsprechenden Einträge des Formulars KB-Properties editiert werden. ziehungen

zu anderen

Wissensbasen

Be-

werden mit Hilfe der Plus- und Minus-

Buttons an den Fenstern P a r t s und Required KBs manipuliert.

Möchte der

Benutzer eine neue Wissensbasis einfügen, so klickt er auf den Plus-Button. Darauf erscheint im Fenstertitel die Eingabeanforderung ,,add p a r t : " bzw. „add required K B : " und er kann den Namen der hinzuzufügenden Wissensbasis eingeben.

Zum Löschen einer Beziehung klickt der Benutzer entspre-

chend

Minus-Button;

auf

den

die Wissensbasis,

auf

die er

anschließend

zeigt, wird dann entfernt. Wie der Inhalt einer Wissensbasis verändert werden kann, soll im gezeigt werden. Wie kann zum Beispiel der Benutzer, der mit Wissenseditors ZOO neue Objekte erstellt und bestehende Objekte hat, erreichen, daß die Wissensbasis Mail um die neuen Objekte wird und die Änderungen abgespeichert werden?

folgenden Hilfe des verändert erweitert

In der Beispielsitzung wurden die Klasse f o l d e r , deren Instanz p r i v a t e sowie die Slots C o n t e n t s und i n - f o l d e r neu definiert.

Die dabei erzeugten

Objekte sollen zum Inhalt von Mail hinzugefügt werden. Objekte im Fenster Contents notiert werden.

Dazu müssen die

Dieses Fenster stellt ebenso

wie die Fenster modified-objects und deleted-objects eine editierbare Liste dar.

Solche Listenformulare

können ähnlich wie die Fenster Parts und Re-

quired KBs über die Buttons am linken Fensterrand

manipuliert

werden,

206

Systeme zur Programmierunterstützung

außerdem können ihre Einträge direkt editiert werden. Um z.B. das Objekt f o l d e r zur Wissensbasis hinzuzufügen, muß der Benutzer den PlusButton des Fensters contents drücken und anschließend „ f o l d e r " eingeben. Das Listenformular modified-objects zeigt an, welche der in der Wissensbasis enthaltenen O b j e k t e abgespeichert werden sollen. schon

in der Wissensbasis enthalten

Da das O b j e k t

letter

ist, notiert der Benutzer es nur

in

modified-objects. Soll ein O b j e k t aus der Wissensbasis entfernt werden, so muß es in deletedobjects eingetragen werden.

Dort werden auch Objekte wie das

Objekt

anna notiert, das zwar zuerst zur Wissensbasis hinzugefügt worden war, anschließend jedoch wieder gelöscht wurde. Das Wissensbasisfenster, in dem ein Benutzer seine mit dem Wissenseditor ZOO gemachten Änderungen notiert hat, ist in Abbildung 1 zu sehen. Dabei ist zu erkennen, daß in modified-objects nicht nur das vom Benutzer dort eingetragene Objekt l e t t e r enthalten ist, sondern auch alle Objekte, die zu contents hinzugefügt wurden. Da die neu zum Inhalt der Wissensbasis hinzugefügten Objekte natürlich auch abgespeichert werden müssen, müssen sie auch in modified-objects stehen. Wird ein Objekt in deletedobjects eingetragen, so darf es anschließend natürlich nicht mehr in contents verzeichnet sein. Durch die Abhängigkeiten, die zwischen den drei Listenformularen bestehen, können die vom Benutzer vorgenommenen Änderungen weitere Änderungen erfordern. Diese zusätzlichen Einträge oder Löschungen muß der Benutzer jedoch nicht selbst vornehmen, da OBJBASE auftretende Inkonsistenzen selbständig korrigiert. Wird zur Liste contents ein neues Objekt hinzugefügt, so erscheint dies auch in der Liste modified-objects. Ebenso werden die zur Liste modified-objects hinzugefügten Objekte auch zur Liste contents hinzugenommen, wenn sie darin noch nicht enthalten sind. Objekte, die zur Liste deleted-objects hinzugefügt werden, werden als Folge davon aus contents entfernt. Die Liste deleted-objects zeigt einerseits an, welche Objekte beim Abspeichern der Wissensbasis aus der Wissensbasis gelöscht werden sollen, andererseits bietet sie eine Undo-Möglichkeit 1 . Nehmen wir als Beispiel das O b j e k t anna. Der Benutzer hat es neu erzeugt und fügt es deshalb zur Liste contents hinzu. Dadurch wird es auch in modified-objects eingetragen. Dann

^ Das T h e m a Undo wird ausführlich in Kapitel VIII behandelt.

207

OBJBASE

beschließt er, daß a n n a doch nicht zur Wissensbasis gehören soll und trägt das Objekt in der Liste deleted-objects ein, wodurch es aus contents entfernt wird. W ü r d e a n n a wieder zum Inhalt der Wissensbasis hinzugerügt werden, so müßte das O b j e k t abgespeichert werden. Um diese Information nicht zu verlieren, wird es - obwohl a n n a nun nicht mehr zum Inhalt der Wissensbasis gehört - nicht aus modified-objects entfernt. Will der Benutzer die Löschaktion rückgängig machen, so genügt es daher, das Objekt aus deleted-objects zu entfernen. Dadurch wird es wieder zu contents hinzugefügt: der Benutzer kann sich also das Eingeben des O b j e k t n a m e n s sparen. Ändert der Benutzer ein Objekt, so muß er das nicht sofort in der betroffenen Wissensbasis notieren. Er kann das auch nach Abschluß einer Editiersequenz oder am Ende der Sitzung tun. Hat der Benutzer die Bearbeitung der Wissensbasis abgeschlossen, so kann er die veränderten O b j e k t e der Wissensbasis und die Beschreibung der Wissensbasiseigenschaften und -beziehungen abspeichern. Zum Abspeichern des Wissensbasisinhalts wird die Schnittmenge aus contents und modified-objects bestimmt, die darin enthaltenen Objekte werden dann abgespeichert. Der Benutzer muß jedoch die gemachten Änderungen nicht abspeichern. Er kann durch Menüauswahl festlegen, ob er alles, nur die Beschreibung der Wissensbasis oder gar nichts abspeichern möchte.

2.3 D i e W i s s e n s e r w e r b s k o m p o n e n t e v o n OBJBASE Beim Manipulieren von Wissensbasen kann es leicht geschehen, daß der Benutzer gemachte Änderungen übersieht und abzuspeichern vergißt. Würde der Benutzer die im Beispiel erzeugte Wissensbasis M a i l zu einem späteren Zeitpunkt laden wollen, so würde er, sobald die Objekte p r i v a t e und 1 - 2 5 geladen werden, eine Fehlermeldung erhalten, die besagt, die Slotbelegungen der Slots c o n t e n t s und i n - f o l d e r seien entgegen der Definition nicht invers zueinander (siehe Abbildung 2). Der Benutzer h a t t e übersehen, daß beim Eintragen des Briefes 1 - 2 5 in den c o n t e n t s - S l o t des Objekts p r i v a t e durch diese Inversbeziehung auch 1 - 2 5 verändert wurde und hatte nur p r i v a t e zum Abspeichern vorgemerkt. Außerdem würde auf dem Bildschirm nur das Ausgangsobjektnetz nen:

erschei-

Die in der letzten Sitzung gemachten Änderungen würden nicht dar-

gestellt.

Woran liegt das?

Dem Benutzer war nicht klar, daß beim inter-

aktiven Erzeugen von Objekten mit Z0O nicht nur die Objekte selbst, sondern auch Darstellungsobjekte, die die eigentlichen O b j e k t e auf dem Bildschirm repräsentieren, erzeugt werden.

Der Benutzer hatte deshalb keines

208

Systeme zur Programmierunterstützung

i

-?L0r :.->r C OHTEHFS

B1 Abbildung 2.

I IH-FOLDETn-^-SLOrs-

CED

TT? ED

Die Beziehungen zwischen p r i v a t e und 1 - 2 5 .

der Darstellungsobjekte in der Wissensbasis notiert, so daß diese auch nicht abgespeichert wurden. Solche Fehler entstehen, wenn der Benutzer die Auswirkungen der von ihm vorgenommenen Änderungen nicht überblickt. Um Fehler dieser Art zu vermeiden, k a n n der Benutzer sich beim Eintragen von Änderungen von der Wissenserwerbskomponente von OBJBASE unterstützen lassen. W ä h r e n d der Benutzer Änderungen vornimmt, protokolliert die Wissenserwerbskomponente in der gerade aktiven Wissensbasis, welche Objekte neu erzeugt, welche verändert und welche gelöscht werden. Der Benutzer kann somit zu jedem Zeitpunkt nachsehen, welche Änderungen abgespeichert werden müssen. So wird dem Benutzer auch die Arbeit erspart, am Ende einer Sitzung feststellen zu müssen, welche Änderungen vorgenommen wurden. Da prinzipiell jede vom Benutzer vorgenommene Änderung weitere Änderungen auslösen kann, stellt dies schon bei einfachen Objektnetzen eine relativ komplexe Aufgabe dar (siehe Anzahl der zusätzlich durch die Wissenserwerbskomponente notierten Objekte in Abbildung 4 verglichen mit Abbildung 1). Will sich der Benutzer beim Manipulieren der Wissensbasis von der Wissenserwerbskomponente unterstützen lassen, so muß er die Wissenserwerbskomponente aktivieren. Hierzu klickt er auf den Object-Supervision-Button, der in Abbildung 1 zu sehen ist. Die Inschrift wechselt daraufhin zu ,,Object Supervision O n " . Sie zeigt an, daß nun die Veränderungen der aktiven Wissensbasis protokolliert werden. Dadurch, daß der Benutzer die Wissensbasis M a i l aktiviert hat, zeigt er der Wissenserwerbskomponente an, daß er diese Wissensbasis manipulieren möchte. Die Wissenserwerbskomponente achtet nun darauf, welche der in M a i l enthaltenen Objekte verändert oder gelöscht werden und welche Objekte neu erzeugt werden, und notiert die Änderungen im zuständigen Formular der Wissensbasis.

209

OBJBASE

Aktion im Wissenseditor

Aktion der Wissenserwerbskomponente

Navigation zu thomas

o b j e c t - p i c t u r e - t h o m a s —• contents

Erzeugen von anna

anna —• contents o b ] e c t - p l c t u r e - a n n a —• contents anna deleted-objects o b ] e c t - p l c t u r e - a n n a —• deleted-objects

Löschen von anna

Erzeugen von p r i v a t e Erzeugen von i n - f o l d e r

p r i v a t e —• contents o b j e c t - p l c t u r e - p r l v a t e —• contents i n - f o l d e r —• contents s l o t - p l c t u r e - i n - f o l d e r —• contents l e t t e r —• modified-objects

Ändern von p r i v a t e 2

1 - 2 5 —• m o d i f i e d - o b j e c t s

Abbildung 3.

Reaktionen der Wissenserwerbskomponente auf Aktionen des Wissenseditors.

Abbildung 3 zeigt einen Ausschnitt der mit dem Wissenseditor vorgenommenen Änderungen sowie die Änderungen der Wissensbasis Mail, die die Wissenserwerbskomponente als Reaktion darauf vornimmt: • Bei der Navigation zum Objekt thomas wurde das Objekt, das vorher noch nicht auf dem Bildschirm dargestellt war, sichtbar. Dazu hat ZOO das Objekt o b ] e c t - p i c t u r e - t h o m a s erzeugt. Die Wissenserwerbskomponente hat dies bemerkt und o b j e c t - p i c t u r e - t h o m a s zum Inhalt der Wissensbasis hinzugefügt. • Ebenso wurde das Erzeugen und Löschen des Objekts anna und seines zugehörigen Darstellungsobjekts o b j e c t - p l c t u r e - a n n a festgestellt und in Contents bzw. deleted-objects notiert. • Beim Erzeugen und Einfügen des Slots l n - f o l d e r wurde auch das Objekt l e t t e r verändert. Da es schon in der Wissensbasis Mail enthalten ist, wird es in modified-objects notiert. • Als im Objekt p r i v a t e der Slot c o n t e n t s mit 1 - 2 5 belegt wurde, wurde durch die definierte [nvers-Beziehung auch der Slot l n - f o l d e r des Objekts 1 - 2 5 verändert. 1 - 2 5 wird deshalb in modified-objects notiert ( p r i v a t e braucht dort nicht mehr notiert werden, da es schon bei seiner Erzeugung notiert worden war).

2

contents = 1-25

210

Systeme zur Programmierunterstützung

Da Inkonsistenzen, die infolge der durch die Wissenserwerbskomponente vorgenommenen Einträgen zwischen den Formularen contents, modified-objects und deleted-objects auftreten können, korrigiert werden, wird bei jedem Eintrag der Inhalt der anderen Formulare entsprechend angepaßt. Das Endergebnis der durch die Wissenserwerbskomponente veränderten Wissensbasis ist in Abbildung 4 zu sehen.

contents : moclif l e d - o b j e c t s : deleted-objects: Jl-25 lobj ect-pictu r e-anna 1-25 • letter • letter •anna !slot-picture-in-folder !slot-picture-in-folder lin-folder lin-folder Is l o t - p i c t u r e - c o n t e n t s Is 1ot-p ictu r e-cont ent s ¡contents ¡contents l o b j e c t - p i c t u r e - p r i v a t e lobj ect-p ictu r e-pr i vat e •private •private Iclass-picture-folder Iclass-picture-folder •folder Ifolder lobject-picture-thomas [object-picture-anna •anna lobject-picture-thomas Abbildung 4.

Ergebnis der Wissenserwerbskomponente.

Die Existenz des Objekts object-picture-anna ist mit der Existenz des Objekts anna verknüpft; deshalb wurde es, als anna im Wissenseditor gelöscht wurde, ebenfalls unter deleted-objects eingetragen. Will der Benutzer lediglich das Abspeichern dieser Objekte verhindern, so genügt es, diese aus dem Inhalt der Wissensbasis zu entfernen. Er muß sie nicht zusätzlich noch im Wissenseditor löschen. Weiß der Benutzer schon beim Erzeugen des Objekts anna, daß er es nicht abspeichern möchte, so hat er folgende einfache Möglichkeit.

Er kann die

Protokollführung der Wissenserwerbskomponente durch Klicken auf den Object-Supervision-Button kurzzeitig ausschalten.

Die Änderungen, die er an-

schließend d u r c h f ü h r t , werden dann nicht zum Abspeichern vorgemerkt. Eine weitere Unterstützungsfunktion der Wissenserwerbskomponente demonstriert das Fenster Infos (siehe Abbildung 5). Beim Erzeugen des Objekts anna hatte der Benutzer übersehen, daß dieses Objekt auch in der Wissensbasis Persons enthalten ist und dort schon zum Abspeichern vorgemerkt wurde. Beim Erzeugen eines neuen Objekts anna würde das bestehende Objekt überdefiniert. In der Wissensbasis Persons würde dann ein O b j e k t abgespeichert, das in dieser Form hierfür nicht vorgesehen war.

211

OBJBASE

Infos

Changing which is already modified on KB:Persons! Save it before? Yes Saving on KB:Persons

Abbildung 5.

Warnung bei folgenschweren Aktionen.

Die Wissenserwerbskomponente stellt bei solchen folgenschweren Aktionen vor deren Ausführung fest, ob das betroffene Objekt für irgendeine Wissensbasis zum Abspeichern vorgemerk ist. Ist das der Fall, warnt sie den Benutzer und gibt ihm die Möglichkeit, vor Ausführung der Aktion das betroffene Objekt abzuspeichern.

2.4 A u f t e i l e n v o n Ä n d e r u n g e n auf m e h r e r e

Wissensbasen

In den bisher gezeigten Beispielen wurde das neue Wissen in der Wissensbasis Mall abgespeichert. Die abgespeicherten Objekte lassen sich, wie an ihren Namen (siehe Abbildung 4) zu erkennen ist, in zwei Kategorien, die Mail-Objekte und die Darstellungsobjekte, einteilen. Die in der Ausgangswissensbasis enthaltenen Objekte waren diesen Kategorien entsprechend auf die zwei Wissensbasen MallObjects und MailPictures aufgeteilt 3 . Will der Benutzer die Änderungen, die er an der Wissensbasis Mall vorzunehmen wünscht, nicht lokal abspeichern, sondern auf deren Teilwissensbasen aufteilen, so muß er die Teilwissensbasen parallel verändern. Bisher war nur eine Wissensbasis, die Wissensbasis Mall, aktiv. Jetzt sollen ihre Teilwissensbasen zum Bearbeiten geöffnet werden. Es ist dabei nicht nötig, die Teilwissensbasen sequentiell zu bearbeiten, d.h. die Bearbeitung von MailOb] ects muß nicht abgeschlossen werden, bevor die Wissensbasis MailPictures zum Bearbeiten geöffnet werden kann. Es ist möglich, beide Wissensbasen zum Bearbeiten geöffnet zu haben und, je nachdem an welcher gerade Änderungen vorgenommen werden sollen, mal die eine, mal die andere zu aktivieren und die Änderungen nach Abschluß der Bearbeitung abzuspeichern. Sollen die durchgeführten Änderungen durch die Wissenserwerbskomponente protokolliert werden, so müssen die beiden Teilwissensbasen wirklich gleichzeitig verändert werden können, d.h. sie müssen auch gleichzeitig aktiv sein.

•j

Die Wissensbasis Mall hatte nur die Aufgabe, diese Wissensbasen zusammenzufassen; sie enthielt selbst keine lokalen Objekte.

212

Systeme zur P r o g r a m m i e r u n t e r s t ü t z u n g

Der Bearbeitungszustand, in d e m sich eine Wissensbasis befindet, k a n n d e m Wissensbasismanager F o r m u l a r dar.

entnommen

werden.

Auch

er stellt

ein

editierbares

Der Benutzer aktiviert die Wissensbasen MailObJ ects u n d

MailPictures, indem er sie in die Formularzeile „active-KBs" des Wissensbasismanagers einträgt.

Auf diese Weise beendet er auch die B e a r b e i t u n g

der Wissensbasis Mail.

Abbildung 6 zeigt den d a d u r c h erreichten

Zustand

des Wissensbasismanagers.

KB-Manager protocoI = ON active-KB = (MailObjects MailPictures) open-KBs = (MailObjects MailPictures Persons) closed-KBs = (Mail) loaded-KBs « (MailObjects MailPictures Mail ...) path = (/users/dorle/base/KBs . /users/dorle/base/code

Abbildung 6.

...)

Der Wissensbasismanager.

Wenn die d u r c h g e f ü h r t e n Änderungen d u r c h die

Wissenserwerbskomponente

protokolliert werden sollen, besteht das Problem, daß nicht m e h r nur eine Wissensbasis aktiv ist, der sämtliche Ä n d e r u n g e n zugeordnet werden.

Nun

sind zwei Wissensbasen aktiv, so daß f ü r jede einzelne Ä n d e r u n g

entschie-

den werden

Benutzer

muß, welcher Wissensbasis sie zuzuordnen

ist.

Der

möchte Darstellungsobjekte auf der Wissensbasis MailPictures notiert

ha-

ben, alle anderen Ä n d e r u n g e n sollen auf der Wissensbasis MailObjects notiert werden. Bei Wissensbasen besteht hinsichtlich der O b j e k t e , die sie a u f n e h m e n nen keine E i n s c h r ä n k u n g , außer bei sog. Instanzenwissensbasen: ausschließlich Instanzen

a u f n e h m e n , deren Klasse in einer

den Klassenwissensbasis enthalten ist. res.

rende Klassenwissensbasis spezifiziert .

Sie k ö n n e n

korrespondieren-

Ein Beispiel hierfür ist MailPictu-

Der Ersteller dieser Wissensbasis hat ZooPictures als 4

korrespondie-

D a d u r c h h a t er erreicht, d a ß Mail-

Pictures nur Darstellungsobjekte a u f n e h m e n k a n n , also Instanzen ZooPictures e n t h a l t e n e n Klassen.

4

kön-

Vgl. Titelzeile der Wissensbasis M a i l P i c t u r e s in Abbildung 8.

der

in

213

OBJBASE

Aktion im Wissenseditor

Aktion der Wissenserwerbskomponente MailObjects

Navigation zu thomas

Erzeugen von anna Löschen von anna

Erzeugen von p r i v a t e Erzeugen von i n - f o l d e r

Ändern von p r i v a t e 5

Abbildung 7.

MailPictures ob]ect-plcture-thomas —• contents

anna - * contents anna deleted-objects

ob]ect-picture-anna —• contents ob]ect-picture-anna —• deleted-objects

private —• contents in-folder —• contents letter > modified-objects

ob]ect-picture-private - * contents slot-picture-in-folder —• contents

1-25 —• modified-objects

Aufteilen der Änderungen res und MailOb]ects.

auf die Wissensbasen

MallPictu-

Abbildung 7 zeigt, wie die Wissenserwerbskomponente aufgrund der Spezifikation von ZooPictures als korrespondierende Klassenwissensbasis zu Pictures

Mail-

die mit dem Wissenseditor verursachten Änderungen aufteilt:

• Die neu erzeugten O b j e k t e ob] ect-plcture-thomas, ob] e c t - p i c t u r e - a n n a usw. werden der Wissensbasis MailPictures zugeordnet, weil M a l l P i c t u r e s als Instanzenwissensbasis von ZooPictures spezifiziert wurde. • Die restlichen neu erzeugten O b j e k t e anna, private, in-folder werden in der Wissensbasis M a i l O b j e c t s notiert.

etc.

• Die Änderungen an den O b j e k t e n letter und 1 - 2 5 werden in M a i l Ob] ects notiert, da sie zu deren Inhalt gehören. • Die Löschung des O b j e k t s a n n a und des zugehörigen Darstellungsobj e k t s ob] e c t - p i c t u r e - a n n a wird jeweils in der Wissensbasis festgehalten, zu der das O b j e k t gehört.

5

contents = 1-25

214

Systeme zur Programmierunterstützung

Die Zuordnung von Änderungen basiert auf Regeln, die in den meisten Fällen das vom Benutzer gewünschte Ergebnis liefern. Hat der Benutzer jedoch Absichten, die von den behandelten Standardfällen abweichen, so können sie zu unerwünschten Zuordnungen führen. Die durch die Wissenserwerbskomponente veränderten Wissensbasen sind in Abbildung 8 zu sehen. Der Benutzer wird sie sich am Ende der Sitzung betrachten und überprüfen, ob die von ihm gewünschten Objekte, keines mehr und keines weniger, bei der richtigen Wissensbasis zum Abspeichern vorgemerkt wurden. Sollte er mit dem Ergebnis nicht zufrieden sein, kann er die Wissensbasis jederzeit wie in Abschnitt 2.2 beschrieben seinen Wünschen entsprechend verändern, bevor er sie abspeichert.

H3

Active KB:Mail Pictures Instances of ZooPictures Required KBs

^o^im^Uu^^uT^^der slot-picture-contents object-picture-private c1ass-picture-folder object-picture-thomas object-picture-michael object-picture-John object-picture-mai1-in object-picture-1-25 object-picture-1-24 object-picture-1-23 object-p i ctur e-12jan87 slot-picture-text s1ot-picture-subject slot-picture-sender slot-picture-receiver slot-picture-date slot-picture-contents method-picture-send method-picture-edit met hod-p i ctur e-d e1et e class-picture-mailbox class-picture-letter c lass-picture-person class-picture-date

I mod if i ed-obj ects : jdeleted-objects: s lot-picture-in-toIder aobject-picture-anna slot-picture-contents object-picture-pr ivate class-picture-folder object-pi cture-anna object-picture-thomas Active KB:Ma1lobjects Required KBs

contents:

Iin-folder •contents !pr ivate •folder |jljan87 Il2jan87 |5jan87 Ithomas Ijohn

m

Imodified-objectsfdeleted-objects:

I I -2S •letter !in-folder |contents Ipr ivate Ifolder lanna

11-23

ll-24 11 -25 WWW

Abbildung 8.

Die Wissensbasen MailObjects und MailPlctures am Ende des Wissenserwerbsvorgangs.

215

OBJBASE

3. W i s s e n s b a s e n und W i s s e n s e r w e r b Im vorhergehenden

Abschnitt w u r d e erläutert, wie sich Wissensbasen

Benutzer darstellen und wie er mit ihnen interagieren k a n n .

dem

Im folgenden

soll auf die zugrundeliegenden K o n z e p t e der Wissensverwaltung u n d die Methodik des Wissenserwerbs eingegangen werden.

3.1 D a s K o n z e p t

Wissensbasis

Das grundlegende Konzept von OBJBASE ist die Wissensbasis.

U n t e r einer

Wissensbasis versteht man eine Menge von O b j e k t e n , die gemeinsam verwaltet werden.

Das bedeutet, daß diese O b j e k t e an einer gemeinsamen

Stelle

abgespeichert

sind, einen gemeinsamen Besitzer haben

Frage

und daß die

der Zugriffsberechtigung f ü r diese O b j e k t e gemeinsam geregelt wird. Wissensbasen

bauen

auf sog. Grundlagenwissensbasen

Fenster Requiered KBs dargestellt).

auf

(sie werden

im

Die Grundlagenwissensbasen einer Wis-

sensbasis definieren die F u n k t i o n a l i t ä t des Systems, auf das die Wissensbasis aufsetzt.

Sie e n t h a l t e n Objekte, die von den O b j e k t e n der Wissensbasis an-

gesprochen werden, die aber nicht in der Wissensbasis selbst definiert sind. Sind zum L a d e z e i t p u n k t einer Wissensbasis die O b j e k t e ihrer

Grundlagen-

wissensbasen nicht vorhanden, so werden diese zuerst geladen.

W e r d e n bei-

spielsweise die Superklassen einer Klasse nicht in derselben Wissensbasis definiert wie die Klasse selbst, so gehören die Wissensbasen, in denen sie definiert werden,

zu den Grundlagenwissensbasen

der Wissensbasis.

Die Wis-

sensbasis Zoo stellt z.B. die nötige G r u n d f u n k t i o n a l i t ä t zur V e r f ü g u n g ,

um

die in Mail enthaltenen O b j e k t e zu definieren. Wissensbasen können aus Teilwissensbasen

bestehen (sie werden im F e n s t e r

P a r t s dargestellt).

Die Menge der in einer Wissensbasis e n t h a l t e n e n

te, d.h. ihr Inhalt,

setzt sich aus den lokal in der Wissensbasis e n t h a l t e n e n

O b j e k t e n und den in den Teilwissensbasen e n t h a l t e n e n O b j e k t e n (siehe A b b i l d u n g

9).

Die O b j e k t e , die in den Teilwissensbasen

sind, werden von diesen „ e r e r b t " ; die ererbten

O b j e k t e können

Objek-

zusammen enthalten wiederum

von Teilwissensbasen ererbt sein. Das

Konzept

der

Grundlagen-

und

Teilwissensbasen

bungsmöglichkeit für die Abhängigkeiten gung.

Dadurch

stellt

zwischen Wissensbasen

kann das Gesamtwissen eines Systems in

Wissensgebiete oder Anwendungsbereiche

eine

unterteilt

werden.

Beschreizur V e r f ü -

unterschiedliche So bildet

die

216

Systeme zur

Programmierunterstützung

Mail

Die Wissensbasis Mail m i t ihren Teilwissensbasen len O b j e k t e n .

Abbildung 9.

und

loka-

Wissensbasis Zoo, die ihrerseits aus m e h r e r e n Teilwissensbasen b e s t e h t , n i c h t n u r die G r u n d l a g e der Wissensbasis Mail, s o n d e r n

a u c h die a n d e r e r

Wis-

sensbasen (z.B. Computers), die ebenso in Teilwissensbasen a u f g e t e i l t sind.

ZooPictures

Abbildung 10.

OBJBASE

Die I n s t a n z e n w i s s e n s b a s e n MailPlctures der Klassenwissensbasis ZooPictures.

unterscheidet

wissensbasen.

des

weiteren

Instanzenwissensbasen

Klassenwissensbasen Jede

MailPictures

sowohl

Instanzenwissensbasis

Instanzen hat

eine

Klassenwissensbasen enthalten als auch

nur Klassen

korrespondierende

enthält

Instanzen

und

Instanzen-

Instanzen, enthalten

während können.

Klassenwissensbasis.

Eine Instanzenwissensbasis e n t h ä l t

nur Instanzen der Klassen, die in

Klassenwissensbasis d e f i n i e r t sind.

Ein Beispiel h i e r f ü r stellt die

wissensbasis

MailPlctures

dar,

die n u r

ZooPictures e n t h ä l t (siehe A b b i l d u n g 10).

Instanzen

der

dieser

Instanzen-

Klassenwissensbasis

217

OBJBASE In Instanzenwissensbasen henden Konzepten,

Pictures

getrennt

die in der korrespondierenden

halten sind, repräsentiert. sen aus anderen

wird Faktenwissen

von den

dahinterste-

Klassenwissensbasis

D a d u r c h können K o n z e p t e auch auf

Anwendungsbereichen

angewendet

werden.

Da

die allgemeinen Konzepte zur Darstellung von O b j e k t e n

von den F a k t e n der Wissensbasis M a i l P i c t u r e s

ent-

Faktenwisin

Zoo-

separat

repräsentiert werden,

kön-

nen mit d e m System ZOO auch andere Wissensbasen visualisiert werden.

3.2 B e a r b e i t u n g s z u s t ä n d e v o n

Wissensbasen

Die Bearbeitung einer Wissensbasis heißt, den Inhalt, die Eigenschaften oder die Beziehungen zu anderen Wissensbasen zu v e r ä n d e r n .

Veränderungen

am

Inhalt können durch den Benutzer oder durch die Wissenserwerbskomponente von OBJBASE d u r c h g e f ü h r t werden.

Die in einem laufenden System gela-

denen Wissensbasen können sich in unterschiedlichen befinden:

Eine Wissensbasis kann aktiv,

geöffnet,

Bearbeitungszuständen

geschlossen

oder

geladen

sein. • Eine Wissensbasis, die sich in Bearbeitung befindet, wird als aktiv bezeichnet. N u r an aktiven Wissensbasen können Ä n d e r u n g e n vorgen o m m e n werden. • Soll eine Wissensbasis zwischenzeitlich nicht mehr v e r ä n d e r t werden, so wird sie deaktiviert. D a n n zählt sie nur noch zu den offenen Wissensbasen. Offene Wissensbasen sind zwar zum Bearbeiten geöffnet, werden jedoch m o m e n t a n nicht bearbeitet. Sie können Modifikationen e n t h a l t e n , die z u m Abspeichern vorgemerkt sind. • Soll eine Wissensbasis nicht weiter bearbeitet werden, so wird sie geschlossen. Die vorgemerkten Ä n d e r u n g e n werden dabei abgespeichert. Der Benutzer k a n n jedoch auch auf das Abspeichern verzichten. Danach werden die Listen der zum Abspeichern und zum Löschen vorgem e r k t e n O b j e k t e zurückgesetzt. • Wissensbasen können auch nur geladen sein. Die in einer geladenen Wissensbasis e n t h a l t e n e n O b j e k t e befinden sich im laufenden System u n d können angesprochen werden. Der Benutzer k a n n stets nur eine Wissensbasis editieren.

Um

anzuzeigen,

welche Wissensbasis er im Moment verändern möchte, aktiviert er sie.

Sie

wird d a n n - sofern noch nicht geshehen - geladen und zum Bearbeiten geöffnet. die

Will der Benutzer eine andere Wissensbasis aktivieren, so k a n n er

Bearbeitung

der

gerade

aktiven

Wissensbasis

jederzeit

ohne die g e m a c h t e n Ä n d e r u n g e n abgespeichern zu müssen.

unterbrechen,

Die deaktivierte

218

Systeme zur Programmierunterstützung

Wissensbasis kann dann nicht mehr verändert werden und ist somit vor irrtümlichen Veränderungen geschützt. Durch erneutes Aktivieren der Wissensbasis kann die Bearbeitung zu einem späteren Zeitpunkt wieder aufgenommen werden. Abbildung 11 zeigt die möglichen Zustände.

bearbeiten

Abbildung 11.

Die möglichen Zustände von Wissensbasen.

Mit dem Schließen der Wissensbasis wird eine Bearbeitungphase beendet. Die Änderungen können dabei abgespeichert werden. Dadurch ensteht eine neue Version der Wissensbasis. Soll eine Wissensbasis auf ihren Ausgangszustand zurückgesetzt werden, so kann sie auch geschlossen werden, ohne Veränderungen abzuspeichern. Die Bearbeitung der Wissensbasis kann wieder aufgenommen und eine neue Bearbeitungsphase eröffnet werden, indem die Wissensbasis wieder geöffnet wird.

3.3 Der

Wissenserwerbsvorgang

Die Fähigkeit zu Lernen ist die Grundvoraussetzung für intelligentes Verhalten. Ein Teilaspekt ist der Erwerb von neuem Wissen. Wissenserwerb kann definiert werden als Lernen neuer symbolischer Information zusammen mit der Fähigkeit, diese Information auf effektive Weise anzuwenden [Michalski, Carbonell, Mitchell 83]. Maschinelle Wissenserwerbskomponenten unterscheiden sich hinsichtlich des Automatisierungsgrads des Wissenserwerbsvorgangs. Die Wissenserwerbskomponente von OBJBASE liegt in der Mitte dieses Spektrums, da sie sowohl das automatische als auch das manuelle Verändern von Wissensbasen erlaubt. Zusätzlich hat der Benutzer mehrere Möglichkeiten, den automatischen Wissenserwerb steuernd und kontrollierend zu beeinflussen. Der Wissenserwerb vollzieht sich in Kooperation zwischen Benutzer und Wissenserwerbskomponente. Die Wissenserwerbskomponente von OBJBASE ermöglicht es dem Benutzer, das in einem System enthaltene Gesamtwissen an beliebigen Stellen zu verändern, ohne darauf achten zu müssen, zu welcher Wissensbasis die veränderten Objekte gehören. Die Wissenserwerbskomponente hat die Aufgabe,

219

OBJBASE

die vom Benutzer an den Objekten vorgenommenen Änderungen festzustellen und zu beurteilen, ob es sich dabei um Änderungen handelt, die abgespeichert werden sollten. Diese als relevant beurteilten Änderungen werden dann den geeigneten Wissensbasen zugeordnet, so daß sie auf Wunsch des Benutzers später abgespeichert werden können. Dieser Wissenserwerb vollzieht sich in vier Phasen: 1. Objektüberwachung 2. Relevanzbeurteilung 3. Objektzuordnung 4. Abspeichern der Wissensbasis

3.3.1 D i e

Objektüberwachung

Wie anhand des Beispieldialogs gezeigt wurde, ist es für den Benutzer ein großer Aufwand, alle im Laufe einer Sitzung vorgenommenen Veränderungen zu notieren, damit sie abgespeichert werden können, vor allem wenn es sich um eine große Objektmenge handelt. Dies um so mehr, als durch Änderungen, die der Benutzer an einem Objekt durchführt, oft indirekt andere Objekte verändert werden, ohne daß sich der Benutzer dessen bewußt ist. überwacht auf Wunsch des Benutzers das Erzeugen von neuen Objekten sowie das Löschen und Verändern von bestehenden O b j e k t e n 6 . Objekte können auf recht unterschiedliche Art und Weise manipuliert werden. Der Benutzer kann Objekte direkt manipulieren, indem er ihnen entsprechende Nachrichten schickt. Objekte können aber auch indirekt manipuliert werden, indem durch die Interaktionen über die Benutzerschnittstelle eines Systems derartige Nachrichten versandt werden oder indem Regeln, Trigger oder das Abarbeiten sonstiger Methoden das Versenden solcher Nachrichten auslösen. So wird z.B. beim Erzeugen eines Objektes mit ZOO nicht nur das Objekt selbst, sondern auch ein zugehöriges Darstellungsobjekt erzeugt. O B J B A S E stellt alle Manipulationen fest. Da dies indirekte Manipulationen einschließt, ist O B J B A S E darin dem Benutzer überlegen. OBJBASE

Um die Objektüberwachung durchzuführen, erweitert

OBJBASE

die elementa-

ren ObjTalk-Mechanismen, mit denen Objekte manipuliert werden, und notiert jeweils das von einer Manipulation betroffene Objekt.

Dieses O b j e k t

und

Ändern)

die darauf

ausgeführte Operation

(Erzeugen, Löschen,

dann der Relevanzbeurteilung zur Bewertung übergeben.

® Im folgenden einfach Manipulation

genannt.

wird

220

Systeme zur Programmierunterstützung

Ein Problem ergibt sich daraus, daß der Benutzer wissentlich oder unwissentlich Objekte zerstören kann, die eigentlich zum Abspeichern vorgemerkt sind. Oder daß er ein Objekt verändert, das in einer deaktivierten Wissensbasis zum Abspeichern vorgemerkt ist. Um den Benutzer bei solchen folgenschweren Aktionen warnen zu können, Uberwacht OBJBASE zusätzlich alle Objekte, die bei den offenen Wissensbasen zum Abspeichern vorgemerkt sind. Wird auf eines dieser Objekte eine verändernde oder zerstörende Operation ausgeführt, so erhält der Benutzer eine Mitteilung und k a n n vor Ausführung der Aktion das Objekt abspeichern.

3.3.2 D i e

Relevanzbeurteilung

Bei den von der Objektüberwachung festgestellten Änderungen handelt es sich nicht nur um solche, die der Benutzer abspeichern möchte. Änderungen werden auch zu Testzwecken vorgenommen oder entstehen bei der Interaktion mit den Werkzeugen der Programmierumgebung. Insgesamt kann man die vorkommenden Änderungen in vier Gruppen einteilen: • gewünschte Änderung an der aktiven Klassenwissensbasis • gewünschte Änderung einer aktiven Instanzenwissensbasis • Änderungen, die durch das Arbeiten grammierumgebung entstehen

mit den Werkzeugen

der

Pro-

• Änderungen zu Testzwecken oder sonstiges temporäres Wissen Das Ziel der Relevanzbeurteilung ist es, herauszufinden, welche der von der Objektüberwachung festgestellten Änderungen abgespeichert werden müssen, damit der Benutzer alle von ihm benötigten Objekte bei einem späteren Laden in der gewünschten Form wieder vorfindet.

Ihre Aufgabe ist es, die

Änderungen am laufenden System dahingehend zu beurteilen, ob sie fristig

länger-

interessant sind und ob sie zum Wissen gehören, das der Benutzer

einbringen möchte.

Die Manipulation eines Objekts sollte dann als relevant

betrachtet werden, wenn dadurch • ein Objekt entsprechend den Absichten des Benutzers verändert wird, • ein „falsches" Objekt gelöscht oder durch ein richtiges ersetzt wird, • ein neues Objekt hinzugefügt wird, das einen Teil des einzubringenden Wissens repräsentiert.

221

OBJBASE

Es zeigt sich, daß die Beurteilung der Relevanz stark von den des Benutzers abhängt.

Der Benutzer hat mehrere Möglichkeiten sie der

Wissenserwerbskomponente Wissensbasen

bestimmt

Absichten

er,

mitzuteilen:

Durch die Festlegung der

welche

er

Objektmengen

verändern

aktiven möchte.

Durch das Einschalten des Protokolls teilt der Benutzer mit, daß er nun Änderungen vorzunehmen wünscht, die abgespeichert werden sollen.

Möchte

er Änderungen nur zu Testzwecken vornehmen - die also längerfristig nicht interessant sind - so schaltet er das Protokoll aus. Die Relevanzbeurteilung geht von der Annahme aus, daß die vom Benutzer beabsichtigten Manipulationen die aktiven Wissensbasen

verändern.

Dazu

stellt sie fest, in welcher Beziehung die von der Objektüberwachung festgestellten Änderungen zu den aktiven hen.

Objekten

und den aktiven

Klassen

ste-

Aktive Objekte bzw. Klassen werden wie folgt bestimmt:

• Ein Objekt ist aktiv, wenn es in einer aktiven Wissensbasis enthalten ist. • Eine Klasse ist aktiv, o wenn sie in der Menge der aktiven Objekte enthalten ist oder o wenn sie in einer Wissensbasis enthalten ist, die korrespondierende Klassenwissensbasis einer aktiven Instanzenwissensbasis ist. Zur Durchführung der Relevanzbeurteilung wird derzeit auf Heuristiken zurückgegriffen, die vom zu modellierenden Wissen unabhängig sind 7 .

Sie er-

lauben deshalb nur eine annäherungsweise richtige Beurteilung der Relevanz. Bei eingeschaltetem Protokoll wird anhand folgender Heuristiken die Relevanz von Änderungen bestimmt: • Eine Änderung ist relevant, wenn sie ein in der Menge der aktiven Objekte enthaltenes Objekt verändert, ersetzt oder löscht. Im Beispieldialog: l e t t e r (verändern), anna (löschen). • Wird ein neues Objekt erzeugt, so ist dies relevant, wenn es eine Klasse oder Instanz einer aktiven Klasse ist. Im Beispieldialog: f o l d e r (Klasse), o b j e c t - p l c t u r e - t h o m a s und p r i v a t e (Instanzen der aktiven Klassen o b j e c t - p i c t u r e bzw. f o l d e r ) .

7

Der B e g r i f f H e u r i s t i k w i r d v e r w e n d e t , da es sich u m R e g e l n h a n d e l t , die z w a r in d e n m e i s t e n , j e d o c h n i c h t in allen F ä l l e n die R e l e v a n z e n t s p r e c h e n d d e n B e n u t z e r a b s i c h t e n beurteilen.

222

Systeme zur Programmierunterstützung

3.3.3 Die

Objektzuordnung

Wurde eine Änderung als relevant beurteilt, so muß das betroffene O b j e k t bei der zugehörigen Wissensbasis notiert werden, so daß die Änderung zum Abspeichern vorgemerkt wird. Dazu ist von jedem Objekt bekannt, zu welcher Wissensbasis es gehört. Bei neu erzeugten Objekten ist es zunächst unklar, in welcher Wissensbasis sie abgespeichert werden sollen. Sie werden anhand folgender Heuristiken zu Wissensbasen zugeordnet: • Klassen werden der aktiven Klassenwissensbasis zugeordnet. spieldialog:

Im Bei-

folder —• MailObjects.

• Instanzen aktiver Klassen werden der Instanzenwissensbasis zugeordnet, in deren korrespondierenden Klassenwissensbasis die Klasse enthalten ist.

I m B e i s p i e l d i a l o g : o b j e c t - p i c t u r e - p r i v a t e —• M a i l P i c t u r e s .

• Instanzen der in der aktiven Klassenwissensbasis enthaltenen Klassen werden der aktiven Klassenwissensbasis zugeordnet, sofern sie zu keiner Instanzenwissensbasis korrespondiert. Im Beispieldialog: private -• M a i l O b j e c t s .

3.3.4 A b s p e i c h e r n einer W i s s e n s b a s i s Soll eine Wissensbasis abgespeichert werden, die mit Hilfe der Wissenserwerbskomponente verändert wurde, so sollte der Benutzer zuvor die Menge der zum Abspeichern vorgesehenen Objekte auf ihre Vollständigkeit und Richtigkeit überprüfen. Das ist deshalb nötig, weil die bei der Relevanzbeurteilung und der Objektzuordnung eingesetzten Heuristiken nur annäherungsweise richtige Ergebnisse liefern können. Hat der Benutzer die nötigen Korrekturen vorgenommen, so kann er die Wissensbasis abspeichern. Es werden dann alle dort protokollierten Änderungen abgespeichert, wobei eine neue Version der Wissensbasis angelegt wird.

3.4 K o o p e r a t i o n z w i s c h e n und B e n u t z e r

Wissenserwerbskomponente

Die von der Wissenserwerbskomponente angelegten Änderungsnotizen sind als Vorschläge zu betrachten. Der Benutzer kann den erzeugten Vorschlag jederzeit kontrollieren und von Hand modifizieren, bis alle gewünschten Objekte zum Abspeichern vorgemerkt sind. Die Qualität der Vorschläge kann verbessert werden, wenn der Benutzer der Wissenserwerbskomponente seine Absichten mitteilt und dadurch den Wissenserwerbsvorgang steuert.

223

OBJBASE

3.4.1 S t e u e r u n g des W i s s e n s e r w e r b s Der Benutzer kann sowohl auf die Relevanzbeurteilung als auch auf die Objektzuordnung Einfluß nehmen. Folgende Mittel stehen ihm dabei zur Verfügung • Ein-/Ausschalten des Protokolls • Aktivieren/Deaktivieren von Wissensbasen • Hinzufügen/Löschen von Objekten bzw. Teilwissensbasen Durch Ein- bzw. Ausschalten des Protokolls kann der Benutzer die Relevanz von Aktionen bestimmen. Bei eingeschaltetem Protokoll werden beim Durchführen einer Aktion sämtliche durch sie bewirkte Manipulationen hinsichtlich ihrer Relevanz beurteilt und bei den geeigneten Wissensbasen protokolliert. Bei ausgeschaltetem Protokoll werden alle vorgenommenen ManiWenn pulationen als irrelevant eingestuft und deshalb nicht protokolliert. der Benutzer zum Durchführen von Tests Objekte manipulieren möchte, kann er das Protokoll ausschalten und so die von ihm bearbeiteten Wissensbasen vor ungewollten Veränderungen schützen. Er sollte das Protokoll auch abschalten, wenn er genau weiß, daß seine nächste Aktion nur Auswirkungen hat, die von kurzfristigem Interesse sind. Manche Programmierwerkzeuge erweitern alle im System vorhandenen Objekte derart, daß sie durch das Werkzeug bearbeitet werden können. Diese Änderungen sind jedoch nur von Bedeutung, solange das Werkzeug benutzt wird, und brauchen deshalb nicht abgespeichert zu werden. Durch Aktivieren

und

Deaktivieren

von Wissensbasen

kann der

Benutzer

die Menge der aktiven Objekte bestimmen, d.h. er legt fest, bei Objekten Veränderungen protokolliert werden sollen.

welchen

Er wird alle die Wis-

sensbasen aktivieren, von denen er annimmt, daß die darin enthaltenen Objekte zur Modellierung des neu einzubringenden Wissens verändert müssen. zungen

Als relevant eingestufte Veränderungen,

Löschungen

oder

werden Erset-

von Objekten werden der Wissensbasis zugeordnet, die das betroffe-

ne O b j e k t enthält. Durch Aktivieren bzw. Deaktivieren von Wissensbasen wird auch der Erwerb von neuen Objekten gesteuert. Indem der Benutzer die aktiven Klassen festlegt, bestimmt er, welche der neu erzeugten Instanzen als relevant eingestuft werden. Möchte der Benutzer Instanzen erzeugen, so kann er diese entweder der Klassenwissensbasis, in der die benötigten Klassen enthalten sind, zuordnen lassen oder einer separaten Instanzenwissensbasis.

Systeme zur Programmierunterstützung

224

Hierfür muß er entweder die Klassenwissensbasis oder die Instanzenwissensbasis aktivieren. Er erreicht dadurch, daß die Klassen, die er instantiieren möchte, aktiviert und somit die davon erzeugten Instanzen notiert werden. Will der Benutzer neu erzeugte Klassen notieren lassen, so muß er eine Klassenwissensbasis aktivieren, die die neuen Klassen aufnehmen soll. Mit der Festlegung der aktiven Klassenwissensbasis (es kann zu jedem Zeitpunkt nur eine Klassenwissensbasis aktiv sein) gibt er an, wie die Wissensbasis heißen soll, die die Konzepte des neu zu modellierenden Wissens a u f n e h m e n soll. Wechselt er das Wissensgebiet, muß er eine andere Klassenwissensbasis aktivieren. Durch Hinzu fügen oder Löschen von Objekten bzw. Teilwissensbasen bei einer aktiven Wissensbasis kann der Benutzer ebenfalls die Menge der aktiven Objekte verändern. Muß der Benutzer in Zusammenhang mit dem Erstellen einer Wissensbasis ein Objekt verändern, das in einer anderen Wissensbasis enthalten ist, so hat er zwei Möglichkeiten das Objekt abzulegen: Er kann das Objekt entweder der Wissensbasis zuordnen lassen, die es lokal enthält; dazu muß er diese kurzzeitig aktivieren. Dies ist z.B. bei einer Fehlerkorrektur sinnvoll, wenn das Objekt fortan nur noch in seiner veränderten Form verwendet werden soll. Oder er möchte, daß die Änderung auf der Wissensbasis abgespeichert wird, die er gerade erstellt; dann muß er das veränderte Objekt zu dieser Wissensbasis hinzufügen. Die Änderung des Objekts gilt dann nur in Zusammenhang mit dieser Wissensbasis. Will der Benutzer mehrere Objekte hinzufügen, die alle in derselben Wissensbasis enthalten sind, so muß er nicht jedes O b j e k t einzeln hinzufügen, sondern es genügt die Wissensbasis als Teilwissensbasis hinzuzunehmen. Alle Änderungen an den Objekten der Teilwissensbasis werden dann bei der übergeordneten Wissensbasis zum Abspeichern vorgemerkt. Durch Hinzu fügen

oder Löschen

von Klassen

bzw. Teilwissensbasen

zu ak-

tiven Wissensbasen kann der Benutzer die Menge der aktiven Klassen verändern und so den Erwerb von Instanzen beeinflußen.

Indem der Benutzer

neuen Klassen zu einer aktiven Klassenwissensbasis hinzufügt, erreicht

er,

daß auch die Instanzen der neu hinzugefügten Klassen in der aktiven Klassenwissensbasis notiert werden.

Durch das Hinzufügen von Klassen zu einer

Wissensbasis, die zu einer aktiven Instanzenwissensbasis korrespondiert, wird erreicht, daß auch die Instanzen der neu hinzugefügten Klassen in der aktiven Instanzenwissensbasis das Löschen.

notiert

werden.

Entsprechendes gilt jeweils für

225

OBJBASE

Mit diesen Mitteln zur Steuerung des Wissenserwerbs kann der Benutzer explizite Angaben zur Relevanz von Aktionen machen, die Menge der aktiven Objekte, d.h. die Menge der Objekte, deren Veränderung protokolliert werden soll, bestimmen und er kann die Relevanzbeurteilung von Instanzen beeinflussen.

3.4.2 K o n t r o l l e des

Wissenserwerbs

Die Ergebnisse des Wissenserwerbsvorgangs stellen Vorschläge dar, die die meisten der abzuspeichernden Objekte enthalten. Da die Relevanzbeurteilung und die Objektzuordnung auf dem Einsatz von Heuristiken beruhen, können in geringem Umfang Fehlnotierungen auftreten. Der Benutzer k a n n die Änderungsnotizen in den einzelnen Wissensbasen jederzeit kontolüeren und die geringfügigen Korrekturen durchführen. Ein Fehler bei der Relevanzbeurteilung bedeutet, daß die Veränderung zwar bemerkt, aber ihre Relevanz falsch beurteilt wurde. Hierbei sind zwei Fehlerarten zu unterscheiden: Einfach zu beheben sind Fehler, bei denen eine Änderung fälschlicherweise als relevant eingestuft wurde. Hierfür muß das Objekt nur aus dem Inhalt oder aus der Liste der modifizierten Objekte der Wissensbasis entfernt werden, zu der die Änderung zugeordnet wurde. Eine fälschlicherweise als irrelevant eingestufte Änderung ist dagegen nur zu beheben, wenn der Benutzer den Fehler bemerkt hat und von der Änderung Kenntnis hat. Um den Fehler zu beheben, muß er je nach Änderung das betroffene Objekt entweder in die Liste der zu löschenden oder in die Liste der abzuspeichernden Objekte eintragen. Wurde ein O b j e k t der falschen Wissensbasis zugeordnet, so muß es entfernt und der richtigen Wissensbasis zugeordnet werden.

4. Z u s a m m e n f a s s u n g und A u s b l i c k OBJBASE stellt ein System zur Verwaltung von Wissensbasen dar. Ein Aspekt der Verwaltung, das Einbringen von neuem Wissen in ein System, wurde in diesem Beitrag ausführlich dargestellt. Die dabei a u f t r e t e n d e n Probleme der Strukturierung des neu einzubringenden Wissens wurden erläutert und als Lösungsmöglichkeit der kooperative Wissenserwerb vorgestellt. Dabei können zwischen der alleinigen Veränderung von Wissensbasen durch den Benutzer und der vollautomtischen Manipulation durch eine Wissenserwerbskomponente verschiedene Stufen der Kooperation von Benutzer und System gewählt werden.

226

Systeme zur Programmierunterstützung

Diese Kooperation zwischen System und Benutzer ist unter anderem deshalb notwendig, weil die Wissenserwerbskomponente Heuristiken verwendet, u m neues Wissen den einzelnen Wissensbasen zuzuordnen, die noch einer starken Überwachung durch den Benutzer bedürfen. Die Überwachung ist nötig, weil die Heuristiken subjektive Kriterien der Zuordnung unberücksichtigt lassen. Ein erster Schritt zu einer Verbesserung wäre, dem Benutzer die Möglichkeit zu geben, subjektive Zuordnungskriterien zu formulieren, die von der Wissenserwerbskomponente von OBJBASE verwendet werden können.

Baukästen für Benutzerschnittstellen

Visival

XIII VISrVAL E i n B a u k a s t e n für Bildschirm-Instrumente Michael Herczeg

Die eine ben sind

Arbeit mit interaktiven Computersystemen ist gekennzeichnet durch dichte, alternierende Abfolge von Eingaben des Benutzers und Ausgades Systems. Die Protokolle, d.h. die Regeln, die diesen Dialog leiten, im Computerprogramm festgeschrieben.

Die Erstellung eines interaktiven Anwendungssystems auf einem Computer setzt sich somit aus wenigstens zwei Teilaufgaben zusammen: zum einen aus der Bereitstellung der eigentlichen Anwendungsfunktionalität und zum anderen aus deren Anbindung an die Ein-/Ausgabegeräte. Insbesondere die Programmierung der Ein-/Ausgabe, man spricht vom Bau der Benutzerschnittstelle, läßt sich durch die Bereitstellung anwendungsneutraler und damit wiederverwendbarer Bausteine deutlich vereinfachen. Durch die Verwendung leistungsfähiger und individualisierbarer Bausteine lassen sich Benutzerschnittstellen schneller, konsistenter und trotzdem problemangemessener erstellen. Am Beispiel des Baukastens VlSIVAL mit Bausteinen zur vorwiegend graphischen Ein- und Ausgabe numerischer Daten soll diese Vorgehensweise verdeutlicht werden.

1. E i n l e i t u n g Typische Anwendungen, in denen die graphische Ein- und Ausgabe numerischer Werte eine problemangemessene Interaktionsform ist, sind vor allem die Überwachung und Steuerung realer oder simulierter Prozesse. Die Medien zur Ausgabe numerischer Werte nennt man in tradionellen - nicht zwangsläufig computergestützten - Anwendungen Instrumente. Die Darstellungen solcher Instrumente auf dem Computerbildschirm werden im folgenden ebenfalls Instrumente genannt. Diese können allerdings gegenüber ihren mechanischen ,,Vorbildern" gleichzeitig zur Werteingabe und Wertausgabe benutzt werden.

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter Sc Co. • Berlin • N e w York

230

Baukästen für Benutzerschnittstellen

Als Anwendungsbeispiel dient ein Monitor zur Überwachung wichtiger Zustandsparameter des Betriebssystems UNIX auf einem Rechner des Typs VAX 11/780. Beim VAX/UNIX-Monitor handelt es sich u m ein reines Kontrollwerkzeug; die Eingabe von Werten wird daher nicht betrachtet werden. Dieses Beispiel ist repräsentativ für eine große Klasse von Anwendungen. Uberall dort, wo heute Menschen vor Instrumenten sitzen, um den Ablauf eines Prozesses zu kontrollieren, können sich in Zukunft Bildschirme mit Darstellungen von Instrumenten befinden, die genauer, flexibler, leichter modifizierbar, abnutzungsfrei und unzerstörbar die wichtigsten Kenndaten der Prozesse darstellen. Als Prototyp eines Baukastens zur Erstellung von Bildschirminstrumenten dient das System VlSIVAL1. Verwandte Arbeiten finden sich in den Systemen LOOPS [Stefik, Bobrow 86], KEE [KEE 85] und STEAMER [Hollan, Hutchins, Weitzmann 84].

2. Der

VAX/UNIX-Monitor

Am Beispiel der Bedienoberfläche einiger K o m m a n d o s des UNIX-Betriebssystems soll gezeigt werden, wie ein Baukasten zum Bau von Benutzerschnittstellen gestaltet werden kann.

2.1 Das P r o b l e m aus B e n u t z e r s i c h t Im UNIX-Betriebssystem gibt es eine Reihe von Dienstprogrammen, die einen Einblick in das Verhalten des Betriebssystems erlauben. Ein solcher Einblick ist notwendig, um das Betriebssystem möglichst gut an die ablaufenden Anwendungsprogramme anpassen zu können. Durch das Dienstprogramm v m s t a t [UNIX 83] läßt sich beispielsweise das Paging-, Ein-/Ausgabe- und Time-Sharing-Verhalten sowie die Auslastung des Rechners kontrollieren (Abbildung 1). Das Dienstprogramm ps zeigt die Verteilung der Rechnerressourcen auf die Benutzer (Abbildung 2). Die Zahlenkolonnen der beiden Programme enthalten die zur Kontrolle von UNIX notwendigen Daten. Die Tabellen werden auf dem Bildschirm ,,gescrollt", d.h. neue Tabellenzeilen schieben die vorausgehenden Darstellungen nach oben und lassen die Zeilen am oberen Bildschirmrand verschwinden.

' Das S y s t e m VIS[VAL w u r d e f i n d e t sich in [ S t e n g e r 8 6 ] .

von H.-D. S t e n g e r e r s t e l l t . Eine a u s f u h r l i c h e B e s c h r e i b u n g Viele Bilder dieses B e i t r a g s s t a m m e n a u s dieser A r b e i t .

231

VisrvAL

Das Herausfiltern und Interpretieren dieser Daten fällt selbst Systemspezialisten schwer.

Dies gilt insbesondere für das Abschätzen des zeitlichen sowie das Ergründen

Sy-

von Ursache und Wirkung.

Gründe

dafür sind die eigenwillige Codierung der Daten, die Einbettung

wichtiger

stemverhaltens

in unwichtige Daten, der Umfang der Daten und die aus diesen Bedingungen resultierende Uberforderung des visuellen Aufnahmevermögens

und

dächtnisses des Betrachters.

csh(167): vastat 2 20 procs menory r b w Avm fre re at 1 0 0 1428 752 3 0 1 0 0 1480 709 0 0 1 0 0 1480 709 0 0 0 0 0 1343 724 0 G 0 0 0 1343 724 0 0 0 0 0 1343 724 0 0 2 0 0 1368 730 0 0 2 0 0 1368 730 0 3 0 0 0 1321 706 0 1 0 0 0 1321 706 0 0 1 0 0 1423 716 4 0 1 0 0 1423 716 2 0 1 0 0 1423 716 5 0 1 1 0 1744 662 3 0 1 1 0 1744 662 1 0 1 0 0 2156 551 0 G 1 0 0 21S6 551 0 0 1 0 0 2156 551 0 0 1 0 a 2152 448 0 0 1 II n 215? 44A n n Abbildung 1.

Pf 1 1 0 G 0 0 0 3 2 2 3 5 9 a 20 30 26 18 12 7

po 1 0 0 0 0 0 0 0 0 0 0 0 G G 0 0 1S 13 8 5

fi

page disk faults de sr r0 ho hl X3 in sy a 2 2 1 1 0 172 37 0 0 G 0 3 0 231 215 0 0 0 0 0 G 502 155 0 0 0 a 0 G 351 105 0 0 2 0 0 0 264 77 0 0 0 i 0 0 212 55 0 G G 2 3 0 164 83 0 0 G 3 14 0 313 74 0 0 a 0 0 G 253 64 0 a 2 4 0 G 203 65 0 0 1 3 0 0 160 64 0 0 7 11 1 0 127 102 a 0 14 7 17 G 123 111 a 0 5 13 4 G 169 148 0 0 0 49 0 0 152 114 G 3 1 47 0 G 146 79 G 36 5 19 3 0 125 57 0 32 a 3 6 G 102 44 a 21 a 3 0 G 82 32 0 1? n n G n 66

es us 16 27 17 84 14 0 11 37 12 13 9 22 16 61 25 17 18 14 16 10 15 4 25 12 31 8 41 43 59 10 75 17 68 36 55 73 41 91 111 98

epu sy id 12 61 13 3 13 86 5 58 6 80 8 69 36 3 33 50 5 81 20 70 13 83 45 43 44 48 45 13 30 59 28 55 17 47 14 12 6 3 ? G

Das UNIX-Dienstprogramm v m s t a t .

csh(lSB) : ps -au PIO CPU iMEM sz USER michael 26060 44 . 4 2 0 170 michael 26061 36 8 1 .4 158 joachim 24139 23 .9 4 9 665 juergenh 25800 3 .0 50 9 5763 joachimn 25771 1 9 3 3 443 mart in 26048 0 .2 0 6 114 root 26047 0 1 0 3 57 juergenh 25913 0 .0 3 .7 427 nichael 26003 0 0 3..7 443 notes 24918 0 0 0 6 152 michael 25890 0 0 1 .2 169 joachim* 25752 0 0 5 .0 3809 joachim 24158 0 .0 4 . 1 L320 dor le 23665 0 0 0 0 25 dor le 24141 0 0 0 0 4462 martin 23091 0 0 0 0 1336 kalle 24241 0 .0 0 .0 5432 kalle 23886 0 0 0 .0 595 dor le 25742 0 0 0 0 169 martin 25082 0 0 0 0 101 dor 1 e 23666 0 0 0 . G 542 klaus 25728 0 0 0 . G 101 joachim 25562 0 0 0 G 122 root 25561 0 0 0 . 2 57 Abbildung 2.

fr 0 0 0 0 0 0 0 0 0 0 0 0 G 0 0 0 12 14 10

RSS 139 95 344 3623 227 37 15 256 256 34 77 325 284 0 0 52 0 31 28 9 31 9 9 8

TT STAT 01 R 01 R 10 R 05 S 15 I Pi I Pl I 05 T 01 T 04 I 01 T 15 T 10 T 22 TU 22 TU 20 TU 08 IU 08 TU 22 IU 20 IU 22 TU 11 IU pO IU 1)0 I

TIME COMMAND 0:: 04 bgx -2 vmstat.bgs 0 : 01 ps -au 5 : 11 emacs 4 : 03 elah 1:: 02 emacs test.1 0:: 03 -csh (csh) 0 : 00 /etc/telnetd 0 : 19 emacs ablauf.mss 0:: 06 emacs visival.mss 0:: 15 notes 1:: 08 scbg master 0 : 17 bicjwl isp 0 : 37 7 inform/cmd/post 0:: 26 emacs 2:: 45 snap 0 : 33 post 7 : 39 /inform/demos/help/demo 2 : 22 emacs 0 : 26 schg otello 0 : 00 /hin/csh /inform/cmd/toff 1 : 45 emacs 0 : 00 /bin/csh /inform/cmd/toff 0 : 10 -csh (csh) 0 : 00 /etc/telnetd

Das UNIX-Dienstprogramm ps.

Ge-

232

B a u k ä s t e n f ü r Benutzerschnittstellen

In Abbildung 3 sieht man eine Alternative, den VAX/UNDC-Monitor, der neben anderen die gleichen S y s t e m p a r a m e t e r wie vmstat und ps visualisiert. Die Daten werden durch I n s t r u m e n t e übersichtlich dargestellt, zeitliche Verläufe werden ,,auf einen Blick" sichtbar. chen

visuellen

Wahrnehmungsvermögens

Die hohe Leistung des menschliwird

dabei

ausgenutzt.

Relative

Größen können direkt e r k a n n t werden u n d müssen nicht rechnerisch beitet werden.

erar-

Dort, wo exakte W e r t e von Bedeutung sein können, werden

sie in den I n s t r u m e n t e n zusätzlich zur graphischen Darstellung digital angezeigt.

Die Anzeigen

in den

Instrumenten

verändern

sich dynamisch

V e r ä n d e r u n g der überwachten Größen.

VAX/UNix-Monitor

CPU

Switches

E5B

USER michael mi chae1 m i chae1 joachim k laus dieterm tiara Id dieterm liara Id d ieterh

CPU MEM COMMAND ill 29 monitor 1 PS 21 20 1 /bin/tcsh 11 3 emacs 3 emacs 3 1 2 emacs 0 1 /users/nor 0 12 comobj 0 2 emacs 0 IS bigwlisp

N.

\II

h/

r-\ 1

ME ¿

>h

Frt 13. Nov. 1987

• loa • so

Load Average

User System Idle :/.CPU

Device Interrupts

150 100 -

. load Average

A b b i l d u n g 3.

1/s

i L Reclaims

Der VAX/UNDC-Monitor.

Iklil.-.. Payes In

I-I.L Pages Out

bei

VISIVAL

233

2.2 G r u n d t y p e n v o n

Instrumenten

Im VAX/UNIX-Monitor werden verschiedenartige Instrumente eingesetzt. Sie können nach Darstellungsform, Anzahl der dargestellten Werte und der Sichtbarkeit der zeitlichen Werteentwicklung (Wertehistorie) unterschieden werden.

Darstellungsform Je nach notwendiger Genauigkeit oder Übersichtlichkeit der dargestellten Zahlenwerte lassen sich digitale und analoge Instrumente einsetzen. Digitale Instrumente stellen die Werte in Ziffernschreibweise mit beliebiger Genauigkeit dar; Analoginstrumente zeigen den Zahlenwert graphisch durch einen Zeiger auf einer Skala an. Zeiger und Skala können dabei reichhaltig variiert und damit an die Anwendung und den Benutzer angepaßt werden. Wenn nötig, können Digital- und Analoginstrumente zu einem kombinierten Instrument zusammengesetzt werden (Abbildung 4).

11 u s e r s

Abbildung 4.

Analoges, digitales und kombiniertes Instrument.

A n z a h l der d a r g e s t e l l t e n Innerhalb eines Instruments werden.

Werte

können

auch

mehrere

Zahlenwerte

dargestellt

Dies bietet sich zum Beispiel bei der Darstellung logisch

mengehöriger Werte oder bei Darstellung der zeitlichen Entwicklung

zusameines

Zahlenwerts an (Abbildung 5). Abbildung 5 zeigt links ein Instrument mit der Aufteilung der CPU-Leistung auf Anteile für die Benutzer, für das System und, als eventuell verbleibender Rest, die nicht ausgenutzte Leistung. Die Werte sind jeweils auf 100% bezogen und bilden damit relative Wertdarstellungen, die leicht überblickt werden können. Die Skala spielt hier nur eine untergeordnete Rolle.

234

Baukästen für Benutzerschnittstellen

150 — 100 —

1

SO —

0—

JH.... ILM.... Reclaias

1/s

Abbildung 5.

Ein Instrument Wertehistorien.

mit

Pages In

drei Zahlenwerten

und

iJaL Pages Out

eines mit

drei

Wertehistorien Rechts in Abbildung 5 sieht m a n die zeitliche Entwicklung des Pagingverhaltens der Maschine. Jeder neue Wert wird als schwarzer Balken rechts angehängt. Wird die darzustellende Anzahl der Zahlenwerte (hier zehn) überschritten, so wird der älteste Wert entfernt und die Darstellung nach links verschoben. Die Darstellung der Einzelwerte kann durch verschiedene Zeiger erfolgen; in diesem Beipiel wurden wertproportionale Flächen in F o r m von Balken gewählt.

Manipulierbarkeit visualisierter

Werte

Aus der Erfahrung kennt man vor allem Anzeigeinstrumente. Es k a n n jedoch auch sinnvoll sein, die angezeigten Werte vom Benutzer ändern zu lassen. Bei digitalen Instrumenten kann dies durch Eintippen des gewünschten Werts mittels T a s t a t u r , bei analogen Instrumenten durch Verstellen des Zeigers oder durch Deuten auf einen Zielwert der Skala erfolgen. Dies ist ein wichtiger Vorteil von Bildschirminstrumenten gegenüber mechanischen Instrumenten. Im VAX/UNIX-Monitor könnte man verschiedene Betriebssystemparameter zum Verstellen anbieten, z.B. die maximal zulässige Anzahl von Benutzern im System.

2.3 B e s t a n d t e i l e der

Instrumente

Instrumente lassen sich sowohl konzeptionell als auch nisch in verschiedene Bestandteile zergliedern.

implementierungstech-

In erster Linie sind dies An-

zeigen, Skalen, Beschriftungen, Alarme sowie Über- und Unterlaufanzeigen.

VISIVAL

235

Anzeigen Eine Anzeige ist die eigentliche Visualisierung eines Werts. In digitalen Instrumenten ist dies die dargestellte Zahl, in analogen Instrumenten der Zeiger. Digitale Anzeigen können durch verschiedene Zeichensätze (Fonts) in Größe und Schriftart variiert werden. Die Zahl kann u.a. als Festpunktzahl, Gleitpunktzahl oder Exponentialdarstellung ausgegeben werden. Sie kann zentriert, rechts- oder linksbündig positioniert werden. So lassen sich diese Instrumente an die von der Anwendung abhängigen Wertebereiche anpassen. Auch analoge Anzeigen können vielfältig variiert werden. Wertproportionale Flächen oder Zeiger visualieren den aktuellen Wert, meist in Bezug auf eine Skala. Typische Zeiger bewegen sich entweder kreisförmig oder linear horizontal oder linear vertikal (Abbildung 6). Die Zeigerform kann durch Rechtecke, Dreiecke, Kreise oder durch Kombinationen davon beschrieben werden.

hn.-sca.Le - bar -char t

mm

vnv - sq - bar - char t

100

•i

— so mm

wm

— 20 -0

Ixri- sc -pornter-chart

Abbildung 6.

-

— 40

60

— 40

Variation von Zeigern

SO — 60 mm

-

— 20 —0

vm - s q-pornttr -chart

Skalen in linearen Instrumenten.

236

Baukästen f ü r Benutzerschnittstellen

Skalen Analoge Anzeigen

sind

meist

mit

einer

oder

mehreren

Skalen

gekoppelt.

Nur so k a n n aus der Position eines Zeigers der Anzeigewert abgeleitet werden.

Entsprechend

angeordnet.

den I n s t r u m e n t e n

sind Skalen kreisförmig oder

linear

Sie e n t h a l t e n M a r k i e r u n g e n u n d Beschriftungen, an denen die

aktuellen W e r t e abgelesen werden können.

Die dargestellten

Wertebereiche

sind entweder linear gestaffelt oder über eine m a t h e m a t i s c h e F u n k t i o n (häufig L o g a r i t h m u s

oder

Quadrat)

verzerrt

(Abbildung 7).

Damit

kann

der

Wichtigkeit verschiedener Bereiche des dargestellten Wertebereichs R e c h n u n g Im I n s t r u m e n t Device Interrupts sowie in den beiden

getragen werden.

untersten I n s t r u m e n t e n (Load-Average u n d Paging) im V A X / U N E X - M o n i t o r werden nichtlineare Skalen verwendet (Abbildung 3).

Abbildung 7.

Verschiedene Skalen in horizontal linearen I n s t r u m e n t e n .

Beschriftungen Die B e d e u t u n g eines I n s t r u m e n t s bzw. seiner Anzeigen wird d u r c h tungen

gekennzeichnet,

die

durch

S c h r i f t a r t variiert werden k ö n n e n . Beschriftung innerhalb tung.

vielerlei

Zeichensätze

in

Beschrif-

Größe

und

Auch die Position oder A n o r d n u n g einer

des I n s t r u m e n t s

ist f ü r seine N u t z u n g

von

Bedeu-

F ü r die unterschiedlichen I n s t r u m e n t t y p e n gibt es jeweils s t a n d a r d i -

sierte günstige A n o r d n u n g e n f ü r Beschriftungen (Abbildung 8).

Alarme Inbesondere

bei

Prozeßüberwachungen

haben

dargestellte

Größen

meist

Grenzwerte, deren U n t e r - oder Überschreitung vermieden werden soll.

Tritt

eine solche Größe aus d e m zulässigen Bereich heraus, soll ein Alarm

erfol-

YlsrVAL

237 — 100

100 —

-

•

— 80

80 —

-

-

— 60

60 —

-

-

40 —

— 40

-

-

— 20

20 — -

0—

Abbildung 8.

—

Standardanordnungen struments.

—0

für Beschriftungen

eines

linearen

In-

gen, der aus einem akustischen bzw. einem optischen Signal bestehen kann. F ü r den Fall, daß der Beobachter bei Auftreten des Alarms das Instrument gerade nicht beobachtet, sollte eine deutlich sichtbare zusätzliche Markierung des Instruments vorgesehen werden, die erst durch Bestätigung der überwachenden Person beseitigt wird. Im VAX/ÜNDC-Monitor tritt ein solcher Alarm beispielsweise bei einem Load A v e r a g e von mehr als acht ein. In diesem Fall sollte der Operateur eingreifen und unwichtige Prozesse in der Priorität vermindern oder ganz anhalten. Bei einem Alarm kann zusätzlich eine beliebige Aktion im Anwendungssystem ausgelöst werden.

Instrumente können auf diese Weise nicht nur zur

Überwachung, sondern auch zur Prozeßsteuerung eingesetzt werden.

Es ist

d a n n auch zwischen dem Unterschreiten eines Minimalwerts und dem Überschreiten eines Maximalwerts zu unterscheiden, da dies im allgemeinen unterschiedlicher Reaktionen bedarf.

Uber- und

Unterlaufanzeigen

Gelegentlich reicht die in einem analogen Instrument vorhandene Skala nicht mehr aus, um einen Wert anzuzeigen. In solchen Fällen kann ein zusätzliches digitales Instrument sichtbar gemacht werden, um den Wert darzustellen (Abbildung 9): aus analogen Instrumenten werden damit kombinierte Instrumente. Solange sich der darzustellende Zahlenwert innerhalb des vorhandenen Skalenbereichs befindet, kann dieses Uber-/Unterlau finstrument unsichtbar bleiben. T r i t t der Wert jedoch aus dem darstellbaren Bereich, wird es sichtbar und überlagert das Analoginstrument.

Baukästen für Benutzerschnittstellen

238

0 T1T x y< ,20 80 C i 1 in 1 7.1 C J ' 30 •1 1 L 50 K

(

y

Abbildung 9.

• loa

400

• ao • eo

-jnn

^mhp

N

\

im

600 900 \ Hl •

• 20

•0

0-

Instrumente bei Uberlauf.

Durch diese Technik kann die Skala eines Instruments auf den Normalbetrieb ausgelegt werden, damit die Werte gut abzulesen sind. Wird dann der Maximalwert gelegentlich über- oder unterschritten, geht das Instrument nicht wie bei mechanischen Instrumenten in einen nutzlosen Endausschlag, sondern zeigt den Wert digital an. Alternativ wäre ein dynamisches Verändern des Skalenbereichs möglich; dies hat jedoch den Nachteil, daß sich der Beobachter nicht ohne Ablesen des genauen Werts orientieren kann, da sich die Skalen ständig beliebig verändern könnten. Bei einer routinemäßigen Überwachung wäre dies wegen möglicher Fehlinterpretation einer dargestellten Größe problematisch.

3. D i e S y s t e m s t r u k t u r v o n VlSIVAL Der logische A u f b a u und der Variationsreichtum von Instrumenten forden geradezu, Instrumente mittels eines Baukastens konfigurieren zu können. Die Bausteine sind die Anzeigen, Skalen, Beschriftungen und Alarme. Darüber hinaus können zum Beispiel Über-/Unterlaufanzeigen und andere Instrumente (Abbildung 10) in ein Instrument eingebaut werden. Man erhält auf diese Weise hierarchisch gegliederte komplexe Instrumente. Aufgrund des Gegenstandscharakters dieser Bausteine bietet es sich an, einen solchen Baukasten sowohl konzeptionell als auch programmtechnisch objektorientiert zu gestalten. Ein Alarmobjekt hat beispielsweise die Attribute unterer Grenzwert und oberer Grenzwert sowie die Methoden (d.h. funktionale Elemente) Ausgabe der Warnung (z.B. Warnton), Aktion bei Unterlauf und Aktion bei Uberlauf. Die Attribute und Methoden können für die jeweiligen Anwendungen verschieden definiert werden. Die verschiedenartigen Bausteine, die zu Instrumenten gekoppelt werden, besitzen jeweils eine Vielzahl von Attributen

und Methoden, die in

Objekt-

239

ViSrVAL ZeigerN Instrument J

Teile

( Unter V^ Instrument

/ \

Skalenelemente

Zeichensatz

f Beschriftetes^ Beschriftetes^ y SSkalenelementV kalenelement/ V Zeichensatz

/Unbeschriftete§\ ySkalenelementy

C Abbildung 10.

3

Aufbau des Instruments aus Abbildung 11.

200

N

Device

Abbildung 11.

Font

nV" \

Interrupts

Instrument, das sich gemäß Abbildung 10 zusammensetzt.

klassen

beschrieben

menten

wieder

werden.

vielfältige

Nun

weisen selbst die Bausteine

Differenzierungen

Klassenhierarchien beschrieben werden.

auf,

von

die objektorientiert

Instrudurch

Für die verschiedenen Zeiger ergibt

sich die Klassenhierarchie in Abbildung 12. Die Erstellung eines Instruments für eine bestimmte Anwendung besteht aus der

Auswahl,

Spezifikation

und

Generierung

ments aus den vorhandenen Klassen. bei

guter

Dokumentation

der

Bestandteile

des

Instru-

Dieser Konfigurationsprozeß ist selbst

eines Baukastens,

der beispielsweise

wie

VlSfVAL

240

B a u k ä s t e n f ü r Benutzerschnittstellen

Abbildung 12.

Klassenhierarchie von Zeigern.

mehr als 200 Bausteine in F o r m von Klassen besitzt, ein nicht m e h r einfaches u n d daher fehleranfälliges V e r f a h r e n .

ganz

F ü r das gewünschte Ausse-

hen u n d Verhalten eines I n s t r u m e n t s müssen die richtigen Bausteine erzeugt und

gekoppelt

werden.

sinnvoll u n d verträglich.

Nicht

alle

Kombinationen

von

Bausteinen

sind

So m a c h t es beispielsweise wenig Sinn, eine kreis-

förmige Skala mit einem linear bewegten Zeiger zu verbinden.

Es gibt eine

ganze Reihe solcher Restriktionen bezüglich der K o m b i n i e r b a r k e i t von Bausteinen sowie deren A t t r i b u t i e r u n g . lungsmöglichkeiten

erlaubt

aber

Benutzer und A n w e n d u n g .

Das v o r h a n d e n e S p e k t r u m der Darstel-

das

Maßschneidern

In A b b i l d u n g

Instrumenten

für

13 finden sich exemplarisch

von

die

Anwendungsprogrammierer

so

Variationen r u n d e r I n s t r u m e n t e . Benutzerschnittstellen-Baukästen weit wie möglich entlasten. Instrumenten

durch

ein

sollen

den

Daher bietet es sich an, die K o n f i g u r a t i o n von

interaktives

Der A n w e n d u n g s p r o g r a m m i e r e r

Konstruktorsystem

zu

unterstützen.

spezifiziert d a m i t - auf W u n s c h

systemge-

f ü h r t - wie die I n s t r u m e n t e aussehen sollen.

Das ganze S p e k t r u m an Mög-

lichkeiten wird dabei vor ihm ausgebreitet.

Seine E n t s c h e i d u n g e n

d u r c h die Darstellung eines Beispielinstruments verdeutlicht.

werden

V o m gesamten

Designraum werden ihm die jeweils noch verbleibenden sinnvollen

Freiheits-

grade angeboten und eventuell an Beispielen e r l ä u t e r t .

Das K o n s t r u k t o r s y -

stem benötigt dazu u.a. Wissen über Verträglichkeiten

bzw.

keiten zwischen den einzelnen Bausteinen.

Unverträglich-

VlSrVAL

241

steamer-gauge

20

40

30

50

\

10

V %

70

80

'/

round-pointer

Abbildung 13.

60

••'///

90

- gauge

Verschiedene kreisförmige Instrumente.

Ist ein Instrument

fertiggestellt, kann es vom Konstruktorsystem

Anwendungssystem angekoppelt werden.

Ist dieses noch nicht

an

das

vorhanden,

können Ein- und Ausgaben simuliert und so das spätere Verhalten des Instruments getestet werden. Ein solches Konstruktorsystem hat sich bei allen komplexen Baukästen als wichtige und oft notwendige Unterstützung herausgestellt. Für VISFVAL ist ein solches in Planung.

4. Z u s a m m e n f a s s u n g und A u s b l i c k Instrumente, wie sie beispielsweise mit VlSIVAL erzeugt werden können, sind nur

eine

Komponente

Komponenten Jedes dieser Baukasten dann

sind

Interaktionsmedien

modular

aufbauen

in allgemeineren

können.

eines

Benutzerschnittstellen-Baukastens.

beispielsweise

Formulare, läßt sich

und

Tabellen,

wiederum

konfigurieren,

Baukastensystemen

Icons

durch

wobei

Menüs.

einen

eigenen

diese

eine gemeinsame

Man gelangt so zu einem komplexen

Weitere und

System aus

Baukästen

Basis

besitzen

ineinanderge-

Baukästen für Benutzerschnittstellen

242

schachtelten, aufeinanderaufbauenden oder nebeneinanderstehenden Moduln, die als Gesamtheit den Kern eines sogenannten User Interface Management Systems (¡JIMS) bilden. Konstruktorsysteme, Anwendungssimulatoren und Benutzermodelle vervollständigen dieses UIMS weiter. Sowohl ergonomischen als auch wirtschaftlichen Forderungen kommt man mit solchen Systemen wesentlich entgegen [Herczeg 86a]. Wenn bislang vorwiegend Büroarbeiten durch moderne Benutzerschnittstellen mit Icons, Menüs und Formularen unterstützt werden konnten, so werden durch Systeme wie VlSIVAL in Zukunft auch Techniker ihre Arbeitswelt auf dem Bildschirm wiederfinden. In vielen Fällen werden sie ihre Anwendungen selbst mit geeigneten Interaktionsmedien (wie z.B. Instrumenten) versorgen; ein Beispiel dafür ist das computergestützte Elektronik-Simulationslabor ELAB, das in Kapitel II beschrieben ist. Als programmtechnische Basis für derartige

Benutzerschnittstellen-Baukästen

haben sich objekt- und frameorientierte Sprachen als sehr geeignet herausgestellt.

Bei VisrVAL ist es die Sprache ObjTalk

[Rathke C. 86b],

Als

Ausgabegerät wird ein hochauflösender Rasterbildschirm verwendet, als Zeigeinstrument eine Maus. Zu erwartende Verbesserungen in der Geschwindigkeit und der Feinheit der graphischen Ausgabe auf dem Bildschirm werden es ermöglichen, daß Bildschirminstrumente realen physikalischen Instrumenten in der Darstellungsqualität praktisch nicht mehr nachstehen. In Genauigkeit, Flexibilität und Robustheit sind sie ihnen heute schon überlegen. Der Trend zu Bildschirminstrumenten zeichnet sich bei aufwendigen technischen Überwachungssystemen wie zum Beispiel Flugzeugcockpits schon heute ab.

XTV

TRISTAN

Ein generischer E d i t o r für g e r i c h t e t e Graphen Helga Nieper-Lemke

Viele Computersysteme berücksichtigen trotz der heutzutage vorhanden Bildschirme mit hoher Auflösung noch nicht die visuellen Fähigkeiten des Menschen. Häufig verwendete Datenstrukturen sind Graphen, d.h. S t r u k t u r e n aus Knoten und sie verbindenden Kanten. Werden diese Strukturen textuell dargestellt, ist es sehr schwer, sie zu verstehen, wohingegen dies bei einer graphischen Darstellung oft mit einem Blick möglich ist. Ohne geeignete Unterstützung ist es für einen Programmierer eine mühevolle Aufgabe, ein Werkzeug zur Darstellung und Manipulation von Graphen, die in seiner Anwendung vorkommen, zu implementieren. In diesem Kapitel wird TRISTAN beschrieben, ein System, das es einem Anwendungsprogrammierer erlaubt, mit einfachen Mitteln einen Grapheditor für eine beliebige Anwendung zu implementieren. Das Ziel bei der Entwicklung war, durch das Auffinden geeigneter Abstraktionen wiederverwendbare Bausteine für Grapheditoren zur Verfügung zu stellen.

1. E i n l e i t u n g Graphen sind häufig verwendete Datenstrukturen.

Beispiele sind

hierarchien in einer objektorientierten Sprache, Dateihierarchien,

Klassen-

Funktions-

aufrufhierarchien, Syntaxbäume oder Projektmitarbeiterhierarchien. Ein Großteil der Funktionalität eines Systems zur Darstellung und Manipulation dieser Strukturen ist anwendungsunabhängig. Um zu vermeiden, daß Programmierer verschiedener Anwendungen „bei Null a n f a n g e n " und immer wieder die gleiche Funktionalität implementieren müssen, werden in TRISTAN anwendungsneutrale Bausteine zur Implementierung von Grapheditoren zur Verfügung gestellt 1 . Ein anderer Vorteil dieses generischen Ansatzes ist die einheitliche Bedienung der resultierenden Systeme.

1

Siehe hierzu a u c h die Diskussion über a n w e n d u n g s n e u t r a l e B a u s t e i n e in K a p i t e l XIII.

Prototypen benutzergerechter Computersysteme © 1988 Walter de Gruyter Sc Co. • Berlin • N e w York

244

B a u k ä s t e n für

In A n l e h n u n g

an

Generationsfolgen

werden

Benutzerschnittstellen

im folgenden

Begriffe

t e r n " für die d i r e k t e n V o r g ä n g e r u n d „ K i n d e r " für die d i r e k t e n eines K n o t e n s Abbildung über

die

wie

„El-

Nachfolger

verwendet.

1 zeigt, wie TRISTAN e i n g e s e t z t wird: zugrundeliegende

Grapheditor.

Zu diesem

Anwendung Wissen

u n d K i n d e r eines K n o t e n s

ergibt

gehört

berechnet,

TRISTAN u n d das

einen

Wissen

anwendungsspezifischen

beispielsweise,

wie m a n

was es b e d e u t e t ,

die

eine K a n t e

Eltern einzufü-

gen oder zu löschen, was es b e d e u t e t , einen K n o t e n zu erzeugen o d e r zu lös c h e n , u n d wie ein K n o t e n in der A n w e n d u n g bezeichnet

wird.

Wissen über Klassenhierarchien a | Klassenhierarchie-Editor |

TRISTAN

Abbildung

Da

mit

1.

Wiesen über Dateihierarchien

E i n s a t z von

TRISTAN 86]

Visualisierungswerkzeuge

terschied

beschriebenen

zu den dort

bestimmte

beschriebenen

Anwendung

leicht

erstellt

[ B ö c k e r , Nieper 8 5 ]

Idee eines

ausgerichtet

TRISTAN b e s o n d e r e r W e r t

~|

TRISTAN.

stellt es einen B e i t r a g zu der in Nieper

= | Dateihierarchie-Editor

werden

und

„Software-Oszilloskops"

dar.

Visualisierungswerkzeugen, sind,

wurde

bei

der

a u f die W i e d e r v e r w e n d b a r k e i t

können,

[Böcker,

Fischer, Im

Un-

die a u f eine

Entwicklung der e i n z e l n e n

von Bau-

s t e i n e gelegt.

2. Z w e i Abbildung dient

zur

Beispielanwendungen 2

zeigt

zwei

Darstellung

Anwendungen

von

von

TRISTAN.

Klassenhierarchien

einer

abstrakten

denselben

Algorithmus

stieren

dieselben

Ebene

die

gleiche

Operationen

für die K n o t e n

Sie enthalten

wiederum

dieselbe

die gleichen

haben

Sie

benutzen

Funktion

haben

und

der G r a p h e n .

außer den letzten

nur

der

Anwendung

z.B.

u n d es exi-

Letzteres

wider, die für die K n o t e n

Einträge,

System

Beide Systeme

Funktionalität:

zur P l a n u n g der r ä u m l i c h e n A n o r d n u n g ,

gelt sich in den gezeigten P o p u p - M e n ü s sind:

erste

Spra-

che, das zweite zur D a r s t e l l u n g von D a t e i h i e r a r c h i e n . auf einer

Das

objektorientierten

spie-

definiert

vier, die

aber

entsprechend

245

TRISTAN

bezeichnet wurden.

Im Falle der Dateihierarchie wurden zwei verschiedene

Arten

verwendet:

von

Knoten

Knoten

mit

Rand

für

Dateiverzeichnisse,

Knoten ohne R a n d für Dateien.

class-hi erarchy-wiiulow Ii nt : s i wpl e-dl so I av-req 1 on| cInss-menu

move move-hor1z move-vert adjust-x adjust-y kill ki 11-subhlerarchy display-subhlerarchy tobottom totop refresh flip display-one-superclass... dlsplay-al1-superclasses display-one-subclass... d1splay-al1-subclasses

la i up I e-d I SPI ay-req ¡ onl Fi sp I av-req i oiil Ibg-n I K I nl

lus : d i sp I ay-req I onl

It 1t1 e-ni K i ni Iborder-ni K I ñl

Ipane-nt ni ni

Ibas i c-Mi ndoul

Isuper-uI r i d o l t e w t - u I ridoni |paned-u I ndoj

It tv-ut ndoul

(I i rector y-ln erarchy-w i ntlow ut I I-ni Ki n.o ut I I -nl xl n. I •repr-n iKin.o repi—nlKi n.I order-n iKin.o order-nI Hi n.I node-ni KIn.o node-niK i n.I Bocl (I i rectory-menu

move aove-horlz •ove-vert adjust-x adjust-y k111 k111-subhìerarchy dlsplay-subhlerarchy tobottom totop refresh flip d1splay-one-parentd1rectory... display-all-parentd1rector les display-one-subdirectory... di splay-all-subdirector les

Abbildung 2.

short des. nss Iongdes.nss Readtle kaestI e.I kaestIe-to-pIc.I kaestIe-phash.s ci rei e.I autoup. I ReadMe HakefI le kaestIe85.I.Z kaestIe84.I.Z kaestIe83.I.Z hdskaestI e.I.Z gkaestI e.I-Z bkaestI e.I .Z ReadMe

Zwei Beispielanwendungen von TRISTAN.

246

B a u k ä s t e n f ü r Benutzerschnittstellen

3. F u n k t i o n a l i t ä t v o n TRISTAN Zur F u n k t i o n a l i t ä t von TRISTAN gehört die Darstellung einer beliebigen Untermenge von K n o t e n mit den zugehörigen K a n t e n (selektives Darstellen eines G r a p h e n ) , die a u t o m a t i s c h e P l a n u n g der räumlichen A n o r d n u n g Operationen zum Editieren der graphischen Darstellung bzw. der liegenden S t r u k t u r .

sowie

zugrunde-

Daneben können dynamische Abläufe visualisiert

wer-

den, und es lassen sich Aktionen definieren, die durch Mausklicks auf einem K n o t e n ausgelöst werden.

Selektives Darstellen des

Graphen

In vielen A n w e n d u n g e n m u ß davon ausgegangen werden, d a ß ein G r a p h so umfangreich

ist,

werden k a n n .

daß er

nicht

vollständig

auf

dem

Bildschirm

dargestellt

Dies ist meist auch nicht notwendig, da der B e n u t z e r o f t

nur an einem Ausschnitt des G r a p h e n interessiert ist.

Eine Möglichkeit zur

Lösung des Problems ist, d e m Benutzer immer nur einen rechteckigen Ausschnitt

einer

Operationen

vollständigen zum

Darstellung

Verschieben

der

des

Graphen

Darstellung

zur

zu

zeigen

Verfügung

und zu

ihm

stellen.

Das P r o b l e m hierbei ist, daß es f ü r den Benutzer schwierig ist, einen Uberblick über die G e s a m t s t r u k t u r den.

zu b e k o m m e n u n d sich in ihr

zurechtzufin-

Verkleinerte Ubersichtsgraphen k ö n n e n hier etwas Abhilfe s c h a f f e n .

In TRISTAN w u r d e ein anderer Ansatz gewählt, nämlich ein selektives stellen

des G r a p h e n :

mens sichtbar gemacht werden. Knoten

können

bzw. Eltern,

Dar-

Ein einzelner K n o t e n k a n n d u r c h A n g a b e seines NaAusgehend von einem bereits dargestellten

alle seine K i n d e r

die aus einem

Menü

bzw. Eltern oder auch ausgewählt

werden,

einzelne

dargestellt

Kinder werden.

Ebenso k a n n der gesamte Unter- bzw. Ü b e r b a u m eines K n o t e n s (bis zu einer angebbaren Tiefe) ausgegeben werden. Da es f ü r den Benutzer oft wichtig ist, zu sehen, ob ein K n o t e n

Kinder

oder Eltern hat, die nicht dargestellt sind, k a n n er sich dies d u r c h angedeutete K a n t e n (beschriftet mit der Anzahl nicht dargestellter K i n d e r bzw. Eltern) anzeigen lassen.

P l a n u n g der räumlichen

Anordnung

Bei der P l a n u n g der räumlichen A n o r d n u n g der Knoten eines G r a p h e n wird vorausgesetzt, daß die K n o t e n als rechteckige Bereiche dargestellt sind. Breiten

und Höhen der Rechtecke können

und G r a p h i k e n t h a l t e n .

variieren, und sie k ö n n e n

Die Text

247

TRISTAN

Der verwendete Planungsalgorithmus setzt außerdem eine hierarchische Ordnung der Knoten voraus, d.h. er nimmt an, daß zwischen den Knoten eine „Eltern-Kinder-Beziehung" besteht und der Graph keine Zyklen enthält. Ausgehend von dieser Voraussetzung gibt es zwei verschiedene Möglichkeiten (siehe auch Abbildung 2): eine Orientierung von oben nach unten (vertikale Orientierung) oder von links nach rechts (horizontale Orientierung). Während die vertikale Orientierung üblicher ist, ist die horizontale i.a. platzsparender, vor allem bei „buschigen" Strukturen. In TRISTAN kann der Benutzer zwischen horizontaler und vertikaler Orientierung auswählen. Weiterhin verwendet TRISTAN zum Zeichnen der Kanten nur gerade Linien, ohne dabei die Lage von anderen Knoten und Kanten zu berücksichtigen. Unter diesen Voraussetzungen kann ein einfacher horizontaler Planungsalgorithmus 2 wie folgt beschrieben werden (die x- und y-Koordinaten

beziehen

sich hierbei auf die linke obere Ecke eines Knotens; der Ursprung des Koordinatensystems befindet sich links oben): 1. Die y-Koordinaten werden in der Reihenfolge „Tiefe zuerst" bestimmt: • Wenn ein Knoten Kinder hat, plane diese zuerst der Reihe nach und bestimme seine y-Koordinate so, daß sein Zentrum in der Mitte zwischen dem ersten und dem letzten Kind liegt. • Wenn ein Knoten keine Kinder hat und ein älterer Geschwisterknoten existiert, setze den neuen Knoten direkt darunter. • Sonst bestimme die y-Koordinate so, daß der Knoten unterhalb des bisher untersten Knotens liegt; wenn es noch keinen gibt, nimm y = 0 . 2. Die x-Koordinaten werden in der Reihenfolge „Breite zuerst" bestimmt: • Der Wurzelknoten liegt bei x=0. • Alle Knoten einer Generation haben dieselbe x-Koordinate. • Der Abstand zwischen Generation n und Generation n-1 wird durch den längsten Knoten der Generation n plus einer Konstanten bestimmt. Dieser Planungsalgorithmus wurde für Bäume entwickelt.

Er ist zwar hin-

sichtlich der Platzausnutzung nicht optimal, liefert aber ein optisch zufriedenstellendes Ergebnis.

2

Für andere hierarchische Strukturen mit nur einer

Dieser Algorithmus k a m beispielsweise im unteren Fenster von Abbildung 2 zum Einsatz. Ein vertikaler Planungsalgorithmus kann analog beschrieben werden.

248

Baukästen für Benutzerschnittstellen

Wurzel kann er oft auch verwendet werden, aber für Graphen mit mehr als einer Wurzel und zyklische Graphen liefert er kein befriedigendes Ergebnis. Natürlich kann dieser Planungsalgorithmus verbessert werden (siehe dazu [Vaucher 80] und [Reingold, Tilford 81]), aber es gibt Gründe, w a r u m ein Planungsalgorithmus wohl nie optimal sein wird: • Der Begriff der „Schönheit" einer Darstellung ist sehr subjektiv. • Die Semantik einer S t r u k t u r erfordert oft eine Darstellungsform, nicht von der Syntax der S t r u k t u r abgeleitet werden kann.

die

Daher wurde in TRISTAN ein kooperativer Ansatz gewählt: Der Computer erzeugt eine vorläufige Darstellung, und der Benutzer ändert die Anordnung der Knoten von Hand, bis sie seinen Vorstellungen entspricht. Dies wurde z.B. im oberen Fenster von Abbildung 2 getan. Es soll hier noch erwähnt werden, daß bei TRISTAN kein Wert auf einen möglichst effizienten Planungsalgorithmus gelegt wird (wie in [Robins 87]), da die Anzahl der dargestellten Knoten eines Graphen als klein angenommen wird.

E d i t i e r e n durch d i r e k t e

Manipulation

TRISTAN stellt eine Reihe von Operationen zur direkten Manipulation des äußeren Erscheinungsbildes eines Graphen zur Verfügung. Diese Operationen lassen den Graphen selbst unverändert. Mit ihnen kann der Benutzer bestimmen, welche Teilstrukturen wo abgebildet werden. Folgende Operationen stehen zur Verfügung: • Bewegen von Knoten an beliebige Positionen, eingeschränkt auf Positionen genau neben bzw. unter einem anderen Knoten oder eingeschränkt auf horizontale bzw. vertikale Bewegungsrichtung, • Darstellen von zusätzlichen Teilstrukturen, • Löschen einzelner Knoten oder Teilstrukturen vom Bildschirm, • Neuplanen der Darstellung von Teilstrukturen. Ebenso können durch direkte Manipulation in der graphischen

Darstellung

neue Knoten und Kanten kreiert oder existierende gelöscht werden.

Dazu

muß der Programmierer TRISTAN mitteilen, was dies in der Anwendung bedeutet, damit der

zugrundeliegende

kann (siehe hierzu Abschnitt 4).

Graph

entsprechend

angepaßt

werden

249

TRISTAN

Weitere funktionelle Eigenschaften Durch Inversdarstellung von sog. „aktiven K n o t e n " können dynamische Abläufe visualisiert werden.

Dies wurde beispielsweise in einem System

zur

Darstellung von Regelmengen (siehe Abbildung 10) eingesetzt, wobei die jeweils feuernde Regel markiert wurde. System wie das in

Eine weitere Anwendung wäre ein

[Böcker, Nieper 85] und

[Böcker, Fischer, Nieper 86]

beschriebene FOOSCAPE, das die augenblicklich

aktiven

Funktionen

eines

Programms in einer graphischen Darstellung der Aufrufhierarchie markiert, während das P r o g r a m m abläuft. Des weiteren können

mit einem Knoten Aktionen

durch einen Mausklick ausgelöst werden.

verknüpft werden,

die

Eine solche Aktion könnte z.B.

eine Detaildarstellung des Knotens bewirken und das Editieren des Knoteninhalts erlauben.

4. TRIKIT - Ein S y s t e m z u m E r s t e l l e n v o n TRISTAN-Anwendungen TRIKIT

ist

ein

System,

das

dem

Anwendungsprogrammierer

hilft,

die

Schnittstelle zwischen der Anwendung und TRISTAN zu definieren und damit einen anwendungsspezifischen Grapheditor zu erstellen.

Es wurde von

A. Lemke implementiert [Fischer, Lemke 88a; Fischer, Lemke 88b]. Abbildung 3 zeigt den Einsatz von TRIKIT. kann

mit

Hilfe dieses Systems einen

Der Anwendungsprogrammierer

anwendungsspezifischen

implementieren, ohne TRISTAN selbst kennen zu müssen.

Abbildung 3.

Einsatz von TRIKIT (nach [Fischer, Lemke 88b]).

Grapheditor

250

B a u k ä s t e n f ü r Benutzerschnittstellen

A n h a n d der Erstellung eines graphischen Dateihierarchie-Editors wie in Abbildung 4 soll im folgenden der Einsatz von TRIKIT demonstriert K n o t e n sind

hierbei Dateiverzeichnisse

u n d Dateien.

Ein

werden.

Dateiverzeichnis

k a n n andere Dateiverzeichnisse und Dateien e n t h a l t e n , was d u r c h die K a n ten des G r a p h e n veranschaulicht

werden soll.

Außerdem sollen

Dateiver-

zeichnisse u n d Dateien optisch voneinander unterscheidbar sein.

•Idöcl

Abbildung 4.

Ein graphischer Dateihierarchie-Editor.

Der Benutzer von TRIKIT b e k o m m t ein F o r m u l a r wie in A b b i l d u n g 5 vorgelegt.

Es h a t verschiedene Feldertypen:

• Editierfelder werden d u r c h ihren g e p u n k t e t e n H i n t e r g r u n d angezeigt u n d dienen zum Eintragen und Ä n d e r n von N a m e n , Zahlen, P r o g r a m m c o d e usw. Durch einen Mausklick wird ein Feld selektiert u n d k a n n d u r c h Eingabe von der T a s t a t u r editiert werden. • Auswahlfeider werden verwendet, wenn die Anzahl der möglichen W e r t e f ü r dieses Feld sehr klein ist. Durch Mausklicks können diese W e r t e nacheinander angezeigt werden. • Menüfelder werden verwendet, wenn die Anzahl der möglichen W e r t e f ü r dieses Feld zu groß f ü r ein Auswahlfeld ist. Ein Mausklick auf diesem Feld erzeugt ein P o p u p - M e n ü der möglichen Werte. • Buttons werden als schmale Rechtecke dargestellt. Ein Mausklick auf diesem Feld löst die mit ihm v e r b u n d e n e Aktion aus. • Icons, die einen Zugriff auf U n t e r f o r m u l a r e ermöglichen, h a b e n eine quadratische F o r m . Ein Mausklick bewirkt, daß das e n t s p r e c h e n d e U n t e r f o r m u l a r auf den Bildschirm k o m m t . Durch einen Mausklick auf d e m D i r e c t o r y - I c o n F o r m u l a r , das in Abbildung 6 gezeigt ist, sichtbar.

in Abbildung 5 wird

das

W ä h r e n d das H a u p t f o r -

mular allgemeine Angaben über den G r a p h e n e n t h ä l t , beschreiben die Unt e r f o r m u l a r e Eigenschaften der K n o t e n .

251

TRISTAN

Itristan-design-kit Name of relation:

directory-hierarchy';

An item is called a:

directory; ;

Name of child relation:

subdirectory '•;•;

Name of parent relation:

parent-directory

Default layout direction:

horizontal

Evaluate item name?

No

Compare items by:

equal;';-; ;•

:; ;;

Pname selector f o r items:

de:pname; : ; ;•;';•;•;•:•;•;• Create an unlinked item with name "name": Create a child for "item" called "name": (de:create-child name item) ; Add "child" t o "item": Remove "child" f r o m "item": Relink "item" f r o m " p a r e n t i " t o "parent2": (de.move item parent2);•;•:•;•;•; The window has a default size? Width:

466

;:

Height:

T y p e s of items:

|Shou

|s a vg s ^ t . . on Fi u I ¡Create

S-jsten

and

Yes

149:

|SpP.C!fH

tristan-system.l

I n , t a n t , a t e 11

size

[Create

rubber

bo-'

:

S-jst]^

» Abbildung 5.

uiTh

E x a n p le